Background

[0001] The Internet of Things (loT) refers to uniquely identifiable objects in an internet-like structure where the objects are data-enabled and may comprise data sources (e.g. they may be capable of reporting data on a regular, event-triggered or on-demand basis) and/or actuators (e.g. they may be capable of receiving a control instruction and taking an action in response to the control instruction). Equipping all objects in the world with minuscule identifying devices or machine-readable identifiers could transform daily life. For instance, it may improve the growth of plants in a greenhouse by enabling collection of multiple data sources (e.g. air quality inside the greenhouse, weather outside the greenhouse, soil temperature, etc.) and control of watering systems based on the sensed data. However there are a large number of practical challenges in the implementation of loT. These challenges include aspects relating to security of the network, the devices and the data streams and aspects relating to authentication and trust between devices (e.g. a device that provides data and a device that consumes that data). As the number of loT devices increases, the challenges in relation to device discovery and interconnection become more complex.

[0002] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known systems.

Summary

[0003] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0004] Described herein is a method of dynamically and collectively providing a function (which may be referred to as a complex function), such as the functionality of a washing machine or journey monitoring in a transport network, that is performed collectively by a set of independent modules. The independent modules do not communicate with each other but instead receive signals from a virtual asset within a connection brokerage system which corresponds to the complex function. As there is no single real device that corresponds to the complex function (it comprises the virtual asset within the connection brokerage system and its associated agent that may run anywhere), the complex function may be referred to as a ‘cloud machine’. By separating the coordination of the modules from the physical modules themselves, the complex function can easily be upgraded or reconfigured by updating the corresponding virtual asset. Furthermore, the set of independent modules that collectively perform the function may change overtime. Additionally, the complex function may have improved security because it is not implemented as a single device and so is more difficult to tamper with.

[0005] A first aspect provides a method of dynamically providing a complex function performed collectively by a set of independent modules, the method comprising: for one or more of the set of independent modules, receiving data at a corresponding virtual asset in a connection brokerage system and forwarding the data within the connection brokerage system from the virtual assets corresponding to the independent modules in the set to a virtual asset corresponding to a controller of the complex function; and in response to a trigger signal received at the virtual asset corresponding to the controller of the function, sending a sequence of independent control instructions to two or more of the independent modules in the set via their corresponding virtual assets to cause the independent modules to perform their discrete functions according to a sequence and collectively perform the complex function.

[0006] The term ‘discrete function’ is used herein to refer to the function performed by a single module independent of any other modules. As described below, the separate modules operate independently and without communicating directly with each other under the control of the virtual asset corresponding to a controller of the complex function (referred to herein as the controller virtual asset).

[0007] A second aspect provides a system for dynamically providing a complex function performed collectively by a set of independent modules, the system comprising: a connection brokerage system comprising one or more virtual assets corresponding to each of the modules in the set of independent modules and a virtual asset corresponding to a controller of the complex function, wherein the one or more virtual assets corresponding to each of the modules in the set of independent modules are arranged to receive data from the modules and forward the data to the virtual asset corresponding to a controller of the complex function, and the virtual asset corresponding to the controller of the function is arranged to send a sequence of independent control instructions to two or more of the independent modules in the set via their corresponding virtual assets to cause the independent modules to perform their discrete functions according to a sequence and collectively perform the complex function.

[0008] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

[0009] This acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[0010] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

Brief Description of the Drawings

[0011] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[0012] FIG. 1 is a schematic diagram of a first example system comprising a connection brokerage system and a plurality of independent devices which work together to implement complex functionality;

[0013] FIG. 2 is a schematic diagram of a second example system comprising a connection brokerage system and a plurality of independent devices which work together to implement complex functionality;

[0014] FIG. 3 is a flow diagram of an example method of operation of a cloud machine that is implemented within a connection brokerage system such as shown in FIGs. 1 and 2; and

[0015] FIG. 4 is a schematic diagram of a computing device that may run an agent of a virtual asset.

[0016] Common reference numerals are used throughout the figures to indicate similar features.

Detailed Description

[0017] Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0018] As described above, there are a large number of practical challenges in the implementation of loT. As well as problems relating to security, authentication and trust (e.g. where the ownership of different data sources and/or actuators is diverse and/or there are security I safety concerns regarding the data or the actuator control), configuring and managing the large number of deployed devices is difficult, particularly as a consequence of the scale (i.e. the potential number of loT devices that may be deployed). Furthermore, whilst some loT devices may only provide data (e.g. measurement data or other locally generated data), others may include actuators, or control functionality for connected actuators. This means that there is a huge range of capabilities of the deployed devices (e.g. in terms of generating data and/or receiving controls for local actuators).

[0019] In order for an loT device to serve a useful purpose, other devices need to be able to find the loT device and then receive data from the loT device and/or transmit control data to the loT device. A connection brokerage system may be used to broker such connections and in order to broker connections, the connection brokerage system comprises a registrar functionality (which may be implemented as a centralized entity or in a distributed manner) and a plurality of virtual assets. A virtual asset acts as a proxy for a real device (e.g. a physical device such as an loT device that generates data using one or more sensors), a data source (e.g. where the data is not measurement I sensor data), another virtual asset or a group of real devices and/or other virtual assets. Each virtual asset comprises metadata that describes what it is a proxy for (e.g. the real device, data source, group of devices, etc.) along with information about data streams that can be provided by the virtual asset (e.g. wind speed in m/s) and/or can be received by the virtual asset (e.g. on I off or other control signals). Each virtual asset therefore corresponds to a data entry in the connection brokerage system, referred to as a registry entry, that is created when the virtual asset is created. There is a separate agent that corresponds to a virtual asset which drives (or encodes) the behaviour of the virtual asset. The code resides outside the connection brokerage system and may run anywhere (e.g. on a cloud-based server, on the real device itself, or any other computing device located outside the connection brokerage system) as long as it can connect to the virtual asset (i.e. to the data stored in the registry entry for the virtual asset in the connection brokerage system). In this way, the data and code relating to a virtual asset are separate. The agent may act as a bridge between a virtual asset and its corresponding real device (i.e. between the virtual asset and the physical electronics in the device) and may operate to report the state of the real device to the virtual asset and/or to provide a hardware interface to the real device, if the real device is controllable externally (e.g. it comprises or is connected to an actuator). In various examples, there may be an agent that acts as a bridge between each virtual asset and its corresponding real device, although some agents may act as a bridge for more than one virtual asset and/or real device (e.g. there may be fewer agents than virtual assets and/or real devices).

[0020] An loT device registers with the connection brokerage system in order that it can distribute data it generates or in order that it can receive controls for local actuators and on registration, a corresponding virtual asset, and hence registry entry, is created. Such a virtual asset may be referred to as a service providing virtual asset (SP-VA). A device that wishes to obtain data from the system also registers with the connection brokerage system and on registration, a corresponding virtual asset, and hence registry entry, is created. Such a virtual asset may be referred to as a service requesting virtual asset (SR-VA). A physical device may both provide services and request services (i.e. request data and provide control signals) and so may have two (or more) associated virtual assets. In such examples there may be a single agent that acts as a bridge for all the virtual assets associated with a single real device or there may be more than one agent.

[0021] A registrar functionality within the connection brokerage system, which may be implemented as a central server or in a distributed manner, manages the registration of real devices (including identity management), creation of virtual assets and storing and maintaining (e.g. updating when required) metadata about each of the virtual assets in the system. Example registration sequences are shown and described in the following PCT applications WO2015/052478, WO2015/052479, WO2015/052480, WO2015/052481 , WO2015/052482, WO2015/052483 and WO2015/052512 and registration may involve authentication of the real device and creation of the counterpart virtual asset.

[0022] The registrar functionality also brokering connections between virtual assets (including identity management and global search functionality), i.e. the registrar functionality brokers connections between service requesting virtual assets and service providing virtual assets that are already registered in the system. When a connection is brokered between a service requesting virtual asset and a service providing virtual asset, the service requesting virtual asset subscribes to a data feed or control stream of the service providing virtual asset and dependent upon the nature of the subscription either receives the data stream (i.e. the service requesting virtual asset, or its counterpart real device, receives the data stream from the service providing virtual asset or its counterpart real device) or is enabled to provide control signals (i.e. the service requesting virtual asset, or its counterpart real device, can send control signals to the service providing virtual asset or its counterpart real device). Example methods of brokering connections between virtual assets are shown and described in the referenced PCT applications. Once a connection has been brokered by the registrar functionality, the data (e.g. measurement data or control signals) may be transferred without further involvement of the registrar functionality (i.e. any data transfer does not go via the registrar functionality).

[0023] Described herein are methods of using a connection brokerage system as described above to create and collectively control complex functionality using multiple, independent, real (i.e. physical) devices. Each of the modules performs a part of the collective functionality such that the resultant action from the group of modules is the complex functionality. This can be described with reference to FIG. 1 . FIG. 1 is a schematic diagram of a system comprising a connection brokerage system 100 and a plurality of real devices 102, 110, 122 (shown as circles). The connection brokerage system comprises a plurality of virtual assets 104, 106, 108, 124 (shown as rectangles) and a registrar functionality (not shown in FIG. 1) that brokers connections between virtual assets. The registrar functionality may additionally perform other functions as described above.

[0024] As shown in FIG. 1 , the virtual assets 104, 106, 108, 124 exist within the connection brokerage system 100 and the real devices 102, 110, 122 exist outside the connection brokerage system and have counterpart virtual assets 104, 108, 124 within the connection brokerage system. Some or all of the counterpart virtual assets 104, 108, 124 may have a corresponding agent 105, 109, 125 (shown as a diamond) which runs on a computing device outside of the connection brokerage system. Although FIG. 1 shows each virtual asset having a corresponding agent that acts as a bridge to a single real device, in some examples, agents may be shared between virtual assets or may act as a bridge between a virtual asset and more than one real device (e.g. by spawning separate threads for each real device or using re-entrant programming).

[0025] The complex function is controlled by a virtual asset 106 with its corresponding agent 107 (that comprises the control code) being external to the connection brokerage system (i.e. running on a server or other computing device outside the connection brokerage system). The virtual asset 106 that controls the complex function may be referred to as the controller virtual asset. As shown in FIG. 1 , there is no real device that corresponds to the complex function - it comprises the virtual asset 106 (i.e. data) within the connection brokerage system 100 and its associated agent 107 that may run anywhere and hence the complex function may be referred to as a ‘cloud machine’.

[0026] The agent 107 that corresponds to the virtual asset 106 that corresponds to the complex function and collectively controls the individual modules to perform the function may be implemented in a number of different ways. In a first example, the agent 107 may comprise fixed function (e.g. pre-compiled or pre-loaded) code. In a second example, the agent 107 may comprise “dummy” code that loads in and executes pre-compiled instructions, e.g. from a library. This enables selection of different pre-compiled instructions depending upon the circumstances (e.g. dependent upon data received by the virtual asset 106). In a third example, the agent 107 may comprise code that loads in and executes rules based or data driven instructions from a database. Both the second and third examples provide an easily upgradable complex function as new instructions I rules I code can be added to the library I database and loaded in by the “dummy” agent code for execution.

[0027] The complex function is collectively implemented by a group of independent (real, physical) modules 112, with each module 102 in the group 112 having a counterpart virtual asset 104. The independent modules 102 do not communicate with each other and dependent upon the complex function may, or may not, be physically and/or geographically co-located. In an example, the independent modules in the group may all be physically colocated within an appliance (e.g. a home appliance, such as a washing machine); however unlike in a conventional appliance, there is no processor within the appliance that operates the code for the complex function and communicates locally to control the modules contained within it. There may be a processor within the appliance on which the agents 105 for each of the virtual assets 104 corresponding to independent modules 102 in the group 112 run; however, these agents 105 all run independently of each other and the data and control signals do not flow directly between the agents. Instead the data and control signals flow via the connection brokerage system and pass via the corresponding virtual assets 104 and via the virtual asset 106 that corresponds to the complex function (as shown by the arrows in FIG. 1). In another example, the independent modules 102 may be geographically co-located in the same factory but physically spaced around the building. In a further example, the independent modules 102 may be both physically and geographically separated, e.g. a series of sensors and actuators along an oil pipeline that may span many hundreds of miles or geographically dispersed sensors and/or actuators across a number of different transport networks for journey monitoring. The membership of the group 112 may be fixed or may vary over time (as described below). In some examples, the group may comprise a first subset of modules that are permanently in the group and a second subset of modules that are only transient members (e.g. their membership changes overtime).

[0028] As shown in FIG. 1 , the modules 102 (which are real devices) and their counterpart virtual assets 105 communicate via their agents 105. This communication may be unidirectional (e.g. data from a sensor module to the counterpart virtual asset or control signals from the counterpart virtual asset to an actuator module) or bidirectional (e.g. control signals from the counterpart virtual asset to an actuator module and acknowledgements and/or operational data from the actuator module to the counterpart virtual asset). The controller virtual asset 106 has brokered connections with each of the counterpart virtual assets 104 and as a result receives data streams from the counterpart virtual assets and/or can send control signals to those counterpart virtual assets that have such a functionality (e.g. as defined by a service descriptor). As described above the agent 107 for the controller virtual asset 106 executes the code that defines the complex functionality, i.e. it takes as inputs the data streams received by the controller virtual asset 106 from the counterpart virtual assets and generates control signals for some or all of the individual modules as outputs which are then output by the controller virtual asset 106. The group of modules 112 may comprise any combination of sensing modules and actuating modules and some modules may have both sensing and actuating capabilities. Some modules may comprise a plurality of actuators and/or sensors and so may be referred to as machines. The actuators may be of any time including motors, valves, etc.

[0029] As well as receiving data from and sending control instructions to the modules’ counterpart virtual assets 104, the controller virtual asset 106 itself has a service descriptor that indicates it can receive control commands to trigger the execution of the complex function. A service requesting virtual asset 108 can broker a connection with the controller virtual asset 106 and subscribe to this service. As shown in FIG. 1 , this service requesting virtual asset 108 that subscribes to the cloud machine controller virtual asset 106 may have a counterpart real device 110 with which a user can interact to trigger (or otherwise control) the execution of the complex function or the service requesting virtual asset 808 may itself trigger (or otherwise control) the execution of the complex function without user input via a real device (e.g. where the complex function is in fact part of a bigger cloud machine that coordinates and controls the operation of multiple complex functions or where user input is provided indirectly via user interaction with one of the modules 102, such as opening or closing a door which is sensed by a sensing module).

[0030] The controller virtual asset 106 may also have a service descriptor that indicates that it can provide a data stream in relation to performance of the complex function (e.g. to provide progress updates, fault messages, etc.). The service requesting virtual asset 108 may broker a connection to receive the data stream as well as being able to trigger execution of the complex function. In some examples there may be different service requesting virtual assets 108 that broker connections with the controller virtual asset 106 to receive different data streams, e.g. a first service requesting virtual asset may broker a connection to receive the data stream providing progress updates and a second service requesting virtual asset may broker a connection to receive the data stream comprising fault messages.

[0031] The controller virtual asset 106 may take additional inputs from outside the group of modules (and their virtual counterparts). As shown in FIG. 1 , the controller virtual asset 106 may broker connections and receive data streams from one or more other virtual assets 124 (from outside the group 112) and these may also be used as inputs when executing the complex function. These virtual assets 124 may have counterpart real devices 122 (e.g. sensors) or may be synthesizing entities (i.e. entities without a real counterpart that generates a data stream from other data sources). In an example, if the cloud machine is a combined washing machine and tumble dryer, the controller virtual asset 106 may take as an input a data stream of weather data relating to the location of the combined washing machine and tumble dryer group of modules and may only activate the tumble drying part of the complex function if the local weather conditions (as determined from the stream of weather data) meet pre-defined conditions (e.g. if it is raining) in order to reduce the overall energy usage of the household where the modules are located. In an example, to improve I balance energy usage on a larger scale, the controller virtual asset 106 may take as input a usage level from the energy grid (e.g. the electricity grid) and trigger the complex function (based on the grid usage level) when demand is low and/or delay triggering the function when energy demand (from other sources, as determined from the grid usage level) is high. In an example, where one of the modules are powered by renewable energy sources (e.g. solar panels, wind turbines, etc.) the controller virtual asset 106 may take as input weather forecast data and only trigger the complex function based on a determination, using the weather forecast data, that sufficient renewable power will be available to complete the operation of the complex function.

[0032] In addition, or instead, of using these additional inputs when executing the complex function, they may be used in troubleshooting. For example, if the cloud machine is a washing machine, the controller virtual asset 106 may take as an input, sensor data from a water flow sensor on the water input to the building where the washing machine is located. This sensor data may be used in the execution of the complex function (e.g. stopping execution of the complex function if the sensor data indicates that water is flowing) and/or in troubleshooting (e.g. if the complex function does not function as expected, checking the sensor data to determine whether lack of water flow may be a cause). The additional inputs may in addition, or instead, be used to prevent problems, e.g. by not executing the complex function if a sensor indicates malfunctioning in a previous execution (e.g. excessive vibration, overheating, etc.) or that one or more necessary supplies (e.g. water, coolant, etc.) are not available.

[0033] In addition to, or instead of, taking additional inputs, the controller virtual asset 106 may generate additional outputs to virtual assets other than the counterparts of the group of modules 812. These additional outputs may provide alerts to a user, for example to indicate the progress of execution of the complex function (e.g. when it starts, stops and/or has a problem) or provide fault or maintenance information (e.g. an instruction to clear a filter, add oil, etc.). [0034] By taking additional inputs and/or generating additional commands, the controller virtual asset 106 is more intelligent than the combination of the virtual assets which are the counterparts to the modules in the group 112.

[0035] In a variation of that described above, instead of the controller virtual asset 106 taking additional inputs, the service requesting virtual asset 108 may receive one or more additional inputs (as indicated by the line of long dashes in FIG. 1). This would result in some of the intelligence being implemented in the service requesting virtual asset 108 (e.g. in the agent 109 of the service requesting virtual asset 108). In a further variation, both the controller virtual asset 106 and the service requesting virtual asset 108 may receive one or more additional inputs, such that the intelligence is shared between them (e.g. between their respective agents).

[0036] Use of a cloud machine, as described above, results in a complex, decentralised function which is more secure (e.g. it has improved resistance to tampering since the complex function does not exist within the group of modules but is represented in the connection brokerage system 100) and more flexible (e.g. functionality can be upgraded by updating the code run by the agent of the controller virtual asset without requiring a software update to be implemented on a machine that has been deployed and the controller virtual asset may broker connections with additional virtual assets to provide additional inputs and outputs after deployment). Use of a cloud machine may also improve performance and reliability and enable faster diagnosis of faults (e.g. because other information can be used as inputs to the code run by the controller virtual asset). Any upgrading and fault diagnosis can be performed remotely from the modules themselves which may be particularly useful for those modules deployed in inhospitable, unsafe or geographically dispersed situations.

[0037] Use of a cloud machine, as described above, may enable re-use of modules between complex functions which improves efficiency and overall size of the hardware. This is shown in FIG. 2. In the arrangement of FIG. 2 there are two groups of independent modules 112, 212 but there is an overlap, with both groups containing the same module. For example, the two cloud machines (each associated with one of the two groups of independent modules) may operate as a washing machine and a dishwasher and they may share a water pump. In another example, the two cloud machines may share a power supply. As shown in FIG. 2, there may be separate controller virtual assets (and corresponding agents), one for each complex function, and both may receive data from and/or send commands to the counterpart virtual asset of the independent module that is in both groups. The same service requesting virtual asset 108 may subscribe to both controller virtual assets 106 and/or different service requesting virtual assets may subscribe to each of them. [0038] FIG. 3 is a flow diagram of an example method of operation of the cloud machine that is implemented within a connection brokerage system 100, 200. Whilst the arrows in FIG. 3 indicate one possible order of the method blocks, the blocks may be implemented in other orders and/or several of the blocks may be implemented substantially in parallel.

[0039] As shown in FIG. 3, the counterpart virtual assets of the modules in the group of independent modules (working in combination with their agents) may perform two operations: they receive data from their counterpart real device (e.g. one of the independent modules) and forward this on to the controller virtual asset (block 302) and the receive control signals from the controller virtual asset and as a result of these, they send commands to their counterpart real device (block 304). The commands that are sent to the counterpart real devices may be different to the control signals that are received from the controller virtual asset and the counterpart virtual asset (using its agent) may perform translation between control signals received and commands and that can be understood and implemented by the counterpart real device. It will be appreciated that where the counterpart real device is a sensor, the virtual asset may only receive data and not send commands (i.e. block 304 may be omitted).

[0040] The controller virtual asset, as described above, receives data from the virtual assets which are the counterparts to the modules in the group of independent modules (block 306) and may also receive data streams from other virtual assets (not shown in FIG. 3). The controller virtual asset also receives control signals from a service requesting virtual asset that triggers, or otherwise influences, the execution of the complex function (block 308). The controller virtual asset, in response to receiving data streams (in block 306) and/or in response to receiving control signals (in block 308) generates, using its agent, control signals and sends these to the counterpart virtual assets of the modules in the group of independent modules (block 310). This process is ongoing throughout the execution of the complex function, depending upon the particular complex function code, with commands being sent at different times, often in response to data received from the modules via their counterpart virtual assets, i.e. the controller virtual asset orchestrates the execution sequence and individually instructs the different counterpart virtual assets, The counterpart virtual assets do not communicate with each other to implement the complex functionality. As also shown in FIG. 3, the controller virtual asset may generate a data stream that it sends to service requesting virtual assets (block 312) and as described above this data stream may provide status information about the complex function itself and/or about the individual modules within the group of independent modules that collectively implements the complex function under the control of the controller virtual asset. [0041] As described above, in the cloud machine the only interaction between the individual modules occurs within the connection brokerage system and via the controller virtual asset (and its associated agent, which is external to the connection brokerage system).

[0042] In the examples described above, the cloud machine is implemented by a predefined, fixed group of real devices 112, 212. In other examples, the membership of the group of real devices may vary overtime and one or more real devices (and hence their counterpart virtual assets) may only transiently be part of the cloud machine.

[0043] In an example the cloud machine may be a traffic junction with the group of modules comprising the traffic lights (as a permanent member of the group) which are actuated by the controller virtual asset. Autonomous vehicles that are in the vicinity of the traffic lights may be transient members of the group, such that they are only members whilst they are in the vicinity of the traffic lights. The group may also comprise sensors to detect other objects at or near the junction (e.g. people). In such an example, the complex function controls the traffic lights, and potentially pedestrian crossing control lights, based on its knowledge of what is at or near the junction and may also control (or provide information to) the autonomous vehicles (e.g. to warn them of an impending change in the traffic lights or an unexpected obstacle on the road). The controller virtual asset may receive a data stream from another data source, such as a weather sensor or moisture sensor and may, for example, adjust the timing of the traffic lights when it is raining or the road surface is wet. By implementing the road junction as a cloud machine, road safety may be improved and/or delays at the junction may be reduced. In this example the transient members of the group may be defined based on their location (e.g. using geofencing). Privacy concerns may be alleviated due to the transient nature of the association with the junction and/or by not revealing identity information to the controller virtual asset (e.g. such that the controller virtual asset knows that there is a vehicle at a particular location but not the identity of that vehicle).

[0044] In another example the cloud machine may be a moving vehicle (e.g. a train) and the group of independent modules may comprise a fixed subset (e.g. those modules which are on the train) and a transient subset (e.g. proximate modules such as tracks, points, stations, signals, etc. which the train passes by). This may, for example, be used to automatically and collectively re-route a vehicle (e.g. a train) around a problem (e.g. an accident, a faulty track, etc.).

[0045] By using the methods described above the cloud machine may be a service that a user can subscribe to and dependent upon the type of subscription, the cloud machine (and hence the group of independent modules) may operate in different ways and/or with different levels of functionality. This may, for example, enable a person to purchase a washing machine with low-end functionality but to subsequently upgrade to a higher performing washing machine without needing to replace any hardware in their house.

[0046] Although in the examples described above, the independent modules are all real, physical modules (e.g. with sensing and/or actuating capability), the methods described above may also be used to implement a complex function using a plurality of independent modules where one or more of the modules are not real, physical modules but instead are independent services, or they may be real, physical computing devices running independent services (e.g. financial services, security-based services, etc.). For example, one of the independent modules may be a service relating to the purchase of rail tickets and another of the independent modules may be a ticket barrier or part thereof (and hence is a real, physical module).

[0047] As described above, the agents of the virtual assets may run on a computing device, with a single computing device running one or more agents. The term ‘computing device’ and 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices. FIG. 4 shows an example computing device 400.

[0048] Computing device 400 comprises one or more processors 402 which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to implement the methods described herein (e.g. to execute a virtual agent). In some examples, for example where a system on a chip architecture is used, the processors 402 may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of a virtual agent in hardware (rather than software or firmware). Platform software comprising an operating system 404 or any other suitable platform software may be provided at the computing-based device to enable application software 406 to be executed on the device.

[0049] The computer executable instructions may be provided using any computer-readable media that is accessible by computing device 400. Computer-readable media may include, for example, computer storage media such as memory 408 and communications media. Computer storage media, such as memory 408, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Although the computer storage media (memory 408) is shown within the computing device 408 it will be appreciated that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using communication interface 410).

[0050] The computing device 400 also comprises an input/output interface 412 arranged to output display information to a display device 414 which may be separate from or integral to the computing device 400. The display information may provide a graphical user interface. The input/output interface 412 is also arranged to receive and process input from one or more devices, such as a user input device 416 (e.g. a mouse or a keyboard). This user input may be used to provide user input to a virtual agent, send trigger signals, etc. In an embodiment the display device 414 may also act as the user input device 416 if it is a touch sensitive display device. The input/output interface 412 may also output data to devices other than the display device, e.g. a locally connected printing device (not shown in FIG. 4).

[0051] Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

[0052] Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.

[0053] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems orthose that have any or all of the stated benefits and advantages. [0054] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements. [0055] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. [0056] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.