3.10 임베디드와 실시간 시스템

개요와 동기

임베디드 시스템은 범용 컴퓨터가 아니라 장치 위에서 실행되는 소프트웨어입니다. 자동차, 심박 조율기, 온도 조절기, 공장 로봇, 유도 장치 안에 삽니다. 소프트웨어는 그 장치 전용이고, 장치는 대개 메모리, 처리 능력, 에너지에 빡빡한 한도가 있습니다. 클라우드 콘솔의 버튼을 눌러 자원을 늘릴 수는 없습니다. 출하한 것이 흔히 몇 년 동안 돌아가는 것입니다.

실시간 시스템은 정확성이 올바른 답을 내는 것만이 아니라 타이밍에 달린 시스템입니다. 완벽한 전개 명령을 1초 늦게 계산한 에어백 제어기는 완전히 실패한 것입니다. 실시간 작업은 모든 태스크에 어려운 질문을 더합니다. 이것이 최악의 경우에도 매번 마감 시한까지 끝나는가? 이는 웹과 클라우드 소프트웨어에서 흔한 처리량 우선의 사고와는 다른 규율입니다.

대규모 조직에는 처음 보이는 것보다 이것이 더 중요합니다. 기업은 커넥티드 카, 의료 기기, 산업 제어기, 수십억 개의 사물 인터넷(IoT) 장치를 만듭니다. 정부는 국방 플랫폼, 항공 전자 장비, 전력망 제어기, 의료 규제 기관을 운영합니다. 이런 영역에서 소프트웨어 결함은 사람을 다치게 하고, 생산 라인을 멈추고, 국가 안보를 위태롭게 할 수 있습니다. 여기의 규칙은 더 엄격하고, 테스트는 더 어렵고, 표준은 법적 구속력이 있습니다. 이 장은 실제 제약 아래서 정확하고, 시의적절하고, 안전하고, 보안이 된 소프트웨어를 만들도록 돕습니다. 소프트웨어 구축(2.9장), 분산 시스템(3.3장), 확장성과 성능(3.5장), 인프라 및 클라우드 보안(4.3장), 소프트웨어 유지보수(3.7장)와 연결됩니다.

핵심 원칙

타이밍은 성능의 부가 사항이 아니라 정확성 요구 사항입니다. 늦은 답은 틀린 답일 수 있습니다.
평균이 아니라 최악의 경우에 맞춰 설계하십시오. 실시간 보장은 평소 속도가 아니라 최악의 동작에 근거합니다.
결정성이 순수한 속도를 이깁니다. 항상 마감을 맞추는 예측 가능한 시스템이 가끔 놓치는 더 빠른 시스템을 이깁니다.
자원은 유한하고 고정되어 있습니다. 메모리, CPU 주기, 에너지를 돈을 예산 잡듯 의도적으로 예산하십시오.
안전과 보안은 나중에 더하는 것이 아니라 엔지니어링해 넣는 것입니다. 규제 영역에서는 품질을 단언하는 것이 아니라 작업을 보여야 합니다.
하드웨어는 시스템의 일부입니다. 칩, 센서, 물리를 추론하지 않고는 소프트웨어를 추론할 수 없습니다.
현장 업데이트는 사후 생각이 아니라 수명 주기 능력입니다. 세상에 나간 장치에는 수정을 받을 안전한 방법이 필요합니다.

권장 사항

각 타이밍 요구 사항을 하드, 펌, 소프트로 분류한다

모든 마감이 같지는 않습니다. 하드 실시간 마감은 놓치면 시스템 실패나 피해를 일으키므로 절대 놓쳐서는 안 됩니다. 엔진 제어나 비행 조종면을 생각하십시오. 펌 마감은 드문 놓침을 허용하지만 늦은 결과는 쓸모없어 버려집니다. 소프트 실시간 마감은 가치가 우아하게 저하됩니다. 약간 늦게 도착한 비디오 프레임은 품질을 낮추지만 재앙을 일으키지 않습니다. 타이밍에 민감한 모든 태스크에 그 등급을 표시하십시오. 노력, 테스트의 엄밀함, 비용이 엄청나게 다르기 때문입니다. 두 가지 속성이 타이밍 동작을 기술합니다. 지연은 이벤트와 응답 사이의 지연입니다. 지터는 그 지연의 한 번과 다음 번 사이의 변동입니다. 하드 실시간 시스템은 지연을 낮추는 것만큼 지터를 한정하는 데 신경 씁니다. 예측 가능성이 마감이 항상 지켜짐을 증명하게 해 주기 때문입니다.

실행 기반을 의도적으로 선택한다: RTOS 또는 베어메탈

두 가지 주된 기반이 있습니다. 베어메탈 펌웨어는 운영체제 없이 하드웨어에서 직접 실행되며, 단순한 루프와 인터럽트 핸들러를 씁니다. 가장 작고 가장 예측 가능한 선택지이며, 하나의 분명한 일을 하는 아주 작은 장치에 맞습니다. 실시간 운영체제(RTOS)는 태스크를 우선순위로 스케줄링하고 타이밍 한계를 보장하는 작은 운영체제입니다. 타이밍을 예측 가능하게 유지하면서 여러 태스크, 스케줄러, 타이머와 메시지 큐 같은 서비스를 줍니다. 마감이 다른 동시 태스크가 여럿일 때 RTOS를 고르십시오. 장치가 매우 제약되었거나 타이밍이 증명 가능하게 단순해야 할 때 베어메탈을 고르십시오. 하드 실시간 작업에는 선점형 우선순위 기반 스케줄러를 선호하고, 태스크 빈도로 우선순위를 할당하여 태스크 집합이 스케줄 가능함을 증명하게 해 주는 율 단조 스케줄링 같은 방법으로 분석하십시오.

메모리, CPU, 전력을 일급 자원으로 예산한다

각 희소 자원을 딱딱한 상한이 있는 예산으로 다루십시오. 메모리에서는 힙의 동적 할당보다 정적 할당을 선호하십시오. 동적 메모리는 조각나고 최악의 순간에 예측 불가능하게 실패할 수 있기 때문입니다. 많은 안전 표준이 정확히 이 이유로 시작 후의 힙 사용을 제한하거나 금지합니다. CPU에서는 최악 실행 시간(WCET), 곧 태스크가 걸릴 수 있는 가장 긴 시간을 측정하고, 평균이 아니라 그 숫자에 맞춰 스케줄링하십시오. 전력에서는 많은 장치가 배터리로 돌거나 에너지를 수확함을 기억하고, 몇 달이나 몇 년 지속되어야 하는 에너지 예산을 맞추도록 듀티 사이클, 슬립 상태, 깨우기 이벤트를 설계하십시오. 이 예산을 적어 두고 다른 요구 사항처럼 검토하십시오.

인터럽트와 동시성을 엄격한 규율로 다룬다

인터럽트는 현재 작업을 멈추고 핸들러를 즉시 실행하는 하드웨어 신호입니다. 인터럽트는 장치가 세상에 즉각 반응하는 방법이며, 미묘한 버그의 주된 원천입니다. 핸들러를 가능한 한 짧게 유지하십시오. 이벤트를 확인하고, 최소한의 데이터를 보관하고, 실제 작업은 일반 태스크로 미루십시오. 인터럽트는 어느 두 명령 사이에서든 발생할 수 있으므로 공유 데이터를 경쟁 조건으로부터 신중하게 보호해야 합니다. 락 없는 기법, 짧은 임계 구역, 잘 이해된 프리미티브를 쓰고, 락을 쥔 낮은 우선순위 태스크가 높은 우선순위 태스크를 막는 우선순위 역전을 경계하십시오. 이 동시성은 3.3장의 추론을 공유하지만, 타이밍이 더 빡빡하고 재시도할 여지가 없습니다.

하드웨어 세부를 격리하는 디바이스 드라이버를 쓴다

디바이스 드라이버는 센서, 무선, 모터 제어기 같은 특정 하드웨어와 대화하는 소프트웨어 계층입니다. 하드웨어 전용 코드를 깨끗한 인터페이스 뒤에 두어, 나머지 소프트웨어가 레지스터 주소가 아니라 안정적인 추상화에 의존하게 하십시오. 이렇게 하면 코드를 타깃 밖에서 테스트할 수 있고, 칩이 품절되었을 때 이식하기 쉽고, 추론하기 단순해집니다. 타이밍, 바이트 순서, 하드웨어의 괴팍함에 대한 모든 가정을 문서화하십시오. 현장 실패를 일으키는 것이 이런 세부이기 때문입니다. 잘못된 비트 하나가 모터를 멈출 수 있는 곳에 적용된 2.9장의 구축 규율입니다.

도메인을 다스리는 기능 안전 표준을 채택한다

장치가 사람이나 재산을 해칠 수 있다면 기능 안전 표준이 적용될 가능성이 높고, 그것은 흔히 법입니다. IEC 61508은 전자 시스템 안전에 대한 일반 표준이며 여러 다른 표준의 모체입니다. ISO 26262는 도로 차량 안전을 다룹니다. DO-178C는 민간 항공의 탑재 소프트웨어를 다룹니다. IEC 62304는 의료 기기 소프트웨어를 다룹니다. 코딩에는 MISRA C가 위험한 C 언어 기능을 제한해 코드를 더 안전하고 분석 가능하게 하는 널리 쓰이는 규칙 집합입니다. 이런 표준은 요구 사항에서 코드, 테스트까지의 추적성, 정의된 프로세스, 감사자나 규제 기관에 건넬 수 있는 증거를 요구합니다. 맞는 표준을 일찍 채택하십시오. 서류 흔적을 나중에 사후 보강하는 것은 고통스럽고 때로 불가능하기 때문입니다.

시뮬레이션과 하드웨어 인 더 루프로 테스트한다

웹 앱을 테스트하는 방식으로 임베디드 소프트웨어를 테스트할 수는 없습니다. 계층화된 전략을 세우십시오. 일반 컴퓨터에서 하드웨어 추상화 인터페이스에 대해 단위 테스트를 실행하십시오. 실제 하드웨어가 희소하거나 시험하기 위험할 때 장치와 환경을 모델링하는 시뮬레이션을 쓰십시오. 그다음 하드웨어 인 더 루프(HIL) 테스트를 쓰십시오. 실제 제어기가 자신이 제어하는 물리 시스템의 시뮬레이션 버전에 대해 실행되어, 고장 난 센서나 갑작스러운 부하 같은 결함 조건을 안전하게 테스트할 수 있습니다. 모든 변경이 장치에 닿기 전에 현실적인 조건에서 검사되도록 이 테스트를 파이프라인에서 자동화하십시오.

OTA 업데이트와 장치 보안을 첫날부터 설계한다

현장의 장치는 수정이 필요할 것이므로, 새 펌웨어를 네트워크로 안전하게 전달하는 방법인 무선(OTA) 업데이트를 계획하십시오. 안전한 OTA 설계는 각 업데이트를 암호로 서명하고, 설치 전에 서명을 검증하고, 원자적으로 업데이트하며, 새 것이 부팅에 실패하면 알려진 정상 이미지로 롤백할 수 있습니다. 이를 제약된 하드웨어에 맞춘 4.3장의 보안 원칙과 짝지으십시오. 하드웨어 신뢰 루트와 보안 부팅을 써서 서명된 펌웨어만 실행되게 하십시오. 전송 중과 저장 시 데이터를 암호화하십시오. 기본 자격 증명을 바꾸고 쓰지 않는 인터페이스를 끄십시오. IoT 장치군은 거대한 공격 표면을 가진 분산 시스템이며, 약한 기본 비밀번호 하나가 수백만 장치를 한꺼번에 침해할 수 있습니다.

장단점

선택	장점	단점 / 비용
RTOS	멀티태스킹. 우선순위 스케줄링. 타이밍 서비스	오버헤드. 더 큰 풋프린트. 학습 곡선
베어메탈	가장 작고 가장 예측 가능. 완전한 통제	많은 태스크로 확장하기 어려움. 수동 작업이 더 많음
정적 할당	예측 가능. 조각화 없음. 안전에 우호적	덜 유연함. 모든 것의 크기를 미리 정해야 함
공식 안전 인증	법적 시장 접근. 엄밀한 증거. 높은 신뢰	큰 시간과 돈의 비용. 느린 반복
OTA 업데이트	현장 장치 수정과 개선. 수명 연장	업데이트 인프라. 보안 부담. 롤백 위험

핵심 트레이드오프는 예측 가능성과 유연성 사이에 있습니다. 범용 시스템을 편리하게 만드는 모든 것(동적 메모리, 백그라운드 가비지 컬렉션, 최선 노력 스케줄링, 탄력적 자원)이 태스크가 항상 고정된 풋프린트 안에서 제시간에 끝난다는 보장에 맞서 작동합니다. 임베디드와 실시간 엔지니어링은 결정성과 안전을 얻으려고 유연성을 의도적으로 포기합니다. 기술은 마감이나 위험이 정말 요구하는 곳에만 그 거래를 쓰고, 유연하고 더 빨리 움직이는 부분(장치의 클라우드 백엔드 같은)은 깨끗한 경계 반대편에 두는 것입니다.

팀과 논의할 질문

타이밍이 핵심인 경로에서 평균 지연만이 아니라 지터를 측정합니까? 하드 실시간 정확성은 일반적 지연을 낮추는 것만이 아니라 응답 시간의 변동(지터)을 한정하는 데 달려 있습니다. 예측 가능성이 마감이 항상 지켜짐을 증명하게 해 주기 때문입니다. 평균은 낮지만 가끔 큰 스파이크가 있는 제어 루프도 마감을 놓쳐 피해를 일으킬 수 있고, 평균은 그것을 가립니다. 타이밍이 핵심인 각 태스크의 최악의 경우를 포함한 분포 측정치를 가져오고, 테스트의 엄밀함이 놓침의 결과와 맞도록 모두를 하드, 펌, 소프트로 표시하십시오. 범용 시스템에서 편리한 모든 것(동적 메모리, 가비지 컬렉션, 최선 노력 스케줄링)은 예측 가능성을 공격하므로 하드 경로에서 빼 둡니다. 평균만 보고한다면 하드 마감이 지켜진다고 정직하게 주장할 수 없습니다.
RTOS 또는 베어메탈 선택이 여전히 옳으며, 태스크 집합이 스케줄 가능함을 증명할 수 있습니까? 실행 기반은 장치가 커짐에 따라 재검토할 결정입니다. 베어메탈은 하나의 분명한 일에 가장 작고 가장 예측 가능하고, RTOS는 마감이 다른 동시 태스크가 여럿일 때 오버헤드만큼 값을 합니다. 하드 실시간 작업에 이 장은 율 단조 스케줄링 같은 방법으로 분석되는 선점형 우선순위 기반 스케줄러를 가리키며, 태스크가 맞기를 바라는 대신 맞음을 증명하게 해 줍니다. 현재 태스크 집합, 그 빈도, 최악 실행 시간을 가져와, 스케줄 가능성이 실제로 성립하는지 아니면 태스크가 기반이 보장할 수 있는 것을 넘어 조용히 쌓였는지 확인하십시오. 락을 쥔 낮은 우선순위 태스크가 높은 우선순위 태스크를 막는 우선순위 역전을 경계하십시오. 태스크 집합이 아니라 습관으로 기반을 고르는 것이 타이밍 보장이 조용히 침식되는 방식입니다.
결정적인 장치와 유연한 클라우드 백엔드 사이의 경계는 정확히 어디이며, 한쪽에서 빠르게 움직이면서 다른 쪽을 위태롭게 하지 않을 만큼 깨끗합니까? 이 장의 핵심 트레이드오프는 결정성과 안전을 얻으려고 유연성을 포기하며, 기술은 마감이나 위험이 정말 요구하는 곳에만 그 거래를 쓰는 것입니다. 깨끗한 경계는 안전이 핵심인 펌웨어가 보수적이고 인증된 상태로 남고 클라우드 백엔드는 빠르게 반복하게 하여, 둘이 각자 안전한 속도로 진화하게 합니다. 아키텍처를 가져와 그 이음새를 찾으십시오. 결정적임을 증명하고 서명되고 검증된 경로로 업데이트해야 하는 것과, 서버에서 매주 바뀔 수 있는 것은 무엇입니까? 선을 흐리면 클라우드식 습관(동적 할당, 최선 노력 타이밍)이 제어 경로로 끌려 들어가거나, 백엔드가 펌웨어의 주기로 불필요하게 느려집니다. 경계를 맞게 잡는 것이 안전 증거와 전달 속도를 모두 지켜 줍니다.
각 제품을 어떤 기능 안전 표준이 다스리며, 현재 증거는 감사자가 받아들일 것과 얼마나 떨어져 있습니까? 표준(IEC 61508, 도로 차량의 ISO 26262, 탑재 소프트웨어의 DO-178C, 의료 기기의 IEC 62304)은 흔히 법이며, 마지막에 꾸며낼 수 없는 요구 사항에서 코드, 테스트까지의 추적성을 요구합니다. 큰 팀에서 위험은 그룹마다 서류 흔적을 고르지 않게 채택해, 한 제품군은 감사 준비가 되었는데 다른 제품군은 인증 중반에야 요구 사항이 한 번도 추적되지 않았음을 발견하는 것입니다. 상충하는 끌림은 속도입니다. 완전한 추적성과 MISRA C 시행은 일상 반복을 늦추고, 마감 압박 아래의 팀은 증거를 “나중으로” 미루고 싶어집니다. 현재 추적성 매트릭스, 여전히 열려 있는 정적 분석 발견 사항, 목표 보증 수준에 대한 정직한 간극 분석을 가져오십시오. 기업과 정부 맥락에서는 인증 리드 타임과 감사자의 기대를 더하십시오. 설계 후에 증거를 사후 보강하는 것은 느리고, 비싸고, 때로 불가능하며, 미뤄진 인증은 시장 접근을 완전히 막을 수 있기 때문입니다.
내일 현장 장치에서 심각한 결함이 발견된다면 전체 장치군에 걸쳐 안전하게 얼마나 빨리 고칠 수 있으며, 롤백을 리허설해 보았습니까? 패치할 수 없는 장치는 영구적인 안전 및 보안 부채가 되고, 물리적 리콜은 서명된 무선 업데이트보다 몇 자릿수 더 비쌉니다. 긴장은 부주의한 업데이트 메커니즘이 그 자체로 공격 표면이자 벽돌화 위험이라는 점입니다. 서명되지 않은 이미지를 설치하거나 나쁜 부팅을 롤백할 수 없는 OTA 경로는 나쁜 릴리스 하나를 수백만 대의 죽은 장치로 바꿀 수 있습니다. 업데이트 설계(암호 서명, 설치 전 서명 검증, 원자적 설치, 알려진 정상 이미지로의 자동 롤백), 보안 부팅과 하드웨어 신뢰 루트 상태, 마지막으로 누군가 실제 하드웨어에서 롤백을 실행해 본 때를 가져오십시오. 기업이나 공공 장치군에서는 서명 키에 누가 책임지는지, 침해된 키를 어떻게 폐기할지 더하십시오. 유출된 키나 공유된 기본 자격 증명이 장치군 전체를 한꺼번에 침해할 수 있기 때문입니다.
메모리, CPU, 전력 예산이 딱딱한 상한과 함께 적혀 있으며, 테스트 전략이 시뮬레이션과 실제 하드웨어를 모두 실행합니까? 실시간 보장은 평균 동작이 아니라 최악 실행 시간과 고정된 자원 풋프린트에 근거하므로, 예산에 없는 힙 할당이나 테스트되지 않은 최악의 부하가 결정성이 조용히 침식되는 곳입니다. 큰 팀에서 위험은 표류입니다. 태스크가 쌓이고, 메모리가 슬금슬금 늘고, 몇 주의 가동 후 장치가 현장에서 실패할 때까지 아무도 예산을 소유하지 않습니다. 트레이드오프는 커버리지 대 비용입니다. 고장 난 센서 같은 결함을 주입하는 하드웨어 인 더 루프 장비는 만들기 비싸고, 순수 시뮬레이션은 실제 칩에서만 나타나는 타이밍 버그를 가립니다. 문서화된 예산, 그에 대한 측정된 최악 실행 시간, 릴리스 전에 파이프라인이 추상화 계층의 단위 테스트, 시뮬레이션, 하드웨어 인 더 루프를 실행한다는 증거를 가져오십시오. 규제되고 정부의 환경에서는 이를 표준이 요구하는 구조적 테스트 커버리지에 연결하십시오. 감사자는 평균적 경우가 괜찮아 보였다는 보증이 아니라 결함 조건이 실행되었다는 증명을 원할 것이기 때문입니다.

분야별 관점

스타트업. 속도와 생존이 지배하므로 가벼운 RTOS나 단순한 베어메탈 루프를 고르고, 시작 후 동적 할당을 금지하고, 없는 인증 예산을 쫓는 대신 하나의 핵심 루프의 최악 시간을 측정하십시오. 시장이 강제하지 않는 한 공식 기능 안전 프로세스는 건너뛰되, 자동 롤백이 있는 서명된 무선 업데이트는 절대 건너뛰지 마십시오. 어린 회사는 현장 리콜에서 살아남을 수 없고, 원격 수정이 나쁜 하룻밤과 죽은 제품의 차이입니다. 희소한 엔지니어가 감당할 수 없는 파이프라인을 유지하지 않도록 장치 펌웨어를 작고 보수적으로 유지하십시오.

소기업. 임베디드 전문가가 없으니 스케줄러나 부트로더를 직접 만들기보다 검증된 모듈, 레퍼런스 설계, 벤더 RTOS 배포판에 기대십시오. 만들기 대 사기의 선택을 앞으로 10년 동안 누가 장치를 패치할지로 구성하십시오. 믿을 수 있는 구매한 보안 및 업데이트 스택이 아무도 유지할 수 없는 맞춤형보다 낫습니다. 기본 비밀번호, 열린 디버그 인터페이스, 서명되지 않은 업데이트를 가장 해가 될 실패로 다루십시오. 예방하기 싸고 현장에서 발견하면 파멸적이기 때문입니다.

대기업. 문제는 많은 제품군과 팀에 걸친 일관성입니다. 공유 실행 기반 정책, 공통 자원 예산 템플릿, 시행되는 MISRA C와 정적 분석, 각 그룹이 다시 발명하지 않도록 인증된 하나의 무선 업데이트 및 보안 부팅 플랫폼입니다. 기능 안전과 하드웨어 인 더 루프 부담을 명시적으로 예산에 넣고, 칩 품절이 제품을 발이 묶이게 하지 않도록 하드웨어 추상화 인터페이스를 표준화하고, 장치군의 타이밍 증거, 안전 산출물, 보안 태세를 팀별 민간 전승이 아니라 다스려지는 자산으로 관리하십시오. 장치군 전반의 약한 기본 자격 증명 하나는 기업 규모의 부채이므로 자격 증명과 키 관리를 중앙화하십시오.

정부. 조달 규칙, 투명성, 공적 책임성이 모든 선택을 형성합니다. 공급자가 위험에 맞는 보증 수준에서 탑재, 의료, 국방 소프트웨어를 다스리는 표준(DO-178C, IEC 62304, IEC 61508)에 따라 개발하고, 감사자가 검토할 추적성과 구조적 커버리지 증거를 넘기도록 요구하십시오. 비행이나 전력망 시스템의 검증되지 않은 업데이트는 용납할 수 없으므로 보안 부팅, 하드웨어 신뢰 루트, 통제되고 서명된 현장 업데이트 프로세스를 요구하십시오. 소스, 안전 산출물에 대한 권리와 두 번째 공급자로 재인증할 수 있는 계약을 선호해, 벤더의 폐업이 대중이 수십 년 의존하는 시스템을 발이 묶이게 하지 않도록 하십시오.

사례

스타트업. 배터리로 구동되는 공기질 모니터를 만드는 작은 하드웨어 스타트업은 고정된 태스크 집합과 시작 후 동적 할당 없음의 가벼운 RTOS에 맞춰 펌웨어를 쓰므로, 출하된 장치가 코인 셀로 수년간 돌아가는 바로 그 장치입니다. 인증 예산이 없어도 팀은 센서 읽기 루프의 최악 시간을 측정하고 매 릴리스 전에 벤치 장비에서 주입한 결함 조건에 대해 장치를 테스트합니다. 자동 롤백이 있는 서명된 무선 업데이트 덕에 출하된 모든 장치의 결함을 고칠 수 있어, 현장의 나쁜 측정값이 어린 회사가 살아남을 수 없는 리콜을 뜻하지 않습니다.

대기업. 한 커넥티드 카 제조사가 전자 제동 제어기를 만듭니다. 하드 실시간 제어 루프는 율 단조 스케줄링과 정적 메모리의 RTOS에서 돌고, 모든 태스크가 측정된 최악 실행 시간을 지닙니다. 팀은 요구 사항에서 코드, 테스트까지 완전한 추적성으로 ISO 26262에 맞춰 개발하고, 모든 커밋에서 정적 분석으로 MISRA C를 시행합니다. 하드웨어 인 더 루프 장비가 주입된 센서 결함을 포함한 수천 개의 도로 시나리오를 재생한 뒤에야 어떤 펌웨어든 출하됩니다. 서명된 OTA 업데이트로 회사는 비싼 리콜 없이 전체 장치군의 결함을 고치며, 차가 새 이미지로 부팅에 실패하면 자동 롤백됩니다.

정부. 한 국가 항공 당국이 새 비행 관리 컴퓨터를 인증합니다. 공급자는 위험에 맞는 보증 수준에서 DO-178C에 따라 탑재 소프트웨어를 개발하고, 감사자가 검토하는 요구 사항 커버리지와 구조적 테스트 커버리지의 증거를 만듭니다. 타이밍은 한정된 인터럽트 지연과 시작 후 동적 할당 없음으로 최악의 부하에서 결정적임이 증명됩니다. 보안 부팅과 하드웨어 신뢰 루트가 서명되고 인증된 펌웨어만 실행됨을 보장합니다. 비행 시스템의 검증되지 않은 업데이트는 용납할 수 없으므로 현장 업데이트는 통제되고 서명된 프로세스를 따릅니다.

비즈니스 사례: 동기, ROI, TCO

비즈니스 사례는 실패의 비용과 시장 접근의 비용이 지배합니다. 규제 영역에서는 안전 인증 없이는 제품을 아예 팔 수 없으므로, 프로세스 비용은 단순히 진입 가격입니다. 그 너머에서 현장 하드웨어의 결함은 엄청나게 비쌉니다. 물리적 리콜은 클라우드 핫픽스보다 훨씬 많이 들고, 안전 사고는 제품군을 끝낼 수 있는 책임, 규제 벌금, 평판 손상을 안깁니다. 처음부터 안전, 결정성, 업데이트 가능성을 만들어 넣는 것은 현장에서 그 부재를 발견하는 것에 비해 쌉니다.

투자 수익을 피한 리콜, 더 빠른 인증, 더 긴 장치 수명을 중심으로 구성하십시오. 견고한 OTA 능력은 많은 잠재적 리콜을 저비용 원격 수정으로 바꾸며, 피한 리콜 하나가 업데이트 프로그램 전체를 지불할 수 있습니다. 엄밀한 WCET 분석과 자원 예산은 자신 있게 더 싼 하드웨어로 출하하게 해 큰 장치군 전체에서 단가를 낮춥니다. 총소유비용에서는 이런 장치가 수년, 수십 년 산다는 것을 기억하십시오. 유지보수, 보안 패치, 지원 부담(3.7장)은 초기 구축을 압도합니다. 업데이트 가능성, 분명한 하드웨어 추상화, 문서화된 예산을 위한 설계가 그 긴 꼬리를 감당할 만하게 유지합니다.

안티패턴과 함정

평균적 경우의 최적화. 마감을 “대체로” 맞추는 것은 하드 실시간 요구 사항에 실패하는 것입니다.
제어 경로의 동적 할당. 힙 조각화는 몇 주의 가동 후에야 나타나는 실패를 일으킵니다.
뚱뚱한 인터럽트 핸들러. 인터럽트 안에 무거운 처리를 넣으면 타이밍 예산이 깨지고 경쟁 조건이 생깁니다.
감사까지 표준 무시. 추적성과 증거를 늦게 사후 보강하는 것은 느리고, 비싸고, 때로 불가능합니다.
업데이트 경로 없이 출하. 패치할 수 없는 장치는 영구적인 보안 및 안전 부채가 됩니다.
기본 비밀번호와 열린 인터페이스. 약한 자격 증명 하나가 IoT 장치군을 봇넷으로 만듭니다.
시뮬레이터에서만 또는 하드웨어에서만 테스트. 각각이 다른 쪽이 잡을 버그를 가립니다. 둘 다 필요합니다.
하드웨어를 남의 문제로 취급. 여기서는 타이밍, 바이트 순서, 센서의 괴팍함이 소프트웨어의 관심사입니다.

성숙도 모델

1단계: 시작. 타이밍은 분석되는 것이 아니라 바라는 것입니다. 메모리는 마음대로 동적으로 할당됩니다. 어떤 기능 안전 표준도 따르지 않습니다. 테스트는 수동이고 장치에서만 합니다. 출하 후 장치를 업데이트할 수 없어, 현장 결함은 리콜이나 영구 부채를 뜻합니다.
2단계: 발전. 일부 태스크는 타이밍이 측정되고 기본 RTOS나 구조화된 루프가 갖춰져 있지만, 실천은 팀마다 다릅니다. 코딩 지침은 있지만 시행되지 않습니다. 테스트에 약간의 시뮬레이션이 포함됩니다. 수동적이고 위험한 업데이트 경로가 일부 제품에는 있고 일부에는 없습니다. 좋은 습관이 있지만 일관되지 않고, 다음 제품군이 그것을 물려받는다는 보장은 없습니다.
3단계: 표준화. 타이밍 요구 사항이 하드, 펌, 소프트로 분류되고, 최악 실행 시간과 스케줄 가능성 방법으로 분석되어 조직 전체에 문서화되고 시행됩니다. 메모리, CPU, 전력 자원 예산이 딱딱한 상한과 함께 적혀 있습니다. 다스리는 기능 안전 표준이 요구 사항에서 코드, 테스트까지의 추적성으로 지켜지고, MISRA C나 그에 상응하는 것이 모든 커밋에서 정적 분석으로 시행됩니다. 하드웨어 인 더 루프 테스트가 파이프라인에서 돕니다. 롤백이 있는 서명된 원자적 무선 업데이트와 보안 부팅이 어디서나 요구되는 기준선입니다.
4단계: 관리. 조직이 임베디드 자산을 기준선에 대해 측정하고 통제합니다. 최악 실행 시간 마진, 지터 분포, 마감 놓침 비율, 메모리와 전력 여유, 여전히 열려 있는 정적 분석 발견 사항, 인증 증거 커버리지, 무선 업데이트 성공 및 롤백 비율을 추적하고 합의된 목표와 비교합니다. 자원이나 타이밍 예산에 대한 표류는 장치가 현장에서 실패하기 전에 조치를 촉발하고, 릴리스 진행 여부 결정은 그 순간의 판단이 아니라 이 데이터에 근거합니다. 관리자는 어느 제품군이 감사 준비가 되었고 어느 것이 놓친 마감이나 초과된 예산으로 향하는지 볼 수 있습니다.
5단계: 오케스트레이션. 결정성, 안전 증거, 보안이 지속적으로 검증되고 자동화됩니다. 결함 주입과 하드웨어 인 더 루프가 모든 변경에서 돌고, 인증 산출물은 프로세스의 부산물로 생성됩니다. 장치군은 긴 서비스 수명 내내 규모에서 안전하게 모니터링되고, 패치되고, 업데이트됩니다. 조직은 칩이 품절되고, 위협이 진화하고, 규제가 바뀜에 따라 실행 기반, 자원 예산, 표준 채택을 적응시키며, 각 위기에 홀로 반응하는 대신 증거에 따라 장치 포트폴리오 전체를 재균형합니다.

논의를 위한 아이디어

장치의 태스크 중 어느 것이 진짜 하드 실시간이며, 각각이 항상 마감을 맞춘다고 증명할 수 있습니까?
핵심 제어 루프의 최악 실행 시간을 압니까, 아니면 평균만 압니까?
제품을 어떤 기능 안전 표준이 다스리며, 현재 증거는 그것이 요구하는 것과 얼마나 떨어져 있습니까?
내일 현장 장치에서 심각한 결함이 발견된다면 어떻게, 얼마나 빨리 고치겠습니까?
제어 경로에 동적 메모리 할당이 여전히 어디에 있으며, 1000시간째에 그것이 실패하면 어떻게 됩니까?
공유된 기본 자격 증명 하나를 찾은 공격자를 IoT 장치군은 어떻게 견디겠습니까?

핵심 요점

임베디드 소프트웨어는 제약된 하드웨어에서 실행되며, 실시간 정확성은 올바른 답만이 아니라 타이밍에 달려 있습니다.
각 마감을 하드, 펌, 소프트로 분류하고, 순수한 속도보다 최악의 타이밍, 한정된 지터, 결정성에 맞춰 설계하십시오.
RTOS나 베어메탈을 의도적으로 고르고, 메모리, CPU, 전력을 고정된 일급 자원으로 예산하십시오.
인터럽트 핸들러를 아주 작게 유지하고, 공유 데이터를 보호하고, 하드웨어를 깨끗하고 테스트 가능한 드라이버 인터페이스 뒤에 격리하십시오.
도메인이 요구하는 기능 안전 표준(IEC 61508, ISO 26262, DO-178C, IEC 62304, MISRA C)을 완전한 추적성과 함께 일찍 채택하십시오.
시뮬레이션과 하드웨어 인 더 루프로 테스트하고, 안전하고 서명되고 롤백 가능한 OTA 업데이트와 장치 보안을 첫날부터 구축하십시오.

참고 문헌과 더 읽을거리

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
ISO 26262, Road Vehicles: Functional Safety
RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification
IEC 62304, Medical Device Software: Software Life Cycle Processes
MISRA, MISRA C: Guidelines for the Use of the C Language in Critical Systems
Michael Barr and Anthony Massa, Programming Embedded Systems
Elecia White, Making Embedded Systems
Jane W. S. Liu, Real-Time Systems
Giorgio Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications
Colin Walls, Embedded Software: The Works
Philip Koopman, Better Embedded System Software
OWASP Internet of Things (IoT) security guidance