Redefining Automotive Software Development

As the automotive industry moves to the software-defined vehicle (SDV), it needs to catch up to  other industry best practices in terms of software development productivity, quality, and time-to-market.. 

What caused the lag? Historically, vehicles were a complex system of sophisticated hardware with added software to control their few electronic components. For many years, whenever new capabilities and functions needed to be added, the solution was to add another ECU with the necessary software. 

Today’s consumer demands for customization, personalization, comfort, and autonomy require an overhaul to the development and deployment processes of software.

Developing Automotive Software Today

Currently, E/E architects will design automotive software 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. This system has complex,  hard-coded interfaces which are pre-defined during the conceptual phase. The lack of modularity does not allow changing SWC without complete integration (re)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. With numerous suppliers, each with it’s own sizable team of engineers, that need to check the code, troubleshoot bug fixes, and coordinate across teams and organizations , the entire process ends up being extremely complex, time consuming and costly.

With vehicle customization becoming a more common feature, virtually every car on the production line is different. This requires many different SW configurations that are flashed into the electronic components towards the end of the manufacturing process. But 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, Service-Oriented Architectures (SOA) were introduced and popularized the late 1990s and early 2000s. SOA allows the decoupling of services from the underlying hardware and network infrastructure. Services are implemented as individual SWCs and communicate 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 transport middleware implementations such as 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 new service is added by the following process:

1. 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). 
2. A tool then creates descriptions and code templates for each service. This description is called a manifest. 
3. 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. 
4. 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 a SWC has bugs it can be corrected and rebuilt without impacting any other SWC.

The SOA Framework creates a uniform SW environment where new or updated applications do not have to be tested against all other applications. The end user experience enabled by SOA is analogus to how users interact with their  smartphones or tablets: the user selects an application (or ‘service’), downloads it, installs it and then it’s ready for use. Developers can code functionality logic without knowing or dealing with the hardware platform details, cutting down the time for new applications, new features in the same application, updates, security patches, and more. SOA also allows the concurrent use of multiple operating systems. So, for the infotainment systems OSs like Android can be employed that allow users to download and install arbitrary apps from an app store without affecting any of the other domains.

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.

The automotive industry has already developed a certain degree of service orientation, with the AUTOSAR Adaptive platform. GuardKnox’ Secure SOA Framework supports AUTOSAR Adaptive seamlessly 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 to integrate and test the SW system. This creates dependencies between HW and SW development leading to inefficiencies when some HW components are not be available during the early phase of SW development.

The automotive SOA development approach facilitates simulation of the SW system through a digital twin. With well-defined interfaces of all the services, there is no need to run these on the target hardware and a simulation environment can instead be created to test the interactions of the services on the digital twin. 

However, specific HW components like sensors and actuators still have to be emulated. For certain functions some services may not be required, so they will not be addressed and instead be represented in the services directory, running dummy code.

Benefits of Automotive SOA on The Production Line

As more possible functions become available in a car, the number of different vehicle configurations grows. In the classical approach, this would require an enormous number of different SW configurations to be created and maintained.

Automotive SOA on the other hand, creates the SW configuration automatically during startup of the system. All available services are stored in a repository and listed in the services directory 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 each car model. Modifications to 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’ Secure 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’ Secure 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 where services can be dynamically modified outside the factory or the garage.