Workproducts#
Fig. 23 Project development work product traceability model#
Platform management#
General#
Policies
|
status: draft
|
||||
Organization-specific rules and processes for functional safety and cybersecurity. |
|||||
Training path
|
status: draft
|
||||
Evidence of competence management. |
|||||
Quality management system
|
status: draft
|
||||
Evidence of quality management. |
|||||
Quality report
|
status: draft
|
||||
Evidence of quality conformance:
* Identifies what tasks/activities/process produce the information
* Identifies when the data was collected
* Identifies source of any associated data
* Identifies the associated quality criteria
* Identifies any associated measurements using the information
|
|||||
Platform Management Plan
|
status: valid
|
||||
The Platform Management Plan shall include the Project Management Plan, Configuration Management Plan, Change Management Plan, Documentation Management Plan and Problem Resolution Plan. Plan to ensure that all work products can be uniquely identified and reproduced in a controlled manner at any time. Plan to ensure that relations and differences between versions can be traced. Plan to manage, analyse and control changes of the work products during the project life cycle. Documents should be precise, concise, clearly structured, understandable for intended users, verifiable, maintainable, and organized according to in-house procedures to facilitate information retrieval. Documentation guideline requirements must be defined for each WP. Each work product or document must include a title, author and approver, unique revision identification, change history, and status. |
|||||
Software Development Plan
|
status: draft
|
||||
Process description of SW development including
- selection of design and programming language
- design guideline
- coding guideline (e.g. MISRA, can also include style guide or naming convention)
- SW configuration guideline
- Method selection (e.g. for Architecture Verification)
- development tools
Compare also Gitub documentation
Compare also Eclipse Project Handbook
|
|||||
Process#
Process Definition
|
status: draft
|
||||
Process definitions. |
|||||
Process Improvement Report
|
status: draft
|
||||
Process improvement report. |
|||||
Process Management Strategy
|
status: draft
|
||||
Plan to manage and guide execution of the process management activities. |
|||||
Product development#
Platform development#
Feature Safety Analyses
|
status: draft
|
||||
Bottom-Up Safety Analysis with e.g. FMEA method, verifies the feature architecture (as part of SW Safety Concept) - Detection and prevention mitigations linked to Software Feature Requirements or Assumptions of Use |
|||||
Feature DFA
|
status: draft
|
||||
Dependent Failure Analysis on platform/feature level - Detection and prevention mitigations linked to Software Feature Requirements or Assumptions of Use Perform analysis on interactions between safety related and non-safety related modules or modules with different ASIL of one feature. Including potential influences from the rest of the SW platform. |
|||||
Platform Build Configuration
|
status: draft
|
||||
Build configuration capable to create the SEooC Library for the reference HW, platform level. Note: Embedded software in the sense of the Iso (i.e. deployed on the production HW) is not part of our delivery. |
|||||
Platform Release Notes
|
status: draft
|
||||
Release notes describe the qualified SW version including known bugs from own testing and field reporting, with clear statement, that these bugs do not lead to violation of any safety requirements or with corresponding workaround measures. Platform level. |
|||||
Component development#
Hardware-software interface (HSI) specification
|
status: draft
|
||||
The HSI specification shall specify the hardware and software interaction and be consistent with the technical safety concept.
The HSI specification shall include the component’s hardware parts that are controlled by software and hardware resources that support the execution of the software.
|
|||||
Component Safety Analyses
|
status: draft
|
||||
Bottom-Up Safety Analysis with e.g. FMEA method, verifies the component architecture (as part of SW Safety Concept) - Detection and prevention mitigations linked to Software Component Requirements or Assumptions of Use |
|||||
Component DFA
|
status: draft
|
||||
Dependent Failure Analysis on component/module level - Detection and prevention mitigations linked to Software Component Requirements or Assumptions of Use Perform analysis of safety related and non-safety related sub-elements or sub-elements with different ASIL. Perform analysis on interactions between safety related and non-safety related sub-components or sub-components with different ASIL of one component. Including potential influences from the other components in the component’s module. |
|||||
Architecture Verification
|
status: draft
|
||||
Depends on architecture, FMEA and DFA tooling. May include several methods like inspection, modelling … Which are selected in SW Development Plan. |
|||||
Implementation
|
status: draft
|
||||
Implementation includes source code and detailed design (e.g. in form of comments or linked graphical representations) and SW configuration (e.g. #ifdef) The “how to” is described in the SW Development Plan guidelines |
|||||
Code Inspection
|
status: draft
|
||||
github review with integrated inspection checklist (includes manual checking of coding guidelines) |
|||||
Module Build Configuration
|
status: draft
|
||||
Build configuration capable to create the SEooC Library for the reference HW, module level. Note: Embedded software in the sense of the Iso (i.e. deployed on the production HW) is not part of our delivery. |
|||||
Module Release Notes
|
status: draft
|
||||
Release notes describe the qualified SW version including known bugs from own testing and field reporting, with clear statement, that these bugs do not lead to violation of any safety requirements or with corresponding workaround measures. Module level. |
|||||
Supporting activities#
Software tool criteria evaluation report
|
status: draft
|
||||
According to the tool evaluation process, each tool’s confidence level (TCL) must be determined. Based on TCL the appropriate qualification methods shall be applied. |
|||||
Note: All the work products are set to status “draft”, as the linkage to standard requirements is missing currently on purpose, namely to those of ISO 26262.