Understanding Connected Vehicle Architecture for Automotive OTA

We live in exciting times as we witness the transformation of entire industries unfold before our eyes resulting from the explosive growth of connected things and the advent of 5G networks. From consumer products such as appliances, toys or lawnmowers to industrial equipment, medical devices, cities and our vehicles - if something is not connected now, it's only a matter of time. With any connected device or machine, comes the need for ongoing software updates and data collection to ensure optimal service, improve future product design and upgrade features overtime.

Connectivity in the automotive and mobility industry however is uniquely different. The connected car, while not a new concept, has and largely still remains limited to one-way, linear applications (e.g. the SOS button or refreshing infotainment apps or maps). As autonomous driving, electrification, mobility-as-a-service, micro-mobility and other transportation trends evolve, we at Sibros are seeing a tremendous uptick in the demand for advanced connectivity capabilities that must support all vehicle types, spanning typical passenger cars as well as commercial trucks, buses, e-scooters, e-bikes, recreational vehicles and more.
‍
Enter full vehicle Over-the-Air (OTA) software updates with data logging. With the proper architecture in place these capabilities can be achieved in a single system to ensure vehicles are always updated while providing a vital closed feedback loop to manufacturers for every ECU, sensor and sub-component in the vehicle. However, not all architectures are created equal for this purpose. With workload intensive requirements for comprehensive communication with every ECU while minimizing downtime, choosing the right architecture can be a make or break decision for an advanced OTA system that can support a deeply connected vehicle platform. 

POSIX Architecture‍

A "POSIX Architecture" implies a Linux, QNX or equivalent operating system that has OS provided services for file system, and networking through BSD sockets API. This architecture generally has applications in electric cars and buses, and vehicles with infotainment UI screens. 

Typically, this system would contain tens of megabytes of RAM, and a GHz scale processor such as a 1GHz ARM processor. With a POSIX architecture, networking stack or TLS security stack are provided by the OS, making writing software applications on top of this POSIX OS much more simplified.

In this architecture, the POSIX operating system provides access to the Internet (with on-board LTE modem and Wifi), and is also connected to any downstream controllers directly through CAN or another high speed CAN gateway.

In figure 1A, the POSIX system is directly interfaced to other ECUs, so the OTA software update stack or the vehicle data logging stack can run directly on this system. In figure 1B, a CAN gateway is connected to the POSIX system, and still facilitates the updater and logging stack easily. Even if the CAN gateway is interfaced to multiple CAN buses (such as 5x at 1Mbps), 100Mbps ethernet interface would be fast enough to accommodate the CAN gateway.

A typical POSIX system contains ample amounts of RAM and on-board storage to store and uncompress firmware update artifacts which are then transferred to the downstream controllers.

‍

Example Hardware:

• NXP S32G
• 1GHz ARM with 1 Gigabytes of RAM
• Built-in CAN peripherals or CAN bus access through a CAN Gateway through Ethernet backbone
  

Benefits:

• Security is easier to implement on a POSIX system (TLS managed by the OS)
• Applications are easier to develop with standard interface to network stack (BSD sockets)
• If one application crashes (such as infotainment), it will not affect the ability to provide future bug fixes through OTA updates

Microcontroller Architecture

In this architecture, a microcontroller running an RTOS (such as FreeRTOS) is connected to the Internet via a modem. The applications for this architecture are most commonly scooters or 2 wheelers, or cost sensitive IoT devices. 

This architecture has its advantages, such as optimized power consumption, lower hardware cost, and faster bootup when compared to a POSIX operating system. It is also cost effective because it does not require a POSIX operating system. 

However, there is a hidden cost of supporting a microcontroller that may need to run a complex software stack. Integrating a TLS library on a microcontroller requires a measurable amount of software integration effort, whereas in a Linux-like environment, such a facility is provided in the operating system itself. Also, interface to the modem is non-standard, requiring additional engineering effort, limiting the interface and making supporting multiple IP connections difficult. 

CPU computing power is usually not a limitation with this architecture, but in order to comfortably support on-board TLS security, data logging, and firmware update stack, a minimum of 128K of RAM is highly recommended. External flash storage of 2 megabytes is recommended assuming modest requirement of supporting OTA update of 2 controllers with 512K hex file size.

Example Hardware:

• ARM Cortex (M0,M3,M4 etc.)
• Minimum 128K RAM, 512K ROM
• External interface to at least 2 Megabytes of flash
  

Benefits:

• Cost effective solution (Hardware cost is cheap, and RTOS like FreeRTOS also free)
• Lower power consumption, and the hardware can be in ON/Active state to provide quick power-up operation to the end user (such as customer opening a car door)
  
  

Architectures Not Recommended

In architecture 1A, there is a bottleneck in the system because multiple CAN buses are designed to be gated through another CAN bus. In such a system, if there are heavily loaded CAN buses, then squeezing all of their traffic through another CAN bus is not feasible. Excessive software development would be needed in order to prevent the bottleneck, and the system could still result in compromises.

In architecture 1B, a modem is connected to a microcontroller with limited amount of RAM. It would be extremely difficult to run any form of data logging and firmware upgrade stack with limited amounts of RAM. A typical RAM requirement is 20K of RAM for data logging and software upgrade stack, and with this limit of 36K of RAM, there is little RAM to run the rest of the customer application. Another issue that arises with storage constraints is the lack of ability to secure the hardware from internet attacks. Adding TLS to a microcontroller would require at least 20 kilobytes of RAM, and it is recommended to have at least 128 KB of ram on the microcontroller to account for TLS security, Updater stack, Logging stack, and customer applications.

A second challenge in architecture 1B, is that it does not have any non-volatile storage to be able to store the firmware update artifacts (hex files of other controllers). In order to perform security and signature verification, the entire image would need to be downloaded to a storage medium.  

In summary storage, performance, cost, and security are among just some of the key attributes to consider when selecting a connected vehicle platform architecture. Specifically for automotive OTA, these are high stakes decisions as they have significant impact upon vehicle performance, product experience and safety critical factors. As we continue to see rapidly evolving transportation trends come to mass appeal, it's important to understand and select the right connected vehicle architecture that can scale across fleets, geographies and the end-to-end vehicle lifecycle.