0. 3.8 Develop Functional Safety Concept
Derive functional safety requirements from safety goals
Determine functional safety subsystems
Allocate functional safety requirements to subsystems

1. 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

2. 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. 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. 4.0 Systems Engineering for product development
First part of Systems engineering covers
Second half covers testing at various level to release for production

5. 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

6. 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

7. Develop Technical Safety Architecture
Architecture Structure
Used to check technical safety concept as an executable model by fault injection

8. Develop Technical Safety Architecture
Physical architecture overview
Similar to AUTOSAR topology diagram

9. 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

10. 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

11. AUTOSAR and ISO 26262 AUTOSAR maps to development stages of ISO 26262
Provides a “How” to the ISO “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

12. 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

13. 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

14. Mapping between VFB and Topology diagram
Mapping carried out using SWCtoECUmapping
The mapping is expressed in the SWCtoECUmapping table

15. 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 has guidelines for using SW in this way in Vol 8 clause 12

16. 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
If you have been given a functional model or a requirements module you need to select the appropriate SWC and BSW elements from the AUTOSAR libraries
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 now works with AUTOSAR models at the SWC unit level

17. 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
This objective-based nature of DO-178B allows a great deal of flexibility in regard to following different styles of software life cycle. However, once an activity within a process has been defined, it is generally expected that the project respect that documented activity within its process. Furthermore, processes (and their concrete activities) must have well defined entry and exit criteria, according to DO-178B, and a project must show that it is respecting those criteria as it performs the activities in the process.

18. Efficiency through Automation for DO-178B
SOI#1
SOI#2
SOI#3
SOI#4
Planning
Development
Cert. Liason
Requirements
Design
Code
Integration
PSAC
SDP
SVP
SCMP
SQAP
Standards
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
Excessive code iterations
Lack of automated testing
Improper Tool Qual (too much or too little)
Inadequate formal plans or not following them
Inadequate level of detail and process for Reqs
Inadequate or non-automated Reqs Mgmt and Traceability Mgmt
Verification Data, SQA data, SCM data
Technical problems: Complexity and duration of test phases, inconsistent tools
Personnel problems: Unclear responsibilities, project members with low availability
Organizational problems: Complexity of project structure, uncoordinated cross-sectional Processes
Supplier/partner problems: Strong dependency on external suppliers/partners, single sourcing of critical technology issues
Planning problems: No "realistic" view on time- and cost-to-completion, lack of progress monitoring
Incomplete Software Tool strategy for future success
Transparency is a pivotal issue in DO-178B compliance and demands that all processes and stages be fully documented in a way that can be easily reviewed and approved by regulators. It's imperative that this process is completed as accurately as possible, but also as efficiently as possible, to avoid delays in certification.
Last minute change requests that invariably have to be made can put previous standards work in jeopardy. More importantly, at each criticality, developers would be responsible for creating and managing their own documentation. Without the benefit of tools or guidelines, regulators will face a difficult review and approval process. COTS solutions can help streamline this process by providing qualifiable code generators, automatic document generation, and other mechanisms in order to reduce effort wherever possible for routine updates or changes. Developers can also take advantage of COTS software tools to support in-house processes. The choice can even be difficult for experienced developers who have been meeting DO-178B regulations for years but still need to find ways to reduce the time required to complete important but mundane tasks, such as performance testing, bug detection, and traceability. Other key considerations include cost, transparency, third-party reliability, and technology's increasing complexity, and COTS is proving itself a viable remedy to these issues.
Furthermore, once a hand-coded application is certified and flying, it can cost a substantial amount to change a line of code due to the recertification process. COTS guarantees a seamless approach to recertification.
Will using third-party software to help reach DO-178B compliance require a larger investment than building the software in-house?
Implementing COTS tools does require an investment, and companies must accurately assess their needs and spend the time necessary to identify the combination of tools that will produce the best solution. Monetarily, the majority of the investment is made up-front instead of in the development stage. But time and again, successful DO-178B compliant companies have shown that this investment pays off in the long run by using DO-178B qualifiable COTS software. Businesses can amortize the investment over several programs, easily reuse designs from project to project, and easily make modifications without having to put in the extra effort otherwise required. In fact, a conservative estimate shows that by using COTS, organizations can slash DO-178B project times by as much as 25 percent, and reduce the costs involved by as much as 70 to 80 percent. To cite one example, Ultra Electronics Datel, a software maker based in the United Kingdom, turned to a COTS tool to reduce the amount of effort required for DO-178B compliance. Using VAPS Qualifiable Code Generator (QCG) software from Presagis, Ultra Electronics Datel reduced the requirements specification and the design and test phases of  avionics display development, resulting in 25 percent faster time-to-market, and 87 percent lower development costs.
What other considerations need to be evaluated before making the choice between in-house development and purchasing COTS software?
By leveraging the latest software techniques, companies - whether they're new to DO-178B or have years of experience - will benefit from fewer coding iterations, which also means less testing for bugs, a notorious problem area when it comes to achieving DO-178B compliance. They will also face less and easier regression testing and improved hardware integration, the latter being an often-overlooked consideration. This is a critical oversight, as DO-178B is designed to help hardware and software operate in harmony.
Companies also need to consider the rapidly evolving sophistication of the avionics industry. Cockpits today are markedly different from their predecessors - the newest commercial aircraft cockpits feature access to live video, high-end menu-based graphics, and a growing dependence on displays in general. An example of a smart display found in modern cockpits is the multi-function display from Barco. This makes it even more imperative for avionics developers to use the right tools to help them certify their systems as quickly and easily as possible. In this way, the effective use of COTS can help them build a stronger competitive advantage.
Verification, Configuration Management, Quality Assurance
Neglecting “Independence” &
QA Empowerment (“Boss”)
Weak process and checklist management
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

19. 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

20. 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

21. ISDP-178 Links to DO-178B Standard Content

22. ISDP-178 Links to DO-178B Objectives

23. ISDP-178 Links to DO-178B Objectives

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

25. 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
Section 12.2: Can generate code if verified according to Section 6.
Example:
Config Tool: reviewed
Reqs Tool: reviewed
Modeling Tool- review generated code
Can an Error be Introduced
Can an Error be overlooked
Qualify as Dev. Tool Y
Qualify as Verification Tool Y

26. 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

27. 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

28. 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)

29. 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.