[Background] During the discussion of a control command, we proposed to use the SOME/IP protocol, but the other party suddenly suggested using the MQTT protocol for transmission. This proposal was something we had not encountered before, which left us a bit confused. Therefore, classmate Jiahui conducted an investigation and comparison of the two protocols and shared the findings for university learning and understanding.
[Comparison]
|
MQTT |
SOME/IP |
|
|
Principle |
The MQTT protocol is a message queuing transmission protocol that uses a publish/subscribe mechanism. Subscribers only receive the data they have subscribed to, while non-subscribed data is not received. Message delivery is done through a broker, and sessions are established between the client and the broker. The broker can also handle retained messages for publishers and can change the Quality of Service (QoS) level. |
SOME/IP is a protocol developed specifically for automotive use, based on IP protocol, and is a service-oriented extensible communication middleware protocol. Service providers and subscribers are directly related to each other without a central broker. Data and functions are encapsulated as services based on a service-oriented communication paradigm, using methods, events, and fields in the service interface description. |
 |
|
|
|
Differences |
|
|
|
Usage Scenarios |
Mainly used for vehicle-to-cloud communication, providing data transmission and monitoring for remote devices based on cloud platforms, suitable for low bandwidth and unreliable network scenarios, such as simple functionality and limited hardware resources in the low-speed vehicle domain. |
Mainly applied to in-vehicle communication in the automotive network and can only be used in IP-based network environments. |
|
Advantages |
|
1. Flexible and extensible: The SOME/IP protocol supports various service types and message types and can meet different communication needs by extending services and message types. 2. Can be deployed on AUTOSAR Adaptive and Classic platforms, allowing seamless integration within AUTOSAR. 3. Functional safety design benefits from being incorporated into AUTOSAR standards, allowing for standardized descriptions. |
|
Disadvantages |
1. The scalability of MQTT is relatively poor. 2. Delays can increase disproportionately with the number of topics that need to be managed, making the use of MQTT more challenging in certain applications. 3. Currently, MQTT has not been used in AUTOSAR AP and CP platforms. 4. Issues regarding the functional safety design and scalability of the central broker remain to be resolved. |
1. High resource demands. 2. SOME/IP does not define a standard API (Application Programming Interface); implementations typically provide a C++ API, and applications based on different SOME/IP implementations are generally not portable to each other. 3. The current SOME/IP protocol does not provide any security measures; security depends on the transmission protocol. |
[Additional Information]: Implementing an MQTT Client on an ECU running Autosar indeed poses certain challenges, making it relatively difficult to implement. However, for non-AUTOSAR ECUs, introducing an MQTT Client is relatively straightforward. As for whether these ECUs can be used as a Broker, it is still uncertain. In practical applications, MQTT is mainly used for communication between clients and the cloud. This communication method is particularly suitable for in-vehicle systems and may require transforming cloud messages into in-vehicle SOA (Service-Oriented Architecture) messages to meet common needs such as remote control, remote upgrades, and big data collection. Through this transformation, the application of the MQTT protocol in in-vehicle systems can be utilized more effectively, achieving more efficient and convenient vehicle communication and data management.