Automatically generate control decision logic for complex engineering systems from dynamic physical models

Abstract

Iterating over possible combinations of input values ​​predicted by the engineering system, for the possible combinations of input values, including: selecting an action to be performed on the engineering system for the possible combinations of input values, including: scoring a plurality of predictions of the engineering system by evaluating an objective function associated with the engineering system and using the possible combinations of input values ​​and the corresponding plurality of actions. Selecting an action from the corresponding plurality of actions, the selection being based at least in part on the scores of the plurality of predictions. Generating a rule—the rule specifying a corresponding set of one or more rule conditions that are satisfied when the possible combinations of input values ​​are matched, and a corresponding action associated with the rule as the selected action. Outputting the generated set of rules for storage or further processing.

Description

[0001] Cross-references to other applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 968,019, filed on January 30, 2020, entitled “AUTOMATIC GENERATION OF CONTROLDECISION LOGIC FOR COMPLEX ENGINEERED SYSTEMS FROM DYNAMIC PHYSICAL MODEL,” which is incorporated herein by reference for all purposes. Background Art

[0003] Computer logic has difficulty controlling complex systems. Self-driving cars and self-driving aircraft will be important and useful, for example, reducing labor expenditures, enhancing human safety, and transporting injured owners closer to medical facilities. However, the physical environment in which cars and aircraft operate makes it challenging to replace human pilots and drivers with digital logic.

[0004] Dynamic environments such as vehicle roads present a huge set of complexities for autonomous navigation. Currently, it is challenging to generate control decision logic that can effectively cope with these complexities. These complexities cause problems due to the cost of computing resources such as processing power, memory, storage and network resources and / or slow response in terms of latency and / or throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.

[0006] Figure 1 is a functional diagram illustrating a programmed computer / server system for automatic rule generation according to some embodiments.

[0007] Figure 2 is a block diagram illustrating an embodiment of a control system.

[0008] Figure 3 is a block diagram illustrating an embodiment of a rule-based system.

[0009] Figure 4 is a diagram of an embodiment of a reactive rules engine.

[0010] Figure 5 is an illustration of an embodiment of a reactive rules engine in a monitored system.

[0011] Figure 6 is an illustration of a navigation channel in an example autonomous vehicle application.

[0012] Fig. 7A , Figure 7B and Figure 7C An example of a graded channel for stock trading is illustrated.

[0013] Fig.7D An example of a graded waterway for medical applications is illustrated.

[0014] Figure 8 is an illustration of a channel maneuver for an autonomous vehicle example.

[0015] Fig. 9 is a block diagram illustrating an embodiment of control system pipeline partitioning.

[0016] Fig.10 is a flow chart illustrating an embodiment of a process for automatically generating control decision logic for a control system.

[0017] Fig.11 is a flow chart illustrating an embodiment of a process for iterating over possible input value combinations.

[0018] Fig.12 is a flow chart illustrating an embodiment of a process for selecting actions to be performed on an engineering system for possible combinations of input values.

[0019] Fig.13 is a flow chart illustrating an embodiment of a process for iteratively selecting actions. DETAILED DESCRIPTION

[0020] The present invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these implementations or any other form that the present invention can take can be referred to as techniques. In general, within the scope of the present invention, the order of steps of the disclosed processes can be changed. Unless otherwise stated, components such as processors or memories described as being configured to perform tasks can be implemented as general components that are temporarily configured to perform tasks at a given time, or are manufactured to perform specific components of the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.

[0021] A detailed description of one or more embodiments of the present invention is provided below, together with the accompanying drawings that illustrate the principles of the present invention. The present invention is described in conjunction with such embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention includes numerous alternatives, modifications and equivalents. In order to provide a thorough understanding of the present invention, numerous specific details are set forth in the following description. These details are provided for illustrative purposes, and the present invention can be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical materials known in the technical field related to the present invention are not described in detail to avoid unnecessarily obscuring the present invention.

[0022] Automatically generating control decision logic for complex engineering systems from dynamic physical models is disclosed. As used herein, an engineering system refers to a system that has been engineered to provide predictable behavior to a human operator (e.g., an engineer of an automobile or aircraft). As part of engineering these engineering systems, dynamic physical models can produce acceptable and predictable behavior. Utilizing dynamic physical models for synthesizing these engineering systems in the automatic generation of logic to control these same systems is disclosed.

[0023] In some embodiments, the dynamic physics model comprises a digital simulation package such as a flight simulator, and may include an objective function that captures the design requirements, giving a quantitative indication of how preferred the results are. The use of a simulator and an objective function to automatically generate logic for control is disclosed.

[0024] The use of discretization to refine the automatic generation of control decision logic is disclosed. For example, while a digital computer has the ability to set airspeed to extremely high precision, such as 300.0 knots, 300.1 knots, 300.2 knots, etc., a human pilot does not necessarily fly an aircraft with such precision, and then the aircraft's engineering systems allow the pilot to achieve the goal of stable flight with much lower precision. Using discretization to reduce this precision by many orders of magnitude - for example, flying the aircraft at a small number of speeds including taxi speed (~50 knots), takeoff speed (~500 knots), and cruising speed (~350 knots) - may be sufficient for control of important piloting scenarios.

[0025] The use of pipeline stages to refine the automatic generation of control decision logic is disclosed. For example, driving a car from home to the theater can embody different goals. Pipeline partitioning can address each of these goals: the long-term / strategic goal of determining current traffic congestion and freeway closures to determine the selected path; the short-term / tactical goal of driving along the selected path and handling roadblocks, traffic jams, or emergency vehicles; and the near-instant / responsive goal of avoiding children suddenly running out of traffic or trucks suddenly overtaking.

[0026] The use of a prune function to refine the automatic generation of control decision logic is disclosed. To a human operator, there may be control system logic that may appear irrelevant or "stupid" to consider which may be pruned using such a prune function. For example, if a sensor detects that an aircraft is flying below a desired altitude, control variables including lowering the elevator a little, lowering the elevator a lot, and lowering the elevator the maximum amount will all lower the nose of the aircraft and further reduce altitude, and therefore may be pruned without further consideration.

[0027] Figure 1 is a functional diagram illustrating a programmed computer / server system for automatic rule generation according to some embodiments. As shown, Figure 1 A functional illustration of a general purpose computer system programmed for automatic rule generation according to some embodiments is provided. As will be clear, other computer system architectures and configurations may be used for automatic rule generation.

[0028] The computer system 100, which includes various subsystems as described below, includes at least one microprocessor subsystem, also referred to as a processor or central processing unit ("CPU") (102). For example, the processor (102) may be implemented by a single-chip processor or multiple cores and / or processors. In some embodiments, the processor (102) is a general-purpose digital processor that controls the operation of the computer system 100. Using instructions retrieved from a memory (110), the processor (102) controls the receipt and manipulation of input data and the output and display of data on output devices, such as a display and a graphics processing unit (GPU) (118).

[0029] The processor (102) is bidirectionally coupled to a memory (110), which may include a first main storage area, typically a random access memory ("RAM"), and a second main storage area, typically a read-only memory ("ROM"). As is known in the art, the main storage device can be used as a general storage area and a scratch-pad memory, and can also be used to store input data and processed data. In addition to other data and instructions for processes operating on the processor (102), the main storage device can also store programming instructions and data in the form of data objects and text objects. As is also known in the art, the main storage device generally includes basic operating instructions, program code, data, and objects, such as programming instructions, used by the processor (102) to perform its functions. For example, depending on whether data access requires bidirectional or unidirectional, the main storage device (110) may include any suitable computer-readable storage medium, as described below. For example, the processor (102) can also directly and very quickly retrieve frequently required data and store it in a cache memory (not shown). The processor (102) may also include a co-processor (not shown) as a supplemental processing component to assist the processor and / or the memory (110).

[0030] The removable mass storage device (112) provides additional data storage capacity for the computer system 100 and is coupled to the processor (102) bidirectionally (read / write) or unidirectionally (read-only). For example, the storage device (112) may also include computer readable media such as flash memory, portable mass storage devices, holographic storage devices, magnetic devices, magneto-optical devices, optical devices, and other storage devices. The fixed mass storage device (120) may also provide additional data storage capacity, for example. An example of a mass storage device (120) is an eMMC or microSD device. In one embodiment, the mass storage device (120) is a solid state drive connected by the bus (114). The mass storage devices (112), (120) typically store additional programming instructions, data, etc. that are not typically actively used by the processor (102). It will be appreciated that if desired, the information stored within the mass storage devices (112), (120) can be incorporated as part of the main storage device (110) in a standard manner, such as RAM as virtual memory.

[0031] In addition to providing processor (102) with access to the storage subsystem, bus (114) may also be used to provide access to other subsystems and devices. As shown, these may include a display monitor (118), a communication interface (116), a touch (or physical) keyboard (104), and one or more auxiliary input / output devices (106), including an audio interface, a sound card, a microphone, an audio port, an audio recording device, a sound card, a speaker, a touch (or pointing) device, and / or other subsystems as desired. In addition to a touch screen and / or capacitive touch interface, auxiliary device (106) may be a mouse, stylus, trackball, or input tablet, and is useful for interacting with a graphical user interface.

[0032] The communication interface (116) allows the processor (102) to be coupled to another computer, computer network, or telecommunication network using a network connection as shown. For example, through the communication interface (116), the processor (102) can receive information from another network, such as a data object or program instruction, or output information to another network during the execution of a method / process step. Information, which is generally represented as a sequence of instructions to be executed on the processor, can be received from another network and output to another network. An interface card or similar device and appropriate software implemented by the processor (102) (e.g., implemented / executed on the processor (102)) can be used to connect the computer system 100 to an external network and transmit data according to a standard protocol. For example, various process embodiments disclosed herein can be implemented on the processor (102), or can be executed across a network such as the Internet, an intranet, or a local area network in conjunction with a remote processor that shares a portion of the processing. Throughout this specification, "network" refers to any interconnection between computer components, including the Internet, Bluetooth, WiFi, 3G, 4G, 4GLTE, GSM, Ethernet, TCP / IP, Intranet, Local Area Network ("LAN"), Home Area Network ("HAN"), Serial Connection, Parallel Connection, Wide Area Network ("WAN"), Fibre Channel, PCI / PCI-X, AGP, VLbus, PCI Express, Expresscard, Infiniband, ACCESS.bus, Wireless LAN, HomePNA, Fiber Optic, G.hn, Infrared Network, Satellite Network, Microwave Network, Cellular Network, Virtual Private Network ("VPN"), Universal Serial Bus ("USB"), FireWire, Serial ATA, 1-Wire, UNI / O, or any form of homogeneous, heterogeneous systems and / or groups of systems connected together. Additional mass storage devices not shown may also be connected to the processor (102) via the communication interface (116).

[0033] An auxiliary I / O device interface (not shown) may be used in conjunction with the computer system 100. The auxiliary I / O device interface may include general and customized interfaces that allow the processor (102) to send and more typically receive data from other devices such as microphones, touch-sensitive displays, transducer card readers, magnetic tape readers, voice or handwriting recognizers, biometric readers, cameras, portable mass storage devices, and other computers.

[0034] In addition, various embodiments disclosed herein further relate to a computer storage product with a computer-readable medium, which includes program codes for performing various computer-implemented operations. A computer-readable medium is any data storage device that can store data, which can then be read by a computer system. Examples of computer-readable media include, but are not limited to, all of the media mentioned above: flash media, such as NAND flash, eMMC, SD, compressed flash; magnetic media, such as hard disks, floppy disks, and tapes; optical media, such as CD-ROM disks; magneto-optical media, such as optical disks; and specially configured hardware devices, such as application-specific integrated circuits ("ASICs"), programmable logic devices ("PLDs"), and ROM and RAM devices. Examples of program code include both machine code, such as generated by a compiler, or files containing higher-level code (such as scripts that can be executed using an interpreter).

[0035] Figure 1 The computer / server system shown in is merely an example of a computer system suitable for use with the various embodiments disclosed herein. Other computer systems suitable for such use may include additional or fewer subsystems. In addition, the bus (114) is illustrative of any interconnection scheme that serves to link the subsystems. Other computer architectures with different subsystem configurations may also be utilized.

[0036] The engineering systems described herein are designed to operate according to a dynamic physical model. For example, a refrigeration system operates by the usual principles of refrigeration, stated simply: running a compressor gradually lowers the temperature in the refrigerated space by transferring its heat away. Many engineering systems are analog systems because the real world is continuous. Refrigeration is an example because the temperature and pressure produced by the compressor are continuous values.

[0037] The engineering of such a system requires the provision of components with known capacities and power requirements. Thus, for a given space to be cooled and a given refrigeration system, if its heat gain characteristics from the external environment and the starting temperature are known, a computer simulation can be used to receive one or more inputs and predict with a certain level of accuracy the effect of the refrigeration compressor operating over a given period of time T. In essence, the engineered system may require a dynamic physical model that allows its performance to be predicted in terms of both dynamic capacity and resource requirements. Otherwise, the system may not have predictable performance and cost, which is unacceptable in most applications.

[0038] An engineering system may also have an objective function, such as a measure of how well it is achieving its desired goals / design requirements. In the example case of a refrigeration system, informally, the objective function is a measure of how well it is maintaining the temperature within a specified range with a minimum amount of energy and wear on the equipment and / or providing maximum comfort for humans or other items within the refrigerated space. As part of the design of an engineering system, it is common to have an objective function and develop a dynamic physical model that is typically mapped to the design as a computer simulation and then evaluated for its performance relative to the objective function to see if the design is adequate to meet the requirements. Such a computer simulation may have an API (application programming interface) or other interface to allow third parties other than the design team to model the system.

[0039] In the case of the simple example of a refrigeration system, the control logic is simple, i.e., if the temperature is too high, the compressor power is turned on, and if the temperature is low enough, the compressor power is turned off. However, for control systems in more complex environments with more control variables, generating control algorithms is much more complex. For example, the control algorithm used to fly an aircraft involves more degrees of freedom, more control variables, and more complex behaviors of the controlled system, coupled with the significant complexity of the environment such as wind, dynamic obstacles, etc. Nevertheless, there is still an objective function that can be applied, i.e., maintaining the desired trajectory when there are no obstacles, and avoiding obstacles when obstacles exist. Another example is controlling an autonomous land vehicle. The same characteristics used to fly an aircraft also apply to controlling an autonomous vehicle, although as part of the control, attention should be paid to the fact that there are often more obstacles and more obstacles that are in closer proximity.

[0040] One traditional approach for these complex control systems is to manually write the control software in imperative code (using statements to change the state of the program, such as C++), which can result in complex code that is expensive to develop, maintain, and extend. It is also error-prone and difficult to test: there are an enormous number of possible scenarios, far exceeding the practical number covered in a test sequence. For example, consider the essentially infinite number of scenarios that an autonomous vehicle may encounter in terms of input variables, even if confined to driving on roads. Thus, in practice, testing may only cover a very small percentage of the possible scenarios.

[0041] Another traditional approach is to use so-called machine learning to effectively automate the generation of control software by using a neural network-based implementation. This approach reduces the development cost down to the cost of coming up with a training set of scenarios and then training the neural network for that training set. However, the training set itself is a very small subset of possible scenarios, so the training achieves the equivalent of very limited testing.

[0042] Furthermore, the resulting control network is a "black box" in the sense that its behavior is unpredictable unless the input exactly matches one of the input training set. For example, there is no means of identifying the boundary conditions against which to test it. In contrast, for a manually generated procedure, if it contains an "if" statement such as:

[0043]

[0044] The test can then be divided into two cases, with the temperature above the limit and with the temperature below the limit. If there are no other dependencies on the temperature in the control software, it is sufficient to test with two temperature values, either above the limit or below the limit, to at least verify what the control software does in these two cases. There is no need to test all temperature values. For neural networks of a certain complexity, identifying dependencies between these boundary conditions and the input is not feasible, because the output is a complex function of the weights and the floating-point inputs.

[0045] The control action possibilities of complex control systems are often very simple, especially when designed to be operated by humans. For example, for an autonomous land vehicle, the controls are basically just the steering angle, throttle position, and brake position. Therefore, the real complexity of the control system lies in the decision logic that determines how to set the control variables that control these actions, such as what appropriate steering angle to choose given the input conditions. Automatic generation of control decision logic for complex engineering systems when there is a computable objective function is disclosed.

[0046] Figure 2 is a block diagram of an embodiment of a control system. In one embodiment, Figure 2 The control system (202) is as follows Figure 1 The computer system shown in . Figure 2 As shown in , the control system (202) accepts inputs such as operator command inputs and configuration files from sensors (204), current system (206) status, and other modules (208), determines an action, and outputs the action(s) to the actuator through the setting of control variables (210).

[0047] Figure 3 is a block diagram illustrating an embodiment of a rule-based system. In one embodiment, Figure 3 The control system (202) is Figure 2 A control system (202). Figure 3 As shown in FIG. 1 , when (one or more) specific conditions (304) match the rule conditions, for example, by a rule execution engine (306), the rule set specifies (one or more) actions (302) to be performed by the control system in response to the (one or more) specific conditions (304). The specific conditions can be a combination of input values, such as from sensor inputs (204), the state of the engineering system (206) / control system (202), and / or other modules ( Figure 2 This action can be achieved by setting a control variable (210), such as setting a set point of a PID (proportional-integral-derivative) controller that controls the throttle of the aircraft (206).

[0048] exist Figure 3 In the example, rules governing the decision logic of the control system (202) can be automatically generated before the control system (202) is executed. These rules can then be used to implement the control system (202). In various embodiments, the implementation can use a conventional rule execution engine (306), a table matching implementation, compiling rules into " ” structure that evaluates rule conditions and executes associated actions and / or any other appropriate implementation.

[0049] Reactive rule engines. Similarly, rule engines typically repeatedly poll the entire rule set to check rule conditions for true in order to detect rule actions that may trigger. However, this approach suffers from the typical tradeoff between the overhead of rapid polling and the delay in detecting conditions that may trigger an action. In particular, higher frequency polling to minimize the delay in triggering an action introduces a large amount of overhead, while lower frequency polling to reduce that overhead increases the delay in triggering after the condition becomes true. An alternative approach supported by explicit rule condition code is to have a reactive implementation in which input attribute changes trigger an immediate re-evaluation of the rule conditions that depend on that input. Thus, if the rule condition for the action now becomes true, the action can be executed without delay. Such a reactive implementation is described below.

[0050] Reactive rule engine implementation. Rule engines traditionally repeatedly poll the entire rule set to check for true rule conditions in order to detect rule actions that may be triggered. However, this approach suffers from the typical tradeoff between the overhead of rapid polling and the latency of detecting conditions that may trigger an action. In particular, higher frequency polling to minimize latency in triggering an action introduces significant overhead, while lower frequency polling to reduce that overhead increases the latency of triggering after a condition becomes true. An alternative approach supported by explicit rule condition code is to have Reactive Implementation In this reactive implementation, input property changes trigger an immediate re-evaluation of rule conditions that depend on that input. Thus, if the rule condition for the action now becomes true, the action can be executed without delay.

[0051] In one embodiment, the compiler outputs code that implements a reactive rule engine. It can be reactive in the sense that it reacts directly to input changes and executes actions (if any) associated with rule conditions that become true as a result of the input changes.

[0052] Figure 4 is a diagram of an embodiment of a reactive rule engine. Figure 4 As shown in , the reactive rule engine is implemented as a "listener" module (404). A "listener" or equivalently an "observer" (404) is a traditional software design pattern in object-oriented programming. Essentially, a listener (404) is a module that is notified via a callback when a certain attribute of interest in one of the "listened" objects (402) has changed. Thus, the listener (404) reacts to changes in element attributes (402) and, if the rule condition is true, adds a rule instance to a matching set (406).

[0053] There are established techniques for manually implementing listener modules in C++ and other languages. In general, in one embodiment, the compiler portion generates code for element types and callback notifications using other techniques, including techniques disclosed in U.S. patent application Ser. No. 12 / 154,354, filed May 21, 2008, entitled “DYNAMIC COLLECTION ATTRIBUTE-BASED COMPUTER PROGRAMMING LANGUAGE METHODS,” which is incorporated herein by reference for all purposes. It further generates a listener module (404) using techniques in U.S. patent application Ser. No. 12 / 154,399, filed May 21, 2008, entitled “NOTIFICATION-BASED CONSTRAINT SET TRANSLATION TO IMPERATIVE EXECUTION,” which is incorporated herein by reference for all purposes, having a callback procedure for each callback notification, i.e., for each modifiable attribute required to evaluate an observable subcondition. In this context, a rule can be viewed as a constraint between a model and a matching set of action labels, requiring that the action label for the rule be in the set of matching sets if the rule condition is true.

[0054] In one embodiment, a listener module (404) is generated to listen to each input property of each element (402a, 402b, ..., 402z) instantiated in the model. Thus, in C++ terms, the compiler defines a class with a data member pointing to each element that the module needs to listen to or respond to, either as a single pointer or as a collection of pointers (if there are multiple such elements of the same type). For each input property ia The compiler also generates a callback function "onia()". Following standard practice in C++, this callback may be in a separate class that is a derivative of the callback interface, which then calls the actual main listener module class. The callback function is generated with code to evaluate each rule condition specified in the model that is affected by this input property. ia Therefore, when the attribute " ia When the (404) The process is called. The process evaluates the rule conditions that depend on the input and outputs an action label for each rule condition that evaluates to true (406).

[0055] Note that, especially for more complex rules, the relationships between objects clarify and / or indicate connectivity. The compiler also generates the necessary data members and collections in the listener module to allow these rule conditions to be evaluated. For example, in one example of a computer network model, a rule condition corresponding to a broken link in a physical network requires knowledge of the "other" interface, i.e., the interface at the other end of the link, to evaluate the rule condition, as illustrated by the following code:

[0056]

[0057] In the above, "notifier" corresponds to the interface element executing the callback, and otherInterface is the interface it is connected to (indirectly through the Link and Unilink objects), as returned by getOtherInterface. Therefore, the compiler can generate code to store and maintain a collection in the listener module that can hold connected interface pairs. Therefore, when the above condition is evaluated as part of executing the callback function, the "otherInterface" variable in the above code is set to the interface that the "notifier" interface is connected to by accessing the collection.

[0058] Notice, Input properties Specified as inputs in the model, but may be complex calculations from actual system inputs. For example, an input attribute may be a weighted moving average of some raw sensor value that is updated only when the average changes by a significant amount. Therefore, the actual input may change more frequently and by more significant amounts than the input attribute used in the model.

[0059] In one embodiment, the listener module (404) is implemented as a derived class of a base class (in C++ terms) that defines and implements an action program. For example, an action can be manually specified in C++ as follows:

[0060]

[0061] That is, the (generated) RuleModule is a derived class of ActionModule that can be explicitly programmed so that it has access to the "protected" action procedures provided by the ActionModule. Then, as described earlier, rule evaluation code can be generated for each input property, and calls to action procedures only call those specified in the ActionModule, which is incorporated into the Rule Module through inheritance.

[0062] In one embodiment, selected portions of the listener module code may be provided by manual programming. For example, by specifying "external" in a rule condition, automatic generation does not generate a rule condition for that rule, but instead assumes / relies on manually specified code to handle that condition. This provision recognizes that for a particular application, some special optimizations that are beyond the scope of compiler support are often required.

[0063] Figure 5 is a diagram of an embodiment of a reactive rules engine in a monitored system. Figure 5 It shows how a reactive rules engine (400) structured as a listener module (404) and an action execution module (408) is connected to a monitored system (502 to 508). Figure 5 In the example of FIG. 4 , sensors (504) provide measurements of values ​​associated with the monitored system (502), such as temperature, humidity, orientation, velocity, and the like. These values ​​are collected by a telemetry system (506), which delivers them for input processing (508), which can take several actions on the input. For example, it can convert sensor input values ​​from one measurement to another, such as from A / D units to temperature in degrees Celsius. It can also interpolate or extrapolate sensor values ​​in the case of missing values, or smooth or correct sensor values ​​in the case of spikes or erroneous values ​​that may be due to sensor transients. In this case, it can provide calculated values ​​from the input, such as a weighted moving average for a certain input. It can also discretize the input stream into a small number of discrete values ​​defined by thresholds, such as, for example, cold, cool, warm, and hot for temperature readings. Thus, the reactive rule engine (400) only reacts to temperature changes that cross a threshold. Finally, it can retain input values ​​from the listener (404) until some specified period or round to support periodic polling of rules rather than reacting to every input change, as described later. That is, the mapping can limit the reactive rule engine to only react to threshold crossings to reduce noise, retain input values ​​to reduce noise, and so on.

[0064] In one embodiment, if multiple rule conditions depend on the same input property, the compiler generates these rule conditions in the same callback function.

[0065] To identify rule conditions in a matching set that are no longer valid, a periodic process can test the set of matching rule conditions and remove the set of matching rule conditions from the set if it is no longer valid and / or when an element "bar" changes, which can prompt a re-evaluation of any rule conditions (RCs) in the set that depend on that element. In embodiments where only a single independent rule condition should be true at any time, a match to a different rule condition can instantly remove the existing rule condition (if any) from the matching set.

[0066] In one embodiment, as an optimization, the compiler can identify the case of an object in the model that exists entirely for constant rules and does not correspond to any input. For example, a cable in a network typically does not have a sensor on it and is therefore modeled without an input indicator. It exists only to provide a context for specifying one or more rule conditions and their meanings. In these cases, the compiler can optimize away these objects by folding relationships so that objects with observed symptoms are evaluated directly. For example, in the example of a computer network, Link and Unilink objects can be optimized away, and the interconnections between interfaces can be recorded directly in the Interface object. In particular, with this optimization, the interface contains the attribute "otherInterface", which points to the interface to which it is connected. In the special case of a relationship like "parent", the parent is easily determined from the component element through the usual parent back pointer.

[0067] Non-binary relations can be decomposed into binary relations, so the above method can also be used to handle ternary relations / parameters. When the reactive rule engine software is initially executed, the generated objects can be instantiated with initial values ​​for input attributes that do not exist in practice. The rule engine process and these input attributes can then be connected to actual telemetry, which causes these input attributes to be changed to different values, thereby causing the reactive behavior to match the rule conditions as described earlier, and then calling the relevant (one or more) rules (if any).

[0068] In one embodiment, the compiler optimizes the generated code in the callback function to reduce execution time and code size. For example, in the above code snippet, if another rule condition requires "otherInterface", the generated code will be optimized to access the value once from the above collection and use the value for both rule conditions.

[0069] As another candidate for optimization, sub-expressions involving the input attributes of the notification can be tested first before performing the actions necessary to evaluate the remaining rule conditions. For example, the above code snippet can be optimized as follows:

[0070]

[0071] Where getOtherInterface is a procedure that returns another interface.

[0072] Nesting the getOtherInterface inside the "if" block means that the getOtherInterface procedure call is only executed if the notifier's lossOfSignal property is true. In the expected common case, this property is likely to be false, thus saving the cost of this call.

[0073] A further optimization is to identify common sub-expressions in the rule conditions being evaluated. For example, a rule condition corresponding to a unidirectional cable disconnect corresponds to a loss of signal at one end but not the other. That is,

[0074]

[0075] By identifying common subexpressions, the rule condition can be optimized according to the following code:

[0076]

[0077] In one embodiment, the compiler may determine that one or more parameters for a regular expression may be determined based on attributes in one or more elements. For example, in the running example of the network, an Interface instance may have a pointer to the Unilink instance to which it is connected, and a Unilink instance may have a pointer to the interface to which it is connected. In addition, the interface must specify an inverse relationship, such as the connectedToBy relationship in Interface. Therefore, the compiler may generate a C++-like implementation of getOtherInterface as follows:

[0078]

[0079] The program follows these pointers, using the state in these network elements to return "otherInterface" rather than having a separate set of interface pairs, thereby avoiding the associated state overhead.

[0080] In one embodiment, the reference attribute is a collection. For example, in a broadcast network, an interface may be viewed as connected to multiple different interfaces. In such a case, the rule condition may be evaluated in an iterative loop, where for each iteration of the loop, the value of "otherInterface" is set to the next other interface.

[0081] In one embodiment, an element type can be defined as another element type derivedType, similar to the inheritance mechanism in most object-oriented languages. A derived type can add additional subconditions on top of the subconditions of the base class. It can also extend or override the meaning of subconditions provided in the base class. In specific cases, a derived type subcondition can correspond to an extended or refined version of a rule condition in the base class. Such a derived rule condition can extend or refine the observed subconditions of the base rule condition. For example, a base rule can specify its rule condition to imply the observed subconditions SC0 and SC1, so its conditional expression is:

[0082]

[0083] The derivation rule can specify the sub-conditional meaning that further leads to SC2, so its conditional expression is:

[0084] .

[0085] In one embodiment, a rule condition may be specified with the same type by specifying that it "extends" an existing rule condition, thereby allowing a derived rule condition to be defined with the same element type as the base rule condition.

[0086] Derived rule conditions can be used with base rule conditions to effectively specify partial matches of sub-conditions. Or conversely, it can be used to avoid situations where a rule condition fails to match when one or more sub-conditions are missing, even though the intended scenario is very likely to be the case. For example, a base rule condition for an object being a stop sign can be a sub-condition of having an observed octagonal shape as well as being red. A derived rule condition can specify an additional sub-condition of a sign being engraved with the word "Stop." Even if the engraving cannot be read, the object can still be identified as a stop sign, but if the engraving can be read, the object is identified as a stop sign with a high degree of confidence. The derivative relationship between these rule conditions provides an indication that suppresses matching with the base rule condition when the derived rule condition matches.

[0087] In one embodiment, the compiler can automatically generate derived rule conditions based on inference, i.e., back propagation of sub-conditions, as described above for back propagation of symptoms. In particular, the compiler can add observed sub-conditions in derived rule conditions that may be false, thereby distinguishing the specified rule conditions from other rule conditions that otherwise overlap in the observed sub-conditions, causing them to trigger.

[0088] The above optimization can be used to optimize the code for handling the evaluation of the base condition and (one or more) derived conditions. In the simple case, the code is structured as follows:

[0089]

[0090]

[0091] That is, the derived rule conditions are evaluated only if the base rule conditions are true.

[0092] In one embodiment, action mapping / conflict resolution recognizes situations where both base and derived action labels are present, and only executes the action associated with the most derived rule condition.

[0093] In one embodiment, the input sub-conditions can be defined as expressions based on the actual input attributes. For example, a switch can have Attributes, not Boolean input property. The signal loss from the input is then indicated by the expression

[0094] .

[0095] In the model, this can be expressed as:

[0096]

[0097] In one embodiment with input sub-conditional expressions, as an optimization, the compiler generates code such that it performs a true check of the sub-condition associated with the notification for the notification before performing the associated rule evaluation. That is, as an example, if a change in signalInLevel is notified, the callback returns immediately if the value is greater than or equal to "minSignalLevel".

[0098] In one embodiment as described above, as an optimization, the compiler generates code to evaluate the input subcondition before calling the callback, and calls the callback only if it is true.

[0099] The method used by the compiler to generate rule evaluation code can be described as follows:

[0100]

[0101] Step 1: Populate the OSS. In one embodiment, the OSS is represented as a directed acyclic graph (DAG), and the leaves of the DAG are associated with rule conditions RC.

[0102] In step 2 above, it is assumed that standard compiler technology has an internal data structure representation of "if" and "else" statements. In addition, OSS is just a data structure that represents the logical connection of sub-conditions, similar to the parse tree structure inside many compilers. With this representation, additional statements can be added to the body of the "if" statement in the same way as such a data structure is usually built by parsing the input. The main difference is that the rule condition is embedded in an "if" or "else" statement, which is conditional on the input attribute IA, rather than being placed entirely on the parsed input as in ordinary programming languages. In addition, the compiler needs to determine the access path to other values ​​required to evaluate the rule condition, for example, in our network example, determine how to access "otherInterface". However, this access path can be determined by the relationship of the current rule condition transition to the sub-condition and the relationship from the current rule condition to these other sub-conditions. In particular, for each other sub-condition SCi, it uses the inverse relationship to access back to the rule condition scope, and uses the implicit relationship to these other sub-conditions to build a path to access the data required for each sub-condition. In one embodiment, the compiler must evaluate the access path, in part to find other interfaces. Therefore, the compiler can use the DAG to determine the access path by inverting the relations.

[0103] The steps to generate the code for finding the corresponding element or elements for a given parameter of the go condition are:

[0104] a. Make the input sub-condition the current sub-condition

[0105] b. Find the inverse relation of the relation that implies the current sub-condition. (e.g. Figure 2 , and thus indicate the inverse relationship in the model.)

[0106] c. Generate code that processes each element in the inverse relation as follows (a "for" loop if it is a set, or an "if" conditional if it is a singleton (the singleton is allowed to be empty)):

[0107] i. Get the subcondition that implies the current subcondition, if any. Usually there is a single such subcondition, so this is specified as such in the code in these cases.

[0108] ii. Follow the implied relationships implied by that sub-condition, proceeding to the input attribute, excluding the relationship corresponding to the inverse relationship just traversed. (In the case of "otherInterface", there are no other relationships except the case of the rule condition itself.) Record the input attribute value used as the argument to the condition.

[0109] iii. If the sub-condition corresponds to the rule condition, parameter generation is complete.

[0110] iv. Otherwise, recursively call the procedure on the subcondition.

[0111] For example, in the case of the example computer network, it is known that the input property of "lossOfSignalInEth14" will be implied by the interface named "eth14" from the "lossOfSignalIn" subcondition. The latter has no other meaning. The inverse relationship to the relationship that implies this subcondition is the connectedToBy property, which then provides the inbound Unilink object. Subconditions have The inverse relation implied by the sub-condition is thus terminated by backpropagation across the inverse relation. The rule condition implies across a Link component that is of type Unilink. Because there are two such components, it is obvious that there is a single "other" component, namely the other Unilink instance, given one that can correspond to a relation inverse to the other, to reach the rule condition. A forward traversal of this "other" Unilink component yields the "other" interface to which the Unilink component is connected, which is the parameter required for conditional evaluation in this case. The generated code can be optimized to bypass the Link level and recognize the connectedToUnilink instance as containing the inverse of a pointer to "otherInterface". The result is code that finds "otherInterface" with minimal memory references.

[0112] This same internal compiler data structure representation of the generated code can be used to perform various optimization transformations to reduce code size and improve execution performance using standard compiler optimization techniques as well as other techniques made possible by the structures and specifications in the model.

[0113] The implementation of the remaining subconditions described in the above sequence includes generating code to access the values ​​used by these other subconditions, consistent with the lines described for "otherInterface" in the earlier example.

[0114] In one embodiment, the model is expressed in a general purpose object-oriented language, with the addition of subcondition and the concept of sub-conditional meaning. In another embodiment, rule constructs are added and their meanings are indicated as Boolean expressions. As described above, the compiler is then extended to perform code generation for these rules, sub-conditions and meanings.

[0115] To avoid excessive callback overhead, the input value can be discretized in the input attribute to the condition so that notification occurs only when the value crosses a certain threshold associated with the condition. For example, if the condition specifies temperature as hot as a sub-condition, the temperature sensor can provide a discretized attribute that indicates only "hot" or "cold". Thus, notification is not issued for every minor change in temperature, but only when the input value changes from "cold" to "hot".

[0116] Polling and Polling Optimization. In some applications, the reactive execution of the rule engine incurs excessive overhead due to rapid changes in input values, most of which do not result in any rule triggering. For example, in some applications, rules need to be called only when conditions persist for a period of time, rather than only occurring instantaneously, so rule triggering occurs rarely and / or the vast majority of reactions do not result in useful processing. After a rule is triggered, the condition indicating the trigger tends to persist until the condition is substantially changed. In this hypothetical case, it is not necessary to react to every input change. Instead, the rule engine can periodically reevaluate the rule conditions, rather than reacting to every input change. In one embodiment, the rule engine can call the same generated code to periodically evaluate all rule conditions.

[0117] In one embodiment, periodic evaluation and triggering of rules are provided by updating input attributes to their current values ​​only at the beginning of each cycle. These updates cause rule conditions that depend on input attributes that change due to updates to be (re)evaluated on the current input. Therefore, the same rule engine can be executed periodically and still operate correctly, rather than reacting to changes in each input attribute. In fact, depending on how to configure input processing, the same generated code may be called to be reactive, or called periodically. That is, input processing can be configured to update input attributes when receiving input or only at polling cycle intervals. Note that the above processing assumes that in this application, when the trigger condition is not true at the beginning of the next cycle, it is not a problem to respond to intermediate changes in the input between these cycles without triggering the action. That is, when the condition of the action is only true instantaneously between two execution cycles, the application allows the action to be skipped. In one embodiment, this can be done by freezing all inputs for a period of time and updating them in discrete time periods later.

[0118] In an alternative implementation, the compiler generates the program PP , the program PP When called, each reactive procedure is called with each possible parameter. In this embodiment, the PP The procedure is called at the beginning of each cycle.

[0119] In one embodiment, the implementation of the program is optimized to minimize or avoid repeated rule evaluations. For example, considering the previous example of rule conditions associated with broken links, the program may recognize that the evaluation of a rule condition with an interface pair (intfj, intfi) is the same as the evaluation of a rule condition with an interface pair (intfi, intfj), and therefore only one of them is executed as part of the execution of the program. The embodiment may generate a single optimized pollEvaluate procedure that, when called, implements all rule conditions, outputting indications of rule conditions that are true.

[0120] In general, the same code generation techniques can be used to generate rule engine code for the periodic polling form of execution and for the reactive execution described earlier, and in one embodiment dynamically switched. One of ordinary skill in the art of software programming can recognize that, in addition to those detailed herein, a variety of optimizations can be implemented to allow efficient execution in the case of the polling form of execution.

[0121] A control system as a set of rules. Figure 3 The control system (202) in is logically implemented as a set of rules for controlling the system, where the rules are structured as a conventional condition-action approach. A rule execution engine (306) accepts inputs that allow it to evaluate rule conditions (304). It then periodically or in response to a change in the input (or both) executes the actions (302) associated with one or more rule conditions that evaluate to true, such as Figure 3 As illustrated in , the action sets the control variable (210) to an appropriate value. The effect of repeated evaluation and execution of the rule action is effective control of the system (202) according to the corresponding objective function.

[0122] In one embodiment, the rule condition is evaluated periodically (304), such as every 100 milliseconds. In one embodiment, the rule condition is re-evaluated whenever the input changes. In one embodiment, the rule condition is re-evaluated periodically, but is also re-evaluated when a particular input changes by a significant amount, such as more than a configured threshold.

[0123] In one embodiment, rule condition evaluation is implemented by a matching mechanism, where rule conditions (304) are mapped to symptoms, and root causes correspond to different actions to be taken. Thus, rule condition evaluation can be performed within a predictable period of time. In an alternative reactive implementation, rule conditions can be automatically generated as conventional imperative "if .. else" boxes, as described herein. In either case, the matching mechanism can determine the action to be performed in a few milliseconds or less, which is sufficient for the control of physical systems, as they typically react much more slowly.

[0124] In one embodiment, the rules are automatically generated by a program that iterates over input value combinations (304) and, for each potential input variable value combination IC, selects an action A' (302) that is expected to achieve a good result with respect to the system objective function, and then outputs a rule having a condition corresponding to the input value combination, and the action is the action A'.

[0125] In one embodiment, the selection of action A' is performed by predicting the new state S' of the system at time T2 for each credible action A with input condition IC, assuming it is in a state corresponding to IC at time T1, and it takes action A. After each such prediction, it evaluates the objective function for that new state S', and records the result. After recording the objective function value for each such new state S' for all actions A, it selects the action A' that achieves the best objective function value. In one embodiment, one or two iterative loops can be described in pseudo code as:

[0126]

[0127] For example, if the autonomous aircraft is slightly below the target altitude, possible actions include modifying the flaps, ailerons, and throttle settings. Reducing the throttle is likely to have a negative effect on the target, as is lowering the nose with the flaps, which is determined by the prediction of these action choices. Simply raising the nose of the aircraft may be effective, as long as doing so does not put the aircraft in danger of stalling. The behavior is detected by predicting the behavior of the aircraft with the current airspeed range and the action selection. If the action will produce a stall, the objective function will assign a low rating to the action. The action can include increasing the throttle and adjusting the flaps. Therefore, each generated rule is constructed as a condition that is true for a given combination of input values ​​and an action that has been determined to be optimal for the objective function relative to the input value combination.

[0128] The above predictions are feasible for engineering systems (206) because such systems must be designed to have predictable behavior given a known set of inputs. For example, an aircraft with a given throttle setting, attitude, passenger / cargo weight, airspeed, etc. has reasonably predictable behavior in response to a reduction in throttle. This prediction is typically achieved through the use of a predictive model that is defined as part of the system design. Systems without predictive models have unpredictable behavior, which is unacceptable in many applications. Many engineering systems (206) have reasonably accurate computer simulations of their behavior developed as part of the design process to provide this prediction. The simulation ensures that the behavior of the system, when actually implemented, will meet the application requirements and is therefore not just predictable behavior, but Acceptable Predictable behavior.

[0129] In one embodiment, the prediction is performed by simulating the behavior of the system (206) forward in time, assuming that the current / starting scenario corresponds to the input conditions IC and the actions A being taken. The simulation is typically implemented by a time-stepping simulator that steps the state of the system forward in time based on the inputs and the system model described above. There is not necessarily a closed-form mathematical model of the system's behavior. The simulation software may reasonably include thousands of lines of computer code and may have an available API.

[0130] The objective function is also computable in the engineering system (206) because there is a quantifiable performance measure that the system needs to meet, such as the simple case of a refrigeration zone being kept within a temperature range. "Computable" as referred to herein means that it is feasible to write a software program that returns some numerical measure of performance quality. In some cases, there does not necessarily exist a closed form mathematical function for the objective function. A software-implemented objective function implementation can reasonably be several thousand lines of complex computer source code that performs case analysis on inputs and may have an API available for use by third parties.

[0131] The cost of automatically generating the rule set is significant, but is incurred prior to execution by the control system (202) and is offline, so it does not impact the performance of the control system (202).

[0132] Automatic generation of control decision logic (or Automatically generate ) is that the automatically generated objectives are specified as rules, which are structured as conditions (304) / actions (302) and rule execution means (306) that provide repeated / iterative evaluation of the rules and execution of the associated actions for matching the rules. Using this structure, the automatic generation does not have to deal with arbitrarily complex control flows and algorithms. Instead, it simply determines the actions (302) to be executed under each possible input condition (304) based on the predictive capabilities of the controlled system (206) and the objective function. As mentioned earlier, the rule structure can thereby be compiled into conventional code, or executed as rules by a rule engine. This relies on the characteristics of dynamic control systems, namely that correct execution requires repeatedly responding to changing inputs and adjusting control variables to meet the desired behavior as captured by the objective function.

[0133] Optimizing Automatic Generation. There are at least three aspects that make the techniques described in this article more practical. Automatic generation may seem infeasible: K input, each input takes N value, and when needed T time steps for evaluation A different possible actions, the total number of evaluations of the generated rule set is N of K Multiply by the powerA Multiply T ,Right now , assuming that a different action can be chosen at each time step. For any practical values ​​of these parameters, the total number may appear unrealistically large.

[0134] Aspects that make it more practical are:

[0135] Discretization of input;

[0136] Partitioning control into a pipeline of separate control stages, with each stage having decision logic; and / or

[0137] · Reduction of input value combinations.

[0138] Discretization of inputs and outputs. In one embodiment, the values ​​from the input sources are discretized into a small / limited set of ranges. For example, instead of providing the actual distance to the vehicle ahead in meters as an input to an autonomous vehicle (AV) control system, the distance may be provided in one of five discrete ranges, such as: far (1), near (2), very close (3), close (4), too close (5).

[0139] Discretization of the input means that the set of input value combinations is reduced to a set of range combinations. For example, in the case of the distance example, the original distance when provided in meters could have any one of billions of values, however in the above example, discretization into ranges reduces the cardinality of the input values ​​to 5, i.e. one of 5 values ​​identifying a range corresponding to the distance to the vehicle ahead.

[0140] Discretization means that the rule effectively implements a step function approximation of a continuous function. For example, in the autonomous vehicle (AV) example, there is a continuous formula that determines the degree of braking to apply based on a continuous value of the distance to the vehicle ahead. Discretized ranges of distance mean that the function is approximated using a step size defined by a set of ranges. The more ranges in the set, the better the approximation, but the greater the cost of the automated generation, as this increases the number of input conditions to consider.

[0141] Discretization can also be applied to outputs / actions that might otherwise be considered continuous. For example, brake pressure is logically a continuous value. However, it can be discretized into ranges such as: no braking, light braking, moderate braking, hard braking, and very hard braking. Again, the approach is to approximate continuous functions with these discrete ranges, thereby drastically reducing the number of actions considered by the auto-generation program, and therefore reducing the cost of the auto-generation.

[0142] For discrete actions, the approximation is further aided by the rapid re-evaluation of rule conditions (304) during control system execution and the fact that physical actuators such as brakes, signs, accelerators, etc. react relatively slowly compared to computer calculation times. For example, if the correct degree of braking is actually between medium braking and hard braking, the output of the control system (202) may oscillate between these two ranges. However, if the reaction time of the braking system is RT Longer than the periodic rule evaluation, if the previous action was medium braking, the output action is likely to change from medium braking to hard braking just when the actual brake pressure has been actuated to slightly below the midpoint between medium and hard braking. Therefore, the actual physical effect is this intermediate level of braking. Also, note that if the system only applied medium braking in this example, the situation could quickly evolve to require emergency braking to compensate for the lack of braking.

[0143] In one embodiment, each action (302) is simply the setting of one or more output control variables (210) that indicate the control level of various actuators, PID controllers of said actuators, or the like. For example, for an AV, the control variables may be the angle of the steering wheel and negative values ​​of throttle and / or brake levels. In one embodiment, repeatedly selecting the same action (302) - for example, a negative 15 degree angle of the steering wheel - has no effect other than maintaining the same control settings. In general, the actions (302) may be idempotent so that repeatedly selecting the same action at each time step for rule evaluation maintains the same behavior when appropriate. For example, if the input condition (304) indicates acceleration to a given rate and the throttle setting is providing sufficient acceleration to achieve this, then at each time step that the vehicle is below the target rate, the throttle should not be increased. Instead, the action (302) is the setting of the throttle control variable (210) to achieve the desired acceleration, and therefore does not change unless the current setting does not achieve the desired acceleration to reach the target rate. Alternatively, the action (302) may use an existing or new PID controller setpoint as the control variable (202), for example to provide a dedicated method of achieving a target rate within a desired acceleration profile.

[0144] In some applications, position is also relevant to control. For example, in flight control systems, the position and attitude of an aircraft are important. In particular, the precise position of an aircraft can be given as a continuous value corresponding to altitude, longitude, and latitude. However, the altitude can be discretized into a range set for input to the control system, thereby reducing the number of values ​​to be considered as for other inputs described herein. In addition, it is usually possible to provide a discretized input relative to a certain target position. For example, control systems usually focus on making the aircraft follow a specified flight path, i.e., a "course". Therefore, it is sufficient for the control system to know the difference between the position where the flight plan indicates that the aircraft should be located and the position where it is actually located. This difference is usually much smaller than the absolute value involved. Therefore, a smaller number of ranges in the range set can be used, and effective control can still be achieved. The smaller cardinality of the range set means that automatic generation has a lower cost than trying to use absolute values.

[0145] Simplify / discretize the route structure of the dynamic environment. As referred to herein, a route is a discretized directional path segment that the controlled system (206) can traverse under certain conditions. N dimensional space while obeying non-dynamic constraints. An example of a waterway is a waterway in a road, but as described below, there are other environments in which the abstraction of a waterway works, including a stock market environment as described below and a medical application environment as described below. Thus, a waterway can impose structure on a dynamic environment so that a rule-based system can effectively automatically navigate a controlled system through the environment. Throughout this specification, examples of autonomous vehicles, stock trading, and / or medical fields / applications may be given for purposes of illustration, but the principles, techniques, and systems described herein may be generalized to other applications without limitation.

[0146] As described herein, rule-based systems are an intuitive and attractive approach to constructing automated control systems, since the usual manual methods for control are typically specified in terms of rules. For example, in the application domain of self-driving cars, manual driving is governed by rules including road rules and safe driving rules. Similarly, in automated stock trading systems, there are rules associated with trading, which are imposed by both the market platform itself and the financial institution running the trading application. Similarly, medical treatments for diseases or disorders typically follow a prescribed set of rules, e.g., if a patient has already taken drug Y, then they should not be prescribed drug X.

[0147] When applying rule-based systems ("RBS") to automated control, the first problem to be solved is that the rules used for manual / human operation are usually stated in terms of constraints, rather than in terms of the condition:action formula used in automated RBS. For example, a standard driving rule is: do not exceed the speed limit. This rule does not indicate the speed at which the vehicle should travel, but leaves it to the judgment of the human driver. This example is a constraint in the sense that it states that the speed of the vehicle is always less than or equal to the speed limit. Constraints are referred to in this article as statements and / or conditions that the system should strive to achieve. For an automated system, rules need to provide this judgment. That is, there needs to be a rule in the condition:action format so that the system responds to the condition under which the rule becomes true to trigger an action to achieve the constraint.

[0148] In simple formula, the basic rule can be easily stated as:

[0149]

[0150] However, in reality, the conditions for deceleration are much more complex, including the potential presence of dynamic obstacles suddenly appearing in the direction of the vehicle's advance, traffic lights ahead, entering a relatively sharp turn, etc. The real-world conditions for when a vehicle should decelerate can be quite complex and difficult to get right.

[0151] Similar complications arise in stock trading applications. An initial rule might be: do not allow a portfolio to have more than X percent of its value in a single stock. However, the conditional: action rules that implement this may be more complex. In particular, rules for increasing stock positions or selecting purchase amounts may need to avoid quantities exceeding X percent of the portfolio value. However, if the value of one stock rises significantly or the value of the remaining stocks in the portfolio falls significantly, it is possible that the X percent threshold is exceeded again and corrective action is required. The exact action may depend on various factors, including which of these scenarios causes the constraint to become problematic. For clarification, the term "vehicle" is used in investment contexts to designate a specific investment category that is an "investment vehicle."

[0152] Another challenge is that actions in dynamic environments / applications are not instantaneous, but may occur over a period of time, during which conditions may change. For example, in a medical application, the action of triggering the start of a patient taking a specific medication does not produce results immediately. In addition, even after initiating the treatment, the patient's condition may suddenly change, requiring a different treatment plan. As referred to herein, "suddenly" means relative to the time required for the selected treatment to have an effect. Therefore, the rule set may be further complicated by the need to consider actions that have initiated certain behaviors but have not yet been completed.

[0153] Another challenge facing RBS is that these applications may have an infinite number of actions to be taken, and therefore an infinite number of conditions to be evaluated to select these actions, and / or these conditions may change rapidly and unpredictably. For example, an autonomous vehicle operating in an environment where there are many other independently controlled vehicles must implement the constraint of not colliding with these other vehicles, even though it may not predict the behavior of these other vehicles. Similarly, in an automated stock trading system, the price of the stock itself may change significantly outside the control of the control system.

[0154] The control system may implement actions in response to these dynamically changing actions in an attempt to maintain the constraints specified for the control system. One challenge is to specify correct, efficient and reliable logic for the control when there may be an infinite number of dynamic scenarios that can occur and therefore an infinite number of situations to consider in the control logic. This challenge is further complicated by the fact that in many cases the actions may not be executed instantaneously and the environment may further change during the execution of the actions.

[0155] There is often a basis for top-level planning based on environmental knowledge, referred to herein and in the context of navigation as "route guidance." For example, an autonomous vehicle ("AV") may use conventional vehicle navigation techniques, such as based on GPS ("Global Positioning System"), to generate a plan to reach a destination along a plausible sequence of roads and intersections. In a financial setting, an automated trading platform may navigate a portfolio through a stock market. The stock market itself is a collection of stocks that dynamically changes over time. In a medical setting, a health plan may navigate a patient back to health.

[0156] Essentially, the route guidance module generates a sequence of waypoints corresponding to actions at key roads and intersections. Similarly, there may be a top-level plan for automated stock trading based on P / E ratios, different indices, trading strategies, etc., where the waypoints are from trade opening in the morning to trade closing at the end of the day, at least in a one-day trading application.

[0157] However, this type of top-level plan does not necessarily take into account specific dynamic aspects of the environment that may appear between waypoints. For example, an AV entering an intersection to turn left will need to switch to a left-turn lane before the intersection and then negotiate the turn while complying with the constraint that the vehicle must avoid collisions with other vehicles and obstacles, even though it may not accurately predict what other vehicles and dynamic obstacles may do while it is executing the plan. Similarly, there may be stock market changes such as changes in interest rates that may be unpredicted and may require quick reactions coupled with constraints such as not becoming overweighted in a particular industrial sector. As referred to herein, this form of navigation is "dynamic navigation" because it takes into account dynamic elements in the environment.

[0158] A technique for rapidly reacting to a dynamically changing environment without incurring the overhead of generating short-term plans or courses of action is described herein. Embodiments implementing the technique include automated navigation of vehicles, automated stock trading platforms, medical or other applications that exercise control or recognition in a dynamic environment. The term "automated dynamic navigation" as referred to herein is defined as the process of determining and maintaining a route or trajectory to a target location. The trajectory may occur in a broad sense. N dimensional space, and the "determine" step consists of navigating a path through this space that is consistent with the constraints imposed on the controlled system.

[0159] A control system (202) is described herein that uses a rule-based system to achieve automatic dynamic navigation of a controlled system or "vehicle" (206) through a dynamic "course" constructed environment, where the trigger action is the dynamic selection and execution of a "course maneuver" to achieve the navigation. That is, navigation is achieved by executing new course maneuvers and interrupting existing course maneuvers in response to rule triggers, where the rule conditions are responsive to changes in the environment and the vehicle.

[0160] As referred to herein, a "lane maneuver" is an action performed over time to control a vehicle relative to a lane. For example, a simple maneuver is to maintain the speed of the vehicle in the middle of the current lane. In one embodiment, a maneuver is an action performed during the action time independent of dynamic changes to the environment. For example, a course change to the right adjacent lane is a maneuver for the AV.

[0161] Channels. Channels are discretized directional path segments that controlled vehicles can traverse under certain conditions. N dimensional space while obeying non-dynamic constraints. Ndimensional space, which contains the path from the start of the lane to its end point. For example, the physical roads in autonomous vehicle applications are discretized or divided into physical lanes or path segments, each of which is wide enough and smooth enough for the vehicle to traverse. For example, on a two-lane highway in the United States, vehicles are expected to stay in the right-hand lane except when overtaking. Without limitation and as described below, lanes are an abstract concept that can be applied to physical lanes in AV applications, but can also be applied to other dynamic environments like stock trading and medical applications.

[0162] Lanes impose structure on the environment or space to be navigated. That is, rather than being able to travel anywhere, a vehicle is constrained to travel on one lane or switch to another lane and then travel on that lane. For example, on a six-lane divided highway, a vehicle travels in the rightmost lane, the middle lane, or the leftmost lane unless the vehicle is changing lanes. Thus, the lane concept reduces the choices of actions in the short term. For example, a vehicle can travel in the current lane, or otherwise switch to another lane. As a side note, it may be possible to specify an environment with a lane configuration in which it is impossible for a vehicle to get from one destination to another, but it would be useless to do so.

[0163] Lane construction constrains the options that a vehicle must navigate. For example, in the case of an autonomous vehicle, a vehicle may have to navigate relative to a lane, such as following a current lane, switching to an adjacent lane, or turning onto a lane on another road at an intersection.

[0164] The restriction of a channel may mean that some navigation plans that would otherwise be possible may not be considered or supported. For example, if a road is completely blocked, it may actually be possible for a vehicle to go "off-road" and still reach the destination in unconstrained navigation. However, for channel-constructed navigation, unless a channel is provided around the blockage, the vehicle is forced to stop and may not be able to make it to the destination without human intervention.

[0165] Course construction can also mean that dynamic navigation of a vehicle can also assume that other vehicles also use navigation constructed using the course. For example, vehicle control can assume that an approaching vehicle can remain on its course and not suddenly deviate to the course of the current vehicle. By making this assumption, the course can allow some driving that would otherwise be infeasible. For example, consider the constraint: a vehicle should not have an approach speed V to another vehicle at a distance D that exceeds the vehicle's ability to decelerate V within a travel time D. This constraint is limited only to other vehicles on the same course as the current vehicle. This limitation on course-based behavior is precisely when there are vehicles approaching quickly on an adjacent course, allowing the driver to assume that it is safe to continue driving on the current course.

[0166] Lane restrictions may be critical for safe navigation because it is virtually impossible to handle many common scenarios without relying on lanes and associated vehicle behavior. For example, oncoming vehicles on a two-lane highway typically travel in their own lanes at, say, 65 miles per hour. Given a high-speed approach, if the oncoming vehicle suddenly swerves into its lane, it is virtually impossible for the controlled vehicle to avoid a collision. If there is no lane, the vehicle may not travel at any significant speed if the oncoming vehicle can choose to navigate anywhere on the road at any time. Similarly, if a car that should have been parked suddenly drives out of its lane, a vehicle passing the parked car may not be able to actually avoid a collision.

[0167] In the case of on-road vehicle navigation using high-definition (HD) maps, the course information is important for vehicles traveling in the area. a priori Available. The vehicle then needs to perform positioning to maintain the vehicle's position on the HD map. Existing technologies use GPS, dead reckoning, and visual or other channel marker indications to achieve vehicle positioning with high accuracy.

[0168] Figure 6 is an illustration of a course in an example autonomous vehicle application. A map (602) illustrates an AV (604) with a location target (606). An example of a top-level plan (608) includes a series of waypoints as it navigates various highways, roads, and transition roads like on-ramps and off-ramps. Following the plan, the AV (604) travels in a current course (610) with two adjacent courses (614), (616).

[0169] Channels in Other Fields / Applications. In the world of stock trading, there are channels based on the classification of stocks into different industry segments. Typically, other market participants do not suddenly switch all investments to another random set of stocks. Instead, certain dynamic events such as refinery explosions, interest rate changes, and other examples are known to affect specific "channels" or industry segments. Therefore, a portfolio can react to dynamic events by recognizing that each event only affects one or more investment channels and the constraints associated with (one or more) those channels. For example, a major explosion at a refinery may have a negative impact on the company that operates the refinery, but be beneficial to other companies in the refinery "channel", and have a negative impact on other companies that are highly dependent on oil, such as companies in the transportation "channel".

[0170] Unlike the case of an auto-navigated vehicle, an auto-stock trading application can have hierarchical "lanes", with a top level of consumer goods, a mid-level of dry goods sectors, and a low level of specific stocks / companies. It can also have multiple investment themes corresponding to: effectively controlling multiple instruments / sub-instruments at the same time, observing constraints between these instruments / sub-instruments, such as avoiding staying too long in too many companies that are growth-stage companies on each "lane" across investment themes.

[0171] Fig. 7A , 7B 7C illustrate examples of graded channels for stock trading. Fig. 7A In the example, tool / app (702) is currently in the "Technical Services" top-level hierarchical channel (704), which is adjacent to the "Electronic Technology" top-level hierarchical channel (706) and the "Health Technology" top-level hierarchical channel (708). In other words, the tool / app can be moved from channel (704) to adjacent channels such as channels (706) / (708). Figure 7B In the example, tool / app (702) is currently located in the "Cloud Department" intermediate hierarchical channel (714) in the "Technical Service" top-level hierarchical channel. The "Cloud Department" intermediate hierarchical channel 714 is adjacent to the "Streaming" intermediate hierarchical channel (716) and the "Operating System" intermediate hierarchical channel (718). Figure 7C In the example, tool / app (702) is currently located in the "GOOG" low-level classification channel (724) in the "Cloud Department" middle-level classification channel in the "Technical Services" top-level classification channel. Channel (724) is adjacent to the "AMZN" low-level classification channel (726) and the "MSFT" low-level classification channel (728).

[0172] In this context, stock trading can be viewed as navigating multiple investment instruments / sub-instruments simultaneously, with constraints between these instruments, subject to constraints between these instruments, and constraints between the environment and each instrument.

[0173] Fig.7D An example of a hierarchical channel for a medical application is illustrated. The tool / app (752) is currently in an "Aspirin Treatment Plan" channel (754) which is adjacent to two "No Treatment Plan" channels (756), (758) indicating the period of time a patient spent off an old treatment plan before starting a new one. One "No Treatment Plan" channel (756) is adjacent to a "Fentanyl Treatment Plan" channel (760) indicating a possible new treatment, while the other "No Treatment Plan" channel (758) is adjacent to a "Cardiac Surgery Treatment Plan" channel (762). Without restriction, Fig. 7A , 7B , 7C and 7D illustrate the use of two-dimensional navigation channels (like physical roads) to draw Figure 6 By conceiving in more than two dimensions, the same principle can be extended to, for example, a three-dimensional channel set, where the "no treatment" channels (756), (758) are the same channel, and other treatments (754), (760), (762), etc. are adjacent to "no treatment". Without limitation, N dimensional space can be used for other applications.

[0174] General Channel View In the most general formulation, the channel is usually the direction in which the "vehicle" is traveling. N A constrained directional path in a dimensional space that is sufficient for a vehicle to travel from one end to the other in the absence of dynamic obstacles without violating vehicle constraints, including static vehicle constraints. A course may have certain dynamic and static properties and behaviors. For example, in medical applications, a course corresponding to a treatment plan for a specific patient may require specific side effects and may have a limited application time. Navigation requires following the current course and switching to a different course from time to time when appropriate to achieve a desired goal, such as curing the patient. The vehicle (the patient in this medical application example) is not allowed to change from its current course to any other course. Instead, it is only allowed to switch to a course that is consistent with the current course. Adjacent waterway.

[0175] The concept of “adjacent” is defined in application-specific terms and constraints. In particular, a lane L0 is adjacent to another lane L1 if it is feasible to perform a lane maneuver from L0 to L1 subject to some dynamic conditions. For example, refer to Fig.7D, a patient who is being treated with fentanyl and therefore in a channel (760), may not be switched directly from that channel or treatment to the aspirin treatment channel (754) without going through the "no treatment" channel (756). This is necessary because there may be adverse interactions between the drugs if the patient has some fentanyl in their system when they begin taking aspirin. Furthermore, the patient is only allowed to switch from the fentanyl channel when their symptoms have stabilized. The adjacent designation between channels is part of the context of the channel construction.

[0176] Course maneuvers. "Course maneuvers" herein refer to actions that occur in one or more courses. For example, changing to the right course is a maneuver that changes the vehicle from the current course to the adjacent course on the right. Thus, as described above, "adjacent courses" herein refer to courses that can be reached from the current course using course maneuvers, similar to physical two-dimensional courses in driving. In this sense, courses and their adjacent areas serve a discretized environment, so the number of maneuvers is also conveniently limited and achievable. For example, a change of course to an adjacent course is one of a small number of maneuvers and is straightforward to implement.

[0177] In many cases, the maneuvers may be static, pre-computed solutions relative to the course. For example, the “change course” maneuver is static, where the course is of standard width – a simplified and standard motion plan may be used, perhaps parameterized by vehicle speed. Furthermore, the maneuvers do not have to account for dynamic events or obstacles. Thus, when a new maneuver is selected, the AV can take instantaneous action to execute the selected maneuver without having to dynamically generate a maneuver sequence or program.

[0178] Figure 8 is an illustration of a lane maneuver for an autonomous vehicle example. In general, there are usually a finite number of actions that a controlled system can perform, especially when the actions are defined by parameters. For example, a factory robot can reach forward, lift up, lift down, and so on. Similarly, Figure 8 As shown in FIG, the vehicle (802) can slow down (810), speed up (808), change course to the left (812), change course to the right (814), perform a left turn (816), perform a right turn (818), etc. These actions are a bounded set of actions, possibly parameterized by speed, road conditions, etc. Thus, the maneuvers can be preset in the control software and / or implemented in the hardware (e.g., hardwired), and thus executed with rapid response.

[0179] Course construction can be used to significantly reduce the number of actions to consider at any given time. For example, consider a flat plain stretching from point A to point B. Without any courses, there are an infinite number of potential paths to choose between points A and B. With one course in each direction between points A and B, the actions are reduced to staying on the travel course (slowing down, speeding up, or maintaining speed), changing to another course to pass through, and changing back to the travel course after passing.

[0180] In the medical context, there are a bounded number of course maneuvers because there are established treatment sequences that are known to be safe. For example, a physician should never prescribe a sudden change in a treatment plan without knowing whether the change is safe to make. In the world of stock trading, there are a bounded number of actions or maneuvers to perform, such as selling at market, stopping losses, and so on. Furthermore, a stock portfolio that is required to allocate 10 percent of its assets to high-tech large-cap growth stocks may not replace one such stock in the portfolio with any other stock. Instead, refer to, e.g. Figure 7C , if the portfolio has a large holding of AMZN (726), it can only replace that stock with GOOG (724) or NFLX (730) because these stocks are adjacent to AMZN (726). As mentioned earlier, the adjacent example is illustrated in two dimensions. In reality, there can be many different stocks adjacent to AMZN, which can be easily handled in N-dimensional space.

[0181] In every possible scenario where navigation is strictly possible, it is not strictly necessary for the vehicle or robot to navigate for maneuvering; nor may it be necessary for a human driver to do so. For example, consider a zigzag collection of static obstacles and dynamic objects moving through an intersection or the like in some rapid mode. It may be theoretically possible to navigate safely through this intersection, but few humans will be able to navigate in this situation. This situation is very unusual, so given the economic value of being able to drive safely in the actual real-world scenario of interest, it would be acceptable to not have the ability to automatically handle it.

[0182] Thus, there is a set of basic course maneuvers, such as in the AV context: maintain speed in current course, decelerate, accelerate, change to right course, change to left course, turn right, turn left, etc. These maneuvers can be refined into more specific maneuvers. For example, deceleration can be refined into: sudden emergency braking, emergency braking, gradual braking, and deceleration / cutting off the throttle. The course structure implies a relatively small set of basic maneuvers, which can be refined into larger and more complex sets.

[0183] In contrast, without a channel structure, there is an infinite number of possible actions. In addition, the number of conditions is at least the number of actions, so the number of rule conditions is also excessive unless the number of actions / maneuvers is strictly limited. In particular, without a channel, either an infinite number of actions are generated - such as "move 1 inch to the right", "move 2 feet to the right", "move 3 yards to the right", etc., or the actions are parameterized without restrictions or meaningful restrictions. For example, if the action is to move X feet to the right, very large values ​​may have different implementations than small values, so it is inherently difficult to implement. In contrast, with a channel, changing the channel to the right is used for small movements, but to go a significant distance to the right, the vehicle turns right and then proceeds along the channel to the right, and then may turn left to continue.

[0184] In one embodiment, a lane maneuver is implemented as "preemptible," as that term is referred to herein, in that a new maneuver can be triggered instantly, even while another maneuver is being executed. The new maneuver is able to take over and execute its maneuver, taking into account the intermediate state of the vehicle based on the previous maneuver. For example, a maneuver to change to a passing lane and accelerate may have been previously triggered, but before that action is completed, a dynamic obstacle is detected that triggers the maneuver to slow down and return to the lane of travel. The maneuver identifies the current position of the vehicle relative to the lane of travel and adjusts its steering action based on the vehicle's deviation from the lane of travel. In particular, if the vehicle is only slightly off the lane of travel at the point at which the new maneuver is triggered, the steering action may need to be less aggressive than if the vehicle was already fully in the passing lane.

[0185] Lane Subconditions. A "lane subcondition" as used herein refers to an input that indicates the state of one or more lanes relative to the vehicle or other object. For example, hasRightLaneClear is a subcondition that is true if there are no obstacles in the right lane relative to the vehicle. This is a lane subcondition because it is tied to the state of the lane.

[0186] Just as the channel structure reduces the number of channel maneuvers, it also reduces the number of channel subconditions required. This is because the only actions are relative to channel maneuvers, so it is acceptable to consider only subconditions relative to the channel. That is, if the only action choice is one of the channel maneuvers, then the condition for the channel maneuver choice should be sufficient if expressed in terms of channel subconditions. In the case of a channel, the conditions of interest are reduced down to the conditions that should trigger each of these actions. For example, the action of slowing down in the current travel channel has a small number of subconditions related to the state of the current travel channel and possible adjacent channels, as well as the current position of the vehicle in the current channel.

[0187] Because most or all of the relevant sub-conditions are associated with the current lane or adjacent lanes, and are vehicle-dependent, it is often easier to determine the lane sub-conditions from sensors on the vehicle. For example, the hasRightLaneClear sub-condition is relative to the vehicle, and can be sensed by sensors on the vehicle to the right of the vehicle, including cameras, microwaves, radars, and lidars. Lane sub-conditions are also local to the controlled vehicle, making them easier to sense accurately.

[0188] The lane structure also allows for the exclusion of sub-conditions that may cause false positive reactions. For example, without a lane, a vehicle may want to sense whenever there is an object with a high closing speed towards the vehicle. With a lane, on a slightly curved two-lane highway, an oncoming vehicle in the opposite lane may appear to have such a high closing speed: With the lane structure, the vehicle may recognize the presence of an oncoming vehicle in the opposite lane and only use this sub-condition to prevent overtaking in the opposite lane and not react to it in other ways.

[0189] It is possible to assume scenarios where the course subcondition is not sufficient. For example, a rock may fall from a high cliff adjacent to the road, directly onto the vehicle. With additional subconditions driven by aerial sensors, it may be possible to avoid this collision. However, these are extreme and unusual situations that are beyond what a human / manual driver can typically handle. However, it may be feasible to extend the sensors on the vehicle to detect relevant subconditions above the course, and thus treat these subconditions as additional course subconditions, as required in this extreme example.

[0190] For the channel construction of the environment, RBS navigation is implemented by having a rule condition as a channel sub-condition, triggering a rule action as a channel maneuver. For example, in the application of an autonomous vehicle, one sub-condition may be that the current channel is blocked ahead. The other two sub-conditions may be that the adjacent left channel and the adjacent right channel are free. The last sub-condition may be that it is about to turn to the right hand side. With this set of sub-conditions, it is reasonable for the vehicle to choose to switch to the right channel instead of braking or switching to the left channel. That is, the above rules can be implemented as:

[0191]

[0192]

[0193] Note that this rule does not require a leftLaneClear sub-condition and therefore the leftLaneClear sub-condition is not included in the lane sub-condition.

[0194] In general, the context of channel construction results in a relatively bounded set of maneuvers and a relatively bounded set of subconditions to consider, so that the rule set is of reasonable size for design, validation, and execution.

[0195] General effectiveness of discretization. Increasing the number of ranges in the discretization improves the approximation to these continuous values ​​at the expense of increasing the cost of automatic generation and the cost of matching, the latter because of the number of rules involved, and vice versa. However, due to the smoothing effect of the physical actuators and the effect of the rapid re-evaluation of the rule conditions, which is fast relative to the physical reactions, a relatively small number of discrete ranges is sufficient. This sufficiency is also enabled by the monotonicity of the actuators. That is, greater brake pressure leads to stronger braking / deceleration.

[0196] As described herein, a design engineer for a control system (202) has tasks that include:

[0197] Specifying a discrete set of ranges for inputs and discrete actions for outputs, and making appropriate tradeoffs between control accuracy and automatic generation cost;

[0198] Providing a predictive simulation model / implementation of an engineering system (206); and / or

[0199] Provide an implementation of the objective function of the engineering system (206).

[0200] From these, design engineers can then automatically generate a rule set that provides the decision logic for the system, which can then be compiled into executable code or executed by a rule engine.

[0201] In one embodiment, in a computer ( Figure 1 The program running on 100 of ) accepts as input the input specifications of the range set, simulator module and objective function, and then automatically generates the control decision logic rules.

[0202] Pipeline partitioning. Fig. 9 is a block diagram illustrating an embodiment of pipeline partitioning of a control system. Fig. 9 As shown in , control is divided into three separate pipeline stages. In this embodiment, control is divided into pipeline stages, each stage has its own objective function and its own table or generated code. In this embodiment, the stages are constructed according to the length of the time frame considered by the stage. For example, with three stages, the first stage can handle a long time frame for control, the second stage can handle a shorter time frame, and the third stage can handle the shortest time frame.

[0203] For example, for an engineering system such as an aircraft (916), Fig. 9As shown in FIG, the third phase (902) may involve short-term control aspects of achieving a specified altitude, attitude, and orientation. In this case, it only involves the flight characteristics of the aircraft (904) and environmental aspects such as altitude, wind speed, etc. as sensor inputs. The second phase (906) may be responsible for tactical control, such as avoiding obstacles and weather interference using appropriate sensor inputs for weather and obstacles (908). The actions it selects occur over a longer period of time. The first phase (910) then involves a strategy for following a given route over a longer period of time using appropriate sensor inputs for mapping and positioning (912). Its actions occur over an even longer period of time.

[0204] This ordering is imposed because earlier stages like (910) are more advanced and primarily provide goals or suggestions for subsequent stages like (906) to try to achieve if feasible. For example, an aircraft may have a strategy that generates a first stage (910) to bank left to align with a landing strip, while a second stage (906) may detect that this action will put it on a collision course with another aircraft. Therefore, the second stage (906) will (temporarily) override the action suggested by the first stage (910). In other cases, later stages like (902) refine the action selected by a previous stage like (906). For example, the second stage (906) may indicate a bank to the left, while a subsequent stage (902) refines this into specific adjustments (914) to the ailerons, throttle and rudder and / or PID controllers, with set points for these mechanisms.

[0205] As such, the partitioning into multiple phases can be viewed as functional partitioning in the sense that the first phase (902) determines the strategy, the second phase (906) determines the tactics, and the third phase (910) controls the actual execution. It may just be the case that these different functional components need to consider different time frames.

[0206] Note that sometimes partitioning by actuator or by sensor is not feasible. The controlled system needs to operate correctly based on a unified control mechanism. For example, controlling a flying drone while landing requires coordinated control across all actuators and inputs from all its sensors.

[0207] This partitioning into phases by the length of the time frame can significantly reduce the overall complexity of the automatic generation in several aspects.

[0208] First, this means that some stages do not require some input, thereby reducing the cardinality of input conditions that the automatic generation of that stage must handle. For example, the final stage in controlling an aircraft (902) is concerned only with flying the aircraft according to its physical properties (904). It does not require input indicating the presence of (external) obstacles in its vicinity. Instead, it relies on input from previous stages that provide a choice of actions to avoid those obstacles, such as Fig. 9 905 in . Thus, the automatic generation for this final stage (902) need only process its own relevant inputs (904) plus a single previous stage input (905), rather than depending on all the inputs required by the previous stage to detect potential obstacles and determine how to avoid them. Similarly, an earlier stage (910) can pass high-level actions to a later stage (906) via inputs (909) without being concerned with how those actions are implemented. It can prepare for the later stage (906) to be unable to implement the desired action, either because of a potential collision or because it is beyond the ability of the aircraft (916) to safely execute.

[0209] To illustrate, if the control system (202) has 21 inputs, then non-partitioned control needs to consider K 21 input combinations, where K is the number of discrete values ​​for each input. On the other hand, if the control system is partitioned into 3 stages, and these inputs can be strictly partitioned across the 3 stages, then each stage will have K 8 input combinations, and for inputs from previous stages, each stage counts one new input in addition to the 7 original inputs. Therefore, the cost is 3× K 8 , which is significantly lower than K 21 .

[0210] Second, the partitioning reduces the cost of auto-generation for later stages because, in this case, auto-generation can start with a suggested action from a previous stage and use that action to reduce the range of actions to evaluate whether the suggested action is inconsistent with the control constraints imposed by the current stage with the current IC. For example, in the case of flying a drone, the second stage (906) can take a suggested bank-to-left maneuver if doing so does not put the drone at risk of collision or stalling. Then, evaluating expected common cases is more efficient because no alternative actions need to be considered except when the input scenario requires overriding the suggested maneuver.

[0211] Third, the partitioning reduces the number of time steps to be considered in each stage and therefore reduces the cost of automatic generation, i.e., it decouples the temporal granularity requirements of long-term decisions from short-term requirements. For example, short-term control of the aircraft (902) attitude requires a high rate of control actions, such as 10 Hz. On the other hand, long-term control (910) actions require long time frames for execution, such as performing a turn to align with a landing runway. Evaluating both in a single stage means having fine-grained time steps over a long period of time, which makes evaluation very expensive. Staging means that only the later fine-grained stages need to consider fine-grained time steps.

[0212] Fourth, partitioning can also reduce the cost of the objective function. This is because the earlier stages only have to evaluate coarse conditions that affect the goodness of high-level decisions, and the later stages only have to evaluate fine-grained conditions. In addition, as mentioned above, there are fewer inputs to consider in each stage than in a combined stage.

[0213] Fifth, the partitioning allows for the automatic generation of controls for each phase to be executed independently. For example, if the model for the second phase (906) is refined, the rules for the second phase can be regenerated without modifying the control rules for the first phase (910) and the third phase (902). Therefore, the cost of maintaining the control system over time can be significantly reduced.

[0214] In one embodiment, another partition that may be used is a separate set of rules that describes what is wrong with an action and then eliminates that error. Other techniques, such as those disclosed in U.S. Provisional Patent Application No. 62 / 698,672, filed on July 16, 2018, entitled “INCORPORATING RULES INTO COMPLEX AUTOMATED DECISION MAKING,” which is incorporated herein by reference for all purposes, and in U.S. Patent Application No. 62 / 154,354, filed on July 15, 2019, entitled “INCORPORATING RULES INTO COMPLEX AUTOMATED DECISION MAKING,” which is incorporated herein by reference for all purposes, may be used, such as using rules to find flaws in the options being explored. That is, input from a stage such as detecting flaws (910) may override a subsequent stage (906) that uses one or more inputs (909) to explore an action.

[0215] Pruning Actions. In one embodiment, a pruning function is used to eliminate certain actions from consideration to avoid unnecessary overhead such as for simulation and full evaluation. For example, considering the case where the aircraft is below a target altitude, there is no need to simulate control settings that reduce the target altitude, such as flap settings or reduced throttle settings. As with the model simulation and objective functions, the implementation of the pruning function can be application specific.

[0216] In one embodiment, the pruning function takes part or all of the input sub-conditions ( Figure 3 304) as input and returns a subset of actions corresponding to actions that may be useful relative to the objective function ( Figure 3 302 in ). For example, for an AV, if none of the input conditions indicate an unsafe situation, all sudden emergency actions, such as emergency braking, sudden left and right turns, can be excluded from consideration. In addition, if there are no input conditions indicating an unsafe situation, if there are suggested actions from upstream modules (such as Fig. 9 906 in ), it should be sufficient to prune the set of actions to only those actions that are consistent with the recommended actions and some default actions. For example, in the case of an AV, if there are no unsafe conditions and the upstream policy module recommends merging into the left lane, the AV can reasonably limit its selection of potential actions to merging into the left lane or staying in the same lane.

[0217] On the other hand, if there is an unsafe situation, the actions can be pruned to only those corresponding to sudden emergency maneuvers, such as emergency braking and sudden steering. In addition to saving computation, another advantage of this pruned is that it ensures that sudden emergency maneuvers are chosen when the AV is in an unsafe situation, rather than less aggressive maneuvers. For example, there is a risk that the automatic generation may choose, for example, to accelerate and change to the left channel to escape from an unsafe situation, which will be more unsafe than simply braking in the same channel. This should not happen in an ideal objective function, but is difficult to ensure in practice. To avoid overreaction, unsafe conditions can be divided into slightly unsafe, unsafe, and very unsafe. Then, very aggressive sudden emergency maneuvers are only taken when the scenario is very unsafe.

[0218] Symmetry. In some application areas, there is symmetry for certain input scenarios and rules, which can be used to reduce the cost of automatic generation. For example, for an aircraft, if the action is to lean to the left, there is a symmetrical set of input sub-conditions that will cause the aircraft to lean to the right. The action processing step of generating a rule for a lean-to-left action can identify the existence of a symmetrical action to the right, and generate a rule in which the condition is a symmetric version of the condition of the current rule, and the action is to lean to the right. For example, if the input for the left rule is "get close to the adjacent aircraft on the right", the symmetric condition for the right rule is "get close to the adjacent aircraft on the left".

[0219] In one embodiment, after generating an action for the current input scenario, the action process generates a symmetric condition, and then looks to see if that rule condition already exists in the rule set generated at that point. If not, it adds that symmetric generated rule to the rule set. This optimization reduces / eliminates the cost of iterating over all potential actions, and the associated evaluation of actions that are symmetric to existing rules.

[0220] In one embodiment, based on the current input conditions, a rule set is used to classify the current scenario under consideration in the automatic generation process to aid in pruning. For example, the input conditions (304) can be matched to determine the "root cause" problem to be solved by the control, thereby providing a category for the action selection (302). It may be possible to further classify in unsafe and very unsafe situations.

[0221] Preferably, the deletion will not eliminate certain actions that may be good choices for the situation. For example, for an autonomous aircraft, banking the aircraft to the left is part of a left turn action, although part of the overall goal is to maintain the aircraft in level flight.

[0222] Preprocessing to prune input conditions. There are combinations of input values ​​that may not make sense. For example, for an AV, there may reasonably be an input condition that indicates that there is an adjacent left lane that is drivable. However, it should never be the case that the left lane is drivable while another input condition indicates that there is an adjacent left vehicle. One approach is to prune such invalid input combinations out of consideration, thereby reducing the cost of rule generation.

[0223] In one embodiment, the input value combinations are filtered or pruned to detect and skip those invalid combinations. Here, "skipping" can mean automatically generating rules that issue matching this situation, and taking the action of reporting "impossible" input combinations, rather than performing normal prediction-based evaluation of all possible actions.

[0224] An alternative approach is to collapse different logical inputs into a single input to avoid or reduce redundancy that could result in invalid input combinations. For example, continuing with the example above, pre-processing the inputs could allow the AV control system to create a virtual vehicle that is adjacent to indicating when there is no drivable left lane. The number of input combinations is then reduced because a separate “is drivable” input sub-condition is eliminated, thereby reducing the cost of automatic generation. A similar approach could be used to impose behavior associated with traffic signs. For example, instead of having an input condition indicating a red traffic light, the pre-processing input could introduce a virtual vehicle that stops in front of the current virtual vehicle, thereby forcing a stop as a red light would do.

[0225] In one embodiment, input pre-processing maps individual logical inputs to another real input before providing them to the generated control system, thereby reducing the number of input combinations that need to be considered for automatic generation.

[0226] This combination of the above methods requires some preprocessing of the input conditions before they are provided to the generated control system, but in many cases the preprocessing may be relatively simple and may be similar to the preprocessing required to discretize the inputs before providing them to the generated control system, as described herein.

[0227] Roughly approximate predictive simulation. Significant cost in the automatic generation of rules is incurred by the prediction step, i.e., the computation that predicts the outcome of the action under consideration (302) over some number of time steps. The cost is proportional to the number of time steps taken in the predictive simulation to reach a state that can be used to evaluate the action. Each step can incrementally advance the objects of interest, updating their positions, velocities, and accelerations, or any dynamic characteristics of these objects of interest. In many cases, actual control systems are also time-stepped. For example, a control system for an AV may update its maneuvering decisions every 100 milliseconds, thereby ensuring that it reacts quickly to some sudden / unexpected events, such as initiating a sudden turn to avoid a sudden obstacle ahead. That is, the period is selected based on the desired reaction rather than the time granularity required for a sufficiently accurate simulation.

[0228] Various maneuvers may take significant periods of time to complete. For example, an AV course change may take 3-5 seconds to complete. Therefore, a naive approach would be to simulate 30 to 50 time steps to evaluate potential action choices, as this naive approach has considerable computational cost.

[0229] In one embodiment, the cost of the simulation can be reduced by using a larger time step than is used in actual control system implementations. For example, if the simulation uses a 1 second time step instead of a 100 millisecond time step, the number of time steps used for the simulation is only 3-5, reducing the cost by an order of magnitude. This approach reduces the accuracy of the simulation and therefore reduces the accuracy of the simulated position, velocity, etc. as of the last time step. However, in actual execution using the rule set generated by this optimization, there are several points to note about the effect of the control behavior:

[0230] 1. In actual implementation, the control system still uses a finer time step, such as a 100 millisecond time step, so that it can still respond quickly to unexpected events or different conditions.

[0231] 2. If the behavior of some dynamic objects changes in unexpected ways during actual execution, the actual results may differ significantly from the predicted results even if a fine-grained time-stepping simulation was used during rule generation. If not, then a coarse-grained time-stepping approach is likely to be accurate enough. The effect of a slight inaccuracy is likely to mean that a maneuver cannot be chosen in some situations where it is "barely" safe to do so. In short, unavoidable inaccuracies are introduced by the fact that the future cannot be known very accurately by the system. When the assumption about the future is correct, a coarse-grained simulation is adequate, and if that assumption is incorrect, a fine-grained simulation is no better; and

[0232] 3. The discretization of inputs usually introduces a certain level of inaccuracy. For example, considering an AV, the vehicle ahead can be mapped to a range of 7.5 to 10 meters as one of the ranges in the range set. The automatically generated simulation is then based on a certain value of that range, but not necessarily the actual distance. For example, the simulation can be simulated using a midpoint of 8.75 meters, so the potential inaccuracy in the initial conditions used for the simulation is up to 1.25 meters. There are also many other sources of inaccuracy, including inaccuracies in the input sensors and inaccuracies in the simulation model relative to the actual physical implementation. It can be noted that if the actual distance in this example is close to one of the boundaries, such as close to 10 meters away, it is likely to oscillate between that range and the next higher range in reality, causing the control to adjust accordingly, while if it is far from the boundary, such as about 8.75 meters, the estimate used in the rule generation is reasonably accurate. That is, when the estimate is most inaccurate, the subsequent time step is likely to compensate.

[0233] In general, the adequacy of a control system is based on:

[0234] 1. Not making bad decisions given the current scenario, as captured by the input conditions;

[0235] 2. Rapidly revise its decisions based on mispredicted changes in conditions and behaviors indicated by subsequent input values; and / or

[0236] 3. Given all sources of error / inaccuracy / uncertainty in the inputs, models, and future behavior, including elements outside the control of the control system, it is impossible to achieve optimal or extremely accurate control.

[0237] In summary, the cost of rule generation can be significantly reduced by using coarse approximation prediction simulations as part of action evaluation.

[0238] Selecting a set of input ranges. One aspect as described herein is selecting a set of ranges to be used to discretize the inputs. A plurality of potential ranges are predetermined / predefined by the engineering characteristics of the system (206) to be controlled. For example, a takeoff speed for an unmanned aerial vehicle is defined as part of engineering the system. Similarly, for a given vehicle, the maximum deceleration that the AV can achieve is also known. Additionally, a maximum safe steering angle for passenger comfort as a function of speed may also be defined by the known effects of the corresponding forces on the passengers.

[0239] These ranges defined by engineering characteristics can also be refined by adding intermediate thresholds to slightly increase the number of ranges. For example, starting from a technology-neutral model such as the Responsibility Sensitive Safety (RSS) safety model, there are ranges corresponding to safe distances from the vehicle ahead and to unsafe distances. However, within the unsafe range, two or more (sub-)ranges corresponding to different collision severities in the case where the vehicle ahead suddenly applies maximum braking can be identified. With this refinement, automatic generation can select different actions based on how unsafe the scenario is. For example, if the worst case scenario in the case where the vehicle ahead suddenly applies maximum braking is some kind of minor impact on the bumper of the vehicle ahead, the risk is relatively low.

[0240] Mapping the input value to the right range includes checking consecutive input values ​​against a threshold to map the value to a range, and outputting a range ID for the matching range. The input values ​​may still be pre-processed using known techniques, such as smoothing out small glitches in the input, as can be done with a Kalman filter.

[0241] In summary, discretizing the inputs into appropriate ranges may be simple to write, and selecting appropriate ranges and their associated thresholds is simplified by the engineering characteristics of the system and other known aspects, such as human factors.

[0242] Rule combination. In one embodiment, the automatic generation method checks each new rule against existing rules to see if it can be combined with the existing rules. This combination reduces the space of the table or associated rule condition code and also reduces the computational cost of rule condition evaluation.

[0243] For example, if a new rule Rj is identical to an existing rule Ri in terms of conditions and actions except for one binary sub-condition, then these two rules Ri and Rj can be replaced by a new rule Rk that "does not care" about the sub-condition. The term "don't care" as referred to herein is a term in the digital logic sense, also known as redundant, irrelevant, and / or irrelevant values ​​corresponding to terms that are not needed for a particular analysis. Then, for example, rule evaluation can use ternary matching.

[0244] Another rule combination method is to determine that rules Ri and Rj are identical except for the value of some input sub-condition IC, and rule Rk is identical to Ri and Rj except that the input sub-condition IC has a different corresponding action. In this case, rules Ri to Rj can be combined into a single rule Rij, and Rk can be designated as having a higher matching priority than Rij. The three rules can be combined so that when the input condition matches Rij as well as Rk, the combined rule matches, and when the input sub-condition IC corresponds to Rk, Rk will be used. This combination technique also applies when the code is generated as a nested box of "if ... else" boxes, as illustrated using the pseudo code below.

[0245]

[0246] As an example, given a set of input conditions, the behavior of the aircraft may be the same except when the altitude is in a range that places it close to the ground. Then, low altitudes correspond to Rk, and all higher altitudes correspond to Rij. This combination method can be extended to handle multiple specific values ​​plus a "don't care" case.

[0247] Another combination method is to recognize when a subset of rules are identical in terms of action, and differ pairwise in at most one "don't care" designation on the input, and are otherwise unique with respect to the other rules. In this case, the rule subset can be combined into a single rule, and matching can be done using the rule with the maximum mismatch of one , so even if the input is at most one The input will also match the rule if the input sub-conditions are different. This method can be extended to Approximate Match matchAs referred to herein, an "approximate match" is based at least in part on the results of a specified matching function applied between the input sub-condition and the mask. For example, based on a certain distance metric defined between the input sub-condition and the mask, if the input sub-condition is within a distance threshold, an approximate match can be provided by specifying a distance threshold parameter and outputting the input sub-condition as matched. Examples of specified matching functions are distance threshold functions and intensity threshold functions.

[0248] In one embodiment, according to some distance metric defined between the input sub-condition and the mask, if the input sub-condition is within the distance threshold, then the mask can be removed by specifying distance The threshold parameter and the output provide approximate matches according to the matched input sub-conditions. For example, a distance metric would be

[0249]

[0250] Where N is the number of input subconditions where the mask is true and the entry is false, or vice versa, P is the number of input subconditions where the entry is "unknown to be true" and the mask is true, and R is the number of input subconditions where the entry is known and the mask entry is unknown. The constants preceding these parameters can be specified in registers or variables and can therefore be changed dynamically depending on the application needs. Many other distance metrics and associated parameters can be implemented. In one embodiment, as the approximate matching operation matches each entry in the input subcondition with the mask, it incrementally calculates the distance, and once the calculated distance exceeds the distance threshold, a mismatch is determined. In one embodiment, the distance metric is specified as a relative percentage rather than an absolute value.

[0251] For example, rule subsets may be combined by selecting a minimum number of matches or a percentage of matches, where a post-matching process selects the best match from among these selected approximate matches.

[0252] Parallelized automatic rule generation. In one embodiment, the automatic generation of rule sets is performed in parallel by partitioning the input value combinations based on some criteria. For example, if the first three input variables can each take 10 values, each of the one thousand processors can be assigned to a specific triplet value of these input variables, and therefore one of the 1000 possible three-value combinations, and tasked with evaluating an input scenario with this setup of the first three input variables. Thus, each of the 1000 processors can execute in parallel to generate a subset of rules, where each processor is considering an input scenario separate from the other processors.

[0253] In the final step, all 1000 rule subsets can be merged into a final rule set. In a simple approach, these rule subsets are simply appended to the main rule set. In an embodiment, the above rule combination is performed as part of this merger, thereby reducing the total number of rules in the final rule set.

[0254] This parallel execution can greatly improve processing speed in many applications. For example, if a strictly sequential execution of automatic rule generation for autonomous vehicle design requires three years of continuous processing, parallelizing the execution with 1000 processors will reduce the execution time to approximately one day, making iterative refinement and correction of the model feasible. Given the modern feasibility of applying thousands of processors to host complex decision logic control applications, this parallelization capability means that even more expensive / detailed control models can become practical, especially given that the cost of the computations may still be much lower than the manual development of these control systems.

[0255] Fig.10 is a flow chart illustrating an embodiment of a process for automatically generating control decision logic for a control system. In various embodiments, Fig.10 The process can be done by Figure 1 In one embodiment, Fig.10 The control decision logic automatically generated by the result can finally be Figure 2 The control system (202) is implemented during execution.

[0256] Step (1002) iterates over possible input value combinations predicted by the engineering system. In one embodiment, prediction is a mechanism (e.g., software, hardware, firmware, or a combination) that, given an engineering system in an initial state, substantially determines a later state of simulated action of the given engineering system. For example, a flight simulator and a corresponding API for a third party interface may be an example of a prediction mechanism. In one embodiment, the engineering system is designed to have predictable performance that is satisfactory relative to application requirements captured by an objective function.

[0257] In one embodiment, the objective function includes a set of calculations that provide an indication of whether the engineered system behaves as expected and / or the objective function quantifies the difference between simulated behavior and expected behavior. An example of an objective function is a measure of safety / comfort for passengers on an aircraft.

[0258] In step (1004), the generated rule set is output for storage or further processing. In one embodiment, the generated rule set is further processed at least in part by using the generated rule set for subsequent execution of a control system for controlling an engineering system.

[0259] Fig.11is a flow chart illustrating an embodiment of a process for iterating possible input value combinations. In one embodiment, Fig.11 The process is as follows Figure 1 The computer shown in the Fig.10 Part of step (1002).

[0260] In step (1102), for a possible combination of input values ​​iterated over all possible combinations of input values, an action is selected to be performed on the engineering system. In one embodiment, for a possible combination of input values, a second action is selected to be performed on the engineering system, such as a portion of the iteration through all actions. In one embodiment, the action includes setting a set point for a controller, such as a PID controller for a throttle on an aircraft. In one embodiment, the action to be performed is selected based at least in part on the prediction and the objective function.

[0261] In one embodiment, selecting an action includes: iterating over potential actions for possible combinations of input values; and selecting the potential action as the action with the preferred outcome according to the objective function. In one embodiment, iterating over potential actions for possible combinations of input values ​​includes: predicting the behavior of the engineering system from an initial state consistent with the considered possible combination of input values ​​to a subsequent time assuming the considered potential action is taken; and evaluating the predicted state according to the objective function.

[0262] In one embodiment, steps (1002) and (1102) can be described in pseudo code as:

[0263]

[0264] In one embodiment, prediction of the behavior of an engineering system is performed by simulating the engineering system from states consistent with possible input value combinations forward in time.

[0265] In step (1104), a rule is generated - the rule specifies that when a possible combination of input values ​​is matched, the corresponding rule condition set is satisfied, and the corresponding action associated with the rule is the selected action. For example, if the autonomous aircraft is in a state slightly below the target altitude, possible actions include modifying the flaps, ailerons, and throttle settings. Reducing the throttle is likely to have a negative effect on the target, as is lowering the nose with the flaps, which is determined by the prediction of these action selections. Simply raising the nose of the aircraft may be effective as long as doing so does not put the aircraft in danger of stalling. The behavior is detected by predicting the behavior of the aircraft with the current airspeed range and the action selection. If the action will produce a stall, the objective function will assign a low rating to the action. The action may include increasing the throttle and adjusting the flaps. Therefore, each generated rule is constructed as a condition that is true for a given input value combination and an action that has been determined to be optimal for the objective function relative to the input value combination.

[0266] Fig.12 is a flow chart illustrating an embodiment of a process for selecting actions to be performed on an engineering system for possible input value combinations. Fig.12 The process is as follows Figure 1 The computer shown executes and / or acts as Fig.11 Part of step (1102).

[0267] In step (1202), a plurality of predictions of the engineering system are scored by evaluating an objective function associated with the engineering system using possible combinations of input values ​​and corresponding plurality of actions. For example, given a windy environment, the plurality of predictions may include what would be predicted given a first action of increasing throttle and a second action of decreasing throttle. The predictions may include: conventional time-stepping simulations; and simpler prediction functions, such as using an aircraft, if the elevator is down, the aircraft loses altitude.

[0268] In step (1204), an objective function associated with the engineering system is evaluated to select an action from a corresponding plurality of actions based at least in part on the plurality of predicted results. In one embodiment, the rule is automatically generated by a program that iterates over input value combinations and, for each potential input variable value combination IC, selects an action A' that is expected to achieve a good result with respect to the system objective function, and then outputs a rule having a condition corresponding to the input value combination, and the action is the action A'.

[0269] Fig.13 is a flow chart illustrating an embodiment of a process for iterating selection actions. In one embodiment, Fig.13 The process is as follows Figure 1 The computer shown in the Fig.11 Part of step (1102).

[0270] In an iteration, step (1302) selects the next action A. Step (1304) performs predictions using the selected action A, scoring the predicted results using the objective function. If action A has a better score than the previously saved action, step (1306) saves this action A as a candidate action. In one embodiment, the selection of action A' is performed by predicting the new state S' of the system at time T2 for each credible action A with input condition IC, assuming that it was in the state corresponding to IC at time T1 and it took action A. After each such prediction, the objective function is evaluated for this new state S' and the result is recorded. After recording the objective function values ​​for each such new state S' of all actions A, it selects the action A' that achieves the best objective function value. Fig.13 An alternative not shown in is to save all the scores for each action and choose the action with the best score when the iteration over the possible actions terminates.

[0271] In one embodiment, the input values ​​are discretized into a smaller number of possible values. In one embodiment, the input values ​​are discretized into a smaller number of possible values, and these discretized values ​​are used in the iteration over the input value combinations in place of the actual input values.

[0272] In one embodiment, the control decision logic is divided into pipeline stages. In one embodiment, the generated rule set corresponds to one of the pipeline stages. In one embodiment, the possible input value combinations correspond to one of the pipeline stages. In one embodiment, the selected action corresponding to the first pipeline stage is included as part of the second possible input value combination corresponding to the second pipeline stage. In one embodiment, a pruning function is used to eliminate some possible input value combinations.

[0273] Although the foregoing embodiments are described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways to implement the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system for rule generation, comprising: The processor is configured as: Iterate over possible combinations of input values ​​predicted by the engineering system, including: For possible input value combinations: Select actions to be performed on the engineering system for possible combinations of input values, including: scoring a plurality of predicted executions of the engineering system by evaluating an objective function associated with the engineering system and using possible input value combinations and corresponding plurality of actions; and selecting an action from a corresponding plurality of actions, the selection based at least in part on the plurality of predicted scores; and generating a rule—the rule specifies a corresponding set of one or more rule conditions that are satisfied when possible combinations of input values ​​are matched, and a corresponding action associated with the rule as the selected action; and outputting the generated rule set for storage or further processing; and The memory is coupled to the processor and configured to provide instructions to the processor.

2. The system according to claim 1, wherein: Given a predicted action and an engineered system in an initial state, the prediction substantially determines a later state of the engineered system.

3. The system according to claim 1, wherein: The engineered system is designed to have predictable performance relative to the application requirements captured by an objective function.

4. The system according to claim 1, wherein: The processor is further configured to select, in an iteration, a second action to be performed on the engineering system for the possible input value combinations.

5. The system according to claim 1, wherein: The action includes setting a set point of a controller.

6. The system according to claim 1, wherein: The action to be performed is selected based at least in part on the prediction and the objective function.

7. The system according to claim 1, wherein: The objective function indicates whether the engineered system behaves as desired.

8. The system according to claim 1, wherein: The objective function quantifies the difference between simulated behavior and desired behavior.

9. The system according to claim 1, wherein: The generated rule set is further processed, including by subsequent execution of a control system for controlling the engineering system using the generated rule set.

10. The system according to claim 1, wherein: The input value is discretized into a smaller number of possible values.

11. The system according to claim 1, wherein: The input values ​​are discretized into a smaller number of possible values, and the discretized values ​​are used in iterating over combinations of input values.

12. The system of claim 1, wherein: Select actions include: Iterate over potential actions for possible combinations of input values, including: Predict the behavior of the engineering system from an initial state consistent with a possible combination of input values ​​to a predicted state at a subsequent time, assuming the potential actions under consideration are taken; and Evaluate the predicted state according to the objective function; and Potential actions are selected as actions with preferred consequences according to the objective function.

13. The system according to claim 12, wherein: Predicting the behavior of an engineering system involves simulating the engineering system from states consistent with possible combinations of input values ​​forward in time.

14. The system of claim 1, wherein: The control decision logic is divided into pipeline stages.

15. The system of claim 14, wherein: The generated rule set corresponds to one of the pipeline stages.

16. The system of claim 14, wherein: A possible combination of input values ​​corresponds to one of the pipeline stages.

17. The system of claim 14, wherein: The selected action corresponding to the first pipeline stage is included as part of a second possible input value combination corresponding to the second pipeline stage.

18. The system of claim 1, wherein: The pruning function is used to eliminate some possible combinations of input values.

19. A method for rule generation, comprising: Iterate over the possible input value combinations predicted by the engineering system, for possible input value combinations, including: Select actions to be performed on the engineering system for possible combinations of input values, including: scoring a plurality of predicted executions of the engineering system by evaluating an objective function associated with the engineering system and using possible input value combinations and corresponding plurality of actions; and selecting an action from a corresponding plurality of actions, the selection based at least in part on the plurality of predicted scores; and generating a rule—the rule specifies a corresponding set of one or more rule conditions that are satisfied when possible combinations of input values ​​are matched, and a corresponding action associated with the rule as the selected action; and Output the generated rule set for storage or further processing.

20. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: Iterate over the possible input value combinations predicted by the engineering system, for possible input value combinations, including: Select actions to be performed on the engineering system for possible combinations of input values, including: scoring a plurality of predicted executions of the engineering system by evaluating an objective function associated with the engineering system and using possible input value combinations and corresponding plurality of actions; and selecting an action from a corresponding plurality of actions, the selection based at least in part on the plurality of predicted scores; and generating a rule—the rule specifies a corresponding set of rule conditions that are satisfied when possible combinations of input values ​​are matched, and a corresponding action associated with the rule as the selected action; and Output the generated rule set for storage or further processing.

Images