A process-oriented event handling and collaborative table management system and method for multi-airport operation on duty

Abstract

The application discloses a process-oriented multi-airport operation value-keeping event handling and collaborative account management system and method, which comprises a value-keeping terminal module, an airport tenant context and identity permission module, a process configuration management module, an event identification and process instance generation module, a step state control module, a business data and collaborative account module, a system file and anchor positioning module, and an audit recovery and report output module. The application takes the airport tenant as the data isolation boundary, realizes independent operation, process handling and whole-process traceable management under the multi-airport shared system through configuration-driven event identification, process instance snapshot generation, step state machine sequential control, system document page code anchor positioning and unified audit recovery mechanism. The application can effectively reduce the dependence of value-keeping personnel on personal experience and manual search, reduce mistakes, forgetfulness and omissions, shorten the system document positioning path, and form traceable records from event occurrence, handling, handover to review.

Description

Technical Field

[0001] This invention relates to the field of airport operation management technology, specifically to a process-oriented event handling and collaborative ledger management system and method for multi-airport operation duty, which is particularly suitable for business scenarios such as duty in airport operation control centers, emergency handling, shift handover, telephone recording and operation review. Background Technology

[0002] Airport operations control and duty management involve multiple aspects, including emergency response, shift handover, telephone recording, operational debriefing, and retrieval of policy documents. Current methods typically rely on paper ledgers, spreadsheets, instant messaging tools, and static PDF policy documents: duty personnel first determine the category of the incident based on its description, then search for contingency plans in different folders or documents, and fill in the handling process, telephone records, and shift handover details based on their personal experience. While some units have deployed general office systems or single-ledger systems, process configurations, policy documents, and handling records are often scattered, failing to create a unified operating interface for duty scenarios.

[0003] In scenarios where multiple airports or operating units share a system, each airport's processes, contacts, policy documents, and historical records are independent. Traditional solutions often distinguish data by using separate folders, manual naming, or separate system deployments, which increases maintenance costs and is prone to cross-airport confusion when configuring permissions, referencing data, or compiling reports.

[0004] A search revealed existing technologies related to the generation of civil aviation incident handling procedures. For example, Chinese patent application CN112686583A discloses a method and system for automatically generating civil aviation incident handling procedures. This method determines the incident type and level by acquiring incident information, and then determines the automatic handling procedure based on the incident type and level. However, this solution mainly addresses the coordination efficiency issue between business systems and does not involve technical means such as tenant isolation in multi-airport scenarios, snapshot separation of process configuration and handling instances, step-level state machine control, and anchor point positioning of policy documents. Another example is Chinese patent CN105096231B, which discloses an intelligent management and control system for joint airports. This system achieves collaborative command and dispatch across multiple airports through a joint operation database and business data exchange system, but it focuses on the exchange and collaborative dispatch of flight dynamic data, rather than incident handling process management and ledger collaboration in on-duty scenarios. Furthermore, Chinese patent application CN117668073A relates to a tenant management platform for civil aviation systems, achieving multi-tenant isolation through tenant resource authorization configuration, but it does not address core on-duty business functions such as configuration-driven incident handling procedures, state machine control, and policy document positioning.

[0005] Therefore, the existing technology has at least the following shortcomings: First, incident handling relies on manual retrieval and personal experience, making it impossible to continuously display the steps to be taken, verification items, and related system documents after an incident is entered, which easily leads to errors, omissions, and oversights.

[0006] Second, the handling procedures, telephone records, shift handover and debriefing records are kept in a scattered manner, and it is difficult to form a unified chain of evidence based on the completion time, the operating entity and the supporting data, resulting in low efficiency in post-event tracing.

[0007] Third, when deploying across multiple airports, without permission and data filtering mechanisms based on airport tenants, process configurations, ledger records, and uploaded materials may be accessed or misoperated by other airport accounts.

[0008] Fourth, static PDF policy documents can usually only be read in full or roughly searched, making it difficult for staff to accurately locate the corresponding chapter and page number from the current handling steps. Summary of the Invention

[0009] Therefore, the purpose of this invention is to overcome the shortcomings of the prior art and provide a process-oriented event handling and collaborative ledger management system and method for multi-airport operation and monitoring. With airport tenants as data isolation boundaries, the system achieves independent operation, process-oriented handling, and full-process traceability management under a shared system for multiple airports through configuration-driven event identification, process instance snapshot generation, step state machine control, system document page number anchor point positioning, and a unified audit retrieval mechanism.

[0010] This invention is implemented by constructing a process-oriented event handling and collaborative ledger management system for multi-airport operation and monitoring, characterized by comprising: The duty terminal module runs on the terminal used by duty personnel or administrators to complete tasks such as airport selection and login, event description entry, candidate event confirmation, question and answer information collection, step verification and completion, system document viewing, shift handover and telephone record filling. The airport tenant context and identity permission module is used to receive the airport identifier, account and password submitted by the monitoring terminal, verify the ownership relationship between the account and the airport, and form a signature session context containing the airport identifier, user identifier and role after successful verification. Each subsequent business operation is based on the signature session context to perform airport data range verification and role permission verification. The process configuration management module is used by the current airport administrator to maintain the event categories, identification words, question and answer fields, step sequence, handling points, precautions, pre-completion verification items, time limit rules, and system document anchors for the airport. The configuration data is saved separately according to the airport identifier. The event recognition and process instance generation module is used to standardize the text description of the event entered by the duty personnel, call the current airport's valid recognition words and event rules for matching and output candidate events. In response to the user's confirmation of the candidate event, it copies the corresponding process steps, Q&A fields, verification items and data anchors, forms a process instance snapshot with configuration version information and generates a unique handling record identifier. The step status control module is used to maintain the locked, handleable, and completed status of each step for the process instance, and save the verification results, the operator who completed the operation, and the completion time; in response to the step completion request submitted by the duty terminal, the module verifies the status of the previous step and the current verification item on the server. After the verification is successful, the module records the completion information with a status transition and unlocks the next step. The business data and collaborative ledger module is used to save incident handling instances, Q&A content, step status, shift handover, telephone records, control room duty logs, and field candidate values ​​according to airport identification. The system document and anchor point positioning module is used to receive data anchor points in process instances according to airport management PDF system documents and their document identifiers, chapters, page numbers, keywords and text ranges, and return the specified page and positioning parameters after verifying the airport to which the document belongs. The audit, recovery, and report output module is used to summarize event descriptions, Q&A information, step details, operators, completion time, and supporting documentation, generate browsing reports and documents, and record key status transitions and operations. When deleting a record, a recovery status with an airport identifier is written first, and permission and tenant verification are performed when restoring or permanently deleting the record.

[0011] Furthermore, the step status control module arranges the process steps in a preset order. When the verification items of the current step are satisfied and the user submits the data, the server records the completion time of the step and switches the status of the next step from locked to ready for processing. If the preceding steps are not completed, the subsequent steps remain in an incomplete state. After the last step is verified and submitted, the process instance is marked as closed, and it is prohibited to restore the completed steps to an incomplete state.

[0012] Furthermore, the system document and anchor point positioning module transmits the file identifier, page number, and positioning information corresponding to the current step to the PDF viewing page. The viewing page opens the specified page according to the positioning information and highlights only the text range required for the current jump. The positioning information includes at least one of the following: chapter name, page number, keywords, or text range.

[0013] Furthermore, the event recognition and process instance generation module standardizes the event description by removing spaces, punctuation, and capitalization to form the text of the event to be recognized, while retaining the original description for handling records and reports; the candidate results simultaneously display the event name, applicable instructions, and process summary; if there are multiple candidate results, the on-duty personnel confirm the target event.

[0014] Furthermore, the business data and collaborative ledger module adopts an independent ledger method for shift handover and telephone records, which requires filling in the information first and then saving it. The browsing mode displays the saved snapshots, and the editing mode records changes and generates update time and operator information. Candidate values ​​such as name, unit, and location are maintained separately according to field category and most recent usage time, and candidate values ​​are not mixed between different fields.

[0015] Furthermore, in the airport tenant context and identity permission module, after a user selects an airport and completes identity verification on the login page, the selected airport is recorded in the monitoring terminal by default; subsequent requests involving process reading, event creation, shift handover, telephone records, system documents, reports, recycle bins and user management are all based on the airport identifier for permission verification and data range filtering; the administrator can only maintain the configuration and account of this airport.

[0016] A process-oriented incident handling and collaborative ledger management method for multi-airport operation and duty management is characterized by the following steps: Step S1, establish airport tenant context: The user selects an airport and enters account information on the login page. The system verifies the ownership relationship between the account and the airport. After successful verification, a signature session containing airport identifier, user identifier and role is established. Step S2, Enter Event Description: The on-duty personnel enter the event description at the handling entry point, and the on-duty terminal submits the text to the application service. The application service performs standardization processing on the text to form the event text to be identified. Step S3, perform current airport rule matching: The event recognition module reads the event categories and recognition words of the current airport in the enabled state, matches the normalized text and forms candidate results; Step S4, Generate process instance and configuration snapshot: After the user confirms the event, the system copies the currently valid question and answer fields, step sequence, handling points, precautions, verification items, time limit rules and system file anchors of the event, generates a process instance snapshot bound to a unique handling record identifier, sets the first step as handleable, and sets the remaining steps as locked; Step S5: Complete the step-by-step processing according to the state machine sequence: The terminal displays all steps and processing content on a single page. The staff adds Q&A information and step details, checks the pre-completion verification items for the current step, and submits a completion request. The server verifies the status of the preceding steps, the required verification items, and the record ownership. If the verification passes, it records the operator and completion time, changes the current step to "completed," and unlocks the next step. If the verification fails, it returns the missing items, and subsequent steps remain locked. This process is repeated until the last step is completed. Step S6, locate the system data according to the current step: During the handling process, the on-duty personnel click on the associated system file. The system reads the file identifier and location parameters from the process instance snapshot, verifies the consistency between the file and the current airport, opens the specified page and highlights the corresponding text range. Step S7, complete information closure and instance archiving: After the final step of verification and submission, mark the process instance as closed, and summarize the event description, collected information, details of each step, completion time, operation subject and system document references to form a history record; Step S8: Generate ledgers, reports, and audit results: Generate disposal reports based on saved instances and export documents; related operations are synchronously written to audit records; when deleting records, first transfer them to the airport's recycle bin.

[0017] Furthermore, in step S3, the system does not call the process configuration of other airports besides the currently logged-in airport; in step S4, subsequent modifications to the process configuration by the administrator will not affect the already generated process instance snapshot.

[0018] Furthermore, in step S6, the viewing page displays only the text range required for this jump in yellow according to the positioning parameters, and retains the original processing instance and step status after closing the data page.

[0019] Furthermore, in step S8, shift handover and telephone records are archived by date. When creating a new ledger, the system does not pre-generate blank official records. The visible ledger is created only after the user fills in the information and saves it. Saved records provide browsing mode and editing mode. Editing mode displays the changed content.

[0020] Compared with the prior art, the present invention has the following advantages: 1. By using airport tenant identifiers throughout authentication, permission verification, data querying, file referencing, and data recycling operations, multiple airports can operate independently within a single deployment, reducing redundant construction costs and mitigating the risk of cross-airport data contamination. After a user selects an airport on the login page, all subsequent operations are automatically limited to the data scope of that airport, eliminating the possibility of cross-airport misoperations at the architectural level.

[0021] 2. By employing event recognition, process snapshots, and sequential unlocking mechanisms, abstract policy requirements are transformed into executable page states and verification actions, reducing the reliance of on-duty personnel on memory and manual retrieval. On-duty personnel no longer need to manually determine event categories and handling steps; the system automatically matches processes based on the entered event descriptions and guides them through each step in a preset order, effectively reducing errors, omissions, and oversights.

[0022] 3. By linking steps with chapters, page numbers, and highlighted areas in system documents, the path to locating policy documents is shortened, making the basis for the current step directly visible and improving the interpretability of the process. On-duty personnel no longer need to manually search through hundreds of pages of PDF files; they can simply click to jump to the specific chapter and page number corresponding to the current step, with only the relevant text highlighted to avoid information interference.

[0023] 4. By establishing a unified ledger, timeline, operating entity, recycle bin, and Word report mechanism, a traceable record is created from the occurrence, handling, handover, to post-event review, facilitating operational management and post-event verification. The completion time, operator, and verification results of each step are recorded. Shift handover and telephone records are independently stored and their change history is traceable, providing a complete chain of evidence for operational reviews and safety audits. Attached Figure Description

[0024] Figure 1 This is the logical architecture diagram of the AODS airport operation monitoring system; Figure 2 Incident handling and control flowchart. Detailed Implementation

[0025] The following will be combined with the appendix Figures 1-2 This invention will be described in detail, and the technical solutions in the embodiments of this invention will be clearly and completely described. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0026] This invention provides an improved, process-oriented incident handling and collaborative ledger management system and method for multi-airport operation monitoring. The system adopts a browser / server architecture and includes a monitoring terminal, application services, business data storage, policy document services, and report output modules. Each airport operates as an independent tenant, and administrators can maintain the users, roles, incident flows, Q&A fields, system documents, and alert rules for their respective airports. Monitoring personnel perform handling and ledger operations only within the tenant context of the currently logged-in airport. Figure 1 This is the logical architecture diagram of the AODS airport operation monitoring system.

[0027] 1. System overall structure and module functions like Figure 1 As shown, the system is organized into four levels: duty interaction, business control, data and documentation support, and output and traceability. Each module receives the current airport tenant identifier as a business processing condition and establishes a connection through the processing record identifier, process configuration version, and document anchor point. The system mainly includes the following modules: The duty terminal module runs on the browser terminal used by duty personnel or administrators. It is used to complete tasks such as airport selection and login, event description entry, candidate event confirmation, Q&A information collection, step verification and completion, system document viewing, shift handover, and telephone record filling. This module displays all handling steps, current operable status, completion time, and related information on the same workflow page, and submits user operations to the application service without directly bypassing the server to modify the step status.

[0028] Airport Tenant Context and Identity Permission Module: Receives the airport identifier, account, and password submitted by the monitoring terminal, verifies whether the account belongs to the selected airport, and generates a signed session context containing the airport identifier, user identifier, and role upon successful verification. Every subsequent process, ledger, document, report, and reclaim operation first reads this context before performing role permission verification and airport data scope verification, preventing cross-airport access from the request entry point.

[0029] The process configuration management module allows the current airport administrator to maintain event categories, identifiers, question and answer fields, step sequence, key handling points, precautions, pre-completion verification items, time limit rules, and system document anchors. Configuration data is saved separately according to airport identifiers; when the configuration is modified, it only affects newly created handling instances and does not write back existing historical handling snapshots.

[0030] The event recognition and process instance generation module standardizes the event descriptions input by on-duty personnel and matches them using only valid recognition words and event rules for the current airport, outputting one or more candidate events. After the user confirms the event category, this module copies the corresponding process steps, Q&A fields, verification items, and data anchors to form a process instance snapshot with configuration version information and generates a unique handling record identifier.

[0031] Step Status Control Module: This module maintains the locked, ready-to-handle, and completed statuses of each step in the process instance, and saves the verification results, the operator who completed the task, and the completion time. When the terminal submits a step completion request, this module verifies the previous steps and the current verification item on the server side. If the verification passes, it records the completion information with a single status transition and unlocks the next step. If the verification fails, it maintains the original status and returns the item to be supplemented.

[0032] The business data and collaborative ledger module stores incident handling instances, Q&A content, step status, shift handover records, telephone records, control room duty logs, and candidate field values ​​according to airport identifiers. Shift handover records and telephone records use a separate ledger method where data is filled in first and then saved. The browsing mode displays saved snapshots, while the editing mode records changes. Candidate values ​​such as name, unit, and location are maintained separately according to field category and most recent usage time to avoid mixing different fields.

[0033] System Documents and Anchor Point Location Module: Based on airport management PDF policy documents and their document identifiers, chapters, page numbers, keywords, and text ranges. This module receives data anchor points from process instances, verifies the airport to which the document belongs, returns the specified page and the required location parameters, causing the viewing page to jump to the corresponding page and highlight only the key range associated with the current step.

[0034] The audit, recovery, and reporting output module summarizes event descriptions, Q&A information, step details, operators, completion times, and supporting documentation to generate browsing reports and Word documents. It also records key status transitions, manual confirmations, and modification operations. When deleting a record, a recovery status with an airport identifier is first written. Upon restoration or permanent deletion, permission and tenant verification are performed again to maintain a traceable operational chain.

[0035] The collaborative relationship among the above modules is as follows: the monitoring terminal submits user input along with the airport tenant context in the session to the application service; the application service calls the current airport's process configuration to complete event identification and instance snapshot generation; the step status control module performs execution order verification and status transition based on the instance snapshot; the business data module saves the handling status and ledger content; the system file module returns the location result of the specified page based on the data anchor points in the instance; after the handling is closed, the output module generates reports from the same instance and audit records. This forms a continuous data chain from airport identity boundaries, configuration rules, handling status to data basis and archived output.

[0036] 2. Airport Tenant Context and Access Control After a user selects an airport and completes authentication on the login page, the application service writes the airport identifier, user identifier, and role into the signed session context. Subsequent requests involving process retrieval, event creation, shift handover, call logs, system documents, reports, recycle bins, and user management are all based on this airport identifier for permission verification and data range filtering. Administrators can maintain the airport configuration and accounts, and duty officers can use authorized processing, ledger, and query functions. For deletion operations, the system does not directly clear the business entity but first writes a recycling status and operation record; recovery and permanent deletion functions continue to be executed within the same tenant boundary.

[0037] 3. Configuration-driven event recognition and process instance generation Administrators configure event categories, identification keywords, process steps, key points of each step, precautions, pre-completion verification items, Q&A collection fields, and associated system files for each airport. After on-duty personnel enter the event description, the system standardizes the description text and matches it against the event identification keywords already configured for the current airport; if a match is found, the corresponding event candidate and process summary are displayed. After on-duty personnel confirm the event category and create a handling record, the system associates this record with the process configuration snapshot, Q&A field snapshot, and system file reference snapshot, thereby preventing subsequent configuration modifications from affecting existing historical records.

[0038] 4. Step-by-step processing and verification control based on state machines Each action record maintains the step number, current status, completion time, operator, and verification item status. The system arranges the process steps in a preset order, such as receiving information, initial handling, information transmission, information reporting, and information closure. Once the verification items for the current step are satisfied and the user has explicitly submitted the completion, the server records the completion time of that step and switches the status of the next step from locked to ready for handling; if the preceding steps are not completed, subsequent steps remain in an incomplete state. The page simultaneously displays the core content of all steps, eliminating the need for operators to frequently switch between pages. Figure 2 Incident handling and control flowchart.

[0039] 5. Detailed operational process of incident handling (combined with...) Figure 2 ) Figure 2 The event handling control flow shown is executed through the following steps. The process configurations, business data, and system files used in each step are limited to the tenant context of the currently logged-in airport: The first step is to establish an airport tenant context. Users select an airport and enter their account information on the login page. The system verifies the relationship between the account and the airport. Upon successful verification, a signature session is established, containing the airport identifier, user identifier, and role. Subsequent queries and writes will automatically include this airport identifier. The selected airport is recorded by default on the monitoring terminal for easy access upon subsequent logins.

[0040] The second step involves entering an event description and collecting initial information. On-duty personnel input the event name, location, phenomenon, or keywords at the handling portal. The on-duty terminal retains the complete Chinese input and submits the text to the application service. The application service standardizes spaces, punctuation, and capitalization, forming the event text to be identified, but does not change the original description, which continues to be used in handling records and subsequent reports.

[0041] The third step is to perform current airport rule matching. The event recognition module reads the event categories and recognition words that are currently enabled at the airport, matches the standardized text, and generates candidate results. The candidate results simultaneously display the event name, applicable instructions, and process summary; if multiple results exist, the on-duty personnel confirm the target event based on the on-site situation, and the system does not call the process configuration of other airports.

[0042] The fourth step is to generate a process instance and configuration snapshot. After the user confirms the event, the system copies the valid Q&A fields, step sequence, handling points, precautions, verification items, time limit rules, and system document anchors at the time of the event, generating a process instance snapshot bound to a unique handling record identifier. The system sets the first step as handleable and the remaining steps as locked; thereafter, if the administrator modifies the process configuration, the content already saved in this instance will not be changed.

[0043] The fifth step involves completing the step-by-step processing according to the state machine sequence. The monitoring terminal displays all steps and processing details on a single page, highlighting the currently operable step. The monitoring personnel supplement the question and answer information, step details, and key time points, check the pre-completion verification items for the current step, and submit a completion request. The server re-verifies the status of the preceding steps, required verification items, and record attribution; if verification passes, it records the operator and completion time, changes the current step to "completed," and unlocks the next step; if verification fails, it returns the missing items, and subsequent steps remain locked. This process is repeated until the final step is completed.

[0044] Step 6: Locate the relevant system documents according to the current step. During the handling process, the staff clicks on the associated system document. The system reads the document identifier, chapter, page number, keywords, or text range from the process instance snapshot, first verifying the consistency between the document and the current airport, and then opening the specified PDF page. The page displays only the text range required for the current jump in yellow according to the current anchor point. After closing the document page, the original handling instance and step status are retained.

[0045] Step 7: Complete information closure and instance archiving. After the final step of verification and submission, the step status control module marks the process instance as closed, preventing the restoration of completed steps to an incomplete state and thus disrupting the timeline. The system summarizes event descriptions, collected information, details of each step, completion time, operating entity, and system document references, forming a historical record unaffected by subsequent process configuration modifications.

[0046] Step 8: Generate ledgers, reports, and audit results. The report output module generates handling reports based on saved instances and can export Word documents containing details of all steps and timelines; related operations are synchronously written to the audit log. Collaborative ledgers such as shift handover records and telephone records can reference the airport's handling status to complete subsequent handovers. If a user deletes a record, the system first transfers it to the airport's recycle bin, where only authorized users can restore or permanently delete it.

[0047] 6. System document page number anchors and dynamic emphasis positioning The system document module allows airport administrators to upload, download, or delete airport documents and maintain the association between document names, chapter names, page numbers, keywords, and corresponding process steps. When an operator clicks on a document reference on the process page, the system sends the document identifier, page number, and location information corresponding to the current step to the PDF viewing page. The viewing page then opens the specified page and highlights only the text area required for the current jump. By saving steps, chapters, and page numbers together, the system avoids issues such as simultaneous highlighting of multiple chapters or inaccurate jumps caused by relying solely on vague keywords.

[0048] 7. Collaborative ledger, audit, and report output Shift handover and telephone records use a date-based ledger model. When creating a new ledger, the system does not pre-generate blank official records; a visible ledger is created only after the user fills in and saves the entry. For saved records, the page provides a browsing mode and an editing mode. The editing mode displays changes, and saving generates update time and operator information. The system summarizes the Q&A information, step details, completion time nodes, associated files, and operation traces during event handling to generate a handling report, and supports exporting Word documents containing handling step details and time nodes.

[0049] To reduce repetitive data entry, the system maintains recently used values ​​for different business fields such as name, company, phone number, and location, and provides candidate suggestions near the corresponding input boxes. Candidate values ​​are displayed in the order of most recent use, and different fields are not mixed. For unsaved changes, the system displays the change status near the corresponding input box, making it easier for staff to identify the content to be saved.

[0050] (2) Technical effects By using airport tenant identifiers throughout identity authentication, permission verification, data query, file referencing, and recycling operations, multiple airports can be supported to operate independently in a single deployment, reducing the cost of redundant construction and minimizing the risk of data contamination across airports.

[0051] By using event recognition, process snapshots, and sequential unlocking mechanisms, abstract institutional requirements are transformed into executable page states and verification actions, reducing the reliance of on-duty personnel on memory and manual retrieval.

[0052] By linking steps with chapters, page numbers, and highlighted areas in system documents, the path to locating institutional data is shortened, the basis for the current step can be directly presented, and the interpretability of the process is improved.

[0053] By establishing a unified ledger, timeline, operating entity, recycle bin, and Word report mechanism, a traceable record is formed from the occurrence, handling, handover to review of the incident, which facilitates operation management and post-event verification.

[0054] This invention also provides a process-oriented event handling and collaborative ledger management method for multi-airport operation and duty, including the following steps: Step S1, establish airport tenant context: The user selects an airport and enters account information on the login page. The system verifies the ownership relationship between the account and the airport. After successful verification, a signature session containing airport identifier, user identifier and role is established.

[0055] Step S2, Enter Event Description: The on-duty personnel enter the event name, location, phenomenon, or keywords at the handling portal. The on-duty terminal retains the complete Chinese input and submits the text to the application service; the application service standardizes spaces, punctuation, and capitalization, forming the event text to be identified, but does not change the original description, which continues to be used in handling records and subsequent reports.

[0056] Step S3: Perform current airport rule matching: The event recognition module reads the event categories and recognition words that are currently enabled at the airport, matches the standardized text, and generates candidate results. The candidate results simultaneously display the event name, applicable instructions, and process summary; if multiple results exist, the on-duty personnel confirm the target event based on the on-site situation, and the system does not call the process configuration of other airports.

[0057] Step S4: Generate a process instance and configuration snapshot: After the user confirms the event, the system copies the valid Q&A fields, step sequence, handling points, precautions, verification items, time limit rules, and system document anchors at the time of the event, generating a process instance snapshot bound to a unique handling record identifier. The system sets the first step as handleable and the remaining steps as locked; thereafter, if the administrator modifies the process configuration, the content already saved in this instance will not be changed.

[0058] Step S5: Complete the step-by-step processing according to the state machine sequence: The monitoring terminal displays all steps and processing content on a single page, highlighting the currently operable step. The monitoring personnel supplement the Q&A information, step details, and key time nodes, check the pre-completion verification items for the current step, and submit a completion request. The server re-verifies the status of the preceding steps, the required verification items, and the record attribution; if the verification passes, it records the operator and completion time, changes the current step to "completed," and unlocks the next step; if the verification fails, it returns the missing items, and subsequent steps remain locked. The above process is executed cyclically until the last step is completed.

[0059] Step S6: Locate the relevant system documents according to the current step: During the handling process, the on-duty personnel click on the associated system document. The system reads the document identifier, chapter, page number, keywords, or text range from the process instance snapshot. First, it verifies the consistency between the document and the current airport, and then opens the specified PDF page. The viewed page only displays the text range required for the current jump in yellow according to the current anchor point. After closing the document page, the original handling instance and step status are still retained.

[0060] Step S7, completing information closure and instance archiving: After the final step of verification and submission, the step status control module marks the process instance as closed, preventing the restoration of completed steps to an incomplete state and thus disrupting the timeline. The system summarizes event descriptions, collected information, details of each step, completion time, operating entity, and system document references, forming a historical record that cannot be affected by subsequent process configuration modifications.

[0061] Step S8 generates ledgers, reports, and audit results: The report output module generates handling reports based on saved instances and can export a Word document containing all step details and time nodes; related operations are synchronously written to the audit log. Collaborative ledgers such as shift handover records and telephone records can reference the airport's handling status to complete subsequent handovers. If a user deletes a record, the system first transfers it to the airport's recycle bin, where only authorized users can restore or permanently delete it.

[0062] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are only used to illustrate the present invention and should not be regarded as limiting the scope of the present invention.

[0063] Example 1: System Deployment and Multi-Airport Tenant Configuration This embodiment takes the example of Airport A and Airport B under an airport group sharing a single AODS airport operation and monitoring system to illustrate the multi-airport tenant deployment and configuration process of the system.

[0064] The system adopts a browser / server architecture, with the server running in a Node.js environment and business data stored in an SQLite database. After deployment, the system administrator first creates two tenants, Airport A and Airport B, within the system. For each airport, the administrator configures the user accounts, role permissions, event flows, policy documents, and business parameters.

[0065] Taking Airport A as an example, after logging into the system, the administrator completes the following configuration in the process configuration management module: (1) Configure event categories. For example, configure the "Hydrogen-borne Object Handling" event, set the event name to "Hydrogen-borne Object Emergency Handling", and identify keywords including "Hydrogen-borne object", "Balloon", "Kite", "Drone", "Aerial object", etc.

[0066] (2) Configure the handling steps. Configure the steps in the preset order: Step 1 "Receive Information", Step 2 "Preliminary Handling", Step 3 "Information Transmission", Step 4 "Information Reporting", Step 5 "Information Closure". Configure the key points, precautions and pre-completion verification items for each step.

[0067] (3) Configure the question and answer collection fields. For example, configure fields such as "Event discovery time", "Event location", "Type of airborne object", "Affected area" and "Measures taken".

[0068] (4) Upload system documents and configure anchor points. The administrator uploads the PDF file of "Emergency Response Plan for Airborne Objects", maintains the document identifier, chapter name, page number, and keywords, and associates each chapter with the corresponding process steps. For example, associate pages 15-18 of Chapter 3 "Initial Response Measures" with step 2 "Initial Response".

[0069] Airport B's administrator independently completes similar configurations, and the configuration data is saved in the database according to the airport identifier. Airport A's configuration and information will not appear in Airport B's user interface.

[0070] Example 2: Event Recognition and Process Instance Generation This embodiment uses the handling of an airborne object incident by staff at Airport A as an example to illustrate the specific process of event identification and process instance generation.

[0071] The staff member on duty entered the event description into the event handling portal of the monitoring terminal: "At 09:25, a red balloon was spotted at the north end of the runway, at a height of approximately 50 meters, drifting towards the runway." The monitoring terminal then submitted the complete Chinese input to the application service.

[0072] The event identification and process instance generation module performs text normalization on the event description: removing extra spaces and standardizing punctuation marks to form the text of the event to be identified. Then, the module reads all event categories and identification words currently in operation at Airport A and matches them against the normalized text. Because the text contains keywords such as "balloon" and "drifting," the system identifies the "emergency response to airborne objects" event and displays the candidate results, including the event name "emergency response to airborne objects," applicable instructions, and a process summary.

[0073] After the on-duty personnel confirm the candidate event, the event identification and process instance generation module immediately copies the currently valid question and answer fields, step sequence, handling points, precautions, verification items, time limit rules, and system document anchors for the event, generating a process instance snapshot bound to a unique handling record identifier (e.g., "A-20260903-001"). The system sets step 1 "Receive Information" to a handleable state, and steps 2 through 5 to a locked state.

[0074] At this point, even if the airport administrator subsequently modifies the "emergency response to airborne debris" process configuration (e.g., adding or deleting steps, or modifying verification items), the generated response record "A-20260903-001" remains unaffected, ensuring the consistency and traceability of historical response records.

[0075] Example 3: Step-by-step processing and state machine control This embodiment follows Embodiment 2, illustrating the specific process by which on-duty personnel complete step-by-step handling according to the state machine sequence.

[0076] The monitoring terminal displays the core content and current status of all five steps on the same workflow page. Step 1, "Receiving Information," is in an actionable state (highlighted), while steps 2 through 5 are in a locked state (grayed out). The page also displays the key points for handling step 1—"Record the time, location, phenomenon, and reporter information of the incident"—and the verification items—"□Time of discovery recorded □Location of incident recorded □Description of phenomenon recorded □Reporter recorded."

[0077] After the on-duty personnel fill in the Q&A collection fields (event discovery time, location, type of airborne object, etc.), they check all the verification items and click "Submit to Complete". The step status control module verifies on the server side: no preceding steps (step 1 is the first step), all necessary verification items are checked, and the record belongs to Airport A. After the verification is successful, the module records the operator as "Zhang San" and the completion time as "2026-09-03 09:28:15", changes the status of step 1 to "Completed", and switches the status of step 2 "Initial Handling" from locked to handleable.

[0078] The on-duty personnel then complete steps 2 through 5 in sequence. In step 2, "Initial Handling," the on-duty personnel click on the associated system file. The system reads the file identifier and anchor point information of the "Emergency Response Plan for Airborne Objects" (Chapter 3, pages 15-18) from the process instance snapshot. After verifying that the file belongs to Airport A, the system opens the PDF in a browser and jumps to page 15, highlighting the relevant text area under "Initial Handling Measures" in yellow. After the on-duty personnel complete the on-site handling measures according to the plan, they check the verification items and submit, completing step 2.

[0079] The above process is repeated until step 5, "Information Loop Closure," is completed. After the final step is verified and submitted, the step status control module marks the entire process instance as "Closed Loop," prohibiting any completed step from being restored to an incomplete state, thereby ensuring the integrity and immutability of the processing timeline.

[0080] Example 4: Shift handover and telephone record management This example illustrates the process of managing separate ledgers for shift handover and telephone records.

[0081] The shift handover log adopts a fill-in-the-blank model. After the outgoing and incoming shift personnel fill in the handover details, incoming personnel, handover items, risk warnings, and key tasks on the handover page, they click the "Save" button. Only then does the system create a visible handover record, recording the save time and the operator. Saved handover records support both browsing and editing modes: in browsing mode, the record content is displayed in read-only mode; in editing mode, the system records each modification, the update time, and the operator, forming a complete change history.

[0082] Telephone records also follow a "fill in first, save later" model. During or after a call, staff fill in the telephone record, including call time, the other party, a summary of the call content, and any proposed actions. Once completed, the record is saved as an official document.

[0083] To reduce duplicate data entry, the system maintains recently used values ​​for different business fields such as name, organization, phone number, and location. For example, near the "Name of Caller" input box, the system displays a list of recently used names for that airport, sorted in descending order of usage time; near the "Event Location" input box, the system displays a list of recently used locations. Candidate values ​​for different fields are not mixed to avoid mistakenly entering name candidates into location fields.

[0084] Example 5: Auditing, Recovery, and Report Generation This example illustrates the audit log, recycle bin, and report generation mechanisms.

[0085] In the handling process of Example 3, each state transition of the step status control module (e.g., step 1 changes from disposable to completed, step 2 changes from locked to disposable) is recorded as an audit record by the audit, recycling, and report output module. This audit record includes the handling record identifier, step number, operation type (state transition), operator, operation time, and states before and after the operation. If a staff member accidentally deletes a handling record, the system does not directly delete the record but writes it to the recycle bin and marks it as a recycled record with an airport identifier. The system also records the deleting operator and the deletion time. Users with recovery permissions can view the deleted record in the recycle bin and perform a recovery operation. After recovery, the record is returned to the original business data table. Users with permanent deletion permissions can perform permanent deletion. Before permanent deletion, the system re-verifies the operator's airport ownership and permissions.

[0086] After the incident is closed, the report output module summarizes the event description, Q&A information, details of each step, completion time points, operating entities, and system document references to generate a structured incident report. On-duty personnel can export a Word document containing all step details and time points with one click for use in post-incident reviews, safety reports, or archiving.

[0087] Alternative solutions description Figure 1 This is a logical architecture diagram of the AODS airport operation monitoring system of the present invention, which shows the hierarchical relationship and data flow between the monitoring terminal, application service, business data storage, system information service and report output module.

[0088] Figure 2 This is a flowchart of the event handling control process of the present invention, which shows the complete handling process from event description entry, rule matching, step-by-step handling, data location to closed-loop archiving.

[0089] Industrial Applicability: This invention can be widely applied in scenarios such as airport operation control centers, airport group operation monitoring, and multi-airport collaborative management. Through a browser / server architecture, personnel can access the system via PC or mobile browsers to perform monitoring and record management anytime, anywhere. The system supports multiple airports sharing a single deployment, significantly reducing IT infrastructure and maintenance costs, and possesses excellent industrial applicability and promotional value.

[0090] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A process-oriented incident handling and collaborative ledger management system for multi-airport operation and duty, characterized in that, include: The duty terminal module runs on the terminal used by duty personnel or administrators to complete tasks such as airport selection and login, event description entry, candidate event confirmation, question and answer information collection, step verification and completion, system document viewing, shift handover and telephone record filling. The airport tenant context and identity permission module is used to receive the airport identifier, account and password submitted by the monitoring terminal, verify the ownership relationship between the account and the airport, and form a signature session context containing the airport identifier, user identifier and role after successful verification. Each subsequent business operation is based on the signature session context to perform airport data range verification and role permission verification. The process configuration management module is used by the current airport administrator to maintain the event categories, identification words, question and answer fields, step sequence, handling points, precautions, pre-completion verification items, time limit rules, and system document anchors for the airport. The configuration data is saved separately according to the airport identifier. The event recognition and process instance generation module is used to standardize the text description of the event entered by the duty personnel, call the current airport's valid recognition words and event rules for matching and output candidate events. In response to the user's confirmation of the candidate event, it copies the corresponding process steps, Q&A fields, verification items and data anchors, forms a process instance snapshot with configuration version information and generates a unique handling record identifier. The step status control module is used to maintain the locked, handleable, and completed status of each step for the process instance, and to save the verification results, the operator who completed the operation, and the completion time. In response to the step completion request submitted by the monitoring terminal, the server verifies the status of the previous step and the current verification item. After the verification is successful, the completion information is recorded with a status transition and the next step is unlocked. The business data and collaborative ledger module is used to save incident handling instances, Q&A content, step status, shift handover, telephone records, control room duty logs, and field candidate values ​​according to airport identification. The system document and anchor point positioning module is used to receive data anchor points in process instances according to airport management PDF system documents and their document identifiers, chapters, page numbers, keywords and text ranges, and return the specified page and positioning parameters after verifying the airport to which the document belongs. The audit, recovery, and report output module is used to summarize event descriptions, Q&A information, step details, operators, completion time, and supporting documentation, generate browsing reports and documents, and record key status transitions and operations. When deleting a record, a recovery status with an airport identifier is written first, and permission and tenant verification are performed when restoring or permanently deleting the record.

2. The system according to claim 1, characterized in that, The step status control module arranges the process steps in a preset order. When the verification items of the current step are satisfied and the user submits the data, the server records the completion time of the step and switches the status of the next step from locked to ready for processing. If the preceding steps are not completed, the subsequent steps remain in an incomplete state. After the last step is verified and submitted, the process instance is marked as closed, and it is prohibited to restore the completed steps to an incomplete state.

3. The system according to claim 1, characterized in that, The system document and anchor point positioning module transmits the file identifier, page number, and positioning information corresponding to the current step to the PDF viewing page. The viewing page opens the specified page based on the positioning information and highlights only the text range required for the current jump. The positioning information includes chapter name, page number, keywords, or text. At least one of the words in the range.

4. The system according to claim 1, characterized in that, The event recognition and process instance generation module standardizes the event description by removing spaces, punctuation, and capitalization to form the text of the event to be recognized, while retaining the original description for handling records and reports. The candidate results simultaneously display the event name, applicable instructions, and process summary; if multiple candidate results exist, the on-duty personnel shall confirm the target event.

5. The system according to claim 1, characterized in that, The business data and collaborative ledger module adopts an independent ledger method for shift handover and telephone records, which is filled in first and then saved. The browsing mode displays the saved snapshot, and the editing mode records changes and generates update time and operator information. Candidate values ​​such as name, unit, and location are maintained separately according to field category and most recent usage time, and candidate values ​​are not mixed between different fields.

6. The system according to claim 1, characterized in that, In the airport tenant context and identity permission module, after a user selects an airport and completes identity verification on the login page, the selected airport is recorded in the monitoring terminal by default. Subsequent requests involving process reading, event creation, shift handover, telephone records, system documents, reports, recycle bins, and user management are all based on the airport identifier for permission verification and data range filtering. Administrators can only maintain the configuration and account of their own airport.

7. A process-oriented incident handling and collaborative ledger management method for multi-airport operation and duty, characterized in that, Includes the following steps: Step S1, establish airport tenant context: The user selects an airport and enters account information on the login page. The system verifies the ownership relationship between the account and the airport. After successful verification, a signature session containing airport identifier, user identifier and role is established. Step S2, Enter Event Description: The on-duty personnel enter the event description at the handling entry point, and the on-duty terminal submits the text to the application service. The application service performs standardization processing on the text to form the event text to be identified. Step S3, perform current airport rule matching: The event recognition module reads the event categories and recognition words of the current airport in the enabled state, matches the normalized text and forms candidate results; Step S4, Generate process instance and configuration snapshot: After the user confirms the event, the system copies the currently valid question and answer fields, step sequence, handling points, precautions, verification items, time limit rules and system file anchors of the event, generates a process instance snapshot bound to a unique handling record identifier, sets the first step as handleable, and sets the remaining steps as locked; Step S5: Complete the step-by-step processing according to the state machine sequence: The terminal displays all steps and processing content on a single page. The staff adds Q&A information and step details, checks the pre-completion verification items for the current step, and submits a completion request. The server verifies the status of the preceding steps, the required verification items, and the record ownership. If the verification passes, it records the operator and completion time, changes the current step to "completed," and unlocks the next step. If the verification fails, it returns the missing items, and subsequent steps remain locked. This process is repeated until the last step is completed. Step S6, Locate the relevant system data according to the current step: During the handling process, the on-duty personnel click on the associated system file. The system reads the file identifier and location parameters from the process instance snapshot, verifies the consistency of the file with the current airport, opens the specified page and highlights it. Corresponding text range; Step S7, complete information closure and instance archiving: After the final step of verification and submission, mark the process instance as closed, and summarize the event description, collected information, details of each step, completion time, operation subject and system document references to form a history record; Step S8: Generate ledgers, reports, and audit results: Generate disposal reports based on saved instances and export documents; related operations are synchronously written to audit records; when deleting records, first transfer them to the airport's recycle bin.

8. The method according to claim 7, characterized in that, In step S3, the system does not call the process configuration of other airports besides the currently logged-in airport; in step S4, subsequent modifications to the process configuration by the administrator will not affect the already generated process instance snapshot.

9. The method according to claim 7, characterized in that, In step S6, the viewing page displays only the text range required for this jump in yellow according to the positioning parameters. After closing the data page, the original processing instance and step status are retained.

10. The method according to claim 7, characterized in that, In step S8, shift handover and telephone records are archived by date. When creating a new ledger, the system does not pre-generate blank official records. The visible ledger is created only after the user fills in the information and saves it. Saved records provide browsing mode and editing mode. Editing mode displays the changed content.

Images