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

ii

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.

iii

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.

iv

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.

v

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

vi

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

vii

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

viii

Bibliography ..................................................................................................................... 81

Appendix ........................................................................................................................... 83

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

ix

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

x

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

xi

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

xii

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

1

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

2

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

3

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

Coupler American Axle Custom Designed and Made

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.

4

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.

5

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].

6

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

7

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].

8

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].

9

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].

10

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].

11

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].

12

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].

13

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,

14

“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]

15

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].

16

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.

17

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,

18

“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].

19

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

20

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

21

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

22

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,

23

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].

24

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

25

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].

26

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].

27

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].

28

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].

29

“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,

30

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].

31

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

32

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].

33

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

34

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].

35

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].

36

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.

37

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].

38

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]

39

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

40

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

41

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

42

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

43

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”.

44

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

text file (. tsv) intended

to load into Excel

This is an external file

generated by the profile helper

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.

45

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.

46

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.

47

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

48

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.

49

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

50

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

51

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

52

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.

53

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.

54

Table 3: Summary of Additional Safety Systems Identified

HAZARD Safety Systems Status

Unintended

Direction

Redundant PRNDL sensors, detection/mitigation

SW

Implemented

Unintended

Acceleration/

Deceleration

Acc. pedal detection/mitigation SW Refine

Torque security detection/mitigation SW Refine

Force park mitigation SW Refine

Driveline/torque coupling device speed sensors Needed

Regen braking detection/mitigation SW Needed

Shock/HV

Exposure

Industry standard conduit/insulating materials Implemented

Ground fault detection/mitigation Implemented

Charging/driving diagnostics/mitigation SW Implemented

Unintended

Thermal Energy

Shields, thermal wrap Implemented

Coolant temperature and flow sensors,

diagnostic/mitigation SW

Needed

Access to Rotating

Components

Shields, i.e. BAS coupling to engine Implemented

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.

55

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.

56

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.

57

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.

58

Figure 34: Process for Defining Safety Requirements

Figure 35: Example for defining safety requirements

59

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.

60

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.

61

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

62

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.

63

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

64

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.

65

Fault Detection & Diagnostic

Fault Management Fault MitigationTo SW/HWFrom SW/HW

STAGE 1 STAGE 2 STAGE 3

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.

66

- 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.

Torque FeedbackTorque Producers (i.e. BAS, Engine, TM)

ComparisonTorque Request

Torque Request

Theoretical Torque Estimation

Sensor Inputs

Fault

Continuous Torque Monitoring

Figure 42: Torque Security Monitoring Process

67

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.

68

Table 4: Torque Estimation Methods for Transmitting Devices

Torque Transmitting

Devices

Estimator Options

Engine OSU derived estimator based on air per cylinder,

RPM, and coolant temperature

Belted Starter

Alternator

(8 estimates possible)

Torque prediction based on phase currents A, B,

and C (3 estimates) and speed (BAS and engine)

Torque prediction based on DC current and speed

(BAS and engine)

Traction Motor

(12 estimates possible)

Torque prediction based on phase currents A, B,

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

Devices

For each torque coupling device, our system includes speed

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.

69

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.

70

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.

71

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.

72

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.

73

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.

74

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.

75

Figure 48: Example of EM Torque Signals

Figure 49: Statistics for Requested Torque versus Commanded Torque

76

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.

77

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

78

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.

79

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.

80

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.

81

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.

82

[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.

83

Appendix

1.1 Safety Analysis: Diagrams and Snapshots of Working Documentation

Figure 54: CAN Interactions

84

Figure 55: Electrical Interactions

85

Figure 56: Torque Flow Interactions

86

Figure 57: Snapshot of Working Documentation for Preliminary Hazard Analysis

87

Figure 58: Snapshot of Working Documentation for Safety Concept