Control Unit Software Allocation Across Hardware-Specific Dependencies
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing control unit architectures face challenges in efficiently reallocating software components across different control units due to hardware-specific dependencies, requiring separate software development for each unit and limiting flexibility in shifting functionalities.
Innovation Solution
A method involving classification of software components into hardware-related and non-hardware-related classes, using an optimization algorithm to allocate these classes across multiple control units, considering resource constraints and dependencies, allowing for efficient and flexible software distribution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If separate software is developed for each control unit to ensure hardware-specific functionality, then reliability is improved, but device complexity increases and adaptability decreases
Solution Approach 1:
The software is segmented into two distinct parts: hardware-related components that are tightly coupled to specific control units, and non-hardware-related components that are portable across different control units. This segmentation allows each part to be developed and managed independently, reducing overall software complexity while maintaining hardware-specific reliability where needed.
Solution Approach 2:
Hardware-specific dependencies are extracted from the general software codebase and placed into separate hardware-related components. This extraction allows the core software functionality to be hardware-agnostic and reusable across multiple control units, while hardware-specific adaptations are isolated in dedicated components that can be selectively deployed.
2Reliability
If separate software is developed for each control unit to ensure hardware-specific functionality, then reliability is improved, but adaptability deteriorates
Solution Approach 1:
By dividing software into hardware-related and non-hardware-related components, the system enables selective reusability. Non-hardware-related components can be freely reused across different control units and even across different vehicle models, while hardware-related components are only instantiated where specific hardware is present, thus maintaining both reliability and adaptability.
Solution Approach 2:
The non-hardware-related software components are designed to be universal and can execute on any control unit regardless of specific hardware configuration. This universality allows the same software code to serve multiple functions across different hardware platforms, significantly improving software reusability and reducing development effort for new control units.
3Ease of manufacture
If hardware resources in control units are limited for cost reasons, then cost is reduced, but productivity deteriorates due to inefficient resource allocation
Solution Approach 1:
The system implements dynamic software allocation where non-hardware-related components can be flexibly assigned to different control units based on available resources and performance requirements. This dynamic approach allows optimal utilization of limited hardware resources across the control unit architecture, improving productivity without requiring additional hardware investment.
Data Source
AI summary
A method for allotting a group of software components to a control unit architecture having a plurality of interconnected control units. An executable software functionality is defined by a sequence chain for the group of software components. The method includes detecting, for each software component, a classification which is allocated to the particular software component, classification including at least one or more hardware-related classes which are allocated to software components, the functions of which are associated with hardware interfaces of at least one specific control unit, and wherein the classification includes at least one or more non-hardware-related classes which are allocated to software components, the functions of which are not associated with hardware elements of a specific control unit; detecting properties of the control unit architecture, wherein the detected properties include at least a number of control units and for each control unit the available resources.