controller

Abstract

A data storage unit (13) temporarily holds respective data received from a plurality of IO devices (15A to 15C). Data update units (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 unit (13). An application execution unit (11A) executes a program (111A) using the data stored in the data storage unit (13).

Description

controller

[0001] The present invention relates to 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 have dedicated communication programs for each IO device and main programs for processing data exchanged with the IO devices. As a result, it takes time 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.

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

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

[0012] 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;

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

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

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

[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 communications 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 possessed by controllers 1A and 1B 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. 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.

[0021] (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. Furthermore, the 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 specified sensor." Furthermore, 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 each may use a different communication protocol.

[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 data received from the IO devices 15A to 15C.

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

[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 update units 14A to 14C periodically acquire data from the connected IO devices 15A to 15C using their respective communication protocols. The data acquisition periods of the data update units 14A to 14C are independent of each other. That is, the data update units 14A to 14C acquire data from each of the external devices, that is, the data update units 14A to 14C, at independent periods. The periodic data acquisition is an 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 upon receiving an acquisition command.

[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] That is, the data storage unit 13 divides the storage area it holds into individual IO devices 15A to 15C, which are external devices, and stores data transmitted from different external devices in each divided area.

[0030] The data update 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 impact 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 external IO devices 15A to 15C without overlapping with any other. The data update units 14A to 14C periodically acquire data held by the corresponding external device using the 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 the acquisition date and time and store it in the data storage unit 13.

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

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

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

[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 executed program accesses data stored in the data storage unit 13 to execute a predetermined process. 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 be described here without distinction 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] 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, or processing acquired data and then writing the data. Furthermore, 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 the date and time the data was acquired, 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 date and time the data was acquired.

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

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

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

[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 obtains the acquisition results for the data acquisition 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 associated with 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 showing 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 can 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] 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.

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

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

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

[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 the application execution units 11A and 11B or 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 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.

[0066] Furthermore, the development setting unit 40 creates and builds the program 111B by referencing the data area definition 411B using the development environment 41B, 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 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.

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

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

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

[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 and the device data 130A to 130C in the tag management unit 12 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 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).

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

[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 program development and tag definition 120 generation process 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). Thereafter, 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. The application execution unit 11B of the controller 1 starts the application and executes the program 111B (step S7).

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

[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 communications and data from multi-CPU communications 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, 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.

[0086] (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.

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

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

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

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

[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, 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.

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

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

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

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

[0104] (1) A controller comprising: a data storage unit that temporarily stores data received from a plurality of external devices; a plurality of data update units that correspond to each external device without overlapping 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 of the corresponding external device 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. (2) The controller described in (1), wherein the program execution unit causes the executed program to access the data stored in the data storage unit and perform a predetermined process. (3) The controller described in (2) or (3), wherein the data update unit associates the acquired data with a date and time of acquisition and stores it in the data storage unit. (4) The controller described in (3), wherein the program execution unit causes the executed program to access the data stored in the data storage unit and the date and time of acquisition of the data and perform a predetermined process. (5) The controller described in (4), wherein the program execution unit causes the executed program to perform data analysis according to a 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 includes 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 includes another controller. (9) The controller according to any one of (1) to (8), 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) 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 period.(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.

[0105] 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 controller comprising: 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 specific 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.

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

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

4. The controller according to claim 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, and executes a predetermined process.

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 date and time of data acquisition.

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

7. The controller according to claim 1, wherein said plurality of external devices includes an IO (Input Output) device for inputting and outputting data.

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

9. The controller according to claim 1, wherein the data storage unit divides the 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. The controller according to claim 1, wherein said data update unit acquires data for each of said external devices at an independent cycle.

11. 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.

Images