고방사능 환경에서 사용하기 위한 애플리케이션 컴파일

고방사능 환경에서 사용하기 위한 애플리케이션 컴파일

우리는 이온화 방사선이 쏟아지는 환경에서 차폐 장치에 배치되는 임베디드 C++ 애플리케이션을 컴파일하고 있다.ARM은 GCC와 크로스 컴파일을 사용하고 있습니다.도입 시 어플리케이션이 몇 가지 오데이터를 생성하여 원하는 것보다 더 자주 크래시됩니다.하드웨어는 이 환경에 맞게 설계되었으며, 당사의 애플리케이션은 이 플랫폼에서 수년간 실행되어 왔습니다.

단일 이벤트 업셋으로 인한 소프트웨어 오류 및 메모리 손상을 식별/수정하기 위해 코드를 변경하거나 컴파일 시간을 개선할 수 있습니까?다른 개발자들은 장기간 실행되는 애플리케이션에 대한 소프트 오류의 폐해를 줄이는 데 성공했습니까?

소프트웨어/펌웨어 개발 및 소형화 위성 환경 테스트*에 약 4~5년간 종사한 경험을 공유하고 싶습니다.

* (소형 위성은 전자 컴포넌트의 크기가 비교적 작고 한정되어 있기 때문에 대형 위성에 비해 단일 이벤트 혼란이 발생하기 쉽습니다.)

매우 간결하고 직접적인 요점: 소프트웨어/펌웨어 자체의 검출 가능한 오류 상황으로부터 복구하는 메커니즘은 없습니다.복구 목적으로 소프트웨어/펌웨어의 최소 동작 버전 복사본이 적어도 1개 이상 없고, 복구(기능)를 지원하는 하드웨어가 필요합니다.

이 상황은 보통 하드웨어 레벨과 소프트웨어 레벨 모두에서 처리됩니다.요청하신 대로 소프트웨어 레벨에서 할 수 있는 일을 공유하겠습니다.

1. ...복구 목적...실제 환경에서 소프트웨어/펌웨어 업데이트/재컴파일/재플래시 기능을 제공합니다.이 기능은 이온화가 심한 환경에서 소프트웨어/펌웨어에 거의 필수적인 기능입니다.이 기능이 없으면 다중 소프트웨어/하드웨어를 원하는 만큼 보유할 수 있지만, 어느 시점에서는 모두 사용할 수 없게 됩니다.이 기능을 준비하세요!

2. ...작업 버전 확인...코드에 소프트웨어/펌웨어의 응답성, 여러 복사본, 최소 버전이 있어야 합니다.이것은 Windows 의 세이프 모드와 같습니다.소프트웨어의 완전한 기능을 갖춘 버전을 1개만 보유하는 것이 아니라 소프트웨어/펌웨어 최소 버전의 복사본을 여러 개 보유합니다.보통 최소 복사본은 전체 복사본보다 크기가 훨씬 작으며, 대부분의 경우 다음과 같은 두 세 가지 기능만 있습니다.

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

3. ...복사... 어디선가...용장 소프트웨어/펌웨어가 어딘가에 있습니다.

   1. 용장 하드웨어의 유무에 관계없이, ARM uC에 용장 소프트웨어/펌웨어를 탑재할 수 있습니다.이것은 보통 서로 하트비트를 보내는 다른 주소에 동일한 소프트웨어/펌웨어가 2개 이상 있으면 이루어지지만 동시에 활성화되는 것은 1개뿐입니다.1개 또는 복수의 소프트웨어/펌웨어가 응답하지 않는 것이 판명되면 다른 소프트웨어/펌웨어로 전환합니다.이 접근 방식을 사용하면 오류가 발생한 후 즉시 기능을 교체할 수 있습니다. 오류를 감지하고 수리할 책임이 있는 외부 시스템/당사자와 접촉하지 않아도 됩니다(위성의 경우 일반적으로 미션 컨트롤 센터(MCC)).

      엄밀히 말하면, 용장 하드웨어가 없는 경우, 실제로는 단일 장애점을 모두 제거할 수 없다는 단점이 있습니다.적어도 1개의 단일 장애 지점(스위치 자체(또는 대부분의 경우 코드의 시작)이 존재합니다.단, 고이온화 환경(피코/펨토 위성 등)에서 크기에 따라 제한된 장치의 경우 추가 하드웨어 없이 단일 장애 지점을 1점으로 줄이는 것은 여전히 고려할 가치가 있습니다.Somemore, 전환용 코드 조각은 프로그램 전체의 코드보다 훨씬 작기 때문에 단일 이벤트가 발생할 위험이 크게 줄어듭니다.

   2. 그러나 이 작업을 수행하지 않을 경우 외부 시스템에 장치에 연결하여 소프트웨어/펌웨어를 업데이트할 수 있는 복사본이 하나 이상 있어야 합니다(위성의 경우 다시 미션 컨트롤 센터임).

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

4. ...오류 상황 검출 가능..일반적으로 하드웨어 오류 수정/검출 회로 또는 오류 수정/검출을 위한 작은 코드로 오류를 검출할 수 있어야 합니다.이러한 코드는, 메인 소프트웨어/펌웨어로부터 독립해, 작고 복수의 코드를 넣는 것이 가장 좋습니다.주요 작업은 확인/수정 작업입니다.하드웨어 회로/펌웨어의 신뢰성이 높은 경우(예를 들어 정지대보다 방사 경화도가 높은 경우, 또는 복수의 회로/로직이 있는 경우 등), 에러 수정을 실시하는 것을 검토할 수 있습니다.그러나 그렇지 않으면 오류 검출로 만드는 것이 좋습니다.수정은 외부 시스템/디바이스에 의해 이루어질 수 있습니다.오류 수정에는 Hamming/Golay23과 같은 기본적인 오류 수정 알고리즘을 사용하는 것을 고려할 수 있습니다.이는 회로와 소프트웨어 모두에서 구현이 보다 용이하기 때문입니다.하지만 이는 궁극적으로 팀의 능력에 달려 있습니다.에러 검출에는, 통상은 CRC 가 사용됩니다.

5. 복구를 지원하는 하드웨어는 이 문제에 대해 가장 어려운 측면이 있습니다.궁극적으로 복구를 수행하려면 복구를 담당하는 하드웨어가 최소한 기능해야 합니다.하드웨어가 영속적으로 파손되어 있는 경우(통상은, 총 이온화 선량이 특정 레벨에 도달한 후에 발생합니다), 소프트웨어는 복구에 도움이 되지 않습니다(슬프게도).따라서 하드웨어는 높은 방사선 수준(위성 등)에 피폭된 장치에 대한 가장 중요한 관심사이다.

단일 이벤트 업셋으로 인한 펌웨어 오류 예측에 대한 제안과 더불어 다음 사항을 제안합니다.

1. 서브시스템간 통신 프로토콜에서의 오류 검출 및/또는 오류 정정 알고리즘.이는 다른 시스템으로부터 수신된 불완전한 신호나 잘못된 신호를 피하기 위해 거의 필요한 또 다른 기능입니다.

2. ADC 판독치를 필터링 합니다.ADC 판독값을 직접 사용하지 마십시오.중위수 필터, 평균 필터 또는 다른 필터로 필터링하십시오. 단일 판독 값은 신뢰하지 마십시오.더 많이, 더 적게, 더 많이 - 합리적으로.

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

1. 메모리에 대한 정기적인 오류 모니터링 및 오류 제거
2. 견고한 오류 복구 메커니즘 및
3. 어떤 것이 더 이상 작동하지 않을 경우 재구성할 수 있는 기능

대부분의 ECC 메모리는 멀티비트 에러가 아닌 싱글비트 에러로부터 회복할 수 있기 때문에, 메모리 스캔 레이트는 멀티비트 에러가 거의 발생하지 않는 빈도로 할 필요가 있습니다.

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

데이터 복원을 위한 주요 권장 사항은 중간 데이터를 임시로 처리하여 오류가 발생하기 전에 재시작하면 데이터가 신뢰할 수 있는 상태로 롤백되도록 함으로써 데이터 복원의 필요성을 피하는 것입니다.이는 데이터베이스의 "트랜잭션" 개념과 유사합니다.

이들은 특히 C++와 같은 객체 지향 언어에 적합한 기술에 대해 논의합니다.예를들면

1. 연속 메모리 객체용 소프트웨어 기반 ECC
2. 계약에 의한 프로그래밍: 전제조건과 사후조건을 확인한 후 오브젝트가 아직 유효한 상태인지 확인합니다.

그리고 공교롭게도 NASA는 화성 탐사선과 같은 주요 프로젝트에 C++를 사용했습니다.

C++ 클래스의 추상화와 캡슐화를 통해 여러 프로젝트와 개발자 간에 신속한 개발과 테스트를 수행할 수 있었습니다.

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

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

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

ROM을 좀 더 창의적으로 사용하세요.

ROM에 저장할 수 있는 것은 모두 저장합니다.룩업 테이블을 계산하는 대신 ROM에 저장하십시오(컴파일러가 룩업 테이블을 읽기 전용 섹션으로 출력하는지 확인하십시오.런타임에 메모리 주소를 인쇄하여 확인하세요!)인터럽트 벡터 테이블을 ROM에 저장합니다.물론 몇 가지 테스트를 실행하여 RAM에 비해 ROM의 신뢰성이 어느 정도인지 확인합니다.

스택에는 최적의 RAM을 사용합니다.

스택 내의 SEU는 인덱스 변수, 상태 변수, 리턴 주소 및 다양한 종류의 포인터 등이 일반적으로 존재하기 때문에 크래시의 가장 가능성이 높은 원인일 수 있습니다.

timer-tick 및 watchdog 타이머 루틴을 구현합니다.

타이머 틱마다 "온전성 검사" 루틴을 실행하고 시스템 잠금을 처리하는 감시 루틴을 실행할 수 있습니다.메인 코드에서는 카운터를 정기적으로 증가시켜 진척을 나타낼 수도 있습니다.또, 온전성 체크 루틴을 사용하면, 이것이 발생하고 있는 것을 확인할 수 있습니다.

소프트웨어에 에러 정정 코드를 실장합니다.

데이터에 중복성을 추가하여 오류를 감지하거나 수정할 수 있습니다.이로 인해 프로세서가 더 오랜 시간 동안 방사선에 노출되어 있을 수 있으므로 오류 발생 가능성이 높아지므로 균형을 고려해야 합니다.

캐시를 기억해 주세요.

CPU 캐시 크기를 확인합니다.최근에 액세스하거나 수정한 데이터는 아마도 캐시 내에 있을 것입니다.적어도 일부 캐시는 디세블로 할 수 있다고 생각합니다(대규모의 퍼포먼스 비용으로).캐시가 SEU에 얼마나 영향을 받기 쉬운지를 확인하려면 이 방법을 사용해 보십시오.캐시가 RAM보다 하드한 경우 중요한 데이터를 정기적으로 읽고 다시 쓸 수 있으므로 캐시에 남아 RAM을 다시 정렬할 수 있습니다.

페이지 폴트 핸들러를 교묘하게 사용합니다.

메모리 페이지에 존재하지 않는 마크를 붙이면, 액세스 하려고 하면 CPU가 페이지 장해를 발행합니다.읽기 요청을 처리하기 전에 일부 확인을 수행하는 페이지 장애 핸들러를 만들 수 있습니다(PC 운영 체제는 이를 사용하여 디스크에 스왑된 페이지를 투명하게 로드합니다).

중요한 일(모든 것이 될 수 있음)에는 어셈블리 언어를 사용합니다.

어셈블리 언어를 사용하면 레지스터에 무엇이 있고 RAM에 무엇이 있는지 알 수 있습니다.또한 CPU가 사용하는 특수한 RAM 테이블도 알 수 있으며 위험을 줄이기 위해 우회적으로 설계할 수 있습니다.

사용하다objdump생성된 어셈블리 언어를 살펴보고 각 루틴이 차지하는 코드의 양을 계산합니다.

Linux와 같은 대규모 OS를 사용하는 경우 문제가 발생합니다.복잡함과 문제가 너무 많습니다.

이것은 확률의 게임이라는 것을 기억하라.

댓글에 의하면

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

이는 사실이지만 체크 루틴이 올바르게 기능하기 위해 필요한 코드 및 데이터의 100바이트에 오류가 발생할 가능성은 다른 곳보다 훨씬 낮습니다.ROM 의 신뢰성이 높고, 거의 모든 코드/데이터가 실제로 ROM 에 있는 경우는, 확률이 한층 더 높아집니다.

용장 하드웨어를 사용합니다.

동일한 코드를 가진 2개 이상의 동일한 하드웨어 설정을 사용합니다.결과가 다를 경우 리셋이 트리거되어야 합니다.3대 이상의 디바이스에서는 "투표" 시스템을 사용하여 어떤 디바이스가 손상된지를 식별할 수 있습니다.

알고리즘 내결함성을 주제로 한 풍부한 문헌에도 관심이 있을 수 있습니다.여기에는 이전 과제가 포함됩니다: 일정한 수의 비교가 실패할 때(또는 실패한 비교의 점근적 수가 다음과 같이 확장될 때 약간 더 나쁜 버전) 입력을 올바르게 정렬하는 정렬이 포함됩니다.log(n)위해서n비교).

먼저 Huang과 Abraham의 1984년 논문 "행렬 연산을 위한 알고리즘 기반 Fault Tolerance"를 읽어 보십시오.이들의 아이디어는 동형 암호화 계산과 거의 유사합니다(단, 운영 수준에서 오류 검출/정정을 시도하고 있기 때문에 실제로는 동일하지 않습니다).

Bosilca, Delmas, Dongara 및 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그리고..bss(및 C++ 컨스트럭터를 호출합니다).이것에 의존한 코드를 쓰면 링커 에러가 발생합니다.대부분의 컴파일러는 보통 "최소/고속 시작" 또는 이와 유사한 방법으로 이 옵션을 건너뛸 수 있습니다.

  즉, 외부 라이브러리가 이러한 의존성을 포함하지 않도록 확인해야 합니다.

• 프로그램의 안전 상태를 구현하고 정의합니다.중요한 오류가 발생했을 경우 원래 위치로 돌아갑니다.

• 오류 보고서/오류 로그 시스템을 구현하는 것은 항상 유용합니다.

면책사항:저는 방사능 전문가도 아니고 이런 종류의 응용 프로그램에도 종사하지 않았습니다.그러나 중요한 데이터를 장기간 아카이브하기 위해 소프트 오류와 용장성에 대해 연구했습니다.이것은 어느 정도 관련성이 있습니다(같은 문제, 다른 목표).

내 생각에 방사능의 주요 문제는 방사능이 비트를 바꿀 수 있기 때문에 방사능이 디지털 메모리를 손상시킬 수 있다는 것이다.이러한 에러는, 통상은 소프트 에러, 비트 썩음 등이라고 불립니다.

문제는 메모리가 불안정할 때 어떻게 계산해야 하는가 하는 것입니다.

소프트 에러율을 큰폭으로 삭감하려면(대부분 소프트웨어 베이스의 솔루션이기 때문에 계산상의 오버헤드를 희생한다), 다음의 어느쪽인가를 실행할 수 있습니다.

• 오래된 용장성 방식, 구체적으로는 보다 효율적인 에러 수정 코드(동일한 용도와 용장성을 억제하면서 보다 많은 비트를 회복할 수 있는 보다 현명한 알고리즘)에 의존합니다.이것은 체크섬이라고도 합니다(잘못).이런 종류의 솔루션에서는 프로그램의 전체 상태를 마스터 변수/클래스(또는 구조체?)에 언제든지 저장하고 ECC를 계산하여 ECC가 올바른지 확인하고 그렇지 않은 경우 필드를 복구해야 합니다.그러나 이 솔루션은 소프트웨어가 정상적으로 동작할 수 있음을 보증하는 것은 아닙니다(ECC가 문제가 있는 경우 ECC가 사용자에게 알려줄 수 있기 때문에 정상적으로 동작하지 않거나 그렇지 않은 경우 동작을 정지할 수 있습니다).이 경우 잘못된 결과를 얻지 않도록 소프트웨어를 정지할 수 있습니다.

• 또는 복원력 있는 알고리즘 데이터 구조를 사용하여 소프트 오류가 있더라도 프로그램이 올바른 결과를 제공함을 어느 정도 보장할 수 있습니다.이러한 알고리즘은 일반적인 알고리즘 구조와 ECC 스킴이 기본적으로 혼합되어 있는 것으로 볼 수 있지만 복원 스킴이 구조물에 밀접하게 한정되어 있기 때문에 ECC를 체크하기 위해 추가 절차를 인코딩할 필요가 없고 일반적으로 훨씬 더 빠릅니다.이러한 구조는 소프트 에러의 이론적인 한계까지 어떠한 조건에서도 프로그램이 동작할 수 있도록 하는 방법을 제공합니다.또한 이러한 복원력 구조를 용장성/ECC 체계와 혼합하여 보안을 강화할 수도 있습니다(또는 가장 중요한 데이터 구조를 복원력으로 인코딩하고 나머지 데이터는 ECC 또는 매우 빠른 패리티 검사를 통해 일반 데이터 구조로 재계산할 수 있습니다).

내장해성 데이터 구조(알고리즘과 용장성 엔지니어링의 최근 새로운 분야)에 관심이 있는 경우 다음 문서를 읽는 것이 좋습니다.

• Giuseppe F가 소개한 복원 알고리즘 데이터 구조.이탈리아노, 로마 유니버시타 디 로마 "Tor Vergata"

• 크리스티아노, P., 데메인, E.D. 및 키쇼어, S. (2011)추가 오버헤드를 수반하는 무손실 폴트 톨러런스 데이터 구조.알고리즘 및 데이터 구조(페이지 243-254).스프링거 베를린 하이델베르크입니다

• Feraro-Petrillo, U.S., Grandoni, F. 및 Italiano, G. F. (2013).메모리 장애에 대한 복원력 있는 데이터 구조: 사전의 실험적 연구.JEA(Journal of Experimental Algorithmics), 18, 1-6.

• 이탈리아어, G.F. (2010년)내장해성 알고리즘 및 데이터 구조알고리즘과 복잡성 (13-24페이지)스프링거 베를린 하이델베르크입니다

복원력 있는 데이터 구조 분야에 대해 자세히 알고 싶다면 Giuseppe F의 작업을 확인할 수 있습니다. 이탈리아어(및 참조 참조)와 결함 RAM 모델(Finocchi 등 2005년, Finocchi 및 Italiano 2008에 소개됨)

/EDIT: 주로 RAM 메모리와 데이터 스토리지용 소프트 에러로부터의 방지/복구 방법을 설명했지만, 계산(CPU) 오류에 대해서는 언급하지 않았습니다.다른 답변은 이미 데이터베이스와 같이 원자거래를 이용하는 것을 지적하고 있기 때문에, 저는 용장성과 다수결이라는 또 다른 간단한 방법을 제안합니다.

즉, 필요한 각 계산에 대해 동일한 계산을 x배하고 결과를 x개의 다른 변수(x > = 3)에 저장하는 것입니다.그런 다음 x 변수를 비교할 수 있습니다.

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

이 용장성 스킴은 ECC(실제로는 O(1))에 비해 매우 고속으로 페일 세이프가 필요한 경우 클리어 신호를 제공합니다.때문에 확률은)계산이 동일한 출력을 아주 적다 대다수 투표 또한 사소한 계산 오류에서 회복하기 위해 손상된 출력을 충당하는 것이 보장되었기 때문에 가능한 산출물 엄청난 양은 심지어 기회가 많지 않다면 x>(, 그것은 거의 무작위로 3번 갈 수 있습니다;불가능해요(거의) 있다.3).

따라서 다수결의 경우 손상된 출력으로부터 안전하며 이중화 x == 3의 경우 오류 1개를 복구할 수 있습니다(x == 4의 경우 오류 2개를 복구할 수 있는 등). 정확한 방정식은 다음과 같습니다.nb_error_recoverable == (x-2)여기서 x는 계산 반복 횟수입니다.다수표를 사용하여 회복하려면 적어도2개의 동의 계산이 필요하기 때문입니다).

단점은 한 번이 아니라 x번 계산해야 하므로 추가 계산 비용이 발생하지만 선형 복잡성이 너무 높아 이점을 얻을 때 큰 손실을 입지 않는다는 것입니다.다수결의 빠른 방법은 배열의 모드를 계산하는 것이지만 중위수 필터를 사용할 수도 있습니다.

또, 계산이 올바르게 행해지고 있는 것을 확실히 하고 싶은 경우는, 독자적인 하드웨어를 작성할 수 있는 경우는, x개의 CPU로 디바이스를 구성하고, 최종적으로는 (AND/OR 게이트를 사용하는 등) 과반의 투표로 x개의 CPU간에 자동적으로 계산이 복제되도록 시스템을 배선할 수 있습니다.이는 종종 비행기와 미션 크리티컬 장치에 구현됩니다 (3중 모듈식 용장성 참조).이렇게 하면 (추가 계산이 병행되기 때문에) 계산 오버헤드가 발생하지 않고 (계산 복제와 다수결은 소프트웨어가 아닌 하드웨어에 의해 직접 관리되기 때문에) 소프트 에러로부터 다른 층을 보호할 수 있습니다.이것은 프로그램이 s이기 때문에 더 쉽게 파손될 수 있습니다.메모리에 저장된 비트를 암시합니다...).

이것은 매우 광범위한 주제이다.기본적으로 메모리 손상은 회복할 수 없지만 적어도 즉시 장애는 시도할 수 있습니다.사용할 수 있는 기술은 다음과 같습니다.

• 체크섬 상수 데이터장기간 일정하게 유지되는 설정 데이터(설정된 하드웨어 레지스터 포함)가 있는 경우 초기화 시 체크섬을 계산하고 정기적으로 확인합니다.일치하지 않는 경우는, 재초기화 또는 리셋을 실시할 때입니다.

• 용장성이 있는 변수를 저장합니다.중요한 변수가 있는 경우x, 그 값을 에 기입합니다.x1,x2그리고.x3라고 읽는다.(x1 == x2) ? x2 : x3.

• 프로그램 흐름 모니터링을 구현합니다. XOR은 메인 루프에서 호출되는 중요한 함수/브런치에 고유한 값을 가진 글로벌 플래그입니다.100%에 가까운 테스트 적용 범위로 방사선 없는 환경에서 프로그램을 실행하면 사이클 종료 시 허용되는 플래그 값 목록이 나타납니다.편차가 보이면 재설정합니다.

• 스택 포인터를 감시합니다.메인 루프의 선두에서 스택포인터를 예상되는 값과 비교합니다.편차에 따라 재설정합니다.

대부분의 컴파일러 최적화가 비활성화되어 있는 경우에만 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_incriptions를 호출하지 않은 경우(스택에 장애가 발생하면 실행이 직전 스폿으로 진행될 수 있음)trigger_activation()호출한 컨텍스트 뒤에prepare_for_activation()에 대한 콜이 반환됩니다.cancel_preparations()에의 콜 사이에 일어났을 것이다.prepare_for_activation()그리고.trigger_activation()이것에 의해, 후자의 콜은 무해하게 됩니다.

이러한 코드는 기존 C에서는 안전하지만 최신 C 컴파일러에서는 안전하지 않습니다.이러한 컴파일러는 그러한 환경에서 매우 위험할 수 있습니다.왜냐하면 이러한 컴파일러는 공격적으로 코드만 포함하려고 하기 때문입니다.코드는 명확하게 정의된 메커니즘을 통해 발생할 수 있고 그 결과도 명확하게 정의될 수 있습니다.장애 발생 후 검출 및 정리가 목적인 코드는 상황을 악화시킬 수 있습니다.만약 컴파일러가 어떤 경우에 복구 시도가 정의되지 않은 동작을 호출한다고 판단한다면, 그러한 경우에 복구가 필요한 조건은 일어날 수 없다고 추론할 수 있으며, 따라서 그들을 체크했을 코드를 제거할 수 있다.

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

하드웨어 변경을 제안하고 있는 사람도 있고(이미 답변에 좋은 내용이 많이 있어 모두 반복할 생각은 없습니다), 용장성을 제안하고 있는 사람도 있습니다만(원칙적으로 매우 높음) 그 용장성이 실제로 어떻게 기능하는지는 아무도 제안하지 않은 것 같습니다.어떻게 페일오버를 합니까?언제 '잘못된'지 어떻게 알아?많은 테크놀로지가 모든 것을 기반으로 작동하기 때문에 실패는 다루기 어려운 것입니다.그러나 확장용으로 설계된 일부 분산 컴퓨팅 테크놀로지에서는 장애가 발생할 수 있습니다(확장성이 충분할 경우 단일 노드의 MTBF에서는 많은 노드 중 하나의 장애가 불가피합니다). 이를 환경에 맞게 활용할 수 있습니다.

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

• 전체 하드웨어가 복제되었는지 확인n횟수(여기서)n는 2보다 크고 가능하면 홀수)이며 각 하드웨어 요소가 서로 통신할 수 있습니다.이더넷은 이를 위한 명백한 방법 중 하나이지만, 더 나은 보호를 제공하는 훨씬 더 단순한 루트(예를 들어 CAN)가 많이 있습니다.공통 컴포넌트(전원장치까지)를 최소화합니다.이것은, 예를 들면, 복수의 장소에서 ADC 입력을 샘플링 하는 것을 의미할 가능성이 있습니다.

• 응용 프로그램 상태가 유한 상태 기계 등 단일 위치에 있는지 확인합니다.이는 완전히 RAM 기반일 수 있지만, 안정적인 스토리지를 방해하지는 않습니다.따라서 여러 곳에 저장됩니다.

• 상태 변경에 대한 쿼럼 프로토콜을 채택합니다.예를 들어 RAFT를 참조하십시오.C++에서 작업하고 있기 때문에 이를 위한 잘 알려진 라이브러리가 있습니다.FSM에 대한 변경은 노드의 과반수가 동의했을 경우에만 이루어집니다.프로토콜 스택 및 쿼럼 프로토콜에 대해 알려진 양호한 라이브러리를 직접 롤링하지 않고 사용하십시오. 그렇지 않으면 쿼럼 프로토콜이 중단되면 중복성에 대한 모든 작업이 낭비됩니다.

• FSM 체크섬(예를 들어 CRC/SHA)을 실행하고 CRC/SHA를 FSM 자체에 저장합니다(메시지 전송 및 메시지 자체의 체크섬).노드가 이러한 체크섬, 체크섬 착신 메시지에 대해 정기적으로 FSM을 체크하도록 하고 체크섬이 쿼럼의 체크섬과 일치하는지 확인합니다.

• 시스템에 가능한 한 많은 내부 체크를 내장하여 자신의 장애를 검출한 노드를 reboot합니다(노드가 충분한 경우 반쯤 작업하는 것보다 이 방법이 더 좋습니다).재기동시에 쿼럼에서 완전히 삭제되도록 합니다.다시는 표시되지 않게 됩니다.reboot 시 소프트웨어 이미지(및 로드하는 다른 모든 것)에 체크섬을 표시하고 풀 RAM 테스트를 실행한 후 쿼럼에 다시 추가합니다.

• 하드웨어를 사용하여 사용자를 지원하되 신중하게 지원하십시오.예를 들어, ECC RAM을 입수해, ECC 에러를 정기적으로 읽고 쓸 수 있습니다(에러를 수정할 수 없는 경우는 패닉 상태가 됩니다).단, (메모리로부터의) 스태틱램은 처음부터 DRAM보다 이온화 방사선에 대한 내구성이 훨씬 높기 때문에 스태틱D램을 사용하는 것이 좋을 수 있습니다.'내가 하지 않을 일'의 첫 번째 포인트도 참조하십시오.

예를 들어, 하루에 특정 노드에서 장애가 발생할 확률이 1%라고 가정하고 장애를 완전히 독립적으로 만들 수 있다고 가정해 보겠습니다.노드가 5개일 경우 하루에 3개가 고장나야 합니다.그 확률은 .00001%입니다.더 많은 걸 보면 알 수 있을 거야

내가 하지 않을 일:

• 처음부터 문제가 없다는 것의 가치를 과소평가하세요.무게가 문제가 되지 않는 한, 장치 주변에 있는 큰 금속 블록이 프로그래머 팀이 고안할 수 있는 것보다 훨씬 저렴하고 신뢰할 수 있는 솔루션이 될 것입니다.EMI 입력의 광커플링 등이 문제다.어쨌든, 이온화 방사선에 대해 가장 적합한 것으로 평가된 부품을 조달할 때 시도해 보십시오.

• 독자적인 알고리즘을 조작해 주세요.사람들은 전에 이런 일을 해 본 적이 있다구요.그들의 일을 이용하라.폴트 톨러런스 및 분산 알고리즘은 어렵습니다.가능한 한 다른 사람의 일을 이용하세요.

• 복잡한 컴파일러 설정을 사용하여 더 많은 장애를 검출할 수 있기를 바랍니다.운이 좋으면 더 많은 고장을 탐지할 수 있습니다.컴파일러 내에서 코드 패스를 사용하는 경우가 많습니다.특히 직접 롤링을 했을 경우 테스트 대상이 되지 않습니다.

• 사용자 환경에서 테스트되지 않은 기술을 사용합니다.고가용성 소프트웨어를 작성하는 대부분의 사용자는 HA가 올바르게 동작하고 있는지 확인하기 위해 장애 모드를 시뮬레이션해야 하며 그 결과 많은 장애 모드를 놓치게 됩니다.요청 시 고장이 자주 발생하는 '운' 위치에 있습니다.따라서 각 기술을 테스트하고 해당 애플리케이션의 MTBF가 복잡함을 초과하는 수준으로 향상되는지 확인합니다(복잡한 경우에는 버그가 발생합니다).특히 이것을 제 조언의 쿼럼 알고리즘 등에 적용하세요.

소프트웨어 솔루션을 요구하고 C++를 사용하고 있으므로 연산자 오버로드를 사용하여 안전한 데이터 유형을 만드는 것은 어떻습니까?예를 들어 다음과 같습니다.

사용하는 대신uint32_t(그리고double,int64_t기타) 자체 제작SAFE_uint32_t여기에는 uint32_t의 배수(3의 배수)가 포함되어 있습니다.실행할 모든 작업(* + - / < > === 등)을 오버로드하고 오버로드된 작업을 각 내부 값에 대해 독립적으로 수행하도록 합니다. 즉, 한 번 수행하지 않고 결과를 복사합니다.전후 모두 내부 값이 모두 일치하는지 확인합니다.값이 일치하지 않으면 잘못된 값을 가장 일반적인 값으로 업데이트할 수 있습니다.가장 일반적인 값이 없는 경우 오류가 있음을 안전하게 알릴 수 있습니다.

이렇게 하면 ALU, 레지스터, RAM 또는 버스에 손상이 발생하더라도 여러 번 시도하여 오류를 탐지할 수 있습니다.단, 이것은 치환 가능한 변수에 대해서만 기능하지만 스택포인터는 영향을 받기 쉽습니다.

한편, 오래된 ARM 칩에서도 비슷한 문제가 발생했습니다.이전 버전의 GCC를 사용한 툴체인으로 특정 칩과 함께 특정 엣지 케이스에서 손상된 값이 함수로 전달되는 버그가 트리거되었습니다.방사능 탓으로 돌리기 전에 장치에 문제가 없는지 확인하십시오. 때로는 컴파일러 버그 =)

첫째, 장애를 고려하여 애플리케이션을 설계합니다.통상의 플로우 동작의 일부로서 리셋이 예상되는 것을 확인해 주세요(어플리케이션과 소프트 또는 하드의 장애 타입에 따라 다릅니다).이는 완벽하기 어렵습니다.어느 정도의 트랜잭션성을 필요로 하는 중요한 조작을 어셈블리레벨로 체크 및 조정하여 키포인트에서의 중단으로 인해 외부 명령어가 일관되지 않도록 해야 합니다.회복 불가능한 메모리 파손 또는 제어 흐름 편차가 검출되면 즉시 장애 발생.가능한 경우 로그 실패.

둘째, 가능하면 부패를 바로잡고 계속하세요.즉, 각 메이저 조작 전 또는 타임 인터럽트에 대해 체크섬을 작성하고 가능하면 프로그램 코드를 수정하며 변수를 자동 수정하는 구조에 저장합니다(각 메이저 조작 전 또는 타임 인터럽트에 대해서도 3에서 다수결로 하고 단일 편차일 경우 수정).가능한 경우 수정 내용을 기록합니다.

셋째, 시험 불합격입니다.메모리 psuedo의 비트를 랜덤으로 플립하는 반복 가능한 테스트 환경을 설정합니다.이를 통해 손상 상황을 복제하고 해당 상황을 기준으로 애플리케이션을 설계할 수 있습니다.

나 정말 좋은 답 많이 읽었어!

여기 제 2센트가 있습니다.메모리/레지스터의 이상 통계 모델을 작성합니다.메모리를 체크하는 소프트웨어를 작성하거나 레지스터를 자주 비교합니다.또한 문제를 실험할 수 있는 가상 시스템 스타일로 에뮬레이터를 생성합니다.접점 크기, 클럭 주파수, 벤더, 케이스 등이 다르면 다른 동작을 볼 수 있을 것입니다.

델의 데스크탑 PC 메모리에도 일정한 장해가 발생하고 있습니다만, 일상 업무에 지장은 없습니다.

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

정답은 보통 자동 장치 테스트입니다.개발 시스템에 코드를 적용하는 테스트 하니스를 작성한 다음 대상 시스템에서 동일한 테스트 하니스를 실행합니다.차이점을 찾아보세요!

또, 임베디드 디바이스의 에러타도 확인합니다."크래쉬가 발생하기 때문에 이 작업을 수행하지 마십시오.그러면 컴파일러 옵션과 컴파일러가 이 작업을 회피할 수 있습니다."라고 생각할 수 있습니다.

즉, 가장 가능성이 높은 크래시의 원인은 코드의 버그입니다.이것이 사실이 아님을 확실히 확인할 때까지 더 난해한 장애 모드에 대해 걱정하지 마십시오.

당신에게 도움이 될 수 있는 것은 감시자입니다.워치독은 1980년대 산업용 컴퓨팅에서 광범위하게 사용되었습니다.하드웨어 장애는 그 보다 훨씬 더 흔했습니다.또 다른 답변도 그 시기를 언급하고 있습니다.

워치독은 하드웨어/소프트웨어의 조합 기능입니다.하드웨어는 숫자(1023 등)에서0까지 카운트다운하는 단순한 카운터입니다.TTL 또는 기타 로직을 사용할 수 있습니다.

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

일반적인 상황에서는 하드웨어 카운터가 제로에 도달하지 않도록 설계되어 있습니다.카운터가 0에 도달하면 카운터의 하드웨어는 단독 태스크를 실행하여 시스템 전체를 리셋합니다.카운터 관점에서 0은 1024에 해당하며 카운터는 다시 카운트다운을 계속합니다.

이 워치독에 의해, 접속되어 있는 컴퓨터가, 많은 장해가 발생했을 경우에 재기동합니다.오늘날의 컴퓨터에서 이러한 기능을 수행할 수 있는 하드웨어에 익숙하지 않다는 것을 인정해야 합니다.외부 하드웨어에 대한 인터페이스가 이전보다 훨씬 복잡해졌습니다.

워치독의 본질적인 단점은 장애가 발생한 시점부터 워치독카운터가 제로 + reboot 시간이 될 때까지 시스템을 사용할 수 없다는 것입니다.일반적으로 이 시간은 외부 또는 사람의 개입보다 훨씬 짧지만 지원되는 기기는 그 시간 동안 컴퓨터 제어 없이 작업을 진행할 수 있어야 합니다.

주기 스케줄러를 사용합니다.이를 통해 정기적인 유지 관리 시간을 추가하여 중요한 데이터의 정확성을 확인할 수 있습니다.가장 자주 발생하는 문제는 스택의 파손입니다.소프트웨어가 주기적인 경우 주기 간에 스택을 다시 초기화할 수 있습니다.인터럽트 콜에 스택을 재사용하지 말고 중요한 인터럽트 콜마다 다른 스택을 설정합니다.

Watchdog의 개념과 유사한 것은 마감 타이머입니다.함수를 호출하기 전에 하드웨어 타이머를 시작합니다.마감 타이머가 중단되기 전에 함수가 돌아오지 않으면 스택을 새로고침하고 다시 시도하십시오.3/5 시도 후에도 실패하면 ROM에서 새로고침해야 합니다.

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

모든 일에는 CRC가 필요합니다.RAM에서 실행할 경우 .text에도 CRC가 필요합니다.순환 스케줄러를 사용하는 경우는, CRC 를 정기적으로 체크해 주세요.일부 컴파일러(GCC가 아닌)는 각 섹션의 CRC를 생성할 수 있으며 일부 프로세서는 CRC 계산을 위한 전용 하드웨어를 갖추고 있지만, 이는 질문의 범위 밖일 수 있습니다.또한 CRC를 체크하면 메모리 상의 ECC 컨트롤러가 문제가 되기 전에 싱글비트 오류를 복구하도록 요구됩니다.

기동시에는 워치독을 1회만 사용해 주세요.부팅에 문제가 발생한 경우 하드웨어 지원이 필요합니다.

방사선 환경 외부에 마스터가 있는 3대 이상의 슬레이브 기계를 원합니다.모든 I/O는 투표 및/또는 재시도 메커니즘을 포함하는 마스터를 통과합니다.슬레이브에는 각각 하드웨어 워치독이 필요합니다.또한 슬레이브를 범핑하는 콜을 CRC 등으로 둘러싸서 의도하지 않은 범핑의 가능성을 낮출 필요가 있습니다.범핑은 마스터에 의해 제어되어야 합니다.따라서 마스터와의 연결이 끊기면 몇 초 안에 재부팅됩니다.

이 솔루션의 장점 중 하나는 슬레이브와 같은 API를 마스터에 사용할 수 있기 때문에 용장성이 투과적인 기능이 된다는 것입니다.

편집: 코멘트로부터, 「CRC 아이디어」를 명확하게 할 필요가 있다고 느끼고 있습니다.마스터로부터의 랜덤 데이터에 대한 CRC 또는 다이제스트 체크로 범프를 둘러싸면 슬레이브 자체 워치독의 범핑 가능성은 제로에 가깝습니다.이 랜덤 데이터는 조사 대상 슬레이브가 다른 슬레이브와 정렬되어 있을 때만 마스터에서 전송됩니다.랜덤 데이터와 CRC/다이제스트는 각 범프 후 즉시 지워집니다.마스터 슬레이브 범프 빈도는 워치독타임아웃의 2배를 넘어야 합니다.마스터에서 전송된 데이터는 매번 고유하게 생성됩니다.

하드웨어가 '이 환경용으로 설계되어 있다'는 것을 의미하는지 알아두는 것이 도움이 될 수 있습니다.SEU 오류의 수정 방법 및/또는 존재 여부를 나타내는 방법

한 우주 탐사 관련 프로젝트에서는 SEU 오류에 대한 예외/중단을 발생시키는 커스텀 MCU가 있었지만, 일부 사이클은 SEU 예외를 발생시킨 insn 이후에 통과/지시가 실행될 수 있습니다.

특히 데이터 캐시가 취약했기 때문에 핸들러는 문제의 캐시 행을 무효화하고 프로그램을 재시작합니다.단, 예외 발생 insn을 선두로 하는 insn 시퀀스는 예외 발생 insn의 특성이 부정확하기 때문에 재시작할 수 없습니다.

위험(재시작 불가) 시퀀스를 식별했습니다(예:lw $3, 0x0($2), 뒤에 insn이 붙습니다.이것에 의해서,$2데이터에 의존하지 않습니다.$3GCC에 변경을 가하여 이러한 시퀀스가 발생하지 않도록 했습니다(마지막 수단으로 2개의 인스톨을 1개의 인스톨로 구분하는 등).nop).

생각해 볼 게 하나 있는데...

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

방사선의 영향을 받지 않는 물질의 표면이 있을 것이다.기어가 여러 개 있을 거예요.기계식 판독기는 모든 기어에서 작동하며 상하로 유연하게 움직일 수 있습니다.Down은 0, up은 1을 의미합니다.0과 1에서 코드 베이스를 생성할 수 있습니다.

당신이 묻는 것은 매우 복잡한 주제입니다. 쉽게 대답할 수 없습니다.다른 답변도 괜찮지만, 해야 할 일 중 극히 일부에 불과합니다.

코멘트에서 보듯이 하드웨어 문제를 100% 해결할 수는 없지만 다양한 기술을 사용하여 하드웨어 문제를 줄이거나 포착할 가능성이 높다.

내가 당신이라면 안전 무결성 수준이 가장 높은 소프트웨어(SIL-4)를 만들 것이다.(원자력 산업용) IEC 61513 문서를 입수하여 준수한다.

응용 프로그램의 여러 인스턴스를 실행하는 것은 어떨까요?랜덤 메모리 비트 변경으로 인해 크래시가 발생하는 경우, 일부 앱 인스턴스가 성공하여 정확한 결과를 얻을 수 있습니다.(통계적 배경을 가진 사람의 경우) 원하는 만큼 작은 전체 오류를 달성하기 위해 몇 개의 인스턴스가 필요한지를 계산하는 것은 매우 쉽습니다.

이온이 쉽게 튀는 것을 방지하기 위해 느린 칩을 사용하는 것을 언급했습니다.같은 방법으로, 1비트를 저장하기 위해 여러 비트를 실제로 사용하는 특수한 cpu/ram따라서 모든 비트가 뒤집힐 가능성은 매우 낮기 때문에 하드웨어 폴트 톨러런스가 제공됩니다.따라서 1 = 1111이지만 실제로 플립하려면 4번 눌러야 합니다. (2비트가 플립되면 이미 애매한 숫자이므로 4는 잘못된 숫자일 수 있습니다.)따라서 8을 선택하면 RAM은 8배 줄어들고 액세스 시간은 다소 느려지지만 데이터 표현은 훨씬 더 안정적입니다.소프트웨어 레벨에서는 전용 컴파일러(모든 것에 대해 x개의 공간을 더 할당) 또는 언어 구현(이렇게 할당하는 데이터 구조용 쓰기 래퍼)을 모두 사용할 수 있습니다.또는 논리 구조는 동일하지만 펌웨어에서 이 기능을 수행하는 전용 하드웨어입니다.

Given supercat's comments, the tendencies of modern compilers, and other things, I'd be tempted to go back to the ancient days and write the whole code in assembly and static memory allocations everywhere. For this kind of utter reliability I think assembly no longer incurs a large percentage difference of the cost.

Here are huge amount of replies, but I'll try to sum up my ideas about this.

Something crashes or does not work correctly could be result of your own mistakes - then it should be easily to fix when you locate the problem. But there is also possibility of hardware failures - and that's difficult if not impossible to fix in overall.

I would recommend first to try to catch the problematic situation by logging (stack, registers, function calls) - either by logging them somewhere into file, or transmitting them somehow directly ("oh no - I'm crashing").

Recovery from such error situation is either reboot (if software is still alive and kicking) or hardware reset (e.g. hw watchdogs). Easier to start from first one.

If problem is hardware related - then logging should help you to identify in which function call problem occurs and that can give you inside knowledge of what is not working and where.

Also if code is relatively complex - it makes sense to "divide and conquer" it - meaning you remove / disable some function calls where you suspect problem is - typically disabling half of code and enabling another half - you can get "does work" / "does not work" kind of decision after which you can focus into another half of code. (Where problem is)

If problem occurs after some time - then stack overflow can be suspected - then it's better to monitor stack point registers - if they constantly grows.

And if you manage to fully minimize your code until "hello world" kind of application - and it's still failing randomly - then hardware problems are expected - and there needs to be "hardware upgrade" - meaning invent such cpu / ram / ... -hardware combination which would tolerate radiation better.

Most important thing is probably how you get your logs back if machine fully stopped / resetted / does not work - probably first thing bootstap should do - is a head back home if problematic situation is entcovered.

If it's possible in your environment also to transmit a signal and receive response - you could try out to construct some sort of online remote debugging environment, but then you must have at least of communication media working and some processor/ some ram in working state. And by remote debugging I mean either GDB / gdb stub kind of approach or your own implementation of what you need to get back from your application (e.g. download log files, download call stack, download ram, restart)

ReferenceURL : https://stackoverflow.com/questions/36827659/compiling-an-application-for-use-in-highly-radioactive-environments