嵌入式物联网设备的3种方案

尽管嵌入式设备在物联网中的作用可能十分重要，但目前并未强制要求这些设备都符合安全标准。由于物联网发展很快，合规要求可能滞后很多，有时候甚至在代码写好并测试之后才出现。那么，如何为嵌入式物联网设备的未来做好准备？

物联网（IoT）是由网络设备、组件或服务组成的系统，能产生和/或使用数据。物联网应用逐渐成为人们生活中不可或缺的部分：从工业机器人和手术器械，到自动驾驶汽车和自主飞行的无人机。今天，很多这些设备已经对用户的安全、隐私和安防产生影响，有一些甚至是致命的。因此，为物联网设备制定通用标准至关重要。

如果软件设计一开始就能符合规范当然是最好的，但众所周知，严格的开发流程，特别是在没有实现自动化的情况下，会影响产品上市时间。没有几个开发人员愿意加班完成额外的测试工作并记录可追溯性，如果费时费力地建立合规性只是出于将来“可能需要”，务实、敏捷和快速的开发团队是不会为此而损失元气的。相反，许多团队相信“船到桥头自然直”。

然而，没有什么魔法可以让时光倒流“使”代码从开始就符合规范。这些团队最后得到的教训是，等项目结束时再考虑合规性所需的成本，比开发伊始就考虑的成本要高出几个数量级。

所以，为了满足未来严格的规范要求，现在可以采取哪些有效措施呢？

措施1：清楚了解自己的技术负债

了解项目当前的状况非常重要。由于代码太复杂，加上代码中存在任何原本的编码标准及安全违规时，需要重写代码花费的成本即技术负债量。技术负债来自随后要完成的代码清理、修复和测试。静态代码自动分析是掌握项目当前状况的一种方法，它可以对代码库质量和安全性进行深入分析，并列出编码标准的违规（如果有的话）。

然而，许多用C和C++语言开发嵌入式应用程序的团队并没有采用静态分析法，而是依赖编译器或通过手动检查代码来找出问题。一些团队因为各种原因，如发现静态分析工具噪声太多且很难使用，或者由于紧急的日常事务而不能将其纳入日常开发流程，而难以决定是否使用静态分析工具。一种常见的误解是，确定哪些违规值得修复所需的时间，远超过实际修复的价值。

但我们发现，如果一个团队在项目的前期就强制性地采用了少许重要的规则，那么当项目后期面临功能安全审查时，重写代码花费的时间要少得多。如果从一开始就将安全性植入其中，例如实施CERT C安全编码规则，则更容易建成一个安全可靠的系统。我们可以从简单的规则开始。CERT拥有先进的优先级系统（包含严重性、可能性和补救成本三个指标，每个指标分为3个等级，总共27个级别），如果使用自动化测试工具，通常很容易在预先设置好的控制面板（dashboard）中查看合规状态。

静态分析通过采集数据点，帮助管理安全与安防合规性，使公司能够了解其技术负债。管理者可以轻松评估一些重要的问题，比如：

·底线是什么？代码库中不严重的编码违规有多少？

·趋势数据：是否每个新版本都报告了新的和已修复的违规？情况变好了还是变差了？

·目前的代码复杂度是什么？复杂度在增加吗？

有些标准要求衡量环路复杂度（cyclomatic complexity），并使其低于某个阈值。复杂度指标也可用于估计测试工作量——例如，对某个函数进行IEC 61508 SIL 2合规测试，若要达到100％的分支级覆盖率，则所需的测试用例数与该函数的McCabe环路复杂度成比例。

图1的例子来自一个控制面板，显示了某项目的MISRA合规性。

图1：项目的MISRA合规性。

图2显示的是CERT合规性。

图2：项目的CERT合规性。

查看代码指标有助于暴露更复杂的地方，从而进一步检查代码，同时监控测试是否对这些地方实现了良好覆盖。图3是指标控制面板示例。

图3：指标控制面板示例。

首先从基本的开始。一旦开发团队能够轻松自如地管理最严重的错误，就可以增大管理标准违规的范围。并非所有规则都是“一成不变”的，因此决定将哪些规则纳入项目编码标准非常重要。在一些关键编码标准中至少采用一组强制性的规则（例如MISRA强制性规范或环路复杂度C规则），将使联网设备未来的安全与安防论证变得更容易。

措施2：建立合格的单元测试框架并衡量代码覆盖率

大多数务实的工程师都会认同，盲目地为所有功能设置单元测试并不能获得良好的投资回报率（ROI）。但是，如果开发团队可以访问的单元测试框架是沙盒（sandbox）项目的一部分，那么这就是一项有价值的投资。当需要单独测试某些复杂的算法或数据操作时，可以根据实际情况来选择进行单元测试。完成单元测试这个过程本身也很有价值——从公司的角度来看，仅仅是编写和执行单元测试就可以使代码更加强健，并且代码设计得更好。

当安全与安防合规要求增加时，公司只需临时增加测试人员，就可加快单元测试工作。但要快速扩展测试工作，就需要在整个项目进程中了解单元测试框架和流程，并形成文档。一个考虑了未来合规性的可扩展单元测试框架应具有以下特征：

·适合指定安全标准的应用（例如通过TÜV认证）

·集成到自动打包系统中

·报告所需的代码覆盖率指标（例如MC/DC）

·按时间记录每个版本完成的测试结果和覆盖范围

·适用于多个项目和开发团队

最重要的是，要以最小的规模来部署未来安全标准需要的所有测试技术。这样的话，如果需要认证就更容易扩展，而不用从头开始。

措施3：隔离关键功能

构建嵌入式系统需要考虑大量的“非功能性需求”，如简单性、可移植性、可维护性、可扩展性和可靠性，同时还要综合考虑延迟、吞吐量、功耗和尺寸限制等因素。在设计可能与大型物联网生态相连的系统架构时，许多团队优先考虑的是一些与质量相关的因素，而不是安全与安防。

如果将组件在时间和空间上分离出来，未来它们便更容易符合安全规范（并具有良好的架构）。例如，在设计系统时，可以将所有的关键操作都放在单独的专用CPU上执行，所有的非关键操作放在另一个CPU上执行，从而实现物理隔离。另一种方法是采用分离内核管理程序（Separation Kernel Hypervisor）和微内核（Microkernel）概念。当然还有其它方法，但重点是要尽早采用关键架构方法，如关注点分离、深度防御和混合关键性分离。这些方法不仅减少了遵守安全与安防标准所需的工作量，还提高了应用程序的质量与复原性。例如，以下是隔离关键代码的一些方法：

·空间域：

文件

模块

目录

库

·执行域：

线程、RTOS任务、管理程序

CPU内核、独立CPU

将关键功能与非关键功能分离，未来检查合规性时，验证范围就可以缩小。

结语

物联网生态中的许多边缘设备提供关键性服务，它们可能需要符合未来的安全与安防标准。努力满足标准要求却不管是否真正需要，显然并不是一种合算的方法。但我们还是应该为未来做好准备，比如采用关键设计技术、单元测试方法和静态分析工具，同时收集各项指标数据来支持未来的需求。如果尽早启动，软件开发团队就可以将这些方法无缝应用到现有流程中。同时也应尽早采用具有可扩展性的正确方法，避免在开发、测试和部署软件时花费更大的力气使代码合规。