嵌入式软件开发者们总是喜欢躲开关于软件架构、抽象化、建模和模拟的讨论，直接开始进行编程，而嵌入式软件代码往往一旦发布就不能进行改动了，出错的余地非常小。既然我们都知道测试对嵌入式软件非常重要，也有很多进行建模/仿真的工具，那么，为什么还会先编程，然后等待很久才开始测试呢p>

啄木鸟带来的危险

那是一次“原来是这样！”的顿悟。当时正在为了一个培训课程进行准备，我在想，为什么嵌入式软件工程师如此不愿意使用在其他软件开发过程中常见的概念和方法呢控制器相关的工程中，我时常会遇到这样的工程师：他们既不定义代码风格标准（尽管软件开发有多个工程师参与），也不会定义任何帮助提高代码可移植性和可用性的设计准则，更不会关心面向对象设计、建模和仿真。

我的脑海中浮现出了下面这句话：“如果木匠用程序员编程的方法建造建筑，只需要一只啄木鸟就可以摧毁整个人类文明。”这句话从温伯格法则稍微修改而来，它着实引起了我的共鸣。为什么嵌入式软件开发者们不借鉴计算机科学研究成果，使用正确的方式构建代码，或者借力建模/仿真技术呢p>

编程太快了吗strong>

一个原因可能是来自这一代程序员的经历。他们的生涯从资源受限的8位微控制器开始，用汇编语言最高程度地利用硬件的性能是王道，抽象化和工具自动生成的代码只能意味着代码冗余和失去对代码的完全控制。转移到C语言对于一些人来说都有难度，尽管C语言已经非常贴近硬件了。

另一个角度是C语言的教学方式往往注重语法，而不是如何最佳地使用这门语言。但是，就像自然语言一样，精通语法并不能让你成为一位演说家。

物联（IoT）应用出现以前，升级微控制器的固件基本意味着亲自前往设备的所在地，代码出错的余地非常小。即便如此，许多嵌入式程序员的开发方式也始终没有改变。

推广新的开发方式strong>

过去，运行在微控制器上的代码往往可以用一个简单的状态机表示，如今微控制器需要解决多维的问题。今天的微控制器可以通过磁场导向控制（FOC）技术对电动机进行换向操作，并同时运行其他任务。虽然相关的代码已经存在，但是，实时确定电动机的角度和计算下次换向的时机就已经非常复杂了。

这样的微控制器如果出现在家用洗衣机中的话，我们还需要考虑IEC 60730标准（自动电子控制 – 第1部分：一般要求）。大多数微控制器厂商会提供能够执行CPU寄存器、程序计数器、内存完整性和时钟测试的“B类”库，库代码应该在运行实时电动机控制的同时执行。系统中一般还会有能快速响应的通讯接口和人机交互界面，嵌入式开发者也许可以保证每个部分都能单独运行，但是整合在一起后系统是否依然可靠呢p>

一个选项是用统一建模语言（UML）针对应用进行建模并运行仿真。嵌入式软件开发者往往非常不喜欢这种方式，他们认为这样做是浪费时间：如果有时间建模和运行仿真，还不如直接把代码写出来。一些人还在系统设计中滥用UML，导致UML染上了不好的名声。抽象的设计方式还意味着不同的开发过程，说服一个开发团队转变开发过程并不是一件容易的事情。

对于在设计和实现中各编程一次的担心，我们称为过程的不连续性（phase discontinuity）。理想状况下，建模过程应该解决这一问题，比如实时面向对象建模（ROOM）领域特定语言（DSL）。ROOM专门针对事件驱动的实时系统，它支持建模和模拟，还能够生成针对目标硬件的代码。

ROOM从三个维度描述软件：结构、行为和继承。结构可以用角色（actor）通过端口（port）互相通信表示，消息通过运行时软件库进行传递。角色的行为通过多层有限状态机进行表示，并可以图表形式输出。进入和离开状态的代码可以用代码生成器（比如针对微控制器的C编译器）的目标语言进行定义。当端口接收消息或者收到回应时，状态改变会发生。

继承提供了ROOM中面向对象的部分，既将角色看作可以多次实例化的类。每个实例继承状态机，需要的话，状态机还可以进一步扩展。最后一个概念是分层（layering），它允许应用互相进行通信，或者通过服务访问点（SAP）使用服务（比如定时器）。

Eclipse集成开发环境插件eTrice支持这一软件开发方式。模型可以通过图形或者文本创建，并可以输出C、C++或者Java代码。在模型上运行模拟将会输出消息序列图（MSC），UML工具Trace2UML（Astade[8]的一部分）可以将序列图进行可视化。图1所示的是一个简单的“乒乓” 样例应用，其中定时器SAP决定了响应延迟的时间。通过图像和ROOM DSL可以检查应用的结构和行为。执行模型将会在命令行上输出结果，模拟的输出是MSC（见图2）。

图2 在“乒乓”模型上运行模拟所产生的消息序列图

为什么测试开始得很晚strong>

在匆匆开始编程之后，许多嵌入式开发团队往往会等到已经编写了不少代码后才考虑开始测试问题，这样做的背后有很多繁杂的原因，比如错误地认为测试必须由一个团队或者部门负责，或是缺乏清晰、易于测试的软件需求。集成开发环境强大的调试器也可能让我们产生了虚假的安全感。

Lisa Simone在《If I Only Changedthe Software, Why is the Phone on Fire书[9]中用幽默的方式探讨了程序错误带来的后果。在一个例子中，不当的数据类型导致了温度控制算法的错误。虽然Simone完整地描述了寻找这类问题根源的过程，但事实上，这些问题在单元测试中就应该被发现。

iSYSTEM开发的testIDEA提供了显著降低测试难度的方法。iSYSTEM开发的调试工具意味着开发环境不仅能访问源代码，还可以通过调试接口访问微控制器的环境。使用testIDEA只需要提供能够写入微控制器闪存的编译过的应用代码（ELF格式）。

在testIDEA中定义的测试用预定义的参数单独测试函数（图3）。在软件中我们能够任意修改RAM，从而注入任何类型的数据和指针。测试的通过与否取决于函数的的返回值是否正确，测试中还可以通过跟踪功能提供代码覆盖的数据。工具中有对C++的支持，但是在测试各类方法之前需要先调用构造函数。测试还可以输出进入Python环境，帮助测试的自动化。

图4 电子驻车制动装置的EnterpriseArchitect模型

图6 MBTsuite中电子驻车刹车的模型产生全路径覆盖测试方案

从电子驻车刹车（EPB）的模型（见图4）可以看出，遍历节点的过程中可能会进入无限循环。循环数目（number of loop）和最长路径长度（maximum path length）参数可以用来避免这一情况的产生。你也可以通过指定模型的区域来生成针对特定功能的测试。

MBTsuite最简单的用法是产生Word或Excel文档详述测试的步骤和各个验证点预期的结果，手动测试时可以勾选每一步的完成情况，最终给出通过/失败的结果。自动化测试的情形下，软件根据模板生成合适的格式，比如Python代码。

在硬件上快速测试

理想条件下，应用在开发过程中应该进行硬件在环（HIL）测试，这对于在高压、高电流或者有活动部件的环境中运行的应用尤其重要。但是，这样的测试机制可能会很昂贵，许多团队也可能需要在同一套硬件上测试多种产品。其结果是HIL测试的瓶颈效应导致测试直到开发末期才进行。在当前新冠疫情的影响下，HIL测试甚至可能完全无法进行。

为了应对这一挑战，PROTOS Software GmbH开发了miniHIL平台。平台包括一个A4纸大小的硬件板，其上右侧是安装STM32 Nucleo开发板的位置，左侧有一个强力的STM32H743微控制器，中间则是连接两侧的针脚矩阵。STM32H743的作用是模拟STM32 Nucleo控制的设备，并产生同样的信。这一平台非常适用于在没有实体洗衣机或者电钻的情况下测试电动机控制应用。

miniHIL环境支持eTrice和CaGe（Case Generator）语言进行测试的开发。这既让开发者可以快速检查代码改动的正确性，也允许整个平台和持续集成（CI）平台相结合，比如Jenkins。这样一来，自动测试可以定期在硬件上执行，比如每晚执行测试，第二天一早在仪表盘上检查结果（见图7）。

通过定义代码段的超时时间，以及同时注意功能和定时特性，与时间相关的ECU通过CAN连接的问题可以在设计层面上解决。在模型中，可以理解时钟频率变动、核心分配、代码执行时间和时钟频率变化的影响。这些工具还可以分析在实际硬件上运行的微控制器产生的跟踪数据，检查在不同测试条件下代码段的执行时间是否合乎需求。

是更加重视建模的时候了strong>

嵌入式软件开发领域一直比较传统。“急于编程”的思维方式被微控制器供应商提供的编程和调试工具链所加剧，这些工具多是免费的，这样一来其他付费授权的工具链就失去了存在的意义。

支持嵌入式系统建模和仿真的工具提供了一个在开始编程前后退一步、进一步抽象化的机会。这一方式的背后是重复性的分析和测试，它因此可以帮助在开发太过深入前以较低的成本纠正设计上的问题。桌面HIL还允许通过压缩的测试周期快速验证小的代码改动，而不是在整合后的代码上运行完整的测试。最后，虽然最复杂的实时应用（比如汽车）开发中建模和测试手段已经被广为应用，我们还是应该在功能要求的基础上添加定时的要求。

采用这些基于模型的工具的最大挑战，是对改变的畏惧。它们的抽象性让传统嵌入式开发者不得不离开他们熟悉和喜欢的硬件，前往一个陌生的地方。它们还需要开发过程做出改变，这导致了很多负面的意见。这些工具从纸面上看非常合理，但只有真正开始使用，我们才能知道在实际操作中它们带来的益处。许多此类工具已经存在了十年或者更久，它们的地位和作用已经建立起来了。这些工具可以降低开发时间和开销、提高产品的质量，开发者们需要从实际的开发过程出发，分析这类选项是否适用于他们的产品。

是时候改变一下嵌入式软件开发思维方式了！