hsl's tsmaster 사용기 hsl's tsmaster 사용기

개요SecOC의 작동을 데모하기 위해 TSMaster 미니프로그램을 짠다. 데모의 구성은 아래 그림과 같다.PC에서 TSMaster를 2개 연다. 한 쪽은 센더, 다른 쪽은 리시버 역할을 한다.센더는 메시지에 MAC을 부착하여 전송한다.리시버는 메시지의 MAC을 검사한다.필요한 경우 FV 값을 변경할 수 있다.  PC에서 TSMaster를 2개 열어 사용하기TSMaster가 이미 열려있는 상태에서 설명한다.TSMaster 아이콘에서 마우스 우클릭을 하여 팝-업 메뉴를 띄운다. 메뉴에서 TSMaster를 선택한다. 두 번째 TSMaster가 시작된다. 중간에 TSMaster가 이미 실행 중이라는 안내가 나온다.  양쪽 TSMaster 모두 메인 메뉴/ Hardware/ Channel Selection 버튼..

시작하기 전에 SecOC에 관한 글을 작성한다. 아래 내용들을 포함한다.SecOC가 무엇인가?왜 CRC는 사용하지 않는가?SecOC 구현  SecOC는 무엇인가?SecOC는 Secure On-board Communication을 줄임말이다.On-board는 "차량 내"라는 의미이다. "차량 내 통신 보안" 정도로 해석할 수 있다.AUTOSAR에서 발표한 통신 보안을 위한 사양이다.AUTOSAR는 AUTomotive Open System ARchitecture의 줄임말이다. 문맥에 따라 아키텍처, OS를 혹은 AUTOSAR 기구(organization)를 의미한다.AUTOSAR (Automotive Open System Architecture)  다양한 통신 프로토콜에 적용 가능하다고 한다. 나는 CAN(..

Reverse Engineer CRC목적CRC를 리버스 엔지니어링하는 것이 어렵지 않다는 것을 보여준다.개요데이터 준비데이터 길이가 16 바이트인 CAN 메시지를 가정한다.시작 바이트는 0번이다.0번 부터 10번 바이트까지를 랜덤 바이트로 채운다.11번 바이트에는 alive counter를 넣는다.12번 부터 15번 바이트까지는 4 바이트 CRC로 채운다.왜 4 바이트 CRC인가?AUTOSAR CRC는 1 바이트이거나 4 바이트이다.1 바이트는 4 바이트보다 상대적으로 CRC 알고리즘을 찾는 리버스 엔지니어링이 쉬울 것 같다. (실제 그런지 모르겠다.) 일부러 어려워 보이는 4 바이트를 선택한다. 어려워도 리버스 엔지니어링 된다는 것을 보여주려는 목적이다실험용 메시지 n_message개를를 생성한다.CR..

시작하기 전에 요즘 절대 다수의 차량 제어기들은 통신을 한다. 이들 중 상당수는 다른 제어기이 보내는 CAN 메시지들을 수신해야 정상 작동 상태가 된다. CAN 메시지들을 공급하는 방법은 크게 두 가지다. 실제 다른 제어기들과 CAN 버스를 직접 연결하는 방법,  CAN 버스 통신을 모사(시뮬레이션) 해주는 방법. 전자는 현실적으로 여러가지 어려움이 있다. 후자를 RBS (Remaining/Rest Bus Simulation)이라고 한다. TSMaster GUI에서 TSMaster가 제공하는 기능들을 조작하여 RBS 하는 방법을 CAN 버스 시뮬레이션 (RBS: Remaining Bus Simulation) :: hsl's tsmaster 사용기, 트레이스를 이용한 RBS(Remaining Bus Sim..

mobis esc readDID scan blfmobis esc를 대상으로 DID(Data IDentifier)를 0x0000부터 0xFFFF까지 변경하며 readDID 요청을 하는 DID 스캐닝을 하였다.DID 스캐닝을 하며 측정한 CAN 버스 트레이스(blf) 파일을 분석하여 긍정 응답을 받은 DID를 추출한다.import osfrom pathlib import Pathimport canimport pandas as pdldf is not supportedxls is not supportedxlsx is not supported# constant# parse_resp()에서 사용되는 고정값들을 정의한다.# 긍정 응답은 진단 요청에 0x40을 더한 값으로 시작한다.k_offset_positive_res..

시작하기 전에 진단 응답 해석하기 :: hsl's tsmaster 사용기 에서 Read ECU ID, Read DTC, Read Software Version, Tester Present 요청으로 진단 통신의 m_id (0x700 ~ 0x7FF)를 스캐닝해보았다. Read ECU ID 요청의 응답은 유용했다. Read DTC나 Read Software Version 요청들의 응답은 유용하지 못했다. 서비스 요청의 파라미터가 제어기들이 지원하지 않는 것이기 때문일 수 있다고 생각한다. 그렇다면 "제어기들이 지원하는 파라미터는 어떤 것들일까?" 하는 의문이 생겼다. m_id를 스캐닝한 것처럼 파라미터를 스캐닝해볼 수 있다.  UDS에 정의되어 있는 모든 서비스들을 대상으로 파라미터를 찾는 것은 데모로는 과하..

venue_parse_diag_resp_blf차(베뉴)에서 측정한 CAN 트레이스(blf 파일)를 분석한다.진단 응답 (DTC: Diagnostic Trouble Code)을 해석한다.DTC 설명은 현대차의 DTC(Diagnostic Trouble Code) 설명을 찾는 방법 :: hsl's tsmaster 사용기에서 구한 DTC 설명을 사용하였다.import osfrom pathlib import Pathimport can # blf 파일 처리를 위해 python-can 모듈을 사용한다.import pandas as pdldf is not supportedxls is not supportedxlsx is not supported# 측정한 blf 파일들k_dir_data = Path().absolute..

venue_uds_match_diag_req_resp_m_id_blf차(베뉴)에서 측정한 CAN 트레이스 (blf 파일)을 분석한다.진단 요청과 응답 메시지 아이디들의 짝을 찾는다.표준에 따르면 진단 메시지의 아이디(m_id)는 0x700에서 0x7FF로 정해져있다.표준에 Read ECU ID, Read DTC 등 몇몇 서비스는 대부분의 제어기들이 응답한다.위 두 가지 사실에서 착안하여 m_id를 0x700에서 0x7FF까지 순차적으로 증가시키면서 (스캐닝) Read ECU ID, Read DTC 등의 서비스를 요청한 후, 0x700번대 응답 메시지를 500msec(응답 대기 시간) 동안 기다린다.응답이 있으면 그 메시지의 m_id를 요청 메시지 m_id와 짝으로 판정한다.import osfrom pat..

시작하기 전에 CAN 통신 데이터를 수집하고, 수집한 데이터에서 메시지 아이디들을 찾고, 찾은 메시지 아이디들을 dbc에서 찾는 방식으로 차에 어떤 제어기들이 있는 지 확인할 수 있다. (dbc에서 m_id들을 찾기 :: hsl's tsmaster 사용기) 이는 차량 형상 관리를 위한 최소한의 점검이다. 이 점검을 통해서 차에 있는 제이기들과 빠진 제어기들을 확인할 수 있다. 제어기들의 하드웨어와 소프트웨어가 설계 사양에 맞는지까지 확인하기는 쉽지 않다. 필요가 있으면 발명이 있다.UDS 서비스 중에 Read Data By Identifier라는 것이 있다. 자동차사들은 진단 통신 사양서에 이 서비스를 명시한다. 그래서 제어기의 하드웨어, 소프트웨어 정보를 읽도록 한다. Read Data By Ident..

dbc에서 m_id들을 찾기목적: 차량 형상 관리 관점에서 설계 사양 (dbc)과 실차의 형상(m_id_info)을 비교한다.m_id_info는 blf 파일에서 m_id, dlc, d_ts 추출하기 :: hsl's tsmaster 사용기에서 측정한 CAN 통신 데이터를 분석한 결과이다. 메시지 아이디(m_id)별로 메시지 길이(dlc), 메지지 전송 주기(d_ts) 정보를 갖고 있다.  dbc 파일에서 m_id_info의 m_id들을 찾는다.찾아야할 m_id들은 ~mid_info.xlsx에 저장되어 있다.cantools라는 Python 모듈을 이용하여 dbc의 내용을 읽는다.찾기와 비교를 쉽게 하기 위해서 pandas라는 Python 모듈을 이용한다.xlsx의 내용을 df_car라는 dataframe(d..