Workproducts#
Fig. 2 Project development work product traceability model#
Platform management#
General#
Policies
|
status: draft
security:
safety:
|
||||
Organization-specific rules and processes for functional safety and cybersecurity. |
|||||
Training path
|
status: draft
security:
safety:
|
||||
Evidence of competence management. |
|||||
Quality management system
|
status: draft
security:
safety:
|
||||
Evidence of quality management. |
|||||
Quality report
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
- 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
security:
safety:
|
||||
- Feature request
- Change request
|
|||||
Platform Management Plan
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
Process definitions. |
|||||
Process Improvement Report
|
status: draft
security:
safety:
|
||||
Process improvement report. |
|||||
Process Management Strategy
|
status: draft
security:
safety:
|
||||
Plan to manage and guide execution of the process management activities. |
|||||
Safety#
Platform Safety Plan
|
status: draft
security:
safety:
|
||||
Plan to manage and guide the execution of the safety activities of a project including dates, milestones, tasks, deliverables, responsibilities (including the Safety Manager appointment) and resources. Guidelines on how an impact analysis shall be concluded on each item or element involved together with it’s connected items or elements. This is on following level: - Project/Platform (contains definitions how safety planning is performed generally in the project) |
|||||
Module Safety Plan
|
status: draft
security:
safety:
|
||||
Plan to manage and guide the execution of the safety activities of a project including dates, milestones, tasks, deliverables, responsibilities (including the Safety Manager appointment) and resources. Guidelines on how an impact analysis shall be concluded on each item or element involved together with it’s connected items or elements. This is on following level: - Project/Platform (contains definitions how safety planning is performed generally in the project) - Module (contains activities planning based on a Contribution Request) |
|||||
Platform Safety Case
|
status: draft
security:
safety:
|
||||
Argument that functional safety is achieved for items, or elements, and satisfied by evidence compiled from work products of activities during development. For Platform SEooC. |
|||||
Module Safety Case
|
status: draft
security:
safety:
|
||||
Argument that functional safety is achieved for items, or elements, and satisfied by evidence compiled from work products of activities during development. For Module SEooC. |
|||||
Confirmation Review Reports
|
status: draft
security:
safety:
|
||||
Confirmation that a work product provides sufficient and convincing evidence of their contribution to the achievement of functional safety considering the corresponding objectives and requirements of ISO 26262. Will contain confirmation review report for Safety Plan, Safety Case, Safety Analyses and Dependent Failure Analyses (DFA) |
|||||
Functional Safety Assessment Report
|
status: draft
security:
safety:
|
||||
Examination of whether a characteristic of a component achieves the ISO 26262 objectives and examination of an implemented process with regard to the process objectives. |
|||||
Product development#
Platform development#
Stakeholder Requirements
|
status: draft
security:
safety:
|
||||
Technical requirements from a stakeholder viewpoint and Assumptions of use based on the integration as SW platform SEooC in an assumed context. |
|||||
Tool Requirements
|
status: draft
security:
safety:
|
||||
SW Requirements for tools to ensure automatic enforcement of rules and as input for software tool qualification. |
|||||
Feature Requirements
|
status: draft
security:
safety:
|
||||
SW Requirements describing in a more detailed way the functionality which will fulfill a set of stakeholder requirements. A “feature” consists of a set of requirements. These feature requirements shall also be the basis for integration testing on platform level. |
|||||
Feature Assumptions of Use
|
status: draft
security:
safety:
|
||||
SW Safety Requirements for the user of the feature, exportable requirements for the user to integrate in their req mgt system. |
|||||
Platform Safety Manual
|
status: draft
security:
safety:
|
||||
The safety manual exists for every SEooC/qualified component. It describes: - The Assumed Platform Requirements (Safety related); - the safety concept of the SEooC (i.e. which faults are taken care of); - the Assumptions of Use (of the features); - a link to the user manual; - the reactions of the implemented functions under anomalous operating conditions; and - a description of known anomalies with corresponding workaround measures. This is on platform level. |
|||||
Feature Architecture
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
Platform Testing verfies Stakeholder Requirements performed on reference HW |
|||||
Platform Verification Report
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
SW Requirements for own and OSS qualified components/libraries. QM and ASIL requirements are distinguished by attributes/tags.
|
|||||
Component Assumptions of Use
|
status: draft
security:
safety:
|
||||
SW Safety Requirements for the user of the component, exportable requirements for the user to integrate in their req mgt system. |
|||||
Module Safety Manual
|
status: draft
security:
safety:
|
||||
The safety manual exists for every SEooC/qualified component. It describes: - The Assumed Platform Requirements (Safety related); - the safety concept of the SEooC (i.e. which faults are taken care of); - the Assumptions of Use (of the modules’s components); - a link to the user manual; - the reactions of the implemented functions under anomalous operating conditions; and - a description of known anomalies with corresponding workaround measures. This is on module level. |
|||||
Hardware-software interface (HSI) specification
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
Depends on architecture, FMEA and DFA tooling. May include several methods like inspection, modelling … Which are selected in SW Development Plan. |
|||||
Implementation
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
github review with integrated inspection checklist (includes manual checking of coding guidelines) |
|||||
Module Verification Report
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
Component Testing verifies Component Requirements |
|||||
Software component classification
|
status: draft
security:
safety:
|
||||
The classification shall include: - the unique identification of the pre-developed software component; - the maximum ASIL of the safety requirements allocated to it; - a development processes analysis; and - a complexity analysis of the pre-developed SW component; and - finally a SW component classification as input for the safety planning (which is to cover the determined gaps, if any, by additional verification measures). |
|||||
Supporting activities#
Verification Plan
|
status: draft
security:
safety:
|
||||
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
security:
safety:
|
||||
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
security:
safety:
|
||||
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. |
|||||
Tailoring#
Tailoring Documents
|
status: draft
security:
safety:
|
||||
This workproduct argues why some workproducts are not needed in the project. It may have several levels: - Project/Platform - Feature/Component It belongs to the Safety Plan. |
|||||
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.