EnOcean與KNX的IP網關及通訊網絡和方法
2023-06-08 23:14:31 2
EnOcean與KNX的IP網關及通訊網絡和方法
【專利摘要】本發明公開一種EnOcean與KNX的IP網關及其通訊網絡和協議轉換方法，實現了嵌入式Internet技術、KNX技術和EnOcean技術的巧妙融合，彌補了KNX技術在工程實施中需要布線、信息傳輸速率有局限等不足，同時又結合KNX本身易於擴展等優越性，為智能樓宇、智能家居項目實施提供便利性和靈活性，使用戶能方便地在Internet上對符合KNX總線協議的智能樓宇設備進行遠程監控和管理，同時也使得遠程設備維護和集成設備管理成為可能，還可以使設備主動地通過Internet獲取信息或發送信息，EnOcean終端設備不需要提供工作電源，極大的方便了實際工程中控制系統的搭建和集成，同時節約能源。
【專利說明】EnOcean與KNX的IP網關及通訊網絡和方法
【技術領域】
[0001]本發明涉及實現EnOcean網絡與KNX網絡連接的IP網關及基於網關的通訊網絡和協議轉換方法。
【背景技術】
[0002]EnOcean (易能森)是一種新型的無線傳輸技術，由德國易能森有限公司(EnOceanGmbH)提出，該技術同Zigbee、WiF1、Bluetooth、Z_Wave等無線技術相比最大的優點是極低的功耗，可以在ImW的發射功率傳輸距離超過300米。基於超低功耗的特性，該公司及其發起的易能森聯盟成員(EnOcean Alliance)開發出了一系列的無線、無電池、無限制的開關產品及傳感器產品以及和其他網絡傳輸技術銜接的網關產品。這些產品可以不用布線、免維護的運用於綠色節能智能建築、工業數據採集、儀器儀表及其他很多領域。Enocean產品目前有315MHz和868MHz兩種工作頻率。
[0003]2012 年 3 月，國際電工技術委員會(International ElectrotechnicalCommission)將EnOcean無線通信標準採納為國際標準「IS0/IEC 14543_3_10」，這也是世界上唯一使用能量採集技術的無線國際標準。該標準規範了協議棧中最底3層-物理層、數據鏈路層和網絡層-的通訊協議。EnOcean無線能量採集模塊由EnOcean GmbH生產銷售，並為EnOcean Alliance成員提供技術支持。基於這個平臺，原始設備生產商可以輕鬆且快速實現定製化的基於無線能量採集技術的無線開關傳感解決方案。
[0004]在中國，包括同方泰德、南京天溯、寧波杜亞、成都英泰力、深圳綠拓、北京沃克森、北京賽易科等一部分優秀的中國企業也相繼加入易能森聯盟，研發生產基於EnOcean無線無源技術的智能樓宇及智能家居系統，共享EnOcean創新科技帶來的綠色與節能。
[0005]KNX/IP網關是一個特殊的設備，在樓宇自控系統中，它既不屬於傳感器也不屬於執行器，而是一個協議轉換單元和系統節點。對KNX總線網絡而言，它是一個連接Internet的關鍵設備，外擴顯示、操作等單元，亦能作為KNX總線網絡的監控裝置，例如ABB公司的IG/S 1.1網關實現了 KNX總線和LAN連接，IN/S1.1和IN/S1.2則實現了 KNX總線和Internet的連接。KNX總線的協議數據單元F1DU (Protocol Data Unit)攜帶了能夠被總線設備接收到的控制和執行器發送出的反饋信息。基於KNX總線協議的嵌入式網關的研究和開發能夠為總線設備的遠程監控提供了良好的平臺。
[0006]1999年，KNX總線進入中國。廈門國際會展中心2000年8月開始運行，是KNX總線在中國的第一次成功應用。此外國家奧林匹克水上中心、大連國貿中心、北京朝陽區體育館、上海新國際博覽中心、浙江人民大會堂、杭州黃龍體育中心、上海春天花園別墅等都是KNX總線的成功應用案例。
[0007]EnOcean產品可以不用布線、免維護和超低功耗等特點，運用於綠色節能智能建築、工業數據採集、儀器儀表及其他很多領域具有很大的優越性，倘若將其與KNX和Ethernet相結合，EnOcean產品更易於實現系統化配置和集成，KNX系統可以被更好的擴充和延伸，加上Ethernet可以讓大數據流的傳輸更加順暢，發明一種EnOcean、KNX與 Ethernet之間數據轉換的網關為智能建築等領域的系統搭建提供很大的便利性。
【發明內容】
[0008]本發明的目的就在於提供一種實現EnOcean網絡與KNX網絡連接的IP網關及其基於此的通訊網絡和協議轉換方法，實現EnOcean、KNX與Ethernet之間的結合。
[0009]為實現上述目的，本發明採用如下技術方案:
一種EnOcean與KNX的IP網關，包括電源模塊，其特徵在於還包括:
EnOcean無線收發模塊,用於連接EnOcean側網絡；
KNX總線模塊，用於連接KNX側網絡；
Ethernet網絡模塊，用於連接IP側網絡；
處理器模塊，連接EnOcean無線收發模塊、KNX總線模塊和Ethernet網絡模塊，用於控制、協調網關的工作運行，實現EnOcean側網絡、KNX側網絡及IP側網絡之間的數據轉換，使EnOcean單向設備發出的報文被識別為KNX組播報文，EnOcean雙向設備被識別為網關的KNX虛擬通訊對象。
[0010]優選地:
EnOcean無線收發模塊包括EnOcean無線收發器,無線收發器提供連接EnOcean側網絡的EnOcean埠，並與處理器模塊的串口相連接。
[0011]KNX總線模塊包括KNX總線埠、KNX串口收發器和高速光耦模塊，KNX總線埠與KNX串口收發器相連接，KNX串口收發器與高速光耦模塊相連接，高速光耦模塊與處理器模塊的串口相連接。
[0012]Ethernet網絡模塊包括RJ45乙太網接口、乙太網控制器和網絡變壓器模塊，RJ45乙太網接口與網絡變壓器模塊相連接，網絡變壓器模塊分別與乙太網控制器的乙太網接口和乙太網信號發送指示燈模塊相連接。
[0013]進一步優選地:
Ethernet網絡模塊採用處理器模塊自帶的包含PHY和MAC的乙太網控制器。
[0014]電源模塊利用Ethernet網絡模塊的POE功能通過乙太網為網關提供工作電源。
[0015]基於上述EnOcean與KNX的IP網關，本發明的通訊網絡特徵在於KNX總線模塊的KNX總線埠與KNX總線相連接；EnOcean無線收發模塊的EnOcean埠與其周圍區域上的EnOcean無線中繼器和EnOcean其他無線終端設備進行無線通訊；多個網關通過Ethernet網絡模塊的乙太網埠與交換機相連接，交換機與監控中心計算機相連接，所述多個網關之間通過交換機的連接實現相互之間的數據交換。
[0016]本發明還提供一種EnOcean與KNX的IP網關的協議轉換方法，網關包括提供網關工作電源的電源模塊、用於連接EnOcean側網絡的EnOcean無線收發模塊,用於連接KNX側網絡的KNX總線模塊，用於連接IP側網絡的Ethernet網絡模塊及連接EnOcean無線收發模塊、KNX總線模塊和Ethernet網絡模塊的用於控制、協調網關的工作運行，實現EnOcean偵_絡、KNX側網絡及IP側網絡之間的數據轉換的處理器模塊，IP側網絡和KNX側網絡分別採用標準KnxNet/IP協議和標準KNX協議，其特徵在於處理器模塊對EnOcean單向設備和EnOcean雙向設備分別做不同處理:從IP側網絡或KNX側網絡看不到EnOcean單向設備，EnOcean單向設備發出的報文被識別為KNX組播報文；EnOcean雙向設備被識別為網關的KNX虛擬通訊對象。
[0017]本發明的EnOcean與KNX的IP網關及其通訊網絡和協議轉換方法，實現了嵌入式Internet技術、KNX技術和EnOcean技術的巧妙融合,可廣泛應用於智能樓宇、智能家居網絡，其彌補了 KNX技術在工程實施中需要布線、信息傳輸速率有局限等不足，同時又結合KNX本身易於擴展等優越性，為智能樓宇、智能家居的項目實施提供很大的便利性和靈活性。該設計方案使用戶可以方便地在Internet上對符合KNX總線協議的智能樓宇設備進行遠程監控和管理，同時也使得遠程設備維護和集成設備管理成為可能，還可以使設備主動地通過Internet獲取信息或發送信息，EnOcean終端設備可以做到不需要額外提供工作電源，利用自身的發電機制就可以滿足自身的用電需要，極大的方便了實際工程中控制系統的搭建和集成，同時節約能源。
[0018]本發明EnOcean與KNX的IP網關的一實施例中，Ethernet網絡模塊採用處理器模塊自身的乙太網控制器，省去了一個獨立的乙太網控制器，節省硬體成本的同時，縮小了硬體佔用的空間。
[0019]本發明EnOcean與KNX的IP網關的一實施例中，電源模塊利用Ethernet網絡模塊的POE功能通過乙太網為網關提供工作電源，無需額外配置KNX電源，在確保現有結構化布線安全的同時保證現有網絡的正常運作，最大限度地降低成本。
【專利附圖】
【附圖說明】
[0020]圖1是本發明的EnOcean與KNX的IP網關電路框圖；
圖2是本發明的EnOcean與KNX的IP網關電路簡圖；
圖3是本發明的KNX總線模塊的電路圖；
圖4是本發明的EnOcean無線收發模塊的電路圖；
圖5是本發明的Ethernet網絡模塊的電路圖；
圖6是本發明的電源模塊部分的KNX供電電路圖；
圖7是本發明的電源模塊部分的乙太網供電(POE)電路圖；
圖8是本發明的EnOcean與KNX的IP網關的協議轉換流程圖；
圖9是本發明的EnOcean與KNX虛擬通訊對象的對應表；
圖10是EnOcean串口通訊協議包結構圖；
圖11是本發明的EnOcean與KNX的IP網關的IP側報文處理軟體流程圖；
圖12是cEMI伺服器和cEMI客戶端之間的數據流圖；
圖13是KNX的IP報文結構圖；
圖14是KNX物理地址結構圖；
圖15是KNX組地址結構圖。
[0021]圖16是KNXnet/IP幀首部結構圖；
圖17是設備查找功能示意圖；
圖18是設備連結控制功能示意圖；
圖19是隧道功能示意圖；
圖20是基於本發明網關的嵌入式乙太網通訊網絡框圖。【具體實施方式】
[0022]實施例一
如圖1所示，EnOcean與KNX的IP網關的內部連接關係為:處理器模塊分別與電源模塊、Ethernet網絡模塊、KNX總線模塊、EnOcean無線收發模塊，負責控制、協調網關的工作運行，實現EnOcean側網絡、KNX側網絡及IP側網絡之間的數據轉換，
如圖2所示，處理器模塊採用TI的以ARM Cortex-M3為內核的LM3S9B92處理器，電源模塊採用LM2574-3.3P+晶片和乙太網供電的H)接口集成開關穩壓器LTC4267晶片，Ethernet網絡模塊採用LM3S9B92處理器自帶的包含PHY和MAC的乙太網控制器和網絡電壓器HX2019NL，KNX總線模塊採用KNX串口收發器E981.03晶片，E981.03可以提供高達50mA的直流電供系統工作使用，EnOcean無線收發模塊採用EnOcean無線收發器TCM310模塊晶片。
[0023]LM3S9B92處理器AUl的引腳12與光耦I的引腳2相連，LM3S9B92處理器AUl的引腳13與光耦2的引腳2相連，LM3S9B92處理器AUl的引腳16和引腳17分別與25MHz晶振的兩個引腳相連，引腳22、23、24和25分別與信號指示燈模塊1、2、3、4相連，引腳26與EnOcean無線收發模塊TCM210的引腳16相連，引腳27與EnOcean無線收發模塊TCM210的引腳15相連，引腳28與EnOcean無線收發模塊TCM210的引腳27相連，引腳37與Ethernet網絡變壓器HX2019NL的引腳9相連，引腳40與Ethernet網絡變壓器HX2019NL的引腳11相連，引腳43與Ethernet網絡變壓器HX2019NL的引腳16相連，引腳46與Ethernet網絡變壓器HX2019NL的引腳14相連，引腳41與電阻Rl的一端相連，引腳59、60分別與信號指示燈模塊5、6相連。
[0024]電源模塊:
出於電氣隔離方面的考慮，EnOcean與KNX的IP網關不能使用KNX總線模塊輸出的電流提供給網關工作電源，故需要一個獨立的KNX電源模塊給其提供電源。針對有些項目場合不方便獨立配置KNX電源模塊的場合，特別增加了乙太網接口的POE (Power OverEthernet)功能，通過乙太網給EnOcean與KNX的IP網關提供工作電源。
[0025]POE (Power Over Ethernet)指的是在現有的乙太網Cat.5布線基礎架構不作任何改動的情況下，在為一些基於IP的終端(如IP電話機、無線區域網接入點AP、網絡攝像機等)傳輸數據信號的同時，還能為此類設備提供直流供電的技術。POE也被稱為基於區域網的供電系統(POL, Power over LAN )或有源乙太網(Active Ethernet),有時也被簡稱為乙太網供電，這是利用現存標準乙太網傳輸電纜的同時傳送數據和電功率的最新標準規範，並保持了與現存乙太網系統和用戶的兼容性。POE技術能在確保現有結構化布線安全的同時保證現有網絡的正常運作，最大限度地降低成本。IEEE 802.3af標準是基於乙太網供電系統POE的新標準，它在IEEE 802.3的基礎上增加了通過網線直接供電的相關標準，是現有乙太網標準的擴展，也是第一個關於電源分配的國際標準。
[0026]電源模塊內部連接關係為:專用KNX電源接口與降壓穩壓器模塊相連接；乙太網接口及網絡變壓器與整流橋模塊相連接；整流橋模塊與乙太網供電的ro接口集成開關穩壓器模塊相連接；乙太網供電的ro接口集成開關穩壓器模塊分別與光隔離誤差放大器模塊、莫斯管和POE功率變壓器模塊相連接。降壓穩壓器模塊採用LM2574-3.3P+晶片，整流橋模塊採用DB107S晶片，乙太網供電的H)接口集成開關穩壓器模塊採用LTC4267晶片，光隔離誤差放大器模塊採用F0D2712晶片，POE功率變壓器模塊採用PA1279。
[0027]如圖6所示，專用KNX電源埠可外接24?30V的KNX標準電源，專用KNX電源埠的引腳I分別與TVS管BVD7的一端和整流橋BUR2的引腳I相連，專用KNX電源埠的引腳2分別與TVS管BVD6的一端和整流橋BUR2的引腳2相連，TVS管BVD6、BVD7的另一端接地，整流橋BUR2的引腳3分別與降壓穩壓器BU2的引腳10和電解電容BC21的正極相連，整流橋BUR2的引腳4與電阻BR17的一端相連，電阻BR17的另一端接地，降壓穩壓器BU2的引腳4、5、6接地，降壓穩壓器BU2的引腳12分別與二極體BVD5的負極和電感BLl的一端相連，二極體BVD5的正極接地，降壓穩壓器BU2的引腳3是3.3V電源輸出，其分別與電感BLl的另一端、電解電容BC22的正極、電容BC23的一端相連，電解電容BC21負極、電解電容BC22的負極及電容BC23的另一端接地。如圖7所示，POE (Power Over Ethernet)乙太網供電可以通過乙太網線提供EnOcean與KNX的IP網關工作用電，乙太網接口的引腳
4、5與整流橋BUR2的引腳I相連，乙太網接口的引腳7、8與整流橋BUR2的引腳2相連，網絡變壓器BTl的引腳2與整流橋BURl的引腳I相連，網絡變壓器BTl的引腳7與整流橋BURl的引腳2相連，整流橋BURl和BUR2的引腳3與乙太網供電的H)接口集成開關穩壓器BUl的引腳13和POE功率變壓器BT2的引腳3相連，整流橋BURl和BUR2的引腳4與乙太網供電的H)接口集成開關穩壓器BUl的引腳7和引腳12相連，BUl的引腳3與莫斯管的G極相連，BUl的引腳2與二極體BVD2的正極相連，二極體BVD2的負極與光隔離誤差放大器BU4的引腳2相連，POE功率變壓器BT2的引腳7、8與肖特基二極體BVD3的正極相連，肖特基二極體BVD3的負極是3.3V電源輸出。所述的降壓穩壓器模塊採用LM2574-3.3P+晶片，整流橋模塊採用DB107S晶片，乙太網供電的H)接口集成開關穩壓器模塊採用LTC4267晶片，光隔離誤差放大器模塊採用F0D2712晶片，POE功率變壓器模塊採用PA1279。
[0028]Ethernet 網絡模塊:
處理器LM3S9B92自帶乙太網控制器，其由一個完全集成的媒體訪問控制器(MAC)和網絡物理(PHY)接口。該乙太網控制器符合IEEE802.3規範並完全支持10BASE-T和100BASE-TX標準，同時還具支持多種工作模式、高度可配置、支持物理媒體操縱、支持用微型直接內存訪問(μ DMA)有效的傳輸數據等特點。採用處理器自身的乙太網控制器，省去了一個獨立的乙太網控制器，節省硬體成本的同時，縮小了硬體佔用的空間。
[0029]Ethernet網絡模塊內部連接關係為:RJ45乙太網接口與網絡變壓器模塊相連接，網絡變壓器模塊分別與處理器的乙太網接口和乙太網信號發送指示燈模塊相連接。所述的網絡變壓器模塊採用HX2019NL。
[0030]如圖2和圖5所示，RJ45乙太網接口 BXJ3的引腳1、2、3、6分別與網絡變壓器BTl的引腳1、3、6、8相連接，網絡變壓器BTl的引腳9、11、14、16分別與處理器LM3S9B92的引腳37、40、43、46相連接，網絡變壓器BTl的引腳16同時還與與門晶片BU3的引腳1、2相連接，網絡變壓器BTl的引腳10、15同接3.3V直流電，與門晶片BU3的引腳7與電阻BR18的一端和電容BC24的一端相連接，電容BC24的另一端接地，電阻BR18的另一端與發光二極體BHLl的負極相連接，發光二極體BHLl的正極接3.3V直流電。所述的網絡變壓器模塊採用HX2019NL，與門晶片採用NC7WZ08晶片。
[0031]KNX總線模塊:
KNX的總線接口晶片在不斷的進化。原先有西門子公司推出的KNX雙絞線收發器FZE1066晶片，該晶片能提供5V直流電源，支持溫度管理，該晶片的數據收發是以比特(bit)作為收發單位，這樣處理器發生中斷就會很頻繁，同時接收數據時的比特組合和發送數據時的字節拆分等工作佔用較多的處理器時間，因此不太適合應用於需要處理較多不同中斷的KNX系統元件設備中。後來西門子公司又推出了 KNX-TP-UART-1C晶片，該晶片與處理器之間可以選擇9600bps或19200bps的波特率進行串口通訊，以字節(byte)為單位收發晶片本身能緩衝一整包的報文，處理器將整個報文發給KNX-TP-UART-1C晶片後，再由晶片發送到KNX總線上，只是該晶片只能提供20mA的工作電流，且價格比較貴。而E981.03晶片的功能與KNX-TP-UART-1C晶片一致，能提供高達50mA的電流，且價格相對便宜，因此選擇此晶片比較合適。
[0032]KNX總線模塊內部連接關係為:KNX總線埠與KNX串口收發器模塊相連接，KNX串口收發器模塊與高速光耦模塊相連接，高速光耦模塊與CPU的串口相連接。所述的KNX串口收發器模塊採用E981.03晶片，高速光耦模塊採用HllLl晶片。
[0033]如圖3所示，KNX總線的正極分別與二極體AVD2的正極和TVS管AVDl的一端相連接，KNX總線的負極及TVS管AVDl的另一端連接KNX總線模塊的電源地，二極體AVD2的負極與KNX串口收發器AU2的引腳12和電容AC22的一端相連接，電容AC22的另一端與KNX串口收發器AU2的引腳8相連，KNX串口收發器AU2的引腳10、11分別與電阻AR12的兩端相連，AU2的引腳14與鉭電容AC23的正極相連，鉭電容AC23的負極電源接地，KNX串口收發器AU2的引腳15與電容AC24和AC26的一端以及電解電容AC25的正極相連，電容AC24的另一端和電解電容AC25的負極均接電源地，電容AC26的另一端與KNX串口收發器AU2的引腳16相連，KNX串口收發器AU2的引腳17與穩壓管AVD3的正極和電感ALl的一端相連，AU2的引腳18、19與電感ALl的另一端、鉭電容AC27的正極、電容AC28的一端相連，AU2的引腳23、24分別與晶振AG3的兩個引腳相連，KNX串口收發器AU2的引腳25與高速光耦AU4的引腳2相連，AU2的引腳26與高速光耦AU3的引腳4相連，高速光耦AU3的引腳2與LM3S9B92處理器的引腳13相連，高速光耦AU4的引腳4與LM3S9B92處理器的引腳12相連。所述的KNX串口收發器模塊採用E981.03晶片，晶振頻率選擇7.3728MHz，高速光耦模塊採用HllLl晶片。
[0034]EnOcean無線收發模塊:
EnOcean無線收發器模塊TCM310能夠實現868 MHz的無線電系統的網關功能，它提供了 一個雙向無線通訊接口和一個雙向串行接口。與之雙向串行接口連接的處理器可以通過它透明的收發無線數據，處理器可以通過它發送無線控制命令，例如配置中繼器功能或管理智能ACK功能等。TCM310利用它的智能ACK技術可以充當「郵件管理員」管理多達15個雙向傳感器。
[0035]如圖2和圖4所示，EnOcean無線收發器AU5的引腳2與電容ACll的一端、電解電容AClO的正極和電感AL2的一端相連，電感AL2的另一端接3.3V直流電源，電容ACll的另一端和電解電容AClO的負極接地，EnOcean無線收發器AU5的引腳23接3.3V直流電源，AU5的引腳15接處理器LM3S9B92的引腳27，AU5的引腳16接處理器LM3S9B92的引腳26，AU5的引腳27接處理器LM3S9B92的引腳28。
[0036]本發明的EnOcean與KNX的IP網關還包括用於人機互動的人機接口模塊，包括編程按鈕和信號指示燈。[0037]隨著Linux的持續發展，其代碼結構更加清晰，資源的定義和分類更加明確，可讀性很強，條理清楚，修改起來容易，其支持標準的高級電源管理，更加省電。將嵌入式作業系統Linux移植到EnOcean與KNX的IP網關硬體平臺，作為EnOcean與KNX的IP網關的軟體平臺，在Linux軟體平臺上運行EnOcean與KNX的IP網關的應用軟體，提高了軟體的設計效率。
[0038]本發明對EnOcean的處理方法為:單向不可見，即IP側網絡的其他設備和KNX側總線的其他設備收到來自網關的關於EnOcean的報文均被識別為KNX的組播報文；雙向被識別為KNX的一部分，即與網關發生通訊聯繫的EnOcean無線終端設備均被識別為網關的KNX虛擬通訊對象。本發明的EnOcean與KNX的IP網關的IP側和KNX側分別採用標準KnxNet/IP協議和標準KNX協議。
[0039]本發明的EnOcean與KNX的IP網關的協議轉換方法如下:
如圖8所示是本發明的EnOcean與KNX的IP網關的協議轉換流程圖，EnOcean與KNX之間通過相關協議進行相互轉換，IP與KNX之間進行相互轉換，IP側是不能直接看到EnOcean側的。網關內部對EnOcean單向設備(如EnOcean傳感器等只發送數據不接收數據的設備)和EnOcean雙向設備(如EnOcean執行器等既接收動作指令又反饋狀態的設備)分別做了不同處理:從Ethernet側或KNX側看不到EnOcean單向設備，EnOcean單向設備發出的報文被EnOcean與KNX的IP網關接收後，重新封裝成標準的KNX組播報文，根據過濾規則轉發到Ethernet側或KNX側；En0cean雙向設備被識別為KNX虛擬通訊對象。EnOcean無線收發模塊對外採用EnOcean無線通訊協議(ERP)與EnOcean側網絡的其他EnOcean無線模塊(接收模塊、發送模塊或收發模塊)進行數據交換，採用EnOcean串口通訊協議(ESP)跟與它相連的處理器進行數據交換。處理器通過網關的EnOcean無線收發模塊與EnOcean側網絡的其他EnOcean無線模塊(接收模塊、發送模塊或收發模塊)建立通訊，獲取這些EnOcean無線模塊所屬設備的設備類型，然後將這些被識別的EnOcean設備映射成本發明的網關的KNX虛擬通訊對象，並在處理器模塊中形成如圖9所示的EnOcean與KNX虛擬通訊對象的對應表，例如圖中通訊對象編號1、2所分別對應的是設備ID為0x00018C3B的EnOcean執行器的開關動作和開關狀態反饋，通訊對象編號5所對應的是設備ID為0x00018C43的EnOcean傳感器輸入信號，通訊對象編號7、8所分別對應的是設備ID為0x00019Cll的EnOcean兩鍵面板的兩個開關輸入信號。由此網關的KNX側和IP側對EnOcean的通訊都變成了對KNX虛擬通訊對象的通訊。
[0040]EnOcean側網絡的其他EnOcean無線模塊收到無線數據後，將無線數據根據EnOcean串口通訊協議進行轉換,然後通過網關的EnOcean無線收發模塊通過串口發送給與之連接的處理器，EnOcean串口通訊協議報文結構如圖10所示，處理器收到串口的數據後，先同步同步字節(sync byte)，然後讀報文頭(header)，報文頭裡面有無線報文的數據長度，然後做CRC，之後按照數據長度取無線報文數據內容(即無線報文部分)，其中的choice為應用類型,如按鍵開關為RPS類型,則可以解讀後面的user data, 0x50為按鍵按下,0x00為按鍵鬆開,Sender ID是無線發送報文EnOcean無線模塊的獨一無二的身份ID,通過它可以識別與網關通訊的EnOcean無線設備，以在網關內組建KNX虛擬通訊對象。
[0041]圖11是EnOcean與KNX的IP網關的IP側報文處理軟體流程圖，圖13是KNX的IP報文結構圖。IP側主要支持以下4個方面的服務類型:核心規範、設備管理、隧道和路由。相對應的服務類型號範圍為:
0200h …020FhKNXnet/IP Core (核心規範)
0310h …031FhKNXnet/IP Device Management (設備管理)
0420h …042FhKNXnet/IP Tunnelling (隧道)
0530h …053FhKNXnet/IP Routing (路由)
其中，核心規範服務是其他服務的基礎，設備管理、隧道和路由的實現需要核心規範服務的支持。
[0042]EnOcean與KNX的IP網關中，KNXNet/IP數據報的主機協議是IP協議，即KNXNet/IP數據報是IP報文的數據。當KNXnet/IP數據包在IP通道上傳輸時，將封裝KNX數據包的IP報文發送給該IP通道上的其他KNXnet/IP設備。通過用單播IP位址列表的方式來規定IP通道，其對每個KNXnet/IP設備都有一個準確的IP位址。在一個IP網絡上的KNXnet/IP設備數量沒有最高限值。UDP在傳輸通過隧道的KNX數據報文時更有效率，但由於缺乏可靠的分發服務，它不能保證數據包的排序。支持AutoIP的設備能夠給它自己分配一個單播 IP 地址，範圍在 169.254.1.0 到 169.254.254.255 之間。
[0043]IP側的系統啟動多播地址與路由多播地址是有區別的，系統啟動多播地址為224.0.23.12 ;實現KNXnet/IP路由的任何KNXnet/IP設備都有一個「路由多播地址」。該地址是通過增加偏移從「系統啟動多播地址」獲得。此地址預設值為O。如果一個項目中有多於一個安裝，則在不同安裝中的KNXnet/IP路由器分配給不同的路由多播地址。一個KNXnet/IP設備應有一個單播IP位址，應屬於至少一個IP多播組，並且可以能夠屬於最多16個多播組。埠號為3671的`KNXnet/IP用於發現端點。它也可用於發現數據和控制端點。這不是強制的。響應C0NNECT_ REQUEST而返回的KNXnet/IP伺服器埠號可為任何有效的埠號。設備管理應使用通用KNXnet/IP埠號3671。
[0044]EnOcean與KNX的IP網關的4個方面的服務類型:核心規範、設備管理、隧道和路由中，後三個服務的實現是需要cEMI來進行數據處理的。cEMI是一種通用結構的媒體無關/[目息，它可以被加入時間戮等?目息。圖12是cEMI /[目息流的不意圖。
[0045]核心服務:
字節順序是大端模式。KNXnet/IP結構通用規則是第I個八位位組總是該完整結構的長度(因為某些結構可能有變長度的欄位，例如:字符串)，第2個八位位組總是規定該結構類型的標識符。從第3個八位位組開始是結構數據。如果數據總數超過252個八位位組，則長度八位位組應為FFh，其後的2個八位位組應包含16比特長度值，那麼從第5個字節開始是結構數據。
[0046]KNXnet/IP幀首部如圖16所示。首部長度可被用作KNXnet/IP幀數據的索引，用來確定KNXnet/IP幀體的起始位置。服務類型標識符的高八位位組指示服務類型類，低八位位組指示在該服務類型類中的實際服務類型。總長度包括完整的KNXnet/IP幀，以KNXnet/IP首部的首部長度開始並包括整個KNXnet/IP幀體。
[0047]核心服務包括以下功能: η設備查找功能和設備描述
對於支持熱插拔和可能在運行狀態下分配地址的網絡，發現和自我描述可以避免通過非標的途徑或通過手動方式建立連接來找回網絡屬性，而且通過它可更精確的知道設備所支持的服務。
[0048]發現規程(設備查找)見圖17。
[0049]注意:發現端點通信僅允許使用UDP。
[0050]發現操作由SEARCH_REQ數據包構成，SEARCH_REQ數據包通過使用發現端點的多播發出，該發現端點包含KNXnet/IP客戶機發現端點的HPAI。HPAI可包含一個單播IP位址，以接收直接來自點對點模式下不同KNXnet/IP伺服器的應答。通常HPAI應包含KNXnet/IP系統設置多播地址以確保接收來自不同子網上的KNXnet/IP伺服器的數據包。任何KNXnet/IP伺服器應通過處理發現請求並發送正確的響應來支持發現。HPAI (主機協議地址信息)是向另一個設備發送KNXnet/IP幀所要求的數據。主機協議地址信息(HPAI)是主機協議中唯一要求識別通信通道的地址信息。在不同的主機協議中HPAI的長度是不同的。HPAI的具體定義可參考KNXnet/IP規範中主機協議相關的附錄。當響應DESCRIPTION_REQ時，KNXnet/IP伺服器使用描述信息塊(DIB)結構返回設備信息的特定信息塊。應利用(I)設備硬體和(2)所支持的服務類中有關的設備能力信息，返回至少兩個DIB結構。在一個描述響應數據報中可以返回兩個以上的DIB結構。每個DIB的第I個八位位組包含DIB結構的長度，第2個八位位組描述DIB結構類型。DIB的實際數據在其後。該結構應總是有偶數個八位位組，可以通過在DIB結構的最後一個八位位組後添OOh來實現這種偶數個八位位組。
[0051]η設備連結控制功能
連結控制主要用在需要點對點通訊的服務場合，如設備管理和隧道。點對點通訊由客戶機進行初始化，所有的伺服器至少同時接受一個客戶端與其建立連接(新建的連接不能影響既有的連接)，見圖18。
[0052]連結控制包括了連結請求和回復、連結狀態請求和回復、斷鏈請求和回復。
[0053]設備管理:
用於路由設備本身的管理，比如私有地址配置、參數下載等。先連接後使用，使用設備管理時，需要通過傳輸層建立KNX的傳輸層連結。通過cEMI伺服器進行數據處理。對於下載，所有的參數值都應該表達成「大端模式」，所以總是首先傳輸最高有效字節。如果一個伺服器支持多於一個KNX子網連接，則要求每個KNX子網由一個不同的控制端點來表示。
[0054]設備管理定義了兩類服務，分別是DEVICE_C0NFI⑶RATION_REQUEST和DEVICE_CONFI⑶RAT10N_ACK。
[0055]KNXnet/IP伺服器為每個已建立通信通道分配一個通信通道ID。每個通信通道維護一個序列計數器。對於在數據連接上發送的每個KNXnet/IP幀，每個通信通道的序列計數器加I。維護該通信通道的KNXnet/IP設備有獨立的序列計數器。每次建立一個連接，該連接的計數器被置0，所以在已建立通信通道上發送的第I個KNXnet/IP幀的序列計數器為O。
[0056]隧道:
隧道功能一般用於通過網關進行別的設備管理的應用，見圖19。KNX設備和ETS間的數據交換是通過「非KNX」網絡實現的。使用cEMI報文通訊。先連結後使用。隧道的特徵是由ETS在IP幀內發送單獨的報文，然後等待直到接收到響應或超時。KNX報文總是在TUNNELING_REQUEST幀中發送。每個KNXnet/IP隧道連接應由一個獨立的KNX地址響應，即當隧道連接被建立時，KNXnet/IP伺服器給它分配一個獨立的KNX地址。在CONNECT_RESPONSE 巾貞 Connection Response Data Block (CRD)中返回這個獨立的 KNX 地址。如果KNXnet/IP給隧道連接分配它自己獨立的KNX地址，那麼通過隧道報文或KNX子網管理KNXnet/IP伺服器是不可能的。KNXnet/IP伺服器自身的KNX單個地址是通過ETS獲得的，該地址可被用於上面所指的隧道連接。任何附加隧道連接的KNX單個地址由ETS分配。附加的 KNX 單個地址存儲在屬性 PID_ADDITIONAL_INDIVIDUAL_ADDRESSES 中。
[0057]KNX數據鏈路層上的隧道是強制的。如果KNXnet/IP伺服器也實現KNXnet/IP路由，那麼它不應使用它自己的KNX單個地址，而應採用上述的KNX單個地址。
[0058]除非已使用KNXnet/IP設備管理設置了至少一個附加的獨立KNX地址，否則KNXnet/IP路由器不應激活KNXnet/IP隧道。如果隧道客戶機發送一個帶有KNX單個地址(KNX源地址)被設置為OOOOh的cEMI幀L_Data.req,那麼隧道伺服器應進入分配給該隧道連接的KNX單個地址。否則，應不更改KNX報文進行發送。
[0059]路由:
在KNX設備之間通過IP網絡實現點對多的通信時，用到路由服務功能。該服務通過路由服務命令實現報文路由，無連結，採用cEMI報文格式。KNXnet/IP路由被定義為以一對多通信關係(多播)進行通信的一系列KNXnet/IP路由器，KNX數據通過該路由在IP網絡上從一個設備同時傳輸到多個其他設備。
[0060]ETS對KNXnet/IP設備應執行如下的地址分配規則:如果KNX幹線耦合器地址(x.0.0)已經分配了另一個KNXnet/IP路由器，或者一個或多個KNX線路耦合器已經分配了 KNX線路耦合器地址(X.y.0)(其中:y= [I...15])，那麼KNXnet/IP路由器不應分配KNX線路耦合器地址(X.y.0)。如果一個或多個KNXnet/IP路由器已經分配KNX線路耦合器地址(x.y.0)(其中:y= [I...15])，那麼KNXnet/IP路由器不應分配KNX幹線耦合器地址(X.0.0)。
[0061]KNXnet/IP路由器不建立互相之間的通信通道。KNXnet/IP路由器總是傳輸數據至IJ同一網絡中具有同樣IP多播(組)地址的所有其他KNXnet/IP路由器，或者根據路由報文的TTL通過IP路由器到達其他網絡。
[0062]路由器可以使用優先級FIFO和一般FIFO模式兩個轉發規則。報文過濾分組地址過濾、LTE組地址過濾和單獨地址過濾。
[0063]對於來自KNX網絡的報文，執行上面所述的組地址過濾、LTE組地址過濾和單播地址過濾進行路由，同時需要判斷路由跳數(routing counter)。
[0064]而對於來自IP網絡的報文，路由器接收所有路由多播地址相符合的報文，然後再執行下面的過濾:埠號(3671)、多播IP位址、過濾表(組地址過濾、LTE組地址過濾和單播地址過濾)或掩碼類型(MASK)。
[0065]在KNX系統中有兩種尋址方式:物理地址尋址(Physical Addressing)和組地址尋址(Group Addressing)。物理地址尋址主要用於KNX設備的程序下載以及系統監控等功能。組地址尋址在KNX通信機制中扮演著關鍵的角色，KNX設備間的相互通信主要是通過組地址尋址實現的。通過組地址就可以實現一控多、多控一、場景控制等功能。
[0066]物理地址尋址:在KNX系統中，每一個總線設備都有其物理地址，並且物理地址是獨一無二的。它和設備在KNX系統中網絡拓撲結構相對應，根據物理地址我們可以確定它在KNX系統中的位置。如圖14所示，物理地址由2Bytes構成，用十進位表示為XX.XX.XXX，其最大值為15.15.255。物理地址包含域序號、線序號、設備序號三部分。通過總線元件的編程按鈕就可以將物理地址寫入該元件。物理地址在編程設定後，就作為KNX應用程式下載到設備的通信尋址。比如位於域1、線I上的第7個設備，其物理地址為00010001，
00000111B,即 1107H。
[0067]組地址尋址:KNX系統中的元件之間的通信是通過組地址實現的。組地址包含2bytes，其最高有效位永遠為O。如圖15所示，組地址有兩種格式，2層組地址(主組[4位]/子組[11位])和3層組地址(主組4位/中間組[3位]/子組[8位])。層的設定在KNX編程軟體中設定。不同分層關係只是在功能概念上的劃分，其比特數據本身並沒有區別。如2層式組地址的I / 258與3層式的組地址I / I / 2完全一樣，其二進位表示均為00001001,00000010。組地址表示的是設備在功能上的劃分，比如第一層用於區分照明、溫度或窗簾等大的功能，第二層用於區分開關和調光，則第三層可以用於區別不同的燈。
[0068]實施例二
如圖20所示，EnOcean與KNX的IP網關在工程上的典型應用可以為=SfEnOcean與KNX的IP網關的乙太網埠與交換機相連接，交換機與監控中心計算機相連接，多個EnOcean與KNX的IP網關之間通過交換機的連接實現它們相互之間的數據交換；En0cean與KNX的IP網關的KNX總線埠與KNX總線相連接，KNX總線上可以掛KNX線路耦合器、KNX其他終端設備節點和KNX/EnOcean網關等設備，KNX線路耦合器支線側的KNX支線可以掛KNX其他終端設備節點和KNX/EnOcean網關等設備，KNX/EnOcean網關與其周圍區域上的EnOcean無線中繼器和EnOcean其他無線終端設備進行無線通訊；En0cean與KNX的IP網關的EnOcean埠與其周圍區域上的EnOcean無線中繼器和EnOcean其他無線終端設備進行無線通訊。
[0069]除上述實施例外，本發明還可以有其他實施方式。凡採用等同替換或等效變換形成的技術方案，均落在本發明要求的保護範圍。
【權利要求】
1.一種EnOcean與KNX的IP網關，包括電源模塊，其特徵在於還包括: EnOcean無線收發模塊,用於連接EnOcean側網絡； KNX總線模塊，用於連接KNX側網絡； Ethernet網絡模塊，用於連接IP側網絡； 處理器模塊，連接EnOcean無線收發模塊、KNX總線模塊和Ethernet網絡模塊，用於控制、協調網關的工作運行，實現EnOcean側網絡、KNX側網絡及IP側網絡之間的數據轉換，使EnOcean單向設備發出的報文被識別為KNX組播報文，EnOcean雙向設備被識別為網關的KNX虛擬通訊對象。
2.如權利要求1所述的一種EnOcean與KNX的IP網關,其特徵在於EnOcean無線收發模塊包括EnOcean無線收發器,無線收發器提供連接EnOcean側網絡的EnOcean埠，並與處理器模塊的串口相連接。
3.如權利要求1所述的一種EnOcean與KNX的IP網關，其特徵在於KNX總線模塊包括KNX總線埠、KNX串口收發器和高速光耦模塊，KNX總線埠與KNX串口收發器相連接，KNX串口收發器與高速光耦模塊相連接，高速光耦模塊與處理器模塊的串口相連接。
4.如權利要求1所述的一種EnOcean與KNX的IP網關,其特徵在於Ethernet網絡模塊包括RJ45乙太網接口、乙太網控制器和網絡變壓器模塊，RJ45乙太網接口與網絡變壓器模塊相連接，網絡變壓器模塊分別與乙太網控制器的乙太網接口和乙太網信號發送指示燈模塊相連接。
5.如權利要求1或4所述的一種EnOcean與KNX的IP網關,其特徵在於Ethernet網絡模塊採用處理器模塊自帶的包含PHY和MAC的乙太網控制器。
6.如權利要求1所述的一種EnOcean與KNX的IP網關,其特徵在於電源模塊利用Ethernet網絡模塊的POE功能通過乙太網為網關提供工作電源。
7.基於權利要求1所述EnOcean與KNX的IP網關的通訊網絡，其特徵在於KNX總線模塊的KNX總線埠與KNX總線相連接；En0cean無線收發模塊的EnOcean埠與其周圍區域的EnOcean無線中繼器和EnOcean其他無線終端設備進行無線通訊；多個網關通過Ethernet網絡模塊的乙太網埠與交換機相連接，交換機與監控中心計算機相連接，所述多個網關之間通過交換機的連接實現相互之間的數據交換。
8.一種EnOcean與KNX的IP網關的協議轉換方法，網關包括提供網關工作電源的電源模塊、用於連接EnOcean側網絡的EnOcean無線收發模塊，用於連接KNX側網絡的KNX總線模塊，用於連接IP側網絡的Ethernet網絡模塊及連接EnOcean無線收發模塊、KNX總線模塊和Ethernet網絡模塊的用於控制、協調網關的工作運行，實現EnOcean側網絡、KNX側網絡及IP側網絡之間的數據轉換的處理器模塊，IP側網絡和KNX側網絡分別採用標準KnxNet/IP協議和標準KNX協議，其特徵在於處理器模塊對EnOcean單向設備和EnOcean雙向設備分別做不同處理:從IP側網絡或KNX側網絡看不到EnOcean單向設備，EnOcean單向設備發出的報文被識別為KNX組播報文；En0cean雙向設備被識別為網關的KNX虛擬通訊對象。
9.如權利要求8所述的協議轉換方法，其特徵在於EnOcean側網絡與KNX側網絡之間採用虛擬通訊對象對應表進行映射。
10.如權利要求8所述的協議轉換方法，其特徵在於EnOcean無線收發模塊採用EnOcean無線通訊協議與EnOcean側網絡的EnOcean無線模塊進行數據交換,採用EnOcean串口通訊協議與處理器模塊進行數據交換，處理器模塊獲取所述EnOcean無線模塊所屬設備的設備類型，然後將這些被識別的EnOcean設備映射成網關的KNX虛擬通訊對象，並在處理器模塊中建立EnOcean與KNX虛擬通`訊對象對應表。
【文檔編號】H04L12/66GK103763187SQ201410052553
【公開日】2014年4月30日 申請日期:2014年2月17日 優先權日:2014年2月17日
【發明者】馬如明, 黃水生, 楊毅, 王偉江, 吳明光 申請人:南京天溯自動化控制系統有限公司