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.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

Fig. 4. UART data frame

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.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.