我是NASA的一家承包商，從事同一份合同，但與3家不同的公司合作，從1989年到1995年為航天飛機編寫GN&C代碼。最初是福特航空航天公司，然後是勞拉爾，然後是洛克希德·馬丁公司。在那個時候，IBM是最重要的。自從我做這樣的工作以來已經有很長時間了，所以不要持有我在下面寫的福音書。
今天早上我有一些時間，所以我會發些想法...
Shuttle OS並不是通用的。它是專門構建的，旨在加載1個程序，指令指針設置為0，然後開始運行。老實說，我不知道這是怎麼工作的，因為我們從未接觸過任何飛行計算機。我只看過照片，最近又在博物館的玻璃櫃中看到了一張。當我在那里工作時，我們無法直接訪問計算機。因為計算硬件是基於IBM 360的修改過的系統，所以所有主要係統都使用機器語言。有5個GPC-通用處理計算機。在上升和降落過程中，有4個運行了PASS-Primary Avionics系統軟件，另外1個運行了BFS（備用飛行軟件）。 BFS由另一承包商Rockwell編寫和維護。我對BFS一無所知，只是從未使用過。聽到謠言說最終合同被取消了，因為PASS的質量很高，因此不需要BFS。也許來自羅克韋爾的人可以回答？
GPC的絕大多數編程都是用HAL / S編寫的。這是一種類似於PL / 1的編譯語言，但具有矩陣計算擴展功能和多優先級調度系統。基本上，它支持254個線程，但是我們只使用了3個。HFE，MFE，LFE-嗨，中，低頻主管。優先級依次為H，M，L。 HFE以25Hz運行。 MFE以12.5Hz運行，低頻以0.5Hz運行。中間指令，較高的優先級可能會中斷較低的優先級。重要的是要留出時間，以便優先級較低的任務有足夠的時間運行。一些複雜的指導代碼會超出分配的時間，因此必須進行高度優化。由於這些都是實時系統，所以遲來的答案就很糟糕，因為它是錯誤的答案。定期地，每台計算機將到達檢查點，並與“冗餘集”中的其他計算機進行比較。基本上，他們會投票。多數規則。大多數計算機之外的任何計算機都將被刪除，而該計算機中所有將來的值都將被忽略。如果冗餘集中只有2個系統並且他們不同意，則認為首先到達的計算機是正確的。我認為他們運行的GPC少於3個。基本上，只有1個因代碼路徑分歧（1996年或更早）而被丟棄。 1996年我離開NASA區域後，我一無所知。
由於在堆棧上傳遞參數的性能較差，我們使用了全局變量。有一個嚴格的命名約定，該約定指出可以在哪個優先級上使用該變量，該變量屬於哪個子系統以及該變量的類型（int，標量，double，bit，hex）。我認為我們只能使用32個字符的變量名，但不要引用我，這不是問題。
不允許使用動態內存。曾經使用過一次的指針（在HAL / S中稱為“ NAMED”變量），並且需要獲得批准的方差。由於許多程序員都接受過工程學方面的培訓（包括我在內），而不是CS方面的培訓，因此對指針的理解並不充分。我利用指針溢出來訪問連續的內存變量，這些變量超出了編譯器為數組支持的允許大小。基本上，我背對背聲明了多個數組，並使用了一個指針將其內存視為1變量。沒什麼，但是這意味著必須確保編譯器不會以意外的方式優化存儲。編譯器和鏈接器特定於Shuttle程序，並且不防錯。但是，它們的質量很高。我們的一些基礎設施人員會執行編譯器審核，以查找奇怪的問題。一個叫JY的人，有太多的經驗和知識，問他一些問題很令人沮喪。 10年後，我在工作中變得和他一樣，並且明白簡單的問題並不總是能得到簡單的答案。 “取決於”是有效的答案，需要更多信息才能回答。
由於內存有限，打包位很常見。我的大部分代碼都是基於位值的二進制邏輯，以決定在可能非常不同的情況下執行哪種計算。
在軌道上，程序就像以前的MS-DOS“覆蓋”方法一樣被覆蓋。我沒有使用車輛工具代碼VU，但是它處理了手臂控制以及飛行控制（HiFE），生命支持（LoFE）和製導（MedFE）之外的其他事情。
如果對從事這項工作的人很感興趣，幾十年來有幾篇關於我們的文章。一位同事離開了該項目，為AMD工作。一年後，他回來了，因為AMD尋求的是“足夠好”的工程，而不是完美的工程。他的故事在“快速公司”-“寫正確的東西”中 https://www.fastcompany.com/28121/they-write-right-stuff
板載其他一些“使用的語言”並不是真正的語言。DFG-顯示格式生成器（或類似的東西）。正是這種語言驅動了DEU，使宇航員能夠查看狀態並管理計算機。僅BE（分支相等）和BNE（分支不相等）類型的比較操作非常基礎。標籤不跳-它僅使用了指令數。基本上，如果X為true，則跳15條指令並繼續。這很簡單，但是第一次很難正確顯示。我們沒有基於代碼的交互方式來查看屏幕輸出。必須等待批測試運行的打印輸出才能看到圖紙。
對於成千上萬個參數的初始值，有2種不同的預處理器-I-Load和K-Loads。我從未碰過任何K-Load東西。 I-load物料指定了初始值，這些初始值要么複製到存儲位置，要么根據其他輸入執行計算，然後將其他輸入複製到存儲位置。這些位置可以在RAM或在主要“ OPS”更改期間加載的磁帶存儲上。發射OPS 1/6。著陸的OPS 3。 OPS 2/8用於在軌物體。我的任務發生在任務前。 i-load運算符的優先級並非世界各地在數學課程中普遍教授和使用的優先級。 PMDAS-括號，乘法，除法，加法然後減法。通常，乘法或除法具有相同的優先級，但i-load工具卻沒有。加法和減法相同。因此，當我在導師的代碼中工作僅幾個月時，就在我的導師的代碼中發現了許多錯誤。我正在閱讀i-load手冊，並且足夠新，無法承擔任何責任。我的導師DC在那兒工作了至少5年，也許是10年。他非常聰明。他們進行了一次正式的代碼審查，我沒有準備，沒有準備。幾天后，我參考I-load用戶指南，完成了對他的代碼的審查，並詢問為什麼這些語句還行。他仔細閱讀，然後說我發現了其他所有人都錯過的許多錯誤。 IBM的正式審查（我們是其中的一員）被推遲了，他修復了問題，在內部進行了重新審查，然後在IBM寄出了新的審查。順便說一句，在代碼審查中發現錯誤非常罕見。每個人都非常努力地互相幫助。在小組工作的頭幾個月後，即使在我們內部審查的情況下，大多數程序員也不會在其代碼中發現任何錯誤。我們中的一些人每年內部都會發現1或2個錯誤。 IBM評論發現任何錯誤是非常奇怪的。我們使用戴明的統計過程控制方法來根據需要調整內部過程，以解決發現的任何錯誤。當我離開團隊時，每隔一年在代碼中發現1個錯誤。人們普遍認為，該軟件中保留了零個SEV-1錯誤。吉姆·奧爾（Jim Orr）在2010年創建了一份報告，該報告顯示1994年該代碼中存在100多個SEV-1錯誤，稍後將在FSW程序中找到該錯誤。我相信，SEV-1的錯誤是人員/車輛的損失。 http://www.slideshare.net/JamesOrr4/space-shuttle-flight-software-pass-loss-of-crew-errors-jk-orr-20150827-52150515
我們在地面上使用了基於MVS的大型機來構建所有運行TSO / ISPF的軟件。版本控制由IMS數據庫管理。 JCL用於向系統提交編譯，鏈接，測試，打印任務。我們有許多不同的工具可用來幫助研究代碼-使用ISPF宏語言或REXX（在我繼續學習之後）編寫的基本上不同的菜單用於搜索不同的代碼庫。每次飛行都有不同的代碼，但是大多數都是基於OIs來實現的。我從事OI8D-OI24的工作，並為OI25進行了一些規劃。我最喜歡的工具叫做HALSTAT。它提供了其餘代碼中有關模塊（文件）中使用的所有變量的報告。參考文獻，作業均具有不同的代碼。我認為代碼分別是2、4和6。從那時起，儘管c標籤和etag總比沒有好，但我在所有編碼中都想念HALSTAT。
那幾年我工作的某些系統是：
- 水車轉向重新設計（JP和合資企業）
- 2-Engine Out Abort（不記得整個團隊）
- 3-Engine Out Abort（SM，JP，LP是主要的，但每個人
- Mir Docking（BW和PD）
- 拖動滑道展開（主要用於PD）
- 主要著陸改進-基本上，他們正在吹輪胎，所以需要更平穩的著陸。如果您看一下1992年以後的降落，那麼感謝這段代碼，它們都非常非常平滑。
請注意，我當時在主齒輪著陸改進中引入了1個DR（1個錯誤通過了所有內部和IBM審查）。大約一年後，在6/7級測試中發現了它。第一年，我的同事發現了很多錯誤。在經過大約10個錯誤的1次非常糟糕的審核之後，我的老闆問我對這項工作是否滿意。基於縮進，我對要求的理解不同於其他人。確實是1個錯誤，但我是一致的。但是，在代碼中，大約有10個錯誤。當其他人發現您的錯誤時，這令人感到謙卑。我們是同一團隊的非常親密的成員。我們在復習紙上的簽名意味著重要的事情。我們永遠不會忘記生命危在旦夕，民族自豪感。
有很多其他項目和修復方法。
我不會錯過系領帶的感覺。 ;）我確實錯過了大約8-5小時的時間。
世界各地的任務控制軟件和有效載荷運營中心也完全不同。與團隊合作，用類似星際迷航NG的系統（主要運行DEC Alpha系統）和一些SunOS，HP-UX，AIX和Irix系統替換了阿波羅時代控制中心，並在後台進行了工作。作為參考，大約有600個Alpha和少於20個其他系統。當我們部署它們時，他們運行Unix變體OSF / 1，但名稱更改為Digital Unix……這是在Compaq購買DEC之前。幾年前訪問了MSFC，並看到了他們為太空站提供支持的POC。無法查看正在運行的操作系統，導遊也不知道。控制台家具與我們在1990年代初部署的家具完全不同。
我不知道有什麼方法可以運行PASS HAL / S軟件或使用硬件（在2017年）。操作系統不是交互式的。它僅與沒人會擁有或無法在家中使用的特定硬件進行通信。沒有DEU和飛行鑰匙輸入系統，操縱桿和數百個航空電子開關/旋鈕，我看不到如何使該軟件可用。有人需要為所有這些創建一個仿真層。
請記住，我所有直接的知識都在1990年代中期結束。事情可能會在程序的後面進行更新，這可能會改變很多事情。例如，我認為DEU被LCD屏幕取代了。我不知道是否有任何代碼更改可以支持該更改，即使他們不只是將它們放置在DEU的仿真層中。
在1990年代，我確實找到了用於Intel CPU的IBM 360/370 ASM仿真器。當時，即使運行我的初學者級IBM 360 ASM作業也不夠好。很難解釋軟件開發過程的複雜程度。一切都通過AP101電腦的MVS系統進行交叉編譯和交叉鏈接。
查閱了今天的NASA公共代碼檔案，搜索沒有找到任何與“班車”相關的代碼。很想了解GPE（模塊名稱）多年來的變化。
在其他地方可以讀到早期的HAL語言指南，但是HAL / S語言有所不同。例如，我不記得有任何方法可以在HAL / S中“打印”任何內容-並不意味著該指令已被刪除，但是沒有任何設備可以“打印”。輸入來自硬件設備，並存儲到變量中。輸出已寫入硬件設備。到我來的時候，所有的I / O東西都已經寫了很長時間並且可以正常工作，所以不需要學習它是如何發生的。
此外，我對任何特定任務都不了解。我的日常工作與目前的任務相去甚遠。在工作日，我們沒有停止觀看發射/著陸的情況。我們的代碼通常是在執行任務之前一兩年編寫的。我懷疑IBM會更嚴格地更改每個任務的代碼。在1995/96年左右，IBM組被出售給Loral，而這兩個組合併為一個團隊。有些人轉移到IBM內部，而另一些人則熱愛這項工作並留下來。 Perl，Python，Ruby，Java，C ++可以處理。至少對於簡單的1個模塊程序。也許與C ++最初作為C預處理器的方式類似。 p>
很抱歉，您的話題不對。希望有人會發現這有點有趣。