Methods and systems for generating a pattern of life history

Abstract

A pattern of life history is generated by receiving measurement data of system or entities within an environment at different points in time from which a pattern of life history is generated, the patt

Description

FIELD Embodiments described herein relate to methods and systems for generating a pattern of life (PoL) history. BACKGROUND Pattern of life (PoL) analysis is widely used to monitor, analyse and predict the behaviour of different systems or 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 or environment will typically involve the surveillance of the entity or environment over a period of time to build up a PoL history. 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 (or the state of the environment) 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 or environment. Generating a PoL history for a system or environment in which no prior observations exist only becomes possible once the system or environment has been observed for a certain period of time; this is true regardless of whether the PoL history is to be generated manually or in an automated fashion. Ideally, repeated examples of behaviours are required in order to extract the pattern. The period of time over which observations must be made will, therefore, vary with the application; behaviours that occur on Christmas Day, for example, will only be observable once a year, whereas behaviours that occur on a Monday will be observable once a week, and behaviours that occur at lunchtime will be observable every day. Until such a history is available, many aspects of PoL processing, such as anomaly detection or behaviour prediction, for example cannot be performed. Thus, when studying a new system or environment, a delay may occur in being able to further analyse and predict the behaviour of that system or environment. It is desirable, therefore, to provide means for reducing the delay in generating a PoL history for a new system or environment, which has not previously been subject to observation. SUMMARY According to a first aspect of the present invention, there is provided a computer-implemented method of generating a pattern of life PoL history, the method comprising: receiving a first data set comprising measurements of at least one parameter associated with a first system or one or more entities within a first environment at different points in time; generating a first pattern of life history for the first system or environment using the first data set, the pattern of life history providing a statistical representation of the historical behaviour of the system or the one or more entities within the first environment; and using the first pattern of life history to seed a second pattern of life history for a second system, or one or more entities within a second environment. The method may comprise determining to use the first pattern of life history to seed the second pattern of life history by comparing one or more properties of the first system and second system, or comparing one or more properties of the first environment and second environment. The one or more properties may include the type of entities within the first and second environments. The one or more properties may include geographical aspects of the first and second environments. The one or more properties may include the type of system that the first system belongs to, and the type of system that the second system belongs to and / or the purpose for which the first and second system are used. The method may further comprise: receiving a second data set comprising measurements of at least one parameter associated with the second system or the one or more entities within the second environment; and building the second pattern of life history using the second data set. The second pattern of life history may be seeded using the first pattern of life history prior to receiving the second data set. The first data set may be acquired using one or more 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 second pattern of life history. The alert may be issued in response to identifying an anomalous behaviour of the second system or one or more of the entities in the second environment based on the second pattern of life history. The method may comprise outputting on a user interface information obtained by processing the second pattern of life history. The method may comprise: generating instructions for causing one or more of the entities in the second environment to perform one or more actions based on the second 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 second pattern of life history may comprise controlling the entity to operate according to historical behaviour defined in the second 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. 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 flow-chart of steps used in generating a PoL history for a system or environment according to an embodiment; Figure 2 shows a flowchart for generating and utilising Pattern of Life Intelligence (PoL-INT) according to an embodiment; Figure 3 shows a map of a town comprising several streets that meet at intersections, and for which different PoL histories may be applicable to different locations within the map; Figure 4 shows an example of a system according to an embodiment; Figure 5 shows components of a PoL module as shown in Figure 5 in more detail; and Figure 6 shows a flow-chart of steps as carried out by the history extraction and processing module of Figure 4. DETAILED DESCRIPTION Embodiments described herein provide a partial PoL history for a new system or environment without requiring that system or environment to have been observed for a period of time to provide the data for creating the history. This is especially important for real-time operations where there is a need to act quickly after arriving in an area. Whilst not a complete history, the partial PoL history provides sufficient knowledge to provide useful situation awareness information to an operator while the system or environment is observed and a specific history is developed. In doing so, embodiments can reduce the burden on the operator, who is not required to generate a PoL history manually from scratch. Embodiments can thereby yield significant savings in both manpower and processing time. Once generated, the PoL history for the new system or environment can be stored by a computer and exploited by the operator or by further autonomous processes. Figure 1 shows a flow-chart of steps used in generating a PoL history for a system or environment according to an embodiment. An environment under observation may include one or more entities, where 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. As a further example, a car or vehicle can be considered as a system of components; a PoL history may be obtained for that system, for purposes of maintenance and repair. The method begins by receiving data from observations of a first system or environment (step S101). In a second step (S103), the observations are used to generate a first pattern of life history for the first system or environment. The process of generating the first pattern of life history (S103) may itself comprise a sequence of steps, which can be further understood with reference to Figure 2. Here, the observations 200 as obtained in step S101 of Figure 1 are accumulated over time, so as to build up data from which behaviour patterns can be extracted. The behaviour of a system or environment can be understood to comprise a sequence of dynamic parameters associated with that system or environment, which can be observed or inferred from the observations. Dynamic parameters are themselves ones that change over time and might include kinematic parameters, such as the position, velocity, and / or acceleration of entities within the environment, for example. Through observing dynamic parameters, it is possible to identify different behaviours, such as in the case of observing kinematic parameters, 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 environment’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 I network parameters such as the amount of data traffic being sent across a network connection at any one point in time. Still referring to Figure 2, the recorded observations 200 can be used to establish sets of behavioural patterns 201a, 201b ..., 201 n. To determine the behaviour of a system, or entities within an environment, 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 environment 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. Once the behavioural patterns are established, these may in turn be processed to generate histories 203a, 203b ..., 203n. For each instance of an observed behaviour, the history may record one or more of: - A time and / or date at which the behaviour occurred. - A length of time over which the behaviour occurred. - A 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. - A set of conditions at the time of the behaviour (e.g. weather conditions). Different observations of the same entity, environment 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 205 into a single PoL history 207, using steps 209 to 221. In step 209, 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 211 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 213. 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 215 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 219 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 221 into the history merging process 205; 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. As well as continuing to update and refine the PoL history, the steps shown in Figure 2 include the output 223 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. Returning back to Figure 1, having generated the first pattern of life history, that pattern of life history may be used to seed a pattern of life history for a second system or environment (step S105). In order for the first pattern of life history to act as an accurate seed for the second pattern of life history, it will be necessary for the first system or environment to share similar types of behaviour with that of the second system or environment. Thus, as a prelude to seeding the second pattern of life history, consideration will need to be given to the nature of the second system or environment, and its similarities to the first system or environment. As an example, if the second environment is based at a different location, it will be necessary to have a basic knowledge of the characteristics of that location; this might include knowledge of geography, maps, culture, climate, etc. The process of identifying a first pattern of life history that may provide a seed for a second, specified system or environment - or identifying a second system or environment for which an existing pattern of life history may provide a seed - can be further understood with reference to Figure 3. Figure 3 shows a map of a town comprising several streets that meet at intersections 301, 303, 305. Traffic lights 307a, 307b, 307c are located at the different intersections, and serve to manage the flow of traffic through those intersections. Also shown on the map are various cars 309a, 309b, 309c, 309d etc. that are travelling along the streets at a particular moment in time. One or more cameras or other sensors may be placed at each intersection to capture images of the intersection throughout the day. Each one of the intersections 301, 303, 305 can be considered a distinct environment, having its own associated pattern of life history. The pattern of life history for a particular intersection may characterise the flow of traffic passing through the intersection at different times of the day, the direction of travel of the different vehicles, the number of pedestrians crossing the street at each intersection etc. In an example embodiment, a pattern of life history may be generated for the first intersection 301 by analysing the data contained in images captured by the sensor(s) at that location over time. The pattern of life history may provide useful information regarding the flow of traffic through the intersection, which can be used to optimise the control of the traffic lights 307a located at that intersection. The pattern of life history will also include positional coordinates of the intersection, as well as one or more tags or labels describing the nature of the location from which the history was created. These tags may include, for example, “Road intersection”, “Traffic Lights”, “Suburban”, “Four-Way Junction”, etc. The pattern of life history generated for the first intersection 301 may provide the basis for seeding a second pattern of life history for one or more of the other intersections 303, 305. Here, consideration will need to be given to the similarities and differences in geography and infrastructure at those intersections. These similarities may be examined by comparing the tags associated with the pattern of life history for the first intersection 301 with aspects of the second 303 and third intersections 305. Beginning with the second intersection 303, this intersection, like the first intersection 301, comprises a four-way junction with traffic lights. In addition, the first intersection 301 and second intersection 303 have similar geographies; both have neighbouring parks or green spaces, for example. In contrast, the third intersection 305 has quite a different layout from the first intersection 301. The third intersection 305 comprises a T-junction, with no traffic lights. Moreover, the third intersection 305 lies between a fire station and hospital; thus, the third intersection 305 is likely to see a greater number of ambulances and fire engines than that seen at the first intersection 301 and the second intersection 303, with an associated difference in traffic flow owing to the different speeds at which such vehicles travel compared to the other cars on the roads. By taking these similarities and differences in geography and local infrastructure between the intersections 301, 303, 305 into account, it can be determined that the first pattern of life history provides a suitable basis for seeding a pattern of life history at the second intersection 303, but not the third intersection 305. When using the pattern of life history for the first intersection 301 as a basis for seeding a pattern of life history at the second intersection 303, the positional coordinates of the first intersection 301 will be removed, but the vehicle behaviour at different parts of that intersection will be retained. As time processes, observations received from sensors located at the second intersection 303 can be used to refine and replace the more general details in the seed history obtained from the first intersection 301. Accordingly, embodiments can be understood to apply an existing pattern of life history to new areas with the same or similar type of location, with more specific histories for those locations being produced over time. Whilst the example embodiment shown in Figure 3 considers the case of two separate environments (in this case, the locations of the first intersection 301 and the third intersection 303), it will be appreciated that the same principle is applicable to two different systems. As an example, the pattern of life history for a first chemical processing apparatus may be used to seed a pattern of life history for a second chemical processing apparatus, where that second apparatus has a similar structure, function and / or operating parameters to the first apparatus. Figure 4 shows a system suitable for implementing a method as described above. The system includes a first part 401 that is used to generate a PoL history for a first system or environment under observation. The first part includes a database 403, a PoL module 405 and a PoL-INT module 407. The PoL module 405 and the PoL-INT module 407 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 to perform the operations defined herein. The database 403 is used to store data received from sensors 409a, 409b, such as might be positioned at the intersections 301, 303, 305 of Figure 3. The data corresponds to the event data recorded when observing the first environment or system. Figure 5 shows the components of the PoL module 405 in more detail. The PoL module 405 includes a data compiler 501, an interpolation module 503, and a training module 505. The data compiler 501 is configured to receive the data sets from the database 403. Since the data sets include unstructured data, the data compiler 501 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 a system or entity’s activity. The data compiler 501 is configured to monitor the 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 data set. 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 data compiler 501 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. The interpolation module 503 is configured to predict the behaviour of the system under observation, or an entity within an environment, over a gap in data where sensor data is not available in the data set. The interpolation module 503 may include a behaviour model. The behaviour model is configured to predict the behaviour of the system or environment based on the available sensor data, as well as any knowledge that exists about the system or environment, either a-prior or learnt. More specifically, the behaviour model is configured to predict the behaviour of the system or environment based on data points in the vicinity of the start and end of the gap. 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 interpolation module 503 may identify a plurality of options for the behaviour of the system or environment under observation during the gap. A probability is assigned to each option to identify the likelihood that the option reflects the real activity performed by the system or one or more entities in the environment over the gap. The probability may be based on comparative data from elsewhere in the data set. For instance, if an entity in an environment under observation 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 data set 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 interpolation module 503 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 systems or environments to the one under observation. 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 data compiler 501 generates a compiled data set including the original data set and interpolated data generated by the interpolation module 503. In this way, the data compiler 501 performs steps 217 and 221 as shown in Figure 2. The interpolated data may be labelled as such. In this way, if the sensors 409a, 409b detect new events in future which corresponds to a gap in the historical data of the data set, the interpolated data may be overwritten with the newly obtained event data. The training module 505 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 system or environment. The confidence level may be based on the density of data points, or frequency of data points within the data set. For instance, more observations results in a higher confidence level. Returning to Figure 4, the PoL-INT module 407 is configured to generate PoL-INT based on the PoL model for the system or environment. More specifically, the PoL-INT module 407 is arranged to receive the latest PoL history from the PoL module 405 and receive data from the sensors 409a, 409b. Based on the PoL history and the sensor data, the PoL-INT module 407 is configured to generate the PoL-INT. For instance, the PoL-INT module 407 may compare the current data received from the sensors 409a, 409b, to the current PoL history. Based on the comparison, the PoL-INT module 407 may output the PoL-INT to a user interface 411. 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 411. The alert may be an anomaly that an entity in an environment 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 411. 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. The PoL-INT module 407 may also be used to activate an actuator 413 that is configured to control an entity or system to perform operations in the real world according to instructions included in the PoL-INT. For example, the PoL-INT module 407 may include instructions for the actuator 413 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 411, on the basis of which the user may take action to activate the actuator. 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. The 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. The PoL-INT may be useful for predictive maintenance, thus reducing vehicle unavailability and repair costs. 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. The second part 415 of the system includes similar components to the first part 401 of the system; as in the first part, the second part includes a database 417, a PoL module 419, a PoL-INT module 421, one or more sensors 423a, 423b, a user interface 425 and actuator 427. The second part 415 of the system may be used to generate a second PoL life for a second system or environment that is different from the first PoL history generated by the first part 401 of the system; thus, the components 417 - 427 have the same functionality as their counterparts 403 - 417 in the first part 401 of the system, but perform their roles in relation to a different system or environment. The first part 401 of the system may generate the first PoL history before it becomes necessary or desirable to obtain a PoL history for the second system or environment. In such cases, the first PoL history may be used to seed the creation of the PoL history for the second system or environment. In order to enable this, a PoL history extraction and processing module 429 is provided, together with a further database 431. The database 431 is used to store PoL histories such as the first PoL history, as well as knowledge of the characteristics of the systems or environments for which those PoL histories have been created. Each stored history may be tagged with labels describing the type of location from which the history was created. The database 429 also stores knowledge of characteristics of systems and / or environments for which a PoL history has yet to be obtained, including the second system or environment. The function of the history extraction and processing module 429 can be understood with reference to Figure 6, which shows a flow-chart of steps carried out by that module. In step S601, the history extraction and processing module 429 receives a description of the second system or environment. In step S603, the history extraction and processing module identifies, from the list of PoL histories stored in the database 431, the PoL history for the system or environment that most closely matches the second system or environment. Based on the information stored in the database 431, the history extraction and processing module 429 is able to determine that the second system or environment has characteristics similar to the first system or environment, which makes the first PoL history a suitable basis for seeding a PoL history for the second system or environment. In step S605, the history extraction and processing module 429 proceeds to extract the general aspects of the first PoL history, by removing location and time labels from the first PoL history, thereby generating a “generic” version of the PoL history. Referring back to the example of Figure 3, a generic version of the PoL history for the first intersection 301 may include the sequence of traffic light signals: Red, Red / Amber, Green, Flashing Amber, Red, without specifying the time intervals for which the lights remain Red and Green; this reflects the fact that the timing of the traffic light signals (e.g. how long a light remains green) may change from one location to another, but the underlying sequence remains the same. In step S607, the generic version of the PoL history is forwarded to both the PoL module 419 and the PoL-INT module 421 of the second part 415 of the system. By receiving the generic version of the PoL history from the history extraction and processing module 429 at the outset, the PoL-INT module 421 of the second part of the system can immediately generate PoL-INT for the second system or environment, even before many (or any) observations have been received from the sensors 423a, 423b associated with that system or environment. The PoL-INT module 421 can, in turn, perform operations akin to that of the PoL-l NT module 407 in the first part 401 of the system. Meanwhile, the PoL module 419 will, over time, supplement the received PoL history with observations received from the sensors 423a, 423b, in turn refining the PoL-INT output from PoL-INT module 421. Techniques such as incremental learning may be useful for combining the newly received sensor data into the initial seed history received from the history extraction and processing module 429. In this way, the output from the first part of the system can provide a template for a second PoL history relating to a second system or environment By doing so, the second PoL history can be established more quickly and with reduced manpower. Moreover, the template may itself be used to immediately generate and output PoL-INT for the second system or environment, something that is especially useful for situation awareness of a new region into which a team has just been deployed. Refinements to the second PoL history may then feed through into the PoL-INT as the number of observations made of the second system or environment grows over time. Accordingly, having determined it is desirable to study a particular system or environment in more detail, embodiments can be used to more quickly assemble a data set from which behaviours associated with that system or environment can then be derived and analysed in greater detail. This in turn can be contribute to increased mission effectiveness and improved decision making, with applications including: - 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 land, air, sea and cyber domains for the military and transport, and may be applied to any system or environment 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, eg., 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. 29 07 24

Claims

1. A computer-implemented method comprising:5 receiving a first data set comprising measurements of at least one parameterassociated with a first system or one or more entities within a first environment at different points in time;generating a first pattern of life history for the first system or environment using the first data set, the pattern of life history providing a statistical representation of the10 historical behaviour of the system or the one or more entities within the first environment;using the first pattern of life history to seed a second pattern of life history for a second system, or one or more entities within a second environment; andone or both of:15 issuing an alert to a user based on the second pattern of life history; andgenerating instructions for causing one or more of the entities in the second environment to perform one or more actions based on the second pattern of life history.

2. A computer-implemented method according to any one of the preceding claims,20 comprising determining to use the first pattern of life history to seed the second pattern of life history by comparing one or more properties of the first system and second system, or comparing one or more properties of the first environment and second environment.25 3. A computer-implemented method according to claim 2, wherein the one or moreproperties include the type of entities within the first and second environments.

4. A computer-implemented method according to claim 2 or 3, wherein the one or more properties include geographical aspects of the first and second environments.

305. A computer-implemented method according to claim 2, wherein the one or more properties include the type of system that the first system belongs to, and the type of system that the second system belongs to and / or the purpose for which the first and second system are used.

6. A computer-implemented method according to any one of the preceding claims,29 07 24further comprising:receiving a second data set comprising measurements of at least one parameter associated with the second system or the one or more entities within the second environment; andbuilding the second pattern of life history using the second data set.

7. A computer-implemented method according to claim 6, wherein the second pattern of life history is seeded using the first pattern of life history prior to receiving the second data set.

8. A computer-implemented method according to any one of the preceding claims, wherein the first data set is acquired using one or more sensors mounted on one or more platforms.

9. A computer-implemented method according to claim 8, wherein the one or more platforms are vehicles and / or vessels.

10. A computer-implemented method according to claim 8 or 9, 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.

11. A computer-implemented 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.

12. A computer-implemented method according to any one of the preceding claims, wherein the alert is issued in response to identifying an anomalous behaviour of the second system or one or more of the entities in the second environment based on the second pattern of life history.

13. A computer-implemented method according to any one of the preceding claims, comprising outputting on a user interface information obtained by processing the second pattern of life history.29 07 2414. A computer-implemented method according to any one of the preceding claims, comprising activating an actuator to act on the entity in response to a behaviour in the pattern of life history.

515. A computer-implemented method according to claim 14, wherein causing the entity to perform one or more actions based on the second pattern of life history comprises controlling the entity to operate according to historical behaviour defined in the second pattern of life history.1016. 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 any preceding claim.15 17. A computer system comprising:one or more processors; and a transitory or non-transitory computer-readable medium according to claim 16.

Images