Resource utilization of vehicle electronic control units in vehicle control processes

Abstract

Examples described herein provide a method with electronic control unit resource monitoring and time domain adaptation during vehicle control. The method includes receiving data from sensors of a vehicle. The method also includes determining a reference trajectory and a control time domain of the vehicle. The method further includes partitioning a discretization step into a plurality of steps. The method further includes converting a continuous-time dynamic model to a discrete-time dynamic model for one of the plurality of steps. The method also includes iterating over the plurality of steps to generate a discretized dynamic model of the discretization step. The method also includes using the discretized dynamic model in a model predictive controller to generate a desired steering command for the vehicle. The method also includes controlling the vehicle using the desired steering command generated by the model predictive controller using the discretized matrix.

Description

Technical Field

[0001] This topic relates to vehicles, and specifically to the utilization of vehicle electronic control unit resources during vehicle control. Background Technology

[0002] Modern vehicles (e.g., cars, motorcycles, boats, or any other type of vehicle) may be equipped with one or more cameras that provide reversing assistance, capture images of the vehicle's driver to determine driver drowsiness or attention, provide images of the road while the vehicle is in motion for collision avoidance purposes, provide structure recognition (e.g., road signs, etc.), and include combinations and / or multiple of these. For example, a vehicle may be equipped with multiple cameras, and images from multiple cameras (referred to as "surround view cameras") can be used to create a "surround" or "bird's-eye view" view of the vehicle. Some of the cameras (referred to as "remote cameras") may be used to capture remote images (e.g., object detection for collision avoidance, structure recognition, etc.).

[0003] Such vehicles can also be equipped with sensors for perception tasks, such as radio radar equipment, lidar (Light Detection and Ranging) equipment, and / or the like. Radio radar (radio detection and ranging) is a technology that uses radio waves to detect and determine the distance, velocity, and angle of objects. Radio radar works by transmitting radio signals that bounce off an object and return to the radio radar system, where the reflected waves are analyzed based on the amount of time and frequency changes between transmission and reception. The measured time can be used to determine the distance between the radio radar equipment and the detected object, while the measured frequency changes in the carrier wave can be used to determine the velocity difference using the Doppler effect, which can be used when performing perception tasks.

[0004] Perception tasks can include one or more of object detection, classification, tracking, lane detection, road sign recognition, and obstacle avoidance. Perception tasks are particularly useful for autonomous or semi-autonomous vehicles to provide the vehicle with real-time awareness of its environment to make safe and informed driving decisions. Images from one or more cameras on the vehicle can also be used to detect objects, track targets, etc., including combinations and / or multiple of these. Perception tasks are useful for implementing advanced driver assistance systems (ADAS).

[0005] The desire to use ADAS for precise vehicle control is important for the effective operation of vehicles. Summary of the Invention

[0006] In one embodiment, a computer-implemented method is provided for monitoring electronic control unit resources and time-domain adaptation during vehicle control. The method includes receiving data from the vehicle's sensors. The method also includes determining a reference trajectory and control time domain for the vehicle. The method further includes dividing a discretized step size into a plurality of steps. The method further includes converting a continuous-time dynamic model into a discrete-time dynamic model for one of the plurality of steps. The method also includes iterating over the plurality of steps to generate a discretized dynamic model for the discretized step sizes. The method further includes using the discretized dynamic model in a model predictive controller to generate desired steering commands for the vehicle. The method also includes controlling the vehicle using the desired steering commands generated by the model predictive controller using a discretized matrix.

[0007] In addition to one or more features described herein, or as an alternative, other implementations of the method may include dynamically adjusting the control time domain based on the available computing resources of the vehicle's electronic control unit.

[0008] In addition to one or more of the features described herein, or as an alternative, other implementations of the method may include: dynamically adjusting the prediction time domain and the control time domain, including monitoring central processing unit utilization and task execution time.

[0009] In addition to one or more of the features described herein, or as an alternative, further implementations of the method may include using scaling and squaring methods to generate the discretized dynamic model for the discretization step size.

[0010] In addition to one or more of the features described herein, or as an alternative, other implementations of the method may include performing the discretization step size into multiple step sizes using the following equation:

[0011]

[0012] Where h is the time period of one of the multiple step sizes, T is the total time period of a discretized step size, and N is an integer.

[0013] In addition to one or more of the features described herein, or as an alternative, other implementations of the method may include using a bilinear transformation to generate a transformation from a continuous-time dynamic model to a discrete-time dynamic model for one of the plurality of step sizes.

[0014] In addition to one or more of the features described herein, or as an alternative, other implementations of the method may include performing the continuous-to-discrete transformation by discretizing the following equation for each of a plurality of step sizes h:

[0015]

[0016] Where x is the state vector. A is the derivative of the state vector x with respect to time t. c It is a continuous-time system matrix, B c It is a continuous-time input matrix, and u is an input vector.

[0017] In addition to one or more of the features described herein, or as an alternative, further implementations of the method may include: converting the continuous-time dynamic model into a discrete-time dynamic model to obtain the following equation:

[0018] x(k+1)=A d x(k)+B d u(k)

[0019] Where k is the discrete-time exponent, A d It is the discretized system matrix using bilinear transformation, and B d It is a discretized input matrix using a bilinear transformation.

[0020] In addition to one or more of the features described herein, or as an alternative, another implementation of the method may include performing a second iteration k+2 of the discretization process according to the following equation:

[0021] x(k+2)=A d x(k+1)+B d u(k)=(A d ) 2 x(k)+(A d +I)B d u(k)

[0022] Where I is the identity matrix.

[0023] In addition to one or more of the features described herein, or as an alternative, another implementation of the method may include performing a third iteration k+4 of the discretization process according to the following equation:

[0024] x(k+4)=(A d ) 2 x(k+2)+(A d +I)B d u(k)=(A d ) 4 x(k)+

[0025] ((A d ) 2 +I)(A d +I)Bd u(k).

[0026] In addition to one or more of the features described herein, or as an alternative, another implementation of the method may include performing a fourth iteration k+8 of the discretization process according to the following equation:

[0027] x(k+8)=(A d ) 4 x(k+4)+((A d ) 2 +I)(A d +I)B d u(k) =

[0028] (A d ) 8 x(k)+((A d ) 4 +I)((A d ) 2 +I)(A d +I)B d u(k).

[0029] In another embodiment, a vehicle is provided. The vehicle includes sensors, vehicle facilities, and a processing system, the processing system including a memory having computer-readable instructions and processing means for executing the computer-readable instructions. The computer-readable instructions control the processing system to perform operations related to the utilization of electronic control unit resources during vehicle control. The operations include receiving data from the vehicle's sensors. The operations also include determining a reference trajectory and a control time domain for the vehicle. The operations further include dividing a discretization step into a plurality of steps. The operations further include converting a continuous-time dynamic model into a discrete-time dynamic model for one of the plurality of steps. The operations also include iterating over the plurality of steps to generate a discretized dynamic model for the discretized step. The operations further include using the discretized dynamic model in a model predictive controller to generate a desired steering command for the vehicle. The operations also include causing the vehicle facilities to control the vehicle using the desired steering command generated by the model predictive controller using the discretized matrix.

[0030] In addition to one or more features described herein, or as an alternative, other embodiments of the vehicle may include: the operation further includes dynamically adjusting the control time domain based on the available computing resources of the vehicle's electronic control unit.

[0031] In addition to one or more of the features described herein, or as an alternative, other implementations of the vehicle may include dynamically adjusting the prediction and control time domain, including monitoring central processing unit utilization and task execution time.

[0032] In addition to one or more of the features described herein, or as an alternative, other implementations of the vehicle may include a discretized dynamic model with a discretized step size generated using a scaling and square method.

[0033] In addition to one or more of the features described herein, or as an alternative, other implementations of the vehicle may include: using a bilinear transformation to generate a transformation from a continuous-time dynamic model to a discrete-time dynamic model for one of a plurality of steps.

[0034] In another embodiment, a computer program product is provided. The computer program product includes a set of one or more computer-readable storage media and program instructions, which are collectively stored in the set of one or more storage media, for causing a processor group to perform computer operations for electronic control unit (ECU) resource utilization when controlling a vehicle. The operations include initiating a prediction and control time domain using nominal values. The operations also include monitoring ECU resources. The operations further include determining whether the rate of change of task execution at the ECU exceeds a first threshold. The operations also include determining whether the rate of change of CPU utilization at the ECU exceeds a second threshold. The operations also include detecting whether CPU task overrun exists at the ECU. The operations further include, in response to determining that the rate of change of task execution exceeds the first threshold, the rate of change of CPU utilization exceeds the second threshold, or that CPU task overrun exists, reducing the prediction time domain and the control time domain to generate a reduced prediction time domain and control time domain. The operations also include determining whether the reduced prediction and control time domain is below a minimum acceptable threshold. The operations further include: continuing control operations in response to determining that the reduced prediction and control time domain is not below the minimum acceptable threshold. The operation further includes: requesting an upgrade in response to determining that the reduced prediction and control time domain is not lower than the minimum acceptable threshold.

[0035] In addition to one or more of the features described herein, or as an alternative, other implementations of the computer program product may include: reducing the prediction time domain and the control time domain by reducing the prediction time domain and the control time domain by a predefined step size to generate a reduced prediction time domain and the control time domain.

[0036] In addition to one or more of the features described herein, or as an alternative, other implementations of the computer program product may include: requesting an upgrade including generating an alarm to the vehicle operator indicating that manual intervention is required.

[0037] In addition to one or more features described herein, or as an alternative, other implementations of the computer program product may include: requesting an upgrade to include implementing an alternative control strategy to control the vehicle.

[0038] The above-described features and advantages, as well as other features and advantages, of this disclosure will become apparent when taken in conjunction with the accompanying drawings and the following detailed description. Attached Figure Description

[0039] Other features, advantages, and details appear by way of example only in the following detailed description, which is described in detail with reference to the accompanying drawings, wherein:

[0040] Figure 1A A vehicle with a processing system, sensors, and vehicle facilities according to one or more embodiments is shown;

[0041] Figure 1B The illustration shows one or more embodiments. Figure 1A The processing system;

[0042] Figure 2 A block diagram of an ADAS controller according to one or more embodiments is shown. This ADAS controller is responsible for processing various inputs and generating control commands to manage the operation of the vehicle of FIG1.

[0043] Figure 3 A flowchart is shown of a method for vehicle control based on model predictive control using a multi-step online discretization strategy on an electronic control unit (ECU) during vehicle control, according to one or more embodiments.

[0044] Figure 4 A flowchart is shown, according to one or more embodiments, of a method for monitoring and adapting electronic control unit resource utilization and control time domain using a feedback mechanism during vehicle control; and

[0045] Figure 5 A block diagram of a scene-based engagement processing system for a model prediction controller for controlling a vehicle, according to one or more embodiments, is shown. Detailed Implementation

[0046] The following description is exemplary in nature only and is not intended to limit this disclosure, its application, or use. It should be understood that throughout the drawings, corresponding reference numerals denote the same or corresponding parts and features. As used herein, the term "module" refers to processing circuitry that may include application-specific integrated circuits (ASICs), electronic circuitry, processor (shared, dedicated, or group) and memory executing one or more software or firmware programs, combinational logic circuitry, and / or other suitable components that provide the described functionality.

[0047] As used herein, the term “controller” (e.g., a charging controller as further described herein) refers to a dedicated controller that includes a processor and memory, a general-purpose controller that includes control modules configured to formulate control processes using the dedicated controller, a network of multiple different controllers that communicate with each other and each includes a processor and memory and are configured to cooperate in implementing control processes, and any similar configuration for implementing control processes.

[0048] One or more embodiments described herein relate to the utilization of vehicle electronic control unit resources during vehicle control.

[0049] Vehicles can use advanced driver assistance systems (ADAS) to improve vehicle performance and enhance driving comfort by providing automation, adaptation, or enhancement of vehicle systems to offer better awareness, decision-making, and control.

[0050] An example of ADAS is Adaptive Cruise Control (ACC), which automatically adjusts the vehicle's speed to maintain a safe following distance from the vehicle directly in front. Another example of ADAS is Automatic Lane Change (ALC), which enables the vehicle to perform lane changes. Yet another example of ADAS is Forward Collision Alert (FCA), which generates a warning to the vehicle's operator of a potential forward collision. Another example of ADAS is Collision Emergency Braking (CIB), which applies the vehicle's brakes to reduce its speed. A further example of ADAS is Automatic Evasive Steering (AES), which adjusts the vehicle's trajectory.

[0051] ADAS typically utilizes various sensors, including cameras, radio radar devices, and / or lidar devices, to perform perception tasks such as object detection, classification, tracking, lane detection, road sign recognition, and obstacle avoidance. Data collected from these sensors enables vehicles to make real-time decisions, thereby improving the overall driving experience and safety. Despite advancements in ADAS, precise vehicle control remains a significant challenge. The computational demands of model predictive control (MPC) algorithms, commonly used in ADAS for motion planning and control, can be substantial. These algorithms require significant processing power to discretize continuous-time dynamics models and generate control commands in real time. In resource-constrained environments, such as those using embedded electronic control units (ECUs) for ADAS and / or MPC, often found in vehicles, meeting these computational demands can be difficult, leading to potential latency, task overruns, and suboptimal control performance.

[0052] Existing solutions for vehicle control using MPC in ADAS often conflict with high computational requirements, especially in embedded systems with limited processing power. Existing discretization methods may be insufficient to effectively handle the real-time demands of vehicle control, leading to increased ECU throughput and potential task overruns. Furthermore, the lack of feedback mechanisms to adjust control strategies based on available ECU resources can result in interruptions in control operations and reduced system reliability.

[0053] One or more embodiments described herein address these and other drawbacks by providing a fast, efficient, and accurate model predictive control strategy for embedded applications in autonomous driving. Such embodiments introduce a novel plant modeling strategy that fits the model predictive controller within the constraints of the embedded ECU. By employing multi-step discretization of the plant model, one or more embodiments reduce the computational requirements of the MPC algorithm, enabling real-time execution in resource-constrained environments. Furthermore, a feedback mechanism between the ECU resource monitor and the ADAS control strategy can be implemented to provide uninterrupted operation by dynamically adjusting the control and prediction time domains based on available resources. This real-time adaptation helps avoid task overruns and infeasible solutions, enhancing the overall performance and reliability of the vehicle control system.

[0054] Figure 1A A vehicle 100, having a processing system 102, sensors 104, and vehicle facilities 106, is shown according to one or more embodiments. The vehicle 100 may be a car, truck, van, bus, motorcycle, boat, or any other type of vehicle. According to one embodiment, the vehicle 100 is a hybrid electric vehicle, such as a plug-in hybrid electric vehicle (PHEV) that is partially or fully powered by electricity. According to another embodiment, the vehicle 100 is an electric vehicle powered by electricity. A battery (not shown) is used to provide power to components of the vehicle 100, such as an electric motor (not shown), electrical components (not shown), etc., including combinations thereof and / or multiples thereof. According to one or more embodiments, the vehicle 100 includes an internal combustion engine (not shown) that provides electrical and / or mechanical energy for providing propulsion to the vehicle 100. According to one or more embodiments, the vehicle 100 is an autonomous or semi-autonomous vehicle. An autonomous vehicle is a vehicle with autonomous driving capabilities. A semi-autonomous vehicle is a vehicle with some autonomous features (e.g., self-parking, lane keeping, etc.) but lacks fully autonomous control.

[0055] The processing system 102 is located within the vehicle and is responsible for managing and processing the data collected by sensors 104. Sensor 104 refers to one or more sensors, which can vary in type. Sensor 104 can be any suitable sensor and / or combination of sensors, such as cameras, radio radar devices, lidar devices, proximity sensors, etc., including combinations thereof and / or multiples thereof. An arrow between sensor 104 and processing system 102 indicates the data flow from sensor 104 to processing system 102, highlighting the interaction between these components. This setup enables vehicle 100 to use the data collected by sensor 104 to perform perception tasks, which can be used for, for example, autonomous driving. According to one or more embodiments, processing system 102 can be used to implement active safety features (e.g., ADAS) and to control vehicle 100 using vehicle plant 106. Vehicle plant 106 is a collection of electromechanical components and subsystems within vehicle 100 responsible for executing control commands and performing physical actions. This includes, but is not limited to, actuators, sensors, and control modules that manage various aspects of the operation of vehicle 100, such as steering, braking, acceleration, and stability control. The controlled vehicle 106 interacts with the processing system 102 to receive control signals generated by the processing system 102 and converts these signals into precise mechanical movements and adjustments for controlling the vehicle 100. This integration ensures that the vehicle 100 can respond accurately and effectively to dynamic driving conditions, thereby enhancing the overall performance, reliability, and efficiency of the vehicle 100.

[0056] Now for reference Figure 1B Further features and functions of the processing system 102, sensor 104, and vehicle controlled object 106 are described.

[0057] In particular, Figure 1B An illustration is provided according to one or more embodiments. Figure 1A The processing system 102. According to one or more embodiments, the processing system 102 includes a processing device 110, a memory 112, and an ADAS control engine 120. It should be understood that the processing system 102 can be any device suitable for ADAS and / or performing model predictive control for controlling a vehicle. For example, the processing system 102 can be a device implemented in or otherwise associated with vehicle 100, such as an electronic control unit (ECU) (also referred to as an electronic control module). As another example, the processing system 102 can be a smartphone, tablet computer, laptop computer, desktop computer, wearable computing device, etc., including combinations and / or multiples thereof. As yet another example, the processing system 102 can be... Figure 5 The processing system 500 and / or may include Figure 5 One or more components of the processing system 500.

[0058] Processing device 110 is responsible for executing instructions and managing the overall operation of processing system 102. Processing device 110 can be any suitable processing circuitry used for executing instructions and processing data. For example, processing device 110 can be a microcontroller, microprocessor, application-specific integrated circuit (ASIC), or any other type of processing unit capable of handling the computational needs of processing system 102. Processing device 110 is Figure 5 Examples of one or more of the processing devices 521 are described in more detail herein.

[0059] Memory 112 stores data (e.g., data 105), computer-readable instructions, and algorithms useful for the operation of processing system 102. This may include real-time data processing, historical data analysis, and storage of firmware or software programs. Memory 112 is any suitable device for storing data (such as data 105 received from sensor 104) and / or instructions. For example, memory 112 may be a combination of volatile memory (e.g., random access memory) and non-volatile memory (e.g., read-only memory, flash memory). Memory 112 is Figure 5 Examples of one or more of system memory 522, random access memory 523, and / or read-only memory 524 are described in more detail herein.

[0060] Processing system 102 receives data 105 (from sensor 104) regarding vehicle 100 (e.g., telemetry data about the vehicle) and / or the environment in which the vehicle is operating (e.g., images of objects in the environment, point cloud data of objects in the environment, etc.). According to one or more embodiments, data 105 may be an image of the lane in which vehicle 100 is traveling, including any lane markings (e.g., lane lines, turn indicators, etc.). Data 105 may be useful, for example, for performing perception tasks, which in turn are used to control the vehicle using ADAS.

[0061] The ADAS control engine 120 is responsible for managing and executing advanced driver assistance system functions. The ADAS control engine 120 is designed to enhance vehicle performance and efficiency by automating, adapting, and / or augmenting various vehicle systems to provide better perception, decision-making, and control.

[0062] ADAS control engine 120 processes data (e.g., data 105) received from various sensors (e.g., sensor 104) (e.g., cameras, radio radar devices, and lidar devices) to perform perception tasks, including object detection, classification, tracking, lane detection, road sign recognition, and obstacle avoidance. By analyzing this sensor data, ADAS control engine 120 can generate real-time situational awareness of the environment in which vehicle 100 operates.

[0063] One of the functions of the ADAS control engine 120 is to implement the MPC algorithm for motion planning and control. The ADAS control engine 120 uses data (e.g., data 105) from sensors (e.g., sensor 104) to predict the future state of the vehicle 100 and optimize control inputs to achieve the desired trajectory. This involves calculating optimal steering, acceleration, and braking commands to ensure that the vehicle 100 follows the planned path while maintaining operational efficiency, reliability, and comfort.

[0064] The ADAS control engine 120 also includes mechanisms for adapting control parameters in real time based on the available computing resources of the processing system 102, which may be or includes an ECU. This includes dynamically adjusting the predictive and control horizons to avoid task overruns and ensure uninterrupted operation. The ADAS control engine 120 monitors various resource metrics, such as CPU utilization and task execution time, and adjusts the ADAS control strategy accordingly to maintain optimal performance of the processing system 102 (e.g., the ECU).

[0065] The ADAS control engine 120 controls the vehicle 100 by sending commands to the vehicle controlled object 106, which includes electromechanical components and subsystems responsible for executing these commands. Commands from the ADAS control engine 120 may include steering angle, acceleration, and braking commands, among others. The ADAS control engine 120 dynamically adjusts these commands based on current driving conditions and available ECU resources to ensure the vehicle 100 operates effectively. The commands are then sent to the vehicle devices 106, where actuators and control modules translate them into physical actions, such as turning the steering wheel, applying the brakes, or adjusting the throttle. This seamless integration between the ADAS control engine 120 and the vehicle controlled object 106 enables the vehicle 100 to respond quickly and accurately to dynamic driving environments, thereby enhancing the overall performance and operation of the vehicle 100.

[0066] In summary, the ADAS control engine 120 is a complex module within the processing system 102 that integrates sensor data processing, perception tasks, and model predictive control to enhance vehicle efficiency and performance. The ADAS control engine 120 also ensures real-time and accurate control of the vehicle 100 by dynamically adapting to resource constraints and optimizing control inputs based on current driving conditions.

[0067] Figure 2A block diagram of an ADAS controller 200 according to one or more embodiments is shown, which is responsible for processing various inputs and generating control commands to manage the operation of vehicle 100. The ADAS controller 200 is one possible implementation of the ADAS control engine 120, but modifications may be made in other embodiments. The ADAS controller 200 is designed to enhance vehicle performance and operation by automating, adapting, or enhancing various vehicle systems.

[0068] Figure 2 The diagram is divided into several functional blocks, each representing a different stage of data processing and control within the ADAS controller 200. The input 202 block represents various inputs received by the ADAS controller 200, including data from one or more sensors (e.g., sensor 104), such as cameras, radio radar, lidar, and other relevant sources that provide real-time information about the vehicle's environment and driver actions.

[0069] Box 210 represents preprocessing, which may include several sub-components responsible for processing different types of driver input and environmental data (e.g., input 202). For example, processing driver pedal input 220 (e.g., processing input from the driver's pedal actions), processing driver steering input 222 (e.g., processing input from the driver's steering actions), processing turn switch input 224 (e.g., processing input from a turn signal switch), processing driver attention state 226 (e.g., monitoring and processing the driver's attention state), vehicle path prediction 228 (e.g., predicting the vehicle's path based on current inputs and conditions), object fusion 230 (e.g., fusing data from multiple sensors and tracking objects around the vehicle), and lane fusion 232 (e.g., fusing data to detect and track lane markings).

[0070] Box 212 represents motion planning, which may include components for planning the tasks of vehicle 100 based on processed inputs (from box 210). More specifically, motion planning in box 212 may include processing activation conditions 234 (e.g., determining whether conditions are suitable for enabling ADAS), generating an obstacle mesh 236 (e.g., creating a mesh map of obstacles around the vehicle), and generating super cruise and / or assisted evasive steering (AES) trajectories 238 (e.g., generating trajectories for super cruise and / or AES).

[0071] Box 214 represents MPC-based control. Specifically, this box focuses on model predictive control and includes the controlled object model and real-time discretization 240 (e.g., modeling the vehicle's dynamics and discretizing them in real-time or near real-time for MPC); input / output weights, references, and constraints 242 (e.g., defining weights, references, and constraints for MPC optimization); a real-time predictive and control time-domain modifier 244 (e.g., defining and / or adjusting the predictive and control time domain based on the available resources of the processing system 102 (e.g., ECU); and MPC optimization and desired steering commands 246 (e.g., optimizing control inputs and generating desired steering commands).

[0072] Box 216 represents a resource feedback mechanism for monitoring ECU resources (e.g., processing system 102) and includes an ECU resource monitor 248 (e.g., monitoring the overall resource usage of processing system 102 (e.g., ECU)) and an ECU task execution monitor 250 (e.g., monitoring the execution of tasks within processing system 102 (e.g., ECU)).

[0073] Box 218 provides vehicle control, which includes the final stages of command processing and vehicle operation monitoring, including command processing 252 (e.g., processing optimized control commands and generating actuator commands for execution), safety monitoring 254 (e.g., monitoring the safety of control commands / actions), and escalation requests 256 (e.g., generating an escalation request if the control action cannot be safely executed). Output from ADAS controller 200 is sent to vehicle equipment 106, which includes actuators responsible for steering, braking, and propulsion. Additionally, ADAS controller 200 can provide information to the operator of vehicle 100 via a human-machine interface (HMI) provided through display 108 to provide feedback to the operator.

[0074] In general, Figure 2 An overview of the ADAS controller 200 is provided, detailing the data flow at each stage from initial sensor input to processing, motion planning, model predictive control, resource monitoring, and final command execution to ensure optimized and efficient operation of the vehicle 100.

[0075] Figure 3 A flowchart illustrating an MPC-based vehicle control method 300 using a multi-step online discretization strategy on an electronic control unit during vehicle control, according to one or more embodiments, is shown. Method 300 can be implemented using any suitable system or device. For example, method 300 and its real-time discretization method can be used... Figure 1A and 1B The processing system 102, through Figure 5 The processing system 500, etc., is used for implementation, including combinations thereof and / or multiple thereof. Now refer to... Figure 1A , Figure 1B and Figure 2 The method 300 is described by at least some of its parts, but is not limited thereto.

[0076] Block 302 initiates method 300 by receiving data (e.g., data 105) from sensors (e.g., sensor 104) of the vehicle (e.g., vehicle 100). The sensors can be any suitable sensors, such as cameras, radio radar devices, lidar devices, or combinations thereof. The data received from the sensors provides real-time (or near real-time) information about the vehicle's environment, driver actions, etc., including combinations and / or multiple of these. This data is used to perform perception tasks for controlling the vehicle using ADAS. For example, processing system 102 manages and processes the data received from sensor 104. Data 105 from sensor 104 may include an image of the lane in which vehicle 100 is traveling, including any lane markings, objects in the environment, and other relevant information.

[0077] Box 304 relates to determining a reference trajectory and control time domain for vehicle 100 given a discretization step size (e.g., a multiple of the predicted future discretization step size). The trajectory is the planned path that vehicle 100 will follow, determined based on data received from sensor 104 and processed by ADAS control engine 120. The control time domain refers to a future time span in which MPC-based control (…) Figure 2 (Box 214) Optimizes the control input for vehicle 100.

[0078] Box 306 relates to segmenting a single discretization step size into multiple step sizes to facilitate the MPC optimization process. This segmentation allows for MPC-based control (…). Figure 2 The box 214) yields an accurate discretized dynamic model, which is useful for generating precise control commands. By decomposing the typically large discretization step size into smaller steps, MPC-based control (… Figure 2 Box 214) can iteratively compute the optimal control input in the control time domain based on the precisely discretized dynamics of each discretization step. This is calculated iteratively based on the discretized dynamics model of these smaller step sizes, thereby ensuring real-time performance and accuracy. For example, multiple steps can be determined as follows:

[0079]

[0080] Where h is the time period of one of the multiple step sizes, T is the total time period of a discretized step size, and N is an integer.

[0081] Box 307 relates to converting a continuous-time dynamic model into a discrete-time dynamic model (e.g., h) for one of a plurality of steps from Box 306. To characterize the dynamic model, the state vector represents the current state of vehicle 100, including variables such as position, velocity, and orientation. A continuous-time dynamic model refers to how the rate of change of state is affected by the current state and system inputs, while a similar discrete-time dynamic model refers to how the next state is affected by the current state and current inputs.

[0082] An example of performing a continuous-to-discrete (C2D) transformation is now described. The C2D transformation is performed by discretizing the following continuous-time dynamic model for each step h across multiple step sizes:

[0083]

[0084] Where x is the state vector. A is the derivative of the state vector with respect to time t. c It is a continuous-time system matrix, B c Let be a continuous-time input matrix and be an input vector. Performing the C2D transformation results in the following discrete-time dynamics:

[0085] x(k+1)=A d x(k)+B d u(k)

[0086] Where k is the discrete-time index (e.g., x(k) refers to x(t) at time t = k × h), A d It is the discretized system matrix, and B d It is a discretized input matrix.

[0087] In this embodiment, the bilinear transform (BT) (also known as the (1,1)-Pade approximation) is used to perform the C2D transformation; however, in other embodiments, other suitable techniques can be used to perform the C2D transformation, such as backward Euler integration, forward Euler integration, Taylor series, etc., including combinations thereof and / or multiple thereof. Although various discretization methods can be used, the bilinear transform offers advantages over existing methods because it works well at all speeds, the step size does not need to be very small due to cubic accuracy, and pre-computation can be used to improve efficiency.

[0088] According to one or more embodiments, a bilinear transformation is used to perform C2D conversion based on the following equation:

[0089]

[0090] in The following is one implementation plan: A d Using bilinear transformation, and The following is one implementation plan: B d Use bilinear transformation. For example, discretization using bilinear transformation significantly improves model accuracy (e.g., by more than two orders of magnitude), thereby improving MPC performance in real time (or near real time).

[0091] Box 308 relates to generating a discretized dynamic model (e.g., T) for a discretization step size. By iteratively propagating the discretized dynamic model characteristics from each of the multiple step sizes in Box 307, the discretized dynamic model characteristics can be transformed into a discrete-time representation of the vehicle's continuous-time dynamic model for each of the multiple step sizes in Box 307. This is more suitable for real-time computation on resource-constrained embedded ECUs. The discretized dynamic model is obtained using the "scaling and squaring" method, described in more detail herein. In this method, iterations at Box 308 are performed by doubling the step size of the next step (e.g., 1, 2, 4, 8, 16, ..., 2). N It should be understood that the step size is doubled but the matrix is ​​squared, which is why this method is called the "scaling and squaring" method.

[0092] Discretization of a single discretization step is performed iteratively N times (e.g., 2). N In a process known as "scaling and squaring," one or more steps following the C2D transformation are performed within a single step out of a plurality of steps. In the first iteration, for k+1, discretization is performed according to the aforementioned C2D transformation equation:

[0093] x(k+1)=A d x(k)+B d u(k)

[0094] For the second iteration, for k+2, discretization is performed according to the following equation:

[0095] x(k+2)=A d x(k+1)+B d u(k)=(A d ) 2 x(k)+(A d +I)B d u(k)

[0096] Where I is the identity matrix.

[0097] For the third iteration, for k+4, discretization is performed according to the following equation:

[0098] x(k+4)=(A d ) 2 x(k+2)+(A d +I)B d u(k)

[0099] =(A d ) 4 x(k)+((A d ) 2 +I)(A d +I)B d u(k)

[0100] For the fourth iteration, discretization is performed for k+8 according to the following equation:

[0101] x(k+8)=(A d ) 4 x(k+4)+((A d ) 2 +I)(A d +I)B d u(k)

[0102] =(A d ) 8 x(k)+((A d ) 4 +I)((A d ) 2 +I)(A d +I)B d u(k)

[0103] Therefore, using this method, from to The number of iterations is significantly reduced. As an example, consider the following pseudocode describing the process:

[0104] For k = 1: N

[0105] B d =(A d +I)B d

[0106] A d =A d A d

[0107] According to one or more embodiments, a system matrix A for a continuous-time physical system cThe block upper triangular matrix (e.g., with all elements in the lower left corner of the matrix being zero) can be made so by appropriately defining the state vectors (e.g., typically in the order of position, velocity, acceleration, etc.). This property is preserved in the corresponding system matrix A. d This is used for discretizing dynamic models and matrix squaring. Therefore, in the matrix squaring process described in this paper, it is used to update the non-zero elements of the matrix without updating the "zero" elements in the lower left corner, since the true result is known beforehand. Furthermore, when updating these non-zero elements, the addition and multiplication operations on these "zero" elements can be skipped. This improves the efficiency and accuracy of iterative discretization by not expending ECU computational resources on zero elements (the computer representation of zero has some potential machine error).

[0108] Continue to refer to Figure 3 Box 310 relates to using a discretized dynamic model to generate desired steering commands for the vehicle. The MPC optimization process uses the discretized dynamic model to calculate the optimal steering angle, acceleration, and braking commands for the vehicle 100 to follow the planned trajectory. The desired steering commands are generated based on the predicted future state of the vehicle 100 and a cost function with predetermined weights, references, and constraints. The ADAS control engine 120 processes these commands and sends them to the vehicle controlled object 106, which includes actuators responsible for performing the control actions.

[0109] Box 312 relates to controlling the vehicle using desired steering commands generated using a discretized matrix. The ADAS control engine 120 sends optimized control commands to the vehicle equipment 106, where actuators and control modules translate them into physical actions, such as turning the steering wheel, applying the brakes, adjusting the throttle, etc., including combinations and / or multiple of these. The vehicle equipment 106 executes these commands to ensure the vehicle 100 follows a planned trajectory while maintaining operational efficiency, reliability, and comfort. The ADAS control engine 120 continuously monitors the performance of the vehicle 100 and available ECU resources, dynamically adjusting control strategies to avoid exceeding limits and ensure uninterrupted operation.

[0110] Additional processes may also be included, and it should be understood that... Figure 3 The processes described herein are illustrative, and other processes may be added, or existing processes may be removed, modified, or rearranged without departing from the scope of this disclosure. It should also be understood that... Figure 3 The process described herein can be implemented as programming instructions stored on a non-transitory computer-readable storage medium, when executed by a computing system (e.g., Figure 1A and 1B Processing system 102 Figure 5Processing systems 500, etc., including combinations thereof and / or multiple thereof) of processors (e.g., Figure 1B Processing equipment 110 Figure 5 When a processor 521, etc., including combinations thereof and / or multiple thereof, is executed, the processor performs the process described herein.

[0111] Figure 4 A flowchart is shown of a method 400 for monitoring ECU resource utilization and control horizon adaptation during vehicle control using a feedback mechanism, according to one or more embodiments. Method 400 can be implemented using any suitable system or device. For example, method 400 and its steps can be implemented using... Figure 1A and 1B The processing system 102 is composed of Figure 5 The method is implemented using a processing system 500, etc. (including combinations thereof and / or multiple thereof). Method 400 provides efficient and reliable operation of vehicle 100 by dynamically adjusting the predictive and control time domains for autonomous and / or semi-autonomous control of vehicle 100 based on available ECU resources. According to one or more implementations, Figure 4 The ECU described in the text is Figure 1A and Figure 1B An example implementation of the processing system 102. That is, processing system 102 represents an ECU, but it should be understood that method 400 can be implemented for monitoring any suitable type of controller, device, or system that can be used to control one or more aspects of a vehicle. Now refer to Figure 1A , Figure 1B and Figure 2 Method 400 is described by at least some of its parts, but is not limited thereto.

[0112] Method 400 begins at box 402, where method 400 commences. At box 404, nominal values ​​are used to initialize the prediction and control time domains.

[0113] The prediction horizon refers to a future time span, based on MPC control. Figure 2 (Box 214) predicts the behavior of vehicle 100 over a future time span. When predicting the vehicle's state and performance, MPC-based control ( Figure 2 Box 214) considers the number of future discrete time steps. Predicting the time domain enables MPC-based control (…). Figure 2(Box 214) can anticipate future events and make informed decisions to optimize the trajectory and control actions of vehicle 100. A longer prediction time domain provides a relatively more comprehensive picture of the future, but utilizes relatively more computational resources, while a shorter prediction time domain reduces computational requirements, but may lead to relatively less ideal control decisions.

[0114] The control time domain refers to the future time span, based on MPC control ( Figure 2 (Block 214) optimizes the control input to vehicle 100 over this future time span. When the optimal control action is determined to implement the desired vehicle behavior, MPC-based control (…) Figure 2 Box 214) considers the number of future discrete time steps. In one or more embodiments, the control time domain may be shorter than or equal to the prediction time domain. The control time domain defines the duration for which the control input is actively adjusted to influence the vehicle's trajectory. A longer control time domain enables relatively more gradual and smooth control actions, while a shorter control time domain results in relatively more immediate and aggressive adjustments.

[0115] The nominal value represents the default length of the prediction and control time domain typically used under normal operating conditions, and can be based on various vehicle characteristics (e.g., weight, mass moment of inertia, discretization step size, accuracy requirements of control commands, specified computing resources, etc., including combinations and / or multiples thereof) and / or operating conditions (e.g., speed, road type, weather, etc., including combinations and / or multiples thereof).

[0116] At box 406, method 400 relates to monitoring the ECU resources of vehicle 100. This monitoring includes tracking various metrics such as task execution time (e.g., the duration for which a computational task completes its processing), central processing unit (CPU) utilization (e.g., the percentage of CPU capacity used to execute a task at a given time), occurrence of task overruns (e.g., a computational task exceeding its allocated execution time, potentially leading to delays or failures in completing subsequent tasks within the expected time frame), and combinations thereof and / or multiple thereof. The objective is to ensure that the ECU has sufficient resources to perform the necessary calculations for vehicle control.

[0117] Then, method 400 proceeds to decision box 408, where it is determined whether the rate of change of task execution exceeds a predefined threshold (e.g., a first threshold). If the rate of change of task execution exceeds the threshold, method 400 moves to box 414. If not, method 400 proceeds to decision box 410.

[0118] At decision box 410, method 400 checks whether the rate of change of CPU utilization exceeds a predefined threshold (e.g., a second threshold). If the rate of change of CPU utilization exceeds the threshold, method 400 moves to box 414. If not, the method proceeds to decision box 412.

[0119] At decision box 412, method 400 determines whether a CPU task overrun has been detected. If a CPU task overrun is detected, method 400 moves to box 414. If no task overrun is detected, method 400 loops back to box 418 to continue control operations.

[0120] At block 414, if any condition in decision blocks 408, 410, or 412 is met, method 400 reduces the prediction and control time domain. According to one or more embodiments, reducing the prediction and control time domain involves reducing the prediction and control time domain by a predefined step size to generate a reduced prediction and control time domain. This reduction is performed to decrease the computational load on the ECU, ensuring that the control tasks for controlling vehicle 100 can be completed within available resources.

[0121] Then, method 400 proceeds to decision box 416, where it determines whether the reduced prediction and control time domain is below a minimum acceptable threshold. If the reduced prediction and control time domain is not below the minimum acceptable threshold, method 400 continues the control operation of vehicle 100 at box 418. If the reduced prediction and control time domain is below the minimum acceptable threshold, method 400 moves to box 420.

[0122] At box 420, method 400 requests an upgrade. According to one or more implementations, the upgrade involves implementing an alternative control strategy to ensure the continued safe operation of the vehicle. The alternative control strategy may include switching to a simpler control algorithm or a predefined backoff maneuver. Additionally or alternatively, an alarm may be generated to notify the vehicle operator that manual intervention is required.

[0123] Finally, method 400 ends at box 422.

[0124] In general, Figure 4 A detailed flowchart is provided for a method 400 for dynamically adjusting the prediction and control time domain based on ECU resource availability, thereby ensuring effective and reliable vehicle control of vehicle 100.

[0125] Additional processes may also be included, and it should be understood that... Figure 4 The processes described herein are illustrative, and other processes may be added, or existing processes may be removed, modified, or rearranged without departing from the scope of this disclosure. It should also be understood that... Figure 4The process described herein can be implemented as programming instructions stored on a non-transitory computer-readable storage medium, when executed by a computing system (e.g., Figure 1A and 1B Processing system 102 Figure 5 Processing systems 500, etc., including combinations thereof and / or multiple thereof) of processors (e.g., Figure 1B Processing equipment 110 Figure 5 When a processor 521, etc., including combinations thereof and / or multiple thereof, is executed, the processor performs the process described herein.

[0126] One or more embodiments provide significant technical benefits. For example, one or more embodiments described herein provide significant benefits in terms of the functionality of vehicle functions and processing systems (e.g., ECUs). These benefits are implemented through the integration of advanced driver assistance systems and model predictive control strategies, which enhances the overall performance, safety, and efficiency of the vehicle.

[0127] One or more embodiments achieve precise and real-time control of a vehicle by utilizing data from various sensors, such as cameras, radio radar, and lidar. This data is used to perform perception tasks, including object detection, lane following, and obstacle avoidance, which are crucial for safe and efficient vehicle operation. By implementing MPC algorithms, one or more embodiments can predict the future state of the vehicle and optimize control inputs to follow a desired trajectory. This results in smoother and more accurate steering, acceleration, and braking actions, enhancing vehicle stability and responsiveness. Furthermore, one or more embodiments provide the ability to dynamically adjust the prediction and control time domain based on real-time conditions, ensuring that the vehicle can adapt to changing environments and maintain optimal performance.

[0128] The processing system, including the ECU, benefits from efficient utilization of computational resources through the described device modeling strategy and multi-step discretization of the device model. By reducing the computational requirements of the MPC algorithm, one or more embodiments enable real-time (or near real-time) execution in resource-constrained environments. A feedback mechanism between the ECU resource monitor and the ADAS control strategy ensures uninterrupted operation by dynamically adjusting the control and prediction time domains based on available resources. This real-time adaptation helps avoid task overruns and infeasible solutions, enhancing the overall reliability and robustness of the vehicle control system. Furthermore, one or more embodiments provide the ability to monitor various ECU resource metrics, such as CPU utilization and task execution time, which allows for proactive adjustments to the control strategy to ensure the ECU operates within its capacity and maintains optimal performance without excessive or undesirable performance degradation that could render the vehicle partially or completely inoperable.

[0129] It should be understood that one or more embodiments described herein can be implemented in conjunction with any other type of computing environment now known or developed hereafter. For example, Figure 5 A block diagram of a processing system 500 for implementing the techniques described herein is depicted. According to one or more embodiments described herein, the processing system 500 is an example of a cloud computing node in a cloud computing environment. In the example, the processing system 500 has one or more central processing units (also referred to as “processors”, “processing resources”, or “processing devices”) 521a, 521b, 521c, etc. (collectively or generally referred to as processor 521 and / or processing device 521). In various aspects of this disclosure, each processor 521 may include a Reduced Instruction Set Computer (RISC) microprocessor. The processor 521 is coupled to system memory 522 and / or various other components via a system bus 533. System memory 522 may include one or more temporary and / or permanent memory devices, such as random access memory (RAM) 523, read-only memory (ROM) 524, etc., including combinations thereof and / or multiples thereof. System bus 533 may include a Basic Input / Output System (BIOS) that controls certain basic functions of the processing system 500.

[0130] Further depictions include an input / output (I / O) adapter 527 and a network adapter 526 coupled to the system bus 533. The I / O adapter 527 may be a Small Computer System Interface (SCSI) adapter that communicates with a hard disk 535 and / or storage device 536 or any other similar component. The I / O adapter 527, hard disk 535, and storage device 536 are collectively referred to herein as mass storage 534. An operating system 540 for execution on the processing system 500 may be stored in the mass storage 534. The network adapter 526 interconnects the system bus 533 with an external network 538, enabling the processing system 500 to communicate with other such systems.

[0131] A display (e.g., a display monitor) 539 is connected to the system bus 533 via a display adapter 532, which may include a graphics adapter to improve the performance of graphics-intensive applications and video controllers. In one aspect of this disclosure, adapters 526, 527, and / or 532 may be connected to one or more I / O buses connected to the system bus 533 via an intermediate bus bridge (not shown). Suitable I / O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI). Additional input / output devices are shown connected to the system bus 533 via a user interface adapter 528 and a display adapter 532. A keyboard 529, a mouse 530, and a speaker 531 may be interconnected to the system bus 533 via a user interface adapter 528, which may include, for example, a super I / O chip integrating multiple device adapters into a single integrated circuit.

[0132] In some aspects of this disclosure, the processing system 500 includes a graphics processing unit (GPU) 537. The GPU 537 is a dedicated electronic circuit designed to manipulate and modify memory to accelerate the creation of images in a frame buffer intended for output to a display. Typically, the GPU 537 is highly efficient in manipulating computer graphics and image processing and has a highly parallel architecture that makes it more efficient than general-purpose CPUs for parallel processing of algorithms handling large blocks of data.

[0133] Therefore, as configured herein, the processing system 500 includes processing power in the form of a processor 521, storage capacity including system memory 522 and mass storage 534, input devices such as a keyboard 525 and a mouse 530, and output capacity including a speaker 531 and a display 539. In some aspects of this disclosure, a portion of the system memory 522 and the mass storage 534 jointly store an operating system 540 to coordinate the functions of the various components shown in the processing system 500.

[0134] The term “a” does not indicate a limitation of quantity, but rather that at least one of the referenced items is present. Unless the context clearly indicates otherwise, the term “or” means “and / or”. Throughout the specification, the reference to “aspect” means that a particular element described in connection with that aspect (e.g., a feature, structure, step, or characteristic) is included in at least one aspect described herein and may or may not be present in other aspects. Furthermore, it should be understood that the described elements may be combined in any suitable manner in the aspects.

[0135] When an element, such as a layer, film, region, or substrate, is referred to as being “on” another element, it can be directly on the other element, or there may be intermediate elements present. Conversely, when an element is referred to as being “directly” on another element, there are no intermediate elements present.

[0136] Unless otherwise stated herein, all test standards are the most recent standards in force up to the date of filing of this application, or, if priority is claimed, the date of filing of the earliest priority application in which a test standard appears.

[0137] Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0138] While the foregoing disclosure has been described with reference to exemplary embodiments, those skilled in the art will understand that various changes can be made and elements can be substituted with equivalents without departing from its scope. Furthermore, many modifications can be made to adapt particular situations or materials to the teachings of this disclosure without departing from the basic scope of this disclosure. Therefore, it is intended that this disclosure be limited to the specific embodiments disclosed, but will include all embodiments falling within its scope.

Claims

1. A computer-implemented method for monitoring and time-domain adaptation of electronic control unit resources during vehicle control, the method comprising: Receive data from the vehicle's sensors; Determine the reference trajectory and control time domain of the vehicle; Divide the discretization step size into multiple step sizes; For one of the multiple step sizes, the continuous-time dynamic model is converted into a discrete-time dynamic model. Iterate over the plurality of step sizes to generate a discretized dynamic model for the discretization step sizes; Discretized dynamic models are used in model predictive controllers to generate desired steering commands for the vehicle; and The vehicle is controlled using the desired steering command generated by the model predictive controller using the discretized matrix.

2. The computer-implemented method according to claim 1, further comprising: The control time domain is dynamically adjusted based on the available computing resources of the vehicle's electronic control unit.

3. The computer-implemented method according to claim 2, wherein dynamically adjusting the control time domain includes monitoring central processing unit utilization and task execution time.

4. The computer-implemented method according to claim 1, wherein, The discretized dynamic model for the discretization step size is generated using scaling and squaring methods.

5. The computer-implemented method of claim 1, wherein the discretization step size is segmented into multiple step sizes using the following equation: Where h is the time period of one of the multiple step sizes, T is the total time period of a discretized step size, and N is an integer.

6. The computer-implemented method of claim 1, wherein a bilinear transformation is used to generate a transformation from a continuous-time dynamic model to a discrete-time dynamic model for one of the plurality of step sizes.

7. The computer-implemented method of claim 6, wherein the continuous-to-discrete transformation is performed by discretizing the following equation for each of a plurality of step sizes h: Where x is the state vector. A is the derivative of the state vector x with respect to time t. c It is a continuous-time system matrix, B c It is a continuous-time input matrix, and u is an input vector.

8. The computer-implemented method according to claim 6, wherein, The following equation is obtained by converting the continuous-time dynamic model into a discrete-time dynamic model: x(k+1)=A d x(k)+B d u(k) Where k is the discrete-time exponent, A d It is the discretized system matrix using bilinear transformation, A B d It is a discretized input matrix using a bilinear transformation.

9. The computer-implemented method according to claim 4, wherein, Perform the second iteration k+2 of the discretization process according to the following equation: x(k+2)=A d x(k+1)+B d u(k)=(A d ) 2 x(k)+(A d +I)B d u(k) Where I is the identity matrix.

10. The computer-implemented method according to claim 4, wherein, Perform the third iteration k+4 of the discretization process according to the following equation: x(k + 4) = (A d ) 2 x(k + 2) + (A d + I)B d u(k) = (A d ) 4 x(k) + ((A d ) 2 + I)(A d + I)B d u(k), and The fourth iteration k+8 of the discretization process is performed according to the following equation: x(k+8)=(A d ) 4 x(k+4)+((A d ) 2 +I)(A d +I)B d u(k)=(A d ) 8 x(k)+((A d ) 4 +I)((A d ) 2 +I)(A d +I)B d u(k)。

Images