What are benefits from safety analysis?


Safety analysis should be derived from design. I prefer that FMEA or FTA should be derived systematically.

And what if there are nothing identified additional safety requirements from safety analysis?

It would be good news, because your design is safe even though you considered diverse failure conditions.

But what if there is no history to improve your system safety and there is nothing identified and your system is safety critical. Does it make sense?

Of course, customer will not believe what you did.

IF safety requirements are not additionally identified from safety analysis, then please consider that your mechanism to derive FMEA and FTA from design is wrong, or your design may miss what should be contained.

There are many approaches, some are useful, and the others may not. Your practice can be improved, so continually improve your design to stretch to safety.

In this sense, re-work is very common.

 

 

Advertisements

The thing Changed in the System Development Lifecycle of ISO 26262-4:2018


In first edition, Safety system requirement stage and safety system design stage are distinguished. I’ve thought that it was natural until 1 year ago. But Applying ISO 26262, it was vague.

My major question applying ISO26262-4:2011 was

Comparing Automotive SPICE and ISO 26262-4, TSR specification is performed in ENG.2(Requirement specification) phase? But the details of TSRs cannot be determined in the ENG.2 stage.

Because requirement and design is distinguished in the ISO 26262 standard, I’d like to define the two.

  • Requirement defines what shall be done.
  • Design define how shall be implemented.

Safety relevant functions are closely related not only to requirement, but also to design decision in the supplier aspect.

Safety mechanisms are belong to TSR, but they are design decision to handle failures that are related to safety.

When I realized the fact, I feel so confused. Then how deep should I recommend functional safety engineers to specify TSRs? How should I define development life-cycle? How to combine from existing development lifecycle?

 

My conclusion is that I don’t have to distinguish between safety requirement and safety design, because major contents specified in the Technical Safety Requirements stage are derived from design decision.

After Safety analysis results, TSRs are additionally identified and safe design decision is defined. Then, TSR stage does not just cover requirement stage.

So my idea is that TSR does not cover fully ENG.2(requirement specification) and ENG.3(design specification) both but is in the overlap of both ENG.2 and ENG.3. and TSC is in ENG.3

When I review latest ISO 26262-4:2018, I thought that the author of the standard might be in the similar situation. I do not know the real, anyway I welcome that TSR stage and Safety design stage are merged.

 

(Paper) Functional Safety Extensions to ASPICE According to ISO 26262


과거에 있던 회사에서 자동차 분야에서 functional safety관련된 인증 체계를 구축하기 위한 연구 자료이다.

요약. 자동차 산업은 현재 안전한 개발에 집중하고 있다. 이런 feature의 구현은 전자 하드웨어뿐만 아니라 소프트웨어에서의 복잡성 및 기능 통합을 증가시킨다. 복잡하고 통합된 환경에서 안전을 유지하기 위해서 ISO26262 기능 안전 표준이 이를 지원할 것이다. 자동차 제조사들은 ISO26262도입을 통해 이득을 얻을 것이다. ISO26262의 요구사항 중의 하나는 표준에 부합하도록 사용되는 개발 프로세스 역량(capability)을 평가하는 것이다. 기능 안전 확장은 Automotive SPICE와 함께 사용될 수 있다.

ISO26262 프로세스와 A-SPICE는 굉장히 유사하다. overlap되는 부분이 많다. ISO26262와 A-SPICE에 대한 harmonized integrated process에 대해서는 이 당시 study했던 때와는 많이 생각이 다르다. 과거보다 훨씬 깊이있고 radical하게 변화했다고 생각한다. 그런 idea를 언제쯤 공유하게 될지는 모르겠으나, 일단 여기서는 그 얘기는 하지 않고 논문 이야기만 한다.

고려대상

  • ISO26262
  • Automotive SPICE
  • +SAFE(CMMI계열이다)
  • ISO/IEC 15504-10 – Safety Extension

Assessment Framework

결국 이것이 인증 체계의 골격이라고 할 수 있을 것이다.  이 논문에서 생각해 낸 것은 3가지이다.

  • Use the Automotive SPICE framework
  • Develop custom framework based on ISO 26262
  • Use framework from other domains

 

1) Use the Automotive SPICE framework

이 방법은 인증 체계를 SPICE체계의 표준에 align시키는 방법이다. 개인적으로 이 방법을 가장 선호한다. 다양한 분석이 가능하고, 궁극적인 목적인 supplier의 weak point 식별 및 OEM으로서 어떻게 supplier를 이끌어 갈 것인지에 대한 계획을 수립할 수 있다. 그렇게 하려면 ISO 26262를 SPICE스타일로 변환시키는 과정이 필요하다. 이것은 일반 OEM회사에서는 접근하기가 쉽지는 않다. 그러한 평가 모델을 만든다는 것이 말처럼 간단한 것은 아닐 것이다. SPICE는 Plug-in play방식같이 새로운 것을 끼워 넣는 것이 유연해서 가능한 방식이라고 생각된다. 적어도 인증 기관에서 운영을 한다면 이 정도의 품위는 있어줘야 하는게 아닐까 생각을 하기도한다.

2) Develop custom framework based on ISO 26262

26262를 분석해서 checklist를 만들어서 rating하는 방식이다. 만들기는 아주 간단하다. 그러나 평가기관의 품위가 없고 굉장히 평가 점수가 의미하는 바는 너무 단순하다. all or nothing이다. 50점과 70점의 점수의 차이가 굉장히 정성적인 느낌이다. 어차피 안된건 마찬가지다. 그런데 어느 부분에 개선이 필요할까? 이런 부분에 대한 답을 주지 못한다. 그냥 못한거다. 또한 A-SMGCS의 프로젝트에서 TTA가 감사원의 세력을 등에 업고 지적질을 하면서 A-SMGCS 프로젝트를 drop을 시킬 때 이런 방법을 썼었다.

Continue reading (Paper) Functional Safety Extensions to ASPICE According to ISO 26262

ISO26262, DO-178C, DO-278A