主题：【原创】F-35的苦日子还没有开始呢 -- 晨枫

提高劳动效率会导致失业率上升。

这就是一个严重的政治问题。

航空航天类软件专业性强、涉及面广，现场情况又很复杂，总有研发人员和测试人员估计不到的情况发生。软件现场出问题，研发团队必须第一时间解决掉，把危险消除在萌芽状态，这点对任何国家航空航天类软件从业人员而言都是家常便饭。这样的例子很多很多：

1970年美国“阿波罗13号”飞船在飞往月球路上出事故，最后也是地面测控人员和宇航员保持合作排除危险，最后安全回到地球；

神舟飞船升空后，负责测控的远望测量船遥感天线滑环坏了，天线没法正常转动，最后也是船上通信工程师连夜解决。

每次飞机试飞、飞船发射，厂家、研究所工程师都会到一线维护跟踪就这道理。飞机投产后还会有用服在现场解决问题，收集用户反馈。

你不能说有个故障泄露到现场就一口咬定整个软件设计很失败，那就很武断了。

退一步说，F-35飞控软件不算最复杂的，很多军用软件复杂度不比它差：核武器、军事决策、军事物流、宇宙飞船、海军战术决策系统、军事医疗......要是按你说的开发F-35软件就要吸毒了，那后面这些软件开发员要不要开飞机撞大楼了？

Rational Rose和wsad、eclips都嵌入UML功能，但还没有像你说的那么厉害。

先是大批被开， 留下的随时可能被戴上JD的罪名。

哈哈哈

有分析说山姆炒作东亚和东南亚局势就是为了为自己的军工产品找市场。

我说的是软件的关键性，怎么被你联想到失败了？我就是干自控软件的，你说的这些性质的事情我都亲手做过，包括现场“热态”解决。F-35的软件复杂性和其他系统的比较，你能说说那些系统都是怎么样的，有多少行代码？

Bill Gates都对华尔街忧心忡忡，怕他们把他最好的人才拉走了。洛克希德或许不至于惨到只有末流人才，但顶级人才确实有可能拉不过来。

航电整合都是这么干的，可以和飞机试飞并行。

可以将第三方开发工具集成进去。例如Rational Rhapsody可以集成Mathlab/Simulink，可以定制C++代码生成功能

在汽车行业里面，这种类似的系统已经应用很多了

工程师把物理模型转换为数学模型，再通过可视化模型表达出来，然后把可视化模型自动生成C++代码。

对工程师来说，通过这样的工具，就算是不懂C++，也能做软件了，只需要工程师理解控制对象的物理本质，并能够将之转化为数学模型就好啦。

这种类似的东东在汽车行业嵌入式系统开发中已经得到不少应用了。

都十三罪恶了，还没开始，国防部长大概该吸毒了。

我猜在F22上各个EUC之间也是通过数据总线连接的，不管是哪种数据总线，对于发送/接收信息的校验和保护是免不了的，如果导航的EUC因为软件bug而导致死机或者连续reset，那么可能会触发其他EUC的相应的自我保护机制（例如采用default值），这样一来，引起的次级故障会被逐级放大，严重情况的确可能导致大面积的系统死机。

飞控系统的安全等级较高，可能会有独立冗余机制，所以在这种情况下还能工作，但是仪表显示系统的等级肯定要低一些，所以被牺牲了。

因此在ISO26262（IEC61508在汽车行业的衍生标准）里面要求软件工具（例如Code Generator）也要通过相应的认证。

就目前的应用来说，这样的自动代码工具可以满足汽车行业的安全等级要求，但是对于航空等级或军用等级的安全要求，我就不晓得是否符合了。

估计汽车的ABS和electric steering也不会用这个？