“啊?”
發出這聲驚唿的並不是徐洋。
實際上,她隻是有些訝異地抬頭看了一眼常浩南,甚至連表情變化都不太大。
反倒是站在旁邊的另外幾名624所技術人員,此時正用有些茫然地目光看向坐在一張桌子兩邊的常浩南和徐洋。
講道理的話,這也不能全怪他們。
剛才這兩個人的一番交流全程連筆都沒用,對於周圍的其他人來說確實有億點不友好。
哪怕其中的相當一部分都直接參與了這套仿真驗證程序的設計,但仍然很難跟上徐洋剛才的介紹思路。
結果前麵的內容還沒完全理解透,常浩南這邊的意見都已經給出來了。
自然會有一種“數學課上低頭撿了一支筆”的感覺。
麵對徐洋帶著詢問的眼神,常浩南總算從旁邊拿起了一支筆:
“驗證程序的算法和控製邏輯是沒問題的,我的意思是,還有一些測試的內容沒有考慮到。”
剛剛還散落在房間周圍的一眾人見到這一幕,幾乎是整齊劃一地向前幾步,圍到了二人身後。
常浩南瞬間覺得打在紙上的光線都變暗了……
“咳咳……裝備全權限數字控製係統的發動機普遍不會再配置完整的機械控製係統,因此必須要考慮到可能麵臨的各種工況,比如在飛行過程中因為各種原因出現網絡誘導時延和數據包丟失。”
“時延就不用說了,如果從操作端發出控製指令到動作端響應之間會出現明顯間隔的話,恐怕再好的飛行員都沒辦法正常駕馭飛機。”
“至於丟包……對於fadec使用的ttcan總線,如果數據包發送失敗,協議隻會允許參考消息立即重發,而其它數據則不能,這樣會顯著影響到係統控製的精度和速度,甚至導致係統失穩。”
常浩南一邊解釋一邊筆走龍蛇:
“比如,我們可以先分析一下最簡單的時延和丟包形式,假設時延是短時延且在各個采樣周期內恆定,數據包連續丟失數也具有上限n,那麽在一個采樣周期之內,到達執行器端的控製器輸出可能就會出現兩個……”
“……”
“發動機在穩態點附近工作的動態特性可以簡單用一個連續狀態空間方程描述,再把這個方程進行離散化,就會出現2n+1種子係統,實際的發動機工作特性會在這2n+1種之間隨機且連續跳變,顯著延長穩態係統的收斂過程……”
說到這裏,常浩南停下手中的筆,把已經寫滿公式的兩張紙推到前麵,然後抬起頭。
這一番計算讓周圍的人直接表演了一個目瞪口呆。
但好在這次至少是邊說邊寫,有不少紙麵內容,所以相比剛才的完全茫然,至少還是有幾個人聽懂了其中的關鍵。
“我們這個是線控連接,應該不至於出現特別誇張的延遲或者丟包吧……”
一個人帶著些許遲疑地問道。
常浩南此時剛喝了口水,趕緊咽下去,然後搖了搖頭:
“其實就跟我們正常的電腦上網一樣,發動機的ecu單元以及線纜的信號傳輸帶寬實際上還不如家用電腦和網線,所以,哪怕是在正常飛行過程中,出現信息傳輸不通暢的問題也是很正常的。”
“那這樣的話……豈不是說明fadec在穩定性方麵存在硬傷?”
另一個聲音明顯有點顫抖:
“畢竟,機械控製係統的延遲是確定的,隻要適應下來就可以了,更不可能出現數據丟失問題,但電控的這些都是隨機出現,難道還要保留一套完整的機械係統做備份?”
fadec的一個巨大優勢就是減重,保留機械備份自然是不現實的。
不過,常浩南既然已經提出來了這個問題,那解決辦法就必定是有的:
“電控的延遲和丟包雖然是隨機出現,但還是可以通過高魯棒性的控製算法減弱甚至消除對於性能表現的影響。”
“所以我在設計發動機控製程序的時候,采用了分布式控製增益矩陣,以提高對時延和丟包情況的穩定裕度,但這個裕度具體有多少,能否滿足戰鬥機在各種工況下的需求,還需要在測試過程中進行驗證。”
“如果穩定裕度不夠,那就需要再增加一個發動機控製單元,如果裕度過剩的話,還可能得減少一個,畢竟一套ecu和相關的線纜加在一起,也有個幾十公斤的重量……”
“分布式控製增益矩陣……這……還可以這樣?”
剛剛一直坐在常浩南旁邊的薑甫和眼中頓時閃過一絲茅塞頓開的明悟。
在去年把624所的研發重點轉向垂直起降發動機之後,擺在他麵前的最大問題就是發動機垂直輸出動力過程中的控製響應和穩定性問題。
要知道,垂直起降不像平飛,推力大點小點影響都不會很大,如果在這個過程中推力輸出失衡,那飛機輕則失穩重則直接墜毀。
然而垂直起降過程的高壓燃氣要經過一個90°甚至更大角度的偏轉,可能受到的外界擾動反而更複雜……
所以對於發動機控製係統的要求相比普通發動機來說要高得多。
在目前用老型號渦噴7發動機外接垂直噴口進行測試的過程中,哪怕用上電控單元,也仍然不能保證垂直輸出過程的可靠性。
但常浩南剛剛這一陣卻,給了他一個完整的思路。
薑甫和隻覺得可惜,自己並不是控製算法領域的專家,所以現在空有一個思路,卻很難落實下去……
坐在對麵的徐洋剛剛就已經把那兩張紙拿到手裏,別人還在提問的功夫,她已經飛速看完了上麵的內容:
“這樣的話,我隻要在測試控製係統裏麵加入一個丟包和時延模擬就可以……而且本質上,丟包也可以被等效為發動機的輸入時滯……”
“所以,可以認為發動機的輸入端存在隨時間推移而同步增長的時延,從而使得發動機收到的控製輸入信號隻跟測量值有關……”
“當然,這種辦法測出來的結果是係統允許的最大連續丟包數,不是丟包率,應該沒問題吧?”
“可以。”
常浩南果斷點頭:
“用最大連續丟包數的話,無非需要稍微改一下極限參數設置邏輯,這是個完全獨立的單元,也就幾個小時的事情。”
“那等我消息,兩天之內給你弄好。”
徐洋把兩張紙丟在桌上,站起身點了幾名624所工程師的名字,便帶著他們匆匆離開了控製室。
“常總。”
在房間裏麵重新變得冷清下來之後,薑甫和重新找上了常浩南:
“關於您剛剛提到的分布式控製增益矩陣,能說一下完整的思路麽?”
後者稍微一愣。
主要是沒想到會有人問這種問題。
因為這個屬於設計過程中的內容。
不過轉念一想倒也合理,畢竟624所又不是隻做航發測試,他們本身也是渦輪動力研究機構。
甚至在上一世,有不少核心機都是624所搞出來的。
隻不過如今因為他的原因導致人家幾乎成了小透明……
“這個其實是受到了主機那邊飛控程序算法的啟發……”
常浩南說著重新拿過來了紙筆。
他在這件事上並沒有說謊。
確實是受到飛控程序的啟發。
隻不過不是自家的飛控程序,而是美國人的。
後世f35戰鬥機飛控的一個巨大問題,就是在某些飛行工況下會出現巨大的舵麵操控延遲。
一直到常浩南重生那會,這個毛病都還沒解決……
所以他在開發渦扇10控製程序的時候,幾乎第一個就想到了這個問題。
當然,這些內容不可能講給薑甫和聽,所以常浩南換了另外一個版本的故事。
反正隻要講的知識沒錯就行了。
看著眼前逐漸被填滿的草稿紙,薑甫和之前還有些憤懣的內心反而愈發平靜下來。
“常總,我們院手頭現在有個垂直起降發動機的項目,您看……等到渦扇10那邊結束之後,您有沒有興趣接手?”
人嘛,總要學會跟現實和解的。
打不過就加入,不丟人……
(本章完)
發出這聲驚唿的並不是徐洋。
實際上,她隻是有些訝異地抬頭看了一眼常浩南,甚至連表情變化都不太大。
反倒是站在旁邊的另外幾名624所技術人員,此時正用有些茫然地目光看向坐在一張桌子兩邊的常浩南和徐洋。
講道理的話,這也不能全怪他們。
剛才這兩個人的一番交流全程連筆都沒用,對於周圍的其他人來說確實有億點不友好。
哪怕其中的相當一部分都直接參與了這套仿真驗證程序的設計,但仍然很難跟上徐洋剛才的介紹思路。
結果前麵的內容還沒完全理解透,常浩南這邊的意見都已經給出來了。
自然會有一種“數學課上低頭撿了一支筆”的感覺。
麵對徐洋帶著詢問的眼神,常浩南總算從旁邊拿起了一支筆:
“驗證程序的算法和控製邏輯是沒問題的,我的意思是,還有一些測試的內容沒有考慮到。”
剛剛還散落在房間周圍的一眾人見到這一幕,幾乎是整齊劃一地向前幾步,圍到了二人身後。
常浩南瞬間覺得打在紙上的光線都變暗了……
“咳咳……裝備全權限數字控製係統的發動機普遍不會再配置完整的機械控製係統,因此必須要考慮到可能麵臨的各種工況,比如在飛行過程中因為各種原因出現網絡誘導時延和數據包丟失。”
“時延就不用說了,如果從操作端發出控製指令到動作端響應之間會出現明顯間隔的話,恐怕再好的飛行員都沒辦法正常駕馭飛機。”
“至於丟包……對於fadec使用的ttcan總線,如果數據包發送失敗,協議隻會允許參考消息立即重發,而其它數據則不能,這樣會顯著影響到係統控製的精度和速度,甚至導致係統失穩。”
常浩南一邊解釋一邊筆走龍蛇:
“比如,我們可以先分析一下最簡單的時延和丟包形式,假設時延是短時延且在各個采樣周期內恆定,數據包連續丟失數也具有上限n,那麽在一個采樣周期之內,到達執行器端的控製器輸出可能就會出現兩個……”
“……”
“發動機在穩態點附近工作的動態特性可以簡單用一個連續狀態空間方程描述,再把這個方程進行離散化,就會出現2n+1種子係統,實際的發動機工作特性會在這2n+1種之間隨機且連續跳變,顯著延長穩態係統的收斂過程……”
說到這裏,常浩南停下手中的筆,把已經寫滿公式的兩張紙推到前麵,然後抬起頭。
這一番計算讓周圍的人直接表演了一個目瞪口呆。
但好在這次至少是邊說邊寫,有不少紙麵內容,所以相比剛才的完全茫然,至少還是有幾個人聽懂了其中的關鍵。
“我們這個是線控連接,應該不至於出現特別誇張的延遲或者丟包吧……”
一個人帶著些許遲疑地問道。
常浩南此時剛喝了口水,趕緊咽下去,然後搖了搖頭:
“其實就跟我們正常的電腦上網一樣,發動機的ecu單元以及線纜的信號傳輸帶寬實際上還不如家用電腦和網線,所以,哪怕是在正常飛行過程中,出現信息傳輸不通暢的問題也是很正常的。”
“那這樣的話……豈不是說明fadec在穩定性方麵存在硬傷?”
另一個聲音明顯有點顫抖:
“畢竟,機械控製係統的延遲是確定的,隻要適應下來就可以了,更不可能出現數據丟失問題,但電控的這些都是隨機出現,難道還要保留一套完整的機械係統做備份?”
fadec的一個巨大優勢就是減重,保留機械備份自然是不現實的。
不過,常浩南既然已經提出來了這個問題,那解決辦法就必定是有的:
“電控的延遲和丟包雖然是隨機出現,但還是可以通過高魯棒性的控製算法減弱甚至消除對於性能表現的影響。”
“所以我在設計發動機控製程序的時候,采用了分布式控製增益矩陣,以提高對時延和丟包情況的穩定裕度,但這個裕度具體有多少,能否滿足戰鬥機在各種工況下的需求,還需要在測試過程中進行驗證。”
“如果穩定裕度不夠,那就需要再增加一個發動機控製單元,如果裕度過剩的話,還可能得減少一個,畢竟一套ecu和相關的線纜加在一起,也有個幾十公斤的重量……”
“分布式控製增益矩陣……這……還可以這樣?”
剛剛一直坐在常浩南旁邊的薑甫和眼中頓時閃過一絲茅塞頓開的明悟。
在去年把624所的研發重點轉向垂直起降發動機之後,擺在他麵前的最大問題就是發動機垂直輸出動力過程中的控製響應和穩定性問題。
要知道,垂直起降不像平飛,推力大點小點影響都不會很大,如果在這個過程中推力輸出失衡,那飛機輕則失穩重則直接墜毀。
然而垂直起降過程的高壓燃氣要經過一個90°甚至更大角度的偏轉,可能受到的外界擾動反而更複雜……
所以對於發動機控製係統的要求相比普通發動機來說要高得多。
在目前用老型號渦噴7發動機外接垂直噴口進行測試的過程中,哪怕用上電控單元,也仍然不能保證垂直輸出過程的可靠性。
但常浩南剛剛這一陣卻,給了他一個完整的思路。
薑甫和隻覺得可惜,自己並不是控製算法領域的專家,所以現在空有一個思路,卻很難落實下去……
坐在對麵的徐洋剛剛就已經把那兩張紙拿到手裏,別人還在提問的功夫,她已經飛速看完了上麵的內容:
“這樣的話,我隻要在測試控製係統裏麵加入一個丟包和時延模擬就可以……而且本質上,丟包也可以被等效為發動機的輸入時滯……”
“所以,可以認為發動機的輸入端存在隨時間推移而同步增長的時延,從而使得發動機收到的控製輸入信號隻跟測量值有關……”
“當然,這種辦法測出來的結果是係統允許的最大連續丟包數,不是丟包率,應該沒問題吧?”
“可以。”
常浩南果斷點頭:
“用最大連續丟包數的話,無非需要稍微改一下極限參數設置邏輯,這是個完全獨立的單元,也就幾個小時的事情。”
“那等我消息,兩天之內給你弄好。”
徐洋把兩張紙丟在桌上,站起身點了幾名624所工程師的名字,便帶著他們匆匆離開了控製室。
“常總。”
在房間裏麵重新變得冷清下來之後,薑甫和重新找上了常浩南:
“關於您剛剛提到的分布式控製增益矩陣,能說一下完整的思路麽?”
後者稍微一愣。
主要是沒想到會有人問這種問題。
因為這個屬於設計過程中的內容。
不過轉念一想倒也合理,畢竟624所又不是隻做航發測試,他們本身也是渦輪動力研究機構。
甚至在上一世,有不少核心機都是624所搞出來的。
隻不過如今因為他的原因導致人家幾乎成了小透明……
“這個其實是受到了主機那邊飛控程序算法的啟發……”
常浩南說著重新拿過來了紙筆。
他在這件事上並沒有說謊。
確實是受到飛控程序的啟發。
隻不過不是自家的飛控程序,而是美國人的。
後世f35戰鬥機飛控的一個巨大問題,就是在某些飛行工況下會出現巨大的舵麵操控延遲。
一直到常浩南重生那會,這個毛病都還沒解決……
所以他在開發渦扇10控製程序的時候,幾乎第一個就想到了這個問題。
當然,這些內容不可能講給薑甫和聽,所以常浩南換了另外一個版本的故事。
反正隻要講的知識沒錯就行了。
看著眼前逐漸被填滿的草稿紙,薑甫和之前還有些憤懣的內心反而愈發平靜下來。
“常總,我們院手頭現在有個垂直起降發動機的項目,您看……等到渦扇10那邊結束之後,您有沒有興趣接手?”
人嘛,總要學會跟現實和解的。
打不過就加入,不丟人……
(本章完)