25、城市轨道交通系统关键性能指标评估与轻轨列车车载系统架构设计

gitlab7runner

于 2025-07-19 11:10:35 发布

阅读量57

点赞数

CC 4.0 BY-SA版权

分类专栏：铁路系统安全与可靠性进展文章标签：城市轨道交通轻轨列车关键性能指标

本文链接：https://blog.youkuaiyun.com/gitlab7runner/article/details/149598033

铁路系统安全与可靠性进展专栏收录该内容

30 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

城市轨道交通系统关键性能指标评估与轻轨列车车载系统架构设计

城市轨道交通乘客流量建模
在城市轨道交通系统中，考虑乘客在不同线路间的换乘流量，能够提升模型的准确性。地铁网络通常由多条相互连接的线路组成，从线路端点进入的乘客可能会在网络的交汇点换乘到其他线路。这种乘客流量通常通过起讫点矩阵（Origin - Destination Matrices）来捕捉，矩阵中的元素表示在车站 i 下车的乘客在车站 j 离开列车的比例，或者在交汇站离开的乘客进入另一条线路下一趟列车的比例。
目前的模型尚未整合乘客流量，也未考虑乘客数量。然而，乘客数量会影响延误的分布。但将乘客流量整合到模型中可能会显著增加模拟时间，因为这需要统计列车数量（或至少进行量化），并记录乘客的下车历史，以确保准确表示乘客流量。一种改进模型和模拟框架的灵感来源于多相流体 Petri 网。另外，流量表示的一个难点在于起讫点矩阵并非事先可知，在地铁网络设计的早期阶段无法获取，通常需要在网络投入运营后，通过长时间观察乘客习惯来构建。
城市轨道交通系统性能评估框架
提出了一个用于评估特定地铁线路调节算法性能的框架。该框架由网络和列车运行的高级模型组成，其中包含随机扰动，调节算法被插入其中以纠正延误。整个系统允许进行快速模拟，从而开展模拟活动，以获取调节算法实现关键性能指标（KPI）目标效率的统计数据。
以圣地亚哥地铁 1 号线为例，通过该框架得出了相关统计数据。研究提出的一个关键问题是抽象（确保模拟效率）与所导出统计数据准确性之间的权衡。Petri 网能够准确建模网络拓扑，因此模型的关键在于运行时间和停留时间的准确性。截断指数多项式函数可以精确建模列车延误比提前更可能出现的分布。当对这些函数进行采样过于耗时，可用仿射函数界定的区域来近似这些函数。
当前的一个重大挑战是定义这些分布。在设计早期阶段，可以根据网络和列车的预期特性预先设计分布。对于现有系统，当挑战不是设计而是调整列车车队及其路径以提高 KPI 时，可能需要使用考虑上下文元素（如乘客、列车和调节本身）的准确分布。收集的日志可以帮助学习停留或运行时间分布的参数，但估计乘客或调节对特定时长的贡献仍然是一项具有挑战性的任务，因为这些参数通常不会记录在日志中。
轻轨列车车载系统架构背景
轻轨交通（LRT）系统兼具有轨电车和地铁的特点。分析了 Thales 公司的 LRT 车载系统（OBS）架构，该架构旨在实现高可用性，基于开源技术和成熟的通信标准构建。使用开源基础技术满足了架构要求，特别是 Qt 框架、0MQ 和 ASN.1 到 C 编译器被用于开发面向微服务的容错系统。
冗余服务在复制的相同硬件单元上生成，其中一个为主单元，通过特定算法无缝且自动地保持同步。当其中一个复制硬件盒上的服务出现故障时，有两种选择：一是进行完全的主控制权切换，另一个冗余盒成为新的主单元；二是将微服务迁移到另一个冗余盒，以控制相同的非故障设备。该架构已在 LRT 和地铁解决方案中积极应用，将描述其在实际应用中的好处以及在代码质量和可维护性方面的有效性。
LRT 系统环境概述
LRT 系统由不同的子系统组成，这些子系统提供不同的功能。所有子系统都消费和发送数据，以便运营控制系统（OCC）监控 LRT 服务，并为其他子系统提供输入和读取输出。系统的物理分布通常分为三个不同区域：
- OCC ：操作员通过实时读取系统生成的事件来监控服务，并可以与司机和车载人员交谈，对 LRT 子系统进行操作（如手动覆盖）。
- 路侧（WS） ：这是一个分布式系统，提供和分发有关 LRT 物理状态和状态的信息，如列车状态、信号和道岔的当前配置、乘客信息和广播服务（PIS/PAS）、视频磁盘记录（VDR）。
- 车载系统（OBS） ：连接到列车设备、传感器、显示器、扬声器、无线电（如 Tetra、802.11abgn、LTE），能够收集、分发和存储服务数据，用于列车与路侧元素连接（如列车到达交汇区域时向信号系统请求路线），使设备、人员和乘客能够与 OCC 和路侧进行通信（在车载时接收和发送服务相关数据，如 PIS/PAS），以及使用 GNSS 和标签读取器数据定位列车。
  作者关注的是非安全关键的 OBS。车载系统可分为安全关键（如能够影响列车位置和速度的系统）和非安全关键（如列车定位和 PIS/PAS）两类。车队安全关键决策（信号）由路侧单元负责，因此即使列车无法通信其状态，路侧单元也能在无需列车协作的情况下防止事故发生。作者的应用场景可总结为：
- 无安全关键问题；
- 需要冗余和无缝的主控制权切换；
- 嵌入式设备环境；
- 多种网络接口设备和协议（Tetra、LTE、WiFi）；
- 实时数据处理。
  在这种情况下，以前版本的整体式应用往往较为脆弱，例如低优先级数据源的单个协议处理程序可能会导致整个车载控制单元（OBCU，即嵌入式 PC）崩溃，这促使作者研究分布式架构。
车载系统架构的冗余设计
OBS 故障可能导致系统故障，中断或破坏 LRT 运营的连续性。因此，OBS 使用冗余作为提供降级运行模式的手段，即使在车载故障的情况下也能使 LRT 正常服务继续。所描述的架构允许单个服务在复制设备实例之间无缝迁移，这对于处理硬件组件的服务特别有用。在发生多次故障时，系统可以在降级模式下继续工作，除非所有副本中的相同类型资源都出现故障。例如，在一个有两个复制 OBCU，每个都连接到 Tetra 无线电和标签读取器的系统中，即使一个 OBCU 的标签读取器和另一个 OBCU 的无线电都出现故障，系统仍能在降级模式下工作。如果只有一个 OBCU 发生故障，即使该故障完全阻止其运行，系统也能以另一个 OBCU 作为新的主单元优雅降级。
所有主控制权的切换可以随时发生，因此从系统/设备的状态始终保持同步。当系统发生故障时，新的候选主设备已经准备好其状态，并能在尽可能短的时间内切换模式。
分布式应用架构及问题解决
当项目的复杂性使得将其组织成多个独立的软件应用程序合理时，共享状态更新就变得必要。作者使用开源项目 ØMQ 来解决这个问题。
ØMQ 是一个旨在简化消息传递模式的通信库。两个软件进程的连接通常使用客户端 - 服务器范式实现，其中服务器端为一个或多个客户端提供服务。实际上，客户端 - 服务器是一个通用模式，因为服务的提供方式有很多种。客户端 - 服务器仅定义了哪个进程在监听，哪个进程在连接。ØMQ 试图抽象出双方的连接方式，而是专注于消息传递的方式。有各种类型的套接字可用于利用基本的消息传递模式。作者选择使用如克隆模式这样的高级消息传递模式。
应用互联模式分析
在实现分布式系统或将系统的复杂逻辑分离成多个独立进程时，需要考虑到这种方法通常会带来更高的通信成本和系统复杂性，因此在小项目中并不总是方便采用。然而，将整体业务逻辑组织成多个独立应用程序有一些优点：
- 较小的应用程序通常比大型应用程序复杂度低，更易于维护；
- 便于大型团队协作；
- 出现故障时责任明确；
- 系统的部分可以在不关闭整个服务的情况下进行更新；
- 如果组织得当，整个系统的扩展性更好；
- 单个应用程序的崩溃不会影响其他应用程序，只会影响出现问题的那个；
- 定义清晰接口的小型应用程序更易于自动化测试。
  由于整个系统的逻辑分布在多个应用程序中，状态也随之分布。每个应用程序或组件都有自己的状态。通常最直接的解决方案是组件之间的直接连接，但这种分散式架构虽然非常灵活，但会导致更高的复杂性和维护成本。因为每个应用程序都可能独立地与其他对等方通信，从而定义了许多应用程序特定的状态更新策略和可能的端点。
  为了解决复杂性的增加，可以使用集中式架构，即使用一个代理来管理分布式应用程序状态的传递和存储。使用中央组件既有优点也有潜在的缺点：
  | 优点 | 缺点 |
  | ---- | ---- |
  | 代理简化了网络应用程序的发现 | 代理可能成为瓶颈，需要了解和评估流量数据量 |
  | 每个应用程序使用相同的协议连接到代理 | 发送消息时可能会有一些延迟和抖动，具体取决于数据流量和系统负载 |
  | 无需为每对通信应用程序定义绑定和连接方 | |
  | 系统在连接数量方面随着应用程序数量的增加扩展性更好 | |
  | 添加新应用程序并不总是需要修改所有现有应用程序 | |
共享状态与 ØMQ 克隆模式
选择 ØMQ 克隆模式作为进程间通信的模式，用于使应用程序能够通信和共享其状态。连接到代理的应用程序将被称为克隆节点。
该架构是集中式且以代理为中心的。在作者的实现中，代理不仅负责消息的传递，还负责状态的存储。这种存储能力是相对于通用集中式模型的一种变体。状态存储和转发在代理内部进行，因为其他软件模块不能直接相互通信。
该模式可以通过以下操作来描述：
- 同步操作 ：应用程序在连接到克隆代理时立即进行同步。在同步过程中，应用程序从代理获取其所需的共享状态。这样，应用程序可以在崩溃或停止后从之前的状态重新启动。同步使用一对请求 - 回复套接字进行。代理始终监听状态请求，每当收到请求时，它会停止正常操作流程，将其整个状态发送回去。
- 更新操作 ：网络内的数据传播通过一对发布者 - 订阅者套接字进行。节点之间共享的消息是键 - 值对，键称为主题，值是有效负载。应用程序可以订阅主题。当建立订阅时，代理将其收到的所有具有订阅主题的消息转发给应用程序，即应用程序收到主题更新。
- 更改操作 ：应用程序可以通过发送其主题被代理识别为更改主题的消息来更改共享数据。具体来说，每个模块通过一对管道套接字转发其更改。代理序列化从应用程序收到的所有更改，更新其状态并重新发布（更新）更改。任何更改后，键等于消息主题名称的共享状态的值将等于消息有效负载。
  克隆模式及其实现定义了组件之间消息的交换方式，但对有效负载格式没有限制。为了有明确的软件接口，有效负载可以由其他形式主义（如 ASN.1、MessagePack、JSON 等）定义，这取决于应用程序的业务逻辑。作者选择使用在电信领域广泛使用且经过验证的 ASN.1 格式作为有效负载。
状态复制与切换
为了提高集中式架构的可用性，添加了热备用机制。在这种情况下，系统定义为运行在同一台机器上的所有应用程序和代理的集合。实例化并连接两个系统，其中一个是备用系统，另一个是活动系统。
承担热备用角色的代理系统（系统 B）无限制地订阅活动系统（系统 A）的整个状态。这意味着系统 B 将获得所有更新，并使其自身状态与系统 A 保持一致。代理不需要扩展以连接到另一个代理，而是使用联邦式方法，而不是专用通信通道（对等方法）。
通过两个特殊应用程序（类似于普通节点）连接系统 A 和系统 B，即 OuterApp 和 InnerApp，负责将消息从一个系统注入到另一个系统。OuterApp 使用专用连接到 InnerApp。为了防止消息循环，OuterApp 对其收到的消息进行标记，并过滤掉已标记的消息。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B{系统故障?}:::decision
    B -->|是| C(选择切换方式):::process
    B -->|否| D(正常运行):::process
    C --> E{选择主控制权切换?}:::decision
    E -->|是| F(新主单元接管):::process
    E -->|否| G(微服务迁移):::process
    F --> H(系统继续运行):::process
    G --> H
    D --> B
    H --> B

综上所述，城市轨道交通系统的性能评估和轻轨列车车载系统架构设计都面临着各自的挑战和机遇。在乘客流量建模和系统性能评估方面，需要平衡模拟效率和数据准确性，克服数据获取和参数估计的困难。而在轻轨列车车载系统架构设计中，分布式架构和冗余设计提高了系统的可用性和容错能力，但也需要解决分布式应用带来的复杂性问题。通过合理选择通信模式和技术，如 ØMQ 克隆模式和开源技术，可以有效应对这些挑战，实现系统的高效运行和高质量维护。未来，可以进一步探索如何更准确地定义分布函数，以及如何优化车载系统架构以适应不断变化的需求。

城市轨道交通系统关键性能指标评估与轻轨列车车载系统架构设计

热备用机制详细流程
热备用机制在轻轨列车车载系统架构中起着关键作用，确保系统在出现故障时能够快速恢复。以下是热备用机制的详细流程：

初始化阶段 ：系统启动时，会确定一个活动系统（系统 A）和一个备用系统（系统 B）。备用系统的代理会无限制地订阅活动系统的整个状态，开始同步状态信息。
正常运行阶段 ：活动系统处理所有的业务逻辑和数据交互，备用系统持续接收活动系统的状态更新，保持自身状态与活动系统一致。
故障检测阶段 ：系统会实时监测各个组件的状态，当检测到活动系统出现故障时，会触发切换机制。
切换阶段 ：根据故障的类型和严重程度，系统会选择主控制权切换或微服务迁移。如果选择主控制权切换，备用系统将成为新的活动系统，接管所有的业务逻辑；如果选择微服务迁移，故障的微服务将被迁移到备用系统上继续运行。
恢复阶段 ：切换完成后，系统会继续正常运行，同时对故障进行诊断和修复，以便在必要时能够再次切换回原来的配置。

阶段	描述
初始化	确定活动系统和备用系统，备用系统订阅活动系统状态
正常运行	活动系统处理业务，备用系统同步状态
故障检测	实时监测系统状态，检测故障
切换	根据故障情况选择主控制权切换或微服务迁移
恢复	系统继续运行，诊断和修复故障

分布式架构的性能分析
分布式架构虽然带来了诸多优点，但也可能引入一些性能问题。以下是对分布式架构性能的分析：
- 通信延迟 ：由于各个应用程序之间需要通过网络进行通信，因此通信延迟是一个不可忽视的问题。特别是在使用集中式架构时，代理可能会成为瓶颈，导致消息传递的延迟增加。
- 系统复杂性 ：分布式架构的复杂性较高，需要更多的资源来管理和维护。例如，需要对各个应用程序的状态进行同步和更新，这可能会增加系统的开销。
- 可扩展性 ：分布式架构的可扩展性较好，可以根据需求添加或删除应用程序。但在实际应用中，需要考虑到系统的负载均衡和资源分配问题，以确保系统的性能不会受到影响。
- 容错性 ：分布式架构的容错性较高，当某个应用程序出现故障时，不会影响整个系统的运行。但在故障发生时，需要快速进行切换和恢复，以减少对业务的影响。
为了提高分布式架构的性能，可以采取以下措施：
- 优化网络配置 ：选择合适的网络拓扑结构和通信协议，减少通信延迟。
- 使用缓存技术 ：在代理或应用程序中使用缓存技术，减少对数据库的访问次数，提高系统的响应速度。
- 负载均衡 ：使用负载均衡器将请求均匀地分配到各个应用程序上，避免某个应用程序过载。
- 监控和调优 ：实时监控系统的性能指标，及时发现和解决问题。根据系统的运行情况进行调优，提高系统的性能和稳定性。
未来发展趋势与展望
随着城市轨道交通系统的不断发展，对系统的性能和可靠性提出了更高的要求。未来，城市轨道交通系统可能会朝着以下方向发展：
- 智能化 ：引入人工智能和机器学习技术，实现列车的自主运行和智能调度。例如，通过对乘客流量的预测，优化列车的运行时刻表，提高运输效率。
- 集成化 ：将各个子系统进行深度集成，实现数据的共享和协同工作。例如，将车载系统、路侧系统和运营控制系统进行集成，实现对列车的全方位监控和管理。
- 绿色化 ：采用环保节能的技术和设备，减少对环境的影响。例如，使用再生制动技术回收列车的能量，降低能耗。
- 安全化 ：加强系统的安全防护，保障乘客的生命财产安全。例如，采用多重安全机制，防止列车受到黑客攻击和恶意干扰。
为了适应未来的发展趋势，需要不断地进行技术创新和架构优化。例如，在乘客流量建模方面，可以引入更先进的数据分析和预测技术，提高模型的准确性；在车载系统架构设计方面，可以采用更灵活的微服务架构，提高系统的可扩展性和容错性。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(智能化发展):::process
    B --> C(集成化发展):::process
    C --> D(绿色化发展):::process
    D --> E(安全化发展):::process
    E --> F(技术创新与架构优化):::process
    F --> G([结束]):::startend

综上所述，城市轨道交通系统的性能评估和轻轨列车车载系统架构设计是一个复杂而又重要的领域。通过对乘客流量的建模和系统性能的评估，可以提高系统的运行效率和服务质量；通过采用分布式架构和冗余设计，可以提高系统的可用性和容错能力。未来，随着技术的不断发展，城市轨道交通系统将朝着智能化、集成化、绿色化和安全化的方向发展，需要不断地进行技术创新和架构优化，以适应未来的发展需求。