ISO 26262 제2판 주요 개정 내용 및 의미(2)

자동차 전기·전자 제어 시스템의 결함으로 인한 오동작으로 인해 발생할 수 있는 자동차 수준의 위험을 완화?제어?회피하기 위한 ISO 26262 Road Vehicles-Functional Safety 표준 제2판(2nd edition)이 5월에 발간된다. 전체적으로 봤을 때, ISO 26262 제2판은 systematic failure와 random hardware failure의 대응 설계를 위한 엔지니어링 측면의 기술적인 요소를 좀더 강화하는 방향으로 개정됐다고 할 수 있다.

ISO 26262 개정 내용은 OEM과 전자제어분야 협력사에게 미칠 영향이 상당할 것으로 예상된다. 지난 호에 part 1에서 part 5까지 다룬 데 이어, 이번 호에는 part 6 Product development at the software level에 관한 내용을 다룬다.

1. Part 6
Product development at the software level

1.1 구조의 변경
Part 1의 verification에 대해 보완된 정의^¹를 바탕으로, 9절 software unit testing, 10절 software integration and testing은 각각 software unit verification과 software integration and verification으로 그 제목을 변경했으며, 내용 또한 testing을 포함하여 review, analysis 등 여러 가지 verification 방법들을 다루고 있다. 또한 이와는 반대로 11절 Verification of software safety requirements는 Testing of the embedded software로 변경했으며, 1판에서 다루었던 testing 환경에 추가해 testing 방법, test case 생성방법 등 testing에 관한 내용들을 상세화 했다.

Annex B는 현장에서 Model based development 적용 시 고려해야 할 사항을 반영시킨 결과로, 1판 내용과 비교하여 새로운 내용을 대거 추가했으며, Annex E가 아래와 같이 새롭게 추가됐다.
- Annex E: Application of safety analyses and analyses of dependent failures at the software architectural level
¹ Verification은 세부 방법으로 verification review, verification testing, simulation, prototyping, analysis로 구분될 수 있다.

1.2 주요 변경내용
Safety plan, verification plan의 삭제
기존 1판에서는 5. Initiation of product development at the software level에서 소프트웨어 개발계획 및 검증계획 수립이 요구됐으나, 제2판에서는 이러한 계획 활동은 part 2와 part 8에서 다루는 것으로 정리하고, part 6에서는 engineering 측면을 주로 다루기로 해, 이러한 내용이 명시적으로 삭제됐다.

Concurrency 이슈
자동차 제어기에 multi-core 하드웨어 플랫폼 적용이 많아지면서, multi-core 시스템 상에서 concurrent software 실행 시 발생할 수 있는 일반적인 이슈들에 대해서 고려해야 하는 내용들이 몇 가지 추가됐고, 그 의미가 확장됐다^².

- Table 1 “Modelling and Coding guidelines” - Concurrency aspects (ASIL A,B,C,D : +)
- Table 3 “Principles for software architectural design” - interrupts using a clear priority(ASIL A,B,C : +, ASIL D : ++), shared resources management(ASIL A,B,C,D : ++)
- Table 4 “Methods for the verification of the software architectural design”
- Scheduling analysis(ASIL A,B : +, ASIL C,D : ++)
- Access permission control mechanism to safety-related shared resources : 안전 메커니즘 설계 시 고려사항으로 언급
² 단, 나열된 모든 내용이 multi-core 환경에서 동작하는 task/process에만 해당하는 것은 아니다.




모델 기반 개발 방법론
모델링 가이드라인에 대한 예제로 MISRA AC 시리즈를 언급하고 있다. 이러한 가이드라인은 Simulink, state flow, 자동 코드 생성 등에 필요할 것이며, 대표적인 예로는 GMG, SLSF, TL, AGC 등이 될 것이다.

Annex B에서는 소프트웨어 수준 개발 시 Model-Based Development approaches(MBDV)가 가질 수 있는 장점과 잠재적인 이슈 사항을 설명하고 개발단계별 고려사항을 예제로 설명하고 있다.

모델 기반 개발 시에는 requirement, architectural design, detailed design 등 표준에서 요구하는 여러 가지 work product들이 모델 하나로 대표될 수 있으므로, 연속성, 일치성, 정보공유로 인한 효율성 향상 등이 기대될 수 있으나 반대급부로 systematic failure를 일으킬 수 있다.

이러한 내용은 표 2와 같이 모델 기반 개발의 5가지 use case별로 설명하고 있다.



Software architecture design
Software architecture design 시 systematic failure를 회피하기 위해 가져야 할 notation 특성 8가지와 설계 원칙을 통해 확보해야 하는 특성 4가지가 새롭게 추가됐다.

- (Notation 특성) comprehensibility, consistency, simplicity, verifiability, modularity, abstraction, encapsulation, maintainability.
- (architecture design 특성) comprehensibility, consistency, verifiability, maintainability.

또한 Table 2 “Notations for software architectural design”에 natural language를 추가했으며 모든 ASIL에서 highly recommended를 적용했다. Natural language는 다른 notation을 보조하여 보완하는 방법으로 사용되도록 하고 있다. Semi-formal notation에는 UML, SysML, Simulink, Stateflow를 이용한 pseudocode나 modelling을 포함할 수 있다는 내용을 포함했다. Semi-formal notation은 2011년 판에는 ASIL B부터 D까지 ++이었으나, 2018년 판에는 ASIL A,B는 +, ASIL C,D는 ++로 변경됐다.
표 3은 Principles for software architectural design에 대하여 1판 대비 2판에서 변경된 부분을 정리한 것이다. 인터페이스 사이즈 제한은 ASIL D에서는 ++로 상향 조정했으며, freedom from interference, cascading failure 및 common cause failure 등을 고려하여 1h와 1i를 새롭게 추가했다.


³ Spatial isolation: SW elements를 different memory partition에 배치하여 할당된 영역에서만 read/write 할 수 있음



소프트웨어 아키텍처 수준에서의 안전분석은, 1판에서는 error detection과 error handling을 위한 안전 메커니즘 설계가 필요할 경우, table 4 “Mechanisms for error detection at the software architectural level”과 table 5 “Mechanisms for error handling at the software architectural level”을 적용하도록 요구하고 있다(ISO 26262-6의 7.4.12, 7.4.13). 제2판에서는 7.4.12와 7.4.13을 하나의 요구사항으로 통합했으며, table 4와 table 5를 모두 삭제했다.

Table을 삭제하는 대신 error detection과 error handling에 대한 안전 메커니즘은 본문에 note로서 내용을 삽입했다. 그 이유는 소프트웨어 결함은 systematic 특성을 가지고 있기 때문에 table 4와 table 5에 나열돼 있는 error detection과 error handling 안전 메커니즘 만이 반드시 효과적인 것은 아니고, 안전분석을 통한 잠재결함 파악을 통해 다양한 대응설계가 가능하기 때문이다. 어떤 경우에는 안전 메커니즘 설계가 필요 없는 경우도 발생할 수 있기 때문이다. 이러한 내용은 annex E를 통해 추가적으로 파악될 수 있다.

Software unit design and implementation
Semi-formal notation은 2011년 판에는 ASIL B부터 D까지 ++이었으나, 2018년 판에는 ASIL A,B는 +, ASIL C,D는 ++로 변경됐다.
Design principles 역시 ASIL별 권고하는 수준이 변경됐다. 표 5에서 볼 수 있듯이, 변수명의 중복 사용금지는 모든 ASIL에서 ++이며, 포인터의 제한적 사용은 ASIL A에서 +로 권고수준이 상향됐다.

Software unit verification
1판에서는 8절 unit design and implementation에 verification 내용이 정의되어 있었으나, 2판에서는 9절 software unit verification으로 그 내용이 통합됐다. 1판의 table 9 “Methods for the verification of software unit design and implementation”과 table 10 “Methods for software unit testing”이 2판에서는 table 7 “Methods for software unit verification”으로 통합된 것이다.

통합되면서 unit verification 방법으로 pair-programming이 새롭게 추가됐고, 기존 semantic code analysis는 static analyses based on abstract interpretation으로 그 명칭이 변경됐는데, 그 이유는 sematic code analysis라는 기술 자체가 가지는 모호성 때문에 오해의 소지가 있었기 때문이다. 또한 모델 기반 개발 시 unit 수준의 verification 대상은 model 자체 또는 model로부터 생성된 코드 중 어느 하나이거나 두 가지 모두로 설명하고 있다.


Software integration and verification
2판의 Software integration verification 방법은 기존 1판의 내용에 표 7과 같이 3가지 방법이 추가됐다.
모델 기반 개발에 대한 verification 대상은 software component에 관련된 모델이 될 수 있다.

Testing of the embedded software
Embedded software 시험환경에 대한 요구사항이 표 8과 같이 변경됐다. 즉 HIL이 모든 ASIL에서 ++로 강조되고 있으며, Vehicle level 시험은 ASIL A와 B에서는 중요성이 약화됐다.



Embedded software 시험에 대한 test 방법과 test case 도출 방법이 표 9와 10과 같이 추가됐다.

Annex E의 추가 - Application of safety analyses and analyses of dependent failures at the software architectural level
기존 표준에서는 software 특성을 고려한 safety analysis 방법에 대한 내용이 부족했는데, 2판에서는 annex E를 통해 많은 보완이 이루어졌다. Annex E에서는 안전분석과 종속고장분석(Dependent Failure Analyse, DFA)의 목적과 범위, 의도, 분석수행 시 고려해야 하는 토픽 및 식별된 약점(weakness)에 대한 완화전략(mitigation strategy)을 설명하고 있다.

소프트웨어의 안전분석의 목적은 소프트웨어가 해당 ASIL에서 요구하는 수준의 무결성으로, 특정한 안전관련 기능과 특성을 제공하기에 충분한 지에 대한 증거를 제공하기 위한 것이다. 자동차 산업계에서는 그동안 많은 현장에서 소프트웨어 안전분석을 위하여 주로 FMEA, FTA의 방법론에 집착하는 경향이 있었으나, 이에 대한 효과성에 대한 고민은 크지 않았던 것으로 생각된다.
소프트웨어 안전분석의 목적을 고려할 때는 그 효과가 충분하지 않았던 것이 사실이다. 제2판에서는 소프트웨어 실행, 스케줄링, 통신 등 소프트웨어의 특성과 공유자원인 메모리 등 하드웨어 결함을 고려한 분석에 대한 방법론을 좀더 구체적으로 제시해 software element 간의 freedom from interference와 independence를 확보한 설계를 강조하고 있다.

Annex E의 주요 내용을 요약하면 다음과 같다.

- 안전분석과 종속고장분석은 software architecture 수준에서 적용
- 안전분석 목표 설정 및 아키텍처에 대한 분석 범위 결정
- safety-related weakness 식별을 위한 적절한 분석방법 선정
- 종속고장분석 시 ISO 26262-9:2018의 annex C에 정의된 coupling factor(공유자원, 공유정보입력-전역변수 등, systematic coupling 요소-동일한 소프트웨어 툴 사용 등) 내용 활용
- Annex D의 timing and execution, memory, exchange of information 등의 예와 관련된 software fault model을 고려한 분석
- “after, late, before, entry, no, more, less” 등 Guide word를 사용한 분석
- 분석을 통해 도출된 weakness에 대한 완화 전략(mitigation strategy)
 
 

---

[필자 소개]
· ISO TC22/SC32/WG8 한국대표
· ISO 26262 등 기능안전 컨설팅 및 교육
· ISO 26262 등 functional safety assessment (Porsche, Volvo, 현대차, 쌍용차 向 제어기 등 다수)
· Intacs™ Automotive SPICE competent assessor
· 전(前) 한국산업기술시험원(KTL) 책임연구원

---

---

AEM_Automotive Electronics Magazine