부록
이 장에서 할 일
이 부록은 따라 하는 장이 아니라 참고 자료이다. 튜토리얼을 마친 뒤 자신의 PNC 설계를 점검할 때, 또는 화면에 보이지 않는 값이 파일에 어떻게 기록되는지 확인할 때 본다.
다섯 부분으로 나뉜다. 설계 체크리스트, 프로젝트 파일 구조, 모델 조각, 직접 만든 프로젝트와 완성 예제의 차이, 자주 겪는 문제이다.
시작하기 전에
- 앞 장인 ARXML 익스포트까지 마쳤다면 그 상태 그대로 읽으면 된다.
- 체크리스트만 쓰려면 완성된 모델이 없어도 된다. 자신의 프로젝트에 그대로 적용할 수 있다.
설계 체크리스트
PNC 설계를 마친 뒤, 또는 이 튜토리얼과 다른 차량으로 설계할 때 다음을 차례로 확인한다. 각 항목 뒤의 링크는 그 항목을 다룬 장이다.
- PNC 식별자가
pncVectorOffset × 8이상,(pncVectorOffset + pncVectorLength) × 8 − 1이하인가(constr_3040). 1장, 3장 - 모든 커넥터의 PNC 필터 배열 마스크 길이가
pncVectorLength와 같은가. 3장 - 물리 채널마다
pncGatewayType이 active 인 커넥터가 최대 1개인가(constr_5093). 3장, 11장 - PNC마다 최상위 PNC 코디네이터가 있는가. 관련 채널 2개 이상에 연결되고 그 연결이 모두 active 인 ECU가 필요하다(
constr_3781). 2장 - PNC별 I-PDU Group이 Rx/Tx 쌍으로 있고, PNC 다이얼로그의 PNC GROUPS에 바인딩되어 있는가. 4장, 7장
- PNC가 지나는 버스의 NM 클러스터마다 NM PNC PARTICIPATION이 YES이고, NM 타이밍 필수 속성(
constr_9157,constr_9158,constr_9159,constr_9162, UdpNm은constr_5222)이 채워져 있는가. 3장 - NM 노드마다 NM NODE ID가 클러스터 안에서 겹치지 않고, TX-NM-PDU-REFS가 자기 NM-PDU 1개(
constr_9388), RX-NM-PDU-REFS가 같은 클러스터의 나머지인가. 3장, 4장 - VFC 이름이 원자 SWC, ECU 컴포지션, 루트 컴포지션까지 모두 같은가(VFC 패밀리). 6장
- AP 머신의 NM 네트워크 핸들이 PNC를 참조하고, ACTIVE 와 INACTIVE 양쪽 FunctionGroup 상태 매핑을 갖는가. 9장
- PNC를 요청하는 응용 AA가
NetworkManagementPortInterfaceP-Port 와 NetworkHandle 매핑을 갖는가. PARA 플랫폼이 임포트되어 SM, NM 모듈이 실제 AA와 연결되는가. 10장 - 웨이크업 프레임이 실제 버스에 존재하는 프레임을 가리키는가(Classic Platform 쪽). 7장
- VALIDATION 패널이 0건이고, 익스포트 결과가
PNC_COM.arxml의 익스포트 자체에서 생기는 오류를 빼면 스키마 검사 0 오류인가. 11장, 12장
프로젝트 파일 구조
PAIO 프로젝트는 폴더 하나이다. 이 튜토리얼이 만드는 PNC 프로젝트에서 설계와 관련된 파일은 모두 design/ 아래에 있다.
PNC/
├─ PNC.io.prj
└─ design/
├─ IVC.io.model 토폴로지, 커넥터 PNC 속성, 스위치 포트 PNC 참조, NM 설정
├─ SIGNAL.io.model 신호, PDU, 프레임, NM-PDU, I-PDU Group
├─ SYSTEM.io.model PNC 매핑, PNC 벡터 오프셋과 길이, SWC-ECU 매핑
├─ INTERFACE.io.model SR 인터페이스, 서비스 인터페이스, NM 인터페이스
├─ SERVICE.io.model SOME/IP 배포, 제공자와 소비자 인스턴스
├─ VFB.io.model 컴포지션 목록
├─ DATATYPE.io.model 데이터 타입
├─ SWC/
│ ├─ Application/ 원자 SWC 9개. PortGroup(= VFC)이 여기 들어간다.
│ ├─ AdaptiveApplication/ AP 앱 3개. PARA 플랫폼 AA는 하위 폴더 HPC/에 들어간다.
│ ├─ Composition/ 노드 컴포지션 14개, 루트 PncVehicle, PARA_HPC
│ └─ Layout/ VFB 캔버스 배치(뷰 상태)
└─ Module/
└─ Machine/
└─ HPC.machine.io.model FunctionGroup, NM 네트워크 핸들, AP 모듈 설정
프로젝트 폴더에는 이 밖에 code, doc, export, import, workflow 폴더가 있다. ARXML 익스포트의 결과는 export 아래에 생긴다.
어느 편집기가 어느 파일을 쓰는지는 예제와 설계 목표의 5개 층 표에 정리되어 있다.
모델 조각
화면에 보이는 값이 파일에 어떻게 기록되는지 보여 주는 발췌이다. 완성 예제에서 가져온 실제 값이다. 파일을 직접 편집할 필요는 없다. 값이 어디에 있는지 확인하는 용도이다.
SYSTEM.io.model — PNC 매핑 한 항목
PNC 다이얼로그 — PNC별 바인딩에서 PNC_ParkAssist에 입력한 내용이 그대로 한 덩어리로 기록된다. VFC, I-PDU Group, 물리 채널, 서비스 인스턴스가 모두 여기 모인다.
{
"pnc-id": 18,
"short-label": "PNC_ParkAssist",
"vfc-refs": [{ "target-port-group": "/SwComponentType/Composition/PncVehicle/VFC_ParkAssist",
"context-composition": "/System/PncVehicle/PncVehicle" }],
"pnc-group-refs": ["RearCAN_PNC_ParkAssist_Rx", "RearCAN_PNC_ParkAssist_Tx"],
"physical-channel-refs": [
"ETHERNET-PHYSICAL-CHANNEL|/System/CommunicationCluster/Ethernet/Backbone/VLAN_Rear",
"CAN-PHYSICAL-CHANNEL|/System/CommunicationCluster/Can/RearCAN/RearCAN_Channel" ],
"service-instance-refs": [
"PROVIDED-SOMEIP-SERVICE-INSTANCE|/System/Service/Instance/SOMEIP/Provider/ParkDistance_Provider",
"REQUIRED-SOMEIP-SERVICE-INSTANCE|/System/Service/Instance/SOMEIP/Consumer/ParkDistance_Consumer" ]
}
같은 파일에 전역 값 "pnc-vector-offset": 2와 "pnc-vector-length": 6이 있다. 예제와 설계 목표에서 식별자 범위를 계산할 때 쓴 값이다.
IVC.io.model — Zone CAN 커넥터의 PNC 속성
PNC 정의와 커넥터 PNC 속성에서 입력한 게이트웨이, 웨이크업, 필터 마스크이다.
{
"name": "SouthZone_CanFd_Conn", "controller": "SouthZone_CanFd", "type": "can",
"pnc-gateway-type": "active",
"create-ecu-wakeup-source": true,
"pnc-mappings": [{ "pnc-id": 18, "pnc-name": "PNC_ParkAssist" }, { "pnc-id": 19, "pnc-name": "PNC_Trailer" }],
"pnc-filter-array-masks": [12, 0, 0, 0, 0, 0],
"pnc-wakeup-can-id": 1280, "pnc-wakeup-can-id-extended": false,
"pnc-wakeup-can-id-mask": 1792, "pnc-wakeup-dlc": 8,
"tx-frames": ["RearCAN_NmFrame_SouthZone", "RearCAN_TrailerCmd", "RearCAN_TailLampCmd"],
"rx-frames": ["RearCAN_ParkDistance", "RearCAN_TrailerStatus", "RearCAN_TailLampStatus"]
}
읽는 요령은 다음과 같다.
| 필드 | 값 | 뜻 |
|---|---|---|
pnc-filter-array-masks | [12, 0, 0, 0, 0, 0] | 길이 6은 pnc-vector-length와 같다. 첫 바이트 12는 2진수로 00001100, 즉 비트 2와 비트 3이다. 벡터가 비트 16에서 시작하므로 PNC 18과 19를 뜻한다. |
pnc-wakeup-can-id | 1280 | 16진수로 0x500이다. |
pnc-wakeup-can-id-mask | 1792 | 16진수로 0x700이다. 0x500부터 0x5FF까지의 프레임이 웨이크업으로 걸린다. |
pnc-mappings | PNC 18, 19 | 이 커넥터가 어느 PNC에 참여하는지 선언한다. 화면에 편집란이 없는 값이다. |
HPC.machine.io.model — NM 네트워크 핸들
AP 머신 — NM 핸들과 FunctionGroup에서 만든 핸들이다. 매핑이 두 방향으로 하나씩 있는 점을 확인한다.
{ "type": "nm", "name": "NM", "network-handles": [
{ "name": "NH_ParkAssist",
"vlan-refs": ["HPC_Eth_Rear_Conn"],
"partial-network-refs": ["/System/PncVehicle/SystemMapping/PNC_ParkAssist"],
"function-group-state-mappings": [
{ "mapping-direction": "FUNCTION-GROUP-STATE-TO-NM-HANDLE",
"function-group-states": [{ "context-function-group-ref": "ParkAssistFG", "target-state-ref": "Active" }] },
{ "mapping-direction": "NM-HANDLE-INACTIVE-TO-FUNCTION-GROUP-STATE",
"function-group-states": [{ "context-function-group-ref": "ParkAssistFG", "target-state-ref": "Off" }] } ] } ] }
앞 방향은 "ParkAssistFG가 Active가 되면 이 PNC를 요청한다", 뒤 방향은 "이 PNC가 내려가면 ParkAssistFG를 Off로 내린다"는 뜻이다.
직접 만든 프로젝트와 완성 예제의 차이
이 튜토리얼을 토폴로지 설계부터 끝까지 따라 만든 프로젝트는 완성 예제와 완전히 같지 않다. 현재 버전에 만드는 화면이 없는 값이 몇 가지 있기 때문이다. 무엇이 다른지, 왜 다른지, 무엇에 영향을 주는지는 다음 표와 같다. 개수는 완성 예제의 design/ 파일에서 센 값이다.
| 항목 | 완성 예제 | 따라 만든 프로젝트 | 왜 다른가 | 영향과 우회 |
|---|---|---|---|---|
| CAN NM 프레임 | NM 프레임 13개. CAN 프레임은 모두 29개 | 0개. CAN 프레임은 응용 프레임 16개 | Signal 편집기에서 CAN 프레임의 PDU REFERENCES 후보에 I-Signal I-PDU(와 N-PDU)만 나오고 NM-PDU는 나오지 않는다 | NM-PDU 18개는 만들지만 프레임에 실리지 않아 NM 통신이 완성되지 않는다. PNC 다이얼로그 — PNC별 바인딩의 WAKEUP FRAMES 후보가 29개가 아니라 16개이고, 예제가 고른 NM 프레임 3개가 후보에 없어 웨이크업 프레임을 지정할 수 없다. 우회: ARXML 임포트 |
| NM 클러스터 커플링 | 2개. UdpNm 커플링 1개(NmCluster_VLAN_Body, NmCluster_VLAN_Rear), CanNm 커플링 1개(CAN 클러스터 3개) | 없음 | 커플링을 만들거나 고치는 화면이 없다 | 익스포트한 PNC_COM.arxml에 <UDP-NM-CLUSTER-COUPLING>과 <CAN-NM-CLUSTER-COUPLING>이 생기지 않는다. 검증은 통과한다. constr_9165와 constr_9166은 커플링이 있을 때만 검사하기 때문이다. 우회: ARXML 임포트 |
| 컨테이너 I-PDU Group과 NoPnc I-PDU Group | I-PDU Group 20개. PNC 리프 8개, 컨테이너 6개(WestCAN_Rx, WestCAN_Tx, RearCAN_Rx, RearCAN_Tx, EastCAN_Rx, EastCAN_Tx), NoPnc 6개(모두 비어 있음) | 8개. PNC 리프만 | 두 종류를 만드는 전용 화면이 없다. PNC GROUPS의 + 버튼으로 만들면 선택한 PNC에 묶인다 | 검증 결과와 PNC에 묶인 그룹의 내용은 같다. 익스포트한 PNC_COM.arxml의 <I-SIGNAL-I-PDU-GROUP>이 20개가 아니라 8개이고, <ECU-INSTANCE>의 <ASSOCIATED-COM-I-PDU-GROUP-REFS>도 그만큼 줄어든다. 우회: ARXML 임포트 |
통신 클러스터의 전송 프로토콜(tp-config)과 VLAN 설정 | tp-config 없음. Backbone에 VLAN 이름을 VLAN_Body, VLAN_Rear로 정하는 vlan-configs가 있음 | CanTpConfig가 없는 빈 tp-config가 있고, vlan-configs는 없음 | Communication Cluster Configuration 대화상자에서 Ctrl+S를 누르면 빈 tp-config가 추가된다. 전송 프로토콜은 클러스터마다 켜는 기능이고 이 튜토리얼에서는 꺼져 있다. vlan-configs에는 화면의 편집란이 없다 | 빈 tp-config는 NM 설정에서 NM 값을 저장하면 생긴다. 두 차이 모두 검증 오류를 만들지 않고, 설계 내용과 PNC 관련 익스포트 결과에도 영향이 없다. 우회: 없음 |
두 번째 UdpNm 클러스터(NmCluster_VLAN_Rear)의 값 | NM 타이밍, USER DATA, NETWORK CONFIGURATION (UDP)(IPv4 239.200.0.1)이 모두 채워져 있음 | 자동으로 만들어질 때의 기본값 그대로 | 통신 클러스터 하나에 붙은 NM 클러스터 가운데 첫 번째만 대화상자에 실린다. Backbone을 더블클릭하면 언제나 NmCluster_VLAN_Body가 열리고, NmCluster_VLAN_Rear를 여는 화면이 없다 | NM 설정의 전체 NM 값 표에서 이 클러스터 한 행만 입력할 수 없다. NM PNC PARTICIPATION과 USER DATA 네 값이 비어 있는 채로 남으므로, VLAN_Rear 위의 NM은 예제와 같이 동작하지 않는다. PNC_ParkAssist와 PNC_Trailer가 이 채널을 쓴다. 우회: ARXML 임포트 |
커넥터의 PNC 참여 선언(pnc-mappings) | CAN 커넥터 13개에 기록 | 없음 | 속성 패널에 편집란이 없다. ARXML 임포트도 이 값을 채우지 않는다. AUTOSAR에 대응하는 요소가 없기 때문이다 | ARXML에 이 값만의 요소는 없다. 익스포트할 때 <ECU-INSTANCE>의 <ASSOCIATED-COM-I-PDU-GROUP-REFS>를 정하는 "어느 ECU가 어느 PNC에 참여하는가"의 두 출처 가운데 하나이고, 다른 하나는 PNC 매핑의 VFC 참조이다. 이 예제에서는 VFC 참조가 같은 ECU를 모두 덮으므로 익스포트 결과가 같다. 우회: 없음 |
| 루트 컴포지션 이름과 시스템 정보 | 루트 PncVehicle. NAME PncVehicle, VERSION 1.0.0, DESCRIPTION Zonal PNC tutorial vehicle | 루트 System. 나머지는 새 프로젝트의 기본값 | 새 프로젝트의 루트 이름은 System이고, 이 튜토리얼에는 루트 이름이나 SYSTEM 패널의 값을 바꾸는 절차가 없다 | 캔버스 왼쪽 위 라벨과 System 에디터와 검증의 SYSTEM 패널이 다르게 보인다. 익스포트한 PNC_System.arxml의 <SHORT-NAME>과 그 이름을 지나는 경로(/System/PncVehicle/…)도 달라진다. 설계 내용에는 영향이 없다 |
| AP 머신의 모듈 인스턴스 | 7개. LOG, CM, SM, NM, PHM, TIME_SYNC, CRYPTO | 11개. 위 7개에 PERSISTENCY, IDSM, UCM, DM이 더 있음 | Machine Configuration 다이얼로그가 항상 모듈 11개를 보여 주고, 저장하면 11개가 그대로 파일에 기록된다 | 머신 파일에 모듈 4개가 더 생긴다. PNC 설계와 검증에는 영향이 없다 |
| PARA 플랫폼의 형식과 상태 클라이언트 인터페이스 | 컴포지션 타입 PARA. AA는 SWC/AdaptiveApplication/ 바로 아래에 있음. 상태 클라이언트 인터페이스는 StateClient_MachineFG 1개 | 컴포지션 타입 PARA_HPC. AA는 SWC/AdaptiveApplication/HPC/ 아래에 있음. 상태 클라이언트 인터페이스는 StateClient_HPC_MachineFG, StateClient_ParkAssistFG, StateClient_TrailerFG, StateClient_ComfortFG | 완성 예제는 이전 형식의 PARA를 그대로 쓴다. 10장의 임포트는 컴포지션과 그 상태 클라이언트 인터페이스 이름에 머신 이름 HPC를 붙이고, 9장에서 FunctionGroup을 추가하면 FunctionGroup마다 StateClient_ 인터페이스가 생긴다 | HPC 안에서 프로토타입 PARA의 노드가 예제에서는 PARA, 직접 만든 프로젝트에서는 PARA_HPC로 보인다. 예제의 Machine Configuration 다이얼로그에는 Migrate PARA Base Set to per-Machine layout 버튼도 보인다. PNC 설계와 검증에는 영향이 없다 |
| SOME/IP 배포에서 파생된 신호와 PDU | 없음 | SVC_ParkDistance_SR 같은 SENDER-RECEIVER 인터페이스와 SVC_…_PDU 이름의 PDU | SOA 배포를 추가하거나 인스턴스의 포트를 고치면 PAIO가 CP-SOA 신호와 PDU를 자동으로 파생한다 | 파생된 PDU는 검증 오류를 내지 않으므로 그대로 두어도 된다 |
| SOME/IP 세부 값 | 제공자와 소비자의 SD 설정값, 엔드포인트 이름 HPC_Rear_UDP_30501 형식 | 새로 만든 인스턴스의 SD 기본값, 엔드포인트 이름은 <노드>_<커넥터>_UDP_<포트> 형식 | 예제는 다른 SD 값으로 저장되어 있고, 엔드포인트 이름은 PAIO가 자동으로 붙인다 | PNC 설계와 검증에는 영향이 없다. 값을 맞추려면 인터페이스와 SOME/IP 서비스의 SD 설정 표대로 입력한다 |
| CAN FD 세부 값 | CAN 클러스터에 데이터 구간 2 Mbps 설정, 응용 프레임 16개가 CAN FD 프레임 | 컨트롤러의 CAN FD 토글만 설정됨. CAN 클러스터는 Classical CAN 그대로 | 이 튜토리얼은 CAN 클러스터의 CAN FD BAUDRATE (DATA PHASE, KBPS) 항목을 Classical CAN 그대로 두고, 프레임 수준 CAN FD를 넣는 화면은 없다 | PNC 설계와 검증, PNC 관련 익스포트 결과에는 영향이 없다. 클러스터를 맞추려면 CAN CLUSTER 패널의 CAN FD BAUDRATE (DATA PHASE, KBPS) 항목에서 2000을 고른다 |
| 배치와 자동 입력 기본값 | 예제 파일의 노드 배치. FunctionGroup 상태에 VALUE 없음. Zone ECU 3개에만 pnc-synchronous-wakeup: false | Auto Layout 결과의 배치. VALUE에 0이 자동으로 들어감. 화면에서는 세 경우 모두 같게 보임 | 배치는 뷰 상태이고, 나머지는 새로 만든 행의 기본값이다 | 파일에 저장되는 값이 조금 다르지만 설계 내용과 검증 결과는 같다 |
그래서 어떻게 하면 되는가
익스포트한 ARXML을 다른 도구에 그대로 넘겨야 하는 것처럼 예제와 같은 모델이 필요하다면, 예제 프로젝트를 열거나 예제 ARXML을 임포트해 시작한다. 표에서 우회가 "ARXML 임포트"인 항목은 그렇게 채워진다. PNC 설계를 익히는 것이 목적이라면 표의 차이를 그대로 두고 끝까지 진행해도 된다. 위 표의 차이는 어느 것도 검증 항목으로 보고되지 않으므로, 따라 만든 프로젝트도 System 에디터와 검증이 말하는 "No validation issues."를 목표로 한다.
자주 겪는 문제
화면이 기대와 다르게 보일 때 먼저 확인할 것들이다. 대부분 잘못 입력한 것이 아니라 현재 버전의 표시 방식이다.
캔버스와 선택
- 클러스터의 종류와 전송 속도는 마우스를 올렸을 때만 보인다. 클러스터 이름은 사각형 아래에 늘 적혀 있다. 사각형에 마우스를 올리면 그 위에
WestCAN (Can, 500 kbps)같은 라벨이 나타난다. - 노드를 우클릭했는데 다른 메뉴가 열린다. 노드 경계 위의 커넥터나 안쪽 컨트롤러를 우클릭하면 그 자식의 메뉴가 열린다(커넥터 메뉴에는 Delete만 있고, 같은 종류의 클러스터가 생긴 뒤에는 Connect to Channel... 항목이 함께 나온다). 노드 안의 빈 곳을 우클릭한다.
- 커넥터나 컨트롤러가 선택되지 않는다. 작은 아이콘을 정확히 클릭해야 선택된다. 클러스터도 사각형을 클릭한다.
- 속성 패널 뒤의 노드를 클릭할 수 없다. 속성 패널을 펼치면 캔버스 오른쪽이 가려진다. 캔버스를 드래그해 옮기거나 속성 패널을 접은 뒤 선택한다.
- Auto Layout 결과가 위에서 아래로 정렬되지 않는다. 노드 수가 적으면 말단 ECU가 Zone ECU보다 위에 놓이기도 한다. 배치는 모델 값에 영향이 없다.
- VFB 캔버스에서 노드 이름이 너무 작다. 1920×1080에서 전체를 맞추면 글씨가 읽기 어려울 만큼 작아진다.
Ctrl과 휠로 확대해 확인한다. - VFB 드릴다운의 경로 표시 첫 항목이
System이다. 루트 컴포지션 이름은PncVehicle인데도 그렇게 보인다. 표시만의 문제이다.
값이 화면에 안 보이거나 편집란이 없을 때
- 커넥터의 PNC 참여 선언(
pnc-mappings)에 편집란이 없다. 파일에는 기록되고 보존되지만 속성 패널에 나타나지 않는다. 값은 위의 모델 조각에서 확인한다. - HPC 커넥터에는 PNC GATEWAY TYPE 이 없다. 이 속성은 Classic Platform ECU의 커넥터에만 나타난다. HPC는 AP 머신이라 PNC 게이트웨이가 될 수 없다.
- VLAN 이름 설정에 편집란이 없다. 채널에는 VLAN ID만 입력한다. CAN FD는 이와 달리 두 곳에서 설정한다. 컨트롤러 패널의 CAN FD 토글과 CAN CLUSTER 패널의 CAN FD BAUDRATE (DATA PHASE, KBPS) 항목이다.
- 프레임 수준 CAN FD 표시가 Signal 편집기에 없다. 화면에서 확인할 수 없는 값이다.
- CAN 클러스터의 TRANSPORT PROTOCOL 탭이 꺼져 있다. 전송 프로토콜은 클러스터마다 켜는 기능이고 이 튜토리얼에서는 켜지 않는다(탭의 빈 동그라미). 그래서 통신 클러스터 대화상자를 저장해도 빈
tp-config만 추가되고 검증 오류는 생기지 않는다. 위 표의 해당 행을 참고한다. Backbone을 더블클릭하면 언제나NmCluster_VLAN_Body만 열린다. 통신 클러스터 하나에 붙은 NM 클러스터 가운데 첫 번째만 대화상자에 실린다.NmCluster_VLAN_Rear를 여는 화면이 없다. 위 표의 해당 행을 참고한다.- NM 노드 목록에 같은 이름이 둘씩 보인다. 자동으로 만들어진 NM 노드의 NAME이 그 노드(ECU)의 이름과 같기 때문이다.
WestZone_CanNm,WestZone_UdpNm처럼 NAME을 고쳐 구분한다. 이름을 바꾸면 NM ECU의 코디네이터 참조도 함께 갱신된다. - NM 노드의 TX-NM-PDU-REFS 후보가 비어 있다. NM-PDU를 아직 만들지 않았기 때문이다. 신호·PDU·프레임과 I-PDU Group의 NM-PDU 만들기를 마친 뒤 3장의 NM 설정으로 돌아와 지정한다.
- 컨테이너 I-PDU Group과 NoPnc 그룹을 만드는 전용 화면이 없다. PNC GROUPS의 + 버튼으로 만들면 현재 선택한 PNC에 묶이므로 이 방법으로는 만들지 않는다. 이름은 CONTAINED PDUS의 KIND를 GROUP으로 바꿨을 때의 후보 목록에서 볼 수 있다.
목록과 표
- I-PDU Group에 넣을 PDU 후보에 NM-PDU가 섞여 나온다. KIND가 I-SIGNAL-I-PDU 인데도 NM-PDU가 후보에 들어온다. 이름이
_Pdu로 끝나는 응용 PDU만 고른다. NM-PDU는 PNC 그룹에 넣지 않는다. - 그룹 행 오른쪽 끝의 × 는 연결 해제가 아니라 삭제이다. PNC에서 빼려던 것이라면 누르지 않는다.
- PNC MEMBERSHIP 으로 PDU를 지정하면 Rx와 Tx 그룹 양쪽에 들어간다. 보내는 노드와 받는 노드가 모두 있는 PDU는 양쪽에 들어간다. 한쪽만 두려면 반대쪽 그룹을 펼쳐 × 로 뺀다.
- 뷰어의 열이 잘리거나 보이지 않는다. 기본 폭에서는 PNC MEMBERSHIP 열이 화면 밖에 있고 GATEWAY 열이 잘린다. 뷰어 경계를 끌어 넓히면 보인다. 넓힌 폭은 다이얼로그를 닫으면 초기화된다. 잘린 값은 셀에 마우스를 올려 툴팁으로도 볼 수 있다.
- NM 클러스터 머리글이 모두 대문자로 보인다. 모델 이름은
NmCluster_WestCAN이고, 화면의 대문자 표시는 머리글 스타일 때문이다. - 검색 상자로 클러스터 이름을 찾을 수 없다. 클러스터로 좁히려면 옆의 필터를 쓴다.
편집 중 동작
- NM 네트워크 핸들 행이 펼쳐진 채로 남는다. 새 핸들 행은 펼쳐진 채로 열리고 이름을 바꿔도 접히지 않으므로, 앞서 추가한 행이 펼쳐져 있을 수 있다. 요약 행을 누르면 그 행이 펼쳐지거나 접힌다.
- 상태 버튼을 눌러도 아무 일이 없다. 값이 아직 없는 두 상태 버튼은 화면에서 한쪽이 눌린 것처럼 보이지만 모델에는 값이 없다. NM BUSLOAD REDUCTION ACTIVE처럼 값이 없는 항목에서 원하는 쪽이 이미 눌려 보이면 반대쪽을 한 번 눌렀다가 되돌려야 값이 확정된다.
- 신호의 LENGTH 를 줄여도 MAX 가 따라 바뀌지 않는다. MAX는 직접 고친다.
- 새 신호가 비어 있는 첫 비트가 아니라 마지막 신호 다음에 놓인다. 원하는 자리가 있으면 START를 직접 입력한다.
- 서비스 인스턴스의 포트를 바꾼 뒤
Ctrl+S를 눌러도PNC:Interface탭이 저장되지 않은 채로 남는다. 포트를 바꾸면 PAIO가 SOME/IP 서비스의 신호와 PDU를 파생한다. Interface 편집기가 열려 있으면 파생된 인터페이스가 거기에 추가되므로 그 탭에도 ● 표시가 붙는다. PROJECT › Save All을 선택한다. 파생된 요소는 검증 오류를 내지 않는다. 자세한 절차는 System 에디터와 검증에 있다. - 검증 오류 행을 클릭하면 값을 고칠 수 없는 화면으로 이동한다. SOME/IP 포트 오류는 Interface 편집기의 인스턴스 카드로 이동하지만, 포트는 System 편집기의 커넥터에서 고친다.
- Machine Configuration 다이얼로그의 모듈이 항상 11개로 보인다. 파일에 든 모듈 수와 다를 수 있다. 이 상태에서 저장하면 11개가 파일에도 기록된다.
- NM 네트워크 핸들 요약의 NM CLUSTER 줄이 실제와 다르게 보인다. 표시용 요약이며 저장되는 값에는 영향이 없다. 연결이 맞는지는 VLANS와 PARTIAL NETWORKS 값으로 확인한다.
- 하나를 고쳤는데 오류가 둘 사라진다. 원인 하나가 여러 제약을 동시에 어길 수 있다. 예를 들어 채널의 active 게이트웨이가 둘이면
constr_5093과constr_3714가 함께 보고된다.
마치며
여기까지 따라왔다면 PNC 3개가 토폴로지부터 ARXML까지 일관되게 기록된 모델 하나를 갖게 된다. 각 편집기의 전체 기능은 에디터에, 임포트와 익스포트, 검증의 전체 설명은 작업 흐름에 있다.