Blinky-Lite Architecture

Table of contents

The Blinky-Lite Architecture consists of three major components:

  • Application Box
  • Message Trays
  • Controller Cubes

Fig. 1 Blinky-Lite Architecture

The Application Box

The Application Box is comprised of three services, the MQTT Broker, the Application Server, and the Database Server. Each of these three services can be hosted on the same computer inside a firewall or on the cloud, or each service can be hosted on its own computer inside a firewall or on the cloud. For reliability and ease of installation, the preferred method is to have each service hosted own its own machine in the cloud.

  • The MQTT Broker

    The MQTT broker provides:.

    • Communication exchange
      The communication protocol for Blinky-Lite is MQTT. MQTT uses a publish-subscribe paradigm. The MQTT Broker relays messages between message trays and the Application Server. For prompt communications, the MQTT broker can also relay messages directly between message trays without having to go through the Application Server
    • Data Pooling
      Because of the publish-subscribe paradigm, The MQTT broker effectively protects the message trays from being overloaded from too many communication requests from the Application Server.
    • Security
      The MQTT broker acts an additional layer of security because both the message trays and Application Server must authenticate to the MQTT broker to pass messages. Since the message tray must initiate the connection to the MQTT Broker, this eliminates the need for external SSH tunnels into your private network for remote access. Finally, the MQTT Broker can be easily configured to only accept specific and unique topics to and from each message tray adding another layer of security.

  • The Application Server

    The Application Server tasks are:

    • Alarm Scanning
      The Application Server collects messages from the message trays via the MQTT Broker scans for alarms and routes these alarms to user alarm applications and the SMS messenger
    • Data Archival
      The Application Server routes the messages from the message trays to the database server for status update and archival.
    • User application server
      The Application Server also hosts the user applications. The Application Server checks user requests via role-based access routing and and routes the requests to the appropriate message trays and database server. The application server is written using the Node-RED programming environment.
      Node-RED makes it easy:
      • to read, edit, and document the code
      • for the user to change the code
      • to version control the code
      • to port the code to other machines

      Fig. 2 Node-RED Programming Environment

  • The Database Server

    Instead of using name-value pairs for describing the data as with most other control system platforms, Blinky-Lite uses a class structure to describe systems in the message trays. This structure makes communicating between subsystems and data archival much more streamlined and easy to read and modify. The data in the class structure is stored in JSON objects which is a common lightweight data-interchange format ideal for communicating with mobile browser-based web applications. Most of the data in the control system is time-sequenced so a non-SQL type of database such as MongoDB or RethinkDB is much easier to configure and use. Currently, Blinky-Lite is configured to interface smoothly with a MongoDB database.1

    The database is divided into collections of JSON object documents to not only handle data archiving but other services as well such as access logs and app configurations. The list of collections in a Blinky-Lite project is:

    • trays - tray configuration
    • archiver - tray data archiving
    • users - list of users, their credentials, and their roles
    • appConfig - configurations for the standard applications
    • appStyleSheets - custom CSS sheets for the standard applications
    • accessLog - record of all visits to the project
    • settingsLog - record of all tray settings made in the project
    • restAccessLog - record of all RESTful interface visits to the project

Message Trays

The concept of message trays is what makes Blinky-Lite truly versatile. The message trays communicate to a device using whatever protocol and hardware is supported by the device, such as Modbus, serial (UART, SPI, I2C, etc.), RS232, MQTT, etc. The message tray packages the device information into a Blinky-Lite Tray JSON object in a standard format that is discussed in [Need REF!].

The tray message is then published to the Application Box MQTT broker. Since the Application Server subscribes to all the message tray topics in a Blinky-Lite project, the Application Server will receive this message. In this way, the applications on the Application Server can be standardized and reused from project to project. Also, any other tray that subscribes to the message tray’s unique topic can also receive the tray’s JSON object.

The message tray can also subscribe to other message tray topics or messages sent from the Application Server. These messages can the be used to alter the state of the tray or devices the tray is connected to. As shown in Figure 1, more than one device can be connected to a single tray. Thus, the tray can function as a micro-control system in a truly Edge computing manner.

Each message tray runs as a separate Node-RED flow. Usually, there is only a single tray flow running on a single Node-RED process running on a microcomputer such as a Raspberry Pi. However, it is also possible to run multiple tray flows on a single Node-RED instance running on a computer other than a Raspberry Pi, such as computer in the cloud. Local and cloud trays are discussed in [Need Ref!]

Cube Controllers

Cube controllers are not necessarily required in a Blinky-Lite project. For example, if the device is a Modbus device, then the tray can be directly connected to the device. An example ModBus tray can be found in [Need Ref!]. If the device is, for example, a stepper motor, then some hardware is required to interface the motor to translate tray commands. This is usually done through a micro-controller such as an Arduino, Teensy, or Raspberry Pi Pico. We have developed a number of serial and MQTT interfaces to micro-controllers that can be found at [Needs Ref!].

  1. MongoDB is not open-source software so the user must provide their own instance of a MongoDB database server. ↩