Railway construction whole process digitization collaborative management and control platform

Abstract

The application provides a railway construction whole-process digital collaborative management and control platform, and belongs to the field of construction safety, and comprises the following steps: acquiring construction plan data through a service end, and generating a construction task according to the construction plan data; when entering, acquiring a personnel recognition result in a video of a channel door camera, judging the personnel recognition result according to the construction task, and opening the channel door; after opening, acquiring positioning data of a mobile client and a wearable device and corresponding electronic fence information, and performing early warning according to the positioning data and the electronic fence information; when exiting, acquiring exit counting information and task end information of the mobile client, and performing task end recording. Through the above technical scheme, the multi-role whole-process collaborative safety construction degree in railway construction can be improved.

Description

Technical Field

[0001] This invention relates to the field of construction safety technology, and more specifically, to a digital collaborative management and control platform for the entire railway construction process. Background Technology

[0002] Construction on operational railway lines involves multiple professional trades, various roles, and a large number of mobile devices and fixed facilities, resulting in a complex working environment and high safety risks. For a long time, construction safety management has relied primarily on manual monitoring, intercom communication, and paper records, lacking a unified digital means to integrate personnel, vehicles, areas, and equipment into real-time monitoring and achieve efficient multi-role collaboration. The traditional manual approach is gradually revealing its limitations in terms of the timeliness of information transmission, the accuracy of early warning responses, the traceability of process records, and the smoothness of cross-role collaboration. Existing technologies struggle to achieve a fully digital, comprehensive closed loop, thus limiting the overall effectiveness of safety management. Summary of the Invention

[0003] In view of this, the present invention proposes a digital collaborative management and control platform for the entire railway construction process to solve the problems existing in the prior art.

[0004] To achieve the above objectives, this invention proposes a digital collaborative management and control platform for the entire railway construction process, comprising: The server and the mobile client that communicates with the server; The system obtains construction plan data from the server and generates construction tasks based on the data. Upon entry, it acquires personnel identification results from the video of the access gate camera, judges the personnel identification results based on the construction tasks, and opens the access gate. After opening, it acquires the location data of the mobile client and wearable device, as well as the corresponding electronic fence information, and issues warnings based on the location data and electronic fence information. Upon exit, it acquires exit inventory information and task completion information from the mobile client and records the task completion.

[0005] Optionally, the server performs an integrity check when obtaining construction plan data. The integrity check items include construction date, construction location, construction manager, and number of construction workers.

[0006] Optionally, upon entry, the server obtains video data from the access gate and identifies the video data to obtain personnel detection results and identity characteristics. Based on the personnel detection results and identity characteristics, the server compares the list of personnel in the construction task to obtain a matching result. The server then obtains an unlocking request from the mobile client. If the matching result is a match, the access gate is opened; otherwise, a retry instruction is transmitted to the mobile client.

[0007] Optionally, the server obtains the start request for electronic fence information from the mobile client, acquires the location data of the mobile client and wearable device in real time based on the start request, determines whether to start the electronic fence based on the number of location data, or forcibly starts the electronic fence through the mobile client; and triggers the early warning rule engine; the electronic fence information is obtained through construction tasks.

[0008] Optionally, on the server side, the warnings include warnings for people and vehicles in the avoidance zone, warnings for vehicles approaching when the geofence is not open, warnings for people and geofences, and warnings for vehicles approaching when the geofence is open.

[0009] Optionally, upon exiting the site, the server obtains the exit count information from the mobile client, compares the number of people exiting the site with the number of people entering the site for the construction task, marks the personnel who did not exit as abnormal, and obtains the task completion information.

[0010] Optionally, the server can record trajectory points of the positioning data during the construction process to obtain trajectory point data; and record the video and audio data of the passage door.

[0011] Optionally, data related to construction tasks can be recorded and statistically analyzed via the server.

[0012] Compared with the prior art, the beneficial effects of the present invention are as follows: This platform, through the collaborative operation of a web platform and an app, constructs an integrated digital management and control system covering the entire construction process. Compared to traditional manual management methods, the platform significantly improves the automation level of construction safety management and the efficiency of multi-role collaboration. The platform can collect and integrate multi-source data such as personnel location, locomotive operation, and equipment status in real time, automatically triggering tiered early warnings based on an intelligent rule engine, and simultaneously pushing warning information to all relevant roles, effectively compensating for the blind spots and delays of voice communication. Simultaneously, the platform connects construction plans, personnel binding, entry and exit records, electronic fence activation and deactivation, hazard reporting, trajectory playback, and video evidence collection into a complete data chain, making the entire construction process recordable, traceable, and analyzable, providing a reliable basis for post-event review and responsibility determination. Furthermore, the platform ensures data consistency and business continuity in complex scenarios through distributed transactions, message queues, and offline caching technologies, reducing the difficulty of on-site operation and maintenance. Overall, this platform significantly improves the safety, collaborative efficiency, and digital management level of railway operating line construction, and has good application value. Attached Figure Description

[0013] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings: Figure 1 This is a flowchart of the method in an embodiment of the present invention; Figure 2 This is a schematic diagram of the warning entries in an embodiment of the present invention; Figure 3 This is a schematic diagram of the early warning visualization in an embodiment of the present invention. Detailed Implementation

[0014] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0015] This embodiment proposes a digital collaborative management and control platform for the entire railway construction process, such as... Figure 1 As shown, the railway construction full-process digital collaborative management and control platform is a multi-role, full-process, intelligent safety management and control system for railway operating line construction. The platform consists of a web platform (server and management backend) and an APP (mobile client), covering business processes such as construction plan management, temporary task creation, entry inventory, construction process monitoring, early warning handling, exit inventory, trajectory backtracking, image evidence collection, and statistical analysis. It enables information exchange and business collaboration among six key roles: dispatchers, stations, construction managers, safety officers, station liaisons, and locomotive crew. The web platform, as the server, serves as the service and management backend, including the web interface, backend services, database, rule engine, and message queue. The APP, as the mobile client, is installed on mobile phones, handheld positioning terminals, or vehicle-mounted tablets. Construction personnel wear wearable devices as independent positioning terminals for location reporting and audible / visual early warning. The mobile client supports two deployment modes: separate smart terminals (Bluetooth + APP) and integrated handheld / vehicle-mounted terminals (serial port direct connection). Figure 1 As shown, the key processes implemented by the platform are as follows: I. Pre-construction preparation process The web platform proactively calls the open API of the railway construction planning and scheduling system via scheduled tasks to acquire construction plan data in an incremental synchronization manner. The synchronization process employs a "fetch first, merge later" strategy, maintaining a local table of plan version numbers and exchanging version numbers with the scheduling system during each synchronization. Only plans with changed version numbers are fetched. To prevent data loss due to network interruptions, the synchronization task supports breakpoint resumption. After fetching each batch of plans, an offset is committed, and upon restarting, the process continues from the last committed offset. Simultaneously, the synchronization service utilizes dual-machine hot standby; if the primary node fails, the backup node automatically takes over, using distributed locks to ensure that only one node executes the synchronization task at a time. For plans that fail to synchronize, the web platform stores them in a dead-letter queue, where a separate repair task periodically retryes them. Once the retry limit is exceeded, manual processing is initiated.

[0016] The web platform performs integrity checks on received data. If critical data is missing, an alert is generated and displayed on the homepage. The missing data criteria are: any one of the following four items—construction date, construction location, construction supervisor, or number of workers—will trigger an alert. Based on login account permissions, the web platform filters and displays a list of construction tasks within a corresponding range. Dispatch accounts can view key tasks across the entire line, while station accounts can only view tasks for their own station. Access control is based on the RBAC model, with user roles bound to an organizational structure tree.

[0017] When a temporary construction task is created, the management interface of the web platform encapsulates the form data into a JSON object and submits it to the web platform backend via an HTTPS POST request. The web platform backend first performs a construction time conflict detection: it queries whether a construction task with a status of "Pending Inventory" or "In Progress" already exists at the same construction site and within the same time period. If so, it returns a conflict warning. After passing the detection, the system generates a unique task number (using a specific prefix, date, and serial number) and initializes the task status to "Pending Inventory". The status transition of each construction task (Pending Inventory → Inventory → Entering → Under Construction → Exiting → Completed) is driven by a finite state machine. The state machine is stored as a status field and a version number in the database. Each status change uses optimistic locking: during an update, it checks whether the version number is consistent with the one read in; if they are inconsistent, the entire transaction is retried. Status change events trigger corresponding callback functions. The state machine also defines rules prohibiting illegal state transitions; any illegal transition request will be rejected and logged. Subsequently, the Web platform uses the WebSocket connection pool to find all online apps of related roles and pushes the task summary information to the apps of the construction supervisor, safety officer, and on-site liaison officer.

[0018] When a skylight is created, the web platform, in addition to saving basic information, also calls the section management module to verify whether the entered "operating section" is in the system's defined section list. Simultaneously, it performs time overlap detection: within the same section, if the time interval of the newly created skylight overlaps with an existing "active" skylight (compared to the nearest minute), the user is prompted to make corrections. After successful creation, the system caches the skylight information in a high-speed cache for quick retrieval during construction task filtering.

[0019] When the construction supervisor logs into the app, the app sends their username and password to the web platform's authentication server. The password is transmitted using asymmetric encryption. After successful authentication, the server returns a token containing the user ID, role, and permissions. The app then requests a list of tasks within a specific future timeframe. The web platform server, based on the current time and the supervisor's ID, filters from the database tasks whose construction dates fall within the specified range and whose status is either pending or completed. If there are multiple tasks, the app displays the task cards in ascending order of construction start time; if there is only one task, it automatically navigates to the task's details preview page.

[0020] During the inventory process, for each piece of information (access gate, safety protection point, electronic fence) confirmed or modified by the construction supervisor, the APP generates a change record object, temporarily stores it in the local database, and marks it as "pending synchronization." When the user clicks "Next" or "Inventory Complete," the APP packages all change records and reports them to the Web platform via the MQTT protocol. When multiple users concurrently modify the same task, the Web platform uses row-level locking to lock the task record at the start of the transaction, while using distributed locking to prevent concurrent modifications across nodes. The lock has a timeout period, which is automatically released after the timeout. The requesting party, upon receiving a lock conflict warning, uses exponential backoff and retry. After receiving the data, the Web platform verifies whether the changed data conforms to business rules (e.g., access gates must belong to the task's area; safety protection points must be within the vehicle avoidance zone; the number of polygon vertices in the electronic fence must not be less than the minimum value). After successful verification, the task association information is updated, and a confirmation message is returned. Implementation of personnel addition and terminal binding: When adding personnel, the APP obtains the personnel tree from the organizational structure interface, selects it, and generates a personnel record. Terminal binding involves three data tables: a device status table (updating status to "assigned"), a personnel-device association table (inserting associated records), and a task-device table (recording the devices used by tasks). To ensure consistency across these three tables, the web platform uses the TCC distributed transaction model. The process is as follows: Try phase: Reserve the device (change the device status to "Reserved" and set a timeout); Confirm phase: Confirm the binding (update the status to "assigned" and insert an associated record); Cancel phase: Rollback (release the device status). Unconfirmed reservations that time out are automatically released to prevent deadlocks. This transaction coordinator runs independently, does not rely on local database transactions, and supports cross-microservice calls. Additionally, the device binding operation checks whether the device is already occupied by another task. This check is implemented using a unique database index combined with the status field, ensuring that the same wearable device or handheld terminal can only be bound to one incomplete task at a time. After binding is complete, the web platform updates the personnel-device relationship table and changes the device status from "idle" to "assigned".

[0021] II. Construction Entry Procedure The on-site liaison officer triggers the entry command via the "Allow Entry" button in the app. After clicking, the web platform generates an entry command message, which is sent to the construction manager's app via WebSocket. Upon receiving the command, the construction manager's app automatically switches to the "Pending Entry" page and activates the video recognition control.

[0022] The video recognition system utilizes a collaborative approach between an app and a web platform. Cameras at the entrance push video streams to a streaming media server, which then pulls the stream via a low-latency protocol. Simultaneously, the web platform initiates an independent recognition service. Each frame of the image is sent to this service via a message queue. The recognition service loads the object detection model and outputs bounding boxes and identity features of individuals. The recognition results are returned to the web platform in list format, which compares them to the list of personnel. If the similarity between a person's facial feature vector and a pre-stored vector exceeds a threshold, a match is considered. Successfully matched individuals' IDs are recorded in the "Entry List" and pushed to the app in real time.

[0023] Afterwards, unlocking begins. When the Web platform receives the unlocking request from the APP, it first compares the number of people already identified with the number of people expected to be present. If they match, it directly calls the smart lock control interface to send the unlocking command. If they don't match, the Web platform returns a status code requiring secondary confirmation. The APP then displays a dialog box; after the user confirms, the Web platform sends the unlocking command again. The unlocking command sending uses a retry mechanism: if a successful response is not received from the lock within a specified time after the first send, it retryes a limited number of times, with the interval increasing each time. The lock's open / closed status is reported via a heartbeat mechanism, and the Web platform periodically updates the lock's status cache. After entry is complete, the APP switches its local state machine from "Entering" to "Under Construction" and begins periodically (adaptively adjusting based on device movement status) reporting its local location. Simultaneously, the Web platform activates all early warning rule engines for this task.

[0024] III. Construction Process Control Both the app and wearable devices have built-in location service modules, calculating the current location using a fusion positioning algorithm. During reporting, data first enters an edge message queue and is sent in batches to the web platform. Due to network fluctuations potentially leading to duplicate reporting of location data at the same time, the web platform uses "timestamp + device ID" as an idempotent key, writing it to a temporary cache with a set lifespan. If a request with the same idempotent key is received, success is returned directly without duplicate processing. Simultaneously, for multiple location data entries from the same device within a short period, the web platform employs a strategy of overwriting previous data with the latest entry, retaining only the most recent location for real-time push, but all raw data is written to a time-series database for trajectory playback. The location reporting interface supports batch submission, allowing devices to package and send multiple location points at once, reducing network overhead. After receiving the data, the web platform first stores it in a spatiotemporal index, then pushes the location to all apps subscribed to the location stream using a publish / subscribe model. Upon receiving the location data, the app calls the map SDK's update marker interface; if the marker already exists, it is moved; otherwise, it is added. Color Determination: Before rendering, the app uses ray casting to determine if each location point is within the polygon of the construction electronic fence. Points inside are rendered in green, and points outside are rendered in yellow. Aggregate Display: A spatial partitioning algorithm divides the map into multiple grids. When the number of marker points in each grid exceeds a threshold, an aggregation icon is displayed, with the number on the icon indicating the number of marker points within the grid. Clicking the aggregation icon allows the app to calculate the average latitude and longitude of each point within the grid, then zoom in on the map and expand to display detailed marker points.

[0025] The electronic fence is then activated: After the construction manager clicks "start," the app sends a start request. When the web platform receives the request, it needs to calculate the number of people currently within the fence. Since location reporting is asynchronous, the "last location" might be outdated. To address this, upon receiving the start request, the web platform proactively sends a location refresh command (via WebSocket or MQTT) to all relevant apps and wearable devices, requiring them to immediately report their current location and wait for a response within a limited time. Devices that do not respond within the timeout period use their most recent valid location. After all locations are collected, the fence entry is then checked. A total timeout is set for the entire waiting process to ensure no prolonged blocking. If the number of people is equal, the web platform changes the "fence status" field in the task status to "activated" and triggers the warning rule engine to switch rule sets (disabling the avoidance zone and unfenced vehicle rules, and enabling the rules for people and fences and fenced vehicle rules). If the number of people is unequal, the web platform returns a list of discrepancies, and the app highlights the current location of these people on the GIS (in a special style) and displays a pop-up notification. The construction manager can choose to force activation; in this case, the web platform ignores the number verification and directly activates the fence, but the forced activation operation is recorded in the logs.

[0026] Real-time early warnings are implemented during construction. To achieve efficient early warning judgment, the Web platform's rule engine is adapted based on the Rete algorithm. Facts such as personnel location, vehicle location, and fence boundaries are injected into the network. Each early warning rule is compiled into an Alpha node (single-condition matching) and a Beta node (multi-condition cross-matching). For example, the "Person and Passing Zone Early Warning" rule includes two conditions: the person's location is not within the passing zone, and the person's role is not a safety officer. When the location changes, only the relevant Alpha node is triggered, reducing the number of matches. Simultaneously, the rule engine uses incremental updates: when the personnel's location changes, only the memory of the node corresponding to that fact is updated, rather than rematching all rules. The rule engine runs in an independent thread pool, with each task allocated one engine instance. Instances are completely isolated to avoid mutual interference. Early warning pushes use message queues to decouple early warning generation and push execution. After an early warning is generated, the message is written to a specific topic. The push process retrieves messages from the topic and queries the corresponding terminal connection status based on the target role. For online apps, messages are sent directly via WebSocket and the app is waited for an ACK; for offline apps, messages are stored in an offline message table and retrieved the next time the user logs in. For wearable devices, push notifications are sent via UDP. Since UDP is unreliable, the device needs to respond with an acknowledgment. If no acknowledgment is received within a specified time, the push service will retry a limited number of times. All push results are written back to the alert log for subsequent tracking.

[0027] Due to GPS positioning drift, personnel may frequently enter and exit near the fence boundary, leading to frequent alert triggering. The rule engine introduces anti-jitter logic: an alert is only triggered when a person's location is consistently outside the fence multiple times. Simultaneously, a "buffer zone" extends outward from the fence boundary; personnel within this zone do not trigger alerts but are recorded as "approaching the boundary." An alert is only triggered when the person actually crosses the outer edge of the buffer zone. Furthermore, a "cooling-off period" is implemented after an alert is triggered; the same person will not generate repeated alerts for the same rule during this period, the duration of which depends on the alert level.

[0028] Data collection during construction: When a hazard is reported, the APP takes a picture using the camera in the construction scene, compresses the image to an appropriate size, and then combines it with text, location, and time to form form data, which is uploaded via HTTP POST. After storage on the web platform, the hazard record is associated with the task, triggering a "hazard report" event to notify the construction supervisor and station duty officer. The recording function uses the system's recording component to record in a specified format, with a maximum duration limit each time, and is uploaded upon completion. SOS alert implementation: When the interval between two consecutive button presses on the wearable device is less than a threshold, the device firmware generates an SOS data packet, which is sent to a specific interface on the web platform via the cellular module. The interface priority is set to the highest, and the data is directly written to a memory queue and processed by an independent thread. Upon receiving the packet, the web platform immediately locates the task and supervisor associated with the device and sends an "emergency pop-up" command via WebSocket. This command is of the emergency type. Upon receiving the packet, the APP, regardless of its current page, will launch a full-screen flashing red interface and loop the emergency voice message while continuously vibrating until the user clicks the "confirm" button. When the SOS is deactivated, the construction supervisor sends a deactivation command through the APP. The web platform records the deactivation time and broadcasts the cessation of the emergency status.

[0029] During construction, the app and wearable devices should continue to function even when the signal is weak in the construction area. The app has a built-in local database that caches essential data such as construction task information, personnel lists, and electronic fence boundaries. Wearable device location reporting uses a store-and-forward mode: location data is first written to the device's local storage, and then packaged and sent in batches after a certain number of data points have accumulated. If the transmission is successful, the cache is cleared; if it fails, the cache continues to be cached, with a capacity limit. Even without a network connection, the app can still view task information and record potential hazards (stored locally), which are automatically synchronized to the cloud once the network is restored. Synchronization employs a "timestamp priority" automatic conflict resolution strategy: the app's local data carries the last updated timestamp. The web platform receives the data and compares the timestamps; if the app's data is newer, it overwrites the web platform's data; otherwise, the app's data is discarded. For critical data such as task status, the web platform's records are used, and the app retrieves the latest status.

[0030] At the end of construction, the electronic fence is closed: When the construction supervisor clicks "close," the web platform recalculates the number of people remaining within the fence. If the number is zero, the electronic fence is closed directly, all warning rules dependent on the fence boundary are stopped, and the original warning rule set is switched back. If there are still people remaining, the web platform returns a list of those remaining, and the app pops up a window displaying their locations. Users can choose to force closure. In this case, the web platform records the forced closure operation, immediately disables the electronic fence's boundary monitoring function, and stops warning rules dependent on the fence boundary (such as "person and electronic fence," "electronic fence open, vehicle approaching"), but retains other warning rules not dependent on the fence boundary (such as "electronic fence not open, vehicle approaching"). Since people may still be in the danger zone, the system continues to push vehicle approach warnings. The task can end, but those who have not left the site will be marked as having left abnormally. The forced closure operation is recorded in detail in the log for later review.

[0031] The specific content of the aforementioned warning push notification is as follows: The early warning monitoring system employs an independent rule engine service. This service retrieves real-time location data from a message queue and reads task configurations (electronic fence boundaries, avoidance zone boundaries, early warning thresholds, etc.) from a cache. The rule engine uses a state machine pattern: each person-rule pair has a state instance that records the current early warning level and the deactivation timer. In four-way control communication, multiple commands (such as unlocking, activating the fence, and deactivating the early warning) may be sent concurrently, requiring adherence to causal relationships. The system assigns a logical clock to each task, and all messages are accompanied by this timestamp. The receiver (web platform or app) processes messages in order of timestamp; if a received timestamp is less than the maximum processed timestamp, it is discarded (indicating a delayed, older message). For scenarios requiring strict order (such as requiring the fence to be activated before it can be deactivated), the state machine records the preceding state; subsequent operations can only be executed if the preceding state is satisfied, otherwise an error is returned.

[0032] Person and Vehicle Avoidance Zone Warning: After receiving a person's location, the rule engine determines whether they are within the vehicle avoidance zone polygon. If the previous status was "inside the zone" and the current status is "outside the zone," a warning is triggered. If the previous status was "outside the zone" and the current status is also "outside the zone," the engine checks if the reset timer has reached zero. If not, it continues to wait; if it has reached zero, the warning is triggered again. When a warning is triggered, the rule engine constructs a warning message, writes it to the warning table, and sends it to the push service via a message queue. The push service, based on the person's task, searches for the APP or wearable device IDs of all relevant roles and calls their respective push channels.

[0033] When the electronic fence is not activated and a vehicle is approaching, the rules engine simultaneously maintains a vehicle location cache (storing the latest location by vehicle number). Upon receiving a person's location, the distance between the vehicle and the person is calculated. Distance calculation uses a spherical distance formula, with results accurate to the meter. When the distance exceeds a threshold, the corresponding level of warning is triggered. Note: Only the "entry" event is triggered, not the "departure" event. If all distances exceed the threshold plus the buffer value for a sustained period, the rules engine automatically clears the warning status for that person.

[0034] Person and electronic fence alerts: Similar to vehicle avoidance zones, but with different fence boundaries. Meanwhile, safety personnel are excluded from the rules, filtered by the rule engine through the role field. If a person returns inside the fence after an alert is triggered, the rule engine immediately cancels the alert and resets the timer; if the construction supervisor manually cancels it, the rule engine sets a timer that will not trigger again even if the person remains outside the fence during the timer period, and the detection restarts after the timer expires.

[0035] When an electronic fence is activated and a vehicle approaching, the rules engine simultaneously calculates the distance between the vehicle and the fence, as well as the distance between the safety officer and the vehicle. The distance between the vehicle and the fence is calculated using a point-to-polygon shortest distance algorithm (first calculating the distance from the point to each edge, then taking the minimum). When the distance exceeds a threshold, different text messages are pushed to different roles based on the current alert level and role matrix. The conditions for deactivation are: manual deactivation by the construction supervisor, and confirmation from the backend that all personnel have entered the safe zone (the safe zone is an independent polygon, usually located inside the fence). Upon receiving a manual deactivation request, the rules engine iterates through all personnel locations to determine if all are within the safe zone. If so, the alert is deactivated and a timer is started; otherwise, deactivation is rejected and a list of remaining personnel is returned.

[0036] Manual handling of early warnings: Records related to early warnings, such as... Figure 2 As shown, the early warning visualization content is as follows: Figure 3 As shown, station duty officers can click the "Process" button for a specific warning in the warning center or homepage pop-up window within the management interface of the web platform. A processing window will pop up displaying the warning content and related images or videos. Images are loaded using thumbnails; clicking on them allows viewing the original image. Videos are loaded using a streaming media protocol. Station duty officers select the processing result based on the on-site verification: if it's a false alarm, mark it as "False Alarm"; if the number of people at the passageway door is inconsistent, mark it as "Inconsistent Number of People"; if the uniform is not up to standard, mark it as "Inconsistent Uniformity"; if it's a perimeter intrusion, mark the specific type of intruder; if it's a foreign object intrusion, mark the specific type of foreign object. After clicking "Confirm," the warning status changes to "Processed," and the processing result is synchronized to the dispatch terminal.

[0037] IV. Construction Site Procedure The exit count is implemented similarly to the entry count, but in the reverse direction. After the construction supervisor clicks "Exit Count" in the app, the web platform activates exit mode and begins receiving exit recognition results from the access door cameras. When comparing the number of people leaving with the number entering, the web platform saves a snapshot of the final number of people at the time of entry. If the number of people leaving is insufficient, the web platform does not automatically prevent the task from ending, but instead provides the construction supervisor with a "forced end" option. Upon forced end, the web platform records the list of personnel who did not leave and marks the status of their wearable devices or handheld terminals as "abnormal departure." After the task is completed, these devices will enter a pending recycling state and cannot be immediately used for the next task.

[0038] Implementation of Order Cancellation Notification: After the construction supervisor clicks "End Task," the Web platform performs a series of cleanup tasks: stopping all warning rules, calculating the total task duration, generating a trajectory summary, archiving images and audio recordings, and releasing device binding relationships. At the end of the task, the system needs to ensure that all trajectory points, warning records, and image data have been completely archived. To this end, a verification task is designed: immediately after the task ends, a data list is generated, including the expected number of location points (estimated based on task duration and reporting frequency), the number of warnings, and the number of image files. Then, the actual stored data is scanned asynchronously, and differences are compared. If missing data is found, a supplementary data collection task is triggered: requesting supplementary location data for the missing period from the local cache of the APP or wearable device; if the device is powered off, it is retrieved from the cache of the edge node. All supplementary data is timestamped to ensure no duplication. Then, the message service is called to notify the station liaison officer via in-station messaging and APP push notifications. After receiving the notification, the station liaison officer clicks "Confirm Order Cancellation," and the Web platform updates the station's construction registration status.

[0039] V. Track Recording and Image Archiving When the web platform receives location data, in addition to real-time push notifications, it also writes the data to a time-series database. During writing, the data is partitioned by task ID and time, with each partition containing trajectory points within a fixed time range. When querying a trajectory, the web platform generates a corresponding query based on the time range, utilizing spatiotemporal indexes for acceleration. During trajectory playback, the web platform's management interface or app requests trajectory point data, and the web platform returns a standard-formatted geographic data set, with each feature containing a coordinate sequence and a timestamp sequence. The management interface or app uses a timeline plugin to drive the movement of marker points based on the timestamps. When the user drags the timeline, the requested time point may not have an accurate location record. The time-series location points returned by the web platform are typically spaced at fixed intervals; the management interface or app uses linear interpolation to calculate the intermediate position between two points. To improve visual smoothness, the management interface or app also applies spline interpolation to convert discrete points into continuous curves. For abrupt changes in the direction of movement, the interpolation algorithm detects the rate of change of velocity; if it exceeds a threshold, piecewise linear interpolation is used instead of a smooth curve to avoid unreasonable "penetration" phenomena.

[0040] The access gate camera pushes the stream via a streaming media protocol, while the web platform uses a multimedia framework to pull the stream and detect human bodies. When the human detection box stays in the center of the screen for more than a threshold time, it triggers a snapshot and recording. Snapping is done by calling a frame screenshot command, and recording is done by starting a subprocess and continuing for a fixed duration before stopping. The video files recorded by the access gate camera are large, and resuming interrupted uploads is supported when uploading to object storage. On the device side (camera edge node), the file is divided into blocks. After each block is successfully uploaded, its offset is recorded. If the upload is interrupted, it resumes from the maximum previously uploaded offset. Simultaneously, the video is transcoded and compressed before upload, using a more efficient encoding format to reduce file size while maintaining image quality. The transcoding task is completed on the edge computing node, without consuming cloud resources. The generated image and video files are first stored in a local temporary directory and then uploaded to object storage. After upload, a thumbnail is generated, an access URL is generated, and written to the task association table. When displayed in the web platform's management interface or app, it is directly loaded based on the URL, supporting anti-hotlinking signatures.

[0041] VI. Device Binding and Firmware Management The web platform maintains a device table containing fields such as device identifier, status (idle / assigned / faulty), current task identifier, and current user identifier. During binding, the web platform initiates a database transaction, first updating the device status to "assigned," and then inserting the associated record. If binding fails (e.g., the device has already been bound to someone else), the transaction rolls back and returns an error code. Unbinding occurs automatically after the task ends; the web platform uses a scheduled task to scan completed tasks and release their associated devices.

[0042] The web platform provides a firmware upload interface. Uploaded firmware files are saved to object storage, and the version number, device type, checksum, and release time are recorded in the database. The app requests the latest firmware version through periodic polling or manual user triggering. If a new version is available, the app displays a dialog box. After user confirmation, the app starts a background download service using a resume download protocol. After downloading, the app verifies the checksum and then calls different update APIs based on the firmware type. If a power outage or network interruption occurs during the firmware update process, the device may become unusable. To address this, a dual-partition update strategy is designed: device storage is divided into two partitions, A and B. The currently running partition is A, and the new firmware is written to partition B. After writing, the signature is verified. If successful, the boot flag is changed to B, and then the device restarts. If the new firmware fails to boot, the watchdog timer detects a boot timeout, automatically switches back to partition A, and reports the error. Simultaneously, the previous firmware version is retained in the cloud, supporting remote one-click rollback. Before downloading firmware, the app checks the device's battery level; if it is below a threshold, the update is prohibited, and a charging prompt is displayed.

[0043] VII. Statistical Analysis and Data Output At specific points in time, the web platform uses scheduled tasks to aggregate and calculate data from the previous stage, generating an intermediate result table. When users query, they directly access this intermediate result table, eliminating the need for real-time calculations of large amounts of raw data. If the time range selected by the user does not match the pre-aggregation granularity, the query will revert to the original data, but the query time span will be limited to a reasonable range. Report generation uses asynchronous tasks: after a user clicks to generate a report, the web platform creates an asynchronous task. Upon completion, the task stores the PDF file in object storage and notifies the user to download it via in-site message. PDF generation uses a template engine, converting an HTML-formatted report template into a PDF after populating it with data.

[0044] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A digital collaborative management and control platform for the entire railway construction process, characterized in that: include: The server and the mobile client that communicates with the server; The system obtains construction plan data from the server and generates construction tasks based on the data. Upon entry, it acquires personnel identification results from the video of the access gate camera, judges the personnel identification results based on the construction tasks, and opens the access gate. After opening, it acquires the location data of the mobile client and wearable device, as well as the corresponding electronic fence information, and issues warnings based on the location data and electronic fence information. Upon exit, it acquires exit inventory information and task completion information from the mobile client and records the task completion.

2. The platform according to claim 1, characterized in that, When the server obtains construction plan data, it performs an integrity check. The integrity check items include construction date, construction location, construction supervisor, and number of construction workers.

3. The platform according to claim 1, characterized in that, Upon entry, the server retrieves video data from the access gate and identifies the personnel to obtain their detection results and identity characteristics. Based on these results, the server compares the list of personnel in the construction task with the data to obtain a matching result. The server then retrieves an unlocking request from the mobile client. If the matching result is a match, the access gate is opened; otherwise, a retry instruction is sent to the mobile client.

4. The platform according to claim 1, characterized in that, The server obtains the start request for electronic fence information from the mobile client, acquires the location data of the mobile client and wearable device in real time based on the start request, determines whether to start the electronic fence based on the number of location data, or forcibly starts the electronic fence through the mobile client; and triggers the early warning rule engine; the electronic fence information is obtained through construction tasks.

5. The platform according to claim 1, characterized in that, On the server side, warnings include warnings for people and vehicles in the avoidance zone, warnings for vehicles approaching when the geofence is not open, warnings for people and geofences, and warnings for vehicles approaching when the geofence is open.

6. The platform according to claim 1, characterized in that, Upon exiting the site, the system obtains exit count information from the mobile client via the server, compares the number of people exiting the site with the number of people entering the site for the construction task, marks those who did not exit as abnormal, and obtains task completion information.

7. The platform according to claim 1, characterized in that, The server records trajectory points of the positioning data during the construction process to obtain trajectory point data; and records video and audio data of the passage door.

8. The platform according to claim 1, characterized in that, The server records and compiles data related to construction tasks.

Images