第三十八章 优先级与反转 (第1/1页)

    唐占文顿了顿，话峰一转道：“关于歼轰七A飞控软件开发，我想还是请六一八所的高明同志来说一说吧，因为这套飞控系统是由两所共同合作完成，除了控制律软件外，基本上是由他们主要负责的。”

    这时候大家伙儿都把目光投向了一名中年人，六一八所的飞控专家高明。

    在歼轰七A的设计研制当中，六一八所负责了飞控系统的大部分研制开发工作，作为中国航空工业集产品设计、开发、生产、服务于一体的导航、制导与控制技术研发中心，涉及多个行业和国防科技领域，产品横向覆盖多类飞行器，纵向贯穿从零部件制造到系统集成的全过程。

    无论是歼八二飞机的电传系统研制，还是歼十战斗机的飞控系统开发，都有它的身影，也就是说，整个国内战机的飞控软件编写，都是六一八所负责完成。

    高明便是经验非常丰富的飞软系统专家，参与了多型飞机的飞控系统开发工作，在歼轰七A项目中，高明便是飞控软件开发总体负责人。

    高明沉声道：“各位领导，专家，下面我就从飞控的角度说一说这一次试飞事故的原因分析，关于飞控系统硬件的研制和软件的程序编写，是由我所完成，由我本人总体负责，因为我们对这次试飞事故，也进行了认真的分析。关于飞控软件，刚才唐总师说了，采用了容错技术，发生错误的概率基本上没有，大家也都清楚，飞控软件缺陷发生的概率在千万小时分之一以上，也就是说咱们的歼轰七A战机，飞行时间累积一千万小时，可能会出现一次错误，大家想想这是不可能出现的。”

    “而且这套软件，虽然是由我所负责编写，但也是由主机所进行了检查，然后共同安装检测，当时的评审会上，专家组也明确表示非常好。所以在飞控软件上的缺陷，是不可能有的。两所共同对飞控系统可靠性进行对比分析结果显示，这套系统表现良好，我们攻克了飞控系统余度配置、同步算法、余度通道间信息交换与共享、电磁兼容、故障检测隔离与重构、机内自检测等一系列关键技术。而这一次飞机姿态失控，我们认为与飞控系统无关，应是外界因素导致。”高明说完了，便不再多作解释。

    这下子，会议就陷入了僵局，如果说飞控系统也没有问题，试飞员的操作更是没有问题，那问题出在哪儿呢？

    今天这个事故分析会，怕是分析不出个结果了。

    只有林鹏才知道，事故的真正原因，就是软件代码上的一个隐形错误导致的。

    但是他作为整个会议室里资历最浅的人，也不可能站起来说啊，再者他要站起来说了，恐怕也没有人会相信他的。

    更重要的是六一八所的专家自己都说了，飞控软件不可能有问题，他这时候要是站起来说有问题，那不是打别人的脸吗？当然这也是打六零三所，打一飞院，打唐总师的脸啊！

    可是这个问题怎么才能解决呢？

    林鹏也陷入了纠结当中，怎么样才能让大家知道问题出在哪儿，然后去解决它，但是又不能伤了和气和脸面，更不能让人知道他是怎么知道飞控软件代码有问题的。

    这个林鹏还真是犯难了。

    此时会议室里的专家们也是议论纷纷，交头接耳，现在谁都知道，出了这么大的问题，恐怕大家都不想问题出在自己身上。

    唐占文总师也不知道该说什么好了，因为飞控软件的确是两家合作的，当然设备和软件都是六一八所主导的，六零三所只是负责飞行控制律方面的工作。

    这套飞控系统，也是经过了严格的测试的，当时表现良好，专家评审一致认为达到了国内领先的水平。

    甚至是软件的编码，都是组织了专家进行评审的，对这套飞控系统的模块测试，综合测试和硬件软件的集成测试，结果都是非常好的。

    唯一欠缺的可能是没有进行铁鸟台的飞行测试，因为当时就没有条件搞铁鸟台，在国内铁鸟台还是一个很难突破的技术，六一一所在研制歼十这样的三代战斗机过程中，才逐步摸索搞出来了。

    但是就算没有铁鸟台，也在综合测试和飞行测试中表明，这套三轴三余度数模飞控系统还是很可靠的。

    但是如果不是飞控的问题，那这次事故发生的原因是什么呢？总不能不了了之吧？这肯定是不被允许的，也过不了上级那一关。

    就在这时候唐占文忽然感觉口袋里的手机，震动了几下，开会的时候他的手机的确是调到了静音的。

    唐占文心想这时候是谁发了短信过来？唐占文拿出手机一看，发短信给他的人，是林鹏。

    当他看到短信内容的时候，也是震惊了。

    林鹏发给他的短信内容不长，就提到了两个关键词，优先级与反转，1997年M国火星探路者事件。

    看到林鹏这个提示，唐占文总师只觉得脑袋里面，似乎都嗡的响了一下，好像问题出在哪儿，他找到了！但这也只是林鹏的揣测，到底是不是，也不是凭猜测和嘴巴说就能证明的。

    但不管怎么样，今天这个事故分析会，必须要有个结果啊，所以唐占文决定哪怕是丢了面子，也要讲出来。作为总师，他对飞行控制系统还是非常了解的，虽然他不会编写那些代码，但基本的原理和架构，他非常清楚。

    而火星控路者事件，是怎么一回事呢？一九九七年，M国炎星探路者着陆火星后第十天，就开始犯傻，它开始无规律的重启，每次启动都会造成数据丢失。

    当时NASA的解释是火星探路者的计算机试图同时完成太多任务造成故障。

    在当时的分析会上，开发火星控路者自动控制软件系统的公司，就给出了一个很有意思的说法，这就是优先级与反转。

    火星探路者的气象任务，这是一个低优先级的任务，在写总线的时候，一个中断的发生导致了通信任务被调度并就绪，最后由于通信任务运行时间稍长了，总线管理任务等待超时，返回错误。结果就是系统重启。