ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • UDS 진단 통신으로 하는 소프트웨어 업데이트 1 - 작업 개요
    카테고리 없음 2025. 2. 26. 14:42

    시작하기 전에

    진단 통신은 제어기 소프트웨어 업데이트에도 활용될 수 있다. UDS 표준이 만들어진 시기에는 프로그래밍이라고 불렀다. 요즘은 소프트웨어 업데이트가 더 흔하게 사용된다. 여기서는 문맥에 따라 소프트웨어 업데이트와 프로그래밍을 혼용한다.

    TSMaster의 UDS Diagnostic 모듈을 이용하여 프로그래밍 하는 방법을 설명한다.

     

    Secure Boot :: hsl's tsmaster 사용기에서 설명한 제어기 플래시 메모리의 구조, 부트로더 개념에 대한 이해가 다음 이야기의 이해에 도움이 될 것으로 생각한다. 

     

     

    개요

    제어기 소프트웨어 업데이트는 대략 아래의 절차로 이뤄진다.

    • 소프트웨어 업데이트 중에 다른 통신에 방해를 받지 않도록 하기 위해서 모든 제어기들에게 CAN 송신 중지를 요청한다. 모든 제어기에 요청하므로 펑셔널 어드레스로 요청한다. (펑셔널 어드레스는 UDS 진단 통신 (2 / 4) - Transport Protocol 설정 :: hsl's tsmaster 사용기 에서 설명을 했다.) CAN 송신 중지 요청은 일반적이지 않기에 먼저 제어기들의 모드를 (확장) 진단 모드로 변경해야 한다. 따라서 CAN 송신 중지 요청 전에 진단 모드 진입 요청을 한다. 모든 제어기가 진단 모드 진입 요청을 해야 하니까 이것도 펑셔널 어드레스로 한다. 아래 그림에서 [Fn]은 펑셔널 어드레스를 표시한다.

    프로그래밍 시작 전에 전체 제어기들의 일반 CAN 통신을 정지한다.

     

    • 그렇게 해서 CAN 버스가 조용해지면 진단기와 소프트웨어 업데이트 대상 제어기 (이하 제어기)는 프로그래밍에 필요한 통신을 한다. 미리 정한 프로그래밍 모드로 전환한다. 접근 제어를 위해 보안 접속 (Security Access)를 한다. 보안 접속을 위한 다양한 방법들이 있다. 시드 & 키 (Seed & Key) 방식이 흔히 적용된다. 진단기는 제어기에 시드를 요청한다. 제어기는 임의의 수인 시드를 생성하여 진단기에 전송한다. 진단기는 수신한 시드와 미리 정한 알고리즘으로 키를 계산하고, 키를 제어기에 전송한다. 제어기도 시드와 알고리즘으로 키를 계산하여 수신한 키와 동일한지 확인한다. 동일하면 이후 진단기의 프로그래밍 요청에 응답한다.  

    보안 접속. 시드 & 키 검증 과정

     

    • 진단기는 제어기에 소프트웨어를 쓸 플래시 메모리 영역의 삭제를 요청한다. 프로그래밍 준비를 요청 하고 (소프트웨어를 쓸 블록의 주소와 크기를 전달한다.) 데이터 전송을 시작한다. 데이터는 CAN 메시지 하나에 다 넣을 수 없을 정도로 크다. TP(Transport Protocol. UDS 진단 통신 (1 / 4) - Transport Protocol, UDS의 개요 :: hsl's tsmaster 사용기에서 설명하였다.)가 적용된다. 모든 데이터가 전송된 후 데이터 전송을 마친다.
    • 프로그래밍 후에 소프트웨어 번호, 프로그래밍 날짜, 프로그래밍을 한 정비소나 정비사 등 메타 정보를 제어기에 기록한다. 나중에 추적이 필요할 때를 대비해서다. 여기에서는 소프트웨어 번호만 기록하는 것으로 가정한다.

    소프트웨어를 전송한다.

     

    • 차 안이 모든 제어기가 다시 정상 작동하도록 제어기 리셋을 펑셔널 어드레스로 요청한다.
    • 한 제어기의 소프트웨어를 업데이트하면 그 제어기와 통신을 하는 제어기들에 영향이 없는 지를 확인해야 한다. 그래서 정비사는 차의 이그니션 전원을 껐다가 다시 켠다. (바로 위 펑셔널 어드레스로 요청한 제어기 리셋이 잘 작동하면이 과정은 필요하지 않을 것이다.) 그리고 제어기들의 진단 코드와 메타 정보 등을 읽어서 소프트웨어 업데이트가 잘 되었는지 확인한다. 

    제어기 리셋 후 소프트웨어 번호  확인으로 업데이트  성공을 확인한다.

     

    • OTA(Over The Air) 소프트웨어 업데이트가 적용된 차는 정비사가 하는 작업을 차 안에 있는 소프트웨어 업데이트 매니저 제어기가 한다. 소프트웨어 업데이트 매니저 제어기가 제어기들에게 공급되는 전원을 켜고 끌 수 있도록 차가 설계/제작 되어야 한다.
    • 위 전체 절차를 순서도로 표현하면 아래와 같다. [Fn]: 펑셔널 어드레스 요청, [P]: 피지컬 어드레스 요청 
    • 위 절차에 있는 서비스들을 정의하고 서비스들을 연결하여 프로그래밍 절차를 만드는 방법을 살펴본다.

     

     

    모드 변경 (0x10: Diagnostic Session Control)

    • 개요에서 설명한 것처럼 제어기는 진단 모드, 프로그래밍 모드 같이 상태에 따른 모드들을 갖고 있다. 모드 대신 세션이라고도 부른다. (모드와 세션에 의미적 차이가 있는 것 같은데 내가 그 차이를 구분할 지 모른다. 모드와 세션을 혼용한다.) 모드를 바꾸는 것을 세션 제어 (Session Control)라고 한다. 표준 (진단) 모드 (Standard Diagnostic Mode/Session), (확장) 진단 모드 (Extended Diagnostic Mode/Session), 프로그래밍 모드 (Programming Mode/Session) 등이 널리 알려진 모드이다.
    • UDS 표준에 정해진 session control 요청의 서비스 Id 0x10이다. 모드별로 정해진 DiagnosticSessionType이라는 파라미터가 있다. (예를 들어 진단 모드의 파라미터는 0x03이다.) 진단 모드 진입을 위한 session control 요청은 0x10 0x03 이렇게 된다. 이를 TSMaster의 Disgnostic 창에서 설정하자면 아래와 같다. 
    • 메인 메뉴/ Application/ Disgnostic Module 버튼을 클릭하여 Diagnostic 창을 연다.
    • Basic Diagnostic Config 탭을 클릭한다. 
    • 왼쪽에 UDS 표준의 서비스들이 나열된 트리 영역에서 DiagnosticSessionControl 항목을 선택하고 마우스 우클릭하여 Add New Service를 선택한다. 그리고 아래 그림과 같이 입력한다.
    • 입력하는 상세 과정은 UDS 진단 통신 (3 / 4) - 진단 요청/ 응답 메시지 설정 :: hsl's tsmaster 사용기에서 설명하였다.
    • Session control 요청에는 DiagnosticSessionType을 위한 파라미터 외에 다른 파라미터가 없다고 가정했다. 그래서 요청 메시지는 "10 03"으로 끝나는 것으로 정의했다.

    session control에 Extended Diag Session을 정의한다. Diagnostic 창에서 Basic Diagnostic Config 탭을 선택하고 왼쪽 UDS 서비스 트리에서 DiagnosticSessionControl을 선택하여 Extnd Diag Session을 정의한다.

    • 응답은 "50 03" 외에 4 바이트 파라미터가 추가로 있는 것으로 정의했다. 나는 UDS Simulator라는 것을 이용해서 진단 통신을 시뮬레이션 할 것이다. 이 시뮬레이터가 session control 요청에 4 바이트 파라미터를 회신한다.  
    • 전체 제어기를 대상으로 진단 모드 진입을 요청할 것이라 Is Function ID에 체크를 했다.
    • DiagnostionSessionType은 아래 그림의 마우스 화살표가 있는 부분의 '...' 버튼을 클릭하면 Select Sub Function ID 창이 뜬다. 이 창에서 UDS 표준에 정해진 세션 타입을 선택할 수 있다.  

    • 같은 방법으로 프로그래밍 모드(0x02)와 표준 모드 (0x01, DefaultSession)을 정의하였다.
    • 표준 모드 진입은 전체 제어기를 대상으로 하기에 Is Function ID에 체크를 했지만, 프로그래밍 모드는 특정 제어기만 대상으로 하기에 Is Function ID를 체크하지 않았다. 

     

     

    CAN 통신 중지 (0x28: Communication Control)

    • 소프트웨어 업데이트를 위한 통신이 진행되는 동안 전체 제어기의 일반 CAN 통신을 정지시킨다. 이런 통신 제어는 Communication Control 서비스에 속한다. 
    • UDS 표준에 Communication Control 서비스의 아이디는 0x28로 정해져 있다. 요청은 "0x28 ControlType" 형식이 된다.
    • 아래 그림과 같이 서비스를 추가 정의하였다. 
      • ControlType 파라미터 입력 칸에서 오른쪽 끝에 '...' 버튼을 클릭하면 UDS에서 정한 ControlType 파라미터들을 볼 수 있다. Rx는 켜고, Tx는 끌 것이라서 ControlType으로 0x01을 선택한다. 
      • 전체 제어기들을 대상으로 하므로 펑셔널 어드레스 요청을 한다.

    CommunicationControl에서 Stop CAN Tx를 정의한다.
    ControlType 칸의 오른쪽 끝 '...' 버튼을 클릭하여 뜬 창에서 ControlType을 선택한다.

     

    블로그를 작성 중에 그림이 보이지 않는 오류가 발생한다. 글이 통째로 날라가는 일을 방지하기 위해 여기에서 설명을 마무리 한다. 보안 접속(Security Access)은 다음 글에서 설명한다. UDS 진단 통신으로 하는 소프트웨어 업데이트 2 - 보안 접속 :: hsl's tsmaster 사용기

     

     

    목차 :: hsl's tsmaster 사용기