Programmable device, version management method, and recording medium

Abstract

The PLC (10) has a storage section (100) that stores a first data set, a version management section (103) that performs version management on the first data set stored in the storage section (100), and a communication section (101) that transmits the first data set on which version management is performed by the version management section (103) to a development device, receives a second data set that is created based on the transmitted first data set and on which version management is performed by the development device in association with the first data set, and the version management section (103) stores the second data set received by the communication section (101) in the storage section (100) in association with the first data set and performs version management in association with the first data set.

Description

Technical Field

[0001] This invention relates to programmable devices, development apparatus, version management systems, version management methods, and computer-readable recording media storing programs. Background Technology

[0002] Programmable devices used in Factory Automation (FA), such as programmable logic controllers (PLCs) and motion units, execute programs created by the user to control the controlled equipment. To manage changes and progress during development, version management of the program and related data is required.

[0003] As a related technology, for example, non-patent document 1 discloses a technique for assisting the development of control software implemented by multiple people using the open-source distributed version management system Git.

[0004] Non-patent document 1: Shintaro Iwamura, "Utilizing Git's FA Integrated Development Environment and Multiple People's Parallel Development", [online], 2019 / 03 / 25, OMRON TECHNICS, [Retrieved March 10, 2019], website <URL: https: / / www.omron.com / jp / ja / technology / omrontechnics / 2019 / 20190315-iwamura.html> Summary of the Invention

[0005] In the technology described in Non-Patent Document 1, the programmable device itself is independent of the distributed version control system. Therefore, manual management of the compatibility between the source code managed by the distributed version control system and the program executed by the programmable device is required, increasing the user's burden. For example, there is the possibility that the program executed by the programmable device is not based on source code managed by the distributed version control system.

[0006] The object of the present invention is, in view of the above circumstances, to provide a programmable device, etc., that can easily perform distributed version management of data related to the programmable device.

[0007] To achieve the above objectives, the programmable device of the present invention has the following features:

[0008] The first storage unit stores the first dataset;

[0009] The first version management unit manages the version of the first dataset stored in the first storage unit;

[0010] The first sending unit sends the first dataset, which has been version-managed by the first version management unit, to the development device; and

[0011] The first receiving unit receives a second dataset, which is created based on the first dataset sent by the first sending unit and is version-managed by the development device in association with the first dataset.

[0012] The first version management unit stores the second dataset received by the first receiving unit in the first storage unit in association with the first dataset, and performs version management in association with the first dataset.

[0013] The effects of the invention

[0014] According to the present invention, distributed version management of data related to programmable devices can be easily performed. Attached Figure Description

[0015] Figure 1 This is a diagram illustrating the overall structure of the version management system according to Embodiment 1 of the present invention.

[0016] Figure 2 This is a diagram illustrating an example of version management implemented through the version management system according to Embodiment 1 of the present invention.

[0017] Figure 3 This is a block diagram illustrating the functional structure of the PLC according to Embodiment 1 of the present invention.

[0018] Figure 4 This is a diagram illustrating an example of the hardware structure of the PLC according to Embodiment 1 of the present invention and the development device according to Embodiment 2 of the present invention.

[0019] Figure 5 This is a flowchart illustrating an example of version management operations implemented by a PLC according to Embodiment 1 of the present invention.

[0020] Figure 6 This is a diagram illustrating the overall structure of a version management system according to a variation of Embodiment 1 of the present invention.

[0021] Figure 7 This is a block diagram illustrating the functional structure of the development apparatus according to Embodiment 2 of the present invention.

[0022] Figure 8 This is a diagram illustrating an example of distributed version management implemented through the version management system according to Embodiment 2 of the present invention.

[0023] Figure 9This is a diagram illustrating an example of distributed version management implemented through the version management system according to Embodiment 2 of the present invention.

[0024] Figure 10 This is a diagram illustrating an example of distributed version management implemented through the version management system according to Embodiment 2 of the present invention.

[0025] Figure 11 This is a diagram illustrating an example of distributed version management implemented through the version management system according to Embodiment 2 of the present invention.

[0026] Figure 12 This is a diagram illustrating an example of distributed version management implemented through the version management system according to Embodiment 2 of the present invention.

[0027] Figure 13 This is a diagram illustrating an example of distributed version management implemented by a version management system according to a variation of Embodiment 2 of the present invention.

[0028] Figure 14 This is a diagram illustrating an example of distributed version management implemented by a version management system according to a variation of Embodiment 2 of the present invention. Detailed Implementation

[0029] The following is a reference to the appendix. Figure 1 The version management system according to embodiments of the present invention will be described below. In the accompanying drawings, the same or equivalent parts are labeled with the same reference numerals.

[0030] (Implementation Method 1)

[0031] While referring to Figure 1 The version management system 1 according to Embodiment 1 will be described below. Version management system 1 includes a PLC (Programmable Logic Controller) 10 and multiple development devices 20. Version management system 1 is an example of the version management system involved in this invention.

[0032] In the version management system 1, multiple users develop programs that are executed by PLC 10 using various development devices 20. Users send the dataset to PLC 10, which includes the programs developed using the development devices 20 and related data. This program-related data includes, for example, the source code that forms the program's origin, configuration and resource files required by the program, and documentation specifying the program's specifications.

[0033] For example, when a user completes a program change job, they send the dataset to PLC 10. PLC 10 performs version management on the received dataset while executing the program contained within it. When a user sends the dataset to PLC 10 each time a change job is completed, PLC 10 performs version management on the dataset after each change job.

[0034] PLC 10 executes user-developed programs to control controlled devices (not shown). In addition to program execution, PLC 10 also performs version control of the dataset as described above. The functional structure of PLC 10 will be described later. PLC 10 is an example of the programmable device involved in this invention.

[0035] The development device 20 is used for developing programs executed by the PLC 10. The development device 20 is, for example, a personal computer with engineering design tools installed. The user creates a dataset containing the program executed by the PLC 10 using the development device 20 and sends the created dataset to the PLC 10. The development device 20 is an example of the development apparatus of the present invention.

[0036] Next, we will give a brief overview of version management in Version Management System 1. In Version Management System 1, program development generally follows this process.

[0037] (1) Users create datasets containing programs through development jobs.

[0038] (2) PLC 10 authenticates users.

[0039] (3) The user sends the dataset to PLC 10.

[0040] (4) PLC 10 performs version management on the received dataset.

[0041] (5) The user performs debugging work by executing the program contained in the dataset sent to PLC 10 on PLC 10.

[0042] (6) Modify the assignment as needed and repeat the assignment starting from (1).

[0043] (7) After all the modifications are completed, the program is executed on PLC 10 and multiple users confirm the actions.

[0044] (8) Based on the results of the action confirmation, the user repeatedly performs the operation that started from (1).

[0045] In (1) to (8) above, (7) is a job performed jointly by multiple users, while the others are jobs performed individually by users. Therefore, it is sufficient to manage the datasets related to individual user jobs and the datasets related to joint jobs separately.

[0046] PLC 10 manages datasets by dividing them into a main area and user areas for each user. The main area is accessible to all users, while the user areas are accessible only to their respective users. Datasets created by users are generally stored in the user areas; however, datasets that should be shared among all users are stored in the main area based on user actions. Hereinafter, storing datasets in the main area based on user actions is referred to as "applying datasets to the main area." Examples of datasets that should be shared among all users include, for instance, datasets containing executable files that should be tested together by all users after all change jobs performed by users are completed, and datasets containing executable files that have reached a deliverable level as a product.

[0047] While referring to Figure 2 Specific examples will be provided. Figure 2 The circles shown represent one dataset. Figure 2 The arrows shown indicate a dataset that is used as the most recent parent to create a child dataset. When a change operation is performed on a dataset and other datasets are created, the dataset before the change is the "most recent parent," and the dataset after the change is the "child." Furthermore, the dataset x1, which serves as the "original dataset," is created, for example, by saving the dataset to the main area when the PLC 10 first receives the dataset.

[0048] First, user A performs a change job based on dataset x1, which exists in the main region, and sends the modified dataset to PLC 10. Hereafter, performing a change job based on a dataset and sending the modified dataset to PLC 10 will be referred to as an "update". Through the update performed by user A, dataset y1, which branches off from dataset x1 in the main region, is stored in user A's region instead of the main region. Dataset x1 is the most recent parent of dataset y1.

[0049] By updating dataset y1 through user A, dataset y2, with dataset y1 as its nearest parent, is saved in user region A. Next, through the same update operation, dataset y3, with dataset y2 as its nearest parent, is saved in user region A.

[0050] Then, user A performs a job to apply dataset y3 to the main region, resulting in dataset x2, which has the same content as dataset y3, being saved in the main region with datasets x1 and y3 as its closest parents. This dataset x2 has the content of the change job performed by user A between datasets y1 and y3 applied. The root parent of dataset y3 is dataset x1, and the latest dataset in the main region at this point in time is dataset x1; therefore, dataset y3 can be applied to the main region without any problems. Furthermore, the term "root parent" here refers to a dataset whose parent is traced back one generation or more. Figure 2 In the example shown, dataset x1 is called the "root parent" relative to each of datasets y1, y2, and y3.

[0051] Next, we will explain user B's task. First, like user A, user B updates the dataset x1 in the main region, thereby saving the dataset z1, which branches off from dataset x1 in the main region and has dataset x1 as its nearest parent, in user B's region. User B then performs two more updates: dataset z2, with dataset z1 as its nearest parent, is saved in user B's region, and dataset z3, with dataset z2 as its nearest parent, is saved in user B's region. Furthermore, user B's task up to this point was performed before dataset x2 was saved in the main region.

[0052] User B then wants to apply dataset z3, which has had its changes applied, to the main region. However, the latest dataset stored in the main region is dataset x2, not dataset x1. Therefore, a conflict will occur even if dataset z3 is applied to the main region. Consequently, it cannot be applied directly.

[0053] Therefore, user B performs a job that merges dataset z3 (with the latest changes applied by user B) with dataset x2 in the main region, so as to update the dataset using the changes made by this job. As a result, dataset z4, with dataset z3 as its most recent parent, is stored in user region B.

[0054] Then, user B performs a job that applies dataset z4 to the main region, resulting in dataset x3, which has the same content as dataset z4, being stored in the main region with dataset x2 and dataset z4 as its most recent parents. This dataset x3 is formed by merging the content of the change job performed by user B between datasets z1 and z3 with the content of dataset x2.

[0055] PLC 10 manages datasets by dividing them into main and user areas, enabling user-based dataset management. This allows users to focus on only the main dataset and their corresponding user dataset during program development, facilitating version control in multi-user development environments.

[0056] Next, while referring to Figure 3 The functional structure of PLC 10 will be explained below. PLC 10 has a storage unit 100, a communication unit 101, a user authentication unit 102, a version management unit 103, and a program execution unit 104.

[0057] The storage unit 100 stores the dataset based on version management implemented by the version management unit 103, which will be described later. The storage unit 100 includes a main area M and multiple user areas U set up on a per-user basis. The storage unit 100 is an example of the first storage unit of the present invention.

[0058] The communication unit 101 communicates with the development device 20. The communication unit 101 is, for example, a network interface. The communication unit 101 is an example of the first transmitting unit and the first receiving unit of the present invention.

[0059] User authentication unit 102 authenticates users corresponding to development devices 20 that become communication targets of communication unit 101. User authentication unit 102 authenticates users, for example, through password authentication. Alternatively, the administrator of PLC 10 may pre-register users corresponding to each development device 20 in PLC 10, and user authentication unit 102 may automatically authenticate users by identifying development devices 20.

[0060] Version management unit 103 manages the versions of the datasets received by communication unit 101. Version management unit 103 manages the datasets by storing them separately in main region M and individual user regions U. Version management unit 103 stores the dataset whose most recent parent is the dataset stored in main region M in the user region U corresponding to the user who made the update. Therefore, the dataset to be stored is the dataset "branched" from the dataset in main region M. Furthermore, version management unit 103, in principle, stores the dataset whose most recent parent is the dataset stored in user region U. Therefore, in principle, datasets sent by users are stored in user region U.

[0061] However, when a user performs a job to apply a dataset stored in their user region U to the main region M, the version management unit 103 stores that dataset in the main region M. Furthermore, if the root parent of the dataset the user wants to apply to the main region M differs from the latest dataset stored in the main region M, the version management unit 103 rejects the application performed by the user. In this case, the user needs to perform a job to merge the latest dataset stored in the main region M with their own dataset.

[0062] When saving a dataset in the main area M or the user area U, the version management unit 103 not only saves the dataset body, but also saves metadata that independently identifies the dataset and metadata representing the most recent parent dataset of the dataset to be saved, in association with the dataset body. For example, the hash value of the binary data when the dataset body is processed as a single binary data can be used as metadata. Therefore, when saving a dataset, it can be associated with the most recent parent dataset, thus enabling the management of parent-child relationships between datasets and allowing version management of the dataset as a whole. The version management unit 103 is an example of the first version management unit of the present invention.

[0063] The program execution unit 104 reads the program stored in the storage unit 100 via the version management unit 103 and executes the read program. For example, the program execution unit 104 reads and executes the program contained in the latest dataset stored in the storage unit 100. Alternatively, the program execution unit 104 may also read and execute the program contained in a dataset specified by the user. For example, sometimes due to work process reasons, the source code cannot be compiled temporarily, resulting in a state where the executable file does not exist in the latest dataset. In such cases, the user needs to specify a dataset where the executable file exists.

[0064] Furthermore, the program execution unit 104 stores logs related to program execution and datasets corresponding to executed programs in the storage unit 100. The logs related to program execution include, for example, information indicating the execution date and time, information related to events and errors generated during program execution, and information about datasets corresponding to executed programs. For example, users can analyze these logs to evaluate the quality of the program for each dataset.

[0065] Next, while referring to Figure 4 Here's an example illustrating the hardware structure of a PLC 10. A PLC 10 is a programmable logic controller, and therefore a type of computer.

[0066] The PLC 10 has a processor 1001, a memory 1002, an interface 1003, and a secondary storage device 1004 that are connected to each other via a bus 1000.

[0067] The processor 1001 is, for example, a CPU (Central Processing Unit). The processor 1001 implements the various functions of the PLC 10 by reading the operation program stored in the secondary storage device 1004 into the memory 1002 and executing the operation program. Furthermore, in addition to the processor that executes the operation program, the processor 1001 may also include a processor that reads and executes the dataset stored in the storage unit 100. In this case, the latter processor implements the functions of the program execution unit 104.

[0068] The memory 1002 is, for example, a main storage device composed of RAM (Random Access Memory). The memory 1002 stores the operation program read by the processor 1001 from the secondary storage device 1004. In addition, the memory 1002 functions as working memory when the processor 1001 executes the operation program.

[0069] Interface 1003 is, for example, an I / O (Input / Output) interface such as a serial port, a USB (Universal Serial Bus) port, or a network interface. The functions of the communication unit 101 are implemented through interface 1003.

[0070] The secondary storage device 1004 is, for example, flash memory, HDD (Hard Disk Drive), or SSD (Solid State Drive). The secondary storage device 1004 stores the operating programs executed by the processor 1001. The functions of the storage unit 100 are realized through the secondary storage device 1004.

[0071] Next, while referring to Figure 5 Here is an example of a version management action implemented by PLC 10. Figure 5 The actions shown are, for example, performed at the point when the user operates the development device 20 and the development device 20 initiates communication in order to send the dataset to the PLC 10.

[0072] The user authentication unit 102 of PLC 10 communicates with the development device 20 to authenticate the user of the development device 20 (step S101). The user who sent the dataset is determined through this action.

[0073] If the user is authenticated, the development device 20 sends a dataset to the PLC 10, and the communication unit 101 of the PLC 10 receives the sent dataset (step S102).

[0074] The version management unit 103 of PLC 10 determines whether the user wants to apply the dataset to the main area M (step S103).

[0075] When a user does not want to apply the dataset to the main region M (step S103: No), the version management unit 103 saves the dataset received in step S102 to the user region U corresponding to the user authenticated in step S101 (step S104). In this operation, if the nearest parent of the saved dataset is a dataset existing in the main region M, the saved dataset is a dataset "branched" from the dataset in the main region M. Then, PLC 10 ends the version management operation.

[0076] When a user wants to apply a dataset to the main region M (step S103: Yes), the version management unit 103 determines whether the dataset of the root parent of the dataset to be applied is consistent with the latest dataset of the main region M (step S105).

[0077] When the root parent dataset of the dataset to be applied is consistent with the latest dataset in the main region M (step S105: Yes), the version management unit 103 saves the dataset to be applied in the main region M (step S106). Then, PLC 10 ends the version management operation.

[0078] When the root parent dataset of the dataset to be applied is inconsistent with the latest dataset in the main region M (step S105: No), the version management unit 103 rejects the application of the dataset to the main region M (step S107). Then, PLC 10 ends the version management operation.

[0079] The version management system 1 according to Implementation Method 1 has been described above. The PLC 10 of the version management system 1 manages versions by storing datasets separately in a main area M and a user area U for each user. Therefore, when developing a program, users only need to focus on the dataset in the main area M and the dataset in their corresponding user area U, making version management easy in a multi-user development environment.

[0080] (A variation of Implementation Method 1)

[0081] In implementation method 1, it is also possible to... Figure 6 As shown, PLC 10 is communicatively connected to external system 30. The version management unit 103 of PLC 10 performs backups by sending the dataset stored in storage unit 100 to external system 30 at predetermined timings. The backup timing can be based on newly added datasets or performed periodically.

[0082] Alternatively, instead of PLC 10, development device 20 can be communicatively connected to external system 30. Data sets stored in the storage unit 100 of PLC 10 can be read by development device 20 and sent to external system 30 for backup. This method can be used, for example, when development device 20 can connect to the internet but PLC 10 cannot.

[0083] In implementation method 1, each user can access the dataset corresponding to their own user region U, but cannot access the datasets corresponding to other users' user regions U. Here, it's not simply a matter of inaccessibility; the datasets of each user region U can also be encrypted using an encryption key corresponding to each user.

[0084] Alternatively, the dataset in the main area M can be encrypted using the encryption key inherent in the PLC 10. Therefore, anyone without the PLC 10 cannot decrypt the dataset in the main area M. This prevents third parties from knowing the contents of the dataset even if it is leaked for some reason.

[0085] In Implementation 1, as long as it does not conflict with the latest dataset in the main region M, the user can apply the dataset from the user region U to the main region M at any time. On the other hand, if the dataset is continuously updated without being applied to the main region M, the discrepancy between the content of the dataset in the main region M and the content of the dataset in the user region U will increase, potentially hindering development. Therefore, for example, the version management unit 103 may issue a warning to the user if the dataset has been updated a certain number of times in the user region U. For example, the version management unit 103 sends the warning data to the development device 20 via the communication unit 101, and the development device 20 notifies the user of the warning.

[0086] (Implementation Method 2)

[0087] The version management system 1 according to Embodiment 2 will be described below. The overall structure of the version management system 1 according to Embodiment 2 is similar to... Figure 1 The structure is the same as in Embodiment 1. The difference in Embodiment 2 is that the development device 20 also performs version management of the dataset, unlike in Embodiment 1.

[0088] Therefore, users do not need to send datasets to PLC 10 for each change. For example, users can make multiple changes to the dataset, and after all the change jobs are completed, send the aggregated datasets corresponding to the multiple changes to PLC 10.

[0089] For example, in Figure 2In the example shown, in Implementation 1, user A updates the dataset by sending datasets y1, y2, and y3 to PLC 10 each time. On the other hand, in Implementation 2, if user A obtains dataset x1, after obtaining dataset x1, they can perform change operations related to datasets y1, y2, and y3 without communicating with PLC 10, and can send datasets y1, y2, and y3 in summary to PLC 10 to apply dataset y3 to the main area M.

[0090] While referring to Figure 7 The functional structure of the development apparatus 20 according to Embodiment 2 will be described below. The development apparatus 20 according to Embodiment 2 includes a storage unit 200, a communication unit 201, a dataset creation unit 202, and a version management unit 203.

[0091] The storage unit 200 stores the dataset based on version management implemented by the version management unit 203, which will be described later. The storage unit 200 includes a main area M and a user area U. However, unlike the storage unit 100 of the PLC 10, the user area U is only one area corresponding to the user of the development device 20. The storage unit 200 is an example of the second storage unit involved in this invention.

[0092] The communication unit 201 communicates with the PLC 10. Based on the control of the version management unit 203 (described later), the communication unit 201 sends datasets created by the user through the development device 20 to the PLC 10 and receives datasets stored in the storage unit 100 from the PLC 10. The communication unit 201 is implemented, for example, via a network interface. The communication unit 201 is an example of the second receiving unit and the second transmitting unit involved in this invention.

[0093] The dataset creation unit 202 creates a program executed by the PLC 10 and related data based on user operations via an input device (not shown). In other words, the dataset creation unit 202 creates a dataset based on user operations. The dataset creation unit 202 may have, for example, the functionality of an editor for describing source code, configuration files, documents, etc. The dataset creation unit 202 is an example of the dataset creation unit of the present invention.

[0094] Version management unit 203 manages the version of the datasets created by dataset creation unit 202 by storing them in the user area U of storage unit 200. When saving the dataset, version management unit 203, similar to version management unit 103 of PLC 10, not only saves the dataset body but also saves metadata that independently identifies the dataset and metadata representing the most recent parent dataset of the dataset to be saved, in association with the dataset body. Thus, version management is performed on user-created datasets within development device 20.

[0095] Version management unit 203 will send one or more datasets that have not yet been sent to PLC 10 from the datasets stored in user area U of storage unit 200 to PLC 10 via communication unit 201. This allows the changes made by the user through development device 20 to be synchronized with PLC 10.

[0096] Version management unit 203 obtains, via communication unit 201, one or more datasets from the datasets stored in the main area M of storage unit 100 of PLC 10 that are not stored in the main area M of storage unit 200, and stores them in the main area M of storage unit 200. This allows changes to the main area M of PLC 10 to be synchronized with development device 20. Version management unit 203 is an example of the second version management unit of the present invention.

[0097] Here, the differences between the PLC 10 in Embodiment 2 and Embodiment 1 will be explained. As described above, the development device 20 in Embodiment 2 can send multiple datasets to the PLC 10. Furthermore, as described above, the development device 20 in Embodiment 2 obtains the datasets of the main area M from the PLC 10. Therefore, the version management unit 103 in Embodiment 2 also corresponds to this. The version management unit 103 in Embodiment 2 receives multiple datasets from the development device 20 in aggregate and stores the received datasets in the user area U of the storage unit 100. The version management unit 103 in Embodiment 2 sends one or more datasets from the main area M to the development device 20 according to a request from the development device 20.

[0098] By utilizing the functions of the version management unit 203 of the development device 20 and the version management unit 103 of the PLC 10, version management of the dataset can be performed independently in the PLC 10 and the development device 20, and synchronization can be achieved between the PLC 10 and the development device 20 as needed. Therefore, according to the version management system 1 of Embodiment 2, distributed version management can be realized.

[0099] The following is a reference to the appendix. Figure 1 Let's illustrate with a specific example. First, assume that only dataset x1 is stored in the storage unit 100 of PLC 10, and no dataset is stored in the storage unit 200 of development device 20.

[0100] First, based on user operation, the version management unit 203 of the development device 20 retrieves the dataset x1 stored in the storage unit 100 from the PLC 10 and stores it in the main area M of the storage unit 200. Thus, as... Figure 8 As shown, dataset x1 is also stored in the main area M of the storage unit 200 of the development device 20.

[0101] Next, the user of development device 20 performs modification operations on dataset x1. As a result, the dataset creation unit 202 of development device 20 creates a new dataset, such as... Figure 9 As shown, the version management unit 203 saves the new dataset as dataset y1 in the user area U of the storage unit 200. At this point in time, PLC 10 is not communicating with the development device 20, therefore, the storage unit 100 of PLC 10 is not significantly changed.

[0102] Then, the user performs two change jobs, such as Figure 10 As shown, datasets y2 and y3 are stored in the user area U of storage unit 200. At this point in time, there are no significant changes in storage unit 100 of PLC 10.

[0103] Next, based on the user's actions, the version management unit 203 will send the datasets y1, y2, and y3 stored in the user area U of the storage unit 200 to the PLC 10 in a summarized manner. The version management unit 103 of the PLC 10 will then... Figure 11 As shown, the received datasets y1, y2, and y3 are stored in the user area U of the storage unit 100. Synchronization can only be achieved between the development device 20 and the PLC 10 at this point in time.

[0104] Then, by applying dataset y3 to the main area M of storage unit 100 of PLC 10, dataset x2 with the same content as dataset y3 is saved in the main area M of storage unit 100. The version management unit 203 of development device 20 then retrieves dataset x2 saved in the main area M of storage unit 100 from PLC 10 and saves it in the main area M of storage unit 200. Thus, as... Figure 12 As shown, either PLC 10 or development device 20 can perform version management on datasets x1, x2, y1, y2, and y3.

[0105] In addition, such as Figure 2As illustrated by datasets z3, x2, z4, and x3, sometimes conflicts arise when trying to apply a dataset from user area U to main area M, preventing direct application. In this case, firstly, the version management unit 203 of development device 20 obtains the dataset stored in main area M of storage unit 100 from PLC 10 and stores it in main area M of storage unit 200. Next, the user performs a merge operation on the dataset stored in main area M of storage unit 200, the dataset creation unit 202 creates a dataset, and the version management unit 203 saves the dataset in user area U of storage unit 200. Then, the version management unit 203 sends the new dataset stored in user area U of storage unit 200 to PLC 10, and the version management unit 103 of PLC 10 saves the received dataset in user area U of storage unit 100. Then, the user can try to apply the dataset from user area U to main area M again.

[0106] The program execution unit 104 of PLC 10 executes the program contained in the dataset stored in storage unit 100 in the same manner as in Embodiment 1. Therefore, the user can easily manage the compatibility between the source code, which is subject to version management, and the program executed by PLC 10.

[0107] Furthermore, the hardware structure of the development device 20 involved in Implementation 2 is similar to... Figure 4 The structures shown are largely the same. This is because, as explained in Embodiment 1, the development device 20 is, for example, a personal computer with a program for engineering design tools installed.

[0108] The version management system 1 according to Embodiment 2 has been described above. According to the version management system 1 according to Embodiment 2, the dataset can be version managed independently in the PLC 10 and the development device 20, and synchronization can be achieved between the PLC 10 and the development device 20 as needed. Therefore, the version management system 1 according to Embodiment 2 can realize distributed version management. Furthermore, similar to Embodiment 1, the PLC 10 executes the program contained in the dataset stored in the storage unit 100; therefore, the user can easily manage the compatibility between the source code that is the object of version management and the program executed by the PLC 10. Therefore, the version management system 1 according to Embodiment 2 can easily perform distributed version management of data related to the programmable device.

[0109] Furthermore, by managing datasets separately in the main region M and the user region U, when a user wants to merge created datasets, both the dataset in user region U and the dataset in main region M are checked, and the merge is performed only after a decision is made. Therefore, managing datasets separately in the main region M and the user region U avoids placing a significant burden on the user during the merging process, naturally allowing for decision-making and preventing accidental merging of datasets. For example, it can prevent datasets that have not yet been fully debugged from being accidentally merged.

[0110] (A variation of Implementation Method 2)

[0111] Implementation 2 is a variation of Implementation 1; therefore, similarly to Implementation 1, there are multiple users. On the other hand, in Implementation 2, even when there is only one user, distributed version management of the dataset is possible within the user's development device 20 and the PLC 10. In this case, the storage unit 100 of the PLC 10 has a main area M and one user area U. Furthermore, the PLC 10 does not necessarily need to have a user authentication unit 102.

[0112] Furthermore, in Implementation Method 2, a method is also conceived of managing the dataset in a single area instead of separating it into a main area M and a user area U. The following description illustrates an example where multiple users create datasets using their respective development devices 20, and then send these datasets to the PLC 10 for updates.

[0113] like Figure 13 As shown, consider the scenario where users A and B develop data using development devices 20 based on dataset x1 stored in the storage unit 100 of PLC 10. User A creates datasets y1, y2, and y3, while user B creates datasets z1 and z2. Next, user A updates the datasets earlier than user B, and then user B updates the datasets. In this case, as... Figure 14 As shown, user A's datasets y1, y2, and y3, which were updated first, are stored unchanged in the storage unit 100 of PLC 10. The line storing datasets x1, y1, y2, and y3 is called the "main line". Then, user B's datasets z1 and z2, which were updated later, are stored in the storage unit 100 of PLC 10 in a branching form from the main line. In this way, by applying the "first-come, first-served" principle to update the datasets, and storing datasets that were not updated first in a branching form from the main line, distributed version management by multiple users can be achieved without distinguishing between the main area M and the user area U. Furthermore, the merging of y3 and z2 can be achieved in the same way as in embodiments 1 and 2.

[0114] Furthermore, in Implementation 2, if a dataset exists in user region U that has not been merged with the main region M for a long time, a warning email can also be sent to the user. For example, the warning email can be sent to the user based on the information used in the authentication process when the user is authenticated by the user authentication unit 102. Since datasets that have not been merged with the main region M for a long time are likely to deviate significantly from the dataset in the main region M, issuing a warning is beneficial.

[0115] (Other variations)

[0116] In the embodiments described above, PLC 10 performs version management of the dataset. On the other hand, other programmable devices besides the PLC can also implement version management by having the same functional units as the PLC 10. For example, in the development of a program executed by a motion unit, the motion unit has the same functional units as the PLC 10, thereby enabling version management of the dataset associated with the program executed by the motion unit.

[0117] exist Figure 4 In the hardware structure shown, the PLC 10 and development device 20 have a secondary storage device 1004. However, it is not limited to this; the secondary storage device 1004 can also be located externally to the PLC 10 and development device 20, with the PLC 10 and development device 20 connected to the secondary storage device 1004 via interface 1003. In this configuration, removable media such as USB flash drives and memory cards can also be used as the secondary storage device 1004.

[0118] Alternatively, it can also replace Figure 4 The hardware structure shown consists of a PLC 10 and a development device 20, which are constructed using dedicated circuits such as ASICs (Application Specific Integrated Circuits) and FPGAs (Field Programmable Gate Arrays). Additionally, in Figure 4 In the hardware structure shown, for example, a portion of the functions of the PLC 10 and the development device 20 can also be implemented by a dedicated circuit connected to the interface 1003.

[0119] The programs used in PLC 10 and development device 20 can be stored and distributed on computer-readable recording media such as CD-ROM (Compact Disc Read-Only Memory), DVD (Digital Versatile Disc), USB flash drive, memory card, and HDD. Furthermore, by installing these programs on a specific or general-purpose computer, that computer can function as PLC 10 and development device 20.

[0120] Alternatively, the program can be pre-stored on the storage device of another server on the Internet, and then downloaded from that server.

[0121] This invention allows for various implementations and modifications without departing from its broad spirit and scope. Furthermore, the above-described embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. That is, the scope of the invention is defined by the claims, not the embodiments. Moreover, various modifications implemented within the scope of the claims and their equivalents are considered to fall within the scope of this invention.

[0122] Explanation of the label

[0123] 1 Version Management System, 10 PLCs, 20 Development Devices, 30 External Systems, 100 Storage Unit, 101 Communication Unit, 102 User Authentication Unit, 103 Version Management Unit, 104 Program Execution Unit, 200 Storage Unit, 201 Communication Unit, 202 Dataset Creation Unit, 203 Version Management Unit, 1000 Bus, 1001 Processor, 1002 Memory, 1003 Interface, 1004 Secondary Storage Device, M Main Area, U User Area.

Claims

1. A programmable device comprising: The first storage unit includes a first main area and a first user area, and the first dataset is stored in the first main area; The first version management unit performs version management on the first dataset stored in the first main area of ​​the first storage unit; The first sending unit sends the first dataset, which has been version-managed by the first version management unit, to the development device; and The first receiving unit receives a second dataset, which is created based on the first dataset sent by the first sending unit and is version-managed by the development device in association with the first dataset. The first version management unit stores the second dataset received by the first receiving unit in association with the first dataset in the first user area of ​​the first storage unit, and performs version management in association with the first dataset. If, based on a user's operation, it is desired to save the second dataset stored in the first user area to the first main area, the first version management unit determines whether the first dataset corresponding to the second dataset is consistent with the first dataset stored in the first main area. If they are consistent, the saving is allowed; if they are inconsistent, the saving is rejected.

2. A version management method, wherein, The programmable device performs version management on a first dataset stored in the first main area, which includes a first main area and a first user area, within a first storage unit. The programmable device sends the version-managed first dataset to the development device. The programmable device receives a second dataset, which is created based on the first dataset and is version-managed by the development device in association with the first dataset. The programmable device stores the received second dataset in association with the first dataset in the first user area of ​​the first storage unit, and performs version management associated with the first dataset. If, based on a user's operation, it is desired to save the second dataset stored in the first user area to the first main area, it is determined whether the first dataset corresponding to the second dataset is consistent with the first dataset stored in the first main area. If they are consistent, the saving is allowed; if they are inconsistent, the saving is rejected.

3. A recording medium storing a computer-readable program that causes a computer to perform the following actions: Version management is performed on the first dataset stored in the first main area, which includes the first main area and the first user area, in the first storage unit. The first dataset, which has undergone version control, is sent to the development device. The system receives a second dataset, which is created based on the first dataset and is version-managed by the development device in association with the first dataset. The received second dataset is stored in the first user area of ​​the first storage unit in association with the first dataset, and version management is performed in association with the first dataset. If, based on a user's operation, it is desired to save the second dataset stored in the first user area to the first main area, it is determined whether the first dataset corresponding to the second dataset is consistent with the first dataset stored in the first main area. If they are consistent, the saving is allowed; if they are inconsistent, the saving is rejected.

Images