[OTA] Over-The-Air 개요

CS·2026년 2월 3일

OTA

목록 보기
1/2

Overview

무선 SW Update 기술은 무선 통신을 활용해 차량의 SW를 최신 버전으로 Update하는 기술

SW와 ECU를 언제나 최신 상태로 유지해 새 기능과 편리하고 안전한 차량 서비스 제공

  • SOTA : 주로 AVN에 적용되는 기술

  • FOTA : VCU(동력)/IEB(브레이크)/MDPS(스티어링)/ECS(전자제어 서스펜션) 등 기능 개선 가능
    ADAS 개선 및 확장도 가능하도록 다양한 ECU를 개선해 서비스센터 없이 경험 증대

가속 페달 반응 설정을 개선해 가속 특성 변화 / 드라이브 모드 특성 조율 가능(VCU의 PE기능)
스티어링 감도나 ECS 설정을 달리해 주행 질감 개선도 가능

절차는 다음과 같다

  1. Download : 주행 중 Download

  2. 설치 : 정차 후 전원을 끄면 차량이 Update 하기 안전한 상태인지 확인하는 과정을 거치고
    IVI를 통해 Update 승인 여부를 알리는 창을 띄움. 선택 시 설치 진행 (운행 금지)
    또한, 충전이나 V2L기능 또한 불가능 함

  • Server - Vehicle간 인증을 통한 무선 통신 보안 필요

  • ECU Update시 ROM file 변조 / 외부 해킹 막기 위한 ECU별 HSM 적용 필요

  • UNECE WP.29 규정 준수 등 필요

또, Update시 오류를 줄이기 위한

  1. 검증 절차

  2. 복구 방법

존재

Definition

차량의 수명 주기 안전 / 보안 관련해 악영향을 줄 수 있는 SW 결함 수정하고 성능을 개선하기 위해
SW를 Update하는 기술W를 Update하는 기술

무선통신으로 SW를 업데이트하는 기술로 기존의 OBD-II 단자를 통한 Update방식 탈피하고도

  • 새 기능 추가

  • 오류 개선

  • 보안 강화 등 가능

Recall 요구되는 일부 결함 수준도 OTA만으로 해결가능 (서비스 엔지니어를 통하지 않아도 됨)

종류

  1. SOTA : 구동계 제외 AVN Domain
    Update하며 이용이 가능해야 함

  • 메모리 이중화

  • 백그라운드 다운로드 및 설치

  1. FOTA : ECU Update로 주행 중에 할 수 없음
  1. E/E Domain Architecture의 한계

내부 ECU들의 위치와 존재 여부 즉, 아키텍처에 표준이 없음

SW 개발자 입장에선 HW가 끝나고 나야 개발에 착수 가능하고 구조를 알고 있어야함

이 Level에선 OTA해봐야 이식성이 없음(HW 구조와 존재가 다 다르기 때문에)

  1. SDV oriented Architecture

상위 제어기인 Zonal Control Unit(ZCU) 밑에 ECU들을 둠 (하위 ECU들은 표준화 안됨)
HPC(Vehicle Computer)를 두고 거기서 AVN/ADAS/자율 주행등을 수행

HPC <-> Gateway(CGW/CCU) <-> ZCU <-> ECUs 구조로 표준화되어 OTA 용이
HPC가 중앙 제어하는 구조로 여기가 Server랑 연결

차량 SW 증가 및 SDV 전환의 효과적 대응이 필요하고 그게 OTA
(Update 빈번/많은 ECU, SW/Recall 대응/유럽 수출 필수 등...)

  1. 자율 주행 :
    다양한 Factor Upgrade하여 주행 능력과 보조 기능 지속 Upgrade가 필수임
    차량간 SW Version이 같아야 서로 소통하며 V2V 자율주행 관리 가능

  2. 빅데이터 :
    주행 중 어떤 문제가 많이 발생하는지 업데이트를 통해 실시간 수집 가능
    수집된 데이터들을 통해
    "차선 변경 이후 옆 차 인식 속도 문제" 등을 분석 가능
    OTA 덕분에 주행 전/중/후 시간 대 별로 민감한 기술 이슈 실시간 파악 가능
    이는 곧 자율주행을 더 완벽/안전/편리하게 완성시킬 수 있게함

  3. OEM과 고객의 시간/비용/노력 절감

OTA 절차

  1. OEM/Tier-1 :
    Romdata(binary) + Reprogramming Config(표준 없음) = Pacakge

  2. OTA Server :
    Package를 받고 Vehicle로 전송

  3. Vehicle :
    Request를 보내고 Response를 받는 Clinet로 동작(특정 지역에서)
    있다면, HPC(혹 CGW)에 Download하고 unzip+무결성 검증후 ZCU로 전송
    ZCU는 Target Ecu에 UDS 리프로그래밍
    ISO 24089의 SW update 표준

다만 이 방식은 망 사용료 관련 문제와 (Request 주기)
DDOS에 취약하기에 Client-Server으로 사용하지않음

그래서 Publish-Subscribe 구조로 사용됨(MQTT를 주로 사용하나 표준은 아님)

Target ECU에 줄 Parsing Logic이 다 다르다.

  • OTA Server :
    VIN 및 ECU 버전 기반 OTA 실행 판단
    제어기 ROM data 및 진단법규 Data 저장
    Download Manager Master

  • DCU(Modem) :
    Server와 무선 통신 수행(3A등 인증 필요)

  • Master ECU(CGW=CCU) :
    Download Manager Client 및 OTA Master 포함
    Version check / 무선 Download / Reprogramming 수행
    ROM file 관리 / OTA 우선순위 판단 등

  • Target ECU :
    Reprogramming을 수행하는 로직. OTA Slave
    CGW_CCU의 Reprogramming 명령에 따라 ECU내 Code/Data 영역 삭제하고
    수신한 ROM file을 write

좀 더 상세히

  1. Cloud Service에서 OTA Master로 update file 전송(보안)

  2. Security Key 확인 후, OTA Master에 Update SW 저장
    Key는 EVITA 정의 HSM Full level에 의해 해킹에 대한 보안 강화 대한 보안 강화

  3. 정지 상태에서 OTA Slave로 전송

  4. Update Data를 Flash에 write. 이후 reset시 동작

  • Booting(시동)시 A/B Swap하거나 In-Place로 하는데 안전관점에서 A/B Swap을 많이 채택(롤백)
    복잡하고 메모리도 두배로 드는 기법
    Boot Sequence가 Root of Trust기때문에 (Boot loader의 롤백/검증/부팅 위치 판단 등)
    Bootloader가 뚫리면 이상한 Image를 받거나 다운그레이드 시키는 등 문제점 발생
    그래서 부팅마다 엄격히 검증을 해야한다.

  • In-Place의 경우 싸고 생명에 지장없는 경우에 여전히 채택해서 사용중이고
    Update할 때만 위험함

OTA가 외부 File을 설치하는 것이기에 Attack Surface와 Entry Point를 열어주는 격이다
기존엔 OBD 단자등 물리적인 접근만 가능했으나, 이젠 전기차 충전기로도 주입이 가능함

HKMC는 벤더사들과 함께 모든 Module에 대한 보안 검증을 거쳐야함
이에 다른 벤더사들과 함께 OTA 관련 보안 검증을 다 거친 다음 진행 가능하여
벤더사별 ECU에 한 번에 시스템을 맞추는 것은 시간이 오래 걸릴 수 밖에 없음

기술은 쉽지만, 차에 적용하기 어려운 것은 이런 Chain 구조 때문
(OTA를 어디에/ 통신 모듈은 어디에/ 누구 주관으로 인터페이스를 맞추고/ 누가 업데이트를?)

일반적으로 통신 모듈은 AP에 포함되어 출시(AVN은 OTA 이루어지고 있는 이유)
FOTA까지 가려면 책임주체나 고민이 많음

여하튼 E/E를 완전히 탈피해야해서 시작/유지 비용도 많이들고 쉽진않다.

SDV와 OTA

  • SDV : SW 중심 구동되는 수단으로 SW가 주체가 되어야 함
    HW가 Spec을 결정하지 않고 SW가 Spec을 결정할 수 있는 SW 중심 성능 필요
    즉, 동일 HW에서 SW가 영향을 지대히 줄 수 있는 차량 아키텍쳐

이에 따라 Agile을 통한 지속 SW 개발 주도 및 OTA를 통한 SW upgrade

가장 중요한 것은 차량 내 보안 SW로 사이버 공격을 탐지/방어해야 하며
시스템 내 개별 구성 요소만 보호하는 것이 아닌, 차량 전체 시스템 보호 필요

벤더사들도 이 흐름에 같이 타줘야 발전이 가능함

  • 사실 OTA가 곧 SDV나 다름이 없다

SDV는 제품 수명주기 동안 OTA를 통한 성능/기능 개선 및 추가와 서비스를 제공해

  1. 고객에게 지속적으로 새 경험 가치를
  2. OEM에게 부가 가치 창출과 개발 자원 절약/데이터 활용을
  3. 벤더사에게는 HW규모의 경제와 SW의 부가가치를 창출하는
  4. IT/SP에게 APP또는 생태계를 확장할 수 있는

자동차 수명 주기가 연장되고 SOP 이후에도 성능향상이 가능한 것이 정의인데
이는 OTA로 인해 발생하기 때문

  • ECU 통합화(ZCU) 및 중앙화(HPC) E/E Architecture 기반
  • HW-SW 디커플링으로 HW몰라도 빠른 개발 가능 및 새로운 서비스/기능 제공
  • SW Platform/Cloud Service로 차량 기능 확장 및 다양화
  • OTA를 통한 차량 수명 주기와 성능 증대

즉 디커플링(표준화) / 추상화 등 일반 서비스SW에서 쓰듯 바꾸는 것

기존 방식의 분산 E/E는 기능 추가시 DCU만 늘고, 이에 따라 하네스 늘고,
부품 연동을 위한 HW/SW 복잡도와 유지도 올라가고
유연성 없어서 확장도 못하고 안좋은 반면

SDV는 여러 DCU를 하나의 ZCU로 대체하기에 복잡도/하네스/확장성/표준화 모든 것을 가져올 수 있음(중앙집중형 E/E)

OTA 관련 표준

  • UNR.155(보안 규제) -> CSMS 표준

  • UNR.156(SW Update 규제) -> SUMS 표준

의 법규(반드시 지켜야 하는 것)이 있음

차량 별 형식승인(VTA)을 받아야하고
차량 형식에 법규 별 SW ID, Update 보안 및 OTA 기능 요건 반영 필요
제조사도 결국 UNR.156을 획득해야 됨조사도 결국 UNR.156을 획득해야 됨

즉 UNECE의 WP(Working Point) 29에서 Regulation을 제정했고
거기에 빛/가스/에너지도 있지만 Automated Vehicle내에 Cyber security와 OTA TF가 존재함

  • Regulation(반드시 지켜야 함) : 1초 이내 들어와야 한다.

  • ISO 표준(어떻게 지켜야 할까?) : "HOW TO 달성/평가" 대한 것으로 꼭 지킬 필요는 없음.
    해당 Regulation을 위한 Guide이기에 조직내에서 맘대로 해도되긴함

CSMS/SUMS 인증을 받아야 VAT를 받고 차를 팔 수가 있음
3년간 유효하고 각 차량 타입마다 다 필요함

단 이들의 경우 프로세스만 평가하는게 아니라
그대로 했다는 구현결과와 검증 증거까지 반드시 요구함

profile
CS
학습
다음 포스트

[OTA] OTA Process

0개의 댓글