Resource utilization decisions in systems with autonomous capabilities.

Abstract

Resource utilization decisions in systems with autonomous capabilities. A computer-implemented method for determining resource utilization in a system having autonomous capabilities. The method comprises receiving (304) a plurality of input data from each of a plurality of components of the system and receiving (302) rule set data including a plurality of rules. Each of the plurality of rules is configured to determine an integrity value for the input data. The method further comprises processing (306) the plurality of input data and the rule set data to generate an integrity value for each of the plurality of input data and using (308) the integrity value to determine resource utilization of the system.

Description

[Technical Field]

[0001] The present invention relates to determining resource utilization in systems with autonomous capabilities. [Background technology]

[0002] Various types of systems with autonomous capabilities have been developed. Examples include air, ground, and / or water-based / sea-based vehicle systems that can automatically respond to stimuli detected by sensors to control some of their onboard components, such as speed / direction controllers. In some existing aircraft with autonomous capabilities, the pilot operates the aircraft's sensors through controls in the cockpit. The operator uses their own experience to determine the most appropriate sensor to use and can also determine which sensor mode to use for the current task. The sensors and sensor modes are controlled discretely and independently; i.e., the use of one sensor does not affect the use of another sensor.

[0003] Modern and future sensors are more powerful and can "see" further, thereby generating more data and consequently increasing the amount of information (clutter) presented to the operator. The growth in modern sensor capabilities, coupled with growth in autonomy, can pose significant challenges for operators when determining which sensors, which sensor modes, and which combinations of sensor types will produce the most effective image. This may even be an impossible task for humans.

[0004] In military situations, it is conceivable that in the future, adversaries may be able to spoof nearly imperceptibly, making it virtually impossible for current sensor systems to distinguish spoofs from real entities. Understanding how autonomous systems respond to stimuli can provide an adversarial advantage to malicious actors. For example, an adversary can inject spoof entities into a system, e.g., multiple radar or infrared detections, to create the impression of multiple threats instead of a single aircraft. There have been cases where an autonomous drone was forced to land due to adversarial exploitation of the relationship between sensor inputs and resulting system behavior. Every entity detected by a vehicle, even a spoof, requires sensor resources, e.g., sensor tracking effort. Multiple entities require even more effort to track. It is important to avoid wasting sensor resources when multiple entities are spoofs, e.g., injected by a malicious actor.

[0005] Furthermore, although most advanced systems with autonomous capabilities include error checking and fault detection, and a great many errors and faults can be detected, there may still be insidious faults / errors that may not be detected by existing systems.

[0006] Humans have an intuitive sense that develops from learned experiences. Often, intuition and consideration of evidence for consequences coincide, but often they do not. Although an individual may be presented with objective evidence, including sensory output, that initially points to what appears to be an obvious conclusion, humans often still rely on intuition, which may suggest an opposite conclusion that then proves correct. This intuition is based on subtle nuances about how information is presented to the individual. These nuances may relate to how the data was originally generated, where it came from, when it was generated, and its quality.

[0007] Intuition is difficult to truly describe or simulate, but it often considers facets of the received data that would not normally be considered to compile a picture of confidence, rather than simply an objective conclusion. If a protection system could rely on innate "gut feeling" rather than just raw data (which can be spoofed), task-based cockpit systems and the like would not expend significant effort tracking spoofed entities—entities that are very often known to be false by human pilots—while the system continues to interleave with track / lock / follow activity. Currently, no automated system addresses this problem. Summary of the Invention

[0008] SUMMARY OF THE INVENTION Embodiments of the present invention are intended to address at least some of the above-mentioned technical problems.

[0009] Embodiments may use a schema / rule set to determine the level of investment needed, for example, in terms of system resources, based on the threat level and potential threat level of objects detected by sensors. Embodiments may provide protection to products that consume data from multiple, disparate, distributed sources (e.g., different platforms and different sensors, and geographically distributed) to support decision-making based on the reliability of that data.

[0010] Embodiments may perform cross-checking activities to determine by cross-checking whether the data being received is authentic, i.e., not spurious. Embodiments may also determine a level of importance based on the currently performing activity, which affects the level of effort invested in the amount of cross-checking activity, with more effort being invested if there is a high level of importance. By considering a combination of conditions regarding the source and quality of the data, embodiments may provide protection against excessive resource consumption due to sensor spoofing.

[0011] Embodiments can also protect against system failures, not by identifying failures, but by assessing the integrity of the data generated by the system and seeking to ensure that resource usage decisions made using that data have the required data integrity (i.e., the data can be trusted).

[0012] According to one aspect of the present invention, there is provided a computer-implemented method for determining resource utilization of a system having autonomous capabilities, the method comprising: receiving a plurality of input data from a respective plurality of components of the system; receiving rule set data comprising a plurality of rules, each of the plurality of rules configured to determine an integrity value of input data; processing the plurality of input data and the rule set data to generate an integrity value for each of the plurality of input data; outputting an integrity value; and using the integrity value to determine resource utilization of the system.

[0013] The plurality of input data may comprise a plurality of track data output by a respective plurality of sensors, where each of the plurality of track data comprises information regarding at least one entity detected by the respective sensor.

[0014] The method may comprise, for example, using the integrity value to determine sensor utilization in future tracks of the detected entity.

[0015] The track data may include location information (e.g., latitude, longitude, and / or altitude) of the detected entity, the speed of the detected entity, the direction of the detected entity, and / or the type of the detected entity (e.g., vehicle type).

[0016] The method may further include obtaining additional sensor data from at least one of the plurality of sensors. The additional sensor data may be used by at least one of the plurality of rules. The additional sensor data may include information regarding a reliability of track data provided by the sensor and / or a type of sensor.

[0017] The integrity value may represent a confidence level that a detected entity in the track data is a real object, and a rule in the rule set data may determine a high integrity value for the track data when it determines that a detected entity in the track data is likely to be a real object.

[0018] The rules may comprise: generating a low integrity value for the input data if the input data indicates abnormal behavior of a detected object or system component; and / or Producing a high integrity value for input data if the input data matches one or more other input data.

[0019] The rules in the rule set data relating to the track data may be selected from a set including: determining a high integrity value if the detected entity of the track data is also detected in at least one other track data of the plurality of track data; determining a low integrity value when there is a significant difference (e.g., greater than a threshold of 250 m) in the detected position of the detected entity between the track data and at least one other track data of the plurality of track data; Determining a low integrity value when the type of detected entity in the track data at the location detected by the sensor is abnormal (e.g., track data showing a passenger aircraft flying at an abnormally low level is given a low integrity value, while flying at a normal / expected altitude over a particular area is given a high integrity value); determining a low integrity value if the type of detected entity in the track data is not operating within the known performance limits of a certain type of vehicle (e.g., track data showing a helicopter flying at an unexpected high speed would be given a low integrity value, and a high integrity value if flying within its normal expected speed range); determining a low integrity value if the detected entity in the track data originates from a hostile country; and / or Determining a low integrity value when the behavior of a detected entity in the track data is abnormal (e.g., a civil flight suddenly turns towards the vehicle and increases its speed).

[0020] The method may comprise fusing a plurality of track data to generate a list of fusing tracks.

[0021] The method may further comprise receiving task data relating to a plurality of tasks to be performed during use of the system. In some embodiments, the task data may identify objects and / or areas and actions to be taken with respect to the objects and / or areas, for example, a task comprising tracking an object within a defined area.

[0022] The method may further comprise checking the determined integrity value for each input data associated with the task and generating data indicating whether the resource providing the input data (e.g., a sensor outputting track data) should continue to be used for the task. For example, if the integrity value of the input data (e.g., track data) is below a threshold, the method may generate data indicating that the component (e.g., a sensor) outputting the track data should not be assigned to future tasks.

[0023] Each of the multiple tasks may have an associated importance value, and the task threshold may vary according to the task's importance value, e.g., a lower threshold may be set for a task with a low importance value, while a higher threshold may be set for a task with a high importance value. The thresholds and / or importance values ​​may be defined in a schema / rule set by a system operator.

[0024] The method can further include receiving a plurality of resource usage data, each of the plurality of resource usage data comprising a value representing a current usage level relative to a maximum usage capacity of a resource of the system, wherein the resource may comprise said sensor of the system or another resource / component of the system.

[0025] The method further comprises: receiving a plurality of resource usage data, each of the plurality of resource usage data comprising a value representing a current level of usage of a resource of the system; and processing the resource usage data and the task data to generate a target usage level for the resource used in association with the task.

[0026] For example, the method may further comprise analyzing data indicating whether a sensor outputting track data should continue to be used for the task and the plurality of resource usage data to determine a future usage level of at least one of the sensors for use in connection with the task. The task may comprise tracking an object using a resource comprising the sensor, and the process may comprise reducing a target usage level of the sensor if the sensor has a low data integrity value.

[0027] According to another aspect of the present invention there is provided a (computing) device comprising a processor configured to carry out a method substantially as described herein.

[0028] According to yet another aspect of the present invention there is provided a system having autonomous capabilities comprising a processor configured to carry out a method substantially as described herein. The system may comprise or be associated with a vehicle.

[0029] According to another aspect, there is provided a computer program product comprising instructions which, when executed by a computer, cause the computer to perform a method substantially as described herein. [Brief explanation of the drawings]

[0030] For a better understanding of the present invention, and to show how embodiments thereof may be carried into effect, reference will now be made, by way of example, to the accompanying drawings in which: FIG. [Figure 1] FIG. 1 is a block diagram of an exemplary vehicle system including a computing device configured to implement embodiments. [Figure 2] FIG. 2 is a block diagram that schematically illustrates the configuration of a computing device including an integrity generator software component, a proportionality checker component, and a resource monitor component. [Figure 3]FIG. 3 is a flowchart illustrating exemplary steps performed by the integrity generator component. [Figure 4] FIG. 4 is a flowchart illustrating exemplary steps performed by the proportionality checker component. [Figure 5] FIG. 5 is a flowchart illustrating exemplary steps performed by the resource monitor component. DETAILED DESCRIPTION OF THE INVENTION

[0031] FIG. 1 is a block diagram of an exemplary system 100. While the detailed examples provided below are based on a vehicle system, it will be understood that embodiments may be used in connection with other types of systems having autonomous capabilities. A "system having autonomous capabilities" may also include the autonomous portion of a manned system. The vehicle in this example may include any type of land, air, or surface / sea vehicle, such as an aircraft, having autonomous capabilities. Various levels of vehicle autonomy exist, and according to embodiments, the vehicle system may be configured to receive control commands from a human operator, which may be onboard the vehicle or located remotely. Common components of a vehicle, such as a body, engine, communication system, etc., are not shown for ease of explanation but are well known to those skilled in the art.

[0032] The vehicle system 100 comprises a computing device 102. The computing device may be substantially conventional and includes or is associated with at least one processor 104 and internal memory 106, e.g., random access memory. The internal memory can store data and instructions for execution by the processor. The computing device further includes at least one interface 108 that enables communication with other components / devices, e.g., via any suitable wired / wireless interface and / or communications network. The computing device may include or be associated with additional conventional features, such as a non-volatile storage device, a user interface, etc., that need not be described in detail herein. The computing device may be mounted within or on the vehicle, or may be remote from the vehicle, communicating via a network.

[0033] The computing device 102 communicates with multiple sensors 110A, 110B via the interface 108. The sensors may be mounted in or on the vehicle, or in some cases may be remote from the vehicle. Examples of sensors include radar, LIDAR, accelerometer, GPS, etc. For ease of explanation, only two sensors are shown in this example, but it will be understood that any feasible number of sensors, which may be of the same type or different types, may be used with the embodiments.

[0034] The computing device 102 may also communicate with one or more other components / resources 112A, 112B associated with the system / autonomous vehicle via the interface 108. Examples of such components include fuel tanks, weapons systems, etc. For ease of explanation, only two components are shown in this example, but it will be understood that any feasible number of components, which may be of the same type or different types, may be used with the embodiments.

[0035] The computing device 102 may further communicate with a vehicle interface component 114 via the interface 108. The vehicle interface component may include a display used to display information to an operator of the vehicle system. In some embodiments, the vehicle interface component may include or communicate with a vehicle control system (not shown) that issues control signals directly to components of the vehicle, for example, vehicle propulsion or steering components.

[0036] 2 is a block diagram of software components used by computing device 102, according to an exemplary embodiment. It will be appreciated that in alternative embodiments, the software components may be combined or arranged differently.

[0037] Embodiments can fulfill two primary roles. The first role is to help conserve and optimize system resource usage by ensuring that resources, such as sensors, are used proportionally based on some criteria. The second role is to ensure that information (e.g., generated by a sensor fusion system) upon which vehicle behavior or operation decisions are based is not spurious. By using a rule set or schema, embodiments can declare the level of effort to be invested in verifying whether received information is true or false. For example, for tasks that require a significant investment of resources, such as tracking a high-threat target, more demand is generated to ensure the correct level of resources is invested. If an entity is detected but presents little or no threat, embodiments can determine that little or no effort is required to ensure a proportional level of resources is invested in tracking it.

[0038] Embodiments can use a schema / rule set to ensure that multiple data sources, e.g., different sensor types, sensors from other aircraft (collaborators), optionally along with open-source data (such as location), or any other attributes, are integrated to create assurance and suggest a level of “truth”—in this case, truth represented by a score. Embodiments can generate a value / score based on the number and type of sensors and other available data to generate sensor resource investment requirements. The more sensors and types that can detect an entity, the higher the score (although it will be understood that this is merely an example and that alternative embodiments can use lower values ​​or non-numeric rating systems). This, combined with how threatening the entity may be, can create sensor demand; more actual entities and threat levels result in proportional sensor demand. Multiple spurious entities, while clearly a threat, will result in lower demand for sensors.

[0039] The exemplary embodiment includes an integrity generator component 202 that can process various information, such as vehicle location, behavior, and sensor type, to generate an integrity value / rating for each data received as input by the integrity generator component, e.g., data generated by the system's sensors. The exemplary embodiment further includes a proportionality checker component 204 that can determine, based on the input data's perceived threat and / or integrity rating, how much effort should be expended in the future with respect to that input data, e.g., with respect to tracking entities detected by one or more of the sensors. The component can use a schema / predetermined rule set to, for example, attempt to ensure that sensor resources are not wasted tracking spoof entities. The exemplary embodiment further includes a resource monitor component 206 that can be driven in part by a schema, such as a sensor schema. In some embodiments, the component can output an indication that current resource usage should be changed. The data received as input by the various components can be stored in memory 106 of the computing device 102 or received from a remote source.

[0040] FIG. 3 is a flowchart illustrating exemplary steps performed by the integrity generator component 202.

[0041] In step 302, the integrity generator component 202 receives a data integrity schema that includes a set of rules for determining the integrity rating / value of input data. Examples of the rules are shown below. The schema is created by one or more experts; for example, a radar sensor data expert may create rules that are used to determine the integrity of track data generated by radar-based sensors in the system 100. The schema may be modified for each mission; for example, the rules that are most likely to be appropriate for a particular mission are selected by an operator for use as the schema data input in step 302.

[0042] In step 304, the integrity generator component 202 receives input data from components of the system 100. The input data can take various forms and can be provided by anything that converts information about the system or the external environment into system data. Examples include track data output by each of multiple sensors, e.g., sensors 110A, 110B, regarding the entities they detect, and, optionally, additional data from one or more of the sensors. Examples of track data include latitude, longitude, altitude, speed, and tracks of one or more detected entities. Examples of additional sensor data include information about the type of sensor. Different sensors may provide more or less data depending on their capabilities, and some smart sensors may be able to provide a form of confidence for the data they provide. Track data from multiple sensors / platforms can be fused to generate a fused track list.

[0043] Embodiments may be applied to any system that uses data, where rules may be applied to that data, e.g., air data, navigation data, fuel system data, hydraulic system data, and / or electrical system data, to assess its integrity. It will be appreciated that complex systems may operate using thousands of different types of data, and a non-exhaustive list of examples of input data that may be processed by embodiments includes: air data (speed, pressure, temperature, etc.), hydraulic system data (pressure, temperature, contents, pump status), fuel system data (contents, temperature, pressure, flow rate), inertial system data (rotational rate, orientation, acceleration, velocity, position), weapon system data (store volume, store status, target information), GPS data (position, speed, altitude, time), navigation system data, non-track-related radar data, transponder data, cockpit interface data (button presses, stick / throttle movement, switch positions), human physiological data (heart rate, skin temperature, blood pressure, pupil size, gaze), and data pre-loaded into the system (navigation data, target data, route, mission).

[0044] In step 306, the integrity generator component 202 processes the received data and determines how trustworthy the data can be, which may involve applying one or more rules from the schema to each input data to generate a score / number that can be used as its integrity value / rating.

[0045] The following are examples of rules that may be applied to determine the integrity of each input track data: Is it normal for the truck to be in that position (e.g. why is the plane flying at a low level?) - If so, determine a low integrity value. · Is the truck within its known performance limits (e.g., why is a helicopter flying at 350 knots?) If so, determine a high integrity value. Did the aircraft depart from an unexpected location (e.g. why did a friendly aircraft depart from an enemy country) - if so, determine a low integrity value. Truck behavior is unusual (e.g., why did a commercial flight suddenly veer toward us and increase its speed?) - If so, determine a low integrity value. Is the track not seen by other sensors (e.g. close enough to be seen by the FLIR, but the FLIR is not picking it up, or allies should be able to see it on their radar, but can't)? - If so, determine a low integrity value. ·Are there significant differences in track position between sensors? - If so, determine a low integrity value.

[0046] Other examples of rules / criteria that may be used by embodiments to evaluate input track data include: · Is the detection unusual (e.g., four aircraft detected in an area where only two vessels normally operate)? - If so, determine a low integrity value. ·Can multiple sensors detect these entities? If so, determine a high integrity value. · Can multiple cooperating aircraft detect these entities using different sensors (to ensure all radars are not spoofed)? If so, determine a high integrity value. ·Can you identify the individual signatures of detected entities? If so, determine a high integrity value.

[0047] It will be appreciated that the above rules are merely exemplary and that more / alternative rules may be provided depending on the data integrity schema being created and the type of data being evaluated.

[0048] Examples of rules that may be applied to determine the integrity of input air data include: If the climb rate of the detected object is greater than the climb rate of the aircraft, a lower integrity value is determined. If the detected vehicle acceleration is greater than the maximum known acceleration for that type of vehicle, determine a low integrity value. If the detected vehicle speed is greater than the known maximum speed for that type of vehicle, determine a low integrity value. If speed and climb rate do not match, determine a lower integrity value. If the pressure is higher or lower than possible, or changes at a rate greater than possible, determine a low integrity value. If the pressure changes in the wrong direction (i.e., the pressure increases instead of decreasing), determine a low integrity value.

[0049] Some of the above rules can be used to identify low integrity data caused by simple failures such as pitot / static system blockages. While a human pilot is likely to be able to identify the signs of a pitot / static system blockage, a traditional autonomous system may not be able to do so.

[0050] Examples of rules that can be applied to determine the integrity of input GPS data include: - Determine a low integrity value if the detected vehicle altitude does not match the air data system. If there are jumps in the position data or the position integrity is poor, a low integrity value is determined. If the time or rate of change of time is inconsistent with other time sources, determine a low integrity value. If the detected position is varying differently from that given by the INS position or naval derived position, determine a low integrity value.

[0051] As another example, a fuel system sensor failure may result in an over-reading of fuel content. This may cause the pilot or autonomous system to commit to a particular route, resulting in fuel starvation and loss of the aircraft. An embodiment configured with appropriate rules can continuously evaluate the integrity of fuel system data. Aberrant behavior, such as increased fuel content, fuel content exceeding the maximum capacity of a fuel tank, or a discrepancy in fuel usage rates, may result in low fuel data integrity. This may alert the pilot, allowing them to make appropriate decisions regarding the task, and / or provide integrity data to the autonomous system, which may then determine that it does not have the fuel data integrity required to make certain routing decisions. While embodiments do not detect such failures and are unaware that less fuel is available than required for the mission, the embodiment may determine that there is insufficient integrity in the data to allow certain resource usage decisions (e.g., committing an engine to navigating a particular route) to be made.

[0052] In some cases, the rule determination may correspond to a binary yes / no (e.g., either 1 or 0), while in other cases the determined numerical value may be a number within a range (e.g., 0 to 10) to indicate a confidence score or the like. Various factors may be combined into an overall integrity score for each input datum, for example, by summing the values ​​of all applied rules, possibly using a weighted average.

[0053] At step 308, the generated integrity assessment may be output by the integrity generator component 202. The output integrity assessment may include a numerical value determined for each input data processed and / or other information, such as information identifying the system component that provided the input data, each entity detected in the input track data, and / or associated sensors. The integrity assessment may be received as input by the proportionality checker 204 and / or the resource monitor component 206 and / or any other component that can use the integrity values ​​to determine future utilization of the system's resources. The steps performed by the integrity generator component may be repeated at small, regular intervals, for example, several times per second, or whenever new track data is received from a sensor. Thus, embodiments can determine resource utilization in substantially real time based on current data input, such as sensor detections.

[0054] 4 is a flowchart illustrating exemplary steps performed by the proportionality checker component 204. The proportionality checker component is intended to evaluate whether the integrity of the data processed to perform a task is proportional to the scale / magnitude / importance of the task (e.g., required resource use, risk, outcome, etc.). The importance value may be determined by a system operator.

[0055] In step 402 , the proportionality checker component 204 receives as input the integrity assessment data from the integrity generator component 202 .

[0056] In step 404, the proportionality checker component receives as input data regarding multiple tasks to be performed during the current mission assigned to the system 100. The tasks can take a variety of forms. For example, one of the tasks can identify an entity or area and an action to be taken in relation thereto, such as tracking a detected foreign aircraft or detecting any entities within an area defined by a set of coordinates. Tasks can range from large, mission-level tasks to very small, system- or subsystem-level tasks. Tasks are hierarchical, with larger tasks being composed of smaller tasks.

[0057] A non-exhaustive list of example tasks includes mission-level tasks (tasks involving multiple platforms working together to achieve a common goal, such as reconnaissance missions, air superiority missions, jamming missions, relocation missions, humanitarian missions, etc.), platform-level tasks (tasks involving a single platform, such as following a route, dropping stores, refueling, circling a track, observing, or illuminating), system-level tasks (tasks involving a single system, such as stopping a transmission, tracking a target, or initiating jamming), and subsystem-level tasks (tasks involving part of a system, such as transferring fuel from one tank to another, turning off a cooling system, changing a subsystem mode, or turning on a light). In step 406, the proportionality checker component 204 processes the received data. In some embodiments, this processing can involve checking the integrity assessment generated for one or more of the input data associated with a particular task. The required data integrity is task-dependent; for example, low-integrity data may be acceptable for some tasks but not others. The required (e.g., minimum numerical) data integrity required for a particular task can be defined in a schema / rule set by the system operator.

[0058] For example, if a task is tracking a particular aircraft, the integrity ratings of all track data in which that aircraft has been detected (e.g., within a recent time window) may be evaluated. If the integrity ratings of all associated track data are below a certain threshold, this suggests that the detected entity is a spoof, and thus the proportionality checker may generate an output indicating that the number of sensors assigned to the task is imbalanced. Additionally or alternatively, if only one (or a few out of many) track data has a high integrity rating and the others are low, the proportionality checker may generate an output indicating that the sensors assigned to the task are imbalanced.

[0059] As another example, allocating four aircraft to perform a mission will use a lot of fuel and expose the aircraft to potential danger. This is a large-scale task, and the data used to make that decision must have very high integrity. Therefore, a proportionality checker may generate an output indicating that the data integrity value is insufficient if the data integrity value is below a high threshold. An unnecessary drop in fuel can have consequences for a single aircraft, and therefore the data integrity required to make that decision must be proportional. Therefore, a proportionality checker may generate an output indicating that the data integrity value is insufficient if the data integrity value is below an associated threshold. Turning on a light has low consequences, and therefore the data integrity required to make that decision is likely to be low. Therefore, a proportionality checker may generate an output indicating that the data integrity value is insufficient only if the data integrity value is below a relatively low threshold.

[0060] In step 408, the proportionality checker component 204 can output the data generated in step 406. The data can comprise information regarding whether resources being used for a task, such as sensor utilization, should be modified, or an indication that the data integrity value is not high enough for a particular task. In some cases, the output data can correspond to a binary yes / no (e.g., either 1 or 0), while in other cases, the output data can include a numeric value within a range (e.g., between 0 and 10) to indicate a confidence score or the like. The data can be received as input by the resource monitor 206 and / or output to the component 114, for example, to display a warning to an operator that sensors are being disproportionately utilized. The generated data can also be output to one or more other systems, such as a component that can determine what to do if the data integrity value does not meet a desired data integrity set by an operator or the like.

[0061] 5 is a flowchart illustrating exemplary steps performed by resource monitor component 206. In some embodiments, the resource monitor component operates as a proportionality checker applied to tasks already in progress (i.e., it can determine whether data integrity is high enough to continue executing a particular task that has already started), while the proportionality checker component 204 may be used to determine whether data integrity is high enough to begin executing a particular task. In other embodiments, the steps shown as performed by the resource monitor component are a subset of those performed by the proportionality checker component (i.e., there is not necessarily a separate resource monitor component).

[0062] In step 502 , the resource monitor component 206 receives as input the integrity evaluation data from the integrity generator component 202 .

[0063] In step 504, the resource monitor component receives as input data from the proportionality checker component 204. Thus, the resource monitor can receive an indication of the level of sensor resources invested to ensure proportionality.

[0064] At step 506, the resource monitor component receives as input data regarding resource usage. This data may be received from some or all of the sensors 110A, 110B and / or some or all of the other components 112A, 112B associated with the vehicle system 100. The resource usage may be a numerical value, such as a score out of 10 or a percentage, representing the current usage relative to the maximum usage / capacity of a particular resource. The data may include further information such as a sensor or component identifier, type information, etc.

[0065] At step 508, the resource monitor component 206 processes the received data. This may involve analyzing the integrity assessment, resource usage data, and task data to generate information regarding whether usage of resources, such as sensors, should be modified. As an example, if the determination indicates that a real (i.e., non-spoof) entity has been detected but its threat level is perceived to be low, the use of a schema by the resource monitor component 206 can ensure that sensor resources are not wasted on tracking potential spoof entities.

[0066] In step 510, the data generated in step 508 may be output. The output data may comprise information regarding how resource usage should be altered or continued, such as a target usage level for a resource to be used in the future in connection with a particular task. For example, the output may include data indicating that a particular sensor should no longer be used, or its usage level should be reduced, in connection with tracking a particular detected entity determined to be at risk of spoofing. Thus, embodiments may generate an output indicating that usage of a particular resource should be reduced to reduce the risk of wasting resources on a spoof track. However, if a new task is created to perform a different action on the same tracked target, the scale of the task may increase, and therefore the data integrity required to undertake the new task may be increased. To achieve this, one or more of the following resource usage controls may be used: increasing sensor resources on the target, combining / comparing existing information for that target, tasking another sensor to provide information on the target, and / or tasking another platform to provide information on the target.

[0067] The data generated in step 508 may be output to the vehicle interface component 114. For example, that interface may display information to an operator that, based on the received data, resource usage, including sensors, should be modified taking into account the determined integrity of the track data and other factors. In some cases, the data may be used to directly / autonomously modify the vehicle system so that sensor usage is modified, while in other cases, human operator confirmation or selection may be required based on suggestions generated by the resource monitor component, such as, for example, using resources with increased data integrity until a task can be undertaken. Thus, embodiments may use data based on the integrity values ​​to determine future utilization of resources, such as which sensors should be used, and in what mode, for future tracks of one or more of the detected entities.

[0068] Some smart sensors may use schemas to define their behavior, e.g., which mode is used. Sensor schemas are complex rule sets that can manage sensor behavior based on operating conditions and what the sensor reports is being detected. Schemas can be used to create or present behaviors. Considered in this context, schemas can be used to manage which sensor types are used in which modes in response to the detection of an entity. For example, if a detected entity is moving at a high speed relative to the vehicle, it may be considered more threatening, and therefore the system should invest more sensor resources in tracking that entity.

[0069] Some embodiments may perform additional actions, such as comparing the outputs of proportionality checker 204 and resource monitor 206 for discrepancies, e.g., alerting an operator that they are using resources inappropriately.

[0070] Embodiments can build a perceived level of integrity by considering freely available sources of intelligence, i.e., open intelligence (OpIntel). Thus, if embodiments know the quantity and type of aircraft in an area, e.g., a collision zone, the level of integrity or confidence can be increased. Embodiments can improve traditional aircraft detection using features that simulate human intuition by considering other attributes that traditional detection systems do not.

[0071] By allocating resources proportional to the perceived importance of a threat, such as a detected object, embodiments can help ensure that system resources are not devoted to low-priority tasks, such as tracking when a detected entity is actually a spoof or poses little threat. By using embodiments, autonomous systems can be better protected from manipulation by adversaries. Embodiments can protect against some system failures and inconsistencies that would previously go undetected.

[0072] Those skilled in the art will understand that the component embodiments described herein may be implemented using any suitable software application, programming language, data editor, etc., and may be represented / stored / processed using any suitable data structures, etc. It will also be understood that steps described herein as part of the detailed embodiments may be reordered, omitted, and / or repeated. Additional steps may also be performed. Some steps may be performed simultaneously rather than sequentially.

[0073] Attention is directed to all references and documents related to this application, filed contemporaneously with or prior to this specification, and open to public inspection herewith, and the entire contents of such references and documents are incorporated herein by reference.

[0074] All of the features disclosed in this specification (including any accompanying claims, abstract, and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive.

[0075] Each feature disclosed in this specification (including any accompanying claims, abstract, and drawings), unless expressly stated otherwise, may be replaced by alternative features serving the same, equivalent, or similar purpose. Thus, unless expressly stated otherwise, each disclosed feature is only one example of a common series of equivalent or similar features.

[0076] The invention is not limited to the details of the foregoing embodiments, and extends to any novel one or any novel combination of features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one or any novel combination of steps of any method or process so disclosed.

Claims

1. 1. A computer-implemented method for determining resource utilization in a system having autonomous capabilities, comprising: receiving a plurality of input data from a plurality of respective components of the system; receiving rule set data including a plurality of rules, each of the plurality of rules configured to determine an integrity value of the input data; processing the plurality of input data and the rule set data to generate an integrity value for each of the plurality of input data; and using the integrity value to determine resource utilization of the system (308).

2. Processing the plurality of input data and the rule set data to generate an integrity value for each of the plurality of input data includes: The method of claim 1 , comprising generating a low integrity value for the input data if the input data indicates anomalous behavior of a detected object or system component.

3. Processing the plurality of input data and the rule set data to generate an integrity value for each of the plurality of input data includes:

3. The method of claim 1, comprising generating a high integrity value for the input data if the input data matches one or more other input data.

4. 4. The method of claim 1, wherein the plurality of input data comprises a plurality of track data output by a respective plurality of sensors, wherein each of the plurality of track data comprises information about at least one entity detected by a respective sensor.

5. The method of claim 4 , further comprising using the integrity value to determine utilization of the sensor in future tracks of the detected entity.

6. 6. The method of claim 4 or 5, further comprising obtaining additional sensor data from at least one of the plurality of sensors, the additional sensor data comprising a reliability of track data provided by the sensor, wherein the additional sensor data is used by at least one of the rules of the plurality of rules.

7. 7. The method of claim 4, wherein the integrity value represents a confidence that the detected entity of the track data is a real object, and wherein a rule in the rule set data generates a high integrity value for the track data when it determines that the detected entity of the track data is likely to be a real object.

8. receiving task data relating to a plurality of tasks to be performed by the system; checking the integrity value determined for each input data associated with the task; and generating data indicating whether the component providing the input data should continue to be used as a resource for the task.

9. each of the plurality of tasks having an associated importance value; The method according to claim 8 , wherein the threshold is set lower for a task with lower importance, and the threshold is set higher for a task with higher importance.

10. receiving a plurality of resource usage data, each of the plurality of resource usage data comprising a value representing a current level of usage of a resource of the system; 10. The method of claim 8, further comprising: processing the resource usage data and data integrity values ​​associated with components performing the task to generate a target usage level for the resource used in association with the task.

11. 11. The method of claim 10, wherein the task comprises tracking an object using resources comprising a sensor, and wherein the processing comprises reducing a target usage level of the sensor if the data integrity value of the sensor is low.

12. A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 11.

13. A device comprising a processor configured to perform the method of any one of claims 1 to 11.

14. A system having autonomous capabilities and including a processor configured to perform the method of any one of claims 1 to 11.

15. A vehicle comprising the system of claim 14.

Images