PROGRAMMABLE DEVICE, VERSION MANAGEMENT SYSTEM, VERSION MANAGEMENT METHOD AND PROGRAM

Abstract

The PLC (10) includes a storage unit (100) including a master area (M) and a plurality of user areas (U) corresponding to a plurality of users, a user authentication unit (102) that authenticates each of the plurality of users, and a version management unit (103) that stores a first data set created by a user authenticated by the user authentication unit (102) in the storage unit (100) and performs version management. The version management unit (103) associates the first data set with a second data set that is already stored in the storage unit (100) and is the immediate parent of the first data set, and stores the first data set in the master area (M) or in the user area (U) corresponding to the user authenticated by the user authentication unit (102) among the plurality of user areas (U).

Description

[Technical field]

[0001] The present disclosure relates to a programmable device, a version control system, a version control method, and a program. [Background technology]

[0002] Programmable devices for FA (Factory Automation), such as programmable logic controllers and motion units, execute programs developed by users to control controlled devices. There is a demand for version management of programs and data related to the programs to manage changes and progress during development.

[0003] In relation to the above circumstances, for example, Patent Document 1 discloses a programmable logic controller that itself has a version management function. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2022 / 259374 Summary of the Invention [Problem to be solved by the invention]

[0005] The programmable logic controller in Patent Document 1 does not assume development by multiple people, and therefore has the problem of not being able to manage versions by user. Therefore, when multiple users individually carry out program development work, it is necessary to determine in advance operational rules between the users, such as the order in which to update the program in the programmable logic controller, which may induce operational errors.

[0006] In view of the above circumstances, an object of the present disclosure is to provide a programmable device or the like that allows easy version management in an environment where multiple people are developing the device. [Means for solving the problem]

[0007] In order to achieve the above object, the programmable device according to the present disclosure comprises: a storage means including a master area and a plurality of user areas corresponding to a plurality of users; a user authentication means for authenticating each of the plurality of users; a version management means for storing in the storage means a first data set created by a user authenticated by the user authentication means and managing the version of the first data set; Equipped with the version management means associates the first data set with a second data set that is already stored in the storage means and is the immediate parent of the first data set, and stores the first data set in the master area or a user area among the plurality of user areas that corresponds to a user authenticated by the user authentication means and when the second data set is stored in the master area, the first data set is stored in a user area corresponding to a user authenticated by the user authentication means. do. Effect of the Invention

[0008] According to the present disclosure, version control can be easily performed in an environment where multiple people are developing. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram showing an overall configuration of a version control system according to a first embodiment of the present disclosure. [Diagram 2] FIG. 1 is a diagram illustrating an example of version management by a version management system according to a first embodiment of the present disclosure. [Diagram 3] FIG. 1 is a block diagram showing a functional configuration of a PLC according to a first embodiment of the present disclosure. [Figure 4] FIG. 1 is a diagram illustrating an example of a hardware configuration of a PLC according to a first embodiment of the present disclosure and a development device according to a second embodiment of the present disclosure. [Diagram 5]1 is a flowchart showing an example of a version management operation by a PLC according to the first embodiment of the present disclosure. [Figure 6] FIG. 1 is a diagram showing an overall configuration of a version control system according to a modification of the first embodiment of the present disclosure. [Figure 7] FIG. 11 is a block diagram showing a functional configuration of a development device according to a second embodiment of the present disclosure. [Figure 8] FIG. 1 is a diagram for explaining an example of distributed version management by a version management system according to a second embodiment of the present disclosure. [Figure 9] FIG. 1 is a diagram for explaining an example of distributed version management by a version management system according to a second embodiment of the present disclosure. [Figure 10] FIG. 1 is a diagram for explaining an example of distributed version management by a version management system according to a second embodiment of the present disclosure. [Figure 11] FIG. 1 is a diagram for explaining an example of distributed version management by a version management system according to a second embodiment of the present disclosure. [Figure 12] FIG. 1 is a diagram for explaining an example of distributed version management by a version management system according to a second embodiment of the present disclosure. [Figure 13] FIG. 10 is a diagram for explaining an example of distributed version management by a version management system according to a modification of the second embodiment of the present disclosure. [Figure 14] FIG. 10 is a diagram for explaining an example of distributed version management by a version management system according to a modification of the second embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, a version control system according to an embodiment of the present disclosure will be described with reference to the drawings. In each drawing, the same or equivalent parts are denoted by the same reference numerals.

[0011] (Embodiment 1) A version control system 1 according to a first embodiment will be described with reference to Fig. 1. The version control system 1 includes a PLC (Programmable Logic Controller) 10 and a plurality of development devices 20. The version control system 1 is an example of a version control system according to the present disclosure.

[0012] In the version control system 1, multiple users develop programs to be executed by the PLC 10 using their respective development devices 20. The users transmit to the PLC 10 a data set that combines the programs developed using the development devices 20 and data related to the programs. The data related to the programs includes, for example, source code that is the basis of the programs, setting files and resource files necessary for the programs, and document files that explain the specifications of the programs.

[0013] For example, a user transmits a data set to the PLC 10 each time a program change is completed. The PLC 10 executes the program contained in the data set while managing the version of the received data set. When a user transmits a data set to the PLC 10 each time a change is completed, the PLC 10 manages the version of the data set for each change.

[0014] The PLC 10 executes a program developed by a user and controls a controlled device (not shown). In addition to executing the program, the PLC 10 also performs version management of the data set as described above. The functional configuration of the PLC 10 will be described later. The PLC 10 is an example of a programmable device according to the present disclosure.

[0015] The development device 20 is used to develop a program to be executed by the PLC 10. The development device 20 is, for example, a personal computer on which an engineering tool program is installed. A user creates a data set including a program to be executed by the PLC 10 using the development device 20, and transmits the created data set to the PLC 10. The development device 20 is an example of a development device according to the present disclosure.

[0016] Next, we will explain briefly about version management in the version management system 1. In the version management system 1, program development is generally carried out according to the following flow. (1) A user creates a dataset that includes a program through development work. (2) PLC 10 authenticates the user. (3) The user sends a data set to PLC10. (4) The PLC 10 performs version control on the received data set. (5) The user executes and debugs the program contained in the data set sent to PLC10 on PLC10. (6) Make any necessary corrections and repeat steps (1) to (7). (7) Once all corrections have been made, the program is run on PLC 10 and multiple users check that it works. (8) Depending on the results of the operation check, the user repeats the steps from (1).

[0017] Of the above (1)-(8), (7) is a task performed jointly by multiple users, but the others are tasks performed individually by users. Therefore, it is preferable to manage the data set related to the individual tasks of users separately from the data set related to the collaborative tasks.

[0018] The PLC 10 manages data sets by dividing them into a master area and a user area for each user. The master area is an area accessible to any user, and the user area is an area accessible only to each user and not to other users. Data sets created by a user are stored in the user area in principle, but data sets to be shared among all users are stored in the master area based on the user's operation. Storing a data set in the master area based on the user's operation is hereinafter referred to as "applying a data set to the master area." Examples of data sets to be shared among all users include a data set that includes an executable file that has been modified by the user and is to be tested by all users in common, and a data set that includes an executable file that has reached a level that is suitable for shipping as a product.

[0019] A specific example will be described with reference to FIG. 2. The circle in FIG. 2 represents one dataset. The arrow in FIG. 2 indicates that a child dataset is created with a certain dataset as the immediate parent. When a change is made to a certain dataset and another dataset is created, the dataset before the change is the "immediate parent" and the dataset after the change is the "child." Note that dataset x1, which is the "first dataset," is created by, for example, storing a dataset in the master area when PLC 10 receives the dataset for the first time.

[0020] First, user A makes changes based on dataset x1 in the master area and sends the changed dataset to PLC 10. Hereinafter, making changes based on a dataset and sending the changed dataset to PLC 10 will be referred to as "updating." As a result of the update by user A, dataset y1, which branched off from dataset x1 in the master area, is saved in the user A area rather than the master area. Dataset x1 becomes the immediate parent of dataset y1.

[0021] When user A updates dataset y1, dataset y2, which has dataset y1 as its immediate parent, is saved in user area A. Subsequently, a similar update operation causes dataset y3, which has dataset y2 as its immediate parent, to be saved in user area A.

[0022] After that, user A applies dataset y3 to the master area, and dataset x2, which has the same contents as dataset y3, is saved in the master area with dataset x1 and dataset y3 as its immediate parents. This dataset x2 is the one to which the changes made by user A between datasets y1 and y3 have been applied. Since the ancestor of dataset y3 is dataset x1, and the latest dataset in the master area at this point is dataset x1, dataset y3 can be applied to the master area without any problems. Note that the "ancestral parent" here refers to a dataset that can be traced back one or more generations from the parent of a dataset. In the example shown in FIG. 2, dataset x1 is the "ancestral parent" of all of datasets y1, y2, and y3.

[0023] Next, the work of user B will be described. First, like user A, user B also updates dataset x1 in the master area, and dataset z1, which branches off from dataset x1 in the master area and has dataset x1 as its immediate parent, is stored in the user B area. User B then performs two updates, and dataset z2, which has dataset z1 as its immediate parent, is stored in the user B area, and dataset z3, which has dataset z2 as its immediate parent, is stored in the user area B. Note that it is assumed that user B's work up to this point has been performed before dataset x2 was stored in the master area.

[0024] After that, user B tries to apply dataset z3, which has had its changes applied, to the master area. However, because the latest dataset stored in the master area is dataset x2, not dataset x1, a conflict occurs when trying to apply dataset z3 to the master area. Therefore, it cannot be applied as is.

[0025] Therefore, user B merges dataset z3, to which user B's own latest changes have been applied, with dataset x2 in the master area, and updates it with the dataset changed in this merger. As a result, dataset z4, which has dataset z3 as its immediate parent, is saved in user area B.

[0026] Then, user B applies dataset z4 to the master area, and dataset x3, which has the same content as dataset z4, is saved in the master area with dataset x2 and dataset z4 as its immediate parents. This dataset x3 is a merge of the changes made by user B between datasets z1 to z3 and the content of dataset x2.

[0027] The PLC 10 manages data sets by dividing them into a master area and a user area, allowing the data sets to be managed on a per-user basis. This allows users to focus only on the data sets in the master area and the data sets in the user area that correspond to them when developing a program, making it easier to manage version control in an environment where multiple people are developing programs.

[0028] Next, the functional configuration of the PLC 10 will be described with reference to Fig. 3. The PLC 10 includes a storage unit 100, a communication unit 101, a user authentication unit 102, a version management unit 103, and a program execution unit 104.

[0029] The storage unit 100 stores a data set based on version management by the version management unit 103 described below. The storage unit 100 includes a master area M and a plurality of user areas U provided for each user. The storage unit 100 is an example of a storage means according to the present disclosure. The master area M is an example of a master area according to the present disclosure. The user area U is an example of a user area according to the present disclosure.

[0030] 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 a communication means according to the present disclosure.

[0031] The user authentication unit 102 authenticates a user corresponding to the development device 20 that is the communication destination of the communication unit 101. The user authentication unit 102 authenticates the user by, for example, password authentication. Alternatively, an administrator of the PLC 10 may register a user corresponding to each development device 20 in advance in the PLC 10, and the user authentication unit 102 may automatically authenticate the user by identifying the development device 20. The user authentication unit 102 is an example of a user authentication means according to the present disclosure.

[0032] The version management unit 103 performs version management of the dataset received by the communication unit 101. The version management unit 103 stores and manages the dataset by dividing it into a master area M and each user area U. The version management unit 103 stores a dataset having a dataset stored in the master area M as its immediate parent in the user area U corresponding to the user who performed the update. Therefore, the stored dataset is one that has "branched" from the dataset in the master area M. Furthermore, the version management unit 103 stores, in principle, in the user area U, a dataset having a dataset stored in the user area U as its immediate parent. Therefore, in principle, a dataset transmitted by a user is stored in the user area U.

[0033] However, when the user performs an operation to apply a dataset stored in his / her own user area U to the master area M, the version management unit 103 stores the dataset in the master area M. Note that if the ancestor of the dataset that the user is attempting to apply to the master area M is different from the latest dataset stored in the master area M, the version management unit 103 rejects the application by the user. In this case, the user needs to perform an operation to merge the latest dataset stored in the master area M with his / her own dataset.

[0034] When saving a dataset in the master area M or the user area U, the version management unit 103 saves not only the dataset body but also metadata for individually identifying the dataset and metadata indicating the immediate parent dataset of the dataset to be saved in association with the dataset body. For example, a hash value of the binary data when the dataset body is treated as one binary data can be used as the metadata. This allows the dataset to be associated with the immediate parent dataset when saved, making it possible to manage the parent-child relationship between the datasets and to perform version management of the dataset as a whole. The version management unit 103 is an example of a version management means according to the present disclosure.

[0035] The program execution unit 104 reads out the program stored in the storage unit 100 via the version management unit 103, and executes the read out program. The program execution unit 104 reads out and executes, for example, a program included in the latest data set stored in the storage unit 100. Alternatively, the program execution unit 104 may read out and execute a program included in a data set specified by the user. For example, due to the convenience of the work process, the source code may temporarily become uncompileable, resulting in a state in which no executable file exists in the latest data set. In such a case, the user needs to specify a data set in which the executable file exists.

[0036] Furthermore, the program execution unit 104 stores a log relating to the execution of the program in the storage unit 100 in association with a dataset corresponding to the executed program. The log relating to the execution of the program includes, for example, information indicating the execution date and time, information regarding events and errors that occurred during program execution, and information indicating the dataset corresponding to the executed program. For example, a user can analyze this log to evaluate the quality of the program for each dataset.

[0037] Next, an example of the hardware configuration of the PLC 10 will be described with reference to Fig. 4. The PLC 10 is a programmable logic controller, and is therefore a type of computer.

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

[0039] The processor 1001 is, for example, a CPU (Central Processing Unit). The processor 1001 loads an operating program stored in a secondary storage device 1004 into a memory 1002 and executes it, thereby implementing each function of the PLC 10. The processor 1001 may include a processor that loads and executes a data set stored in the storage unit 100, in addition to the processor that executes the operating program. In this case, the latter processor implements the function of the program execution unit 104.

[0040] The memory 1002 is a main storage device formed of, for example, a RAM (Random Access Memory). The memory 1002 stores an operating program that the processor 1001 reads from the secondary storage device 1004. The memory 1002 also functions as a working memory when the processor 1001 executes the operating program.

[0041] The interface 1003 is an I / O (Input / Output) interface such as a serial port, a USB (Universal Serial Bus) port, a network interface, etc. The interface 1003 realizes the function of the communication unit 101.

[0042] The secondary storage device 1004 is, for example, a flash memory, a hard disk drive (HDD), or a solid state drive (SSD). The secondary storage device 1004 stores the operation program executed by the processor 1001. The secondary storage device 1004 realizes the function of the storage unit 100.

[0043] Next, an example of the operation of version management by the PLC 10 will be described with reference to Fig. 5. The operation shown in Fig. 5 is executed, for example, when a user operates the development device 20 and the development device 20 starts communication to transmit a data set to the PLC 10.

[0044] The user authentication unit 102 of the PLC 10 communicates with the development device 20 and authenticates the user of the development device 20 (step S101). Through this operation, the user who transmitted the data set is identified.

[0045] When the user is authenticated, the development device 20 transmits a data set to the PLC 10, and the communication unit 101 of the PLC 10 receives the transmitted data set (step S102).

[0046] The version management unit 103 of the PLC 10 determines whether or not the user is attempting to apply a data set to the master area M (step S103).

[0047] When the user does not intend to apply a dataset to master area M (step S103: No), the version management unit 103 saves the dataset received in step S102 in the user area U corresponding to the user authenticated in step S101 (step S104). In this operation, when the immediate parent of the dataset to be saved is a dataset in master area M, the dataset to be saved becomes one that has "branched" from the dataset in master area M. Then, the PLC 10 ends the version management operation.

[0048] When a user is attempting to apply a dataset to master area M (step S103: Yes), the version management unit 103 determines whether the ancestor dataset of the dataset being applied matches the latest dataset in master area M (step S105).

[0049] When the parent dataset of the dataset to be applied matches the latest dataset in master area M (step S105: Yes), the version management unit 103 stores the dataset to be applied in master area M (step S106). Then, the PLC 10 ends the version management operation.

[0050] If the parent dataset of the dataset to be applied does not match the latest dataset in master area M (step S105: No), the version management unit 103 rejects the application of the dataset to master area M (step S107). Then, the PLC 10 ends the version management operation.

[0051] The version control system 1 according to the first embodiment has been described above. The PLC 10 of the version control system 1 stores data sets in a master area M and a user area U for each user, and performs version control. This allows a user to focus only on the data sets in the master area M and the data sets in the user area U corresponding to the user when developing a program, making it easy to perform version control in an environment where multiple people are developing the program.

[0052] (Modification of the first embodiment) In the first embodiment, as shown in Fig. 6, the PLC 10 may be communicably connected to the external system 30, and the version management unit 103 of the PLC 10 may transmit the data set stored in the storage unit 100 to the external system 30 at a predetermined timing to back it up. The backup may be performed when a new data set is added, or may be performed periodically.

[0053] Also, the development device 20, instead of the PLC 10, may be communicatively connected to the external system 30, and the development device 20 may take a backup by reading out a data set stored in the storage unit 100 of the PLC 10 and transmitting it to the external device 30. For example, this form can be adopted when the development device 20 can connect to the Internet but the PLC 10 cannot.

[0054] In the first embodiment, each user can access the data set in the user area U corresponding to the user, but cannot access the data sets in the user area U corresponding to other users. Here, instead of simply making the data sets inaccessible, the data sets in each user area U may be encrypted with an encryption key corresponding to each user.

[0055] Furthermore, the data set in the master area M may be encrypted with an encryption key unique to the PLC 10. This prevents anyone who does not own the PLC 10 from decrypting the data set in the master area M, so that even if the data set stored in the master area M is leaked for some reason, it is possible to prevent a third party from learning the contents of the data set.

[0056] In the first embodiment, the user can apply the dataset in the user area U to the master area M at any timing as long as it does not conflict with the latest dataset in the master area M. On the other hand, if the dataset continues to be updated without being applied to the master area M at all, the discrepancy between the contents of the dataset in the master area M and the contents of the dataset in the user area U may become large, which may cause problems in development. Therefore, for example, the version management unit 103 may issue a warning to the user when the updates of the dataset in the user area U continue for a certain number of times or more. For example, the version management unit 103 transmits data indicating a warning to the development device 20 via the communication unit 101, and the development device 20 notifies the user of the warning.

[0057] (Embodiment 2) The version control system 1 according to the second embodiment will be described below. The overall configuration of the version control system 1 according to the second embodiment is similar to that of the first embodiment shown in Fig. 1. The second embodiment differs from the first embodiment in that the development device 20 also performs version management of the data set.

[0058] This eliminates the need for the user to transmit a data set to the PLC 10 every time a change is made. For example, the user may change a data set multiple times, and after completing all the change work, transmit the multiple data sets corresponding to the multiple changes to the PLC 10 all at once.

[0059] 2, in the first embodiment, user A updated the data sets y1, y2, and y3 by transmitting each of the data sets to the PLC 10 each time. On the other hand, in the second embodiment, once user A has acquired data set x1, he or she can make changes to the data sets y1, y2, and y3 without communicating with the PLC 10, and can transmit the data sets y1, y2, and y3 together to the PLC 10 and apply the data set y3 to the master domain M.

[0060] The functional configuration of the development device 20 according to the second embodiment will be described with reference to Fig. 7. The development device 20 according to the second embodiment includes a storage unit 200, a communication unit 201, a data set creation unit 202, and a version management unit 203.

[0061] The storage unit 200 stores a data set based on version management by a version management unit 203 described later. The storage unit 200 includes a master 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.

[0062] The communication unit 201 communicates with the PLC 10. Based on the control of a version management unit 203 described later, the communication unit 201 transmits a data set created by a user via the development device 20 to the PLC 10, and receives a data set stored in the storage unit 100 from the PLC 10. The communication unit 201 is realized by, for example, a network interface.

[0063] The data set creation unit 202 creates a program to be executed by the PLC 10 and data related to the program based on a user's operation via an input device (not shown). That is, the data set creation unit 202 creates a data set based on the user's operation. The data set creation unit 202 has a function of an editor for writing, for example, source code, setting files, documents, and the like.

[0064] The version management unit 203 stores the dataset created by the dataset creation unit 202 in a user area U of the storage unit 200 and performs version management. When saving a dataset, the version management unit 203, like the version management unit 103 of the PLC 10, saves not only the dataset itself but also metadata for individually identifying the dataset and metadata indicating the nearest parent dataset of the dataset to be saved, in association with the dataset itself. This allows the version management of the dataset created by the user in the development device 20.

[0065] The version management unit 203 collectively transmits one or more data sets that have not yet been transmitted to the PLC 10, among the data sets stored in the user area U of the storage unit 200, to the PLC 10 via the communication unit 201. This allows the contents of changes made by the user in the development device 20 to be synchronized with the PLC 10.

[0066] The version management unit 203 acquires, via the communication unit 201, one or more data sets that are not stored in the master area M of the storage unit 200, among the data sets stored in the master area M of the storage unit 100 of the PLC 10, and stores the data sets in the master area M of the storage unit 200. This makes it possible to synchronize changes made to the master area M of the PLC 10 with the development device 20.

[0067] Here, the PLC 10 according to the second embodiment will be described in terms of differences from the first embodiment. As described above, the development device 20 according to the second embodiment can transmit a plurality of data sets to the PLC 10. Also, as described above, the development device 20 according to the second embodiment acquires a data set in the master area M from the PLC 10. Therefore, the version management unit 103 according to the second embodiment also corresponds to this. The version management unit 103 according to the second embodiment receives a plurality of data sets collectively from the development device 20, and collectively stores the received data sets in the user area U of the storage unit 100. The version management unit 103 according to the second embodiment transmits one or more data sets in the master area M to the development device 20 in response to a request from the development device 20.

[0068] The function of the version management unit 203 of the development device 20 and the function of the version management unit 103 of the PLC 10 enable the PLC 10 and the development device 20 to individually manage the versions of data sets, while synchronizing the PLC 10 and the development device 20 as necessary. Therefore, the version management system 1 according to the second embodiment can realize distributed version management.

[0069] A specific example will be described below with reference to the drawings. It is assumed that initially, only data set x1 is stored in storage unit 100 of PLC 10, and no data set is stored in storage unit 200 of development device 20.

[0070] First, based on a user operation, the version management unit 203 of the development device 20 acquires the data set x1 stored in the storage unit 100 from the PLC 10 and stores it in the master area M of the storage unit 200. As a result, the data set x1 is also stored in the master area M of the storage unit 200 of the development device 20, as shown in FIG.

[0071] Next, the user of the development device 20 performs a change operation on the data set x1. This causes the data set creation unit 202 of the development device 20 to create a new data set, and as shown in Fig. 9, the version management unit 203 stores the new data set as data set y1 in the user area U of the storage unit 200. At this point, there is no particular change in the storage unit 100 of the PLC 10, because there is no communication between the PLC 10 and the development device 20.

[0072] Thereafter, the user performs two changes, and the data sets y2 and y3 are stored in the user area U of the storage unit 200, as shown in Fig. 10. Even at this point, there are no particular changes in the storage unit 100 of the PLC 10.

[0073] Next, based on a user operation, the version management unit 203 collectively transmits the data sets y1, y2, and y3 stored in the user area U of the storage unit 200 to the PLC 10. The version management unit 103 of the PLC 10 stores the received data sets y1, y2, and y3 in the user area U of the storage unit 100, as shown in Fig. 11. It is only at this point that synchronization can be achieved between the development device 20 and the PLC 10.

[0074] Then, the user performs an operation to apply the data set y3 to the master area M of the storage unit 100 of the PLC 10, whereby a data set x2 having the same contents as the data set y3 is stored in the master area M of the storage unit 100. The version management unit 203 of the development device 20 then acquires the data set x2 stored in the master area M of the storage unit 100 from the PLC 10, and stores it in the master area M of the storage unit 200. This makes it possible for both the PLC 10 and the development device 20 to manage the versions of the data sets x1, x2, y1, y2, and y3, as shown in FIG.

[0075] As illustrated by the data sets z3, x2, z4, and x3 in FIG. 2, when a data set in the user area U is applied to the master area M, a conflict may occur and the data set cannot be applied as it is. In that case, first, the version management unit 203 of the development device 20 acquires the data set stored in the master area M of the storage unit 100 from the PLC 10 and stores it in the master area M of the storage unit 200. Next, the user performs a merge operation on the data set stored in the master area M of the storage unit 200, the data set creation unit 202 creates a data set, and the version management unit 203 stores the data set in the user area U of the storage unit 200. Then, the version management unit 203 transmits the new data set stored in the user area U of the storage unit 200 to the PLC 10, and the version management unit 103 of the PLC 10 stores the received data set in the user area U of the storage unit 100. After that, the user may try to apply the data set in the user area U to the master area M again.

[0076] As in the first embodiment, the program execution unit 104 of the PLC 10 executes the program included in the data set stored in the storage unit 100. Therefore, the user can easily manage the consistency between the source code subject to version management and the program executed by the PLC 10.

[0077] The hardware configuration of the development device 20 according to the second embodiment is generally similar to that shown in Fig. 4. This is because, as described in the first embodiment, the development device 20 is, for example, a personal computer in which an engineering tool program is installed.

[0078] The version control system 1 according to the second embodiment has been described above. According to the version control system 1 according to the second embodiment, the PLC 10 and the development device 20 can individually perform version control of data sets, while the PLC 10 and the development device 20 can be synchronized as necessary. Therefore, the version control system 1 according to the second embodiment can realize distributed version control. As in the first embodiment, the PLC 10 executes a program included in a data set stored in the storage unit 100, so that a user can easily manage the consistency between the source code that is the subject of version control and the program executed by the PLC 10. Therefore, according to the version control system 1 according to the second embodiment, data related to a programmable device can be easily distributed version controlled.

[0079] Furthermore, by managing the datasets separately in the master area M and the user area U, when a user attempts to merge datasets created by the user, the user checks the dataset in the user area U and the dataset in the master area M and makes a decision before merging. Therefore, by managing the datasets separately in the master area M and the user area U, a natural opportunity for decision-making is provided without placing a large burden on the user when merging, and it is possible to prevent datasets from being unintentionally merged. For example, it is possible to prevent a dataset that has not yet been debugged from being unintentionally merged.

[0080] (Modification of the second embodiment) Since the second embodiment is a modification of the first embodiment, it is assumed that there are multiple users, as in the first embodiment. On the other hand, in the second embodiment, even if there is only one user, it is possible to perform distributed version management of a data set between the user's development device 20 and the PLC 10. In this case, the storage unit 100 of the PLC 10 has a master area M and one user area U. Also, the PLC 10 does not necessarily need to include a user authentication unit 102.

[0081] In the second embodiment, a configuration may be considered in which the data set is managed in one area, rather than being divided into the master area M and the user area U. In this configuration, an example will be described below in which a plurality of users create data sets in each development device 20, and the created data sets are transmitted to the PLC 10 for updating.

[0082] As shown in FIG. 13, consider a case where user A and user B perform development using each development device 20 based on a data set x1 stored in the storage unit 100 of the PLC 10. User A creates data sets y1, y2, and y3, and user B creates data sets z1 and z2. Next, user A updates the data set before user B, and then user B updates the data set. In this case, as shown in FIG. 14, data sets y1, y2, and y3 of user A who updated the data set first are stored as they are in the storage unit 100 of the PLC 10. The line in which data sets x1, y1, y2, and y3 are stored is a so-called "master line." Then, data sets z1 and z2 of user B who updated the data set later are stored in the storage unit 100 of the PLC 10 in a form branched from the master line. In this way, by applying the update of the data set on a "first come, first served" basis and storing the data set that was not updated first in a form branched from the master line, distributed version management by multiple users can be realized without dividing into a master area M and a user area U. Incidentally, merging of y3 and z2 is possible as in the first and second embodiments.

[0083] Furthermore, in the second embodiment, if a dataset that has not been merged into the master area M for a long period of time exists in the user area U, a warning email may be sent to the user. The warning email may be sent to the user based on information used for authentication, for example, when the user is authenticated by the user authentication unit 102. It is highly likely that a dataset that has not been merged into the master area M for a long period of time has become significantly different from the dataset in the master area M, so it is useful to send a warning.

[0084] (Other variations) In the above-described embodiments, the PLC 10 performs version management of the data set. However, programmable devices other than a PLC can also perform version management by providing functional units similar to the functional units of the PLC 10. For example, in the development of a program executed by a motion unit, if the motion unit has functional units similar to the functional units of the PLC 10, the data set related to the program executed by the motion unit can be version-managed.

[0085] 4, the PLC 10 and the development device 20 are equipped with a secondary storage device 1004. However, the present invention is not limited to this, and the secondary storage device 1004 may be provided outside the PLC 10 and the development device 20, and the PLC 10 and the development device 20 may be connected to the secondary storage device 1004 via an interface 1003. In this configuration, removable media such as a USB flash drive and a memory card can also be used as the secondary storage device 1004.

[0086] 4, the PLC 10 and the development device 20 may be configured by a dedicated circuit using an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), etc. In the hardware configuration shown in FIG. 4, some of the functions of the PLC 10 and the development device 20 may be realized by a dedicated circuit connected to the interface 1003, for example.

[0087] The programs used in the PLC 10 and the development device 20 can be distributed by storing them in computer-readable recording media such as CD-ROMs (Compact Disc Read Only Memory), DVDs (Digital Versatile Discs), USB flash drives, memory cards, HDDs, etc. By installing such programs in a specific or general-purpose computer, the computer can function as the PLC 10 and the development device 20.

[0088] Furthermore, the above-mentioned program may be stored in a storage device owned by another server on the Internet, and the above-mentioned program may be downloaded from that server.

[0089] Various embodiments and modifications of the present disclosure are possible without departing from the broad spirit and scope of the present disclosure. The above-described embodiments are for explaining the present disclosure and do not limit the scope of the present disclosure. In other words, the scope of the present disclosure is indicated by the claims, not the embodiments. Various modifications made within the scope of the claims and within the scope of the disclosure equivalent thereto are considered to be within the scope of the present disclosure. [Explanation of symbols]

[0090] 1 version control system, 10 PLC, 20 development device, 30 external system, 100 memory unit, 101 communication unit, 102 user authentication unit, 103 version control unit, 104 program execution unit, 200 memory unit, 201 communication unit, 202 dataset creation unit, 203 version control unit, 1000 bus, 1001 processor, 1002 memory, 1003 interface, 1004 secondary storage device, M master area, U user area.

Claims

1. Storage means including a master area and a plurality of user areas corresponding to a plurality of users User authentication means for authenticating each user of the plurality of users Version management means for storing and version-managing a first data set created by a user authenticated by the user authentication means in the storage means Comprising The version management means associates the first data set with a second data set already stored in the storage means and being the immediate parent of the first data set, and stores it in the user area corresponding to the user authenticated by the user authentication means among the master area or the plurality of user areas. When the second data set is stored in the master area, the first data set is stored in the user area corresponding to the user authenticated by the user authentication means A programmable device

2. The version management means further transmits the first data set stored in the storage means to an external system at a predetermined timing to back up the first data set The programmable device according to claim 1

3. The data sets stored in each of the plurality of user areas corresponding to the plurality of users are accessible only by the user corresponding to the user area The programmable device according to claim 1

4. A programmable device according to any one of claims 1 to 3 A plurality of development devices corresponding to the plurality of users Comprising Each of the plurality of development devices transmits the first data set created by the user The programmable device further comprises communication means for receiving the first data set from each of the plurality of development devices A version management system

5. A version management method executed by a programmable device comprising storage means including a master area and a plurality of user areas corresponding to a plurality of users, the method comprising: Authenticating each user of the plurality of users The first data set created by the authenticated user is associated with a second data set already stored in the storage means, which is the second data set that is the most recent parent of the first data set, and is stored in the user area corresponding to the authenticated user among the master area or the plurality of user areas. When the second data set is stored in the master area, the first data set is stored in the user area corresponding to the authenticated user for version management. Version management method.

6. A computer comprising storage means including a master area and a plurality of user areas corresponding to a plurality of users, user authentication means for authenticating each user of the plurality of users, version management means for storing and version managing a first data set created by a user authenticated by the user authentication means in the storage means, functioning as, The version management means associates the first data set with a second data set already stored in the storage means, which is the second data set that is the most recent parent of the first data set, and stores it in the user area corresponding to the user authenticated by the user authentication means among the master area or the plurality of user areas. When the second data set is stored in the master area, the first data set is stored in the user area corresponding to the user authenticated by the user authentication means. Program.

Images