Overcoming the industry’s bottle-necks in automotive software development, maintenance and deployment

It’s a known fact that the software system in today’s vehicle covers a distributed system of 100 to 150 Electronic Control Units (ECUs) that control virtually every aspect of a car’s functionality from power brakes to seat alignment. Does this make sense?

These ECUs use networks based on a variety of transmission technologies like CAN, LIN, MOST, FlexRay and Ethernet. Each ECU has its own microprocessor (MPU) or microcontroller (MCU) running software (SW) or firmware (FW) created by its manufacturer. To support the variety of transmission technologies some gateway functionalities must be included. 

An automaker integrates all the different software packages, including some home-brewed software to create a SW system for a particular model of vehicle. Every change in any ECU requires regression testing of the entire package. In the future, the ECUs will need to support various customizations built for individual car models and/or customers that would require tedious regression testing of each variant.

The problems with software in the automotive industry

It doesn’t end there, though. Every application has to be aware of all the sensors and actuators it must communicate with, and how to reach them.  The number of sensors and actuators in the connected and autonomous vehicle will grow substantially, directly increasing requirements for the number and performance capabilities of the ECUs, as well as leading to significant security demands.

In today’s automotive software development environment the SW system for a particular model can be considered as a monolithic block of code that is built and tested by the automaker and loaded (flashed) into the various ECUs at the end of the manufacturing process. Every change of functionality requires re-integration, re-testing and re-flashing of the entire system - resulting in an extremely tedious as well as costly process.

Due to this complexity, the development of a feature update generally requires 3-6 months with all the associated cost (including but not limited to man hours, quality assurance, verification and validation, etc.)  while the market is aiming to target a cost-optimizing 2-4 week turnaround.

With this much testing required, customizing the system to specific customer desires is virtually impossible. Software updates or after-market enhancements are very complex and have to be deployed by authorized dealerships and are typically done with a visit to the shop instead of Over The Air (OTA).

The awareness of every relevant sensor and actor by a particular application is very complex and error-prone. To a certain degree the AUTOSAR Platform provides an abstraction of these interfaces, mapping them to ports that hide the hardware characteristics.

Applications need to be able to talk to one another. For example, an application performing the communication to the environment (V2X) has to be able to trigger an action by an application controlling the brakes or the steering. This communication has to occur through well-defined interfaces that meet strict performance and security standards. Nevertheless, these ports need to be determined up front.

Comparing automotive software to other industries

Modern computing platforms are able to run any application that has been implemented using the specific APIs of the Operating System (OS). For example, any app a customer/user can get from Google’s Play Store will run on any Android smartphone. There is no need for regression testing this app with every existing or planned Android smartphone, nor with every other app to check whether there are any side effects. The only restriction may be a certain OS release because older releases may not offer the OS functionality required by the app.

The development of a feature update generally requires 3-6 months with all the associated cost... while the market is aiming to target a cost-optimizing 2-4 week turnaround.

In today’s automotive SW environment working with a complex network of ECUs, such an approach is unfortunately not feasible. To meet customer desires, vehicles need a new approach that allows applications to run on top of a network of computing platforms with different characteristics, without a need for each application to be aware of the network.

Solutions to the automotive software problems

For automotive SW development, we require an approach that:

1. Hides the complexity of the hardware with all the sensors and actuators below an abstraction level and allows applications to find them in a directory instead of programming their interfaces into the code base.
2. Allows applications to run on any computing platform / ECU that has the necessary performance characteristics. The distribution of applications to ECUs does not have to be pre-determined during the design phase. If additional or more demanding applications are required, further ECUs can be added or existing ECUs can be replaced with higher performance models during the lifetime of the car. This is very much like replacing an outdated PC with a higher performance model, or replacing/upgrading certain components, e.g., CPU, GPU, RAM, etc., but still running the same applications.
3. Consolidates multiple application-specific ECUs into fewer higher-performance generic ECUs that act as computing platforms, thus reducing overall cost and complexity.
4. Allows to update/upgrade the SW during the lifetime of the vehicle, either by an authorized dealership or a third party, over a wired connection or OTA, using WLAN or mobile radio.
5. Provides the necessary level of security for every communication inside and outside of the vehicle, and for every installation of an application.
6. Functions inside a vehicle, be they low-level hardware functions, or high-level applications, have to be considered as services offered by certain devices or applications and used by others. Services can be combined to provide a required function, feature or capability..

Communication among services occurs through a level of SW with well-defined interfaces where the services are advertised in a common directory. This level of SW is known as middleware and supports the abstraction from the specific HW environment. A service can be provided by any ECU with the required characteristics, and its location can be changed, depending on the requirements of the computing environment. Services are tested against a reference environment, and if services are added or modified they do not need to be tested against the entire system at large. This greatly simplifies SW development and testing and provides the basis for a truly distributed development environment that can also involve third parties.

What is Automotive SOA?

An Automotive Service-Oriented Architecture (Automotive SOA) is a blueprint for the development and maintenance of the typical distributed SW systems found in automotive environments. It is based on the idea of a service as a discrete unit of functionality that can be accessed remotely and used and modified independently.

Automotive SOA is an evolution of the SOA concept that has been successfully introduced for commercial distributed SW environments.

A service has four properties:

1. It logically represents a repeatable activity with a specified outcome.
2. It is self-contained.
3. It is a black box for its consumers, meaning the consumer does not have to be aware of the service's inner workings.
4. It may be composed of other services.

Each SOA building block can play any of the three roles:

1. Service provider: It creates a service and provides its information to the service registry.
2. Service broker, service registry or service repository: Its main functionality is to make the information regarding the service available to any potential requester.
3. Service requester/consumer: It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its services.

Figure 1: SOA building blocks and their relationships

An example for the specification of an object / service-oriented middleware is CORBA (Common Object Request Broker Architecture). Its core is the Object Request Broker (ORB) and an Interface Definition Language (IDL) for the interface definition between objects/services and the middleware.

Communication among services is provided by an Enterprise Service Bus (ESB), a virtual bus structure interconnecting all the services.

AUTOSAR Adaptive

While AUTOSAR Classic only supports some abstraction of internal interfaces, AUTOSAR Adaptive is an attempt by the automotive industry to introduce a service-oriented architecture.

Its core is an operating system based on the POSIX standard. The operating system can be used by the application via a subset of POSIX. The communication protocol used for the in-vehicle networking using the Adaptive Platform is SOME/IP on top of Ethernet.

Two types of interfaces are available: services and application programming interfaces (APIs). The platform consists of functional clusters which are grouped into services and the AUTOSAR Adaptive Platform foundation.

Adaptive Platform services include:

• Update and Configuration management
• State Management
• Network Management
• Diagnostics

The AUTOSAR Adaptive Platform contains both specification and code. In comparison to the Classic Platform, AUTOSAR develops an implementation to shorten the validation cycle and illustrate the underlying concepts. This implementation is available to all AUTOSAR partners.

GuardKnox’s patented automotive SOA Framework to automotive software development

Recognizing the requirements and trends for SW development in the automotive industry as it transitions to next-generation E/E architectures such as Zonal Architecture, GuardKnox has developed a framework of a number of components, acting as middleware between the basis software (OS) and applications which provide or consume services. This framework allows maximum modularity of individual software components (SWC) which are dynamically managed, and thus, decouple the SWCs from the runtime environment and HW.

The SOA framework serves as a baseline for features, capabilities and functionalities, and the solution is adapted for specific customer requirements and target environments. It consists of generic components and customized solutions. The delineation of which elements will be generic or customized depends very much on the target solution tailored to the customer needs. The framework’s toolchain allows system architects to utilize multiple pre-existing components and automatically create hypervisor configurations and partition images using a graphical interface. With this approach automakers can hit the 2-4 week time to market for SW updates and upgrades; a vast improvement from the current 6 month norm.

Glossary