航展畅想：从F35机载软件研发来看汽车车载软件研发

两款经典战机的机载软件

在这里插入图片描述

F-22和F-35战斗机的研制分别始于1980年代和1990年代末，F-22项目在1981年启动，主要由洛克希德·马丁（Lockheed Martin）和波音公司（Boeing）合作开发，以满足美军“先进战术战斗机” (ATF) 项目的需求。F-35的研发则开始于1996年，由洛克希德·马丁领导，同样与诺斯罗普·格鲁曼和BAE系统公司合作，以满足美军的“联合攻击战斗机” (JSF) 项目的需求。

F-35的代码量比F-22大得多，F-35的软件代码行数高达2500万，而F-22仅为约200万。这种差距的原因主要是由于两机型的任务和技术需求不同。F-22主要设计为制空战斗机，注重空对空作战，而F-35是多用途战斗机，不仅具备空战能力，还需要执行空对地攻击、电子战和情报侦察任务，这些任务需要更复杂的传感器融合和信息处理能力。

关于编程语言的选择，虽然F-22的核心代码使用了Ada语言，但F-35项目团队选择了C++。这部分是因为C++在商业和军事软件开发中变得更为普及，具有更广泛的支持和开发资源。而且C++相比Ada有更好的灵活性，可以更好地支持现代计算平台和硬件接口，符合F-35复杂任务系统的需求。因此，为了满足多任务环境下的模块化和扩展性需求，F-35的软件开发转向了C++而非延续F-22的Ada代码。

在这里插入图片描述

F35战斗机机载软件的几个重大问题

在F-35的研发过程中，出现了几个重大软件问题，影响了其整体性能和交付进度。以下是一些主要问题：

武器系统软件问题：在一些早期的软件更新中，增加新的武器功能时，导致之前已经正常运行的武器系统出现故障。例如，在为F-35增加其他武器系统的功能后，AIM-120先进中程空空导弹（AMRAAM）的相关功能出现问题。
持续的软件更新失败：F-35采用了“持续能力开发与交付”（C2D2）模型，计划每六个月交付增量的软件更新。然而，这一做法证明是不可持续的，常常引入稳定性问题，甚至影响到其他系统的正常运行。因此，更新的周期被延长至每年一次。
测试不足：由于资金和资源的限制，开发团队在软件部署前未能进行充分的测试、回归测试和数据分析，这导致一些软件缺陷和操作问题未能及时发现，通常是在实际使用中由作战单位发现。
技术刷新延迟：另一个重大问题是F-35的技术刷新（TR-3）延迟，原计划的更新被推迟了超过一年，这直接影响了飞机的交付进度。

这些软件问题反映了在将高度依赖软件的功能集成到战斗机中的复杂性。洛克希德·马丁努力解决了这些问题，致力于稳定软件和提高机队的可用性。

给汽车 车载软件研发的启示

上面所讲述的F-35的开发过程中遇到的重大软件问题为国内汽车车载软件研发提供了一些重要的启示：

持续更新与回归测试的重要性：

F-35采用的“持续能力开发与交付”（C2D2）模式，尽管初衷是希望通过定期小规模的软件更新不断优化系统，但这一方式未能有效避免新版本引入的稳定性问题。对于国内汽车车载软件而言，类似的情况同样适用。汽车软件，尤其是车载娱乐、自动驾驶和安全系统的更新（O TA），若过于频繁或未进行充分的回归测试，可能会导致新功能与已有功能的冲突，从而影响车辆的可靠性。因此，在进行软件更新时，必须加强回归测试，确保新功能不会破坏现有系统的稳定性。

资金与资源的保障：

F-35在软件开发过程中由于资金和资源不足，导致了许多测试未能按计划完成，进而影响了软件质量和交付进度。对于车载软件研发，尤其是涉及到智能驾驶、ADAS（高级驾驶辅助系统）等复杂功能时，充足的资金和资源投入至关重要。开发团队需要在前期阶段就确保有足够的时间和资源进行测试，尤其是对安全性和可靠性至关重要的系统。

系统的模块化与可维护性：

F-35软件中的一些问题是由新增的功能与已有功能的冲突引起的。这提醒我们，在汽车车载软件的设计时，模块化和高可维护性非常重要。如果一个新的软件模块的加入可能影响到其他系统的稳定性，那么必须设计合理的接口和清晰的模块划分，以减少不同模块间的相互干扰和兼容性问题。

确保“原始设计”的高质量：

F-35软件在设计阶段未能做到完全的完善，导致后期的更新不断修复问题。这表明，在初始版本发布时，软件的质量和稳定性必须尽可能接近最终需求。对于汽车车载系统，特别是在自动驾驶领域以及功能安全相关软件，过于依赖后续的修复和更新可能会带来严重安全隐患。因此，初期的开发阶段要确保软件系统设计的全面性和严谨性，减少后期修复的负担。