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).
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.
The protocol buffer messaging structure utilizes extensions which is defined in version 2 and supported in version 3. The reference client and service utilize version 2.6.1 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. One implementation approach is to utilize the CN of the Public Certificate assigned to the TBM/HU device.
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 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. Uconnect Security will provide the specification for the required interactions by the TBM/HU and SDP for the CSR process.
The implementation requirements for the TBM/HU and SDP can be found in the System Function Specification (SFS) documents at the followin link: here
Given we are not using MQTT QoS 2 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.
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.
For eg: If we need to send 2 messages (Vehicle Sync and provisioning Push)in one Uconnect message then you need 2 signature messages one for each which has its own messageId in the signature.
Steps for Downloading and activating AWS IOT Device Certificate can be found here
Example to show how to use KeyStore Credentials using AWS IOT Certificate
{{{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}} |
Here are some code samples to demonstrate how to create, send and receive messages. This tutorial shows how to
Start with .proto file. Add required messages and elements to each message.
Download Protobuf Compiler here and run the following command.
which then generates java file in package that you specified in .proto.
| .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 |