Hub-OS：一个可互操作的物联网计算平台

沙特国王大学学报Hub-OS：一个可互操作的物联网计算平台，用于实时支持Desoky AbdelqawySunday，Abeer El-Korany，Amr Kamel，Soha Makady开罗大学计算机和人工智能学院，5博士。Ahmed Zewail Street，吉萨，12613，奥曼，埃及阿提奇莱因福奥文章历史记录：2021年11月20日收到2022年1月20日修订2022年2月10日接受2022年2月25日在线提供保留字： 物联网IoT平台IoT架构抽象A B S T R A C T物联网（IoT）是一种模型，其中设备和应用程序交互在一起，以在不同的环境中提供物联网的挑战之一是提供物联网设备和物联网应用的供应商这种多样性导致物联网计算平台内所提供的计算资源的利用率降低，这是由于每个供应商对其开发的应用程序及其相应设备的不同硬件要求。因此，相同的计算资源可以在相同的物联网平台中重复使用，只有微小的变化，以满足不同供应商的需求。这种重复导致应用程序供应商的额外成本，并降低了这些计算资源的利用率。这种多样性的另一个后果是缺乏一个通用接口，用于跨不同供应商的物联网设备和应用程序进行通信。 这样的通用接口应该提供一个抽象级别，隐藏特定于供应商和特定于物联网平台的实现细节，以提供物联网平台内新物联网设备和应用的无缝集成。本文提出了一种物联网计算平台的新架构，即Hub-OS，用于管理来自不同供应商的设备和应用程序，并有效利用计算资源。物联网设备和应用程序可以轻松集成，而无需修改Hub-OS软件组件或特定于供应商的应用程序和设备。此外，Hub-OS可以托管需要实时处理的物联网应用程序。为了评估集线器操作系统，我们实现了一个案例研究的智能车辆，并进行了定量评估，使用不同的配置。我们的定量评估表明，Hub-OS可以集成来自不同供应商的应用程序和设备，降低延迟，减少CPU使用，有效的物联网应用程序启动和迁移时间。©2022作者（S）。由爱思唯尔公司出版代表沙特国王大学这是一个开放的访问CC BY-NC-ND许可证下的文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。1. 介绍物联网计算平台通过网络集成了一组异构设备及其物联网应用，同时提供托管此类应用所需的计算资源。由于这些应用程序正常工作所需的硬件或软件规范存在差异，并且缺乏用于这些应用程序、其对应设备和目标IoT平台服务之间通信的标准接口，因此这种集成可能具有挑战性。为了成功地将物联网应用及其设备集成到物联网计算平台中，此类平台需要满足一系列服务和架构要求（Agarwal和Alam，2020 b）。服务需求包括支持资源发现和资源管理，而体系结构需求则需要提供*通讯作者。电子邮件地址：d. fci-cu.edu.eg（D. Abdelqawy）。编程抽象，跨异构设备和基于服务的框架的互操作性。在当前的资源发现方法中，设备在注册表中注册它们自己，以使用特定的软件开发工具包（SDK）可与网络上的其他设备兼容这样的方法将IoT平台限制为支持与所提供的SDK相匹配的特定编程语言以用于集成的IoT应用对于资源管理，需要监控计算资源并将其分配给托管的IoT应用程序，以最佳地利用这些计算资源。分配策略应考虑特定于应用程序的因素，如内存使用情况、处理能力和硬件要求。扩展这样的计算资源不应导致违反与任何IoT平台相关的非功能性要求;即可扩展性、可用性和对实时应用的支持（Chen等人，2018年）。然而，当前的物联网平台支持以额外的财务成本扩展计算资源。在云上托管增加的计算资源https://doi.org/10.1016/j.jksuci.2022.02.0111319-1578/©2022作者。由爱思唯尔公司出版代表沙特国王大学这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。可在ScienceDirect上获得目录列表沙特国王大学学报杂志首页：www.sciencedirect.comD. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1499将导致增加的延迟（Wang等人，2018年），以及有限种类的托管应用程序，以减轻将私有数据部署到云（Mineraud等人，2016年）。尽管云平台提供了高可用性，但如果计算资源变得不可用，它们仍然缺乏对物联网应用程序故障检测和迁移的支持软实时支持可以通过边缘计算实现，但硬实时处理仍然是一个未解决的问题（Agarwal和Alam，2020b）。对于编程抽象，IoT平台提供的SDK应该提供与IoT平台的不同利益相关者此外，物联网平台的内部设计不应对该平台的不同利益相关者施加限制。这些利益相关者包括物联网应用程序开发人员及其支持的物联网设备。物联网平台中目前提供的抽象选项可以跨不同的编程语言工作，但将物联网应用程序部署到这些平台的抽象级别有限。当前的部署模型仅限于特定的编程语言，对部署到这些平台的支持有限。（Guth等人， 2018年）。IoT平台需要支持：（1）不受SDK限制的IoT设备、应用程序和计算资源的资源发现;（2）促进可扩展性、可用性和硬实时支持的资源管理;以及（3）适合不同IoT平台利益相关者的各种抽象。本文提出了一种新的物联网计算平台Hub-OS，该平台专注于控制物联网网络和/或子网，并提供了一个可扩展的物联网计算平台，既可以作为本地物联网平台，也可以扩展到与基于云的资源进行通信。因此，Hub-OS平台保留了两个本地IoT平台的优点（例如，隐私、低延迟）和云平台（例如，可扩展性）（Guth等人， 2018），同时减轻其局限性。Hub-OS通过提供以下各项来消除IoT计算平台的当前限制：（i）用于更好地利用计算资源的调度和监视机制;（ii）异构IoT应用及其对应设备的自动化部署和更新，而不管其供应商的变化;（iii）一个抽象级别，以使得能够将新IoT应用及其对应设备集成到Hub-OS中，而不管编程语言的变化;（iv）一个抽象级别，以使得能够在Hub-OS服务与集成的IoT应用之间进行通信，而不管编程语言的变化;以及（v）迁移策略，以增加所部署的IoT应用的可用性Hub-OS原型已应用于智能车辆环境，以证明该方法在不同供应商应用程序中的适用性实现了另一个原型，以评估所提出的Hub-OS方法对CPU使用率、延迟、启动时间和迁移时间的影响。结果表明，CPU使用率可接受，延迟减少，启动和迁移时间有效。1.1. 研究贡献这项工作的主要贡献是：通过用于部署物联网应用的新型调度和监控算法，提高物联网平台内计算资源的利用率。自动更新和迁移已部署的IoT应用程序，从而提高此类IoT应用程序的可用性。提供双重抽象以通过以下方式提高互操作性：（i）将一组异构的IoT设备集成到IoT平台中，以及（ii）物联网平台服务和物联网应用程序之间的差异，尽管这些服务和物联网应用程序开发本文的结构如下。我们讨论了物联网平台目前的研究趋势如何不能满足第2节中的上述需求。我们的Hub-OS平台架构将在第3节中介绍，随后是一个真实的案例研究，展示了Hub-OS如何解决第4节中概述的问题。我们的定量评价在第5节中进行了解释。第6节讨论了Hub-OS当前的局限性，以突出未来的工作，第7节总结了本文。2. 相关工作最近对物联网平台的调查（Mineraud等人，2016; Guth例如，2018; Guth等人，2016; Razzaque等人，2015; Hejazi等人，2018;Bittencourt等人，2018; Bastidas等人， 2018）得出结论，缺乏具有两个基本功能的物联网平台。首先，物联网平台应该提供所需的抽象级别，以部署和托管由不同供应商开发或编写的应用程序。不同的编程语言。其次，物联网平台应该有效地协调异构物联网设备所需的计算资源。我们讨论了这些功能的当前研究趋势，以及它们在某些情况下如何不足。2.1. IoT平台抽象和开发支持IoT平台需要公共接口，使得IoT设备可以通过某种服务来标识自己，并且通过一组服务来通信（Mineraud等人，2016;Dumitru，2017; Sobin，2020; Agarwal和Alam，2020 a）。这种支持可以通过提供新物联网设备将实现的软件开发工具包（SDK）来完成这种抽象实现了跨不同供应商设备的互操作性例如，SDK可以是特定于域的（Dumitru ， 2017; Mineraud例如， 2016 年），比如Carriots 1，其SDK主要针对开发用于监控物联网设备的仪表板应用程序和仅用Java编写的最终用户应用程序。至于允许物联网应用的自动编排、部署和监控，BIG IoT（Schmid et al.，2016）通过提供的API实现物联网资源的共享和监控。但BIG IoT缺乏对新开发应用程序的编排、部署和上传的任何其他方法提供了用于向IoT设备发出命令 的 易 于 使 用 的 图 形 用 户 界 面 （ Lin 等 人 ， 2017; Lin 等 人 ，2018），但不提供用于通用计算活动的SDK。当前的抽象仍然存在以下问题：（i）缺乏跨不同编程语言工作的通用SDK，并且具有来自不同供应商的IoT设备(ii)缺乏发现计算的抽象层次资源，并部署以不同编程语言编写的物联网应用程序。2.2. 利用计算资源提供所需的计算资源对于物联网平台内的托管物联网应用程序至关重要（Sobin，2020）。这样的资源基于IoT平台类型以不同的方法分配如下。基于云的平台。基于云的平台以应用程序即服务的形式提供可扩展的计算资源第1https://www.carriots.com●●●D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1500（A-as-S）或平台即服务（P-as-S）。在商业和开源的基于云的平台中，所提供的计算资源都托管在云上，从而导致延迟。物联网设备和云之间的距离很大。这种延迟使得不可能托管具有实时要求的应用或带宽密集型应用（Guth等人，2018年）。远程托管限制了托管应用程序的类型，以避免在云上托管违反隐私的数据边缘/雾计算。边缘计算通过将计算和数据存储靠近数据源来实现智能计算基础设施。一种方法引入了开放且可扩展的物联网平台（Javed等人，2020年）通过调整边缘计算的模块化特征，其中主要关注动态物联网设备的发现和配置。然而，所提供的平台缺乏对硬实时应用程序的支持，并且主要集中在编排边缘服务，而不是将这种编排扩展到托管在云上的常规服务。雾计算提供了一种分散的计算平台，其中数据、计算、存储和网络服务器位于数据源和云之间的某处（Mouradian等人，2017年）。FoT-Stream平台（Alencar等人，2020）在雾中实时处理和分析数据流。主要目标是减少网络基础设施中传输的数据量，从而减少互联网使用。然而，FoT-Stream的主要焦点是通过利用具有固定资源能力的IoT边缘网关来减少通信和数据流时延，因此不会动态扩展。虚拟化框架。ParaDrop（Liu等人， 2016）采用轻量级虚拟化“容器”技术来实现边缘计算框架，该框架允许将IoT服务部署到WiFi接入点（AP）或其他无线网关中。WiFi AP对于许多类型的应用可能是资源受限的。当部署为单个节点时，WiFi AP将是固定的计算资源，但如果连接为WiFi AP节点的集群，则将动态扩展。或者，引入了基于网络功能虚拟化（NFV）的架构（Miladinovic和Schefer-Wenzl，2017），其中集中式网络功能被虚拟化并在数据中心内运行，而驻留在客户端的组件变得非常简单。然而，这种形式的虚拟化仍然保留了基于云的平台的限制：延迟和缺乏实时支持。另一种虚拟化方法利用IoT微元件（MEL）概念（Villari等人，2019年），以组成，部署和跨不同的资源类型迁移物联网应用程序，它可以跨系统内的不同资源迁移。然而，计算节点仍然是根据环境设置的固定集合，因此缺乏动态可扩展性。因此，利用计算资源的现有方法仍然缺乏：（i）由于基于云的平台内的延迟而对实时应用的支持;（ii）跨各种应用服务的编排，以及对边缘计算平台内的硬实时应用的支持;（iii）动态可扩展性以及雾计算平台内的固定资源。当前的虚拟化解决方案仍然受到上述三个限制中的一些限制。需要一种替代的物联网计算平台架构来解决所有这些问题3. Hub-OS物联网计算平台Hub-OS计算平台专注于与控制智能车辆或智能工厂相关的物联网应用程序，其中预期来自不同供应商的一组异构物联网应用程序和物联网设备需要在Hub-OS内部署：（i）计算资源的最小集合，（ii）导致集线器操作系统服务与集成的物联网应用程序和物联网设备之间的平滑通信的最小所需集成工作，（ii）实时数据处理的可能需求为了提供用于部署一组异构物联网应用和物联网设备的最小计算资源集，我们采用虚拟化的概念来实现在集线器操作系统计算资源上同时部署多个物联网应用，而不管这些计算资源和物联网应用之间的规范差异。这种差异可能是在所需的硬件规格，或所需的软件规格。此外，我们还提供了一套Hub-操作系统独特的服务，用于识别适合目标物联网应用程序部署的计算资源，包括所需的内存使用和CPU使用。为了最大限度地减少所需的集成工作，我们提供了自己的独立于编程语言的API和软件开发工具包（SDK），以允许：（i）将新的物联网应用程序和设备集成到Hub-OS中，与不同的物联网应用程序进行通信，以及（ii）在这些物联网应用程序、物联网设备和Hub-OS独特服务之间进行通信为了实现实时数据处理，我们采用了几种通信协议来在部署的物联网应用程序和Hub-OS平台服务之间发送和接收数据。将使用IoT平台参考模型中推荐的四个模型来解释Hub-OS提议的架构（Bauer等人，2013年）的报告。我们首先解释Hub-OS的物理架构（见3.1小节），然后继续讨论逻辑架构（见3.2小节）。稍后，我们将说明物理体系结构中的不同节点如何在运行时通过Hub-OS平台第3.4节介绍了Hub-OS平台编程SDK使用的信息模型。3.1. Hub-OS物理体系结构集线器OS驻留在本地IoT环境（例如，一个人在这种设备需要与互联网通信的情况下，这种通信可以通过采用存在于Hub-OS平台内的任何智能传感器作为到外部世界的网关 这种布置在图1的部署图中示出。1.一、图的左侧显示了将Hub-OS部署到三个（或更多）物理节点的一种变体，而右侧显示了将Hub-OS部署到两个物理节点的另一种变体。构成Hub-OS物理架构的三个节点这三个节点通过某种通信介质（紫色轮廓）进行通信，Hub-OS的逻辑视图对此进行了详细解释（参见第3.2节）。服务节点。服务节点提供一组Hub-OS独特的服务，以提高Hub-OS可用计算资源的利用率，而不管托管的IoT应用和IoT设备的供应商的差异。这种增强是通过一种新颖的算法来实现的，该算法：（1）监视Hub-OS计算资源，（2）在合适的计算资源上调度新的IoT应用，（3）在所选择的计算资源上部署新的IoT应用，以及（4）根据需要更新所部署的IoT应用。该算法由一组具有面向服务架构的服务来实现。这些服务如图所示。 1，即：数据存储服务、系统监控服务、代理服务和空中服务。的更多信息D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1501Fig. 1. Hub-OS物理架构中的两种备选部署选项。这些服务是在Hub-OS体系结构的逻辑视图中提供的（参见第3.2节）。处理节点。处理节点托管正在运行的IoT应用。正在运行的IoT应用程序可以部署在单独的处理节点（如图1的左侧），或者可以部署在由Hub-OS提供的服务节点上（作为（图1右侧）。因此，如果IoT应用所有者不能提供他自己的计算资源，或者如果他的计算资源中发生了一些故障，则他的IoT应用可以被移动到Hub-OS服务节点。这种部署灵活性使得能够在运行时重新定位IoT应用，从而为托管的IoT应用提供高可用性。为了实现处理节点内托管的IoT应用与服务节点和传感器集线器节点之间的通信，Hub-OS提供节点控制服务。有关该服务的更多信息，请参见Hub-OS体系结构的逻辑视图（参见第3.2节）。传感器集线器节点。传感器集线器节点负责与集线器操作系统平台上托管的不同物联网应用所使用的传感器/执行器进行通信。这些传感器/执行器具有特定的硬件和计算资源要求，并且需要将其收集的数据传递到托管在Hub-OS平台内的相应物联网应用程序。因此，Hub-OS平台通过传感器-集线器节点提供传感器服务以实现这种通信。Hub-OS平台内的虚拟化。根据图1，三个物理节点采用基于管理程序的虚拟化（Morabito等人，2015年）。在图1的左侧中的处理节点内所使用的管理程序引擎将托管所部署的IoT应用/设备的虚拟机与Hub-OS主机操作系统及其所利用的硬件隔离。这样的虚拟化使得能够保护所需的计算资源，而不管通信设备的供应商之间的差异如何。物联网应用程序、物联网设备的供应商以及集成在Hub-OS中的计算资源的供应商。这种虚拟化将增强中心操作系统的互操作性。然而，由于基于虚拟机管理程序的虚拟化在硬件级别上运行，它导致主机操作系统及其硬件与部署的虚拟机隔离。由于虚拟化硬件和虚拟设备驱动程序的开销，这种隔离减少了托管物联网应用程序的数量（Bhardwaj和Krishna，2021）。因此，Hub- OS提供了基于容器的虚拟化作为基于管理程序的虚拟化的第二种替代方案。3.2. Hub-OS逻辑架构构成Hub-OS平台的软件分为多个层，下面将对其进行说明。这样的层将不必被部署到相同的物理机器。图2显示了Hub-OS平台的内部组织，显示了对Hub-OS功能有贡献的主要组件。应用层：此层显示在Hub-OS计算平台内运行的已部署IoT应用程序。这些应用程序可能需要不同的硬件配置，因为它们将使用虚拟化部署在Hub-OS中。此外，部署的物联网应用程序可以用任何编程语言编写，因为它们将通过面向服务的架构（SOA）与Hub-OS一起通信。服务层：为了实现Hub-OS和部署的物联网应用程序之间的通信，无论其编程语言或目标平台如何，都采用了面向服务的架构，从而实现了更高的互操作性。因此，所有的Hub-OS功能都将作为一组服务提供，这些服务使用面向服务的体系结构（SOA）。因此，所有集线器- OS平台客户端将仅需要知道将从集线器-OS平台服务发送或接收什么消息。这种架构消除了在Hub-OS客户端内使用的编程语言与Hub-OS提供的服务之间的任何依赖性。已经定义了六个服务，其中四个服务将被部署到服务节点（数据存储、系统监视器、代理和空中），一个服务将被部署到处理节点（节点控制），并且一个服务将被部署到传感器集线器节点（参见图2）。①的人。这些服务包括：数据存储服务：通过根据需要将此类信息存储在本地托管的计算资源中，保护当前由平台托管的物联网应用程序所需的存储空间，同时考虑数据安全性和隐私性。系统监控服务：监控整体平台状态，包括平台服务以及托管的物联网应用程序。这种服务保持对可用处理节点、可用传感器/致动器的跟踪，以及当前在其上部署了应用的处理节点内的可用CPU功率和存储器。经纪人服务：基于适当的处理节点如何匹配IoT应用所需的配置，在适当的处理节点上调度IoT应用的部署。这种服务还处理IoT应用程序的启动和关闭过程。●●●D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1502图二. Hub-OS逻辑架构。空中下载（OTA）服务：管理Hub-OS平台服务和托管IoT应用程序的软件更新。节点控制服务：支持处理节点上托管的物联网应用程序与Hub-OS平台内的其他节点之间的通信。这样的通信使得能够在IoT应用和集线器操作系统服务之间交换信息，或者从IoT设备检索信息传感器即服务：允许将其他物联网设备与Hub-OS平台集成。这种服务提供了一个API（应用编程接口），它应该由任何传感器/致动器来实现，这些传感器/致动器将被插入到集线器-OS平台中。通过传感器/致动器实现这样的API将使得能够将从传感器/致动器收集的数据发送到处理节点内的其对应的IoT应用。传感器服务是特定于Hub-OS的服务。抽象层：第三层分为两部分。第一个通过提供的面向服务的架构抽象物联网设备，物联网应用程序和集线器操作系统之间的集成和通信第二种方法通过提供两种虚拟化选项：基于管理程序和基于容器，抽象了Hub-OS节点的硬件配置通信层：第四层由不同的协议组成，以实现物理架构中提到的通信介质（见图1）。我们的面向服务的体系结构是使用SOME/IP网络中间件标准2构建的，因为它针对的是我们案例研究中使用的汽车用例（参见第4节）。可以使用其他替代协议，如MQTT3，DSS4，REST5或SOAP协议6。为了支持实时数据处理，需要一个确定性以太网用于Hub-OS内的通信。在确定性以太网中，每个节点都有一个预定义的带宽，该带宽保证在该节点与其他节点的通信中始终可用。这种确定性行为可以通过实现网络协议IEEE TSN 802.1AS7来支持。在一个不-2r.orghttps://www.autosa3https://mqtt.org/第https://www.dds-foundation.org/what-is-dds-3/https://restfulapi.net/6https://www.w3.org/TR/soap/7https://www.ieee802.org/在普通以太网中，每个节点的带宽没有保证因此，为了保证对Hub- OS中的IoT应用的硬实时支持Hub-OS可以在这两种设置下正常工作。事物层：第五层由IoT设备（即事物）形成，其可以是传感器（例如，车辆的镜左摄像头）或致动器（例如，智能锁）。3.3. 平台动态架构在所使用的面向服务的体系结构中，部署的Hub-OS服务的角色已经在前面的Hub-OS静态体系结构中进行了解释。 图图3示出了图1中存在的部署拓扑的集线器-OS平台通信图，同时解释了不同的集线器-OS组件如何通信。通信图显示了启动Hub-OS和部署物联网应用程序的四个步骤。Hub-OS平台唯一服务从冷启动开始底层操作系统在系统启动期间自动启动平台服务这种初始化在图3中使用调用序列1.1 Init（）到1.5 Init（）来反映。因此，服务节点启动系统监视服务、数据存储服务、代理服务和OTA服务。类似地，处理节点启动节点控制服务，传感器集线器节点启动传感器抽象服务。之后，如果服务节点需要与部署在传感器集线器上的传感器通信，则这种通信将通过传感器即服务节点来完成。类似地，如果服务节点需要与部署在处理节点上的IoT应用通信，则这种通信将通过节点控制服务节点来实现。报名：不同的平台服务向系统监视器服务发送注册事件，系统监视器服务充当可用的hub-OS服务、计算资源、传感器和执行器的全局注册表。在图3中使用调用序列2.1 register（）到2.4 register（）示出了这样的注册阶段。激活：激活阶段如下进行。(i)代理服务从数据存储服务获取关于要部署的目标IoT应用的信息。这些信息包括正确部署所需的CPU利用率、内存规格以及部署的目标操作系统●●●D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1503图三. Hub-OS平台通信图。并运行这样的IoT应用程序。（ii）代理服务从系统监视器服务检索关于可用处理节点的信息以及它们的空闲CPU利用率和存储器规范（参见图3中的call3.1pull_processing（））。(iii)节点控制服务应用调度算法来指定目标处理节点。这种调度算法将最大化资源利用或最小化功耗（参见图3中的调用3.2 schedule_activations（））。(iv)指定的目标处理节点的节点控制服务从数据存储节点下载目标IoT应用的图像（参见图3中的调用3.3pull_Activation_binaries（））。(v)节点控制服务启动一个新的虚拟机（VM），并在该虚拟机上部署目标IoT应用程序（参见图3中的调用3.4 Start_VM（）和3.5 Exe- cute_VM（））。 3）。执行：主动物联网应用开始与该平台用于读取传感器数据。3.4. Hub-OS信息模型Hub-OS平台通过用C/C++编写的整合平台SDK为应用程序开发人员抽象底层计算这样的SDK将平台的能力暴露给托管的应用，包括：（i）检查可用的计算资源以识别具有空闲CPU和存储器配置的节点，以用于调度与这样的配置匹配的新IoT应用，（ii）调度IoT应用以在匹配的处理节点上执行，（iii）停止IoT应用的执行，（iv）读取/消耗传感器数据，（v）将控制计算发送到处理节点命令到致动器，以及（vi）安装/移除/更新IoT应用。为了在Hub-OS平台上托管新的IoT应用，IoT应用开发人员对其IoT应用所选择的编程语言没有限制。每个应用程序由两个组件组成：应用程序激活和应用程序逻辑。应用程序激活是一个模板项目，它与Hub-OS平台交互，以基于某些期望的情况（例如，在所有门关闭后执行安全监控应用）。应用程序激活包括一个JSON配置文件，该文件为物联网应用程序规定了：最大所需CPU、内存大小、目标平台以及在执行期间可能访问的传感器/执行器。图图4呈现了与以下各项相关的类：（i）集线器-OS服务，（ii）IoT应用及其IoT设备，以及（iii）集线器-OS服务与IoT应用/设备之间的信息交换，如下所示。图4中的Platform服务包包括四个类，它们代表服务节点中托管的四个Hub-OS服务（参见第3.2节）。这些服务将调度和控制物联网应用程序。物联网应用程序开发人员不需要实现这些类，但可能需要从它们调用服务。图4中的传感器和致动器包包括需要由IoT设备供应商实现的类，以便使集线器-OS能够与这样的IoT设备通信。因此，如果传感器或致动器供应商希望将其IoT设 备 集 成 到 Hub-OS 平 台 中 ， 则 需 要 实 现 SensorAbstSrvc 、ISensor、Actua和D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1504见图4。 Hub-OS平台类图。torAbstSrvc 和 IActuator 。 ActuatorInfo 、 NodeInfo 、 AppInfo 和SensorInfo类表示当Hub-OS服务与托管的IoT应用程序通信时交换的信息，或与集成的IoT设备一起使用。4. 智能汽车案例研究如今，车辆通常配备有用于驾驶辅助的新的先进系统。这种系统可分为两类。第一类是在低速操纵期间支持车辆驾驶员的低速驾驶辅助系统（例如，停车辅助和交通堵塞辅助系统）。第二类是高速驾驶辅助系统，其在高速操纵（例如，车道保持辅助和自适应巡航控制系统）。这样的系统利用可能连接到一组传感器和/或致动器的一些计算资源来实现目标功能。例如，基于超声波的停车辅助系统-tems（Dokur等人， 2016）利用超声波传感器提供一个边界警告声音时，车辆接近障碍物在停车操纵。基于摄像头的停车系统应提供360度俯视图，以便驾驶员通过使用安装在车辆前、后、左、右的四个摄像头组来监控周围环境。这样的系统还可以使用方向盘致动器来在操纵时自动地使车辆转向。高速辅助系统可以使用不同的传感器组。例如，头戴式前置摄像头可用于提供车道保持辅助特征，而激光雷达传感器可用于提供紧急制动系统。对于停车和车道保持辅助系统，其所需计算资源的规格取决于在其相应应用内所利用的算法的实现因此，算法可能需要GPU进行处理或来自Arm架构的某些配置文件，例如Arm A配置文件，有时具有Neon SIMD（单指令多数据）指令。因此，提供一种适合不同实时应用的计算资源可能是困难的.D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报15054.1. 使用传统的车载计算平台考虑一个汽车制造商，他的目标是在即将发布的汽车中支持自动泊车和车道保持辅助。制造商决定利用来自供应商-x的现成停车应用以及来自供应商-y的车道保持辅助应用。这种车辆为了部署来自供应商x的停车应用，停车电子控制单元（停车ECU）通过红色虚线连接到四个摄像头（前、后、左后和右后），并通过车辆网络连接连接到转向和制动ECU，如蓝色实线所示。为了部署来自供应商的车道保持辅助应用，前激光雷达和前摄像头传感器通过蓝色虚线连接到车道保持电子控制单元（LKA ECU），并通过蓝色实线连接到车辆网络。车辆的ECU设计由两个RT核心充当ECU主机，管理与车辆其他ECU的连接，并托管一些需要实时处理的HPC SoC充当由RT核心控制的从机，并托管相同感兴趣应用的高密集为了说明车辆ECU的内部结构，图图6示出了在图1内的车辆中使用的停车系统ECU的高级软件逻辑架构视图。 五、RT核心架构基于经典的autosar标准8（汽车开放系统架构），并托管两个主要的可执行软件组件。这些软件组件是：（i）车辆控制软件组件，用于管理转向和制动ECU，(ii)片上系统软件组件HPC ScC托管由高级操作系统（例如，Linux9或Integrity10），其托管插槽检测和视频拼接软件组件以及用于管理与RT核心的内部通信的Host-CoM组件。图5示出了车辆制造商必须将停车应用部署到一个ECU（停车ECU），并且将车道保持辅助应用部署到另一个ECU（LKA ECU）。而不是利用一个电子控制单元主机的两个应用程序的组件，两个类似的电子控制单元被利用。这主要是由于供应商x提供的现有停车ECU中的RT核心规范与供应商y开发LKA ECU软件组件所依据的规范之间存在差异这样的架构不是可扩展的，因为计算资源是有限的，并且它必须从车辆制造/设计的开始就被定义。4.2. 使用Hub-OS物联网计算平台图图7示出了利用Hub-OS IoT平台的替代车辆架构。在这种架构中，四个安装的摄像头直接连接到车辆网络，而不是像原始架构中那样连接到停车ECU每个摄像机通过为其功能提供传感器即服务（SAS）实现而充当智能传感器（参见第3.4节）。这样的特征可以是视频流服务、控制帧速率的传感器配置、视频格式、或到集线器操作系统平台的简单传感器集成此外图 7显示了一个处理集群（红色矩形，8r.org/https://www.autosa9https://www.linux。组织/第10https://www.ghs.com/products/rtos/integrity.htmlgle），其中一个或多个ECU充当通用共享服务节点。处理集群与车辆网络连接，停车和车道保持辅助物联网应用程序都可以托管在同一ECU或不同ECU上此外，每个ECU可以在未来扩展为包括多个RT内核或多个HPC-SOC，以确保目标功能应用所需的计算资源这种灵活性提高了Hub-OS平台的可扩展性。图图8展示了图9中DC-ECU的软件架构。7.第一次会议。 DC ECU包含一个RT Core和一个HPC SOC，其中两者都由Hub-OS平台提供的NodeCtrl服务管理的hypervisor抽象。这样的管理程序将托管停车IoT应用和车道保持辅助IoT应用的虚拟机（VM）。停车主机VM包含停车应用程序的硬实时部分，其控制转向和制动将被分配/调度到RT核心，而停车应用程序VM包含停车应用程序的计算密集部分，其在HPC Soc上实现插槽检测和视频拼接每个VM通过配置文件VM提供其所需的资源和依赖性，即CPU、存储器、硬件加速器、外围设备、传感器或致动器，该配置文件VM将由平台服务解析以保护所需的资源并启动应用VM。当车辆制造商决定扩展车辆特征以包括供应商-y LKP特征以及从供应商-x停车时，集线器-OS可扩展性将是更好地利用现有计算资源的良好适合。两个新的VM将被部署到可用的处理集群中;即图8中的LKP主机VM和LKP应用VM。Hub-OS将在高速机动期间管理调度和激活/启动LKP辅助VM，并在低速机动中停放VM，这导致可用资源的最大利用。4.3. Hub-OS功能Hub-OS利用物联网平台中现有的未利用这些功能导致了Hub-OS平台的几个优点，如下所示：隐私：云物联网平台的一个限制是，如果这些数据托管在云上，则会存在数据隐私风险。使用Hub-OS平台，用户将能够在自己的处理节点中本地存储数据低延迟：由于Hub-OS在本地网络中工作，其延迟将小于基于云或基于雾的物联网平台。此外，由于Hub-OS可以在确定性以太网中实现，因此可以控制其延迟，为安全关键应用提供所需的硬实时支持。互操作性：由于Hub-OS支持基于容器和基于虚拟机管理程序的虚拟化，因此可以无缝集成各种硬件配置和物联网设备，从而提高来自不同供应商的各种物联网设备之间的互操作性。可用性：如果使用Hub-OS的开发人员需要将可用性作为其物联网平台的首要任务，那么他/她可以选择在Hub-OS平台中使用基于容器的虚拟化。这样的选择将意味着每个IoT应用将被部署在单独的容器中，并且在其托管处理节点中发生任何故障的情况下可以容易地当这种迁移发生时，物联网应用程序启动时间将减少，因为●●●●D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1506图五、使用传统物联网计算平台的停车系统和车道保持辅助车辆架构图六、停车系统车辆软件架构。依赖于容器化技术，该技术在跨处理节点移动其容器的同时保留可靠性：如果使用Hub-OS的开发人员需要将可靠性作为其IoT平台的首要任务，则他/她可以在Hub-OS平台内选择基于虚拟机管理程序的虚拟化。这样的选择将在单独的虚拟机中部署每个IoT应用如果一个虚拟机发生故障，同一个处理节点内的其余虚拟机仍然可以正常工作，从而提高了此类平台内托管的物联网应用程序的可靠性。实时支持：Hub-OS保证了托管应用程序之间的无干扰（FFI），因此包括实时和非实时应用程序的混合设置可以在同一平台上并行执行，而不会有风险通过在单独的虚拟机中执行每个应用程序，该虚拟机具有预构建的Linux根FS（文件系统），其中包含平台的基本依赖关系。5. Hub-OS平台评估Hub-OS作为一个面向嵌入式Linux操作系统的原型，采用C/C++语言实现SOME/IP实现已从开源Genivi11中重新使用，作为面向服务的通信协议。通过扩展systemd-nspawn 12，为我们的评估原型实现了基于容器的虚拟化。 在成功部署该原型后，对Hub-OS进行了定量评估。由于每个平台支持不同的IoT设备系列，并且针对不同的非功能需求子集，因此该评估没有将Hub-OS与现有技术中的因此，比较评估将变得复杂，因为收集的指标将涉及由Hub-OS处理的非功能需求的子集。因此，根据以下小节完成了一组针对Hub-OS不同方面的单独实验5.1. 实验装置一台Lenovo T530膝上型计算机，具有4个Intel（R）Core（TM）i5-3320 M CPU@2.60 GHz，具有8 GB DDR3内存，运行UbuntuLinux 16.04（此后称为Lenovo PC）;一个R-Car Starter Kit PremierH3 with ARM big.Little with ARM CA57（ARMv8）1.5 GHz quadcore ， with 4 GB DDR4 Memory running a custom build LinuxYocto distribution v3.21.0（after非实时应用程序中的某些故障会导致实时应用程序的故障这样的改善是第11https://docs.projects.genivi.org/vSomeIP/1.3.0/html/README.html12https://wiki.archlinux.org/title/systemd-nspawn●●D. Abdelqawy，A.El-Korany，A.Kamel等人沙特国王大学学报1507图7.第一次会议。停车系统和车道保持辅助车辆架构集线器操作系统。