NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - AI模型在线查看 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割 - 3D道路快速建模
我们在之前的报告中已经触及了与数字孪生相关的各种数据类型和相应的企业系统。这可能涵盖从连接到数字孪生原型的 PLM 系统到通过数字孪生实例连接到物理车辆的自动驾驶机器学习系统。以目前的专家观点，我们希望专注于我们经常从企业和物联网架构师那里听到的问题：哪些数据应该存储在孪生体中？
为了调查这个问题的明确答案，我们想提醒我们的读者数字孪生的最初目的。它是一个物联网架构元素，它使软件程序能够与物理产品对话——无论产品是否实际在线——或者在双原型的情况下，物理产品是否已经存在！以下是一些说明挑战的示例：
- DTP 示例：CNC 制造机器或机器人可能会要求制造过程中的“零件”告知其客户的具体变化。因此，数字孪生很可能不负责管理基本 CAD/CAM（计算机辅助设计/制造）数据并将其传输给机器人。机器人可以将这些指令作为生产线的一次性配置获得。但是，数字孪生应该包含客户特定的变化。这可能只是与批量生产的几个字节的偏差，甚至是根据个人订单制造的消费车辆示例中的复杂配置。
- DTI 示例：像货运卡车这样的 B2B 车辆连接了一个 GPS 接收器，使车队经理能够跟踪实际位置并计算例如估计的交货时间。理想情况下，卡车不直接连接到车队管理系统，而是将其 GPS 数据简单地发送到其数字孪生。然后车队管理系统可以访问卡车的（最后已知的）GPS 位置（即使车辆当前处于离线状态）。在这个例子中，孪生体显然使车队管理系统的编码变得更加容易。它不必处理任何物联网通信，并且可以依赖始终可用的 GPS 数据。但是，你是否希望孪生体能够长时间存储每辆车的所有精确 GPS 轨迹，例如用于审计和保险目的？一些架构师可能会在数字孪生中构建完整的 GPS 跟踪系列。
让我们关注数字孪生实例，以进行以下数据架构的顶级讨论。与许多技术术语一样，也存在将所有内容打包成新术语并将其变成解决任何物联网挑战的秘诀的趋势。这实际上是一个设计挑战，可能会导致非常复杂且难以管理的数字孪生。为避免这种情况，我们想提醒物联网架构师我们与 Cloudflight 客户端完成的许多数字孪生设计会议中的一些最佳实践：
- 涵盖物理设备的所有实际状态。如果隐私允许，任何业务应用程序都应该可以通过数字孪生访问设备的状态，例如传感器数据。任何应用程序都不得直接访问设备。甚至写入变量来改变物联网设备的状态也应该通过将所需状态写入数字孪生来实现。
- 实现覆盖状态的所有离线读写功能。 除了上述所有实际状态的覆盖之外，弥合离线差距是极简实例孪生的第二个关键能力。始终应从两个方向考虑：无论设备是否在线，业务应用程序都可能写入孪生体，而无论设备是否在线，设备都可能写入本地数字孪生体 API。一旦设备再次上线，孪生提、物理设备和数字孪生将再次相互同步。
- 将应用程序逻辑排除在数字孪生之外。 应用逻辑可能位于周边的业务应用中，也可能同时位于更强大的边缘设备中。孪生提本身可能是将容器文件分发到边缘设备的交付机制，但数字孪生本身绝不应该是业务逻辑的执行环境。唯一的例外是对孪生本身非常通用的逻辑。例如，在设备离线时处理并发写入访问的智能乐观锁定应该是孪生体本身的一部分。
- 将流程逻辑排除在数字孪生之外。 正如之前的报告中已经提到的，数字孪生的职责不是执行流程。理想情况下，孪生只是 API 的一个端点。它应该通过事件通知其他应用程序有新数据，但它不负责以传统中间件的方式将某些数据集推送到消费应用程序。
- 在云中建立更大数据量的代理。 一些物联网架构师实际上将非常大的数据集存储在数字孪生体中，并将孪生体和数据湖架构合并。虽然这是可能的，但我们认为这不是最佳做法。如果你拥有大量的远程信息处理或其他时间序列数据，你可能会更好地利用适当的现成存储解决方案。孪生提可能会在那里自动卸载数据，并且仍然可以为查询接口提供代理。这意味着，开发人员将能够始终询问数字孪生（的 API），但它只对最新数据进行本地回答，并转发对大量过去数据的请求。
- 为设备上的实时数据建立代理。 读取和写入可能偶尔离线的设备的数字孪生概念不适用于所有应用程序。有时，你需要确保数据是实时数据。从特斯拉汽车的车库或停车场开出的非自主遥控器就是这样一个例子。其他示例是关于隐私问题的数据，这些数据不应存储在 OEM 的双存储中，而应仅供车主使用。
让我们探索非官方的 Tesla API ( www.teslaapi.io )，它是所有智能手机应用程序（Tesla 的官方应用程序）以及许多第三方应用程序的基础。API 是对所有特斯拉消费类设备的访问的完全抽象，包括汽车和家用电池或太阳能电池板。根据上述指南，我们可以对数据域进行分类并探索它们的外部暴露或假设特斯拉内部使用它们。如果企业和物联网架构师喜欢设计数字孪生数据域模型，则将所有实体分布到这三个类别中并按两个或多个隐私级别进行分配是一种明智的方法。
它们是以下三个数据域：
- 真正的数字孪生：这个领域真正实现了数字孪生概念所期望的远程访问和状态分布。
- 远程车辆访问：这基本上是直接连接到在线车辆的代理 API。令人惊讶的是，特斯拉的大多数消费者 API 和相应的数据集都属于这一类。
- 远程云访问：这是存储在云中的较大数据量的代理 API，如上所述。
就特斯拉汽车而言，真实孪生数据和远程车辆访问域之间的差异变得非常明显，因为它们可以在几个小时不使用后进入睡眠模式。虽然有关车辆及其驾驶/睡眠状态的基本信息始终可用，但如果车辆处于睡眠状态，则请求 GPS 位置等数据会失败。应用开发者需要调用唤醒API，然后再次请求GPS定位。尽管对开发人员来说看起来确实很不方便，但将这些数据定位在“远程车辆访问”域中的明显背景是欧洲数据隐私法规。如果用户没有将他/她的车辆上线，特斯拉将无法访问这些私人信息。即使汽车像往常一样在线，特斯拉也从不存储与车辆或用户身份相关的信息。
跨域的数据分布如下所示：
除了三个访问类别之外，我们还探索了两个隐私类别，消费者可访问和 OEM 机密。上述方框的大小表示每个组合中的 API 和数据集或命令的数量。查看消费者可访问的 API，这些 API 记录在www.teslaapi.io，值得注意的是，大多数数据实际上并未反映在数字孪生中。对于许多数据安全和隐私专家来说，这显然是一个好消息，但这意味着许多 API 调用需要远程唤醒整辆汽车，并且可能会在汽车停车时迅速导致每天超过 5 千瓦时的幻象功耗。同样有趣的是，特斯拉决定不披露任何有关汽车历史数据的云服务。因此，如果你想生成例如完整的电池充电日志，需要使用第三方应用程序或将你的 Tesla API 连接到智能家居系统，该系统可以轻松记录所有这些数据。
很明显，例如商用卡车等 B2B 车辆将分布完全不同的数据域。一旦你与客户建立了值得信赖的 B2B 关系，尽可能多的当前数据将在真实孪生中，以减少远程车辆访问的带宽和延迟。此外，商业 B2B 车辆可能会利用来自真实数字孪生的历史数据，并将其作为远程云访问货币化。想想物流路线优化或类似的用例。
不幸的是，特斯拉并没有透露太多关于上图左侧的非公开 API 和数据域。幸运的是，很容易根据公开可见或推广的功能假设 OEM 机密部分：
- 真正的数字孪生和 OEM 机密：所有软件的无线 (OTA) 更新都属于这一类。特斯拉确切地知道每辆汽车的 50 多个嵌入式设备中的每个软件版本是什么——而且他们可以肯定地知道这一点，而无需轮询汽车。
- 远程车辆访问和 OEM 机密：默认情况下，特斯拉确实“记录”很少的数据。出于赔偿原因，他们会记录例如发生事故时的自动驾驶水平。即使汽车完全损坏并且断电，他们也多次公开表示，某些汽车在事故发生时使用或未使用自动驾驶。如果用户打开数据共享，特斯拉确实会记录远程信息处理数据以提高自动驾驶能力。特斯拉可能还可以远程访问嵌入式设备以进行诊断——但这可能因地区而异。
- 真正的云访问和 OEM 机密：有一些例子表明某些车辆可以访问其他人生成的数据。自治系统的学习数据是显而易见的。启用远程信息处理数据共享的每个人的数据贡献都会对其进行改进。此类别的另一个示例是记录道路颠簸和坑洼。一旦单车报告悬架系统测得的垂直加速度，随后的特斯拉 Model S 就会收到警告，通过空气悬架自动降低速度或增加离地间隙。特斯拉官方声称所有这些数据都是完全匿名的。
图为 Tesla API 文档以及这三个部分如何属于我们的分类。企业和物联网架构师应浏览这些示例并使用引入的数字孪生数据类别来构建其数据模型并访问其数字孪生的层。该方法还有助于以敏捷的方式构建你的单个孪生架构的实施波。根据数字业务模式，你可能首先从“OEM 机密”或“消费者可访问”方面开始。
原文链接：Learnings From The Digital Twin’s Data Architecture Of Tesla
BimAnt翻译整理，转载请标明出处
