最近正好在推进一个水利数字孪生的项目，相较于过去做的智慧城市类的数字孪生类的项目主要侧重于可视化的效果，这个项目则更加趋向于专业和严谨一点儿的应用，不仅仅要集成一些专业的水动力模型，其中还需要集成一些专业的GIS空间分析能力，也正是由于之前做了很多偏可视化的弱GIS类项目，导致最近团队成员都在恶补之前遗忘的专业知识。正是要集成这些领域的专业能力，也导致了水利项目的开发复杂度要远高过去数据驱动类型的数字孪生项目，其核心的差异体现在如下两点：
1、从专题数据展示到交互式控制，在智慧城市或者智慧工厂类的数字孪生主要还是以数据集成可视的产品形式为主，就像我们在项目中经常会遇到的一个问题「数字孪生要不要反控设备」，绝大多数情况下，从安全的角度出发得到的回答都是「NO」，但是在水利「四预」的场景下，就包含了一个交互性很强的「预演」场景，在这个场景下，就是需要能够具备支持多调度对象和多样化调度方式的“正算”与“反算”的模拟，在孪生的场景中找到最优的方案，在这个过程中就会存在对很多孪生要素的控制、修改以及计算，并生成该方案的影响评估，这是一个虚拟计算的过程，这也是数字孪生在水利业务中最直接的应用价值。2、数据单一方向流动到多要素之间数据双向流动，在智慧城市类的数字孪生项目中，为了利用渲染引擎的渲染能力，其实我们只需要将各种异构的数据单向处理城渲染引擎能够支持的格式就可以，这里面比较代表性的就是GIS+BIM+IOT的数据格式，所以这种能够支持单向数据接入的插件就称为了主要的产品形态。但是在具备「预演」这个交互的应用场景下，问题的复杂度就会立马上升，由于存在计算反馈的要求，就会导致两方面的诉求：第一、场景单一要素本身要具备正反向的反馈能力，给一个输入就要对应的得到一个输出，所以这里面还是之前的老生常谈，从「底图」到「算据」，我们构建高精度的孪生底板的目的不仅仅是为了看的更清楚，他更多的还是要作为算法的数据支撑，比如DEM过去更多是配合影像叠加做出更好的可视化效果，但是在计算的场景中，高精度DEM就是很重要的一种输入数据。对于我们常用的倾斜三维其实也是一样的，倾斜三维由于具备更多的细节，但是在计算的时候还需要将倾斜三维再转换为算法能够识别的格式，一起作为模型的一个输入进行参数的计算，在防洪方案确定的时候就又需要在这个三维场景上去调整以及搭建防洪的水利设施，从而来进一步影响演算的结果；
第二、场景多要素之间要相互进行计算，这也就要求这些要素之间要能够实现数据格式的相互转换，才有可能实现对其他要素算力的使用，所以在这个动态交互的过程中，就会发现问题的复杂度上升了，过去的用于支持单向互通和集成的一些产品在需求支持上就显得功能偏弱了，在场景上可能是个简单的「选择和确认」，在背后就是涉及到一些跨引擎的计算，其实在这个过程中还有非常多的工作要做。在水文领域不是所有的模型都是二维的水动力模型，还有很多其他类型的水文模型，还有很多梳理统计的经验模型，比如在游戏引擎里面通过平均比降法得到的水面数据，视觉上可能已经能够比较直观的看出哪些区域肯能会被淹没，但是如果定量的进行灾损的预估就需要利用空间的分析方法进行淹没涉及的人口和房屋进行计算，这就需要将当前的游戏引擎中的面转化为GIS中的数据模型，再利用GIS的一些能力进行计算，从而再将GIS的计算结果转换到游戏引擎的场景中进行可视化出来，这个路径其实来说还是稍微有点麻烦的。当然这是表象，纠其背后的原因就是：当前的融合主要是以「可视」为出发点，但是并没有以「可算」这个出发点出发。当然这也是在新的场景下得到的新的孪生需求，过去的场景下这类需求其实是不强的，现在我们为了解决水利的问题，需要将客观世界的「机理和规律」搬到数字化孪生场景中。过去新势力的数字孪生厂商在弱GIS场景上，从「可视」出发，可以说给传统的GIS厂商造成了很大的冲击，但是在水利数字孪生这种专业的场景上，对于数字孪生的要求不在仅仅是「看着好」，更重要的还是要能够「算的好」，所以传统专业GIS厂商可以说还是具备一定的先发优势，阿里在水利的解决方案上也提到了「视算一体」的概念，但是目前还没有看到具体的细节，听说后续会有论文出来，「看」和「算」需要一种更好的兼容方案出来。第一，从数据的角度出发，构建「看算一体化」的统一模型，这个概念其实很类似过去GIS领域提的「矢栅一体化」的逻辑，但是这种「***一体化」的东西其实很难做到一统江湖的作用，牵涉到的东西太多，对存储、算法以及可视化都需要支持和重构，我读书阶段的一个研究方向就是全球离散网格，希望通过从数据模型的角度，在全球这个尺度上实现GIS模型和数值模型的底层数据模型的统一。第二，从计算的角度出发，让算法适配到当前的可视化模型，这种方法就是将很多计算搬到前端上来，直接在当前的可视化模型上进行算法的实现，比如现在也有很多三维GIS的引擎是支持直接在可视化前端使用前端的数据进行空间计算，但是通常会出现一种情况就是，比如这种空间分析只能够支持倾斜的空间分析，但是不支持矢量切片格式的三维白模的空间分析，所以就要求算法也要能够适配到当前的可视化格式上。第一、当前的可视化数据结构并不是很严谨，比如现在可视化数据模型为了便于前端的调度都被切片了、简化了，所以数据本身也是不严谨的。第二、前端的算力也不一定能够支持，对于一些简单的分析尚能能够支持，但是对于比如水利这类水动力模型，计算其实是比较复杂的，通常都需要对算法进行并行化以及GPU利用改造，对于规模更大的还需要超算的资源来支持。但是同样存在一种可能，比如现在GIS数据接入游戏引擎就是通过插件的方式来接入的，现在类似低代码这类的场景制图功能其实也集成进来了，那对于一些算法是不是也可以通过类似ArcToolBox这种工具集的集成进行实现？对于一些数据管理的能力是不是也可以同样集成进来？以游戏引擎为例，未来的这些数据管理、算法能力都会以插件产品的形式接入到这个大生态中，用户只要根据自己的需求对一些专业的模块化进行付费就好了，大家也可以根据自己的需求组装出一个符合自己需求的数字孪生产品，这样一来每家其实都是在维护好一个自己专业的能力，然后构建好自己与游戏引擎这个大生态的连接就好了，这种模式的核心就是就是将视和算的 入口统一到游戏引擎这个体系下来。在这一点上其实也很类似Visual Studio Code，做好一个轻量化的编辑器，其他语言以及开发的支持都以插件的方式集成进来。数字孪生看不是目的，能够辅助支持决策才是价值，而支持更好的决策，「预演」则是一个少不了的过程，而这个「预演」的过程既需要看也需要算，而且需要实时的反馈。而数字孪生则恰好是实现这个目标的一个路径，所以「孪生不是终局，孪生只是路径和手段」，而孪生一定是发展的，因为解决这个目标需要更多、更好的方法以及手段，而这些方法和手段都是孪生需要涵盖的内容。其实我本质上觉得，不存在一个产品叫「数字孪生产品」，「数字孪生」应该是解决一类问题的方法的抽象统称。就像水利数字孪生，「四预」是2+N应用的构建范式，而实现这样专业的范式底层就需要构建全要素的算据、专业的算法、强大的算力。而水利行业总结的这套「四预+数字孪生」的应用构建方法其实在很多条线都有很好的参考意义。过去的数字孪生注重的是「表」，而这个阶段的孪生则要注重「理」，最终要实现的目标肯定是「表理如一」。
