Policy management

Abstract

Extracting from a first policy data file features of the first policy and determining, based on a comparison between the target device and condition extracted from the first policy, and stored policy

Description

102 i sub-system GB 2642759 A 200a Figure 2a 200b Figure 2b User interface 308 detected Raise alert 8 a 8 S 8 8 a 8 8 8 8 8 8 a 8 8 Global data store 804 Global machine learning training engine 806 User interface 810 Communication module 808 Receive data Receive data 104b 5 3 3 3 3 3 3 Discovery module 1102 User interface 1104 3 3 3 3 3 3 3 Routing module 1106 Datastore 1108 Encryption module 1110 Decryption module 1112 Node details: • Unique identifier • Address 1204 Establish connection(s) 1208 State details: * Encryption level • Software version Store records 1207, 1216, 1219 Request node routing tables 1218 — Analyse request 1302 ______t_____ Analyse routing tables 1304 Retrieve routing tables Decide route request 1308 Via communication network sub-systems ____________v___________ ! j J Poiicy management : ; sub-system । * Anomaly detection 104a i sub-system i Create / update policy 1512 Policy Management Field of Invention This invention relates to policy management. More specifically, the invention relates to a methods of policy management, anomaly detection, and network communication in a policybased control system. Background Policy-based systems are systems that are controlled at least in part on the basis of policies which define an action to be taken when one or more conditions exists. Typically, policies are created by a user and entered into a control system which stores and implements the policies. Existing policy-based control systems are static and unintelligent which gives rise to a number of problems. First, it is possible in existing policy-based control systems to have several conflicting policies which can lead to poorly configured sub-systems and even critical system failures. Second, the data used to determine whether a particular condition exists can contain anomalies. Identifying and classifying these anomalies accurately is important to ensure efficient and accurate implementation of the policies. Third, existing systems are typically based on centralised networks which are more open to cyber vulnerabilities. The present invention seeks to at least partially ameliorate these problems. Summary of the Invention Aspects and embodiments of the present invention are set out in the appended claims. These and other aspects and embodiments of the invention are also described herein. According to at least one aspect described herein, there is provided a method of policy management in a policy-based control system, the policy-based control system storing a plurality of policy data files recording policies for the policy-based control system, the method comprising: extracting from a first policy data file features of the first policy, the features comprising at least one target device of the first policy and at least one condition of the first policy; determining, based on a comparison between the target device and condition extracted from the first policy, and target devices and conditions of the plurality of stored policy data files, a conflict between the first policy and at least one of the stored policies; and outputting an alert to a user. Preferably, the method comprises generating the first policy data file based on a user input via a user interface. Preferably, the user input comprises: a user entering the policy, or features of the policy, in plain text; and / or a user selecting, via the user interface, features of the policy, wherein the features of the policy comprise one or more of: at least one parameter; at least one threshold; at least one comparison operation; and at least one action. Preferably, the first policy data file is generated in JavaScript Object Notation (JSON) format. Preferably, wherein extracting the features of the first policy comprises parsing the first policy data file. Preferably, extracting the features of the first policy comprises generating an array object, preferably a JavaScript or JSON array, the array comprising the extracted features of the policy. Preferably, the comparison is between the generated array object and a plurality of other array objects generated from the plurality of stored policy data files. Preferably, the extracted features of the first policy also comprise a category of the target device of the first policy. Preferably, determining a conflict comprises, first, comparing the target device extracted from the first policy and the target devices of the plurality of stored policy data files to identify a sub-set of the plurality of stored policies that act on the same target device. Preferably, determining a conflict comprises, second, comparing the condition extracted from the first policy and the conditions of the sub-set of the plurality of stored policy data files to identify potentially conflicting policies that have conditions overlapping with the extracted condition of the first policy. Preferably, determining a conflict comprises, third, determining, preferably according to hardcoded rules, which of the potentially conflicting policies have actions that conflict with an action of the first policy. Preferably, the method comprises receiving user input to select one of multiple conflicting policies to be implemented in preference to the other conflicting policies to resolve a conflict. Preferably, the method comprises receiving user input to amend a feature of at least one of multiple conflicting policies to resolve a conflict. Preferably, the method comprises determining a priority associated with one of multiple conflicting policies, and implementing the highest priority conflicting policy in preference to the other conflicting policies to resolve a conflict. According to another aspect disclosed herein, there is provided a method of anomaly detection in a policy-based control system, the method comprising: monitoring, using a first anomaly detection system, a first data stream, the first anomaly detection system configured to classify data in the first data stream as anomalous or not anomalous based on a first trained model local to the first anomaly detection system; monitoring, using one or more further anomaly detection systems, one or more further data streams, the one or more further anomaly detection systems configured to classify data in the one or more further data streams as anomalous or not anomalous based on further trained models local to each respective further anomaly detection system; and for a classification made by the first anomaly detection system which is within a confidence threshold: transmitting to the further anomaly detection system(s) the data on which the classification was based; and classifying, by the further anomaly detection system(s), the data as anomalous or not anomalous based on the further trained model(s), re-classifying, by the first anomaly detection system, the data as anomalous or not anomalous based at least in part on an assimilation of the classifications made by the further anomaly detection system(s). Preferably, the assimilation comprises computing a weighted average of the classifications made by the further anomaly detection system(s), wherein the classifications are weighted according to a level of trust associated with each further anomaly detection system. Preferably, each anomaly detection system comprises a local data store configured to store local training data to train the model of each anomaly detection system. Preferably, the models of each anomaly detection system are reinforcement learning models. According to another aspect disclosed herein, there is provided a method of network communication of data between an origin node and a destination node in a policy-based control system, the method comprising: determining, using routing tables stored by the origin node, potential paths through the network from the origin node to the destination node; determining a trust level for each of the potential paths, wherein the trust level of each potential path is determined at least in part from trust scores associated with intermediate nodes along the path; determining at least one constraint for the data, the at least one constraint comprising a security and / or time constraint; selecting one of the potential paths based on the at least one constraint for the data and the trust level of the potential paths; and transmitting the data from the origin node to the destination node along the selected path. Preferably, the method comprises the origin node transmitting, preferably by broadcasting or multicasting, a messenger signal to the nodes in the network, wherein the trust scores of the intermediate nodes are determined based on a reaction of the intermediate nodes to the messenger signal. Preferably, the messenger signal comprises at least one of: a unique identifier and / or network address of the origin node; information relating to neighbouring nodes in the network; preferably routing tables and / or encryption standards; and quality of service requirements. Preferably, the reaction of the intermediate nodes comprises at least one of: a failure to respond within a time out period; a Transport Layer Security level; a software version for the intermediate node; and a geographical location of the intermediate node. Preferably, the method comprises re-determining potential paths to the destination node and the trust levels of each potential path at intermediate nodes along the path, and re-selecting the path to the destination node based on the re-determination. According to another aspect disclosed herein, there is provided a policy-based control system comprising at least one of: a policy management system configured to implement the method of policy management as aforementioned; an anomaly detection system configured to implement the method of anomaly detection as aforementioned; a communication network system configured to implement the method of network communication as aforementioned. According to another aspect disclosed herein, there is provided a policy-based control system comprising: an anomaly detection system configured to implement the method of anomaly detection as aforementioned and a communication network system configured to implement the method of network communication as aforementioned, wherein the anomaly detection system forms an edge node of the communication network system. Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. Furthermore, any, some and / or all features in one aspect can be applied to any, some and / or all features in any other aspect, in any appropriate combination. It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and / or supplied and / or used independently. The invention also provides a computer program or a computer program product for carrying out any of the methods described herein, and / or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and / or for embodying any of the apparatus features described herein. The invention also provides a signal embodying a computer program or a computer program product for carrying out any of the methods described herein, and / or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out the methods described herein and / or for embodying any of the apparatus features described herein. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory. Furthermore, features implanted in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. One or more aspects will now be described, by way of example only and with reference to the accompanying drawings having like-reference numerals, in which: Figure 1 is a diagram showing the overall architecture of a policy-based control system including a policy management sub-system, an anomaly detection sub-system, and communication network sub-systems; Figure 2a is a flowchart showing an existing policy management procedure, not according to the present invention; Figure 2b is a flowchart showing an improved policy management procedure implemented by the policy management sub-system disclosed herein; Figure 3 is a diagram showing the logical architecture of the policy management sub-system; Figure 4 is a diagram showing the logical architecture of a policy handler of the policy management sub-system; Figure 5 is a diagram showing the logical architecture of a policy conflict detection tool of the policy handler; Figure 6 is a diagram showing the functional architecture of the policy management subsystem; Figure 7 is a diagram showing the logical architecture of an anomaly detection sub-system; Figure 8 is a diagram showing the logical architecture of a central orchestration server coupled to the anomaly detection sub-system; Figure 9 is a diagram showing a high-level overview of the functional architecture of the anomaly detection sub-systems; Figure 10 is a diagram showing in more detail the functional architecture of the anomaly detection sub-systems, and in particular the consensus decision making functionality; Figure 11 is a diagram showing the logical architecture of a communication network subsystem; Figure 12 is a diagram showing the functional architecture of the communication network sub-system; Figure 13 is a flowchart showing the procedure for a communication network sub-system deciding a routing path in the network; and Figures 14 and 15 are diagrams showing, in combination, the wider functional architecture of the anomaly detection sub-system and policy management sub-system. Detailed description Overview Figure 1 is a diagram showing the overall architecture of a policy-based control system 100 according to the present disclosure. The policy-based control system 100 includes a policy management sub-system 102, and first anomaly detection sub-system 104a, a second anomaly detection sub-system 104b, and multiple communication network sub-systems: one (106a, 106b) associated with each of the anomaly detection sub-systems and one (106c) associated with the policy management sub-system. In other examples of the system 100 other sub-systems may be present, in addition to those shown in Figure 1, such as additional anomaly detection sub-systems or other integrated applications. In such other examples, the additional sub-systems may also have their own associated communication network sub-systems. Each anomaly detection sub-system and policy management sub-system, together with its associated communication network sub-system, forms a node in a network upon which the control system 100 is based. The three communication network sub-systems implement a communication framework for exchanging information between the other sub-systems of the control system 100 over this network. In this way, the communication network sub-systems form a one-to-many communication network (in that, the policy management sub-system has one associated communication network sub-system which communicates with many communication network sub-systems associated with each of the other sub-systems in the system 100). The policy management sub-system 102 stores, manages, and implements policies for controlling a policy-based system. In the context of the present disclosure, the term “policy” is used to mean a logical statement defining the action to be taken if a particular condition or combination of conditions exists. A policy-based system is a system which is controlled, at least in part, on the basis of such policies. An example of a policy-based control system is a building management system which would monitor the conditions in a building and implement actions to be taken on the basis of those conditions. In this example, the building management system may contribute to the monitoring and / or automation of tasks such as any one or more of: energy management and optimisation; heating, ventilation, and air conditioning (HVAC) control and optimisation; lighting control and efficiency; security and access control; and fire safety and emergency response. In this example, a policy for such a system might be to turn the heating on if the time is after 0600, and / or to maintain the temperature of the building at 20 degrees Celsius between the hours of 0800 and 1700. The logical and functional architecture of the policy management sub-system 102 is described in detail below with reference to Figures 2a, 2b and 3 to 6. The anomaly detection sub-systems 104 act as gateways for information coming into the policy-based control system 100 from the system it is controlling, and therefore act as edge nodes in the network upon which the control system 100 is based. The anomaly detection sub-systems monitor the data they receive for anomalies. The anomalies may relate to security infringements (for example, malicious network traffic being transmitted into the control system 100 via these edge nodes) or the anomalies may relate to the performance of devices within the system being controlled (for example, data indicative that a device in the system is failing and requires maintenance). The control system 100 shows two anomaly detection sub-systems 104a, 104b, but in other examples there may be one anomaly detection sub-system for each stream of data being monitored by the system 100. In the example where the policy-based control system is a building management system, the control system may include a plurality of anomaly detection sub-systems to monitor streams of data received from a plurality of sensors in the building to identify anomalies before the data is used to determine whether policy conditions are met. In this example, each sensor feeding into the control system 100 may have a corresponding anomaly detection subsystem to check for anomalies. The architecture, function, and operation of the anomaly detection sub-system 104 is described in detail below with reference to Figures 7 to 10. The policy-based control system 100 is formed as a network, where the anomaly detection sub-systems and policy management sub-system(s) exchange information via communication network sub-systems. The communication network sub-systems implement procedures to enable efficient and secure communications within the network. The architecture, function, and operation of the network upon which the policy-based control system 100 is based are described in detail below with reference to Figures 11 to 13. The wider functional architecture of the control system 100 is described in detail below with reference to Figures 14 and 15. Policy management Figure 2a is a flowchart showing a traditional policy management procedure 200a implemented by a policy management system not according to the present invention. The functions handled by the traditional policy management system are shown above the dashed line, and the functions handled manually by the user are shown below the dashed line. In the procedure 200a of Figure 2a, the user creates a policy at step 202. This involves, for example, a user determining an action to be taken when a condition, or a combination or sequence of conditions, is detected. The user may create the policy by interacting with a (graphical) user interface to input the features of the policy (i.e., the action(s) and / or the condition(s) of the policy). For example, the user may select an action from a range of possible actions and the user may also select one or more conditions from a range of possible conditions. Alternatively, the user may input text comprising a policy in code form (for example, in JavaScript Object Notation (JSON) format). At step 204, a policy conflict is detected. In a traditional policy management system, this step is carried out manually by the human user. This involves a user manually looking through all existing policies (as may be, for example, stored in a policy database associated with the policy management sub-system) to determine whether the newly created policy may conflict with any existing policies. This is difficult firstly because the number of policies stored in a typical policy database could be thousands or more, particularly for large or complex systems, and secondly because the user would typically need to follow complex logic gates to identify whether there might be a situation where a set of conditions could trigger conflicting actions to be implemented. At step 206, action is taken to resolve the policy conflict identified in the previous step. For example, the user may amend the action(s) or condition(s) of the newly created policy and / or an existing policy to avoid conflicts. At step 208, the new policy is stored in records. For example, the policy database may be updated to store the new policy. In addition, the policy database may be updated to record an update to one or more existing policies as they may have been amended to avoid conflicts with the new policy. Figure 2b is a flowchart showing an improved policy management procedure 200b implemented by the policy management sub-system 102 of the policy-based control system 100 disclosed herein. The functions handled by the policy management sub-system 102 are shown above the dashed line, and the functions handled by the user are shown below the dashed line. In the procedure 200b of Figure 2b, the user creates a policy at step 210. As with the procedure 200a of Figure 2a, this step is carried out by the user and involves, for example, a user determining an action to be taken when a condition, or a combination or sequence of conditions, is present either by interacting with a user interface to input the features of the policy or to input a policy in plain text or code form. At step 212, a policy conflict is detected. Unlike in existing policy management systems, this step is carried out by the policy management sub-system 102, and the process for doing so is set out in more detail in Figure 6. At step 214, action is taken to resolve the policy conflict identified in the previous step. In this procedure 200b, this may involve issuing an alert to a user (e.g., via the user interface) to make the user aware of the conflict and seeking user input to resolve the policy conflict. In this case, as a next step 216, user input is received (e.g., again, via the user interface) to resolve the conflict. The user input may include the user selecting from multiple options for resolving the conflict as generated by the policy management engine, or the user amending a feature of the newly created policy and / or an existing policy (such as amending the action(s) or condition(s) of the newly created or existing policies) to avoid conflicts. Alternatively, action at step 214 could include the policy management sub-system autonomously resolving the detected policy conflict. This autonomous conflict resolution mechanism may work best in cases where there is a clear pathway to resolution. In this case, an alert would still be raised to the user to notify them of the policy conflict. In the JSON schema, there is a parameter called ‘priority’. The priority parameter may be used to decide which of two conflicting policies may be implemented over the other in case of a conflict. For example, in cases where there is a conflict between two policies, one with priority 1, and one with priority 2, the policy with priority 1 would be implemented since it takes precedence over the other. For example, where two policies conflict in an overlapping parameter range, each policy may be activated in the non-overlapping part of the range, but the lower priority policy may be deactivated in the overlapping range. At step 218, the new policy is stored in records. For example, the policy database may be updated to store the new policy. In addition, the policy database may be updated to record a change to one or more existing policies as may have been required to avoid conflicts with the new policy. Figure 3 is a diagram showing the logical architecture of the policy management sub-system 102. The policy management sub-system includes a policy handler module 302, a data handler module 304, and one or more integrated applications 306. The modules of the policy management sub-system can exchange information with one another as indicated by the arrows in Figure 3. The policy handler 302 comprises at least two servers, one clear server and one Secure Sockets Layer (SSL) server, which are responsible for the internal and external communications of the policies and their actions. The policy handler also comprises a parser, which is responsible for formatting and extracting data from the policies. An Application Programming Interface (API) is then responsible for managing data inputs and outputs from external integrated applications to the policy handler system. The data handler 304 provides an API frontend for third-party applications to directly query the database through a defined and access-controlled API, for example providing near realtime information on devices and configurations within the system. The integrated applications 306 are the devices or systems which are controlled by the policy-based control system. In the example of a building control system, the integrated applications would be, for example, the HVAC system, cameras, alarm systems, door systems etc. A user interface 308 is communicatively coupled to the policy management sub-system 102 in this example. In other examples, the user interface 308 may be a distinct module within the policy management sub-system 102. The user interface is configured to display information to a user, and to receive user input of information, relating to policies of the policy-based controlled system. The user interface is where the user can login, and create, edit, update, and delete policies. The user interface will also display the current policies in the database, and any alerts for conflicts currently ongoing. Figure 4 is a diagram showing the logical architecture of the policy handler module 302 of the policy management sub-system 102. The policy handler module 302 is communicatively coupled to a policy database 402 which stores existing policies for the control system 100. The policy handler 302 interacts with the database 402 to retrieve existing policies to check whether a new policy conflicts with any existing policies, and also to store new policies (or update existing policies) depending on the outcome of a conflict detection procedure. The policy handler 302 is also communicatively coupled to an application programming interface (API) 404. The API is configured to convert a policy from one format to another format. In particular, the API in this example is configured to convert policies from JSON format to an array format and back again. Policies are initially generated in JSON format when created by a user, and stored and implemented in JSON format. However, an array format enables the policy to be checked against existing polices for conflicts more effectively. Therefore, to check policies for conflicts, newly created policies and stored existing policies may be converted from JSON format to array format for checking, and then returned to JSON for storage and implementation. The API may be communicatively coupled to a parser 406 to parse policies to extract features of the policies as described below. The parser may parse the policies in JSON format before the policies or policy features are converted to array format, or the parser may receive from the API policies in array format to be parsed by the parser. The API may pull relevant policies from the database, adding them to an array for comparison against the new policy for conflicts, the API will also query target system states, and these are added to a second array for comparison against the new policy to identify if a policy cannot be actioned due to the target system state (for example, the device is offline and not active). The policy handler 302 is also communicatively coupled to a policy conflict detection tool 408. This tool 408 is used to cross reference the features extracted from a new policy against the features extracted from an existing policy to check whether there is a match or overlap between the conditions of the policies and any conflict in the actions of the policies. The policy conflict detection tool 408 may therefore be communicatively coupled to the policy database 402 to retrieve from the database details of existing policies. Figure 5 is a diagram showing the logical architecture of the policy conflict detection tool 408 of the policy handler. The tool 408 includes a triage service 502, which deals with run-time conflicts, and a conflict detection service 504 to detect any conflicts between new policies and existing policies at the point of policy creation of the new policies, or to detect run-time conflicts, and a conflict resolution service 506 to resolve (either autonomously or via user input) any conflicts detected. It should be noted that in each of Figures 3 to 5 the logical architectures shown are exemplary, and in some cases simplified for the purposes of brevity and clarity. In practice, the logical architecture may differ from what is shown: for example, connections between modules may exist where none are shown, connections between modules may be direct where they are shown as being indirect, and vice versa, and there may be additional modules which are not shown in the drawings. Figure 6 is a diagram showing the functional architecture of the policy management subsystem 102. At step 602, a user interface (e.g., user interface 308) is provided to a user. For example, the system may display a graphical user interface on a display. The user interface may be provided with physical controls such as buttons, dials, sliders, or a keyboard in addition to a display, or the display may include a touchscreen interface. In any case, the user interface may provide a means for the user to view currently active policies managed by the policy management sub-system (and any policy conflicts) and for the user to input at least one feature of a new policy or update at least one feature of an existing policy. For example, the user interface may provide a means for a user to input at least one action and at least one condition to be met forthat action to be implemented. Alternatively, or additionally, the user interface may allow a user to input a policy in plain text. The features of the policy may include at least one parameter; at least one comparison operation; at least one threshold for (each of) the parameter(s); and an action to be taken. Each of these features may be user input. In the example where the policy management system is used as part of a building control system, a simple example of these policy features is shown in the table below: Parameter Threshold Comparison operation Action Temperature 19°C Less than Activate heating In this example, the temperature in a part of the building is measured (e.g., by an in-situ sensor), and if it is determined to be less than 19°C, the heating is activated. Other policies may be significantly more complex. For example: an action may be taken in 5 dependence on how multiple parameters compare to a threshold (or multiple thresholds); an action may be taken only if a parameter differs from a threshold for a certain period of time; an action may be taken only if multiple parameters differ from their respective thresholds by a cumulative amount; or an action may be taken only if multiple parameters differ from their respective thresholds in a particular sequence. 10 At step 604, a policy data file is created based on the user input. In this example, the policy data file is created using the JSON format. An exemplary JSON policy for a building management system, following the example provided for step 602 above, is as follows: {“policy": { "priority": 1, "schema": 1, "timestamp": "2017-01 -01T12:00:00Z", "enabled": true, "requires_approval": false, "conditions": { "logic": "parameter! <parameter! .valuer, "parameter!": { "name": "Temperature", "targets": "system.thermostat", "valuer: "19" }}, "actions": { "parameter{ "name": "Temperature", "targets": "group.heaters", "value": "19" }}}} As can be seen, the JSON policy includes coded conditions and actions. The conditions are the logical statements) to be met in order for the action to be taken. In this example, the logical statement is "parameterl <parameter! .valuer - that is, the value of parameterl must be less than the threshold value parameterl .valuel for the condition to be met. As can be seen from the definition of “parameterl”, this relates to the temperature (for example in degrees Celsius) as measured by the “system.thermostat” sensor which may be, for example, an in-situ thermostat in a building management system. The threshold value parameterl .valuel is set at 19 (degrees Celsius). Therefore, in this example, if the temperature as measured by the thermostat drops below 19 (degree Celsius) the action is taken. The actions are the instructions to the system being controlled by the control system 100 if the logical condition is fulfilled. In this example, the action involves setting a heater system “group.heaters” to a value of “19” (degrees Celsius). Both the conditions and the actions include “target” devices These are the devices that are being used by the policy management sub-system either to determine whether a condition is met or to implement the action. In the above example, to determine whether the temperature condition is met, the target device is the “system.thermostat” and to implement the resulted action the target device is the “group.heaters”. At step 606, the JSON policy is transmitted (e.g., to the policy handler 302) for further analysis to detect whether there are any policy conflicts. At step 608, the JSON policy is parsed (e.g., using the parser 406). The JSON policy may be parsed into a code object to verify that it is a valid policy. This involves breaking the policy down into its constituent features and confirming that all features are present and valid. The constituent features of the policy may include what devices the policy is acting on, or what categories of devices the policy is acting on. The devices the policy acts on may include both the devices that are used to detect whether a condition has been met (such as sensors, e.g., temperature sensors in a building management system) as well as the devices that are used to implement the action of the policy (such as heaters or air conditioners in a building management system). The categories of devices may refer to a type of device (for example, heaters, air conditioners and temperature sensors may all fall within an “HVAC” category in a building management system) or the categories may refer simply to a sub-set of devices that have a common characteristic (such as a common location). The constituent features of the policy may also include what the conditions of the policy are and what the actions of the policy are. The constituent features of the policy may also include the parameters of the policy (such as the parameters of the conditions, e.g., a threshold value for a measured parameter, and the parameters of the actions, e.g., the target value for a parameter) and the logical relationships embodied by the policy (e.g., a parameter being less than a threshold value). At step 610, the constituent features of the policy are extracted into a data file 611 storing the policy features in a useable format for cross-referencing to take place. For example, at this step, the features of the policy may be converted from JSON format to array format (e.g., JavaScript array). The extracted features may include: the device(s) / category acted on by the policy, the condition for the policy and the parameters of the conditions, and / or the actions of the policy and the parameters of the actions. The features may be extracted into a single data file, or separate data files for each feature or for groups of the features. At step 612, existing policies are retrieved. This involves searching in a policy database 614 (which may be the database 402) for current policies which include features that are also present in the new policy and retrieving those current policies from the database. For example, the exemplary JSON policy set out above acts upon the “system.thermostat” and “group.heaters” devices as part of the action of the policy. In this example, step 612 may involve searching in the policy database 614 for any policies that also act on either one of the “system.thermostat” or “group.heaters” devices and retrieve them from the database. The exemplary JSON policy set out above also includes “19” (degrees Celsius) as a parameter of the condition (i.e., the threshold temperature below which the action will be implemented). In this example, 612 may involve (additionally or alternatively) searching the policy database 614 for policies having actions that are implemented when based on a measured temperature and retrieving such policies from the database. At steps 616 and 618, the policy features extracted from the new policy are cross referenced against the policy features of the existing policies retrieved from the policy database 614. At step 616, the conditions of the new policy are cross checked against the conditions of the existing policies retrieved from the policy database 614. For example, for a building management system, where the condition of a policy relates to comparing a temperature measured in the building to a threshold temperature value, this step may involve cross checking whether there is any match or overlap between the conditions of the new policy and the conditions of any of the existing policies retrieved from the database 614. Existing policies having conditions which do not match or overlap with the conditions of the new policy, may be filtered out at (or just after) step 616 and excluded from further analysis. Taking the example of a building management system, a new policy may involve the logical condition of checking whether the temperature in a building is less than 19 (degrees Celsius) on a weekday (Monday to Friday). An existing policy may involve checking whether the temperature in a building is less than 19 (degrees Celsius) on a weekend (Saturday and Sunday). The existing policy may be identified and retrieved from the database because it acts on the same devices as the new policy (e.g., temperature sensors and heaters) or because it relates to a measurement of the same type of parameter (a temperature). However, at step 616, it will be determined that there is no match or overlap between the conditions of the new policy and existing policy because they relate to different times; since the policies therefore cannot possibly give rise to any conflict, the existing policy is filtered out from further analysis. Existing policies having conditions which do match or overlap with the conditions of the new policy, may be taken forward for further analysis at step 618. Taking again the example of a building management system, a new policy may involve the logical condition of checking whether a temperature in a building is within a range (for the purposes of activating heating) and an existing policy may involve checking whether the temperature in a building is within another range (for the purpose of activating cooling, such as air conditioning) which overlaps with the range of the new policy. The existing policy may be identified and retrieved from the database because it acts on the same devices (e.g., temperature sensors) or categories of devices (heating, ventilation, and air conditioning (HVAC)) as the new policy, or because it relates to measurement of the same type of parameter (a temperature). In this example, at step 616, it will be determined that there is a match or overlap between the conditions of the new policy and existing policy because there is an overlap in the temperature ranges of the conditions of the two policies. Thus, the existing policy will be taken forward for further analysis in step 618. At step 618, the actions of the new policy are cross checked against the actions of the existing policies retrieved from the policy database 614 to identify any conflicting actions. Taking the example set out in the previous paragraph, at step 618 it will be determined that there is a conflict between the new policy and the existing policy because in the overlapping portion of the temperature ranges of the two policies, the existing policy would be activating the air conditioning while the new policy would be activating the heating, which are conflicting actions. At step 620, when a conflict between the new policy and an existing policy is detected, an alert is raised. This may be, for example, displaying on the display of the user interface a message indicating that the new policy conflicts with an existing policy. The alert may also provide details of the existing policy with which a conflict has been detected. The alert may also provide details of the features of the new and / or existing policy which are in conflict (i.e., the condition, or the action, or the parameter for example). If no conflict is detected, for example because there is no match or overlap between the conditions of the new policy and any existing policies, or because insofar as there is a match or overlap the actions of the new policy do not conflict with the actions of the existing policies, the new policy is approved and the policy database 614 is updated at step 622 to store the new policy in addition to the existing policies. If there is a conflict, but the conflict is resolved (such as by a user amending the new or existing policy to remove conflict), the new policy is stored in the policy database along with any amendments and / or the existing policy is updated to reflect any amendments. The preceding description relates to the procedure for identifying policy conflicts at the time that a policy is created and added to the policy management sub-system. However, the disclosure may also enable detection and resolution of run-time conflicts. Run-time conflicts occur when two policies are not conflicting at the time they are created, but at the time one of them needs to be implemented they then do conflict. In the event of a run-time policy conflict (which may be detected in the same way as for a creation-time conflict as described above), the policy management sub-system will seek to resolve the conflict if a clear pathway is given, such as if one of the conflicting policies has higher priority. If such a resolution is not possible, a user may provide input to manually resolve the policy conflict. Anomaly detection Figure 7 is a diagram showing the logical architecture of an anomaly detection sub-system 104a. The anomaly detection sub-system 104a is communicatively coupled to a central orchestration server 702. The central server 702 may also be communicatively coupled to at least one further anomaly detection sub-system. In this example, the central server 702 is communicatively coupled to a second anomaly detection sub-system 104b and a third anomaly detection sub-system 104c. The description of the logical and functional architecture of the first sub-system 104a which follows below applies equally to the architecture of the further sub-systems 104b, 104c. The anomaly detection sub-system 104a comprises a local data store 704 which receives and stores data to be checked for anomalies. The data store 704 may also store additional information, such as data related to anomalies detected, machine learning models for determining whether data is anomalous, machine learning training data for the models, test data, trusted nodes, and cryptographic keys. In the example where the control system 100 is used to implement a building management system, the data to be checked for anomalies may be sensor data from the sensors in the building, and the data store may be used to store the sensor data. An anomaly detection module 706 analyses data to detect anomalies contained within the data. The anomaly detection module is coupled to a machine learning detection engine 708 which provides the machine learning models (in this example, reinforcement learning models) used to classify data as anomalous or not anomalous. A local machine learning training engine 710 is also provided which carries out training of the machine learning models based on training data local to the sub-system 104a. The local machine learning training engine 710 provides the machine learning training functionality within the subsystem 104a. That is, the reinforcement learning algorithm being trained on the collected data stored in the local data store. An anomaly detection sub-system (such as sub-system 104a) would be coupled to each source of data coming into the overall policy-based control system 100. In this way, the anomaly detection sub-systems act as edge nodes in the control system 100. For example, when the system 100 is used to implement a building management system as previously described, each sensor device in the building which sends data to the control system 100 will have an associated anomaly detection sub-system to monitor the sensor data and detect anomalies. Each sub-system maintains a secure local storage 704 of the data to be checked for anomalies and uses this data to continually train and reinforce their learning. These training results are then securely shared with neighbouring sub-systems as described below to improve anomaly detection decision making. The anomaly detection sub-system 104a may also comprise a management system (not shown) which handles the sub-system’s services and functionality. That is, if commands come in to retrain, the management system can facilitate the retraining, and likewise if a consensus ensemble needs forming the management system can arrange this. It also provides a means to communicate its results with the central orchestration server. Figure 8 is a diagram showing the logical architecture of the central orchestration server 702 of the anomaly detection sub-system 104a. The central orchestration server 702 has a global data store 804 which receives and stores data from the various anomaly detection sub-systems to which the server is connected. For example, the global data store 804 may store data related to anomalies detected by the anomaly detection sub-systems, global machine learning models for determining whether data is anomalous, and global machine learning training data for the models. The server 702 runs a global machine learning training engine which coordinates and shares training of the various connected anomaly detection sub-systems. The server comprises a communication module 808 which handles communication between the server 702 and the connected anomaly detection sub-systems. The communication module 808 is responsible for providing the anomaly detection sub-systems with the means to exchange data as and when needed, such as commands from the central orchestration server to retrain or sending / receiving anomaly data to trusted anomaly detection subsystems. This will also feature encryption and decryption services. A user interface 810 (such as a graphical user interface) is also provided to enable a user to interact with the server 702, for example to configure the anomaly detection sub-systems, the machine learning engine or machine learning models. The user interface provides the system with a reporting mechanism for the anomaly detection sub-system so a user can see the various anomaly detection sub-systems and their status, highlighting whether a subsystem is in training, or detecting an anomaly, or seeking consensus from the other subsystems. Figure 9 is a diagram showing a high-level overview of the functional architecture of the anomaly detection sub-systems. In this example, two anomaly detection sub-systems 104a, 104b are shown. Each of the anomaly detection sub-systems receives data from devices in a policy-based system. For example, when the policy-based system is a building being controlled by the control system 100, the devices may be various sensors located in the building, such as temperature sensors, humidity sensors, gas concentration sensors, lighting sensors, and energy usage sensors. The anomaly detection sub-systems represent edge nodes in the policy-based control system 100 because they act as gateways for information coming into the control system 100 from the system it is controlling. The anomaly detection sub-systems monitor the data they receive for anomalies. The anomalies may relate to security infringements (for example, malicious network traffic being transmitted into the control system 100 via these edge nodes) or the anomalies may relate to the performance of devices within the system being controlled (for example, data indicative that a device in the system is failing and requires maintenance). Each anomaly detection sub-system uses local machine learning detection engines (e.g., engine 708) trained by local machine learning training engines (e.g., engine 710) to classify data as anomalous or not anomalous. In this example, the local machine learning engines use reinforcement learning models. In some instances, the anomaly detection sub-systems may receive data which, according to their models and training, is on a borderline between being classified as anomalous or not anomalous. In such cases, one anomaly detection sub-system may request support from sibling sub-systems (i.e., other anomaly detection sub-systems in the control system 100) to help determine how best to classify the data. In this case, a first anomaly detection subsystems 104a contacts at least one other anomaly detection sub-system 104b to form a consensus ensemble 902 to generate a consensus decision 904 using the combined local training of the sub-systems. The consensus decision is then used by the first anomaly detection sub-system to classify the data. The operation of the anomaly detection sub-system is described below with respect to Figure 10. In summary, during initialisation and training, an anomaly detection sub-system is initialised and assigned a unique identifier for the purposes of tracking and management. The machine learning training engine of the sub-system is configured and parameters relating to training such as batch size, and learning rate are defined. The sub-system then collects data samples from the network environment and stores them in the local data store, for training. The machine learning training engine then proceeds to perform feature engineering on the data collected. The sub-system then begins to learn on the extracted data features collected in the previous step. The management system can evaluate the subsystems reinforcement learning model efficacy once it has completed training, including by determining an F1 score. This F1 score will then be communicated via the communication service to the central orchestration server, which can keep track of all the sub-systems’ scores. Following the model evaluation, provided it is successful, the sub-system will then be deployed for anomaly detection. The sub-system can be monitored via the user interface which will alert users when an anomaly is detected. In some cases, the sub-system will encounter data that is on the border of being considered an anomaly, and struggles to classify it, so it seeks a consensus with the other sub-systems. This consensus mechanism is managed by the management system, which issues the command to multicast a request for a consensus ensemble to other trusted anomaly detection sub-systems. If the other sub-system(s) accept the request, those other subsystem then run the data through their own anomaly detection algorithms and return their results back to the original sub-system, which takes an average of the values presented back to it and makes a final decision on the anomaly. This procedure will now be described in more detail. Figure 10 is a diagram showing in more detail the functional architecture of the anomaly detection sub-systems. In particular, Figure 10 shows how an anomaly detection sub-system can share data with a trusted sibling sub-system to form a consensus ensemble to increase the confidence in its anomaly classification. Figure 10 shows a first anomaly detection sub-system 104a and a second anomaly detection sub-system 104b which is a trusted sibling of the first. While only one sibling sub-system is shown, it should be understood that the first sub-system may contact a plurality of subsystems for support and the description of the functionality of the sibling sub-system applies equally to any of the plurality of sub-systems providing support to the first. At step 1002, the first anomaly detection sub-system 104a receives incoming data from a device of the system being controlled by the policy-based control system 100. For example, where the control system 100 is implemented as a building management system, the data may be a stream of data from a sensor in the building. The sub-system 104a analyses the data, including for example monitoring the data using machine learning models, detecting anomalies, and performing data processing, such as cleaning and aggregation. The first anomaly detection sub-system 104a classifies the data, according to its local machine learning models and local training, as being either anomalous or not. If the classification of an anomaly by the first sub-system 104a is within a defined threshold (e.g., confidence threshold), at step 1004 the first sub-system 104a requests support from sibling anomaly detection sub-systems to increase confidence in its classification. In this example, a second anomaly detection sub-system 104b provides the support, but in other examples multiple sibling sub-systems may each provide support. At step 1006, the first sub-system 104a securely transmits data to the sibling sub-system (e.g., directly, or via a central server such as the central orchestration server 702). In some examples this data is the raw data that was received by the first sub-system. In other examples, the data may be modified in some way (for example, the data may be modified to include data relating to the classification that the first sub-system made (or would have made) before requesting support) or the data may be information derived from the raw incoming data received by the first sub-system (for example, the data transferred to the sibling sub-system may relate to features extracted from the raw data received by the first sub-system). At step 1008, a record of the data transferred from the first sub-system 104a to the sibling sub-system 104b is stored locally by the first sub-system as reference data. Whenever data is transferred between the sub-systems (e.g., steps 1006, 1008, 1010, 1018, and 1020), the data may be stored with information for future use, such as routing tables, cryptographic keys, etc. At step 1010, the data is received by the second (i.e., sibling) sub-system 104b, and at step 1012 a record of the data received by the second sub-system 104b from the first sub-system 104a is stored locally by the second sub-system as reference data. At step 1014, the sibling sub-system 104b analyses the data it received from the first subsystem 104a. The analysis may be the same analysis performed by the first sub-system at step 1002 (i.e., including monitoring the data using machine learning models, detecting anomalies, and / or performing data processing, such as cleaning and aggregation). At step 1016, the sibling sub-system classifies the data as being either anomalous or not anomalous, according to its local machine learning models and local training. (The classification decision made by the first and second sub-systems 104a, 104b is also referred to herein simply as the ‘decision’). At step 1018, the classification decision of the second (sibling) sub-system 104b is transmitted securely back to the first sub-system 104a. This may be a simple output of the classification result, or it may include metadata relating to the parameters of the sibling’s machine learning models (e.g., weights) or the local training data of the model which caused the classification to be made. A record of the data transferred back from the second subsystem 104b to the first sub-system 104a is stored locally by the second sub-system 104b as reference data at step 1019. At step 1020, the data is received by the first sub-system 104a, and a record of the classification (and any associated data) received by the first sub-system 104a from the second sub-system 104b is stored locally by the first sub-system as reference data at step 1021. At step 1022, the first sub-system 104a assimilates the data received from the sibling sub-system(s) 104b. In this example, the data received from the sibling sub-system comprises (or consists of) a decision relating to the classification made by the sibling. At step 1024, the first sub-system 104a analyses the decisions made by the other sibling sub-system(s) 104b. This involves analysing the supporting siblings’ decisions and assessing them against the level of trust associated with each sibling sub-system. For example, the first sub-system may assign weights to the decisions made by the sibling subsystems and may generate a weighted average decision. The weights may correspond to the relative level of trust associated with each sibling sub-system. The level of trust associated with each sibling sub-system may be determined, for example, by the position of the sibling sub-system in the network, the amount of training the sibling sub-system has received, and / or the historic quality of decisions made by a given sibling sub-system. At step 1026, the first sub-system 104a makes a final decision as to the classification of the data based on its own classification (i.e., from step 1002) and based on its analysis of the assimilated decisions of the sibling sub-systems. Once a final decision has been made, a user of the control system 100 may be alerted to the anomaly, for example by way of information presented to the user via an interface (such as user interface 810). This provides the user with enhanced situational awareness and improved operational oversight, enabling improved data-driven decision making. The anomaly detection sub-systems described above give rise to a number of advantages. In particular, it provides the advantages of edge computing (including decentralised data storage, because each anomaly detection sub-system locally stores the data it is checking for anomalies) but enables the anomaly detection sub-systems to extend their anomaly detection mechanism to form a consensus ensemble, utilising their shared experience, which allows them to come to decisions on data that is more difficult to analyse and would typically either be incorrectly dismissed or raised as an alert. This consensus mechanism may enable smaller anomalies to be captured and reported and reduces the potential of false alerts being raised. Network communication Figure 11 is a diagram showing the logical architecture of the communication network subsystem 106. In the policy-based control system 100, each of the anomaly detection sub-systems 104 and the policy management sub-system 102 may have an associated communication network sub-system 106. The communication network sub-system together with its associated subsystem forms a node in a network, such that the communication network sub-systems enable networked communication between the anomaly detection sub-systems and the policy management sub-system(s). The term “node” is used to refer to a node in this network; generally, a communication network sub-system acting with or on behalf of another sub-system (such as an anomaly detection sub-system or policy management sub-system). The communication network sub-system includes a discovery module 1102. The discovery module is used when a new node is introduced into the network to discover details of other nodes in the network, and to assess their trust and reliability. The discovery module finds the new nodes and services within the network. This occurs through the broadcast, or multicast, of a messenger signal as described below. The response to this messenger signal is then logged within the node’s data store. A user interface 1104 is also provided to enable a user to interact with the network, such as to manually establish connections between nodes in a network if none have automatically been established. The user interface shows the state of the node, connected nodes and relevant data, also the services that have been registered as being available on this node. A routing module 1106 is provided to analyse routing tables and establish routing pathways through the network for subsequent communication in the network. The routing module calculates the appropriate pathway forthe data to go down. It could be the path of least time, or the path of highest security. A datastore 1108 is provided to enable the other modules to store reference data. For example, the discovery module 1102 may use the datastore to store details of other nodes in the network, and the routing module may use the datastore to store routing tables received from other nodes. The datastore holds the information relating to the node’s unique identifier, its address within the network, the routing tables, and service tables, and the keys used for cryptographic activities. An encryption module 1110 and a decryption module 1112 are provided to establish secure tunnels (i.e., secure, encrypted connections) for information transfer between the nodes of the network. The encryption module provides the encryption functionalities to secure communication channels and data transmission within the network. Its primary task is to encrypt data using cryptographic algorithms to ensure the confidentiality of sensitive information. The decryption service block is responsible for providing the decryption functionalities to the network nodes. Its primary task is to decrypt data using the reverse of the cryptographic algorithms. In addition to the modules shown in Figure 11, the communication network sub-system may also include a communication module, management module, and service board. The communication module physically sends the data via the appropriate network protocol, depending on the requirements of the receiver node. The communication module is also responsible for the broadcast and multicast services used to disseminate information to multiple neighbouring nodes at once, and for prioritising and managing network traffic based on the quality-of-service requirements, ensuring that critical messages receive the bandwidth and reliability they need. The communication module is also responsible for the error handling of data streams to mitigate against data loss. The communication module sends and receives data in IP format. The management module is responsible for the management of the node and its services, this includes keys, and data within the data store. It is responsible for managing the node discovery module and keeping track of the trust scores of the neighbouring nodes. The service board is responsible for displaying a list of the node’s services or microservices, so other nodes can access it to find additional functionality within the network. It could be that one node has access to an external API and another node needs information from it, so it can find the node with the API access and can get the information it requires. Figure 12 is a diagram showing the functional architecture of the communication network sub-system. In particular, Figure 12 shows the procedure followed by a node newly placed into the communication network to establish new connections and to assess the trust and reliability of existing nodes in the network. At step 1202, the newly added node broadcasts its node details to the network (i.e., to the other nodes connected within the network). The node details 1204 may include at least a unique identifier for the new node (such as a unique number) and an address for the new node in the network. The broadcast may include a messenger signal which will inform existing nodes in the network of the new node’s presence. The messenger signal may be broadcast or multicast via all communication pathways in the network. The broadcast messenger signal will request the other nodes in the network to respond with their own unique identifiers and addresses. The messenger signal has two functions: firstly, to allow the formation of a network by allowing nodes to find each other and locating potential new nodes; and secondly, to assess the other nodes trust when the network has been established. In the first instance, the messenger signal will be a data packet that contains the following information: • Node Identifier - The sender’s unique identifier and address within the network. • Node Information - Information relating to their neighbouring nodes such as a routing table, their services, and their encryption standard. • Quality of Service Requirements - Messenger signals may include Quality of Service requirements / preferences for communications, such as bandwidth and encryption standard. The messenger signal may be a JSON formatted message that provides the information above. This information will enable nodes to add each other to their routing tables, with the relevant Quality of Service information, so that the network can keep an accurate topological map of where data can be sent, given some constraints. Nodes will respond to messenger signals so that the sender can keep a track of the node’s reliability and response times. In the second instance, messenger signals will be of the same format, except the nodes will already be known to each other, so it will only require a simple response from the receiving node to acknowledge the messenger signal, and respond with any updates to the node, such as new neighbours, or bandwidth constraints, etc. At step 1206, the new node receives the responses from existing nodes and tracks their response times. Nearby nodes respond to the messenger signal with their identifier, address, services, and routing tables. These nearby nodes then add the initial node into their routing system, with a preliminary trust score. The nearby node responses are then sent back to the initial node, which captures all the incoming information in its routing system and data store, so it can begin mapping the topology of the network. The response to the messenger signal is used to generate the preliminary trust score, as characteristics of the response may be indicative of the trustworthiness of a node. In particular, the following factors may be taken into account when determining the preliminary trust score: • There is a timeout period set for response returns; if a node does not return its response within this timeframe, it will receive a lower score. • Level of TLS for initial secure tunnel establishment will be used. If a Node has 1.1 TLS, or 1.2 TLS, then they will have a lower trust score than if they had 1.3 TLS. • Version of software the node is running: if a first node has a more up to date version of software compared to a second node, the first node will lower its trust score of the second node. • Geographical Location of the node. At step 1207, the new node may store a local record (e.g., in its local datastore 1108) of the responses received from the existing nodes, including the unique identifiers and addresses of the existing nodes in the network, and optionally also a record of the response times for each node. At step 1208, the new node establishes a formal connection to the existing nodes in the network, for example using the unique identifiers and addresses received at step 1206. At step 1210, the new node establishes secure tunnel(s) with the existing nodes in the networks. The secure tunnel(s) are established using the encryption module 1110 to establish a means for secure information transfer with the existing nodes. At step 1212, the new node requests state details from the existing nodes in the network. The state details 1214 may include for example, the encryption level of each node and / or the software version used by each node. At step 1216, the new node stores the state details it received in its local datastore. The details stored in the datastore may also include information for future use, such as cryptographic keys. At step 1218, the new node requests routing tables from the existing nodes in the network, along with the associated trust scores for each node in the table. When a node interacts with another node for the first time, it will have a default trust score of (for example) 0 / 50. Then, based on predefined rules for calculation (which can be controlled via the user interface), the node will add points depending on the available cipher suite version and age, response time, software version etc. When a new node joins the network, it will adopt existing routing tables received from the other nodes, along with the trust score associated with each node, to begin networking. Thereafter, the new node will start to adjust its trust score for each other node based on the interactions it has with the nodes in the network. At step 1219, the new node stores the routing tables for future use. In particular, a new node will adjust its trust score for each other node in the network based at least in part on the responses received from the existing nodes in the network at step 1206 and the state details 1214 (e.g., encryption level and software version) received from the existing nodes at step 1212. Figure 13 is a flowchart showing the procedure for a communication network sub-system deciding a routing path in the network. This procedure is used by a node once it has joined the network and completed the procedure described above with reference to Figure 12. At step 1302, the node receives a request for information to be sent from the node to a destination node in the network and analyses the request. In particular, the node analyses details relating to where the information is being sent (for example, the location of the destination node in the network). At step 1304, the node analyses the routing tables it has stored. This may include a step 1306 of retrieving stored routing tables from the datastore. The node cross-references the routing tables to determine possible paths through the network which will enable the information to be sent to the destination node. The potential paths may include information associated with characteristics of the paths, such as the speed of the path and the security level of the path (the security level of the path being determined by the trust scores of the nodes along the path, since the trust score of each node is at least partly determined by the encryption level of the node). The potential paths identified by the analysis of the routing tables may then be stored in the local datastore for future reference. At step 1308, the node decides on the most optimal path for the information to be sent on to reach the destination. The decision as to which path is optimal may be based at least in part on the type of data being transmitted. For example, if the data is needed urgently and is not particularly sensitive, it may be sent via the fastest route through the network, even if such a route would involve passing the data through nodes with lower trust scores. In another example, if the data is sensitive, it may be sent via the fastest route through the network which avoids nodes with trust scores below a threshold value. At step 1310, the node transmits the data through the network along the path decided at step 1308. When data is transferred through the network using the above procedure, the data is encrypted by the encryption module before sending. The encrypted data is handed to a communication module (not shown) which divides the data into discrete data packets which contain additional information such as source and destination addresses, sequencing information, and error checking codes. The destination of the data is then passed to the routing module which identifies the best path from point A to point B using the routing tables with considerations of constraints on security and reliability, as described above. The routing path is then handed back to the communication module. The encrypted data is then passed through the secure tunnel to the appropriate nodes along the routing path. If the data must go through intermediate nodes, these will view the metadata, highlighting the destination of the data, but will not get to see the encrypted data packet. These intermediate nodes can dynamically evaluate the path to point B from where they are, to ensure the data is transferred in the most efficient manner possible, given the dynamic nature of networks (for example the optimal onward path from the intermediate node to point B may be changed since the packet was dispatched from point A). The encrypted data finally arrives at the intended destination node, which can then store the information and decrypt it using their data stores and decryption services, delivering it to the end user, device etc. The routing of data is conducted through a routing tree method, where paths are calculated prior to data being sent to the target system, this involves passing data from one node to another until it reaches a destination, if during transit a node in the defined path fails then the route is recalculated at the current node and rerouted through this new path. Policy-based control system Figures 14 and 15 are diagrams showing, in combination, the wider functional architecture of an anomaly detection sub-system 104a and a policy management sub-system 102. Referring first to Figure 14, at step 1402 the anomaly detection sub-system 104a receives data to be checked for anomalies. In the example where the control system 100 is used to implement a building management system, the incoming data may be sensor data from sensors located in the building. The anomaly detection sub-system performs pre-processing on the data, such as normalisation, cleaning, and aggregation. At step 1404, the data is analysed to identify features, parameters, and patterns in the data. This analysis step may be the same as the step 1002 described with reference to Figure 10. At step 1406, a local picture is generated. The local picture is based on data flowing through the particular anomaly detection sub-system 104a. At step 1408, the local picture for the sub-system 104a is stored for future reference. At step 1410, the sub-system 104a detects anomalies in data packets. In some cases, the anomalies are detected by comparing data packets to the local picture obtained at step 1406. At step 1412, the sub-system 104a analyses the anomalies detected at step 1410. This involves determining why the data is anomalous (i.e., which features of the data are anomalous in comparison to the local picture). At step 1414, the sub-system 104a communicates with a sibling anomaly detection subsystem 104b to resolve any cases in which the sub-system 104a requires additional confidence of its classification of data, or to resolve any cases where the classification of the data is within a threshold (i.e., a borderline case). This step may be the same as the steps 1006 to 1026 described with reference to Figure 10. The data is then transferred, including data relating to any anomalies detected in the data, via communication network sub-systems, to a policy management sub-system. Referring now to Figure 15, the data transferred from the anomaly detections sub-system 104a, via communication network sub-systems, is received by a policy management subsystem 102. At step 1502, the policy management sub-system 102 aggregates the data that is received from all of the various anomaly detection sub-systems, of which the anomaly detection subsystem 104a in Figure 14 is just one. At step 1504, the policy management sub-system generates a global picture. The global picture is based on the data flowing through all of the connected anomaly detection subsystems. At step 1506, the global picture is stored for future reference. The sub-system 102 may also store local data referring to how responses to anomalies should be formulated. The local picture, in the context of the anomaly detection sub-systems, refers specifically to the local data flows a sub-system experiences, and what is considered normal there. For each anomaly detection sub-system, this will be different, depending on what they are monitoring. For example, an anomaly detection sub-system associated with sensors might have several sensors measuring the same source (e.g., multiple temperature sensors measuring the temperature in the same room). On a local level, each anomaly detection sub-system will report an anomaly in its respective sensor data, but in the global picture these anomalies will be assimilated to show that they represent a single anomaly. The system being controlled by the policy-based control system will include disparate devices with a range of different data types and parameters. The global picture is the assimilated, unified view of everything that is going on in the given operational environment. It provides a means to place the disparate devices into a common context, which forms part of the global picture. This common context makes it significantly easier to implement policies across a system, without the need to worry about different data types, or parameter units etc. As a simple example, one device might use Celsius and another may use Fahrenheit, so ensuring continuity between these two units is paramount for operational efficiency. At step 1508, the policy management sub-system 102 makes a decision as to whether any policy conditions are triggered by the anomaly received from the anomaly detection subsystem and decides on the action to take. At step 1510, any actions implemented by any triggered policies are implemented by the policy management sub-system 102. Depending on the conditions of the policy, and the environment of operation, the action of the policy may be triggered either by the data itself, or by the act of identifying an anomaly in the data. Separately, at step 1512, a user may create a new policy or update an existing policy on the policy management sub-system 102 (for example by interacting with a graphical user interface), and these policies or policy updates are received by the sub-system 102 at step 1514. The sub-system 102 manages the policies at step 1516 to ensure that there are no policy conflicts, and to resolve any conflicts that do arise. This step 1516 may involve the procedure described above with reference to Figure 6. Not shown in Figures 14 and 15 is the architecture of the communication network subsystems. However, the communication network sub-systems as described above are used to facilitate the transfer of information from the anomaly detection sub-system 104a to the policy management sub-system 102 as indicated in Figure 14. In more detail, the communication network sub-system associated with any anomaly detection sub-systems will continually collect and assess details of neighbouring nodes (e.g., neighbouring anomaly detection sub-systems, policy management sub-systems, or other network devices), and decide paths for the transmission of information across the network such that information can be routed across the network in the least time (subject to any security considerations). The path by which one node sends data to another node is based on the node’s analysis of its neighbouring node’s reliability and trust, as described above, to decide the most optimal path for the transmission of information. This may include constraints other than speed, such as security classification. Alternatives and modifications The present invention has been described above occasionally with reference to how the invention could be used to implement a building management system. It should be noted for completeness that this exemplary implementation is discussed only to enable the invention to be understood more clearly, and other implementations of the invention are envisaged. For example, the policy-based control system disclosed herein could also be used to control autonomous vehicles. In this case, the system being controlled would be a vehicle (such as a car) having sensors to detect information about the environment in which the vehicle is travelling, and systems to control movement of the vehicle (e.g., propulsion, steering, etc.). The anomaly detection sub-systems would be used to monitor data from the sensors to detect anomalies and would share its training with other anomaly detection sub-systems (in the vehicle, or in other vehicles implementing the same control system). The policy management sub-system would receive data from the anomaly detection sub-systems and implement actions to control the movement of the vehicle depending on the conditions and actions defined in the policies stored in the policy management sub-system. The communication network sub-systems would facilitate communication between the other subsystems. Other exemplary systems including an adaptive communications system for controlling communications between, for example, radios and routers. It will be understood that the invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention. Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1. A method of policy management in a policy-based control system, the policy-based control system storing a plurality of policy data files recording policies for the policybased control system, the method comprising:extracting from a first policy data file features of the first policy, the features comprising at least at least one target device of the first policy and at least one condition of the first policy;determining, based on a comparison between the target device and condition extracted from the first policy, and target devices and conditions of the plurality of stored policy data files, a conflict between the first policy and at least one of the stored policies; andoutputting an alert to a user.

2. A method according to Claim 1, comprising generating the first policy data file based on a user input via a user interface.

3. A method according to Claim 2, wherein the user input comprises:a user entering the policy, or features of the policy, in plain text; and / ora user selecting, via the user interface, features of the policy, wherein the features of the policy comprise one or more of: at least one parameter; at least one threshold; at least one comparison operation; and at least one action.

4. A method according to Claim 2 or Claim 3, wherein the first policy data file is generated in JavaScript Object Notation (JSON) format.

5. A method according to any preceding claim, wherein extracting the features of the first policy comprises parsing the first policy data file.

6. A method according to any preceding claim, wherein extracting the features of the first policy comprises generating an array object, preferably a JavaScript or JSON array, the array comprising the extracted features of the policy.

7. A method according to Claim 6, wherein the comparison is between the generated array object and a plurality of other array objects generated from the plurality of stored policy data files.

8. A method according to any preceding claim, wherein the extracted features of the first policy also comprise a category of the target device of the first policy.

9. A method according to any preceding claim, wherein determining a conflict comprises, first, comparing the target device extracted from the first policy and the target devices of the plurality of stored policy data files to identify a sub-set of the plurality of stored policies that act on the same target device.

10. A method according to Claim 9, wherein determining a conflict comprises, second, comparing the condition extracted from the first policy and the conditions of the subset of the plurality of stored policy data files to identify potentially conflicting policies that have conditions overlapping with the extracted condition of the first policy.

11. A method according to Claim 10, wherein determining a conflict comprises, third, determining, preferably according to hardcoded rules, which of the potentially conflicting policies have actions that conflict with an action of the first policy.

12. A method according to any preceding claim, comprising receiving user input to select one of multiple conflicting policies to be implemented in preference to the other conflicting policies to resolve a conflict.

13. A method according to any preceding claim, comprising receiving user input to amend a feature of at least one of multiple conflicting policies to resolve a conflict.

14. A method according to any preceding claim, comprising determining a priority associated with one of multiple conflicting policies, and implementing the highest priority conflicting policy in preference to the other conflicting policies to resolve a conflict.

15. A method of anomaly detection in a policy-based control system, the method comprising:monitoring, using a first anomaly detection system, a first data stream, the first anomaly detection system configured to classify data in the first data stream as anomalous or not anomalous based on a first trained model local to the first anomaly detection system;monitoring, using one or more further anomaly detection systems, one or more further data streams, the one or more further anomaly detection systems configured to classify data in the one or more further data streams as anomalous ornot anomalous based on further trained models local to each respective further anomaly detection system; andfor a classification made by the first anomaly detection system which is within a confidence threshold:transmitting to the further anomaly detection system(s) the data on which the classification was based; andclassifying, by the further anomaly detection system(s), the data as anomalous or not anomalous based on the further trained model(s), re-classifying, by the first anomaly detection system, the data as anomalous or not anomalous based at least in part on an assimilation of the classifications made by the further anomaly detection system(s).

16. A method according to Claim 15, wherein the assimilation comprises computing a weighted average of the classifications made by the further anomaly detection system(s), wherein the classifications are weighted according to a level of trust associated with each further anomaly detection system.

17. A method according to Claim 15 or 16, wherein each anomaly detection system comprises a local data store configured to store local training data to train the model of each anomaly detection system.

18. A method according to any of Claims 15 to 17, wherein the models of each anomaly detection system are reinforcement learning models.

19. A method of network communication of data between an origin node and a destination node in a policy-based control system, the method comprising:determining, using routing tables stored by the origin node, potential paths through the network from the origin node to the destination node;determining a trust level for each of the potential paths, wherein the trust level of each potential path is determined at least in part from trust scores associated with intermediate nodes along the path;determining at least one constraint for the data, the at least one constraint comprising a security and / or time constraint;selecting one of the potential paths based on the at least one constraint for the data and the trust level of the potential paths; andtransmitting the data from the origin node to the destination node along the selected path.

20. A method according to Claim 19, comprising the origin node transmitting, preferably by broadcasting or multicasting, a messenger signal to the nodes in the network, wherein the trust scores of the intermediate nodes are determined based on a reaction of the intermediate nodes to the messenger signal.

21. A method according to Claim 20, wherein the messenger signal comprises at least one of:a unique identifier and / or network address of the origin node;information relating to neighbouring nodes in the network; preferably routing tables and / or encryption standards; and quality of service requirements.

22. A method according to Claim 20 or 21, wherein the reaction of the intermediate nodes comprises at least one of:a failure to respond within a time out period;a Transport Layer Security level;a software version for the intermediate node; and a geographical location of the intermediate node.

23. A method according to any of Claims 19 to 22, comprising re-determining potential paths to the destination node and the trust levels of each potential path at intermediate nodes along the path, and re-selecting the path to the destination node based on the re-determination.

24. A policy-based control system comprising at least one of:a policy management system configured to implement the method of any of Claims 1 to 14;an anomaly detection system configured to implement the method of any of Claims 15 to 18; anda communication network system configured to implement the method of any of Claims 19 to 23.

25. A policy-based control system comprising:an anomaly detection system configured to implement the method of any of Claims 15 to 18; anda communication network, system configured to implement the method of any of Claims 19 to 23,wherein the anomaly detection system forms an edge node of the communication network system.38

Images