Automotive Ethernet Socket API for C

The Automotive Ethernet Stack functions provide tools to create everything required for TCP and UDP communication, independent from the limitations of the IP stack native to your operating system (OS). A test application typically uses a single IP Stack for each XNET Interface (physical port), but more complex configurations are possible.

For example, suppose that you are testing eight identical instances of an ECU, each instance connected to a distinct XNET Interface (e.g., two 4-port Automotive Ethernet Interface Modules). For each of the eight repeated test setups, you could use the same static IP address for each XNET Interface, and communicate with the same static IP address in the ECU. This configuration is difficult to achieve using the native Windows or Linux IP stack, because the operating system assumes that each interface uses a different unicast IP address.

As another example, to fully test a physical ECU, suppose you need to simulate six real ECUs that are part of a single in-vehicle network. (This is sometimes called "restbus simulation.") The IP stack enables you to configure six distinct virtual interfaces in the IP stack to represent multiple simulated ECUs. These virtual interfaces can all run on the IP stack associated with a single XNET Interface (physical port) that is connected to your real ECU under test.

For a given XNET Interface, TCP and UDP traffic switch from the OS stack to IP Stack when you call nxIpStackCreate the first time for that XNET Interface. Communication changes back to OS stack when you call nxIpStackClear the last time for that XNET Interface. When you are viewing traffic on the XNET Interface (e.g., Wireshark on ENET2), you might notice that some protocols run in the OS stack (e.g., Windows running DHCPv6), but those protocols cease after you call nxIpStackCreate.

IP Stack functions are specific to NI-XNET.