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

时间：2021-09-16 14:17:49

关键字：嵌入式软件软件开发

[导读]关注「嵌入式大杂烩」，选择「星标公众号」一起进步！作者|Elektor译者 | 禾沐国内嵌入式软件开发一直比较传统，除涉及关键系统外的多数项目，都是在“编程”优先的开发方式驱动下实施的。这背后的原因有很多，除了产品上市压力大、建模和仿真工具价格不菲之外，还有一个重要因素——嵌入式...

作者 | Elektor

译者 | 禾沐

国内嵌入式软件开发一直比较传统，除涉及关键系统外的多数项目，都是在“编程”优先的开发方式驱动下实施的。

这背后的原因有很多，除了产品上市压力大、建模和仿真工具价格不菲之外，还有一个重要因素——嵌入式软件开发的思维方式转变需要漫长时间和教育过程才能完成。

本篇译文详细阐述了如何改变嵌入式软件开发思维方式，并结合几款很实用的工具和汽车电子实例进行了具体分析。

嵌入式软件开发者们总是喜欢躲开关于软件架构、抽象化、建模和模拟的讨论，直接开始进行编程，而嵌入式软件代码往往一旦发布就不能进行改动了，出错的余地非常小。

既然我们都知道测试对嵌入式软件非常重要，也有很多进行建模/仿真的工具，那么，为什么还会先编程，然后等待很久才开始测试呢？

啄木鸟带来的危险

那是一次“原来是这样！”的顿悟。当时正在为了一个培训课程进行准备，我在想，为什么嵌入式软件工程师如此不愿意使用在其他软件开发过程中常见的概念和方法呢？

在微控制器相关的工程中，我时常会遇到这样的工程师：他们既不定义代码风格标准（尽管软件开发有多个工程师参与），也不会定义任何帮助提高代码可移植性和可用性的设计准则，更不会关心面向对象设计、建模和仿真。

我的脑海中浮现出了下面这句话：“如果木匠用程序员编程的方法建造建筑，只需要一只啄木鸟就可以摧毁整个人类文明。”

这句话从温伯格法则稍微修改而来，它着实引起了我的共鸣。为什么嵌入式软件开发者们不借鉴计算机科学研究成果，使用正确的方式构建代码，或者借力建模/仿真技术呢？

编程太快了吗？

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

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

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

推广新的开发方式？

过去，运行在微控制器上的代码往往可以用一个简单的状态机表示，如今微控制器需要解决多维的问题。今天的微控制器可以通过磁场导向控制（FOC）技术对电动机进行换向操作，并同时运行其他任务。

虽然相关的代码已经存在，但是，实时确定电动机的角度和计算下次换向的时机就已经非常复杂了。

这样的微控制器如果出现在家用洗衣机中的话，我们还需要考虑IEC 60730标准（自动电子控制 – 第1部分：一般要求）。大多数微控制器厂商会提供能够执行CPU寄存器、程序计数器、内存完整性和时钟测试的“B类”库，库代码应该在运行实时电动机控制的同时执行。

系统中一般还会有能快速响应的通讯接口和人机交互界面，嵌入式开发者也许可以保证每个部分都能单独运行，但是整合在一起后系统是否依然可靠呢？

一个选项是用统一建模语言（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）。

图1 eTrice“乒乓”样例工程，可以看到“乒”和“乓”的角色（左）以及它们的行为（右）

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

为什么测试开始得很晚？

在匆匆开始编程之后，许多嵌入式开发团队往往会等到已经编写了不少代码后才考虑开始测试问题，这样做的背后有很多繁杂的原因，比如错误地认为测试必须由一个团队或者部门负责，或是缺乏清晰、易于测试的软件需求。

集成开发环境强大的调试器也可能让我们产生了虚假的安全感。

Lisa Simone在《If I Only Changedthe Software, Why is the Phone on Fire?》一书[9]中用幽默的方式探讨了程序错误带来的后果。在一个例子中，不当的数据类型导致了温度控制算法的错误。

虽然Simone完整地描述了寻找这类问题根源的过程，但事实上，这些问题在单元测试中就应该被发现。

单元测试是一种白盒风格测试，即编写测试的工程师有源代码的知识，往往编写者就是源代码的作者。在微控制器上，单元测试需要一个能够执行测试和分析输出的应用，最终结果往往通过串口输出到控制台上。

这意味着，我们需要能够执行测试的硬件平台。Arduino和其他类似的平台提供UART到USB转换，这让在控制台上输出测试结果变得更容易。但是，针对每个软件模块开发和维护一个测试应用确实是很大的工作量。

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

在testIDEA中定义的测试用预定义的参数单独测试函数（图3）。在软件中我们能够任意修改RAM，从而注入任何类型的数据和指针。

测试的通过与否取决于函数的的返回值是否正确，测试中还可以通过跟踪功能提供代码覆盖的数据。

工具中有对C 的支持，但是在测试各类方法之前需要先调用构造函数。测试还可以输出进入Python环境，帮助测试的自动化。

图3 通过testIDEA测试在微控制器上运行的软件函数

testIDEA的一大功能是所有内部和私有变量值都可以在测试时进行注入，当你调试时可以想做什么就做什么。

这对于在编译中优化过的代码非常有帮助：我们都知道无用代码的移除和代码段的重组意味着优化后代码的行为和优化前并不完全一致，换言之，代码和二进制代码的关系会变得模糊，这让调试变得更加有挑战性。

通过在testIDEA中运行同样的测试，你可以在进行系统整合前确定基础代码的行为没有变化。

多少测试才足够？

对初次接触测试的工程师来说，确定最佳的策略并不简单。像《爱丽丝梦游仙境》中的兔子洞一深入研究测试的方法，你会觉得需要测试的东西越来越多。

软件的多维性和复杂的依赖关系意味着我们很难预估多少测试是足够的。参与过安全关键项目的工程师都知道，相关的标准都不是绝对的，比如汽车相关的ISO 26262和医疗相关的ISO 14971、IEC 60601。

举例来说，ISO 26262“非常推荐”代码分支覆盖作为测试覆盖的基准，然后只是“推荐”语句覆盖和MC/DC（修改条件、决策覆盖）。只有和测试领域的专家合作，才能确定在你的应用中如何测试才是最佳的。

为了确保代码的全部分支都被覆盖，所有可能的代码组合都要被测试到，我们可以借助sepp.med GmbH公司的MBTsuite产品。其基于模型的测试框架能够帮助确定所有可能的测试组合，因而非常适合系统集成和测试。

确定测试范围的第一步是将系统需求输入到Enterprise Architect这类的工具中。接下来构造系统的模型，将其和系统需求链接在一起。设计中较为复杂的部分可以用子模型来表示，从而保持模型整体的抽象程度和简洁性（见图4和图5）。

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

图5 释放刹车部分的Enterprise Architect子模型，可以看到模型到要求间的链接

接下来将完成的模型导入到MBTsuite中。软件允许你定义不同的测试策略，全路径覆盖（Full Path Coverage）会生成覆盖整个模型的测试方案，最短路覆盖（Shortest Path）用最短的路径遍历模型（见图6）。

此外，随机策略可以帮助发现形式化策略可能无法发现的问题，也可以作为在目标硬件上验证测试机制的冒烟测试（smoke test ）的一部分。

图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）。

图7 miniHIL和运行Jenkins持续集成平台服务器的PC整合（来源：PROTOS SoftwareGmbH）

寻找偶发失效

今天的汽车应用非常复杂，在一辆汽车上运行的代码量和Windows NT类似。代码开发的分布性意味着很多供应商（甚至客户）都参与到了其中。偶发的失效往往和定时有关，而不是功能，多核处理器和虚拟机的广泛应用更是加剧了这一情况。

即使在测试充分的情况下，即将发货的硬件上，甚至是客户环境中，奇怪的事情还是时而发生。一个汽车电子的实例：两个通过CAN总线相连的电子控制单元（ECU）会偶发错误，ECU A和B连接偶尔会出错，但是和C连接不会，ECU B和C能正常协同工作。

问题的根本原因是ECU石英频率的微小不同，运行时间足够长的情况下，两个微控制器的时钟差异会导致CAN消息的偶尔丢失。

Inchron AG[17]的chronSIM和chronVIEW，以及Vector InfomatikGmbH的TA Tool Suite等工具将定时看得和功能一样重要。它们允许在编写任何代码前在目标系统上构建模型，从而帮助系统架构师针对多种不同的硬件设计最佳的系统架构。

这些工具会分析在不同处理器核上运行代码的影响，这对于在核心频率不同的异构多核处理器上运行的应用而言至关重要。最后，工具分析事件链（见图8），并测量事件从传感器到达系统，并最终到达执行器的时间。这些工作对于整合若干数据速率不同的传感器数据的自动驾驶系统而言尤为重要。

图8 Inchron Tool Suite通过建模、仿真和分析等方法突出定时的重要性，图中展示的是一个事件链的分析（来源：INCHRON AG）

通过定义代码段的超时时间，以及同时注意功能和定时特性，与时间相关的ECU通过CAN连接的问题可以在设计层面上解决。在模型中，可以理解时钟频率变动、核心分配、代码执行时间和时钟频率变化的影响。

这些工具还可以分析在实际硬件上运行的微控制器产生的跟踪数据，检查在不同测试条件下代码段的执行时间是否合乎需求。

是更加重视建模的时候了？

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

支持嵌入式系统建模和仿真的工具提供了一个在开始编程前后退一步、进一步抽象化的机会。这一方式的背后是重复性的分析和测试，它因此可以帮助在开发太过深入前以较低的成本纠正设计上的问题。

桌面HIL还允许通过压缩的测试周期快速验证小的代码改动，而不是在整合后的代码上运行完整的测试。最后，虽然最复杂的实时应用（比如汽车）开发中建模和测试手段已经被广为应用，我们还是应该在功能要求的基础上添加定时的要求。

采用这些基于模型的工具的最大挑战，是对改变的畏惧。它们的抽象性让传统嵌入式开发者不得不离开他们熟悉和喜欢的硬件，前往一个陌生的地方。它们还需要开发过程做出改变，这导致了很多负面的意见。

这些工具从纸面上看非常合理，但只有真正开始使用，我们才能知道在实际操作中它们带来的益处。许多此类工具已经存在了十年或者更久，它们的地位和作用已经建立起来了。

这些工具可以降低开发时间和开销、提高产品的质量，开发者们需要从实际的开发过程出发，分析这类选项是否适用于他们的产品。