前言:想要寫出一篇引人入勝的文章?我們特意為您整理了電力二次設(shè)備中容器技術(shù)的應(yīng)用范文,希望能給你帶來靈感和參考,敬請閱讀。
摘要:能源互聯(lián)網(wǎng)作為電網(wǎng)發(fā)展的新階段,海量設(shè)備的接入和數(shù)據(jù)量要求電力二次設(shè)備具備邊緣計(jì)算能力,實(shí)現(xiàn)電力相關(guān)設(shè)備實(shí)時(shí)感知、監(jiān)測及智能控制。為了快速部署、響應(yīng)用戶新業(yè)務(wù)新需求,提升邊緣設(shè)備的計(jì)算能力,介紹在設(shè)備上應(yīng)用Docker技術(shù)的方案,通過軟件APP化以及使用MQTT消息總線進(jìn)行APP間通信,提升電力設(shè)備運(yùn)維和計(jì)算能力。經(jīng)實(shí)際測試,該設(shè)備部署容器后軟硬件運(yùn)行正常,可通過遠(yuǎn)程運(yùn)維平臺管理裝置上的各類APP,具有較好的工程應(yīng)用前景。
關(guān)鍵詞:容器;邊緣計(jì)算;配電網(wǎng)
隨著能源互聯(lián)網(wǎng)和數(shù)字電網(wǎng)建設(shè)的持續(xù)推進(jìn),大量的傳感器接入,電力系統(tǒng)獲取的感知數(shù)據(jù)是海量級的,導(dǎo)致系統(tǒng)傳輸壓力大、主站計(jì)算負(fù)荷重。傳統(tǒng)的傳感信息獲取方式處理方式存在數(shù)據(jù)良莠不齊、數(shù)據(jù)缺失、格式不統(tǒng)一、數(shù)據(jù)處理不及時(shí)等問題,導(dǎo)致電力系統(tǒng)尤其是低壓配電系統(tǒng)存在故障定位時(shí)間長、事故處理響應(yīng)慢等痛點(diǎn)[1]。隨著終端側(cè)裝置數(shù)量日益增多,對電網(wǎng)中心化數(shù)據(jù)處理平臺提出更高的需求。為降低系統(tǒng)成本并防止中心化節(jié)點(diǎn)成為瓶頸,邊緣計(jì)算利用更接近用戶側(cè)的基礎(chǔ)設(shè)施,在網(wǎng)絡(luò)邊緣對數(shù)據(jù)進(jìn)行處理[2]。提供強(qiáng)大算力的邊緣計(jì)算技術(shù)方案可以將分散的電力設(shè)備作為數(shù)字電網(wǎng)的重要端口,在新一代信息技術(shù)支撐下,實(shí)現(xiàn)互聯(lián)互通,全面感知狀態(tài)、高效處理信息,形成數(shù)字化管理的強(qiáng)大生產(chǎn)動能,挖掘出大數(shù)據(jù)價(jià)值。其中邊緣計(jì)算設(shè)備作為提供算力的計(jì)算節(jié)點(diǎn),在邊緣側(cè)要滿足行業(yè)在實(shí)時(shí)業(yè)務(wù)、應(yīng)用智能、安全與隱私保護(hù)等方面的基本需求。如何動態(tài)地、按需隨時(shí)將計(jì)算算力下發(fā)部署到邊緣設(shè)備節(jié)點(diǎn)上,并保證各計(jì)算之間互相隔離互不干擾就成為了技術(shù)要點(diǎn)。以Docker為代表的虛擬化技術(shù)天然具備動態(tài)部署、隔離應(yīng)用的特性,因此在邊緣設(shè)備上應(yīng)用Docker技術(shù)能較好地適應(yīng)這種場景。
1Docker容器技術(shù)簡介
容器技術(shù)作為一種資源隔離的虛擬化技術(shù),其概念始于1979年提出的UNIXchroot。經(jīng)過多年發(fā)展,從最初的chroot到Jails、LinuxVserver、Solaris、OpenVZ、Process容器、Con-trolGroups到LXC以及現(xiàn)在火熱的Docker技術(shù)等。容器作為一個(gè)輕量級的虛擬化技術(shù),由應(yīng)用程序及其依賴構(gòu)成,并在Host操作系統(tǒng)的用戶空間運(yùn)行,與操作系統(tǒng)其它進(jìn)程隔離。在嵌入式裝置中應(yīng)用較多的是容器技術(shù)是Docker和LXC。LXC起源于cgroup(源自控制組群)和namespaces(命名空間)在Linux內(nèi)核方面的發(fā)展,它支持輕便的虛擬技術(shù)操作系統(tǒng)環(huán)境。LXC系統(tǒng)提供工具管理容器,先進(jìn)的網(wǎng)絡(luò)和存儲支持,還有最小容器操作系統(tǒng)模板的廣泛選擇。Docker的構(gòu)想是要實(shí)現(xiàn)“Build,ShipandRunAnyAPP,Anywhre”,即通過對應(yīng)用的封裝(Packing)、分發(fā)(Distribution)、部署(Deployment)、運(yùn)行(Runtime)生命周期進(jìn)行管理,達(dá)到應(yīng)用組件“一次封裝,到處運(yùn)行”的目的[3]。兩者差異如表1所示。Docker相對于LXC技術(shù),在可移植性、工具生態(tài)系統(tǒng)、開放兼容性、工具生態(tài)系統(tǒng)上等方面都更具優(yōu)勢,因此本系統(tǒng)采用Docker技術(shù)作為最終使用的虛擬化技術(shù)。
2系統(tǒng)硬件設(shè)計(jì)
本項(xiàng)目硬件平臺采用ZYNQ-7000系列芯片,包括片外Flash存儲、EMMC存儲、DDR內(nèi)存、模擬量采集、數(shù)字輸入輸出、串口RS485/232等[4]。該芯片性能強(qiáng)大,可以實(shí)現(xiàn)保護(hù)控制通信等多種功能,適合在電力設(shè)備上使用。其中片外Flash主要存儲用于啟動的u-boot、內(nèi)核鏡像、設(shè)備樹等文件,EMMC存儲文件系統(tǒng)、應(yīng)用程序及日志、數(shù)據(jù)信息。
3系統(tǒng)軟件設(shè)計(jì)
電力二次設(shè)備大多采用嵌入式Linux操作系統(tǒng),系統(tǒng)基礎(chǔ)軟件設(shè)計(jì)主要基于Linux操作系統(tǒng)構(gòu)建容器運(yùn)行環(huán)境、運(yùn)行APP、建立各APP間通信機(jī)制。其中容器運(yùn)行環(huán)境構(gòu)建主要包括:Linux內(nèi)核定制、容器基礎(chǔ)鏡像的構(gòu)建、APP鏡像的構(gòu)建。以下先介紹應(yīng)用整體框架,再分別介紹構(gòu)建容器環(huán)境的幾個(gè)環(huán)節(jié)。
3.1應(yīng)用整體框架
基于Docker容器技術(shù)的系統(tǒng)軟件總體結(jié)構(gòu)如圖1所示。在作為分布式計(jì)算系統(tǒng)應(yīng)用時(shí),計(jì)算任務(wù)需要分配到多個(gè)CPU、DSP才能完成,各CPU、DSP需要按照預(yù)定設(shè)計(jì)的目標(biāo)定時(shí)工作,并實(shí)時(shí)交換數(shù)據(jù)。因?yàn)槌R?guī)Linux系統(tǒng)實(shí)時(shí)性滿足不了電力系統(tǒng)中一些高實(shí)時(shí)的計(jì)算任務(wù),系統(tǒng)設(shè)計(jì)采用非對稱多進(jìn)程處理(AMP)模式,通過Linux+裸核的方式運(yùn)行;ZYNQ-7000處理器集成雙核ARMCortex-A9,可在其中一個(gè)核上跑Linux操作系統(tǒng),另一個(gè)核上進(jìn)行高實(shí)時(shí)性的運(yùn)算。其中Linux操作系統(tǒng)上每個(gè)業(yè)務(wù)APP都通過鏡像的方式運(yùn)行在容器中,通過docker設(shè)備映射功能訪問各外設(shè)設(shè)備,如配變交采類應(yīng)用可通過驅(qū)動設(shè)備文件獲取各類模擬量信息;系統(tǒng)管理進(jìn)程負(fù)責(zé)系管理系統(tǒng)中各類進(jìn)程;各APP與系統(tǒng)管理程序及APP之間通過容器間IP化技術(shù)和MQTT總線進(jìn)行各類消息主題的訂閱和。系統(tǒng)host上運(yùn)行遠(yuǎn)程管理模塊,通過網(wǎng)絡(luò)與遠(yuǎn)程運(yùn)維主站進(jìn)行通信;通過運(yùn)維主站進(jìn)行各容器APP部署下發(fā),遠(yuǎn)程管理模塊可解析命令進(jìn)行APP的安裝部署,同時(shí)可將各APP的運(yùn)行狀態(tài)上送給運(yùn)維主站,達(dá)到遠(yuǎn)程運(yùn)維的目的。
3.2Linux內(nèi)核定制
容器運(yùn)行在宿主機(jī)上,與宿主機(jī)共享內(nèi)核。容器的正常運(yùn)行依賴內(nèi)核自身的許多特性。因此在開發(fā)構(gòu)建容器的運(yùn)行環(huán)境時(shí),首先要定制相應(yīng)的內(nèi)核配置,以支撐容器的運(yùn)行。Docker運(yùn)行要求內(nèi)核版本不低于3.10。內(nèi)核中與容器緊密相關(guān)的最核心的特性是Namespaces命名空間和Controlgroups(cgroups)控制組。利用命名空間這一特性,每個(gè)容器都有獨(dú)立的命名空間,每個(gè)運(yùn)行其中的應(yīng)用都像是擁有了獨(dú)立的操作系統(tǒng),保證了容器彼此之間的互不干擾。命名空間提供了系統(tǒng)資源隔離的基礎(chǔ),其包括了進(jìn)程隔離、網(wǎng)絡(luò)管理接口、管理跨進(jìn)程通信訪問、管理掛載點(diǎn)、隔離內(nèi)核和版本標(biāo)識。內(nèi)核配置上需對以上命令空間進(jìn)行配置??刂平M是Linux內(nèi)核的另一個(gè)特性,主要用來對共享資源進(jìn)行隔離、限制、審計(jì)等,只有能控制分配到容器的資源,才能避免多個(gè)容器同時(shí)運(yùn)行時(shí)對宿主機(jī)系統(tǒng)的資源競爭。資源控制是Docker的基礎(chǔ),在Dockerd啟動過程就需要cpuset、cpu、cpuacct、blkio、memory、devices、freezer、pids,要保證各個(gè)控制組已經(jīng)掛載完成。另外Docker啟動時(shí)會使用iptables配置一些網(wǎng)絡(luò)規(guī)則等也會涉及一些內(nèi)核配置,不一一贅述。
3.3基礎(chǔ)鏡像及APP鏡像的構(gòu)建
采用Yocto框架來構(gòu)建基礎(chǔ)鏡像。Yocto的基礎(chǔ)使用方法,可參照Yocto官方文檔。構(gòu)建方法主要分為以下幾步:1)根據(jù)相應(yīng)的硬件平臺,設(shè)置對應(yīng)的BSP配置文件,并將配置文件設(shè)置為默認(rèn)BSP配置;2)進(jìn)行內(nèi)核recipe(配方)的配置。一個(gè)完整的OS由內(nèi)核和rootfs構(gòu)成,兩者需保持兼容。在構(gòu)建rootfs的過程中,必須要選擇和該內(nèi)核兼容的kernel來配置recipe;3)進(jìn)行rootfs的recipe配置。image用于指定需要編譯進(jìn)rootfs的軟件以及其依賴軟件。比如要使用Docker軟件,就需要將Docker以及相關(guān)的依賴,比如Docker-registry增加到image中;4)一些特殊的定制。通常會根據(jù)整個(gè)系統(tǒng)的兼容性和需求,調(diào)整相關(guān)軟件的版本和配置。比如容器只需要Docker,不需要lxc,需要設(shè)置runc的recipe;5)使用bitbake(構(gòu)建系統(tǒng))構(gòu)建相應(yīng)的版本。APP容器化的基礎(chǔ)是每一個(gè)APP都做成鏡像運(yùn)行??梢酝ㄟ^Dockerfile來進(jìn)行APP鏡像的制作。Dockerfile是一個(gè)文本文件,記錄了鏡像構(gòu)建的所有步驟。下面是一個(gè)Dockerfile的實(shí)例,baseimage是基礎(chǔ)鏡像,appname是要打包的APP,需在“/bin”目錄執(zhí)行。#DockerfileexampleFROMbaseimageMAINTAINERauthornameemail@xxx.comCOPYappname/binCMD/bin/appname將Dockerfile和appname放置在同一個(gè)目錄后,可通過如下命令制作APP鏡像。dockerbuild-tappimage.執(zhí)行完成后,就可以通過dockerimages命令查看到生成的APP鏡像。如果執(zhí)行的命令比較復(fù)雜,也可以做成一個(gè)shell腳本,同樣拷貝到鏡像中,編寫Dockerfile的時(shí)候CMD后面執(zhí)行shell腳本來運(yùn)行程序。如果應(yīng)用有依賴的lib庫,lib庫需要根據(jù)對應(yīng)的編譯鏈進(jìn)行編譯并打包到容器鏡像內(nèi)。
3.4APP通信機(jī)制
APP通信流程如圖2所示。在容器運(yùn)行環(huán)境下,各APP的通信設(shè)計(jì)基于以下原則:交互完全基于消息機(jī)制,以達(dá)到數(shù)據(jù)交互解耦,避免私有交互造成的管理復(fù)雜性;各APP開發(fā)統(tǒng)一的預(yù)留接口,保證互通互用?;谙C(jī)制,各APP間通信引入了MQTT總線。MQTT協(xié)議是一個(gè)客戶端服務(wù)端架構(gòu)的/訂閱模式的消息傳輸協(xié)議,設(shè)計(jì)思想是輕巧、開放、簡單、規(guī)范、易于實(shí)現(xiàn)。所有APP間通信可通過MQTT總線/訂閱消息,獲取系統(tǒng)資源以及APP交互,可提供一對多的消息分發(fā)和應(yīng)用間的解耦。具體的消息交互流程如下:1)MQTT消息總線提供訂閱主題接口,各應(yīng)用APP啟動運(yùn)行時(shí)需先進(jìn)行、訂閱數(shù)據(jù)主題注冊;2)對外提供數(shù)據(jù)的APP應(yīng)用,在生成新數(shù)據(jù)后調(diào)用總線消息接口進(jìn)行數(shù)據(jù);3)消息總線接收到數(shù)據(jù)后,將數(shù)據(jù)存儲至實(shí)時(shí)數(shù)據(jù)庫。消息總線在發(fā)現(xiàn)被訂閱的數(shù)據(jù)變化后,啟動主題推送程序,根據(jù)訂閱主題信息調(diào)用訂閱方接收接口,推送數(shù)據(jù)。
4應(yīng)用情況
本文完成了在嵌入式裝置上部署容器運(yùn)行環(huán)境,實(shí)現(xiàn)APP服務(wù)容器化的設(shè)計(jì)目標(biāo)。目前該技術(shù)已在某變電站遠(yuǎn)程運(yùn)維系統(tǒng)中成功應(yīng)用。該項(xiàng)目通過遠(yuǎn)程運(yùn)維平臺部署各容器/業(yè)務(wù)APP到電力裝置上,如104通信規(guī)約APP、停電告警、相序識別等;實(shí)現(xiàn)了數(shù)據(jù)的貫通,通過從底層驅(qū)動獲取到電壓電流等數(shù)據(jù)通過APP計(jì)算后,使用MQTT總線上送到IEC104APP等,驗(yàn)證了各APP間數(shù)據(jù)交互、消息發(fā)送的機(jī)制和可行性。同時(shí)對裝置資源的消耗和容器大小測試,其中容器鏡像文件大小根據(jù)實(shí)際應(yīng)用文件及依賴有所不同,一般在幾MB。系統(tǒng)運(yùn)行中CPU和內(nèi)存占用率有所上升,只是在原有基礎(chǔ)上增加幾十MB內(nèi)存的占用,對系統(tǒng)開銷影響不大。
5結(jié)束語
在能源互聯(lián)網(wǎng)建設(shè)的背景下,本文提出一種在電力設(shè)備上應(yīng)用Docker技術(shù)以及設(shè)備上各APP間通信機(jī)制的方法,并對相關(guān)的操作進(jìn)行了闡述。通過引入Docker技術(shù),實(shí)現(xiàn)了邊緣計(jì)算節(jié)點(diǎn)業(yè)務(wù)容器化、軟硬件解耦操作,為軟件APP化提供了實(shí)踐方法。在當(dāng)前運(yùn)維和部署服務(wù)越來越復(fù)雜的情況下,為實(shí)現(xiàn)電力行業(yè)的業(yè)務(wù)需求彈性擴(kuò)展、快速滿足用戶需求以及邊緣計(jì)算的應(yīng)用提供了有力支撐。為電力物聯(lián)網(wǎng)建設(shè)提供軟件平臺,提供了開源、開放式的環(huán)境,對電力設(shè)備開發(fā)提供一定的參考。
參考文獻(xiàn)
[1]張樹華,仝杰,張鋆等.面向能源互聯(lián)網(wǎng)智能感知的邊緣計(jì)算技術(shù)研究[J].電力信息與通信技術(shù),2020(18):4
[2]李彬,賈濱誠,曹望璋,等.邊緣計(jì)算在電力需求響應(yīng)業(yè)務(wù)中的應(yīng)用展望[J].電網(wǎng)技術(shù),2018,42(1):79-87
[4]楊保華,戴玉劍,曹亞侖.Docker技術(shù)入門與實(shí)踐[M].北京:機(jī)械工業(yè)出版社,2014
作者:吳汪兵 龔行梁 劉偉 單位:南京南瑞繼保電氣有限公司