Power operation and maintenance project business state generation method and system, and storage medium

Abstract

The embodiment of the application provides a kind of electric power operation and maintenance project business state generation method, system and storage medium, belong to project management data processing technical field.The method comprises: obtaining the project business execution record generated in the implementation process of electric power operation and maintenance project, and the event processing is executed to project business execution record, and the business event stream with uniform structure is generated;Business state instance for representing the current execution stage of electric power operation and maintenance project is generated, and the corresponding trustable sustained amount is set for business state instance;Time sequence identification counter-event is generated, and the decay update processing is executed to trustable sustained amount;When trustable sustained amount meets preset failure condition, the state degradation processing of business state instance is triggered, and the business state data for reflecting the current electric power operation and maintenance project execution situation is output.The application scheme is through event driving and trustable sustained amount decay mechanism, realizes the dynamic correction and the degradable update of electric power operation and maintenance project business state, avoids state lag distortion.

Description

Technical Field

[0001] This invention relates to the field of project management data processing technology, specifically to a method, system, and storage medium for generating business status of power operation and maintenance projects. Background Technology

[0002] During the implementation of power operation and maintenance projects, project management systems typically need to identify the current status of the project to support business processes such as operation and maintenance scheduling, resource approval, performance settlement, and risk control. In existing technologies, the business status of power operation and maintenance projects is mostly updated based on work order completion status, progress node declaration results, or manual confirmation information. Once the status is generated, it is usually regarded as a deterministic result and maintained in the long term.

[0003] However, in real-world engineering scenarios, power operation and maintenance projects are characterized by long cycles, complex processes, and repeated adjustments during execution. Even after a project meets predetermined state triggering conditions at a certain point in time, subsequent rework orders, supplementary tasks, resource additions, and acceptance delays may still occur. These subsequent business realities often contradict the already generated business state. Because existing project management systems lack a constraint mechanism to ensure the continued validity of state establishment conditions, the business state cannot be dynamically corrected according to actual execution, leading to inconsistencies between the project state and the actual execution situation.

[0004] Furthermore, existing technologies for managing project business status often rely on static judgment or simple rollback methods, lacking quantitative means to express the reliability of a status's establishment, and also lacking mechanisms to gradually weaken and automatically degrade the status based on subsequent business activities. With the continuous generation of multi-source business data, these technical deficiencies are further amplified, easily leading to project status distortion and affecting the accuracy and reliability of operational decisions.

[0005] Therefore, there is an urgent need for a data processing method that can dynamically generate, continuously verify, and automatically degrade the business status of power operation and maintenance projects based on the evolution of business data, so as to improve the ability of project business status to reflect the actual execution situation. Summary of the Invention

[0006] The purpose of this invention is to provide a method, system, and storage medium for generating business status of power operation and maintenance projects, so as to at least solve the problems that existing power operation and maintenance project business statuses rely on static determination and cannot continuously verify the validity of the status and automatically degrade based on subsequent business events.

[0007] To achieve the above objectives, the first aspect of the present invention provides a method for generating business status of a power operation and maintenance project. The method includes: acquiring project business execution records generated during the implementation of a power operation and maintenance project, and performing event-based processing on the project business execution records to generate a business event stream with a unified structure; based on the business event stream, generating a business status instance to characterize the current execution stage of the power operation and maintenance project according to a preset state triggering rule, and setting a corresponding trusted persistence quantity for the business status instance; after the business status instance is generated, continuously receiving subsequent business events in the business event stream, identifying a counter-evidence event based on the generation sequence of the subsequent business events and the business status instance, and performing decay update processing on the trusted persistence quantity according to the counter-evidence event; when the trusted persistence quantity meets a preset failure condition, triggering state degradation processing of the business status instance, and outputting business status data reflecting the current execution status of the power operation and maintenance project.

[0008] Optionally, the project business execution records include any one or more of the following: work order records reflecting the execution status of tasks, progress node records reflecting the progress of project stages, and resource usage records reflecting resource input and consumption. Event-based processing is performed on the project business execution records to generate a business event flow with a unified structure, including: parsing the project business execution records according to preset event extraction rules to extract event elements related to changes in business status; generating corresponding business events for each project business execution record based on the event elements, and assigning each business event an event type identifier, an associated project identifier, and event occurrence time information; and organizing the obtained business events in chronological order to form a corresponding business event flow.

[0009] Optionally, the project business execution records are parsed according to preset event extraction rules to extract event elements related to changes in business status, including: determining an event element extraction template corresponding to the record type of the project business execution records, the event element extraction template being used to limit the set of element fields that can affect the validity of business status; extracting element fields that match the event element extraction template from the project business execution records, the element fields including at least behavioral identifier elements, associated object elements, and time elements; performing consistency verification processing on the extracted event elements, and eliminating element combinations that do not meet preset integrity conditions or temporal consistency conditions to form valid event elements.

[0010] Optionally, based on the business event flow, a business state instance representing the current execution stage of the power operation and maintenance project is generated according to a preset state triggering rule. This includes: determining state triggering event combinations corresponding to different business state types based on the event type identifier and event occurrence time information of each business event in the business event flow; performing a timing consistency determination on the state triggering event combinations to determine whether the state triggering event combinations meet the timing conditions for representing the establishment of the target business state; and generating a corresponding business state instance when the state triggering event combinations meet the preset state triggering conditions.

[0011] Optionally, the rule for setting the corresponding trusted persistence quantity for the business state instance is as follows: based on the number of business events included in the state trigger event combination used to generate the business state instance, the event type identifier corresponding to each business event, and the event occurrence time information of each business event, a trusted persistence quantity is constructed to characterize the reliability of the establishment of the business state instance; wherein, the number of business events in the state trigger event combination is used to characterize the establishment coverage of the business state instance; the event type identifier is used to distinguish the influence weight of different business events on the establishment of the business state; and the event occurrence time information is used to characterize the concentration of each business event in the time dimension.

[0012] Optionally, identifying disproving events based on the generation time sequence of the subsequent business events and the business state instance, and performing attenuation update processing on the trusted persistence quantity based on the disproving events, includes: determining the time sequence of subsequent business events in the business event stream based on the generation time of the business state instance, identifying business events whose occurrence time is later than the generation time of the business state instance and which are consistent with the project identifier corresponding to the business state instance as candidate disproving events; determining whether the candidate disproving events belong to disproving events that weaken the conditions for the establishment of the business state instance based on the event type identifier of the candidate disproving events; when determined to be a disproving event, determining the corresponding attenuation weight based on the event type identifier of the disproving event, and performing attenuation update processing on the trusted persistence quantity based on the attenuation weight; wherein, different event type identifiers correspond to different attenuation weights, used to distinguish the degree of influence of different types of disproving events on the establishment of the business state instance.

[0013] Optionally, when a counter-evidence event is identified, a corresponding attenuation weight is determined based on the event type identifier of the counter-evidence event, and attenuation update processing is performed on the trusted persistence quantity based on the attenuation weight. This includes: obtaining an attenuation weight matching the counter-evidence event from a preset correspondence between event types and attenuation weights based on the event type identifier of the counter-evidence event; performing time-related modulation processing on the attenuation weight based on the time interval between the occurrence time of the counter-evidence event and the generation time of the business state instance to reflect the temporal impact of the counter-evidence event on the validity of the business state instance; applying the modulated attenuation weight to the current trusted persistence quantity, and performing a numerical deduction update of the trusted persistence quantity to obtain the updated trusted persistence quantity; wherein, the attenuation weight is used to characterize the degree of weakening of the validity conditions of the business state instance by different types of counter-evidence events, and the attenuation weights corresponding to different counter-evidence events are different.

[0014] Optionally, when the trusted persistence quantity meets a preset failure condition, the state degradation processing of the service state instance is triggered, and service state data reflecting the current execution status of the power operation and maintenance project is output. This includes: when the trusted persistence quantity is detected to be less than or equal to a preset failure threshold corresponding to the service state instance, determining that the service state instance is no longer valid and marking the service state instance as a failed state; based on the generation order of the service state instances, reverting to the previous service state instance corresponding to the failed state and determining the previous service state instance as the current valid service state instance; and based on the current valid service state instance, generating service state data for external output, wherein the service state data includes at least the current service state type, the corresponding trusted persistence quantity, and a set of state source events related to the current service state type.

[0015] A second aspect of the present invention provides a power operation and maintenance project business status generation system, the system comprising: a data acquisition unit, configured to acquire project business execution records generated during the implementation of a power operation and maintenance project, and perform event-based processing on the project business execution records to generate a business event stream with a unified structure; a processing unit, configured to generate a business status instance representing the current execution stage of the power operation and maintenance project based on the business event stream and according to preset state triggering rules, and set a corresponding trusted persistence quantity for the business status instance; a decay update unit, configured to continuously receive subsequent business events in the business event stream after the business status instance is generated, identify counter-evidence events based on the generation sequence of the subsequent business events and the business status instance, and perform decay update processing on the trusted persistence quantity according to the counter-evidence events; and a result output unit, configured to trigger state degradation processing of the business status instance when the trusted persistence quantity meets preset failure conditions, and output business status data reflecting the current execution status of the power operation and maintenance project.

[0016] On the other hand, the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described method for generating the business status of power operation and maintenance projects.

[0017] Through the above technical solution, this invention processes business execution records generated during the implementation of power operation and maintenance projects into event-based data, forming a business event stream with a unified structure. This allows for continuous processing and analysis of multi-source business information within the same temporal framework. Based on this, business state instances are generated from the business event stream, and a trusted persistence quantity is introduced to quantify the reliability of the business state's validity, preventing the business state from being a fixed, one-time judgment. By continuously receiving subsequent business events after state generation and identifying counter-evidence events that weaken the state's validity based on the event occurrence sequence, the trusted persistence quantity is decayed and updated, enabling the business state to dynamically evolve with the actual project execution. When the trusted persistence quantity meets preset failure conditions, business state degradation is automatically triggered, and the current business state data is output. This ensures that the project's business state can promptly reflect changes during execution, reducing state distortion and improving the business state's responsiveness and interpretability to the actual operation and maintenance process.

[0018] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings:

[0020] Figure 1 This is a flowchart of the steps of a method for generating business status of power operation and maintenance projects according to one embodiment of the present invention;

[0021] Figure 2 This is a detailed flowchart of step S10 of the power operation and maintenance project business status generation method provided in one embodiment of the present invention.

[0022] Figure 3 This is a detailed flowchart of step S30 of the power operation and maintenance project business status generation method provided in one embodiment of the present invention.

[0023] Figure 4 This is a system structure diagram of a power operation and maintenance project business status generation system provided in one embodiment of the present invention;

[0024] Figure 5This is an internal structural diagram of a computer device provided in one embodiment of the present invention. Detailed Implementation

[0025] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0026] like Figure 1 As shown, this invention provides a method for generating business status for power operation and maintenance projects, the method comprising:

[0027] Step S10: Obtain the project business execution records generated during the implementation of the power operation and maintenance project, and perform event-based processing on the project business execution records to generate a business event flow with a unified structure.

[0028] Specifically, during the implementation of power operation and maintenance projects, project business execution records are typically generated in different business systems and management stages, with significant differences in data structure, record granularity, and time annotation methods, making them difficult to directly use for unified business status processing. In this embodiment, various project business execution records generated during project implementation are acquired, and event-based processing is performed on these records. The original business records are parsed and converted into business events with a unified structure. Each business event includes at least event type information representing the occurrence of a business action, project identifier information representing business relationships, and time information representing the order of business occurrence. Through event-based processing, the originally discrete and heterogeneous business execution records are transformed into a continuous and sortable stream of business events, providing a unified data foundation and temporal support for subsequent time-evolutionary business status generation, updating, and degradation processing. Specifically, such as... Figure 2 Step S10 includes the following steps:

[0029] Step S101: Obtain project business execution records generated during the implementation of power operation and maintenance projects.

[0030] Specifically, the project business execution records include any one or more of the following: work order records reflecting the execution of tasks, progress node records reflecting the progress of project phases, and resource usage records reflecting resource input and consumption.

[0031] Specifically, during the implementation of power operation and maintenance projects, the actual execution status of the project is usually reflected through various business records, with different types of business records corresponding to different aspects of the project execution process.

[0032] In this embodiment, project business execution records generated during the implementation of power operation and maintenance projects are obtained. These project business execution records are not limited to a single source or a single data structure, but cover multiple types of business information that can objectively reflect the project execution status.

[0033] Specifically, the project execution records may include work order records reflecting the execution of specific tasks, such as records of work order creation, dispatch, execution, completion, or rework, to depict the actual occurrence of on-site work activities. They may also include progress node records reflecting the project's phased progress, such as information on the declaration, confirmation, withdrawal, or postponement of key milestones, to describe the project's position within the overall implementation plan. Furthermore, they may include resource usage records reflecting resource input and consumption, such as records of personnel working hours, spare parts requisition, and vehicle or equipment usage, to reflect the actual resource allocation and consumption during project implementation.

[0034] The aforementioned project execution records can exist independently or be generated simultaneously during the implementation of the same power operation and maintenance project. This implementation method does not limit the acquisition of all types of execution records at the same time, but allows the acquisition of any one or more types of execution records based on the actual deployment of the project management system and data availability.

[0035] Step S102: Parse the project business execution records according to preset event extraction rules and extract event elements related to changes in business status.

[0036] Specifically, based on the record type to which the project business execution record belongs, an event element extraction template corresponding to the record type is determined. The event element extraction template is used to limit the set of element fields that can affect the validity of the business status. Element fields matching the event element extraction template are extracted from the project business execution record. The element fields include at least behavioral identifier elements, associated object elements, and time elements. Consistency verification processing is performed on the extracted event elements to eliminate element combinations that do not meet preset integrity conditions or temporal consistency conditions, so as to form valid event elements.

[0037] In this embodiment of the invention, after obtaining the project business execution records, further parsing and processing of the records is required to extract key event elements that reflect changes in business status. Since different types of project business execution records differ in their business meaning, field structure, and how they affect business status, this embodiment does not employ a uniform field extraction method. Instead, it determines corresponding event element extraction templates based on the record type of each project business execution record.

[0038] The event element extraction template is used to define which fields in the corresponding record type are considered as the set of element fields that may affect the validity of the business status. Specifically, for work order records, the event element extraction template can focus on fields that reflect the occurrence of the work behavior, such as work order operation type, work order status change identifier, and corresponding work time.

[0039] For progress node records, the event element extraction template can focus on the node application result, node confirmation status, and node occurrence time; for resource usage records, the event element extraction template can focus on information such as resource usage behavior identifier, resource associated object, and resource usage occurrence time. By configuring corresponding event element extraction templates for different record types, the extracted event elements can be semantically consistent with changes in business status.

[0040] In the specific parsing process, element fields matching the event element extraction template are extracted from the project business execution records. The extracted event elements include at least a behavior identifier element to characterize the occurrence of a business action, an associated object element to characterize the object affected by the business action, and a time element to characterize the order in which the business action occurs. For example, in a work order completion record, the behavior identifier element corresponds to the type of operation completed, the associated object element corresponds to the specific work order or project identifier, and the time element corresponds to the time when the work order was completed.

[0041] After extracting event elements, consistency verification is required to prevent interference with subsequent business status generation due to missing records, supplementary entries, or abnormal reporting. This consistency verification may include integrity verification and temporal consistency verification. Integrity verification determines whether the extracted event elements simultaneously contain behavioral identifier elements, associated object elements, and time elements. Temporal consistency verification determines whether the event occurrence time conforms to the basic time logic of the project implementation process. For element combinations that do not meet the preset integrity or temporal consistency conditions, they are removed from the valid event elements, retaining only the verified event elements as the foundational data for generating subsequent business events and business event flows.

[0042] Through the above processing, the event elements entering the subsequent state generation and update process have clear business semantics and reliable temporal order, providing stable data support for the dynamic generation and evolution of business states.

[0043] Step S103: Generate a corresponding business event for each project business execution record based on the event elements, and assign an event type identifier, associated project identifier, and event occurrence time information to the corresponding business event.

[0044] Specifically, after extracting and verifying the consistency of event elements, these elements need to be further organized into structured business events to facilitate unified processing and analysis of project execution status. In this embodiment, based on the event elements, a corresponding business event is generated for each project business execution record, and the business event is assigned a clear event type identifier, associated project identifier, and event occurrence time information, thereby forming an event object with unified semantics and structure.

[0045] Specifically, the business event is the result of reorganizing validated event elements. The event type identifier clarifies the behavioral attributes of the business event during project execution, such as distinguishing different types of business behaviors like task completion, node reporting, and resource usage, enabling subsequent processing to classify and judge based on event type. The associated project identifier indicates the specific power operation and maintenance project or project sub-unit to which the business event belongs, ensuring that in the case of multiple projects implemented in parallel, each business event can be accurately aggregated into the corresponding project scope; the event occurrence time information characterizes the actual occurrence sequence of the business event during project execution, providing a basis for subsequent time-series-based state generation, state update, and state degradation processing.

[0046] In practical engineering applications, the same power operation and maintenance project often generates multiple project business execution records at different points in time. By converting each eligible project business execution record into a corresponding business event and uniformly assigning it the aforementioned key information, the differences in source systems, field structures, and naming methods of the original records can be effectively eliminated, allowing different types and sources of business behaviors to be expressed within the same processing framework. For example, a work order completion record and a progress node confirmation record, although from different sources and with different business focuses, can both be uniformly managed through event type identifiers, associated project identifiers, and event occurrence time information after being converted into business events.

[0047] Step S104: Organize the obtained business events in chronological order to form a corresponding business event flow.

[0048] Specifically, after generating business events and assigning them event type identifiers, associated project identifiers, and event occurrence time information, these business events need to be uniformly organized and processed. In this embodiment, the obtained business events are sorted according to their occurrence time and organized chronologically to form a corresponding business event stream. Through this business event stream, discrete business behaviors generated during the implementation of power operation and maintenance projects are transformed into continuous time-series data, enabling subsequent processing to analyze and judge the project execution status based on the chronological relationship of events. The business event stream provides a unified temporal basis for the generation of subsequent business state instances, the updating of reliable persistence quantities, and state degradation processing, helping to ensure the continuity and consistency of the business state evolution process.

[0049] Step S20: Based on the business event flow, generate a business state instance to represent the current execution stage of the power operation and maintenance project according to the preset state triggering rules, and set a corresponding trusted persistence quantity for the business state instance.

[0050] Specifically, based on the business event flow, a business state instance representing the current execution stage of the power operation and maintenance project is generated according to preset state triggering rules. This includes: determining state triggering event combinations corresponding to different business state types based on the event type identifier and event occurrence time information of each business event in the business event flow; performing a timing consistency determination on the state triggering event combinations to determine whether the state triggering event combinations meet the timing conditions for representing the establishment of the target business state; and generating a corresponding business state instance when the state triggering event combinations meet the preset state triggering conditions.

[0051] Furthermore, the rule for setting the corresponding trusted persistence quantity for the business state instance is as follows: based on the number of business events included in the state trigger event combination used to generate the business state instance, the event type identifier corresponding to each business event, and the event occurrence time information of each business event, a trusted persistence quantity is constructed to characterize the reliability of the establishment of the business state instance; wherein, the number of business events in the state trigger event combination is used to characterize the establishment coverage of the business state instance; the event type identifier is used to distinguish the influence weight of different business events on the establishment of the business state; and the event occurrence time information is used to characterize the concentration of each business event in the time dimension.

[0052] In this embodiment of the invention, after forming a business event flow, this implementation further generates a business state instance to characterize the current execution stage of the power operation and maintenance project based on the business event flow and according to a preset state triggering rule, and sets a corresponding trusted persistence quantity for the business state instance.

[0053] For ease of explanation, we will first define the business event flow and its attributes. The business event flow is denoted as... Where E represents the business event flow; Let represent the i-th business event; N represents the number of business events in the business event stream. The order of business events in the business event stream is consistent with the chronological order of their occurrence. In other words, if business events... Ranked in business events Previously, business events The event occurred no later than the business event. The time when the event occurred.

[0054] For any business event Its core attribute is denoted as , Indicates a business event The event type identifier is used to distinguish the semantic categories of business behaviors; Indicates a business event The event occurrence time information is used to depict the temporal position of business activities during project implementation; Indicates a business event The associated project identifier is used to indicate business events. The power operation and maintenance project to which it belongs.

[0055] In this implementation, a business state instance is not directly triggered by a single business event, but rather is established by a group of business events in the business event stream that satisfy preset state triggering rules. The business state type is denoted as... , representing the j-th business status type. Business status types can be configured according to the power operation and maintenance project management standards, such as corresponding to the work execution stage, acceptance stage, or resource input stage. Each business status type corresponds to a set of preset status trigger rules, which specify the types of business events that should occur when the status is established, the order of business events, and the tolerable time deviation.

[0056] Based on business status type The combination of state trigger events used to trigger this business state type is selected from the business event stream and denoted as... ,in, Indicates the business status type Corresponding state-triggered event combinations; This represents the m-th business event in the combination; This indicates the number of business events in the state-triggered event combination. The state-triggered event combination is not an arbitrary selection of business event streams, but rather determined by preset state triggering rules. These preset state triggering rules define at least two conditions: first, a type condition, meaning the event type identifiers of the business events in the state-triggered event combination must match the triggering requirements of that business state type; second, a timing condition, meaning the business events in the state-triggered event combination must satisfy constraints on their order and time intervals.

[0057] To avoid situations such as duplicate counting of the same type of event, mixing of cross-project events, and disruption of the time sequence due to supplementary events in engineering scenarios, this implementation method performs a time sequence consistency check on the state-triggered event combination after it is formed. The purpose of the time sequence consistency check is to confirm whether the combination has the time logic to support the establishment of the business state. The occurrence time of the business events in the state-triggered event combination is extracted to obtain the time series. ,in, This represents the time sequence of events corresponding to the combination of state-triggered events; Indicates a business event The event occurrence time information is included. The timing consistency determination includes at least two parts: sequential consistency and window consistency. Sequential consistency is used to determine whether the time series satisfies a non-decreasing relationship; window consistency is used to determine whether the span of the time series falls within the tolerable time range of the business state type. If the determination result is that the preset state triggering conditions are met, a corresponding business state instance is generated, and the set of state source events for that business state instance is recorded. This set of state source events is the state triggering event combination, so that it can be traced in subsequent counter-evidence event identification and degradation rollback.

[0058] When a business state instance is generated, this implementation sets a trusted persistence quantity for that instance to characterize the reliability of its establishment and its sustainability under subsequent business event impacts. The trusted persistence quantity is not a fixed duration, nor is it manually assigned; rather, it is constructed based on a combination of state-triggered events used to generate the business state instance. The construction of the trusted persistence quantity considers at least three dimensions:

[0059] 1) Establish coverage, which corresponds to the number of business events in the state-triggered event combination.

[0060] 2) Type structure, corresponding to the event type identifier of each business event.

[0061] 3) Time concentration, which refers to the clustering of the occurrence times of various business events on the timeline.

[0062] The three dimensions mentioned above address three common problems in engineering: insufficient evidence leading to a fragile state, a single type of evidence leading to a biased state, and excessively scattered evidence leading to an unstable state.

[0063] To achieve reproducible construction rules, this implementation defines a type weight mapping for combinations of state-triggered events. This mapping applies to business state types. A pre-defined set of influence weights corresponding to event type identifiers is used to distinguish the degree of influence of different types of business events on the validity of the business status. The weight set is denoted as... ,in, Indicates the business status type The corresponding set of event type weights; This represents the influence weight of the q-th event type; This indicates the number of event types involved in this business status type. It should be noted that the event type weight set corresponds one-to-one with the business status type; different business status types may have different weight sets to adapt to the evidence strength requirements at different stages.

[0064] Based on this, for each business event in the state-triggered event combination, the type weight of the business event is obtained by looking up its event type identifier in a table, forming a weight sequence. ,in, This represents the sequence of type weights for each business event in a state-triggered event combination; [symbol] Indicates a business event The corresponding type weights. This weight sequence is used to reflect the type structure strength of the combination of state-triggered events.

[0065] Meanwhile, to characterize the degree of time concentration, this implementation method uses time series... Calculate its dispersion. First, define the mean time of this time series:

[0066]

[0067] in, Representing time series The mean time. The time dispersion is defined based on the mean time:

[0068]

[0069] Among them, symbols The dispersion of a time series is used to characterize the degree of concentration of business events over time. Higher dispersion indicates more dispersed business events, while lower dispersion indicates more concentrated business events. To avoid incomparable dispersion due to differences in the cycle scales of different projects, this implementation can normalize the dispersion by incorporating a preset time scale parameter for that business status type. This time scale parameter is a pre-configured time base and will not be elaborated upon here.

[0070] Considering the comprehensiveness of coverage, structural strength of types, and degree of temporal concentration, this implementation method constructs a reliable persistence quantity. The reliable persistence quantity is denoted as:

[0071]

[0072] Among them, symbols Indicates the business status type The trusted persistence quantity of the corresponding business state instance; symbol This represents the coverage coefficient, used to modulate the contribution of the number of service events to the reliable persistence quantity; symbol Represents the type structure coefficient, used to modulate the contribution of the mean type weight to the reliable duration; symbol The time dispersion coefficient is used to modulate the weakening effect of time dispersion on credible duration. All the above coefficients are pre-configured parameters, which can be configured by the project management system based on historical statistics or expert experience. However, their value selection does not affect the core idea of ​​this implementation method: credible duration is jointly determined by the quantity of evidence, the structure of evidence types, and the degree of temporal concentration of evidence. The purpose of using a logarithmic term in the formula is to suppress extreme amplification of a single dimension, ensuring that credible duration maintains a reasonable sensitivity to changes in the quantity of evidence and time dispersion, and avoiding distortion of credible duration when the number of business events is too large or the time span is too long.

[0073] To facilitate understanding, a simplified engineering example illustrates how the above rules work. For instance, if a power maintenance project generates three key business events simultaneously within a short period—"work order completion," "node confirmation," and "resource recovery"—and these events occur within a concentrated timeframe, the combination of business events triggering the state will have a large number of events, a high average type weight, and low temporal dispersion, resulting in a larger reliable persistence. This makes the business state instance less likely to be overturned by a single contradictory event over a longer period. Conversely, if only a single type of business event triggers the state, or if the events required for triggering are scattered across a long time span, while the triggering conditions for generating a state instance may be met, the reliable persistence will be relatively small. Subsequent business events contradicting the state will more easily trigger reliable persistence decay and enter a degradation path, thus making the state more closely resemble the actual execution situation.

[0074] Through the aforementioned rules for generating business state instances and constructing trusted persistence quantities, this implementation method completes the structured solidification of evidence for state establishment and the quantitative expression of state persistence capability at the moment of business state instance generation. This result provides a stable foundation for subsequent identification of counter-evidence events based on subsequent business events, execution of trusted persistence quantity decay updates, and triggering state degradation when failure conditions are met. This ensures that the output business state data continuously reflects the true evolution of the power operation and maintenance project.

[0075] Step S30: After the business state instance is generated, continue to receive subsequent business events in the business event stream, identify counter-evidence events based on the generation time sequence of the subsequent business events and the business state instance, and perform decay update processing on the trusted persistence quantity according to the counter-evidence events.

[0076] In this embodiment of the invention, after a business state instance is generated, the implementation does not consider the business state instance as the final result. Instead, it continuously receives subsequent business events from the business event stream and compares and analyzes these subsequent business events with the generation sequence of the business state instance. By judging subsequent business events based on their temporal order, business events that occur after the business state instance is generated and weaken or negate the conditions for the establishment of the business state in terms of business semantics are identified as counter-evidence events. After identifying counter-evidence events, based on the degree of influence of the counter-evidence events on the validity of the business state, a decay update process is performed on the credible persistence quantity corresponding to the business state instance, so that the credibility of the business state instance changes dynamically with the actual business execution process. Through the above method, the business state can be continuously constrained by subsequent business facts after its generation, avoiding the long-term maintenance of the business state and deviation from the actual project execution, and providing a reliable basis for subsequent state degradation judgment. Specifically, as shown... Figure 3 Step S30 includes the following steps:

[0077] Step S301: After the business state instance is generated, continue to receive subsequent business events in the business event stream.

[0078] Specifically, after a business state instance is generated based on the business event stream, and using the generation time of the business state instance as a time base, a continuous receiving phase begins to receive business events generated after that time base. For ease of description, the generation time of the business state instance is defined as... This indicates the point in time when the corresponding business status instance was generated and recorded.

[0079] After a business state instance is generated, all business events in the business event stream that occur later than the generation time are considered subsequent business events, and their time relationships satisfy the following: , This indicates the time when the corresponding business event occurred.

[0080] In step S301, business events that satisfy the above-mentioned time relationship are continuously received, and these business events are appended to the business event stream in chronological order of their occurrence. The continuous receiving process uses project association as a basic constraint, requiring only that the received business events be consistent with the power operation and maintenance project corresponding to the business state instance, without pre-limiting the event type or business semantics of the business events. This ensures that after the business state instance is generated, any new business facts generated during project implementation, such as job execution behaviors, schedule node adjustment behaviors, and resource input or consumption behaviors, can be fully captured and entered into the subsequent processing flow.

[0081] Furthermore, the continuous receiving mechanism in step S301 adapts to both real-time and non-real-time business events. For real-time business events, they can be included in the business event stream immediately after the event occurs. For business events that are delayed in entering the system due to system synchronization, manual entry, or management process reasons, as long as their occurrence time meets the above-mentioned time relationship, they are also processed as subsequent business events. By uniformly defining the scope of subsequent business events in the time dimension, a continuous and complete business event input foundation is provided for identifying counter-evidence events based on the time sequence relationship generated by subsequent business events and business state instances.

[0082] Step S302: Based on the generation time of the business state instance, perform time sequence determination on subsequent business events in the business event stream, and identify business events that occurred later than the generation time of the business state instance and are consistent with the project identifier corresponding to the business state instance as candidate counter-evidence events.

[0083] Specifically, after completing the continuous reception of subsequent business events, this implementation further performs timing determination processing on subsequent business events in the business event stream based on the generation time of the business state instance, in order to identify candidate counter-evidence events that may weaken the validity of the business state instance.

[0084] In this step, the occurrence time of each business event in the business event stream is compared one by one, and business events whose occurrence time is later than the business state instance generation time are filtered out. This time-series determination process effectively excludes business facts that occurred before the business state instance was generated, avoiding the misjudgment of historical behavior prior to the state's establishment as evidence against it. Through this time-based filtering, all the resulting business events are those that occurred after the business state instance was generated, possessing the temporal condition to influence the current business state.

[0085] After completing the time-based filtering, it is necessary to further consider project relationships and perform project consistency determination on the aforementioned business events. Specifically, the project identifier associated with the business event is compared with the project identifier corresponding to the time the business state instance was generated. Only when the two are consistent is the business event considered to be directly related to the current business state instance. Through project consistency determination, business events generated by other projects or other task units can be avoided from being mistakenly included in the counter-evidence analysis scope of the current business state, thereby ensuring the accuracy of the subsequent counter-evidence identification process.

[0086] If, simultaneously, the event occurs later than the business state instance generation time, and the business event's associated project identifier matches the corresponding project identifier of the business state instance, the corresponding business event is marked as a candidate disproving event. These candidate disproving events do not necessarily negate the business state instance; rather, they serve as candidate inputs for further determination of whether they weaken the conditions for the business state's validity. Through this two-level screening mechanism, business events entering the subsequent disproving judgment and credible persistence decay processing stages possess a clear temporal rationality and project relevance, thus providing reliable factual evidence for the dynamic evolution of the business state.

[0087] Step S303: Based on the event type identifier of the candidate disproving event, determine whether the candidate disproving event belongs to the disproving event that weakens the conditions for the establishment of the business state instance.

[0088] Specifically, after screening the candidate disproving events, it is necessary to further determine whether each candidate disproving event constitutes a disproving event that weakens the conditions for the establishment of the business state instance based on its event type identifier. It should be noted that not all business events that occur after the business state instance is generated and are consistent with the project will necessarily negate the establishment of the business state. Therefore, the purpose of this step is to further distinguish the candidate disproving events at the semantic level, avoiding misjudging business events that are unrelated to the business state or have no substantial impact on the state as disproving events.

[0089] In this implementation, a set of allowed or prohibited business event types is pre-configured based on the business state type corresponding to the business state instance. The event type identifier of the candidate disproving event serves as the core judgment criterion and is matched and analyzed with the business state type corresponding to the business state instance. When the event type identifier of the candidate disproving event belongs to the preset set of "weakening event types," it is determined that the candidate disproving event weakens the conditions for the establishment of the business state instance in terms of business semantics; when the event type identifier of the candidate disproving event does not belong to this set, it is considered that the candidate disproving event does not constitute a direct negation of the conditions for the establishment of the current business state instance.

[0090] To achieve configurability and scalability of the above determination process, this implementation introduces a mapping rule between event type and the influence of state establishment. The mapping rule This is used to describe the direction and intensity of the impact of different event types on different business status types. Mapping rules This is used to characterize the correspondence between event type identifiers and the impact of business status establishment. Its output indicates whether the corresponding event type weakens the conditions for the current business status to be established. It should be noted that the mapping rule can be implemented in the form of a rule table, configuration file, or parameterized model, but its implementation method does not affect the determination logic of this step.

[0091] After completing event type matching and impact relationship determination, a candidate disproving event is only formally marked as a disproving event and used as input for subsequent trusted persistence decay update processing if it is determined at the event type level to weaken the conditions for the establishment of a business state instance. By limiting the determination of disproving events to the event type semantic level, unnecessary interference to the business state caused by business events triggered by normal business progress, information supplementation, or irrelevant operations can be effectively avoided, thereby ensuring the stability and rationality of the business state evolution process.

[0092] Through the above-mentioned judgment mechanism, the identification of counter-evidence events not only has the basis of temporal rationality and project consistency, but also has a clear business semantic basis, providing reliable input conditions for subsequent decay update processing of credible persistence quantities based on counter-evidence events.

[0093] Step S304: When a counter-evidence event is determined, the corresponding attenuation weight is determined according to the event type identifier of the counter-evidence event, and attenuation update processing is performed on the trusted persistence quantity based on the attenuation weight.

[0094] Specifically, based on the event type identifier of the counter-evidence event, a decay weight matching the counter-evidence event is obtained from a preset correspondence between event types and decay weights; based on the time interval between the occurrence time of the counter-evidence event and the generation time of the business state instance, time-related modulation processing is performed on the decay weight to reflect the temporal impact of the counter-evidence event on the validity of the business state instance; the modulated decay weight is applied to the current trusted persistence quantity, and the value of the trusted persistence quantity is reduced and updated to obtain the updated trusted persistence quantity; wherein, the decay weight is used to characterize the degree of weakening of the validity conditions of the business state instance by different types of counter-evidence events, and the decay weights corresponding to different counter-evidence events are different.

[0095] In this embodiment of the invention, after a candidate disproving event is determined to be a disproving event through event type determination, this implementation further determines the degree to which the disproving event weakens the conditions for the establishment of the business state instance based on its event type identifier, and accordingly performs decay update processing on the trusted persistence quantity corresponding to the business state instance. Through this decay update mechanism, the trust level of the business state instance can gradually decrease as disproving events occur, thereby preventing the business state from being maintained even when it is clearly no longer valid.

[0096] In this embodiment, based on the event type identifier of the disproving event, a basic attenuation weight matching the disproving event is obtained from a preset correspondence between event types and attenuation weights. This correspondence between event types and attenuation weights describes the weakening effect of different types of disproving events on the conditions for establishing a business state; it can be configured based on business experience or historical statistical results. For ease of description, the basic attenuation weight corresponding to the current disproving event is represented as... This weight is used to characterize the degree to which this type of counter-evidence event weakens the fundamental conditions for the validity of the business state instance, without considering the time factor. It should be noted that the basic attenuation weights corresponding to different event types are distinguished from each other, thus causing counter-evidence events with different semantic strengths to have different effects in subsequent attenuation processing.

[0097] After determining the basic attenuation weight, this embodiment further introduces a time dimension factor, performing time-related modulation processing on the basic attenuation weight. Considering that the timing of the counter-evidence event affects its actual weakening effect on the validity of the business state, this embodiment modulates the basic attenuation weight by the time interval between the occurrence time of the counter-evidence event and the generation time of the business state instance. For ease of explanation, the modulation factor corresponding to this time interval is denoted as... The modulation factor characterizes the degree of impact of a counter-evidence event on the validity of a business state instance over time. When the time interval between the occurrence of the counter-evidence event and the generation of the business state instance is short, the modulation factor value is large, reflecting the direct impact of the counter-evidence event on the validity of the business state; when the time interval is long, the modulation factor value is relatively small, reflecting the gradually weakening effect of the counter-evidence event on the current business state. The specific functional form of the modulation factor can be configured according to engineering needs, and its implementation does not affect the technical effect of this embodiment.

[0098] In one specific implementation, the time modulation factor adopts an exponential decay form that monotonically decreases with time interval to reflect the temporal impact characteristics of the disproving event on the validity of the business state instance. This implementation is based on the following engineering assumptions: the closer the disproving event occurs to the time of business state instance generation, the stronger its negation effect on the validity conditions of the business state; the later the disproving event occurs, the relatively weaker its weakening effect on the current business state.

[0099] In this implementation, the time interval between the occurrence time of the counter-evidence event and the generation time of the business state instance is denoted as . The time interval is used to characterize the time distance between the counter-evidence event and the moment the business state instance was generated. The specific functional form of the time modulation factor is defined as:

[0100]

[0101] in, This represents the time decay parameter, used to control the decay rate of the time modulation factor. The time decay parameter is a preset parameter, and its value can be configured according to the typical stage cycle or business rhythm of the power operation and maintenance project, such as setting it based on the length of the operation cycle, the node acceptance cycle, or the frequency of resource adjustment.

[0102] Under the above functional form, when the time interval between the occurrence of the disproving event and the generation of the business state instance is small, the time modulation factor is close to 1. At this time, the weakening effect of the disproving event on the conditions for the establishment of the business state instance is mainly determined by the basic decay weight corresponding to its event type. As the time interval increases, the time modulation factor gradually decreases in an exponential form, so that the consumption effect of the disproving event that occurs later in the process of credible persistence decay update is reduced accordingly.

[0103] Based on the basic attenuation weight and the time modulation factor, this implementation method obtains the effective attenuation weight after modulation, and its calculation relationship is as follows:

[0104]

[0105] The effective attenuation weight is used to comprehensively reflect the weakening effect of the counter-evidence event in terms of both event type and time dimension.

[0106] After obtaining the effective attenuation weight, this implementation applies it to the trusted persistence quantity corresponding to the current service state instance, performing a numerical deduction and update process on the trusted persistence quantity. The value of the trusted persistence quantity before the update is represented as follows: The updated value of the trusted persistence quantity is represented as The decay update relationship of the reliable duration can be expressed as:

[0107]

[0108] The above update method ensures that each counter-evidence event results in a quantifiable depletion of the trusted persistence quantity. As counter-evidence events continue to occur, the trusted persistence quantity will gradually decrease, providing a direct basis for subsequently determining whether a business state instance meets the failure conditions.

[0109] Through the aforementioned decay update mechanism, this implementation maps the semantic strength and occurrence sequence of the counter-evidence event together as a dynamic consumption process of the credible persistence quantity, so that the business state instance is no longer a static conclusion, but a state object that can be continuously corrected by subsequent business facts, thereby laying a reliable computational foundation for the subsequent state degradation processing of the business state instance.

[0110] Step S40: When the trusted persistence quantity meets the preset failure condition, trigger the state degradation processing of the service state instance and output service state data reflecting the current power operation and maintenance project execution status.

[0111] Specifically, when the trusted persistence value is detected to be less than or equal to a preset failure threshold corresponding to the service state instance, the service state instance is determined to be no longer valid and is marked as a failed state; based on the generation order of the service state instances, the process reverts to the previous service state instance corresponding to the failed state and determines the previous service state instance as the current valid service state instance; based on the current valid service state instance, service state data for external output is generated, and the service state data includes at least the current service state type, the corresponding trusted persistence value, and a set of state source events related to the current service state type.

[0112] In this embodiment of the invention, the trusted persistence quantity, as a core quantitative indicator characterizing the reliability of the establishment of a business state instance, is not only used for internal evaluation, but also directly serves as the basis for determining whether to trigger business state degradation processing. When the trusted persistence quantity meets the preset failure condition during continuous decay and update, the validity of the current business state instance will be actively terminated, and the business state will be rolled back and adjusted, thereby ensuring that the business state output externally can truly reflect the current execution status of the power operation and maintenance project.

[0113] Specifically, for each service state instance, a failure threshold corresponding to that service state type is pre-configured to limit the minimum success requirement for that service state instance in terms of trusted persistence. The trusted persistence value corresponding to the current service state instance is represented as... The preset failure threshold corresponding to this business state instance is represented as: When a trusted persistent quantity is detected to satisfy the following relationship, it is determined that the service state instance is no longer valid:

[0114]

[0115] After meeting the above criteria, the current business state instance is marked as invalid, and it is no longer used as a valid representation of the current execution phase of the project. It should be noted that invalidation here does not mean the business state is directly deleted; rather, its historical existence is preserved through explicit marking for subsequent auditing, backtracking, or analysis.

[0116] After a business state instance is marked as invalid, this implementation further introduces a state degradation mechanism based on the generation order. Following the generation order of business state instances, the preceding business state instance, which is adjacent to the current invalid instance and was generated earlier, is located and reverted to the current valid business state instance. This reversion process maintains the temporal continuity of the business state evolution path, avoiding issues such as gaps or jumps in business states after invalidation.

[0117] It is important to emphasize that this state degradation mechanism is not a simple state reset, but rather an orderly rollback based on the generation history of business state instances, between historical states that are fully supported by business events. Since the previous business state instance also underwent the process of determining the combination of state triggering events and assigning trusted persistence values ​​during its generation phase, it still has a clear business factual basis as the current valid business state instance after rollback.

[0118] After completing the state degradation process, business state data for external output is generated based on the current valid business state instance. This business state data includes at least the current business state type, the corresponding reliable persistence quantity, and a set of state source events supporting the establishment of this business state. By outputting the set of state source events together, external or management personnel can not only know the current business state but also trace the factual basis for its formation, thereby improving the interpretability and reliability of the business state data.

[0119] In one specific implementation, the power operation and maintenance project business status generation method of the present invention is applied to an annual maintenance project of a 220kV substation. The project is divided into four business status types: "preparation stage", "on-site maintenance stage", "test acceptance stage" and "project completion stage".

[0120] During project implementation, project business execution records are continuously collected, including records of work order issuance and receipt, confirmation records of key maintenance milestones, and resource usage records for personnel and equipment. These records are then processed as events to form a unified business event flow.

[0121] In this embodiment, when the following combination of events is detected in the business event stream:

[0122] 1) The maintenance work order has entered the "started" status.

[0123] 2) The first on-site work progress milestone has been confirmed as completed.

[0124] 3) If the on-site maintenance personnel and testing equipment resources have been registered and the above events occur consecutively within 2 hours, a business status instance of "on-site maintenance phase" will be generated according to the preset status trigger rules.

[0125] For this business state instance, based on the number of business events, event types, and the concentration of event occurrence times included in the state-triggered event combination, its initial trusted persistence is calculated to be 100. Subsequently, subsequent business events are continuously received, and counter-evidence is performed on them.

[0126] Three hours after the business status instance was generated, a business event of type "work order paused" was received. This event was identified as a counter-evidence event. Based on the correspondence between event type and attenuation weight, the base attenuation weight for this event was 30. Combining the time interval between the occurrence time of this counter-evidence event and the generation time of the business status instance, the time modulation factor was calculated to be 0.8, thus determining the effective attenuation weight to be 24, and updating the trusted persistence value to 76.

[0127] Furthermore, 6 hours after the business status instance was generated, a counter-evidence event of the event type "critical resource withdrawal" was received. Its basic attenuation weight was 40, the corresponding time modulation factor was 0.6, and the effective attenuation weight was 24, which further updated the trusted persistence value to 52.

[0128] When a subsequent "maintenance node rollback" event occurs as a counter-evidence, the trusted persistence value is updated to 45, which is lower than the preset failure threshold of 50 for this service state instance. Based on this, it is determined that the "on-site maintenance phase" service state instance is no longer valid and is marked as a failed state.

[0129] Furthermore, following the generation order of business status instances, the system automatically reverts to the previous business status instance and identifies it as the current valid business status instance. Ultimately, the output business status data includes the current business status type "Preparation Phase," the corresponding trusted persistence quantity, and the set of events supporting this status, thus providing a true reflection of the execution status of the power operation and maintenance project.

[0130] In another possible implementation, the power operation and maintenance project business status generation method of the present invention is applied to a cross-regional transmission line integrated online maintenance project. Unlike conventional implementations, this embodiment focuses on dynamically correcting the business status to address issues such as incomplete information feedback, scattered data sources, and delays in manual confirmation during project execution.

[0131] In this implementation, the system also generates business event streams based on project business execution records, and generates corresponding business status instances and trusted persistence quantities. However, after the business status instance is generated, the system not only identifies disproving events based on explicitly occurring business events, but also further uses "business events that should have occurred but did not occur" as potential disproving evidence. For example, when a business status instance has entered the "on-site maintenance phase," but has not received the corresponding key progress node confirmation event or resource continuous investment event within a preset time window, the system transforms this missing fact into an implicit disproving event.

[0132] For the aforementioned implicit counter-evidence events, the system retrieves the corresponding basic attenuation weight from the correspondence between event type and attenuation weight based on the event type identifier. Then, combining this with the time interval between the business state instance generation time and the current time, the system performs time-related modulation processing on the attenuation weight, thereby deducting and updating the trusted persistence quantity. In this way, even if no anomalies are actively reported on-site, the trusted persistence quantity of the business state instance will still gradually decrease due to the long-term lack of critical information.

[0133] When the trusted persistence value drops below the preset failure threshold, the system triggers a state degradation process for the business state instance and automatically reverts to the previous business state instance. By incorporating "information missing" and "progress mismatch" into the proof-of-contrast mechanism, this implementation method can effectively identify common execution risks in power operation and maintenance projects that are difficult to capture through a single abnormal event, making the generated business state results closer to the actual execution of the project.

[0134] like Figure 4As shown, this invention provides a power operation and maintenance project business status generation system. The system includes: a data acquisition unit, used to acquire project business execution records generated during the implementation of a power operation and maintenance project, and to perform event-based processing on the project business execution records to generate a business event stream with a unified structure; a processing unit, used to generate a business status instance representing the current execution stage of the power operation and maintenance project based on the business event stream and according to preset state triggering rules, and to set a corresponding trusted persistence quantity for the business status instance; a decay update unit, used to continuously receive subsequent business events in the business event stream after the business status instance is generated, identify counter-evidence events based on the generation sequence of the subsequent business events and the business status instance, and perform decay update processing on the trusted persistence quantity according to the counter-evidence events; and a result output unit, used to trigger state degradation processing of the business status instance when the trusted persistence quantity meets preset failure conditions, and output business status data reflecting the current execution status of the power operation and maintenance project.

[0135] The present invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described method for generating the business status of a power operation and maintenance project.

[0136] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor A01, a network interface A02, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A06. The non-volatile storage medium A06 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A06. The network interface A02 is used for communication with external terminals via a network connection. When the computer program B02 is executed by the processor A01, it implements a method for generating the business status of a power operation and maintenance project.

[0137] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0138] The optional embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present invention are not limited to the specific details described above. Within the scope of the technical concept of the embodiments of the present invention, various simple modifications can be made to the technical solutions of the embodiments of the present invention, and these simple modifications all fall within the protection scope of the embodiments of the present invention. It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, the embodiments of the present invention will not further describe the various possible combinations.

[0139] Furthermore, various different embodiments of the present invention can be combined in any way, as long as they do not violate the spirit of the embodiments of the present invention, they should also be regarded as the content disclosed by the embodiments of the present invention.

Claims

1. A method for generating business status of power operation and maintenance projects, characterized in that, The method includes: Acquire project business execution records generated during the implementation of power operation and maintenance projects, and perform event-based processing on the project business execution records to generate a business event flow with a unified structure; Based on the business event flow, a business state instance is generated to represent the current execution stage of the power operation and maintenance project according to the preset state triggering rules, and a corresponding trusted persistence quantity is set for the business state instance. After the business state instance is generated, subsequent business events in the business event stream are continuously received. Based on the generation sequence of the subsequent business events and the business state instance, a counter-evidence event is identified, and the trusted persistent quantity is subjected to decay update processing according to the counter-evidence event. When the trusted persistence quantity meets the preset failure condition, the state degradation processing of the service state instance is triggered, and service state data reflecting the current power operation and maintenance project execution status is output. The rule for setting the corresponding trusted persistence quantity for the business state instance is as follows: Based on the number of business events included in the state trigger event combination used to generate the business state instance, the event type identifier corresponding to each business event, and the event occurrence time information of each business event, a reliable persistence quantity is constructed to characterize the reliability of the establishment of the business state instance; wherein, The number of business events in the state-triggered event combination is used to characterize the establishment coverage of the business state instance; The event type identifier is used to distinguish the impact weight of different business events on the validity of the business status. The event occurrence time information is used to characterize the degree of concentration of each business event in the time dimension.

2. The method for generating business status of power operation and maintenance projects according to claim 1, characterized in that, The project execution records include: Any one or more of the following: work order records used to reflect the execution of tasks, progress node records used to reflect the progress of project phases, and resource usage records used to reflect resource input and consumption. The project's business execution records are processed using event-based methods to generate a business event flow with a unified structure, including: The project business execution records are parsed according to preset event extraction rules to extract event elements related to changes in business status. Based on the event elements, a corresponding business event is generated for each project business execution record, and the corresponding business event is assigned an event type identifier, an associated project identifier, and event occurrence time information. The obtained business events are organized in chronological order to form corresponding business event streams.

3. The method for generating business status of power operation and maintenance projects according to claim 2, characterized in that, The project's business execution records are parsed according to preset event extraction rules to extract event elements related to changes in business status, including: Based on the record type to which the project business execution record belongs, an event element extraction template corresponding to the record type is determined. The event element extraction template is used to limit the set of element fields that can affect the validity of the business status. Extract element fields from the project business execution records that match the event element extraction template. The element fields include at least behavior identifier elements, associated object elements, and time elements. The extracted event elements are subjected to consistency verification processing to eliminate element combinations that do not meet the preset integrity conditions or temporal consistency conditions, so as to form valid event elements.

4. The method for generating business status of power operation and maintenance projects according to claim 3, characterized in that, Based on the business event flow, a business state instance representing the current execution stage of the power operation and maintenance project is generated according to preset state triggering rules, including: Based on the event type identifier and event occurrence time information of each business event in the business event stream, determine the combination of state triggering events corresponding to different business state types; Perform a timing consistency determination on the combination of state-triggered events to determine whether the combination of state-triggered events satisfies the timing conditions used to characterize the establishment of the target business state; When the combination of state triggering events satisfies the preset state triggering conditions, a corresponding business state instance is generated.

5. The method for generating business status of power operation and maintenance projects according to claim 1, characterized in that, Based on the generation sequence of the subsequent business events and the business state instance, a counter-evidence event is identified, and a decay update process is performed on the trusted persistence quantity according to the counter-evidence event, including: Based on the generation time of the business state instance, the subsequent business events in the business event stream are time-series determined, and business events that occur later than the generation time of the business state instance and are consistent with the project identifier corresponding to the business state instance are identified as candidate counter-evidence events. Based on the event type identifier of the candidate disproving event, determine whether the candidate disproving event belongs to the disproving event that weakens the conditions for the establishment of the business state instance; When a counter-evidence event is identified, the corresponding attenuation weight is determined according to the event type identifier of the counter-evidence event, and attenuation update processing is performed on the trusted persistence quantity based on the attenuation weight. Different event type identifiers correspond to different attenuation weights, which are used to distinguish the degree of influence of different types of counter-evidence events on the validity of the business state instance.

6. The method for generating business status of power operation and maintenance projects according to claim 5, characterized in that, When a counter-evidence event is identified, a corresponding attenuation weight is determined based on the event type identifier of the counter-evidence event, and attenuation update processing is performed on the trusted persistence quantity based on the attenuation weight, including: Based on the event type identifier of the counter-evidence event, obtain the attenuation weight that matches the counter-evidence event from the preset correspondence between event type and attenuation weight; Based on the time interval between the occurrence time of the counter-evidence event and the generation time of the business state instance, time-related modulation processing is performed on the attenuation weight to reflect the temporal impact of the counter-evidence event on the validity of the business state instance. The modulated attenuation weight is applied to the current trusted duration, and the value of the trusted duration is reduced and updated to obtain the updated trusted duration. The attenuation weight is used to characterize the degree to which different types of disproving events weaken the conditions for the establishment of the business state instance, and the attenuation weights are different for different disproving events.

7. The method for generating business status of power operation and maintenance projects according to claim 1, characterized in that, When the trusted persistence quantity meets the preset failure condition, the state degradation processing of the service state instance is triggered, and service state data reflecting the current execution status of the power operation and maintenance project is output, including: When the trusted persistence quantity is detected to be less than or equal to the preset failure threshold corresponding to the service state instance, it is determined that the service state instance is no longer valid and the service state instance is marked as a failure state. Based on the generation order of the business state instances, the process reverts to the previous business state instance corresponding to the failed state, and determines the previous business state instance as the current valid business state instance. Based on the current valid business state instance, business state data for external output is generated. The business state data includes at least the current business state type, the corresponding trusted persistence quantity, and a set of state source events related to the current business state type.

8. A power operation and maintenance project business status generation system, characterized in that, The system includes: The acquisition unit is used to acquire project business execution records generated during the implementation of power operation and maintenance projects, and to perform event-based processing on the project business execution records to generate a business event stream with a unified structure. The processing unit is configured to generate a business state instance that represents the current execution stage of the power operation and maintenance project based on the business event flow and according to a preset state triggering rule, and set a corresponding trusted persistence quantity for the business state instance. The rule for setting the corresponding trusted persistence quantity for the business state instance is as follows: Based on the number of business events included in the state trigger event combination used to generate the business state instance, the event type identifier corresponding to each business event, and the event occurrence time information of each business event, a reliable persistence quantity is constructed to characterize the reliability of the establishment of the business state instance; wherein, The number of business events in the state-triggered event combination is used to characterize the establishment coverage of the business state instance; The event type identifier is used to distinguish the impact weight of different business events on the validity of the business status. The event occurrence time information is used to characterize the degree of concentration of each business event in the time dimension; The decay update unit is used to continuously receive subsequent business events in the business event stream after the business state instance is generated, identify counter-evidence events based on the generation time sequence of the subsequent business events and the business state instance, and perform decay update processing on the trusted persistent quantity according to the counter-evidence events. The result output unit is used to trigger the state degradation processing of the service state instance when the trusted persistence quantity meets the preset failure condition, and output service state data that reflects the current power operation and maintenance project execution status.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the power operation and maintenance project business status generation method as described in any one of claims 1-7.

Images