Restrictive inheritance-based rule conflict resolution

Abstract

A rule set is constructed to meet restrictive inheritance requirements. A rule is selected from a set of matching rules that do not have subsequent matching rules, wherein the set of matching rules is a subset of the set of rules. A rule action associated with the selected rule is output. Input is received from a sensor. A physical actuator is controlled based at least in part on the input from the sensor and the rule action associated with the selected rule.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 405,817, filed on September 12, 2022, entitled “Rule Conflict Resolution Based on Restrictive Inheritance,” which is incorporated herein by reference for all purposes. Background Art

[0003] Conventional rule-based systems may be limited in scope due to the complexity of rule conflicts during rule execution. It would be an improvement to apply rule-based systems to more substantial physical engineering by improving rule conflicts to use fewer computing resources (including fewer processing resources, fewer storage resources, and / or fewer network resources), and / or using reduced design time and / or reduced run time for rule-based systems. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0005] Figure 1 is a functional diagram illustrating a programmed computer / server system for efficient rules processing according to some embodiments.

[0006] Figure 2 is a graphic representation of restrictive requirements.

[0007] Figure 3 Illustration of an example that is part of a simple decision tree.

[0008] Figure 4 is a diagram of an example of a partial derivation rule.

[0009] Figure 5A and Figure 5B is a flow chart illustrating an embodiment of a process for generating fully specified derivation rules from partially specified derivation rules.

[0010] Figure 6 is a flow diagram illustrating an embodiment of a process for determining whether to generate a leaf node and a rule action to be used with a restrictive inheritance rule set.

[0011] Figure 7 is a flow diagram illustrating an embodiment of a process for resolving rule conflicts. DETAILED DESCRIPTION

[0012] The present invention may be implemented in a variety of ways, including as: a process; an apparatus; a system; a material composition; 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 or provided by a memory coupled to the processor. In this specification, these embodiments or any other form that the present invention may take may be referred to as techniques. In general, the order of the steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise stated, a component described as being configured to perform a task (such as a processor or memory) may be implemented as a general component that is temporarily configured to perform a task at a given time, or as a specific component that is manufactured to perform a task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores that are configured to process data (such as computer program instructions).

[0013] The following is a schematic diagram of the principles of the present invention. Figure 1 A detailed description of one or more embodiments of the present invention is provided. The present invention is described in conjunction with these 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 encompasses many alternatives, modifications and equivalents. In order to provide a thorough understanding of the present invention, many 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 material known in the technical field related to the present invention is not described in detail so as not to unnecessarily obscure the present invention.

[0014] In a computer rule-based system, specified rules may result in rule conflicts during rule execution. That is, the conditions of two or more rules are true, but their actions are different. For example, but not limited to, in an autonomous vehicle rule-based system (such as an autonomous aircraft), if one rule indicates to increase throttle and raise elevator when below target altitude, and another rule indicates to descend when an engine problem is detected, then when the two conditions occur, the two rules "fire", but the actions associated with the two rules are conflicting, i.e., contradictory.

[0015] Inputs for rule-based systems can be received from sensors. Sensors referred to herein are anything that detects, measures, and / or responds to physical properties and / or physical records. Examples of sensors include, but are not limited to: cameras, pressure sensors, speed sensors, level sensors, load sensors, position sensors, torque sensors, center of gravity sensors, feedback sensors, airspeed sensors, vertical speed sensors, altimeters, cabin pressure sensors, temperature sensors, variable transformer sensors, force sensors, vibration sensors, magnetometers, gyroscopes, data monitoring sensors, telemetry sensors, ultrasonic sensors, infrared sensors, speedometers, tachometers, tension sensors, microphones, mechanical sensors, electromagnetic sensors, electronic sensors, solid-state sensors, optical sensors, corporate stock exchanges (including sensors for sensing stock price values), and / or doctors' senses (such as their eyes / nose / hands). In one embodiment, rules associate inputs from sensors with sensor data interpretation.

[0016] Physical actuators are controlled based at least in part on rules in a rule-based system and inputs from one or more sensors. Physical actuators referred to herein are anything that causes a physical device to (further) act, display, and / or operate. Examples of actuators include, but are not limited to, machine control, aileron control, elevator control, stabilizer control, rudder control, flap control, leading edge device, spoiler control, trim system, autopilot switch, ejection seat activator, accelerator, brake control, steering control, parking brake control, light switch, communication control, robotic arm, LED display, database storage, magnetic / optical storage device, electromagnetic waves, stock purchase orders, and / or medical diagnostic records.

[0017] Traditionally, solutions to this problem teach the use of various rule conflict resolution methods, including using precedence, specificity, and even executing the actions of both rules. However, it is difficult to provide credible semantics for the resulting decision making using these methods. For example, in a rule set with 100 rules, there are potentially 2 100 possible triggering rule combinations, of which only 101 combinations correspond to "1 or 0 rules are active". That is, unless there are known constraints on the rule conditions that reduce these combinations, many quadrillions of rule combinations are to be considered. Therefore, it is generally not feasible to predetermine and specify the semantics of conflict resolution in this huge number of combinations that may occur through these conventional techniques. However, in many applications (including the example of rule-based automatic control of aircraft), correct behavior under all conditions (and therefore combinations of input values) is necessary, for example, to protect people and / or property from harm.

[0018] One improvement is the following restriction: requiring that there is no overlap between the rule conditions of any rule in the rule set. As referred to in this article, "overlap" is: for at least one input scenario or set of input values, the conditions of two or more rules are true. This restriction requires the ability to test overlap. For example, in the case of 100 rules in a rule set, there are approximately 10,000 possible rule pairs to be tested, and in order to try to detect overlap between each pair, there are potentially an impractical number of input value combinations unless there is a faster way to determine overlap. Many actual application rule sets are much larger than 100 rules. Therefore, it is largely impractical to do this manually. However, in the case of arbitrary rule conditions, although overlaps can be automatically detected by evaluating all rule conditions on all possible input combinations, this is generally not feasible for rule set compilers or similar tools. As an improvement, a means of automatically testing overlaps is disclosed.

[0019] Application rule sets are typically developed and evolved incrementally to expand the operational domain, and adding new sub-conditions / features / inputs is part of the process. Continuing with the autonomous aircraft example, the initial rule set may only consider how to maintain flight and avoid obstacles, without considering different forms of equipment failure. This initial rule set may contain hundreds of rules, if not more. Extending or evolving the rule set to handle component failures means adding inputs or features that indicate the operational state of the component.

[0020] Continuing with the example of an autonomous aircraft, a rule that "triggers" when there is an engine failure but not otherwise requires the addition of an input that indicates the engine's failure state. Existing rule set rules do not include this engine failure state as part of their rule conditions. Therefore, without modifying these existing rules, their conditions may be true regardless of whether the engine failure state indicates a failure. Therefore, traditionally, each existing rule potentially needs to be modified to consider the engine failure state sub-condition. Adding a new sub-condition to the rule (i.e., the engine failure sub-condition) and ensuring that there is no overlap means modifying each existing rule to consider the sub-condition, including adding a rule for when the condition is true. Otherwise, it is likely that the engine failure rule, which is triggered only when the engine failure condition is true, will match and overlap with all other rules that do not consider the engine failure condition.

[0021] On the other hand, if the conventional priority technique is used to give the engine failure rule a higher priority, it is possible that in the event of an engine failure, the aircraft will immediately descend even if the existing rules would not allow the aircraft to descend due to other traffic just below the aircraft. That is, a priority-based solution may result in a mid-air collision. Another alternative (i.e., using specificity) is that the rule used to react to the obstacle in this particular case may be more specific and therefore will be selected, thereby effectively ignoring the engine failure state. However, the appropriate response in this case may be to only temporarily maintain the current altitude before descending, rather than taking the action of matching any of the rules. Note that the correct rule for dealing with the additional sub-condition may be different in action from the existing rule (which shares the same existing sub-condition with the existing rule), that is, the correct new rule overlaps and conflicts due to different actions.

[0022] In practice, the rule set can be extended with multiple new inputs or features. Continuing with the autonomous aircraft example, when failures are added to the rule set as a consideration, there are usually many failure conditions to consider, such as aileron stuck, rudder failure, etc., rather than just one failure condition. If there are K such failure conditions and they are independent, then there are 2 failure conditions that include no failure. K possible combinations, so the failure condition potentially requires increasing the number of rules to 2. K times to avoid overlap. In the case where K takes a practical value, this can be a very large multiple. One result is that with each such evolution, the cost of developing and testing the rules becomes significantly higher. Therefore, when it may be necessary to add new features or inputs to the rule conditions, the strict enforcement of no overlap may make it extremely expensive to develop and test the rule specifications. At each extension, the developer of such a traditional rule-based system may have to go back and revise almost all of the existing rules.

[0023] Many applications require a single action in response to an input scenario. In addition, if it is known that there is a single rule action selected on each rule evaluation for a rule set, conventional techniques show how to transform the rule set into a decision tree, thereby allowing more efficient rule evaluation. In particular, the cost of rule evaluation is proportional to K (the number of inputs, not the number of rule conditions), which can be large. To illustrate with a simple example, if there are three inputs to the rule set corresponding to airspeed, altitude, and vertical speed and each of these inputs is mapped to 5 different ranges in the rule set, there can be up to (5*5*5)=125 rule conditions as combinations of these ranges, but the decision tree is only 3 inputs deep, one level for each input. Therefore, ensuring that a single rule action is selected each time is an improvement in human safety, system reliability, and efficient computing resources, and this requires achieving no overlap.

[0024] Another traditional alternative is to use so-called machine learning to automatically generate rules from labeled data sets. For example, using a labeled data set of aircraft positions, rules can be automatically generated to identify possible mid-air collision situations. However, using this approach, the rules are only correct in probability, and there is no guarantee that the correct rules will trigger to avoid mid-air collisions in all cases. In addition, because mid-air collisions and near misses are rare, it is impractical to obtain actual data for a large number of cases. In general, probabilistic or heuristic rules are only applicable when the cost of error is relatively low, and machine learning is only suitable for use when this is true and there are large labeled data sets available to train the system. This is not the case for autonomous aircraft and many other control systems, especially for emergency and other less common scenarios.

[0025] Figure 1 is a functional diagram illustrating a programmed computer / server system for efficient rule processing according to some embodiments. As shown, Figure 1 A functional diagram of a general purpose computer system programmed to provide efficient rule processing according to some embodiments is provided. As will be apparent, other computer system architectures and configurations may be used for efficient rule processing.

[0026] 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 by 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 the memory 110, the processor 102 controls the receipt and manipulation of input data, as well as the output and display of data on output devices (e.g., display and graphics processing unit (GPU) 118).

[0027] The processor 102 is bidirectionally coupled to a memory 110, which may include a first main storage device, typically a random access memory ("RAM"), and a second main storage device 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 temporary storage, 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 programmed instructions, used by the processor 102 to perform its functions. For example, depending on whether data access needs to be bidirectional or unidirectional, the main storage device 110 may include any suitable computer-readable storage medium described below. For example, the processor 102 can also directly and very quickly retrieve frequently required data in a cache memory not shown. The processor 102 can also include a coprocessor (not shown) as an auxiliary processing component to assist the processor and / or the memory 110.

[0028] 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 via the bus 114. The mass storage devices 112, 120 generally store additional programming instructions, data, etc. that are not usually actively used by the processor 102. It should be understood that if desired, the information retained in the mass storage devices 112, 120 can be incorporated as virtual memory in a standard manner as part of the main storage device 110 (e.g., RAM).

[0029] 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 input device, an audio card, a speaker, a touch (or pointing) device, and / or other subsystems as desired. In addition to a touch screen, auxiliary device 106 may be a mouse, stylus, trackball, or tablet computer, and is useful for interacting with a graphical user interface.

[0030] 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 may receive information (e.g., data objects or program instructions) from another network or output information to another network in the course of performing method / process steps. Information, typically represented as a sequence of instructions to be executed on the processor, may be received from another network and output to another network. The computer system 100 may be connected to an external network and data may be transferred according to standard protocols using an interface card or similar device and appropriate software implemented by the processor 102 (e.g., executed / implemented on the processor 102). For example, the various process embodiments disclosed herein may be executed on the processor 102, or may be executed across a network (such as the Internet, an intranet network, or a local area network) in conjunction with a remote processor (which 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, 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 connecting homogeneous and / or heterogeneous systems and / or groups of systems together. Additional mass storage devices (not shown) may also be connected to processor 102 via communication interface 116.

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

[0032] 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 that can then be read by a computer system. Examples of computer-readable media include, but are not limited to, all of the above media: flash media, such as NAND flash, eMMC, SD, compact 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 codes include, for example, machine code generated by a compiler or files containing higher-level code (e.g., scripts) that can be executed using an interpreter.

[0033] 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, bus 114 illustrates any interconnection scheme for linking subsystems. Other computer architectures with subsystems in different configurations may also be utilized.

[0034] Efficiently Resolving Rule Conflicts. An efficient and semantically meaningful means of resolving rule conflicts is disclosed to ensure correct operation of rule-based systems while ensuring efficient rule evaluation, such as provided by transformations to decision trees.

[0035] As referred to herein, rules are merely conventional "if ... then" / conditional ... action statements that are recognized by the compiler and can be manipulated by the compiler. Without limitation, nothing herein is meant to imply or require or exclude that rules be executed by a rule execution engine in a manner that is conventionally possible.

[0036] Rules are included in a partial ordering rule set with restrictive requirements. As used herein, partial ordering is used in the conventional mathematical sense, because except for a "first" rule, each rule has a rule "before" or less than it - its predecessor, and if rule R1 is less than R2 and R2 is less than R3, then R1 is less than R3 (transitivity), and if R1 is less than R2, then R2 cannot be less than R1. The term successor of Ri is used herein to refer to a rule Rj that is greater than rule Ri in the partial ordering. (It is called "partial" because for some rule pairs Ri and Rj, there may be a rule Ri that is neither less than nor greater than Rj). The following restrictive requirements are defined and referenced herein:

[0037] 1. There is a default or first rule that is the (indirect) predecessor of all rules in the rule set in this partial ordering;

[0038] 2. Each successor rule Rj of a rule Ri in the rule set must match (at most) a subset of the input scenarios matched by the rule condition of Ri; and

[0039] 3. There is no overlap between the input scenario matched by a successor rule Rj of Ri and the input scenario matched by another successor Rk of Ri.

[0040] Figure 2 is a graphic representation of restrictive requirements. Figure 2 As shown, the scenes matched by Rj (204) and Rk (206) are subsets of the scenes matched by Ri (202), and the scenes matched by Rj (204) do not intersect with the scenes matched by Rk (206). Figure 1 As shown, Ri (202) is the default / first rule. Another alternative is that the input scenario of Ri is included in the set of input scenarios handled by another first rule Ro, which is Figure 1 Not shown in FIG, the scenario matched by Ri (202) is a subset of the scenario matched by Ro. A rule set that meets the restrictive requirement is referred to herein as a restrictive inheritance rule set.

[0041] Informally, Figure 2 It can be thought of as a simple hierarchy where the rule-based system designer defines what to do in case Ri (202), and the designer identifies (notes) sub-case exceptions Rj (204) where the corresponding action is different from the action of the main case Ri (202). The designer can also identify a second sub-case exception Rk (206) where the corresponding action is different from the action of the main case Ri (202), which can be the same action as the action specified by Rj (204) or a different action. Figure 2 As shown, due to restrictive requirements, Rj (204) and Rk (206) do not overlap.

[0042] The rule set compiler can check and enforce these rule requirements if it can compare the set of input scenarios that one rule condition matches with another rule condition. In one embodiment, each rule condition is evaluated on every possible combination of input values ​​(i.e., input scenario) to see when both rule conditions evaluate to true.

[0043] If Rj or Rk matches a scene outside the range matched by Ri, this will violate the restrictive requirement. If there is an input scene that matches both Rj and Rk, this will also violate the restrictive requirement.

[0044] When evaluating an input scenario using a restrictive inheritance rule set, when multiple rule conditions are matched, conflict resolution selects the one rule Rj that has no successor in the matching set to operate on. As referred to herein, Rj overrides its predecessor, and conversely, its predecessor rule is overridden by Rj.

[0045] This method enables the selection of exactly one rule in the restrictive inheritance rule set. This is because multiple rules Ri and Rj may match the same input scenario only if Rj follows Ri in the partial ordering (and vice versa). In addition, as stated in the restrictive requirements parts (1) and (3) above, a rule Rk that is not partially ordered relative to Rj cannot be selected because it cannot overlap with the scenario matched by Rj. Part (1) ensures that any two rules in the rule set have at least one common predecessor, namely the first or default rule. It also ensures that the rule condition of at least one rule is matched on each input combination, namely the default rule.

[0046] Using a restrictive inheritance rule set differs from traditional rule conflict resolution. Priority-based methods impose a complete ordering on the rules and impose no requirements on the rule conditions between rules. Specificity methods simply require that the rule with the most matching attributes be selected, which is not necessarily a rule that matches a strict subset of another matching rule. Random selection or "latest" selection methods use completely different criteria.

[0047] Similarly, in practice, an overriding rule may be generated by refining an existing rule set with additional conditions. For example, consider again a rule set for controlling an autonomous aircraft that initially did not consider engine failure. Subject to other relevant constraints, the rule added to deal with engine failure overlaps with the previous rule that was not constrained by the aircraft's fault state. Therefore, the new rule constrained by the fault state overlaps with the existing rule that was not constrained. To meet the restrictive inheritance requirement, the new rule needs to have a rule condition that matches a subset of the input scenarios of the existing rules, and it needs to include the fault state. Since the existing rules do not include the fault state, the new rule must match the subset of input scenarios matched by the existing rules, namely the subset that indicates an engine failure. By relying on restrictive inheritance conflict resolution, there is no need to modify the existing rules to deal with the fault condition as part of adding the rule. The new rule simply "overrides" the existing rule when its rule condition is true.

[0048] In one embodiment, a first or default rule is specified with a rule condition that matches all input scenarios and a rule action that corresponds to a default action, such as "act outside the operational domain". With this rule condition, it clearly matches a superset of scenarios for any possible rule, so it is a precursor to all possible rules. The default action is taken to act on any input scenario that no other rule in the rule set matches.

[0049] Restrictively derived rule set. In one embodiment, the rule set DRS can be specified as restrictively derived from a base restrictive inheritance rule set BRS (as referred to herein), thereby including all rules in BRS in the DRS. In this case, if the input scenario matched by DRm is a subset of the input scenario matched by BRj, then the rule DRm is referred to in this article as being derived from the rule BRj in the rule set BRS. If the derived rule set adds additional features or sub-conditions to be considered, the base rule is interpreted as implicitly specifying "don't care" for these additional sub-conditions. This derivation is referred to as restrictive inheritance in this article. Restrictive inheritance requires that each rule in the DRS is derived from a rule in the BRS, and there is no overlap between two rules in the DRS that are derived from a common base rule. The rule set compiler can automatically check that the restrictive inheritance requirements are met between the specified base rule set and the derived rule set.

[0050] With restrictive inheritance, assuming that BRS is a restrictive inheritance rule set, DRS is also a restrictive inheritance rule set. This is because, for any two rules R1 and R2, if they are derived from different base rules, they cannot overlap because their respective base rules do not overlap and their matching domains are contained in the matching domains of their respective base domains. If they are derived from a common base rule, they cannot overlap based on the base restriction on overlap. Therefore, restrictive inheritance rule conflict resolution can also be applied to DRS.

[0051] Restricted inheritance between rule sets allows application-level rule sets to be incrementally developed from base rule sets without having to go back and modify existing rules in, for example, a base rule set. Instead, the introduced derived rules simply override existing rules in the special cases required. For example, using the previous example of an autonomous aircraft, the rule for acting below a target altitude and in the presence of an engine failure is a derived rule of the base rule for below target altitude. Note that there may be separate rules for the aircraft being at or above the target altitude. The base rule subconditions provide the necessary conditions regarding the aircraft and vicinity; the derived rule combines the subconditions of the base rule and adds the engine failure subcondition.

[0052] Restricted inheritance facilitates the development, maintenance, and evolution of application rule sets while ensuring that a single predictable action is taken for each input. It also allows efficient rule evaluation by being convertible to decision trees, as described below. This restricted rule set inheritance is similar to the use of inheritance in object-oriented programming ("OOP") in the sense that derived types build on existing base types without directly modifying the existing base types. However, it differs in that derived rules are restricted to apply only to a subset of input scenarios to which the base rules apply. Note that, in contrast to conventional / unrestricted OOP inheritance, derived types can override restrictions in base types to make instances more general than the derived type possible.

[0053] Note that, as required by the above definition of restrictive inheritance, a derived rule must effectively inherit the sub-conditions (or a restricted version thereof) of a base rule in order to be restricted to a subset of the scenarios matched by the base rule. Said another way, a derived rule overrides its base rule when a derived rule condition or conditions are true. In this sense, a derived rule specializes the action of a base rule when the derived rule condition is true. Note that this specialized action can be completely different from the action of the base rule.

[0054] Given the requirement for a default rule (from which all rules are derived), any restrictive inheritance rule set can be implemented as a restrictively derived rule set from a base rule set that contains only default rules for associated sub-conditions or attributes (as they are referred to in traditional approaches). This construction justifies the term restrictive inheritance rule set; that is, a rule set with only a single rule that is the default rule is a restrictive inheritance rule set. Furthermore, any restrictive inheritance rule set can be implemented as a restrictive inheritance structure from this single rule set. There can also be multiple levels of (restrictive) inheritance between the default rule and the final application-level rule set. Note that a base rule set can have multiple derived rule sets, each of which is a separate rule set.

[0055] In one embodiment, a rule may specify an array of parameter values ​​to be used as its decision action. For example, the array values ​​may specify a target range for throttle, elevator, aileron, etc. In this example, the action of the derived rule may be the result of combining the array of parameter values ​​of the base rule with the array of parameter values ​​of the derived rule. Returning to the previous example - flying below the target altitude and an engine failure occurs - the engine failure parameter may significantly limit the control parameters associated with the climb, so the combined result with the downward flight is to only maintain the current altitude while the flight exists. This is essentially the intersection of the ranges of the corresponding parameters between the two action value arrays. The rule set compiler may support other methods of combining rule actions to generate the actual action of the derived rule.

[0056] Note that sub-conditions of base rules can be included by reference, thereby reducing duplication in the rule set, especially if the end result is a decision tree - given that decision trees can make rule evaluation more efficient. For example, a partially specified derived rule can contain a list of base rules as determined by the rule set compiler, from which the derived rule restrictively inherits. In one embodiment, such a partially specified derived rule explicitly specifies one or more of its base rules, rather than matching the base rule based solely on overlap, and is referred to herein as an explicitly specified base rule. An explicitly specified base rule can also be a partially specified derived rule.

[0057] A decision tree can be generated for a restrictive inheritance rule set in the following way:

[0058] 1. Generate a decision tree for a base rule; that is, a base rule with no base rule or with a default base rule; and

[0059] 2. For each leaf of the base tree, generate a decision subtree for the derived rules corresponding to the base rule of the leaf.

[0060] That is, overlapping rules are in a decision subtree that deals with the decision subtree of the rule that overlaps with it, and vice versa.

[0061] Figure 3 An illustration of an example that is part of a simple decision tree. Figure 3 , the root decision node (302) determines whether the aircraft is flying (304). If the aircraft is flying, the root decision node selects whether the aircraft is below the target altitude (306); this is the base rule. In the case of an engine failure, the shaded decision node for engine failure (308) overrides the base rule (310), and the base rule action (312) is used in other cases. If the aircraft is not flying, the root decision node selects whether the aircraft is taxiing (326); this is the second base rule. In the case of a brake failure, the shaded decision node for brake failure (328) overrides the second base rule (330), and the second base rule action (332) is used in other cases.

[0062] Because the derived rule for handling engine failure is required to follow restrictive inheritance, the derived rule has a rule condition that is an additional restriction on the base rule. The additional restriction in this case is that an engine failure is required. Therefore, its additional condition (engine failure) can be attached to the leaf node of the base decision tree. If the derived rule also restricts other conditions (such as the degree below the target altitude), there will be an additional decision node in the derived decision subtree that tests the degree below the target altitude. The situation for the derived rule for handling brake failure while taxiing (330) is similar (only relevant in the subtree indicating that the aircraft is taxiing) and only overrides the base rule action (332) when a brake failure occurs.

[0063] This construction shows that decision trees can be generated for rule sets that comply with restrictive inheritance requirements, i.e., where there are base rules that do not overlap each other and each derived rule restrictively inherits from one of the base rules. It is not excluded to use one of the efficient conventional methods to generate decision trees from such rule sets.

[0064] Partially Specified Derived Rule Sets. In one embodiment, one or more rules in a derived rule set may be designated as partially specified derived rules. A partially specified derived rule as referred to herein is a derived rule whose conditions specify only the difference between a base rule or base rule set and a rule or rule set that is desired as the final result derived rule or rule set, as opposed to a complete rule condition and action. In the former case, the base rule(s) may be explicitly specified, as indicated above when referring to explicitly specified base rules. Alternatively, as described below, a partially specified derived rule may be derived from each base rule that overlaps with it. (The former case may be considered to be a partially specified overlap, as defined by the rule conditions in each specified base rule).

[0065] Figure 4 is a diagram of an example of a partial derivation rule. Figure 4 In the section, the derived rules specify the rule (402):

[0066] If you are in flight and an engine fails,

[0067] Then descend carefully Figure 4In FIG. 4 , the root decision node (404) determines whether the aircraft is flying (406). If the aircraft is flying, the root decision node selects whether the aircraft is below the target altitude (408). When the aircraft is not flying below the target altitude, the shaded decision node for engine failure (410) overrides the base rule (414) in the case of an engine failure, and uses the base rule action (412) in other cases. When the aircraft is flying below the target altitude, the shaded decision node for engine failure (420) overrides the base rule (424) in the case of an engine failure, and uses the base rule action (422) in other cases.

[0068] As referred to herein, rule (402) is partially specified because it does not indicate a desired value for the aircraft altitude relative to the target altitude. As described above and without limitation, a partially specified derived rule may explicitly specify its base rule or determine its base rule by overlapping. In this example, the partially specified rule has conditions that overlap with two base rules, namely: (1) a base rule for flying below the target altitude, and (2) a base rule for flying at or above the target altitude. Therefore, the rule set compiler creates two derived rules, as indicated by the dashed arrows (403a), (403b) in the accompanying drawings, one derived rule for each of these base rules. Therefore, in this example, it produces a fully specified derived rule (414) corresponding to the condition of flying below the target altitude and an engine failure, and a fully specified derived rule (424) corresponding to the condition of flying above the target altitude and an engine failure.

[0069] Figure 5A and Figure 5B is a flow chart illustrating an embodiment of a process for generating a fully specified derivation rule from a partially specified derivation rule. In one embodiment, Figure 5A and Figure 5B The process is Figure 1 The system and / or ruleset compiler is executed.

[0070] like Figure 5A and Figure 5B As shown, the process includes: in one part, for each pair of partially specified derived rule sets and base rule sets (whose rule conditions overlap), iterating on the partially specified derived rule sets and nested iterations on the base rule sets, plus testing the overlap of the associated rule conditions, thereby generating a suitable derived rule, and adding it to the derived rule set unless the generated rule conflicts with another derived rule (in which case, the conflict is reported instead).

[0071] In step (502), the next partially specified derivation rule is selected from the derivation rule set and the marked PSDR. According to the previous example, the partially specified derivation rule can be:

[0072] PSDR: If in flight and an engine fails,

[0073] Then descend carefully

[0074] In step (504), if there are no more PSDRs, the control flow stops and the process is complete; otherwise, the rules in the base rule set are iterated in step (506). In part, for each rule in the base rule set that overlaps with the rule condition of the PSDR, as determined in step (520), the process obtains the next base rule in step (508) and generates a derived rule condition with maximum coverage of scenarios that meet the conditions consistent with restrictive inheritance, as shown in step (522). For example, if the base rule is:

[0075] If in flight and above 1000 feet, and there is traffic below, increase altitude

[0076] The rule condition for a fully specified derivation rule would be

[0077] If in flight and at an altitude greater than 1000 feet, with traffic below, and an engine failure,

[0078] Then maintain altitude by adding the sub-condition of "greater than 1000 feet" from the base rule, and the sub-condition of "engine failure" from the derived (partially specified) rule. Note that there may be a separate base rule for: flying below 1000 feet and there is traffic below. In that case, Figure 5A A single iteration in the process of / 5B will combine the PSDR with this single base rule to produce:

[0079] If you are in flight and the altitude is less than 1000 feet, and there is traffic below you, and there is an engine failure,

[0080] Then {corresponding action}

[0081] In both cases, as shown in step (524), the action for the generated fully specified derived rule results from the combination of the action of the PSDR and the current base rule. For example, in the first case, the base rule action is to climb, while the derived rule action is to descend. The combination as an intersection results in an action that only maintains altitude. On the other hand, if the base rule does not overlap with the PSDR in step (520), control flow is transferred to step (508) via node (B) to obtain the next base rule.

[0082] As the final step in the iteration started in step (506), the rule set compiler checks to see in step (526) whether the generated derived rule overlaps with any other fully specified derived rules in the derived rule set. If so, the process indicates an error in step (528) and transfers the control flow via node (B) to step (508) to obtain the next base rule. Otherwise, the generated derived rule is added to the derived rule set in step (530). Then via node (B) to step (508), the control flow continues to process the next base rule in the base rule set. If there are no more base rules to be considered for PSDR in step (510), it selects the next partially specified derived rule (if available) in the derived rule set in step (502) and repeats the iteration on the base rule started in step (504) as described above. If there are still base rules to be considered for PSDR in step (510), the control flow is transferred via node (A) to step (520) as described above.

[0083] In one embodiment, the derived rule specifies a combination method, which is used to combine the action of the derived rule with the action of each base rule. The specific combination method may include:

[0084] 1. Intersection - take the intersection of the parameter values ​​between two rules;

[0085] 2. Override - use the derived parameter value for anything different than the base rule action;

[0086] 3. Union – effectively taking two actions; and / or

[0087] 4. Library - Find a combination action in the library

[0088] Other action combination methods may be supported.

[0089] With respect to the library approach described above, in one embodiment, the action of the actual derived rule or decision rule generated from the specified derived rule is generated from a combination of the action of the base rule and the action of the derived partial rule. For example, for an autonomous aircraft, the combination of the derived partial rule for left engine failure with the "slow climb" rule produces a rule with an action labeled "slow climb + left engine failure". The application can then map the rule action name to the appropriate actual action or select a default action (possibly using so-called "wildcard" matching of the name). For example, for K different possible failures, the developer can define approximately K squared rules and map each rule to a default best-efforts action, which corresponds to the presence of two or more failures occurring simultaneously. Then, as described in U.S. Patent Application 18 / 225,627, filed on July 24, 2023, entitled "Automatic Generation of Rules and Controls from Partial Rule Sets," which is incorporated herein by reference for all purposes, if the fault response is defined as a partial rule set union of component partial rule sets (one partial rule set for each component), then all combinations of two or more faults are mapped to the best effort action. The developer may then only need to specify rule actions for each fault in conjunction with the base rules. This is an improvement in processing, as the number of independent fault combinations may be very large (as previously implied).

[0090] In general, the rule set compiler instantiates a fully specified derived rule for each base rule that overlaps with the rule conditions of the derived rule. In extreme cases, in a practical version of this example, a partially specified derived rule (such as an engine failure rule) is likely to overlap with every rule in the base flight operation base rule set, since engine failure may occur in any situation. As in the previous example, the derived rule set can incorporate environmental factors by adding sub-conditions that characterize external conditions (such as other navigation, weather conditions, etc.) and associated rules and actions.

[0091] For partially specified rules in a derived rule set, the developer of the derived rule set may only need to specify additional sub-conditions, or any restrictions on the original sub-conditions, and the associated actions and action combination methods. The rule set compiler may handle the actual generation and checking of the rules and the automatic transformation to a decision tree representation. The rule set compiler may accomplish the latter by selecting the most derived rule to resolve conflicts between base and derived rules when under the conditions to which it applies. In this way, with restrictive inheritance, there is at most one rule action for a given combination of input values, and therefore, a decision tree may be generated to provide efficient rule evaluation.

[0092] In one embodiment, a rule set operator uses the method disclosed in U.S. Patent Application 18 / 225,627 to generate a derived rule set that may include partially specified derived rules. For example, a partially specified derived rule set for introducing equipment failure response can be generated as a union of multiple partial rule sets, one for each different power plant and control surface on the aircraft. Then, the rule set compiler uses the above method to generate fully specified derived rules based on these partially specified derived rules and the base rules.

[0093] Partially specified derived rules and their treatment relative to base rules are similar to derived classes in traditional object-oriented programming languages ​​(such as C++). Specifically, C++ derived classes only specify the differences between the expected actual derived class and the specified base class. That is, the derived class does not repeat the member functions and data members of the base class, but includes them by referencing the base class, and they are logically and actually part of the derived class when executed. In addition, similar to the overrides that occur with partially specified derived rules, the derived class can specify one or more member functions that also exist in the base class to override these base member functions. However, for C++, there is a single explicitly specified base class, while the partially specified derived rules are effectively and implicitly derived from each base rule in the base rule set that overlaps with it, and the rule condition and rule action generation for the actual derived rule is more complicated.

[0094] Rule set compiler support. The rule set compiler can be used to automatically read, check, and optionally convert a restrictive inheritance rule set into a decision tree. In one embodiment, the compiler can automatically infer that a rule DR is derived from a base rule BR based on the overlap of the rule DR with the base rule, i.e., DR is a successor of BR in partial order. That is, the compiler can determine one or more base rules whose rule conditions correspond to a superset of the scenarios matched by the current rule DR, rather than explicitly specifying the derived rule DR of its predecessor. For example, returning a reference Figure 3 , the rule set compiler may determine that a derived rule (whose condition specifies flying, below target altitude, and engine failure) overlaps with a base rule (flying and below target altitude), and infer (restrictive) inheritance from this, thereby automatically identifying the base rule as a base rule for that particular derived rule. Thus, the following may be automatically performed by the rule set compiler: determining which are the base rules, and checking the derived rules against these base rules. When a rule is not a derived rule of another rule, the rule set compiler may report an error if a rule overlaps with two different base rules. For example, a rule that specifies a rule condition of (flying above or below target altitude and aileron stuck) will overlap with a base rule for flying above target altitude and a separate base rule for flying below target altitude.

[0095] Note that if a derived rule DR is a subset of a base rule, it cannot be a derived rule of another base rule, because the base rule is assumed and required not to overlap with any other rule in the base rule set. Therefore, for the rule set compiler, in addition to determining the base rule, it is sufficient to just verify that there is no overlap between the rules in the derived rule set.

[0096] Using the example of an autonomous aircraft to illustrate, a first-level base rule set can handle flight operations without considering external factors such as altitude, weather, and other navigational factors. The rule set compiler can verify that the base rule set does not contain any overlapping rules. Then, a derived rule set can be developed that includes additional features and inputs (including sub-conditions) for external factors and rules that override the behavior of the base rules based on these additional sub-conditions. The rule set compiler can then verify that each rule in the derived rule set of the base rule set restrictively inherits from a rule in the base rule set and does not overlap with another rule in the derived rule set with the same base rule. Therefore, assuming the restrictive inheritance property of the base rule set, the compiler can verify that the derived rule set produces a single rule action on each input value combination by only checking for overlaps between rules in the derived rule set and between derived rules and rules in the base rule set.

[0097] A rule set compiler can use various techniques to determine overlap between rule conditions. For example, it can exhaustively evaluate rule conditions using all possible input values. In some cases, it may be feasible to analyze rule conditions to reduce the number of input values ​​to consider. Restricting the form of rule conditions to reduce compile-time evaluation is an improvement. Specific restrictive forms are described below.

[0098] In one embodiment, one or more sub-conditions are specified as one or more ranges for a given decision value. For example, the "low altitude" sub-condition can be specified as an altitude between 5 feet and 400 feet. Utilizing these sub-conditions, it is more efficient to automatically determine whether a given sub-condition in rule R1 overlaps with a corresponding sub-condition in another rule R2 in terms of computing resources for the compiler. Continuing with the above example, if the first sub-condition uses a low altitude sub-condition as defined above, and the second sub-condition uses a reduced range of 5 feet to 100 feet, the latter sub-condition is identified as overlapping (and included in) the first altitude range.

[0099] In one embodiment, the rule conditions are specified as a conjunction of identified sub-conditions, each of which is specified as the above range. In this case, the compiler directly detects overlaps and subsets between rule conditions and generates revised rule sub-conditions. For example, if the engine failure partial derived rule specifies an altitude range between 5 feet and 40,000 feet, and the base flight rule specifies different actions between 5 feet and 400 feet and between 400 and 40,000 feet, the rule set compiler can split the derived rule into one rule for 5 feet to 400 feet and one rule for 400 feet to 40,000 feet in order to maintain the subset requirements for the actual derived rule.

[0100] Methods for selecting actions when generating a decision tree. Techniques such as those described in "RBDT-1: a New Rule-based Decision Tree Generation Technique" by Amany Abdelhalim, Issa Traore, and Bassam Sayed can generate a decision tree based on rules. Among them, when a subset of rules for the current subtree all lead to the same rule action, a decision tree leaf node is generated, and when all subconditions of the rule condition have been evaluated, when two or more rules with different actions remain in the subset, it is considered an error. However, with a restrictive inheritance rule set, there may be multiple rules with different actions at this time. Therefore, these traditional methods can be improved / modified / extended to cope with the restrictive inheritance rule set described in this article.

[0101] Conventional techniques (including those cited above) recursively construct decision trees by selecting a sub-condition or attribute for the next decision node of a decision sub-tree, and then partitioning the rules associated with the decision path to the node based on the value of the sub-condition, recursively generating a decision sub-tree for each partition of the rule. The path from the root node to the current decision node in the decision tree represents a partial rule condition corresponding to the conjunction of the sub-conditions of each decision node on the path. For example, in Figure 4 In FIG. 4 , the “engine failure” node ( 420 ) corresponds to the partial rule condition “in flight and below target altitude”.

[0102] Typically, a leaf decision node is generated when there is a single rule in a partition or when all rules in a partition assign the same action. However, with restrictive inheritance, a partition logically contains all base rules for any rule in the partition, and these base rules typically have different associated actions.

[0103] Figure 6 1 is a flow chart illustrating an embodiment of a process for determining whether to generate a leaf node and a rule action to be used with a restrictive inheritance rule set. Figure 6 The process is Figure 1 The system and / or ruleset compiler is executed.

[0104] When a new subtree of a decision tree is to be generated, there is a partition or subset SCR of rules such that each of these rules has a rule condition that can be true given a path to the root node of the subtree. Before selecting the next subcondition / attribute, with a restrictive inheritance rule set, the following process is performed to determine if a leaf node can be generated instead at this time:

[0105] 1) In step (602), an effective default rule condition (EDRC) is generated for the node using the default action, ie, a partial rule condition corresponding to the path to the decision node.

[0106] 2) As shown in the loop starting from step (604), for each rule R in the subset SCR:

[0107] a) In step (608), the intersection of rule R and valid default rule conditions is generated;

[0108] b) in step (610), checking whether the rule condition generated by the intersection covers the valid basic rule condition or has the same action as the valid basic rule condition;

[0109] c) if it is no in step (610), then indicate that there is a conflict in the leaf node partition and exit the iteration, where control flow is transferred to step (612); and

[0110] d) Otherwise, if rule R has no successor in SCR, the rule action of the rule is recorded as a potential action for the leaf, and the control flow is transferred to step (604) for the next rule in the subset SCR.

[0111] 3) If no conflict is detected in step (604) and no more rules exist, the control flow is transferred to step (606) to generate a leaf node with the recorded potential rule action PRA as the rule action of the leaf node.

[0112] 4) If a conflict is detected in step (612) and there are more sub-conditions to consider, the process generates sub-trees for the rules in the SCR according to conventional techniques in step (614).

[0113] If a conflict exists at step (612), but there are no additional attributes or sub-conditions that distinguish the conflicting rules, then it is not feasible to complete the decision tree and an error is indicated as shown at step (616).

[0114] Note that the effective default rule condition is the base rule condition for all rules in the SCR. Therefore, if there are two rules R1 and R2 in the SCR, either R1 is the base rule of R2 or vice versa. Otherwise, if both R1 and R2 cover the effective default rule condition, they overlap in the rule condition, but do not have an inheritance relationship, thereby contradicting the restrictive inheritance requirement.

[0115] Note that this approach does not exclude the generation of unnecessary subtrees when the rules in the partition are not related to inheritance but have the same action. However, further note that such duplication is not specifically related to restrictive inheritance.

[0116] As disclosed, rule conflicts, which traditionally would have been run-time, are resolved at "compile time" (i.e., when a decision tree is generated by identifying when a rule overrides another rule to resolve the conflict). This provides a computational resource improvement, i.e., rule conflict resolution overhead is eliminated from rule evaluation.

[0117] Figure 7 is a flow chart illustrating an embodiment of a process for resolving rule conflicts. In one embodiment, Figure 7 The process is Figure 1 The system and / or ruleset compiler is executed.

[0118] In step (702), a rule set is constructed to satisfy a restrictive inheritance requirement. In one embodiment, this step may occur at compile time. In one embodiment, this step may occur at runtime. In one embodiment, restrictive inheritance is implemented in part by restrictively deriving a rule set from a base rule set, which is a restrictive inheritance rule set. In one embodiment, one or more derived rules are partially specified and concretized using partially specified restrictive inheritance. In one embodiment, a rule condition is specified as a conjunction of sub-conditions. In one embodiment, one or more sub-conditions are indicated as a range of values.

[0119] In step (704), a rule is selected from a set of matching rules that have no successors, wherein the set of matching rules is a subset of the rule set. In one embodiment, this step may occur at compile time. In one embodiment, this step may occur at runtime.

[0120] In one embodiment, selecting a rule from a set of matching rules that do not have a successor is based at least in part on rule evaluation. In one embodiment, selecting a rule from a set of matching rules that do not have a successor is based at least in part on decision tree generation. In one embodiment, when two or more rules are applicable to an input, decision tree generation avoids multiple matches by selecting the last derived rule.

[0121] In step (706), the rule action associated with the selected rule is output. In one embodiment, the rule action output is a combination of the rule actions of the base rule and the derived rule, wherein the base rule is a rule from the base rule set.

[0122] In step (708), an input is received from a sensor. In step (710), a physical actuator is controlled based at least in part on the input from the sensor and a rule action associated with the selected rule.

[0123] Improvements. Improvements to conflict resolution using restrictive inheritance-based rules include savings in computing resources and human development cycles, including:

[0124] 1) Minimum specification for developers. Given an existing basic rule set and the need to extend and revise it to expand its operational domain, developers only need to specify the increments of the basic rule set using partially specified derived rules and restrictive inheritance without modifying the existing basic rules;

[0125] 2) Rule conflict resolution makes sense and can be checked by the compiler ahead of time, since overlapping rules logically override base rules. This also avoids the overhead of conflict resolution during rule evaluation; and / or

[0126] 3) Given that there is a single action per evaluation, the compiler can enforce the absence of overlap at each inheritance level, thereby enabling efficient rule execution by automatically generating decision trees from the rules.

[0127] Although the foregoing embodiments have been described in detail for the purpose 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 rather than restrictive.

Claims

1. A system comprising: sensor; Physical actuators; a processor coupled to the sensor and the physical actuator, wherein the processor is configured to: Constructing rule sets to satisfy restrictive inheritance requirements; selecting a rule from a set of matching rules that have no successors, wherein the set of matching rules is a subset of the set of rules; outputting the rule actions associated with the selected rule; receiving input from said sensor; as well as The physical actuator is controlled based at least in part on the input from the sensor and the rule action associated with the selected rule. 2 . The system of claim 1 , wherein selecting the rule from the set of matching rules without successors is based at least in part on rule evaluation. 3 . The system of claim 1 , wherein selecting the rule from the set of matching rules without successors is based at least in part on decision tree generation.

4. The system of claim 3, wherein when two or more rules are applicable to an input, decision tree generation avoids multiple matches by selecting the last derived rule.

5. The system of claim 1, wherein restrictive inheritance is implemented in part by restrictively deriving the rule set from a base rule set, the base rule set being a restrictive inheritance rule set.

6. The system of claim 5, wherein one or more derivation rules are partially specified and concretized using partially specified restrictive inheritance.

7. The system of claim 6, wherein one of the one or more partially specified derived rules explicitly specifies at least one of its base rules.

8. The system of claim 6, wherein one of the one or more partially specified derived rules is derived from at least one base rule that overlaps therewith.

9. The system of claim 6, wherein the output rule action is a combination of rule actions of a base rule and a derived rule, wherein the base rule is a rule from the base rule set.

10. The system of claim 1, wherein a rule condition is specified as a conjunction of sub-conditions. The system of claim 10 , wherein one or more sub-conditions are indicated as a range of values.

12. The system of claim 1, wherein the restrictive inheritance requirements include: There is a default or first rule that is the predecessor of all rules in the rule set in a partial ordering.

13. The system of claim 1, wherein the restrictive inheritance requirements include: Each successor rule of a given rule in the rule set matches at most a subset of the input scenarios matched by the rule condition of the given rule.

14. The system of claim 1, wherein the restrictive inheritance requirements include: There is no overlap between the input scenarios matched by a first successor rule of a given rule and the input scenarios matched by a second successor rule of the given rule, wherein two rules overlap if their conditions are true for at least one input scenario or set of input values.

15. The system of claim 14, wherein overlap is determined by exhaustively evaluating rule conditions using all possible input values.

16. The system of claim 14, wherein overlap is determined by pre-analyzing the rule conditions using a reduced number of input values ​​to evaluate the rule conditions.

17. The system of claim 1, wherein selecting the rule from the set of matching rules without successors is based at least in part on a rule condition of the selected rule and the input from the sensor.

18. The system of claim 1, wherein if a derived rule set adds additional features or sub-conditions, then its base rules are interpreted as implicitly specifying "don't care" for these additional features or sub-conditions.

19. A method comprising: Constructing rule sets to satisfy restrictive inheritance requirements; selecting a rule from a set of matching rules that have no successors, wherein the set of matching rules is a subset of the set of rules; outputting the rule actions associated with the selected rule; receiving input from sensors; as well as A physical actuator is controlled based at least in part on the input from the sensor and the rule action associated with the selected rule.

20. The method of claim 19, wherein restrictive inheritance is achieved in part by restrictively deriving the rule set from a base rule set, the base rule set being a restrictive inheritance rule set.

21. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: Constructing rule sets to satisfy restrictive inheritance requirements; selecting a rule from a set of matching rules that have no successors, wherein the set of matching rules is a subset of the set of rules; outputting the rule actions associated with the selected rule; receiving input from sensors; as well as A physical actuator is controlled based at least in part on the input from the sensor and the rule action associated with the selected rule.

22. The computer program product of claim 21, wherein restrictive inheritance is implemented in part by restrictively deriving the rule set from a base rule set, the base rule set being a restrictive inheritance rule set.

Images