成功迁移安全关键型软件

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

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

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

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

对开发环境的更改也可能导致迁移系统软件的需要。开发和维护应用程序的主机的过时（如 VAX/VMS 主机所发生的情况）可能会在难以找到故障硬件的备件时强制将系统软件迁移到新的开发工具。开发工具本身的过时或应用程序工具或语言专业知识的丧失可能会启动向新工具的迁移，以确保开发人员可以继续支持已安装的系统。同样，RTOS 的过时可能会促使软件迁移到新平台。

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

降低成本和风险

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

移徙因素

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

性能：新处理器/实时操作系统/平台能否满足系统“Äôs”的实时截止时间要求？

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

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

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

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

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

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

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

迁移期间所做的更改越多，起作用的因素就越多。风险最低的迁移是仅更改系统的一个方面，例如主机开发平台。如果原始软件开发系统和软件工具在当前主机平台（如运行微软Windows的PC）上可用，这是可行的。仅更改开发主机对系统和软件的其余部分的影响最小。

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

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

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

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

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

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

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

设计服务提供专家协助

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

如果最终必须废弃原始语言，系统设计人员可以使用翻译工具部分更改语言（如图 1 所示）。但是，没有任何工具可以完成完整的工作，并且转换后的源程序的可读性可能值得怀疑。如果可能，开发团队应努力仅在绝对必要的部分更改语言。

图1

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

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

图2

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

审核编辑：郭婷