Specification of Safety Requirements

In the ISO 26262, there are 4 kinds of safety requirements – FSR, TSR, SSR and HSR. But I’d like to recommend that you don’t have to divide into 4 pieces exactly.

FSR can be defined conceptually from customer side, and safety requirements can be identified for supplier side. If system is complex (i.e, a system of systems) it can be possible to consider a system that consists of sub-systems that consists of TSR, SSR and HSR. In this case, it is not a good practice just to think that level of safety requirements are system level, SW and HW level. if you have such category, it will prohibit to manage safety requirements. Managing in the unit of sub-system is easier.

To specify safety requirements, it should be identified from product requirements.

Reference;

• Identification of Safety requirements in a product requirements
• Meaning of safety requirements

if they are identified, then detailed review with safety aspect should be perform (so we call it safety analysis)

Proper fault model and fault propagation model is prerequisite to conduct it.

Reference;

• Safety Use Case Example – AUTOSAR

After impact of considered failure mode, remedy(safety mechanisms, or additional processes) needs to be decided. So how to detect faults and how to handle faults should be considered.

Reference;

• Explanation of Error Handling on Application Level – AUTOSAR

 

All of safety mechanisms needs to be traceable to results of safety analysis, and all of evidence for identified additional processes needs to be traceable. They are required in order to build safety case.

Specification for A-SPICE or ISO 26262

In the A-SPICE, there are various kinds of requirements; System Requirement, System Design, SW Requirement, SW architecture, SW Unit design. ISO 26262 requires similarly .

To manage traceability rigid decomposition of requirements into these are beneficial.

You can integrate all kinds of requirements into one documents. Then you will face a fact that managing traceability is not a easy task.

To specify, it requires different kinds of technical skills. It is not related engineering knowledge. It is closely related to logical thinking and writing technique.

You may wonder if I emphasize that writing technique is core skill to comply engineering process, because writing technique seems not to be related to engineering knowledge.

To Know it and to explain what you know are different. Sometimes it takes much time or infinite time to understand a document, because it is hard to understand.  Requirement obfuscation is not good for team’s productivity and team’s communication. It also makes hard to achieve A-SPICE or functional safety standard.

So, engineers are required to learn how to specify requirements. It shall be educated.

To engineers, please do not blame readers because of their poor engineering knowledge, and do not think that it is a reason they do not understand your document. It is not good.

For reference,

1. Requirements_Engineering_Management_Handbook explains how to specify requirements.
2. safety driven model based system engineering methodology(Part 1, Part 2) shows example.
3. AUTOSAR Use Case Example CP Release 4.3.1

 

Why do you think that SW codes should be implemented after unit design is finished?

DO-178C basis, it is very good practice. In the standard there are SW HLR(high level requirements), and SW LLR(Low level requirements).

But A-SPICE and ISO 26262 basis, 3 steps of process are considered. SW Requirement, SW Architecture, and SW Unit design.

I prefer DO-178C to A-SPICE, because it feels natural to me.

There are so many good practices. Waterfall development model, Agile development model, DO-178C, and A-SPICE. They are not consistent.

When they have a belief that SW codes should be developed after unit design is finished as standard specified, such a rigid question during a design review is a burden to me.

Refer to development life cycle model(in Korean)