공간 / 방사 환경에서 C ++ 템플릿 사용이 권장되지 않는 이유는 무엇입니까?

공간 / 방사 환경에서 C ++ 템플릿 사용이 권장되지 않는 이유는 무엇입니까?

---

예를 들어이 질문 을 읽음으로써 나는 우주 나 원자력 발전소와 같이 방사선이 높은 환경에서 동적 할당 또는 예외가 권장되지 않는 이유를 이해했습니다. 템플릿과 관련하여 이유를 모르겠습니다. 설명해 주시겠습니까?

이 답변을 고려 하면 사용하는 것이 매우 안전하다고 말합니다.

참고 : 복잡한 표준 라이브러리에 대해 말하는 것이 아니라 목적에 맞게 만들어진 사용자 지정 템플릿에 대해 이야기합니다.

---

공간 호환 ( 방사선 강화 , 항공 준수) 컴퓨팅 장치는 매우 비싸고 ( 무게가 킬로그램을 초과하기 때문에 우주에서 발사 하는 데 포함 ), 단일 우주 임무 비용은 약 1 억 유로 또는 미화로 계산됩니다. 소프트웨어 또는 컴퓨터 문제로 인해 임무를 잃는 것은 일반적으로 엄청난 비용이 들기 때문에 용납 할 수 없으며 휴대 전화 애플릿 개발에 사용하는 꿈도 꾸지 않을 비용이 많이 드는 개발 방법 및 절차를 정당화하며 확률 적 추론 및 엔지니어링 접근 방식을 사용하는 것이 좋습니다. 우주선여전히 "비정상적인"이벤트입니다. 높은 수준의 관점에서 볼 때 우주선과 그것이 생성하는 비트 플립은 추상적 인 형태의 신호 또는 입력에서 노이즈로 간주 될 수 있습니다. "무작위 비트 플립"문제를 신호 대 잡음비 문제로 볼 수 있습니다. 그러면 무작위 알고리즘 이 유용한 개념적 프레임 워크를 제공 할 수 있습니다 (특히 메타 수준, 즉 안전에 중요한 소스 코드를 분석 하거나 컴파일 할 때). 바이너리, 정보 이론 관점 에서 중요한 시스템 런타임, 정교한 커널 또는 스레드 스케줄러 ) .

공간 / 방사 환경에서 C ++ 템플릿 사용이 권장되지 않는 이유는 무엇입니까?

그 권고는이다 일반화 의, C ++로, MISRA C 코딩 규칙과의 임베디드 C ++ 규칙, 그리고 DO178C의 권고 , 그리고 방사선 관련이 없습니다 만, 임베디드 시스템에. 복사 및 진동 제약으로 인해 모든 우주 로켓 컴퓨터의 임베디드 하드웨어는 매우 작아야합니다 (예 : 경제적 및 에너지 소비 이유로 인해 대형 x86 서버 시스템보다 라즈베리 파이와 유사한 시스템). ). 공간 강화 칩은 민간용 칩보다 1000 배 더 비쌉니다. 그리고 공간에 내장 된 컴퓨터 에서 WCET 를 계산하는 것은 여전히 ​​기술적 인 문제입니다 (예 : CPU 캐시관련 문제). 따라서 안전이 중요한 임베디드 소프트웨어 집약적 시스템 에서는 힙 할당 이 눈살을 찌푸리게됩니다 (이러한 시스템에서 메모리 부족 상태를 어떻게 처리 하시겠습니까? 아니면 모든 실시간 런타임 사례에 충분한 RAM이 있음 을 어떻게 증명할 수 있습니까?)

안전이 중요한 소프트웨어 세계 에서는 어떻게 든 "보증"또는 "약속"하고 확실히 평가 (종종 현명한 확률 적 추론을 통해) 할뿐만 아니라 자체 소프트웨어의 품질뿐만 아니라 사용되는 모든 소프트웨어 도구에 대해 빌드하십시오 (특히 : 컴파일러 및 링커; Boeing 또는 Airbus는 FAA 또는 DGAC의 사전 서면 승인 없이 비행 제어 소프트웨어를 컴파일하는 데 사용되는 GCC 크로스 컴파일러 버전을 변경하지 않습니다 ). 대부분의 소프트웨어 도구는 승인 또는 인증을 받아야합니다.

,주의하십시오 실제로 , 대부분의 C ++ (하지만 당연히 모두) 템플릿을 내부적으로 힙을 사용합니다. 그리고 표준 C ++ 컨테이너는 확실히 그렇습니다. 힙을 사용 하지 않는 템플릿을 작성 하는 것은 어려운 작업입니다. 가능하다면 템플릿을 안전하게 사용할 수 있습니다 (C ++ 컴파일러와 템플릿 확장 기계를 신뢰한다고 가정하면 GCC 또는 Clang 같은 최신 C ++ 컴파일러의 C ++ 프런트 엔드에서 가장 까다로운 부분입니다 ).

비슷한 (도구 세트 안정성) 이유로 인해 많은 소스 코드 생성 도구 를 사용하는 것이 눈살을 찌푸리는 것 같습니다 ( 예 : C ++ 또는 C 코드 생성 과 같은 일종의 메타 프로그래밍 수행 ). 예를 들어, 일부 안전에 중요한 소프트웨어 ( 및로 컴파일 됨 )에서 bison(또는 RPCGEN ) 을 사용하는 경우 및 뿐만 아니라 를 평가 (그리고 아마도 철저하게 테스트)해야합니다 . 이것은 과학적인 이유가 아니라 공학적인 이유입니다. 일부 임베디드 시스템은 무작위 알고리즘을 사용할 수 있습니다 . 특히 잡음이 많은 경우makegccgccmakebison입력 신호 (아마도 드문 우주선으로 인해 임의의 비트가 뒤집힐 수도 있음). 이러한 무작위 기반 알고리즘을 증명, 테스트 또는 분석 (또는 평가)하는 것은 매우 어려운 주제입니다.

으로도 봐 FRAMA - 연타 와 CompCert 하고 다음을 준수하십시오

• C ++ 11 (또는 다음) 은 매우 복잡한 프로그래밍 언어 입니다. 완전한 형식적 의미 가 없습니다 . C ++ 전문가는 전 세계적으로 수십 명에 불과합니다 (아마도 대부분은 표준위원회에 있습니다). 나는 C ++로 코딩 할 수 있지만 이동 의미론이나 C ++ 메모리 모델의 모든 미묘한 모퉁이 사례를 설명 할 수는 없습니다 . 또한 C ++는 실제로 효율적으로 사용하기 위해 많은 최적화가 필요합니다.

• 오류가없는 C ++ 컴파일러를 만드는 것은 매우 어렵습니다 . 특히 C ++는 실제로 까다로운 최적화 가 필요 하고 C ++ 사양의 복잡성으로 인해 더욱 그렇습니다 . 그러나 현재의 것 (최근 GCC 또는 Clang과 같은)은 실제로 매우 훌륭하며 잔여 컴파일러 버그가 거의 없습니다. 아직 C ++ 용 CompCert ++는 없으며 하나를 만들려면 수백만 유로 또는 US $가 필요합니다 (하지만 그러한 금액을 모을 수있는 경우 이메일 (예 : 내 업무 이메일)로 저에게 연락 하십시오basile.starynkevitch@cea.fr ). 그리고 우주 소프트웨어 산업은 매우 보수적입니다.

• 좋은 C 또는 C ++ 힙 메모리 할당자를 만드는 것은 어렵습니다 . 코딩 하나는 절충안의 문제입니다. 농담 으로이 C 힙 할당자를 C ++에 적용하는 것을 고려하십시오 .

• 템플릿 관련 C ++ 코드의 안전성 특성 (특히 경쟁 조건 부족 또는 런타임시 버퍼 오버플로와 같은 정의되지 않은 동작 ) 을 입증하는 것은 2019 년 2 분기에도 여전히 C ++ 코드 의 정적 프로그램 분석 기술보다 약간 앞서 있습니다. . 내 Bismon 기술 보고서 초안 (H2020 초안으로 제공되므로 유럽 관료의 경우 페이지를 건너 뛰십시오)에 자세한 내용을 설명하는 여러 페이지가 있습니다. 알고 있어야 라이스의 정리 .

• 전체 시스템 C ++ 임베디드 소프트웨어 테스트 에는 로켓 발사 ( Ala Ariane 5 테스트 비행 501 또는 적어도 실험실에서 복잡하고 무거운 실험) 가 필요할 수 있습니다. 그것은 이다 매우 비싸다 . 심지어 대지,에, 테스트 로버 화성 소요 많은 돈을.

생각해보십시오. 안전에 중요한 임베디드 소프트웨어 (예 : 열차 제동, 자율 주행 차량, 자율 드론, 대형 석유 플랫폼 또는 정유 공장, 미사일 등)를 코딩하고 있습니다. C ++ 표준 컨테이너, 예를 들어 일부 std::map<std::string,long>. 메모리 부족 상태에 대해 어떻게해야합니까? 1 억 유로의 우주 로켓에 자금을 지원하는 조직에서 일하는 사람들에게 임베디드 소프트웨어 (개발에 사용 된 컴파일러 포함)가 충분하다는 것을 어떻게 "증명"하거나 최소한 "설득"합니까? 10 년 전의 규칙은 모든 종류의 동적 힙 할당을 금지하는 것이 었습니다.

나는 복잡한 표준 라이브러리에 대해 말하는 것이 아니라 의도적으로 만들어진 사용자 정의 템플릿에 대해 이야기하고 있습니다.

이것조차도 증명하기 어렵 거나 일반적으로 품질을 평가하기 가 어렵습니다 (그리고 아마도 그들 안에 자신의 할당자를 사용하고 싶을 것입니다 ). 우주에서 코드 공간은 강력한 제약입니다. 따라서 예를 들어 g++ -Os -Wall또는 clang++ -Os -Wall. 하지만에서 수행 한 모든 미묘한 최적화를 어떻게 증명 했습니까 (또는 단순히 테스트 했습니까) -Os(그리고 이들은 GCC 또는 Clang의 버전에 따라 다릅니다)? 귀하의 우주 자금 지원 기관은 임베디드 C ++ 우주 소프트웨어의 런타임 버그가 임무를 충돌시킬 수 있기 때문에 귀하에게 요청할 것입니다 ( Ariane 5 첫 번째 비행 실패 에 대해 다시 읽으십시오 . 그 당시에는 "더 나은"및 오늘날 C ++ 17보다 "안전한"유형 시스템),하지만 유럽인을 너무 많이 웃지 마십시오.737 MAX 보잉 그와 MACS 것은 A는 유사한 혼란 ).

---

제 개인적인 추천은 (하지만 너무 심각하게 받아들이지는 마세요. 2019 년에는 다른 어떤 것보다 말장난이 될 것 입니다.) Rust로 스페이스 임베디드 소프트웨어를 코딩하는 것을 고려하는 것이 좋습니다. C ++보다 약간 더 안전하기 때문입니다. 물론 우주 컴퓨터에 적합한 훌륭한 Rust 컴파일러를 얻으려면 5 ~ 7 년 안에 5 ~ 10M € (또는 MUS $)를 써야합니다. 자유 소프트웨어 Compcert / Rust like 컴파일러). 그러나 그것은 소프트웨어 엔지니어링 및 소프트웨어 프로젝트 관리의 문제 일뿐 입니다 (더 많은 정보 는 Mythical Man-Month 및 Bullshit 작업 을 모두 읽으십시오. Dilbert 원칙 도 알고 있어야합니다.: 우주 소프트웨어 산업 또는 임베디드 컴파일러 산업에 적용됩니다.)

내 강하고 개인적인 의견은 유럽위원회 (예를 통해 자금을해야한다는 것입니다 호라이즌 유럽 a)는 자유 소프트웨어 프로젝트와 같은 (더 나은 또는, Compcert / 녹) CompCert ++ (와 같은 프로젝트가 5 년 이상 이상 상위 5 필요 -클래스, 박사 연구원). 그러나, 60 세의 나이에, 나는 슬프게도이 -mostly 분명 reasons-을위한 독일 정책에 의해 영감 EC 이데올로기는 여전히 환상 때문에 (일어나지 않을 것을 알고 역사의 끝 H2020과 지평선 유럽 그래서,에, 관행, 주로 유럽 조세 피난처를 통해 유럽의 기업에 대한 세금 최적화를 구현하는 방법 ), 그리고 CompCert 프로젝트의 여러 구성원과 몇 차례의 비공개 토론 후. 슬프게도 DARPA를 기대합니다또는 NASA 가 향후 CompCert / Rust 프로젝트에 자금을 지원할 가능성이 훨씬 더 높습니다 (EC 자금 조달보다).

---

NB. The European avionics industry (mostly Airbus) is using much more formal methods approaches that the North American one (Boeing). Hence some (not all) unit tests are avoided (since replaced by formal proofs of source code, perhaps with tools like Frama-C or Astrée - neither have been certified for C++, only for a subset of C forbidding C dynamic memory allocation and several other features of C). And this is permitted by DO-178C (not by the predecessor DO-178B) and approved by the French regulator, DGAC (and I guess by other European regulators).

Also notice that many SIGPLAN conferences are indirectly related to the OP's question.

---

The argumentation against the usage of templates in safety code is that they are considered to increase the complexity of your code without real benefit. This argumentation is valid if you have bad tooling and a classic idea of safety. Take the following example:

template<class T>  fun(T t){
   do_some_thing(t);
}

In the classic way to specify a safety system you have to provide a complete description of each and every function and structure of your code. That means you are not allowed to have any code without specification. That means you have to give a complete description of the functionality of the template in its general form. For obvious reasons that is not possible. That is BTW the same reason why function-like macros are also forbidden. If you change the idea in a way that you describe all actual instantiations of this template, you overcome this limitation, but you need proper tooling to prove that you really described all of them.

The second problem is that one:

fun(b);

This line is not a self-contained line. You need to look up the type of b to know which function is actually called. Proper tooling which understands templates helps here. But in this case it is true that it makes the code harder to check manually.

---

This statement about templates being a cause of vulnerability seems completely surrealistic to me. For two main reasons:

• templates are "compiled away", i.e. instantiated and code-generated like any other function/member, and there is no behavior specific to them. Just as if they never existed;

• no construction in any language is neither safe or vulnerable; if an ionizing particule changes a single bit of memory, be it in code or in data, anything is possible (from no noticeable problem occurring up to processor crash). The way to shield a system against this is by adding hardware memory error detection/correction capabilities. Not by modifying the code !

참고URL : https://stackoverflow.com/questions/56557596/why-is-c-template-use-not-recommended-in-a-space-radiated-environment