Programmable device, development device, version management system, version management method, and program

Abstract

A PLC (10) is provided with: a storage unit (100) that stores a first data set; a version management unit (103) that performs version management on the first data set stored in the storage unit (100); and a communication unit (101) that transmits, to the development device, the first data set that has been edited by the edition management unit (103), and that receives a second data set that has been edited in association with the first data set by the development device, said second data set being created on the basis of the transmitted first data set. The version management unit (103) stores the second data set received by the communication unit (101) in the storage unit (100) in association with the first data set, and performs version management in association with the first data set.

Description

Technical Field

[0001] The present invention relates to a programmable device, a development apparatus, a version management system, a version management method and a program. Background Art

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

[0003] As a technology related to the above situation, for example, Non-Patent Document 1 discloses a technology for assisting control software development performed by multiple people using Git, an open source distributed version management system.

[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 management system. Therefore, it is necessary to manually manage the compatibility between the source code managed by the distributed version management system and the program executed by the programmable device, which places a heavy burden on users. For example, there is a possibility that the program executed by the programmable device is not generated based on the source code managed by the distributed version management system.

[0006] In view of the above circumstances, an object of the present invention is to provide a programmable device and the like that can easily perform distributed version management on data related to the programmable device.

[0007] In order to achieve the above object, the programmable device according to the present invention has:

[0008] a first storage unit for storing the first data set;

[0009] a first version management unit configured to perform version management on the first data set stored in the first storage unit;

[0010] a first sending unit configured to send the first data set version-managed by the first version management unit to a development device; and

[0011] a first receiving unit for receiving a second data set, the second data set being created based on the first data set sent by the first sending unit and version-managed by the development device in association with the first data set;

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

[0013] Effects of the Invention

[0014] According to the present invention, distributed version management of data related to programmable devices can be easily performed. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 This is a diagram showing the overall configuration of the version management system according to the first embodiment of the present invention.

[0016] Figure 2 This is a diagram showing an example of version management implemented by the version management system according to the first embodiment of the present invention.

[0017] Figure 3 This is a block diagram showing the functional configuration of the PLC according to the first embodiment of the present invention.

[0018] Figure 4 This is a diagram showing an example of the hardware configuration of the PLC according to the first embodiment of the present invention and the development device according to the second embodiment of the present invention.

[0019] Figure 5 This is a flowchart showing an example of the operation of version management implemented by the PLC according to the first embodiment of the present invention.

[0020] Figure 6 This is a diagram showing the overall configuration of a version management system according to a modified example of the first embodiment of the present invention.

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

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

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

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

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

[0026] Figure 12 This is a diagram illustrating an example of distributed version management implemented by the version management system according to the second embodiment 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 modified example 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 modified example of Embodiment 2 of the present invention. DETAILED DESCRIPTION

[0029] Below, with reference to the attached Figure 1 The version management system according to the embodiment of the present invention will be described. In the drawings, the same or equivalent parts are denoted by the same reference numerals.

[0030] (Implementation 1)

[0031] While referring to Figure 1 Next, a version management system 1 according to Embodiment 1 will be described. The version management system 1 includes a PLC (Programmable Logic Controller) 10 and a plurality of development devices 20. The version management system 1 is an example of a version management system according to the present invention.

[0032] In the version management system 1, multiple users develop programs executed by the PLC 10 using development devices 20. Each user sends a data set to the PLC 10 that aggregates the programs developed by the development devices 20 and data related to the programs. The data related to the programs includes, for example, the source code that forms the source of the programs, setting files and resource files required for the programs, and document files that describe the program specifications.

[0033] For example, each time a user completes a program modification, they send a data set to the PLC 10. The PLC 10 performs version management on the received data set while executing the program contained in the data set. If a user sends a data set to the PLC 10 each time a modification is completed, the PLC 10 performs version management on the data set each time the modification is completed.

[0034] The PLC 10 executes user-developed programs to control controlled devices (not shown). In addition to executing programs, the PLC 10 also performs version management on data sets, as described above. The functional structure of the PLC 10 will be described later. The PLC 10 is an example of a programmable device according to the present invention.

[0035] Development device 20 is used to develop programs executed by PLC 10. Development device 20 is, for example, a personal computer with an engineering design tool installed. A user uses development device 20 to create a data set containing a program executed by PLC 10 and transmits the created data set to PLC 10. Development device 20 is an example of a development device according to the present invention.

[0036] Next, the version management in the version management system 1 will be briefly described. In the version management system 1, program development is performed roughly according to the following flow.

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

[0038] (2) The PLC 10 authenticates the user.

[0039] (3) The user sends a data set to the PLC 10.

[0040] (4) The PLC 10 performs version management on the received data set.

[0041] (5) The user executes the program included in the data set sent to the PLC 10 on the PLC 10 to perform debugging work.

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

[0043] (7) After all modification work is completed, the program is executed on the PLC 10 and the operation is confirmed by multiple users.

[0044] (8) Based on the result of the action confirmation, the user repeats the operation from (1).

[0045] Among the above (1) to (8), (7) is a task performed jointly by multiple users, and the others are tasks performed by individual users. Therefore, it is sufficient to manage the data sets related to the individual tasks and the data sets related to the joint tasks separately.

[0046] The PLC 10 manages datasets by dividing them into a main area and a user area for each user. The main area is an area that can be accessed by all users, while the user area is an area that can only be accessed by a certain user and is inaccessible to other users. In principle, datasets created by users are stored in the user area. However, datasets that should be shared among all users are stored in the main area based on user operations. Hereinafter, the situation where a dataset is stored in the main area based on user operations is referred to as "applying the dataset to the main area." Examples of datasets that should be shared among all users include datasets containing executable files that should be tested jointly by all users after all changes made by users are completed, and datasets containing executable files that have reached a deliverable level for products.

[0047] While referring to Figure 2 A specific example will be described. Figure 2 The circle shown represents 1 data set. Figure 2 The arrows shown indicate the creation of child datasets using a dataset as the most recent parent. When a dataset is modified and another dataset is created, the dataset before the modification is the "most recent parent," and the dataset after the modification is the "child." The dataset x1, the "initial dataset," is created, for example, by saving the dataset in the master area when the PLC 10 first receives it.

[0048] First, user A modifies dataset x1 in the master area and sends the modified dataset to PLC 10. Hereinafter, performing a dataset modification and sending the modified dataset to PLC 10 is referred to as "updating." User A's update causes dataset y1, which branches from dataset x1 in the master area, to be stored in user A's area instead of the master area. Dataset x1 is now the most recent parent of dataset y1.

[0049] When user A updates dataset y1, dataset y2 having dataset y1 as its most recent parent is stored in user area A. Next, dataset y3 having dataset y2 as its most recent parent is stored in user area A through the same updating operation.

[0050] Then, user A applies dataset y3 to the master area, so that dataset x2 with the same content as dataset y3 is saved in the master area with dataset x1 and dataset y3 as the most recent parents. The content of the change operation performed by user A between datasets y1 and y3 is applied to dataset x2. The root parent of dataset y3 is dataset x1, and the latest dataset in the master area at that time is dataset x1. Therefore, dataset y3 can be applied to the master area without any problems. In addition, the "root parent" mentioned here refers to the dataset that is traced back to the parent of the dataset by more than one generation. Figure 2 In the example shown, data set x1 becomes the "root parent" with respect to each of data sets y1, y2, and y3.

[0051] Next, we will explain user B's work. First, similar to user A, user B updates dataset x1 in the master area. This causes dataset z1, which branches from dataset x1 in the master area and has dataset x1 as its most recent parent, to be stored in user B's area. User B then performs two updates: dataset z2, with dataset z1 as its most recent parent, is stored in user B's area, and dataset z3, with dataset z2 as its most recent parent, is stored in user B's area. User B's work up to this point was performed before dataset x2 was stored in the master area.

[0052] Next, user B attempts to apply dataset z3, after applying the changes to it, to the master zone. However, the latest dataset stored in the master zone is not dataset x1 but dataset x2. Therefore, applying dataset z3 to the master zone will result in a conflict, preventing it from being applied directly.

[0053] Therefore, user B merges dataset z3, to which user B's latest modification has been applied, with dataset x2 in the master area, thereby updating the dataset with the modified dataset.

[0054] User B then applies dataset z4 to the master area. This causes dataset x3, which has the same content as dataset z4, to be stored in the master area, with datasets x2 and z4 as its closest parents. This dataset x3 is a result of merging the content of datasets z1 through z3, modified by user B, with the content of dataset x2.

[0055] The PLC 10 manages datasets by dividing them into a master area and a user area, enabling data set management on a per-user basis. This allows users to focus only on the master area dataset and their own corresponding user area dataset when developing programs. This facilitates version management in environments with multiple developers.

[0056] Next, refer to Figure 3 Next, the functional configuration of the PLC 10 will be described. 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 .

[0057] The storage unit 100 stores data sets based on version management implemented by a version management unit 103 described later. The storage unit 100 includes a main area M and a plurality of user areas U provided for each user. The storage unit 100 is an example of a first storage unit according to 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 transmission unit and the first reception unit according to the present invention.

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

[0060] The version management unit 103 performs version management on the datasets received by the communication unit 101. The version management unit 103 manages the datasets by storing them separately in the master area M and in each user area U. The version management unit 103 stores the dataset whose most recent parent is the dataset stored in the master area M in the user area U corresponding to the user who updated the dataset. Therefore, the dataset to be stored is a dataset that "branched" from the dataset in the master area M. Furthermore, in principle, the version management unit 103 stores the dataset whose most recent parent is the dataset stored in the user area U in the user area U. Therefore, in principle, datasets sent by users are stored in the user area U.

[0061] However, when a user applies a dataset stored in their user area U to the master area M, the version management unit 103 stores the dataset in the master area M. Furthermore, if the root parent of the dataset the user wants 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 user's application. In this case, the user needs to merge the latest dataset stored in the master area M with their own dataset.

[0062] When saving a dataset in the main area M or user area U, the version management unit 103 not only saves the dataset body but also stores metadata that independently identifies the dataset and metadata representing the dataset's most recent parent, in association with the dataset body. Metadata such as the hash value of a single binary data set can be used. This allows for association with the dataset's most recent parent dataset when the dataset is saved, thereby managing parent-child relationships between datasets and enabling 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 a 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 read and execute a program contained in a dataset specified by the user. For example, due to operational process issues, the source code may be temporarily unable to compile, resulting in an executable file not existing in the latest dataset. In such cases, the user must specify a dataset where the executable file exists.

[0064] In addition, the program execution unit 104 stores logs related to program execution and data sets corresponding to the executed programs in association with each other in the storage unit 100. The logs related to program execution include, for example, information indicating the execution date and time, information regarding events and errors generated during program execution, and information indicating data sets corresponding to the executed programs. For example, users can analyze these logs to evaluate the quality of the programs for each data set.

[0065] Next, refer to Figure 4 An example of the hardware configuration of the PLC 10 will be described. The PLC 10 is a programmable logic controller and is 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 , which are connected to one another via a bus 1000 .

[0067] The processor 1001 is, for example, a CPU (Central Processing Unit). The processor 1001 reads an operating program stored in the secondary storage device 1004 into the memory 1002 and executes the operating program, thereby implementing the various functions of the PLC 10. Furthermore, in addition to the processor that executes the operating program, the processor 1001 may also include a processor that reads and executes a data set 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 a main storage device composed of, for example, a RAM (Random Access Memory). The memory 1002 stores the operating program read by the processor 1001 from the secondary storage device 1004. The memory 1002 also functions as a working memory when the processor 1001 executes the operating program.

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

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

[0071] Next, refer to Figure 5 An example of the version management operation implemented by the PLC 10 will be described. Figure 5 The illustrated operation is executed, for example, when the user operates the development device 20 and the development device 20 starts communication in order to transmit a data set to the PLC 10 .

[0072] 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). This operation identifies the user who has sent the data set.

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

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

[0075] If the user does not wish to apply the dataset to the main 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, if the most recent parent of the saved dataset is a dataset existing in the main area M, the saved dataset is a dataset "branched" from the dataset in the main area M. The PLC 10 then terminates the version management operation.

[0076] When the user wants to apply a dataset to the master area 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 master area M (step S105 ).

[0077] If the root parent dataset of the dataset to be applied matches the latest dataset in the master area M (step S105: Yes), the version management unit 103 stores the dataset to be applied in the master area M (step S106). The PLC 10 then terminates the version management operation.

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

[0079] The above describes the version management system 1 according to Embodiment 1. The PLC 10 in the version management system 1 manages versions by storing data sets separately in a master area M and a user area U for each user. This allows users to focus only on the data sets in the master area M and their own user area U when developing a program, making version management easier in environments with multiple developers.

[0080] (Variation of Embodiment 1)

[0081] In embodiment 1, it is also possible to Figure 6 As shown, the PLC 10 is communicatively connected to the external system 30. The version management unit 103 of the PLC 10 sends the data set stored in the storage unit 100 to the external system 30 at a predetermined timing to perform a backup. The backup timing can be when a new data set is added or can be performed regularly.

[0082] Alternatively, the development device 20, rather than the PLC 10, may be communicatively connected to the external system 30, and the backup may be performed by reading the data set stored in the storage unit 100 of the PLC 10 from the development device 20 and sending it to the external device 30. This method can be used, for example, when the development device 20 can connect to the Internet but the PLC 10 cannot.

[0083] In the first embodiment, each user can access the data set corresponding to their own user area U, but cannot access the data sets corresponding to other users' user areas U. This does not simply mean that the data set in each user area U is not accessible, but rather that the data set in each user area U is encrypted using an encryption key corresponding to each user.

[0084] Alternatively, the data set in the main area M may be encrypted using an encryption key inherent to the PLC 10. This prevents a person who does not own the PLC 10 from decrypting the data set in the main area M. Therefore, even if the data set stored in the main area M is leaked for some reason, the contents of the data set cannot be known to a third party.

[0085] In the first embodiment, the user can apply the dataset in the user area U to the master area M at any time, as long as it does not conflict with the latest dataset in the master area M. On the other hand, if datasets are continuously updated without being applied to the master area M, the discrepancy between the content of the dataset in the master area M and the dataset in the user area U will increase, potentially hindering development. Therefore, for example, the version management unit 103 may issue a warning to the user if dataset updates continue in the user area U for a certain number of times or more. For example, the version management unit 103 transmits data indicating the warning 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 following describes the version management system 1 according to the second embodiment. Figure 1 The configuration is the same as that of the embodiment 1. The second embodiment is different from the first embodiment in that the development device 20 also performs version management of the data set.

[0088] Thus, the user does not need to send a data set to the PLC 10 every time a change is made. For example, the user may make multiple changes to a data set, and after all changes are completed, send the multiple data sets corresponding to the multiple changes to the PLC 10 in a bundle.

[0089] For example, in Figure 2In the example shown, in Embodiment 1, user A updates the datasets by sending each dataset y1, y2, and y3 to the PLC 10 individually. In Embodiment 2, on the other hand, if user A obtains dataset x1, after obtaining dataset x1, they can modify datasets y1, y2, and y3 without communicating with the PLC 10. They can then collectively send datasets y1, y2, and y3 to the PLC 10 and apply dataset y3 to the master area M.

[0090] While referring to Figure 7 Next, the functional configuration of the development device 20 according to Embodiment 2 will be described. The development device 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 data sets based on version management implemented by the version management unit 203 (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 a single area corresponding to the user of the development device 20. The storage unit 200 is an example of the second storage unit of the present invention.

[0092] The communication unit 201 communicates with the PLC 10. Under the control of the version management unit 203 (described later), the communication unit 201 transmits data sets created by the user via the development device 20 to the PLC 10 and receives data sets stored in the storage unit 100 from the PLC 10. The communication unit 201 is implemented, for example, by a network interface. The communication unit 201 is an example of the second receiving unit and the second sending unit of the present invention.

[0093] The dataset creation unit 202 creates a program executed by the PLC 10 and data related to the program based on user operations performed via an input device (not shown). Specifically, the dataset creation unit 202 creates a dataset based on user operations. For example, the dataset creation unit 202 functions as an editor for describing source code, setting files, documents, and the like. The dataset creation unit 202 is an example of a dataset creation unit according to the present invention.

[0094] The version management unit 203 stores the dataset created by the dataset creation unit 202 in the user area U of the storage unit 200 to perform version management. When saving a dataset, the version management unit 203, like the version management unit 103 of the PLC 10, not only stores the dataset itself but also stores metadata that uniquely identifies the dataset and metadata indicating the dataset's closest parent, in association with the dataset itself. This allows version management of user-created datasets within the development device 20.

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

[0096] The version management unit 203 obtains, via the communication unit 201, one or more data sets from the data sets stored in the main area M of the storage unit 100 of the PLC 10 that are not stored in the main area M of the storage unit 200, and stores them in the main area M of the storage unit 200. This allows changes to the main area M of the PLC 10 to be synchronized with the development device 20. The 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 according to the second embodiment and the first embodiment are described. As described above, the development device 20 according to the second embodiment can send multiple data sets to the PLC 10. In addition, as described above, the development device 20 according to the second embodiment obtains the data set of 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 multiple data sets from the development device 20 in a batch and stores the received data sets in a batch in the user area U of the storage unit 100. In response to the request of the development device 20, the version management unit 103 according to the second embodiment sends one or more data sets of the master area M to the development device 20.

[0098] The functions of the version management unit 203 of the development device 20 and the version management unit 103 of the PLC 10 enable independent version management of data sets in the PLC 10 and the development device 20, and synchronization between the PLC 10 and the development device 20 as needed. Therefore, the version management system 1 according to the second embodiment enables distributed version management.

[0099] Below, with reference to the attached Figure 1 A specific example will be described. First, it is assumed that only the data set x1 is stored in the storage unit 100 of the PLC 10 and no data set is stored in the storage unit 200 of the development device 20 .

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

[0101] Next, the user of the development device 20 performs a modification operation on the dataset x1. As a result, the dataset creation unit 202 of the development device 20 creates a new dataset, such as Figure 9 As shown, 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 in time, the PLC 10 and the development device 20 are not communicating, so the storage unit 100 of the PLC 10 has not changed in particular.

[0102] Then, the user performs two change operations, such as Figure 10 As shown, the data sets y2 and y3 are stored in the user area U of the storage unit 200. At this point in time, the storage unit 100 of the PLC 10 has not undergone any particular changes.

[0103] Next, based on the user's operation, the version management unit 203 sends 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 Figure 11 As shown, the received data sets y1, y2, and y3 are stored in the user area U of the storage unit 100. At this point in time, synchronization between the development device 20 and the PLC 10 is achieved.

[0104] Then, the user applies the dataset y3 to the main area M of the storage unit 100 of the PLC 10, and the dataset x2 having the same contents as the dataset y3 is stored in the main area M of the storage unit 100. The version management unit 203 of the development device 20 then obtains the dataset x2 stored in the main area M of the storage unit 100 from the PLC 10 and stores it in the main area M of the storage unit 200. Figure 12 As shown, both the PLC 10 and the development device 20 can perform version management on the data sets x1, x2, y1, y2, and y3.

[0105] In addition, if Figure 2As illustrated by the datasets z3, x2, z4, and x3 shown, sometimes a conflict arises when attempting to apply a dataset in the user area U to the main area M, preventing direct application. In such cases, the version management unit 203 of the development device 20 first retrieves the dataset stored in the main area M of the storage unit 100 from the PLC 10 and stores it in the main area M of the storage unit 200. Next, the user performs a merge operation on the datasets stored in the main area M of the storage unit 200. The dataset creation unit 202 creates a dataset, and the version management unit 203 stores the dataset in the user area U of the storage unit 200. The version management unit 203 then sends the new dataset 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 dataset in the user area U of the storage unit 100. The user can then attempt to apply the dataset in the user area U to the main area M again.

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

[0107] In addition, the hardware structure of the development device 20 involved in the second embodiment is the same as that of the Figure 4 The structures shown are substantially the same. 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.

[0108] The version management system 1 involved in the second embodiment has been described above. According to the version management system 1 involved in the second embodiment, it is possible to perform version management on the data set separately in the PLC 10 and the development device 20, and to achieve synchronization between the PLC 10 and the development device 20 as needed. Therefore, according to the version management system 1 involved in the second embodiment, distributed version management can be implemented. In addition, similarly to the first embodiment, the PLC 10 executes the program included in the data set stored in the storage unit 100, so that 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, according to the version management system 1 involved in the second embodiment, it is possible to easily perform distributed version management on data related to programmable devices.

[0109] Furthermore, by managing datasets separately in the main area M and the user area U, when a user wishes to merge created datasets, they can simply check the datasets in the user area U and the main area M, and after making a decision, merge them. Therefore, by managing datasets separately in the main area M and the user area U, the merge is performed without placing a heavy burden on the user, allowing for a natural decision-making process and preventing datasets from being accidentally merged. For example, this can prevent datasets that have not yet been fully debugged from being accidentally merged.

[0110] (Variation of Embodiment 2)

[0111] Embodiment 2 is a variation of Embodiment 1. Similarly to Embodiment 1, multiple users are involved. However, even with a single user, distributed version management of data sets is possible across the user's development device 20 and the PLC 10. In this case, the storage unit 100 of the PLC 10 includes a main area M and a single user area U. Furthermore, the PLC 10 does not necessarily need to include the user authentication unit 102.

[0112] In the second embodiment, a method is also conceivable in which datasets are managed in a single area, rather than being divided into a master area M and a user area U. The following describes an example in which multiple users create datasets using development devices 20 and transmit the created datasets to the PLC 10 for updating.

[0113] like Figure 13 As shown in FIG. 1 , consider a case where user A and user B develop data using development devices 20 based on data set x1 stored in storage unit 100 of 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 earlier than user B, and then user B updates the data set. In this case, as Figure 14 As shown, datasets y1, y2, and y3 of user A, who updated the datasets first, are stored intact in the storage unit 100 of the PLC 10. The line storing datasets x1, y1, y2, and y3 is the so-called "main line." Then, datasets z1 and z2 of user B, who later updated the datasets, are stored in the storage unit 100 of the PLC 10 as branches from the main line. In this way, by applying the "preemptive principle" to dataset updates, datasets that were not updated first are stored as branches from the main line, thereby enabling distributed version management by multiple users without dividing them into the main area M and user areas U. Furthermore, the merge between y3 and z2 can be achieved in the same way as in embodiments 1 and 2.

[0114] Furthermore, in Embodiment 2, if a dataset exists in the user area U that has not been merged with the main area M for a long time, a warning email may be sent to the user. For example, the warning email may be sent to the user based on the information used for authentication when the user is authenticated by the user authentication unit 102. A dataset that has not been merged with the main area M for a long time is likely to deviate significantly from the dataset in the main area M, so issuing a warning is beneficial.

[0115] (Other Modifications)

[0116] In each of the above embodiments, the PLC 10 performs version management on data sets. Alternatively, programmable devices other than PLCs can also implement version management by having functional units identical to those of the PLC 10. For example, when developing a program executed by a motion unit, the motion unit can have functional units identical to those of the PLC 10, thereby enabling version management of data sets related to the program executed by the motion unit.

[0117] exist Figure 4 In the illustrated hardware configuration, the PLC 10 and the development device 20 include a secondary storage device 1004. However, this is not limiting; the secondary storage device 1004 may be provided externally to the PLC 10 and the development device 20, and connected to the secondary storage device 1004 via the interface 1003. In this configuration, removable media such as a USB flash drive or a memory card can also be used as the secondary storage device 1004.

[0118] Alternatively, you can replace Figure 4 The hardware structure shown in FIG. 1 is composed of a dedicated circuit using an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), etc., to form the PLC 10 and the development device 20. Figure 4 In the hardware configuration shown, for example, a part of the functions of the PLC 10 and the development device 20 may be realized by a dedicated circuit connected to the interface 1003 .

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

[0120] Alternatively, the program may be stored in advance in a storage device of another server on the Internet, and downloaded from the server.

[0121] The present invention is capable of various embodiments and variations without departing from the broad spirit and scope of the present invention. Furthermore, the above-described embodiments are intended to illustrate the present invention and are not intended to limit the scope of the present invention. That is, the scope of the present invention is not defined by the embodiments but by the claims. Furthermore, any variations implemented within the scope of the claims and equivalent inventions are considered to fall within the scope of the present invention.

[0122] Description of the label

[0123] 1 Version management system, 10 PLC, 20 Development device, 30 External system, 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 Data set 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: a first storage unit for storing the first data set; a first version management unit configured to perform version management on the first data set stored in the first storage unit; a first sending unit configured to send the first data set version-managed by the first version management unit to a development device; and a first receiving unit for receiving a second data set, the second data set being created based on the first data set sent by the first sending unit and version-managed by the development device in association with the first data set; The first version management unit stores the second data set received by the first receiving unit in the first storage unit in association with the first data set, and performs version management in association with the first data set.

2. A development device comprising: a second storage unit; a second receiving unit configured to receive, from a programmable device, a first data set that has been version-managed by the programmable device; a second version management unit configured to store the first data set received by the second receiving unit in the second storage unit to perform version management; a data set creating unit, which creates a second data set based on the first data set based on a user operation; as well as a second sending unit, which sends the second data set to the programmable device, The second version management unit stores the second data set created by the data set creation unit in association with the first data set in the second storage unit, and performs version management in association with the first data set. The second sending unit sends the second data set, which is version-managed in association with the first data set, to the programmable device.

3. A version management system comprising: The programmable device of claim 1; and The development device according to claim 2.

4. A version management method, wherein: Performing version management on the first data set stored in the first storage unit, Sending the version-managed first data set to a development device, receiving a second data set, the second data set being created based on the transmitted first data set and being version-managed by the development device in association with the first data set; The received second data set is stored in the first storage unit in association with the first data set, and version management is performed in association with the first data set.

5. A version management method, wherein: receiving, from a programmable device, a first data set that is version-managed by the programmable device, The received first data set is stored in the second storage unit to perform version management, Based on the user's operation, a second data set is created based on the first data set. The created second data set is stored in the second storage unit in association with the first data set, and version management is performed in association with the first data set. The second data set that is version-managed in association with the first data set is transmitted to the programmable device.

6. A program that causes a computer to perform the following actions: Performing version management on the first data set stored in the first storage unit, Sending the version-managed first data set to a development device, receiving a second data set, the second data set being created based on the transmitted first data set and being version-managed by the development device in association with the first data set; The received second data set is stored in the first storage unit in association with the first data set, and version management is performed in association with the first data set.

7. A program that causes a computer to perform the following actions: receiving, from a programmable device, a first data set that is version-managed by the programmable device, The received first data set is stored in the second storage unit to perform version management, Based on the user's operation, a second data set is created based on the first data set. The created second data set is stored in the second storage unit in association with the first data set, and version management is performed in association with the first data set. The second data set that is version-managed in association with the first data set is transmitted to the programmable device.

Images