Safety management monitoring system for port vehicle traffic management based on big data

Abstract

The invention relates to the technical field of port automation, and discloses a safety management monitoring system for port vehicle traffic management based on big data. Comprising a data acquisition module, an event extraction module, an event system modeling module, a safety specification modeling module, a controllable observable event boundary identification module, a specification projection module, a supervision permission control module and a runtime verification and control execution module. Event modeling is carried out on multi-source traffic data, a safety specification is projected to a controllable and observable event subset, an executable safety specification and a corresponding permission control strategy are constructed, and specification consistency verification and dynamic permission control of traffic control events such as gate release, road section entry and intersection pass are realized. By introducing the controllable and observable event boundary recognition module and the standard projection module, the problem of control mismatch caused by direct participation of uncontrollable events or unobservable events in safety judgment is avoided.

Description

Technical Field

[0001] This invention relates to the field of port automation technology, and in particular to a safety management and monitoring system for port vehicle traffic management based on big data. Background Technology

[0002] Port vehicle traffic management systems typically involve multiple subsystems, including vehicle positioning, road access control, gate release control, and operation scheduling coordination. Their operation relies on the coordinated work of multi-source sensing and control devices.

[0003] Existing technologies often include all observed traffic events in the scope of safety assessment and directly perform conflict detection or constraint verification based on these events and safety rules. These events include those that can be directly intervened in through the control interface, such as gate opening, intersection signal release, and road segment entry permission, as well as events that cannot be directly suppressed or triggered through the control interface, such as vehicle acceleration / deceleration behavior, temporary stopping behavior, and sudden changes in state caused by the external environment. Meanwhile, some events, although logically important to safety assessment, cannot have their occurrence time and location determined deterministically by the system due to limitations in sensor deployment location, communication latency, or sensing accuracy; they can only be observed in an incomplete or uncertain manner.

[0004] However, the inventors of this application discovered in the process of implementing the relevant technical solutions that the prior art has at least the following technical problems: because the safety specifications do not distinguish between the controllability and observability of events, the safety determination process directly uses the complete set of events containing uncontrollable or unobservable events as the constraint object, resulting in the problem of control mismatch caused by uncontrollable or unobservable events directly participating in the safety determination. Summary of the Invention

[0005] To overcome the above shortcomings, this invention provides a safety management and monitoring system for port vehicle traffic management based on big data. It aims to improve the problem of control mismatch caused by the failure of existing safety regulations to distinguish between the controllability and observability of traffic events, resulting in uncontrollable or unobservable events directly participating in safety judgment.

[0006] This invention provides the following technical solution: a safety management and monitoring system for port vehicle traffic management based on big data, comprising: The data acquisition module is used to acquire port vehicle positioning data, gate status data, intersection control data, and operation scheduling event data, and to perform time and spatial alignment on the data. The event extraction module is used to generate discrete traffic events based on the aligned data, according to preset resource boundaries and state determination rules, and to attach a confidence label to each discrete traffic event. The event system modeling module is used to construct a discrete event system model based on the discrete traffic events and establish the occupancy status relationship between vehicles and port resources. The safety specification modeling module is used to represent port traffic safety rules as a set of safety specifications consisting of event sequence constraints and resource mutual exclusion constraints. The controllable and observable event boundary identification module is used to classify the events in the discrete event system by controllability and observability, and obtain a set of controllable events, a set of uncontrollable events, a set of observable events, and a set of unobservable events. The specification projection module is used to map the set of security specifications to a subset of events that simultaneously belong to the set of controllable events and the set of observable events, thereby generating executable security specifications; The supervision and permission control module is used to construct a permission set for controllable events based on the executable security specification and the discrete event system model. The runtime verification and control execution module is used to perform standardization and consistency judgment on the real-time event sequence, and to allow or block the gate release event, road segment entry event and intersection release event according to the permission set.

[0007] Preferably, in the data acquisition module, the steps of acquiring port vehicle positioning data, barrier gate status data, intersection control data, and operation scheduling event data, and performing time and spatial alignment on the data, include: Establish timestamp sequences for vehicle positioning data, barrier gate status data, intersection control data, and operation scheduling event data according to their data sources; Based on a preset time mapping relationship, each timestamp sequence is converted to a unified timeline; Perform coordinate transformation on data with different coordinate representations according to the port's unified coordinate system; The multi-source data, after time mapping and coordinate transformation, will be rearranged according to a unified time order. Generate an aligned data record set containing vehicle identifiers, resource identifiers, time information, and spatial location information.

[0008] Preferably, in the event extraction module, the step of generating discrete traffic events according to preset resource boundaries and state determination rules, and attaching a confidence level identifier to each discrete traffic event, includes: Based on the topological relationship between the aligned vehicle trajectory data and the port resource spatial boundary, the time when the vehicle enters and leaves the resource is determined. An entry event is generated when entry is determined, and a departure event is generated when departure is determined. Generate release and closure events based on the changes in the gate's status; For each event, record the event type, vehicle identifier, resource identifier, and occurrence time; Perform consistent matching of similar events from different data sources; For each event, a corresponding confidence level is calculated and attached based on the consistency matching results; A discrete traffic event sequence is formed in chronological order.

[0009] Preferably, in the event system modeling module, the step of constructing a discrete event system model based on the discrete traffic events and establishing the occupancy status relationship between vehicles and port resources includes: The set of event types for the discrete traffic events is defined as an event alphabet; Construct a system state set based on the combined occupancy states of vehicles and resources; Construct state transition relationships based on changes in resource usage before and after the event; Establish a vehicle and resource occupancy mapping table for each state; When an event is triggered, update the corresponding state occupancy mapping table to indicate the state change of resources being occupied or released; A discrete event system model is formed, which includes a set of states, a set of events, and state transition relationships.

[0010] Preferably, in the safety specification modeling module, the step of representing port traffic safety rules as a set of safety specifications consisting of event sequence constraints and resource mutual exclusion constraints includes: Establish a resource mutual exclusion table for port sections, intersections, narrow passages, and work area entrances; Transform resource mutual exclusion relationships into constraints that do not allow simultaneous use of resources; Establish an event precedence table for rules involving the sequence of operations such as release, entry, inspection, and passage; Transform the event precedence relationship into an event sequence constraint; The resource mutual exclusion constraints and event sequence constraints are uniformly encoded into structured security specification entries; This forms a set of safety specifications containing multiple safety specification entries.

[0011] Preferably, in the controllable and observable event boundary identification module, the steps of classifying events in the discrete event system by controllability and observability include: Establish a mapping table between port control interfaces and event types; According to the corresponding relationship table, events that can be triggered or prohibited through the control interface are controllable events; The remaining events are marked as uncontrollable events; Based on the event confidence level and sensor coverage, events that can be reliably sensed are identified as observable events; The remaining events are marked as unobservable events; Create a joint classification table of events with controllability and observability categories.

[0012] Preferably, in the specification projection module, the step of mapping the set of security specifications to a subset of events that simultaneously belong to the set of controllable events and the set of observable events to generate executable security specifications includes: Extract event types that simultaneously belong to both the set of controllable events and the set of observable events to form a subset of target events; Traverse the event sequence constraints and resource mutual exclusion constraints involved in the set of security specifications; Retain only the security specification entries that contain events from a subset of the target events; For safety specification entries that contain uncontrollable or unobservable events, establish a correspondence between them and proxy events in the target event subset; Based on the aforementioned correspondence, uncontrollable or unobservable events in the original safety specification entries are replaced with corresponding proxy events; The replaced security specification entries are combined with the retained security specification entries to form an executable security specification set that contains only a subset of the target events.

[0013] Preferably, in the supervision and permission control module, the step of constructing a permission set for controllable events based on the executable security specification and the discrete event system model includes: Obtain the mapping relationship between vehicles and resource occupancy corresponding to the current system state in the discrete event system model; Enumerate all controllable events under the current system state; For each controllable event, simulate its state transition result in the discrete event system model; Determine whether the state transition result violates any specification entry in the executable security specification set; Add controllable events that do not cause violations of specification entries to the permission set; A set of controllable event permissions corresponding to the current system state is formed.

[0014] Preferably, in the runtime verification and control execution module, the step of performing a conformity check on the real-time event sequence includes: Receive discrete traffic events arriving in chronological order; Based on the classification results output by the controllable and observable event boundary recognition module, the discrete traffic events are mapped to a subset of target events; Construct a sequence of projected events based on a subset of the target events; The sequence of projection events is matched one by one with the set of executable security specifications; Identify whether the current sequence of projected events satisfies the event sequence constraints and resource mutual exclusion constraints in the executable security specification set; Generate the standard consistency judgment result.

[0015] Preferably, in the runtime verification and control execution module, the step of allowing or blocking the gate release event, road segment entry event, and intersection release event based on the permission set includes: Obtain the set of controllable events permitted under the corresponding system state before a controllable event is triggered; Determine whether the controllable event to be triggered exists in the permission set; When a controllable event to be triggered exists in the permission set, an execution command is sent to the corresponding control interface; When the controllable event to be triggered does not exist in the permission set, a blocking command is sent to the corresponding control interface; At the same time as the blocking command is issued, the proxy event flow associated with the blocked event is triggered according to the proxy event correspondence established by the standard projection module. The execution result of the proxy event process is used as a new discrete traffic event input to the event extraction module and the event system modeling module to update the subsequent system state.

[0016] The present invention has the following beneficial effects: 1. This invention introduces a controllable and observable event boundary identification module and a specification projection module to map the original safety specifications onto the intersection of the controllable event set and the observable event set to form an executable safety specification. This ensures that safety constraints only apply to event types that the system can actually intervene in and reliably perceive. As a result, the safety management constraints are structurally consistent with the port's existing control interfaces and perception conditions, avoiding control mismatch problems caused by uncontrollable or unobservable events directly participating in safety determination.

[0017] 2. This invention constructs a discrete event system model and maintains the occupancy relationship between vehicles and port resources at the state level. It integrates resource mutual exclusion constraints and event sequence constraints into the same state transition and permission determination framework, so that there is a clear logical correspondence between the execution of controllable events such as gate release, road segment entry and intersection release and resource occupancy changes. This enables traffic safety constraints to make consistent judgments and permission control based on the state evolution process.

[0018] 3. By setting up a supervision and permission control module and a runtime verification and control execution module, this invention generates a corresponding set of controllable event permissions in each system state and verifies and intercepts them in real time before the event is triggered. This ensures that security specifications are no longer just used as a basis for post-event analysis, but participate in the permission determination process before the event is triggered. Thus, an online security management closed loop with discrete event models, executable security specifications and permission control strategies as the core is formed during system operation. Attached Figure Description

[0019] Figure 1 This is a diagram illustrating the architecture of a port vehicle traffic management and safety monitoring system based on big data, as proposed in this invention. Figure 2 This invention presents a flowchart of discrete event modeling and safety specification construction for a port vehicle traffic management safety monitoring system based on big data, as proposed in this invention. Figure 3 This is a schematic diagram of the controllable and observable boundary identification and standardized projection of a port vehicle traffic management safety management monitoring system based on big data proposed in this invention. Figure 4 This invention presents a closed-loop diagram of the supervision, permission control, and runtime execution of a port vehicle traffic management safety management and monitoring system based on big data. Detailed Implementation

[0020] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Reference Figures 1-4 This invention provides a safety management and monitoring system for port vehicle traffic management based on big data, comprising: The data acquisition module is used to acquire port vehicle positioning data, barrier gate status data, intersection control data, and operation scheduling event data, and to perform time and spatial alignment on the data. The event extraction module is used to generate discrete traffic events based on the aligned data, according to preset resource boundaries and state determination rules, and to attach a confidence label to each discrete traffic event. The event system modeling module is used to construct discrete event system models based on discrete traffic events and establish the occupancy status relationship between vehicles and port resources. The safety specification modeling module is used to represent port traffic safety rules as a set of safety specifications consisting of event sequence constraints and resource mutual exclusion constraints. The controllable and observable event boundary identification module is used to classify events in a discrete event system by controllability and observability, and obtain sets of controllable events, uncontrollable events, observable events, and unobservable events. The specification projection module is used to map the set of security specifications to a subset of events that simultaneously belong to the set of controllable events and the set of observable events, thereby generating executable security specifications; The supervision and licensing control module is used to construct a set of licenses for controllable events based on executable security specifications and discrete event system models. The runtime verification and control execution module is used to perform standardization and consistency judgment on real-time event sequences, and to allow or block gate release events, road segment entry events and intersection release events according to the permission set.

[0022] Specifically, the data acquisition module connects to the port vehicle positioning terminal, gate controller, intersection signal controller, and operation scheduling system via a communication interface to receive raw data sequences identified by timestamps. Let the vehicle set be... Port resources are aggregated as The time set is Then, on a unified timeline, for any vehicle The aligned observation record at time t is represented as follows: ; in, This indicates the spatial position of the vehicle in the port's unified coordinate system. It indicates the vehicle's operating status and the status information of the corresponding equipment.

[0023] The event extraction module is based on aligned observation records, according to the port resource spatial boundary function. ; Vehicle position changes are determined, generating entry and departure events. Each discrete traffic event is represented as a quintuple: ;in, Indicates the event type, Indicates vehicle identification. Indicates associated resources, The value represents the time when the event occurred, and q represents the confidence level calculated by multi-source consistency.

[0024] The event system modeling module will construct an event set from all event types. The system is then abstracted into a discrete event system: ;in, For a set of states, This is a state transition relation. Given the initial state, for any state The relationship between vehicle and resource occupancy is defined as follows: This indicates the extent to which vehicles are using port resources in this state.

[0025] The safety specification modeling module represents port traffic rules as a set of safety specifications. ;in, Represents a set of event sequence constraints. This represents a set of mutually exclusive resource constraints. Resource mutual exclusion relationships consist of a set of mutually exclusive resource pairs. Given any state Define resource usage projection The resource mutual exclusion constraint is then expressed as: .

[0026] The controllable and observable event boundary identification module will identify the event set. Divided into: ; ;in, A set of controllable events that can be triggered or suppressed by the port control interface. To determine the set of observable events that meets the confidence threshold requirement, the canonical projection module constructs a subset of the target events: And define the projection operator. ; Set up safety standards Mapped to contain only The set of executable security specifications for events .

[0027] The supervised permission control module constructs a set of controllable event permissions for any state x in the discrete event system model G: ;in, This indicates a violation of the set of executable security specifications. The state set. The runtime verification and control execution module performs projection calculations on the real-time event sequence: And based on the license set The execution status of gate release events, road segment entry events, and intersection release events is determined, thereby forming a closed-loop processing structure based on a discrete event system model, controllable and observable event boundaries, and executable safety specifications during the system state evolution process.

[0028] Furthermore, in the data acquisition module, the steps of acquiring port vehicle positioning data, barrier gate status data, intersection control data, and operation scheduling event data, and performing time and spatial alignment on the data, include: Establish timestamp sequences for vehicle positioning data, barrier gate status data, intersection control data, and operation scheduling event data according to their data sources; Based on a preset time mapping relationship, each timestamp sequence is converted to a unified timeline; Perform coordinate transformation on data with different coordinate representations according to the port's unified coordinate system; The multi-source data, after time mapping and coordinate transformation, will be rearranged according to a unified time order. Generate an aligned data record set containing vehicle identifiers, resource identifiers, time information, and spatial location information.

[0029] Specifically, the data acquisition module connects to at least the communication interfaces of satellite positioning terminals, short-range positioning base stations, gate controllers, intersection signal controllers, and port operation scheduling systems. The raw record output from any data source s is represented as: ; in, Indicates the data source identifier. Represents the local timestamp. Indicates location coordinates or device space identifier. This indicates attribute information related to the status of a vehicle or equipment.

[0030] The time alignment process is achieved by constructing a unified time mapping function. Let the reference time axis of the port system be... Define a time mapping function for any data source s: ;in, This is a monotonic mapping function used to map local timestamps from various data sources to a unified time axis. The time mapping function establishes a correspondence table based on fixed synchronization points and corrects continuous time intervals through interpolation. The fixed synchronization points include the gate opening and closing times, signal light phase switching times, and dispatch command issuance times.

[0031] The spatial alignment process is completed based on the port unified coordinate system and resource topology model. Let the port unified coordinate system be... For any primitive space representation Define coordinate transformation function: ;in, Map geographic coordinates, relative coordinates, or device logical numbers from different sources to spatial locations in a unified coordinate system. And further through resource topology mapping functions Link spatial location to corresponding port resource identifiers. .

[0032] After completing the time and space mapping, an aligned data unit is constructed for each data record: ;in, For vehicle identification, For resource identification, To unify the points in time on the timeline, To unify position coordinates in a coordinate system, This refers to information about the vehicle's operating status or the equipment's status.

[0033] The data acquisition module sorts all aligned data units according to a unified time axis T, forming a multi-source aligned data sequence: The aligned data sequence will then be used as input for the subsequent event extraction module and event system modeling module.

[0034] Through the aforementioned time and space alignment processing, vehicle positioning information, gate status information, intersection control information, and operation scheduling information, which were originally distributed under different time bases and coordinate systems, are transformed into a structured data sequence under a unified time axis and a unified spatial coordinate system. This enables various types of data to have a consistent representation basis in terms of temporal and spatial relationships, thereby providing a deterministic input data structure for subsequent event determination, state transition analysis, and safety specification constraint calculation based on resource boundaries.

[0035] Furthermore, in the event extraction module, the steps of generating discrete traffic events according to preset resource boundaries and state determination rules, and attaching a confidence level label to each discrete traffic event, include: Based on the topological relationship between the aligned vehicle trajectory data and the port resource spatial boundary, the time when the vehicle enters and leaves the resource is determined. An entry event is generated when entry is determined, and a departure event is generated when departure is determined. Generate release and closure events based on the changes in the gate's status; For each event, record the event type, vehicle identifier, resource identifier, and time of occurrence; Perform consistent matching of similar events from different data sources; For each event, a corresponding confidence level is calculated and attached based on the consistency matching results; A discrete traffic event sequence is formed in chronological order.

[0036] Specifically, the event extraction module receives the aligned data sequence output by the data acquisition module. ; where each aligned data unit Includes vehicle identification. Resource Identifier Time on a unified timeline Position in a unified coordinate system and the corresponding vehicle or equipment status information The spatial boundaries of port resources are stored in the form of a resource topology model, and a spatial coverage function is defined for any resource r: ; in, This represents the spatial extent of resource r in a unified coordinate system. The event extraction module extracts data from the same vehicle v at adjacent time points. and The spatial position is continuously determined when the condition is met. When, an entry event is generated for vehicle v entering resource r; when the condition is met... When vehicle v leaves resource r, a departure event is generated, and the event is recorded by the time of occurrence. As an event time marker.

[0037] The event extraction module parses the status data output by the barrier gate controller and the intersection signal controller according to the status change rules. When a barrier gate status changes from closed to open, a release event for the corresponding resource is generated; when a barrier gate status changes from open to closed, a corresponding close event is generated. All of the above events are uniformly represented as a five-tuple structure: ; in, Indicates the event type, Indicates vehicle identification. Indicates resource identifier, It indicates the moment of occurrence on a unified timeline.

[0038] To ensure consistency across multiple records of the same physical event generated from different data sources, the event extraction module establishes an event matching window. Event records with a time difference less than a preset time threshold and whose resource identifier matches the vehicle identifier are aggregated. Let the observation results of the same event in the data source set S be... Then, a matching set is constructed using time consistency and space consistency rules. ;in, , , For reference, the time, resources, and vehicle identification of the event.

[0039] For the matching set The observations in the dataset are weighted according to the reliability of the data source. Calculate the confidence level q for this event, expressed as follows: ;in, This represents the set of valid data sources that provide observations of the event. This represents the reliability weight of the corresponding data source. The final generated discrete traffic event is represented as: And sort them according to the time order on a unified timeline to form a global discrete traffic event sequence: .

[0040] Through the above processing, continuous trajectory data and discrete device status data are uniformly converted into discrete traffic event sequences with time, space, resource correlation, and confidence level identifiers. This enables the subsequent event system modeling module to construct state transitions and analyze resource occupancy relationships on a unified event semantic layer, thereby providing a structured event input basis for safety specification modeling and permit control.

[0041] Furthermore, in the event system modeling module, the steps of constructing a discrete event system model based on discrete traffic events and establishing the occupancy relationship between vehicles and port resources include: Define the set of event types for discrete traffic events as an event alphabet; Construct a system state set based on the combined occupancy states of vehicles and resources; Construct state transition relationships based on changes in resource usage before and after the event; Establish a vehicle and resource occupancy mapping table for each state; When an event is triggered, update the corresponding state occupancy mapping table to indicate the state change of resources being occupied or released; A discrete event system model is formed, which includes a set of states, a set of events, and state transition relationships.

[0042] Specifically, the event system modeling module uses the discrete traffic event sequences output by the event extraction module. ; as input, where each event ; Includes event types Vehicle identification Resource Identifier Time of occurrence and confidence level indicator .

[0043] First, construct an event alphabet from all event types: The event alphabet includes entry events, departure events, release events, closure events, and other operational event types related to port traffic control. Next, the system state set is constructed. Let the vehicle set be... Port resources are aggregated as The system state is then represented by a combination of vehicle-resource occupancy relationships. For any given moment, the occupancy mapping function is defined as follows: ;in, For a set of states, This indicates that vehicle v occupies resource r in state x. System initial state. The occupancy mapping is determined by the initial event sequence.

[0044] Next, construct state transition relationships based on the impact of events on occupancy relationships. For any state... and events Define the state transition function: When the event type is an entry event When the state transition occurs, the corresponding occupancy update rule is: When the event type is "Leave Event" When the state transition occurs, the corresponding occupancy update rule is: When the event type is a release event or a close event, the state transition is used to update the available status identifier of the resource, but does not change the correspondence between the vehicle and the resource. The update rule is also implemented through a predefined state update function.

[0045] Based on this, the event system modeling module maintains a vehicle and resource occupancy mapping table for each state. Its data structure includes a vehicle identifier field, a resource identifier field, and an occupancy relationship flag, used to record the resource location of each vehicle in the current state, such as the road segment, intersection, gate, or work area entrance. As discrete traffic events are triggered sequentially over time, the system follows a state transition function. Update status sequentially: The corresponding occupancy mapping table is updated synchronously to form a complete state evolution sequence. Finally, the event system modeling module forms a discrete event system model. It contains a set of states. Event Alphabet State transition relationship and initial state It also displays the occupancy relationship between maintenance vehicles and port resources in each state.

[0046] Through the above modeling process, the original discrete traffic event sequence is transformed into a discrete event system structure with state transitions and resource occupancy relationships as its core. This enables the entry, stay, and departure processes of vehicles on various port resources to be uniformly expressed in the form of state evolution, providing a definite state space and transition basis for subsequent safety regulation constraints, controllable and observable event boundary identification, and permission control strategy generation.

[0047] Furthermore, in the safety specification modeling module, the steps for representing port traffic safety rules as a set of safety specifications consisting of event sequence constraints and resource mutual exclusion constraints include: Establish a resource mutual exclusion table for port sections, intersections, narrow passages, and work area entrances; Transform resource mutual exclusion relationships into constraints that do not allow simultaneous use of resources; Establish an event precedence table for rules involving the sequence of operations such as release, entry, inspection, and passage; Transform the event precedence relationship into an event sequence constraint; Resource mutual exclusion constraints and event sequence constraints are uniformly encoded into structured security specification entries; This forms a set of safety specifications containing multiple safety specification entries.

[0048] Specifically, the safety specification modeling module first assigns numbers and classifies various traffic resources based on the port road topology map and the work area layout map, forming a resource set. ; among which, each resource This corresponds to a road segment, an intersection, a narrow passage, or the entrance to a work area. Based on the spatial relationships between resources—such as intersections, overlaps, or shared access areas—a resource mutual exclusion table is established. ; among them, any pair Representing resources With resources It is not allowed to be occupied by different vehicles at the same time.

[0049] In a discrete event system model, a resource occupancy set is defined for any system state x. Each resource mutual exclusion constraint is then formalized as the following logical condition: This is used to describe a situation where mutually exclusive resources cannot be occupied simultaneously in any given state.

[0050] For safety rules involving work processes and traffic control sequences, the safety specification modeling module analyzes event sets. Establish an event prerequisite relationship table. For any rule "event" An event can only occur after it has happened. "Define the preceding relation pair" ;in, This represents the set of all event precedence relations. In the state space of a discrete event system, this precedence relation is represented as: if from the initial state... The event sequence up to the current state x has not yet appeared. Then the event Triggering is not allowed.

[0051] In formal expression, let... To reach the state Given a set of historical events, the event sequence constraint can be expressed as: The security specification modeling module encapsulates the aforementioned resource mutual exclusion constraints and event sequence constraints into structured security specification entries. Each security specification entry includes a constraint type identifier, the identifier of the resource or event involved, and the corresponding logical conditions. All security specification entries constitute a security specification set. ;in, For a set of mutually exclusive resource constraints, This is a set of constraints for the order of events.

[0052] By using the above modeling method, the spatial conflict relationships and operational timing relationships in port traffic management are uniformly mapped into a set of logical constraints that can be determined in the state space of a discrete event system. This enables subsequent controllable and observable event boundary identification, normative projection, and permission control processes to be processed based on a unified form of safety norms, thereby providing a clear structured rule basis for determining the legality of the state and the constraints of event triggering conditions during system operation.

[0053] Furthermore, in the controllable and observable event boundary identification module, the steps for classifying events in a discrete event system by controllability and observability include: Establish a mapping table between port control interfaces and event types; Events that can be triggered or prohibited through the control interface based on the corresponding relationship table are controllable events; The remaining events are marked as uncontrollable events; Based on the event confidence level and sensor coverage, events that can be reliably sensed are identified as observable events; The remaining events are marked as unobservable events; Create a joint classification table of events with controllability and observability categories.

[0054] Specifically, the controllable and observable event boundary identification module first establishes an interface model for the port's existing control devices, including gate controllers, intersection signal controllers, variable traffic restriction sign controllers, and dispatch command issuance terminals. For each control device, a set of event types that it can act upon is established. For example, event types such as gate opening, gate closing, intersection release phase switching, and road segment entry permit issuance are registered as events that can be directly triggered or suppressed by the control interface. This leads to the construction of an event-control interface correspondence table. ; in, I represents the set of events, and I represents the set of control interfaces. Indicates the ability to respond to events A set of control interfaces for applying triggering or disabling operations. For those satisfying... event types These are identified as controllable events and constitute a set of controllable events. The remaining event types are identified as uncontrollable events, forming a set of uncontrollable events. .

[0055] During the observability classification process, the module utilizes the confidence label q generated for each event by the event extraction module, and combines it with the coverage area set formed by the port sensor deployment. For any event If the resource r corresponding to the location where the event occurs is located within at least one sensing coverage area, and its confidence level meets a preset reliability condition. Then the event type This is identified as an observable event. Formal representation: ; in, For the set of observable events, This is the confidence threshold. Event types that do not meet the above conditions are marked as unobservable events, forming a set of unobservable events. .

[0056] After completing the controllability and observability classifications, the controllable and observable event boundary identification module generates a joint classification identifier for each event type: ; in, Indicates the controllability category, This indicates the observability category. The joint classification results of all event types constitute the event joint classification table, which is used by the subsequent normative projection module to filter the target event subset. .

[0057] Through the aforementioned boundary identification process, events in a discrete event system are clearly divided into a subset of events that can be intervened by the control interface and reliably perceived by the sensing system, and a subset of events that do not possess the corresponding attributes. This enables safety specifications to be mapped and constrained based on the actual controllable and observable range of the system during subsequent processing, thereby providing a definite event domain basis for the construction of executable safety specifications and the generation of permission control strategies.

[0058] Furthermore, in the specification projection module, the steps of mapping the set of safety specifications to a subset of events that simultaneously belong to the set of controllable events and the set of observable events to generate executable safety specifications include: Extract event types that simultaneously belong to both the set of controllable events and the set of observable events to form a subset of target events; Traverse the event sequence constraints and resource mutual exclusion constraints involved in the set of security specifications; Retain only the security specification entries that contain events from a subset of the target events; For safety specification entries that contain uncontrollable or unobservable events, establish a correspondence between them and proxy events in the target event subset; Based on the correspondence, replace the uncontrollable or unobservable events in the original safety specification entries with the corresponding proxy events; The replaced security specification entries are combined with the retained security specification entries to form an executable security specification set that contains only a subset of the target events.

[0059] Specifically, the specification projection module receives the set of security specifications output by the security specification modeling module. ;in, Represents a set of mutually exclusive resource constraints. Represents the set of events constrained by their order.

[0060] Simultaneously, it receives the event classification results output by the controllable and observable event boundary identification module, including the set of controllable events. With the set of observable events The standard projection module first constructs a subset of the target events: This target event subset is used to define the range of event types that are allowed to directly participate in constraint operations and permission decisions in subsequent security specifications.

[0061] Traversing the set of security specifications During the process, event domain analysis is performed on each safety specification item. For event sequence constraint items, if both its preceding and succeeding events belong to a subset of the target event, then... If the entry is not specified, it will be directly retained in the executable security specification set; if any event in the set does not belong to the set, it will be retained directly in the executable security specification set. If the entry involves an uncontrollable or unobservable event, then proxy mapping processing is required. For resource mutual exclusion constraint entries, if the resource occupancy status involved in the constraint is triggered or released only by events in the target event subset, then the entry is retained; if the resource status change involved is triggered by a non-target event, then the proxy mapping processing flow is also entered.

[0062] To implement proxy mapping, the standard projection module establishes a set of correspondences between uncontrollable or unobservable events and proxy events: ;in, Indicates the relationship with the original event A set of events that are equivalent or substitutable in terms of control semantics or state impact. The correspondence is established based on the state transition effect of events in a discrete event system model; that is, if two events cause the same resource consumption change or the same control precondition change in the state space, then a mapping relationship is established.

[0063] In the specific replacement process, for a line containing uncontrollable or unobservable events... The security specification entry will be replaced by the specification projection module with its corresponding proxy event set. And perform a structure-preserving transformation on the original constraints. For example, in event sequence constraints, ... Convert to This ensures that the constraint relationship is fully expressed within the subset space of the target events. Similarly, the triggering source of the state triggering condition in the resource mutual exclusion constraint is replaced according to the proxy event correspondence, so that the mutual exclusion relationship is completely transformed by... Event-driven in.

[0064] The replaced security specification entries are uniformly encoded with the directly retained security specification entries, forming an executable set of security specifications that contains only a subset of the target events: ; among them, each All with The events in the specification are the constraint objects, and the consistency with the original security specifications in terms of resource usage relationships and event sequence logic is maintained.

[0065] Through the above-mentioned normative projection and proxy replacement processing, the set of safety norms maintains a complete semantic expression of port traffic safety rules, while limiting it to a subset of events that are controllable and reliably observable in the event domain. This provides a consistent normative basis for the subsequent supervision and permission control module to perform state transition determination and permission set generation within a limited and executable event space.

[0066] Furthermore, in the supervision and permission control module, the steps for constructing a permission set for controllable events based on executable security specifications and a discrete event system model include: Obtain the mapping relationship between vehicles and resource occupancy corresponding to the current system state in the discrete event system model; Enumerate all controllable events in the current system state; For each controllable event, simulate its state transition result in the discrete event system model; Determine whether the state transition result violates any entry in the executable safety specification set; Add controllable events that do not cause violations of specification entries to the permission set; A set of controllable event permissions corresponding to the current system state is formed.

[0067] Specifically, the supervision and permission control module constructs a discrete event system model using the event system modeling module. ; and the set of executable safety specifications output by the standard projection module. As input, during system operation, the current system state is first determined based on the evolution of the real-time event sequence in the model. And read the mapping relationship between vehicles and port resource occupancy corresponding to this status. ,in, This indicates that vehicle v is currently occupying resource r.

[0068] In the current state x, the supervision and permission control module controls the set of controllable events. The function enumerates all controllable event types and constructs hypothetical triggering scenarios for each. For any controllable event... The subsequent state after the event is triggered is calculated using the state transition function in the discrete event system model: Based on the resource occupancy update rules corresponding to the event type, the resource occupancy mapping relationship in the subsequent state is obtained. Subsequently, the monitoring and authorization control module monitors the subsequent state. Perform a security specification consistency check. For resource mutual exclusion specification items, based on... Determine if mutually exclusive resource pairs exist. At the same time belong to In cases where events occur sequentially, the order of events is determined based on the state path history and the prerequisite relationships defined in the executable security specification. Whether an event sequence structure that violates the sequential constraint occurs later.

[0069] When the successor state If no violation condition of any executable security specification item is triggered in the above judgment, the supervision and permission control module will control the corresponding controllable event. Recorded as permitted events in the current state; when the subsequent state... If an event is inconsistent with any specification entry, it will not be included in the allowed scope. This results in a discrepancy with the current system state. The corresponding set of controllable event permissions: The permission set is stored in the form of an association between event identifiers and status identifiers. It is used to compare and generate control instructions one by one for gate release events, road segment entry events and intersection release events in the runtime verification and control execution module.

[0070] Through the above-mentioned process of constructing the permission set based on state transition simulation and standard consistency judgment, each controllable event has a clear state legality judgment result before actual triggering, thereby forming a state-by-state constraint basis for port vehicle traffic control behavior at the discrete event system model level.

[0071] Furthermore, in the runtime verification and control execution module, the steps for determining the conformity of real-time event sequences include: Receive discrete traffic events arriving in chronological order; Based on the classification results output by the controllable and observable event boundary identification module, discrete traffic events are mapped to a subset of target events; Construct a sequence of projected events based on a subset of the target events; Match the sequence of projected events with the set of executable security specifications one by one; Identify whether the current sequence of projected events satisfies the event sequence constraints and resource mutual exclusion constraints in the executable safety specification set; Generate the standard consistency judgment result.

[0072] In the runtime verification and control execution module, the steps for allowing or blocking gate release events, road segment entry events, and intersection release events based on the permission set include: Obtain the set of controllable events permitted under the corresponding system state before a controllable event is triggered; Determine if the controllable event to be triggered exists in the permission set; When a controllable event to be triggered exists in the permission set, an execution command is sent to the corresponding control interface; When the controllable event to be triggered does not exist in the permission set, a blocking command is sent to the corresponding control interface; At the same time as the blocking command is issued, the proxy event flow associated with the blocked event is triggered according to the proxy event correspondence established by the standard projection module. The execution results of the proxy event process are used as new discrete traffic events to be input into the event extraction module and the event system modeling module to update the subsequent system state.

[0073] Specifically, the runtime verification and control execution module uses the discrete traffic event sequence continuously output by the event extraction module. As input, each event This includes event type, vehicle identifier, resource identifier, occurrence time, and confidence level identifier. The module first filters event types based on the joint classification table provided by the controllable and observable event boundary identification module, retaining only the subset belonging to the target event. The event symbols are defined as follows: the remaining event symbols are ignored or replaced by their corresponding proxy event identifiers during projection. This constructs the projection event sequence. .

[0074] The runtime verification process is based on a sequence of projected events and a set of executable security specifications. Match each item individually. For resource mutual exclusion specifications, after a state update caused by an event, the module matches the resource occupancy set based on the current state. Determine if mutually exclusive resource pairs exist. At the same time belong to For event sequence-based specifications, the system determines whether the corresponding preceding event constraints are satisfied based on the order of events in the projected event sequence. If any specification entry is not true in the current projected event sequence and its corresponding state, a specification inconsistency flag is generated; if all specification entries are true, a specification consistency flag is generated.

[0075] During the control execution phase, before each controllable event is about to be triggered, the runtime verification and control execution module first reads the controllable event permission set generated by the supervision and permission control module based on the current system state x. and the event symbol to be triggered Compare with the license set. When When the module sends an execution command to the corresponding barrier gate controller, intersection signal controller, or road segment entry control interface, the event occurs at the physical level; when When this happens, the module sends a blocking command to the corresponding control interface, preventing the event from being executed at the physical level.

[0076] When an interruption occurs, the runtime verification and control execution module uses the proxy event mapping relationship established by the specification projection module. The system triggers proxy event flows that correspond to the blocked event in terms of state semantics, such as triggering alternative resource locking events, waiting for confirmation events, or delayed release events. After the proxy event completes execution at the control interface level, its execution result is re-encapsulated as a discrete traffic event and sent back to the event extraction module, which in turn updates the system state through the event system modeling module. .

[0077] Through the above runtime verification and control execution process, real-time traffic events undergo consistency verification between the projected event sequence and the executable safety specifications before entering the physical execution layer. In addition, the permission set is combined to make a permission or blocking decision on an event-by-event basis. Thus, a closed-loop execution link based on the discrete event system model, specification projection results and permission control strategy is formed during system operation.

[0078] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A port vehicle traffic management and monitoring system based on big data, characterized in that, include: The data acquisition module is used to acquire port vehicle positioning data, gate status data, intersection control data, and operation scheduling event data, and to perform time and spatial alignment on the data. The event extraction module is used to generate discrete traffic events based on the aligned data, according to preset resource boundaries and state determination rules, and to attach a confidence label to each discrete traffic event. The event system modeling module is used to construct a discrete event system model based on the discrete traffic events and establish the occupancy status relationship between vehicles and port resources. The safety specification modeling module is used to represent port traffic safety rules as a set of safety specifications consisting of event sequence constraints and resource mutual exclusion constraints. The controllable and observable event boundary identification module is used to classify the events in the discrete event system by controllability and observability, and obtain a set of controllable events, a set of uncontrollable events, a set of observable events, and a set of unobservable events. The specification projection module is used to map the set of security specifications to a subset of events that simultaneously belong to the set of controllable events and the set of observable events, thereby generating executable security specifications; The supervision and permission control module is used to construct a permission set for controllable events based on the executable security specification and the discrete event system model. The runtime verification and control execution module is used to perform standardization and consistency judgment on the real-time event sequence, and to allow or block the gate release event, road segment entry event and intersection release event according to the permission set.

2. The port vehicle traffic management and monitoring system based on big data as described in claim 1, characterized in that, In the data acquisition module, the steps of acquiring port vehicle positioning data, barrier gate status data, intersection control data, and operation scheduling event data, and performing time and spatial alignment on the data, include: Establish timestamp sequences for vehicle positioning data, barrier gate status data, intersection control data, and operation scheduling event data according to their data sources; Based on a preset time mapping relationship, each timestamp sequence is converted to a unified timeline; Perform coordinate transformation on data with different coordinate representations according to the port's unified coordinate system; The multi-source data, after time mapping and coordinate transformation, will be rearranged according to a unified time order. Generate an aligned data record set containing vehicle identifiers, resource identifiers, time information, and spatial location information.

3. The port vehicle traffic management safety monitoring system based on big data as described in claim 1, characterized in that, In the event extraction module, the step of generating discrete traffic events according to preset resource boundaries and state determination rules, and attaching a confidence level identifier to each discrete traffic event, includes: Based on the topological relationship between the aligned vehicle trajectory data and the port resource spatial boundary, the time when the vehicle enters and leaves the resource is determined. An entry event is generated when entry is determined, and a departure event is generated when departure is determined. Generate release and closure events based on the changes in the gate's status; For each event, record the event type, vehicle identifier, resource identifier, and time of occurrence; Perform consistent matching of similar events from different data sources; For each event, a corresponding confidence level is calculated and attached based on the consistency matching results; A discrete traffic event sequence is formed in chronological order.

4. The port vehicle traffic management safety monitoring system based on big data as described in claim 1, characterized in that, In the event system modeling module, the steps of constructing a discrete event system model based on the discrete traffic events and establishing the occupancy status relationship between vehicles and port resources include: The set of event types for the discrete traffic events is defined as an event alphabet; Construct a system state set based on the combined occupancy states of vehicles and resources; Construct state transition relationships based on changes in resource usage before and after the event; Establish a vehicle and resource occupancy mapping table for each state; When an event is triggered, update the corresponding state occupancy mapping table to indicate the state change of resources being occupied or released; A discrete event system model is formed, which includes a set of states, a set of events, and state transition relationships.

5. The port vehicle traffic management safety monitoring system based on big data according to claim 1, characterized in that, In the safety specification modeling module, the step of representing port traffic safety rules as a set of safety specifications consisting of event sequence constraints and resource mutual exclusion constraints includes: Establish a resource mutual exclusion table for port sections, intersections, narrow passages, and work area entrances; Transform resource mutual exclusion relationships into constraints that do not allow simultaneous use of resources; Establish an event precedence table for rules involving the sequence of operations such as release, entry, inspection, and passage; Transform the event precedence relationship into an event sequence constraint; The resource mutual exclusion constraints and event sequence constraints are uniformly encoded into structured security specification entries; This forms a set of safety specifications containing multiple safety specification entries.

6. The port vehicle traffic management safety monitoring system based on big data as described in claim 1, characterized in that, In the controllable and observable event boundary identification module, the steps of classifying events in the discrete event system by controllability and observability include: Establish a mapping table between port control interfaces and event types; According to the corresponding relationship table, events that can be triggered or prohibited through the control interface are controllable events; The remaining events are marked as uncontrollable events; Based on the event confidence level and sensor coverage, events that can be reliably sensed are identified as observable events; The remaining events are marked as unobservable events; Create a joint classification table of events with controllability and observability categories.

7. A port vehicle traffic management and monitoring system based on big data as described in claim 1, characterized in that, In the specification projection module, the step of mapping the set of security specifications to a subset of events that simultaneously belong to the set of controllable events and the set of observable events to generate executable security specifications includes: Extract event types that simultaneously belong to both the set of controllable events and the set of observable events to form a subset of target events; Traverse the event sequence constraints and resource mutual exclusion constraints involved in the set of security specifications; Retain only the security specification entries that contain events from a subset of the target events; For safety specification entries that contain uncontrollable or unobservable events, establish a correspondence between them and proxy events in the target event subset; Based on the aforementioned correspondence, uncontrollable or unobservable events in the original safety specification entries are replaced with corresponding proxy events; The replaced security specification entries are combined with the retained security specification entries to form an executable security specification set that contains only a subset of the target events.

8. A port vehicle traffic management and safety monitoring system based on big data as described in claim 1, characterized in that, In the supervision and permission control module, the step of constructing a permission set for controllable events based on the executable security specification and the discrete event system model includes: Obtain the mapping relationship between vehicles and resource occupancy corresponding to the current system state in the discrete event system model; Enumerate all controllable events under the current system state; For each controllable event, simulate its state transition result in the discrete event system model; Determine whether the state transition result violates any specification entry in the executable security specification set; Add controllable events that do not cause violations of specification entries to the permission set; A set of controllable event permissions corresponding to the current system state is formed.

9. A port vehicle traffic management and monitoring system based on big data as described in claim 1, characterized in that, In the runtime verification and control execution module, the step of performing a conformity check on the real-time event sequence includes: Receive discrete traffic events arriving in chronological order; Based on the classification results output by the controllable and observable event boundary recognition module, the discrete traffic events are mapped to a subset of target events; Construct a sequence of projected events based on a subset of the target events; The sequence of projection events is matched one by one with the set of executable security specifications; Identify whether the current sequence of projected events satisfies the event sequence constraints and resource mutual exclusion constraints in the executable security specification set; Generate the standard consistency judgment result.

10. A port vehicle traffic management and monitoring system based on big data as described in claim 1, characterized in that, In the runtime verification and control execution module, the step of allowing or blocking gate release events, road segment entry events, and intersection release events based on the permission set includes: Obtain the set of controllable events permitted under the corresponding system state before a controllable event is triggered; Determine whether the controllable event to be triggered exists in the permission set; When a controllable event to be triggered exists in the permission set, an execution command is sent to the corresponding control interface; When the controllable event to be triggered does not exist in the permission set, a blocking command is sent to the corresponding control interface; At the same time as the blocking command is issued, the proxy event flow associated with the blocked event is triggered according to the proxy event correspondence established by the standard projection module. The execution result of the proxy event process is used as a new discrete traffic event input to the event extraction module and the event system modeling module to update the subsequent system state.

Images