Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ISO 26262 Approval of Automotive Software Components

2,878 views

Published on

Originally presented on December 07, 2016.

Watch on-demand: http://ecast.opensystemsmedia.com/704

Published in: Software
  • Be the first to comment

  • Be the first to like this

ISO 26262 Approval of Automotive Software Components

  1. 1. Bob Leigh, Director of Market Development, RTI Joe Wlad, Vice President of Business Development, Verocel ISO 26262 Approval of Automotive Software Components Moderator: Brandon Lewis, OpenSystems Media Speakers:
  2. 2. Agenda  Housekeeping  Presentation  Questions and Answers  Wrap-up
  3. 3. The Verification Company Software Component Approval Joe Wlad, VP, Business Development
  4. 4. © Agenda • ISO 26262 Overview • ISO 26262 Software Objectives • Software Components • Key Characteristics of Reusable Components • Integration of Software Components 4
  5. 5. © Verocel – What we do Safety Critical Software Verification ToolsVerification Services Development ToolsSoftware Development Services 5 Verocel has undertaken ISO26262 Certification with TüV Sud for ISO26262 accreditation for Verocel’s plans
  6. 6. © What we will cover • ISO26262 covers ten parts, including management of functional safety, safety analyses, product development at the system level, among others • We will focus on the areas of ISO26262 that are relevant to software development • We will not cover system activities, safety analyses, hardware and production and operation requirements 6
  7. 7. © ISO26262 Overview • ISO26262, published in 2011, is a derivative of IEC61508, the safety standard for electric and electronic systems • Defines a development lifecycle that is unique to automotive design and production • Addresses safety through a risk-based approach for determining Automotive Safety Integrity Levels (ASIL) • Safety Cases are required to justify ASIL selection and compute residual risk • Next revision is due in 2018 7
  8. 8. © Automotive Safety Lifecycle 8 Management Development Production Operation Service DecommissionVovlo
  9. 9. © Example Applications of ISO26262 • Applies to vehicles of 3500 Kg and less 9 ISO26262 Stability and Control Steering Assist ADAS Clemson.edu
  10. 10. © ISO26262 SOFTWARE COMPONENTS 10
  11. 11. © Software Component Relevant parts of ISO26262 11 1. Vocabulary 2. Management of Functional Safety 2-5 Overall Safety Management 2-6 Safety Management During Development 2-7 Safety Management after release 3. Concept Phase 3-5 Item Definition 3-6 Initiation of Safety Lifecycle 3-7 Hazard Analysis and Risk Assessment 3-8 Functional Safety Concept 7. Production and Operation 7-5 Production 7-6 Operation, Service and Decommissioning 4. Product Development: System Level 4-5 Initiation of Product Development at System Level 4-6 Specification of Technical Safety Requirements 4-7 System Design 4-11 Release for Production 4-10 Functional Safety Assessment 4-9 Safety Validation 4-8 Item Integration and Testing 5. Product Development: Hardware Level 5-6 Specification of Hardware Safety Requirements 5-5 Initiation of Product Development at Hardware Level 5-7 Hardware Design 5-8 Hardware Architectural Metrics 5-9 Evaluation of Violation of Safety Goal due to Random HW failures 5-10 Hardware Integration and Testing 6. Product Development: Software Level 6-6 Specification of Sofware Safety Requirements 6-5 Initiation of Product Development at Software Level 6-7 Software Arch. Design 6-8 Software Unit Design 6-9 Software Unit Test 6-10 Software Integration and Testing 6-11 Verification of Software Safety Requirements 8. Supporting Processes 8-5 Interfaces within Distributed Environments 8-10 Documentation 8-6 Specification and Management of Safety Requirements 8-7 Configuration Managements 8-8 Change Management 8-9 Verification 8-11 Qualification of Software Tools 8-12 Qualification of Software Components 8-13 Qualification of Hardware Components 8-14 Proven in Use Argument 9. ASIL-oriented and Safety-oriented Analyses 9-5 Requirements decomposition with respect to ASIL Tailoring 9-6 Criteria for coexistence of elements 9-8 Safety Analyses 9-7 Analysis of Dependent Failures 10. Guideline on ISO26262 (informative) Source: ISO26262
  12. 12. © Software-specific Objectives • Part 2 – Management of Functional Safety – Overall Safety Management • Describes the complete safety lifecycle including all work products and activities in the standard (quality control, hazard analysis, etc.) – Safety Management During Development • Plans, reviews, roles, independence, safety assessment, etc. – Safety Management After Release • Continued lifecycle management and monitoring of fielded equipment (e.g., recalls, software updates) 12 Bosch
  13. 13. © Part 6 Product Development – Software Level 13 • Initiation – Plans, lifecycle phases and activities, tools, design and verification methods • Specification – Allocation and Definition of Safety Requirements to Software • Software Architectural Design – Methods and Properties of Software Design (informal vs. formal and design constraints) – Error Detection and Handling and methods of verification Raffenday.com
  14. 14. © Part 6 Product Development – Software Level (con’t) • Software Unit Design – Coding-level activities, properties and verification methods (including static code analysis) • Software Unit Test – Requirements-based, integration and fault-injection tests, coverage analysis • Software Integration and Testing – Interface tests, function and call coverage (data and control coupling) • Verification of Software Safety Requirements – Testing in the target environment (target board, integration lab or vehicle) 14
  15. 15. © Part 8 – Supporting Processes Specific to Software • Configuration Management – Control of the software, unique identification and reproducibility • Change Management – Control, monitoring, implementation and documentation of changes • Documentation – Methods to store, control and manage data and documentation • Confidence in Software Tools – Confidence = Impact and Tool Error Detection capabilities – Dependent on ASIL, Usage History and Use Cases: determined by user • Qualification of Software Components – Reuse of qualified software elements – the topic of this presentation 15
  16. 16. © Lifecycle Traceability 16 Bi-directional traceability is called out in sections 7 and 8 of Part 6. Traceability is implied in all phases when establishing compatibility with inputs of each phase
  17. 17. © Examples of Software Tools • Coverage Tools (Statement, Decision and MCDC coverage analysis tools) • Example: VerOCode: Object Code Coverage tool addresses MCDC coverage – Test on target without instrumenting the code • Application Lifecycle Management Tools • Example: VeroTrace – Verification Life-Cycle Management Tool – Manages Requirements, Design, Tests, Coverage, Problem Reports, and more. – Provides full Traceability between all of the Artifacts – Eases showing completeness of traceability – Enforces Software Development Processes – Impact Analysis for Changes • Static Code Analysis Tools – Many COTS Vendors • Test Harness Tools – Many COTS Vendors including Verocel 17
  18. 18. © SOFTWARE COMPONENTS 18 TechTom
  19. 19. © What is a Software Component? • Components such as graphics libraries, operating systems and communication protocols 19 Hardware Operating Environment Board Support Package (BSP) Architecture Support (ARM, x86, Power Arch) Graphics Library Pub/Sub MessagingFile System Qualified Reusable Software Components
  20. 20. © KEY CHARACTERISTICS OF SOFTWARE COMPONENTS 20 Dupont
  21. 21. © Qualified Software Component- Desired Characteristics • Have few, if any hardware dependencies • Be easily portable to varying hardware platforms • Have clear boundaries with other software components and hardware • Be provided in binary or pre-linked form, obviating the need for rebuilding • Be of limited complexity • Be adaptable for modification and expansion with minimal change impact 21
  22. 22. © INTEGRATION OF QUALIFIED SOFTWARE COMPONENTS 22
  23. 23. © Integration of Qualified Software Components • ISO26262 Compliance Certificate from an approved entity (such as TüV). • Software Safety Plan • Functional Safety Manual • Compliance Matrix : shows the Part 2, 6 and part 8 objectives that the software component fulfils The matrix summaries each requirement, the associated evidence of compliance and to what extent credit is taken for each objective. For any objectives where full credit is not taken, a summary of the required activities by the integrator should be included. • Configuration Index or Version Description Document • User’s Guides and Manuals • Integration Guide: Integrator’s roadmap to ISO26262 using the documentation set provided by the component supplier 23
  24. 24. © Integration of Qualified Software Components (Con’t) • Verification Results: The verification results would include information on reviews of requirements, design and code, test cases and results. • Test Vectors: means to establish equivalence to the results supplied by the component developer. • Tool Qualification Data • Vulnerability Analysis or Hazard Analysis: This document would provide details on the hazards and vulnerabilities summarized in the safety manual. This information will give the integrator additional insight into the rationale behind each hazard and mitigation technique. Aids developer in composing their safety analysis • Traceability Data: Req/Des/Test/Results/ISO objectives • Partitioning Analysis (optional): A partitioning analysis may be required if the software component supports some level of ASIL separation 24
  25. 25. © Summary • ISO26262 qualification of software components is possible • Sections 2, 6 and 8 of ISO26262 address software development and qualification • Key characteristics for qualified components are modularity, hardware independence, clear interfaces • Component suppliers should provide guidance on how to integrate qualified components by providing instructions and activities for integrators 25
  26. 26. Using RTI Connext® DDS Cert for ISO 26262 Bob Leigh, Director of Market Development, RTI
  27. 27. RTI’s Experience • ~1000 Projects – Healthcare – Transportation – Communications – Energy – Industrial – Defense • 15+ Standards & Consortia Efforts – Interoperability – Multi-vendor ecosystems ©2016 Real-Time
  28. 28. Need for Safety Certification • Ensure safe operation of autonomous cars • Ensure design of commercial components © 2016 RTI
  29. 29. Software Connectivity Within and Between Segments Sensors Communications Fusion Actuators Control Displays Recording © 2016 RTI
  30. 30. Traditional Approach to Distributed Systems • Apps or connectivity layer written directly to transport – Custom handling of addressing, discovery, interoperability, reliability, failover, security… • Tied to transport’s: – Semantics, e.g.: 11, 1many, reliable, unreliable… – Proximity assumption, e.g.: same partition, same node Sockets, AFDX, shared memory, ARINC ports, message queues… Application OS & Transport Application OS & Transport May not be clean separation between app, connectivity and integration logicConnectivity Logic Connectivity Logic © 2016 RTI ASIL ASILASIL ASIL
  31. 31. Costs Increase over Time • Often use point-to-point integration – Changing or adding components affects others – Necessitates integration work, re-certification – O(n2) complexity • Requirements change, e.g., moving apps and changing transports • Systems become more stovepipe, brittle and expensive to maintain over time © 2016 RTI
  32. 32. Savings from DDS Certification Evidence (Avionics) 30,000 ELOC 20,000 ELOC 10,000 ELOC DO-178C DAL A $3,000,000 $2,000,000 $1,000,000 DO-178C DAL B / ASIL-D $2,550,000 $1,700,000 $850,000 DO-178C DAL C / ASIL-B,C $1,800,000 $1,200,000 $600,000 • DDS certification evidence available at fraction of development cost • Availability at start of project significantly reduces risk 32 © 2016 RTI
  33. 33. Reducing Software Certification Costs © 2016 RTI Custom Application Code Operating System Hardware Middleware Middleware Reduce and simplify application code Leverage software components with proven certifiability and reusable certification evidence
  34. 34. Reducing (Re)certification Costs Modularize and decouple system components • Evaluate each only to its applicable ASIL Level • Minimizes recertification effort as components evolve • Promotes reuse © 2016 RTI Module Operating System Hardware Middleware Module Module Module
  35. 35. Approach: Data Distribution Service (DDS) • Standard means for inter-module communication • Intra-node and inter-node • Between safety levels © 2016 RTI Module Operating System Hardware Data Distribution Service – DDS DataBus Module Module Module Module Operating System Hardware Module Module Module Network
  36. 36. DDS Connectivity Standard • Defined by Object Management Group (OMG) • High-level publish/subscribe API – Common semantics regardless of underlying transport, physical proximity • Addresses portability and interoperability – Across programming languages, CPU types and DDS implementations © 2016 RTI Application Operating System DDS DataBus UDP TCP Shmem Qs/ports Standard API Standard Protocol
  37. 37. RTI Connext® DDS Cert • Replaces custom connectivity code, simplifies app and integration logic • Based on Data Distribution Service (DDS) standard DDS APIApplication Operating System Application Operating System xport1 xportn… xport1 xportn… Connext DDS Cert Connext DDS Cert DDS-RTPS Wire Interoperability Protocol: Interoperable across programming languages, operating systems, CPU families Pluggable transport interface Publish/subscribe semantics © 2016 RTI
  38. 38. Isolate Certified Components • Freedom from Interference • Certify Modules to Required Safety Levels • Upgrade components without re-certification © 2016 RTI Module Operating System Hardware Data Distribution Service Module Module Module Module Operating System Hardware Module Module Module Network ASIL ASIL ASIL ASIL
  39. 39. Reduced Application Code Message Centric Data Centric (DDS) Message Centric Middleware Application Application Logic Message Parsing and Filtering Message Caching Send/Receive Packets Addressing, Marshaling Data Centric Middleware (DDS) Send/Receive Packets Discovery, Presence Marshaling, 32/64 Message Caching & State Management Message Parsing and Filtering Application Application Logic Savings © 2016 RTI
  40. 40. Connext DDS Cert • Limits size of distributed system – Suits most onboard systems – Reduces ELOC • Predictable – No dynamic memory allocation – Applications preconfigured – Integrates with Full Connext DDS non- certified components 40 © 2016 RTI
  41. 41. Software Development Folder (electronic form) (SDF) NOTE: This information is provided as a set of files on a DVD. They are not maintained as a folder; instead, additional files are generated which allow these materials to be grouped by requirements. The information is presented in a browseable format so that the information may be viewed as a software development folder based on requirement identification. The Software Development Folder (SDF) includes at a minimum:  Reference to the applicable requirements.  Reference to the implementation (Design & Code).  Evidence of reviews for the requirements, design, code, test procedures, test results, and structural coverage analyses.  Software test procedures.  Software test results.  White Papers.  Artifact Change history (CM System).  Applicable problem reports.  SQA Audit Reports.  Internal Software Conformity Review (provided separate from the certification data package). CC1 11.9 11.10 11.13 11.14 11.17 11.18 11.19 Full Evidence Product Name Product Description Control Category DO-178C Reference Plan for Software Aspects of Certification (PSAC) Provides the certification (approval) authorities an overview of the means of compliance, and insight into the planning aspects for delivery of the product specific to Connext DDS Cert. CC1 11.1 Software Quality Assurance Plan (SQAP) Defines the SQA process and activities. CC1 11.5 Software Configuration Management Plan (SCMP) Defines the CM and change control processes. CC1 11.4 Software Development Plan (SDP) Software Requirements Standard (SRStd) Software Design Standard (SDStd) Software Coding Standard (SCStd) Defines the processes used for requirements analysis, development, and test for the software product. Includes the standards for requirements, design, and code. CC1 11.2 11.6 11.7 11.8 Software Verification Plan (SVP) Defines the test philosophy, test methods, and approach used to verify the software product. CC1 11.3 Software Test Plan (STP) Documents the project-specific approach to verifying Connext DDS Cert. CC1 11.3 Tool Qualification Plan Identifies the tools to be qualified under the current project. CC2 12.2.2 DO-330 10.1.2 Software Requirements Specification (SRS) Defines the software requirements applicable to Connext DDS Cert. CC1 11.9 Software Vulnerability Analysis (SVA) Identifies potential failure conditions in the software, their potential impact, and proposed mitigation for Connext DDS Cert. CC1 N/A Design Components, in Program Design Language (PDL) Describes the design of Connext DDS Cert. CC1 11.10 Software Configuration Index (SCI) Software Configuration Index (SCI) Tables Identifies the software components for Connext DDS Cert with version information necessary to support regeneration of the product. Also includes the documents comprising the data package. CC1 11.16 Software Life Cycle Environment Configuration Index (SECI) Identifies the tools used to build and test the software for Connext DDS Cert. CC1 11.15 Technical White Paper: - Control-Coupling Verification With VerOLink (VerOLinkWP.pdf) - Single topic technical paper providing additional information to the certification authorities and users. CC2 N/A Requirements Traceability Document (RTD) Provides traceability from the requirements to all related certification life cycle artifacts including design, code, and test materials for the delivered software product. CC1 11.9 11.21 Software Accomplishment Summary (SAS) Documents the actual versus planned (per PSAC) activities and results for the project. Provides a summary of the means of compliance used for the software. Justifies any deviations from the plans. CC1 11.20 Sources Provides the Source files for: - Connext DDS Cert - Test procedures. - Build and test scripts. CC1 11.11 Results Documents the results of the functional and structural coverage analysis. This includes the actual results and any applicable analyses performed including coverage analysis. CC1 11.14 11.21 11.22 Libraries Linkable versions of the “as tested” product libraries. CC1 11.12 Verification tools Verification tools are identified and described in the Tool Qualification Plan for Connext DDS Cert. CC2 12.2 940 High-Level Requirements 3,680 Low-Level Requirements 3,400 test files 99.88% code coverage testing © 2016 RTI
  42. 42. Certified Middleware Greatly Eases Safety Certification • Provides non-stop availability – Decentralized architecture – No single point of failure – Support for redundant networks – Automatic failover between redundant publishers – Dynamic upgrades • No central server or services • Version-independent interoperability protocol • Supports subsystem isolation and incremental certification • Controls real-time Quality of Service • Makes missed deadlines and presence visible • Proven in thousands of mission critical systems © 2016 RTI
  43. 43. Ease Safety Certification • Safety certifiable connectivity platform – Stringent SWaP requirements – Complete certification evidence – Full interoperability with DDS implementations • DO-178C Level A – Flight management systems • ISO 26262 – Road vehicle functional safety • IEC 60601 class 3 – Medical devices Available Soon Soon © 2016 RTI
  44. 44. Full System Support Program Development Connext DDS Pro Connext DDS Micro Connext DDS Cert Connext DDS Secure Research In-car Platform Connected Vehicle © 2016 RTI
  45. 45. Connext DDS Cert Summary • Certify to ISO 26262 ASIL-D • Preliminary Certification Package available now • Significantly reduces initial and ongoing certification effort – Can save 10,000s lines of application code – Loose coupling minimizes software changes as systems evolve © 2016 RTI
  46. 46. Audience Q & A Bob Leigh, Director of Market Development, RTI Joe Wlad, Vice President of Business Development, Verocel
  47. 47. Thanks for joining us Event archive available at: http://ecast.opensystemsmedia.com/ E-mail us at: jgilmore@opensystemsmedia.com

×