月球任务“ Bereshit”-事故分析,宣布启动“ Bereshit 2.0”设备开发


2019年4月11日傍晚是启动新项目“ Bereshit 2.0”的起点,因为首个私人设备在试图登上月球时发生的事故只会激怒工程师和SpaceIL组织。

空间是残酷的,月亮不能立即让自己坐下。 但是有了经验和现代技术,每一次新尝试都会变得更加成功。


Bereshit任务取得了哪些成功?

关于Bereshit任务的简要介绍:8年的发展,该项目耗资1亿美元,有200名志愿者科学家和工程师,飞行了47天,超过650万公里,克服了启动时的380公斤燃油,加速的LEROS 2b发动机,6个侧面摄像头,磁力计,激光角反射器阵列和一次着陆尝试,其中一台150千克重的装置以76公斤重的燃料(肼)在高速坦克中飞行,飞越了计划着陆的区域,跌落到了月球表面。

Bereshit装置在月球轨道上运行,着陆时使用了磁力计,并将有关月球磁场的一些科学数据传输给了MCC。

现在,以色列是将其航天器发射到月球轨道上的第七个国家(并在那里停留了7天)。

月球轨道上的设备所在的国家/地区列表(计算出第一个设备):

1.苏联Luna-10,1966年;
2.美国,1966年,月球轨道器1;
3.日本羽衣市,1990年;
4. SMART-1,欧洲航天局,2005年;
5. Chang娥一号,中国,2007年;
6. Chandrayan-1,印度,2008年;
7.以色列,贝雷什特,2019年。

然而,现在以色列是第七个将航天器降落在月球表面的国家(尽管在着陆过程中,这变成了无法控制的致命坠毁)。



假设形成的弹坑的直径从3米下降到5米。 Bereshit装置以小角度(〜8°)撞入月球表面,火山口可以拉长。

Bereshit设备的组件成本( 从此处拍摄的图片 ):



任务和登月车“ Bereshit”的主要特征:
-任务开始:2019年2月22日;

-任务结束:在2019年4月11日着陆的最后阶段坠毁在月球表面;

-登月运动的轨迹(实际上是最大的可能):通过执行一系列动作(打开引擎几秒钟或什至几分钟)以增大其绕椭圆形座垫的顶点的复杂度,可变性;

-Bereshit仪器的高度约为1.5米,直径为2米(着陆支架之间为2.3米);

-带燃料的重量530公斤(燃料重量-380公斤),不带燃料的重量为150公斤;

-主机:LEROS 2b的修改;

-车载计算机的主要组成部分:双核处理器Gaisler HiRel GR712RC;

-六台具有光学Ruda的8百万像素Imperx山猫B3320C相机;

-科学仪器:磁力计,激光角反射器阵列。



Bereshit装置是由SpaceIL组织开发的,主要由私人投资者支持,其中包括美国大亨谢尔登·阿德尔森(Sheldon Adelson)和亿万富翁莫里斯·卡恩(Morris Kahn),他们也是以色列最大的公司之一Amdocs(DOX)的联合创始人。

仅靠一个小型私人公司的力量和手段就不可能将登月装置送入太空,但是在国际太空界的帮助下,您可以将这一构想变成一个正在实施的成熟项目。

参与Bereshit任务的项目参与者:

-来自SpaceIL的一组年轻的以色列科学家和工程师,

-NASA(美国),

-ISA(以色列航天局),

-IAI(以色列航空业关注的问题),

-Spaceflight Industries(美国,Bereshit装置发射进入轨道的组织者),

-SpaceX公司(美国,猎鹰9号助推火箭),

-瑞典航天公司(Swedish Space Corporation),

-Cobham公司(瑞典),

-Ramon Chips公司(以色列)。



毕竟,按照国际标准,SpaceIL是一个小型组织,拥有约200名员工,其中大多数是志愿科学家和工程师,他们“致力于促进以色列科技进步的发展”。

在2019年4月11日Bereshit设备登陆期间发生了什么?

实际上,Bereshit设备的问题几乎在发射后立即开始。

2019年2月:

向传感器照射设备的位置(传感器对这种“眩光”非常敏感),这可能会影响设备在空间中的方向。

解决方案:进行软件补偿以处理来自传感器的数据并降低其灵敏度,并对设备传感器的新数据进行了多次检查。

在准备阶段,在执行第二次引擎操纵之前,Bereshit车载计算机意外重启,并且操纵执行阶段被自动取消。 SpaceIL和IAI工程师开始分析情况。
机上有一个问题限制了设备的可操作性。

解决方案:SpaceIL和IAI工程师修复了Bereshit设备的计算机系统故障,现在Bereshit设备以正常模式继续向月球飞行。

此外,SpaceIL并未宣布Bereshit装置出现新的故障或问题 ,但是,在登月演习之前,该报告具有这样的幻灯片,即不列颠哥伦比亚省的工作有多次重启/失败-甚至超过工程师的预期,以及恶劣的太空环境。

空间中存在的问题和解决方案(事实证明,BC进行了多次重启):



因此,可以预期的是,经过1128小时的飞行(47天)之后,Bereshit设备内部组件的问题可能会致命,并且如果元件失效或在重负荷和太空环境的影响下它们无法正常工作,则无法进行校正。

设备在月球上的着陆是一个复杂的过程,其中机载计算机执行大量任务:控制引擎的运行模式,分析遥测和来自传感器的数据(位置,高度,速度,着陆等),根据着陆路径调整设备的当前位置和实际坐标,自适应油耗,使用通信系统的数据传输。

如果在着陆过程中一个或多个传感器发生紧急情况,那么如果有备用电路,则可以自动补偿这一时刻;如果有时间,可以通过重新启动(重新引导)车载计算机系统来补偿。

在手动模式和实时模式下,MCC的工程师没有控制Bereshit设备,当设备退出“不返回点”时,机载计算机就降落了,这时只需要执行着陆程序即可,该命令先前已由机载计算机接收。

但是要考虑到这种情况,并在多个元件级联失效时进行补偿,然后由于这些元件的故障,设备的主要组件(引擎,遥测系统,车载计算机)将关闭-这对于这种级别的设备(没有冗余控制系统)也很困难实践证明,这是不可能的。

关于Bereshit设备的硬件和软件组件还有什么其他了解

-一(1)台430N推力发动机和八(8)台25N推力发动机。 降落时使用了调车引擎来帮助主力。

-电子设备的温度保持在-10°C至+ 40°C的范围内。 大部分电力都用于加热电子设备(无冷却系统)。

-车载计算机为一(1),不可重复;

-定向Bereshit装置的恒星传感器配备了一个用于吸收第三方射线的黑色锥体,但是,当Bereshit装置在启动后与卫星分离时,发现锥体很脏,工程师们解决了这个问题,找出没有发生反射的角度并引入了调整用于处理传感器数据的软件算法(使用软件补丁);

-在飞往月球的过程中有几次计算机重启;

-用C语言控制程序代码,命令并与车载计算机一起工作;

-由于只有一台计算机,因此在重新启动时,所有更新(补丁)都将被删除,并且需要再次将其重新下载到系统中;

-低数据传输速度:一张高分辨率照片(来自8 Mpx相机)加载40分钟;

-DLR(德国航空航天中心)测试了Bereshit航天器的着陆机制。

SpaceIL团队:他们大多数是航空工程师和物理学家。 但是,还有一些年轻的成员接受了IDF卫星作战部门的培训。

Bereshit硬件系统,其故障可能导致着陆程序各阶段的异常执行并跌倒:


设备“ Bereshit”的引擎。

Bereshit装置的发动机是LEROS系列的特殊改装(为缩短Bereshit任务而进行的改进,通过缩短喷嘴和增加推力进行了改进)化学导弹装置(用于卫星平台)-对肼(一甲基肼)进行了LEROS 2b的改进,推力为45 kgf(441H),略高于其常规特性41.5 kgf(407H)。





可以假设该发动机不是为多次启动而设计的,也没有节流,尽管在Bereshit任务期间,主引擎在几分钟内有多次启动,在着陆期间是数十分钟。

调车发动机的总推力为8 * 25H = 200H(主机的一半)。 也就是说,当主机关闭时,推力将下降三倍,这是在着陆期间观察到的。

还记录了着陆期间的发动机停机情况:

Bereshit装置降落的多普勒曲线 ,大约在19:19制动几乎停止了:



车载计算机。



Cobham Gaisler的HiRel GR712RC处理器

作为车载计算机的主要元件,Bereshit设备使用了Cobham 双核Gaisler HiRel GR712RC处理器

从技术上讲,该芯片基于LEON SPARC,并使用独特的抗辐射硅技术制造。

SpaceIL成为该处理器第一个客户, SpaceIL工程师在Bereshit设备上实际交付和交换之前为其编写了专用软件。

GR712RC是双核处理器LEON3FT SPARC V8 它可以在整个军事频率范围内以高达125 MHz的频率运行。 这提供了高达300 DMIPS和250 MFLOPS的峰值性能。 集成了高级接口协议,包括SpaceWire,CAN,SatCAN,UART,1553B,以太网,SPI,I2C,GPIO等。 它具有用于外部存储器SDRAM / SRAM / PROM / EEROM / NOR-FLASH的高速接口总线。 经验证的抗辐射性-高达300度。 低功耗。





根据更新的数据,该处理器使用最常见的商用技术(以色列制造的TowerJazz 180 nm)制造,与电热水壶的控制器大致相同。 由于元件的电路和拓扑结构,在确保快乐的同时不会干扰技术,这比专门开发制造工艺要便宜一到两倍。

由于空间环境(辐射,温度)的影响,Bereshit装置的车载计算机在着陆之前已经重新启动了几次。

TT&C。

此项目中使用的跟踪,遥测和命令子系统(TT&C-跟踪,遥测和命令子系统)系统在最后的着陆阶段“挂”了两(2!)次,尽管其状态为“确定”

遥测数据窗口中的Bereshit设备的传感器和系统元素:



遥测系统如何挂起:





根据遥测数据,这是MCC工程师着陆时看到的内容:

正常着陆模式:











在这里,问题已经随着发动机停机,遥测数据的“冻结”和异常的速度读数而开始,这在设计高度上应该是完全不同的。

















23:03遥测指示灯变为绿色。 子状态是方向。

25:04子状态更改为“制动”。

25:20“我们已经超越了无可挽回的地步。”

25:26“不返回点”指示器变为黑色。

25:52垂直速度显示变为绿色。

28:16遥测指示器不再为绿色。

28:20遥测指示器暂时变成绿色,然后不再是绿色。

29.37距离显示为210公里。

29:50距离更改为385公里。

30:03距离更改为370公里。

30:40遥测指示灯为绿色。

30:51距离是314公里。

31:33显示Beresheet自拍。 海拔约22公里 遥测为绿色。

31:50遥测指示器不再为绿色。

31:55至32:29“ [听不清]杀死它。” “ [听不清任务的ter不休]忙。”

32:48显示遥测屏幕。 遥测指示器为浅黄色。 海拔是14095 m。 水平速度为955.5 m / s。 垂直速度为24.8 m / s。 主机已启动。 水平速度为浅黄色。 除遥测指示器外,其他参数为绿色。

32:49所有引擎都打开。

32:51所有引擎都关闭。

32:55主机已打开。

32:57所有引擎均已启动。

32:59主机已启动。 距离是183.8公里。

33:01-33:03“ IMUstein不好。”

33:02所有引擎都打开。

33:05主机已启动。

33:07所有引擎都打开了。

33:09主机已启动。

33:11所有引擎都打开了。

33:13主机已启动。

33:16所有引擎都打开了。

33:20遥测指示灯变为绿色。 所有引擎均关闭。 所有显示均保持静态(不变)。

33:32遥测指示器不再为绿色。 所有引擎均关闭。 所有显示均保持静态(不变)。

34:24遥测指示灯变为绿色。 所有引擎均已关闭,但据称已打开。 Z轴上的垂直加速度固定为0.6。 “目前,我们的惯性测量单元之一存在问题。” 垂直速度开始稳定增加。 海拔持续稳定下降。 Z轴上的垂直加速度固定为0.6。 主机可能没有启动。

遥测指示器间歇性地变为绿色,然后变为浅黄色,直到下一个视频时间戳记为止。

34:56遥测指示器不再为绿色。 尽管所有引擎均显示为开启,但垂直速度继续增加。 Z轴上的垂直加速度保持固定为0.6。 主机可能没有启动。

36:25-36:33“我们的主机似乎有问题。 我们正在重置航天器以尝试启用引擎。”

36:40遥测指示灯为绿色。 所有引擎似乎都处于开启状态,但Z轴加速度保持固定为0.6 m / s。 海拔678米。 水平和垂直速度分别为948.1 m / s和130.1 m / s。

36:44最后的遥测数据。 遥测指示灯为绿色。 所有引擎似乎都已启动。 Z轴加速度变为0.7 m / s。 最终高度为149米。 最终的水平和垂直速度分别为946.7和134.3 m / s。 主机似乎无法正常运行。

根据MCC的数据,设备使用寿命的最后4秒(从678米减少到149米):









在19:23,遥测数据完全停止到达。

以前-问题是在14公里的高度开始出现的,着陆过程中主机关闭了,重启后为时已晚-设备无法正确制动,这种故障导致高速下坠并从150米高处坠落到月球。

惯性方向单元(惯性测量单元-IMU1,IMU2)-节点重复。

但这很有趣,因为这里使用了两个模块,并且它们的数据对于车载计算机非常重要。

早在2016年,由于此类模块的故障,就发生了事故-如2016年火星上的Schiaparelli装置。

事实证明,由于“惯性表”(IMU)的操作出现问题,Skiaparelli软件的操作发生了致命错误,该设备测量模块围绕其轴的旋转速度。

正如工程师解释的那样,在处理来自Schiaparelli雷达的高度数据时,已考虑到了该设备的数据。 有一次,IMU崩溃了,结果是它“测量”了渲染的异常高的旋转速度,超出了允许的值。 这种故障是惯性传感器运行中的常态,通常为了抑制故障,科学家们“平滑”了信号,并将当前时刻的数据与过去获得的结果进行比较。

但是在这种情况下,IMU意外地长时间将数据传输到Schiaparelli主机,一秒钟,这“欺骗了”模块软件,并迫使其将这些测量结果视为真实数据,而不是异常现象。 在计算模块高度时,会考虑到不正确的值,因此,Skiaparelli车载计算机会收到负高度值。

该模块认为它甚至不在火星表面,而是在其下方,这迫使他在3.7 km的高度启动着陆程序的最后阶段,以分离降落伞并关闭发动机。

设备Bereshit使用了以下IMU模块: STIM300



该模块具有低辐射防护特性,因此以后在新任务中,SpaceIL工程师可能会进一步考虑在月球上使用此类设备。

事故发生后,SpaceIL发表了一个声明: “ Beresheet的惯性测量单元之一出现了问题。 地面控制器暂时失去了遥测功能,但重新获得了遥测功能。”

确实,Bereshit IMU模块(或两个模块)为车载计算机提供了不正确的数据(包括不可能测量角加速度和线性加速度),以及出于什么原因-SpaceIL工程师仍在对此进行调查

但是,到目前为止,很明显Bereshit航天器的其中一个部件发生了技术故障,导致发动机关闭,阻止了航天器降低下降到月球表面的速度。

当引擎重新启动时,它们无法再进行完全制动,事实证明,车辆的速度太高,到月球表面的高度大大降低,并且发生了破坏性的碰撞。



Bereshit相机的最后一张照片也有些令人困惑。 因为它显示的是距澄澈海计划降落区1000公里的月球表面。

Bereshit装置的最后一帧(正式发布)(从8 km高处拍摄):



因此,由于搜索区域非常广泛,因此很难从Bereshit设备中找到至少一些东西:



尽管看起来比较清楚(距阿波罗11号登陆区200公里):





NASA计划使用LRO探针检查Bereshit装置的撞击区域,希望激光角反射器阵列的元件不会塌陷并位于月球表面。

反射器固定在设备的上部,当其坠落时,可能会在月球土壤中弹跳,散射,翻滚和挖洞。但是,即使只有部分反射器可用来反射光脉冲,这也将由LRO固定。

LRO激光高度计(NASA月球探测器)旨在编辑高度图,它将激光脉冲发送到Bereshit入射点的角反射器,然后测量光返回的时间。

使用这种技术,NASA和SpaceIL工程师计划能够找到Bereshit设备的残骸。



尽管在这里也很有趣,但仍有SpaceIL跌落的照片,但它们没有发布:

- 这真的是从Beresheet收到的最后一张照片吗?到底是什么时候服用的?我问是因为Hypatia火山口比计划的登陆点更南。

- 不,这不是最后拍摄的照片。我们有一张照片是在降落时拍摄的,但尚未确认是否发布。我认为它将很快发布。


Bereshit任务接下来会发生什么? 以色列

宣布了一项新的航天项目,即Bereshit 2.0,



以色列总理本杰明·内塔尼亚胡(Benjamin Netanyahu)承诺,该国将参与第二次尝试将自动发射台送上月球。

“我们将发射Bereshit-2。以色列国参加了第一个航天器的发射,并将参加第二个航天器的发射。我希望这次一切都会成功。内塔尼亚胡在一次政府会议上说,在这种情况下,我们确实将成为世界上第四个登上月球的国家。

按计划,Bereshit 2.0项目将更加严肃和昂贵(与第一个相比),但仍将是私有的。



SpaceIL也将负责新的Bereshit 2.0项目,并将继续是一个非营利组织。

“ Bereshit 2.0”项目的计划工期:2-3年。

国家,工程师和人民不停止相信胜利,这真是太好了。



No dream is beyond your reach, if you truly want it!

:

Lego model of Beresheet

Source: https://habr.com/ru/post/zh-CN448154/


All Articles