您好,登錄后才能下訂單哦!
本篇內容主要講解“ServerSuperIO的相關知識點有哪些”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“ServerSuperIO的相關知識點有哪些”吧!
發展歷程
SuperIO&ServerSuperIO最早的雛形于2010年開始開發,當時主要是解決公司內部硬件產品眾多、協議眾多、以前的軟件經常出問題、維護成本高、搞集成系統時各方面都很累。經過兩三年的發展,確實解決了公司內部的產品體系問題,所有硬件產品都可以掛載到平臺下運行。離開公司之后,感覺這個平臺從代碼、應用等方面還有很大發展空間,2014年逐步產品化后才形成了SuperIO(SIO)這個平臺。
但是SIO也只是解決了設備驅動(眾多協議)插件式掛載的問題,不過只限于運行在Windows系列操作系統下,一般性的PC機和工控機上數據采集完全沒有問題。但是在運行效率方面還有很大提升空間、設備驅動的接口還可以進一步標準化(為了各層級都可以應用)、跨平臺運行必須攻克、設備(驅動)之間信息交互與控制必須實現、框架在不同層級應用的級聯與控制必須實現、多服務實例的應用等等,一系列的框架和技術性問題還可以進一步完善。從整體物聯網建設的框架性方面考慮,從2015年初開始,基于SIO的核心思想重新開發新一代物聯網框架,也就是現在的ServerSuperIO(SSIO)框架,經過兩年多的發展,搭載在智能網關的基礎上,可以形成綜合性的解決方案。
SSIO通信框架的設計思想是在SuperIO(SIO)基礎上發展而來,并沒有高大上的技術,主要是工作經驗的積累,適合于不同應用場景的物聯網的數據采集與交互。SSIO和SIO并不是簡單的對IO高性能的操作,而是設備驅動、IO通道、控制模式和實際硬件設備之間的協調機制,各方面之間無縫銜接和運行,也是為了解決現實工作和應用場景的一些痛點。
軟硬件之間的數據交互,并且面臨著復雜的現場環境:
(1)復雜的、多樣的通訊協議。有標準的協議,例如:Modbus等,也有很多根據標準協議修改的協議格式、以及自定義協議格式,并且千差萬別。對于不好的軟件架構,疲于應對,增加設備或協議要對整個軟件進行梳理,往往在此過程中出現新的問題或BUG。
(2)針對不同用戶對軟件界面或功能的要求有很大不同,使之滿足不同用戶的顯示要求,可以自定義數據顯示界面。那么就需要提供顯示視圖接口,與設備驅動進行交互。
(3)既然現場設備的數據被采集上來,那么就需要對其進行處理,不僅僅是保存、查詢、報表等,還有:數據轉發、數據輸出(OPC、模擬量、大屏等)等。那么就需要提供服務性的接口,與設備驅動進行交互。
(4)通訊鏈路的多種性,對于同一個設備可能要支持RS232/RS485/RS422、RJ45、3G/4G等通訊方式,所以對于一個設備要對應多種通訊方式(串口和網絡),也給我們的開發造成很大的障礙。
(5)設備驅動、IO通道和實際的現場硬件終端之間鏈路復雜,有可能:一個設備驅動對應一個IO通道、一個設備驅動對應多個IO通道、多個設備驅動對應一個IO通道等情況。
(6)既然設備與服務端進行數據交互,那么就應該對設備的通訊狀態、IO狀態、以及設備本身的狀態進行監控,這樣設備才處于可維護狀態。
(7)軟件各版本、以及軟件與硬件之間的兼容性很差,管理起來錯綜復雜。在框架平臺穩定的情況下,只需要更新設備驅動。
為了解決以上諸多問題,開發一個軟件框架,支持二次開發。在不對軟件框架改動的情況下,能夠很方便的接入設備、維護設備、集成設備、處理設備業務數據等。軟件框架相對穩定,把容易變化的部分進行靈活設計。
框架特點
輕型高性能通信框架,適用于多種應用場,輪詢模式、自控模式、并發模式和單例模式。
不光是通訊框架,是設備驅動、IO通道、控制模式場景的協調機制。
支持協議驅動器,可以按規范寫標準協議和自定義協議。
支持發送數據緩存器,支持命令緩存重發和按優先級別發送。
支持協議過濾器,按規則篩選數據,并且可以承繼接口,自定義過濾方式。
支持接收數據緩存器,可以緩存不符合過濾器的數據,和下次接收數據進行拼接。
支持按設備命令優先級別進行調度設備,保證有高級別命令的驅動及時發送。
支持一個設備驅動,同時支持串口和網絡兩種通訊方式,可以監視IO通道數據。
支持一個設備驅動,在網絡通訊時可以支持TCP Server和TCP Client兩種工作模式。
支持多設備共享同一IO通道進行通訊。
支持定時清理超時的網絡IO通道。
支持顯示視圖接口,滿足不同顯示需求。
支持服務組件接口,4-20mA輸出、LED大屏顯示、短信服務、以及多功能網關服務。
支持OPC Server服務。
支持創建多服務實例,完成不同業務的拆分。
支持跨平臺部署,可以運行在Linux和Windows系統。
設備驅動與設備驅動,設備驅動與服務器(云端)可以實時雙向交互,上傳數據和指令下發。
一套設備驅動,支持多種IO通訊
不管是zigbee、wifi、有線網絡,還是RS485、RS232、RS422,總之主要分為兩種硬件接口:網口和串口。至于OPC協議,可以用SSIO服務接口的形成間接實現,形成服務插件的一部分。如果不結構化的設計IO,網口和串口獨立存在,隨著產品越來越多,是很頭痛的一件事,也不一定運行穩定。對于ServerSuperIO框架,在此基礎上開發一套設備驅動可以分別實現通過網口或串口與硬件設備(傳感器)進行交互,非常方便。有人認為通訊很簡單,其實如果把眾多問題都考慮進去,那么將變得很復雜。也有很多純網絡通訊框架,業務場景、通訊機制的不同,純網絡通訊框架也未必能夠完全的適用于現場環境。根據多年的工作經驗,針對SSIO增加了通訊機制與應用場景,參見:《連載 | 物聯網框架ServerSuperIO教程》1.4種通訊模式機制。
示意圖如下:
物聯通訊的級聯
如果單單是采集硬件的數據與控制,也只能算是本地的系統,但是在物聯網和集成系統建設中,必須形成體系化、網絡化框架。所以ServerSuperIO在采集本范圍內的數據信息與控制外,還要形成與上一級的ServerSuperIO進行數據交互,以及接收下一級的ServerSuperIO的交互數據,那么ServerSuperIO之間就形成了級聯的關系,主要完成兩大職責:數據的級聯上傳和反向控制,進而對設備本身進行級聯控制。
結構示意圖如下:
設備之間的通訊、控制
采集與控制單個設備,在實際應用中還遠遠不夠,還要能夠設備與設備之間進行信息傳遞與控制,并且返回給發送控制源設備確認信息。例如:在監測流量計嚴重報警的情況下,是否應該調節或控制液體源頭的閥門。類似的例子很多。
在ServerSuperIO最新的3.1版本中(還沒有發布),支持設備向另一個設備發起傳遞信息和控制后,被控制設備是否立即返回確認信息,還是自主異步決定返回確認信息。增加了異步返回確認信息的功能,因為控制命令只是發給了另一個設備驅動,設備驅動還會進一步與實際的硬件設備進行交互,與實現硬件交互成功后,再返回確認信息給發起的源設備驅動。
示意圖如下:
與云端的交互、控制
ServerSuperIO提供了服務驅動的接口,一些除設備驅動類的功能以外,都可以以服務驅動的方式存在,例如:多設備采集的數據的融合模型計算、與其他平臺或上層進行交互等等,在此僅以與服務端進行交互為實例進行介紹。與設備驅動之間的交互與控制不同的是,設備驅動主動把采集的數據信息傳遞給服務驅動,服務驅動與云端進行交互,在接收云端指令后,發起傳遞信息或控制設備驅動,設備驅動再返回確認信息給服務驅動。
示意圖如下:
控制模式
(1)輪詢模式:當串口和網絡通訊時都可以使用這種控制模式。當有多個設備連接到通訊平臺時,通訊平臺會輪詢調度設備進行通訊任務。某一時刻只能有一個設備發送請求命令、等待接收返回數據,這個設備完成發送、接收(如果遇到超時情況,則自動返回)后,下一個設備才進行通訊任務,依次輪詢設備。如下圖:
(2)并發模式:只有網絡通訊時可以使用這種控制模式。并發通訊模式是集中發送所有設備的請求指令,框架是采用循環同步方式發送請求命令。還有進一步提高的機會,采用并行異步方式集中發送請求命令。硬件設備接收到指令后進行校驗,校驗成功后返回對應指令的數據,通訊平臺異步監聽到數據信息后,進行接收操作,然后再進行數據的分發、處理等。如下圖:
(3)自控模式:只有網絡通訊時可以使用這種控制模式。自控通訊模式與并發通訊模式類似,區別在于發送指令操作交給設備驅動本身進行控制,或者說交給二次開發者,二次開發者可以通過時鐘定時用事件驅動的方式發送指令數據。硬件設備接收到指令后進行校驗,校驗成功后返回對應指令的數據,通訊平臺異步監聽到數據信息后,進行接收操作,然后再進行數據的分發、處理等。
自控通訊模式可以為二次開發者提供精確的定時請求實時數據機制,使通訊機制更靈活、自主,如果多個設備驅動使用同一個IO通道的話,時間控制會有偏差。如下圖:
(4)單例模式:只有網絡通訊時可以使用這種控制模式。在一個服務實例內只能有一個設備驅動,相當于一個設備驅動對應著N多個硬件設備終端。更適合通訊的數據協議有固定的標準,以命令關鍵字處理不同的數據。適用于高并發的硬件終端設備主動上傳數據,服務器端根據數據信息進行處理和返回相應的數據。如下圖:
跨平臺
(1)Windows運行效果
(2)Linux運行效果
到此,相信大家對“ServerSuperIO的相關知識點有哪些”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。