In recent times, the automotive industry has been rapidly shifting from hardware-defined vehicles to software-defined vehicles (SDVs). In the past, vehicle improvement was referred as changing in hardware, electronic control unit (ECU) upgrade, or adding any new mechanical parts. But many vehicle functions were closely integrated with hardware, even if small change requires proper engineering approach.
But now the industry is changing. As Automotive industry is adopting software which gives flexibility where industry can add new features, upgrade existing functions, and release new software updates even vehicle already left the factory floor. This is changing how we design, develop, and maintain vehicles.
Android Automotive OS (AAOS) is now become an integral part of the industry, where initially it was used for in-vehicle infotainment (IVI), but now it broader its area with SDV architectures.
In result, AAOS is not just now used as infotainment activity purpose; it is now widely used as reusable software foundation.
Getting started with AAOS on one vehicle is just the beginning. When its role grows, the software must support more hardware setups, vehicle functions, and system requirements.
For example, one vehicle may use some system-on-chip (SoC) and display setup, on other hand, different vehicle may use a different computing platform, multiple displays, or different vehicle network architecture. Where same AAOS implementation may not work appropriately for both different vehicle platforms without any integration or testing.
Here the real challenge begins when we need to utilize the same software across various vehicle models, hardware platforms, brands, and markets.
Now the question arises in industries that,
how do we reuse the AAOS across multiple vehicles without repeating or replacing the whole engineering work in vehicle-by-vehicle?
To answer this, first we need to go through with why reuse is difficult in practical approach. And what are the key challenges that industries facing while scaling AAOS from single vehicle to entire vehicle portfolio.
Key Challenges in Scaling AAOS SDV
As we seen earlier, that reusing of AAOS across vehicles is not just single engineering problem, it involves various hardware management, software architecture, validation, security, long-term maintenance and management etc.
When these differences handled by factory floor for each vehicle separately, it might impact on repeated engineering effort, inconsistent plant operations, and maintenance burden increases.
So, here we discussed some of the key challenges which explains why scaling of AAOS SDV from one vehicle to every vehicle becoming difficult, and why structured (step-by-step) approach is feasible to apply. Let us start with foundation: Hardware;
1. Hardware Complexity
Hardware complexity begins when different vehicle platforms may use different SoCs, GPU architectures, hypervisors, memory strengths, and display technologies. This creates the challenge on integration of Android Automotive OS, resource management, and majorly how the application is performed.
For example, a digital cockpit applications works smoothly on one vehicle, but it requires internal changes when we shift it to another vehicle platform. Why? Because of differences in graphic capabilities, display pipelines, or hardware interfaces which may affect the application running and display information.
We need to adapt and test the foundational software components to make sure that they are operate correctly on new hardware.
Also, to avoid repetition of this work across whole vehicle portfolio, we can separate out the common application logic from hardware-specific implementations. We can reuse the core application logic with clearly defined interfaces and abstraction layers; so just dependent components need to adapt on targeted hardware requirements.
This approach is not eliminating hardware-specific development or testing. However, it saves the factory time by just separate out the change required hardware across multiple software layers every time the AAOS implementation on various vehicle platforms.
2. Vehicle Network Complexity
Hardware alone is not only part, which is challenging, software also needs to communicable part in vehicle’s electronic systems, and this is not an easy as always.
Our modern-day vehicles use various communication technologies such as, CAN, CAN-FD, LIN, Automotive Ethernet, and FlexRay. Also, combination variation depends upon the vehicle architecture and the functions based on OEMs.
But the challenges come when the software developed for one vehicle needs to work with other vehicles properly without making any network changes. If an application is connected properly to specific network implementation, we need to change the application itself by access the same vehicle functions or data.
These changes can affect other software components which are dependent on it.
We can avoid much rework by clearly define the interfaces between applications, vehicle services, and base communication layers. This allows various applications to be accessed in vehicle data and functions without delay and without any more detailed network implementations.
In this way, when the network architecture changes between vehicle functions, we can simply focus on adaption the relevant interfaces and services rather than revisiting the whole application.
Key Challenges in AAOS SDV Scaling
3. Brand Differentiation
One of the challenges of working with different automotive brands is the differences in technology. A car maker might create several different brands under one roof, each of which will have its own design philosophy, experience, and, of course, unique applications and options.
In cases in which the two brands share the same platform, the requirements for both platforms can be different. One brand might need a different home screen while another would need something different in the way of voice interaction, display layout, or the set of services available in the car.
Creating separate branches of the code for all car brands could lead to serious difficulties. Even a minor issue that can be fixed without any difficulty might have to be tested on various platforms.
A better way to approach this issue is proposed by creating and keeping the main software identical and allowing brands the opportunity to make necessary changes.
4. Regional Requirements
Branding is just the tip of the iceberg. When automakers roll out the exact same vehicle platform across different global markets, they instantly run into a wall of local demands.
Think about it; certain regions might need extra language packs, specific local connectivity partners, or regional services baked right in.
Besides this, there are many local laws and laws regarding data privacy that one has to be aware of. Some of these changes might require simple changes in configuration, whereas others would demand full coding changes.
Things start getting complicated when one has to manage dozens of markets. Keeping separate builds of software for each country makes development and QA extremely complicated and takes away all the fun associated with the process, not even mentioning making it ten times easier to release software updates and patches.
It is advisable to decide which changes can be made through alterations of configuration, and which ones would require more serious modifications of a software.
Mitigating These Challenges
When we think about hardware, vehicle networks, brand, and regional requirements in the process of expanding AAOS across vehicle programs, we begin to understand the problems that creating the same OS for multiple ecosystems requires.
Each vehicle program brings with it several differences. If we address each difference independently, we may end up with number of software versions that perform the overall task and the identical tasks in software development.
What we should do is to implement architecture, enabling the same common elements to be shared, which also ensures that parts dependent upon the vehicle/brand/market are altered independently.
In the next section, we discuss the building blocks of the architecture that make it possible.
Architectural Foundations for Scalability
As soon as we find out where the differences originate, we can create new software solutions that allow much better management of those differences. Four of the most important parts to consider in this respect are modular design techniques, Vehicle Hardware Abstraction Layer (VHAL), virtualization, and service-oriented architecture (SOA).
Each one addresses a particular aspect of the problem, and together they allow us to create a flexible approach to accommodate different types of vehicles.
Modular Software Design
The first step in the process of making software components is to divide them. Each component must be complete and cleanly designed, and developed on its own without needless dependencies. For instance, if a vehicle needs a different version of one service, it is expected that the component can be modified without rewriting unrelated parts of the whole.
Modularity also makes it easier for different teams to work on different components independently since any changes can be made within the specified framework and it won’t affect the process.
Although it is still required to verify the full system, the modular approach allows for decreasing the amount of repetitive work.
Vehicle Hardware Abstraction Layer (VHAL)
The VHAL is key to connecting AAOS to the way vehicles implement certain properties including road speed, gear, and climate settings in the vehicle.
Rather than expecting every application to know how to deal with the hardware specific to every vehicle, Android Automotive OS will use the well defined interfaces through which it can access the states of supported properties.
The implementation then deals with the specifics of the vehicle.
For example, if there is a difference in implementation between two different models for a supported property, then the integration layer will handle it instead of requiring the applications that utilize the property to change.
While VHAL does not eliminate vehicle-specific integration, it allows us to implement this integration differently from applications that are being developed for use on all vehicles.
As vehicular computing systems evolve, we should also think about how different software environments can work on the same hardware.
Architectural Foundation for Scalability
Virtualization
Today’s driverless vehicles are becoming smarter, opting for integrated computing designs in which a solitary computing unit handles several operations.
A digital cockpit, for instance, can depend on AAOS as opposed to Linux or RTOS. In some cases, the processor needs to meet safety, time, and resource needs.
Using virtualization technology makes it possible for numerous operating systems to work simultaneously without interfering with each other. The hypervisor will isolate the various operating systems and allow them access to the hardware.
In the case of AAOS-equipped cars, virtualization allows the driverless vehicle to carry out its cockpit operations and other functions provided the various systems work as independent operating systems
Good planning is essential to ensure that resources are appropriately allocated, communication between systems is effective and proof of system operation is achieved.
Service-Oriented Architecture (SOA)
Service-oriented architecture separates the function a component provides from the details of how that function is implemented.
Consider vehicle status, climate management, diagnostics, power management, and connectivity. These functions may be implemented differently across vehicle programs, but applications should not need to understand every implementation detail to use them.
With well-defined service interfaces, applications can request the functions they need while the underlying services handle the relevant vehicle-specific integration.
For example, two vehicles may control climate through different hardware, but an application can request “set cabin temperature” through the same service interface on both.
This approach allows teams to develop and maintain components more independently. It also makes it easier to introduce new features or change an implementation without unnecessarily affecting other parts of the platform.
SOA complements VHAL and virtualization. VHAL provides access to supported vehicle properties, virtualization helps separate software environments, and service interfaces define how software components interact.
Together with modular design, they give us a common software foundation that can accommodate different vehicle requirements.
However, building a reusable platform is only part of the work. We also need a reliable way to maintain and improve the software after vehicles are deployed.
Maintaining and Securing the Platform After Deployment
Once vehicles start moving on the road, three key factors come into play: Over-the-Air (OTA) updates, telemetry and observability, and security.
OTA Updates: Keeping Vehicle Software Up to Date
Although a reusable software platform is necessary, it still needs attention after vehicles leave the assembly plant. OTA updates enable original equipment manufacturers (OEMs) to perform software alterations, improvements, fixes, and enhancements remotely.
Even if a single refutable platform means more effective use of software updates across vehicles programs, every specific update must nevertheless be checked against the vehicles hardware, software configuration, and dependencies.
Besides applying updates, an understanding of how the software behaves in practice must be garnered as well as problems discovered and improvements proposed.
Telemetry and Observability: Understanding Software in the Field
Once the car is out there, engineering teams would require to observe how the software is working in the field.
Telemetry serves for gathering important knowledge about the system’s status and performance, covering all aspects including how well the system worked, gained resources, and how good its performance is.
Observability is about processing available information coming from diagnostics to figure out what was going on inside the system.
For instance, let us assume that a vehicle is experiencing slow response from an application. Through the diagnostic information we have, we might determine whether this is caused by the way memory is being used, the application performance, or the load on the system processor.
If we do not have such information, we might depend on reports that are at times limited or try to recreate the problem in a controlled environment before we check it out.
When all the relevant telemetric and diagnostic mechanisms are in place, engineers can check for patterns in the way different vehicle configurations work, report on the issues that repeat with different vehicles, and gain this knowledge for the new software updates.
As we see, the main problem is not to gather as much data as possible, but rather to get the required information and protect it.
Security Must Be Part of the Design
While technologies for connection of vehicles are being developed and software updates take place remotely, security is becoming a vital aspect of platform maintenance.
It is essential to protect the system starting from powering it on and during the operation process and software updates via various technologies like Secure Boot, hardware trust root, trusted execution environment, secure communication, and secure OTA. This system should work as one in the security system’s design of a given vehicle and should be checked for the validity.
Security should be incorporated in the platform from the very beginning so that all the processes of the vehicle are protected while using various hardware and software combinations.
The MosChip Perspective
To establish an Android Automotive OS SDV platform that is scalable, more work is necessary than merely assembling separate parts and pieces.
Allotting together different levels of the Android stack and adapting them for the needs of every vehicle platform is necessary. This is tightly connected to the more general principles of the development of software-defined vehicles in which architecture and integration solutions are key to the vehicles’ capabilities.
This is what MosChip’s thorough knowledge in Android engineering is used for.
We cover the whole Android stack from kernel and driver development to HAL and native libraries, system services, framework, and applications. Different layers are customized according to product requirements.
This also encompasses VHAL development, cockpit multi-monitor integration, and adaptation of the Android platform components to the overall vehicle software solutions.
Our approach presupposes an analysis of requirements of the target vehicle, identifying re-usable parts of the platform, and adjusting only those layers that must be changed.
As a result, it becomes possible for OEMs to utilize the same platform for different physical configurations, vehicle functions, and user experience across their vehicle fleet.
To know more about MosChip’s capabilities, drop us a line, and our team will get back to you.