View Points in the Architecture

Purpose of the design is to help stakeholders to understand author’s intent. To do this, having several view points are necessary. But what happens if an author tries to contain all knowledge in one view?

As I know, an engineers knows too much and it prohibit him to explain simply. She/He might think that the reason the other persons do not understand her/his documents is humble knowledge that readers have. It may be true, but too much information do not help readers to understand author’s point.

To achieve this, proper abstraction is necessary. Less important parts are recommended to be deleted to help reader’s understanding. Or proper hierarchical structure helps readers to understand.

When we think why this documents are existing, purpose of the document is to let others understand author’s point. By the reason, viewpoints are necessary.

When we consider a design in the system level, he/she wants to communicate to hardware and software team. As you know, One to One communication is better than multi to multi. System designer’s point of view, a viewpoint specific to software is easy to communicate than a viewpoint to all.

And many contents are contained in the design, readers don’t like to read because too much information is contained. They will lost their concentration and miss some contents. This situation will not be what the author want to.

Do not try just to contain all knowledge that you know in the design. Functional safety manager has to help engineers to write documents by guidelines, policies. In the functional safety standards, not only system design but also SW/HW design is required. To have balance between system, SW and HW design, structure and contents detail level needs to be considered. And proper viewpoints are required to guide engineers’ documentation.

As I emphasized in the previous post, scope of safety analysis depends on what engineers contain in the design document. If they omit some view points, safety analysis for the missed contents cannot be analyzed.

 

Related Article(in Kor)

• 소프트웨어 설계와 추상화
• System, Software 및 요구사항 및 설계의 경계를 명확하게 정하기
• SW requirement와 SW design의 경계
• ISO IEC 42010 Recommended Practice for Architectural description
• IEEE-Std-1016-2009 Systems Design — Software Design Descriptions

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.

 

Functional safety manager can’t assure that this product is safe. instead, he/she knows that it is not safe.

There is saying about interview. An interviewer cannot make a interviewee be hired but can make him/her failed to be hired. I believe that this is true and a similar correspondence can be possible in the functional safety project.

I review functional safety documents frequently, and functional safety scope is too vast for one person to know everything fully so I sometimes conduct incomplete review. Incomplete review means that even though I approve it, it cannot be ensured that it is fully achieved.

Because I understand my weakness, I tried to find nonconformances in the documents. At least I’m first auditor in this project. And if I don’t agree, then it cannot be proceed. In the near future, I have to respond against customer auditor’s questions. There should be some layers of reviewers like me. They act as if ‘safety-nets’ in the project, and they protect systematic faults in the project.

Final reviewer shall be customer side auditors(or assessors). In some ways, customer have to not only have a deep knowledge about product knowledge but also have a deep technical functional safety knowledge. If a person does not have both, team has to be arranged. And who does not have a deep knowledge about the project but has a functional safety knowledge has to enough review experience whether the product under review is well documented or not. And he has to help a customer side product champion to determine whether supplier’s safety concepts or their approaches are good to satisfy their safety requirements.

But…. even though they conduct such audit or assess, they cannot ensure that safety is fully achieved.