[分享] F-22猛禽機的飛航控制系統
不知道有沒有人分享過了
去年底一位美國空軍的測試飛官到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.cc), 來自: 169.234.228.195 (美國)
※ 文章網址: https://www.ptt.cc/bbs/Military/M.1594581804.A.660.html
推
07/13 03:40,
3年前
, 1F
07/13 03:40, 1F
哈哈你是說字幕嗎?有空再來做吧
推
07/13 03:41,
3年前
, 2F
07/13 03:41, 2F
我最初在 Hacker News 看到這影片的時候下面也很多人拿 Su-35 來做比較
俄係戰機也許機動性比猛禽高 但也有其他留言是說:
1. 現代空戰到底有多少是距離近到需要超高機動性?
2. 別忘了F22還能匿蹤 匿蹤性跟機動性永遠是在繩子兩端互相拉扯的因素
※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 04:42:00
推
07/13 04:56,
3年前
, 3F
07/13 04:56, 3F
→
07/13 04:57,
3年前
, 4F
07/13 04:57, 4F
→
07/13 07:12,
3年前
, 5F
07/13 07:12, 5F
基本上有一拖拉庫的缺陷 其中本魯認為最嚴重的用專有名詞的話就是alias analysis
非常難做。用最白話的解釋的話就是你很難去判定說當寫入一個數值後 會不會影響到
其他現有的數值。倒也不是其他程式語言沒有這問題 而是C/C++ 在這方面特別糟糕
推
07/13 07:19,
3年前
, 6F
07/13 07:19, 6F
原來如此(筆記
推
07/13 07:25,
3年前
, 7F
07/13 07:25, 7F
推
07/13 07:47,
3年前
, 8F
07/13 07:47, 8F
→
07/13 07:56,
3年前
, 9F
07/13 07:56, 9F
→
07/13 07:56,
3年前
, 10F
07/13 07:56, 10F
→
07/13 08:09,
3年前
, 11F
07/13 08:09, 11F
抱歉 小弟以前都沒特別注意其他飛機QQ
推
07/13 08:17,
3年前
, 12F
07/13 08:17, 12F
Computer Science,就是台灣的資工
※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 08:27:47
推
07/13 08:25,
3年前
, 13F
07/13 08:25, 13F
推
07/13 08:43,
3年前
, 14F
07/13 08:43, 14F
推
07/13 08:44,
3年前
, 15F
07/13 08:44, 15F
→
07/13 08:50,
3年前
, 16F
07/13 08:50, 16F
推
07/13 08:50,
3年前
, 17F
07/13 08:50, 17F
推
07/13 08:51,
3年前
, 18F
07/13 08:51, 18F
→
07/13 08:51,
3年前
, 19F
07/13 08:51, 19F
→
07/13 08:51,
3年前
, 20F
07/13 08:51, 20F
推
07/13 09:07,
3年前
, 21F
07/13 09:07, 21F
→
07/13 09:07,
3年前
, 22F
07/13 09:07, 22F
→
07/13 09:39,
3年前
, 23F
07/13 09:39, 23F
→
07/13 09:41,
3年前
, 24F
07/13 09:41, 24F
推
07/13 09:43,
3年前
, 25F
07/13 09:43, 25F
→
07/13 09:43,
3年前
, 26F
07/13 09:43, 26F
→
07/13 09:43,
3年前
, 27F
07/13 09:43, 27F
推
07/13 09:50,
3年前
, 28F
07/13 09:50, 28F
推
07/13 09:58,
3年前
, 29F
07/13 09:58, 29F
→
07/13 09:58,
3年前
, 30F
07/13 09:58, 30F
推
07/13 10:02,
3年前
, 31F
07/13 10:02, 31F
→
07/13 10:02,
3年前
, 32F
07/13 10:02, 32F
→
07/13 10:02,
3年前
, 33F
07/13 10:02, 33F
還有 41 則推文
還有 4 段內文
→
07/13 12:45,
3年前
, 75F
07/13 12:45, 75F
※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 12:55:20
→
07/13 12:46,
3年前
, 76F
07/13 12:46, 76F
推
07/13 12:47,
3年前
, 77F
07/13 12:47, 77F
→
07/13 13:02,
3年前
, 78F
07/13 13:02, 78F
→
07/13 13:04,
3年前
, 79F
07/13 13:04, 79F
→
07/13 13:09,
3年前
, 80F
07/13 13:09, 80F
→
07/13 13:10,
3年前
, 81F
07/13 13:10, 81F
→
07/13 13:12,
3年前
, 82F
07/13 13:12, 82F
→
07/13 13:14,
3年前
, 83F
07/13 13:14, 83F
我說的是 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)上勢必就比較困難一些
→
07/13 13:27,
3年前
, 84F
07/13 13:27, 84F
→
07/13 13:27,
3年前
, 85F
07/13 13:27, 85F
→
07/13 13:28,
3年前
, 86F
07/13 13:28, 86F
→
07/13 13:28,
3年前
, 87F
07/13 13:28, 87F
→
07/13 13:30,
3年前
, 88F
07/13 13:30, 88F
→
07/13 13:30,
3年前
, 89F
07/13 13:30, 89F
→
07/13 13:38,
3年前
, 90F
07/13 13:38, 90F
→
07/13 13:38,
3年前
, 91F
07/13 13:38, 91F
※ 編輯: mshockwave (169.234.228.195 美國), 07/13/2020 13:54:08
推
07/13 14:18,
3年前
, 92F
07/13 14:18, 92F
→
07/13 14:56,
3年前
, 93F
07/13 14:56, 93F
推
07/13 15:02,
3年前
, 94F
07/13 15:02, 94F
→
07/13 15:03,
3年前
, 95F
07/13 15:03, 95F
→
07/13 16:15,
3年前
, 96F
07/13 16:15, 96F
→
07/13 16:16,
3年前
, 97F
07/13 16:16, 97F
→
07/13 18:38,
3年前
, 98F
07/13 18:38, 98F
推
07/13 18:54,
3年前
, 99F
07/13 18:54, 99F
→
07/13 18:54,
3年前
, 100F
07/13 18:54, 100F
推
07/13 19:11,
3年前
, 101F
07/13 19:11, 101F
→
07/13 20:28,
3年前
, 102F
07/13 20:28, 102F
→
07/13 20:29,
3年前
, 103F
07/13 20:29, 103F
→
07/13 20:29,
3年前
, 104F
07/13 20:29, 104F
→
07/13 20:37,
3年前
, 105F
07/13 20:37, 105F
→
07/13 20:39,
3年前
, 106F
07/13 20:39, 106F
→
07/13 20:40,
3年前
, 107F
07/13 20:40, 107F
→
07/13 20:41,
3年前
, 108F
07/13 20:41, 108F
推
07/13 22:12,
3年前
, 109F
07/13 22:12, 109F
→
07/13 22:12,
3年前
, 110F
07/13 22:12, 110F
→
07/13 22:13,
3年前
, 111F
07/13 22:13, 111F
討論串 (同標題文章)