Two years ago, we reported on a field-grade wireless I/O product called Spider67 Mobile, which helps users connect various signals from devices on-site directly to a remote cloud data system via mobile wireless communication networks, enabling various IoT applications. At that time, I speculated that this product could provide a means of IoT technology for information exchange between enterprises and bottom-layer device components, independent of traditional automation control systems and unaffected by the complex component wiring and location distribution on-site.
So, for users, what would the application process be like when using a wireless I/O gateway like Spider67 Mobile to integrate an IoT system? In this issue, we will briefly discuss based on the product information we have at hand.
First, let’s take a look at the architecture and components of the entire Spider67 Mobile system.
From the architecture diagram above, the Spider67 Mobile system consists mainly of I/O components, target data pools, and operational terminals, among other parts. The general workflow of the system is that the I/O components deployed on-site interact with the target data pool via wireless communication, and users can access the data pool through the terminal platform to access and operate the on-site devices.
The I/O components are mainly the Spider series field I/Os, available in mobile wireless and bus communication versions. The former can connect to mobile communication networks via Wi-Fi or 4G, comes standard with 16 DI/DO, and is equipped with a standard field bus port for local I/O expansion; the latter provides users with more I/O options, including digital, voltage, and current-type analog inputs and outputs, but only offers traditional field bus options for communication interfaces. Users can connect multiple field I/Os to a Spider67 Mobile module via the field bus and use it as a gateway to access the communication network.
The role of the target data pool is to interact with the on-site I/O in real-time and store data, providing a buffered data interface for terminal application systems to access on-site devices. The default data pool for Spider67 Mobile is ELCO’s IoT Hub™, in which case users generally do not feel the existence of this data pool, as the communication between the Spider67 Mobile gateway and the IoT Hub™ is completed automatically without configuration.
Regarding operational terminals, Spider67 Mobile provides users with an application configuration management platform based on IoT Hub™. Users only need to log in with the corresponding account to perform various access operations on the deployed on-site I/O system, such as adding device components, parameter configuration, data display, threshold settings, and so on.
In my understanding, the application process of the Spider67 Mobile system would roughly be as follows:
First, there is the hardware layout. Users need to arrange the appropriate number of Spider67 Mobile and bus expansion modules on-site based on the system’s I/O point count, type, and geographical distribution, and connect the device components that need to be integrated into the system to these I/O modules. This is similar to the use of I/Os in general automation systems.
Next, if users choose to use the standard service of Spider67 Mobile, the official will provide them with a (set of) application account that matches the gateway ID, including administrator and user accounts, to access the application configuration management platform of Spider67 Mobile.
It is understood that when using the standard service, the application configuration management platform can automatically recognize and detect the powered-on Spider67 Mobile gateways on-site via IoT Hub™, so users do not need to set up communication protocols for the on-site I/Os. Therefore, after logging into the application configuration management platform, the first thing users need to do is to configure and set the on-site I/O modules according to application needs.
The configuration mentioned here likely includes several aspects:
-
Expanding bus-type Spider67 I/O modules for each Mobile gateway;
-
Calibrating the physical meaning and engineering units of the I/O port data;
-
Setting the conversion relationship between analog signal and actual physical values;
-
Setting the display methods for input data, such as: graphics, tables, curves, etc.;
-
Defining the logical relationships of output data, such as: alarm signals based on thresholds…
After completing the configuration of the above I/O modules, users can log into the application terminal platform to use functions such as data trend charts and threshold alarms for remote monitoring and management of on-site devices.
It can be seen that when users use the Spider67 Mobile system service to build an IoT system, they basically do not need to make any adjustments to existing devices and do not require highly specialized IT technical skills. Coupled with the aforementioned independence from traditional automation control systems and the characteristic of being unaffected by complex component wiring and location distribution on-site, it actually provides a relatively realistic and effective method for the information transformation and upgrading of many traditional application fields.
If users have certain IT system integration capabilities, they can also develop a customized application operation platform based on their own customization needs and integrate Spider67 Mobile field-grade I/Os into it. It is understood that in this case, the official will provide users with corresponding I/O module configuration tools to help achieve protocol docking between the Spider67 Mobile gateway and the user’s custom platform. Clearly, this is another non-standard service model.
From the current publicly available information, the functions demonstrated by the Spider67 Mobile system mainly focus on various detection and monitoring applications, such as:
-
Monitoring the working current, voltage, working temperature, vibration, liquid level, and pressure of devices;
-
Collecting temperature and humidity in workshops, warehouses, underground garages, urban utility tunnels, and other areas;
-
Monitoring the heat and flow in centralized pipeline areas such as industrial and civil heating pipe networks and steam pipe networks;
-
Monitoring toxic and harmful gases, airborne particulate matter, and water pollution sources in factories, outdoors, and public areas;
-
Collecting meteorological data such as light, rainfall, wind direction, wind speed, PM values, etc., from outdoor weather stations;
-
…
It is expected that the official will continue to upgrade various application functions based on user needs within the existing system framework, such as: data evaluation and analysis, predictive maintenance, expansion of 5G communication capabilities, etc.
Of course, that is a topic for another time…
Information reference from: elco | 宜科
For any questions, feel free to contact us through this public account at any time.
Click to read the original article to learn more about “Smart Manufacturing Discussions”.
