차량 형상 점검

시작하기 전에 

 

새 차를 개발할 때 시작차(Prototype)를 만든다. 시작차는 기존 차(들)에서 시스템들을 가져다 만든다. (이를 캐리-오버라고 부른다.) 내가 말하는 시스템은 제어기, 센서, 액추에이터로 구성된다. 센서나 액추에이터는 단순 부품일 수도 혹은 그 자체가 하나의 시스템일 수도 있다. (전통적으로 시스템은 차 안에 있었지만 커넥티비티의 발전으로 요즘 시스템은 차 밖에 있을 수도 있다.) 시스템들은 "통신"을 통하여 개별 시스템은 할 수 없는 기능을 구현한다. 소위, 협조 제어 (coordinated control)라고 한다.

캐리-오버한 시스템들로 시작차 조립을 한 후 곧바로 모든 시스템 기능들이 정상 동작하는 경우를 나는 겪어보지 못했다. 거기에는 여러 가지 원인들이 있다. 이 들 중에 하나는 시스템들 사이의 호환성 불일치 문제이다. 이 문제 해결을 위해

• 호환성 문제와 관련된 시스템들은 어떤 것들인지
• 각 시스템의 하드웨어 버전과 소프트웨어 버전은 무엇인지
• 위 정보는 설계 사양과 일치 하는지를

확인해야 한다. 이런 류의 이슈 관리를 총칭하여 형상 관리라고 한다. 

 

차에는 수 십개의 시스템들이 있다. 선택에 따라 다양한 형상이 존재한다. 선택이 하나 증가하면 가능한 형상은 두배로 증가한다. 이론적으로는. 도구 없이 차량 형상 관리를 하는 것은 무모하다.

 

통신을 모니터링하여 설치된 시스템들을 확인할 수 있다. 진단 통신으로 제어기별 하드웨어/소프트웨어 버전을 확인할 수 있다. 이렇게 실제 차량의 형상 정보를 수집할 수 있다. 수집된 차량 형상 정보를 설계 사양과 비교하면 시스템별로 문제 유무를 확인할 수 있다. CAN 통신 모니터링을 통해 차량 형상 정보 수집 방법 개발을 시도한다. 

 

 

개요

아래와 같이 해볼 것이다.

• 차량 통신 데이터 분석을 통해 시스템 확인하기
  • 실차 CAN 버스 메시지 분석하기
  • 실차 CAN 버스 메시지와 dbc를 비교하기
• 진단 통신으로 제어기 확인하기
  • 진단 요청과 응답 CAN 메시지 아이디 짝 찾기
  • 진단 응답 해석하기

 

 

차량 통신 데이터 분석을 통한 시스템 확인

실차 CAN 버스 메시지 분석

• blf 파일에서 m_id, dlc, d_ts 추출하기 :: hsl's tsmaster 사용기
  • CAN 버스 데이터를 blf 파일로 저장한다. 파일 안에 있는 메시지들의 아이디 (m_id), 메시지별 데이터 길이 (dlc)와 전송 주기 (d_ts. difference of timestamp between consecutive messages)를 구한다. 이를 메시지 정보 (m_info)라고 부르겠다. m_info를 표 형태로 xlsx에 저장한다.

실차 CAN 버스 메시지와 dbc를 비교하기

• dbc에서 m_id들을 찾기 :: hsl's tsmaster 사용기
  • dbc의 정보와 실차 CAN 버스에서 구한 m_info 정보를 비교하는 것은 설계 사양과 실차 형상을 비교한다는 의미이다.
  • 비교 결과는 아래와 같이 분류할 수 있다. 
    • 설계와 실차에 모두 있고 사양도 동일하다. OK
    • 설계와 실차에 모두 있는데 사양이 다르다. NOK
    • 설계에 있는데 실차에 없다. Missing
    • 실차에 있는데 설계에 없다. Unidentified
  • 분류에 따라 dbc를 점검 및 수정하거나, 제어기를 점검 및 수정해야 한다. 
  • 내가 갖고 있는 dbc 정보가 빈약하여 이 예제가 형상 관리 점검 아이디어를 제대로 설명했는 지 모르겠다. 부족한 dbc로 인한 부실한 예제가 설계 사양에 따른 dbc 관리가 형상 점검에 얼마나 중요한가를 잘 시사했기를 바란다. ^^

 

진단 통신으로 제어기 확인하기

• 진단 통신으로 제어기 확인하기 :: hsl's tsmaster 사용기
  • Read ECU ID 진단 요청으로 차에 있는 제어기들의 사양 정보를 확인할 수 있다.
  • 제어기 사양 정보를 설계 사양과 비교하는 방법으로 차량 형상을 관리를 할 수 있다.  

 

결론

• 차량 통신 데이터 분석
  • CAN 통신을 측정하여 메시지 아이디(m_id)들을 확인하였다. 
  • 메시지 아이디들이 dbc에 있는지 확인하고, 메시지 길이나 전송 주기 같은 통신 사양을 비교하였다. 이런 과정을 통해서 확인 결과를 4가지로 분류하였다.
    • OK: dbc에도 있고 CAN 버스에도 있으며, 사양이 동일함. 문제 없음 
    • NOK: dbc에도 있고 CAN 버스에도 있으나, 사양이 다름. 문제임 
    • Missing: dbc에는 있으나 CAN 버스에는 없음. 설계 사양의 오류이거나 구현의 오류임. 문제임
    • Unidentified: dbc에는 없으나 CAN 버스에 있음. 설계 사양의 오류이거나 구현의 오류임. 문제임
• 진단 통신으로 제어기 확인
  • 진단 통신의 Read ECU ID 서비스를 이용하여 실차에 있는 제어기들의 하드웨어와 소프트웨어 정보를 확보하여 실차 형상 정보를 확보할 수 있다.
  • 실차 형상 정보를 설계 사양과 비교하여 차이를 식별할 수 있다.
  • 형상 관리에 차이를 이용할 수 있다.

 

 

목차 :: hsl's tsmaster 사용기