To set the stage, let me quote two press releases about 10 years apart. The first press release was made at the inception. You can find these on the GENIVI website.
“San Ramon, Calif., Mar. 2, 2009 — Leading automobile manufacturers and suppliers announced today the formation of the GENIVI Alliance, a non-profit organization committed to driving the development and broad adoption of an open source In-Vehicle Infotainment (IVI) reference platform. The new alliance will unite industry-leading automotive, consumer electronics, communications, and application development companies investing in the IVI market and driving innovation. The effort will result in both reducing time-to-market and total cost of ownership. GENIVI Alliance founding members BMW Group, Delphi, General Motors Corp., Intel, Magneti Marelli, PSA Peugeot Citroën, Visteon Corp., and Wind River are collaborating to create a shared GENIVI platform — a common software architecture that is scalable across product lines and generations. The GENIVI platform will accelerate the pace at which automakers can deliver new solutions, bringing them closer to the life-cycle of consumer devices, and accelerating new business models, such as connected services.”
“SAN RAMON, Calif. — Dec. 18, 2018 — The GENIVI Alliance, the organization responsible for introducing Linux and open source software into the in-vehicle, infotainment domain, has successfully delivered several assets through its vehicle domain interaction strategy and is evolving into an alliance integrating multiple, in-vehicle operating systems required for a fully integrated vehicle cockpit. As the industry moves toward combining multiple vehicle cockpit domains (IVI, cluster, connected devices) into a single silicon solution, often with multiple operating systems, automakers are exploring the concept of a central compute platform, coined by some in the market as cockpit computing”
The press release of 2018 is interesting due to several reasons.
- There is no mention of a platform — rather it only talks about Linux and open source software in the vehicle.
- Due to Industry evolution, the focus has changed to investigate concepts to integrate multiple vehicle cockpit domains into a single silicon solution.
Even though there have been some successful GENIVI products, It is clear that the idea of building a GENIVI platform did not really work.
Meanwhile, Android Automotive has risen up the ranks and is now a viable platform that is already being used in several vehicles and may be well on its way to becoming the preferred infotainment platform. GENIVI now has an Android Automotive SIG.
Here are my thoughts on why this is so.
- Fine-grained, fortuitous reuse
The concept in GENIVI was to allow members to present candidate solutions for parts of the system. Candidate solutions were evaluated and if accepted by the appropriate committee, would get included in the component list.
What is the problem with this approach? A democratic solution to such a problem rarely results in the best solution. Participants were constrained by their own in-house choice of their solution. The final solution becomes the lowest common denominator, the one that everyone is willing to “compromise” on.
Take, for example, a lot of studies was done to decide on a suitable IPC mechanism. The final decision was to use DBus even though more performant solutions were evaluated. Techniques and tools like Franca IDL and IPC agnostic code generation, while nice tools on their own, their use in the platform is a symptom of indecisiveness in one of the fundamental parts of a platform — the IPC mechanism.
Compliance escape hatches were provided by defining the P1, P2 and P3 type of components which resulted in a multitude of potential solutions.
The P1 priority list of compliance components was a handful of standard open source components with Layer Management and Audio Management solutions thrown in.
A platform is useful if it is reusable in products. With a lightweight approach to compliance, reuse depends on the predisposition of the product developer. It was possible to brand pretty much any Linux solution as “GENIVI Compliant”. Solutions were about how to “co-exist” with GENIVI. The benefits of the co-existence were rarely more than just being mentioned on marketing material.
In contrast, the Android platform is opinionated on what the basic infrastructural components are and the architecture. More importantly, the platform was empowered to build a new suitable solution if the right one didn’t exist. To take a few examples, Binder, the Hal architecture.
2. Missing top-down architecture
I do understand the importance of having a good architecture model. However, too much importance was given to fine-grained modeling of components and their interfaces. A lot of effort went in creating and maintaining the architecture model. The ROI for this effort is questionable.
The architecture was built bottom up as a result of what was mentioned earlier. A top-down view of a GENIVI compliant product is hard to visualize and to enforce.
It is important to define and communicate a top-down architecture and lay down the rules and constraints of that architecture. The component first approach did not really encourage top-down architecture.
A reference architecture for GENIVI does exist in a diagram form, but if you go into the details of the reference architecture you will notice that the elements that build up the architecture are a mix of actual software components and capabilities.
The effort to define the common architecture was started, but probably only towards the fag end of the decade. This was probably too late.
3. Mostly a set of technical standards
GENIVI compliance hinged around checking off satisfied rows in the compliance document. Building a compliant system had a low entry barrier with a lot of workarounds to achieve compliance. What was the benefit of compliance? Nothing more than marketing, in the form of getting your name on the GENIVI website.
Compliance should have real benefits to the users of the platform — the developers building the product.
There may be other issues, but in my view, these are three important reasons why the original goals of GENIVI were not met. As I wrote in , these are actually commonly made mistakes when building a product line and the Software Product Line community actually calls them out and asks us to be watchful of these patterns.
Coming back to the title, did GENIVI really hold back the evolution of Linux Infotainment? I believe this is true because it allowed the development of a fragmented ecosystem with a multitude of solutions. Developers were focusing on solving recurring problems in their own way rather than identifying and solving higher level problems.
Android Automotive is a strong platform. Products built on this benefit from the huge ecosystem of applications and developers of this ecosystem. There still are some issues and some use-cases, such as early camera and other automotive use-cases that require the development of alternate native solutions. However, solutions to these problems are well understood and do not pose a significant challenge.
While Android comes with its advantages, all the powerful features are controlled by Google. Most of the software that runs as part of the system is commoditized and the differentiating features are downloaded applications, online services or a combination of both. These come with strings attached.
Not every OEM wants to use an Android system. The phone ecosystem has space for two players, Apple and Google. Does the same apply for Vehicle infotainment units? Who are the contenders?
AGL: AGL seems to be more opinionated in how a product comes together. It also includes an app framework and HMI framework. This seems to be headed in the right direction.
Tizen: Tizen automotive had some initial traction, but Tizen no longer supports automotive or has plans to do so. AGL takes ideas also potentially some software from Tizen.
WebOS: Having an established developer and app ecosystem is a massive boost to a platform. If you stretch your imagination, an infotainment system is just a souped-up TV. Both WebOS and Tizen-TV have established TV ecosystems — could these be leveraged to bootstrap an automotive ecosystem?
To summarize, I am of the opinion that GENIVI actually prevented the creation of a single Linux Infotainment platform due to the issues mentioned earlier. Building a platform requires a more opinionated approach which is hard to do when there are too many organizations trying to push their own implementations and agenda. A platform built by a smaller organization might have had more success in converging into a single platform.
I believe there still exists a market for Linux systems even though Android is making gains in the automotive industry. A competition to Android automotive is really needed in this space and I would love to see a new contender that can spice things up. This can be successful only if the contributors to these potential platforms focus on the bigger picture to really build a single platform.
Hindsight is 20–20. This is not a criticism of but an attempt to write down what we could learn from the clarity that looking back provides us. Knowing about Software Product lines will help you learn best practices to build a successful software platform.
This may be a controversial topic, but it is something worth discussing. I would love to hear your feedback and counter-view points.
Disclaimer: Opinions are my own and not the views of my employer.