The Future of the Software-Defined Vehicle is in Domain-Agnostic Software Middleware

Like workers in many industries that predate the modern technology landscape, automotive software engineers have been accustomed to working in silos for years. For each of the 5 domains that exist within cars today—ADAS, infotainment, body controls, drive controls, and environment controls— a different development team is likely responsible for the software. Furthermore, there is little to no cross-over or collaboration among teams, as each domain tends to operate mostly independently of the other.

In some ways, this separation of domains made sense due to technological limitations at the time. For example, ADAS is a safety-critical, life-saving functionality that has much stricter safety and security regulations than infotainment or other less safety-critical domains. But, as technology has advanced, it is becoming possible to create an advanced and de-siloed software architecture while still meeting the requirements of safety-critical applications as well as simplifying the development and deployment of the software artifacts. This advanced software structure is key to the economical and timely development of applications within the software-defined vehicle. 

With the development of SDVs comes a need for mixed-criticality systems, and the ability to more easily shift resources from the needs of software services in one automotive domain to another. For this to happen, the traditional silos need to be broken down and a domain-agnostic solution must be implemented. 

Why is the Software Siloed?

Benefits of a Domain Agnostic Software Middleware Framework

As its name implies, the SDV is powered by software, a shift from the more hardware-focused vehicles of the past as well as many modern vehicles that use software for various services but aren’t truly software-defined. This means that having a way to easily manage the existing software and provide Over-The-Air (OTA) updates as needed is crucial. 

As one Senior Manager of Engineering E/E at an OEM said, “All domains develop their own software and then fail when an E2E function is needed. I am not even speaking about the subsequent updates.” The current siloed system adds unnecessary layers of complexity and cost that can be remedied with the introduction of a domain-agnostic software middleware framework. 

With a homogenous middleware in place, there can be a complete abstraction of hardware across the entire vehicle. This will provide the following benefits:

• Sharing Resources - compute resources can easily be shifted or allocated from services in one automotive domain to another, and back, on an as-needed basis.
• Reduction of Redundancies - because resources can be shared, duplication can be eliminated while maintaining necessary contingencies if needed, significantly decreasing costs.
• Shorter Development Cycles Across Vehicles’ Lifecycles - having one middleware for all domains, as opposed to a separate system for each, means easier maintenance and much shorter development cycles measured in days and weeks vs the months and years typical today.
• Faster Time to Market - automotive applications and services can quickly be developed and deployed onto the vehicle, allowing for fast implementation of these services to the market while still maintaining the requisite safety and security qualities.

As an example, an ADAS system is typically set up in many vehicle models to have at least one backup in place in case the system fails. With a domain-agnostic solution, if the device managing ADAS applications at that moment fails, resources can be drawn from another less-critical domain to ensure that the ADAS system can run at full capacity until the car is able to stop safely. This has the potential for huge cost savings without impacting the safety of the driver, passengers, or others on the road. 

Challenges for Domain-Agnostic Software Middleware Frameworks

While a domain-agnostic solution will enable a more streamlined automotive architecture and provide cost savings, it does not come without any challenges. 

The differing levels of security needed for each domain will remain. This means that the middleware that will be used by all domains will need to adhere to stringent standards that all ADAS systems are bound by. Even though different domains will have different levels of criticality, the overall middleware must be constructed to meet the most stringent requirements.

In addition, there must be safeguards in place to ensure that a domain with lower-security requirements cannot be used by a hacker as a point of entry to a domain with higher security. That’s why built-in protection from cross-domain access or cross-domain vulnerabilities is essential when developing middleware. 

Finally, in developing domain-agnostic middleware and devices that perform routing and switching actions across the entire vehicle, the developers must ensure that they offer the same capabilities and performance (if not better) as the domain-specific solutions that are currently available. If the domain-agnostic solution were to limit the functionality of a certain domain, it would not be a competitive option in the marketplace for OEMs to consider. 

Next Steps

The automotive industry is not the first to shift to implementation middleware solutions to connect all systems and ‘domains.’ For example, the airline industry employed completely separate systems for reservations, loyalty programs, crew management, and maintenance in the past. Realizing that all the systems are connected and need to be able to communicate with each other, airlines were one of the first to implement a SOA framework to create middleware that allowed the systems to interact with each other, streamlining the entire process.

With domain-agnostic routing gateways and middleware, OEMs will experience reduced integration requirements and complexities leading to a faster time to market and significant cost savings. 

GuardKnox’s CommEngine™ and SOA Framework work together to allow OEMs and Tier-1s to streamline their software development, thereby decreasing complexity and redundancy and enabling a faster time to market for new features. For more information about how automotive leaders are developing the software-defined vehicle with the required middleware implementation, please contact us.