Data Management System

Abstract

To improve development efficiency by appropriately managing development data.SOLUTION: A data management system 100 includes a data storage system 3 for storing development data 4 and a plurality of client servers 11 to 14 each having BLC data 7 in which transaction data related to the development data 4 is stored. Each of the plurality of client servers 11 to 14 stores the transaction data including a first hash value generated from first development data and a second hash value generated from second development data in the BLC data 7 if the second development data from which the first development data is derived is present when registering the first development data in the data storage system 3.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present disclosure relates to a data management system. [Background technology]

[0002] Various technologies for managing the traceability of products have been proposed. For example, International Publication No. 2021 / 95795 (Patent Document 1) discloses an information processing device for managing the traceability of gemstones. The information processing device includes a generating means for generating a hash value of each of one or more pieces of data that can prove the traceability of gemstones. Each of the one or more hash values ​​generated by the generating means is associated with each of one or more pieces of data so as to be identifiable, and is managed in a communication network. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] WO 2021 / 95795 Summary of the Invention [Problem to be solved by the invention]

[0004] Generally, in a company's product development site, many developers carry out development work in parallel. Development data such as CAD (Computer Aided Design) data is stored in a data storage system. Each developer accesses the data storage system from his or her own server. The developer's terminal is configured to read the development data from the data storage system and to register the development data that the developer has considered in the data storage system.

[0005] In development work, data is often created by branching off from one piece of data to consider product specifications, performance, conditions, etc. As a result, various development data may be stored on the server. If development data is not managed appropriately, development costs may increase and development periods (lead times) may become longer due to the need to reconsider things because incorrect development data was used for the study. In other words, development efficiency may decrease.

[0006] The present disclosure has been made to solve the above problems, and one of the objectives of the present disclosure is to improve development efficiency by appropriately managing development data. [Means for solving the problem]

[0007] A data management system according to an aspect of the present disclosure includes a data storage device that stores development data, and a plurality of data management devices having a distributed ledger in which transaction data related to the development data is stored. When registering first development data in the data storage device, if second development data from which the first development data is derived exists, each of the plurality of data management devices stores transaction data in the distributed ledger, the transaction data including a first hash value generated from the first development data and a second hash value generated from the second development data.

[0008] In the above configuration, transaction data including a first hash value and a second hash value is generated. In other words, the first hash value and the second hash value are linked in the transaction data, thereby defining the relationship between the first development data and the second development data. Then, when a user selects development data (the first development data or the second development data) for review, it becomes possible to confirm where the development data came from, that is, the identity of the development data, so to speak. As a result, review using incorrect development data is prevented, and therefore increases in development costs and extensions of development periods can be suppressed. Therefore, according to the above configuration, development efficiency can be improved. Effect of the Invention

[0009] According to the present disclosure, development efficiency can be improved by appropriately managing development data. [Brief description of the drawings]

[0010] [Figure 1] 1 is a diagram illustrating an overall configuration of a data management system according to an embodiment of the present disclosure. [Diagram 2] FIG. 2 is a diagram for explaining an example of development data. [Diagram 3] FIG. 2 is a diagram illustrating a hardware configuration of a client server. [Figure 4] FIG. 1 is a diagram illustrating the data structure of blockchain data. [Diagram 5] FIG. 1 is a schematic diagram for explaining a typical example of the transition of development data in a development operation. [Figure 6] FIG. 2 is a schematic diagram for explaining an overview of the association of development data in the present embodiment. [Figure 7] FIG. 11 is a conceptual diagram for explaining linking of hash values ​​in the present embodiment. [Figure 8] 1 is a conceptual diagram for explaining transaction data stored in BLC data in the present embodiment. FIG. [Figure 9] FIG. 2 is a functional block diagram of a client server (control device) related to management of development data. [Figure 10] 13 is a flowchart showing a series of processing steps for registering development data. [Figure 11] 13 is a flowchart showing a series of processing steps for reading development data. [Figure 12] FIG. 11 is a diagram showing an example of display content on a display device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference characters, and the description thereof will not be repeated.

[0012] [Embodiment Mode] <Overall system configuration> 1 is a diagram showing an overall configuration of a data management system according to an embodiment of the present disclosure. The data management system 100 is configured to manage product development data using distributed ledger technology. An example in which the data management system 100 manages product development data using blockchain technology will be described below. However, the distributed ledger technology is not limited to blockchain technology, and may be other distributed ledger technologies such as CORDA (registered trademark).

[0013] The data management system 100 includes multiple client servers 11-14, a management server 2, and a data storage system 3. Due to space limitations, an example will be described in which the data management system 100 includes four client servers, but the number of client servers is not particularly limited as long as it is multiple. Usually, the number of client servers is much larger, and can range from tens to hundreds.

[0014] In this example, a private network NW is formed among multiple departments (which may be affiliated companies) in a certain company. In this example, multiple client servers 11-14 belong to departments A-D, respectively. Note that a consortium network may also be formed among multiple participants that are independent of each other, such as companies and universities.

[0015] Development tools such as CAD tools, simulation tools, etc. are installed in each of the multiple client servers 11 to 14. Each of the client servers 11 to 14 reads development data 4 from the data storage system 3 and performs various processes (such as duplication, conversion, and modification) on the read development data 4.

[0016] Blockchain-based software is further installed in each of the client servers 11-14. When the blockchain-based software functions, a control device (see FIG. 2) included in each of the client servers 11-14 functions as a node. A blockchain network is formed when multiple nodes communicate with each other via the network NW. Each of the client servers 11-14 corresponds to a "data management device" according to the present disclosure.

[0017] The management server 2 manages a blockchain network formed by multiple client servers 11 to 14. More specifically, the management server 2 accepts applications for participation in the blockchain network from each of the client servers 11 to 14. The management server 2 permits the client server to participate in the blockchain network based on an operation by the administrator of the management server 2 to permit participation, or based on the result of judging a predetermined condition.

[0018] The data storage system 3 is, for example, a product data management (PDM) system. The data storage system 3 includes a non-volatile storage medium such as a hard disk drive (HDD), a solid state drive (SSD), a flash memory, etc. (none of which are shown). The data storage system 3 stores development data 4 that has been subjected to various processes by client servers 11-14. The development data 4 stored in the data storage system 3 is managed off-chain (outside the blockchain network). The data storage system 3 corresponds to a "data storage device" according to the present disclosure.

[0019] 2 is a diagram for explaining an example of product development data 4. The product is an industrial product in the field of mechanical industry, metal industry, petrochemical industry, etc. The product development data 4 is data for examining the above-mentioned industrial product.

[0020] Here, it is assumed that the product is an automobile. The development data 4 is CAD (Computer Aided Design) data, CAE (Computer Aided Engineering) data, and CAM (Computer Aided Manufacturing) data for the automobile or automobile parts.

[0021] 2, the development data 4 includes, for example, a data name, a data format, a creation time of the development data 4, a (last) update time of the development data 4, and a data body. The development data 4 is stored (registered) together with a hash value in the data storage system 3. The hash value of the development data 4 will be described later.

[0022] However, it is not essential that the hash value of the development data 4 is stored in the data storage system 3. The hash value of the development data 4 may not be stored in the data storage system 3, and may be calculated each time it is needed.

[0023] <Client-server configuration> The multiple client servers 11 to 14 have the same configuration and functions. Therefore, in the following, the client server 11 belonging to the A department will be explained as a representative example.

[0024] 3 is a diagram illustrating a schematic hardware configuration of the client server 11. The client server 11 includes a control device 511, a ROM (Read Only Memory) 512, a RAM (Random Access Memory) 513, a communication device 514, a storage device 515, an input device 516, and a display device 517. The above devices are communicatively connected via a bus 518.

[0025] The control device 511 includes an integrated circuit such as a CPU (Central Processing Unit). The ROM 512 stores various programs including blockchain-based software. The RAM 513 functions as a working memory and temporarily stores data required for the execution of the various programs. The control device 511 is configured to execute various arithmetic operations by expanding the various programs stored in the ROM 512 into the RAM 513.

[0026] The control device 511 is configured to execute the following processes as a node in the blockchain network. When the control device 511 is started for the first time as a node, it generates a private key 61 and a public key 62 that comply with a predetermined standard. The control device 511 generates transaction data. The control device 511 generates a digital signature using the private key 61 and adds it to the transaction data. The control device 511 approves the transaction data proposed by the other nodes (consensus). The control device 511 verifies the transaction data proposed by the other nodes, and if there is no problem with the verification result, it affixes a digital signature to the transaction data and returns the transaction data to the other nodes.

[0027] The communication device 514 is configured to be capable of communicating with external devices. The external devices include other client servers 12 to 14, the management server 2, and the data storage system 3. The communication between the communication device 514 and the external devices is performed using the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet (registered trademark) network, a public network, a private network, a wired network, a wireless network, or a combination of these.

[0028] The storage device 515 includes a storage medium such as an HDD, an SSD, or a flash memory. The storage device 515 stores the private key 61 and the public key 62 generated by the control device 511, as well as block chain data (hereinafter, referred to as "BLC data") 7. The transaction data stored in the BLC data 7 in this embodiment will be described later.

[0029] The input device 516 receives operations from a user. A user is a person in charge of handling product development data 4, such as a developer, a researcher, a CAD operator, etc. The input device 516 includes, for example, a mouse, a keyboard, and a touch panel.

[0030] Display device 517 displays various images in accordance with control signals from control device 511. Display device 517 includes, for example, a liquid crystal display or an organic EL (Electro Luminescence) display.

[0031] <BLCデータ> 4 is a diagram for explaining the data structure of the BLC data 7. The BLC data 7 includes a plurality of consecutive blocks 70. Each of the plurality of blocks 70 stores a hash value of the previous block and transaction data. The BLC data 7 records the history of the development data 4 from the start of operation of the data management system 100 to the present.

[0032] The BLC data 7 is recorded in all client servers 11 to 14 that form the blockchain network (see FIG. 1). As a result, even if the BLC data 7 of the client server 11 is tampered with, the tampering is suppressed by using the BLC data 7 of the other multiple client servers 12 to 14 as a reference.

[0033] More specifically, when new development data 4 is created or existing development data 4 is modified, the client server 11 (control device 511) stores the development data 4 in the data storage system 3 and generates transaction data indicating processing on the development data 4. The client server 11 hashes the development data 4 using a hash function, and generates transaction data including a hash value obtained by hashing. The client server 11 transmits the generated transaction data to the blockchain network via the communication device 514.

[0034] Unapproved transaction data is collected into a new block 70 (the (n+1)th block in the figure). When the new block 70 is approved by the mining process, it is added to the BLC data 7. Transaction data becomes valid only after it is added to the BLC data 7 recorded in each client server 11-14. As a consensus algorithm for the mining process, for example, algorithms such as PoW (Proof of Work), PoS (Proof of Stake), and PBFT (Practical Byzantine Fault Tolerance) can be adopted.

[0035] <Associating development data> 5 is a schematic diagram for explaining a typical example of the transition of development data 4 in a development operation. It is assumed that the development data 4 that is the basis of the study is created at time t0. Hereinafter, this development data 4 is also referred to as "mainstream data."

[0036] At time t1, another development data 4 derived from the mainstream data is created and registered. This development data 4 is hereinafter also referred to as "first derived data." The first derived data may be a copy of the mainstream data in order to consider product specifications, performance, conditions, etc. The first derived data may be a conversion of the mainstream data in order to use the mainstream data in other tools for the purpose of thermal analysis, crash analysis, etc. of the mainstream data. The first derived data may be a modification of the mainstream data (or data obtained by copying the mainstream data).

[0037] Since the mainstream data itself may be updated, the mainstream data is not necessarily always unchanged after it is created. In the example of Fig. 5, the mainstream data is updated twice, at time t2 and time t3.

[0038] At time t4, another development data 4 derived from the first derived data is created and registered. This development data 4 is hereinafter also referred to as "second derived data." The second derived data is the first derived data that has been subjected to processing such as duplication, conversion, and modification.

[0039] As described above, various development data 4 can be registered (stored) in the data storage system 3 by updating the mainstream data, creating the first derived data from the mainstream data, and creating the second derived data from the first derived data. When another development data is derived by duplicating, converting, modifying, etc., a certain development data, the two development data can be said to be "related." If the related development data 4 is not properly managed, a situation such as "re-examination is required because the wrong development data 4 was used for the examination" may occur, which may increase development costs and lengthen the development period (lead time). In other words, there is a possibility that development efficiency may decrease. Therefore, in this embodiment, a hash value is generated from each development data 4, and the development data 4 is associated using the hash value.

[0040] Fig. 6 is a schematic diagram for explaining an overview of association of the development data 4 in this embodiment. In this embodiment, the association of the development data 4 is realized by linking hash values ​​to each other. In the example shown in Fig. 5 and Fig. 6, when the first derived data is created from the mainstream data at time t1 and registered, the hash value HV0 generated from the mainstream data and the hash value HV1 generated from the first derived data are linked.

[0041] Similarly, when the second derived data is created from the first derived data at time t4 and registered, the hash value HV0 generated from the mainstream data, the hash value HV1 generated from the first derived data, and the hash value HV2 generated from the second derived data are linked together. The mainstream data on which the hash value HV0 is based is not the mainstream data at times t2 and t3 when the mainstream data was updated, but the mainstream data at time t1 when the first derived data linked to the second derived data was created.

[0042] <Transaction data> Fig. 7 is a conceptual diagram for explaining linking of hash values ​​in this embodiment. Fig. 7 shows three transaction data 700 to 702 corresponding to the example explained in Fig. 6. The transaction data 700 to 702 are generated in this order.

[0043] The transaction data 700 includes a hash value HV0 generated from the mainstream data 40. The transaction data 701 includes, in addition to the hash value HV0 generated from the mainstream data 40, a hash value HV1 generated from the first derived data 41. The transaction data 702 includes, in addition to the hash value HV0 generated from the mainstream data 40 and the hash value HV1 generated from the first derived data 41, a hash value HV2 generated from the second derived data 42.

[0044] The transaction data 700 to 702, each including a hash value of the development data 4, are stored in the same block 70 (see FIG. 4). By managing the hash value of the development data 4 as part of the BLC data 7, it is possible to improve the tamper resistance of the development data 4.

[0045] Each of the transaction data 700 to 702 preferably includes the following information in addition to the hash value generated from the development data 4.

[0046] 8 is a conceptual diagram for explaining transaction data 700-702 stored in block 70 of BLC data 7 in this embodiment. The transaction data 700-702 includes, for example, a transaction ID for identifying the transaction data, a hash value HV0 of the main data, a timestamp T0 indicating the generation time of the hash value HV0, a ​​hash value HV1 of the first derived data, a timestamp T1 indicating the generation time of the hash value HV1, a hash value HV2 of the second derived data, and a timestamp T2 indicating the generation time of the hash value HV2. Although not shown due to space limitations, the transaction data may include hash values ​​and timestamps of the third and subsequent derived data.

[0047] Conversely, the transaction data does not have to include all derived data. In other words, the transaction data may include a hash value of a certain development data and a hash value of a development data from which the development data is derived, but may not include a hash value of a development data from which the development data is derived further upstream. This is because if each transaction data includes hash values ​​of two development data, it is possible to trace the hash value of the development data from which the development data is derived further upstream.

[0048] 10, a hash value is generated every time a registration operation is performed on the development data 4. Therefore, the generation time of the hash value approximately coincides with the registration time of the development data 4. Therefore, the generation time of the hash value in the transaction data can be read as the registration time of the development data 4.

[0049] It is desirable that the transaction data 700 to 702 further include the purpose of the study of the development data 4 and the processing content for the development data 4. The study purpose is, for example, an explanation of which item is to be studied for what purpose among items such as product specifications, performance, and conditions. The processing content is, for example, the change content corresponding to the difference between before and after the change. The processing content may be the content of a conversion process carried out for thermal analysis, collision analysis, and the like. The study purpose and the processing content are input as text by a user (such as a developer in charge) when processing the development data 4. This allows other users to understand the study purpose and processing content of the development data 4, making it possible, for example, to easily find the development data 4 they are looking for.

[0050] Although not shown, the transaction data 700-702 may further include time information when the transaction data is transmitted (broadcast) to the blockchain network, sender information of the transaction data (information indicating the development department or developer), an electronic signature, etc.

[0051] In this manner, in this embodiment, the relationship between the development data 4 is defined by linking hash values ​​generated from each of the development data 4 related to each other. This makes it possible for a user to confirm where the development data 4 came from, that is, the identity of the development data 4, when selecting the development data 4 for review. As a result, review using incorrect development data 4 is prevented, and therefore increases in development costs and extensions of development time can be suppressed. In other words, development efficiency can be improved.

[0052] <Function block> 9 is a functional block diagram of the client server 11 (more specifically, the control device 511) related to the management of the development data 4. The control device 511 includes a development data 4 processing unit 801, a hash generation unit 802, a digital signature unit 803, a time acquisition unit 804, a text acquisition unit 805, a transaction data generation unit 806, a transaction data acquisition unit 807, a hash extraction unit 808, a time extraction unit 809, a text extraction unit 810, and a display command unit 811.

[0053] The development data 4 processing unit 801 receives the development data 4 from the data storage system 3 via the communication device 514. The development data 4 processing unit 801 can also newly create (copy, etc.) development data 4 and process (convert, modify, etc.) the development data 4. Furthermore, the development data 4 processing unit 801 transmits the created or processed development data 4 to the data storage system 3 via the communication device 514. The development data 4 processing unit 801 also outputs the development data 4 to the hash generation unit 802.

[0054] The hash generation unit 802 generates a hash value by hashing the development data 4 received from the development data 4 processing unit 801 using a hash function. The hash generation unit 802 outputs the hash value to the digital signature unit 803 and the transaction data generation unit 806. Furthermore, although not shown, the hash generation unit 802 outputs the hash value to the data storage system 3. As a result, the development data 4 is stored in the data storage system 3 together with the hash value, as described in FIG. 2.

[0055] The digital signature unit 803 reads out the private key stored in the storage device 515. The digital signature unit 803 generates a digital signature by encrypting the hash value using the private key. The digital signature unit 803 outputs the digital signature to the transaction data generation unit 806.

[0056] The time acquisition unit 804 acquires the time (time stamp) when the transaction data is generated. The time stamp may be acquired using an internal timer (not shown) of the client server 11, or may be acquired from an external time stamp authority (not shown). The time acquisition unit 804 outputs the time stamp to the transaction data generation unit 806.

[0057] The text acquisition unit 805 acquires text data related to the purpose of the development data 4 and the processing content for the development data 4. As described above, the purpose of the development data 4 and the processing content are input as text by the user (developer). The text acquisition unit 805 outputs the text data to the transaction data generation unit 806.

[0058] The transaction data generation unit 806 generates transaction data for storing the hash value received from the hash generation unit 802 in the BLC data 7 (block 70). Furthermore, the transaction data generation unit 806 adds a digital signature from the digital signature unit 803 to the transaction data. The transaction data generation unit 806 outputs the transaction data with the digital signature added to it, together with the address of the node indicated by the destination information of the transaction data, to the communication device 514. As a result, the transaction data is transmitted to the destination node.

[0059] The transaction data acquisition unit 807 acquires the transaction data stored in the BLC data 7 in the storage device 515. The transaction data acquisition unit 807 outputs the transaction data to a hash extraction unit 808, a time extraction unit 809, and a text extraction unit 810.

[0060] The hash extraction unit 808 extracts a hash value from the transaction data (see FIG. 8). The hash extraction unit 808 identifies the development data 4 (relationship of the development data) associated by the hash values ​​linked to each other. As described above, the development data 4 is stored in the data storage system 3 together with its hash value. Therefore, it is possible to obtain the data name, data format, etc. of the development data 4 based on the hash value extracted by the hash extraction unit 808. The hash extraction unit 808 outputs each piece of information identified or obtained to the display command unit 811.

[0061] The time extraction unit 809 extracts a time stamp from the transaction data and outputs the extracted time stamp to the display command unit 811.

[0062] The text extraction unit 810 extracts text data related to the purpose of study and the processing content of the development data 4 from the transaction data. The text extraction unit 810 outputs the extracted purpose of study and the processing content to the display command unit 811.

[0063] The display command unit 811 generates a command for displaying the hash value, the time stamp, and text data related to the purpose of the study and the processing content of the development data 4 on the display device 517. The display command unit 811 outputs the generated command to the display device 517. As a result, each piece of information is displayed on the display device 517.

[0064] <Processing flow> FIG. 10 is a flowchart showing a series of processing steps for registering development data 4. The processing shown in this flowchart is called from a main routine (not shown) and executed when a predetermined condition is met (for example, at a predetermined interval). Each step is realized by software processing by the control device 511 of the client server 11. However, some or all of the steps may be realized by hardware (electronic circuitry) arranged within MS Mincho. Hereinafter, steps are abbreviated as S. The same applies to the flowchart in FIG. 11 described later.

[0065] In S101, the control device 511 executes various processes (such as duplication, conversion, and modification) on the development data 4 read from the data storage system 3 in accordance with an operation on the input device 516 by a user.

[0066] In S102, the control device 511 determines whether the input device 516 has accepted a user's operation to register the development data 4. A registration operation is an operation by the user to request registration (or storage) of the development data 4. If a registration operation has not been accepted (NO in S102), the control device 511 skips the following processing and returns the processing to the main routine. If a registration operation has been accepted (YES in S102), the control device 511 advances the processing to S103.

[0067] In S103, the control device 511 acquires text data relating to the purpose of study and the processing content of the development data 4 via the input device 516.

[0068] In S104, the control device 511 acquires a time stamp of the registration time of the development data 4 (=the generation time of the hash value in the following step).

[0069] In S105, the control device 511 hashes the latest development data 4 after the process in S101 using a hash function to generate a hash value.

[0070] In S106, the control device 511 uses the private key stored in the storage device 515 to encrypt the hash value generated in S105 to generate a digital signature.

[0071] In S107, the control device 511 generates transaction data (see FIG. 8) including each piece of information generated in the processes of S103 to S106 (text data related to the purpose of the study and the processing content of the development data 4, the time stamp of the registration time, the hash value, and the electronic signature). In addition to this information, the control device 511 may include in the transaction data time information for transmitting (broadcasting) the transaction data to the blockchain network, sender information of the transaction data, and the like.

[0072] In S108, the control device 511 outputs a command to transmit the transaction data to the blockchain network to the communication device 514. As a result, the transaction data is transmitted from the communication device 514 to the blockchain network.

[0073] In S109, the control device 511 outputs the development data 4 after the processing of S101 and the hash value generated in S105 to the data storage system 3, and also outputs a request to register (save) the development data 4 and the hash value to the data storage system 3. As a result, the development data 4 and the hash value are registered in the data storage system 3.

[0074] 11 is a flowchart showing a series of processing steps for reading the development data 4. In S201, the control device 511 judges whether the input device 516 has accepted a user's operation to read the development data 4. If the read operation has not been accepted (NO in S201), the control device 511 skips the following processing and returns the processing to the main routine. If the read operation has been accepted (YES in S201), the control device 511 advances the processing to S202.

[0075] In S202, the control device 511 acquires, from the BLC data 7 in the storage device 515, transaction data (see FIG. 8) corresponding to the development data 4 selected by the read operation in S201.

[0076] In S203, the control device 511 identifies one or more development data 4 corresponding to one or more hash values ​​included in the transaction data acquired in S202, based on the hash values. For example, when the transaction data 702 is acquired in the example of FIG. 8, the control device 511 identifies three development data 4 corresponding to the hash values ​​HV0 to HV2 linked to each other. That is, the control device 511 identifies the second derived data corresponding to the hash value HV2 as the development data 4 selected by the read operation, and identifies the first derived data corresponding to the hash value HV1 and the main stream data corresponding to the hash value HV0. The development data 4 and the hash values ​​are stored in the data storage system 3. It is preferable that the control device 511 acquires the data name of the development data 4 corresponding to the hash value from the hash value of each development data 4 from the data storage system 3.

[0077] In S204, the control device 511 extracts the timestamp of each piece of development data 4 from the transaction data.

[0078] In S205, the control device 511 extracts text data relating to the purpose of examination and the processing content of each piece of development data 4 from the transaction data.

[0079] In S206, the control device 511 controls the display device 517 to display the information acquired or extracted by the processes in S203 to S205.

[0080] Fig. 12 is a diagram showing an example of the display contents on the display device 517. As shown in Fig. 12, the display device 517 displays, for example, in a format like a table 91, the data name of the development data 4, the update time of the development data 4, the data name of the mainstream data for the development data 4, the update time of the mainstream data, the data name of the derived data for the development data 4, the update time of the derived data, text data related to the purpose of the study and the processing contents of the development data 4, and the like. By referring to this table, the user can check at a glance the relationship of the development data 4 selected by the user to other development data 4, in other words, the nature of the development data 4.

[0081] Also, the user can check the update time of each development data 4. This allows the user to judge the validity of the development data 4 by judging whether it matches the period when development work using the development data 4 was carried out. Alternatively, the user can judge whether the selected data is the latest data. Furthermore, the user can easily understand the contents of the development data 4 from the text data related to the purpose of the study and the processing contents related to the development data 4.

[0082] 11 again, in S207, the control device 511 judges whether or not a user operation to the input device 516 for confirming the development data 4 to be read has been accepted. For example, when the decision button 92 shown in FIG. 12 is clicked, the control device 511 judges that the development data 4 to be read has been confirmed. When the development data 4 to be read has been confirmed (YES in S207), the control device 511 reads the development data 4 from the data storage system 3 (S208). Thereafter, the control device 511 returns the process to the main routine.

[0083] In addition, if the development data 4 to be read is not confirmed (NO in S207), for example, when the cancel button 93 shown in Figure 12 is clicked, the control device 511 returns the processing to the main routine without reading the development data 4 from the data storage system 3.

[0084] As described above, in this embodiment, the relationships between a plurality of development data are defined using the hash values ​​stored in the BLC data 7. The defined relationships between the development data are displayed on the display device 517. This allows the user to check in advance the main stream data of the development data selected by the user, related derived data, and the like, thereby preventing an investigation starting from incorrect development data 4. Therefore, according to this embodiment, it is possible to improve development efficiency.

[0085] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present disclosure is defined by the claims, not by the description of the embodiments described above, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0086] 100 data management system, 11-14 client server, 2 platform server, 3 data storage system, 411 control device, 412 ROM, 413 RAM, 414 communication device, 415 storage device, 416 input device, 417 display device, 418 bus, 51 private key, 52 public key, 6 BLC data, 60 block, 600-602 transaction data, 7 development data 4, 70 main stream data, 71 first derived data, 72 second derived data, 801 development data 4 processing unit, 802 hash generation unit, 803 electronic signature unit, 804 time acquisition unit, 805 text acquisition unit, 806 transaction data generation unit, 807 transaction data acquisition unit, 808 hash extraction unit, 809 time extraction unit, 810 text extraction unit, 811 display command unit, 91 table, 92 decision button, 93 cancel button.

Claims

1. A data storage device for storing development data; a plurality of data management devices each having a distributed ledger in which transaction data related to the development data is stored; When registering first development data in the data storage device, if second development data from which the first development data is derived and third development data from which the second development data is derived exist, each of the multiple data management devices stores the transaction data in the distributed ledger, the transaction data including a first hash value generated from the first development data, a second hash value generated from the second development data, and a third hash value generated from the third development data; the second hash value is generated from the second development data when the first development data is derived from the second development data; The data management system according to claim 1, wherein the third hash value is generated from the third development data when the second development data is derived from the third development data.

2. The plurality of data management devices include first transaction data including a first time stamp indicating a generation time of the first hash value and first text data relating to a review purpose and a processing content of the first development data; second transaction data including a second time stamp indicating a generation time of the second hash value and second text data related to a review purpose and a processing content of the second development data; 2. The data management system according to claim 1, further comprising: a third transaction data generating unit configured to generate a third transaction data including a third timestamp indicating the time when the third hash value was generated and third text data relating to the purpose of the review and the processing content of the third development data.

3. The plurality of data management devices include a display device that displays update times of the first development data to the third development data based on the first time stamp to the third time stamp, and also displays a review purpose and a processing content of the first development data to the third development data based on the first text data to the third text data; an input device that accepts an operation by a user who has confirmed a display on the display device to select one of the first development data to the third development data; 3. The data management system according to claim 2, further comprising a control device for reading the development data selected by the user from the data storage device.

Images