英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
科学直击
摘自 计算机科学 98（2016）107-116
第7届关于新兴的普适系统和泛在网络的会议（EUSPN2016）
只是一个智能家居或者你的智能家居——这是一个基于智能家居编程和通用远程遥控用于私人定制用户界面的框架
摘要
智能家居科技在过去几年来完成了大量的工程项目，并且比起以往，它能更好的支持和帮助我们的日常生活。它不仅仅只适用于普通用户，还能满足像老人与残疾人这样有特殊需求的人。智能家居这种适宜的设计能使这些用户更加自主地生活并且给予他们能更长时间地在熟悉的环境下生活的机会。因此，当为了解决大多数工业国家中出现的人口统计变化时，智能家居这一理念扮演着重要角色。然而，尽管技术看起来很先进，期望收益高，但是这一理念至今还没被广泛地接受。导致这一现象出现的原因有很多。在这些原因中，我们能发现的问题是缺少合适的用户界面来适应各式各样的未来智能家居的用户群体和不同的智能家居系统之间的通用性很低。智能家居编程（ESH）和通用远程遥控（URC）这两个平台能解决这些问题。ESH着重于整合不同的硬件和后端技术；URC提供了一个可定制，可插入的用户界面。这篇文章将分析这两种系统的异同。分析结果表明，一种将URC整合进ESH工程的观点被提及。这种观点的第一步是面向一个在智能家居和环境辅助起居领域里私人定制用户界面的平台。
关键词：智能家居；环境辅助起居；私人定制；用户界面；智能家居编程；通用远程遥控；
1.介绍说明
目前，像物联网（IOT），智能家居或者通用远程遥控已经不再仅仅是学术兴趣上的词语。这些观念的形成是由每天不断增长的内部联系，电子元件造成的。可使用的案例从想象的到娱乐的（例如：视频/音频器）再到对每个人都有帮助的（例如：能源管理）并且这也能给与老年人和残疾人一个可供分享的生活。尤其是智能家居和与其相关的环境辅助起居，他们在为残疾人设计有着广泛的影响，给了他们一个更加独立自主的生活。同时也在大多数工业国家中的人口统计变化中扮演着重要角色。
然而，尽管这些观念的技术基础看起来已经建立并且承诺的预期收益很高，现实情况是仍然远低于预期值然而这些观念也没有被广泛接受。
在笔者看来，下文的这些原因尤其重要。第一，研究所比起用户的真正需求更在乎技术上的发展。第二，研究所忽视了合适的用户界面。第三，既然未来智能家居的用户群体能反应我们整个社会，我们需要优先考虑个性化的用户界面与个体用户的需求。
第二个问题是不同的智能家居系统之间缺少互通性。由于智能家居市场刚刚开始发展，因此对于用户来说选哪一个系统是件非常困难的事。此外，用户有可能通过结合不同的系统来获得最好的体验。在这些问题之中，由于不同系统之间低的互通行，让硬件和后端技术对用户首要的相互影响性变得微乎其微。
取决于上述原因我们需要一个框架，一个一方面能将不同的后端科技结合，另一方面能解决首要的物质供应问题和私人定制用户界面。为了实现这一系统，我们选择智能家居编程和通用远程遥控作调查。
之所以选择通用远程遥控框架是因为两位作者涉及相关的发展和标准化流程。而选择智能家居编程的原因就像URC运行启动时，它遵循通往核心的途径而不是依赖一个发散的运行系统，像其他的物联网平台那样。这些框架例如AllJoyn框架直接将他们的代码输入到目标硬件上。一个有着相近的核心途径的结构让两种框架的结合变得更容易。另一种争议是URC和ESH的开源类型；还有一点要说的是所有的程序都由团体而非工业运作。
接下来的文章结构是这样的。下一章节将介绍基于用户说明案例的一些私人定制用户界面的需求。第三节将介绍ESH和URC的核心观念。第四节包含我们对两种系统的分析。第五节我们会提出一个观点：怎么将创意和主要利益由URC框架转向ESH工程。
2.个性化用户界面的需求
这章旨在解释尤其注重图像用户界面的个性化URC和ESH的特点。在第一部分的解释中，我们已经完成了对考虑到有效成分和通常特点的系统结构之间的对比。接下来，考虑到他们的结构和表现力，我们将对系统描述相关联硬件和服务的抽象模型进行对比。
对抽象代表和实体硬件的需求可以从以下的使用实例来说明：
- 经常地，年长的人更熟悉一种专门的设备并且很难适应另一个新的。既然设备迟早会坏（例如：洗衣机，HVAC系统），对于人们来说保持相似的用户界面是很有益的。为了这么做，我们需要将智能家居系统的物理设备和抽象代表分离。
- 这种分离生成了其它许多使用案例，在这些案例中有一个帮助了因意外变瘫痪的人。在这个案例中，这个使用者期望住在他们熟悉的家里而不是搬去由特殊设备的新家。比起更换设备，弄一个不易掌握的用户界面，只提供一个可替换的用户界面会更加高效和易掌握。（例如：交换或补充一个支持视线追踪的可触摸控制板）
- 通常地，智能家居是有着不同需求的各式各样人的栖息之所，例如残疾人和需要被限制接触重要功能的孩童。拥有一个通用的抽象层就可以同时连接不同的、个性化的用户界面。
然而，有时不仅仅需要可交换的还需要有适应性的用户界面。用户界面的适应性能体现在不同的等级上。他们中有的像改变对比度或者字体大小，同时也考虑到屏幕的大小或者让用户感觉到用户界面的本土化，这些在控制设备运行时都很容易做到。因此这不在我们的考虑范围内。然而，当用户界面被提供给不同语言的残疾人或不同文化图标的人时，有必要去交换一些用户界面内容。为了让这些增添内容适用于大的用户群体和自主地区，我们需要一个UI内容核心资料库。
同时，让第三方给小的用户群提供他们自己的解决方法也是有利的办法。（小语种，给聋哑人看的手语电视或者其他科技辅助解决方法）。这种数据库应该是开源和可扩展的。此外，第三方应该能够贡献一个充足的模型化基础。最后，在各种使用背景下，我们需要考虑怎么用系统做出任何用户可接受界面。
3.科技概念
这一节解释了URC和ESH最重要的特点并对这两种框架有一个大体的了解。可以找到更详细的描述。
3.1通用远程遥控
通用远程控制台是一种设计初衷是为了实现个性化和可交换的用户界面的框架。URC的主要目的是使每个用户能够控制任何设备或服务(目标)的用户界面来最大限度满足他们的需求。因此，每个目标都表明了其操作用户界面的抽象描述——用户接口套接字描述(短接口套接字描述)——这是目标和任何已开发UI之间的可靠协议。除了套接字描述和它们的内容外，还可以定义更多的UI资源，比如标签，以及各种语言或图片中的文本，以供UI呈现。资源可以直接存储在目标上，也可以存储在专用的、全局访问的资源服务器上。在运行时，任何控制器都可以连接到目标，读取它的套接字描述并使用相关资源(可能来自第三方)来呈现个性化的用户界面。不符合ISO/IEC标准的目标可以通过通用遥控显示器 (UCH)集成。这个中转站从资源服务器下载套接字描述，并将它们暴露给任何一个控制器。控制器可以通过URC HTTP协议15(如图1所示)连接到一个普通目标。
图1. 通用遥控显示器（UCH）结构.UCH是控制器（左）和目标（右）之间的中转站.UCH能从资源服务器下载用户资源.
3.2智能家居编程
ESH为智能家居和环境辅助生活解决方案提供了一个侧重于异构环境的灵活的、模块化的框架。与定义一种必须由不同设备支持的公共通信协议相比，ESH的目标是应对目前非常分散的智能家庭系统和物联网设备市场。所提供的模块构成了一个抽象和转换框架，以支持跨系统和协议边界的用例和交互。图2提供了开放集线器体系结构的概述。这是ESH的基础。各种设备或服务(例如，电视或天气服务)可以通过加载特定的绑定连接到框架。绑定实现一种特定的协议，通过事件总线连接，以实现组件间通信。中心项存储库也连接到事件总线。存储的变量(项)支持有状态交互。
ESH定义了一个公开模型来描述连接到ESH网关的东西。该模型包含了事物类型和通道类型的概念。每个连接的设备或服务都是特定类型的东西事物。事物的功能是通过频道类型来描述的，例如电视机的音量或当前的温度。通道类型应该是当前30个标准类别中的一个，它们添加了进一步的语义，对于呈现用户界面非常有用。
图2. 开放集成器架构(ESH的基础)。开放集成器事件总线连接控制台、日志记录设备和存储库(顶部)和智能家居的设备和服务(底部)。
4.通用远程遥控和智能家居编程的对比
4.1结构
ESH框架和URC参考安装启动都是基于java系统、模块化的。虽然ESH使用了OSGi框架，但它启用了自己的机制来加载额外的组件。为了能够扩展系统并连接到新设备，加载新组件遵循模块化和热部署的原则。此外，这两个系统都支持发现新连接设备和服务。
诸如项目存储库、规则引擎和连接事件总线等元素只能在ESH框架中找到。在UCH参考实现中，有状态信息必须直接存储在目标适配器中。目前，规则引擎或事件总线还没有实现。尽管如此，它仍然允许目标用户界面。然而，不同的目标和决策过程之间的交流必须在用户界面层的代码中直接实现。同样，规则引擎需要驻留在控制器上，让用户有机会根据自己的需要配置智能家居。而在这种带有语法可用的规则引擎中，URC框架规则必须进行硬编码。
如URC资源服务器的用于存储附加UI组件(例如，不同语言或不同图标集的标签)的概念，并且支持诸如(U4)的使用情况不能在ESH框架中找到。但是，ESH参考实现开放集成器作为离线和在线版本。在线版本自动从远程GIT存储库下载新的绑定，以防本地安装的代码不支持添加的设备或服务。但是，在运行时不支持基于其当前连接设备和服务下载用户界面或部分内容的抽象描述概念。还可以从GIT存储库下载包含图标集的绑定。但是，这是由用户而不是系统初始化的，因此不存在用户配置文件的概念。此外，没有发现GIT存储库中包含的组件被索引。这与URC资源服务器形成对比，在URC资源服务器中，所有用户界面组件都被索引，并且可以根据任何给定的用户配置文件或使用上下文进行搜索。
4.2用户界面内容和连接设备服务的建模
URC框架和ESH框架都定义了XML语言，以抽象的方式描述连接的设备和服务。这些信息可以用于用户界面的自动生成，以及为用户界面开发人员提供可靠的合同。尽管这些概念在描述连接设备和服务的概念上是相似的，但它们的表达方式和使用它们的方式不同，它们可以用于用户界面的个性化。在URC中，抽象描述的概念称为套接字，而在ESH框架中提到了事物类型和通道类型。由于URC套接字包含了关于目标用户界面的信息，而不是关于目标及其配置的信息，所以它与套接字等价的是一个通道类型或通道组，而不是事物类型。
然而，正如前面提到的，概念在表达性上有所不同。在这两个概念中，可以定义具有数据类型的变量，例如，用于指示电视机的当前频道。ESH使用一组受限制的只有定义值集的数据类型集。开发人员可以为数据类型添加更多的限制，比如最小值和最大值。相反，URC套接字使用XSD数据类型的完全表达性。
此外，ESH只定义了通道类型的概念，这几乎等同于URC套接字描述中的一个变量。在URC中，套接字描述包含指示目标状态的变量，控制控制器和目标之间的同步交互的命令和异步交互的通知。更重要的是，URC套接字描述可以包含前置和后置条件来模拟任务和它们的依赖关系，例如，DVD只能在播放机的碟机中启动。
在ESH中，不可能定义命令。然而，在某些情况下，通道的数据类型也定义了一个适用的命令。例如，数据类型转换可以具有“ON”和“OF”的值，但也可以发送命令“toggle”。但是，开发人员不能定义新的命令。因此，在控制器和控制之间的一个更复杂的交互可以用URC而不是在ESH框架中技术建模。
接下来，在URC标准中，在套接字和额外的用户接口资源之间有严格的分离。套接字描述和资源总是位于单独的文件中。这在ESH框架中是不同的。事物类型和通道类型通常包含标准标签和附加说明(在URC术语中它们将是单独的资源)。不过，也可以在单独的文件中提供ESH框架的标签和描述; 一个文件对应一种语言。
这两个系统在方法上也有不同，指的是抽象描述的位置和附加的UI组件。在ESH框架中，事物类型和通道类型定义直接位于标准化文件夹中的绑定中。对于其他用户界面组件，如语言文件和图标集(作为单独的OSGi包提供)也是如此。这在URC框架中是非常不同的，在URC框架中，资源服务器上存储了附加的用户接口资源。当第三方(如用户界面开发人员或专家)想为特殊的用户界面(U5)提供补充资源时，这是特别有趣的。不需要提供整个图标集，相反，可以为套接字描述的一个特定元素添加一个原子资源(例如，一个触发器的单个标签或象形图)。此外，还可以为一个或多个套接字描述添加完整的用户界面(例如，用于控制电视机和DVD播放器的用户界面)。此外，就像在ESH里一样，格式是完全开放的而且不局限于SVG和JPG。因此，URC在开放性、模块化和可扩展性方面具有优势。通过简单的上载到资源服务器，可以在更细粒度的级别上提供额外的资源。相反，在ESH框架中，替代语言必须直接集成到一个绑定中，从而使整个开发环境的设置成为必要。
这两个框架的另一个不同之处在于，对设备和服务的可用描述是有组织的。URC框架的思想是构建标准化的套接字描述的层次结构。开放URC联盟正在开发一套可以通过任何第三方通过继承机制扩展的标准套接字描述。因此，任
全文共12553字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[16049]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
