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

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.

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

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? 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

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