AUTOSAR : 입출력 변수의 형태 및 정의

AUTOSAR 스터디 2편입니다. 앞선 절에서 Compostion component에 대해 알아 봤다면, 본 포스팅에서는 Component 입출력 변수에 대해 작성했습니다. 이외에도 입출력 변수의 형태 및 종류에 대해서도 작성 해봤스니다.

AUTOSAR 입출력 변수의 정의

AUTOSAR에서 결국 기능에 따른 composition component or component에 대한 정의가 되면 다음 스텝으로 해야 할 일이 있습니다. 뻔하지만 입출력에 대한 정의가 필요 합니다. 크기 입출력 형태의 정의는 R-PORT와 P-PORT로 정리 할 수 있습니다. 만양 CoreCtrl이 Component이고, 외부 컴포넌트로 받아오는 변수가 In_VehicleSpeed, 보내는 변수가 Out_ClampingFore, 외부 파라미터를 받아서 내부 Component의 calibration을 수행하는 변수가 Brake Offset 이라면, 다음과 같이 하이라키 구조로 설명 할 수 있다.

+ COMPONENT: CoreCtrl

├── R-Port: In_VehicleSpeed (VehicleSpeed_IF)

├── P-Port: Out_ClampingForce (ClampingForce_IF)

└── PARAMETER: BrakeOffset (float, default: 10.0)

결국 외부 와의 연결을 정의하는 형태이기 때문에 Port로 정의 되는 것을 확인 할 수 있으며, 인터페이스의 역할은 다음과 같이 사전적인 정의를 할 수 있다.

SENDER-RECEIVER-INTERFACE

데이터의 계약서 역할
데이터의 이름, 타입, 의미, 단위, CompuMethod 등을 정의 함
어떤 데이터가 오가야 하는지를 정의할 뿐, 누가 보내는지/받는지는 모름
추상적인 인터페이스 정의

개인적으로 3번째 항목에 있는 누가 보낸 줄 모르기 때문에 한 참을 고생했습니다. 회사에서는 상용 툴인 IBM Rhapsody, Vector davinci 를 이용해서 전체적인 Sender와 Reiceive에 대한 구조를 쉽게 잡을 수 있습니다. 사실 요구사항 분석도 하고 코드도 생성하고 많은 부분들을 해당 툴로 할 수 있지만, 대부분 한정적으로 사용 할 것으로 생각 됩니다. 특히 IBM Rhapsody는 custom 하게 PJT를 생성할 수 있습니다만, 오히려 잘 못 된 사용으로 랩소디 자체를 불안정하게 만들 수 있습니다. 랩소드가 그렇게까지 무거운 SW가 아닌데, 키기만하면 꺼진다 던지 일부 버젼에서 이슈가 생겨 패치를 꼭 해줘야 하는 단점도 있습니다. 그러나 전체 P, R port 정의와 연결 외에도 강력한 기능들이 많아 사용 할 수 밖에 없는 툴이라고 생각이 듭니다.

P-Port / R-Port (Provide / Require Port)

SW-C 내부에서 실제로 이 데이터를 주고받는 출입구(Port)
각 포트는 어떤 인터페이스(S-R Interface)를 사용하는지를 지정함
실제 데이터가 흐르는 방향(제공 or 수신)을 정의

개인적으로 회의에서 용어들을 못 알아 듣다 보니, 좀 더쉽게 정리하는 방법을 찾게 되었고 다음과 같이 개념 정리를 했습니다.

개념	역할	비유
SENDER-RECEIVER-INTERFACE	데이터 내용 정의 (무엇을 주고받을지)	계약서 / 약속된 데이터 명세서
P-Port	이 인터페이스의 데이터를 제공하는 출구	송신 측의 포트 (보내는 문)
R-Port	이 인터페이스의 데이터를 요구하는 입구	수신 측의 포트 (받는 문)

그렇다면, 앞서 말씀 드린 내용을 arxml 파일로 작성하게 되면 어떤 형태로 생성이 될까요? 구조상 정리하면, Component를 정의하고, 1. Sender-Receiver를 정리 2. Parameter 정의 한다고 보시면 됩니다. 이 후에 P, R Port를 정리하면 됩니다.

<AR-PACKAGES>

<AR-PACKAGE>

<SHORT-NAME>MyComponents</SHORT-NAME>

<SENDER-RECEIVER-INTERFACE>

<SHORT-NAME>VehicleSpeed_IF</SHORT-NAME>

<DATA-ELEMENTS>

<VARIABLE-DATA-PROTOTYPE>

<SHORT-NAME>VehicleSpeed</SHORT-NAME>

<TYPE-TREF DEST="APPLICATION-DATA-TYPE">uint16</TYPE-TREF>

</VARIABLE-DATA-PROTOTYPE>

</DATA-ELEMENTS>

</SENDER-RECEIVER-INTERFACE>

실제 코드를 봐도 어느 component에서 만들었는지 어디서 왔는지 알 수가 없습니다. 여기서 하나 또 확인해야하는 사항은 APPLICATION DATA TYPE 입니다. 해당 부분도 한번 찾아서 어떤 식으로 사용 되는지 확인해 보겠습니다.

<SENDER-RECEIVER-INTERFACE>

<SHORT-NAME>ClampingForce_IF</SHORT-NAME>

<DATA-ELEMENTS>

<VARIABLE-DATA-PROTOTYPE>

<SHORT-NAME>ClampingForce</SHORT-NAME>

<TYPE-TREF DEST="APPLICATION-DATA-TYPE">uint16</TYPE-TREF>

</VARIABLE-DATA-PROTOTYPE>

</DATA-ELEMENTS>

</SENDER-RECEIVER-INTERFACE>

<PARAMETER-DATA-PROTOTYPE>

<SHORT-NAME>BrakeOffset</SHORT-NAME>

<TYPE-TREF DEST="APPLICATION-DATA-TYPE">float32</TYPE-TREF>

<VALUE-SPECIFICATIONS>

<NUMERICAL-VALUE-SPECIFICATION>

</NUMERICAL-VALUE-SPECIFICATION>

</VALUE-SPECIFICATIONS>

</PARAMETER-DATA-PROTOTYPE>

<APPLICATION-SW-COMPONENT-TYPE>

<SHORT-NAME>CoreCtrl</SHORT-NAME>

<PORTS>

<REQUIRED-PORT-PROTOTYPE>

<SHORT-NAME>In_VehicleSpeed</SHORT-NAME>

<REQUIRED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">VehicleSpeed_IF</REQUIRED-INTERFACE-TREF>

</REQUIRED-PORT-PROTOTYPE>

<PROVIDED-PORT-PROTOTYPE>

<SHORT-NAME>Out_ClampingForce</SHORT-NAME>

<PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">ClampingForce_IF</PROVIDED-INTERFACE-TREF>

</PROVIDED-PORT-PROTOTYPE>

</PORTS>

<INTERNAL-BEHAVIOR>

<SHORT-NAME>CoreCtrl_Behavior</SHORT-NAME>

<PARAMETER-DATA-PROTOTYPE>

<SHORT-NAME>BrakeOffset</SHORT-NAME>

<TYPE-TREF DEST="APPLICATION-DATA-TYPE">float32</TYPE-TREF>

</PARAMETER-DATA-PROTOTYPE>

</PARAMETERS>

</INTERNAL-BEHAVIOR>

</APPLICATION-SW-COMPONENT-TYPE>

</ELEMENTS>

</AR-PACKAGE>

</AR-PACKAGES>

</AUTOSAR>

여기서 또 궁금한 부분이 생길 수 있습니다. 개인적으로 Application data type이라고는 작성 되어 있으나, 실제 ECU에서 바라보는 변수능 어떤의미일까요?

AUTOSAR : 변수 정의

변수에 대한 정의는 크게 component application, implementation data type 으로 나눌 수 있습니다.

Application Data Type (ADT)

- 용도 : ADT는 일반적으로 RTE를 통해 소프트웨어 컴포넌트 간에 주고받는 데이터 타입을 정의할 때 사용됨

- 사용 목적: 애플리케이션 계층의 의미적 데이터 표현

- 예시: Speed_kph, Temperature_degC

- 구성 요소 : **Base Type (ImplDT)**에 대한 mapping : 물리적인 범위 (min, max), 단위, 해상도 등 추가 의미 포함

Implementation Data Type (ImplDT)

- 용도 : AUTOSAR XML(ARXML)에서는 <IMPLEMENTATION-DATA-TYPE>으로 정의됨

- 사용 목적: 구체적인 데이터 표현 및 메모리 표현 정의

- 예시: uint8, sint16, float32, boolean 등

- 구현 세부정보 : 비트 길이 (8, 16, 32 등)

실제 코드를 살펴 보면 다음과 같이 생성 할 수 있습니다.

<APPLICATION-DATA-TYPE>

<SHORT-NAME>Speed_kph</SHORT-NAME>

<BASE-TYPE>uint16</BASE-TYPE>

</APPLICATION-DATA-TYPE>

<IMPLEMENTATION-DATA-TYPE>

<SHORT-NAME>uint16</SHORT-NAME>

<CATEGORY>VALUE</CATEGORY>

<BASE-TYPE>

<SHORT-NAME>uint16</SHORT-NAME>

<BASE-TYPE-SIZE>16</BASE-TYPE-SIZE>

<BASE-TYPE-ENCODING>UNSIGNED</BASE-TYPE-ENCODING>

</BASE-TYPE>

</IMPLEMENTATION-DATA-TYPE>

여기서 또 집고 넘어가량 할 부분이 있습니다. AUTOSAR 자체가 어찌 보면 Reuse를 목표로 설계 되었는데, 변수 형태도 모르니 재활용이 가능할까요? 그래서 다음 절에서 어떻게 변수에 대한 정의와 스케일링이 어떻게 되는지에 대해 실전 사례로 정리했습니다.

항목	값 예시
신호명	WheelSpeed
단위	km/h (또는 rad/s 등 목적에 따라 변경 가능)
해상도 (Resolution)	0.125 단위 per 1 LSB
ImplDT	uint16
물리값 계산	물리값 = Raw값 × 0.125

<COMPU-RATIONAL-COEFFS>

<COMPU-NUMERATOR>

<V>scale</V>

<V>offset</V>

</COMPU-NUMERATOR>

<COMPU-DENOMINATOR>

</COMPU-DENOMINATOR>

</COMPU-RATIONAL-COEFFS>

위의 내용을 물리적인 형태로 바꿔서 해석을 하면 다음과 같이 표현 할 수 있습니다.

PhysicalValue = (scale / denominator) × RawValue + offset

<COMPU-NUMERATOR>

</COMPU-NUMERATOR>

<COMPU-DENOMINATOR>

</COMPU-DENOMINATOR>

PhysicalValue = (125 / 1000) × Raw + 0

→ PhysicalValue = 0.125 × Raw

마지막으로 주의해야하는 경우가 있습니다. 저도 해결은 못했습니다. Scale과 Offset의 순서가 변경 된 경우가 있습니다. 실제 생성된 코드에는 적합한 코드가 생성 되지만, 스케일은 늘 휴먼 에러의 발생 가능성이 높은 분야 입니다.

마무리

개인적인 공부 자료다 보니, 체계가 없습니다. 그래도 나름 이해한 방향으로 작성하고 있으니, 참조 부탁 드리겠습니다.

AI