Ethernet represents one of the most famous communication protocol for the physical and Data Link Layer (DLL) OSI stack for network communication. The previous two layer can be completed by IP protocol for the network layer and then TCP or UDP at the Transport layer.

The main advantage of the OSI stack network communication is in the possibility to establish remote networks nodes communication in a very flexible manner. The OSI communication stack allows an high dynamic management of the network nodes, mainly thanks to the logic in addressing mode. Each node has a logic addresses that can change according to the network necessity without changes int eh physical environment.

The Ethernet communication stack for the AUTOSAR perspective is not so much different from the other communication protocols.

The following picture (referenced from AUTOSAR_SWS_TcpIp.pdf ) shows all the BSW modules in the communication stack  for establishing an OSI stack network communication. Please consider that no all the real BSW modules are in the picture but they will be explained in the next sections anyway.

The next sections reports the main tasks for each module in the communication stack. The base configuration hints for each one is reported too.

Please let's consider that no all the possible use cases for a network configuration are considered there, but just the main topics for a base configuration.

The following modules are also in the scope of the Ethernet networking:

1. V2X
2. CDD

Features

EtherIf provides an Hardware Independent Application Process Interface (API) to the AUTOSAR Service Layer. Hardware-Independent means that System Services has not any knowledge about:

1. Ethernet Controller
   
2. Ethernet Transceiver
3. Ethernet Switches

And the EthIf accesses to those resources by the means of Hardware specific drivers too.

The EthIf provides the Hw-Independent APIs to the following BSW communication modules:

• TcpIp BSW
  
• EthSM

In same cases also the following modules request the EthIf APIs:

• CDD
  
• V2X

The Interface uses an indexing methodology This last allow the abstraction of the main Ethernet hardware resources in the service layer. The interface is responsible to keep a mapping between the Virtual Hw index in BSW and the real Hw index in the Driver.

The intended functionality of the UdpNM module is to play as a network manager supporting module for the TCP/IP protocol. This because the Ethernet protocol does not define a protocol-specific Network manager as CAN, LIN or FlexRay. The UdpNM mainly acts itself as a coordinator for network mode transitions.

Due to this, UdpNM might play an important role in the Partial Networking using the Ethernet protocol.

As main difference with respect to the other Network managers, the UdpNM does not directly interact with the Interface layer. The UdpNM just interfaces itself with the Socket Adaptor in the communication stack(Service Layer). By the other hand, UdpNM synchronizes itself with the general NM module as for the others protocols.

As Additional feature, the Udp can optionally implement a service to:

1. Detect all presents node in the network;
   
2. Detect if a node is ready to go in sleep mode.

The main limitation in the deployment of the UdpNM: The multiplicity between NM-Cluster and UdpNM instance is a mandatory 1-on-1. So that more NM-Clusters in one single ECU requires a 1-on-1 instances of UdpNM as interface between Socket Adaptor and Network Manager.

The UdpNM is very useful in distributed networks. It currently implements a coordination algorithm among the several nodes in a NM cluster.

The main Coordination algorithm step are the following:

1. A NM-Cluster is "enabled" whenever its nodes receive the NM periodic packets via broadcast;
   
2. If a node in the NM-Cluster is detected in "Ready to Bus-Sleep" mode, then
   1. it can stop participating to the communication;
   2. stays in the current mode until the cluster is awake;
3. If all nodes in a cluster has not received any NM packet for a specific amount of time, all nodes in the cluster moves to Bus-Sleep mode;
4. If one single node requires a communication by sending a NM packet from a cluster, then the cluster is kept awake.

NOTE:  The UdpNM coordination algorithm works for any single node in a cluster independently

UdpNM manages the Partial Networking for the Ethernet communication protocol. The configuration phase is very similar to the configuration of the protocol specific-NM. As the other communication protocols, the Protocol-specific Network Manager manages the Partial Networks per channels. The Channel Virtualization between Network Managers and ComM allows the right level of abstraction to the Physical part.

The Partial Networking request a coordinator and an attender. The coordinator is able to manage the Partial Networking as internal requests, while the attenders receive the requests as external information. In both of the cases, the global Network Management interface (Nm module) acts as a coordinator between ComM and Protocol-specific Nms for these requests.

In particular, the ComM is the main actor that manages the internal requests of partial networking. So that, it plays a very important role in the coordinators. By the other side, the Protocol-specific Network Manager (UdpNm) handles all the received request from remote actor (the coordinator) and then UdpNm forwards them to the higher level modules after a filtering activity per configuration.

UdpNm uses the NM-PDU and frames for exchanging all the "logistic" information and communication-of-services in a Partial Networking communication system. Therefore the main task of the UdpNm are the following:

• Manage the Reception Indication of the NM-PDU
• Manage the transmission Indication of the NM_PDU
• Retry information about the EIRA and ERA request from ComM, by Network management Interface;
• Manage the PDU filtering according to PN values;
• Manage spontaneous transmission of the NM-PDU;

The NM-PDU are packets that travel on the network as normal PDU, but they specifically contain information about the status of the Networking. In case the Partial networking are in aggregation, the particular Partial networking Management signal is an EIRA or ERA signal.

in chapter 7 of the AUTOSAR_SWS_UDPNetworkManagement.pdf is possible to see the NM-PDU payload structure with all the necessary information for the Partial Networking.

The main scope for the Nm prtocol specific is to manage the Partial Networking timing operations.

The Socket Adaptor is an interfacing module between the Transport and Network Protocol (respective the TCP and the IP) and PDU Router and UdpNm.

The Socket Adaptor also interfaces itself with the Service Discovery Module and the Diagnostic Over IP module (DoIP).

The Socket Adaptor acts as bridge between the opposite concepts behind:

• the very static (rigid) establishment of communication of AUTOSAR (pre-determined at compile time)
• and the dynamic routing and networking of the OSI stack.

The main task of the Adaptor is to map I-PDU identifier to a socket connection. This shall work as a glue between the TCP/UDP Transport protocols and the PDU protocol that is native in AUTOSAR. In oaricular:

• TCP is connection-oriented, therefore the connection is Point-to-point and a negotiation to define the connection is necessary at priori;
• UDP is connectionless, therefore it can be used in multicast or broadcast communication is possible.

The socket connection defines a Process-to-Process communication. Each connection requires a description, the Socket Descriptor. This descriptor contains the aggregation of IP and TCP addresses and in addition the port number. In SoAd specification, the socket description contains just only IP address and port number.  A port identifier maps a specific process or application that shall run on that connection.

Each connection shall have an unique socket, even if they are between the two same modules.

SoAd is able to manage any connection thanks to the Socket API, in a synchronous manner.

The SoAd shall also ask to the PduR about a PDU route: each PDU shall be mapped to a socket connection, but the PDU shall pass through the PduR before going to Transport Protocol. In case of a PDU reserved on ethernet physical bus, the PduR shall pass the PDU to the socket adaptor in order to get the PDU respective connection and then the right transport protocol.

All routes between the TcIp and the socket connection are in scope to the SoAd. They are called socket Route. The socket route is also used for forwarding the UDP/TCP from SoAd to the upper layer:

• In case of UDP protocol, the Socket Route defines the best route to follow

The main configuration of the SoAd allows:

1. PduRoutes
   
   1. RouteDest
2. PduRoutingGroups
3. SocketConnectionGroups
4. SocketRoutes

The TcpIp module offers the possibility to send and to receive data via Internet Protocol.

The TcpIp protocol receives data inform of datagram from the interface layer. Then it applies all the process in order to assign the IP addresses to the datagram.

According to this and the other configurations, the datagram will be:

• A Packet for the UDP;
  
• A segment for the TCP;

Once the transport protocol ends its processing on the item header, then the transmission can happen thanks to the interfaces of the SoAd. In particular the SoAd will receive:

• Message if the UDP choosen
  
• Stream if the TCP choosen

IP v4/v6

This component defines the scalability. Scalability defines more classes according to the selected internet protocol.

The default Internet protocol is the IPv4 (32bit - 4 Byte) with a multicast communication system. The Internet Protocol allows the addressing of several hosts by the same IP thanks to sub-network addressing.

An IP address is used by several network devices as gateway and routers.

The IP allows security mechanism of the ARPANET.

The IP reliability follows the value of the MTU (Maximum Transfert Unit) in order to get smaller encapsulation than the self MTU.

NOTE: The IP is just an header packet for data from the upper layer. At the same time, the upper layer shall know how to unpack stream or message in order to get the payload.

The layout of the IP packet is the following (source of images here)

ARP

The ARP protocol allows a mapping between an IP address and a MAC (Media Access Controller). This last is a logic address (in DLL), nearer to the physical part of a device than IP address.

ICMP

The Internet Control Message Protocol can be configured as optional parameter in TcpIp/TcpIpGeneral/TcpIppV4General/TcpIpIcmpEnabled.

The ICMP allows:

• The Control protocol over the IP communication protcol;
  
• The transmission of error messages over the IP, for example to inform for a missing service or unreachable host;

Just for mention, the IP protocol allows the PING operation. A node pings another network node in order to label it as "reachable". The ping operation is done by the destination host IP address. The ping program is an example of ICMP usage.

Ping just sends an ICMP packet to the host destination, creating an Echo request on the network interfaces. The Echo request always waits for an echo reply. If the echo receives the request, then it replies with another ICMP message.

In case the Echo reply misses for a certain amount of time, then the host considers that request as lost. In case, the router does not contain the hops path to reach that host, it directly replies to the source with the "unreachable destination".

The ICMP differs from other packets because it is always directed to the source of the communication.

The ICMP packet layout is the following (source of image here)

As Configuration overview:

The TcpIp module requires a direct configuration of the EthIf controllers. For each controller is possible to configure the own TTL for Internet Protocol.

Then for each controller, the TcpIp shall:

• identify the version of the IP
• Set if the ageing timer for the ARP table si enabled;
• Specify if the system is able to perform an echo to the ICMP;

The configuration of the IP can be done as it follows:

This container is the one that is referenced by the SoAd.

Another important point is the assignment of the IP address. This can be static or dynamic. The configuration can be done as the following picture:

As mentioned, the transformation of a OSI transport protocol in a PDU, cannot be done automatically but it requires a module as interface. This module can be:

• Socket Adaptor (to be configured according to autosar specification);
  
• Complex Device Driver;

This choice is configuration-specific one. You can address this in the following section of the  TcpIp configuration:

The Service Discovery module manages all the service-labeled software entities in the vehicle network.

ECU can offer service instances to all the other nodes of the network. Each Service instance implements a Service Interface. The Service Discovery:

• evaluates the status of this Service Instance.
  
• Find Services Instances in the vehicle network;

So that the Service Discovery amps all the services for an ECU.

The second (but not least) task is to control the event-message transmission by means of a Publish/Subscribe mechanism.

The Publish/Subscribe mechanism is possible thanks to the Scalable service-Oriented MiddlewarE over IP (or SOME/IP).

The Events are the service communication, generally between an Offer and a Requester.

The Service Discovery has the following message format:

At communication level, the Service discovery interacts with the SoAd.

The Service Discovery takes the main requests from the upper layer thanks to the BswM. Then it recovers all network information about a specific service, and then ask to the SoAd the transport and network services to allow the communication between client and servers.