Program, server device, and target device monitoring method

Abstract

In a system that controls and monitors target devices with diverse platforms, this program provides a method for appropriately retrieving target device information even when the node ID of the node where the target device information is stored changes. [Solution] When the server starts up, the address space module generates address space information from the information model definition file, recursively searches for nodes in the address space, and extracts hierarchical information of the nodes based on the results. Based on the extracted hierarchical information, it generates a browse path that shows the position of the node in the hierarchy, and generates a second data table that shows the node's browse path in association with the node ID.

Description

Technical Field

[0001] The present invention relates to a program for transmitting operation instructions to a target device and receiving notifications from the target device, a server device, and a method for monitoring the target device.

Background Art

[0002] More than 50% of the manufacturing industry plans to invest in smart factories, and it is said that the market investment amount will reach 20 trillion yen by 2025. There are various backgrounds, such as being forced to innovate due to global factors such as a shortage of human resources, the limit of creating added value only through manufacturing, and environmental and trade issues. Although the visibility of factory facilities and personnel is gradually progressing in Japan, it is said that only 4% of companies can effectively utilize the collected data. In such a situation, in the plastic molding market, as one of the methods to solve these problems, a standard called EUROMAP has been established and standardization is being promoted.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Although it is desired to make production results and quality visible, there are variations in communication interfaces and available information for each piece of equipment, and the lack of progress in IoT implementation is a common problem in the manufacturing industry. Especially in plastic molding as shown in FIG. 10, since the molding conditions affect the quality of the product, variations in the available information become a bottleneck in promoting improvement. Furthermore, there is also a current situation where there is a divergence in functions between existing equipment and the latest equipment, hindering the acceleration of DX implementation.

[0005] To address the aforementioned challenges, developing custom servers tailored to specific equipment would involve a vast array of communication protocol specifications that the servers must cover, resulting in high learning costs. Consequently, personnel training would be lengthy, potentially leading to situations where customer requirements cannot be met. Furthermore, server development presents challenges such as frequent software updates and the difficulty in securing the necessary human resources to handle them. Furthermore, each company using the server requires a different development platform, and development cannot begin without understanding the client company's development environment. As a result, development periods become longer and development costs increase.

[0006] The above-mentioned publication discloses a system that solves the problems described above. Incidentally, if the information model is updated or a server device with a different implementation method is used, the namespace number may change, and the node ID of the node where the target device information is stored may change. The change of the namespace number is performed by the toolkit 61. In other words, the node ID is defined based on the namespace number and a predetermined identifier, and the namespace number may change automatically when the information model definition file is updated or when a server device with a different implementation method is used. In that case, there is a problem in that the target device information cannot be obtained based on the node ID.

[0007] This invention has been made in view of the above circumstances, and its purpose is to provide a program, a server device, and a method for monitoring target devices that can appropriately acquire target device information even when the node ID of the node where the target device information is stored changes, in a system for controlling and monitoring target devices that have diverse platforms. [Means for solving the problem]

[0008] The present invention is a program executed by a server device that receives notifications from a target device and sends operation instructions to the target device, comprising: a first data table that shows the association between identification information of the target device from which data is to be acquired and a browse path which is a logical address and file name on the system; an information model definition file that defines a plurality of nodes that indicate addresses in the address space where the target device information acquired from the target device is stored; a manager module that communicates with the target device using a predetermined communication method, acquires target device information from the target device shown in the first data table and stores it at the address of the node shown in the information model definition file; and data for a communication method for data exchange used for communication between the higher management device or a provider that communicates with the higher management device, obtained from the higher management device or the provider. A program that causes a computer to execute an address space module for creating or deleting an address space to be stored in an accessible manner, and a generation module for creating the first data table, the manager module, and the address space module, wherein the address space module is a program that executes a first step of creating address space information in the information model definition file, a second step of recursively searching for nodes in the address space, a third step of extracting hierarchical information of the nodes based on the search results of the second step, a fourth step of generating a browse path indicating the position of the nodes in the hierarchy based on the hierarchical information extracted in the third step, and a sixth step of generating a second data table that shows the browse path of each node and the node ID of the node in association with each of the nodes.

[0009] Preferably, when reading the target device information from the node, the manager module performs the following steps: an eleventh step of referring to the first data table to obtain a browse path corresponding to the identification information of the target device in the target device information; a twelfth step of referring to the second data table to obtain the node ID corresponding to the browse path obtained in the eleventh step; and a thirteenth step of reading the target device information stored in the address space using the node ID obtained in the twelfth step.

[0010] Preferably, the node includes attribute information including the namespace number and the index name, the third step extracts the index name included in the attribute information of the node, and the fourth step generates the browse path including the extracted index name.

[0011] Preferably, the system further includes a server module that controls the operation of the manager module and the address space module. The generation module generates the server module.

[0012] Preferably, when the generation module generates the manager module, the address space module, and the server module, it transfers execution privileges to the server module, and after the execution privileges are transferred, the server module performs a process to associate the address space defined by the manager module and the address space module with the higher-level management device or the provider via the manager module so that the address space can be accessed.

[0013] Preferably, the manager module includes a data manager module that acquires data from the target device and writes the data to the target device.

[0014] Preferably, the manager module further comprises a method manager module that controls operations on the target device and an event manager module that controls notifications from the target device.

[0015] Preferably, when the program is started, the generation module generates the modules specified in the operation specification data to be generated from among the server module, address space module, data manager module, method manager module, and event manager module, and does not generate any modules that are not specified.

[0016] Preferably, the operation specification data specifies the operation of the server module after the execution rights have been transferred.

[0017] Preferably, the generation module generates one or more modules from among the server module, address space module, data manager module, method manager module, and event manager module, which are specified in the operation specification data to be generated.

[0018] Preferably, the node ID is defined based on a namespace number and a predetermined identifier. If the aforementioned information model definition file is updated, or if a server device with a different implementation method is used, ( ) will change the namespace number.

[0019] The present invention relates to a server device that receives notifications from a target device and transmits operation instructions to the target device, comprising: a first data table that shows the identification information of the target device from which data is to be acquired, and a browse path which is a logical address and file name on the system; An information model definition file that defines multiple nodes indicating addresses in an address space where target device information acquired from the target device is stored; a manager module that communicates with the target device using a predetermined communication method, acquires target device information from the target device indicated in the first data table, and stores it in the addresses of the nodes indicated in the information model definition file; an address space module that generates or deletes the address space in which data for a communication method used for data exchange used for communication between the higher management device or a provider communicating with the higher management device is stored in an address space accessible from the higher management device or the provider; and the first data The system includes a generation module that generates a data table, the manager module, and the address space module, wherein the address space module includes a first step of generating address space information in the information model definition file, a second step of recursively searching for nodes in the address space, a third step of extracting hierarchical information of the nodes based on the search results of the second step, a fourth step of generating a browse path indicating the position of the nodes in the hierarchy based on the hierarchical information extracted in the third step, and a sixth step of generating a second data table that associates the browse path of the node with the node ID of the node for each of the nodes. This is a server device that executes [the task].

[0020] The present invention relates to a provider device that communicates with a host system and a server device, and a target device monitoring method performed using the server device. The server device includes a first data table that associates and shows identification information of the target device to be the target of data acquisition with a browsing path that is a logical address and a file name on the system, an information model definition file that defines a plurality of nodes indicating addresses of address spaces where target device information acquired from the target device is stored, a manager module that communicates with the target device in a predetermined communication method between the target device and the target device, acquires target device information from the target device indicated by the first data table, and stores the target device information at the addresses of the nodes indicated by the information model definition file, and an address space module that generates or deletes the address space that stores, in an accessible manner from the host management device or the provider that communicates with the host management device, data of a communication method for data exchange used for communication between the host management device or the provider. The address space module includes a first step of generating address space information of the information model definition file, a second step of recursively searching nodes of the address space, a third step of extracting hierarchical information of the nodes based on the search result of the second step, a fourth step of generating the browsing path indicating the position of the nodes in the hierarchy based on the hierarchical information extracted in the third step, and a sixth step of generating a second data table that associates and shows the browsing path of each node with the node ID of the node for each of the nodes. The present invention is a target device monitoring method that executes the above steps.

Advantages of the Invention

[0021] According to the present invention, an object is to provide a program, a server device, and a target device monitoring method capable of appropriately acquiring target device information even when the node ID of a node storing the target device information changes in a system for controlling and monitoring target devices having various platforms.

Brief Description of the Drawings

[0022] [Figure 1] Figure 1 is an overall configuration diagram of the business monitoring system 1 according to an embodiment of the present invention. [Figure 2] Figure 2 is a diagram for explaining the functions of each component of the business monitoring system 1 shown in Figure 1. [Figure 3] Figure 3 is a diagram for explaining the information model adopted by the system shown in Figures 1 and 2. [Figure 4] Figure 4 is a functional block diagram of the server device 13 shown in Figures 1 and 2. [Figure 5] Figure 5 is a diagram for explaining the functions of the server device 13. [Figure 6] Figure 6 is a flowchart for explaining an operation example of the server device 13. [Figure 7] Figure 7 is a flowchart for explaining the process of step ST12 shown in Figure 6 (address space generation process by the address space module 45). [Figure 8] Figure 8 is a flowchart for explaining the operation of reading the target device information stored in the nodes of the report model definition file 75. [Figure 9] Figure 9 is a flowchart for explaining the overall flow from the development to the execution of the business monitoring system shown in Figure 1. [Figure 10] Figure 10 is a diagram for explaining a conventional molding monitoring system.

Embodiments for Carrying Out the Invention

[0023] Hereinafter, the business monitoring system according to an embodiment of the present invention will be described. Figure 1 is an overall configuration diagram of the business monitoring system 1 according to an embodiment of the present invention. Figure 2 is a diagram for explaining the functions of each component of the business monitoring system 1 shown in Figure 1. The business monitoring system 1 shown in Figure 1 is effective for promoting a smart factory. As shown in Figures 1 and 2, the business monitoring system 1 processes data using, for example, the target device 11, the server device 13, the provider device 15, and the higher-level system 17.

[0024] [Server device 13] The server device 13 connects to the existing target device 11 (molding machine), enabling data exchange with the higher-level system 17 (MES) using a common communication method (communication interface, OPC UA).

[0025] [OPC UA (communication method)] OPC UA stands for Open Platform Communication Unified Architecture, and it is a standard communication method for data exchange. Initially, its main role was to act as a link between OT (operating systems) and IT (information systems), but OPC UA can handle a wide range of tasks, including data sharing to the cloud, communication between controllers and equipment, and communication between controllers. Until now, communication methods have been a chaotic mix of vendor-created standards for each piece of equipment and facility, requiring users to adapt to these different standards. By adopting OPC UA, smooth communication becomes possible without the need for individual data conversion.

[0026] OPC UA includes robust security features, enabling secure data communication when sharing data from the factory to external locations (such as office servers or the cloud). Furthermore, as shown in Figure 3, OPC UA has an information model that can standardize the content (structure) of the data. This allows for the standardization of not only the data exchange standards but also the data content, enabling the collection of similar data even when accessing equipment from multiple different vendors.

[0027] The information model shown in Figure 3 is a specification that defines the data structure and is the main element of OPC UA. An information model addresses a problem where, for example, when obtaining the number of good products from an injection molding machine (an example of a target device), the data names and locations differ between company A and company B. From the user's perspective, this requires understanding the location and names of data from both companies, which is inefficient. The information model solves this problem of having the same type of equipment but different data structures.

[0028] As shown in Figure 3, the information model has a four-layer structure: a metamodel (basic services) layer, a built-in layer, a companion layer, and a vendor-specific feature extension layer. The companion layer is an information model being developed for each industry. For example, for injection molding machines, there is EUROMAP in Europe, and the data structure between MES and injection molding machines is EUROMAP77. By storing data based on EUROMAP77, each injection molding machine manufacturer can handle data from all their injection molding machines using the same data structure from higher-level systems such as MES.

[0029] OPC UA has the following functions: Acquire and write data from the existing target device 11 (equipment). Using the OPC UA information model, you can freely create and publish data structures. A unified information model can be published to higher-level systems such as MES. Since customer requirements vary, we can choose whether or not to include certain features.

[0030] [EUROMAP] By utilizing EUROMAP, it becomes possible to standardize the content of data that varies from vendor to vendor. This enables connection with target devices 11 from multiple different companies (platforms).

[0031] In addition to acquiring information such as the operating status of the target device 11 (molding machine), mold temperature, and number of shots, it is also possible to set and instruct the molding machine, including its operating mode (automatic / manual / semi-automatic).

[0032] EUROMAP is a standard specifically for the plastic molding market. EUROMAP has different standards depending on the system or equipment being used, and the standards adopted for server device 13 are EUROMAP77 and EUROMAP83.

[0033] EUROMAP77 and EUROMAP83 are standards between the higher-level system 17 and the target device 11, allowing information such as the operating status of the molding machine, production results, and mold temperature to be collected from the molding machine. They also provide specifications for the MES to issue instructions to the molding machine, such as changing the operating mode (automatic / manual / semi-automatic), managing jobs, and sending setting data. This means that EUROMAP77 and 83 can be used not only to collect and visualize data from equipment, but also to analyze the collected data and access the equipment for subsequent improvements.

[0034] [Server device 13] In order to make the target device 11 compatible with the aforementioned OPC UA communication method, the following challenges exist, as mentioned above. To address the aforementioned challenges, developing custom servers tailored to specific equipment would involve a vast array of communication protocol specifications that the servers must cover, resulting in high learning costs. Consequently, personnel training would be lengthy, potentially leading to situations where customer requirements cannot be met. Furthermore, server development presents challenges such as frequent software updates and the difficulty in securing the necessary human resources to handle them. Furthermore, each company using the server requires a different development platform, and development cannot begin without understanding the client company's development environment. As a result, development periods become longer and development costs increase. The server device 13 has the following configuration (functions) to solve these problems.

[0035] Figure 4 is a functional block diagram of the server device 13 shown in Figures 1 and 2. As shown in Figure 4, the server device 13 includes, for example, a communication unit 31, a memory 33, and a processing unit 35.

[0036] The communication unit 31 communicates with the target device 11 and the provider device 15 shown in Figure 1. Memory 33 stores the program PRG1 executed by the processing unit 35. Program PRG1 describes the operation of the provider device 15 as defined herein. The processing unit 35 executes the program PRG1 to realize the functions of the server device 13 described herein.

[0037] Figure 5 is a diagram illustrating the functions of the server device 13. As shown in Figure 5, the server device 13 uses, for example, a generation module 41, a server module 43, an address space module 45, a first data table 81, a data manager module 49, an event manager module 51, and a method manager module 53 as functional modules. The processing of these functional modules is described in program PRG1.

[0038] Program PRG1 contains operation specification data 39 that defines how to generate and start (start) the module shown in Figure 5. Operation specification data 39 also describes the operation of the server module 43 after execution privileges have been transferred. This significantly reduces the development burden of the server device 13, which is tailored to the attributes (industry) of the target device 11.

[0039] The generated module 41 is generated when the server device 13 is started or when the program PRG is started, and generates other modules based on the operation specification data 39. The modules specified to be generated by the operation specification data 39 differ depending on the attributes of the target device 11. That is, some or all of the modules shown in Figure 5 will be activated. After generating other modules, the generation module 41 transfers execution privileges to the server module 43. The generation module 41 may generate multiple copies of each of the following: server module 43, address space module 45, first data table 81, data manager module 49, event manager module 51, and method manager module 53. After generating each of the above modules, the server module 43 performs a process to associate the data manager module 49, event manager module 51, and method manager module 53 with the address space (data structure) defined by the address space module 45, via these manager modules, so that the provider device 15 can see (access) the address space.

[0040] The server module 43 issues start commands to the address space module 45, the first data table 81, the data manager module 49, and the method manager module 53, and controls their operation. After the server module 43 has been transferred execution privileges from the generation module 41, it performs, for example, the operations specified in the operation specification data 39.

[0041] The address space module 45 creates or deletes an address space (data structure selection) that stores data of a predetermined data exchange communication standard (OPC UA) in a manner accessible from the provider device 15. This address space is located in the memory of the server device 13, or in the memory of the target device 11 or other devices.

[0042] The first data table 81 is configuration information that defines the target device from which the data manager module 49 will acquire data. The first data table 81 shows the identification information of the target device 11 from which data is to be acquired, and the browse path, which is the logical address and file name on the system, in association with each other. The browse path shows the logical address and file name of the target device information for target device 11 in the system. Addresses within the address space are accessed using the node ID.

[0043] The information model definition file 75 is a file that defines the information model described above, and specifies multiple nodes that indicate the addresses of the address space where the target device information obtained from the target device 11 is stored. In this embodiment, the node ID that identifies each node includes a namespace number (namespace identification information) and an identifier (an identifier within a namespace that does not overlap within the same namespace, but may overlap between different namespaces: an index name). In this embodiment, if the information model is updated or a server device with a different implementation method is used, the namespace number may change and the node ID may change. In this embodiment, this problem is solved by the processing of the address space module 45 as shown below. Additionally, each node is assigned a standard attribute called "BrowseName". The "BrowseName" field contains the namespace number and the index name. Index names are names that are not guaranteed to be unique and are used for searching. Names can be the same as long as the node ID is unique within the same namespace, even if they are not unique and the system works even if they are incorrect. Furthermore, the format of such attribute information is not particularly limited in this invention.

[0044] The data manager module 49 acquires data from the target device 11 and writes the data to the target device 11. The data manager module 49 refers to the first data table 81 to identify the area to access data on the target device 11. The data manager module 49 communicates with the target device 11 using a predetermined communication method, retrieves target device information from the target device 11 indicated in the first data table 81, and stores it in the aforementioned address of the node indicated in the information model definition file 75.

[0045] As will be described later, when the data manager module 49 receives a request to read target device information, it refers to the first data table 81 and obtains a browse path corresponding to the identification information of the target device 11. Then, the data manager module 49 refers to the second data table 82 to obtain the node ID corresponding to the acquired browse path. Next, the data manager module 49 uses the acquired node ID to retrieve the target device information stored in the address space described above. The data manager module 49 outputs the acquired target device information to a predetermined module or performs predetermined processing based on that information. In other words, the node ID is used to access addresses in the address space and retrieve data.

[0046] The event manager module 51 controls notifications from the target device 11. Specifically, the server device 13 sends notifications (data, etc.) received from the target device 11 to the provider device 15, and the provider device 15 then sends this to the higher-level system 17.

[0047] The method manager module 53 controls operations on the target device 11. Specifically, it controls the target device 11 based on operation instructions (methods) received by the server device 13 from the higher-level system 17 via the provider device 15.

[0048] The following describes an example of the operation of server device 13. The operation of the server device 13 is defined in the operation specification data 39 and is executed by the processing unit 35. Figure 6 is a flowchart illustrating one example of the operation of the server device 13. Each of the following steps is realized by the processing unit 35 shown in Figure 4 executing the operation specification data 39. Step ST11: The processing unit 35 executes the operation specification data 39, and the generation module 41 generates each module shown in Figure 5. Execution privileges are transferred from the generation module 41 to the server module 43.

[0049] Step ST12: The server module 43 uses the address space module 45 to create an address space within the server device 13. In other words, after the creation of each of the above modules, the server module 43 performs a process to associate the data manager module 49, the event manager module 51, and the method manager module 53 with the address space defined by the address space module 45, via these manager modules, so that the provider device 15 can see (access) the address space. The process in step ST12 will be explained in detail later.

[0050] Step ST13: The server module 43 uses the first data table 81 to establish a connection with the target device 11. Specifically, each manager module makes it possible to access the data stored in the memory of the target device 11.

[0051] Step ST14: The server module 43 starts the data manager module 49, enabling read / write access to the target device 11.

[0052] Step ST15: The server module 43 starts the event manager module 51, enabling it to receive notifications from the target device 11.

[0053] Step ST16: The server module 43 starts the method manager module 53, enabling it to issue commands to the target device 11.

[0054] The following describes the process of step ST12 shown in Figure 6 (address space generation process by address space module 45). Figure 7 is a flowchart illustrating the process of step ST12 shown in Figure 6 (address space generation process by address space module 45). Step ST21: The address space module 45 reads the information model definition file 75.

[0055] Step ST22: The address space module 45 generates address space information from the information model definition file 75 read in step ST21.

[0056] Step ST23: The address space module 45 recursively searches for nodes in the address space generated in step ST22.

[0057] Step ST24; The address space module 45 extracts hierarchical information of multiple nodes in the information model definition file 75 and the index name in the attribute information "BrowseName" of the node, based on the node search results in step ST23.

[0058] Step ST25: The address space module 45 generates a browse path (node ​​location information, / representation) that indicates the position of each node in the hierarchy, based on the hierarchy information extracted in step ST24. The browse path is node location information, and the hierarchy is represented using notation such as " / ". The browse path also includes the index name extracted in step ST25.

[0059] Step ST26: The address space module 45 generates a second data table 82 that associates the browse path of the node generated in step ST25 with the node ID (namespace) of the node for each node in the information model definition file 75.

[0060] In this embodiment, as described above, a browse path without using namespace numbers is generated, and a second data table 82 is generated that shows the correspondence between the browse path and the node ID. This allows a user to specify a call operation using a browse path when reading target device information for target device 11, and then obtain the node ID corresponding to that browse path by referring to the second data table 82. In other words, even if the information model is updated or the namespace number changes due to the use of a server device with a different implementation method, the appropriate target device information can be accessed using the changed node ID.

[0061] The following describes the operation of reading the target device information stored in the node of the information model definition file 75. Figure 8 is a flowchart illustrating the operation of reading the target device information stored in the node of the report model definition file 75. Step ST31: When the data manager module 49 receives a request to read target device information specifying the target device 11, it proceeds to step ST32.

[0062] Step ST32: The data manager module 49 refers to the first data table 81 and obtains a browse path corresponding to the identification information of the target device 11 related to the request in step ST31.

[0063] Step ST33: The data manager module 49 refers to the second data table 82 to obtain the node ID corresponding to the browse path obtained in step ST32.

[0064] Step ST35: The data manager module 49 uses the node ID obtained in step ST33 to retrieve the target device information stored in the address space described above. The data manager module 49 outputs the acquired target device information to a predetermined module or performs predetermined processing based on that information.

[0065] As mentioned above, even if the namespace number changes, if the brush-up data can be obtained, the address space can be accessed using the appropriate node ID to retrieve the target device information.

[0066] The developer of server device 13 uses client computer 65 to develop server device 13 through the functions of toolkit 61. Specifically, they develop operation specification data 39, address space module 45, and first data table 81. They also create data manager module 49 if a new device is required.

[0067] Toolkit 61 is a Software Development Kit (SDK) that enables rapid integration of OPC UA connectivity. It consists of a library set including a concisely documented programming interface, tools for testing and simulation, and related sample applications. This powerful development tool can dramatically shorten development time.

[0068] The hardware of server unit 13, as an IoT device, was one of the first to standardize so-called "IoT functions" as applications, such as data collection from sensors, PLCs, and CNCs, data transmission to higher-level networks, and conversion of various communication protocols. Equipped with these "IoT functions," it offers multiple product lines with a wide range of interfaces. Furthermore, the hardware of the server unit 13 is designed to be power-efficient and environmentally resistant, and eliminates short-life components. The lineup includes multiple controllers and I / O modules, and in addition to M2M controllers for sensor connection and M2M EUROMAP Gateways for PLC connection, it has expanded its scope to include real-time controllers that can be programmed using the IEC61131-3 compliant PLC language.

[0069] The server device 13 can use a software development kit that allows various hardware to be freely converted into IoT devices, and it can also use a software development tool that enables the addition of programs using an SD card while retaining the "IoT functionality".

[0070] The development method for server device 13 is described below. The server device 13 is developed by a developer operating the client computer 65 shown in Figure 5 and generating operational specification data 39 via the toolkit 61 using a development program (core architecture) that makes all the modules shown in Figure 5 available for use.

[0071] In other words, the developer writes the operation specification data 39 so that the generation module 41 generates only the minimum necessary modules for the server device 13 under development from among the generation module 41, server module 43, address space module 45, first data table 81, data manager module 49, event manager module 51, and method manager module 53 (hereinafter referred to as all modules) shown in Figure 5. That is, the operation specification data 39 is written so that unnecessary modules are not generated.

[0072] In this way, the operation specification data 39 can be generated through the simple task of writing the operation specification data 39 to generate only the necessary modules, and this essentially constitutes the development of the server device 13. In other words, the modules of the server device 13 that correspond to the target device 11 of multiple platforms can be made common, thereby reducing the development burden.

[0073] [Provider device 15 (MES)] Regarding the higher-level MES system, by using EUROMAP Provider software, existing MES systems can exchange data and issue commands to equipment using the OPC UA communication interface and EUROMAP specifications.

[0074] MES stands for Manufacturing Execution System, which refers to a "manufacturing execution system" that manages the manufacturing process and provides instructions and support to workers. With the goal of "utilizing resources efficiently and improving production efficiency," it is a system that collects on-site information and supports the improvement of production efficiency through evaluation and analysis in order to continuously improve quality, cost, and delivery time in production activities. It acts as a link between the ERP system, which handles production management, inventory management, and order management, and each manufacturing process on the factory's production line. As shown in Figure 9, it has 11 functions, including work scheduling, allocation and monitoring of production resources, quality control, data collection, and maintenance management, and users utilize the functions as needed. As the economy becomes increasingly globalized, production sites are required to handle small-batch, high-mix production and shorten lead times, making the need for rationalization through the introduction of MES (Manufacturing Execution System) a growing priority. Aiming to improve the efficiency of manufacturing processes with MES, which allows for the management of raw materials, delivery dates, and production processes, is an urgent issue for the manufacturing industry.

[0075] [Provider device 15] The provider device 15 is linked to the higher-level system 17 and also connects to the target device 11 (molding machine). The EUROMAP77 / 83 specifications are being developed with a view to directly monitoring and controlling molding machines from the MES. However, currently, there are very few MES systems that can access molding machines using EUROMAP77 / 83 + OPC UA. The main reasons are that the MES already in place does not support OPC UA, and even if it did, a program for the MES would be required to send instructions directly to the molding machine. In any case, the significant initial costs involved in implementation make it a high hurdle.

[0076] The server device 13 can acquire information from the target devices (molding machines from various manufacturers) 11, but it does not have the functionality to link with the MES. The server device 13 alone cannot solve the above problem. Therefore, a provider device 15, which is an OPCUA client that works in conjunction with the server device 13, was developed in parallel.

[0077] The provider device 15 implements the following functions using OPC UA and is responsible for information transmission between the server device 13 and the MES. Data acquisition in accordance with EUROMAP77 / 83. • Data writing in accordance with EUROMAP77 / 83 • Event monitoring of the target device 11 (molding machine) in accordance with EUROMAP 77 / 83 (e.g., notification of the number of good products after each molding cycle is completed). • Instructions and operations to the target device 11 in accordance with EUROMAP 77 / 83 (e.g., starting and stopping the operating mode). In particular, detailed control over event monitoring and command operations is specified in EUROMAP77 / 83.

[0078] Furthermore, the provider device 15 is connected to the higher-level system 17 as follows. To enable use from the higher-level system 17 already installed in the factory, the connection between the provider device 15 and the higher-level system 17 is provided as a software library that is directly embedded in the program of the higher-level system 17. The provider device 15 comes standard with an OPC UA client, minimizing the significant development costs associated with connecting to OPC UA. If it cannot be directly integrated into the higher-level system 17, or if integration is desired but there are no engineers capable of handling it, then an application using the provider device 15 can be developed.

[0079] If you have not yet implemented MES, we offer a solution consisting of "Server Device 13 + Provider Device 15 + IB-Mes" with pre-installed software and connection verification already completed, including Uniface's IB-Mes. IB-Mes has both a standard on-premise version and a cost-effective cloud version, and the provider device 15 supports both. Both standard support with IB-Mes and custom development for MES are carried out to match the environment of the target device 11 as closely as possible.

[0080] The following describes the overall flow of Business Monitoring System 1. Figure 9 is a flowchart illustrating the overall flow from development to implementation of business monitoring system 1. Step ST41: The operation specification data 39 to be executed by the server device 13 is developed as described above.

[0081] Step ST42: A provider program is developed to be executed by the provider device 15. This provider program is developed to operate as a client of the server device 13.

[0082] Step ST43: The server device 13 and the provider device 15 are executed to transmit data from the target device 11 to the higher-level system 17, and the higher-level system 17 controls the target device 11.

[0083] As explained above, according to the business monitoring system 1, the server device 13 is configured in advance to generate each module shown in Figure 5, and when developing it to be compatible with the target device 11, it is sufficient to create operation specification data 39 to generate only the module corresponding to the target device 11 from among the modules. This significantly reduces the development burden compared to developing the entire configuration of the server device 13 from scratch.

[0084] The present invention is not limited to the embodiments described above. In other words, those skilled in the art may make various modifications, combinations, subcombinations, and substitutions with respect to the components of the embodiments described above, within the technical scope of the present invention or its equivalents.

[0085] In the embodiments described above, a molding machine was used as the target device 11, and EUROMAP, which corresponds to the molding machine, was used as the companion layer shown in Figure 3. However, other devices may be used as the target device 11, and industry standards corresponding to those devices may be used as the companion layer.

[0086] Furthermore, in the embodiment described above, the modules shown in Figure 5 were given as examples of modules for the server device 13, and the operation specification data 39 was defined to generate all of them. However, the configuration of the modules and the modules to be generated may be only a part of them.

[0087] In the embodiment described above, transmission and reception between the server device 13 and the higher-level system 17 were performed via the provider device 15. However, depending on the communication method, the server device 13 and the higher-level system 17 may communicate directly. In that case, the higher-level system 17 will be able to access the address space defined by the address space module 45 shown in Figure 5. [Industrial applicability]

[0088] The present invention is applicable to a monitoring system that transmits operation instructions to a target device or receives notifications from said target device. [Explanation of Symbols]

[0089] 1…Business monitoring system 11…Target device 13…Server device 15...Provider equipment 17…Higher-level system 31… Communications Department 33…Memory 35… Processing Unit 39…Operational specification data 41…Generating Module 43…Server Module 45…Address Space Module 51…Event Manager Module 53…Method Manager Module 61…Toolkit 65…Client Computer 81...First data table 82...Second data table

Claims

1. A program executed by a server device that receives notifications from a target device and sends operation instructions to the target device, A first data table that shows the identification information of the target device from which data is to be acquired, and the browse path which is the logical address and file name on the system, An information model definition file that defines multiple nodes indicating addresses in the address space where the target device information acquired from the aforementioned target device is stored, A manager module that communicates with the target device using a predetermined communication method, obtains target device information from the target device indicated in the first data table, and stores it at the address of the node indicated in the information model definition file, An address space module that generates or deletes the address space in which data for a communication method used for data exchange in communication between a higher management device or a provider communicating with the higher management device is stored in an address space accessible from the higher management device or the provider, A generation module that generates the first data table, the manager module, and the address space module. A program having, The address space module, A first step of generating address space information for the aforementioned information model definition file, A second step involves recursively searching for nodes in the address space, A third step is to extract hierarchical information of the node based on the search results of the second step, A fourth step involves generating the browse path that indicates the position of the node in the hierarchy based on the hierarchical information extracted in the third step, A sixth step is to generate a second data table that shows the association between the browse path of the node and the node ID of the node for each of the aforementioned nodes. Execute, The aforementioned manager module When reading the target device information from the node, the 11th step is to refer to the first data table and obtain a browse path corresponding to the identification information of the target device in the target device information, A twelfth step involves obtaining the node ID corresponding to the browse path obtained in the eleventh step by referring to the second data table, A 13th step involves reading the target device information stored in the address space using the node ID obtained in the 12th step, and The manager module executes program.

2. The node includes attribute information including a namespace number and an index name, The third step involves extracting the index name included in the attribute information of the node, The fourth step is to generate the browse path that includes the extracted index name. The program according to claim 1.

3. Server module that controls the operation of the manager module and the address space module. It further possesses, The generation module generates the server module. The program according to claim 1.

4. The aforementioned generation module is When the manager module, address space module, and server module are generated, Transfer execution permissions to the aforementioned server module, After the execution rights are transferred, the server module performs a process to associate the address space defined by the manager module and the address space module with the address space accessible from the higher-level management device or the provider via the manager module. The program according to claim 3.

5. The manager module described above is A data manager module that acquires data from the target device and writes the data to the target device. has The program according to claim 1.

6. The manager module described above is A method manager module that controls operations on the aforementioned target device, An event manager module that controls notifications from the aforementioned target device and It further possesses The program according to claim 5.

7. When the program is started, the generation module generates the modules specified in the operation specification data to be generated from among the server module, address space module, data manager module, method manager module, and event manager module, and does not generate any modules that are not specified. The program according to claim 6.

8. The aforementioned operation specification data defines the operation of the server module after the execution rights have been transferred. The program according to claim 7.

9. The generation module generates one or more modules from among the server module, address space module, data manager module, method manager module, and event manager module, which are specified in the operation specification data to be generated. The program according to claim 8.

10. The aforementioned node ID is defined based on a namespace number and a predetermined identifier. If the aforementioned information model definition file is updated, or if a server device with a different implementation method is used, the namespace number may be changed by a toolkit outside the server device. The L according to claim 1

11. A server device that receives notifications from a target device and transmits operation instructions to the target device, A first data table that shows the identification information of the target device from which data is to be acquired, and the browse path which is the logical address and file name on the system, An information model definition file that defines multiple nodes indicating addresses in the address space where the target device information acquired from the aforementioned target device is stored, A manager module that communicates with the target device using a predetermined communication method, obtains target device information from the target device indicated in the first data table, and stores it at the address of the node indicated in the information model definition file, An address space module that generates or deletes the address space in which data for a communication method used for data exchange in communication between a higher management device or a provider communicating with the higher management device is stored in an address space accessible from the higher management device or the provider, A generation module that generates the first data table, the manager module, and the address space module. It has, The address space module, A first step of generating address space information for the aforementioned information model definition file, A second step involves recursively searching for nodes in the address space, A third step is to extract hierarchical information of the node based on the search results of the second step, A fourth step involves generating the browse path that indicates the position of the node in the hierarchy based on the hierarchical information extracted in the third step, A sixth step is to generate a second data table that shows the association between the browse path of the node and the node ID of the node for each of the aforementioned nodes. Execute, The aforementioned manager module When reading the target device information from the node, the 11th step is to refer to the first data table and obtain a browse path corresponding to the identification information of the target device in the target device information, A twelfth step involves obtaining the node ID corresponding to the browse path obtained in the eleventh step by referring to the second data table, A 13th step involves reading the target device information stored in the address space using the node ID obtained in the 12th step, and The manager module executes Server device.

12. A method for monitoring target devices using a provider device that communicates with a higher-level system and a server device, and a server device, The server device is A first data table that shows the identification information of the target device from which data is to be acquired, and the browse path which is the logical address and file name on the system, An information model definition file that defines multiple nodes indicating addresses in the address space where the target device information acquired from the aforementioned target device is stored, A manager module that communicates with the target device using a predetermined communication method, obtains target device information from the target device indicated in the first data table, and stores it at the address of the node indicated in the information model definition file, An address space module that generates or deletes the address space in which data for a communication method used for data exchange in communication between a higher management device or a provider communicating with the higher management device is stored in an address space accessible from the higher management device or the provider, A generation module that generates the first data table, the manager module, and the address space module. It has, The address space module, A first step of generating address space information for the aforementioned information model definition file, A second step involves recursively searching for nodes in the address space, A third step is to extract hierarchical information of the node based on the search results of the second step, A fourth step involves generating the browse path that indicates the position of the node in the hierarchy based on the hierarchical information extracted in the third step, A sixth step is to generate a second data table that shows the association between the browse path of the node and the node ID of the node for each of the aforementioned nodes. Execute, The aforementioned manager module An eleventh step in which, when reading the target device information from the node, a browse path corresponding to the identification information of the target device in the target device information is obtained by referring to the first data table, A twelfth step involves obtaining the node ID corresponding to the browse path obtained in the eleventh step by referring to the second data table, A 13th step involves reading the target device information stored in the address space using the node ID obtained in the 12th step, and The manager module executes Method for monitoring the target device.

Images