Software architecture and processes are key challenges for the development and deployment of advanced customizable automotive software today. With the current complex distributed system comprising more than 100 Electronic Control Units (ECUs) per vehicle, the vehicle software system forms a monolithic block of code that is very complicated to maintain and modify.
Currently, there is no support for the standard computing environments that would allow the automaker, and later an owner or driver to easily install apps to the vehicle. Even if this support would exist, including a library of available apps, the current security mechanisms in the automotive software would not allow for sufficient isolation of these apps to prevent them from being used as stepping stones to penetrate safety-critical systems of the vehicle.
Growth of functionalities, with the goal of fully autonomous vehicles, will only make the problem worse.
In a Service-Oriented Architecture, communication among services occurs through a level of SW with well-defined interfaces, known as middleware. Middleware supports the abstraction from the specific HW environment and greatly simplifies SW development and testing. It provides the basis for a truly distributed development environment that can and will involve third parties.
Automotive SOA takes the fundamental SOA concept of service providers and service consumers and translates them to the automotive software environment. Every ECU uses layers of abstraction to hide the complexities of network topology, communication, and implementation. Interactions between software components are therefore no longer hard-coded. Every new service is represented in a directory from where its functions can be offered and where it can find the services that it needs to use. Binding between services is not fixed and can be changed dynamically.
Multiple different operating systems can run in parallel on each ECU, supported by a hypervisor: popular OSs like Windows, MacOS, iOS, Android, etc. can be supported to enable the installation of standard applications and 3rd party apps.
While downloading malicious or buggy apps to a smartphone may impact the function of the smartphone or the privacy of the user, downloading such inappropriate apps into a car can impact driving safety and have fatal consequences.
Therefore, communication between services is restricted to mandatory interactions. Everything else is blocked. Highly secure OTA download and deployment of SWCs prevents any malicious or accidental attack vectors from impacting the safety of the car.
Automotive SW development is a complex work-split between the OEM and a large number of suppliers, with each player providing ECUs with their specific SW or Firmware (FW) implementations. This entire set of HW and SW needs to be integrated and tested to build the overall vehicle system. The lack of modularity makes any modifications to the SW system a complex and slow task which requires re-building and re-testing, resulting in today’s lengthy time to market.
Automotive SOA enables an unprecedented degree of modularity where services can be independently implemented and tested already during the development stage.
This complexity reduction will lead to significantly decreased development costs and much quicker integration cycles. Fewer errors will be created and according to industry estimates, the number of testers will decrease from several hundreds to less than 100. This will result in a significant acceleration of correction cycles, reducing them from several months to just a few weeks.
Automotive SOA is based on well-defined abstract interfaces between all the services. This makes the implementation independent of any particular computing platform and allows the creation of a simulation environment that supports SW integrating and testing instead of the target platform.
The SW configuration of each car is dynamically created at startup of the system. Therefore, for any car model, all available services are stored in a repository and published in the directory. The binding of the services is dynamic and can change according to local HW and SW modifications. The services themselves can be modified on the fly during the manufacturing process on the production line or even after the car has left the factory.
The work-split between OEM and suppliers will be redefined: the main responsibility of the OEM remains defining the architecture, and the creation of the framework by extension, while the service implementations can be performed by any suitable party.
3rd party application developers, who may not be part of the classical automotive ecosystem, can create new services for the vehicle without in-depth knowledge of the HW configuration. Opening the app market to new entrants will increase competition and improve capabilities and expand applications supply instead of relying on a limited number of OEM or pre-defined developers. Consumers will be able to enjoy an experience in their vehicle similar to their smartphone with this broadened developer market.
Today’s drivers can instantly and independently customize their computers, smartphones and tablets to their needs. They are starting to expect the same from their cars and this is leading to the trend of vehicle smartphonization. Drivers want the ability to add new functions (i.e. ADAS functions, games, videoconferencing SW). While the physical infrastructure to provide greater interactivity and communication are available in any modern car, the SW architecture of today’s vehicles usually cannot support much beyond specific predefined use cases decided by the OEM or Tier 1.
With the emergence of autonomous vehicles, requirements for car customization will grow. Their interior will more likely resemble a living room or home office in place of the driving-focused experience we have today. Evolving demands means that audio and video-based entertainment functions, video conferencing and professional workstation features will require support via high-speed wireless external communication.
Nowadays, the majority of cars are shared only amongst family and perhaps friends, but this is already changing with the advent of commercial car sharing. This will become only more popular with autonomous vehicles and shared cars. Cars will need to meet the preferences of any user, whether they will want to be entertained while commuting or work or rest while they travel. Cars will be instantly customized by portable digital identities as soon as a particular user logs their profile into the car.
An unfortunate reality of software development is that software in any computing environment can always contain bugs. The number of residual bugs grows as the size of the SW packages increases. We have grown accustomed to regular software updates to patch fixes and add new functionality in our everyday environments and devices, but not in our cars.
If a bug is severe enough to impact driving or functional safety, automakers have traditionally initiated a very expensive and reputation-impacting recall program to fix the software in an authorized garage – usually only as a last resort.
The standard Over-the-Air (OTA) updates approach used in our smartphones and computers is not available in a vehicle as it could be utilized as an entrance to safety critical functionalities. However, with Automotive SOA, the safety critical applications are securely separated in partitions and a unique framework prevents malicious code from spreading through the vehicle. Secure OTA updates will provide software updates from any location as soon as a new release is available.
