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:

Agenda

Housekeeping

Presentation

Questions and Answers

Wrap-up

The Verification Company

Software Component Approval

Joe Wlad, VP, Business Development

©

Agenda

• ISO 26262 Overview

• ISO 26262 Software Objectives

• Software Components

• Key Characteristics of Reusable Components

• Integration of Software Components

4

©

Verocel – What we do

Safety Critical Software

Verification ToolsVerification Services

Development ToolsSoftware Development Services

5

Verocel has undertaken ISO26262 Certification with TüV Sudfor ISO26262 accreditation for Verocel’s plans

©

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

©

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

©

Automotive Safety Lifecycle

8

Management

Development

Production

Operation

Service

Decommission Vovlo

©

Example Applications of ISO26262

• Applies to vehicles of 3500 Kg and less

9

ISO26262

Stability and Control

Steering Assist

ADAS

Clemson.edu

©

ISO26262 SOFTWARE COMPONENTS

10

©

Software Component Relevant parts of ISO26262

11

1. Vocabulary

2. Management of Functional Safety

2-5 Overall Safety Management2-6 Safety Management During

Development2-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 Level4-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 Analyses9-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

©

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

©

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

©

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

©

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

©

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

©

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

©

SOFTWARE COMPONENTS

18

TechTom

©

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 LibraryPub/Sub

MessagingFile System

Qualified ReusableSoftware Components

©

KEY CHARACTERISTICS OF SOFTWARE COMPONENTS

20

Dupont

©

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

©

INTEGRATION OF QUALIFIED SOFTWARE COMPONENTS

22

©

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

©

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

©

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

Using RTI Connext® DDS Cert for ISO 26262

Bob Leigh, Director of Market Development, RTI

RTI’s Experience• ~1000 Projects

– Healthcare– Transportation– Communications– Energy– Industrial– Defense

• 15+ Standards & Consortia Efforts– Interoperability– Multi-vendor ecosystems

©2016 Real-Time Innovations, Inc.

Need for Safety Certification

• Ensure safe operation of autonomous cars

• Ensure design of commercial components

© 2016 RTI

Software ConnectivityWithin and Between Segments

Sensors

Communications

FusionActuators

Control

Displays

Recording

© 2016 RTI

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.: 11, 1many, 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

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

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

Reducing Software Certification Costs

© 2016 RTI

CustomApplication Code

Operating System

Hardware

Middleware Middleware

Reduce and simplify application code

Leverage software components with proven certifiability andreusable certification evidence

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

Mo

du

le

Operating System

Hardware

Middleware

Mo

du

le

Mo

du

le

Mo

du

le

Approach: Data Distribution Service (DDS)

• Standard means for inter-module communication• Intra-node and inter-node• Between safety levels

© 2016 RTI

Mo

du

le

Operating System

Hardware

Data Distribution Service – DDS DataBusM

od

ule

Mo

du

le

Mo

du

le

Mo

du

le

Operating System

Hardware

Mo

du

le

Mo

du

le

Mo

du

le

Network

DDS Connectivity Standard

• Defined by ObjectManagement 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 DataBusU

DP

TCP

Shm

em

Qs/p

orts

StandardAPI

StandardProtocol

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 Systemxport1 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

Isolate Certified Components

• Freedom from Interference• Certify Modules to Required Safety Levels• Upgrade components without re-certification

© 2016 RTI

Mo

du

le

Operating System

Hardware

Data Distribution ServiceM

od

ule

Mo

du

le

Mo

du

le

Mo

du

le

Operating System

Hardware

Mo

du

le

Mo

du

le

Mo

du

le

Network

ASIL

ASIL

ASIL

ASIL

Reduced Application CodeMessage 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

Savi

ngs

© 2016 RTI

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

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 EvidenceProduct 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.5Software 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 Requirements3,680 Low-Level Requirements3,400 test files99.88% code coverage testing

© 2016 RTI

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

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

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

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

Audience Q & ABob Leigh,

Director of Market Development,

RTI

Joe Wlad,

Vice President of Business Development,

Verocel

Thanks for joining us

Event archive available at:

http://ecast.opensystemsmedia.com/

E-mail us at: jgilmore@opensystemsmedia.com