Rewiring Vehicles with AUTOSAR SOME/IP

Many modern automotive systems use Ethernet as the backbone for networking, where SOME/IP is used for signalling. SOME/IP is an automotive/embedded communication protocol that supports remote procedure calls and messaging using a publish and subscribe model.

In AUTOSAR, SOME/IP is implemented by four modules working in tandem: Sd, SoAd SomeIpTp and SomeIpXf, each handling one aspect of the SOME/IP protocol. When I first encountered the SOME/IP AUTOSAR specification, it was hard to understand the the role of each of these components, and was hard to form a good mental model. In this article, I hope to demystify AUTOSAR’s SOME/IP layering by looking into how wired point-to-point connections functioned in the past and how it relates to SOME/IP in the present day.

Tangled Point-to-Point Wiring

In the pre-CAN era of automotive communication, point-to-point wiring was used to connect sensors to actuators. Consider the example of a door sensor and the light controller. In a point-to-point wiring setup, a wire would run from the Door Sensor to the Light Controller and another to the Driver Dashboard. The following diagram shows the point-to-point wiring between the ECUs.

Given that each door has its own door sensor, a four door vehicle will have a total of eight wires to ensure all the data from the Door Sensors is available to both the Light Controller and the Driver Dashboard. The following diagram shows the point-to-point wiring with four Door Sensors.

With numerous sensors and actuators in a vehicle network, there will be a whole lot of wires running within the vehicle, making it a maintenance nightmare.

Untangling with CAN Bus

In 1983, Bosch developed CAN bus to solve this problem. The CAN specification was standardized in 1993. CAN bus uses a pair of wires to connect multiple ECUs. These ECUs send periodic broadcast messages on the bus for signalling. For example, a Door Sensor ECU would periodically send a CAN bus message indicating its door status. The Light Controller and Driver Dash dashboard will pickup these messages and take action accordingly. Even with multiple Door Sensor ECUs, no additional wires are required. All the Door Sensors can connect on the same CAN bus.

CAN bus solved many of the problems with point-to-point wiring. It has been adopted by nearly every car manufacturer.

While CAN bus served the automotive usecase for a long time, it has a significant bandwidth limitation. This became problematic for software updates for ECUs that had very large firmware images. Additionally, more complex ADAS sensors such as cameras, RADAR and LIDAR require high bandwidth networks.

Virtual Wiring with SOME/IP

The automotive industry developed a variant of Ethernet to support both signalling and high bandwidth applications. SOME/IP, developed by BMW, is used for time-critical signalling alongside other protocols for high bandwidth applications. SOME/IP is implemented as an application layer protocol on top of the TCP/IP stack.

Within AUTOSAR, SOME/IP is implemented primarily by the following modules:

1. SoAd - Socket Adaptor
2. Sd - SOME/IP Service Discovery
3. SomeIpTp - SOME/IP Transport
4. SomeIpXf - SOME/IP Transformer

SoAd: The Virtual Wiring

The SoAd is responsible for creating and maintaining TCP connections within a vehicle network. The connections an ECU must maintain is provided as part of SoAd’s configuration, which is dervied from the overall system design. Let’s take our original example, a possible Ethernet network diagram is shown below.

During the system design, the designer identifies that both the Light Controller and the Driver Dashboard need access to the Door Sensor ECUs. The Door Sensor ECUs SoAd layer, implement a server socket and accept incoming connections, by listening on specific ports specified by its configuration.

The SoAd layer of the Light Controller ECU’s SoAd is provided a configuration to maintain 4 TCP connections, one to each door sensor. And the Driver Dashboard ECU’s SoAd is provided a configuration to maintain 4 TCP connnections, one to each door sensor. When the Door Sensor status changes, event messages are sent on the already established TCP connections.

These connections maintained by the SoAd mimic the point-to-point wiring that we originally had in vehicles. These TCP connections act as virtual wires, on top of the physical Ethernet wiring.

Sd: Dynamic Re-Wiring

When SoAd is used with a static configuration the IP address for the nodes need to be static and fixed at compile time. But what if the IP address is dynamically assigned. The SoAd needs to know the dynamically assigned IP address. Sd addresses this problem. The Sd module of the Light Controller ECU periodically sends out an Offer message indicating its IP address. The Sd module in the Light Controller and the Driver Dashboard ECUs, use this information to re-configure the SoAd.

SomeIpTp and SomeIpXf: Wire Formatting

The SomeIpTp is responsible for generating the required headers when sending messages over the TCP connection. And the SomeIpXf is responsible for converting signals into the SOME/IP wire format for transmission.

Sd: Linking Events to Wires

While Sd helps in identifying the IP address of the nodes when the nodes have a dynamic IP, it is not limited to that. Sd is also responsible for implementing the subscribe mechanism. When an ECU A is interested in a particular event type from another ECU B, it needs to indicate this through a Subscribe request. Subsequent events of the type from ECU B will be sent to all the subscribed ECUs. The subscription of events is handled by the Sd layer.

In the case of Door Sensor example, the application component in the Light Controller ECU, would indicate to the Sd layer that it is interested in the Door Status Change event in the Door Sensor ECUs. Once each Door Sensor becomes available, the Sd would then send a subscription request to each of the Door Sensor ECU’s Sd layer.

Since the subscriptions are not persistent, the Sd keeps track of when a reboot occurs in the ECUs that it is receiving events from. When a reboot occurs, it re-triggers the subscription requests, thus ensuring that it always subscribed to events that ECU is interested.

Summing Up

Hope this is a given you a 1000 foot view of how the various AUTOSAR components work together to implement SOME/IP, especially the Sd and the SoAd. I took the liberty of excessively simplifying things for the reader to get a good mental model. But here are few things that you might want to be aware of.

1. In practice, Door Sensors would themselves would not be implemented as an Ethernet based ECU. The Door Sensors on side of the CAR would probably talk over a bus LIN or CAN to a larger ECU, which would then expose the Door Sensor over the Ethernet backbone.
2. This is further emphasized in modern Software Defined Vehicles (SDVs), that use Zonal Gateways to manage sensors in the zone and provide access to them over SOME/IP.
3. SOME/IP services were not discussed in this article, since it was not necessary while discussing the broader roles of SoAd, Sd, SomeIpTp and SomeIpXf. In practice, an ECU would have one or more SOME/IP services each listening on its own port. And each service would provide its own set of events.

About the Author

Vijay Kumar Bagavath Singh heads the Automotive Division at Zilogic Systems. He has been involved in multiple implementations of SOME/IP protocol stack on both AUTOSAR and non-AUTOSAR platforms. Whether you need firmware development, test automation, or embedded automotive software solutions, we’re ready to collaborate. Please feel free to reach out to us at sales@zilogic.com