Future cars need standardized layered software architectures to realize the vision of software-defined vehicles that can enjoy seamless and timely software updates even after production. The most common architecture currently in use is the AUTOSAR Classic, widely used to develop ECUs in hundreds of vehicle models. However, the cost and complexities of this approach are well-noted in the industry.
To help address the cost/complexity issues and to allow for more complex tasks such as autonomous and connected vehicles, AUTOSAR Adaptive was developed. It is intended for high-performance computing platforms initially designed into 4th generation Domain centric E/E vehicle architectures which leverage AUTOSAR Classic ECUs to create a first generation of software-defined vehicles (SDV).
The dynamic nature and requirements of a modern vehicle require flexibility, scalability and efficient communication. AUTOSAR Adaptive uses the principles of Service-Oriented Architecture (SOA) such as dynamic discovery and asynchronous communication, to answer these needs. SOA is an architecture approach that is used across many industries but has not yet been widely adopted in the automotive field.
At GuardKnox, we have developed our patented Secure SOA Framework Suite (SFS) to provide OEMs and Tier 1s the ability to easily create their own Service Oriented Architectures to leverage the most out of the ECU consolidation that is part of 5th-generation E/E architectures as well as enable service-based communication across all of the vehicle’s devices and functional domains (in other words, system-wide SOA).
While AUTOSAR and the SFS have their own pros and cons, the SFS expects parallel usage of alternative middlewares such as Adaptive AUTOSAR or ROS. There are three main areas in which Secure SOA Framework best complements AUTOSAR (specifically AUTOSAR Adaptive): Communication management, execution management and orchestration and validation and qualification.
Communication Management
AUTOSAR Adaptive was developed with a focus on using SOME/IP as the transport middleware, which means that AUTOSAR Adaptive stacks were typically locked into SOME/IP. About 2 years ago, DDS was introduced as another transport middleware and because AUTOSAR Classic also uses the same middleware, the two versions can communicate with each other, but you cannot easily switch to another vendor or use a different middleware without investing in a new AUTOSAR stack.
Secure SOA Framework on the other hand, is completely agnostic to the communication layer. A Secure SOA Framework solution can support almost any communication technology, cutting down on development time and making it easier to reuse components across projects and vehicles.
Execution Management & Orchestration
The execution management function refers to the deployment of applications, enabling them to run throughout the vehicle. AUTOSAR Adaptive can currently only deploy software across a single ECU. It is unable to deploy from one ECU to another across the entire in-vehicle E/E system or from in-vehicle to the cloud. The SFS, on the other hand, sees ECUs and devices as a pool of resources where software components can be shifted from one hardware to another based on need and optimization.
The Secure SOA Framework’s domain manager is transport middleware/software-agnostic. It serves as a conductor, managing the whole deployment dynamically at the runtime level. It can handle and run disparate software apps regardless of the middleware and can deploy the apps across multiple ECUs or even between the vehicle and the cloud.
The Secure SOA Framework also allows for interoperability between different systems, including legacy systems. OEMs can continue using existing systems while also incorporating new features and apps which use different middleware frameworks.
Validation and Qualification
In general, the more safety-critical a system is, the more time it takes for validation and qualification to ensure that any new components or features won’t compromise driver and passenger safety. Since the Secure SOA Framework has a much smaller and more concise set of requirements built specifically for automotive embedded systems, the validation and qualification process is much less complicated.
During testing, there are likely to be fewer issues in the middleware when using a lean, automotive-focused middleware like Secure SOA Framework. And, because the approach itself has already been used in defense applications for over 20 years, its ability to handle safety-critical applications is already proven in use.
In contrast to our Secure SOA Framework, AUTOSAR was developed before the current mainstream safety regulations and standards were created (ISO 26462). This is why, for example, the crypto module in an AUTOSAR stack is an add-on and not part of the original design. The Secure SOA Framework is secure-by-design, built to provide the security needs of automotive applications.
Secure SOA Framework Suite + AUTOSAR: A Winning Combination
The creation of AUTOSAR was a crucial first step in standardizing the design and development of vehicle software. While it does enable a degree of software and hardware abstraction, it isn’t a complete solution. Even with AUTOSAR Adaptive, OEMs remain locked in to specific vendors, communication technologies, and AUTOSAR stacks preventing them from the level of flexibility they truly need.
With a Secure SOA Framework Suite OEMs can continue to leverage AUTOSAR capabilities and continue using existing assets, or choose to develop directly within the Secure SOA Framework to unleash the full power of the SDV. With the Secure SOA Framework Suite, OEMs can take full advantage of new functions and technologies as they are developed without the concern of fitting them into an existing rigid stack.
Click here to learn more about GuardKnox’s Secure SOA Framework that integrates seamlessly with AUTOSAR Classic and Adaptive.
