controller

The controller's data storage and tag management system enhances data access efficiency and controllability by integrating data from diverse IO devices, reducing processing time and development efforts.

JP2025152700APending Publication Date: 2025-10-10YOKOGAWA ELECTRIC CORP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2024054728
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-03-28
Publication Date
2025-10-10

AI Technical Summary

Technical Problem

Conventional controllers face challenges in reducing processing time for data access from IO devices due to dedicated communication programs and the difficulty in accessing data from different IO devices, even with techniques like extracting variable names and using address map files or symbol tables.

Method used

A controller design that includes a data storage unit for temporarily storing data from multiple external devices, data update units for acquiring and updating data using specific communication methods, and a program execution unit for executing programs using this stored data, with a tag management unit for managing tag definitions that allow access across different programming languages.

Benefits of technology

This design reduces processing time, simplifies data access, and allows for efficient data analysis and control across IO devices with different protocols, while minimizing the impact of changes to IO devices on application code, thus improving controllability and reducing development time.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025152700000001_ABST
    Figure 2025152700000001_ABST
Patent Text Reader

Abstract

To shorten processing time using data from an IO device.SOLUTION: A data storage section 13 temporarily holds respective data received from a plurality of IO devices 15A to 15C. Data update sections 14A to 14C respectively correspond to the IO devices 15A to 15C without overlapping, acquire data held by the corresponding IO devices 15A to 15C using communication methods used by the corresponding IO devices 15A to 15C, and use the acquired data to update the data of the corresponding IO devices 15A to 15C held by the data storage section 13. An application execution section 11A executes a program 111A using the data stored in the data storage section 13.SELECTED DRAWING: Figure 2
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to a controller. [Background technology]

[0002] Controllers are known in various production facilities, such as plants or factories, that receive information from IO (Input Output) devices, such as various sensors for temperature, flow rate, pressure, etc., and control actuators and other devices based on the received information. Various programs run on the controller, and multiple control applications operate to control the IO devices and actuators. For example, the control applications perform control calculations using data read from the IO devices and output the calculation results to the actuators for control. In addition, the control applications analyze and process data collected from the IO devices.

[0003] Applications use a variety of data, such as IO data for controlling the input and output of IO devices connected to the outside of the controller, and internal data managed within the controller.Internal data includes status data that indicates the controller's status and local data used by the application.

[0004] Various IO devices are connected using various communication protocols, and data is accessed from the control application using access procedures that conform to each communication protocol. Also, the methods for accessing and managing data collected from IO devices differ depending on the programming language used.

[0005] For example, when using C / C++, the most popular language for embedded devices, it is necessary to create methods for accessing actual IO devices and methods for managing various data on the application side. At this time, variable definitions are prepared within each program, and IO devices are assigned to variables that link IO device data with defined variables. Traditionally, linking IO device data with variables has been done on a language-by-language basis.

[0006] The following technologies are related to industrial controllers. For example, a technology has been proposed that extracts variable names from a control program to create an address map file and a header file, and then a program created using the header file accesses data using the address map file. Another technology has been proposed that creates a symbol table that allows a program executed by a programmable logic controller in an industrial automation environment to communicate with external devices. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Publication No. 2018-185772 [Patent Document 2] International Publication No. 2013 / 005350 Summary of the Invention [Problem to be solved by the invention]

[0008] However, applications running on conventional controllers have dedicated communication programs for each IO device and main programs that process data exchanged with the IO devices. This makes it time-consuming for applications to access data from different IO devices, making it difficult to reduce processing time. Furthermore, it is difficult to reduce data access time even with techniques for extracting variable names from the control program and accessing data using an address map file or creating a symbol table.

[0009] One aspect of the present invention is to reduce processing time using data from an IO device. [Means for solving the problem]

[0010] A controller according to one aspect includes the following units: a data storage unit that temporarily stores data received from a plurality of external devices; a plurality of data update units that each correspond to a corresponding external device without overlapping with any of the external devices, acquire data stored in the corresponding external device using a communication method used by the corresponding external device, and update the data stored in the data storage unit with the acquired data; and a program execution unit that executes a program using the data stored in the data storage unit. [Effects of the Invention]

[0011] According to the present invention, it is possible to reduce the processing time using data from an IO device. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram of a control system according to an embodiment. [Figure 2] FIG. 2 is a block diagram of a controller. [Figure 3] FIG. 10 is a diagram showing a state when the association between tag names and device data is changed. [Figure 4]FIG. 10 is a sequence diagram of a process for collecting data held by an IO device and acquiring the data by a program. [Figure 5] 1 is a block diagram illustrating a system for program development and generation of tag definitions. [Figure 6] FIG. 10 is a diagram showing a GUI screen used to generate a tag definition. [Figure 7] 10 is a flowchart of a program development and tag definition generation process. [Figure 8] FIG. 2 is a diagram illustrating the hardware configuration of a development computer. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, an embodiment of the controller will be described with reference to the drawings. Note that the same elements are given the same reference numerals, and duplicated descriptions will be omitted as appropriate. Furthermore, each embodiment can be appropriately combined within a range that does not cause inconsistencies.

[0014] (Overall composition) FIG. 1 is a block diagram of a control system according to an embodiment. The control system 100 is used in various manufacturing sites, such as semiconductor manufacturing plants and machine tool manufacturing plants. The control system 100 includes an upper server 20 and control devices 10A and 10B. A data input / output device 31, sensors 32, 34, and 36, and actuators 33, 35, and 37 are various devices used in the manufacturing site. The data input / output device 31 is a CPU-equipped device or a dedicated communication device equipped with a communication interface with the controller 1A. The data input / output device 31 is, for example, an EtherCAT (registered trademark) slave device, and is connected to the sensor 36 and the actuator 37.

[0015] The upper server 20 includes, for example, an industrial PC (Personal Computer) 21 and a database 22. The industrial PC 21 acquires data collected by the controller 1A or 1B using general-purpose communication such as OPC (Open Platform Communications) UA (Unified Architecture) (registered trademark) or Modbus (registered trademark). Alternatively, the industrial PC 21 may acquire data collected by the controller 1A or 1B using communication unique to the controller 1A or 1B. The industrial PC 21 then stores the acquired data in the database 22. The industrial PC 21 also sets control parameters for sensors 32, 34, and 36 and actuators 33, 35, and 37 for the controller 1A or 1B.

[0016] The control devices 10A and 10B are connected to an upper server 20. The control devices 10A and 10B control various devices arranged at the manufacturing site. There is no particular limit to the number of the control devices 10A and 10B. The control device 10A has a controller 1A. The control device 10B has a controller 1B.

[0017] The controller 1A has two CPUs (Central Processing Units) and two IO units. The CPUs and IO units of the controller 1A are connected to each other via an internal communication interface. One of the CPUs of the controller A is connected to a data input / output device 31 via an external communication interface. For communication between the CPU of the controller A and the data input / output device 31, industrial communication protocols such as EtherCAT, OPC UA, Modbus, EtherNet / IP (Internet Protocol) (registered trademark), and Profinet (registered trademark) are used.

[0018] Furthermore, controller 1B has one CPU and two IO units. The CPU and IO units of controller 1 are connected to each other via an internal communication interface. The CPU of controller 1B is connected to one CPU of controller 1A via an external communication interface. Here, the number of CPUs and IO units that controllers 1A and 1B have is an example, and there is no particular limit to this number.

[0019] Communication between the CPUs mounted on the controller 1A may be called "multi-CPU communication." Furthermore, communication between the CPU of the controller 1A and the CPU of the controller 1B may be called "inter-controller communication."

[0020] For example, the controller 1A periodically acquires data from the data input / output device 31 and the sensor 32. Then, the controller 1A transmits the acquired data to the industrial PC 21. The controller 1A also controls the actuator 33 using the acquired data and controls the actuator 37 by transmitting commands to the data input / output device 31. The controller 1A also transfers data to the controller 1B. Similarly, the controller 1B periodically acquires data from the sensor 34, transmits the data to the industrial PC 21, and controls the actuator 35. Here, the controller 1A and the controller 1B have similar functions, and therefore, in the following description, when there is no need to distinguish between them, they will be described as the controller 1.

[0021] (controller) Fig. 2 is a block diagram of a controller. The controller 1 in Fig. 2 corresponds to the controllers 1A and 1B in Fig. 1. Also, IO devices 15A to 15C correspond to the data input / output device 31 and the sensors 32, 34, and 36 in Fig. 1. The data input / output device 31 is an example of a "device that transmits data collected by a predetermined sensor." Also, the sensors 32, 34, and 36 are examples of "IO devices that input and output data."

[0022] Various communication protocols are used for communication among the IO devices 15A to 15C. Some or all of the communication protocols used by the IO devices 15A to 15C may be the same, or different communication protocols may be used by each of the IO devices 15A to 15C.

[0023] 1, the controller 1 includes application execution units 11A and 11B, a tag management unit 12, a data storage unit 13, and data update units 14A to 14C. The data storage unit 13 is a shared memory that temporarily stores the data received from the IO devices 15A to 15C.

[0024] The data update unit 14A is connected to the IO device 15A via an external communication interface. The data update unit 14B is connected to the IO device 15B via an external communication interface. The data update unit 14C is connected to the IO device 15C via an external communication interface.

[0025] The data update units 14A to 14C communicate using the communication protocols used by the IO devices 15A to 15C connected to them, respectively. The communication protocols used by the data update units 14A to 14C to communicate with the corresponding IO devices 15A to 15C may include different communication protocols.

[0026] The data updating units 14A to 14C periodically acquire data from the connected IO devices 15A to 15C using the respective communication protocols. Here, the data acquisition periods of the data updating units 14A to 14C are independent of each other. That is, the data updating units 14A to 14C acquire data at independent periods for each of the data updating units 14A to 14C, which are external devices. Here, periodic data acquisition is an example, and for example, if the IO devices 15A to 15C are devices connected to an Ethernet such as EtherNet / IP, the data updating units 14A to 14C may acquire data when an acquisition command is received.

[0027] Furthermore, when acquiring data, the data updating units 14A to 14C also acquire a timestamp indicating the acquisition time. Then, the data updating units 14A to 14C add the timestamp to the acquired data and store it as device data 130A to 130C in the data storage unit 13, which is a shared memory. The data updating units 14A to 14C overwrite the device data 130A to 130C every period and store it.

[0028] In this case, the data updating units 14A to 14C store the data obtained from the IO devices 15A to 15C, respectively, in different areas of the data storage unit 13, which is a shared memory. Specifically, the data updating unit 14A stores the device data 130A obtained from the IO device 15A in an area of ​​the data storage unit 13 allocated to the IO device 15A. For example, the device data 130A includes data A0 and A1 to which a timestamp is added. Furthermore, the data updating unit 14B stores the device data 130B obtained from the IO device 15B in an area of ​​the data storage unit 13 allocated to the IO device 15B. For example, the device data 130B includes data B0 and B1 to which a timestamp is added. Furthermore, the data updating unit 14C stores the device data 130C obtained from the IO device 15C in an area of ​​the data storage unit 13 allocated to the IO device 15C. For example, the device data 130C includes data C0, C1, and C2 to which a timestamp is added.

[0029] That is, the data storage unit 13 divides the storage area it holds into each of the IO devices 15A to 15C, which are external devices, and stores data transmitted from different external devices in each of the divided areas.

[0030] The data updating units 14A to 14C store the device data 130A to 130C in the same data format in the data storage unit 13. This simplifies the structure when accessing data, and absorbs the influence when the IO devices 15A to 15C are changed.

[0031] In this way, the data update units 14A to 14C each correspond to one of the IO devices 15A to 15C, which are external devices, without overlapping with each other. The data update units 14A to 14C periodically acquire data held by the corresponding external device using a communication method used by the corresponding external device, and use the acquired data to update the data of the corresponding external device held in the data storage unit 13. The data update units 14A to 14C also associate the acquired data with an acquisition date and time and store it in the data storage unit 13.

[0032] The tag management unit 12 holds a tag definition 120. The tag definition 120 holds tag names specified by a user. A tag name is information for identifying a tag used to access the device data 130A to 130C. For example, the tag definition 120 holds tag names T1 to T4. Furthermore, the tag definition 120 holds information on the correspondence between each tag name and the data included in the device data 130A to 130C linked to that tag name. For example, the tag definition 120 can use a combination of information on the IO devices 15A to 15C and the type of data as information for identifying the device data 130A to 130C. In FIG. 2, lines connecting each tag name held in the tag definition 120 to the data held in the device data 130A to 130C represent the correspondence. That is, the tag definition 120 in FIG. 2 actually includes tag names and information linking each tag name to the data held in the device data 130A to 130C. For example, the tag definition 120 may be a correspondence table that associates tag names with data held by the device data 130A to 130C.

[0033] 2, the tag definition 120 associates the tag name T1 with the data A0 included in the device data 130A, and associates the tag name T2 with the data A0 included in the device data 130A. In this way, the tag definition 120 can associate different tag names for each piece of device data 130A acquired from the same IO device 15A.

[0034] Furthermore, the tag definition 120 associates the tag name T3 with the data B0 included in the device data 130B. In this manner, the tag definition 120 can associate different tag names with the device data 130A and the device data 130B acquired from the different IO devices 15A and 15B, respectively.

[0035] Furthermore, the tag definition 120 associates the tag name T4 with the data C0 and C1 included in the device data 130C. In this way, the tag definition 120 can associate the same tag name T4 with different data included in the device data 130C.

[0036] By linking multiple pieces of data to a single tag, such as tag name T4, it is possible to group data by application or function. This reduces the amount of code while improving code readability. An example of a data grouping is explained below. For example, the tag name is "RIGHT_ARM," which means "a collection of control data for the robot's right arm." RIGHT_ARM is then linked to data #1 indicating the measured value of motor M1, data #2 indicating the output of motor M1, data #3 indicating the measured value of motor M2, data #4 indicating the output of motor M2, and data #5 indicating the measured ambient temperature. This is a single group of data, and it can be managed collectively.

[0037] When the tag management unit 12 receives a data access request specifying a tag name from the application execution unit 11A or 11B, the tag management unit 12 accesses the data held by the device data 130A to 130C linked to the tag name. Here, for example, if the tag definition 120 is a correspondence table, the tag management unit 12 can identify and access the data held by the device data 130A to 130C specified in the correspondence table corresponding to the specified tag name.

[0038] The application execution unit 11A runs an IEC61131-3 application by executing a program 111A. The program 111A is written in, for example, the IEC61131-3 programming language. The IEC61131-3 programming language defines LD (Ladder Diagram), FBD (Function Block Diagram), SFC (Sequential Function Chart), IL (Instruction List), and ST (Structured Text). The program 111A uses a shared library 112A to access device data 130A to 130C acquired from the IO devices 15A to 15C.

[0039] The application execution unit 11B runs a C / C++ application by executing a program 111B. The program 111B is written in, for example, the C / C++ programming language. The program 111B uses a shared library 112B to access the device data 130A to 130C acquired from the IO devices 15A to 15C.

[0040] The executed program is made to access data stored in the data storage unit and execute a predetermined process. Access to device data 130A to 130C by program 111A or 111B will be described below. Since the data access functions of programs 111A and 111B are similar, programs 111A and 111B will not be distinguished from each other and will be described as "program 111." Shared libraries 112A and 113B will also be referred to as "shared library 112" without distinction.

[0041] The program 111 accesses the device data 130A-130C using tags represented by tag names T1-T4. Specifically, the program 111 describes the process of accessing the device data 130A-130C using tag names, which are identification information of individual tags, definition names of data types, and an API (Application Programming Interface) for accessing the tag definition 120. During operation, the program 111 uses the API to call the function of the shared library 112 for accessing data associated with the tag name corresponding to the target of the access request.

[0042] Thereafter, program 111 uses the function of shared library 112 to access data stored in data storage unit 13 that is associated with the tag name specified as the access target via tag definition 120. For example, if the tag corresponding to the target of the access request is tag name T1, program 111 calls the function of shared library 112 using the API to access data A0 of device data 130A that is associated with tag name T1 via tag definition 120. In this case, if the process to be executed by accessing the data is data acquisition, program 111 acquires and stores a timestamp along with data A0. Program 111 can process data A0 in chronological order using the timestamp.

[0043] In this way, even if the program 111A and the program 111B are written in different programming languages, they can access the device data 130A to 130C using the same tag. Furthermore, by storing a timestamp along with the data, it becomes possible to perform data analysis taking into account the time series. Furthermore, the I / O devices 150A to 150C can be controlled using data with a consistent time series, improving controllability.

[0044] The application execution units 11A and 11B are examples of "program execution units." The application execution units 11A and 11B execute programs using data stored in the data storage unit 13. More specifically, the application execution units 11A and 11B cause the executed programs 111A and 111B to access data stored in the data storage unit 13 and execute predetermined processing. Examples of predetermined processing include reading data and controlling an actuator, and processing acquired data and then writing the data. The application execution units 11A and 11B also cause the executed programs 111A and 111B to access data stored in the data storage unit 13 and the acquisition date and time of the data and execute predetermined processing. Furthermore, the application execution units 11A and 11B cause the executed programs 111A and 111B to perform data analysis according to a time series based on the acquisition date and time of the data.

[0045] Here, a case where there is a change in the association between the tag name and the data included in the device data 130A to 130C will be described. Fig. 3 is a diagram showing a state where there is a change in the association between the tag name and the device data. Here, a case where the data associated with tag name T3 has been changed from data B0 to data B1 will be described.

[0046] When this change is made, in tag definition 120, information 121 linking tag name T3 to data B0 is changed to information 122 linking tag name T3 to data C2. In this case, programs 111A and 111B can access the changed data C2 by specifying tag name T3, without making any changes to application execution units 11A and 11B. In this way, even if the linkage is changed, application execution units 11A and 11B and programs 111A and 111B contained therein can continue to access the changed data without being changed.

[0047] (Device data collection and data acquisition flow) 4 is a sequence diagram of the process of collecting data held by the IO devices and the process of acquiring data by a program. Next, with reference to FIG. 4, the flow of the process of collecting data held by the IO devices 15A to 15C by the data update units 14A to 14C of the controller 1 according to this embodiment and the process of acquiring data by the program 111A or 111B will be described. Here, the process of collecting device data 130A held by the IO device 15A by the data update unit 14A and the process of acquiring data A0 of the IO device 15A by the program 111A will be described as an example.

[0048] The data updating unit 14A periodically collects data from the IO device 15A and obtains the results of the data collection. Then, the data updating unit 14A stores device data 130A, which is data acquired from the IO device 15A, in the data storage unit 13 (steps S101 to S103).

[0049] The IO device 15A receives periodic data collection from the data updating unit 14A and outputs the data to the data updating unit 14A (steps S111 to S113).

[0050] The data storage unit 13 stores the device data 130A periodically sent from the data update unit 14A in an overwrite format (step S140).

[0051] The program 111A acquires data by the tag name T1 from the tag management unit 12 at a timing required for the processing it executes, independent of the periodic data collection by the data update unit 14A. This timing does not need to be periodic. The program 111A then acquires the acquisition result for the acquisition of data by the tag name T1 from the tag management unit 12 (steps S121 to S123).

[0052] Upon receiving a request from the program 111A to acquire data with the tag name T1, the tag management unit 12 outputs the data A0 linked to the tag name T1 to the program 111A (steps S131 to S133).

[0053] The data storage unit 13 outputs the data A0 in response to a request from the tag management unit 12 (step S140).

[0054] (Program Development) The following describes the development of programs 111A and 111B and the generation of tag definitions 120. Figure 5 is a block diagram illustrating a system for program development and tag definition generation.

[0055] 5 is a computer that develops the programs 111A and 111B and generates the tag definitions 120. The development computer 4 may be, for example, a personal computer.

[0056] The development computer 4 has a development environment 41A for the program 111A and a development environment 41B for the program 111B. The development computer 4 also has a development setting unit 40 that creates the programs 111A and 111B and the tag definition 120 using the development environments 41A and 41B.

[0057] Fig. 6 is a diagram showing a GUI (Graphical User Interface) screen used to generate tag definitions. A user defines a tag using a GUI screen 200 shown in Fig. 6. The GUI screen 200 has items such as a data tag 201, a tag data type 202, an output 203, a device 204, a device data type 205, a direction 206, and a comment 207. The comment 207 can be used as a memo when defining the tag.

[0058] The data tag 201 indicates a tag name. The tag name used in the data tag 201 can be freely set by the user. The tag data type 202 is a data type of data to which the tag name indicated by the data tag 201 is assigned. The tag name of the data tag 201 may be associated with a plurality of different tag data types 202, devices 204, and device data types 205. Conversely, the same tag data type 202, devices 204, and device data types 205 may be associated with a plurality of different tag names of the data tag 201.

[0059] Output 203 is a tag (specifically, a tag registered in data area definition 411A or 411B) that is referenced in the development of program 111A or 111B, respectively, and is also an item for selecting a tag to be used in shared library 112A or 112B. After defining various tags on GUI screen 200, the user can use the items of output 203 to select a tag to be used in programming development from the defined tags.

[0060] The device 204 indicates the IO devices 15A to 15C that are the source of data associated with the tag name defined in the data tag 201. Here, specific identification information of the connected equipment is defined in the device 204. In this embodiment, the IO devices 15A to 15C are external devices to the controller 1, but it is also possible to specify internal devices mounted on the controller 1. The device data type is the data type of data handled by the IO devices 15A to 15C.

[0061] Direction 206 is the direction in which data travels for each of IO devices 15A to 15C, where IN indicates data input from the outside and is read-only, and OUT indicates data output to the outside and is readable and writable.

[0062] Continuing the explanation, returning to Fig. 5, the development setting unit 40 sets a data area for storing the device data 130A to 130C in the data storage unit 13. When setting the data area, the development setting unit 40 defines the device data 130A to 130C according to their intended use.

[0063] Next, the development setting unit 40 acquires the definition set on the GUI screen 200. Here, the development setting unit 40 can freely select and access either of the application execution units 11A and 11B and the development environments 41A and 41B.

[0064] The development setting unit 40 generates a data area definition 411A for IEC 61131-3 environment development in the development environment 41A according to the set definition. The development setting unit 40 also generates a shared library 112A for an IEC 61131-3 application according to the set definition. Similarly, the development setting unit 40 generates a data area definition 411B for a C / C++ development environment in the development environment 41B according to the set definition. The development setting unit 40 also generates a shared library 112B for a program 111B that runs a C / C++ application according to the set definition.

[0065] The development setting unit 40 creates and builds the program 111A by having the development environment 41A refer to the data area definition 411A, thereby generating a program execution file for the IEC61131-3 application.

[0066] Furthermore, the development setting unit 40 creates and builds the program 111B by having the development environment 41B refer to the data area definition 411B, thereby generating a program execution file for the program 111B that runs the C / C++ application.

[0067] The development setting unit 40 downloads to the controller 1 a program execution file and a shared library 112A for a program 111A that runs an IEC61131-3 application. The development setting unit 40 also downloads to the controller 1 a program execution file and a shared library 112B for a program 111B that runs a C / C++ application.

[0068] The following process is executed in the controller 1. The application execution unit 11A starts the IEC61131-3 application. When the program 111A of the IEC61131-3 application starts to execute, the shared library 112A is linked to the program 111A, the tag management unit 12 stores tag names, and the tag names are associated with the device data 130A to 130C. As a result, the tag definition 120 is generated.

[0069] Similarly, the application execution unit 11B starts the C / C++ application. When the program 111B of the C / C++ application starts to execute, the shared library 112B is linked to the program 111B, and the tag names in the tag definition 120 of the tag management unit 12 are associated with the data of the device data 130A to 130C.

[0070] Thereafter, the program 111A accesses the device data 130A to 130C using the tag name and the shared library 112A, and the program 111B accesses the device data 130A to 130C using the tag name and the shared library 112B.

[0071] When resetting the tag definition 120, the development setting unit 40 performs the following processing. The development setting unit 40 sets the data area in the data storage unit 13 again. The development setting unit 40 also acquires the definition newly set on the GUI screen 200, and regenerates the data area definition 411A and shared library 112A, as well as the data area definition 411B and shared library 112B, in accordance with the new definition. Thereafter, the development setting unit 40 downloads the shared libraries 112A and 112B to the controller 1.

[0072] When the programs 111A and 111B start executing, the tag definition 120 updates the association between the tag name in the tag definition 120 of the tag manager 12 and the device data 130A to 130C based on the shared libraries 112A and 112B.

[0073] 7 is a flowchart of the program development and tag definition generation process. Next, the flow of the program development and tag definition generation process 120 will be described with reference to FIG.

[0074] The development setting unit 40 sets a data area in the data storage unit 13 for storing the device data 130A to 130C (step S1).

[0075] Next, the development setting unit 40 acquires the definition set on the GUI screen 200. Then, the development setting unit 40 generates a shared library 112A for the IEC61131-3 application in accordance with the set definition. Similarly, the development setting unit 40 generates a shared library 112B for the program 111A that runs the C / C++ application, and data area definitions 411A and 411B in accordance with the set definition (step S2).

[0076] Next, the development setting unit 40 determines whether or not the tag definition 120 is to be reset based on the definition set on the GUI screen 200 (step S3).

[0077] If the tag definition 120 is not to be reset (step S3: No), the development setting unit 40 references the data area definition 411A and creates the program 111A in the development environment 41A. Also, the development setting unit 40 references the data area definition 411B and creates the program 111B in the development environment 41B (step S4).

[0078] Then, the development setting unit 40 downloads the program execution files of the programs 111A and 111B and the shared libraries 112A and 112B to the controller 1 (step S5). After that, the process of developing the program and generating the tag definition 120 proceeds to step S7.

[0079] On the other hand, if the tag definition is to be reset (step S3: Yes), the development setting unit 40 downloads the shared libraries 112A and 112B to the controller 1 (step S6). After that, the program development and tag definition 120 generation process proceeds to step S7.

[0080] The application execution unit 11A of the controller 1 starts the application and executes the program 111A. Also, the application execution unit 11B of the controller 1 starts the application and executes the program 111B (step S7).

[0081] A link to shared library 112A is created for program 111A. Also, a link to shared library 112B is created for program 111B. Furthermore, tag definition 120 is generated or updated based on shared libraries 112A and 112B (step S8).

[0082] Thereafter, the program 111A uses the tag and shared library 112A to access the data included in the device data 130A to 130C. Similarly, the program 111B uses the tag and shared library 112B to access the data included in the device data 130A to 130C (step S9).

[0083] In this embodiment, data acquired by sensors has been described as an example of data from the IO devices 15A to 15B, but other data such as the following can also be used. For example, AI (Analog Input) / AO (Analog Output) data and DI (Digital Input) / DO (Digital Output) data can be used. Also, for example, data acquired via EtherCAT, OPC UA, Modbus, EtherNet / IP, and Profinet can be used. In addition, data from inter-controller communication and data from multi-CPU communication can also be used.

[0084] Although C / C++ and IEC61131-3 are given as examples of programming languages ​​for the programs 111A and 111B, usable programming languages ​​are not limited to these. For example, C#, ladder programming language, Python or other scripting languages ​​may also be used.

[0085] Furthermore, if the functions of development setting unit 40 are incorporated into controller 1 rather than development computer 4, and settings can be made from a web browser or the like via a network, development computer 4 can be omitted if development computer 4 is configured not to create programs for development environments 41A and 41B. However, since it is only necessary to prepare an information terminal device connected to the network, settings can also be made from information terminal devices such as smartphones and tablets, rather than personal computers.

[0086] (effect) As described above, the controller 1 according to this embodiment periodically collects data from each of the devices 15A to 15C and temporarily stores the data in a unified data format together with a timestamp inside the controller 1. This allows data to be collected at high speed even from the IO devices 15A to 15C that use different protocols. This makes it possible to shorten the processing time using the data from the IO devices 15A to 15C.

[0087] Furthermore, the unified data format simplifies the structure when accessing data and absorbs the impact of changes to the devices 15A to 15C. It also becomes possible to handle data from the IO devices 15A to 15C and timestamps indicating the time when the data was acquired. This allows the programs 111A and 111B to perform data analysis based on time series. Furthermore, the IO devices 15A to 15C can be controlled using data with a consistent time series, improving controllability.

[0088] Furthermore, in the controller 1 according to this embodiment, the programs 111A and 111B access data in the IO devices 15A to 15C using unified tags. This reduces application development time. Conventionally, when the IO devices 15A to 15C associated with the data are changed, the programs 111A and 111B must be rebuilt and the extent of the impact must be reassessed. In contrast, in the controller 1 according to this embodiment, changes to the IO devices 15A to 15C do not affect the application code, so rebuilding the programs 111A and 111B and reassessing the extent of the impact are not necessary. For example, even if the IO devices 15A to 15C are changed after product release due to performance improvements, changes to the IO devices 15A to 15C to accommodate revisions or abolitions, or changes to the IO devices 15A to 15C due to changes in system requirements, all that is required is to change the tag definition 120 and evaluate the entire system. This reduces development time when changing data specifications. Furthermore, in the controller 1 according to this embodiment, even if the programs 111A and 111B are written in different programming languages, there is no duplication of data management between the multiple languages. This eliminates the need to design and implement the programs 111A and 111B with the duplication in mind, and also eliminates the need to deal with changes in specifications for each language, thereby shortening the overall development time.

[0089] Furthermore, the programming language can be easily expanded. For example, since the programming language desired for development varies from user to user, it is easy to imagine a case where a language other than the one considered at the time of release of the controller 1 is desired. In this regard, in the controller 1 according to this embodiment, the programming language and tag definition 120 are independent. Therefore, even if a programming language is added in the future, all data can be accessed simply by preparing an interface using tags. In this way, it is possible to omit the design and implementation of the device access section, data management section, and coordination section with other languages ​​for each programming language. This makes it possible to shorten the application development time.

[0090] In addition, in the past, device allocation work had to be performed manually in the development environment of each programming language. In contrast, in the development environments 41A and 41B provided by the development computer 4 according to this embodiment, the programs 111A and 111B can be created using the set definition content, thereby improving development efficiency. Furthermore, in the development environments 41A and 41B provided by the development computer 4 according to this embodiment, the definition content of the data area can be created by assigning any name as a data tag, which leads to improved visibility and allows the programs 111A and 111B to be developed efficiently. Furthermore, the tag names and associations used in the tag definition 120 can be selected and used for the IO devices 15A to 15C required for the application. This makes it possible to reduce operational errors during program creation by hiding unnecessary IO devices 15A to 15C.

[0091] Furthermore, when changing the IO devices 15A-15C that output data associated with the tag definition 120, conventionally, it was necessary to redo the data settings in the program, modify the program, build it, and then download it to the controller. In contrast, in the development computer 4 according to this embodiment, the changes are completed by downloading the shared libraries 112A and 112B regenerated by the development setting unit 40, thereby reducing the amount of work involved in development. Furthermore, because the application's program execution file can be used as is, it is possible to prevent degradation due to the re-creation of the programs 111A and 111B and shorten the verification work. Furthermore, since the re-creation of the programs 111A and 111B is unnecessary, the setting change work can be performed even on a computer that does not have the development environments 41A and 41B for the programs 111A and 111B, thereby reducing equipment costs.

[0092] (system) The information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified.

[0093] Furthermore, the components of each device shown in the figure are functional concepts and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown. In other words, all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0094] Furthermore, each processing function performed by each device can be realized, in whole or in part, by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.

[0095] [Hardware] Next, an example of the hardware configuration of the controller 1 will be described. For example, the CPUs of the controllers 1A and 1B in Fig. 1 read and execute various programs stored in memory. As a result, the CPUs of the controllers 1A and 1B realize the functions of the application execution units 11A and 11B, the tag management unit 12, and the data update units 14A to 14C. In this way, the controller 1 operates as an information processing device that executes various processing methods by reading and executing programs.

[0096] Next, an example of the hardware configuration of the development computer 4 will be described. Fig. 8 is a diagram showing the hardware configuration of the development computer. As shown in Fig. 8, the development computer 4 has a processor 91, memory 92, a hard disk 93, an input device 94, a display device 95, and a network interface 96. The processor 91 is connected to the memory 92, the hard disk 93, the input device 94, the display device 95, and the network interface 96 via a bus.

[0097] The network interface 96 is a network interface card or the like, and is used for communication with other information processing devices. For example, the network interface 96 relays communication between the controller 1 and the processor 91.

[0098] The input device 94 is a keyboard, a mouse, etc. The display device 95 is a monitor, a display, etc. The user refers to a GUI screen 200 displayed on the display device 95 and uses the input device 94 to input tag definitions, etc.

[0099] The hard disk 93 is an auxiliary storage device and stores various programs including a program for realizing the functions of the development setting unit 40.

[0100] The processor 91 reads out various programs stored in the hard disk 93, loads them into the memory 92, and executes them. In this way, the processor 91 realizes the functions of the development setting unit 40.

[0101] In this way, the development computer 4 operates as an information processing device that executes various processing methods by reading and executing the program. The development computer 4 can also realize the same functions as those of the embodiments by reading the program from a recording medium using a media reader and executing the read program. Note that the program referred to here is not limited to being executed by the development computer 4. For example, the present invention can also be applied in the same way to cases where another computer or server executes the program, or where these execute the program in cooperation with each other.

[0102] This program can be distributed via a network such as the Internet. In addition, this program can be recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, a magneto-optical disk (MO), or a digital versatile disk (DVD), and can be executed by being read from the recording medium by a computer.

[0103] Some examples of combinations of the disclosed technical features are set out below.

[0104] (1) a data storage unit that temporarily stores data received from a plurality of external devices; a plurality of data update units, each corresponding to one of the external devices without overlapping with another, each acquiring data held by the corresponding external device using a communication method used by the corresponding external device, and updating data of the corresponding external device held in the data storage unit with the acquired data; a program execution unit that executes a program using the data stored in the data storage unit; A controller comprising: (2) The controller according to (1), wherein the program execution unit causes the executed program to access data stored in the data storage unit and execute a predetermined process. (3) The controller according to (2) or (3), wherein the data update unit associates the acquired data with an acquisition date and time and stores the data in the data storage unit. (4) The controller according to (3), wherein the program execution unit causes the executed program to access the data stored in the data storage unit and the acquisition date and time of the data to execute a predetermined process. (5) The controller according to (4), wherein the program execution unit causes the executed program to perform data analysis according to time series based on the date and time of data acquisition. (6) The controller according to any one of (1) to (5), wherein the plurality of external devices includes a device that transmits data collected by a predetermined sensor. (7) The controller according to any one of (1) to (6), wherein the plurality of external devices include an IO (Input Output) device that inputs and outputs data. (8) The controller according to any one of (1) to (7), wherein the plurality of external devices include another controller. (9) The controller described in any one of (1) to (8) is characterized in that the data storage unit divides the memory area it holds for each of the external devices and stores data sent from different external devices in each of the divided areas. (10) The controller according to any one of (1) to (9), wherein the data update unit acquires data for each of the external devices at an independent cycle. (11) The controller according to any one of (1) to (10), wherein the plurality of data update units each include a different communication protocol among the communication protocols used for communication with the corresponding external device. [Explanation of symbols]

[0105] 1,1A,1B Controller 4 Development Computer 10A, 10B Control device 11A, 11B Application execution unit 12 Tag Management Section 13 Data storage unit 14A, 14B, 14C Data update section 15A, 15B, 15C IO devices 20 Upper Server 21 Industrial PC 22 Databases 32, 34, 36 Sensors 33, 35, 37 Actuator 40 Development Execution Department 41A, 41B development environment 100 Control System 111A, 111B Program 112A,112B shared library 120 tag definitions 130A, 130B, 130C device data 411A, 411B Data area definition

Claims

1. a data storage unit that temporarily stores data received from a plurality of external devices; a plurality of data update units, each corresponding to one of the external devices without overlapping with another, each acquiring data held by the corresponding external device using a communication method used by the corresponding external device, and updating data of the corresponding external device held in the data storage unit with the acquired data; a program execution unit that executes a program using the data stored in the data storage unit; A controller comprising:

2. 2. The controller according to claim 1, wherein the program execution unit causes the executed program to access the data stored in the data storage unit and execute a predetermined process.

3. 2. The controller according to claim 1, wherein the data update unit associates the acquired data with an acquisition date and time and stores the data in the data storage unit.

4. 4. The controller according to claim 3, wherein the program execution unit causes the executed program to access the data and the acquisition date and time of the data held in the data storage unit and execute a predetermined process.

5. 5. The controller according to claim 4, wherein the program execution unit causes the executed program to perform data analysis according to time series based on the acquisition date and time of the data.

6. The controller according to claim 1 , wherein the plurality of external devices includes a device that transmits data collected by a predetermined sensor.

7. 2. The controller according to claim 1, wherein the plurality of external devices include an IO (Input Output) device that inputs and outputs data.

8. The controller of claim 1 , wherein the plurality of external devices includes other controllers.

9. 2. The controller according to claim 1, wherein the data storage unit divides a storage area it holds for each of the external devices, and stores data transmitted from different external devices in each of the divided areas.

10. 2. The controller according to claim 1, wherein the data update unit acquires data for each of the external devices at an independent cycle.

11. 2. The controller according to claim 1, wherein the plurality of data update units each include a different communication protocol among the communication protocols used for communication with the corresponding external device.

Citation Information

Patent Citations

  • Industrial controller and data sharing method for industrial controller

    JP2018185772A

  • Symbol table generation method, method for communication with peripheral apparatus and programmable logic controller

    WO2013005350A1