Firmware Strategy for the Internet of Cars David Kleidermacher, CTO
Green Hills Software
The Internet of Things (IoT) trend can be defined as the rapid assimilation of the world’s objects (anything that is not already a networked computer such as a PC or smartphone) into the Internet. This transformation is accelerating rapidly due to the availability of ultra low size, weight, power, and cost digital processing and wireless connectivity, and the connected car is taking center stage in this revolution – hence the Internet of Cars (IoC). Within the car, there is likely to be multiple networked components, including telematics units, gateways, infotainment, and ADAS, to name a few.
In this article, we arm both new and experienced automotive systems developers with a firmware strategy to ensure success in the IoC. We define the major layers of the firmware stack, the major goals or focal points of a firmware strategy, and finally high-‐level guidance for these points at each layer.
Firmware Stack
When deciding on a firmware strategy, the following major layers are important:
-‐ Hardware/microprocessor
-‐ Run-‐time executive (real-‐time OS, hypervisor, etc.) -‐ Web messaging infrastructure
Traditionally, firmware is thought of as bootloaders and the operating system kernel. However, it is impossible to develop a quality firmware strategy without making sound hardware decisions. Furthermore, in the IoC, many applications are remotely, rather than locally, hosted. Thus, web-‐messaging infrastructure – the lingua franca of the IoT – must be considered an integral part of firmware strategy. Software applications remain above the firmware layer, regardless of whether they make use of local or web APIs.
Strategic Goals
The following five goals should be included in an IoC firmware strategy:
-‐ Ease of use / learning -‐ Maximal use of standards -‐ Think security
-‐ Design for efficiency -‐ Plan for scalability
asset -‐ your developers -‐ live every day. Do not underestimate the long-‐term impact of an optimized day-‐to-‐day firmware development, testing, and maintenance cycle. Utilizing protocols and architectures compliant to open standards will provide many benefits, from a wider range of available products to a larger pool of experienced developers. The IoC brings profound security and privacy challenges, and developers that fail to consider security in initial concepts and designs may be faced with project or company-‐killing failures later. Scalability is a factor that often goes underappreciated; designers must consider how firmware choices will scale across products within a model year as well as generations of model years to come, in order to protect those investment decisions.
Now let’s dive deeper and apply these focus points across the firmware stack.
Hardware
There are many microprocessor architectures from which to choose in new IoC designs. Prefer those that offer numerous toolset choices. Look for a processor architecture that scales across product families and generations. For example, ARM has offerings in the ultra low power MCU area to ARM/FPGA combos to 64-‐bit cloud server processors.
An important aspect of scalability in hardware selection is support for software/system robustness; as IoC devices grow in complexity, the role of memory management units (MMU), virtual memory, and hardware virtualization support become increasingly important. Again by way of example, the recently announced ARMv8-‐R architecture is the first ever to offer all three in a design aimed at real-‐ time, embedded processing applications.
Run-‐Time Executive
Run-‐time execution platform selection is critical to IoC firmware strategy. The executive is responsible for efficient and secure resource management across the device. There are tons of kernels -‐ CMX, FreeRTOS, uc/OS, MQX, RTXC, T-‐Kernel -‐ just to name a few, that provide similar scheduling, multithreading, and synchronization services upon which one can build basic IoC systems. What practically all of these have in common, however, is the use of proprietary APIs and an inability to take maximum advantage of the aforementioned high-‐end robustness hardware capabilities.
On the other end of the scale is Linux. With its open source licensing and widespread availability of developers, middleware, and applications, Linux has an undeniably important position in the run-‐time strategy for IoC, regardless of flavor (GENIVI, AGL, Android, etc.). However, Linux has problems scaling to lower end designs, real-‐time latency and instant-‐on limitations, and lacks the safety and security pedigree one would like to have in a future-‐proofed IoC strategy.
There is an IoC sweet spot between these two extremes: the microkernel. Monolithic general-‐purpose operating systems, such as Linux, contain system software, such as networking stacks, file systems, and device drivers that share a single memory space and execute in privileged mode. This results in a large footprint and a plethora of robustness challenges, as exhibited by the many vulnerabilities found in smartphones.
Figure 1 - Microkernel vs. monolithic architecture
In contrast, a microkernel runs a minimal set of services and can run on anything from a cheap microcontroller without MMU to the beefy multicore processors we’re now seeing in head units. The microkernel supports lightweight, real-‐time virtual memory processes that provide a scalable, robust environment for IoC developers. Figure 1 depicts the difference between the microkernel and monolith approaches. Most major new operating systems are built with microkernels and run practically every type of electronic product. Examples of microkernel-‐based operating systems include Green Hills’ INTEGRITY and PikeOS.
However, the decision to use a microkernel or Linux need not be mutually exclusive; a sound IoT firmware strategy can leverage the real-‐time, footprint, and robustness advantage of a microkernel as well as the device driver, middleware, and applications availability of Linux. This happy coexistence is enabled with system virtualization. Figure 2 shows virtualization as a service of the microkernel. Examples of microkernel hypervisors include the INTEGRITY Multivisor from Green Hills Software and some variants of the L4 microkernel.
Figure 2 - Microkernel hypervisor architecture for IoC
Web Services Middleware
Including web services middleware in an article about firmware strategy may seem blasphemous, but the IoT is changing how we think about devices. With ubiquitous connectivity into the cloud, remote service calls become the new OS service calls.
RESTful web services are the most popular web middleware approach in resource-‐ constrained environments like cars. Developers can quickly develop RESTful interactions with a simple HTTP client on the device and a web server on the network. Because of its relative simplicity and efficiency, RESTful looks well positioned to become dominant in the IoC.
Figure 3 brings together the entire IoC firmware stack into a single picture, including the concept of multiple securely partitioned web services components, Linux guest operating systems, and real-‐time and security-‐critical native microkernel components.
Figure 3 - a complete IoC firmware stack
We find ourselves in the midst of an exciting time, when the number of objects has recently eclipsed the number of people (PCs, smartphones) on the web. The Internet of Cars has the potential of making our lives better and yielding incredible opportunities for automotive systems developers, especially those that approach their craft with an effective firmware strategy.
Green Hills, the Green Hills logo, MULTI, INTEGRITY, and INTEGRITY Multivisor are trademarks or registered trademarks of Green Hills Software in the U.S. and/or internationally. All other trademarks are the property of their respective owners.
