01

The introduction of Ethernet to the automotive industry not only increased available bandwidth substantially, but also established IP-based communication in the automotive en-vironment. First applications focused primarily on offboard diagnostics, especially on the flashing process. Traditional domains such as powertrain, body and chassis continued to use bus technologies such as Controller Area Network (‘CAN’), Local Interconnect sub-bus Network (‘LIN’) and FlexRay, and they took the approach of signal-based, stati-cally configured communication. Nonetheless, it made sense to shift more communication to Ethernet technology and take advantage of its benefits more broadly.

To this end, the automotive industry introduced a new physical layer (“automotive Ethernet” or 100BASE-T1) and the first automotive middleware protocol: SOME/IP (Scal-able Service-Oriented Middleware over IP). For some time now, there has also been more discussion about protocols from the IT world and the Internet of Things (IoT) field. Their key characteristic is their data-centric approach. The protocols of primary interest are DDS (Data Distribution Service) and MQTT (Message Queuing Telemetry Trans-

These days, users want to adapt their vehicle to their personal preferences, expand it with functions and provide it with regular updates, just as they do with their mobile devices. One building block for technically implementing these desired properties is Internet Protocol (‘IP’) based communication; IP opens the way for new design patterns, because it enables the use of higher-layer protocols. These “middleware” protocols should be examined in greater detail. What are their defining characteristics? And which ones can be considered for use in the automotive environment?

Middleware Protocols in the Automobile:Service-Oriented, Data-Centric or RESTful?

PREEvision Technical Article

port Protocol). Also suitable as a technology in some indi-vidual applications is REST (Representational State Trans-fer). It implements a pull method which is relevant to user interactions, for instance. However, REST lacks one prop-erty that is important for engineering control systems: It cannot send data in an event-triggered way (on Event). Without this push method, widespread use of the protocol in vehicles is unlikely. That is why REST is not examined fur-ther here.

Instead, this article offers an overview of MQTT, DDS and SOME/IP and compares the protocols regarding their suit-ability for communication in the vehicle. How can they be implemented in Electronic Control Units (‘ECUs’) , and how does this affect the embedded architecture? What consequences are there for designing and modeling on the system level?

02

Middleware Protocols in the Automobile / March 2020

Origins and Communication ParadigmsMQTT was published in 1999 and has been administered by the Organization for the Advancement of Structured In-formation Standards (OASIS) since 2013. The two main versions of MQTT are Version 3.1.1 (published in ISO/IEC standard 20922) and the follow-up version 5 that ap-peared in 2019. The key advantages of MQTT are its low resource demands and its suitability for use in unreliable networks, which have made it popular in the IoT world. Here, MQTT relies on a central “broker” (Server), which communicates information (Topics) between senders (Publishers) and receivers (Subscribers). Nodes can pub-lish messages under certain topics and subscribe to receiv-ing messages on certain topics. TCP is used as the trans-port protocol here (Figure 1).

A publisher-subscriber pattern is also used in DDS, although decentralized without a broker (Figure 2). The first version of DDS was published by OMG (Object Management Group) in 2004; Version 1.4 is now available. With DDS, communica-tion may be both unicast or multicast, which is why both TCP and UDP are used as transport protocols. When multi-cast is used, UDP enables more efficient communication than TCP. Compared with MQTT, the primary consider-ations with DDS are transmission dynamics and flexibility as well as its scalability for systems with a lot of nodes.

SOME/IP, published in 2013 , is the only protocol specifically developed for automotive use. Here, the providers and con-sumers of services stand in direct relation to one another without a central broker. Data and functions are encapsu-lated into services based on the paradigm of service-ori-ented communication. Methods, events and fields are used in the description of the service interface (Figure 3). SOME/IP, like DDS, utilizes unicast and multicast communication and is typically based on UDP.

Figure 1: System logic of communication of the MQTT protocol communication with quality of service (QoS) parameters.

Broker

Publisher

Publisher

Subscriber

SubscriberQoS

QoS

QoS

QoS

QoSQoS

Publisher

Topic 2

Topic 1

Author

Markus Helmling Vector Informatik GmbH Product Manager Ethernet Solution

Author

Alexander Mayr Vector Informatik GmbH Product Manager PREEvision

03

Middleware Protocols in the Automobile / March 2020

Communication Design and ElementsIn the world of signal-based communication, signals are sent out periodically or are event-triggered. There are no plans for a native communication pattern of Remote Pro-cedure Calls (RPC) or a native dynamic subscription mech-anism for notification of changes. If necessary, they are manually emulated on the application level. SOME/IP han-dles these paradigms innately. Event-triggered transmis-sion of data is also the basis for communication with MQTT and DDS. The necessity of RPCs (MQTT Version 5) was also recognized for both protocols. However, they are not supported directly, rather only by combining multiple topics as forward and return channels.

The MQTT protocol only prescribes a byte array with a maximum length of 256 megabytes. Serialization and deserialization of the useful data (UTF8-coded strings) is handled autonomously by the sender and receiver. DDS, on the other hand, offers detailed typing of the data and a dedicated transport protocol. However, like MQTT, it too involves byte array serialization. With SOME/IP, the data is also typed in detail. Serialization of supported data types is defined in the standard. SOME/IP permits data messag-es with a payload of up to 4 gigabytes based on its 4-byte length field.

How do the publishers and subscribers of data or services find one another? This is a fundamental question in dynam-ic systems, especially in the case of multiple instances, i.e., multiple providers of data. The answer of SOME/IP is what is known as ‘Service Discovery’, a mechanism over which services are offered at runtime and notifications can be subscribed to. This mechanism also exists with DDS. In MQTT, on the other hand, the implementation is different due to the central broker. The broker manages all topics at runtime. To obtain a listing of all topics, it is possible to sim-ply subscribe to all topics with a wildcard on the root level.

Quality-of-Service (QoS) parameters are often utilized to compare communication protocols. They include parame-ters such as data rate, reliability and fault tolerance. Mid-dleware protocols do not cover all characteristics, and they may need to be implemented on the next higher layer in the application. Some of these factors are also affected by the underlying transport protocol. In MQTT, the only QoS parameter that is specified is reliability. The user can choose between three different QoS levels, for both pub-lishing (sender to broker) and subscribing (broker to receiv-er). They range from Fire-and-Forget to confirmation of delivery including historic values. SOME/IP does not define its own QoS mechanisms, and it relies on the application

Figure 2: System logic of communication of the DDS protocol.

DDS Domain + Discovery

DataWriter

DataWriter

DataReader

Topic 2Type QoS

Topic 1Type QoS

Publisher Subscriber

DataReader

DataReader

Subscriber

04

Middleware Protocols in the Automobile / March 2020

and the mechanisms of TCP and UDP for implementation. DDS, on the other hand, supports a wide range of QoS mechanisms. Not only is transmission reliability imple-mented; so are latency and fault tolerance. Also offered are functions such as a software watchdog, data saving and administration of metadata which can save a lot of effort on the application level.

Effects on the Embedded ImplementationThe vast majority of today’s Ethernet-capable and there-fore IP-capable ECUs are based on ‘AUTOSAR’ (AUTomo-tive Open System ARchitecture). When considering an em-bedded implementation of DDS, MQTT and SOME/IP, the question arises: How well can they be integrated into an existing AUTOSAR solution? Also important are the memo-ry usage and the processor load that a solution causes in the given architecture. AUTOSAR distinguishes between two basic platforms: the Classic Platform (‘CP’) and the Adaptive Platform (‘AP’). The CP was designed for tradi-tional control systems that are based on relatively small microcontrollers. The configuration is largely static, con-trolled by an OSEK operating system. The entire solution is compiled monolithically in binary. It is still able to fulfill stringent requirements for real-time capability and short start times. Generally, however, the semiconductor chips

used here have very limited RAM and ROM resources, espe-cially in a direct comparison to the semiconductors that are typical in AP systems. As a supplemental standard for high-performance ECU’s, the AP was designed to be exe-cuted on microprocessors and application cores under POSIX -based operating systems. The resources of typical semiconductors for the AP are also expandable, because they are generally operated with external flash and RAM chips. Overall, greater value was placed on flexibility in specifying the AP: this flexibility refers primarily to soft-ware that is added later and to updating capability.

In the CP, the application layer interfaces with the basic software over the runtime environment (‘RTE’). In the AP, protocol specifications are implemented via protocol bind-ing beneath the ARA:COM interface. For SOME/IP, a na-tive implementation is used for both the CP and the AP. However, if AUTOSAR runtime is to be used for DDS and MQTT applications, the usual approach today is to access existing IoT implementations and adapt them to AUTO-SAR. Binding to DDS has already been defined in the AP. Therefore, it appears that integration for the AP will be possible with moderate effort initially. This is not the case for the CP where an adaptation to the RTE is necessary. On the other hand, there are no plans yet for MQTT in either

Figure 3: System logic of communication of the SOME/IP protocol.

Services + SD

*PSI: Provided Service Instance*CSI: Consumer Service Instance

PSI*

CSI*

CSI*

Service 2

FieldType

Service 1

EventType

Method

ParameterType

PSI*

05

Middleware Protocols in the Automobile / March 2020

CP or AP (Figure 4). Furthermore, all protocols need a way to communicate over sockets. Here, it is important to con-sider the interface to the TCP/IP stack, especially in the CP. SOME/IP is placed directly on the socket adapter, which also forms parts of the SOME/IP protocol header. In DDS and MQTT, this method is not possible due to the lack of protocol compatibility. In principle, placement on the socket adapter without the PDU header option or directly on the TCP/IP is therefore possible in the CP.

In evaluating the three middleware protocols, their re-source requirements are also of interest. It can be assumed that DDS will exhibit a much larger demand for memory than SOME/IP due to the scope of the protocol and its QoS features. Therefore, the DDS implementations avail-able for microcontrollers are usually very limited in their functional scope. The resource requirements of MQTT pri-marily depend on whether a broker or an end node is being

implemented. The latter can be integrated very efficiently in CP systems, for example. The extent to which MQTT memory requirements might be less than those of SOME/IP must still be demonstrated in future implementations. A similar situation exists when considering protocol over-head. Its many features and transmitted metadata make DDS a heavyweight. MQTT, on the other hand, with just a few bytes in its header is a protocol lightweight compared to SOME/IP.

Regarding data throughput: In a pure protocol analysis, there is currently no evidence that DDS is superior to SOME/IP in terms of performance. What is certain is that MQTT has poor scalability. Depending on the implementa-tion of the broker, latency increases disproportionately to the number of topics that need to be managed. This makes it more difficult to use MQTT for certain applications.

Figure 4: The DDS, SOME/IP and MQTT middleware protocols in the layer model and their link to AUTOSAR.

Application

Ethernet

IP

UDP / TCP

DDS - RTPS

DDS SOME/IP SD + XF

SOME/IP TP

TCP

MQTT

AUTOSARRuntime

Middleware

Transport

Network

Link

Physical

Classic

n/a ARA:COM

Adaptive

RTE ARA:COM

Classic Adaptive Classic Adaptive

n/a n/a

06

Middleware Protocols in the Automobile / March 2020

Differences in Architecture and System DesignThe central broker of MQTT is critical in terms of a func-tionally safe system design. This broker must be imple-mented redundantly in safety-relevant systems, since it is a potential single point of failure. MQTT Version 5 solves this aspect fully: there is an option for specifying an alternative server address. There are no fundamental obstacles to functional safety. At the same time, the central broker of MQTT is the bottleneck in cases of large data volume, and it must be sized accordingly.

This challenge does not exist in the decentralized layouts of the DDS and SOME/IP communication architectures. If ex-tensive Electric/Electronic architectures are implemented by different partners, a standardized exchange format is needed. DDS and SOME/IP benefit here from being adopt-ed into the AUTOSAR standard (DDS only in AUTOSAR Adaptive), so they can be described in a standardized way. This is not implemented in MQTT, in part due to the cited differences in typing and depth of detail.

Conclusions and OutlookAll three protocols have specific properties as well as ad-vantages and disadvantages for a given application. SOME/IP clearly reflects its origins and customization for automotive applications. It can be arranged seamlessly in AUTOSAR, and it earns high marks in terms of resource requirements and scalability. Unlike DDS and MQTT, how-ever, no QoS features are defined in SOME/IP. If these are needed for certain applications, they must be implement-ed in the application or in the transport protocol. The pur-pose of use must be considered in evaluating DDS. Thanks to its extensive specification and its many different fea-tures, DDS is well suited for a lot of applications. However, a more precisely customized version is always needed for production use due to limited resources.

Above all, MQTT impresses with its simplicity and low re-source requirements. The protocol is designed for trans-mitting small amounts of data over unreliable communi-cation channels, and it is well suited for transferring small amounts of data to the backend. Currently, however, sev-eral questions need to be answered for its use in vehicle communications. In particular, there are questions about functionally safe design of the central broker and its scal-ability. For in-vehicle applications, the future will show whether DDS can make in-roads as an automotive new-comer in competition with the established SOME/IP. Deci-sive factors will be the scope of functionality that is con-sidered essential and which middleware solution offers the best cost-benefit ratio for the majority of Ethernet ECUs.

Originally published in “Elektronik automotive” magazineIssue 3/2020 – March 2020