From the emergence of the first numerical control system in the 1850s to modern open numerical control systems, there have been many major changes, but these changes have been limited to the innovation and upgrading of single-machine functions and unit technologies. Progress in networking technologies for equipment has been slow.
In recent years, CNC system products with different structural levels have emerged, including complete systems, semi-finished products, and core software, as shown in the table below. For example, the German company ISG only provides the intellectual property rights for the CNC software, allowing users to configure or further develop their own branded CNC products. The US National Institute of Standards and Technology (NIST) and other open-source organizations provide open-source Linux CNC software, whose source code is freely available to users and can be developed under the GNU shared license. German companies PA (PowerAutomation) and Beckhoff provide modular CNC system platforms, allowing users to configure them to create their own branded CNC products. The US company DeltaTau provides PMAC motion control cards and related software, allowing users to develop their own CNC systems, etc.
The table below describes the evolution of CNC system interconnection methods: CNC system interconnection has gradually upgraded from the earliest serial communication to Ethernet communication. The communication ports and protocols of different types (brands) of CNC systems vary significantly. Table 1 also shows that at different times and stages, CNC system manufacturers have designed and provided communication methods and protocols for different application goals. For example, the earliest I/O method was used for handshaking and collaborative work with other devices. In the second stage, during the serial communication era (which is still used by many domestic and international manufacturers), mainly due to the limited memory of CNC systems, online NC file downloads were used when encountering large programs, i.e., the most basic DNC function. This method was widely used by domestic CNC manufacturers due to its low technical threshold, simplicity, ease of implementation, and low cost. However, this also limited the application of network technology in domestic CNC systems, resulting in extremely limited functionality. In the third stage, mid-to-high-end CNC systems such as Fanuc and Siemens were equipped with Ethernet interfaces. For example, Siemens CNC systems provided standardized LAN communication protocols based on OPC, and data acquisition and file transfer moved towards standardization. However, the system design and network protocol design at this stage were still limited to LAN applications and were more based on the traditional DNC design concept. The network transmission functions of CNC systems at this time were mainly aimed at data uploading and downloading (such as backup/restore, NC program download and upload, parameter setting, etc.) to meet the goal of point-to-point or LAN interconnection applications. However, with the advent of the Internet era, the above functions and their protocol forms seemed somewhat inadequate.
Changes in the interconnection methods of CNC systems
Taking the OPC protocol released in 1996 as an example, its original purpose was to abstract PLC-specific protocols (such as Modbus, Profibus, etc.) into standardized interfaces and provide standardized connection and communication support to systems such as HMI/MES via Ethernet. This communication for local area networks has the following disadvantages: platform limitations, difficulty in firewall penetration, OPC cannot support the Internet, weak security functions, and data integrity cannot be guaranteed.
1. Platform limitations: Cross-platform compatibility is virtually impossible. OPC is developed based on Microsoft's COM/DCOM technology and can only run on Windows systems. It is not supported on embedded platforms such as Linux, which are popular in today's industrial control field. Furthermore, in early 2002, Microsoft announced the cessation of COM technology development, and the technological foundation of OPC faced obsolescence.
2. Firewall penetration is difficult. OPC communication is difficult to complete when crossing computer boundaries. Users need to open many ports in the firewall to allow DCOM communication to pass through, which seriously affects the security and reliability of the entire network.
3. Lack of support for Internet applications such as the Web; OPC cannot support the Internet.
4. Weak data structure support: OPC cannot support complex data specifications such as structured data.
5. Weak security features: Security features that are very important in network applications, such as device authentication and data encryption, were not designed in the old OPC protocol.
6. Data integrity cannot be guaranteed. In the event of communication interruption or abnormality, the OPC protocol cannot guarantee the accurate delivery of transmitted data, and data communication is often damaged and cannot be recovered.
To address the aforementioned shortcomings, the fourth stage of communication design saw the emergence of protocols such as OPCUA and MTConnect, designed for Internet applications.
OPCUA is an extension and upgrade of the original OPC protocol by the OPC Foundation. It first addresses the dependency issue on operating system platforms and provides greater support for applications in the internet environment. OPCUA solves network security and firewall penetration problems through tunneling technology and supports emerging communication technologies for internet applications, such as publish/subscribe. Its technical framework is shown in Figure 2.
MTConnect is an open-source, free machine tool communication standard initiated by the American Machine Tool Technician (AMT) and developed in conjunction with world-leading manufacturing companies such as General Electric. It aims to improve interoperability between manufacturing equipment, devices, and software applications from different manufacturers and software vendors. Its technical framework is shown in Figure 3. However, the system architectures of major CNC manufacturers differ, and their parameters, file naming conventions, and even operating systems vary. Standardizing a vast number of CNC devices and enabling a large number of client-side applications such as ERP and MES to work collaboratively remains a long and arduous journey.
The MTConnect protocol only specifies communication between the client and the device, but it does not address internet applications and their interoperability interfaces. Like OPCUA, its fundamental problem is that it still relies on point-to-point communication, but internet applications require more than that. Therefore, the MTConnect protocol needs a set of cloud application specifications to supplement it, enabling truly smooth internet applications for CNC machine tools.
