Originally presented on December 07, 2016. Watch on-demand: http://ecast.opensystemsmedia.com/704

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. Agenda
 Housekeeping
 Presentation
 Questions and Answers
 Wrap-up

3. The Verification Company
Software Component Approval
Joe Wlad, VP, Business Development

4. ©
Agenda
• ISO 26262 Overview
• ISO 26262 Software Objectives
• Software Components
• Key Characteristics of Reusable
Components
• Integration of Software Components
4

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. ©
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. ©
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. ©
Automotive Safety Lifecycle
8
Management
Development
Production
Operation
Service
DecommissionVovlo

9. ©
Example Applications of ISO26262
• Applies to vehicles of 3500 Kg and less
9
ISO26262
Stability
and Control
Steering
Assist
ADAS
Clemson.edu

10. ©
ISO26262 SOFTWARE COMPONENTS
10

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. ©
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. ©
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. ©
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. ©
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. ©
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. ©
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. ©
SOFTWARE COMPONENTS
18
TechTom

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. ©
KEY CHARACTERISTICS OF SOFTWARE
COMPONENTS
20
Dupont

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. ©
INTEGRATION OF QUALIFIED SOFTWARE
COMPONENTS
22

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. ©
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. ©
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. Using RTI Connext® DDS Cert for ISO 26262
Bob Leigh, Director of Market Development, RTI

27. RTI’s Experience
• ~1000 Projects
– Healthcare
– Transportation
– Communications
– Energy
– Industrial
– Defense
• 15+ Standards & Consortia Efforts
– Interoperability
– Multi-vendor ecosystems
©2016 Real-Time

28. Need for Safety Certification
• Ensure safe operation of autonomous cars
• Ensure design of commercial components
© 2016 RTI

29. Software Connectivity
Within and Between Segments
Sensors
Communications
Fusion
Actuators
Control
Displays
Recording
© 2016 RTI

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Audience Q & A
Bob Leigh,
Director of Market
Development,
RTI
Joe Wlad,
Vice President of Business
Development,
Verocel

47. Thanks for joining us
Event archive available at:
http://ecast.opensystemsmedia.com/
E-mail us at: jgilmore@opensystemsmedia.com