CN107766521B - Power grid planning data version control method - Google Patents
Power grid planning data version control method Download PDFInfo
- Publication number
- CN107766521B CN107766521B CN201711006395.6A CN201711006395A CN107766521B CN 107766521 B CN107766521 B CN 107766521B CN 201711006395 A CN201711006395 A CN 201711006395A CN 107766521 B CN107766521 B CN 107766521B
- Authority
- CN
- China
- Prior art keywords
- data
- version
- data warehouse
- warehouse
- local
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/219—Managing data history or versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/06—Electricity, gas or water supply
Abstract
The invention relates to the field of power grid planning informatization, and discloses a method for controlling a power grid planning data version. The method comprises the following steps: step 1, modeling a database of power grid planning data; step 2, hijacking a database access interface and recording all data change logs; step 3, carrying out a data change content agreement step 4, and submitting the agreement content to a local data warehouse to form a version; step 5, comparing the versions with a central data warehouse to determine synchronous contents; step 6, merging the data difference parts in the central data warehouse and the local data warehouse, if the data conflict is resolved to form a new version, returning to the step 5, and if no data conflict exists, entering the next step; and 7, submitting the difference part between the local data warehouse and the central data warehouse to finish the sharing of the data version. According to the scheme, all change conditions of power grid planning data can be recorded, any historical version can be traced back, and data version combination among multiple persons can be achieved.
Description
Technical Field
The invention relates to the technical field of power grid planning informatization, in particular to a method for controlling a power grid planning data version.
Background
Among factors restricting the planning efficiency of the power grid, the data cooperation problem among different planners also influences the planning efficiency to a great extent. In the conventional data collaborative service, planning personnel of a plurality of units are often required to be gathered together, design data are compared line by line, and a great deal of careful and patience work is carried out to obtain a combined product data. How to invent a new method for planning data version control realizes the cooperation of an automatic version management version to replace the traditional manual data version control mode, can obviously improve the efficiency of planning work, and is also a hotspot problem in the field of power grid planning informatization.
The reasonable data version control method for planning can meet the requirement of local version management and can support data collaboration among multiple persons. Can realize submitting and backtracking: the design achievement and the engineering document are stored as a historical version, and a user can check which data among different versions are changed according to needs and can trace back to a certain specified version. Push and merge can also be achieved: the data difference between the local computer and other designers is compared, the local computer data is pushed to other people, the data of other people is merged into the local computer, and a conflict resolution mechanism is supported at the place where the data conflict occurs. Finally, the accurate data collaboration can be realized only by simple push and download operations among planning personnel, and the workload brought by the data collaboration is fundamentally saved.
Therefore, the method for researching the version control of the power grid planning data has important significance for the development of the power grid planning technology.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: aiming at the existing problems, a method for controlling the version of the power grid planning data is provided.
The technical scheme adopted by the invention is as follows: a method for controlling the version of power grid planning data specifically comprises the following processes:
step 1, modeling a database of power grid planning data;
step 2, hijacking a database access interface and recording all data change logs;
step 3, carrying out data change content agreement;
step 4, submitting the protocol content to a local data warehouse to form a version;
step 5, comparing the versions with a central data warehouse to determine synchronous contents;
step 6, merging the data difference parts in the central data warehouse and the local data warehouse, if the data conflict is resolved to form a new version, returning to the step 5, and if no data conflict exists, entering the next step;
and 7, submitting the difference part between the local data warehouse and the central data warehouse to finish the sharing of the data version.
Further, in step 2, all data change logs are recorded, and the data change types include:
a. adding a log to the table;
b. a table update log;
c. deleting the log from the table;
d. adding logs to fields;
e. a field update log;
f. deleting the log from the field;
g. recording an addition log;
h. recording an update log;
i. and recording the deletion log.
Further, in the log added in the step 2 g, in order to ensure that the added record does not have a duplicate number, an algorithm for creating a 16-bit unique Id number is compiled, wherein the Id number comprises: year, sequence seconds, sequence milliseconds, random sequence.
Further, the data change content in step 3 is agreed, specifically, a character string is used for recording data change, and the serialization of the data change is supported as a character string; and the method also supports the deserialization of the character strings into data change, and the lossless bidirectional conversion between the data change and the character strings forms the basis of data versioning and data exchange.
Further, the data change content in step 3 is agreed, and the types of data fields that can be acted by the agreement include: a Boolean type; a character type; numerical type; the time type does not include the byte type and the multimedia type.
Further, the step 4 specifically includes the following steps:
step 41, checking the modified data;
42, abandoning modification and recovery;
step 43, submitting to a local data warehouse and generating a new version.
Further, the step 43 includes the following processes:
step 431, adding a version number to the data submitted to the local data warehouse;
step 432, adding version details;
step 433, deleting the change log;
and 434, changing the current status of the version.
Further, the step 5 specifically includes the following steps:
step 51, extracting a local data warehouse version tree;
step 52, extracting a central data warehouse version tree;
step 53, the single table executes the version alignment operation;
after alignment, if the central data warehouse version is more than the local data warehouse, it is the content to be synchronized.
Further, the step 6 specifically includes the following steps:
step 61, comparing versions of the central data warehouse and the local data warehouse, and only synchronizing partial data changed by the central data warehouse;
step 62, data packaging is carried out on the data to be changed, and if a plurality of versions of a record are changed for a plurality of times, only the latest version is selected;
step 63, comparing the data with the existing records one by one, and judging whether the data conflict or not;
step 64, under the condition of no conflict, modifying the data of the local data warehouse to form a new version, and successfully combining;
and 65, under the condition of conflict, resolving the conflict firstly and failing to combine.
Further, the conflict types in step 63 include:
(1) deleting the table when any table data is changed;
(2) tables are added, but the fields are not consistent;
(3) adding fields of the same name and different types;
(4) modifying a field encounters a delete field;
(5) adding the same id record;
(6) adding a record while the same id record already exists;
(7) modifying the same attribute of the same record;
(8) deleting a record encounters editing a record.
Further, the step 7 specifically includes the following steps:
step 71, successfully executing data merging, and determining that no more data can be merged from the central data warehouse;
step 72, extracting a local data warehouse version tree, extracting a central data warehouse version tree, executing version alignment operation, and finding out the difference part between the local data warehouse and the central data warehouse, namely finding out the incremental data packet to be submitted;
step 73, pushing the incremental data packet to a central data warehouse;
and step 74, forming a new data version in the central data warehouse, and successfully sharing the data version and finishing.
In summary, due to the adoption of the technical scheme, the invention has the beneficial effects that: firstly, all slight change conditions of power grid planning data can be recorded, and personal incremental design work can be carried out by submitting a new version or giving up the current change; secondly, the system can roll back to any one historical version to ensure that all past submissions can be effectively recorded; and finally, merging of data versions among multiple persons can be realized, data exchange and conflict processing are completed, and the goal of team collaborative design is finally achieved.
Drawings
The invention will now be described, by way of example, with reference to the accompanying drawings, in which:
fig. 1 is a schematic flow chart of a method for controlling version of power grid planning data according to the present invention.
FIG. 2 is a schematic diagram of a power grid databased data model of the present invention.
Detailed Description
All of the features disclosed in this specification, or all of the steps in any method or process so disclosed, may be combined in any combination, except combinations of features and/or steps that are mutually exclusive.
Any feature disclosed in this specification may be replaced by alternative features serving equivalent or similar purposes, unless expressly stated otherwise. That is, unless expressly stated otherwise, each feature is only an example of a generic series of equivalent or similar features.
As shown in fig. 1, a method for controlling a power grid planning data version specifically includes the following processes: step 1, modeling a database of power grid planning data; step 2, hijacking a database access interface and recording all data change logs; step 3, carrying out data change content agreement; step 4, submitting the protocol content to a local data warehouse to form a version; step 5, comparing the versions with a central data warehouse to determine synchronous contents; step 6, merging the data difference parts in the central data warehouse and the local data warehouse, if the data conflict is resolved to form a new version, returning to the step 5, and if no data conflict exists, entering the next step; and 7, submitting the difference part between the local data warehouse and the central data warehouse to finish the sharing of the data version.
In the modeling process of the database, the data storage is divided into the following 3 parts: (1) the personal working directory realizes the database storage of a plurality of power grid planning data, namely the most conventional data persistence mode; (2) the personal data warehouse is used for storing all data versions and change details of the local computer and submitting the edited planning result data to the local data warehouse, the local data warehouse can record the detailed historical condition submitted each time, and designers can perform operations of submitting the power planning design result, cancelling the previous power planning design result, giving up the editing and the like under the offline condition; c. and the central data warehouse is used for storing the data version and the change details of the whole team, uploading the latest power planning design result in the local data warehouse to the central data warehouse in an online mode, downloading and combining the power planning design result uploaded to the central data warehouse by other people, and realizing multi-user collaborative editing.
As shown in fig. 2, the power grid planning device of the database includes elements of power stations, lines, converter stations, transformer stations, switchgears, and serial-complement stations. Firstly, modeling a database of all power grid planning data, wherein the database after model establishment comprises the following data contents: (1) a geographical wiring diagram; (2) a single line drawing component card; (3) and (5) designing a result of the scheme. Table 1 below is the identity and main contents of the grid database, the project design database, the BPA database.
TABLE 1
Preferably, in step 2, all data change logs are recorded, and the data change types include: a. adding a log to the table; b. a table update log; c. deleting the log from the table; d. adding logs to fields; e. a field update log; f. deleting the log from the field; g. recording an addition log; h. recording an update log; i. and recording the deletion log. All grid planning data are assigned the following distinguishable states on a log basis, as shown in table 2 below.
TABLE 2
Preferably, in the log added to the record in step 2 g, in order to ensure that no duplicate numbers appear in the added record, an algorithm for creating a 16-bit globally unique Id number is compiled, where the Id number includes: year, 2, the last two thousand years, for example, 2017, 17; sequence second, which takes 8 bits, the current time is the second in a year; sequence milliseconds, which take 4 bits, and the current time is the second millisecond within one second; the random sequence, which occupies 2 bits, is randomly generated. A practical example is generated such as "1718710533744796" according to the Id number algorithm described above. If all data elements adopt the unique Id algorithm, the Id conflict can be avoided under the condition that multiple persons have multiple versions.
Preferably, the content of the data change in step 3 is agreed, specifically, a character string is used to record the data change. The data version and data exchange foundation is formed by lossless bidirectional conversion between the data change and the character string. The encoding mode of the serial protocol comprises the following steps: a "86 HF _" force head; b. a table name; c. a unique Id; d. subsequent fields, for example, as one record in table 3 below:
TABLE 3
| NO. | Name of field | Value taking |
| 1 | id | 1718995745881200 |
| 2 | parent_domain_id | 1 |
| 3 | field0 | 2 |
| 4 | field1 | 3 |
| 5 | field2 | 0.4 |
| 6 | … | … |
The final agreement is:
86HF_git_demo table，id，id，1718995745881200，parent_domain_id，1，field0，2，field1，3，field2，0.4，field3，2.5，field4，StringField，field5，2015-01-01，field6，&true，field7，7&comma7，field8，&false，field9，1，fieldl0，2，field11，3，field12，4，field13，5，field14，2015-01-0100：00：00#。
preferably, the data change content in step 3 is agreed, and the types of data fields that can be acted by the agreement include: a Boolean type; a character type; numerical type; the time type does not include the byte type and the multimedia type.
Preferably, the step 4 of submitting the agreed content to the local data warehouse to form the version includes the following steps: step 41, checking the modified data; 42, abandoning modification and recovery; step 43, submitting to a local data warehouse and generating a new version. For example: a new province of 220KV feeder lines need to be added, and after the addition is finished, a result version is temporarily stored in a local data warehouse; or the transformer substation in the first floor is deleted by mistake and needs to be retrieved from the local data warehouse without loss.
Preferably, the process of submitting to the local data warehouse and generating the new version in step 43 comprises the following steps: step 431, adding a version number to the data submitted to the local data warehouse; step 432, adding version details; step 433, deleting the change log; and 434, changing the current status of the version. The version number and the version details belong to a parent-child relationship, and one version corresponds to a plurality of version details, for example, 2 substations and 1 line are added, and one version is generated by submitting the version number and the version details. The structure of the version detail is as follows:
| name (name) | Type (B) | Length of | Decimal point |
| detail_id | bigint | 20 | 0 |
| parent_log_id | bigint | 20 | 0 |
| table_name | varchar | 80 | 0 |
| opr_type | smallint | 6 | 0 |
| row_id | bigint | 20 | 0 |
| old_row_data | longtext | 0 | 0 |
| new_row_data | longtext | 0 | 0 |
The fields 'old _ row _ data' and 'new _ row _ data' before and after the change of the single record are stored in the data object after the protocol stated before.
Preferably, the step 5 specifically includes the following processes: step 51, extracting a local data warehouse version tree; step 52, extracting a central data warehouse version tree; step 53, the single table executes the version alignment operation; after alignment, if the central data warehouse version is more than the local data warehouse, it is the content to be synchronized.
Preferably, the step 6 specifically includes the following processes: step 61, comparing versions of the central data warehouse and the local data warehouse, and only synchronizing partial data changed by the central data warehouse; step 62, data packaging is carried out on the data to be changed, and if a plurality of versions of a record are changed for a plurality of times, only the latest version is selected; step 63, comparing the data with the existing records one by one, and judging whether the data conflict or not; step 64, under the condition of no conflict, modifying the data of the local data warehouse to form a new version, and successfully combining; and 65, under the condition of conflict, resolving the conflict firstly and failing to combine. In actual implementation, one of the two most commonly used operations, downloading data from the central data warehouse and automatically merging the data into the local data warehouse and the design personal work catalog, includes the following algorithm rules: (1) if some element class is not edited locally, the element class is automatically kept consistent with the central data warehouse; (2) if some element class is locally edited, comparing single primitives, reserving the locally edited primitives, and automatically merging the primitives edited by other designers into the local machine; (3) if a single graphic element is edited locally by other designers, the system automatically gives a prompt to keep local or other designers; (4) after all the merging and conflict resolution, a new data version is formed locally, and a design working directory is automatically covered; (5) if the local data is damaged unexpectedly, part of the unexpectedly damaged data can be retrieved and repaired by using the operation; (6) under the support of the pull command, the electric power planning design result cannot be lost due to unexpected reasons such as hardware faults and the like, and in any case, a designer can find back own planning result data through the pull command.
Preferably, the conflict type in step 63 is regarded as a data conflict, such as the following situations: (1) deleting the table when any table data is changed; (2) tables are added, but the fields are not consistent; (3) adding fields of the same name and different types; (4) modifying a field encounters a delete field; (5) adding the same id record; (6) adding a record while the same id record already exists; (7) modifying the same attribute of the same record; (8) deleting a record encounters editing a record.
Preferably, the step 7 specifically includes the following processes: step 71, successfully executing data merging, and determining that no more data can be merged from the central data warehouse; step 72, extracting a local data warehouse version tree, extracting a central data warehouse version tree, executing version alignment operation, and finding out the difference part between the local data warehouse and the central data warehouse, namely finding out the incremental data packet to be submitted; step 73, pushing the incremental data packet to a central data warehouse; and step 74, forming a new data version in the central data warehouse, and successfully sharing the data version and finishing. In practical implementation, one of the two most commonly used operations is to temporarily store the power planning and design result edited by the local computer into a local data warehouse, compare and combine the results, and upload the result to a central data warehouse for sharing by all designers, wherein the two operations include the following algorithm rules: (1) before uploading, pull operation is automatically carried out, and the fact that the push is established on the data comparison with the latest version of the central data warehouse is ensured; (2) before uploading, automatic merging and conflict resolution tests are firstly carried out in the local data warehouse, and the data are submitted to the central server after being confirmed to be correct, so that the risk of data merging is isolated in the local data warehouse, the data cannot spread to the central data warehouse, and the data which are being designed by the local data warehouse cannot be influenced; (3) designers can frequently upload own periodic power planning and design results (1 hour and half a day) to the central data warehouse through push commands, so that the power planning and design results can be shared, and the own power planning and design results can be well backed up in the central data warehouse.
One embodiment is as follows:
and carrying out power grid planning for the next five years for the province A in the southwest, and allocating work according to the configuration of one full-time planning worker in each region of the province A in the province A. As the traditional file type data version control is adopted throughout the years in the province A, a set of independent data is respectively provided in different provinces, different years, different big, small and big modes. If the automatic data version control cannot be realized, after each area is respectively planned, a large amount of time is spent for processing the problem of data combination of the cross-area planning results, once a person has a hand mistake, the data of other areas are wrongly modified, and the whole team needs to expend huge energy to compare line by line so as to find out the part of the planning conflicts. Obviously, under the condition that automatic data version control cannot be realized, the number of people in collaborative design is increased, the cost of data collaboration is increased in a geometric progression, and the increase of the collaborative cost is a main symptom that the large-scale collaborative design cannot be performed in the power grid planning industry.
The method for controlling the power grid planning data version is utilized to realize automatic data collaboration, any power grid planning personnel can divide the whole process into a plurality of stages, each stage submits a data version, and the versions are stored in a local data warehouse in an incremental mode. The power grid planner can perform daily design work under the support of the versions, and can select to submit the edition to the local data warehouse to form the edition, abandon the edited part to restore to the latest edition, and check or rollback the edited part to a designated historical edition according to requirements.
Under the support of the data warehouse of the machine, automatic data combination and data sharing can be realized among multiple people. And merging the difference part of the central data and the local data. All planners can support frequent data updating, merging, submitting and conflict solving of team properties through simple pull operation and push operation, online synchronous data collaboration of the whole team is completed, and finally a technical foundation is laid for large-scale team collaborative design in the power grid planning industry.
The invention is not limited to the foregoing embodiments. The invention extends to any novel feature or any novel combination of features disclosed in this specification and any novel method or process steps or any novel combination of features disclosed.
Claims (4)
1. A method for power grid planning data version control is characterized by comprising the following processes:
step 1, modeling a database of power grid planning data;
step 2, hijacking a database access interface and recording all data change logs;
step 3, carrying out data change content agreement;
step 4, submitting the protocol content to a local data warehouse to form a version;
step 5, comparing the versions with a central data warehouse to determine synchronous contents;
step 6, merging the data difference parts in the central data warehouse and the local data warehouse, if the data conflict is resolved to form a new version, returning to the step 5, and if no data conflict exists, entering the next step;
step 7, submitting the difference part between the local data warehouse and the central data warehouse to complete the sharing of the data version;
the data change content in the step 3 is agreed, specifically, a character string is used for recording data change, and the serialization of the data change is supported as the character string; the types of data fields that the protocol can act on include: a Boolean type; a character type; numerical type; time type, not including byte type and multimedia type;
the data change content in the step 3 is agreed, specifically, a character string is used for recording data change, and the serialization of the data change is supported as the character string; the types of data fields that the protocol can act on include: a Boolean type; a character type; numerical type; a time type;
the step 4 specifically comprises the following steps:
step 41, checking the modified data;
42, abandoning modification and recovery;
step 43, submitting to a local data warehouse and generating a new version;
the step 43 includes the following processes:
step 431, adding a version number to the data submitted to the local data warehouse;
step 432, adding version details;
step 433, deleting the change log;
step 434, changing the current status of the version;
the step 5 specifically comprises the following steps:
step 51, extracting a local data warehouse version tree;
step 52, extracting a central data warehouse version tree;
step 53, the single table executes the version alignment operation;
step 54, after alignment, if the version of the central data warehouse is more than that of the local data warehouse, the contents to be synchronized are obtained;
the step 6 specifically comprises the following steps:
step 61, comparing versions of the central data warehouse and the local data warehouse, and only synchronizing partial data changed by the central data warehouse;
step 62, data packaging is carried out on the data to be changed, and if a plurality of versions of a record are changed for a plurality of times, only the latest version is selected;
step 63, comparing the data with the existing records one by one, and judging whether the data conflict or not;
step 64, under the condition of no conflict, modifying the data of the local data warehouse to form a new version, and successfully combining;
step 65, under the condition of conflict, firstly resolving conflict and failing to combine;
the step 7 specifically comprises the following steps:
step 71, successfully executing data merging, and determining that no more data can be merged from the central data warehouse;
step 72, extracting a local data warehouse version tree, extracting a central data warehouse version tree, executing version alignment operation, and finding out the difference part between the local data warehouse and the central data warehouse, namely finding out the incremental data packet to be submitted;
step 73, pushing the incremental data packet to a central data warehouse;
and step 74, forming a new data version in the central data warehouse, and successfully sharing the data version and finishing.
2. The method for controlling the version of the power grid planning data according to claim 1, wherein in the step 2, all data change logs are recorded, and the data change types include:
a. adding a log to the table;
b. a table update log;
c. deleting the log from the table;
d. adding logs to fields;
e. a field update log;
f. deleting the log from the field;
g. recording an addition log;
h. recording an update log;
i. and recording the deletion log.
3. The method for controlling the version of the power grid planning data according to claim 2, wherein in the g of the step 2, the added log is recorded, and in order to ensure that the added log does not have a duplicate number, an algorithm for creating a 16-bit unique Id number is compiled, wherein the Id number comprises: year, sequence seconds, sequence milliseconds, random sequence.
4. The method for power grid planning data versioning according to claim 1, wherein the conflict types in step 63 include:
(1) deleting the table when any table data is changed;
(2) tables are added, but the fields are not consistent;
(3) adding fields of the same name and different types;
(4) modifying a field encounters a delete field;
(5) adding the same id record;
(6) adding a record while the same id record already exists;
(7) modifying the same attribute of the same record;
(8) deleting a record encounters editing a record.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711006395.6A CN107766521B (en) | 2017-10-25 | 2017-10-25 | Power grid planning data version control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711006395.6A CN107766521B (en) | 2017-10-25 | 2017-10-25 | Power grid planning data version control method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107766521A CN107766521A (en) | 2018-03-06 |
| CN107766521B true CN107766521B (en) | 2021-12-14 |
Family
ID=61271498
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711006395.6A Active CN107766521B (en) | 2017-10-25 | 2017-10-25 | Power grid planning data version control method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107766521B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108647268A (en) * | 2018-04-28 | 2018-10-12 | 国网湖南省电力有限公司 | Increment updating method for distribution network planning data integration |
| CN111143315A (en) * | 2019-12-27 | 2020-05-12 | 贵州电网有限责任公司 | Version management method of transformer substation secondary circuit information model based on Git |
| CN112162970B (en) * | 2020-09-04 | 2022-03-29 | 华南理工大学 | Basic data maintenance method, enterprise side client, client side client and cloud server |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103823797A (en) * | 2012-11-16 | 2014-05-28 | 镇江诺尼基智能技术有限公司 | FTP (file transfer protocol) based real-time industry database data synchronization system |
| CN105930439A (en) * | 2016-04-20 | 2016-09-07 | 国电南瑞科技股份有限公司 | System and method for managing multiple versions of power grid model |
| CN105976262A (en) * | 2016-05-09 | 2016-09-28 | 国电南瑞科技股份有限公司 | Power plant granularity based power grid model version sharing method |
| CN106372301A (en) * | 2016-08-29 | 2017-02-01 | 西电通用电气自动化有限公司 | Method and system for detecting visualization and configuration consistency of configuration file of intelligent substation |
| CN106780157A (en) * | 2017-03-13 | 2017-05-31 | 国电南瑞科技股份有限公司 | Power network multi-time Scales model storage and management system and method based on Ceph |
| CN107292759A (en) * | 2016-04-10 | 2017-10-24 | 国网山东省电力公司经济技术研究院 | Distribution network planning based on power supply reliability calculates analysis system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9684680B2 (en) * | 2011-07-12 | 2017-06-20 | General Electric Company | Version control methodology for network model |
| CN102917020B (en) * | 2011-09-24 | 2016-02-17 | 国网电力科学研究院 | A kind of method of mobile terminal based on packet and operation system data syn-chronization |
| US20150149371A1 (en) * | 2013-11-27 | 2015-05-28 | Red Ball Express, LLC | System And Method For Generating And Formatting Formally Correct Case Documents From Rendered Semantic Content |
| CN104834700A (en) * | 2015-04-27 | 2015-08-12 | 南京邮电大学 | Method for capturing movement data increment based on track change |
| CN105790441B (en) * | 2016-05-02 | 2019-03-22 | 国家电网公司 | A kind of intelligent substation relay protection cruising inspection system |
-
2017
- 2017-10-25 CN CN201711006395.6A patent/CN107766521B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103823797A (en) * | 2012-11-16 | 2014-05-28 | 镇江诺尼基智能技术有限公司 | FTP (file transfer protocol) based real-time industry database data synchronization system |
| CN107292759A (en) * | 2016-04-10 | 2017-10-24 | 国网山东省电力公司经济技术研究院 | Distribution network planning based on power supply reliability calculates analysis system |
| CN105930439A (en) * | 2016-04-20 | 2016-09-07 | 国电南瑞科技股份有限公司 | System and method for managing multiple versions of power grid model |
| CN105976262A (en) * | 2016-05-09 | 2016-09-28 | 国电南瑞科技股份有限公司 | Power plant granularity based power grid model version sharing method |
| CN106372301A (en) * | 2016-08-29 | 2017-02-01 | 西电通用电气自动化有限公司 | Method and system for detecting visualization and configuration consistency of configuration file of intelligent substation |
| CN106780157A (en) * | 2017-03-13 | 2017-05-31 | 国电南瑞科技股份有限公司 | Power network multi-time Scales model storage and management system and method based on Ceph |
Non-Patent Citations (1)
| Title |
|---|
| 基于版本化模型的配电网辅助设计系统的实现;陈荣权等;《电力信息化》;20110815;第24-27页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107766521A (en) | 2018-03-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107766521B (en) | Power grid planning data version control method | |
| CN101167048B (en) | Generation of aggregatable dimension information within a multidimensional enterprise software system | |
| US20080140732A1 (en) | Method and system for sharing file based data | |
| CN100492370C (en) | Document management method facing to integration business model | |
| CN104598610A (en) | Step-by-step database data distribution uploading and synchronizing method | |
| CN104731596A (en) | Classification compiling method supporting several persons to online compile XBRL | |
| CN109472446B (en) | BIM model-based engineering budget estimate planning method | |
| CN105224527A (en) | Be applicable to the general ETL method of multiple object table update mode | |
| CN101685452B (en) | Data warehouse scheduling method and scheduling system | |
| CN102999524A (en) | Method and system for searching document association | |
| CN106780157B (en) | Ceph-based power grid multi-temporal model storage and management system and method | |
| CN106802928B (en) | Power grid historical data management method and system | |
| CN100485640C (en) | Cache for an enterprise software system | |
| CN110399142B (en) | Method and system for isolating gray scale from production environment version | |
| CA2398814C (en) | System for controlling and monitoring a process | |
| CN113407230B (en) | Intelligent main model management system based on data driving | |
| CN104750849A (en) | Method and system for maintaining tree structure-based directory relationship | |
| CN115759562A (en) | Logic relation and construction period calculation algorithm of preventive maintenance work order for overhaul of nuclear power plant | |
| KR20050061557A (en) | Data processing method and data processing program | |
| CN100576806C (en) | Logical difference construction system data integration method in the peer-to-peer network | |
| CN113568921A (en) | Multi-person cooperative operation method for geographic information data production and update | |
| CN104375939B (en) | A kind of method and system of Version Control | |
| CN112381228B (en) | Knowledge system construction and application method based on business | |
| Kalay | A database management approach to CAD/CAM systems integration | |
| CN101216910B (en) | Isomorphic model merging method in the modeling of distributed enterprises |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |