一个智能家居或您的智能家居——基于Eclipse智能家居和通用远程控制台的个性化用户界面框架外文翻译资料

 2022-05-31 22:05:03

英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料

一个智能家居或您的智能家居——基于Eclipse智能家居和通用远程控制台的个性化用户界面框架

Lukas Smirek*a, Gottfried Zimmermanna, Michael Beiglb
aStuttgart Media University, Nobelstr. 10, 70569 Stuttgart, Germany
bKarlsruhe Institute of Technology, Vincenz-Priessniz-Str. 1, 76131 Karlsruhe, Germany

摘要

在过去的几年中，智能家居技术取得了实质性的进步，并承诺在日常生活中支持和协助我们比以往更高。这不仅适用于普通用户，也适用于有特殊需求的人士，如老人和残疾人士。智能家居的适当设计可以为这些用户提供更加独立的生活，并让他们有机会在更长时间内呆在他们熟悉的环境中。因此，在解决大多数工业国家的人口变化问题时，智能家居概念可以发挥重要作用。然而，尽管技术似乎已经进步并且预期效益很高，但尚未广泛采用。这种情况有各种原因。其中，未来智能家庭异构用户群缺乏合适的用户界面，以及不同智能家居系统之间互操作性差的问题。解决这些问题的两个平台是Eclipse智能家居（ESH）项目和通用远程控制台（URC）。ESH专注于不同设备和后端技术的整合; URC提供个性化的可插拔用户界面。本文分析了两种制度的异同。作为分析的结果，提出了将URC的想法整合到ESH项目中的概念。这个概念是迈向智能家居和环境辅助生活领域个性化用户界面平台的第一步。

关键字：智能家居，AAL; 个性化; 用户界面; Eclipse智能家居; 通用远程控制台;

1.介绍

如今，物联网（IOT），智能家居或泛在计算等词语不再仅仅是学术兴趣。互联电子设备在我们日常生活中的不断发展使这些概念的出现成为可能。可能的用例包括花哨的和有趣的用例（例如：视频/音频发布），以便对每个人都有帮助（例如能源管理），但也可以为老年人或残疾人提供更多的参与性生活。特别是智能家居以及环境辅助生活的相关领域及其广泛的辅助功能可以使家庭更长久的独立生活，并将在应对大多数工业国家正在发生的人口变化时发挥重要作用。然而，虽然这些概念的技术基础似乎已经确立和承诺的好处1，但现实仍然落后于预期，尚未广泛采用。

从作者的角度来看，具有以下特殊重要性原因：

首先，研究界关注的重点是技术上可行的1,2,3，而不是真正的用户需求。另外，研究忽视了适当用户界面的主题4。由于未来智能家居的用户群体将反映我们社会的全部范围，因此需要考虑个人用户需求和偏好的个性化用户界面。

第二个问题是缺乏不同智能家庭系统的互操作性。智能家居市场正在不断发展，因此用户很难决定选择哪一个。此外，用户可能通过集成不同系统获得最高价值。随着不同系统之间兼容性较低的问题出现，设备和后端技术总体用户交互概念缺失。

由于这些原因，需要一个框架，一方面解决不同后端技术的集成问题，另一方面解决设备总体和个性化用户界面的配置问题。为了实现这样的系统，选择Eclipse Smart Home项目5（ESH）和通用远程控制台6（URC）进行调查。

选择URC框架是因为两位作者参与了相关的开发和标准化流程。ESH被选中，是因为就像URC运行时实现一样，它遵循中央网关的方法，而不像其他一些IOT平台那样依赖分布式操作系统。

AllJoyn框架等框架直接在目标设备上查找代码。 具有中央网关的类似架构使得这两个框架的集成更加容易。我们选择的另一个理由是URC和ESH的开源性质; 此外，这两个项目都是由社区而非行业驱动的。

本文的其余部分的结构如下。在下面的章节中，将根据一些说明性用例介绍个性化用户界面的需求和要求。第3节介绍了ESH和URC的核心概念。第4节包含我们对这两个系统的分析。在第5节中，我们提出了一个关于如何将URC框架的想法和主要收益转移到ESH项目的概念。

2.个性化用户界面的要求

本文旨在评估URC和ESH的个性化特性，特别关注图形用户界面。在评估的第一部分中，系统架构的比较是针对可用组件和一般功能进行的。在下一步中，将描述连接设备和服务的系统抽象模型在结构和表现方面进行比较。

以下用例可以说明对物理设备的抽象表示的需求：

（1）通常，老年人熟悉特定的装置，并且有适应新问题的问题。由于任何设备迟早会损坏（例如洗衣机，暖通空调系统），因此人们保持熟悉的用户界面是受益人。为此，需要在智能家居系统中将物理设备与其抽象表示分离（U1）。

（2）这样的分离使许多其他用例成为可能，其中包括支持因一次意外被截瘫的用户。在这种情况下，用户和他们的家人想要呆在他们熟悉的家中，而不是用特殊设备搬进新家。仅仅为了无法访问的用户界面而不是交换设备，仅提供替代的用户界面（例如交换或补充具有一个支持眼睛跟踪的触摸屏控制面板）是更具成本效益和用户友好的（U2）。

（3）通常情况下，智能家居是由多种需求不同的人共同居住的，例如，残疾人或儿童应该被限制进入某些功能。拥有一个共同的抽象层，可以同时连接不同的个性化用户界面（U3）。

但是，有时不仅需要可交换的，而且需要适应性的用户界面。用户界面的适应可以在不同的层次上进行10。其中一些例如调整对比度或字体大小，以及考虑屏幕尺寸或给用户界面提供本机渲染平台的外观和感觉，可以在运行时由控制器设备容易地完成。因此这不在我们考虑的范围内。但是，当用户界面应该以不同语言提供给残疾人或不同文化区域的图标（U4）时，就需要交换用户界面内容的某些部分。为了使这些补充用户界面组件可供大型用户组使用并且与位置无关，需要用于UI组件的中央存储库11。

此外，向第三方提供针对较窄用户群（U5）（罕见语言，为聋人或其他辅助技术（AT）解决方案的签名视频）提供自己解决方案的机会是有利的。这样的存储库应该是开放的和可扩展的。同时，第三方应该能够在非常模块化的基础上做出贡献12。最后，要考虑系统如何处理任何用户界面适配所需的使用环境。

3.技术概述

本节介绍URC和ESH最重要的特点，以便对这两个框架达成共识。在5和13中可以找到更详细的说明。

3.1.通用远程控制台

通用远程控制台（URC6,14）是从一开始就设计的一个框架，用于实现个性化和可交换的用户界面9。URC的主要思想是使每个用户都可以通过用户界面最好地满足他们的需求来控制任何设备或服务（目标）。目标范围可以从电视亭到天气服务。因此，每个目标都会公开其操作用户界面（用户界面套接字描述（短套接字描述））的抽象描述，该描述作为目标和任何开发用户界面之间的可靠合同。除了套接字描述及其内容之外，还可以定义更多UI资源，如各种语言或图片中的标签和帮助文本，以用于UI呈现。资源可以直接存储在目标上，也可以存储在全球可访问的专用资源服务器上。在运行时，任何控制器都可以连接到目标，读取其套接字描述并使用相关资源（可能来自第三方）呈现个性化用户界面。不符合ISO / IEC标准的目标可以通过通用控制集线器13（UCH）集成。该中间件解决方案从资源服务器下载套接字描述并将它们公开给任何控制器。控制器可以通过URC HTTP15协议连接到UCH，就像常规目标一样（见图1）。

图1.通用控制集线器（UCH）架构。UCH是控制器（左侧）和目标（右侧）之间的中间件。UCH可以从资源服务器下载用户界面资源。

3.2.Eclipse智能家居

ESH为智能家居和环境辅助生活解决方案提供了一个灵活的模块化框架，专注于异构环境。ESH不是定义必须由不同设备支持的通用通信协议，而是致力于应对当前非常分散的智能家庭系统和物联网设备市场。提供的模块形成一个抽象和翻译框架，以实现跨系统和协议边界的用例和交互5。图2概述了作为ESH基础的openHAB体系结构。通过加载特定的绑定，可以将各种设备或服务（例如电视机或天气服务（东西））连接到框架。绑定实现了特定于对象的协议，并通过事件总线进行连接以启用组件间通信。中央项目库也连接到事件总线。存储的变量（项目）启用有状态的交互。

ESH定义了一个声明模型来描述连接到ESH网关的东西。该模型包含事物类型和渠道类型的概念。每个连接的设备或服务都是特定类型的东西。事物的功能通过频道类型来描述，例如电视机的音量或当前温度。频道类型应该是目前30种标准类别中的一种，这些类别增加了语义，对用户界面呈现非常有用。

在运行时，只要发现了新事物，它的频道就会链接到项目存储库的一个项目。这可以通过用户界面或通过规则连接进行远程控制。此外，相关通道类型中给出的信息可用于自动生成用户界面。在渲染用户界面时，可以考虑来自不同图标集（例如古典或现代）的图标。图标的选择取决于通道类别和通道的当前值。

图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 2可用16作为离线和在线版本。在线版本自动从远程GIT存储库下载新绑定，以防本地安装的代码不支持添加的设备或服务。但是，运行时不支持基于其抽象描述下载与当前连接的设备和服务相关的用户界面或其部分的概念。包含图标集的绑定也可以从GIT存储库下载。但是，这是由用户而不是由系统初始化的，因此没有用户配置文件的概念。此外，GIT存储库中包含的组件不会编入索引以供发现。这与URC资源服务器形成对比，在该服务器中，所有用户界面组件都被编入索引，并且可以根据任何给定的用户配置文件或使用环境进行搜索。

4.2.用户界面组件、连接设备和服务的建模

URC框架和ESH框架都定义了XML语言，以抽象的方式描述连接的设备和服务。 这些信息可以用于自动生成用户界面，以及用户

全文共12832字，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[11440]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章