CN108235755A - 一种物联网控制器用户界面的方法及系统 - Google Patents

Abstract

本发明公开了一种物联网控制器用户界面的方法及系统。本发明解决了应用程序开发和部署。本发明中的应用程序元数据编辑器允许开发人员指定元数据，该元数据指导实际数据的结构，该数据在特定终端用户的程序特定运行实例（或任务）调用时，可以传递给应用程序。一旦开发了应用程序并进行了测试部署，开发人员就可以将应用程序上传到在线应用程序商店。其他人可以从应用程序商店中下载和部署应用程序。数据编辑器允许终端用户根据开发者的元数据创建他/她自己的数据，使其执行适应他/她的特定需求。在允许灵活性的同时，数据编辑器确保所创建的数据遵循开发人员提供的元数据的整体模式。同时提供了基于众包模式的，国际化应用程序显示表达的工具。

Description

一种物联网控制器用户界面的方法及系统

技术领域

本发明涉及物联网（或称IoT）领域，并且更具体地涉及一种物联网控制器用户界面的方法及系统。

背景技术

已知的物联网设备的控制器包含两种类型的接口。第一种类型是可定制开发的，但只有专业的软件开发工程师才能操作。第二种类型的输入范围是非常有限的，但是对于一个没有编程基础的人来说也是可用的。第二种类型接口的局限性严重的限制了物联网控制器可以提供的适应性水平，而不采取第一种类型的接口，生产全定制软件需要极高的成本。

因此，需要提供比第二种类型的接口具有更大适应性的IoT控制器，同时避免第一种接口类型的开发成本。

发明内容

为解决上述现有技术存在的问题，本发明提出一种物联网控制器用户界面的方法及系统。

物联网控制器需要满足灵活性和可扩展性，必须要提供编程接口和整合第三方应用程序的架构。本发明之前的控制器，均采用云服务的架构，因其需求必须要满足收割用户数据之需要。鉴于现成的可抄袭的框架的局限性，它们均采用事件驱动和注册事件响应函数的架构。因此提供给编程者和用户的定制能力就会受到限制。

本发明采用虚拟机驱动虚拟进程作为物联网用户应用App实例。虚拟进程的输入可以是任意深度的，包含数组和键值对表的任意复杂数据结构。极大地提高了应用App的灵活性和用户定制的灵活性。特别地，本发明包含如下数据结构的定义以及用户界面的实现：键值表中包含键值表；同构数组中包含同构数组；同构数组中包含键值表；键值表元素包含同构数组。

本发明采用的技术方案是，一种物联网控制器用户界面的方法，包括：

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一元数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据表示的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一表格的元数据节点，添加相对应的第一表格数据节点给第一数据结构；

e)运行至少包括计算硬件和可编程存储器的配置，根据第一表格的元数据节点的指定结构，添加第一表格的数据节点所需要的至少第一和第二键值对；

f)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第二表格元数据节点的结构，向所述第一数据结构增加相对应的第二表格数据节点；

g)运行至少包括计算硬件和可编程存储器的配置，根据第二表格元数据节点的指定结构，添加第二表格数据节点所需要的至少第一和第二键值对；

h)运行至少包括计算硬件和可编程存储器的配置，将所述第二表格数据节点连接到所述第一表格数据节点，使得所述第二表格数据节点是所述第一表格数据节点的一个键值对的后代，即键值对的值；

i)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构作为第一应用程序的第一输入参数的第一自变量。

在另一实施例中，本发明提出的物联网控制器用户界面的方法，包括：

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一元数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据表示的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一列表型元数据节点，创建相对应的第一数据结构的第一列表型数据节点；

f)运行至少包括计算硬件和可编程存储器的配置，创建所述第一列表型数据节点使其能够接收数据的有序列表；

g)运行至少包括计算硬件和可编程存储器的配置，在所述第一图形用户界面中指示所述第一列表型数据节点时，接收来自所述第一终端用户的第一信号；

h)运行至少包括计算硬件和可编程存储器的配置，响应接收到的所述第一信号，识别第一子元数据节点，第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

i)运行至少包括计算硬件和可编程存储器的配置，响应所述第一信号并根据所述第一子元数据节点创建所述第一列表型数据节点的第一子数据节点最为列表元素；

j)运行至少包括计算硬件和可编程存储器的配置，当第一列表型数据节点被指示时，响应第一列表数据节点的每个附加信号，根据第一子元数据节点，创建所述第一列表型数据节点的附加子数据节点；

k)运行至少包括计算硬件和可编程存储器的配置，当第二列表数据节点在第一图形用户界面中被指示的时候，接收来自第一终端用户的第二信号，该第二列表型数据节点是所述第一列表型数据节点的后代，也就是第一列表的元素节点；

l)运行至少包括计算硬件和可编程存储器的配置，创建所述第二列表型数据节点使其能够表示数据的有序列表；

m)运行至少包括计算硬件和可编程存储器的配置，响应接收所述第二信号，识别与所述第二列表型数据节点对应的第二列表型元数据节点；

n)运行至少包括计算硬件和可编程存储器的配置，识别第二子元数据节点，该第二子元数据节点作为第二列表型元数据节点的唯一子节点描述了列表元素的数据类型；

o)运行至少包括计算硬件和可编程存储器的配置，响应所述第二信号，根据所述第二子元数据节点，创建第二子数据节点作为所述第二列表型数据节点的子数据节点代表列表元素；

p)运行至少包括计算硬件和可编程存储器的配置，当第二列表型数据节点被指示时，响应每个附加信号，根据第二子元数据节点，创建所述第二列表型数据节点的附加子数据节点；

q)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构。该第一数据结构作为所述第一应用程序的第一输入参数的第一自变量。

在另一实施例中，本发明提出的物联网控制器用户界面的方法，包括；

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一元数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据表示的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一表格的元数据节点，添加相对应的第一表格数据节点给第一数据结构；

e)运行至少包括计算硬件和可编程存储器的配置，根据第一表格元数据节点的指定结构，添加第一表格型数据节点所需要的至少第一和第二键值对；

f)运行至少包括计算硬件和可编程存储器的配置，创建第一列表型数据节点使其表示数据的有序列表，作为第一表格型数据节点的一个键值对的值；

g)运行至少包括计算硬件和可编程存储器的配置，当该第一列表型数据节点的一个键值对后代在在第一图形用户界面中被指示时，接收来自第一终端用户的第一信号；

h)运行至少包括计算硬件和可编程存储器的配置，识别第一列表型数据节点对应的第一元数据格式的第一列表型元数据节点；

i)运行至少包括计算硬件和可编程存储器的配置，识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

j)运行至少包括计算硬件和可编程存储器的配置，响应第一信号，根据第一子元数据节点，创建第一列表型数据节点的第一子数据节点；

k)运行至少包括计算硬件和可编程存储器的配置，当第一列表型数据节点被指示的时候，响应于每个附加信号，根据第一子元数据节点，创建第一列表型数据节点的额外子数据节点；

l)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构，使其作为第一应用程序的第一输入参数的第一自变量。

在另一实施例中，本发明提出的物联网控制器用户界面的方法，包括：

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一列表型元数据节点，创建相应的第一数据结构的第一列表型数据节点；

e)运行至少包括计算硬件和可编程存储器的配置，创建所述第一列表型数据节点使其能够表示数据的有序列表；

f)运行至少包括计算硬件和可编程存储器的配置，当所述第一列表型数据节点在第一图形用户界面中被指示时，接收来自所述第一终端用户的第一信号；

g)运行至少包括计算硬件和可编程存储器的配置，响应所述第一信号，识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

h)运行至少包括计算硬件和可编程存储器的配置，响应于所述第一信号，根据所述第一子元数据节点，创建所述第一列表型数据节点的第一子数据节点；

i)运行至少包括计算硬件和可编程存储器的配置，当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点，创建第一列表型数据节点的附加子数据节点；

j)运行至少包括计算硬件和可编程存储器的配置，响应于来自第一终端用户的第二信号，添加第一表格数据。该第一表格数据是第一列表型数据节点的后代，作为列表的元素；

k)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一表格元数据节点的指定结构，添加第一表格数据节点所需要的至少第一和第二键值对；以及

l)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构作为第一应用程序的第一输入参数的第一自变量。

本发明还提出一种物联网控制器的用户界面系统，包括：

一个或多个处理器和可编程存储器，其中系统配置包括：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据第一元数据格式的第一表格元数据节点来完成添加相应的第一对应表格数据节点给第一数据结构；

根据第一表格元数据节点来完成添加第一表格数据节点所需要的至少第一和第二键值对；

根据第一元数据格式的第二表格元数据节点完成添加相应的第二表格数据节点到第一数据结构；

根据第二表格元数据节点来完成添加第二表格数据节点所需要的至少第一和第二键值对；

完成将第二表格数据节点连接到第一表格数据节点，使得第二表格数据节点是第一表格数据节点的键值对的值；以及

完成将第一数据结构作为第一输入自变量提交给第一应用程序的第一参数。

在另一实施例中，本发明提出的物联网控制器的用户界面系统包括：

一个或多个处理器和可编程存储器，其中系统配置包括：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问所述第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据第一元数据格式的第一列表型元数据节点来完成创建第一数据结构的第一对应列表型数据节点；

完成创建第一列表型数据节点使其能够表示数据的有序列表；

在所述第一图形用户界面中指示所述第一列表型数据节点时，完成从所述第一终端用户接收第一信号；

响应于接收到所述第一信号，完成识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

响应于所述第一信号，根据所述第一子元数据节点来完成创建第一列表型数据节点的第一子数据节点；

当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点完成创建第一列表型数据节点的附加子数据节点；

当第二列表型数据节点，作为第一列表型数据节点的后代和列表元素，在第一图形用户界面中被指示，完成从第一终端用户接收第二信号；

完成创建第二列表型数据节点使其能够表示数据的有序列表；

响应接收第二信号，完成识别第二列表型数据节点对应的第二列表型元数据节点；

完成识别第二子元数据节点，即第二列表型元数据节点的唯一子元素描述了列表元素的数据类型；

响应所述第二信号，根据所述第二子元数据节点来完成创建所述第二列表型数据节点的第二子数据节点；

当第二列表数据节点被指示，响应每个附加信号，根据第二子元数据节点来完成创建第二列表型数据节点的附加子数据节点；以及

完成将第一数据结构作为第一输入自变量提交给第一应用程序的第一参数。

在另一实施例中，本发明提出的物联网控制器的用户界面系统包括：

一个或多个处理器和可编程存储器，其中系统被配置包含：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问所述第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据第一元数据格式的第一表格元数据节点，完成添加对应的第一表格数据节点给第一数据结构；

根据所述第一表格元数据节点来完成添加所述第一表格数据节点所需至少第一和第二键值对；

完成创建第一列表型数据节点使其能够表示数据的有序列表；

当第一列表数据节点，作为第一表格数据节点的一个子键值对的一个后代，在第一图形用户界面被指示，完成从第一终端用户接收第一信号；

完成识别第一列表型数据节点所对应的，第一元数据格式的第一列表型元数据节点，对应所述第一列表型数据节点；

完成识别第一子元数据节点，即第一列表型元数据节点的唯一子元素描述了列表元素的数据类型；

响应所述第一信号，根据所述第一子元数据节点来完成创建所述第一列表型数据节点的第一子数据节点作为列表元素；

当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点来完成创建第一列表型数据节点的附加子数据节点作为附加列表元素；以及

完成将第一数据结构作为第一自变量提交给第一应用程序的第一参数。

在另一实施例中，本发明提出的物联网控制器的用户界面系统包括：

一个或多个处理器和可编程存储器，其中系统配置包括：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问所述第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据所述第一元数据格式的第一列表型元数据节点，完成创建所述第一数据结构的第一对应列表型数据节点；

完成创建第一列表型数据节点使其能够表示数据的有序列表；

当第一列表型数据节点在第一图形用户界面被指示时，完成从所述第一终端用户接收第一信号；

响应所述第一信号，完成识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

响应所述第一信号，根据所述第一子元数据节点来完成创建所述第一列表型数据节点的第一子数据节点作为列表元素；

当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点完成创建第一列表型数据节点的附加子数据节点作为附加列表元素；

响应来自所述第一终端用户的第二信号，完成添加第一表格数据节点，该第一列表数据节点是第一列表型数据节点的列表元素；

根据第一元数据格式的第一表格元数据节点来完成添加第一表格数据节点所需的至少第一和第二键值对；以及

完成将第一数据结构作为第一输入自变量提交给第一应用程序的第一参数。

与现有技术相比，本发明提出了一种第二种类型的接口具有更大适应性的IoT控制器，同时避免第一种接口类型的开发成本。

附图说明

下面将结合附图及实例，对本发明做进一步说明。

图1A-1B展示了物联网生态系统的硬件视图和逻辑视图。

图2 显示了JSON格式的数据示例，用于规划智能恒温器物联网应用程序。

图3描绘了用于描述智能恒温器物联网应用的一组有效输入的元数据示例。

图4A-4C描绘了与图3相同的元数据的视图在一个图形用户界面的表达例子。

图5A呈现了一组文档节点500，其记录了图3的元数据的自然语言英语的表达。

图5B描述了图3的元数据也可以具有中文，俄文和西班牙文文档模块的事实。

图6A-6B描述了当语言模块从英文变为中文时图形用户界面视图如何改变的例子。

图7描述了用Lua编程语言编写的智能恒温器（称为“SevenDayThermostat”）的空函数。

图8A-8D描述了图7定义应用程序的具体Lua代码完全实现。

图9阐述了通用的元数据编辑器图形用户界面处理流程图。

图10A描绘了示例初始屏幕，元数据创建过程可以通过该初始屏幕开始。

图10B描绘了将“SevenDayThermostat”的显示名称改变为“QW: 7 DayThermostat”。

图10C描述具有原生名称“groups”的节点被指示为当前节点，选择下拉菜单的“List”类型以及添加详细信息。

图10D描绘了图10C中的进一步节点类型改变，节点原生名称设定为“thermostats”。

图11A和11B分别描绘图10A的图形用户界面视图对应的元数据和文档节点。

图11C-11D根据底层元数据和文档节点显示了来自图10B-10D所示的用户输入的最终结果。

图12A-12B 展示通过图形用户界面开始元数据的下一级分层结构。

图12C展示了第一参数的子节点，其初始默认类型“Number”被改变为类型“Table”。

图12D展示了已经添加了默认的子节点的第二参数，并且将其子节点的默认类型改变为“Thermostat”（恒温器）类型。

图12E显示“Table”表格节点重新作为当前节点，然后添加的“Details”字段到节点文档。

图13A和13B分别描绘了元数据编辑器图形用户界面已经达到图12E所示的状态时的元数据和文档节点的状态。

图14A-14B描绘了将第一默认键值对添加到第一参数的表格节点的子节点。

图15A-15B描述了创建默认键值对所导致的元数据和文档节点的变化。

图16A-16B描绘了第一个默认键值对的默认值被改变。

图17A-17B描述了将第一个键值对改为非默认值所导致的元数据和文档节点的变化。

图18显示了添加第二个键值对所导致的对图形用户界面的更改。

图19A-19B展示了添加第二键值对所导致的元数据和文档节点的变化。

图20A-20B展示了向第二键值对添加枚举节点。

图21A-21B说明了添加枚举节点所导致的元数据和文档节点的变化。

图22A-22B展示了将枚举值节点添加到枚举节点。

图23A-23B说明了由添加枚举值节点导致的元数据和文档节点的变化。

图24显示了在添加了所有枚举值节点后，生成的图形用户界面。

图25A-25B展示了通过添加所有枚举值节点而导致的元数据和文档节点中的变化。

图26显示了向类型“Table”（表格）的节点添加第三个键值对。

图27A-27B展示了通过添加第三键值对所导致的元数据和文档节点的变化。

图28作为展示了通用的参数编辑器图形用户界面的处理流程图。

图29A显示了参数编辑器的一个初始参数根数据节点示例。

图29B-29C描绘了参数编辑器的初始图形用户界面。

图30A在参数节点级别展示在“Schedules”节点下创建时刻表实例。

图30B-30C在参数编辑器图形用户界面中显示在“Schedules”节点下创建时刻表实例。

图31A显示了在参数节点“Thermostats”下添加恒温器的数据。

图31B-31C在参数编辑器图形用户界面中向“Thermostats”节点添加恒温器的实例。

图32A在参数节点级别显示选择特定恒温器的结果。

图32B-32C显示在参数编辑器图形用户界面中选择特定的恒温器。

图33A显示了在参数实例＃1的第一个键值对中，在参数节点层级上填充非默认数据值的结果。

图33B展示了在参数编辑器图形用户界面中针对时刻表实例＃1的第一键值对填充非默认数据值的结果。

图34A显示了在参数节点级别上的一个过程的前半部分，通过该过程添加了一个枚举值，以表示星期几。

图34B显示了在参数编辑器图形用户界面中，一个过程的前半部分，通过该过程添加一个枚举值，以表示星期几。

图35A表示在一个参数节点级别上，一个过程的后半部分的结果，通过该过程枚举值被设置为一个特定值，以便表示一周中的一天。

图35B-35C展示了在参数编辑器图形用户界面中过程的后半部分，通过该过程将枚举值设置为特定值，以表示星期几。

图36A在参数节点级别显示了将第一动作实例添加到“Actions”列表的结果。

图36B显示了在第一个动作实例被添加到“Actions”列表之后的参数编辑器图形用户界面。

图37A在参数节点级别显示了将第一个动作实例设置为非默认值的结果。

图37B显示了在参数编辑器图形用户界面中将第一个动作实例设置为非默认值的结果。

图38A描绘了用于提交给SevenDayThermostat应用的图形花的，参数节点级别的，参数数据的表示。

图38B-38C描绘了已完成的参数编辑器图形用户界面表示，以提交给SevenDayThermostat应用。

图39描述了一个纯粹出于说明可空属性的示例用法的目的而创建的示例“测试”函数。

图40A-40C描绘了在元数据编辑器中所显示的用于测试功能的元数据示例。

图41A显示了在示例终端用户参数编辑器屏幕中，在应用程序开发期间使用“Nullable”属性的优点。

图41B显示准备移除“Null”设置的终端用户。

图41C显示了删除了“Null”设置的参数编辑器。

图42表示元数据示例，其可以对应于图40A-40C的图形用户界面视图。

图43A在参数节点级别表示图41A的参数编辑器视图。

图43B在参数节点级别表示图41C的参数编辑器视图。

具体实施方式

我们将用文字和图形的方式详细说明本发明。为了便于阅读，文中存在大量的交叉引用。只要可能，在整个附图中将使用数字来标记各种交叉引用。应用程序软件在本文中可以更简单地称为“applications”，或者更简洁地称为“apps”。

一般来说，在附图中，如果一个节点用下划线数字标记，则该节点是一个交叉引用标记点。如果一个节点的数字用方括号括起来（例如[node-number]），则意味着在另一个图中代表一个交叉引用（或指针）到数字代表的标记点。通常，图形界面的视图也可以有额外添加的标记点。

请参阅标题为“术语词汇表”的章节，了解本文某些特定术语的定义。

目录

1.引言

2.物联网应用商店

3.物联网生态系统

4.元数据语言

5.元数据编辑或提取

5.1呈现元数据

5.2创建元数据

6.参数编辑器

6.1概观

6.2构建一个论据

7.属性

8.附加信息

8.1物联网设备

8.2计算机设备

9.术语词汇表

详细说明

1.引言

为了更好地理解本发明，通常把计算机系统分为两个主要的类别：

○那些被终端用户视为通用设备的设备。

这种机器的标准术语是通用计算机（或GPC）。

○很多终端用户不知道他们使用的产品中包含了GPC。然而，制造商并没有使用专用硬件来生产产品，而是选择嵌入配备了定制的应用程序和数据的GPC。这种机器的标准术语是嵌入式系统。

虽然这两类计算机已经沿着相对独立的道路发展，但物联网技术提供了两种类型的系统进行组合的机会。

用GPC平台编写的终端用户应用程序的一个基本假设，是如此基本以至于很难将其视为是一种假设，即当终端用户使用应用程序的功能时，实际上是在GPC中， 或通用接口设备上。换句话说，终端用户在一个非常类似于应用程序编写的硬件环境中与应用程序进行交互。由于终端用户不能预期电脑或其接口设备的生命周期，所以使用应用软件必然是偶发事件，并且由终端用户做出判断。

虽然这个基本假设是从一台占用一个大房间的空间的计算机开始的，它仍然适用于所谓的个人计算机革命。换句话说，即使在台式机或笔记本电脑中，终端用户仍然需要身临其境，以便在通用接口设备上使用应用软件。

这种应用程序的使用场景和认识在引进智能手机后继续存在。智能手机的主要“革命”导致GPC变得如此之小，终端用户可以（从个人空间和能量使用的角度来看）将电脑实际携带到他或她身上很长时间（如果需要的话，可以全天候携带）。同时，智能手机在开发者和终端用户的GPC硬件所使用的GPC环境之间引入了更大的差异。

尽管存在这些差异，智能手机应用程序使用的基本模式仍然保持不变。每个应用程序仍然被视为一种单独的专门的“工具”，终端用户将根据需要专门调用。从一个应用程序，回到一个智能手机的主屏幕，终端用户不仅仅启动另一个工具，而且也隐含了他/她暂时结束了他/她正在使用的工具。

通常认为需要连续操作的智能手机的这些方面，诸如可从其开始应用的连续可用的主屏幕，被认为是其“操作系统”的一部分。

相比之下，GPC作为一个嵌入式系统使用时，具有非常不同的使用情况。

如上所述，嵌入式系统的定义特征是其操作不依赖于终端用户与通用计算平台交互。终端用户不需要在嵌入式系统中明确“启动”或“停止”应用软件。嵌入式GPC一直致力于某些独立的应用程序，并且该应用程序始终运行（或者至少始终可用）。因此，与GPC应用程序相比，嵌入式系统可能会花费大量的运行时间 - 等待那些需要为终端用户感觉到的“事物”的时刻。

我们致力于应用程序和数据，将GPC适配成为一个嵌入式系统。包括应用程序的适应性和数据的实用性。

在传统的嵌入式系统中，自适应应用程序和数据基本上由制造商一次创建。

嵌入式系统设计的解耦合是IoT技术的一个潜在的革命，这样一个GPC就可以装载多个，变化的自适应应用程序和数据集合。

这种后期制造可编程性至少提供以下优点：

在没有创建新的物理产品的制造能力的情况下，对现有已有的产品从新方法的新概念的角度进行整合。

通过依靠终端用户可编程能力的后期制造，以较少的制造量创造新的物理产品。

因此，新产品不一定需要提供所有自己的硬件，而是可以依赖于创新与现有产品交互（或利用）的能力，终端用户可以期望拥有或获得该产品。

像常规嵌入式系统的控制器一样，根据本发明的原理构建的在IoT控制器上执行的大多数应用程序基本上可以全天候执行，等待当其功能需要的那一刻。

此外，像常规嵌入式系统的控制器一样，终端用户通过功能特定的硬件与正在执行的IoT应用进行交互。在正常操作期间，终端用户不需要知道在哪里存在具有GPC硬件的“盒子”（其可以是云计算数据中心）。

然而，与传统嵌入式控制器制造商不同的是；传统制造商控制整个硬件环境，而IoT应用程序的终端用户必须能够使程序适应他或她的特定硬件组合。

此外，我们需要超越在传统制造的产品上提供“控制面板”，因为这样的控制面板通常难以学习，同时为终端用户的定制提供了非常有限的机会。

2.物联网应用商店（App Store）

在销售“应用”的“商店”推出之前，物联网技术的现状类似当时智能手机技术的现状。这样的商店（或“应用商店”,App Store）将软件的开发者与终端用户紧密联系起来。智能手机有很多潜在的用途，一家公司试图去创建和销售覆盖所有情况的程序根本没有意义。此外，对于许多应用而言，个体市场并不需要大型企业组织来进行市场营销和销售。通过降低开发人员将应用程序推向市场的交易成本，可使智能手机享有更加广泛的“工具”满足各种潜在用途。

但是，在考虑应用商店方式是否适用于物联网的情况下，必然会遇到以下现实：智能手机应用程序软件的流行硬件平台标准化。目前两个主要平台是Apple的iOS和Google的Android操作系统。这些操作系统为程序员提供了一个简化和统一的模型，用于运行任何手机程序。

然而，在物联网技术，像手机这种标准化和简化模型是不可能的。鉴于物联网硬件的异构特性，问题变成是否有可能制定一个类似智能手机操作系统提供的标准化和简化的模式，以便于在希望开发应用程序和希望使用应用程序的人之间，实现应用程序交换。物联网应用的另一个问题是如何实现图形用户界面（图形用户界面），终端用户可以通过图形用户界面来选择自适应程序执行，并输入特定的适配数据（我们将参考特定适配程序，根据特定适配数据在特定的IoT控制器上运行 ，称为一项任务）。智能手机集成了无论应用程序是否正在运行都始终可用的输入/输出设备（例如触摸屏）。物联网控制器通常不包括这种外设。

本发明主要是提供一种被称为“参数编辑器”的图形用户界面。这个接口使终端用户可以更容易地适配物联网应用程序，提供一致的，相对简单易用且富有表现力的界面。通过将参数编辑器作为强制性部分，提供在物联网控制器上运行的任何应用程序的启动参数，至少部分地保证了操作的一致性。因此，本发明可被视为物联网控制器的操作系统的一部分。而作为一种替代方法，应用程序开发人员可能需要在其代码中包含特定的接口，如此保证一致性将是一个更加疲劳且易于出错方法。

通过提供一个标准框架，在为终端用户提供这些优点的同时，本发明不会使开发者更难以编程，并且将很可能给开发者更多辅助。

参数编辑器的基本思想包含两个主要部分：

定制当应用程序实例被运行的时候所需的一个或多个初始参数。

提供一个图形用户界面，使非技术用户能够相对容易地构建相对复杂的初始参数。

这些初始参数（以及终端用户选择的物联网应用程序）可以扮演类似于传统嵌入式系统中的适配程序，适配数据或二者的角色。

实际上，与传统的嵌入式系统设计相比，适配程序和适配数据的设计分为两个阶段：

第一阶段，由应用程序开发人员进行。 在这个阶段，应用程序开发人员决定应用程序的哪些方面可以接受终端用户调整，以及应该使用哪种数据结构来表达。这些数据结构的描述称为 “元数据”（meta-data）。一般来说，有三种主要的方式可以创建元数据：

元数据可以由开发者使用“元数据编辑器”的工具“手动”创建。

元数据可以通过算法从应用程序的源代码中提取出来。

可以使用上述两种方法的组合。

在第一阶段完成后，与传统的嵌入式系统相比，IoT应用程序仍然是不完整的。它需要进一步的信息。只有传递给它特定的初始适配数据，IoT应用程序才能转换成在特定硬件环境中执行特定行为的一个实例。

在第二阶段，终端用户使用上面引入的“参数编辑器”，其操作由第一阶段的元数据做引导，以便制定应用程序的初始参数。

尽管计算机科学领域已经开发了多种数据的元数据表示，本发明的关键是识别以下两种结构化技术，在IoT控制器的应用软件的环境中特别有用：

树的数据结构；

同构列表结构。

同构列表结构在此所指的是数据结构的有序列表，其中列表中的每个元素满足以下两个条件：

1.每个都有相同的组织结构。

2.所有占据相同位置（相对于组织结构）的节点具有相同的类型，并且（如果存在）具有相同的名称。这两种元数据代表了强大的中间立场，因为它们都具有以下两个属性：

1.每种方法都可以让开发人员为终端用户的应用程序行为提供相对丰富和具有表现力的选择规范。

2.虽然丰富而富有表现力，但每个这样的构造技术仍然很容易被没有编程（或任何其他技术）基础的人理解：

○树的数据结构在大多数人的日常生活中有许多常识可以类比。

○树结构”这个名字本身就是源于一个生物学例子。

○同构数据组结构在日常生活中也有许多常识类比。

○“千篇一律”的复制就是这样的一个类比，因为它捕捉到创造无限数量副本的方法，这是一种常见的类型。

此外，这两个元表示在递归嵌套组合时特别强大。递归嵌套组合有四种基本类型：

1.在更高级别的树结构中使用树结构。

2.使用同构数据组结构作为更高级同构数据组结构的每个成员。

3.使用同构数据组结构作为更高级别树结构的一部分。

4.使用树结构作为更高级同构数据组结构的每个成员。

应用程序开发人员在上述第一阶段输入的元数据的另一个重要方面是文档问题。元数据的文档对于开发者和终端用户都是重要的，但是对终端用户来说尤其重要。因为文档就是终端用户图形用户界面的表达（文字和图像的组合）。本发明利用了两阶段，允许在与元数据紧密结合的第一阶段输入文档。具体而言，可以为元数据的每个节点提供相应的文档节点。每个文档节点通常至少配备以下两个字段：

显示名称（DisplayName）：与节点相关联的计算机可读名称（在此称为节点的“原生名称”（native name））。在接受用户输入适配数据的时候，在图形用户界面上显示“显示名称”，向终端用户提供最大可理解性。显示名称的长度一般不超过几个字。

详细信息（Details）：此字段允许开发人员输入比显示名称长的文档。通常情况下，如果使用“详细信息”字段，输入的文档至少有一个句子的长度。通过在图形用户界面上允许用户查看数据对性的详细信息，可以给用户提供更多的理解。

通过提供紧密耦合的文档，在使用参数编辑器期间，图形用户界面能够以相对简单的方式向终端用户显示这些文档。方便用户理解。

除了紧密耦合之外，需要将这些文档保存为逻辑上独立的模块。保持逻辑分隔至少提供以下两个优点：

1.由于文档与元数据分离，因此也可以在元数据编辑器以外的图形用户界面中使用。具体而言，即使在开发人员发布物联网应用程序后，其文档也可以由终端用户通过参数编辑器界面进行显示。

2.由于文档可以由终端用户维护，这样终端用户就有可能为文档坐车贡献，以便应用程序能够被更广泛地使用。例如，假设一个应用程序可以有多个文档模块，每个文档模块专用于不同的自然语言。假设一个app_1的开发人员只知道一种自然语言（称之为“自然语言1”）。此外，假设终端用户知道自然语言1以及另一种自然语言（称为“自然语言2”）。开发者可以提供专门用于自然语言1的app_1的文档模块。终端用户可以添加另一个专用于自然语言2的app_1文档模块。

对于以静态类型编程语言（如Java）编写的应用程序，其元数据可以从代码中自动提取。然而，对于以动态类型编程语言（如Lua，Javascript）编写的应用程序来说，一般情况，描述其潜在参数的元数据不能以自动方式完全提取。

物联网生态系统

如下我们将通过具体例子进一步介绍本发明的元数据语言。但是，在做这件事之前，先介绍一个物联网生态系统的例子，通过这个系统可以找到合适的物联网应用，然后再应用。

图1A中描绘了根据本发明的原理的物联网生态系统的示例。图1A描绘了示例部署地点100，诸如家庭，办公楼或工厂，其中终端用户相信可以受益于IoT技术。 在部署地点内展示了IoT控制器120。它形成一个控制中心，用于管理一个或多个物联网（IoT）网络，其上运行一个或多个物联网设备。 IoT网络的具体示例将在“附加信息”部分的“物联网设备”小节下进行讨论。

图1A描绘了两个正在使用的物联网：物联网1和物联网2。对于这些IoT网络中的每一个，控制器120被示为分别具有对应的收发器124和125。这两个网络中的每一个也分别显示为具有部署的n个和i个设备。这样的IoT设备可以用作输入设备（例如传感器或开关），输出设备（例如，控制电源插座，灯或电动机）或输入输出设备。值得注意的是，至少目前大部分物联网网络协议是用于无线网络，其中也有使用有线网络的协议。为了简化连接和普及设备应用，促使厂商专注于无线连接。

在部署地点100内还展示了更传统的LAN类型的网络110，通过该LAN类型的网络110，控制器120（通过其LAN协议收发器123）获得因特网访问（在该特定示例中，通过电缆或DSL调制解调器113）。LAN 110还被部署为客户提供连接。这样的客户端可以用于IoT应用软件（例如，开发者客户端111）的开发者，IoT应用软件的终端用户（例如，终端用户客户端112）或两者。

在内部，控制器120包含通用计算系统122，作为控制器120的主要子系统（例如，子系统122-125），它们通过共同的外设总线121彼此通信。

其基本思想是终端用户希望在他/她的部署地点100处为他/她的控制器120（并且更具体地在通用计算系统122内）安装合适的应用程序。从而受益于物联网技术。尽管控制器展示的位置位于部署位置处，但可以容易地认识到，通用计算系统122的功能可以位于远程。例如，这种通用计算可以通过所谓的“云计算”来提供。

然而，为了向终端用户提供更高水平的隐私和控制，使用作为专用硬件单元的通用计算系统122在物理上位于部署位置可能是有利的。专用硬件单元可以是例如所谓的“Raspberry Pi”（由英国注册慈善组织Raspberry Pi Foundation提供）。

即使可以达到所需的隐私和控制水平，基于云的控制器仍然会受到至少以下两个缺点的影响，这两个缺点都是由于云需要通过广域网（WAN）连接运行到 部署位置：

连接中断：互联网本质上是不可靠的，并且可能会发生连接中断。在普通的网页浏览或电子邮件通信等情况下，这种中断是可以容忍的。但是，如果互联网连接成为提供实时服务和控制的关键路径的一部分，则连接中断变得完全不可接受。例如，如果基于云的控制器正在控制加热系统，为了提供更高的能源效率，仅仅因为互联网连接暂时不可用，导致部署位置失去供暖。

更高的延迟：控制回路如果包含来回的互联网访问，将具有比保持在本地更大的延迟。例如，考虑电灯开关的情况，其实际上打开或关闭位于同一房间内的照明设备供电的电路。用户期望照明设备在墙壁开关已经被置于“接通”位置之后几乎即刻打开。现在考虑一下这样的情况，即灯开关已经被物联网墙壁开关所取代，并且照明设备被IoT控制。根据互联网流量，当物联网墙壁开关的特定实例处于“开”位置时，物联网交换机的信号穿越互联网之间可能存在非常显着的延迟，甚至达到几秒， IoT照明设备才经过互联网之后接收“开”信号。

图1A还描绘了IoT App Store 101。应用程序商店可以提供各种搜索工具，终端用户可以通过这些工具查找他们所需要合适的物联网应用程序。App Store可以通过网站界面（例如，通过基于网页浏览器的界面或者类似技术），这里可以将其称为“App Store终端用户界面”。通过这个界面，应用程序一旦被终端用户找到，就可以被下载到终端用户的客户端上。

下一步，能够利用所找到的应用程序，使终端用户能够在他/她的IoT控制器120上安装并运行该应用程序。在IoT控制器上终端用户可以完成应用程序的安装和执行，在这里可以被称为“IoT控制器终端用户界面”。

为了强调终端用户的行动可以在部署地点或其他地方执行的事实，图1A中示出了两个终端用户客户端：位于部署位置的终端用户客户端112，以及 终端用户客户端132，其可以位于任何位置。可以看出，终端用户客户端112通过部署位置的LAN与IoT控制器120通信。具有任意互联网连接的终端用户客户端132也可以与IoT控制器120通信。可以通过使用动态DNS服务器（在图中标记为102）来辅助这种类型的WAN连接。

在终端用户能够使用App Store或IoT Controller终端用户界面之前，至少有一个应用程序必须已经可用于下载（我们也称为“发布”）。应用程序开发者发布的界面在这里可以被称为“App Store开发者界面”。

关于开发人员对应用程序的设计和编程，可以使用“物联网控制器开发人员界面”来完成。这个开发者的接口包括任何合适的软件工程工具，比如适当的IDE。开发者界面还需要在应用程序发布之前对其进行测试。

正如上面对终端用户所展示的，为了强调开发者采取的行动可以在部署地点或其他地方执行的事实，图1A中示出了两个开发者客户端：开发者客户端111，位于部署位置 ，以及可以位于其他地方的开发者客户端131。

虽然终端用户客户端112和132被展示为智能手机，并且开发者客户端111和131被展示为桌面，这并不是必须如此。 终端用户客户端以及开发者客户端可以是任何种类的通用计算系统。

图1B描绘了同一种物联网生态系统的逻辑视图，图1A从硬件的角度展示。为了协助将这两个数字相关联，IoT控制器在两个图中都编号为120。 同样，图1A和1B中的AppStore编号为101。然而，这两个数字之间的差异包括以下几点。

图1B简单地从逻辑的角度表明，物联网生态系统包含一个或多个终端用户图形用户界面（由框171表示）和一个或多个开发者图形用户界面（由框181表示）。终端用户图形用户界面被终端用户170使用，而开发者图形用户界面被开发者180使用。

上面讨论的IoT控制器终端用户界面和App Store终端用户界面（其在图1A中没有特定的图形表示）分别由图1B中的双向箭头172和173表示。同样地，上面讨论的IoT控制器开发者接口和App Store开发者接口在图1B中分别由双向箭头182和183表示。

从逻辑角度分析，使用何种类型的网络将各种物联网设备连接到物联网控制器并不重要。因此，图1B没有显示网络类型，物联网控制器可用的所有物联网设备都被视为一个组，共包含j个设备。

在物联网控制器120内，图1B表示一个软件工程体系结构，其由两个主要部分组成：一个主进程（编号150）和一个应用程序引擎（编号151）。 进一步描述如下。

当终端用户在他/她的IoT控制器上提交特定的IoT应用程序用于实际执行时，该应用程序的执行实例在这里可以被称为“任务”。在图1B的软件体系结构可以看出，这些任务的实际执行由应用程序引擎处理。有图1B可以看出，应用程序引擎151被描绘为当前执行总共k个任务。为了系统稳定性和安全性，这些任务中的每一个都显示为在其各自的沙箱上执行。

对于终端用户希望执行的每个IoT应用程序，其至有一个可执行副本必须存储在IoT控制器上。对于图1B，该存储由标题为“应用程序存储”的数据库155表示。除了存储应用程序的副本之外，物联网控制器还需要存储各种相关的信息，通过这些信息来跟踪应用程序存储中的文件。这种信息的存储由标题为“应用程序数据库”的数据库156表示。

在一次运行过程中，每个图形用户界面和应用程序引擎都产生并响应消息。在这种消息传递方式下，主进程150可以提供消息转发服务。而且，各种物联网设备可以通过消息传递与应用程序引擎上的各种任务进行通信。对于这种类型的消息传递，主进程可以提供消息转发。另外，主流程可以包括管理各种物联网网络，以及确定物联网设备的状态。

在图1B中将App Store 101描绘为与基于云的服务提供者一起实现。 描绘了AppStore的三个主要功能：

应用程序搜索引擎（编号为160），终端用户可以通过它搜索满足其个人需求的应用程序。

当应用程序由开发者发布时，其本身的存储。以数据库161表示。

存储有关可用应用程序的信息。以数据库162表示。

4元数据语言

现在已经提供了一个物联网生态系统的示例，上面讨论的应用程序元数据由应用程序开发者创建，下面将进一步详细介绍。通过一个真实世界的问题来讨论元数据，这个问题可以通过一个物联网应用程序来有效解决。

使用恒温器来调节建筑内部温度的问题。众所周知，通过提供“更智能”的加热和冷却控制，能够获得大量的能源效率。这对于各种室内环境都适用，包括但不限于：商业，工业和住宅。就这个例子而言，重点将放在住宅用途上。

一种更智能的温度控制的方法是向终端用户提供一个接口，通过该接口编程设定温度范围变化的时刻表。在这种类型的程序中，允许终端用户基于星期和时间来指定期望的温度范围。

对于这个物联网应用程序，编写它的初始化函数时包含以下两个参数：

第一个参数接受终端用户指定温度范围的时刻表。

第二个参数接受一个或多个恒温器的列表，这些恒温器将根据第一个参数提供的时刻表进行控制。

在开始编程之前，规划程序参数的数据结构是一个好的编程习惯。这样做的一个示例格式是称为JSON（标准ECMA-404，ECMA国际，日内瓦，瑞士）的数据交换格式。

图2显示了这些参数的示例结构（JSON）。在第二行是第一个参数称为“groups”，而第二个称为“thermostats”的参数在第52行。

关于第一个参数，除了它的“groups”名称外，它还是一个有序的列表，这个列表从第2行的方括号（即“[”）开始，到第51行方括号（即“]” ）结束。该列表包含两个项目：

第一个键值对的表格，从第3行的开括号（即“{”）开始，到

32行结尾大括号（即“}”）结束。

第二个键值对的表格，从33行的开括号（即“{”）开始，到第50行的结尾大括号（即“}”）结束。

正如展示的那样，第一个和第二个表格都是温控器遵循的完整时刻表。因此，我们将第一个和第二个表格称为第一个和第二个时刻表。可以看出，开发者已经将每个时刻表构想为由三个键值对组成，其中键名是“name”，“weekdays”和“actions”。对于第一个时刻表，三个值的位置和内容如下：

第4行：“name”键对应的值是存储对终端用户有意义的计划名称。对于开发者设想的终端用户场景，终端用户已经将名称设置为“工作日”（Business Days），因为这个第一时刻表旨在成为终端用户离开他/她的时间的那些日子的适用的取暖/空调时刻表， 她的住所工作。

第5行：“weekdays”键对应的值是用来存储计划适用的星期几。在这种情况下，开发人员正在设想一个周末到周五标准工作周的终端用户。开发人员设想一周中的日子由枚举类型表示，其中每天用0-6范围内的整数表示。此外，对于该整数范围，日期名称的对应顺序是星期日至星期六（即星期日由0表示，星期六由6表示）。 因此，星期一至星期五由数字1-5表示。所选择的时刻表适用的日期存储在第5行的列表中

第6-31行：键“actions”对应的值在存储适用的温度范围列表，以“工作日”指定的星期几。除了存储取暖和空调的设定点之外，每个温度范围还存储适用的时间。对于第一个“工作日”时刻表，开发者已经设想了四个温度范围，每个温度范围是具有四个键值对的表格。这四个表格的位置以及每个表格中四个键值对的设置如下：

第7-12行的表格：

键“actionName”（见第8行）对应的值被开发人员设置为对终端用户有意义的名称。终端用户被设想为将名称设置为“起床”（Wake），因为该表格旨在表示终端用户在工作日第一次起床时的温度范围。

键“time”（见第9行）对应的值设置为该温度范围适用的时间。为了这个规划的例子，开发人员设想一个终端用户在工作日上午6点醒来。

键“heatSetPoint”和“coolSetPoint”（见第10-11行）对应的值分别被设置为该表所表示的温度范围的所需上限和下限。可以看出，开发人员正在设想一个终端用户在准备离开工作时温度在70-74°F范围内。

第13-18行的表格：

终端用户（见第14行）将名称设置为“离家”（Leave），因为该表格旨在表示当终端用户离开工作时的温度范围。

终端用户（见第15行）在上午8点开始工作。

在开始工作时，开发人员设想一个终端用户，他能够将自己的住宅温度保持在64-80°F的较低的范围内（见16-17行）。

第19-24行的表格：

终端用户（参见第20行）将名称设置为“回家”（Back），因为该表旨在表示终端用户从工作中返回时的温度范围。

设想终端用户（见第21行）在下午6点回家。

当晚上回到家中时，开发者设想一个终端用户喜欢温度在70-74°F范围内。

第25-30行的表格：

设想终端用户（参见第26行）将名称设置为“睡觉”（Sleep），因为该表旨在表示终端用户睡眠时的温度范围。

设想终端用户（见第27行）将在晚上10点睡觉。

在睡觉的时候，开发人员设想一个终端用户，他发现温度范围较低的68-72°F，要么更好，要么更便宜，可以接受。

可以看出，第二个时刻表与第一个时刻表具有相同的结构，但有两点不同：

原始数据值在两个时刻表中的相应位置之间往往是不同的。例如，对于每个时刻表的第一个键值对，值设置为对终端用户有意义的名称。如上所述，对于第一个时刻表，给予时刻表的名称是“工作日”（Business Days）（第4行），而对于第二个时刻表，给予时刻表的名称是“周末”（Weekends）（第34行）。这是因为第二个时刻表旨在指定终端用户不工作的那些日子的可接受温度范围。类似地，虽然第一个时刻表指定代表星期列表的值为从1到5五个数，但第二个时刻表该列表值为0和6。如上所述，这些整数被分配为枚举类型的一部分，其中整数0-6对应于星期天和星期六的日子。因此，0对应于星期天，6对应于星期六。

列表元素的值在两个时刻表中也往往是不同的。例如，刚才讨论的星期枚举例子就是这样。在这种情况下，第一个时刻表的名称是“工作日”（Weekdays），包含五个元素（星期一到星期五），而第二个时刻表的“周末”（Weekends）列表只包含两个元素（星期六和星期天）。另外，虽然第一个时刻表的“actions”列表指定了四个温度范围，但第二个时刻表的“actions”列表仅指定以下两个温度范围：终端用户在上午7点被设想为醒来（见第39行）（这比在工作日稍晚）。在家时，开发人员设想一个终端用户喜欢温度在70-74°F范围内。

第37-42行的表格：

设想终端用户（见第38行）将名称设置为“Wake”，因为该表格旨在表示终端用户在周末起床的温度范围。

设想终端用户在早上7点（比工作日稍晚）起床（见第39行）。

开发者设想终端用户喜欢温度在70-74°F范围内

第43-48行的表格：

设想终端用户（见第44行）将名称设置为“Sleep”，因为该表格旨在表示终端用户在周末睡觉时的温度范围。

设想终端用户在晚上11点（比工作日稍晚）睡觉（见第45行）。

在睡着的时候，终端用户指定了一个工作周夜间（68-72°F）适用的温度范围。

第二个时刻表仅指定两个温度范围，因为事先不能预知周末期间终端用户不在家时的时间。

计划中的第二个参数（第52行），它的名称为“thermostats”(恒温器)，其在图2中显示为具有下列数字标号的有序列表：103和115。假定这些数字中的每一个都标识了终端用户的物联网系统中的一个可控恒温器。因此，恒温器103和恒温器115并行地接收与两个时刻表所产生的相同的一组命令。在规划过程的这个阶段，为了创建一个提供智能恒温控制的IoT应用程序，开发人员应该对所需的结构（第一个和第二个参数）有一个良好的规划。然而，这种理解没有形式化，因此不能作为基础来指导终端用户未来创建自动化所需要参数。

我们需要某种形式化的元语言，通过这种语言来指定所有可能的结构集合。

图3提供了图2智能恒温器示例的正式规范。作为元语言的具体应用，在此将其称为元数据的例子。图3给出了一个树结构，其中每个节点至少有以下两个字段：

原生名称：指定在写入时应用程序的实际代码中使用的名称。

类型：节点提供的数据表示的类型。 节点的类型可以分为两大类：

叶子节点或“primitive”：至少代表与其相关的应用程序的编程的原始数据类型的节点。这个类别可以包括程序员普遍期望的编程语言（例如数字和字符串）中的任何内置数据类型。

相对（Relative）：节点类型取决于与其子节点的节点类型。下面列出了两种相关的主要数据类型。它们与上面讨论的两个数据元结构相对应，在表达性和可理解性之间提供了强有力的中间立场：

表格：允许数据的树形结构（一系列键值组）。

列表：允许同构数据组的定义。

对于本节的其余部分，图3被用作介绍其描述的元语言的工具。在下一节中，将介绍一些技术，通过这些技术可以通过一个图形用户界面（一个元数据编辑器）交互式地创建元数据，自动提取或两者的组合。

关于图3的顶级节点330，它指定了最初调用应用时调用的顶级函数的名称：SevenDayThermostat。

它的两个子节点331和361每个都标有额外的“参数”（parameter）属性，因为每个节点都是SevenDayThermostat参数的根节点。

参数节点331是被称为“groups”的同构列表的头部，对应于图2的线2。为了强调数据结构在“groups”列表的所有成员中是同构的，虚线340已被添加到图3中。

在图2中，上面讨论的第一和第二时刻表中的每一个都对应于虚线340内的数据的一个结构化的实例。

显而易见，“groups”列表的每个实例的结构都遵循节点341。节点341是表格类型，并且由节点342,343和344所表示的三个键值对组成。列表元素的一个例子就是上面关于图2讨论的第一个时刻表，三个键值对分别从行4,5和6开始。我们可以看到，节点342,343和344 的 “原生名称”（native name）取值，对应了图2中相应的键值对中的“键”的部分。

节点343和344中的每一个都是“List”（列表）类型。对于节点343，每个列表项是一个简单的枚举值（由节点345表示）。但是，节点344指向另一个同构结构，被包围在虚线350内。同构结构350作为同构结构340的成员嵌套在同构结构340内。根据图2，同构结构350的每个成员表示温度范围。如上面关于图2所讨论的那样，对于第一和第二时刻表中的每一个，都嵌套有温度范围的列表。例如，关于图2的第一个时刻表，四个温度范围从第7,13,19和25行开始。参数节点361对应于图2的线52的名为“thermostats”的列表。每个恒温器都被视为原始数据类型的一个实例，称为“thermostat”。这使得“thermostats”列表非常简单。因此，在形成这种同类的组时，不需要使用复杂的相对类型。

关于列表型元数据（list），值得强调以下几点：

对于任何特定的列表，只有一个类型为“List”的节点，并且它是该列表的头或入口的节点。

为了确保同构元素的列表，列表的头节点只能有一个直接子节点。当然，通过表格型数据结构以及可空（nullable）元素的组合，可以模拟出任意有限异构列表。

列表头节点的直接子节点没有原生名称。这是因为在“运行时”（即，当终端用户实际上在参数编辑器中创建参数时）创建的列表实例是同构的。因此，列表中的每个项目都可以通过索引号访问而不是按名称访问。

在这两种相对类型中，图3包含了所有四种基本的嵌套组合：

1.在表格结构中嵌套表格结构。例如，由节点351表示的表格嵌套在由节点341表示的更高级别的表格内。

2.同构列表作为其他同构列表的成员的一部分。例如，由节点344表示的列表被嵌套在由节点331表示的更高级别的列表内。

3.同构列表作为更高级别表格结构的一部分。例如，由节点344表示的列表嵌套在由节点341表示的表格内。

4.表格结构作为更高级同构列表的每个成员的一部分。例如，由节点341表示的表格嵌套在由节点331表示的列表内。

元数据编辑或提取

已经讨论了元数据语言，现在将介绍一个用于演示的示例图形用户界面，以及可以创建元数据的具体过程。

5.1 呈现元数据

图4A描绘了图3表示的元数据的一个视图，但是是通过一个图形用户界面的例子描述的。（不同之处在于，图4A包括元数据的一些文档，通过包括“显示名称” 但是这将很快被讨论）。图4B描绘了与图4A相同的用户界面，但是用户界面被划分成的三个由虚线和编号标识的主列。沿着X轴从右到左行进（参见图4B底部的X-Y轴420对），这些列是：

410，顶部标有“Native Name”（原生名称），

411，顶部标有“Type”（类型），和

412，在顶部标有“Display Name”（显示名称）。

列410和411的每一行呈现图3的每个节点所示的NativeName和Type信息。沿着Y轴从顶部（即，具有Native Name栏410中的“SevenDayThermostat”的行）到底部（即，类型栏411中具有“恒温器”的线）的每条线对应于一个深度优先遍历图3的节点。

列412呈现关于图3迄今尚未讨论的信息。对于在列410和411中标识的图3的节点，列412的每一行呈现自然语言英语的“显示名称”。在列412中，沿着X轴的显示名称的缩进表示其在其表示的元数据树内的级别。显示名称越靠近列412的左侧，其在树内级别越高。

图4C与图4B相似，不同之处在于列412的某些显示名称用它在图3中表示的节点号标记。可以看出，图3中的节点331和361分别由图4C中的显示名称“时刻表”（Schedules）和“恒温器”（Thermostats）表示。

图5A呈现了一组文档节点500，其记录了图3的元数据的自然语言英语描述。标识元数据结构的一组特定自然语言的文档节点在本文中可被称为“模块”。因此，500是用于标识图3元数据的英文模块。特别地，500包含14个文档节点，编号为501-514，其中每个对应于图3的14个节点之一。文档节点在模块中的排序纯粹出于图形方便的目的。其顺序是图3的元数据节点的广度优先遍历顺序，采取单调递增的节点编号（从501-514）。

对于元数据的每个节点，其对应的文档节点可以用如下方法找到：每个元数据节点具有指向相应文档节点的指针（显示在方括号中）。例如，对于元数据节点331，其指针可以跟随到图5A的文档节点502，其显示名称（DisplayName）为“Schedules”（时刻表）。 类似地，对于元数据节点361，其指针可以跟随到图5A的文档节点503，其中显示名称“恒温器”被找到。相反，每个文档节点都有一个指向其对应的元数据节点的指针。 例如，除了具有名称为“DisplayName”和“Details”的字段之外，每个文档节点具有“MetaDataNode”字段。对于节点502和503，每个具有分别指向节点331和361的元数据指针。

将特定自然语言的文档节点组织成一个专用于该自然语言的模块，允许方便地以多种自然语言标记单个元数据结构，类似“星形”结构。例如，图5B表示图3的完整元数据，其中单个圆标记为330（因为330是图3的根节点）。图5B通过标记为500的单个圆圈表示图5A的英文模块。从元数据到英文文档以及从英文文档到元数据的指针由圆圈330和500之间的双向箭头表示。

图5B描绘了元数据330也可以具有用于中文，俄文和西班牙文的文档模块的事实。这些自然语言中的每一个分别由圆圈520,540和560表示。图6A描绘了当语言模块从英语变为中文时图形用户界面视图如何改变的示例。图6B与图6A相同，除了添加了虚线和标记之外。可以看出，图6B与图4C相同，只是所用的自然语言已经从英文变成中文。需要特别指出的是：

图4C的列412,411和410分别对应于图6B的列612,611和610。

图6B的列612描绘与图4C的列412中所示相同的显示名称，除了已经用图3的元数据的中文文档模块将其翻译成中文外。例如，在图4C中表示为“Schedules”和“Thermostats”的元数据节点331和361的显示名称具有图6B中所示的其对应中文（“时刻表”和“恒温器”）。

用于显示“细节”信息的图形面板也不显示在任何一个

图4C或6B中。然而，对于图6B的任何中文显示名称，每个细节字段可以包含中文翻译，图4C的相应细节字段的英文翻译。

值得注意的是，如图6B所示的图形用户界面的其他方面还没有被翻译成中文：

对于图4C和图6B，列名保持英文（“显示名称”，“类型”和“原生名称”）。

图4C的列411和图6B的列611的数据类型名称保持英文。

图6B的列610的原生名称从图4C的列410保持不变。

列和数据类型名称是独立于任何特定应用程序的系统图形用户界面的示例。因此，他们的翻译（如果提供的话）通常不会由IoT应用程序开发人员或终端用户完成。这些是系统级别的更改，通常由系统工具提供者（即，元数据编辑器和参数编辑器的提供者）进行。

值得注意的是，与显示名称或细节字段相比，一组列名和数据类型名称代表了一组小的固定术语。因此，对于工具提供者来说，它代表了一套可以相对简单地翻译成多种语言的工具。相反，终端用户可以学习列名和数据类型名称，即使用他/她所不熟悉的语言来表达。

原生名称保持英文，因为它们是开发人员编写的应用程序代码中使用的实际符号名称的直接拷贝。

创建元数据

现在已经介绍了图3的元数据，并且已经解释了它的图形用户界面视图。现在我们应该提供示例步骤，展示如何通过该示例步骤可以创建图3的元数据。元数据的目的是作为一个准确的指导，据此终端用户可以随后输入实际的数据。只要创建的数据符合元数据，终端用户能够放心他/她提交的数据符合他/她应用程序选择使用的规则。

如上所述，有三种方式可以创建这样的元数据：

元数据可以由开发人员使用交互式的基于图形用户界面的工具“手动”创建，这里称为“元数据编辑器”。

元数据可以通过算法从应用程序的源代码中提取出来。

可以使用上述两种方法的组合。如果选择“手动”方式，则甚至可以在任何应用程序的实际代码被写入之前创建元数据。所有这一切都是必要的，一旦应用程序编写，开发人员要有一个完全正确的理解应用程序将如何处理其参数。

如上所述，对于以静态类型编程语言（如Java）编写的应用程序，其元数据可以从代码中自动提取。

这是因为在程序执行开始之前，必须明确声明可以分配给变量的允许的数据结构（包括Java中的annotation和.Net中的attribute）。因此，使用软件工程师已知的过程作为“reflection”，可以自动确定结构，并将其转换为元数据形式。

然而（如上所述），对于以动态类型编程语言（例如Lua）编写的应用程序，描述其潜在参数的元数据不能以自动方式完全提取。这是因为，可以分配给变量的允许的数据结构不需要在程序执行开始之前显式声明。

作为元数据创建的完全手动方法的示例，图7描述了用Lua编程语言编写的智能恒温器（称为“SevenDayThermostat”）的功能。可以看出，这个版本的函数完全没有实际的代码。它基本上只是一个声明，将会有一个具有特定名称的函数（“SevenDayThermostat”），并且它将有一个特定顺序的两个参数，每个参数都有一个特定的名字（“groups”和“thermostats”）。

相比之下，图8A描述了在详细的Lua代码中完全实现的相同功能。图8B-8D描绘了由图8A的功能所利用的另外的Lua功能。

以任一方式开始，通过空功能或完全编码的功能，可以使用如下方法逐步通过图4A的图形用户界面创建图3的元数据。图9的流程图描述了适合于图形用户界面的通用过程。该流程图也可以用来解释这个例子。

图9从步骤900开始，一旦元数据编辑器针对某一个特定功能被启动，该步骤900负责对表示参数的所有节点进行初始化。

接下来，图9的流程图在步骤901等待，直到在特定节点（在流程图中称为“当前节点”）处标识的图形用户界面接收到指示用户请求的信号为止。节点的标识可以通过在代表节点的图形用户界面的整个线上呈现颜色变暗的“一条”来反映在图形用户界面中。然后，用户请求可以通过明确指定相对于当前节点要采取的动作的输入产生。例如，当鼠标指针指向适当的屏幕区域时，通过输入鼠标点击（或双击鼠标双击）来产生用户请求信号。

图9展示一旦用户发送了请求。有六个主要决策点，编号如下：910,920,930,940，950和960。这些决策点被依次测试。只要有一个决策点测试为真，相应的动作就会被执行。然后流程图返回到步骤901。如果没有一个决策点测试为真的，则该过程简单地返回到步骤901，在那里等待随后的用户请求。

图10A描绘了示例初始屏幕，元数据创建过程可以通过该初始屏幕开始。可以看出，该过程首先将SevenDayThermostat应用程序的每个参数初始化为Number类型。此外，默认显示名称与原生名称相同，只是添加了大写字母（如果尚未存在于原生名称中）。图11A和11B分别描绘了用于产生图10A的图形用户界面视图的对应的元数据和文档节点。执行图9的步骤900就可以生成生成图10A。

图10B描绘在由箭头1010指示的屏幕区域处将“SevenDayThermostat”的显示名称改变为“QW: 7 Day Thermostat”。图10B还示出在由箭头1011指示的屏幕区域处输入细节文本。

关于图9的流程图，当图形用户界面被指向特定节点的元数据（在流程图中称为“当前节点”）的时候，我们假设（如上所述）进程是在步骤901等待用户请求的信号。对于这个图形用户界面，当前节点由表格视图的X，Y坐标指定。X轴在图形界面上被渲染成深色条纹（参见X-Y轴420对）。

对于图10B，可以看出，当前节点是具有原生名称“SevenDayThermostat”（图11A中的编号330）的节点，因为深色水平条位于由区域1010指示的Y轴位置处。用户请求信号的提交可以通过开发人员在区域上双击鼠标来完成。

离开步骤901后，根据图9的流程图，执行的第一测试是步骤910。由于用户请求是要改变显示名称，因此步骤910测试成功，应该执行步骤911。在执行步骤911之后，流程处理返回到步骤901等待下一个用户请求。

尽管节点330仍然被指示，但是当鼠标指针悬停在“详细信息”面板上时，开发人员只需单击鼠标就可以编辑其“详细信息”字段。这再一次导致流程图退出步骤901，并且决策点910再次测试为肯定的。因此，根据步骤911将所输入的信息添加到细节字段。细节信息的输入如图10B所示，在屏幕位置1011处。

图10C描绘具有原生名称“groups”（对应于图11A中的节点331）的节点被指示为当前节点（Y轴位置1020处深色条带）。在屏幕区域1020处的鼠标双击产生用户请求，使得流程图离开步骤901.先判定点910不被满足，随后判定点920被满足，因此执行步骤921。步骤921的这个执行可以导致类似图10C的下拉菜单出现。

可以看出，图示开发者为已经用鼠标在屏幕位置1021上选择“列表”（List）类型。如果需要，步骤921将递归地移除所有的子节点（如果这种删除是由开发者要求的类型变更指示的）。在当前这种情况下，由于节点331的先前类型是原始类型（即Number），因此不存在可以应用该递归移除的子节点。

图10C还展示了细节信息被添加到屏幕位置1022处的节点331。这个关于图9的细节信息的改变上面已经讨论了。

图10D描述了和刚才图10C类似的节点类型改变。指示这一次改变发生在具有原生名称“thermostats”的节点（对应于图11A中的节点361）。节点类型的改变可以通过在屏幕区域1030的鼠标双击来启动。图示中开发人员的鼠标指针处于屏幕区域1031处，表示选择了“列表”（List）类型。

图10B-10D所示的用户输入，其产生的结果，用元数据和文档节点的方式，展示在在图11C-11D中。比较图11A和图11C，可以看出，对于节点331和361，其类型从“数字”（Number）改变为“列表”（List）。比较图11B和图11D，可以看出，对于每个文档节点，进行了以下改变：

节点501：显示名称从“SevenDayThermostat”更改为“QW: 7Day Thermostat”，细节从空字符串更改为” Aprogrammable thermostat that improves comfort and savesenergy.”(可编程温控器，提高舒适度并节省能源)。

节点502：将显示名称从“Groups”更改为“Schedules”（时刻表），并且将详细信息从空字符串更改为“List of schedules”（时刻表列表）。

节点503：没有改变。

图12A显示了下一层级的开始。节点331由于被选中而被指示为“当前节点”（暗色条带1210）。图12A还示出了后续的动作，通过“点击”“添加成员”（Add Member）按钮来添加子节点。 “添加成员”按钮在图12A中通过虚线1211被围起来。

图12B显示了“添加成员”按钮被按下后的结果。图12B展示了在屏幕区域1220处一个Number类型的子节点被添加了。根据图9的流程图，具体步骤如下：

按下“添加成员”按钮产生了一个用户请求，该用户请求导致该过程离开步骤901。判定点910和920不被满足，但是判定点930被满足。然后，判定点931测试当前节点是否是“列表”（List）类型。由于当前节点（节点331）是列表，因此接下来测试点933。测试点933是特别重要的，因为它的作用是将“List”类型的节点限制为最多只有一个子节点。正是这个限制，对于一个单独的子节点来说，这使得列表是同构的。

由于当前节点还没有子节点，测试点933测试结果为否，导致执行步骤934。可以看出，除非新节点是枚举值，否则默认情况下，步骤934添加的新子节点的类型为“Number”（数值）。

在图12C中，如屏幕区域1230所示，初始默认类型的“Number”（在屏幕区域1220处）被改变为类型“Table”（表格）。上面已经讨论了关于图9改变节点类型的过程。

在添加了“Number”类型的默认子节点（在屏幕区域1240处）之后，在图12D中，第二个参数（具有原生名称“thermostats”（恒温器）的那一行）被展示出来。此外，图12D展示出了屏幕区域1240处的子节点的默认类型被改变为“Thermostat”（恒温器），在屏幕区域1241处。

图12E示出在作为当前节点返回到“Table”子节点，在屏幕区域1220处。这是为了添加节点的“详细信息”字段到文档，如屏幕区域1250所示。

当元数据编辑器图形用户界面已经达到图12E所示的状态时，图13A和13B分别描绘了元数据和文档节点的状态。与图11C和11D相比，图13A和13B具有以下变化：

节点341：节点331的新增子节点。

节点504：新节点341的文档节点。

节点362：节点361的新增子节点。

节点505：新节点362的文档节点。

根据13A，341是列表节点331的唯一子节点，它代表同质组340的开始。

到目前为止，表格节点341指定一个空表，因为它不提供键-值对。但是，从图3中可以看出，节点341需要指定以下三个键值对：

节点342：键“name”，值类型为字符串（string）。

节点343：键“weekDays”，值类型是一个枚举值的列表。

节点344：键“actions”，值类型是一个复杂嵌套类型的列表（其中每个表将根据节点351指定）。

图14A描绘了表格节点341为当前节点（通过屏幕区域1410处深色条指示）。图14A还显示了一个开发者将通过按下“添加成员”按钮（由虚线轮廓1411包围）来向该表添加第一键-值对。

图14B示出了响应图14A的按钮产生的默认键值对。在图9中，该动作对应于判断点930在结果为真，判断点931在结果为假和判断点932结果为真。在判断点932处的肯定结果导致步骤934添加默认的键值对。可以看出，默认的键值对被初始化如下：

默认键是“NewMember”（新成员），如屏幕区域1420所示。

如屏幕区域1421所示，该值被给予默认类型“Number”（数值）。

键值对可以被赋予显示名称，而与键无关。然而，图14B示出显示名称默认为与屏幕区域1423处所指示的键“NewMember”相同。

图15A-15B描述了创建了这个默认的键值对以后元数据和文档节点的改变。图15A与图13A的区别如下：

键-值节点342已被添加为表格节点341的子节点。

节点342具有“NewMember”的初始原生名称（或键/Key）和Number的值类型。

图15B和图13B的区别如下：

已经为元数据节点342添加了文档节点506。

节点506具有“NewMember”的初始显示名称（Display Name）和空字符串细节(Details)字段。

将节点506的显示名称改变为“Name”（名称），并将节点342的类型改变为类型“String”（字符串）。以上操作涉及图9流程图中的步骤910和920的操作（这些步骤已经在上面讨论过了）。在图形用户界面上，这些改变导致图16A与图14B发生如下变化：

表格节点341不再是“当前节点”，节点342为当前节点。（图中1610部分）

在屏幕区域1423处，显示名称已从“NewMember”（新成员）改变为“Name”（名称）。

在屏幕区域1421处，类型已经从数字改变为字符串。

然而，将节点342的原生名称从“NewMember”改变为“name”涉及图9流程图的前面没有讨论的步骤的操作：判断点960。这个步骤可以通过如下操作完成：移动鼠标指针到“NewMember”所在的区域（区域1420处），然后双击鼠标。图16A展示了鼠标双击之后的图形用户界面。这意味着判断点960已被确定为真，然后开始评估判断点961。可以看出，判断点961只有当（当前节点的）父节点类型为表格（Table）时，才允许改变原生名称。在图16A的情况下，由于到当前节点的父节点是表格（在屏幕区域1220处的表格），判定点961也被判定为真。因此，执行实际执行原生名称改变的步骤962被执行。在图16A中，屏幕区域1420处出现可以输入新的原生名称的对话框。

图16B与图16A差别在于，图16B在屏幕区域1420处输入了原生名称“name”，并且原生名称改变对话框已经关闭。

图17A-17B描述了元数据和文档节点的变化，这是上述第一键值对添加到表节点341而产生的改变。图17A和图15A之间的差异如下：

键值节点342已经将其原生名称改变为“name”。

节点342已经将其类型更改为”String”（字符串）。

图17B和图15B之间的差异如下：

文档节点506已经将其显示名称改变为“Name”（名称）。

继续构建图3的元数据的过程，第二键值对（节点343表示）被添加到节点341的表格中。这个第二键 - 值对如图19A所示。而且如图19B所示，节点343具有对应的文档节点507。

在图形用户界面中，根据图9的流程图，可以用前述方式添加第二键-值对，如以上所讨论的节点342。所得到的图形用户界面如图18所示，相对于图16B的变化在于1810区域。

恰似表节点341作为列表节点331的唯一子节点，我们需要添加枚举节点345作为列表节点343的唯一子节点。根据图19A，产生的元数据如图21A。枚举节点的文档节点509被显示在图21B中。由于开发者尚未定义枚举集合的大小，所以如图21A所示的节点345的“范围”字段具有值“TBD”。同样，由于开发人员尚未分配终端用户友好的显示名称，因此对于枚举集的每个成员，节点509的“显示名称”DisplayName字段显示为空字符串。

在图形用户界面上，图20A展示了在完成以下一系列步骤之后的情况：

代表节点343的行（参见图20A中标记为343的线）被选择为“当前节点”，并且“AddMember”（添加成员）按钮被按下。结果是图20A中所示的行，其代表节点345（参见图20A中标记为345的暗条）。节点345的默认类型显示为数值（在屏幕区域2010）。

屏幕区域2010处的“Type”（类型）字段受到鼠标双击（根据图9流程图，该动作产生用户请求，以改变节点的类型）。在屏幕区域2011，开发人员为节点345的类型选择“Enumeration”（枚举）。

在图20B中，图形用户界面展示了节点345选择了枚举类型（见屏幕区域2010）。

在图22A中，图形用户界面操作如下：当代表节点345的行被选中的时候，“AddMember”（添加成员）按钮被按下。可以看出，第一个元素已被添加到枚举。该元素被给予默认的显示名称“EnumItem”（参见屏幕区域2210）。因为“EnumItem”是这个枚举列表的第一项，所以它被分配原生名称“0”（见屏幕区域2211）。

图22B与图22A不同之处在于默认的显示名称已被开发者替换为“Sunday”（星期天）（参见屏幕区域2210）。

图23A和23B中展示了用于图22B所示的图形用户界面产生的元数据和文档节点的对应状态。图23A与图21A差别在于节点345，“Range”（范围）字段的值已经从TBD改变为0-0。图23B与图21B差别在于文档节点509，“DisplayName”字段的值已经从空字符串改变为“Sunday”。

重复图22A-22B所示的过程，一周的剩余六天可以被添加到由节点345所表示的枚举集合中。在进行六次添加之后，所得到的图形用户界面被显示在图24中。

图25A和25B中展示图24所示的图形用户界面产生的元数据和文档节点。图25A与图23A不同在于节点345，“Range”字段的值已经从0-0扩展到0-6。图25B与图23B不同在于文档节点509，“DisplayName”字段的值已经从“Sunday”改变为“Sunday, Monday, Tuesday,Wednesday, Thursday, Friday, Saturday”。因此，对于枚举元数据节点，将DisplayName字段解释为符号标签列表（用逗号分隔）。这些符号标签中的每一个都与其枚举元数据节点范围内的对应值相匹配。

对于枚举值，其相应的文档节点的内容在随后的参数输入过程中比在其他类型的文档节点中承担更积极的角色。这些我们将稍后讨论。正如下面将要讨论的那样，在参数编辑器，当终端用户选择一个特定的时刻表应用到哪一天时，图形用户界面可以在其下拉菜单中显示值0-6。但是，如果下拉菜单列出从“Sunday”到“Saturday”，或者中文“星期天”到“星期六”（文档节点的相应符号名称），则对终端用户来说更有意义。比起试图记住分配的数字的含义，符号标签，特别是当它们是终端用户流利的自然语言的词语时，对于一个人来说通常容易得多。

图26行2611处展示出将第三键-值对添加到表格节点341（其中节点341在图26行2613）。 此第三键-值对在图3和27A中标记为节点344。添加方式我们已经讨论过。参见第二键值对的添加（图26行2610所示的节点343）。

节点344代表一个列表，就像第二键值对的节点343一样。然而，节点343的列表的成员是枚举值。（可以参考图24来查看这些枚举值。纯粹为了节约节点343的图形表示空间，行2610在图26中被示为折叠状态）。节点344的列表元素类型是一个表格，其定义为节点351，该表格的定义在图26的图形用户界面中在行2612处。

如图27A，节点351标记同构列表350的开始。可以看出，节点351来世状态与节点341类似，但节点351表示一个同构列表，嵌套在另一个同构列表340成员内。

总而言之，比较图27A和图25A，我们看到以下增加：

具有原生名称“actions”的节点344，类型为“列表”（List）。

不具有原生名称的节点351，类型“表格”（Table）。

类似地，比较图27B和图25B，我们看到以下增加：

节点508代表“Actions”的显示名称和细节描述。对应图26的2614行。

显示名称为“Action”的节点510。

表格节点351的四个键值对的添加可以通过图形用户界面以基本上与上面讨论的用于将键值对添加到表格节点341的方式相同的方式来实现。如图3所示，唯一显着的区别是表节点351的所有键值对都是原始类型。换句话说，表格节点351不具有嵌套的列表或表格作为其键值对中的一个的值类型。

表格节点351对应的元数据和文档节点，分别如图3和5A所示。图4A中显示了相应的完成的图形用户界面视图。

参数编辑器

6.1 概论

将参数传递给程序通常是只有熟悉计算机编程语言的人才能进行的活动。然而，本发明使得这个任务相对简单，对于没有编程基础的人来说不太陌生。造成这种简单明了的三个主要因素包括：

允许开发者以元数据的形式提供指导终端用户参与创建参数过程的通用指令。

通过图形用户界面，使必要的参数的数据结构更容易理解。

通过允许开发人员为元数据提供详细的节点文档，文档中包含的文字（甚至扩展为包含图像等信息）是图形用户界面作为表示层的重要组成部分。如上面关于元数据编辑器所讨论的，这个文档至少包括以下两个字段：“NativeName”原生名称和“Details” 详细描述。

为了呈现参数编辑器的一个实例，我们假定终端用户希望利用上一节讨论的示例“SevenDayThermostat”应用程序。应用程序的元数据如图3所示。此外，我们假设终端用户希望为这个应用程序输入图2的示例数据（在第4节“元数据语言”中有讨论）。

图28作为流程图示出了适合于参数编辑器图形用户界面的通用流程。

在完成下一节（即下面的标题为“构建参数”的章节）后，图2中的数据将被创建在上面讨论的物联网控制器的用户终端的计算机存储器中（请参阅第3节“物联网生态系统”）。图38A中显示了完成的参数数据的图形表示，用于提交给SevenDayThermostat应用程序。

通过物联网控制器终端用户界面输入适当的终端用户命令，将导致图形用户界面输入的参数数据被重新打包为合适的格式，该格式可以作为存储在物联网控制器120上的应用的拷贝的实际参数提交。根据图1A-1B的物联网架构，这种重新打包可以发生在终端用户的客户端（例如，客户端112或132）上，在物联网控制器120上（例如通过主进程150），或者两者的组合。

假定SevenDayThermostat应用的拷贝已经被存储在应用存储器155上。主进程150可以将参数数据发送到应用程序引擎151，其中数据与应用程序的副本组合以在应用程序引擎上的沙箱内创建执行任务。

构建一个参数

根据图28的步骤2800，执行参数输入会话开始于为相关元数据的每个参数根节点生成初始参数。对于图3的元数据，这意味着需要为节点331和361中的每一个确定初始参数值。

基于数据类型进行初始化的一组示例规则可以概括如下：

根据其对应的元数据规范，如果一个值可以设置为空值（任何类型），其将被初始化为空。一般而言，开发人员需要确定一个值节点是否可以为空值。每种数据类型都可以接受null作为其值之一。因为将数据可以为空值对于函数的输入参数尤其重要，几乎任何数据类型都可以作为参数。如果开发者没有明确地指出该节点表示值可以为空，根据其他的初始化规则，确定该类型的一个默认的初始化值。

如本文所使用的，“原始”类型是在对应的元数据中必须表现为叶节点的类型。在原始类型中，“数值”Number可以被初始化为0，“字符串”String可以被初始化为空字符串，并且“Boolean”布尔可以被初始化为“FALSE”。除了这三种基本类型之外（不管开发者是否选择添加该功能），基本数据类型通常被设计为将其类型的任何新实例初始化为空值。例如，将以下基本类型的实例初始化为空值（时间和日期）可能是一个很好的设计选择。代表物联网设备的原始类型经常被初始化为空。在物联网设备的一般类别中，根据其通用功能来组织物联网设备通常是进一步的设计选择。例如，对于通常用于产生照明的所有物联网设备，可以将它们分组在称为“灯光”的数据类型下。

列表被初始化为空列表。

一个表格被初始化为包含所有的键值对。然后，根据每个值的数据类型，相应地初始化该值。

如果一对数据类型本身是另一个复杂结构（Table或者List），那么以递归的方式进一步初始化。在图28中，这个潜在的递归初始化由步骤2802完成。步骤2802不是图28所示的控制流程的直接部分。而是，步骤2802被调用为名为“populate_node”的子例程。对于递归枚举的每一个子节点，子例程populate_node频繁被调用（例如，节点2800,2812和2841）。调用步骤2802的节点也可能向正在创建的参数数据中引入新的表格。

对于图3的示例元数据，由于其参数根元数据节点（表示参数“组”的节点331，以及表示参数“恒温器”的节点361）的类型都是类型“列表”，所以它们被初始化为空列表。这样的空列表由图29A的参数根数据节点2931和2961表示。

从图29A中还可以看出，每个参数根数据节点包括一个指向图3的相应元数据节点的指针。节点2931和2961分别具有指向元数据节点331和361的指针。请注意，如果开发人员将参数根元数据节点设置为空值，则相应的参数数据节点2931和2961将被初始化为空值。

图29B展示了图29A的数据的一个图形用户界面的表达。 （为了方便识别的目的，引入了一对X-Y轴2946）。因此，当首先开始输入SevenDayThermostat应用的数据时，终端用户看到类似于图29B的图形用户界面屏幕。

可以看出，图形用户界面的图形区域主有以下两个区域（或“面板”），相对于Y轴可以被标识为“上”和“下”：

上部显示面板2940：用于显示正在构建的参数的分层结构。

下显示面板2950：用于显示当前在上显示面板中指示的节点的详细文档。

图29C与图29B不同在于平行于Y轴的虚线已被添加到上显示面板中。这个虚线不是图形用户界面本身的一部分，但被用来阐明如何将上部显示面板分成两列：

左列2941：标题为“Name”（名称）

右栏2942：标题为“Value”（值）

左列2941的基本结构基本上与元数据编辑器图形用户界面的最左列相同（例如，参见上面关于图4C的列412的讨论）。上部显示面板的每一行代表一个参数节点（类似于元数据编辑器，其中每一行代表一个元数据节点）。在上部显示面板的左侧列中，节点的缩进表示其层级。进一步向左侧放置节点，表示较高的层级。

正如在介绍元数据编辑器时所讨论的那样，对于在编程语言级别上是机器可读的每个符号名称（或“原生名称”），参数编辑器图形用户界面可以显示（如果开发者如此选择的话）对应的显示名称。

例如，从图3可以看出，三个最高级别节点的原生名称如下：

“SevenDayThermostat”：对应的应用程序源代码内的入口函数名称。

“groups”：第一个参数在源代码内名称。

“thermostat”：第二个参数在源代码内的名称。

从图29C中可以看出，这些原生名称中的每一个都分别被替换为以下显示名称（其中以下在元数据编辑器的部分中作为对应的显示名称被提供）：

“QW: 7 Day Thermostat”：见行2945;

“Schedules”：见行2946，它对应于参数根节点2931; 和

“Thermostats”：参见第2947行，其对应于参数根节点2961。

应用程序本身（即，图3的节点330）当前在图形用户界面中被指示，可以从图29C中看出，应用程序的显示名称在行2945的暗条。由于应用程序本身的节点当前被指示，所以其详细文档当前显示在下部显示面板2950中。

为了显示“显示名称”和“详细信息”，对于由终端用户构建的参数数据结构的每个节点，都需要找到相应的文档节点。这可以找到如下：参数的每个节点都有一个指向其对应元数据节点的指针，每个元数据节点都有一个指向其相应文档节点的指针。例如，对于参数根节点2931，其显示名称可以如下获得。其指针可以跟随到图3的节点331.节点331又具有指向图5A的文档节点502的指针，其中找到DisplayName为“Schedules”。

在创建参数时，合乎逻辑的下一步可以是在“Schedules”（时刻表）节点2931下创建时刻表实例。图30B显示了在图形用户界面中采取的下一个步骤。在图30B中，“时刻表”节点已经是图形用户界面中指示的当前节点，行2946所示的变暗的区域。

图30B还展示了终端用户通过将鼠标指针点击“Add”(添加)按钮。作为响应，图30C展示了已经添加的时刻表的实例。对应图3的元数据节点341，该时刻表标记为“＃1”（见行3030）并且是一个表格结构。

图30A以图形方式展示了在参数节点级上的相同的改变，如图30C所示。通过比较图30A和图29A可以清楚地看出这些变化，图30A的虚线轮廓标识的3000就是差异。参数根2931的所添加的直接子节点在图30A中被描绘为节点3010。表格3010的三个键值对的初始值由节点3011,3012和3013表示。

通常，图形用户界面输入的参数数据节点的每个节点可以具有以下四种类型的信息：

指向其对应的元数据节点的指针。如上所述，这在一对方括号中示出，并且通常包括在参数数据的每个节点中。

如果参数节点对应于“List”类型节点的直接子元数据节点，则参数节点通常会包含索引号，以便将其与同一列表中的其他实例区分开来。例如，图30A中，参数节点3010既具有指向其对应的元数据节点（即，[341]）的指针，又具有索引号“＃1”。

如果参数节点对应于相对类型（即，表格或列表）的元数据节点，则它可以具有指向其每个参数子节点的指针。例如，参数节点3010是表格类型。因此，节点3010具有指向其包含的每个键值对实例节点的指针。具体而言，节点3010具有指向以下参数节点的指针：3011,3012和3013。

如果参数节点对应于原始类型的元数据节点，则它可以存储一个具体的值实例。例如，图30A的参数节点3011存储空字符串值。如果列表当前为空。

图30C以图形方式将节点3010显示为行3030。节点3011,3012和3013分别由图30C的行3031,3032和3033表示。

根据图28所示的参数编辑器流程图，虚线轮廓3000对应节点的添加处理如下：在“添加”按钮被按下之前，我们假定图形用户界面正在步骤2801等待终端用户输入。我们知道，根据在行2946处的深色条，“Schedules”(时刻表)节点2931被选择为当前节点，如图30B所示。当“添加”按钮被按下时，生成用户请求。在离开步骤2801时，要执行的第一步是判断点2810。由于对判断点2810的回答是真，下一个要执行的步骤是判断点2811。由于所指示的当前节点（即，节点2931）是List类型的，所以执行步骤2812。该步骤首先创建子节点（节点3010），然后调用“populate_node”子例程（步骤2802）。由于节点3010的类型为“表格”，所以步骤2802使其所有子节点（即，其键值对）被填充缺省实例。

图30A展示了填充节点3010的表格的三个键值对：

3011：图3的节点342表示的键（即，原生名称“name”）初始化为空字符串（“”）。在图30C所示的图形用户界面中，在行3031，节点3011的显示名称“Name”（名称）。显示名称“Name”取自节点342的文档节点506。

3012：初始化为一个空列表，索引键为“weekDays”。在图3中对应的值节点为343。在如图30C所示的图形用户界面中，在行3032，节点3012的显示名称“Weekdays”，取自节点343的文档节点507的

3013：初始化为一个空列表，索引键为“actions”。图3对应的值节点344。在如图30C所示的图形用户界面中，在行3033，节点3013显示名称“Actions”（动作列表），取自节点344的文档节点508。

步骤2802完成后，控制返回到步骤2812。由于步骤2812已经完成，所以参数编辑器的控制流程返回到步骤2801（其等待下一个用户请求）。

值得注意的是，对于图28所示的参数编辑器的具体实现，如果终端用户产生的“添加子节点”信号，那么只有所指示的当前节点是 “List”类型才会工作。这可以通过以下事实来理解：可以添加子节点的唯一其他类型的节点是“表格”。然而，无论何时引入表格，都会通过对步骤2802的调用自动填充表格（并且如果需要，递归地填充子表格）。

终端用户的下一个步骤可以是物联网控制的恒温器的规格，即根据一天中的时间和一天中的一天中的时间设置不同的制冷和取暖设定点。

图31B展示在图形用户界面中 “Thermostats”(恒温器)节点（图30A的节点2961）已经被指示（选中），如行3120所示。图31B还显示终端用户用鼠标点击 “添加”按钮。作为响应，图31C示出了已经添加的恒温器（行3130）。（为了识别的目的，重新引入一对X-Y轴2946）。根据图3的元数据节点362，该恒温器被标记为“＃1”，表示一个特定的恒温器。

图31A相对于图30A的变化被包围在虚线轮廓3100中。参数根2961的添加的子节点被描绘为图31A中的节点3110。图31C以图形方式将节点3110显示为行3130上的标签“＃1”。

图31C还强调（用虚线3122）参数编辑器的上部面板的划分成左右两半。从线3130右半部分的“值”可以看出，所添加的恒温器最初只是“空”恒温器（在屏幕区域3121处），该值也可以在图31A的节点3110中看到。

根据图28所示的参数编辑器流程图，添加节点3110的过程可以描述如下：我们假定控制流程在步骤2801，等待用户请求。如上面关于图31B所讨论的，节点2961通过行3120的变暗而被指示为当前节点。然后按下”Add”(添加)按钮，这会生成一个类型为“添加子节点”的用户请求。步骤2810测试结果为真，导致步骤2811，2811测试结果也为真（因为“恒温器”表示列表节点2961）。然后通过执行步骤2812添加新的恒温器。由于恒温器被假定为原始数据类型（类型“恒温器”），虽然子程序2802被调用，但它没有效果。

图32A显示了通过图形用户界面选择的特定恒温器的最终结果。所选择的恒温器被假定为在终端用户的物联网系统中具有103的ID号。图32B-32C显示了一个示例图形用户界面。图32B示出了下拉菜单（在行3130处），其可以例如通过在行3130的“值”一侧点击鼠标来激活。可以看到，下拉菜单有两个温控器可供选择：显示名称为“Upstairs Thermostat”的恒温器和显示名称为“Downstairs Thermostat”的温控器。在图32C中可以看出，选择了“Upstairs Thermostat”作为thermostat＃1。本例中，这个恒温器的ID号码是103。

根据图28所示的参数编辑器流程图，选择“Upstairs Thermostat”恒温器的过程可以描述如下：我们假定控制流程在步骤2801，等待用户请求。如上面关于图32B所讨论的，节点3110已经通过行3130的变暗而被指示为当前节点。如上面针对图32B所讨论的，当激活用于潜在选择的列出恒温器的下拉式菜单界面时，发生用户请求（类型“设置或修改非空值”）。以下每个测试点都测试为否定的：2810，2820，2830和2840。然而，测试点2850测试是肯定的，因为我们试图为叶节点（即叶节点3110）设置非空值（即，恒温器值）。执行步骤2851，其中可用恒温器如图32B所示可视化，并且如图32C所示接受对“UpstairsThermostat”恒温器的选择。

图33B表示终端用户的焦点转移到天填写时刻表实例＃1（图33A的节点3010）的键值对。具体而言，图33B展示了填写当前数据“Name”（名称，参见行3320）。此外，在行3320的“Value”（值）侧，已经激活了一个对话框（例如，通过在该区域中的点击鼠标），并且字符串“Business Days”已经被输入。在图33A中，相对于图32A的改变被包围在虚线轮廓3300中。具体地，对于节点3011，空串已经被改变为“Business Days”（工作日）。

根据图28所示的参数编辑器流程图，字符串“Business Days”的输入处理方式与选择特定恒温器的方式基本相同（默认恒温器添加到“恒温器”列表之后）。在这两种情况下，目的都是为一个原始类型（或叶节点）设置一个非空值。在图33A-33B的情况下，类型是“String”（字符串）而不是“恒温器”。

图34B显示了添加枚举值过程的前半部分，以表示一周中的某一天。图34B显示了在行3420处添加的具有显示名称＃1的默认枚举值Null。该值的添加对应于图34A所示的节点3410。再次，虚线轮廓（在这种情况下编号为3400）描述了从图33A到34A的变化。

根据图28所示的参数编辑器流程图，节点3410的添加与上面讨论的添加默认恒温器过程基本相同。在两种情况下，按下“添加”按钮（在将适当的节点指示为当前节点之后）生成由判断点2810检测到的“添加子节点”类型的用户请求。然后，判断点2811也被肯定地回答，导致在步骤2812中增加新的原始类型子节点。

图35B展示了可以从中选择星期几（以与选择特定恒温器类似的方式）的下拉菜单界面（在行3420处）的激活。就像选择特定的恒温器一样，作为判断点2850被肯定地回答的结果，执行该用户界面，导致执行步骤2851。图35C示出了在选择“Monday”(星期一)之后的图形用户界面。图35A在虚线轮廓3500内展示了作为选择“Monday”的结果的节点3410的示例值。可以看出，在这种情况下，星期一由数字“1”表示。

这个值的选择是两个因素的结果：

在图3的元数据中，节点345将枚举表示为整数范围0-6。

在图5A的节点345的节点509的文档节点中，“详细信息”字段显示符号标签的列表，其分别对应于整数范围0-6。如上所述，就元数据编辑器而言，对于枚举值，文档节点的内容在数据输入过程中承担更积极的角色。在图35B中，图形用户界面可以在下拉菜单中显示值0-6而不是“星期天”到“星期六”的日期名称。然而，符号标签（特别是当它们是终端用户流利的自然语言的词语时）通常对于人来说更容易使用。

图36B示出了一个动作的实例（在行3620处）被添加到列表“Actions”(动作)列表之后的图形用户界面。

在图36A中，虚线轮廓3600包含新创建并添加的对应数据节点：

节点3610表示动作实例本身，它是一个表格类型。

节点3611至3614表示当添加表格时发生的自动填充的键值对。根据其类型，每个键值对都被初始化为一个适当的值：

节点3611对应于图3的元数据节点352，其类型是字符串。因此，它的初始值是空字符串。

节点3612对应于时间类型的图3的元数据节点353。因此，其初始值为空。

节点3613和3614都对应于Number类型的元数据节点（即，354和355）。因此，每个节点都被初始化为0。

图37B示出了图36B的动作实例（由线3620表示的节点3610），不同在于默认值已经被终端用户输入的值替换。这些值的设置也反映在图37A中的虚线轮廓3700内：

节点3611已被设置为字符串“Wake”（起床）。

节点3612已被设置为6 AM。

节点3613已经被设定为70作为取暖设定点。

节点3614已经被设置为74作为空调设定点。

此时，我们已经创建了一个实例，基于图3的元数据的所有列表类型：

对于图3中的节点331（对应于图37A中的节点2931）所表示的列表，已经创建了由图37A中的节点3010表示的“表”类型实例。

对于图3中的节点361（其对应于图37A中的节点2961）所表示的列表，已经创建了由图37A中的节点3110表示的恒温器类型实例。

对于图3中的节点343（其对应于图37A中的节点3012）表示的嵌套列表，已经创建了由图37A中的节点3410表示的枚举类型实例。

对于图3中的节点344（其对应于图37A中的节点3013）表示的嵌套列表，已经创建了由图37A中的节点3610表示的“表格”类型的实例。

然而，为了具有实际使用的恒温器时刻表，终端用户可以期望为这些列表中的至少一些添加额外的实例。图38B-38C描绘了实用恒温器时刻表的图形用户界面视图的一个例子。这基本上是图2标识的数据，目的是具有图2所讨论的功能。由于图38B-38C的时刻表比较复杂，因此对应于图37A的节点的这些图的每个显示名称或值被标识出来。具体而言，对于图37A中每一个列表节点（节点2931,3012,3013和2961），以及列表内的表格节点（节点3010和3610），其在图38B或38C中对应的显示名称和值，都被标识出来。图37A每个叶节点（节点3011,3410,3611-3614和3110），在图38B或38C中的相应的值也被标识。

图38A包括图37A的所有节点，具有相同的节点编号，但是图38A还包括由图38B-38C的图形用户界面所标识的所有附加节点。下面我们将描述图38B-38C的图形用户界面表示的时刻表：对应图38A（为了减少所需的节点标记量，将一对轴3800添加到图中）。

可以看出，列表节点2931具有两个调度实例：节点3010和节点3810。计划实例3010已经被命名为“Business Days”（工作日）（通过其直接子节点3011），并且旨在在工作日的每一天执行终端用户期望的温度范围的时刻表。节点3012旨在列举构成终端用户的工作日的那些特定星期。在这种情况下，终端用户的星期一到星期五的工作时间非常标准。对于在节点3012下列举的每一天，节点3013下面是要遵循的温度范围的时刻表。节点3013下的时刻表的温度范围沿着“X”轴从左到右排列。

第一温度范围在表格实例节点3610下（也具有显示名称＃1）。温度范围由四个键值对指定，编号为3611-3614。这四个键值对沿着“Y”轴从上到下排列。最上面的键 - 值对给出这个温度范围的名称“Wake”（起床），它应该是终端用户在起床时所需的温度范围。下一个键-值对指定“Wake”温度范围开始的时间：上午6点。其后两个键-值对（编号为3613和3614的节点）分别指定了所需的取暖设定值和空调制冷设定值。可以看出，当终端用户起床时，他/她喜欢在70-74℃范围内的温度。因此，在寒冷的天气，加热系统将被激活，直到达到约70°F的温度。相反，在炎热的天气，制冷系统将被激活，直到达到约74°F的温度。

从左向右移动，沿着“X”轴，第二个温度范围在显示名称为“＃2”的节点下。从上到下，沿着“Y”轴，第二温度范围的四个键值对如下。最上面的键值对给出了这个温度范围的名称“Leave”（离家），并且当他/她离开他的工作时，它应该是终端用户想要的温度范围。下一个键值对表示终端用户预计在上午8点离开工作。当终端用户离开工作时，其后两个键值对指定他/她喜欢将家维持在64-80°F的温度范围内。因此，通过一个智能的基于时刻表的恒温器，终端用户可以大大节省能源成本。

继续沿着“X”轴从左到右移动，第三个温度范围在显示名称为“＃3”的节点下。从上到下，沿着“Y”轴，第三温度范围的四个键值对如下。最上面的键值对给出了这个温度范围的名字“Back”（回家），并且当他/她下班回到家时，它应该是终端用户想要的温度范围。下一个较低的键值对表示终端用户预计在下午6点到达家中。在晚上/晚上回到家中时，终端用户喜欢70-74°F的相同温度范围，他/她喜欢在早上醒来。

最后，最右边（和最右边）的温度范围在显示名称为“＃4”的节点下。从上到下，沿着“Y”轴，第三温度范围的四个键值对如下。顶部的键 - 值对给这个温度范围的名称“Sleep”（睡觉），它应该是他/她睡觉时的终端用户所需的温度范围。下一个较低的键值对表示终端用户预计在晚上10点左右睡觉。在睡觉的时候，这个特定的终端用户喜欢温度比他/她喜欢的温度稍低。两个键值对指定预设温度范围是68-72°F。

我们解释时刻表实例节点3010，下面轮到时刻表实例节点3810。时刻表实例3810已经被赋予名称“Weekends”（周末，参见其最左边的直接子节点），并且旨在在周末的每一天执行终端用户期望的温度范围的时刻表。从左到右，沿着“X”轴，下一个直接子节点列举构成终端用户周末的特定日子。在这种情况下，终端用户的周末有了非常良好的定义（周六和周日）。（时刻表实例节点3810的）最右边的直接子节点被编号为3813。节点3813下的温度范围的时刻表沿着“X”轴从左到右排列。

第一个温度范围在显示名称为＃1的表实例节点下。从上到下，沿着“Y”轴，第一温度范围的四个键值对如下。最上面的键值对给出了这个温度范围的名称“Wake”（起床），并且当用户在周末醒来时，它应该是终端用户想要的温度范围。下一个键值对表示，终端用户期望在周末晚些时候醒来：上午7点。在醒着的时候，这个特定的终端用户喜欢70-74°F的温度范围。

由于终端用户预期他/她可以在一天中的任何时间在家，在周末，他/她“离开”或者当他/她是“返回”时不包括温度范围。第二个（也是最右边的）温度范围在显示名称为＃2的表实例节点下。从上到下，沿着“Y”轴，第一温度范围的四个键值对如下。顶部的键-值对给这个温度范围的名称“Sleep”(睡眠)，它应该是他/她睡觉时的终端用户所需的温度范围。下一个键值对表示终端用户预计在周末晚上大约晚上11点睡觉。两个最低的键-值对指定了与平日指定的睡眠相同的预设温度范围：68-72°F。

关于参数根节点2961，可以看出，已经添加了由节点3850引用的另外的恒温器。假设第二个恒温器的ID号为115.在图38C中可以看到第二个恒温器是“DownstairsThermostat”（楼下恒温器）。

属性

尽管树结构化和同质化列表是功能强大的工具，开发人员可以通过这些工具为终端用户提供选项，有时终端用户可以至少部分地避免这种表达。

除了具有类型之外，还可以通过使用一个或多个属性（attributes）来进一步限定元数据节点。

比如我们可以向一个或多个元数据节点添加“nullable”属性。如果添加到元数据节点，则nullable属性意味着在随后的参数编辑器过程中，可以简单地为相应的参数数据节点分配Null（空）值。即使在对应的元数据中，在可空元数据节点下面存在复杂的子树，也可以使用这种仅分配空值的能力。

图39描述了一个纯粹出于说明可空属性示例用法的目的而创建的示例“测试”函数。

图40A描绘了在元数据编辑器中所显示的用于测试功能的示例元数据。如对于5.1节（“呈现元数据”）所做的那样，在图4C中，添加了平行于Y轴的虚线，以强调“原生名称”（列4000），“类型”（列4001）和“显示名称”（列4002）的列

图40A的线4010代表测试的唯一参数“p1”，（在栏4001中）是表格类型。然而，开发人员并不是只由一个表格组成，而是将这个参数构成为包含两个子表格：

第一个子表位于第4020行，并具有原生名称“Options”。该表旨在允许终端用户在必要时指定用于改变“test”执行的附加参数。可以看出，Options表的可选参数为Option_A和Option_B。

第二个子表位于第4030行，并具有原生名称“Main_Data”。此表旨在保存终端用户在每次使用测试应用程序时必须指定的数据。Main_Data所需的项目为Data_Item_1和Data_Item_2。

图40B中可看到Options子表的可选性质。在该图中，由于行4020变暗，说明Options子表已被指示为当前节点。如果当前节点具有属性，则对于此图形用户界面，将显示在位于上部和下部显示面板之间的属性面板中。对于图40B，可以在属性面板内的行4021处看到属性“可空”。如果开发者希望删除这个属性，可以用鼠标指针来点击行4021（见屏幕区域4004）最左侧的“X”按钮。

在图9中，由判断点940确定开发者是否已经做出用户请求，添加或移除属性，并且在步骤941执行。

Main_Data子表格的所需属性可以在图40C中看到。在该图中，由于行4030变暗，Main_Data子表已被指示为当前节点。然而，与图40B不同的是，没有显示属性面板。如果开发者希望添加一个属性，可以用鼠标指针来点击虚线4005包围的“Attribute”（属性）按钮。

在应用程序开发期间使用“Nullable”属性的优点可以在图41A的示例终端用户参数编辑器屏幕中看到。该屏幕可以是初始数据输入屏幕，终端用户在选择执行“test”应用程序时就会看到。

（例如参见第6.2节“构建参数”，图29C），虚线4100被添加到图41A，以强调参数编辑器的上部显示面板的“名称”和“值”（Name，Value）。

可以看出，4110行的“Options”表格因为可以为空，因此初始化给终端用户时被设置为空，并且没有显示表的内部特征。相比之下，对于“数据项目1”和“数据项目1”，行4120的“主数据”表格被初始化为完全填充（作为图28的步骤2802的结果），默认值为0。另外，作为用户请求“设置或修改非空值”（满足图28的步骤2850）的结果，在行4121上展示了用于改变“Data Item 1”的值的对话框。

在图41B中，展示了终端用户准备去除“Null”设置。线4110被示出为指示当前节点（参见变暗），并且终端用户将要按下“Table”（表格）按钮（由虚线4101包围）。在图41C中，展示了参数编辑器从“4110行”的“选项”表中删除了“Null”设置。参照图28流程图，该步骤可以由判定点2840进行测试来执行，从而导致执行步骤2841。因为步骤2841将进行到步骤2802的子程序调用，“Options”表格中“Option A”和“Option B”元素被完全填充，缺省值为0。因为不存在要从当前指示的节点（恰好是“Option B”）中删除的“空”值，所以“表”按钮（在虚线轮廓4101内）变灰。

图42表示一个元数据例子，对应于图40A-40C的图形用户界面视图。例如，线4010对应于图42的节点4211。可以看出，节点4211在其左侧具有“parameter：”值。行4020对应于节点4212，行4030对应于节点4213。可以看出，节点4212在其左侧具有“nullable：”值。

图41A的参数编辑器视图可以由图43A在参数节点级别表示。可以看出，“Options”节点（节点4311）初始为“空”，从节点4311内的值反映出来。但是，每个“MainData”节点（Data Item 1和Data Item 2）具有相应的值节点。这些对应的值节点是节点4013和节点4314。

图41C的参数编辑器视图可由图43B参数节点表示。可以看出，“Options”表格不再为空，选项“A”和“B”中的每一个都具有对应的值节点。这些对应的值节点是节点4015和节点4316。

除了一个节点是否可以用一个空值来表示之外，许多其他类型的属性对元数据也是有用的。

下面为一些好的例子：

Max(最大值)：如果元数据节点表示将在参数编辑器中接收定量值的内容，有时可能会有对开发人员指定最大值有所帮助。例如，关于图3的恒温器元数据，对于节点354的heatSetPoint，设置最大值可能是有帮助的。例如，终端用户可能被限制在设定温度不高于90°F。

Min(最小值)：如果元数据节点表示将在参数编辑器中接收定量值的内容，有时可能会对开发人员指定最小值有所帮助。例如，关于图3的恒温器元数据，对于节点355的coolSetPoint，设置最小值可能是有帮助的。例如，终端用户可能被限制在设定不低于60°F的温度。

Step(步长)：如果元数据节点表示将在参数编辑器中接收定量值的内容，则开发人员可以在适用范围内指定每个增量或减量的大小。例如，关于图3的恒温器元数据，对于节点353的时间，需要时间以四分之一小时为单位来指定。

属性还可以用来影响图形用户界面。比如：

Unique(唯一)：如果一个别表的元素子节点（认知可以是间接子节点）设置为唯一，则图形用户界面要确保用户列表相应的元素不能重复选取。这样图形用户界面甚至可以进一步优化成为多选窗口（不需要一个个地添加）。

Header(表头)：表格节点的子节点如果设置为表头，则在用户界面上会被优化成代表这个表格节点的表达。

附加信息

如本文所使用的，物联网（IoT）设备是通过提供嵌入式计算机系统和网络连接而变得可远程访问的物理设备。远程访问可以用于指示物理设备（远程控制），或者从物理设备获取信息（远程感测）或两者都有。

这种物联网设备的能力一般可以通过它们在远程通用计算平台（“物联网控制器”）的指导下以新的不可预知的方式相互操作的能力得到增强。通过向物联网控制器添加新的软件，可以使与其连接的物联网设备出现新的行为。例如，这样的互操作性通常可以被表示为从一个或多个IoT设备进行远程感测，从而在IoT控制器的指导下引起一个或多个IoT设备的远程控制的改变。

在拥有网络连接的同时，物联网设备不需要包含自己连接到互联网的能力。例如，通常情况下，通过在IoT控制器上执行的软件来实现的最终结果可以使用全部位于公共部署位置的IoT设备来完成。由于这个原因，物联网设备本身通常只具有局域网连接功能。如果物联网控制器也位于部署地点，则可能导致整个物联网系统缺乏互联网连接。但是，物联网系统几乎总是在系统的某个部分包含至少一个互联网连接。

虽然物联网设备可以在物联网设备的上下文中使用非物联网局域网联网协议（例如以太网或802.11协议套件）来实现其网络连接，但是这样的局域网协议通常具有明显的缺点。例如，非IoT LAN协议可以具有以下缺点：

需要消耗过多功率的硬件;

要求硬件不能足够便宜;

可靠性不够高;

不是为了容纳足够数量的具有同时网络连接的设备而设计的。

由于这些原因和其他原因，物联网设备所连接的局域网通常专门针对物联网类型系统的需求。

这种IoT-LAN协议通常具有以下优点的组合：

低电量;

便宜的硬件;

高可靠性;

容纳大量同时连接的设备。

为了实现这些优点，IoT-LAN协议通常可以利用比非IoT LAN设计的更容易实现的某些要求。

这些优点至少可以包括以下任意组合：

低速连接;

小消息通信。

示例基于无线连接的IoT LAN协议包括以下内容：

6LoPAN（RFC 4944及相关的Internet工程任务组，弗里蒙特，加利福尼亚州，美国），

蓝牙（Bluetooth Special Interest Group，Kirkland，WA，USA）。

ZigBee（ZigBee联盟，戴维斯，加利福尼亚州，美国）和

Z-Wave（Z-Wave Alliance，Freemont，CA，USA）。

使用有线（电力线布线）和无线连接的示例物联网局域网原型是Insteon（SmartLabs，Inc.，Irvine，CA，USA）。

一个特别常见的物联网设备的例子是替代普通的壁挂式照明开关的物联网设备。与普通的墙壁开关相比，由于机械的用户输入，它简单地打开或关闭电路，IoT墙壁开关具有以下两种功能：

它变成了一个遥感设备。具体而言，远程IoT控制器可以检测开关是处于“开”还是“关”的位置，或者实时接收开/关状态。

它成为一个遥控设备。具体而言，位于远程的IoT控制器可以指示墙壁开关打开或关闭与其连接的电路。

出于向后兼容的目的，为了防止基于物联网的服务暂时中断，物联网设备通常会提供一定程度的本地控制。例如，对于物联网墙壁开关，将其开关设置到“开”位置通常会导致与其连接的电路接通，而无需IoT控制器的参与。但是，这样的本地控制通常被实现为简单的附加并行控制路径。例如，即使由于IoT墙壁开关电力供电的灯由于其开关被置于“接通”位置而已经被“接通”，来自IoT控制器的后续信号仍然可以在“开”和“关”状态之间切换灯光。

在某些情况下，可以在更通用的计算系统的环境中模拟IoT“设备”。例如，许多智能手机被认定为通用计算系统，并且经常被用作这样的系统。但是，智能手机将小型物理封装与各种输入/输出设备结合在一起，可以使其至少在特定时间段内用作模拟专用设备。

例如，通过执行适当的应用程序，智能手机可以充当物联网“开关”的角色。

在这种情况下，智能手机屏幕上的“按钮”上的连续的点击可以通过在IoT控制器上执行的软件感测为开关的打开或关闭。

计算机设备

作为本专业领域公知的技术常识，图1的IoT控制器可以通过使用任何合适的计算硬件来实现。合适的硬件可以包括使用一个或多个通用计算机或处理器。

作为本专业领域公知的技术常识，应用程序商店可以作为一个Web服务来实现。可以通过使用任何合适的计算硬件来实现网络服务器。合适的硬件可以包括使用一个或多个通用计算机或处理器。这样的处理器或计算机可以是专用的，或者如近年来流行的那样，它们的使用可以通过各种“云计算”服务提供商来租用。

每个终端用户或开发人员都可以通过一个控制器或应用程序商店，在适当的客户端计算机上执行的基于Web的或者专用本地程序界面进行交互。用于客户端计算机的合适硬件可以包括使用一个或多个通用计算机或处理器。硬件实现技术可以包括使用各种类型的集成电路，可编程存储器（易失性和非易失性）或两者。

尽管可以包括其他类型的组件（例如，光学，微机电或磁性），但是无论是以集成电路形式还是其他形式，计算硬件通常基于使用晶体管（场效应，双极性或两者）。任何计算硬件都具有消耗能量的性质，作为能够执行其功能的必要部分。而且，不管运行得有多快，计算硬件都需要一些时间来改变状态。由于其基于物理设备（电子或其他）的基础，计算硬件（无论小）将占用一定的物理空间。

可编程存储器也经常以集成电路形式实现，并且具有与上述计算硬件相同的物理限制。可编程存储器意图包括使用任何种类的基于物理学的效果或性质的设备，以至少以非暂时性方式存储信息，并且存储与应用程序相对应的时间量。用于实现这种存储的物理效应的类型包括但不限于：通过反馈信号维持特定状态，电荷存储，材料的光学性质变化，磁性变化或化学变化（可逆或不可逆的）。

除非特别指出，否则术语计算硬件，可编程存储器，计算机可读介质，系统和子系统不包括人员或人员可能进行的精神步骤。

对于上述的任何方法，过程或技术，就其被实现为计算机或其他数据处理系统的程序而言，也可以被描述为计算机程序产品。计算机程序产品可以体现在任何合适的计算机可读介质或可编程存储器上。

在计算机可读介质和/或可编程存储器上的这里描述的信息的类型（诸如数据和/或指令）可以被存储在其中计算机可读代码设备上。

计算机可读代码设备可以表示其中可以存储定义的信息单元（比如比特）的存储器部分，从其中可以检索定义的信息单元，或者可以同时存储9术语词汇表

[节点号]一般来说，在图中，节点的数字用方括号括起来，表示对另一个节点的引用（或指针），在另一个图中，用这个数字标记。通常，通过在节点内包括数字的下划线版本（即，节点号）或者通过将数字图形附加到节点来完成用数字标记节点。

适配应用程序和适配数据：用于使通用计算机（GPC）成为嵌入式系统的应用程序和数据。

应用程序：除非上下文另有特别说明，否则在此使用是指由开发者编写以供终端用户使用的应用程序软件项目。

终端用户：实际使用应用程序的实体。可以和开发者是同一个实体。

实体：就“终端用户”和“开发者”的定义而言，可以是个人，团体或组织（例如公司，公司或协会）。

开发人员：负责创建应用程序并进行计算机编程的实体。

图形用户界面：图形用户界面。

同构列表：如本文所使用，是指列表中的每个元素的结构都有一样格式定义

GUI：图形用户界面

IDE：集成开发环境。

：物联网。

物联网设备：请参阅“附加信息”部分。

列表：如本文所使用的，“list”（或“list-organized structure”）用于指任何如下类型的数据结构，其可以以有序的序列存储任意类型和任意复杂度的，无限数量的数据项目元素。因此，一个列表通常可以作为一个数组来实现。然而，数组只是一种实现所需的功能方法。

编程语言：Lua编程语言是1993年在巴西里约热内卢天主教大学开发的。

程序员：Programmer，除非上下文特别指出，否则在此用作开发者“developer”的另一个术语。

表格：如本文所使用的，表格（或“tabular structure”）是指实现所谓关联数组的功能的任何类型的数据结构。关联数组可以看作是键值对的集合。对于特定的关联数组（或表格），每个键只出现一次，但多个键可映射到相同的值。散列函数是一种常用的实现技术，用于将键连接到存储其值的存储位置。

任务：物联网控制器根据特定的适配数据实际执行的终端用户选择的物联网应用程序（或自适应程序）的实例。

: 用户界面。

虽然我们已经结合具体实例描述了本发明，但是很明显存在许多替代方案，根据前面的描述，修改和变化将是显而易见的。比如用任务参数编辑器可以在手机端实现，可用弹出窗口取代下拉菜单，图形用户界面的信号可以被聚集（比如生成一个单独的UI元件，触发该UI元件会连续发出多个预订信号的触发）等等。但很明显的，对于所述技术领域的技术人员来说，他们对本发明的结构和相关部件的改动是不会超出本发明所述的实质和范围的。

Claims (8)

1.一种物联网控制器用户界面的方法，包括：

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一元数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据表示的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一表格的元数据节点，添加相对应的第一表格数据节点给第一数据结构；

e)运行至少包括计算硬件和可编程存储器的配置，根据第一表格的元数据节点的指定结构，添加第一表格的数据节点所需要的至少第一和第二键值对；

f)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第二表格元数据节点的结构，向所述第一数据结构增加相对应的第二表格数据节点；

g)运行至少包括计算硬件和可编程存储器的配置，根据第二表格元数据节点的指定结构，添加第二表格数据节点所需要的至少第一和第二键值对；

h)运行至少包括计算硬件和可编程存储器的配置，将所述第二表格数据节点连接到所述第一表格数据节点，使得所述第二表格数据节点是所述第一表格数据节点的一个键值对的后代，即键值对的值；

i)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构作为第一应用程序的第一输入参数的第一自变量。

2.一种物联网控制器用户界面的方法，包括：

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一元数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据表示的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一列表型元数据节点，创建相对应的第一数据结构的第一列表型数据节点；

f)运行至少包括计算硬件和可编程存储器的配置，创建所述第一列表型数据节点使其能够接收数据的有序列表；

g)运行至少包括计算硬件和可编程存储器的配置，在所述第一图形用户界面中指示所述第一列表型数据节点时，接收来自所述第一终端用户的第一信号；

h)运行至少包括计算硬件和可编程存储器的配置，响应接收到的所述第一信号，识别第一子元数据节点，第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

i)运行至少包括计算硬件和可编程存储器的配置，响应所述第一信号并根据所述第一子元数据节点创建所述第一列表型数据节点的第一子数据节点最为列表元素；

j)运行至少包括计算硬件和可编程存储器的配置，当第一列表型数据节点被指示时，响应第一列表数据节点的每个附加信号，根据第一子元数据节点，创建所述第一列表型数据节点的附加子数据节点；

k)运行至少包括计算硬件和可编程存储器的配置，当第二列表数据节点在第一图形用户界面中被指示的时候，接收来自第一终端用户的第二信号，该第二列表型数据节点是所述第一列表型数据节点的后代，也就是第一列表的元素节点；

l)运行至少包括计算硬件和可编程存储器的配置，创建所述第二列表型数据节点使其能够表示数据的有序列表；

m)运行至少包括计算硬件和可编程存储器的配置，响应接收所述第二信号，识别与所述第二列表型数据节点对应的第二列表型元数据节点；

n)运行至少包括计算硬件和可编程存储器的配置，识别第二子元数据节点，该第二子元数据节点作为第二列表型元数据节点的唯一子节点描述了列表元素的数据类型；

o)运行至少包括计算硬件和可编程存储器的配置，响应所述第二信号，根据所述第二子元数据节点，创建第二子数据节点作为所述第二列表型数据节点的子数据节点代表列表元素；

p)运行至少包括计算硬件和可编程存储器的配置，当第二列表型数据节点被指示时，响应每个附加信号，根据第二子元数据节点，创建所述第二列表型数据节点的附加子数据节点；

q)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构；该第一数据结构作为所述第一应用程序的第一输入参数的第一自变量。

3.一种物联网控制器用户界面的方法，包括；

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一元数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据表示的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一表格的元数据节点，添加相对应的第一表格数据节点给第一数据结构；

e)运行至少包括计算硬件和可编程存储器的配置，根据第一表格元数据节点的指定结构，添加第一表格型数据节点所需要的至少第一和第二键值对；

f)运行至少包括计算硬件和可编程存储器的配置，创建第一列表型数据节点使其表示数据的有序列表，作为第一表格型数据节点的一个键值对的值；

g)运行至少包括计算硬件和可编程存储器的配置，当该第一列表型数据节点的一个键值对后代在在第一图形用户界面中被指示时，接收来自第一终端用户的第一信号；

h)运行至少包括计算硬件和可编程存储器的配置，识别第一列表型数据节点对应的第一元数据格式的第一列表型元数据节点；

i)运行至少包括计算硬件和可编程存储器的配置，识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

j)运行至少包括计算硬件和可编程存储器的配置，响应第一信号，根据第一子元数据节点，创建第一列表型数据节点的第一子数据节点；

k)运行至少包括计算硬件和可编程存储器的配置，当第一列表型数据节点被指示的时候，响应于每个附加信号，根据第一子元数据节点，创建第一列表型数据节点的额外子数据节点；

l)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构，使其作为第一应用程序的第一输入参数的第一自变量。

4.一种物联网控制器用户界面的方法，包括：

a)运行至少包括计算硬件和可编程存储器的配置，接收第一应用程序，该第一应用程序执行时可以远程访问一个或多个物联网设备；

b)运行至少包括计算硬件和可编程存储器的配置，访问第一应用程序的第一参数关联数据格式的第一数据；

c)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据的格式，操作第一图形用户界面以便第一终端用户创建第一个数据结构；

d)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一列表型元数据节点，创建相应的第一数据结构的第一列表型数据节点；

e)运行至少包括计算硬件和可编程存储器的配置，创建所述第一列表型数据节点使其能够表示数据的有序列表；

f)运行至少包括计算硬件和可编程存储器的配置，当所述第一列表型数据节点在第一图形用户界面中被指示时，接收来自所述第一终端用户的第一信号；

g)运行至少包括计算硬件和可编程存储器的配置，响应所述第一信号，识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

h)运行至少包括计算硬件和可编程存储器的配置，响应于所述第一信号，根据所述第一子元数据节点，创建所述第一列表型数据节点的第一子数据节点；

i)运行至少包括计算硬件和可编程存储器的配置，当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点，创建第一列表型数据节点的附加子数据节点；

j)运行至少包括计算硬件和可编程存储器的配置，响应于来自第一终端用户的第二信号，添加第一表格数据；该第一表格数据是第一列表型数据节点的后代，作为列表的元素；

k)运行至少包括计算硬件和可编程存储器的配置，根据第一元数据格式的第一表格元数据节点的指定结构，添加第一表格数据节点所需要的至少第一和第二键值对；以及

l)运行至少包括计算硬件和可编程存储器的配置，提交第一数据结构作为第一应用程序的第一输入参数的第一自变量。

5.一种物联网控制器的用户界面系统，包括：

一个或多个处理器和可编程存储器，其中系统配置包括：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据第一元数据格式的第一表格元数据节点来完成添加相应的第一对应表格数据节点给第一数据结构；

根据第一表格元数据节点来完成添加第一表格数据节点所需要的至少第一和第二键值对；

根据第一元数据格式的第二表格元数据节点完成添加相应的第二表格数据节点到第一数据结构；

根据第二表格元数据节点来完成添加第二表格数据节点所需要的至少第一和第二键值对；

完成将第二表格数据节点连接到第一表格数据节点，使得第二表格数据节点是第一表格数据节点的键值对的值；以及

完成将第一数据结构作为第一输入自变量提交给第一应用程序的第一参数。

6.一种物联网控制器的用户界面系统，包括：

一个或多个处理器和可编程存储器，其中系统配置包括：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问所述第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据第一元数据格式的第一列表型元数据节点来完成创建第一数据结构的第一对应列表型数据节点；

完成创建第一列表型数据节点使其能够表示数据的有序列表；

在所述第一图形用户界面中指示所述第一列表型数据节点时，完成从所述第一终端用户接收第一信号；

响应于接收到所述第一信号，完成识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

响应于所述第一信号，根据所述第一子元数据节点来完成创建第一列表型数据节点的第一子数据节点；

当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点完成创建第一列表型数据节点的附加子数据节点；

当第二列表型数据节点，作为第一列表型数据节点的后代和列表元素，在第一图形用户界面中被指示，完成从第一终端用户接收第二信号；

完成创建第二列表型数据节点使其能够表示数据的有序列表；

响应接收第二信号，完成识别第二列表型数据节点对应的第二列表型元数据节点；

完成识别第二子元数据节点，即第二列表型元数据节点的唯一子元素描述了列表元素的数据类型；

响应所述第二信号，根据所述第二子元数据节点来完成创建所述第二列表型数据节点的第二子数据节点；

当第二列表数据节点被指示，响应每个附加信号，根据第二子元数据节点来完成创建第二列表型数据节点的附加子数据节点；以及

完成将第一数据结构作为第一输入自变量提交给第一应用程序的第一参数。

7.一种物联网控制器的用户界面系统，包括：

一个或多个处理器和可编程存储器，其中系统被配置包含：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问所述第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据第一元数据格式的第一表格元数据节点，完成添加对应的第一表格数据节点给第一数据结构；

根据所述第一表格元数据节点来完成添加所述第一表格数据节点所需至少第一和第二键值对；

完成创建第一列表型数据节点使其能够表示数据的有序列表；

当第一列表数据节点，作为第一表格数据节点的一个子键值对的一个后代，在第一图形用户界面被指示，完成从第一终端用户接收第一信号；

完成识别第一列表型数据节点所对应的，第一元数据格式的第一列表型元数据节点，对应所述第一列表型数据节点；

完成识别第一子元数据节点，即第一列表型元数据节点的唯一子元素描述了列表元素的数据类型；

响应所述第一信号，根据所述第一子元数据节点来完成创建所述第一列表型数据节点的第一子数据节点作为列表元素；

当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点来完成创建第一列表型数据节点的附加子数据节点作为附加列表元素；以及

完成将第一数据结构作为第一自变量提交给第一应用程序的第一参数。

8.一种物联网控制器的用户界面系统，包括：

一个或多个处理器和可编程存储器，其中系统配置包括：

完成接收对第一应用程序的选择，执行所述第一应用程序时可以远程访问一个或多个物联网设备；

完成访问所述第一应用程序的第一参数关联数据格式的第一元数据；

根据第一元数据格式来完成操作第一图形用户界面，以便允许第一终端用户创建第一数据结构；

根据所述第一元数据格式的第一列表型元数据节点，完成创建所述第一数据结构的第一对应列表型数据节点；

完成创建第一列表型数据节点使其能够表示数据的有序列表；

当第一列表型数据节点在第一图形用户界面被指示时，完成从所述第一终端用户接收第一信号；

响应所述第一信号，完成识别第一子元数据节点，该第一子元数据节点作为所述第一列表型元数据节点的唯一子节点描述了列表元素的数据类型；

响应所述第一信号，根据所述第一子元数据节点来完成创建所述第一列表型数据节点的第一子数据节点作为列表元素；

当第一列表型数据节点被指示时，响应每个附加信号，根据第一子元数据节点完成创建第一列表型数据节点的附加子数据节点作为附加列表元素；

响应来自所述第一终端用户的第二信号，完成添加第一表格数据节点，该第一列表数据节点是第一列表型数据节点的列表元素；

根据第一元数据格式的第一表格元数据节点来完成添加第一表格数据节点所需的至少第一和第二键值对；以及完成将第一数据结构作为第一输入自变量提交给第一应用程序的第一参数。