Brake Motion Manager Using Actuator Type Data for Unified Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing motion managers, such as those described in JP 2020-32894 A, face challenges in handling multiple preliminary braking requests from applications, as the instruction values required differ based on the type and structure of the brake device. This necessitates heavy development burdens to match each application with the appropriate brake device mode.
Innovation Solution
A motion manager configured with one or more processors and memories, capable of receiving motion requests from applications, arbitrating these requests, and generating instruction values for a control unit based on arbitration results, using pre-stored type information of actuators to ensure compatibility across different brake device types.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the motion manager generates instruction values based on pre-stored type information of actuators, then the adaptability to different brake device types is improved, but the device complexity increases due to the need to store and manage multiple actuator type specifications
Solution Approach 1:
The motion manager is designed with a universal interface that can handle multiple actuator types through a unified request structure. The system stores type information for different actuators in advance and uses this information to generate appropriate instruction values, allowing the same motion manager hardware to support various brake device configurations without requiring separate dedicated systems for each actuator type.
Solution Approach 2:
The system manages different actuator types by storing their specific parameters (type information) in advance. When a motion request is received, the motion manager retrieves the appropriate parameters for the connected actuator type and generates instruction values based on these parameters, enabling adaptation to different actuator characteristics through parameter configuration rather than structural modification.
2Ease of manufacture
If applications are developed with unified standards, then the ease of application development is improved, but the manufacturing precision of instruction values may worsen due to the need for generic handling of diverse actuator types
Solution Approach 1:
The motion manager acts as an intermediary layer between applications and actuators. Applications send unified motion requests through this intermediary, which then translates the generic requests into precise actuator-specific instruction values by referencing stored type information. This mediator approach allows applications to maintain unified development standards while ensuring precise control for each specific actuator type.
Solution Approach 2:
The system performs preliminary actions by storing type information for all supported actuator types in advance. This pre-configured information includes the specific parameters and characteristics of each actuator type, enabling the motion manager to quickly and accurately generate appropriate instruction values without requiring real-time analysis or complex calculations when motion requests are received.
Data Source
AI summary
A motion manager that is mounted on a vehicle includes a processor and a memory. The processor receives a motion request that corresponds to an application from individual applications. The processor arbitrates the received motion request. The processor generates, based on an arbitration result, an instruction value of an operation request to be output to a brake control unit. The memory stores, in advance, type information of an actuator to be controlled by the brake control unit. The processor generates the instruction value of the operation request using the type information.