IoT数字孪生平台建设

IOT数字孪生

数字孪生的概念简单的说，就是把真实的物理设备，映射到虚拟的数据模型，再将数据模型通过建模（或者其它）的方式直观的展示出来。

整个流程抽象后可以区分为：

设备信息采集 -> 数据流转 -> 数据模型 -> 前端建模与展示

AWS中这部分称为 Connect 、Model 、Compose

我们如果需要建设数字孪生平台，那么就需要尽量剥离业务属性，尽可能的抽象通用的功能。而剥离业务属性，并不代表完全交给业务实现，而是提供标准化的接入方式，和完善的工具，来帮助业务构建业务属性。

数据流转（Connect）

原始数据到模型数据的转换，定义了从设备采集到的数据，到数据模型数据的转换规则。可以认为一个过滤器，对原始数据做过滤和处理。

数据模型（Model）

数据模型定义了格式化后的的虚拟数据结构，代表了真实设备在数字化之后的展现形式，是对原始数据的二次整理和组合。 一般是在数字孪生系统中的最小展示单位。

前端建模与展示（Compose）

经过数据流转数据模型的定义后，这里负责定义怎么将数据模型进行展示，即数据模型与前端展示的映射。最终输出可能是数据、图表、3D模型等。

通过以上三个步骤，则将整个数字孪生的定义进行了标准化，流程标准化之后，则是接入方式的标准化，在数据流转、数据模型配置、前端建模中，每一步都涉及到业务属性，而平台需要做的则是将其中所有的业务属性解耦，通过平台提供的工具来导入或生成对应的配置。

要建设完善的数据孪生平台，尽可能的简化业务接入流程和工作量，最主要的是平台工具的完善，一个最基础的数字孪生平台，我认为最少需要有上面的4类工具或功能：

• 数据转换定义，如何快速的将各种不同的设备数据，转换为平台所需要标准化数据是十分重要的一个功能，这里要考虑的是如何兼容各种数据入口，以及标准化数据格式的定义
• 数据处理API，在标准化数据之后，由数据处理API对数据做过滤或处理，理论上平台需要支持简单的脚本功能，以及允许接入外部的扩展服务（通过标准的输入输出）
• 模型定义，定义数字孪生的最小化模型的schema，和物模型类似，需要考虑到模型的复用
• 模型映射，前面都是数据的处理，那么模型映射需要最终的数据，转换为对应的图表或3D模型，这里理论上需要提供功能完善的建模工具，通过建模工具，创建对应的图表或3D模型，并且关联到对应的数据模型上。

AWS在这里提供了功能很完善的建模工具，并且支持将CAD输出的文件直接导入，复用。

一个完整的业务接入流程应该是：

数字孪生价值

AWS中将数字孪生定义为4级，每一级都带来更好的业务价值

L1 Descriptive

很简单，Descriptive，即数字孪生仅仅只是描述真实的设备情况，比如将工厂、办公楼内的各种设备的信息，直接通过图表、3D模型的方式进行展示

L2 Informative

相比于L1，它会提供简单的信息过滤和处理，来获取更的价值信息，比如通过办公楼内的各种传感器、灯、屏幕的状态数据，在经过处理后，可以展示更详细的且更有价值的模型，如平均温度、上课状态等，而通过这些处理后的数据，可以反向的影响真实设备，比如在时间段内平均温度过高时，打开空调。

L3 Predictive

预测，引入算法模型，对数据进行更深度的处理，来根据历史数据，对未来数据进行预测，用于后续的决策的数据依据。比如对整个办公楼的历史设备使用情况、办公室利用率等，预测后续的相关数据，对采购或办公楼建设做决策依据

L4 Living

这个在AWS中被认为是最理想的数据孪生形式，符合数字孪生的完整定义。Predictive是使用历史数据来创建预测模型，但是在长时间的运行后，由于训练数据的时效性，准确性会持续下降，与Predictive相比，L4可以自升级，将源源不断的设备数据，作为训练数据来升级模型，而后提供更准确的预测数据。