System Safety Development of a Performance PHEV Through a Model-Based Systems Engineering Approach

THESIS

Presented in Partial Fulfillment of the Requirements for the Degree Master of Science in the Graduate School of The Ohio State University

By

Samuel Yacinthe

Graduate Program in Mechanical Engineering

The Ohio State University

2016

Master's Examination Committee:

Prof. Shawn Midlam-Mohler, Advisor

Prof. Giorgio Rizzoni

Copyright by

Samuel Yacinthe

2016

Abstract

The Ohio State University is participating in EcoCAR 3, which is a four-year long competition amongst 16 North American university teams to redesign the 2016 Chevrolet

Camaro to reduce its environmental impact, while maintaining the muscle and performance expected from the iconic American car. To effectively assess and increase overall product quality and readiness of Ohio State’s vehicle, this work defines and deploys a state of the art Model-Based Systems Engineering (MBSE) approach for managing engineering complexity as it relates to requirements management, traceability, and fulfillment. To demonstrate the effectiveness of the implemented approach, this work presents system

safety development activities that have been conducted during the first two years of the competition. As EcoCAR 3 transitions into year-three, this work has already contributed to over a dozen awards by increasing overall documentation, traceability and workflow management as part of the overall engineering development process.

ii

Dedication

This is dedicated to my family and friends who have helped support and guide me over

the years during my pursuit of higher education.

iii

Acknowledgments

I would like to thank my advisor, Prof. Shawn Midlam-Mohler, for his superb guidance and knowledge throughout this thesis work and throughout my tenure with the

EcoCAR team. His ideas, thoughts, and management made my time on the EcoCAR team successful and this thesis possible. I'd also like to acknowledge the team members who have been a part of EcoCAR 3 that have helped make this experience beyond educational, while also playing key roles in making the first two years of competition successful at Ohio

State: Brandon Bishop, Tom Brown, Greg Jankord, Aditya Karumanchi, Arjun Khanna,

Dennis Kibalama, Aditya Modak, Brielle Reiff, Jenn Shafer, Trevor Thompkins, Nick

Tomczak, and Jason Ward. A special shout-out to M.J. Yatsko for dealing with all the things that I did not want to deal with. Also, a special thanks to Prof. Giorgio Rizzoni and all the EcoCAR industry sponsors, for their support throughout my time on EcoCAR.

iv

Vita

February 22, 1991 ...... Born – Cap-Haitien, Haiti

2009...... West Boca Community High School

2014...... B.S. Mechanical Engineering, University of

Central Florida

2014 to present ...... Graduate Fellow, The Ohio State University

Publications

Yacinthe, S., Khanna, A., Ward, J., Yatsko, M. et al., "Development of the Design of a Plug-In Hybrid-Electric Vehicle for the EcoCAR 3 Competition," SAE Technical Paper

2016-01-1257, 2016, doi:10.4271/2016-01-1257.

Khanna, A., Yacinthe, S., Ward, J., Yatsko, M. et al., "Model and Controls Development of a Post-Transmission PHEV for the EcoCAR 3 Competition," SAE Technical Paper 2016-01-1252, 2016, doi:10.4271/2016-01-1252.

Field of Study

Major Field: Mechanical Engineering

v

Table of Contents

Abstract ...... ii

Dedication ...... iii

Acknowledgments...... iv

Vita ...... v

Table of Contents ...... vi

List of Tables ...... ix

List of Figures ...... x

Chapter 1: Introduction ...... 1

1.1 Background ...... 1

1.2 Motivation ...... 1

1.3 Project Objective ...... 4

1.4 Organization of Thesis ...... 4

Chapter 2: Literature Review ...... 5

1.1 Systems Engineering ...... 5

1.1.1 Motivation and Introduction ...... 5

vi

1.1.2 Model-Based Systems Engineering ...... 15

1.1.3 System Safety Alignment ...... 23

1.1.4 State of the Art Methodologies ...... 27

Chapter 3: Model-Based Systems Engineering Approach ...... 36

1.1 Implemented Approach ...... 36

1.2 Supporting Tools Implemented...... 39

1.3 Alignment with System Safety Development ...... 41

1.4 Deployment Strategy ...... 45

Chapter 4: System Safety Analysis ...... 48

1.1 Introduction ...... 48

1.2 Preliminary Hazard Analysis and Safety Concept ...... 48

1.3 Requirements Generation and Management ...... 55

Chapter 5: System Safety Design and Implementation ...... 63

1.1 Introduction ...... 63

1.2 Software Design ...... 64

1.3 Implementation and Testing ...... 70

Chapter 6: Accomplishments and Future Work ...... 80

1.1 Accomplishments ...... 80

1.2 Future Work ...... 80

vii

Bibliography ...... 81

Appendix ...... 83

1.1 Safety Analysis: Diagrams and Snapshots of Working Documentation ...... 83

viii

List of Tables

Table 1: Ohio State EcoCAR 3 Vehicle Architecture Component Specifications ...... 3

Table 2: Tables and Matrix Summary Views [16]...... 44

Table 3: Summary of Additional Safety Systems Identified ...... 54

Table 4: Torque Estimation Methods for Transmitting Devices ...... 68

ix

List of Figures

Figure 1: Vehicle Development Process ...... 2

Figure 2: Ohio State EcoCAR 3 Vehicle Architecture ...... 2

Figure 3: Traditional Product Development Sequential Process [10] ...... 6

Figure 4: Systems Engineering Practice and Process [10] ...... 9

Figure 5: Traditional V-model for Systems Engineering [10] ...... 10

Figure 6: The Common Process Validation Leading to Integration Wars [10] ...... 14

Figure 7: Continuous Validation with the Customer in the Loop [10] ...... 14

Figure 8: INCOSE MBSE Roadmap [9] ...... 17

Figure 9: Traceability from Requirements to Engineering Artifacts [7] ...... 19

Figure 10: Traceability Between Elements of Different Artifacts [6] ...... 20

Figure 11: Systems Modeling and Common Elements [7] ...... 21

Figure 12: Requirements Coverage and Fulfillment [7] ...... 22

Figure 13: Main Tools for MBSE [8] ...... 24

Figure 14: Systems Models and Functional Safety Analysis [12] ...... 26

Figure 15: Model- and State-Based Control Architecture ("Control Diamond") [11] .... 28

Figure 16: Conceptual Layout of Requirements, Functions, and Components. [11] ...... 29

Figure 17: Vitech MBSE Primary SE Activities [11] ...... 31

Figure 18: Vitech MSBE Primary SE Domains [11] ...... 32 x

Figure 19: Harmony Integrated Systems and Software Development Process [11] ...... 33

Figure 20: Harmony-SE Process Elements [11] ...... 35

Figure 21: Rational Integrated Systems/Embedded Software Development Process [14] 37

Figure 22: Rational Solution for Systems and Software Engineering [15] ...... 38

Figure 23: IBM Rational Supporting Tools ...... 39

Figure 24: MathWorks and dSPACE Model-Based Design Tools for SW Dev...... 41

Figure 25: Example of FTA Linked to Requirements [16] ...... 43

Figure 26: Deployment Timeline for Integration of MSBE Approach...... 45

Figure 27: High Level Block Diagram of Functional Control System ...... 49

Figure 28: Hazard Identification and Classification Process ...... 50

Figure 29: Hazard Identification Example ...... 51

Figure 30: Process for Developing Diagnostic and Mitigation Strategies ...... 52

Figure 31: Examples of Developed Diagnostic and Mitigation Strategies ...... 53

Figure 32: Hazard Metrics Translation Process ...... 56

Figure 33: Hazard Metrics Translation Example ...... 57

Figure 34: Process for Defining Safety Requirements ...... 58

Figure 35: Example for defining safety requirements ...... 58

Figure 36: Process for Developing Preliminary V&V Plans ...... 59

Figure 37: Highlight of IBM Quality Manager for V&V Plans ...... 60

Figure 38: Initial Documentation Workflow ...... 61

Figure 39: Snapshots of IBM DOORS Tool Integration ...... 62

Figure 40: OSU Controls Software Development Process ...... 63

xi

Figure 41: High-level Functional Safety Software Design ...... 65

Figure 42: Torque Security Monitoring Process ...... 66

Figure 43: Comparison of Feedback Torque, Estimated Torque, and Allowable Range . 69

Figure 44: DOORS Integration for Requirements Traceability ...... 70

Figure 45: V-Process with Verification and Validation Emphasis ...... 71

Figure 46: Controls Software Development Process [need citation] ...... 73

Figure 47: Example of Directional Torque Flow in EV Only Mode ...... 74

Figure 48: Example of EM Torque Signals ...... 75

Figure 49: Statistics for Requested Torque versus Commanded Torque ...... 75

Figure 50: Statistics for Commanded Torque versus Torque Feedback ...... 76

Figure 51: Example Testing for Fault Insertion ...... 77

Figure 52: Tiered Fault Mitigation Strategy ...... 78

Figure 53: Example of Tiered Fault Mitigation Strategy ...... 79

Figure 54: CAN Interactions ...... 83

Figure 55: Electrical Interactions ...... 84

Figure 56: Torque Flow Interactions ...... 85

Figure 57: Snapshot of Working Documentation for Preliminary Hazard Analysis ...... 86

Figure 58: Snapshot of Working Documentation for Safety Concept ...... 87

xii

Chapter 1: Introduction

1.1 Background

Given the continued trends in the automotive industry for increased fuel economy and reduced emissions, solutions have been driven by innovative research in the area of hybrid electric vehicles and subsequent technologies. To help support this effort, the United

States Department of Energy (U.S. DOE) has sponsored the Advanced Vehicle Technology

Competitions (AVTC’s) for over the past 27 years. Through management by Argonne

National Labs (ANL), the AVTC program has partnered with North American OEMs and

automotive suppliers to serve as the premier training ground in developing the next generation of automotive engineers and future leaders in engineering. The latest ATVC is

EcoCAR 3, in which students are challenged to re-engineer a stock conventional vehicle to a hybrid-electric powertrain.

1.2 Motivation

In particular, the Ohio State University is participating in EcoCAR 3, which is a four-year long competition amongst 16 North American university teams to redesign the

2016 Chevrolet Camaro to reduce its environmental impact, while maintaining the muscle and performance expected from the iconic American car. Figure 1 illustrates the four-year

1

long vehicle development process, highlighting the design, integration, development, and market engagement gates throughout the years.

Figure 1: Vehicle Development Process

To meet the performance hybrid vehicle requirements of the competition, the Ohio State team has designed a plug-in hybrid-electric architecture that’s illustrated in Figure 2.

Figure 2: Ohio State EcoCAR 3 Vehicle Architecture 2

As Figure 2 highlights the configuration of the vehicle, Table 1 details the architecture components, including the manufacturer, model, and key performance specifications.

Table 1: Ohio State EcoCAR 3 Vehicle Architecture Component Specifications

Component Manufacturer & Model Performance Specifications Engine 2.0L GDI TiVCT I4 E85 119 kW, 198 Nm Transmission Tremec T-5 5-speed MT (to be automated) BAS Motor Denso ISG 32 kW, 350V

BAS Inverter Rinehart PM100DX 360V Max DC; 300 Arms/350 Apeak Electric Machine Parker GVM-210-150S 112 kW peak, 350V

EM Inverter Rinehart PM150DX 360V Max DC; 450 Arms/750 Apeak Mechanical American Axle Custom Designed and Made Coupler Rear Differential General Motors Stock 2016 Camaro part Fuel Tank OSU custom made 8.2 Gal capacity Charger Brusa NLG513 3.7 kW, air cooled

To effectively assess and increase overall product quality and readiness, a robust framework for managing engineering complexity is needed throughout the vehicle development process. Specifically, in order to realize requirements driven by the EcoCAR

3 competition and the Ohio State team, there must be processes and tools in place for requirements management, traceability, and fulfillment throughout all levels of the development process. Implementing a suite of processes and supporting tools that align with development activities will lead to increased documentation, reduced re-work, and ultimately an accelerated engineering environment.

3

1.3 Project Objective

The goal of this project is to lay down a foundation for increasing the overall product quality and readiness of Ohio State’s EcoCAR 3 vehicle. This work defines and deploys a state of the art Model-Based Systems Engineering (MBSE) approach for managing engineering complexity as it relates to requirements management, traceability, and fulfillment. To demonstrate the effectiveness of the implemented approach, this work presents development activities for system safety that have been conducted so far.

1.4 Organization of Thesis

The rest of the thesis is organized as follows:

Chapter 2 will introduce the concept of systems engineering and its motivation. This

chapter will also elaborate on MBSE, the state of the art approaches, and the supporting tools that have been implemented.

Chapter 3 will elaborate on the specific MBSE approach that the Ohio State team is implementing, focusing on specific supporting tools, and how the approach aligns with

EcoCAR 3 and system safety activities.

Chapter 4 will go into specific system safety analysis activities that have been conducted and how they have been integrated into the MBSE framework

Chapter 5 will be a deep dive into system safety software design, implementation and testing to demonstrate how the MBSE framework supports these development activities.

Chapter 6 will draw conclusions on the project by highlighting accomplishments and areas where future work can be conducted. 4

Chapter 2: Literature Review

1.1 Systems Engineering

1.1.1 Motivation and Introduction

Motivation for Systems Engineering

Presented in Figure 3 is today’s sequential process for product development which is geared towards static, stand-alone, hardware-centric products. The procedure begins with bright individuals asking, “What can we build that will make money?” and concludes with a complete product that’s handed off to manufacturing. This process assumes that all

requirements can be determined a head of time and treats changes to requirements as an undesirable burden [1].

In particular, these static requirements are viewed as outputs of the planning stage and inputs to the design stage, while the sets of requirements for hardware and software are related. For hardware and software design and development, these activities are done independently without much collaboration amongst teams. Next, the system design, including hardware, software, and the associated bill-of-materials (BOM) are released to manufacturing, which optimize time and cost to build the product. Lastly, hardware and software integration takes place at the end of the development process [1].

5

Figure 3: Traditional Product Development Sequential Process [1]

Initially this traditional waterfall approach for product development may seem to make sense by enabling teams of experts to focus on their respective areas. But it’s becoming clear that with today’s evolving products, the traditional process can be improved in a number of areas including the following [1]:

. Aversion to change: As end-users and customers change their minds along with

the availability of new technologies and competitive products, requirements do

change, thus requirements stability is beyond optimistic in sequential product

development. In such a process, change is considered incredibly disruptive to

previously defined plans that lead to a significant amount of rework. As change is

6

inevitable and will continue to increase, rethinking traditional approaches for

managing change is critical [1].

. Inefficient use of engineering resources: The sharing of data, information, and

expertise are constrained due to silos of development. On the off chance that one is

developing a new product that shares features with or has comparable elements to

an existing product, the new product is developed from scratch [1].

. Internal focus: The traditional waterfall product development process often has an

internal focus. For better agility and to improve the development process,

opportunities need to viewed for continuous gathering of information from stake

holders and operational systems [1].

. Misaligned metrics: Metrics frequently have an inner core interest on internal

processes. Effective metrics need to highlight how well a product meets

specifications [1].

. Late discovery of defects: The inevitable integration wars begin due to integration

of mechanical, electrical, and software systems happening at the end of

development. Integration problems are difficult to diagnose as they are discovered

very late in the engineering process [1].

. Gap between needs and requirements: After the completion of integration wars,

and the system has gone through exhaustive testing, the validation process begins.

As this process takes place at the end to check how well the product meets the

customer and end-user needs, needs have changed, and there’s a significant gap

between user expectations and product performance [1].

7

Introduction to Systems Engineering

Systems engineering can be defined as, “an interdisciplinary approach for creating large, complex systems that meet a defined set of business and technical requirements”.

With a new era of smarter and highly connected products, the fundamentals of systems engineering can be used to develop these smarter, interconnected products, though the specific approach could use some work. Produced out of the space program systems engineering consist of both a practice and a process[1]:

. As a practice, systems engineering deals with the overall behavioral and functional

features of systems, how they interface amongst other systems and users, the

interactions between the subsystems, and how the interdisciplinary of engineering

unite to work together [1].

. As a process, systems engineering lays out “a robust, structured approach to system

development that can be applied at a system- of- systems level or within specific

engineering disciplines”. Figure 4 illustrates the “realm” of systems engineering,

highlighting the alignment of practice and process [1].

8

Figure 4: Systems Engineering Practice and Process [1]

“Since the 1990s, systems engineering has been successfully helping companies grapple with increasingly complex products”. Today, the systems engineering philosophy,

“of viewing products as one part of an overall system and defining a structured approach to development” continues to be valid as it has been in the past. The traditional systems engineering process, illustrated by the V-model in Figure 5, is however sequential in nature, and as stated previously sequential process are far from ideal moving forward. Thus new approaches to implementing systems engineering must be explored [1].

9

Figure 5: Traditional V-model for Systems Engineering [1]

Given current trends of increased product complexity, an overall systems focus should be kept, “not only just on the system you’re building but also on the larger system it’s a part of and on the system that the larger system is a part of”. Thus, any new approaches to systems engineering should build on the following key components [1]:

. Levels of abstraction: This component aids with establishing defined scopes and

boundaries between elements of work to enable those elements to be further refined

and developed in parallel. “System decomposition is a critical technique for

improving parallelism in the development process” [1].

10

. Modeling: System models allows for complexity at different levels of abstraction

to be captured, thus enabling exploration of the details at each level. These models

also provide a method for capturing system decomposition at levels of abstraction

without the need of providing all the implementation details. “Modeling languages,

such as the Systems Modeling Language (SysML), use a common vernacular to

represent system models in order to promote shared understanding” [1].

. Traceability: “All the steps on the left side of the “V” are linked through

requirements, which are referenced as the steps up the right side of the “V” are

executed, providing the ability to trace all design elements back to specific

requirements” [1].

What is considered to be a good system engineering process “captures traceability between the different artifacts in the life cycle to capture relationships and document decisions so

you can better understand cause-and-effect, explore the impact and scope of a change, and provide auditability for compliance reasons” [1].

Systems engineering has provided a solid foundation for product development, “it has traditionally been carried out as a series of sequential processes, traversing the “V” from left to right, starting with requirements and ending with release to manufacturing”.

Though, what is needed now is a less constrained approach to systems engineering, “that welcomes change by leveraging an open tools platform to ensure that all users have easy access to information anywhere in the life cycle at any time”. On the bright side, the high- tech industry is quickly producing new developments that support turning systems engineering into a “powerhouse” for smarter product development [1].

11

Ensuring that the system is built to the desired specification is great, but what if initial requirements driven by the customers or stakeholders change? This is where validation is key. Validation is a process that ensures that requirements conform with the users’ needs and uses. In particular, it involves these two things [1]:

. “Helping your customers figure out their needs because users can’t always

conceptualize exactly what it is they need” [1]

. “Making sure to share the same understanding of what you’re going to build for

your customers” [1]

Some example of questions that able to be answered through validation include:

. “Should a user be able to customize the fields in the display on a runner’s watch?”

[1]

. “What’s the right behavior of a Wi-Fi-enabled home dialysis system when the

connection is intermittent?” [1]

. “Is this {command1, command2, . . .} the right sequence of voice commands for

making a phone call while driving your car?” [1]

Although validation is not a new concept when developing a product, it is common practice to validate a system against customer needs, but only after the system has been designed, developed, tested, and integrated. The new approach to validation in the concept of

“continuous engineering” is about when and how often validation is done. “Continuous engineering challenges you to validate your progress continuously with your customer throughout the entire design — not just at the end” [1].

12

Further, the concept of continuous validation is, “an ongoing, iterative discovery process through which you continuously improve your understanding of end-user needs throughout the product development process”. By doing so, end-users better articulate and refine their needs throughout the development process, while the system requirements are updated to reflect the newly discovered needs [1]. For the sake of a detailed anecdote that illustrates continuous validation:

If you hired an architect and builder to create your dream home, would you

be content with seeing the house for the first time only after the construction is

over? Or would you prefer that the architect and builder check in with you

periodically to validate their assumptions and make sure the project is on track to

meet (or exceed) your expectations? People aren’t always good at imagining the

end product based on requirements. For instance, is a 110 square foot kitchen big

enough to comfortably prepare a meal for six people? Who knows until you can

walk around in it or at least see it mocked up in a drawing or model. While you

may wish that you could get to a stable, “frozen” set of requirements, that is

unrealistic. And if customers’ requirements get refined or even changed, wouldn’t

you prefer to know as early as possible, rather than at the end? Continuous

validation enables you to compress time to end-user feedback, which means that

you find out early on if there’s a gap between the latest end-user needs and the

current set of requirements [1].

Closing the loop with the end-user or stakeholders as much as possible, leads to the avoidance of defects and reduction in business risk. The V model, previously presented,

13

“applies to waterfall development process just as it applies to iterative processes and even to Agile development around the bottom of the V. But the truth is that in reality, product development goes through many Vs”, as illustrated in Figure 6 [1].

Figure 6: The Common Process Validation Leading to Integration Wars [1]

By applying continuous engineering practices, the interaction with the stake holders and/or end-user becomes much more frequent, as illustrated in Figure 7 [1].

Figure 7: Continuous Validation with the Customer in the Loop [1]

14

1.1.2 Model-Based Systems Engineering

Motivation

“Standard development lifecycles are often described in a document centric fashion

(e.g. ISO 26262 defines a V-Model with Work Products after each Lifecycle step to be verified)”. Each department describes requirements in a document through the document centric approach, usually in a document type out of the Microsoft Office Family, which seems easy to implement initially. Although there is very little training that needed with standard office tools that are widely available, many failures can be made here, and document maintainability may become very error-prone” [2].

Worst case scenario, critical documents are saved on a server without any version control or configuration/change management. As documents are simply forwarded to

various engineering departments for implementation, this simple hand-over without any structured approval process is not ideal for traceability. “Links and references to additional related documents may be deeply nested within documents, not updated, and hard to follow. In such a scenario traceability would be hard to implement and maintain” [2].

Further, in document centric development process that lacks appropriate supporting tools, maintenance and verification/validation activities have to be done manually. Thus, given the complexity of today’s products, this becomes infeasible, “Therefore companies may fail to prove compliance to ISO 26262 despite best intent” [2].

15

Model centric or Model based development is, “focusing on providing the information within one repository on the basis of a model”. The same steps are followed as seen in the document centric development process. A typical workflow includes:

Requirements are forwarded to the system via written specifications hold in a

requirements engineering and management tool (RME Tool). The RME tool is

interfacing the modelling tool via direct tool interfaces for instance Rhapsody

Doors Gateway. The modelling tool holds the model artefacts and allows the

creation of the model in descriptive languages like SysML or UML. Describing the

systems architecture in a model is guiding and formalizing the analysis task and

providing the requirements for the following engineering activities, i.e. for the

implementation domains like HW and SW [2].

Requirements management (RM) is not being replaced by modeling, it is actually assisting

with understanding the rationale for design decisions. Especially for complex systems, both are much needed for a complete understanding. “RM provides the traceability and contractual basis, Modelling allows multiple views using different diagrams and helping to understand the requirements and assuring consistency thereof by having them linked into the model”. As modeling act as the “glue” between levels of requirements, model tools also help automate verification tasks that are error-prone, such as traceability and consistency check [2]. Lastly, Figure 8 illustrates the roadmap for extending the maturity and capability of MSBE.

16

Figure 8: INCOSE MBSE Roadmap [3]

Requirements Management and Traceability

When requirements management is built on the foundation of a systems engineering paradigm, this “enables organizations to capture and validate software requirements, link them to downstream development and testing activities and to manage their completion through a unified process across the lifecycle”. The activities that are performed within the area of requirements become management-focused, once the requirements become developed and the product begins to take shape [4].

This is what can be referred to as the “living” stage of the product development lifecycle, as new information can surface throughout the development process, requirements and any upstream or downstream artifacts are informed. Thus,

17

“modifications, enhancements, corrections and additions occur during this living period of the product's lifecycle, leading to the generation of a significant amount of information”.

All this information needs to be fulfilled through traceability and management, and approaching these tasks manually leads to increased cost and error. Further, “automation requires that all engineering artifacts and work products are somehow connected - an inherent quality of the systems engineering approach to product development” [4].

For visibility into the engineering process, traceability from the requirements to the engineering artifacts yields key metrics and insights. Any lack of traceability also offers insight into the requirements that are not traced to a model. So when approached from a systems engineering perspective, the overall goal should be to, “seamlessly trace and interactively navigate within a project through various levels of requirements to design features, specifications, assigned tasks, testing and deployment activities, and view activity

in context with associated source code changes - all within in a single system and user interface” This idea of traceability from requirements to engineering artifacts is illustrated in Figure 9 [4].

18

Figure 9: Traceability from Requirements to Engineering Artifacts [4]

Navigation of linked items provide insight to all types of important information including relevance to compliance, impact analysis and reporting. Ultimately by linking the entire system to its related work products, “one can confirm that all requirements have functional specifications and test cases so that they are developed and tested before the product is released or project milestones are reached”. In addition, standards related to compliance, need/want assurance that requirements in implementation are connected from the engineering process, and vise-versa, “that each model element is there for a reason and

19

that reason is identified by the traced requirements”. For instance, when test cases and acceptance criteria from software artifacts are tied to their source system models and requirements, “predicting possible risks can be simplified, allowing for more informed changes to work products and informing artifacts, and better risk assessment” [4]. Figure

10 illustrates the idea of tracing elements of different artifacts.

Figure 10: Traceability Between Elements of Different Artifacts [5]

Architecture and Design Management

So, as system engineering approach assist with the workflow of information exchange, tracking changes to collaborative artifacts, and propagating modifications to related requirements and work products, “Models and other graphical elements which are generally the output of a systems engineering approach can dramatically improve this

20

communication and shorten the negotiation and understanding process”. Further, through mapping the need of existing components and architectures, leads to increased used from an implementation process, while enabling reuse from a collaboration perspective. For instance, when “requirements for existing components and architectural elements have already been identified, articulated and agreed upon by all parties and the product already delivered and hence can be visualized more readily, thereby allowing focus to be placed on the differences or new needs looking to be fulfilled” [4]. Figure 11 highlights this system modeling and identification of common elements.

Figure 11: Systems Modeling and Common Elements [4]

As stated previously, “a systems engineering approach also enables more specific articulation of the interfaces between elements or the layers of the system itself”. Thus, a system model or diagram can be utilized to define direct system inputs and outputs, communication layers, and operational constraints. When these details are leveraged early in the requirements development process, “the final product goals surface earlier, further

21

informing other downstream activities and arriving at a more complete starting set of requirements through techniques stemming from a systems engineering approach” [4].

Requirements Coverage and Fulfillment

A critical aspect of management, is visibility into the development process for effective planning and quality control throughout product development. Thus, the state of product release and readiness needs to reviewed frequently by management teams [4].

Figure 12: Requirements Coverage and Fulfillment [4]

Key to the determination of project completion and fulfillment as it aligns with product goals, are readiness indicators such as the degree of requirements coverage and consistency. For instance, “a project that encompasses hundreds of live requirements that may be subject to modifications and edits presents a complicated management task. By connecting requirements to work products and engineering artifacts as they are created,

22

developed and subsequently modified, one can utilize metrics and reports to identify the extent of completion of a product based on how many requirements have been met; how many are in progress; and how many requirements are not associated with an existing or completed work product”. As a results, informed decisions based on release readiness can be made by management. Requirements management becomes of increased importance as the complexity of a product increases. Thus, “a systems engineering approach to managing these requirements ensures that valuable information tying critical product elements – from requirements to informing artifacts and work products - is tracked, managed and accounted for”. So while considering the entire system and its related goals, this can yield the following benefits [4]:

. “Assurance of consistency from stated requirements to upstream and downstream

artifacts” [4]

. “Management visibility of progress at critical parts of the development cycle” [4]

. “Compliance validation at selected points in the process” [4]

. “Design reconciliation at an early stage of product development” [4]

1.1.3 System Safety Alignment

The Model Based Design approach also serves as an enabler for an iterative safety analysis method, as requirements change constantly because of refinement or systems parameter updates to adapt to meet other system interfaces. “As a rule of thumb, two percent of the sum of all requirements changes per month. Therefore a single requirements analysis phase in a standard V-cycle or waterfall model is not strictly applicable” [2].

23

Figure 13: Main Tools for MBSE [2]

Further, faster and more efficient adaption of requirements or designs are enabled by the Model Based approach. As requirements are changed, the impact to the design of safety concept is analyzed easier given a model based design. Given that the requirements are linked to specific model elements, the requirements are changed, the links become

“suspect”, and the supporting tool assist with showing the propagation of the change into the design. Additionally, “information about modifications is also forwarded into the safety analysis tool, as this is based on the modelled artefacts which have changed by the initial requirements change.” Thus, with the main supporting tools for MBSE as seen in

24

Figure 13, the analyst can identify various changes and judge if there is an impacting the safety case or not [2].

The main purpose of safety analyses is to prove that the system is safe with respect to random occurrences of hardware failures. According to ISO 26262, “this means the probability of the violation of the safety goals is below an ASIL specific target value and evidence is given for an appropriate ASIL specific limitation of the hazards caused by single- and dual point faults”. Therefore, the initial step of the safety analysis is to populate the architecture model with failure information. Secondly, the analysis models are manually or automatically derive from the enhanced model containing failure information.

Finally, “the analysis activities are performed and depending on the outcome new requirements are specified. As the safety analyses are ASIL and safety goal specific traces between the safety goals and the different analyses assist in establishing the final safety

case” [6].

Figure 14 illustrates what this approach may look like as it relates to safety analysis.

This approach has been practically implemented with available tools in order to pilot functional safety focused engineering projects. In particular, with commercially available tools including IBM Rational Rhapsody and Medini, architecture and design models were developed and used for functional safety analysis tasks. [6].

25

Figure 14: Systems Models and Functional Safety Analysis [6]

Further, once safety related information is imported into a model, such as “failure modes and failure rates of parts and blocks have been added, safety analysis activities like

FTA”, applications such as hardware diagnostic coverage metrics etc. can then be executed.

As a result, “traceability to safety requirements and safety goals is established through an allocation of functional or technical safety requirements to elements of the architecture model” [6].

26

1.1.4 State of the Art Methodologies

Presented will be an overview of a few of the more notable MBSE methodologies that have, “have received attention in the various industry forums and publications and are intended to serve as candidates for adoption and tailoring to an organization’s SE practices and procedures”. Each methodology is briefly described along with a highlight of available tools that support each approach [7].

JPL State Analysis

A JPL-developed MBSE methodology that “leverages a model- and state-based control architecture” is State Analysis (SA), Figure 15 illustrates this method. State is defined to be “a representation of the momentary condition of an evolving system,” and models describe how a state evolves. Further, “SA provides a process for capturing system

and software requirements in the form of explicit models, thereby helping reduce the gap between the requirements on software specified by systems engineers and the implementation of these requirements by software engineers”. Traditionally, the translation of requirements to system behavior was done manually by software engineers with the hope that the understanding of the system behavior was accurately captured. In SA, model- based requirements are mapped directly to software artifacts [7].

27

Figure 15: Model- and State-Based Control Architecture ("Control Diamond") [7]

The SA methodology defines, “an iterative process for state discovery and modeling, which allows the models to evolve as appropriate across the project lifecycle.

(A tool known as the State Database compiles information that is traditionally documented in a variety of systems engineering artifacts.)” Additionally, various mechanisms are specified based on how the models are used to design software and operations artifacts. In summary, SA provides a rigorous approach for the following three primary activities [7]:

. “State-based behavioral modeling. Modeling behavior in terms of system state

variables and the relationships between them” [7].

28

. “State-based software design. Describing the methods by which objectives will be

achieved” [7] .

. “Goal-directed operations engineering. Capturing mission objectives in detailed

scenarios motivated by operator intent” [7].

Figure 16 presents the results of an iterative decomposition process that stems from a traditional functional analysis & decomposition approach, which that ultimately results in,

“a hierarchy of functions, physical components (product breakdown structure) and requirements and the linkages between the functional, physical, and requirements hierarchies” [7].

Figure 16: Conceptual Layout of Requirements, Functions, and Components. [7]

State Database, which “utilizes a Structured Query Language (SQL)-compliant relational database management system (RDBMS) such as Oracle® with a front end user interface”, provides tool support for State Analysis. This tool supports the development, 29

management, inspection, and validation of system and software requirements that are captured throughout the SA process. To support system safety development techniques, including hazard analysis, “commercial tools such as Specifications Tool and

Requirements Methodology (SpecTRM) and the formal requirements language used in that tool, SpecTRM-RL, as well as SpecTRM-GSC (Generic Spacecraft Component) are available from Safeware Engineering” [7] .

Vitech Model-Based System Engineering Methodology

Vitech Corporation, the providers of the CORE® product suite, offer “a MBSE methodology via a set of tutorials developed and offered by Vitech CEO and Chief

Methodologist James (“Jim”) E. Long”. In fact, variations of the tutorial have been delivered at a numerous INCOSE International Symposia. Illustrated in Figure 17 is the

Vitech MBSE methodology which is based on, “four primary concurrent SE activities that are linked and maintained through a common System Design Repository” [7].

30

Figure 17: Vitech MBSE Primary SE Activities [7]

Each of the primary Systems Engineering (SE) activities are linked within the appropriate context as they associated with the specific domains illustrated in Figure 18. In particular, the SE activities are considered, “elements of a particular kind of domain known as the Process Domain. In the Vitech MBSE methodology, it is stressed that a MBSE

System Definition Language (SDL) is needed to manage model artifacts, which means that an agreed-upon information model in the form of a schema or ontology is necessary to manage the syntax (structure) and semantics (meaning) of the model artifacts”. Thus, an

“SDL” a numerous uses including “struced” or common context-free language for technical communication, which can serve as a, “guide for requirements analysts, system

31

designers, and developers, and providing a structure for the graphic view generators, report generator scripts, and consistency checkers” [7].

Figure 18: Vitech MSBE Primary SE Domains [7]

Although the Vitech MSBE approach is considered to be tool-independent, there are strong ties to the CORE tool set, “There is no process framework tool offered by Vitech

Corporation or third party provider that supports the Vitech MBSE methodology. Vitech does offer an MBSE tool set via its CORE® product suite” [7].

32

IBM Harmony-SE

“Harmony-SE is a subset of a larger integrated systems and software development process known as Harmony®. Development of Harmony-SE and Harmony® originated at

ILogix, Inc., formerly a leading provider of modeling tools for the embedded market.”

Figure 19 illustrates the Harmony integrated systems and software development process as it mirrors the classic “V” process [7].

Figure 19: Harmony Integrated Systems and Software Development Process [7]

Although components of the Harmony process are supported by the Telelogic

Rhapsody “model-driven development environment”, this method is designed to be tool and vendor neutral. As the Harmony process somewhat mirrors the classic “V” development process, it assumes model and requirement artifacts are managed/maintained 33

in a centralized repository. The systems engineering component of the Harmony process show in the upper left corner of Figure 19, known as Harmony-SE has the following stated key objectives [7]:

. “Identify / derive required system functionality” [7].

. “Identify associated system states and modes” [7].

. “Allocate system functionality / modes to a physical architecture” [7].

Harmony-SE uses a “service request-driven” modeling approach along with, “Object

Management Group™ Systems Modeling Language™ (OMG SysML™) artifacts. In the service request-driven modeling approach, system structure is described by means of

SysML structure diagrams using blocks as basic structure elements”. In the Harmony-SE process, artifacts (work products) and task flow include the following three top-level process elements [7]:

. Requirements analysis [7]

. System functional analysis [7]

. Architectural design [7]

Illustrated in Figure 20 are the process elements including the flow of some of the primary work products [7].

34

Figure 20: Harmony-SE Process Elements [7]

Although the Harmony-SE and Harmony MBSE methods were created as tool

independent, tool support for these methods are of course provided by IBM, specifically

IBM Telelogic via the Telelogic Tau and Telelogic Rhapsody product offerings [7].

35

Chapter 3: Model-Based Systems Engineering Approach

1.1 Implemented Approach

After much consideration and review of the state of the art approaches for practically implementing MBSE, it became clear that the Ohio State team would move forward with the Harmony Integrated Systems and Software Development Process with

IBM supporting tools. Although no case studies or pilots exist that capture the full integration of the chosen IBM process and tools for automotive development, the Ohio

State EcoCAR team is confident in IBM’s capabilities given the case studies that do exist, and the developed relationship between the Ohio State EcoCAR team and IBM. Figure 21 details the high-level “V” process in which the Ohio State team is implementing for MSBE, the IBM Rational Integrated Systems/Embedded Software Development Process. The systems engineering requirements generation process is highlighted, as well as the software development and implementation process as it aligns with the traditional “V” diagram.

36

Figure 21: Rational Integrated Systems/Embedded Software Development Process [8]

Illustrated in Figure 22, the Rational Solution for Systems and Software

Engineering, breaks down IBM’s approach to MBSE into four major components including

Requirements Engineering, Architecture and Design, Quality Management, and

Collaboration Planning and Workflow Change Management. Given time constraints of the

EcoCAR 3 competition, the Ohio State team will focus on implementing three of these components and will not include Collaboration Planning and Workflow Change

Management. The motivation for implementing each component includes:

. Requirements Engineering: Making requirements the “heartbeat” of the

project to “facilitate visibility and collaboration on requirements across the

entire development organization” [9]. 37

. Architecture & Design: Reducing risk early with model-based systems

development. Combining requirements, models and designs for an iterative

approach to systems engineering and software development that enables

continuous validation and verification. Thus, system specifications are derived

from generated requirements and source code can be generated directly from

the developed models [9].

. Quality Management: Helps the management of risk in complex system

development by linking verification activities directly to requirements. These

activities include test management, status for requirements coverage and

fulfillment, and prioritizing verification activities to manage risk [9].

Figure 22: Rational Solution for Systems and Software Engineering [9]

38

1.2 Supporting Tools Implemented

The supporting tools deployed to support Ohio State’s implemented MSBE approach includes a suite of IBM’s Rational tools that directly align with the Rational

Solution for Systems and Software Engineering presented in Figure 22. Also implemented are MathWorks and dSPACE Model-Based Design (MBD) tools for software development activities, as they are traditionally utilized by Ohio State’s team and they have the ability to integrate with IBM’s tools.

IBM Rational Suite

Figure 23: IBM Rational Supporting Tools

Illustrated in Figure 23 is the suite of IBM supporting tools deployed for increased documentation, traceability and workflow management as the Ohio State team implements a MSBE approach for systems engineering. These tools include IBM Rational DOORS to

39

support requirements management and traceability, Quality Manager for managing V&V test activities for requirements coverage and fulfillment, and Rhapsody for architecture and design management. Motivations for each tool includes:

. Requirements Management and Traceability:

IBM Rational DOORS® – “A world leading requirements management system that

contains proven capabilities to help increase quality and efficiency by optimizing

requirements communication and collaboration”. Web-based tool with key

capabilities including the ability to import existing requirement documents from

formats including word and excel, and integration capabilities with MathWorks and

MBD tools for traceability [9].

. Architecture and Design Management:

IBM Rational Rhapsody® – “A visual analysis and development solution for both

systems engineering and embedded software development that helps to graphically

abstract and simulate complex designs to aid in improving productivity and

reducing costs and risk.” Also supports system safety development activities

including FTA/DMFEA, and integration of MathWorks models [9].

. Requirements Coverage and Fulfillment:

IBM Rational Quality Manager – “A robust solution which provides testing teams

with the means to track and manage the whole quality life cycle. IBM Rational

Quality Manager is a web-based test management environment for quality

professionals who seek a collaborative and customizable solution for test planning,

workflow control, tracking, and metrics reporting, designed to help unite teams by

40

seamlessly sharing test information, accelerating project schedules and making

informed release decisions” [9].

MathWorks and dSPACE

Additionally, for software development activities the Ohio State team is using

MathWorks and dSPACE tools as part of the teams’ common practices with the model- based design development process. Figure 24 highlights the tools for SW development and how they fit into the “V” process.

Figure 24: MathWorks and dSPACE Model-Based Design Tools for SW Dev.

1.3 Alignment with System Safety Development

Effective development of system safety for the Ohio State’s EcoCAR 3 can be broken down into two high-level activities, which include system safety analysis and system safety design and implementation. As these activities will be further detailed in the

41

upcoming chapters, this section briefly introduces how the capabilities of the implemented

MSBE approach support and align with system safety development.

System Safety Analysis

As system safety analysis is conducted to understand how system faults lead to hazards and how they can be addressed, a model-centric approach to analyzing the system can aid the development of safety systems. In particular, IBM Rational Rhapsody (which is one of the tools that the Ohio State team is implementing to support the MSBE approach) is a UML based tool with capabilities of supporting this effort, “UML is a modeling language that is commonly applied to both software and systems development. It provides a semantic basis of fundamental concepts and views (diagrams) that depicts the interaction of elements of interest. UML can aid the development of safety critical systems in a number

of ways” [10]:

. “By providing design clarity” [10]

. “By modeling architectural redundancy” [10]

. “By modeling low-level redundancy” [10]

. “By creating safety-relevant views of the requirements and design” [10]

. “By aiding in safety analysis” [10]

Specifically, IBM Rational Rhapsody supports a number of analysis techniques including Fault Tree Analysis (FTA), “an analytic approach discussed later in the paper, is a common technique for analyzing how faults lead to hazards and how to add safety measures to address these concerns”. Figure 25 illustrates an example of an FTA model in

42

Rhapsody while highlighting traceability capabilities to requirements. Also, matrix and tabular views are available for summaries of results from analyses [10].

Figure 25: Example of FTA Linked to Requirements [10]

While there are many FTA tools available, the advantages are that, “the requirements, design model and safety analysis are all co-located and all interconnected.

This allows developers to reliably navigate between these three kinds of views with ease”.

43

Additional capabilities are summarized in Table 2, including key metadata from hazard analysis activities [10].

Table 2: Tables and Matrix Summary Views [10]

Table or Matrix Format Description Fault Table Rhapsody Table View This lists the faults and all their metadata Hazard Table Rhapsody Table View This lists the hazards and all their metadata Fault Source Matrix Rhapsody Matrix View This shows a fault x fault source matrix, as defined by the Manifests relations Fault Detection Matrix Rhapsody Matrix View This shows a fault x safety measure matrix, as defined by the Detects relations Fault Extenuation Matrix Rhapsody Matrix View This shows a fault x safety measure matrix, as defined by

the Extenuates relations Hazard Analysis Tab-separated value This is an external file text file (. tsv) intended generated by the profile helper to load into Excel macros summarizing the hazard and fault information.

System Safety Design and Implementation

As illustrated in Figure 24, Ohio State’s SW development is following a model- based design approach which enables seamless design and implementation of system safety software. In particular, with a model centric approach to design, using MathWorks and dSPACE tools, models are used to auto-generate code for implementation onto controller hardware, i.e. rapid-prototyping.

44

1.4 Deployment Strategy

Given the overall competition development timeline, and specifically system safety deliverables, there needed to be a deployment strategy for effectively implementing the selected MSBE approach and respective supporting tools. Figure 26 illustrates a deployment timeline for integrating each major MSBE component as they align with the overall competition development timeline and major system safety activities.

Figure 26: Deployment Timeline for Integration of MSBE Approach

In particular, the development timeline is four years long consisting of the following major activities during each year:

. Year One: Main focus is design, including vehicle architecture selection and initial

component testing and system modeling and simulation.

. Year Two: Main focus is full vehicle integration, and rigorous testing of major

components, as well as controls development for initial deployment.

. Year Three: Main focus is development, full vehicle testing and refinement as it

relates to component integration and controls development.

45

. Year Four: Main focus is vehicle optimization and finalizing verification and

validation activities to achieve 100% build.

Further, as defined by the EcoCAR 3 competition and driven by major deliverables, system safety activities fits into the overall development timeline as follow:

. Year One: The system safety component of EcoCAR was not deployed until year

two, thus there were no deliverables during year one.

. Year Two: Main focus is initial safety requirements generation through hazard and

fault analysis for initial system safety concept, defining safety requirements, and

generation of preliminary V&V plans.

. Year Three: Main focus is system safety design and implementation, including

system and component level DFMEA/FTA activities and updates to V&V plans.

. Year Four: Main focus is safety verification and validation through exhaustive

testing and reviews.

Lastly, the deployment of each phase and supporting tool of the MBSE process will be as follows to be in line with expectations and requirements of the EcoCAR 3 competition:

. Year One: Main focus was the review and selection process for an MBSE method

and supporting tools, including brief pilots of potential methods and tools.

. Year Two: Main focus was to commit to a MBSE approach and supporting tools,

including the full deployment of the requirements management tool IBM Rational

DOORS and initial deployment of Test Management Tool IBM Quality Manager.

Year two also included the initial deployment of IBM Rational Rhapsody.

46

. Year Three: Main focus will be the full deployment of IBM Rational Rhapsody

and final integration of IBM Quality Manager.

. Year Four: Main focus will be assessing the overall MBSE method as it is fully

integrated, and identifying areas for workflow improvement

47

Chapter 4: System Safety Analysis

1.1 Introduction

According to the EcoCAR 3 competition, system safety development is described as a “disciplined and comprehensive engineering effort to identify safety related risks to be either eliminated or controlled”. This includes a number of tasks which were briefly highlighted in Chapter 3 and will be further detailed in this chapter. In particular, as the

EcoCAR 3 is currently in transition to year three of the competition, this chapter will highlight system safety activities that have been done during year two of the competition.

Overall, this will include preliminary hazard analysis and system safety concept, and requirements generation and management activities conducted by the Ohio State team.

1.2 Preliminary Hazard Analysis and Safety Concept

Conducting a preliminary hazard analysis and developing an initial safety concept for iterative refinements begins with defining the functional control system that fully describes the system being analyzed and developing processes for key activities including vehicle hazard identification and classification, and diagnostic and mitigation strategies.

48

Functional Control System

Illustrated in Figure 27 is the high level block diagram of the functional control system which lays out the major components of Ohio State’s EcoCAR 3 vehicle. Also highlighted are the primary functions of each component and the key information being transmitted between components. In brief, the system contains a number of controllers which communicate through CAN (Controller Area Network) to send out commands to their respective components based on driver demand and feedback from the overall state of the vehicle including individual components (i.e. battery state of charge, vehicle speed, etc.). Lower level diagrams and interactions are included in the appendix.

Figure 27: High Level Block Diagram of Functional Control System

49

Vehicle Hazard Identification and Classification

Figure 28 presents the process implemented for identifying and classifying system hazards. For hazard identification the Ohio State adapts a General Motors (GM) process referred to as System Element Hazard Analysis (SEHA). Through this process potential hazards and operating sceneries are first assessed based on literature and expert opinions, then each system element in the vehicle is failed independently to determine the resulting effect on the overall system. As a result, the potential safety hazard is identified and further defined.

Figure 28: Hazard Identification and Classification Process

Further, hazard classification is done through the standard Automotive Safety

Integrity Level (ASIL) methodology. This process as highlighted in Figure 28 includes 50

evaluating the risk level of the identified hazard based on literature and expert opinion, it then includes determining the severity exposure and controllability of the hazard to determine and assign and overall ASIL rating of A through D. Lastly the hazards are given high, medium, or low classification. Figure 29 presents a brief example of hazards identified through the SEHA methodology. A snapshot of the working documentation for hazard identification and classification can be seen in the appendix.

Figure 29: Hazard Identification Example

51

System Safety Concept

As defined by the EcoCAR 3 competition, the system safety concept is the diagnostic and mitigation strategy developed for either eliminating or controlling safety related risks. The process for developing the system safety concept is presented in Figure

30. Simply, when a fault is present, the effected systems and associated hazards are assessed to determine whether effective diagnostics and mitigation strategies already exist to address the situation, and if they do its noted, otherwise strategies are developed through referencing of literature and expert opinion.

Figure 30: Process for Developing Diagnostic and Mitigation Strategies

Figure 31 presents an example of developed diagnostic and mitigation strategies based on the identified hazards presented in Figure 29. This includes the identified systems that will be available and capable of diagnosing and mitigating the fault, the immediate action taken for mitigation, and the final vehicle state. A snapshot of the working documentation for diagnostic and mitigation strategy development is in the appendix. 52

Figure 31: Examples of Developed Diagnostic and Mitigation Strategies

Identification of Additional Safety Systems

As a result of the system safety analysis activities, and number of safety systems were identified to assist with eliminating and controlling identified safety risk with Ohio

State’s EcoCAR 3 vehicle. These safety systems are summarized in Table 3, and included the hazard being addressed, the needed safety system and the current status of implemented the system. The major systems needed are related to software development torque security risk related to unintended vehicle acceleration.

53

Table 3: Summary of Additional Safety Systems Identified

HAZARD Safety Systems Status

Unintended Redundant PRNDL sensors, detection/mitigation Implemented Direction SW Unintended Acc. pedal detection/mitigation SW Refine Acceleration/ Torque security detection/mitigation SW Refine Deceleration Force park mitigation SW Refine Driveline/torque coupling device speed sensors Needed Regen braking detection/mitigation SW Needed Shock/HV Industry standard conduit/insulating materials Implemented Exposure Ground fault detection/mitigation Implemented

Charging/driving diagnostics/mitigation SW Implemented

Unintended Shields, thermal wrap Implemented Thermal Energy Coolant temperature and flow sensors, Needed diagnostic/mitigation SW Access to Rotating Shields, i.e. BAS coupling to engine Implemented

Components

Future Activities

As preliminary safety analysis activities for EcoCAR 3 year two are completed, system safety development is well positioned for EcoCAR 3 year three. As mentioned in the deployment strategy timeline in Chapter 3, primary system safety analysis deliverables for year three include DMFEA and FTA, and to support this effort IBM Rational Rhapsody is aligned to be deployed as part of the suite of supporting tools for MBSE. Thus, future supporting activities include translating the functional control system diagrams into rhapsody models for centralized documentation, increased traceability and management.

54

1.3 Requirements Generation and Management

EcoCAR 3 year two requirements generation activities included hazard metrics translation in which vehicle level hazard metrics are translated to system specific metrics.

Another activity included requirements decomposition and allocation to specific software and hardware systems/components. Additionally, preliminary V&V plans were generated and an initial documentation workflow was defined which included integration of IBM

Rational DOORS and Quality Manager for effective management of requirements.

Hazard Metrics Translation

Outlined in Figure 32 is the hazard metrics translation process that is followed by the Ohio State team. The process includes first defining the vehicle level hazard metrics from primarily the vehicle level hazard analysis and sources including competition rules,

product data sheets, literature, and expert opinion. Once the vehicle level hazard metric is defined, systems that contribute or have an effect on the hazard metric are identified.

Lastly, the systems are analyzed through testing, basic calculation, or simulations to translate the vehicle level hazard metric to a system specific engineering requirements.

55

Figure 32: Hazard Metrics Translation Process

Figure 33 illustrates a hazard metric translation example based on basic calculations with key vehicle parameters. The excel sheet translation snapshot shows the working documentation of how vehicle level hazard metrics are translated into system specific engineering requirements. This example highlights an unintended acceleration metric that cannot be violated, and shows the translated metrics specific to torque producing components that must not be violated in order to abide by the vehicle level metric. Also noted is the EcoSIM Vehicle Simulator, which in this context supports the efforts of hazard metric translation by enabling scenarios to be simulated for capturing predicted system specific behavior. Thus, based on vehicle level outputs/metrics, system specific outputs/metrics can be captured.

56

Figure 33: Hazard Metrics Translation Example

Requirements Decomposition and Allocation

Outlined in Figure 34 is the process for defining safety requirements, thus decomposing and allocating system level safety requirements to specific hardware (HW) and software (SW). This process begins with a system level safety requirement (derived from sources including the system safety strategy, hazard metric translation activities, etc.), then HW and SW that contribute to meeting that requirement are identified, and lastly the requirement is decomposed and allocated to the contributed HW and SW resulting in

HW/SW specific engineering requirements. Figure 35 illustrates an example of the decomposition and allocation of a system level requirement into specific SW and HW components.

57

Figure 34: Process for Defining Safety Requirements

Figure 35: Example for defining safety requirements

58

Development of Preliminary V&V Plans

Figure 36: Process for Developing Preliminary V&V Plans

The development process for preliminary V&V plans are outlined in Figure 36, which first include developing a template in IBM Quality Manager, and then defining test scenarios for major systems based on expert opinions and literature, and lastly given the system and test scenario specific requirements are allocated resulting in a preliminary V&V test case/plan.

59

Figure 37: Highlight of IBM Quality Manager for V&V Plans

Figure 37 highlights a snapshot of a preliminary V&V plan developed in IBM

Quality Manager. It highlights to the structure of the plan on the left of the diagram, and on the right of the diagram is shows that the plan was derived from a template. In the center of the diagram gives a brief description of the test case and highlights all the requirements that are linked from IBM DOORS.

60

Documentation Workflow

Figure 38: Initial Documentation Workflow

Based on EcoCAR 3 year two deliverables and all the system safety activities discussed in this chapter, Figure 38 highlights the initial documentation work flow for management as part of the MSBE approach. This includes populating all the excel docs from initial analysis activities into IBM DOORS for traceability to the derived requirements. For further traceability as it relates to requirements coverage and fulfillment, requirements for IBM DOORS are linked to preliminary V&V test cases/plans in IBM

Quality Manager. Optionally, a traceability matrix in excel formatting is exported. Figure

39 presents snapshots of traceability using IBM DOORS. The top images show a default

61

spreadsheet-like view highlight specific requirements with their respective ID and the upstream and downstream links that the requirement is mapped to. Additionally, the bottom of the figure highlights the links explorer in DOORS which is a diagram view for visually see the upstream and downstream mapping of requirements, test cases/plans, and various documents.

Figure 39: Snapshots of IBM DOORS Tool Integration

Future Activities

Future activities include upgrading the documentation workflow to link to the tool integration of IBM Rational Rhapsody in EcoCAR year 3 in support of year 3 system safety activities including FMEA/FTA.

62

Chapter 5: System Safety Design and Implementation

1.1 Introduction

As Chapter 4 focused primarily on system safety analysis for the development of requirements, Chapter 5 transitions into software development for fulfilling the generated system safety requirements. As highlighted previously, the OSU team is using MBD for software/controls development as it aligns with the MBSE approach. In particular, Figure

40 illustrates the controls software development process followed by OSU.

Figure 40: OSU Controls Software Development Process

63

The controls software development process is broken down into two major activities including software design, and implementation and testing which will be model- centric and developed using MathWorks tools. This chapter will focus on these two activities as they align with the year-two goals of EcoCAR and the MBSE approach.

1.2 Software Design

As a re-cap, at the time of this work the OSU team is transitioning into year-three of the competition, in which the main focus will be system safety design and implementation. This section focuses on the initial work completed for system safety software design as it aligns with year-two competition goals, including the high-level software design and specific system safety software functions related to torque security.

High-Level Design

The OSU team is implementing a three-stage functional safety software design to meet robust system safety goals. The design is illustrated in Figure 41 and includes fault detection and diagnostic, fault management, and fault mitigation. Stage 1 is responsible for detecting and diagnosing faults for all team developed software and hardware, while Stage

2 manages all potential faults in the system including faults from procured subsystems with pre-existing fault detection and diagnostic. Lastly, Stage 3 deploys fault mitigation strategies based on the combination of faults detected in the system.

64

STAGE 1 STAGE 2 STAGE 3

Fault Detection & Fault Management Fault Mitigation Diagnostic From SW/HW To SW/HW

To Dash/OBD

Figure 41: High-level Functional Safety Software Design

Given OSU’s functional safety design, testing activities need to ensure that all three stages of the functional safety algorithm are verified and validated in each development environment (MIL/HIL/VIL). To support this effort, model development is focused on two key areas including model fidelity and accuracy. For instance, model fidelity will be increased to ensure that models have sufficient I/O to meet testing needs, while model accuracy will be increased to ensure accurate responses to fault insertion in areas such as the accelerator pedal potentiometer.

Torque Security

Within stage 1 of the functional safety software design is vehicle torque security, which ensures the integrity of driver requested torque. In particular, specific software functions include the following:

. DIRECTIONAL torque flow and ZERO torque flow based on PRNDL position.

65

- When the PRNDL enters drive or reverse, the algorithm verifies and updates

the appropriate rotational DIRECTION for the Traction Motor, and the

appropriate gear for the transmission.

- When the PRNDL enters park or neutral, the algorithm ensures ZERO

torque flow by saturating driver torque request to ZERO.

. Position sensors for PRNDL, accelerator and brake pedals.

- TWO string potentiometers in each device transmits a unique voltage range.

- Verifies that sensors are in the appropriate voltage range

- Verifies that sensor ratios/offsets always agree with one another to

diagnosis if sensors are faulty

Additionally, the OSU team is implementing a robust torque monitoring function to ensure that each torque producing component is effectively delivering the requested torque. This

monitoring function for torque security is illustrated in Figure 42, and highlights the high- level process for evaluating whether or not torque production for each component is faulty.

Continuous Torque Monitoring

Sensor Inputs Theoretical Torque Estimation

Fault Torque Request Torque Producers Torque Feedback Comparison (i.e. BAS, Engine, TM)

Torque Request

Figure 42: Torque Security Monitoring Process

66

Overall, this process is a two prong approach which utilizes an allowable torque range, as well as a torque estimation based off of other sensor inputs. The torque security monitoring function first begins when torque is produced by subsystems in the powertrain.

First, an allowable torque range is generated from the current torque commanded. This allowable torque range is then compared to the feedback torque received by the torque producing component, creating the first torque check in the system. At the same the feedback torque is being checked, an additional sensor is utilized to estimate torque generation. Utilizing a different sensor to provide a check creates a more robust system through redundancies that ensures against faulty readings from any one signal. If any of the torque checks fail, the torque producing components of the vehicle will immediately halt torque production. Table 4 details the torque estimation methods for the torque transmitting devices in the vehicle.

67

Table 4: Torque Estimation Methods for Transmitting Devices

Torque Transmitting Estimator Options Devices Engine  OSU derived estimator based on air per cylinder, RPM, and coolant temperature Belted Starter  Torque prediction based on phase currents A, B, Alternator and C (3 estimates) and speed (BAS and engine) (8 estimates possible)  Torque prediction based on DC current and speed (BAS and engine) Traction Motor . Torque prediction based on phase currents A, B, (12 estimates possible) and C (3 estimates) and speed (BAS, Transmission output, and rear wheel speeds) . Torque prediction based on DC current and speed (BAS, Transmission output, and rear wheel speeds) Total Wheel Torque . Estimate of wheel torque based on measured grade, velocity, and estimated vehicle mass*

*Vehicle mass requires a state estimator to be designed; it will utilize the baseline mass of the vehicle and estimate cargo capacity based on nominal reported torque. Torque Coupling For each torque coupling device, our system includes speed Devices sensors that allow assessing the status of the coupler (i.e. gear ratio, slip ratio, or broken shaft.)

For example, as part of the torque-monitoring function, Figure 43 illustrates a torque comparison for the engine. The upper and lower torque limits illustrate the 10% torque tolerance determined from the requested torque signal, while estimated torque illustrates the predicted torque of the engine based on the method detailed in Table 4, and feedback torque simply illustrates the reported torque from the engine ECU. Both torques, feedback and estimated, lie within the requested torque tolerance; thus no faults are triggered for the given time interval.

68

Figure 43: Comparison of Feedback Torque, Estimated Torque, and Allowable Range

Alignment with MBSE Approach

These software designs are being developed using MBD, thus there is direct alignment with MBSE as MBD is a model-centric approach for software design.

Additionally, for requirements traceability, Rational DOORS integrates with MathWorks tools for tracing requirements to specific model/SW components. Figure 44 illustrates an example snapshot of this capability.

69

Figure 44: DOORS Integration for Requirements Traceability

Future Activities

Given system safety analysis activities presented in Chapter 4, future software design activities for system safety as it relates to torque security, includes diagnostic and mitigation software for regenerative braking.

1.3 Implementation and Testing

Following from the previous section of software design for system safety as it to torque security, this section focuses on the high-level development strategy for system safety software implementation and testing, and highlights results from initial xIL (MIL,

HIL, VIL) development for torque security.

70

High-Level Development Strategy

As part of the MBSE approach that OSU is implementing, implementation and testing for verification and validation (V&V) of software fits within the latter phase of the

MBSE framework. Figure 45 illustrates the V-Process with an emphasis on V&V, while highlighting the structure and tools implemented for managing this development process.

Figure 45: V-Process with Verification and Validation Emphasis

The development process in Figure 45 highlights the generation of requirements, which are covered by the test plan/case generation, followed by the execution of test plans/cases to validate the system design (i.e. supervisory control algorithm) against the generated requirements. Lastly, there is traceability of reported results from test plan/case execution for requirements and/or system design refinement. 71

In addition, the team structure for this process isolates requirement/test developers, system developers, and testers. This enables a more robust validation because of separation of duties between these roles. The key tools implemented throughout this process are IBM

Rational DOORS for requirements management, and IBM Rational Quality Manager for test plan/case generation, execution, and reporting. OSU leverages these two tools together for a seamless synergy between requirements traceability, test plan/case coverage, and reporting.

More specifically as it relates to software development, the OSU team follows an xIL process as part of MBD V&V. Figure 46 details each testing phase of the process including model in the loop (MIL), hardware in the loop (HIL), and vehicle in the loop

(VIL). These three phases essentially go from desktop to vehicle testing platforms in which the software code is verified and validated to ensure it fulfills requirements.

72

Figure 46: Controls Software Development Process

Development of Torque Security

A few examples will now be presented that illustrates results from the development of torque security as part of EcoCAR year-two. Firstly, to illustrate how the OSU team ensures the directional torque security for the traction motor, Figure 47 is presented along with the following requirements that are being met for the given scenario:

. REQID 1105: The HSC shall disable EM inverter, change Rotation Direction

Parameter to 1 and re-enable EM inverter when the PRND goes into Reverse

. REQID 1106: The HSC shall disable EM inverter, change Rotation Direction

Parameter to 0 and re-enable EM inverter when the PRND goes from Reverse to

Drive.

73

Figure 47: Example of Directional Torque Flow in EV Only Mode

Additionally, an example for propulsive torque diagnostics is presented in Figure

48, while Figure 49 and Figure 50 illustrate the statistics used when comparing test data to determine the fault tolerance when comparing signals. In particular:

. For example, when comparing EM inverter torque command against HSC torque

request, they must be within 10% of each other, otherwise a fault is triggered.

. When comparing EM Inverter torque estimate against EM Inverter torque

command, they must be within 10% during a transient state and 10% during steady

state, otherwise a fault is triggered.

74

Figure 48: Example of EM Torque Signals

Figure 49: Statistics for Requested Torque versus Commanded Torque

75

Figure 50: Statistics for Commanded Torque versus Torque Feedback

Further, Figure 51 illustrates the fault thresholds when comparing electric machine

signals, and demonstrates that when the EM torque feedback goes beyond the allowable fault thresholds a fault is triggered.

76

Figure 51: Example Testing for Fault Insertion

Once faults are detected, OSU mitigates faults by following a tiered fault mitigation strategy that is presented in Figure 52. In particular:

. Vehicle fault mode is determined based on severity of fault

. Limp home modes allow for safe vehicle operation under certain conditions to

allow driver to get vehicle to a safe location

. Limp home modes include: Limited EV, Engine Only, Series

77

Figure 52: Tiered Fault Mitigation Strategy

To demonstrate this tiered fault mitigation strategy, Figure 53 is presented. The following is what occurs:

1. The vehicle is operating in EV only mode, in which only the electric

machine is being used for propulsion.

2. Then 30% additional torque from the electric machine is detected.

3. As a result, the vehicle transitions into mode 5, which is vehicle engine only

mode, as the engine is available to provide propulsion.

78

Figure 53: Example of Tiered Fault Mitigation Strategy

Alignment with MBSE Approach

The results from the testing activities presented in this section is supported by

Rational Quality Manager, for test case and test plan management to ensure that the requirements developed for each scenario were fulfilled.

79

Chapter 6: Accomplishments and Future Work

1.1 Accomplishments

As EcoCAR 3 transitions into year-three, this work has already contributed to over a dozen awards by increasing overall documentation, traceability and workflow management as part of the overall engineering development process. In particular, this work contributed to the following year-two EcoCAR 3 awards:

. 2nd Place MathWorks

. 1st Place dSPACE

. 1st Place WW HIL Review

. 1st Place Y2 HIL Review

. 1st Place Controls

. 1st Place Functional Safety

1.2 Future Work

A future activities section can be found in previous chapters that align with the information presented. Overall, the next major step as part of the deployed MSBE approach will be to implement Rational Rhapsody in order to support safety analysis activities a part of EcoCAR 3 year-three activities.

80

Bibliography

[1] “Continuous Engineering for Dummies.” [Online]. Available: http://www.scmsolution.com/wp-content/uploads/2016/01/continuous-engineering- for-dummies-ibm-limited-edition.pdf. [Accessed: 07-Jun-2016]. [2] T. Lovric, M. Schneider-Scheyer, and S. Sarkic, “SysML as Backbone for Engineering and Safety - Practical Experience with TRW Braking ECU,” 2014. [3] “MBSE Roadmap,” INCOSE MBSE IW, 2012. [4] C. Perdikoulias and D. Akers, “A Systems Engineering Approach to Requirements Elicitation and Management,” SAE Int. J. Passeng. Cars - Mech. Syst., vol. 5, no. 4, pp. 1285–1293, Sep. 2012. [5] G. Beier, A. Figge, R. Müller, U. Rothenburg, and R. Stark, “Supporting Product Development through Cross-Discipline Dependency-Modeling–Novel Approaches for Traceability-Usage,” Lect. Notes Inf. Theory Vol, vol. 1, no. 1, 2013.

[6] M. Born, O. Kath, E. Holz, and B. Douglass, “Safety Analysis and Design for ISO 26262 - Model Based and Tool Supported,” 2013. [7] J. A. Estefan and others, “Survey of model-based systems engineering (MBSE) methodologies,” Incose MBSE Focus Group, vol. 25, no. 8, 2007. [8] “IBM Model-Based Systems Engineering with Rational Rhapsody and Rational Harmony for Systems Engineering -- Deskbook 3.1.2 - United States,” 15-Feb-2016. [Online]. Available: http://www- 01.ibm.com/support/docview.wss?uid=swg27023356. [Accessed: 09-Jun-2016]. [9] “http://www.sedcconference.org/wp-content/uploads/2013/09/Commercial-The- Rational-Solution-for-Systems-and-Software-Engineering-Greg-Gorman.pdf - Google Search.” [Online]. Available: https://www.google.com/?gws_rd=ssl#q=http:%2F%2Fwww.sedcconference.org%2 Fwp-content%2Fuploads%2F2013%2F09%2FCommercial-The-Rational-Solution- for-Systems-and-Software-Engineering-Greg-Gorman.pdf. [Accessed: 09-Jun- 2016]. [10] BruceDouglass, “Safety Analysis with the UML - Bruce Douglass Blog,” 19:47:19.08. [Online]. Available: https://www.ibm.com/developerworks/community/blogs/BruceDouglass/entry/safet y_analysis_with_the_uml8?lang=en. [Accessed: 09-Jun-2016]. [11] H. Martin, M. Krammer, B. Winkler, and C. Schwarzl, “Model-based Engineering Workflow for Automotive Safety Concepts,” 2015.

81

[12] M. Lu, “Systems Engineering - Directions and Challenges,” 2014. [13] S. Christiaens, J. Ogrzewalla, and S. Pischinger, “Functional Safety for Hybrid and Electric Vehicles,” 2012. [14] J. Zhang and G. Rizzoni, “Functional Safety of Electrified Vehicles Through Model- Based Fault Diagnosis,” IFAC-Pap., vol. 48, no. 15, pp. 454–461, 2015. [15] C. Moure and K. Kersting, “Development and Comparison of Monitoring Functions for Electric Vehicles,” 2013. [16] R. Isermann, “Model-based fault-detection and diagnosis–status and applications,” Annu. Rev. Control, vol. 29, no. 1, pp. 71–85, 2005.

82

Appendix

1.1 Safety Analysis: Diagrams and Snapshots of Working Documentation

Figure 54: CAN Interactions

83

Figure 55: Electrical Interactions

84

Figure 56: Torque Flow Interactions

85

86

Figure 57: Snapshot of Working Documentation for Preliminary Hazard Analysis

87

Figure 58: Snapshot of Working Documentation for Safety Concept