In-Vehicle Middleware Mapping for Flexible ECU Communication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In hierarchical software architectures like AUTOSAR, data transfer between ECUs in vehicle networks requires manual source code changes for port or signal mode changes, increasing software development man-hours.
Innovation Solution
An in-vehicle equipment control device with a control unit and storage unit, featuring an application layer, device driver, and middleware layer, utilizing rewritable mapping tables to define communication routes, allowing data exchange without application intervention, thus reducing software development time.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If data transfer is handled through application layer with manual source code changes, then communication flexibility is improved, but software development time increases
Solution Approach 1:
The patent introduces a middleware layer as an intermediary between the application layer and device driver layer. This middleware contains mapping tables that automatically route data packets between ECUs without requiring application layer intervention. When communication routes need to change, only the mapping tables in middleware need to be modified, not the application source code, thus maintaining flexibility while reducing development time.
Solution Approach 2:
The software architecture is segmented into distinct layers: application layer, middleware layer, and device driver layer. The middleware layer is further segmented into internal mapping tables (for ECU-to-ECU communication) and external mapping tables (for ECU-to-external device communication). This segmentation allows independent modification of communication routes at the middleware level without affecting other layers.
2Reliability
If dedicated applications are prepared for each data transfer scenario, then communication reliability is improved, but device complexity increases
Solution Approach 1:
The middleware layer serves as a universal component that handles all data transfer routing between ECUs and external devices. Instead of requiring separate dedicated applications for each communication scenario, the single middleware with configurable mapping tables provides multi-functional routing capabilities. This reduces software structure complexity while maintaining reliable communication through standardized routing procedures.
3Adaptability or versatility
If application layer processes all data conversion and routing, then communication versatility is improved, but processing speed decreases
Solution Approach 1:
The mapping tables in the middleware layer are pre-configured with routing information and communication protocols. When data needs to be transferred, the middleware simply looks up the pre-defined routes in the mapping tables and forwards packets accordingly, without requiring real-time processing and conversion at the application layer. This preliminary preparation of routing information significantly speeds up data transfer while maintaining versatility through configurable table entries.
Data Source
AI summary
To reduce the man-hours of software development when vehicle types are deployed an in-vehicle equipment control device includes a CPU and a memory. The CPU has an application layer, a middleware layer, and a device driver unit as software components. First communication packets on the application side and second communication packets on the device driver side are implemented in the middleware layer. The memory stores an internal mapping table that defines the connection relationships between the first communication packets and the second communication packets and an external mapping table that defines the direct communication routes between the first communication packets or the second communication packets and an in-vehicle network.