[OTA] OTA Process

Overview

1. Update Mode 진입 : Reprogram Mode Boot
   Reprogram을 위한 최소한의 기능만 동작함
   이 이전에 별도 Register로 Download file Check 필요

2. Full Image 생성 : Unzip 등으로 전체를 만드는 과정
   차분 로직을 통해 Full image로 전환

3. Update : SOTA / FOTA

4. 정상 부팅 : Register Reset후 Booting(Mode 변경 Boot)

---

OTA Update 중에는 CAN BUS랑 분리하여 영향을 덜 주는게 좋다는게 정론
그래서 IVN에서 CAN대신 UART를 쓰는 Case가 존재함

AP(Reprogram Mode)

• Update Agent(MCU Update Agent) - Read(8Bytes) DATA PACK(CRC16 + 2Bytes)

• Middleware (MCU Middleware)

• Driver (UART Driver)

• Linux Kernel

대로 쭉 내려와서

Target ECU

• Boot Loader(CAN TP/UART 등)

• OS

• Flash

를 거쳐 Update됨

대신 UART 검증을 위해 패킷에 CRC16 적용해 매 패킷 송수신시 CRC 검출

---

그래서 큰 흐름으로는

1. CGW_CCU : IGN OFF -> 사용자 승인 -> Update Session Open후 AP에 작성

2. AP : Target 통신 시작 / Flash 지우기 / Image 보내기 / Target 통신 종료
   SDV에선 ZCU인데 Broadcast로 과거 Hash 값들을 비교함 (ECU 갯수 비교)
   취약점은 Fake ZCU로 ECU를 먹통만들어 버릴 수 있는데, 여기 보안 적용이 불가함
   즉 Fake ECU로 Update file 탈취도 가능함

3. 이후 Active Area Swap

---

Boot Sequence

Boot Loader가 관리하니까 완벽한 Bootloader를 만들거나 여러 loader로 쪼개서 실행

A/B Update는 Boot Sequence를 반드시 건드리기 때문에 일반적으로 Chip사에서 막아둠
(벽돌 방지)

1. Primary Bootloader
   MCU의 ROM에 영구 상주하는 SW Apps
   1단계 Bootloader가 있는 영역은 정보 공간으로 사용자 접근 종종 차단됨
   Reset할 때마다 실행되어 필수 HW reset후 SW를 메모리에 Load
   근데 MCU는 보통 Flash써서 로딩 필요없이 바로 Flash에 있는 프로그램에 제어권이 넘어감

2. Bootloader(Second Stage Boot Loader, SSBL)
   1단계가 OTA 미지원시 SSBL이 필요
   1단계와 마찬가지로 SSBL도 Reset마다 실행되나 OTA 업데이트 프로세스 부분만 실행