ABSTRACT
Smart phones comprise a large and rapidly growing market. These devices provide unprecedented opportunities for sensor mining since they include a large variety of sensors, including an: accele-ration sensor (accelerometer), location sensor (GPS), direction sensor (compass), audio sensor (microphone), image sensor (cam-era), proximity sensor, light sensor, and temperature sensor. Com-bined with the ubiquity and portability of these devices, these sensors provide us with an unprecedented view into people’s lives—and an excellent opportunity for data mining. But there are obstacles to sensor mining applications, due to the severe resource limitations (e.g., power, memory, bandwidth) faced by mobile devices. In this paper we discuss these limitations, their impact, and propose a solution based on our WISDM (WIireless Sensor Data Mining) smart phone-based sensor mining architecture.
智能手机是一个巨大且快速增长的市场。这些设备为传感器挖掘提供了前所未有的机会，因为它们包括多种传感器，包括：加速度传感器（加速计）、位置传感器（GPS）、方向传感器（指南针）、音频传感器（麦克风）、图像传感器（cam era）、接近传感器、光传感器和温度传感器。这些传感器结合了这些设备的普遍性和可移植性，为我们提供了一个前所未有的视角，了解人们的生活，为数据挖掘提供了极好的机会。但是，由于移动设备面临着严重的资源限制（如功率、内存、带宽），传感器挖掘应用存在障碍。本文讨论了这些局限性及其影响，提出了一种基于wirelesssensordatamining（wirelesssensordatamining）智能手机的传感器挖掘体系结构的解决方案。
Categories and Subject Descriptors
H.2.8 [Database Applications]: Data Mining
General Terms
Performance, Design, Security, Experimentation, Human Factors
Keywords
Sensor mining, sensors, smart phone, cell phone, data mining, accelerometer, mobile applications.
1. INTRODUCTION
智能手机和其他无线移动设备，包括平板电脑、音乐播放器和便携式游戏系统，构成了一个巨大且快速增长的市场。事实上，自2010年第四季度以来，智能手机的销量已经超过了个人电脑[11]。智能手机为传感器挖掘提供了前所未有的机会，因为它们包括多种传感器，包括：加速度传感器（加速计）、位置传感器（GPS）、方向传感器（指南针）、音频传感器（麦克风）、图像传感器（摄像头）、接近传感器、光传感器和温度传感器。这些设备的普遍性和可移植性，加上它们所承载的许多传感器，为我们提供了一个前所未有的视角，了解人们的生活，以及数据挖掘的巨大机会。
然而，由于对移动设备施加了严重的资源限制，传感器挖掘应用面临许多挑战。本文讨论了基于WISDM（Wireless Sensor Data Mining）智能手机的传感器挖掘体系结构的这些局限性、它们对设计的影响以及提出的解决方案。我们确定的设计考虑因素将对构建基于智能手机的数据挖掘应用程序的其他人有用，也可用于评估未来基于智能手机的传感器挖掘平台。
我们简要介绍了几个具有代表性的基于智能手机的传感器挖掘应用，因为很难独立于任何应用评估设计考虑因素。一类传感器数据挖掘应用主要依靠智能手机的加速来了解用户正在执行的活动（步行、慢跑等）[4、9、12、19]。此类活动识别应用程序可用于确定用户是否获得足够的物理活动，或基于上下文自定义智能手机行为。由于用户的移动形成一个独特的特征，智能手机的加速计也可用于生物识别和认证[6，10]。基于位置的传感器数据挖掘是一个特别受欢迎和不断扩展的应用领域，它已经成熟到足以催生商业应用。例如，Sense Networks[14]提供了几个基于位置的数据挖掘应用程序，包括Citysense™，它可以识别热点，还可以了解每个用户喜欢在哪里花费时间。其他应用包括Google地图和Navigator，它们根据来自大量智能手机用户的实时GPS定位数据来识别流量，然后结合有关历史流量模式的知识。我们的WISDM研究小组[17]已经开发了基于智能手机的活动识别[9]和生物识别[10]应用程序，并正在我们的WISDM体系结构中实现它们，以便它们实时运行。出于第3.1节所述的原因，我们选择使用Android移动操作系统和安卓手机来实现我们的WISDM传感器挖掘架构，但此架构可以适用于使用其他移动操作系统。
移动传感器挖掘体系结构必须满足许多高层设计约束。首先，它必须能够扩展到千个用户，即使不是数百万个用户（例如，Google Navigator）。它还必须实时生成结果，这意味着将任何学习到的模型实时应用于传感器数据（大多数活动接收系统都需要这样做）。该体系结构还必须能够生成接近实时的预测模型并自动部署它们，因为一些传感器挖掘应用程序将需要这样做。该体系结构还应支持不同级别的分布式处理，其中一个极端是电话充当“哑”客户端，服务器负责所有数据处理和挖掘，而另一个极端是在“智能”客户端本地完成所有工作。由于各种原因，包括可伸缩性、应用程序独立性和用户隐私，在可行的情况下，将处理任务推送到移动设备上是有意义的。但有些任务，就其本质而言，可能需要集中处理数据（如道路交通分析）。此外，如果应用程序对于智能手机来说过于计算密集，或者必须收集和保存传感器数据（这是许多学术研究的关键要求），则需要基于服务器的解决方案。到目前为止，我们已经确定了三个影响基于电话的传感器挖掘体系结构设计的高级设计问题：
- Design Issue 1: Mobile devices have severe resource limitations with respect to battery power, computational speed (CPU), memory, and bandwidth which must be accommodated.
- Design Issue 2: The sensor mining architecture must be scalable so that it can accommodate thousands or even millions of users.
- Design Issue 3: Sensor mining applications must often generate results in real-time—and sometimes must also be able to learn (i.e., build predictive models) in real-time.
本文的其余部分安排如下。在第2节中，我们描述了智能手机上可用的传感器以及使用它们时遇到的一些关键问题。我们的WISDM数据挖掘体系结构在第3节中进行了描述。安全性和隐私性是智能手机传感器挖掘的两个非常重要的问题，在第4节中进行了讨论。第5节描述了资源使用问题，然后第6节总结了我们的主要贡献。
2. SENSORS
第2.1节描述了智能手机中包含的传感器。然后，第2.2节描述了更新传感器信息的频率，第2.3节讨论了传感器的使用如何与正常电话功能交互。
2.1 Description of Sensors
在本节中，我们将介绍智能手机传感器，但为最强大和最复杂的传感器提供更多详细信息。一个关键的传感器是加速计，它最初是在智能手机上提供的，用于处理屏幕旋转和支持高级游戏。所有的Android手机和iphone都包括一个三轴加速度计，可以测量所有三个空间维度的加速度。安卓手机中的加速度计因制造商而异，但作为一个例子，流行的HTC Hero使用了博世的BMA150数字加速度传感器[3]，苹果在iPhone和最新iPod中使用了LIS302DL加速度计[15]。重力可由大多数加速度计测量，这些信息可用于确定向下的方向（即到地球的方向）。这些加速度计往往能产生高精度的测量结果。
智能手机还包括用于确定位置的传感器。最准确的信息由GPS接收机提供，它可以在几米之内提供位置信息。这种功能依赖于地球轨道上卫星的三角测量，但通常不在室内运行。当GPS信号不可用时，大多数智能手机依赖于其他精度差得多的三角测量，并使用估计到本地手机塔和WiFi网络的距离来计算位置。然而，在人口稠密、手机和WiFi信号众多的地区，这种“人工GPS”方法仍然是相当精确的。现在，数百万用户通过谷歌导航器（Google Navigator）等服务，经常使用智能手机来绘制地图和路由信息。
音频传感器（即麦克风）可用于监测语音和背景噪声。语音到文本功能为感兴趣（也许是令人不安的）传感器挖掘应用提供了机会，但即使是像声音级别这样的粗略测量也可以提供有关用户环境或活动的线索。例如，一个应用程序使用麦克风帮助确定用户是否在聚会上[12]。图像传感器（即照相机）也可以是有用的，特别是随着照相机质量的提高。这些传感器可以与图像挖掘程序相结合来执行人脸识别和自动识别物体和地点。不幸的是，相机不能用于连续监控，因为当手机不在使用中时，相机通常会被遮挡。
智能手机包含我们称之为二级传感器的功能有限。其中一个传感器是光传感器，它测量环境光的强度。此传感器的主要用途是确定适当的屏幕亮度。它只在智能手机打开时才工作，并限制其用于其他用途。接近传感器确定障碍物与手机的距离，主要目的是确定手机是否压在耳朵上，在这种情况下，关闭屏幕以节省电池电量。一些接近传感器测量距离，而另一些只支持二进制测量（近或远）。此外，一些接近传感器使用红外信号，而其他只是一个“伪传感器”实现使用光传感器。智能手机通常还包括一个测量地球磁场的磁罗盘。虽然这些辅助传感器的功能可能受到限制，但它们仍然可以提供有用的信息以增强传感器挖掘应用。此外，智能手机可以连接到外部传感器（例如，我们正在使用Zephyr HxM蓝牙心率监视器进行实验[20]）。
2.2 Sensor Polling and Sensing Rates
向智能手机应用程序提供传感器值涉及两个阶段。在第一阶段中，传感器硬件基于感测速率Sr将来自传感器的测量存储在共享存储器中。在第二阶段中，应用程序请求传感器测量并将值返回给应用程序。假设应用程序连续监视传感器，则请求值的速率为轮询速率Pr。对于每个传感器，这两个速率可能不同。只有轮询率由程序员控制。重要的是Pr不应比Sr更频繁，以保持有限的资源。
Figure 1. Accelerometer data using different polling rates
图1显示了来自Android手机的实际加速计数据。当以20毫秒的间隔轮询值时，两个值和六个值之间会有明显的重复，方差很可能是由于系统负载引起的。当我们减少Pr时，重复次数减少，直到在50ms时，应用程序可靠地返回每个连续样本的唯一值。这表明，在实际操作中，该手机上的加速计Sr为50ms，因此Pr的设置频率不应高于此值。
- Design Issue 4: The sensing rate Sr may sometimes not provide sufficient granularity for some sensor mining applications, and the application will have to take this into account.
对于我们的活动识别工作，Sr不足以为重复活动（如步行、慢跑和爬楼梯）提供平滑的曲线。重复模式可以通过目视检查来近似，但由于数据稀疏（一个周期内只有3到5个数据点），峰值无法精确确定，因此重复频率也无法确定。
- Design Issue 5: The polling rate Pr should be configurable by application developers and users to match needs of particular applications and conserve limited resources.
我们不应该比所需的更频繁地轮询传感器，因为这将浪费CPU周期，而不足够频繁地轮询传感器将降低应用程序的性能。像GPS这样的传感器需要比加速度计低得多的Pr，由于其数值变化比较缓慢，人们在50毫秒内不会移动太远，但加速度值在50毫秒内会发生很大变化。我们在WISDM体系结构中解决了这一问题，为每个传感器提供不同的默认Pr值，并允许每个传感器通过客户端的用户界面重新配置。
2.3 Interactions with Normal Phone Function
传感器挖掘并不是智能手机的主要功能。其他功能，即打电话和接听电话，具有更高的优先级，因此传感器挖掘应用程序不能过度影响这些其他功能。一个好的传感器挖掘架构必须非常小心地使用共享资源。本主题在第4节中讨论，在本节中，我们将重点讨论其他交互。
在开发客户机数据采集器应用程序时，我们遇到了几个软件问题。之所以会出现这种情况，是因为传感器应用程序并不是手机和安卓操作系统设计和测试中的关键问题。我们发现的一些问题，其他传感器开发人员也遇到过，只发生在特定型号的手机和机器人版本上。具体来说，当我们的数据采集器应用程序运行时，当手机屏幕旋转时，我们的应用程序崩溃。在我们实现了自动重启应用程序的临时解决方案之后，我们发现旋转屏幕会交换加速度计数据的空间轴，这是我们没有预料到的。然后，**我们在应用程序运行时禁用了自动屏幕旋转功能，作为解决方法。**但最终，我们的应用程序必须进行编码，以正确处理屏幕旋转的变化。这说明了理解和测试电话交互的必要性。
- Design Issue 6: Sensor mining development must carefully con-sider interactions with normal phone functioning and incorporate this into the testing process.
第二个问题涉及设备的休眠模式，即在手机处于非活动状态时进入休眠模式，以延长电池寿命。**此模式通常关闭屏幕并更改CPU的操作模式。这会导致“传感器冻结”，因此我们收集的传感器数据包含重复值。**显然，这是一个关键和根本的问题。我们发现这个问题发生在一些Android模型上，而不是其他的Android操作系统版本上。一项互联网搜索显示，许多传感器开发人员正在努力解决这个问题。但甚至没有一个普遍的共识是这是一个错误，因为功能保护电池寿命。**最后，我们通过插入一个“唤醒锁”来解决这个问题，当手机处于休眠模式时，这个“唤醒锁”可以使CPU保持活动状态。**这个演示策略的问题，使用资源限制设备的目的，原本并不认为重要。
- Design Issue 7: Smart phones are designed to conserve resources and this sometimes conflicts with the needs of sensor mining.
3. THE WISDM ARCHITECTURE
数据挖掘通常是离线进行的，但大多数传感器挖掘应用程序都要求对大量用户实时生成结果。例如，我们的ActiTracker活动识别系统被设计成支持成千上万的用户，并通过web界面提供实时结果。类似的实时性和可扩展性限制存在于许多其他传感器挖掘应用中，包括地图导航、流量分析和生物认证。一些应用程序，如导航，甚至需要大量的用户来生成有用的结果，因为交通信息是直接从用户那里推断出来的。最后，应用程序还必须在资源有限的移动设备上运行。在设计WISDM传感器挖掘架构时，这些是我们主要关注的架构。
传感器挖掘过程包括几个步骤。首先，来自手机传感器的原始时间序列数据必须在本地收集和存储。由于传统的预测数据挖掘算法（例如决策树）不直接对时间序列数据进行操作，因此传统方法的下一步涉及将时间序列数据转换为在固定时间段内汇总数据的示例。对于我们当前的活动识别和生物测量应用[9，10]，我们从每10秒的加速度计数据中生成一个包含43个特征的示例。接下来，使用预构建的分类器生成预测（我们的体系结构还支持分类器的动态创建）。最后一步是向用户报告结果，将结果发送到手机和/或通过网络提供。
3.1 Mobile Operating System and Platform
WISDM传感器挖掘架构是为运行Android操作系统的智能手机和移动设备设计的。我们选择Android[2]而不是Apple iOS[8]的原因总结在表1中，其中包括Android使用更流行的编程语言，提供多处理，有免费且有良好文档记录的开发工具，开源，有竞争性的市场份额，便于在市场上发布应用程序，并得到多家硬件供应商的支持，这些供应商应鼓励创新并降低成本。
-
Design Issue 8: The platform’s mobile operating system should be easy to develop for: it should use a common programming lan-guage, have a well documented and inexpensive software devel-opment kit (SDK), and ideally it should be open source.
不过，使用Android也有一些问题。名义上，当我们开始这个项目的时候，Android不是很完美，也不稳定（在3年半的时间里，Android操作系统已经升级了8次）。这导致了复杂的问题，包括为哪个机器人版本开发，因为每个Android版本都提供不同的功能。我们决定将应用程序编程为旧版本（1.5版），以确保与现有Android智能手机的最大兼容性。另外，与苹果iPhone不同的是，Android有几十种型号，它们完成了兼容性测试的过程。事实上，在第2.3节中，我们注意到了一些只在某些版本的Android和某些型号的手机上出现的错误。
3.2 Sensor Mining Process Overview
我们的架构使用一个客户机-服务器模型来执行本节开始时确定的步骤。客户机应用程序提供一个图形界面，用于从用户手机收集传感器数据并从服务器报告结果。服务器是用来接收原始传感器数据、对其进行转换、分类、存储结果，并通过电话和/或web界面将结果报告给用户的。正如我们将要讨论的，应用程序的性质决定了如何（以及是否）在客户机和服务器之间分配这些任务。在我们最简单的“哑客户机”体系结构中，客户机的责任最小，大多数处理和挖掘都发生在服务器上。
图2描述了WISDM系统的“哑客户端”版本。图中的数字表示传感器挖掘过程中的步骤。步骤1涉及在客户端设备上记录传感器数据。一旦客户机收集了数据，它就联系我们的服务器（步骤2a），然后在步骤2b中，服务器上的侦听器将连接传递给处理程序线程，然后处理程序线程与客户机通信（步骤2c），以验证用户并接受其数据。该数据被聚合并成批提交给数据库（步骤2d）。随着更多的功能被推送到客户端，步骤2将需要在稍后的时间执行，或者可能根本不执行（参见第3.3节）。
控件随后传递给服务器。在步骤3中，数据被转换为从时间序列传感器数据创建示例（可能并不总是需要此步骤）。在步骤3a中，由排序线程周期性地从数据库中检索新到达的数据，该排序线程对数据进行组织，以便将来自同一传感器和手机的记录（即在Pr处记录的传感器值的快照）一起处理。相关的数据存储在队列中，直到触发步骤3b，步骤3b有一个分组线程将排序后的时间序列记录绑定到示例中。在我们的例子中，一个检查代表10秒的数据，记录在Pr=50毫秒，因此每个例子包含200个传感器读数。加速计在轮询时返回3个值（vis。x、 所以这200个读数包含600个值。在步骤3c中，特征基因发生器线程将它们转换为一个检查实例。这些示例被保存到两个单独的队列中，以便可以存储它们并继续进行处理。在步骤5a中，从这些队列中的一个队列中提取示例，为了提高效率而将其分组并保存到数据库中。这确保我们有一份工作中间阶段的记录。这些转换后的例子也可以形成一个数据集，并与其他研究人员共享。步骤4有一个线程从另一个队列中获取示例，并通过预先构建的分类器运行它们。在步骤5b中，将结果保存到最终队列中，然后聚合成批并保存到数据库中。将分类结果存储在数据库中，之后可以通过我们的web界面查询这些结果，以便向用户进行可视化和演示。
刚才描述的场景没有涵盖分类器的动态构造。我们认为，传感器挖掘应用需要为某些应用（如活动识别）建立个人模型，以获得高精度的结果。因此，这种能力是必要的，是我们的WISDM体系结构的一部分。但这也需要智能手机应用程序来促进自我培训。我们的WISDM平台将通过引导用户通过收集标记的训练活动数据的过程来促进活动识别的自我训练阶段。
- Design Issue 9: Some sensor mining applications may require self-training to generate personalized models and the sensor min-ing architecture should support this ability.
3.3 Client/Server Architectures
客户机和服务器的责任可以通过多种方式进行分配。这两个极端是“哑客户端”体系结构，其中在客户端上完成的工作最少，以及“智能客户端”体系结构，其中客户端完成所有工作，不需要服务器。在这些极端之间有几个可行的中间日志架构。表2总结了合理的备选方案。
目前，称为数据收集器的WISDM客户机应用程序实现了哑客户机的职责，尽管将来它将能够配置为支持表2中所示的任何工作负载。数据采集器有一个非常简单的用户界面，用于管理数据采集和数据上传过程。主屏幕上有用户名和密码字段，以及“开始录制”、“发送数据”和“退出”按钮，外加一个下拉式数据标签选择器，这样人们就可以为他们为受监督的学习应用程序（如活动记录、他们正在进行的体力活动）收集的数据贴上标签。当点击“开始”时，它们会被带到一个新的屏幕上，显示传感器的轮询率，并通知用户它正在记录。此屏幕有一个“停止收集”按钮，用于停止收集并将用户返回主屏幕。传感器轮询率和服务器连接设置可以在正常的Android应用程序设置屏幕中进行修改。很快，我们的应用程序将支持自动（定期）上传数据。
在未来，我们将把额外的服务器功能迁移到手机上，以减少中央服务器上的工作负载。我们计划为我们的生产应用程序ActiTracker[2]这样做，以使其具有可伸缩性。将功能移动到客户端应用程序的第一步是将时间序列传感器数据转换为电话上的单个示例（客户端类型2）。这个过程很容易实现，而且只是适度的计算意图。这也意味着传输到服务器的数据更少，从而节省了通信带宽。
下一步是使用预先构建的模型（客户机类型3）在电话上执行分类过程。在大多数情况下，实现这一点非常简单。此外，根据模型的类型，所需的计算量可以是低（例如，决策树）或高（最近邻）。这种体系结构是相当可扩展的，手机执行大多数常规处理，服务器主要负责存储和报告结果。在许多方面，这可能是最优的，因为客户端仍然相对简单，服务器从大多数工作中卸载，客户端不需要存储大量结果。这是我们的ActiTracker应用程序的目标体系结构，因为我们希望允许用户通过互联网查看他们在很长一段时间内的活动历史。
模型生成可能是最复杂的处理步骤，因此通常在服务器上执行。由于模型生成很少发生，这可能不会过度影响体系结构的可伸缩性。但在某些情况下，在应用程序上生成模型是可取的，这会导致客户机类型4。在手机上实现模型生成可能比人们想象的要容易得多，因为我们的WISDM平台使用WEKA数据挖掘套件[18]，它是用Java编写的，Java代码可以在Android下运行。而且，今天的智能手机确实有处理能力运行这样的工具。甚至计算密集型任务，如声音样本的离散傅立叶变换，也被证明在老式智能手机上是可能的[12]。但是，由于模型生成仍然是最复杂的步骤，因此它仍然经常保存在服务器上。在这种情况下，我们仍然可以将更多的功能转移到客户端，方法是将所有的结果和报告工具都保留在电话上（客户端类型5）。但是，在这种情况下，由于我们不将传感器数据传输到服务器，因此只能使用预先构建的模型，这意味着不能使用个性化模型。但这对于许多应用来说都是很好的。最后，在“智能客户端”极端（客户端类型6）中，所有功能都在移动设备上。
- Design Issue 10: Smarter clients trade off application scalability with limited resources.
3.4 A Central Database
我们的数据存储在一个MySQL数据库中，其中有原始、中间和最终数据的表。这允许我们返回并修改我们的方法，添加新任务，或者可视化如果只保留结果分类将丢失的数据。这些都是学术研究的标准能力，但在许多消费者应用中可能并不重要。然而，在关系数据库中存储大量记录存在一些实际问题。
-
Design Issue 11: Storing large numbers of records in a database can make finding specific or related records difficult.
**为了达到我们的目的，我们需要将连续数据分块处理，以便将单个读数转换为10秒的活动示例。**这也意味着我们需要防止来自多个用户的数据混合。因为所有记录共享同一表单，所以将它们存储在一个表中是很有诱惑力的。如果这样做了，来自不同用户、时间和活动的数据将被混合，并且在评估之前必须将数据重新排序到同源组中。即使使用哈希表和索引，这些表也将很难管理，并且提取所需的和相关的记录将是CPU密集型的。通过基于相关信息将数据划分到单独的表中，可以消除这种混合，并减小表的大小。增加组织增加了可访问性，但更严格的组织也会引入应用程序开销，以便对数据库之外的新记录进行排序。 -
Design Issue 12: Relational databases are I/O chokepoints which can impede real time functionality.
在“dumb client”架构中，即使是单个用户每天也会生成数百万条记录（例如，50毫秒的轮询率），这将导致大多数查询需要很长时间才能运行。由于MySQL等关系数据库系统的开销，即使将我们的研究数据集插入到数据库中，在一台加密的机器上也要花费数小时。此开销包括插入时间、索引更新、权限检查和锁定[5]。如果在serting新数据和查询它需要比处理它更长的时间，那么应用程序将浪费时间等待数据库。这就意味着响应性较差的“实时”应用程序，在连续接受大量数据的情况下，这可能意味着服务器严重积压，永远赶不上。因此，限制查询和应用程序对数据库的依赖性是很重要的。在可能的情况下，应用程序应在内存中存储和处理所有传感器数据，并仅将数据库用于长期存储。如果必须保存原始传感器读数，则应独立于其处理来保存它们。
3.5 Concurrency
从移动设备中挖掘传感器数据所产生的海量数据使得并发处理非常有吸引力。如前所述，数据挖掘任务通常是按顺序完成的，这对于实时应用来说是不充分的。当然，传感器挖掘是由独立的步骤和具体的记录组成的，这些步骤和记录有利于并行处理。对于我们的工作来说，并发有两种重要的类型：一种是一次在多个数据上形成相同的任务（即并行），另一种是同时在一个过程（即在不同的数据上）执行多个步骤（即流水线）。
- Design Issue 13: Parallelism requires careful separation of data so that no data’s processing depends on the state or content of other data.
第3.2节中的许多步骤可以并行执行。在我们的服务器中，每个步骤都由持久线程组成，以避免启动后的线程创建开销。对于可以对多个并行数据执行的所有步骤（即。客户端连接、记录分组、特征生成、分类），我们使用线程池来管理线程数量和平衡工作负载。
- Design Issue 14: Pipelining requires careful separation and se-quencing of tasks to avoid dependencies that can cause unneces-sary stalls.
如果数据必须在阶段之间来回移动，或者来自一个阶段的数据与来自另一个阶段的数据相关联，那么某些阶段可能最终会等待其他阶段。每个阶段都必须能够少考虑其他阶段，以确保应用程序不会暂停。首先，这要求每个任务都有单独的线程，以便这些步骤可以独立进行。这还意味着为每个任务使用单独的线程池，这样某些步骤的线程就不会排在其他步骤的线程后面执行不相关的工作。其次，两个步骤之间需要缓冲区，因为它们需要花费不同的时间来完成。我们使用步骤之间的队列来解决这个计时问题。当一个步骤完成时，它将其结果放入一个队列，并从另一个队列获取下一个作业。如果输入队列为空或正在使用中，则线程将等待，直到有工作。因此，资源可以保持忙碌。
为了避免等待I/O操作，将要保存的数据传递到另一个队列，以便处理线程可以继续执行。专用的I/O线程从每个队列获取数据并将其组合成批处理查询，然后大量执行这些查询以减少数据库开销。每个I/O线程都有自己的到数据库的持久连接，以减少连接开销。
3.6 Language and Operating System
3.7 Web Interface and Data Representation
3.8 Algorithm Efficiency
数据挖掘模块是任何传感器挖掘体系结构中的关键组件。关键问题包括：应该使用什么数据挖掘算法，如何和何时建立预测模型，培训过程需要多长时间，以及使用现有模型对新数据进行分类需要多长时间。由于移动设备上的资源限制，在解决这些问题时，效率考虑是至关重要的。
没有最佳的数据挖掘算法可供使用，但对于实时应用，有些算法比其他算法更适合。特别是，基于实例的（最近邻）学习算法特别合适，因为它们根本不需要任何训练时间。因此，它们对应用程序很好，比如activity recognition，其中个性化模型的性能最好。**将新的数据应用到所学习的模型并快速生成结果也是至关重要的。**但大多数算法生成的模型可以快速生成结果。虽然基于实例的学习方法实际上可能需要一些时间来生成结果，但这些方法可以通过直接实现来加快速度，而不依赖于任何学习程序，并通过利用现代处理器架构支持的矩阵运算来加快速度[6]。
4. SECURITY AND PRIVACY
4.1 Communication
4.2 Storage
4.3 Application Level User Control
5. RESOURCE USAGE
5.1 Battery
5.2 CPU and RAM
智能手机的计算能力和RAM也受到限制。由于传感器挖掘应用程序可能会持续运行，因此我们需要更加关注它们的累积CPU和RAM使用情况，以便不影响正常的设备操作。
- Design issue 26: The operation of sensor mining applications should not impact normal functioning of smart phones; consump-tion of CPU and RAM should not exceed 20%, on average.
CPU使用测试是在“哑”数据收集器客户端应用程序上执行的。这些测试是在一款HTC EVO 4G上进行的，它采用了SD8650芯片组和1GHz Snapdragon Scor-pion处理器。在记录时，WISDM数据采集器的服务将大约3.4%的正常运行时间用作活动进程，这相当于CPU总潜力的大约2%。相比之下，Android 2.2内核占据了CPU容量的3.6%。
在Android手机上，除非屏幕处于活动状态，否则服务不会占据CPU的前台，从而降低CPU的优先级。实际上，这会转化为一个较慢的Pr值，因为应用程序没有执行命令的优先级。对于Pr值为50 ms的应用程序，我们发现只能每100到200 ms成功轮询一次新值。此问题可能不会对不需要如此高频率Pr的传感器挖掘应用程序产生重大影响。数据采集器的未来工作包括实现独立运行的远程服务申请的。当应用程序离开前台时，这将防止收集服务的CPU优先级降低。如果是这种情况，那么任何持续轮询传感器的应用程序都需要使用这种或类似的技术。
WISDM数据采集器采用18MB的RAM，其中12MB为数据预留，6MB为共享。全内存使用率约为HTC EVO 512 MB内存总量的3.5%。应用程序的内存使用相对较小，不太可能与其他应用程序发生冲突或干扰正常操作。
5.3 Data Storage
传感器挖掘有可能产生大量的数据集。应用程序可以拥有数千甚至数百万用户。更重要的是，移动传感器可能会不断报告新数据，这意味着即使每个用户的数据也会快速增长。像ActiTracker这样的应用程序，尽可能频繁地轮询加速计，每小时将产生72000条记录。
-
Design Issue 27: Compression and efficient encoding are critical to manage the storage needs of sensor mining applications.
通过一个案例研究来演示数据存储需求是最容易的。使用ActiTracker，同一原始加速度计数据的数据存储要求根据数据的格式有很大的不同。例如，每个记录都有一个用户ID和活动标签，这两个标签对许多其他记录都是重复的。此外，每条记录的时间戳几乎与上一条和下一条记录的时间戳相同。这为数据压缩节省了空间。编码也会产生显著的不同。我们使用ASCII编码生成可读文件，将单精度浮点值（单字节）转换为多个单独的字符（每个字符由一个字节表示）。一个纯二进制的平面文件可以将数据压缩到我们的平均ASCII文本文件大小的15.7%。
6. CONCLUSIONS
在未来十年中，使用智能手机的传感器挖掘应用将变得普遍。本文描述了在资源受限的设备上运行时，传感器挖掘体系结构和传感器挖掘应用必须处理的关键问题，以便为用户提供好处。这些问题对于开发和评估传感器挖掘架构和平台至关重要。此外，我们描述了我们的WISDM传感器挖掘架构。通过这样做，我们以具体的方式演示了如何解决这些设计问题。我们还展示了一个灵活的体系结构如何支持客户机和服务器之间不同级别的责任。还强调了有关资源使用、安全和隐私的问题。
WISDM平台是部分实现的，大多数基本功能都在运行和测试。我们预计，我们的第一个产品应用程序ActiTracker[1]将于2011年9月1日左右发布。这将使研究人员和日常用户能够跟踪他们的活动时间，看看他们是否得到足够的体力活动。它还将提供关于我们的WISDM传感器挖掘架构的有效性的具体反馈。