글│알렉산더 레온하디(Alexander Leonhardi) alexander.leonhardi@daimler.com,
    안드리아 발렌틴(Andreas Vallentin) andreas.vallentin@daimler.com,   
    토스덴 포(Torsten Pech) torsten.pech@daimler.com
    Daimler AG

차량용 내비게이션, 엔터테인먼트, 통신 기능을 제공하는 고급 자동차 인포테인먼트 시스템은 분산 시스템 구조로 돼 있다. MOST 버스를 통해 분산 연결된 디바이스 사이에는 제어 명령, 오디오/비디오, 그리고 정보 항목(예, 웹 열람 서비스를 위한 IP 기반의 데이터)이 전송된다. 예들 들면 헤드유닛은 운전자를 위한 사용자 영역(User Interface, UI), 헤드유닛에 의해 제어되는 위성 라디오나 모바일 멀티미디어 재생기를 연결해 주는 게이트웨이 같은 여러 가지 주변 디바이스들로 구성된다.
일반적으로 자동차 인포테인먼트 시스템은 안전에 결정적이지 않다. 그러나 애플리케이션은 고도의 쌍방향 통신을 요구한다. 일례로 모바일 멀티미디어 재생기의 음악 타이틀을 검색하는 경우, 메시지 손실과 같은 에러는 사용자를 당황케 하는 원인이 될 수 있다. 예를 들어 기능 실행을 지연시키거나, 잘못된 정보를 표시하거나, 애플리케이션이 정지할 때까지 확실한 기능들을 이용할 수 없게 된다. 그러므로 차량용 시스템의 에러 처리는 사용자에게 제공되는 기능의 적절한 응답을 확인하는 데 대부분 집중되고 있다. 효율적인 에러 처리는 시스템 품질에 상당한 영향을 미친다. 또한 통신 네트워크의 실패로 인한 갑작스런 심한 소음이 운전자의 주의를 분산시킬 수 있다는 점에서 오디오 신호를 다룰 경우에는 에러 처리가 안전과 관계가 있다. 에러 처리는 운전자 보조 시스템이나 인포테인먼트 시스템이 통합되는 현 추이로 미뤄 볼 때 향후 더욱 중요해질 것이다.
에러 처리는 안전이 중요한 시스템, 데이터의 일관성이 보장되어야 하는 데이터베이스 시스템, 그리고 분산 알고리즘에서 광범위하게 논의돼 왔다(예, [7]). 이러한 메커니즘은 일반적으로 하드웨어 지원 또는 통신 증가나 의미 있는 요구사항을 처리할 것을 요구한다. 에러 처리 전략을 기술할 때 애플리케이션 영역과 통신 네트워크의 고유 특성을 고려하는 것이 중요하다.
데이터 링크 계층을 포함해서 구체적인 물리 계층을 구성하는 MOST 버스의 특징과 아울러, MOST 버스를 위한 명확한 속성의 드라이버, NetServices[4], 그리고 MOST 표준도 구문과 의미론(예, 통지 처리 서비스)을 명확히 정의하고 애플리케이션 계층을 상세히 기술하고 있기 때문에, 적절한 시스템-와이드(system-wide) 에러 처리 전략은 MOST 애플리케이션 프레임워크의 중요한 측면이다.
이 글에서는 MOST 시스템에서 발생할 수 있는 다양한 종류의 에러에 대해 논의할 것이며, 에러의 원인과 있을법한 에러를 기반으로 분류와 등급을 제안한다. 이어서 이 분류에 의거해서 검증된 일반적인 에러 검출과 에러를 복구하기 위한 첫 번째 메커니즘, 그리고 복구할 수 없는 에러 처리를 위한 두 번째 메커니즘을 정의하는 에러 처리 전략을 기술한다.
에러 처리 논의는 기존의 시스템과 경험에 의거해야 하므로, 이 글의 논의는 MOST25와 그 광 물리 계층에 국한한다. 또한 지면 관계상 디바이스 연결 처리와 MOST 고차원 프로토콜(MOST High Protocol)[1]에 대한 특정 에러 처리 전략에 대해서는 논의하지 않는다.

 MOST 시스템에서 에러 원인

MOST 시스템에서 에러는 다양한 문제를 일으킴으로 반드시 검출해야 하며, MOST 디바이스의 각 계층에서 처리돼야 한다. 에러 처리에 대한 논의를 위해 MOST 디바이스의 다음 3계층 모델을 이용한다(그림 1 참조).
MOST 디바이스의 애플리케이션 계층에서 동작하는 애플리케이션은 MOST NetServices를 포함하는 네트워크 계층을 통해 그들의 요청을 물리 계층으로 전달하며, 물리 계층은 이 요청을 MOST 버스로 보낸다. 요청에 대한 응답은 물리 계층을 통해 MOST 버스로부터 읽혀지고 네트워크 계층을 통해 애플리케이션 계층으로 보내진다.
다음은 MOST 시스템에서 일어나는 가장 일반적인 에러들이다.

● 메시지 손실: 메시지 손실은 MOST 디바이스의 수신 버퍼가 가득 찼을 때 드물게 발생한다. OS8104 네트워크 인터페이스 컨트롤러 NIC[5] 또는 그 후속 버전인 OS81050 INIC[6]의 단일 수신 버퍼로 인해 수신 디바이스가 현재 수신 버퍼로부터 읽을 수 있는 것보다 빠르게 하나 이상의 디바이스가 메시지를 전송한다면 단일 메시지 손실은 흔하게 발생한다. 그러므로 디바이스에 높은 통신 부하가 걸리면 다중 메시지 손실도 역시 흔하게 발생한다. 더 나아가 메시지 손실은 애플리케이션 계층의 높은 부하나 또는 통신 스택의 상위 계층에서의 에러가 원인이 될 수 있다.
● 전송 에러: 물리적 네트워크에서 비트 에러는 상위 계층에서 메시지 손상의 원인이 될 수 있다. 그러나 MOST 버스의 광 물리 계층으로 인해 비트 에러는 매우 드물게 발생한다[단, 시스템 초기 동작(Start-up) 같은 불안정한 상태는 제외]
● 통신 중단: MOST 버스에서 잠금 해제(Unlock)는 통신 중단의 원인이 된다. 잠금 해제는 특별히 디바이스의 초기 동작중에 아주 흔하게 나타난다(예, 크랭킹 동작중). 상위 계층에서 잠금 해제는 갑작스런 메시지 손실로 감지된다.
● 시스템 환경 설정 에러: MOST 시스템의 바이패스 개폐에 의해 참여하고 떠나는 디바이스는 시스템 환경 설정에서 변화의 원인이 된다. 이를 MPR-event라고 한다. MPR-event가 검출되고 처리되기 전까지, 통신 파트너가 준비되지 않았을 경우 시스템 환경 변화는 남겨진 디바이스에 의해 다른 종류의 에러로 감지된다. 환경 설정 변화는 매우 드물게 발생한다. 예를 들면 시스템의 크랭킹 동작시 전압 강하는 몇몇 디바이스의 초기화를 야기하는 반면, 다른 디바이스는 지속적으로 동작한다.
● 디바이스 기능들의 비유효성: 높은 처리 부하, 외부 시스템의 문제 또는 디바이스 특정 에러로 인해 사용자가 요구하는 실행에 필요한 디바이스 기능이 현재 이용 불가능할 수 있다. 이러한 에러 가능성은 특히 디바이스 유형에 관련이 있다. 이들 에러는 제어 채널 상에서 적절한 에러 응답에 의해 나타나야 하고 애플리케이션 계층에서 처리되어야 한다.
● 메시지 순서 에러와 중복 에러: 이러한 에러들은 주로 에러 복구 메커니즘(예, 재시도-Retries) 자체가 원인이다. 단일 전송 큐를 지원하는 NetServices 구조로 인해 이러한 에러들은 애플리케이션 계층 재시도를 사용하지 않을 경우에 약간 드물게 나타나며 피해갈 수도 있다. 그러나 메시지 순서 에러(sequence error)는 애플리케이션 메시지와 시스템 환경 설정 상태 메시지와 같은 경우처럼 메시지가 디바이스에서 다양한 인스턴스에 의해 처리되면 발생할 수 있다.
● 디바이스 고장과 구현 에러: 다른 종류의 에러들은 디바이스 고장과 디바이스가 잘못된 에러 메시지를 보내는 것과 같은 구현 실수에 의해 나타날 수 있다. 이러한 에러들은 시스템 통합과 평가중에 발생하며 제품 생산 준비 이전에 수정돼야 한다. 차량의 시스템 통합 단계에서 어느 정도의 에러 처리 목표를 둘 것인지는 시스템 통합 설계자가 결정해야 한다.

유감스럽게도 에러의 원인은 그 증상에 의해서만 알 수 있다. 따라서 에러 원인은 경험을 바탕으로 한 추측에 의존할 수밖에 없다. 일부 에러는 아예 검출되지 않을 수도 있다.