View
346
Download
9
Category
Preview:
Citation preview
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
Recommended