Category Archives: DO-278A

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.


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.


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.



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.

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)



Two styles of FMEA

SAE J1739 is a FMEA standard, whose title is “Potential Failure Mode and Effects Analysis in Design (Design FMEA), Potential Failure Mode and Effects Analysis in Manufacturing and Assembly Processes (Process FMEA)”

If you look a structure of a FMEA sheet, then there is a column “cause”.  and if you proceed to follow, there is a column “prevention”, “detection”, or “recommended action”.

Sample style can be found in google. Ex)


In this style, safety mechanisms are considered in the lower level of potential failure mode. I.e, safety mechanisms are not considered in the identified potential failure mode, but are considered in the cause level of the potential failure mode.

Is it different? Yes, I think so.

I doubt that we can find all kinds of causes that trigger potential failure mode. It means that we just find key causes that can be triggered to potential failure mode.

Even though we have corresponding safety mechanisms for key causes, the potential failure mode can be triggered because of latent faults.

As a result, My opinion is that…

if it is applicable, safety mechanisms are better to be considered in the potential failure mode level not in the cause of the potential failure mode level.

To apply this approach, this format needs to be tailored.

And one more comment is that..

I understand that finding causes are beneficial. Then please try to design hierarchically and apply FMEA in multi-stage way. It is more powerful.

For more detail, please refer to “ECSS-Q-ST-30-02C”