Appendix

What You Will Do

This appendix is reference material, not a chapter you follow along with. Read it when you review your own PNC design after finishing the tutorial, or when you want to see how a value that the screen does not show is recorded in a file.

It has five parts: a design checklist, the project file layout, model excerpts, the differences between a hand-built project and the finished example, and the problems you will likely hit.

Before You Begin

• If you finished the previous chapter, ARXML Export, you can read on from that state.
• You do not need a finished model to use the checklist. Apply it to your own project as it stands.

Design Checklist

Work through the following after you finish a PNC design, or when you design a vehicle other than the one in this tutorial. The link after each item points to the chapter that covers it.

• Is every PNC identifier at least pncVectorOffset × 8 and at most (pncVectorOffset + pncVectorLength) × 8 − 1 (constr_3040)? Chapter 1, Chapter 3
• Does every connector's PNC filter array mask have the same length as pncVectorLength? Chapter 3
• Does each physical channel have at most one connector whose pncGatewayType is active (constr_5093)? Chapter 3, Chapter 11
• Does every PNC have a top-level PNC coordinator? You need an ECU that connects to two or more of the channels involved, with all of those connections active (constr_3781). Chapter 2
• Does each PNC have an Rx/Tx pair of I-PDU Groups, bound under PNC GROUPS in the PNC dialog? Chapter 4, Chapter 7
• For every NM cluster on a bus the PNC crosses, is NM PNC PARTICIPATION set to YES, and are the mandatory NM timing properties filled in (constr_9157, constr_9158, constr_9159, constr_9162, and constr_5222 for UdpNm)? Chapter 3
• For every NM node, is NM NODE ID unique within its cluster, does TX-NM-PDU-REFS hold exactly one NM-PDU of its own (constr_9388), and does RX-NM-PDU-REFS hold the rest of the same cluster? Chapter 3, Chapter 4
• Is the VFC name identical across the atomic SWC, the ECU composition, and the root composition (the VFC family)? Chapter 6
• Does the NM network handle on the AP machine reference the PNC and carry FunctionGroup state mappings for both the ACTIVE and the INACTIVE direction? Chapter 9
• Does the application AA that requests the PNC have a NetworkManagementPortInterface P-Port and a NetworkHandle mapping? Is the PARA platform imported so that the SM and NM modules connect to real AAs? Chapter 10
• Does each wakeup frame point to a frame that actually exists on the bus (on the Classic Platform side)? Chapter 7
• Is the VALIDATION panel at zero findings, and does the export pass the schema check with zero errors, apart from the errors in PNC_COM.arxml that come from the export itself? Chapter 11, Chapter 12

Project File Layout

A PAIO project is a single folder. In the PNC project this tutorial builds, every file related to the design sits under design/.

PNC/
├─ PNC.io.prj
└─ design/
   ├─ IVC.io.model            Topology, connector PNC properties, switch port PNC references, NM configuration
   ├─ SIGNAL.io.model         Signals, PDUs, frames, NM-PDUs, I-PDU Groups
   ├─ SYSTEM.io.model         PNC mappings, PNC vector offset and length, SWC-to-ECU mappings
   ├─ INTERFACE.io.model      SR interfaces, service interfaces, NM interfaces
   ├─ SERVICE.io.model        SOME/IP deployment, provider and consumer instances
   ├─ VFB.io.model            Composition list
   ├─ DATATYPE.io.model       Data types
   ├─ SWC/
   │  ├─ Application/                 The nine atomic SWCs. PortGroups (the VFCs) live here.
   │  ├─ AdaptiveApplication/         The three AP applications. The PARA platform AAs are in the subfolder HPC/.
   │  ├─ Composition/                 The 14 node compositions, the root PncVehicle, and PARA_HPC
   │  └─ Layout/                      VFB canvas placement (view state)
   └─ Module/
      └─ Machine/
         └─ HPC.machine.io.model      FunctionGroups, NM network handles, AP module configuration

The project folder also holds the folders code, doc, export, import, and workflow. The results of ARXML Export appear under export.

Which editor writes which file is summarized in the five-layer table in The Example and the Design Goals.

Model Excerpts

These excerpts show how a value you see on screen is recorded in a file. The values are taken from the finished example. You never need to edit the files by hand; the point is to see where each value lives.

SYSTEM.io.model — One PNC Mapping Entry

What you entered for PNC_ParkAssist in The PNC Dialog — Per-PNC Bindings is recorded as a single block. The VFC, the I-PDU Groups, the physical channels, and the service instances all gather here.

{
  "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" ]
}

The same file holds the global values "pnc-vector-offset": 2 and "pnc-vector-length": 6. These are the values used to calculate the identifier range in The Example and the Design Goals.

IVC.io.model — PNC Properties of a Zone CAN Connector

These are the gateway, wakeup, and filter mask values you entered in PNC Definition and Connector PNC Properties.

{
  "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"]
}

Read it as follows.

Field	Value	Meaning
pnc-filter-array-masks	[12, 0, 0, 0, 0, 0]	The length of 6 matches pnc-vector-length. The first byte, 12, is 00001100 in binary, that is bit 2 and bit 3. Because the vector starts at bit 16, it means PNC 18 and 19.
pnc-wakeup-can-id	1280	0x500 in hexadecimal.
pnc-wakeup-can-id-mask	1792	0x700 in hexadecimal. Frames from 0x500 through 0x5FF are caught as wakeup frames.
pnc-mappings	PNC 18, 19	Declares which PNCs this connector participates in. There is no field for this value on screen.

HPC.machine.io.model — NM Network Handle

This is the handle you created in The AP Machine — NM Handles and FunctionGroups. Note that there is one mapping for each of the two directions.

{ "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" }] } ] } ] }

The first direction means "when ParkAssistFG becomes Active, request this PNC". The second means "when this PNC goes down, bring ParkAssistFG to Off".

How a Hand-Built Project Differs from the Finished Example

A project you build by following this tutorial from Designing the Topology through to the end is not identical to the finished example. The current version has no screen for a handful of values. The table below lists what differs, why it differs, and what it affects. The counts come from the design/ files of the finished example.

Item	Finished example	Hand-built project	Why it differs	Impact and workaround
CAN NM frames	13 NM frames. 29 CAN frames in total	None. 16 CAN frames, all application frames	In the Signal editor, the PDU REFERENCES candidates of a CAN frame are I-Signal I-PDUs (and N-PDUs) and never NM-PDUs	You create the 18 NM-PDUs, but they are never carried in a frame, so NM communication stays incomplete. The WAKEUP FRAMES candidate list in The PNC Dialog — Per-PNC Bindings holds 16 frames instead of 29, and the three NM frames the example picks are not among them, so you cannot assign the wakeup frames. Workaround: ARXML import
NM cluster couplings	Two. One UdpNm coupling (NmCluster_VLAN_Body, NmCluster_VLAN_Rear) and one CanNm coupling (the three CAN clusters)	None	There is no screen for creating or editing a coupling	The exported PNC_COM.arxml contains no <UDP-NM-CLUSTER-COUPLING> or <CAN-NM-CLUSTER-COUPLING>. Validation still passes, because constr_9165 and constr_9166 are checked only when a coupling exists. Workaround: ARXML import
Container I-PDU Groups and NoPnc I-PDU Groups	20 I-PDU Groups. 8 PNC leaves, 6 containers (WestCAN_Rx, WestCAN_Tx, RearCAN_Rx, RearCAN_Tx, EastCAN_Rx, EastCAN_Tx), and 6 NoPnc groups (all empty)	8. The PNC leaves only	There is no dedicated screen for either kind. A group created with the + button under PNC GROUPS is bound to the selected PNC	The validation result and the contents of the groups bound to a PNC are the same. The exported PNC_COM.arxml holds 8 <I-SIGNAL-I-PDU-GROUP> elements instead of 20, and the <ASSOCIATED-COM-I-PDU-GROUP-REFS> of each <ECU-INSTANCE> shrinks accordingly. Workaround: ARXML import
Transport protocol (tp-config) and VLAN configuration of a communication cluster	No tp-config. Backbone has vlan-configs, which name its VLANs VLAN_Body and VLAN_Rear	An empty tp-config with no CanTpConfig, and no vlan-configs	Pressing Ctrl+S in the Communication Cluster Configuration dialog adds the empty tp-config. The transport protocol is a per-cluster feature that stays off in this tutorial. vlan-configs has no field on screen	The empty tp-config appears once you save the NM values in NM Configuration. Neither difference adds a validation error, and the design content and the PNC-related export results are unaffected. Workaround: none
Values of the second UdpNm cluster (NmCluster_VLAN_Rear)	NM timing, USER DATA, and NETWORK CONFIGURATION (UDP) (IPv4 239.200.0.1) are all filled in	The defaults it receives when it is created automatically	Of the NM clusters attached to one communication cluster, only the first is loaded into the dialog. Double-clicking Backbone always opens NmCluster_VLAN_Body, and there is no screen that opens NmCluster_VLAN_Rear	You cannot enter the one row for this cluster in the Full NM Values table in NM Configuration. NM PNC PARTICIPATION and the four USER DATA values stay empty, so NM over VLAN_Rear does not behave as it does in the example. PNC_ParkAssist and PNC_Trailer use this channel. Workaround: ARXML import
Connector PNC participation declarations (pnc-mappings)	Recorded on 13 CAN connectors	None	The properties panel has no field for it. An ARXML import does not fill it either, because AUTOSAR has no corresponding element	ARXML has no element dedicated to this value. On export it is one of the two sources for "which ECU participates in which PNC", which determines the <ASSOCIATED-COM-I-PDU-GROUP-REFS> of an <ECU-INSTANCE>; the other source is the VFC reference of the PNC mapping. In this example the VFC references already cover the same ECUs, so the export result is identical. Workaround: none
Root composition name and system information	Root PncVehicle. NAME PncVehicle, VERSION 1.0.0, DESCRIPTION Zonal PNC tutorial vehicle	Root System. The rest keep the defaults of a new project	A new project names its root System, and this tutorial has no step that changes the root name or the values in the SYSTEM panel	The label at the top left of the canvas and the SYSTEM panels in The System Editor and Validation look different. The <SHORT-NAME> in the exported PNC_System.arxml and every path that passes through that name (/System/PncVehicle/…) also differ. The design content is unaffected
Module instances on the AP machine	Seven: LOG, CM, SM, NM, PHM, TIME_SYNC, CRYPTO	Eleven: the seven above plus PERSISTENCY, IDSM, UCM, and DM	The Machine Configuration dialog always shows eleven modules, and saving writes all eleven to the file	The machine file gains four extra modules. The PNC design and validation are unaffected
Form of the PARA platform and state-client interfaces	The composition type PARA, with its AAs directly under SWC/AdaptiveApplication/. One state-client interface, StateClient_MachineFG	The composition type PARA_HPC, with its AAs under SWC/AdaptiveApplication/HPC/. The state-client interfaces StateClient_HPC_MachineFG, StateClient_ParkAssistFG, StateClient_TrailerFG, and StateClient_ComfortFG	The finished example keeps the earlier form of PARA. The import in Chapter 10 names the composition and its state-client interface after the machine HPC, and each FunctionGroup you add in Chapter 9 gets its own StateClient_ interface	Inside the HPC, the node of the prototype PARA reads PARA in the example and PARA_HPC in your project. In the example, the Machine Configuration dialog also shows a Migrate PARA Base Set to per-Machine layout button. The PNC design and validation are unaffected
Signals and PDUs derived from the SOME/IP deployment	None	SENDER-RECEIVER interfaces such as SVC_ParkDistance_SR and PDUs named SVC_…_PDU	When you add an SOA deployment or change the port of an instance, PAIO derives the CP-SOA signals and PDUs automatically	The derived PDUs raise no validation error, so you can leave them in place
SOME/IP detail values	SD settings on the provider and the consumer, endpoint names in the form HPC_Rear_UDP_30501	The SD defaults of a newly created instance, with endpoint names in the form <node>_<connector>_UDP_<port>	The example is saved with different SD values, and PAIO names endpoints automatically	The PNC design and validation are unaffected. To match the values, enter them as listed in the SD settings table in Interfaces and SOME/IP Services
CAN FD detail values	A 2 Mbps data phase on the CAN clusters, and all 16 application frames as CAN FD frames	Only the CAN FD toggle on the controller is set. The CAN clusters stay at Classical CAN	This tutorial leaves CAN FD BAUDRATE (DATA PHASE, KBPS) of the CAN clusters at Classical CAN, and there is no screen for frame-level CAN FD	The PNC design, the validation, and the PNC-related export results are unaffected. To match the clusters, select 2000 under CAN FD BAUDRATE (DATA PHASE, KBPS) in the CAN CLUSTER panel
Placement and auto-filled defaults	The node placement from the example file. No VALUE on the FunctionGroup states. pnc-synchronous-wakeup: false on the three zone ECUs only	The placement produced by Auto Layout. VALUE is filled with 0 automatically. On screen all three cases look the same	Placement is view state, and the rest are defaults for a newly created row	The values saved to the file differ slightly, but the design content and the validation result are the same

What to Do About It

If you need a model identical to the example — for instance because you must hand the exported ARXML to another tool as is — open the example project, or start from an import of the example ARXML. Every item whose workaround is "ARXML import" is filled in that way. If your goal is to learn PNC design, you can leave the differences in place and work through to the end. None of the rows above adds a validation finding, so a hand-built project aims for the same "No validation issues." that The System Editor and Validation describes.

Problems You Will Likely Hit

These are the things to check first when the screen looks different from what you expect. Most of them are not mistakes in your input but the way the current version displays things.

Canvas and Selection

• The kind and baud rate of a cluster appear only on hover. The name of each cluster is written below its rectangle. Hover over the rectangle to see a label such as WestCAN (Can, 500 kbps) above it.
• Right-clicking a node opens a different menu. Right-clicking a connector on the node border or a controller inside it opens that child's menu (the connector menu holds only Delete, plus Connect to Channel... once a cluster of the same kind exists). Right-click an empty spot inside the node.
• A connector or controller does not get selected. You have to click the small icon exactly. For a cluster, click the rectangle.
• You cannot click a node behind the properties panel. Expanding the properties panel covers the right side of the canvas. Drag the canvas aside, or collapse the properties panel before selecting.
• Auto Layout does not arrange nodes from top to bottom. With few nodes, an end ECU can end up above a zone ECU. Placement has no effect on the model values.
• Node names are too small on the VFB canvas. Fitting the whole canvas at 1920×1080 makes the text hard to read. Zoom in with Ctrl and the wheel.
• The first entry in the VFB drill-down path reads System. It shows that way even though the root composition is named PncVehicle. This is a display-only issue.

When a Value Is Not Shown or Has No Field

• The connector PNC participation declaration (pnc-mappings) has no field. It is recorded and preserved in the file but does not appear in the properties panel. Check the value in the model excerpts above.
• An HPC connector has no PNC GATEWAY TYPE. This property appears only on connectors of a Classic Platform ECU. An HPC is an AP machine and cannot be a PNC gateway.
• VLAN name settings have no field. On a channel you enter only the VLAN ID. CAN FD, by contrast, is set in two places: the CAN FD toggle in the controller panel and CAN FD BAUDRATE (DATA PHASE, KBPS) in the CAN CLUSTER panel.
• The Signal editor does not show frame-level CAN FD. This value cannot be checked on screen.
• The TRANSPORT PROTOCOL tab of a CAN cluster is off. The transport protocol is a per-cluster feature that this tutorial does not turn on (the hollow dot on the tab). Saving the communication cluster dialog therefore adds only an empty tp-config, and no validation error. See the matching row in the table above.
• Double-clicking Backbone always opens only NmCluster_VLAN_Body. Of the NM clusters attached to one communication cluster, only the first is loaded into the dialog. There is no screen that opens NmCluster_VLAN_Rear. See the matching row in the table above.
• The NM node list shows the same name twice. An automatically created NM node takes its NAME from the node (the ECU) it belongs to. Edit NAME to tell them apart, for example WestZone_CanNm and WestZone_UdpNm. Renaming also updates the coordinator reference in NM ECU.
• The TX-NM-PDU-REFS candidate list of an NM node is empty. You have not created the NM-PDUs yet. Finish Creating the NM-PDUs in Signals, PDUs, Frames, and I-PDU Groups, then return to NM Configuration in Chapter 3 and assign them.
• There is no dedicated screen for creating container I-PDU Groups and NoPnc groups. A group created with the + button under PNC GROUPS is bound to the currently selected PNC, so do not create them that way. You can see the names in the candidate list that appears when you change KIND under CONTAINED PDUS to GROUP.

Lists and Tables

• NM-PDUs are mixed into the PDU candidates for an I-PDU Group. NM-PDUs appear among the candidates even when KIND is I-SIGNAL-I-PDU. Pick only the application PDUs whose names end in _Pdu. NM-PDUs do not belong in a PNC group.
• The × at the right end of a group row deletes rather than unlinks. If you only meant to remove it from the PNC, do not click it.
• Assigning a PDU through PNC MEMBERSHIP puts it in both the Rx and the Tx group. A PDU that has both a sending and a receiving node goes into both. To keep only one side, expand the other group and remove it with ×.
• Viewer columns are cut off or not visible. At the default width the PNC MEMBERSHIP column is off screen and the GATEWAY column is cut off. Drag the viewer border to widen it. The widened size resets when you close the dialog. You can also read a cut-off value from the tooltip by hovering over the cell.
• NM cluster headers appear in all capitals. The model name is NmCluster_WestCAN; the uppercase display comes from the header style.
• The search box cannot find a cluster name. Use the filter next to it to narrow down to clusters.

Behavior While Editing

• NM network handle rows stay expanded. A new handle row opens expanded and stays expanded when you rename it, so rows you added earlier may still be open. A click on a row summary expands or collapses that row.
• A state button does nothing when you click it. A two-state button that holds no value yet looks as though one side is pressed, but the model holds no value. If an item such as NM BUSLOAD REDUCTION ACTIVE has no value and the side you want already looks pressed, click the other side once and then click back to commit the value.
• Reducing the LENGTH of a signal does not change MAX with it. Edit MAX yourself.
• A new signal is placed after the last signal instead of at the first free bit. If you need a specific position, enter START yourself.
• After you change the port of a service instance, Ctrl+S leaves the PNC:Interface tab unsaved. The port change makes PAIO derive the signals and PDUs of the SOME/IP services. If the Interface editor is open, the derived interfaces are added to it, so its tab gets the ● marker as well. Choose PROJECT › Save All. The derived elements raise no validation error. The full procedure is in The System Editor and Validation.
• Clicking a validation error row takes you to a screen where you cannot fix the value. A SOME/IP port error takes you to the instance card in the Interface editor, but you fix the port on the connector in the System editor.
• The Machine Configuration dialog always shows eleven modules. This can differ from the number of modules in the file. If you save in this state, all eleven are written to the file as well.
• The NM CLUSTER line in an NM network handle summary looks different from reality. It is a display summary and does not affect the saved values. Check the VLANS and PARTIAL NETWORKS values to confirm the links.
• You fix one thing and two errors disappear. A single cause can violate several constraints at once. For example, two active gateways on one channel are reported as both constr_5093 and constr_3714.

Closing

If you followed through to here, you now have a single model in which three PNCs are recorded consistently from the topology all the way to the ARXML. The full feature set of each editor is in Editors, and the complete description of import, export, and validation is in Workflow.