ISO/TS 29843-2 — 智能交通系统 — 出行整合 — 第2部分：数据模型与通信协议

ISO/TS 29843-2 概述：智能交通系统——出行整合——第2部分：数据模型与通信协议

ISO/TS 29843-2是与第1部分配套的技术规范，提供了实现ISO/TS 29843-1中定义的出行整合框架所需的数据模型、通信协议和消息格式的详细规范。第1部分制定了架构蓝图，而第2部分提供了使系统开发者能够构建可互操作的出行平台组件的具体技术规范。这包括服务发现、行程规划、预订、支付和实时运行状态交换的标准化数据模式。

ISO/TS 29843-2中定义的数据模型采用了基于Transmodel标准并扩展了出行特定概念的语义本体方法。这使得能够自动验证不同服务提供商之间的数据一致性，与使用专有数据格式的项目相比，集成测试工作量减少约40%。

该规范涵盖六个主要数据域：服务提供数据、网络和时刻表数据、行程计划数据、预订和支付数据、实时运行数据和用户档案数据。每个域使用抽象数据建模方法定义，并为JSON和XML格式指定了具体的序列化方式，确保跨不同技术栈的广泛兼容性。

核心数据模型及其关系

ISO/TS 29843-2定义了一套全面的数据实体及其显式关系和完整性约束。中心实体是MobilityService，代表向用户提供的任何交通服务。每个MobilityService具有服务类型、运营商、服务区域、时刻表、票价结构和无障碍特性等属性。MobilityService组织成ServiceNetwork，代表服务运行的物理或逻辑基础设施。

数据实体	关键属性	关系	验证规则
MobilityService	服务ID、服务类型、运营商ID、状态、票价模型、无障碍等级	属于ServiceNetwork；具有ServiceSchedule；参与ServiceOffering	服务类型必须来自受控词汇表；票价模型必须包含基础货币和定价结构
ServiceSchedule	有效起始日、有效截止日、运营日、时刻表条目	被MobilityService引用；链接到JourneyPattern	同一服务的有效期不能重叠；时刻表条目必须按时间顺序排列
TripPlan	计划ID、起点、目的地、出发/到达时间、行程段、总费用、总时长	由TripLegs组成；每个TripLeg引用一个MobilityService	段间换乘时间≥最小换乘时间；总时长≤请求的最大值
Booking	预订ID、用户ID、计划ID、状态、支付参考、创建时间戳	引用TripPlan；关联PaymentTransaction；链接到UserProfile	单次预订不可超出发车前24小时；取消必须在最小取消通知时间内允许
RealtimeStatus	实体ID、时间戳、状态代码、延迟、位置、载客量等级	可引用MobilityService、TripLeg或InfrastructureElement	状态更新必须带有实际观察时间的时间戳；延迟值相对于计划时间

通信协议与消息流

该规范为不同集成场景定义了同步和异步通信模式。同步RESTful API用于请求-响应交互，如服务发现、行程规划查询和预订确认。使用MQTT或AMQP的异步消息传递用于实时状态更新、中断通知和位置上报。ISO/TS 29843-2还定义了事件驱动通知的webhook机制，使服务提供商能够将关键事件推送到订阅平台。

在实施实时状态更新协议时，工程师应考虑使用基于主题过滤的发布-订阅模式。ISO/TS 29843-2建议按层级组织主题，以实现细粒度的订阅控制和高效的消息路由。这种方法通过确保客户端只接收与其运营上下文相关的更新来减少带宽消耗。

典型的多模式出行消息流涉及多个顺序交互。首先，用户提交包含起点、目的地和偏好的行程规划请求。平台查询已注册的MobilityService，生成候选TripPlan，并按用户标准排序返回。用户选择并确认计划后，向每个相关服务提供商发送预订请求。确认后，平台监控每个TripLeg的RealtimeStatus，并在发生需要替代方案的中断时主动通知用户。

安全、隐私与数据质量

ISO/TS 29843-2强制要求全面的安全措施，包括所有通信通道的TLS 1.3、用于认证和授权的OAuth 2.0与OpenID Connect，以及金融交易中的消息级签名以实现不可否认性。该标准还定义了数据质量要求，包括准确性、完整性、及时性和一致性。

出行数据整合中一个经常被低估的挑战是时间数据对齐。不同的服务提供商可能使用不同的时钟源，存在不同程度的漂移。ISO/TS 29843-2要求所有带时间戳的数据使用UTC和微秒精度，每个服务提供商应实施NTP同步。工程师还必须处理夏令时转换和国际日期变更线期间的时钟偏差边缘情况。

隐私保护遵循数据最小化和目的限制原则。用户档案数据分为必填字段、可选字段和敏感字段。标准要求个人身份信息在所有域间数据交换中进行假名化处理，用于分析和报告的数据则需完全匿名化。

ISO/TS 29843-2识别了行程规划协议中的一个特定安全漏洞：攻击者可以提交大量行程规划请求来推断用户移动模式或耗尽平台资源。标准要求实施者部署基于用户和IP配额的速率限制、对所有请求参数进行输入验证以防止注入攻击，以及识别和阻止滥用查询模式的异常检测系统。速率限制阈值应由平台运营商配置并在API文档中透明传达。

常见问题

问：ISO/TS 29843-2如何处理跨多个服务提供商的票价计算和支付？

答：该规范定义了清算所模型，每个预订包含服务提供商价格、平台费用和适用折扣的票价组件。平台将这些汇总为面向用户的单一价格。服务提供商与平台运营商之间的结算使用标准化的清算消息格式，对账周期可从每日到每月配置。

问：当服务提供商的实时数据源离线时会发生什么？

答：ISO/TS 29843-2要求平台维护每个服务提供商的最后已知时刻表和状态的本地缓存。当实时数据源不可用时，平台回退到计划数据，并将该提供商的所有实时依赖功能标记为不可用。提供商连接健康状态受到监控，每30秒自动尝试重新连接。如果中断超过可配置的阈值（通常为15分钟），平台可能暂停涉及该提供商的行程规划。

问：ISO/TS 29843-2是否支持移动应用的离线操作？

答：是的。该规范包括一个缓存同步协议，使移动应用能够下载服务时刻表、票价表和网络拓扑以进行离线行程规划。该协议支持增量更新以最小化带宽消耗，并定义了设备重新连接时需要协调本地创建的预订与中央平台的冲突解决规则。

📥 标准文件下载

🔒

请等待 10 秒，广告加载完成后将显示下载链接

暂无下载文件