UDS (Unified Diagnostic Service) 프로토콜을 이용한 차량 진단 및 Reprogramming
자율주행 기술이 고도화되면서 차량 내 ECU의 개수는 물론,
개별 ECU에 올라가는 프로그램 코드의 양과 복잡도 또한 증가하고 있습니다.
프로그램의 양이 많아지고 복잡해질수록 계획 단계에서 생각하지 못한 오류들이 발생하게 됩니다.
스마트폰 같은 전자기기에서는 이러한 오류 개선을 위한 업데이트가 당연하게 여겨지고 있지만,
사실상 차량용 ECU 또한 이러한 업데이트가 필요합니다.
특히, AUTOSAR가 본격적으로 적용되면서 SW 업데이트에 대한 필요성은 증대되었고, 이에 대한 대비도 필수가 되었습니다.
이 글에서는 차량용 진단 프로토콜로 범용화되어있는 UDS(Unified Diagnostic Service) 프로토콜이
SW 업데이트에 적용되는 방식과 해당 기능이 FBL에서 사용되는 방식
을 간략하게 알아보겠습니다.
차량 진단 프로토콜
차량은 고장이나 사고 등 많은 위험이 따르는 교통수단이기 때문에
이를 방지하기 위해서 반드시 수명주기 동안 차량 상태를 모니터링해야 합니다.
차량에 탑재된 장치로부터 진단 장비로 진단 데이터를 가져오기 위해서는 특별한 진단 프로토콜을 사용해야 하는데,
일반적으로 많이 사용하는 프로토콜이 XCP, OBD, UDS입니다.
- UDS (Unified Diagnostic Service) 프로토콜
> 진단에 중점, 일반적으로 차량 오작동 진단을 목적으로 offline 진단에 사용됨
- OBD (On-board Diagnostics) 프로토콜
> 진단에 중점, on board ECU 자가 진단 서비스가 주요 목적
- XCP (Universal measuremnet and Calibration Protocal
> 주로 진단 데이터 교환을 위해 on board ECU 들을 연결해 주는 확장 가능한 네트워크 생성을 지원
> low bandwidth delay나 real-time fault analysis 가 요구되는 on bard 진단 시스템에 사용됨
UDS 프로토콜
Unified Diagnostic Services 는 ECU 진단 및 Reprogramming 시 사용할 수 있는 차량용 프로토콜로,
다양한 ECU를 지원하고 특정 국가 및 제조사에 의존적이지 않습니다.
네 개의 계층 모델을 기반으로 하며, OSI 네트워크 모델과 비슷하고 사실상 표준으로 취급되고 있기 때문에
대부분의 Automotive 제조사에서 개발 과정뿐 아니라 차량 AS시에도 사용하고 있습니다.
AUTOSAR 표준에 따르면 UDS는 ECU reprogramming을 bootloarder에 구현할 때 가장 적합한 프로토콜로 생각할 수 있습니다.
적용 예시
1. 오작동 진단
UDS 프로토콜의 주요 사용처 중 하나는 진단 입니다. 차량에 문제가 생겼을 때
FCM (Fault Code Memory)에 DTC (Diagnostic Trouble Code)가 저장되는데,
이 정보를 가져오기 위해서 ReadDTCInformation 같은 UDS 명령어가 사용됩니다.
2. ECU Reprogramming
SW 업데이트 기능에 적용되는데, 오작동을 일으키는 부분을 업데이트하거나 ECU에 새로운 기능을 추가하기 위해서 사용됩니다.
3. Remote routine activation
다른 시스템 테스트를 시작하거나 입력 파라미터 값들의 오작동 여부에 대한 검사를 동시에 해야하는 경우,
UDS 프로토콜의 Remote Rountine Activation 서비스가 사용될 수 있습니다.
4. Data Exchange
UDS 프로토콜을 사용해서 ECU상의 ECU 시리얼 번호 같은 Static data 혹은 현재의 센서 값 같은 dynamic data를 읽어올 수 있습니다.
ECU Reprogramming 에서 사용되는 UDS의 주요 기능
> UDS에 의해서 server 쪽이 reprogramming mode로 변경되고 reprogramming 시퀀스가 시작
> Data 전송의 시작/종료를 핸들링
> UDS는 주고받을 data block의 크기와 순서 그리고 data가 저장될 메모리 block을 관리
> Client는 UDS 서비스를 통해서 서버에서 실행되는 루틴을 시작하고 멈춤
> Client는 UDS 서비스를 통해서 서버의 SW reset을 실행
FBL (Flash BootLoader)
ECU에 업데이트된 SW 및 보안 패치를 적용해야 하는 경우,
FBL이 제공하는 Reprogramming 기능을 사용할 수 있습니다.
일반적으로 FBL SW의 구조는 그림과 같습니다.
통신 프로토콜, UDS, Flash Driver와 같은 Reprogramming을 위한 기능이 포함되어 있음을 확인할 수 있고,
상황에 따라 SW 업데이트를 진행하거나 혹은 어플리케이션을 로딩하는 역할을 합니다.
FBL을 사용한 펌웨어 업데이트
FBL 시스템 부팅 시 가장 처음 활성화되는 SW 모듈입니다.
업데이트를 처리하기 위한 루틴이 존재하고, 업데이트 시 CRC check나 seedkey check와 같은 내부 인증 절차를 거치는데,
시스템에 사전 정의된 방식으로 업데이트 바이너리를 검사하고,
확인된 문제가 없다면 Flash 메모리에 업데이트 버전을 복사하게 됩니다.
Flash 메모리에 쓰기가 끝나면 다시 한번 기록한 바이너리의 정합성 및 동일성 검사를 하고,
이상이 발견되지 않으면 FBL에서 어플리케이션으로 제어가 넘어가게 됩니다.
Reprogramming 관련 FBL 프로세스는 2단계로 구분할 수 있는데,
때로는 명시적으로 별도의 처리 기능별 FBL로 나누어 구현하기도 합니다.
1단계 : MCU 초기화
MCU 리셋 후 FBL의 1단계를 거쳐 MCU가 초기화되면서 시스템을 사용하기 위한 준비를 합니다.
CAN을 사용하는 FBL인 경우, CAN 프로토콜이나 CAN Controller가 SW 업데이트를 할 수 있도록 초기화됩니다.
1단계에서는 어플리케이션으로 제어가 넘어가거나 혹은 Reprogramming으로 진입해도
필요한 대응이 가능하도록 MCU 초기화가 진행됩니다.
업데이트가 존재할 경우 (혹은 통신 채널을 통해서 업데이트 프로세스로 진입하도록 요청된 경우)
Reprogramming 프로세스로 진입하고, 아니면 어플리케이션 시작 위치로 점프하면서
제어가 어플리케이션으로 넘어갑니다.
2단계 : Reprogramming
연결된 통신채널로 펌웨어 업데이트 요청이 있을 때 활성화되어 어플리케이션 소프트웨어 업데이트를 진행합니다.
일반적으로 2단계에서는 제어기의 펌웨어를 다운로드 받아서 Flash 메모리에 Reprogramming 하는 기능을 수행합니다.
FBL에는 Flash 메모리에 펌웨어를 업데이트하기 위해 필요한 flash 루틴 및 UDS 함수들이 포함되어 있습니다.
FBL은 UDS 서버 역할을 하며 업데이트를 요청한 UDS client SW와 UDS 명령어 및 응답을 주고 받으며
re-programming을 수행하게 됩니다.
일반적인 진행과정을 간단히 설명하면 아래의 그림과 같습니다.
1. ECU 하드웨어 ID와 소프트웨어 ID를 읽고 올바른 장치인지 확인
2. UDS 고급 서비스를 사용할 수 있는 확장된 진단 세션으로 전환
3. Routine control을 사용해서 Reprogramming을 위한 체크사항 확인
4. DTC를 OFF로 설정
5. 진단이 아닌 다른 컨트롤러의 버스 통신을 OFF
6. Programming Session으로 전환
7. Server에 Seed를 요청해서 받은 Seed로 계산된 Key 값을 서버로 전달
8. 누가 ECU 메모리 프로그래밍을 했는지에 대한 정보 기록
9. Flash programming을 위해서 메모리 삭제
10. Reprogramming 작업 시작 요청(데이터의 크기나 메모리 정보에 대한 알림)
11. 블록 단위로 바이너리 다운로드
12. 바이너리 전송이 종료되었음을 알림
13. 전송된 데이터를 검사하고 Reprogramming이 성공했는지 확인
14. ECU를 재부팅
15. 버스 통신을 정상화시킴
16. DTC를 ON으로 설정
17. ECU가 재부팅되고 정상 작동되기 때문에 기본 진단 세션으로 복귀
지금까지 UDS 프로토콜이 적용된 FBL에서 소프트웨어 업데이트를 위한 Reprogramming에 대해서 간략히 살펴보았습니다.
앞서 언급한 소프트웨어 업데이트를 위해 필요한 FBL 및 UDS Server/Client 기능을 직접 구현하기 위해서는
많은 시행착오가 필요하고, 많은 시간 소요가 예상되기 때문에 특별한 경우가 아니라면 직접 구현은 권장하지 않습니다.
최근에는 FBL 및 업데이트 기능이 개발 플랫폼에 구현된 기능의 일부로 제공되는 경우가 많은데,
여기서 제공되는 모듈에 필요한 설정을 적용하여 사용하는 것이 시간과 비용을 아끼고
더 안전한 시스템을 구축하는데 도움이 될 것 입니다.
