作者:COLIN DOYLE,STEPHEN DENMAN
军事系统和产品中的组件过时是一个众所周知的挑战,但它已经发展出一个相对较新的转折点:嵌入式软件数量的快速增长。虽然软件在某种程度上已经嵌入军事电子元件中数十年,但在过去十年中,这一趋势已经加速到白热化的程度;我们的系统和产品中越来越多的关键功能依赖于软件。在大多数其他复杂的军事系统和产品中都可以找到类似形状的曲线,包括所有其他飞机、海军舰艇、地面车辆、C4ISR 系统和场外支持系统。
事实上,航空航天和国防工业的许多人会声称,软件早已取代硬件成为创新的主要来源。软件与硬件一样,不能免受需要升级或更换这些组件的问题的影响。但是,与硬件不同,这些问题往往具有不同的性质,因此需要不同的处理。
硬件就像人 – 软件就像酒
硬件和软件组件之间最大的区别之一是硬件往往会随着时间的推移和使用而降级,而软件保持不变。给定相同的输入,软件每次都会生成相同的结果。另一方面,硬件在达到或超过其使用寿命时,由于磨损、腐蚀和/或疲劳开裂,最终会发生故障或停止按规格运行。
这并不是说软件不包含缺陷;只是这些缺陷在软件生产时就潜伏在软件中,而不是随着时间的推移而通过使用而引入。软件不是在与硬件相同的意义上“制造”的。一旦开发出软件组件,就可以以基本上零成本和自动复制过程引入的零缺陷进行复制。软件组件的可靠性往往表现出“浴缸”形状,其中最初的使用揭示了许多这些潜在缺陷,然后通过软件更新来解决这些缺陷,然后是相对较长的低缺陷率,然后随着操作环境的变化,作为软件组件基础的原始设计假设和约束失效,问题增加。像葡萄酒一样,软件组件往往会随着时间的推移而改进,因为更多的潜在缺陷被发现和解决。
鉴于软件没有与硬件制造相关的容差问题,软件也不会因使用而磨损,传统的硬件报废措施(如平均故障间隔时间 (MTBF))与软件没有太大相关性。因此,如果软件随着年龄的增长而变得更好,它如何加剧军事组件过时的挑战?要回答这个问题,我们需要了解是什么会导致软件过时。
软件过时的根本原因
软件组件过时的主要原因有三个:
软件必须运行的环境更改(兼容性)
潜在缺陷的暴露
软件必须执行的角色和功能的更改
软件只是一系列编码指令,用于控制其执行的硬件平台的行为。软件组件依赖于底层电子组件来提供正确的接口并按指定运行。因此,软件过时的一个主要因素是由于电子元件过时而导致底层硬件平台的变化。电子元件过时是一个众所周知的问题,因为基础技术变化迅速,而且与商业应用相比,军事采购量相对较低。每当软件与之交互或运行时的底层电子元件发生变化时,还必须重新评估软件,并可能升级或更换软件。
一个典型的例子是 5 年的阿丽亚娜 501 航班 1996,它在发射 40 秒后以火箭被摧毁而告终。故障的根本原因是重复使用阿丽亚娜4号的惯性参考系统,而没有在阿丽亚娜5号设计的背景下对该子系统背后的约束和假设进行适当的评估。惯性参考系统被重复使用,因为它被认为是经过验证和验证的设计。然而,该系统是为火箭设计的,其发射剖面的功率更小,水平加速度明显低于阿丽亚娜5。将浮点值转换为 16 位整数触发溢出错误,导致飞行控制系统崩溃。
显然,当在软件组件中发现缺陷时,必须解决它们。根据软件组件及其相关硬件环境的性质,在现场执行此类更新可能与通过网络连接下载更新一样简单,或者与更换整个电子组件一样昂贵。软件组件的较大成本是分析缺陷、更新设计和实现以及在发布组件之前重新验证组件所需的开发工作。此成本通常较大,因为更新的机会通常会导致第三个原因:软件组件的角色和功能更改。
如前所述,软件越来越成为产品创新的源泉。它是一种关键的系统集成技术,许多系统的寿命通过软件升级得到延长。在当前的军事采购环境中,“及时”的备件采购方法变得越来越普遍,任何软件更新机会通常都涉及增强功能,以延长系统的使用寿命或扩展功能,以及解决缺陷。随着硬件平台变得越来越强大,系统工程师将越来越多的功能分配给软件,以减轻重量、降低成本并提高灵活性。正是这些特性导致了军事系统中软件的数量和复杂性的急剧增长。
软件工程:不仅仅是即插即用
对于电子和软件以外的组件,处理过时主要是为组件寻找替代制造来源的问题。如前所述,对于软件,制造不是问题;组件过时需要重新设计软件,无论是解决缺陷还是扩展和增强其功能。
如前所述,导致软件过时的因素之一是软件必须运行的环境的变化——包括平台和与之交互的信号,以及软件启用的系统的目标和角色。在重新设计软件组件时,需要考虑这种情况,而且往往没有得到适当的解决。
软件复杂性的快速增长、在系统工程环境中更新软件组件的需求以及软件的无形性质都带来了更新和维护软件组件的挑战。支持开发更复杂软件的相同高级语言抽象也增加了隔离缺陷和确定提议更改的影响的挑战。
传统上,用于软件组件维护的技术数据包侧重于源代码,将其作为与最终软件组件最密切相关的工件,而不太强调其余的软件工件,并且工件之间的凝聚力很小。如果需求、设计、实现和验证工件之间没有完全的可追溯性,就很容易错过需要考虑的细微依赖关系。软件组件源代码的战术“修补”可能导致软件的单一、难以维护。需要对软件组件采取更具凝聚力、更全面的方法来正确管理其复杂性。这种方法称为应用程序生命周期管理 (ALM)。ALM 管理定义、设计、实现和验证软件组件(以及这些工件和活动之间的关系)所需的所有工件和活动。
征服史诗般的挑战
虽然嵌入式软件的增长是一个挑战,但它也是一个巨大的机会,特别是在当前的军事采购环境中,需要成本控制和战略优势。软件开发原则、实践和工具正在成熟并不断改进。以下建议可以大大有助于应对组件过时带来的软件挑战:
采用系统工程方法进行电子和软件组件开发,对模块化组件进行深思熟虑的规划和架构,以支持跨不同系统的重用,并在组件之间定义明确的接口来管理复杂性。确保在使用这些组件的系统使用寿命内捕获和管理驱动组件定义的需求和关键设计决策。
实施全面的 ALM 方法来开发软件组件,对所有工件和活动具有完全可追溯性,并具有管理开发各个方面的一致流程。投资工具以自动化和实施 ALM 实践;寻找提供单一流程引擎来管理所有工件的系统,这些系统与系统工程和硬件工程(如 PLM 系统)有着密切的联系。管理整个工具链,包括构建和发布管理系统,以确保在维护或更新软件组件时获得可预测的结果。
使用迭代和增量开发实践来缩短反馈周期,并提高组件发布的可预测性和质量。在组件更新中涉及所有学科(硬件和软件),以确保理解并完全解决组件之间的任何依赖关系。实施主动变体管理,以最大限度地重用组件并控制变体来源,例如更改角色或技术。
有了这些建议,军事系统设计人员可以使用软件来区分变体而不是硬件,从而可能降低成本,减轻重量和功耗。制造商发现,基于通用硬件平台设计产品,该平台能够支持所有产品线变体功能,同时使用软件创建单个变体,具有许多优势。
审核编辑:郭婷
全部0条评论
快来发表一下你的评论吧 !