CAN Newsletter magazine
The authors take a look on IP concepts with CAN XL and the transformation of Some/IP towards Some/CAN. Additionally, this article sets out several options for implementing service-oriented communication with CAN XL.
The complete article is published in the December issue of the CAN Newsletter magazine 2020. This is just an excerpt.
The networking of future generations of automobiles will be based primarily on use of the various Ethernet and CAN variants. While Ethernet dominates with its service- based IP communication and Some/IP middleware at the level of assistance systems, signal-based CAN networking will continue to exist long into the future in the drive and chassis sector. The new CAN XL should assume an important role in enabling these two fundamentally different concepts to co-exist and to work alongside one another. This raises questions as to whether the CAN XL ECU (electronic control unit) participates in service-based communication, and about the possible ways that might exist for enabling this to happen.
In broad terms, the key technical parameters for CAN XL have been defined: The new CAN variant offers data speeds of up to 10 Mbit/s and, with a variable length of user data in a range of 1 byte to 2 048 byte, it is also capable of transporting complete Ethernet frames inside CAN XL frames. As you would expect, CAN XL is otherwise broadly speaking reverse-compatible with Classical CAN or CAN FD and with the concept of signal-based communication. This is of particular benefit for the further development of electronic architectures for small and compact automobiles for which, at this time, no Ethernet high-performance communication is required for advanced driver assistance systems (ADAS) and autonomous driving. CAN XL makes it possible to continue using existing networking concepts and wiring harnesses without the need for big modifications.
Nonetheless, the future will inhabit the realm of service-oriented IP communication with Ethernet, according central significance to Some/IP (scalable service-oriented middleware over IP) middleware with its Some/IP-SD service discovery process. On board vehicles, Some/IP enables dynamic links to be established between providers (data sources) and consumers (data sinks). For modern applications, it does not matter who is supplying data or services.
Service-oriented communication is also in charge of the transmission of dynamic data structures. The volume of data to be transmitted, for example in the case of sensor data fusion applications, is generated only during the runtime of the application. Such data cannot be mapped statically in the way typical of signal-based communication. Instead, the communication system must serialize the data dynamically. The SomeIpXf module is responsible for serialization in the Autosar Classic Platform. Since it is part of the middleware level of Autosar, its functionality can be used to serialize dynamic data for CAN XL as well.
Some/IP supports both, fully dynamic and semi-dynamic link connections. The fully dynamic link connection is used when the network nodes do not know each other's IP and MAC addresses. A few benefits are associated with the establishment of dynamic communication on all protocol levels: A service can be relocated within the network to any other desired node without requiring modifications to the ECU. The same applies to MAC and IP addresses. When required, consumers and providers may make multiple use of the Address Resolution Protocol (ARP) to determine their respective MAC and IP addresses.
Likewise, there are reasons in favor of a semi-dynamic link connection with static IP addresses and MAC addresses. Each ECU has a mapping table in which the IP and MAC addresses of the other network nodes are saved. This method also establishes dynamic communication on the service level during runtime, but allows communication to start faster because it can do so without ARP. With a semi-dynamic link connection, services can also be moved arbitrarily because all IP and MAC addresses are known. The drawback here is that IP/MAC addresses can now no longer be changed. In this case, the mapping tables in all ECUs involved would also have to be updated. What is important to know is that, depending on the vehicle or model series, the industry sometimes uses fully dynamic and sometimes semi-dynamic link connections. Some/IP works with every Ethernet variant, regardless of whether it only involves switched networks or ones with net- work topology.
To do justice to its role as the link element between Ether- net and CAN domains, CAN XL should also be able to participate in service-oriented communication. It is therefore of great interest to the designers of future E/E architectures to establish which options CAN XL can offer to this in technical terms. At the same time, users continuously strive to find the most cost-effective solution. A crucial factor in this is to establish which requirements individual solutions impose on the soft- ware stack and on the ECU hardware.
The first possibility is to route Ethernet frames on CAN XL. To this end, a standard Ethernet switch can be used. On the hardware side, it is necessary to develop and then incorporate a CAN XL PHY between the port to which the CAN XL network is attached and the CAN XL network. The CAN XL PHY should be able to copy all of the Ethernet frames to CAN XL frames and vice versa – depending on the direction of communication. It is needed only at the Ethernet switch, while at the CAN XL nodes commonly used transceivers suffice. Of course, it is also always possible to use a conventional gateway (figure 1).
The demands on the CAN XL stack are considerably higher. As soon as Ethernet frames can be incorporated in CAN XL, a common TCP/IP stack will also be required in the CAN XL ECU. Keep in mind: Embedded in the CAN XL frame is an Ethernet frame, which also contains an IP packet. The interface layer, in turn, must be able to accommodate the behavior of CAN as well as that of Ethernet. The CAN part of the interface layer unpacks the Ethernet frame, while the Ethernet part unpacks the IP frame. In addition, each CAN XL node requires a virtual MAC address. The CAN XL PHY then just requires one CAN frame for further transmission of the frames received by the Ethernet network to CAN XL, and for every CAN XL node to have another CAN frame for response data. Filter functions can be performed on the basis of the MAC address embedded in the frame. Under these conditions, Some/IP, Some/IP-SD, and ARP function exactly as in a pure Ethernet network (figure 2).
News and reports