[分享] F-22猛禽機的飛航控制系統

mshockwave 發表於 2020/7/13 上午3:23:21

看板Military標題[分享] F-22猛禽機的飛航控制系統作者

mshockwave

(夏克維夫)時間Jul 13 03:23:21 2020推噓38 推:38 噓:0 →:73

PTT評價

不知道有沒有人分享過了

去年底一位美國空軍的測試飛官到MIT講猛禽機的飛航控制系統

（他本身也有MIT工程學位帝國空軍真的是有各種怪物人才ww)

https://youtu.be/Evhrk5tY-Yo

很可惜還沒有中文字幕但他用詞還蠻簡單的也不需要什麼背景就能理解

我非常喜歡他不斷拿F22跟西斯納小飛機做比較來做講解雖然我完全沒開過小飛機

但這樣一比較很多概念就突然變得很好懂

有興趣的可以看完整個影片非常精彩

這邊列出幾個出乎我個人意料之外的知識：

1. 飛機的重心。不用談各種高科技的因素最基本的飛機重心就是個難題了

因為F22的武器艙在機體重心的前面，丟完一兩顆炸彈大概等於突然少掉一台房車

的重量，沒有做任何調整的話飛機會直接往後翻

2. 水平舵與升降舵。如果只用水平舵後緣一小部份當升降舵的話在高速下很容易被鎖死

所以F22直接把整塊水平舵當作升降舵

3. 垂直尾翼。這部分真的是令我蠻 Mind Blown 的：F22的水平尾翼可以兩邊往內翻或者

往外翻。往內翻可以在起飛的時候更容易拉高機鼻，往外翻則是可以當作減速板

4. 飛航控制系統。基本上是猛禽機設計上的核心概念：駕駛不再是負責「控制」飛機

而是只負責告訴飛機要做什麼，電腦會負責做出所有細節操控。例如從他播的幾個

YT影片裡看到的在轉彎的時候機翼尾翼水平舵有一大堆的動作那些其實都不是

飛行員控制的而是電腦在做的。另外就是根據不同情況電腦也有相對應的模式

例如起飛的時候有一個模式空中加油的時候有另一個。而且最重要的是都不需要

飛行員手動去切換模式 (e.g. 偵測到起落架放下而且輪胎有壓力就會自動切到

起飛模式)

另外就是從本魯CS的背景來看，這代表他們程式碼的數量與前一代戰機比起來根本是成

指數倍成長。不僅要雇用更多人來寫，測試與驗證還是一個更大的問題。這讓我想起了

看過的一篇文章在說以前美國最頂尖的CS人才都跑去國防產業他們也自己發明出一大堆

專用的程式語言和系統，畢竟他們有點想要跟「凡人」的程式語言區隔開的感覺。

但後來矽谷崛起後，矽谷程式設計師的薪水海放洛馬和波音。越來越少人想進這個產業

所以國防產業最後只能收二流的程式設計師，選用程式語言上也開始妥協，畢竟用一般

常見的程式語言會更好招人。所以據傳F22的系統大多是用C/C++寫成的。

至於C/C++在驗證(verification)上有先天的限制那又是另一個故事了XDD

※ PTT 留言評論

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 169.234.228.195 (美國)

※ PTT 網址

推

ohmylove34707/13 03:40挖坑就要填！

哈哈你是說字幕嗎？有空再來做吧

推

homer0007/13 03:41對比:看到華人媒體說J20B要開始量產,引擎用俄製的

我最初在 Hacker News 看到這影片的時候下面也很多人拿 Su-35 來做比較俄係戰機也許機動性比猛禽高但也有其他留言是說： 1. 現代空戰到底有多少是距離近到需要超高機動性？ 2. 別忘了F22還能匿蹤匿蹤性跟機動性永遠是在繩子兩端互相拉扯的因素

※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 04:42:00

推

MartianIT07/13 04:56MIT IAP (independent activity period 一月長假<>寒假

→

MartianIT07/13 04:57) 常有些好玩的課有年我參加把妹課charm school XD

→

F04E07/13 07:12C/C++驗證有什麼先天上的限制？？

基本上有一拖拉庫的缺陷其中本魯認為最嚴重的用專有名詞的話就是alias analysis 非常難做。用最白話的解釋的話就是你很難去判定說當寫入一個數值後會不會影響到其他現有的數值。倒也不是其他程式語言沒有這問題而是C/C++ 在這方面特別糟糕

推

kira92507/13 07:19F-22還是ADA 是F-35才是C/C++

原來如此（筆記

推

bla07/13 07:254的話應該是FBW的飛機都是這樣吧

推

ayuhb07/13 07:47想想F22那時候用的電腦就覺得可怕

→

huckerbying07/13 07:56F-16開始就已經用FBW囉，不然以F-16的氣動設計飛出去

→

huckerbying07/13 07:56沒多久就墜機了

→

sdiaa07/13 08:09現在戰機還有不是整片水平尾翼都會轉的嗎??

抱歉小弟以前都沒特別注意其他飛機QQ

推

cwjchris07/13 08:17請問一下CS是什麼的縮寫？

Computer Science，就是台灣的資工

※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 08:27:47

推

bla07/13 08:25computer science

推

edison07/13 08:43F16在開發時,有考慮萬一FBW失敗時,改回傳統的操控方式

推

kira92507/13 08:443是不是把垂尾跟平尾寫反了?

→

edison07/13 08:503沒錯, F-18在航艦起飛時,垂尾那兩片也是同時向內

推

giancarlo8207/13 08:50YF-23的水平尾翼好像也可以轉?

推

kira92507/13 08:51YF-23只有V尾都是全可動的

→

kira92507/13 08:513.的內文寫水平尾

→

kira92507/13 08:51我還在想說水平尾向內跟向外是怎麼轉

推

maxiexc07/13 09:07如果沒記錯的話，全可動翼是超音速戰機的必要配備，主要

→

maxiexc07/13 09:07是用來避免控制翼失速

→

MOONRAKER07/13 09:39全動水平尾翼從F-86E就有了那是70年前吧

→

fantasyhorse07/13 09:41台灣這塊只能用慘來說...

推

momijichan07/13 09:43幻象的問題比較特別，主要是量少又不同戰系，同戰系的

→

momijichan07/13 09:43F-15和F-16才比較好對比，而F-2因為產量很低，雖然引

→

momijichan07/13 09:43擎是F110單發產量很多，但引擎以外的部份應該都不便宜

推

OpenGoodHate07/13 09:50何時史塔克工業要改用C#/Java 記得叫我

推

homer0007/13 09:58覺得C++算相對高級的語言了,很多SoC都用C而已;不過好奇戰

→

homer0007/13 09:58機上面CPU的computing power大概是甚麼程度的

推

momijichan07/13 10:02F-22已知大約是90年代末的powerPC，F-35沒印象，不過

→

momijichan07/13 10:02可以推估可以到10年代初的水準

→

Piin07/13 10:02F-22當年的計算能力不超過奔騰的計算能力..這已經是當年頂尖

→

kira92507/13 10:20用C是很合理的 C++完全不適合做OS級開發

推

homer0007/13 10:21C寫寫driver用的

推

homer0007/13 10:26想想就是C用來一個HW module(radar,sensor,...etc)的

→

homer0007/13 10:26driver就差不多,但是螢幕上顯示出來讓飛行員有situation

→

homer0007/13 10:26awareness的東西...還是需要OS之類的東西來整合來自各

→

homer0007/13 10:26module的訊息,這個還是用C/C++...(?)

推

kira92507/13 10:26全都可以用C寫啊....

推

OpenGoodHate07/13 10:29win/mac有用C++寫…

推

OpenGoodHate07/13 10:34基本上想的到的東西都能用C跟組語寫，有時後為了求

→

OpenGoodHate07/13 10:34效能表現重度運算的部份都會拆起來用C或組語寫成lib

推

homer0007/13 10:35有點奇妙的感覺,一台上億美金的精密裝備,跟一顆幾塊美金

→

homer0007/13 10:35的SoC...萬變不離其宗

推

OpenGoodHate07/13 10:37雷克勒也是裝windows呀，符合需求就好

推

kira92507/13 10:37我比較好奇你怎麼會這麼低看C...

→

kira92507/13 10:37C作為程式語言的歷史地位可能是前無古人的...

推

OpenGoodHate07/13 10:42現代計算機科學的領域也是講多層分工，用C寫核心效

→

OpenGoodHate07/13 10:42能棒是沒錯，但是如果是大型系統沒物件導向的話你很

→

OpenGoodHate07/13 10:42難把功能模組拆分重用，最後變成整套打掉重練

推

kira92507/13 10:45物件導向的寫法跟物件導向的程式語言其實是不一樣的事情

→

OpenGoodHate07/13 10:57我意思是在不同層用不同語言寫，核心用C除外的東西

→

OpenGoodHate07/13 10:57用其它高階語言寫

推

homer0007/13 11:09以前大學專題玩zigbee,想把RSSI用pathloss model來換算成

→

homer0007/13 11:09距離,稀哩呼嚕偷懶用一個table來mapping..(C code),進階

→

homer0007/13 11:09的刻一個三角定位運算...放棄

→

ja2307200807/13 11:21雷克勒windows是外銷版。

推

homer0007/13 11:22*不過這應該算是DSP engine的工作了

推

tpmstr11107/13 11:36這飛官的學經歷，讓我想起之前NASA太空人的學經歷，完

→

tpmstr11107/13 11:36全無法想像.....

→

F04E07/13 11:39聽你在喇叭

→

F04E07/13 11:42寫入一個值會影響其他值根本就是你程式有問題

如果再更進階一點描述的話就是「兩個指針(pointer)是否會指向同一塊記憶體」或是「兩個指針所指向的記憶體會不會重疊」。舉個例子好了： void foo(int* a, int* b, int x) { a[10] = x; b[0] = x + 1; printf("%d\n", a[10]); } 正常情況下我們會預期他印出來x的值。但問題是假設今天有一個函式呼叫的地方是這樣： bar() { int a[20]; foo(a, a+10, 32); } 那他就不會印出我們所預期的32，而是33。因為foo函式的a和b參數重疊(alias)了。換句話說，參數a和參數b其實是指向同一塊記憶體。這種事情會不會發生？當你的專案大到一種程度，這種問題根本是家常便飯。你說的沒錯，這的確是程式設計師的錯，而所謂的驗證(verification)

就是用來抓出這種問題

→

kira92507/13 11:44他寫的很實際歐...在多工環境非常多問題

的確，多工的驗證(e.g.偵測race condition)又是另一個level了XDD

推

awhat07/13 11:54因為程式不可能只有一個人寫，多個工程師要寫自己的部分

→

awhat07/13 11:54然後把不同的lib合在一起，所以舉個最簡單的例子，不同的

→

awhat07/13 11:55lib要是有用到相同的變數就有可能出問題

→

awhat07/13 11:55 *命名

※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 12:21:39

→

F04E07/13 12:41那就是程式的bug跟語言本身有什麼關係

這個問題問得非常好：如果語言設計的好的話，其實是可以避免這種alias問題的舉個最成功的例子：Rust programming language。首先他的變數有分唯讀(immutable)以及可變(mutable) 後者可以改變其中的值，前者只能讀。Rust 規定一塊記憶體可以被多個唯獨變數指向，但同時只能有一個可變變數指向他。不能同時存在一個可變變數與多個唯獨變數 (如果違反的話就會丟出compile error) 這種設計基本上就解決了很多的記憶體 alias 問題。其他例子還有Erlang，利用類似 message passing 的方式大大簡化了 memory model，讓靜態分析更為簡單。

推

kira92507/13 12:43程式語言設計哲學的意思

→

kira92507/13 12:43有的程式語言是不給pointer的

→

F04E07/13 12:44你的比喻就像是說刀子會割傷人所以切菜削水果盡量不用

→

F04E07/13 12:45刀子一樣可笑

→

kira92507/13 12:45而在那個年代系統資源有限導致的各種重複使用不勝枚舉

→

kira92507/13 12:45看起來很可笑沒錯但是是實際的問題

※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 12:55:20

→

kira92507/13 12:46pointer在大規模軟體企劃很危險

推

kira92507/13 12:47打錯專案

→

F04E07/13 13:02所以C++11開始有smart pointer不是? 更何況早在smart

→

F04E07/13 13:04pointer誕生前, 早就有使用pointer的design pattern了

→

F04E07/13 13:09大型專案別說是pointer很危險, 危險根本到處都是

→

F04E07/13 13:10所以才需要unit test, 甚是利用靜態解析工具來分析程式碼

→

F04E07/13 13:12我是覺得拿alias analysis來說C/C++很多缺陷是蠻怪的

→

F04E07/13 13:14畢竟alias analysis只是實作編譯器上的一種技巧

我說的是 C/C++ 在驗證(verification)上有許多缺陷這邊不斷提及的驗證或者說關鍵系統(critical system)的驗證如果去翻翻相關文獻的話大部分時候用的就是靜態分析(static analysis) 而alias analysis 除了編譯器優化外靜態分析當然也有用而且是決定性的關鍵驗證跟你提及的測試一個很大的不同點在於他必須窮舉所有輸入資料的情況寫一個測試你只要餵少數幾筆輸入資料就行了如果出現新bug在寫一個新的測試或者加入新的測試資料。(code coverage是一個很重要的指標但是他指的是覆蓋多少程式碼而不是覆蓋多少輸入資料) 但 critical system 沒這個餘裕，等出現新bug大概都已經很糟了XDD 所以通常會用靜態分析加上一些抽象模型例如SMT Solver，來證明說「對於所有輸入資料，這個系統沒有問題」，雖然一切都是 best efforts，但絕對比 testing 還更為縝密。另外你提及smart pointer這點也非常有趣我記得CppCon 19年來自google的Chandler 有給一個talk "There is no Zero Abstraction"，裡面提及說 smart pointer 固然實用，但其實還是潛藏許多 runtime overhead，例如stack unwind 以及 ABI 相關問題只要軟體規模一擴大(例如他們google自家的伺服器) 這些小 overhead就會逐漸累積回到軍事的話題上，如果這些 smart pointer 有潛藏甚至不固定的 overhead，那麼在預估最糟時限(deadline)上勢必就比較困難一些

→

kuma66022407/13 13:27很多華麗寫程式技巧在軍用是不必要風險

→

kuma66022407/13 13:27好維護不當機才是優先

→

kuma66022407/13 13:28畢竟90年代以後最高薪的少數高手

→

kuma66022407/13 13:28通常不會去幫軍方寫東西.

→

F04E07/13 13:30我只是在反駁pointer危險這點上危不危險是看用的人而不是

→

F04E07/13 13:30pointer本身