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 OfficerMentor Embedded

ECU Component Reuse and ISO 26262

Chief Safety Officer

Mentor Embedded

May 2015

mentor.com/automotive

Agenda


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)

http://www.iec.ch/functionalsafety/explained


Safety Standard Relationships

DO-178C— Standard for safety of software in certain airborne systems

IEC 61508— Base functional safety specification (for industrial automation)


IEC 62304Adaptation of IEC 61508 for medical devices

EN 50128Adaptation of IEC 61508 for railway signaling, control, protection

ISO 26262Adaptation of IEC 61508 for automotive electronic systems

ISO 25119Adaptation 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]

http://www.mentor.com/embedded-software/automotive/autosar

http://s3.mentor.com/public_documents/report/solutions/automotive/hansen-report-4-2105.pdf

http://www.mentor.com/embedded-software/blog/post/interoperability-is-key-to-autosar-success-6e450124-1c05-493f-98e2-5a41f44644f5

http://www.mentor.com/products/electrical-design-software/resources/overview/delivering-requirements-traceability-impact-analysis-d357d594-f1a4-4c3c-a9d3-f2cc04b0df04

http://www.mentor.com/embedded-software/resources/overview/the-electrifying-side-of-autosar-the-case-for-using-the-ecu-resource-template-e97c1c5d-5d39-4c5a-a407-9eb394063582

http://www.mentor.com/products/vnd/resources/overview/the-electrifying-side-of-autosar-the-case-for-using-the-ecu-resource-template-e97c1c5d-5d39-4c5a-a407-9eb394063582

http://www.mentor.com/embedded-software/resources/overview/the-electrifying-side-of-autosar-the-case-for-using-the-ecu-resource-template-e97c1c5d-5d39-4c5a-a407-9eb394063582


QUESTIONS?


Engineering

Iso26262 component reuse_webinar