Executable 과 Process

이 장에서 할 일

이 장에서는 Adaptive Application 과 포트에서 만든 Adaptive Application 다섯 개 각각을 더블클릭해 AA Internal Behavior 다이얼로그를 열고, EXECUTION 탭에서 Executable 을 확인하고 Process 를 하나씩 추가한다. Executable 은 이미 채워져 있어 아무것도 입력하지 않는다. Process 에는 이름, STARTUP CONFIG 의 ENTER TIMEOUT 과 EXIT TIMEOUT, FUNCTION GROUP STATE 로 MachineFG 의 상태, 그리고 Sensor, Fusion, Actuator 에는 EXECUTION DEPENDENCY 로 CM 프로세스가 Running 이어야 한다는 조건을 넣는다. CM 을 먼저 만들고, Sensor 를 절차로 보인 뒤, 나머지 셋은 표로 반복한다. 마지막으로 Machine Configuration 다이얼로그의 PROCESSES 탭에서 프로세스 다섯 개가 머신에 모였는지 확인한다.

이 장을 마치면 design/SWC/AdaptiveApplication/ 의 *.swc.io.model 다섯 개에 executable 과 process 가 저장된다. 이것이 ARXML 익스포트에서 참조 설계의 EXECUTABLE 다섯 개, PROCESS 다섯 개, STARTUP-CONFIG 다섯 개, FUNCTION-GROUP-STATE-IREF 와 EXECUTION-DEPENDENCY 가 된다.

시작하기 전에

Adaptive Application 과 포트를 마친 상태에서 시작한다. design/SWC/AdaptiveApplication/ 의 Sensor, Fusion, Actuator, CM, EM 다섯 파일에는 아직 executable 과 process 가 없다.
머신 Ecu 에는 머신 설정에서 본 함수 그룹 MachineFG 하나가 있고 상태는 Off, Startup, Shutdown, Restart, Verify 이다. 이 장의 FUNCTION GROUP STATE 는 이 함수 그룹의 상태를 고르는 것이므로 머신에 MachineFG 가 있어야 한다.
VALIDATION 패널은 No validation issues. 이다.
순서가 중요하다. CM 을 가장 먼저 만들고 저장한다. EXECUTION DEPENDENCY 의 PROCESS 목록에는 같은 컴포지션 HPC 안의 다른 Adaptive Application 이 이미 저장한 프로세스만 나오므로, CM 의 프로세스가 저장돼 있어야 Sensor, Fusion, Actuator 에서 CM 을 고를 수 있다.

이 장에서 키보드로 입력하는 값은 프로세스 이름 다섯 개와 타임아웃 숫자뿐이다. 나머지는 + 버튼과 드롭다운에서 클릭해 고른다. Executable 섹션의 값은 모두 미리 채워져 있어 바꾸지 않는다.

Adaptive Application	Process NAME	ENTER TIMEOUT / EXIT TIMEOUT	FUNCTION GROUP STATE	EXECUTION DEPENDENCY
`CM`	`CM`	`1` / `1` (기본값 그대로)	`MachineFG : Startup`, `MachineFG : Shutdown`, `MachineFG : Restart`, `MachineFG : Verify`	없음
`Sensor`	`Sensor`	`5` / `5`	`MachineFG : Startup`	`CM : Running`
`Fusion`	`Fusion`	`5` / `5`	`MachineFG : Startup`	`CM : Running`
`Actuator`	`Actuator`	`5` / `5`	`MachineFG : Startup`	`CM : Running`
`EM`	`EM`	`0` / `0`	`MachineFG : Startup`	없음

타임아웃의 단위는 기본값 s 그대로 둔다. SCHEDULING POLICY 는 SCHED_OTHER, SCHEDULING PRIORITY 는 0 으로 다섯 모두 기본값이다.

CM 의 Executable 과 Process 만들기

AA Internal Behavior 다이얼로그 열기

왼쪽 EDITOR 뷰의 DESIGN 아래에서 VFB 를 클릭한다. 탭 AADesign:VFB 가 열리고 루트 캔버스에 컴포지션 노드 HPC [Ecu] 가 보인다. 노드 HPC [Ecu] 를 더블클릭한다. 빵부스러기가 System > HPC 로 바뀌고 프레임 HPC 안에 8장에서 만든 노드 다섯 개와 커넥터 두 개가 보인다. 8장의 탭 AADesign:VFB 가 아직 열려 있고 빵부스러기가 이미 System > HPC 이면 바로 2 로 넘어간다.
노드 CM 을 더블클릭한다.

그림 9-1. 컴포지션 HPC 안으로 들어간 VFB 편집기. ① 더블클릭할 노드 CM. 윗줄에 Sensor, Fusion, Actuator, 아랫줄에 CM, EM 이 있고 Sensor 의 P 에서 두 R 로 선이 이어져 있다. 노드 배치는 8장에서 Auto Layout 을 누른 결과에 따라 그림과 다를 수 있으며 설계 값에는 영향이 없다.
다이얼로그 AA Internal Behavior [CM] 이 열린다. 왼쪽 캔버스에 CM 본체가 있고 포트는 없다. 오른쪽 패널의 탭은 PROPERTIES 와 EXECUTION 두 개이며 처음에는 PROPERTIES 가 열려 NAME CM, AS PROTOTYPE CM, DESCRIPTION -, PORTS No ports available 이 보인다. 바닥에 Close 버튼이 있다.

그림 9-2. 막 열린 다이얼로그. ① 제목 AA Internal Behavior [CM], ② 탭 EXECUTION. PROPERTIES 탭은 8장에서 입력한 이름과 포트를 읽기 전용으로 보여 준다.

EXECUTION 탭의 EXECUTABLE 섹션 확인하기

탭 EXECUTION 을 클릭한다. 위에 EXECUTABLE 섹션, 아래에 PROCESS 머리글과 + 버튼(툴팁 Add Process), 그리고 No processes defined 가 보인다.

EXECUTABLE 섹션의 값을 확인만 한다. 아무것도 입력하지 않는다.

EXECUTION 탭. EXECUTABLE 섹션은 채워져 있고 PROCESS 는 비어 있음

그림 9-3. EXECUTION 탭을 처음 열었을 때. ① EXECUTABLE 섹션, ② No processes defined, ③ PROCESS 머리글 오른쪽의 + 버튼(툴팁 Add Process).

라벨	값	비고
NAME	`CM`	Adaptive Application 이름이 미리 들어 있다
ROOT SWC PROTOTYPE	`AA`	기본값
CATEGORY	`APPLICATION`	토글 `APPLICATION` / `PLATFORM`
BUILD TYPE	비어 있음	토글 `DEBUG` / `RELEASE` 둘 다 꺼짐. 켜지 않는다
REPORTING BEHAVIOR	`REPORTS-EXECUTION-STATE`	토글 `REPORTS-EXECUTION-STATE` / `DOES-NOT-REPORT-EXECUTION-STATE`
VERSION	`1.0.0`	기본값
MINIMUM TIMER GRANULARITY	비어 있음	안내 `Time Value (≥0)`, 단위 `s`. 입력하지 않는다

다섯 Adaptive Application 모두 같은 값이며, NAME 만 각자의 이름이다.

Process 를 추가하고 이름 입력하기

PROCESS 머리글 오른쪽의 + 버튼을 클릭한다. 카드 CM_0 이 접힌 채 생긴다. 카드 머리글 오른쪽의 ×(툴팁 Remove Process)는 누르지 않는다.
카드 머리글 CM_0 을 클릭해 펼친다. 안에 NAME 필드와 아코디언 STARTUP CONFIG, FUNCTION GROUP STATE, EXECUTION DEPENDENCY, LOG CONFIG, DLT CONTEXTS 가 있고 STARTUP CONFIG 만 펼쳐져 있다.
NAME 에 CM 을 입력하고 Tab 을 누른다. 카드 머리글이 CM 으로 바뀌고, 다이얼로그 제목은 수정됨 표시가 붙은 ● AA Internal Behavior [CM] 이다.

STARTUP CONFIG 는 그대로 둔다. CM 의 타임아웃은 기본값 1 s / 1 s 가 그대로 참조 설계의 값이다.

이름을 CM 으로 입력한 프로세스 카드와 STARTUP CONFIG 기본값

그림 9-4. 이름을 입력한 뒤의 프로세스 카드. ① 카드 머리글 CM, ② NAME = CM, ③ ENTER TIMEOUT 1 s, ④ EXIT TIMEOUT 1 s, ⑤ SCHEDULING POLICY = SCHED_OTHER, ⑥ SCHEDULING PRIORITY = 0. 제목이 ● AA Internal Behavior [CM] 이다.

STARTUP CONFIG 라벨	기본값	이 장에서
ENTER TIMEOUT	`1` `s`	`Sensor`, `Fusion`, `Actuator` 는 `5`, `EM` 은 `0` 으로 바꾼다
EXIT TIMEOUT	`1` `s`	위와 같다
CPU USAGE	`0`	그대로
MEM USAGE	`0` `B`	그대로
SCHEDULING POLICY	`SCHED_OTHER`	토글 `SCHED_OTHER` / `SCHED_FIFO` / `SCHED_RR`. 그대로
SCHEDULING PRIORITY	`0`	그대로
EXECUTION ERROR	비어 있음	안내 `Unsigned Integer (0..4294967295)`. 그대로
TERMINATION BEHAVIOR	`PROCESS-IS-NOT-SELF-TERMINATING`	토글 `PROCESS-IS-NOT-SELF-TERMINATING` / `PROCESS-IS-SELF-TERMINATING`. 그대로

Function Group State 네 개 추가하기

CM 프로세스는 MachineFG 의 Startup, Shutdown, Restart, Verify 네 상태에 묶인다. 행 하나를 만들어 상태를 고르는 절차를 네 번 반복한다.

아코디언 머리글 FUNCTION GROUP STATE 를 클릭해 펼친다. 본문은 No function group states defined 이다.
머리글 오른쪽의 + 버튼(툴팁 Add Function Group State)을 클릭한다. 행 MachineFG : Off 가 생긴다. 기본값은 머신의 첫 함수 그룹과 그 그룹의 첫 상태이다.
행 머리글 MachineFG : Off 를 클릭해 펼친다. FUNCTION GROUP 칸은 MachineFG, FUNCTION GROUP STATE 칸은 Off 이다.
FUNCTION GROUP STATE 칸을 클릭한다. 드롭다운에 Off(현재 값, 체크 표시), Startup, Shutdown, Restart, Verify 가 순서대로 보인다.

그림 9-5. 첫 행의 상태 드롭다운. ① FUNCTION GROUP STATE 머리글의 + 버튼, ② 새 행 MachineFG : Off, ③ FUNCTION GROUP STATE 칸, ④ 드롭다운 항목 Startup. FUNCTION GROUP 칸은 MachineFG 이다. 드롭다운이 Close 버튼 위로 겹쳐 보인다.
Startup 을 클릭한다. 행 머리글이 MachineFG : Startup 으로 바뀐다. 행 머리글을 다시 클릭해 접는다.
2~5 를 세 번 더 반복해 Shutdown, Restart, Verify 를 고른다. 새 행은 매번 MachineFG : Off 로 생기므로 행이 생기자마자 상태를 고른다. 행 끝의 ×(툴팁 Remove Function Group State)는 누르지 않는다.
아코디언 머리글 EXECUTION DEPENDENCY 를 클릭해 펼쳐 본다. 본문은 No execution dependencies defined 이다. CM 은 의존성이 없으므로 그대로 둔다.

그림 9-6. 네 행을 모두 만든 뒤의 카드. ① 행 MachineFG : Startup, MachineFG : Shutdown, MachineFG : Restart, MachineFG : Verify, ② EXECUTION DEPENDENCY 의 No execution dependencies defined.

주의. 새 행의 기본 상태는 Off 이다. 참조 설계의 어느 프로세스도 Off 에 묶이지 않으므로 행을 만들 때마다 상태를 바꿔야 한다. Off 행을 남겨 두면 저장 파일에 그대로 들어간다.

저장하고 닫기

다이얼로그 안에서 Ctrl+S 를 누른다. 제목의 ● 가 사라져 AA Internal Behavior [CM] 이 된다. 탭은 EXECUTION 에 머문다.
Close 를 클릭한다. 저장했으므로 묻는 창 없이 닫힌다.

그림 9-7. 저장한 뒤의 다이얼로그. ① 제목 AA Internal Behavior [CM](수정됨 표시 없음), ② 카드 머리글 CM, ③ FUNCTION GROUP STATE 행 네 개. 저장해도 아코디언은 그대로이므로 EXECUTION DEPENDENCY 는 펼쳐진 채이고, 본문 No execution dependencies defined 는 패널 아래 경계에서 잘려 있다.

참고. 다이얼로그 안의 Ctrl+S 는 CM.swc.io.model 을 쓰고 AADesign:VFB 탭까지 함께 저장한다. 닫은 뒤 탭에 수정됨 표시 ● 가 없다. 저장하지 않고 Close 를 누르면 Do you want to save the changes? 창이 Save, Don't Save, Cancel 버튼과 함께 뜬다. 이 장에서는 항상 Ctrl+S 로 저장한 뒤 Close 를 누른다.

Sensor 의 Process 만들기

Sensor 는 타임아웃을 바꾸고 실행 의존성을 넣는 프로세스이다. Fusion 과 Actuator 도 값이 같다.

카드를 만들고 타임아웃 입력하기

노드 Sensor 를 더블클릭한다. AA Internal Behavior [Sensor] 가 열리고 캔버스에 Sensor 본체와 경계의 P 포트 Sensor 가 보인다.
탭 EXECUTION 을 클릭하고 PROCESS 의 + 버튼을 클릭한다. 카드 Sensor_0 이 생긴다. 머리글을 클릭해 펼친다.
NAME 에 Sensor 를 입력하고 Tab 을 누른다.
STARTUP CONFIG 의 ENTER TIMEOUT 에 5 를 입력하고 Tab, EXIT TIMEOUT 에 5 를 입력하고 Tab 을 누른다. 단위 s 는 그대로 둔다.

그림 9-8. 타임아웃을 입력한 뒤의 카드. ① NAME = Sensor, ② ENTER TIMEOUT = 5 s, ③ EXIT TIMEOUT = 5 s. 제목은 ● AA Internal Behavior [Sensor] 이고 캔버스에 P 포트 Sensor 가 보인다.

Function Group State 추가하기

FUNCTION GROUP STATE 머리글을 클릭해 펼치고 + 버튼을 클릭한다. 행 MachineFG : Off 가 생긴다.
행 머리글을 클릭해 펼치고 FUNCTION GROUP STATE 칸에서 Startup 을 클릭한다. 행이 MachineFG : Startup 이 된다. 행 머리글을 다시 클릭해 접는다.

그림 9-9. 상태를 고른 뒤의 FUNCTION GROUP STATE. ① + 버튼, ② 행 MachineFG : Startup(접힘). EXECUTION DEPENDENCY 는 아직 접혀 있다.

Execution Dependency 추가하기

EXECUTION DEPENDENCY 머리글을 클릭해 펼친다. 본문은 No execution dependencies defined 이다.
머리글 오른쪽의 + 버튼(툴팁 Add Execution Dependency)을 클릭한다. 행 CM : Running 이 생긴다.
행 머리글을 클릭해 펼친다. PROCESS 칸은 CM, PROCESS STATE 칸은 Running 이다.
PROCESS 칸을 클릭해 드롭다운을 연다. 항목은 CM 하나뿐이다. 지금 이 컴포지션 안에서 프로세스를 저장한 다른 Adaptive Application 이 CM 뿐이기 때문이다. PROCESS STATE 드롭다운의 항목은 Idle, Starting, Running, Terminated 이다.

그림 9-10. 실행 의존성 행을 펼친 화면. ① EXECUTION DEPENDENCY 머리글의 + 버튼, ② 새 행 CM : Running, ③ PROCESS 칸과 열린 드롭다운(항목 CM, 체크 표시), ④ PROCESS STATE = Running.
CM 을 클릭한다. PROCESS STATE 는 Running 그대로 둔다.
Ctrl+S 를 누른 뒤 Close 를 클릭한다.

그림 9-11. 저장한 뒤의 Sensor 다이얼로그. ① 제목 AA Internal Behavior [Sensor], ② FUNCTION GROUP STATE 행 MachineFG : Startup, ③ EXECUTION DEPENDENCY 행 CM : Running(PROCESS CM, PROCESS STATE Running). STARTUP CONFIG 는 5 s / 5 s 이다.

Fusion, Actuator, EM 의 Process 만들기

같은 방법으로 나머지 셋을 만든다. 노드를 더블클릭하고 EXECUTION 탭에서 + 를 눌러 카드를 만든 뒤, 표의 값을 입력하고 Ctrl+S, Close 순서로 마친다.

노드	NAME	ENTER TIMEOUT / EXIT TIMEOUT	FUNCTION GROUP STATE	EXECUTION DEPENDENCY
`Fusion`	`Fusion`	`5` / `5`	`MachineFG : Startup`	+ 로 행을 만들고 PROCESS 를 `CM` 으로 바꾼다. PROCESS STATE 는 `Running`
`Actuator`	`Actuator`	`5` / `5`	`MachineFG : Startup`	위와 같다
`EM`	`EM`	`0` / `0`	`MachineFG : Startup`	없음

주의. Fusion 과 Actuator 에서 EXECUTION DEPENDENCY 의 + 를 누르면 새 행의 기본값이 Sensor : Running 이다. 기본값은 목록의 첫 프로세스이고, 목록은 Fusion 에서는 Sensor, CM 이며 Actuator 에서는 Sensor, Fusion, CM 이다. 행을 펼쳐 PROCESS 칸에서 반드시 CM 을 고른다. 행 머리글이 CM : Running 인지 확인한 뒤 저장한다.

EM 은 타임아웃 두 칸에 0 을 입력한다. 참조 설계의 EM 에는 타임아웃 값이 없는데, PAIO 는 0 을 입력하면 ARXML 로 내보낼 때 타임아웃 태그를 생략하므로 같은 모양이 된다.

EM 프로세스 카드. 타임아웃 0 s, FUNCTION GROUP STATE MachineFG : Startup, 의존성 없음

그림 9-12. 저장 직전의 EM 카드. ① ENTER TIMEOUT = 0 s, ② EXIT TIMEOUT = 0 s, ③ 행 MachineFG : Startup, ④ EXECUTION DEPENDENCY 의 No execution dependencies defined. 제목은 ● AA Internal Behavior [EM] 이다.

다섯 다이얼로그를 모두 저장하면 design/SWC/AdaptiveApplication/ 의 각 파일에 executable 과 process 가 추가된다. 저장하면 internal-behavior 도 함께 추가된다. runnable-entities 와 rte-events 는 비어 있고, canvas-size({ "width": 160, "height": 120 })와 port-positions(포트마다의 위치이며, 포트가 없는 CM 과 EM 은 {})는 다이얼로그 캔버스의 배치를 담는다. CM.swc.io.model 의 executable 은 다음과 같다.

"executable": {
  "name": "CM",
  "root-swc-prototype": "AA",
  "version": "1.0.0",
  "category": "APPLICATION_LEVEL",
  "reporting-behavior": "REPORTS-EXECUTION-STATE"
}

process 에는 이름, startup-configs 한 항목(함수 그룹 상태, cpu-usage 0 과 mem-usage 0 을 담은 resource-group, scheduling-policy SCHED_OTHER, scheduling-priority 0, enter-timeout 과 exit-timeout, execution-dependencies)이 들어간다. Sensor, Fusion, Actuator 는 enter-timeout 과 exit-timeout 이 5, execution-dependencies 가 [{ "process-ref": "CM", "state": "Running" }] 이고, EM 은 타임아웃이 0, execution-dependencies 가 [] 이다. 화면의 CATEGORY APPLICATION 은 파일에 APPLICATION_LEVEL 로 저장된다.

참고. LOG CONFIG 아코디언을 열지 않았는데도 process 에 log-config 가 함께 저장된다. application-id 는 빈 문자열, default-log-level 은 INFO, log-mode 는 CONSOLE, dlt-contexts 는 [] 이다. 로그와 DLT에서 이 빈 APPLICATION ID 를 채운다. 빈 값은 검증에 걸리지 않는다.

머신의 PROCESSES 탭에서 확인하기

프로세스는 Adaptive Application 마다 따로 입력했지만, 머신은 그것을 한 목록으로 모아 보여 준다.

캔버스 위 빵부스러기의 System 을 클릭해 루트로 돌아간다.
노드 HPC 머리글의 머신 아이콘을 클릭한다. Machine Configuration [HPC] 가 열리고 탭 MACHINE, FUNCTION GROUP, PROCESSES, MODULE 이 보인다.
탭 PROCESSES 를 클릭한다. 왼쪽 PROCESSES 목록에 Sensor, Fusion, Actuator, CM, EM 다섯 개가 있다. 1장에서는 이 목록이 No Adaptive Application processes found in this Composition 이었다.
목록에서 CM 을 클릭한다. 가운데 패널 머리글이 CM 이고 오른쪽에 Mark as SM, Mark as PHM 버튼이 있다. 둘 다 누르지 않는다. 아래로 CORE AFFINITY, ADAPTIVE APPLICATION, STARTUP CONFIG, FUNCTION GROUP STATE, EXECUTION DEPENDENCY 섹션이 이어진다.

그림 9-13. PROCESSES 탭에서 CM 을 고른 화면. ① 목록의 CM, ② CORE AFFINITY 표(열 CORE, SHALL RUN ON, SHALL NOT RUN ON, 행 Core0 (0) 부터 Core3 (3), 체크박스 전부 비어 있음), ③ ADAPTIVE APPLICATION(EXECUTABLE CM, CATEGORY APPLICATION_LEVEL, REPORTING BEHAVIOR REPORTS-EXECUTION-STATE, VERSION 1.0.0), ④ FUNCTION GROUP STATE 네 행. STARTUP CONFIG 는 POLICY SCHED_OTHER, PRIORITY 0, ENTER TIMEOUT 1 s, EXIT TIMEOUT 1 s, CPU USAGE 0 %, MEM USAGE 0 B 이다. 오른쪽 그래프에서 CM 이 파란 테두리로 강조된다.
목록에서 Sensor 를 클릭하고 가운데 패널을 아래로 내린다. ADAPTIVE APPLICATION 아래에 SWC Sensor 와 포트 행 P Sensor Sensor 가 있고, STARTUP CONFIG 는 ENTER TIMEOUT 5 s, EXIT TIMEOUT 5 s, FUNCTION GROUP STATE 는 MachineFG : Startup, EXECUTION DEPENDENCY 는 CM : Running 이다.
오른쪽 패널의 탭 EXECUTION DEPENDENCY 를 본다. 왼쪽에 CM 과 EM, 오른쪽에 Sensor, Fusion, Actuator 가 있고 CM 에서 세 노드로 화살표 셋이 각각 Running 라벨을 달고 이어진다. 고른 프로세스가 파란 테두리로 강조된다.

그림 9-14. Sensor 를 고른 화면. ① 목록의 Sensor, ② STARTUP CONFIG(5 s / 5 s), ③ EXECUTION DEPENDENCY CM : Running, ④ 오른쪽 EXECUTION DEPENDENCY 그래프. CM 에서 Sensor, Fusion, Actuator 로 가는 화살표 셋에 Running 이 붙어 있다.
Close 를 클릭한다. 아무것도 바꾸지 않았으므로 묻는 창 없이 닫힌다.

참고. 이 탭의 가운데 패널은 CORE AFFINITY 의 체크박스만 편집할 수 있고 나머지는 읽기 전용이다. 이 튜토리얼은 코어를 체크하지 않는다. 참조 설계에는 프로세스와 코어의 매핑이 없고, 체크하지 않아도 익스포트에는 PROCESS-TO-MACHINE-MAPPING-SET 과 매핑 다섯 개가 자동으로 나온다. 그 내용은 ARXML 익스포트에서 본다.

검증 결과 보기

화면 아래 푸터의 왼쪽에서 다섯 번째 아이콘인 V 를 본다. 배지가 붙어 있지 않다.
VALIDATION 패널을 본다. 닫혀 있으면 푸터의 V 아이콘을 클릭한다. 헤더에 배지가 없고, 열 머리글 ELEMENT TYPE, NAME, DESCRIPTION, CONSTR 아래 본문이 No validation issues. 이다.

그림 9-15. 다섯 다이얼로그를 모두 저장한 뒤의 VALIDATION 패널. 본문은 No validation issues. 이다.

참고. 프로세스를 추가하고 FUNCTION GROUP STATE 를 넣기 전에 저장하면 검증이 The process "EM" declares no functionGroupState; at least one is required. 와 같은 행을 낸다(이 장의 절차대로 행을 먼저 넣고 저장하면 생기지 않는다). 이 문장은 검증에서 일부러 만들어 다시 본다.

왜 이렇게 설계하는가

Executable 은 입력하지 않는다. 참조 설계의 EXECUTABLE 다섯 개는 모두 VERSION 1.0.0, CATEGORY APPLICATION_LEVEL, REPORTING-BEHAVIOR REPORTS-EXECUTION-STATE 이고 BUILD-TYPE 과 MINIMUM-TIMER-GRANULARITY 가 없다. 다이얼로그의 기본값이 이와 같으므로 BUILD TYPE 과 MINIMUM TIMER GRANULARITY 를 비워 둔다.
ROOT SWC PROTOTYPE 은 다섯 모두 AA 이다. 참조 설계는 Sensor, Fusion, Actuator 가 AA, CM 과 EM 이 RootSwComponent 로 섞여 있다. 이 튜토리얼은 기본값 AA 를 그대로 써서 다섯 개를 통일한다. 이름만 다르고 설계 내용은 같다.
타임아웃은 Sensor, Fusion, Actuator 가 5 / 5, CM 이 1 / 1 이다. 참조 설계의 STARTUP-CONFIG 다섯 개는 모두 SCHED_OTHER, 우선순위 0 이고 ENTER-TIMEOUT-VALUE 와 EXIT-TIMEOUT-VALUE 가 이 값이다. EM 의 STARTUP-CONFIG 에는 타임아웃 요소가 없으므로 0 을 입력해 태그가 생략되게 한다.
CM 은 MachineFG 의 네 상태, 나머지는 Startup 에 묶인다. 참조 설계의 FUNCTION-GROUP-STATE-IREF 는 CM 에 Startup, Shutdown, Restart, Verify 네 개, Sensor, Fusion, Actuator 에 Startup 하나씩이다.
EM 도 MachineFG : Startup 에 묶는다. 검증 때문에 참조 설계와 다르게 한 곳이다. 참조 설계의 EM 프로세스에는 FUNCTION-GROUP-STATE-IREF 가 없다. 그러나 PAIO 검증은 함수 그룹 상태가 없는 프로세스를 The process "EM" declares no functionGroupState; at least one is required. 로 거부한다. 그래서 이 튜토리얼은 EM 도 Startup 에 묶는다. 익스포트에는 FUNCTION-GROUP-STATE-IREF 가 참조 설계보다 하나 많은 여덟 개가 나온다.
실행 의존성은 Sensor, Fusion, Actuator 가 CM 의 Running 에 건다. 참조 설계의 EXECUTION-DEPENDENCY 셋은 모두 CM 프로세스의 ProcessState/Running 을 가리킨다. CM 과 EM 에는 의존성이 없다.
CPU USAGE 와 MEM USAGE 는 0 그대로이다. 참조 설계의 리소스 그룹에는 값이 없다. 익스포트에서는 프로세스마다 CPU-USAGE 0, MEM-USAGE 0 을 가진 리소스 그룹이 머신 쪽에 생기며, 참조 설계의 공유 리소스 그룹 하나와 모양이 다르다. UI 로는 만들 수 없는 차이이다.

확인하기

노드 Sensor, Fusion, Actuator, CM, EM 을 더블클릭해 EXECUTION 탭을 열면 EXECUTABLE 의 NAME 이 각자의 이름이고 VERSION 이 1.0.0 이다.
각 PROCESS 에 카드가 하나씩 있고 머리글이 CM, Sensor, Fusion, Actuator, EM 이다.
CM 의 STARTUP CONFIG 는 1 s / 1 s, Sensor, Fusion, Actuator 는 5 s / 5 s, EM 은 0 s / 0 s 이다.
CM 의 FUNCTION GROUP STATE 에 행 네 개 MachineFG : Startup, MachineFG : Shutdown, MachineFG : Restart, MachineFG : Verify 가 있고, 나머지 넷에는 MachineFG : Startup 한 행이 있다. MachineFG : Off 행은 어디에도 없다.
Sensor, Fusion, Actuator 의 EXECUTION DEPENDENCY 에 행 CM : Running 이 있고, CM 과 EM 은 No execution dependencies defined 이다.
다이얼로그 제목과 탭 AADesign:VFB 에 수정됨 표시 ● 가 없다.
Machine Configuration [HPC] 의 PROCESSES 탭 목록에 프로세스 다섯 개가 있고, 그래프에 CM 에서 Sensor, Fusion, Actuator 로 가는 Running 화살표 셋이 있다.
VALIDATION 패널에 No validation issues. 가 보이고 헤더에 배지가 없다.

다음 단계

서비스 인스턴스 매핑에서 Sensor, Fusion, Actuator 의 포트를 6장에서 만든 SOME/IP 서비스 인스턴스에 매핑한다.

이 장에서 할 일​

시작하기 전에​

CM 의 Executable 과 Process 만들기​

AA Internal Behavior 다이얼로그 열기​

EXECUTION 탭의 EXECUTABLE 섹션 확인하기​

Process 를 추가하고 이름 입력하기​

Function Group State 네 개 추가하기​

저장하고 닫기​

Sensor 의 Process 만들기​

카드를 만들고 타임아웃 입력하기​

Function Group State 추가하기​

Execution Dependency 추가하기​

Fusion, Actuator, EM 의 Process 만들기​

머신의 PROCESSES 탭에서 확인하기​

검증 결과 보기​

왜 이렇게 설계하는가​

확인하기​

다음 단계​