공간 강화를 다루었습니까?

공간 강화와 관련하여 모범 사례를 연구하고 싶어합니다. 예를 들어, 화성 탐사선의 일부 핵심 부분이 동적 메모리 할당을 사용하지 않았다는 사실을 읽었습니다 (사실 더 이상 기사를 찾을 수는 없지만). 실제로 금지되어 있습니다. 또한 구식 코어 메모리가 공간에서 바람직 할 수 있다고 읽었습니다.

Google Lunar Challenge와 관련된 일부 프로젝트를보고 달이나 심지어 우주로 코드를 가져 오는 느낌이 어떤지 궁금했습니다. 공간이 강화 된 보드는 열악한 환경에서 어느 정도의 위생을 제공한다는 것을 알고 있지만 (C 프로그래머로서) 우주에서 실행되는 무언가를 작성하는 경우 사고와 코드를 어떻게 조정해야하는지 궁금합니다.

향후 몇 년간 개인 우주 회사에서 더 많은 성장을 보일 것으로 생각합니다. 적어도 모범 사례에 대해 어느 정도 지식이 필요합니다.

방사선, 냉기 또는 열이 절연에 손상을 입힌 보드에 충격을 가하면 프로그램은 어떻게됩니까? 목표는 우주선을 우주선 안에 넣는 것 (물건을 고치거나 바꾸는 한)을 고치는 임무를 피하는 것입니다.

또한 이사회가 중요한 시스템을 유지 관리하는 경우 조기 경보가 가장 중요합니다.

테스트와 시행 착오 (개인 위성 발사 금지)를 통해 어떻게이 경험을 얻습니까?

우주 소프트웨어는 신비한 마법이 아닙니다. 여전히 1과 3이 아닌 0과 1을 사용하고 있습니다. 따라서 소프트웨어 개발에 사용되는 내용을 설명하는 데에는 아무런 문제가 없을 것입니다.

현재 떠오르는 약간의 차이점은 다음과 같습니다.

• 매우 프로세스 지향적입니다.
• 우주 소프트웨어에는 항상 소프트웨어 및 하드웨어 감시 타이머가 있습니다.
• 내가 작업 한 모든 우주 시스템은 어려운 실시간 시스템이었습니다.
• 모든 외부 행위자를 시스템에 시뮬레이션 (정확하게)합니다. 여기에는 일반적으로 테스트 용도로만 사용되는 맞춤형 하드웨어를 구축하는 것이 포함됩니다.
• 공식적인 테스트를 수행하기 위해 엄청난 노력과 비용을 소비합니다.
• 고객 (보통 JPL)은 테스트 프로세스에 극도로 관여합니다.
• 일반적으로 새로운 컴파일러 대신 기존의 알려진 컴파일러와 개발 환경을 사용하고 있습니다.
• 코드 검토, 코드 검토 및 코드 검토
• 하드웨어와 소프트웨어 환경 사이에서 매우 편안하게 전환 할 수 있습니다. 하드웨어를 디자인하는 방법을 알 필요는 없지만 작동 방식을 알아야합니다.
• 오실로스코프, 로직 분석기, 신시사이저 및 스펙트럼 분석기와 같은 테스트 장비를 광범위하게 사용합니다.
• 응용 프로그램을 저장하기위한 3 개 이상의 위치. 기본값은 ROM에 기록됩니다. 이것은 절대 변하지 않을 것입니다. 나머지 2 개는 현재 버전과 다음 / 마지막 버전입니다.
• MTBF (실패 분석)는 정말 중요합니다.
• 중요한 구성 요소에 대한 중복 시스템 및 장애 조치 계획.

방금 당신의 흥미로운 질문에 빠져 들었습니다.

나는 아폴로 기간 동안 계측 연구소에 있었고 나중에 "차가운 전쟁"중에 Draper Lab이라고 불렀습니다.

Apollo 안내 컴퓨터의 경우 RAM은 코어가 사용되었고 ROM은 특수 브레이드 코어가 사용되었습니다. 기계 자체는 완전히 NOR 게이트로 만들어졌으며 신뢰성을 위해 상당히 느리게 클럭되었습니다.

Minuteman 미사일에서 직접 작업하지는 않았지만 일부 문제를 알고있었습니다. 일부 전자 제품 근처에서 핵탄두가 사라지면 기본적으로 핵탄두가 단락됩니다. 안내 컴퓨터에는 Vc를 즉시 차단할 수있는 방사선 센서가있어 아무것도 타지 않습니다. 그런 다음 레지스터가 지워지면서 컴퓨터가 다시 시작됩니다.

이를 처리하기 위해 컴퓨터는 주기적으로 레지스터를 코어로 스냅 샷하고 다시 시작할 때 해당 체크 포인트에서 시작합니다. 이 작업을 수행하려면 소프트웨어 (ASM의 모든 기능)를 분석하여 오답없이 어떤 빈도로든 그러한 횟수의 히트가 발생할 수 있는지 확인해야했습니다. 이를 "재시동 보호"라고합니다. (감사합니다) 주어진 적이 없어서 매우 흥미로운 문제입니다.

특히 C에서 강력한 환경 안정성을 얻기 위해 내가 본 것 중 일부는 구체적입니다.

MISRA-C : 자동차 C 서브셋. Ravenscar ADA / Java와 비슷합니다.

워치 독 : 프로그램이 잠기지 않도록하십시오

ECC 메모리 (때로는)

체크섬 : 뒤집기 비트를 찾습니다. 하나의 시스템에서이 세 가지를 모두 보았습니다.

1) 프로그램을 지속적으로 체크섬합니다 (EPROM에 있었지만 여전히 뒤집어졌습니다).

2) 특정 데이터 구조를 주기적으로 체크섬합니다.

3) CPU 온 전성 검사가 주기적으로 수행됩니다.

4) IO 레지스터가 가지고있는 것을 확인하십시오.

4b) 독립적 인 입력으로 출력을 다시 읽고 확인하십시오.

프로그래밍 언어보다 훨씬 중요한 것은 기본 시스템 (OS 및 하드웨어)의 요구 사항입니다. 기본적으로 전체 시스템의 결정적이고 예측 가능한 동작 을 보장하고 증명해야 합니다. 실시간 커뮤니티에서 많은 관련 연구가 수행되었습니다. : 당신이 정말이 주제를 공부하고 싶다면 난 강력하게 두 권의 책을 읽어 보시기 바랍니다 리얼 타임 시스템 에 의해 제인 리우 와에 의해 같은 이름의 책 헤르만 코 페츠을 . 전자는 매우 이론적 인 방식으로 스케줄링을 다루고 후자는 발을 땅에 돌려 놓고 결함 시스템과 같은 (실시간) 시스템 설계의 모든 관련 측면을 거의 다룹니다.

또한 다음 두 사건은 소프트웨어 엔지니어가 무언가를 우주로 보낼 때 직면해야하는 문제의 품질을 잘 보여줍니다.

• Ariane 5 (다른 제약 조건에서 검증 된 소프트웨어 재사용)
• 화성 탐사선 패스 파인더 재부팅 (우선 반전)

이 문서 (2009 년경)를 Jet Propulsion Laboratory 사이트 에서 LaRS (Reliable Software for Laboratory) 의 C 프로그래밍 언어 에 대한 JPL 기관 코딩 표준에 대한 찾았습니다 .

다음은 문서화 된 규칙에 대한 요약입니다.

1. 언어 준수

   • 언어 정의를 벗어나지 마십시오.
   • 모든 경고가 활성화 된 상태에서 컴파일하십시오. 정적 소스 코드 분석기를 사용하십시오.

2. 예측 가능한 실행

   • 종료하려는 모든 루프에 대해 검증 가능한 루프 경계를 사용하십시오.
   • 직접 또는 간접 재귀를 사용하지 마십시오.
   • 작업 초기화 후 동적 메모리 할당을 사용하지 마십시오.
   • * 작업 통신에 IPC 메시지를 사용하십시오.
   • 작업 동기화에 작업 지연을 사용하지 마십시오.
   • * 공유 데이터 개체에 대한 쓰기 권한 (소유권)을 명시 적으로 전송합니다.
   • 세마포어 및 잠금 사용에 제한을 두십시오.
   • 메모리 보호, 안전 마진, 장벽 패턴을 사용하십시오.
   • goto, setjmp 또는 longjmp를 사용하지 마십시오.
   • 열거 형 목록의 요소에 선택적 값을 할당하지 마십시오.

3. 방어 코딩

   • 가능한 가장 작은 범위의 레벨에서 데이터 오브젝트를 선언하십시오.
   • 비 공백 함수의 반환 값을 확인하거나 명시 적으로 (공개)로 캐스트하십시오.
   • 함수에 전달 된 값의 유효성을 확인하십시오.
   • 정성 검사로 정적 및 동적 어설 션을 사용하십시오.
   • * int, short 등과 같은 사전 정의 된 C 데이터 유형 대신 U32, I16 등을 사용하십시오.
   • 복합 표현식의 평가 순서를 명시 적으로 작성하십시오.
   • 부작용이있는 표현은 사용하지 마십시오.

4. 코드 명확성

   • C 전처리기를 매우 제한적으로 사용하십시오.
   • 함수 나 블록 내에서 매크로를 정의하지 마십시오.
   • 매크로를 정의 해제하거나 재정의하지 마십시오.
   • #else, #elif 및 #endif를 일치하는 #if 또는 #ifdef와 동일한 파일에 배치하십시오.
   • * 한 줄에 한 문장이나 선언을 두지 마십시오.
   • * 제한된 수의 매개 변수로 짧은 기능을 사용하십시오.
   • * 선언 당 2 단계 이하의 간접 지시를 사용하십시오.
   • * 객체 참조 당 두 가지 수준의 역 참조를 사용하십시오.
   • 매크로 나 typedef 내부에서 역 참조 작업을 숨기지 마십시오.
   • * 상수가 아닌 함수 포인터를 사용하지 마십시오.
   • 함수 포인터를 다른 유형으로 캐스트하지 마십시오.
   • #include 지시문 앞에 코드 나 선언을 넣지 마십시오.

*) 모든 규칙은 하여야한다 별표로 표시 제외하고, 규칙.

방폭 컴퓨팅 시스템은 모두 신뢰성에 관한 것입니다. 신뢰성 에 대한 기본 개념 에서 해당 분야에 대한 자세한 소개를 볼 수 있습니다 장에 대한 자세한 내용은 Al-Grade Laprie & Brian Randell의 Algirdas Avižienis .

실시간은 또한 공간 컴퓨팅의 핵심 개념입니다. Pankrat으로서 Hermann Kopetz의 Real-Time Systems 를 추천 합니다.

공간 컴퓨팅의 과제를 실용적으로 이해하려면 다음 사항을 고려하십시오.

• 우주에서 극한의 조건 : 태양을 향할 때 매우 뜨겁고 반대쪽을 매우 추우 며, 메모리에서 비트를 뒤집을 수있는 많은 우주 광선, 웅크 리고있을 때 큰 가속 및 진동이 발생합니다. ... 공간을위한 하드웨어는 하드웨어보다 훨씬 강력해야합니다. 군대를 위해.

• 국제 우주 정거장 또는 허블 우주 망원경을 제외하고 장애가 발생하면 아무도 고장난 시스템을 찾아 교체하지 않습니다. 모든 것은 최대의 관찰 가능성과 명령 가능성을 통해, 그리고 예비 시스템을 통해 전환되어야합니다. 이것은 지구 위성에 쉽습니다. 통신 지연이 1 시간 길이 일 수있는 공간 프로브의 경우 더 어렵습니다. 실제로 모든 것이 가능한 한 신뢰할 수 있어야합니다.

내가 인턴으로 참여한 한 프로젝트에서 배운 것 :

하드웨어 사양은 일반적으로 더 나쁘게 변경됩니다!

예를 들어, 디자인에 사용 된 공간 강화 CPU는 20MHz에서 실행될 것이라고 약속 했습니다.

최종 결과는 12MHz에서 실행되었습니다. 이 프로젝트의 수석 프로그래머는 제어 시스템의 어려운 실시간 요구 사항을 충족시키기 위해 알고리즘을 재 설계하는 데 많은 시간을 보냈으며 대부분의 원격 측정 소프트웨어는 기본 CPU에서 실행되는 대신 두 번째 시스템으로 오프로드되었습니다.

따라서 원래 디자인에서 사용 가능한 추가 리소스를 남겨두고 사용 가능한 모든 CPU 및 메모리를 사용하지 마십시오.

소프트웨어 관점에서, 때때로 무작위로 코드의 비트를 뒤집는 특권 작업을 작성하고 어떻게 처리하는지 확인하십시오. 이것이 시뮬레이터입니다.

하드웨어 적으로는 공간을 차지하는 데 시간이 오래 걸리기 때문에 부품이 오래되었습니다. 또한, 새로운 부품의 크기는 지속적으로 줄어들고 있으며, 피처가 작을수록 (IC의 메모리 셀 생각) 방사선 이벤트로 인해 손상되기 쉽습니다.

나는 안전에 중요한 장치에서 일했고 비슷한 농구대를 거쳐야했다.

안전에 중요한 변수가있었습니다. 변수의 역의 사본이있었습니다. 각 루프 후에 변수의 역수를 검사했습니다.

우리는 모든 레지스터의 1과 0 테스트를 거쳤습니다. 여기에는 프로그램 카운터가 포함되었습니다!

우리는 마이크로 명령어 세트의 모든 opcode를 테스트했습니다. 레지스터 2 개를 추가 한 경우 레지스터가 추가되었는지 확인해야했습니다.

이 중 일부는 공간에있는 프로그램과 관련이 없을 수 있지만 가능한 검사 크기에 대한 감각을 제공합니다.

환경이 나빠질수록 오류 수정 코드 가 더 많이 사용되며 ECC 메모리 가 있다고 생각합니다. 가 어느 정도 사용될 수 있다고 생각합니다.

오류의 수준을 추정 할 수 있다면 도입 된 오류를 처리 할 수있는 오류 수정 코드를 구성 할 수 있습니다.

• 예, 핵심 메모리는 리서치 보드에 있습니다.
• 동적 메모리는 임베디드 시스템에 적합하지 않습니다. 신뢰성 문제.

데이터의 소프트웨어 ECC와 정보 이론 및 사용자 정의 로더를 사용하여 메모리 장애를 관리하기 위해 시스템 주위에 데이터를 분산시키는 것이 시작이라고 생각합니다. 그러나 나는 rad-hard 소프트웨어를 연구하지 않으므로 그것에 익숙하지 않습니다. 그냥 추측입니다.