Control program and controller

Abstract

Provided is a control program for controlling a controller comprising: data update units (14A-14C) that receive data from external devices; a data storage unit (13) that stores data transmitted from the external devices; and a computer. The control program causes the computer to execute a process in which: a processor is caused to execute a plurality of programs; a tag definition, which is information linking each piece of data stored by a data storage apparatus with a tag that is common to the plurality of programs, is retained; a request to access the data stored in the data storage unit (13), said request using a tag, is made for each program; and data corresponding to the tag included in the access request from each program is identified on the basis of the tag definition, and as a result each program is allowed to access the identified data stored in the data storage unit (13).

Description

Control Program and Controller

[0001] The present invention relates to a control program and a controller.

[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 the like based on the received information. Various programs run on the controller, and multiple control applications operate to control the IO devices, actuators, etc. The control applications perform control calculations using data read from the IO devices, for example, and output the calculation results to the actuators to perform 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. Furthermore, 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, the application must create methods for accessing actual IO devices and managing various data. In this case, 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.

[0007] JP 2018-185772 A International Publication No. 2013 / 005350

[0008] However, applications running on conventional controllers require rebuilding the program when data specifications change due to changes in the device or location of the data access destination. Rebuilding an application requires evaluation to confirm the modifications, even if they are minor. Furthermore, when multiple applications written in different programming languages ​​are installed, data management becomes redundant. This increases the number of modifications required when data specifications change, and further increases the development time required because of the need for design to avoid data conflicts. Therefore, it is difficult to reduce application development time with conventional controllers.

[0009] Furthermore, even if techniques for extracting variable names from a control program and accessing data using an address map file or creating a symbol table are used, changes to data specifications still require rebuilding the program and duplication of data management. Therefore, even with these techniques, it is difficult to reduce application development time.

[0010] One aspect of the present invention reduces application development time.

[0011] According to one aspect, a control program controls a controller having a receiver that receives data from an external device, a data storage device that stores each piece of data transmitted from the external device, and a computer. The control program executes a plurality of programs, holds tag definitions that are information that link each piece of data stored in the data storage device with a tag common to the plurality of programs, causes each program to make an access request to data stored in the data storage device using the tag, identifies data corresponding to the tag included in the access request from each program based on the tag definition, and causes the computer to execute a process of causing each program to access the identified data stored in the data storage device.

[0012] According to the present invention, the development time of an application can be reduced.

[0013] 1 is a block diagram of a control system according to an embodiment; FIG. 2 is a block diagram of a controller; FIG. 3 is a diagram showing a state when there is a change in the association between tag names and device data; FIG. 4 is a sequence diagram of a process for collecting data held by an IO device and acquiring data by a program; FIG. 5 is a block diagram showing a system for program development and generation of tag definitions; FIG. 6 is a diagram showing a GUI screen used for generating tag definitions; FIG. 7 is a flowchart of a process for program development and generation of tag definitions; FIG. 8 is a hardware configuration diagram of a development computer;

[0014] Hereinafter, an embodiment of a control program and a controller will be described with reference to the drawings. The same elements are denoted by the same reference numerals, and redundant descriptions will be omitted as appropriate. Furthermore, the respective embodiments can be combined as appropriate within a range that does not cause inconsistencies.

[0015] (Overall Configuration) 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 actuator 37.

[0016] The upper server 20 includes, for example, an industrial personal computer (PC) 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 the sensors 32, 34, and 36 and the actuators 33, 35, and 37 for the controller 1A or 1B.

[0017] The control devices 10A and 10B are connected to a host 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.

[0018] 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 communications such as EtherCAT, OPC UA, Modbus, EtherNet / IP (Internet Protocol) (registered trademark), and Profinet (registered trademark) are used.

[0019] 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 possessed by controllers 1A and 1B is an example, and there is no particular limit to this number.

[0020] 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."

[0021] For example, the controller 1A periodically acquires data from the data input / output device 31 and the sensor 32. The controller 1A then 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, unless a distinction is made between them, they will be referred to as the controller 1.

[0022] (Controller) Fig. 2 is a block diagram of the controller. The controller 1 in Fig. 2 corresponds to the controllers 1A and 1B in Fig. 1. Also, the IO devices 15A to 15C correspond to the data input / output device 31 and the sensors 32, 34, and 36 in Fig. 1.

[0023] 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 each may use a different communication protocol.

[0024] 1, the controller 1 has 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 data received from the IO devices 15A to 15C. The IO devices 15A to 15C are examples of external devices, and the data storage unit 13 is an example of a "data storage device."

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

[0026] The data update units 14A to 14C communicate using the communication protocols used by the IO devices 15A to 15C connected to them. The data update units 14A to 14C periodically acquire data from the IO devices 15A to 15C connected to them using their respective communication protocols. Here, the data acquisition periods of the data update units 14A to 14C are independent of each other. Here, periodic data acquisition is one example; for example, if the IO devices 15A to 15C are devices connected to an Ethernet such as EtherNet / IP, the data update units 14A to 14C may acquire data when an acquisition command is received.

[0027] When acquiring data, the data updating units 14A to 14C also acquire a timestamp indicating the time of acquisition. 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 and store the device data 130A to 130C every period.

[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 with timestamps 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 with timestamps 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 with timestamps added.

[0029] The data updating units 14A to 14C store the device data 130A to 130C in the data storage unit 13 in the same data format. This simplifies the structure when accessing data and absorbs the impact when the IO devices 15A to 15C are changed. These data updating units 14A to 14C are an example of a "receiver." The data updating units 14A to 14C store data for each type of external device in the data storage unit 13.

[0030] The tag management unit 12 holds tag definitions 120. The tag definitions 120 hold tag names specified by the user. A tag name is information for identifying a tag used to access the device data 130A-130C. For example, the tag definitions 120 hold tag names T1-T4. Furthermore, the tag definitions 120 hold information on the correspondence between each tag name and the data contained in the device data 130A-130C linked to it. For example, the tag definitions 120 can use a combination of information on the IO devices 15A-15C and the type of data as information for identifying the device data 130A-130C. In FIG. 2, the lines connecting each tag name held in the tag definition 120 to the data held in the device data 130A-130C represent the correspondence. In other words, the tag definitions 120 in FIG. 2 actually include tag names and information linking each tag name to the data held in the device data 130A-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.

[0031] In this way, the tag management unit 12 holds tag definitions 120, which are information that links each piece of data stored in the data storage unit 13 with a tag common to multiple programs. The tag management unit 12 also holds tag definitions, which are information that links a combination of an external device type and a data type with a tag.

[0032] 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.

[0033] The tag definition 120 also associates the tag name T3 with the data B0 included in the device data 130B. In this way, 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.

[0034] The tag definition 120 also links the tag name T4 to the data C0 and C1 included in the device data 130 C. In this way, the tag definition 120 can link the same tag name T4 to different data included in the device data 130 C. In this way, the tag management unit 12 may hold the tag definition 120, which is information that links multiple data to tags.

[0035] By linking multiple pieces of data to a single tag, such as tag name T4, it becomes possible to group data by application or function. This reduces the amount of code while improving code readability. An example of a data grouping will be described below. For example, the tag name is "RIGHT_ARM," which means "a collection of control data for the robot's right arm." 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 are linked to RIGHT_ARM. This is a single group of data, and it can be managed collectively.

[0036] In this way, the tag management unit 12 may hold tag definitions 120, which are information that links tags with data organized in units of applications run by the programs 111A and 111B. The tag management unit 12 may also hold tag definitions 120, which are information that links tags with data organized in units of functions.

[0037] When the tag management unit 12 receives a data access request specifying a tag name from the application execution unit 11A or 11B, it accesses the data held by the device data 130A to 130C linked to that 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 IEC 61131-3 application by executing a program 111A. The program 111A is created in, for example, the IEC 61131-3 programming language. The IEC 61131-3 programming language defines a ladder diagram (LD), a function block diagram (FBD), a sequential function chart (SFC), an instruction list (IL), and structured text (ST). 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 device data 130A-130C obtained from the IO devices 15A-15C.

[0040] The following describes access to device data 130A to 130C by program 111A or 111B. Because 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 referred to 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 to 130C using tags represented by tag names T1 to T4. Specifically, the program 111 describes the process of accessing the device data 130A to 130C using tag names, which are identification information for individual tags, data type definition names, 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, the program 111 uses the function of the shared library 112 to access data stored in the data storage unit 13 that is associated with the tag name specified as the access target via the tag definition 120. For example, if the tag corresponding to the target of the access request is tag name T1, the program 111 calls the function of the shared library 112 using the API to access data A0 of the device data 130A that is associated with tag name T1 via the tag definition 120. In this case, if the process to be executed by accessing the data is data acquisition, the program 111 acquires and stores a timestamp along with the data A0. The program 111 can process the data A0 in chronological order using the timestamp.

[0043] In this way, even if the programs 111A and 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 IO devices 150A to 150C can be controlled using data with a consistent time series, improving controllability.

[0044] In this manner, the controller 1 according to this embodiment causes each of the programs 111A and 111B to make a request to access data stored in the data storage unit 13 using a tag. Based on the tag definition 120, the controller 1 identifies data corresponding to the tag included in the access request from each of the programs 111A and 111B, and causes each of the programs 111A and 111B to access the identified data stored in the data storage unit 13. The controller 1 also causes each of the programs 111A and 111B to execute a predetermined process using the identified data. The predetermined process includes a process of acquiring data and controlling an actuator according to the acquired data, a process of processing and writing the acquired data, and a process in chronological order. The controller 1 also causes each of the programs 111A and 111B to make a request to access data collected by a predetermined sensor.

[0045] Here, we will explain what happens when there is a change in the association between tag names and data included in device data 130A to 130C. Figure 3 is a diagram showing the state when there is a change in the association between tag names and device data. Here, we will explain the case where the data associated with tag name T3 has changed from data B0 to data B1.

[0046] When this change is made, information 121 linking tag name T3 to data B0 in tag definition 120 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 linking is changed, application execution units 11A and 11B and the programs 111A and 111B contained therein can continue to access the changed data without being changed.

[0047] In this way, the controller 1 according to this embodiment can update the association between the data and the tag included in the tag definition 120 independently of the program.

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

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

[0050] The IO device 15A periodically collects data from the data updating unit 14A and outputs the data to the data updating unit 14A (steps S111 to S113).

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

[0052] 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 obtains the acquisition results for the data acquisition by the tag name T1 from the tag management unit 12 (steps S121 to S123).

[0053] 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 associated with the tag name T1 to the program 111A (steps S131 to S133).

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

[0055] (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 showing a system for program development and tag definition generation.

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

[0057] 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.

[0058] 6 is a diagram showing a GUI (Graphical User Interface) screen used to generate tag definitions. A user defines tags 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 a tag.

[0059] 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.

[0060] 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, a user can use the items of output 203 to select a tag to be used in programming development from the defined tags.

[0061] 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 the data handled by the IO devices 15A to 15C.

[0062] The direction 206 is the direction in which data travels for each of the 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.

[0063] 5, the description will continue. 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.

[0064] 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 the application execution units 11A and 11B or the development environments 41A and 41B.

[0065] 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.

[0066] The development setting unit 40 creates and builds a program 111A by referencing the data area definition 411A using the development environment 41A, thereby generating a program execution file for an IEC 61131-3 application.

[0067] 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.

[0068] 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 IEC 61131-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.

[0069] The following process is executed in the controller 1. The application execution unit 11A starts an IEC 61131-3 application. When the program 111A of the IEC 61131-3 application starts execution, 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.

[0070] Similarly, the application execution unit 11B starts a C / C++ application. When the C / C++ application program 111B starts execution, 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 device data 130A to 130C.

[0071] 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.

[0072] When resetting the tag definition 120, the development setting unit 40 performs the following process. The development setting unit 40 resets the data area in the data storage unit 13. 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. The development setting unit 40 then downloads the shared libraries 112A and 112B to the controller 1.

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

[0074] 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.

[0075] 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).

[0076] 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 IEC 61131-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).

[0077] 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).

[0078] If the tag definition 120 is not being reconfigured (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).

[0079] 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 program development and tag definition 120 generation process proceeds to step S7.

[0080] 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). Thereafter, the program development and tag definition 120 generation process proceeds to step S7.

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

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

[0083] 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).

[0084] 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 communications and data from multi-CPU communications can also be used.

[0085] 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.

[0086] 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, then if development computer 4 is configured not to create programs for development environments 41A and 41B, development computer 4 can be omitted. However, since it is only necessary to prepare an information terminal device connected to the network, settings can be made from information terminal devices such as smartphones and tablets instead of personal computers.

[0087] (Effects) As described above, the controller 1 according to this embodiment periodically collects data from each of the IO 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 IO devices 15A to 15C that use different protocols. This makes it possible to shorten the processing time using data from the IO devices 15A to 15C.

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

[0089] 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 are made to accommodate revisions or abolitions, or changes to the IO devices 15A to 15C are made 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 address each language when a specification change occurs, thereby shortening the overall development time.

[0090] 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 the 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.

[0091] Additionally, in the past, device assignment work had to be performed manually in the development environment for each programming language. In contrast, the development environments 41A and 41B provided by the development computer 4 according to this embodiment allow programs 111A and 111B to be created using the configured definitions, improving development efficiency. Furthermore, in the development environments 41A and 41B provided by the development computer 4 according to this embodiment, data area definitions can be created with arbitrary names as data tags, leading to improved visibility and enabling the efficient development of programs 111A and 111B. Furthermore, the tag names and associations used in the tag definition 120 can be selected and used for the IO devices 15A-15C required for the application. This allows unnecessary IO devices 15A-15C to be hidden, reducing operational errors during program creation.

[0092] 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, with the development computer 4 according to this embodiment, the change is completed by downloading the shared libraries 112A and 112B regenerated by the development setting unit 40, thereby reducing the amount of work required for 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 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.

[0093] (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 as desired unless otherwise specified.

[0094] Furthermore, the components of each device shown in the figure are conceptual functional components 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 the devices can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.

[0095] 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.

[0096] [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.

[0097] 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.

[0098] 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.

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

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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 read out from the recording medium and executed by a computer.

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

[0105] (1) A control program for controlling a controller having a receiver that receives data from an external device, a data storage device that stores each piece of data transmitted from the external device, and a computer, the control program causing the computer to execute the following processes: execute a plurality of programs; retain tag definitions that are information linking each piece of data stored in the data storage device with a tag common to the plurality of programs; cause each program to make an access request to data stored in the data storage device using the tag; identify data corresponding to the tag included in the access request from each program based on the tag definitions; and cause each program to access the identified data stored in the data storage device. (2) The control program described in (1), wherein the process of executing the plurality of programs includes a process of executing the plurality of programs written in a language different from that of the data stored in the data storage device. (3) The control program described in (1) or (2), further causing the computer to execute a process of storing data for each type of external device in the data storage device, and wherein the process of retaining the tag definitions includes a process of retaining the tag definitions that are information linking a combination of the type of external device and the type of data with the tag. (4) The control program according to any one of (1) to (3), wherein the process of retaining the tag definition includes a process of retaining the tag definition, which is information linking a plurality of data with the tag. (5) The control program according to (4), wherein the process of retaining the tag definition includes a process of retaining the tag definition, which is information linking the tag with data organized in units of applications run by each program. (6) The control program according to (4), wherein the process of retaining the tag definition includes a process of retaining the tag definition, which is information linking the tag with data organized in units of functions.(7) The control program according to any one of (1) to (6), further causing the computer to execute a process of updating the association between the data included in the tag definition and the tag, independent of the program. (8) The control program according to any one of (1) to (7), further causing the computer to execute a process of causing each of the programs to execute a predetermined process using the identified data. (9) The control program according to any one of (1) to (8), further causing the process of making a data access request to include a process of making an access request to data collected by a predetermined sensor. (10) A controller comprising: a receiving unit that receives data from an external device; a data storage unit that holds each piece of data transmitted from the external device; a program execution unit that executes a plurality of programs that access data stored in the data storage unit using a tag common to the programs linked to each piece of data; and a tag management unit that holds a tag definition, which is information that links each piece of data held in the data storage unit with the tag, and based on the tag definition, identifies data corresponding to a tag included in an access request from each program executed by the program execution unit, and causes each program to access the identified data held in the data storage unit.

[0106] 1, 1A, 1B Controller 4 Development computer 10A, 10B Control device 11A, 11B Application execution unit 12 Tag management unit 13 Data storage unit 14A, 14B, 14C Data update unit 15A, 15B, 15C IO device 20 Upper server 21 Industrial PC 22 Database 32, 34, 36 Sensor 33, 35, 37 Actuator 40 Development setting unit 41A, 41B Development environment 100 Control system 111A, 111B Program 112A, 112B Shared library 120 Tag definition 130A, 130B, 130C Device data 411A, 411B Data area definition

Claims

1. A control program for controlling a controller having a receiver that receives data from an external device, a data storage device that stores each piece of data transmitted from the external device, and a computer, the control program causing the computer to execute the following processes: execute a plurality of programs; retain tag definitions that are information that link each piece of data stored in the data storage device with a tag common to the plurality of programs; have each program make an access request to data stored in the data storage device using the tag; identify data corresponding to the tag included in the access request from each program based on the tag definition, and have each program access the identified data stored in the data storage device.

2. The control program according to claim 1, characterized in that the process of executing the plurality of programs includes a process of executing the plurality of programs generated in languages ​​different from the data stored in the data storage device.

3. The control program according to claim 1, further comprising causing the computer to execute a process for storing data in the data storage device for each type of external device, and wherein the process for retaining the tag definition includes a process for retaining the tag definition, which is information linking the combination of the type of external device and the type of data to the tag.

4. The control program according to claim 1, wherein the process of storing the tag definition includes a process of storing the tag definition, which is information that links a plurality of data with the tag.

5. The control program described in claim 4, characterized in that the process of retaining the tag definition includes a process of retaining the tag definition, which is information that links the tag to data organized by application units run by each program.

6. The control program according to claim 4, characterized in that the process of storing the tag definition includes a process of storing the tag definition, which is information that links data organized by function with the tag.

7. The control program according to claim 1, further causing the computer to execute, independent of the program, a process of updating the association between the data included in the tag definition and the tag.

8. The control program according to claim 1, further causing the computer to execute a process for causing each of the programs to execute a predetermined process using the identified data.

9. The control program according to claim 1, wherein the process of making a data access request includes a process of making an access request to data collected by a predetermined sensor.

10. A controller comprising: a receiving unit that receives data from an external device; a data storage unit that holds each piece of data transmitted from the external device; a program execution unit that executes a plurality of programs that access data stored in the data storage unit using a tag common to the programs linked to each piece of data; and a tag management unit that holds tag definitions, which are information that link each piece of data held in the data storage unit with the tag, and based on the tag definitions, identifies data corresponding to tags included in access requests from each program executed by the program execution unit, and causes each program to access the identified data held in the data storage unit.

Images