Design Goals and Rationale¶

Goals¶

Our aim is to design a framework that simplifies the development and use of smart space applications yet is flexible enough to enable a diverse range of these applications. To balance ease-of-development and flexibility, we want (1) modular building blocks that are (2) controlled in a declarative manner. This simplifies code reuse and evolution and reduces the surface area of the code that a developer must understand. In addition, we want to make it easy for developers to (3) compose high-level abstractions and aggregates e.g., a “room” controller that coordinates all the devices in a room; a “home” controller that coordinates all the rooms, and so forth. Such abstractions simplify development for downstream coders and ultimately simplify the user experience since it is now easier to build applications that expose higher-level controls to users (e.g., putting an entire room into a low-energy mode).

Finally, we also want to simplify the use of smart-home apps. For this, our framework aims to simplify (4) integration with AI/ML frameworks. Doing so paves the way for policies that are automatically learned rather than manually written by users (§6). In addition, we aim to support (5) delegation of controls via which a user can flexibly outsource portions of home management to different third-party services; e.g., outsourcing control over garden irrigation to a landscaping service, or yielding control over the home to a city-run emergency service under certain events. Delegation frees the home owner from the burden of home management but does so in a controlled and fine-grained manner.

我们的目标是设计一个既能简化智能空间应用开发与使用，又具备足够灵活性以支持多样化应用的框架。为在开发简便性与灵活性之间实现平衡，我们希望实现以下几点目标：

提供 模块化的构建块，并通过
声明式方式控制模块。这种设计能够简化代码的复用与演进，同时减少开发者需要理解的代码范围。

此外，我们希望使开发者能够轻松

组合高级抽象与聚合，例如“房间”控制器可以协调房间内的所有设备，“家庭”控制器可以协调所有房间的操作，依此类推。这种抽象不仅简化了下游开发者的开发工作，还最终改善了用户体验，因为开发者能够更轻松地构建提供更高级控制的应用（例如，将整个房间切换到低能耗模式）。

最后，我们还希望简化智能家居应用的使用。为此，我们的框架旨在

简化与 AI/ML 框架的集成，为通过自动学习而非用户手动编写的策略铺平道路（见 §6）。此外，我们还希望支持
控制的委托，使用户能够灵活地将部分家庭管理任务外包给不同的第三方服务。例如，将花园灌溉的控制权委托给园艺服务，或者在特定事件发生时，将整个家庭的控制权交由城市紧急服务机构。控制委托不仅减少了房主的管理负担，还以一种可控且细粒度的方式实现了任务的分配。

Goal

modular building blocks
declarative control
composition of high-level abstractions and aggregates
integration with AI/ML frameworks
delegation of controls

Challenges¶

To some degree, the above are classic goals and our novelty lies only in tackling them in the context of smart spaces. This context raises certain unique challenges:

1) Composition must be adaptive, based on events and conditions in the physical world. Consider a home with “room” controllers that program the devices in that room; this set of devices changes with device mobility (e.g., a roomba) yet must be automatically handled. Delegation also requires adaptive composition – e.g., a room that is mounted to an emergency controller in the event of extreme heat.

2) Policies abound. A key challenge in smart spaces is that there is rarely a single “correct” action and instead user preferences as captured by policies determine the desired behavior of the system - e.g., does the user want the heat turned on when entering a room? to what level? does she prefer appliances to be run at night or when the user is away from the home? And so on. Today’s systems maintain such policies as a flat file of IFTTT rules [31, 48] but this is hard to scale with increasing numbers of devices, difficult to maintain in customized deployments, and at odds with the information hiding that higher-level abstractions provide.

3) Intent specification is messy. In our declarative control paradigm, the dSpace application configures the target state or “intent” for each device based on user policies or other control logic. The challenge that arises in applying this paradigm to our context is that intents may also be determined by interactions in the physical world – e.g., consider a scenario in which a user manually turns on a lamp in a home that is in sleep mode. Ideally, this action should cause the home to reconsider its intended state - e.g., “waking” the relevant room, or the entire house, or perhaps raising an alarm. The exact action to be taken is a matter of policy - the challenge for us is to provide the architectural hooks that allow the developer to more easily express how conflicting intents (e.g., from the virtual vs. physical world) should be resolved.

在某种程度上，以上目标是经典的系统设计目标，而我们的创新之处在于将这些目标应用于智能空间的特定上下文。然而，这一背景也引发了一些独特的挑战：

1) 组合需要具备自适应性，能够根据物理世界中的事件和条件进行调整。例如，假设一个家庭中有“房间”控制器负责管理房间内的设备；设备的移动性（如扫地机器人）会导致设备集合发生变化，这种变化必须能够被自动处理。此外，控制的委托也需要自适应的组合 —— 例如，在极端高温事件中，将某个房间挂载到紧急控制器上。

2) 策略繁多。智能空间中的一个关键挑战在于，系统很少存在单一的“正确”行为，相反，用户偏好决定了系统的预期行为，例如：用户进入房间时是否希望开启暖气？暖气的强度是多少？用户更倾向于夜间运行电器还是在离家时运行？等等。当前的系统通常将这些策略维护为 IFTTT 规则的扁平化文件 [31, 48]，但随着设备数量的增加，这种方式难以扩展，难以维护个性化的部署，而且与高级抽象提供的信息隐藏理念相冲突。

3) 意图的指定较为复杂。在我们的声明式控制范式中，dSpace 应用根据用户策略或其他控制逻辑为每个设备配置目标状态或“意图”。然而，将这种范式应用于智能空间时会产生一个挑战：意图也可能受到物理世界交互的影响。例如，考虑一种场景：在房屋处于睡眠模式时，用户手动打开了一盏灯。理想情况下，这一操作应促使系统重新考虑其目标状态 —— 例如，“唤醒”相关房间、整个房屋，或可能触发警报。具体采取的行动取决于策略，而我们的挑战在于提供架构支持，帮助开发者更轻松地表达如何解决虚拟世界和物理世界之间的意图冲突。

Design choices¶

We highlight the key design decisions that allow dSpace to meet the above goals and challenges.

(1) Separation of control and data. Our first design principle is to decouple data and control processing into distinct abstractions: digivices and digidata, as mentioned in §1. This is in contrast to several existing IoT systems (e.g., HomeAssistant [29]) but is a deliberate choice that we made for two reasons. First, it allows us to adopt different programming paradigms for each: declarative models for control processing and dataflow models for data processing. Second, it allows us to easily leverage existing analytics and AI frameworks [9, 51, 56, 68, 71] rather than reinvent the wheel (see §3.1). I.e., developers of digivice control logic can leverage systems like Tensorflow or Spark while keeping their control logic cleanly separated and easier to evolve.

(2) First-class composition. Our second design principle is to embrace composition as a first-class design primitive, leading to the mount and pipe operators corresponding to digivices and digidata respectively. Such composition allows us to easily program aggregates of devices (e.g., configuring all the devices in a room R by iterating through the devices mounted to R) and to construct digivices at a higher layer of abstraction (e.g., instead of interacting with individual lamps, we can simply configure the brightness of the room). Composition also simplifies reuse since it allows the same building blocks to be composed in different ways to achieve different goals.

我们强调了关键的设计决策，这些决策使得 dSpace 能够实现上述目标并应对相关挑战：

1) 控制与数据的分离。我们的首要设计原则是将数据处理与控制处理解耦，分别抽象为 digivice 和 digidata（如 §1 中所述）。这一设计与现有的一些 IoT 系统（如 HomeAssistant [29]）形成对比，但却是我们出于以下两个原因的深思熟虑之举。首先，这种解耦使我们可以对两者采用不同的编程范式：声明式模型用于控制处理，数据流模型用于数据处理。其次，它让我们能够轻松利用现有的分析和 AI 框架（如 TensorFlow 或 Spark）[9, 51, 56, 68, 71]，而无需从头开始重新开发（详见 §3.1）。例如，开发 digivice 控制逻辑的程序员可以借助这些框架，同时保持控制逻辑的独立性，从而更易于扩展和演化。

2) 一等公民的组合。我们的第二个设计原则是将组合作为一等设计原语，这催生了 digivice 和 digidata 分别对应的 mount 和 pipe 操作符。这种组合方式使我们能够轻松地对设备集合进行编程（例如，通过迭代挂载到房间 R 的设备来配置 R 中的所有设备），并在更高抽象层次上构建 digivice（例如，与其逐个配置灯具，不如直接调整整个房间的亮度）。组合还简化了复用，因为它允许以不同方式重新组合相同的构建模块以实现不同的目标。

Another important design decision is how we constrain composition and the resultant digi-graph. A natural approach would be to compose digis into higher-level aggregates and a hierarchical control tree. This approach captures the natural organization commonly found in the physical world. E.g., consider a scenario where a campus or company headquarters wants to enforce occupancy limits. Each building/office in the campus may have their local policies that translate the campus-wide occupancy limit to per-floor or per-room limit based on which they may adjust the lighting, temperature, humidity, and smart locks settings on individual devices.

另一个重要的设计决策是如何约束组合及由此产生的 digi-graph。一个自然的方法是将 digis 组合成更高层次的聚合体和分层控制树，这反映了物理世界中常见的自然组织。例如，考虑一个校园或公司总部想要实施占用限制的场景。校园内的每栋建筑或办公室可能有自己的本地策略，将全校范围的占用限制转换为每层楼或每个房间的限制，并据此调整个别设备（如灯光、温度、湿度和智能锁）的设置。

However, we do not limit ourselves to just a single static control hierarchy. Instead, a user/developer can define a multi-rooted control hierarchy. E.g., a lamp digivice might be mounted to a room controller (that controls devices in the presence of home occupants) and an energy-efficiency controller (that implements power savings when occupants are absent). As a different example, a digi-graph might include three services separately controlled by home owners, a landscaping service, and an emergency service. Note that allowing multiple control hierarchies to simultaneously configure a device can lead to access conflicts in which different controllers overwrite each other’s configurations (e.g., a lamp’s power level) leading to unpredictable and undesirable outcomes. To avoid access conflicts, we enforce that multiple control hierarchies may simultaneously read the device states but only one control hierarchy is allowed to write/configure the device.

然而，我们并不仅限于单一静态的控制层级结构。相反，用户或开发者可以定义多根控制层级结构。例如，一个灯具 digivice 可以同时挂载到房间控制器（用于管理家庭占用者在场时的设备）和节能控制器（用于在占用者不在场时实现节能）。另一个例子是，一个 digi-graph 可能包括分别由房主、园艺服务和紧急服务控制的三个服务。需要注意的是，允许多个控制层级同时配置一个设备可能导致访问冲突，不同的控制器可能相互覆盖其配置（如灯具的功率级别），从而引发不可预测和不可取的结果。

We achieve this with programmable “yield” and “mount” policies that explicitly determine which hierarchy is allowed to control the device at any point in time (e.g., “yield control to the emergency digivice under <...> condition”). Multirooted hierarchies with explicit yield policies allows dSpace to support delegation and adaptive composition, providing a level of flexibility that goes beyond traditional modular software frameworks that allow code reuse within a single developer/operator context.

为避免访问冲突，我们规定多个控制层级可以同时读取设备状态，但只有一个控制层级被允许写入或配置设备。我们通过可编程的 “yield” 和 “mount” 策略实现这一点，这些策略明确决定了在任何时刻哪个层级被允许控制设备（例如，“在特定条件下将控制权移交给紧急 digivice”）。带有显式 yield 策略的多根层级结构使 dSpace 能够支持委托和自适应组合，其灵活性超越了传统模块化软件框架中仅允许单一开发者或运营者上下文内代码复用的局限。

(3) Embedded policies. dSpace implements embedded policies and intent reconciliation (§3.5) to meet our last two challenges. In dSpace, a policy is contained within a digi; i.e., it is written as a part of that digi’s definition and implementation. Their embedded nature ensures that policies are co-located (i.e., “fate share”) with their associated digi. As such, the scope of an embedded policy is immediately clear: it is determined by the position of its corresponding digi within the overall digi-graph. For example, two rooms – a bedroom and a kitchen – may have different policies for their desired light and sound levels and these policies must only be imposed on devices currently “mounted” to that room. Embedded policies (together with the digi-graph topology) make it easy to correctly identify devices and enforce policy even as devices move from one room to another.

3) 嵌入式策略。dSpace 通过嵌入式策略和意图调和机制（详见 §3.5）应对我们的最后两项挑战。在 dSpace 中，策略是 digi 的一部分，即作为该 digi 定义和实现的一部分编写。这种嵌入式的设计确保策略与其关联的 digi 共存（即“共享命运”）。因此，嵌入式策略的作用范围是明确的：由其对应的 digi 在整个 digi-graph 中的位置决定。例如，两个房间 —— 一个卧室和一个厨房 —— 可能对其所需的光照和声音级别有不同的策略，而这些策略仅应适用于当前“挂载”到相应房间的设备。嵌入式策略（结合 digi-graph 的拓扑结构）使得即使设备从一个房间移动到另一个房间，也能正确识别设备并执行策略。

Finally, we briefly discuss our approach to accommodating device heterogeneity since this has been the focus of much prior work. The common proposal is to address heterogeneity through standardization (e.g., of configuration parameters for a particular class of devices). However, in practice, adoption of such standards has been slow and at times hampered innovation. Thus, in dSpace, we do not assume any standardized device models. At the same time, we liked the idea of shielding developers from the vagaries of vendor-specific APIs. dSpace achieves this through the notion of a universal digivice that exposes a “universal” set of configuration parameters and that includes the code to translate from these universal parameters to a vendor-specific digivice. E.g., consider a universal lamp U that exposes a standardized set of parameters 𝑢 and contains the logic to translate 𝑢 to the parameters 𝑙 of a vendor-specific lamp L. In dSpace, we mount L to U so that any higher-level digivice that U is mounted to is shielded from the details of L.

最后，我们简要讨论了如何应对设备异构性的问题，因为这是许多先前研究的重点。常见的提议是通过标准化来解决异构性问题（例如，为特定类别的设备制定统一的配置参数标准）。然而，在实践中，此类标准的采用速度缓慢，有时甚至阻碍了创新。因此，在 dSpace 中，我们不假设任何设备模型的标准化。与此同时，我们希望将开发者从依赖特定厂商 API 的复杂性中解放出来。dSpace 通过“通用 digivice”的概念实现了这一目标，该通用 digivice 提供了一组“通用”配置参数，并包含将这些通用参数转换为特定厂商 digivice 参数的逻辑。例如，考虑一个通用灯具 U，它提供了一组标准化的参数 𝑢，并包含将 𝑢 转换为特定厂商灯具 L 参数 𝑙 的逻辑。在 dSpace 中，我们将 L 挂载到 U，从而使任何挂载到 U 的更高级 digivice 都无需关心 L 的具体实现细节。

Note that there is no magic here and we are not claiming to have solved the challenge of heterogeneous APIs: someone still has to write U and deal with the idiosyncrasies of L’s implementation. Instead, our only claim is that we’re providing a framework that makes it easy to systematically reuse U and the effort that went into developing it. Moreover, this approach is flexible: developers can choose when and which universal devices to use on a per-device basis.

需要注意的是，这里并不存在什么神奇的解决方案，我们并不声称已经彻底解决了异构 API 的挑战：仍然需要有人编写 U 并处理 L 实现中的各种特性和复杂性。然而，我们的主张是，dSpace 提供了一个框架，使得可以轻松且系统地复用 U 以及开发它所投入的努力。此外，这种方法具有灵活性：开发者可以基于每个设备的需求，选择何时以及在哪些设备上使用通用 digivice。

Putting the pieces together¶

To build an end-to-end smart space application, a developer and/or user selects the desired digivices and digidata, composes them into her desired hierarchy, and then “programs the space” using the declarative API exposed by the digivice at the root of the hierarchy. This high-level input is then translated into control actions (or “intents”) that travel down the hierarchy. Similarly, events from the physical world travel up the hierarchy. Intents and events are processed at each digi in accordance with its embedded policy and this processing may trigger additional control actions and/or intent reconciliation.

为了构建一个端到端的智能空间应用，开发者和/或用户需要选择所需的 digivices 和 digidata，将其组合成目标的层级结构，然后通过该层级根 digivice 所暴露的声明式 API 来 “编程空间”。这种高层次的输入会被翻译成控制操作（或称为“意图”），并沿着层级结构向下传播。同样，来自物理世界的事件会沿着层级结构向上传播。意图和事件在每个 digi 中都会根据其嵌入的策略进行处理，而这种处理可能会触发额外的控制操作和/或意图协调。

Developers follow the above process when developing a dSpace application, while users (i.e., home owners and occupants) do so when setting up and using the application. Users interact with dSpace by configuring high-level intents and writing/customizing policies. We envision that interaction will be done via a user-friendly user interface (UI) and user experience (UX) design, though the design of this UI/UX is beyond the scope of this paper.

开发者在开发 dSpace 应用时遵循上述流程，而用户（即家庭业主和住户）在设置和使用应用时也遵循类似的流程。用户通过配置高层次的意图并编写/自定义策略与 dSpace 交互。我们设想，这种交互将通过用户友好的用户界面（UI）和用户体验（UX）设计来实现，尽管具体的 UI/UX 设计不在本文的讨论范围内。