Vehicle Controller Middleware for Physical Quantity Conversion
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In hierarchical software architectures like AUTOSAR, changes in in-vehicle equipment require rewriting application code to convert physical quantities, leading to increased software development and verification man-hours.
Innovation Solution
An in-vehicle equipment controller with a middleware layer that includes a physical quantity conversion module, allowing changes in equipment characteristics to be handled by rewriting conversion rules without modifying application code, thus reducing software development man-hours.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If application code is rewritten to handle changes in in-vehicle equipment characteristics, then the system can adapt to new equipment, but software development man-hours increase
Solution Approach 1:
The patent segments the software architecture into distinct layers: application layer, device driver layer, and middleware layer. The physical quantity conversion module is isolated in the middleware layer, separating conversion logic from application code. This segmentation allows equipment characteristic changes to be handled in the middleware without requiring application code modifications, thus reducing software development man-hours while maintaining adaptability.
Solution Approach 2:
The patent introduces a middleware layer as an intermediary between the application layer and device driver layer. This middleware contains the physical quantity conversion module, acting as a mediator that handles equipment-specific conversions. When in-vehicle equipment changes, only the middleware needs to be updated, not the application code, thereby reducing development time while preserving adaptability to new equipment.
2Adaptability or versatility
If application code is modified to convert physical quantities for different equipment, then equipment compatibility is achieved, but verification man-hours increase
Solution Approach 1:
By segmenting the conversion logic into a separate middleware layer, the patent isolates equipment-specific variations from the core application code. This segmentation means that verification efforts are concentrated only in the middleware layer rather than throughout the entire application, significantly reducing verification man-hours while maintaining full equipment compatibility.
Solution Approach 2:
The middleware layer serves as an intermediary that absorbs all equipment-specific conversion variations. This intermediary approach ensures that the application layer remains equipment-agnostic, requiring verification only of the middleware's conversion capabilities rather than end-to-end verification for each equipment change, thus reducing verification time while preserving compatibility.
3Adaptability or versatility
If data in memory is recompiled to replace physical quantity data, then the system adapts to new equipment, but software development complexity increases
Solution Approach 1:
The patent segments the software architecture so that physical quantity data and conversion rules are localized in the middleware layer's memory, separate from the application layer. This segmentation means that data replacement and recompilation are confined to a small, isolated section rather than requiring full application recompilation, reducing software development complexity while maintaining system adaptability.
Solution Approach 2:
The middleware acts as an intermediary buffer between hardware-specific data representations and application-level data requirements. This intermediary structure allows physical quantity data to be stored and converted in a standardized format in the middleware, simplifying memory management and reducing the complexity of data replacement operations while preserving full adaptability to new equipment.
Data Source
AI summary
The present disclosure relates to reducing software development man-hours when vehicle models are developed. In an in-vehicle equipment controller, a control section has, as a software configuration: an application layer in which an application for in-vehicle equipment is implemented; a device driver; and a middleware layer in which a communication path is generated between the application and the device driver. The middleware layer includes a physical quantity conversion module that converts physical quantity data according to a specified conversion rule, the physical quantity data being included in data transferred through the communication path.