기술 및 방법

SYS 시스템 개발
HW 하드웨어 개발
SW 소프트웨어 개발

SYS.001 기술안전 컨셉 개발

0 : 해당 method를 해당 ASIL에서 사용하는 것이 권장되지 않음(no recommendation)
+ : 해당 method를 해당 ASIL에서 사용할 것을 권장함(recommendation)
++ : 해당 method를 해당 ASIL에서 사용할 것을 매우 권장함(highly recommendation)

SYS Table 1 — 시스템 아키텍처 설계 분석

No	Methods	ASIL
No	Methods	A	B	C	D
1	연역적 분석 (ex. FTA)	o	+	++	++
2	귀납적 분석 (ex. FMEA)	++	++	++	++

SYS Table 2 — 검증(Verification)

No	Methods	ASIL
No	Methods	A	B	C	D
1a	인스펙션	+	++	++	++
1b	워크스루	++	+	o	o
2a	시뮬레이션	+	+	++	++
2b	시스템 프로토타입 개발 및 차량 테스트	+	+	++	++
3a	시스템 아키텍처 설계 분석: 연역적 분석 (ex. FTA)	o	+	++	++
3b	시스템 아키텍처 설계 분석: 귀납적 분석 (ex. FMEA)	++	++	++	++

1a 워크쓰루 : 개발 산출물에 대해서 설계자나 개발자가 검토자들에게 질문이나 피드백을 받아서 발생할 수 있는 에러, 개발 표준의 위배나 문제점을 찾아내는 방법
1b 인스펙션 : 개발 산출물을 검토자들이 검토하고, 결함을 식별하여 식별된 결함에 만장일치 합의하는 방법
2a 시뮬레이션 : 컴퓨터 환경에서 시스템 아키텍처를 검토하는 방법
2b 시스템 프로토타입 : 프로토타입은 개발해야 하는 시스템의 미완성 버전을 만드는 것으로써, 최종 시스템의 요구사항 가운데 일부만을 구현하여 구현 가능성을 확인하기 위한 목적으로 사용되는 방법.
2b 차량 테스트 : 실제 차량에서 시스템을 평가하는 방법
3a 연역적 분석 : 연역적 분석 방법은 FTA, RBD (reliability block diagrams) 등의 논리적 분석 방법으로 만일 전제가 참이면, 결론도 반드시 참이다.
3b 귀납적 분석 : 귀납적 분석 방법은 FMEA, ETA, Markov modeling 등의 경험적 요인을 포함시킨 확률적 분석 방법으로 만일 전제가 참이면, 결론은 확률적으로는 참이나 필역적으로 참은 아니다.

SYS.002 통합 및 테스트

SYS Table 3 — 통합 테스팅을 위한 테스트케이스 도출 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 분석	++	++	++	++
1b	내/외부 인터페이스 분석	+	++	++	++
1c	HW-SW 통합을 위한 등가 클래스 생성 및 분석	+	+	++	++
1d	경계값 분석	+	+	++	++
1e	지식 또는 경험 기반 오류 추정	+	+	++	++
1f	기능 의존성 분석	+	+	++	++
1g	공통 한계 조건, 전개방식 및 의존고장 출처 분석	+	+	++	++
1h	환경 조건 및 운영 유즈케이스 분석	+	++	++	++
1i	필드 경험 분석	+	++	++	++

SYS.002 통합 및 테스트 - 하드웨어-소프트웨어 통합 테스트

SYS Table 4 — 하드웨어-소프트웨어 수준에서의 기술안전 요구사항의 올바른 구현

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 기반 테스트	++	++	++	++
1b	결함 주입 테스트	+	++	++	++
1c	비교 (백투백) 테스트	+	+	++	++

1a 요구사항 기반 테스트 : 기능 및 비기능적 요구사항에 대한 테스트를 의미
1b 결함 주입 테스트 : 런타임 동안 테스트 대상에 결함을 발생시키는 어떤 특별한 방법을 사용. 이 경우 특정 테스트 인터페이스를 통해 소프트웨어나 별도로 준비한 하드웨어에서 실시된다. 정상적으로 운영되는 동안에는 안전 메커니즘이 작동하지 않기 때문에, 안전 요구사항의 테스트 커버리지를 향상시키기 위해 일반적으로 사용된다.
1c 비교(백투백, Back-to-back) 테스트 : 모델과 그것을 실제 구현한 것 간의 차이점을 알아보기 위해, 시뮬레이션 모델과 테스트 대상에 동일한 자극을 주고 그 반응을 비교하는 것

SYS Table 5 — 하드웨어-소프트웨어 수준에서의 안전 메커니즘의 올바른 기능 수행, 정확성 및 타이밍

No	Methods	ASIL
No	Methods	A	B	C	D
1a	비교 (백투백) 테스트	+	+	++	++
1b	성능 테스트	+	++	++	++

1a 비교 테스트 : 모델과 그것을 실제 구현한 것 간의 차이점을 알아보기 위해, 시뮬레이션 모델과 테스트 대상에 동일한 자극을 주고 그 반응을 비교하는 것이다.
1b 성능 테스트 : 테스트 대상 시스템의 포괄적인 성능(예를 들어 태스크 스케줄링, 타이밍, 전원 출력)을 검증할 수 있으며, 하드웨어 동작을 제어하는 소프트웨어의 기능을 검증할 수 있다.

SYS Table 6 — 하드웨어-소프트웨어 수준에서의 내/외부 인터페이스의 일관성 및 올바른 구현

No	Methods	ASIL
No	Methods	A	B	C	D
1a	외부 인터페이스 테스트	+	++	++	++
1b	내부 인터페이스 테스트	+	++	++	++
1c	인터페이스 일치성 체크	+	++	++	++

명시된 인터페이스, 호환성, 타이밍 및 기타 명시된 사항을 완전하게 테스트하기 위해, 아날로그/디지털 입출력 테스트, 경계 값 테스트, 동치 클래스 테스트를 포함한다.
ECU의 내부 인터페이스는 SPI(Serial Peripheral Interface) 통신이나 IC(Integrated Circuit) 통신 또는, ECU 엘리먼트들간의 인터페이스에 대한 동적 테스트와, 하드웨어와 소프트웨어 간의 호환성에 대한 정적 테스트를 통해 확인될 수 있다.

SYS Table 7 — 하드웨어-소프트웨어 수준에서의 안전 메커니즘 효과성

No	Methods	ASIL
No	Methods	A	B	C	D
1a	결함 주입 테스트	+	+	++	++
1b	오류 추정 테스트	+	++	++	++

1a 결함주입 테스트 : 런타임 동안 테스트대상에 결함을 발생시키는 특별한 방법을 사용한다. 이 테스트는 특별한 테스트 인터페이스를 통해 소프트웨어나 따로 준비된 하드웨어에서 실시된다. 정상적으로 운영되는 동안에는 안전 메커니즘이 작동하지 않기 때문에, 안전 요구사항의 테스트 커버리지를 향상시키기 위해 일반적으로 사용된다.
1b 오류 추정 테스트 : 테스트 대상에 대해, 추정 가능한 오류 데이터 및 전문가 지식을 사용한다. 그런 다음, 적절한 테스트설비를 이용하여, 이러한 오류가 일어나도록 테스트를 고안한다. 오류 추정은 이전에 유사한 대상을 경험한 테스트자가 있는 경우에, 효과적인 방법이다.

SYS Table 8 — 하드웨어-소프트웨어 수준에서의 강건성 수준

No	Methods	ASIL
No	Methods	A	B	C	D
1a	자원 사용 테스트	+	+	++	++
1b	스트레스 테스트	+	++	++	++

자원 사용 테스트 : 통계적(예: 최악의 시나리오도 자원을 모두 소비하지 않음을 검증하기 위해서 수행하는, 코드 사이즈 확인 또는 인터럽트 사용에 대한 코드 분석) 방법이나 런타임 모니터링에 의한 동적 방법을 통해 수행될 수 있다.
스트레스 테스트 : 외부환경에서 기인한, 작동 부하가 높은 경우나 작동 요구가 많은 경우에도 제대로 동작하는지 검증하는 것이다. 따라서 테스트 대상에 극한 온도조건이나 습도 또는 기계적 쇼크를 가하는 테스트 뿐 아니라, 정상이 아닌 인터페이스 부하를 주거나, 이상 값(버스 부하, 전기적 쇼크 등) 과 같은 높은 부하를 주는 테스트가 적용될 수 있다.

SYS Table 9 — 시스템 수준에서의 기능안전 및 기술안전 요구사항의 올바른 구현

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 기반 테스트	++	++	++	++
1b	결함 주입 테스트	+	+	++	++
1c	비교 (백투백) 테스트	o	+	+	++

요구사항에 기반 테스트 : 기능 및 비-기능적 요구사항에 대한 테스트
결함주입테스트 : 런타임 동안 테스트대상에 결함을 발생시키는 어떤 특별한 방법을 사용. 이 테스트는 특별한 테스트 인터페이스를 통해 소프트웨어나 따로 준비된 하드웨어에서 실시된다. 정상적으로 운영되는 동안에는 안전 메커니즘이 작동하지 않기 때문에, 안전 요구사항의 테스트 커버리지를 향상시키기 위해 일반적으로 사용된다.
비교 테스트 : 모델과 그것을 실제 구현한 것 간의 차이점을 알아보기 위해, 시뮬레이션 모델과 테스트 대상에 동일한 자극을 주고 그 반응을 비교하는 것

SYS Table 10 — 시스템 수준에서의 안전 메커니즘의 올바른 기능 수행, 정확도 및 타이밍

No	Methods	ASIL
No	Methods	A	B	C	D
1a	비교 (백투백) 테스트	o	+	+	++
1b	결함 주입 테스트	+	+	++	++
1c	성능 테스트	o	+	+	++
1d	오류 추정 테스트	+	+	++	++
1e	필드 경험으로부터 도출된 테스트	o	+	++	++

비교 테스트 : 테스트 대상의 응답과 시뮬레이션 모델의 응답을 동일하 자극에 비교하여 모델의 동작과 구현 간의 차이를 검출
결함 주입 테스트 : 시스템 수준에서 안전 메커니즘의 고장 모드 적용 범위의 효율성을 설명하기 위해 결함주입 방법 기반 테스트는 런타임 중에 테스트 객체에 결함을 주입하는 것을 의미한다. 이는 특별한 테스트 인터페이스 또는 특별히 준비된 하드웨어를 통해 소프트웨어 내에서 수행될 수 있다. 이 접근법은 제한된 결함 모델 세트, 즉 시스템 레벨에서 사실적으로 주입할 수 있는 간단한 결함 모델(예, 컴포넌트 핀에서 멈춤된 재생)에 유효하다.
성능테스트 : 시스템 안전 메커니즘의 성능(예, 액추에이터 속도 또는 강도, 전체 시스템 응답 시간)을 확인
오류추측 테스트 : 시스템의 오류를 예측하기 위해 배운 교훈을 통해 수집된 전문지식과 테스터를 사용한다. 그런 다음 적절한 테스트 기능과 함께 이러한 오류를 확인하도록 순차적으로 테스트가 설계된다. 오류 추측은 유사한 시스템에 대한 이전 경험이 있는 테스터에 효과적인 방법이다.
필드 경험으로부터 도출된 테스트 : 현장 경험과 현장에서 수집한 데이터에서 도출된 테스트이다.

SYS Table 11 — 시스템 수준에서의 내/외부 인터페이스의 일관성 및 올바른 구현

No	Methods	ASIL
No	Methods	A	B	C	D
1a	외부 인터페이스 테스트	+	++	++	++
1b	내부 인터페이스 테스트	+	++	++	++
1c	인터페이스 일치성 체크	o	+	++	++
1d	상호작용/통신 테스트	++	++	++	++

시스템의 인터페이스 테스트에는 시스템의 지정된 인터페이스, 호환성, 타이밍 및 기타 지정된 특성을 완전히 테스트하기 위해 아날로그 및 디지털 입력 및 출력 테스트, 경계 테스트 및 동등성 테스트가 포함된다. 시스템의 내부 인터페이스는 정적 테스트(예, 플러그 커넥터 일치)와 버스 통신 또는 시스템 엘리먼트 간 기타 인터페이스에 대한 동적 테스트를 통해 테스트 할 수 있다.
통신 및 상호작용 테스트에는 기능 및 비기능 요구사항에 대한 테스트 중에 시스템 엘리먼트와 테스트 중인 시스템 및 다른 차량 시스템 간의 통신 테스트가 포함된다.

SYS Table 12 — 시스템 수준에서의 강건성 수준

No	Methods	ASIL
No	Methods	A	B	C	D
1a	자원 사용 테스트	o	+	++	++
1b	부하 테스트	o	+	++	++
1c	특정 환경 조건에서 간섭에 대한 내성 및 강건성 테스트	++	++	++	++

시스템 수준에서 자원사용 테스트는 일반적으로 동적환경(예, 실험실 차량 또는 프로토타입)에서 수행된다. 테스트 할 문제에는 전력 소비 및 버스 로드가 포함된다.
스트레스 테스트는 높은 운영 부하 또는 환경 요구가 높은 시스템의 올바른 작동을 검증한다. 따라서 시스템의 높은 부하 또는 다른 시스템의 사용자 입력 또는 요청에 대한 테스트는 물론 온도, 습도 또는 기계적 충격에 대한 테스트를 적용할 수 있다.
특정 환경 조건에서 간섭 저항 및 견고성 테스트는 특수한 스트레스 테스트 사례이다. 예기에는 EMC 및 ESD 테스트가 포함된다.

SYS.002 통합 및 테스트 - 차량 통합 테스트

SYS Table 13 — 차량 수준에서의 기능안전 요구사항의 올바른 구현

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 기반 테스트	++	++	++	++
1b	결함 주입 테스트	++	++	++	++
1c	장기 테스트	++	++	++	++
1d	실사용 조건에서의 사용자 테스트	++	++	++	++

요구사항 기반 테스트 : 기능 및 비-기능적 요구사항에 대한 테스트를 의미한다.
결함주입테스트 : 런타임 동안 테스트대상에 결함을 발생시키는 어떤 특별한 방법을 사용한다. 이 테스트는 특별한 테스트 인터페이스를 통해 소프트웨어나 따로 준비된 하드웨어에서 실시된다. 정상적으로 운영되는 동안에는 안전 메커니즘이 작동하지 않기 때문에, 안전 요구사항의 테스트 커버리지를 향상시키기 위해 일반적으로 사용된다.
비교 테스트 : 모델과 그것을 실제 구현한 것 간의 차이점을 알아보기 위해, 시뮬레이션 모델과 테스트 대상에 동일한 자극을 주고 그 반응을 비교하는 것이다.

SYS Table 14 — 차량 수준에서의 안전 메커니즘의 올바른 기능 수행, 정확도 및 타이밍

No	Methods	ASIL
No	Methods	A	B	C	D
1a	성능 테스트	+	+	++	++
1b	장기간 테스트	+	+	++	++
1c	실사용 조건에서의 사용자 테스트	+	+	++	++
1d	결함 주입 테스트	o	+	++	++
1e	오류 추정 테스트	o	+	++	++
1f	필드 경험으로부터 도출된 테스트	o	+	++	++

성능 테스트는 아이템고 관련된 안전메커니즘의 성능 (예, 차량 수준의 결함 허용 시간 간격 및 결함이 있을 경우 차량 제어 가능성)을 확인할 수 있어야 한다.
실제 조건에서의 장기 테스트 및 사용자 테스트는 현장 경험에서 얻은 테스트와 유사하지만 일상 생활 동안의 생활 조건의 더 큰 샘플 크기를 사용한다(일반 사용자를 테스터로 사용). 이러한 테스트에는 테스터의 안전을 보장하기 위해 필요한 경우 제한이 있을 수 있다(예, 추가 안전 수단 또는 비활성화된 액추에이터 포함).
결함 주입 테스트는 특별한 수단을 사용하여 아이템에 결함을 주입한다. 이는 특수 테스트 인터페이스 또는 특수하게 주입된 엘리먼트 또는 통신장치를 통해 아이템 내에서 수행할 수 있다. 이 방법은 정상 작동 중에 안전 메커니즘이 호출되지 않기 때문에 안전 요구사항의 테스트 범위를 개선하는데 종종 사용 된다.
오류 추측 테스트는 시스템의 오류를 예측하기 위해 배운 교훈을 통해 수집된 전문지식과 데이터를 사용한다. 그런 다음 적절한 테스트 기능과 함께 일련의 테스트가 이러한 오류를 확인하도록 설계되었다. 오류 추측은 유사한 시스템에 대한 이전 경험이 있는 테스터에게 효과적인 방법이다.
현장 경험과 현장에서 수집한 데이터에서 도출된 테스트이다.

SYS Table 15 — 차량 수준에서의 내/외부 인터페이스의 올바른 구현

No	Methods	ASIL
No	Methods	A	B	C	D
1a	내부 인터페이스 테스트	+	+	++	++
1b	외부 인터페이스 테스트	+	+	++	++
1c	상호작용/통신 테스트	+	+	++	++

차량 수준에서 인터페이스 테스트는 차량 시스템 인터페이스의 호환성을 테스트하는 것이다. 이 테스트는 차량 운영시와 같은 동적 환경은 물론, 값의 범위 확인, 레이팅 확인, 기하학적 확인과 같이 정적으로도 실시될 수 있다.
통신 및 상호작용 테스트란, 기능 및 비기능 요구사항에 대해 런타임 동안 차량 시스템 간에 통신을 테스트하는 것을 포함한다.

SYS Table 16 — 차량 수준에서의 강건성 수준

No	Methods	ASIL
No	Methods	A	B	C	D
1a	자원 사용 테스트	+	+	++	++
1b	부하 테스트	+	+	++	++
1c	특정 환경 조건에서 간섭에 대한 내성 및 강건성 테스트	+	+	++	++
1d	장기간 테스트	+	+	++	++

시스템 수준에서 자원 사용 테스트는 보통 동적 환경(예: 랩 카 또는 시제작품)에서 수행된다. 아이템 내부 자원, 전원 소비 및 다른 차량 시스템의 한정된 자원 등 쟁점사항을 포함한다.
스트레스 테스트는 외부환경에서 기인한, 작동 부하가 높은 경우나 작동 요구가 많은 경우에도 제대로 동작하는지 검증하는 것이다. 따라서 테스트 대상에 극한 온도조건이나 습도 또는 기계적 쇼크를 가하는 테스트뿐 아니라, 다른 시스템으로부터 발생되는 대량의 사용자 입력/요청 상황이나 시스템에 높은 부하를 가하는 상황아래에서 테스트가 적용될 수 있다.
인터페이스 내성 및 강건성에 대한 테스트는, 특정한 환경 조건하에서 실시되는 스트레스 테스트의 한 종류로 EMC 및 ESD 테스트 등이 있다.
실생활 조건하에서 수행되는 장기 테스트와 사용자 테스트는, 필드 경험에 기반한 테스트와 유사하지만 샘플크기가 더 크며, 일반 사용자가 테스트하는 사람이고, 기존에 수행된 테스트 시나리오에 구애 받지 않으며, 일상 생활 동안 발생할 수 있는 실생활 조건에서 수행된다.

HW.002 하드웨어 설계

HW Table 1 — 하드웨어 아키텍처 설계 속성

No	Methods	ASIL
No	Methods	A	B	C	D
1	계층적 설계	+	+	+	+
2	안전 관련 하드웨어 컴포넌트들에 대해 정확하게 정의된 인터페이스	++	++	++	++
3	불필요하게 복잡한 인터페이스 방지	+	+	+	+
4	불필요하게 복잡한 하드웨어 컴포넌트 방지	+	+	+	+
5	유지보수성 (서비스)	+	+	++	++
6	테스트 가능성	+	+	++	++

HW Table 2 — 하드웨어 설계 안전 분석

No	Methods	ASIL
No	Methods	A	B	C	D
1	연역적 분석 (ex. FTA)	o	+	++	++
2	귀납적 분석 (ex. FMEA)	++	++	++	++

분석의 상세 수준은 설계의 상세 수준에 비례한다. 특정한 경우 두 가지 방법을 다른 상세 수준에서 수행할 수 있다.
예를 들어 하드웨어 컴포넌트 수준에서 FMEA를 수행하고, 상위 추상화 수준에서 수행되는 FTA의 기본 이벤트를 제공할 수 있다.

HW Table 3 — 하드웨어 설계 검증

No	Methods	ASIL
No	Methods	A	B	C	D
1a	하드웨어 설계 워크스루	++	++	o	o
1b	하드웨어 설계 인스펙션	+	+	++	++
2a	안전분석: 연역적 분석	o	+	++	++
2b	안전분석: 귀납적 분석	++	++	++	++
3a	시뮬레이션	o	+	+	+
3b	하드웨어 프로토타입 개발	o	+	+	+

하드웨어 설계 검증의 목적은 하드웨어 안전 요구사항에 관한 기술적 정확성과 완전성이다.
하드웨어 설계의 리뷰는 하드웨어 안전 요구사항을 완전하고 정확하게 구현함을 확인하기 위해 사용된다.
시뮬레이션 및 하드웨어 프로토타입 개발을 통한 검증은 하드웨어 설계 리뷰 또는 안전분석을 통한 설계 검증이 충분하지 않다고 판단되는 경우 하드웨어 설계의 특별한 부분을 확인하기 위해 사용한다.

HW.003 하드웨어 아키텍처 평가

HW Table 4 — "단일점 고장 메트릭" 목표값 도출을 위한 가능한 출처

	ASIL
	A	B	C	D
단일점 고장 메트릭 (Single-point fault metric)	─	≥90%	≥97%	≥99%

HW Table 5 — "잠재고장 메트릭" 목표값 도출을 위한 가능한 출처

	ASIL
	A	B	C	D
잠재 고장 메트릭 (Latent-fault metric )	─	≥60%	≥80%	≥90%

HW Table 6 — 하드웨어 우발 고장 목표값 도출을 위한 가능한 출처

ASIL	하드웨어 우발고장 목표값 (Random hardware failure target values )
D	<10E-8 (1/h)
C	<10E-7 (1/h)
B	<10E-7 (1/h)

HW Table 7 — 단일점 고장 관련 하드웨어 부품의 목표 고장률 등급

ASIL	고장률 등급 (Failure rate class)
D	고장율 등급 1 + 전용 수단 (Failure rate class 1 + dedicated measuresa)
C	고장율 등급 2 + 전용 수단 또는 고장율 등급 1 (Failure rate class 2 + dedicated measuresa or Failure rate class 1)
B	고장율 등급 2 또는 고장율 등급 1 (Failure rate class 2 or Failure rate class 1)

HW Table 8 — 하드웨어 부품에 주어진 진단 커버리지를 위한 최대 고장률 등급 - 잔존 고장

ASIL	잔존 결함에 대한 진단 커버리지 (Diagnostic coverage with respect to residual faults)
ASIL	≥99.9%	≥99.9%	≥90%	≥90%
D	고장율 등급 4	고장율 등급 3	고장율 등급 2	고장율 등급 1 + 전용수단
C	고장율 등급 5	고장율 등급 4	고장율 등급 3	고장율 등급 2 + 전용수단
B	고장율 등급 5	고장율 등급 4	고장율 등급 3	고장율 등급 2 + 전용수단

HW Table 9 — 이중점 결함에 관한 하드웨어 부품의 고장율 등급 목표 및 커버리지

ASIL	잔존 고장율과 관련된 진단 커버리지 (Diagnostic coverage with respect to latent faults)
ASIL	≥99%	≥90%	<90%
D	고장율 등급 4	고장율 등급 3	고장율 등급 2
C	고장율 등급 5	고장율 등급 4	고장율 등급 3

HW.005 하드웨어 통합 및 검증

HW Table 10 — 하드웨어 통합 테스팅을 위한 테스트케이스 도출 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 분석	++	++	++	++
1b	내/외부 인터페이스 분석	+	++	++	++
1c	등가 클래스 생성 및 분석	+	+	++	++
1d	경계값 분석	+	+	++	++
1e	지식 또는 경험 기반 오류 추정	++	++	++	++
1f	기능 의존성 분석	+	+	++	++
1g	공통 한계 조건, 전개방식 및 의존고장 출처 분석	+	++	++	++
1h	환경 조건 및 운영 유즈케이스 분석	+	++	++	++
1i	(존재할 경우) 관련 표준	+	+	+	+
1j	주요 변종 분석	++	++	++	++

HW Table 11 — 하드웨어 안전요구사항 구현의 완전성 및 정확성 검증을 위한 하드웨어 통합 테스트

No	Methods	ASIL
No	Methods	A	B	C	D
1	Functional testing a 기능 테스트	++	++	++	++
2	Fault injection testing b 결함 주입 테스트	+	+	++	++
3	Electrical testing c 전기적 테스트	++	++	++	++

기능 테스트는 기술된 아이템의 특성이 구현되었음을 검증하기 위한 것이다. 아이템은 예상한 정상 작동 상태가 되도록 하는 입력 값을 입력되어야 한다. 출력을 관찰하고 그 반응을 명세서상의 내용과 비교한다. 명세서와 상이한 점과 불완전한 명세서 내용을 분석한다.
반도체 컴포넌트의 결함 주입에 대한 지침을 참고한다.
전기적 테스트는 지정된 (정적 및 동적) 전압 범위 내 하드웨어 안전 요구사항의 부합을 검증하기 위한 것이다. 기존 표준에는 ISO 16750 과 ISO 11452 가 포함된다.

HW Table 12 — 스트레스 조건에서 내구성, 강건성 및 운영을 검증하기 위한 하드웨어 통합 테스트

No	Methods	ASIL
No	Methods	A	B	C	D
1a	기본 기능 검증을 포함한 환경 테스트	++	++	++	++
1b	확장 기능 테스트	o	+	+	++
1c	통계적 테스트	o	o	+	++
1d	최악 조건 테스트	o	o	o	+
1e	한계 초과 테스트	+	+	+	+
1f	기계적 테스트	++	++	++	++
1g	가속 수명 테스트	+	+	++	++
1h	기게적 내구성 테스트	++	++	++	++
1i	EMC / ESD 테스트	++	++	++	++
1j	화학적 테스트	++	++	++	++

1a 기본 기능 검증과 함께 환경 테스트를 하는 동안, 하드웨어는 하드웨어 요구조건이 평가되는 다양한 환경 조건하에 놓이게 된다. 이때 ISO 16750－4를 적용할 수 있다.
1b 확장된 기능 테스트는 단지 드물게 발생할 것으로 예상(예를 들면, 극단적인 임무 프로파일 값)되거나 하드웨어의 명세서 밖(예를 들면, 잘못된 명령)의 입력 조건에 대한 아이템의 기능적 동작을 점검한다. 이러한 상황에서 하드웨어 엘리먼트에서 관찰되는 동작은 기술된 요구사항과 비교된다.
1c 통계기반 테스트는 실제 임무 프로파일의 예상되는 통계상 분포에 따라 선택된 입력 데이터로 하드웨어 엘리먼트를 테스트하는 것이다. 허용 기준이 정의되어 있어 결과의 통계적인 분포가 요구되는 고장율에 일치하는지를 확인하게 된다.
1d 최악 조건 테스트는 최악의 경우를 분석하는 동안 발견 된 테스트 케이스를 테스트하기 위한 것이다. 그러한 테스트에서 환경 조건은 사양에 정의된 최대 허용 한계 값으로 변경된다. 하드웨어의 관련 응답을 검사하고 지정된 요구사항과 비교한다.
1e 한계 초과 테스트에서 하드웨어 엘리먼트는 동작이 멈추거나 파괴될 때까지, 환경 또는 기능제약 조건을 점진적으로 증가시켜 규정된 값을 초과하는 상황에 놓이게 된다. 이 테스트의 목적은 요구 되는 성능과 관련하여 테스트중인 엘리먼트의 강건성의 한계를 결정하는 것이다
1f 기계적 테스트는 인장 강도와 같은 기계적 특성에 적용된다. ISO 16750-3을 적용 할 수 있다.
1g 가속 수명 테스트는 운용 수명 기간 동안 예상되는 것보다 더 큰 스트레스를 주어 정상 운용 조건에서 제품의 반응 정도를 예측하기 위한 것이다. 가속 테스트는 고장 형태 가속에 대한 분석 모델을 기반으로 한다.
1h 이 테스트의 목적은 고장까지 걸리는 평균 시간 또는 엘리먼트가 견디는 최대 주기수를 연구하는 것이다. 테스트는 결함이 생길 때까지 수행하거나 손상 평가로 진행할 수 있다.
1i EMC 테스트를 위해 ISO 7637－2, ISO 7637－3, ISO 10605, ISO 11452－2, ISO 11452－4를 적용할 수 있다. ISO 16750－2는 ESD 테스트에 적용될 수 있다.
1j 화학 테스트와 관련하여 ISO 16750－5를 적용할 수 있다.

SW.002 소프트웨어 아키텍처 설계

SW Table 2 소프트웨어 아키텍처 설계 표기법

No	표기법	ASIL
No	표기법	A	B	C	D
1a	자연어	++	++	++	++
1b	비정형 표기법	++	++	+	+
1c	준정형 표기법	+	+	++	++
1d	정형 표기법	+	+	+	+

자연어는 표기법의 사용을 보완하는데 사용될 수 있다. 예를 들어, 어떤 주제에 대해서는 자연어로 표현하는 것이 보다 이해하기 쉬울 수 있으며, 표기법에서 설명하고자 하는 판단에 대한 합리성과 설명에 대한 제공이 보다 용이하다.
준정형 표기법은 Pseudo 코드나 UML, SysML, Simulink 또는 Stateflow와 같은 모델링을 포함한다.

SW Table 3 — 소프트웨어 아키텍처 설계 원칙

No	표기법	ASIL
No	표기법	A	B	C	D
1a	SW 컴포넌트의 적절한 계층 구조	++	++	++	++
1b	제한된 SW 컴포넌트 크기 및 복잡성	++	++	++	++
1c	제한된 인터페이스 크기	+	+	+	+
1d	각 SW 컴포넌트 내 강한 응집도	+	++	++	++
1e	SW 컴포넌트 간 느슨한 결합도	+	++	++	++
1f	적절한 스케줄링 속성	++	++	++	++
1g	제한된 인터럽트 사용	+	+	+	++
1h	SW 컴포넌트들의 적절한 공간적 분리	+	+	+	++
1i	적절한 공유 자원 관리	++	++	++	++

위의 "제한된" 의 의미는 다른 설계 고려사항과 균형을 최소화하는 것을 의미한다.
소프트웨어 컴포넌트의 응집도와 결합도는 예를 들어 특정 컨셉, 목표, task, 목적과 관련이 있는 소프트웨어 부분을 식별하고 캡슐화하고 조작하는 능력을 말하는 concerns의 분리를 통해 구현할 수 있다.
소프트웨어 컴포넌트 사이 제한된 결함도는 컴포넌트 간 종속성 관리를 의미한다.
제한된 인터럽트 사용은 우선순위가 명확한 인터럽트를 사용하거나 그 수를 최소화하여함을 의미한다.
공유 자원의 적절한 관리는 공유 소프트웨어 자원 뿐만 아니라 공유된 하드웨어 자원에 적용된다. 이런 자원 관리는 소프트웨어 또는 하드웨어로 구현될 수 있으며, 공유 자우너에 충돌하는 액세스를 탐지하고 처리하는 안전 메커니즘 뿐 아니라 공유 자원에 충돌하는 액세스를 방지하는 안전 메커니즘 및/또는 프로세스 수단을 포함한다.

SW Table 4 — 소프트웨어 아키텍처 설계 검증 방법

No	표기법	ASIL
No	표기법	A	B	C	D
1a	설계 워크스루	++	+	o	o
1b	설계 인스펙션	+	++	++	++
1c	설계의 동적 동작 시뮬레이션	+	+	+	++
1d	프로토타입 생성	o	o	+	++
1e	정형 검증	o	o	+	+
1f	제어 흐름 분석	+	+	++	++
1g	데이터 흐름 분석	+	+	++	++
1h	스케줄링 분석	+	+	++	++

SW.003 소프트웨어 단위 설계 및 SW.004 소프트웨어 구현

SW Table 5 — 소프트웨어 단위 설계 표기법

No	표기법	ASIL
No	표기법	A	B	C	D
1a	자연어 표기법	++	++	++	++
1b	비정형 표기법	++	++	+	+
1c	준정형 표기법	+	+	++	++
1d	정형 표기법	+	+	+	+

자연어 표기법은 다른 표깁버 사용을 보완하는데 사용될 수 있다. 예를 들어, 어떤 주제에 대해서는 자연어로 표현하는 것이 보다 이해하기 쉬울 수 있으며, 표기법에서 설명하고자 하는 판단에 대한 합리성과 설명에 대한 제공이 보다 용이하다.

SW Table 6 — 소프트웨어 단위 설계 및 구현을 위한 설계 원칙

No	Methods	ASIL
No	Methods	A	B	C	D
1a	서브 프로그램과 함수에서 1개의 진입점과 1개의 종료점	++	++	++	++
1b	생성 과정 동안 동적 개체 또는 변수 또는 다른 온라인 테스트 없음	+	++	++	++
1c	변수 초기화	++	++	++	++
1d	변수 이름을 여러 용도로 사용하지 않음	+	++	++	++
1e	전역 변수 사용을 회피하거나, 그렇지 않을 경우 타당한 사유 제시	+	+	++	++
1f	제한된 포인터 사용	o	+	+	++
1g	암시적 형 변환 없음	+	++	++	++
1h	숨겨진 데이터 흐름이나 제어 흐름 없음	+	++	++	++
1i	무조건적 점프 없음	++	++	++	++
1j	재귀 없음	+	+	++	++

SW.005 소프트웨어 단위 검증

SW Table 7 — 소프트웨어 단위 검증 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	워크쓰루	++	+	o	o
1b	페어 프로그래밍	+	+	+	+
1c	인스펙션	+	++	++	++
1d	준정형 검증	+	+	++	++
1e	정형 검증	o	o	+	+
1f	제어흐름 분석	+	+	++	++
1g	데이터 흐름 분석	+	+	++	++
1h	정적 코드 분석	+	++	++	++
1i	추상적 해석에 기반한 정적 분석	+	+	+	+
1j	요구사항 기반 테스트	++	++	++	++
1k	인터페이스 테스트	++	++	++	++
1l	결함 주입 테스트	+	+	+	++
1m	자원 사용 평가	+	+	+	++
1n	해당되는 경우, 모델과 코드 간의 연속 비교 테스트	+	+	++	++

모델 기반 개발의 경우 Code generator에 대한 Confidence를 정당화하는 증거를 제공하기 위하여 워크쓰루, 페어프로그래밍, 인스펙션 방법이 적용될 수 있다.
제어흐름 분석 및 데이터 흐름 분석은 소스코드 수준에서 적용 될 수 있으며, 모델기반 개발, 매뉴얼 코드 개발 방법 모두 적용 가능하다.
제어흐름 분석 및 데이터 흐름 분석은 정형검증, 정적 코드 분석, 추상적 해석에 기반한 정적 분석 방법의 일부일 수 있다.
정적 분석은 알려진 결함과 매칭하는 패턴을 찾는 코딩 가이드라인 또는 모델 가이드라인 준수 여부를 분석하는것과 같은 분석을 포함하는 집합적 용어이다.
추상적 해석을 기반으로 한 정적 분석은 정의도니 규칙위반, 제어 흐름 그래프 생성 및 데이터 흐름 분석 (예 : 경쟁 조건 및 교착 상태, 포인터 오용과 관련된 오류를 캡처하기) 또는 메타 컴파일 및 추상 코드 또는 모델 해석 등과 같은 의미 정보를 추가하여 컴파일러 구문 분석 트리를 확장하는 것과 같은 분석을 포함하는 확장 된 정적 분석의 집합적인 용어이다.
단위 수준의 소프트웨어 요구사항은 이 요구사항 기반 테스트이 기초이다. 이는 소프트웨어 단위 설계 사양과 소프트웨어 단위에 할당된 소프트웨어 안전 요구사항에 포함된다.
인터페이스 테스트는 사용된 혹은 교환된 데이터의 무결성에 대한 증거를 제공하는데 사용될 수 있다.
결함주입 테스트는 테스트 되는 소프트웨어 단위의 수정 즉, 예를 들어 변수 값의 손상, 코드 변형, 또는 CPU 레지스터 값의 손상 등의 임의의 고장에 대한 주입을 의미한다.
자원 사용 평가의 일부 측면은 소프트웨어 단위 테스트가 목표 환경에서 실행되거나 타겟 프로세스의 에뮬레이터가 자원 사용 테스트를 적절히 지원하는 경우에만 올바르게 수행될 수 있다.

SW Table 8 — 소프트웨어 단위 테스팅을 위한 테스트케이스 도출 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 분석	++	++	++	++
1b	동치 클래스 생성 및 분석	+	++	++	++
1c	경계 값 분석	+	++	++	++
1d	지식 및 경험 기반의 오류 추측	+	+	+	+

동치 클래스 입력과 출력의 분배를 기반으로 식별되어 각 등급의 대표 시험값을 선탁한다.
경계 값 분석은 인터페이스, 경계 부근 및 교차값, 범위를 벗어난 값에 적용한다.
오류 추측 테스트는 "Lesson learned" 절차와 전문가 판단을 통해 수집된 데이터를 기준으로 수행할 수 있다.

SW Table 9 — 소프트웨어 단위 수준에서 구조 커버리지 메트릭

No	Methods	ASIL
No	Methods	A	B	C	D
1a	구문 (Statement coverage)	++	++	+	+
1b	분기 (Branch coverage)	+	++	++	++
1c	MC/DC (Modified Condition/Decision Coverage)	+	+	+	++

SW.006 소프트웨어 통합 및 검증

SW Table 10 — 소프트웨어 통합 검증 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 기반 테스트	++	++	++	++
1b	인터페이스 테스트	++	++	++	++
1c	결함 주입 테스트	+	+	++	++
1d	자원 사용 평가	++	++	++	++
1e	해당되는 경우, 모델 간의 비교 테스트(back-to-back test)	+	+	++	++
1f	제어 흐름 및 데이터 흐름 검증	+	+	++	++
1g	정적 코드 분석	++	++	++	++
1h	추상적 해석에 기반한 정적 분석	+	+	+	+

아키텍처 엘리먼트에 할당된 소프트웨어 요구사항은 요구사항 기반 테스트의 "basis"이다.
결함 주입 기법은 특히 안전 메커니즘과 관련하여 하드웨어-소프트웨어 인터페이스의 정확성을 테스트하기 위해 소프트웨어에 결함을 유도하는 것을 의미한다. 이는 안전 메커니즘을 테스트하기 위해, 임의의 결함을 주입하는 것도 포함한다.
충분한 내구성을 갖춘 하드웨어 아키텍처 설계에 의해 영향을 받는 요구사항의 달성을 보장하기 위해, 평균 및 최대 프로세서 성능, 최소/최대 실행시간, 저장 사용량(RAM, ROM)과 통신 링크 (예: data bus)의 밴드폭을 결정해야 한다.
리소스 사용 평가의 일부 측면으로는 소프트웨어 통합 테스트는 목표 환경에서 실행되거나, 만일 목표 프로세서에 대한 에뮬레이터가 적절히 리소스 사용 테스트를 지원하는 경우에만 적절히 수행될 수 있다.
모델간의 비교 테스트는 이 방법은 소프트웨어 컴포넌트의 기능을 시뮬레이션할 수 있는 모델이 필요하다. 여기서, 모델과 코드는 같은 방식으로 시뮬레이션 되고, 서로 결과값을 비교한다.
정적 분석은 단위 수준에서 검증하지 않았다면, 구조 분석,리소스 소비 분석 및 알려진 결함과 일치하는 패턴의 모델 혹은 모델 혹은 소스코드 지침 준수와 같은 분석을 포함하는 집합적 용어이다.
만일 단위 수준에서 이미 수행되지 않았다면, 추상 해석을 기반으로 한 정적 분석은 정의 된 규칙 (예 : 데이터 유형 문제, 초기화되지 않은 변수) 위반, 제어 흐름 그래프 생성 및 데이터 흐름 분석 (예 : 경쟁 조건 및 교착 상태, 포인터 오용과 관련된 오류를 캡처하기) 또는 메타 컴파일 및 추상 코드 또는 모델 해석 등과 같은 의미 정보를 추가하여 컴파일러 구문 분석 트리를 확장하는 것과 같은 분석을 포함하는 확장 된 정적 분석의 집합적인 용어이다.

SW Table 11 — 소프트웨어 통합 테스트를 위한 테스트케이스 도출 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 분석	++	++	++	++
1b	동치 클래스 생성 및 분석	+	++	++	++
1c	경계값 분석	+	++	++	++
1d	지식 및 경험에 기반한 오류 추정	+	+	+	+

동치 클래스는 입력과 출력의 분배를 기반으로 식별되어, 각 등급의 대표 시험값을 선택할 수 있다.
오류 추측 테스트는 "Lessons learned" 절차와 전문가 판단을 통해 수집된 데이터를 기준으로 할 수 있다.
이 방법은 인터페이스, 경계 부근 및 교차값, 범위를 벗어난 값에 적용한다.

SW Table 12 — 소프트웨어 아키텍처 수준에서 구조 커버리지

No	Methods	ASIL
No	Methods	A	B	C	D
1a	기능 커버리지	+	+	++	++
1b	호출 커버리지	+	+	++	++

기능 커버리지는 소프트웨어에서 기능 또는 소프트웨어 서브 프로그램의 실행된 퍼센티지이다.
호출 커버리지는 소프트웨어에서 함수나 서브 프로그램의 구현된 각 호출에 대하여 실행된 소프트웨어 하위 프로그램이나 함수의 퍼센티지이다.

SW.007 안전 요구사항 검증

SW Table 13 — 소프트웨어 테스트 수행을 위한 테스트 환경

No	Methods	ASIL
No	Methods	A	B	C	D
1a	루프 내의 하드웨어	++	++	++	++
1b	전자 제어 장치 네트워크 환경	++	++	++	++
1c	차량	+	+	++	++

SW Table 14 — 소프트웨어 안전 요구사항 테스트 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 기반 테스트	++	++	++	++
1b	결함 주입 테스트	+	+	+	++

SW Table 15 — 소프트웨어 안전 요구사항 검증을 위한 테스트케이스 도출 방법

No	Methods	ASIL
No	Methods	A	B	C	D
1a	요구사항 분석	++	++	++	++
1b	동치 클래스 생성 및 분석	+	++	++	++
1c	경계 값 분석	+	+	++	++
1d	지식 및 경험 기반 오류 추측	+	+	++	++
1e	기능적 의존성 분석	+	+	++	++
1f	운영 사용 사례 분석	+	++	++	++

자동차 융합형 전장부품 고안전 기술지원 플랫폼

사이트맵