Urban rail transit intelligent scheduling method and system based on microservice and DDD layering

Abstract

This invention provides a method and system for intelligent scheduling of urban rail transit based on microservices and DDD layering, comprising: a data processing platform microservice that processes and stores data from multiple professional systems, calls an intelligent algorithm engine platform microservice to generate call results, and generates subscription events based on the call results; a contingency plan center microservice that, based on the subscription events, calls the intelligent algorithm engine platform microservice to generate call plans; a collaborative scheduling microservice that, based on the call plans, creates collaborative tasks and establishes dependencies between various professional tasks, and a planning scheduling microservice that sequentially assigns each professional task to its corresponding professional system; and a runtime monitoring microservice that monitors the status and visualizes it, feeding back the monitoring results to the collaborative scheduling microservice to determine whether scheduling adjustments are needed. This invention solves the problems of poor scalability, lagging data processing, and weak multi-professional collaboration in existing scheduling systems through a loosely coupled microservice architecture, dual-link data lake processing, and multi-model collaborative decision-making.

Description

Technical Field

[0001] This invention belongs to the field of urban rail transit technology, specifically, it relates to an intelligent scheduling method and system for urban rail transit based on microservices and DDD layering. Background Technology

[0002] With the continuous expansion of urban rail transit networks and the increasing passenger flow, dispatching and command systems face severe challenges such as the difficulty of multi-disciplinary collaboration, the lag in processing massive amounts of data, and insufficient intelligent decision-making capabilities. Traditional dispatching systems often adopt an independent construction model oriented towards a single discipline. Data is isolated and information is fragmented between various professional systems such as signaling, rolling stock, power supply, and passenger information, making it difficult to form a unified global dispatching view. When emergencies such as sudden large passenger flows or equipment failures occur, dispatchers need to communicate and coordinate with each professional system separately, resulting in low response efficiency and a high risk of decision-making bias due to information asymmetry.

[0003] In recent years, some intelligent dispatching technologies for rail transit have emerged in the industry. Patent document "An Intelligent Passenger Dispatch and Command System and Method for Urban Rail Transit" (CN109598453A) discloses an intelligent passenger dispatching and command system for urban rail transit. This system collects data from multiple subsystems through a central FEP (Front-End Processing Unit) and vehicle gateways, and the dispatching and command server performs correlation analysis and pre-plan triggering. However, it adopts a centralized monolithic architecture, resulting in poor system scalability and tight coupling between various professional subsystems, making independent evolution difficult.

[0004] The patent document "Intelligent Scheduling Optimization Method and System for Metro Lines Based on Real-time Data Analysis" (CN119130054A) discloses the introduction of multi-source data fusion technology to complete data cleaning and integration, and the combination of adaptive scheduling algorithm and intelligent prediction model to realize intelligent scheduling of metro lines. However, its focus is on the in-depth decomposition of the scheduling system architecture design. It proposes a loosely coupled microservice architecture mode of "platform + business" through DDD design, but fails to decouple data processing, algorithm reasoning and business collaboration in layers. This results in a single data processing link, limited intelligent decision-making capabilities, and an imperfect collaborative orchestration mechanism for multi-professional scheduling instructions.

[0005] Therefore, an intelligent scheduling scheme is needed that features high cohesion and low coupling in its architecture, balances real-time and full-scale data processing, and supports multi-model collaboration in decision-making. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the purpose of this invention is to provide an intelligent scheduling method and system for urban rail transit based on microservices and DDD layering.

[0007] The present invention provides an intelligent scheduling method for urban rail transit based on microservices and DDD layering, comprising multiple microservices, including: a data processing platform microservice, an intelligent algorithm engine platform microservice, a contingency plan center microservice, a collaborative scheduling microservice, a planned scheduling microservice, and an operation monitoring microservice.

[0008] The data processing platform microservice processes and stores data from multiple professional systems, calls the intelligent algorithm engine platform microservice to generate call results, and generates subscription events based on the call results. The contingency plan center microservice generates a call plan by invoking the intelligent algorithm engine platform microservice based on the received subscription events; The collaborative scheduling microservice creates collaborative tasks and establishes dependencies between various professional tasks according to the invocation plan. The planning scheduling microservice then distributes each professional task to the corresponding professional system in sequence. The operation monitoring microservice monitors the status of various professional tasks and displays the results visually. The monitoring results are then fed back to the collaborative scheduling microservice, which determines whether scheduling adjustments are needed.

[0009] Each microservice is bounded context based on DDD layering and communicates collaboratively through event-driven and / or API calls.

[0010] Preferably, the bounded context partitioning based on DDD layering includes performing domain modeling and hierarchical partitioning of the business functions of the scheduling system, obtaining the corresponding domain events, extracting aggregate roots and confirming entities, and partitioning the context based on well-defined boundaries.

[0011] The microservices are divided into an interface layer, an application layer, a domain layer, and an infrastructure layer.

[0012] The domain layer includes an alarm rule aggregation root, a configured rule deduplication mechanism, and performs hash calculations on rule conditions and thresholds to determine whether there are duplicate rules under the same conditions.

[0013] Preferably, the data processing platform microservices include a time-series library and a data lake, and adopt a dual-link processing architecture with real-time links and batch links running in parallel.

[0014] The time-series library stores short-term, hot data, while the data lake stores all data.

[0015] The full data includes long-term warm and cold data and short-term data that requires preprocessing.

[0016] The time-series database and the data lake achieve collaboration through a state coordination mechanism for redundant data.

[0017] The state coordination mechanism includes: subscribing to newly added or changed data in the previous time window from the time series library according to preset time parameters, using a streaming synchronization engine to convert the exported data into a columnar format file and write it to a specified location in the data lake, and registering the synchronization job as a data lineage.

[0018] Preferably, the time-series library provides fast response to data with higher priority, while the data lake processes or batches data with lower priority.

[0019] Use StarRocks' federated query portal to query data in the time-series database and data lake.

[0020] Preferably, the intelligent algorithm engine platform microservices are deployed using at least two of the following: a time-series prediction model, a large language model, and a graph neural network model.

[0021] The time-series prediction model is used to perform passenger flow prediction, the large language model is used to generate natural language text of the scheduling plan, and the graph neural network model is used to perform impact analysis on the scheduling instructions associated with the scheduling plan.

[0022] A smart scheduling method for urban rail transit based on microservices and DDD layering, provided by the present invention, includes: Step S1: Process and store the collected multi-disciplinary system data through the data processing platform microservices; Step S2: Call the intelligent algorithm engine platform microservice to generate the call result, and generate subscription events based on the call result; Step S3: The contingency plan center microservice calls the intelligent algorithm engine platform microservice to generate a call contingency plan based on the subscribed events; Step S4: The collaborative scheduling microservice receives the call plan, creates collaborative tasks, and establishes dependencies between various professional tasks; Step S5: The planning and scheduling microservices sequentially assign professional tasks to the corresponding professional systems, and each professional system executes the assigned professional tasks. The monitoring microservice monitors the status of each professional task and feeds back the monitoring results to the collaborative scheduling microservice, which then determines whether scheduling adjustments are needed.

[0023] Preferably, the data processing platform microservice adopts a dual-link processing architecture with parallel real-time and batch links to process data from multiple professional systems, forming a dual-storage architecture of time-series database and data lake.

[0024] The time-series database and the data lake achieve state coordination through a synchronization mechanism.

[0025] The synchronization mechanism includes: subscribing to newly added or changed data in the previous time window from the time series library according to preset time parameters, using a streaming synchronization engine to convert the exported data into columnar format and write it into the data lake, and registering the synchronization job as a data lineage.

[0026] Preferably, the contingency plan center microservice receives summary information from the subscribed event and requests detailed feature data corresponding to the subscribed event from the data processing platform microservice via API call.

[0027] Preferably, the planning and scheduling microservice orchestrates the dependencies and execution order of various professional tasks through a workflow engine.

[0028] The dependencies include: power supply adjustment tasks are executed before train speed-up tasks and train preparation and commissioning tasks; information dissemination tasks are executed in parallel with other tasks; and station guidance signal adjustment tasks are executed after the information dissemination tasks are completed.

[0029] Preferably, the microservice generation and invocation plan of the intelligent algorithm engine platform includes: Use a rule engine or time series model to make an initial judgment on the calling scenario and obtain the event type and urgency level; The large language model is used to integrate the preliminary judgment results and related data to generate natural language text for invoking the contingency plan; A graph neural network model was used to perform an impact analysis on the scheduling instructions associated with the invoke plan.

[0030] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention adopts the domain-driven design (DDD) layering concept to construct a loosely coupled microservice architecture of "platform + business", decoupling multi-professional collaborative scheduling business such as signal, vehicle, power, and information, strengthening the cohesion of data processing and algorithm reasoning microservices, and improving system scalability and maintainability.

[0031] 2. This invention achieves automated orchestration and closed-loop processing of multi-professional scheduling tasks through a collaborative mechanism that combines event-driven and API calls. The workflow engine uniformly orchestrates the execution order and dependencies of professional tasks such as power supply, vehicles, signals, and information dissemination, ensuring the real-time performance and coordination of scheduling instructions.

[0032] 3. This invention constructs a dual-link data processing and multi-model intelligent decision-making system. Real-time data is accessed to the time series database at millisecond level to ensure status monitoring. Full data is fed into the lake to support complex feature calculation and offline analysis. It also integrates time series prediction, large language model and graph neural network to realize intelligent scheduling decision-making from passenger flow prediction to plan generation and impact analysis. Attached Figure Description

[0033] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of an intelligent dispatching system architecture for urban rail transit based on microservices and DDD layering; Figure 2 This is a schematic diagram of the system microservice dependencies in an embodiment of the present invention; Figure 3 This is a schematic diagram of the timing of passenger flow prediction alarm events in an embodiment of the present invention; Figure 4 This is a schematic diagram of the domain modeling and hierarchical division of the scheduling system in an embodiment of the present invention; Figure 5 This is a schematic diagram of domain events in the scheduling system of this invention embodiment; Figure 6 This is a schematic diagram of the service aggregation root of the scheduling system in an embodiment of the present invention; Figure 7 This is a schematic diagram of the bounded context of the scheduling system in an embodiment of the present invention. Detailed Implementation

[0034] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0035] This invention provides an intelligent dispatching system for urban rail transit based on microservices and DDD layering. It simultaneously realizes functions such as status monitoring of multiple professional systems and equipment, passenger flow monitoring and prediction, comprehensive evaluation of system operation big data, train operation plan management, intelligent dispatching plan for power supply system, intelligent dispatching plan for vehicle / station information notification system, intelligent dispatching plan for vehicle (traction / braking) system, intelligent dispatching plan for signaling system, emergency dispatching, user management, and information release / notification. It adopts Docker combined with Kubernetes to achieve server virtualization, efficient resource management and automated deployment.

[0036] The business functions of the scheduling system are modeled and hierarchically divided, and the corresponding domain events are obtained; aggregate roots are extracted and entities are confirmed; bounded contexts are divided; and the partitioning results of loosely coupled microservices can be obtained based on the contexts with clear boundaries.

[0037] The dispatching system has microservices for data integration, contingency planning center, operation monitoring, passenger flow assessment, planning and dispatching, collaborative dispatching, data processing platform, intelligent algorithm engine platform, and basic platform.

[0038] To strengthen the cohesion of each microservice, taking the data processing platform microservice as an example, such as... Figure 4 As shown, based on DDD, it is further layered into interface layer, application layer, domain layer and infrastructure layer.

[0039] The interface layer handles the technical adaptation of external input / output, but does not include business logic. It includes external RESTful APIs, event publishing, message subscription, and adapters.

[0040] In more preferred embodiments, the external APIs of the data processing platform microservices include: The rule management API provides functions such as creating / updating alarm and alert rules, disabling / enabling rules, and querying rule lists. The data query API provides functions such as real-time data query from time-series databases, historical data query from lake warehouses, data lineage query to obtain data sources and dependencies, data quality report query to obtain data quality assessment results, feature data query to provide feature calculation services, and data snapshot query. The pipeline management API provides functions such as creating / starting / stopping pipelines, monitoring pipeline status, updating pipeline configuration, querying / deleting pipeline lists, and compression operations. The Feature Management API provides functions such as registering feature definitions, querying feature values, managing feature versions, verifying feature quality, creating feature snapshots, and time travel queries.

[0041] The event publishing of the data processing platform microservices includes: Alarms / warnings are issued for incidents involving abnormal passenger flow, equipment malfunctions, data quality issues, and system malfunctions. Data event releases include data readiness, feature readiness, quality assessment, pipeline status updates, snapshot creation time, compression completion events, etc. Iceberg table change events include changes to the release mode, updates to the release partition specification, and rollback of release snapshots.

[0042] The message subscription of the microservices in the data processing platform includes: Raw data subscription: Subscribing to business interface data from different professional systems; Command subscription, including subscription to pipeline control commands, rule update commands, feature calculation commands, compression operation commands, data quality check commands, etc. System event subscriptions include system configuration updates, service status changes, (system) resource alerts, table maintenance events, etc.

[0043] The adapters for the microservices of the data processing platform include: The time-series database adapter provides functions such as writing, querying, data transformation, and connection pool management; The Iceberg Data Lake Adapter is compatible with Apache Iceberg operations, such as creating / querying Iceberg tables, managing snapshots, and time travel queries. Parquet file adapter, adapted for Parquet columnar storage, such as reading and writing Parquet files; The StarRocks adapter adapts to StarRocks analytics queries, such as creating / refreshing materialized views and managing table indexes. The stream processing engine adapter provides functions such as submitting Flink stream processing jobs and managing Flink state checkpoint configurators; The rule engine adapter provides adaptation to the Drools rule engine: performing rule matching, dynamically compiling rules, and managing rule facts.

[0044] The application layer focuses on business process orchestration, rather than business rule implementation. Core processes include: Streaming data processing flow: sequentially through data reception, feature calculation, rule matching, and finally alarm generation; Data pipeline management process: sequentially goes through verification and configuration, pipeline creation, startup and operation, and finally status monitoring; Feature calculation process: It sequentially goes through feature definition, data preparation, calculation execution, result storage, and finally completes service publication; Alarm / warning generation process: The process involves data consumption, rule matching, alarm / warning generation, level assessment, and finally event release. Quality monitoring process: The process involves data inspection, quality assessment, and problem recording, culminating in a quality report. Data lake management process: sequentially involves creating Iceberg tables, appending data, compressing files, and finally cleaning up snapshots; The query performance optimization process involves analyzing query patterns, loading hot data into MIO, creating materialized views, and finally adjusting the indexes.

[0045] The domain layer encapsulates core business logic and rules, does not depend on other layers, accumulates business domain knowledge, and maintains stability. Specifically, it includes: The core business rules of the data pipeline aggregation root include: complete configuration before activation, no configuration updates during operation, data source availability, data processing latency not exceeding thresholds, ACID transactions guaranteed for Iceberg table writes, schema definition compliance for Parquet file writes, and minimum data quality standards.

[0046] The alarm / early warning rule aggregation root has core business rules including: it must contain a complete conditional expression, the rule level must be within the valid range, there cannot be duplicate rules under the same conditions, the rule must pass a syntax check before it is enabled, and the rule must have a clear owner (professional system), etc.

[0047] The core business rules for defining feature aggregate roots include: they must contain a complete description of the data source; the computational logic must be executable; they must conform to semantic versioning specifications; they must have a clear business meaning; updates must be backward compatible; feature storage must support time travel queries; and feature data must support MIO acceleration.

[0048] The infrastructure layer implements the technical details and supports the technical requirements of other layers. Specifically, the infrastructure layer of the data processing platform microservices includes: The storage layer includes TDengine for high-concurrency real-time data writing and fast querying; MinIO stores all data (including raw data, Iceberg metadata, metadata managed by raw data, manifest lists, manifest files, data warehouse data, feature data, and time-series JSON) in Parquet columnar file format objects, and uses Iceberg data lake technology to implement ACID transactions; StarRocks implements a "cold-warm-hot" tiered storage for accelerated analysis queries and result caching.

[0049] The computation layer consists of Spark for batch processing and offline feature computation, and Flink for real-time data computation.

[0050] The scheduling layer uses Airflow to schedule "stream processing" and "batch processing" workflows.

[0051] The service layer uses the Kafka message middleware.

[0052] The monitoring layer uses Prometheus (metrics), ELK (logs), Grafana (visualization), and ZipKin Slueth (tracing).

[0053] The system deployment architecture diagram is as follows Figure 4For example, when a client makes a business request to the backend, the load balancer (Nginx) first forwards the traffic based on the current load of the API gateway. The API gateway cluster, leveraging Nacos's dynamic service discovery, then implements API-level routing and control according to different protocols, requesting business processing from the application server cluster. During the data flow, Sentinel focuses on rate limiting and circuit breaking to ensure the stability of the entire distributed system.

[0054] Taking the intelligent algorithm engine platform microservice as an example, DDD layering is used for similar construction.

[0055] Specifically, in the interface layer, the external APIs include: The Model Inference API provides functions such as single data inference, batch data inference, streaming inference, asynchronous inference, and inference status query; the Feature Service API provides functions such as extraction, verification, transformation, caching, and metadata; the Model Management API provides functions such as registration, version management, status monitoring, and performance evaluation; and the Service Health API provides functions such as service health check, model health check, resource usage status, and service metric query.

[0056] Event releases include: model events, involving model registration, model deployment, model anomalies, model shutdown, etc.; inference events, involving start, completion, anomalies, performance metrics, etc.; and evaluation events, involving start, results, performance alerts, data drift, etc.

[0057] Message subscriptions include: inference requests, such as contingency plan generation requests, real-time prediction requests, batch prediction requests, and model evaluation requests; feature data, such as real-time feature streams, batch feature sets, feature update notifications, and feature quality reports; and system commands, such as model deployment, model switching, service scaling, and resource allocation.

[0058] The adapter includes: a model service framework using Triton Interface Server; a feature store providing real-time feature query, batch feature query, and feature caching functions; a service mesh providing circuit breaking and degradation, and tracing functions; and monitoring providing model performance monitoring, resource usage monitoring, service health monitoring, and business metric monitoring.

[0059] The core business processes at the application layer include: Model management process: model registration, version control, service deployment, health check, and traffic management.

[0060] Model inference process: request reception, feature processing, model invocation, result processing, and response return.

[0061] Feature service process: input data, feature extraction, feature verification, feature transformation, feature output.

[0062] Model evaluation process: evaluation request, data preparation, model testing, indicator calculation, and report generation.

[0063] The domain layer includes: The core business rules of the model aggregation root include: registration must be verified; the version must conform to the semantic versioning specification; performance testing must be passed before deployment; the service must be healthy to receive requests; there must be clear input and output specifications; version specifications must be evaluated and updated regularly; inference requests must conform to the input pattern; and the model must be re-evaluated regularly.

[0064] The core business rules of the model service endpoint aggregation root include: the endpoint must be bound to a valid model version; it must pass a health check before it can be enabled; concurrent requests cannot exceed the capacity limit; endpoints that fail must be automatically restarted or switched over; and monitoring and alarm configurations are required.

[0065] The infrastructure layer includes: Multi-model database storage uses MySQL to store runtime data and rule features, Neo4j to store scheduling knowledge graphs, and Milvus to store augmented vector data; for models, it includes a rule engine, LLM, GNN, and time series models; for model inference services, it uses Triton Interface Server for unified management and efficient service of multiple models; for workflow orchestration and scheduling, it uses Apache Airflow for complex inference pipeline tasks involving multi-model collaboration; for resource management and monitoring, it uses Prometheus (metrics), ELK (logs), and Grafana (visualization).

[0066] Taking the microservices of the intelligent algorithm engine platform as an example, DDD layering is constructed using the same approach. Specifically: The interface layer includes the following external APIs: The Emergency Task API provides functions such as creating emergency tasks (creating collaborative tasks based on subscribed events and levels), querying task details, updating task status, assigning specialized tasks, querying task lists, obtaining task timelines, and task statistical analysis. The Collaborative Communication API provides functions such as sending collaborative messages, creating collaborative sessions, file sharing, querying message history, managing session members, controlling session status, and broadcasting system notifications. The Post-Event Analysis API provides functions such as generating handling reports, analyzing collaborative efficiency, conducting drill debriefings, querying historical reports, exporting analysis data, updating the knowledge base, and generating optimization suggestions. The Specialized Task Coordination API provides functions such as creating specialized tasks, querying task status, updating task progress, handling task exceptions, coordinating task dependencies, assigning execution resources, and accepting task results.

[0067] Event announcements include: emergency task creation, status changes, and completion of professional tasks.

[0068] Event subscriptions include: emergency alerts, dispatch plans, and updates for specialized tasks.

[0069] The core business processes at the application layer include: Emergency coordination process: incident reception, assessment and classification, task creation, professional assignment, execution monitoring, and result summarization.

[0070] Collaborative communication process: session creation, member management, message exchange, file sharing, state synchronization, and session archiving.

[0071] Post-event analysis process: data collection, process reproduction, effect evaluation, problem analysis, improvement suggestions, and knowledge accumulation.

[0072] Task coordination process: task decomposition, dependency analysis, resource allocation, progress tracking, exception handling, and result acceptance.

[0073] The domain layer includes: The core business rules of the emergency task aggregation root include: tasks must be based on valid event triggers; task levels must match the severity of the event; there must be a clear owner (professional system); task state transitions must conform to the lifecycle; tasks must contain complete handling requirements; and task timeouts must be automatically escalated or alerted.

[0074] The core business rules of the collaborative session aggregation root include: sessions must be associated with specific emergency tasks; session participants must have the corresponding permissions; session messages must record the complete context; session files must be security verified; session timeouts must be automatically closed or notified; and session content must be traceable and auditable.

[0075] The core business rules of the professional task aggregation root include: professional tasks must belong to emergency tasks; tasks must be assigned to specific professional systems; task execution must meet prerequisite dependencies; task results must be verified and confirmed; task timeouts must trigger retries or upgrades; and task exceptions must be recorded and handled.

[0076] The infrastructure layer includes: The Camunda workflow engine is responsible for collaborative process orchestration, state machine management, and process monitoring; the business database uses MySQL to store only the structured data generated within the microservices; and the cache uses Redis to store session state and hot data to accelerate data queries to the data processing platform microservices.

[0077] Instead of focusing on how to implement scheduling, this approach leverages DDD (Design for Decoupling) to achieve internal decoupling. It adopts a loosely coupled microservice architecture pattern of "platform + business," strengthening the cohesion of microservices such as data processing and algorithm inference. By combining event-driven and API calls, it creates an architecture where "data," "algorithm," and "business" support each other. This solves the common problems in current intelligent scheduling systems, such as low data processing efficiency, insufficient intelligence in intelligent services, and lack of coordination in scheduling plans.

[0078] Top-level domain modeling and context microservice mapping Figure 2 For example, each microservice performs its own function and is invoked on demand, supporting the flexible expansion and continuous evolution of multi-professional collaborative scheduling functions. Its continuous evolution capability provides strong scalability for subsequent optimization, and the containerized deployment method also provides technical support for subsequent system cloud migration.

[0079] This invention also provides an intelligent scheduling method for urban rail transit based on microservices and DDD layering, so as to... Figure 1 For example, by using Domain-Driven Design (DDD) layering, the collaborative scheduling business domains of multiple disciplines such as signaling, vehicles, power, and information are decoupled, supporting unified orchestration and closed-loop linkage of cross-disciplinary tasks. Adopting a "platform + business" architecture, the cohesion of microservices such as data processing and algorithm inference is strengthened to address the problems of poor scalability, lagging data processing, weak multi-disciplinary collaboration, low intelligence level, and severe inter-layer coupling in existing scheduling systems, achieving simultaneous improvement in the real-time performance, accuracy, scalability, and collaboration of intelligent scheduling decisions. The methods include: Step S1: Process and store the collected multi-disciplinary system data through the data processing platform microservices; Step S2: Call the intelligent algorithm engine platform microservice to generate the call result, and generate subscription events based on the call result; Step S3: The contingency plan center microservice calls the intelligent algorithm engine platform microservice to generate a call contingency plan based on the subscribed events; Step S4: The collaborative scheduling microservice receives the call plan, creates collaborative tasks, and establishes dependencies between various professional tasks; Step S5: The planning and scheduling microservices sequentially assign professional tasks to the corresponding professional systems, and each professional system executes the assigned professional tasks. The monitoring microservice monitors the status of each professional task and feeds back the monitoring results to the collaborative scheduling microservice, which then determines whether scheduling adjustments are needed.

[0080] In more preferred embodiments, the data processing platform microservices adopt a dual-link processing architecture with parallel real-time and batch links to process data from multiple professional systems, forming a dual-storage architecture of time-series database and data lake.

[0081] The time-series database and the data lake achieve state coordination through a synchronization mechanism. The synchronization mechanism includes: subscribing to newly added or changed data within the previous time window from the time-series database according to preset time parameters, using a streaming synchronization engine to convert the exported data into columnar format and write it to the data lake, and registering the synchronization job as a data lineage.

[0082] The contingency plan center microservice receives summary information from subscribed events and requests detailed feature data corresponding to the subscribed events from the data processing platform microservice via API calls.

[0083] The planning and scheduling microservice orchestrates the dependencies and execution order of various professional tasks through a workflow engine.

[0084] The dependencies include: power supply adjustment tasks are executed before train speed-up tasks and train preparation and commissioning tasks; information dissemination tasks are executed in parallel with other tasks; and station guidance signal adjustment tasks are executed after the information dissemination tasks are completed.

[0085] The intelligent algorithm engine platform microservice generation and invocation plan includes: Use a rule engine or time series model to make an initial judgment on the calling scenario and obtain the event type and urgency level; The large language model is used to integrate the preliminary judgment results and related data to generate natural language text for invoking the contingency plan; A graph neural network model was used to perform an impact analysis on the scheduling instructions associated with the invoke plan.

[0086] Specifically, with Figure 3 For example, when a coordinated scheduling event (such as an anticipated large passenger flow event) is triggered, involving the signaling system, vehicle system, vehicle / station information notification system, and power supply system scheduling, the process includes: Step S1: Data integration microservices.

[0087] Data from external systems (AFC, video, mobile signaling, Wi-Fi) is collected through a data acquisition gateway. After the custom protocol adapter completes the protocol parsing, the raw data is published to Kafka, and Kafka performs data persistence to ensure that the data is not lost.

[0088] Step S2: Data processing platform microservices.

[0089] Data access uses a unified entry point and data bus, with raw data subscribed to by Kafka consumers. However, subsequent real-time data streams employ a dual-link parallel processing architecture. Data used for real-time status monitoring and real-time alarms (alarms directly reported by professional systems) will be directly written to the time-series database after simple data format conversion or filtering, ensuring millisecond-level status monitoring queries.

[0090] Full data undergoes batch / stream processing (Flink / Spark) for more complex ETL, window aggregation, and feature computation to support real-time anomaly detection (such as passenger flow characteristics data like entry and exit volume, growth rate, congestion, trends, and year-on-year comparisons) and offline trend statistics (long-term passenger flow trends). The processed data is then written to MinIO + Apache Iceberg (Parquet format) as the core data lake for the scheduling system. StarRocks will serve as a unified query acceleration layer, providing high-performance queries of full historical data for other microservices.

[0091] When a condition is triggered (primarily by timed triggering, but alternatively by event triggering or external command triggering), the service will proactively call the model inference API to perform passenger flow prediction inference services.

[0092] Specifically, in the dual-storage architecture of time series database and data lake, the time series database is used to store short-term, hot data, and has ultra-low latency for writing and querying; the data lake is used to store all data, including long-term warm and cold data as well as some short-term data that needs to be preprocessed, and has analytical flexibility and open ecosystem.

[0093] To fully leverage the performance of the aforementioned architecture across different scenarios, the time-series library and data lake do not need to compromise with each other. Instead, they achieve collaboration through redundant data state coordination and eventual consistency mechanisms, ensuring real-time scheduling. Specific collaboration methods include: Regarding the synchronization mechanism, based on the preset time parameters, the system subscribes to the data added or changed within the previous time window from the time series library, and uses the Flink streaming synchronization engine to execute the synchronization job in a way that minimizes latency. The exported data is converted into a columnar format (Parquet) file and written to a specified location in the data lake (MIO). The synchronization job from the time series library to the data lake is registered as a data lineage to support data traceability.

[0094] Data is assigned a pre-defined priority. High-priority data is processed quickly using a time-series library, achieving millisecond-level processing cycles to ensure real-time monitoring. Low-priority data is processed via a data lake for either stream processing (net real-time) or batch processing (longer processing time). Stream processing (Spark) focuses on data preprocessing, while batch processing (Flink) focuses on batch statistics and aggregation calculations.

[0095] In terms of query collaboration, StarRocks' federated query capabilities are used as a unified query entry point, with both the time-series database and the data lake serving as metadata sources, and query services are provided to the outside world through a unified data access view.

[0096] Under the aforementioned collaborative mechanism, the needs for high-speed querying of short-term data and the data integrity requirements for long-term historical data analysis can be met simultaneously, keeping data consistency risks within a manageable and predictable range.

[0097] Through a dual-link data processing architecture, the real-time link ensures millisecond-level status monitoring and alarm response, while the batch link supports offline analysis and feature calculation of the full data, meeting the differentiated needs of real-time and near-real-time scenarios.

[0098] Step S3: Run the monitoring microservice.

[0099] By calling the data processing platform microservice through the API gateway, real-time data is queried from the time-series database and real-time passenger flow data is displayed.

[0100] Step S4: Intelligent Algorithm Engine Platform Microservices.

[0101] After the model inference API is invoked and the request parameters are verified, the passenger flow data (real-time passenger flow data / passenger flow characteristic data) stored in the subscribed data processing platform microservice can be queried. After preprocessing, the time series prediction model inference can be executed to generate prediction results and return them to the data processing platform microservice.

[0102] In more preferred examples, the fault alarm calls the intelligent algorithm engine platform to assess the impact of the fault and generate corresponding events, which are then used to generate scheduling plans.

[0103] Step S5: Data processing platform microservices.

[0104] After obtaining the passenger flow prediction results returned by the model inference API call, the rules engine processes the data (e.g., prediction confidence > 80%; prediction time window 5-15 minutes in the future; prediction passenger flow value exceeds the threshold) and issues an alarm event for anomaly detection (e.g., expected large passenger flow event).

[0105] Step S6, Contingency Plan Center Microservice.

[0106] After subscribing to an alarm event, construct the contingency plan trigger conditions, assess the scope of impact (such as signals, vehicles, information notifications, and power supply), query the contingency plan template from the relational database (MySQL) of this service, prepare the contingency plan generation context (alarm data, historical data), and construct the contingency plan generation request.

[0107] The API gateway calls the inference service of the intelligent algorithm engine to ultimately generate a complete scheduling plan.

[0108] A hybrid collaboration model combining event-driven and API call approaches is adopted. The event-driven approach enables asynchronous communication between microservices through message middleware. The communication chain for service publishing events is relatively long, making it suitable for scenarios with lower real-time requirements, such as the periodic release of passenger flow trend prediction results.

[0109] The API call method enables synchronous requests and instant responses between services through the API gateway, featuring instant access and suitability for scenarios with high real-time requirements, such as alarm prediction, which requires instant querying of real-time passenger flow data and returning inference results.

[0110] In the actual operation of the scheduling system, after receiving an event, the subscribed microservice can immediately request detailed data related to the event through API calls as needed to supplement the summary information in the event body.

[0111] Both event-driven and API calls are methods for driving communication between microservices, but the response latency of event-driven communication is usually higher than that of direct synchronous API calls. Therefore, based on the real-time requirements of business scenarios, event-driven communication is mainly used in asynchronous notification scenarios with strong decoupling, while API calls are mainly used in real-time interactive scenarios that require immediate use. The two methods work together to achieve a flexible balance between system communication efficiency and the degree of decoupling.

[0112] Step S7: Intelligent Algorithm Engine Platform Microservices.

[0113] Upon receiving an inference request from the contingency planning center microservice, the Triton Interface Server will be used to complete multi-model collaborative analysis. Use a rule engine / time series model to make an initial judgment on the scheduling scenario, and obtain event type, urgency level and preliminary quantitative evidence.

[0114] Large Language Model (LLM) is used to complete information integration and natural language generation (to complete the key text fields of the scheduling plan).

[0115] Impact analysis of scheduling instruction association objects was performed using graph neural networks (GNNs).

[0116] Step S8: Coordinate the scheduling of microservices.

[0117] Since the contingency plan center microservice triggered the complete scheduling contingency plan generation ready event, the microservice will be invoked through the API gateway.

[0118] Upon receiving the contingency plan, collaborative tasks are created through the collaborative workflow orchestration of the workflow engine (Camunda), and task information is stored in the relational database (MySQL) of this service. Task dependencies are established (e.g., power supply adjustments must precede train speed increases and standby train deployment; information dissemination can be performed in parallel with other tasks; station guidance signals are executed after information dissemination), and a collaborative communication session is created.

[0119] Based on the task dependencies established by the collaborative scheduling, specialized tasks are assigned sequentially, and the planning and scheduling microservice API is invoked.

[0120] Step S9: Plan and schedule microservices.

[0121] It will receive collaborative scheduling tasks and generate professional instructions, distribute the instructions through various professional protocol adapters, and record the instruction status in the relational database of this service.

[0122] Specifically, each professional adapter is deployed in the planning and scheduling microservice, responsible for interfacing with various professional systems and distributing professional instructions. The collaborative scheduling microservice focuses on defining collaborative tasks, including their order and content, rather than the actual instructions.

[0123] Step S10: Data processing platform microservices.

[0124] We will continuously acquire real-time data to calculate and manage the effectiveness of scheduling and handling metrics (such as changes in congestion and passenger waiting times), assess whether the expected results have been achieved, and, if necessary, publish monitoring events to the API gateway.

[0125] Step S11: Run the monitoring microservice.

[0126] Real-time monitoring data obtained from time-series databases is visualized to show the results of the handling process.

[0127] Step 12: Coordinated scheduling of microservices Continuously monitor the scheduling and handling related monitoring events published by the operation monitoring microservice, continuously analyze whether scheduling adjustments are needed, and call the contingency plan center microservice again through the API gateway.

[0128] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function as logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0129] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A city rail transit intelligent scheduling system based on microservices and DDD layering, comprising a plurality of microservices, characterized in that, Microservices include: Data processing platform microservice, intelligent algorithm engine platform microservice, contingency plan center microservice, collaborative scheduling microservice, planning and scheduling microservice, and operation monitoring microservice; The data processing platform microservice processes and stores data from multiple professional systems, calls the intelligent algorithm engine platform microservice to generate call results, and generates subscription events based on the call results. The contingency plan center microservice generates a call plan by invoking the intelligent algorithm engine platform microservice based on the received subscription events; The collaborative scheduling microservice creates collaborative tasks and establishes dependencies between various professional tasks according to the invocation plan. The planning scheduling microservice then distributes each professional task to the corresponding professional system in sequence. The operation monitoring microservice monitors the status of each professional task and displays it visually. The monitoring results are fed back to the collaborative scheduling microservice, which then determines whether scheduling adjustments are needed. Each microservice is bounded context based on DDD layering and communicates collaboratively through event-driven and / or API calls.

2. The micro-service and DDD layered based urban rail transit intelligent dispatching system according to claim 1, characterized in that, The bounded context partitioning based on DDD layering includes performing domain modeling and hierarchical partitioning of the business functions of the scheduling system, obtaining the corresponding domain events, extracting aggregate roots and confirming entities, and partitioning the context based on well-defined boundaries. The microservices are divided into an interface layer, an application layer, a domain layer, and an infrastructure layer. The domain layer includes an alarm rule aggregation root, a configured rule deduplication mechanism, and performs hash calculations on rule conditions and thresholds to determine whether there are duplicate rules under the same conditions. 3.The urban rail transit intelligent dispatching system based on microservices and DDD layering according to claim 1, characterized in that, The data processing platform microservices include a time-series library and a data lake, and adopt a dual-link processing architecture that combines real-time and batch links in parallel. The time-series library stores short-term, hot data, while the data lake stores all data. The full data includes long-term warm and cold data and short-term data that requires preprocessing. The time-series database and the data lake achieve collaboration through a state coordination mechanism for redundant data; The state coordination mechanism includes: subscribing to newly added or changed data in the previous time window from the time series library according to preset time parameters, using a streaming synchronization engine to convert the exported data into a columnar format file and write it to a specified location in the data lake, and registering the synchronization job as a data lineage.

4. The micro-service and DDD layered based urban rail transit intelligent dispatching system according to claim 3, characterized in that, The time-series library responds quickly to high-priority data, while the data lake processes or batches low-priority data. Use StarRocks' federated query portal to query data in the time-series database and data lake.

5. The micro-service and DDD layered based urban rail transit intelligent dispatching system according to claim 1, characterized in that, The intelligent algorithm engine platform is deployed in microservices using at least two of the following: a time-series prediction model, a large language model, and a graph neural network model. The time-series prediction model is used to perform passenger flow prediction, the large language model is used to generate natural language text of the scheduling plan, and the graph neural network model is used to perform impact analysis on the scheduling instructions associated with the scheduling plan.

6. A city rail transit intelligent scheduling method based on microservices and DDD layering, characterized in that, include: Step S1: Process and store the collected multi-disciplinary system data through the data processing platform microservices; Step S2: Call the intelligent algorithm engine platform microservice to generate the call result, and generate subscription events based on the call result; Step S3: The contingency plan center microservice calls the intelligent algorithm engine platform microservice to generate a call contingency plan based on the subscribed events; Step S4: The collaborative scheduling microservice receives the call plan, creates collaborative tasks, and establishes dependencies between various professional tasks; Step S5: The planning and scheduling microservices sequentially assign professional tasks to the corresponding professional systems, and each professional system executes the assigned professional tasks. The monitoring microservice monitors the status of each professional task and feeds back the monitoring results to the collaborative scheduling microservice, which then determines whether scheduling adjustments are needed.

7. The micro-service and DDD layered based urban rail transit intelligent scheduling method according to claim 6, characterized in that, The data processing platform microservices adopt a dual-link processing architecture with parallel real-time and batch links to process data from multiple professional systems, forming a dual storage architecture of time-series database and data lake. The time-series database and the data lake achieve state coordination through a synchronization mechanism. The synchronization mechanism includes: subscribing to newly added or changed data in the previous time window from the time series library according to preset time parameters, using a streaming synchronization engine to convert the exported data into columnar format and write it into the data lake, and registering the synchronization job as a data lineage.

8. The intelligent scheduling method for urban rail transit based on microservices and DDD layering as described in claim 6, characterized in that, The contingency plan center microservice receives summary information from subscribed events and requests detailed feature data corresponding to the subscribed events from the data processing platform microservice via API calls.

9. The micro-service and DDD layered based urban rail transit intelligent scheduling method according to claim 6, characterized in that, The planning and scheduling microservice orchestrates the dependencies and execution order of various professional tasks through a workflow engine; The dependencies include: power supply adjustment tasks are executed before train speed-up tasks and train preparation and commissioning tasks; information dissemination tasks are executed in parallel with other tasks; and station guidance signal adjustment tasks are executed after the information dissemination tasks are completed.

10. The micro-service and DDD layered based urban rail transit intelligent scheduling method according to claim 6, characterized in that, The intelligent algorithm engine platform microservice generation and invocation plan includes: Use a rule engine or time series model to make an initial judgment on the calling scenario and obtain the event type and urgency level; The large language model is used to integrate the preliminary judgment results and related data to generate natural language text for invoking the contingency plan; A graph neural network model was used to perform an impact analysis on the scheduling instructions associated with the invoke plan.

Images