EP3329373A1

EP3329373A1 - An edge network device for a data network and a method of processing data in a data network

Info

Publication number: EP3329373A1
Application number: EP16754415.4A
Authority: EP
Inventors: Angelo GRECO; Paul Conway; Andrew Timothy TABERNER; Benjamin KINSELLA
Original assignee: B+b Smartworx Ltd
Current assignee: B+b Smartworx Ltd
Priority date: 2015-07-29
Filing date: 2016-07-28
Publication date: 2018-06-06
Also published as: WO2017017200A1

Abstract

Provided is an edge network device or gateway device for a data network. The device comprises a memory storing operating system (OS) software and a processor for executing the OS software to provide an OS level virtualization environment. The OS level virtualization environment provides a data distribution service to share services and an OS command interpreter interfaced with the data distribution service to enable the sharing of services on the data distribution service. An event processing engine receives data from the data distribution service and uses a query language to match received data with a query and then publish results of any matched queries onto the data distribution service. The data distribution service is configured to share services in the data network with one or more other similarly configured edge network devices and the OS command interpreter is configured to use the data distribution service to pass logic between the edge network device and the one or more other similarly configured edge network devices.

Description

An Edge Network Device for a Data Network and a Method of Processing

Data in a Data Network.

Field

The invention relates to a distributed architecture for an edge network device or a gateway device for a data network and more specifically to an architecture for an Internet of Things (loT) gateway device, and a method to process data at a semantic level in the same context and environment as the edge network device, including the deployment, the configuration and the maintenance of the data network.

Background The Internet of Things vision requires application layer gateways on software and hardware to fill the gap between "Things", the interfaces to the physical world, featured by desirability of simplicity, high volumes deployments, low price, low energy consumption, specialized functions, easy configurability, fast paced availability of new solutions, and the "Internet", with its ubiquity, big power of processing and storage, security and versatility, providing the User Experience.

There are many devices and service solutions in the worlds of loT and M2M and others that provide data connectivity in many disparate environments such as integrated transport, traffic management, industrial automation, environmental monitoring, building management, by way of example only. However, each environment can be considered as comprising a 'silo' in that there is presently no easy way technically to cross-correlate data between these different "worlds". ΙοΤ gateways, cellular routers and M2M edge network devices normally comprise embedded devices located at the edge of the data network which typically run data aggregation services. Such devices may also be configured to run independent embedded client modules which aggregate and transmit data to cloud based data aggregation and analysis services. Operating such devices normally requires the following: prior knowledge of the data: its properties and context; prior knowledge of the problem domain; prior knowledge of the protocols deployed at the devices' Interfaces; an ability to program the deployed solution in a specific programming language; some cross-compilation steps with library dependencies; an ability to deploy the program onto the embedded device; and some manual integration of services on the embedded edge network or gateway device. These requirements present considerable technical difficulties in provisioning such devices as the provision is in each case a bespoke arrangement being specific to the required solution and time-consuming to implement. Each such edge device typically operates as a single entity using its own, but not shared, rules and services locally.

Furthermore, there are, for example, no known methods of extending the "port count", hardware interfaces, processing power, throughput, bandwidth, storage, logical and software capabilities of pre-installed gateway devices, especially when considering the integration of emerging technologies through the system's lifetime, without either: un-installing and replacing existing devices; replacing existing infrastructure; and/or re-deploying/re-writing programmed logic. In many cases, the replacement of a device may involve a degree of risk analysis and safety case development before the actual replacement project can be specified, and such changes can therefore be a significant contributor to the lifetime cost of the installed system.

Existing edge devices are by their nature located at a single point within a network, and require all connected data source devices, e.g. sensors, and sink devices, e.g. actuators, to be exposed at that point. This typically requires significant cost and effort in providing the necessary physical cable connections between the edge network device and the data sink and source devices and a design that can support only limited infrastructure and software changes over the lifespan of the project.

A conventional approach to building loT gateway devices, or M2M edge network devices, has been to extend the capabilities of the device within the device itself. Consequently, the gateways or edge network devices, sometimes referred to as "Fat" Gateway devices, must have all of the physical, i.e. hardware, interfaces required to support the specific solution for which they are deployed. They must also have all of the required low level rules and business-logic, embedded therein. These gateways therefore are designed to aggregate data and apply basic logic and rules locally, with the constraint of their physical processing limit and usually sending continuous data streams over a link to an external application. They typically depend on a network level entity such as a "cloud" processing entity to provide business logic and data analytics. The cloud processing entity may also provide device configuration and software upgrade. In such a case, the cloud processing entity deploys the edge-of-the-network data aggregation rules and logic and configuration items to each edge of network or gateway device

For such edge network devices, data and action requests are pushed from the devices to the cloud processing entity for further analysis. Control and configuration data, responses to device action requests, and data-handling rules- logic are pushed from the cloud processing entity to the edge network or gateway devices. Consequently, each device must be controlled and configured individually and each device must maintain a connection with the cloud processing entity. Inside each edge network device or gateway device, there are provided low level functions, e.g. application programming interfaces (APIs), objects and the like, which combine to provide the specific solution for which the devices are deployed. Fig. 1 diagrammatically shows this conventional approach for an loT gateway device. Table 1 provides a description of the entities comprising the conventional loT gateway device. In the example conventional loT gateway device of Fig. 1 , each of the gateway devices 10 has a direct connection 1 2 to the cloud processing entity 14. The cloud processing entity 14 configures the gateway devices 10, and deploys specific and localised low level business logic (events processing and rules) to each of the gateway devices 10. Each gateway device 10 then functions independently of all others taking inputs only from the physical interfaces 16 that are available to it and processes those inputs only through direct function-calls 18 that provide interfaces to other physical or logical entities available in the same gateway. As data is aggregated on each gateway device 1 0, the data will be either sent in full to the cloud processing entity 14, or pre-filtered and sent on an as-needs basis depending on local basic rules. The cloud processing entity 14 will then also aggregate the data from each of the gateways devices 10 and perform a second higher level of data-analysis and filtering, before either storing the data to a "Big Data" database (not shown), or making it immediately available for a user system or apparatus 10 to consume, eventually applying a data format and/or a protocol conversion.

For most edge network device or gateway device architectures, there is a clear separation of the operating system (OS) "Kernel Space", and "User Space". One example of an OS which deploys a kernel space and a user space is Linux™. Linux™ is often the OS of choice for M2M edge network devices and loT gateway devices, because it facilitates the separation of the kernel space and the user space and provides much of the required functionality. The kernel space can be considered as the core of the OS. It normally has full access to all memory and device hardware and everything else on the device. The user space is basically a form of sand-boxing whereby it restricts user programs access to memory and other resources Owned' by other programs or by the OS kernel. Figure 2 shows a typical OS architecture 22 of an edge network device or gateway device 10. The kernel space 24 typically provides a hardware abstraction layer 26; a board support package 28; an OS kernel 30 with hardware and architecture dependent code modifications; and an OS system-call interface 32. The user space 34 has libraries 36, which provide required functionality, and an application space 38, which is custom to each device or device vendor, for example. The application space 38 utilizes the libraries 36 and makes system calls in a known manner. Linux distros provide also a set of well proven tools in the application space, and interprocess communication mechanisms, that make it easy to create complex solutions "composing" basic functionalities into scripts.

It will be appreciated from the foregoing that introducing new edge network devices or gateway devices into installed data network infrastructure or even extending the capabilities of an already installed edge network or gateway device is complicated, difficult and time-consuming in the fast evolving technologies of IT, M2M and loT. Adding and supporting new sensors and actuators could require many changes on the hardware and software configuration on the gateway and increasing security concerns, because of the "wider attach surface". The same issue is encountered on developing and deploying new software capabilities on pre-existing monolithic application, even when only little extensions to a previous set of functionalities is required. It is also clear that transmitting continuously not contextualized, uncorrelated raw data is not an optimized usage of time, load and bandwidth, especially when data has low entropy (i.e. transmitting periodically a GPS location of a motionless device doesn't add any informative content). A standardized description and exposure of the capabilities, both hardware and software, and their interfaces, could open the system to be more interoperable with existing or even not yet existing technologies, that is the foundation of the Internet of Things. It would be appreciated in this context, to be able to provide also the openness to run third party software without the concerns of harming the overall functionality of the device: this "sandboxing capability" could enable the deployment of multi-user and multi-applications gateways, to elevate bespoke embedded solutions into general purpose service-provider platforms, at the edge.

The Internet of Things is data-centric and event-based; every application can be modelled as a dynamic graph with mutable software agents as nodes, exchanging actionable data over mutable channels (edges with changeable strength). It is difficult, if not impossible, for a pre-designed, pre-deployed monolithic application on the gateway to handle with this dynamicity.

An object of the invention is to mitigate or obviate to some degree one or more problems associated with known edge network devices or gateway devices for data networks.

The above object is met by the combination of features of the main claims; the sub-claims disclose further advantageous embodiments of the invention.

Another object of the invention is to mitigate or obviate to some degree one or more problems associated with known M2M edge network devices or loT gateway devices for data networks.

One skilled in the art will derive from the following description other objects of the invention. Therefore, the foregoing statements of object are not exhaustive and serve merely to illustrate some of the many objects of the present invention.

Summary

In general, the invention seeks to provide an edge network device or gateway device for a data network, particularly for an M2M network and/or an loT data network, as set out in the appended claims.

In one embodiment the edge device comprises a memory storing operating system (OS) software and a processor for executing the OS software to provide an OS level virtualization environment. The OS level virtualization environment provides a data distribution service to share services and an OS command interpreter interfaced with the data distribution service to enable the sharing of services on the data distribution service. An event processing engine receives data from the data distribution service and uses a query language to match received data with a query and then publish results of any matched queries onto the data distribution service. The data distribution service is configured to share services in the data network with one or more other similarly configured edge network devices and the OS command interpreter is configured to use the data distribution service to pass logic between the edge network device and the one or more other similarly configured edge network devices.

In preferred embodiments, the OS level virtualization environment is configured to provide an agent comprising a software entity which interfaces with the data distribution service to access shared services. The edge network devices make their agents available to a logically grouped set of agents within the data network to form a logical distributed data processing entity or a 'swarm'.

The invention provides a number of significant advantages over known edge devices including, but not limited to: the ability to aggregate and distribute data, seamlessly, between 'swarmed' devices at the edge of the network; the ability to aggregate and share physical interfaces, seamlessly, between swarmed devices at the edge of the network; the ability to create event processing rules, which combine data that is produced, in real-time, across multiple physical swarmed devices at the edge of the network; the ability to annotate meta-data (i.e. information) to real-world data, automatically and in real-time; the ability to filter, and act on, information (as opposed to just data), in real-time, at the edge of the network; the ability to cross-correlate the data and information gathered from a device or a swarm of devices at the edge of the network, with non-related domains of information from non-related "silos", using linked data query techniques; and the ability to dynamically profile data provisioning in the network. In a first main aspect, the invention provides an edge network device for a loT data network, said edge loT device comprising: a memory storing operating system (OS) software; and a processor for executing the OS software to provide an OS level virtualization environment configured to implement: a data distribution service to share services; and an OS command interpreter interfaced with the data distribution service to enable the sharing of services on the data distribution service.

In a second main aspect, the invention provides a method of processing data in a data network, said method comprising: provisioning an edge network device according to the first main aspect of the invention at an edge of the data network; receiving data from the network via the data distribution service; processing said received data at a processing engine using a query language to match received data with a query; and publishing results of the matched query onto the data distribution service.

In a third main aspect, the invention provides a computer readable medium storing machine readable instructions executable by a processor of an edge network device for implementing the steps of the second main aspect of the invention. In a fourth main aspect, the invention provides a data network comprising a plurality of edge network devices according to the first main aspect of the invention and a network level entity, said network level entity being arranged to: configure each of the plurality of edge network devices; arrange said plurality of edge network devices into a single logical entity whereby said devices share their agents and rules-based logic; logically group the agents of the plurality of edge networks devices to form a logically distributed data processing entity.

In a fifth main aspect, the invention provides a method of forming a logically distributed data processing entity in a data network, comprising: providing a plurality of edge network devices according to the first main aspect of the invention and a network level entity; arranging said network level entity to: configure each of the plurality of edge network devices; arrange said plurality of edge network devices into a single logical entity whereby said devices share their agents and rules-based logic; and logically group the agents of the plurality of edge networks devices to form said logically distributed data processing entity.

In a sixth main aspect, the invention provides a computer readable medium storing machine readable instructions executable by a processor of an edge network device for implementing the steps of the fifth main aspect of the invention.

In a seventh main aspect, the invention provides an edge loT gateway device for an Internet of Things data network, said edge loT gateway device comprising:

a memory storing operating system (OS) software; and a processor for executing the OS software to provide an OS level virtualization environment configured to implement:

a data distribution service to share services in the data network with one or more other similarly configured edge loT gateway devices; and

an OS command interpreter interfaced with the data distribution service to enable the sharing of services on the data distribution service;

wherein the OS software executed by the processor is configured to provide semantic information for the edge loT gateway device to one or more other similarly configured edge loT gateway devices and/or to receive sematic information from the one or more other similarly configured edge loT gateway devices.

In an embodiment, the semantic information for the edge loT gateway device comprises a semantic link network modelling the edge loT gateway device. In an embodiment, the semantic link network models the software and the hardware of the gateway and all data passing through the gateway.

In an embodiment, the edge loT gateway device further comprises a semantic engine to query and update the semantic link network.

In an embodiment, the edge loT gateway device comprises an event processing engine interfaced with the semantic engine configured to gather data streams from the data distribution service and to use a query language to match received data streams with queries and to publish results of matched queries onto the data distribution service.

In an embodiment, the event processing engine can learn of any available services in the form of available software agents implementing the nodes of the semantic link network from the stored semantic information and can update the stored semantic information.

In an embodiment, the edge loT gateway device further comprises a script interpreter for creating and deleting the software agents.

There is also provided a computer program comprising program instructions for causing a computer program to carry out the above method which may be embodied on a record medium, carrier signal or read-only memory. The summary of the invention does not necessarily disclose all the features essential for defining the invention; the invention may reside in a subcombination of the disclosed features. Brief Description of the Drawings

The foregoing and further features of the present invention will be apparent from the following description of preferred embodiments which are provided by way of example only in connection with the accompanying figures, of which:

Figure 1 is a schematic diagram illustrating a conventional loT gateway device network connection arrangement;

Figure 2 is a block diagram of the logical structure of a conventional loT gateway device;

Figure 3 is a block schematic diagram of the structure of a gateway device according to the invention;

Figure 4 is a block diagram of the logical structure of a gateway device according to the invention;

Figure 5 is a schematic diagram illustrating a gateway device network connection arrangement according to the invention;

Figure 6 is a block diagram of the logical structure of a logical distributed data processing entity formed by a plurality of gateway devices according to the invention;

Figure 7 is a block diagram of the logical structure of a virtual global user space for a logical distributed data processing entity formed by a plurality of gateway devices according to the invention;

Figure 8 shows a schematic illustrating how the gateway of the present invention can be viewed as a transform between the Semantic Link Network of Things and the Semantic Link Network of Internet;

Figure 9 illustrates how a problem in the Domain of Device can be abstracted into a problem of SLN;

Figure 10 shows a schematic of one embodiment of the semantic link network of the present invention;

Figure 1 1 shows a schematic of one embodiment of a software SLN; Figure 12 shows a schematic of one embodiment of a hardware SLN;

Figure 13 shows a schematic of one embodiment of a DATA SLN;

Figure 14 shows a schematic of the Fractal model using the semantic link network of the present invention;

Figure 15 shows the main process steps in the deployment of an agent;

Figure 16 shows the main process steps in the development of an app into a single gateway;

Figure 17 shows the main process steps in the deployment of an App into multiple gateways; and

Figure 18 shows a schematic of the structural mapping between joined gateways and joined SLNs.

Detailed Description of Preferred Embodiments

The following description is of preferred embodiments by way of example only and without limitation to the combination of features necessary for carrying the invention into effect.

Reference in this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.

It should be understood that the elements shown in the figures, may be implemented in various forms of hardware, software or combinations thereof. Some of these elements may be implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, memory and input/output interfaces.

The present description illustrates the principles of the present invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope.

Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, by the mean of the same concept and the same structural approach.

In the claims hereof, any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements that performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The invention as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. It is thus regarded that any means that can provide those functionalities are equivalent to those shown herein.

Reference in the following description of preferred embodiments to a 'gateway device' is to be taken as also a reference to any of an 'edge network device', an 'edge device' and a 'network edge device'.

Machine to machine (M2M) refers to technologies that allow both wireless and wired systems to communicate with other devices of the same type. M2M is a broad term as it does not pinpoint specific wireless or wired networking, information and communications technology. M2M is considered an integral part of the Internet of Things (loT) and brings several benefits to industry and business in general as it has a wide range of applications such as industrial automation, logistics, Smart Grid, Smart Cities, health, defense etc. mostly for monitoring but also for control purposes.

In order to address the problems highlighted in the background of the invention section, in the context of edge loT gateways, embodiments of the proposed invention provide a distributed architecture for an edge network device or gateway device, or even a set of devices, for a data network, particularly an Internet of Things data network, and a method to process data at a semantic level in the same context and environment as the edge network device, including the deployment, the configuration and the maintenance of the data network.

In particular the loT Gateway of the present invention is a gateway between Semantic Link Networks. A semantic network is a network representing semantic relations between concepts. A Semantic Link Network (SLN) consists of semantic nodes, semantic links and reasoning rules. The semantic nodes can be any resources, classes of resources, or even a semantic link network. Semantic links can be established by tools or automatic discovery approaches. The reasoning rules are for semantic reasoning. New semantic links may be derived out by rule reasoning. The semantics of a semantic link network will change if its rules are changed. With this definition, it should be understood that the gateway architecture of the present invention is applicable practically to every entity/scenario in a loT context: the "input network" can be composed conceptually of sensor measurements, events, configuration items, environmental contexts, security constrains, relations and time representation; the "output network" can be composed conceptually of events, alerts, enriched data, application structures, logic, physical actions, files, security Access Control Rules; the transformation functions can be data enrichment, filtering and aggregation, configuration, data format translations, protocol translations, data format/protocol adapting, time series generations, input multiplexing and security policies. Figure 8 shows a schematic illustrating how the loT Gateway of the present invention can be viewed as a Transform between the Semantic Link Network of the Things and the Semantic Link Network of Internet. In particular, the Gateway itself can be described by a dynamic SLN. With this definition, the Edge Data are transformed into Internet Data by a set of logically linked software Agents.

The gateway is abstracted to a SLN and so the architecture of the present invention has the functionally of a fractal model, in the sense that the overall function of the loT Gateway on the edge network is the result of and repeats itself in the collective behavior of a "swarm" of "microgateways" performing the same logical function at a smaller scale, semantically classified into the SLN and so exposed as a graph, and each of them is composed by an internal graph of "gateway libraries" between the hardware and the software domains, acting as "nanogateways" between the physical domain and its virtual representation.

Figure 14 illustrates the Fractal model of the SLN of the invention. A Swarm is conceptually a gateway between the Thing Domain and the Actionable Data Domain (at the Edge of network). The structure of the Swarm is replicated in the composing gateways, transforming Thing Domain into Local Edge Intelligence. On a lower scale, App gateways composing the gateway are structurally made by microgateway Agents, and each Agent is made by low level nanogateway libraries. Intermediate structures can also emerge, such as two Apps to form a new conceptual gateway).

On the other side, the gateway function can be extended over the Internet, composing multiple swarms into a "megagateway" function, e.g. into a Big Data application from the Domain of sensors to the Domain of Insights. Using this model, the architecture of the present invention is platform independent, language independent, fully modular and extensible in space and time. The more interactions/layers are used to implement the architecture and the bigger number of specialized entities is used (increasing their functional granularity), the more complex/intelligent behavior is expected to emerge. Through the use of the SLN abstraction of the gateway, and assuming the properties of SLNs and a plethora of theories, tools and algorithms available to describe and manage SLNs, these properties and frameworks will be available in order to solve the issues into the physical embodiment of the abstraction.

Figure 9 illustrates how, through the use of the abstraction explained with reference to Figure 8, a problem in the Domain of Device can be abstracted in a problem of SLN. New features are new nodes and new links, resource constraints can be overcome by decoupling the processing entities from the hardware interfaces, so that same entities can refer transparently to new delocalized added hardware capabilities and the data can be treated in a holistic way with the system state and the behaviour changed accordingly, using the same common modelling language. A structural mapping between the SLN and the implementation using technologies like LXC, DDS, Semantic Engine, and Interpreted Languages is needed to deploy the SLN solution into the Gateway, as software items.

Once a mapping by structural similarity and a set of enabling technologies is provided, a problem in a physical embodiment can be solved into the abstract domain, as described in the following sections. The foregoing combination of concepts and technologies may be known as SmartSwarm Architecture (SSA).

In one exemplary embodiment the enabling components of the proposed invention are deployed in a partition of the storage memory of an edge network device, comprising a memory storing an Operating System, a processor executing the OS into a Random Access Memory and some hardware interfaces exposed by drivers to the OS. Hardware devices are connected to those interfaces, to provide network access (i.e. cellular modems, Ethernet ports, serial ports), data sources (sensors, digital inputs, switches) or data sinks (actuators, digital outputs, leds). In one embodiment the SSA is deployed on an edge device comprising a memory storing the operating system (OS) software, a processor for executing the OS software into a Random Access Memory, and drivers to access the actual hardware exposing it through interfaces.

Upon this network device architecture, the SSA is deployed as

Components. Components are Linux Containers, language support libraries, template Agents, taps between Agents and the underneath software configuration layer, the middleware, the model representation as an ontology, third part libraries. An application can be created composing template Agents or bespoke Agents of the same species derived from them; this composition can happen statically, with predefined and predeployed scripts modelling the Application behavior, or dynamically with run time selection, configuration and deployment of the composing Agents instances on the fly, depending on run time assessed circumstances. Some Agents are alive during the entire lifespan of the hive: they are needed to perform mandatory tasks like health reporting, reconfigurations, load balancing, the maintenance of the link to external management systems (if any) and fault recovery. The composition of Linux Containers, Agents, middleware, containers and ontology results in a Virtualized Linux OS, or Virtual OS, with an extensible set of Linux commands, an extensible set of hardware capabilities and interfaces. The semantic based discovery, tasks composition and orchestration expose the functions of the Agents conceptually as services.

Referring to the drawings, Fig. 3 is a schematic diagram of a gateway device 40 for a M2M data network or the like. The gateway device 40 comprises a memory 42 storing operating system (OS) software and a processor 44 for executing the OS software. The processor 44 executes the OS software to provide an OS level virtualization environment 46 (Fig. 5) configured to implement a data distribution service (DDS) 48 to share services and an OS command interpreter 50 interfaced with the data distribution service 48 to enable the sharing of services on the data distribution service 48. The gateway device 40 also comprises an event processing engine (CEP) 52 configured to receive data streams from the data distribution service 48 and to use a semantic query language such CQELS or SPARQL to match a received data stream with a query and to publish results of any matched queries onto the data distribution service 48. The OS software is configured to provision a semantic model (SSM) 54 for the gateway device 40 to store semantic information about said device 40 such that the event processing engine 52 can learn of any available services from the stored semantic information.

In one embodiment, the data distribution service 48 is configured to share services in the data network with one or more other similarly configured gateway devices and the OS command (Script) Interpreter 50 creates Agents with a DDS interface and use the data distribution service 48 as a logic link between the gateway device 40 (in particular its SLN representation) and the one or more other similarly configured gateway devices (their SLN representations). So the action of join more gateways into a super-gateway is conceptually a join operation by link addition between their SLN models.

Whilst in some embodiments, the OS level virtualization environment 46 on the gateway device 40 comprises a virtual machine, it is preferred that the OS level virtualization environment 46 comprises an OS container such as a Linux™ container (LXC) configured to run on an Linux™ control host provided in the data network. LXC is a Linux™ Container technology, which offers an environment close to that of a virtual machine, but without the overhead that comes with running a separate kernel and simulating all of the device hardware. This is achieved through a combination of kernel security features such as namespaces, mandatory access control and control groups.

This technology has therefore the capabilty to add and remove dynamically nodes and links into the physical implemetation of the SLN representing the gateway. Sandboxing a node implementation with all its dependencies into a Linux Container converts an install/uninstall operation into a copy/delete operation, so it is possible to add/remove software and hardware support on the fly. DDS and standard Linux I PC mechanism are suitable thereafter to add/remove dynamically communication channels (links) between nodes.

The OS software executed by the processor 44 is configured to provide semantic information for the gateway device 40 to the one or more other similarly configured devices 40 and/or receive sematic information from the one or other devices. The OS software may exchange semantic information between the gateway devices when a gateway device connects to the data network and/or when a gateway device joins one or more other gateway devices in the data network to form a logical distributed data processing entity or a 'swarm' 56. A swarm 56 can be considered as comprising more than one logically grouped interoperable agent, running in the operating context of one or more gateway devices 40 at the edge of the data network.

The OS level virtualization environment 46 may be configured to provide each gateway device 40 with an agent comprising a software entity which interfaces with the data distribution service 48 to access shared services. The gateway devices 40 each make their agents available to the logically grouped set of agents within the data network to form the logical distributed data processing entity or swarm 56.

Referring to Figs. 4 to 18, it can be seen that the gateway device 40 is different to the conventional gateway device 10 depicted in Fig. 1 .

The architecture of the gateway device 40 is different to that of the conventional gateway device 1 0, but has a generally similar overall structure in that it also shows a clear separation between the kernel space 58 and the user space 60. Linux™ is the preferred underlying OS. The kernel space 58 of the gateway device 40 of the invention is similar to that of the kernel space 24 of the conventional gateway device 10 in that each of the typical blocks is present, namely a hardware abstraction layer 62; a board support package 64; an OS kernel 66 with hardware and architecture dependent code modifications; and an OS system-call interface 68. It is in the user space 60 that there are significant differences as particularly shown by Fig. 4 which shows the architecture of the gateway device 40 and Table 2 which describes the key components of the gateway device 40.

The capabilities of the swarm 56 comprises a combination of the capabilities of the gateway devices 40 and their agents that have been deployed in the swarm 56. The swarm 56 will be composed of available agents. The available agents depend on the capabilities of the gateway devices 40 that are deployed in a 'hive' and the services that those devices 40 expose. A 'hive' refers to a deployment of more than one gateway device 40 into a single solution space. The gateway devices 40 are deployed with the intention that they will operate together, distributing their agents (services and capabilities) and rules- based logic amongst each other thereby operating together as a virtual single physical entity. The hive will host a single swarm 56.

The Agents make use of the available physical (hardware) services that exist on all of the gateway devices 40 in the swarm 56, the software services that are available on the gateway devices 40, and the loT Services that are available on the gateway devices 40. The swarm 56 distributes the rules logic across the available gateway devices 40 using the DDS 48.

The gateway devices 40 of the invention, like the conventional gateway devices, may aggregate data, and apply logic and rules locally. In this respect, they may still operate as standalone devices on an edge of a network despite their being capable of forming a logical distributed processing entity, i.e. a swarm.

Prefereably, however, the gateway devices are best used as members of a hive where they contribute their agents to a swarm 56 and thereby enable the swarm 56 to aggregate data and apply logic and rules across the entire distributed swarm 56. In effect, each gateway device 40 comrpises a number of logical entities, each of which may become a component of the swarm 56.

The gateway devices 40 of the invention can operate at the edge of a data network without the necessity of the network having a network level processing entity such as a cloud processing entity. However, in some embodiments, the gateways devices operate with a cloud processing entity 70 as shown in Fig. 5.

The cloud processing entity 70 which may comprise a cloud server or a distributed set of connected cloud servers may be used to: configure the gateway devices 40, hive, swarm 56 and swarm intelligence; to join gateway devices 40 to a hive; join the agents that are available on each gateway device 40 into a swarm 56; set Quality of Service (QoS) levels for the swarm 56; and apply logic and rules to the swarm 56.

When one or more agents running in one or more gateway devices 40 is deployed into a swarm 56 with a common set of rules-based logic defining its behaviour, then the collective behaviour of the swarm 56 is referred to as 'swarm Intelligence'.

The swarm 56 sends data, data patterns and event notifications to the cloud processing entity 70. If a gateway device 40 is part of a hive, and the gateway device agents are part of a swarm 56, then the data pushed to the cloud processing entity 70 will come from a single agent within the swarm 56, i.e. each individual gateway device 40 is not required to directly push data to the cloud processing entity 70 not to be connected directly to it.

Each gateway device 40 in a hive is capable of receiving data from all of the available hardware interfaces that are available from the gateway devices 40 forming the swarm 56 and so can utilize any or all hardware interfaces even if said gateway device itself does not actually have any physical hardware interfaces built-into it.

As already described, it is only necessary that one agent in a swarm 56 maintains a connection with the cloud processing entity 70. In the event that the connection breaks, the swarm 56 may continue to operate as an autonomous entity. When the connection with the cloud processing entity 70 is re-established, the swarm 56 is capable of re-syncing both data and state for said connection and the formerly connected agent.

Redundancy may be built into the swarm 56 such that agents on one or more of the gateway devices 40 maintain the connection to the cloud processing entity 70 if necessary. Furthermore, agents on one or more of the gateway devices 40 may maintain the state of the swarm 56 itself. Should hardware on a gateway device fail, agents from other gateway devices 40 may provide redundant paths. The failed gateway device 40 may be replaced and re- activiated, i.e. a new gateway device may join the hive, and that gateway device's agents may join the swarm 56, without re-configuring or re-deploying onto any of the other gateway devices in the hive.

The swarm 56 comprises process components, i.e. agents, instead of functions. The agents may be combined in different sequences to produce the required outputs, but each agent is a standalone entity which provides a service to the swarm 56. Each service is available to each of the gateway devices 40 natively via the swarm 56, using the gateway device OS which preferably comprises an embedded Linux™ OS with extensions. The services accessed by the agents may exist anywhere on the swarm 56 and may be consumed by any of the gateway devices 40.

Referring to Fig. 5, it can be seen that only one of the software agents comprising node 72 has a direct connection to the cloud processing entity 70. The cloud processing entity 70 configures the swarm 56 and each of the gateway devices 40. The cloud processing entity 70 may also deploy business logic (events processing and rules) to the swarm 56 whereby the swarm 56 distributes the logic as required to each of the individual gateway devices 40 using the DDS 48. The agents in each gateway device 40 function as components of the swarm 56 wherein the swarm receives inputs from the hardware and services that are available on the swarm 56 from any of the gateway devices 40 and applies business logic using all of these available services. As data is aggregated on the swarm 56, the data may be sent in full to the cloud processing entity 70, or pre- filtered and sent on an as-needs basis depending on the local rules; or the data may be consumed by the swarm itself. Consequently, the swarm 56 is capable of much more powerful business logic and complex events and rules processing than traditional gateway devices. Ultimately, the swarm 56 will pass on relevant data and events to the cloud processing entity 70, which may then perform a second level of data-analysis and filtering, before either storing the data to a Big Data database or making it immediately available for a user system or apparatus 74 to consume.

Every gateway device 40 hosts all of the user space components as described in Figure 4 and Table 2. The architecture of the gateway device 40 extends beyond the physical constraints of the device itself, because each gateway device 40: abstracts it's physical (hardware) services; is self-aware due to the SSM; uses the distributed data service (DDS) middleware for real-time distribution of capabilities and services; and provides a OS level command interpreter.

In Figure 6, one can see the logical representation of a swarm architecture which is derived from a plurality of the individual gateway devices 40. The OS level virtualization environment 46 of each edge network device 40 is configured to combine with the OS level virtualization environments 46 of the one or more other similarly configured gateway devices 40 to provide a virtual global user space for the swarm 56.

The DDS middleware provides a logical bus that enables the services of the individual gateway devices to be available to all of the other devices 40, as though they were all available on a single physical entity. The OS command interpreter provides the conduit, which is available on each of the individual gateway devices 40, to pass any one or any combination of: logic, rules, data, meta-data, and services between the peer devices 40 on the swarm 56. The gateway devices' semantic models (SMs) combine to provide an overall swarm Semantic Model (SSM).

The event processing engine may comprise a complex event processing (CEP) engine which is capable of consuming very complex events- and rules- logic, using a relatively simple query language. The CEP can combine data (and meta-data) streams, and provide triggers and results based on queries that may be applied at run-time, i.e. without requiring any embedded logic. The CEP can also combine data and meta-data streams, and provide triggers and results, based on pre-defined static queries, which may be pre-programed and deployed as embedded rules.

The combination of the SSM, CEP and DDS of each gateway device 40 provides a virtual global user space as shown in Figs. 6 and 7 which sits above the local user spaces of the individual gateway devices 40.

Specific applications may be created and deployed to a gateway device

40 such that these applications can make use of the swarm agents, the OS level command interpreter which is the swarm command interpreter, and the standard command interpreter which is the individual gateway device command interpreter.

Every swarm OS command writes to, and/or reads from, the DDS middleware. The CEP is a subscriber on the DDS middleware such that the CEP receives the data streams as requested by a user adapter 76, and will apply internal matching logic to the data streams. Queries, e.g. rules, events, and triggers, are created in the application space. They are entered onto the DDS middleware via the OS command interpreter. The CEP receives each query in the same way as it receives data streams. The CEP matches data streams with queries using its internal matching logic. As long as the query follows the grammar of the query language, there is no limit to the complexity permitted by the CEP. The CEP is also a publisher on the DDS middleware. The CEP may publish the results of the matching queries back onto the DDS, which makes these results available to all members of the swarm 56. As the DDS and the OS command interpreter operate across the entire swarm 56, so too does the CEP operate across the entire swarm 56.

It should be understood that Agents can be considered as individuals acting inside a small part of the network, using the network as context. Agents are smaller SLN and their behavior can be defined by a SLN through an enrichment process. Some templates of Agents are provided following functionally the Enterprise Integration Pattern nomenclature. The preferred mechanism of communication of the Agents is stigmergic: an Agent communicates with other Agents, in order to exchange application or configuration data, "leaving" traces into the environment. These "data drops" can be left on the filesystem, on the stdout, on pipes, or on the middleware. The similarity of this approach with biological mechanism used inside communities of insects, is the reason of referring the Agents as the Swarm.

Template Agents are provided to derive bespoke Agents from them: in the exemplary embodiment of the invention a typical Agent is a multi-input to multi- output microgateway. The preferred input/output models are streams, protocol channels and the middleware, so a framework of basic Agent using stdin, stdout, files, sockets as stigmergic communication channels is provided. When a new functionality is needed a new Agent is deployed. Figure 15 shows the typical steps in the deployment of an agent. The Agent lifecycle is managed by a script command, like an extension to the Agent. A Linux Container contains all dependencies and interfaces used by the Agent (105). Some Agents are dependency and hardware support free: they can be deployed in any linux container if needed. To complete the "registration" of an Agent, a SLN describing static data and dynamic data is needed (1 10), and the Agent will join the swarm with a join operation between the SLN of the Agent and the SLN of the Swarm (1 15) and thus be deployed (120). In the preferred embodiment of the invention, some default template Agents are identifiable:

1 ) Sensor: It is a microgateway from the low level sensor, directly interfaced with the physical entity object of interest, to the Virtual Entity representation in the cyberspace. Adding new support for sensors to the architecture is achieved adding new derived types of this template.

2) Actuator: It is a microgateway dual of the Sensor Agent. It transforms the Virtual Entity state associated to a physical entity into a new state for that entity. As the Sensor Agent it is usually interfaced with low level firmware and external apparatuses.

3) Protocol: It is responsible to manage a protocol used to communicate with the gateway through external networks and interfaces. It is a microgateway from the internal representation of the Virtual Entity, suitably adapted, to the external format requested by the managed protocol and viceversa.

4) Adapter: It is used to modify the format of a Virtual Entity and add all needed metadata to fit a new channel communication. Usually is used to feed a Protocol Agent.

5) Aggregator

6) Filter

7) Splitter

8) CEP

9) Reasoner

10) Decoder

1 1 ) Encoder

12) TSED

13) Node Configurator 14) Installer

15) Enricher

16) Multiplexer

17) Service Configurator

18) Killer

19) Keepalive

20) Buffer

In one embodiment of the invention, previous types of Agents are provided in form of a framework. Sensor Agents have at least one input, attached to the physical interface where the physical sensor or network of sensors is connected to. Through this interface, the Agent gathers raw data from the sensor or network of sensors. A typed Sensor Agent is derived from the template, to match the data format and the protocol of the attached network. This is the development effort to extend the swarm with a new species of Sensors Agent. Sensor Agents have also a configuration input, and two Agents of the same species have the same configuration format. Sensor Agents have at least one output interfaced to the middleware, to "leave" samples of raw data whenever available. The approach is, again, stigmergic. They can also leave the data on stdout. When a new species is deployed, the SLN representing the Gateway by the provided ontology is enriched with the new SLN representing the species: configurations, dependencies, constraints, size, data format, etc. are added and new links created. A "join" operation is performed between the two SLNs. This could happen also dynamically: provided some security constraints, a common standard taxonomy to identify basic entities (i.e. the Semantic Sensor Network Ontology) and a common protocol, e.g. provide a Standard Sensor Agent, this join operation could happen on the fly. In the preferred embodiment, Sensor Agents are added by controlled deployment process. Sensor Agents are configured by a configuration input; every time a Sensor Agent comes up, it looks for its configuration in his location. To configure a Sensor Agent, a Configuration Agent is always looking for "configuration data" on the middleware. Once available, it gets data from there, drops the data in the Sensor Agent location ,and asks the Killer Agent to kill the Sensor Agent. The KeepAlive Agent restarts then so that the Sensor Agent will get the new configuration. This "rule" is reusable for all kinds of Agent and is type and location agnostic and totally decoupled (can be used across different cells and different devices providing the Agents involved). Sometimes Agents can look for configurations also on the middleware or on stdin: in this case they don't need to die in order to ingest the new configuration.

Decoder Agents are responsible to convert raw data into a normalized format, with all information associated to the type of data. They are always looking for "data drops" on the middleware of a particular data type (the middleware is network agnostic but data centric and typed on data). Each Sensor Agent has a Decoder Agent associated with it, and they are linked in the SLN by a friendship relation. They are able to decode in a common readable format the variegate information coming from sensors. In the preferred embodiment, the common format is JSON, but this is not restrictive for the functionality of the architecture. The decoder can also wait for data on stdin or any IPC communication channel. Actuator and Encoder Agents are dual respect of Sensor and Decoder: the Encoder gets a normalized version of the "thing" (in one embodiment a Virtual Entity specifying in JSON format a physical entity) and transforms that into a suitable format to be understood by an Actuator Agent. The latest couple of Agent interfacing the external environment is Protocol and Adapter: this combination transforms a normalized sample of data into the data expected by a specific protocol and vice versa. In one embodiment, a Sensor Agent has stdout interface to drop data on and the associated Decoder Agent has a stdin interface to look for data to gather: They could be piped using the standard Linux feature to pipe processes in the user space: a microgateway from "Raw data domain" to "Common format domain" results from this composition (fractal property). This "application" can be described in the SLN with the two nodes representing the Agents, and a new link "pipedTo" between them. From the SLN perspective, just adding a semantic link "pipedTo" between two Agents that are "pipeable" in the SLN, will result in a new deployed application (microgateway), assuming that a facility to create links (pipes) in the physical architecture is available (and this is trivial in a Linux environment). A common operation in the SLN, a link creation, is reflected in a deployment of an application that normalizes sensor data.

Extending this idea to all entities and relationships in the SLN, assuming the availability of variegate extensible spectrum of "composible" functions in a form of framework of Agents, and a set of "composition rules" in a form of framework of enabling technologies, one skilled in the art will appreciate the possibility to create and deploy applications of whatever complexity, conceptually and so structurally dependent from the actual environment conceptualized in the SLN. In particular, whilst the Agents are the implementation of nodes of the SLN representing the software, the DDS is one special implementation of semantic links: this combination has interesting capabilities in order to face all issues presented by conventional loT Gateway devices.

New devices (sensors, actuators, network interfaces) support is conceptually achieved adding new nodes and links to the SLN: this is translated by deploying new Sensor (Actuator or Protocol) Agents and Decoders linked by DDS. The middleware abstracts the underneath network, and pierces the Linux Containers and the device boundaries. This conceptually exposes disjointed physical resources, eventually across multiple devices, to be shared as services. It should be understood that a Semantic Engine is a specialized Agent that can manage data organized as semantic web standards like Resource Description Framework (RDF) or Web Ontology Language (OWL). In a semantic data model, data is organized linearly and hierarchically to represent the real world, describing the objects in triples, two objects and their relationship. An ontology that represents the Entity Relationship model of the Gateway and the data passing through it, is provided: the SE agent is capable of understanding and to derive from that, and from external linked knowledge bases, new concepts and facts resulting in new data instances, with a higher content of meanings, and new Agents autonomous interactions. SE agents, as well as every type of Agent, can be distributed and deployed in multiple instances across the system, to decentralize the process, improving adaptiveness, robustness, reliability and flexibility. The Semantic Engine is used by the Complex Event Processing Agent, able to detect events on semantically structured data and semantically structure queries and the Reasoner Agent, able to derive new concepts and facts from previous concepts and facts to extend the model.

It should also be understood that specialized Agents are also responsible for creating virtual entities for sensor and actuators. Virtual entities are normalized objects, described by a common unique format, that store the state of the physical sensor or the physical actuator. A change in the Sensor Virtual Entity is a symptom of a change in the physical entity measured by the relative sensor (e.g a temperature) whilst a change in a Actuator Virtual Entity will be reflected in a change of a physical entity (e.g. a pressure inside a valve). Sequences of Virtual Entity states over time are referred as Streams. Sensor and Actuator Agents are microgateways between the physical entity and its representation into the cyberspace (Virtual entity). The Enterprise Integration Pattern nomenclature is used to create types of Agents, or "species": this is important to specify the behavior of each Agent by its type. The behavior of an Agent is a pattern as its actual instance is derived in run time and depends on some environment "traces" left by the actions of other Agents. Examples of this are "Channel Adapter Agents", able to adapt Streams between different Channels (acting as a microgateway between different data formats and protocols, so different concepts organized in different semantic networks), that depends on "maps" left by "Configuration Agents", or "Message Filter Agents" (microgateway between the entire knowledge network of the input and the subset knowledge network of interest of the output), that depends on "rules". One skilled in the art can derive easily new instances of new swarm Agents from all standard El Patterns.

The model is extended also to the User Interface: Ul Agents are responsible to visualize "concepts" consuming data from some data sources. The representation chosen to visualize some data will depend on the meaning of the data. The same data could produce totally different representations in respect of the conceptual perspective they are consumed by Ul Agents (e.g a temperature can be visualized on a thermometer gauge or on a graph, depending on whether it refers to a "room temperature" or a "weather station daily temperature").

The framework also provides also several language supports in form of

APIs, in order to facilitate the development of Swarm Agents in different languages: due to the distributed nature of the architecture, Agents implemented in different languages can exchange data seamlessly with no interoperability issues.

The following case studies demonstrate the useful contribution to the art made by the gateway device according to the invention. It will be appreciated that the following case studies are provided by way of example only and without limitation to the application of the present invention. Case study 1.

A user wishes to deploy a single loT gateway device. The user requires a physical RS485 serial interface. The user wishes to connect the RS485 physical interface onto an existing multi-drop RS485 modbus network. A Modbus network uses the Modbus Protocol as a messaging structure to establish master- slave/client-server communication between intelligent devices. The user wishes to observe the data that is present on the Modbus network, without interfering with that data. The user wishes to be able to view that data, but does not require a cloud processing entity for either configuring the gateway device, or for presenting the data, i.e. the gateway device is deployed into the field as a single, standalone entity at the edge of the data network.

The gateway device may be configured via its local web-interface or serial command line interface (CLI). The gateway device must have a physical RS485 serial port. A logical serial device process will be provided on the gateway device's DDS middleware. There will be one or more modbus processes available to the gateway device's OS level command interpreter. The modbus processes may be configured by a local configuration process (which will also be present on the DDS middleware). The gateway device will have a semantic model (SM), which will include a model of the RS485 physical interface, the modbus process, and the meta-data to associate with any modbus data. The CEP will be aware of the available services via the SM.

An application is provided and deployed onto the gateway device. This application is configured to pipe the relevant modbus data to the CEP for analysis. The application creates the relevant query, and writes that query via the OS level command interpreter to the CEP.

The CEP is subscribed to the data streams and the query. When the query matches the available data (i.e. all conditions are met), the CEP publishes the match (i.e. the event) back onto the DDS Middleware, for the application to interpret and publish via a local interface. Case study 2.

A site is under construction. The site requires perimeter security. The site manager wishes to be able to monitor and control high definition Etherent/IP cameras at six different locations on the site. He also wishes to have twenty PIRs (Passive Infrared Sensors) in place. Six of the PI Rs require serial RS485 interface control; eight of the PIRs require a 433MHz wireless interface; six of the PIRs require an Etherent/I P interface. If the PI Rs are triggered, then the site manager requires three of the cameras to swivel towards the geographic location of the trigger, and to start a video stream to a third party monitoring company. Over time, the site manager wishes to extend his security mechanisms with alarm generation to loud speakers, and automated locking mechanisms: but his budget does not permit him to put the full solution in place immediately.

Provided is a deployment of 6 gateway devices with two physical Ethernet ports which are connected to an Ethernet/I P camera and a PIR sensor; six gateway devices with an RS485 physical port connected to a PIR sensor; and eight gateway devices with a 433 MHz physical interface connected to a PI R sensor.

Each gateway device contains a semantic model (SM), which models its physical capabilities and services. There is a cloud processing entity provided which, as the gateway devices are deployed and switched on, the gateway devices 'call home' to the cloud processing entity. The cloud processing entity is used to: (a) configure each of the deployed gateway devices; (b) place the deployed gateway devices into a hive; (c) join the available agents (services) into a swarm; (d) deploy the business logic which has been written to satisfy the needs of the specific use case requirements.

Once the agents have been joined to a swarm, they no longer need to communicate with the cloud processing entity; only a single member of the swarm may be utilized for this purpose, if it's required at all. The business logic runs on the swarm. It makes use of applications, agents, hardware services, process services, OS or swarm command interpreter; DDS and CEP.

As the conditions of the business logic are matched within the CEP, the swarm business logic consumes the 'alarm' triggered by the CEP, and controls the appropriate cameras on the distributed site. The swarm does not need to push data back to the cloud processing entity in order to take the appropriate action.

When the video streams are started, the swarm pushes the video stream data to the third party monitoring company's server(s), as it was configured to do by the cloud processing entity.

It can be seen therefore that the gateway device according to the invention abstracts all its services and capabilities and publishes these on a data distribution service middleware bus which is logically available between and across all gateway devices on the swarm. This means that new gateway devices may be added to the swarm and that, when they are, they will self-publish their services and capabilities, and their services and capabilities may be immediately be usable within the context of the swarm from the virtual global user-space without requiring any replacements or programmed logic re-deployment.

Gateway devices according to the invention devices can be added at any physical location in the network and still join the swarm as long as they have a visible IP connection. This means that gateway devices according to the invention can be located in close proximity to sensors and other devices they are connected to, and make information from such connected devices available to the distributed swarm, dramatically reducing the need for physical cabling.

Furthermore, interfaces and resources are made visible within the swarm as services. This means that it is relatively simple to add redundancy by 'wiring' data flows to/from multiple service bindings. Figure 10 illustrates how, in accordance with the present invention, the hardware, software and DATA are all described by a Semantic Link Network. The software is deployed as interconnected Agents, able to expose Hardware nodes, configure the hardware interface, change other Agents behaviour, or access DATA Attributes, adding, filtering or observing them to trigger other operations on other SLNs.

One embodiment of a Software SLN is illustrated in Figure 1 1 . In this SLN, adding a node is mapped into the Device Domain into an Agent Deployment. This implies the usage of a Linux Container to sandbox the Agent environment and dependencies, and the creation of a "Script Wrapper" to expose the Agent in the Virtual Global User Space of Figure 6. The link creation is mapped to a stigmergic I PC mechanism. The Agent can communicate with other Agents, leaving data on the environment. If the data is left on a middleware, like DDS, which is able to produce a bus between different devices, data can be exchanged between devices transparently. This is a join operation between two SLNs of two Gateways. For example, to support a new sensor device, a new software Sensor Agent is derived from the Sensor Agent Template, as previously explained. Once the software is deployed into the Gateway, the SLN is updated by the Reasoner with new knowledge describing the new capability. From now on, the "Sensor" is available to an application of whatever complexity (extensibility) across the swarm, and whatever complexity of processing is possible on its data (by Complex Event Processing on its SLN). Cross-correlation of different data sources or sinks is then possible, composing totally different Domain SLNs, by a join, which will result in deployment of Agents and IPC links.

One embodiment of a Hardware SLN is illustrated in Figure 12. In this

SLN, a node creation is mapped to a new virtual Hardware node in Device Domain using a LXC facility. An Agent exposing the interface is created and added to the SLN. The link is the channel mechanism/protocol , or constraints like blocks on serial interfaces (e.g. a HW node with a "is_blocked_by" link to another Agent cannot be used).

One embodiment of a DATA SLN is illustrated in Figure 13. In this SLN, a node creation is mapped to enrichment of data in the physical representation of SLN, while deletion is mapped to filtering. The semantic rules used to modify dynamically the SLN are mapped into rules to enrich or filter DATA, and consequently the behaviour of the application. Links are mapped into Attribute relationships, so that new links can result in reconfigurations of Agents as well.

The structural mapping between joined gateways and joined SLN is shown in Figure 18. This figure represents how DDS (or other middleware) provides a logical link between Agents. A script into GW 1 exposes AG2 functions. The join between the SLN means that having this underneath I PC mechanism, logically exposes HW2 to Agents in GW1 , or that DATA from GW1 can flow and go outside using HW2, transparently. The interaction between SCRI PT exposing AG1 and script exposing AG2 is stigmergic and so highly decoupled, asynchronous, as so scalable and potentially transient.

The core of the approach of the present invention is an ontology that describes semantically all entities composing or interacting with the system, including the hardware, the software, the algorithms, the protocols and the processed data using a common unified language. This ontology is modular, distributed and can be extended. From some basic upper ontologies, Domain, Task and Application ontologies, new custom ontologies are derived. Deriving new facts and concepts that are not expressed in the ontology explicitly is the object of study of "Reasoning": through the reasoning the swarm is able to create new virtual sensors (combining some sensors of lower levels in an upper level of actionable meaning, e.g. several temperature, pressure, humidity, gas and noise sensors inside a room into a "room comfort sensor"), new applications (e.g. an Agent composition, like subgraphs into a graph, determined run time and based on a "purpose definition", i.e. "Send to a Cloud Application the average pressure over that pipe in that plant"), new configurations (e.g. "Redeploy the Agents performing this task, optimizing the average CPU or saving storage space on this device") and new virtual networks (e.g. find backup routes based on reliability, availability and health of available networks) to send the processed data stream to external destinations, run time, in an optimized way. The semantic support to describe data and the system itself, provides the capability to treat the data, the processing logic and the network at a higher level, in a holistic manner: the system awareness of the operational environment, at the "edge", is improved directly inside the gateway.

Figure 16 shows a schematic of one embodiment of developing an app into a single gateway. In order to develop an App into a single gateway, the SLN of the APP is needed. This is a structural description of the App in terms of the composing Agents and their model of interaction. The first step is to check the SLN of the gateway to find a selection matching the app structure (200). This means that all requirements of the App, in term of hardware and software, are already available in the gateway, or downloadable and/or can be created. It's a semantic search of the needs to perform a task. It should be noted that this approach is in contrast to the approach in respect of a conventional loT Gateway: instead of predefined embedded software, the conceptual function of the App is the primary interest, so the semantic search is intended to "prepare" the field in order to dispatch the function. Many realizations of the function are possible, and for this purpose all tools/theories available in the semantic world represent an endless portfolio of solutions. Thus, it's a matter of finding the optimal solutions using semantic and graph theories. For example, if the interest is give me a high priority alert when the value of pressure in that pipe is too high, there are an infinity of use cases for this scenario. Having a knowledge of who is "me" (such as a list of available destinations, i.e. mqtt brokers, REST APIs, sms, a LED on the front of the gateway, a GPIO), "high priority" (select the most reliable outbound interface, or all available interfaces in that moment), "value of pressure" (find the Agent capable to "decode a pressure"), "that pipe" (find the Agent associated to that pipe, sensor on that pipe if any), "too high " (what are the rules to define "too high" a value on the stream generate by the previous Agent), it is always possible to generate a path to transfer high level event based data. The availability of the nodes (agents) are then checked by querying the SLN of the gateway by the semantic engine (205). If all agents are available (210), the app SLN is translated into script interpreter commands (215). The script and agents constraints are then checked against the gateway (225), and if the script is deployable (230), the app is deployed on the gateway (235). If all agents are not available, or if the script is not deployable, the app is not deployable on the gateway (220).

It should be noted in this regard that there is difference between the check "all agents available" (the functionalities are available somehow in the SLN Domain) and "script deployable" (check the physical constraints in the Device Domain, e.g. space, memory/CPU load),

Figure 17 shows a schematic of the deployment of an App into multiple gateways. It will be noted that steps 300 to 330 of Figure 17 share the same concept as steps 200 to 235 shown in respect of Figure 16, but in this case the semantic search has been extended to a bigger availability of Agents (functions), hardware, including outbound interfaces, power, said more knowledge. It will be understood that this is extensible with potentially no limit.

An ontology describing the Entity Relationship Model of the gateway is provided in order to describe semantically all entities composing and interacting with the gateway: this stores the SLN model for software, hardware and data.

Each microgateway or "Agent" is specialized to perform one task, and it exposes semantically described capabilities. It can also change its behavior by means of special inputs called "rules" and "maps" depending of its species. Outputs from some Agents can become Input for other Agents or can change their behavior. The approach is stigmergic: a change in some environment characteristic due to a trace left by an action of an Agent, stimulates a different action or a different behavior of another Agent. The Publish-Subscribe Pattern is an example of this model of interaction even if in that case there is a need of a contract between the publisher and the subscriber; in the Stigmergic Pattern introduced, the producer leaves a trace somewhere without the need to know about the consumer and viceversa. They can be created in totally uncorrelated time slots, and there is no need to create management mechanisms to handle shared buffers, because the shared resource is the environment itself within a context, and always available. The configurations and the behavior rules are like a shared memory distributed across the entire system. When an Agent terminates its task, it dies.

By using Linux Interprocess Communication to create channels of interactions between Agents, and applying OS "free" mechanisms like buffering, querying and process management to these interactions, and to the lifetime of the Agents, it creates an extension to the standard set of Linux commands, providing a "Bash for loT" that is a powerful scripting environment to create loT applications in the Linux user space using a Model Driven Development approach. Bash is only a choice to implement a Script Interpreter: other languages like Python and Nodejs could equally well be used.

Linux Containers are provided in order to facilitate the hardware abstraction, and the software installation. Virtual hardware interfaces can be created, added and destroyed in run time, and the access to them is controlled in the user space. This is an enabler for the lifecycle of the nodes in the SLN, and provides a security feature to sandbox disjointed SLNs on different domains (e.g. in practice Administrator capabilities from User Capabilities, hardware and software related in a configuration from others HW/SW configurations and different Access Control Domains). By using Linux Containers to create "cells" into the "hive" of Agents, agents performing a common task are totally relegated, and their action doesn't affect the rest of the hive and therefore the device functionality. This creates a logical separation between domains, and is used to separate Control and Configuration Domains, with Administrator grants from Application domains. This configures the possibility to deploy Multi Applications and even Multitenants solutions. Third part Agents can also be added to the swarm using a "swarm enabling" wrapper, with no harm for the hive.

The present invention provides a technology that enables creation and destruction of communication links between software entities (like links in a SLN), abstracting the network layer, decoupling the nodes using a data-centric approach through the use of the Data Distribution Service middleware implementing a Publish Subscribe pattern. The choice of DDS is optimal but not mandatory in order to perform the middleware function of the invention. The advantage of the middleware is that it enables the boundaries of the cell to be overcome. The middleware is able to separate domains through a virtual networking approach. It also provides an abstraction of the underneath network using a typed approach for data modelling and provides the interfaces to exchange data. This is a perfect fit to implement the edges into the graph model. Data flows through pipes or Linux IPC channels inside the cell, and through the middleware between cells. Extending the middleware over the device boundaries, extends the landscape to other devices and extends the stigmergic communication to them. Agents can also migrate through the middleware to perform their task on other containers and devices.

The invention provides several advantages over existing systems. These include real-time data collection and aggregation, within a single silo; unique integration and aggregation of data, across multiple silos, using only a query language in the user domain; removal of the requirement of prior-knowledge of properties of data, formats of data, programming languages; and operational context.

The invention also enables: wireless gateway devices according to the invention to be added to a system infrastructure on an as and where-needs basis. It provides seamless integration with existing, pre-installed, gateway devices; seamless "port count" extension to an existing, pre-installed, network infrastructure, without requiring any device-replacement or additional cabling. It also enables the integration of new and emerging monitoring technologies, without requiring any device replacement or additional cabling; existing complex event processing, user configuration and user applications programming to remain unchanged, while simultaneously adding new complex events, configuration and applications to the logical domain.

The gateway device of the invention provides the ability to:

a. create an edge-of-the-network swarm of data sources (e.g. sensors). The data sources are not limited to being connected to a single physical entity, and they do not require any cloud based services to operate as a single eco-system (swarm) of data sources. There may be multiple data sources, each with potentially different data formats and data rates. Each data source may be geographically displaced, and may represent data from separate and disparate domains (e.g. using different data formats and protocols).

b. create an edge-of-the-network swarm of data sinks (e.g. actuators). The data sinks are not limited to being connected to a single physical entity, and they do not require any cloud based services to operate as a single eco-system (swarm) of data sinks. Each data sink may be geographically displaced, and may represent actuators on separate and disparate domains. c. create an edge-of-the-network swarm of services. The services are not limited to being available on a single physical entity, and they do not require any cloud based services to operate as a single eco-system (swarm) of services.

d. annotating, in real time, meta-data (semantic information) to the data sources that are available on an edge-of-the-network swarm.

e. gateway device self-discovery of data sources, data sinks, and services, together with annotated semantic information, that enables each of the individual agents in a swarm to immediately make use of the data sources, sinks, services and semantic information.

f. enable complex events, distributed across many physically separated gateway devices and data sources, to be aggregated, analysed, and processed in real-time, by the swarm entity at the edge-of-the-network. This method does not require any cloud based services, nor does it require any specific programming or embedded-clients at the edge-of-the- network.

g. Enable gateway devices (and, specifically, the swarm agents within the gateway devices) to: join an established and deployed swarm; publish their services and capabilities (e.g. hardware services, data sources, protocol services, analytics services, loT services) to the swarm; discover and utilize the services that already exist in the deployed swarm; and contribute events to the swarm's complex events processing engine: without requiring the previously deployed devices to be uninstalled, re- commissioned or re-configured.

h. securely deploy new capabilities (e.g. services, applications, rules, logic, algorithms) to the swarm entity.

i. enable the complex event processing within the swarm to combine events that occur within the swarm itself and /or with events that are available on the world-wide-web. It will be appreciated that the present invention acts as an Internet of Things Gateway. In order to perform this function, the gateway is redefined as a Gateway between Semantic Link Networks and its structure is described as a SLN as well. As a result of this structure, the invention provides the following advantages over conventional gateway device architectures:

1 ) Automatic discovery of new nodes (links) is feasible, with the relevant amount of associated metadata.

2) The evolution is feasible, redistributing and redefining links. The SLN is dynamic and can handle also transient interactions.

3) Reasoning is feasible, as relational reasoning and analogical reasoning are naturally supported by SLN. A self-organization arises from the consensus of the rules, without a centralized control.

This is in contrast to the features provided by a conventional loT Gateway device where the installation of new devices (network devices or sensors) into pre-existing infrastructure, or even the extension of the capabilities is complicated, difficult and time-consuming. Furthermore, the evolving of an infrastructure is complicated, especially for embedded bespoke legacy systems.

While the invention has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in character, it being understood that only exemplary embodiments have been shown and described and do not limit the scope of the invention in any manner. It can be appreciated that any of the features described herein may be used with any embodiment. The illustrative embodiments are not exclusive of each other or of other embodiments not recited herein. Accordingly, the invention also provides embodiments that comprise combinations of one or more of the illustrative embodiments described above. Modifications and variations of the invention as herein set forth can be made without departing from the spirit and scope thereof, and, therefore, only such limitations should be imposed as are indicated by the appended claims.

The embodiments in the invention described with reference to the drawings comprise a computer apparatus and/or processes performed in a computer apparatus. However, the invention also extends to computer programs, particularly computer programs stored on or in a carrier adapted to bring the invention into practice. The program may be in the form of source code, object code, or a code intermediate source and object code, such as in partially compiled form or in any other form suitable for use in the implementation of the method according to the invention. The carrier may comprise a storage medium such as ROM, e.g. CD ROM, or magnetic recording medium, e.g. a memory stick or hard disk. The carrier may be an electrical or optical signal which may be transmitted via an electrical or an optical cable or by radio or other means.

In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

Tables

Table 1 Component Description

Virtual Network Provides a Network Abstraction Service, which enables the

Applications to use Virtual Network services, regardless of any hardware bindings.

DDS DDS stands for Data Distribution Service. The Data Distribution

Service for Real-Time Systems (DDS) is an Object

Management Group (OMG) machine to machine

Middleware ("m2m") standard that enables scalable, real-time, dependable, high-performance and interoperable data exchanges between publishers and subscribers. DDS specifies a publish-subscribe model for sending and receiving data, events and commands amongst DDS nodes.

Script Interpreter The Script Interpreter is a bespoke DDS-aware interface

between the Application Space and the Virtual Network, OS Services, and Libraries.

Swarm Linux This is a set of Swarm- and DDS- aware Process Services, Command which are available via a Command Interpreter on the

SmartSwarm OS.

This is the command-interpreter which enables the Swarm logic and Services distribution between Agents within a Swarm.

LXC LXC is a Linux Container technology, which offers an

environment as close to that of a Virtual Machine, but without the overhead that comes with running a separate kernel and simulating all the hardware.

This is achieved through a combination of kernel security features such as namespaces, mandatory access control and control groups.

Swarm Semantic This is the semantic-model of the Swarm: This model holds Model (SSM) semantic information about each of the the Devices and their capabilities. Whenever a Device joins a Hive, it will make it's Semantic Model available to the Swarm.

Complex Event There is a Complex Event Processing Engine component, Processing (CEP) which may or may not be on every Device. This component must be on a Swarm. This engine is optimised and tuned for use with the SSM. The CEP Engine is further capable of processing complex events that are not confined to the closed- system Swarm: The CEP may additionally extend to enable queries that includes data that's available via Linked Data across the world-wide web.

Table 2 Tag Label Represents Example Comments

SmartSwarm A physical A deployed Each physical Device may have Gateway Device SmartSwarm Gateway different physical (hardware)

3000 device, which interfaces.

has been configured Each Device may use all of the to be part of a Hive, hardware Services available and whose Agents are across the Swarm.

available in a Swarm.

SmartSwarm An Agent which A Swarm software It may contribute Services to the Node is available in entity that is not bound Swarm, and it may consume the the Swarm. by specific hardware. available Swarm Services.

Hla Hardware RS232 Serial port Serial port to enable device

Interface a connectivity with a control machine or a Terminal

Hlb Hardware RS485 Serial Port Serial port to enable device

Interface b connectivity with PLCs

Hlc Hardware Ethernet Port 0 Ethernet port to enable device

Interface c connectivity on a wired network

Hid Hardware Cellular Modem Cellular interface to enable

Interface d connectivity on a cellular

network

P1 Process 1 An Agent that takes Inputs: Hla, Hlb, C P1

input from the physical Outputs: P2

serial interfaces, and

the configuration

component C1 ;

Provides output

required by P2

P2 Process 2 An Agent that takes Inputs: P1 , Hlc, P3

input from P1 and P3, Outputs: P4;

as well as from the

physical ethernet port.

Provides output to P.

P3 Process 3 An Agent that takes Inputs: Hid

input from the physical Output: P2

cellular interface.

Provides output to P2.

P4 Process 4 An Agent that takes Input: C_P2, P2

input from C_P2 and Output: Cloud Processing P2. Provides output to

the Cloud.

Output is typically

either a full Data Set,

or a Request for

Action from the Cloud.

Table 3

Claims

1 . An edge loT gateway device for an Internet of Things data network, said edge loT gateway device comprising:

2. The edge loT gateway device of Claim 1 , wherein the semantic information for the edge loT gateway device comprises a semantic link network modelling the edge loT gateway device.

3. The edge loT gateway device of Claim 2, wherein the semantic link network models the software and the hardware of the gateway and all data passing through the gateway.

4. The edge loT gateway device of Claim 2 or Claim 3, further comprising a semantic engine to query and update the semantic link network.

5. The edge loT gateway device of claim 4, wherein the edge loT gateway device comprises an event processing engine interfaced with the semantic engine configured to gather data streams from the data distribution service and to use a query language to match received data streams with queries and to publish results of matched queries onto the data distribution service.

6. The edge loT gateway device of claim 5, wherein the event processing engine can learn of any available services in the form of available software agents implementing the nodes of the semantic link network from the stored semantic information and can update the stored semantic information.

7. The edge loT gateway device of claim 6, further comprising a script interpreter for creating and deleting the software agents.

8. The edge loT gateway device of any of the preceding claims, wherein the data distribution service is configured for real-time sharing of services in the data network with the one or more other similarly configured edge loT gateway devices.

9. The edge loT gateway device of any of the preceding claims, wherein the data distribution service comprises a logical common bus between the edge loT gateway device and the one or more other similarly configured edge loT gateway devices, making the services in the form of available software agents of each edge loT gateway device available to all other edge loT gateway devices.

10. The edge loT gateway device of any of the preceding claims, wherein the data distribution service comprises the Data Distribution Service for Real-Time Systems (DDS) which comprises an Object Management Group (OMG) machine to machine Middleware ("m2m") standard.

1 1 . The edge loT gateway device of any one of claims 7 to 10, wherein the script interpreter is configured to create and delete the software agents dynamically in order to create any combination of: logic, rules, data, meta-data, and services between the edge loT gateway device and the one or more other similarly configured edge loT gateway devices.

12. The edge loT gateway device of any of the preceding claims, wherein the OS level virtualization environment on the edge loT gateway device comprises a virtual machine.

13 The edge loT gateway device of any of Claims 7 to 12, wherein the combination of the DDS, the script interpreter, the software agents, Linux containers and Linux I PC mechanisms realize a virtual global user space.

14. The edge loT gateway device of any of claims 7 to 13, wherein the software generated by the script interpreter is configured to provide the semantic information for the edge loT gateway device to the one or more other similarly configured edge loT gateway devices when the edge loT gateway device is connected to the data network and/or when the edge loT gateway device joins one or more other edge loT gateway devices in the data network to form a logical distributed data processing entity realizing a join operation between the respective semantic link networks modelling the edge IOT gateway devices.

15. The edge loT gateway device of any of the preceding claims, wherein the OS is configured to provide a kernel space and a user space.

16. The edge loT gateway device of any of the preceding claims, wherein the virtualization environment of the edge loT gateway device is configured to combine with virtualization environments of the one or more other similarly configured edge loT gateway devices to provide a virtual global user space for a logical distributed data processing entity formed by said edge loT gateway device and one or more other similarly configured edge loT gateway devices.

17. A method of processing data in an Internet of Things data network, said method comprising:

provisioning an edge loT gateway device according to any one of claims 1 to 16 at an edge of the data network;

receiving data from the network via the data distribution service or from other edge loT devices;

processing said received data through the use of a semantic link network model; and

publishing results of the processing onto the data distribution service to reach other edge loT devices.

18. A computer readable medium storing machine readable instructions executable by a processor of an edge loT gateway device for implementing the steps of the method of claim 17.

19. A data network comprising a plurality of edge loT gateway devices according to any one of claims 1 to 17 and a network level entity, said network level entity being arranged to:

configure each of the plurality of edge loT gateway devices;

arrange said plurality of edge loT gateway devices into a single logical entity whereby said devices share their agents and rules-based logic; and logically group the agents of the plurality of edge loT gateway devices to form a logically distributed data processing entity.

20. A method of forming a logically distributed data processing entity in a data network, comprising:

providing a plurality of edge loT gateway devices according to any one of claims 1 to 17 and a network level entity;

arranging said network level entity to:

configure each of the plurality of edge loT gateway devices;

arrange said plurality of edge loT gateway devices into a single logical entity whereby said devices share their agents and rules-based logic; and

logically group the agents of the plurality of edge loT gateway devices to form said logically distributed data processing entity.