Decisions on resource utilization in autonomous systems

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 the use of resources in a system having autonomous capability.

Background Art

[0002] Various types of systems having autonomous capability have been developed. Examples include aerial, ground, and / or water-based / marine vehicle systems that can automatically react to stimuli detected by sensors to control some of the on-board components such as speed / direction controllers. For some existing aircraft having autonomous capability, a pilot operates sensors of the aircraft via a control device in the cockpit. An operator can use their own experience to determine the most appropriate sensor to use, and also determine which sensor mode to use for a current task. Sensors and sensor modes are controlled discretely and independently, that is, the use of one sensor does not affect the use of another sensor.

[0003] Modern and future sensors are more powerful and capable of further "seeing", thereby generating more data and consequently increasing the amount of information (clutter) presented to an operator. The growing capability of modern sensors, coupled with the growth of autonomy, can bring significant challenges to an operator when determining which sensor, which sensor mode, and which combination of sensor types will produce the most effective image. It is believed that this can even become an impossible task for humans.

[0004] In a military context, it is conceivable that in the future, adversaries may be able to spoof to an almost imperceptible degree, making it virtually impossible for current sensor systems to distinguish spoofs from real entities. Understanding how autonomous systems respond to stimuli can provide a hostile advantage to malicious actors. For example, an adversary could deploy a spoof entity into a system, for instance, by performing multiple radar or infrared detections, giving the impression of multiple threats instead of a single aircraft. There have been cases where autonomous drones have been forced to land due to the hostile exploitation of the relationship between sensor input and the resulting system behavior. All entities detected by a vehicle, even if spoofs, require sensor resources, such as sensor tracking effort. Multiple entities require even more effort to track. If multiple entities are spoofs, for example, deployed by a malicious actor, it is crucial to avoid wasting sensor resources.

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

[0006] Humans possess intuitive senses that develop from learned experience. Often, intuition and consideration of evidence for the outcome coincide, but often they do not. Individuals may be presented with objective evidence, including sensor outputs, that initially points to what appears to be an obvious conclusion, yet humans often still rely on intuition, which may suggest a contrary conclusion that later proves correct. This intuition is based on subtle nuances about how the information was presented to the individual. These nuances may relate to how the data was initially generated, where it came from, when it was generated, and its quality.

[0007] While it is difficult to truly describe or simulate instinctive intuition, it often considers facets of incoming data that would not normally be taken into account in order to compile a trustworthy image, rather than simply relying on objective conclusions. If a protection system can rely on innate "intuition" rather than just raw data (which can be spoofed), then task-based cockpit systems, for example, would not expend considerable effort tracking spoofing entities—entities that are very often known to be wrong by human pilots—while the system continues to interleave its tracking / lock / follow activities. Currently, no automated system exists to address this problem. [Overview of the project]

[0008] Embodiments of the present invention are intended to address at least some of the technical problems described above.

[0009] The embodiment can use a schema / rule set to determine the level of investment required for system resources based on the threat level and potential threat level of objects detected by sensors. The embodiment can provide protection for products that consume data from multiple different distributed sources (e.g., different platforms and different sensors, as well as geographically distributed) to support decision-making based on the reliability of that data.

[0010] The embodiment can perform cross-checking activities to determine by cross-checking whether the received data is true, i.e., not spurious. The embodiment can also determine the importance level based on the activity currently being performed, which affects the level of effort invested in the amount of cross-checking activity, with more effort invested at higher importance levels. By considering a combination of conditions regarding the data source and quality, the embodiment can provide protection against excessive resource consumption due to sensor spoofing.

[0011] Embodiments may also protect against system failures by evaluating the integrity of data generated by the system, rather than by identifying failures, and aiming to ensure that resource usage decisions made using that data have the necessary data integrity (i.e., the data can be trusted).

[0012] According to one aspect of the present invention, a computer implementation method is provided for determining the utilization of resources in a system having autonomous capabilities, and the method is: Receiving multiple input data from various components of the system, It receives rule set data containing multiple rules, and each of the multiple rules is configured to determine the integrity value of the input data. Processing multiple input data and rule set data to generate an integrity value for each of the multiple input data, Outputting an integrity value, It includes using an integrity value to determine the use of system resources.

[0013] Multiple input data can comprise multiple track data output by each of the multiple sensors, where each of the multiple track data comprises information about at least one entity detected by the respective sensor.

[0014] This method may, for example, include using an integrity value to determine the use of the sensor in future tracks of the detected entity.

[0015] The track data may include location information of the detected entity (e.g., latitude, longitude, and / or altitude), 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] This method may further include obtaining additional sensor data from at least one of several sensors. The additional sensor data may be used by at least one of several rules. The additional sensor data may include information about the reliability of the track data provided by the sensor and / or the type of sensor.

[0017] The integrity value may represent the confidence that the detected entities in the track data are real objects, and a rule in the rule set data may assign a high integrity value to the track data when it determines that the detected entities in the track data are likely to be real objects.

[0018] Multiple rules can include the following: If the input data indicates abnormal behavior of the detected object or system component, a low integrity value will be generated for the input data, and / or Generate a high integrity value for the input data if the input data matches one or more other input data.

[0019] The rules in the rule set data for track data may be selected from a set that includes the following: If an entity detected in track data is also detected in at least one other track data among multiple track data sets, a high integrity value is determined. A low integrity value is determined when there is a significant difference (for example, greater than a threshold of 250m) in the detected location of an entity between the track data and at least one other track data among multiple track data. When the type of detected entity in the track data at a location detected by the sensor is abnormal, a low integrity value is assigned (for example, a low integrity value is assigned to track data indicating a passenger aircraft flying at an abnormally low level, while a high integrity value is assigned to one flying at a normal / expected altitude over a specific area), If the type of entity detected in the track data is not operating within the known performance limits of a certain type of vehicle, a low integrity value will be assigned (for example, track data indicating a helicopter flying at an unexpectedly high speed will be given a low integrity value, while data indicating it is flying within its normal expected speed range will be given a high integrity value), If the detected entities in the track data originate from a hostile country, a low integrity value will be determined, and / or Determining a low integrity value when the behavior of detected entities in track data is abnormal (for example, a civilian aircraft suddenly turns towards a vehicle and increases its speed).

[0020] The method may involve fusing multiple track data to generate a list of merged tracks.

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

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

[0023] Each of the plurality of tasks may have an associated importance value, and the threshold for a task may vary according to the importance value of the task; for example, a lower threshold may be set for a task having a low importance value, while a higher threshold may be set for a task having a high importance value. The threshold and / or the importance value may be defined in a schema / rule set by a system operator.

[0024] The method may further comprise 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. 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 usage level of a resource of the system, processing the resource usage data and task data to generate a target usage level for a resource to be 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, along with multiple resource usage data, to determine a future usage level for at least one of the sensors to be used in connection with the task. The task may comprise tracking an object using a resource equipped with a sensor, and the process may comprise reducing the target usage level of the sensor if the sensor's data integrity value is low.

[0027] According to another aspect of the present invention, a (computing) device is provided comprising a processor configured to perform substantially the methods described herein.

[0028] According to yet another aspect of the present invention, a system having autonomous capability is provided, comprising a processor configured to perform a method substantially described herein. The system may include or be associated with a vehicle.

[0029] In another embodiment, a computer program product is provided which, when executed by a computer, comprises instructions causing the computer to perform a method substantially as described herein. [Brief explanation of the drawing]

[0030] For a better understanding of the present invention and to illustrate how embodiments of the present invention are put into practice, references to the accompanying figures are made as examples. [Figure 1] Figure 1 is a block diagram of an exemplary vehicle system including a computing device configured to perform an embodiment. [Figure 2] Figure 2 is a schematic block diagram showing the configuration of a computing device, including the integrity generator software component, the proportionality checker component, and the resource monitor component. [Figure 3]Figure 3 is a flowchart showing exemplary steps performed by the integrity generator component. [Figure 4] Figure 4 is a flowchart illustrating exemplary steps performed by the proportional checker component. [Figure 5] Figure 5 is a flowchart illustrating exemplary steps performed by the resource monitor component. [Modes for carrying out the invention]

[0031] Figure 1 is a block diagram of an exemplary system 100. The detailed example given below is based on a vehicle system, but it will be understood that embodiments may be used in connection with other types of systems having autonomous capabilities. "Systems 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 water / sea vehicle, such as an aircraft, that has 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 that may be mounted on the vehicle or located remotely. Common components of a vehicle, such as the body, engine, communication system, etc., are not shown for the sake of clarity but are well known to those skilled in the art.

[0032] The vehicle system 100 includes a computing device 102. The computing device may be substantially conventional and may include, or be associated with, at least one processor 104 and internal memory 106, such as random access memory. The internal memory may 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, for example, via any suitable wired / wireless interface and / or communication network. The computing device may include, or be associated with, further conventional features such as non-volatile memory devices and user interfaces, which do not need to be described in detail herein. The computing device may be mounted in or on the vehicle, or may be remote from the vehicle, communicating via a network.

[0033] The computing device 102 communicates with a plurality of sensors 110A, 110B via interface 108. The sensors may be mounted inside or on the vehicle, or, in some cases, remotely from the vehicle. Examples of sensors include radar, LiDAR, accelerometer, GPS, etc. For the sake of clarity, 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 or different types, may be used with the embodiment.

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

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

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

[0037] The embodiment can fulfill two main roles. The first role is to help conserve and optimize the use of system resources by ensuring that resources such as sensors are used proportionally based on certain criteria. The second role is to ensure that the information underlying vehicle behavior or operational decisions (e.g., generated by a sensor fusion system) is not spurious. By using a rule set or schema, the embodiment can declare the level of effort that should be invested in verifying whether the 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 that the correct level of resources is invested. If an entity is detected but shows little to no threat, the embodiment can determine that little / no effort is required to ensure that a proportional level of resources is invested in tracking it.

[0038] Embodiments can use schemas / rule sets to ensure that multiple data sources, e.g., different sensor types, sensors from other aircraft (collaborators), along with optionally open-source data (such as location), or any other attributes, are integrated, creating assurances and suggesting a level of "truth"—in this case, truth is represented by a score. Embodiments can generate values / scores based on the number and types of sensors, as well as other available data, to generate requirements for sensor resource investment. The more sensors and types that can detect entities, the higher the score (however, this is just an example, and it will be understood that in alternative embodiments, lower values ​​or non-numerical evaluation systems may be used). This, combined with how threatening an entity may be, can generate sensor demand, and many real entities and threat levels result in proportional sensor demand. Multiple spurious entities are clearly threatening but will result in lower demand for sensors.

[0039] An 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 / evaluation for each data received as input by the integrity generator component, for example, data generated by the system's sensors. The exemplary embodiment further includes a proportional checker component 204 that can determine, based on the perceived threat and / or integrity evaluation of the input data, how much effort should be spent in the future with respect to that input data, for example, with respect to tracking entities detected by one or more of the sensors. The component can use a schema / predefined rule set to attempt to ensure, for example, that sensor resources are not wasted on tracking spoof entities. The exemplary embodiment further includes a resource monitor component 206 that may be partially driven by a schema, such as a sensor schema. In some embodiments, the component may output an instruction that the current resource usage should be changed. The data received as input by the various components may be stored in the memory 106 of the computing device 102, or may be received from a remote source.

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

[0041] In step 302, the integrity generator component 202 receives a data integrity schema containing a set of rules for determining the integrity rating / value of the input data. An example of these rules is shown below. The schema may be created by one or more experts; for example, a radar sensor data expert may create rules used to determine the integrity of track data generated by the radar-based sensors of 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 the operator to be used as the schema data input in step 302.

[0042] In step 304, the integrity generator component 202 receives input data from the components of system 100. The input data can take various forms and can be provided by any means of converting information about the system or external environment into system data. Examples include multiple track data about entities detected by each of several sensors, e.g., sensors 110A, 110B, 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 list of fused tracks.

[0043] The embodiments can be applied to any system that uses data, in which case the rules can 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. Complex systems can operate using thousands of different types of data, and it will be understood that a non-exhaustive list of examples of input data that can be processed by the embodiments includes: air data (velocity, pressure, temperature, etc.), hydraulic system data (pressure, temperature, contents, pump status), fuel system data (contents, temperature, pressure, flow rate), inertial system data (rotational speed, orientation, acceleration, velocity, position), weapon system data (store quantity, store status, target information), GPS data (position, velocity, altitude, time), navigation system data, non-track-related radar data, transponder data, cockpit interface data (button presses, stick / throttle movements, switch positions), human physiological data (heart rate, skin temperature, blood pressure, pupil size, gaze), and data preloaded 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 that data is. This may involve applying one or more rules from the schema to each input data to generate a score / numerical value that can be used as its integrity value / assessment.

[0045] The following are examples of rules that may be applied to determine the integrity of each input track data: • It's normal for a truck to be in that position (for example, why is the plane flying at such a low altitude?). - If so, a lower integrity value is determined. • Is the truck within its known performance limits? (For example, why is the helicopter flying at 350 knots?) - If so, a high integrity value is determined. • Did the aircraft depart from an unexpected location (for example, why did a friendly aircraft depart from an enemy country)? If so, determine a low integrity value. • The truck's behavior is abnormal (for example, why did the civilian flight suddenly change direction towards us and increase its speed?) - If so, a lower integrity value is determined. • Is the track not visible to other sensors (for example, is it close enough to be visible by FLIR, but FLIR isn't picking it up, or should an ally be able to see it with their radar, but can't)? - If so, a lower integrity value is determined. Is there a significant difference in the track position between sensors? - If so, a lower integrity value is determined.

[0046] Other examples of rules / criteria that may be used by the embodiment to evaluate input track data include: • Is the detection abnormal (for example, were four aircraft detected in an area where only two ships normally operate)? - If so, a lower integrity value is determined. Can multiple sensors detect these entities? - If so, a high integrity value is determined. Can multiple collaborative aircraft detect these entities using different sensors (to ensure that not all radars are spoofed)? - If so, a high integrity value is determined. Can we identify the individual signatures of the detected entities? - If so, a high integrity value is determined.

[0047] The rules above are merely examples, and it should be understood that more / alternative rules can be provided depending on the data integrity schema being created and the type of data being evaluated.

[0048] The following are examples of rules that may be applied to determine the integrity of input air data: • If the rate of climb of the detected object is greater than the rate of climb of the aircraft, a lower integrity value is determined. • If the detected vehicle acceleration is greater than the known maximum acceleration for that type of vehicle, a lower integrity value is determined. • If the detected vehicle's speed is greater than the known maximum speed for that type of vehicle, a lower integrity value is determined. • If speed and rate of ascent do not match, a lower integrity value is determined. • A lower integrity value is determined if the pressure is higher / lower than possible, or if it changes at a faster rate than possible. • A low integrity value is determined if the pressure changes in the wrong direction (i.e., the pressure decreases and then increases).

[0049] Some of the rules above can be used to identify low-integrity data caused by simple malfunctions such as pitot / static system blockage. Human pilots are more likely to be able to identify signs of pitot / static system blockage, whereas conventional autonomous systems may not.

[0050] The following are examples of rules that can be applied to determine the integrity of input GPS data: • If the detected vehicle altitude does not match the aerial data system, a low integrity value is determined. • A low integrity value is determined if there are jumps in the location data or if the location integrity is poor. • A low integrity value is determined if the time or rate of change of time does not match other time sources. • If the detected location differs from the location given by the INS location or the location derived from the Navy, a lower integrity value will be determined.

[0051] As another example, a failure in the fuel system sensor may result in an overread of the fuel content. This could lead to the pilot or autonomous system committing to a particular route, potentially resulting in fuel depletion and aircraft loss. Embodiments configured with appropriate rules can continuously assess the integrity of fuel system data. Abnormal behavior such as increased fuel content, fuel content exceeding the maximum capacity of the fuel tank, or mismatch in fuel usage rate results in low fuel data integrity. This can alert the pilot, enabling them to make appropriate decisions regarding the task, and / or supply integrity data to the autonomous system, which can then determine that it does not have the fuel data integrity required to make a certain routing decision. An embodiment may not detect such a failure and may not know that less fuel is available than required for the mission, but the embodiment may determine that there is insufficient integrity in the data to enable a resource usage decision (e.g., committing the engines 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 value may be a number within a range (e.g., 0 to 10) to represent a confidence score or similar. Various factors can be combined into an overall integrity score for each input data by summing the values ​​of all applicable rules, for example, using a weighted average in some cases.

[0053] In step 308, the generated integrity evaluation may be output by the integrity generator component 202. The output integrity evaluation may include a numerical value determined for each processed input data, 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 related sensors. The integrity evaluation may be received as input by the proportional checker 204 and / or the resource monitor component 206 and / or any other component that can use the integrity value to determine the future use 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, the embodiment can determine resource utilization in substantially real time based on current data inputs such as sensor detections.

[0054] Figure 4 is a flowchart illustrating exemplary steps performed by the proportionality checker component 204. The proportionality checker component is intended to assess whether the integrity of the data being processed to perform a task is proportional to the scale / size / importance of the task (e.g., required resource usage, risks, consequences, etc.). The importance value may be determined by the system operator.

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

[0056] In step 404, the proportional checker component receives as input data about several tasks that are scheduled to be performed during the current mission assigned to system 100. These tasks can take various forms. For example, one task may identify an entity or area and the actions taken in relation to it, such as tracking a detected foreign aircraft or detecting any entity within an area defined by a set of coordinates. Tasks can range from large-scale mission-level tasks to very small-scale system or subsystem-level tasks. Tasks are hierarchical, with larger tasks consisting of smaller tasks.

[0057] A non-exhaustive list of task examples includes mission-level tasks (tasks involving multiple platforms working together to achieve common objectives such as reconnaissance missions, air superiority missions, jamming missions, redeployment missions, and humanitarian missions), platform-level tasks (tasks involving a single platform, such as following a route, dropping a store, refueling, turning around a track, observing, and lighting), system-level tasks (tasks involving a single system, such as stopping a transmission, tracking a target, and initiating jamming), and subsystem-level tasks (tasks involving a part of a system, such as transferring fuel from one tank to another, turning off a cooling system, changing subsystem modes, and turning on lights). In step 406, the proportional relationship checker component 204 processes the received data. In some embodiments, this processing may involve checking the generated integrity assessment 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 one task but not for another. The required data integrity (e.g., minimum numerical value) for a specific task can be defined by schemas / rules set up by the system operator.

[0058] For example, if a task tracks a particular aircraft, the integrity rating of all track data in which that aircraft is detected (e.g., within a recent time window) can be evaluated. If the integrity ratings of all relevant track data fall below a certain threshold, this suggests that the detected entity is spoofed, and therefore the proportional checker may produce an output indicating an imbalance in the number of sensors assigned to the task. Additionally or alternatively, if only one (or a few of many) track data have high integrity ratings and the others have low ratings, the proportional checker may produce an output indicating an imbalance in the sensors assigned to the task.

[0059] As another example, assigning four aircraft to perform a mission would use a lot of fuel and put the aircraft at potential risk. This is a large-scale task, and the data used to make that decision must have a very high level of integrity. Therefore, a proportional checker may produce an output indicating that the data integrity value is insufficient if the data integrity value falls below a high threshold. Unnecessary fuel dropping can have consequences for a single aircraft, and therefore the data integrity required to make that decision must be proportional. Therefore, a proportional checker may produce an output indicating that the data integrity value is insufficient if the data integrity value falls below a relevant 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 proportional checker may produce an output indicating that the data integrity value is insufficient only if the data integrity value falls below a relatively low threshold.

[0060] In step 408, the proportional checker component 204 may output the data generated in step 406. The data may include information about whether the use of resources used in the task, such as sensors, should be corrected, or an indication that the data integrity value is not high enough for a particular task. In some cases, the output data may correspond to binary yes / no (e.g., either 1 or 0), while in other cases, the output data may include a numerical value within a range (e.g., between 0 and 10) to indicate a confidence score, etc. The data may be received as input by the resource monitor 206 and / or output to component 114 to display a warning to the operator, for example, that sensors are being used unbalanced. The generated data may 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 the desired data integrity set by the operator, etc.

[0061] Figure 5 is a flowchart illustrating exemplary steps performed by the resource monitor component 206. In some embodiments, the resource monitor component acts as a proportional 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 been started), while the proportional checker component 204 may be used to determine whether data integrity is high enough to begin executing a particular task. In other embodiments, steps shown as being performed by the resource monitor component are part of those performed by the proportional checker component (i.e., there is not necessarily a separate resource monitor component).

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

[0063] In step 504, the resource monitor component receives 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] In step 506, the resource monitor component receives data regarding resource usage as input. This data may be received from some of all of sensors 110A, 110B and / or some of all of the other components 112A, 112B associated with the vehicle system 100. Resource usage may be a numerical value representing the current usage relative to the maximum usage / capacity of a particular resource, for example, on a scale of 1 to 10 or as a percentage. The data may include further information such as the identifier and type information of the sensor or component.

[0065] In step 508, the resource monitoring component 206 processes the received data. This may involve analyzing integrity assessments, resource usage data, and task data to generate information about whether the use of resources such as sensors should be changed. For example, if the decision indicates that a real (i.e., not a spoof) entity was detected but its threat level was deemed low, the use of the schema by the resource monitoring component 206 can ensure that the sensor resource is not wasted tracking a potential spoof entity.

[0066] Step 510 allows the data generated in Step 508 to be output. The output data may include information on how resource usage should be changed or continued, such as the target usage level of a resource that should be used in the future in relation to a particular task. For example, the output may include data indicating that a particular sensor should no longer be used, or that its usage level should be reduced, in relation to tracking a particular detected entity that has been determined to be at risk of spoofing. Thus, an embodiment may generate output indicating that the use of a particular resource should be reduced to mitigate the risk of wasting resources on a spoof track. However, if a new task is generated to perform a different action on the same tracked target, the task scale increases, and therefore the data integrity required to undertake the new task may increase. 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 on that target, assigning a task to another sensor to provide information on the target, and / or assigning a task to 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, the interface may display to the operator, based on the received data, information that the use of resources, including sensors, should be modified considering 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 the use of sensors 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 using resources with increased data integrity until the task can be initiated. Thus, embodiments can use integrity-based data to determine future use of resources, such as sensors, for one or more future tracks of detected entities, and in what mode they should be used.

[0068] Some smart sensors may use schemas to define their behavior, for example, which mode is used. A sensor schema is a complex set of rules that can manage sensor behavior based on operating conditions and what the sensor is detecting and reporting. Schemas can be used to create or present behavior. In this context, a schema could be used to manage which sensor type is used in which mode in response to the detection of an entity. For example, if a detected entity is moving at high speed relative to a 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, for example, by comparing the outputs of the proportional checker 204 and the resource monitor 206 for discrepancies and warning the operator if, for example, they are using resources inappropriately.

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

[0071] By allocating resources in proportion to the perceived importance of threats such as detected objects, embodiments can help ensure that system resources are not allocated 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 adversarial manipulation. Embodiments can protect against several system failures and inconsistencies that would not have been previously detected.

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

[0073] Attention is drawn to all documents and papers that have been filed concurrently with or prior to this specification and are made available to the public together with this specification, and all the contents of such documents and papers are incorporated into this specification by reference.

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

[0075] Each feature disclosed herein (including any attached claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose unless expressly stated otherwise. Thus, unless expressly stated otherwise, each disclosed feature is merely one example of a common set of equivalent or similar features.

[0076] The present invention is not limited to the details of the embodiments described above. The present invention extends to any novel one or any novel combination of features disclosed herein (including any appended claims, abstract, and drawings), or to any novel one or any novel combination of any step of any method or process disclosed herein. The following is a direct reproduction of the claims as originally filed. [C1] A computer implementation method for determining resource utilization in a system with autonomous capabilities, The system receives multiple input data from each of its multiple components, The system receives rule set data containing multiple rules, and each of the multiple rules is configured to determine the integrity value of the input data. Processing the plurality of input data and the rule set data so as to generate an integrity value for each of the plurality of input data, A method comprising (308) using the integrity value to determine the use of the resources of the said system. [C2] Processing the plurality of input data and the rule set data in order to generate an integrity value for each of the plurality of input data is, The method of C1, further comprising generating a low integrity value for the input data if the input data indicates abnormal behavior of a detected object or system component. [C3] Processing the plurality of input data and the rule set data in order to generate an integrity value for each of the plurality of input data is, The method according to C1 or 2, further comprising generating a high integrity value for the input data if the input data matches one or more other input data. [C4] The method according to any one of C1 to C3, wherein the plurality of input data comprises a plurality of track data output by each of the plurality of sensors, where each of the plurality of track data comprises information relating to at least one entity detected by each of the sensors. [C5] The method according to C4, further comprising using the integrity value to determine the use of the sensor in a future track of the detected entity. [C6] The method of C4 or 5, further comprising obtaining additional sensor data from at least one of the plurality of sensors, wherein the additional sensor data comprises the 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. [C7] The method according to any one of C4 to 6, wherein the integrity value represents the confidence that the detected entity in the track data is a real object, and a rule in the rule set data generates a high integrity value for the track data when it determines that the detected entity in the track data is likely to be a real object. [C8] The system receives task data relating to multiple tasks performed by the aforementioned system, Check the integrity value determined for each input data associated with the task, The method according to any one of C1 to 7, further comprising generating data indicating whether the component providing the input data should continue to be used as a resource for that task. [C9] Each of the aforementioned tasks has an associated importance value, The method according to C8, wherein the threshold is set lower for tasks of lower importance and higher for tasks of higher importance. [C10] Receiving multiple resource usage data, and each of the multiple resource usage data having a value representing the current usage level of the system's resources, The method according to C8 or 9, further comprising processing the resource usage data and data integrity values ​​related to the component performing the task in order to generate a target usage level of the resources used in connection with the task. [C11] The method according to C10, wherein the task comprises tracking an object using a resource equipped with a sensor, and the processing comprises reducing the target usage level of the sensor if the data integrity value of the sensor is low. [C12] A computer program product comprising instructions, wherein, when the program is executed by a computer, the instructions cause the computer to perform the method described in any one of C1 to C11. [C13] A device comprising a processor configured to perform the method described in any one of items C1 to C11. [C14] A system comprising a processor having autonomous capabilities and configured to perform the method described in any one of the items C1 to C11. [C15] A vehicle equipped with the system described in C14.

Claims

1. A computer implementation method for determining resource utilization in a system with autonomous capabilities, The system receives multiple input data from each of its multiple components, The system receives rule set data containing multiple rules, and each of the multiple rules is configured to determine the integrity value of the input data. Processing the plurality of input data and the rule set data so as to generate an integrity value for each of the plurality of input data, The integrity value is used to determine the use of the resources of the system (308), The system receives task data relating to multiple tasks performed by the aforementioned system, Check the integrity value determined for each input data associated with the task, The component that provides the input data generates data indicating whether it should continue to be used as a resource for that task, A method that includes [a certain feature].

2. Processing the plurality of input data and the rule set data in order to generate an integrity value for each of the plurality of input data is, The method according to claim 1, further comprising generating a low integrity value for the input data if the input data indicates abnormal behavior of a detected object or system component.

3. Processing the plurality of input data and the rule set data in order to generate an integrity value for each of the plurality of input data is, The method according to claim 1, further comprising generating a high integrity value for the input data if the input data matches one or more other input data.

4. The method according to claim 1, wherein the plurality of input data comprises a plurality of track data output by each of the plurality of sensors, and each of the plurality of track data comprises information relating to at least one entity detected by each of the sensors.

5. The method according to claim 4, further comprising using the integrity value to determine the use of the sensor in a future track of the detected entity.

6. The method of claim 4, further comprising obtaining additional sensor data from at least one of the plurality of sensors, wherein the additional sensor data comprises the 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. The method according to claim 4, wherein the integrity value represents the confidence that the detected entity in the track data is a real object, and when a rule in the rule set data determines that the detected entity in the track data is likely to be a real object, it generates a high integrity value for the track data.

8. Each of the aforementioned tasks has an associated importance value, The method according to claim 1, wherein the threshold is set lower for tasks with a lower importance value and higher for tasks with a higher importance value.

9. Receiving multiple resource usage data, and each of the multiple resource usage data includes a value representing the current usage level of the system's resources. The method according to claim 1, further comprising processing the resource usage data and data integrity values ​​related to the component that performs the task in order to generate a target usage level of the resources used in connection with the task.

10. The method according to claim 9, wherein the task comprises tracking an object using a resource equipped with a sensor, and the processing comprises reducing the target usage level of the sensor if the data integrity value of the sensor is low.

11. A computer program comprising instructions, wherein, when the program is executed by a computer, the instructions cause the computer to perform the method according to claim 1.

12. A device comprising a processor configured to perform the method described in claim 1.

13. A system comprising a processor having autonomous capabilities and configured to perform the method described in claim 1.

14. A vehicle comprising the system described in claim 13.

Images