安全关键型系统迁移应该考虑哪些问题

　　软件俱乐部的第一条规则：如果它没有坏，不要谈论它。但是，这在许多情况下是不可行的，例如当由于系统相关原因必须迁移运行良好的代码时。这在安全关键系统中成为一个大问题，在这些系统中，更改代码可能会触发许多其他昂贵且有风险的活动。那么设计师该怎么做呢？这里解释了如何衡量团队的目标以及应该考虑哪些选项。

　　将安全关键型系统迁移到新技术可能是一个代价高昂且有风险的过程，开发人员应尽可能避免。然而，在某些情况下，出于财务或性能原因，迁移是可取的，或者由于硬件过时和新要求而不可避免。面临迁移的开发人员需要仔细考虑系统更改的类型和程度，以比较内部活动与设计服务支持的好处。

　　部署在航空航天和国防领域的安全关键嵌入式系统的使用寿命通常超过单个系统组件的使用寿命。技术发展的快速步伐很可能在系统本身退役之前至少需要更改其中一个组件数年甚至数十年。反过来，此类硬件更改可能会引发开发人员需要将系统软件迁移到新技术以确保持续的可维护性。

　　许多系统更改可以触发软件组件迁移。例如，外围设备、通信总线或协议可能会发生变化，从而迫使代码段迁移到新硬件。目标硬件或处理器可能会过时，就像基于 Intel 80860 的系统一样，迫使整个系统软件迁移到一个全新的平台。可能会出现新的功能要求或认证标准，迫使系统设计结合以前不需要的实时操作系统 （RTOS）。同样，新标准的实施、监管机构（如 FAA）对认证的新要求以及与新系统互操作的需求可能会产生将软件迁移到新平台的需求。

　　对开发环境的更改也可能引发迁移系统软件的需要。开发和维护应用程序的主机过时，就像 VAX/VMS 主机一样，当故障硬件的备件变得难以找到时，可能会迫使系统软件迁移到新的开发工具。开发工具本身的过时或应用程序工具或语言专业知识的丧失可以启动向新工具的迁移，以确保开发人员可以继续支持已安装的系统。同样，RTOS 的过时可能会促使软件迁移到新平台。

　　即使是业务变化也会刺激迁移。与 RTOS 或其他软件组件相关的生产版税会影响系统的盈利能力。随着利润的缩小，开发人员可能会选择迁移系统软件以消除此类版税。

　　降低成本和风险

　　无论是什么触发了硬件或软件的变化，迁移系统软件都涉及成本和风险。软件迁移不仅意味着更改软件及其伴随的引入错误的风险，还意味着重新测试和可能重新认证软件。开发和测试工作的综合成本可能相当可观，尤其是对于必须满足严格要求的安全关键系统。

　　迁移因素

　　成功迁移的一个关键——最小化成本和风险——是彻底了解迁移的影响。开发人员需要考虑许多因素，包括：

　　性能：新处理器/RTOS/平台能否满足系统的实时期限要求？

　　资源限制：软件是否适合系统内存和寄存器可用性的限制？

　　RTOS 影响：将 RTOS 更改或添加到曾经裸板环境中可能会改变代码执行顺序或时序。它还可能增加系统复杂性并改变内存需求。

　　字长：字长的变化，比如从 16 位到 32 位，将如何影响现有代码？计算算法、指针、计数器、上溢/下溢条件和执行速度会受到字长变化的影响。

　　工具可用性：主机或目标平台的变化是否也意味着工具集的变化？用于创建和维护系统软件的开发工具可能不适用于主机系统和目标处理器或 RTOS 的给定组合。

　　数据布局：编译器将数据映射到寄存器和内存的方式各不相同。这种变化可能会导致与软件中隐含或预期的映射发生冲突。

　　可扩展性：软件迁移可能需要升级或增强功能以​​满足新要求。工具和系统资源需要支持此类增强功能。

　　可追溯性：将迁移的软件追溯到原始版本的能力可以通过证明软件没有改变来帮助降低测试成本。

　　迁移过程中发生的变化越多，发挥作用的因素就越多。最低风险的迁移是只改变系统的一个方面，例如主机开发平台。如果原始软件开发系统和软件工具在当前主机平台（例如运行 Microsoft Windows 的 PC）上可用，则这是可行的。仅更改开发主机对系统和软件的其余部分的影响很小。

　　开发人员应该寻求创造性的方法来将更改的数量保持在最低限度。例如，如果新主机平台上没有开发工具，则仿真可以提供切换工具集的替代方法。在 PC 上运行的 VAX 仿真器已被证明成功地允许继续使用工具，并且由此生成的二进制目标代码通常与原始代码相同。工具、源代码和目标代码没有改变，减少了重新测试和重新认证的需要。

　　工具更改需要编译器专业知识

　　当工具集必须改变时，开发人员面临着额外的挑战。编译器将源代码映射到底层硬件结构的方式各不相同，例如内存寻址和寄存器使用。除非开发人员仔细约束编译器的行为，否则这些变化可能会导致目标代码发生变化。充其量，这会触发重新测试并可能重新认证软件的需要。在最坏的情况下，这些更改可能会在执行期间导致意外且可能存在缺陷的系统行为。

　　在不引起其他更改的情况下更改工具集要求开发团队具有编译器行为方面的专业知识，而这正是应用级工程师通常缺乏的专业知识。为了避免花费时间和精力来获得所需的技能，开发团队可以向外部寻求帮助。设计服务组织通常具有使用各种工具集的经验，并且可以将这些经验用于确保工具更改不会触发软件更改。

　　设计团队应尽可能避免一些更改，例如将应用程序从旧式编程语言转换为当前编程语言。团队应该利用旧语言和新目标硬件的开发系统，而不是转换。这将并发更改和风险的数量限制在两个：开发系统和目标硬件。

　　改变语言涉及许多可能的陷阱。生成的应用程序将与原始应用程序不同，需要进行昂贵的重新测试和重新认证。其他因素也起作用。生成的代码将具有不同的布局，并且可能不再适合可用内存；数据布局将不同，不再正确映射到底层硬件；性能和时间方面将发生变化。应用程序必须在源代码级别进行修改，这将需要培训软件工程师使用新的编程语言以及应用程序的设计和内部工作。

　　尽管如果没有一个程序员接受过应用程序编程语言的培训，迁移到一种新语言可能很诱人，但这应该是最后的手段。在采取这条路线之前，请考虑用旧语言培训程序员。精通 Java 或 C++ 等相对复杂的当前语言的程序员不会发现学习另一种语言是不可逾越的。

　　设计服务提供专家协助

　　另一种可能性是聘请提供必要语言专业知识的设计服务。对于针对军事和航空电子系统的 Ada 和 JOVIAL 等专业语言，设计服务提供商通常在应用领域和语言方面拥有丰富的经验，包括满足安全关键系统设计需求的经验。这使他们能够快速深入了解系统软件，并提供开发团队所需的维护和升级支持。

　　如果归根结底必须废弃原始语言，系统设计人员可以使用翻译工具部分更改语言。然而，没有任何工具可以完成完整的工作，并且转换后的源程序的可读性可能会受到质疑。在可能的情况下，开发团队应努力仅在绝对必要的部分更改语言。

　　实现此目的的一种方法是使用支持新旧目标语言并可以混合语言的工具集。这允许团队保持原始代码中仍然可用的部分完整，并将语言更改限制在满足新要求所涉及的部分。

　　这种混合语言工具的一个关键部分是调试器。虽然许多编译器可以组合不同语言的代码段，但大多数调试器工具一次只能处理一种语言。这意味着开发人员必须同时调用多个工具来查看代码段之间的交互，而这些工具很少以协调的方式交互或交换信息以帮助将目标代码与多种语言源相关联。DDC-I，Äôs OpenArbor等工具允许从一次启动中进行混合语言调试，可以显着减少调试时间并更容易检测交互错误。

　　无论是否涉及语言更改，迁移安全关键系统软件都是一项复杂的任务，存在许多潜在的陷阱。硬件、主机、目标、工具和语言的每次更改都会带来复杂性，并可能会强制进行额外更改，从而导致后果升级。通过最大化遗留工具和代码重用，应尽可能避免迁移中固有的成本和风险。当需要更改时，仔细选择新工具并战略性地使用经验丰富的设计服务可以降低软件迁移风险和成本。

　　审核编辑：郭婷