피터 펠메스 (Peter Fellmeth) J1939, ISOBUS, 이더넷 및 Car2x 부문 그룹 책임, Vector Informatick GmbH
홀거 소늘레 (Holger Sohnle) J1939 및 ISOBUS 임베디드 소프트웨어 부문 매니저, Vector Informatick GmbH)


CAN 버스(ISO 11898에 따른 고속용 CAN)를 기반으로 하는 SAE J1939 표준은 주로 상용 차량의 파워트레인 및 새시 네트워크에 사용된다. 이 프로토콜은 전자 ECU 간의 통신을 위한 단일화된 토대를 형성하며 플러그 앤 플레이 원리로 작동한다. 현재 사용되고 있는 J1939 표준은 19개의 문서로 구성돼 있다(그림 1). 이 표준을 담당하는 SAE 부속 위원회는 매년 4차례의 회의를 통해 변경사항과 추가 개발 사항을 결정한다. 문서의 현재 버전은 SAE 웹 사이트에서 개별적으로 구매할 수도 있으며 “Paks”라는 패키지로 일괄 구매할 수도 있다[1].
늘어난 대역폭
현재까지 몇 년 동안 이 표준에 지정된 최대 250 kbit의 대역폭으로 인해 상용 차량 개발자들은 성능상 제한을 받으며 연구를 진행할 수밖에 없었다[2]. 통신 측면에서 보면 500 kbit의 데이터 전송 계층 개발은 한참 늦은 감이 있다. 유럽의 상용 차량 제조업체들은 가까운 미래에 최종 결정을 내리려 하고 있다. 사양은 J1939-14로 나뉘어 발표될 예정이다. 주요 내용은 다음과 같다.

- 두 배의 보드율(250 kbit가 아닌 500 kbit).
- [2] 및 [3]에 정의된 차폐 및 비차폐 케이블을 계속 사용 가능.
- 토폴로지는 최대 길이가 1 m인 분기 라인이 있는 버스. 진단 툴을 연결하기 위해서는 경우에 따라 길이가 5 m인 분기 라인(진단 소켓에서 진단 툴까지)을 사용할 수도 있음.
- 버스는 120 Ω의 특성 임피던스로 양쪽 모두에서 종단됨.

진단 플러그에 대한 사양[4]은 500 kbit 작동에 맞게 개정됐다. 또 녹색 컬러 코딩이 지정된 차량에 새로운 “유형 II(Type II)”의 진단 소켓이 사용되며 해당 커넥터 키 연결 방식으로 인해 이전의 250 kbit “유형 I(Type I)”의 진단 플러그는 사용할 수 없다. “유형 II”의 플러그는 “유형 I” 소켓과 호환된다. 또 다른 변화는 “유형 II” 진단 소켓에서 이전에 SAE J1708/J1587에 사용되던 핀을 예비용으로 지정한다는 점이다. 따라서 J1708/ J1587 네트워크는 더 이상 “유형 II”의 진단 플러그를 통해 주소를 지정할 수 없다.

동적 주소에 대한 SAE의 고민
네트워크 관리 영역에서도 변경된 부분이 있다[5]. 한 동안 J1939 위원회는 영구적으로 할당되는 ECU 주소(address)가 부족한 상황을 처리하는 방법에 대해 많은 논의를 해왔다. 특히 이는 버스에 직접 연결되는 센서를 제조하는 업체에 있어 문제가 됐다. 배기가스 규제 수준이 높아지고 보조 시스템이 추가됨에 따라 새로운 디바이스의 수가 급속히 증가하고, 이에 따라 센서를 위한 전용 네트워크에 새로운 프로토콜을 구현(예: 이전에 예약된 데이터 페이지 사용)하는 것에 이르기까지 많은 대안들이 제시되었지만 모두 거부돼 왔다. 이같은 상황이 지속되는 동안 SAE는 새로운 주소를 추가 할당하지 않았고, 이는 ECU 공급업체에게 만족스럽지 못한 상황으로 전개됐다. 또 공급업체들은 해당 제품 디자인이 영구적인 가치를 지니게 될 지 모르는 경우가 대부분이었다.
SAE는 최신 버전의 네트워크 관리(Network Management)에서 “AAC (Address Arbitrary Capable)” ECU를 구현하도록 권장하고 있다. 이러한 ECU는 순간적인 차량 구성(momentary vehicle configuration)을 통해 런타임에 고유한 주소를 계산할 수 있다. 이같은 접근방식은 본질적으로 상용 차량에서는 언제나 존재해왔지만, 실제로 구현되거나 사용된 적이 없는 동적 주소 할당 메커니즘을 활용하는 것을 목표로 하고 있다.
완벽성을 높이려면 네트워크 관리와 함께 새로 추가된 이름 관리(Name Management)도 언급해야 한다. 이는 64비트 디바이스 이름의 특정 컴포넌트를 변경하기 위한 표준화된 인터페이스다. 이 인터페이스는 관련 기능 또는 측정 파라미터가 디바이스 이름에서 파생되는 경우에 필요할 수 있다. 따라서 디바이스 이름을 사용해 이중 흐름(dual-flow) 배기 시스템의 왼쪽이나 오른쪽에서 배기가스 온도 센서(촉매 컨버터의 업스트림 또는 다운스트림)의 위치를 식별할 수 있다. 여러 ECU를 순서대로 변경해 특정 시점에 활성화할 수 있는데, 이는 네트워크의 여러 ECU에 새로운 기능을 동시에 할당해야 하는 경우 등에 유용할 수 있다.
벡터(Vector)의 CANalyzer.J1939 버전 7.5 분석 툴과 CANoe.J1939 개발 및 테스트 툴에서는 이같은 네트워크 관리의 변경사항을 모두 지원하고 있다.

더욱 가까워진 AUTOSAR와 J1939
승용차 업계의 AUTOSAR 도입은 빠른 속도로 진행되고 있다. 게다가 상용 차량 및 농기계 시장에서도 AUTOSAR의 이점을 활용하는 데 높은 관심이 나타나고 있는 상황이다.
그러나 이러한 시장의 특수한 요구사항은 AUTOSAR를 개발하는 데 있어 포커스 되고 있지 않다. 따라서 현재까지 발표된 AUTOSAR 버전은 매우 제한적이다. 특히 SAE J1939의 요구사항은 현재의 AUTOSAR 개념에 매핑 할 수 없거나 매핑 하더라도 상당히 제한적인 방식으로만 가능하다.
AUTOSAR의 “정적” 접근 방식은 J1939의 “동적” 동작과 대조를 이룬다. AUTOSAR 아키텍처에서는 고정된 CAN 식별자((Identifier)만 허용된다. 즉, 정확히 하나의 CAN 식별자와 하나의 메시지 레이아웃 사이로 할당이 고정돼 있다. 이와 반대로 J1939 관련 메시지 레이아웃은 파라미터 그룹(PG: Parameter Group)이라는 식별자의 특정 부분에만 할당된다. 29비트 식별자의 일부 다른 컴포넌트는 동적 특성을 나타내며 구성 시 정의되지 않는다. 이러한 동적 식별자는 네트워크에서 발생할 수 있는 각각의 우선순위 조합, 발신지 주소(Source Address, SA) 및 목적지 주소(Destimation Address, DA)에 대한 별도의 정적 식별자를 만드는 방식으로 AUTOSAR에서 모델링할 수 있다(그림 2).
J1939 네트워크의 모든 노드를 알고 있고 구성 시 노드 주소를 이미 정의한 상태라면 J1939 PG를 AUTOSAR에 매핑하기가 비교적 쉽다. 이같은 정적 네트워크에서는 ECU 주소가 고정되기 때문이다. 따라서 발신지 및 목적지 주소가 고정되기 때문에 정적 식별자를 통해 작동할 수 있게 된다.
CAN 프레임에서 사용할 수 있는 8바이트가 넘는 데이터를 전송하기 위해 J1939-21에서는 두 개의 전송 프로토콜(TP) 변형을 지정하고 있는데, 하나는 브로드캐스트 공지 메시지(BAM: Broadcast Announce Message)의 변형이고 다른 하나는 연결 모드 데이터 전송(CMDT: Connection Mode Data Transfer, RTS/CTS라고도 함)의 변형이다. 둘 모두 이미 AUTOSAR 릴리스 4.0에 정의됐으며 2009년 12월부터 지원됐다. 따라서 AUTOSAR 릴리스 4.0은 이미 유럽의 많은 상용 차량 제조업체의 요구사항을 수용하고 있는 셈이다.
2012년 말에는 AUTOSAR 4.1을 통해 J1939 요구사항을 보다 세부적으로 지원할 예정이다. 지원 대상에는 유럽 및 일부 북미 상용 차량 OEM이 포함된다. AUTOSAR에 추가될 향상된 주요 사양은 다음과 같다.

- 레이아웃이 동일한 여러 메시지 지원(동일한 파라미터 그룹)
- 동적 NM 없이(즉, AAC 없이) SAE J1939/81에 따라 네트워크 지원
- 요청 메시지에 대한 응답
- 진단 서비스 지원
- J1939를 통한 온보드 진단(WWH-OBD)

벡터는 유럽 상용 차량 OEM과 함께 AUTOSAR에 대한 이같은 J1939 확장 표준을 지정하려는 노력에 적극 참여하고 있다. 벡터는 이미 AUTOSAR 릴리스 4.0을 기반으로 하는 J1939 확장 표준이 적용된 AUTOSAR 솔루션을 선보였다(그림 3). 이 솔루션은 유럽의 한 대규모 상용 차량 OEM의 생산 환경에 적용될 예정이다. AUTOSAR 릴리스 4.1에 대한 확장 표준은 현재 개발 단계에 있다.

WWH-OBD를 사용하는
상용 차량 진단
온보드 진단(OBD)은 ISO에서 표준화한 진단 시스템으로, ODB의 응용 부문 중 하나는 배기가스 배출 제어와 관련된 시스템을 모니터링 하는 것이다. 시간이 지남에 따라 이 표준에서 여러 지역 표준(예: ISO 15031)이 파생됐으며 현재는 WWH-OBD(World-Wide-Harmonized On-Board-Diagnostics)로 다시 병합됐다. 이 표준은 UN(United Nations)에서 발의했으며 UN의 세계 기술 규정(GTR-5: Global Technical Regulation 5)에 문서화돼 있다. ISO 27145는 GTR 5를 기술적으로 구현한 것이며, WWH-OBD에 대한 기술 제약 사항을 정하고 있다. WWH-OBD는 처음에는 상용 차량 시장을 대상으로 했지만 결과적으로는 다른 차량 산업으로도 확장되고 있다.
ISO 27145는 6개 부분으로 구성돼 있다(그림 4). 현재의 문서는 “국제 표준 초안(DIS: Draft International Standard)”이며 최종안은 2011년 말로 예정돼 있다.
첫 번째 단계는 방출량 제어 및 진단 통신에 대한 요구사항을 정하는 일이다. 이를 위해 차량 측 구현, 데이터 액세스 및 OBD 데이터가 지정됐다. 여러 지역 기관에서는 여전히 제한 사항 및 임계값을 정의하는 중이다. 따라서 이후에도 조화가 이뤄지지 않을 전망이다.
현재 상용 차량의 온보드 진단을 위해 두 개의 CAN 기반 프로토콜인 “Diagnostics on CAN”(ISO 15765-4) 및 J1939-73이 광범위하게 사용되고 있다(그림 5). WWH-OBD로 경제적으로 전환할 수 있도록 처음에는 CAN을 통한 진단이 사용될 예정이다. 장기적으로는 이더넷을 통한 유선 또는 무선 액세스 기능을 구현하는 DoIP(Diagnostics over Internet Protocol)의 사용도 가능할 전망이다.
현재의 OBD-II 표준과 달리 WWH-OBD에서는 이미 ISO 14229 “DS(Unified Diagnostic Services)”로 정의된 서비스를 활용하고 있다. 추가로 필요한 OBD 관련 서비스는 없다. 특히 WWH-OBD에서는 그림 6에서처럼 UDS 서비스를 지원해야 한다.
2014년부터 새로 등록되는 모든 대형(Heavy-duty) 상용 차량이 Euro VI 표준을 따라야 하기 때문에 WWH-OBD 진단 기능을 갖춰야만 한다. 새로운 유형의 차량과 관련된 개발 업무에서는 이보다 1년 빠른 2013년 1월 1일부터 표준을 충족해야 한다.
UDS 진단 서비스는 J1939도 함께 지원하는 CANbedded 통신 소프트웨어를 통해 구현할 수 있다. 이러한 소프트웨어는 벡터에서 제공하며 많은 양산 구현을 통해 실제 환경에서 검증을 마친 상태다. 또한 최근에는 UDS를 통한 WWH-OBD 진단 기능을 구현하기 위해 양산 환경에 바로 사용 가능한 AUTOSAR 솔루션이 나오기도 했다.
J1939 영역에 기술된 개발사항에서는 이 표준이 어떤 식으로 현재의 요구사항에 맞게 지속적, 정기적으로 조정되고 있는지를 보여 준다. 승용차 기술 개념의 이전, 확장 및 수정 노력은 J1939 ECU 개발의 경제성을 높이는 데 목표를 두고 있다. 벡터는 수년간 축적한 네트워킹 관련 전문 기술을 통해 표준 위원회에 적극적으로 관여하며 꾸준히 기여하고 있다. 또한 상용 차량 전자 장치 개발자들은 임베디드 소프트웨어 및 개발 툴에 새로운 표준이 조기에 개발됨에 따라 혜택을 얻고 있다.

AEM_Automotive Electronics Magazine