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

Abstract

A PLC (10) comprises a memory (100) that stores a first data set, a version manager (103) that implements version management of the first data set stored in the memory (100), and a communicator (101) that sends the first data set versioned by the version manager (103) to a development device and receives a second data set that is generated based on the sent first data set and versioned by the development device in association with the first data set. The version manager (103) causes the second data set received from the communicator (101) to be stored in the memory (100) in association with the first data set and implements version management of the second data set in association with the first data set.

Description

Technical FieldThe present disclosure relates to a programmable device, a development device, a version management system, a version management method, and a program.BackgroundProgrammable factory automation (FA) devices such as a programmable logic controller and a moving unit execute a program generated by development by a user, to thereby control a control target device. For managing change locations, progress management, and similar purposes in development, there is a need for version management of a program and data related to that program.As an example related to the above circumstances, Non-Patent Literature 1 discloses a technique for supporting development of control software by multiple persons using Git, which is an open source system for distributed version management.Citing listNon-Patent LiteratureNon-Patent Literature 1: Shintaro Iwamura, "Concurrent development by multiple developers in integrated factor automation development environment using open-source system 'Git'", [online], 25 March 2019, OMRON TECHNICS, [retrieved 10 March 2023], Internet URL: https: / / www.omron.com / jp / ja / technology / omrontechnics / 2019 / 20190315-iwamura.htmlOverview of the InventionTechnical ProblemIn the technique disclosed in Non-Patent Literature 1, the programmable device itself is independent of the distributed version management system. This configuration presupposes manual management for consistency between source code managed with the distributed version management system and a program to be executed by the programmable device, resulting in a great burden on a user. For example, a case is conceivable in which the program executed by the programmable device is not a program generated based on the source code managed with the distributed version management system.In view of the above circumstances, an object of the present disclosure is to provide a programmable device and the like that enables simple distributed version management of data related to the programmable device.Solution of the ProblemTo achieve the above object, a programmable apparatus according to the present disclosure includes a first storage means for storing a first record, a first version management means for implementing version management of the first record stored in the first storage means, a first transmission means for transmitting the first record versioned by the first version management means to a development device, and a first reception means for receiving a second record generated based on the first record transmitted by the first transmission means and versioned by the development device in association with the first record. The first version management means causes the second record received by the first receiving means to be stored in association with the first record in the first storage means, and implements version management of the second record in association with the first record.Advantageous Effects of the InventionThe present disclosure enables simple distributed version management of data related to a programmable device.Brief Description of the DrawingsFIG. 1 shows an overall configuration of a version management system according to Embodiment 1 of the present disclosure; FIG. 2 shows an example of version management by the version management system according to Embodiment 1 of the present disclosure; FIG. 3 shows a functional configuration of an PLC according to Embodiment 1 of the present disclosure; FIG. 4 shows an example of a hardware configuration of the PLC according to Embodiment 1 of the present disclosure and a developing device according to Embodiment 2 of the present disclosure; FIG. 5 is a flowchart showing an example of an operation of version management by the PLC according to Embodiment 1 of the present disclosure; FIG. 6 shows an overall configuration of a version management system according to a modification of Embodiment 1 of the present disclosure; FIG. 7 shows a functional configuration of a developing device according to Embodiment 2 of the present disclosure; FIG. 8 is a diagram for explaining an example of distributed version management by a version management system according to Embodiment 2 of the present disclosure; FIG. 9 is a diagram for explaining the example of the distributed version management by the version management system according to Embodiment 2 of the present disclosure; FIG. 10 is a diagram for explaining the example of the distributed version management by the version management system according to Embodiment 2 of the present disclosure; FIG. 11 is a diagram for explaining the example of the distributed version management by the version management system according to Embodiment 2 of the present disclosure; FIG. 12 is a diagram for explaining the example of the distributed version management by the version management system according to Embodiment 2 of the present disclosure; FIG. 13 is a diagram for explaining an example of the distributed version management by a version management system according to a modification of Embodiment 2 of the present disclosure; and FIG. 14 is a diagram for explaining the example of the distributed version management by the version management system according to the modification of Embodiment 2 of the present disclosure.DESCRIPTION OF EMBODIMENTSHereinafter, a version management system according to embodiments of the present disclosure will be described with reference to the drawings. In each of the drawings, the same reference numeral is assigned to the same or equivalent parts.Embodiment 1A version management system 1 according to Embodiment 1 will be described with reference to FIG. 1. The version management system 1 includes a programmable logic controller (PLC) 10 and a plurality of development devices 20.In the version management system 1, each of the plurality of users develops, with the corresponding development device 20, a program to be executed by the PLC 10. The user sends a record to the PLC 10 that is a compilation of a program programmed with the development device 20 and data pertaining to that program. The data concerning this program include, for example, a source code which is the basis of the program, a configuration file and a resource file necessary for the program, and a documentation file explaining the specifications of the program.For example, the user sends the record to the PLC 10 upon each completion of a change work of the program. the PLC 10 executes the program included in the record while realizing version management of the received record. In the case of the configuration in which the user sends the record to the PLC 10 at each completion of the change work, the PLC 10 is caused to implement the version management of the record at each completion of the change work.The PLC 10 executes the program developed by the users to thereby control a control device not shown. In addition to executing the program, the PLC 10 implements the version management of the record as described above. A 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.The developing device 20 is used for developing the 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. The user generates, with the development device 20, the record including the program to be executed by the PLC 10 and transmits the generated record to the PLC 10. The development device 20 is an example of a development device according to the present disclosure.Next, an overview of the version management in the version management system 1 will be described. An overview of the processes for the development of the program in the version management system 1 will be described later.(1) The user generates the record including the program by development work.(2) The PLC 10 authenticates the user.(3) The user sends the record to the PLC 10.(4) The PLC 10 implements the version management of the received record.(5) The user executes the program included in the record sent to the PLC 10 on the PLC 10, thereby performing an debugging work.(6) performing error recovery work as necessary and repeating the processes from (1).(7) After completion of the necessary error recovery work, the program is executed on the PLC 10 and a plurality of users perform an operation check.(8) The user repeats the processes from (1) depending on a result of the operation check.Except for (7) which is a work performed in common by a plurality of users, all the others of steps (1) to (8) are work performed by each individual user. Accordingly, a configuration that enables separate management of the record concerning the work to be performed by the single user and the record concerning the joint work is desirable.The PLC 10 controls the record separately in a master area and user areas each provided for the corresponding user. The master area is an area that is accessible to any user, and the user area is an area that is accessible only by the corresponding user and inaccessible to the other users. Although the record generated by the user is stored in the user area in principle, the record to be shared with all of the users is stored in the master area in accordance with a user operation. Hereinafter, the expression "applying the record to the master area" is used to refer to storing the record in the master area in accordance with the user operation. Examples of the record to be shared with all the users include a record including an executable file for which necessary modification work by the user is completed and testing by all the users is to be performed together, and a record including an executable file that has reached a level acceptable for delivery of a product.A specific example will be described with reference to FIG. 2. Each circle shown in FIG. 2 indicates a data record. Each arrow shown in FIG. 2 indicates generation of a lineage dataset including a particular dataset as a direct lineage dataset. When a new record is created by performing a change work on a record, the record before the change is the "direct parent record", and the record after the change is the "parent record". A data record x 1, which is the "original data record", is generated, for example, in that, when a data record is first received from the PLC 10, this data record is stored in the master area.First, a user A performs a change work based on the data set x 1 in the master area and transmits the data set thus changed to the PLC 10. Hereinafter, performing a change work based on a data set and transmitting the data set thus changed to the PLC 10 will be referred to as "update". By the update by the user A, a record y 1 that is a branch from the record x 1 in the master area is stored in an area of the user A instead of the master area. The data set x1 serves as a direct master data set of the data set y1.By updating the data record y 1 by the user A, a data record y 2 with the data record y 1 as a direct master data record is stored in the user area A. By similar updating work, a record y 3 including the record y 2 as a direct master record is thereafter stored in the user area A.Thereafter, the user A performs a work for applying the data set y3 to the master area, thereby causing a data set x2 identical in content to the data set y3 to be stored in the master area with the data set x1 and the data set y3 as direct master data sets. This data set x2 is a data set that applies the contents of the change works performed by the user A in the data sets y1 to y3. Since the original root record of the record y3 is the record x1 and the most up-to-date record in the master area at this time is the record x1, the record y3 can be applied to the master area without any problem. The "parent record" herein refers to a record that is achieved by tracing back the parent record for a record over one or more generations. In the example shown in FIG. 2, the data set x 1 serves as the "original master data set" for each of the data sets y 1, y 2 and y 3.Next, a work of a user B will be described. Similarly to the user A, the user B updates the data set x 1 in the master area and thereby stores a data set z 1 that is a branch from the data set x 1 in the master area with the data set x 1 as a direct master data set in an area of the user B. The user B performs the update twice in succession to thereby store a data set z 2 with the data set z 1 as a direct master data set in the user area B and store a data set z 3 with the data set z 2 as a direct master data set in the user area B. Up to this point, the work of the user B is done before the record x 1 is stored in the master area.Thereafter, the user B tries to apply the record z 3 to which the content of the own change work is applied to the master area. However, since the most up-to-date record in the master area is not the record x1, but the record x2, the attempt to apply the record z3 to the master area causes conflict. This state makes the application of the data set z3 unreachable.Thus, the user B performs a work for merging the record z 3 to which the current change work of the user B is applied with the record x 2 in the master area and updates with the record changed by this work. This has the effect that a data record z4 with the data record z3 is stored as a direct master data record in the user area B.Thereafter, the user B performs a work for applying the data set z4 to the master area, thereby causing a data set x3 identical in content to the data set z4 to be stored in the master area with the data set x2 and the data set z4 as direct master data sets. This data set x 3 is a data set obtained by merging the content of the change work performed by the user B in the data sets z 1 to z 3 with the content of the data set x 2.The PLC 10 controls the records separately in the master area and the user areas, thereby enabling the records to be managed on a pro-user premises. This configuration allows each user to focus only on the records in the master area and the records in the user area corresponding to the user during the development of a program, thereby facilitating version management operations in an environment in which multiple persons are involved in the development.Next, a functional configuration of the PLC 10 will be described with reference to FIG. 3. The PLC 10 includes a storage 100, a communicator 101, a user authenticator 102, a version manager 103, and a program execution device 104.The memory 100 stores the records based on the version management described later and implemented by the version manager 103. The memory 100 includes a master area M and a plurality of user areas U provided for the respective users, respectively. The memory 100 is an example of a first storage means according to the present disclosure.The communicator 101 communicates with the development device 20. The communicator 101 is an example of a first transmitting means and a first receiving means according to the present disclosure.The user authenticator 102 authenticates a user corresponding to the development device 20 that is a communication destination of the communicator 101. The user authenticator 102 authenticates the user by, for example, password authentication. In another example, the configuration may be employed in which an administrator of the PLC 10 for each development device 20 registers the corresponding user in the PLC 10 in advance, and the user authenticator 102 automatically performs the user authentication by identifying the development device 20.The version manager 103 implements the version management of the record received from the communicator 101. The version manager 103 stores and manages the records separately in the master area M and each user area U. The version manager 103 stores, in the user area U corresponding to a user who made the update, a record having the record stored in the master area M as a direct master record. Thus, the record to be stored is a record which is a "branch" from the record in the master area M. In addition, the version manager 103 fundamentally causes the data record with the data record stored in the user area U to be stored as a direct master data record in the user area U. Accordingly, the data set transmitted by the user is stored in the user area U in principle.On the other hand, when the user performs the work of applying the record stored in the own user area U to the master area M, the version manager 103 stores this record in the master area M. In the case where the original master record of the record that the user tries to apply to the master area M is different from the current record stored in the master area M, the version manager 103 rejects the application by the user. In this case, the user performs a work for merging the current record stored in the master area M with the own record.When storing a record in the master area M or the user area U, the version manager 103 stores, in addition to the record per se, metadata for individually identifying the record and metadata indicating a record as the direct root record of the record which is a target of storage, in association with the record per se. For example, in the case of treating the data set per se as a binary data part, a hash value of this binary data may be used as the metadata. Since this configuration enables storage of a record when the record is assigned to a record as a direct root record, management of root-and-root relationships of records can be achieved, and thus version management of the record as a whole can be achieved. The version manager 103 is an example of a first version management means according to the present disclosure.The program execution device 104 loads the program stored in the memory 100 via the version manager 103, and executes the loaded program. For example, the program execution device 104 loads and executes the program included in the current record stored in the memory 100. In another example, the program execution device 104 loads and executes the program included in the record specified by the user. For reasons of working processes, a case may arise, for example, in which the source code is temporarily not compilable and accordingly no executable file is included in the current data record. In such cases, the user must specify the record that includes an executable file.In addition, the program execution device 104 causes a log regarding the execution of the program in association with the record corresponding to the executed program to be stored in the memory 100. The protocol relates to the execution of the program, and includes, for example, information indicating a date and time of execution, information regarding an event or an error that occurred in the execution of the program, information indicating the record corresponding to the executed program, and the like. For example, by analyzing this protocol, the user may evaluate a quality of the program for each data set.Next, an example of a hardware configuration of the PLC 10 will be described with reference to FIG. 4. The PLC 10 is a programmable logic controller and is thus one type of computer.The PLC 10 includes a processor 1001, a memory 1002, an interface 1003, and a secondary memory 1004, which are connected to each other via a line 1000.The processor 1001 is, for example, a central processing unit (CPU). The functions of the PLC 10 are achieved by a processor 1001 that loads an operation program stored in the secondary memory 1004 into the memory 1002 and executes the program. The processor 1001 may include, separately from the processor for executing the operation program, a processor for loading and executing the record stored in the memory 100. In this case, the latter processor achieves the functions of the program execution device 104.The memory 1002 is, for example, a main memory including a random access memory (RAM). The memory 1002 stores the operation program loaded from the secondary memory 1004 by the processor 1001. The memory 1002 serves as a working memory when the processor 1001 executes the operation program.The interface 1003 is an input / output (I / O) interface such as a serial port, a universal serial line (USB) port, or a network interface. The interface 1003 performs the functions of the communicator 101.The secondary storage 1004 is, for example, a flash memory, a hard disk drive (HDD), or a solid state drive (SSD). The secondary storage 1004 stores the operation program to be executed by the processor 1001. Secondary memory 1004 performs the functions of memory 100.Next, an example of operations of version management by the PLC 10 will be described with reference to FIG. 5. The operation shown in FIG. 5 is performed, for example, when the user operates the development device 20 and when starting communication for sending the record to the PLC 10.The user authenticator 102 of the PLC 10 communicates with the development device 20 and authenticates the user of the development device 20 (step S 101). By this operation, the user who sent the record is specified.In the authentication of the user, the development device 20 transmits the data set to the PLC 10, and the communicator 101 of the PLC 10 receives the transmitted data set (step S 102).The version manager 103 of the PLC 10 determines whether the user tries to apply the record to the master area M (step S 103).When the user does not attempt to apply the record to the master area M (No in step S 103), the version manager 103 causes the record received in step S 102 to be stored in the user area U corresponding to the user authenticated in step S 101 (step S 104). In the case where, in this operation, the direct root record of the record to be stored is the record in the master area M, the record to be stored is a record that is a "branch" from the record in the master area M. Then, the PLC 10 ends the operation of the version management.When the user tries to apply the record to the master area M (Yes in step S 103), the version manager 103 determines whether the record, which is the original master record of the record that is the target of the application, matches the current record in the master area M (step S 105).When the record which is the original root record of the record which is the target of the application matches the current record in the master area M (Yes in step S 105), the version manager 103 causes the record which is the target of the application to be stored in the master area M (step S 106). Then, the PLC 10 ends the operations of the version management.When the record that is the original root record of the record that is the target of the application does not match the current record in the master area M (No in step S 105), the version manager 103 rejects the application of the record to the master area M (step S 107). Then, the PLC 10 ends the operations of the version management.The version management system 1 according to Embodiment 1 has been described above. The PLC 10 of the version management system 1 implements the version management by separately storing the records in the master area M and the user areas U. This configuration allows the user to focus only on the records in the master area M and the records in the user area U corresponding to the user during the development of a program, thereby enabling simple version management operations in an environment in which a plurality of persons are involved in development.Modification of Embodiment 1In Embodiment 1, the configuration may be employed in which the PLC 10 is communicatively connected to an external system 30, as shown in FIG. 6, and the version manager 103 of the PLC 10 applies backup by sending the record stored in the memory 100 to the external system 30 at a predetermined timing. The time of backup may be a time when a new record is added, or the backup may be regularly created.Further, the configuration may be adopted in which, in place of the PLC 10, the development device 20 is communicatively connected to the external system 30, and the development device 20 applies backup by loading the record stored in the memory 100 of the PLC 10 and sending this record to the external system 30. This configuration can be employed, for example, in a case where the development apparatus 20 is connectable to the Internet but the PLC 10 is not connectable to the Internet.In Embodiment 1, each user is granted access to the record in the user area U corresponding to the user and prohibited access to the record in the user area U corresponding to another user. The record in each user area U may be encrypted with an encryption key corresponding to the user, rather than simply being inaccessible.Further, the data set in the master area M may be encrypted with an encryption key that is unique to the PLC 10. This configuration prevents a third party from knowing the content of the record stored in the master area M even if the record has leaked for some reason, because a person who does not own the PLC 10 cannot decrypt the record in the master area M.In Embodiment 1, the user can apply the record in the user area U to the master area M at any time on condition that no conflict occurs with respect to the current record in the master area M. On the other hand, when the record is continuously updated without ever applying it to the master area M, the deviation between the content of the record in the master area M and the content of the record in the user area U becomes larger and thus may impede development. Thus, for example, the version manager 103 may prompt the user with a warning if the record has been updated more than a certain number of times in the user area U. For example, the version manager 103 may transmit data indicating a warning to the development device 20 via the communicator 101, and the development device 20 transmits a notification of the warning to the user.Embodiment 2Next, a version management system 1 according to Embodiment 2 will be described. The overall configuration of the version management system 1 according to Embodiment 2 is similar to that of Embodiment 1 shown in FIG. 1. Embodiment 2 is different from Embodiment 1 in that the development device 20 also realizes the version management of the record.This configuration eliminates the need for the user to send the record to the PLC 10 each time it changes. For example, after multiple changes of the record and completion of necessary change work, the user may send multiple records corresponding to the multiple changes together to the PLC 10.For example, in the example of Embodiment 1 shown in FIG. 2, the user A updates the record by sending, to the PLC 10, the record corresponding to the update for each update corresponding to the records y 1, y 2, or y 3. On the other hand, according to Embodiment 2, after the user A once acquires the data set x 1, the user A can perform the changing work on the data sets y 1, y 2, and y 3 without communication with the PLC 10, and thus apply the data set y 3 to the master area M by sending the data sets y 1, y 2, and y 3 to the PLC 10 together.The functional configuration of the developing device 20 according to Embodiment 2 will be described with reference to FIG. 7. The development device 20 according to Embodiment 2 includes a storage 200, a communicator 201, a record generator 202, and a version manager 203.The memory 200 stores the record based on the version management described later and implemented by the version manager 203. The memory 200 includes the master area M and the user area U. Unlike the memory 100 of the PLC 10, only a user area U corresponding to the user of the developing device 20 is included. The memory 200 is an example of a second storage means according to the present disclosure.The communicator 201 communicates with the PLC 10. Based on the management of the version manager 203 described later, the communicator 201 transmits the data set generated by the user with the development device 20 to the PLC 10 and receives the data set stored in the storage 100 from the PLC 10. The communicator 201 is reached through, for example, a network interface. The communicator 201 is an example of a second reception means and a second transmission means according to the present disclosure.The record generator 202 generates, based on a user operation via an input device not shown, the program to be executed by the PLC 10 and data related to this program. That is, the record generator 202 generates the record based on a user work. The data set generator 202 has an editing function for describing, for example, a source code, a configuration file, documentation and the like. The record generator 202 is an example of a record generating means according to the present disclosure.The version manager 203 causes the record generated by the record generator 202 to be stored in the user area U of the memory 200, and implements the version management. Similarly to the version manager 103 of the PLC 10, when storing a record, in addition to the record per se, the version manager 203 stores metadata for individually identifying the record and metadata indicating a record as a direct root record of the record which is a target of storing, in association with the record per se. This configuration results in version management of the user generated record in the development device 20.Of the data sets stored in the user area U of the memory 200, one or more data sets that have not yet been sent to the PLC 10 are commonly sent to the PLC 10 by the version manager 203 via the communicator 201. This configuration enables synchronization of contents of the change work performed by the user on the development device 20 with the PLC 10.The version manager 203 acquires, from the data sets stored in the master area M of the memory 100 of the PLC 10, one or more data sets not yet stored in the master area M of the memory 200 via the communicator 201 and stores them in the master area M of the memory 200. This configuration enables synchronization of contents of the changes made in the master area M of the PLC 10 with the development device 20.Here, the location that distinguishes the PLC 10 according to Embodiment 2 from that of Embodiment 1 will be described. As described above, a plurality of data sets may be transmitted to the PLC 10 by the development apparatus 20 according to Embodiment 2. In addition, as described above, the development apparatus 20 according to Embodiment 2 acquires the record from the PLC 10 in the master area M. Thus, the version manager 103 according to Embodiment 2 has functions corresponding to these configurations. The version manager 103 according to Embodiment 2 collectively receives a plurality of records from the development device 20, and collectively stores the received records in the user area U of the storage 100. The version manager 103 according to Embodiment 2 sends one or more records in the master area M to the development device 20 in response to a request from the development device 20.The functions of the version manager 203 of the development device 20 and the functions of the version manager 103 of the PLC 10 allow version management of the record in the PLC 10 and the development device 20 to be separately implemented upon achieving necessary synchronization between the PLC 10 and the development device 20.Hereinafter, a specific example will be described with reference to the drawings. It is assumed that originally only one record x 1 is stored in the memory 100 of the PLC 10 and no record is stored in the memory 200 of the development apparatus 20.First, the version manager 203 of the development device 20 acquires the data set x 1 stored in the memory 100 based on a user operation from the PLC 10 and stores it in the master area M of the memory 200. This causes the data set x1 to be stored in the master area M of the memory 200 of the developing device 20, as shown in FIG. 8.Then, the user of the developing device 20 performs a changing work on the data set x 1. This causes the record generator 202 of the development apparatus 20 to generate a new record, and the version manager 203 stores this new record as a record y1in the user area U of the memory 200 as shown in FIG. 9. At this time, no particular change occurs in the memory 100 of the PLC 10 because communication between the PLC 10 and the developing device 20 is not performed.After that, the user performs two change operations, and the records y2 and y3 are stored in the user area U of the memory 200 as shown in FIG. 10. At this time, no particular change still occurs in the memory 100 of the PLC 10.Then, the version manager 203 collectively sends the data sets y 1, y 2, and y 3 stored in the user area U of the memory 200 to the PLC 10 based on a user operation. the version manager 103 of the PLC 10 stores the received data sets y 1, y 2, and y 3 in the user area U of the memory 100 as shown in FIG. 11. At this time, the first synchronization is performed between the developing device 20 and the PLC 10.Then, the user performs an operation of applying the record y 3 to the master area of the memory 100 of the PLC 10, and thereby stores a record x 2 identical in content to the record y 3 in the master area M of the memory 100. Thereafter, the version manager 203 of the development apparatus 20 acquires the data set x 2 stored in the master area M of the memory 100 from the PLC 10 and stores it in the master area M of the memory 200. This allows both the PLC 10 and the development device 20 to implement the version management with the data sets x1, x2, y1, y2, and y3, as shown in FIG. 12.Note that, as described in the example with the data sets z 3, x 2, z 4, and x 3 of FIG. 2, a case may occur in which the data set is not applicable in the user area U due to the occurrence of conflict in attempting to apply to the master area M. In this case, the version manager 203 of the development apparatus 20 first acquires the record stored in the master area M of the memory 100 from the PLC 10 and stores it in the master area M of the memory 200. Then, the user performs a merging work on the record stored in the master area M of the memory 200, thereby causing the record generator 202 to generate a record, and the version manager 203 stores this record in the user area U of the memory 200. Then, the version manager 203 sends the new record stored in the user area U of the memory 200 to the PLC 10, and stores the record received from the version manager 103 of the PLC 10 into the user area U of the memory 100. The user may then again attempt to apply the data set of the user area U to the master area M.Similarly to Embodiment 1, the program execution device 104 of the PLC 10 executes the program included in the record stored in the memory 100. This allows the user to easily manage the consistency between the source code that is the target of version management and the program to be executed by the PLC 10.The hardware configuration of the developing device 20 according to Embodiment 2 is substantially similar to that shown in FIG. 4. This is because the development device 20 is, for example, a personal computer on which a program as an engineering tool is installed as described in Embodiment 1.The version management system 1 according to Embodiment 2 has been described above. The version management system 1 according to Embodiment 2 enables version management of the records in the PLC 10 and the development device 20 to be separately implemented while achieving necessary synchronization between the PLC 10 and the development device 20. Accordingly, with the version management system 1 according to Embodiment 2, distributed version management can be achieved. Further, similarly to Embodiment 1, the PLC 10 executes the program included in the record stored in the memory 100. This allows the user to easily manage the consistency between the source code that is the target of version management and the program to be executed by the PLC 10. Thus, with the version management system 1 according to Embodiment 2, distributed version management of data concerning the programmable device can be easily achieved.Further, due to the configuration of separately managing the records in the master area M and the user area U, the user is caused, in attempting to merge the record generated thereby, to check the record in the user area U and the record in the master area M and make a determination before merging. Thus, the configuration of separately managing the record in the master area M and the user area U can provide the user with a natural opportunity to make a decision without imposing a large burden on the user for merging, and thus can avoid a circumstance in which the records are merged unintentionally. For example, there could be an unintentional merging of data sets that were not freed from errors.Modifications of Embodiment 2Since Embodiment 2 is a modification of Embodiment 1, a plurality of users are involved in Embodiment 2 similarly to Embodiment 1. Even in a case where only one user is involved in Embodiment 2, the distributed version management of the records can still be achieved with the development device 20 of the user and the PLC 10. In this case, the memory 100 of the PLC 10 is provided with the master area M and a user area U, and the PLC 10 does not necessarily need to include the user authenticator 102.Further, in Embodiment 2, a configuration is conceivable in which management of the records having an area without disconnection is converted into the master area M and the user area U. An example according to this configuration will be described below, in which each of a plurality of users generates a record with the corresponding development device 20 and performs the update by transmitting the generated record to the PLC 10.FIG. 13 shows a case where both the user A and the user B perform development with the corresponding development device 20 based on the data set x 1 stored in the memory 100 of the PLC 10. User A generates records y1, y2, and y3, and user B generates records z1 and z2. Next, assume that user A updates the record before user B, and then user B updates the record. In this case, as shown in FIG. 14, the records y 1, y 2, and y 3 of the user A who has updated the record earlier are stored in the memory 100 of the PLC 10 as they are. The line in which the data sets x1, y1, y2and y3are stored is a so-called "master line". Then, the records z 1 and z 2 of the user B that has updated the record after the user A are stored as a branch from the master line in the memory 100 of the PLC 10. In this way, distributed version management can be achieved by multiple users without separation into the master area M and the user area U by performing the update of the dataset on a "wer first, grind first" premises and storing the datasets that do not experience the earliest update as a branch from the master line. Merging y3and z2may be performed similarly to Embodiments 1 and 2.Further, in the case where, in Embodiment 2, a record exists in the user area U that is not merged into the master area M for a long time, a warning mail can be sent to the user. For example, upon authentication of a user by the user authenticator 102, the alert mail may be sent by sending a mail to that user based on information used for authentication. Since a record which is not merged into the master area M for a long time is most likely to have a large deviation from the record in the master area M, issue of a warning is useful.Other ModificationIn the above embodiments, the PLC 10 implements version management of the record. Programmable devices other than the PLCs, which include functional elements similar to those of the PLC 10, may implement version management. For example, in developing a program to be executed in a moving unit, inclusion of functional elements similar to those of the PLC 10 in the moving unit enables version management of the record concerning the program to be executed in the moving unit.In the hardware configuration shown in FIG. 4, the PLC 10 and the developing device 20 include the secondary storage 1004. This configuration is not limiting, and a configuration may be adopted in which the secondary storage 1004 is disposed outside the PLC 10 and the developing device 20, and the secondary storage 1004, the PLC 10, and the developing device 20 are connected via the interface 1003. The secondary storage 1004 according to this configuration may be a removable medium such as a USB flash memory or a memory card.Instead of the hardware configuration shown in FIG. 4, the PLC 10 and the development apparatus 20 may each include a dedicated circuit including an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). In the hardware configuration shown in FIG. 4, some functions of the PLC 10 and the developing device 20 may be achieved by, for example, a dedicated circuit connected to the interface 1003.The programs used in the PLC 10 and the development device 20 may be distributed on a non-transitory computer readable storage medium such as a compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a USB flash memory, a memory card, or an HDD. A specific computer or a general-purpose computer on which the program is installed may function as the PLC 10 or the development device 20.Further, the above program may be stored in a memory included in another server on the Internet and downloaded from the server to a computer.The foregoing describes some exemplary embodiments for illustrative purposes. Although the foregoing discussion has presented specific embodiments, those skilled in the art will recognize that changes may be made in form and detail without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. This detailed description, accordingly, is not to be taken in a limiting sense, and the scope of the invention is defined only by the claims appended hereto, along with the full breadth of equivalents to which such claims are entitled.List of reference characters1 Version management system 10 PLC 20 Development device 30 External system 100 Memory 101 Communicator 102 User authenticator 103 Version manager 104 Program execution device 200 Memory 201 Communicator 202 Record generator 203 Version manager 1000 Line 1001 Processor 1002 Memory 1003 Interface 1004 Secondary memory M Master area U User area

Claims

A programmable apparatus comprising: first storage means for storing a first record; first version management means for implementing version management of the first record stored in the first storage means; first transmission means for transmitting the first record, version managed by the first version management means, to a development apparatus; and first reception means for receiving a second record, which is generated based on the first record transmitted by the first transmission means and version managed by the development apparatus in association with the first record, wherein the first version management means causes the second record received by the first reception means to be stored in association with the first record in the first storage means, and implements version management of the second record in association with the first record.A development apparatus comprising: second storage means; second receiving means for receiving a first record versioned by a programmable apparatus from the programmable apparatus; second version management means for causing the first record received by the second receiving means to be stored in the second storage means and for implementing version management of the first record; record generation means for generating a second record based on the first record in accordance with work by a user; and a second transmission means for transmitting the second record to the programmable device, wherein the second version management means causes the second record generated by the record generation means to be stored in the second memory in association with the first record, and converts the version management of the second record in association with the first record, and wherein the second transmission means transmits the second data version-managed in association with the first record to the programmable device.A version management system comprising: the programmable device of claim 1; and the development device of claim 2.A version management method comprising: implementing version management of a first record stored in a first storage means; sending the version managed first record to a development device; receiving a second record which is generated based on the sent first record and which is version managed by the development device in association with the first record; and causing the received second record to be stored in association with the first record in the first storage means, and implementing version management of the second record in association with the first record.A version management method comprising: receiving from the programmable device a first record versioned by a programmable device; causing the received first record to be stored in a second storage means, and implementing the version management of the first record; generating a second record based on the first record in accordance with a work by a user; and causing the generated second record to be stored in association with the first record in the second storage means, and implementing the version management of the second record in association with the first record; and sending the second record versioned in association with the first record to the programmable device.A program for causing a computer to execute the steps of: implementing version management of a first record stored in a first storage means; sending the version managed first record to a development device; receiving a second record generated based on the sent first record and version managed by the development device in association with the first record; and causing the received second record to be stored in association with the first record in the first storage means, and implementing version management of the second record in association with the first record.A program for causing a computer to execute the steps of: receiving from the programmable device a first data set version-managed by a programmable device; causing the received first data set to be stored in a second storage means, and implementing the version management of the first data set; generating a second data set based on the first data set in accordance with a work by a user; and causing the generated second data set to be stored in association with the first data set in the second storage means, and implementing the version management of the second data set in association with the first data set; and transmitting the second data set version-managed in association with the first data set to the programmable device.

Images