Emily Hayter, lead software architect at WAN data acceleration provider Bridgeworks speaks to TU Automotive Magazine about the latest tech trends in software for the connected car.
July 7, 2020
By having cross-industry collaborations it becomes possible to define common software development standards.
That’s the opinion of Adi Singh, product manager for the robotics and automotive verticals at Canonical. He says this will in turn “accelerate the development and adoption of new technology for the connected car”. He thinks this can be achieved by bringing together experts from different fields, and from various industries, to enable “a dialogue to represent the needs and priorities of the various stakeholders relevant to the technology”.
Dan Cauchy, executive director of Automotive Grade Linux (AGL) at the Linux Foundation adds: “Open source software enables cross-industry collaboration and shared development, which can lead to de facto standards. For example, within AGL, automakers, suppliers and vendors have collaboratively developed an open source software platform called the AGL Unified Code Base (UCB), which has become the de factostandard for infotainment, instrument cluster, heads-up-display and telematics.”
The ELISA project
The ELISA project is an example that Singh cites. As an acronym it stands for Enabling Linux in Safety Applications and it creates a forum for automakers and microchip manufacturers to develop standards around open source safety-critical systems. He explains: “The resulting standards provide a framework for companies to easily build, certify and deploy their proprietary solutions. Simultaneously, they provide regulatory agencies with quantitative measures and a set of concrete processes for fair and efficient governance of a given technology.”
Emily Hayter, lead software architect at WAN data acceleration provider Bridgeworks, finds that currently there are an insufficient number of cross-industry collaborations. However, she finds that there are many start-ups that “may be more open to partnerships to cover the bases”.
She adds: “Part of that view comes from all of the large vehicle manufacturers, having their own closed projects and handling some areas of the development, while dumping billions onto a handful of developers like Argo AI, who have Ford & VW as investors, to cover other areas.” She suspects that there won’t be a unified connected car and autonomous vehicle (CAV) platform. Ultimately, she claims there will be about “10 different platforms, platforms, each with a different level of openness, and supported by a different vendor”.
Technology fragmentation
Singh agrees that technology initiatives tend to be high fragments within the automotive industry. However, there are standardization such as AUTOSAR, ISO26262 and SAE J3061. In his view they represent a step in the right direction. However, there is a need in his opinion for a CAV platform definition to “accommodate the nuances of everyday driving and behind-the-wheel decision-making”. Collaboration, therefore, requires the sharing of data and the ability to sift through it to, as he puts it, “determine overarching trends around which platform should be defined”.
He adds: “Collecting field data is a capital-intensive exercise relying on a fleet of operational CAV prototypes, and not many have the resources to do this at scale. Fortunately, several organizations — most significantly, automotive OEMs — that do have such resources at hand have started making their datasets available to the public for CAV research. This trend needs to continue and expand for achieving a unified CAV software platform.”
By sharing a single open source collaborative platform, Cauchy claims it becomes possible to “reduce fragmentation across the industry through the growth of an AGL ecosystem and supply chain that all use the same code base. Developers and suppliers can build a product once and have it work for multiple OEMs instead of having to build different versions for each manufacturer and vehicle model”.
Open source benefits
So, what benefits does the use of open source software provide, and what challenges does it pose to achieving standardization? Hayter responds: “Open source software usually provides easier starting points for smaller players to jump onboard, and it is sometimes used to provide a test-bed or reference implementation for standards.”
“However, there is unlikely to be deep interworking between open source and autonomous vehicle teams, and yet some open source components will undoubtedly be used in AV systems. These components will need extensive testing for AV systems, creating many versions behind the active open source development. For safety-critical areas the value of a well-tested and stable platform is far more valuable than the latest features.”
Cauchy adds: “AGL has already become the industry standard, the project is supported by 11 major car manufacturers and over 150 companies. So we feel we are mostly past the standardization hurdles.”
He explains that the AGL UCB includes “an operating system, middleware and application framework, and provides roughly 70-80% of the starting point for a production infotainment, instrument cluster, or telematics system.” The benefit is that carmakers and their suppliers, he reveals, can now shift their time and resources over to innovating on top of the platform, focusing on areas of differentiation: such as user experience, connected car features and new cloud-based services that appeal to consumers.
There are other benefits too, he explains: “It also allows for code reuse and a more efficient development process. With 150+ member companies at AGL, each one with potentially hundreds of engineers working on AGL, we are able to leverage a massive economy of scale that simply cannot be reproduced inside a single company. For example, if a company finds a critical bug or security flaw, they will fix it and share the fix with the AGL community, and everyone will benefit. This is the power of open source!”
The importance of outsiders
Singh also explains that there is a realization from companies within traditional sectors such as manufacturing, automotive and finance of the importance of collaborating with industry outsiders. Why? They deem it necessary to be able to, as Singh says, “stay on top of their innovation game”. He finds that this is particularly vital as the boundaries between the sectors are becoming blurred. “Cars have become computers on wheels, and smartphones have put a trading desk in everyone’s pocket”, he explains. The view is that this will enable car manufacturers to gain from the economic benefits of open source software by allowing more people to contribute to connected car and the CAV software development.
The benefits of this collaboration should, according to Singh, leads to faster software cycles, a more reliable codebase, and voluntary help “from some of the brightest minds in the world.” The perquisite is the need for high quality data to enable the reliable development of machine learning software to teach CAVs how to react with their environments. To this end he explains: “Shared datasets lower the barriers to innovation and accelerate development. Engineers from different companies can collaborate on the same common dataset (or, being in the public domain, even combine their individual datasets) to solve problems that are pertinent to the entire industry.”
Sharing datasets
“Common datasets also introduce structure and replicability in new breakthroughs, so open-sourcing field data can actually help with standardization of software platforms. But on the flipside, it can be argued that having a large globally distributed developer base is not conducive to standardization; each team would want to bring in their own engineering practices and processes to the codebase.”
Automakers can, in his view, subsequently play a crucial role by striking a balance between open source collaboration and unified platform development. “If these larger organizations can play the role of technology integrators, they can extract the business logic from new developments and add them to wrappers that conform to standards agreed to by cross-industry coalitions,” he says.
Hayter adds: “The Unified Code Base distribution seems presently to currently cover only Infotainment, Telematics and Instrument Cluster applications, so the human-machine interface. However, they want to cover drive assistance, functional safety and autonomous driving as well.”
Open source examples
Subaru, according to Singh, has been frequently criticized “for dropping the ball on the in-cabin user experience of their vehicles.” He says: “Subaru needed a way to catch up with competitors and produce an infotainment system that could impress its customers.”
“To accomplish this, the company turned to Automotive Grade Linux (AGL), an open-source platform that brings together OEMs, Tier 1s and tech companies to collaborate on vehicle platforms and change the way manufacturers write software for cars. It includes an operating system, middleware and an application framework to get users started with developing their proprietary solutions with as little effort as possible.”
With the AGL Unified Code Base, Subaru gained a codebase that was already 70% production-ready. This avoided the need to build everything from scratch, saving precious time and money while allowing the project to readily begin.
Singh elaborates: “Subaru could thus instead focus its energy on extending the platform with integrations, features, and services that were unique to its own offering, and were aligned with the brand’s vision of their revamped in-cabin user experience. As a result, the company significantly reduced the launch cycle of its new Starlink infotainment platform and announced the AGL integrated system in its 2020 Outback and Legacy models.”
Changing Perceptions
However, the biggest challenge according to Cauchy was to change the perception that car manufacturers have about software, and there has been a need to disrupt their supply chain model for software procurement. Before AGL, he claims that automakers “provide a specification to a supplier, and the supplier would build a “black box” with some software inside, and as long as that software met the specifications, the OEM was content.”
“This is very short sighted as there was no long-term reuse or investment made in the software platform, and the platform would change every few years. With AGL, we disrupted this concept and allowed the OEMs to make a long term investment into a platform that they can own, control and modify, such that they can focus on value added features and not reinvent the platform every 3-4 years. This is probably the single most important outcome out of AGL.”
