IoT Agent Architecture

An architecture sketch is presented in figure 1. The learning system presents a publish/subscription architecture pattern, on its external communication with its clients (devices, applications or services) as well as in its internal logic. On the one hand, the clients communicate by publishing asynchronous messages to which the IoT Learning Agent (LA) or LAs are subscribed. On the other hand, the Models subscribe to the data, provided by the clients, through Statements/queries; and sending back by publishing the selected information by its clients. The internal and external pub/sub architecture allows the system to distribute the data processing into external or internal processing nodes, depending on the needs. E.g. having the processes p1 and p2, where p1 = c (b+c) and p2 = d (b+c); the process can be split such that pi = a+b then p1 = c pi and p2 = d pi. Each process is transformed into statements, in which can be deployed into one LA or several. In case of being deployed into one LA, the processing nodes subscribe to each other internally. While in the case of several LA, the subscriptions are between LAs distributing the processing in different services. Furthermore, the LA uses the Broker as data source, data recipient, control input and output. All those roles of the Broker can be realized by one Broker (as is shown in 1) or several, one per role. Regarding the data heterogeneity in the IoT, the system managed in twofold. Firstly, the different types of data payloads and data sources are separate in different topics. Secondly, the fusion or transformations needed on the data are made by Statements and put them together in internal streams or published externally in their corresponding topics. The internal streams are managed by Handlers depending on the type of statement produced the stream. The system orchestrate all the streams involved on the learning process of the Model through the Learning Request. While, each Model is responsible of evaluation themselves, and this process is done by the Evaluator.

The current implementation realized the architecture as follows. The Broker or Brokers role is taken by the MQTT mosquitto Broker. The real connection between the LA and one Broker is established and managed by the BrokerService. This means that there is one BrokerService per Broker in the deployment, and the connections are established using Paho clients. While the logical connections between the components and the Broker/s is managed by StaticBroker. This means, there are as many StaticBroker instances as there are components using a connection to a Broker. These logical connections are managed by one thread per topic, and each topic has a queue. I.e. in the Figure 1 there are one Broker deployed and five components that use a connection to that broker, therefore there is one BrokerService and five StaticBroker. The Feeders are the components that managed the types of payloads, which are: data/events, statements, and learning request, managed by EventFeederService, StatementFeederService, and CEMLFeederService, respectively. The event payload enveloped is based on the OGC SensorThing standard [26]. The Statements are deployed in the CEP engines by the StatementFeeder, which are access by the CEPWrappers. The CEPWrappers handles all the CEPWrappers as a single entity, while the CEPWrapper hides the complexity of each CEP engine implementation. In the current LA implementation, there are two CEPWrappers one for Esper CEP [14] and one for WSO2 CEP [41]. Each Statements inside the CEP engine produce streams which in a LearningRequest fall in three categories: learning streams, deployment streams, and auxiliary streams. The learning streams are the input of the Models and are used by the Evaluator for evaluation as well. The contentious learning process is known as learning process, and is managed by LearningHandler. The deployment streams are the streams to be used when the Model has been evaluated as deployable by the Evaluator; and the streams are publish by the CEHandler on the output Broker accordantly to the Statement. The auxiliary streams are used as internal processing nodes by the learning streams or deployment streams, and their visibility is restricted to the CEP engine itself. Therefore, they don’t have any handler. Finally, the Models hides the complexity of learning algorithms to the system and provide a common interface. In the current implementation, there are two Model implementations, one for classification problems using Weka [24] UpdateableClassifier several implementations; and one for regression using Auto-Regressive which uses Artificial Neural Networks implemented by deep learning 4j [34].