基于模型的设计为下一代救援梯开发控制系统

| 作者 Clemens Friedl，卢森宝亚集团

当飞机上或跑道附近发生意外事故时，急救人员需要快速进入机舱。在这种情况下，快速架设救援梯有助于快速疏散乘客或机组人员，或让医护人员能够为他们提供及时的医疗救助。 最近，卢森宝亚重新设计了飞机内部通道车（更通俗的说法是“救援梯”），旨在最大程度减少安装时间，同时保持高安全标准并提高易用性（图 1）。在开始这项工作时，我们还籍此机会重建了现有的控制软件开发流程，该流程之前一直基于手写编码和大量的车载测试。我们不再使用这种过时的方法，而是采用我们原本以为只对更大型 OEM 具有经济可行性的方法。具体来说，我们在 MATLAB 和 Simulink 中使用了基于模型的设计，通过仿真验证我们的早期控制设计，使内外部开发团队能够运行硬件在环测试，生成产品级代码，并将项目开发时间缩短一半。

控制设计面临的机遇和挑战

在我们为上一代救援梯设计控制系统时，当时可用的控制硬件较为有限。因此，我们需要将控制软件分布到六个 ECU 上。为了满足安全要求，我们还需要布线和其他组件应有大量冗余。 对于当前的设计，新的硬件让我们能够大大简化架构，并且只需使用两个 ECU。一个 ECU 通过了安全认证，可以处理所有安全功能，其软件由我们的供应商 TTControl 的工程师团队开发。另一个 ECU 负责运行控制应用软件，该软件则由我在卢森宝亚的团队开发。

虽然控制系统的架构较为简单，但我们在实现该系统时仍面临诸多挑战。首先，我们需要在获得救援梯的硬件（包括液压和机械组件）之前就着手开发工作。其次，控制器有一项关键设计限制，禁止楼梯在升降时随意停在任何位置。控制器必须从 2,500 个预定义锁定位置中找到最近的位置。在此位置，机械闩锁和齿条在重量满载的情况下应该能够支撑楼梯（图 2）。随着这种复杂性的增加，手工编写代码和直接在车辆上进行测试变得不切实际。此类方法实施起来往往很难，而我们的特定需求也使得该过程更具挑战性。最后，考虑到车辆的尺寸以及在测试过程中需要运行柴油发动机，所有车载测试都必须在室外进行。过去，我们经常需要在恶劣的天气或夜晚黑暗中运行测试，以满足截止期限要求。

开发被控对象和基本控制器模型

随着项目的推进，我们开始在 Simulink 中开发救援梯的被控对象模型。该模型包括用于作动器位置、液压、电流和 CAN 信号的传感器。它还包括液压系统的元件，如阀门和液压缸。这些元件视制造商数据表中的信息而定。 除了被控对象模型，我们还使用 Simulink 和 Stateflow 开发了一个简单的控制器模型。这个初始模型并未实现我们针对控制软件提出的所有需求。不过，其功能足以让我们了解机器将如何运转，以及我们可能需要对硬件设计进行哪些改进（如果有的话）。

通过将控制器和被控对象模型相结合，我们创建了一个用于运行闭环仿真的系统级模型（图 3）。仿真结果的分析影响了我们在以下方面的决定：将哪种液压升降机用于救援梯，以及实施哪种类型的传感器。例如，我们最初计划在液压缸上使用电流传感器，但当仿真显示这些传感器缺乏足够的精度时，我们决定改用 CAN 传感器。过去，这类设计问题只有等到开发过程的后期（即实车测试阶段）才被发现。

图 3. 包含被控对象和控制器子模型的系统级模型。

▼ 代码生成和 HIL 测试

通过桌面仿真验证了我们的早期控制设计后，我们很快便转向了 HIL 测试。我们使用 Embedded Coder 从我们的被控对象模型生成了代码，并将其部署到了一个 TTControl 的 TTC 580 ECU。我们还遵循同样的流程从控制器模型生成了代码，并将其部署到了另一个 TTControl 的 ECU。以实际控制器连接到救援梯的方式将这两个 ECU 连在一起后，我们运行了 HIL 测试来确认控制设计的实时性能，并验证救援梯触摸屏控制面板的操作（图 4）。 我们还为 TTControl 公司从事安全软件工作的同行提供了相同的 HIL 测试设置。这样，该团队便能与我们同时工作，对他们正在开发的软件进行自己的测试，而无需登上实际的救援梯。这种 HIL 测试设置不仅使 TTControl 团队能够加速他们的软件开发，而且还能够帮助他们开始在实际的救援梯上进行测试之前便发现并解决一些问题。

▼ 车载测试和调试

当 TTControl 团队完成安全软件开发时，我们继续开发并完善控制应用软件。在这个过程中，我们使用代码继承工具 (https://ww2.mathworks.cn/help/simulink/sfg/integrating-existing-c-functions-into-simulink-models-with-the-legacy-code-tool.html) 将 TTControl 工程师手写的电流和位置控制 C++ 代码导入我们的 Simulink 模型。然后，我们继续运行仿真和 HIL 测试，这不仅是为了验证我们添加到控制应用的新功能，而且是为了验证另一个团队开发并交付的 C++ 代码。 此时，我们已经准备好要在实际的救援梯上测试我们的控制器。我们再次使用 Embedded Coder 从 Simulink 模型生成了代码，并将其部署到了 TTControl 的 ECU。但这次，我们不是将 ECU 连接到 HIL 设置，而是将其连接到了实际的救援梯，并运行了一系列车载测试。 我们通过仿真验证的所有测试用例，也都在实际的救援梯上顺利执行。不过，我们确实发现了一些我们事先没有考虑到的边角情况，包括触摸屏显示器上的奇怪按钮组合。通过在 Stateflow 的状态机中插入额外的状态和转移，我们解决了这些问题（图 5）。然后，我们运行了仿真来验证所做的更改，重新生成了代码，并在实际的救援梯上再次进行了测试，以确保各方面都正常工作。以前，在我们手写控制代码时，凡是涉及添加状态和转移的更改，都需要相当长的时间来实现和调试。

图 5. 使用 Stateflow 设计的状态机概览。

▼ 在当前项目中使用基于模型的设计

随着救援梯现已投产，我们对所取得的成果做个总结。在性能方面，这些救援梯可以快速延伸到最高位置，其速度比我们之前的设计要快 20% 左右，这提高了紧急情况下的实际救援速度。从开发角度看，基于模型的设计帮助我们实现了更可靠的控制系统，而用时大约是以前方法的一半。 使用 Embedded Coder 从 Simulink 模型生成代码，是我们提高开发速度的关键因素之一。为了更好地了解如何利用代码生成，我们专门花时间学习了 Embedded Coder 的相关培训课程。除了帮助我们充分利用这款工具之外，这门课程还让我们对于将代码生成融入我们工作流的便捷程度大开眼界。以前，我们曾经花费大量时间调试和维护手写代码。那时，我们并未意识到有那么多汽车行业的大型公司都在利用代码生成实现生产控制软件。凭借这一认识，再加上我们自己在救援梯方面的第一手经验，我们的团队已将基于模型的设计推广应用到了其他几个项目，包括目前正在开发的电动消防车的控制设计。

编辑：黄飞