{'fraction_non_alphanumeric': 0.01649639926310501, 'fraction_numerical': 0.005359236308825992, 'mean_word_length': 4.965534465534465, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Machine to Machine Communication Protocol for SMART Manufacturing Units

This paper explores the need for a true Machine-to-Machine communication protocol without the need of intermediate servers, to allow machines to communicate with one another in a decentralized manner, while offering a lower latency and transmission time than existing protocols. The communication protocol is developed with Siemens Siematic S7-1200 modules that will communicate within different networks and benchmarked against the existing protocols. The results show that a decentralized communication protocol can be implemented with reduced latency and transmission time, while offering critical characteristics needed to realize SMART Manufacturing within real-time for a production line.


Methodology
This paper uses a SMU that has an attached Siemens S7-1200 module that is tasked with the filling of different size water bottles. This SMU will then communicate with a standalone S7-1200 module for testing of the M2M communication protocol.
The first layer of the OSI model is concerned with the physical layer. This layer is responsible for the physical structure of the network (topology) made up of the different hardware devices and link between them. A communication network can be realized with a single connection existing between each machine, but with the redundancy and hardware cost of amount of links existing between each machine becoming expensive, a switch can suffice as a solution to both cost and addressing scheme. This switch is where the M2M communication protocol can share a similar addressing scheme as the standard IPv4 internet protocol.
Although in this case there is a switch linking the two S7 modules, as seen in Fig. 2, this switch serves only as a means to allow multiple access points for future SMU's. This switch does not any anyway act as a server to facilitate, decode or extract the information sent from machine to machine. Alternatives would call for expansion models to be attached to every SMU for multiple Ethernet access.
The switch only acts as a forwarding node of information to facilitate the exchange of information from machine to machine. The S7-1200 modules and communication protocol were programed in Totally Integrated Automation (TIA) portal.

Plant Set-up
Within the water bottling plant production line, two SMU's exists to fill the custom water bottle with either 300 ml or 500 ml of water and to cap each custom water bottle. The first SMU uses image processing to determine the shape and volume of the bottle, and then fill the water bottle with the correct amount of water. The height of the bottle can then be extracted from SMU 1 and communicated to SMU 2 in order to gain the correct height placement for the capping process.

SMART Manufacturing Units
The paper utilizes two SMU stations communicating though a switch. As previously mentioned, the switch only serves as a multi-access port plug in the expansion of the network and plays no point in transporting or encapsulating the communication protocol.
The SMU's used in this study are controlled using Siematic S7-1200 PLC's. This network can be expanded in the future to accommodate larger production lines, however this papers focus is to analysis the effectiveness of the communication protocol as well as measure the latency and transmission time of the communication protocol. These aspects would be the easiest to monitor with a scaled down network.

Communication Method
Within the communication protocol there are two major aspects, the Communication Method and the Communication Information. The communication method is used to decide on how information is sent. The communication information will decide on what information is sent.
The method includes the addressing scheme of the protocol, the structure and version of the protocol and an encapsulation of the message information sent from the communication information. The structure of the communication method can be seen in Table 1.

1) Method
The protocol is designed to use similar methods of the HTTP protocol, namely: GET and PUT. The PUT method is used to assign information from one S7 SMU module to another. The GET method is used to retrieve information from a S7 SMU module. These two methods are then used on trigger basis to receive information about another SMU and bring in-line the contextual awareness characteristic of SMART Manufacturing. As in contrast to other communication protocols, such as HTTP, where a handshake agreement is needed for exchange of information, the GET and PUT methods have reserved memory only accessed by other communicating devices.

2)
Destination The destination field specifies the host device/ server of which the method would transfer the information to. This field only specifies the direct device and not the location of where the information to be stored. The actual location within the device where the information is stored, is handled in the BODY field. The destination field works similar to that in other communication protocols, such as HTTP, where in the 3 rd layer of the OSI Model, namely the Network layer, handles all destination and source information. The addressing scheme for the SMART Manufacturing Protocol (SMP) implemented works similar to that of the IPv4 protocol, where each device is given one of a unique 2 32 possible addresses. These addresses can be divided up for different subnet and different networks of devices.

3)
Body The Communication method is then used to communicate the BODY of the message which contains the Information of the SMU. The BODY contains the Machine Type, Machine Status (Flags) and any data a user wishes to communicate between devices. Each of these fields is accompanied with a unique 8byte address that is stored onto the SMU.
This unique address is used to either update only a certain portion of the communication from the PUT method or retrieve a certain portion of information from the GET method. Therefore, not the entire body of information needs to be retrieved, if not updated, to reduced latency.

Communication Information
The information Communicated is used to communicate the actual information about the machine. This information is used to allow other machines to acquire information about surrounding machines and their environments. This adds to an expanding network where each machine is able to realize every other's machines environment, bringing about a contextual awareness for the machines and the environment.
This contextual awareness through the communication of the protocol will allow the machines create intelligent decisions and become SMU for SMART Manufacturing. The communication information that would be emasculated into the DATA field of the communication method can be seen in Table 2.

1)
Machine Type The MACHINE TYPE field is used to identify the types of machines that exist within the production line. Since there is a finite amount of types of machines that exist, this field could be used in a lookup table to allow machines to reference the type of attached machine next to itself. This will allow machines the ability to decide if a current product on the production line can be manufactured with the types of machines attached on the production line. Similarly, if products would require special manufacturing instructions, then the machine can easily decide what type of machine is the product needed to be directed to with the MACHINE TPE identifier. Since the communication protocol is designed using inspiration of HTTP GET and PUT methods, a machine could gather information about the surrounding machines for if production is able to continue and be completed. This will lead to machines being able to decide whether to continue or halt production or to even work at a reduced/increased production pace.

3)
Data The data field of the communication protocol is left open for user specific information to be sent. With the case of the IPv4 protocol this field would typically contain the information sent to decode a YouTube video, or populate a website that is loading. Therefore, this information would typically contain information about the machines' sensors. This information can then be passed onto machines on a conveyor to trigger events to continue production.

Results
The communication protocol is tested with two parameters but is still discussed in the sense if the protocol is able to be applied to assist in SMART Manufacturing. The two parameters that is tested is the Transit Time and Latency of the communication protocol.

Transit Time
With the transmission time of a protocol being the time taken for a message to be sent and received, the developed SMART Manufacturing protocol (SMP) was tested to have about 15ms transmission time, tested at standard conditions. This transmission time of the SMP is on par with most communication protocols and is less than both OPC and WebSocket, as seen in Fig. 3.

Latency
With the latency of communication being the down time between which two messages can be sent between devices. It is clear to see that the newly developed SMP, on the far right of Fig. 4, has a considerably lower latency compared to OPC and better latency compared to WebSocket.
With OPC and WebSocket being the main two communication protocols in use with M2M communication, it is also worth re-noting that the SMP protocol does not require an intermediate server, unlike its predecessor. The reason for the lower latency in the SMP when compared to WebSocket and OPC, is due to the lack of acknowledgement and checksum fields in the SMP protocol. Since the OPC has redundant acknowledgment fields and waits for returns on the original message, scaling networks with use of OPC usually see increasing latency issues.
However, it is seen as the machines responsibility to ensure the accuracy of information received, whether through multiple GET methods or multi-host comparison. Even with a threefold repeat of the GET method, the latency will still be lower than that of OPC.

Communication
With the communication protocol using similar HTTP GET and PUT methods, communication is seen as a server communication with a device. However, since each device has both methods, each device is seen as server.
Centralized communication exists when multiple host connect to a single server, where the server has PUT method administration rights. Since each device acts as a server however, each device has decentralized operation as the server/machines is able to store as well as sends/transmits data to other hosts.

Conclusion
This paper explores the need for a true Machine-to-Machine communication protocol without the need of intermediate servers, to allow machines to communicate with one another in a decentralized manner, while offering a lower latency and transmission time than existing protocols.
As part of the study, the paper examines communication protocols such as; OPC, WebSocket and MQTT as well as the characteristics making up SM. These characteristics revolved around Decentralization, Networkability, Interoperability, Information Appropriateness and Distributed. These characteristics could be achieved with effective communication, rooting from a well-defined communication protocol. While previous communication protocols proved effective in their own right with either low latency or effective transit time, they lack requirements for SM. These requirements revolved around Big Data, effective transit time and low latency bringing to shape real-time communication.
A communication protocol is then developed between two (however still scalable) Simatic S7 1200 modules, acting as SMU's. The communication protocol formed similar as the HTTP protocol, with major differences coming in the Transport and Network layer of the OSI Model. These changes included the methods for information transmission and information sent. This included the GET and PUT methods.