2023 IoTDB Summit：北京城建智控科技股份有限公司高级研发主管刘喆《IoTDB在城市轨道交通综合监控系统中的应用》...

12 月 3 日，2023 IoTDB 用户大会在北京成功举行，收获强烈反响。本次峰会汇集了超 20 位大咖嘉宾带来工业互联网行业、技术、应用方向的精彩议题，多位学术泰斗、企业代表、开发者，深度分享了工业物联网时序数据库 IoTDB 的技术创新、应用效果，与各行业标杆用户的落地实践、解决方案，并共同探讨时序数据管理领域的行业趋势。

我们邀请到北京城建智控科技股份有限公司高级研发主管刘喆参加此次大会，并做主题报告——《IoTDB 在城市轨道交通综合监控系统中的应用》。以下为内容全文。

目录

城轨交通工业物联网业务概览

云交自动化系统数据处理架构

IoTDB 在城轨系统融合场景的实践

城轨交通工业物联网展望

各位专家、各位与会的嘉宾，大家下午好，我是北京城建智控科技股份有限公司的高级研发主管刘喆。下面由我来给大家分享 IoTDB 在城市轨道交通综合监控系统，就是一个类工业物联网的应用场景下的应用。

我的分享包括这么几块：首先是城建智控轨道交通工业物联网业务的概览，这里主要包括两方面，一块是我们针对车站相关设备的监控系统，我们叫云交自动化系统；另一块是针对信号的，我们正在研发中的云信号系统。其次，在这样一个业务的基础上，我会简单介绍一下我们这种云交自动化系统，它的数据处理的架构。它整体上是一个类工业物联网的体系，但是它会有我们轨道交通的一些特点，对安全性、对冗余性、一些突发事件的响应，这对我们实际在使用 IoTDB 过程中提出了一些新的要求。第三部分，我会讲一下 IoTDB 在我们这个城市轨道交通系统相应的融合场景的实践，我们具体怎么去用的、性能的评估、以及使用的效益。第四部分，我会简单讲一下城市轨道交通工业物联网的展望，尤其是在我们云信号系统，它的这样一个数据融合决策支撑中，IoTDB 将会扮演什么样的角色。

01

城轨交通工业物联网业务概览

首先讲一下城轨工业物联网的业务概览。我们城市轨道交通其实是一个相比其他行业，可能在数字化、信息化方面相对有些落后的行业。今年城市轨道交通协会也提出了“多元融合、可持续发展”的理念，这样一个理念是希望能够用智慧的一些技术去赋能我们的绿色城轨，在九个大的板块去提升我们整个行业的智慧化的实践。具体过程中就包括引流、增收、降本，而在降本这一块，是我们作为轨道交通智慧解决方案提供商的一个重要的努力方向。

那么在城市轨道的弱电系统，它面临一些问题，这也是我们跟行业协会、跟相关的业主去共同沟通，归纳出来的一些痛点。这些痛点包括：硬件设备的种类特别的多，那建设运维就导致成本很高。这里不光是它的土建，包括拆迁的成本，还有后续设备投入的成本、系统的投入成本都很高，设备的用房很大，能耗也高。基于这些痛点，我们现在的一个行业趋势就是做硬件共性的整合，像类似的一些硬件，在不同的专业里面，我们通过云计算、虚拟化的一些技术做相应的资源整合。

痛点二就是各个系统在传统的相对封闭的建设模式下，它各个系统是独立的，系统间的联动都是依赖完全定制化的接口，这就导致我们想做一些智能化的、跨专业的场景的时候非常的困难。那么我们就需要对专业进行融合，要采用架构相对统一的一套软件平台去支撑我们轨道交通的智能化的建设。

痛点三就是传统的建设行为，它是单线路、单中心去做建设的，比如说我上了一号线、二号线、三号线，可能每号线的系统、厂家、运营的班组都是不同的，这就导致重复建设；甚至设备的品牌类型也是不一样的，它的管理和运营成本也会越来越高。后续我们想做跨轨道交通，跨地铁、高铁与快轨的这些不同制式的轨道交通融合的时候，困难也非常大。那么这里就需要我们建立一控到底的线网的轨道交通指挥系统。

第四个痛点就是，既有的一些装备、设备，它过于的传统老旧，它不适用于我们现在智能化的需求。

结合这些痛点和我们的行业发展趋势，我们城建智控公司就提出了基于云计算的安全可靠的轨道交通自动化系统，也就是云交自动化系统。云交自动化系统其实是我们相对传统的城轨行业，面向工业 4.0 的其中一个答案。我们会在这样一个系统里面采用很多工业 4.0 的理念、技术、架构，这里面当然也就包括 IoTDB 来组成这样的系统，从各个层级去对我们的数据化资产进行管理、表达；从设计、建设、运营、服务全生命周期，对我们的城市轨道交通的系统业务进行重构和优化升级。

在架构上，可能与会的嘉宾都非常熟悉。这是一个比较典型的工业物联网的架构，它整体是符合我们对工业物联网的认知的，只是在具体的一些业务层面，会对我们的轨道交通做相应的定制和实现。比如说我们在 IaaS 层会提出一体机的架构，这是符合工业化的设计，实现高密度的一些集成。在应用层面，我们会针对轨道交通，有运营、维护、服务等相应的一些定制化的服务。

那么在云信号方面，其实它也是在解决我们轨道交通的信号系统的相应的问题。除了有共性的设备分散、种类繁多、运维难度大，融合的系统类型多、成本高的这些问题以外，信号系统还需要考虑的是安全方面，尤其是随着智能化的提升，相应的信息安全的要求是越来越高的。车载的设备它也受限于它的性能、工作条件，按传统落地的设备智能化升级的思路去做，会遇到很多的问题，这就需要我们去强化通信安全的管理，还有精简我们车载的各种设备应用的执行功能，这也是我们提出这样一个云信号系统的契机。

智控公司其实从一四年开始，我们就在做这样一个安全可靠的轨道交通信号系统的研发，逐步地去拿下了包括地铁、有轨电车等等项目。在今年的十月份，我们的全自动运行系统也拿下了欧标的最高安全等级 SIL4 等级的认证，后续也会在一些市域铁路、在更多的工程中去做应用。

我们的云信号系统，它其实是以一个“下地·上云”的底层逻辑去对我们的系统进行重构的。“下地”就是指传统车载中，受限于它的运行环境，性能也很受限的这样的情况，我们让里面的一些算力逻辑去下放到地面系统，减轻我们对车上设备的依赖。那么“上云”就是再把进一步更多的计算上到我们中心的云平台，通过各种通信安全的保障，保障我们的实时性和安全性，并做资源的进一步整合，构建从线网控制中心到执行终端的新一代列车运行控制系统。

02

云交自动化系统数据处理架构

以上就是我们智控公司在轨道交通的类工业物联网场景下的两个主要解决方案，即云交自动化系统以及云信号系统。下面我简要讲一下云交自动化系统在数据处理方面的架构，以及它在各种场景下需要面对的一些需求和挑战。

首先是系统融合。系统融合方面，轨道交通行业在协会的大力推进下，我们在积极地推进传统系统的上云，但这里面上云不单只是中心云，我们其实更多的推的是中心云与边云结合的这种分布式云，这是为什么呢？因为可能之前也有一些纯中心云的案例，但是当它发生中心云与车站断联，或者一些故障的情况下，车站的业务是会降级甚至不可用的，这就给轨道交通的运营，尤其是给市民的出行带来很大的困扰。

基于此，我们现在的行业里面更有共识的一个解决方案是分布式云，也就是说我每个车站其实都是一个小的边缘云，而所有的车站在线路、线网层面再组成一个大的分布式云。整体我们资源是有一定的共享和调配的，当某个车站与中心断联的时候，它自己的车站云能够支撑本车站的一些业务的应用；而当车站的边缘云故障的时候，它相邻的车站边缘云能够做临站的接管。通过这样的模式去提高我们整体分布式云的可靠性和可用性，去满足我们轨道交通对服务的更高的要求。

那么在这样的场景下，其实对我们的硬件、软件服务以及我们数据处理的模式有了不一样的一些需求场景。在硬件方面，我们现在是结合硬件融合的这样一个趋势，引领行业研发了智能控制一体机。在我们之后，其实也有很多其他厂家也在陆续推出相应的一体机，而我们是最早提出来的。这种一体机它其实有点像我们在中心机房里面用的刀片服务器，但它的特点就在于它是一种工业级的设计，去满足我们车站的要求，即基于机房所提供的相对没办法达到这么高的环境下的运行条件，包括抗干扰、低功耗，还有对轨道交通运行过程中振动的一些适应等等；包括它对冗余性的一些安全的要求；对于我们工业的各种设备接口的扩展，它通过各种板卡可以去扩展对工业设备硬件的接口；还有就是资源调度的一个很强的能力。通过这种智能控制一体机，我们去支撑刚刚说的车站，我可以非常快速、低成本地搭建一个小的边缘云，而整体又可以作为一个大的分布式云的场景。

在具体设备接入方面，除了有一些扩展性的网关去直接对接设备，我们也研制了相应的机电控制单元，对我们车站里面的风机等设备做感知端的接入和数据的采集，就可以满足我们就地控制的一些实际的工业要求。针对像消防这种有特殊安全要求和认证要求的场景，我们也针对性地研发了消防一体机，它是要通过对应的一些消防安全的认证，满足比如耐火等特殊的一些要求，去接入相应的消防设备，也是集成了我们边缘的消防终端，通过这样一种标准化的控制单元去替代原来可能多个的主机，可以减少我们车站 80% 的占地面积和 60% 的能耗。

除了在硬件层面的一些配合以外，我们在软件层面也是引入了现在比较火热的微服务的架构和技术，去对传统单专业重复的服务去做重构。像配置、监控的一些模块，我们去抽象成通用的服务；对应的像扣车、计费的一些模块，我们去抽象成专用的服务，这样就组成了我们的服务池和应用平台，去支撑各个专业实际的业务。同时，新的一些业务，包括像智慧车站、智慧城轨的自动化、一键开关站的很多服务，就可以直接在我们微服务的接口上去做开发，大大减少了传统意义上我们可能为了开发一个智能服务，需要对接五六个不同专业，而且很多都是工控专业，开发效率非常低的情况。

通过这种软硬件的融合，我们原专业的大量的硬件、软件设备就可以做一个整合。这里列举了我们在轨道交通常见的一些专业，其实每个专业都会有自己的服务器、存储设备、网络设备、安全设备，这些都可以通过上云和上我们这种工控级的一体机的模式，去精简它的硬件设备的数量，降低我们建设和运维的成本。这里举一个例子，我们对于某一个车站，如果采用我们这一套方案，它可以减少各个专业它自有的设备室。考虑到像地铁这种轨道交通，它的建设用地的征用、拆迁，还有土建的施工成本非常高，我们其实是有一个很好的减轻用房和能耗的经济效益。我们也知道各地的这种市政的预算并不充足，以后轨道交通运营的经济压力也会越来越大，这种更简化的运营成本其实是很受业主的欢迎的。

那么上述这些软硬件的融合和变化，其实对我们传统轨道交通行业的各个专业，它的系统是有相应的革新的。在实现了上云和硬件融合的改进以后，对我们相关的专业，包括 BAS，就是环境控制的专业来说，它会使得资源更集中，运维的成本更低，有更强的扩展能力，也有更快的控制能力。利用这种车站，我们有车站云的更强的计算能力，还有分布式云的资源调度的能力，就可以处理很多传统业务处理不了的问题，包括利用 AI 、大数据等 IT 工具，对我们采集的设备数据做相应的一些智能化的分析，比如去做能耗的、节能的分析，实现我们绿色城轨的这样一个愿景。

除了前面说到的设备的融合，在它的基础上，其实我们也在推进进一步的、更大范围的整合。传统意义上的轨道交通其实是四级的控制架构，从就地的设备层级，到车站层级，再到线路层级，最后到线网层级。这种四级的控制架构，它的实时性以及系统的重复建设是非常不好的。通过我们统一的线网级的系统，我们在逐步地推行三级架构，甚至二级架构，就是去掉线路中心，也就解决了我们前面说到的一个线路、一个班组、一个厂家、一类设备重复建设，以及高昂的运营成本的问题。同时，当新线需要建设、需要扩容，比如说我已经建了三条线，我要扩第四条线的时候，通过这样一个线网级的平台，而且是基于云计算这种虚拟化技术的平台，我们只需要去扩展我们的 IT 资源，就可以去支撑新线的运营，大大降低了系统的建设运营成本。

在具体的线网层面，它的运营就不再是传统的，因为有这一套设备，所以我要配这一套人员，而是我的设备、系统都是同一套，我的运营人员是根据实际的运营模式，去做逻辑上的、软件层面的权限配置，去支撑多种运营模式不断地演进过渡，就大大提高了我们运营人员配备的灵活性。通过这种一岗多能的综合运营，也可以降低我们对运营人数的要求，降低运维的成本。

03

IoTDB 在城轨系统融合场景的实践

前面的系统融合场景其实讲到了我们轨道交通的大趋势，在这样的趋势下，其实我们采集的数据量、设备的智能化程度，以及基于云以及分布式的模式以后，在线网层面数据的一个更大范围的汇聚，都对我们数据的存储、分析、查询有了更高的要求。这也是我们智控公司和清华联合去引入 IoTDB，在我们轨道交通系统里面用的一个契机。以下我简要说一下 IoTDB 在我们系统里面的使用方法、性能评估以及效益。

我们的系统其实有大量很典型的物联网的数据，包括车辆、信号的安全产品的联锁、电力的、火灾的、机电等相关的设备所产生的变位数据，这是典型的物联网数据。我们设备操作的事件、用户操作的日志、设备的报警数据，这些其实也是泛物联网的数据。针对这些数据，我们要进行比如说单设备的最新点查询、时间范围的筛选、聚合统计、多值筛选、对齐查询等等，其实这些都是典型的时序数据库的一些场景。

当然也有一些可能跟标准的 IoTDB 场景不太一致的地方，包括我们的车站中心、线网中心数据同步的场景，在 IoTDB 里默认应该是支持多对一的数据同步，但在我们这个场景里面，我们在车站会设主备服务器，主备服务器之间要做数据同步，而车站和中心之间我们有多中心，中心内部再有主备的一些服务器，相当于它是需要做多对多的数据同步，来保证我们系统的高可用，以及同步之后一旦发生问题，它需要有数据回补等机制。这些是原生的 IoTDB 不支持的，所以需要我们在实际使用过程中做一些相应的定制研发。

这是我们原来的技术架构。在最早的版本里面，我们其实采用的是 Cassandra 作为我们中心级、线网级的数据存储的数据库；在车站端，我们是采用了国外的驱采软件配套的数据库，做临时的本地存储。那么 Cassandra 它本身的性能和压缩能力，以及对资源的使用，作为上一代的数据库，相对性能会差很多；而采用国外的驱采软件，它对应的售价也非常高，就导致我们项目实施成本很高。引入 IoTDB 以后，我们就将原来的 Cassandra 用 IoTDB 进行替换，得到了一个比较好的性能效果，也节省了我们的资源。在车站侧，我们就根据不同的场景去采用 MySQL 或 IoTDB，进行原来国外组件的实现。

在数据模型层面，虽然我们是典型的物联网的数据，但因为我们使用的方法有一些我们自己的特殊性，所以我们并不完全是采用 IoTDB 原生的树模型。在使用过程中也根据我们数据查询的特点，对查询效率的一些要求，还有跨设备查询的一些场景，我们也做了好几版模型的演变。右边其实就是我们因为要进行一些跨设备、跨车站的查询，对时序数据的层级进行了精简。原来可能是多层级的时序，现在我们会精简为单时序，这样避免了旧版本在做这种跨设备查询的时候的性能问题。

针对“多发多收”的数据同步场景，我们也是做了自己的定制，就实现了车站间可以做主备的双向同步，而车站又可以对多中心的多个节点进行同步的模式。如果遇到了数据同步失效的情况，还可以实现自动回补，通过这样一个模式，就可以满足我们对分布式云的数据同步的要求。在具体的车站场景上，我们不纯粹是单时序的查询，涉及到很多跨时序的查询场景。这里我们是根据实际的测算，去选用具体的 MySQL 去支持相对跨设备的查询，同时基于 IoTDB 去做单设备的、高性能的查询和存储。

具体收益方面，通过针对中心和车站相关系统进行国产化数据库 IoTDB 的逐步替代，我们现在实现了关键系统不再被国外系统卡脖子。自主化以后，我们现在有跟清华深度的合作，所以很多问题其实都可以自主化地去解决，去做实时性、可靠性、安全性的深度分析。相较于传统的时序数据库，我们的资源占用降低了 60%，查询性能提升了 120%，能够支撑轨交每秒百万级数据存取，使用的实时成本也有了大量的节省。

当然，在实施过程中我们也遇到了比较多的困难。早期我们应该是在 IoTDB 的 0.12 版本开始使用的，在我们不断的落地测试和应用过程中，有一些问题在逐步解决，包括非顺序的数据存储过程中，有数据崩溃的一些问题；数据同步、定制研发方面的问题；内存使用和资源回收方面的问题；还有多值筛选下的一些数据查询性能的问题。这些问题随着我们和社区不断的沟通和协作，都在逐步的解决，这也是我们现在很看好 IoTDB 在我们轨道交通场景下进一步应用的很重要的原因。

04

城轨交通工业物联网展望

前面提到了 IoTDB 在我们类物联网的云交自动化系统的应用，我再简单讲讲后续在云信号系统，我们希望 IoTDB 在里面发挥什么样的作用。

云信号其实目的是控制车辆，控制车辆其实对我们的要求会更高，这也是我们暂时还没有完全将 IoTDB 落在这个信号系统里面的一个原因。信号系统其实对自主可控、高安全、低时延、确定性的要求，以及对决策、执行、简化这些能力的要求，其实是比我们刚刚提到的云交自动化的场景更高的。那么在这个过程中，我们需要建立统一基础平台，这个平台将部署在异构云上，并必须要通过欧标的最高安全标准，这里面有很多的挑战。在异构云上我们要部署 IoTDB 的话，对它的安全性、确定性也有很高的要求，而前面提到的在早期版本里面的内存回收，或者是一些数据崩溃的情况，这些都是我们现在在谨慎评估和需要解决的一些问题。

在具体的通信层面，我们也跟很多不同的厂家、高校去合作，去解决我们上云以后通信的实时性和安全性的问题。在精简执行指令上也进一步去落地我们“下地上云”的理念，把算力去做重新的调配。

数据融合决策这方面，是我们希望 IoTDB 能够发挥更大作用的地方。列车的运行现在已经开始逐步的无人化、全自动化，我们也研发了自己的全自动化的列车运行系统。但实际的落地中，其实现在司机还是需要有一个，要么是在列车的司机室做监督，或者是在中心进行远程监控。随着我们自动化能力的提升，后续要逐步真正实现无人化，需要我们更多的去用数据处理融合决策的能力，使我们信息的循环、数据的融合、自主的决策有更强的安全性和智能性，来保障我们以乘客为中心的安全、舒适、便捷、高效的智慧出行服务。这部分我们现在也在积极地适配车辆的相关数据，对 IoTDB 进行压力测试、安全性测试和可靠性测试，后续应该会有更多的应用。

以安全为基石，用软件定义硬件，通过数字化铸就自主决策，打造绿色智能可持续发展的新选择，这是我们城建智控公司的愿景，也希望我们能和 IoTDB 一起，携手在城轨的工业物联网实现更多、更广、更深度的应用。

我的分享到此结束，谢谢大家。

可加欧欧获取大会相关PPT

微信号：apache_iotdb