Downhole operation management system, method and device based on wireless positioning and electronic equipment

Abstract

The invention provides a downhole operation management system, method and device based on wireless positioning and electronic equipment, and the system comprises a downhole record management module, a trajectory tracking module, a dynamic attendance module, and a multi-level cache realized through a memory object and Redis. The data storage module is used for storing data generated by the well descending record management module, the trajectory tracking module and the dynamic attendance module. According to the scheme disclosed by the invention, real-time updating and query of the label state can be supported, the attendance checking rules of all enterprises can be flexibly adapted, and the efficiency and accuracy of underground operation management are improved.

Description

Technical Field

[0001] The present disclosure relates to the field of industrial safety technologies, and particularly to an underground operation management system, method, device, and electronic device based on wireless positioning. Background Art

[0002] Currently, in China, most mines adopt wireless positioning technologies such as UWB to manage operating personnel and vehicles. Traditional underground operation management often relies on a single database or simple threshold judgment, and there are mainly the following problems:

[0003] 1) Inaccurate recording: The tunnel or underground environment is complex, and the base station signals are easily interfered with, resulting in misjudgment of the entry and exit status of personnel or vehicles.

[0004] 2) Poor real-time performance: Frequent reading and writing of the traditional database lead to response delays and cannot meet the requirements of high-concurrency scenarios.

[0005] 3) Rigid attendance rules: Rules such as shifts, early arrivals and late departures cannot be dynamically adapted to complex scenarios such as across days and overtime.

[0006] 4) Lack of trajectory tracking: It is impossible to accurately record the stay duration in the operation area, and it is difficult to analyze the operation path and efficiency.

[0007] 5) Different times for multiple trajectory data: According to the requirements of the state and regulatory agencies at all levels, the times of multiple trajectories must be consistent. For example, the time of going down the well must be equal to the start time of the wellhead area group (if any), and at the same time, the time of going down the well must be equal to the start time of the first regional trajectory; the time of coming out of the well must be equal to the leaving time of the wellhead area group (if any), and at the same time, the time of coming out of the well must be equal to the leaving time of the last regional trajectory; the start time of the regional group trajectory must be equal to the start time of the first regional trajectory included therein; the end time of the regional group trajectory must be equal to the end time of the last regional trajectory included therein. The regional trajectory times must be connected end to end, and no gaps are allowed. Traditional processing methods process multiple types of data such as going-down-the-well records, regional group trajectories, and regional trajectories separately, and often the times of each data are inconsistent. Some enterprises, in order to reduce the pressure on the database, adopt the method of statistically calculating the regional group trajectory based on the regional trajectory to indirectly meet the requirements of regional group statistics, resulting in low processing efficiency and high implementation complexity.

[0008] Based on this, there is an urgent need to achieve efficient and accurate management of underground operations. Summary of the Invention

[0009] The present invention provides an underground operation management system, method, device, and electronic device based on wireless positioning, which are used to solve the deficiencies of low efficiency, high misjudgment rate, poor real-time performance, and rigid rules in traditional management methods.

[0010] The present invention solves the above technical problems through the following aspects:

[0011] In a first aspect, the present invention provides an underground operation management system based on wireless positioning, comprising:

[0012] A downhole record management module for generating and recording real-time data of the tag going downhole and coming uphole;

[0013] A trajectory tracking module for aggregating the positioning data of the tag based on a pre-divided operation area according to the real-time data generated by the downhole record management module, generating a continuous trajectory of the tag, and calculating the residence time of the tag in the corresponding operation area;

[0014] A dynamic attendance module for calculating the working hours of the tag according to the residence time of the tag in the corresponding operation area and a preset attendance rule;

[0015] A multi-level cache implemented by a memory object and Redis for storing the data generated by the downhole record management module, the trajectory tracking module, and the dynamic attendance module.

[0016] In a second aspect, the present invention provides an underground operation management method based on wireless positioning, which uses the aforementioned underground operation management system. This method includes:

[0017] After receiving the positioning data of the tag, execute the downhole record initialization logic corresponding to the tag;

[0018] When the tag is in the wellhead area, determine that the tag is coming uphole and execute the tag coming uphole logic;

[0019] When the tag is not in the wellhead area and the first reading time and the number of readings of the tag underground meet the conditions, determine that the tag has reached underground;

[0020] When it is determined that the tag has reached underground, execute the tag downhole record processing logic to generate a downhole record corresponding to the tag;

[0021] Call the area group trajectory processing logic with the downhole time in the downhole record as a parameter;

[0022] Call the area trajectory processing logic with the start time of the area group trajectory as a parameter.

[0023] In a third aspect, the present invention provides an underground operation management device based on wireless positioning, which uses the aforementioned underground operation management system. This device includes:

[0024] An initialization module for executing the downhole record initialization logic corresponding to the tag after receiving the positioning data of the tag;

[0025] The uphole processing module is used to determine that the tag is ascending the well and execute the tag uphole logic when the tag is in the wellhead area;

[0026] The downhole processing module is used to determine that the tag reaches the downhole when the tag is not in the wellhead area and the first read time underground and the number of times the tag is read underground meet the conditions;

[0027] The downhole record generation module is used to execute the tag downhole record processing logic to generate a downhole record corresponding to the tag when it is determined that the tag reaches the downhole;

[0028] The area group processing module is used to call the area group trajectory processing logic with the downhole time in the downhole record as a parameter,

[0029] The area processing module is used to call the area trajectory processing logic with the start time of the area group trajectory as a parameter.

[0030] In a fourth aspect, the present invention provides an electronic device for underground operation management. This electronic device includes at least one processor, as well as a memory and a data interface that are communicatively connected to the processor; the memory stores instructions executable by the processor, and when these instructions are executed by the processor, they can implement the foregoing method; the data interface is used to obtain the positioning data of the tag for the processor to process, and store the process data generated by the processor into the corresponding buffer. The buffer among them is the foregoing multi-level buffer.

[0031] The technical solution of the present invention has the following beneficial effects: By using the multi-level buffer mechanism to record the tag status in real time, the access to the database is reduced, and the data reading is efficient; Based on the area group to aggregate the scattered base station data, generate a continuous trajectory, and filter out short-term invalid stays through thresholds, improving the accuracy of trajectory tracking and being able to track the tag trajectory in real time; By caching the shift and attendance rules, and combining the cross-day type to adjust the work recording date, the attendance rules can be dynamically matched, achieving the purpose of accurately recording the work hours; By processing the downhole records asynchronously with multiple threads and avoiding data conflicts between multiple tags through a concurrent queue, the processing process is efficient and has a low error rate. The solution of the present invention can support the real-time update and query of the tag status, and can flexibly adapt to the attendance rules of each enterprise, improving the efficiency and accuracy of underground operation management. Description of the Drawings

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in the present disclosure. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0033] Figure 1 Block diagram of an underground operation management system based on wireless positioning provided by an embodiment of the present disclosure;

[0034] Figure 2 Flowchart of an underground operation management method based on wireless positioning provided by an embodiment of the present disclosure;

[0035] Figure 3 Schematic diagram of the data flow for downhole record processing in an embodiment of the present disclosure;

[0036] Figure 4 Schematic diagram of the data flow for personnel ascending the shaft in an embodiment of the present disclosure;

[0037] Figure 5 Schematic diagram of the data flow for processing the trajectory of a regional group in an embodiment of the present disclosure;

[0038] Figure 6 Schematic diagram of the data flow for processing the trajectory of a region in an embodiment of the present disclosure;

[0039] Figure 7 Block diagram of an underground operation management device provided by an embodiment of the present disclosure. Detailed implementation manners

[0040] In order to enable those skilled in the art to better understand the technical solutions in the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present disclosure without creative efforts shall fall within the scope of protection of the present disclosure. In addition, for clarity, parts irrelevant to the description of the exemplary embodiments are omitted in the drawings.

[0041] In this specification, it should be understood that terms such as "including" or "having" are intended to indicate the presence of the features, numbers, steps, actions, components, parts, or combinations thereof disclosed in the present disclosure, and are not intended to exclude the possibility of the presence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof. Additionally, it should be noted that, without conflict, the embodiments in the present disclosure and the features in the embodiments may be combined with each other.

[0042] Figure 1 Block diagram of an underground operation management system based on wireless positioning provided by an embodiment of the present disclosure.

[0043] As Figure 1As shown, the underground operation management system 100 based on wireless positioning includes a downhole record management module 110, a trajectory tracking module 120, a dynamic attendance module 130, and a multi-level cache 140. The system 100 can be implemented as part or all of an electronic device through software, hardware, or a combination of both.

[0044] The downhole record management module 110 is used to generate and record the real-time data of the tag going down and coming up from the well.

[0045] The trajectory tracking module 120 is used to aggregate the positioning data of the tag based on the real-time data generated by the downhole record management module 110 in a pre-divided operation area, generate a continuous trajectory of the corresponding tag, and calculate the residence duration of the tag in the corresponding operation area. This module can achieve the purpose of real-time tracking of the tag trajectory.

[0046] The dynamic attendance module 130 is used to calculate the working hours of the tag according to the residence duration of the tag in the corresponding operation area and the preset attendance rules.

[0047] The multi-level cache 140 is implemented through a memory object and Redis, and is used to store the data generated by the downhole record management module 110, the trajectory tracking module 120, and the dynamic attendance module 130. This multi-level cache can record the downhole status and underground trajectory of personnel and vehicles in real time, accurately calculate the working hours and attendance status, reduce the access to the database, and improve the data reading efficiency.

[0048] A cache is data stored in memory. To improve access efficiency, specific data in the database can be loaded into memory, and this part of the data is called a cache. Among the data generated by the above modules, most of them are directly stored in the memory cache of the application process. Usually, the data in the memory cache is only accessible to the same process; another part of the data is cached in an independently running service process through Redis (Remote Dictionary Server), and the data is stored in the memory of the Redis process, decoupled from the application process, and can support cross-process and cross-server data sharing. In this embodiment, a memory Map is used to cache the current downhole records, and Redis is used to persist the historical state, which is convenient for third-party applications to access. This mechanism of classifying data and using a multi-level cache effectively reduces the access to the database.

[0049] The pre-divided working areas underground are also known as working faces or area groups, usually being relatively large production sites. Multiple positioning base stations complete signal coverage within the working face, and the signal range of a single base station is called an area. As tags move underground, the generated positioning data is relatively scattered. After aggregating the scattered positioning data, the trajectories of the tags within the area group and the trajectories within the area can be obtained. Therefore, the trajectory tracking module 120 is also used to asynchronously process the trajectory data of multiple tags through a thread pool, and separately store the area group trajectories and area trajectories of each tag. This asynchronous multi-threaded processing method can avoid concurrent conflicts by setting a thread execution switch, aggregating the scattered area stay records of the tags into area group trajectories, and the separate storage method can optimize the query efficiency.

[0050] The multi-level cache 140 includes the following cache areas that can be implemented through Map memory.

[0051] The first cache is used to record the time when the tag first enters the area, which can be used for anti-shake to avoid the influence of short-term fluctuating data on the results.

[0052] The second cache is used to record the time when the tag first reaches the wellhead, which can be used for anti-shake to avoid the influence of fluctuating data on the results.

[0053] The third cache is used to record the information of the tag going down the well.

[0054] The fourth cache is used to record the trajectory of the area passed by the tag before going down the well again, which can be used for anti-shake to avoid the influence of interfering data on the results.

[0055] The fifth cache is used to record the number of times the tag is continuously read by the underground base station before the down-the-well record is generated, and its function is to prevent the down-the-well record from being triggered by mistake.

[0056] The sixth cache is used to record the shift type of the operation and the start and end times of the shift. This cache can adapt to the respective shifts of enterprises, such as: the three-eight shift system, the four-six shift system, etc. This cache can enhance the flexibility of the operation management system and meet the individual needs of each enterprise.

[0057] Furthermore, the multi-level cache 140 in this embodiment also includes a first Redis and a second Redis implemented through Redis.

[0058] The first Redis is used to store attendance rules. The attendance rules include the shift type for going to work and the attendance duration.

[0059] The second Redis is used to store the down-the-well status of the tag for third-party applications to access.

[0060] Furthermore, the multi-level cache 140 in this embodiment also includes an area group cache implemented through Map memory, which is used to cache the data of the tag within the area group (within the working face), where:

[0061] The first area group cache is used to cache the correspondence between the base station and the area group, so as to quickly find the corresponding area group according to the base station.

[0062] The second area group cache is used to cache the tag information currently in the area group.

[0063] The third area group cache is used to cache the trajectory data of the area group that the tag has completed. This data can be used for anti-pulling.

[0064] The fourth area group cache is used to store the multi-threaded concurrent processing queue of the tag to avoid repeated generation of area group trajectories.

[0065] Furthermore, the multi-level cache 140 in this embodiment further includes an area cache implemented through Map memory, which is used to cache the data of the tag within the area (within the coverage range of a single base station), including:

[0066] The first area cache is used to cache the trajectory information of the area where the tag is currently located.

[0067] The second area cache is used to cache the trajectory data of the area that the tag has completed, which can be used to prevent data pulling.

[0068] The third area cache is used to store the multi-threaded concurrent processing queue of the tag to avoid repeated generation of area trajectories.

[0069] The job management system provided in this embodiment records the tag status in real time through a multi-level cache mechanism, reduces database access, has efficient data reading and good real-time performance of the tag status. Based on area group aggregation of scattered base station data, it generates continuous trajectories, and filters short-term invalid stays through thresholds, improving the accuracy of trajectory tracking. By caching shift and attendance rules, and adjusting the working date in combination with cross-day types, it can dynamically match attendance rules, and the working hours are accurate. By asynchronously processing underground records through multi-threading and avoiding data conflicts between multiple tags through a concurrent queue. The solution of the present invention can support real-time update and query of tag status, and can flexibly adapt to the attendance rules of each enterprise, improving the efficiency and accuracy of underground operation management.

[0070] On this basis, the embodiments of the present disclosure also provide a method for underground operation management based on wireless positioning.

[0071] Figure 2 It is a flowchart of the method for underground operation management based on wireless positioning provided in the embodiments of the present disclosure.

[0072] Such as Figure 2As shown in the figure, the operation management method includes steps S210 to S260, and uses the aforementioned downhole operation management system. From a program perspective, the execution entity of the process can be a program running on an application server or an application terminal. It can be understood that this method can be executed by any device, equipment, platform, or equipment cluster with computing and processing capabilities.

[0073] S210: After receiving the positioning data of the tag, execute the initialization logic of the downhole record for the corresponding tag.

[0074] S220: When the tag is in the wellhead area, determine that the tag is ascending, and execute the tag ascending logic.

[0075] S230: When the tag is not in the wellhead area and the first read time and the number of times read downhole meet the conditions, determine that the tag has reached the downhole.

[0076] S240: When it is determined that the tag has reached the downhole, execute the downhole record processing logic to generate the downhole record for the corresponding tag.

[0077] S250: Call the area group trajectory processing logic with the downhole time in the downhole record as a parameter.

[0078] S260: Call the area trajectory processing logic with the start time of the area group trajectory as a parameter.

[0079] The implementation manner of this management method is described below through a specific example.

[0080] The following table is Figure 1 a schematic structure of the multi-level cache 140 in the operation management system 100 shown in the figure.

[0081]

[0082]

[0083] The specific process of executing the operation management method based on this multi-level cache structure is as follows.

[0084] (I) Downhole record generation process

[0085] Figure 3 It is a schematic diagram of the data flow for downhole record processing.

[0086] As Figure 3 shown, after receiving the positioning data pushed by the base station, first determine whether the downhole record initialization action has been executed. If the initialization has not been executed, first execute the downhole record initialization logic L1. If the initialization action has been completed, then continue to execute the subsequent downhole record judgment process L2.

[0087] (1.1) Initialization Logic L1 of Downhole Record

[0088] The operations to be performed in the initialization logic of the downhole record are: query the database, load the shift cache, load the attendance rule cache, load the downhole record cache, and load the downhole status to Redis.

[0089] (1.2) Judgment Process L2 of Downhole Record

[0090] Judge whether the current tag is in the wellhead area. If it is in the wellhead area, first clear the cache of the number of times the tag is read underground, and then clear the cache of the second downhole. After that, execute the tag uphole logic L21. If it is not in the wellhead area, first judge whether the tag has really reached the underground according to the cache of the first read time underground and the cache of the number of times the tag is read underground. If the time difference between the current time and the first read time is less than the parameter required threshold, do not process. After the duration meets the parameter requirements, further judge whether the number of reads meets the parameter requirements. If the number does not meet the required number of times, increment the number by 1. If both the number and the duration meet the parameter requirements, it means that the tag has really reached the underground, and the tag downhole record processing logic L22 can be executed.

[0091] (1.2.1) Tag Uphole Logic L21

[0092] Use a thread pool to process the tag uphole logic. First, record the tag in the downhole record thread queue cache to avoid the same tag being processed by multiple threads simultaneously.

[0093] Record the tag information in the exit cache. Query the current status of the tag recorded in Redis. If the status of the tag in Redis does not exist, it means that the tag is preparing to go downhole for the first time, and record the status of this tag in Redis as 0, indicating that the tag is on the ground and preparing to go downhole; if the status in Redis is 0, it means that the tag has been read on the ground and does not need to be processed; if the status in Redis is 1, it means that the tag is underground and is now read by the ground base station. First, judge whether the duration of the tag being read by the wellhead base station has reached the uphole threshold. Subtract the time of the tag recorded in the exit cache from the current time. If the time is not enough, it means that it is caused by signal pulling and is not processed. If the time reaches the threshold, it means that it is a normal uphole and continue to execute.

[0094] If the tag is a personnel tag, execute the personnel uphole process. If the tag is a vehicle tag, execute the vehicle uphole process.

[0095] Figure 4 Schematic diagram of the data flow for personnel uphole.

[0096] Such as Figure 4As shown in the figure, the process of personnel ascending the shaft is as follows. First, obtain the start time of the tag from the regional trajectory cache; then obtain the attendance rule of the tag from Redis, and obtain the required downhole duration of the tag from the rule. Obtain the downhole record information of the tag from the downhole record cache, and remove the tag information from the downhole record cache after obtaining it. Set the data of the tag in Redis, including: status is 0 (out of the well), out-of-well time, and other information.

[0097] Calculate the current downhole duration by subtracting the downhole time in the downhole record information from the time read by the current base station. Use the set attendance rule to implement the scientific anti-shake function. If the downhole time is less than the set attendance rule, first delete the regional trajectory and regional group trajectory generated after the tag goes downhole in the database, then delete the downhole record, and at the same time remove the tag cache from the tag entry area cache, tag entry area group cache, and downhole record cache.

[0098] If the downhole time is greater than or equal to the set attendance rule, it means that the current downhole is valid. At this time, first process the last regional group trajectory and regional trajectory.

[0099] (a) First, process the regional group cache. If the regional group entry trajectory cache contains the tag trajectory, first complete the regional group trajectory in the cache. See the logic G11 for completing the regional group trajectory for details. If the current area is included in the regional group, generate a regional group trajectory. See the logic G12 for processing the newly entered regional group trajectory for details, and execute the logic G11 for completing the existing regional group trajectory.

[0100] (b) Then, process the regional trajectory. If the regional entry cache contains the tag trajectory, first complete the regional trajectory in the cache, update the departure time of the trajectory in the database to the current entry time, and calculate the residence duration = current entry time - cache entry time. Then insert into the database according to the newly pushed area information, update the tag departure time in the database to the current entry time, and the residence duration is 0.

[0101] After processing the last regional group and regional trajectory of the tag, continue to execute the tag downhole record processing logic, set the out-of-well time to the time read by the current base station, and the downhole duration to the current downhole duration calculated above. According to the previous attendance rule T 要求 and the current downhole duration T 实际 Calculate the work count, see the formula.

[0102] S 工数 = R(T 实际 / T 要求 ).

[0103] The attendance rounding rules include: rounding, ceiling, floor, etc. Each user enterprise can set different attendance rounding rules according to its actual situation.

[0104] After calculating the completion number, the downhole information can be updated to the database to complete the current uphole process.

[0105] After the uphole process is completed, release the tag status in the thread queue.

[0106] The vehicle uphole process: Similar to the personnel uphole process, the personnel uphole processing logic can be referred to.

[0107] (1.2.2) Tag downhole record processing logic L22

[0108] When the tag arrives downhole, remove the tag from the exit cache.

[0109] Use a thread pool to process the tag downhole logic. First, record the tag in the thread queue cache to avoid the same tag being processed by multiple threads simultaneously.

[0110] If the tag is a personnel tag, execute the personnel downhole processing logic; if the tag is a vehicle tag, execute the vehicle downhole processing logic.

[0111] Personnel downhole processing logic: Determine whether the tag status exists in Redis. If not, execute the downhole record generation logic L221; if it exists, first retrieve the tag status from Redis. If the tag status is equal to 0, execute the downhole record generation logic L221. If the tag status starts with 0, intercept the last uphole time. Compare the last uphole time with the current read time. If the current read time is less than or equal to the last uphole time, it indicates that the data pushed by the base station is incorrect data and will not be processed. Otherwise, check whether the tag exists in the tag secondary downhole trajectory cache. If so, calculate the downhole residence duration using the following formula.

[0112] t 停留 = T 本次读到时间 - T 标签二次下井轨迹缓存中首条记录开始时间

[0113] If the residence duration reaches the threshold of the secondary downhole parameter requirement duration, execute the downhole record generation logic L221. If the duration does not meet the parameter requirements, append the currently read data from the base station to the tag secondary downhole trajectory cache.

[0114] If there is no tag information in the tag secondary downhole trajectory cache, it indicates that the tag has just arrived downhole, and the currently read data from the base station is stored in the tag secondary downhole trajectory cache.

[0115] (1.2.1.1) Downhole record generation logic L221:

[0116] Empty the tag information in the read times cache of the underground. Take the first track time from the tag's second trip trajectory cache as the trip time, and the first track position as the trip location. Store the tag status 1 (going down the well) and the trip time in Redis. Start generating the trip record: Retrieve the corresponding shift type of the tag from the tag shift type cache, and combine it with the trip time T dq , and obtain the shift start time T bcs according to the shift type, and obtain the shift end time T bce ; Obtain whether early trip duration T tq is allowed from the system parameter settings, and start calculating the corresponding work recording date (considering cross-day and allowing early trips):

[0117] (a) If T bcs > T bce , it indicates a cross-day shift. If T dq >= T bcs - T tq , if the cross-day shift is recorded as the next day, the work recording date is the current date + 1; if T dq < T bce - T tq , if the cross-day shift is recorded as the previous day, the work recording date is the current date - 1.

[0118] (b) If T bcs < 180, it indicates a shift after midnight. If T dq <= T bce - T tq If the cross-day shift is recorded as the previous day, the work recording date is the current date - 1. If T dq > T bce - T tq , if the cross-day shift is recorded as the next day, the work recording date is the current date + 1.

[0119] Note: The above T dq , T bcs , T bce are all the number of minutes from 0:00 to the current time, and T tq is the set number of minutes.

[0120] After calculating the work recording date, start inserting the trip record information into the database. At the same time, add it to the trip record cache.

[0121] After generating the trip record, to ensure that the trip time is consistent with the start time of the area group and area trajectory. Pass the trip time as a parameter to the area group trajectory processing logic and execute the area group trajectory generation process.

[0122] After the trip process is completed, release the tag status in the trip record thread queue.

[0123] (2) Regional group trajectory processing flow

[0124] Figure 5 It is a schematic diagram of the processing data flow of the regional group trajectory.

[0125] As Figure 5 shown, after receiving the data, it is judged whether the regional group data initialization has been executed. If the initialization has not been performed, the initialization action is executed. The operations required for regional group initialization are: querying the database, loading the base station regional group cache, loading the tag regional group trajectory cache, and loading the tag completed regional group trajectory cache.

[0126] After the initialization is completed, it is judged whether the received data is the tag data of a person according to the received data. If it is not the tag data of a person, it is not processed (vehicles generally do not reach the working face, so there is no regional group trajectory). If it is the tag of a person, a thread pool is used to process the tag regional group trajectory logic. First, the tag number is recorded in the regional group thread queue cache to avoid the same tag being processed by multiple threads simultaneously.

[0127] After entering the regional group trajectory processing method, it is first judged whether the downhole record has been generated. If it has not been generated, the regional group trajectory logic is not executed. If it has been generated, the regional group trajectory processing logic is continued to be executed.

[0128] Then it is judged whether there is a current tag in the regional group trajectory cache. If there is, the tag existing regional group trajectory logic G1 is executed, otherwise the tag non-existing regional group trajectory logic G2 is executed.

[0129] (2.1) Tag existing regional group trajectory logic G1

[0130] The tag regional group trajectory is taken out from the tag regional group trajectory cache. According to the base station regional group cache, it is judged whether there is a corresponding regional group for the current base station. If there is a corresponding regional group, it is judged whether the regional group corresponding to the current base station is the same as the regional group where the tag is located. If they are different, the completed existing regional group trajectory logic G11 is first executed, and then the processing of the newly entered regional group trajectory logic G12 is executed. If there is no corresponding regional group for the current base station, the completed existing regional group trajectory logic G11 is executed. After completion, in order to ensure that the start time of the regional trajectory is the same as the start time of the regional group trajectory, the start time of the regional group trajectory is passed as a parameter to the regional trajectory processing logic, and the regional trajectory processing flow is executed.

[0131] (2.1.1) Completed existing regional group trajectory logic G11

[0132] When there is an unfinished area group trajectory for a tag, calculate the residence duration of the area group trajectory by subtracting the start time of the unfinished area group trajectory from the current time. If the residence duration is less than the trajectory valid threshold, remove the tag from the area group trajectory cache. At the same time, delete the corresponding area group trajectory record from the database. If the residence duration reaches the valid threshold, set the current time as the departure time of the area group trajectory, store the area group trajectory information in the cache of the area group trajectory that the tag has just completed, and remove the tag information from the area group trajectory cache. Synchronously update the area group trajectory record in the database, set the departure time as the current base station entry time, and set the residence duration as the calculated residence duration of the area group trajectory.

[0133] (2.1.2) Processing Logic G12 for Newly Entered Area Group Trajectories

[0134] Check if the tag exists in the cache of the area group trajectory that the tag has completed. If it does, retrieve the completed trajectory of the tag and check if the area group that the tag has just left is the same as the current entered area group. If they are the same, check if the time interval between the departure time of the area group that the tag left and the current entry time exceeds the valid trajectory duration. If it exceeds the interval duration, execute the logic G121 for inserting the area group and area trajectory; if the interval time does not reach the valid trajectory duration, it is considered that the tag drifted out of the area group due to signal pull and did not actually leave. Update the area group trajectory record in the database, set the departure time and residence duration to empty, and at the same time store the area group trajectory in the area group trajectory cache and remove the tag information from the cache of the area group trajectory that the tag has just left (completed). After processing the area group trajectory, in order to ensure that the start time of the area trajectory is consistent with the start time of the area group trajectory, pass the start time of the area group trajectory as a parameter and execute the area trajectory processing process. If the area group that the tag has just left is different from the current area group, execute the logic G121 for inserting the area group and area trajectory. If the tag does not exist in the cache of the area group trajectory that the tag has just left (completed), execute the logic G121 for inserting the area group and area trajectory.

[0135] (2.1.2.1) Insertion Logic G121 for Area Group and Area Trajectory

[0136] If the tag does not exist in the area group trajectory cache, generate area group trajectory data, record it in the area group trajectory cache, and store it in the database. After completion, in order to ensure that the start time of the area trajectory is consistent with the start time of the area group trajectory, pass the start time of the area group trajectory as a parameter and execute the area trajectory processing process.

[0137] (2.2) Tag Without Area Group Trajectory Logic G2

[0138] When there is no current tag in the label area group trajectory cache, determine whether there is a corresponding area group in the current area according to the base station area group cache. If there is a corresponding area group, execute the processing area group trajectory logic G12. If there is no area group, execute the area trajectory processing flow.

[0139] After the area group trajectory process is completed, release the tag status in the area group thread queue.

[0140] (3) Area trajectory processing flow

[0141] Figure 6 It is a schematic diagram of the processing data flow of the area trajectory.

[0142] As Figure 6 shown, after receiving the data, first execute the initialization action. The operations required for initialization are: query the database, load the tag into the area trajectory cache, and load the tag to complete the area trajectory cache.

[0143] After initialization, determine whether the current area is the wellhead area. If it is the wellhead area, do not process and return directly. If it is not the wellhead area, determine whether there is such tag information in the area trajectory cache. If there is no such tag information or the area in the area cache is different from the current entering area, use the thread pool to process the label area trajectory logic. First, record the tag in the area trajectory thread queue cache to avoid the same tag being processed by multiple threads simultaneously.

[0144] If the tag is a personnel tag, execute the personnel area trajectory processing logic. If it is a vehicle tag, execute the vehicle area trajectory processing logic.

[0145] Personnel area trajectory processing logic: First, determine whether there is a downhole record of this tag in the downhole record. If not, do not process the area trajectory and return directly.

[0146] After the tag has a downhole record, further determine whether there is a corresponding area group in the current area according to the base station area group cache. If there is an area group, determine whether the area group trajectory has been generated. If it has not been generated, do not process the area trajectory and return directly.

[0147] After there is no corresponding area group in the current area or the area group trajectory has been generated, determine whether the label entering the area trajectory cache contains the current tag information. If there is, execute the label existing area trajectory logic Q1. If not, execute the label non-existing area trajectory logic Q2.

[0148] (3.1) Label existing area trajectory logic Q1

[0149] If the area where the tag is located in the area trajectory cache is different from the currently entered area, calculate the residence duration of the tag in the area where it is located. The tag residence duration = the current area entry time - the start time of the cached trajectory. If the tag residence duration reaches the required duration parameter, use the current area entry time as the tag's area departure time and the calculated residence duration to update the tag area trajectory record in the database. At the same time, record the tag trajectory in the tag's completed area trajectory cache and remove it from the tag's entered area trajectory cache. If the residence duration does not reach the required duration parameter, delete the tag area trajectory from the database and remove the tag data in the tag's entered area trajectory cache. After processing the existing trajectory, insert the newly entered area trajectory into the database and record it in the tag's entered area trajectory cache.

[0150] (3.2) Tag has no area trajectory logic Q2

[0151] There is no current tag information in the tag area trajectory cache. Further determine whether there is tag information in the tag's completed area trajectory cache. If there is, execute the tag has completed area trajectory logic Q21. If not, execute the tag newly entered area trajectory processing logic Q22.

[0152] (3.2.1) Tag has completed area trajectory logic Q21

[0153] Retrieve the tag trajectory information from the tag's completed area trajectory cache and compare it with the currently entered area. If it is the same area, it means the tag has drifted out of the area due to signal pull and is actually still in the area. Clear the departure time and residence duration in the tag area trajectory record in the database. At the same time, store the tag area trajectory information in the tag's entered area trajectory cache. Query the previous completed area trajectory data of the tag in the database and record it in the tag's completed area trajectory cache.

[0154] If the area in the completed trajectory is not the same as the currently entered area, update the departure time of the completed trajectory in the database and the tag's completed area trajectory cache to the current entry time, and recalculate the residence duration. Then insert into the database according to the newly pushed area information to generate new area trajectory information and record it in the tag's entered area trajectory cache.

[0155] (3.2.2) Tag newly entered area trajectory processing logic Q22

[0156] The tag has no unexited trajectory and no completed area trajectory. Insert into the database according to the newly pushed area information to generate new area trajectory information and record it in the tag's entered area trajectory cache.

[0157] After the area trajectory process is completed, release the tag status in the area thread queue.

[0158] Vehicle area trajectory processing logic: The vehicle area trajectory processing logic is the same as that of personnel, referring to the personnel area trajectory processing logic.

[0159] According to the solution of this embodiment, the tag status is recorded in real time through a multi-level caching mechanism, reducing database access, with efficient data reading, high real-time performance of the tag status. Based on aggregating scattered base station data in the area group, continuous trajectories are generated, and short-term invalid stays are filtered through thresholds, improving the accuracy of trajectory tracking. By caching shift and attendance rules and adjusting the work recording date in combination with cross-day types, the attendance rules can be dynamically matched, and the work hours are accurately recorded. The downhole records are processed asynchronously with multiple threads, and data conflicts between multiple tags are avoided through a concurrent queue.

[0160] The above describes the implementation manners of the downhole operation management method provided by the present disclosure. Next, an embodiment of the management device corresponding to this management method is described.

[0161] Figure 7 It is a structural block diagram of an operation management device 300 provided by an embodiment of the present disclosure. The device 300 can be implemented as part or all of an electronic device through software, hardware, or a combination of both. The device operates based on the aforementioned downhole operation management system and implements the various management methods described above.

[0162] As Figure 7 shown, the device 300 includes an initialization module 310, an uphole processing module 320, a downhole processing module 330, a downhole record generation module 340, an area group processing module 350, and an area processing module 360.

[0163] The initialization module 310 is configured to execute the downhole record initialization logic of the corresponding tag after receiving the positioning data of the tag.

[0164] The uphole processing module 320 is configured to determine that the tag is uphole and execute the tag uphole logic when the tag is in the wellhead area.

[0165] The downhole processing module 330 is configured to determine that the tag arrives downhole when the tag is not in the wellhead area and the downhole first read time and the number of times the tag is read downhole meet the conditions.

[0166] The downhole record generation module 340 is configured to execute the downhole record processing logic to generate the downhole record of the corresponding tag when it is determined that the tag arrives downhole.

[0167] The area group processing module 350 is configured to call the area group trajectory processing logic with the downhole time in the downhole record as a parameter.

[0168] The area processing module 360 is configured to call the area trajectory processing logic with the start time of the area group trajectory as a parameter.

[0169] On this basis, the present disclosure also provides an electronic device for downhole operation management. The electronic device includes at least one processor, as well as a memory and a data interface that are communicatively connected to the processor; the memory stores instructions executable by the processor, and when these instructions are executed by the processor, the foregoing method can be implemented; the data interface is used to obtain the positioning data of the tag for the processor to process, and store the process data generated by the processor into the corresponding buffer. The buffer mentioned above is the multi-level buffer described above.

[0170] The downhole operation management device and the corresponding electronic device provided by the embodiments of the present disclosure record the tag status in real time through a multi-level cache mechanism, reduce database access, and have efficient data reading and good real-time performance of the tag status. Based on the aggregation of scattered base station data in the regional group, a continuous trajectory is generated, and short-term invalid stays are filtered through thresholds, improving the accuracy of trajectory tracking. By caching shift and attendance rules, and adjusting the work recording date in combination with the cross-day type, the attendance rules can be dynamically matched, and the work hours are accurately recorded. The downhole records are processed asynchronously with multiple threads, and data conflicts between multiple tags are avoided through a concurrent queue.

[0171] The various embodiments in the present disclosure are all described in a progressive manner. For the same or similar parts between the various embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the device and the electronic device, since they are basically similar to the embodiments of the management system or the management method, the description is relatively simple, and the relevant parts can be referred to the description of the embodiments of the management system or the management method.

[0172] The above describes specific embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0173] The above is only for the embodiments of the present disclosure and is not used to limit the present disclosure. For those skilled in the art, the present disclosure can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included within the scope of the claims of the present disclosure.

Claims

1. An underground operation management system based on wireless positioning, characterized in that, Including: An underground operation record management module, used to generate and record real-time data of the tag going down and coming up from the well; A trajectory tracking module, used to aggregate the positioning data of the tag based on the real-time data generated by the underground operation record management module in a pre-divided operation area, generate a continuous trajectory of the tag, and calculate the residence time of the tag in the corresponding operation area; A dynamic attendance module, used to calculate the working hours of the tag according to the residence time of the tag in the corresponding operation area and preset attendance rules; A multi-level cache, implemented through memory objects and Redis, used to store the data generated by the underground operation record management module, the trajectory tracking module, and the dynamic attendance module.

2. The system according to claim 1, wherein The trajectory tracking module is further used for: Asynchronously processing the trajectory data of multiple tags through a thread pool, and separately storing the regional group trajectory data and regional trajectory data of the tags.

3. The system according to claim 1, wherein The multi-level cache includes: A first cache, used to record the time when the tag first enters the area; A second cache, used to record the time when the tag first reaches the wellhead; A third cache, used to record the underground information of the tag; A fourth cache, used to record the trajectory of the area passed by the tag before going down the well again; A fifth cache, used to record the number of times the tag is continuously read by the underground base station before the underground operation record is generated.

4. The system according to claim 3, wherein The multi-level cache further includes: A first Redis, used to store attendance rules; A second Redis, used to store the underground state of the tag for third-party applications to access.

5. The system according to claim 3, wherein The multi-level cache further includes: A first regional group cache, used to cache the corresponding relationship between the base station and the regional group, so as to quickly find the corresponding regional group according to the base station; A second regional group cache, used to cache the tag information currently in the regional group; A third regional group cache, used to cache the trajectory data of the regional group completed by the tag; A fourth regional group cache, used to store the multi-threaded concurrent processing queue of the tag to avoid repeated generation of regional group trajectories.

6. The system according to claim 5, wherein The multi-level cache further includes: A first regional cache, used to cache the trajectory information of the area where the tag is currently located; A second regional cache, used to cache the trajectory data of the area completed by the tag; A third regional cache, used to store the multi-threaded concurrent processing queue of the tag to avoid repeated generation of regional trajectories.

7. The system according to claim 3, characterized in that, The multi-level cache further includes: A sixth cache, used to record the shift type of the operation and the start and end times of the shift.

8. A downhole operation management method based on wireless positioning, characterized in that, Using the underground operation management system according to any one of claims 1-7, the method includes: After receiving the positioning data of the tag, execute the initialization logic of the underground operation record corresponding to the tag; When the tag is in the wellhead area, determine that the tag is coming up from the well and execute the tag coming-up logic; When the tag is not in the wellhead area and the time when the tag is first read underground and the number of times the tag is read underground meet the conditions, determine that the tag has reached underground; When it is determined that the tag has reached underground, execute the underground operation record processing logic to generate an underground operation record corresponding to the tag; Call the regional group trajectory processing logic with the underground time in the underground operation record as a parameter; Invoke the area trajectory processing logic with the start time of the area group trajectory as a parameter.

9. An underground operation management device based on wireless positioning, characterized in that, Using the downhole operation management system according to any one of claims 1-7, the device includes: An initialization module, configured to execute the downhole record initialization logic corresponding to the tag after receiving the positioning data of the tag; A hoisting processing module, configured to determine that the tag is hoisting and execute the tag hoisting logic when the tag is in the wellhead area; A downhole processing module, configured to determine that the tag reaches the downhole when the tag is not in the wellhead area and the first downhole reading time and the number of times the tag is read downhole meet the conditions; A downhole record generation module, configured to execute the tag downhole record processing logic to generate a downhole record corresponding to the tag when it is determined that the tag reaches the downhole; An area group processing module, configured to invoke the area group trajectory processing logic with the downhole time in the downhole record as a parameter, An area processing module, configured to invoke the area trajectory processing logic with the start time of the area group trajectory as a parameter.

10. An electronic device for downhole operation management, characterized in that, The electronic device includes: At least one processor, and a memory and a data interface communicatively connected to the processor; The memory stores instructions executable by the processor, and when the instructions are executed by the processor, the method according to claim 8 can be implemented; The data interface is used to obtain the positioning data of the tag for the processor to process, and store the process data generated by the processor into the corresponding buffer.

Images