글│볼프강 브란트슈태터 (Wolfgang Brandstatter) 칼스텐 뷔케(Carsten Boke)
    FlexRay 하드웨어, 프로토콜 개발팀 네트워크, 분산시스템 툴 개발 선임
    AUDI AG Vector Informatik GmbH

프레임-지향적인 FIBEX 2.x 데이터베이스 포맷이 발표됨에 따라 네트워크 노드들 간 PDU 통신 정의를 위해 새로운 디스크립션 시맨틱(description semantic)이 필요해졌다. 아우디는 이러한 간극을 극복하기 위해 FIBEX+ 디스크립션 시맨틱을 개발했다.
벡터는 자사의 툴을 통해 FIBEX+를 즉시 지원할 수 있었다. 아우디는 FIBEX+에 대한 경험을 얻는 동시에 ASAM(Association for Standardisation of Automation and Measuring Systems [1])의 새로운 FIBEX 3.0 표준에 PDU를 도입했다.
아우디의 지속적 피드백은 벡터의 엔지니어들이 툴 개발 초기 단계부터 중요한 PDU 기능들을 통합할 수 있게 도왔다. 아우디에는 CANoe 서비스 팩이 정기적으로 제공되었기 때문에 PDU 통신 스택을 사용한 ECU 테스트를 초기부터 할 수 있었다. 아우디는 최신 FIBEX+ 데이터베이스 버전을 벡터에 제공함으로써 CANoe와의 호환성을 계속해서 유지할 수 있도록 했다. CANoe를 이용한 지속적인 검증을 위해 아우디는 최신 FIBEX+ 데이터베이스 버전들을 벡터에 제공했다.
이같이 아우디와 벡터 간 긴밀한 협력 관계는 툴 개발 속도를 가속화하는 동시에 FIBEX+와 신형 FIBEX 3.0 기반의 FlexRay 네트워크를 위한 전문적인 분석과 플랫폼 개발을 가능하게 했다. 본고는 PDU가 FlexRay 개발 툴 CANoe.FlexRay의 내부 구조와 기능에 미친 영향과 아우디의 엔지니어들이 벡터의 적절한 툴 지원으로부터 얻은 효과에 대해 설명한다.

네트워크 분석을 위한 PDU 레이어

PDU는 하위 레벨의 신호(signal)들을 적절하게 배치한 상위 레벨의 통신 데이터 컨테이너, 즉 메시지로 정의할 수 있다. PDU는 CANoe와 같은 분석, 시뮬레이션, 테스트 기능을 지닌 툴들을 이용해 관리한다.
FlexRay 프레임은 복수의 PDU를 포함할 수 있다. 프레임의 레이아웃은 사이클에 따라 변화할 수 있기 때문에 동일한 PDU를 다양한 프레임으로 맵핑할 수 있다. PDU는 특정 사이클에서 특정 슬롯의 FlexRay 프레임 내 위치에 의해 개별적으로 식별된다. 벡터는 PDU 레이어를 통해 CANoe에서 PDU를 식별한다(그림 1). PDU 레이어는 PDU 객체들을 도입하고 버스와 사용자 인터페이스 사이에 각각 위치한다. 레이어는 적절한 데이터베이스(FIBEX+ 또는 FIBEX 3.0)를 CANoe에 할당함으로써 활성 또는 불능화 된다. 레이어가 활성화되면 데이터베이스를 기반으로한 완벽한 네트워크 통신 해석(PDU 명칭, 신호, 타이밍)이 PDU 레벨에서 수행된다.
PDU의 주요 특성은 업데이트 비트(Update Bit)에 의해 정의되며 네트워크상의 프레임 발생과는 분리돼 있다. 따라서 네트워크상의 프레임은 업데이트되거나 업데이트되지 않은 PDU를 동시에 포함할 수 있다. 업데이트 비트 값은 사전에 정의된 신호를 통해 시각화되거나 평가될 수 있다(즉 그래픽 창 이용, 그림 2). 간단한 분석 또는 시뮬레이션 기능을 위해 만일 수신된 PDU가 계속 업데이트되지 않는다면 이 PDU를 무시하는 것이 기본 기능이다. 하지만 상세한 분석의 경우, 업데이트되지 않은 PDU는 선택적으로 디스플레이 돼 시뮬레이션 노드로 전달될 수 있다. 뿐만 아니라 이들의 페이로드(payload)를 포함하는 FlexRay 프레임들은 디스플레이 되어 소위 로 프레임(Raw Frame)으로서 수신될 수 있다. 아우디는 통합 테스트를 진행할 때 이와 같은 PDU 기반 분석 기능을 많이 사용했다.

네트워크 시뮬레이션을 위한 PDU 레이어

FlexRay 프로토콜이 (심지어 업데이트 사항이 없는 경우에도) 주기적으로 전송될 프레임들을 정의함에도 불구하고 본래의 PDU는 이러한 특성을 가지고 있지 않다. PDU가 업데이트되지 않는 경우에 수신기는 일반적으로 PDU를 인식하지 않는다. 수신기를 주기적으로 트리거(trigger)하기 위해서 PDU는 반드시 주기적으로 업데이트되어야 한다. 분명히 데이터 업데이트가 없지만 업데이트 비트가 1로 설정되어 PDU의 자동 전송이 요구된다면 네트워크 설계자들은 이러한 PDU가 주기적인 타이밍을 가지도록 정의할 수 있다. 이런 이유에서 PDU 레이어의 최상위에 상호작용 레이어(Interaction Layer)를 개발해 제약요소들을 처리했다(그림 3).  FlexRay 프로토콜의 확장 기능으로써 PDU는 업데이트 비트가 1로 설정되면 (거의) 임의적인 주기로 전송되기도 한다.
아우디는 메시지 카운터와 체크섬(check sum)을 정의했는데 이것은 PDU의 선택적인 속성이다. 사실 PDU의 업데이트 비트, 메시지 카운터, 체크섬 등은 상호작용 레이어를 통해 CANoe의 애플리케이션에 상관없이 독립적으로 설정되기 때문에 나머지 버스 시뮬레이션 과정을 단순화시킨다. 따라서 엔지니어는 적절한 신호값을 설정하기만 하면 된다. 또 다른 사용 사례로는 ECU의 반응을 테스트하기 위해 나머지 버스 시뮬레이션 과정에 명확한 고장 사항들을 삽입하는 것이다. 따라서 CANoe 자동 기능은 모두 사용할 수 없고 상호작용 레이어가 고장 유발 수단으로 사용될 수 있다.
ECU와의 통신 기능을 시뮬레이션하는 것은 특정 이벤트의 발생에 의해 좌우된다(이벤트 기반 시뮬레이션). 가장 중요한 이벤트 중의 하나는 메시지 수신 또는 신호값 변경 등이다. 이와 같이 PDU 수신 및 신호 변화를 알려주는 공지 핸들러(notification handler)는 PDU 레이어에 의해 트리거된다.