美国国防部工业发展软件(软件采办系统国防部国防)「美国国防工业公司」

美国国防部工业发展软件(软件采办系统国防部国防)

作 者:赵翰林引子:美国软件的军备级竞赛要问地球上最上心的软件开发组织有谁,应该有微软谷歌、有NASA、有洛马、还有华为。
不过,这份长名单里还要加上一位:美国国防部。
以空军为先锋,美军正在向世界级科技巨头看齐打造超一流的软件开发组织,在Kessel Run实验室的示范带头下,美军的软件工厂遍地开花。
这个局面是在三股力量的交汇推动下形成的。
最上层是美国政界,在AI等软件密集型领域进行布局;中间层则是美国国防科学委员会、国防创新委员会、兰德公司等智囊咨询机构延续数十年的声音,认为软件采办的现代化是国防现代化的必由之路。
而最底层,则是美国国防部在类似于“战备压力”的氛围中,加快了新能力开发和武器系统现代化改造的步伐,而软件系统的开发、升级和维护是重中之重。
四十年的凝视与呐喊美军对军用软件的重视由来已久。
早在1982年,就已经充分认识到软件的重要性。
一个由Duffel领导的国防部联合特遣小组1982年在他们的报告开头说:"计算机软件已成为现代武器系统的重要组成部分。
它集成和控制了许多硬件部件,并提供了武器系统的多数功能。
由于软件的灵活性和相对较低的复制成本,它已经成为增加武器系统能力和快速应对敌人新威胁的首选手段”。
1987年,美国国防科学委员会军用软件工作组审查了包括Ada计划、STARS计划、DARPA的战略计算计划、软件工程研究所和战略防御计划在内的多项软件投资计划,指出军事软件开发的主要问题不是技术问题,而是管理问题。
2000年,美国国防科学委员会再次调研了军用软件开发项目,指出国防部软件开发项目相关的大多数问题都是由于缺乏纪律的执行造成的。
2004年,兰德公司一份149页的报告指出,美军亟需与私营企业竞争信息技术人才。
2009年3月,美国国防科学委员会在研究国防部信息技术采办政策时指出,传统的国防部采办过程太长太繁琐,无法适应大多数IT系统的需求,需要不断变化和升级。
工作组建议采用单独的流程采办信息技术系统。
2010年,一份关于国防软件生产力的研究报告指出,国防部持续依赖软件能力来完成其任务,必须在一些重要领域超越主流能力,在其他领域可以从商业成熟产品中获益。
2017年2月,软件工程研究所调研了美国国防部软件维护生态系统,指出国防部已经处在一个关键转折点上,它需要处理这样一个现实,即软件维护不是关于维护,而是关于生命周期的连续系统和软件工程,以演进软件产品基线。
报告建议改变软件采办范式,以实现应对快速变化的技术环境所需的创新,特别是通过对人力资本的投资,更好的软件维护性能度量,以及对软件组合更好的可见性。
长期呐喊,回音微茫。
直到近年来,“软件定义世界”渐成共识,随着两份国防科学委员会和国防创新委员会两份重磅报告的出台,才终于将言论转化为政策,将势能变成了动能。
作为“采办对象”的软件作为采办对象的软件范围广泛,既有现成的、非定制的商品现货软件,又有运行在定制硬件上的高度专业化的嵌入式软件。
为每种类型应用正确的工具和方法是至关重要,所以有必要厘清软件分类的关键问题。
首先要看计算平台。
软件运行在计算平台上,常用的计算平台包括云计算平台、客户端、服务器计算平台、台式机/笔记本电脑/平板电脑平台以及嵌入式计算平台。
云计算平台提供的算力通常与计算机硬件所在的位置不相关。
这样的系统通常运行于商业硬件上,并使用商业操作系统,即使底层硬件发生变化,在这些系统上运行的应用程序也会照常运行。
云计算系统的硬件和操作系统通常对应用程序及其用户是透明的。
客户端/服务器平台的算例通常由计算中心和本地计算机的硬件资源组合提供,这些系统通常运行在商业硬件上,并使用商业操作系统。
台式机/笔记本/平板电脑的算力来自于本身的单一系统,通常会与网上的数据源进行交互,这些系统通常运行在商业硬件上,并使用商业操作系统。
嵌入式计算通常与物理的、定制的硬件平台紧密关联,具有特殊的特性,需要在软件和硬件之间进行仔细的集成。
谈软件绕不开计算平台,这是软件兼容性要重点考虑的问题。
每种类型的软件系统在更新速度、所需的信息保证级别以及将参与软件开发、测试、定制和使用的组织方面都有不同的需求。
不同类型的软件可能需要不同的法规、规章和流程。
其次是操作功能,软件有什么用?按操作功能分类,美国国防部要采办的软件可分为企业系统、业务系统和作战系统。
这种分类维度,类似于我们在进行信息化建设时所说的公网/集团网、内网/企业网以及专业应用。
企业系统是用于国防部或同等级别的大规模软件系统,旨在管理大量用户,并连接大量其他系统。
这些系统应该始终运行在云中,并且拥有允许互操作性、可扩展性以及高可靠性的架构。
在大多数情况下,这类软件应该是不需要修改底层代码的商业软件,根据国防部的应用场景进行配置,例子包括电子邮件系统、会计系统、差旅系统和人力资源数据库等。
业务系统本质上与企业系统相同,但规模略小,是在各军种和部局内部运行的系统。
业务系统也应该是客户操作的、可扩展的、可靠的,也有可能基于商业产品,可以根据各军种和部局的业务需求定制功能,例子包括软件开发环境、军兵种专用的人力资源、财务和物资系统。
作战系统是国防领域特有的软件应用,用于支持作战行动。
作战系统在很大程度上是定制的,并强制要求具备网络攻防能力,使它们能够在受到网络攻击时依然能够发挥作用。
作战系统可进一步细分为后勤系统、任务系统和武器系统。
后勤系统是用于追踪作战物资供给和运输的系统,后勤系统很可能运行在商业硬件和操作系统之上,允许它们构建于商业现货技术基础上。
任务系统是用于规划和监视正在进行之作战行动的系统,这类软件通常使用商业硬件和操作系统,可能在云中运行,也可能在本地服务器上运行。
但即使是在比如说空战中心这样的本地运行,它们也会至少在关键功能方面采用大量的云技术。
这样的系统应该能够紧跟作战环境的变化速度,能够在几天到数月这样的时间范围内升级合并新功能。
武器系统是能够投送致命力量,或用作武器作战一部分的直接支持系统(火控软件)。
传统上,武器系统的软件和硬件是紧密绑定的,但是随着转向由软件定义系统和分布式智能带来的更高可靠性,武器系统的软件正变得越来越独立于硬件,这就和智能手机的操作系统很相似,比如说安卓系统能够运行在许多不同的硬件平台上。
软件在防务系统中的重要性与日俱增,现代化水平越高的军队越离不开软件。
美国国防部和美军运营和使用的所有物体中都有软件。
软件现在定义了军队遂行任务的关键能力,以及感知、共享、整合、协调和行动的能力。
软件驱动了武器系统、指挥控制和通信系统、情报系统、后勤系统以及各种基础设施。
软件驱动了行政部门和作战部门的业务流程和组织流程。
在网电域作战,部队的态势感知以及对抗、防御和应对威胁的能力都将基于软件能力。
在这个作战域,软件既是使能者,也是作战目标。
随着军用系统越来越网络化和自动化,随着自主系统变得越来越普遍,随着作战变得越来越依赖于机器学习和人工智能,美军维持压倒性优势的能力直接与部署和维护比对手更好、更智能、更有力的软件的能力挂钩。
防御新型物理学和动力学武器的能力,诸如高超音速、高能武器和生物武器的能力也将基于软件能力。
当新威胁发生时,需要立刻几乎同时地识别并作出反应。
美军即时识别并响应这些新威胁的能力取决于开发并推送由软件定义的新能力,软件升级足够快,才能以在时间尺度上大大超越对手的水平来应对这些威胁。
图1 商用飞机和军用飞机源代码行数的变化(来源:网络素材,略作汇编)航空航天系统软件复杂性的增长是软件定义军事装备的一个缩影。
飞机的源代码(SLOC)大约每四年翻一番。
这种趋势已经存在了至少50年,既适用于商用飞机,也适用于军用飞机。
由于软件系统的开发成本随着SLOC呈指数级增长,成本正以惊人的速度增长。
对民用飞机来说,A-310在1983年推出。
五年后,A-320拥有两倍的机载SLOC,需要2.14倍的开发努力。
又过了五年,A-330拥有比A-320多2.5倍的机载SLOC,估计需要2.7倍的开发努力。
B-757于1982年首次试飞。
5年后,B-737-400拥有1.9倍的机载SLOC,需要2.7倍的开发努力。
在接下来的5年里,B-777的SLOC是B-757的21倍,估计需要28.5倍的开发努力。
对军用飞机来说,F-16于1974年首次试飞。
20年后,F-22拥有126倍的机载SLOC,需要估计204倍的开发努力。
F-35于2006年底首次试飞,其SLOC是F-22的1.4倍,是F-16的177倍。
F-35的软件开发工作估计比F-22多1.5倍,比F-16多298倍。
在32年的时间里,软件开发成本增加了近300倍。
面对像软件这样重要的问题,美国人整体上呈现出一副“杠精”的态势,这种气质一言以蔽之就是“自己的体制是束缚,别人的成绩是威胁”。
美国国防部认为美国软件能力的领先地位受到不可忽视的挑战,“背锅的”依然是中国。
按照美国国防委员会报告中的说法,如果坐视不理,技术风险在短期内就会转化成战场失败。
如果对手的软件能力更强,就有可能更快的开发出新能力,并持续的更新升级,从而获得更快的防卫反击速度,如果对手的算法和人工智能技术更先进,就有可能在系统与系统的对抗中取得决定性的优势。
如果对手的网络能力更强,就有可能关闭我方网络,在我方网络制造混乱,窃取机密,而我方甚至无力留下证据。
总之,如果不能尽快做出改变,美军在工业时代积累的国防技术优势将在不到十年的短期内荡然无存。
开发、采办、保证、部署和维护软件的能力居于国防事业的中心位置。
美国面临的威胁正在以越来越快的速度发展变化,国防部适应和应对这些威胁的能力如今取决于快速地开发软件并将其部署到战场的能力。
目前的软件开发方法是国防部的主要风险来源,它耗时耗资,使作战人员因为未能及时获得确保任务成功所需的装备而承担无法接受的风险。
正如国防委员会主席、谷歌母公司alphabet董事会成员施密特所说:“如果国防部不采取措施使其软件采购和开发实践现代化,我们将不再拥有世界上最好的军队,无论我们投资多少,无论我们的军队多么有才华和敬业。
中国正积极利用其私营产业开发国家安全软件(特别是人工智能领域),招募18岁以下的顶尖学生从事“智能武器设计”,并直接从美国挖走软件人才。
在俄罗斯,弗拉基米尔·普京告诉学生们,人工智能是未来,不仅是俄罗斯的未来,也是全人类的未来。
谁成为这个领域的领导者,谁就成为世界的统治者。
美国能够而且必须在与软件和软件制造者的竞争中胜出,这不仅是为了保持美国的军事优势,也是为了确保软件所代表的力量是按照美国的价值观来使用的。
”基于这样的认识,以国防科学委员会和国防创新委员会的两份报告为蓝图,美国国防部和整个美军迅速开展了软件采办转型。
一旦投入行动,动作要快美国2018年国防战略提出采取流畅、迅速、迭代的措施,提高采办体系的反应速度。
2018年国防授权法案推动的国防部改组,设立了专门负责软件采办的国防部软件采办部长特别助理的职位;同时推动了为期一年的国防创新委员会“软件采办与实践”研究。
2018年2月,此前进行的国防科学委员会“防务系统软件设计与采办”研究项目结题,提出了包括设立软件工厂与机器学习监管验证与确认在内的七项建议。
2019年5月,“软件采办与实践”研究结题,提出了关于软件采办10项建议,要在美军全面推进DevSecOps,并制定了实施计划。
国防创新委员会的报告名为“软件永无完成时-面向竞争优势重构采办规则”。
在这份报告中,关注三个基础性主题:(1)速度和时间周期是软件管理最重要的指标;(2)软件由人们建造,为人们服务,所以数字人才很重要;(3)软件不同于硬件,且并不是所有软件都是相同的。
针对这三个主题,提出了四方面的建议。
一是重构专门针对软件的法规、规章和流程(包括采购、开发、保证、部署和维护),以消除以硬件为中心的瓶颈,同时提供更多的洞察力和更好的监督;二是创建和维护可互操作(跨程序/跨服务)的数字基础设施,使持续快速部署、扩展、测试和优化软件成为一种持久的能力;三是为数字人才创造新途径,并提高采办工作人员对现代软件的理解水平;四是通过采用现代软件开发方法改变软件采办和开发的实践。
这些建议随后由2020年度国防授权法案推动实施。
2020年1月,美国国防部5000.02指令改版,新的指令名为“适应性采办框架的运行”,开辟了能够反映敏捷迭代特色的软件采办路径,作为六种采办路径之一。
2020年6月,美国国防部发布了“软件采办路径临时政策与程序”,这是美军第一部专门的软件采办指令文件。
在短短不到三年的时间里,美国国防部为软件采办转型的政策大厦敲上了最后一颗钉子。
图2 美军软件采办转型从战略布局到指令实施的时间线(Source:网络素材)星罗棋布的“软件工厂”随着国防创新委员会软件采办建议的出台,尤其是2020年国防授权法案的发布,美国国防部组织美军各军种相关单位利用更现代的采办和开发实践,取得了显著的成功。
国防数字服务(DDS)、国防创新单元(DIU)、联合临时打击威胁组织(JIDO)和空军的Kessel Run项目都是证明国防部有能力交付世界级软件的例子。
其中最引人注目的就是代表着美国国防部实施devSecOps举措的“软件工厂”建设。
如果看过科幻电影《星球大战》与《星际迷航》,一定也能从这些软件工厂的名字看到美军赋予其中的面向未来挑战极限的涵义。
“Kessel Run”——快到不可思议的航程、“Kobayashi Maru”——不可能完成的训练演习、“BESPIN”——星球大战中的小行星。
软件工厂的尝试是从“Kessel Run”项目开始的。
在星球大战中,汉·索罗向欧比旺·肯诺比吹嘘他的千年隼号星舰,说千年隼号跑的非常快,能将克赛尔航程缩短至12秒差距。
美国空军将他们新设立的软件开发组织命名为“克赛尔航程”,也许是期望其能够表现的又快又灵活,就像千年隼号一样。
Kessel Run是从2018年开始独立运营的,但它的发端是在2017年的八月,是在DIU国防创新小组的支持下,从位于马萨诸塞州Hanscom空军基地的空军生命周期管理中心的空中作战中心AOC10.2武器系统现代化计划的灰烬中站起来。
AOC 10.2计划在10年里花费了4.3亿美元,最后被终止,用参议员约翰·麦凯恩(John McCain)的话来说,“没有提供任何有意义的能力”。
Kessel Run迅速洗刷了耻辱,在不到130天的时间里,Kessel Run在Al Udeid空军基地部署了一个认证的秘密互联网协议路由器(SIPR)原生云DevOps平台,然后在Shaw空军基地复制了这个实例,并在日本乌山空军基地部署了另一个DevOps平台,重点是他们很快就把这些软件投入到战场应用。
Kessel Run最初的使命是为当时的空军作战中心开发动态作战任务操作系统,操作系统必须提供现代化的软件平台,并且能够自动的支持第三方应用;与此同时,Kessel Run在签署合同的90天内必须至少交付6个相关应用软件。
但是,随着Kessel Run在短期内表现出的巨大价值,Kessel Run的任务很快就突破了团队最初创建时的范围,扩编为美国空军生命周期管理中心的一个独立特遣分队。
现在,Kessel Run的任务是“持续交付空军作战人员喜爱的制胜软件”。
相对于美国空军的传统软件开发组织,Kessel Run在软件开发绩效方面取得了巨大的进步。
观察数据显示,Kessel Run开发的软件从概念生成到战场部署的平均周期大约是四个半月,软件项目的策划和导入时间从大约五年缩短至三天半,有能力在发现漏洞的1小时内推送安全更新,平均每月开发并交付42项作战软件能力。
图3 Kessel Run软件工厂的使命任务Kessel Run取得了令人瞩目的成功。
时任美国空军部长希瑟·威尔逊(Heather Wilson)于2018年10月向国会提交了一份报告,描述了凯塞尔·Run迄今为止的成就。
她写道:“敏捷DevOps方法论的使用……证明是成功的,我们能够快速交付增加运营效用的本地云应用程序......我们相信我们已经证明了持续交付软件的能力,为作战人员增加价值”。
Kessel Run的成功为其他软件工厂踩出了足迹。
“我们正试图将这一信息传递给任何试图建立一个组织的人,这样他们就不会从零开始,”Kessel Run主任恩里克·奥蒂中校说。
“他们可以从我们的错误中吸取教训,希望能够更快地投入运营。
”追随Kessel Run的脚步,美国太空反导装备司令部于2018年在美国西海岸创立了名为“Kobayashi Maru(小林丸)”的软件工厂,这个软件工厂是在同样失败的“太空作战联合任务系统”的废墟上站起来的。
另外一个项目,则由太空反导装备司令部内部一个名为“31节”的团队领衔主打,以Kessel Run项目为模型,在洛杉矶建立软件工厂,并于范德堡空军基地的第18太空控制中队对接。
“31节”的名称同样大有来头。
来自《星际迷航》影片的根据一个编号为31的条款所创建的组织,“面对非常的威胁,必须采取非常的措施”是这个组织的座右铭。
在短短的三年多时间里,美军的软件工厂像雨后春笋般涌现,像星星一样洒遍全美各地。
根据美国空军网站公开信息,目前共有16个软件工厂投入运营。
图4 美国空军的软件工厂分布(Source:美国空军网站)小结马克·安德森2011年在华尔街日报专栏撰文,提出“软件吞噬世界”的观点。
他认为,在所有行业,推动变革的主要力量已经从“原子”转向“比特”。
而且“软件永无完成时”,软件是数字世界的基础,有数字世界,就有软件;软件演化,数字世界向前。
美军软件采办的转型,既是为美军数字转型扫清道路,也是为数字转型准备生产力基础。
这样的道路对于美军也许是合适的,对于其他国家却不一定合适。
“数字转型”转是要转的,但投入多少资源、选择什么样的技术、开发什么样的新产品、从什么样的场景切入,这些都是不同层面决策者和管理者需要深思熟虑的问题。
错过了,可能就是一个时代。
(本文观点只代表个人,不代表服务机构)作 者赵翰林:北京索为系统技术股份有限公司编 审林雪萍:北京联讯动力咨询公司总经理,上海交大中国质量发展研究院客座研究员

联系我们

在线咨询:点击这里给我发消息