当飞机上或跑道周围有意外事故发生，第一时间的反应人员会需要可以快速进入舱内的途径。在这种情况下，迅速部署救援梯可以做为一个快速疏散的装置，或者协助医护人员提供乘客或机组成员及时的医疗援助。

我们在Rosenbauer公司的团队近期重新设计了飞机内部通道车（Aircraft Interior Access Vehicle），或者更通俗的说法为「救援梯」，在维持高安全标准并改善使用便利性的同时，尽可能缩短设置时间（图1）。

图1 : Rosenbauer救援梯

当我们开始这项工作时，也藉此机会重塑既有的控制软体开发流程，该流程是以手写的程式码与大量的实车测试为基础。我们将这套过时的方法以一种原本认为只对更大型OEM专案具备经济可行性的方式取代。

特别是使用MATAB与Simulink提供的以模型为基础的设计流程（Model-Based Design），透过模拟来验证我们的早期控制设计，让内部与外部的开发团队能够执行硬体??圈（hardware-in-the-loop）测试、产生产品程式码，并且将专案开发时间缩减了一半。

控制设计的机会与挑战

在设计前一代救援梯的控制系统时，能够选择的控制硬体比起现在相当有限。因此，我们需要将控制软体分配给六组ECUs，同时也需要在线路和其他元件加入大量的冗馀（redundancy）以符合安全要求。

而至於现在的设计，新的硬体让我们能够将架构大幅简化，只需要使用到两组ECUs。一组经过安全性验证的ECU处理所有的安全性功能，其软体是由我们的供应商TTControl的工程团队所开发；第二组ECU执行控制应用软体，该软体由Rosenbauer团队自行开发。

虽然新版的架构较为简单，我们在实现控制系统时还是遇到了几项挑战。首先，我们必须在取得救援梯硬体（包含液压和机械元件）之前，就开始开发工作。第二，有一项控制器的关键设计限制是禁止救援梯在上升或下降时随意停止在任何位置。控制器必须从2,500个预先设好的锁定位置找出最接近的定位。在这个位置上，会有机械拴扣和齿在重量满载时支撑着救援梯（图2）。

图2 : 救援梯上的锁定机械装置

随着复杂度提高，手动编写程式码以及直接进行车载测试变得不切实际。这种方法通常已经相当困难，而我们特殊的要求又让流程更具挑战性。最後，鉴於车辆的尺寸以及在测试时需要启动柴油引擎，所有的车载测试都必须在户外执行。以前，我们经常需要在恶劣的天气或夜间黑暗中进行测试来满足截止期限。

开发受控体和基础控制器模型

随着专案展开，我们开始在Simulink开发一个救援梯的受控体模型。这个模型包括致动器的位置、液压、电流及CAN讯号，它也包括液压系统的要件，例如阀门和液压缸，我们依据制造厂商提供的资料工作表上的资讯来加入这些元件。

伴随着受控体模型，我们还使用Simulink和StateflowR开发一个简易的控制器模型。这个初始的模型并未实现对於控制软体的每一项要求，然而它包含足够的功能，帮助我们得知机器会如何运作，以及是否需要在硬体设计上做出任何改变。

我们组合控制器与受控体模型来建立一个使用来执行封闭??圈模拟的系统层级模型（图3）。模拟结果的分析会影响我们决定要在救援梯上使用哪一种液压升降机，以及要实现哪些种类的感测器。举例来说，我们一开始是计划要在液压缸上使用电流感测器，但是看到模拟结果并发觉它们的精确度不足时，就决定改为使用CAN感测器。以前，这类的设计问题会在开发流程较後面的实车测试阶段才被发现。

图3 : 包含受控体和控制器子模型的系统层级模型

程式码生成与HIL测试

经由桌上模拟验证过早期控制设计之後，我们很快地进入到HIL测试。在使用Embedded CoderR从受控体模型产生程式码，并且将程式码部署在一个TTControl提供的TTC 580 ECU。再依循同样的流程从控制器产生程式码，并且部署到第二个TTControl ECU。在完全按照真正控制器接在救援梯的方式将这两个ECUs衔接一起之後，我们执行HIL测试来检验控制器设计的即时效能，并且验证控制器与救援梯触控面板之间的运作（图4）。

图4 : 用来控制救援梯的10寸触控萤幕显示器

我们也为在TTControl负责安全软体的同事提供一个相同的HIL测试设置。该团队接下来的工作就可以与我们同时进行，他们可以执行自己测试来检验其开发的软体，而不用要求进入真正救援梯。这个HIL测试设置不只是帮助TTControl团队加快软体的开发，也帮助他们在开始到真正的救援梯执行测试之前，就发现并解决了几个问题。

实机测试与投产

当TTControl团队完成安全软体的开发，我们这边则持续开发并精进控制应用软体。作为流程的一部分，我们使用Legacy Code Tool将TTControl工程师手动编写的电流和位置控制C++程式码汇入至Simulink模型。接下来，继续执行模拟和HIL测试，不只是为了验证我们在控制应用加入的新功能，也验证了由其他团队开发及发布的C++程式码。

这个时候，我们已经准备好要在真正的救援梯上面测试控制器。我们再一次使用Embedded Coder从Simulink模型产生程式码，并且将程式码部署到一个TTControl ECU。不过这一次我们不是把ECU写进HIL设置，而是连接到真正的救援梯来执行一系列的实机测试。

所有藉由模拟验证的测试情境在真实的救援梯，也都可以顺利运行。不过我们确实发现有几个之前没有考虑到的边角案例，包含在触控萤幕上按下奇怪的按钮组合。我们透过将几个额外的状态和转换??入至Stateflow的状态机来解决这些问题（图5）。接着，执行模拟来验证变更、重新产生的程式码，并且再一次实际的救援梯测试以确保每一个环节都正确运作。以前在手动编写控制程式码的时候，牵涉加入状态和转换的任何形式变更，都需要花上更长的时间来实现和除错。

图5 : 使用Stateflow进行状态机设计

以模型为基础的设计用於专案

当救援梯现在已投入生产，我们来为已达成的成就做个总结。就性能表现来说，该救援梯延伸到其最顶端的位置所花的时间比我们先前的设计快了20%━提高了紧急情况下的真实救援速度。从开发的观点来看，以模型为基础的设计帮助我们实现一个更可靠的控制系统，而且耗费的时间还不到采取原本方式的一半。

使用Embedded Coder从Simulink模型产生程式码是提高研发速度其中的关键因素之一。我们在Embedded Coder的训练课程投入一些时间，用来更透彻地了解程式码生成的利用。除了帮助我们发挥这套工具的最大价值，这门课程也让我们对於将程式码生成纳入工作流程的便利程度大开眼界。

我们从前曾经花费大量时间在除错及维护手写程式码，而且未察觉已经有那麽多车辆产业的大型公司采用程式码生成於产品阶段的控制软体。这项认知，再加上在救援车的第一手经验，促使我们的团队在几项其他专案扩大使用以模型为基础的设计流程，包括目前正在开发的电动消防车的控制设计。

（本文由??思科技提供；作者Clemens Friedl任职於Rosenbauer Group）