天问一号成功落火：使用国产自研操作系统

天问一号成功落火：使用国产自研操作系统
分享到： 20
2021-06-21 09:50:40字号：A- A A+来源：央视新闻客户端
前不久，“天问一号”着陆器成功着陆火星，它使用的就是我国自主研发的麒麟操作系统。在国家重大航天任务中，中国电子信息产业集团麒麟操作系统的党员突击队冲锋在前，担当起了操作系统国产化过程中攻坚克难的任务。

今年5月15日，天问一号着陆巡视器成功着陆火星，我国首次火星探测任务取得圆满成
功。在整个任务过程中，麒麟党员突击队有两名工程师始终在航天飞行控制中心随时待命。

在重大项目中，遇到应急、疑难任务党员先上，是麒麟团队从“嫦娥三号”任务起形成的制度。在“嫦娥三号”任务过程中，由于航天对操作系统稳定性、实时性的严苛要求，麒麟团队曾经遭遇了前所未有的极限挑战。在任务过程中，记录在案的问题就有180
多个。在这些问题中，最让麒麟团队头痛的是：航天方面提出，操作系统的实时响应精度为8毫秒，而一般通用系统的实时精度，最多能达到20毫秒至30毫秒。

麒麟团队接受到任务时，距离嫦娥三号发射只有半年时间了。任务紧迫，由于航天飞控中心白天要进行各系统联合调试，麒麟团队经常要到晚上才能使用设备进行测试验证，加班到凌晨是经常的事。

面对高强度、高难度任务的挑战，麒麟软件成立了专项攻关党员突击队，由6名党员带
领一个十多人的团队开始昼夜不停地攻关。党员在团队成员中占了三分之一。

刘军带领的团队通过绑定CPU、设置优先级等办法，验证的数据都达不到8毫秒。整整半个月时间，团队成员反复探讨，集思广益之下，终于找到了解决问题的思路。

为了解决这个问题，麒麟软件团队修改了约12万行代码，采用抢占式策略来满足任务的实施要求。从提出设想到最终成功实施，花了将近半年时间反复验证，嫦娥三号发射之前，180多个问题最终都得到了圆满解决。

麒麟软件团队平均年龄不到30岁，党员的先锋作用带动了这支年轻团队迅速成长。如今，麒麟操作系统已经在中国空间站、北斗工程、金融、能源、交通等领域得到广泛应用，为国家重大项目贡献了“中国大脑”。

在操作系统上，中国并不落后。落后的是市场化，因为先来者已经把市场占领了。

写这篇文章的人，瞎扯蛋。

8毫秒，笑话了

80微秒马马虎虎。。。。

8微秒，那就太牛B了。。。。。

这里面有我最讨厌的一句话

麒麟软件团队平均年龄不到30岁

到处透露着年龄歧视

没有头绪的东西
专门开拓的事实操作系统应用也会很广泛

【 在 tmbb2012(tmbb2012) 的大作中提到: 】

: 写这篇文章的人，瞎扯蛋。

: 8毫秒，笑话了

: 80微秒马马虎虎。。。。

: 8微秒，那就太牛B了。。。。。

JB掐得不够,再努力一把.

麒麟不能做个简版的RTOS么？
抢占式，是preemptive么？

估计就是个实时Linux。
这个一顿吹。
20毫秒至30毫秒，大概指的是tick10毫秒时的延迟。
估计是把实时的补丁打上去了，提高到8毫米，不容易啊。
呵呵。

属实，把抢占式吹得很高大上，这不是常规思路么

【 在 tmh (kcc) 的大作中提到: 】
: 估计就是个实时Linux，
: 这个一顿吹。
: 呵呵。

Rtos 还不简化？ 再简化就干脆不要操作系统了

【 在 iWater(aspire to inspire before i expire) 的大作中提到: 】

: 麒麟不能做个简版的RTOS么？

: 抢占式，是preemptive么？

应该是个改编的实时操作系统。能实现火星着陆还不伟大吗？换个货架产品行吗？

飞机的操作系统可是要花无数金钱来验证的。

【 在 tmh(kcc) 的大作中提到: 】

: 估计就是个实时Linux。

: 这个一顿吹。

: 20毫秒至30毫秒，大概指的是tick10毫秒时的延迟。

: 估计是把实时的补丁打上去了，提高到8毫米，不容易啊。

: 呵呵。

因为文中所述模棱两可

【 在 wildThing (东风起兮轰他娘, 安得巨浪兮吞扶桑) 的大作中提到: 】
: Rtos 还不简化？ 再简化就干脆不要操作系统了
:
: 麒麟不能做个简版的RTOS么？
:
: 抢占式，是preemptive么？
:

就是linux，估计打了实时的补丁，用于嵌入系统。
https://zh.wikipedia.org/wiki/%E4%B8%AD%E6%A0%87%E9%BA%92%E9%BA%9F

【 在 wildThing (东风起兮轰他娘, 安得巨浪兮吞扶桑) 的大作中提到: 】
: 应该是个改编的实时操作系统。能实现火星着陆还不伟大吗？换个货架产品行吗？
: 飞机的操作系统可是要花无数金钱来验证的。
:
: 估计就是个实时Linux。
:
: 这个一顿吹。
:
: 20毫秒至30毫秒，大概指的是tick10毫秒时的延迟。
:
: 估计是把实时的补丁打上去了，提高到8毫米，不容易啊。
:
: 呵呵。
:

得了吧。普通Linux的时钟是最高优先级，default的响应延迟是1毫秒

这篇文章的作者明显是根本不懂，单位量级搞错了，正确的应该是微秒

【 在 tmh (kcc) 的大作中提到: 】
: 估计就是个实时Linux。
: 这个一顿吹。
: 20毫秒至30毫秒，大概指的是tick10毫秒时的延迟。
: 估计是把实时的补丁打上去了，提高到8毫米，不容易啊。
: 呵呵。

狗屁，一般做不到1毫秒，大概是20，30毫秒级，如果tick是10毫秒的话。
【 在 tmbb2012 (tmbb2012) 的大作中提到: 】
: 得了吧。普通Linux的时钟是最高优先级，default的响应延迟是1毫秒
: 这篇文章的作者明显是根本不懂，单位量级搞错了，正确的应该是微秒

Linux的延迟是个难点，不过不到要党员冲锋的地步。
和信仰有个屁关系，谁的技术好，谁上。
宣个誓，就能解决bug吗？
呵呵。

不是吧，我记得jvm都能做到1ms精度。

【 在 tmh (kcc) 的大作中提到: 】
: 狗屁，一般做不到1毫秒，大概是20，30毫秒级，如果tick是10毫秒的话。

毫秒是千分之一不是百万分之一秒。
你是说微秒吧

【 在 tmbb2012(tmbb2012) 的大作中提到: 】

: 得了吧。普通Linux的时钟是最高优先级，default的响应延迟是1毫秒

: 这篇文章的作者明显是根本不懂，单位量级搞错了，正确的应该是微秒

10年前的RTOS就可以做到50微秒的延迟响应，

现在估计20-30微秒左右（CPU时钟频率越来越高了），

如果中国的火星探测器真能做到8微秒，那确实是牛B了。

8微秒的背后，需要对硬件以上的所有代码都重新设计，否则达不到这个尺度。

【 在 wildThing (东风起兮轰他娘, 安得巨浪兮吞扶桑) 的大作中提到: 】
: 毫秒是千分之一不是百万分之一秒。
: 你是说微秒吧
:
: 得了吧。普通Linux的时钟是最高优先级，default的响应延迟是1毫秒
:
: 这篇文章的作者明显是根本不懂，单位量级搞错了，正确的应该是微秒
:

1ghz 的cpu时钟是一纳秒一个指令。一千个指令的反应是一微秒的延迟。唉搞不明白。

【 在 tmbb2012(tmbb2012) 的大作中提到: 】

: 10年前的RTOS就可以做到50微秒的延迟响应，

: 现在估计20-30微秒左右（CPU时钟频率越来越高了），

: 如果中国的火星探测器真能做到8微秒，那确实是牛B了。

: 8微秒的背后，需要对硬件以上的所有代码都重新设计，否则达不到这个尺度。

要的就是这种效果

【 在 iWater (aspire to inspire before i expire) 的大作中提到: 】
: 因为文中所述模棱两可

应该是8微秒。查了一下，目前一般是20微秒，最好的是做到5微秒。

国产化的“化” 就是先抄再改，算不得“自研”

哪个不是先抄再改的？

【 在 vigo(vigo) 的大作中提到: 】

: 国产化的“化” 就是先抄再改，算不得“自研”

这个跟 l1/l2 cache 优化有关吗？差不多都是纳秒级别了

【 在 wildThing (东风起兮轰他娘, 安得巨浪兮吞扶桑) 的大作中提到: 】
: 1ghz 的cpu时钟是一纳秒一个指令。一千个指令的反应是一微秒的延迟。唉搞不明白。
:
: 10年前的RTOS就可以做到50微秒的延迟响应，
:
: 现在估计20-30微秒左右（CPU时钟频率越来越高了），
:
: 如果中国的火星探测器真能做到8微秒，那确实是牛B了。
:
: 8微秒的背后，需要对硬件以上的所有代码都重新设计，否则达不到这个尺度。
:

应该有关系。我早不记得clock rate和指令频率的关系了。
要看instruction set是怎么设计的。risc应该就是一个clock cycle一个basic
instruction.
但是要读内存，就要好多个cycle了。要是cache miss, 那就更多了。所以操作系统1
micro sec延迟还是困难--主要是要能保证时时能做到。

【 在 realoption (Options) 的大作中提到: 】
: 这个跟 l1/l2 cache 优化有关吗？差不多都是纳秒级别了