In the last century vehicles and the related mobility defined the speed of many economies. Besides carrying people and goods, they have been seen as status-symbols. This will change. Parallel to the definition of e.g. SAE J3016, the level of highly automated vehicles (HAVs) in 2014, the automotive story has been redefined – compare the Tesla success story. Either driving assistant systems (ADAS) or automated driving (AD), the driver will lose charge of vehicle control. The control is taken over by (autonomous acting) software, not spending emotional thoughts on vehicle attributes. For occupants it’s a question of convenience and safety.
As a matter of fact, electric-electrical (E/E) architectures will dramatically lose complexity as well as hardware and software will have separated development and release cycles. A good analogy is what happened with the introduction of the IPhone and Android phones. Before introducing them, hardware and software were tightly coupled. Afterwards software was decoupled and defined how the hardware is facilitated. Let’s have a look at Android over 10 years in the past. Android was introduced in November 2007 with version 1.0. In September 2009 the version 1.6 introduced the support for CDMA-based networks, allowing it to be sold by all carriers around the world. Today’s engine-control-units (ECUs) orchestration serve a specific purpose, as an at design phase well defined interaction to other ECUs. In the near future ECUs will interact according to multiple, changing, varying demands and purposes. Smartened sensors and actuators as well as extended system scopes, e.g. the chassis-system at all, will become more attractive. Software on top, including functionalities such as over-the-air (OTA) updates, will become the dynamic binding element. May the first step in this consolidation was the introduction of connectivity-control-units (CCUs). CCUs host personal-computer (PC) grade software, often bridge in- with off-vehicle functionality.
While this vehicle architecture consolidations, the evolving software requires virtualization. One concept supporting these necessary consolidations, through virtualization software layers, is called software-defined-architecture (SDA). SDA serves a massive number of increasing business demands while adapting to the rapidly changing E/E architecture. For example in today’s E/E architectures up to 18+ controller-area-network (CAN) signals represent the vehicle speed. The application software just requires e.g. the vehicle speed information, may with specific quality of service constraints. It is not important which of these 18+ CAN signals serve the informational demand. If the application software does not have to take care of the specifically consumed signal, more business solution aspects could be more flexible taken into account. Same already happened at the large cloud services with their application-program-interface (API) virtualization. Due to Gartner research, API virtualization allows
- management,
- monitoring,
- optimization and,
- orchestration
without injecting or compromising existing logic. For automotive requirements this encloses an anticipation of hazard and risk assessments as well as derived measures. All necessary tasks happen behind the scenes, e.g. access control, bus monitoring, etc. Furthermore SDA supports consumers to design own views on APIs, while
- improving overall system stability,
- reducing provisioning time and,
- scaling across hybrid environments (in- and off-vehicle).
A good example for this API flexibility, in the automotive domain, is the GENIVI/ W3C common-vehicle-interface (CVI) definition. This includes definition languages such as the GENIVI vehicle-signal-specification (VSS) and vehicle-service-catalogue (VSC). Both have a predefined API with semantic, on demand with specific overlays e.g. allowing to transfer the given passenger-car definition to a commercial-vehicle definition and vice versa. That context specific semantics is one pillar to reduce complexity of given tasks e.g. being able to apply heuristics. Heuristics solving problems by making quick and efficient judgments. In its core, it is all about understanding the problem context – also called domain knowledge. In example the gaze heuristic solving the question of catching a ball from the air with just one variable. A catcher just has to keep the angle between its eye and the ball constant, by adapting its own speed. All other variables such as wind speed, present ball speed, initial throwing angle, etc. are not important to solve the problem. This easy heuristic is used by nearly all non-human animals. The gaze heuristic keeps control of one variable instead of multiple. Instead of applying computation performance and mathematics it applies knowledge on a dimensional reduced solution space. This is the power semantics gives to technical solutions.
According to Gartner research the SDA concepts consist of multiple plans. From bottom to top the
- data-plan,
- control-plan and,
- application-plan
All may be managed by one management plan. It is a bit like the ISO/OSI 7 layer concept for network protocols. The bottom layer encapsulates the infrastructure specifics, e.g. mapping from a socket CAN via a DBC file specific signals into the API endpoint(s), represented by the southbound interface. On top of this data plan the control plan includes everything needed to ensure the quality-of-service (QoS) aspects like application gateway functionality for safety purpose, access control checks, etc. The control plan ends with the northbound interface providing mandatory semantics for the specific application plan. For the application-plan (aka front-end) the attributes are often summarized as mobile- or web-scale. It has nothing to do with web browser or mandatory HTTP as an application-layer protocol, it is more like
- service-oriented,
- event-driven,
- loosely-coupled,
- frequently-change,
- reduced chattiness,
- etc.
On control-plan in the behaviour of common cloud solutions:
- service-oriented,
- loosely-coupled,
- event-driven,
- continuously versionable,
- platform independent,
- composed and compostable,
- etc.
Overall it is like a service-oriented-architecture (SOA) but in a virtualized and managed manner. The management includes the important aspect of semantics. Past approaches like CORBA and AUTOSAR (AR) Adaptive have minimal solution related semantics (pre-)defined. Mechanisms like service definition and it’s invocation have been well defined, but e.g. the semantic names of the service endpoints are free to choose. It is hard to find common sense on semantics, but API virtualization could be the bridging approach for business applications. Business applications in a SDA environment are event-driven and loosely-coupled to the northbound interface, sharing the same semantic understanding with this interface, but may not with the southbound interface. A northbound based business application can clearly define its informational demand, e.g. via triggering rules. This approach is known from multi-agent-network (MAS) frameworks such as provided by the GENIVI project „IoT Event Analytics“ on GitHub.
Summarized, the automotive industry is in a transition phase. Software becomes a hardware independent topic. Stay tuned and let us see how the story will be written at the end.