developing safe automotive electric and electronic · pdf filedeveloping safe automotive...

®

IBM Software Group

© 2011 IBM Corporation

Developing Safe Automotive Electric and Electronic (E/E) Systems: Achieving Compliance with ISO 26262

http://www.ibm.com/software/rational



IBM Software Group | Rational software

© 2011 IBM Corporation 2

Agenda

Trends in Automotive Product

Development & Delivery

The importance of “safety”

Introduction to ISO 26262

IBM Rational software platform for

automotive systems

An integrated support ISO 26262

Process and collaboration support

Requirements Engineering

A modelling approach for a safety based

development lifecycle

Quality Management

Summary



Business and Market Drivers Are Leading to Increased Electronic and Embedded (E/E) Software Content

Green

Hybrid Electric

Product Differentiation

Innovation Brand Image

Growing Customer Demands

Comfort Telematics

Competition

Overcapacity Price Wars

Legal Requirements

Safety Environment

Increased usage of electronics and embedded software; Highly sophisticated in-vehicle electric/electronic (E/E) systems

INSTRUMENTED INTERCONNECTED INTELLIGENT



Electric and Electronic (E/E) systems are realizing automotive product innovation .. BUT

µC

ECU

Domain

Vehicle

Software -

Komponente

Software -

Subsystem

Software

IBM Software Group | Rational software IBM Software Group | Rational software

Issues with the complexity of automotive

Electrical and Electronic systems

Typically 50 + ECUs, 8 Buses of 4

different types, Network controllers

Diagram schematics for most vehicles now

resemble small modern aircraft with a

similar amount of code and its inherent

complexity

Embedded systems are being used to

Implement more and more advanced

features

Improve safety (although this adds

complexity and leads to other issues)




Electric and Electronic (E/E) systems are realizing automotive product innovation

µC

ECU

Domain

Vehicle

Software -

Komponente

Software -

Subsystem

Software

IBM Software Group | Rational software IBM Software Group | Rational software

Issues with the complexity of automotive

Electrical and Electronic systems

Typically 50 + ECUs, 8 Buses of 4

different types, Network controllers

Diagram schematics for most vehicles now

resemble small modern aircraft with a

similar amount of code and its inherent

complexity

Embedded systems are being used to

Implement more and more advanced

features

Improve safety (although this adds

complexity and leads to other issues)

How can you ensure that a possible

malfunction will not harm the driver,

occupants or road users?

You‘ll need to take care

about „safety“




What is Safety?

Safety in the context of automotive embedded

systems is about the prevention, detection, and

response to unintended behavior that can lead

to harm for the vehicle occupants and other

road user



What is ISO 26262?

ISO 26262 FDIS („Road vehicles – Functional

safety“) “) is a new upcoming ISO standard for

safety relevant electronic and electric (E/E)

systems in passenger cars up to 3.5 tons.



Drivers for ISO 26262

Numerous cases of recalls and problems with automotive software (just some

examples, many others)

March 2004: Chrysler Pacifica (34,561 vehicles)

Software protocol used to test the vehicle exhaust gas recirculation (EGR) system may

lead to engine stalling under certain circumstances, increasing the risk of a crash.

http://www.car-accident-advice.com/chrysler-pacifica-recalls-030004.html

Apr 2004: GM recalls 12,329 Cadillac SRXs

One-second delay in brake activation “The problem, due to a software anomaly, only

occurs during the first few seconds of driving when the SUV is moving slowly”

http://www.accidentreconstruction.com/news/apr04/040204a.asp

Dec 2004: Hyundai recalls 120,000 Elantras

Airbag software problem detected in Insurance Institute crash tests (driver side airbag

didn’t deploy in crash test)

http://money.cnn.com/2004/12/19/pf/autos/bc.autos.hyundai.recall.reut/index.htm












http://www.accidentreconstruction.com/news/apr04/040204a.asp



Drivers for ISO 26262

German Legislature requires, that safe cars are developed according to

state-of the-art technology

You need a defensible process for creating safe software

Consider adopting documented best practices instead of inventing your own

If everyone else adopts MISRA, IEC 61508 or ISO 26262 and you don’t, you might be

considered negligent (failure to follow “standard practices”)

ISO 26262 currently draft standard (DIS)

Published June 2009

Currently delivery rumours sometime between September and December 2011



Scope of ISO 26262

ISO 26262 (derived from principles in IEC 61508)

Functional Safety for EE Systems in passenger vehicles, i.e. Automotive as

opposed to Trucks and Buses

Covers the management and technical aspects of the complete safety


Takes a risk-based approach for determining risk classes (Automotive Safety

Integrity Levels, ASILs).

Definition of optional, recommended and highly recommended methods for

development activities within system-, hardware and software development

depending on defined ASIL

Design safety into the system from the outset

ISO 26262 covers the complete development lifecycle from Lust to Dust



What this means for Automotive

All Automotive System development for Electronic and Electrical components need to comply to ISO 26262 Consists of 10 parts

Due to the reuse of a large number of existing elements and pre-existing vehicle architectures the

development cycle is seldom a pure top down V-cycle

Means that the safety-lifecycle must be adaptable and flexible

Heavily influenced by the V-model

Made more modular

1 Vocabulary

2 Management of functional safety

10 Guideline on ISO 26262 (informative)

9 ASIL-oriented and safety-oriented analysis

8 Supporting processes

3 Concept

phase

4 Product development

on system level

5 Hardware

development

6 Software

development

7 Production

and

operation

DIS 26262



IBM Rational Software Platform for Automotive Systems provide the means to implement Automotive Best Practices for Functional Safety, complying with ISO 26262

Focusing on collaborative

1. Product Portfolio Management

2. Requirement Engineering

3. Model Driven Systems Development

4. Software Development for Systems

5. Integrated Product Change Management

6. Quality Management

Supporting Automotive Standards such as

EAST-ADL2, RIF, MISRA, CMMI/SPICE, ISO26262 and AUTOSAR

Based on technology

ISO WD 26262

Automotive SPICE©

Foundation for an end-to-end Engineering Lifecycle Management solution



Rational Method Composer Rational Team Concert

Use modeling to validate requirements, architecture and design earlier in the development process – including

Simulink integration, autocode generation and automated test case generation; use in the same way models for

FMEA, FTA

Rational Rhapsody

Manage system requirements with complete traceability

across the product lifecycle

Rational DOORS

Automate quality and test management with an

integrated, lifecycle-based testing process

Rational Quality Manager Rational Test Conductor Rational Test RealTime

Manage collaborative systems lifecycle management across development teams and engineering disciplines with Automotive data model based on AUTOSAR & ISO26262 process template and

compliance

A look to the inside: How IBM Rational Software Platform for Automotive Systems supports ISO 26262




Rational Rhapsody

Rational DOORS







Rational Rhapsody

Rational DOORS



Process and collaboration support



Rational Team Concert is the enabler for controlling process and managing change

Process template for ISO 26262

Helps with project management

Team management

Task allocation

Integrates with practices that give can guidance on the application of ISO 26262

Configuration management and Collaboration platform

Integrates with multiple Rational Tools

Rational Method Composer (RMC) for process management

Rational DOORS for requirements management

Rational Rhapsody for Model Based Systems Engineering

Removes system design errors early in the development process

Has a safety profile to aid in FMEA, FTA and hazard analysis

Developing an Automotive Safety profile specifically for ISO 26262

Rational Quality Manager (RQM) to plan tests

Rational Test Conductor to automate tests

Rational software Process and Collaboration support



Supports all core processes and work products defined in the standard

Process template implemented in Rational Team Concert

Guidance and practices implemented in Rational Method Composer

Process template with work items

Web based ISO 26262 guidelines

and MBSE practices

ISO 26262 RTC and RMC

ISO26262 Standard Rational Team Concert

Rational Method Composer

Guidelines

reference

ISO 26262

ISO26262 Work products Work items,

products and

flows derived

from ISO 26262

Workitems linked to process guidance



RTC ISO 26262 Process and Practice templates

Scope of Process template and guidance covers 95%, phases 2-8*

*Clauses 8.12 Qualification of Software components and 8.14 Proven in use argument, not currently supported



Available practices for ISO 26262 Mainly in the areas of supporting practices and around MBSE, SW and test

Work going on with Embedded HW and SW integration

1 Vocabulary

2 Management of functional safety

10 Guideline on ISO 26262 (informative)

9 ASIL-oriented and safety-oriented analysis

8 Supporting processes

3 Concept

phase

4 Product development

on system level

5 Hardware

development

6 Software

development

7 Production

and operation

FDIS 26262

Practices for

Requirements management

Configuration Management

Change management



ISO 26262 in Rational Method Composer

RMC captures activities and

flows

Flows are generic and reflect

ISO 26262

Can be customised to fit

your process

Activities and flows Reflected

in RTC process template

RTC allows project managers

to plan the work and assign

tasks to teams

Drill down through activities

for more detail

Workflows

Task descriptions

Incoming and outgoing

workproducts

Applicable roles



ISO 26262 scalability and modularity

Process flow is very modular, componentised across

Systems, SW or HW or OEM and Subcontractor relationships

Process template also modular to reflect major tasks or phases



ISO 26262 Process flow

The modular nature of the time lines

means that the flow can be adapted

Duplicate the available flows or

Further levels of detail can be applied at

the iteration level

The process flow is controlled in the

project environment by start and end

dates

Make the relevant work task the active

iteration in a timeline



ISO RTC 26262 Roles

Only two roles specifically defined

Project manager

Safety manager

A number of other roles can be inferred by

the nature of the tasks e.g

Software engineer

Safety engineer

Roles defined in the template allow project

managers to assign them to team members

Affects what they do

Controlled by permissions (pre set)

Task and work item assignment can be

further controlled using teams



ISO 26262 Teams

Set of predefined teams that map to the concept phases

Need to be populated with team members

Teams can be linked to project phases

Makes it easy for a project manager to allocate the contents of work

item template to team

Team leaders assign work items to team members.



ISO 26262 work item templates

Work item templates are

modularised , it covers

Separate safety management section

Main concept phases

Seperation of production and operation

activities

Aspects of supporting processes



ISO 26262 work items Individual activities are children of

main task

Individual activities are linked

together in flows

Contain basic description that links

to details of task




Rational Rhapsody

Rational DOORS



Requirements Engineering



Quality begins with Requirements: IBM Requirements Engineering Solution

Getting everyone on the same page

Includes suppliers and subcontractors

Managing scope, plus assessing and controlling the impact of change

Ensuring end-to-end traceability

From ideas, feature definitions, product specifications and models…

To mechanical, electric/electronic and embedded software implementation, test and maintenance

Ensuring conformance to contractual agreements

Demonstrating compliance to regulations such as ISO 26262

IBM Requirements Engineering Solution Capture • Trade-off Analysis • Validation • Change Management • Traceability • Impact Analysis • Reporting & Metrics • Monitoring

Business Analysis Systems/Product Analysis & Implementation

Test & Maintenance Analysis Ideas Implementation

Requirements Definition Requirements Management



Traceability is the key to compliance with ISO 26262

Initial requirements will be decomposed, which creates traceability relationships

Other relationships can also be traced such as “consists of”, “verifies”, etc.

Traceability must be enforced in order to ensure consistency and completeness

Traceability from customer requirements through product development to test and delivery enables organizations to:

Know which requirements are implemented and tested vs. those which are not

Manage and defend against scope creep

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and development

activities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or result

in, input to the design and development process.

The plans shall be reviewed as design and development evolves.

The plans shall be updated as design and development evolves.

The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input

2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the user

and patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a


and patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.

2.4. The procedures shall include a mechanism for addressing ambiguous requirements.

2.5. The procedures shall include a mechanism for addressing conflicting requirements.

2.6. The design input requirements shall be documented by a designated individual(s).

2.7. The design input requirements shall be reviewed by a designated individual(s).

2.8. The design input requirements shall be approved by a designated individual(s).

2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.

2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of

design input.

2.10.2. From what sources are design inputs sought?

2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)

2.10.3.1. intended use

2.10.3.2. user/patient/clinical

2.10.3.3. performance characteristics

2.10.3.4. safety

2.10.3.5. limits and tolerances

2.10.3.6. risk analysis

2.10.3.7. toxicity and biocompatibility

2.10.3.8. electromagnetic compatibility (EMC)

2.10.3.9. compatibility with accessories/auxiliary devices

2.10.3.10. compatibility with the environment of intended use

2.10.3.11. human factors

2.10.3.12. physical/chemical characteristics

2.10.3.13. labeling/packaging

2.10.3.14. reliability

2.10.3.15. statutory and regulatory requirements

2.10.3.16. voluntary standards

2.10.3.17. manufacturing processes

2.10.3.18. sterility

2.10.3.19. MDRs/complaints/failures and other historical data

2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?

2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information

1.1. Input electronically formatted data

1.2. Reference external information sources

1.3. Reference external documentation

2. Store design and related information

2.1. Identify and tag design information as unique “design elements”

2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element

2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available

2.3.1. Store design elements by Design Control Guidance Element

2.3.2. Store design elements and their historical values

3. Manage all user needs

3.1. Identify the source of the user need

3.2. Identify all user types (groups)

3.3. Identify the customer (s)

3.4. Profile the expected patients

3.5. State the intended use of the product (family)

3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements

4.1. Identify the source of the requirement

4.2. Identify the associated user need

4.3. Capture requirement description and attributes

4.4. Capture acceptance criteria

4.5. Assign responsibility for each requirement

4.6. Manage incomplete requirements

4.7. Manage ambiguous requirements

4.8. Manage conflicting requirements

4.9. Approve all requirements

5. Manage acceptance

5.1. Ensure the acceptance of every user need

5.2. Ensure the acceptance of every design input requirement

5.3. Document the results of every user need acceptance test

5.4. Document the results of every design input requirements test

5.5. Make acceptance results available

6. Manage change

6.1. Maintain history of design element changes

6.1.1. Make complete change history available

6.1.2. Maintain history within and across any organizational procedure

6.1.3. Maintain history within and across any project milestone

6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes

6.2.1. Provide rationale for change

6.2.2. Describe decisions made

6.2.3. Identify approval authority for the change

6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element

6.3.1. Create backward traces to design elements within and across any organizational procedure

6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element

Traceability Reports: consistency with driving design elements

Impact Reports: other design elements affected

Links to impacted design elements

1.1.1. Create backward traces to design elements within and across any organizational

procedure

Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone

Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design Control

Guidance Elements

Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizational

procedure

Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone

Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design Control

Guidance Elements

Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements

Link Change Design Object with affected design element(s)

Traceability Links and Reports from affected design element(s)

Impact Links and Reports from affected design element(s)

1.2.1. Associate design element changes with decisions, rationale, and approval authority

information

Change Decision Objects with following Attributes:

Disposition Attribute

Decision Attribute

Rationale Attribute

Owner Attribute

Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure

Change Design Object Traceability Link on Procedure Attribute

Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone

Change Design Object Traceability Link on Milestone Attribute

Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements

Change Design Object Traceability Link to traced design elements

Change Design Object Impacts Link to linked design elements

1.3. Mange the change process

Design Change Module

Design Change Reports

Object History

Object History Reports

Versions

Baselines

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and development

activities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or result

in, input to the design and development process.

The plans shall be reviewed as design and development evolves.

The plans shall be updated as design and development evolves.

The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input

2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a


and patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a


and patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.

2.4. The procedures shall include a mechanism for addressing ambiguous requirements.

2.5. The procedures shall include a mechanism for addressing conflicting requirements.

2.6. The design input requirements shall be documented by a designated individual(s).

2.7. The design input requirements shall be reviewed by a designated individual(s).

2.8. The design input requirements shall be approved by a designated individual(s).

2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.

2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of

design input.

2.10.2. From what sources are design inputs sought?

2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)

2.10.3.1. intended use

2.10.3.2. user/patient/clinical

2.10.3.3. performance characteristics

2.10.3.4. safety

2.10.3.5. limits and tolerances

2.10.3.6. risk analysis

2.10.3.7. toxicity and biocompatibility

2.10.3.8. electromagnetic compatibility (EMC)

2.10.3.9. compatibility with accessories/auxiliary devices

2.10.3.10. compatibility with the environment of intended use

2.10.3.11. human factors

2.10.3.12. physical/chemical characteristics

2.10.3.13. labeling/packaging

2.10.3.14. reliability

2.10.3.15. statutory and regulatory requirements

2.10.3.16. voluntary standards

2.10.3.17. manufacturing processes

2.10.3.18. sterility

2.10.3.19. MDRs/complaints/failures and other historical data

2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?

2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

User Requirements

Technical Requirements

Test Cases Design

Requirements Management Must Provide Lifecycle Traceability From Idea through End of Life



User Reqts Technical Reqts Test Cases Design

Context Requirements Browser

End-to-end visual validation in a single view

Writing Requirements within Context

Combined document and spreadsheet views

Simple, intuitive interfaces for easy adoption

History and baselines

Solve the right problem because the requirements are visible at all times

Input and output from/to

various common formats

IBM Rational DOORS Manage All Requirements Across the Lifecycle and Across Disciplines




Rational Rhapsody

Rational DOORS



A modelling approach for a safety based




Past

Modern Approaches for Describing Systems Are Evolving To Better Manage Complexity and Reduce Time-to-market

Moving from Document-centric to Model-centric

Specifications

Interface requirements

System design

Analysis & trade-off

Test plans

Future

Cruise Control

Driver Brake

Press Brake

Brake

Disengage

Cruise Control

CC Accel Control

Disengage

Cruise Control

Release

Brake



What is Model Driven Systems Development (MDSD)?

A structured approach for the development of complex

systems across the mechanical, electronic and software disciplines

Ensures that all requirements are fulfilled

Employs models as the primary artifacts throughout systems development

Facilitates improved communication among all stakeholders

Provides a disciplined way to manage complexity through abstraction

Improves quality through integration of testing with development

Allows specification and development of software that controls the system and enables its use



Allowing abstraction, hierarchies and modularization with domain-focused, standards-based languages

Requirements

Capture &

Analysis

Systems

Analysis &

Design

System

Acceptance

(Sub-)System

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements

Requirements

Capture &

Analysis

Systems

Analysis &

Design

System

Acceptance

(Sub-)System

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements

Capture &

Analysis

Requirements

Capture &

Analysis

Systems

Analysis &

Design

Systems

Analysis &

Design

System

Acceptance

System

Acceptance

(Sub-)System

Integration &

Test

(Sub-)System

Integration &

Test

Module

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements

SysML – Systems Modeling

Language for modeling high-level

vehicle functions

logical and technical

architecture

vehicle and E/E system

behavior

UML – Unified Modeling Language

for modeling

ECU and SW architecture

Client-specific profiles

AUTOSAR

Detailed E/E System and ECU HW and

SW architecture



Maximize your budget & boost productivity with effective Systems Engineering

IBM Rational Rhapsody® software Family

Safety driven Systems Design

Understand Safety requirements early in the development cycle

Design safety into the system to begin with

Model Driven Testing:

Bring the benefits of abstraction and automation to testing

Deliver products that meet customer expectations faster, cheaper

Simulation, Execution and Automation:

Identify and eliminate errors early when they are less costly to fix

Visually communicate intended behavior to customers to deliver the right product

Perform design level debugging

Requirements Driven Testing:

Reduce overall dev costs by dramatically reducing time in the testing phase

Automatic regression testing, Change impact and analysis

Simulation

Finding & Correcting Errors Sequence Diagrams

Automated unit testing

Host based Target based



Safety-Critical Profile in UML for Rhapsody

Brings together model based systems and software development with safety analysis

Safety Analysis profile in Rhapsody allows safety analysis to be carried out

Covers

FTA diagrams

Hazard analysis table view

Constraint table view

Derived safety based requirements

Also work going on with KVI

Medini tool

Safety analysis

Integrate with Rhapsody and RTC



Auto-generation of safety-relevant summary data

Fault Source Matrix, Fault Detection Matrix, Fault-Requirement Matrix, Hazard Analysis…

• Traceability improves your ability

to make your safety case

• Safety metadata guides

downstream engineering work



Automotive Safety Analysis Profile

Extends the original safety

analysis profile

Extended FMEA table into an

ASIL table

Captures ISO 26262 specific

concepts

SafetyGoal

SafetyRequirement

ASILs for elements

Captures Safety Requirements

ASIL

System/Subsystem

Allocation

Requirement type



Extend requirements engineering

to development

“Traceability and more … “

Use models for Safety Analysis

Focus on analysis and design

From “system” down to “software”

Execute models

Analyze behavior

Find errors early

Develop highly-optimized embedded C/C++/Java software

Model and Code are kept in sync

Collaborate visually

Integrated in the IBM Rational Software Platform for Automotive Systems

Benefit from Modeling with IBM Rational Rhapsody


Requirements

Capture &

Analysis

Systems

Analysis &

Design

System

Acceptance

(Sub-)System

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements

Requirements

Capture &

Analysis

Systems

Analysis &

Design

System

Acceptance

(Sub-)System

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements

Capture &

Analysis

Requirements

Capture &

Analysis

Systems

Analysis &

Design

Systems

Analysis &

Design

System

Acceptance

System

Acceptance

(Sub-)System

Integration &

Test

(Sub-)System

Integration &

Test

Module

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements




Manage Complexity

across automotive product development

and test

collaborative between OEM

and supplier

aligning the different disciplines,

mechanics, electric, electronic and

embedded software

Improve Quality

finding errors more early in the


Increase Re-use

Re-use E/E architectural elements –

from vehicle product lines down to

embedded software

Benefit from Modeling with IBM Rational Rhapsody


Requirements

Capture &

Analysis

Systems

Analysis &

Design

System

Acceptance

(Sub-)System

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements

Requirements

Capture &

Analysis

Systems

Analysis &

Design

System

Acceptance

(Sub-)System

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements

Capture &

Analysis

Requirements

Capture &

Analysis

Systems

Analysis &

Design

Systems

Analysis &

Design

System

Acceptance

System

Acceptance

(Sub-)System

Integration &

Test

(Sub-)System

Integration &

Test

Module

Integration &

Test

Module

Integration &

Test

SW Design

SW

Implementation

& Unit Test

Requirements





Rational Rhapsody

Rational DOORS



Quality Management



Model Driven Testing IBM Rhapsody Test Conductor

Test Execution &

Test Reporting

Design & Test

Processes Fully

Integrated



Rational Rhapsody TestConductor integration with Rational Quality Manager

Enables full execution control & management of model based Rhapsody TestConductor

test cases from RQM

Execution status (passed/failed) and result reports (Execution Results, Coverage Results)

accessible through RQM

RQM can utilize TestConductor execution results to continuously provide transparent &

up to date QA statistics and QA reports




Rational Rhapsody

Rational DOORS






Integrate Safety Design into Design from the beginning

Safety Eng.

Requirements Eng.

System Architect

Safety Analysis:

• Fault Tree Analysis (FTA)

• Fault Means and Effective

Analysis (FMEA)

• Hazard Analysis

Requirements Analysis:

• Functional and Non-Functional

Requirements

• Safety Requirements

• Business and Regulatory

Requirements

System and Software Design:

• Structural

• Behavioral

• Temporal

• …



4

8 Recap: How the elements of our platform relate to ISO 26262 Requirements (DOORS)

26262 Standard should be placed into a requirements database

Drive activities as well as support traceability and verification

Systems Modeling, Simulation, and Auto-Code Generation (Rhapsody)

SysML modeling provides ability to architect overall system – mechanical and E/E and then to execute to

verify model

Configuration and Change Management (Rational Team Concert)

Configuration management of E/E In development (baseline and other revisions), as well as configuration

management for different option combinations

Change Management for control of ECRs to E/E

Process (Rational Team Concert and Method Composer)

26262 is very process based

Non-prescriptive: “what to do” as opposed to “how to do”

Verification and verification planning (Test Conductor and Rational Quality Manager)

Lot of emphasis on validation and verification of Systems, HW and SW

Level and type of test dependent upon ASIL of element to be developed.



Traceability,Compliance & Security

CollaborativeLifecycle

Management DomainModels

FutureIBM

Capabilities

Storage

Collaboration

QueryDiscovery

Administration: Users, projects, process

Best Practice Processesand Methodologies

Presentation:Mashups

Design &Development

3rd-PartyJazz

Capabilities

Yourexisting

capabilitiesPortfolio, Product

& Project Management

Traceability,Compliance & Security

CollaborativeLifecycle

Management DomainModels

FutureIBM

Capabilities

Storage

Collaboration

QueryDiscovery

Administration: Users, projects, process

Best Practice Processesand Methodologies

Presentation:Mashups

Design &Development

3rd-PartyJazz

Capabilities

Yourexisting

capabilitiesPortfolio, Product

& Project Management

Key Results

Improved collaboration along the design chain and the entire lifecycle

Increased productivity due to comprehensive electrical, electronics and software asset management

Lower cost of safety and regulatory compliance

ISO FDIS 26262

Automotive SPICE©

Effective product development processes

can increase productivity by 40%

and reduce defects by 75%

IBM Rational Software Platform for Automotive Systems Key Results of an E/E engineering lifecycle management



© Copyright IBM Corporation 2011. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

www.ibm.com/software/rational

developing safe automotive electric and electronic · pdf filedeveloping safe automotive...

Documents