沈文海

軟件是與計算機相伴相生的,氣象部門也是如此。
上世紀五、六十年代,氣象部門用于分析處理數據的工具,大致局限在算盤、手搖計算器范圍,鮮有電子計算機,遑論計算機軟件。
上世紀七十年代,氣象部門陸續引進了若干臺國產晶體管計算機(如DJS-108、131等),但由于這些計算機配置簡單,既無操作系統,更無標準的輸出存儲設備(如磁帶、磁盤等),甚至連鍵盤和終端顯示器都沒有,計算機操作員通過控制面板上的幾排不停閃爍著亮光的開關來操縱計算機的各種運行,而使用者只能以紙帶或卡片的形式將編寫的簡單程序(包括數據)通過光電機輸入,運算完畢后再通過寬行打印機將計算結果打印在打印紙上供使用者分析。那時由于計算機網絡還未出現,存儲方式簡單而不安全(紙帶、卡片),通用計算機語言尚不豐富(僅有如:Fortran、Basic、Arglo等),甚至連英文字母的計算機16進制碼都尚未統一(有EBCDIC碼和ASCII碼之分),氣象部門對計算機的應用多是以“程序”形式予以完成的,這些程序規模較小(≤1,000行),通過紙帶或卡片保存于個人手中。真正意義上的氣象軟件尚未出現。
氣象部門成規模的軟件,肇始于1980年初投入運行的BQS系統(世界氣象組織亞洲通訊樞紐)。BQS系統對于氣象業務的意義,在于建立起了實時獲取全球氣象觀測資料的路徑和手段;對于氣象IT的意義,在于所有的全球氣象觀測資料通信、數據的處理及繪圖等工作,全部由計算機自動處理完成。為此該項目引進了三臺大型計算機(日立M-160二臺,M-170一臺),所有業務功能全部由計算機軟件實現,而這些軟件全部由氣象部門的技術人員在日本專家的指導下設計、編制完成。
BQS系統的業務軟件,是我國氣象部門首個成規模的氣象軟件,也是我國氣象部門首次接觸到軟件工程這一概念和方法。
由于當時國內高性能計算資源奇缺,BQS系統引進的大型計算機(M160、M170)是當時世界上先進的計算機,在國內實屬翹楚,且這三臺大型機的內存、存儲、輸入輸出設備以及通用計算機語言等配置完整;因此這些大型機在業務空閑時段為全國以及氣象部門科研人員提供了良好的運算環境,我國第一代氣象預報模式(A模式)就是在這幾臺大型機上發育成長的。
作為世界銀行第一期農業貸款的使用單位之一,國家氣象中心于1984年購買了日本富士通的M360大型計算機以及相應的配套設備,用于氣象資料的分析處理,并在其上進行了我國第二代氣象預報模式(B模式)的研制和試運行。中國氣象科學研究院利用世界銀行第二期農業貸款,于1986年從法國引進了大型計算機DPS7,并在其上完成了中尺度模式MM4的引進和試運行。與此同時,一些國際通用的氣象繪圖軟件(如NCAR繪圖軟件等)也陸續在這些大型機上移植成功,提供使用。
上世紀八十年代前期和中期,高檔計算器PC-1500在一些省轄氣象觀測站的普及使用,為臺站觀測數據的處理和編報提供了便捷的手段。PC-1500內置有BASIC語言,并配有精巧的液晶顯示器、鍵盤和針式打印機,一些省局技術人員在其上編制了基于BASIC語言的氣象觀測站數據處理程序,實現了地面和高空常規觀測數據氣象要素的提取和換算以及報文編碼等項工作的半自動化處理。國家氣象局主管職能部門為此曾召開研討會,在對其進行相應完善后予以全國范圍內推廣。由于PC-1500上配有RS232串口,可連接盒式錄音機,為這套軟件的復制和推廣提供了便捷條件。
與此同期,氣象科學研究院通過從中科院獲得的五臺不同型號的Cormemco微型計算機,嘗試用BASIC語言編制高空氣象探測信號的全自動化處理軟件,并取得一定經驗。
1988年9月7日,我國第一個自行研制的氣象衛星“風云一號”A星發射成功。該衛星的地面接收系統的所有應用軟件全部由國家氣象衛星中心的技術人員自行設計并編制完成。這是繼BQS系統之后我國氣象部門又一個完全由部門內部組織設計開發完成的大型計算機軟件系統。
上世紀八十年代后期,以CONVEX-120為代表的“小巨型機”、以DEC-VAX系列為代表的“小型機”以及以IBM-PC為代表的具有工業規范意義的微機逐步進入氣象部門,UNIX和DOS作為通用操作系統開始在氣象部門普及。上至中大規模數值預報模式的研究和試運行,下至省地縣局常規氣象數據的分析處理,各種計算機應用在氣象部門全方位展開,相應的各種基于通用操作系統的氣象應用軟件也開始萌芽破土。由于“小巨型機”和“小型機”均可配有6250bpi磁帶驅動器以及各種當時流行的I/O設備(如3.5 軟盤驅動器),而IBM-PC標配有3.5 軟盤驅動器,這為各類氣象軟件和數據的復制、流轉和磁介質保存提供了條件。
上世紀九十年代初,微機開始在氣象部門進一步普及,從一個處室擁有一、二臺微機,到一個科、組擁有一、二臺微機,最后到每個技術人員擁有一臺微機,擁有程度逐漸大眾化。與此同時,微軟Windows圖形界面操作系統以及鼠標隨著微機進入到氣象部門的計算機房乃至辦公室,氣象數據的分析和展示開始向著可視化方向發展。
同樣在九十年代初,以“粗纜”和“細纜”為主要形式的辦公室網絡、以及以同軸電纜為主要形式的通用高帶寬局域網絡開始傳入氣象部門,同事之間、科室之間的實時數據通信開始出現。隨后不久,TCP/ IP網絡協議,以太網、令牌環、FDDI、ATM等網絡形式和概念隨著“9210工程”、國家氣候中心籌建、風云系列衛星地面測控系統建設等一系列大型項目和工程建設而進入氣象部門,局域網絡環境迅速形成。技術和科研人員告別了延續十余年的在計算機房集中使用計算資源的“上機”時代,開始自己的辦公桌上完成所有業務和科研工作。
1992年10月由國務院批復,代號為“9210工程”的氣象衛星通信系統工程,是氣象部門繼BQS系統之后又一個大型信息系統建設工程。該工程利用國產通信衛星亞衛-2號的星載富余帶寬,建立起國省地縣四級星型衛星通信網絡系統,徹底解決了困擾氣象部門數十年的氣象觀探測資料實時獲取難題,為天氣預報、氣候預測以及氣象服務等領域業務工作的快速發展奠定了堅實的數據基礎。“9210”系統(氣象衛星通信系統)與各級氣象部門已先后建成的本地局域網系統的有機結合,實現了各級氣象部門之間的遠程數據通信。
“9210”通信系統軟件由氣象部門獨立設計,采用部門內部大協作方式,集體開發完成。
“9210工程”在成功建立起全氣象系統的衛星通信網絡的同時,還計劃建立國省地縣四級氣象數據庫系統,為此引進了當時業界較為著名的Sybase數據庫系統,并隨工程建設的各種設備一道布設到各級部門。這是氣象部門首次接觸到業界規范的商用數據庫概念及系統。
“9210工程”的另一項成果,是著手開發了第一版用于天氣預報員分析天氣情況并制作天氣預報產品的實時交互式圖形/圖像桌面系統“氣象信息綜合分析處理系統”(即:MICAPS系統),填補了我國氣象部門在這一業務領域的空白。第一版MICAPS系統與“9210”通信系統一樣,完全由氣象部門自己設計、自行開發完成。限于當時的設備條件,第一版的MICAPS分別由工作站版和微機版兩個小組分頭開發。后隨著市場上微機性能和功能的快速提升,工作站版MICAPS逐漸淡出;自第二版起,MICAPS全部采用基于Windows的微機版。
自出生伊始,有關部門就注意營造MICAPS的生態環境。隨著時間的流逝,MICAPS至今已走過二十幾個春秋,版本更新到第四版,開發模式也由最初的自行設計、自己開發轉變成現在的軟件外包。
MICAPS是目前我國氣象部門最為知名的行業軟件之一。
上世紀九十年代,氣象部門先后從美國引進了巨型向量機CRAY/C92、巨型陣列機IBM-SP和IBMSP2、大型機Cyber-991/992等大規模和超大規模計算機設備,并同期引進了國產巨型機“銀河-I”、“銀河-II”及“曙光-100”等國產計算設備,為我國數值天氣預報模式的業務運行構建了較為完備的算力環境。短短幾年時間,T42、T63、T106等全球譜模式以及MM5等區域天氣模式紛紛業務化或準業務運行,天氣預報開始向著以數值預報為主要手段的方向發展。

與此同時,新組建不久的國家氣候中心也在積極從事氣候模式的研制、引進、調試和業務化工作,其主要模式有:CCM2、MOMs3及動力延伸預報等,這些工作大部分是在以服務器IBM-59H為主的相對簡陋的計算環境下完成的。
自1988年9月7日第一顆國產氣象衛星“風云-I號”A星始,至上世紀九十年代末,所有發射的風云系列國產氣象衛星的地面接收處理系統的軟件部分,都是由國家氣象衛星中心的技術人員設計、研發、調試并運行的。
也是在上世紀九十年代,以ArcGIS和MAPinfo為代表的地理信息系統進入中國大陸并迅速為氣象部門所接受,氣象服務部門和一些專業氣象(如農業氣象)部門積極應用這些新概念和新平臺拓展自己的工作領域,豐富自己的工作內容,并取得良好成效。與此同時,伴隨著工作站這一曇花一現的專用于可視化展示和制作的專用計算機的出現,一批繪圖軟件也隨之進入用戶視野,其中以SGI公司的GL庫最為著名。而在氣象繪圖方面,NCAR、Vis5D、GrADS等通用氣象繪圖軟件以源代碼或可執行程序形式出現在互聯網上,為氣象工作者所擁躉。其中GrADS以其適用計算機種類廣泛、操作簡單、便于個性化補充完善等特點,受到氣象從業者(尤其是科研人員)的熱捧。
同樣是上世紀九十年代中期,互聯網首先以email形式在氣象部門得到應用,相比較紙質信函郵遞,電子郵件大大提高了氣象工作者之間的遠距離通信時效——尤其是越洋跨國通信時效。很快地,氣象部門便出現了利用email成功進行越洋數據傳輸的事例。緊接著,瀏覽器開始出現并為氣象從業者所青睞,通過瀏覽器搜尋國外各大著名氣象單位網站上的各種信息,下載渴望已久的數據資料和軟件,成為不少氣象工作者上班期間的一項日常工作內容,GrADS繪圖軟件的迅速普及應用,就是這項工作內容的成果之一。由于互聯網上豐富的氣象數據資源,許多原本因缺乏相關數據而無法開展的業務工作因此而得以開展,一些單位甚至將國外網站上所發布的專業氣象數據作為本單位業務的數據來源,并為此建立了相應的業務系統,編制相應的下載軟件,以便定時下載獲取;其中的一些業務甚至延續二十余年,直至現在。
九十年代中后期,國家氣象中心依托DEC公司的小型機VAX6320開發出了我國第一套氣象實時資料數據庫,并正式投入運行,為國家級氣象業務單位提供由國際和國內通信系統所獲得的實時氣象資料服務。該數據庫的投入運行,在氣象部門內部首次實現了實時氣象資料的數據管理和共享,并為日后一系列氣象數據庫的建設進行了有益的探索和實踐。
也是在九十年代后期,國家氣象中心以引進的IBM Lotus/Notes為依托,首次在全氣象系統建立起辦公自動化平臺。該平臺最初以郵件、文字對話、日程安排、會議管理等為主要功能。該平臺以業務單位為節點,基本達到了受眾范圍的橫向到邊、縱向到底,從而使得氣象部門的辦公效率得以大幅提升。
同樣是在上世紀九十年代后期,由于“9210”工程、局域網以及計算機的普及,許多因計算資源和通信資源問題而被遲滯的業務工作因之而得以陸續展開,氣象各部門紛紛自己著手建設或完善領域內的各項業務工作,業務系統建設數量和規模明顯上升。由于氣象業務的特點,幾乎所有氣象業務系統的建設最終都將歸結到相關的氣象信息系統建設、歸結到軟件研發。而由于各單位相應技術力量和水平參差不齊,業務系統建設的質量亦出現較明顯差異。有鑒于此,有關職能部門在總結BQS系統和9210系統建設經驗,并參照當時國家頒布的相關標準規范的基礎上,編制并發布了《氣象信息工程建設規范》和《氣象軟件工程規范》,試圖以此來規范氣象部門內部的業務系統建設,保證工程質量。
二十一世紀初,中國氣象局抽調全國各省數值預報業務和科研骨干,成立了“數值預報創新基地”,開始研制國產數值預報模式GRAPS。在此前后,由于國產氣象衛星研制和發射計劃的有序進行,各待發射國產氣象衛星的地面接收處理系統需要一一設計和建設,國家衛星氣象中心為此成立了 “星地通公司”,專職于國產氣象衛星地面接收系統設計和研制。為進一步規范軟件研發過程,該公司特意引進了專門人才,以推進軟件工程理念、方法的貫徹和實施。華云信息科技有限公司(簡稱“華信公司”)則是在九十年代中期,依托“9210工程”而成立的信息系統集成公司,專司承接國家氣象中心中大型氣象軟件的研發任務。
二十一世紀頭十年,是氣象軟件高速發展的十年,除風云系列國產氣象衛星地面接收系統及相應的遠程數據傳輸系統外,國家級氣象資料管理系統、新一代國內通信系統、衛星視頻會商系統等一批基礎性工程陸續展開并完成。其中:國家級氣象資料存儲系統(MDSS)首次在國家級層面上實現了除衛星資料外所有實時和歷史氣象資料的統一規范化管理、服務。該系統首次運用商用關系型數據庫(ORACLE)實現了結構化氣象資料的規范化管理,實現了結構化、非結構化氣象數據的一體化管理,實現了熱、溫、冷數據的動態遷移和回遷,實現了氣象數據的規范化對外服務。
上世紀九十年代建成的“9210工程”首次實現了氣象觀探測資料的實時傳輸,具有劃時代里程碑意義。但由于所依托的通信衛星富余帶寬資源有限,無法適應日益增長的氣象觀測資料、數據和服務產品的傳輸需求。因此在新世紀之初,在三大運營商地面光纖寬帶通信迅速發展的背景下,依托地面光纖寬帶通信公共資源,國家氣象信息中心啟動、實施并完成了“光纖為主、衛星為輔”的新一代國內通信系統的設計和建設工作,為此后氣象觀測、預報和服務領域的高速發展奠定了堅實的通信基礎。
由于上世紀九十年代一系列大規模信息基礎設施的建設,氣象系統各業務部門終于擺脫了因計算、通信、存儲等IT基礎資源長期短缺所造成的窘境,業務創新與發展熱情空前高漲,業務系統建設遍地開花。一批涉及短時臨近預報、干旱預測、臺風、農業氣象等重要業務領域的業務系統,依托國內通信系統、Internet系統、數據庫系統、繪圖系統、地理信息系統等基礎性平臺而逐一建立或重建起來。這些系統以及相應業務軟件的建設,絕大部分是由項目所屬單位自行設計、開發、運行和維護的。
2008年,為貫徹執行國務院政企分離的重要指示精神,氣象部門內部采取了大規模行動,許多掛靠在各單位業務處室之下的小微企業紛紛關閉,中大規模企業如星地通、華信等公司則逐步獨立經營,與原有掛靠單位不再有直接往來。伴隨而來的是這些企業中的不少業務骨干紛紛或出走、或回歸業務單位,積累十余年的技術力量大量流失,令企業經營者痛心疾首,一時茫然不知所措。
政企分離措施對氣象軟件研發工作最直接的影響,是徹底斷絕了氣象部門內部自行研發氣象軟件的經費來源,迫使氣象部門轉而尋求社會力量,以軟件項目外包形式來完成氣象軟件的設計和研發工作。自此,氣象軟件逐步走上了“軟件研制項目化”的道路。
“軟件研制項目化”的直接結果,是使氣象部門擺脫了氣象軟件自己設計、自己研發、自己運行、自己維護的小作坊型生產模式,氣象軟件的規模不再受到限制,一些大型和超大型氣象軟件陸續被研制出來,同時軟件的質量得到了相當的保證。
“軟件研制項目化”的另一個結果,是軟件研發周期的確定性作為剛需被強制遵守。甲乙雙方在研制時間上都有明確要求,氣象部門作為甲方在付出費用后,希望能在預想的時間內得到滿意的結果——即便在需求一時梳理不清的情況下;而乙方出于企業經營考慮,更不可能無限期地在需求、功能和性能等方面與甲方無休止地磨合,需求在梳理到一定階段后必須凍結,后續跟進的軟件設計和研發一切以凍結時的需求為依據。而需求一旦固定下來,軟件的功能和性能也就隨之固定下來,研制出來的軟件以“產品”的形式提供給甲方,這就是所謂“軟件形態產品化”。
“軟件研制項目化”的再一個結果,是項目外包承接方的不確定性。由于軟件研制項目外包多采用招標形式,為公平起見,甲方不可能直接指定承接商,一切以投標企業的投標書和評標專家組的評判結果為結果。因此最終中標者很可能是甲方不熟悉甚至不中意的陌生企業。這對于一些以升級和更新換代為目標的氣象軟件的研制是相當不利的,因為陌生的中標企業對需要升級的原軟件不熟悉,而對于一個大規模軟件而言,由陌生到熟悉的過程,對甲乙雙方而言都是十分痛苦的過程。受到時間、人力資源和經費的三重壓力,多數情況下陌生的中標企業不可能投入充足的時間和人力資源來了解、熟悉并掌握原有軟件的各種技術細節,技術人員寧可推倒重來,在需求的基礎上重新研制一套新的軟件產品,也不愿埋頭一頁頁一行行閱讀原有軟件的各種技術文本,以求在字里行間中獲取原有軟件的設計理念、風格、方法和具體技術手段。新研制的升級軟件不是在原有軟件基礎之上繼承開發,而是在一片平地上另起爐灶、重打鼓另開張,原有軟件的繼承性受到破壞——即所謂“軟件升級斷代化”。
“軟件研制項目化”的最后一個較有影響的結果,是研制團隊的臨時性。從建設項目管理角度而言,研制團隊因項目而聚,項目結束而散,原本天經地義、無可厚非。然對于氣象軟件(尤其是那些關鍵業務的軟件系統)而言,如果沒有一支較穩定的團隊(甚或小組)對該軟件持續跟蹤,發現問題、記錄問題、分析問題并最終解決問題,或者將所有發現的問題歸納匯總,作為軟件下一個版本的需求內容之一,那么這個軟件實際上便置身于一種乏人問津的環境之中,敗枝無人修剪、干涸無人澆灌,聽憑其自生自滅,此即所謂“軟件生態荒蕪化”。
實事求是地說,并非所有氣象軟件都需要培育生態環境,如:國內通信系統、氣象衛星地面接收系統等,這些系統功能需求明確且不會變更,能力邊界清晰,并有其自身的特定運行環境和業務流程節點位置,只要運維措施得當,終其一生也不需要對其悉心觀察、小心呵護。
但也確有不少氣象軟件,因其最初的需求不確定、不完整或應對新情況需要調整增加新的功能,導致功能需求的不斷變化。這樣的情形在面向用戶的、以應用和服務為主要特征的氣象軟件中隨處可見。這種氣象軟件,與其說是產品,不如說是生命體,因為它一直處于生長變化狀態。而生長狀態中的氣象軟件,最為需要的就是良好的生態環境。
很遺憾,除MICAPS等僅有的幾個知名氣象軟件外,不少以應用和服務為特征的“生命體”氣象軟件,其所處生態環境并不理想,一些大型應用服務軟件因項目驗收后缺乏后續的應用培訓、推廣普及、技術交流和經驗總結等有效的生態培育機制的建立和落實,軟件項目的驗收之日,便是該軟件的凋零之始。即便主導者以行政命令強行推廣,也往往事倍功半,難收預期之功。過若干年后,根據形勢需要,不得不再以另一個單位,用另一個名稱重新再建一遍,令前番所做的所有工作全部消散于無形中。
所以,軟件研制項目化,軟件形態產品化、軟件升級斷代化和軟件生態荒蕪化,是十余年來困擾氣象軟件的幽靈。
對此,氣象部門并非束手無策,筆者認為至少有以下應對策略:
事實上,國內各大互聯網企業、電訊運營商、銀行等都擁有自己實力雄厚、技術精湛的軟件研發團隊,以滿足自身業務變更和發展的需要。氣象部門即便因各種原因不能擁有類似的機構,只能以項目外包形式實現業務發展目標,則起碼應當配置適當的技術崗位,擁有若干熟悉業務、了解技術、善于交流、掌握項目管理技能并具備一定組織能力的技術骨干,通過技術交流和項目管理等途徑,在項目執行過程中完美地貫徹甲方的業務意圖,而不是將所有管控工作悉數交予監理部門;同時,應當盡可能培育熟悉氣象業務的、有較強專業擅長的長期穩定的合作伙伴;以此來減緩因項目外包所可能導致的一些負面效應。
氣象部門的許多業務并非穩態,其功能是需要不時變化和更新的,有些業務需要快速發布,不斷更新迭代,這在氣象服務領域尤為常見;一些雖以“平臺”著稱,但用戶需要在其上進行各種開發應用的軟件平臺,也有功能不斷補充和組合的現實需求;采用經典的軟件工程方法研制和維護這類業務顯然存在缺陷。因此,氣象部門需要引進“敏捷業務”概念,以“穩態”和“敏捷”雙模式架構共同驅動業務發展。就軟件研制方式而言,氣象部門在以經典軟件工程為靈魂的軟件項目外包之外,需要引進敏捷開發模式,并著意培養掌握相應技能的敏捷開發技術骨干,以適應敏捷業務的各種需求;職能管理部門則需要給予相應的配套政策支持。事實上,相應的技術和研制模式(如“微服務”等)已經成熟,一些單位已經在具體應用了。
應用和服務型業務及軟件需要下大力氣培育良好的生態環境,以利其茁壯成長,這是常識;相應的方法和手段也盡人皆知;問題的關鍵在于貫徹和落實。這不是技術問題,而是機制和管理問題,且并非無解。故在此不予展開。
總之,氣象軟件的發展歷程充滿艱辛,成果輝煌。目前雖面臨諸多問題和挑戰,但這畢竟僅為行路上的羈絆,只要認真面對、積極思考、著力解決,發展的前景依舊光明。