Upload
corey-york
View
265
Download
11
Embed Size (px)
Citation preview
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.