现场部署设备中的软件跟踪

软件跟踪是每个嵌入式开发人员工具箱中的重要工具，尤其是与高级可视化结合使用时。大多数嵌入式系统都有大量循环模式，其中相同的序列一遍又一遍地重复。调试时，您经常希望找到异常情况，即发生异常情况的与正常循环行为的偏差。

但是，软件跟踪本身只是一种数据收集形式。在大量文本或数字日志数据中寻找问题类似于大海捞针，但通过适当的可视化，搜索会转化为视觉模式识别问题，这是人类大脑特别擅长做的事情.交互式图表显示执行时间、响应时间、任务切换、任务之间的消息传递——所有这些都使开发人员能够快速发现其固件执行中的异常情况，以便进行更深入的挖掘。

用于可视化跟踪诊断的工具已经存在至少十年，并且已被证明对实验室的开发和调试很有用。随着越来越多的嵌入式软件开发人员添加安全的“物联网”云连接，很自然地考虑在现场部署的设备中使用跟踪，以捕获在测试过程中遗漏的实际问题。毕竟，基于软件的跟踪不需要任何额外的硬件，并且连接的物联网设备显然能够像常规应用程序数据一样上传诊断跟踪数据。通过这种方式，开发人员可以快速了解在实际操作中导致问题的任何剩余软件问题，并获得详细的诊断信息以了解原因。

在这种情况下，软件跟踪相当于一个虚拟的“飞行记录器”，就像在发生事故时在客机中使用的那些。它是产品的一个组成部分，始终记录，在出现问题时提供重要信息。但与真正的飞行记录仪盒不同，它是一个软件解决方案，旨在解决软件问题。

这种 IoT 设备监控的一种解决方案是 Percepio 的 DevAlert（图 1），它由三部分组成：固件监控器、添加到固件中以实现警报跟踪和上传的小型库；我们的 Tracealyzer 工具用于视觉跟踪诊断；以及一个云服务，负责分类和存储警报、通知开发者、过滤重复警报等。

图一。 Percepio DevAlert 为 IoT 开发人员提供有关其云连接设备中错误的即时反馈，从而快速持续改进设备软件。
（点击图片放大）

初始版本在 AWS 上运行，适用于使用 AWS IoT 核心的 RTOS 应用程序，但该解决方案可适用于其他云平台。

软件跟踪和云连接
在开发实验室中跟踪和跟踪部署的设备是两件不同的事情。如果您今天在实验室中使用视觉跟踪诊断并希望将其扩展到该领域，则需要考虑一些事项。

与 USB 或以太网等直接物理连接相比，云连接提供有限的带宽和更长的响应时间。通过无线接口上传 5 KB 的数据可能需要数十或数百毫秒。然而，在这种方法中，跟踪不是连续传输的，而是仅在生成警报并且只有最近事件的少量跟踪时才传输。警报仅用于不寻常但重要的事情，例如，如果在应用程序代码中检测到错误，例如健全性检查失败、硬故障或看门狗重置。

任何连接互联网的设备都需要安全。因此，重要的是不要引入任何新的攻击媒介。我们在 DevAlert 中通过依赖现有的云连接而不是引入新连接来解决这个问题。这利用了 AWS 和其他领先的物联网/云提供商的安全性，这些提供商为云连接提供经过验证的 SDK，这些 SDK 根据最佳实践进行保护，例如使用 X.509 证书的设备身份验证和使用 TLS 的加密通信。这将使 DevAlert 上传与常规 IoT 应用程序数据一样安全，并且为了增加安全性，它只需要单向通信：它从不侦听传入消息。

在这种方法中，警报上传到设备通常使用的相同云帐户，并具有相同的安全级别。一旦进入云，一小部分数据将提供给云服务。这不包括实际的跟踪数据，这些数据可能被视为敏感信息，因此保留在设备的云帐户中。图 2a 和图 2b 更详细地显示了数据流和安全屏障。

图 2a。 数据流从设备软件开始，开发人员在此向源代码添加警报。上传到设备云帐户的每个警报都包含一个简短的跟踪，其中包含警报之前的最新事件。最后，元数据签名被转发到 DevAlert 云服务。 （点击图片放大）

图 2b。 云服务将传入警报与来自客户整个设备群的先前警报进行比较，并将任何新问题通知开发人员。重复的警报会被计数和存储，但不会发送通知。这样，如果在多个设备中触发了相同的警报，开发人员的收件箱就不会被淹没。 （点击图片放大）

接收云帐户警报的运营成本通常很低，尽管它自然取决于数量。首先，只要没有检测到问题，就不会发送警报。一般而言，云供应商对发送和存储偶尔的警报消息也收取很少的费用。大多数物联网应用会生成更多数据，这反映在物联网/云服务的定价中。例如，向 AWS IoT 核心发送 100 万条 MQTT 消息的成本为 1 美元。

大多数警报处理是在云服务中完成的，这是一个由 Percepio 托管的完全托管的服务。设备开发者云账号只进行初始处理，上云成本低，集成简单。

发送无线更新以修复报告的错误可能会花费更多，因为您需要传输更多数据并传输到所有设备。 AWS 提供了一个定价示例，其中更新 600,000 台设备的成本为 1,275 美元。然而，相对于让错误保持未修复的成本而言，这并不是很昂贵——客户体验受损、产品评论评级降低、销售额下降，甚至事故和法律诉讼。

用于嵌入式开发的 DevOps
使您的物联网设备能够在出现软件问题时“打电话回家”具有显着的优势。对错误的直接感知和详细的诊断在开发人员和部署的代码之间创建了一个反馈循环，使开发人员能够更快地修复错误并更快地推出更新的固件——见图 3。这种所谓的 DevOps 哲学长期以来一直是移动开发的标准和云应用程序，随着基于云的安全物联网平台的引入，嵌入式开发也有可能以这种方式工作。

图 3。 Tracealyzer 中的 DevAlert 仪表板列出了最近报告的警报和跟踪。
（点击图片放大）

从业务角度来看，这种 DevOps 式监控转化为更少的不满意客户，因为更少的最终用户会受到生产代码中的错误的影响。尽管进行了所有验证工作，但大多数嵌入式软件在发布时都包含一些遗漏的错误，但它们通常不会直接向所有人显示。如果您及早了解问题，通常会有一些时间在许多客户受到影响之前解决问题。理想情况下，应该在第一次警报的几秒钟内通知开发人员，并且提供的跟踪诊断允许快速分析和纠正。然后，开发人员可以发送自动无线更新来解决问题。即时感知和跟踪诊断可以大大缩短维修时间并最大限度地减少受影响客户的数量。

改进的设备可靠性降低了责任风险，还降低了客户支持、退货和调试的成本。提供的诊断使开发人员可以更轻松地重现客户问题，因为他们直接从设备获取信息，而不必依赖用户来描述情况。如果没有自动反馈，您只能依靠最终用户报告任何问题并提供足够详细的信息。诸如“系统停止响应”之类的模糊错误报告并不是很有帮助，可能需要数周时间才能找到可能的原因。即便如此，这也只是你最好的猜测——你无法真正知道你是否解决了正确的问题。

不仅是错误
需要注意的一件事是，警报不一定是关于遗漏的错误和由此产生的错误。由于开发人员可以自由决定在何处以及为何生成警报，因此他们还可以使用它们来监控应用程序的关键性能指标并查看偶尔出现性能问题的原因。

监视用户界面还可以揭示有趣的信息。假设您遇到用户在触摸屏上打开菜单的情况，例如在汽车的信息娱乐系统中，然后犹豫从哪里开始。为了捕捉此类问题，应用程序开发人员可以在每个输入事件后启动一个计时器，如果在 5 秒内未收到任何输入，则生成警报。如果随后收到许多关于用户界面同一部分的警报，这可能是重要的反馈，可以帮助您的组织构建更好的产品。

总而言之，在部署的设备中利用软件跟踪和基于云的警报具有重大优势，而且并不复杂。但是，要完全接受 DevOps 风格的工作流程，需要具备无线更新能力，以及了解软件测试的局限性以及在发布后持续改进的重要性的响应式开发组织。