Introduction
As an HMI innovation and development services company, Siili Auto works with many different OEMs and Tier1s. In our projects we have faced one persistent issue: the proliferation of different data models and interfaces representing the same essential vehicle information. While the automotive industry races towards innovation and connectivity, this fragmentation in data representation presents a hurdle that slows down innovation and development time.
Divergent Interfaces, Duplicated Efforts
Imagine a scenario where engineers and designers must recreate the same features for an HMI across different interfaces and data models used by various Original Equipment Manufacturers (OEMs). This recurrent dilemma results in the wasteful duplication of efforts and resources, and as a consequence, time and energy better invested in pushing the boundaries of HMI technology are squandered on repetitive tasks.
Redundancy in In-Vehicle and Cloud Connectivity
Another symptom of this issue manifests in the domain of in-vehicle and cloud connectivity. These critical components of modern automobiles frequently require duplicate implementation for the same set of vehicle-related information. Not only does this redundancy consume valuable development resources, but it also leads to increased complexity and potential points of failure in the full experience.
Inconsistencies and Implementation Errors
Furthermore, the existence of various data models gives rise to inconsistencies and implementation errors when mapping information from one model to another. These discrepancies can introduce bugs, security vulnerabilities, and operational inefficiencies: posing substantial risks to both vehicle performance and the user experience.
To overcome these challenges, the automotive industry must seek a standardized solution that transcends the silos of data models and interfaces: streamlining the process and fostering innovation. We set out to explore the potential of the COVESA Vehicle Signal Specification (VSS) as a viable solution to this problem and thus built a proof-of-concept implementation.
VSS as a potential solution?
Overview of VSS
Vehicle Signal Specification (VSS) (https://covesa.github.io/vehicle_signal_specification/ ) is a COVESA initiative designed to define a syntax and catalog for vehicle signals. It represents a transformative approach that can address the persistent challenge of diverse data models and interfaces.
VSS introduces a common syntax for defining vehicle signals in a structured and standardized manner, acting as a lingua franca for the automotive industry and transcending the boundaries set by OEM-specific data models and interfaces. At its core, VSS offers two essential components:
- Common Syntax: VSS provides a unified language for describing vehicle signals, enabling consistent communication both within and outside the vehicle. This common syntax lays the groundwork for seamless data exchange and integration.
- Signal Catalog: VSS comes equipped with a comprehensive catalog of signals related to vehicles. This catalog serves as a valuable resource, offering a standardized set of signals ripe for use by HMI developers, OEMs, and industry stakeholders.
Standardization in HMI Development
The potential of VSS in HMI development cannot be overstated. A substantial portion of features found in automotive HMIs—such as instrument clusters and infotainment systems—remain consistent across different OEMs. These shared functionalities form the cornerstone of the in-vehicle user experience.
By providing standardized vehicle data specification, VSS empowers industry actors to embrace a common naming space for communication both outside and inside the vehicle. Moreover, VSS abstracts the intricate details of underlying vehicle implementations, fostering a level of consistency and reliability that eases up HMI developer work.
Flexibility for Vendor-Specific Extensions
While VSS offers a standardized foundation for HMI development, it also recognizes the need for customization and differentiation. Acknowledging that different OEMs may have unique requirements and features, VSS provides ample room for vendor-specific extensions.
In essence, VSS strikes a harmonious balance between standardization and flexibility, offering a versatile framework that can accommodate the diverse needs of the automotive industry. It also empowers developers to leverage a common framework while tailoring HMI solutions to meet specific OEM or branding requirements.
VSS as a Data Model
It’s important to clarify that in itself, VSS is not an interface (API) and rather serves as a robust data model—a structured representation of vehicle signals and their attributes. To harness the power of VSS in HMI development, an API framework is required.
ApiGear
ApiGear (https://apigear.io/) is an open-source tool for API-driven code generation and integration based on ObjectAPI. We chose ApiGear for our HMI demo because it promises not only efficiency but also interoperability and consistency.
Figure 1. ApiGear API-driven workflow.
The ApiGear Ecosystem
ApiGear represents more than just a tool; it’s an entire ecosystem designed to facilitate the creation of software interfaces and a new generation of ready-to-use integration Software Development Kits (SDKs). This SDK includes pre-configured support for essential aspects of modern software development such as monitoring, logging, tracing, and simulating interface calls.
When confronted with the need for an interface and API framework to harness the power of the COVESA Vehicle Signal Specification (VSS) in our HMI prototype, the choice of ApiGear quickly became clear for several reasons:
Integration Simplicity
ApiGear’s user-friendly interface and robust code generation capabilities simplify the integration of complex data models like VSS into HMI projects. Teams can leverage its features to effortlessly bridge the gap between VSS and HMI components.
Monitoring and Simulation Support
In selecting ApiGear, we gain access to built-in support for monitoring, logging, tracing, and simulating interface calls. These features are invaluable for debugging and optimizing HMI development, enhancing overall system reliability.
Open-Source Community
ApiGear benefits from a thriving open-source community, meaning it’s continuously evolving and receiving updates. This active environment ensures the tool remains relevant and adaptable to changing HMI development needs.
Seamless Integration
ApiGear’s adaptability and compatibility enable seamless integration into our HMI prototype, making it the ideal candidate to bridge the gap between VSS and the user interface.
Our Proof-of-Concept: Code Generation
We previously explored HMI development challenges and introduced the COVESA Vehicle Signal Specification (VSS) as a promising solution. Now, we’ll delve into technical aspects of our proof-of-concept (PoC) implementation: illustrating how we integrated VSS using ApiGear.
Exporter Implementation
Figure 2. Proof-of-concept, VSS to ApiGear code generation.
To effectively leverage VSS in our HMI development, we began by implementing an additional exporter that seamlessly interacts with the VSS structure and is responsible for generating necessary files and code artifacts for ApiGear integration.
Core exporter functionality involves traversing the loaded VSS structure systematically, extracting relevant information about vehicle signals and their attributes/relationships and thus enabling the generation of interface-specific code.
An important consideration in our implementation is VSS tree structure flattening. As ApiGear does not support structuring modules. we reorganize the VSS tree to align with ApiGear requirements: ensuring effective integration into our HMI project.
The exporter produces ApiGear solution and module files tailored to our HMI project needs. These files act as the blueprint for our interface and API framework, providing a structured foundation for VSS integration.
In the VSS, some signals may have bounded lists of possible values or custom-defined types. To accommodate these scenarios, our exporter generates an enum containing all possible values and exports custom-defined VSS types: ensuring comprehensive coverage of signal variations.
A critical PoC milestone was testing the exported solution and module files. We chose to run the ApiGear code generation process using C++14, Qt, and Unreal Engine templates—key components of our HMI development stack.
Testing results were promising, as all generated codebases compiled successfully without major issues. This marked a significant achievement, demonstrating exported code compatibility with our chosen development tools and platforms.
Integration into vss-tools Repository
To streamline our development process and maintain a cohesive workflow, we integrated the exporter into the vss-tools repository: ensuring our tools and codebase align seamlessly with the VSS ecosystem, enhancing efficiency and collaboration among our development team.
Our PoC: Functionality
To assess the practicality and effectiveness of our PoC, we utilized the generated code to facilitate communication between two applications: an Unreal Engine application and an Unreal Engine instrument cluster. Communication was established via C++ server implementation, showcasing the real-world applicability of our approach.
Client-Server Interaction
One key outcome of our PoC is the establishment of client-server communication facilitated by the generated code. In our PoC, the generated client—implemented using Unreal Engine—interacts with the generated server (a C++ Olink server). This client-server architecture forms the backbone of our HMI development, enabling seamless data exchange and functionality.
Figure 3. Proof-of-concept run-time setup.
A crucial aspect of our client-server interaction is state change management. When a signal’s state changes on the client side (e.g., user input or sensor data), the change is transmitted to the server. The server then stores this information and subsequently notifies all connected clients that subscribe to the modified interface, ensuring real-time synchronization.
Figure 4. Unreal Engine cluster application and simulation in action.
Conclusion and Next Steps
Our PoC was conducted with the primary goal of addressing the challenges posed by diverse data models and interfaces in human-machine interface (HMI) development.
By leveraging the COVESA Vehicle Signal Specification (VSS) and the ApiGear framework, the HMI development process can be effectively streamlined. Eliminating redundant efforts when implementing similar features across different interfaces results in improved efficiency and resource allocation.
In our PoC, we successfully demonstrated the elimination of redundancy in in-vehicle and cloud connectivity implementations. The unified approach facilitated by VSS has not only reduced development time but also minimized the potential for errors, with the same generated ApiGear interface effectively used both in cloud connectivity applications as well as HMI development.
The use of VSS as standardized vehicle data specification can provide a new level of consistency in HMI development. Common naming spaces and the abstraction of underlying vehicle implementation, specifically, contribute to a more stable and reliable system.
Our integration of the exporter directly into the vss-tools repository reflects our commitment to building a collaborative ecosystem. By sharing tools and resources, we encourage industry-wide collaboration: ultimately driving innovation and progress. We are now ready to contribute the vss2apigear exporter to the global COVESA vss-tools repository.
