이정훈
(Jung-Hoon Lee)
†iD
Copyright © The Korea Institute for Structural Maintenance and Inspection
Key words
Smart Factory, HW, SW, Sensor Data, Communication, REST API, AT Command, IoT
1. Introduction
As the Fourth Industrial Revolution progresses, significant changes are occurring
in the field of factory automation. Smart factories are advancing according to the
government's R&D mid- to long-term roadmap, and research and development are underway
in alignment with South Korea's eight key manufacturing innovation technologies. These
technologies include the Internet of Things(IoT), Cloud computing, Cyber-Physical
Systems(CPS), Big Data analytics, Smart Sensors, 3D Printing, energy conservation,
and holography[1]. Countries such as Germany, the United States, and Japan have introduced smart factories
in large-scale manufacturing facilities such as automobile and machinery plants, with
a focus on product production factories. They are striving to increase production
efficiency by adopting intelligent systems. Germany, for instance, is actively engaged
in standardizing smart manufacturing through activities centered around ISO/184 and
TC65. Additionally, in areas related to the Internet of Things and intelligence, standard
development is being pursued in various aspects by organizations such as ISO/IEC JTC1,
IEEE OMG, and IIC[2]. In recent times, there is a trend towards implementing control systems based on
the OPC UA(Open Platform Communications Unified Architecture) and Modbus standard
for transmitting data between heterogeneous systems[3-5]. This trend extends to integrating sensor data with Digital Twins, enabling the monitoring
and control of the physical world through twin systems[6-8].
In larger companies, it is relatively easy to implement solutions such as using proprietary
solutions or utilizing OPCUA to define sensor data and employing SW stack for data
transmission and AI for control. However, in smaller companies, utilizing such platforms
is not easy, especially considering the limited amount of data to be sensed and the
need for intuitive control without highly processing sensor data. Here are the usage
scenarios for corresponding sensor data:
- To remotely manage coffee roasting equipment, measure the temperature of the device,
control valve opening and closing at the appropriate time, synchronize with the server,
and record the actions.
- In cases where preheating of equipment is required in a factory, remote power
on/off is necessary, along with monitoring and modifying the device's temperature,
synchronized with the server, and recording the actions.
- Sensing dust generation at a construction site, monitoring the situation remotely,
and controlling a fine mist spray system as needed.
To perform the tasks mentioned above, it is necessary to implement functionalities
such as interfacing specific sensors with microprocessors, transmitting data to the
server using communication protocols, defining data types between the server and clients(microprocessor
boards), and monitoring and controlling situations from smart devices. Small-scale
companies often aim to implement only essential features without utilizing complex
platforms. To this end, this study presents data sensing and communication methods
using embedded systems in Chapter 2, server and client communication methods in Chapter
3, design, implementation, and functional verification for each element function in
Chapter 4, and concludes with a conclusion in Chapter 5.
2. Selection of controller and communication method
2.1 Selection of controller and sensor
To implement the functionality of receiving data such as temperature, humidity, and
light intensity, a microcontroller with the performance level of Atmel's AVR series,
particularly utilizing the Atmega chipset, is suitable. In this paper, the Atmega328P
chip is selected, and the readily available Arduino Uno board, which integrates this
chip, is chosen. The Arduino Uno board provides the specifications as shown in Table 1 and offers an integrated development environment(IDE), making it convenient for implementation
and validation.
Table 1 Technical specification of Arduino
Items
|
Value
|
Microcontroller
|
ATmega328P
|
Operating Voltage
|
5V
|
Digital I/O Pins
|
14
|
PWM Digital I/O Pins
|
6
|
Analog Input Pins
|
6
|
Flash/SRAM/EEPROM
|
32KB/2KB/1KB
|
Clock Speed
|
16 MHz
|
The pinout of the Arduino Uno is as shown in fig 1, providing external interfaces including six analog pins(A0~A5) with 10-bit resolution,
and 14 digital I/O pins. It also offers support for I2C, SPI, PWM, and UART, allowing
interface implementation according to sensor specifications.
The MVH3200D chipset, selected for the temperature and humidity sensor, utilizes
I2C communication for data transmission. Two lines, SDA(Serial Data) and SCL(Serial
Clock), are connected to the D18 and D19 ports of the Arduino, respectively. The data
frame of I2C(SDA) is depicted in fig 2, and when the Arduino sends the sensor's address and a read bit, the sensor responds
with temperature and humidity data in a 4-byte length value.
2.2 Selection of communication method
Arduino communication can be implemented through Ethernet-based wired communication
or wireless communication based on a WiFi module. However, in this paper, flexible
wireless communication was chosen, and an Arduino-compatible WiFi shield(ESP8266 WiFishield)
was used. The WiFi shield aligns with Arduino's pinout, making it physically compatible
and user-friendly. The ESP8266 chipset used in the WiFi shield supports IEEE802.11
b/g/n specifications and can be used in STA(Stand Alone), AP(Access Point), or STA+AP
modes. It notably includes a TCP/IP stack, allowing for the application of necessary
OSI layer functionalities in Arduino without the need for the protocol stack, and
enables multiple client connections. The connection between Arduino and the WiFi shield
is illustrated in fig 3, requiring a total of four pin connections: 3.3V power, ground, and UART(Universal
asynchronous receiver/transmitter) TX/RX.
Fig. 1. Pin Map of Arduino
Wi-Fi Shield connection with Arduino is as shown in fig 3, and requires a total of 4 pin connections: 3.3V power, ground, and UART (Universal
asynchronous receiver/transmitter) TX/RX.
Fig. 2. I2C frame structure
In the UART physical layer, information is transmitted using a frame format similar
to fig 4. The voltage level remains high (logic 1) until the start bit transitions to low
(logic 0), indicating the start of communication. After transmitting data, parity
bits are used to verify the integrity of the transmitted data, and a stop bit is appended
to conclude data transmission.
Fig. 3. Connecting Arduino and Wi-Fi Shield
To control the WiFi module in Arduino, data in AT Command format is transmitted through
the UART physical layer. AT Commands can be categorized into basic commands, WiFi
commands, and TCP/IP commands. The AT Commands included in the WiFi shield are embedded
in the manufacturer's firmware, which may lead to variations in functionality depending
on the version, necessitating version control. AT Commands are further classified
into solicited commands and unsolicited commands. Solicited commands involve Arduino
sending commands in the format of 'AT+XXX'(e.g., AT+CIPAPMAC), to which the WiFi shield
responds with 'OK' string. Querying is done in a similar format like 'AT+XXX?'(e.g.,
AT+CIPAPMAC?), and the WiFi shield responds with '+XXX'(e.g., +CIPAPMAC:<mac>) followed
by 'OK' string to complete the command cycle. Unsolicited commands involve the WiFi
shield transmitting data to Arduino without the 'AT' string, typically for forwarding
network data to the main processor on Arduino. This communication is done in the format
such as '+XXX'(e.g., +IPD=...) as depicted in fig 5.
Fig. 5. ATcommand transmission format
3. Communication method between server and client
3.1 Communication between server and client
Above, the physical layer interface between Arduino and Wi-Fi Shield, as well as the
upper data transmission standard, were determined. However, for transmitting data
between the client and the server, a higher-level data transmission protocol beyond
this is needed. Typically, between clients and servers, socket communication or HTTP-based
REST API is used. Socket communication operates above the OSI 7-layer model, encapsulating
data into packets for transmission and appending TCP/IP headers to pass down to lower
layers. It's characterized by establishing connections between the server and client
even when no data is being transmitted, and both sides can initiate data transmission.
On the other hand, REST API, as part of the HTTP protocol, is a communication method
where servers and clients don't maintain connections after data transmission. Hence,
clients need to periodically check for values using polling, which can be less convenient
compared to socket communication. However, REST API is easier to implement. In this
paper, considering the modest performance of Arduino, you intend to use REST API for
data transmission.
REST API methods include POST, GET, PUT, and DELETE, as illustrated in fig 6. The POST method requests a URI(Uniform Resource Identifier) to create resources
on the server, the GET method reads information about resources, the PUT method modifies
the content of resources, and the DELETE method removes the specified resource. The
format of the REST API is often based on JSON type, but it's designed to be flexible
and not limited to any specific format.
Fig. 6. API transmission scheme between server and client
4. Design, implementation and functional verification
We have implemented a system to check the operational status of factory equipment,
measure temperature, and transmit the data to the server. Users can connect to the
server from their smart devices to monitor the status and control temperature and
power on/off. fig 7 illustrates an implementation example of transmitting data using REST API.
Fig. 7. Example of information transmission based on REST API
4.1 Design
The interface between the client (Arduino, Micom) and the server utilizes REST API,
primarily designed using POST/GET methods as shown in Table 2.
The REST API used for device-to-server communication employs both GET and POST methods.
When using GET, the endpoint 'http://192.168.0.7:3000/device' is utilized to retrieve
temperature settings and power on/off commands stored on the server. When using POST,
data is sent to the server using the endpoint 'http://192.168.0.7:3000/device?Temperature=30&PwrOn
-Off Status=1', containing temperature measurement values (Temperature=30) and power
on/off status (PwrOnOffStatus=1) of the equipment. The server stores these values
and transmits them when accessed by a smart device. In this case, GET method is used
with the format 'http://192.168.0.7:3000/mobile'. To control the temperature (SetTemperature=70)
and power on/off (PwrOnOffCommand=1) of factory equipment connected to Arduino from
a smart device, the POST method is employed with the format 'http://192.168.0.7:3000/mobile?PwrOnOffCom
-mand=1& SetTemperature=70'.
Table 2 URI format
direction
|
host(:port)
|
path
|
query
|
device to
server
|
ip and port
|
device
|
Temperature, PwrOnOffStatus
|
mobile to
server
|
ip and port
|
mobile
|
PwrOnOffCommand, SetTemperature
|
To transmit data from Arduino to the server, the WiFi shield must be interfaced using
AT commands, as outlined in Table 3.
Table 3 ATCommand for WIFI Shileld
ATCommand
|
description
|
CWMODE
|
Wi-Fi mode(sta/AP/sta+AP)
|
CWLAP
|
Lists available APs
|
CWJAP
|
Connect to AP
|
CIPSTART
|
Establish TCP connection, UDP transmission or SSL connection
|
CIPSEND
|
Send data(REST API)
|
4.2 Implementation and Verification
The integration of the WiFi shield with Arduino enables the transmission and reception
of REST API data to and from the server.
This connectivity was confirmed through Arduino logs, which show that data is sent
according to the AT command specifications, and the cycle is completed upon receiving
the OK string after transmitting the command. To send data to the server, the Arduino
initiates a TCP connection using CIPSTART and then uses CIPSEND to transmit the REST
API. The process of sending the REST API and receiving responses is depicted in fig 8.
The Node.js server is implemented with the functionality to listen on a port in the
server.js file, as shown in fig 9. The router.js file distinguishes paths (device, mobile) to branch the operation
of the REST API, and the data.js file implements POST/GET methods for device/mobile.
During development, server-side verification was performed using POSTMAN. The logs
from the integration with Arduino are depicted in fig 10.
The implementation on the smart device utilizes a LinearLayout to organize the screen
layout. It is vertically divided into three areas: at the top is a still image representing
the smart factory, followed by a textView displaying factory conditions, and at the
bottom, there are EditText, Switch, and Button components for sending commands to
the heater in the Factory setting section.
Fig. 8. REST API transmission and response log on Arduino
Fig. 9. Node.js server implementation
Fig. 10. Operation log on server
To handle network connections, the implementation is separated into a separate thread
from MainActivity due to issues with CPU occupation causing crashes. Communication
between MainActivity and the thread is achieved asynchronously using a messageHandler
to send messages for data processing. The source code for the functionality implementation
and its operation verification is depicted in fig 11.
Fig. 11. Implementation and function confirmation on smart device
5. Conclusion
This paper has designed the selection of a microcontroller capable of information
transmission and device control, sensor interfaces, communication integration using
a WiFi shield, and the data communication format with the server. Furthermore, by
implementing and verifying these aspects, including the integration functionality
between the microcontroller(Arduino), server, and smart device, the proposed interface
approach has been demonstrated to be useful. Existing interface methods such as Modbus
and OPCUA are burdensome for small companies because they are large and heavy to use
by implementing or porting the corresponding software stack. However, the method proposed
in this paper is simple and efficient, so it can be widely used.
Acknowledgements
This work was supported by Research Support Center of Dong Seoul University in 2022
References
Jong-Kyung Park, Tai-Woo Chang, “Review of Domestic Research on Smart Manufacturing
Technologies”, The Journal of Society for e-Business Studies, vol. 23, no. 2, pp.
123-133, 2018
![URL](../../Resources/images/icon_url.png)
Sun-yang Chung, Joong-Yang Jeon, Jeong-Jae Hwang, “Standardization Strategy of Smart
Factory for Improving SME’s Global Competitiveness”, Journal of Korea Technology Innovation
Society, vol. 19, no. 3, pp. 545-571, 2016
![URL](../../Resources/images/icon_url.png)
Jae-Sung Kim, Seok-Chan Jeong, Dong-Woo Seo, Dae-Gi Kim, “Development of OPC UA based
Smart Factory Digital Twin Testbed System”, Journal of Korea Multimedia Society,
vol. 25, no. 8, pp. 1085-1096, 2022.
![URL](../../Resources/images/icon_url.png)
Jeom-Goo Kim, Hyun-Cheol Kim, “Development of Intelligent Sensing Agent for Automatic
Control of IoT based Electro Deposition Coating”, Journal of Korean Institute of Next
Generation Computing, vol. 16, no. 4, pp. 67-77, 2020.
![URL](../../Resources/images/icon_url.png)
Jin-Seok Han, Jae-Soo Yoo, “Design and Implementation of Modbus Communications for
Smart Factory PLC Data Collection”, The Journal of the Korea Contents Association,
vol. 21, no. 4, pp. 77-87, 2021.
![URL](../../Resources/images/icon_url.png)
Tae-Hwan Ko, Seok-Bong Noe, Dong-Hee Noh, Ju-Hwan Choi, Tae-Beom Lim, “Study of Implementation
as Digital Twin Framework for Vertical Smart Farm”, Journal of Broadcast Engineering,
vol. 26, no. 4, 2021.
![DOI](../../Resources/images/icon_crossref.png)
Hyeon-Chan Kim, Yoo-Ho Son, Ji-Hyun Bae, Sang-Do Noh, “A Study on the Digital Twin
Visualization Method for Smart Factory of Dye Processing Industry”, Journal of the
Korean Institute of Industrial Engineers, vol. 47, no. 1, pp. 077-091, 2021.
![URL](../../Resources/images/icon_url.png)
Young-Wook Nam, Sang-Ho Lee, Dong-Gun Lee, Sun-Gju Im, Sang-Do Noh, “Digital Twin-based
Application for Design of Human-Machine Collaborative Assembly Production Lines”,
Journal of the Korean Institute of Industrial Engineers, vol. 46, no. 1, pp. 042-054,
2020.
![URL](../../Resources/images/icon_url.png)
저자소개
He received his B.S, M.S degrees in electrical engineering from Sung Kyun Kwan University,
Suwon, South Korea, in 1999, 2001 and Ph.D degree in IT Policy from Seoul National
University of Science and Technology, Seoul, South Korea, in 2012, respectively. Since
2015, he has been a Professor in the Department of Electrical Engineering, Dong Seoul
University, SeongNam, Korea. His research interests include IoT, Digital Communication,
Embedded System, Distribution facility control.