近日,SpaceX软件团队在Reddit上发起了AMA(Ask Me Anything)活动,团队中的6名成员在线回答网友关于Dragon、软件以及在SpaceX上工作的任何问题。

该团队帮助开发和部署了可以用于Dragon的软件,并为SpaceX的人类航天演示任务(又名Crew Demo-2)提供了触摸屏显示器。这一活动吸引了上千名网友参与讨论,累计互动量近万。本文基于团队回答的内容,整理归纳为19条SpaceX技术干货,一起来看看吧!

1、运行平台为linux

(1)配置:就Starlink的某种规模而言,每发射60颗卫星就包含4000多台Linux计算机。“星座”目前在太空中有3万多个Linux节点(和6000多个微控制器)。因为我们与Falcon和Dragon共享我们的很多Linux平台基础设施,他们从我们超过180多年的在轨测试时间中受益。

(2)系统:应用了PREEMPT_RT补丁,以获得更好的实时性能。不使用任何第三方发行版,但保留了自己的内核和相关工具的副本。这些年来,我们对内核做了一些小的修改,尽管大部分都没有修改过。唯一的例外是添加了几个自定义驱动程序来与我们的硬件接口。我们使用多种硬件架构。

2、每天产生超过5TB的数据量,在轨检测问题可减少发送的数据量

对于Starlink,我们现在每天产生超过5TB的数据!我们正在积极减少每个设备的发送量,但我们也在迅速增加系统中的卫星(和用户)数量。就分析而言,在轨检测问题是减少我们需要发送和存储的遥测数据量的最好方法之一(只在有趣的时候发送)。我们使用的报警系统是Starlink和Dragon共享的。

3、设置了卫星的冗余策略,以发射更多卫星作为核心竞争力

在Starlink上,我们设计了这样一个系统,在卫星失效的情况下,卫星会由于大气阻力而被动地快速脱离轨道(尽管我们努力在可能的情况下主动脱离轨道)。我们在飞船内部仍然有一些冗余,这很容易,也很有意义,但我们主要相信系统级的容错能力:多颗卫星可以为用户服务。发射更多的卫星是我们的核心竞争力,所以我们通常在任何可能的地方使用这种容错,它让我们在大多数没有问题的时候提供更好的服务。

4、采用web开发的模式开发卫星星座,做了很多定制的ASIC开发工作

对于Starlink来说,我们需要把我们的卫星看作是数据中心的服务器。有些需要绝对确定(命令、软件更新、电源和硬件安全)的测试,会用到特定的用例。对于其他很多事情则采用类似于web开发的方法,可以在一小部分卫星上部署一个测试构建,然后与其他卫星进行比较。可以不停地发现问题、暂停、回滚,然后再试一次。比如,一个在轨卫星出现了从未想到过的故障,但是它能够保证自身的安全,就可以有足够长的时间来调试它,找出解决办法或解决办法,并进行软件更新。spaceX在Starlink项目中做了很多定制的ASIC(特殊应用集成电路)开发工作。

Starlink的硬件非常灵活——它需要大量的软件才能工作,软件上的小改进可以对提供的服务质量和服务人数产生巨大的影响。倾向于每周更新运行在所有Starlink卫星上的软件,同时也进行一些小规模的测试部署。地面系统或设施倾向于每周部署几次或更多。

6、卫星长时间未收到地面信号时会因阻力被拉下轨道

如果卫星长时间没有收到地面信号,它们就会进入高阻力状态。这使得大气阻力以一种非常可预测的方式将它们拉下来。

7、Falcon9和Dragon之间有什么样的控制程序,使用什么通信连接

有许多计算机在载具上,每个都建造和配置最适合它的任务分配。它们都在时间上同步运行,飞行计算机监控所有的动作。几乎所有的东西都可以表示为一个实时控制循环: 读取一些传感器,做出一个决定(传感器和过去状态的组合) ,然后将决定的输出返回到硬件。这种情况每秒发生很多次。

8、在 Falcon9上运行的控制软件是同一个源代码,但会定期更新,并且在每次任务中加入新代码

我们在每次任务中都会在 Falcon 上运行相同的源代码,尽管我们仍在定期更新软件,并且通常在每次任务中都会有新的代码。我们还对其他工程团队提供的软件有信心,这些团队通常会改变每个任务。这些修改包括状态机、容错阈值、发射日风等,这些都是软件用来操作飞行器的。

9、自动飞行安全系统软件的工作原理

自动飞行安全系统(AFSS)软件运行在一组独立于飞行计算机的微控制器上。它直接接收传感器输入(例如 IMU 测量)以及飞行计算机的一些计算输入。任务数据加载配置 AFSS,在这种情况下可能需要终止飞行,如火箭偏离轨道,失去所有加速度等。

10、Falcon/Dragon使用的开源软件

 Linux kernel、Chromium、Das U-Boot, Buildroot, MUSL. Outside of the OS 、 the Crew Displays software

并没有使用很多外部软件,而是尽量保持程序简单、精简,并且基于开发团队自始至终理解的代码。

11、发射日当天Falcon/Dragon的软件工程开发团队做什么工作?

主要还是在飞行前的模拟场景中承担大量工作。

名义上它是支持/双重检查的能力。在任务开始之前,我们花了很多时间研究实时飞行器的数据,在飞行的所有重要阶段,我们都有任务控制中心的软件人员,以防万一。我们有一个伟大的任务培训团队,让我们的任务控制操作员在飞行前的模拟中与各种各样的场景进行竞争。

12、开发F9和Dragon软件的相关解答

(1)所有自有的应用级软件都是用c++编写的,采用面向对象编程技术

(2)使用开源库,主要是标准c++库,再加上一些其他的。只使用高质量的库,并且在可行的情况下经常选择开发自己的库。

(3)飞行软件使用c++,测试使用python。显示使用HTML、JavaScript和CSS,并大量使用Web组件。

(4)显示:目前在“猎鹰”和“龙”任务控制中看到的地面显示是基于LabVIEW的,但我们的机组人员显示和未来的“星舰”地面显示是基于web堆栈的。

(5)测试软件的方式:能想到的所有方法!

①单元测试、包含的集成测试(您可以在自己的机器上运行这些测试,并进行完整的物理模拟),以及在实际飞行硬件上进行完整的“HITL”(半实物)测试——同样是完全模拟的。

②对于每一个飞行器,我们在回路模拟器中都有一个硬件(所有的飞行关键硬件加上模拟物理和传感),在将其部署到生产的飞行器或用于飞行之前,我们对其进行了大量的测试。

③手工验证和文档化我们的新特性,以确保它们按照预期工作

④通过CI系统持续运行这些测试,并运行自动数据检查,以确保不会出现意外行为。

13、在飞行过程中进行错误检测和纠正的方式

(1)计算机中的辐射引起的误差:通过使用多个冗余计算机并对其输出进行投票来处理。故障计算机可以重新启动和重新合并到系统中,一旦它恢复,这恢复原来的容错。

(2)传感器中的错误:通过使用多个不同的传感器来处理。为了校正/检验传感器数据,在一些应用中使用卡尔曼滤波器(Kalman filters),还为许多传感器采用了更简单的方法,比如基本的健康检查或低通滤波。

(3)数据传输中的错误:通过附加在有效载荷上的错误检测或错误纠正码来处理的。

14、为了飞行中的应急,把所有东西几乎都准备了三份

在我们的软件中,偶然性以多种形式出现。如上所述,我们几乎把所有东西都翻了三倍,这样我们就能容忍猎鹰上任何一台飞行计算机、传感器、驱动器等的丢失,而龙上任何两台都可以。在系统层面上,“猎鹰”和“龙”的设计是为了让引擎作为推进器的损失可以被容忍,而我们的算法可以进行补偿。我们还可以向状态机添加某些偶发事件。例如,Dragon状态机被设计成在观察到某些故障时自动从方法切换到爆发。

15、整个软件团队都从Bob和Doug那里得到了关于软件各个方面的反馈

虽然Bob和Doug主要关注的是显示器、按钮面板和音频系统,但他们也对整个软件的工作方式非常感兴趣,特别是在紧急情况下可能需要的备份功能。他们的反馈对改善这个系统是非常宝贵的

16、Dragon不使用任何人工智能,但使用了一些计算机视觉来导航

17、跟踪代码性能的方式——使用持续集成系统

使用一个持续集成系统,这样我们的代码就会一直被测试,但我们也会实时分析这些数据,以确保我们的性能指标在预期的范围内。这些案例是这样设置的,如果我们违反了任何关键性能指标,案例就会“失败”,工程师会查看。

1、对于安全性,通常有许多层。

(1)设计了对用户数据使用端到端加密的系统,以降低入侵卫星或网关对希望拦截通信的攻击者的作用。

(2)系统中的每一块硬件(卫星、网关、用户终端)都被设计成只运行我们签署的软件,因此即使攻击者闯入,他们也无法获得永久的立足点。

(3)加强系统的内部(包括我们数据中心的服务),使某一领域的漏洞更难以被其他地方利用。

2、使用传统网络安全保护我们的公司网络,监控网络内外的威胁,钓鱼活动等等。我们还需要分析针对我们的载具的潜在攻击,特别是围绕命令路径和最终到达载具上的代码。我们有一个专门的团队来识别我们的载具和卫星是如何被黑客攻击的,这样我们就可以在制造载具时消除或禁止这类威胁。我们还充分利用了对代码的静态和动态分析。

3、正在努力尽快建立一个bug奖励系统。

19、Dragon最有意思的功能

dragon可以与国际空间站进行复杂、精密的零重力会合,它还可以在大气层最厚的地方进行超音速、多重力的安全飞行。

发射逃生系统是dragon最酷的部分之一。同样令人惊讶的是在飞行中止试验。龙平稳地从 F9分离,打开了一个很大的分离距离,而 F9在它下面爆炸。

网友们还提出了一些有意思的问题,但是没有得到官方的回复,如果大家感兴趣的话,也可以在评论区与我们互动讨论~

1、Falcon 9第一步的嵌入式体系结构是什么样的,多少个微控制器?使用哪种总线来互连它们?这些硬件和软件的体系结构是否同质?

2、Crew Dragon的屏幕上是否有单独的芯片?如果该芯片仅用于从飞行软件接收数据并将其显示在屏幕上,SpaceX使用哪种协议或如何传输数据?如果该芯片用于自己执行一些逻辑和后端,SpaceX使用了什么工具?

3、Starlink在不同轨道平面上的卫星之间传递消息,大概是将激光瞄准特定的方向,但是,由于卫星之间可能存在一些问题会使情形变得更加复杂,或者需要处理卫星不活动等情况。SpaceX是否有现有算法可以帮助解决此问题?如何在地球上对此进行测试?

4、Dragon的逃生系统除了中止程序本身之外,是否还有其他任何预先编程的程序?在这种情况下,机组人员是否可以完全控制到达目的地?

5、SpaceX为什么不使用防辐射的计算机?虽然冗余(即容错和投票算法)可以使航天器应对辐射,但是仅适用于低辐射环境。如果在高辐射(3600雷姆)条件下,是否有(可能)消灭全部或大部分飞行计算机的潜力?

关心星链的朋友们,如果您有其他信息或不同见解,或者需要了解更多信息。可以联系我们

描述一下您需要的信息

信息来源

https://www.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/

相关阅读

starlink技术信息——技术瓶颈与技术冲击

解密Starlink的卫星设计——星链计划背后的技术支撑

Leave a Reply

Your email address will not be published. Required fields are marked *