Tag Archives: edge

IoT reference architecture for the edge domain

During my talk at Thingmonk last week, I showed the snippet of an IoT reference architecture that I developed covering the edge gateway domain.

Since I’ve yet to find amongst the many published IoT reference architectures any that decompose the edge and because several people asked for a copy, I thought I’d share it here for people to reuse. It’s simple but hopefully useful, and provides a starting point for proper design of solutions that exploit the edge.

Architecture overview diagram

iot-edge

Explanation of capabilities

The reference architecture shown above describes the key set of technology and organisational capabilities required in the deployment of edge applications.

Technology

  • Physical security mitigates the risk of tampering when devices are deployed in the field.
  • Device platform security protects the software platform, application code and data from unauthorised access.
  • The Device provides the hardware platform for application code and logic deployed at the edge.
  • Analytics models describe deployed analytics logic consumed by analytics runtimes in the edge software platform.
  • A Local Area Network provides the mechanism for the device to communicate with locally deployed applications, sensors and actuators, e.g. Bluetooth Low Energy, Zigbee etc.
  • Local Monitoring and Management tools enable administration and break/fix by local technicians servicing the installed hardware and software.
  • A Remote Monitoring and Management agent on the device enables diagnostics, monitoring and control of edge devices from the centre. This would be the preferred mode of operation since it does not require physical access to the deployed system.
  • Sensors and Actuators provide the link between the assets themselves and the device.
  • Assets monitored and controlled by the edge installation — i.e. the “things”.
  • Local applications support business operations conducted in the field.
  • An Application Runtime provides the programming environment for application logic deployed at the edge, e.g. NodeRED.
  • Control code is application logic deployed in the Application Runtime to orchestrate interactions with sensors and centre.
  • Sensor SDKs (Software Development Kit) facilitate development of sensor-driven applications to run at the edge by providing developer-friendly programmatic access to the sensor hardware.
  • Back-end SDKs facilitate communication with the centre by providing developer-friendly programmatic access to services at the centre and/or provided by third-parties.
  • A Wide Area Network connects the device to the data centre, for example via a cellular network or via wifi to the corporate network.

Organisational

  • Device and asset management is the central service management capability that deals with the ongoing monitoring and support for the hardware and software installation in the field.
  • Device installation and maintenance is the field-based service that installs and maintains the physical device, sensors and assets deployed in the field.
Advertisements

Using the new MQTT v5 client in Expeditor 6.2

With the launch of Expeditor 6.2 comes the next generation of the MQTT client. MQTT is IBM’s specialist messaging protocol designed for use in fragile or expensive networks (e.g. mobile or satellite links) and in constrained devices such as sensors and mobile devices. This latest version (version 5 of the protocol) adds a number of features including the following:

  • Support for the point-to-point (i.e. queues) as well as the traditional pub/sub messaging paradigm.
  • Different payload types such as a textual string in addition to the basic byte array of the previous client.
  • The ability to specify whether an individual subscription is durable (i.e. survives a disconnection and continues to collect messages) or not on a per-subscription basis. In the previous incarnation, the durability of a client’s subscriptions was specified for the whole client. This could mean resources within the broker were consumed by unnecessarily durable subscriptions.
  • The ability to connect to a messaging server over SSL and using authentication credentials.
  • A variety of additional header information for messages including expiry and priority as in JMS.
  • The ability to start and stop message delivery without having to disconnect and reconnect again. This allows the application to control the flow of messages without the overhead of a full connection handshake each time.

Full details can be found in the Javadoc but I’ve included a simple sample here to get you started.

Install the MQTT v5 client into the Expeditor client runtime

In Expeditor 6.2, the MQTT v5 client is not installed by default with the base client installer. You will need to install it as an additional feature from the update site contained in desktop/updates/platform folder in the install media, even for use in the toolkit. A screen shot showing which feature is required is shown below.

image

Sample MQTT application

The following examples show a class that connects to a broker and subscribes durably for messages and a class that publishes a message. The subscriber makes use of the message delivery start/stop feature to enable message delivery only when both subscriptions are in place. You will see that I’ve included some tests that determine the type of payload of a given message as well.

Notice the different package/plug-in name for the v5 MQTT client.

import com.ibm.micro.client.MqttCallback;
import com.ibm.micro.client.MqttClient;
import com.ibm.micro.client.MqttConnectOptions;
import com.ibm.micro.client.MqttDeliveryToken;
import com.ibm.micro.client.MqttDestination;
import com.ibm.micro.client.MqttException;
import com.ibm.micro.client.MqttMessage;
import com.ibm.micro.client.MqttSubscriptionOptions;

public class MqttSubscriber implements MqttCallback {

private MqttClient mqttClient = null;
private String TOPIC_SUFFIX_ALERTS = “alerts”;
private String TOPIC_SUFFIX_DATA = “data”;
public MqttSubscriber() {
super();
}
/* MQTT Client API */
public void connectionLost(Throwable arg0) {
//
System.out.println(“Connection to the micro broker lost”);
}

public void deliveryComplete(MqttDeliveryToken arg0) {
//
}

public void deliveryFailed(MqttDeliveryToken arg0, MqttException arg1) {
//
}

public void messageArrived(MqttDestination destination, MqttMessage message) throws Exception {
System.out.println(“Message has arrived over MQTT.”);
String sourceTopic = destination.getName();
// In MQTT v5 we have different payload types.
if (message.getPayloadType() == MqttMessage.PAYLOAD_TEXT) {
String payload = message.getStringPayload();
System.out.println(“Message payload: “+payload);
} else {
// Enforce a “text only” policy.
System.err.println(“Message is not a text string.”);
}
}

public void start(String mqttUri, String name) throws MqttException {
mqttClient = new MqttClient(mqttUri, “Sub_Client”);
mqttClient.setCallback(this);
MqttConnectOptions options = new MqttConnectOptions();
// Wait until we’re ready to receive messages (overrides default)
options.setAutoStart(false);
// We don’t want our state cleaned up, we need to keep
// Durable subscriptions.
options.setPurge(false);
// Connect
mqttClient.connect(options);

MqttSubscriptionOptions subOpts = new MqttSubscriptionOptions();
subOpts.setDurable(true); // We want durable subscriptions
subOpts.setQos(2); // Once and once only delivery (same as V3 QoS).
mqttClient.subscribe(“acme/sample/”+name+”/”+TOPIC_SUFFIX_ALERTS+”/+”, subOpts);
mqttClient.subscribe(“acme/sample/”+name+”/”+TOPIC_SUFFIX_DATA+”/+”, subOpts);
// Ready to receive.
mqttClient.startListening();

System.out.println(“Connected to “+mqttUri);
}

public void stop() throws MqttException {
//
mqttClient.disconnect();
}

}

The following is the complimentary part of the sample that shows how to publish a message using the v5 client. This class is intended to be run as a simple command line utility.

import com.ibm.micro.client.MqttClient;
import com.ibm.micro.client.MqttException;
import com.ibm.micro.client.MqttMessage;
import com.ibm.micro.client.MqttTopic;

public class MqttPublisher {

public static void main(String[] args) {
try {
// Parameters: <uri> <clientid> <topic> <qos: 0,1 or 2> <string data>
MqttPublisher publisher = new MqttPublisher(args[0], args[1]);
publisher.publish(args[2], Integer.parseInt(args[3]), args[4]);
} catch (Exception ex) {
ex.printStackTrace();
}
}
private String uri = null;
private String clientId = null;
public MqttPublisher(String u, String c) {
uri = u;
clientId = c;
}

public void publish(String topic, int qos, String payload) throws MqttException {
MqttClient client = new MqttClient(“tcp://localhost:1883”, “Pub_Client”);
client.connect();
// Notice the new object model for destinations and messages
MqttTopic t = client.getTopic(topic);
// Create a string payload — v5 discriminates between payload types unlike v3.
MqttMessage message = new MqttMessage(payload);
message.setQos(qos);
t.publish(message);
client.disconnect();
}
}

Enjoy !

Lotus Expeditor integrator is here

We recently announced a new addition to the Lotus Expeditor family, the Integrator. The Integrator provides a small-footprint integration hub for edge of network applications that link back into the enterprise (e.g. a retail branch or warehouse).

Expect to see some more integrator-related posts in the future — having worked directly on the product 🙂 I am looking forward to working with it now it is available.