본문 바로가기
자동차 임베디드 SW/Adaptive Autosar

Adaptive Autosar 기초 개념 정리(2) EM과 Function Group State

by 존버매니아.임베디드 개발자 2024. 7. 8.
반응형

Adaptive Autosar - 기초 핵심 정리 (1) (tistory.com)

위 글에 이어서 작성하는 내용입니다.

 

앞장에서 Application SW의 개념을 알아봤는데,

이번에는 Application SW가 Adaptive Autosar에서 어떻게 실행되고 종료되는지 전체적인 과정을 알아보자.

 

핵심 용어 정리

▶Function Group 과 Function Group State 그리고 Process의 실행

 설명 주저리주저리 쓰는거보다 아래 그림으로 표현하는게 이해가 쉬울 것이다.

Adaptive Autosar에서 Process가 실행되는 조건은, 해당 Process가 Mapping된 Functional Group State 로

State가 천이됐을때 이다.

예를 들어, 위 예시에서 "Test1"이라는 Process는

Group A라는 Functional Group의 State가 "State_A"가 됐을때 실행된다.

Group A라는 Functional Group의 State가  "State_B"가 되면 기존의 State_A에서 실행중이던 Process Test1,Test2를 종료하고 State_B에 매핑되어있는 Test77 Process가 실행된다.

 

오른쪽에 셋팅된 프로세스가 동작하는 방식도 마찬가지다.

Group_B라는 Functional Group이 있고, 해당 그룹 안에는 Start, Test1이라는 2개의 State가 있다.

해당 Functional Group의 State가 "Start state"가 되면, Test11 프로세스가 실행되고.

        Functional Group의 State가 "Test1 State"가 가되면 Process Test123이 실행되는 식이다.

 

이것이 오토사에서 App SW 가 실행되고 종료되는 과정이다.

 

참고로 설명의 편의상, 위에 표현은 안했는데 Functional Group State는 Default로 "Off State" 를 무조건 갖는다.

Off State는 해당 State가 아직 Activate 안된 상태라고 보면 된다.


부연설명 1)

하나의 프로세스는 여러개의 Functional Group State에 속할 수 있다.

(여러개의 Functional Group에 속할 순 없다)

무슨 말이냐면, 위 예시에서 보면 Test1 Process는 Group_A에 속해있고 State_A와 State_C 모두에 할당돼있다.

이런식으로 하나의 Functional Group에서 여러개의 State에 하나의 Process가 속하는건 가능하다.

 

하지만, 하나의 Process가 서로 다른 Functional Group에 속하는 것은 불가하다

부연설명 2)

앞장에서 Execution Manifest에 대해 설명했는데,

Execution Manifest에 각 프로세스가 어떤 Functional Group State에서 실행하는지 정보가 적혀있는 것임!

 

부연설명3)

Functional Group의 State가 천이되면, "기존 State에서 수행중이던 Process를 종료하는 것이 먼저" 고,

그 뒤에 새로운 State에서 실행되야 할 Process가 실행된다.

그런데, 만약 동일한 Process가 기존 State, 변경 된 State 에 모두 매핑되어 있을 경우.

이 경우 Configuration 정보에 따라서. 만약 각 State 에 Configuration된 정보가 동일하면

굳이 Process를 종료하지 않고 그냥 그대로 이어갈 수도 있음

 

부연설명4)

Dependency 개념:

특정 Functional Group state에 여러개의 Process가 할당돼있을때, Process들의 실행순서는 기본적으로는 Random이다.

대신 Dependency라는 것을 유저가 별도로 Configure 하면 Process 간의 실행순서를 지정할 수 있으며,

이것은 Execution manifest에 셋팅하는 것이다.


핵심용어2

machine State : Predefine된 이름을 갖고 있는, 프로젝트상에 반드시 Default로 존재해야하는 Functional Group

Predefine된 이름은 MachineFG 이다.

 

앞에서 말했듯이, 어댑티브 오토사에서 Process는 Functional Group State에 따라서 실행,종료가 되기 때문에

적어도 최소한 한개의 Functional Group State가 존재해야 SW가 실행될 수 있다.

그래서 프로젝트 상에 가장 밑바탕에 깔리는, ECU 전체에 대해서 총괄하는 느낌의 Functional Group State가 mahcine State이다.

 

machine State의 경우, Off/Startup/Shutdown/Restart 라는 4개의 State를 반드시 Default로 갖고있으며,

그 외 나머지 State는 사용자가 필요에 따라 추가하여 사용할 수 있다.

 

Off State의 경우 아직 활성화 자체가 안된 . Inactive 한 상태라고 봐야한다

나중에 상세히 설명하겠지만, Adaptive Platform이 문제 없이 정상적으로 실행됐다면

Machine State는 Startup State가 되야한다.

 

참고로, machine state 도 Functional Group State의 일종이기 때문에,

특정 State로 천이됐을때 해당 State에 mapping된 Process가 실행되게 된다.


핵심용어3

Execution Management: Adaptive Autosar 모듈

Machine State, Functional Group State의 State 천이를 담당하며, 이에 따른 Process 실행, 종료 역시 담당한다.

Adpative Autosar Platform의 OS가 실행된 후, 최초로 실행되는 Process(SW)가 바로 EM(Exeuction Management)이다.

 

EM이 실행되어 Startup이 완료되면, machine State가 Startup State가 되고.

이에 따라, 해당 State에 매핑된 Process가 실행된다.

 

이후에는 Machine State를 비롯한 Functional Group State의 State 변경은 EM이 관리하는게 아니라

State Management(SM)에게 넘기고, EM은 SM으로 부터 State Trainsition 요청을 받아서 그에 따라 동작만 수행한다.

무슨 말이냐면, State 변경 요청 자체를 EM이 직접 하지는 않는다는 것이다.

State Management(SM)이라는 SW가 별개로 있고, 조건에 따라 Transition 변경 요청은 SM이 EM에게 날리는 식이다.

그러면 EM은 그 요청을 받아서,

기존에 수행중이던 Process 종료 , 새로운 State에 해당되는 Process 실행 , State Transition 완료.

식으로 작업을 수행한다.

 

예를 들어 Functional Group A 에 Off_State, State_A, State_B가 있을 때

직접적으로 State를 변경하는건 EM 모듈이지만,

State 변경 요청 자체는 SM이 해야한다.

 

그러므로, 오토사 프로젝트에 반드시 SM 이라는 Process가 존재해야한다.


▶ EM에 대한 부연 설명

 Functional Group State가 변경되면, 해당 State에 매핑된 Process가 실행된다고 했는데.

엄밀히 말하면 아니다. 

State 천이 후에 Process를 실행하는게 아니라,

사실은 Process 실행이 먼저이고, 해당 Processe들이 정상적으로 실행됐을때 비로서 State 천이가 완료된다.

 

EM의 동작을 정확하게 말하자면,

SM으로부터 State Transition 요청을 받으면. 기존 State에서 실행중이던 Process를 종료하고,

State를 천이하기전에. 천이 될 State에 매핑된 Process들을 새롭게 실행한다.

 

이 때, 해당 Process들은 실행이 된 이후에 정상적으로 실행이 됐음을 Timeout 발생 되기전에

EM에게 알려줘야한다.

(ReportExecutionState 라는 API를 통해서 Process가 EM에게 알려주게 되며,

정상적으로 실행된 경우 state를 kRunning 이라는 state라고 알려줘야 함)

 

시간 내에 Process들이 정상 실행되서, 정상 실행됐음을 EM에게 알리면,

그때서야 State를 새로운 State로 천이한다.

그림으로 나타내면 아래와 같다.


핵심용어4Process State 와 Execution State

Process는 아래와 같은 State를 갖는데,

Execution State는 실제 Process가 갖는 State 이고.

 

Process State는 EM 모듈이 바라보는, EM 관점에서의 현재 Process State이다.

좀 헷갈릴 수 있는데.

Execution State : 실제 Process의 State

Process State : EM이 추적(관리?)하는 Process의 State 이다.

 

실제 Process를 실행하는게 EM 인데,  Process가 실행되면 해당 Process의 Execution State는 Initialzing 단계를 거쳐 Running이 된다.  근데 EM 입장에서는 Process 를 fork를 통해 실행을 시키긴 했지만, Process가 정상적으로 실행이 됐는지 여부를. 스스로 알 수는 없다. 그래서 Process가 실행되면, Process는 EM에게 "프로세스가 정상적으로 실행됐어요~" 하고 EM 에게 일정 시간 내에 알려줘야 한다.

해당 알람을 Report 받으면, EM은 해당 프로세스에 대한 Process State를 Running State로 비로소 바꾸게 된다.


▶이해에 도움되는 그림들 추가로 첨부


▶이해에 도움되는 그림들 추가로 첨부

반응형