基于领域驱动与微服务的高铁列控仿真测试系统业务中台设计

2022-10-10 02:12陈汇远
铁道标准设计 2022年10期
关键词:应答器无线列车

陈汇远

(中国铁道科学研究院集团有限公司通信信号研究所,北京 100081)

高速铁路列控系统是保障铁路运输安全的核心装备。其中,车载设备是高铁列控系统的关键部分,其运行直接关系旅客生命和财产安全。为保障车载设备安全可靠地运行,有必要对高铁列控系统车载设备的系统功能进行充分全面测试和验证。

高铁列控仿真测试系统涉及大量软、硬件开发,结构和接口复杂,业务规则繁杂多变。谢雨飞和郭丹青[1-2]通过采用形式化建模方法对高铁列控系统进行验证和测试;卢楠[3]通过采用专家系统方法对列控系统进行测试,但其缺少针对系统业务扩展如何快速响应新需求变化的思考;庞家杰和焦健[4-5]从需求分析、系统设计和系统实现对高铁列控测试系统进行全面详细描述,但系统设计基于传统的单体架构设计,代码耦合性强,资源可重用性低。如何解决大型软件设计建模的复杂性,促进信息系统的开发与协同效率,使核心业务系统能快速响应新需求变化,大幅降低软件开发成本,提高系统的可扩展性和可维护性,成为构建大型复杂信息系统迫切需要解决的问题。

1 系统构成

高速铁路列控仿真测试系统是个半实物仿真系统,它包括主控模块、无线消息处理模块和硬件模块,其系统结构如图1所示。

图1 高速铁路列控仿真测试系统结构

1.1 主控模块

主控模块包括参数设置子模块、车载与地面仿真子模块和故障仿真子模块。

(1)参数设置子模块

用于设置列车参数及与硬件模块通信的参数。列车参数主要包括列车型号、列车长度、轮径值等。与硬件模块通信的参数主要包括:与硬件模块中IO接口模拟装置通信参数、与速度传感器模拟装置通信参数、与轨道电路信号模拟装置通信参数及与应答器信号模拟装置通信参数。

(2)车载与地面仿真子模块

用于模拟地面线路仿真信号和车辆IO功能。通过加载与校核列控工程数据脚本文件产生列车地面线路数据仿真信号;根据列车仿真速度计算列车位置,并通过列车位置逐条执行脚本指令;同时具备模拟车辆IO功能。列控工程数据脚本文件主要包括列车位置、相对距离、载频、低频、区段名称及区段长度等。所产生的仿真信号主要包括:车辆输入输出信号、轨道电路信号、应答器信号及速度传感器信号。通过IO接口模拟装置接收车载设备的制动信息、切除牵引、过分相和过分相有效等信号;通过IO接口模拟装置向ATP车载设备发送方向手柄位置、牵引手柄位置、制动手柄位置、驾驶室激活、休眠和制动反馈等信号。

(3)故障仿真子模块

用于模拟列车故障状况,测试列车ATP异常条件下的功能处理。列车故障不仅包括紧急制动反馈故障、常用制动反馈故障、速度跳变、速度差故障等,也包括模拟牵引手柄、制动手柄、方向手柄的状态故障等。

1.2 无线消息处理模块

用于模拟无线闭塞中心(Radio Block Center,RBC)的功能,加载并校核无线脚本文件,执行无线消息序列,通过硬件模块中的综合业务数字网(Integrated Services Digital Network,ISDN)服务器与真实ATP进行无线消息交互,实现ATP在列控C3等级下控车。无线脚本文件主要包含列车位置、RBC发送的无线消息、RBC接收的无线消息、无线消息长度、无线消息内容和无线消息传输方向等信息。

1.3 硬件模块

硬件模块包括IO接口模拟装置、速度传感器模拟装置、轨道电路信号模拟装置、应答器信号模拟装置和ISDN服务器。其中,IO接口模拟装置用于模拟列车的各种手柄位置、激活驾驶台、过分相、制动、制动反馈等功能;速度传感器模拟装置用于模拟列车的速度脉冲信号;轨道电路信号模拟装置用于模拟地面线路的轨道电路信号;应答器信号模拟装置用于模拟地面线路的应答器信号;ISDN服务器用于RBC与ATP车载设备的无线信息交互。

2 领域驱动设计及微服务

2.1 领域驱动设计2.1.1 领域驱动设计架构

2004年软件设计大师Eric Evans提出领域驱动设计是构建大型复杂软件的系统分析和设计建模方法,它采用分层结构,包括用户界面层、应用层、领域层和基础设施层[6]。其中,用户界面层实现与用户信息交互;应用层起协调作用,不含任何业务规则和逻辑,通知领域层向其传递调用信息;领域层为系统的核心层,负责表达业务定义、业务规则和业务的状态,它将软件中最重要的资产业务规则进行剥离,抽象在领域层,使得业务逻辑与应用层和基础设施层等代码分离,实现业务逻辑与数据分离;基础设施层提供系统的技术支撑,包括具体平台、数据持久化和消息传输等。

领域驱动设计是一系列软件设计实践、技术和原则的集合,它是服务划分的一种方法,领域驱动设计中的核心部分是领域模型,它能够将领域模型解耦成包含业务流程且相互区别的限界上下文并表达它们之间的关系。领域驱动设计的技术特点是分层架构与职责划分和高可复用性。

2.1.2 领域模型设计

领域层是系统核心层,其主要作用是设计出能够准确表示系统业务逻辑的领域模型。Eric Evans提出7种领域模型元素:实体、值对象、关联、服务、聚合、工厂和仓储。其中,实体、值对象、关联和服务是反映领域模型中业务逻辑的基本元素,聚合、工厂和仓储则描述上述4种基本元素在领域模型中的生命运行周期[7]。

在领域模型设计中,首先,明确领域概念和领域边界;其次,领域可细化为子域,通过领域边界分析界定边界的职责和划分限界上下文;然后,通过领域场景分析,设计领域模型的属性和行为,构建限界上下文之间的集成关系[8]。根据领域场景分析中的操作集合定义领域实体,把具有个性特征且身份唯一的领域概念抽象成实体,把不具备身份唯一特征且可变领域概念抽象成值对象,领域对象具备状态和行为,根据领域实体与值对象业务关联性定义聚合,一个聚合就是一个事务边界[9]。此外,有一些逻辑处理和行为是服务于实体,供领域实体对象调用,能很好协调各实体共同完成某些行为称之为领域服务。领域服务只有行为没有状态,通过对实体和领域服务中的行为建模形成领域事件,领域事件能够在业务流程中驱动业务行为进行流转[10]。最后,根据业务和语义边界、服务及领域事件之间的依赖关系确定领域模型。

2.2 微服务

微服务指根据系统业务功能,构建能够互相协作的小而自治服务[11]。它具备高内聚、高扩展和高自治性特点,使得系统易于扩展和维护[12]。

微服务架构是近年来新兴的软件架构,具备服务化、组件化、分散化和独立部署等优点,它通过组件化的方式将应用程序分解为多个微服务,使得系统更易开发、扩展和维护。同时,微服务系统实质是分布式系统,它强调去中心化的软件组织架构,每个微服务都可独立测试、部署和运行,单个服务变更不会影响到其他服务,持续化部署和维护更加便利,实现了系统高可靠性、可用性和可维护性[13]。

设计一种高质量的微服务架构需遵循以下原则:单一职责、服务自治、轻量级通信方式和接口明确。根据这些设计原则,微服务基础框架应包括:服务注册、服务发现、服务通信、日志管理和接口管理等基本功能。此外,为增强微服务架构的完整性及先进性,应加入限流容错、负载均衡、服务配置、服务监控等功能。通过对这些服务功能组合使用,保证了微服务架构的高效、稳定、可移植和跨平台等特性[14]。

2.3 领域驱动设计和微服务的结合

领域驱动设计与微服务相结合,赋予新的活力。SBD公司Jay Bercher指出领域驱动设计和微服务似乎是完美组合,采用这种组合方式,使得开发团队明确各自职责划分,根据负责的相关领域进行相应的微服务开发,限制了并行开发中可能出现的冗余,创建了一种高效的开发模式[15]。

领域驱动设计中限界上下文是微服务设计和拆分的主要依据[8]。领域驱动设计中领域层通过微服务形式实现系统业务逻辑功能,限界上下文中领域模型的领域事件,通过异步机制使得业务流程和数据能够从业务域中映射到微服务。领域驱动设计中应用层不含业务规则和逻辑,协调微服务编排、组合和调用。

3 中台设计

3.1 系统领域驱动模型

综合领域驱动设计理论和微服务特点,设计仿真测试系统领域驱动模型如图2所示。

图2 高速铁路列控仿真测试系统领域驱动模型

表示层实现与用户信息交互,主要包括试验场景信息显示;应用层实现服务调用,不含任何业务规则和逻辑;领域层作为系统核心层,实现系统业务逻辑功能;基础设施层实现数据持久化和数据通信。

3.2 业务中台建设

中台是一种企业能力共享和资源复用的方法论。中台包括业务中台和数据中台,业务中台能够有效组织后台的系统资源,转化为前端可调用的业务服务,提升业务的协作效率。业务中台依据“高内聚、低耦合”原则,将复杂业务系统进行细粒度拆分,降低业务系统复杂度,有利于软件开发和维护。数据中台是指通过数据技术对系统中的数据进行采集、分析和处理,根据业务需要对各类数据进行整合,实现数据汇聚和集中管理,以提供给业务中台使用。

微服务是目前业界公认的业务中台技术最佳实现方式[16]。业务中台架构建设多采用微服务架构,故具备微服务架构的优点和特点,此外,基于微服务架构的中台架构,对系统的共性能力和稳定能力进行提取,并对底层进行封装,通过“搭积木”的系统构建方式,快速实现系统升级和改造[17]。业务中台建设遵循“厚中台、薄应用”的思想,按照高内聚、低耦合的原则进行构建,通过业务逻辑分离,为前台减负,提高前台快速响应能力,整合后台系统资源,快速支持系统的业务扩展[18]。业务中台建设目标是将持续优化和提升的业务能力沉淀到业务中台,通过业务的集中化管控,实现业务能力复用和不同业务板块能力融合。 业务中台价值的核心意义在于将业务能力IT化转化为业务能力资产化,提高了业务的敏捷性,能够快速响应业务需求变化;通过可复用的业务能力能够大幅提高开发效率,避免了软件开发的重复建设,提升业务创新效能,达到降本增效的目标。

3.3 业务中台设计

业务中台设计首先基于业务领域建模,在业务建模的基础上进行中台规划,并根据业务功能进行服务识别和服务设计,最后实现服务[19]。业务中台领域建模通常采用领域驱动设计方法,通过规划业务限界上下文边界,构建中台领域模型,并根据领域模型进行微服务的识别和设计。业务中台设计如图3所示。

图3 业务中台设计

(1)业务领域建模

根据系统需求对业务拆分,并对业务边界划分,在建模中使用领域、子域,明确领域边界和划分限界上下文,依据职责对“领域模型”进行归纳,形成业务域模型;通过领域场景分析,设计业务域的属性和行为;基于领域建模分析方法分析业务实体,建立实体间联系,并根据业务、领域边界及领域事件间的关系确定领域模型。

(2)中台规划

通过领域模型和业务流程对服务进行识别和梳理,进行服务化架构建模,并根据领域驱动设计聚合要求规划业务中心。业务中心关注系统的业务需求,拥有清晰完整的业务边界。业务中台中心划分基本原则遵循高内聚低耦合、数据完整性、渐进性建设等原则。

(3)服务识别和设计

微服务设计和拆分的主要依据是限界上下文,通过领域模型的业务域、业务流程和限界上下文将业务能力设计成按业务域组织的有层次的服务。基于领域驱动设计划分微服务遵循的原则:最小完备原则、稳定空间原则、职责单一原则[20]。

涵盖本系统的主要业务服务包括车辆输入信号处理服务、车辆输出信号处理服务、列车位置计算服务、速度信号生成服务、轨道电路信号生成服务、应答器信号生成服务、无线消息处理服务、故障信息处理服务等。针对复杂业务,可进行颗粒度细化,拆分成若干微服务,分别进行开发和维护,提高了系统可维护性。

系统中多处用到的功能统一封装成可复用的公共服务,为业务服务提供更便利的支撑。它包括通信服务、流程服务、文件服务等。其中,流程服务能够将已有的多个功能独立服务,根据业务需要通过服务组合的方式组合成更为复杂和完善的整体应用,提高了系统可扩展性。

(4)服务实现

在服务实现阶段需考虑系统性能、可靠性、可扩展性和可维护性。经过服务设计,结合微服务的特点,通过基于微服务架构实现服务的开发和部署。

服务网关是连接客户端和后台的中介,它提供服务统一代理入口与调用分发,通过执行服务的路由和消费契约的方式,确保微服务垂直扩展。此外,网关也具备负责鉴权、认证、安全和跳转等作用。

服务监督与治理包括服务注册、服务配置、服务监控、负载均衡和日志管理。服务注册通过去中心化结构,使每个服务节点都可以提供服务注册和发现功能,有效防止只有一个注册中心由于故障而导致的系统风险,提高系统可用性[21]。服务配置提供应用配置与应用部署完全分离,实现在分布式环境下对微服务运行时所需参数的集中管理、动态调整和自动更新。服务监控提供在系统运行时对基础设施和微服务等性能进行监控,方便系统管理员根据微服务状态和执行情况进行系统性能参数的调优和日常运维。负载均衡实现对同一微服务的多个请求到该微服务的特定实例进行科学分配,提高服务的执行效率。日志管理通过日志分析,实现快速诊断微服务等发生故障后,迅速排除错误,提高系统的可维护性。

4 典型业务场景应用

4.1 典型业务支撑

以高速列车C2/C3等级转换场景为例,如图4所示,说明业务中台的应用。

(1)场景说明

高铁列车C2/C3等级转换业务完整流程包含列车C2等级部分模式发车、列车C2等级转完全模式、列车接收到呼叫RBC指令应答器信息和C2/C3转换预告应答器信息、列车接收到C2/C3执行应答器信息和列车C3等级完全运行等5个主要环节[22]。

(2)中台应用说明

本业务场景涉及业务中台的车辆IO信息中心、车辆信息中心、轨道电路信息中心、应答器信息中心和无线消息中心,通过相互协作能力组合应用对高铁列车C2/C3等级转换业务提供有效支撑。具体各环节场景及环节与中心对应关系如下。

①列车C2等级部分模式发车。

通过车辆IO信息中心的车辆输入信号服务和车辆输出信号服务获取驾驶台激活、手柄位置、制动反馈等信息;通过车辆信息中心的速度信号处理服务和列车位置计算服务获取列车速度、加速度和位置信息;通过轨道电路信息中心的轨道电路信号处理服务获取列车行车许可信息。

图4 中台在高铁列车C2/C3等级转换场景中的应用

②列车C2等级转完全模式。

列车在运行过程中,通过应答器信息中心的应答器信号处理服务,获取到线路坡度信息、静态速度信息、轨道区段信息和临时限速信息等,转换成完全模式。

③列车接收到应答器发送的呼叫RBC指令和C2/C3等级转换预告。

列车继续运行,通过应答器信息中心的应答器信号处理服务,获取呼叫RBC指令和C2转C3等级预告报文。通过无线消息中心的无线消息处理服务,获取与RBC交互的通信信息。

④列车接收到C2/C3执行应答器信息。

列车继续运行,越过C2转C3等级应答器,通过应答器信息中心的应答器信息处理服务,获取C2转C3等级执行信息,立即转C3等级。

⑤列车C3等级完全运行。

列车通过无线消息中心的无线消息处理服务,获取RBC发送列车运行的行车许可信息,以C3等级完全模式继续运行。

4.2 应用验证

在实际应用中,通过搭建实验平台对基于领域驱动与微服务框架构建的高铁列控仿真测试系统进行验证。实验平台如图5所示。

图5 实验平台

实验平台构成主要包括客户端程序、接入层、服务注册中心、服务配置中心、服务层和数据层。客户端程序是模拟列车在地面线路上运行轨迹的仿真程序;接入层主要实现身份鉴权和分发请求;服务注册中心提供服务注册和发现功能;服务配置中心提供服务动态配置和服务信息更新同步;服务层包括服务监督与治理、各种业务服务和公共服务;数据层包括重要的业务数据信息。

实验平台采用分布式部署,客户端程序运行在多个终端PC上,服务器A包括接入层、服务注册中心和服务配置中心。服务器B包括服务监督与治理和公共服务。服务器C包括业务服务和数据层。微服务协同工作原理如下:首先,客户端向接入层发送应用请求,经过接入层身份认证后,进入服务网关。服务网关读取数据请求,并从服务注册中心获取相关的服务信息,然后向服务层分发请求。服务层中的微服务根据请求调用数据层中的相关数据信息,在经过相应的业务逻辑处理后将结果返回给客户端。以高铁列车C3等级RBC移交典型场景为例,首先,用户在ATP车载设备端通过DMI启动任务开始流程(SOM),并经过身份认证登录后执行客户端程序。服务端经过服务网关读取客户端的数据请求,并通过服务注册中心获取服务层中的文件服务信息,向服务层文件服务分发请求,加载场景线路脚本文件和无线脚本文件,从数据层中获取线路轨道电路信息、应答器信息、无线消息等。通过执行服务层中的速度信号处理服务、应答器信号处理服务、轨道电路信号处理服务和无线消息处理服务后,通信服务将列车速度信息、应答器信息、地面轨道电路信息和无线消息发送给列车ATP车载设备。列车ATP车载设备通过用户操作DMI以C3等级目视模式发车,接收到RBC发送的线路坡度曲线、静态速度曲线和行车许可等无线信息后转成完全模式。ATP车载设备接收到应答器中RBC切换命令后,双电台分别与移交RBC和接收RBC进行无线连接。当列车最小安全后端经过RBC移交点时,ATP车载设备接受结束与移交RBC通信的命令终止与移交RBC通信,列车以C3等级完全模式继续在接收RBC管辖范围内运行。在此期间,客户端程序界面中能够实时回显列车经过的轨道电路信息、应答器信息、与RBC交互的无线消息、列车速度和列车位置等信息。

4.3 应用成效

业务中台应用在高铁列控仿真测试系统中能快速响应业务需求变化。此外,业务中台主要目标之一实现企业级业务能力的复用,将分散在不同业务场景重复建设的业务能力,沉淀到业务中台,实现业务流程融合和能力复用。综合上述的高铁列车C2/C3等级转换场景和高铁列车C3等级RBC移交场景分析,这两种典型场景多次调用图4中5个能力中心下的同一服务,不同的是根据列车当时的运行等级和模式,以及列车运行过程中调用相关服务接收到不同的应答器报文和无线消息,能够触发不同的业务场景处理流程发生。其他很多场景例如列车过分相等也是类似的处理。通过典型业务场景应用与分析,基于业务中台的可复用业务能力,有效地避免了软件重复开发建设,提升了信息系统的开发与协同效率,提高了系统的可扩展性和可维护性。同时,遵循“厚中台、薄应用”思想建设的业务中台,可根据新的业务需求和设计,在业务中台添加新的业务能力中心,也可以在既有的业务能力中心中添加新的服务,使得业务中台能快速响应业务需求变化,大幅提高系统开发效率,方便了系统的扩展和运维。

5 结语

高铁列控仿真测试系统涉及到大规模软硬件开发,且接口众多结构复杂。通过领域驱动设计和微服务的结合,设计出一种行之有效的业务中台模型。与传统单体架构针对业务全流程开发使得系统存在大量冗余功能缺点的不同,通过业务中台的可复用业务能力,有效避免了软件开发的重复建设,提高了资源的可重用性和信息的共享性,促进了信息系统的开发与协同效率,使业务系统能快速地响应新需求的变化,实现系统可扩展和可维护性。此外,采用本文提供的中台架构设计,在涉及到复杂信息系统业务中台软件建模方面提供了一种实用的解决方案。

猜你喜欢
应答器无线列车
基于Kriging算法的虚拟应答器捕获方法
城际列车
巧用应答器,提高小学语文课堂实效
大师操刀,通勤首选 KEF Mu3真无线降噪耳机
关爱向列车下延伸
《无线互联科技》征稿词(2021)
基于英标联锁的ETCS1级系统应答器设置简析
基于英标联锁的ETCS1级系统应答器设置简析
穿越时空的列车
温馨列车