TinyLink：A Holistic System for Rapid Development of IoT Applications

摘要

快速开发对于物联网应用开发人员获取先发优势、降低开发成本至关重要。在本文中，我们提出了TinyLink，一个快速发展的物联网应用的整体系统。TinyLink的关键思想是使用一种自上而下的方法来设计物联网应用程序的硬件和软件。开发人员用类c语言编写应用程序代码，以指定其应用程序的关键逻辑，而无需处理特定硬件组件的细节。TinyLink将应用程序代码作为输入，自动生成硬件配置以及在目标硬件平台上可执行的二进制程序。

我们实现了TinyLink，并且用真实的物联网系统评估他。结果表明:

(1)TinyLink实现了物联网应用的快速开发，与传统方法相比平均减少了52.58%的代码行数;

(2）与目前最先进的方法相比，由于TinyLink搜索的设计空间要大得多，他可以为硬件配置生成更好的解决方案;

(3) TinyLink在执行时间和程序内存方面带来的开销可以接受。

关键词

物联网，快速开发

1 INTRODUCTION

在过去的几年里，物联网(IoT）从一个模糊的概念发展到连接大量网络设备的实际系统，被认为是未来很有前途的计算技术。IoT平台和应用程序是紧密连接的。这种紧密的连结使得通用的平台很难解决应用程序特殊的需求。

但是实际上我们也缺少通用的IoT平台，这使得IoT应用也很难发展。开发者必须了解IoT系统的各个方面：目标程序的需求、 硬件组成、软件组成等等。他们通常遵循一种自下而上的方法，从建立一个适当的硬件平台(包括适当的微控制器和不同的传感器)到编写可以在该平台上运行的应用程序软件。这种自下而上的方法是非常耗时的[10]:一个独立的应用程序开发人员必须首先学习和构建一个硬件平台，然后构建软件库，最后编写应用程序代码;团队中的应用程序开发人员需要等其他人完成硬件平台和软件系统后才能编写应用程序代码。

本文中，我们提倡的是从上而下的方法。应用程序开发人员可以先编写应用程序代码，就像存在一个拥有市场上所有硬件组件的虚拟平台一样。智能系统以应用程序代码为输入：

(1)自动生成硬件平台的具体配置(如选择哪些组件以及它们如何连接);

(2)将与硬件无关的应用程序代码转换为与硬件相关的代码，可以直接在生成的硬件平台上执行。

这种自顶向下的方法极大地加速了开发过程。

首先，如何选择最合适的硬件组件来满足应用需求?可以从应用程序代码推断出用户所需的功能。如何选择硬件组件来完成所有需要的功能?考虑到这些硬件部件的不同成本和不同特性，该如何制定这个硬件选择问题，应该选择哪些优化标准?

第二，如何以一种兼容的方式接纳一组不同的商业上可用的硬件组件?最近出现了重大的硬件创新，尤其是围绕Arduino和Raspberry Pi平台的Marker领域。已经从固定的平台转向了具有高扩展性的平台。例如，主板已经提供了许多接口，如端口和物理引脚。屏蔽(又名扩展板)提供了更灵活的与主板连接的外设接口。如何考虑外设和主板之间的复杂连接?

最后，如何以独立于硬件的方式表达应用程序逻辑，并将其转换为相应硬件配置的可执行代码?由于不同的平台支持不同的环境，所以很难抽象出统一的编程环境，例如Arduino支持AVR编程环境，Raspberry Pi支持基于arm的Linux编程环境。如何实现一个完整的系统，使应用程序开发人员不必关心底层的细节，如设备驱动程序、交叉编译器等?

为了解决上述挑战，我们提出了TinyLink应用快速开发的完整的系统，一个针对IoT。使用TinyLink，开发人员可以用类c语言指定应用程序逻辑，而无需处理底层硬件、驱动程序、编译器等细节。TinyLink将应用程序代码作为输入，自动生成硬件配置以及与硬件相关的可在目标硬件平台上执行的代码。

TinyLink包含了一个硬件数据库，这个数据库中包含了商用现成品或技术(COTS)【可以采购到的具有开放式标准定义的接口的软件或者硬件产品，可以节省成本和时间】硬件组件以及它们的特性(例如，成本、接口、所需电压等)。TinyLink基于硬件数据库，将可能的硬件组合公式用于硬件约束【这个硬件约束是跟与硬件的特性决定的，与用户提交的代码无关】。TinyLink仔细考虑了由主板和屏蔽提供的端口和物理针之间可能的连接，因此可以包含多种COTS硬件组件。TinyLink还从代码中提取用户约束，例如，调用TinyLink API TL_GPS.read()意味着需要一个GPS传感器。TinyLink通过同时考虑硬件约束和用户约束来探索设计空间。目前TinyLink采用了优化准则来最小化成本。其他标准(例如，可扩展性、能量和性能)也可以采用。TinyLink通过解决优化问题寻求最佳解决方案，并输出硬件配置(包括硬件组件及其连接集)。

TinyLink重用易于使用的 Arduino-like 的环境进行应用程序编程。TinyLink为应用程序提供了统一的api来与底层硬件组件链接。这些api完全在四块主板上实现，包括Arduino UNO、Raspberry Pi 2、BeagleBone Black和LinkIt ONE。为了最小化实现开销，TinyLink大量重用现有库。粘合代码是在TinyLink中实现的，提供了从api到TinyLink所构建的现有库的绑定。

TinyLink是一个整体系统:除了生成硬件配置和提供易用的api外，TinyLink还包括:(1)基于云的编译架构;(2)基于web的应用程序编程接口;(3)常用的系统验证基准。

我们使用真实的物联网应用来评估TinyLink。结果表明:(1)TinyLink实现了物联网应用的快速发展，与现有的Arduino UNO、Raspberry Pi 2、BeagleBone Black、LinkIt ONE等编程方法相比，平均减少了52.58%的代码行数;(2)与CodeFirst[12]相比，TinyLink搜索到更大的设计空间，可以生成更好的硬件配置解决方案;(3) TinyLink在执行时间和程序内存方面带来了可以接受的开销。此外，我们提供了三个具体的案例研究，以说明TinyLink如何帮助我们快速开发真实的物联网应用。

他的贡献如下:

?我们介绍了TinyLink，一个用于开发物联网应用的整体系统。TinyLink将物联网开发过程从自下而上转变为自上而下，实现了物联网应用的快速开发。TinyLink抽象了物联网硬件，因此开发人员可以在没有嵌入式系统经验的情况下专注于应用程序逻辑。

?我们将硬件选择问题表述为一个优化问题。我们仔细考虑了硬件约束和用户约束，以便广泛的COTS硬件组件能够以一种兼容的方式使用，并能够满足应用需求。

?我们为应用程序设计统一的api，以与COTS硬件组件交互。我们在四个主流平台上实现api，这样应用程序开发人员就不需要处理底层的硬件细节。

?我们使用基准和三个具体案例研究仔细评估TinyLink。结果表明，TinyLink在带来可接受的开销的同时，实现了物联网应用的快速开发，生成了最优的硬件配置解决方案。

本文的其余部分结构如下。第2节介绍了如何使用TinyLink。第3节展示了TinyLink的设计概述。第4节和第5节分别描述了硬件生成系统和软件生成系统。第6节为评价结果。第7节讨论了一些重要的未决问题。第8节描述了相关工作，最后，第9节总结了本文并给出了未来的工作方向。

2 TINYLINK USAGE

2.1 Example 

1. 编写应用程序代码。开发人员可以，独立于硬件，直接编写应用程序代码。例如，图2显示了我们的实现。首先，执行setup()函数，初始化所需模块(即WiFi模块)。其次，连续执行loop()函数，读取传感器数据，通过WiFi模块上传数据。应用程序可以通过TinyLink内置api直接调用模块的函数，这些api的前缀是“TL_”。
2. 把代码上传到云中。TinyLink系统运行在云上。TinyLink将应用程序代码作为输入，执行多个任务做一些事情，结果将返回给开发人员。
3. 得到输出。开发人员将获得以下两个输出:(1)硬件配置，其中包括选定的硬件组件及其连接。TinyLink将结果可视化，以便开发人员可以轻松地按照配置组装硬件平台。如图3所示，硬件配置可视化，包括Arduino UNO、Base Shield V1.3、Grove光传感器、土壤湿度模拟传感器和ESP8266 ESP01 WiFi模块;(2)与硬件相关的代码。TinyLink将与硬件无关的应用程序代码转换为与硬件相关的二进制代码，可以直接在目标硬件平台上运行。
4. 组装物联网平台。鉴于硬件配置的可视化(例如，图3)，开发人员可以轻松地将所选组件组装到物联网平台中。
5. 将代码装到平台上。然后，开发人员可以在硬件平台上刻下与硬件相关的代码来执行所需的功能。

这种自顶向下的开发方法与传统的自底向上的开发方法有很大的不同，可以大大加快整个物联网开发过程。使用TinyLink，开发人员可以轻松地表达应用程序逻辑，而无需处理硬件细节。此外，由于TinyLink自动处理复杂的硬件兼容性问题，硬件工程的工作量也可以大大减少。

2.2 TinyLink Programming

我们认为编程的易用性是TinyLink的主要设计目标。TinyLink借用了Arduino编程的程序结构。这是因为:(1) Arduino 相当简单;(2)对于一个大型社区来说，这已经是非常熟悉的了。

如图2所示，构建在TinyLink之上的应用程序代码包括两个主要函数：

• setup()。setup()函数在程序启动时只运行一次。开发人员可以将所需组件的初始化或其他一次性任务放在此函数中。如图2所示,程序首先启动wifi模块(第3行),然后配置了SSID，和AP的密码（第4行），开发人员还可以指定额外的硬件组件的特性,例如,测量范围(第5行)和ADC光传感器的分辨率(第6行)。
• loop()。loop()函数将在setup()函数之后继续执行。loop()函数通常包含一些周期性的任务。如图2所示，程序从光传感器和土壤湿度传感器读取数据。然后，程序调用函数upload()将数据上传到云服务器。最后，程序调用一个内置API来休眠一分钟(第13行)，然后循环再次启动。

TinyLink提供了一个关键字，REQUIRE，用于显式地指定所需的模块。下面，我们举两个例子。

(1)REQUIRE  Light;-本声明规定，即使应用代码中没有使用光传感器，物联网平台也必须包括光传感器;

(2) REQUIRE DBGPrint; -该语句指定物联网平台必须包含一个额外的UART接口，用于打印输出调试信息。

TinyLink为开发人员提供了许多独立于硬件的api。细节将在第5.2节中描述。

3 TINYLINK DESIGN OVERVIEW 

我们将介绍inyLink的设计目标和我们采用的相应方法。

• 快速的物联网应用开发。为了实现这一目标，TinyLink:(1)采用物联网应用自上而下的开发模式;(2)在云端生成硬件配置和二进制程序，不需要安装本地开发环境。
• 易于编程。为了实现这一目标，TinyLink借鉴了Arduino编程的简单程序结构。此外，TinyLink还提供了独立于硬件的api，使应用程序编程变得更加简单。
• 减少配置硬件方面的工作。TinyLink整合了一个硬件数据库，对硬件组件及其特性有明确的说明。硬件配置的生成被表述为一个带有从应用程序代码中推导出的约束的优化问题。通过解决优化问题，tinylink自动生成最佳的硬件配置。
• 高扩展性，可以容纳许多硬件组件。TinyLink被设计为包含一组COTS硬件组件。不像CodeFirst那样[12]，我们不假设一个固定的主板。此外，我们需要考虑硬件组件上接口之间的复杂连接。最后，我们需要仔细考虑库的实现，以便于开发者能够轻松地与底层硬件组件进行连接。

图4描述了TinyLink系统架构，包括硬件生成系统(第4部分)和软件生成系统(第5部分)。应用程序代码作为TinyLink的输入，并被传递给两个生成系统。

• 在硬件生成系统内部，硬件配置生成器通过分析应用程序代码、考虑来自硬件数据库的信息自动生成硬件配置。硬件生成系统还生成硬件配置头文件。
• 在软件生成系统内部，交叉编译器以三个源作为输入，即应用程序代码、生成的硬件配置头文件和库。最后，生成目标平台的二进制程序。

4 HARDWARE GENERATION SYSTEM

在本节中，我们将从硬件数据库(4.1节)和硬件配置生成器(4.2节)两个方面描述TinyLink硬件生成系统。

4.1 Hardware Database 

TinyLink包含一个硬件数据库，其中包含COTS硬件组件及其特性。这个硬件数据库作为自动生成硬件配置的关键信息源。我们寻找流行的和广泛使用的COTS硬件组件用于嵌入式和物联网的开发，发现很多平台都由三种组件组成:

主板。主板包含系统的关键电子元件，如单片机和存储器。它还为其他外设提供接口(以物理引脚或端口的形式)。

盾牌（shield）。shield屏蔽可以插到主板上转换或扩展接口的类型或数量。此外，带有内置模块的shield将使用接口并提供功能，例如，WiFi Shield 2.0使用UART pin并提供WiFi功能。此外，一些包含MCU的shield可以提供额外的接口，例如，GrovePi+[13]有一个ATmega328 MCU，并为Analog Pi提供了三个额外的模拟引脚。

外围设备（Peripherals）。外设可以通过接口连接到主板或shield 。外设包括输入设备(如传感器)、输出设备(如显示模块)和输入/输出设备(如通信模块)。

相应地，我们的数据库包括三个表。

表1是一个简化的表格，包含了以下关键字段:ID, cost, provided interface, consumption interface, provided MCU pin, consumption MCU pin and functional。对于LinkIt One来说，它(1)的价格是59美元;(2)具有三个模拟引脚和两个UART引脚(本例仅显示两种类型);(4)具有一个UART端口;(5)已暴露3个模拟MCU引脚和2个UART MCU引脚;(6)不占用任何接口和MCU引脚;(7)主板集成GPRS、GPS、SD、WiFi、BLE功能。

 如图5所示，物理引脚和端口是物联网组件的两种主要接口。此外，单片机或SoC (System on Chip, SoC)通常包含几个到几十个通用输入/输出管脚(GPIO)，我们称之为MCU管脚。物理引脚和端口连接到MCU引脚。例如，在图6中，UART引脚(即RX和TX)和UART端口连接到UART MCU引脚(即URXD和UTXD)。

4.2 Hardware Configuration Generator

物联网在不同的场景下有不同的应用。虽然一些应用程序可以使用有大量接口的强大主板，但其他应用程序不能。考虑到形式因素、成本和其他因素，最合适的硬件组件可能是资源受限的。generation process旨在解决COTS硬件组件如何有效而兼容的组合在一起。

我们首先描述有效/兼容硬件配置的条件。然后我们将其定为一个选择问题，即应该选择哪些硬件组件来形成物联网平台。最后，我们生成硬件连接并为开发人员可视化最终结果。

4.2.1 ValidHardwareConfiguration. 

在搜索有效的硬件配置之前，清楚地定义一个有效的硬件配置是很重要的。我们首先通过接口定义两个硬件组件之间的有效连接。一个有效的连接必须满足以下条件:

(1)两个接口必须是相同的形式(即物理引脚或端口);

(2)两个接口必须是类型兼容的。通常，这意味着这两个接口具有相同的类型，例如UART。在实践中，我们还考虑了接口可以有两个或更多可选类型的特殊情况;

(3)接口必须是功率兼容的，即一个接口的提供电压电平与另一个接口的工作电压电平兼容，且消耗电流应小于两个接口的最大允许电流。

在有效的硬件配置中，所有连接必须有效。为了简化配置，我们首先假设只有一个主板，另外，它应该满足以下条件:

(1)配置必须满足所有的应用需求;

(2)连接是一对一的映射。换句话说，一个接口不能连接到另一个组件的多个接口，因为这会导致信号干扰。它还意味着，提供的接口数量必须不小于特定接口类型(例如，UART)所消耗的接口数量;

(3)同一MCU引脚的接口只能建立一个连接。如图6所示，可以一次连接UART端口或UART引脚。第4.2.4节将描述一个详细的示例。

表2总结了我们在TinyLink当前实现中考虑的条件:

有几个要点值得强调:

首先，TinyLink比以前的方法(如CodeFirst[12])拥有更大的设计空间。例如，CodeFirst只允许端口之间的连接，而TinyLink允许pin之间的连接。这是许多外设的常见情况，如SoilMoisture模拟传感器和ESP8266 WiFi模块。

其次，我们为有效配置所考虑的条件从来都不是完整的[14]。由于我们没有考虑到的条件，TinyLink生成的有效硬件配置可能无法工作.例如，UART的波特率不兼容。尽管如此，TinyLink还是很有价值的，因为它帮助开发人员避免了大量无效的硬件配置。此外，TinyLink可以很容易地扩展，以适应未来的附加条件。

4.2.2 Problem Formulation.

首先介绍一下符号：

• M代表主板mainboard，S代表shield，P代表外设shield。用集合的形式表示。
• F代表所有功能的集合，U代表用户需求的集合。U可以从用户的代码中提炼出来。U是F的子集。
• d_i表示指标变量。d_i=1表示组件 i 最终用于IoT平台里，并且；d_i=0表示他不在。
• c_i表示组件i的成本
• f_i^u表示组件 i 是否有用户需要的需求
  
• t表示一个接口的类型，T代表类型的集合 T={UART, Analog, SPI, I2C, PWM, USB, Digital}. 
• 表示 组件 i 提供的接口类型为 t  的 接口的数量；表示组件 i 提供的接口类型为   的 接口被消耗的数量

•  跟上面的类似，不过是 表示的物理引脚

•  跟上面的类似，不过是 表示的MCU引脚

 根据上述定义，以总成本为优化准则，可将硬件选择问题表述为:

满足所有的约束条件的集合为可行集。在下面，我们将描述如何小心地设置约束并进行验证，以确保可行的解决方案是有效的。

4.2.3 User Constraint. 

 TinyLink首先对应用程序代码进行预处理，然后推断出用户的需求 U。自动生成用户约束:

例子：

 设硬件数据库如表1所示。TinyLink自动推断U={Light, Soil_Moisture, WiFi}。由此产生三个用户约束:

4.2.4 Hardware Constraint. 

虽然用户约束相当简单，但硬件约束要复杂得多。由于篇幅限制，我们描述了三个重要的约束条件。

1）Port Constraint。

TinyLink允许使用shield来扩展主板的能力。因此，对于特定类型，主板提供的端口数量加上shield提供的端口数量，减去shield所消耗的端口数量，应该不小于外设所消耗的端口数量。TinyLink的端口约束如下所示:

 2) Physical Pin Constraint. 

TinyLink允许通过物理引脚进行连接。与端口约束类似，TinyLink的物理引脚约束如下所示:

 3) MCU Pin Constraint. 

然而，可用端口和物理引脚的实际数量并不像计算它们的总和那么容易。这是因为一些端口和物理引脚被映射到相同的MCU引脚，这意味着它们实际上共享相同的接口，如果它们被同时使用，就会相互干扰。例如，在图6中，pin头中的UART物理引脚RX和UART端口内的引脚(即UART端口的RX引脚)连接到MT2502A上的同一个MCU引脚URXD，即LinkIt One的SoC。UART物理引脚TX和UART端口中的TX引脚也是同样的情况。

 因此，我们需要在MCU pin级限制可用接口的数量。消耗的MCU引脚总数不应大于所提供的引脚总数。MCU引脚约束生成如下:

 例子。我们将在图2中回顾这个示例。TinyLink生成以下约束：

 结合主板约束(即d1 +d2 +d3 = 1)和4.2.3节中的用户约束，可以得到19个可行集。

Comparison with CodeFirst.

CodeFirst[12]:(1)不允许使用屏蔽;(2)不允许通过引脚连接;(3)不考虑MCU引脚约束。有了以下端口约束：

CodeFirst为图2所示的示例生成以下具体约束:

 假设一个固定的BetaBlocks主板，CodeFirst只得到一个可行解{3,6,8,10}，该解包含在TinyLink的可行解集合中。

图7显示了TinyLink和CodeFirst的解决方案空间。在我们所描述的三个约束条件下，所有CodeFirst可行解的集合是TinyLink可行解的子集。TinyLink的搜索空间要大得多，因为它允许组件之间的复杂连接。

 4.2.5 Implementation. 

硬件配置的生成包括三个主要步骤。

首先，我们解决上述优化问题，并寻找最合适的硬件组件。在实际实现中，我们使用表2中列出的完整约束集。我们进一步考虑兼容性约束。兼容性约束:(1)禁止连接物理上不兼容的硬件组件，如Base Shield V1.3和Raspberry Pi 2由于外形因素不同，物理上不兼容;(2)限制硬件组件在运行时与不能兼容的硬件组件连接，例如LinkIt One上的Grove温湿度传感器Pro经常无法通过端口连接读取温度数据。

由于所构造的问题是一个经典的整数线性规划问题，我们利用ILP求解器lp_solve[15]来求解该优化问题

其次，TinyLink在生成硬件组件列表后，将向开发人员展示如何组装这些硬件组件（简单的可视化）。通过正确地分配在主板和shield硬件组件的接口，产生配置。给定选定的主板和shield，TinyLink计算所有可用的接口，然后分配他们的优先级。首先，TinyLink分配主板和shield上的内置模块占用的引脚接口，例如WiFi Shield 2.0上的UART引脚。然后，TinyLink将未占用的端口和未占用的物理引脚分配给外设，因为端口通常占用与物理引脚共享的连续MCU引脚。基于分配，TinyLink利用OpenCV为生成的硬件配置生成一个简单的可视化，例如，图3可视化了图2中所示的应用程序代码的推荐硬件配置。

 最后，TinyLink使用一个额外的验证过程来验证推荐的硬件配置是有效的，根据4.2.1节中描述的定义。如果硬件配置碰巧由于无效连接而无效(从我们的经验来看，这种情况很少见)，TinyLink将再次调用ILP解决程序，以寻求根据我们的定义有效的不同解决方案。在未来，我们将借用众包的理念进行物联网应用的开发。如果当前开发人员选择了其他人使用并成功报告的硬件配置，那么开发人员很有可能获得正确的配置。

5 SOFTWARE GENERATION SYSTEM

 本节描述如何从应用程序代码生成与硬件相关的二进制程序。第5.1节描述了硬件配置头文件的生成。第5.2节和第5.3节详细介绍了TinyLink API的设计和库的实现。章节5.4描述了交叉编译器，章节5.5讨论了TinyLink中的交互调试。

 5.1 Hardware Configuration Header File 

从开发人员的角度来看，应用程序代码是独立于硬件的。然而，从交叉编译器的角度来看，代码应该是依赖于硬件的，例如，链接到与底层硬件对应的正确的库。因此，我们将硬件配置信息(参见图3)转换为C语言的硬件配置头文件(参见图8)。

 硬件配置头文件由三个部分组成：

第一部分包括其他重要的头文件(第1行)，比如设备ID头文件。

第二部分？？描述了哪些硬件组件是通过宏使用的(第3-6行)。在每一行中，一个抽象组件(例如，第3行中的主板)由一个特定的硬件组件(例如，第3行中的ARDUINO_UNO)定义，它将硬件无关的功能与硬件相关的组件联系起来。

第三部分描述了硬件连接信息(第8-11行)。

这个硬件配置头文件由硬件生成系统生成，对于编译目标平台的应用程序代码非常重要。

5.2 API Design

与传统的物联网编程不同，TinyLink的编程是独立于硬件的，也就是说，开发人员不知道底层的硬件组件。api在将高级语义与低级细节联系起来方面扮演着重要的角色。tinylink提供了通用的api来帮助应用程序编程。

为了给开发者提供通用的api，我们调查了116个来自热门物联网论坛[16,17]和网站[18,19]的项目。我们从中提取了225个常用的api，并根据它们提供的功能将它们分为39个类别。如表3所示，我们列出了20个最常用的类别和它们的调用频率，其中最流行的是LED，约占23%。在目前TinyLink的实现中，我们封装实现了24个类，覆盖了我们所调查的全部api的89.78%，还有10.22%(即未覆盖的)未实现的api，包括控制DIY设备、发射和接收红外信号等。在有限的开发时间内，我们决定实现最重要和常用的api，而跳过那些不经常调用的api。

如果项目中使用的所有api都具有相应的TinyLink api，我们就说TinyLink支持一个项目。67.24%的项目得到了TinyLink的支持，并且可以通过很小的修改移植到TinyLink。剩下的32.76%的项目至少有一个未覆盖的API，因此在当前阶段不能轻易地移植到TinyLink。我们计划在未来实现更多的TinyLink api来支持更多的物联网应用。

如何在不可靠的网络上以高效节能的方式交换信息是物联网发展中的一个重要问题。消息队列遥测传输(MQTT)协议是一种轻量级消息传递协议[20]，它构建在TCP协议之上。它已经被主要的物联网云提供商(如IBM、Amazon和微软)采用作为物联网通信的主要协议。为了支持这个在物联网开发中广泛使用的协议，我们在TinyLink中提供了MQTT api。一旦建立了TCP连接，带有MQTT的TinyLink节点就可以在其上连接到代理(即服务器端的MQTT客户端)，然后发布/订阅它们的信息。我们已经在IBM Bluemix和中国移动物联网开放平台上测试了我们的TinyLink MQTT api。我们的四个主板（ Arduino UNO, LinkIt One, Raspberry Pi 2 和 BeagleBone Black, ），可以使用ESP8266 和UART  wifi模块连接到两个云平台上的MQTT代理，或者是使用LinkIt One 的内置的无线模块，Raspberry Pi 2的内置的以太网模块，或者BeagleBone Black。

此外，我们还为开发人员提供了基本的调试api。它们可以编写REQUIRE DBGPrint来表示它们需要打印输出调试信息。在这种情况下，TinyLink硬件系统将占用主板上一个额外的串行接口。所有调试信息都将通过这个串行接口传输。开发人员可以使用TL_Debug.print()来打印他们自己的调试信息。

5.3 Library Implementation

库是TinyLink api的实际实现。我们正面临着实际的实现挑战，因为每个库实现都需要开发，而且所需实现的数量可能会随着硬件组件数量的增加而快速增长。我们通过以下方式应对这些挑战。

首先，我们根据我们的经验实现最常用的库，以便在有限的开发时间内使更多的用户受益。随着TinyLink使用的增加，我们可以得到更多的反馈，看看哪一些库应该以更高的优先级实现。

其次，我们尝试重用现有的库，只添加胶水代码来实现TinyLink api。编写胶水代码包括抽象统一的输入/输出接口，用宏替换依赖于硬件的代码，在API头文件中添加条件语法，等等。

图9展示了我们如何通过重用4个主板上的库来实现TinyLink API TL_LED.turnOn()。对于这四个主板，我们使用pinMode()函数来配置LED引脚行为，并使用digitalWrite()来开启LED。对于不同的平台，这些api的实现是不同的。在Arduino和LinkIt平台(Linux上的Arduino编程环境和VM)上，可以通过系统库轻松实现。在Raspberry Pi和BeagleBone平台(基于debian的Linux操作系统)上，可以使用第三方库实现，如wiringPi[21]和wiringBone[22]。当我们仔细选择现有库时，glue代码的实现开销相对较小。

最后，我们将允许应用程序开发人员参加到库的实现中。我们将发布在线开源的TinyLink图书馆，从长远来看，我们希望越来越多的物联网开发者加入到我们的行列中来，实现有用的库，并与其他开发者共享。首先，我们提供了用c++编写的组件模板，供开发人员为新设备实现TinyLink库。例如，为了实现一个简单传感器的库，开发人员可以使用我们开发的传感器模板，继承传感器类并实现像virtual int _read()=0这样的抽象接口。

值得注意的是，TinyLink生成的硬件配置可能会漏掉一些软件实现。为了解决这个问题，我们为开发者提供了两种选择:(1)提供最好的物联网硬件配置，应用开发者需要实现所需的库代码;(2)提供具有完整软件实现的次优解决方案。

5.4 Cross Compiler 

预处理后的代码需要在云上交叉编译为用于目标平台的二进制代码。TinyLink需要解决两个关键问题:(1)链接哪些库?(2)使用哪个交叉编译器?

TinyLink依赖于编码硬件配置的头文件TL_Config.h。在TL_Config.h中定义的主板类型决定了特定的交叉编译器。

图10显示了TinyLink如何将独立于硬件的应用程序代码与依赖于硬件的库链接起来。TinyLink库包括两个头文件，分别是TL_Library.h和<mainboard>_<peripheral>.h，用于将独立于硬件的api转换为依赖于硬件的api。对于图10所示的示例，TL_Library.h将包括TL_Config.h，以包括必要的功能模块，例如ESP8266_ESP01，根据TL_Config.h中定义的硬件配置，它同样包括Arduino_ESP8266.h。

 我们在表4中列出了四个主板的交叉编译器。Arduino UNO基于AVR ATmega，它利用AVR -gcc和AVR -g++编译器。LinkIt One是基于ARM7的，它利用了armnon -eabi-gcc和arm-none-eabi-g++编译器。分别带有ARM Cortex-A7和CortexA8的Raspberry Pi 2和BeagleBone Black都使用ARM -linux-gnueabihf-gcc和ARM -linuxgnueabihf-g++编译器。

 5.5 Interactive Debugging 

如果本地系统支持，TinyLink支持交互式调试。目前TinyLink在Raspberry Pi和BeagleBone Black上支持使用gdb对Debian系统进行交互调试。如果编写REQUIRE gdb需要进行gdb调试，TinyLink将编译应用程序代码以包含必要的调试信息。此外，还为开发人员提供了整个项目的源代码，包括高级应用程序代码和低级硬件依赖库代码。在此基础上，开发人员可以登录到平台中，使用gdb提供的断点、观察点、步进执行等功能对源代码进行调试。

6 EVALUATION 

在本节中，我们将介绍TinyLink的评估。第6.1节介绍了实验的设置。第6.2节显示了编程的易用性、可行的解决方案和开销方面的总体评估。在第6.3节中，我们研究了使用TinyLink和CodeFirst[12]的三个实际案例。

6.1 Experiment Setup

硬件组件。在图11中，我们列出了按功能分组的硬件数据库中的组件数量。在我们的数据库中有4个主板，10个shields和超过100个外设。四块主板包括Arduino UNO(简称UNO)、LinkIt ONE(简称ONE)、Raspberry Pi 2(简称RP2)和BeagleBone Black(简称BBB)。这些组件的特性(例如，分辨率和传感范围)也存储在我们的数据库中。

 基准。我们根据表3使用了6个常用的基准进行评估，它们是:(1)LED Write(简称LED)，它打开一个LED;(2) WiFi GET(简称WiFi)，向局域网内某网站发送HTTP GET请求并获取响应;(3)文件读写(File Write & Read，简称File)，将数据写入存储模块上的文件，然后读取数据;(4)温度读取(简称Temp)，从传感器读取温度数据;(5)湿度读数(简称Humi)，类似于温度;(6) Light Read(简称Light)，类似于Temp。

案例研究。我们使用了三个真实世界的案例研究，这是一个室内智能家居植物节点，已经在第2节描述，一个空气质量监测节点和一个语音控制LED灯节点。更多细节见第6.3节。

6.2 Overall Evaluation

6.2.1易于编程。

首先，我们比较使用TinyLink api和使用原始api(例如，硬件制造商提供的api)实现基准所需的代码行数。我们在4块主板上实现了6个基准测试，并报告了减少的代码行数。在图12中，我们可以看到使用TinyLink减少了从14.29%到94.67%的代码行数。在四个主板上减少的代码行数的平均百分比是52.58%。特别是在实现WiFi GET基准测试时，使用TinyLink api在所有主板上减少了超过94.40%的代码行数。这是由于简单的API设计和大量的glue代码实现的WiFi库。

其次，我们比较TinyLink和CodeFirst[12]之间的代码行数。CodeFirst使用27行代码实现了从温度传感器读取数据、在LCD屏幕上显示数据以及通过蓝牙传输数据的示例。这是在CodeFirst中拥有源代码的唯一示例。在TinyLink中，开发人员只需使用15行代码就可以实现具有相同功能的应用程序。

 6.2.2可行的解决方案。

TinyLink在对硬件数据库进行搜索后，可以生成许多可行的解决方案，并根据给定的优化准则(如总成本)选择最佳的方案。更大的搜索空间将提供更多的机会来产生更可行的解决方案，以及更好的解决方案。我们评估了6个小型基准测试和3个案例研究的可行解决方案，并将结果与CodeFirst[12]进行比较。图13显示了结果。对于每个基准和案例研究，我们计算可行解的数量，以及可行解集合中的最低成本。我们可以看到，TinyLink生成的解决方案比CodeFirst可行得多，而且对于每个基准测试和案例研究的总成本也低得多。在LED写和文件写和读基准中，CodeFirst不能生成任何可行的解决方案，因为它只使用外设通常不支持的端口与存储功能。

6.2.3开销。

现有库上的粘合代码的实现给生成的物联网应用程序带来了开销。下面，我们将计算执行开销、程序空间开销和内存空间开销。

执行开销。统一的TinyLink api的大多数实现都是对现有api的封装，开销来自于粘合代码。我们在基准测试中对API调用的执行时间进行了实验。表5显示了使用TinyLink api与使用原始api的相对执行开销。考虑到执行开销的大小(例如，UNO上的LED基准测试为0.75开销)，这个开销是可以接受的。

 程序空间开销。程序空间开销与实现的粘合代码量成比例。由于单片机结构的不同，我们采用不同的方法来测量程序空间。对于具有AVR MCU的UNO，程序空间是由.text和.data段的总和计算的。对于其他三个使用ARM MCU的程序，程序空间就是它们交叉编译的二进制程序的大小。

表6显示了程序空间开销。UNO和ONE的程序空间开销分别不超过3KB和31KB。考虑到它们的程序flash分别为32KB和16MB，这样的开销很小，也可以接受。BBB和RP2的开销大得多的原因是它们运行在Debian Linux系统上，并且它们的二进制程序是ELF格式的。但是考虑到他们的程序闪存至少有4GB, 100KB以内的开销可以忽略不计。

 内存空间开销。测量的内存空间开销由静态内存开销(例如.text， .data等)和运行时内存开销(例如，堆栈和堆)组成。表7显示，UNO的内存空间开销很小，相对于其他三个可以忽略不计。对于UNO来说，所有基准测试的开销都在171B之内，占其RAM大小的8.35%(即2KB)。对于ONE来说，所有基准测试的上限为21kb，即其RAM大小的1.03%(即2MB)。对于BBB和RP2，基准测试的开销在100KB以内，这是可以忽略的，因为它们的RAM分别是512MB和1GB。

 6.3 Case Study

 智能室内植物。

在成本最低的条件下，TinyLink和CodeFirst[12]的最佳硬件配置如表8所示。在TinyLink解决方案中，选择Base Shield V1.3，因为它可以提供UNO不包含的端口(Grove光传感器需要的端口)。CodeFirst的固定平台BetaBlocks包含端口，因此它不需要Shield。很明显，TinyLink解决方案的成本远低于CodeFirst解决方案的成本。这是因为BetaBlocks只使用端口的特性限制了对可行解的搜索空间。

 空气质量节点。

Mosaic是一种用于城市尺度传感[23]的移动传感器网络系统。mosaic节点的要求是每30秒测量PM2.5、PM10、位置、温度和湿度。然后通过GPRS将采样数据上传到云服务器上。并输出日志数据存储在SD卡中，以便进一步调试和开发。

我们打算同时使用TinyLink和CodeFirst构建这样的节点。生成的硬件配置如表9所示。Mosaic节点V1是[23]中使用的原始节点，这是非常昂贵的。由于LinkIt One的内置组件，TinyLink生成的硬件配置降低了大约41%的总成本。在表10中，我们可以看到TinyLink实现了Mosaic节点V1提供的所有功能。CodeFirst不能生成可行的解决方案，因为没有适合存储模块的接口。装配的TinyLink节点如图14(b)所示。

声控LED灯节点。

TinyLink适合构建智能家居应用。我们打算通过以语音命令为输入的智能设备来控制家电(例如LED灯)。我们通过TinyLink实现了一个声控LED灯节点。源代码只有51行代码。该系统定期从用户的声音中提取16kHz采样率，识别语音命令(如“开灯”和“关灯”)，在液晶显示屏上打印命令，并控制相应的家用电器。

表11列出了生成的硬件配置。TinyLink的硬件配置包括一个直接连接到Raspberry Pi 2 USB接口的USB桌面麦克风，一个Grove继电器模块和一个Grove LCD RGB背光模块，这些模块连接到一个shield GrovePi+的端口上。图14(c)显示了组装的节点。CodeFirst没有解决方案，因为它的主板缺少语音录音模块的接口。

录音API和语音识别API的库实现基于PocketSphinx，这是一个CMU的独立于扬声器的连续语音识别引擎[24]。

 7 DISCUSSION

讨论几个重要的问题

优化谁？

我们这次优化的是成本，还可以优化 可扩展性、能源消耗

可扩展性？未来可使用的未占用接口的数量。

能源消耗? 然而，在给定应用程序代码的设计期间准确地评估特定平台是一项艰巨的任务。下面描述了一种优化能源消耗的可能方法。首先，我们应该通过设计良好的基准(或数据表中报告的值)来估计不同平台上不同组件的每个TinyLink API的执行时间和能耗。其次，我们应该仔细分析应用程序代码，以获取诸如它调用了哪个TinyLink api之类的信息。通过以上信息，我们可以大致估算出整个代码对于不同平台上不同组件的能耗。最后，我们可以通过设置能源消耗优化标准和其他因素，如成本作为约束，来寻找能源消耗最小的平台。

TinyLink的可扩展性。

由于TinyLink的高层抽象，应用程序代码是独立于硬件的。TinyLink可以通过将其他mcu的特性包含到硬件数据库中，以及为新平台编写胶水代码来合并其他的MCU。因此，未来TinyLink也可以支持其他mcu(例如MSP430)。TinyLink使用COTS硬件组件，并处理如何以兼容的方式组装它们的问题。在目前阶段，我们认为TinyLink的主要目标是快速成型。我们认为TinyLink的快速原型制作方法对最终的生产具有重要的影响和指导作用。

代码迁移。

对于熟悉嵌入式系统(特别是硬件)的开发人员来说，代码转换确实是将现有代码从一个平台移植到另一个平台的好特性。对于其他开发人员，我们认为TinyLink是一个很好的方法，因为它大大减少了开发工作。通过tinylink抽象，代码是独立于硬件的，并且很容易通过云上的交叉编译在平台之间迁移。此外，TinyLink大量重用了Arduino编程风格，以避免学习曲线过于陡峭。由于代码转换是另一个方向的工作，我们将考虑它作为TinyLink未来可能的工作。

8 RELATED WORK 

TinyLink大量借鉴了之前的三大工作领域:硬件平台设计、硬件/软件协同设计和物联网快速开发。这些主题中的每一个都对TinyLink的设计和结构产生了重要的影响。

硬件平台的设计。随着MEMS技术的发展，我们看到了硬件工业的重大进展。早在2003年，著名的传感器网络平台Telos与TinyOS操作系统一起由加州大学伯克利分校的研究人员[25]发布。

传感器网络平台最重要的考虑是能源效率和小型化因素。这种专用的小平台的设计是困难的，需要专家的知识。例如,杜塔等人提出了一个构建块方法[6]硬件平台设计基于十年的集体经验,到达一个架构的通用模块,把常用的功能是与特定于应用程序的集成运营商满足独特的传感、电源、机械应用程序的约束。

 Andersen等人提出了一种新的硬件和软件平台[26]的设计，将移动、可穿戴、制造商和无线传感器网络技术结合在一起，以实现高度的协同和能源效率。

Sutton等人提出了一种用于自适应事件触发声学传感系统的设计方法[27]，并仔细考虑了适应性、响应性和能源效率。所有的工作都是为了设计一个系统性能良好的节能硬件平台。然而，在硬件经验和嵌入式软件方面的特殊知识为上层应用程序开发创造了障碍。TinyLink打算通过将硬件知识纳入我们的系统设计来消除这一障碍。

近年来，Arduino[28]和Raspberry Pi[29]等 Maker 领域也出现了重大创新。这些平台的特点是功能强大的处理器具有丰富的接口。这种发展趋势对我们的设计有重要的影响:(1)硬件组件及其组合已经实现了广泛的创新应用;(2)我们需要仔细考虑硬件组件之间的复杂连接以及不同平台上的API实现。

硬件和软件协同设计。硬件/软件协同设计方法使用综合策略来产生有效的硬件和软件划分。

与我们的工作最相关的是基于平台的设计(PBD)[30]。PBD的目标是从可能的平台配置的设计空间中选择和组成可用组件的子集(例如，配置)。一个好的、可实现的配置满足系统约束以及所有组件施加的假设。PBD是一个中间相遇的过程，它将抽象的顶层描述映射到更详细的底层实现，并通过定义允许性能评估的库来构建平台。

Peter等人提出了一种基于组件的描述语言CoDeL[31]，它允许系统设计者用可参数化的模型、属性和互连来将组件表示为系统的可重用构建块。从上层到下层的自动映射是复杂设计空间探索的过程，这通常是由可满足性(SAT)[32]求解器或整数线性规划(ILP)来实现的。

与PBD类似，TinyLink也采用了从应用程序逻辑到具体硬件配置的自动映射过程。PBD解决的是一个一般性的问题，而TinyLink解决的是具体的和实际的挑战，比如与硬件无关的api, COTS硬件组件之间的兼容性，在不同平台上粘合代码的实现。

物联网的快速开发。物联网系统的快速开发引起了工业界和学术界的广泛关注。

Shayne Hodge提出了[33]的一般想法，即构建一个类似于现代web应用程序的架构。在这个模型的一个非常高的层次上，物联网硬件通过网络(或Internet)将数据发送到后端软件进行存储和处理。用户界面被构建为一个web应用程序，这允许它在广泛的设备上被查看。然而，关于如何构建物联网硬件的细节并没有给出。

Matrix 项目[34]于2015年在Kickstarter上启动。该平台包含多达15个传感器，因此用户只需要创建物联网应用程序，而不需要考虑硬件。但是，平台是固定的，不能灵活地创建定制的物联网应用。

IOTIFY[35]是物联网的虚拟化引擎，帮助构建物联网应用程序。IOTIFY通过虚拟化云中的物联网端点，降低了处理硬件和大型网络的复杂性。与IOTIFY不同，TinyLink生成真实的硬件组件和应用软件。

. net Gadgeteer[36]是微软提供的一个集成平台，用于支持使用定制组件进行开发。开发人员可以借助Gadgeteer模块、. net微框架和3D设计工具快速构建设备。Wio Link[37]是一种类似的方法，它建立在Wio链接板的基础上。TinyLink专注于如何使用各种COTS组件快速开发物联网应用程序，而不是使用定制的组件。

最近的一种方法是代码优先设计，以原型化可穿戴设备[12]。硬件配置将从分析应用程序代码中生成，因为一个软件模块直接映射到一个硬件组件，而硬件依赖关系可以通过分析软件依赖关系来确定。然而，它假设一个固定的主板，限制了它的能力来拥抱一个多样化的COTS组件集合。

TinyLink的设计要复杂得多，因为它支持不同的主板，并且提供了针级抽象，并仔细考虑了shield。TinyLink还包括一些软件库，以方便上层应用程序的编程。

9  Conclusion

在本文中，我们提出TinyLink，一个为物联网应用快速开发而实现的完整的系统。TinyLink在硬件和软件设计上都使用了自顶向下的方法。开发人员只需要使用TinyLink api指定关键的应用程序逻辑，而不需要处理底层硬件。TinyLink将它们的代码作为输入，自动生成在目标平台上可执行的硬件配置和二进制程序。我们实现了TinyLink并使用基准测试和三个真实案例研究来评估它的性能。结果表明，TinyLink实现了物联网应用的快速发展，实现应用程序时平均减少了52.58%的代码行数，同时他的开销可以接受。

TinyLink：A Holistic System for Rapid Development of IoT Applications