Specification Requirements for ECU Ethernet Modules

Specification Requirements for ECU Ethernet ModulesThis article is approximately 6,000 words,recommended for collection and reading

Author | Anonymous

Produced by | Automotive Electronics and Software

Specification Requirements for ECU Ethernet Modules

1. Overview

Implementing an Ethernet communication stack in advanced ECUs requires meeting numerous requirements, which involve functionality, configuration, operation, and interfaces with other modules, aimed at ensuring the reliability, flexibility, and security of Ethernet communication while meeting the specific needs of automotive electronics ECUs.

The following will introduce an overview of the functionalities related to Ethernet communication modules, including TCP/IP protocol stack (TCP/IP), Socket adapter (SoAd), DoIP, Ethernet interface (EthIf), Ethernet driver (Eth), Ethernet transceiver driver (EthTrcv), Ethernet switch driver (EthSwt), Ethernet state manager (EthSM), UDP network management (UdpNm), and service discovery (Sd) and other modules. These modules together form the core architecture of Ethernet communication, responsible for handling communication tasks from the physical layer to the application layer.

Specification Requirements for ECU Ethernet Modules

2. TCP/IP Protocol Stack

The TCP/IP protocol stack is a core component of network communication, and it must implement both IPv4 and IPv6, which covers everything from basic IP packet encapsulation and routing to more complex network address management. Among them, in the IPv4 environment, it is necessary to integrate the Address Resolution Protocol (ARP) to map network layer addresses to data link layer addresses; while in IPv6, the Neighbor Discovery Protocol (NDP) is used to perform similar functions while handling more tasks related to automatic address configuration and link state. Additionally, to dynamically allocate IP addresses, both IPv4 and IPv6 environments must support the Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6), which automatically assigns IP addresses and related configuration parameters to devices on the network.

In terms of network management and diagnostics, the TCP/IP protocol stack should support the Internet Control Message Protocol (ICMPv4 and ICMPv6), which are used not only to report error messages, such as destination unreachable or timeout, but also to perform network connectivity tests such as ping operations.

At the transport layer, the protocol stack needs to implement the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). TCP provides reliable, connection-oriented communication services, with complex congestion control strategies implemented internally to optimize network resource utilization and avoid congestion collapse, while also incorporating theNagle algorithm to reduce the number of small packet transmissions and improve network efficiency. In contrast, UDP provides connectionless, unreliable but fast communication services, suitable for applications with high real-time requirements.

In terms of security, the TCP/IP protocol stack must support the Transport Layer Security (TLS) protocol, which not only means being able to encrypt transmitted data to protect it from eavesdropping and tampering but also includes support for Pre-Shared Key (PSK) mode, allowing simplified security authentication using predefined keys. Additionally, the protocol stack should provide flexible TLS connection configuration options to meet the security needs of different application scenarios.

To facilitate network administrators in monitoring and diagnosing network performance, the TCP/IP protocol stack should also provide a set of access interfaces that allow real-time access and querying of various measurement counter values, including but not limited to the number of packets sent/received, error rates, packet loss rates, and other key indicators, thus ensuring transparency and maintainability of network operating status.

Specification Requirements for ECU Ethernet Modules

3. Socket Adapter

SoAd must have the capability to support local multi-homed hosts, which means it can allow ECUs to connect to multiple IP networks simultaneously, greatly enhancing the system’s network connectivity and redundancy.

In terms of protocol support, SoAd must fully support TCP and UDP, the two mainstream transport layer protocols. In TCP connection management, SoAd should automatically close all open TCP connections when the adapter is closed to ensure proper resource release; at the same time, in the event of unexpected connection loss, SoAd should have the ability to automatically re-establish connections to maintain data transmission continuity.

To enhance the predictability and maintainability of the system, SoAd must provide resource predictability features. This allows developers to accurately predict the resources required for socket connections by analyzing configuration information, enabling more reasonable resource allocation and performance tuning.

At the data transmission level, SoAd must provide an efficient buffer memory allocation API to support dynamic memory management during data transmission. Additionally, to reduce data transmission latency and overhead, SoAd should also optimize copy operations during data transmission, such as using zero-copy techniques to minimize unnecessary data duplication.

Furthermore, SoAd must implement a multicast mechanism for PDU. This mechanism allows PDUs to be transmitted simultaneously to multiple receivers, thus supporting complex network communication modes such as broadcasting and multicasting.

Specification Requirements for ECU Ethernet Modules

4. Ethernet Interface (EthIf)

First, EthIf should provide flexible configuration options to adapt to different application scenarios. This includes the choice between interrupt mode and polling mode, where interrupt mode can respond promptly to network events, while polling mode is more suitable for environments with lower real-time requirements, reducing interrupt overhead by periodically checking network status.

At the hardware level, EthIf must provide comprehensive hardware configuration and initialization interfaces that implement hardware abstraction, allowing upper-layer software to operate without directly manipulating lower-level hardware details, thus improving system portability and maintainability. Meanwhile, EthIf should also have the capability to indicate link status changes, so that upper-layer software can perceive the establishment, disconnection, or changes in network connections in real-time and take appropriate measures.

To support complex network topologies, EthIf must have the ability to add and remove VLAN (Virtual Local Area Network) tags. This feature allows VLANs to be presented as independent EthIf controllers to upper-layer modules, thus achieving effective isolation and management of network traffic.

Additionally, EthIf should provide hardware-independent APIs so that upper-layer software can access the functions and configurations of lower-level hardware. These APIs should be designed to be clear and easy to understand and use, while ensuring effective management and utilization of hardware resources.

To support network performance monitoring and fault diagnosis, EthIf must provide access interfaces for measurement counter values. These interfaces allow upper-layer software to access and query various network performance indicators in real-time, such as the number of packets sent/received, error rates, packet loss rates, etc., thus ensuring transparency and maintainability of network operating status.

In terms of energy saving, EthIf should support receiving sleep requests and, when configured as a communication slave, be able to forward sleep requests to the Ethernet state manager (EthSM). This feature helps reduce system energy consumption in non-communication states and extend battery life.

To meet diverse communication needs, EthIf must also support PDU-based communication configurations. This means that EthIf can perform PDU and frame conversions between the internal communication stack and the Ethernet network, thus achieving flexible conversion and transmission of data formats.

Finally, to handle both best-effort and low-latency communication, EthIf must support scheduling configurations for subsets of the incoming queue. This feature allows the system to flexibly schedule the processing order of packets based on communication needs and data priority, thus ensuring timely transmission and processing of critical data.

Specification Requirements for ECU Ethernet Modules

5. Ethernet Driver (Eth)

First, Eth must provide flexible interrupt or polling mode configuration options to adapt to different application scenarios. Interrupt mode can respond in real-time to network events, ensuring timely processing of critical data; while polling mode reduces interrupt overhead by periodically checking network status, suitable for environments with lower real-time requirements. This flexibility allows Eth to be optimized according to the needs of different systems.

At the hardware level, Eth must provide comprehensive hardware configuration and initialization interfaces that implement hardware abstraction, allowing upper-layer software to operate without directly manipulating lower-level hardware details. This not only improves system portability and maintainability but also ensures effective management and utilization of hardware resources. Meanwhile, Eth should support various hardware interfaces, such as 10BASE-T1S hardware, SPI and MII interfaces to meet the needs of different hardware platforms.

To meet the basic needs of network communication, Eth must support receiving MAC broadcast frames and multicast frames. This feature ensures that broadcast and multicast messages in the network can be correctly delivered to target nodes, thus achieving effective management and distribution of network traffic.

In terms of time synchronization, Eth should support hardware timestamping functions to meet the needs of time synchronization messages. This feature allows the system to accurately record timestamps of network messages, thus achieving time synchronization between network nodes and providing a reliable time reference for distributed systems.

In terms of data transmission, Eth should support hardware-assisted data transmission to reduce CPU load and improve system performance. Meanwhile, Eth should also support direct and indirect data transmission requests, allowing upper-layer modules to provide data and initiate transmissions efficiently. This flexibility allows Eth to be optimized according to the needs of upper-layer modules and the characteristics of data transmission.

To meet diverse communication needs, Eth must support configuring incoming and outgoing queues, allowing frames to be classified and processed based on Ethernet frame attributes. This feature enables the system to flexibly schedule and process frames according to different traffic types and data priorities, thus improving network resource utilization and transmission efficiency.

In terms of traffic shaping and scheduling, Eth should support various transmission selection algorithms and scheduling algorithms. These algorithms include credit-based shapers, asynchronous traffic shaping, enhanced traffic shaping, and strict priority traffic shaping, which can ensure the network robustness and low latency of time-critical traffic. Meanwhile, Eth should also support strict priority scheduling algorithms and enhanced traffic scheduling algorithms to optimize the processing of outgoing queue transmissions.

Finally, to further improve the transmission efficiency of time-critical traffic, Eth should support frame preemption functionality. This feature allows the system to preempt the bandwidth of low-priority frames during transmission, thus ensuring that high-priority frames can be transmitted and processed in a timely manner. This flexibility allows Eth to adapt to complex and variable network environments, ensuring the real-time and reliability of the system.

Specification Requirements for ECU Ethernet Modules

6. Ethernet Transceiver Driver (EthTrcv)

First, EthTrcv must provide a complete set of hardware configuration and initialization interfaces, which not only abstract the underlying hardware, reducing the development difficulty for upper-layer software but also ensure effective management and utilization of hardware resources. Through this set of interfaces, upper-layer software can easily complete hardware initialization configurations, such as setting operating modes and adjusting parameters, thus achieving flexible control over hardware.

To monitor network status in real-time, EthTrcv must provide access to link status. This functionality allows upper-layer software to obtain key information such as link connection status, speed, and duplex mode at any time, thus ensuring the stability and reliability of network connections. At the same time, this also provides strong support for the rapid localization and resolution of network faults.

At the hardware functionality level, EthTrcv must support access to standardized hardware functions, such as signal quality measurement and physical layer test modes. These functions not only help evaluate network performance but also play an important role in troubleshooting hardware failures. By measuring signal quality, issues such as signal attenuation and interference can be detected and resolved in a timely manner; while physical layer test modes allow comprehensive testing of hardware to ensure its normal operation.

To meet energy-saving requirements, EthTrcv should support enabling or disabling wake-up functionality at compile time. This feature allows the system to flexibly configure the wake-up mechanism based on actual needs, thus reducing system energy consumption while ensuring the reliability of network communication. Meanwhile, EthTrcv should also provide access to wake-up reasons, so that upper-layer software can distinguish between different types of wake-up events and take appropriate measures.

To further improve the reliability and availability of the network, EthTrcv should have the capability to actively wake up the Ethernet network and support forwarding and re-triggering of wake-up requests. This means that when a node in the network needs to communicate, it can send a wake-up request to wake up other nodes that are in sleep mode, thus ensuring the activity and communication capability of the entire network. Meanwhile, EthTrcv should also ensure proper management of sleep modes in Ethernet switch networks to avoid network failures caused by improper handling of sleep requests.

In terms of hardware compatibility, EthTrcv should support 10BASE-T1S hardware and MII interfaces to meet the needs of different hardware platforms. This feature allows EthTrcv to be widely applied in various Ethernet communication systems, enhancing the flexibility and scalability of the system.

Finally, to ensure proper management of sleep modes in Ethernet switch networks, EthTrcv should also support forwarding and re-triggering of sleep requests. This means that when a node sends a sleep request, EthTrcv can forward it to other relevant nodes in the network and ensure that these nodes can re-trigger sleep requests when necessary, thus maintaining the stability and reliability of the network. This feature is significant for reducing system energy consumption and improving network efficiency.

Specification Requirements for ECU Ethernet Modules

7. Ethernet Switch Driver (EthSwt)

EthSwt must provide a transparent interface to the underlying Ethernet transceiver module, which should allow upper-layer modules to seamlessly access APIs related to the transceiver, thus enabling flexible scheduling and control of hardware resources. To monitor network status in real-time, EthSwt must provide access to the hardware port status. This way, upper-layer modules can easily read the hardware status of connected ports, including connection status, speed, duplex mode, and other key information.

In terms of hardware management, EthSwt should support managing and controlling switch hardware through MII or SPI interfaces. These interfaces provide direct access capabilities to the hardware, allowing upper-layer software to flexibly configure switch parameters, monitor hardware status, and respond to network events in real-time. This flexibility ensures that EthSwt can adapt to the needs of different hardware platforms and network environments.

EthSwt must support storing switch configurations in non-volatile memory. This feature allows the system to automatically restore previous configurations after power outages or reboots, thus ensuring network stability and continuity. In terms of automatic configuration, EthSwt should support semi-static automatic configuration functionality. This means that when assembling or replacing ECUs, EthSwt can automatically learn certain parameters and persistently store these learned parameters. This feature simplifies the network configuration process and improves the scalability and maintainability of the system.

To meet complex network communication needs, EthSwt must support configuring forwarding rules, such as Address Resolution Table (ARL), VLAN membership, priority regeneration, and transmission schedulers and shapers. These rules ensure that data frames can be transmitted along predetermined paths and priorities in the network, thus improving network throughput and reliability.

To ensure network security and stability, EthSwt must support filtering and shaping functions for Ethernet traffic/ frames. Through filtering functions, EthSwt can identify and block burst traffic, limit the impact of faulty devices, and prevent denial-of-service attacks; while shaping functions can smooth network traffic, ensuring the efficiency and stability of data frame transmission.

To achieve fine control over incoming Ethernet frames, EthSwt must support flow identification functions based on different protocol layers. This means that EthSwt can check incoming frames based on frame protocol type, source address, destination address, and other information, and perform corresponding actions such as forwarding, dropping, or redirecting.

To meet the needs of time synchronization and path delay measurement, EthSwt must support switch frame management functions. This function should provide upper-layer modules with port-specific information related to time synchronization or path delay measurement frames, thus ensuring the synchronization and accuracy of the network.

To improve system reliability and maintainability, EthSwt should allow reset operations independent of the host ECU and switch hardware. This means that after a reset, EthSwt can correctly verify and reconfigure the switch, thus ensuring network stability and continuity.

To read detailed information about switch ports, EthSwt must provide access interfaces to the internal configuration of the hardware. These interfaces should allow upper-layer software to easily read the MAC addresses, mirroring configurations, and other information of switch ports, thus achieving comprehensive understanding and flexible management of network configurations.

Specification Requirements for ECU Ethernet Modules

8. Ethernet State Manager (EthSM)

First, EthSM must provide a set of network-independent configuration and initialization interfaces that implement hardware abstraction, allowing upper-layer software to operate without concerning itself with the specific implementation details of the underlying hardware.

In cases where Ethernet hardware has wake-up capabilities, EthSM must ensure that even if the requested mode has been achieved, it can re-trigger the request mode. This ensures that the entire Ethernet network can respond quickly and accurately when receiving communication requests, thus avoiding communication delays or interruptions.

Additionally, EthSM must forward sleep requests detected by the maintained Ethernet hardware as communication slaves to the responsible upper-layer modules. This functionality allows upper-layer modules to be timely informed of the sleep status of network nodes, thus taking appropriate measures to manage network traffic, optimize resource allocation, or trigger wake-up mechanisms.

Specification Requirements for ECU Ethernet Modules

9. UDP Network Management (UdpNm)

The core task of UdpNm is to provide a set of efficient and reliable interfaces for network management information to be sent and received via UDP protocol. This interface should ensure accurate transmission of information while reducing transmission latency to enhance overall network performance and responsiveness.

Additionally, UdpNm should at least provide functionalities equivalent to those of CAN network management (CAN NM), including but not limited to network status monitoring, fault diagnosis, network configuration, and resource management. The implementation of these functions not only helps improve the reliability and stability of the network but also provides convenient management tools for network administrators, reducing maintenance costs. Meanwhile, UdpNm should also have certain scalability to adapt to new network management needs that may arise in the future.

In addition to basic functionalities, UdpNm should also provide optional network services to meet specific needs in different application scenarios. These services may include but are not limited to network traffic monitoring, bandwidth allocation, priority settings, and quality of service (QoS) guarantees. By providing these additional services, UdpNm can further enhance the flexibility and controllability of the network, providing users with a better network communication experience.

Specification Requirements for ECU Ethernet Modules

10. Service Discovery (Sd)

Sd must build a comprehensive framework to provide APIs that support any protocol, thus allowing developers to implement service discovery functions across different protocol layers. This cross-protocol support capability not only enhances the compatibility of Sd but also makes it possible for its widespread application in various network environments.

To ensure the security of service access, Sd must implement strict access control mechanisms. Sd should support service provider checks, event subscriber checks, and method call request checks, which can ensure that only authorized IP addresses can access the corresponding services. In this way, Sd can effectively prevent unauthorized access and protect sensitive information and resources in the network.

To further enhance security, Sd should allow configuration and updating of access control list (ACL) policies. As a commonly used network security tool, ACL can define which IP addresses or user groups can access which network resources. By supporting the configuration and updating of ACL, Sd enables network administrators to dynamically adjust ACL content at runtime to respond to changing network threats and access needs.

When Sd detects unauthorized access requests, it can quickly trigger security alerts and report relevant information to the intrusion detection and management module (IdsM). As an important part of the network security system, IdsM can monitor network traffic in real-time, detect potential attack behaviors, and take corresponding defensive measures. The close integration of Sd with IdsM allows the network to discover and respond to security threats in the first instance, thus ensuring the secure and stable operation of the network.

Specification Requirements for ECU Ethernet Modules

11. Conclusion

The above specifications for Ethernet modules cover multiple aspects such as data transmission, network management, and diagnostic support. Overall, these functional requirements lay a solid foundation for achieving high performance, security, and flexibility in automotive Ethernet communication, meeting the stringent demands of modern automotive electronic systems for network communication.

/ END /

Leave a Comment