ECU Intermediate Layer for Cross-OS Binary Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing vehicle control systems face challenges in integrating ECUs with different operating systems due to memory address conflicts, resource limitations, and the need for porting work that risks intellectual property leakage, while load distribution is difficult without uniform OSs.
Innovation Solution
An electronic control device with a processor and storage device that includes an intermediate layer library, comprising a function emulator and IF conversion unit, allows the same execution binary to operate on different OSs by converting addresses and combining functions, enabling seamless integration and migration between ECUs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If source code porting is performed to enable integration of ECUs with different OSs, then adaptability is improved, but intellectual property protection deteriorates due to risk of know-how leakage
Solution Approach 1:
The patent uses binary copying instead of source code porting. The execution binary is copied and executed directly on the target ECU without modifying source code, thereby maintaining adaptability across different OSs while preventing intellectual property leakage since no source code is shared or modified.
Solution Approach 2:
The patent introduces an intermediate layer (emulation layer) between the execution binary and the host OS. This intermediary layer translates OS-specific calls into standardized interfaces, enabling the same binary to run on different OSs without exposing source code, thus protecting IP while maintaining versatility.
2Adaptability or versatility
If compilers are used for porting work to convert source code to command code, then adaptability is improved, but reliability deteriorates due to need for retesting after recompilation
Solution Approach 1:
The patent copies the execution binary directly without using compilers. This eliminates the recompilation process that requires retesting, thereby maintaining reliability while still enabling adaptation to different ECUs through the intermediate layer.
Solution Approach 2:
The patent performs preliminary translation of the binary into a standardized intermediate format during the build process, so that no retesting is needed when deploying to different ECUs. The intermediate layer is pre-configured to handle OS-specific variations.
3Reliability
If fixed memory addresses are used for program operation, then reliability is improved, but adaptability deteriorates when integrating multiple binaries
Solution Approach 1:
The patent introduces an intermediate layer that acts as a mediator between the binary and the memory system. This layer handles memory address translation and allocation, allowing multiple binaries to coexist with fixed addresses while maintaining adaptability across different ECUs.
Solution Approach 2:
The patent adds an intermediate translation dimension between the binary's address space and the physical memory address space. This allows binaries to use fixed virtual addresses for reliability while the intermediate layer maps these to appropriate physical addresses, enabling multi-binary integration.
4Adaptability or versatility
If ECUs with different OSs are integrated, then adaptability is improved, but device complexity increases due to memory address conflicts and resource limitations
Solution Approach 1:
The patent introduces an intermediate layer as a mediator that handles OS-specific variations and memory address conflicts. This intermediary abstraction allows multiple ECUs with different OSs to be integrated without increasing visible complexity, as the intermediate layer manages the underlying differences.
Solution Approach 2:
The patent segments the system into three independent parts: the execution binary, the intermediate layer, and the host OS. This segmentation allows each component to be developed and optimized separately, reducing overall system complexity while maintaining adaptability across different ECUs.
Data Source
AI summary
An electronic control device, wherein the operating system includes a host OS library in which a function to be called is recorded during execution of the program, wherein the program includes executable command code and a common IF unit in which a jump destination of a function called by the program is recorded, wherein the intermediate layer library includes an emulation unit including a function emulator that implements another function by combining functions stored in the host OS library, and an IF conversion unit that converts an address for the common IF unit to call the emulation unit and the host OS library, and wherein the operating system, the intermediate layer library, and the program are introduced to the electronic control device separately.