Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Qt is a registered trade mark of Digia Plc and/or its subsidiaries. All other trademarks mentioned in this document are trademarks of their respective owners.
Robert Bates
Chief Safety Officer
Mentor Embedded
ECU Component Reuse
and ISO 26262Chief Safety Officer
Mentor Embedded
May 2015
mentor.com/automotive
Agenda
ECU Component Reuse and ISO 262622
Objectives
Brief overview of ISO26262
Reusable components (SEooC) in
ISO26262
Considerations for SEooC from Suppliers
Reusable Software from other
Industries
Results
Understand considerations when re-
using components in ISO26262
mentor.com/automotive
What is Functional Safety?
From IEC61508:
— The part of the overall safety that depends on a system or
equipment operating correctly in response to its inputs.
From ISO26262
— Absence of unacceptable risk due to hazards caused by mal-
functional behavior of electrical and/or electronic systems
From ISO 25119
— A system that performs in a way that does not present an
unreasonable risk of injury to operators and bystanders
ECU Component Reuse and ISO 262624
Sources: IEC Website - http://www.iec.ch/functionalsafety/explained
Road vehicles – Functional Safety – Part 1: Vocabulary (ISO26262-1)
mentor.com/automotive
Safety Standard Relationships
DO-178C
— Standard for safety of software in certain airborne systems
IEC 61508
— Base functional safety specification (for industrial automation)
ECU Component Reuse and ISO 26262
IEC 62304
Adaptation of IEC
61508 for
medical devices
EN 50128
Adaptation of IEC
61508 for railway
signaling, control,
protection
ISO 26262
Adaptation of IEC
61508 for
automotive
electronic
systems
ISO 25119
Adaptation of
ISO 26262 for
tractors,
agricultural and
municipal
equipment
5
mentor.com/automotive
What is ISO26262?
IEC 61508 adaptation for road vehicle electrical/electronic
systems
Provides guidelines for creating safety related
technologies:
— Providing an automotive safety lifecycle
— Supports the tailoring of the lifecycle as needed
— Providing an automotive-specific risk-based approach for the
determination of Automotive Safety Integrity Levels (ASILs)
— Using ASILs to specify requirements to avoid unreasonable risk
— Providing requirements for validation and confirmation measures
to ensure a sufficient and acceptable level of safety being
achieved
— Provides requirements for supplier relations
ECU Component Reuse and ISO 262626
mentor.com/automotive
ISO 26262 and Software Tools
ISO 26262 considers the safety of software tools
— Applies to any software tool used in the development of a system
or its hardware or software components
— Goal is to quantify the risks of each tool introducing a systemic
fault leading to erroneous outputs, and then mitigate that risk
Tool Confidence Level (TCL) is based on two factors
— Likelihood that, if a tool fails in an undetectable way, if it can
introduce a safety issue in the final system
— Likelihood that a tool will create erroneous output in an
undetectable way
– Note that this includes the tool’s error detection and the developer’s
processes in using the tool
ISO26262 requires the user to make this determination
— They will then have to justify the determination and techniques to
mitigate risk to their certifier
ECU Component Reuse and ISO 262627
mentor.com/automotive
ISO26262 and SEooCs
ISO 26262 defines a Safety Element Out of Context (SEooC)
— An SEooC may be a system, subsystem, hardware or software
component
— SEooCs are components developed to ISO 26262
– If the item is not developed to ISO 26262, it may be Qualified or Proven in
Use
– Or, the system designer will have to make an argument to integrate the
component
Allows component suppliers to develop safe practices without regard
to how their components will be used
— Could be 3rd party providers, or internal providers delivering reusable
components
— SEooC can be hardware or software components
— Specifies handling of Safety Elements out of Context (SEooC)
ECU Component Reuse and ISO 262628
mentor.com/automotive
Why ISO 26262?
Safety issues are extremely expensive
— Recalls, lawsuits and damage to brand can easily happen
— We all know about Toyota, Honda, GM, …
— Takata (#1 air bag supplier) is fighting for survival
— Baxter Healthcare forced by US government to recall and replace
10 years of infusion pumps at significant cost
— Many, many more
German law allows companies to use development to
state of the art practices as a defense to lawsuits
— This spreads to the EU, and to the world
The introduction of IEC 61508 established state of the art
— Other industries are essentially forced to follow
— Automotive industry responded with ISO 26262
ECU Component Reuse and ISO 262629
mentor.com/automotive
What’s new here?
Functional safety has been a focus of the Automotive
Industry as long as there’s been an Automotive Industry
So, what’s different?
— By writing down requirements necessary to achieve functional
safety, a standardized flow is defined, even if it’s not YOUR flow
— In the past, safety agreements were between 2 parties (the OEM
and the Tier 1, or the Tier 1 and a supplier)
— Now, you can consider a third party being involved
– A certifier, or the safety manager of your customer is directly
involved
– They have to be convinced that your process and product is
appropriate for deployment
— This greatly increases the documentation requirements
– From development, validation, tool qualification… EVERYTHING!
ECU Component Reuse and ISO 2626211
mentor.com/automotive
Working with suppliers in ISO26262
ISO26262 formalizes safety when working with partners through
Development Interface Agreement (DIA)
— Ideally should be executed when an RFQ is established, but is required
when safety requirements for partner are known
— DIA specifies communication paths, division of activities, safety targets
(i.e. ASILs), etc. between supplier and customer
— The DIA documents safety agreements so there are no surprises later
Re-used components may either be SEooC, or not
— These might be re-used from other parts of your company, or might only
be applicable in context.
— A DIA should always be in place when the component is not an “off-the-
shelf” item
— While required by ISO26262, a DIA is not always used when the SEooC
is part of a commercial offering (such as an AUTOSAR stack)
The rest of this presentation will discuss considerations unique to
SEooC
ECU Component Reuse and ISO 2626213
mentor.com/automotive
Commercial deliveries of SEooC
Suppliers deliver modules to customers as SEooC
— These can be hardware, software, or complete subsystems
– The development of these modules conform to ISO26262
SEooCs allow supplier to focus on technology and quality
— Developer creates module without consideration to end-use
— Safety requirements, plans, etc. focus on intended usage
– Or, the developer may consider all functional requirements as being
safety requirements
— Artifacts of development, validation and safety can be provided to
customers as a safety case, and/or used for 3rd party certification
— SEooC developer has obligation to document usage, assumptions,
issues, etc. of SEooC to customer
– Generally delivered in a “safety manual”
ECU Component Reuse and ISO 2626214
mentor.com/automotive
SEooC Safety Manual
The Safety Manual is the most important safety delivery
from an SEooC component supplier to a customer
— The Safety Manual shows how to deploy the component safely
— i.e. How to put the SEooC into Context
The Safety Manual will…
— Describe the potential Safety Requirements fulfilled by the
component
– Note that not all of these will be Safety Requirements once deployed
— Describe how the component must be configured and integrated
— Any post-integration module testing that must be performed
— Describe any known safety impacting issues with the module
The Safety Manual imposes requirements on the user
— But, puts them all in one place
ECU Component Reuse and ISO 2626215
mentor.com/automotive
Runtime Component Use in ISO 26262
ISO 26262 provides 3 methods for using (or re-using) a
component to satisfy a safety requirement
— Adherent to ISO 26262
– The component was originally developed to the ISO 26262 standard
– Can be hardware or software
– SEooCs are generally adherent to ISO 26262
– These components can be reviewed by a third party (certification)
— Qualified for use
– For software components only
– Might be 3rd party COTS products (such as a C runtime library), or an
internal product
– Generally developed for use in other industries (or general-purpose)
— Proven in Use
– For components used in systems that pre-date ISO 26262
ECU Component Reuse and ISO 2626217
mentor.com/automotive
Open Source and ISO 26262
ISO 26262 does not provide a direct method to using Open Source
runtime software in safety critical systems
— Certification is intended for software developed specifically to ISO 26262
– Either as part of the device, or as an SEooC deployed into the device
— “Proven in Use” is for software previously used an not being changed
– Allows components developed and deployed before ISO 26262 to be re-used
— Qualification (26262-6, Section 12) is intended to be used for modules
developed for other industries, but with functionality useful in automotive
Open source software is already being used in several safety critical
domains (Medical, Industrial, etc.)
Qualification sounds like the right path – but technically not
— Qualified components “must” be developed to an appropriate safety
standard
— Open source development pracrices do not qualify as of today.
ECU Component Reuse and ISO 2626218
mentor.com/automotive
So, no Open Source for Safety?
Not so fast
— Qualification is intended to support re-use of high quality software
— Open-Source components are used in safety critical systems today, and
some are of very high quality (Apache, OpenSSL, Math libraries, etc.)
— Re-writing these kinds of stacks is NOT the answer
So, how to proceed?
— First, try not to. Is the component REALLY safety relevant?
— If it is relevant, minimize the ASIL level, preferably to ASIL B
— Can you make an argument for the re-use of the open-source software?
– Probably yes for the examples above, probably not for LINUX (at least not
today)
— Have discussion with your customer or certifier BEFORE assuming
success
– Some certifiers are already allowing this under tightly controlled
circumstances
ECU Component Reuse and ISO 2626219
mentor.com/automotive
How to Proceed?
Qualification of a Software Component requires the following:
— Can you Specify the Software Component?
– Requirements, interfaces, configuration, dependencies, etc.
— Can you show the Component meets its Requirements
– This is not difficult for Ethernet technology, where there are well-respected
3rd party test suites (UNH Interoperability Lab is taking the lead on this for
Automotive)
— Can you show the implementation is high-quality
– Well defined development and test requirements for the OSS component?
— Documentation of all of this, reviewed and cross-traceable is required
– Like anything else in ISO 26262
OSS use in Automotive Safety Applications is still in early days
— Much (like SIL2Linux) is still being worked out
But, it’s not impossible, and it’s coming
ECU Component Reuse and ISO 2626220
Source: “Applying Ethernet Test Methodologies to Automotive Applications”, 2014 IEEE-SA ETHERNET&IP Automotive Technology Day Presentation
mentor.com/automotive
Things to Remember
ISO 26262 allows component re-use across multiple
applications
Most suppliers will deliver re-usable components as
SEooCs
SEooC deliveries will include something like a Safety
Manual
— Which formalizes deployment requirements on the customer
For components that are NOT SEooC, a DIA should be in-
place
— Formalizes communication and commitments
Open Source is on its way to safety critical development
— Difficult today, less so tomorrow
ECU Component Reuse and ISO 2626222
mentor.com/automotive
Continue the learning!
Mentor Automotive
ECU Design with Autosar
http://www.mentor.com/embedded-software/automotive/autosar
Hansen Report overview of Mentor Automotive
[view here]
Interoperability is the Key to AUTOSAR Success (Blog post)
[view here]
Delivering Requirements Traceability & Impact Analysis (Presentation)
[view here]
The Electrifying side of Autosar (whitepaper)
The case for using ECU resource template [view]