방사성이 높은 환경에서 사용하기위한 응용 프로그램 컴파일

우리는 이온화 방사선으로 폭격 된 환경에서 차폐 장치에 배치 된 임베디드 C / C ++ 애플리케이션을 컴파일하고 있습니다. ARM에 대해 GCC 및 크로스 컴파일을 사용하고 있습니다. 배포 할 때 응용 프로그램에서 잘못된 데이터가 생성되어 원하는 빈도보다 자주 충돌합니다. 하드웨어는이 환경을 위해 설계되었으며, 당사의 응용 프로그램은이 플랫폼에서 몇 년 동안 실행되었습니다.

단일 이벤트로 인한 소프트 오류 및 메모리 손상 을 식별 / 수정하기 위해 코드를 변경하거나 컴파일 시간을 개선 할 수 있습니까? 다른 개발자가 장기 실행 응용 프로그램에서 소프트 오류의 유해한 영향을 줄이는 데 성공 했습니까?

소프트웨어 / 펌웨어 개발 및 소형 위성 의 환경 테스트를 통해 약 4-5 년 동안 일한 경험을 공유하고 싶습니다.

* ( 소형 위성은 전자 부품의 크기가 상대적으로 작고 크기가 커서 대형 위성보다 단일 이벤트가 발생하기 쉽습니다 )

매우 간결하고 직접적으로 : 복구 할 메커니즘이 없습니다 감지, 잘못된 상황 소프트웨어로는 / 자체 펌웨어 없이 적어도 하나는, 복사 의 최소 작업 버전 소프트웨어 / 펌웨어의 어딘가 를위한 복구 목적 -와 함께 하드웨어 지원 회복 (기능).

이제이 상황은 일반적으로 하드웨어 및 소프트웨어 수준에서 모두 처리됩니다. 요청하신대로 소프트웨어 수준에서 수행 할 수있는 작업을 공유하겠습니다.

1. ... 복구 목적으로 ... . 실제 환경에서 소프트웨어 / 펌웨어를 업데이트 / 재 컴파일 / 리 플래시하는 기능을 제공합니다. 이것은 고도로 이온화 된 환경에서 모든 소프트웨어 / 펌웨어에 대해 거의 필수 기능입니다. 이것이 없다면, 당신 은 원하는만큼 중복 소프트웨어 / 하드웨어를 가질 수 있지만, 어느 시점에서 그것들은 모두 폭발 할 것입니다. 이 기능을 준비하십시오!

2. ... 최소 작업 버전 ... 코드에 반응 형, 여러 복사본, 최소 버전의 소프트웨어 / 펌웨어가 있습니다. 이것은 Windows의 안전 모드와 같습니다. 소프트웨어의 완전한 기능을 갖춘 버전이 하나만있는 대신 최소 버전의 소프트웨어 / 펌웨어 사본이 여러 개 있습니다. 최소 사본은 일반적으로 전체 사본보다 크기가 훨씬 작으며 거의 ​​항상 다음 두세 가지 기능 만 갖습니다 .

   1. 외부 시스템에서 명령을들을 수 있음
   2. 현재 소프트웨어 / 펌웨어 업데이트 가능
   3. 기본 운영 하우스 키핑 데이터를 모니터링 할 수 있습니다.

3. ... 복사 ... 어딘가 ... 어딘가에 중복 소프트웨어 / 펌웨어가 있습니다.

   1. 당신은 함께 할 수 또는 여분의 하드웨어없이, 당신의 ARM uc에에 중복 소프트웨어 / 펌웨어를하려고합니다. 이것은 일반적으로 하트 비트를 보내는 별도의 주소에 둘 이상의 동일한 소프트웨어 / 펌웨어 를 보유함으로써 이루어 지지만 한 번에 하나만 활성화됩니다. 하나 이상의 소프트웨어 / 펌웨어가 응답하지 않는 것으로 알려진 경우 다른 소프트웨어 / 펌웨어로 전환하십시오. 이 방법을 사용하면 오류를 감지하고 복구 할 책임이있는 외부 시스템 / 당사자와 접촉하지 않고 오류가 발생한 직후 즉시 기능을 교체 할 수 있다는 이점이 있습니다 (위성의 경우 일반적으로 임무 제어 센터 ( MCC)).

      엄밀히 말하면, 여분의 하드웨어가 없으면이 작업의 단점은 실제로 모든 단일 장애 지점을 제거 할 수 없다는 것 입니다. 적어도, 당신은 여전히 것 중 하나 개 입니다 단일 장애 지점, 스위치 자체 (보통 또는 코드의 시작). 그럼에도 불구하고 고도로 이온화 된 환경 (예 : 피코 / 펨토 위성)에서 크기가 제한된 장치의 경우 추가 하드웨어 없이 단일 지점 지점을 한 지점으로 줄이면 여전히 고려할 가치가 있습니다. 또한, 전환을위한 코드는 전체 프로그램의 코드보다 훨씬 작을 것입니다. 단일 이벤트가 발생할 위험을 크게 줄입니다.

   2. 그러나이 작업을 수행하지 않는 경우 외부 시스템에 장치와 접촉하여 소프트웨어 / 펌웨어를 업데이트 할 수있는 사본이 하나 이상 있어야합니다 (위성 경우에는 다시 임무 제어 센터 임).

   3. 또한 실행중인 시스템의 소프트웨어 / 펌웨어를 복원하도록 트리거 할 수있는 장치의 영구 메모리 저장소에 사본을 보유 할 수도 있습니다.

4. ... 오류가 감지 될 수 있습니다. 오류는 대개 하드웨어 오류 정정 / 검출 회로 또는 오류 정정 / 검출 을위한 작은 코드 로 감지 할 수 있어야합니다 . 이러한 코드는 작고 여러 개이며 주 소프트웨어 / 펌웨어 와 독립적 으로 설정하는 것이 가장 좋습니다 . 주요 작업입니다 만 확인 / 수정을 위해. 하드웨어 회로 / 펌웨어가 신뢰할 수있는 경우(예를 들어, 나머지 회로보다 방사선이 강화되거나 여러 회로 / 논리가있는 경우) 오류 수정을 고려할 수 있습니다. 그러나 그렇지 않은 경우 오류 감지로 만드는 것이 좋습니다. 외부 시스템 / 장치에 의해 수정 될 수 있습니다. 오류 수정의 경우 회로 / 소프트웨어에서 더 쉽게 구현할 수 있기 때문에 Hamming / Golay23과 같은 기본 오류 수정 알고리즘을 사용할 것을 고려할 수 있습니다. 그러나 그것은 궁극적으로 팀의 능력에 달려 있습니다. 오류 감지에는 일반적으로 CRC가 사용됩니다.

5. ... 복구를 지원하는 하드웨어 이제이 문제에서 가장 어려운 부분이되었습니다. 궁극적으로 복구에는 최소한 복구 기능 을 담당하는 하드웨어가 필요합니다 . 하드웨어가 영구적으로 고장난 경우 (일반적으로 총 이온화 용량 이 특정 수준에 도달 한 후 발생 ) 소프트웨어가 복구에 도움을 줄 수있는 방법은 없습니다. 따라서 하드웨어는 높은 수준의 방사선 (예 : 위성)에 노출 된 장치에서 가장 중요한 관심사입니다.

단일 이벤트로 인한 위의 펌웨어 오류 예상에 대한 제안 외에도 다음 사항을 제안합니다.

1. 서브 시스템 간 통신 프로토콜에서의 오류 검출 및 / 또는 오류 정정 알고리즘. 이것은 다른 시스템으로부터 불완전한 / 잘못된 신호를 수신하지 않기 위해 반드시 가져야 할 다른 것입니다.

2. ADC 판독 값을 필터링하십시오. 하다 하지 직접 읽는 ADC를 사용합니다. 중앙값 필터, 평균 필터 또는 다른 필터로 필터링하십시오 . 단일 판독 값을 신뢰 하지 마십시오 . 적지 않게 더 많이 샘플링하십시오.

NASA는 방사선 경화 소프트웨어 에 관한 논문을 가지고 있습니다. 세 가지 주요 작업에 대해 설명합니다.

1. 오류에 대한 정기적 인 메모리 모니터링 및 오류 제거
2. 강력한 오류 복구 메커니즘
3. 더 이상 작동하지 않는 경우 재구성하는 기능.

대부분의 ECC 메모리는 멀티 비트 오류가 아닌 단일 비트 오류에서 복구 할 수 있으므로 메모리 스캔 속도는 멀티 비트 오류가 거의 발생하지 않을 정도로 자주 발생해야 합니다.

강력한 오류 복구에는 제어 흐름 전송 (일반적으로 오류 이전 시점에서 프로세스 다시 시작), 리소스 릴리스 및 데이터 복원이 포함됩니다.

데이터 복원에 대한 주요 권장 사항은 중간 데이터를 임시로 처리하여 오류가 발생하기 전에 다시 시작해도 데이터가 안정적인 상태로 롤백되도록함으로써 데이터가 필요하지 않도록하는 것입니다. 데이터베이스의 "트랜잭션"개념과 비슷합니다.

C ++과 같은 객체 지향 언어에 특히 적합한 기술에 대해 설명합니다. 예를 들어

1. 연속 메모리 객체를위한 소프트웨어 기반 ECC
2. 계약에 의한 프로그래밍 : 사전 조건 및 사후 조건을 확인한 다음 개체가 여전히 유효한 상태인지 확인합니다.

NASA는 Mars Rover 와 같은 주요 프로젝트에 C ++을 사용했습니다 .

C ++ 클래스 추상화 및 캡슐화를 통해 여러 프로젝트 및 개발자 간의 신속한 개발 및 테스트가 가능해졌습니다.

문제를 일으킬 수있는 특정 C ++ 기능을 피했습니다.

1. 예외
2. 템플릿
3. Iostream (콘솔 없음)
4. 다중 상속
5. 연산자 과부하 ( new및 이외 delete)
6. 동적 할당 ( new시스템 힙 손상 가능성을 방지하기 위해 전용 메모리 풀 및 배치 사용 )

다음은 몇 가지 생각과 아이디어입니다.

보다 창의적으로 ROM을 사용하십시오.

ROM에 가능한 모든 것을 저장하십시오. 계산하는 대신 룩업 테이블을 ROM에 저장하십시오. (컴파일러가 조회 테이블을 읽기 전용 섹션으로 출력하는지 확인하십시오! 런타임에 메모리 주소를 인쇄하여 확인하십시오!) 인터럽트 벡터 테이블을 ROM에 저장하십시오. 물론 ROM과 RAM이 얼마나 안정적인지 확인하기 위해 몇 가지 테스트를 실행하십시오.

스택에 가장 적합한 RAM을 사용하십시오.

스택의 SEU는 아마도 인덱스 변수, 상태 변수, 반환 주소 및 다양한 종류의 포인터와 같은 것들이 존재하기 때문에 충돌의 원인 일 가능성이 높습니다.

타이머 틱 및 워치 독 타이머 루틴을 구현하십시오.

시스템 잠금을 처리하기위한 워치 독 루틴뿐만 아니라 타이머 틱마다 "위생 검사"루틴을 실행할 수 있습니다. 메인 코드는 정기적으로 카운터를 증가시켜 진행 상황을 표시 할 수 있으며, 온 전성 검사 루틴이이를 수행 할 수 있습니다.

오류 수정 코드 구현 소프트웨어를.

데이터에 중복성을 추가하여 오류를 감지 및 / 또는 수정할 수 있습니다. 이로 인해 처리 시간이 추가되어 프로세서가 방사선에 더 오랫동안 노출 될 수 있으므로 오류 가능성이 높아 지므로 절충을 고려해야합니다.

캐시를 기억하십시오.

CPU 캐시의 크기를 확인하십시오. 최근에 액세스하거나 수정 한 데이터는 캐시 내에있을 수 있습니다. 나는 적어도 일부 캐시를 비활성화 할 수 있다고 생각합니다 (성능 비용이 많이 듭니다). 캐시가 SEU에 얼마나 취약한 지 확인하려면이를 시도해야합니다. 캐시가 RAM보다 어려운 경우 중요한 데이터를 정기적으로 읽고 다시 쓰기하여 캐시에 유지되고 RAM을 다시 온라인 상태로 만들 수 있습니다.

페이지 오류 처리기를 영리하게 사용하십시오.

메모리 페이지를 존재하지 않는 것으로 표시하면 CPU는 액세스하려고 할 때 페이지 결함을 발행합니다. 읽기 요청을 처리하기 전에 몇 가지 검사를 수행하는 페이지 오류 처리기를 만들 수 있습니다. (PC 운영 체제는이를 사용하여 디스크로 스왑 된 페이지를 투명하게로드합니다.)

중요한 것 (모든 것이 될 수 있음)에 어셈블리 언어를 사용하십시오.

어셈블리 언어를 사용하면 레지스터의 내용과 RAM의 내용 을 알 수 있습니다 . 당신 은 알고있다CPU가 사용하는 특수 RAM 테이블 있으며 위험을 줄이기 위해 로터리 방식으로 물건을 설계 할 수 있습니다.

사용하다 objdump 사실에 어셈블리 생성 언어에서보고, 루틴 각각 차지하는 코드 해결.

Linux와 같은 큰 OS를 사용하는 경우 문제가 있습니다. 너무 많은 복잡성과 잘못 될 많은 것들이 있습니다.

그것은 확률 게임이라는 것을 기억하십시오.

한 논평자는 말했다

오류를 포착하기 위해 작성하는 모든 루틴은 동일한 원인으로 인해 실패 할 수 있습니다.

이것이 사실이지만, 검사 루틴이 올바르게 작동하는 데 필요한 100 바이트 코드 및 데이터의 오류 가능성은 다른 곳의 오류 가능성보다 훨씬 작습니다. ROM이 꽤 안정적이며 거의 모든 코드 / 데이터가 실제로 ROM에 있으면 확률이 훨씬 좋습니다.

중복 하드웨어를 사용하십시오.

동일한 코드로 2 개 이상의 동일한 하드웨어 설정을 사용하십시오. 결과가 다르면 재설정이 트리거되어야합니다. 3 개 이상의 장치를 사용하면 "투표"시스템을 사용하여 손상된 장치를 식별 할 수 있습니다.

알고리즘 내결함성 주제에 대한 풍부한 문헌에 관심이있을 수도 있습니다. 이것은 이전 할당이 포함되어 비교의 일정한 번호가 실패 할 때 올바르게 입력을 정렬 일종의 쓰기를 (또는 약간 더 악한 버전, 때와 실패 비교 저울의 점근 수 log(n)에 대한 n비교).

Huang과 Abraham의 1984 년 논문 " 매트릭스 연산에 대한 알고리즘 기반 내결함성 (Algorithm-Based Fault Tolerance) "을 읽으십시오 . 그들의 아이디어는 호 모모 픽 암호화 계산과 모호하게 유사합니다 (그러나 작동 수준에서 오류 감지 / 수정을 시도하기 때문에 실제로 동일하지는 않습니다).

이 백서의 최신 후손은 Bosilca, Delmas, Dongarra 및 Langou의 " 고성능 컴퓨팅에 적용된 알고리즘 기반 내결함성 "입니다.

방사성 환경을위한 코드 작성은 미션 크리티컬 한 애플리케이션을위한 코드 작성과 다르지 않습니다.

이미 언급 한 것 외에도 다음과 같은 기타 팁이 있습니다.

• 내부 전문 감시 시스템, 내부 저전압 감지, 내부 시계 모니터 등 모든 반 전문가 용 내장 시스템에 존재하는 일상적인 "빵 및 버터"안전 조치를 사용하십시오. 이러한 것들은 2016 년에도 언급 할 필요가 없으며 거의 ​​모든 최신 마이크로 컨트롤러에서 표준입니다.
• 안전 및 / 또는 자동차 지향 MCU가있는 경우 지정된 시간 창과 같은 특정 워치 독 기능이있어 내부에서 워치 독을 새로 고쳐야합니다. 미션 크리티컬 한 실시간 시스템이있는 경우에 선호됩니다.
• 일반적으로 이러한 종류의 시스템에 적합한 MCU를 사용하고 콘플레이크 패킷에 포함 된 일반적인 주류 보풀은 사용하지 마십시오. 오늘날 거의 모든 MCU 제조업체는 안전 애플리케이션 (TI, Freescale, Renesas, ST, Infineon 등)을 위해 설계된 특수 MCU를 보유하고 있습니다. 여기에는 잠금 단계 코어를 포함하여 많은 내장 안전 기능이 있습니다. 즉, 동일한 코드를 실행하는 2 개의 CPU 코어가 있으며 서로 동의해야합니다.

• 중요 : 내부 MCU 레지스터의 무결성을 보장해야합니다. 쓰기 가능한 하드웨어 주변 장치의 모든 제어 및 상태 레지스터는 RAM 메모리에 위치 할 수 있으므로 취약합니다.

  레지스터 손상을 방지하려면 레지스터의 내장 된 "한 번만 기록"기능이있는 마이크로 컨트롤러를 선택하는 것이 좋습니다. 또한 모든 하드웨어 레지스터의 기본값을 NVM에 저장하고 해당 값을 정기적으로 레지스터에 복사해야합니다. 같은 방식으로 중요한 변수의 무결성을 보장 할 수 있습니다.

  참고 : 항상 방어 프로그래밍을 사용하십시오. 애플리케이션에서 사용되는 레지스터뿐만 아니라 MCU에 모든 레지스터 를 설정해야한다는 의미입니다 . 임의의 하드웨어 주변 장치가 갑자기 깨워지는 것을 원하지 않습니다.

• RAM 또는 NVM의 오류를 확인하는 모든 종류의 방법이 있습니다 : 체크섬, "워킹 패턴", 소프트웨어 ECC 등 오늘날 가장 좋은 해결책은 이들 중 하나를 사용하지 않고 내장 ECC가있는 MCU를 사용하는 것입니다. 비슷한 검사. 소프트웨어에서이 작업을 수행하는 것은 복잡하기 때문에 오류 확인 자체에 버그와 예기치 않은 문제가 발생할 수 있습니다.

• 중복성을 사용하십시오. 휘발성 및 비 휘발성 메모리를 두 개의 동일한 "미러"세그먼트에 저장할 수 있으며 항상 동일해야합니다. 각 세그먼트에는 CRC 체크섬이 첨부 될 수 있습니다.
• MCU 외부에서 외부 메모리를 사용하지 마십시오.
• 가능한 모든 인터럽트 / 예외에 대해 기본 인터럽트 서비스 루틴 / 기본 예외 처리기를 구현하십시오. 사용하지 않는 것조차도. 기본 루틴은 자체 인터럽트 소스를 종료하는 것 외에는 아무 것도하지 않아야합니다.

• 방어 프로그래밍의 개념을 이해하고 수용하십시오. 이것은 프로그램이 이론 상으로는 일어날 수없는 경우를 포함하여 가능한 모든 경우를 처리해야 함을 의미합니다. 예 .

  고품질 미션 크리티컬 펌웨어는 가능한 많은 오류를 감지 한 후 안전한 방식으로 무시합니다.

• 잘못 지정된 동작에 의존하는 프로그램을 작성하지 마십시오. 방사선이나 EMI로 인한 예기치 않은 하드웨어 변경으로 인해 이러한 동작이 크게 변경 될 수 있습니다. 프로그램에 이러한 쓰레기가 없도록하는 가장 좋은 방법은 정적 분석기 도구와 함께 MISRA와 같은 코딩 표준을 사용하는 것입니다. 또한 방어 프로그래밍과 버그 제거에 도움이됩니다 (어떤 종류의 응용 프로그램에서 버그를 감지하지 않겠습니까?).

• 중요 : 정적 저장 기간 변수의 기본값에 의존하지 마십시오. 즉, .data또는 의 기본 내용을 신뢰하지 마십시오 .bss. 초기화 시점과 변수가 실제로 사용되는 시점 사이에 시간이 많이 소요될 수 있으며, RAM이 손상 될 시간이 충분했을 수 있습니다. 대신, 그러한 변수가 처음으로 사용되기 직전의 모든 변수가 런타임에 NVM에서 설정되도록 프로그램을 작성하십시오.

  실제로 이것은 변수가 파일 범위 또는로 선언되면 변수 를 초기화 static하는 =데 절대 사용해서는 안됩니다 (또는 가능하지만 아무리 값을 사용할 수 없기 때문에 의미가 없습니다). 사용 직전에 항상 런타임에 설정하십시오. NVM에서 이러한 변수를 반복적으로 업데이트 할 수 있으면 업데이트하십시오.

  C ++에서와 마찬가지로 정적 저장 기간 변수에 생성자를 사용하지 마십시오. 생성자 (들)가 공개 "설정"루틴을 호출하게하고,이 호출 루틴은 나중에 호출자 응용 프로그램에서 바로 호출 할 수 있습니다.

  가능하면 초기화 .data하고 .bssC ++ 생성자를 호출 하는 "복사"시작 코드를 제거하여 해당 코드에 의존하는 링커 오류가 발생하도록하십시오. 많은 컴파일러는 이것을 "초소 / 빠른 시작"또는 이와 유사한 것으로 건너 뛸 수 있습니다.

  이는 외부 라이브러리가 그러한 의존성을 포함하지 않도록 검사해야 함을 의미합니다.

• 중대한 오류가 발생할 경우 되돌릴 수있는 프로그램의 안전 상태를 구현하고 정의하십시오.

• 오류 보고서 / 오류 로그 시스템을 구현하는 것이 항상 도움이됩니다.

C를 사용하여 이러한 환경에서 강력하게 작동하는 프로그램을 작성할 수 있지만 대부분의 컴파일러 최적화 형식이 비활성화 된 경우에만 가능합니다. 최적화 컴파일러는 겉보기에 중복되는 많은 코딩 패턴을 "보다 효율적인"패턴으로 대체하도록 설계되었으며 x==42, 컴파일러가 x다른 것을 보유 할 방법 이 없다는 것을 알고있을 때 프로그래머가 테스트하는 이유는 프로그래머가 예방하기를 원하기 때문입니다 특정 x값 을 유지 하면서 특정 코드를 실행하는 경우 (해당 값을 유지할 수있는 유일한 방법 인 경우에도 시스템이 일종의 전기 결함을 수신 한 경우).

변수를 선언하면 volatile도움이 되겠지만 만병 통치약이 아닐 수도 있습니다. 특히, 안전한 코딩을 위해서는 위험한 작업에 여러 단계의 활성화가 필요한 하드웨어 인터록이 있어야하며 패턴을 사용하여 코드를 작성해야합니다.

... code that checks system state
if (system_state_favors_activation)
{
  prepare_for_activation();
  ... code that checks system state again
  if (system_state_is_valid)
  {
    if (system_state_favors_activation)
      trigger_activation();
  }
  else
    perform_safety_shutdown_and_restart();
}
cancel_preparations();

컴파일러가 코드를 상대적으로 문자 그대로 변환하고 시스템 상태에 대한 모든 검사가 이후에 반복되는 prepare_for_activation()경우 시스템 카운터는 프로그램 카운터와 스택을 임의로 손상시킬 수있는 거의 모든 가능한 단일 결함 이벤트에 대해 강력 할 수 있습니다. 에 대한 호출 직후에 글리치가 발생 prepare_for_activation()하면 활성화가 적절했음을 의미합니다 ( prepare_for_activation()글리치 전에 다른 이유 가 호출 되지 않았기 때문에 ). 글리치로 인해 코드가 prepare_for_activation()부적절하게 도달 하지만 후속 글리치 이벤트가 없으면 코드가 이후에 코드에 도달 할 수있는 방법이trigger_activation() 경우 유효성 검사를 통과하거나 cancel_preparations를 먼저 호출하지 않고 직전trigger_activation()호출 한 컨텍스트가 prepare_for_activation()반환 된 후 와 cancel_preparations()호출 사이에 호출이 발생 하여 후자 호출이 무해한 상태가되었습니다.prepare_for_activation()trigger_activation()

이러한 코드는 기존 C에서는 안전하지만 최신 C 컴파일러에서는 안전하지 않습니다. 이러한 컴파일러는 공격적인 경우 잘 정의 된 메커니즘을 통해 발생할 수있는 상황과 관련이 있고 결과가 잘 정의 된 상황에서만 관련이있는 코드 만 포함하려고하기 때문에 이러한 종류의 환경에서 매우 위험 할 수 있습니다. 장애 발생 후 감지하고 정리하는 목적을 가진 코드는 경우에 따라 상황을 악화시킬 수 있습니다. 컴파일러에서 복구 시도가 정의되지 않은 동작을 유발한다고 판단하는 경우, 그러한 경우 이러한 복구가 필요한 조건이 발생하지 않을 수 있음을 유추하여이를 확인한 코드가 제거 될 수 있습니다.

이것은 매우 광범위한 주제입니다. 기본적으로 메모리 손상을 실제로 복구 할 수는 없지만 최소한 즉시 실패를 시도 할 수 있습니다 . 사용할 수있는 몇 가지 기술은 다음과 같습니다.

• 체크섬 상수 데이터 . 오랫동안 일정하게 유지되는 구성 데이터 (구성한 하드웨어 레지스터 포함)가있는 경우 초기화시 체크섬을 계산하고 주기적으로 확인하십시오. 불일치가 표시되면 다시 초기화하거나 재설정해야합니다.

• 중복성을 갖는 변수 저장 . 당신이 중요한 변수가있는 경우 x에 그 값을 쓰기 x1, x2및 x3과 같이 읽을 (x1 == x2) ? x2 : x3.

• 프로그램 흐름 모니터링을 구현 합니다 . 메인 루프에서 호출되는 중요한 기능 / 분기에서 고유 한 값을 가진 글로벌 플래그를 XOR합니다. 거의 100 %의 테스트 범위로 방사선이없는 환경에서 프로그램을 실행하면 사이클이 끝날 때 허용되는 플래그 값 목록이 제공됩니다. 편차가 보이면 재설정하십시오.

• 스택 포인터를 모니터링합니다 . 메인 루프의 시작 부분에서 스택 포인터를 예상 값과 비교하십시오. 편차로 재설정합니다.

워치 독을 도울 수있는 것 입니다. 워치 독은 1980 년대 산업 컴퓨팅에 광범위하게 사용되었습니다. 하드웨어 고장은 그보다 훨씬 흔했습니다. 또 다른 대답은 해당 기간을 나타냅니다.

워치 독은 결합 된 하드웨어 / 소프트웨어 기능입니다. 하드웨어는 숫자 (1023)에서 0까지 카운트 다운되는 간단한 카운터입니다. TTL 또는 다른 논리가 사용될 수 있습니다.

이 소프트웨어는 하나의 루틴이 모든 필수 시스템의 올바른 작동을 모니터링하도록 설계되었습니다. 이 루틴이 올바르게 완료되면 = 컴퓨터가 정상적으로 작동하면 카운터를 1023으로 다시 설정합니다.

전반적인 디자인은 정상적인 상황에서 소프트웨어가 하드웨어 카운터가 0에 도달하지 못하게합니다. 카운터가 0에 도달하면 카운터의 하드웨어는 유일한 작업을 수행하고 전체 시스템을 재설정합니다. 카운터 관점에서, 0은 1024이며 카운터는 다시 카운트 다운을 계속합니다.

이 워치 독은 연결된 컴퓨터가 여러 번 실패 할 경우 다시 시작되도록합니다. 오늘날의 컴퓨터에서 이러한 기능을 수행 할 수있는 하드웨어에 익숙하지 않다는 것을 인정해야합니다. 외부 하드웨어에 대한 인터페이스는 이제 예전보다 훨씬 더 복잡해졌습니다.

워치 독의 본질적인 단점은 워치 독 카운터가 0 + 재부팅 시간에 도달 할 때까지 시스템이 실패한 시점부터 시스템을 사용할 수 없다는 것입니다. 이 시간은 일반적으로 외부 또는 사람의 개입보다 훨씬 짧지 만 지원되는 장비는 해당 기간 동안 컴퓨터 제어없이 진행할 수 있어야합니다.

이 답변은 최소한의 비용 또는 빠른 시스템을 갖춘 시스템이 올바르게 작동하는 데 관심이 있다고 가정합니다. 방사성 물질을 가지고 노는 대부분의 사람들은 속도 / 비용에 대한 정확성 / 안전성을 중요시합니다

여러 사람들이 당신이 할 수있는 하드웨어 변경을 제안했습니다 (좋아요-이미 대답에 좋은 것들이 많이 있으며 반복하지 않을 것입니다). 누구나 이중화가 실제로 어떻게 작동하는지 제안했습니다. 어떻게 페일 오버합니까? 무언가가 잘못되었다는 것을 어떻게 알 수 있습니까? 많은 기술이 모든 것이 작동하는 기초로 작동하므로 실패는 다루기가 까다 롭습니다. 그러나 스케일을 위해 설계된 일부 분산 컴퓨팅 기술은 실패를 예상합니다 (결국 충분한 스케일로 인해 단일 노드에 대한 MTBF를 통해 많은 노드 중 하나의 장애가 불가피 함). 환경에 맞게 활용할 수 있습니다.

몇 가지 아이디어가 있습니다.

• 전체 하드웨어가 복제 n시간 ( n2보다 크거나 바람직하게는 이상) 으로 복제 되고 각 하드웨어 요소가 서로 다른 하드웨어 요소와 통신 할 수 있는지 확인하십시오 . 이더넷은이를위한 확실한 방법 중 하나이지만 더 나은 보호를 제공하는 훨씬 더 간단한 경로가 많이 있습니다 (예 : CAN). 공통 구성 요소 (전원 공급 장치도)를 최소화하십시오. 이것은 예를 들어 여러 곳에서 ADC 입력을 샘플링하는 것을 의미 할 수 있습니다.

• 애플리케이션 상태가 유한 상태 머신과 같은 단일 위치에 있는지 확인하십시오. 안정적인 스토리지를 배제하지는 않지만 RAM 기반 일 수 있습니다. 따라서 여러 곳에 저장됩니다.

• 상태 변경을 위해 쿼럼 프로토콜을 채택하십시오. 예를 들어 RAFT 를 참조하십시오 . C ++로 작업 할 때 잘 알려진 라이브러리가 있습니다. FSM은 대부분의 노드가 동의 한 경우에만 변경됩니다. 프로토콜 스택 및 쿼럼 프로토콜에 대해 알려진 올바른 라이브러리를 사용하십시오. 그렇지 않으면 쿼럼 프로토콜이 중단되면 중복성에 대한 모든 훌륭한 작업이 낭비됩니다.

• FSM을 체크섬 (예 : CRC / SHA)하고 CRC / SHA를 FSM 자체 (메시지 전송 및 메시지 자체 검사)에 저장하십시오. 노드가 이러한 체크섬에 대해 정기적으로 FSM을 확인하고 수신 메시지를 체크섬하며 체크섬이 쿼럼의 체크섬과 일치하는지 확인하십시오.

• 가능한 많은 다른 내부 검사를 시스템에 구축하여 자체 장애 재부트를 감지하는 노드를 만듭니다 (노드가 충분하면 절반의 작업을 수행하는 것보다 낫습니다). 다시 부팅되지 않을 경우 재부팅하는 동안 쿼럼에서 자신을 깨끗하게 제거하도록하십시오. 다시 부팅 할 때 쿼럼에 다시 소개하기 전에 소프트웨어 이미지 (및로드 된 다른 항목)를 체크섬하고 전체 RAM 테스트를 수행하도록합니다.

• 하드웨어를 사용하여 지원하지만 신중하게 수행하십시오. 예를 들어 ECC RAM을 가져와 정기적으로 ECC RAM을 통해 읽고 쓸 수있어 ECC 오류를 수정할 수 있습니다 (오류를 수정할 수없는 경우 패닉). 그러나 (메모리에서) 정적의 RAM은 DRAM은 처음에보다가 있으므로, 이온화 방사선의 훨씬 더 관대 할 수 대신 사용 정적 DRAM에 더 나은. '하지 않을 것'의 첫 번째 요점도 참조하십시오.

하루 동안 특정 노드에서 1 %의 장애가 발생한다고 가정하고 장애를 완전히 독립적으로 만들 수 있다고 가정 해 봅시다. 5 개의 노드를 사용하면 하루 내에 3 개의 장애가 발생하며 이는 .00001 % 확률입니다. 더 잘, 당신은 아이디어를 얻는다.

내가하지 않을 것 :

• 처음부터 문제가없는 것의 가치를 과소 평가하십시오. 무게가 중요하지 않다면, 장치 주변의 큰 금속 블록은 프로그래머 팀이 만들 수있는 것보다 훨씬 저렴하고 안정적인 솔루션이 될 것입니다. EMI 입력의 광학적 광 커플 링은 문제 등입니다. 어쨌든, 전리 방사선에 가장 적합한 등급을 가진 부품을 소싱 할 때 부품을 소싱 할 때 시도하십시오.

• 자신의 알고리즘을 굴 립니다. 사람들은 전에 이런 일을했습니다. 그들의 일을 사용하십시오. 내결함성과 분산 알고리즘은 어렵습니다. 가능한 경우 다른 사람의 작업을 사용하십시오.

• 더 많은 오류를 감지하기를 원하는 복잡한 컴파일러 설정을 사용하십시오. 운이 좋으면 더 많은 실패를 감지 할 수 있습니다. 아마도 테스트가 덜 된 컴파일러 내에서 코드 경로를 사용할 것입니다. 특히 직접 롤링하는 경우 더욱 그렇습니다.

• 환경에서 테스트되지 않은 기술을 사용하십시오. 고 가용성 소프트웨어를 작성하는 대부분의 사람들은 HA가 올바르게 작동하는지 확인하기 위해 실패 모드를 시뮬레이션해야하며 그 결과 많은 실패 모드가 누락됩니다. 귀하는 요청시 빈번한 오류가 발생하는 '운이 좋은'위치에 있습니다. 따라서 각 기술을 테스트하고, 실제로 적용 할 때 MTBF를 도입하는 복잡성을 초과하는 양만큼 애플리케이션이 실제로 MTBF를 향상시키는 지 확인하십시오 (복잡성이 버그가 있음). 특히 내 조언 쿼럼 알고리즘 등에 적용하십시오.

특별히 소프트웨어 솔루션을 요구하고 C ++을 사용하고 있기 때문에 연산자 오버로딩을 사용하여 자신 만의 안전한 데이터 유형을 만드십시오. 예를 들면 다음과 같습니다.

대신에 사용하는 uint32_t(그리고 double, int64_t등)을 (를) 원하는대로 만들어 SAFE_uint32_tuint32_t의 배수 (3 최소)을 포함하는합니다. 수행하려는 모든 작업 (* +-/ << >> = ==! = 등)을 오버로드하고 오버로드 된 작업을 각 내부 값에 대해 독립적으로 수행합니다. 즉, 한 번만 수행하지 말고 결과를 복사하십시오. 전후에 모든 내부 값이 일치하는지 확인하십시오. 값이 일치하지 않으면 가장 일반적인 값으로 잘못된 값을 업데이트 할 수 있습니다. 가장 일반적인 값이 없으면 오류가 있음을 안전하게 알릴 수 있습니다.

이런 방식으로 ALU, 레지스터, RAM 또는 버스에서 손상이 발생하더라도 문제가 여러 번 발생하고 오류가 발생할 가능성이 매우 높습니다. 그러나 이것은 대체 할 수있는 변수에 대해서만 작동하지만 스택 포인터는 여전히 취약합니다.

부수적 인 이야기 : 나는 오래된 ARM 칩에서도 비슷한 문제에 부딪쳤다. 그것은 우리가 사용한 특정 칩과 함께 이전 버전의 GCC를 사용하는 툴체인으로 밝혀졌습니다. 무선 활동을 비난하기 전에 장치에 문제가 없는지 확인하십시오. 그렇습니다. 때로는 컴파일러 버그입니다)

면책 조항 : 저는 방사능 전문가가 아니며 이러한 종류의 응용 프로그램에서 일했습니다. 그러나 중요한 데이터의 장기 보관을 위해 소프트 오류 및 중복성을 작업했습니다.이 데이터는 다소 연결되어 있습니다 (동일한 문제, 다른 목표).

내 생각에 방사능의 주요 문제는 방사능이 비트를 전환 할 수 있으므로 방사능이 모든 디지털 메모리를 변조 할 수 있다는 것 입니다. 이러한 오류를 일반적으로 소프트 오류 , 비트 부패 등 이라고 합니다 .

문제는 메모리가 신뢰할 수 없을 때 안정적으로 계산하는 방법은 무엇입니까?

소프트 오류의 비율을 크게 줄이려면 (대부분 소프트웨어 기반 솔루션이므로 계산 오버 헤드가 발생 함) 다음 중 하나를 수행 할 수 있습니다.

• 오래된 리던던시 구성표 ,보다 효율적인 오류 수정 코드 (동일한 목적이지만보다 효율적인 중복 알고리즘으로 더 많은 비트를 복구 할 수 있도록 보다 효율적인 알고리즘) 에 의존합니다 . 이것은 때때로 (잘못) 체크섬이라고도합니다. 이러한 종류의 솔루션을 사용하면 언제든지 마스터 변수 / 클래스 (또는 구조체?)에 프로그램의 전체 상태를 저장하고 ECC를 계산 한 후 무엇이든하기 전에 ECC가 올바른지 확인해야합니다. 필드를 수리하지 마십시오. 그러나이 솔루션은 소프트웨어가 작동 할 수 있음을 보증하지 않습니다 (간단히 문제가 있는지 ECC가 알려줄 수 있기 때문에 소프트웨어가 작동 할 수 있거나 작동하지 않을 경우 작동이 중지됨). 가짜 결과를 얻지 마십시오).

• 또는 탄력적 인 알고리즘 데이터 구조를 사용할 수 있습니다이는 소프트 오류가있는 경우에도 프로그램이 여전히 올바른 결과를 제공함을 보증합니다. 이러한 알고리즘은 기본적으로 혼합 된 ECC 체계를 사용하는 일반적인 알고리즘 구조의 혼합으로 볼 수 있지만 탄력성 체계가 구조에 밀접하게 바인딩되어 있으므로 추가 절차를 인코딩 할 필요가 없기 때문에 그보다 훨씬 탄력적입니다. ECC를 확인하는 데 일반적으로 훨씬 빠릅니다. 이러한 구조는 프로그램이 이론적 인 범위의 소프트 오류까지 모든 조건에서 프로그램을 작동시킬 수있는 방법을 제공합니다. 또한 이러한 보안 구조를 중복 / ECC 체계와 혼합하여 추가 보안을 강화할 수 있습니다 (또는 가장 중요한 데이터 구조를 탄력성으로, 나머지는 주 데이터 구조에서 재 계산할 수있는 소모성 데이터로 인코딩)

탄력적 인 데이터 구조 (알고리즘 및 중복 공학의 최근이지만 흥미 진진한 새로운 분야)에 관심이있는 경우 다음 문서를 읽는 것이 좋습니다.

• Giuseppe F.Italiano, Universita di Roma "Tor Vergata"의 복원 알고리즘 데이터 구조 소개

• Christiano, P., Demaine, ED, & Kishore, S. (2011). 부가적인 오버 헤드가있는 무손실 내결함성 데이터 구조. 알고리즘 및 데이터 구조 (pp. 243-254). 스프링거 베를린 하이델베르크.

• Ferraro-Petrillo, U., Grandoni, F., & Italiano, GF (2013). 기억 장애에 탄력적 인 데이터 구조 : 사전에 대한 실험적 연구. 실험 알고리즘 (JEA), 18, 1-6.

• GF Italiano (2010). 탄력적 인 알고리즘 및 데이터 구조. 알고리즘과 복잡성 (pp. 13-24). 스프링거 베를린 하이델베르크.

탄력적 인 데이터 구조의 분야에 대해 더 알고 싶다면 Giuseppe F. Italiano 의 작품 (그리고 심판을 통해 당신의 방식으로 작동)과 Faulty-RAM 모델 (Finocchi et al. 2005; Finocchi에서 소개)을 확인하십시오 및 Italiano 2008).

/ 편집 : 주로 RAM 메모리 및 데이터 저장에 대한 소프트 오류 예방 / 복구를 설명했지만 이야기하지 않았습니다. 계산 (CPU) 오류 . 다른 답변은 데이터베이스와 같은 원자 트랜잭션을 사용하는 것을 이미 지적 했으므로 중복 및 과반수 투표라는 또 다른 간단한 체계를 제안 합니다.

아이디어는 필요한 각 계산 에 대해 동일한 계산 을 단순히 x 번 수행하고 결과를 x 개의 다른 변수에 저장한다는 것입니다 (x> = 3 사용). 그런 다음 x 변수 를 비교할 수 있습니다 .

• 모두 동의하면 계산 오류가 전혀 없습니다.
• 동의하지 않으면 다 수표를 사용하여 올바른 값을 얻을 수 있으며 이는 계산이 부분적으로 손상되었음을 의미하므로 시스템 / 프로그램 상태 스캔을 트리거하여 나머지가 정상인지 확인할 수도 있습니다.
• 과반수 투표에서 승자를 결정할 수없는 경우 (모든 x 값이 다름) 비상 안전 절차를 시작 (재부팅, 사용자에게 경고 발생 등)하는 완벽한 신호입니다.

이 중복 체계는 ECC (실제로 O (1))에 비해 매우 빠르며 , 안전 장치 가 필요할 때 명확한 신호를 제공합니다 . 과반수 투표는 또한 손상된 출력을 생성하지 않고 작은 계산 오류 를 복구 하도록 (거의) 보장됩니다. 확률 때문에 그 X 계산주고 같은 출력이 가능한 출력의 거대한 양의가 있기 때문에, 그것은 거의 불가능 (무한소입니다 x> 3) 인 경우 무작위로 동일한 확률로 3 배, 더 적은 확률을 얻습니다.

따라서 과반수 투표로 인해 출력이 손상되지 않고 안전하고 중복 x == 3을 사용하면 1 오류를 복구 할 수 있습니다 (x == 4의 경우 2 오류 복구 가능 등)-정확한 방정식은 nb_error_recoverable == (x-2)x가 숫자입니다. 과반수 표를 사용하여 복구하려면 적어도 2 개의 동의 계산이 필요하기 때문에 계산 반복).

단점은 한 번이 아니라 x 번을 계산해야하므로 추가 계산 비용이 있지만 선형 적으로 복잡하기 때문에 얻는 이점을 많이 잃지 않습니다. 과반수 투표를하는 가장 빠른 방법은 배열에서 모드를 계산하는 것이지만 중앙값 필터를 사용할 수도 있습니다.

또한 계산이 올바르게 수행되는지 확인하려면 자체 하드웨어를 만들 수 있으면 x CPU로 장치를 구성하고 다수의 투표를 통해 x CPU에서 계산이 자동으로 복제되도록 시스템을 연결할 수 있습니다. 기계적으로 (예를 들어 AND / OR 게이트 사용). 이것은 종종 비행기 및 미션 크리티컬 장치에서 구현됩니다 ( 3 중 모듈 리던던시 참조 ). 이 방법으로 계산 오버 헤드가 발생하지 않으며 (추가 계산이 병렬로 수행되므로) 계산 오류 및 과반수 투표는 하드웨어가 직접 관리하므로 소프트웨어는 프로그램이 단순히 메모리에 저장된 비트이기 때문에 더 쉽게 손상 될 수 있습니다 ...).

아무도 언급하지 않은 것 같습니다. GCC에서 개발하고 ARM에 대한 크로스 컴파일을하고 있다고합니다. 사용 가능한 RAM, 정수 크기, 포인터 크기, 특정 작업을 수행하는 데 걸리는 시간, 시스템이 지속적으로 실행되는 시간 또는 이와 유사한 다양한 것들에 대해 가정하는 코드가 없다는 것을 어떻게 알 수 있습니까? 이것은 매우 일반적인 문제입니다.

정답은 일반적으로 자동화 된 단위 테스트입니다. 개발 시스템에서 코드를 실행하는 테스트 하니스를 작성한 후 대상 시스템에서 동일한 테스트 하니스를 실행하십시오. 차이점을 찾으십시오!

임베디드 장치에서 정오표도 확인하십시오. "충돌 할 것이기 때문에이 작업을 수행하지 마십시오. 컴파일러 옵션을 활성화하면 컴파일러가이를 해결할 수 있습니다"라는 내용이있을 수 있습니다.

요컨대, 충돌의 가장 큰 원인은 코드의 버그입니다. 이것이 사실이 아니라는 것을 확신 할 때까지, 난해한 실패 모드에 대해 걱정하지 마십시오.

방사선 환경 외부에 마스터가있는 3 개 이상의 슬레이브 시스템이 필요합니다. 모든 I / O는 투표 및 / 또는 재시도 메커니즘이 포함 된 마스터를 통과합니다. 슬레이브는 각각 하드웨어 워치 독을 가지고 있어야하며 비자발적 충돌의 가능성을 줄이기 위해 충돌을 일으키는 호출은 CRC 등으로 둘러싸여 야합니다. 범프는 마스터에 의해 제어되어야하므로 마스터와의 연결이 끊어지면 몇 초 내에 재부팅됩니다.

이 솔루션의 장점 중 하나는 슬레이브와 동일한 API를 마스터에 사용할 수 있으므로 중복성이 투명한 기능이된다는 것입니다.

편집 : 의견에서 "CRC 아이디어"를 명확히해야한다고 생각합니다. CRC로 범프를 둘러싸거나 마스터에서 임의의 데이터에 대한 다이제스트 검사를 수행하는 경우 자체 감시 장치 인 슬레이브 범프의 가능성은 거의 0에 가깝습니다. 이 임의의 데이터는 감시 대상 슬레이브가 다른 슬레이브와 정렬 된 경우에만 마스터에서 전송됩니다. 랜덤 데이터와 CRC / 다이제스트는 각 범프 후에 즉시 지워집니다. 마스터-슬레이브 범프 주파수는 워치 독 타임 아웃의 두 배 이상이어야 합니다. 마스터에서 전송 된 데이터는 매번 고유하게 생성됩니다.

애플리케이션의 많은 인스턴스를 실행하는 것은 어떻습니까. 임의의 메모리 비트 변경으로 인해 충돌이 발생하는 경우 일부 앱 인스턴스에서 충돌이 발생하여 정확한 결과가 생성 될 수 있습니다. (통계적 배경을 가진 사람에게는) 원하는만큼 작은 전체 오류를 달성하기 위해 비트 플롭 확률을 제공해야하는 인스턴스 수를 계산하는 것이 매우 쉽습니다.

당신이 묻는 것은 매우 복잡한 주제입니다-쉽게 대답 할 수 없습니다. 다른 답변도 괜찮지 만, 당신이해야 할 모든 것의 작은 부분만을 다루었습니다.

의견 에서 볼 수 있듯이 하드웨어 문제를 100 % 해결하는 것은 불가능하지만, 높은 기술 수준에서는 다양한 기술을 사용하여 문제를 줄이거 나 잡을 수 있습니다.

내가 당신이라면, 최고의 안전 무결성 레벨 (SIL-4) 의 소프트웨어를 만들 것 입니다. 원자력 산업을위한 IEC 61513 문서를 입수하여 따르십시오.

누군가가 칩을 쉽게 뒤집는 것을 방지하기 위해 느린 칩을 사용한다고 언급했다. 비슷한 방식으로 실제로 여러 비트를 사용하여 단일 비트를 저장하는 특수한 CPU / RAM을 사용할 수 있습니다. 따라서 모든 비트가 뒤집어 질 가능성이 거의 없기 때문에 하드웨어 내결함성을 제공합니다. 따라서 1 = 1111이지만 실제로 뒤집기 위해서는 4 번의 타격이 필요합니다. (2 비트가 이미 모호한 경우 4는 잘못된 숫자 일 수 있습니다). 따라서 8을 사용하면 램이 8 배 줄어들고 액세스 속도는 느려지지만 훨씬 안정적인 데이터 표현이 가능합니다. 소프트웨어 수준에서 특수 컴파일러 (모든 것에 x 공간을 더 할당) 또는 언어 구현 (이 방법으로 물건을 할당하는 데이터 구조에 대한 래퍼 작성)을 사용하여 소프트웨어 수준 에서이 작업을 수행 할 수 있습니다.

아마도 하드웨어가 "이 환경을 위해 설계되었다"는 것을 의미하는 것이 도움이 될 것입니다. SEU 오류가 있는지 어떻게 수정 및 / 또는 표시합니까?

한 우주 탐사 관련 프로젝트에서 우리는 SEU 오류에 대해 예외 / 인터럽트를 발생시키는 사용자 정의 MCU를 가지고 있었지만 약간의 지연이 있습니다.

데이터 캐시는 특히 취약하므로 처리기는 문제가되는 캐시 라인을 무효화하고 프로그램을 다시 시작합니다. 예외의 부정확 한 특성으로 인해 예외 제기 insn이 이끄는 일련의 함수는 다시 시작할 수 없습니다.

우리는 위험한 (다시 시작할 수없는) 시퀀스 (예 lw $3, 0x0($2): 수정 $2및 데이터 의존성이없는 insn이 뒤 따름 )를 식별하고 $3GCC를 수정 했으므로 이러한 시퀀스가 ​​발생하지 않습니다 (예 : 최후의 수단으로 에 의해 두 개의 여관 nop).

고려해야 할 것 ...

하드웨어에 장애가 발생하면 기계적 저장소를 사용하여 복구 할 수 있습니다. 코드베이스가 작고 물리적 공간이 있으면 기계식 데이터 저장소를 사용할 수 있습니다.

방사선의 영향을받지 않는 재료 표면이있을 것입니다. 여러 기어가 있습니다. 기계식 판독기는 모든 기어에서 작동하며 위아래로 유연하게 움직일 수 있습니다. Down은 0이고 up은 1임을 의미합니다. 0과 1에서 코드베이스를 생성 할 수 있습니다.

주기적 스케줄러를 사용하십시오 . 이를 통해 정기적 인 유지 보수 시간을 추가하여 중요 데이터의 정확성을 확인할 수 있습니다. 가장 자주 발생하는 문제는 스택의 손상입니다. 소프트웨어가주기적인 경우주기간에 스택을 다시 초기화 할 수 있습니다. 인터럽트 호출에 스택을 재사용하지 말고 각각의 중요한 인터럽트 호출에 대해 별도의 스택을 설정하십시오.

워치 독 개념과 유사하게 마감 시간 타이머입니다. 함수를 호출하기 전에 하드웨어 타이머를 시작하십시오. 최종 기한 타이머 인터럽트 전에 함수가 반환되지 않으면 스택을 다시로드하고 다시 시도하십시오. 3/5 시도 후에도 여전히 실패하면 ROM에서 다시로드해야합니다.

별도의 메모리 영역과 실행 시간 (특히 제어 환경)을 사용하도록 소프트웨어를 여러 부분으로 분할하고 이러한 부분을 분리하십시오. 예 : 신호 수집, 데이터 전치, 주요 알고리즘 및 결과 구현 / 전송 즉, 한 부분에서 오류가 발생해도 나머지 프로그램을 통해 오류가 발생하지 않습니다. 따라서 신호 수집을 복구하는 동안 나머지 작업은 오래된 데이터에서 계속됩니다.

모든 것은 CRC가 필요합니다. RAM이 부족하면 .text조차도 CRC가 필요합니다. 주기적 스케줄러를 사용하는 경우 CRC를 정기적으로 점검하십시오. GCC가 아닌 일부 컴파일러는 각 섹션에 대해 CRC를 생성 할 수 있으며 일부 프로세서에는 CRC 계산을 수행하는 전용 하드웨어가 있지만 질문의 범위를 벗어나는 것으로 생각합니다. CRC를 검사하면 메모리의 ECC 컨트롤러가 문제가되기 전에 단일 비트 오류를 ​​복구하라는 메시지를 표시합니다.

먼저, 실패에 대한 응용 프로그램을 설계하십시오 . 정상적인 흐름 작동의 일부로 재설정해야합니다 (응용 프로그램 및 실패 유형에 따라 소프트 또는 하드). 이것은 완벽하게하기가 어렵습니다. 어느 정도의 트랜잭션을 요구하는 중요한 작업은 어셈블리 수준에서 점검하고 조정해야 키 포인트의 중단으로 인해 외부 명령이 일치하지 않을 수 있습니다. 복구 할 수 없는 메모리 손상 또는 제어 흐름 편차가 감지 되는 즉시 빠르게 실패 합니다. 가능하면 로그 실패.

둘째, 가능한 경우 손상을 수정하고 계속하십시오 . 이는 상수 테이블 (및 가능하면 프로그램 코드)을 자주 확인하고 수정하는 것을 의미합니다. 아마도 각 주요 작업 이전 또는 시간 인터럽트에 의해 자동 수정되는 구조에 변수를 저장합니다 (각 주요 op 이전 또는 시간 인터럽트 전에 다시 3에서 과반수의 찬성을 받고 단일 편차 인 경우 수정하십시오). 가능하면 수정 사항을 기록하십시오.

셋째, 테스트 실패 입니다. 메모리의 비트를 무작위로 뒤집는 반복 가능한 테스트 환경을 설정하십시오 . 이를 통해 손상 상황을 복제하고 주변의 응용 프로그램을 설계 할 수 있습니다.

supercat의 의견, 현대 컴파일러의 경향 및 기타 것들을 고려할 때, 나는 고대로 돌아가서 모든 코드를 어셈블리 및 정적 메모리 할당에 모든 곳에서 작성하려고합니다. 이런 종류의 완전한 신뢰성을 위해, 어셈블리는 더 이상 비용의 큰 차이가 발생하지 않는다고 생각합니다.

여기에 많은 답변이 있지만 이것에 대한 아이디어를 요약하려고 노력할 것입니다.

문제가 발생하거나 올바르게 작동하지 않으면 자신의 실수로 인한 것일 수 있습니다. 문제를 찾을 때 쉽게 고쳐야합니다. 그러나 하드웨어 고장의 가능성도 있습니다. 전체적으로 고칠 수는 없지만 어렵습니다.

먼저 로깅 (스택, 레지스터, 함수 호출)을 통해 문제가있는 상황을 파악하는 것이 좋습니다. 파일을 파일 어딘가에 기록하거나 직접 전송합니다 ( "오, 아니오-충돌합니다").

이러한 오류 상황에서 복구는 재부팅 (소프트웨어가 여전히 활성화되어 발차하는 경우)되거나 하드웨어 재설정 (예 : hw 워치 독)입니다. 처음부터 쉽게 시작할 수 있습니다.

문제가 하드웨어와 관련이있는 경우 로깅은 어떤 함수 호출 문제가 발생했는지 식별하고 작동하지 않는 대상과 위치에 대한 내부 지식을 제공합니다.

또한 코드가 비교적 복잡한 경우- "분류하고 정복"하는 것이 합리적입니다. 즉, 문제가 있다고 의심되는 일부 함수 호출을 제거 / 비활성화합니다. 일반적으로 코드의 절반을 비활성화하고 다른 절반을 활성화하면 "작동합니다"/ 코드의 다른 절반에 초점을 맞출 수있는 결정은 "작동하지 않습니다". (문제가있는 곳)

일정 시간이 지난 후 문제가 발생하면 스택 오버플로가 의심 될 수 있습니다. 스택 포인트 레지스터가 지속적으로 커지면 모니터링하는 것이 좋습니다.

그리고 "hello world"종류의 응용 프로그램이 될 때까지 코드를 완전히 최소화 할 수 있고 여전히 무작위로 실패하는 경우 하드웨어 문제가 예상되며 "하드웨어 업그레이드"가 필요합니다. -방사선을 잘 견딜 수있는 하드웨어 조합.

가장 중요한 것은 컴퓨터가 완전히 정지 / 재설정 / 작동하지 않는 경우 로그를 다시 얻는 방법 일 것입니다-아마도 부트 탭이해야 할 일은 문제가있는 상황이 발견되면 집으로 돌아가는 것입니다.

사용자 환경에서 신호를 전송하고 응답을 수신 할 수있는 경우 일종의 온라인 원격 디버깅 환경을 구성하려고 시도 할 수 있지만 최소한 통신 매체가 작동하고 일부 프로세서 / 일부 램이 작동 상태에 있어야합니다. 그리고 원격 디버깅이란 GDB / gdb 스텁 종류의 접근 방식 또는 응용 프로그램에서 다시 가져와야하는 것 (예 : 로그 파일 다운로드, 호출 스택 다운로드, 다운로드 램, 다시 시작)에 대한 자체 구현을 의미합니다.

나는 정말 많은 훌륭한 답변을 읽었습니다!

여기 내 2 센트 : 메모리를 확인하거나 레지스터를 자주 비교하는 소프트웨어를 작성하여 메모리 / 레지스터 이상에 대한 통계 모델을 작성하십시오. 또한 문제를 실험 할 수있는 가상 머신 스타일로 에뮬레이터를 만듭니다. 접합 크기, 클럭 주파수, 공급 업체, 케이싱 등이 달라지면 다른 동작이 관찰됩니다.

데스크탑 PC 메모리조차도 일정 비율의 장애가 발생하지만 일상적인 작업에는 지장이 없습니다.