3.8 Develop Functional Safety Concept

• Derive functional safety requirements from safety goals

• Determine functional safety subsystems

• Allocate functional safety requirements to subsystems

3.8 Develop Functional Safety Concept• Build a detailed functional Safety concept model based upon the

functional safety requirements• Based upon dual redundancy of signals• Cross checking of signals• Could be mapped to a Virtual Function Bus in AUTOSAR terms

• Evaluation of the concept is carried out using execution

3.8 Develop Functional Safety Concept• Verifies that the functional safety concept is appropriate to mitigate against

Safety Requirements• Virtual prototype / Panel graphics support

• Ideal communications aid for design reviews and general sharing of information.

3.8 Develop Functional Safety Concept• Specify the criteria for the

implementation of the functional safety requirements to be test against

• Quality of service/performance requirements

• Functional safe states

• Review the functional safety requirements and test criteria

4.0 Systems Engineering for product development• First part of Systems engineering covers 4.5-4.7

• Second half covers 4.8-4.11 testing at various level to release for production

4.7 System Design• Realization of the technical safety

requirements into a System specification• Allocation of safety requirements

to HW/SW• HW interface specification• SW interface specification

• Carry out system level tests and report on them

• Verification of the proposed technical safety concept architecture

• Test type is dependent on ASIL– 2a is Simulation (highly

recommended ASIL C and D)• Verification report

• Start to understand the effects of the proposed architecture on production and operations

• How you manufacture the software (i.e. burn to EPROM, copy mirror images to HW)

• How to maintain and record issues

Develop Technical Safety Architecture

• Modeling is mentioned is a useful technique in the appendix of part 4

• Explains how systems models can be used to

• Understand safety related behavior

• Verify and validate behavior through simulation and fault injection

• Create system level tests

• The technical safety concept is the physical model of the item under development

• Allocation of the safety features, functions and ASILs defined in the functional safety concept to a physical architecture

• AUTOSAR terms it results in a Topology diagram

Develop Technical Safety Architecture• Architecture Structure

• Used to check technical safety concept as an executable model by fault injection

Develop Technical Safety Architecture• Physical architecture overview

• Similar to AUTOSAR topology diagram

Develop Technical Safety Architecture

• Mapping of Physical Architecture elements to ASIL and implementation type

• Requirements Allocated to physical elements

• Pushed back into DOORS for the specification

• HW/SW interface specs extracted use RPE/RP+ template

• Hand off Model and requirements to Suppliers/ SW development teams

Software Product Development in ISO 26262

• Maps very closely to the V cycle with iterations• In Automotive typically 4 or 5 iterations per software development project

– Actually very agile approach to SW development

• Labeled alphabetically• Some of the input from the AUTOSAR definition used to flesh out the Software

safety specification• Specifically timing information• BSW modules can be used in the Software design to specify the communications

drivers

AUTOSAR and ISO 26262 AUTOSAR maps to

development stages of ISO 26262

Provides a “How” to the ISO 26262 “What”

Provides some detail on the tasks involved in development for an AUTOSAR based project

Functional

Safety

Concept

Product

development

System level

Product

Development

SW level

System Design in AUTOSAR• Define the ECU topology and based upon the SWC constraints

allocate to the relevant ECU in the topology• In AUTOSAR the VFB model is kept independent of the

Topology• Allows great flexibility in the mapping

• From this you can derive the communication requirements and start to understand the communications elements needed from the Basic Software Modules

• Communication protocols supported– CAN– LIN– Flexray

• BSW also support error checking methods, memory partition functionality, Watchdogs etc– Common techniques used by the safety critical

community and mentioned in ISO 26262

• Define System Timing activity• Partnership with INCHRON

– Can be used to verify the safety critical timing constraints

AUTOSAR Topology Diagram• Shows the physical architecture of the feature

• Describes the ECUs and their relationships to the communications networks• Also used as the basis for an ECU extract

– ARrXML representation of the ECU

Mapping between VFB and Topology diagram

• Mapping carried out using SWCtoECUmapping• The mapping is expressed in the SWCtoECUmapping

table

6.7 and 8 Software Architecture and Unit Design

• Typically maps into the SWC and BSW design process in AUTOSAR

• Possible to use prequalified SW components

• Helps with reuse• Configured SW• Parameterised SW• SEOOC

• AUTOSAR SWC really useful for this as they have predefined interfaces in the AUTOSAR API libraries

• ISO 26262 has guidelines for using SW in this way in Vol 8 clause 12

Model Based SWC design in AUTOSAR

• Provides the expected interfaces for the various element types that exist in that group

• PowerTrain• Chassis• Body and Comfort etc.

• This provides the correct ARXML to integrate the units together on the RTE

• In Rhapsody you need to create Rhapsody Implementation Blocks (RImB)

• This provides the detailed implementation of the SWC functionality

• The SWC acts like a wrapper

• Implementation for the SWC for ECU 2

• Provides the basis for the SWC unit test

• testconductor works with AUTOSAR models at the SWC unit level

DO-178B at 30,000 feet

• DO-178B defines detailed guidelines for development of aviation software that performs intended functions

• DO-178C takes into account • Modelling (UML)• Model based code generation

• The FAA accepts use of DO-178B/C as a means of certifying software in avionics

• DO-178B/C outlines the objectives to be met, the work activities to be performed for each objective, and the evidence (output documents) to be supplied for each objective

• Objectives are organized into process areas• Planning• Development • Verification• Configuration Management• Quality Assurance

Efficiency through Automation for DO-178B

Planning Development

• PSAC• SDP• SVP• SCMP• SQAP• Standards

PSAC – Plan for Software Artifacts of CertificationSDP – Software Development PlanSVP – Software Verification PlanSCMP – Software Configuration Management PlanSQAP – Software Quality Assurance Plan

Requirements

Verification Data, SQA data, SCM data

Verification, Configuration Management, Quality Assurance

Design Code Integration

SOI#1 SOI#2 SOI#3 SOI#4

• High Level Req

• Derived High Level Req

• Architecture• Low Level

Req• Derived Low

Level Req

• Source Code• Exec, Object

Code

• Test Cases & Procedures

• Test Results

Cert. Liason

Inadequate formal plans or not following them

Inadequate level of detail and process for Reqs

Inadequate or non-automated Reqs Mgmt and Traceability Mgmt

Excessive code iterations

Lack of automated testing

Improper Tool Qual (too much or too little)

Neglecting “Independence” & QA Empowerment (“Boss”)

Weak process and checklist management

ISDP-178

• The Integrated Software Development Process for DO-178B (ISDP-178) is a set of practices to help organizations developing products for certification under DO-178B

• The process may be applied to any appropriate development tooling but is specifically optimized for the Continuous Engineering Toolsuite consisting of

• Rational Team Concert• Rational DOORS• Rational Rhapsody• Rational Quality Manager

• The ISDP-178 address three primary needs• Process specification• Process enactment• Specific links from the DO-178B standard to process content to aid in ensuring

compliance– By Objective– By Certification Level– By Work Product– By Checklist

ISDP-178 Process Definition• The ISDP-178 Process consists of a

delivery process composed of a number of best practices, including:

• Prespiral Planning• Developing Requirements• Defining and Deploying the Development

Environment• Project Control (governance)• Change Management• Configuration Management• Incremental Iterative Development• High Fidelity Modeling• Real-time Embedded Architecture• Collaborative Design• Continuous Integration• Verification and Validation

ISDP-178 Links to DO-178B Standard Content

ISDP-178 Links to DO-178B Objectives

ISDP-178 Links to DO-178B Objectives

ISDP-178 Links to DO-178B by Certification Level

Tool Qualification for DO-178B • Is Tool Qualification Necessary?

• Generally not. Ask these questions:

DO-178B process

eliminated, reduced or automated?

Is output of tool verified per Section 6?

No Qualification NeededN

Y

N

Can an Error be Introduced

Y

Can an Error be overlooked

Qualify as Dev. Tool

Qualify as Verification Tool

YY

27

Tool Qualification for ISO 26262• Is Tool Qualification Necessary?• Can the output of the tool affect the safety of the output

• More likely yes for 26262• Qualification of tool is also tied into your process and features used in the

tool• Almost the whole tool chain has to be qualified for 26262

• Principally affects Requirements, Configuration Management, Test

IBM Rational ISO 26262 and DO-178B/C Qualification kits available

• TUV kits from IBM and third parties for 26262• DOORS• DOORS Next Generation• Test Conductor• Rational Team Concert • Rational Quality Manager

• DO-178 tool qualification is mainly about the software testing• IBM Rational TestConductor• IBM Rational Test RealTime• IBM Rational Logiscope

Resources• Download practice content from the

IBM Rational Solution Process Assets web page. • Being agile while still being compliant: Paper by Keith Collyer

and Jordi Manzano (Diagnostic Grifols)

Thank YouYour Feedback is

Important!

Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone,

laptop or conference kiosk.