글│옌스 쾨츠 (Jens Koetz) * 칼스텐 바이히 (Carsten Weich) **
    차량 네트워킹 및 에너지시스템 차량소프트웨어 팀장
    책임연구원, AUDI AG TTTech Automotive GmbH

차량용 네트워크에서 보다 높은 데이터 통신 대역 요구가 증가하면서 FlexRay가 등장했다. FlexRay는 차량의 리얼타임 통신을 구현하는 사실상의 새 표준 규격으로 사이클 기반 통신과 Time-triggered 통신에 근거해 초당 10 M bit/s에 이르는 데이터 전송량과 하드 리얼타임 통신능력을 갖는다. 또 미리 정해진 시점에서 통신할 수 있도록 정의하는 오프라인 스케줄링 방식으로 방대하고 복잡한 실시간 네트워크의 통합을 보다 쉽게 구현할 수 있게 한다. FlexRay 네트워크는 차량용 High-speed CAN 네트워크 보다 20배 많은 데이터를 전송함으로써 FlexRay 통신 컨트롤러는 입출력 데이터 프레임을 수용하기 위해 CAN 컨트롤러 보다 현저히 높은 버퍼 메모리를 제공한다. FlexRay 컨트롤러는 일반적으로(혹은 DMA Access를 사용해서) 수 천 바이트의 버퍼 메모리를 제공한다.
AUTOSAR는 ECU 내에서 FlexRay 통신을 잘 관리하기 위한 통신 계층을 정의하고 있다. 이것은 높은 수준의 신호 관리를 위한 COM 계층, 대용량의 데이터 패킷을 다루기 위한 TP 계층에서부터 리얼 타임 인터페이스를 관리하기 위한 FlexRay Interface 계층과 FlexRay Driver 계층 및 하드웨어 추상 계층 등을 포함한다.
이글은 어떻게 하면 ECU에 의해 송수신되는 통신 프레임에 FlexRay 버퍼 메모리를 효율적으로 할당할 것인지, 또 통신 버퍼에 접근하는 것이 CPU에 다소의 작업을 생성한다는 점을 고려할때 이것이 CPU 부하에 어떤 영향을 미치는가에 대해 알아본다.

효율적인 할당에의 도전

전화 서비스 점에서 고객들을 위해 10개의 전화 부스를 설치했고 그 전화기에 고객들을 할당할 수 있다고 하자. 고객들은 그 곳에서 전화를 걸어 “송신”할 수 있고, 또 걸려오는 전화를 “수신” 할 수 있다. 이 때 이 전화 부스 사용이 효율적인지 어떻게 확신할 수가 있을까?
고객들의 특성을 잘 알고 있다면 다음과 같이 미리 계획해 볼 수 있다. 특별히 중요한 고객들을 위해 독점적으로 사용할 수 있는 전화 부스를 준비해 두고, 이 고객들이 언제든지 전화를 사용할 수 있도록 예약해 놓을 수 있다. 어떤 고객들은 통상적으로 몇 분의 짧은 통화를 한다고 하면 이와 같은 부가적인 정보나 “제약조건”으로 전화 부스를 고객별로 할당함으로써 효율적인 전략을 세울 수 있다.
이상과 같은 예는 복잡한 실시간 네트워크를 어떻게 풀어가야 할 것인지를 잘 설명해 주고 있다: 즉, 제한된 수량의 버퍼(전화 부스)와 ECU의 FlexRay 통신 컨트롤러(점포)에 의해서 송신되거나 수신되는 다량의 통신 프레임들(고객들)이 있다면, 버퍼(전화 부스)들이 프레임(고객)에 잘 할당돼야 정보의 유실이 없고(수신 중 버퍼의 여유가 없을 경우 정보의 유실이 발생) 또 과도하게 지연되지 않는다(전송이 이뤄져야 할 때에 만약 가용 버퍼가 없으면 지연이 발생).

AUTOSAR의 최적화 목표

추가적인 제약조건은 AUTOSAR가 FlexRay 통신을 어떻게 다루느냐와 관련된다. FlexRay 버퍼 접근을 다루는 FlexRay Interface 계층(FrIf)은 미리 예정된 시간에 예정된 활동(job), 즉 데이터의 팩킹이나 언팩킹을 수행하는 소프트웨어 계층이다. 이는 마치 전화 서비스 점의 지배인과도 같다. 이는 고객을 전화부스에 할당하기 위해 필요한 오버헤드를 가지고 있는데, 만약에 전화 부스가 많이 있고, 또한 고객의 숫자도 많을 경우 한 번에 여러 개의 할당이 동시에 이뤄질 수 있다면 더욱 효율적일 것이다.
이러한 활동은 ECU 내에서 task activation에 상응한다. FrIf가 각각의 job에 activation 된다면(즉, PDU의 송수신), CPU 시간의 상당 부분이 FrIf activation에 쓰인다. 따라서 이러한 job들을 하나의 그룹으로 묶을 수 있다면 오버헤드를 상당히 줄일 수 있다.
FlexRay 통신 컨트롤러는 하드웨어나 메시지의 크기에 따라 수십 개 혹은 수백 개의 버퍼를 제공한다. 그러나 수천 개 혹은 수만 개의 FlexRay 프레임이 이 노드에서 전송되거나 수신될 수도 있다. 이는 전혀 가능성 없는 시나리오가 아니다: Gateway 등과 같은 ECU들은 한 네트워크 내에서 매우 많은 프레임들을 보내고 받을 필요가 있다. 그리고 일반적으로 중요한 FlexRay 시스템은 수백 개의 서로 다른 프레임을 주고받는다.
이와 같은 수많은 프레임(즉 “정적 프레임”)들을 위해 빈도나 위상 그리고 순서 등이 FlexRay 스케줄로부터 정확하게 알려져야 하는 반면에 여타의 프레임(즉, “동적 프레임”)들에서는 반드시 그렇지는 않다. 비록 많은 양의 통신 버퍼를 가지고서도, 현저하게 많은 데이터를 송신하고 수신하는 AUTOSAR 환경설정을 구현할 때, 적절하게 버퍼를 할당하는 것은 결코 쉬운 일이 아니다. 위에서 설명한 바와 같이 이러한 도전은 버퍼의 위치를 결정함에 있어 버퍼의 효율을 높이고, 모든 프레임이 제때 송수신되도록 하며, 또한 FrIf의 activation으로 발생하는 CPU 부하가 적정한 최저 수준을 유지하는 것이다.

버퍼 할당에 있어서
몇 가지 가능성

버퍼 할당 목적은 메시지 버퍼를 슬롯과 채널에 할당하고 버퍼의 방향(송신 혹은 수신)을 정하며, 사이클(주기) 카운터 필터링을 정의하는 것이다: CAN과 같이 FlexRay 통신 버퍼를 식별자나 식별자 범위로 정의된 프레임만 받도록 할 수 있다(즉, “frame ID 3 수신” 혹은 “0x10과 0x1F 범위의 frame ID들을 수신”).
FlexRay 통신은 64개의 통신 사이클로 구성돼 있으며, 필터링 역시 이들 사이클을 참조할 수 있다(즉, “모든 통신 사이클에서 프레임 3 수신” 혹은 “통신 사이클 20에서 프레임 3 수신”).
FlexRay Interface 계층을 고려하지 않을 경우에 노드에 의해서 송수신되는 매 프레임을 위한 버퍼를 할당하는 것은 보다 쉬운 일이다: 이 경우 하나의 버퍼는 그 슬롯에서 수신된 프레임과는 무관하게 각 슬롯에 할당할 수 있다. 이에 따라 그 버퍼는 각 통신 사이클 마다 읽혀져야 하고, 버퍼 수는 통신 클러스터에서의 노드들의 상한치가 된다. 이는 하나의 버퍼는 하나 이상의 슬롯에 할당되지 못하기 때문이다. 이것은 제약조건들을 상당히 완화시켜 준다: 수백 개의 프레임을 다룰지 모르지만 단지 수십 개의 슬롯과 버퍼는 이런 전략을 만족시키기에 충분하다. 하지만 이것이 항상 가능할까?
유효 범위(Validity Spans)와FrIf Jobs

아래의 보기는 버퍼 할당이 어떻게 CPU 부하와 관련해 최적의 FlexRay Interface 계층의 환경설정을 지원할 수 있는지를 설명한다. 예제로 8개의 사이클과 8개의 정적 슬롯으로 구성된 단일 채널의 FlexRay 스케줄을 보기로 들어 보자. 그림 1에서 보는 바와 같이 이 슬롯(Slot 2)에 전송되는 2개의 PDU가 있다 - 처음(green PDU) 것은 매 홀수 사이클마다 전송되는 것이고, 그 다음(blue PDU) 것은 짝수 사이클마다 전송되는 것이다. 근본적으로 송신(혹은 수신)을 위한 하나의 정적 슬롯의 모든 프레임들은 하나의 버퍼를 공유한다. 이같은 접근의 단점은 PDU들을 저장된 메모리로부터 복사해 송신(혹은 수신의 경우)을 하기위한 컨트롤 버퍼에 입력시키기 위해서 한 FlexRay Interface Interrupt가 매 통신 사이클마다 발생돼야 한다는 것이다.
만약 실시간 제약조건이라면, 매 2 사이클마다 한 FlexRay Interface Interrupt로도 충분하다. 이를 위해서는 반드시 2개의 버퍼가 사용돼야 하고, FlexRay 컨트롤러 설정(configuration)은 언제(즉, 어떤 슬롯과 어떤 사이클에서) 그리고 어떤 버퍼가 보내져야 하는지를 명시해야 한다. 이와 같은 “사이클 필터링” 설정은 “베이스 사이클” 파라미터와(첫 송신은 64 사이클 중의 N 사이클에서 이뤄진다) 각 버퍼를 위한 “반복 사이클” 파라미터(송신은 64 사이클 중에서 매 N 사이클마다 다시 이뤄진다)에 의해서 조건 되어 진다. 하나의 FlexRay Interface job은 이제 2개의 PDU들을 해당 버퍼에 복사하는 매 홀수 사이클의 시작과 더불어 실행된다.
이 예제의 설정에서 이들 2개의 버퍼 “유효 범위”는 “2 사이클”이다. 각각의 버퍼는 FlexRay 컨트롤러에 의해 송신이 이뤄지기 전에 이 2 사이클 사이에 업데이트될 수 있고, 그러기 위해서 새로운 데이터가 제공될 필요가 있다. 넓은 유효 범위 안에서 버퍼를 활용하기 위한 FrIf job 스케줄을 계산하는 일은 비교적 쉬운 일이며, 이는 마치 빨리 움직이는 회전목마 보다 천천히 움직이는 목마를 타기가 훨씬 수월한 것과 같은 이치다. 또한 보다 넓은 유효 범위는 항상 보다 많은 FrIf job이 그룹화 될 수 있음을 의미하며 결과적으로 FrIf activation이나 context 전환을 위한 CPU의 사용량을 낮추는 효과를 불러온다.