Redefining Automotive Software Development

The automotive industry is lagging behind tech industries in terms of productivity, quality, time-to-market, and turn-around times. This is a result of the century-old automotive supply chain and the way software development has evolved in this industry. 

Whereas historically, cars have been complex systems of sophisticated hardware with software being a necessary evil to control their few electronic components, today they are rapidly becoming Software-Defined Vehicles (SDV) with sophisticated driver assistance systems, advanced In-vehicle Infotainment (IVI), driver-oriented applications and transitioning to autonomous driving.

For a SDV to truly evolve, capabilities and functions must be added in SW form as opposed to the traditional automotive way of adding ECUs to support new features. 

In order to answer today’s needs for customization, comfort and autonomy, the processes for development and deployment of software have to change dramatically.

Developing Automotive Software Today

Today’s automotive software is designed by architects with a focus on the immediate needs of a certain car platform or model. All the software components (SWCs) on various Electronic Control Units (ECUs), domain controllers and central controllers form a monolithic system with complex interfaces that are hard-coded and pre-defined during the conceptual phase. The lack of modularity does not allow changing any SWC without complete integration testing of the entire system.

The OEM’s architects provide the interface specifications for hardware and software components to their suppliers. The overall integration is then performed either by the OEM or the supplier. Every new component has to be checked against the entire system. The number of suppliers usually is very large, so the entire process is extremely complex, time consuming and costly.

With today’s possibilities to customize new cars, virtually every car on the production line is different. This is reflected by many different SW configurations that have to be flashed into the electronic components towards the end of the manufacturing process. Creating and maintaining these configurations is a complex and error-prone process which frequently requires human intervention.

The lack of software modularity also causes major problems with testing and debugging. Every large SW system inevitably contains some residual bugs whose number grows with the complexity of the overall system. Fixing SW bugs after a car has left the factory requires a recall to the garage to re-flash the system. There is currently no way individual SWCs could be safely replaced over the air (OTA) without a physical visit to the shop.

Developing Software on The Basis of Automotive SOA

In the enterprise computing industry, the Service-Oriented Architecture (SOA) was successfully introduced a long time ago. SOA allows the decoupling of services from the underlying hardware and network infrastructure. Services are implemented as individual SWCs. The communication among SWCs occurs through well-defined standard interfaces across the Enterprise Service Bus (ESB), an abstract communication infrastructure interconnecting all required SWCs. The framework supports multiple ESBs concurrently, and it can accommodate middleware implementations based on CORBA, DDS and others.

Services and their descriptions are listed in a directory so that every service can find the required other services and the parameters to use them.

Introducing the SOA approach in the automotive industry enables an unprecedented degree of flexibility. Services can be implemented and tested independently. Any change in a service implementation does not require renewed integration and testing of the entire software system as long as its interfaces do not change.

With Automotive SOA a SW architect defines the services and the parameters to be exchanged through the standard interfaces using the language OMG IDL (Interface Definition Language defined by the Object Management Group). A tool then creates descriptions and code templates for each service. This description is called a manifest. The developer of a certain service takes the manifest and fills it with the SWC, i.e., the code representing the logic of the service, like reading a sensor, processing input values, invoking an actuator, transmitting information or alerts, etc. The resulting SWC is then fed into the code repository and made available to other services through the service directory. Since the interfaces of the SWCs have been created automatically by the toolchain, the communication with other services is guaranteed. If during integration tests an SWC shows bugs it can be corrected and rebuilt without impacting any other SWC.

The SOA Framework creates a uniform SW environment, similar to today’s common PC or mobile platforms where new or updated applications do not have to be tested against all other applications. With our smartphones or tablets we simply download an app, install it and use it, and developers can code functionality logic without knowing or dealing with the hardware platform details. As the SOA technology also allows the concurrent use of multiple operating systems, for the infotainment systems OSs like Android can be employed that allow users to download and install arbitrary apps from an app store.

Click image to enlarge

This complexity reduction will lead to significant cost reductions, e.g., reducing the number of testers, and to a significant acceleration of correction cycles, down from several months to just a few weeks, improving time to market.

A certain degree of service orientation has already been developed by the automotive industry, with the AUTOSAR Adaptive platform. GuardKnox’ Secure SOA Framework supports AUTOSAR Adaptive seamlessly in order to allow automakers the reuse of the large amount of existing software.

Simulating Deployment Scenarios

In the classical SW development scenario prototypes or mock-ups of the HW environment are required in order to integrate and test the SW system. This creates dependencies between HW and SW development which cause inefficiencies as some HW components may not be available during an early phase of SW development.

The automotive SOA development approach facilitates simulation of the SW system. With well-defined interfaces of all the services there is no need to run these on the target platform. Instead, a simulation environment can be created that allows testing the interactions of the services. Specific HW components like sensors and actuators have to be emulated. For certain functions some services may not be required, so they will not be addressed by the other services, although they might already be represented in the services directory, running some dummy code.

Benefits of Automotive SOA on The Production Line

With more and more possible functions available in a car the number of different vehicle configurations will grow. In the classical approach this would require more and more different SW configurations to be created and maintained.

Automotive SOA creates the SW configuration automatically during startup of the system. All available services are stored in a repository and they are listed in the services directory from where they can be discovered by other services. The binding between services occurs dynamically. Thus, there is only a single SW load to be created and maintained for a certain car model. Modifications of any service implementation can be introduced into the manufacturing process on the fly. They can even be sent securely over the air after the car has left the production line.

Summary

GuardKnox’ Automotive SOA Framework supports the development and deployment of automotive SW starting with the initial specification of the SW system in IDL, continuing with the distributed development of SWCs, integration, simulation, testing, all the way down to the deployment on the production line and beyond. It also enables the implementation of new features by making services available over the air, by the automaker or from app stores, after a car has left the manufacturing plant.

GuardKnox’ SOA Framework is a unique approach that not only facilitates the development and deployment of automotive SW but has built-in security mechanisms which are a fundamental prerequisite for vehicle safety in a SW environment that allows the modification of services dynamically outside the factory or the garage.