developing safe automotive electric and electronic · pdf filedeveloping safe automotive...
TRANSCRIPT
®
IBM Software Group
© 2011 IBM Corporation
Developing Safe Automotive Electric and Electronic (E/E) Systems: Achieving Compliance with ISO 26262
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
IBM Software Group | Rational software
© 2011 IBM Corporation 4
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
IBM Software Group | Rational software
© 2011 IBM Corporation 6
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)
IBM Software Group | Rational software
© 2011 IBM Corporation 7
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“
IBM Software Group | Rational software
© 2011 IBM Corporation 8
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
IBM Software Group | Rational software
© 2011 IBM Corporation 9
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.
IBM Software Group | Rational software
© 2011 IBM Corporation 10
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
IBM Software Group | Rational software
© 2011 IBM Corporation 11
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
IBM Software Group | Rational software
© 2011 IBM Corporation 12
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
development lifecycle
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
IBM Software Group | Rational software
© 2011 IBM Corporation 13
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 Software Group | Rational software
© 2011 IBM Corporation 14
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
IBM Software Group | Rational software
© 2011 IBM Corporation 15
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
IBM Software Group | Rational software
© 2011 IBM Corporation 16
Rational Method Composer Rational Team Concert
Rational Rhapsody
Rational DOORS
Rational Quality Manager Rational Test Conductor Rational Test RealTime
A look to the inside: How IBM Rational Software Platform for Automotive Systems supports ISO 26262
An integrated support ISO 26262
IBM Software Group | Rational software
© 2011 IBM Corporation 17
Rational Method Composer Rational Team Concert
Rational Rhapsody
Rational DOORS
Rational Quality Manager Rational Test Conductor Rational Test RealTime
A look to the inside: How IBM Rational Software Platform for Automotive Systems supports ISO 26262
Process and collaboration support
IBM Software Group | Rational software
© 2011 IBM Corporation 18
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
IBM Software Group | Rational software
© 2011 IBM Corporation 19
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
IBM Software Group | Rational software
© 2011 IBM Corporation 20
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
IBM Software Group | Rational software
© 2011 IBM Corporation 21
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
IBM Software Group | Rational software
© 2011 IBM Corporation 22
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
IBM Software Group | Rational software
© 2011 IBM Corporation 23
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
IBM Software Group | Rational software
© 2011 IBM Corporation 24
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
IBM Software Group | Rational software
© 2011 IBM Corporation 25
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
IBM Software Group | Rational software
© 2011 IBM Corporation 26
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.
IBM Software Group | Rational software
© 2011 IBM Corporation 27
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
IBM Software Group | Rational software
© 2011 IBM Corporation 28
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
IBM Software Group | Rational software
© 2011 IBM Corporation 29
Rational Method Composer Rational Team Concert
Rational Rhapsody
Rational DOORS
Rational Quality Manager Rational Test Conductor Rational Test RealTime
A look to the inside: How IBM Rational Software Platform for Automotive Systems supports ISO 26262
Requirements Engineering
IBM Software Group | Rational software
© 2011 IBM Corporation 30
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
IBM Software Group | Rational software
© 2011 IBM Corporation 31
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
device are appropriate and address the intended use of the device, including the needs of the user
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
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
device are appropriate and address the intended use of the device, including the needs of the user
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
IBM Software Group | Rational software
© 2011 IBM Corporation 32
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
IBM Software Group | Rational software
© 2011 IBM Corporation 33
Rational Method Composer Rational Team Concert
Rational Rhapsody
Rational DOORS
Rational Quality Manager Rational Test Conductor Rational Test RealTime
A look to the inside: How IBM Rational Software Platform for Automotive Systems supports ISO 26262
A modelling approach for a safety based
development lifecycle
IBM Software Group | Rational software
© 2011 IBM Corporation 34
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
IBM Software Group | Rational software
© 2011 IBM Corporation 35
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
IBM Software Group | Rational software
© 2011 IBM Corporation 36
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
IBM Software Group | Rational software
© 2011 IBM Corporation 37
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
IBM Software Group | Rational software
© 2011 IBM Corporation 38
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
IBM Software Group | Rational software
© 2011 IBM Corporation 39
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
IBM Software Group | Rational software
© 2011 IBM Corporation 40
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
IBM Software Group | Rational software
© 2011 IBM Corporation 41
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
© 2011 IBM Corporation 42
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
development lifecycle
Increase Re-use
Re-use E/E architectural elements –
from vehicle product lines down to
embedded software
Benefit from Modeling with IBM Rational Rhapsody
IBM Software Group | Rational software
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
IBM Software Group | Rational software
© 2011 IBM Corporation 43
Rational Method Composer Rational Team Concert
Rational Rhapsody
Rational DOORS
Rational Quality Manager Rational Test Conductor Rational Test RealTime
A look to the inside: How IBM Rational Software Platform for Automotive Systems supports ISO 26262
Quality Management
IBM Software Group | Rational software
© 2011 IBM Corporation 44
Model Driven Testing IBM Rhapsody Test Conductor
Test Execution &
Test Reporting
Design & Test
Processes Fully
Integrated
IBM Software Group | Rational software
© 2011 IBM Corporation 45
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
IBM Software Group | Rational software
© 2011 IBM Corporation 46
Rational Method Composer Rational Team Concert
Rational Rhapsody
Rational DOORS
Rational Quality Manager Rational Test Conductor Rational Test RealTime
A look to the inside: How IBM Rational Software Platform for Automotive Systems supports ISO 26262
An integrated support ISO 26262
IBM Software Group | Rational software
© 2011 IBM Corporation 47
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
• …
IBM Software Group | Rational software
© 2011 IBM Corporation 48
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.
IBM Software Group | Rational software
© 2011 IBM Corporation 49
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
IBM Software Group | Rational software
© 2011 IBM Corporation 50
© 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