Vehicle Software Access Interface for Cross-Architecture Portability

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing vehicle software applications face limited interoperability due to platforms like AUTOSAR Adaptive, communication protocols, and specific hardware architectures, restricting their portability across different vehicle electrical/electronic architectures.

Innovation Solution

The method provides access to vehicle software applications across various vehicle systems with differently configured electrical/electronic architectures using an interface description language like WIT, enabling defined access interfaces that are independent of specific configurations, and employing WebAssembly System Interface (WASI) for secure and standardized execution.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If vehicle software applications are adapted to specific vehicle electrical/electronic architectures using platforms like AUTOSAR Adaptive and communication protocols like grpc or SomeIP, then the software can access vehicle functions and data, but the interoperability and portability of the software applications are limited across different vehicle architectures

Engineering Contradiction:

Improveportability of vehicle software applicationsVSAvoidcomplexity of platform-specific adaptations

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces WebAssembly as an intermediary layer between the vehicle software applications and the underlying electrical/electronic architecture. This mediator enables software to run portably across different architectures without direct platform-specific adaptations, while the runtime environment handles architecture-specific details

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates a universal execution environment using WebAssembly that can accommodate multiple vehicle architectures and software applications. The standardized interface and common runtime infrastructure allow the same software to function across diverse hardware platforms without modification

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If WebAssembly modules are used to provide hardware-independent execution, then portability is improved, but access to system interfaces and hardware is restricted for security reasons

Engineering Contradiction:

Improvehardware independence of software modulesVSAvoidaccess to system interfaces and hardware

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The runtime environment acts as an intermediary between WebAssembly modules and system interfaces/hardware. It provides controlled access mechanisms that maintain security isolation while enabling necessary interactions with vehicle functions and data through standardized interfaces

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent modifies the execution parameters and interface specifications to enable WebAssembly modules to access system functions. By defining specific interface contracts and access protocols, the system allows controlled hardware interaction while maintaining the security and portability benefits of WebAssembly

Inventive Principle:

Principle #35Parameter changes

3Adaptability or versatility

If standardized access interfaces are defined using interface description languages like WIT, then interoperability across different vehicle systems is improved, but the complexity of defining and implementing these interfaces increases

Engineering Contradiction:

Improveinteroperability of vehicle software applicationsVSAvoidcomplexity of interface definition and implementation

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent uses interface description languages like WIT to standardize interface definitions. By changing the parameter representation to a standardized format, the system enables automatic code generation and reduces manual implementation complexity while maintaining interoperability

Inventive Principle:

Principle #35Parameter changes

Solution Approach 2:

The interface definitions are prepared in advance using description languages, allowing code to be generated automatically before deployment. This preliminary definition phase separates interface specification from implementation, reducing overall system complexity and enabling better tooling support

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS20240354075A1Method for Providing Access From at Least One Vehicle Software Application to at Least One of Different Vehicle Systems

Publication Date: 2024.10.24 ROBERT BOSCH GMBH

AI summary

A method is for providing access from at least one vehicle software application to at least one of different vehicle systems. The vehicle systems include differently configured electrical/electronic architecture. The electrical/electronic architecture includes at least one data processing device configured to execute the at least one vehicle software application for providing functions and/or data. The electrical/electronic architecture is configured to provide further vehicle functions and/or vehicle data in addition to the functions and/or data provided by the at least one data processing device. The method includes providing the vehicle software application. The vehicle software application is configured to be executed in runtime environments of the at least one data processing device. The method also includes providing an access interface to the runtime environments for the vehicle software application. The access interface is defined by an interface description language.