Control program and controller
The control program manages data access through unified tags, reducing development time and eliminating redundant management by linking data across multiple programming languages, addressing the challenges of data specification changes in conventional controllers.
Patent Information
- Application Number
- JP2024054727
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-03-28
- Publication Date
- 2025-10-10
Smart Images

Figure 2025152699000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a control program and a controller. [Background technology]
[0002] Controllers are known in various production facilities, such as plants or factories, that receive information from IO (Input Output) devices, such as various sensors for temperature, flow rate, pressure, etc., and control actuators and other devices based on the received information. Various programs run on the controller, and multiple control applications operate to control the IO devices and actuators. For example, the control applications perform control calculations using data read from the IO devices and output the calculation results to the actuators for control. In addition, the control applications analyze and process data collected from the IO devices.
[0003] Applications use a variety of data, such as IO data for controlling the input and output of IO devices connected to the outside of the controller, and internal data managed within the controller.Internal data includes status data that indicates the controller's status and local data used by the application.
[0004] Various IO devices are connected using various communication protocols, and data is accessed from the control application using access procedures that conform to each communication protocol. Also, the methods for accessing and managing data collected from IO devices differ depending on the programming language used.
[0005] For example, when using C / C++, the most popular language for embedded devices, it is necessary to create methods for accessing actual IO devices and methods for managing various data on the application side. At this time, variable definitions are prepared within each program, and IO devices are assigned to variables that link IO device data with defined variables. Traditionally, linking IO device data with variables has been done on a language-by-language basis.
[0006] The following technologies are related to industrial controllers. For example, a technology has been proposed that extracts variable names from a control program to create an address map file and a header file, and then a program created using the header file accesses data using the address map file. Another technology has been proposed that creates a symbol table that allows a program executed by a programmable logic controller in an industrial automation environment to communicate with external devices. [Prior art documents] [Patent documents]
[0007] [Patent Document 1] Japanese Patent Application Publication No. 2018-185772 [Patent Document 2] International Publication No. 2013 / 005350 Summary of the Invention [Problem to be solved by the invention]
[0008] However, applications running on conventional controllers 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. [Means for solving the problem]
[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. [Effects of the Invention]
[0012] According to the present invention, the development time of an application can be reduced. [Brief explanation of the drawings]
[0013] [Figure 1] FIG. 1 is a block diagram of a control system according to an embodiment. [Figure 2] FIG. 2 is a block diagram of a controller. [Figure 3] FIG. 10 is a diagram showing a state when the association between tag names and device data is changed. [Figure 4] 10 is a sequence diagram of a process for collecting data held by an IO device and acquiring the data by a program. [Figure 5] 1 is a block diagram illustrating a system for program development and generation of tag definitions. [Figure 6] FIG. 10 is a diagram showing a GUI screen used to generate a tag definition. [Figure 7] 10 is a flowchart of a program development and tag definition generation process. [Figure 8] FIG. 2 is a diagram illustrating the hardware configuration of a development computer. DETAILED DESCRIPTION OF THE INVENTION
[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 composition) FIG. 1 is a block diagram of a control system according to an embodiment. The control system 100 is used in various manufacturing sites, such as semiconductor manufacturing plants and machine tool manufacturing plants. The control system 100 includes an upper server 20 and control devices 10A and 10B. A data input / output device 31, sensors 32, 34, and 36, and actuators 33, 35, and 37 are various devices used in the manufacturing site. The data input / output device 31 is a CPU-equipped device or a dedicated communication device equipped with a communication interface with the controller 1A. The data input / output device 31 is, for example, an EtherCAT (registered trademark) slave device, and is connected to the sensor 36 and the actuator 37.
[0016] The upper server 20 includes, for example, an industrial PC (Personal Computer) 21 and a database 22. The industrial PC 21 acquires data collected by the controller 1A or 1B using general-purpose communication such as OPC (Open Platform Communications) UA (Unified Architecture) (registered trademark) or Modbus (registered trademark). Alternatively, the industrial PC 21 may acquire data collected by the controller 1A or 1B using communication unique to the controller 1A or 1B. The industrial PC 21 then stores the acquired data in the database 22. The industrial PC 21 also sets control parameters for sensors 32, 34, and 36 and actuators 33, 35, and 37 for the controller 1A or 1B.
[0017] The control devices 10A and 10B are connected to an upper server 20. The control devices 10A and 10B control various devices arranged at the manufacturing site. There is no particular limit to the number of the control devices 10A and 10B. The control device 10A has a controller 1A. The control device 10B has a controller 1B.
[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 communication protocols 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 that controllers 1A and 1B have 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. Then, the controller 1A transmits the acquired data to the industrial PC 21. The controller 1A also controls the actuator 33 using the acquired data and controls the actuator 37 by transmitting commands to the data input / output device 31. The controller 1A also transfers data to the controller 1B. Similarly, the controller 1B periodically acquires data from the sensor 34, transmits the data to the industrial PC 21, and controls the actuator 35. Here, the controller 1A and the controller 1B have similar functions, and therefore, in the following description, when there is no need to distinguish between them, they will be described as the controller 1.
[0022] (controller) Fig. 2 is a block diagram of a controller. The controller 1 in Fig. 2 corresponds to the controllers 1A and 1B in Fig. 1. Also, IO devices 15A to 15C correspond to the data input / output device 31 and 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 different communication protocols may be used by each of the IO devices 15A to 15C.
[0024] 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. The IO devices 15A to 15C are an example of external devices, and the data storage unit 13 is an example of a "data storage device."
[0025] The data update unit 14A is connected to the IO device 15A via an external communication interface. The data update unit 14B is connected to the IO device 15B via an external communication interface. The data update unit 14C is connected to the IO device 15C via an external communication interface.
[0026] The data updating units 14A to 14C communicate using the communication protocols used by the IO devices 15A to 15C connected thereto. The data updating units 14A to 14C periodically acquire data from the IO devices 15A to 15C connected thereto using the respective communication protocols. Here, the data acquisition periods of the data updating units 14A to 14C are independent of each other. Here, periodic data acquisition is one example, and for example, if the IO devices 15A to 15C are devices connected to an Ethernet such as EtherNet / IP, the data updating units 14A to 14C may acquire data upon receiving an acquisition command.
[0027] Furthermore, when acquiring data, the data updating units 14A to 14C also acquire a timestamp indicating the acquisition time. Then, the data updating units 14A to 14C add the timestamp to the acquired data and store it as device data 130A to 130C in the data storage unit 13, which is a shared memory. The data updating units 14A to 14C overwrite the device data 130A to 130C every period and store it.
[0028] In this case, the data updating units 14A to 14C store the data obtained from the IO devices 15A to 15C, respectively, in different areas of the data storage unit 13, which is a shared memory. Specifically, the data updating unit 14A stores the device data 130A obtained from the IO device 15A in an area of the data storage unit 13 allocated to the IO device 15A. For example, the device data 130A includes data A0 and A1 to which a timestamp is added. Furthermore, the data updating unit 14B stores the device data 130B obtained from the IO device 15B in an area of the data storage unit 13 allocated to the IO device 15B. For example, the device data 130B includes data B0 and B1 to which a timestamp is added. Furthermore, the data updating unit 14C stores the device data 130C obtained from the IO device 15C in an area of the data storage unit 13 allocated to the IO device 15C. For example, the device data 130C includes data C0, C1, and C2 to which a timestamp is added.
[0029] 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 influence when the IO devices 15A to 15C are changed. The 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 a tag definition 120. The tag definition 120 holds tag names specified by a user. A tag name is information for identifying a tag used to access the device data 130A to 130C. For example, the tag definition 120 holds tag names T1 to T4. Furthermore, the tag definition 120 holds information on the correspondence between each tag name and the data included in the device data 130A to 130C linked to that tag name. For example, the tag definition 120 can use a combination of information on the IO devices 15A to 15C and the type of data as information for identifying the device data 130A to 130C. In FIG. 2, lines connecting each tag name held in the tag definition 120 to the data held in the device data 130A to 130C represent the correspondence. That is, the tag definition 120 in FIG. 2 actually includes tag names and information linking each tag name to the data held in the device data 130A to 130C. For example, the tag definition 120 may be a correspondence table that associates tag names with data held by the device data 130A to 130C.
[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] Furthermore, the tag definition 120 associates the tag name T3 with the data B0 included in the device data 130B. In this manner, the tag definition 120 can associate different tag names with the device data 130A and the device data 130B acquired from the different IO devices 15A and 15B, respectively.
[0034] Furthermore, the tag definition 120 associates the tag name T4 with the data C0 and C1 included in the device data 130 C. In this way, the tag definition 120 can associate the same tag name T4 with 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 associates multiple data with tags.
[0035] By linking multiple pieces of data to a single tag, such as tag name T4, it is possible to group data by application or function. This reduces the amount of code while improving code readability. An example of a data grouping is explained below. For example, the tag name is "RIGHT_ARM," which means "a collection of control data for the robot's right arm." RIGHT_ARM is then linked to data #1 indicating the measured value of motor M1, data #2 indicating the output of motor M1, data #3 indicating the measured value of motor M2, data #4 indicating the output of motor M2, and data #5 indicating the measured ambient temperature. This is a single group of data, and it can be managed collectively.
[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, the tag management unit 12 accesses the data held by the device data 130A to 130C linked to the tag name. Here, for example, if the tag definition 120 is a correspondence table, the tag management unit 12 can identify and access the data held by the device data 130A to 130C specified in the correspondence table corresponding to the specified tag name.
[0038] The application execution unit 11A runs an IEC61131-3 application by executing a program 111A. The program 111A is written in, for example, the IEC61131-3 programming language. The IEC61131-3 programming language defines LD (Ladder Diagram), FBD (Function Block Diagram), SFC (Sequential Function Chart), IL (Instruction List), and ST (Structured Text). The program 111A uses a shared library 112A to access device data 130A to 130C acquired from the IO devices 15A to 15C.
[0039] The application execution unit 11B runs a C / C++ application by executing a program 111B. The program 111B is written in, for example, the C / C++ programming language. The program 111B uses a shared library 112B to access the device data 130A to 130C acquired from the IO devices 15A to 15C.
[0040] The following describes access to device data 130A to 130C by program 111A or 111B. Since programs 111A and 111B have the same function for accessing data, 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-130C using tags represented by tag names T1-T4. Specifically, the program 111 describes the process of accessing the device data 130A-130C using tag names, which are identification information of individual tags, definition names of data types, and an API (Application Programming Interface) for accessing the tag definition 120. During operation, the program 111 uses the API to call the function of the shared library 112 for accessing data associated with the tag name corresponding to the target of the access request.
[0042] Thereafter, program 111 uses the function of shared library 112 to access data stored in data storage unit 13 that is associated with the tag name specified as the access target via tag definition 120. For example, if the tag corresponding to the target of the access request is tag name T1, program 111 calls the function of shared library 112 using the API to access data A0 of device data 130A that is associated with tag name T1 via tag definition 120. In this case, if the process to be executed by accessing the data is data acquisition, program 111 acquires and stores a timestamp along with data A0. Program 111 can process data A0 in chronological order using the timestamp.
[0043] In this way, even if the program 111A and the program 111B are written in different programming languages, they can access the device data 130A to 130C using the same tag. Furthermore, by storing a timestamp along with the data, it becomes possible to perform data analysis taking into account the time series. Furthermore, the I / O devices 150A to 150C can be controlled using data with a consistent time series, improving controllability.
[0044] 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 device 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 device 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, a process in chronological order, and the like. 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, a case where there is a change in the association between the tag name and the data included in the device data 130A to 130C will be described. Fig. 3 is a diagram showing a state where there is a change in the association between the tag name and the device data. Here, a case where the data associated with tag name T3 has been changed from data B0 to data B1 will be described.
[0046] When this change is made, in tag definition 120, information 121 linking tag name T3 to data B0 is changed to information 122 linking tag name T3 to data C2. In this case, programs 111A and 111B can access the changed data C2 by specifying tag name T3, without making any changes to application execution units 11A and 11B. In this way, even if the linkage is changed, application execution units 11A and 11B and programs 111A and 111B contained therein can continue to access the changed data without being changed.
[0047] 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) 4 is a sequence diagram of the process of collecting data held by the IO devices and the process of acquiring data by a program. Next, with reference to FIG. 4, the flow of the process of collecting data held by the IO devices 15A to 15C by the data update units 14A to 14C of the controller 1 according to this embodiment and the process of acquiring data by the program 111A or 111B will be described. Here, the process of collecting device data 130A held by the IO device 15A by the data update unit 14A and the process of acquiring data A0 of the IO device 15A by the program 111A will be described as an example.
[0049] The data updating unit 14A periodically collects data from the IO device 15A and obtains the results of the data collection. Then, the data updating unit 14A stores device data 130A, which is data acquired from the IO device 15A, in the data storage unit 13 (steps S101 to S103).
[0050] The IO device 15A receives periodic data collection from the data updating unit 14A and outputs the data to the data updating unit 14A (steps S111 to S113).
[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 acquires the acquisition result for the acquisition of data 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 linked to 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 illustrating 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 may 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] Fig. 6 is a diagram showing a GUI (Graphical User Interface) screen used to generate tag definitions. A user defines a tag using a GUI screen 200 shown in Fig. 6. The GUI screen 200 has items such as a data tag 201, a tag data type 202, an output 203, a device 204, a device data type 205, a direction 206, and a comment 207. The comment 207 can be used as a memo when defining the tag.
[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, the 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 data handled by the IO devices 15A to 15C.
[0062] Direction 206 is the direction in which data travels for each of IO devices 15A to 15C, where IN indicates data input from the outside and is read-only, and OUT indicates data output to the outside and is readable and writable.
[0063] Continuing the explanation, returning to Fig. 5, the development setting unit 40 sets a data area for storing the device data 130A to 130C in the data storage unit 13. When setting the data area, the development setting unit 40 defines the device data 130A to 130C according to their intended use.
[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 of the application execution units 11A and 11B and 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 the program 111A by having the development environment 41A refer to the data area definition 411A, thereby generating a program execution file for the IEC61131-3 application.
[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 IEC61131-3 application. The development setting unit 40 also downloads to the controller 1 a program execution file and a shared library 112B for a program 111B that runs a C / C++ application.
[0069] The following process is executed in the controller 1. The application execution unit 11A starts the IEC61131-3 application. When the program 111A of the IEC61131-3 application starts to execute, the shared library 112A is linked to the program 111A, the tag management unit 12 stores tag names, and the tag names are associated with the device data 130A to 130C. As a result, the tag definition 120 is generated.
[0070] Similarly, the application execution unit 11B starts the C / C++ application. When the program 111B of the C / C++ application starts to execute, the shared library 112B is linked to the program 111B, and the tag names in the tag definition 120 of the tag management unit 12 are associated with the data of the device data 130A to 130C.
[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 processing. The development setting unit 40 sets the data area in the data storage unit 13 again. The development setting unit 40 also acquires the definition newly set on the GUI screen 200, and regenerates the data area definition 411A and shared library 112A, as well as the data area definition 411B and shared library 112B, in accordance with the new definition. Thereafter, the development setting unit 40 downloads the shared libraries 112A and 112B to the controller 1.
[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 of the tag manager 12 and the device data 130A to 130C 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 IEC61131-3 application in accordance with the set definition. Similarly, the development setting unit 40 generates a shared library 112B for the program 111A that runs the C / C++ application, and data area definitions 411A and 411B in accordance with the set definition (step S2).
[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 to be reset (step S3: No), the development setting unit 40 references the data area definition 411A and creates the program 111A in the development environment 41A. Also, the development setting unit 40 references the data area definition 411B and creates the program 111B in the development environment 41B (step S4).
[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 process of developing the program and generating the tag definition 120 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). After that, 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. Also, the application execution unit 11B of the controller 1 starts the application and executes the program 111B (step S7).
[0082] A link to shared library 112A is created for program 111A. Also, a link to shared library 112B is created for program 111B. Furthermore, tag definition 120 is generated or updated based on shared libraries 112A and 112B (step S8).
[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 communication and data from multi-CPU communication 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, development computer 4 can be omitted if development computer 4 is configured not to create programs for development environments 41A and 41B. However, since it is only necessary to prepare an information terminal device connected to the network, settings can also be made from information terminal devices such as smartphones and tablets, rather than personal computers.
[0087] (effect) As described above, the controller 1 according to this embodiment periodically collects data from each of the devices 15A to 15C and temporarily stores the data in a unified data format together with a timestamp inside the controller 1. This allows data to be collected at high speed even from the IO devices 15A to 15C that use different protocols. This makes it possible to shorten the processing time using the data from the IO devices 15A to 15C.
[0088] Furthermore, the unified data format simplifies the structure when accessing data and absorbs the impact of changes to the devices 15A to 15C. It also becomes possible to handle data from the IO devices 15A to 15C and timestamps indicating the time when the data was acquired. This allows the programs 111A and 111B to perform data analysis based on time series. Furthermore, the IO devices 15A to 15C can be controlled using data with a consistent time series, improving controllability.
[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 to accommodate revisions or abolitions, or changes to the IO devices 15A to 15C due to changes in system requirements, all that is required is to change the tag definition 120 and evaluate the entire system. This reduces development time when changing data specifications. Furthermore, in the controller 1 according to this embodiment, even if the programs 111A and 111B are written in different programming languages, there is no duplication of data management between the multiple languages. This eliminates the need to design and implement the programs 111A and 111B with the duplication in mind, and also eliminates the need to deal with changes in specifications for each language, thereby shortening the overall development time.
[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 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] In addition, in the past, device allocation work had to be performed manually in the development environment of each programming language. In contrast, in the development environments 41A and 41B provided by the development computer 4 according to this embodiment, the programs 111A and 111B can be created using the set definition content, thereby improving development efficiency. Furthermore, in the development environments 41A and 41B provided by the development computer 4 according to this embodiment, the definition content of the data area can be created by assigning any name as a data tag, which leads to improved visibility and allows the programs 111A and 111B to be developed efficiently. Furthermore, the tag names and associations used in the tag definition 120 can be selected and used for the IO devices 15A to 15C required for the application. This makes it possible to reduce operational errors during program creation by hiding unnecessary IO devices 15A to 15C.
[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, in the development computer 4 according to this embodiment, the changes are completed by downloading the shared libraries 112A and 112B regenerated by the development setting unit 40, thereby reducing the amount of work involved in development. Furthermore, because the application's program execution file can be used as is, it is possible to prevent degradation due to the re-creation of the programs 111A and 111B and shorten the verification work. Furthermore, since the re-creation of the programs 111A and 111B is unnecessary, the setting change work can be performed even on a computer that does not have the development environments 41A and 41B for the programs 111A and 111B, thereby reducing equipment costs.
[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 arbitrarily unless otherwise specified.
[0094] Furthermore, the components of each device shown in the figure are functional concepts and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown. In other words, all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.
[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 a 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 execution unit 40.
[0101] The processor 91 reads out various programs stored in the hard disk 93, expands them in the memory 92, and executes them. In this way, the processor 91 realizes the functions of the development execution 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 executed by being read from the recording medium by a computer.
[0104] Some examples of combinations of the disclosed technical features are set out below.
[0105] (1) a receiver for receiving data from an external device; a data storage device for storing each piece of data transmitted from the external device; Computer and A control program for controlling a controller having Run multiple programs a tag definition that is information that links each piece of data stored in the data storage device with a tag that is common among the plurality of programs; making a request for access to data stored in the data storage device using the tag for each program; Based on the tag definition, data corresponding to the tag included in the access request from each program is identified, and each program is made to access the identified data stored in the data storage device. A control program that causes the computer to execute a process. (2) The control program according to (1), wherein 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) causing the computer to further execute a process of storing data for each type of external device in the data storage device; The process of storing the tag definition includes a process of storing the tag definition, which is information that links the combination of the type of the external device and the type of data with the tag. The control program according to (1) or (2) above. (4) The control program according to any one of (1) to (3), characterized in that the process of storing the tag definition includes a process of storing the tag definition, which is information that links multiple data with the tag. (5) The control program described in (4) is 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 with data compiled on an application basis run by each program. (6) The control program according to (4), wherein 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) A control program described in any one of (1) to (6), characterized in that the computer is further caused to execute a process of updating the link between the data contained 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 for 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), 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 receiving unit that receives data from an external device; a data storage unit for storing each piece of data transmitted from the external device; a program execution unit that executes a plurality of programs that access the data stored in the data storage unit by using a tag that is common among the programs linked to each data; a tag management unit that stores tag definitions that are information that associate each piece of data stored in the data storage unit with the tag, identifies data corresponding to tags included in access requests from each program executed by the program execution unit based on the tag definitions, and allows each program to access the identified data stored in the data storage unit; A controller comprising: [Explanation of symbols]
[0106] 1,1A,1B Controller 4 Development Computer 10A, 10B Control device 11A, 11B Application execution unit 12 Tag Management Section 13 Data storage unit 14A, 14B, 14C Data update section 15A, 15B, 15C IO devices 20 Upper Server 21 Industrial PC 22 Databases 32, 34, 36 Sensors 33, 35, 37 Actuator 40 Development Execution Department 41A, 41B development environment 100 Control System 111A, 111B Program 112A, 112B Library 120 tag definitions 130A, 130B, 130C device data 411A, 411B Data area definition
Claims
1. a receiver for receiving data from an external device; a data storage device for storing each piece of data transmitted from the external device; Computer and A control program for controlling a controller having Run multiple programs a tag definition that is information that links each piece of data stored in the data storage device with a tag that is common among the plurality of programs; making a request for access to data stored in the data storage device using the tag for each program; Based on the tag definition, data corresponding to the tag included in the access request from each program is identified, and each program is made to access the identified data stored in the data storage device. A control program that causes the computer to execute a process.
2. 2. The control program according to claim 1, wherein the process of executing the plurality of programs includes a process of executing the plurality of programs that are generated in a language different from that of the data stored in the data storage device.
3. causing the computer to further execute a process of storing data for each type of external device in the data storage device; The process of storing the tag definition includes a process of storing the tag definition, which is information that links the combination of the type of the external device and the type of data with the tag.
2. The control program according to claim 1.
4. 2. 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 according to 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 operated by each program.
6. 5. The control program according to claim 4, wherein the process of storing the tag definition includes a process of storing the tag definition, which is information that links data grouped in units of functions with the tag.
7. 2. 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. 2. 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. 2. 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 receiving unit that receives data from an external device; a data storage unit for storing each piece of data transmitted from the external device; a program execution unit that executes a plurality of programs that access the data stored in the data storage unit by using a tag that is common among the programs linked to each data; a tag management unit that stores tag definitions that are information that associate each piece of data stored in the data storage unit with the tag, identifies data corresponding to tags included in access requests from each program executed by the program execution unit based on the tag definitions, and allows each program to access the identified data stored in the data storage unit; A controller comprising:
Citation Information
Patent Citations
Industrial controller and data sharing method for industrial controller
JP2018185772A
Symbol table generation method, method for communication with peripheral apparatus and programmable logic controller
WO2013005350A1