Security system

Abstract

The present invention relates to safety systems. In one embodiment, a safety method includes receiving an input from an operator of a vehicle intended to control the vehicle. The method also includes evaluating a safety of the input using a state-action function that quantifies the safety of the input based on a current state of the vehicle. The method also includes optimizing a vehicle action based on the safety, the vehicle action correcting the input by minimizing a deviation between the input and the vehicle action. The method also includes executing the vehicle action to control the vehicle based on the safety, thereby maintaining the safety while preserving human agency to the greatest extent possible.

Description

Technical Field

[0001] This invention generally relates to safety systems for vehicles, and more specifically to vehicle safety systems that preserve human agency in vehicles to the greatest extent possible. Background Technology

[0002] Many vehicles include driver assistance systems that can intervene in emergency situations. For example, some vehicles equipped with driver assistance systems include automatic braking to stop the vehicle when the system detects an impending collision. In another example, some vehicles include lane-keeping assist that automatically steers the vehicle when the system detects it is leaving its lane. However, most driver assistance systems typically deliver sudden, last-minute corrections, which can be jarring to the driver. This characteristic of driver assistance systems, known as "automatic surprise," can confuse the driver due to the vehicle's intervention or lead the driver to attempt to overtake the intervention, resulting in dangerous driving scenarios and an uncomfortable driving experience. Summary of the Invention

[0003] Embodiments of the present invention relate to a safety system for manually driven vehicles that intervenes gradually to ensure safe vehicle operation while preserving operator agency to the greatest extent possible. As mentioned above, in some cases, unintended automation can lead to dangerous driving scenarios and uncomfortable driving experiences. In a vehicle safety method, the safety system receives input from the operator intended to control the vehicle. In one embodiment, the input is the operation of the position and / or movement of the vehicle's steering wheel and / or brake pedal or accelerator pedal. In one method, the safety system evaluates the safety of the input using a state-action safety value function that quantifies the safety of the input based on the vehicle's current state. In one method, the vehicle's current state includes the vehicle's position relative to its external environment, characteristics of the vehicle's movement (such as speed, acceleration, etc.), contact between the vehicle's wheels and the road on which the vehicle is traveling, etc. In one embodiment, if the safety system determines that the safety of the input satisfies safety constraints, the safety system executes the input to operate the vehicle according to the operator's intention.

[0004] However, if the safety system determines that the safety of the input does not meet the safety constraints, in one embodiment, the safety system will optimize and execute a vehicle action that modifies the input to maintain safe vehicle operation while preserving the operator's intent. In one approach, the vehicle action is a modification of the operator's input that minimizes the deviation between the input and the vehicle action. In any case, in one embodiment, the safety constraint is a model-free discrete-time control barrier function that ensures the state-action safety value function of the vehicle action is greater than or equal to a threshold derived from the current state safety value function. Therefore, the safety system operates the vehicle in a manner that most closely reflects the operator's intent while preventing dangerous driving scenarios.

[0005] In one embodiment, a system is disclosed. The system includes a processor and a memory in communication with the processor. The memory stores modules including, when executed by the processor, instructions received from an operator of a vehicle for controlling the vehicle. The instructions also cause the processor to use a state-action function to evaluate the safety of the input, which quantifies the safety of the input based on the current state of the vehicle. The instructions further cause the processor to optimize vehicle actions based on the safety, which correct the input by minimizing the deviation between the input and the vehicle actions. The instructions further cause the processor to execute the vehicle actions based on the safety to control the vehicle, thereby maintaining safety while preserving human agency to the greatest extent possible.

[0006] In another embodiment, a non-transient computer-readable medium (program product) is disclosed. The non-transient computer-readable medium includes instructions that, when executed by a processor, cause the processor to receive input from an operator of a vehicle intended to control the vehicle. The instructions also cause the processor to use a state-action function to evaluate the safety of the input, which quantifies the safety of the input based on the current state of the vehicle. The instructions further cause the processor to optimize vehicle actions based on the safety, which correct the input by minimizing the deviation between the input and the vehicle actions. The instructions also cause the processor to perform the vehicle actions based on the safety to control the vehicle, thereby maintaining safety while preserving human agency to the greatest extent possible.

[0007] In another embodiment, a method is disclosed. The method includes receiving input from a vehicle operator intended to control the vehicle. The method further includes evaluating the safety of the input using a state-action function that quantifies the safety of the input based on the vehicle's current state. The method also includes optimizing vehicle actions based on safety, which corrects the input by minimizing the deviation between the input and the vehicle actions. The method further includes performing vehicle actions based on safety to control the vehicle, thereby maintaining safety while preserving human agency to the greatest extent possible. Attached Figure Description

[0008] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various systems, methods, and other embodiments of this disclosure. It should be understood that the element boundaries (e.g., frames, groups of frames, or other shapes) shown in the drawings represent one embodiment of a boundary. In some embodiments, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some embodiments, an element shown as an inner component of another element may be implemented as an outer component, and vice versa. Furthermore, elements may not be drawn to scale.

[0009] Figure 1 An example of a vehicle in which the systems and methods disclosed herein can be implemented is shown.

[0010] Figure 2 An example of a safety system associated with a vehicle is shown.

[0011] Figure 3 This demonstrates the situation in a cloud computing environment. Figure 2 One embodiment of the system.

[0012] Figure 4 An example of a method for optimizing and executing vehicle actions is shown, which modifies the operator's input to maintain safe vehicle operation while preserving the operator's intent.

[0013] Figure 5 Examples of vehicles on the runway are shown, including unsafe and safe paths.

[0014] Figure 6 An example is shown of displaying visual cues inside a vehicle to depict vehicle movements relative to the operator's intentions to the driver. Detailed Implementation

[0015] Systems and methods associated with safety systems are disclosed. As mentioned above, in some situations, unintended automation can lead to dangerous driving scenarios and uncomfortable driving experiences. Therefore, the embodiments described herein relate to graded intervention in manually driven vehicles to ensure safety while preserving operator agency to the greatest extent possible. In one method, a safety system is configured to receive inputs from an operator intended to control the vehicle. In one embodiment, the inputs are the position and / or movement of the vehicle's steering wheel and / or brake / accelerator pedals. In one method, the safety system evaluates the safety of the input using a state-action safety value function that quantifies the safety of the input based on the vehicle's current state. In one method, the vehicle's current state includes the vehicle's position relative to its external environment, characteristics of the vehicle's movement (such as speed, acceleration, etc.), contact between the vehicle's wheels and the road on which the vehicle is traveling, etc. In one embodiment, if the safety system determines that the safety of the input satisfies safety constraints, the safety system executes the input to operate the vehicle according to the operator's original intention.

[0016] However, if the safety system determines that the safety of the input does not meet the safety constraints, in one embodiment, the safety system will optimize and execute vehicle actions that modify the input to maintain safe operation of the vehicle while preserving the intent (e.g., the operator's original control input). In one approach, the vehicle actions are modifications of the operator's input that minimize the deviation between the input and the vehicle actions. In any case, in one embodiment, the safety constraints are defined according to a model-free discrete-time control barrier function that ensures the state-action safety value function of the vehicle actions satisfies a threshold derived from the current state safety value function. Therefore, the safety system operates the vehicle in a manner that most closely reflects the operator's intent while preventing dangerous driving scenarios.

[0017] Now for reference Figure 1 An example of vehicle 100 is shown. As used herein, "vehicle" is any form of motorized transport. In one or more embodiments, vehicle 100 is an automobile. While the arrangement will be described with respect to automobiles, it will be understood that the embodiments are not limited to automobiles. In some embodiments, vehicle 100 may be another form of motorized transport, such as a train, airplane, bus, or motorcycle. Vehicle 100 also includes various elements. It should be understood that in various embodiments, vehicle 100 may not necessarily have... Figure 1 All components shown. Vehicle 100 may have Figure 1 Any combination of the various components shown. Furthermore, vehicle 100 may have... Figure 1 Additional components for those components shown. In some arrangements, vehicle 100 may be without... Figure 1 Implemented in the case of one or more of the components shown. Although in Figure 1 Various components are shown as being located within vehicle 100; however, it should be understood that one or more of these components may be located outside vehicle 100. Furthermore, the components shown may be physically separated by large distances. For example, as discussed, one or more components of the disclosed system may be implemented within vehicle 100, while other components of the system may be implemented in a cloud computing environment or in other systems located remotely from vehicle 100.

[0018] Some possible components of vehicle 100 Figure 1 As shown in the appendix and will be attached later Figure 1 The description begins here. However, for the sake of brevity, the description will be shortened to include the following: Figures 2 to 6 Provided after discussion Figure 1 The description includes many elements. Furthermore, it should be understood that, for the sake of simplicity and clarity, reference numerals are repeated in different figures where appropriate to indicate corresponding or similar elements. In addition, the discussion outlines many specific details to provide a thorough understanding of the embodiments described herein. However, those skilled in the art will understand that various combinations of these elements can be used to practice the embodiments described herein.

[0019] In any case, vehicle 100 includes a safety system 170, which is implemented to perform the methods and other functions disclosed herein related to maintaining the safe operation of vehicle 100. As will be discussed in more detail later, in various embodiments, safety system 170 is partially located within vehicle 100 and implemented as a cloud-based service. For example, in one method, functionality associated with at least one module of safety system 170 is implemented within vehicle 100, while further functionality is implemented within a cloud-based computing system. Thus, safety system 170 may include a local instance at vehicle 100 and a remote instance operating within a cloud-based environment.

[0020] Furthermore, the safety system 170 provided within vehicle 100 works in conjunction with the communication system 180. In one embodiment, the communication system 180 communicates according to one or more communication standards. For example, the communication system 180 may include multiple different antennas / transceivers and / or other hardware components for communicating at different frequencies and according to appropriate protocols. In one arrangement, the communication system 180 communicates via a communication protocol such as Wi-Fi, DSRC, V2I, V2V, or another suitable protocol for communication between vehicle 100 and other entities in a cloud environment. Additionally, in one arrangement, the communication system 180 also communicates according to protocols such as Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), Long Term Evolution (LTE), 5G, or another communication technology that enables vehicle 100 to communicate with various remote devices (e.g., cloud-based servers). In any case, the safety system 170 may utilize various wireless communication technologies to provide communication to other entities, such as members of a cloud computing environment.

[0021] Now for reference Figure 2 This further demonstrates Figure 1 One embodiment of the security system 170. The security system 170 is shown as including data from... Figure 1 The processor 110 of the vehicle 100. Therefore, the processor 110 may be part of a security system 170, which may include a processor separate from the processor 110 of the vehicle 100, or the security system 170 may access the processor 110 via a data bus or another communication path. In one embodiment, the security system 170 includes a memory 210 storing a security module 220. The memory 210 is random access memory (RAM), read-only memory (ROM), hard disk drive, flash memory, or other suitable memory for storing the security module 220. The security module 220 includes, for example, computer-readable instructions that, when executed by the processor 110, cause the processor 110 to perform the various functions disclosed herein. In an alternative arrangement, the security module 220 includes separate elements from the memory 210, which may consist, for example, hardware elements. Therefore, the security module 220 alternatively includes an ASIC, a hardware-based controller, a combination of logic gates, or another hardware-based solution.

[0022] like Figure 2 The security system 170 shown is typically an abstract form of a security system 170 that can be implemented between one or more vehicles and a cloud computing environment. Figure 3 An example of a cloud computing environment 300 that can be implemented together with security system 170 is shown. Figure 3 As shown, the security system 170 is at least partially embodied within the cloud computing environment 300.

[0023] Therefore, as shown in the figure, security system 170 may include individual instances within one or more entities of the cloud-based cloud computing environment 300, such as servers, and may also include instances within one or more remote devices (e.g., vehicles) for acquiring, analyzing, and distributing said information. On the other hand, the entities implementing security system 170 within the cloud-based cloud computing environment 300 can vary beyond transportation-related equipment and encompass mobile devices (e.g., smartphones) and other devices, such as those carried by individuals within the vehicle, to operate collaboratively with vehicle 100. Thus, the set of entities that coordinate with cloud computing environment 300 can be varied.

[0024] Continue to refer to Figure 2 In one embodiment, the safety system 170 includes a data storage 240. In one embodiment, the data storage 240 is an electronic data structure stored in memory 210 or another data storage, configured with routines executable by processor 110 for analyzing the stored data, providing the stored data, organizing the stored data, etc. Therefore, in one embodiment, the data storage 240 stores data used by the safety module 220 in performing various functions. In one approach, the data includes various types of data used by the safety module 220 to maintain the safe operation of the vehicle 100. Various types of data, including sensor data 250, will be described in further detail below. In any case, the data storage 240 includes data as well as metadata, such as aspects characterizing the data. For example, metadata may include location coordinates (e.g., longitude and latitude), relative map coordinates or tile identifiers, time / date stamps from when the individual data was generated, etc. In one embodiment, the data storage 240 stores data. In one embodiment, as described in further detail below, the data storage 240 also includes one or more models 260 that can be used to process the data.

[0025] As described above, in one embodiment, the data includes sensor data 250, including observations of one or more objects and / or people in the external environment of vehicle 100 and / or perceptions from within the passenger compartment of vehicle 100. Sensor data 250 may include various perceptions from sensors of sensor system 120 of vehicle 100. For example, safety module 220 typically includes instructions for controlling processor 110 to receive data input from one or more sensors of vehicle 100. As provided herein, in one embodiment, safety module 220 acquires sensor data 250 that includes at least perceptions of occupants within vehicle 100. Safety module 220 may also acquire information about the surrounding environment of vehicle 100 from camera 126. In another arrangement, safety module 220 acquires sensor data 250 from additional sensors, such as radar 123, laser 124, and other sensors. Additionally, when acquiring sensor data 250 from multiple sensors, safety module 220 fuses the sensor data 250 together to form sensor data 250 and provide improved detection determination.

[0026] Therefore, in one embodiment, the safety module 220 controls the corresponding sensors to provide data input in the form of sensor data 250. Additionally, while the safety module 220 is discussed as controlling various sensors to provide sensor data 250, in one or more embodiments, the safety module 220 may employ other techniques to acquire active or passive sensor data 250. For example, the safety module 220 may passively sniff out sensor data 250 from the electronic information stream provided by various sensors to other components within the vehicle 100. Furthermore, when providing sensor data 250, the safety module 220 may employ various methods to fuse data from multiple sensors. Thus, in one embodiment, sensor data 250 represents a combination of perceptions acquired from multiple sensors and / or other sources. As part of controlling the sensors to acquire sensor data 250, it is generally understood that the sensors acquire sensor data 250 of the area around the vehicle 100 and / or the area within the vehicle 100, wherein data acquired from different types of sensors typically overlap to provide a comprehensive sample of the external and / or internal environment of the vehicle 100 at each time step. Typically, sensor data 250 does not need to have exactly the same bounded area in the surrounding environment and / or the internal environment, but should include enough overlapping areas so that different aspects of the area can be correlated.

[0027] In one approach, security module 220 implements and / or otherwise uses machine learning algorithms, which may be one or more of models 260. In one configuration, the machine learning algorithm is embedded within security module 220 (such as a convolutional neural network (CNN)) to perform various perception methods on sensor data 250 from which further information is derived. Of course, in another aspect, security module 220 may employ different machine learning algorithms or implement different methods for performing machine perception, which may include deep neural networks (DNNs), recurrent neural networks (RNNs), or another form of machine learning. Regardless of which particular method security module 220 implements, security module 220 provides various outputs from the information represented in sensor data 250. In this way, security system 170 is able to process sensor data 250 into a contextual representation.

[0028] As described in this article, machine learning algorithms include, but are not limited to, deep neural networks (DNNs), including transformer networks, convolutional neural networks, recurrent neural networks (RNNs), clustering algorithms, hidden Markov models, etc. It should be understood that individual forms of machine learning algorithms can have different applications, such as agent modeling and machine perception.

[0029] Furthermore, it should be understood that machine learning algorithms are typically trained to perform defined tasks. Therefore, unless otherwise stated, the training of a machine learning algorithm is understood to differ from the general use of the machine learning algorithm. That is, the security system 170 typically trains the machine learning algorithm according to a specific training method, which may include supervised training, self-supervised training, reinforcement learning, etc. In contrast to the training / learning of the machine learning algorithm, the security system 170 implements the machine learning algorithm to perform inference. Therefore, the general use of the machine learning algorithm is described as inference.

[0030] Regarding Figure 4 Additional aspects of security system 170 are discussed. Figure 4 A flowchart of a method 400 associated with maintaining the safe operation of vehicle 100 is shown. (From...) Figure 1 and 2 Method 400 is discussed from the perspective of security system 170. Although method 400 is discussed in conjunction with security system 170, it should be understood that method 400 is not limited to implementation within security system 170, but rather security system 170 is an example of a system in which method 400 can be implemented.

[0031] At 410, in one method, safety module 220 receives operator input. As described herein, operator input is input indicating an operator's intention to control vehicle 100 and includes operation of the steering wheel, brake pedal, accelerator pedal, and / or any other vehicle controls that may indicate movement and / or operation of vehicle 100 by an operator of vehicle 100 (e.g., a driver). For example, operator input could be rotation of the steering wheel combined with depressing the accelerator pedal to control vehicle 100 to turn while accelerating. In any case, operator input may include sensor data 250 indicating the operator's intention to control vehicle 100. For example, sensor data 250 may include data from a steering angle sensor, torque sensor, pedal sensor, etc. In some embodiments, at 410, safety module 220 acquires operator input (which may include sensor data 250) in continuous iterations or time steps. Thus, in one embodiment, safety system 170 iteratively performs the functions discussed at 410 to acquire data and provide information therefrom. Furthermore, in one embodiment, the security module 220 performs one or more of the aforementioned functions in parallel for individual observations in order to maintain updated awareness.

[0032] Continue to refer to Figure 4 At 420, in one embodiment, safety module 220 evaluates operator input to determine whether the input is safe. In one method, evaluating the input includes processing data including sensor data 250. Furthermore, in one method, safety module 220 utilizes one or more models 260 of safety system 170 to evaluate the input and / or process the data. Model 260 may include one or more of the models described above, such as machine learning models, neural networks, etc.

[0033] In any case, as described above, safety module 220 evaluates the safety of the input (e.g., safety module 220 determines whether the input is safe or unsafe). As used herein, "safe" means that, if the input is executed, it will cause vehicle 100 to operate in a manner that does not pose a risk of harm to vehicle 100, its occupants, or other persons outside vehicle 100. Examples of "safe" operation of vehicle 100 include situations where the input will not cause vehicle 100 to overturn, leave the boundary of the road it is traveling on, or participate in a collision. Furthermore, in one embodiment, the term "unsafe" refers to a situation where the input would cause vehicle 100 to approach an unsafe boundary too quickly. In any case, in one approach, safety module 220 evaluates the safety of the input at 420 using a state-action function that quantifies the safety of the input based on the current state of vehicle 100. More specifically, in one approach, safety module 220 ensures safe operation of vehicle 100 according to a framework in which it is assumed that vehicle 100 exhibits discrete-time nonlinear dynamics:

[0034] (1)

[0035] in, and Indicates time step The state and control inputs at the location (e.g., the state of vehicle 100 and the control of the operator of vehicle 100). In one implementation, the control of vehicle 100 comes from the task policy. In one approach, a Lipschitz continuous safety margin function is used. This defines the fault set (failure set). :

[0036] (2)

[0037] In one method, The state inside the track is considered a failure in terms of safety. In the context of racing, in some situations, the state corresponding to a race car being outside the track boundaries or in contact with another vehicle is... Some examples within. In one example, within a control set. and fault set A common definition is made for the vehicle's Operational Design Domain (ODD). The ODD can be understood as a social contract bridging robot operators, the public, and decision-makers—it provides a clear set of conditions for the safe operation of vehicle 100. To ensure the safety of vehicle 100 under the ODD, a monitoring framework called a safety filter is implemented. The safety filter will be described in further detail below, in conjunction with section 440.

[0038] As described above, to ensure the safety of vehicle 100 under ODD, a monitoring framework called a safety filter is implemented. As used herein, the "safety filter" continuously monitors the operation of vehicle 100 and, when deemed necessary, modifies the operation by the task strategy. This involves automating a process by providing candidate actions to intervene and prevent potential future safety malfunctions. Specifically, it replaces the direct application of task actions. Security module 220 uses security filtering-based actions in one method:

[0039] (3)

[0040] The specific functional form depends on the type of intervention of the safety filter, which includes, for example, switching, transformation, and optimization. The safety filter prevents the use of task actions that would compromise future safety, thus allowing the safety module 220 to maintain the safety of the vehicle 100 without needing to modify its entire behavior. In one approach, Hamilton-Jacobi (HJ) reachability analysis is used to synthesize the safety filter. .

[0041] In one approach, a security filter is designed to make a given ODD element and Security module 220 in the maximum security set 100 vehicles are operated internally, of which... In one implementation, the maximum security set This provides an indefinite ban on vehicles 100 from entering. The composition of all states of the control strategy. Theoretically, The HJ reachability analysis can be used to compute this problem. This analysis employs a level set method to reproject the safety filter synthesis problem into an optimal control problem, the solution of which follows the solution of the dynamic programming safety Bellman equation:

[0042] (4)

[0043] This allows safe value functions As its fixed point solution. In one method, given Then the maximum safe set Defined as:

[0044] (5)

[0045] For subsequent expansion of the safety filter, adopt The function modifies equation (4) into the state-action safe Bellman equation:

[0046] (6)

[0047] This allows for state-action safe value functions. As its fixed point solution. This formula is in In the sense of, it remains equivalent to equation (4).

[0048] Then, the Last Line of Defense Security Filter (LRSF) is introduced, which is a value-based security filter built on a security value function. and Above:

[0049] (7)

[0050] Among them, the safe rollback strategy is defined as ,and This refers to any task-oriented strategy that does not explicitly consider security. In one case, equation (7) is called a "last line of defense" strategy because in one approach, the security filter extends until... Vehicle 100 is about to leave. Intervention is only initiated at the critical point. (After reaching...) When the boundary is reached, in one method, LRSF is used... Complete oversight (takeover) of control in order to enforce (ensure) security.

[0051] In some cases, LRSF can have limitations. First, its task-independent fallback strategy often leads to discontinuous and abrupt interventions. This can become more pronounced in shared autonomy settings, where human operators may be caught off guard and confused by sudden overreach. Even if LRSF arrives at the system... While providing maximum degrees of freedom before the boundary, its disregard for the risk of human intervention also reduces the operator's sense of control. Furthermore, the time and space complexity required to solve equation (4) is exponentially proportional to the state-space dimension, making grid-based dynamic programming unsuitable for safety control in real-world scenarios.

[0052] Therefore, the safety filter described in this paper addresses these limitations by synthesizing outputs that deviate minimally from the operator's human input, thereby enhancing both agency and smoothness while still enforcing safety. Furthermore, it utilizes safety reinforcement learning (RL) as described in further detail below to approximate safety via RL. This function enables a best-effort fallback strategy for high-dimensional systems. The synthesis of.

[0053] Another approach for value-based security filtering is the implementation of the Discrete-Time Controlled Barrier Function (DCBF):

[0054] Definition 1: If ,as well as, If the following expression is satisfied, then the function It is the DCBF of system (1):

[0055] (8)

[0056] in, .

[0057] Unlike LRSF, which applies safety through hard overlay, DCBF solves by finding the closest action to the task. The optimization of security enforcement actions is needed to achieve smooth security intervention.

[0058] (9a)

[0059] (9b)

[0060] Equation (9b) represents the DCBF constraint. The trade-off (cost, compromise) is that DCBF is usually no longer present in the maximum safe set. Internal enforcement of security. Instead, it targets (smaller) security sets. Perform secure coding.

[0061] HJ safety value function It is closely related to DCBF in the following sense, that is, if If it is continuously differentiable, then it automatically becomes the maximum safe set. Effective DCBF. This understanding makes... This method is capable of being used in a smooth DCBF-based security filter, rather than in an LRSF alternative, and is the theoretical basis for the security filter of this invention.

[0062] Note 1: It should be noted that Definition 1 can be relaxed, simply by making equation (8) applicable to all It is sufficient if it is true. It satisfies the requirement for any function conforming to the relaxed DCBF definition. The control input of formula (9b) It is still possible to make The level set above 0 remains positive. This relaxation of equation (8) still guarantees security, but loses... The set attraction of the level set above 0.

[0063] Based on HJ reachability analysis and DCBF, the security filter framework is extended to a model-free setting. In the sense of Definition 1, the security value function... It is a valid DCBF. Then, the state-action safe value function is used. We introduce a model-free equivalent of the DCBF constraints. Using these results, we propose a Human-Centered Safety Filter (HCSF), which solves the optimal control problem (OCP) at each time step to "anchor" the filtered input near human actions (e.g., inputs) while still ensuring safety via model-free DCBF constraints. The model-free DCBF formulation will now be described.

[0064] Proposal 1 (Model-free DCBF): A safety value function as a fixed-point solution to the safety Bellman equation (4) It is a valid DCBF as defined in Definition 1 and Label 1. The corresponding DCBF constraint is:

[0065] (10)

[0066] in, Using the symbols from Definition 1, Equivalent to .

[0067] A key difference should be noted between the original DCBF constraint (9b) and the current formula (10): the requirement for (or lack thereof) system dynamics. Considering... Satisfying equations (6) and (10) does not require system dynamics for its evaluation. This allows it to be applied to safety-critical systems with black-box (e.g., unknown) dynamics. An example of such a system is a high-fidelity racing simulator. Conversely, evaluating the original DCBF constraint (9b) does require prior knowledge of the system's dynamics, which prevents its application to systems with unknown dynamics. It should also be noted that the system constrained by equation (10) makes the system... It cannot decay below 0. In other words, it keeps the system within the maximum safety set compared to many manual DCBFs that often suffer from conservative safety sets. Inside.

[0068] We now use Proposal 1 to define HCSF, which sets a custom safety filter for shared autonomy. HCSF solves for OCP at each time step to synthesize the minimum deviation from human control. (For example, input) simultaneously satisfies the safe action of model-free DCBF constraints.

[0069] Definition 2. In one method, HCSF is defined as follows:

[0070] (11a)

[0071] (11b)

[0072] in, It is a design parameter that indicates how quickly the safety value function is allowed to decrease within a single time step. In one approach, It is a threshold that defines the constraints on vehicle actions within the maximum safe set when the threshold is met, where the maximum safe set includes vehicle states in which there are control strategies to prevent vehicles from entering unsafe states.

[0073] It should be noted that, according to equation (11a), optimizing vehicle actions at 440 includes minimizing the squared difference between the input and the vehicle actions in one method. In other words, in one implementation, the vehicle actions correct the input by minimizing the deviation between the input and the vehicle actions. Therefore, the safety system 170 can maintain the safety of the vehicle 100 while preserving human agency to the greatest extent possible. According to the safety system 170 described herein, in one method, maintaining the safety of the vehicle 100 includes ensuring that the vehicle 100 does not enter an unsafe state, as described above. Furthermore, in one method, preserving human agency to the greatest extent possible includes correcting the input with automatic control to generate shared control for operating the vehicle 100. Therefore, by maintaining the safety of the vehicle 100 while preserving human agency to the greatest extent possible, the safety system 170 preserves the safety of the operator and the operator's sense of control over the vehicle 100.

[0074] Furthermore, it should be noted that equation (11b) is a safety constraint, which ensures that the state-action function of the vehicle's actions satisfies the current state function (e.g., The derived threshold is a model-free DCBF. The model-free DCBF constraint ensures that the safe-value function does not decay to the specified threshold at each time step. The following is the recursive feasibility of HCSF. This is a direct result of efficient DCBF, as described in Proposal 1. This is formalized in the following proposal:

[0075] Proposal 2 (Recursive Feasibility of HCSF): For any given initial state The optimization problem in equation (11) is... Recursion is feasible.

[0076] Following the aforementioned safety framework, if safety module 220 determines at 420 that the input is safe (e.g., if safety module 220 determines at 420 that a safety constraint is satisfied), then in one approach, safety module 220 executes the input at 430. In one approach, satisfying the constraint means that the state-action function of the vehicle action is greater than or equal to a threshold derived from the current state function. In some cases, the constraint is related to the definition of the state-action function, the threshold, and the current state function. Furthermore, in one approach, executing the input at 430 means that safety module 220 allows vehicle 100 to operate according to the parameters of the input. For example, if the input is that an operator presses the accelerator pedal, then vehicle 100 will accelerate.

[0077] On the other hand, if safety module 220 determines at 420 that the input is unsafe according to the aforementioned framework for safety, then in one approach, safety module 220 optimizes vehicle actions at 440. As used herein, “vehicle actions” can be either (1) a modified version of the input that maintains the safety of vehicle 100 or (2) a new control input generated by the safety module based on the input that maintains the safety of vehicle 100. In either case, in one approach, safety module 220 optimizes vehicle actions such that the vehicle actions most closely match the operator’s input while ensuring the safe operation of vehicle 100, thereby maintaining safety while preserving human agency to the greatest extent possible.

[0078] Referring back to Definition 2 and Proposal 2, these frameworks determine that HCSF actively promotes human agency by selecting actions that remain as close as possible to the expected human input, while ensuring that vehicle 100 never leaves the maximum safety set, thereby enabling optimization of vehicle actions at 440.

[0079] When optimizing vehicle actions at 440 based on the safety assessment at 420, in one method, safety module 220 executes a vehicle action at 450 to control vehicle 100. Upon executing an input at 430 or a vehicle action at 450, in another method, method 400 returns to 410. Therefore, safety system 170 continuously monitors the input at each time step to assess whether the input is safe and whether safety system 170 should intervene. Thus, safety system 170 maintains operator safety at each time step while maximizing operator control over vehicle 100.

[0080] Now for reference Figure 5 This illustrates an example of the operation of vehicle 100 according to HCSF. More specifically, Figure 5An example of a vehicle 100 on runway 500 is depicted, showing an unsafe path 510 and a safe path 520 for the vehicle 100. In one example, unsafe path 510 is the path that the vehicle 100 can follow when performing operator inputs that are not subject to HCSF, while safe path 520 is the path that the vehicle 100 can follow when performing operator inputs that are subject to HCSF. In the example shown, operator inputs can be steering wheel angle, accelerator pedal depressing, brake pedal depressing, or a combination of one or more of these inputs, which would cause the vehicle 100 to cross the boundary of runway 500. It can be seen that the operator input will cause the vehicle 100 to operate unsafely because the vehicle 100 will cross the boundary of runway 500. However, when the operator input is subject to HCSF, safety module 220 determines the vehicle action based on the operator input that produces safe path 520, which is a path that very closely reflects the operator's intention (e.g., driving close to the boundary of runway 500) but is modified for safe operation of the vehicle 100. In other words, the operator input is corrected according to the HCSF so that vehicle 100 is safely kept within the boundaries of runway 500, but follows a trajectory that matches the operator input as closely as possible.

[0081] In some cases, providing the operator with instructions on performing vehicle actions may be beneficial to improve the operator's understanding of the safety system 170. Therefore, reference is now made to... Figure 6 In one embodiment, safety module 220 may be configured to display visual cues within vehicle 100 to depict various characteristics of vehicle movement relative to input to the operator. For example... Figure 6 As shown, operator 600 drives vehicle 100 along road 610. In the example shown, safety module 220 can determine a vehicle action that turns vehicle 100 to the right. Therefore, safety module 220 can display a visual cue 620 (e.g., a right arrow) to operator 600 to indicate that the vehicle action is to turn vehicle 100 to the right.

[0082] In some implementations, the visual cue 620 can depict the direction and magnitude of the vehicle action relative to the input. For example, displaying the visual cue 620 as an arrow can depict the direction of the vehicle action, especially when the vehicle action includes turning the vehicle 100 left or right. Furthermore, regarding magnitude, in some cases, the magnitude of the vehicle action can be depicted via the size and / or brightness of the visual cue 620. For example, a brighter and / or larger visual cue 620 can depict a vehicle action with a greater difference from the input, while a darker and / or smaller visual cue 620 can depict a vehicle action more similar to the input.

[0083] As shown in the figure, visual cues 620 are digital arrows displayed on a head-up display on the windshield of vehicle 100. However, it should be understood that visual cues may also be displayed in other locations within vehicle 100 and in other ways. For example, visual cues 620 may be displayed on the dashboard and / or user interface of vehicle 100, may be projected onto the windshield or another surface within vehicle 100, or may even be displayed on the operator's personal electronic device, such as a mobile phone, smartwatch, etc.

[0084] Now we will discuss this in full detail. Figure 1 This serves as an example environment in which the systems and methods disclosed herein may operate. In some cases, vehicle 100 is configured to selectively switch between autonomous mode, one or more semi-autonomous modes, and / or manual mode. "Manual mode" means performing all or most of the control and / or manipulation of the vehicle based on input received via a manual human-machine interface (HMI) (e.g., steering wheel, accelerator pedal, brake pedal, etc.) operated by a user (e.g., a human driver) of vehicle 100. In one or more arrangements, vehicle 100 may be a manually controlled vehicle configured to operate only in manual mode.

[0085] In one or more arrangements, vehicle 100 implements a level of automation to operate autonomously or semi-autonomously. As used herein, the automatic control of vehicle 100 follows a spectrum defined according to the SAE J3016 standard. The SAE J3016 standard defines six levels of automation from zero to five. Generally, as described herein, semi-autonomous mode refers to levels 0 to 2, while autonomous mode refers to levels 3 to 5. Thus, autonomous mode typically involves controlling and / or maneuvering vehicle 100 along a driving route via a computing system to control vehicle 100 with minimal or no input from the human driver. In contrast, semi-autonomous mode, also known as Advanced Driver Assistance Systems (ADAS), provides a portion of the control and / or maneuvering of the vehicle along a driving route via a computing system, wherein the vehicle operator (i.e., the driver) provides at least a portion of the control and / or maneuvering of vehicle 100.

[0086] Continue to refer to Figure 1 As shown in the various components, vehicle 100 includes one or more processors 110. In one or more arrangements, processor 110 may be a main / centralized processor of vehicle 100 or may represent a number of distributed processing units. For example, processor 110 may be an electronic control unit (ECU). Alternatively or additionally, processors may include a central processing unit (CPU), graphics processing unit (GPU), ASIC, microcontroller, system-on-a-chip (SoC), and / or other electronic processing units that support the operation of vehicle 100.

[0087] Vehicle 100 may include one or more data memories 115 for storing one or more types of data. Data memories 115 may include volatile and / or non-volatile memory. Examples of memories that may form data memories 115 include RAM (Random Access Memory), flash memory, ROM (Read-Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), registers, disks, optical disks, hard disk drives, solid-state drives (SSDs), and / or other non-transient electronic storage media. In one configuration, data memories 115 are a component of processor 110. Data memories 115 are operatively connected to processor 110 for its use. As used throughout this specification, the term "operatively connected" may include direct or indirect connections, including connections without direct physical contact.

[0088] In one or more arrangements, one or more data storage devices 115 include various data elements to support the functions of vehicle 100, such as semi-autonomous and / or autonomous functions. Therefore, data storage devices 115 may store map data 116 and / or sensor data 119. In at least one method, map data 116 includes maps of one or more geographic areas. In some cases, map data 116 may include information about roads (e.g., lane and / or road maps), traffic control devices, road markings, structures, features, and / or landmarks in one or more geographic areas. In at least one method, map data 116 may be characterized as a high-definition (HD) map providing information for autonomous and / or semi-autonomous functions.

[0089] In one or more arrangements, map data 116 may include one or more topographic maps 117. Topographic map 117 may include information about ground, terrain, roads, surfaces, and / or other features of one or more geographic areas. Topographic map 117 may include elevation data for one or more geographic areas. In one or more arrangements, map data 116 includes one or more static obstacle maps 118. Static obstacle map 118 may include information about one or more static obstacles located within one or more geographic areas. A “static obstacle” is a physical object whose location and general properties remain substantially unchanged over a period of time. Examples of static obstacles include trees, buildings, curbs, fences, etc.

[0090] Sensor data 119 is data provided from one or more sensors of sensor system 120. Sensor data 119 may include observations of the surrounding environment of vehicle 100 and / or information about vehicle 100 itself. In some cases, one or more data storage devices 115 located on vehicle 100 store at least a portion of map data 116 and / or sensor data 119. Alternatively or additionally, at least a portion of map data 116 and / or sensor data 119 may be located in one or more data storage devices 115 located remotely from vehicle 100.

[0091] As described above, vehicle 100 may include sensor system 120. Sensor system 120 may include one or more sensors. As used herein, a “sensor” is an electronic and / or mechanical device that generates an output (e.g., an electrical signal) in response to physical phenomena such as electromagnetic radiation (EMR), sound, etc. Sensor system 120 and / or one or more sensors may be operatively connected to processor 110, data memory 115, and / or another element of vehicle 100.

[0092] This document will describe various examples of different types of sensors. However, it should be understood that the embodiments are not limited to the specific sensors described. In various configurations, sensor system 120 includes one or more vehicle sensors 121 and / or one or more environmental sensors. Vehicle sensors 121 are used to sense information about the vehicle 100 itself. In one or more arrangements, vehicle sensors 121 include one or more accelerometers, one or more gyroscopes, inertial measurement units (IMUs), dead reckoning systems, global navigation satellite systems (GNSS), global positioning systems (GPS), and / or other sensors for monitoring aspects of the vehicle 100.

[0093] As described above, sensor system 120 may include one or more environmental sensors 122 that sense the surrounding environment of vehicle 100 (e.g., the exterior) and / or, in at least one arrangement, sense the environment of the passenger compartment of vehicle 100. For example, one or more environmental sensors 122 sense objects in the surrounding environment of vehicle 100. Such obstacles may be stationary objects and / or dynamic objects. Various examples of sensors for sensor system 120 will be described herein. Example sensors may be part of one or more environmental sensors 122 and / or one or more vehicle sensors 121. However, it should be understood that embodiments are not limited to the specific sensors described. As an example, in one or more arrangements, sensor system 120 includes one or more radar sensors 123, one or more laser sensors 124, one or more sonar sensors 125 (e.g., ultrasonic sensors), and / or one or more cameras 126 (e.g., monocular, stereo, RGB, infrared, etc.).

[0094] Continue the discussion Figure 1 The vehicle 100 may include an input system 130. The input system 130 typically includes one or more devices capable of acquiring information from external sources (such as an operator). The input system 130 may receive input from vehicle passengers (e.g., driver / operator and / or passengers). Additionally, in at least one configuration, the vehicle 100 includes an output system 135. The output system 135 includes one or more devices, for example, enabling information / data to be provided to external targets (e.g., people, vehicle passengers, another vehicle, another electronic device, etc.).

[0095] Furthermore, in various arrangements, vehicle 100 includes one or more vehicle systems 140. Figure 1 Various examples of one or more vehicle systems 140 are shown. However, vehicle 100 may include different arrangements of vehicle systems. It should be understood that although a particular vehicle system is defined individually, each or any part of the system may be otherwise combined or isolated via hardware and / or software within vehicle 100. As shown, vehicle 100 includes a propulsion system 141, a braking system 142, a steering system 143, a throttle system 144, a transmission system 145, a signaling system 146, and a navigation system 147.

[0096] Navigation system 147 may include one or more devices, applications, and / or combinations thereof to determine the geographic location of vehicle 100 and / or determine the driving route of vehicle 100. Navigation system 147 may include one or more mapping applications to determine the driving route of vehicle 100 based on, for example, map data 116. Navigation system 147 may include or at least provide connectivity to a Global Positioning System, a Local Positioning System, or a Geospatial System.

[0097] In one or more configurations, vehicle system 140 operates collaboratively with other components of vehicle 100. For example, processor 110, safety system 170, and / or autonomous driving module 160 may be operatively connected to communicate with various vehicle systems 140 and / or their individual components. For example, processor 110 and / or autonomous driving module 160 may communicate to send and / or receive information from various vehicle systems 140 to control the navigation and / or maneuvering of vehicle 100. Processor 110, safety system 170, and / or autonomous driving module 160 may control some or all of these vehicle systems 140.

[0098] For example, when operating in autonomous mode, processor 110, safety system 170, and / or autonomous driving module 160 control the heading and speed of vehicle 100. Processor 110, safety system 170, and / or autonomous driving module 160 cause vehicle 100 to accelerate (e.g., by increasing the supply of energy / fuel to the motor), decelerate (e.g., by applying brakes), and / or change direction (e.g., by steering the front two wheels). As used herein, “cause” or “incident” means to directly or indirectly lead to, force, compel, instruct, direct, and / or cause an event or action to occur.

[0099] As shown in the figure, in one configuration, vehicle 100 includes one or more actuators 150. An actuator 150 is, for example, an element operable to move and / or control mechanisms (such as one or more of the vehicle system 140 or components thereof) in response to electronic signals or other inputs from processor 110 and / or autonomous driving module 160. One or more actuators 150 may include motors, pneumatic actuators, hydraulic pistons, relays, solenoids, piezoelectric actuators, and / or another type of actuator that generates the desired control.

[0100] As previously described, vehicle 100 may include one or more modules, at least some of which are described herein. In at least one arrangement, the module is implemented as non-transient computer-readable instructions that, when executed by processor 110, implement one or more of the various functions described herein. In various arrangements, one or more of the modules are components of processor 110, or one or more of the modules execute and / or are distributed on other processing systems operatively connected to processor 110. Alternatively or additionally, one or more modules are implemented at least partially in hardware. For example, one or more modules may include logic gates (e.g., metal-oxide-semiconductor field-effect transistors (MOSFETs)), application-specific integrated circuits (ASICs), programmable logic arrays (PLAs), field-programmable gate arrays (FPGAs), and / or combinations of other electronic hardware-based implementations for implementing the described functions. Furthermore, in one or more arrangements, one or more modules may be distributed among a plurality of modules described herein. In one or more arrangements, two or more modules described herein may be combined into a single module.

[0101] Furthermore, vehicle 100 may include one or more autonomous driving modules 160. In at least one method, autonomous driving module 160 receives data from sensor system 120 and / or other systems associated with vehicle 100. In one or more arrangements, autonomous driving module 160 uses such data to perceive the vehicle's surrounding environment. Autonomous driving module 160 determines the position of vehicle 100 in the surrounding environment and a map aspect of the surrounding environment. For example, autonomous driving module 160 determines the location of obstacles or other environmental features including traffic signs, trees, bushes, adjacent vehicles, pedestrians, etc.

[0102] The autonomous driving module 160 can be configured, independently or in combination with the safety system 170, to determine driving paths, current autonomous driving maneuvers of the vehicle 100, future autonomous driving maneuvers, and / or corrections to current autonomous driving maneuvers based on data acquired by the sensor system 120 and / or another source. Typically, the autonomous driving module 160 is used to, for example, implement different levels of automation, including advanced driver assistance systems (ADAS), semi-autonomous functions, and fully autonomous functions, as previously described.

[0103] The arrangement disclosed herein provides the benefit of ensuring safe operation of the vehicle while preserving the human operator's agency in controlling the vehicle to the greatest extent possible. Furthermore, the arrangement disclosed herein provides the benefit of notifying the vehicle operator of any actions the vehicle may take if unsafe operator input is assessed.

[0104] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are intended to be illustrative only. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but rather serve as the basis for the claims and as a representative basis for teaching those skilled in the art to flexibly adopt the aspects of this document with virtually any appropriately detailed structure. Furthermore, the terminology and phrases used herein are not intended to be limiting, but rather to provide an understandable description of possible implementations. Various embodiments are described in... Figures 1 to 6 The embodiments are shown, but the embodiments are not limited to the structures or applications shown.

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative embodiments, the functions marked in the blocks may occur in a different order than indicated in the diagrams. For example, depending on the functions involved, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order.

[0106] The systems, components, and / or processes described above may be implemented in hardware or a combination of hardware and software, and may be implemented centrally in a single processing system or distributed in several interconnected processing systems with different components distributed among them. The systems, components, and / or processes may also be embedded in computer-readable storage devices, such as computer program products or other data program storage devices, which are machine-readable and tangibly embody machine-executable instructions for performing the methods and processes described herein. These components may also be embedded in application products that include features enabling the implementation of the methods described herein and, when loaded into a processing system, are capable of executing those methods.

[0107] Furthermore, the arrangements described herein may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied (e.g., stored thereon). Any combination of one or more computer-readable media may be utilized. The phrase "computer-readable storage medium" means a non-transient storage medium. A computer-readable storage medium may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. A non-exhaustive list of computer-readable storage media may include: portable computer disks, hard disk drives (HDDs), solid-state drives (SSDs), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), optical storage devices, magnetic storage devices, or combinations thereof. In the context of this document, a computer-readable storage medium is, for example, a tangible medium that stores a program for use by or in connection with an instruction execution system, apparatus, or device.

[0108] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic, cable, RF, or any suitable combination thereof. The computer program code used to perform the operations of various aspects of this arrangement may be written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as the "C" programming language or similar programming languages). The program code may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0109] As used herein, the terms “basic” or “about” precisely include the terms they modify and their slight variations. Thus, the term “basically parallel” means completely parallel with and with slight variations. “Slight variations” can include within 15 degrees / percentage / unit or less, within 14 degrees / percentage / unit or less, within 13 degrees / percentage / unit or less, within 12 degrees / percentage / unit or less, within 11 degrees / percentage / unit or less, within 10 degrees / percentage / unit or less, within 9 degrees / percentage / unit or less, within 8 degrees / percentage / unit or less, within 7 degrees / percentage / unit or less, within 6 degrees / percentage / unit or less, within 5 degrees / percentage / unit or less, within 4 degrees / percentage / unit or less, within 3 degrees / percentage / unit or less, within 2 degrees / percentage / unit or less, or within 1 degree / percentage / unit or less. In some examples, “basic” can include within normal manufacturing tolerances.

[0110] As used herein, the terms “a” and “an” are defined as one or more. As used herein, the term “multiple” is defined as two or more. As used herein, the term “another” is defined as at least a second or more. As used herein, the terms “including” and / or “having” are defined as including (i.e., open-ended language). The phrase “…at least one” as used herein refers to and covers any and all possible combinations of one or more associated listed items. As an example, the phrase “at least one of A, B, and C” includes only A, only B, only C, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0111] The aspects of this document may be embodied in other forms without departing from its spirit or essential nature. Therefore, reference should be made to the following claims, rather than the foregoing description, to indicate its scope.

Claims

1. A security system, comprising: processor; as well as A memory that communicates with the processor and stores modules including instructions that, when executed by the processor, cause the processor to perform the following operations: Receive input from the vehicle operator intended to control the vehicle; The safety of the input is evaluated using a state-action function that quantifies the safety of the input based on the current state of the vehicle. The vehicle actions are optimized based on the aforementioned safety, and the vehicle actions are corrected by minimizing the deviation between the input and the vehicle actions; as well as The vehicle actions are performed based on the aforementioned safety considerations to control the vehicle, thereby maintaining safety while preserving human agency to the greatest extent possible.

2. The security system according to claim 1, wherein, The instructions for optimizing the vehicle's actions include instructions that minimize the squared difference between the input and the vehicle's actions.

3. The security system according to claim 1, wherein, The instructions for assessing the safety include instructions for assessing the safety based on safety constraints, which are model-free discrete-time control obstacle functions that ensure the state-action function of the vehicle action satisfies a threshold derived from the current state function.

4. The security system according to claim 3, wherein, The module also includes instructions to execute the input in response to a determination that the security constraints are satisfied.

5. The security system according to claim 3, wherein, The threshold defines the constraints on the vehicle's actions within the maximum safe set when the threshold is met. The maximum safe set includes the states of the vehicle in which there exists a control strategy to prevent the vehicle from entering an unsafe state.

6. The security system according to claim 1, wherein, Maintaining safety while preserving human agency to the greatest extent possible includes using automatic controls to correct the inputs provided by the operator to generate shared controls for operating the vehicle, thereby maintaining the operator's sense of control over the vehicle.

7. The security system according to claim 1, wherein, The module also includes displaying visual cues within the vehicle to describe to the driver the direction and magnitude of the vehicle's movements relative to the input.

8. A non-transient computer-readable medium comprising instructions that, when executed by a processor, cause the processor to perform the following operations: Receive input from the vehicle operator intended to control the vehicle; The safety of the input is evaluated using a state-action function that quantifies the safety of the input based on the current state of the vehicle. The vehicle actions are optimized based on the aforementioned safety, and the vehicle actions are corrected by minimizing the deviation between the input and the vehicle actions; as well as The vehicle actions are performed based on the aforementioned safety considerations to control the vehicle, thereby maintaining safety while preserving human agency to the greatest extent possible.

9. The non-transient computer-readable medium according to claim 8, wherein, The instructions for optimizing the vehicle's actions include instructions that minimize the squared difference between the input and the vehicle's actions.

10. The non-transient computer-readable medium according to claim 8, wherein, The instructions for assessing the safety include instructions for assessing the safety based on safety constraints, which are model-free discrete-time control obstacle functions that ensure the state-action function of the vehicle action satisfies a threshold derived from the current state function.

11. The non-transient computer-readable medium according to claim 10, wherein, The instructions also include instructions to execute the input in response to a determination that the security constraint is satisfied.

12. The non-transient computer-readable medium according to claim 10, wherein, The threshold defines the constraints on the vehicle's actions within the maximum safe set when the threshold is met. The maximum safe set includes the states of the vehicle in which there exists a control strategy to prevent the vehicle from entering an unsafe state.

13. The non-transient computer-readable medium according to claim 8, wherein, Maintaining safety while preserving human agency to the greatest extent possible includes using automatic controls to correct the inputs provided by the operator to generate shared controls for operating the vehicle, thereby maintaining the operator's sense of control over the vehicle.

14. A security method comprising: Receive input from the vehicle operator intended to control the vehicle; The safety of the input is evaluated using a state-action function that quantifies the safety of the input based on the current state of the vehicle. The vehicle actions are optimized based on the aforementioned safety, and the vehicle actions are corrected by minimizing the deviation between the input and the vehicle actions; as well as The vehicle actions are performed based on the aforementioned safety considerations to control the vehicle, thereby maintaining safety while preserving human agency to the greatest extent possible.

15. The security method according to claim 14, wherein, Optimizing the vehicle action involves minimizing the squared difference between the input and the vehicle action.

16. The security method according to claim 14, wherein, Assessing the safety includes evaluating the safety based on safety constraints, which are model-free discrete-time control obstacle functions that ensure the state-action function of the vehicle's actions satisfies a threshold derived from the current state function.

17. The security method according to claim 16, wherein, It also includes executing the input in response to a determination that the security constraints are satisfied.

18. The security method according to claim 17, wherein, The threshold defines the constraints on the vehicle's actions within the maximum safe set when the threshold is met. The maximum safe set includes the states of the vehicle in which there exists a control strategy to prevent the vehicle from entering an unsafe state.

19. The security method according to claim 14, wherein, Maintaining safety while preserving human agency to the greatest extent possible includes using automatic controls to correct the inputs provided by the operator to generate shared controls for operating the vehicle, thereby maintaining the operator's sense of control over the vehicle.

20. The security method according to claim 14, wherein, It also includes displaying visual cues within the vehicle to depict to the driver the direction and magnitude of the vehicle's movements relative to the input.

Images