Design

Abstractions

A smart space consists of physical and abstract entities. Using dSpace, developers create digital abstractions (“digis”) to control these entities and process the data they generate. Specifically, we introduce two core abstractions: digivice and digidata, which we depict as shown in Fig.1a.2

Digivice: A digivice enables declarative control over physical devices and other digivices. Each digivice (𝐷) contains four key components:

智能空间由物理实体和抽象实体组成。在 dSpace 中，开发者创建数字抽象（“digis”）来控制这些实体并处理它们生成的数据。具体而言，我们引入了两个核心抽象：digivice 和 digidata，如图 1a 所示。

Digivice: Digivice 使得对物理设备和其他 digivice 的声明式控制成为可能。每个 digivice (𝐷) 包含四个关键组件：

(i) A model (𝐷.𝑚𝑜𝑑): this is a set of attribute-value pairs that capture the intended state or the intent for the digivice, its current state or status, events generated, and other relevant information – the list of attributes can be found in Table 1 and sample digivice models in Fig.1b and Fig.1d.

(ii) A list of the digivice’s children (𝐷.𝑐ℎ) in the digi-graph.

(iii) A driver, 𝐷.𝑑𝑟𝑣(): this is the code whose main function is to reconcile the digivice’s intended state (𝐷.𝑚𝑜𝑑.𝑖) with its current state (𝐷.𝑚𝑜𝑑.𝑐). I.e., based on current events and conditions, as well as policies (described below), the driver takes action(s) to move the digivice’s current state towards its intended one. Actions might involve directly interfacing with and controlling physical devices, programming the intents of its children in the digi-graph, generating events etc..

(iv) Policies (𝐷.𝑝𝑜𝑙): these are rules that can be written by the developer or the user that guide how the dSpace driver responds to physical events. Policies are key to programming/customizing an application’s behavior to specific scenarios and user preferences.

(i) 模型 (𝐷.𝑚𝑜𝑑)：这是一个属性 - 值对的集合，用于捕获 digivice 的预期状态或意图、当前状态或状态、生成的事件及其他相关信息——属性列表可以在表 1 中找到，示例 digivice 模型见图 1b 和图 1d。

(ii) digivice 的子级列表 (𝐷.𝑐ℎ)：这些是 digivice 在 digi-graph 中的子级。

(iii) 驱动程序 (𝐷.𝑑𝑟𝑣())：这是代码，其主要功能是协调 digivice 的预期状态 (𝐷.𝑚𝑜𝑑.𝑖) 和当前状态 (𝐷.𝑚𝑜𝑑.𝑐)。即，根据当前的事件和条件以及策略（见下文），驱动程序采取措施使 digivice 的当前状态朝向预期状态移动。操作可能涉及直接与物理设备接口并控制它们、编程其在 digi-graph 中子级的意图、生成事件等。

(iv) 策略 (𝐷.𝑝𝑜𝑙)：这些是开发者或用户可以编写的规则，指导 dSpace 驱动程序如何响应物理事件。策略对于编程/定制应用程序的行为以适应特定场景和用户偏好至关重要。

Digidata: A digidata enables data processing to be integrated natively with digivices. A digidata follows the same design pattern as a digivice with a few differences/extensions: (i) the digidata’s model (𝑇 .𝑚𝑜𝑑) includes data input (𝑇 .𝑚𝑜𝑑.𝑖𝑛) and data output (𝑇 .𝑚𝑜𝑑.𝑜𝑢𝑡) attributes, (ii) the digidata’s driver (𝑇 .𝑑𝑟𝑣()) includes data processing code that implements the data transformation from the input data to the output data as specified by the data input and output attributes. It can also be a thin wrapper around a standalone data processing system such as FFmpeg [16] and Tensorflow [51]. An example “Scene” digidata is shown in Fig.1c. This digidata takes a video stream (from input.URL), implements object recognition, and updates detected objects (to output.Objects).

Digidata: Digidata 使得数据处理能够与 digivices 原生集成。Digidata 遵循与 digivice 相同的设计模式，但有一些差异/扩展：（i）digidata 的模型 (𝑇.𝑚𝑜𝑑) 包括数据输入 (𝑇.𝑚𝑜𝑑.𝑖𝑛) 和数据输出 (𝑇.𝑚𝑜𝑑.𝑜𝑢𝑡) 属性，（ii）digidata 的驱动程序 (𝑇.𝑑𝑟𝑣()) 包含数据处理代码，执行从输入数据到输出数据的数据转换，具体由数据输入和输出属性指定。它也可以是一个对独立数据处理系统（如 FFmpeg [16] 和 Tensorflow [51]）的轻量级封装。例如，图 1c 中展示了一个“场景” digidata。该 digidata 接收视频流（来自 input.URL），实现对象识别，并更新检测到的对象（输出至 output.Objects）。

We refer to digivice and digidata collectively as digis. Attributes in a digi’s model follow a predefined schema. The model is accessible via verbs, a predefined set of APIs to access attribute-value pairs using their URIs, e.g., get(URI) and update(URI, new_value).

我们将 digivice 和 digidata 统称为 digis。digi 模型中的属性遵循预定义的模式。模型可以通过动词访问，这是一个预定义的 API 集，允许使用其 URI 来访问属性-值对，例如，get(URI) 和 update(URI, new_value)。

这一块不用看文字了，直接上图就行

Composition

Digivices and digidata can be composed to form a “digigraph”. Composition takes place when users call the following composition verbs on digis:

Digivices 和 digidata 可以组合成一个“digigraph”。组合发生在用户对 digis 调用以下组合动词时：

mount: Given a digi 𝐴 and digivice 𝐵, 𝑚𝑜𝑢𝑛𝑡(𝐴, 𝐵) allows 𝐵 to control 𝐴. Note that A might be a digivice or digidata, while B must be a digivice. Specifically, 𝐵 can write to 𝐴.𝑚𝑜𝑑.𝑖 and read from 𝐴.𝑚𝑜𝑑.𝑐, and likewise for digidata. We refer to 𝐵 as the parent digivice and 𝐴 as the child. Mount can be used to implement different semantics:“𝐵 represents 𝐴,” e.g., a universal lamp digivice represents a vendor-specific one; and “𝐵 aggregates 𝐴,” e.g., a room digivice includes other lamp digivices. A digivice can mount multiple children and can also have multiple parents, subject to the mount rule that we describe in §3.3. Mount can also happen at any level (e.g., 𝐴 mounted to 𝐵 and 𝐵 mounted to another digivice 𝐶), forming a hierarchy. Further, each mount has a mode that can take the value “expose” or “hide”. The latter prevents the parent digivice from accessing the child digivice’s children while the former allows it to do so.

mount：给定一个 digi 𝐴 和 digivice 𝐵，mount(𝐴, 𝐵) 允许 𝐵 控制 𝐴。注意，𝐴 可以是 digivice 或 digidata，而 𝐵 必须是 digivice。具体而言，𝐵 可以写入 𝐴.𝑚𝑜𝑑.𝑖 并读取 𝐴.𝑚𝑜𝑑.𝑐，digidata 也类似。我们称 𝐵 为父级 digivice，𝐴 为子级。mount 可以用来实现不同的语义：如“𝐵 代表 𝐴”，例如一个通用灯具 digivice 代表一个厂商特定的灯具；或者“𝐵 聚合 𝐴”，例如一个房间 digivice 包含其他灯具 digivices。一个 digivice 可以挂载多个子级，也可以有多个父级，前提是遵守我们在 §3.3 中描述的挂载规则。挂载还可以发生在任何级别（例如，𝐴 挂载到 𝐵 上，𝐵 挂载到另一个 digivice 𝐶 上），形成一个层次结构。此外，每个挂载有一个模式，可以取“expose”或“hide”值。后者防止父级 digivice 访问子级 digivice 的子级，而前者则允许父级访问。

mount(A, B)

Syntax: allow B to control A.

• A: digivice / digidata
• B: must be digivice

Trait:

1. Multiple hierarchy
2. Access Hieracrchy:
   • When A uses expose mode, B can access A's children.
   • When A uses hide mode, B cannot access A's children.

PS:

• expose模式类似于C++中的protected访问权限，允许特定对象(B)访问内部成员
• hide模式类似于C++中的private访问权限，阻止外部对象(B)访问内部成员

pipe: given two digidata 𝐴 and 𝐵, pipe(𝐴, 𝐵) writes 𝐴’s output to 𝐵’s input; i.e., updates to 𝐴.𝑚𝑜𝑑.𝑜𝑢𝑡 are written to 𝐵.𝑚𝑜𝑑.𝑖𝑛. Note that if 𝐴.𝑚𝑜𝑑.𝑜𝑢𝑡 is a pointer to data (e.g., a URL to a video stream), only the pointer gets written to 𝐵.𝑖𝑛. Each digidata can pipe to multiple digidata; i.e., write its data output attributes to their input attributes. However, at most one digidata can pipe to an input attribute; i.e., we enforce a single writer per port. The URIs to the input and output attributes in 𝐴 and 𝐵 must be specified when calling pipe.

pipe：给定两个 digidata 𝐴 和 𝐵，pipe(𝐴, 𝐵) 将 𝐴 的输出写入 𝐵 的输入；即，𝐴.𝑚𝑜𝑑.𝑜𝑢𝑡 的更新写入到 𝐵.𝑚𝑜𝑑.𝑖𝑛。注意，如果 𝐴.𝑚𝑜𝑑.𝑜𝑢𝑡 是指向数据的指针（例如，指向视频流的 URL），则仅指针被写入 𝐵.𝑖𝑛。每个 digidata 可以向多个 digidata pipe；即，将它的数据输出属性写入它们的输入属性。然而，最多只能有一个 digidata 向输入属性 pipe；即，我们强制每个端口有一个单独的写入者。在调用 pipe 时，必须指定 𝐴 和 𝐵 中输入和输出属性的 URI。

One can use thus the pipe verb to compose digidata to form “data flows”. As mentioned earlier, a digivice can mount a digidata and thus update its data input attributes and read from its data output attributes.

因此，您可以使用 pipe 动词来组合 digidata 形成“数据流”。如前所述，digivice 可以挂载 digidata，从而更新其数据输入属性并读取其数据输出属性。

yield: composition via the mount verb can lead to a multirooted hierarchy. We rely on the yield verb and mount rule (§3.3) to enforce sensible write and mount semantics (§3.3).

yield：通过 mount 动词进行的组合可能会导致多根控制层次结构。我们依赖 yield 动词和挂载规则 (§3.3) 来强制执行合理的写入和挂载语义 (§3.3)。

Specifically, calling the yield verb, e.g., 𝑦 𝑖𝑒𝑙𝑑(𝐴, 𝐵) means that digivice 𝐵’s driver no long has write access over 𝐴. However, the yielded parent digivice may continue to watch for updates to the child’s model and act accordingly. Note that one can use the mount, pipe, and yield verbs to unmount, remove pipe, and unyield respectively by simply setting the corresponding flag at the verb call.

具体来说，调用 yield 动词，例如 yield(𝐴, 𝐵)，意味着 digivice 𝐵 不再对 𝐴 具有写访问权限。然而，被yield的父级 digivice 仍然可以继续监视子级的模型更新并采取相应的行动。注意，您可以通过简单地在动词调用时设置相应的标志，使用 mount、pipe 和 yield 动词来分别卸载、移除 pipe 和解除 yield。

Information about composition is maintained as composition references, where each composition reference tracks the relationship between a pair of digis. Fig.1d includes examples for mount reference/attribute, e.g., mount.unilamp.ul1. Developers define mount references in the digivice’s schema to specify which digivice/data kinds are compatible and hence can be mounted to this digivice. We’ll describe how the composition references are implemented/used at runtime in §5.

关于组合的信息作为组合引用被维护，每个组合引用跟踪一对 digis 之间的关系。图 1d 包括挂载引用/属性的示例，例如 mount.unilamp.ul1。开发者在 digivice 的模式中定义挂载引用，以指定哪些 digivice/数据类型是兼容的，因此可以挂载到该 digivice。我们将在 §5 中描述如何在运行时实现和使用组合引用。

Multi-hierarchy

Digivices can be composed into multi-rooted hierarchies. But not all hierarchies make sense! To see this, consider digivice A, B, U - Z above where A, U - Z form a hierarchy as shown in Fig.2a. We want to mount some of A, U - Z to B (imagine adding digivices in a home hierarchy to a new power controller). Clearly we want to avoid loops since they can lead to erroneous or unpredictable behavior as intents and status are passed around in a cycle. In addition, note that in Fig.2a B can write the intent of both X and Z where Z is already a child of X. This can lead to intent conflicts where Z’s intent can be set by both B and X.

Digivices 可以组合成多根层次结构，但并非所有层次结构都是合理的！为说明这一点，请参考图 2a 中的 digivice A 和 U - Z 所组成的层次结构。假设我们希望将 A、U - Z 中的一些 digivice 挂载到 digivice B（例如，将家庭层次结构中的设备添加到一个新的电力控制器中）。显然，我们需要避免循环结构，因为循环会导致意图和状态在闭环中传递，从而引发错误或不可预测的行为。此外，如图 2a 所示，B 可以设置 X 和 Z 的意图，而 Z 已经是 X 的子 digivice。这可能导致意图冲突，即 Z 的意图同时由 B 和 X 设定。

Our goal is to avoid mount loops and intent conflicts while still allowing a multi-rooted hierarchy in some constrained form. To this end, we require that the digi hierarchy formed by calling mount/yield must be a multitree (more formally, a diamond-free poset [61]) and we meet this requirement by enforcing the following rule when mount is called:

Mount rule: A digivice cannot join a hierarchy that it or any of its descendants is already a part of.

我们的目标是避免挂载循环和意图冲突，同时在一定约束下允许多根层次结构。为此，我们要求通过调用 mount/yield 所形成的 digi 层次结构必须是多树（更正式地说，是无菱形偏序集 [61]）。我们通过以下规则确保这一要求在调用 mount 时得到满足：

挂载规则：一个 digivice 不能加入其自身或其任何后代 digivice 已经属于的层次结构。

An example of a hierarchy that is allowed is shown in Fig.2b. However, the mount rule alone still does not solve the multi-hierarchy problem. As long as a digivice has multiple parents, there can be intent conflicts among the parents. Our solution to this is simple: for each digivice, we allow only a single writer at a time and who gets to be the writer is determined by the yield policy as described next.

图 2b 显示了一个符合要求的层次结构。然而，仅靠挂载规则并不能完全解决多层次结构问题。只要一个 digivice 有多个父级，父级之间就可能发生意图冲突。为解决这一问题，我们采用了简单的策略：对于每个 digivice，在任何时间只允许一个父级具有写权限，具体由 yield 策略决定，如下文所述。

Adaptive Composition

The multi-hierarchy enables shared and delegated control over digivices. In smart space contexts, such sharing often needs to happen dynamically, adapting to real-world events, e.g., when the fire alarm is on, a home digivice should hand over its control to an emergency-control digivice; or when a roomba robot moves between rooms, its digivice might be unmounted from the previous room and mounted to the new one. We often want such adaptive composition to be driven by user-defined policies without a human in the loop.

多层次结构允许对 digivices 进行共享和委派控制。在智能空间场景中，这种共享通常需要动态发生，以适应现实世界中的事件，例如，当火警响起时，家庭 digivice 应将其控制权交给紧急控制 digivice；或者当扫地机器人在房间之间移动时，其 digivice 可能会从先前的房间卸载并挂载到新房间。我们通常希望这种自适应的组合由用户定义的策略驱动，而无需人工干预。

dSpace achieves adaptive composition by allowing users to define composition policies that invoke yield and mount when a specified condition is met. For example, a yield policy may specify the condition under which control over a shared digivice is transferred from one digivice to another. An example yield policy can be found in the Appendix B.3. Mount policies work in a similar fashion allowing digivices to be mounted/unmounted based on predefined conditions.

dSpace 通过允许用户定义组合策略来实现自适应组合，这些策略会在满足特定条件时调用 yield 和 mount。例如，yield 策略可以指定在何种条件下将对共享 digivice 的控制权从一个 digivice 转移到另一个 digivice。Appendix B.3 中提供了一个 yield 策略的示例。Mount 策略以类似的方式运行，使得 digivices 可以根据预定义的条件被挂载或卸载。

Yield allows us to enforce a single-writer policy as follows: when 𝑚𝑜𝑢𝑛𝑡(𝐴, 𝐵) is called, if 𝐴 has no other active parent (where active means the parent hasn’t yielded the child) then the mount call completes and 𝐵 can write to 𝐴. However, if 𝐴 already has an active parent, then the mount is automatically followed by a yield that ensures 𝐵 cannot write to 𝐴.

通过 yield，我们能够强制执行单一写入者策略，具体如下：当调用 𝑚𝑜𝑢𝑛𝑡(𝐴, 𝐵) 时，如果 𝐴 没有其他活动的父 digivice（活动指父 digivice 尚未对子 digivice 调用 yield），则挂载操作完成，且 𝐵 可以对 𝐴 进行写入。然而，如果 𝐴 已经有一个活动的父 digivice，则挂载操作会自动跟随一个 yield 操作，以确保 𝐵 无法对 𝐴 进行写入。

Intent Reconciliation

Intent Reconciliation 意图协调

In dSpace, developers and users “embed” automation logic and policies within a digivice. As described so far, mount and yield policies ensure that at any point in time, a digi’s intent can only be modified by one other digivice; i.e., we’re enforcing single writer semantics on a digi’s intent. However, intent conflicts can still result from events in the physical world. E.g., consider a lamp whose digivice is currently mounted to a room digivice and the room has set the lamp’s intended state to be “on” and now a user physically turns off the lamp. Should the lamp stay on (as dictated by the room) or off (as dictated by the user’s action)? The answer in this case may seem clear - the user’s action should be respected and the lamp turned off. However, the answer might be less clear in a scenario that (say) involves disabling a home alarm or unlocking a door. Such scenarios lead to intent conflicts though, unlike above, they involve a conflict between a digivice’s parent in the digi-graph and the physical world (versus a conflict between a digi’s multiple parents).

在 dSpace 中，开发者和用户可以在 digivice 中“嵌入”自动化逻辑和策略。如前所述，mount 和 yield 策略确保在任意时间点，某个 digi 的意图（intent）只能被另一个 digivice 修改；即，我们对 digi 的意图强制执行了单一写入者语义（single writer semantics）。然而，物理世界中的事件仍然可能导致意图冲突。例如，假设一个灯的 digivice 当前被挂载到一个房间 digivice，而房间 digivice 将灯的目标状态设置为“开”。此时，用户手动将灯关闭。这时，灯应该保持打开状态（由房间的意图决定）还是关闭状态（由用户的操作决定）？在这种情况下，答案似乎很明确 —— 应尊重用户的操作，将灯关闭。但在某些情况下（例如禁用家庭警报或解锁门），答案可能就不那么清晰了。这类场景会导致意图冲突，但与上述情况不同，它涉及 digi-graph 中 digivice 的父 digivice 与物理世界之间的冲突（而非一个 digi 的多个父 digivice 之间的冲突）。

dSpace addresses this by allowing developers or users to define intent reconciliation policies in the digivices. These policies are executed whenever an intent conflict occurs and provides conflict resolution. For instance, when the user physically turns off the lamp, the room may react by resetting the lamp to be “on”, overwriting the user’s intent; or it may adjust its own intent to be compatible with these events. Note that the action taken to resolve an intent conflict is a matter of policy and hence application/user dependent. What dSpace provides is the framework for defining such policies and the runtime guarantees that ensure intent reconciliation is executed correctly.

dSpace 通过允许开发者或用户在 digivice 中定义意图协调（intent reconciliation）策略来解决此类问题。这些策略会在发生意图冲突时执行，以提供冲突解决方法。例如，当用户手动关闭灯时，房间 digivice 可以通过将灯重置为“开”来覆盖用户的意图；或者它可以调整自身的意图以与这些事件兼容。需要注意的是，解决意图冲突的具体措施取决于策略，因此是应用程序或用户定义的。dSpace 提供的是定义这些策略的框架以及确保意图协调正确执行的运行时保障。

For correct execution, dSpace introduces a version number in the digivice model which is incremented when the model is updated. We rely on opportunistic concurrency control based on this version number to achieve serializability on model updates. The dSpace runtime guarantees that if a writer sees updates to a model with two version numbers 𝑉 𝑎 and 𝑉 𝑏 (with 𝑉 𝑎 < 𝑉 𝑏 ), then it must have also seen all updates with version number between the two if any. This ensures that an active parent of 𝐷 will not miss any intent updates on 𝐷. We describe how dSpace’s implementation handles concurrent intent updates in §5.2.

为了正确执行，dSpace 在 digivice 模型中引入了一个版本号（version number），当模型更新时该版本号会递增。我们通过基于版本号的机会并发控制（opportunistic concurrency control）来实现模型更新的可串行化（serializability）。dSpace 运行时保证，如果一个写入者观察到某个模型的两个版本号更新 𝑉𝑎 和 𝑉𝑏（其中 𝑉𝑎 < 𝑉𝑏），那么它还必须观察到介于两者之间的所有版本号的更新（如果存在）。这确保了 𝐷 的活跃父 digivice 不会错过 𝐷 上的任何意图更新。我们将在 §5.2 中描述 dSpace 的实现如何处理并发的意图更新。

Security and Privacy

这段感觉有点在凑字数?...

Security and privacy are important design aspects for IoT systems and dSpace is no exception. There is an extensive literature on IoT security and privacy that, broadly interpreted, falls under two main categories: understanding user awareness and requirements [77, 78, 80] and providing system support [55, 69, 75, 76, 79] for security and privacy.

安全性和隐私性是物联网系统的重要设计方面，dSpace 也不例外。在物联网安全和隐私领域，已有丰富的研究文献，这些研究大致可分为两类：一是研究用户的认知和需求【77, 78, 80】，二是为安全性和隐私性提供系统支持【55, 69, 75, 76, 79】。

With regard to system support, dSpace embraces best practice via the following techniques: (1) Role-based Access Control (RBAC). In dSpace, each digi driver is associated with a role that constrains the driver’s access to its own model. dSpace controllers (§5.2) are associated with roles that are granted the corresponding access for them to enforce composition semantics (e.g., the mounter is assigned write-access to the parent and its children). Users and third-party digis are assigned access by the admin-user following standard practice for managing roles/permissions. (2) Isolation. As we will cover in §5, digis are run in separate application containers which provide OS-level isolation including separate namespaces, network stacks, and performance isolation via cgroups [19]. This helps prevent buggy digis from sabotaging other digis when they are running on the same node. (3) Admission control and general Kubernetes protections. Unlike the common single-node/monolithic architecture in existing IoT frameworks, dSpace builds on top of Kubernetes and allows digis to run in different machines in a distributed fashion. As such, security-critical digis can be run on their dedicated nodes separated from the others. Further, all entities are authenticated with standard tools (e.g., client certificates) when the Kubernetes apiserver receives an API request from them. Each API request undergoes integrity checks by the apiserver to filter malformed requests. dSpace thus provides defense in depth via these layers of system-level protections.

在系统支持方面，dSpace 通过以下技术实践最佳方案：(1) 基于角色的访问控制（RBAC）：在 dSpace 中，每个 digi 驱动程序都与一个角色关联，该角色限制了驱动程序对其自身模型的访问。dSpace 控制器（详见 §5.2）也被分配了角色，这些角色被授予相应的权限，以便它们能够执行合成语义（例如，挂载者被分配了对父 digi 和其子 digi 的写访问权限）。管理员用户按照标准角色/权限管理方法为用户和第三方 digis 分配访问权限。(2) 隔离性：正如我们将在 §5 中讨论的，digis 运行在独立的应用程序容器中，这些容器提供了操作系统级别的隔离，包括独立的命名空间、网络堆栈，以及通过 cgroups【19】实现的性能隔离。这可以防止在同一节点上运行的有缺陷的 digis 干扰其他 digis。(3) 准入控制和通用 Kubernetes 保护：与现有物联网框架中常见的单节点/单体架构不同，dSpace 基于 Kubernetes 构建，允许 digis 分布式运行在不同的机器上。因此，安全性要求较高的 digis 可以运行在专用节点上，与其他 digis 隔离。此外，当 Kubernetes apiserver 接收到实体的 API 请求时，所有实体都需通过标准工具（例如客户端证书）进行身份验证。apiserver 会对每个 API 请求执行完整性检查，以过滤恶意请求。通过这些系统级保护层，dSpace 提供了深度防御。

Next, we discuss the aspects where we believe dSpace’s design can be helpful on the end-user/UX front. Prior studies have reported that the gap between the user’s mental model and the real device setup (e.g., the device topology, how devices interoperate) can introduce security and privacy risks [77, 80]. We speculate that dSpace makes it easier to bridge the gap because (i) the dSpace hierarchy reflects natural organization in the real-world (e.g., lamp mounted to room, then room to home); (ii) dSpace enables adaptation that reflects real-world events (e.g., intent reconciliation given human inputs, dynamic composition); (iii) our use of embedded policies means that policies are co-located with their associated objects and operations rather than exposed to users (or UX designers) as unstructured flat files; and further (iv) composition must be explicit and is a prerequisite to imposing policy - i.e., existence of a policy is not enough (unlike today’s frameworks). As such, dSpace raises a user’s awareness to security and privacy issues, including who has access to what data and devices.

接下来，我们讨论 dSpace 在终端用户/用户体验（UX）方面可能具有帮助的设计点。先前研究表明，用户的心理模型与真实设备设置（例如设备拓扑、设备之间如何交互）之间的差距可能引发安全和隐私风险【77, 80】。我们推测，dSpace 的设计可能有助于缩小这一差距，因为：(i) dSpace 的层次结构反映了现实世界中的自然组织方式（例如，灯挂载到房间，再从房间挂载到家）；(ii) dSpace 支持反映现实世界事件的自适应行为（例如，根据用户输入的意图协调、动态合成）；(iii) dSpace 使用嵌入式策略，意味着策略与其关联的对象和操作共同定位，而不是以无结构的平面文件形式暴露给用户（或 UX 设计师）；(iv) 组合必须显式声明，且是实施策略的前提条件——即，单纯存在策略是不够的（与现有框架不同）。因此，dSpace 提升了用户对安全和隐私问题的认知，包括谁可以访问哪些数据和设备。

Together, we believe these design choices make it easier for developers and users to understand the security of their solutions. However, proving this conclusively requires a UX design and user study which is beyond the scope of this paper. In summary, we believe that security and privacy in smart spaces requires the right combination of system design and UX design. dSpace addresses the systems side but a complete solution including a UX design is a topic for future work.

综合来看，我们认为这些设计选择可以使开发者和用户更容易理解其解决方案的安全性。然而，要得出明确的结论还需要 UX 设计和用户研究，这超出了本文的研究范围。总之，我们认为，智能空间中的安全性和隐私性需要系统设计和 UX 设计的正确结合。dSpace 解决了系统设计问题，但包含 UX 设计的完整解决方案是未来工作的课题。