In-Vehicle Middleware Routing Module for ECU Data Exchange
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In vehicle control systems with AUTOSAR architecture, the manual creation of API programs for data exchange between ECUs increases software development time, and changes in device connections or signal formats require significant rework, leading to inefficiencies.
Innovation Solution
An in-vehicle equipment control device with a middleware layer that includes a routing module and a treatment module, which centrally manages data exchange and processing, reducing the need for API function programs and allowing data to be sent directly between ECUs without central controller intervention.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If API programs are manually created for data exchange between ECUs, then data communication between devices is achieved, but software development time and man-hours increase significantly
Solution Approach 1:
The patent introduces a runtime environment as an intermediary layer between applications and device drivers. This runtime environment automatically manages data exchange between ECUs using predefined APIs, eliminating the need for manual API program creation. The runtime environment handles the complexity of inter-ECU communication while providing a simple interface for applications, thus resolving the contradiction between reliable data communication and reduced development time.
Solution Approach 2:
The patent creates universal API programs that can be reused across multiple ECUs and applications. Instead of creating custom API programs for each ECU pair, a set of standardized API programs is developed that can handle various data exchange scenarios. This universal approach significantly reduces software development time while maintaining reliable communication through proven, reusable code.
2Adaptability or versatility
If API programs are created for each in-vehicle equipment, then device connectivity is established, but the complexity of software development increases
Solution Approach 1:
The patent segments the software architecture into distinct layers: applications, runtime environment, and device drivers. This segmentation allows each layer to be developed and maintained independently. The runtime environment layer handles the complexity of device connectivity through standardized interfaces, while applications remain simple and focused on specific functions. This modular approach reduces overall software complexity while maintaining high adaptability.
Solution Approach 2:
The runtime environment acts as a mediator that simplifies device connectivity. Instead of applications directly managing complex ECU connections and data exchanges, the runtime environment provides standardized API programs that handle these complexities. This intermediary layer maintains high device adaptability while reducing software development complexity through automation and standardization.
3Extent of automation
If data is transmitted through the central controller, then centralized control is achieved, but communication congestion occurs and processing load increases
Solution Approach 1:
The patent segments the control architecture by enabling direct peer-to-peer communication between ECUs for local data exchanges. Not all data needs to pass through the central controller - only critical centralized control data does. This segmentation of communication paths allows high-speed local exchanges while maintaining necessary centralized control, thus resolving the contradiction between automation extent and transmission speed.
4Adaptability or versatility
If source code is changed for API calls when device connections change, then adaptability to new configurations is achieved, but software development time increases
Solution Approach 1:
The runtime environment serves as an adaptable intermediary that can be reconfigured without changing application source code. When device connections change, the runtime environment's configuration can be updated to reflect new topologies, and the same API programs continue to work. This separates configuration adaptability from code modification, eliminating rework time while maintaining configuration flexibility.
Solution Approach 2:
The patent develops universal API programs that work across multiple device configurations and topologies. These API programs are designed to be configuration-agnostic, adapting to different ECU connections through the runtime environment rather than requiring code changes. This universal design provides high configuration adaptability while eliminating software rework time when devices are added, removed, or repositioned.
Data Source
AI summary
To reduce the man-hours of software development when vehicle types are deployed, an in-vehicle equipment control device has a control unit that outputs, to actuators, control signals based on the outputs from sensor devices. The control unit includes a middleware layer and a device driver layer as software components. The middleware layer includes a routing module that selects whether the communication data output from the sensor devices is output as is or the communication data is subjected to predetermined processing and then output according to the type of the communication data, and a treatment module that performs the predetermined processing on the communication data. The routing module has a function of outputting the communication data to the device driver.