As manufacturing sites become smarter, the demand for various industrial applications, such as monitoring systems and HMI, has been increasing. At the same time, research focused on the intelligence and efficiency of manufacturing equipment is also actively progressing. The information required for these industrial applications or research efforts is generated based on data from manufacturing sites. This data is either collected from external devices such as sensors attached to the equipment or directly acquired from the equipment itself. Among these, machine tools are highly complex equipment with a large amount of data to monitor, and their long lifespan often leads to a mixed environment of heterogeneous equipment. Developing industrial applications or conducting research in such heterogeneous environments is challenging. Generally, machine tools are controlled by CNCs, and communication with the CNC is essential to understand the machine’s status. Most CNC manufacturers provide APIs tailored to user requirements, allowing data acquisition and utilization through these APIs [1,2]. However, these APIs are often compatible only with the specific manufacturer’s products, requiring additional development to apply them to other CNCs. To address this issue, some CNC manufacturers have begun to additionally provide industrial standard protocols, such as OPC-UA or MTConnect, and research has been conducted to integrate multiple pieces of equipment at a manufacturing site under a single industrial standard protocol [3]. However, due to the differences in industrial standard protocols used by each manufacturer, integration across heterogeneous machines remains challenging, and unifying each manufacturing site under a single protocol requires separate integration efforts for each site. Consequently, application developers and researchers still need to develop separate communication functions for each CNC machine. To address this issue, a CNC interface platform was developed to unify communications across heterogeneous CNCs [4] and the platform was released under the name TORUS [5]. Based on an abstract Machine Data Model (state model) that represents the state of the machine tool, TORUS is a platform for the development and operation of applications that exchange data between CNCs and applications.

TORUS provides a unified interface for heterogeneous equipment, reducing the development costs of such applications. By using the integrated interface API of TORUS, developers can save time and money without needing to study the API of each CNC vendor. However, TORUS has limitations in its development and operational environments. Since it was developed for the Windows OS environment, which is commonly used by CNC vendors’ APIs, TORUS operates only on Windows OS, as shown in Fig. 1, and applications using the TORUS API, such as the Api.getData( ) function, must run on the same computer as TORUS. Furthermore, the TORUS API only supports C++ and C#.

To solve these limitations, a gateway application was proposed, as shown in Fig. 2, which allows applications that do not use the TORUS API directly to use TORUS indirectly. One example is an OPC UA Server using the TORUS API, and the server provides access TORUS through the OPC UA interface [6]. OPC UA is a widely used industrial standard protocol with high compatibility with industrial equipment. However, it requires a specific client, and the application development process can be complex [7].

We have also developed a gateway application based on MTConnect. MTConnect is an open industrial communication protocol for connecting manufacturing equipment [8]. MTConnect consists of an agent and an adapter, where the agent collects data from equipment and the adapter provides the data in a standardized XML format, allowing users to access it. MTConnect provides all data in XML at once, allowing users to filter the necessary data within XML, but the structure or content of the XML data items cannot be modified in real time. The MTConnect gateway application we developed also operates by allowing users to obtain predefined data in XML format via the HTTP protocol. This method is suitable for building a monitoring system that uses specific data. However, this approach has limitations in flexibility when the type or range of requested data changes frequently. An example of this is ‘macro’ data in machine tools. Macros can number in the hundreds for each model and are distinguished by macro numbers. Using OPC UA, desired macros can be specified through OPC UA node addresses. However, to provide macro data via MTConnect, it would be necessary to provide data for the entire macro list, or to change the configuration of the agent and adapter each time the required macro list is updated. Therefore, a gateway application through MTConnect is suitable for simple monitoring purposes but may not be appropriate if data items need to change flexibly according to user purposes.

REST API, on the other hand, allows specific data items or functions to be targeted through URIs, just like OPC UA. Additionally, it is a simple and generic interface that operates over HTTP and is commonly used in web services and mobile applications. REST API can be easily tested and accessed through simple tools like web browsers or cURL, lowering the entry barrier for developers. It is also easily usable in almost any environment that provides an HTTP client. Due to these advantages, its usage in manufacturing sites is increasing. This paper explains how to use TORUS with a REST API by describing the development of a web server using the TORUS API. The developed web server receives REST API requests from clients, translates them into TORUS API requests, communicates with the CNC through TORUS, and returns the results to the client.

This paper has two main objectives. The first is to demonstrate that even non-expert developers can easily communicate with CNCs at manufacturing sites through TORUS-based gateway applications. The second is to enable anyone to develop a gateway application using not only OPC UA or REST API, but also other interfaces by referencing this paper.

TORUS has a Machine Data Model that defines the state of machine tools. The reason various machine tools can be managed through a unified interface is that the state information of each machine tool is mapped to a common model called the Machine Data Model. The items, descriptions, and usage of the Machine Data Model can be found in the TORUS manual. Fig. 3 shows how to retrieve the value of the machine position from the Machine Data Model by referencing the manual. The process of acquiring data from the machine tools through TORUS using the TORUS API is described in detail in the TORUS manual, so it will not be covered in this paper. When an application retrieves data from TORUS using the Api.getData( ) function of the TORUS API, the Machine Data Model is used to distinguish the data. The Machine Data Model represents the state information of a machine tool, uniquely identified by a URI. This is how TORUS consistently represents the states of heterogeneous CNCs that have different representation methods. Since TORUS is not dependent on any specific machine tool, this common data representation is essential. If the gateway application does not use the Machine Data Model, a new method would need to be created to consistently represent the states of different machines. Utilizing the existing Machine Data Model is more efficient. Therefore, even when adding new interfaces through the TORUS gateway application, the Machine Data Model must still be usable as it is.

In the previously developed OPC UA gateway application, the URI of the Machine Data Model was used as the address of the Node. Since each Node in OPC UA has a unique address, it was possible to use the Machine Data Model as the address.

The TORUS REST API gateway application developed in this study opens a web server and performs requests by receiving the Machine Data Model as a URI. The URI is a core element of the REST API, which identifies web resources. The URI of the Machine Data Model can be directly used to interface with CNCs through the gateway application. As shown in Fig. 4, we use the HTTP methods GET, PUT, and DELETE for this purpose.

Fig. 5 shows the methodology of the TORUS REST API gateway application. The gateway application runs a server, and users input the address and filter of the Machine Data Model by converting them into the required format. The scheme of the Machine Data Model is “data.” In the gateway application, this is converted to “http” for use. Users then input the host and port of the server and the address of the Machine Data Model as the path, with the filter used as a query. Because the REST API is used, these requests can be made through a browser or various HTTP libraries. Upon receiving the request, the gateway application converts the request into the address and filter of the Machine Data Model and receives the result from TORUS, which is then returned as the response. Since the result from TORUS can be converted into JSON format, it can be returned in a web environment without any issues.

In TORUS, the Machine Data Model is used to read or modify data. To read data, the Api.getData( ) function is used, which functions similarly to the GET method in HTTP. To modify data, the Api.updateData( ) function is used, similar to the PUT method in HTTP.

TORUS also provides special functions that do not belong to the Machine Data Model. These are cases where the representation methods for each CNC are too different to create a unified data model or when the function does not belong to the machine tools’ state information. A representative example is the function for accessing part programs. Uploading, downloading, or deleting part programs from the CNC is not part of the machine tools’ status, so it is not included in the Machine Data Model. Therefore, functions like Api.getData( ) and Api.updateData( ), which use the Machine Data Model as a parameter, cannot be used for file access. To access files, TORUS API functions such as Api.UploadFile( ), Api.DownloadFile( ), and Api.CNCFileDelete( ) must be used. These functions are provided specifically for file handling, and their detailed usage can be found in the TORUS manual. The key point is that these functions do not use the Machine Data Model. Therefore, they do not have a URI, and new URIs must be created to use these functions in the gateway application.

As shown in Fig. 6, we defined a new URI that does not conflict with the existing Machine Data Model. This URI can be used to specify files, allowing users to download files with the GET method, upload files with the PUT method, and delete files with the DELETE method. When the gateway application receives a request to download a file using the GET method, it uses the file path and MachineID to call the Api.DownloadFile( ) function. The Api.DownloadFile( ) function downloads the part program from the CNC to the PC where the TORUS App is running. The downloaded file’s path is specified in the LocalPath variable shown in Fig. 6. Therefore, the gateway application first downloads the part program via TORUS and then provides the file as a response through the web server, enabling users to download the part program through a browser, just like downloading any file from the web. In the case of the PUT method, the uploaded file is uploaded to the PC where the gateway application is running through the web server, and the gateway application then uploads the file to the CNC via TORUS using the Api.UploadFile( ) function. The DELETE method does not exchange any files; instead, it issues a delete command to TORUS by calling the Api.CNCFileDelete( ) function. While there are additional file-related functions, this study focuses on demonstrating the most representative functions for creating a gateway application.

As outlined in the method section, we developed the TORUS REST API gateway application. The usage of the TORUS API was referenced from the TORUS manual. Fig. 7 shows the testing environment. A CNC simulator was used for the tests. TORUS is launched, and the connection with the CNC is confirmed. Next, the TORUS REST API gateway application is executed, and a connection to TORUS is established. Once the connection is completed, the web server is opened. Both TORUS and the gateway application run on a PC using the Windows OS, while access to the server is performed from another PC in a Linux environment. This demonstrates that communication with CNCs can occur in a cross-platform environment via the TORUS REST API gateway application.

Fig. 8 shows the use of a browser and cURL to retrieve CNC data using the REST API GET method. Fig. 9 demonstrates the transmission of a target value via the REST API PUT method using cURL and confirms that the change is successfully applied. The paths and queries used in the GET and PUT tests are part of the Machine Data Model described in the TORUS manual. TORUS provides over 200 Machine Data Models. Client developers can select the desired Machine Data Model from the TORUS manual. They can then send requests to the TORUS REST API gateway application using GET and PUT methods. If the developer has experience with REST API, they can easily obtain or modify various data by simply changing the Machine Data Model.

Fig. 10 shows the process of uploading a file to CNC memory using cURL, downloading the file, and finally deleting it. As explained in the method section, handling files does not use the Machine Data Model. Therefore, we need to provide client developers with an explanation of the new URI we created for handling files. The fact that the URI points to the file path, with GET for downloading, PUT for uploading, and DELETE for removing the file, is very intuitive and easy to understand.

Fig. 11 shows an application communicating with a CNC via TORUS without using the gateway application. Application 1 collects and displays data from a Fanuc CNC, while Application 2 collects and displays data from two heterogeneous CNCs: Fanuc and Siemens. Application developers can gather data from different CNCs using common code with the TORUS API, without needing separate code for each CNC manufacturer. Both applications were developed in C#. Applications using the TORUS API must run on the same PC as TORUS, meaning each PC where the application is installed must have TORUS installed.

Fig. 12 shows a REST API application communicating with CNCs through the REST API gateway application and TORUS. TORUS only needs to be installed on the PC where the gateway application is located. REST API Application 1 in Fig. 12 is a monitoring server developed with Next.js. By using REST API, TORUS can be indirectly utilized across various development environments.

Machine tools contain a variety of complex state information, and the representation and classification of this information can vary depending on the vendor. The exclusive APIs that provide access to this state information are difficult to learn and use, especially for non-expert developers. TORUS provides unified access to heterogeneous multi-vendor machines through a unified interface, the TORUS API. However, TORUS has limitations in its operational environment. While the unified interface reduces the learning curve, it still requires specialized development knowledge and an understanding of the TORUS API. To overcome these challenges, we developed the TORUS REST API gateway application. Using the REST API allows even non-expert developers to utilize TORUS’s communication functionality with machine tools via a web browser or HTTP-related libraries. Moreover, by referencing our methodology, it is possible to develop other TORUS gateway applications that utilize different protocols or interfaces to interact with TORUS.

When using the gateway application, each vendor’s exclusive interface is first converted into the TORUS interface through TORUS, and then further converted into the gateway application’s own interface, such as a REST API. Communicating with machine tools through the TORUS gateway application adds an additional conversion step compared to directly using the TORUS API. Therefore, adding a gateway application to TORUS, rather than directly adding interfaces to TORUS itself, is not necessarily efficient in terms of speed or system resource management. For this reason, it is challenging to use for tasks requiring high-frequency time-series data collection, but it is suitable for simpler tasks where speed is not critical, such as basic monitoring of machine or work status, or modifying part programs. Additionally, using universal interfaces such as OPC UA or REST API helps reduce the development and maintenance costs of industrial software and makes it easier for researchers and developers to implement and validate their ideas in a manufacturing environment.