Ibmautomtive

Dr.
Udo Brockmeyer, CEO, BTC Embedded Systems AG

Challenges and solutions for developing safety
critical automotive software in compliance with
ISO 26262
Moderator:
Curt Schwaderer, Technology Editor, OpenSystems Media
Speakers:
Agenda
Housekeeping
Presentation
Questions and Answers
Wrap-up
2014 IBM Corporation
Challenges and solutions for developing
safety critical automotive software in
compliance with ISO 26262
Software and Systems Engineering | Rational
Agenda
Functional Safety
ISO 26262
Model Driven System Development (MDSD) and Model Based
Testing (MBT)
Development and Testing of Safety-Critical Software
IBM Rational Rhapsody Reference Workflow
Qualification of Software Tools
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
Because of E/E vehicles became instrumented, interconnected and
intelligent over the last 30 years
1980 1990 2000 2010 2020
Engine management
ABS
Digital dashboard
Electronic seats /
doors
Automated climate
control
Safety sensors
Door
Brake Engin
e
Instru
ment
Gearb
ox
ECU
Dynamic Damping Control
Brake Energy Regeneration
Integral Active Steering
Electrically controlled air vents
Night Vision
Lane Departure Warning
Lane Change Warning
Adaptive Headlights
Head-Up Display
Active Cruise Control
Camera systems
Driver assistant systems
engine ECU chassis ECU
safety ECU
brake ECU
Infotain-
ment ECU
instrument
ECU
door ECU
gateway ECU
Intelligent Vehicles
Increasing levels of
electrification
Intersection control violations
Lane/road departure
Road surface and pavement
conditions
360/distance vision
Active suspension and
stability control
Dynamic route guidance /
navigation
Motorist information
Data downloads
Recovery of stolen vehicles
Electronic payments
Ignition
Engine controls
Instrumentation
Engine
S
o
f
t
w
a
r
e

F
u
n
c
t
i
o
n
a
l
i
t
y

a
n
d

A
m
o
u
n
t
10 k
LOC
100 k
LOC
1 M
LOC
10 M
LOC
Electric and Electronic (E/E) systems are realizing automotive product
innovation
C
ECU
Domain
Vehicle
Software -
Komponente
Software -
Subsystem
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?
A safety approach is needed
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
Obvious examples:
anti-lock brakes, air bags, traction control, electronic cruise control, adaptive cruise
control, collision avoidance, lane change control
Less obvious examples:
front windshield defroster/defogger, rear windshield (backlite) defroster, auto-on
headlamps, auto-on running lights, seat-belt pre-tensioners, low tire pressure
warning system, engine, electric-assist power steering.
What is ISO 26262
ISO 26262 (derived from principles in IEC 61508)
Functional Safety for E/E Systems in Road vehicles (<3.5 tonnes), 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
What ISO 26262 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
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
The Premier Event for Software and Systems Innovation
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
Software Development and Testing with
IBM
Rational
Rhapsody

and IBM
Rational
Rhapsody
TestConductor Add On
(Model Driven System Development (MDSD) and Model Based Testing (MBT))
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
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
MDSD Benefit 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
Model Driven Testing
IBM Rational Rhapsody Test Conductor Add On
Test Execution &
Test Reporting
Design & Test Processes
Fully Integrated
Code coverage with Rhapsody TestConductor
Rational TestConductor Add On computes
code coverage for individual test cases and
complete test contexts
Statement, Condition/Decision(CD), Modified
Condition/Decision (MCDC) coverage
In particular needed when using Rhapsody for
safety critical development according to safety
standards, e.g. IEC 61508, ISO 26262
In safety critical users have to demonstrate that all
requirements are successfully tested and that the
complete code has been tested
18
MBT Benefit with Rational Rhapsody TestConductor Add On
Visual test definition for improved collaboration
Automated test execution, monitoring and test architecture creation
Early validation of requirements during systems engineering
Automate unit and regression testing helping improve software quality
Requirements
capture & analysis
Systems
analysis & design
System
acceptance
(Sub-)System
integration & test
Module
integration & test
SW design
SW implementation
& unit test
Ensure
Correctness
Implementation
Ensure
Correctness
Specification &
Design
Development and Testing of Safety-Critical Software
Two main topics in the remainder of this discussion:
Functional safety is influenced by the development process (ISO 26262, part 6, Introduction)
Using MBD/MBT and tools like IBM Rational Rhapsody require some guidance for users to enable usage
of MBD/MBT and Rational Rhapsody in safety-critical processes
Rhapsody Reference Workflow for the development of safety-related software provides such guidance
for users
Confidence in the use of software tools is needed (ISO 26262, part 8 chapter 11)
Qualification of software tools shall be performed if necessary
IBM Rational Rhapsody Reference Workflow: Overview
Rhapsody Reference Workflow for the development of safety-related software
provides guidance on how to fulfill functional safety requirements with model-based development
methods and tools
is based on best practices for safety-related projects
addresses various workflow activities relevant for the development of safety-related software with
a special focus on verification and validation to develop safe software
conforms to IEC 61508 and ISO 26262
IBM Rational Rhapsody Reference Workflow: Workflow activities
Software modeling and Requirements traceability
Modeling guidelines and guideline checking
Model verification
Requirements based testing, Requirements coverage, Model coverage
Code generation and Rhapsody frameworks
Coding guidelines and guideline checking
Code verification
Back to back testing, Code coverage
Note: ISO 26262 highly recommends Back to back testing to ensure that the behavior of the
model units with regard to the test objectives is equivalent to the automatically generated code.
Software unit testing is then lifted up to the model level.
(ISO 26262, part 6, section 9.4.6)
Software modeling and Requirements traceability
Given requirements are translated into an executable Rational Rhapsody model with
appropriate modeling guidelines
Modeling guidelines shall be enforced and verified that they are met
Best practices for software design and software modeling shall be applied
ISO 26262 provides additional recommendations, e.g. restricted size of components,
restricted size of interfaces,
Of particular importance is traceability, e.g.
Each requirement can be traced to one or more derived artifact like model elements and/or source
code and test cases. This shall ensure that all requirements are considered in subsequent
development phases.
Each model artifact, the source code and test case can be traced back to one or more
requirement. This shall ensure that no unintended functionality is developed for which no
requirement exists
Tool supported (Rational Rhapsody) traceability information can be used to
automatically generate traceability and coverage reports
Model verification
Created Rational Rhapsody model is verified against the underlying requirements
Model in the Loop Simulation (MiL Simulation) using Rational Rhapsody model animation
User guided (interactive) simulation of the model through different scenarios
Requirements based testing: highly recommended by ISO 26262 for all ASIL levels
Rational Rhapsody TestConductor Add-On can be used to systematically test the correct
implementation of the underlying requirements
Test / Requirements coverage measurement with Rational Rhapsody and Rational
Rhapsody TestConductor
Model coverage measurement with Rational Rhapsody and Rational Rhapsody
TestConductor using model animation
Code generation and Rhapsody frameworks
High quality and automatic C/C++ code generation for the software model
Using an execution framework coming along with Rhapsody
OXF: standard framework
SXF: simplified framework for safety critical C++
SMXF: simplified framework for safety critical C
Rational Rhapsody provides out-of-the-box profiles for code generation, e.g. Misra98 and
MisraC++
Note: using SXF and SMXF means to reuse existing code for a safety project
Demands for specific qualification measures
Rational Rhapsody provides validation suites for the frameworks
Coding guidelines shall be enforced and verified that they are met
Code verification
With Rational Rhapsody the developed/generated production code can be tested on
host computers and also on target machines
Software in the Loop testing (SiL) means testing the software on a host computer, e.g. PC
Processor in the Loop testing (PiL) means testing the software on a target machine, e.g.
evaluation board
Back to back testing is a technique to verify if MiL, SiL, and PiL execution show
equivalent behavior
Assumption: the model is correct
Needed: a thorough test suite
Rational Rhapsody and Rational Rhapsody TestConductor provide automation to
perform back to back testing
Computes pass/fail results
Code coverage can be measured, e.g. statement coverage or MCDC coverage
Excursus: Variation of the Rhapsody Reference Workflow
Sometimes a variation of the reference workflow without explicit model verification is
applied
Creation of a model based on the given requirements. The model is not simulated using
Rational Rhapsody animation or dynamically tested
The model is translated into source code by applying Rational Rhapsody automatic
code generation
The source code is compiled for SiL and/or PiL execution
Test Cases are created and executed on SiL and PiL level respectively. Back-to-back
testing can be performed regarding SiL and PiL
Requirements coverage and code coverage is measured
Qualification of Software Tools: Overview
ISO 26262, part 8 chapter 11, Confidence in the use of software tools
Provides criteria to determine the required level of confidence in a software tool
Provide means for the qualification of a software tool
Confidence is needed that the software tool effectively achieves the following goals:
The risk of systematic faults in the developed product due to malfunctions of the software tool leading to
erroneous outputs is minimized
The development process is adequate with respect to compliance with ISO 26262, if activities or tasks
required by ISO 26262 rely on the correct functioning of the software tool used
It must be performed for individual tools, tool chains, or tool functions
Determining the Required Level of Confidence I
To determine the required level of confidence in a software tool used within development
under the conditions mentioned above, the following criteria are evaluated:
The possibility that the malfunctioning software tool and its corresponding erroneous output can introduce
or fail to detect errors in a safety-related item or element being developed, and
The confidence in preventing or detecting such errors in its corresponding output
Tool Confidence Level (TCL) is based upon
Impact of tool failure (TI)
Level of Tool error detection (TD)
TCL when combined with ASIL leads to methods for tool qualification
Determining the Required Level of Confidence II
Tool Impact = 2: the tool might have an impact on safety
Tool Error Detection = 2 or 3: errors and malfunctions are not detected with sufficient
confidence in a given process
Tool Confidence Level = 2 or 3: Qualification of a tool or feature is needed
Concrete tool qualification requirement depend on the ASIL level of the product under
development
Determining the Required Level of Confidence III
The required software Tool Confidence Level shall be determined according to the following
table.
Examples for tools and functions
Simulation, automatic source code generation, test specification, test execution
Examples for preventing or detecting errors
Prevention or detection can be accomplished through process steps, redundancy in tasks or software tools
or by rationality checks within the software tool itself
Auto Code Generator Example (IBM
Rational
Rhapsody
)
TD1 can be chosen for a code generator in case the produced source code is verified in accordance with
ISO 26262 (=> TCL1, hence no tool qualification needed)
If verification is automated with a tool (IBM
Rational
Rhapsody

TestConductor Add-On) then the
verification tool will get assigned with TCL3
Rhapsody Code Generator Qualification for ISO 26262
Rhapsody Tool Impact = 2: the tool might have an impact on safety
Rhapsody Tool Error Detection =1: errors and malfunctions are detected with sufficient
confidence in a given process according to the Rhapsody Reference Workflow
Tool Confidence Level = 1 (TCL1)
Qualification of Rhapsody code generation is not needed!
Rhapsody TestConductor Qualification for ISO 26262
TestConductor Tool Impact = 2: the tool might have an impact on safety
TestConductor Tool Error Detection =3: errors and malfunctions are not detected with
sufficient confidence in a given process according to the Rhapsody Reference Workflow
Tool Confidence Level = 3 (TCL3): Qualification of Rhapsody TestConductor is needed!
Qualification: Validation of Software Tool
IBM
Rational
Rhapsody

TestConductor Add-On Certification
IBM
Rational
Rhapsody

TestConductor certification (ISO 26262, IEC 61508, IEC
62304, EN 50128)
IBM
Rational
Rhapsody

TestConductor Add-On
is a qualified testing tool for IBM
Rational
Rhapsody
Successful qualification has been acknowledged

by TV Sd (independent German certification
body)
TV Sd issued a certificate about successful
qualification
Customers can immediately leverage from the
certificate
Overview: describes the content of the Rhapsody workflow qualification package
Rhapsody Reference workflow : provides an exemplary workflow for modelling, code
generation and verification in safety critical
TestConductor Workflow: describes testing activities and objectives
TestConductor Safety Manual: provides additional information for using TC in safety
related development
TV Certificate and Report
Validation Suite for TestConductor
SXF/SMXF frameworks
SXF/SMXF validation suites
Validation suite is an essential part of the kit
IBM Rational Rhapsody Kit for ISO 26262
34
Validation Suite consists of
- detailed feature specifications
- detailed test specifications linked to feature specs
- test implementations for test specs & test results
IBM
Rational
Rhapsody

TestConductor Add-On Validation Suite
Test strategy: demonstrate that all specified features are successfully tested with
the set of tests on a certain HW/SW configurations
Summary
Model-based development of safety-relevant software is applied in the industry
IBM Rational Rhapsody Reference Workflow based on best practice industry experiences
provides guidance on the application of model-based development for safety-critical
systems
ISO 26262 defines a new approach to answer the question for software tool qualification
Approach has been successfully applied
IBM Rational Rhapsody
IBM Rational Rhapsody TestCondcutor AddOn
ISO 26262 IEC 61508
Audience Q & A
Dr. Udo Brockmeyer, CEO,
BTC Embedded Systems AG
Thanks for joining us
Event archive available at:
http://ecast.opensystemsmedia.com/
E-mail us at: clong@opensystemsmedia.com

Ibmautomtive

Uploaded by

Copyright:

Available Formats

Ibmautomtive

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ibmautomtive

Uploaded by

Copyright:

Available Formats

Dr.

Udo Brockmeyer, CEO, BTC Embedded Systems AG

Successful qualification has been acknowledged

You might also like