이 기술문서에서는 Simcenter Testlab과 Simcenter SCADAS에서 CAN(Controller Area Network) Bus 데이터를 측정하기 위한 방법과 문제 해결 방법에 대한 내용을 설명하고 있습니다.
하드웨어와 소프트웨어에서 적절한 설정을 하지 않으면 Testlab에서 CAN Bus 데이터를 읽거나 측정을 할 수 없습니다. CAN 데이터가 인식되지 않으면 그림 1과 같이 일반적으로 0인 그래프 결과가 나타납니다.
그림 1 (상단) CAN 데이터 인식 및 측정이 되는 경우
(하단) CAN 데이터 인식이 되지 않아 0으로 나타나는 경우
CAN 데이터 측정이 안되는 원인을 찾기 위해서는 물리적인 하드웨어 연결과 소프트웨어 설정을 살펴보아야 합니다.
1. 용어
이 문서에서 사용되는 약어 리스트는 아래와 같습니다.
- ARXML : AUTOSAR XML은 CAN FD 네트워크의 원시 신호를 읽을 수 있는 값으로 디코딩하기 위한 정보가 포함된 파일이며, 파일 확장자는 *.autosar입니다.
- CAN: 전자 제어 장치 간에 신호를 전달하는 데 사용되는 CAN(Controller Area Network) Bus입니다.
- CAN FD: CAN FD(Controller Area Network Flexible Data rate)는 각 신호에 대해 데이터 전송 속도를 독립적으로 설정할 수 있는 원래 CAN Bus 표준에 대한 업데이트입니다. 이를 통해 CAN FD 인프라는 이전 세대의 CAN Bus 네트워크보다 더 많은 신호를 전달할 수 있습니다.
- DB9: 9개의 핀이 있는 "D"자형 커넥터. CAN Bus 통신에 일반적으로 사용되는 커넥터입니다.
- DBC: 데이터 베이스 파일. CAN 데이터 베이스 파일은 DBC 확장자를 사용합니다. DBC 파일은 CAN 또는 CAN FD 데이터를 물리적 값으로 디코딩하기 위한 정보를 포함하고 있는 파일입니다. 이것은 모든 차량에서 작동하는 것은 아니며, 특정 차량의 모델 및 파워트레인에 따라 각각 다릅니다.
- ECU: 전자 제어 장치(ECU)는 차량 구성(예: 전기 모터, 변속기, 엔진 등)의 특정 기능을 제어하는 전자 장치입니다.
- OBD: On-Board Diagnostics(OBD)는 문제를 보고하기 위한 차량의 자가 진단 장치를 의미하며, 예를 들어서 엔진 오작동에 대한 경고등이 나타나면 OBD를 통해서 이 문제의 특성을 파악 하는데 도움을 받을 수 있습니다.
- OBD-II: On-Board Diagnostic II(OBD-II)는 차량에 탑재된 2세대 자가 진단 장치를 의미합니다.
- RDDF: Raw Data File을 의미하며, Testlab에서 측정된 *.rddf 파일에는 CAN Bus 네트워크에서 전달되는 원시 통신 및 신호가 포함되어 있습니다.
2. CAN Bus 및 Simcenter Testlab 개요
CAN Bus(Controller Area Network)는 여러 장치를 연결해서 서로 통신할 수 있도록 사용하는 통신 시스템입니다. CAN Bus는 일반적으로 차량에서 전자 제어 장치(ECU) 간의 통신에 사용되며, 디지털 센서에서도 사용이 됩니다.(그림 2 참조).
그림 2 ECU(전자 제어 장치, 좌측)와 디지털 센서(우측)가 장착된 장치 간의 CAN Bus 통신.
디바이스 간의 모든 통신은 디지털 방식으로 이루 어지며, 이것은 케이블 1개를 사용해서 여러 신호 전달을 할 수 있습니다.
- 차량: 최신 차량의 여러 구성품(변속기, 모터 등)에서 전자 제어 장치(ECU)는 CAN Bus 네트워크를 통해 수천개에 이르는 신호를 서로 주고받습니다.
- 디지털 센서: 하나의 CAN Bus 케이블을 가지고 휠 포스 트랜스듀서, 관성 측정 장치, 열전대 등의 여러 신호 전달이 가능 합니다.
아날로그 신호와 비교했을 때 CAN Bus 신호의 설정 및 측정은 차이가 있습니다. 아날로그 신호는 전원 연결이 잘못된 센서가 완벽하게 작동하지 않더라도 부분적인 신호 응답을 보일 수 있지만 디지털 CAN Bus 신호에서는 작동 또는 불능의 2가지 경우만 존재합니다. 그렇기 때문에 설정이 정확하지 않으면 신호가 나타나지 않습니다. CAN Bus 데이터를 통해 데이터를 수집하기 위한 몇 가지 물리적인 연결 방법이 있습니다.
2.1 OBD 포트를 통한 차량 CAN Bus
CAN Bus 신호는 차량의 OBD 포트를 통해서 액세스할 수 있으며, OBD 포트는 모든 CAN Bus 정보를 읽을 수 있는 단일 커넥터 사용이 가능하도록 프로그래밍 할 수 있기 때문에 편리 합니다.
OBD-II는 CAN Bus 프로토콜에서 작동되며, 차량의 OBD 포트를 통해 디지털 데이터를 제공하는 표준 프로토콜입니다. 예를 들어서 OBD-II 표준 프로토콜은 OBD 포트를 통해 배기 가스 테스트를 측정하는 데 사용되거나 또는 차량에 따라 프로그래밍 된 CAN Bus 신호 측정도 가능합니다. 많은 차량의 OBD 포트는 대시보드 아래에 있으며, 그림 3에 예시가 있습니다.
그림 3 차량에서 OBD 포트를 통해 CAN Bus 신호에 액세스할 수 있으며(좌측), OBD 포트는 차량 대시보드 밑에 있습니다.(우측)
일반적으로 많이 사용되는 2가지 CAN Bus 파일은 DBC(*.dbc) 와 ARXML(*.arxml) 입니다. 이런 파일은 차량 및 파워트레인에 따라 다르며, OBD-II 신호는 차량의 통신 Bus에 있는 신호의 집합입니다. OBD-II 신호만 읽는 것이 필요하다면, 각 차량별 파일 없이 읽을 수 있으며, 이 때 OBD-II 포트를 통해 CAN Bus 신호를 사용할 필요는 없습니다. 이 경우 다음에서 설명하는 대체 방법을 사용하여 CAN 네트워크에 연결할 수 있습니다.
2.2 Vehicle CAN Bus 태핑
CAN Bus 신호가 존재하지 않거나 OBD-II 포트를 사용할 수 없는 경우에는 다른 방법으로 액세스해야 합니다. 이 때는 각 CAN Bus의 하위 네트워크(파워트레인, 차체, 섀시 등)에 다른 연결이 필요할 수 있으며, 그림 4와 같이 CAN Bus 케이블을 사용 할 수 있습니다.
그림 4 ODB 포트가 없으면 여러 개의 개별 CAN 네트워크를 측정해야 하는 경우가 많습니다.(좌측) DB9 커넥터에 두 개의 집게가 있는 커넥터가 없는 경우 CAN 네트워크를 수동으로 활용해야 할 수 있습니다.(우측)
각 하위 네트워크에서는 각각 다른 신호를 전달할 수 있으며, 각 네트워크에는 자체 커넥터(일반적으로 DB9 커넥터)가 있을 수 있습니다. 그렇지 않다면 커넥터를 수동으로 추가해야 할 수 있습니다.
2.3 디지털 센서
그림 5와 같이 CAN Bus 출력을 활용하여 센서 신호를 전달하는 다양한 유형의 센서(관성, 온도, 압력, 힘 등)가 있습니다.
그림 5 CAN Bus를 사용하 는 센서의 예.
Simcenter SCADAS를 사용한다면 CAN Bus를 사용하는 디지털 센서가 편리 합니다. 예를 들어서 T8A 온도 모듈과 함께 2개의 슬롯을 사용하는 대신 CAN 채널 1개를 사용해서 써모커플 16개를 사용할 수 있습니다.
3. 외부 요인
CAN Bus로 신호 측정을 할 때, 신호 유무를 체크하기 위해서 확인해야 할 몇 가지 항목이 있습니다.
3.1 CANBus를 On 상태 확인
차량 또는 디지털 센서에 전원 공급이 안되면 CAN Bus에 신호가 나타나지 않습니다.
3.2 CAN Bus 잠금 해제
일부 CAN Bus 시스템에서는 신호가 보호되고, 특정 키(전자 파일)를 사용하여 잠금 해제를 하지 않는 이상 신호를 읽을 수 없습니다. 이 키는 시드키(seed-key) 시스템에 의해 관리됩니다.
시드키(seed-key) 시스템의 기본 개념은 전자 제어 장치(ECU)가 시드(바이트 값의 짧은 문자열)를 제공하고 보안 알고리즘을 사용해서 해당 시드를 키로 변환하는 도구가 필요합니다. ECU는 내부적으로 동일한 알고리즘을 적용하고 툴에서 부여한 키 값을 자체 값과 비교합니다. 두 장치에서 값이 서로 일치하면 장치에서 보안 알고리즘을 "알고 있는" 것으로 간주하요 액세스 권한을 부여 합니다.
CAN Bus의 잠금을 해제한 후에도 추가적인 보안 기능은 특정 시간 동안 작동 후 또는 일정 거리를 이동한 후에 CAN Bus 액세스가 거부될 수 있습니다. 이 경우에는 CAN Bus의 잠금을 해제하기 위해 또 다른 시드 키 작업을 해야 합니다.
4. 물리적 하드웨어 연결
CAN Bus 신호를 측정하려면 적절한 물리적 커넥터, 케이블 및 터미네이터를 사용해야 합니다.
4.1 CAN 커넥터
CAN 장치의 커넥터는 일반적으로 그림 6과 같이 9핀 직렬 커넥터입니다. 핀 2, 3 및 7은 표준이며, 전원 핀은 CAN 장치에 따라 다를 수 있습니다. 표시된 핀배열은 SCADAS CN-4 에 사용 됩니다.
그림 6: SCADAS CN-4의 DB9 직렬 커넥터 CAN Bus Pin Map. Pin 7(하늘색)의 CAN High, Pin 2(빨간색)의 CAN Low, Pin 3(녹색)의 접지, Pin 1과 5(보라색)의 전원. 필요한 경우가 아니면 전원 핀을 연결하지 마십시오! 디바이스를 Simcenter SCADAS와 연결하기 위해서는 최소 2개의 Pin이 사용됩니다.
- Pin 7: CAN High(하늘색)
- Pin 2: CAN Low(빨간색)
또한 필요에 따라 다른 핀 사용이 가능합니다.
- Pin 3 : Ground (녹색)
- Pin 1 및 5 : Power (보라색), 옵션(장비 보호에 필요하지 않은 경우 연결하지 않음)
CAN Bus 신호 측정을 위해서 올바른 커넥터 연결을 해야하며, 차량 CAN Bus에는 전원 공급이 되므로 별도로 전원 공급이 필요 없습니다. 만일 추가적인 전원 공급이 될 경우에 CAN Bus가 손상될 수 있습니다. CAN Bus를 통해 디지털 센서를 사용하는 경우에는 Pin1과 Pin5의 CAN 케이블을 사용해서 디바이스에 전원 공급이 되기도 합니다.
다양한 하드웨어를 위한 CAN Bus 전원 옵션:
- SCADAS CN-4는 Pin5에서 +15V, Pin1에서 –15V로 외부 장치에 전원을 공급할 수 있습니다. voltage 공급은 항상 켜져 있습니다.
- SCADAS SYSCON의 CAN 채널은 전원 공급을 할 수 없습니다.
- SCADAS RS: Pin5에서 +15V를 켜고 끌 수 있습니다.
SCADAS 하드웨어의 CAN 전원 구성은 다음과 같습니다.
- SCADAS CN-4 : 위에 표시된 Pin2,3,7. Pin15에서 +1V, Pin5에서 -15V. 장치에 전원이 필요하지 않은 경우 연결하면 안됩니다.
- SCADAS SYSCON: 위에 표시된 Pin2,3,7. 전원 핀이 없습니다.
- SCADAS RS: 위에 표시된 Pin2,3,7. Pin1에만 전원 공급 합니다(+15V). Pin5와 Pin3은 모두 접지(0V)입니다.
4.2 케이블
CAN Bus 케이블은 CAN 디바이스의 출력을 SCADAS에 연결하는 데 사용되며, SCADAS 하드웨어에 따라서 디바이스의 CAN Bus 출력과 SCADAS 하드웨어 사이를 연결하는 다양한 케이블 어댑터가 제공됩니다(그림 7)
그림 7: CAN 커넥터를 SCADAS에 연결하는 데 사용되는 어댑터 케이블.
일부 CAN 장치(예: 차량)에는 OBD(Onboard Diagnostics) 커넥터에 CAN Bus 출력이 있을 수 있습니다. 이 경우에는 OBD를 표준 9핀 CAN 커넥터에 연결하기 위해 추가 케이블이 필요합니다. OBD-II-CAN 9 핀 케이블의 예는 그림 8에 나와 있습니다.
그림 8: OBD-II-CAN 커넥터 케이블의 예.
권장하는 OBD-II 케이블은 아래와 같습니다.
- Siemens: OBD-II 및 CAN-FLEXRAY 용 SCX-CAS20 케이블
- Intrepid Controls: ValueCAN OBD-II 케이블(DB-9F to OBD-II)
- Vector: OBD 케이블 CAN 부품 번호 22089
차량에는 적합한 OBD-CAN Bus 케이블을 사용하는 것이 중요하며, 3개 핀 이외에 연결을 하면 문제가 발생할 수 있습니다. 예를 들어서 다른 핀 중 하나에 전원 연결을 하면 차량의 전자 장치가 손상 될 수 있습니다.
4.3 SCADAS CAN 모듈 및 상태 표시
SCADAS 하드웨어에는 CAN 통신을 위한 전용 모듈이 있습니다. CAN 채널의 LED는 연결 상태를 나타내며, 이것은Testlab에서 ARM을 클릭하면 LED가 활성화 됩니다.
4.3.1 SCADAS SYSCON 컨트롤러
SCADAS의 인터페이스 카드(SYSCON)에는 일반적으로 그림 9와 같이 하나의 CAN Bus 채널이 있습니다.
그림 9: SCADAS SYSCON 인터페이스의 CAN 채널
SYSCON CAN 채널의 LED표시는 다음과 같습니다.
- Green Light : CAN 채널 ON
- Red Light : CAN 통신 없음
- Light OFF : CAN 채널이 활성화되지 않음
4.3.2 SCADAS CN-4 모듈
SCADAS CN-4 모듈(제품 코드: SCM-CN4)에는 그림 10과 같이 2개의 9핀 직렬 커넥터가 있습니다.
그림 10 SCADAS CN-4 모듈의 2개 커넥터에서 4개의 CAN 채널 사용 가능
2개의 9핀 커넥터 각각에 2개의 CAN 케이블 연결이 가능하며, 이때 스플리터 케이블이 필요합니다.
- Blue Light : CAN 채널 ON
- Red Light : CAN 통신 없음
- Light OFF : CAN 채널이 활성화되지 않음. SCADAS CN-4 모듈은 핀1과 5에서 전원을 공급합니다.
4.3.3 SCADAS RS
SCADAS RS는 다양한 환경 조건에서 사용이 가능한 하드웨어이며, CAN 채널에는 LED가(그림 11) 없기 때문에 물과 먼지의 침입을 최소화 할 수 있습니다. 그리고 SCADAS RS Recorder App 또는 Testlab Neo를 사용하면 CAN 채널에 트래픽이 있는지 여부를 알 수 있습니다.
그림 11: SCADAS RS에는 CAN 채널에 LED가 없습니다.
4.3.4 SCADAS LED
그림 12에서 SCADAS의 2가지 조건에서 나타나는 LED를 볼 수 있습니다.
CAN 채널이 켜지면 일반적으로 녹색 표시등 또는 파란색 표시등이 켜집니다. 잘못된 전송 속도 또는 부적절한 터미네이션과 같은 문제가 있는 경우 SCADAS CAN 채널 옆에 있는 LED가 빨간색으로 표시 됩니다.
그림 12 빨간색 표시등(CN-4 모듈)은 CAN 연결에 문제가 있음을 나타내며(부적절한 종료, 전송 속도 등), 녹색 표시등(SYSCON 모듈)은 CAN이 정상적으로 연결되어 있음을 나타냅니다.
5. CAN Bus 하드웨어 터미네이터
CAN Bus의 부적절한 터니네이터는 CAN Bus 네트워크에 신호가 나타나지 않을 수 있는 또 다른 원일일 수 있습니다. 실제로 CAN Bus의 적합한 터미네이터는 CAN Bus의 양끝 사이의 전자기 반사(electromagnetic reflections)를 손상시켜 통신을 불안정하게 만들수 있기 때문에 CAN Bus의 기능을 위해 매우 중요합니다.
5.1 터미네이터 개요
가장 긴 케이블(또는 Bus) 길이는 양쪽 끝에서 120옴 저항으로 테미네이션 되어야 합니다. 저항은 네트워크에 배치된 위치에서 CAN high와 CAN low 사이에 있습니다. CAN 케이블 길이가 길어질 경우 테 미네이 션이 특히 중요합니다.
Simcenter SCADAS 시스템에는 CAN Bus 포트에 터미네이터가 내장되어 있지 않으므로, 필요한 경우 외부 터미네이터를 추가해야 합니다. 그림 13에는 120옴 터미네이터의 두 가지 예가 나와 있습니다.
그림 13 (좌 측) 9핀 직렬 120옴 저항기 (우측) 디지털 센서용 Lemo 타입 저항기
SCADAS CAN Bus의 끝단에 터미네이터를 적용하기 위해 그림 13의 좌측 터미네이터와 같은 저항을 사용할 수 있습니다. CAN Bus 통신이 가능한 모든 SCADAS 모듈에는 직렬 9핀 커넥터 CAN 포트용 전용 케이블이 함께 제공됩니다. 터미네이터는 그림 9와 같이 14핀 연결에 사용할 수 있습니다.
그림 14: SCADAS CAN Bus 케이블에 120옴 터미네이터를 적용한 예시. SCADAS에는 내장된 터미네이터가 없으며 시나리오에 따라 그림과 같이 터미네이터를 추가해야 합니다. 반면에 CAN Bus 또는 케이블이 비교적 짧은 경우에는 하나의 터미네이터만 사용해도 됩니다.
5.2 차량 CAN Bus 터미네이터
차량 CAN Bus에 연결할 때(그림 15) 일반적으로 SCADAS에서는 추가적인 터미네이터가 필요하지 않습니다.
그림 15: 차량 CAN Bus를 읽기 위한 SCADAS 설정. 차량 CAN Bus가 이미 터미네이터 되어 있기 때문에 추가 120옴 터미네이터가 필요하지 않습니다. 차량 CAN Bus가 제대로 작동하기 위해서 CAN 케이블의 내부 끝단에 이미 터미네이터 적용되어 있습니다.
5.3 디지털 센서 CAN Bus 터미네이터
그림 16은 디지털 센서 또는 디지털 센서 모듈(예: 휠 포스 트랜스듀서, 관성 측정 장치 또는 열전대 디지털 센서 모듈)을 Simcenter SCADAS에 연결하여 설정하는 방법을 보여줍니다.
그 림 16: 디지털 센서를 위한 Simcenter SCADAS 설정 및 CAN 케이블 설정. 2개의 터미네이터(파란색, 120옴)는 CAN 케이블의 끝단 근처에 배치해야 합니다 .
CAN Bus는 양쪽 끝, 즉 Simcenter SCADAS와 디지털 센서에서 터미네이터 되어야 합니다. Simcenter SCADAS에는 내부 터미네이터가 없습니다. 대부분의 경우에 터미네이터가 CAN Bus의 디지털 센서 또는 디지털 센서 모듈 끝, 즉 직렬 9핀 커넥터가 이러한 장치에 연결된 경우에 유사하게 적용될 수 있습니다. 다른 경우에는 이러한 디바이스에 터미네이터 기능이 내장(built-in)되어 있을 수도 있습니다.
터미네이터는 연결된 CAN Bus 케이블의 맨 끝에 있을 필요가 없지만 터미네이터를 지나는 CAN Bus 케이블 길이는 메인 연결 케이블의 길이에 비해서 짧아야 합니다.
5.4 디지털 센서 터미네이터 예시 : 열전대(Thermocouple )
Simcenter SCADAS TCK8 디바이스는 디지털 센서 모듈입니다. 이 경우에는 적절한 터미네이터를 적용해야 하며, 이를 위해서 그림 17과 같이 2개의 터미네이터를 사용 하였습니다.
그림 17: TCK8 장치를 SCADAS에 연결하면 2개의 터미네이터가 사용되는데, 하나는 SCADAS에 연결되는 케이블에 있고 다른 하나는 디지털 센서 근처에 있습니다.
6. 소프트웨어 설정(Configuration 파일과 CAN Parameters)
Testlab에서는 연결된 CAN Bus 하드웨어를 적용하기 위해서 몇가지 설정이 필요합니다. 이 설정은 configuration files(*.dbc 또는 *.arxmll)의 조합과 Testlab의 설정으로 가능합니다.
6.1 Configuration Files (DBC, ARXML)
CAN Bus를 통해 데이터 계측을 하는 경우에 DBC 파일(*.dbc) 또는 ARXML(*.arxml) configuration 파일을 사용하여 신호 디코딩을 합니다.
이런 종류의 파일에는 다음 내용이 포함 됩니다.
- 모든 ECU의 목록
- ECU 간에 전송되는 모든 입력 및 출력 신호 목록
- 각 CAN 신호에 대한 Scale factor, offset 및 기본값
파일 정보는 차량의 모델, 연식, 파워트레인에 따라 다르며, DBC 파일은 ASCII 텍스트 파일이며, 메모장에서 편집할 수 있습니다. DBC 파일 내용의 예시는 그림 18에 나와 있습니다.
그림 18: 두 개의 ECU에서 전달하는 신 호를 보여주는 DBC 파일의 내용.
DBC 또는 ARXML 파일은 차량 플랫폼, 모델, 연식, 파워트레인에 따라 다르며, 이 파일에는 모든 차량에서 작동되는 정보가 포함되어 있지 않습니다. configuration 파일(*.dbc, *.arxml)의 정보가 CAN 네트워크에서 전송되는 정보와 일치하지 않으면, 정보를 디코딩하여 표시할 수 없습니다.
Testlab을 사용할 때 broadcast data와 configuration 파일의 정보간의 불일치를 나타내는 로그 파일이 생성됩니다. 불일치 결과의 로그 파일인 CAN_db_parse_log.txt는 C:/users/login/AppData/Local/Temp 에 있으며, Windows 탐색기에서 "CAN"이라는 단어로 검색하면 그림 19와 같이 빠르게 찾을 수 있습니다.
그림 19: "CAN_db_parse_log.txt" 파일에는 CAN Bus에서 읽을 수 없는 메시지/채널에 대한 정보가 포함되어 있습니다.
메모장에서 파일을 열면 그림 20과 같이 CAN 네트워크의 특정 메시지를 읽을 수 없는 이유에 대한 정보를 확인 할 수 있습니다.
그림 20 CAN_db_parse_log.txt 파일의 내용은 특정 메시지를 읽지 못하는 이유를 확인 할 수 있습니다.
시험 차량을 짧은 시간 동안만 사용할 수 있고 적절한 configuration 파일(*.dbc 또는 *.arxml)을 사용할 수 없을 수도 있습니다. 이 경우에는 전체 raw CAN Bus 데이터 스트림을 추후에 디코딩하기 위해 저장이 가능 합니다. Testlab의 채널 설정에서 그림 21과 같이 디지털 Bus 채널 아래의 Save Raw Data 가 체크되어 있는지 확인합니다.
그 림 21 CAN Bus를 On하고 Save Raw Data가 체크되어 있는지 확인합니다.
Save Raw Data를 체크하면 전체 raw CAN Bus 데이터 스트림이 디코딩된 신호와 함께 병렬로 저장 됩 니다. 기본적으로 Save Raw Data 옵션은 On되어 있습니다.
6.2 CAN FD와 CAN Bus 비교
CAN FD(Flexible Datarate)는 기존 classical CAN을 개선한 것이며, 2가지 주요 개선 사항이 있습니다.
- Higher Data Transfer Rate : 1Mbit/s에서 최대 8Mbit/s로 더 빠른 속도로 데이터 전송이 가능합니다.
- Larger Message Size : classical CAN의 8바이트에 비해서 최대 64바이트의 더 높은 데이터 전송이 가능하며, 이를 통해 싱글 메시지에서 더 많은 신호 전달이 가능합니다.
2012년 출시 이후 CAN FD는 자동차 산업에서 점점 더 까다로워지는 대역폭 요구 사항에 대응하기 위해 차량 제조업체와 부품업체에서 더 많이 채택을 하고 있지만, 아직도 많은 vehicle bus는 여전히 standard CAN에을 사용합니다. 그리고 durability 및 NVH 애플리케이션에 사용되는 디지털 센서의 경우에 standard CAN을 기반으로 작동을 하고 있습니다.
Vehicle CAN Bus 연결을 설정할 때, CAN 또는 CAN FD 인지 확인하는 것이 중요하며, 그림 22와 같이 Testlab에서 이 파라미터를 올바르게 선택해야 합니다.
그림 22: (좌측) Testlab Neo의 Conditioning에서 classic CAN인 경우에 Digital CAN을 선택하고 CAN FD인 경우에는 Digital ISO CAN FD를 선택합니다. (우측) Testlab Classic의 Controller Mode에서 사용 중인 CAN 종류에 따라 Standard CAN 또는 ISO CAN FD를 선택합니다.
SCADA하드웨어가 CAN만 지원하는 경우 컨트롤러 모드 선택이 회색으로 표시됩니다. CAN FD를 지원하 는 경우 Standard CAN도 지원하므로 2가지 선택 항목이 나타납니다. Standard CAN과 CAN FD의 물리적인 커넥터는 동일하기 때문에 육안으로 이 2가지를 구별하는 것은 어렵습니다.
Standard CAN 또는 CAN FD 확인하는 방법
- Configuration 파일: CAN 신호를 디코딩하는 데 사용되는 데이터베이스 파일이며, 확장자는 *.dbc 파일 또는 *arxml입니다.
configuration 파일에서 standard CAN인지 CAN FD인지 확인하려면 메모장에서 *.dbc 파일을 엽니다. CAN("BusType", "CAN") 또는 CAN FD("BusType", "CAN FD")로 설정될 매개변수 "BusType"을 검색합니다. 그림 23에서 이 파라미터가 CAN FD로 설정된 예를 볼 수 있습니다.
그림 23: 메모장에서 *.dbc 파일을 열어서 BusType이 CAN FD임을 확인할 수 있습니다.
차량 네트워크와 관련된 .arxml 파일이 있는 경우 그림 24와 같이 Testlab의 CAN 설정에서 import할 수 있습니다.
그림 24: Autosar(*.arxml) 파일 import
CAN FD는 데이터 속도가 더 빠르기 때문에 터미네이션이 중요하고 짧은 Bus(또는 케이블 길이)의 경우에도 2개의 터미네이터를 CAN 네트워크 끝에 최대한 가깝게 배치하는 것이 중요합니다.
6.3 전송 속도(Baud Rate)
CAN Bus 하드웨어는 특정 전송 속도(baud rate)로 작동하며, 이 전송 속도는 Testlab (그림 25)에서 설정해야 합니다. 이 값은 CAN 하드웨어(차량 네트워크 또는 디지털 센서)의 전송 속도와 일치해야 합니다.
그림 25: Baud rate 500,000은 CAN 디바이스에서 일반적인 값 입니다.
많은 CAN Bus 장치는 Baud rate 500,000으로 작동되며, 정확한 값을 모를 경우에 시도해 볼 수 있습니다. 그리고 .dbc 파일 또는 .arxml 파일에서도 이 값을 찾을 수도 있습니다. 위의 그림 23의 메모장에서 .dbc 파일을 열고 Baudrate으로 검색을 하면 됩니다. 이 파라미터가 .dbc 파일(또는 .arxml 파일)에 지정된 경우 Testlab에서 자동으로 선택되고 추가 작업 없이 필드값이 회색으로 표시됩니다.
6.4 CAN 샘플 포인트(Sample Point)
logical 값(0 - dominant 또는 1 - recessive)이 비트 지속 시간을 따라 정의(또는 샘플링)되고 백분율(%)로 표현되는 됩니다. Standard CAN은 대부분 75% 값으로 작동되며 Testlab에서 기본적으로 사용됩니다.
6.5 CAN FD: Data Rate와 Data Sample Point
CAN FD의 유연성이 향상됨에 따라 CAN FD에서 정의해야 하는 2가지 추가 파라미터가 있습니다.
- 데이터 속도(Data Rate) : 데이터 또는 페이로드가 전송되는 속도이며, 실제로 일반적인 값은 1Mbit/s 및 2Mbit/s입니다
- 데이터 샘플 포인트(Data Sample Point) : 논리 값(0 - dominant 또는 1 - recessive)이 메시지의 페이로드 부분에 대한 비트 지속 시간을 따라 정의(또는 샘플링)되고 백분율(%)로 표현됩니다.
이러한 매개변수를 사용하려면 컨트롤러 모드를 ISO CAN FD로 선택해야 하며, *.arxml 파일을 사용할 때 Testlab에서 자동으로 나타납니다(CAN FD 컨디셔닝 모드 선택 후).
6.6 CAN Acknowledge : Active와 Passive
CAN Acknowledge 설정을 Active에서 Passive로(또는 그 반대로) 전환하면 CAN 통신 문제가 해결되는 경우가 많습니다. 이 설정은 그림 26과 같이 CAN 설정에서 찾을 수 있습니다.
그림 26: CAN Acknowledge에서 Active 및 Passive 선택
CAN Bus 신호에는 acknowledgement(승인)이 필요합니다. 신호를 인식하는 수신기가 없으면, CAN 신호의 전송이 중단 됩니다. Acknowledgement는 broadcasting device에서 CAN 신호가 제대로 수신되고 있음을 나타내는 정보를 다시 수신하는 것을 의미합니다.
Active 및 Passive 설정:
- Passive : 관심 있는 CAN 신호가 이미 SCADAS 이외의 다른 장치에서 인식되고 있으며, Passive로 설정하면 Bus에서 중복 메시지를 방지할 수 있습니다. 대부분의 vehicle buses 에는 acknowledging 디바이스가 이미 있습니다.
- Active : Active로 설정하면 SCADAS가 메시지를 인식하며, CAN 네트워크의 다른 장치가 acknowledgement를 수행하지 않을 때 중요합니다.
Active 또는 Passive를 선택하는 3가지 경우
- 일반적인 Vehicle Bus에서 CAN Bus 신호를 읽으려면 차량을 인식하기 때문에 Passive mode를 선택 합니다.
- Onboard Diagnostic connector를 통해 읽을 수 있는 법적인 문구를 확인해야 함(Active mode)
- 디지털 센서에 대한 승인(acknowledgement)가 필요한 경우(Active mode)
7. 디코딩 팁
디코딩은 그림 27과 같이 CAN 메시지(디지털 정보만 포함)를 동시 수집된 아날로그 데이터와 함께 기존의 측정에서 표시 및 해석할 수 있는 엔지니어링 신호로 변환하는 프로세스와 관련이 있습니다.
그림 27: Raw CAN binary 데이터(좌측)가 디코딩 되어 엔지니어링 신호로 변환됩니다(우측).
그러나 디코딩을 검증전에 CAN configuration의 문제가 나타나면, Basic CAN Bus 통신 및 트래픽이 제대로 설정 되었는지 확인해야 합니다. 이것을 평가하는 방법을 아래서 살펴 볼 수 있습니다.
7.1 RDDF 파일
기본적인 하드웨어 연결이 제대로 되었는지 또는 기본 CAN configuration 파라미터가 올바르게 선택되었는지 검증하는 방법은 SCADAS 측정을 통해 저장된 raw CAN 데이터의 내용을 시각화하고 분석하는 것입니다.
Record Raw CAN Bus 옵션을 ON 시키고 저장을 하면 *.rddf 파일이 나머지 데이터와 함께 자동으로 저장 됩니다. 이것은Testlab 내에서 디지털 Bus 데이터 아이콘(그림 28 참조)으로 표시되고 관련된 파일은 Run 폴더에서 찾을 수 볼 수 있습니다.
*.rddf 파일에는 Bus에서 사용할 수 있는 모든 CAN Bus 신호가 raw format (즉, 디코딩이 적용되기 전)으로 포함되어 있습니다.
그림 28: 디지털 Bus 데이터는 CAN Bus의 전체 raw communication이 저장(주황색 박스 표시)되었으며 Testlab project 파일에서 사용할 수 있습니다.
7.2 RDDF(Raw CAN) 파일 읽기
* .rddf 파일은 압축을 위해 Binary Data를 저장하지만, 읽고 해석하기 위해 ASCII 형식으로 변환 할 수 있습니다. 이것은 2가지 방법으로 수행할 수 있습니다.
7.2.1 RDDF를 ASCII로 변환 방법
먼저, 바탕화면의 Simcenter Testlab 폴더에서 Tools에 있는 RDDF to ASCII Converter 를 실행합니다. (그림 29)
그림 29 RDDF to ASCII 변환 툴
RDDF 파일을 선택하고 Convert to ASCII 버튼을 클릭하면 메모장에서 읽을 수 있는 ASCII 파일(*.asc)이 만들어집니다. *.rddf를 변환시킨 ascii(*.asc) 파일은 그림 30과 같은 구조를 가집니다. 변환된 파일에는 타임 스탬프별로 정렬되어 있으며, Bus를 통과하는 모든 메시지가 기록되어 있습니다. 가장 중요한 정보는 메시지를 식별하는 고유 번호인 메시지의 CAN ID와 전송되는 실제 데이터를 포함하는 페이로드(payload)입니다.
그림 30: *.rddf 파일이 ASCII 형식으로 변환되면 메모장에서 살펴 볼 수 있습니다. 이 파일에는 CAN ID와 콘텐츠(Payload \ Data)와 같은 용어로 저장하는 동안 Bus에서 전달되는 모든 메시지가 포함 되어 있습니다.
7.2.2 Testlab Neo에서 RDDF를 ASCII로 변환
*.rddf 파일의 내용을 살펴 볼 수 있는 2번째 방법은 Testlab Desktop Neo를 사용하는 것입니다. 이 작업은 그림 31과 같이 Desktop의 View data에서 진행 할 수 있습니다.
그림 31: *.rddf 파일은 디지털 데이터 아이콘에서 마우스 우클릭을 해서 View 를 선택하면 Testlab Neo에서 직접 ASCII로 변환하고 그 결과를 볼 수 있습니다.
7.3 RDDF ASCII 파일을 통해 CAN 트래픽 Validate
RDDF ASCII 파일은 "비어 있거나"(즉, CAN 트래픽이 기록되지 않음) 또는 CAN 메시지로 채워집니다.
7.3.1 빈 RDDF ASCII 파일
ASCII CAN 파일을 읽을 때 내용이 없는 파일일 수 있습니다. 이 경우에는 파일 사이즈가 작고(4~5킬로바이트) 의미 있는 메시지를 포함하고 있지 않습니다. 빈 파일의 예는 그림 32와 같습니다.
그림 32: 빈 RDDF 파일의 예시
(좌측) SCADAS Mobile/Recorder 파일이 비어 있습니다.
(우측) SCADAS RS 빈 파일은 FFFFFFFF의 문자열로 구성됩니다.
빈 파일은 다음과 같은 몇 가지 다른 문제를 의미할 수 있습니다.
- CAN Bus Off : 단순히 Bus 또는 디바이스가 OFF 되어 있거나 어떤 이유로 필요한 데이터를 보낼 준비가 되지 않았음을 의미
- CAN Connections: 터미네이터를 누락했거나 잘못된 연결 또는 선택한 CAN 위치에 CAN 데이터가 없는 것이 포함될 수 있습니다.
- CAN Settings : 잘못된 baud rate
- Message Requests : 디바이스가 켜져 있고 준비가 되었다고 확신하는 경우 픽업하기 전에 Bus에서 필요한 데이터를 가져오는 데 필요한 일부 상위 계층 프로토콜 작업과 관련된 문제일 수 있습니다(이 경우에 다음 섹션 중 하나를 참조)
7.3.2 밀집된 RDDF ASCII 파일
그림 33은 모든 파라미터가 올바르게 설정된 "양호한" 것부터 시작해서 다양한 상황의 기능에서 특정 CAN Bus의 raw CAN 데이터를 포함하는 *.rddf 파일의 몇 가지 특성을 요약한 것입니다.
그림 33: *.rddf 파일에 포함된 raw CAN 데이터를 보면 CAN Bus 트래픽이 제대로 기록되고 있는지 확인할 수 있습니다.
CAN 메시지가 저장된 경우에 파일 사이즈는 무시할 수 없는 크기(4~5초 수집 시간 동안 몇 킬로바이트 이상)를 가지며, 이 파일에서 그 내용을 살펴보면 여러 개의 서로 다른 CAN ID와 다양한 페이로드를 가진 서로 다른 CAN 메시지를 명확하게 구별할 수 있습니다. 이것은 트래픽이 제대로 저장 될 수 있음을 의미하며, 필요한 신호가 Testlab에 나타나지 않는다면 디코딩이나 상위 계층(dedicated higher layer) 문제와 관련이 있을 가능성이 큽니다(다음 섹션 참조).
7.4 RDDF ASCII 파일과 DBC/ARXML의 메시지 확인
RDDF가 ASCII로 변환되고 여기에 의미 있는 데이터가 포함되어 있는 것으로 확인되면, 더 많은 문제 해결을 진행 할 수 있습니다.
예를 들어, Bus에 있는 메시지가 dbc 파일에서 사용 가능한 메시지와 동일한지 확인할 수 있습니다. dbc 파일에는 실제 Bus에서 사용 가능한 메시지를 디코딩하는 데 필요한 정보가 포함되어 있습니다. dbc의 CAN ID와 *.rddf 파일에 기록된 raw CAN 데이터 간에 일치하는 항목이 없다면, 디코딩이 수행되지 않고 Testlab에서 엔지니어링 신호가 생성되지 않습니다.
그림 34에는 CAN ID 780(16진수로 30C에 해당)이 있는 특정 메시지("LeftFront_3")를 사용할 수 있고 *.rddf ASCII 파일에 잘 기록되어 있습니다.
그림 34: DBC 파일에 나열된 CAN id를 RDDF 파일에서 사용할 수 있는 id자와 비교하면 DBC 파일에서 적절한 디코딩 정보를 사용할 수 있는지 확인할 수 있으며, 트래픽의 일부로 CAN Bus에서 예상 데이터를 사용할 수 있는지 확인할 수 있습니다.
메세지 ID는 DBC 파일에서는 소수 형식으로 저장되는 반면, RDDF에서는 16진수로 저장됩니다. 따라서 일치하는 항목이 있는지 적절하게 평가하기 위해 두 포맷 간의 변환을 수행해야 합니다. 16 진수에서 10 진수로 변환은 Windows 계산기에서 사용할 수 있습니다.
신호에 해당하는 dbc 항목과 일치하는 항목이 없는 경우 다음과 같은 이유일 수 있습니다.
- dbc 파일이 올바르지 않은 경우(예: 일부 CAN ID가 올바르게 지정되지 않음). 오래된 dbc 파일 때문일 수 있으며, RDDF 항목과 일치시키기 위한 수동 변경으로 이 문제를 해결할 수 있습니다.
- 데이터가 CAN Bus에 없음 : 메시지 데이터가 CAN Bus에 없을 수 있습니다. 한 가지 원인은 적절한 차량 CAN Bus에 연결되지 않았을 수 있으며, 이 경우에는 필요한 메시지와 데이터를 찾기 위해 차량의 다른 곳에 연결을 해야 합니다. OBD-II 또는 J1939 PGN에서 사용하기 전에 필요한 데이터와 호환이 되어야 하기 때문일 수도 있습니다.
- 특정 소스 주소: DBC 파일 항목과 RDDF 파일에 기록된 메시지 간에 일치하지 않는 또 다른 잠재적인 원인은 데이터를 송신하는 장치에서 사용하는 특정 소스 주소의 사용과 관련된 것일 수 있는데, 이런 경우에는 디바이스가 SAE J1939 프로토콜을 사용하는 경우일 수 있습니다. 이것은 29비트 CAN에서 실행되는 상위 계층 프로토콜로(higher layer protocol), 몇 가지 추가 정의가 적용된 후 사용됩니다.
7.5 메시지 요청 : OBD-II 및 SAE J1939
CAN Bus의 트래픽이 확인된 경우 raw CAN 데이터가 *.rddf 파일에 제대로 저장된 것으로 확인 되었으나 이런 트래픽에서 예상 메시지를 찾을 수 없는 경우 필요한 데이터를 사용하기 전에 요청해야 합니다.
특정 상위 계층 프로토콜은(Specific higher layer protocols) 실제로 특정 메시지 요청이 필요한 데이터를 디바이스로 전송하는 옵션에 대한 규칙을 정의합니다. 일반적인 것은 자동차에서 널리 사용되는 진단 프로토콜인 OBD-II 프로토콜이며, 네트워크의 모든 장치 또는 특정 주소를 통해 특정 디바이스를 처리하는 특정 매개변수(예: 차량 속도 및 엔진 rpm)를 요청할 수 있습니다.
메시지 요청을 사용하는 또 다른 프로토콜은 SAE J1939 프로토콜이며, 네트워크의 특정 노드로 전송되거나 전달되는 PGN 요청 메시지를 통해 특정 PGN(파라미터 그룹 번호)을 요청할 수 있는 off-highway industry에서 널리 사용됩니다. 이러한 요청은 Testlab Neo Time Data Acquisition 또는 SCADAS RS용 Testlab Neo Recording Workbook에서 정의할 수 있습니다. (그림 35 참조)
그림 35: J1939 PGN 요청은 Testlab Time Data Acquisition 및 Testlab Recording Workbook 에서 정의할 수 있습니다.