Methods and systems for generating a pattern of life history

Abstract

Combining data from a first source and second source of measurements of at least one parameter associated with a system or entity at different points in time and identifying at least one gap in the da

Description

FIELD Embodiments described herein relate to methods and systems for generating a Pattern of Life History. BACKGROUND Pattern of life (PoL) analysis is widely used to monitor and predict the behaviour of different entities over time. An entity’s PoL can be understood to describe the repeatable behaviours of that entity, which recur at normally-distributed time intervals, under a particular set of conditions. The set of conditions may include, for example, the time of day, day of the week, time of year, location, weather, age, type of entity, etc. By way of example, a PoL for a car may be that every morning at 8:00am the car is driven from home to school, then to a work place at 9:00am; however, if Monday is a public holiday or if the driver is on holiday, the car need not go to school and may or may not be used to travel from home to the work place. Generating a PoL for an entity will typically involve the surveillance of the entity over a period of time to build up a PoL history for the entity. The PoL history comprises a set of data from which repeatable behaviours can be identified and used to define the PoL. The PoL history may subsequently be processed to obtain Pattern of Life Intelligence (PoL-INT), which can in turn be used to predict future activity of the entity, as well as indicating whether that entity either is, or has been, engaged in suspicious or anomalous activity. The PoL-INT may be used to determine and execute a particular course of action in relation to the entity. To date, production of PoL histories has not been possible without large, complete, uninterrupted datasets covering a region of space. Complete coverage of an observation area requires extensive sensor coverage, however, which is often impractical. Any gaps in the datasets will be left blank in the PoL history, compromising the PoL-INT that is derived from those histories. SUMMARY According to the present invention, there is provided a method of generating a pattern of life PoL history, the method comprising: receiving, from a first source, a first data set comprising measurements of at least one parameter associated with a system or entity at different points in time; identifying at least one gap in the data set comprising absence of a measurement of the parameter at a particular point in time; receiving, from a second source, a second data set comprising at least one measurement of the at least one parameter at the particular point in time; generating a combined data set by combining the first data set and the second data set, the combined data set including the measurements of the at least one parameter at each different point in time and the particular point in time; and generating a pattern of life history for the system or entity using the combined data set, the pattern of life history providing a statistical representation of the historical behaviour of the entity. The method may comprise receiving, from a plurality of sources, respective data sets comprising measurements of parameters associated with one or more systems or entities. Generating the combined data set may comprise identifying the second data set as comprising the at least one measurement of the at least one parameter at the particular point in time, and responsive to said identifying, selecting the second data set from among the respective data sets to combine with the first data set. The method may further comprise: identifying at least one further gap in the combined data set comprising absence of a measurement of the parameter at another point in time; and generating a measurement value for the parameter at the other point in time by interpolating between measurements of the parameter made before and after said other point in time. The first source and second source may comprise respective sensors mounted on one or more platforms. The one or more platforms may be vehicles and / or vessels. The sensors may be employed for a primary purpose on board the platforms, the primary purpose being distinct from that of generating the pattern of life history. The first and second data sets may comprise measurements captured by the one or more sensors in pursuit of the primary purpose. The at least one parameter may comprise one or more of: a kinematic parameter of an entity; a chemical parameter; and a network communications parameter. The method may comprise issuing an alert to a user based on the pattern of life history. The alert may be issued in response to identifying an anomalous behaviour of the entity or system based on the pattern of life history. The method may comprise outputting on a user interface information obtained by processing the pattern of life history. The method may comprise: generating instructions for causing an entity to perform one or more actions based on the pattern of life history. The method may comprise activating an actuator to act on the entity in response to a behaviour in the pattern of life history. Causing the entity to perform one or more actions based on the pattern of life history may comprise controlling the entity to operate according to historical behaviour defined in the pattern of life history. According to a second aspect of the present invention, there is provided a transitory or non-transitory computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to perform the method of the first aspect of the present invention. According to a third aspect of the present invention, there is provided a computer system comprising: one or more processors; and a transitory or non-transitory computer-readable medium according to the second aspect of the present invention. Embodiments as described herein can automatically create PoL histories from a set of disparate datasets and interpolate across spatial or temporal gaps in the data. The gaps can be in any form of context e.g. time, location, etc. The interpolation produces behaviours and related behaviour details for regions of time and / or space not covered by observation data. By producing a PoL history from a set of disparate datasets gathered opportunistically, embodiments obviate the need for constant observation over a region of space over a lengthy period of time. Embodiments can provide a PoL history for users who have little or no knowledge of the behaviour I activity in an area. BRIEF DESCRIPTION OF DRAWINGS Embodiments of the invention will now be described by way of example with reference to the accompanying drawings in which: Figure 1 shows a flowchart for generating and utilising Pattern of Life Intelligence (PoL-INT) according to an embodiment; Figure 2 shows the path taken by a first ship as it traverses a region of space that contains a plurality of entities; Figure 3 shows the path of a second ship traversing the same region of space as in Figure 2; Figure 4 shows a table summarising which entities are within sight of the first and second ships at different times during their passage through the region of space; Figure 5 shows an example of a computer system according to an embodiment, the computer system including a PoL module; and Figure 6 shows the components of the PoL module of Figure 5 in more detail. DETAILED DESCRIPTION Figure 1 shows a flowchart for generating and utilising Pattern of Life Intelligence (PoL-INT) according to an embodiment. The process begins with observing 100 one or more entities or systems over time, so as to build up data from which behaviour patterns can be extracted. An entity may be a tangible or intangible thing (living or non-living). For example, an entity may be a person or group of people, or a physical object or group of objects. Such object(s) might include vessels or vehicles (either land-based or airborne). A system, meanwhile, may comprise a group of entities or other components that interact with one another to perform a function. Examples of systems include telecommunications and computer networks, as well as chemical processing plant or apparatuses. Different parts or components of the system may be observed over time to develop a picture of those parts’ behaviour. The behaviour of a system or entity can be understood to comprise a sequence of dynamic parameters associated with that system or entity, which can be observed or inferred from observations. A set of observations about an entity will become a behaviour when sufficient observations are seen to create a sequence corresponding to that particular behaviour. Dynamic parameters are ones that change over time. Dynamic parameters may include kinematic parameters, e.g. position, velocity, and acceleration, for example. Through observing kinematic parameters, it is possible to identify different behaviours, such as a vehicle or vessel travelling at a constant speed, its accelerating / decelerating, or manoeuvring to turn left or right etc. Measurements of other parameters such as temperature, meanwhile may reveal behaviours in the form of the system or entity’s warming or cooling. The dynamic parameters may also include other types of parameter, such as chemical parameters e.g. pH, viscosity etc., or computational / network parameters such as the amount of data traffic being sent across a network connection at any one point in time. Simple behaviours may be combined and processed to identify more complex behaviours. The recorded observations 100 can be used to establish sets of behavioural patterns 103a, 103b ..., 103n, which can in turn be processed to generate a history 105a, 105b ..., 105n. To determine an entity or system’s behaviour, a minimum of two time separated items of data or events are required. A single event can be considered to be a state of the entity or system at a particular time point, and may be captured in an instantaneous sensor reading. As the number of observations of the system or entity increases, the confidence in the resultant behaviour increases also. For each instance of an observed behaviour, the history will record: - Time and date at which the behaviour occurred. - Length of time over which the behaviour occurred. - Location of the behaviour (this may be a single point in space or an area of space). In some examples, the “location” may not represent an actual physical location, but rather a “virtual” location, such as a location in cyberspace. - An entity or entities that exhibited that instance of the behaviour. - A name of the behaviour. - The set of conditions at the time of the behaviour (e.g. weather conditions). Different observations of the same entity or system may yield differences in behaviour. For example, observations made at different times, from different locations, using different sensors may reveal different types of behaviour. These behaviours will in turn yield their own respective histories. Each one of these histories can be considered to be a partial history for the respective sub-region of time and space in which the observations were made. The partial histories for the entity or system can be merged 107 into a single PoL history 109, using the process described below. In a first step 111, a model is formed as to which regions of time and space are covered by the partial histories and where there are gaps in coverage (i.e. regions of time and space that are not covered). Where the partial histories overlap, behaviour extraction may be re-applied to the combined set of observations. There may be additional information from the combined set of observations that produces more accurate behaviours and history. Any gaps in coverage may be determined using metadata 113 from the observations used to create the PoL history. Methods such as heatmaps with heatmap temperature representing density of observations can be used for human visualisation of observation coverage 115. For machine readable representations, statistical distributions can be created from the observation density, and these can be sectioned into grids, with grid elements then analysed using techniques such as kurtosis and skewness to provide indications of data regions in which the observation coverage is not uniform. Further analysis of such regions can then be performed to identify exactly where gaps in data exist. Alternately, a simple numerical threshold across the grid elements can be applied, with the threshold set to indicate which areas have no or low coverage. It is important that any of the analysis techniques described consider the dimensionality of the observation data, so analysis is required in each of the metadata dimensions e.g. location, time, etc. Where gaps in coverage are identified, embodiments may interpolate 117 behaviours across those gaps. Interpolation of behaviours across areas and time can be performed used behaviour models and the observation data. It can also be supplemented with external knowledge, e.g. timetables or weather, or by using knowledge from PoL histories from similar areas or entity type. Models 119 of behaviour can be represented by a range of techniques, which can then be used to interpolate the behaviour across gaps in observations; these techniques include, for example, the use of Kalman filters, Extended Kalman filters, function approximators such as Multi-Layer Perceptrons or Radial Basis Functions, ARMAX models, and kinematic equations. Such models are forwards models which calculate a future state or observation based on a current or past state or observation. Backwards models can also be created and used to calculate a past state, based on a later state or observation. The same techniques used for forwards models apply equally to backwards models. If both forwards and backwards models are used, the results can be combined to give confidence values around a calculated observation. Machine learning can be used to generate both backwards and forwards models from observations. Alternately, models can be provided a priori if known. The interpolated values can be fed back 121 into the history merging process 107; in this way, the construction of the PoL history can be seen to be an iterative process, with the PoL being continually updated to take into account newly captured observations, as well as additions made by interpolating based on the captured data. The above principals can be further understood with reference to Figures 2 to 4. Figures 2 and 3 depict a scenario in which ships X and Y, respectively, travel through a region 201. Located within the region are entities A - F. Each ship X and Y includes one or more sensors that can detect dynamic parameters of entities within the ship’s field of view. For instance, the sensors may include cameras, global positioning transceiver, a radar transceiver, a lidar transceiver, a sonar transceiver, etc. As the ship X passes through the region, the sensors may capture information about the entities A - F. The information may include dynamic parameters of the entities A - F. For example, the information may pertain to the position of each entity in x,y,z coordinates, whether or not the entities are partially or wholly submerged, any changes in appearance that could indicate a particular activity on-board those entities etc. In some embodiments, the captured information may be considered “opportunistic data”; that is, the sensors may have been installed on the ships X and Y with a different goal in mind to observing the entities A - F, but may nevertheless capture data regarding those entities as the ship passes through the region. As a result, the ships X and Y can exploit data collected for other purposes, rather than requiring specific sensor deployment to collect the required data. In addition to the entities A - F, the region 201 also includes an obstacle 203. The obstacle may take the form of a landmass, such as a small island, or a man-made platform or other mass that blocks the line of sight between the ships X, Y and the entities A - F as the ships pass through the region. A ship will be unable to capture information about a particular entity when the obstacle 203 lies directly between that entity and the ship. Figure 2 shows the path 205 of ship X as it traverses the region. Referring to the ship’s position at time T1, the ship X has a clear line of sight of entities A, B, E and F. The ship’s sensor(s) cannot detect the entities C and D, however, as they lie behind the obstacle 205. At time T2, the ship has moved to a new position in the region 201. Here, the ship’s sensor(s) can still detect the entities A, B, E and F, whilst it still has no clear line of sight to entities C and D. At time T3, the ship X has now moved further along its path and now has a clear line of sight to each one of the entities A, C, D, E and F. However, the entity B is no longer visible to the ship’s sensor(s) as the obstacle 203 lies directly in the path between the entity B and the ship X. At time T4, the ship X has moved to a position in which the entities A and B are both obscured by the obstacle 203; the ship can, however, still detect the entities C, D, E and F, for which the ship X has a clear line of sight. Accordingly, as the ship X moves across the region 201, it is possible to detect and log information concerning the behaviour of each entity A - F at different points in time. However, as a result of the obstacle 203, the log for some of those entities will contain gaps, corresponding to times when the entity is question was blocked from the view of the ship’s sensors by the obstacle 203. Turning to Figure 3, this shows the path of ship Y moving through the same region 201 along a different path 301 (it will be understood that the ship Y and X traverse the region 201 at the same time as one another; however, for clarity only the path of ship Y is shown in Figure 3). As in the case of the ship X, the ship Y has one or more sensors that can detect the activities of the entities A - F. Owing to the difference in trajectory of the ship Y compared to the ship X, the ship Y is able to detect different ones of the entities at the four time points T1 to T4. Beginning at time T1, the ship Y can see each one of entities A, B, C, D and F; however, the entity E is blocked from view by the obstacle 203. At time T2, the entities C, D and E are all blocked from view by the obstacle 203; entities A, B and F meanwhile are all within sight of the sensor(s) onboard the ship Y. At time T3, entities C, D and E remain obscured by the obstacle 203, and the ship Y still has a clear line of sight to entities A, B and F. At time T4, the ship Y can still no longer see the entities C and D, but has a clear line of sight to each one of the other entities A, B, E and F. The observations of the entities A - F made by the ships X, Y as they traverse the region 201 can yield respective histories for the entities in the region. The histories generated by the ships for each entity will not be complete, but will feature gaps at those points where the entities are blocked from sensor view / detection by the obstacle 203. The gaps in the histories generated by one ship can, however, be filled based on the observations made by the other ship. This can be seen with reference to Figure 4, which shows a table summarising which entities are within sight of the two ships X and Y at the different times points T1 to T4. Referring to that table, it can be seen that for each one of time points T1, T3 and T4, the entities that are obscured from view of ship X are visible to ship Y and vice versa. For example at time T1, ship X does not have visibility of entities C and D, whilst ship Y has visibility of the entities C and D but does not have a clear line of sight of entity E. Thus, whereas the individual histories generated by those ships will both be incomplete, by combining the observations made by the ships, it is possible to obtain a more comprehensive history for each individual entity across that time period. It will be appreciated that even where the histories obtained by the two ships are combined, there may still be regions of time or space where there is a gap in coverage. For example, referring to time point T2 in Figure 4, it can be seen that for both ships X and Y, the same two entities C and D are obscured from view at that point in time. Thus, between time points T1 and T3, there is a gap in coverage of entities C and D that is neither filled by the observations made by ship X nor the observations made by ship Y. To address this, interpolation may be used to estimate the value of dynamic parameters associated with the entities C and D at the time point T2. Interpolation can be considered to be related to prediction, but in this case, a first state (as defined by the observations of entities C and D made at time point T1) and a state at a later point in time (as defined by the observations of entities C and D made at time point T3) are known. Together, these states can be used to refine a missing near future state (i.e. state of entities C and D at time point T2). As an example, the context of the situation e.g. time of day, weather conditions etc. may be taken into account to predict accurate interpolations and so estimate the values of the dynamic parameters for entities C and D at time point T2. Moreover, observations may be captured by ships passing through the region at different times from one another. For example, a third ship Z (not shown in the Figures) may traverse the region 201 during later time points T5 to T8 and capture further observations of the entities A through F. These observations may be used to supplement the time-sequence of observations obtained from the ships X and Y during the period T1 to T4. The above principals are also applicable to other scenarios involving different types of entities, or system components. As an example, in the case of a computer network, network probes may be used to monitor a volume of network traffic and define a number of IP packets and / or a type of IP packet detected at a location on the network at a particular point in time. In another example, a manufacturing plant or chemical plant may include sensors for monitoring variables such as temperature, pressure, chemical concentration, acidity, humidity etc. Each one of these variables comprises a dynamic parameter that can be measured / monitored at different points in time and used to identify behaviours of a particular entity or system. Where gaps appear in the data, these gaps can be filled by interpolating from the existing data. Taking the example of the computer network, not all junctions in the computer network may have network probes, hence it may not be possible to measure the IP packet traffic in all locations. However, the traffic passing through junctions without probes may still be estimated by using knowledge of the traffic at the closest nodes that have probes. Periodically, a temporary probe may be used to monitor particular junctions for a different reason, but still providing opportunistic data from which a PoL can be built up for that particular part of the network. In the case of a chemical plant, it may be the case that not all vats and pipes have sensors; however, by using models of chemical processes and the connectivity of the vats and pipes in the chemical plant, estimates can be made for the parameter values present in areas which are not constantly being monitored. Returning to Figure 1, as well as continuing to update and refine the PoL history, the method includes the output 123 of pattern of life intelligence (PoL-INT). Pol-INT is the set of information that results from processing the PoL history, and which may be used to predict how behaviour will potentially evolve in the future, based on knowledge of how behaviours have evolved in the past. The output is not always unique as there may be several ways in which an entity’s behaviour can evolve. The PoL-INT can be used for a number of applications. As an example, the PoL-INT can be used for anomaly detection, in which currently observed or predicted behaviours are compared with PoL history behaviours, which occurred under similar conditions. Anomaly assessment can be performed using algorithms to determine if the behaviour requires further attention from a user. If so, an alert can be sent to the user or the system using the PoL-INT. Intent and causation analysis can also be performed to specify reasons as to why a behaviour or anomaly is occurring. Reasons are either internal to the entity (intent) or external to the entity (causation). The results of such analysis can be used in determining which activity or course of action to perform, and then perform it. PoL-INT can be applied at any level of abstraction, from the world level, down to the component level. As an example, PoL-INT can be produced for all the interactions experienced by a Connected Autonomous Vehicle (CAV), for all the activities performed by a CAV and for all the operations I actions performed by the systems and sub-systems constituting the CAV. PoL profiles for a CAV can be produced, from which a model of the CAV’s normal behaviour can be extracted. Profiles from a fleet of CAVs operating in a particular area can then be aggregated to produce a PoL profile for that region, something which is useful for journey management and planning. Detection of cyber threats to a CAV can be achieved through detection of anomalous activities (i.e. deviations from normal behaviour), detections of activities of interest (with such activities specified a priori from cyber intelligence), and analysis to understand which of the detected results constitute a threat to the CAV. Such detection and analysis can be utilise any of the different abstraction levels of PoL-INT. Once a profile has been built from a large enough set of examples, statistical analysis can be performed, resulting in the real-world intelligence which can be used to guide forensic analysis in the real-world and in cyber-space. Figure 5 shows an example of a computer system suitable for implementing a method as described above. The system includes a database 501, a PoL module 503 and a PoL-INT module 505. The PoL module 503 and the PoL-INT 505 module may be implemented as sets of instructions stored on a transitory or non-transitory computer readable medium that when executed by a processor cause the processor 8 to perform the operations defined herein. The database 501 is used to store data received from sensors 507a, 507b, such as those on-board the ships X and Y of Figures 2 and 3. The data corresponds to the event data recorded when observing one or more entities, such as the entities A - F shown in those Figures. Figure 6 shows the components of the PoL module 503 in more detail. The PoL module 503 includes a compiler 601, a behaviour predicting module 603, and a training module 605. The compiler 601 is configured to receive the data sets from the data store 501. Since the data sets include unstructured data, the compiler 601 is configured to apply a structure to the data. The structure may include ordering the data within a data set into a sequence of data points. For example, the sequence may be temporal or spatial. As an example, the data set may be structured such that all events are ordered in terms of the time that they were received. As has previously been discussed, an individual data set may not provide complete coverage of the particular sub-region of time and space under observation. For example, there may be gaps in the data where it is not possible to observe the entity’s activity. The compiler 601 is configured to monitor the opportunistic coverage of an area and time to form a model of which areas (or temporal regions) are covered, which areas are not covered, and the frequency of coverage. This frequency of coverage may be provided in the form of a heatmap. These records may help determine the confidence levels for the individual histories. The confidence levels may be based on the frequency of the sub-regions and / or the age of the data. For example, clustering may be applied to the data points in the dataset. This allows the data to be summarised and for models of normal to be produced (e.g. clusters which contain a greater number than a threshold number of points). In some instances, the compiler 601 may determine that adjacent data points relate to the same activity but that further data points are required between them in order to train a PoL model; in other words, there may be a gap in the coverage of the area being observed, such as in the case of the entities C and D in the time point T2 of Figure 4. The behaviour predicting module 603 is configured to predict the behaviour of the entity over a gap in data, where sensor data is not available in the dataset The behaviour predicting module 603 may include a behaviour model. The behaviour model is configured to predict the behaviour of the entity based on the available sensor data, as well as any knowledge that exists about the entity, either a-prior or learnt. More specifically, the behaviour model is configured to predict the behaviour of the entity based on data points in the vicinity of the start and end of the gap, such as that acquired in time points T1 and T3 of Figure 4. The behaviour model may be a kinematic model when the dynamic parameter is a kinematic parameter, e.g. position, velocity, acceleration. The dynamic model may be another type of model based on the nature of the dynamic parameter. When the dynamic model is a kinematic model, the dynamic model may include, for example, a Kalman Filter. The behaviour predicting module 603 may identify a plurality of options for the behaviour of the entity during the gap. A probability is assigned to each option to identify the likelihood that the option reflects the real activity performed by the entity over the gap. The probability may be based on comparative data from elsewhere in the dataset. For instance, if an entity is traveling at velocity V1 at position x1, y1, in a particular direction at time t1, at the start of the gap, and has velocity V2, at position x2, y2, in a particular direction at time t2 at the end of the gap, the dataset can be reviewed to identify similar dynamic parameters elsewhere. The behaviour of the entity between those similar points can be used to assign probabilities to the different options generated by the dynamic model. The behaviour predicting module 603 may select the option with the highest probability for the interpolated data. As more data is obtained, the options can be refined, with the confidence in the selected option increasing accordingly. The interpolation may include interpolating across time and / or space. Interpolating the data may also be supplemented with external knowledge, e.g. timetables or weather, or by using knowledge from PoL histories from similar areas or entity types. For example, the context of the situation, e.g. time of day, weather conditions, etc. should be taken into account to produce accurate interpolations. For example, in bad weather, it may take an entity longer to travel across an area than in good weather. The compiler 601 generates a compiled dataset including the original data set and interpolated data generated by the behaviour predicting module 603. In this way, the compiler 601 performs steps 117 and 121 as shown in Figure 1. The interpolated data may be labelled as such. In this way, if the sensors 10a, 10b detect new events in future which corresponds to a gap in the historical data of the dataset, the interpolated data may be overwritten with the newly obtained event data. The training module 604 may be configured to assign a confidence level to each PoL. The confidence level may be a numerical indicator of the degree of confidence that the PoL model accurately reflects the actual real-world behaviour of the entity. The confidence level may be based on the density of data points, or frequency of data points within the dataset. For instance, more observations results in a higher confidence level. Returning to Figure 5, the PoL-INT module 505 is configured to generate PoL-INT based on the PoL model for the entity. More specifically, the PoL-INT module 505 is arranged to receive the latest PoL history from the PoL module 503 and receive data from the sensors 507a, 507b. Based on the PoL history and the sensor data, the PoL-INT module 505 is configured to generate the PoL-INT. For instance, the PoL-INT module 505 may compare the current data received from the sensors 507a, 507b, to the current PoL history. Based on the comparison, the PoL-INT module 16 may output the PoL-INT to a user interface 509. The user interface may be a touch screen able to receive inputs from a user to interact with the PoL-INT. For instance, the PoL-INT may provide an alert to the user through the user interface 509. The alert may be an anomaly that an entity being observed has performed an unexpected activity or has not performed an expected activity, for example, or the alert may be that the entity has performed a particular activity specified to be of interest by the user. The user is able to interrogate the PoL-INT through the user interface 509. For example, the interrogation may be to understand further layers of detail about the alert, in this case the anomaly. The further layers of detail may include a description of the alert, the time at which the activity occurred / didn’t occur, a description of the activity that occurred / did not occur, etc. In some embodiments, the PoL-INT module 505 may be used to activate an actuator 511 that is configured to control an entity to perform operations in the real world according to instructions included in the PoL-INT. For example, the PoL-INT module 505 may include instructions for the actuator 511 to operate so that the entity behaves according to the historical behaviours. In some embodiments, the actuator may be activated directly by the PoL-INT module, without human intervention. In other cases, the PoL-INT module may display information to a user on the user-interface 509, on the basis of which the user may take action to activate the actuator. Embodiments described herein can contribute to increased mission effectiveness and improved decision making, including: - Enhancing situation awareness knowledge and understanding. - Providing behaviour based intelligence output summary, showing daily, seasonal and cultural variations in the activity for an area. - Providing information and past and future evolution of a situation. - Capturing knowledge of behaviour in a region useful for handover to other operators. Embodiments are applicable across air, land, sea, space and cyberspace, and may be applied to any situation where things change over time, including in the fields of: - Cybersecurity on the internet (monitoring the way in which IP messages are sent across the web) - Chemical processes in a plant (e.g. monitoring pressure, temperature, concentrations when producing a vaccine). - Controlling an unmanned vehicle using information obtained from sensors on-board a platform, such as a vehicle or vessel. Implementations of the subject matter and the operations described in this specification can be realized in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be realized using one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices). While certain embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the invention. Indeed, the novel methods, devices and systems described herein may be embodied in a variety of forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the invention. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the invention. 25 07 24

Claims

1. A method comprising:receiving, from a first source, a first data set comprising measurements taken5 by the first source of at least one parameter associated with an entity at different points in time;identifying at least one gap in the data set comprising absence of a measurement of the parameter at a particular point in time;receiving, from a second source, a second data set comprising at least one10 measurement taken by the second source of the at least one parameter at the particular point in time;generating a combined data set by combining the first data set and the second data set, the combined data set including the measurements of the at least one parameter at each different point in time and the particular point in time;15 generating a pattern of life history for the entity using the combined data set, thepattern of life history providing a statistical representation of the historical behaviour of the entity, the pattern of life history comprising one or more repeated behaviours of the entity, wherein each repeated behaviour corresponds to a particular set of conditions;and20 activating an actuator to act on the entity in response to a repeated behaviour inthe pattern of life history.

2. A method according to claim 1, comprising receiving, from a plurality of sources, respective data sets comprising measurements of parameters associated with one or25 more systems or entities;wherein generating the combined data set comprises:identifying the second data set as comprising the at least one measurement of the at least one parameter at the particular point in time; andresponsive to said identifying, selecting the second data set from among30 the respective data sets to combine with the first data set.

3. A method according to claim 1 or 2, comprising:identifying at least one further gap in the combined data set comprising absence of a measurement of the parameter at another point in time; and35 generating a measurement value for the parameter at the other point in time byinterpolating between measurements of the parameter made before and after said other point in time.25 07 244. A method according to any one of the preceding claims, wherein the first source and second source comprise respective sensors mounted on one or more platforms.

5. A method according to claim 4, wherein the one or more platforms are vehicles and / or vessels.

6. A method according to claim 4 or 5, wherein the sensors are employed for a primary purpose on board the platforms, the primary purpose being distinct from that of generating the pattern of life history, and the first and second data sets comprise measurements captured by the one or more sensors in pursuit of the primary purpose.

7. A method according to any one of the preceding claims, wherein the at least one parameter comprises one or more of:a kinematic parameter of an entity;a chemical parameter; anda network communications parameter.

8. A method according to any one of the preceding claims, wherein comprising issuing an alert to a user based on the pattern of life history.

9. A method according to claim 8, wherein the alert is issued in response to identifying an anomalous behaviour of the entity or system based on the pattern of life history.

10. A method according to any one of the preceding claims, comprising outputting on a user interface information obtained by processing the pattern of life history.

11. A method according to claim 10, further comprising: generating instructions for causing an entity to perform one or more actions based on the pattern of life history.

12. A method according to claim 1, wherein causing the entity to perform one or more actions based on the pattern of life history comprises controlling the entity to operate according to historical behaviour defined in the pattern of life history.

13. A transitory or non-transitory computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to perform themethod of any preceding claim.

14. A computer system comprising: one or more processors; and5 a transitory or non-transitory computer-readable medium according to claim 13.25 07 24

Images