Actuator Fallback Control via Partitioned Local Feedback
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing actuator control systems in safety-critical vehicle steering systems lack a reliable fallback option for local control, which compromises the use of generic programming and increases the need for custom software, even when communication with the domain controller is lost.
Innovation Solution
Implementing a method and system that utilize a hypervisor to allow multiple software components to execute in parallel, with a fallback control algorithm stored in a separate partition of the actuator's memory, enabling the actuator to continue functioning in the absence of communication with the domain controller by generating a fallback actuator control signal based on predefined values or sensor data.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a domain controller architecture with generic programming is used, then actuator reuse and reduced custom software are improved, but reliability under communication failure is worsened
Solution Approach 1:
The memory is divided into a first partition containing generic actuator control software and a second partition containing fallback control software. This segmentation allows the actuator to maintain generic programming for reuse while incorporating localized fallback functionality for reliability during communication failures.
Solution Approach 2:
The fallback control algorithm is pre-stored in the second partition of the actuator's memory. When communication with the domain controller is lost, the actuator can immediately execute this pre-prepared fallback algorithm without requiring real-time computation or external input, ensuring continuous safe operation.
2Reliability
If fallback control algorithm is stored in separate partition, then reliability during communication loss is improved, but device complexity is worsened
Solution Approach 1:
The actuator controller is designed with multi-functionality by incorporating both generic actuator control and application-specific fallback control within a single device. The hypervisor enables the controller to execute different software components (generic and fallback) on the same hardware platform, reducing the need for separate dedicated fallback hardware and thereby limiting the increase in device complexity.
3Adaptability or versatility
If hypervisor is used to execute multiple software components, then adaptability and actuator reuse are improved, but device complexity is worsened
Solution Approach 1:
The hypervisor acts as an intermediary software layer that enables the execution of multiple software components (generic actuator control and application-specific fallback control) on the same hardware platform. This intermediary approach allows for software-level flexibility and adaptability without requiring complex hardware modifications or multiple separate hardware controllers.
Data Source
AI summary
A method for controlling an actuator. The method includes generating, in response to receiving a torque command signal from a first controller, an actuator control signal. The method also includes selectively controlling the actuator based on the actuator control signal. The method also includes, in response to identifying a fault associated with the first controller: generating, responsive to a determination that a partition associated with a second controller includes a fallback indicator, a fallback actuator control signal; and selectively controlling the actuator based on the fallback actuator control signal.