业余骑行者低端设备上的个性化实时监测和性能评估

18330业余骑行者在低端设备上的个性化实时监测0概念验证和性能评估0Mathias De Brouwer IDLab - imec- 根特大学mrdbrouw.DeBrouwer@UGent.be0Femke Ongenae IDLab - imec -根特大学Femke.Ongenae@UGent.be0Glenn Daneels IDLab - imec -安特卫普大学Glenn.Daneels@UAntwerpen.be0Esteban Municio IDLab - imec -安特卫普大学Esteban.Municio@UAntwerpen.be0Jeroen Famaey IDLab - imec -安特卫普大学Jeroen.Famaey@UAntwerpen.be0Steven Latré IDLab - imec -安特卫普大学Steven.Latre@UAntwerpen.be0Filip De Turck IDLab - imec -根特大学Filip.DeTurck@UGent.be0摘要0实现对骑行者传感器数据的实时收集和分析可以使业余骑行者能够持续监测自己的表现，并获得个性化的反馈，并在骑行活动期间与其他人进行交流。语义Web技术可以通过智能整合所有可用的上下文和传感器数据。流推理技术通过将整合的数据相关联来执行高级处理任务，以实现个性化和上下文感知的实时反馈。本文利用和评估了这些技术，设计了一个针对业余骑行者的个性化实时反馈平台的概念验证应用程序。通过Web应用程序提供有关用户心率和心率训练区间的实时反馈。在树莓派上评估了平台的性能和可扩展性。这显示了该框架在小型业余骑行团体中使用低端设备进行实际骑行的潜力，这些团体在活动和训练期间只能使用低端设备。0CCS概念0• 信息系统 → 数据分析；数据流；• 计算理论 → 语义和推理；0关键词0流推理；实时反馈；骑行0ACM参考格式：Mathias De Brouwer，Femke Ongenae，GlennDaneels，Esteban Municio，Jeroen Famaey，Steven Latré和Filip DeTurck。2018年。业余骑行者在低端设备上的个性化实时监测：概念验证和性能评估。在WWW '18Companion：2018年Web会议伴侣，2018年4月23日至27日，法国里昂。ACM，纽约，纽约，美国，8页。https://doi.org/10.1145/3184558.31916480本文以知识共享署名4.0国际（CC BY4.0）许可证发布。作者保留在其个人和公司网站上传播作品的权利，并附上适当的归属。WWW '18 Companion，2018年4月23日至27日，法国里昂，© 2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可证发布。ACM ISBN978-1-4503-5640-4/18/04。https://doi.org/10.1145/3184558.319164801 引言0近年来，对于体育运动中使用数据进行战略决策的重要性显著增加[18]。这种监测在自行车运动中尤为重要[5,20]。许多骑行者都使用一系列传感器来测量心率、功率、位置、速度、海拔和踏频等方面。然而，现有的自行车训练应用程序（如Strava1）几乎都是离线进行数据报告和分析的后处理步骤。因此，实时的数据收集和分析可以为自行车界带来重要的创新，尤其是对于业余骑行者来说，他们通常没有与职业自行车队一样的资源。实现这一点可以使他们能够持续监测自己的表现，并在业余自行车比赛（如弗兰德斯环比赛）期间与他人进行个性化反馈和交流。为了使反馈对每个骑行者更有价值，它应该是个性化的。许多不同的参数定义了骑行者的生理特征。例如，静息心率和最大心率定义了训练区间的边界，这意味着对于具有相同心率的不同骑行者可能适用其他反馈。为了能够立即对接收到的反馈做出反应，其实时性很重要。根据参数的不同，实时要求也会有所不同。例如，功率比心率更容易波动，这意味着只有在每秒至少更新一次时，功率反馈才能被认为是实时的，而对于心率来说，这可以高达5秒。为了实现实时数据的收集和分析，研究了两个重要的技术创新。首先，自行车比赛经常在没有任何蜂窝连接的偏远地区举行。这对于数据收集是一个挑战。因此，本文描述了一种适用于具有挑战性环境的新型物联网平台[8]。它作为一个移动网络层，将自行车作为节点，允许从骑行者到骑行者发送实时传感器信息，而无需任何互联网连接。其次，研究了一种数据分析层，允许智能地01 https://www.strava.com0Track: 个性化的业余自行车手实时监测在低端设备上的实证和性能评估 WWW 2018年4月23日至27日，法国里昂18340在体育赛事之前和期间提供实时反馈，更具体地说是在业余自行车赛事中。为了使这种反馈个性化和上下文感知，系统应该能够考虑上下文信息，如骑手个人资料、路线信息、天气等。鉴于所有可用的上下文信息和不同传感器的观测结果，需要进行智能的数据整合和分析。由于这些数据通常是异构的，语义是解决这个问题的理想方法[4]。本体可以用来建模数据及其关系和属性。然后，流推理技术允许执行高级处理任务，通过将连续数据流映射到本体中建模的可用背景知识上，设计个性化和上下文感知的实时反馈[9]。例如，传感器的心率观测可以与相应的骑手关联起来，从而可以检索到他的个人资料信息，并根据该人的边界确定他当前的心率训练区域和相关的反馈。语义的一个附加优势是使用通用查询，允许将上下文数据（例如新的传感器类型）和查询添加到运行中的系统中，而无需进行适应。在imecICON项目CONAMO（连续运动员监测）2中，实现了一个概念验证（PoC）应用程序，展示了使用上述两种技术进步实现自行车手实时反馈平台的可能性。为了使业余自行车手能够接受，实时反馈系统应该能够在低端设备上运行，例如他们骑车使用的GPS设备或智能手机。因此，对设计的平台的性能和可扩展性进行了树莓派上的评估。本文的大纲如下。第2节介绍了流推理、体育中的语义和物联网数据收集领域的相关工作。第3节详细介绍了概念验证用例，而第4节介绍了其架构设置。第5节描述了用于实时数据收集的物联网平台，而第6节讨论了实时反馈平台本身。在第7节和第8节中，对树莓派上的反馈系统性能进行了评估。最后，第9节和第10节讨论并总结了主要发现。02 相关工作 2.1 流推理0数据流管理系统（DSMS）和复杂事件处理（CEP）可以查询根据固定数据模型结构化的同质流数据[17]。与语义Web推理器相反，DSMS和CEP无法处理异构数据源，并且缺乏对领域知识集成的支持。为了弥补这一差距，流推理侧重于可扩展和高效地采用语义Web技术处理流数据[9]。在过去的几年中，已经开发了几个RDF流处理（RSP）引擎[23]，其中C-SPARQL [3]和CQELS[16]是最著名的。它们在流的顶部定义了一个窗口，并允许注册语义查询，这些查询在数据通过窗口时持续评估。这些RSP引擎可以过滤和查询连续的数据流，为注册的查询提供实时答案，并支持将领域知识集成到查询过程中[9]。C-SPARQL支持RDFS推理，而CQELS不包括任何推理支持。已经对从低端设备发布RDF流进行了一些初步研究[22]。02 https://www.imec-int.com/nl/imec-icon/research-portfolio/conamo0支持领域知识集成到查询过程中[9]。C-SPARQL支持RDFS推理，而CQELS不包括任何推理支持。已经对从低端设备发布RDF流进行了一些初步研究[22]。02.2 体育中的语义技术0关于采用语义技术进行体育运动的研究已经进行了一些初步的研究。其中最先进的是在LifewearITEA项目的背景下进行的研究[1,21]。在这项研究中，设计了一个无线传感器网络，用于模拟在体育馆内进行举重运动的运动员。采用语义推理来提供关于他们当前训练方案的遵守情况的反馈，并在他们将体育锻炼推向危险水平时生成警报。其他努力仅限于体育信息的语义注释和检索[6,26]。02.3用于具有挑战性环境的物联网平台0传统的物联网平台基于高度依赖于密集基础设施的无线技术，因此不适用于人口稀少、偏远和具有挑战性的地区[12,14,15]。为了将物联网应用扩展到这些环境中，提出了一些解决方案[2,7,19]，使用传统移动网络（如GPRS、LTE）、NB-IoT[11]、LoRa或SIGFOX将物联网设备与高速回程网络相互连接。这些基于基础设施的方法的缺点是部署和维护基站的成本高昂，并且物联网设备只能在有基站的情况下工作。另一方面，基于无基础设施的方法[8,10,25]可以在本地工作，无需连接到互联网。它们基于低功耗多跳无线传感器网络（WSN）技术，如DASH7、Zigbee和6TiSCH。03使用案例场景0目标是向业余自行车手提供关于他们当前心率和心率训练区域的实时个性化反馈。这有助于骑手进行最高效的训练，而不是过度或不足的训练。个性化的方法非常重要：所有反馈都应根据骑手的个人资料进行调整。对于自行车手，可以区分出七个心率训练区域3：（1）恢复，（2）长时间慢速距离（LSD），（3）广泛耐力，（4）节奏耐力，（5）分段训练，（6）广泛间隔，（7）无氧。对于每个人来说，这些训练区域之间的界限可能不同。为了能够个性化反馈，因此确定这些界限是很重要的，这是基于一些个人资料信息的。根据一个人的静息心率和最大心率，可以通过应用卡沃宁公式[13]来确定不同训练区域的上限：0U B tz = 强度 tz × ( HR max  −  HR rest  )  +  HR rest (1)0不同训练区域的强度值分别为0.60、0.64、0.70、0.78、0.84、0.89和1.00。要确定一个人的静息心率和最大心率，理想情况下应该执行以下操作：03由CONAMO项目的合作伙伴Energy Lab提供。0Track: Personalized Real-Time Monitoring of Amateur Cyclists on Low-End Devices: Proof-of-Concept & Performance EvaluationWWW 2018, April 23-27, 2018, Lyon, FranceWi-FiBLEANT+6TiSCH6TiSCHANT+HDMI18350专业实验室测试对业余自行车手来说并不总是可行或现实的。因此，存在经验规则，允许从配置参数确定现实的默认值：0•静息心率：这个心率取决于个人的运动水平。对于低水平的运动性，这个值大约是65。同样，对于中等水平，这个值是55，对于高水平，这个值是50。•最大心率：这个值通常随着年龄的增长而减少，可以估计为220−  aдe。0通过使用这些专业规则和卡沃宁公式，可以仅通过请求个人的年龄和运动水平来确定骑手的心率训练区间边界。如果一个人知道自己的最大心率和/或静息心率，当然可以使用这些值代替估计值。04 架构设置0图1展示了具有两名骑行者的PoC设置4。它由两部分组成：用于具有挑战性环境的物联网平台（见第5节）和实时反馈系统（见第6节）。为了个性化目的，在开始PoC之前，开发了一个移动Android应用程序，要求骑行者填写一些个人资料。每辆自行车都连接到一个运行此应用程序的Android智能手机。出于第3节中解释的原因，要求填写出生日期、运动水平以及如果已知的话，静息心率和最大心率。要求姓名和性别是为了允许唯一标识和以后与性别特定的基准进行比较。所有个人资料信息都存储为反馈系统中的上下文数据，以避免每次都需要输入。应用程序问题的截图如图2所示。每个骑行者都佩戴一个心率传感器，每秒测量一次心率。这些观测结果通过不同的阶段和技术发送到后端的实时反馈系统，其中部署了一个流推理框架。实时反馈显示在用户的屏幕上，例如可以在自行车上的GPS设备或智能手机上或安装在汽车上，使用本地运行的Web应用程序。反馈系统安装在Raspberry Pi 3 ModelB上。选择这个低端设备是因为它充当一个简单的Linux计算机，可以轻松地将任何在笔记本电脑上运行的系统进行传输。这在Android平板电脑上是不可能的。图3显示了一个骑行者实时反馈系统的Web应用程序的截图。反馈提供有关心率、相应的训练区域以及骑行持续时间内相对训练区域分布的信息。当骑行者停止骑行时，可以停止实时反馈，显示有关所有训练区域的最终训练区域分布的反馈。根据与人的有氧和无氧阈值相关的当前努力强度，提供视觉上的彩色反馈（绿色、橙色或红色）。05 具有挑战性环境的物联网平台0为了支持传感器数据的实时收集，提出了一种物联网平台，可以可靠地在各种动态环境中传播数据04 值得注意的是，该系统可以与任意数量的骑行者一起使用。0用于具有挑战性环境的物联网平台0实时反馈系统0图1: PoC设置0图2:Android应用程序的截图，请求骑行者的个人资料信息，用于反馈个性化0图3: 实时反馈系统的Web应用程序截图，仅显示一个骑行者0和具有挑战性的环境[8]。该平台显示在图1的左侧。它是一种混合解决方案，将基础设施型和无基础设施型低功耗物联网连接性的优势结合在一个多模式平台中。它使用各种低功耗无线个人区域网络（LoWPAN）技术（例如BLE和ANT+）连接到不同的传感器，监测实体（即骑行者），同时还采用了一种自组织、长距离和多跳无线传感网络，以实时可靠地传播监测数据到网络汇聚点。与现有技术解决方案相比，所提出的多模式平台为具有挑战性的环境提供了一种高度灵活的物联网解决方案，具有无基础设施的数据传播、间歇性中断等特点。0Track: 个性化实时监测业余骑行者在低端设备上的表现: 概念验证和性能评估 WWW 2018, 2018年4月23日-27日, 法国里昂{"@context": {"xsd": "http://www.w3.org/2001/XMLSchema#","schema": "http://schema.org/","sosa": "http://www.w3.org/ns/sosa/","madeBySensor": { "@id": "sosa:madeBySensor", "@type": "@id" },"resultTime": { "@id": "sosa:resultTime", "@type": "xsd:dateTime" },"hasResult": { "@id": "sosa:hasResult" },"value": { "@id": "schema:value", "@type": "xsd:float" },"unitText": { "@id": "schema:unitText", "@type": "xsd:string" }},"@id": "http://idlab.ugent.be/conamo/sensors/Observation_HeartRateSensor_1593_2017_09_16_21_33_25_850Z","@type": "http://www.w3.org/ns/sosa/HeartRateObservation","madeBySensor": "http://idlab.ugent.be/conamo/sensors#HeartRateSensor_1593","resultTime": "2017-09-16T21:33:25.850Z","hasResult": {"@id": "http://idlab.ugent.be/conamo/sensors/ObservationValueSensor_HeartRateSensor_1593_2017_09_16_21_33_25_850Z","@type": "http://idlab.ugent.be/conamo-vocab/sosa#HeartRateObservationValue","value": "137", "unitText": "bmp"}}18360图4: 自行车本体结构的核心结构50具有容忍性的互联网上行链路，并支持异构无线传感器和执行器。为了让人们理解整个PoC，本节提供了设备功能和平台数据传播过程的简要描述。更多细节可以在Daneels等人的文章[8]中找到。05.1 设备功能0平台节点将从骑手使用的传感器收集数据，例如图1中所示的骑手心率监测器。捕获的数据定期转发到网络中以达到网络汇聚点，然后可以进行分析。作为多跳网络的一部分，每个平台节点还负责接收来自其他节点的传入数据，并将这些数据向上中继到汇聚点。平台汇聚点作为来自平台节点的监测传感器数据的收集器。汇聚点本身不连接任何传感器设备，而是使用BLE与其他外围设备连接以分析和/或可视化传入数据。如图1所示，它将监测数据发送到连接到提议的实时反馈系统的平板电脑上。05.2 数据传播0物联网平台支持从传感器到汇聚点的实时数据的端到端传播，以及在相反方向上的传播，覆盖范围可达数公里。它不使用外部基础设施（例如4G或LPWAN），而是使用IEEE 802.15.4g物理层与IEEE802.15.4e MAC层相结合的多跳通信网络。IEEE802.15.4g修正案最近被添加到IEEE802.15.4标准中，支持无基础设施模式，并针对低功耗、远距离通信使用868MHz频段进行了优化。在这个低于1GHz的频段上进行通信，可以在两个节点之间建立数百米的连接。IEEE802.15.4g物理层与6TiSCH架构相结合，将工业性能（可靠性和功耗）与完整的IPv6启用的物联网上层堆栈相结合[24]。6TiSCH堆栈的关键组件是IEEE 802.15.4eMAC层的TSCH模式，它通过信道跳频来避免外部干扰和多径衰落，并采用基于TDMA的发送/接收时间表。这样可以实现极其可靠和节能的多跳物联网网络，可以在数公里的距离上实时传播数据。在图1所示的PoC设置中，节点与汇聚点之间有直接的6TiSCH连接。0清单1：以JSON-LD描述的心率传感器观测示例06 实时反馈系统0反馈系统的主要部分是在低端设备上运行的流推理框架。为了向用户提供可视化反馈，应该实现一个前端应用程序，例如图3中显示的本地运行的Web应用程序。这样的应用程序可以在低端设备本身上查看，也可以在连接到同一网络的任何其他设备上查看。06.1 本体论0开发了一个骑行本体论[6]，它基于SOSA本体论[7]（传感器、观测、样本和执行器）。本体论的核心结构如图4所示。本体论允许定义骑手、训练区域和骑手的生理特征，包括训练区域的边界。每个训练区域都带有包含领域专家编制的反馈的注释。此外，可以定义传感器观测。支持位置和数量观测值。后者包括所有相关的数量观测值，带有值和单位，例如骑手的心率、海拔、功率和速度。这个通用定义使得可以定义相应的通用可重用查询，如第6.3节所述。本体论用于构建RSP引擎使用的知识库。因此，查询和数据（即静态上下文数据和输入流数据）都需要在这个本体论中进行建模。清单1显示了一个心率传感器观测的示例，它在流中发布，以JSON-LD描述。06.2 使用C-SPARQL0系统中使用的RSP引擎是C-SPARQL，因为它支持静态上下文数据，而CQELS不支持。在C-SPARQL中，当相应的窗口被触发时，即在滑动之后，将执行注册的连续查询。为了能够使用RESTful接口，使用了C-SPARQL的RSP服务接口8。启动时，启动WebSocket服务器05 使用Protégé本体编辑器创建（https://protege.stanford.edu）。6公开可用于https://github.com/IBCNServices/cyclists-monitoring。7http://www.w3.org/ns/sosa 8https://github.com/streamreasoning/rsp-services-csparql0Track：业余自行车手个性化实时监测在低端设备上：概念验证和性能评估WWW 2018年4月23日至27日，法国里昂REGISTER STREAM getQuantityObservationValue ASPREFIX f: PREFIX schema: PREFIX sosa: PREFIX conamo-profile: PREFIX conamo-sosa: SELECT?deviceUUID ?firstName ?lastName ?gender ?birthDate ?sensor ?o ?time ?unit ?valueFROM STREAM [RANGE 10s STEP 1s]FROM FROM WHERE {?o sosa:hasResult ?ov . ?o sosa:resultTime ?time . ?sensor sosa:isHostedBy ?platform .?platform conamo-sosa:UUID ?deviceUUID . ?rider conamo-profile:monitoredBy ?platform .?rider schema:givenName ?firstName . ?rider schema:familyName ?lastName .?rider schema:gender ?gender . ?rider schema:birthDate ?birthDate .?ov a conamo-sosa:QuantityObservationValue .?ov schema:unitText ?unit . ?ov schema:value ?value .{ SELECT ?sensor ( MAX ( f:timestamp (?x, sosa:madeBySensor, ?sensor) ) AS ?ts ) WHERE { ?xsosa:madeBySensor ?sensor . } GROUP BY ?sensor }FILTER ( f:timestamp (?o, sosa:madeBySensor, ?sensor) = ?ts )}REGISTER STREAM getTrainingZone ASPREFIX f: PREFIX rdfs: PREFIX schema: PREFIX sosa: PREFIX conamo-profile: PREFIX conamo-sosa: SELECT?deviceUUID ?firstName ?lastName ?gender ?birthDate ?sensor ?o ?time ?tzName ?tzDescription?tzLB ?tzUBFROM STREAM [RANGE 10s STEP 1s]FROM FROM WHERE {?o sosa:hasResult ?ov . ?o sosa:resultTime ?time . ?sensor sosa:isHostedBy ?platform .?platform conamo-sosa:UUID ?deviceUUID . ?rider conamo-profile:monitoredBy ?platform .?rider schema:givenName ?firstName . ?rider schema:familyName ?lastName .?rider schema:gender ?gender. ?rider schema:birthDate ?birthDate .?ov a conamo-sosa:HeartRateObservationValue . ?ov schema:value ?value .?rider conamo-profile:hasTrainingZone ?tzRider . ?tzRider conamo-profile:hasLowerBound ?tzLB .?tzRider conamo-profile:hasUpperBound ?tzUB . ?tzRider a ?tz . ?tz rdfs:label ?tzName .?tz rdfs:comment ?tzDescription . ?tz rdfs:subClassOf conamo-profile:TrainingZone .{ SELECT ?sensor ( MAX ( f:timestamp (?x, sosa:madeBySensor, ?sensor) ) AS ?ts ) WHERE { ?xsosa:madeBySensor ?sensor . } GROUP BY ?sensor }FILTER ( f:timestamp (?o, sosa:madeBySensor, ?sensor) = ?ts )FILTER ( ?value >= ?tzLB ) FILTER ( ?value <= ?tzUB )}9https://www.raspberrypi.org/products/raspberry-pi-3-model-bTrack: Personalized Real-Time Monitoring of Amateur Cyclists on Low-End Devices: Proof-of-Concept & Performance Evaluation WWW 2018, April 23-27, 2018, Lyon, France18370清单2：getQuantityObservationValue查询0开始。对于每个注册的查询，将在特定于查询的WebSocketURL上发布具有变量绑定的查询输出流。然后，任何感兴趣的客户端服务（例如Web应用程序）都可以打开到相关URL的WebSocket连接，然后可以实时接收到变量绑定的消息。06.3 C-SPARQL查询0为了实现实时反馈，可以在引擎中定义和注册C-SPARQL查询。构建了两个查询，允许对骑手的心率和相应的训练区域进行反馈。getQuantityObservationValue查询（清单2）分析数据，以查看流中是否有任何QuantityObservationValue，例如子类HeartRateObservationValue，可以与骑手的个人资料相关联。通过查询过滤掉与现有骑手个人资料相关联的以结果为单位的传感器的任何观测。对于每个传感器，只输出最新的观测结果。查询的通用结构利用了第6.1节中解释的骑行本体的通用结构，因为它聚合了所有产生QuantityObservationValue的传感器的结果。getTrainingZone查询（清单3）推导出骑手的当前心率区域。对于输入窗口中的任何HeartRateObservationValue，查询尝试将此观测链接到相应的骑手个人资料，以选择与心率值相对应的心率训练区域。结果中还给出了相关的训练区域反馈，如骑行本体中定义的那样。对于系统已知的每个心率传感器，只考虑最新的心率传感器观测。两个查询具有相同的窗口参数。这对于实时反馈的一致性是必需的：如果骑手的心率值发生变化，他的训练区域也会相应变化。06.4 动态方法0所述框架的优点是其动态性。为了创建个性化反馈，只需在反馈系统运行时更新上下文信息。例如，假设有新的骑手加入业余自行车手团队。为了能够输出关于该人的心率和0清单3：getTrainingZone查询0训练区域的查询结果，只需通过添加与该骑手及其自行车相关的传感器和个人资料信息来更新C-SPARQL使用的静态上下文数据。此外，不需要对C-SPARQL后端服务器本身和注册的C-SPARQL查询进行运行时更改。如果前端应用程序能够处理任意数量的骑手，那么该应用程序可以像以前一样继续运行；与新骑手相关的新绑定也将作为消息发送到相关的WebSocketURL。同样，可以将新的传感器类型、新的训练区域或其他反馈添加到上下文数据（即本体）中，而无需对实现的平台进行任何更改。此外，对于新的查询，一旦注册，查询将持续执行，并将其结果作为消息发送到其新的WebSocketURL。总结起来，可以在系统运行时随时添加、删除或更新上下文数据和查询，而无需进行其他适应。07 评估设置0重要的是，描述在第6节中的实时反馈系统能够处理一组业余骑手。然而，更多的骑手意味着更多的传感器观测和更多的静态上下文数据供C-SPARQL查询使用。由于低端设备通常具有有限的内存和有限的CPU能力，测试已经进行，以评估一个树莓派可以支持多少骑手。此外，还评估了心率频率和C-SPARQL查询参数对性能的影响。测试是在第3节描述的用例、第4节描述的设置以及第6节给出的流推理框架和查询上进行的。07.1 硬件规格0在本节描述的测试中使用的低端设备是树莓派3型B。该设备配有四核1.2GHz Broadcom BCM2837 64位CPU、1GBRAM和MicroSD存储9。18380操作系统是Raspbian Stretch withdesktop，版本为2017年11月，内核版本为4.910。选择桌面版本而不是最小化操作系统，可以在同一设备上运行和显示前端应用程序。这个应用程序可以消耗C-SPARQL查询结果来可视化实时反馈。当树莓派上没有前台应用程序运行时，大约有900MB的内存未使用，并且活动CPU使用率不超过1%。07.2 评估参数0首先，当反馈系统运行时，可能并不是所有可用的系统内存都在使用中。如果发生这种情况，可能会出现内存问题，导致系统无法正常运行。因此，总内存使用量应低于可用内存。其次，反馈应保持实时。具体而言，这意味着系统不能开始滞后，即总查询执行时间不能超过窗口滑动步长。如果发生这种情况，将再次触发相同的查询执行，而前一个执行仍在进行中。第三，反馈应实时更新每个骑手。这意味着如果静态上下文数据描述了n个骑手配置文件，则每个查询输出应优先包含n个结果，即每个骑手1个结果11，因为可以保证每个传感器的最新观测值都被两个查询过滤。因此，如果这个数量小于n，则至少一个骑手的窗口中没有观测值。这表明C-SPARQL无法正常运行，因为它需要比可用资源更多的资源。07.3 测试场景0为了进行评估，进行了一个真实场景的模拟。模拟了不同的情景。首先，评估了系统中的骑手数量。针对C-SPARQL查询的滑动步长的值，区分了理想情况和极端情况。在理想情况下，查询每秒执行一次，以获得大约1秒的输出事件速率。这将允许任何前端应用程序每秒更新一次，这对于实时系统是可取的。然而，在极端情况下，必须考虑到更新仍然可以被视为实时的最大滑动步长。对于心率值，这个值约为5秒，因为一个人的心率曲线通常相对平滑。如果更新之间的间隔超过5秒，这将不再可接受。除了查询滑动步长，还研究了查询窗口大小和事件速率的影响，即每个骑手连续到达的心率观测之间的时间。对于每个模拟，根据查询参数和骑手数量指定了查询和上下文数据。每次都启动一个C-SPARQL13服务器，并为每个骑手启动一个并行脚本，以指定的事件速率在注册的RDF流上发布随机生成的心率观测。通过这种方式，心率观测的到达模式010 https://www.raspberrypi.org/downloads/raspbian 11假设只有活跃的骑手在静态数据中被描述。 12 根据CONAMO项目的合作伙伴EnergyLab的专业知识。 13C-SPARQL版本0.9.7（https://github.com/streamreasoning/CSPARQL-engine）0不同传感器对输入流的影响是现实的：同一时期的到达时间接近，但到达顺序是未定义的且可能变化的。为了获得可比较的结果，心率观测的数量被选择为在每次模拟中至少执行50次查询。用于评估的测量结果来自于生成的日志文件中的C-SPARQL测量。基于第7.2节中定义的性能评估参数，从日志输出中计算了以下指标：（1）平均查询执行时间，（2）查询执行时间的90百分位数，（3）最大查询执行时间，（4）平均内存使用情况，（5）最大内存使用情况，（6）归一化的平均查询结果数量。最后一个参数被定义为每次查询执行的平均输出绑定数除以骑手配置文件的数量。由于每个骑手最多只能有一个结果，所以这个数值应该始终为1或更小。这个数值越接近1，即结果数量越接近骑手数量，越好，如第7.2节所解释的。08 结果0在图5中，显示了对系统中骑手数量的评估结果，对于固定的事件率和查询窗口大小。在图中，显示了查询执行时间（平均值、90百分位数、最大值），以及归一化的平均查询结果数量。由于这些值从不超过50MB，所以内存使用情况在图中被省略。将理想情况和极端情况（查询滑动步长为1秒和5秒）进行了比较。图中显示了1到20个骑手的模拟结果。如图5a和5b所示，平均查询执行时间从未超过查询滑动步长。然而，最大执行时间在理想情况和极端情况下分别从第6个骑手和第13个骑手开始超过这个值。90百分位数分别从第15个骑手和第19个骑手开始超过这个值。基于这两个事件，图表被分为三个区域（绿色、橙色、红色），在第9节中进行了讨论。随着执行时间的增加，平均查询结果数量从第6个骑手开始在理想情况下减少（图5c），对于15到20个骑手来说，减少幅度显著。在极端情况下（图5d），这个值只在15个骑手及以上的情况下超过1。查询窗口大小对计算指标的影响没有在图中显示，因为结果显示这种影响相当小。对于查询滑动步长为1秒、心率观测之间间隔为1秒和5个骑手配置文件的情况下，查询窗口大小从1增加到20时，最大查询执行时间没有受到影响。平均查询执行时间从95增加到324秒。90百分位数从未超过1秒，最大值也不超过100毫秒。内存使用情况不超过20MB。此外，结果完全不受影响。最后，图6显示了事件率的影响评估结果。在固定的查询窗口大小为10秒的情况下，014 由于两个查询是并行执行且独立的，因此考虑了各自的执行时间。15当C-SPARQL的负载过高时，运行时异常可能导致比正常情况下更多的结果。由于这些结果无法使用，构建图表时将这些值省略，以避免误解。16骑手数量被设置为5，因为在图5中查询滑动步长为1秒的测试结果中，这是仍处于绿色区域的最大数量。0论文：低端设备上业余骑行者个性化实时监测：概念验证和性能评估 WWW