All posts by hongseoklee

(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

Advertisements

(Paper) safety critical system 분야에서의 프로세스 평가를 위한 추가적인 요구사항


예전 회사에 있을 때, 인증 체계를 구축하기 위한 방법을 위해 개인적으로 연구했었던 자료이다. 지금이야 사용할 일이 없을 것 같아 공유한다.

 

핀란드의 원자력 발전소의 안전 소프트웨어 인증을 위한 방법에 대해 소개함

 

소프트웨어의 인증은 다음의 두 가지를 기반으로 함

  • generic sets of criteria(프로세스)
  • domain-specific requirements(안전 표준)

프로세스를 위해서 ISO/IEC15504표준을 사용하고, 안전 표준은 IEC60880를 사용함

 

Process assessment를 위한 integrated approach를 사용함

  • safety case(제품에 대한 안전성)
  • conformance assessment(안전 표준에 대한 적합성)
  • software measurement(프로세스에 대한 평가)

 

Process Assessment의 용도 – 3가지 type의 assessment를 정의함

  • Short ‘ability assessment’ – 개발할 역량이 있는지를 평가하기 위한 목적의 성격. 프로젝트 시작 전 공급자 선정을 위해 평가하는 것과 유사함
  • Full-scale ‘certification assessment’ – 진행중인 프로젝트에 대한 인증 평가
  • ‘Gap fulfillment assessment’ – 인증 평가에서 발견된 Gap에 대해 보완 수정 후 수행하는 인증 평가

 

Assessment type Description
ability assessment Short, even only some days of effort.

Informal한 방법으로 정형화되지 않음

다음의 사례가 있을 수 있음

  • 주요 SW개발 프로세스의 평가(주로 ENG)
  •  핵심 문서의 검토, 프로세스 역량 점검
  • 표준의 conformance
Process assessment Scampi-A방법의 평가 방법론과 유사하며 매우 정형적임

모든 활동은 시스템적으로 수행된다.

ISO 17020에 따른다.

Gap fulfilment assessment 프로세스 평가의 수정 보완 조치 이후 재평가

프로세스 적합성 평가에 대한 basic workfow에 대해서는 논문 참조

 

평가모델

Reference 표준은 61508혹은 60880이라 할 때, 이를 평가하기 위한 기본은 SPICE를 기반으로 함

Table 1과 같이 SPICE체계에서 Reference 표준을 매핑시키고 부가적으로 새롭게 프로세스를 제정함

 

  1. Assessment Result에 대한 고려사항

4.1 Conformance vs capability results

어떤 방식으로 평가 결과를 매기느냐에 따라서 다음과 같이 나뉠 수 있다.

 

(1) 적합성 평가: 적합성 결과는 flat하고 linear하며 대개 Yes/No로 표현된다. 각각의 non-conformance가 기록되고 평가결과는 negative findings의 list로 구성된다.

(2) Capability 평가: Capability 평가는 2차원적으로 보다 구조적이라고 볼 수 있음

 

안전 표준은 conformance oriented되어 있는 측면이 있다.

 

 

결론:

핀란드의 평가모델은 SPICE체계를 따르며(안전 표준을 SPICE틀로 녹여냄) Rating Scheme은 적합성 평가 체계(Yes/No scale)를 따르는 것으로 보임. 하지만 Conformance와 Capability의 혼합 형태도 가능하다는 의견을 피력함. 확실히 안전 표준은 요구사항으로서 기본적으로 표준 적합성(ISO26262-compliant)로서 평가되어야 한다는 점은 동의함. 하지만 그것이 반드시 1차원적인 형태로 표현되어야 할 필요는 없다고 생각함. 이 프로젝트와 관련된 다른 paper에서 SPICE의 y축(capability)에 대한 scheme(15504-2)을 재정비한 자료가 존재함

 

Determining boundaries of Sys, HW and SW


Recently, I perceived that documents among sys, hw and sw are overlapped. In some cases, they are not consistent. To solve this problem, I have to suggest a policy. (In most cases, safety engineers cannot perceive such a problem, because their work scope is not wide. It is not personal problem.)

If I were a system safety engineer, what extent should I cover? If I know SW parts, then I would try to specify sw related specification in the system document. Then many contents will be overlapped. If I know HW parts, then I may cover too much contents of HW details in the system document. If I know both parts, then what are benefits regarding HW and SW documents?

It is true that system documents are associated to HW and SW documents.

Similar problem is that when safety engineers conduct safety analysis, what is unit in the system aspect? I think that there should not be overlapped between not only system result and SW result but also system result and HW result. How safety engineers do not intrude other competencies territory(scope)?

As a Solution for this problem, I recommend a picture from ISO 26262-4.

26262-4.PNG

I have an insight from this picture. Based on this structure, I ask several question to myself.

  • What are system scope?
  • What are sub-systems in our system?
  • How safety requirements in the system scope are allocated to sub-systems?
  • Based requirements allocated to sub-systems, how requirements are detailed?
  • How system building blocks in system design are traceable to blocks in FMEA or FTA?
  • What is unit in the system design and how it is associated to SW and HW?

Logical scheme for these work products help safety engineers to do their tasks. and it will be easier to defense against  customer audit or argue our safety concept in the court. This structure will help our works to have consistent.