账号:
密码:
智动化 / 文章 /

IoT架构里的模拟技术与数位分身应用
加速物联网系统开发的关键技法
[作者 Rich Miron]   2020年08月06日 星期四 浏览人次: [10829]

由于开发人员需要等待新装置进行硬体实作,因此嵌入式应用开发专案常常会出现延误。 IIoT应用的开发,也面临类似的瓶颈,需等待以机器学习为基础的预测性维护系统,或自动化系统应用所需的感测器资料。


大规模的工业物联网(IIoT)应用带来诸多挑战,这些挑战可能会让部署作业停滞,并让公司质疑投资这么多资源,究竟能否回本。为了避免这种情况并协助开发人员更快确认部署 IIoT 的优势,就需要即时取得部署模拟所需的资料。


若使用模拟方法来产生真实的资料流,开发人员可在部署 IoT 网路之前,就开始开发 IIoT 应用,甚至是改善 IIoT 感测器网路本身的定义。


IIoT 资料模拟案例

使用模拟资料来驱动应用和系统的开发,当然不是什么新鲜事。几十年来,开发人员一直使用系统级模拟方法,对运算基础架构和连接性服务进行压力测试。这些测试在验证静态配置的耐用性上,发挥了重要的作用。在云端服务平台中,这些测试能以相对简单的方法,验证虚拟机器和其他云端资源的自动扩缩能力。


IIoT 应用不仅包含以上这些要求,除了协助负载测试和自动扩缩外,资料模拟还提供一个重要的工具,可用于验证许多不同服务和资源的整合,以实作像企业级 IIoT 应用这么复杂的软体。除了这些较为基础的实务外,资料模拟还可以加速复杂 IIoT 应用的开发,而这些应用多在云端供应商提供的服务平台上打造。


软体视角

IIoT 应用在复杂的架构上运行,而这些架构在应用软体开发人员,以及感测器和致动器系统的开发人员看来有很大的不同。对于后者来说,大型 IIoT 架构由大量感测器和致动器构成,与作为整个应用主体的实际过程相介接。对于应用软体开发人员来说,企业级 IIoT 架构则由大量服务构成,这些服务的协调活动,最后会提供该应用的功能。


微软(Microsoft)的 Azure IoT 参考架构,从应用软体的角度提供典型 IIoT 应用 (和一般 IoT 应用) 的代表性视图。此视图总结典型应用在云端整合的多个功能服务,以根据来自端点和周边边缘装置的资料,提供洞见和行动 (图 1)。



图1 : Microsoft 的 Azure IoT 叁考架构展示 IIoT 应用通常需要的多种云端服务和资源,用於从周边装置网路产生的资料提供有用的洞见和行动。(source:Microsoft)
图1 : Microsoft 的 Azure IoT 叁考架构展示 IIoT 应用通常需要的多种云端服务和资源,用於从周边装置网路产生的资料提供有用的洞见和行动。(source:Microsoft)

具体的应用解决方案会以适当的组合,来部署这些云端资源,并透过标准化互换机制进行功能连接,然后由应用逻辑加以协调。例如,Amazon Web Services(AWS)在连网汽车解决方案中,建议如何在不同功能与能力的模组中,混搭云端服务(图2)。



图2 : AWS 的连网汽车解决方案的代表性视图,显示出典型大型 IoT 应用如何协调云端服务来提供所需的功能。(source:Amazon Web Services)
图2 : AWS 的连网汽车解决方案的代表性视图,显示出典型大型 IoT 应用如何协调云端服务来提供所需的功能。(source:Amazon Web Services)

正如这些代表性架构所示,建立 IIoT 应用所需的软体开发工作,与实作感测器和致动器系统的周边网路一样艰巨和庞杂。很少企业组织可以负担装置网路产生足够的资料后,再开始开发此复杂软体所造成的延迟成本。事实上,随着分析专家和机器学习专家开始处理应用结果,装置网路的部署可能需要等待进一步的定义和完善。在最糟的情况下,装置网路部署和软体开发会陷入僵局:相互依赖彼此提供的结果。


所幸,解开这个困局的方法在于 IoT 架构本身的性质。除了一些广泛的相似性,云端服务架构(如Microsoft和AWS) 在细节上确实有所不同。尽管如此,这些架构都展现出 IoT 云端平台中典型的类似架构特点:有定义明确的介面服务模组或分层功能,能分隔 IoT 装置周边网路和云端架构的软体应用。除了提供统一的连接性,这些介面服务对于大规模 IIoT 应用所需的装置管理和安全性,以及其他关键能力也至关重要。


在Microsoft的Azure云端中,此介面服务称为Azure IoT Hub;在AWS云端中,称为AWS IoT Core 。在Google Cloud Platform中,此介面为 Cloud IoT Core,在 IBM Cloud 中则为 IBM Watson IoT Platform Service。其他平台 (如 ThingWorx IoT Platform),也同样透过 ThingWorx Edge Microserver、ThingWorx Kepware Server 或协定配接器工具套件等连接性服务进行连接。简单来说,任何云端平台都需要提供一致的介面服务,将资料从周边装置汇集到云端,以免让周边装置杂乱地直接连接到云端深处的各个资源。


注入模拟资料

使用每个 IoT 平台的软体开发套件(SDK),开发人员能以所需的容量、速度和类型,将模拟的感测器资料直接注入平台的介面服务,来验证应用的功能和效能。以所需速率和解析度产生的模拟资料,会透过讯息伫列遥测传输(MQTT)及受限应用通讯协定(CoAP)等标准协定送达介面服务。该介面服务 (和下游应用软体) 无法分辨模拟资料流与硬体感测器系统撷取的资料的差异。当装置网路准备好上线时,感测器资料流会直接取代模拟资料流并被送达介面服务。


云端平台提供者通常会在不同的能力层级,支援此资料模拟方法。例如,Google 以参考架构和范例程式码,展示简易的模拟驱动式应用,实作温控式风扇的简易控制回路。和前述架构一样,此架构利用由 Google Cloud IoT Core 服务介面馈送的 Google Cloud Platform 服务(图 3)。



图3 : 在任何 IoT 云端平台中,装置模拟器都会采用与实体装置相同的通讯协定,将资料??送到介面服务,如此处所示的 Google Cloud Platform 应用架构的 Google Cloud IoT Core 等。(source:Google)
图3 : 在任何 IoT 云端平台中,装置模拟器都会采用与实体装置相同的通讯协定,将资料??送到介面服务,如此处所示的 Google Cloud Platform 应用架构的 Google Cloud IoT Core 等。(source:Google)

在此范例应用中,温度感测装置的模拟器以选定的更新率产生资料,并透过 MQTT 传讯协定,将资料传送至 Google Cloud IoT Core 介面服务。而该介面服务使用平台的标准「发布-订阅(pub/sub)」协定,将资料传送至模拟伺服器,依需求发出指令,以开启或关闭风扇(图4)。



图4 : Google 范例应用展示一个由模拟装置组成的基本控制??路,可以标准通讯方法透过 Google Cloud IoT Core 将资料传送到模拟伺服器。(source:Google)
图4 : Google 范例应用展示一个由模拟装置组成的基本控制??路,可以标准通讯方法透过 Google Cloud IoT Core 将资料传送到模拟伺服器。(source:Google)

除了 Google 的范例程式码,开发人员还可在 GitHub 等储存库上,找到数十个开源 IoT 装置、系统及网路模拟器。例如,Microsoft 的开源Raspberry Pi系统模拟器程式码,含有预先构建的Azure IoT Hub整合,可快速开发与Raspberry Pi板介接的云端型应用。此外,Node-RED等编程量较低的工具,支援预先构建的模组(节点),可将模拟的感测器资料,馈送到领先的云端平台 IoT 服务介面。开发人员使用这些方法,便可轻松产生感测器资料流。


大规模执行模拟

使用装置级模拟器和相关工具的难处,在于光是管理资料模拟本身,就可能变成一项专案。要执行此模拟器,开发人员需要布建和维持资源,就像对待任何应用一样。更大的问题是,用来产生真实资料的装置模型,会成为独立于 IIoT 应用开发过程的专案。


随着开发作业的进行,开发人员需要确保装置模型的功能与 IIoT 装置网路及应用,在定义上的任何变更都能维持同步。对于企业层级的 IIoT 应用,开发人员可能会发现,扩充这些模拟也很困难,甚至于会开始占用开发应用所需的资源。


各大 IoT 云端平台提供商透过 IoT 装置模拟解决方案解决了这些问题,而这些解决方案可像相应平台中其他云端资源一样容易扩充。例如,AWS IoT Device Simulator 为其 CloudFormation 配置服务提供 AWS 范本,这可部署虚拟私人网路,由其连接以 AWS Fargate 无伺服器引擎上运行的容器实作的微服务(图 5)。



图5 : AWS IoT Device Simulator 结合多个 AWS 服务,可将可扩充的装置资料流提供给实体装置所使用的同一 AWS IoT Core。(source:Amazon Web Services)
图5 : AWS IoT Device Simulator 结合多个 AWS 服务,可将可扩充的装置资料流提供给实体装置所使用的同一 AWS IoT Core。(source:Amazon Web Services)

开发人员可透过在 Amazon S3 服务中运行的图形使用者介面(GUI)控制台,以互动方式存取模拟,也可透过由Amazon API Gateway服务中的CloudFormation范本产生的IoT Device Simulator应用程式开发介面(API),以编程方式存取模拟。在模拟执行期间,IoT Device Simulator微服务会根据自身配置项目中描述的整体模拟计画,从 Amazon DynamoDB NoSQL 资料库提取装置配置。


这些装置配置为 JSON 记录,定义装置属性名称(例如温度)、值范围 (例如 -40 至 85)、更新装置间隔、模拟持续时间以及其他资讯等。开发人员可透过控制台以互动方式或透过 API ,以编程方式新增装置类型。装置类型、配置和基础架构可使用常规的 DevOps 方法快速进行扩充,实现到达 AWS IoT Core 和下游应用所需的资料更新率。


在 Azure 装置模拟器中,开发人员可使用装置在模拟执行期间支援的行为集,以及云端应用可直接调用的方法集,来进一步补充属性基本清单。


数位分身

这种装置资料模拟在概念上与商用 IoT 云端平台中新兴的数位分身能力紧密相关。不像装置影子通常仅会以静态方式提供装置状态,数位分身延伸虚拟装置模型,使其符合实体装置状态及其行为。


在 Microsoft 的Azure中,Azure Digital Twins服务让开发人员包含使用者定义的函数,以定义装置模拟期间的行为,且仍像以前一样将结果馈送到Azure IoT Hub。传入的资料无论是模拟还是真实的资料,随后都会发送到事件路由服务,进一步在应用中分发。此外,Microsoft 还使用数位分身资料建立空间图形,描绘在复杂的层次环境(如由多个网路构成的工业自动化系统)中各个装置之间的相互作用和状态(图 6)。



图6 : Microsoft 的 Azure Digital Twins 服务可让开发人员建立能力和特性与实体装置相符的虚拟装置,并为复杂的服务提供基础,例如复杂的 IIoT 层次结构的空间图形。(source:Microsoft)
图6 : Microsoft 的 Azure Digital Twins 服务可让开发人员建立能力和特性与实体装置相符的虚拟装置,并为复杂的服务提供基础,例如复杂的 IIoT 层次结构的空间图形。(source:Microsoft)

对于 IIoT 应用,数位分身可提供强大的机制,能够在围绕这些能力打造的应用的整个生命周期内提供支援。在开发的早期阶段中,数位分身可由平台的装置模拟服务大规模驱动。随着实体 IIoT 网路上线,这些传送给数位分身的模拟资料馈送,可由装置资料馈送取代。之后,在经过完全部署的 IIoT 应用中,开发人员可使用实体装置和数位分身的任何差异作为某些模组的额外输入,例如预测性维护演算法或安全性侵入侦测器等。在整个生命周期中,数位分身可在网路中断或 IIoT 装置网路配置发生重大变化时,防止应用受到影响。


IoT 平台的数位分身技术还带来了第二个优点,即提供标准化方法来描述装置模型的属性和行为。对于描述语言,Microsoft的Azure Digital Twins服务采用JSON-LD(JavaScript Object Notation for Linked Data)。 JSON-LD 已取得全球资讯网协会(W3C)的支援,其基于工业标准 JSON 格式,提供一种标准格式来序列化连结资料,并已用于其他许多应用领域。


随着感测器和致动器预构建数位分身描述储存库的推出,标准化的数位分身描述可进一步加快开发速度。例如,Bosch 已为多个感测器提供开源数位分身描述,这些描述以Eclipse Vorto语言编写,并发布于Eclipse Vorto储存库中。 Eclipse Vorto语言使用大多数编程者所熟悉的文法,能以简单的方法描述数位分身的模型和介面。开发人员可在后期将Vorto语言描述转换为JSON-LD或其他所需的格式。


构建 IIoT 应用

无论是以离散模拟器,还是以微服务导向平台构建,装置资料模拟都提供有效的软体解决方案来加快应用的开发速度。对于采用多个装置网路的 IIoT 应用而言,将装置模拟移转到边缘,有助于进一步平滑地过渡到部署阶段,而不用牺牲应用开发早期对代表性资料的需求。


边缘运算系统在大规模 IoT 应用中扮演着越来越重要的角色。这些系统提供新兴需求所需要的本地资源,包括为减少抵达云端的资料量而进行的基本资料预处理,以及机器学习推断模型等进阶分类能力等。此外,边缘运算系统作为现场装置网路和高速回程网路之间的通讯闸道器,也发挥更基本的作用。


有些闸道器可提供整合通讯支援与边缘处理能力的平台,如 Multi-Tech Systems 的可编程 MultiConnect Conduit 系列。 Multi-Tech 的 MTCAP-915-001A(适用于 915 MHz 区)和 MTCAP-868-001A(适用于 868 MHz 区),使用LoRaWAN连接来汇集现场网路装置资料,并使用乙太网路或4G-LTE来连接云端。


此外,这些平台以开源 Multi-Tech Linux (mLinux) 作业系统为基础,为执行装置模拟提供熟悉的开发环境。随着各个现场网路与实体感测器及其他装置上线,每个单元都可重新回归通讯闸道器的角色,将处理工作重新导向至资料预处理等需求。


结论

云端型应用软体能将感测器资料转换成有用结果,IIoT 应用为现场部署感测器网路及开发此类软体带来巨大的挑战。感测器网路和应用软体的相互依赖,可能会让开发陷入困境,原因就在于感测器部署和软体实作都在等待彼此达到足够的临界质量。


如本文所述,透过以真实的容量、速度和类型水准来模拟资料流,开发人员可打破这个僵局并加速 IIoT 应用的开发。


相关文章
落实马达节能维运服务
工具机数位分身 实现AI智造愿景
地球数位分身:达梭系统与Airbus携手应对未来气候挑战
精确模拟现实世界 数位分身优化真实世界体验
科技改变世界 AIoT翻转农渔业
comments powered by Disqus
  相关新闻
» 意法半导体突破20奈米技术屏障 提升新一代微控制器成本竞争力
» 意法半导体先进高性能无线微控制器 符合将推出的网路安全保护法规
» 易格斯协助客户精进技术并降低成本 同时实现碳中和
» 心得科技:抓紧双轴智造趋势 与客户协同推动数位与绿能转型
» Lightning Motorcycles 纯电动摩托车创造陆地速度世界纪录
  相关产品
» 明纬推出NGE100(U)系列:100W环球通用4埠USB氮化??快速充电器
» 贸泽扩展来自先进制造商的工业自动化产品系列
» 凌华全新IP69K全防水不锈钢工业电脑专为严苛环境设计
» 凌华支援第14代 Intel处理器用於先进工业与 AI 解决方案
» 智慧监测良方 泓格微型气象站提供资讯面面俱到


刊登廣告 新聞信箱 读者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 远播信息股份有限公司版权所有 Powered by O3
地址:台北数位产业园区(digiBlock Taipei) 103台北市大同区承德路三段287-2号A栋204室
电话 (02)2585-5526 #0 转接至总机 / E-Mail: webmaster@hope.com.tw