Contenu connexe

Présentations pour vous(20)

Similaire à Iso26262 component reuse_webinar(20)


Iso26262 component reuse_webinar

  1. 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
  2. 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
  3. WHAT IS ISO26262?
  4. 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 - Road vehicles – Functional Safety – Part 1: Vocabulary (ISO26262-1)
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. ISO 26262 V Model and SEooCs ECU Component Reuse and ISO 2626210
  11. 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
  13. 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
  14. 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
  15. 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
  17. 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
  18. 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
  19. 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
  20. 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
  22. 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
  23. Continue the learning! Mentor Automotive ECU Design with 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]
  24. QUESTIONS? ECU Component Reuse and ISO 26262