Iso26262 component reuse_webinar

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

WHAT IS ISO26262?

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
Sources: IEC Website - http://www.iec.ch/functionalsafety/explained
Road vehicles – Functional Safety – Part 1: Vocabulary (ISO26262-1)

Safety Standard Relationships
 DO-178C
— Standard for safety of software in certain airborne systems
 IEC 61508
— Base functional safety specification (for industrial automation)
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

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

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

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)

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

ISO 26262 V Model and SEooCs

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!

WORKING WITH
SUPPLIERS

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

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”

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

OPEN SOURCE

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

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.

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

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
Source: “Applying Ethernet Test Methodologies to Automotive Applications”, 2014 IEEE-SA ETHERNET&IP Automotive Technology Day Presentation

CONCLUSIONS

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

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]

QUESTIONS?

Iso26262 component reuse_webinar

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Iso26262 component reuse_webinar

Similaire à Iso26262 component reuse_webinar (20)

Plus de محمدعبد الحى

Plus de محمدعبد الحى (13)

Dernier

Dernier (20)

Iso26262 component reuse_webinar