52监测网
标题: 第三代桥梁健康监测系统与养护数字化 [打印本页]
作者: WYF 时间: 2024-12-11 08:47
标题: 第三代桥梁健康监测系统与养护数字化
国内桥梁监测系统已进入大规模建设的新时代。从交通运输部近几年的重要政策性文件可知，总体建设节奏为2021年至2025年，将长大桥梁系统建设完毕；2026年至2030年，进入中小桥梁监测系统大规模建设时代，其中城市生命线监测中的城市桥梁监测系统也作为重点建设项目。
既然桥梁监测系统建设规模近乎所有桥梁全覆盖，在下一步的中小跨径桥梁监测系统大规模建设之前，需要重新考虑监测系统的功能目标所能达到的层面。
不同等级的桥梁监测系统功能目标不同，针对长大桥梁监测系统，其目标是设计验证、损伤识别承载能力评估，以及某些参数最大值预警。而对于中小跨径桥梁，其设计理论比较成熟，损伤识别所需的传感器种类和数量不够，有些整体性的参数监测可用于评估，如车载数据作为整体量可用于承载能力评估，但不是全部所有桥梁都覆盖，应按需安装。
由于桥梁养护数字化是针对所有的桥梁，针对每座桥梁的整个生命周期，而安装大量的桥梁监测系统获取的数据能够指向桥梁养护数字化便成了系统建设内生性和必然性的功能目标诉求。
养护数字化是用可获得的数据做出科学养护决策，解决有限的资源如何在不同桥梁之间的分配。桥梁养护数字化通过有限资源的科学分配实现两个核心养护目标，即在整个路网层面降低桥梁安全风险，同时实现桥梁生命周期维修成本的最优化。美国将所有的精力放在基于人工的监测养护数字化上，而中国则将精力放在了健康监测上，这是两种不同的路径选择。
1、桥梁监测系统发展历程
第三代桥梁监测系统并不意味着技术比第一代、第二代更加先进，而是根据不同的技术特点所提出的。
第一阶段的桥梁监测系统（SHMS1.0）最早起源于香港青马等桥梁，后集大成于香港昂船洲桥。大陆许多单位曾经去香港取经学习。2000年代以后，大型桥梁在设初期基本都安装了监测系统，第一阶段的监测系统主要有以下特点：以单桥为主，重硬件系统集成；各个监测科目的采集软件比较独立；追求各种算法，模态识别、损伤识别等，颇有理想色彩或科研探索的特点；使用有线传输，组成局部数据网络；单个系统造价高。
总体来说，监测系统建成后运维无法跟上或没有运维，造成部分巨额经费建成的系统很快瘫痪。
第二阶段的桥梁监测系统（SHMS2.0）。这个阶段最大的进步是软件平台化，软件集成度很高。
其特点为：单桥监测转向了桥梁集群监测；设计理念为特定物理参数的最大值；重软件系统集成，轻硬件集成；软件适配性很高，可兼容各类的传感器，也可以使用无线传输；但系统的长期运营机制仍然没有很好的被解决，如一个大规模系统建设期花了两个亿，但其运维经费等于零，此类系统预算分配还比较常见；同时，在这个阶段标准规范制定工作得到了快速提升，但规范化也带来了照本宣科的效果，大量的桥梁监测系统设计得千篇一律。
2021年，交通运输部出台《公路长大桥梁结构健康监测系统实施方案》，推动了大规模的桥梁监测系统建设。从这时开始，桥梁监测系统正式划为第三代。到第三代后，不但总体规模变大，单个项目的规模也更大，由此也带来了几点疑问：
（1）大规模桥梁监测系统与小规模项目模式是否一样？
（2）硬件加软件就等于系统吗？
（3）一个实施单位能否包打天下？（该健康监测系统学科交叉较强，一个单位实施起来难度较大）
（4）几个实施主体同质化叠加，能否提升系统质量？
（5）围绕项目建设和运维的技术生态如何？——生态指的是大规模系统后续是谁来开发和运维，谁来使用和分析此类数据？
（6）大规模系统的项目管理如何？是否能出现一个标杆性的项目？
2021年，我们提出了第三代监测系统的概念与模式，6月底到各省区交流，得到了很好的反馈，如某交通运输厅的124座桥梁要搭建该系统，建设规模较大，就此提出了很多问题。2022年1月底，我们设计出了体系架构方案，并基于某省高速集团的反馈和交流，将第三代系统打磨到可落地实施的层面。
曾经调研某高速集团100座桥梁监测系统，该项目业主下属公司负责施工图设计，桥上设备安装分成5个包分别招标。我们也得出几点疑问：
（1）布点图都只是针对桥梁上硬件，不等于系统，整个项目体系架构该如何搭建以及如何进行管理？
（2）系统建设和长期运维是谁作为责任主体？
（3）在分别招标的方式下，软件平台使用谁家的？
（4）后续运维经费从哪里来？
（5）如此大规模系统，从设计、项目管理到数据分析，能否使得监测系统有技术上实质性的提升？
2、第三代桥梁监测系统
（1）关于模式和技术生态。首先第三代针对大规模系统建设，从方式上看，首先要提倡技术分工深化，要充分利用行业技术潜能。其次，专项数据的集聚会形成数据经验，这是隐性的知识，如某个单位只做模态，其必然有隐性知识，这是无法学来的。同时，围绕大规模项目号召起来庞大的技术生态，系统规模越大则生态越庞大，项目才能够真正用的好、建的好。此外，系统具有很强的弹性，规模越大效率越高。由此带来一个想法：如果进行社会分工，是否能提升效率和质量？如果波音787都可以采取这种方式来进行制造，桥梁监测系统建设是否也能基于这种模式？
（2）关于体系架构。如果实现上述模式，项目不同业主需求不同合作主体不同，系统体系架构则会发生变化。体系架构可调，是根据项目实际情况而设计，体系架构支撑技术生态，如某省高速集团桥梁最多，可以将企业内部的监测数据中台搭建到省平台上，并将所有省内数据映射到部平台中；而另一个省除了高速集团以外的业主桥较少，其他业主则可以将桥梁监测委托给省高速集团，这两种体系架构不同。此外，还有一个项目，某城市桥梁监测项目针对全市450座桥梁，业主把桥梁监测系统分成15个标，每标段30座桥梁。业主要求所有数据必须使用智慧大脑分析，但智慧大脑平台中没有桥梁知识。为此，我们提出了另一个体系架构，15家实施单位都有自家的监测软件，每家都不一样，因此可将智慧大脑当成数据底座，从而形成分布式监测，纳入所有标段承包方对数据的挖掘能力，而不是只用智慧大脑统一性解决。某央企集团投资运营的高速里程为4000-4500公里，包括4000-5000座高速桥梁。首批项目规模为4座桥梁监测系统，我们设计了如下的体系架构。在桥梁监测系统设计中，将各地区桥梁监测数据传输到项目所在省份的桥监测省级数据平台，同时将数据存入集团总部服务器中，这样来看其体系架构与各省高速集团又不一样。总体来说，第三代监测系统的体系架构可按项目需要可调。
（3）项目管理。有个案例，某高速集团计划投资1.4亿元，建设70座桥梁的监测系统，并交给了业主下属单位，但下属单位是很难管理好如此大的项目，因此，我们为其提供了一个系统化的建议，并列出了需要解决和分析的问题（如下图），只有把这些问题一一解决好，才有可能将项目管理好。
（4）关于技术特点。第三代模式有几项技术特点：首先是赋能，我们希望找到能够承担项目的业主下属单位，或以当地企业为主导，辅助当地企业从无到有打造起桥梁监测业务，监测系统归当地企业所有，并为业主提供监测服务，最终完成对运维生态的建设。其次是生态，所谓的生态就是专业单位做专业的事情，实现专业分工深化，通过模式创新解决以往监测系统中存在的各种问题，并整合业内优势技术资源实现监测系统技术水平的显著提升。此外，第三代适合大规模桥梁健康监测系统建设，体系架构弹性很大。最后是数字化，以桥梁监测系统建设为契机，以清单中桥梁为应用示范，建立面向全部桥梁的数字化管养系统，构建桥梁养护管理的数字化体系。（5）几点结论。第三代桥梁健康监测系统的出发点是在现有的产业和技术条件下，通过项目模式的重新设计，把大规模桥梁监测系统尽量做得好一些，但还不能从根本上解决数据有用性（效益大于产出）。目前的长大桥梁监测系统还未能指向养护数字化，大桥主要是对整体量的监测，数据分析结果往承载能力评价层面应用。
--本文部分资料来源于网络，如有侵权请联系删除--
| 欢迎光临 52监测网 (http://bbs.52jiance.cn/) |
Powered by Discuz! X3.2 |
