Certification Liaison Process

This process is specified in DO-178C. It is a kind of communication process with Certification Authority. It is very important for suppliers to get a good results. I’ve never  experienced about type certification or airworthiness certification, but I think that I can imagine the procedure because there are published document.

Though it is natural to think, applicant has to submit safety plan to certification body and it can be proceed if the plan is approved by certification authority.

It would be ridiculous if applicant submit safety plan in the middle of the project. What if the plan is rejected? Everything they have done so far must be dumped.

Unfortunately this process is not defined in the automotive, but it also essential for supplier. Competent OEM may have a detailed process for audit and assessment.

You can also refer a book, “Developing Safety-Critical Software(DO-178C)” in chapter 12

 

Software verification by analysis

모름지기 functional safety software를 개발한다고 하면 이정도 쯤은 해야…

놀랍게도 UA를 일으킨 Toyota의 ETC제품 sw에서 다음의 사항들에 대한 분석 evidence가 거의 없거나 매우 빈약했다.
(그렇다고 직접적인 연관이 있었다는 것은 아니고)

1. Worst-Case Execution Time Analysis

2. Memory Margin Analysis

3. Link and Memory Map Analysis

4. Load Analysis

5. Interrupt Analysis

6. Math Analysis

7. Errors and Warnings Analysis

8. Partitioning Analysis

시스템 요구사항의 고려사항

1. 무결성 및 가용성 고려사항

시스템 요구사항은 무결성(기능 및 운영의 정확함) 및 가용성(기능의 연속성) 양쪽 모두를 언급해야 한다.

• 무결성: “정확하게 동작한다고 믿을 수 있음을 나타내는 시스템 또는 아이템의 질적 또는 양적 특성(Qualitative or quantitative attribute). 이는 때때로 작업이 정확하게 기준을 충족하지 못하는 확률을 사용하여 표현된다.”
• 가용성: 시스템 또는 아이템이 적시에 주어진 지점의 작동 상태(functioning state)에 있는 질적 또는 양적 특성. 이는 때때로 시스템이 출력을 제공하지 못하는 확률(즉, unavailability)을 사용하여 표현된다.

무결성의 손실은 시스템의 부정확한 운영을 초래한다. 예는 기본 비행 디스플레이에 교통 충돌 및 회피 시스템(TCAS; traffic collision and avoidance system)부정확한 해결책 조언, 또는 자동 조종 장치 hardover의 잘못된 데이터를 포함한다. 무결성을 위한 설계를 위해, 방지하거나 고장을 무력화(neutralize faults)하기 위해 주로 아키텍처적 완화가 요구된다. 이것은 무결성 결함을 방지하고 또는 이러한 유형의 결함을 보호하기 위해 중복 구현, 파티셔닝, 모니터링, 비유사성 또는 다른 완화 전략의 사용을 포함할 수 있다. 또한, 무결성을 해결하기 위해, 결함 감지 및 응답 또는 결함 방지는 종종 적용될 수 있고 시스템 요구사항으로 파악되어야 한다.

많은 시스템은 가용성의 손실로부터의 보호를 요구한다. 가용성은 기능적 동작이 모든 예측 가능한 사용 조건(정상 및 비정상 상태를 포함하여)하에서 연속적이고 복구 가능 해야 한다는 점에서 무결성과 다르다. 주요 기능은 하드웨어 우발 결함, 데이터 결함 또는 소프트웨어 및 하드웨어 upset 동안 또는 이후에 이용 가능해야 한다.

높은 가용성을 요구하는 시스템 또는 기능은 일반적으로 매우 높은 신뢰성을 가지고 중복 구현을 활용한 장치를 요구한다. 중복 설계가 가용성을 보장하기 위해 사용되면, 그것들은 결함을 견디는 것(tolerate fault)과 결함을 신속하게 탐지하고 복구가 가능해야 한다. 중복 설계를 통합하는 시스템은 일반적으로 중복 관리 및 결함 관리 요구 사항이 있다.

몇 가지 디자인 결정이 무결성과 가용성 모두에 영향을 미칠 수 있음을 유의해야 한다. 이 두 가지는 모두 고려되어야 한다. 예를 들어, 시스템은 가용성을 손상시키지 않고 무결성 결함을 완화 할 필요가 있다. ARP4754의 원래 버전은 비유사성의 사용을 고려할 때 무결성과 가용성 사이의 관계를 나타낸다: “아키텍처 비유사성이 무결성 및 가용성 모두에 영향을 미친다는 점을 주목해야 한다. 무결성의 증가는 가용성의 감소와 연관될 수 있기 때문에, 반대의 경우도 마찬가지로, 특정 응용프로그램은 적합성을 확인하기 위해 두 관점에서 분석되어야 한다.

 

2. 다른 시스템 요구사항에 대한 고려사항

무결성 및 가용성에 대한 문제 외에도, 시스템 명세에서 다음을 포함하여 고려해야 하는 다른 측면들이 있다. 기능 hazard 평가 또는 후속 안전 분석에 의해 나타나는 요구 사항.

1. 안전 요구사항, 즉, 기능 hazard 평가 또는 후속 안전 분석에 의해 도출된 요구 사항.
2. 결함 허용은 결함 영역의 식별을 포함한 시스템에 영향을 미친다. 전자 아키텍처와 통합 안전 시스템을 위한 시스템 엔지니어링(BASIS) 컨소시엄은 결함 영역을 “장애가 어디에 위치했는지, 어떻게 발생했는지, 결함 영역 내에서 얼마나 멀리 확장되는지에 관계없이 내부 장애(internal disturbances)는 정확히 하나의 결함으로 계산되는 컴포넌트 세트”로 식별한다.
3. 어떤 고립 영역(containment regions)에 대한 필요성을 포함한, 정상적인 저하(Graceful degradation) (예, 고장 안전 모드). EASIS는 “고립 영역(containment region)은 각 고장에 의해 부정적인 영향을 받았을 수 있는 컴포넌트의 세트이다. 다시 말해: 방지 영역은 결함 전파가 중단되어야 하는 경계를 정의한다” 라고 설명한다. 예는 비행 표면을 이동하거나 조종사가 응답하기 전에 플래그된 실패한 데이터 전에 자동 조종 장치 결함 감지를 포함한다.
4. 다음과 같은 에러 감지:
   1. 데이터 확인—범위, fresh, 단락 회로, 개방 회로에서 데이터가 유효한지 확인하기 위해 데이터를 검사하는 것
   2. 중복 데이터의 비교—중복 센서 또는 프로세싱 유닛과 출력을 비교 하는 것
   3. 프로세서와 메모리에서 에러 확인—예를 들어, built-in 테스트를 수행, 워치독 타이머를 사용, ROM 또는 플래시 메모리의 체크섬 계산, built-in 프로세서 예외 사용, 메모리 검사 수행, 또는 RAM 읽기/쓰기 테스트
   4. 통신 모니터링—분산 시스템에서 수신 메시지의 확인을 수행하는 것, 예를 들어, 메시지 제한 시간(message timeout), 메시지 시퀀스 카운터, 또는 체크섬 확인
5. 검출된 오류의 오류 처리. 오류 처리의 몇 가지 예는 다음과 같다.
   1. 기능을 종료
   2. 성능이 저하된 모드로 진입
   3. 사용자에게 안내 제공
   4. 실패한 시스템과 상호작용하는 다른 시스템에게 메시지 전송
   5. 시스템을 리셋하고 이전 상태로 복귀
   6. 다른 신뢰할 수 있는 데이터 사용(입력 에러가 감지되었을 때)
   7. 에러가 연속 발생시 타임 아웃이나 시스템을 셧다운

6. 시스템이 하드웨어 오류에 응답하는 방법을 다루는 결함 감지 및 처리 (연속 또는 랜덤 응답과 같은)
7. 높은 품질 소자를 선택하여 처리(더 높게 지정된 고장 사이의 평균 시간), 전자기 간섭 등에 의한 환경적 영향에 대한 보호, 요구사항에서 특정 금지된 결함을 식별 그리고/또는 구조적 취약성을 제거하여 결함 회피.
8. 아키텍처 또는 설계에 대한 요구사항(즉, 중복, 비교 확인, 투표 방법). 이것이 요구사항과 설계 사이의 경계를 다소 흐리게 할 수 있지만, 구현 시 고려해야 할 사항은 무엇이든 식별하는 것은 중요하다. 요구사항의 해설은 너무 빨리 설계를 정의하지 않고 설계 고려사항을 식별하는 일반적인 방법이다.
9. 제조 공정에 대한 요구사항. 이러한 요구 사항은 하드웨어 제조 및 생산 과정의 주요 특성을 문서화.
10. 기능 제한. 시스템은 임의의 공지 된 또는 원하는 한계에 규정 될 필요가 있다. 예를 들어, 몇 가지 기능은 특정 비행 단계 또는 사용의 범위 동안에만 허용될 수 있다.
11. 중요한 기능. 이러한 요구사항은 고장으로 인한 중요한 기능의 손실을 방지하기 위해 필요하다.
12. 결함의 봉쇄 또는 격리를 제공하기 위한 파티셔닝 또는 보호. 덜 중요한 기능은 더 적은 확인 및 검증의 엄격함을 요구하기 때문에 파티셔닝 또는 보호는 확인 및 검증의 노력을 줄이기 위해 사용될 수 있다.
13. 둘 또는 더 많은 아이템에서 공통 고장을 회피하기 위해 사용될 수 있는 다양성. 다양성의 예는 다른 설계, 알고리즘, 도구(예, 컴파일러) 또는 기술들을 포함한다[5].
14. 결함 허용을 달성하기 위해 또는 단일점 결함을 회피하기 위해 사용되는 중복. 중복 컴포넌트는 다수의 프로세서, 센서 등을 포함한다.
15. 조종석 응답 시간, 오류 감지 및 응답, 전원 가동 시간, 재시작 시간 등과 같은 문제를 해결하기 위한 타이밍 관련 요구사항,
16. 초기화, 콜드 스타트, 웜 스타트 그리고 전원 차단 요구사항을 포함하는 순서(sequence)
17. 비행 단계, 연관 및 분리된 결정, 모드 선택 등의 모드 및 상태 전이
18. 필요한 환경적 안전성을 반영하기 위한 환경적 인증 수준. 수준은 시스템의 중요성, 예상된 설치 환경 및 규제 요구 사항에 따라 달라진다. RTCA/ DO-160[ ]는 민간 항공기에 설치된 장비에 대한 환경 인증 절차를 설명한다.
19. 안전 고려 사항이 적절하게 구현되도록 하기 위하여 필요할 수 있는 시험 규정. 예를 들면 테스트 노력을 지원하기 위한 자극 입력, 데이터 기록, 또는 다른 장비의 인터페이스를 포함한다.
20. 높은 고도에서 발생하는 방사선의 영향으로부터 항공 시스템을 보호하기 위한 몇 가지 항공 프로젝트에 필요한 단일 및 다중 이벤트 고장 보호(Single and multiple event upset protections). 일반적인 해법의 예는 연속 기본 테스트, 에러 정정 코드, 투표 방식, 및 경화된 하드웨어(hardened hardware)를 포함한다.
21. 특히 안전 분석 가정을 지원하기 위한 신뢰성 및 유지 관련 고려 사항: 결함 및 관련된 데이터 logging, 시작 테스트 그리고 조작(rigging).
22. (숨겨진) 잔여 잠재 결함의 가능성을 줄이기 위한 지연 요구사항. 예를 들면 고장 식별 및 유지 보수 또는 built-in 테스트 간격에 대한 경고를 포함한다.
23. 적절한 시스템 사용을 보장하기 위한 사용자 및 휴먼 인터페이스 요구사항. 인적 요소의 요구를 해결하고 운영상 문제를 최소화 하기 위해 광범위한 인증 지침 및 기준이 존재한다.
24. 적절한 사용 및 유지를 보장하기 위한 유지보수 요구사항 또는 제한사항
25. 시스템 아키텍처가 안전 감시를 요구할 때, 안전 감시 요구사항.
26. 암호화, 설정 및 부하 검사 그리고 인터페이스 배리어와 같은 보호를 포함한 보안 고려사항.
27. 타이밍 및 메모리 여분, 노후화된 기술의 최소화 등과 같은 추후 성장 및 유연성 요구.