차량 형상 점검

아직 작성 중입니다. 이 블로그의 소재를 주제로한 다른 블로그와 링크를 만들기 위해 이 블로그를 공개로 합니다.   

 

 

시작하기 전에 

 

새 차를 개발할 때 시작차(Prototype)를 만든다. 시작차는 기존 차(들)에서 시스템들을 가져다 만든다. (이를 캐리-오버라고 부른다.) 내가 말하는 시스템은 제어기, 센서, 액추에이터로 구성된다. 센서나 액추에이터는 단순 부품일 수도 시스템일 수도 있다. (시스템은 차 안에 있을 수도 차 밖에 있을 수도 있다.) 시스템들은 통신을 통하여 개별 시스템은 할 수 없는 기능을 구현한다.

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

• 어떤 시스템들이 포함되어 있는 지,
• 각 시스템의 하드웨어 버전과 소프트웨어 버전 무엇인지
• 위 정보들은 설계 사양과 일치 하는 지

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

통신을 모니터링하여 설치된 시스템들을 확인할 수 있다. 진단 통신으로 제어기별 하드웨어/소프트웨어 버전을 확인할 수 있다. 이렇게 하여 형상 관리에 필요한 차량 정보를 구할 수 있다.

 

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

 

 

개요

아래와 같이 해볼 것이다.

• 차량 통신 데이터 분석을 통한 시스템 확인
• 진단 통신으로 하드웨어 버전과 소프트웨어 버전 확인
• 설계 사양과 차량 정보 비교

 

 

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

실차 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 관리가 형상 점검에 얼마나 중요한 가를 잘 시사하기를 바란다. ^^