Category Archives: DO-178C

Safety Analysis depends on what you contain in the Architecture. So…

Assuming that FMEA and FTA can be generated from Architecture(Sys/EE/SW), quality and depth of safety analysis depends on what you decide to cover in the architecture.

If your architecture is too detailed contents, then it would be labor intensive work. In the SW safety analysis, detailed SW safety analysis is not recommended. For example, ISO 26262 does not require that variable level fault mode has to be considered. If you refer to some papers, you can see such approaches. They always tell us that such task is time consuming work.

In the sense, granularity of architecture is so important. Because FMEA and FTA are different shapes of the diagram for chosen architecture view point, it is so important what kinds of view point has to be necessary.

If you refer to these safety analysis results to specify safety requirements, it will be clear why this requirement is safety related requirements.

While system in the automotive and aircraft vehicle focus on engineering methods to control vehicle, but socio-technical systems such as CNS/ATM system additionally requires related operation process. In this case, FTA and FMEA can enlarge to the operation process scope.

If you understand the principle, it can be applied to different domains.

Thus, important thing is how to determine what contents have to be contained, and how deep it has to be specified. It sounds like boring, but if you do not consider very carefully, you will have poor results even though you spend too much time.

In general, this consideration is functional safety manager’s role. On the contrary, functional safety engineer who knows deep knowledge about product would be hard these determination. Such person is apt to cover contents that does not have to be covered in the safety analysis.

So such policy is necessary. and it has to be determined by functional safety manager and agreed by related functional safety engineers. If there is no policy, you will face overlapped specification among system, SW and EE level.



Similarity between Academic paper and Requirements

When researcher writes academic paper, one of important thing is to make structure. Usually research is one’s own study so it is hard to understand for people who are not interested in the topic. So s/he has to consider how to reader can understand easily.

S/he also consider internal consistency for better understanding.

I realized that writing requirement is quite similar to write an academic paper. If requirements are written without consideration of structure, it is hard to understand. Readers cannot understand what are system’s sub systems, what are functions allocated to sub-systems.

It is not technical point of view. But if they are not clear it is hard to defense against audit, because auditor will confuse it and will not understand what you are saying.

Then s/he will not give a good grade.



Certification Liaison Process

This process is specified in DO-178C. It is a kind of communication process with Certification Authority. It is very important for suppliers to get a good results. I’ve never  experienced about type certification or airworthiness certification, but I think that I can imagine the procedure because there are published document.

Though it is natural to think, applicant has to submit safety plan to certification body and it can be proceed if the plan is approved by certification authority.

It would be ridiculous if applicant submit safety plan in the middle of the project. What if the plan is rejected? Everything they have done so far must be dumped.

Unfortunately this process is not defined in the automotive, but it also essential for supplier. Competent OEM may have a detailed process for audit and assessment.

You can also refer a book, “Developing Safety-Critical Software(DO-178C)” in chapter 12

Developing Safety-Critical Software(DO-178C)에 대한 이미지 검색결과