Category Archives: project management

Fault injection test vs safety analysis


What do you think the purpose of the fault injection test is? Why do safety analysis?

Why do I talk these two together? Of course they are related.

In conclusion, the list or type of faults required in the fault injection test and the location and timing of the fault injection should be based on the results obtained during the safety analysis.

Suppose we have identified a list of faults that affect the safety performed in the safety analysis, and we have identified how to handle such faults as safety requirements (we call this the safety mechanism).

How can you verify them? Naturally, you will have to create a condition for the safety requirement to become active, which is the situation where the fault is injected.

So the two are related.


fault injection test의 목적이 무엇이라고 생각하는가? safety analysis는 왜 하는가? 왜 나는 이 둘을 엮을라고 하는 것인가? 당연히 관련성이 있기 때문에 그런 것이다

결론을 말하면 fault injection test에서 필요한 fault의 list나 type 및 fault를 injection하는 위치나 시점 등은 safety analysis에서 수행하는 동안 얻은 결과를 바탕으로 해야 한다.

safety analysis에서 수행한 안전에 영향을 끼치는 fault list를 식별을 했고, 그런 fault들을 처리하는 방법을 안전 요구사항으로 식별했다고 치자(우리는 이것을 안전 매커니즘이라고 부른다.)

여기서 그 안전 매커니즘에 대한 검증을 어떻게 할 것인가? 당연히 safety requirement가 활성화되기 위한 조건을 만들어줘야 할 것이다, 그것이 바로 fault가 inject된 상황이 된다.

그래서 둘은 이렇게 연관이 있다.

Failure Mode Avoidance


It is a framework for developing systematic system modeling, safety analysis and safety mechanisms. If you search the data, you will find several papers. Interested in the overall content of this framework, detailed data were not available, so that the whole was not understood.

For a complete picture, see the data at
https://www.through-life-engineering-services.org/downloads/campean.pdf.

If you look at this data you can get a sense of the approximate flow.

In the figure below, there are four steps, and the first step is to analyze the function. To do this, define the state of the system at the top level, identify the environment involved, and define the interface. Based on this analysis, we create a function decomposition tree. Personally, I have used function decomposition from other sources, and when I looked at the paper, I thought it was a good practice.

State flow diagrams may be hierarchical diagram in the stateflows or in the statecharts. Another useful point here is interface analysis and boundary analysis. It may not be necessary if you analyze and develop the system by yourself, but if you need to work together, I think it is necessary.

Surprisingly, other people’s minds are not the same as mys, and if you pretend that they are clearly defined in scope, others are often not. Therefore, it is necessary to define clearly. It is also needed to split the system up and hand it over to another department. At this point, what matters is the boundaries, clearly defining what is ambiguous, and therefore need an interface.

Based on these analyzes, we define the decomposition of the function. Functions can be considered as requirements. This enables the representation of requirements and system components to which they are assigned. In this case, if the system function is complicated, it can be expressed hierarchically and expressed in multi level instead of one level. In other words, if the system architecture is organized hierarchically, it is much clearer and more intuitive to configure the corresponding requirements hierarchically. Of course, you will also need to define interfaces for each layer.

That’s the first stage of functional analysis,

Next is the functional failure analysis phase, FMEA. The FMEA is taken at the same hierarchy level as the previous step. Then, in step n, the influence on the failure mode of the element E is configured to be associated with the failure mode of the upper element E_upper in step n-1. That way the FMEA can be configured to allow the fault to be propagated.

This is what I found through FMA and I haven’t confirmed any details since P diagram.

FMA-related papers(not exhaustive)

  1. Systems Engineering Design Through Failure Mode Avoidance: An Automotive Industry Perspective
  2. 2014-01-0740 A Systems Approach to the Development and Use of FMEA in Complex Automotive Applications
  3. 2011-01-1268 A Structured Approach for Function Analysis of Complex Automotive Systems
  4. 2009-01-0990 Implementing Failure Mode Avoidance

To implement this concept it is possible to implement to some extent using the medini tool. Although some of medini’s features are lacking, some of the activities needed during the system analysis phase can be covered. I don’t know how useful other tools are, so medini is a great tool.

 

 

 

FMA는 체계적인 시스템 모델링 및 안전분석, 안전 매커니즘을 개발하기 위한 프레임워크이다. 자료를 검색해보면 여러 paper들이 나온다. 이 framework에 대한 전반적인 내용에 관심이 생겼으나, 자세하게 다룬 자료는 구하지 못해서 전체적인 것을 파악하지는 못하였다.

전체적인 그림은 https://www.through-life-engineering-services.org/downloads/campean.pdf에 있는 자료를 보면 대략적인 flow는 감을 잡을 수 있을 것이다.

아래 그림을 보면 4 단계로 이루어져 있고, 첫번째는 기능을 분석하는 단계이다. 이것을 위해서 top level에서 시스템의 상태를 정의하고, 관련 환경을 파악하고 인터페이스를 정의한다. 그리고 이 분석한 내용을 바탕으로 function decomposition tree를 만든다. 개인적으로 다른 자료를 통해 function decomposition을 활용해 봤고, 그 논문을 봤을때부터 이건 괜찮은 practice라고 생각을 했었다.

state flow diagram은 아마도 stateflow나 statecharts로 hierarchical하게 표현을 해도 괜찮을 것이다. 여기서 또 유용하다고 생각되는 점은 interface analysis와 boundary analysis이다. 혼자 시스템을 분석하고 개발한다면 굳이 필요하지는 않을지도 모르나, 여럿이서 협업을 해야 한다면 반드시 필요한 작업이라고 생각된다,

의외로 다른 사람의 마음은 내 마음과 같지 않고, 척하면 범위가 명확하게 정의가 되었다고 생각하는데, 다른 사람들은 그렇지 않을 때도 많다. 그렇기 때문에 명확하게 정의하는 것이 필요하다. 시스템을 쪼개서 다른 부서에 넘겨줄 때에도 필요하다. 이 때에 중요한 것이 경계상에 있는 것들이다, 애매할 수 있는 것들을 명확하게 정의해야 하고, 그런 이유로 인터페이스가 필요하다.

이런 분석들을 기반으로 기능에 대한 decomposition을 정의한다. 기능은 요구사항으로 간주할 수 있다. 그렇게 되면, 요구사항과 그 요구사항이 할당된 시스템 구성요소를 표현할 수 있게 된다. 여기서 시스템의 기능이 복잡한 경우 하나의 수준으로 표현하지 않고 계층적으로 구성해서 multi level로 표현할 수 있다. 즉, 시스템 아키텍처를 계층적으로 구성한다면 그에 걸맞는 요구사항도 계층적으로 구성하는 것이 훨신 명확하고 직관적이다. 물론 각 계층마다 인터페이스에 대한 정의도 필요할 것이다.

여기까지가 첫번째 단계인 기능 분석 단계이다,

다음으로는 기능 고장 분석단계인데, FMEA이다. FMEA는 이전 단계에서 수행했던 계층 수준과 동일하게 가져간다. 그리고, n단계에서 어떤 엘리먼트 E의 고장 모드에 대한 영향이 n-1단계의 상위 엘리먼트 E_upper의 고장 모드와 연계되도록 구성한다. 그런식으로 fault가 propagation될 수 있도록 FMEA가 구성될 수 있도록 분석을 한다.

여기까지가 내가 FMA를 통해 파악한 내용이고 P diagram이후부터는 아직 구체적인 내용을 확인하지 못했다.

FMA와 관련된 참고자료(일부분만)

  1. Systems Engineering Design Through Failure Mode Avoidance: An Automotive Industry Perspective
  2. 2014-01-0740 A Systems Approach to the Development and Use of FMEA in Complex Automotive Applications
  3. 2011-01-1268 A Structured Approach for Function Analysis of Complex Automotive Systems
  4. 2009-01-0990 Implementing Failure Mode Avoidance

이런 concept을 실행하기 위해 medini도구를 사용하여 어느 정도는 구현하는 것이 가능하다. medini의 기능 중 일부분이 부족한 점이 있기는 하지만, 시스템 분석 단계에서 필요한 활동들은 어느정도 커버할 수 있다. 다른 도구는 사용해 본 적이 없어서 얼마나 유용한지는 모르겠지만, medini는 정말 훌륭한 도구이다.

(Paper Comment) Integrated Safety and Security Development in the Automotive Domain


이 논문을 한마디로 요약하자면, FuSa+Cyber Security계의 광맥이라고 볼 수 있겠다.

이 논문의 focus는 시스템 안전성과 사이버 보안을 독립적이 아닌 결합하여 해결함으로써 상호 영향에 대한 인식을 높이는 데 있다고는 되어 있기는 하지만, 사실 굉장히 방대하게 cover를 하고 있고, 관련 연구를 reference를 달고 있다.

읽고나서는 우와~ 하게 되지만 한마디로 요약하라고 한다면.. 딱히 어떻게 설명하기가 애매.

어쨌거나 유용하다고 생각되는 reference들을 정리하기로 한다.

여기 reference되어 있는 것들 중에 뭘 처음부터봐야 할 지가 심히 고민된다….(왜 이렇게 많아..)

 

Gashi [12]의 연구는 중복성, 다양성 및 임베디드 시스템의 안전 및 보안에 미치는 영향에 중점을 둡니다. 이 작업은 SeSaMo (임베디드 시스템의 보안 및 안전 모델링) 프로젝트의 일부이며, 구체적인 사용 사례를 통한 보안과 안전의 시너지 효과와 상충 관계에 중점을 둡니다.

12. Gashi I., Povyakalo A., Strigini L., Matschnig M., Hinterstoisser T., and Fischer B.. „Diversity for Safety and Security in Embedded Systems”. In International Conference on Dependable Systems and Networks, volume 26, 2014

http://sesamo-project.eu/documents

 

최신 ESCL 시스템은 명백한 안전 및 보안 관련 특성과 시스템 요소, 기본 기능 및 관련 외부 시스템과 관련하여 관리 가능한 복잡성으로 인해 대표적인 안전 및 보안 관련 사용 사례입니다.

따라서 이 사용 사례는 교육 목적으로도 사용되며 철저하거나 상업적으로 민감한 프로젝트를 나타내지 않습니다. 제시된 유스 케이스는 SoQrates 이니셔티브와 긴밀히 협력하여 정교하게 작업되었으며, 주요 작업 그룹의 여러 주요 자동차 공급 업체의 전문가를 통합합니다 [24].

  1. http://soqrates.eurospi.net/

 

 

Initial Cybersecurity and Safety Assessment

사이버 보안 위협 및 안전 위험에 대한 초기 평가를 위해 HARA와 TARA를 결합한 SAHARA 방법 [19]을 적용했습니다. SAHARA 방법의 개념 세부 사항과 ESCL에 대한 자세한 응용 프로그램은 [25]에서 찾을 수 있습니다.

[25] Integrating HARA and TARA – How does this fit with Assumptions of the SAE J3061

 

Security-by-Design
[27]에 따르면 설계별 보안에는 다음과 같은 모범 사례가 포함됩니다.
· 초기 개발 단계 및 주요 개발 단계 (주로 설계 결정이있는 단계)에서 보안 위험 고려
· 잠재적 위협 및 공격 대상 식별 및 해결
· 적절한 공격면(attack surface reduction) 축소 방법
· 계층화 된 사이버 보안 방어 (심층 방어)
· 신뢰 경계 식별
(생략)

27. Automotive Information Sharing and Analysis Center AUTO-ISAC, “Automotive Cybersecurity Best Practices Executive Summary”, 2016

 

 

Layered Cybersecurity Defense (Defense-in-Depth)
심층 방어 접근 방식의 기본 개념은 몇 가지 독립적인 방법을 사용하여 특정 공격으로부터 시스템을 방어하는 것입니다. 계층 중 하나라도 보호에 실패하면 다음 계층이 보호를 제공합니다. 이러한 아키텍처 심층 방어 접근법은 일반적으로 [28, 29]에 의해 자동차 시스템 및 특히 [30]에 의해 차내 인포테인먼트 시스템에 대해 제안된다.

  1. Brown D., Cooper G., Gilvarry I., Rajan A., Tatourian A., Venugopalan R., Wheeler D., and Zhao M., “Automotive Security Best Practices,” White Paper, 2015

  2. Hahn, T.; Matthews, S.; Wood, L.; Cohn, J.; Regev, S.; Fletcher, J.; Libow, E.; Poulin, C. & Ohnishi, K. “IBM Point of View: Internet of Things Security”, 2015.

 

 

 

Identification of Trust Boundaries
신뢰 경계 식별을 지원하기 위한 적절한 체계적인 접근 방식이 필수적입니다. [32]에서는 ISO 26262 기능 안전 개발 프로세스의 중심 개발 아티팩트 인 하드웨어 소프트웨어 인터페이스 (HSI)를 기반으로하는 신호 인터페이스를 통해 복잡한 시스템에서 신뢰 경계 및 공격 벡터를 식별하는 방법을 제안합니다. 이것은 앞에서 언급 한 계층화 된 사이버 보안 방어 접근 방식의 개념을 따릅니다.

  1. Macher, G.; Sporer, H.; Brenner, E. & Kreiner, C. “Supporting Cyber-security based on Hardware-Software Interface Definition Systems”, Software and Services Process Improvement – 23nd European Conference, EuroSPI 2016 Proceedings, Springer, 2016.

현재 보안 설계 조정에 대한 표준화가 확립되지 않았으며 보안 컨텍스트를 제공하는 방법을 결정하는 것은 제조업체의 책임입니다. ECSL의 경우 표 5에 설명 된 서로 다른 보안 수준 ([34] 기준)에 대한 신호 보안에 대한 설계 지침이 작성되었습니다.

  1. Otsuka, S., Ishigooka, T., Oishi, Y., and Sasazawa, K., “CAN Security: Cost-Effective Intrusion Detection for Real-Time Control Systems,” SAE Technical Paper 2014-01-0340, 2014,