The final requirements are assembled from analysis and elicited requirements from earlier phases. These requirements are broken down for the intended architecture of the system. The expected behavior drives hardware and software requirements that are documented at a high level to allow an ECU architecture to be developed, and high-level design to begin. As work progresses these requirements will be distilled into increasing levels of detail, and driven by the rigor that’s expected based on the safety criticality of the controller
System architecture is a representation of the system under development that includes the mapping of functionality into both the hardware and software components. It is a mapping of the software architecture onto the hardware architecture and captures the external interactions with these components.
For ISO 26262 functional safety projects, the components, signals and functions, and the corresponding architecture requirements are be assigned appropriate ASIL ratings that need to be met.
For all projects (prototype and production), Pi Innovo works with the customer to create a system architecture diagram showing all the elements of the system and defines a set of architecture requirements that describe the rules governing the relationships between the elements. These requirements specify the inputs and outputs of the elements and timing dependencies between them.
For ISO 26262 projects, the high-level system architecture is analyzed for impact on the safety goals determined from the HARA. The Functional Safety Requirements (FSRs) establish how the elements in the system provide diagnostics for and mitigation of faults that could violate the safety goals. Safety analyses are performed to demonstrate that the functional safety requirements and overall functional safety concept satisfy the safety goals. At the FSR level, typically qualitative FMEA and FTA are the tools of choice to analyze the Functional Safety Concept (FSC) against the HARA.
The FSC allocates functional safety requirements to the elements and cascades ASIL ratings to those elements.
Although Pi normally expects the FSC to be provided by the vehicle integrator, Pi has developed FSCs for several programs and provides review or development support at this design level.
The Technical Safety Requirements (TSRs) and subsequent Technical Safety Concept (TSC) define the how requirements and overall design to satisfy the requirements defined in the Functional Safety Concept. The TSRs and TSC are companion documentation to the System Design Specification.
The TSRs and TSC refine and allocate the requirements of the FSC to specific hardware and software elements, define specific interface requirements, and define the details of the safety mechanisms of each element. Analysis tools such as qualitative FMEA and FTA are used to verify that the TSRs and TSC satisfy the higher-level safety requirements and concept.
TSRs and TSC may be presented in several hierarchical levels. Typically, Pi expects to receive a set of TSRs and TSCs that have been allocated to the Pi module and then Pi develops the next level of TSRs and TSCs that are internal to the module.
Item-level verification plans are developed in parallel with the TSRs and TSC and documented in the Item Integration and Testing Plan.
The System Design Specification in the ISO 26262 model encompasses both the Technical Safety Concept and the non-safety-related aspects of the design. This entirety of the system design specification is used to produce both the hardware and software requirements.