[AUTOSAR VFB]제8화 AUTOSAR Service

이전 화에서는 Hardware와 Interaction에 대하여 살펴보았습니다. 이번 화에서는 AUTOSAR Service에 대하여 살펴보겠습니다.

 

AUTOSAR Service에 대하여 이야기를 할 때, 가장 쉽게 정의 하면 BSW에 미리 정의된 기능이라고 할 수 있습니다. 실제 VFB에서 AUTOSAR Service를 이야기를 하는 것은, Application 영역에서 이 AUTOSAR Service를 이용하기 때문입니다.

이러한 AUTOSAR Service는 다음과 같습니다.

1. NVRAM Manager – NvM

2. Communication Manager – ComM

3. Diagnostic Communication Manager – Dcm

4. Diagnostic Event Manager – Dem

5. Function Inhibition Manager – Fim

6. ECU State Manager – EcuM

7. Watchdog Manager – WdgM

8. Development Error Tracer – DET

9. Crypto Service Manager – Csm

 

실제 이러한 AUTOSAR Service에 대한 설정 및 모델링 할 때 다음과 같은 부분에 대하여 고려 해야합니다.

• Communication paradigm
• RTE에 정의된 선행 조건의 이행
• Platform dependent types

 

그러면 Communication Mechanism에 대하여 살펴보겠습니다.

주로 크게 2가지 형태의 Communication이 존재합니다. 하나는 Client-Server이고 나머지는 Sender-Receiver입니다.

실제 Clint-Server Interface을 사용한 통신을 할 경우, 라이브러리 호출을 통한 데이터 값의 취득이라고 생각하시면 됩니다. 즉, 즉각적인 결과가 뒤따라야 합니다.

 

하지만, Sender-Receiver Interface를 사용하는 경우에는 즉각적인 결과 값을 요구하지 않는 경우에 사용됩니다. 그리고 VFB에서 AUTOSAR Component를 사용할 경우, 각 Interface에서 IsService 부분에 대하여 설정을 해야합니다.

• ASW에서 AUTOSAR Service를 사용할 경우 - IsService = true

 

실제, System설계를 하고, 그 이후에 관련된 SWC와 AUTOSAR Service와 연동을 하기 위해서는 반드시, 같은 ECU안에서 존재해야 합니다. 실제 이러한 부분을 초월하기 위해서는 Service Proxy Component를 사용합니다.

 

Service Proxy SWC는 실제 Application SWC와 유사한 Atomic 성질을 가지고 있습니다. 단, 이 부분이 System설계 후, 각 ECU 단위로 쪼개질 때 다음 그림과 같이 분리가 됩니다.

단 각 SWC는 Proxy와 통신을 하고, 이 부분을 ECU에 Service와 1:1로 맵핑 되게 보입니다. 하지만, 실제로는 1:N형태로 연결이 되게 됩니다. 앞서 Software Component에서 관련 이야기를 드렸습니다.

 

이번화에서는 AUTOSAR Service에 대하여 간단하게 살펴보았습니다. 다음 화에서는 Model Management에 대하여 살펴보도록 하겠습니다.