在Bereshit装置跌落到月球表面6天后，SpaceIL团队于2019年4月11日正式宣布了有趣的月球事故版本。 关于发生了什么，还有更多的问题。
有关事故的更新信息于04/18/2019。
继续
本出版物 。
来自Bereshit装置的最新SpaceL官方照片（距月球表面15公里）：
这是这张照片的位置参考：
事故调查的初步结果：
在着陆过程中，该命令由机载计算机激活，执行该命令导致任务致命
以下是对Beresheet的着陆操作进行初步调查的结果：看来，在着陆过程中输入了一条命令，该命令导致连锁反应，这导致主机关闭并阻止其重新启动。“似乎
在着陆过程中引入了
一条命令 ，这导致了连锁反应，导致设备的主机关闭，并且不允许其继续工作。”
从04/18/2019起更新：
尽管如此，由于着陆期间操作员收到的命令而造成的事故令人不安，没有时间分析情况，主机IMU1（惯性测量单元）处于紧急模式，操作员发送命令激活备用IMU2单元，这在工作中造成了进一步的严重后果车载计算机（冻结，重新启动）和引擎故障。
根据SpaceIL进行的初步调查，“ 旨在纠正 Beresheet航天器惯性测量单元之一故障的命令导致了一系列事件，导致着陆期间其主机关闭。”
因此，这可能是程序/人为错误（命令由操作员或MCC的工程师输入）在Bereshit设备降落的过程中。
Bereshit设备的命令和操作模式列表已获批准，仅从SpaceIL MCC发送。 SpaceIL工程师为设备的车载计算机创建了补丁程序，检查了它们的可操作性和功能，还为着陆过程准备了命令。
从理论上讲，抓住设备的控制权并将附加的代码/命令引入其车载计算机很有趣，从理论上讲，这是否有可能做到这一点，或者是否存在防止外部未经授权的访问的保护措施？
的确，降落时，时间持续了几秒钟，操作员可能会因为设备接收外国团队而错过了这种情况。 尽管此时，操作员也想起了手动模式，试图使用该设备。 也许在这里，同时输入的命令也有差异。
但是，最有可能的是，“他们的”代码中有错误（可能是每次重新启动后传输到车载计算机的许多补丁之一），其中包含致命命令。
这个团队是有意或无意引入的，这导致了事故-尽管我们正在等待他们承诺发布的SpaceIL的最终结果，但这一事实很可能将保持封闭。
有关Bereshit设备的硬件和软件组件的已知信息：-机载计算机是一（1）台不可复制的计算机（在飞往月球的过程中有几台计算机会重新启动）；
-用C语言控制程序代码，命令并与车载计算机一起工作；
-由于只有一台计算机，因此在重新启动时，所有更新（补丁）都将被删除，并且需要再次将其重新下载到系统中；
-低数据传输速度：一张高分辨率照片（来自8 Mpx相机）加载40分钟；
-DLR（德国航空航天中心）测试了Bereshit车辆的着陆机制；
-SpaceIL MCC的一个团队：大多数是空间工程师和物理学家，还有几位刚刚研究卫星控制系统的年轻科学家和工程师。
何时可以使用此致命命令执行代码？ 最有可能在准备着陆程序时。
但是，当仅由机载计算机控制的自动着陆过程开始时，机载计算机中的命令在设备通过“不返回点”后才起作用。
尽管SpaceIL MCC试图在手动控制模式下影响着陆期间设备的状况。
在距着陆点800公里的距离处，开始种植程序：
Bereshit设备将从MCC接收一系列命令：
着陆传感器（主要和备用）将被激活：
将开始更改Bereshit装置的位置（方向）的过程：
在登机前完成准备程序后，Bereshit车载计算机和MCC将有机会评估系统的状态及其登机准备情况；如果某些操作不正常，则将取消登机程序，如果一切正常，则在下一个阶段开始之后降落将不再被取消：
如果一切正常，那么Bereshit装置将开始使用主引擎和辅助引擎降低其轨道速度并缩短与月球表面的距离，此过程将花费15分钟：
登陆视频：
根据着陆视频，设备发生了什么（视频中显示了时间）：
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与月亮一起显示的自拍照图片。 海拔约22公里？ 遥测指示器变为绿色。
31:50遥测指示器不再变为绿色。
31:55至32:29“ [听不清]杀死他（过程？）。” “ [甚至听不清]忙”
（这里工程师已经处于手动控制之下，试图应对紧急情况）
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“ IMU传感器故障”
33:02所有引擎都打开。
33:05主机已启动。
33:07所有引擎都打开了。
33:09主机已启动。
33:11所有引擎都打开了。
33:13主机已启动。
33:16所有引擎都打开了。
33:20遥测指示器变为绿色。 所有引擎均关闭。 所有图片都冻结（读数没有变化）。
33:32遥测指示器不再变为绿色。 所有引擎均关闭。 所有图片都冻结（读数没有变化）。
34:24遥测指示器变为绿色。 所有引擎均关闭。
36:25-36:33“主机问题。 我们重新启动车载计算机以打开引擎。”
尝试在着陆过程中抄录播音员和工程师的话（时间不同，但本质和秒数相同）：
7:37:37-IMU2不好
7:37:50-[不清楚]将尝试启用它。
7:37:57-有人问它（不清楚“它”是什么）是否会使我们屈服于第二个[某物]
7:38:10-从JPL断开连接
7:38:34-我们丢失了一个IMU，并且失去了与JPL的连接，这两个不应该相关。
[在后台有人说过有关重启IMU的事情]
7:38:39-不要启用IMU2
7:38:52-屏幕上显示的内容不正确，目前没有遥测
7:39:06-[用英语]我们失去了遥测功能，但是现在我们有了遥测功能。
7:39:23-我们越过了海拔10公里
7:39:29-速度低于900 m / s
7:39:34-提醒我们需要达到0的速度
7:39:47-发动机正在运行，压力[不清楚]升至5 bar [？]，“有趣”
7:39:52-下载了第二张图片。
7:40:06-[播音员开始谈论激光着陆传感器]。 [在后台-不清楚，但似乎他说引擎未运行]
7:40:13-我们的主机可能有问题。
7:40:17-重新设置[他们在广播中早先提到过，他们可以在着陆过程中向航天器发送命令]
7:40:24-您想要什么？
7:40:28-情况似乎不好，没有主机。
7:40:33-收到第二张图片。
7:40:40-失去高度
7:41:07-[英语]我们似乎主机有问题，我们正在重置航天器以尝试启用引擎
7:41:10-是否可以发送[不清楚]？
7:41:15-基于[压力测量]，主机现在正在运行
7:41:19-主机重新启动。 [然后再用英语]
7:41:27-失去了很多高度，情况不明。
7:41:32-与JPL的连接断开
7:41:45-我们现在仅通过ssc [??]建立了连接，而没有通过美国国家航空航天局的连接，但是我们与航天器建立了连接。
7:41:49-遥测丢失
7:41:52-我们现在没有遥测
7:41:57-[english]主机启动，但我们失去了沟通
7:42:10-我们会等一下[不清楚]的[评估]
7:42:17-我们怀疑我们没有降落[不清楚]还在评估
7:42:56-我们没有远程通信，怀疑我们丢失了航天器。
7:43:16-所有迹象表明，不幸的是我们不会成为第四个登陆月球的国家。
7:43:33-我们在月球上，但是没有我们想要的样子。
根据MCC的数据，设备使用寿命的最后4秒（从678米减少到149米）：
在19:23，遥测数据完全停止到达。
现在，SpaceIL工程师拥有在每次重新启动车载计算机后发送到Bereshit设备的所有数据，命令列表和补丁程序，还可以更彻底地检查所有这些信息，并在设备发生事故之前分析着陆过程。
如果不仅是导致悲剧的外部传感器的不正确数据，而且是处理该数据甚至使设备意外进入紧急状态的程序代码，那么只有在有经验的情况下才能解决，即使在发送之前的代码创建阶段，也无法避免这种情况。飞船。
SpaceIL主席莫里斯·卡恩（Morris Kahn）表示：“
我为SpaceIL的工程师团队出色的工作和奉献精神感到自豪，不幸的是，事故往往是这种复杂而创新的项目不可或缺的一部分。 现在重要的是，尽可能多地吸取教训，研究错误并大胆地继续前进 。
顺便说一句，Bereshit装置在月球轨道上，在着陆期间使用了机载磁力计，并将有关月球磁场的一些科学数据传输到了SpaceIL MCC。
因此，他仍然完成了他的科学小程序的一部分！
发生事故时错误地
更新了数据 ：
完成调查的第一阶段归结为对事实和事件顺序的研究。 在飞行过程中，通信中断，但是Bereshit装置继续以指定模式运行。 直到设备开始降落在月球表面的那一刻。
在调查过程中，发现未执行从飞行控制中心发送的命令之一，这导致了一系列后续故障：发动机停止工作，设备掉落地面。
在加速度计传感器的操作中检测到故障，称为UMI（负责加速）。 尚未确切确定为什么会继而发生故障，从而导致系统随后出现负面反应。
激活加速度传感器的命令是从SpaceIL MCC发送的。
发生故障后，尝试以其他方式重新启动引擎，但未成功。
一切都在最严重的临时时间压力下发生：任务的最后几秒发生了故障，最终无法完成。
Bereshit装置的车载计算机还尝试自动重启引擎-进行了5到6次这样的尝试。 但是所有这些都不成功。可能是设备上的工程师之间的命令执行不兼容，以打开备用模块（IMU2），这进一步导致了新的问题和事故。
该航天器使用的是IMU 1，最初并未受到IMU 2的故障的影响。
一位工程师询问他们是否应该尝试启用IMU 2，另一位工程师询问“是否会导致系统切换到它”（大概是“它”表示IMU 2）。
也许尽管有第二个工程师的警告，但还是有人发出了尝试重启IMU 2的命令，也许这就是启动一系列事件的错误命令的意思。
