Click to download this document.

Software Version: V2.1.5.0

Document Version: V1.0

About This Document

This guide is intended for engineers, system integrators, and commissioning personnel using E2C Factory for the first time. It provides repeatable examples for common tasks including software installation, Data Collection, MQTT Data to Cloud, Modbus TCP Data Forwarding, and local alarms.

This guide describes only the key settings required for initial validation. For all supported protocols, fields, function rules, and advanced settings, see the E2C Factory Software Product User Manual.

www.robustel.com

Copyright © 2021 Guangzhou Robustel Co., Ltd. All rights reserved.

Trademark Notice: Robustel is a trademark of Guangzhou Robustel Co., Ltd. Other trademarks and trade names mentioned in this guide belong to their respective owners.

Disclaimer: No part of this document may be reproduced in any form without permission from the copyright owner. Because products, designs, and manufacturing processes are continuously improved, the contents of this document may be updated or revised without notice.

Revision History

Terms and Abbreviations

Software Terms

Industry Terms and Abbreviations

1. Quick Start Overview

1.1 Common Scenarios and Reading Guide

This guide uses one Inlet_Pressure Tag to introduce common tasks for software installation, Data Collection, MQTT Data to Cloud, Modbus TCP Data Forwarding, and local alarms. When using this system for the first time, complete Chapter 2, and then read the chapters applicable to the project scenario.

Use the project-specific parameters for real Devices and target systems. When a real environment is not available, the applicable task introduces an optional simulation or validation tool.

1.2 Third-Party Tools

When no real Device or target system is available, this guide uses the following third-party tools for simulation or auxiliary validation. If a real Device, MQTT service, or actual target system is available, use the actual environment instead. The corresponding simulation or validation tools are not required.

2. Before You Begin

This chapter checks the gateway, installs E2C Factory, and sets the correct time in RobustOS Pro before opening E2C Factory.

2.1 Workflow

Complete the following four tasks:

1. Check the gateway model, RobustOS Pro firmware version, and RAM.
2. Sign in to the gateway web interface and install E2C Factory.
3. Confirm that the gateway Time Zone and System Time are correct.
4. Open E2C Factory and select the License Region on first access.

2.2 Check the Gateway and RobustOS Pro

The supported gateways and minimum RobustOS Pro firmware versions for this guide are listed below.

The gateway must have at least 2 GB of RAM.

Connect the management computer to the network of the gateway LAN interface. Make sure that the computer and gateway are on the same subnet and can communicate. This guide uses the following example addresses:

Replace these addresses with those planned for the actual site.

1. Open a browser, go to the default gateway management address http://192.168.0.1, and log in to the gateway web interface. Google Chrome is recommended.
2. Check the gateway model, RobustOS Pro firmware version, and RAM on the home page and compare them with the requirements in this section.
3. If the firmware version is earlier than the minimum version required for the gateway model, obtain the applicable RobustOS Pro firmware from the software provider. Before upgrading the firmware, read the RobustOS Pro upgrade guide applicable to the gateway model and current version.

2.3 Install E2C Factory

Skip this section if the required version of E2C Factory is already installed. Otherwise, download the applicable E2C Factory package from the E2C Factory APP Download page, and then complete the following steps.

Figure 2-1 Install E2C Factory in App Center

1. In the gateway web interface, go to [System] > [App Center].
2. Select the E2C Factory package and click [Install].
3. Follow the on-screen prompt to confirm the installation.
4. When the restart prompt appears, click [OK] to restart the gateway immediately.
5. After the gateway restarts, sign in again and confirm that e2c-factory appears in the installed application list.

Warning: Do not power off the gateway, close the current page, or submit the installation operation again during installation or restart.

2.4 Confirm the Gateway Time

E2C Factory uses the RobustOS Pro system time and does not maintain a separate clock. Before using this system for the first time, confirm that the gateway time zone and system time are correct.

An incorrect gateway time can cause incorrect timestamps or time displays in Data Collection, Data to Cloud, Data Forwarding, and Alarm Management. Set the correct time before collecting, reporting, or forwarding production data.

Log in to the RobustOS Pro web interface, go to Services > NTP, and configure the time according to the gateway's network environment:

• The gateway can access an NTP server: Select the Time Zone for the project location, enable the NTP client, and configure an NTP server accessible to the gateway. The default NTP Update Interval value of 0 synchronizes the time only once. An interval of 30 min is recommended for periodic synchronization. After submitting the configuration, open the Status tab and confirm that System Time and Last Update Time are correct.

Figure 2-2 NTP client configuration for an online gateway

• The gateway cannot access an NTP server: First confirm that the date, time, and time zone of the management computer are correct. Open the Status tab and click Sync to synchronize the gateway with the computer time. For a gateway operating offline for an extended period, check the system time regularly and synchronize it manually if a time difference is found.

Figure 2-3 Manual time synchronization for an offline gateway

Notice: Set the correct time before production data is generated whenever possible. If the gateway time is changed during operation, check the latest data.

2.5 Open E2C Factory

Figure 2-4 Open E2C Factory from the gateway management interface

Before you begin, make sure that E2C Factory is installed and enabled.

1. Log in to the gateway management interface.
2. Locate [Edge Computing] in the left or top navigation area.
3. Open E2C Factory.

The E2C Factory operation page opens in a new browser tab. On first access, select the License Region for the market where the project is located and follow the on-screen prompt to confirm the selection. The License Region cannot be changed directly in the system after confirmation.

3. Collect One Modbus TCP Tag

This chapter uses inlet Inlet_Pressure as the example Tag. If a real Modbus TCP Device is available for testing, use the actual Device connection parameters and Tag address in the following configuration. To avoid affecting production equipment, select a Tag that can be read safely and whose value can be checked easily.

If no real Device is available, prepare simulated data as described in Section 3.2 before configuring this system.

3.1 Workflow

Complete the following four tasks:

1. If no real Device is available, prepare simulated Modbus TCP data. (Optional)
2. Add one Modbus TCP Device under [Data Collection].
3. Add the Inlet_Pressure Tag.
4. Publish the configuration and validate the collected data.

3.2 Prepare Simulated Modbus TCP Data (Optional)

1. Obtain PeakHMI MB TCP Slave from the PeakHMI website, and install and start it on the computer at 192.168.0.89.
2. Click [Windows] in the top menu bar, and then select [Register Data] to open the data list.
3. Locate 400001 on the left side of the list and enter an easily recognizable test value, such as 20, in the corresponding value cell.
4. Keep PeakHMI MB TCP Slave running. This system will read the value through Port 502 and Slave Address 1 in the following steps.

Figure 3-1 Modbus TCP Simulator configuration in Quick Start

These parameters are used only in this example. In the following configuration, enter the corresponding values directly as shown in the tables. You do not need to understand the internal data structure of the simulator first.

3.3 Add a Modbus TCP Device

Figure 3-2 Modbus TCP Device configuration in Quick Start

Go to [Data Collection] > [Device], click [Add], select Modbus TCP, complete the form as follows, and then click [Save and Configure Tag].

3.4 Add the Inlet Inlet_Pressure Tag

In the Tag list of Modbus_Simulator, click [Add], complete the form as follows, and then click [Save].

If the real Device does not have inlet Inlet_Pressure data, select another read-only Tag whose value can be checked easily, and replace the example Name, Function Code, Address, and Data Type with the actual parameters.

3.5 Publish and Validate Collected Data

Click [Publish] in the upper-right corner of the page to apply the new Device and Tag configuration. After a Device or Tag configuration is changed, publish it again for the new Data Collection configuration to take effect in the runtime environment.

Figure 3-3 Tag status, latest value, and update time

1. In the Device list, confirm that the collection status of Modbus_Simulator is normal.
2. Open its Tag list, confirm that Inlet_Pressure has a [Latest Value], and check that the update time continues to refresh.
3. When using the simulator, change the value corresponding to 400001 in PeakHMI from 20 to another value. When using a real Device, change or observe the corresponding Tag only when it is safe to do so.
4. Wait for one or more polling cycles and confirm that the [Latest Value] of Inlet_Pressure follows the data source.

When the validation succeeds, Data Collection is operating correctly and you can continue with Data to Cloud, Data Forwarding, or Alarm Management. Do not continue while the collected data is invalid. Otherwise, a connection may be normal while no valid data is available.

If no data is displayed or the value is incorrect, check whether the data source is running, whether the network between the gateway and Device is reachable, and whether the IP Address, Port, Slave Address, Function Code, Address, and Data Type are correct. If the cause remains unclear, go to [Debug Log] and review the collection information.

4. Configure MQTT Reporting and Validate Data

This chapter adds the collected Inlet_Pressure Tag to a Tag Group and reports it to an MQTT Broker through Standard MQTT. If a real MQTT Broker or target platform supporting Standard MQTT is available, skip Section 4.2 and enter the actual connection and security parameters provided by the target service when creating the Cloud Service.

If no real MQTT service is available, use Mosquitto and MQTTX to prepare a test environment as described in Section 4.2. This environment is used only to validate the data path and does not represent a production cloud platform or deployment.

4.1 Workflow

Complete the following four tasks:

1. If no real MQTT service is available, prepare an MQTT test environment. (Optional)
2. Create a Tag Group and add Inlet_Pressure.
3. Create a Standard MQTT Cloud Service.
4. Configure a Publish message and validate the data at the receiver.

4.2 Prepare an MQTT Test Environment (Optional)

This guide uses Mosquitto 2.0.20 on a Windows x64 computer as the example. Download and install mosquitto-2.0.20-install-windows-x64.exe. This installation package includes the test configuration required for this example.

After installation, open the Mosquitto installation directory, hold down Shift, right-click an empty area, and select [Open PowerShell window here]. Paste the following command into PowerShell and press Enter:

1 .\mosquitto.exe -c .\mosquitto.conf -v

Figure 4-1 Prepare an MQTT Test Environment

Keep the PowerShell window open. If Port 1883 is already in use, a Mosquitto service or another application may already be using the Port. Stop the duplicate Mosquitto service or process and try again.

Start MQTTX, create a connection, and enter the following information:

Click [Connect]. A successful connection indicates that MQTTX has connected to Mosquitto running on the local computer. Keep Mosquitto running. MQTTX can remain connected or reconnect after the Publish message has been configured.

Because MQTTX and Mosquitto run on the same computer, MQTTX can use localhost. This system runs on the gateway, so [Server Address] must be set to the LAN IP address of the computer that is accessible from the gateway. This example uses 192.168.0.89. Do not enter localhost or 127.0.0.1.

For other operating systems or hardware architectures, download the appropriate version from the Mosquitto website and follow its official instructions for installation, startup, and network access. The default configuration of Mosquitto 2.x may accept local connections only. When using a version downloaded from the official website, confirm that its listener and access settings allow the gateway to connect over the LAN. Configuration of other versions is outside the scope of this guide.

The Mosquitto configuration provided for this example is intended only for temporary functional testing on a controlled network. Do not use it directly in a production environment. Stop Mosquitto after testing.

4.3 Create a Tag Group

Go to [Data to Cloud] > [Tag Group], click [Create Group], complete the form as follows, and then click [Save].

After the first save, locate Modbus_Simulator in the Tag selection window, add the published Inlet_Pressure to Group_01, and then click [Save] again. The Tag Group takes effect when saved and does not need to be published separately.

When using a real Device, select the actual Tag that passed the Data Collection validation in Chapter 3. Duplicate Tag names are not allowed within the same Tag Group because the receiver would not be able to identify the data accurately by name.

4.4 Create a Standard MQTT Cloud Service

Figure 4-2 Create a Standard MQTT Cloud Service

Go to [Data to Cloud], click [Create Cloud Service], set [Cloud Service Type] to MQTT, enter MQTT_Service_01 as the Name, and click [Save]. Select the new Cloud Service, complete [Connection Configuration] as follows, and save the configuration.

The [User Authentication] and [SSL/TLS] values above apply only to the local simulation environment. They are not default recommendations for production deployment. When connecting to a real MQTT Broker or cloud platform, follow the connection parameters and security requirements provided by the target service instead of copying the Off settings from this example.

After saving, confirm that the Cloud Service is enabled and check its connection status. A [Connected] status confirms only that this system is connected to the MQTT Broker. It does not confirm that Inlet_Pressure is being reported. Complete the Publish message configuration in the next section.

If the connection fails, check the Server Address and Port, confirm that the gateway can access the target address and that the target Port is open, and verify that User Authentication, SSL/TLS, and the MQTT Version meet the Broker requirements.

4.5 Configure a Publish Message and Validate Data

Figure 4-3 Standard MQTT Publish message configuration

In [Message Management] for MQTT_Service_01, select [Publish], click [Add], complete the form as follows, and then click [Save].

Do not configure a Subtopic in this example. Keep the default values for the other fields. After saving, confirm that the Publish message is enabled.

Validate Reported Data

1. When using the Mosquitto test environment, connect MQTTX to the corresponding Broker and subscribe to /factory/line1/Inlet_Pressure. Keep the Client ID automatically generated by MQTTX and confirm that it is different from E2C_Gateway_01 used by this system.
2. When using a real MQTT service, subscribe to or view the same Topic in the target platform, actual MQTT client, or data-viewing page provided by the platform.
3. Wait for at least one complete reporting interval and confirm that the received message contains Inlet_Pressure and its value.
4. When using the simulator, change the value corresponding to 400001 in PeakHMI. When using a real Device, change or observe the corresponding Tag only when it is safe to do so.
5. Confirm again that the Inlet_Pressure value received by the receiver follows the data source.

If the Cloud Service is connected but no data is received, return to [Data Collection] and confirm that the Inlet_Pressure data is normal. Then check the Tag Group, Publish message status, Publish Topic, subscribed Topic, and confirm that the receiver is connected to the same Broker.

5. Forward Data Through Modbus TCP

Modbus TCP Slave maps Tags to Modbus Coils, Discrete Inputs, Input Registers, or Holding Registers. A third-party Modbus TCP client reads data by using the gateway IP Address, service Port, Slave Address, Function Code, and Mapped Address.

This chapter maps Inlet_Pressure to an Input Register for a SCADA system, HMI, host application, or other Modbus TCP client to read. This example validates reading only and does not configure writeback. After configuration, use the actual target system for validation where possible. Use Modbus Poll only when the actual target system is temporarily unavailable or additional troubleshooting is required.

5.1 Workflow

Complete the following four tasks:

1. Create and configure a Modbus TCP Slave service.
2. Add one slave.
3. Map Inlet_Pressure to a Modbus Input Register.
4. Validate the data in the actual target system or Modbus Poll.

5.2 Create and Configure a Modbus TCP Slave Service

1. Go to [Data Forwarding] and click [Create].
2. Select Modbus TCP Slave for [Driver], and then click [Save].
3. Open the [Configuration] tab for Modbus TCP Slave and enable the service.
4. Set [Port Number] to 502, keep the defaults for the other Basic Settings, and click [Submit].

If Port 502 is already used by another service on the gateway, select an unused Port and configure the client to use the same value.

5.3 Add a Slave

Figure 5-1 Add a Modbus TCP Slave

Modbus TCP mappings are organized by slave. Each slave contains an independent Tag mapping table.

Click [Add] in the slave list, enter the following values, and then click [Save].

[Mapping Table Name] cannot be changed after saving. Slave Addresses within the same Modbus TCP Slave service must be unique.

5.4 Add One Modbus Mapping

Open the Modbus Mapping Table for Line1_SCADA and click [Add]. Select [Device] and [Tag], configure the mapped value, mapped data type, function code, and initial address, and then click [Save].

Different Modbus clients may use offsets starting at 0 or reference addresses such as 30001. Configure the client according to the Function Code and Mapped Address shown in the mapping table, and confirm the address base used by the client. If the client uses a protocol offset starting at 0, Mapped Address 1 may need to be entered as 0.

5.5 Validate Forwarded Data

5.5.1 Use the Actual Target System

1. Open the [Status] tab for Modbus TCP Slave and confirm that the service is started.
2. In the target system, enter gateway address 192.168.0.1 and service Port 502.
3. Set Slave ID to 1 and use Function Code 04 to read Mapped Address 1 as short.
4. Compare the result with Inlet_Pressure under [Data Collection].
5. Change safe test data and confirm that the client value updates accordingly.

5.5.2 Use Modbus Poll (Optional)

Suggested download: Modbus Poll official download page

1. Start Modbus Poll and go to [Connection] > [Connect].
2. Select Modbus TCP/IP, enter the gateway IP Address and service Port, and connect.
3. Go to [Setup] > [Read/Write Definition] and configure Slave ID 1, Function Code 04, the initial address, and the quantity to read.
4. Read Inlet_Pressure according to the mapped address and the address base used by Modbus Poll, and compare it with the value under [Data Collection].
5. Change the test value in PeakHMI and confirm that the Modbus Poll value updates accordingly.

Figure 5-2 Use Modbus Poll

If the client cannot connect, check that the service is enabled and started, that the gateway address and Port are correct, and that the network and firewall permit the connection. If the client connects but the value is incorrect or does not update, check the Slave ID, Function Code, address base, quantity, Mapped Data Type, and byte order, and confirm that the source Tag is still being collected.

6. Create and Validate an Alarm

This chapter creates a high-Inlet_Pressure Alarm Rule based on Inlet_Pressure and validates alarm activation, automatic clearing, and history. The example validates alarms within E2C Factory and does not configure SMS, Email, WeCom, WhatsApp, or Telegram notifications.

6.1 Workflow

Complete the following three tasks:

1. Create an Alarm Rule that monitors Inlet_Pressure.
2. Make Inlet_Pressure meet the condition and check Real-time Alarms.
3. Restore the test value and confirm that the alarm clears and appears in Alarm History.

6.2 Create an Alarm Rule

Figure 6-1 Alarm Rule configuration

Go to [Alarm Management] > [Alarm Rules], click [Add], configure the rule as follows, and then click [Save].

This example sets [Trigger Interval] to 1 sec and [Trigger Count] to 1 so that an alarm is generated promptly after the test condition is met. Keep the default values for the other fields.

When using a real Device, replace the Comparison Value with a condition that can be triggered and restored safely without affecting production. Do not create an alarm by changing a critical production parameter.

6.3 Trigger and Validate the Alarm

1. When using PeakHMI, set the value of 400001 to 30. When using a real Device, make the target Tag satisfy the rule only under safe conditions.
2. Wait for the Alarm Rule evaluation.
3. Go to [Alarm Management] > [Real-time Alarms], confirm that Inlet_Pressure_High appears, and check its level, content, Device, Tag, and time.
4. Go to [Data Collection] and confirm that the alarm count for the applicable level has increased on the Device card.

Figure 6-2 Real-time Alarms and alarm handling

If no alarm is generated, confirm that the real-time Tag value meets the condition, that the correct Device and Tag are selected, and that Condition, Comparison Value, Trigger Interval, and Trigger Count are correct.

6.4 Restore the Test Condition and View Alarm History

1. Restore the PeakHMI value to 20, or return the real Tag to a safe state that does not meet the alarm condition.
2. Return to [Real-time Alarms] and confirm that the alarm clears automatically.
3. Go to [Data Collection] and confirm that the applicable alarm count on the Device card has decreased.
4. Go to [Alarm Management] > [Alarm History] and confirm that the record can be found.

Figure 6-3 Alarm History

If the alarm condition is still present, do not use Manual Clear as a substitute for resolving the actual abnormal condition. Correct the condition or restore the test value before handling the alarm record.

7. Troubleshooting

This chapter helps locate faults by symptom and groups the checks under general system operation, Data Collection, MQTT Data to Cloud, Modbus TCP Data Forwarding, and Alarm Management. First confirm that the gateway network and system time are correct. For Data to Cloud, Data Forwarding, or Alarm Management issues, confirm that upstream Data Collection is operating normally before checking the applicable function. If the cause remains unclear, review [Debug Log] and the complete user manual.

7.1 General System Issues

7.2 Data Collection Issues

7.3 MQTT Data to Cloud Issues

7.4 Modbus TCP Data Forwarding Issues

7.5 Alarm Management Issues