Vehicle Software Control via OS Library Bridging

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing vehicle systems face challenges in integrating applications from different operating systems without performance degradation, particularly in managing compatibility with various hardware vendors and operating system versions.

Innovation Solution

A vehicle software control device that includes a kernel to execute a first operating system, a system library, a connecting unit to link a library for a second operating system, and a first application, utilizing hardware abstraction layers and conversion units to facilitate seamless execution across different OS environments.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a vehicle system integrates applications from different operating systems, then compatibility and versatility are improved, but system complexity and performance degradation occur

Engineering Contradiction:
ImprovecompatibilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a library connection unit as an intermediary layer between applications from different operating systems and the vehicle's hardware. This unit contains conversion logic that translates system calls and library functions between different OS environments (e.g., Android, Linux, Windows), enabling compatibility without directly integrating multiple OS kernels. The intermediary handles OS-specific variations in library interfaces, system call conventions, and hardware abstraction, thereby improving versatility while containing system complexity through centralized conversion logic.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the operating system interface into modular components: a core kernel layer, a hardware abstraction layer, and OS-specific library layers. Each operating system has its own library layer that interfaces with the universal hardware abstraction layer below. This segmentation allows each OS to be independently managed and updated without affecting others, improving compatibility while organizing system complexity into manageable, isolated modules rather than a monolithic integrated system.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If multiple operating systems are integrated in a vehicle system, then adaptability is improved, but performance degradation occurs

Engineering Contradiction:
ImproveadaptabilityVSAvoidperformance
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The library connection unit acts as a performance-optimized intermediary that pre-compiles and caches conversion routines for common OS library calls. Instead of performing real-time translation of every system call, the unit maintains lookup tables and pre-processed conversion paths for frequently used functions, reducing overhead and maintaining near-native performance. The intermediary also implements intelligent routing that directs calls through the most efficient path based on the source and target OS, minimizing performance degradation while maintaining broad adaptability.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If a system supports multiple operating systems with different versions, then versatility is improved, but reliability and stability worsen

Engineering Contradiction:
ImproveversatilityVSAvoidstability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The hardware abstraction layer implements universal interfaces that remain consistent across all operating system versions and types. By defining a stable, version-agnostic hardware interface layer, the system ensures that applications running on any OS version interact with hardware through the same standardized methods. This universality isolates version-specific variations to the library connection unit, preventing them from propagating through the system and compromising stability, while still supporting broad versatility across OS versions.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP3855310B1Device for controlling software for vehicle
Publication Date: 2025.07.02 DRIMAES INC
  • EP3855310B1 patent drawingFigure 1~2
  • EP3855310B1 patent drawingFigure 3~4
  • EP3855310B1 patent drawingFigure 5~6

AI summary

Disclosed is a vehicle software control device which includes hardware, a kernel connected to the hardware and configured to execute a first operating system, a system library connected to the kernel, a first connecting unit configured to connect a library for a second operating system different from the first operating system to the system library, and a first application executed on the second operating system.