Introduction
Architecture Overview
The AUTOSAR Network Management consists of the general NM Interface and the bus-specific NM modules. The UDP Network Management (UdpNm) module implements the network management functionality for the Ethernet. Network management frames are sent as UDP packets.
The purpose of the UdpNm is to detect whether an ECU, connected to the Ethernet channel, requires bus communication or whether all ECUs are ready to go into sleep mode.
The following figure shows where the UdpNm is located in the MICROSAR architecture.
Adjacent Modules
The next figure shows the interfaces to adjacent modules of the UdpNm. These interfaces are described in chapter 5.
Applications do not access the services of the BSW modules directly. They use the service ports provided by the BSW modules via RTE. Since the UdpNm has no service ports, the UdpNm can’t be accessed via RTE by the application. The UdpNm interacts with the generic Network Management (NM) module.
Functional Description
The functional description is limited to the scope of the UdpNm module. If further information for features concerning NM algorithm or involving the NM Interface is needed please refer to the related Technical Reference or the AUTOSAR SWSs.
Features
The features listed in the following tables cover the complete functionality specified for the UdpNm.
The AUTOSAR standard functionality is specified in [1], the corresponding features are listed in the tables
- Table 3-1 Supported AUTOSAR standard conform features
- Table 3-2 Not supported AUTOSAR standard conform features
Vector Informatik provides further UdpNm functionality beyond the AUTOSAR standard. The corresponding features are listed in the table
- Table 3-3 Features provided beyond the AUTOSAR standard
The following features specified in [1] are supported:
Deviations Against AUTOSAR 4.1.1
The following features specified in [1] are not supported:
Additions / Extensions
The following features are provided beyond the AUTOSAR standard:
Limitations
For description of Limitations please refer [1].
Initialization
The UdpNm is initialized by calling the UdpNm_InitMemory() and UdpNm_Init() functions. UdpNm_InitMemory() must only be called, if the compiler or startup code does not initialize variables correctly. The configuration of the module is pre-defined by DaVinci Configurator Pro during the configuration process.
Main Functions
For each Ethernet channel, on which the UdpNm is active, there is one separate main function - UdpNm_MainFunction_x(). The ‘x’ is replaced by the UdpNm channel configuration container name, i.e. UdpNm_MainFunction_UdpNmChannelConfig() is the main function for the UdpNm channel with the configuration container name ‘UdpNmChannelConfig’. All main functions must be called periodically by the BSW Scheduler Module (SchM). The period itself is configured channel specific during the configuration process.
States
The UdpNm is operational after correct initialization. The internal states of the module are shown in Figure 3-1.
NM PDU structure
Payload
The payload of the NM PDU is structured as followed.
It is possible to influence the payload structure channel specific.
The location of the Source Node Identifier and the Control Bit Vector can be changed. Either they can be switched or turned off but it is only allowed to locate theme within the first two byte of the payload.
Control Bit Vector (CBV)
The Control Bit Vector (CBV) is a bit field of size one byte. It contains multiple indication Bits to influence the behavior of the Nodes receiving the NM PDU.
Its structure is shown in the following table.
Repeat Message Request
- 0: Repeat Message State not requested
- 1: Repeat Message State requested
NM Coordinator Sleep Ready
- 0: Start of synchronized shutdown is not requested by main coordinator
- 1: Start of synchronized shutdown is requested by main coordinator
Active Wake-up Bit
- 0: Node has not woken up the network (passive wakeup)
- 1: Node has woken up the network (active wakeup)
Partial Network Information (PNI)
- 0: NM message contains no Partial Network request information
- 1: NM message contains Partial Network request information
Reserved (Res)
- 0: Reserved for future usage
User Data Handling
The User Data Handling allows manipulating and/or retrieving the data contained in the User Data field of an NM PDU. Access to the data is limited channel-wise.
Manipulating the User Data to be transmitted
The API UdpNm_SetUserData() allows to set the data to be transmitted within the User Data field of the NM PDU.
Manipulation of the data in the User Data field is only possible if at the same time [Com User Data Support] is disabled. For further information on Com User Data Support please refer to section 3.14.
Retrieving the User Data received
The API UdpNm_GetUserData() allows to retrieve the data in the User Data field of last received NM PDU.
Remote Sleep Indication
The Remote Sleep Indication feature allows the node to detect whether it’s the only one still requesting the bus and indicate the NM Interface about the circumstance.
Detection of Remote Sleep Indication
Remote Sleep Indication is detected during Normal Operation State by the lack of incoming NM PDUs sent from foreign nodes.
Detection is realized through a timer which is decremented if no NM PDU is received. If the timer exceeds, the Remote Sleep Indication is recognized.
The NM Interface is informed about the Remote Sleep Indication by a call to Nm_RemoteSleepIndication().
Detection of Remote Sleep Cancellation
The Remote Sleep Indication passed to the NM Interface can be cancelled if a foreign node requests the bus again.
This cancellation is only accepted when receiving an NM PDU in Normal Operation State or Ready Sleep State. The NM Interface will be informed about another node requesting the bus again by calling Nm_RemoteSleepCancelation().
Coordination Synchronization Support
The Coordination Synchronization Support feature allows the synchronization of the shutdown between multiple coordinators. Therefore the main coordinator sets the NM Coordinator Sleep Ready Bit in the CBV to indicate the demand for a synchronized shutdown.
Initiation of Coordinator Synchronous Shutdown
The Coordinator Synchronization is initiated by the main coordinator by calling UdpNm_SetSleepReadyBit(). This API will set the related Bit in the CBV of the NM PDU. In addition an asynchronous NM message is transmitted immediately in order to propagate the change as soon as possible.
Detection and Cancellation of Coordinator Synchronous Shutdown
The Coordinator Synchronous Shutdown request is detected by receiving a NM PDU with the NM Coordinator Sleep Ready Bit set in the CBV. This will lead to a call to Nm_CoordReadyToSleepIndication().
This indication is recalled if a NM PDU is received with the NM Coordinator Sleep Ready Bit cleared again. The NM Interface is notified by Nm_CoordReadyToSleepCancellation().
Bus Synchronization
The Bus Synchronization feature allows the node to send a NM PDU asynchronously by a call to UdpNm_RequestBusSynchronization().
Nodes receiving this PDU will reset their NM Timeout Timer which leads to a synchronization of the time base for the transition to Ready Sleep Mode.
Passive Mode
The Passive Mode feature allows to restrict the node to only receiving NM PDUs. Transmission of PDUs is disabled in all states of the state machine any time.
By setting 'Repeat Message Time' to the value 0, the Repeat Message state is skipped. The state does not make sense for passive nodes, since these nodes are only able to receive NM messages, not to send any. Usually, there is another node that sends NM messages in Repeat Message so there is no need for 'Repeat Message Time' being greater than 0 for passive nodes.
Nevertheless, if 'Repeat Message Time' is configured to a value greater than 0 and if 'Passive Mode Enabled' is turned ON, the transition from Repeat Message to Prepare Bus Sleep only depends on the reception of NM messages. If there is no recently received NM message, the transition back to Prepare Bus Sleep occurs after Timeout Time has elapsed.
PDU Rx Indication
The PDU Rx Indication feature allows notifying the NM Interface of an NM PDU reception. If a NM PDU is received the UdpNm will call Nm_PduRxIndication() to indicate the reception to the NM Interface.
State Change Indication
The State Change Indication allows the module to indicate every state change in its state machine during operation. Nm Interface will be notified by calling Nm_StateChangeNotification().
Repeat Message Indication
The Repeat Message Indication feature enables the UdpNm to notify the Nm Interface about the reception of a NM PDU with the Repeat Message Request Bit set in the CBV. The notification is passed by calling the Nm_RepeateMessageIndication() API of Nm Interface.
Com User Data Support
The Com User Data Support feature enables the module to retrieve the data to be placed in the User Data field of the NM PDU automatically.
On transmission of a NM PDU the UdpNm collects the User Data to be transmitted within the PDU from the PduR. Therefore it calls the PduR_UdpNmTriggerTransmit() API of PduR, which provides the corresponding data.
Immediate Tx Support
The Immediate Tx Support feature extends the ‘Com User Data Support’. It enables the transmission of user data within an asynchronous NM message triggered by the change of user data.
Communication Control
The Communication Control feature allows influencing the transmission of NM PDUs during runtime.
Transmission of NM PDUs is stopped by calling the API UdpNm_DisableCommunication(). As result there will be no PDUs transmitted in any state.
To enable the transmission again the API UdpNm_EnableCommunication() is provided.
Active Wake-up Bit Handling
The mode change from Bus-Sleep Mode or Prepare Bus-Sleep Mode to Network Mode triggered by UdpNm_NetworkRequest() is specified as “Active Wake-up”. Upon an Active Wake-up the UDP NM sets the active wake-up bit within the Control Bit Vector at bit position 4. This feature is optional and has to be configured.
Immediate Nm Transmissions
If an Active Wake-up occurs the UDP NM transmits the first NM message immediately (the NM message offset time is ignored) when entering Repeat Message State. For the next NM messages UDP NM uses a faster NM message cycle time. Afterwards it uses the normal NM message cycle time. This behavior is illustrated in Figure 3-2.
The number of ‘Immediate Nm Transmissions’ is the number that is configured for this parameter. As it can be seen in Figure 3-2, after the first Immediate Nm Transmission the interval between the NM messages is ‘Immediate Nm CycleTime’ for (n-1) times. Then, the usual interval ‘Msg Cycle Time’ is used again.
Note that “Any state except Repeat Message” in Figure 3-2 refers to ‘Bus Sleep’ and ‘Prepare Bus Sleep’. If the setting ‘Pn Handle Multiple Network Requests’ is ON, it also refers to ‘Ready Sleep’ and ‘Normal Operation’.
This feature is optional and has to be enabled in the configuration. The amount of messages that are transmitted faster (‘Immediate Nm Transmissions’) and the fast message cycle time (‘Immediate Nm Cycle Time’) can also be configured.
Car Wake-up
Every ECU shall be able to wake up all other ECUs of the car. This wake-up request information is contained in the NM message user data of an ECU. The central gateway ECU evaluates the Car Wake-up request information and wakes up all connected communication channels.
This feature is optional and has to be configured.
Rx-Path
If the UDP NM receives a NM message it evaluates the user data content. If the Car Wake-up Bit is set and the Node ID passes a filter (if Node ID filter is enabled) the UDP NM notifies the NM via the following callback function:
Nm_CarWakeUpIndication()
Tx-Path
For the transmission of the Car Wake-up Bit it has to be set at the corresponding location within the NM user data. If the feature ‘Com User Data Support’ is used and corresponding signal and I-PDU are configured for directly transmitting a changed signal the information is sent immediately. Refer also to chapter 3.14 ‘Com User Data Support’.
Partial Networking
The Partial Networking feature enables the ability to handle NM PDUs containing information about Partial Network (PN) requests. Furthermore the states are aggregated into the so called External-Internal-Request-Aggregation- and External-Request-Aggregation-PDUs, or cut short EIRA- and ERA-PDUs. These PDUs are shared with the upper layer to provide the PN states.
Partial Networking Information in NM PDU
The PN Information is places into the regular NM PDU. More precisely the information is contained in the User Data field.
Table 3-6 shows an example where 2 Byte of Partial Networking Information are contained in the User Data field. Furthermore, as also shown in the figure, the CBV isn’t optional anymore. The PNI Bit contained in the CBV is mandatory for Partial Networking and set if PN Information is contained in the NM PDU.
The PN Information itself describes if a PN is requested. Every Bit in the PN Information stands for a request of the related PN. Table 3-7 shows an example of one Byte of PN Information. As shown the PNs 0, 3 and 6 are requested.
Partial Network States
Every state change (transition from PN Released to PN Requested and vice versa) is indicated to the PduR by calling PduR_UdpNmRxIndication(). The need for a call to the Rx Indication is aggregated within one processing cycle of the PN Information in order to reduce the number of calls to at most one per cycle. Received Partial Networking requests are only processed if they pass the preconfigured PN Filter Mask. Refer to chapter 3.19.3 for further information.
Figure 3-3 shows the state machine for the PN states.
EIRA
The EIRA-PDU is used to aggregate internal and external PN requests respectively states. These states are influenced by the transmission and reception of NM PDUs containing PN Information and an additional timeout releasing the PN if it isn’t requested for a certain time anymore.
The scope of the EIRA-PDU is global. It collects the PN Information from all channels running Partial Networking.
Internal requests for PNs are contained in the User Data Tx PDU. The external requests are collected from the common Rx NM PDUs.
ERA
The ERA-PDU is used to aggregate only external PN requests respectively states. States are influenced by the reception of NM PDUs containing PN Information and an additional timeout releasing the PN if it was not requested for a certain time.
The scope of the ERA-PDU is a channel scope. Therefor every channel enabling Partial Networking has its own ERA-PDU. This scope enables the upper layer to retrieve which channel requests a PN.
The requests are retrieved from the common Rx NM PDUs of the channel.
Partial Networking Information Filter
It is possible to filter not relevant PN Information. Therefore a filter mask is introduced and laid over the PN Information contained in the NM PDUs.
Table 3-8 shows an example of the filter mask processing. PN0 and PN3 are requested but not relevant for the node. The filter mask filters out the information and as a result only PN6 is recognized as requested.
Selective Shutdown
Selective shutdown describes the possibility to shut down channels and/or ECUs in case they have no need to participate in the current communication. The filtering is done according to description in chapter 3.19.3.1.
If a NM message is not relevant and the configuration parameter ’All Nm Messages Keep Awake’ is true the standard NM message reception handling is done, otherwise the NM message is ignored. As a consequence the ethernet channel is subsequently shutdown in case no relevant PN is requested by the own ECU and by other ECUs.
Handle Multiple Network Requests
The Handle Multiple Network Requests feature allows to initiate a state transition from Ready Sleep State, Normal Operation State or Repeat Message State to the Repeat Message State by a call to UdpNm_NetworkRequest().
Error Handling
Development Error Reporting
By default, development errors are reported to the DET using the service Det_ReportError() as specified in [2], if development error reporting is enabled (i.e. pre-compile parameter UDPNM_DEV_ERROR_DETECT == STD_ON).
If another module is used for development error reporting, the function prototype for reporting the error can be configured by the integrator, but must have the same signature as the service Det_ReportError().
The reported UdpNm ID is 33.
The reported service IDs identify the services which are described in chapter 5. The following table presents the service IDs and the related services:
The errors reported to DET are described in the following table:
Production Code Error Reporting
By default, production code related errors are reported to the DEM using the service Dem_ReportErrorStatus() as specified in [3], if production error reporting is enabled (i.e. the related DEM-Event must be configured in the configuration tool).
If another module is used for production code error reporting, the function prototype for reporting the error can be configured by the integrator, but must have the same signature as the service Dem_ReportErrorStatus().
The errors reported to DEM are described in the following table:
References
MICROSAR UDP Network Management Technical Reference (Version 3.02.00)
标签：UDP,Management,Network,Data,PDU,UdpNm,Sleep,PN,NM From： https://blog.csdn.net/erroror/article/details/144881043