The FCA Uconnect Global API’s define a standard data communication protocol for the Telematics Unit in the vehicle to interface with the cloud based Service Delivery Platform (SDP). The in-vehicle unit consists of either a Telematics Box Module (TBM) or Head Unit (HU), while the SDP can be hosted in any one of many cloud based infrastructures including Amazon Web Services (AWS).
The primary objective of this API is to create interoperability between the FCA regions including APAC, EMEA, LATAM, and NAFTA which with proper adoption will result in efficiency improvements and cost reductions as platforms become more global. Additionally, the API will improve the FCA Connected Vehicle Platform design for performance, scalability, flexibility, security, maintainability, and cost effectiveness.
The API is based on industry best-practices for the Internet of Things (IoT) including the use of the secure MQTT and HTTP communication protocols. The need to minimize costly wireless network traffic has also lead to the use of Protocol Buffers for efficiently formatting the data into messages between the client (TBM or HU) and the services (SDP).
Additional information about these standards and practices can be found at the addresses listed below
Currently every SDP provider has their own proprietary communication interface with the vehicle. Everyone is essentially sending very similar data and we have a good understanding of the required data elements. Rather than continually adapting the vehicle HU/TBM to interface with different SDP providers, this API provides a common interface which is intended to be leveraged on a global basis.
The API reference implementation utilizes MQTT 3.1.1. However, the protocol message structures can be transferred over other messaging protocols as required.
Here it is.
No, Any compliant MQTT client library can be used. The reference implementation utilized AWS IoT for the availability, admin console, policy configuration, and management of device certificates for mutual authentication.
MQTT defines three levels of Quality of Service (QoS). The QoS defines how hard the broker/client will try to ensure that a message is received. Messages may be sent at any QoS level, and clients may attempt to subscribe to topics at any QoS level.
QoS Level 1 should be used for publishing a message at least once. The MessageId and CorrelationId can be used to implement de-duplication logic as required.
The protocol buffer messaging structure utilizes OneOf which is defined in Proto Language Version 3 and supported in version 3. The Simulator client and service utilize Version 3.3.0 of the compiler or better.
The protocol buffer messaging structure utilizes OneOf which is defined in Proto Language Version 3 and supported in version 3. This specification is based on Protobuf language Version 3 - the compiler is version 3.30 or better
Changing Protocol Buffer Versions comes with inherent risks and shall not be done in vehicle or at the server except with FCA approval and following our change and release control processes
The protocol buffer messaging structure utilizes OneOf which is defined in Version 3 and supported in version 3. This specification is based on Protobuf language Version 3 - the compiler is version 3.30 or better
Modifying the protocol buffer .proto files shall only be done at new service versions and must be modified by FCA Interface Architecture and through the change and release control processes
The protocol buffer messaging structure utilizes OneOf which is defined in Version 3 and supported in version 3. This specification is based on Protobuf language Version 3 - the compiler is version 3.30 or better
Yes. At the discretion of the sender, messages may be compressed using the format described in RFC 1952 with the default DEFLATE compression method. Messages compressed in this way can reliably be distinguished from uncompressed messages by the magic number in the gzip message header. Receivers can assume compression if the first two bytes of a message are [0x1f,0x8b] because no valid protocol buffers wire format message can start with this particular sequence.
The clientId shall be identified by Uconnect Security during the design phase of the solution. The recommended approach is to utilize the CN of the Public Certificate assigned to the TBM/HU device. Either through back-end feeds or during the initial CommCheck, the clientID should be associated with a specific VIN
Before establishing an MQTT connection, a client must have a certificate for mutual authentication in accordance with security specification CS.00165
The Global V2C API includes an interface to allow the TBM/HU to download a X.509 Public Certificate created from an out of band CSR process between the TBM/HU and Global PKI.
The business requirements for the TBM/HU and SDP can be found in the System Function Specification (SFS) documents at the followin link: here
The implementation requirements for the TBM/HU and SDP can be found in the CTS (Component Technical Specification) and CTDD (Component Technical Design Documents) documents at the followin link: here
Given we are not using MQTT QoS 1 there is the potential to receive a duplicate message. The HU/TBM client endpoint shall utilize the messageId to reject any duplicate messages. The SDP service endpoint shall utilize the clientId and messageId to reject any duplicate messages.
As MQTT defines Quality of Service1 (QoS1), if the Quality of Service is set to 1 then the broker/client will deliver the message atleast once and receiver sends an acknowledgment to the sender. and The message is deleted from the sender after it has received an acknowledgment from the receiver.
An undelivered message may be removed after a specification defined timeout period, as would be the case with Remote Operations
The UconnectMessage contains several IDs for the messages, each is used to create traceability throughout the system. i.e determining duplicates can be done using any combination of MessageID and either SessionID or ServiceID.
Messages and their IDs have the following structure
Yes, listed below.
| Nbr | Type | KPI Requirement |
|---|---|---|
| 1 | Request/Response Message from Vehicle to Cloud | 5 sec |
| 2 | Request/Response Message from Cloud to Vehicle | 5 sec |
| 3 | Push Message from Vehicle to Cloud | <3 sec |
| 4 | Push Message from Cloud to Vehicle | <3 sec |
For logging purposes, MQTT packet identifier can be used to find a sender's packets in a receivers's log files. Sender can append the Packet Identifier with the timestamp in the packet.
If its KPI for Round trip , Message ID/CorrelationId with other information can be used for Logging.
Establishing and passing a session id for every message is the best practice for the purposes of auditing and analytics, as well as correlating multi-point and multi-channel feature messages (i.e. Ecall)
For Hight Priority messages an SMS will be sent to wake the vehicle. For all messages with a prescribed KPI or performance target, the message time to live should be less than the performance target. This should be defined in a requirements document give by the specific feature team
{{{file_description}}}{{/p}}{{/file_description}}
{{#file_messages}}
| Field | Type | Label | Description |
| {{field_name}} | {{field_long_type}} | {{field_label}} | {{#p}}{{field_description}}{{#field_default_value}} Default: {{field_default_value}}{{/field_default_value}}{{/p}} |
| Name | Number | Description |
| {{value_name}} | {{value_number}} | {{#p}}{{value_description}}{{/p}} |
| Extension | Type | Base | Number | Description |
| {{extension_name}} | {{extension_long_type}} | {{extension_containing_long_type}} | {{extension_number}} | {{#p}}{{extension_description}}{{#extension_default_value}} Default: {{extension_default_value}}{{/extension_default_value}}{{/p}} |
| Method Name | Request Type | Response Type | Description |
| {{method_name}} | {{method_request_long_type}} | {{method_response_long_type}} | {{#p}}{{method_description}}{{/p}} |
| .proto Type | Notes | C++ Type | Java Type | Python Type |
| double | double | double | float | |
| float | float | float | float | |
| int32 | Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint32 instead. | int32 | int | int |
| int64 | Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint64 instead. | int64 | long | int/long |
| uint32 | Uses variable-length encoding. | uint32 | int | int/long |
| uint64 | Uses variable-length encoding. | uint64 | long | int/long |
| sint32 | Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int32s. | int32 | int | int |
| sint64 | Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int64s. | int64 | long | int/long |
| fixed32 | Always four bytes. More efficient than uint32 if values are often greater than 2^28. | uint32 | int | int |
| fixed64 | Always eight bytes. More efficient than uint64 if values are often greater than 2^56. | uint64 | long | int/long |
| sfixed32 | Always four bytes. | int32 | int | int |
| sfixed64 | Always eight bytes. | int64 | long | int/long |
| bool | bool | boolean | boolean | |
| string | A string must always contain UTF-8 encoded or 7-bit ASCII text. | string | String | str/unicode |
| bytes | May contain any arbitrary sequence of bytes. | string | ByteString | str |