英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
你的智能家居——
基于Eclipse智能家居和通用远程控制台的个性化用户界面框架
摘要
在过去的几年里，智能家居技术取得了巨大的进步，在我们的日常生活中支持和帮助我们的承诺比以往任何时候都要高。这不仅适用于普通用户，也适用于有特殊需要的人，如老人和残疾人。合适的智能家居设计可以让这些用户拥有更独立的生活，让他们有机会在熟悉的环境中停留更长的时间。因此，智能家居概念可以在解决大多数工业国家存在的人口结构变化方面发挥重要作用。然而，尽管技术看起来很先进，而且预期的收益很高，但是还没有广泛的采用。造成这种情况的原因有很多。其中，未来智能家居的异构用户群缺乏合适的用户界面，不同智能家居系统之间的互操作性较低。解决这些问题的两个平台是Eclipse智能家居(ESH)项目和通用远程控制台(URC)。ESH专注于不同设备和后端技术的集成;URC提供了一个个性化的、可插拔的用户界面。本文分析了这两种制度的异同。根据分析结果，提出了将URC的思想整合到ESH项目中的概念。这一概念是迈向智能家居和环境辅助生活领域的个性化用户界面平台的第一步。
copy; 2016 The Authors. 由Elsevier B.V.发布。这是CC BY-NC-ND许可下的开放获取文章(http://creativecommons.org/licenses/by-nc-nd/4.0/).
由项目主席负责同行评审
关键词：智能家居；AAL；个性化；用户界面；Eclipse智能家居；通用远程控制台；
———
*通讯作者。Lukas Smirek. 电话： 49 711 8923-2672。电子邮件地址：smirek@hdm-stuttgart.de
1877-0509copy; 2016 The Authors. 由Elsevier B.V.发布。这是CC BY-NC-ND许可下的开放获取文章(http://creativecommons.org/licenses/by-nc-nd/4.0/).
由项目主席负责同行评审
doi: 10.1016/j.procs.2016.09.018
1. 介绍
如今，像物联网(IOT)、智能家居或普适计算这样的词已经不再是学术界的兴趣所在。这些概念的出现是由于我们日常生活中互联的电子设备的不断增长。可能的用例范围很广，从花哨的和有趣的用例(例如，视频/音频分发)到对每个人都有帮助的用例(例如，能源管理)，还包括那些为老年人或残疾人提供更参与性生活的用例。特别是智能家居和相关领域的环境辅助生活，其广泛的辅助功能，可以使一个更长的独立生活在家里，并将发挥重要作用，以应对正在发生在大多数工业国家的人口变化。
但是，尽管这些概念的技术基础似乎已经建立1并且所承诺的收益很高，但现实仍然落后于期望，并且尚未得到广泛采用。从作者的角度来看，以下原因特别重要。首先，研究界关注的焦点是技术上可行的1、2、3，而不是真正的用户需求。此外，研究忽略了适当用户界面的主题4）。由于未来智能家居的用户群体将反映我们社会的全方位，因此需要考虑个人用户需求和偏好的个性化用户界面。
第二个问题是不同智能家居系统缺乏互操作性。智能家居市场正在演变，因此用户很难决定选择哪一个。此外，用户很可能通过集成不同的系统获得最高的价值。随着不同系统之间兼容性低的问题出现，设备和后端技术总体用户交互概念的缺失。
由于这些原因，需要一个框架，一方面解决不同后端技术的集成，另一方面提供设备总体和个性化的用户界面。为了实现这样一个系统，选择了Eclipse智能家居项目5（ESH）和通用远程控制台6（URC）进行研究。
选择URC框架是因为两位作者参与了相关的开发和标准化过程。之所以选择ESH，是因为它与URC运行时实现一样，遵循中央网关的方法，而不是像其他物联网平台那样依赖分布式操作系统。像AllJoyn框架这样的框架直接在目标设备上定位它们的代码。具有中央网关的类似体系结构使两个框架的集成更加容易。我们选择的另一个理由是URC和ESH的开源性质；此外，这两个项目都是由社区而不是行业驱动的。
本文的其余部分结构如下。在下面的部分中，我们将在一些示例性用例的基础上介绍个性化用户界面的需求和要求。第3节介绍了ESH和URC的核心概念。第四节是我们对这两个系统的分析。在第5节中，我们提出了如何将URC框架的思想和主要好处转移到ESH项目的概念。
2. 个性化用户界面要求
本文旨在评估URC和ESH的个性化特征，特别关注图形用户界面。在评估的第一部分中，比较了系统架构的可用组件和一般特性。在下一步中，将比较用于描述连接设备和服务的系统抽象模型的结构和表达性。
对物理设备的抽象表示的需求可以通过以下用例来说明：
- 通常，老年人对特定的设备很熟悉，但在适应新设备时遇到了问题。由于任何设备或早或晚都会出现故障(如洗衣机、暖通空调系统等)，所以保持熟悉的用户界面对人们是有益的。为此，需要在智能家居系统中分离物理设备及其抽象表示(U1)。
- 这种分离可以实现许多其他用例，其中包括支持因意外而瘫痪的用户。在这种情况下，用户和他们的家人想要呆在他们熟悉的家里，而不是带着特殊的设备搬进新家。与交换设备相比，仅仅为了一个难以访问的用户界面，提供一个替代的用户界面(例如，交换或补充一个支持眼球跟踪的触摸屏控制面板)更划算，也更友好(U2)。
- 通常，智能家居是由多个有不同需要的人居住，例如残疾人士或儿童，他们应获得有限的使用某些功能的机会。有了一个公共的抽象层，就可以同时将不同的、个性化的用户界面连接到它(U3)。
然而，有时不仅需要可交换的，还需要自适应的用户界面。用户界面的调整可以在不同的层次上进行10。其中一些如调整对比度或字体大小，以及考虑屏幕大小或给用户界面一个呈现平台的本机外观和感觉，可以很容易地由控制器设备在运行时完成。因此，这超出了我们的考虑范围。但是，当需要为残疾人提供不同语言的用户界面或为不同文化领域(U4)提供图标时，有必要交换用户界面内容的某些部分。为了使这些辅助的用户界面组件对一个大的用户组可用并且独立于位置，需要一个UI组件的中央存储库11。
此外，给第三方机会为更窄的用户组(U5)提供他们自己的解决方案是有利的(为聋人提供的罕见言、手语视频或其他辅助技术(AT)解决方案)。这样的存储库应该是开放的和可扩展的。此外，第三方应该能够在一个非常模块化的基础上做出贡献。最后，讨论了系统如何处理任何用户界面调整所必需的使用上下文。
3. 技术概述
本节解释URC和ESH最重要的特性，以便对这两个框架有一个共同的理解。更多详细的描述可以在5和13中找到。
3.1. 通用远程控制台
通用远程控制台 (UCR6,14) 是一个从一开始就设计的框架，用于支持个性化和可交换的用户界面9。URC的主要思想是让每个用户都能够控制任何设备或服务(目标)，并使用最适合他们需要的用户界面。目标可以从电视亭到气象服务。因此，每个目标都公开其操作用户界面的抽象描述—用户界面套接字描述(简称套接字描述)—作为目标和任何已开发UI之间的可靠契约。除了套接字描述及其内容之外，还可以定义更多的UI资源，如各种语言的标签和帮助文本或图片，以便进行UI呈现。资源可以直接存储在目标上，也可以存储在专用的、全局可访问的资源服务器上。在运行时，任何控制器都可以连接到目标，读取其套接字描述并使用相关资源(可能来自第三方)呈现个性化的用户界面。不符合ISO/IEC标准的目标可以通过通用控制中心13(UCH)进行集成。这个中间件解决方案从资源服务器下载套接字描述，并将它们公开给任何控制器。控制器可以通过URC HTTP协议15像连接常规目标一样连接到UCH(如图1所示)。
图1 通用控制中心(UCH)架构。UCH是控制器(左)和目标(右)之间的中间件。UCH可以从资源服务器下载用户界面资源。
3.2. Eclipse智能家居
ESH为智能家居和环境辅助生活解决方案提供了灵活、模块化的框架，重点关注异构环境。ESH的目标不是定义一个必须由不同设备支持的通用通信协议，而是应对当前非常分散的智能家居系统和物联网设备市场。所提供的模块形成了一个抽象和转换框架，以支持跨系统和协议边界的用例和交互5。图2提供了作为ESH基础的openHAB体系结构的概述。通过加载特定的绑定，可以将各种设备或服务(如电视机或天气服务(事物))连接到框架上。绑定实现特定于事物的协议，并通过事件总线连接，以支持组件间通信。中心项存储库也连接到事件总线。存储的变量(项)支持有状态交互。
ESH定义了一个声明性模型来描述连接到ESH网关的事物。该模型包括事物类型和渠道类型的概念。每一个连接的设备或服务都是某种类型的东西。事物的功能是由频道类型来描述的，例如电视机的体积或当前的温度。通道类型应该是目前约30个标准类别中的一个，这些类别进一步增加了语义，对用户界面呈现非常有用。
在运行时，一旦发现一个新内容，它的通道就链接到项目存储库中的一个项目。这允许通过用户界面或通过规则的连接进行远程控制。此外，在相关通道类型中给出的信息可用于自动生成用户界面。在呈现用户界面时，可以考虑来自不同图标集(例如classic或modern)的图标。根据通道类别和通道的当前值选择图标。
图2 openHAB架构(ESH的基础) openHAB事件总线通过绑定(底部)将控制台、日志记录工具和存储库(顶部)与智能家居的设备和服务连接起来。
4. 通用远程控制台与Eclipse智能家居的比较
4.1. 体系结构
ESH框架和URC参考实现(UCH)都是基于java的模块化系统。当ESH使用OSGi框架时，UCH实现了自己的机制来加载额外的组件。为了能够扩展系统并连接到新设备，使用了模块化和热部署的原则来加载新组件。此外，这两个系统都支持新连接设备和服务的发现。
项目存储库、规则引擎和连接事件总线等元素只能在ESH框架中找到。在UCH参考实现中，有状态信息必须直接存储在目标适配器中。目前，UCH中还没有实现规则引擎或事件总线。尽管如此，UCH仍然允许以用户界面为目标。然而，不同目标和决策过程之间的通信必须直接在用户界面层的代码中实现。同样，规则引擎需要驻留在控制器上，让用户有机会根据自己的需要配置智能家居。虽然在ESH中可以使用具有自己语法的规则引擎，但在URC框架中必须对规则进行硬编码。
在ESH框架中找不到URC资源服务器这样的概念来存储额外的UI组件(例如，不同语言的标签或不同的图标集)并支持(U4)之类的用例。不过，ESH参考实现openHAB 216有离线和在线版本。如果本地安装的代码不支持添加的设备或服务，在线版本将自动从远程GIT存储库下载新的绑定。但是，在运行时不支持根据当前连接的设备和服务的抽象描述下载用户界面或其部分内容的概念。包含图标集的绑定也可以从GIT存储库下载。但是，这是由用户初始化的，而不是由系统初始化的——因此不存在用户配置文件的概念。而且，GIT存储库中包含的组件没有被索引以供发现。这与URC资源服务器形成了对比，在URC资源服务器中，所有用户界面组件都被索引，并且可以根据任何给定的用户配置文件或使用上下文进行搜索。
4.2. 连接设备和服务的用户界面组件和建模
URC框架和ESH框架都定义了XML语言，以抽象的方式描述连接的设备和服务。这些信息可以用于用户界面的自动生成，以及用户界面开发人员的可靠契约。虽然这两个概念在描述连接设备和服务的思想上是相似的，但是它们在表达性和用于用户界面个性化的方式上是不同的。在URC中，抽象描述的概念称为socket，而在ESH框架中提到了事物类型和通道类型。由于U
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[238204]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
