主题：【原创】F-35的苦日子还没有开始呢 -- 晨枫
家园 这个很有可能的 我猜在F22上各个EUC之间也是通过数据总线连接的，不管是哪种数据总线，对于发送/接收信息的校验和保护是免不了的，如果导航的EUC因为软件bug而导致死机或者连续reset，那么可能会触发其他EUC的相应的自我保护机制（例如采用default值），这样一来，引起的次级故障会被逐级放大，严重情况的确可能导致大面积的系统死机。
飞控系统的安全等级较高，可能会有独立冗余机制，所以在这种情况下还能工作，但是仪表显示系统的等级肯定要低一些，所以被牺牲了。
家园 现场故障处理和诊断水平也是衡量一个软件团队水平的指标 航空航天类软件专业性强、涉及面广，现场情况又很复杂，总有研发人员和测试人员估计不到的情况发生。软件现场出问题，研发团队必须第一时间解决掉，把危险消除在萌芽状态，这点对任何国家航空航天类软件从业人员而言都是家常便饭。这样的例子很多很多：
1970年美国“阿波罗13号”飞船在飞往月球路上出事故，最后也是地面测控人员和宇航员保持合作排除危险，最后安全回到地球；
神舟飞船升空后，负责测控的远望测量船遥感天线滑环坏了，天线没法正常转动，最后也是船上通信工程师连夜解决。
每次飞机试飞、飞船发射，厂家、研究所工程师都会到一线维护跟踪就这道理。飞机投产后还会有用服在现场解决问题，收集用户反馈。
你不能说有个故障泄露到现场就一口咬定整个软件设计很失败，那就很武断了。
退一步说，F-35飞控软件不算最复杂的，很多军用软件复杂度不比它差：核武器、军事决策、军事物流、宇宙飞船、海军战术决策系统、军事医疗......要是按你说的开发F-35软件就要吸毒了，那后面这些软件开发员要不要开飞机撞大楼了？
家园 UML是一种开放式的标准 主要就是以图形方式描述任何类型的系统，可以从模型到代码
可以看看这个链接
家园 仅就介绍来看，还是主要适用于简单应用 F-35那样的软件人工编制都是绞尽脑汁，自动编程可能不现实。
家园 这个并不是自动编程，而是自动生成代码 工程师把物理模型转换为数学模型，再通过可视化模型表达出来，然后把可视化模型自动生成C++代码。
对工程师来说，通过这样的工具，就算是不懂C++，也能做软件了，只需要工程师理解控制对象的物理本质，并能够将之转化为数学模型就好啦。
这种类似的东东在汽车行业嵌入式系统开发中已经得到不少应用了。
家园 不大明白自动编程和自动生成代码的差别是什么？ 过去编程序有伪码这一说，可视化模型是不是相当于伪码？从伪码到编程已经只是语法的问题了，这一步不是最难的，劳动量而已。
家园 从伪码到实际代码差的远了 中间有一堆一堆的问题,比如和其他模块相关的问题,edge case问题,内存效率优化问题.可视化编程是个美好的梦想,从来就没有实现过.
80年代中乔帮主的NeXT就尝试过,80年代末有一个流行的东东叫做layout,也是拖拽式编程,90年代初有个authorware,也是一样的东西,后来的visual basic, delphi都有这种控件拖拽式的编程模式,都代替不了最终的手工代码.
现在的rails, node, django都有自动框架代码的生成,但是手工代码是替代不了的.如果说有什么技术是可以最大限度的自动化重复代码和逻辑的话,那就只有lisp家族语言.
这类语言其共性有个很学术的名称,叫做homoiconic语言,意思是其代码本身就是数据,是可以被其他代码生成和实时改变的.只有这样,才能在语言本身实现code generating code.
机器代替人来写代码,愿望是好的,实现还要很多年.人工智能走到那一步那就是极大的飞跃了.
家园 谢了 看来我还没有落伍得太离谱，否则人家都自动编程，就我还在手工编程，就太悲催了。
家园 伪码是用来描述数据结构和算法的 上数据结构课的时候老师在黑板上用伪Pascal码描述数据结构和算法。但具体开发过程中很少有人在开发前用伪码描述思路的，因为这样工作量太大，相当于一个程序要写两遍代码，不划算。一般也就是把流程图画好，各个模块之间接口确定下来就可以开发了。和可视化模型更是两码事。
开发过程中劳动量是个很重要的指标，一般换算成人月数，毕竟开发人员也是人，偶尔加几次班可以，加多了人也受不了。
家园 统一建模语言 主要用来建模用的，一般架构设计师用的多，而且多数情况下用在面向对象开发模式下。这种语言可以生成代码框架，但不能生成代码，具体代码还是要靠开发人员一行一行写。