Workproducts#
Fig. 5 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
|
|||||
Issue tracking system
|
status: draft
|
||||
- Identified safety anomaly reports
- Change requests (= Contribution Request)
- Impact analysis
- change request plan
- Change report
Safety anomaly: Conditions that deviate from expectations and that can lead to harm.
The documentation of a change shall contain the list of changed work products, the details of the change and the planned date of deployment of the change.
|
|||||
Feature Request
|
status: draft
|
||||
- Feature request
- Change request
|
|||||
Platform Management Plan
|
status: draft
|
||||
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 Architecture
|
status: draft
|
||||
Feature Architecture linked to Feature Requirements, i.e. interaction of components - Static view (UML) - Feature interfaces (to outside of Feature) and Interfaces between own Components - Dynamic view (UML) - Sequences of component interactions and state diagrams Technical concept on platform level. |
|||||
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. |
|||||
Feature Integration test
|
status: draft
|
||||
Integration Testing verifies feature requirements and architecture: - all interfaces from Static view and - all flows from Dynamic View and - performance: i.e. RAM and processor usage on reference HW |
|||||
Platform test
|
status: draft
|
||||
Platform Testing verfies Stakeholder Requirements performed on reference HW |
|||||
Platform Verification Report
|
status: draft
|
||||
Verification Report contains: - List of requirements (and architecture/detailed design tags) tested by which test (can be several levels), passed/failed and completeness verdict, including normal operation and failure reactions - The list of requirements may also contain other verification methods like “Analysis” - Formal evidence about the preformed DFA. - Formal evidence about the performed Safety Analyses |
|||||
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#
Component Requirements
|
status: draft
|
||||
SW Requirements for own and OSS qualified components/libraries. QM and ASIL requirements are distinguished by attributes/tags.
|
|||||
Component Assumptions of Use
|
status: draft
|
||||
SW Safety Requirements for the user of the component, exportable requirements for the user to integrate in their req mgt system. |
|||||
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.
|
|||||
Requirements Inspection
|
status: draft
|
||||
Depends on requirements management tooling, expect text based requirements maintained in git.
- github review with integrated inspection checklist, only valid requirements get merged
Compare also Gitub documentationt
|
|||||
Component Architecture
|
status: draft
|
||||
Component Architecture linked to Component Requirements - Static view (UML) - Component interfaces (to outside of Component) and Interfaces between own Sub-Components - Dynamic view (UML) - Sequences of Sub-Components interactions and Components States Note: In case no sub-components exist, this can be covered by Detailed Design (in “Implementation” workproduct) |
|||||
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 |
|||||
Unit test
|
status: draft
|
||||
Unit testing verifies component requirements and detailed design (traced to). Tooling defined in SW Development Plan and integrated in CI/Build. |
|||||
Code Inspection
|
status: draft
|
||||
github review with integrated inspection checklist (includes manual checking of coding guidelines) |
|||||
Module Verification Report
|
status: draft
|
||||
Verification Report contains: - List of requirements (and architecture/detailed design tags) tested by which test (can be several levels), passed/failed and completeness verdict, including normal operation and failure reactions - The list of requirements may also contain other verification methods like “Analysis” - Structural Coverage (C0 and C1, from unit testing on host) per unit - Static Code Analysis (including compiler warnings, automated checking of coding guidelines and additional checks) - Formal evidence about the preformed DFA. - Formal evidence about the performed Safety Analyses - Software component qualification verification report |
|||||
Component Integration test
|
status: draft
|
||||
Integration Testing verifies component architecture: - all interfaces from Static view and - all flows from Dynamic View and performance: i.e. RAM and processor usage on reference HW |
|||||
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. |
|||||
Component test
|
status: draft
|
||||
Component Testing verifies Component Requirements |
|||||
Supporting activities#
Verification Plan
|
status: draft
|
||||
Verification planning for each phase of the safety lifecycle must detail the work products, objectives, methods, criteria, environments, equipment, resources, actions for anomalies, and regression strategies, considering method adequacy, complexity, prior experiences, and technology maturity or risks. |
|||||
Verification Specification
|
status: draft
|
||||
The verification specification must outline the verification methods, including review or analysis checklists, simulation scenarios. Test cases, test data, and test objects are part of the respective test WPs. |
|||||
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.