Alarm, Warning and Monitoring System- Part2: IoT Edge Computing Server

In the first part of this series, we laid the foundation for our monitoring system by deploying an MQTT server and a database to act as central collection points for sensor data. Now, we focus on connecting these components to notification services and implementing edge computing to automate responses and alerts. Additionally, we introduce dashboards for real-time monitoring, though their detailed implementation will be discussed in the next part.

To ensure ease of use while also covering a wide range of industrial communication protocols, we chose Node-Red as our edge computing server, deployed within a Docker container on our infrastructure. One of Node-Red’s biggest advantages is its flexibility—once the base server is installed, additional functionality can be easily integrated through its extensive library of add-ons. For this specific application, we installed modules for serial communication, MQTT, TCP/IP communication, and email notifications. With these in place, we could begin defining operational rules to automate the monitoring and alerting processes.

Some infrastructure tools were older models and only supported serial communication. To modernize their connectivity, we installed serial-to-Ethernet converters, enabling remote access and integration with our system.

To understand how data flows within the edge computing server, we break it down into five key steps:

  1. Data Collection: The system gathers raw data from IoT devices and production tools. At this stage, the data is often unstructured, missing essential metadata like units, timestamps, or proper encoding.
  2. Data Formatting & Enrichment: The collected data is converted into a usable format. Node-Red automatically assigns metadata when data enters the system. Here, we add relevant information, such as units, tool names, and timestamps, ensuring consistency across all inputs.
  3. Rule-Based Processing & Storage: The structured data is passed through predefined rules that determine actions based on client requirements. For example, if the bottle pressure of a gas supply drops to 10 bar, the system triggers an email alert to the technical team, reminding them to order a new bottle. If the pressure further drops to 5 bar, another alert notifies operators to switch to a spare bottle immediately. Simultaneously, the data is sent to the database for long-term storage, ensuring historical tracking and analysis.
  4. Post-Processing & Action Preparation: Based on the triggered rule, the system prepares the necessary response. This could involve sending a command to an actuator (such as activating a warning siren or turning on a red light in a specific production zone). In the case of email notifications, the system generates a predefined email template with relevant details.
  5. Execution & Notifications: Finally, the system carries out the predefined action. For example, it connects to the company’s email server and sends notifications to the appropriate team members, ensuring immediate awareness and response.

While most data flows one way from tools to the server, some devices also support remote control functionality, allowing operators to send commands to them. This enables functions like starting, stopping, and adjusting settings remotely, significantly improving response times.

User inputs can be injected into Node-Red in two primary ways:

  • MQTT messages: A small Python application or a hardware button with MQTT capabilities can send a signal to the system, acting as a trigger.
  • User Dashboard: A web-based control panel created within Node-Red provides an intuitive interface with buttons, selection tabs, and tables, allowing operators to interact with the system without needing specialized technical knowledge.

By implementing this system, we significantly reduced downtime by minimizing the need for operators to physically inspect distant equipment—sometimes a process that could take hours. More importantly, in emergency situations, the ability to remotely stop operations prevented cascading failures that could have disrupted interconnected units and led to costly breakdowns.

The rule-based automation in the edge server also reduces human error by repeatedly warning operators about critical actions, ensuring that essential maintenance and supply replenishment tasks are never overlooked. Additionally, it establishes Statistical Process Control (SPC) standardization, defining clear guidelines on when intervention is required versus when a system can be left alone. This approach eliminates unnecessary manual work, freeing up operators for more important tasks while ensuring efficient resource management.

In the next section, we will explore user input and visualization dashboards, along with the advantages of integrating an interactive monitoring system for enhanced operational control.