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
•
•
•
•
•
This provides the correct ARXML
to integrate the units together on
the RTE
In Rhapsody you need to create
Rhapsody Implementation Blocks
(RImB)
•
•
•
•
•
PowerTrain
Chassis
Body and Comfort etc.
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
SOI#2
SOI#1
Planning
Development
Requirements
•
•
•
•
•
•
PSAC
SDP
SVP
SCMP
SQAP
Standards
SOI#3
• High Level
Req
• Derived
High Level
Req
SOI#4
Cert. Liason
Design
• Architecture
• Low Level
Req
• Derived Low
Level Req
Code
Integration
• Source Code
• Exec, Object
Code
• Test Cases &
Procedures
• Test Results
Improper Tool Qual (too
much or too little)
Excessive code iterations
Inadequate formal plans or not
following them
Inadequate level of detail and
Lack of automated testing
process for Reqs
Inadequate
or non-automated
Verification
Data, SQA data, SCM data
Reqs Mgmt and Traceability
Mgmt
Verification, Configuration Management, Quality Assurance
PSAC – Plan for Software Artifacts of Certification
SDP – Software Development Plan
SVP – Software Verification Plan
SCMP – Software Configuration Management Plan
SQAP – Software Quality Assurance Plan
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 DO178B
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?
N
No Qualification Needed
Y
Is output of
tool verified
per Section 6?
Y
N
Qualify as Dev.
Tool
Y
Y
Can an Error
be Introduced
Can an Error
be overlooked
Qualify as
Verification Tool
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
26
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 You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.