ARXML 익스포트
이 장에서 할 일
이 장에서는 검증을 통과한 설계를 AUTOSAR ARXML 파일로 내보낸다. EDITOR 뷰 DESIGN 머리글의 Export 아이콘을 클릭하면, 저장 위치를 묻지 않고 프로젝트의 export 폴더에 파일 다섯 개가 바로 생긴다.
그다음 앞 장들에서 화면으로 넣은 값이 어떤 ARXML 이 되었는지 XML 편집기로 본다. 대표로 Sensor 하나를 따라간다. Executable 과 Process에서 만든 PROCESS Sensor 와 그 시작 조건, 서비스 인스턴스 매핑에서 만든 매핑 Sensor_AA_Sensor, 로그와 DLT에서 만든 DLT 애플리케이션 SENS 이다. 앞의 둘은 AADesign_SWC.arxml 에, DLT 애플리케이션은 AADesign_COM.arxml 에 있다.
마지막으로 내 익스포트가 참조 설계의 파일 EM_Test_*.arxml 다섯 개와 어디가, 왜 다른지 표로 읽는다.
이 장을 마치면 export 폴더에 AADesign_COM.arxml, AADesign_DataType.arxml, AADesign_Interface.arxml, AADesign_SWC.arxml, AADesign_System.arxml 다섯 개가 있고, 두 파일을 연 XML 편집기의 상태 표시줄이 모두 ✓ No problems 이다.
시작하기 전에
- 검증을 마친 상태에서 시작한다. 푸터의 V 아이콘으로 여는 VALIDATION 패널에
No validation issues.가 보인다. 패널이 열려 있으면 V 아이콘으로 닫아 둔다. - 프로젝트의
export폴더는 비어 있다. 검증에서 연 탭AADesign:VFB가 아직 열려 있으면 탭의 × 를 클릭해 닫아, 편집기가 하나도 열려 있지 않게 한다. - 이 장에서 키보드로 입력하는 것은 찾기 창에 넣는 문자열 세 개와
Enter한 번뿐이다. 첫 문자열은 해당 파일에서 두 곳을 찾고, 나머지 두 문자열은 정확히 한 곳씩 찾는다.
| 찾을 것 | 파일 | 찾기 문자열 | 찾기 창 | 이동하는 줄 |
|---|---|---|---|---|
PROCESS Sensor | AADesign_SWC.arxml | /Executable/Sensor/Sensor | 1 of 2, Enter 뒤 2 of 2 | 562행, 이어서 575행 |
매핑 Sensor_AA_Sensor | AADesign_SWC.arxml | Sensor_AA_Sensor | 1 of 1 | 553행 |
DLT 애플리케이션 SENS | AADesign_COM.arxml | <APPLICATION-ID>SENS | 1 of 1 | 446행 |
프로젝트 익스포트하기
Export 아이콘 클릭하기
-
EDITOR 뷰에서 DESIGN 머리글 오른쪽에 있는 아이콘 네 개 가운데 두 번째에 마우스를 올린다. 툴팁 Export 가 보인다. 네 아이콘에는 툴팁 말고는 이름이 없으며, 툴팁은 왼쪽부터 Import, Export, PRTE Code Generation, PARA Code Generation 이다.
그림 13-1. DESIGN 머리글의 Export 아이콘. ① 뷰 머리글
EDITOR: AADesign, ② 마우스를 올린 Export 아이콘과 그 툴팁 Export. DESIGN 과 MODULE 은 펼쳐져 있고 DOC, CODE, EXPORT 는 접혀 있다. 열린 탭이 없어 편집기 영역에는Open a file to start editing이 보인다. -
Export 를 클릭한다.
참고. Export 는 Explorer(창 맨 왼쪽 아이콘 막대 맨 아래의 Explorer 아이콘)에서
design폴더를 오른쪽 클릭하면 열리는 메뉴에도 있다. 두 곳 모두 같은 익스포트를 실행한다.
진행 창 확인하기
-
파일 선택기나 저장 위치를 묻는 창은 뜨지 않는다. 곧바로 진행 창 Exporting to AUTOSAR 가 뜬다. 잠시 뒤 익스포트가 끝나면 메시지가
Export complete: 30 elements exported to AADesign_*.arxml로 바뀐다.
그림 13-2. 익스포트가 끝난 순간의 진행 창. ① 창 제목 Exporting to AUTOSAR, ② 메시지
Export complete: 30 elements exported to AADesign_*.arxml, ③ 단계 표시✓ Complete!. 그 아래에100%,3 / 3 elements와 경과 시간, Close 버튼이 있다. -
진행 창은 완료 2초 뒤에 저절로 닫힌다. 기다려도 되고 Close 를 클릭해도 된다.
참고. 익스포트는 항상 프로젝트의
export폴더에<프로젝트 이름>_*.arxml이름으로 쓴다.design폴더의 설계 파일은 바뀌지 않는다. 진행 창의 경과 시간은 실행할 때마다0s또는1s로 달라진다.
참고. 참조 설계를 PAIO 로 임포트해 그대로 다시 내보내면 메시지의 숫자는
30보다 크다. 임포트한 프로젝트에는 이 튜토리얼이 만들지 않는 파생 요소가 더 있기 때문이다. 파일 내용의 차이는 이 장 끝의 "내 익스포트와 기준 파일의 차이" 절에서 본다.
export 폴더의 파일 다섯 개 보기
-
EDITOR 뷰에서 EXPORT 머리글을 클릭해 펼친다. EXPORT 에는 프로젝트
export폴더의 파일이 보인다. 파일 다섯 개가 이름 순서로 보이고, 잘린 이름은 없다.
그림 13-3. 펼친 EXPORT. ① EXPORT 머리글, ② 파일 다섯 개
AADesign_COM.arxml,AADesign_DataType.arxml,AADesign_Interface.arxml,AADesign_SWC.arxml,AADesign_System.arxml, ③ 다음에 열AADesign_SWC.arxml.
다섯 파일에 담기는 것은 다음과 같다. 다섯 파일 모두 스키마 AUTOSAR_00054 이고, PAIO 에 들어 있는 스키마로 검사하면 오류와 경고가 0건이다. 크기는 PAIO 버전에 따라 조금 다를 수 있다.
| 파일 | 담긴 것 | 크기(바이트) |
|---|---|---|
AADesign_COM.arxml | 머신 디자인 Ecu, Ethernet 클러스터와 커넥터 eth0, 엔드포인트, SOME/IP 배포와 서비스 인스턴스, 인스턴스와 머신의 매핑, DLT ECU 와 DLT 애플리케이션, DLT 컨텍스트, 소비자 두 개의 이벤트 그룹 구독 타이밍 | 28 444 |
AADesign_DataType.arxml | 데이터 타입 ByteArray, String 과 프리미티브 타입, 그 CP 측 미러, 포인터 타입 VoidPtr, ConstVoidPtr | 39 671 |
AADesign_Interface.arxml | 서비스 인터페이스 Sensor | 3 317 |
AADesign_SWC.arxml | Adaptive Application 다섯 개와 포트, 컴포지션 HPC 와 System, Executable, Process, 시작 설정, 서비스 인스턴스 매핑, DLT 애플리케이션과 프로세스의 매핑, 머신 Ecu 와 그 모듈 | 42 260 |
AADesign_System.arxml | 시스템 System 과, 컴포지션 HPC 를 머신 디자인 Ecu 에 놓는 매핑 SwMapping_HPC_to_Ecu | 2 513 |
AADesign_SWC.arxml 을 XML 편집기로 열기
-
EXPORT 에서
AADesign_SWC.arxml을 더블클릭한다. 편집기 탭AADesign:AADesign_SWC.arxml이 열리고 1행부터 보인다. -
편집기 아래의 상태 표시줄을 본다.
Ln 1, Col 1,UTF-8,Schema: R25-11,✓ No problems이다. XML 편집기는 파일을 열 때 PAIO 에 들어 있는 AUTOSAR 스키마로 파일을 자동으로 검사한다.✓ No problems는 스키마 오류가 없다는 뜻이다. 그 위의 PROBLEMS 머리글은 오류가 없으므로 접힌 채이다.
그림 13-4.
AADesign_SWC.arxml을 연 직후. ① 편집기 탭AADesign:AADesign_SWC.arxml, ② 상태 표시줄의✓ No problems. EXPORT 에서 그 파일이 선택되어 있고, 편집기 첫 부분에는ADAPTIVE-APPLICATION-SW-COMPONENT-TYPEActuator,CM,EM,Fusion,Sensor가 차례로 보인다.
참고. 파일은 보기 모드(읽기 전용)로 열린다. 툴바의 첫 버튼은 툴팁 Switch to Edit mode 로, 편집 모드로 바꾸는 버튼이다. 나머지 버튼은 Save (Ctrl+S), Undo (Ctrl+Z), Redo (Ctrl+Y), Format XML (Shift+Alt+F) 이다. 이 장에서는 파일을 고치지 않으므로 편집 모드로 바꾸지 않는다.
PROCESS Sensor 와 시작 조건 보기
찾기로 PROCESS Sensor 로 이동하기
-
편집기 안을 클릭하고
Ctrl+F를 누른다. 편집기 오른쪽 위에 찾기 창이 열린다. -
/Executable/Sensor/Sensor를 입력한다. 찾기 창에1 of 2가 보이고, 편집기가 다음 절에서 볼 서비스 인스턴스 매핑 안의 562행으로 이동한다.Enter를 한 번 누른다. 찾기 창에2 of 2가 보이고, 편집기가 575행으로 이동해 그 글자를 선택한다. 상태 표시줄은Ln 575, Col 80,25 selected이다. -
575행은 편집기 아래쪽에 있다. 블록 전체가 보이도록 마우스 휠을 아래로 몇 칸 굴려, 3줄 위의 572행
<PROCESS>가 편집기 위쪽에 오게 한다.
그림 13-5. 찾기로 이동한
PROCESS Sensor(571-614행). ① 572-573행<PROCESS>와SHORT-NAMESensor, ② 583-590행EXECUTION-DEPENDENCY(CM의Running), ③ 591-596행FUNCTION-GROUP-STATE-IREF(MachineFG의Startup), ④ 597행STARTUP-CONFIG-REF, ⑤ 찾기 창(/Executable/Sensor/Sensor,2 of 2). 575행에 찾은 글자가 선택되어 있고, 603행부터는STARTUP-CONFIGSensor가 이어진다.
참고. 편집기 맨 위의 5줄(줄 번호
2,3,199,201,534)은 파일의 그 자리에 있는 내용이 아니다. 지금 보이는 줄을 감싸는 상위 요소(AUTOSAR,AR-PACKAGES,AR-PACKAGE…)를 편집기 위쪽에 고정해 보여 주는 머리글이다.
블록 읽기
PROCESS Sensor 의 줄과, 그 값을 넣은 곳은 다음과 같다.
| 줄 | 내용 | 화면에서 넣은 곳 |
|---|---|---|
| 572-573 | <PROCESS>, <SHORT-NAME>Sensor</SHORT-NAME> | Executable 과 Process의 Process 이름 |
| 575 | EXECUTABLE-REF = /Executable/Sensor/Sensor | 같은 장의 Executable(이미 채워져 있음) |
| 577-580 | PROCESS-STATE-MACHINE Sensor, TYPE-TREF = /ModeDeclarationGroup/ProcessState | 입력 없음. 익스포터가 만든다 |
| 583-590 | EXECUTION-DEPENDENCY › PROCESS-STATE-IREF: /Executable/CM/Process/CM/CM, /ModeDeclarationGroup/ProcessState/Running | EXECUTION DEPENDENCY 행 CM : Running — CM 프로세스가 Running 이 된 뒤에 시작 |
| 591-596 | FUNCTION-GROUP-STATE-IREF: /MachineConfig/Ecu/FunctionGroup/Ecu_FunctionGroup/MachineFG, /ModeDeclarationGroup/MachineState/Startup | FUNCTION GROUP STATE 행 MachineFG : Startup |
| 597 | STARTUP-CONFIG-REF = /Executable/Sensor/StartupConfig/Sensor | 입력 없음. 아래 시작 설정을 가리킨다 |
| 603-616 | STARTUP-CONFIG Sensor: SCHEDULING-POLICY SCHED_OTHER, SCHEDULING-PRIORITY 0, ENTER-TIMEOUT-VALUE 5, EXIT-TIMEOUT-VALUE 5 | STARTUP CONFIG 의 ENTER TIMEOUT 5, EXIT TIMEOUT 5 |
나머지 프로세스도 같은 꼴이다. 같은 파일에서 다음 줄을 보면 된다.
| 프로세스 | 볼 곳 | 내용 |
|---|---|---|
Actuator | 251-258행 | Sensor 와 같은 EXECUTION-DEPENDENCY(/Executable/CM/Process/CM/CM, Running) |
Fusion | 488-495행 | 같은 EXECUTION-DEPENDENCY |
EM | 394-414행 | FUNCTION-GROUP-STATE-IREF(MachineFG, Startup). 참조 설계와 일부러 다르게 한 곳이다. 이 장 끝의 "SWC 파일" 표를 본다 |
서비스 인스턴스 매핑 Sensor_AA_Sensor 보기
찾기 문자열 바꾸기
-
찾기 창의 입력칸 내용을 지우고
Sensor_AA_Sensor를 입력한다. 찾기 창에1 of 1이 보이고, 편집기가 553행으로 이동한다. 상태 표시줄은Ln 553, Col 47,16 selected이다. -
앞에서와 같이 마우스 휠을 아래로 굴려 552행이 편집기 위쪽에 오게 한다.
그림 13-6. 찾기로 이동한 매핑 블록(551-594행). ① 552-553행
SERVICE-INSTANCE-TO-PORT-PROTOTYPE-MAPPING과SHORT-NAMESensor_AA_Sensor, ② 554-560행ADMIN-DATA(CLIENT-ID가 빈 값), ③ 561-564행PORT-PROTOTYPE-IREF, ④ 565행SERVICE-INSTANCE-REF(Provider_Sensor). 그 아래 569행부터는Process패키지와PROCESS Sensor의 앞부분이 보인다.
블록 읽기
| 줄 | 내용 | 뜻 |
|---|---|---|
| 552-553 | SHORT-NAME Sensor_AA_Sensor | 이름 규칙 <Executable>_<ROOT SWC PROTOTYPE>_<포트> |
| 554-560 | SDG GID="PARA-SOMEIP-CONFIGURATION" › <SD GID="CLIENT-ID"></SD> | 제공자 매핑이므로 비어 있다 |
| 562 | CONTEXT-ROOT-SW-COMPONENT-PROTOTYPE-REF = /Executable/Sensor/Sensor/AA | Executable Sensor 의 루트 프로토타입 AA |
| 563 | TARGET-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE" = /SwComponentType/AdaptiveApplication/Sensor/Sensor | Sensor 의 P 포트 Sensor |
| 565 | SERVICE-INSTANCE-REF DEST="PROVIDED-SOMEIP-SERVICE-INSTANCE" = /System/Service/Instance/SOMEIP/Provider/Provider_Sensor | SOME/IP 배포와 서비스 인스턴스의 제공 인스턴스 Provider_Sensor |
소비자 쪽 매핑 둘은 같은 꼴이고 CLIENT-ID 만 값이 있다.
| 매핑 | CLIENT-ID | 줄 |
|---|---|---|
Sensor_AA_Sensor | 빈 값 | 557행 |
Actuator_AA_Sensor | 1 | 225행 |
Fusion_AA_Sensor | 2 | 462행 |
참고. 파일에서 매핑은
PROCESS보다 앞에 있다. 그래서 그림 13-6 의 아래쪽에PROCESS Sensor가 다시 보인다.
참고. 562행은 패키지
/Executable/Sensor에 있는EXECUTABLESensor안의 루트 프로토타입AA를 가리킨다. 그래서 경로에Sensor가 두 번 나오고, 찾기 문자열/Executable/Sensor/Sensor가 이 줄도 찾았다. 참조 설계의 같은 블록은 이 자리가 한 단계 짧은/Executable/Sensor/AA로, 어떤 요소도 가리키지 않는다. 두 블록의 차이는 이 한 줄뿐이다.
DLT 애플리케이션 SENS 보기
DLT-APPLICATION 은 AADesign_SWC.arxml 이 아니라 AADesign_COM.arxml 에 있다. AADesign_SWC.arxml 에는 그 애플리케이션을 프로세스에 잇는 DLT-APPLICATION-TO-PROCESS-MAPPING Mapping_SENS_TO_Sensor(620-624행)만 있다.
AADesign_COM.arxml 을 열고 찾기
-
EXPORT 에서
AADesign_COM.arxml을 더블클릭한다. 두 번째 탭AADesign:AADesign_COM.arxml이 열린다. 상태 표시줄은✓ No problems이다. -
편집기 안을 클릭하고
Ctrl+F를 누른 뒤<APPLICATION-ID>SENS를 입력한다. 찾기 창에1 of 1이 보이고, 편집기가 446행으로 이동한다. 상태 표시줄은Ln 446, Col 39,20 selected이다. -
마우스 휠을 아래로 굴려 11줄 위의 435행
<DLT-APPLICATION>이 편집기 위쪽에 오게 한다.
그림 13-7.
AADesign_COM.arxml의DLT-APPLICATIONSENS(434-477행). ① 편집기 탭AADesign:AADesign_COM.arxml, ② 435-436행DLT-APPLICATION과SHORT-NAMESENS, ③ 439-443행PARA-DLT-CONFIGURATION(CONSOLE,VERBOSE), ④ 446행APPLICATION-IDSENS, ⑤ 449행DLT-CONTEXT-REF(/DLT/Context/SENS/DltContext_0). 아래에 454행ECU-IDECU1과Context패키지(ACTA…)가 이어진다.
블록 읽기
| 줄 | 내용 | 화면에서 넣은 곳 |
|---|---|---|
| 435-436 | DLT-APPLICATION, SHORT-NAME SENS | 로그와 DLT의 APPLICATION ID |
| 440 | <SD GID="LOG-MODE">CONSOLE</SD> | LOG MODE CONSOLE |
| 441 | <SD GID="LOG-LEVEL">VERBOSE</SD> | DEFAULT LOG LEVEL VERBOSE |
| 442 | <SD GID="LOG-FILE-PATH"/> | 비워 둔 값 |
| 446 | <APPLICATION-ID>SENS</APPLICATION-ID> | APPLICATION ID SENS |
| 449 | DLT-CONTEXT-REF = /DLT/Context/SENS/DltContext_0 | DLT CONTEXTS 에 추가한 컨텍스트 SENS |
| 454 | <ECU-ID>ECU1</ECU-ID> | 머신 설정의 Log and Trace › ECU ID |
나머지 DLT 애플리케이션은 다음과 같다.
| 애플리케이션 | 로그 모드 / 로그 레벨 | 컨텍스트 |
|---|---|---|
FUSN, ACTA | CONSOLE / VERBOSE | /DLT/Context/FUSN/DltContext_0, /DLT/Context/ACTA/DltContext_0 |
CM, EM | CONSOLE / FATAL | 없음 |
Context 패키지(458행부터)에는 ACTA, FUSN, SENS 아래에 DLT-CONTEXT DltContext_0 이 하나씩 있고, 각 CONTEXT-ID 는 ACTA, FUSN, SENS 이다. 컨텍스트의 이름이 DltContext_0 인 이유는 아래 표에 있다.
내 익스포트와 기준 파일의 차이
참조 설계의 파일 EM_Test_COM.arxml, EM_Test_DataType.arxml, EM_Test_Interface.arxml, EM_Test_SWC.arxml, EM_Test_System.arxml 을 내 익스포트와 나란히 놓으면 줄 수와 내용이 다르다. 이 절은 그 차이를 모두 모아 이유를 한 줄씩 적는다. 비교는 이름(SHORT-NAME)이 있는 요소를 패키지 경로로 짝지어 했다.
요약
| 참조 설계 | 내 익스포트 | |
|---|---|---|
| 이름이 있는 요소(패키지 포함) | 245 | 289 |
| 경로가 같고 값과 참조까지 같은 요소 | 204 | 204 |
| 경로는 같고 값이나 참조가 다른 요소 | 23 | 23 |
| 다른 패키지로 옮겨진 요소 | 6 | 6 |
| 같은 자리에서 이름이 바뀐 요소 | 6 | 6 |
| 참조 설계에만 있는 요소 | 6 | — |
| 내 익스포트에만 있는 요소 | — | 50 |
AADesign_Interface.arxml은EM_Test_Interface.arxml과 바이트 단위로 같다.- 설계 내용은 모두 같다. 서비스 인터페이스, SOME/IP 배포와 인스턴스, 서비스 디스커버리 설정, 엔드포인트, Adaptive Application 다섯 개와 포트, 커넥터, Executable, Process 의 시작 설정 값, 실행 의존성, 서비스 인스턴스 매핑, DLT 애플리케이션과 ECU, 데이터 타입, 시스템 매핑이다.
- 다른 곳의 이유는 다섯 가지이다.
| 이유 | 뜻 |
|---|---|
| 참조 설계의 결함 | 참조 설계 파일이 다른 설계에서 옮겨 오며 남긴 끊어진 참조나 엇갈린 머신 디자인 |
| 이름 규칙 | PAIO 익스포터가 정해 둔 이름과 경로 |
| 자동 생성 | PAIO 가 화면에서 만든 프로젝트에 스스로 넣는 요소 |
| 튜토리얼의 의도 | 이 튜토리얼이 일부러 다르게 한 값 |
| 화면에 입력칸 없음 | PAIO 화면으로 넣을 수 없는 값 |
주의.
EM을MachineFG : Startup에 묶은 것은 참조 설계와 일부러 다르게 한 곳이다. 내 익스포트의PROCESS EM(AADesign_SWC.arxml394-414행)에는FUNCTION-GROUP-STATE-IREF(/MachineConfig/Ecu/FunctionGroup/Ecu_FunctionGroup/MachineFG,/ModeDeclarationGroup/MachineState/Startup)가 있다. 참조 설계의EM에는 이것이 없다. 그 모양은 PAIO 검증이The process "EM" declares no functionGroupState; at least one is required.로 거부하므로, Executable 과 Process에서EM을Startup에 묶었다.
Interface 파일
| 요소 | 결과 | 이유 |
|---|---|---|
| 파일 전체 | 같음 | 바이트 단위로 같다 |
DataType 파일
| 요소 | 결과 | 이유 |
|---|---|---|
STD-CPP-IMPLEMENTATION-DATA-TYPE String | 값 다름: <ARRAY-SIZE>256</ARRAY-SIZE> 가 더 있음(502행) | 이름 규칙: 데이터 타입에서 넣은 MAX SIZE 256 을 ARRAY-SIZE 로 내보낸다. 참조 설계의 String 에는 최대 크기가 없다 |
APPLICATION-PRIMITIVE-DATA-TYPE String | 값 다름: SW-TEXT-PROPS(ARRAY-SIZE-SEMANTICS VARIABLE-SIZE, SW-MAX-TEXT-SIZE 256, BASE-TYPE-REF uint16)가 더 있음 | 이름 규칙: 문자열 타입을 내보내는 PAIO 의 표준 형태이다. 참조 설계는 CATEGORY STRING 뿐이다 |
IMPLEMENTATION-DATA-TYPE ByteArray, String(CP 측 미러), APPLICATION-ARRAY-DATA-TYPE ByteArray | 값 다름: DYNAMIC-ARRAY-SIZE-PROFILE 이 VSA_LINEAR(참조 설계는 빈 값이거나 없음). IMPLEMENTATION-DATA-TYPE 두 개는 배열 크기(1, 256)와 ARRAY-SIZE-SEMANTICS 가 한 단계 안쪽 요소로 옮겨 가고, 그 요소에 ARRAY-SIZE-HANDLING ALL-INDICES-SAME-ARRAY-SIZE 가 더 있음. APPLICATION-ARRAY-DATA-TYPE 은 MAX-NUMBER-OF-ELEMENTS 1 을 요소에만 두고, 그 요소에 ARRAY-SIZE-HANDLING 이 더 있음 | 이름 규칙: 가변 크기 배열인 DYNAMIC_ARRAY ByteArray 와 STRING String 을 내보내는 PAIO 의 표준 형태이다. 크기 1, 256 은 같다 |
SW-BASE-TYPE void, IMPLEMENTATION-DATA-TYPE VoidPtr, ConstVoidPtr | 내 익스포트에만 있음 | 자동 생성: 데이터 타입의 내장 포인터 타입 두 개와 그 기본 타입이다. PAIO 가 프리미티브 타입처럼 모든 익스포트에 넣는다. 이 설계는 쓰지 않는다 |
나머지 타입(STD-CPP-IMPLEMENTATION-DATA-TYPE ByteArray, 프리미티브와 그 CP 측 미러, DATA-TYPE-MAPPING-SET) | 같음 | ByteArray 의 네임스페이스 aa, type 까지 같다 |
COM 파일
| 요소 | 결과 | 이유 |
|---|---|---|
MACHINE-DESIGN HPC(빈 요소) | 참조 설계에만 있음 | 참조 설계의 결함: 참조 설계는 머신 디자인이 Ecu(커넥터)와 HPC(컴포지션 매핑) 둘로 엇갈려 있다. 튜토리얼은 노드 Ecu 하나에 둘 다 붙인다 |
ETHERNET-COMMUNICATION-CONNECTOR eth0 | 값 다름: COMM-CONTROLLER-REF → Ecu_EthernetController 가 더 있음(15행) | 자동 생성: 토폴로지에서 컨트롤러를 만들어 커넥터의 Controller 로 고른 결과이다 |
ETHERNET-COMMUNICATION-CONTROLLER Ecu_EthernetController | 내 익스포트에만 있음 | 위와 같은 이유이다 |
SOMEIP-SD-CLIENT-EVENT-GROUP-TIMING-CONFIG SdEventgroupConfig_Actuator_Sensor_Eventgroup_SensorData, SdEventgroupConfig_Fusion_Sensor_Eventgroup_SensorData(298-317행) | 내 익스포트에만 있음 | 자동 생성, 참조 설계의 결함: 익스포터가 소비자마다 이벤트 그룹의 구독 타이밍을 별도 요소로 쓴다. 값은 SOME/IP 배포와 서비스 인스턴스의 소비자 카드 EVENT GROUPS 에 있는 값이며, 이 튜토리얼은 기본값 그대로 둔다(REQUEST-RESPONSE-DELAY 0/0, SUBSCRIBE-EVENTGROUP-RETRY-DELAY 0.5, SUBSCRIBE-EVENTGROUP-RETRY-MAX 3, TIME-TO-LIVE 16777215). 참조 설계의 두 소비자 이벤트 그룹도 이 두 이름을 가리키지만, 참조 설계에는 그 정의가 없다. 내 익스포트에서는 같은 참조가 찾아진다 |
DLT-APPLICATION SENS, FUSN, ACTA | 값 다름: DLT-CONTEXT-REF 의 마지막 부분이 SENS → DltContext_0(FUSN, ACTA 도 같음) | 아래 DLT-CONTEXT 행의 짝이다. 로그 모드, 로그 레벨, APPLICATION-ID 는 같다 |
DLT-CONTEXT SENS, FUSN, ACTA | 이름 바뀜: …/SENS/SENS → …/SENS/DltContext_0 등 | 이름 규칙, 화면에 입력칸 없음: 익스포터가 컨텍스트 이름을 DltContext_<번호> 로 정한다. 화면에는 컨텍스트 이름을 넣는 칸이 없다. CONTEXT-ID 값 SENS 등은 그대로이다 |
머신 디자인 Ecu, 엔드포인트, SOME/IP 배포, 인스턴스, 서비스 디스커버리 설정, 인스턴스와 머신의 매핑, DLT-ECU, DLT-APPLICATION CM, EM | 같음 |
System 파일
| 요소 | 결과 | 이유 |
|---|---|---|
SYSTEM System | 값 다름: FIBEX-ELEMENTS 가 참조 설계의 3개(MACHINE-DESIGN Ecu, MACHINE-DESIGN HPC, ETHERNET-CLUSTER)에서 2개(12행 MACHINE-DESIGN Ecu, 15행 ETHERNET-CLUSTER)로 | HPC 가 없는 것은 COM 파일의 MACHINE-DESIGN HPC 행의 짝이다 |
SWC-TO-ECU-MAPPING | 이름 바뀜: SwMapping_HPC_to_HPC → SwMapping_HPC_to_Ecu | 이름 규칙 SwMapping_<컴포지션>_to_<ECU>: 참조 설계는 빈 머신 디자인 HPC 에 매핑했고(참조 설계의 결함), 튜토리얼은 노드 Ecu 에 매핑한다. 컴포지션을 가리키는 두 참조는 같다 |
SYSTEM-MAPPING, 루트 컴포지션 프로토타입 System | 같음 |
SWC 파일
| 요소 | 결과 | 이유 |
|---|---|---|
PROCESS Sensor, Fusion, Actuator | 값 다름: 실행 의존성과 함수 그룹 상태의 참조 경로 4개가 PAIO 경로(/Executable/CM/Process/CM/CM, /ModeDeclarationGroup/ProcessState/Running, /MachineConfig/Ecu/FunctionGroup/Ecu_FunctionGroup/MachineFG, /ModeDeclarationGroup/MachineState/Startup)이고 RESOURCE-GROUP-REF 가 없음 | 참조 설계의 결함: 참조 설계의 네 경로(/AdaptiveApplication/Process/CM/CM, /StateMachine/ProcessState/Running, /Platform/FunctionGroup/FunctionGroup/MachineFG, /StateMachine/MachineState/Startup)는 다섯 파일 안에서 찾을 수 없는 경로이다. 내 익스포트의 경로는 모두 같은 파일 안에서 찾아진다 |
PROCESS CM | 값 다름: 함수 그룹 상태 4개의 경로가 위와 같이 바뀌고 RESOURCE-GROUP-REF 가 없음 | 위와 같은 이유이다 |
PROCESS EM | 값 다름: FUNCTION-GROUP-STATE-IREF(MachineFG, Startup)가 더 있음(394-414행) | 튜토리얼의 의도: 위 "주의" 를 본다 |
SERVICE-INSTANCE-TO-PORT-PROTOTYPE-MAPPING Actuator_AA_Sensor, Fusion_AA_Sensor, Sensor_AA_Sensor | 값 다름: CONTEXT-ROOT-SW-COMPONENT-PROTOTYPE-REF 가 /Executable/<이름>/AA 에서 /Executable/<이름>/<이름>/AA 로(230행, 467행, 562행) | 참조 설계의 결함: 참조 설계의 경로는 한 단계 짧아 어떤 요소도 가리키지 않고, 내 익스포트의 경로는 각 Executable 의 루트 프로토타입 AA 를 가리킨다. 세 블록의 나머지는 같다 |
RESOURCE-GROUP-REF(프로세스 4개) | 참조 설계에만 있음 | 이름 규칙, 화면에 입력칸 없음: 머신 설정 화면의 OS 칸에 넣은 POSIX 는 머신의 속성으로만 저장되며, 익스포터가 이 값으로 OS-MODULE-INSTANTIATION POSIX 요소를 쓴다(아래 "머신 패키지" 행). 그러나 머신 설정 화면이 미리 만드는 모듈 목록(MODULE 탭)에는 OS 모듈 항목이 없고, 익스포터는 이 목록에 OS 모듈 항목이 있을 때만 프로세스의 RESOURCE-GROUP-REF 를 쓴다. 참조 설계의 이 참조도 찾을 수 없는 경로(/Platform/HPCMachine/POSIX/ResourceGroup)였다 |
RESOURCE-GROUP ResourceGroup | 참조 설계에만 있음 | 이름 규칙: 익스포터는 공유 리소스 그룹 하나 대신 프로세스마다 그룹을 만든다(아래 행) |
RESOURCE-GROUP Sensor_ResourceGroup, Fusion_ResourceGroup, Actuator_ResourceGroup, CM_ResourceGroup, EM_ResourceGroup(CPU-USAGE 0, MEM-USAGE 0) | 내 익스포트에만 있음 | 이름 규칙: 각 Adaptive Application 의 CPU USAGE, MEM USAGE 를 프로세스별 그룹으로 내보낸다. 값이 0 이어도 쓴다 |
머신 패키지 /Machine/HPCMachine | 참조 설계에만 있음: 내 익스포트는 MACHINE Ecu 를 패키지 /Machine 에 바로 두고(634행), 머신의 함수 그룹과 프로세스 매핑은 /MachineConfig/Ecu 아래에 둠 | 이름 규칙, 화면에 입력칸 없음: PAIO 는 머신을 HPC 노드 이름(여기서는 Ecu)으로 /Machine 에 두고, 그 설정 패키지는 /MachineConfig/<머신> 에 둔다. 화면에는 머신 이름을 넣는 칸이 없다. PROCESSOR CPU, 코어 Core0 … Core3, OS-MODULE-INSTANTIATION POSIX 는 값이 같은 채로 /Machine/HPCMachine/HPCMachine 에서 /Machine/Ecu 로 옮겨진다 |
MACHINE HPCMachine → MACHINE Ecu | 이름 바뀜. MACHINE-DESIGN-REF 도 /System/VehicleTopology/Ecu/Ecu 에서 /System/MachineDesign/Ecu 로(634-636행) | 위와 같은 이유이다. 참조 설계의 결함: 참조 설계의 경로는 다섯 파일 안의 어떤 요소도 가리키지 않고, 내 익스포트의 경로는 COM 파일의 MACHINE-DESIGN Ecu 를 가리킨다. 실제로 잃는 값은 ADMIN-DATA 의 WAIT-FOR-SHUTDOWN 1 하나이다. 머신 설정 화면에 이 칸이 없다 |
ROOT-SW-COMPONENT-PROTOTYPE CM, EM 의 RootSwComponent | 이름 바뀜: AA | 튜토리얼의 의도: 참조 설계는 Sensor, Fusion, Actuator 가 AA, CM 과 EM 이 RootSwComponent 로 섞여 있다. 튜토리얼은 다섯 모두 ROOT SWC PROTOTYPE 기본값 AA 이다 |
CM-MODULE-INSTANTIATION CmModuleInstantiation(REQUEST-TIMEOUT 10, ALIVE-CHECK-INTERVAL 0, MAX-DATA-BYTES 0) | 이름 바뀜: LOCAL-COM-ACCESS-CONTROL-ENABLED false 와 REMOTE-ACCESS-CONTROL-ENABLED false 만 있는 CM(644-645행) | 화면에 입력칸 없음: Communication Management 모듈 화면에는 이 세 값을 넣는 칸이 없다. 익스포터는 접근 제어 플래그 두 개를 항상 쓰며, 이 튜토리얼은 둘을 켜지 않는다. 이름 CM 은 머신 설정 화면의 기본 이름이다 |
LOG-AND-TRACE-INSTANTIATION Log | 이름 바뀜: LOG | 이름 규칙: 머신 설정 화면의 기본 이름이다. DLT-ECU-REF → /DLT/Ecu/Ecu 는 같다 |
STATE-MANAGEMENT-MODULE-INSTANTIATION SM(MAX-ACTION-LIST-DURATION 1000) | 내 익스포트에만 있음 | 튜토리얼의 의도: 머신 설정에서 constr_10641 을 없애려고 넣은 값이다. 참조 설계에는 상태 관리 모듈이 없다 |
NM-INSTANTIATION NM, TIME-SYNC-MODULE-INSTANTIATION TIME_SYNC, CRYPTO-MODULE-INSTANTIATION CRYPTO, IDSM-MODULE-INSTANTIATION IDSM, UCM-MASTER-MODULE-INSTANTIATION VUCM(하위 요소 4개 포함), UCM-SUBORDINATE-MODULE-INSTANTIATION UCM(하위 요소 3개 포함) | 내 익스포트에만 있음 | 자동 생성: 머신 설정 화면이 모듈을 미리 만들어 두고, 익스포터는 값이 없는 모듈도 내보낸다 |
함수 그룹 패키지 /MachineConfig/Ecu/FunctionGroup, FUNCTION-GROUP-SET Ecu_FunctionGroup, 함수 그룹 MachineFG | 내 익스포트에만 있음 | 자동 생성, 참조 설계의 결함: 머신의 기본 함수 그룹 MachineFG 가 그대로 나온다. 참조 설계는 프로세스 7곳이 MachineFG 를 가리키면서 그 정의가 없었다 |
MODE-TRANSITION 8개(Off_To_Startup, Startup_To_Shutdown, Startup_To_Restart, Startup_To_Verify, Startup_To_Off, Shutdown_To_Off, Restart_To_Off, Verify_To_Off) | 내 익스포트에만 있음 | 자동 생성: MachineFG 상태 머신의 기본 전이이다. 참조 설계의 MachineState 에는 전이가 없다 |
PROCESS-TO-MACHINE-MAPPING-SET Ecu_ProcessToMachineMapping 과 매핑 5개(Sensor_To_Ecu_Mapping … EM_To_Ecu_Mapping) | 내 익스포트에만 있음 | 자동 생성: 프로세스 다섯 개가 머신 Ecu 에 놓인 결과를 익스포터가 내보낸다. 코어 배정을 하지 않아도 나온다 |
Adaptive Application 다섯 개와 포트, 컴포지션 HPC, System, 커넥터 2개, MachineState, ProcessState, Executable 5개, PROCESS-STATE-MACHINE 5개, STARTUP-CONFIG 5개, DLT-APPLICATION-TO-PROCESS-MAPPING 5개 | 같음 |
확인하기
- EDITOR 뷰의 EXPORT 에
AADesign_COM.arxml,AADesign_DataType.arxml,AADesign_Interface.arxml,AADesign_SWC.arxml,AADesign_System.arxml다섯 개가 있다. - 익스포트 진행 창 Exporting to AUTOSAR 에
Export complete: 30 elements exported to AADesign_*.arxml와✓ Complete!가 보였고, 창이 닫혔다. - 편집기 탭
AADesign:AADesign_SWC.arxml과AADesign:AADesign_COM.arxml의 상태 표시줄이Schema: R25-11과✓ No problems이다. -
AADesign_SWC.arxml에서/Executable/Sensor/Sensor를 찾으면1 of 2,Enter한 번이면 575행의2 of 2이고, 572행PROCESS Sensor의 583-590행에/Executable/CM/Process/CM/CM과Running, 591-596행에MachineFG와Startup이 있다. -
AADesign_SWC.arxml에서Sensor_AA_Sensor를 찾으면1 of 1이고, 565행이/System/Service/Instance/SOMEIP/Provider/Provider_Sensor를 가리킨다. -
AADesign_COM.arxml에서<APPLICATION-ID>SENS를 찾으면1 of 1이고, 그 블록에CONSOLE,VERBOSE,/DLT/Context/SENS/DltContext_0이 있다. - 두 탭 어느 것에도 수정됨 표시
●가 없다.
다음 단계
튜토리얼의 본문은 여기까지이다. 이어서 부록을 본다.