1. What is NM (Network Management) used for?

Whether it is a traditional fuel vehicle or a new energy vehicle, there are various ECUs on the
vehicle, and all these ECUs need electricity, and the power supply unit on the vehicle is generally
a battery, so the power of the battery is limited , For new energy vehicles, too much power
consumption will undoubtedly have a huge impact on the cruising range of the battery.
Therefore, in order to save power as much as possible, network management is proposed,
which means that one of the most important functions of network management is to save
energy. Electricity.

So how does network management achieve power saving? We know that all the ECUs on the car
will communicate with each other through CAN communication, Flexray or Ethernet, etc., then
network management is to send some commands on the network of each ECU to formulate a
set of rules to implement each ECU. Coordinated sleep and wakeup.

What is ECU sleep and wake up? In order to support sleep and wake-up, the chip of ECU must
support switching between low-power mode and normal working mode. Low-power mode (ECU
sleep) refers to a mode in which an ECU is powered off or in a very small number of peripheral
devices; wake-up refers to an ECU in full working mode.

To sum up: In fact, network management is used to save energy and effectively realize the
cooperative sleep and wake-up of the ECU on the car.

The network management in AUTOSAR mainly uses the CAN interface (CanIf) and provides a
general network management interface (NmIf). Where CAN network management fits within
the CAN architecture.
2. The principle of network management in AutoSar

I use more CAN network management as an example to illustrate, and I will mainly introduce
one of the most important state machines.

The ultimate goal of network management is to ensure that the ECUs on the vehicle can
coordinate sleep and wake up. That is to say, the most important point of network management
is to ensure that the ECUs on the vehicle can coordinately wake up and sleep. So if all the ECUs
on the car are in sleep mode and there are no messages on the network, how do you wake them
up? In fact, generally not all ECUs are in sleep mode. At this time, there may be very few ECUs in
the working state. , such as the BCM on the car. That is to say, some ECUs wake up directly
through KL15, while some wake up through CAN messages. Of course, it may be upgraded to a
more energy-efficient module in the future, which does not require a key signal. These modules
consume very little energy when they are in a sleep state, so they can always be in a wake-up
state.

Wake Up Request

There are two types of wake-up requests:

● Active wake-up request : a request to the network from inside the module. The network
management message that actively wakes up the node must be sent before the application
message.

● Passive wake-up request : a network request to the module from other modules on the bus.
For nodes that are passively awakened, there is no special requirement for the order in which
network management messages and application messages are sent.

Network States

The network status of the node includes the following two types:

● Network request: When the module needs to actively exchange information with other nodes
on the bus, it must request the network by sending a network management message, and set its
network status to "network request";

● Network release: When the module does not need to actively exchange information with
other nodes on the bus, its network status must be set to "network release"; information
exchange with the network.

Bus wake up

The ECU adopting the AUTOSAR CAN network management method must select a high-speed
CAN transceiver conforming to the ISO 11898-5 standard. If the ECU is in low power
consumption mode, it can only be woken up by the bus when a wake-up sequence defined by
the ISO 11898-5 standard occurs on the bus and the ECU successfully receives the wake-up
message defined by the network segment. Here this wake-up message must be the network
management message of the ECU in this network segment.

In order to meet this kind of coordinated wake-up and sleep, let's take a look at how the NM in
Autosar achieves coordination.
As shown in the figure, there are three main states in the state machine, which are BusSleep
sleep mode, PreSleep pre-sleep mode, and Network network mode; the Network state is divided
into three sub-states, which are RepeatMsg repeated message state, NormalOperate Normal
operation state, ReadySleep ready to sleep state. Let me talk about its role in each state.

BusSleep sleep mode: This state is what we call the sleep state. In this state, neither network
management packets nor application packets are sent. Generally, this state is a state of low
power consumption, which is what we mentioned above. Synergistic sleep state. Of course,
when we power on and initialize, it will also enter this state by default. (When the node has no
active network wake-up or passive wake-up request, the ECU communication controller
switches to the sleep mode, and the ECU power consumption is reduced to an appropriate level.
In the sleep mode, the node's network management messages and application messages are
prohibited from being sent, and cannot ACK response to the message on the bus. At the same
time when the node is in this mode, if an effective wake-up source is detected, the node must
be woken up).

PreSleep pre-sleep mode: This state is the pre-sleep state before entering the sleep state. In
this state, the network management message frame is generally not sent, and the application
message is not sent. It just waits for other ECUs to sleep together. Why is this state required? ,
In fact, it is to realize the word "collaboration", that is, let all the ECUs on the car sleep together
after a period of time. In fact, this sleep together is quite important, such as the work of one
ECU on the car and the work of other ECUs It is related, such as VCU (vehicle controller) and INV
(motor controller), it is possible that VCU does not send messages, which will cause INV to
report a fault, so this situation should be avoided. (In the pre-sleep mode, the bus activity stops,
and finally there is no activity on the bus, and the ECU communication controller is in the
working mode. In this mode, the node's network management messages and application
messages are prohibited from being sent, but the bus should ACK response to the above
message. The network management state of the node must remain in the pre-sleep mode for a
period of time. Once the timeout expires, the network management state should leave the pre-
sleep mode and enter the sleep mode.)

Network network mode: This state allows the ECU to communicate normally. Generally, in this
state, it can send and receive network management message frames and application messages
(including diagnostic messages), which means the wake-up state. Next, let me explain the
meaning of the three sub-states in this state:

1. RepeatMsg Repeat message status: Indicates the status of repeatedly sending network
management messages. The repeated message state includes two sub-states: the fast sending
state of the network management message and the normal sending state of the network
management message.

NM PDU fast sending state : When the node enters the NM PDU fast sending state, the NM-
Timeout Timer must be turned on or reset . In order to quickly wake up the network , it must
send network management messages in a fast cycle, and must not send normal cycle network
management messages ; All application messages must be delayed for a certain period of time
after the first fast NM PDU message is sent. In the NM PDU fast sending state, once the node
receives or sends a network management message, or the NM-Timeout Timer expires, the NM-
Timeout Timer will be reset immediately.

NM PDU normal sending state : After entering the NM PDU normal sending state, the node must
send network management messages in a normal cycle. If the node enters the NM PDU normal
sending state due to a passive wake-up request , the NM-Timeout Timer must be turned on, and
all application messages must be delayed by Tx_Enable_Time after the node detects the wake-
up request before sending. In the normal sending state of NM PDU, once the node receives or
sends a network management message, or the NM Timeout Timer expires, the NM Timeout
Timer will be reset immediately.

The network management state of the node remains in the repeated message state for a period
of time (this period of time is generally configurable), and once the timeout expires, the network
management state will leave the repeated message state. In this state, the node's network
management packets and application packets can be sent normally.
 Generally, when we enter the network (Network) state, we will first enter this state. In this
state, some network management message frames will be sent out quickly. Why do we need to
quickly send some network management messages? In fact, I just want to tell other ECUs on the
car as soon as possible that I am online! I want to communicate normally, everyone please pay
attention, everyone will also communicate with me for the whole vehicle. That's what it means.

2. NormalOperate normal operating state: After entering RepeatMsg for a period of time, if
communication is required, it will jump to the normal working state, and the normal working
state will send network management messages and all application messages to communicate
normally according to the normal cycle , you can This state is said to be the true awakened state.
(In the normal operation state, once the node receives or sends a network management
message, or the NM-Timeout Timer expires, the NM-Timeout Timer should be reset
immediately. In this state, the network management message and application message of the
node must send normally.)

3. ReadySleep ready to sleep: If you need to sleep after waking up, then we may need to do
some preparatory work to allow our ECU to go to sleep. For example, there are some data to be
stored at this time, such as the motor controller detects that the motor has not stopped. And so
on, so this state is used to do some preparations before going to sleep. We can see that any
process from waking up to going to sleep needs to go through this state, which means that some
preparations must be completed before going to sleep. . Then in this state, communication is
still possible. Only when entering the PreSleep state will the corresponding application message
sending and receiving and sending of NM messages be turned off. Another point to declare is
that the reception of general network management message frames will not be closed . (After
the node enters the sleep-ready state, it must stop sending network management messages,
and all application messages must stop sending after the NM Timeout Timer expires. In the
sleep-ready state, once a node receives a network management message, the NM Timeout
Timer It will be reset immediately. The NM Timeout Timer expires, and the node's network
management state should enter pre-sleep mode.)

3. Network management message (NM PDU)

The data field format of the AUTOSAR CAN network management message is shown in the
following table:
Source Node Identifier

Byte 0 of the NM PDU is used to send the source node identifier, and each ECU will be assigned
a unique identifier to inform the receiving node which node sent the NM PDU.

source node identifier: source node ID, can be configured to Byte 0, Byte 1, or closed through
CanNmPduNidPosition. For example, if the base address of the NM message is 0x400 and the
source node identifier is 0x12, the ID of the NM message is 0x412

Control Bit Vector

Byte 1 of the NM PDU is allocated for sending the Control Bit Vector. Among them:

bit 0: repeat message status request bit;

bit 3: network management sleep coordination bit;

bit 4: activate wake-up bit;

bit 6: partial network information bit;

other bits are temporarily reserved.

Bit 0: Repeat Message Request

0: Repeat Message State not requested

1: Repeat Message State requested

Bit 3: NM Coordinator Sleep Bit

0: Start of synchronized shutdown is not requested by main coordinator

1: Start of synchronized shutdown is requested by main coordinator

Bit 4 Active Wakeup Bit

0: Node has not woken up the network (passive wakeup)

1: Node has woken up the network (active Wakeup)

Bit 6 Partial Network Information Bit (PNI)

 0: NM PDU contains no Partial Network request information

1: NM PDU contains Partial Network request information

Bit 1, 2, 5, 7 are reserved for future extensions

0: Disabled / Reserved for future usage

User Data Domain (User Data)

Byte 2 to byte 7 of the network management message are used to send user-defined data
information, these bytes are currently reserved for expansion, and are filled with '0x00'.
4. Network Management State Transition

Condition_01
After the power supply status of the node is switched from battery off to battery on, the node
must initialize the network management module CanNm. After the initialization is completed,
the node must enter the sleep mode, and must immediately have the ability to be awakened by
active wake-up requests or passive wake-up requests;

Condition_02
When the node is in the sleep mode, if it receives a valid network management message, the
node will leave the sleep mode and enter the normal sending state of the NM PDU in the
repeated message state. After entering the NM PDU normal sending state, before the timer
Repeat Message Timer times out, the node must send network management messages in a
normal period. When a node receives a network management message, the first frame message
it sends to the bus can be either a network management message or an application message.

Condition_03
If the node detects an active wakeup request in sleep mode, the node must send a network
management message to actively wake up the network. During the process of actively waking
up the network, the node must first enter the NM PDU fast sending state. When a node needs
to wake up the network due to an active wakeup request, it must quickly send continuous NM
PDU messages.

Condition_04
A node in the NM PDU fast sending state, when the counter is zero, the node will enter the NM
PDU normal sending state, and start to wait for a period of time before sending network
management messages in a normal cycle.

Condition_05
Actively requesting network nodes in the state of repeated messages, if the Repeat Message
Timer times out, but the node's active network requests still exist, the node must enter the
normal operation state. The node continues to send network management messages and
application message PDUs in a normal cycle.

Condition_06
A node in the normal operation state, if it releases all network requests and no longer needs to
actively request the network, it must immediately switch the network management state to the
ready-to-sleep state, and the node must immediately stop sending network management
messages.

Condition_07
A node in the sleep state, if an active network request is detected, the node must immediately
enter the normal operation state, and must start sending network management messages and
application message PDUs in a normal cycle.

Condition_08
A node in the normal sending state of NM PDUs in the state of repeated messages, if no active
network request is detected, once the Repeat Message Timer times out, the node will enter the
state of preparing for sleep.

Condition_09
If a node in the state of preparing for sleep does not detect an active network request, once the
NM Timeout Timer expires, the node will enter the pre-sleep mode.

Condition_10
If a node in pre-sleep mode receives a passive wake-up request, the node will enter the normal
sending state of NM PDU in the state of repeated messages.
 Condition_11 For
a node in the pre-sleep mode, if an active wake-up request is detected, the node will enter the
NM PDU fast sending state of the repeated message state.

Condition_12
If the node in the pre-sleep mode no longer receives active or passive wake-up requests, once
the Wait Bus-Sleep Timer times out, the node will enter the sleep mode.

Condition_13
If the battery loses power in any state, the node will enter shutdown mode and no longer have
any communication and network management functions. The algorithm of AUTOSAR network
management has nothing to do with the processor, that is, it does not depend on any processor-
specific hardware support, so it can be implemented on any processor architecture within the
scope of AUTOSAR.

5. Timing diagram of state transition

When the wake-up request (active wake-up request, passive wake-up request) activates the
network management state of the node, all application messages of the node must be delayed
for a certain period of time before they can start sending. The sending of the network
management message of the awakened node in the network is not limited by the delay time,
and can be sent before it ends, but the first frame of the network management message must
be sent after a certain period of time after the node enters the repeated message state to avoid
The awakened nodes send network management packets at the same time, causing network
congestion.
Timing diagram of NM signal transmission

Timing diagram of NM signal reception

Timing diagram of NM signal reception

During sleep, once the NM Timeout Timer expires, all application messages of the node must
stop sending immediately. The case described above is for the wake-up and sleep process
triggered by a single active wake-up request. When multiple wake-up requests are interleaved,
each wake-up request must abide by its own timing parameters and will not affect each other.
6. Introduction with examples
The customer's requirement is a standard AutoSar architecture for network management.

In the dormant state, our ECU only has the CAN transceiver in the working state, that is to say, it
can detect NM messages. Of course, this is realized through the chip.

Our ECU is connected to the KL15 signal, so our ECU supports KL15 wake-up and NM message
wake-up, that is, the effective wake-up sources are these two.

Let me take the NM message wake-up as an example, and briefly talk about the wake-up
process.

In the sleep state, there is no message in the network status of the car. Once the BCM on the car
detects that the network is going to be used, it will send out a network management message at
the first time. At this time, our ECU will also receive the network management message. , so it
will wake up our ECU. First, after the transceiver of our ECU receives the NM message, it tells
the chip to wake up. At this time, it will supply power to the controller, and then the program
will initialize, enter the BusSleep state, and then enter RepeatMsg mode, at this time, the first
frame of NM message will be sent quickly, and 5 frames of NM message will be sent quickly (for
example, the cycle is 10ms), so that other nodes know that our ECU has woken up, and then it
will switch to the normal cycle of NM message (such as 50ms), of course, at this time, the
system is also being initialized, and application messages can be sent and received normally
after a certain period. After being in the RepeatMsg state for a certain period of time, it will
switch to the NormalOpr mode, and the communication will be normal at this time. In this
mode, the NM message is sent at a certain period, such as 500ms, telling all nodes that I am
communicating normally. In fact, there are some information in the NM message, such as wake-
up reason, user data, etc., which can be defined.

Let's talk about the process of NM sleep:

In the NormalOpr state, if the ECU does not need the network, such as KL15 disconnection, the
ECU will choose to release the network at this time, and the release of the network is to switch
from the Normal state to the ReadySleep state. At this time, some fault storage and equipment
before power-off will be performed. After the work is completed, it will enter the PreSleep state
after waiting for a certain period of time. This state will also close the application messages and
TX network management messages. After waiting for a certain period of time, it will enter the
BusSleep state. After entering BusSleep, the controller will enter sleep.
https://www.modb.pro/db/536894
2.Autosar Network Management: ERA/EIRA Question QA

Q1: Who is ERA and EIRA for gateway nodes?

In Autosar network management, after enabling the PN (Partial Network) function, there will be
ERA(External Request Array) and EIRA(External and Internal Request Array) configuration items. What is
the difference between the two? To understand the difference between the two, you need to know
whether the developed node (ECU) is a Gateway node.

For gateway nodes , it will involve the configuration of ERA, why do you say that? An ECU acting as a
gateway node means that the ECU contains multiple physical channels , eg: 2 channels of CAN, 1 channel
of Flexray, etc. When a channel of the gateway node (eg: CAN1) receives PNC #n and associates it with
other channels (eg: CAN2), the gateway node needs to assume the responsibility of actively waking up
CAN2, so PNC information routing is required. At this time, ERA is required to receive CAN1 The received
PNC #n information is sent to CAN2. For more details, please refer to the previous Autosar network
management: the relationship between active wakeup source/passive wakeup source and network
active wakeup/passive wakeup .

For non-gateway nodes , there is no task of routing PNC information, just enable the EIRA function.
Autosar Network Management: Partial Network Basics

To learn Autosar network management, there are many minutiae that need to be understood, and these
minutiae need time to ponder. For new learners, I don't know if I have ever felt like this: "This concept
can't be found, and in what scenarios is this thing used...", this is what I used to feel. To be honest, it’s
hard to understand some concepts. If the concepts are not clear, you can’t understand the functions of
the corresponding modules well, and naturally you can’t figure out how to solve actual project
problems. This article shares the concept of the PN (Partial Network) part of the Autosar network
function, hoping to give you some help! I am an Autosar/embedded apprentice, and I don't understand
a lot. Welcome to correct and communicate.

1. NM PDU structure and PNC information location

A classic CAN NM PDU format is as follows:

NID : Source Node Identifier, that is, the CanID of the CAN message of the corresponding node. For
example, if the node NM Msg CanID is 0x509, then NID = 0x09 (configured by the configuration tool),
and 5 is used to indicate the type of network management message.

CBV : Control Bit Vector, control bit vector. The specific information of each Bit is as follows:

bit0 : The node enters the RMS state flag. If the node actively enters the RMS state from the RSS state or
the NOS state , it needs to call the CanNm_RepeatMessageRequest() interface . When the node
enters the RMS state from the RSS or NOS state, bit0 = 1 in the sent NM Msg, When leaving the
RMS state, bit0 = 0. This has been discussed in the previous article. For details, please refer to
 the previous article Errata (1): Autosar network management: the role of
RepeatMessageRequestBit, do you know it? ;
bit4: If the node actively wakes up the network , in the RMS and NOS states, bit4 = 1. The configuration
parameter CanNmActiveWakeupBitEnabled = TRUE is required;
bit6: When the network management uses the PN function, bit6 = 1 when sending a network
management message; when receiving a network management message, it is necessary to
identify the PNI, if PNI = 0, the PN function does not process.

PNC : Partial Network Cluster, part of the network cluster. User Data stores PNC information. Suppose
there are 48 PNCs in a certain network segment. Each Bit in User Data represents a PNC. You can
use PNC 16 ~ PNC 63 to identify these 48 PNCs. Note: How many PNCs the node needs to handle
is configured according to the requirements. For example, if there are 20 PNCs (PNC16~PNC35)
in the network segment, use 3 bytes of User Data to identify them (3 * 8 > 20). The
corresponding relationship between PNC and User Data is as follows:

2. How to understand VFC?

VFC : Virtual Function Cluster, virtual function cluster. SWCs exchange information through Ports to
realize one or more vehicle functions. When a function needs to be enabled, set VFC #n ( = 1) through a
specific SWC ( VFC-Controller ) to request the corresponding communication function, so that
information can be exchanged between different SWCs, and the corresponding function is enabled; if a
certain function is not required function, reset the corresponding VFC #n ( = 0 ) to request to close the
communication, and the function is disabled.

VFC #n status information can be passed to BSW through RTE Port.

An example of the mapping relationship between VFC and PNC is as follows:

+ One VFC can map one PNC;

+ Multiple VFCs can be mapped to one PNC;

+ One VFC can map multiple PNCs;

+ A VFC may also not map a PNC.

3. How to understand the node-associated PNC?

There are multiple nodes in a network segment, and multiple PNCs can be formed between multiple
nodes, which means that not all PNC #n are valid for a certain node. For example: ECU1 has two nodes
Node1 and Node2. In the network management message received by Node1, only pay attention to
whether PNC20, PNC22, and PNC30 are set (= 1), because Node1 only participates in PNC 20 , PNC 22 ,
and PNC30 . The network cluster does not care about the status of PNC16 or other PNC #n, the example
is as follows:

4. CanNmPnResetTime time parameter

How to understand CanNmMsgCycleTime < CanNmPnResetTime < CanNmTimeoutTime ?

Assumption: A node is associated with PNC1, as follows:

1. Why CanNmMsgCycleTime <CanNmPnResetTime?

If the node's NM Msg sending cycle CanNmMsgCycleTime = 1000ms, CanNmP nResetTime = 800ms.

At time t0 , PNC1 is set (PNC1 = 1), that is, it is expected that this node will have PNC1 = 1 in the NM PDU
of the next frame, and the associated Tx I-PDU will continue to be sent;

At t1 , due to CanNmPnResetTime = 0, PNC1 is reset (PNC1 = 0), and the associated Tx I-PDU is stopped ;
At t2 , PNC1 = 0 in the sent NM PDU, instead of the expected PNC1 = 1, so CanNmMsgCycleTime needs
to be less than CanNmPnResetTime. As follows:

2. Why CanNmPnResetTime <CanNmTimeoutTime?

If the node's NM Msg sending cycle CanNmTimeoutTime= 3000ms, CanNmP nResetTime = 3200ms.

At t0 , before the NOS enters the RSS, the PNC1 in the last frame of the NM PDU is set (PNC1 = 1), and
the NM PDU is stopped in the RSS;

At t1 moment , due to CanNmPnResetTime != 0, PNC1 = 1, CanNmTimeoutTime = 0, the node enters the

PBSM state from RSS ;

At time t2 , CanNmPnResetTime = 0, PNC1 = 0. However, during t1~t2, since PNC1=1, the Tx I-PDU
associated with PNC1 continues to be sent out. After entering the PBSM, except for the application
messages cached by the underlying hardware, the application messages (Tx I-PDUs) requested by the
upper layer can be sent out. -PDU) should not be sent . So CanNmPnResetTime needs to be less than
CanNmTimeoutTime . As follows:
5. What are ERA and EIRA?

When the network management uses the PN function, ERA (External Request Array) and EIRA (External
Internal Request Array) are two unavoidable configuration items.

ERA: external network request set, what does it mean?

The network management message received by the node from other nodes is " External ";

For network management messages sent by other nodes, if PNC #n = 1 and is associated with the
receiving node, it means " Request ", requesting the receiving node to maintain the network status of
the PNC;

A node can be associated with multiple PNCs, so an " Array " will be formed.

The use of ERA requires the configuration parameter CanNmPnEraCalcEnabled = 1.

EIRA: internal/external network request set, the external network request is consistent with ERA, no
more details. Requires configuration parameter CanNmPnEiraCalcEnabled = TRUE.

The upper layer of the node (ASWC), using VFC to actively request the node to maintain the network
behavior is " Internal ". A node has multiple VFCs, and can also be associated with multiple PNCs. When
the VFC is set (= 1), the corresponding PNC is set. (=1), actively request to activate/maintain the network
status of this PNC.

For example: SWC 01 recognizes a certain VFC = 1, interacts with BswM through RTE, and then BswM
calls ComM interface to request communication mode switching; SWC 02 can also identify VFC status,
directly through RTE, calls ComM interface, and requests communication mode , as follows Shown:

ERA is related to routing (Gateway). This article will not discuss it, but it will be discussed later, so stay
tuned.
6. How to understand the "fast/slow" sending of network management messages
For active (Active) network nodes , there may be such a requirement in the network management
requirements: "Support the immediate mode (Immediate), enter the RMS (Repeat Message State) state,
need to send NM Msg 10 frames continuously, and the NM Msg interval is 20ms , after the fast sending
mode, enter the normal sending mode, and the NM Msg sending interval is 1000ms."

When to fast and when to slow? If the node network wakes up passively , for example: the node
receives valid network management messages from other nodes, calls the CanNm_PassiveStartUp()
interface to wake up the node network, and the node's NM Msg is sent normally (assuming a period of
1000ms), which is slow sending; if the node network actively Wake up , the node actively requests the
network, for example: call the CanNm_NetworkRequest() interface to wake up the network, after
entering the RMS , enter the fast transmission mode (note: CanNmImmediateNmTransmissions > 0),
assuming that the fast transmission period is 20ms, the fast transmission is 10 frames, and then enters
the slow transmission ( assuming period 1000ms ).

For the specific NM Msg sending behavior, please refer to the previous Autosar network management:
Receiving/sending of network management messages and analysis of network management time
configuration parameters .
Autosar PN network management: PNC information receiving/sending process
1/ Interaction modules involved in PNC information

The interaction and functioning modules of PNC information include: CanTrcv, CanIf, CanNM, CanSM,
PduR, COM, BswM, ComM, RTE, SWC, etc., as follows:

External : Mainly refers to receiving external request information through ERA Rx signal, eg: receiving
NM Msg containing PNC information.

Internal : mainly refers to the "User" who calls the ComM_UserRequest() interface, where the User
includes: Run unnable entities, SW-Cs, BswM and DCM .

2/ Principles of PNC Gateway

The PNC Gateway principle is mainly applicable to the gateway node ECU . For the gateway node ECU, it
contains multiple physical channels . When the PNC crosses network segments, it is necessary to route
the PNC information to the target network segment, and then realize the management of PNCs in
different network segments. As shown in the figure below: PNC 16 is associated with ECU3 and ECU6.
ECU3 belongs to CAN 2 BUS, and ECU6 belongs to CAN 3 BUS. Therefore, PNC16 information needs to be
routed between CAN 2 BUS and CAN 3 BUS to manage the network status of PNC 16 .
The multiple physical channels of the gateway node ECU will correspond to the Channel of the ComM
module. According to Autosar's requirements, ComM is responsible for the routing of PNC information .
ComM will handle the routing of PNC information according to the PNC Gateway type of each Channel .
For the gateway ECU, the PNC Gateway of each Channel can be configured into two types: Active PNC
Gateway and Passive PNC Gateway .

The principles of PNC Gateway are as follows:

(1) PNC #n information is received by Passive Channel

Assumption: PNC #n is associated with Channel 1, Channel2, Channel3, and Channel4.

When the Passive Channel receives PNC #n = 1 , it needs to route PNC #n = 1 to the target Channel of
Active type . Note: The target Channel here includes the Channel that receives PNC #n = 1 .

For PNC #n = 1 information received by Passive Channel, it cannot be routed to Channel of Passive type .
As follows:
(2) PNC #n information is received by Active Channel

When the Active Channel receives PNC #n = 1 , it needs to route PNC #n = 1 to the target Channel of
Active/Passive type . Note: The target Channel here includes the Channel that receives PNC #n = 1. As
follows: