宋宏偉,孫泉明,方 靖,俞 偉
(1.浙江大學 計算機科學與技術學院,浙江 杭州 310012; 2.浙江方大智控科技有限公司,浙江 杭州 310012;3.浙江理工大學,浙江 杭州 310018)
作為智慧城市建設的重要組成部分, 以LED路燈+單燈智能控制為特點的智慧道路照明控制系統建設,已經逐漸得到用戶認可和日漸普及。但是在系統的建設、 運維過程中也存在不少問題,如:智能控制方案各有所長,標準不統一,無法實現互換及互聯互通, 導致后期運維被初始廠家綁定, 新廠家難以進入老市場; 系統功能沒有擴展性,難以接入新型設備,系統維護困難,導致維護工作量不降反增,達不到提高管理效率的目的。
針對以上問題,不少業主單位除了積極參與推動智慧道路照明控制系統全鏈條相關行業標準的制定外,還根據自己的需求,提出了不少解決方案,包括自定通信協議標準以實現互聯互通、采用統一標準接口以實現互換性、平臺建設單獨招標以保證對硬件設備的公平接入等。這些解決方案在一定程度上緩解了部分矛盾, 但是在實際操作過程中,離業主的期望還存在一定的距離。
我們可以通過電子產品充電器接口標準的制定歷程,來看看一個標準制定推廣的艱辛。
首先, 大量電子產品充電器規格不統一,設備更新過程中充電器浪費嚴重。為了解決這個問題,國家有關部門很早就提出了充電器標準化以實現設備更新可不換充電器的目標, 但是過程卻一波三折。
其次,直到2006 年,當時的信息產業部才發布了“YD/T1591-2006”標準,規定了充電器電壓轉換模塊和充電線之間的接口標準。但是對充電線和充電設備之間的接口標準,卻因為大量的電子產品生產廠家無法取得共識而沒有涉及。
截至目前,在已經淘汰了大量充電接口的情況下, 還是存在TYPE-C、Micro USB、Lightning 等事實接口標準, 電子產品銷售至少還得配一根充電線。 而第三方充電器供應商,不得不做出很多“創新”來兼容這么多的充電接口。
從上述例子可以看出, 要研制推廣一個標準,既需要解決技術上的問題,還需要解決利益上的問題。 幾個專家幾次會議編制一個標準,技術難度可想而知,利益方面的協調更是難上加難。 僅僅靠業主單位的有限力量來自定義一個標準,其實并不是一個比較好的選擇。
城市物聯網設備具有海量、通信異構及低速不可靠的特點。因此物聯網平臺的架構,與互聯網、局域網相比,有自己的特點。 下面是目前幾種物聯網平臺架構的介紹。
傳統的煙囪型架構如圖1 所示。早期的城市物聯網系統基本上都是這種架構,各個專項的管理系統像煙囪一樣,從設備層直達應用層,部分系統也可以以最簡單的方式,對本系統的數據做一個最基礎的共享。這樣建設的優點是:便于分步建設,事實上目前絕大部分煙囪型的業務系統,都是基于分管領域在不同時間內陸續建設起來的; 協調簡單,建設時只要滿足本領域需求就可以,最多關注一下上級系統的數據共享要求,不需要關注橫向系統的相關專業知識以及數據共享需求。 該架構的缺點是:大量的基礎數據重復建設; 業務數據難以共享;專業領域封閉,容易形成后來者進入壁壘。
養殖人員在整個龍蝦養殖過程中處于核心地位,大部分養殖工作都需要養殖人員去推進,由此可見養殖工作人員的重要性。但是,結合我國稻田淡水龍蝦養殖的實際情況來看,養殖工作人員的整體素質比較低,且大部分養殖工作人員年紀較大,接受新知識和新技術的能力較差,可以說非常不利于淡水龍蝦養殖技術的創新。隨著時代的發展與進步,稻田淡水龍蝦的養殖不僅需要豐富的專業技能和知識,而且要了解很多其他行業的知識,這就對養殖人員提出了嚴峻的挑戰。所以,提高相關養殖人員的素質是促進稻田淡水龍蝦養殖業發展的關鍵。

圖1 傳統煙囪型架構系統框圖Figure 1 System block diagram of traditional chimney architecture
統一協議型架構的系統框圖如圖2 所示。該類型的物聯網平臺架構以統一設備接入協議為基礎,經由接入層到達管理層進行統一管理;針對專業化的管理需求,則在其上再架構一層專項管理層。 該架構的優點是:建設成功以后,進行不同系統、不同行業間的聯動會比較方便;物聯網設備從基礎上解決了互聯互通的問題。 該架構的缺點是:建設前期需要充分理解各專項業務的概念和管理要求,協調任務艱巨;有些業務系統專業性非常強,通用化的建設滿足不了專業部門的使用要求,但是專項系統建設又可能欠缺更精細化的數據,增加這些數據還可能涉及到協議的更新和業務的理解;容易抹殺各專項系統積累的個性化特點。

圖2 統一協議型架構的系統框圖Figure 2 System block diagram of unified protocol architecture
統一頂層架構的系統框圖如圖3 所示。該類型的物聯網平臺架構通過接入層的適配,實現異構協議設備的統一管理, 并在其上架構專業應用層,部分關鍵操作及數據, 也可以直接與統一管理層交互。 該架構的優點是:建成后,不同系統、不同行業間的數據共享充分;關注于數據的集成應用,通過大數據進行建模分析, 可以極大提高城市管治水平。 但該架構的缺點是:數據模型建設需要充分理解各專項業務的概念和管理要求, 協調任務艱巨;專注于連接,接口規范的專業性不足會導致應用系統接入不容易,滿足不了專業部門的要求。

圖3 統一頂層型系統框圖Figure 3 Block diagram of unified top-level system
城市照明云平臺作為一個專項平臺,需要對整個城市的道路照明、景觀亮化、智慧燈桿等設施進行專業化的管理。 同時作為智慧城市大平臺的一個重要組成部分,它又需要和上級系統、安防、消防、停車等橫向系統以及第三方異構軟硬件進行集成。
根據業主單位的訴求, 并結合行業標準化現狀, 我們整理了理想的城市照明云平臺建設框架,如圖4 所示。

圖4 城市照明云平臺建議框架Figure 4 Suggested framework for urban lighting cloud platform
該框架支持終端-網關-管理平臺兩級硬件一級軟件模式設備、終端-接入平臺-管理平臺一級硬件兩級軟件模式設備以及終端-管理平臺一級硬件一級軟件模式設備的接入,能通過SDK/API/MQTT方式接入第三方設備, 也能通過設備SDK 接口文件和軟件平臺API 接口文件與其他系統交互。
與該框架配套的部署框架如圖5 所示。 必要時,也可以部署成內外網隔離模式。

圖5 城市照明云平臺硬件部署示意圖Figure 5 Schematic diagram of hardware deployment of urban lighting cloud platform
按照該部署框架,在系統小的時候,可以部署在一臺服務器上測試驗證, 隨著系統投入使用,可以視需要進行分拆部署。特別地,IoT 接入服務需保證單臺服務器5 萬IoT 設備的接入, 包括集控、網關、直連終端及其他需直接與接入服務器交互的智能終端設備。在這個框架體系下,WEB 層通過負載均衡來進行擴展,應用和數據庫層通過服務器集群來進行擴展,設備接入層則通過水平復制的方式進行擴展,以保證整個系統不少于200 萬個IoT 設備的接入。 系統盡可能采用通用、開源的底層支撐平臺,包括操作系統和數據庫,降低部署成本。
該平臺框架,可以通過以下幾種方式提供設備支持擴展能力。
(1)設備廠商提供設備及管理系統,并提供符合平臺標準的系統調用接口
平臺建設方定義好基礎接入接口標準,并通過調用這些標準的接口來實現基礎功能及數據的統一管理;設備初始化、日常維護等瑣碎功能,則還是由設備廠商提供的管理系統完成。這個方案的好處是:平臺可以專注于核心功能的實現, 不必分心于各類不同設備的差異,并且也解耦了建設先后順序。平臺建成后,新設備供應商,只要提供符合標準的接口,就可以順利集成應用。 這種方案,比較符合當前實際。
(2)設備廠商提供設備/系統及調用接口,由平臺廠商負責接入
該方案在平臺建設期間一般不會有大問題,主要問題在兩個方面:一是所有功能都需要平臺廠商實現,相對工作量是比較大的,如果平臺廠商僅熟悉軟件開發,對行業了解不深,就會造成比較大的隱患;二是平臺廠商撤場后,對接新產品就成為了難題。
(3)業主自定標準通信協議
該方案,業主保留了最大的控制權,同時也承擔了最大的變更責任,同時很可能抹殺專業廠商很多特色功能。另外,該方案對供應商來說是非標品,運維期的支持會成為比較大的問題。 因此該方案看起來很美好,但是單個業主推動的可行性比較差,建議業界共同努力, 力爭盡早推出國家級的標準供大家統一采用,徹底解決互換性和互聯互通的問題。
歐洲等地的照明系統,包括硬件和軟件,關注重點和國內略有不同,主要體現在兩個方面:道路照明線路基本上24 小時不斷電, 功能重點關注自動開關燈和信息上傳,不關注主動開關控制;管理平臺以大平臺為主,兼容各家硬件。
隨著國內市場的成熟,城市照明管理平臺的集中化、集成化,應該也是個趨勢,而按照目前的現狀,一步到位統一協議又暫時看不到前景。 因此業主和行業可以考慮從以下幾個方面逐步推進:建設完備的數據上傳下行接口, 成為智慧城市/城市大腦/智慧城管的有機分子; 搭建類似MQTT 服務器之類中介,并利用交付給業主的工具軟件來定義平臺與MQTT 之間的交互數據方案,設備廠商則負責保證設備或設備管理系統正確與MQTT 服務器交互,進一步解耦平臺和設備廠商;開發完善的數據分析模型,利用大屏進行監控中心業務值守。