Hardware/microprocessor Run- time executive (real- time OS, hypervisor, etc.) Web messaging infrastructure

Size: px

Start display at page:

Download "Hardware/microprocessor Run- time executive (realtime OS, hypervisor, etc.) Web messaging infrastructure"

Gilbert Hubbard
8 years ago
Views:

1 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 highlevel guidance for these points at each layer. Firmware Stack When deciding on a firmware strategy, the following major layers are important: Hardware/microprocessor Runtime executive (realtime 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, webmessaging 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 Try to select products, protocols, and architectures that are easy for novice developers to learn and use. Firmware is the environment in which your biggest

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

2 asset your developers live every day. Do not underestimate the longterm impact of an optimized daytoday 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 companykilling 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 64bit 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 ARMv8R architecture is the first ever to offer all three in a design aimed at realtime, embedded processing applications. RunTime Executive Runtime 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, TKernel 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 highend 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 runtime strategy for IoC, regardless of flavor (GENIVI, AGL, Android, etc.). However, Linux has problems scaling to lower end designs, realtime latency and instanton limitations, and lacks the safety and security pedigree one would like to have in a futureproofed IoC strategy.

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 companykilling failures later.

3 There is an IoC sweet spot between these two extremes: the microkernel. Monolithic generalpurpose 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, realtime 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 microkernelbased 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 realtime, 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.

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.

4 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 realtime and securitycritical native microkernel components.

RESTful web services are the most popular web middleware approach in resource constrained environments like cars.

5 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.

The Internet of Cars has the potential of making our lives better and yielding incredible opportunities for automotive systems developers, especially those that

Mentor Embedded IVI Solutions

Mentor Embedded IVI Solutions Infotainment Instrument Cluster Andrew Patterson andrew_patterson@mentor.com Business Development Director Automotive Embedded Software mentor.com/embedded Android is a trademark