MobiusFlow has been developed as an MQTT object bus which normalises all device data into standardised MobiusFlow objects which allow interoperability between all devices either real or virtual in the field or Cloud.
MobiusFlow enables actuators, sensors & controllers to connect, control and communicate with each other and to the Cloud so that IoT solutions using scalable monitoring, visualisation and predictive analytics can provide valuable insights into your business and act upon them automatically.
- A complete control and communications platform
- Microservice based architecture
- Secure, open protocol based on MQTT
- Scalable to 1000s of devices
- Platform and language independent
- Does not depend on a network connection for local control
- Provides full discovery of nodes, objects and resources in all directions
- Pub / Sub change of value notifications
- All sensor and actuator data is normalised from any source such as OPC UA/ BACnet/ DALI/ EnOcean/ LoRaWAN / Analog / Digital etc.
Built from the ground up
MobiusFlow has been built from the ground up as a micro service based design with a simple but common set of API commands.
All communication between micro services is performed using the MQTT protocol, ensuring that micro services can be written in any programming language and will run on any device capable of TCP/IP network communications. The only requirement for any MobiusFlow system is that it contains at least one Node.
This Node consists of a MobiusFlow Hub which initiates and facilitates communication between micro services in a secure way. Micro services can run on the same device as the Hub, or on another device such as a temperature sensor, connected to the Hub via a connection capable of transmitting via TCP/IP (provision has been made for future expansion, by adding translation services, to allow micro services to communicate with the Hub over any transmission medium capable to transmitting binary data).
Each Node is typically a stand-alone island which does not require any connection to any other device in order to perform local control. Nodes can be connected together via secure MobiusFlow Routers allowing the creation of a network of interconnected Nodes. When used in this configuration, Nodes can share data with each other and influence the control algorithms running on any connected Node.
The standard MQTT has some limitations in its usefulness as a peer to peer messaging and control protocol. It is based around the Publish / Subscribe pattern which is ideal where multiple devices are sending data to a single end point for logging etc.
MQTT can be used where devices or services need to have a two way peer to peer flow of communication but the different services need to be aware of each other at design time.
MobiusFlow defines a protocol layer above MQTT which enables discovery of devices and services at runtime and then allows two way peer to peer communication to take place, ensuring that new devices and services can be added at any time without having any design time knowledge of the other devices and services in a system.
Mobius system
A typical MobiusFlow system consists of a single or multiple MobiusFlow nodes connected together via a TCP/IP network. Each node is capable of operating independently of the rest of the system, but nodes can interact with each other to form a complex system. All node interaction takes place through one or more brokers via a node’s router. In a multi-node system, the location of the broker is not important. It can reside on the same device as one of the nodes or on an independent device.
Each node is classed as, and exhibits the behavior of, an edge computing device. In this context edge devices are not only field devices but could also be on the edge of a server or cloud server providing the server with connectivity to all of the true edge or field devices.
Mobius nodes
A Mobius node consists of a central Mobius hub, one or more Mobius services and optionally one or more Mobius routers.
Services contain the service logic and an object data store. Connections to sensors, actuators and other communication interfaces such as Modbus or BACnet can be added depending on the service’s purpose and controlled through the service’s logic.
The object data store models the physical or virtual connections and provides a standardised method for services and other nodes to communicate and share data with each other through Mobius objects.
All of the communications between services through the hub or nodes through routers and brokers is based on the MQTT protocol. The MobiusFlow protocol has been defined on top of this MQTT protocol providing a well-defined API enabling different physical devices and protocols to communicate with each other in a consistent way.
Mobius nodes follow the microservice architecture pattern, where each service is a stand-alone process capable of communication with other microservices creating a large application from small manageable pieces.
Routers are used to cross node boundaries. They provide a secure mechanism for nodes to share data using the MobiusFlow protocol.
Logical structure of a node
The logical structure of a node is detailed below. This diagram shows the hierarchical relationship between all of the parts which make up a node and how objects contain resources, services contain objects and hubs connect to services and routers.
The Mobius URI structure allows addressing any part of a node at any depth.
Hubs
A Mobius hub is the foundation of a node. At its heart, a Mobius hub is just an MQTT broker which manages and links Mobius services and Mobius routers. Hubs are responsible for ensuring that all services and routers are valid members of a node by verifying their pre-shared authentication key on connection.
Each hub within a Mobius system is given a unique ID. This is a six digit hex number which forms the first part of the Mobius URI hierarchy. When referencing a hub, for example during a discovery process, this unique ID must be used (see MobiusFlow Uniform Resource Identifiers).
When service or router connects to a hub, and has been validated, the hub provides it with a copy of the Mobius object profiles and pre-shared keys files, ensuring that all services and routers connected to the hub are able to communicate and understand one another.
Services
Mobius services are the engines which drive MobiusFlow. Each service is essentially a microservice performing a specific task and possibly acting as an interface to a piece of hardware or a 3rd party service such as Microsoft’s Azure platform or the IBM Cloud.
All services MUST implement the full MobiusFlow protocol to enable them to connect to hub and communicate with other services. In addition to implementing the MobiusFlow protocol, services can create Mobius objects to store and share data and can also contain service specific logic to perform the task that they are designed for. When creating services, try and keep them focused on one task and create additional services to perform other tasks. This ensures that services are reusable and Mobius systems can be configured to only contain the logic that they require.
Each service within a Mobius node is given a unique ID. This is a three digit hex number which forms the second part of the Mobius URI hierarchy. When referencing a service, for example during a discovery process, this unique ID must be used (see MobiusFlow Uniform Resource Identifiers).
Routers
Mobius routers control all MobiusFlow communication into and out of a node. This ensures that nodes are secure and allows nodes to discover each other within a MobiusFlow system.
Routers are split into two parts, one side of the router communicates internally with its associated hub and all of the services within a node, while the other side of the router communicates externally through a ‘no-mans’ broker to other routers on other nodes. All external communication is done using MQTT over the WebSocket protocol. This could be done over a secure or non-secure connection (ws:// or wss://).
Routers are capable of routing messages between services belonging to different nodes, essentially allowing a service on one node to read, write and subscribe to change-of-value events on objects in another node.
Mobius objects
The key to the MobiusFlow system is Mobius objects. These objects typically model real-world objects and provide a mechanism for sharing data and storing state in a consistent way. Each object has a unique identifier or Mobius URI which can be discovered and used by any part of the MobiusFlow system.
Mobius objects are predefined in an object profiles file which is passed to a services by the hub when a service connects.
Each object within a Mobius node is given a unique ID. This ID consists of two parts and is made up of the object profile ID (PID) which describes the object’s type, and the object’s instance number (INS). The PID is a four digit hex number which forms the third part of the Mobius URI hierarchy and the INS is a four digit hex number which forms the fourth part of the Mobius URI hierarchy. When referencing an object, for example during a discovery process, this unique ID must be used (see ‘MobiusFlow Uniform Resource Identifiers’ on our support site https://docs.mobiusflow.com/ ).
Object resources
Mobius objects contain one or more resources. It is these resources which are used to define objects that mimic or represent real-world objects. An example of a single object is a room temperature sensor. This object may have resources which define the sensor’s name, location, asset reference, engineering units, set point and actual measured value.
Each resource is capable of storing a single value which can currently be of type Boolean, Number, String, DateTime or TimeSpan. Resources also store meta-data about the value. The actual meta-data depends on the value type chosen. Resources can be read only or read/write. Read only resources have their values set when they are created.
Each resource within an object is given a unique ID. This is a two digit hex number which forms the fifth and final part of the Mobius URI hierarchy. When referencing a resource, for example during a read, this unique ID must be used.
Security
The MobiusFlow architecture is designed to allow efficient communication for IoT Devices whilst providing structure and definable trust boundaries.
There are 2 ways to move messages to and from a mobius node one is via the mobius router designed for this task, and preserving the integrity of the message within the node. the other is with a dedicated service, this breaches that integrity to a degree but may be desirable and even necessary in some situations.
Node Internal Communication
With each node consisting of the base of a hub and one or more services, and optionally routers. If for the purpose of this initial discussion assume that the services are only communicating with local hardware, or handling logic, therefore having no mechanism for communicating off of the local hardware. We will discuss how this can be achieved later on.
As the hub is created a pre-shared key (psk) file is generated, these can also be changed using the configuration service. each valid service must have a copy of its psk, to successfully authenticate with the hub. The hub will have the corresponding psk in its psk file. This key is used as a secret key as part of a JSON Web Token (JWT).
Service Authentication
When a service connects to a hub it uses the MQTT built in username / password authentication. The MQTT username is the service’s profile ID (PID) and service (SID) 001F/01F and the MQTT password is a JSON object containing the services PID and SID with a timestamp which is then converted into a JWT (JSON Web Token). The time stamp ensures tight time synchronisation is a requirement and provides greater integrity.
If the service signs its JWT with the same psk as is stored in the hub’s psk file it will successfully complete the authentication process to the hub. On doing this it will be sent a copy of the hubs psk file, giving the service the ability to the received directly signed messages from authorised services.
After successful authentication the service will have a copy of the psk of all services that are authorised to communicate through the hub. The service will then with no further action from the hub be able to validate the authenticity and integrity of messages that have come from a service on the same node.
Service Communication
Once passing traffic the MQTT message will consist of:
The JSON Web Token will also carry the topic, the message payload itself, and a timestamp this will all be hashed along with the service own key creating a HMAC to allow integrity checking:
The time stamp will allow for the message to have a validity life span that can be configured for all services connected to the hub. Internally all messages will be signed in this way and therefore provide a high degree of integrity to the internal communication.
Services may be intentionally created to connect to external interfaces such as a service the connects to remote I/O via TCP/IP or an Azure IoT hub Client, if it is desired to configure a node in this scenario, it is recommended to utilise two interconnected nodes one that handles the external communications and one that handles the more trusted internal communication, the nodes could exist on the same hardware. doing so would allow the creation of multiple trust boundaries.
Node External Communication
Although as just discussed it is not impossible to create services that communicate to external interfaces, it is not recommended to use these on the same node as it compromises the integrity of the node. It is preferable to utilise a known route into and out from the node, it is recommended that this route is a mobius router.
Routers are split into two parts, one side of the router communicates internally with its associated hub and all of the services within a node, while the other side of the router communicates externally through a ‘no-mans’ broker to other routers on other nodes. All external communication is done using MQTT over the WebSocket protocol. This could be done over a secure or non-secure connection (ws:// or ws s://).
The internal side of the router acts in exactly the same way as a service, but will automatically subscribe to all messages from every other service within that node.
The external side of the router will have the ability to sign its messages in the same fashion as the services do for internal communication, it will have two pre shared keys and internal or service psk and an external psk.
Node Peering
To allow router to validate the authenticity and integrity of messages form other routers, the external psks will be required to be manually shared between all the routers that want to take part in this communication. the result is that the external psk file will contain the keys of all authorised routers and therefore nodes.
This communication is done over the WebSocket protocol as it reduces the need to configure firewalls to allow MQTT communication. node peering is best used in an enclosed environment where there is a high degree of confidence in the integrity of the network with which the communication is taking place. This is like to require the input of network and cyber security professionals.
Node Peering will require the provision of a MQTT broker capable of using MQTT over WebSockets. this will be a function that will be optionally provided by the mobius router.
Larger Node Deployments
In larger deployments of nodes, peering may not be viable because of the administrative overhead, or there may be low confidence in the network integrity. There may also be a requirement to not only ensure authenticity and integrity of messages, but also confidentiality.
To achieve this, the nodes should utilise WebSockets over Transport Layer Security (TLS), this is in fact simply a HTTP upgrade in the same way WebSockets are used, on a HTTPS connection
In this case it will almost always be easier to provide the node with access to the public internet where things like server name resolution and certificate control are well practised and understood.
We have a dedicated MobiusFlow website for technical documentation and support.
You can access this via