TW202535689A

TW202535689A - 電動汽車充電站運營架構

Info

Publication number: TW202535689A
Application number: TW114109364A
Authority: TW
Inventors: 李皞白; 王佑仁
Original assignee: 李皞白
Priority date: 2024-03-13
Filing date: 2025-03-13
Publication date: 2025-09-16
Also published as: WO2025190338A1

Abstract

本發明提供一種電動車充電站運營架構，是將超級帳本之區塊鏈技術結合物聯網通信架構後，所建立的一個可以提供電動車在多個充電站之間進行充電預約及充電服務的運營架構與平台。同時，通過本發明的運營架構，能夠提供綠色標章認證資料，包括：發電機輸出的功率、儲能電池組的輸出的功率、每一個充電樁的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等電功率鏈資訊，用以作為綠色標章認證的證據。

Description

電動汽車充電站運營架構

本發明是有關於一種提供電動車會員充電預約及充電服務的運營平台，特別是有關於一種將區塊鏈之超級帳本技術結合物聯網通信架構後，所建立的一個可以提供電動車會員在多個供電站之間進行充電預約及充電服務的運營平台與系統。在本發明的較佳實施例中，進一步提供可以符合綠色標章認證的證據檔案。

隨著人類生活水準的增高，需要高度使用石化能源來供應汽車和機械設備的使用，因而排放出大量的廢氣，不僅造成石油資源的日益枯竭，生態環境的惡化也越來越嚴重。因此，被譽為新能源汽車之一的電動汽車的推廣和應用提上了日程，新能源電動汽車不僅節能、環保、無噪音，而且速度更快。因此，歐洲聯盟(EU)已在2023年2月14日立法，最晚自2035年起禁止販賣汽柴油新車。很明顯的，電動汽車的時代已經來臨。根據此一趨勢，除了電動汽車外，其他的兩輪或是三輪的動力代步工具，也必將被電動化所取代。因此，未來的電動車可以更廣泛的涵蓋至兩輪或是三輪或是四輪的動力代步工具。

由於電動車都需要通過電池來供應動力來源，使得充電設施(例如：一種充電站)成為一個必要的基礎建設，也由於充電設施從供電設備到充電樁充電，或是換電設施從供電設備到換電站等，都需要通過精准的管理，特別是可以通過預約管理，來降低電動車會員充電或是換電的時間。因此，提供電動車進行充電或是換電的充電站管理及運營將是一種新的服務架構。

使用新能源的目的，就是期望能夠使用乾淨無污染的能源，以符合ESG或是綠色標章的環境保護(Environment)、社會責任(Social)和公司治理(Governance)等概念，作為企業永續經營的績效指標。然而，如何提供有效的提供第三方認證單位來認證ESG或是綠色標章的方式，還沒有統一的國際標準，使得碳權交易無法取得大部分國家的信任，因此需要有一些能夠符合新能源範疇的ESG或是綠色標章證據規範，讓企業可以根據這些規範馾舉證，同時也能夠讓第三方認證單位有認證綠色標章的規範與標準，才能達到2050年淨零碳排的目標。

根據上述說明，本發明之一主要目的，是提供一種電動車快充服務的運營平台架構，特別是能提供300千瓦以上的充電服務。其最關鍵的概念是必須使用獨立的發電模組來供應儲能電池模組作為每一個充電介面的電力供應模組，如此才能達到提供快充服務並且不會影響周邊市電或是電網的運作。進一步而言，通過本發明的充電站架構，可以提供直流對直流(即是由儲能電池模組輸出直流電供應給充電樁，充電樁再將直流電輸出至電動車)的充電方式，很明顯的，這種直流對直流(DC-DC)的充電方式可以選擇不需要使用逆變器，故可以降低充電樁的成本。

本發明之另一主要目的，是提供一種使用物聯網通信架構來建立每一個充電站中的充電設備或是換電設備的管理平台，並且可以通過後台或是雲端裝置來重新建立或是設定不同充電站之間的物聯網通信鏈路。

本發明之另一主要目的，先通過互聯網的通信協議(例如：http)，將多個充電站及充電站中的每一個充電樁模組進行雜湊碼(Hash code)編碼，成為超級帳本的驗證節點。並使其成為驗證會員身份的去中心化身份驗證(DID)驗證裝置後，用來驗證每個會員進入充電站時的身份資訊。接著，是將充電站中的全程電功率鏈資訊通過物聯網(IoT)的通信協議(例如：MQTT)進行通信，特別是將充電過程所用到的電功率資訊以及交易資料，逐一寫入每站的超級帳本中，並分散至各站中的所有節點來保存，由於超級帳本的驗證就是使用區塊鏈進行雜湊碼編碼，可以確保資料的不可更改性以及正確性。再將這些資料傳送至後台裝置以及綠色標章的第三方認證單位，使得本發明中的全程電功率鏈資訊資訊安全性提高，不易被黑客竄改，大幅度的提高綠色標章的認證的證據力。其中，全程電功率鏈資訊，包括：充電站中的發電機輸出的功率、儲能電池組的輸出的功率、每一個充電樁的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等，用以作為綠色標章認證的證據。

根據上述之目的，本發明提供一種電動車充電站運營架構，所述充電站是由發電模組、儲能電池模組、能源管理模組及多個充電樁所組成，其中，所述發電模組與儲能電池模組及能源管理模組連接，而能源管理模組與儲能電池模組及多個充電樁連接，是由所述發電模組輸出電功率，並將輸出電功率對儲能電池模組進行充電，同時將所述電功率資訊傳送至能源管理模組，所述能源管理模組控制儲能電池模組輸出電功率至充電樁中，其特徵在於：

所述發電模組、儲能電池模組、能源管理模組及多個充電樁均配置物聯網控制器，使得所述發電模組、儲能電池模組、能源管理模組及多個充電樁輸出的電功率資料通過物聯網控制器傳送至後台裝置；

所述後台裝置已將所述發電模組、儲能電池模組、能源管理模組及多個充電樁通過MQTT通信協議完成配對，並選擇其中一個做為代理伺服裝置；

所述後台裝置已將所述發電模組、儲能電池模組、能源管理模組及多個充電樁設定為超級帳本的識別節點，用以作為去中心化身份驗證(DID)的節點；

所述代理伺服裝置通過MQTT通信協定將電功率資料通過區塊鏈編碼技術編碼後，不做任何處理且直接將接收到的所述編碼紀錄以副本方式分享至多個去中心化身份驗證(DID)的節點中；其中，

所述電功率資料包括：發電模組的輸出電功率、儲能電池模組的輸出電功率、能源管理模組的輸出電功率及每一個充電樁電功率用量的帳單(即智慧合約)等資訊。

100:戶端裝置

110:電動車

120:智慧手機

200的:充電站

210:發電模組

220:儲能電池組

230:逆變器控制模組

240:充電樁模組

2410:充電樁介面

2430:充電模組/充電槍

2450:充電模組控制器

250:換電櫃

260:EMS模組

270:物聯網控制器

500:後台裝置

520:資料處理模組

530:記憶體模組

700:代理伺服裝置

280:私有微電網

290:公有電網

圖1 是本發明的物聯網連接架構示意圖；

圖2 是本發明的物聯網連接架構另一實施例的示意圖；

圖3 是本發明的物聯網連接方法的流程圖；

圖4 是本發明的物聯網連接方法另一實施例的流程圖；

圖5 是本發明的一種電動車充電站架構示意圖；

圖6a，圖6b及圖6c 是揭示本發明充電站的信號傳遞路徑的示意圖；

圖7 是本發明的後台裝置與充電站中的模組通信路徑的示意圖；

圖8 是本發明的後台裝置與充電站中的模組建立通信架構的示意圖；

圖9 是本發明的後台裝置與與多個充電站建立通信架構的示意圖；

圖10a及圖10b 是本發明使用程式來對QR-Code序列化的示意圖；

圖11a及圖11b 是本發明建立的數位憑證及數位簽章資料結構示意圖；

圖12 是本發明的會員註冊及使用充電站進行充電的運營流程圖；

圖13 是本發明的註冊會員在充電站進行充電的流程圖。

在本發明之後的說明書中，為使發明之目的、技術特徵及優點，能更為相關技術領域人員所瞭解並得以實施本發明，在此配合所附圖式，於後續之說明書闡明本發明之技術特徵與實施方式，並列舉較佳實施例進一步說明。然以下實施例說明並非用以限定本發明，且以下文中所對照之圖式，系表達與本發明特徵有關之示意。其中，雲端與後台或是運營平台是屬於同一裝置及功能，之後將以後台裝置為代表。此外，在本發明中的電動車可以更廣泛的涵蓋至兩輪或是三輪或是四輪的動力代步工具。同時，對電動車的充電與換電都可以在本發明的充電站中進行充電樁的充電，也可以在充電站中的換電裝置或是換電櫃進行換電，這是因為在本發明的充電站中，無論在進行充電或是換電的過程，會員都需要通過充電樁或是換電櫃上的顯示幕幕進行身分認證程式，因此，在後續的說明書中，對於一些實施例而言，充電就包括換電。另外，在通信協定的說明上，通常在使用TCP/IP通信協定時，是都需要經過加密及編碼程式之後，才會發送出去，故在本發明的說明書中，會在部分實施例中說明，至於，若只說明使用TCP/IP通信協議時，即表示是包括加密與編碼的程式。以上合先說明。再者，本發明在實際的應用中，會使用去中心化的身份驗證(Decentralized Identity,DID)技術，並會在Hyperledger Indy網路上發佈的身份驗證(DID)添加命名空間元素，以便使用者知道去中心化身份驗證(DID)是在眾多Hyperledger Indy網路中的哪個網路上建立的。其中，在後續的說明中，是以身份驗證(DID)來表示去中心化身份驗證(Decentralized Identity,DID)。此外，就名詞使用上，在本發明中所述的後台裝置與後台裝置是相同的，都是做為本發明最上層的資料中心(data center)或是伺服中心(sever)，其構造上至少都包括了資料處理模組及記憶體模組。另外，在本發明後續的說明中，是以綠色標章(green label)來代表是與ESG、淨零排放、碳權或是綠色環保相關的認證。

首先，請參考圖1，是本發明的物聯網連接架構示意圖。如圖1所示，物聯網連接架構是由用戶端裝置(client device)100、後台裝置(platform)500及至少一個代理伺服裝置(broker device)700所組成；其中，用戶端裝置100為一種具有無線通訊功能且具有特定使用者識別項的裝置；後台裝置500，具有與用戶端裝置100通信之功能，藉由用戶端裝置100的特定使用者識別項確認用戶端裝置100為物聯網中的其中之一個用戶端裝置100；以及代理伺服裝置700，具有其網址及密碼，並能與後台裝置500通信。

在本發明的物聯網連接架構中，用戶端裝置100是一種隨時變動的浮動IP (Internet Protocol)的無線通訊功能的裝置(例如：個人電腦、筆記本電腦、智慧型手機、智慧型可攜式裝置、智慧型讀取裝置，邊緣運算裝置等)，並且每一個用戶端裝置100都具有獨特性的識別字(例如：製造廠商于出廠時所設定的編碼；又例如：MAC Address等硬體資料)，以便用來產生用戶端裝置100的通用唯一識別碼(Universally Unique Identifier；縮寫為uuid)，用以辨識或防止駭客侵入。此外，在本發明的物聯網連接架構中，後台裝置500是一種物聯網通道配發系統(Tunnel Dispatcher of Internet of Thing；縮寫為TDIoT)，其具有伺服器(sever)之功能並且具有與用戶端裝置100通信之功能，同時後台裝置500至少是由接收/發射介面模組(未顯示於圖中)、資料處理模組520及記憶體模組530等裝置所組成；因此，後台裝置500已經記錄著所有屬於本發明物聯網中的所有用戶端的uuid並已儲存在記憶體模組530中，形成一個資料庫。

再者，代理伺服裝置700是由微控制器(Micro Control Unit,MCU)及一個微處理器(Micro Processor Unit,MPU)所組成，其中，微處理器中包括了無線通訊模組。在本發明的實施例中，代理伺服裝置700是一種隨時變動的浮動IP，其最主要的工作是將確認是為物聯網中的用戶端裝置100所傳送的編碼資料串在接收後，直接傳送出至後台裝置500；特別要說明的是，代理伺服裝置700根據所使用的MQTT(Message Queuing Telemetry Transport)的通信協定(protocol)，是在收到用戶端裝置100所傳送的資料串後，不做任何處理，而是直接將接收到的資料串直接傳送出去，在後台裝置500收到代理伺服裝置700的資料串後，再經過資料處理模組520解碼後，才會對用戶端裝置100所傳送的資料串進行處理。很明顯的，在本發明的物聯網連接架構中，在整個用戶端裝置100將資料串遞給後台裝置500的過程中，後台裝置500並不會直接暴露出自己的位址，故可以降低後台裝置500被駭客攻擊的機率，可以大幅度的提高物聯網的安全性。此外，代理伺服裝置700可以配置在有網路條件下的任何位置，本發明並不加以限制。

而在本發明的物聯網連接架構的較佳實施例中，可以將多個用戶端裝置100分為多個群組，每一群組分別對應或配對至一個代理伺服裝置700，故在本發明的物聯網連接架構中，可以有多個代理伺服裝置700，如圖2所示。當後台裝置500判斷其中一個代理伺服裝置700遭受駭客攻擊後，後台裝置500可以選擇將被攻擊的代理伺服裝置700關閉，或由後台裝置500以軟體定義網路(software-defined networking,SDN)的方式再重新建立一個新的代理伺服裝置700的加密通道及密碼，可以更確保本發明物聯網的安全性。此外，在本發明的實施例中，代理伺服裝置700是選擇使用MQTT通信協定來做資料串的傳送。由於MQTT是為了物聯網而設計的通信協議，特別是基於發佈(publish)/訂閱(subscribe)模式的羽量級消息傳輸協定，其為IBM的Andy Stanford-Clark博士及Arcom公司的Arlen Nipper博士于1999年創作；最初是為大量計算能力有限且工作在低頻寬、不可靠的網路的遠端感測器和控制設備之間的通訊而設計的通信協定。因此，MQTT具有傳輸資料小且輕巧的優點，可以在頻寬及速度上都有極大優勢；也由於其所需要的網路頻寬是很低的，因而使得其所需要的硬體資源也是低的，故可以將物聯網系統或是使用此物聯網架構的各種商業運營系統(例如物流管理、產品的生產履歷、產品防贗、區塊鏈或是超級帳本等)之效率性提升；也因此可以有效地降低商業運營的成本。

接著，詳細說明本發明的物聯網實際完成連接的過程及其方法。

請繼續參考圖1，首先，由用戶端裝置100向後台裝置500進行登錄(如第1圖中的S1標示的通信方向)，例如：一個會員通過所持有的智慧型手機作為用戶端裝置100，並以用戶端裝置100通過TCP/IP向後台裝置500登錄，以便啟動物聯網系統，其中，本發明所述的TCP/IP是包括：http/https、http/2、Websocket...以及其他相關應用層通訊協定。接著，當後台裝置500中的資料處理模組520收到用戶端裝置100的請求後(如圖1中的S2標示的通信方向)，後台裝置500會先驗證用戶端裝置100所使用的MAC Address是否已經儲存在後台裝置500的記憶體模組530中；若確認用戶端裝置100所使用的MAC Address已經儲存在後台裝置500的記憶體模組530時，則產生一個客戶辯證碼(client uuid)。接著，後台裝置500產生一對專屬客戶使用的金鑰；在本發明的較佳實施例中，此金鑰是使用RSA非對稱式金鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；其中，RSA非對稱式金鑰具有解碼時間長，所以安全性高。此外，在另一較佳實施例中，後台裝置500還可以選擇性的產生一個用戶端裝置100專屬的對稱式金鑰(Symmetric Key)client_share_key。故在本發明的較佳實施例中，可以選擇性的將RSA非對稱式金鑰及對稱式金鑰配合使用；由於，對稱式金鑰具有解碼時間短，相對地安全性較低，因此需要隨時變動client_share_key，以確保安全性；為此，後台裝置500還會進一步產生/設定一個變動的時間(share_key_expiry date time)，藉由不定時的更改share_key_expiry date time來提升安全性；故當後台裝置500偵測到隨時變動的client_share_key已經超過了share_key_expiry date time設定變動的時間後，即會自動產生新的client_share_key，以確保安全性。當後台裝置500在確認一個用戶端裝置100 的MAC Address資料與儲存在記憶體模組530中相同時，則判斷此用戶端裝置100為本物聯網中的用戶端，之後，後台裝置500會將所產生的uuid及金鑰等訊息回傳至用戶端裝置100(如圖1中的S3標示的標通信方向)，這些回傳至用戶端裝置100的訊息包括：client_uuid、sever_pub_key(此sever_pub_key即是client_pub_key；因為所有用戶端裝置100都會使用同一個pub_key，所以又可稱為sever_pub_key)及client_pri_key。

另外，若當後台裝置500收到用戶端裝置100的請求後，後台裝置500比對出用戶端裝置100所使用的MAC Address並不在後台裝置500的記憶體模組530中時，及判斷此用戶端裝置100所使用的MAC Address並非本物聯網中的用戶端裝置，則將此MAC Address訊息儲存在另一資料庫中，以便後續比對。特別要說明，S3通信方向的回傳機制，一般而言，是不會有錯誤的，但是還是有發生錯誤的機制；例如，等待Server反映時間過久導致此次連線失敗，此時，則是會再由用戶端裝置100重新執行一次，但是此時的後台裝置500會判定此次的MAC address已經在記憶體模組530中被記錄，因而還是會將此MAC address對應的uuid回傳，此時，後台裝置500所產生並回傳給用戶端裝置100的一對金鑰會更新。因此，即便有假的裝置使用任何方法仿冒此用戶端裝置100的MAC address也無法取得相同金鑰。換句話說，只會有一個確定的uuid能存活在系統中。

接著，如圖1中的S4標示的通信方向，當用戶端裝置100以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)通過TCP/IP“要求”取得client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker帳號及密碼(username/passward)；而當後台裝置500收到轉成加密後的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確；待後台裝置500確認client_uuid正確後，後台裝置500將client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker帳號及密碼等以client_pub_key編碼後回傳至用戶端裝置100(如圖1中的S5標示的通信方向)。

此外，在本發明的一個較佳實施例中，MQTT_Broker的IP、帳號及密碼可以選擇分兩次取得；例如，第一次(如圖1中的S4標示的通信方向)，用戶端裝置100以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)通過TCP/IP“要求”取得client_share_key、share_key_expiry date time及MQTT_Broker IP；而當後台裝置500收到轉成加密後的client_uuid後，即會根據sever__pri_key進行解碼，以確認client_uuid是否正確；待後台裝置500確認client_uuid正確後，後台裝置500將client_share_key、share_key_expiry date time及MQTT_Broler IP等以client_pub_key編碼後回傳至用戶端裝置100(如圖1中的S5標示的通信方向)。第二次(如圖1中的S6標示的通信方向)，用戶端裝置100再以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)，通過TCP/IP“要求”取得MQTT_Broker帳號及密碼；而當後台裝置500收到轉成加密後的的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確；待後台裝置500確認client_uuid正確後，後台裝置500將MQTT_Broker帳號及密碼等以client_pub_key編碼後回傳至用戶端裝置100(如圖1中的S7標示的通信方向)。特別要說明的，第一次及第二次所要取得的內容中，只要求將MQTT_Broker的IP、帳號及密碼分兩次取得，其他並不加以限制。

很明顯地，在用戶端裝置100與後台裝置500進行辨識與確認的過程中，所使用的TCP/IP是屬於混合型密碼防駭、安全通訊協定(Secure Sockets Layer；SSL)或傳輸層安全協議(Transport Layer Security；TLS)，其本身屬於公認的安全協定，且後台裝置500端所需要有的公認憑證，可以由用戶端裝置100端藉由認證中心的數位簽章來確認訊息是否由後台裝置500直接傳出；因此，當有駭客在訊息傳遞過程進行竄改、盜用或否認等行為時，都可藉由這些安全認證來防止密碼遭竄改或盜用。

接著，如圖1中的S8標示的通信方向，當用戶端裝置100自後台裝置500取得相關資料後，用戶端裝置100隨即會與代理伺服裝置700進行連接；但在進行連接代理伺服裝置700前，必須確認所收到的訊息必須完整，此完整的訊息包括：1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/passward；5.client_Share_key；6.Share_key_expiry date time。當用戶端裝置100在確認收到完整的訊息後，會使用client_share_key將client_uuid及用戶端裝置100所要傳給後台的資料內容(data involved)進行編碼後，再上傳至代理伺服裝置700(即MQTT Broker)。

在本發明的較佳實施例中，用戶端裝置100會進一步檢查Share_key_expiry date time的時效是否已經到期(例如：到期日為2015/0501)；如果已經過了Share_key_expiry date time的時效時(例如：檢查期日的結果為2015/0502)，則用戶端裝置100會重新以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)，通過TCP/IP要求取得新的share_key﹁_expiry date time訊息。而當後台裝置500收到轉成加密後的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確；待後台裝置500確認 client_uuid正確後，後台裝置500將新的share_key_expiry date time以client_pub_key編碼後回傳至用戶端裝置100。此外，為增加安全性，share_key-_expiry date time所設定的時間可以是週期性的，也可以是隨機變數的，可以由後台裝置500決定。

當用戶端裝置100在確認已收到完整的訊息後，此時用戶端裝置100已經知道代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼，故用戶端裝置100可以將編碼的client_uuid及資料串上傳至代理伺服裝置700(如圖1中的S8標示的通信方向)。接著，代理伺服裝置700在收到用戶端裝置100所上傳的編碼client_uuid及資料串後，隨即將用戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給後台裝置500端。很明顯地，整個物聯網在用戶端裝置100將其訊息串遞給後台裝置500的過程中，後台裝置500並不會直接暴露出自己的位址，故可以降低後台裝置500被駭客攻擊的機率。由於代理伺服裝置700只是將用戶端裝置100上傳的資料直接傳送給後台裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。

接著，如圖1中的S9標示的通信方向，後台裝置500在接收到代理伺服裝置700所直接傳送的資料(即經過編碼後的client_uuid及資料串)後，隨即使用client_share_key進行解碼(decoding)，並且會驗證所收到的client_uuid及資料串是否完整及正確；如果正確時，則再儲存至記憶體模組530中，等待使用者將這些收到的資料串進行特定的應用。若驗證所收到的client_uuid及資料串不完整或不正確時，則進行紀錄。要說明的是，要驗證出不正確的訊息的目的，是可以由物聯網系統借著人工智慧作深度學習或人為增加、更改或修正的驗證機制，來防止或降低被駭成功的機率。在本實施例中，不正確的訊息包括，例如：(1)由網路爬蟲抓取新聞發現當下某些商品的偽品猖獗；又亦或是(2)程式一開始便設定的同一client_uuid，竟然在同一時間出現在兩個完全不同的地方，此時物聯網系統會通知公司稽查人員或提出警告，而稽查人員可做出的處置方式至少有觀察或忽略等動作，達到事先預警及防駭的功效；又亦或是(3)後台裝置500本身持續受到某特定代理伺服裝置700傳送可疑資訊時，例如：不明的client_uuid資訊時。當有任何不正確的訊息持續出現時，則後台裝置500在判斷代理伺服裝置700可能被駭客攻擊後，則後台裝置500一方面可以選擇關閉此代理伺服裝置700(如圖1中的S10標示的通信方向)，同時，後台裝置500可會立即通過圖1中的S7標示的通信方向，通知被關閉的代理伺服裝置700上的所有用戶端裝置100，以新的MQTT_Broker IP及MQTT_Broker username/passward向新指定的代理伺服裝置700連接。特別要說明的是，後台裝置500指定新的代理伺服裝置700的過程是以軟體定義網路(SDN)方式進行，也就是當用戶端裝置100收到後台裝置500所送來的內容後，就會自動的更新至新的MQTT_Broker IP及MQTT_Broker username/passward，故當使用者以用戶端裝置100再發出執行需求時，用戶端裝置100就會直接通過新的代理伺服裝置700與後台裝置500連接。很明顯的，這段更新代理伺服裝置700連接的過程，使用者是不需要被通知的。

在本發明的實施例中，client_share_key編碼方式可以配合雜湊函數來防止竄改，其中雜湊函數可以選擇MD5、SHA-1或SHA-256等。同時， client_share_key也可以配合不同的解碼(decoding)方式，例如：區塊鏈密碼、串流密碼、ECB模式或是前述的混合方法等，除了可以更有效的提高破解難度外，還可以不損失解碼時間。

請參考圖2，是本發明的物聯網連接架構另一實施例的示意圖。如圖2所示，物聯網連接架構是由複數個用戶端裝置100所組成、一個後台裝置500及至少一個代理伺服裝置700所組成；其中，每一個用戶端裝置100均為具有無線通訊功能且具有特定使用者識別項的裝置。後台裝置500，具有與每一個用戶端100通信之功能，藉由每一個用戶端100各自獨有的特定使用者識別項來確認用戶端裝置100為物聯網中的其中之一個用戶端裝置100；代理伺服裝置700，具備前述MCU及MPU的結構，具有其網址及密碼，並能與後台裝置500通信。由於圖2的實施例與圖1的實施例在基本連接的架構是相同的，而兩者之間的差異僅在於後台裝置500提供每一個代理伺服裝置的網址、帳號及密碼予至少一個物聯網中的用戶端裝置100並形成配對後，這些被配對後的用戶端裝置100只能與配對的代理伺服裝置700通信，並再由代理伺服裝置700與後台裝置500通信，以便將每一個用戶端裝置100上的資料串傳至後台裝置500中。故圖2的物聯網實際完成連接的實施過程簡要說明如下。

請繼續參考圖2，首先，每一個用戶端裝置100各自過TCP/IP向後台裝置500進行登錄。接著，當後台裝置500分別收到每一個用戶端裝置100的請求後，後台裝置500會先驗證每一個用戶端裝置100所使用的MACAddress是否已經儲存在後台裝置500的記憶體模組530中；若確認每一個用戶端裝置100所使用的MAC Address都已經儲存在後台裝置500的記憶體模組530時，則分別產生每一個客戶各自的辯證碼(client uuid)；接著，後台裝置500根據每一個用戶端裝置100產生一對專屬客戶使用的金鑰；當後台裝置500判斷每一個用戶端裝置100均為本物聯網中的用戶端之後，後台裝置500會將所產生的每一個uuid及金鑰等訊息回傳至相應的每一個用戶端裝置100中，這些回傳至每一個用戶端裝置100的訊息包括：client_uuid、sever_pub_key及client_pri_key。

接著，每一個用戶端裝置100可以將其編碼後的client_uuid通過TCP/IP“要求”取得client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker帳號及密碼(username/passward)；而當後台裝置500收到轉成加密後的client_uuid後，即會根據各自的sever_pri_key進行解碼，以確認每一個收到的client_uuid是否正確；待後台裝置500確認client_uuid正確後，後台裝置500將client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker帳號及密碼等以client_pub_key編碼後回傳至用戶端裝置100。例如：將代理伺服裝置700-1(Broker-1)的IP、帳號及密碼回傳給Client-1~Client-5；將代理伺服裝置700-2(Broker-2)的IP、帳號及密碼回傳給Client-6~Client-15；將代理伺服裝置700-3(Broker-3)的IP、帳號及密碼回傳給Client-16~Client-50。很明顯的，本物聯網已經將50個各別的用戶端裝置100分別配對由3個代理伺服裝置700來與後台裝置500通信。接著，當每一個用戶端裝置100各自透過後台裝置500取得相關資料後，用戶端裝置100隨即會與其所獲得的配對的代理伺服裝置700進行連接。同時，當每一個用戶端裝置100確認其由後台裝置500所收到的訊息已包括：1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/passward；5.Client_Share_key；6.Share_key_expiry date time後，會使用client_share_key將client_uuid及此用戶端裝置100所要傳給後台的資料內容進行編碼後，再上傳至代理伺服裝置700(即MQTT Broker)。

由於，當每一個用戶端裝置100在確認已收到完整的訊息後，此時用戶端裝置100已經知道其所配對的代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼，故用戶端裝置100可以將編碼client_uuid及訊息串上傳至配對的代理伺服裝置700。接著，每一個代理伺服裝置700在收到配對的用戶端裝置100所上傳的編碼client_uuid及訊息串後，隨即將用戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給後台裝置500端。很明顯地，整個物聯網在用戶端裝置100將其訊息串遞給後台裝置500的過程中，後台裝置500並不會直接暴露出自己的位址，故可以降低後台裝置500被駭客攻擊的機率。由於每一個代理伺服裝置700只是將用戶端裝置100上傳的資料直接傳送給後台裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。接著，後台裝置500在接收到每一個代理伺服裝置700所直接傳送的資料(即經過編碼後的client_uuid及資料串)後，資料處理模組520隨即使用每一個client_share_key進行解碼，並且會驗證所收到的client_uuid及資料串是否完整及正確；如果正確時，則再儲存至記憶體模組中，等待使用者將這些收到的資料串進行特定的應用；若驗證所收到的client_uuid及資料串不完整或不正確時，則進行紀錄。在本實施例中，不正確訊息的產生可能包括：每一個client發佈資訊頻率有一定的規律性，如若產生某client以不正常或過多頻率來發佈的資訊，則視為不正確的訊息；或代理伺服裝置700本身頻率發佈資訊非經MQTT方式，而試圖連接後台裝置500等。當不正確的訊息持續出現時，則判斷代理伺服裝置700可能被駭客攻擊；則後台裝置500可以選擇關閉此代理伺服裝置700。

若當後台裝置500在判斷代理伺服裝置700-1可能被駭客攻擊後，則後台裝置500一方面可以選擇關閉此代理伺服裝置700-1(如圖1中的510標示的通信方向)，同時，後台裝置500可會立即通過圖1中的S7標示的通信方向，通知被關閉的代理伺服裝置700-1上的所有用戶端裝置100(即Client-1~Client-5)，以新的MQTT_Broker IP及MQTT_Broker username/passward向新指定的代理伺服裝置700連接，例如：後台裝置500將代理伺服裝置700-2的MQTT_Broker IP及MQTT_Broker username/passward傳遞給Client-1~Client-5，因此，在用戶端裝置100自動更新程式後，就會通過代理伺服裝置700-2與後台裝置500連接。特別要說明的是，向新指定的代理伺服裝置700-2連接過程是以軟體定義網路(SDN)的方式進行，也就是當用戶端裝置100(即Client-1~Client-5)收到後台裝置500所送來的內容後，就會自動的更新至新的MQTT_Broker IP及MQTT_Broker username/passward，故當使用者再發出執行需求時，用戶端裝置100就會直接通過新的代理伺服裝置700-2與後台裝置500連接，很明顯的，這段更新代理伺服裝置700連接的過程，使用者是不需要被通知的。

綜合上述，本發明之物聯網連接架構的主要結合兩個通信協定的技術手段，第一階段是使用TCP/IP的通信協定(即步驟S1-S7)，在後台裝置500確認每一個用戶端裝置100均為本物聯網的使用者後，後台裝置500會將代理伺服裝置700的MQTT_Broker IP、MQTT_Broker帳號及密碼回傳給每一個用戶端裝置100，之後，每一個用戶端裝置100根據所收到的MQTT_Broker IP、MQTT_Broker帳號及密碼與代理伺服裝置700連接，並且將每一個用戶端裝置100所要傳送的資料串編碼後，一起上傳至代理伺服裝置700。接著，是第二階段使用MQTT通信協定，當用戶端裝置100通過配對的代理伺服裝置700傳送執行內容時，此完成配對的代理伺服裝置700是會在『不對用戶端裝置100傳送的資料串進行處理的狀況下，直接將用戶端裝置100傳送的資料串傳遞至後台裝置500』進行解碼及處理。很明顯的，本發明的物聯網連接架構分為兩個階段進行連接，其中，在第一階段完成用戶端裝置100的辨識並取得配對的代理伺服裝置700的MQTT_Broker IP、MQTT_Broker帳號及密碼後，用戶端裝置100在第二階段中，就只能與完成配對的代理伺服裝置700連接。更進一步說，由於第一階段是在用戶端裝置100將資料串傳遞至後台裝置500之前就已完成，故當用戶端裝置100正式的傳遞資料串時，均只能與完成配對的代理伺服裝置700連接及通信；因此，後台裝置500並不會直接暴露出自己的位址，故可以降低後台裝置500被駭客攻擊的機率，可以有效的提高物聯網連接架構的安全性。

再接著，詳細說明本發明的物聯網連接架構的連接方法及過程，透過本物聯網連接架構的連接方法及過程，可以更清楚的瞭解本發明使用代理伺服裝置700之創新點。

請參考圖3，是本發明的物聯網連接方法的流程圖。如圖3所示，本發明的物聯網連接方法包括：

步驟1：由用戶端裝置100向後台裝置500進行登錄，例如：用戶端裝置100通過TCP/IP向後台裝置500登錄，以便啟動物聯網系統。

步驟2：當後台裝置500收到用戶端裝置100的請求後，後台裝置500中的資料處理模組520會先驗證用戶端裝置100所使用的MAC Address是否已經儲存在後台裝置500的記憶體模組530中。

步驟3：當後台裝置500確認用戶端裝置100所使用的MAC Address已經儲存在後台裝置500的記憶體模組530時，則判斷用戶端裝置100資料正確，其為本物聯網中的用戶端裝置100，則後台裝置500會產生一個客戶辯證碼(client uuid)、一對專屬客戶使用的金鑰。在本實施例中，此金鑰是使用安全性高的RSA非對稱式金鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；並且將其所產生的uuid及金鑰等訊息回傳用戶端裝置100，這些回傳用戶端裝置100的訊息包括：client_uuid、sever_pub_key(此sever_pub_key即是client_pub_key。此外，若當後台裝置500收到用戶端裝置100的請求後，後台裝置500比對出用戶端裝置100所使用的MAC Address並不在後台裝置500的記憶體模組530中時，即會判斷此用戶端裝置100所使用的MAC Address並非本物聯網中的用戶端裝置，則將此MAC Address訊息儲存在另一個資料庫中，以便後續比對。

步驟4：用戶端裝置100判斷後台裝置500所產生的uuid及金鑰等訊息是否以正確收到；當用戶端裝置100確認已經正確地收到uuid及金鑰等訊息後，用戶端裝置100隨即會以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)通過TCP/IP向後台裝置500要求取得client_share_key、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼(username/passward)。

步驟5：當後台裝置500收到轉成加密後的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確；待後台裝置500確認client_uuid正確後，後台裝置500將client_share_key、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼等以client_pub_key編碼後回傳至用戶端裝置100。

步驟6：當用戶端裝置100自後台裝置500取得相關資料後，用戶端裝置100隨即會使用client_pri_key進行解碼，並確認所收到的訊息必須完整，此完整的訊息包括：1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/passward；5.client_Share_key。當用戶端裝置100在確認收到完整的訊息後，即會與代理伺服裝置700進行連接。若用戶端裝置100判斷所收到的訊息不完整時，會回到步驟4，重新要求向後台裝置500要求取得client_share_key、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼(username/passward)。在完成此步驟時，用戶端裝置100與代理伺服裝置700之間已經完成配對。

步驟7：用戶端裝置100使用MQTT_Broker IP及MQTT_Broker帳號及密碼連接至完成配對的代理伺服裝置700；同時，也使用client_share_key將client_uuid及用戶端裝置100所要傳給後台裝置500的資料內容(data involved)進行編碼後，再上傳至代理伺服裝置700。

步驟8：代理伺服裝置700在收到完成配對的用戶端裝置100所上傳的編碼client_uuid及訊息串後，隨即將用戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給後台裝置500端。

步驟9：後台裝置500在接收到代理伺服裝置700所直接傳送的資料後，資料處理模組520會隨即使用client_share_key進行解碼，並且會驗證所收到的client_uuid及資料串是否完整及正確。

步驟10：後台裝置500中的資料處理模組520判斷所收到的client_uuid及資料串完整及正確時，則將解碼後的用戶端資料串儲存至記憶體模組520中，等待使用者將這些收到的資料串進行特定的應用。若驗證所收到的client_uuid及資料串不完整或不正確時，則進行紀錄。在本實施例中，不正確的訊息包括(1)某ip對應到的client_uuid不正確，則可能有盜用問題(2)若某client_uuid有配合上Geo Location的資料上傳，可以藉由驗證GeoLocation的合理性來驗證(是否某個client_uuid這一分鐘在亞洲，下一分鐘在北美)；當不正確的訊息持續出現時，則判斷代理伺服裝置700可能被駭客攻擊；則後台裝置500可以選擇關閉此代理伺服裝置700。

很明顯地，在整個物聯網架構的連接方法過程中，從步驟1至步驟6是可以選擇在每一個用戶端裝置100出廠前或是使用前就與後台裝置500完成連接，即每一個用戶端裝置100使用前，就已經自後台裝置500獲得完整的訊息包括：1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/passward；5.client_Share_key。當物聯網系統啟動後，每一個用戶端裝置100所要傳送給後台裝置500處理的資料串，都會根據MQTT_Broker IP傳送至完成配對的代理伺服裝置700，再由完成配對的代理伺服裝置700直接將用戶端裝置100資料串傳送給後台裝置500。故自步驟7至步驟10之間的訊息傳遞過程中，都是只使用MQTT的通信協定，因此，後台裝置500並不會直接暴露出自己的位址，故可以降低後台裝置500被駭客攻擊的機率。由於代理伺服裝置700只是將用戶端裝置100上傳的資料直接傳送給後台裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。

接著，請參考圖4，是本發明的物聯網連接方法另一實施例的流程圖。如圖4所示，本發明的物聯網連接方法包括：

步驟3：當後台裝置500的資料處理模組520確認用戶端裝置100所使用的MAC Address已經儲存在後台裝置500的記憶體模組530時，則資料處理模組520判斷用戶端裝置100資料正確，其為本物聯網中的用戶端裝置100，則後台裝置500會產生一個客戶辯證碼(client uuid)、一對專屬客戶使用的金鑰。在本實施例中，此金鑰是使用安全性高的RSA非對稱式金鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；並且將其所產生的uuid及金鑰等訊息回傳用戶端裝置100，這些回傳用戶端裝置100的訊息包括：client_uuid、sever_pub_key(此sever_pub_key即是client_pub_key。此外，若當後台裝置500收到用戶端裝置100的請求後，後台裝置500的資料處理模組520比對出用戶端裝置100所使用的MAC Address並不在後台裝置500的記憶體模組530中時，及判斷此用戶端裝置100所使用的MAC Address並非本物聯網中的用戶端裝置，則將此MAC Address訊息儲存在另一資料庫中，以便後續比對。

步驟4：用戶端裝置100判斷後台裝置500所產生的uuid及金鑰等訊息是否以正確收到；當用戶端裝置100確認已經正確地收到uuid及金鑰等訊息後，用戶端裝置100隨即會以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)通過TCP/IP向後台裝置500要求取得client_share_key、share_key_expiry date time、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼(username/passward)。

在本發明的較佳實施例中，此金鑰是使用RSA非對稱式金鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；其中，RSA非對稱式金鑰具有解碼時間長，所以安全性高。此外，在另一較佳實施例中，後台裝置500還可以選擇性的產生一個用戶端裝置100專屬的對稱式金鑰(Symmetric Key)client_share_key。故在本發明的較佳實施例中，可以選擇性的將RSA非對稱式金鑰及對稱式金鑰配合使用；由於，對稱式金鑰具有解碼時間短，相對地安全性較低，因此需要隨時變動client_share_key，以確保安全性。為此，後台裝置500還會進一步產生一個隨時變動的share_key_expiry date time，藉由不定時的更改client_share_key來提升安全性；故當後台裝置500偵測到隨時變動的client_share_key已經超過了設定變動的時間後，即會自動產生新的client_share_key，以確保安全性。

步驟5：當後台裝置500收到轉成加密後的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確；待後台裝置500確認client_uuid正確後，後台裝置500將client_share_key、share_key_expiry date time、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼等以 client_pub_key編碼後回傳至用戶端裝置100。

步驟6：當用戶端裝置100自後台裝置500取得相關資料後，用戶端裝置100隨即會使用client_pri_key進行解碼，並確認所收到的訊息必須完整，此完整的訊息包括：1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/passward；5.client_Share_key；6.share_key_expiry date time。當用戶端裝置100在確認收到完整的訊息後，即會與代理伺服裝置700進行連接；若用戶端裝置100判斷所收到的訊息不完整時，會回到步驟4，重新要求向後台裝置500要求取得。在完成此步驟時，用戶端裝置100與代理伺服裝置700之間已經完成配對。

步驟8：用戶端裝置100檢查Share_key_expiry date time的時效是否已經到期；若檢查結果尚未到期後，則編碼後的client_uuid及資料串內容上傳至代理伺服裝置700。若檢查結果為過期狀態後，則會回到步驟4，重新要求向後台裝置500要求取得新的Share_key_expiry date time。例如：到期日為2015/0501時；如果檢查結果已經過了Share_key_expiry date time的時效時(例如：檢查期日的結果為2015/0502)，則用戶端裝置100會重新以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)，通過TCP/IP要求取得新的share_key_expiry date time；而當後台裝置500收到轉成加密後的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確。待後台裝置500確認client_uuid正確後，後台裝置500將新的share_key_expiry date time以client_pub_key編碼後回傳至用戶端裝置100。此外，為增加安全性，share_key_expiry date time所設定的時間可以是週期性的，也可以是隨機變數的，可以由後台裝置500決定。

步驟9：代理伺服裝置700在收到完成配對的用戶端裝置100所上傳的編碼client_uuid及訊息串後，隨即將完成配對的用戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給後台裝置500端。

步驟10：後台裝置500在接收到代理伺服裝置700所直接傳送的資料後，資料處理模組520會隨即使用client_share_key進行解碼，並且會驗證所收到的client_uuid及資料串是否完整及正確。

步驟11：後台裝置500中的資料處理模組520在判斷所收到的client_uuid及資料串完整及正確時，則將解碼後的用戶端資料串儲存至記憶體模組530中，等待使用者將這些收到的資料串進行特定的應用。若驗證所收到的client_uuid及資料串不完整或不正確時，則進行紀錄。在本實施例中，不正確的訊息包括(1)某ip對應到的client_uuid不正確，則可能有盜用問題(2)若某client_uuid有配合上Geo Location的資料上傳，可以藉由驗證GeoLocation的合理性來驗證(是否某個client_uuid這一分鐘在亞洲，下一分鐘在北美)。當不正確的訊息持續出現時，資料處理模組520會判斷代理伺服裝置700可能被駭客攻擊；則後台裝置500可以選擇關閉此代理伺服裝置700。

很明顯地，在整個物聯網架構的連接方法過程中，從步驟1至步驟6是可以選擇在每一個用戶端裝置100出廠前或是使用前就與後台裝置 500完成連接，即每一個用戶端裝置100使用前，就已經自後台裝置500獲得完整的訊息包括：1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/passward；5.client_Share_key。當物聯網系統啟動後，每一個用戶端裝置100所要傳送給後台裝置500處理的資料串，都會根據MQTT_Broker IP傳送至完成配對的代理伺服裝置700，再由完成配對的代理伺服裝置700直接將用戶端裝置100資料串傳送給後台裝置500。故自步驟7至步驟10之間的訊息傳遞過程中，都是只使用MQTT的通信協定，因此，後台裝置500並不會直接暴露出自己的位址，故可以降低後台裝置500被駭客攻擊的機率。由於代理伺服裝置700只是將用戶端裝置100上傳的資料直接傳送給後台裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker帳號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。

接著，本發明還可以在圖3的步驟4中，將用戶端裝置100向後台裝置500取得代理伺服裝置700的MQTT_Broker IP、MQTT_Broker帳號及MQTT_Broker密碼的過程，分為兩次來執行；例如：第一次是用戶端裝置100以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)通過TCP/IP要求取得client_share_key及MQTT_Broker IP。而當後台裝置500收到轉成加密後的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確。待後台裝置500確認client_uuid正確後，後台裝置500將client_share_key及MQTT_Broker IP等以client_pub_key編碼後回傳至用戶端裝置100。第二次是用戶端裝置100再以編碼後的client_uuid(即client_uuid會根據sever_pub_key轉成秘文)，通過TCP/IP要求取得MQTT_Broker帳號及密碼；而當後台裝置500收到轉成加密後的client_uuid後，即會根據sever_pri_key進行解碼，以確認client_uuid是否正確；待後台裝置500確認client_uuid正確後，後台裝置500將MQTT_Broker帳號及密碼等以client_pub_key編碼後回傳至用戶端裝置100。特別要說明的，第一次及第二次所要取得的內容中，只要求將MQTT_Broker的IP、帳號及密碼分兩次取得，其他並不加以限制。

接下來，本發明要使用前述MQTT物聯網架構的通信協定並結合區塊鏈之超級帳本技術，來建立一個電動車充電站的運營平台及其管理方法。

首先，請參考圖5，是本發明的一種電動車充電站架構。特別要說明的是，本發明的電動車充電站是一種提供電動車快充服務的架構，特別是能提供一部電動車300千瓦以上的充電服務。其最關鍵的架構是必須使用獨立的發電模組來供應儲能電池模組作為每一個充電介面的電力供應模組，如此，才能達到提供快充服務並且不會影響周邊市電或是電網的運作。進一步而言，通過本發明的充電站架構，可以提供直流對直流(即是由儲能電池模組輸出直流電供應給充電樁300千瓦以上的電功率，充電樁再將直流電輸出至電動車)的充電方式，很明顯的，在本發明的一個實施例中，當使用這種直流對直流(DC-DC)的充電方式時，在充電樁模組中，就可以選擇不用逆變器，只需提供充電槍接頭來與電動車連接並進行通信及充電，故可以降低充電樁的成本。

接著，如圖5所示，本發明的電動車充電站架構200是由發電模組210、儲能電池模組220、逆變器控制模組230、至少一個充電樁模組240、至少一個換電櫃250以及一個能源管理模組(Energy Management System；EMS)260等所組成，用以提供發充電站所需的電功率(簡稱功率)。其中，避免敘述過於累贅，可以將至少一個充電樁模組240及至少一個換電櫃250統稱為充電介面。其中，發電模組210、EMS模組260及每一個充電樁模組240上，均配置有智慧電錶(未顯示於圖中)，可以將發電模組210及EMS模組260所送出的功率(包括：電壓及電流的類比信號)及每一個充電樁模組240所提供給電動車的充電功率送至後台500或是邊緣運算裝置。

如圖5所示，本發明的發電模組210可以是一種發電機所組成的發電模組、一種太陽能發電模組、一種風力發電模組、一種液流電池模組或是一種再生能源模組等，很明顯的，本發明對此發電模組是何種發電方式來產生電源的供應，並不加以限制。在本發明的實施例中，發電模組210的發電量大小，可以選擇發電量在100千瓦/小時以上。

繼續如圖5所示，儲能電池模組220其輸入端與發電模組210連接，藉由發電模組210所提供的輸入電能來將儲能電池模組220充滿電力。在本發明的實施例中，在一個充電站中的儲能電池模組220的電池儲能容量，可以選擇性的配置在500千瓦至2000千瓦，其中，儲能電池模組220中的電池模組可以選擇一種磷酸鐵鋰所形成的電池模組。根據本發明的實施例，若是使用100千瓦/小時的發電模組210來對儲能電池模組220進行儲能時，可以在6至8個小時以內將儲能電池模組220充滿至500千瓦以上，因此，可以選擇在晚間或是離峰時間將儲能電池模組220充滿電能。此外，由於儲能電池模組220的輸出是直流電壓，因此，當儲能電池模組220的輸出選擇設定為固定功率的快充模式來輸出電力時，可以選擇直接與充電樁模組 240連接，如圖5中的充電路徑1所示。此外，也可以選擇將儲能電池模組220的輸出先連接至逆變器控制模組230升高至設定的高功率後，再與充電樁模組240連接，如圖5中的充電路徑2所示。再者，當儲能電池模組220的輸出選擇設定為可調變輸出電功率時，可以選擇將儲能電池模組220的輸出連接至EMS模組260，再由EMS模組260連接逆變器控制模組230後，就可以通過電源管理模組260來控制逆變器控制模組230輸出不同的電功率後，再與充電樁模組240連接，如圖5中的充電路徑3所示，使得充電路徑3可以根據電動車不同的充電需求通過EMS模組260來調整，例如：逆變器控制模組230可以控制直流電壓在400V、600V、800V、1000V或是超過1000V中調整。此外，還有可以選擇將儲能電池模組220與EMS模組260直接連接至充電樁模組240，如圖5中的充電路徑4所示，此時，充電樁模組240可以根據電動車不同的充電需求提供是當的電功率對電動車充電。

要說明的是，本發明的充電站架構是以提供電動車的快充為主要的模式，但因電動車可以選擇不同的充電功率，因此，根據本發明上述的配置方式，使得每一個充電站中的儲能電池模組220可以較有彈性的來選擇逆變器控制模組230的配置數量。若再換一個角度來說，根據本發明的充電站架構而言，是可以選擇完全由EMS模組260來控制充電功率(也就是說，不配置逆變器控制模組230，如圖5中的充電路徑1所示)，這樣可以節省設置逆變器控制模組230的成本。此外，當充電站中選擇配置有逆變器控制模組230時(如圖5中的充電路徑2所示)，其在位置的配置上，是可以根據儲能電池模組220與充電樁模組240之間的距離來選擇，用以縮短執行快充時直流對直流(DC-DC)快充的線路距離，以降低電力傳輸線產生高熱的解決門檻。例如：若儲能電池模組220與充電樁模組240之間的距離很近時，可以選擇將逆變器控制模組230配置在儲能電池模組220附近。若儲能電池模組220與充電樁模組240之間的距離較遠時，可以選擇將逆變器控制模組230配置在充電樁模組240附近。

接著，說明充電介面。本發明的充電介面可以包括：至少一個充電樁240及至少一個換電櫃250的組合。

請繼續參考圖5所示，至少一個充電樁模組240，其中一部分充電樁模組240的一端直接與儲能電池模組220連接，可以提供直流對直流(DC-DC)的充電方式。而另一部分充電樁模組240的一端則可以選擇與逆變器控制模組230連接，使得電動車可以選擇不同充電速度的需求。而每一個充電樁模組240的另一端則是以充電槍的形式配置，以便通過充電槍來與電動車上的充電座介面連接。其中，每一個充電樁模組240上皆有顯示幕幕，而充電槍則可以是以單槍、雙槍或是多槍等方式配置在充電樁模組240一側邊或是多個側邊上。

請繼續參考圖5所示，至少一個換電櫃模組250，其中，對換電櫃模組250的充電方式有2條路徑。首先，如圖5中的充電路徑5所示，是儲能電池模組220直接與換電櫃模組250連接，可以提供直流對直流(DC-DC)的方式對換電櫃模組250中的電池充電，其中，每一個換電櫃模組250中配置多個可以取出或是嵌入電池模組(未顯示於圖中)，使得每一個電池模組都可以通過換電櫃模組250進行充電。其次，如圖5中的充電路徑6所示，也可以選擇將儲能電池模組220先連接至EMS模組260後，再連接至換電櫃模組250，也可以提供直流對直流(DC-DC)的方式對換電櫃模組250中的電池充電。在發明的實施例中，每一個換電櫃250上皆有顯示幕幕，螢幕上可以顯示出哪些電池模組已經完成充電，可以取出作為換電的電池模組。同時，螢幕上也可以顯示出哪些電池模組還在充電中，是無法可以取出這些正在充電中的電池模組。要說明的是，本發明的換電櫃模組250可以根據所要提供換電的電動車形式來分別設立，例如：分別在充電站不同的位置上設立二輪、三輪或是四輪的換電櫃模組250。此外，也可以選擇將二輪及三輪的電池模組配置在同一個換電櫃模組250上。

最後，請再參考圖5所示，在本發明的實施例中，充電站中的每一個模組都配置有一個物聯網控制器(顯示於圖6中)。而物聯網控制器270是由微控制器(MCU)及微處理器(MPU)所組成，其中，微處理器中包括了處理器模組、無線通訊模組與記憶體模組。在經過適當的資料流程的設定後，使得每一個物聯網控制器都可以將相應模組的功率信號與操作狀態信號以無線通訊方式送出，同時，通過物聯網控制器的配置，使得充電站中的每一個模組都具有邊緣運算(Edge Computing)的功能，進一步使得充電站中的每一個模組都可以做為超級帳本中的識別節點(Hyperledger-Indy node)，其中，Hyperledger-lndy是採用區塊鏈(Blockchain)技術作為其底層技術。經過上述的說明，在本發明的充電站200架構中的每一個模組都是可以做一個去中心化身份驗證(DID)的節點(node)，包括後台裝置500、電動車以及會員手機。其中，充電站架構200中的每一個身份驗證(DID)的節點都能與後台裝置500進行通信連接。例如：可以選擇性的定義發電模組210是DID1、儲能電池模組220是DID2、逆變器控制模組230是DID3、充電樁模組240是DID4、換電櫃模組250是DID5以及EMS模組260是DID6。

再接著，在本發明的實施例中，會員10是通過手機上的App與充電介面(包括：充電樁模組240或是換電櫃模組250)上的螢幕進行資訊識別及授權，而這些與會員10交流的資訊都必須具有高度的資訊案安全手段來保護會員10的個資及數位錢包。因此，當充電站200中配置有多個充電樁模組240或是多個換電櫃模組250時，每一個充電樁模組240或是換電櫃模組250都需要配置物聯網控制器，進一步使得每一個充電樁模組240或是換電櫃模組250都是可以做一個身份驗證(DID)的節點，通過Hyperledger-lndy的區塊鏈技術，使得會員10的每一次使用充電樁模組240或是換電櫃模組250進行充電過程的所有紀錄，都可以通過分散式帳本的技術，將所有紀錄以副本方式分享至充電站中的每一個身份驗證(DID)節點。也因此，如圖5所示，當充電站中配置有多個充電樁模組240時，每一個充電樁都可以有各自獨立的身份驗證(DID)的節點，例如：當充電站中配置3個充電樁模組240時，其各自的身份驗證(DID)節點分別為DID4-1、DID4-2及DID4-3。另外，對於多個換電櫃模組250而言，每個換電櫃模組250即可成為各自獨立的身份驗證(DID)的節點，例如：當充電站中配置3個換電櫃模組250時，其各自的身份驗證(DID)節點分別為DID5-1、DID5-2及DID5-3。

再進一步來看，本發明上述的EMS模組260，其可以通過物聯網控制器來與充電站中的每一個模組連接，並通過無線通訊來顯示與監控每一個模組的操作資訊及狀態。再者，通過上述的配置方式，進一步使得本發明的EMS模組260，可以通過本身具有邊緣運算的功能，對其所在的充電站的每一個節點的操作或是運營狀況，經過人工智慧的演算後，發出控制指令。例如，當500千瓦的儲能電池模組220的電能已經消耗超過50%時，同時，經過會員10完成預約的資訊分析後，並由後台裝置500或是儲能電池模組220判斷在未來的一小時內，還會有300千瓦的充電需求時，則EMS模組260會立即重新開機發電模組210開始發電並對儲能電池模組220進行充電程式，以滿足充電站的運營需要。當EMS模組260判斷預約的充電需求已經解除，並且在儲能電池模組220又已經充滿電能時，EMS模組260可以讓發電模組210繼續運轉，將此時所發出的電能可以通過私有微電網280，將電能供應至私有微電網280的的用戶或是私有微電網280的儲能裝置中。也可以將此時所發出的電能通過公有電網290，將電能供應至公有電網290中。若當EMS模組260計算出儲能電池模組220的運營需要充電時，再由EMS模組260下達指令，將發電模組210的電能切換至儲能電池模組220並進行充電。很明顯的，在本發明的充電站中的發電模組210可以在維持妥善率(Availability)的狀況下，持續運轉發電，並通過EMS模組260可以將電能賣給私有微電網280或是公有電網290的用戶，可以有效的增加充電站運營的收入。其中，私有微電網280可以包括：充電站用電或是與充電站周邊的商店或是智慧宅用電，而公有電網290則包括了政府運營的電網等。特別要說明，上述的運營控制過程中，除了由EMS模組260的邊緣運算功能來執行之外，EMS模組260也可以接受後台裝置500的指令來執行上述的運作，後續將會再詳細說明。

接下來，請參考圖6a及圖6b，是揭示本發明充電站的信號傳遞路徑的示意圖。其中，在圖6a的充電站架構中，是以圖5中最基本的一個發電模組210、一個充電樁模組240以及雲端(或是後台)500所組成。另外，在圖6b的充電站架構中，是以圖5中的一個發電模組210、儲能電池模組220、一個充電樁模組240以及雲端(或是後台)500所組成。此外，在圖6a及圖6b中的每一個模組上均可以選擇性的配置有物聯網控制器270，用以將每一個模組上的電力信號、操作信號及保護信號等傳的至後台裝置500中。其中，電力信號包括：發電模組210、儲能電池模組220及充電樁模組240的輸入或是輸出的電力信號。由於在物聯網控制器270中，配置有微處理單元(MPU)，使得充電站中的每一個模組都具有邊緣運算(Edge Computing)的功能，進一步使得充電站中的每一個模組都可以做為超級帳本(Hyperledger-lndy)中的身份驗證(DID)的節點，其中，Hyperledger-lndy是採用區塊鏈(Blockchain)技術作為其底層技術。以及，在圖5、圖6a及圖6b中的發電模組210、儲能電池模組220、EMS模組260及每一個充電樁模組240上，均可以選擇性的配置有智慧電錶(未顯示於圖中)，使得智慧電錶可以將發電模組210、儲能電池模組220及EMS模組260所送出的功率(包括：電壓及電流的數位/類比信號)及每一個充電樁模組240所提供給電動車的充電功率通過物聯網控制器270送至後台裝置500。

首先，如圖6a所示，是本發明的電站的一種實施例架構，其中，充電站200是由一個發電模組210、一個充電樁模組240以及雲端(或是後台)500所組成。充電樁模組240是由充電樁介面2410及物聯網控制器270。其中，充電樁介面2410是由充電模組/充電槍2430及充電模組控制器2450所組成，而充電模組/充電槍2430上也配置有智慧電錶，可以將功率信號傳送至充電模組控制器2450。另外，在本發明的一個較佳實施例中，發電模組210是一個由多個定子與轉子所組成的發電機裝置，因此，發電模組210需要接收一個啟動電源才能驅動發電模組210中的發電機裝置運轉並輸出電力，其中，此一啟動電源可以是由電池來提供，也可以連接即有電網(即市電)，但為了使動發電模組210符合綠色標章的規範，在本發明的較佳實施例中，啟動電源的電力來源可以是太陽能等各種符合環保的綠色能源所提供。因此，通過綠色能源啟動發電模組210後，本發明的發電模組210所產生的電力就是一種符合綠色標章的規範的發電系統。

如圖6a所示，本發明的發電模組210的輸出端是與電樁模組240連接，用以將輸出電力經過電力傳輸線(Power Line)送至充電樁模組240。同時，發電模組210與物聯網控制器270連接後，可以將發電模組210運轉時的各種功率的類比信號經過微控制單元(MCU)轉換成數位信號後，將各種數位信號傳送至微處理單元(MPU)中，由微處理單元(MPU)與記憶體模組將功率信號與操作狀態信號經過資料串流(data streaming)後，選擇以MQTT通信協議由物聯網控制器270中的無線通訊模組送至後台裝置500。同時，因物聯網控制器270配置了微處理單元(MPU)，使得充電站中的每一個模組都具有邊緣運算(Edge Computing)的功能，進一步使得充電站中的每一個模組都可以做為超級帳本(Hyperledger-Indy)中的身份驗證(DID)節點(node)，其中，Hyperledger-lndy是採用區塊鏈(Blockchain)技術作為其底層技術。例如：由微控制單元(MCU)將發電模組210上的智慧電錶送出的電壓(V)及電流(I)的類比信號，經過電路處理後，轉換成數位化的電壓及電流信號(即數位信號)，之後，將數位化的電壓及電流數位信號連接至微處理單元(MPU)，經微處理單元(MPU)將這些數位電壓及電流信號儲存及處理後，可以選擇將這些數位信號使用區塊鏈的演算法進行編碼，並將這些區塊鏈編碼資訊傳送至超級帳本中的至少一個身份驗證(DID)節點與後台裝置500中。特別要說明的是，上述實施例是以電壓及電流信號為例來說明，實際上，也可以同時對發電模組210中的操作信號及保護信號進行處理，其中，操作信號(Operated Signal)包括量測發電模組210的多個軸運轉時的微震動信號(例如：是由配置在發電模組210的X/Y/Z軸上的微震動感測器所送出的信號)及發電模組210殼體的溫度以及環境溫度等信號。而保護信號(Protective signal)則包括過壓保護信號、過熱保護信號、絕緣信號及斷電信號等。

在本發明的充電站200中，通常可以配置多個充電樁模組240，而每一個充電樁模組240是由充電樁介面2410及物聯網控制器270所組成，其中，充電樁介面2410還包括：充電模組/充電槍2430及充電模組控制器2450。當發電模組210以電力線(Power Line)將電功率連接至充電樁模組240中的充電模組/充電槍2430後，充電模組/充電槍2430會將其電功率信號、充電模組/充電槍2430的操作信號及保護信號傳送至充電模組控制器2450。當充電模組控制器2450與物聯網控制器270連接後，物聯網控制器270就可以經過微處理單元(MPU)將這些功率信號與操作狀態信號經過資料串流(data streaming)後，選擇以MQTT通信協定由無線通訊模組送至後台裝置500。

特別要說明的是，在本發明中的每一個充電樁模組240都是各自獨立的身份驗證(DID)節點，因此，每一個充電樁模組240的驗證碼(也就是區塊鏈雜湊碼-hash code)都已存在充電模組控制器2450中，故充電模組控制器2450可以隨時與後台裝置500保持通信，特別是當這些充電樁模組240使用開放充電協定(Open Charge Point Protocol,OCPP)來將每一個充電樁模組240上的資訊傳遞至其他充電樁模組240的節點與後台裝置500，讓後台裝置500可以即時的收到每一個充電樁模組240目前的使用狀態，藉此OCPP協定可以讓後台裝置500將多個充電站形成聯合網路，其中，OCPP協定可以使用websocket通信協定來進行雙向資訊的通信。此外，在本發明的較佳實施例中，為了確保每一個充電樁模組240運作的過程可以完全符合符合綠色標章的規範，進步可以選擇將充電樁模組240中的功率信號與身份驗證信號通過充電模組控制器2450先傳送至物聯網控制器270後，經微處理單元(MPU)將這些功率信號與身份驗證信號儲存，之後，根據區塊鏈雜湊碼(hash code)驗證資料來源正確後，並將這些區塊鏈編碼資訊傳送至超級帳本中的身份驗證(DID)節點與後台裝置500中。

很明顯的，在本發明的充電站200運營時，每一個充電樁模組240上的智慧電錶所輸出的電功率數位根據區塊鏈的技術儲存在個節點上，亦可以通過websocket通信協定使用明碼的方式傳送至後台裝置500或是認證的綠色標章的第三方認證單位600。同時，充電站200也可以通過MQTT通信協定並且使用微處理單元(MPU)將智慧電錶所輸出的電功率數位，經過區塊鏈編碼技術編碼後，以加密編碼的方式傳送至超級帳本中至少一個身份驗證(DID)節點與後台裝置500中。因此，本發明的充電站200從發電模組210的智慧電錶所輸出的電功率數位，以及每一個充電樁模組240智慧電錶所輸出的電功率數位，都是通過MQTT通信協定並且通信內容都是使用區塊鏈加密編碼方式傳送至後台裝置500、每一個超級帳本的身份驗證(DID)節點以及認證的綠色標章的第三方證單位600。因此，本實施例使用MQTT通信協定並且通信內容都是使用區塊鏈加密編碼方式來傳遞資訊的手段，是符合WEB3.0的資安與保密規範。為了便於綠色標章的第三方認證，第三方認證單位600可以告知後台裝置500一個第三方認證單位的鏈 (chain)，因此，後台裝置500會將所有的超級帳本的區塊鏈加密資訊通過MQTT通信協定傳給綠色標章認證方所提供的鏈中，而綠色標章認證方在需要的時候，隨時可以解碼區塊鏈的加密資訊(例如，包括：發電機輸出的功率、儲能電池組的輸出的功率、每一個充電樁的輸出的功率以及電動車完成充電後的帳單等)，之後，可以與所收的明碼資訊進行核實或是比對。此外，綠色標章的第三方認證單位600也可以選擇，當第三方認證單位600要進行綠色標章的明碼資訊的核實時，再向後台裝置500申請區塊鏈認證憑證後，三方認證單位就可以通過認證憑證對每一個超級帳本的區塊鏈加密資訊進行解碼運算後，將解碼資訊與明碼的綠色標章資訊進行核實或是比對。至於，綠色標章的第三方認證單位600使用何種解碼手段，本發明並不加以限制。

再接著，請參考圖6a及圖6c所示，其中，圖6c是充電站與會員之間的身分認證示意圖。當會員10使用智慧手機120或是電動車110並以http通信協定向後台裝置500完成對一個充電站200的充電預約後，後台裝置500就會將此會員10的身分資訊以http通信協定或是websocket通信協定傳遞至所預約的充電站200中的DID結點(node)。同時，會員10也能透過電動車110或是智慧手機120向後台裝置500取得進入充電站200的身份驗證憑證訊息。接著，當電動車110到達充電站200並停妥在充電樁模組240附近後，可以將充電模組2430的充電槍與電動車110完成充電介面的連接，之後，電動車110就會將其需要充電的需求電力度數等資訊，通過充電模組/充電槍2430傳遞至充電模組控制器2450。接著，充電模組控制器2450就會以http通信協定或是websocket通信協定發出認證通知至智慧手機120或是電動車110 中，並顯示一個要求會員10要同意或是確認的資訊，當充電模組控制器2450收到此一認證程式後(即表示會員10的交換憑證確認無誤)，才能供電。要特別說明的是，本發明需要經過此一認證程式的原因是，當充電站200聯網後，後台裝置500可以提供多個不同位置充電站200的資訊，由於每一個充電站200都是獨立的去中心化的節點(DID node)，因此，在完成充電站200的聯網後，後台裝置500都會賦予每一個充電站200一個唯一的超級帳本中的身份驗證憑證，之後，就可以通過此唯一的身份驗證憑證進行區塊鏈的加密編碼與解碼。換句話說，區塊鏈認證憑證是後台裝置500將會員身分的編碼以特定充電站的雜湊參數來編碼(因為每一個充電站200的DID node都有一個各自的編碼，也都能根據各自的雜湊碼來進行區塊鏈上的資料操作)，故會員身分的編碼只能由該特定站的雜湊參數才能解碼確認身分。此時，當一部電動車110到達一個充電站200時，都需要通過智慧手機120上的驗證憑證確認，如圖6c所示，才能進行充電程式。

更進一步說明，充電模組2430的充電槍供電前一定要確定充電者(即會員10或是電動車110)的身分，而這個程式是後台裝置500與智慧手機120(或是電動車110)上的APP之間的固定程式，對會員10或是充電者來說，只要按下確認就完成，而此一確認程式是要確證充電模組控制器2450與充電者(即會員10或是電動車110)的智慧合約(Smart Contract)的記載程式，其中，此一Smart Contract的內容記載了實際充電至電動車110的電功率度數以及交易金額，用以作為綠色標章的認證證據。同時，如圖6a所示，此一Smart Contract的內容會以websocket通信協定或是MQTT通信協定傳送至超級帳本中的每一個身份驗證(DID)節點、綠色標章的第三方認證單位600與後台裝置500中。

很明顯的，這個會員10與充電站200上的節點進行認證的過程，完全是由後台裝置500來執行，而會員10只需要在智慧手機120按下同意件即可完成認證。完成認證後，充電站200及後台裝置500都能確認是哪一台電動車110在進行充電以及最終完成交易時，實際支付多少充電的費用(換句話說，本發明的充電模組控制器2450能夠記錄每一部電動車110需要充入多少的電功率以及實際充入多少的電功率)，用以完成消費者(會員10)與充電站之間的智慧合約的區塊鏈資訊。因此，本發明所能提供的綠色標章的認證資料包括：發電機輸出的功率、每一個充電樁的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等全程電功率鏈資訊。

最後，請參考圖6b。圖6b是在圖6a的基礎上，在發電機210與充電樁模組240之間，再串接一個儲能電池組220，且每一個儲能電池組220都配置有智慧電錶及物聯網控制器270，用以提供儲能電池組220輸出的電功率的記錄。由於儲能電池組220是超級帳本中的一個身份驗證(DID)節點，故電功率的記錄會以websocket通信協定或是MQTT通信協定傳送至超級帳本中的每一個身份驗證(DID)節點、綠色標章的第三方認證單位600與後台裝置500中。因此，本發明所能提供的綠色標章的認證資料進一步的包括：發電機輸出的功率、儲能電池組的輸出的功率、每一個充電樁的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等全程電功率鏈資訊。

接下來，請參考圖7，是揭示本發明的後台裝置與充電站中的模組通信路徑的示意圖，其中，圖7是進一步揭示出本發明在完成圖6a、圖6b及圖6c的連接架構之後，使用區塊鏈之超級帳本技術結合物聯網通信架構的實施例，用以建立一個可以提供電動車會員在多個供電站之間進行充電預約及充電服務的運營平台。

如圖7所示，首先，充電站200至少已經配置有發電模組210(DID1)、儲能電池模組220(DID2)、EMS模組260(DID6)及充電樁模組240(DID4)等，其中，這些模組都配置有物聯網控制器270，同時，這些模組都已經被指定是以EMS模組260作為物聯網通信架構的代理伺服裝置，因此，發電模組210、儲能電池模組220及充電樁模組240都已經與EMS模組260完成配對，故這些完成配對的模組都必須將其操作的資訊(如圖7中所標示的圓圈1所示方向)以MQTT通信協定傳遞至EMS模組260，而EMS模組260在收到這些資料串後，不做任何處理，而是直接將接收到的資料串直接傳送至後台裝置500。後台裝置500于收到EMS模組260所傳來的資料串後，需要經過資料處理模組520解碼後，才會將充電站200中的各模組的實際運作狀態儲存到記憶體模組530中，作為會員預約時的資料庫。很明顯的，此時的後台裝置500已經完全掌握了充電站的運狀況。例如：一部100千瓦/小時的發電模組210已經將1000千瓦容量的儲能電池模組220充滿，同時，儲能電池模組220也與4個充電樁(包括充電樁A,B,C,D)連接，可以提供直流對直流(DC-DC)的快充服務。此外，在圖7的實施例中，是進一步將4個充電樁模組240形成超級帳本中的驗證節點，使得這幾個充電樁都可以做為一個身份驗證(DID)的節點，能夠使用區塊鏈的技術形成分散式標識檔，並將所有紀錄以副本方式分享至每一個充電樁，可以確保充電樁模組240與會員10之間交易的資訊不會被竄改、盜用或否認等，可以有效的確保會員的個資、綠色標章的認證資料與電子錢包交易時的資訊安全。

接著，當一位註冊會員10通過手機120以TCP/IP通信協定傳遞向後台裝置500提出要為電動車B預約發電站200的資訊時(如圖7中所標示的圓圈2所示方向)，後台裝置500在收到了會員10預約的資訊後，進行身分查證程式，並在完成身分查證的程式後，就會查詢記憶體模組530中充電站200運作狀態，之後，後台裝置500以TCP/IP通信協定回復會員10可以使用充電樁A進行充電。再接著，電動車B至充電樁A處準備進行充電程式(如圖7中所標示的圓圈3所示方向)，此時，會員10需要通過手機120上的數位憑證或是數位簽證與充電樁A進行資訊交流，其中，在本發明中所述的數位憑證或是數位簽證等編碼及解碼過程會在後續內容中詳細說明)。當後台裝置500確認會員10手機120上所提供的數位簽章都正確時，就會執行充電及自會員10的電子錢包中進行扣款的程式(如圖7中所標示的圓圈4所示方向)。在本發明的較佳實施例中，圓圈2,3,4可以選擇以TCP/IP通信協議應用層中的http通信協議。很明顯的，在會員10與充電樁A進行資訊交流的過程中，特別是一種數位簽章驗證過程，充電樁A都會將資訊以副本方式分享至會員10的手機120及其他三個充電樁(即充電樁B,C,D)(如圖7中所標示的圓圈5所示方向)，其中，圓圈5可以選擇以TCP/IP通信協議應用層中的websocket或是MQTT通信協定，其中，websocket通信協定是使用開放充電協定(Open Charge Poiht Protocol,OCPP)將充電站200中的多個充電樁模組240之間的各種操作資訊相互連接後，傳送至後台裝置500。此外，在圖7的實施例中，後台裝置500可以根據充電站200的運營負載量，來要求充電樁模組240將區塊鏈的資訊通過EMS模組260以MQTT通信協定傳遞至後台裝置500(如圖7中所標示的圓圈6所示方向)。很明顯的，為了達到讓會員10能夠在完成預約充電之後，可以確保到達預約充電站就有充電樁模組240進行充電，也就是不用等待就有充電樁模組240提供充電服務，本發明的後台裝置500必須完全掌握每一個充電站200中的每一個充電樁模組240的即時使用狀態才能達成。根據前述在圖5及圖6的說明中，本發明的實施例中對於充電站200中的每一個充電樁模組240的即時使用狀態都可以通過MQTT通信協定及開放充電協定(OCPP)將各種操作資訊相互連接後，傳送至後台裝置500，其中，開放充電協定(OCPP)是使用websocket通信協定來傳遞資訊。而在本發明的較佳實施例中，圓圈5,6可以選擇以TCP/IP通信協議應用層中的MQTT通信協定，並且通信內容都是使用區塊鏈加密編碼方式來傳遞資訊的手段，是符合WEB3.0的資安與保密規範，可以有效的確保會員的個資、綠色標章的認證資料與電子錢包交易時的資訊安全。

在圖7中，只以充電樁模組240做為身份驗證(DID)的節點，是為了區隔在本發明的充電站200中，是可以提供三種資訊，一種是各個模組操作狀態的監控資訊，包括前述的操作信號(Operated Signal)及保護信號(Protective signal)。而這些操作態的監控資訊是以MQTT通信協定通過EMS模組260(作為代理伺服裝置)傳遞至後台裝置500，用以提供後台裝置500掌握充電站200的運營狀態。而另一種是超級帳本的區塊鏈資訊，可以確保會員的個資與電子錢包交易時的資訊安全。還有一種是提供第三方認證單位600認證綠色標章的資訊，這些資訊包括了從發電機輸出的功率、連接到儲能電池組的輸出的功率、再接到每一個充電樁的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等全程電功率鏈資訊。這些第三方認證單位600認證綠色標章的資訊可以選擇以TCP/IP通信協議應用層中的 MQTT通信協議，因此可以有效的確保會員的個資、綠色標章的認證資料與電子錢包交易時的資訊安全。

接下來，請參考圖8，是揭示本發明的後台裝置與充電站中的模組建立通信架構的示意圖。通過圖8的說明，本發明將會詳細的說明將區塊鏈之超級帳本技術結合物聯網通信架構後，用來建立一個可以提供註冊會員在多個充電站之間進行充電預約及充電服務的運營平台與流程。此外，在圖8的充電站200中的每一個模組都配置有一個物聯網控制器270，並在經過適當的資料流程的設定後，使得每一個物聯網控制器270都可以將相應模組的操作狀態的資訊送出。

接著，請參考圖8所示，在本發明的後台裝置500要建立運營平台時，會先將每一個充電站中的發電模組210、儲能電池模組220、逆變器控制模組230、充電介面(包括：充電樁模組240、換電櫃模組250)以及EMS模組260上的個別身份驗證(DID)作為通用唯一識別碼(uuid)。再接著，充電站中的每一個模組可以通過物聯網控制器270與後台裝置500建立連接關係，特別是以TCP/IP的通信協議完成S1至S7所示的順序。其中，在本發明的較佳實施例中，S1至S7可以選擇以TCP/IP通信協議應用層中的http通信協議。

在本發明的實施例中，當後台裝置500選擇將EMS模組260作為充電站的控制中心或是伺服器中心後，即是選擇以EMS模組260作為代理伺服裝置700，因此，後台裝置500即會賦予EMS模組260一個浮動的IP網址以及連接EMS模組260的帳號及密碼。故當充電站中的發電模組210、儲能電池模組220、逆變器控制模組230及充電介面都已經在前述的S1-S6過程中，都收到本充電站是以EMS模組260作為代理伺服裝置700並在S6步驟中確認收到完整的訊息後，即會與EMS模組260(即前述的代理伺服裝置700)進行連接。很明顯的，此時，充電站中的發電模組210、儲能電池模組220、逆變器控制模組230及充電介面等的這些模組已經與EMS模組260完成配對。因此，充電站中的發電模組210、儲能電池模組220、逆變器模組230及充電介面都會將其操作狀態的資訊通過相應的物聯網控制器270傳遞給EMS模組260。而EMS模組260在收到這些充電樁模組240所傳遞來的資料資訊後，EMS模組260是在不做任何處理而直接將接收到的資訊資料串傳送至後台裝置500，而後台裝置500在收到EMS模組260的資料串後，才由資料處理模組520進行解碼處理及經過資料的分流處理後，儲存至記憶體模組530中，以作為海量資料的分析的基礎。特別要強調的是，充電站200中的每一個模組將資訊串傳送給EMS模組260以及EMS模組260再傳給後台裝置500的過程中，都是以MQTT通信協議來進行，如圖8中的S8、S9及S10所示。很明顯的，由於EMS模組260只是將充電站中的所有資訊資料直接傳送給後台裝置500，故可以降低EMS模組260的MQTT_Broker IP及MQTT_Broker帳號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。

如前所述，本發明將充電站中的每一個模組以MQTT通信協定上傳資訊至EMS模組260(即代理伺服裝置700)後，若後台裝置500發現EMS模組260受到攻擊時，例如：當有駭客在訊息傳遞過程進行竄改、盜用或否認等行為時，後台裝置500即會在通過本發明的S10的程式來關閉EMS模組260的IP網址，並且通過本發明的S1-S6的程式重新指定一個新的模組作為新的代理伺服裝置700，之後，即會再通過S1-S6的程式依序告知充電站中的每一個模組新的代理伺服裝置700(例如：儲能電池模組220)的MQTT_Broker IP及MQTT_Broker帳號及密碼。特別要說明的是，指定儲能電池模組220為新代理伺服裝置的過程是以軟體定義網路(SDN)的方式進行，也就是當充電站中的每一個模組收到後台裝置500所送來的內容後，就會自動的更新至新的MQTT_Broker IP及MQTT_Broker username/passward，故當充電站中的每一個模組再送出操作資訊狀態時，就會直接通過新的代理伺服裝置(例如：儲能電池模組220)與後台裝置500連接。很明顯的，這段更新代理伺服裝置700連接的過程，使用者是不需要被通知的。

接著，請再參考圖8所示，充電站中的每一個充電樁模組240可以進一步的選擇使用開放充電協議(Open Charge Point Protocol,OCPP)來將每一個充電樁模組240上的資訊傳遞至後台裝置500，讓後台裝置500可以即時的收到每一個充電樁模組240目前的使用狀態，藉此OCPP協定可以讓後台裝置500將多個充電站形成聯合網路。形成聯網後，後台裝置500就可以提供電動車來選擇及預約任何一個充電站上的充電樁模組240，降低車主或是會員等待充電的機率。其中，OCPP協定傳遞充電樁模組240的資訊，已在圖5及圖6中詳細說明，故不再贅述之。

最後，如圖8所示，本發明能夠提供第三方認證單位600認證綠色標章的資訊，這些綠色標章的認證資訊包括了從發電機輸出的功率、連接到儲能電池組的輸出的功率、在連接到每一個充電樁的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等全程電功率鏈資訊。這些第三方認證單位600認證綠色標章的息可以選擇以TCP/IP通信協議應用層中的MQTT通信協議，因此，可以有效的確保會員的個資、綠色標章的認證資料與電子錢包交易時的資訊安全。

再接著，請參考圖9所示，是揭示本發明的後台裝置與多個充電站建立通信架構的示意圖。首先，圖9中的每一個充電站的地理位置座標，都已經儲存在後台裝置500中的記憶體模組530。同時，每一個充電站內的模組架構以及連接關係是與圖5及圖6相同，包括：發電模組210是身份驗證的節點1(DID1)、儲能電池模組220是身份驗證的節點2(DID2)、逆變器控制模組230是身份驗證的節點3(DID3)、充電樁模組240是身份驗證的節點4(DID4)、換電櫃模組250身份驗證的節點5(DID5)以及EMS模組260是身份驗證的節點(DID6)。其中，圖10中所示的每一個充電站200中的身份驗證的(DID)節點都已經與後台裝置500完成配對程式。換句話說，當圖9中的每一個充電站200都指定是以EMS模組260作為代理伺服裝置時，就表示每一個充電站200中的發電模組210(DID1)、儲能電池模組220(DID2)、逆變器控制模組230(DID3)、充電樁模組240(DID4)及換電櫃模組250(DID5)等，都已經被配對要通過EMS模組260且以MQTT通信協定將操作資訊狀態的監控信號傳遞至後台裝置500中解碼及儲存。因此，當註冊會員發出充電預約時，後台裝置500就能根據會員10手機的座標位置來回復註冊會員可以至哪一個充電站進行充電，或是回復註冊會員有哪些充電站可以進行充電，讓會員來自己選擇。

很明顯的，圖9最主要是顯示出本發明的後台裝置500可以與多個充電站完成運營過程的每一個模組的操作資訊狀態的監控，因此可以提供註冊會員根據自己的電動車電力的使用狀況，隨時在提出充電預約需求後，通過後台裝置500的回復，自己可以選擇要去哪一個充電站進行充電，而不一定要去指定的充電站才能充電的問題，可以有效的提高客戶使用經驗。此外，通過本發明圖9的架構，可以讓本發明的運營平台具有更高的妥善率與應變能力。例如：當充電站200-1中的EMS模組260(即代理伺服裝置)被駭客攻擊，或是EMS模組260發生操作異常時，則後台裝置500一方面可以選擇關閉充電站200-1中的EMS模組260，同時，後台裝置500可會立即通過圖1中的S7標示的通信方向，通知被關閉的EMS模組260上的所有模組，以新的MQTT_Broker IP及MQTT_Broker username/passward向新指定的代理伺服裝置連接，例如：指定以充電站200-2中的EMS模組260為新的代理伺服裝置。此時，充電站200-1中的每一個模組就會自動的向充電站200-2中的EMS模組260進行連接，使得充電站200-1不會因為EMS模組260的任何因素，造成充電站200-1無法運營的狀態。特別要說明的是，後台裝置500指定新的代理伺服裝置的過程是以軟體定義網路(SDN)方式進行，也就是當充電站每一個模組中的物聯網控制器收到後台裝置500所送來的內容後，就會自動的更新至新的MQTT_Broker IP及MQTT_Broker username/passward，就會直接通過新的代理伺服裝置(即充電站200-2中的EMS模組260)與後台裝置500連接，繼續維持充電站運營的狀態。很明顯的，這段更新代理伺服裝置連接的過程，充電站中的每一個模組是不需要被通知的。

更進一步來說，當充電站內的模組都配置物聯網控制器而具有邊緣運算的功能後，並在與後台裝置500完成物聯網通信架構的連接後，也就是如圖9所示的架構，則可以在任何時間，後台裝置500都可以執行代理伺服裝置更新的過程，例如：充新重新設定充電站200-1的代理伺服裝置由EMS模組260更新為儲能電池模組220後，後台裝置500在完成前述軟體定義網路(SDN)的程式後，則充電站200-1中的所有模組(包括EMS模組260)都已經與儲能電池模組220完成配對，之後，所有模組都是以MQTT通信協定將操作狀態監控信號傳遞至後台裝置500中解碼及儲存。

當然，當充電站內的模組都形成超級帳本中的具有身份驗證(DID)的節點後，故每一個模組所送出的操作資訊狀態都會以副本方式分享至每一個模組，可以確保充電站200中的每一個模組操作狀態不會被竄改、盜用或否認等，可以有效的確保充電站200的資訊安全。

再更進一步來說，當充電站內的模組都具有作為身份驗證(DID)的節點時，後台裝置500可以隨時要求每一個充電站將充電樁模組240與會員10之間交易的資訊以MQTT通信協定分享至後台裝置500，可以更有效的確保會員的個資與電子錢包交易時的資訊安全。很明顯的，圖9可以顯示出本發明是一種將區塊鏈之超級帳本技術結合物聯網通信架構後，所建立的一個可以提供電動車會員在多個供電站之間進行充電預約及充電服務的運營平台。

此外，請再參考圖9所示，充電站中的每一個充電樁模組240可以進一步的選擇使用開放充電協議(Open Charge Point Protocol,OCPP)來將每一個充電樁模組240上的資訊傳遞至後台裝置500，讓後台裝置500可以即時的收到每一個充電樁模組240目前的使用狀態，藉此OCPP協定可以讓後台裝置500將多個充電站形成聯合網路。形成聯網後，後台裝置500就可以提供電動車來選擇及預約任何一個充電站上的充電樁模組240，降低車主或是會員等待充電的機率。其中，OCPP協定傳遞充電樁模組240的資訊，已在圖5及圖6中詳細說明，故不再贅述之。

最後，如圖9所示，本發明能夠將每一個充電站中的綠色標章的資訊提供給第三方認證單位600，這些綠色標章的認證資訊包括了從發電機輸出的功率、連接到儲能電池組的輸出的功率、在連接到每一個充電樁的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等全程電功率鏈資訊。這些第三方認證單位600認證綠色標章的資訊可以選擇以TCP/IP通信協議應用層中的MQTT通信協議，因此，可以有效的確保會員的個資、綠色標章的認證資料與電子錢包交易時的資訊安全。

接下來，要說明本發明的所有電動車車主必須先下載應用程式(App)，之後，才能通過手機上的應用程式(App)與後台裝置500進行註冊並須完成身分管理的程式，才能成為註冊會員，之後，才能通過註冊會員的身分來預約充電站及進行充電，其中，註冊會員是必須通過數位簽章的辨識，才能進行充電程式。其中，說明本發明的身分管理內容檔案的建立過程。請參考圖10a及圖10b所示，是本發明使用程式來對QR-Code序列化的示意圖。

本發明的後台裝置500對於會員10的身分管理內容檔案是包括：主張、證明、辨識及授權。其中，會員的身分主張是以會員10所使用的智慧型通信裝置的識別字號(以下簡稱手機號碼)以及手機號碼數位憑證，例如：手機號碼或是具有用戶身分卡(Subscriber Identity Module，SIM)的通信裝置。接著，身分證明是以會員10的車牌號為目標，特別是，會員10可以指定或是綁定多個或是一個以上的車牌。再接著，身分辨識是以會員10指定的車牌號的數位憑證為目標。特別是將手機號碼以及車牌號進行QR-Code轉換後，通過一個程式對QR-Code進行序列化運算之後，就可以將此QR-Code序列化的結果作為數位憑證，其序列化過程如圖10a所示。其中，本發明是使用一個自行開發的程式來對QR-Code序列化的過程如下：

首先，由資料處理模組520將手機號碼以及車牌號轉換成QR-Code。接著，由資料處理模組520使用程式將QR-Code轉換為二維座標，例如：轉換為512x512格的座標。之後，由資料處理模組520進行對二維座標進行降維處理，例如：資料處理模組520使用程式的亂碼產生器產生x軸的第一亂碼及y軸的第二亂碼，通過第一亂碼及第二亂碼可以確定一個起始座標點位置，以此亂碼所產生出的座標點位置作為序列化(降維)的起點，並由程式來根據QR-Code上的黑白圖案來轉換為一維條碼，轉換方式可以選擇從左向右且由上向下方的順序來分別取得會員手機號碼的一維條碼及車牌號的一維條碼。例如：從起始座標點開始取16個位的一維條碼資訊或是取32個位的一維條碼資訊或是取64個位的一維條碼資訊，如圖10b的右側圖所示。

資料處理模組520將會員手機號碼一維條碼及車牌號一維條碼的資訊轉換成一種資料結構格式，以作為數位憑證，其中，本實施例中的數位憑證的資料結構包括：會員身分管理的手機號碼、車牌號碼、轉換出的手機號碼一維條碼及車牌號一維條碼，再加上形成資料結構的時間戳記(Timestamp)這些資料，如圖11a所示，之後，先將這兩個數位憑證的資料結構儲存至記憶體模組530中。

再接著，為了增加運營平台對會員10個資安全的保護，特別是對於數位錢包進行實質支付時的管理，本發明可以進一步使用電子簽名數位憑證來授權會員10的身分。例如：請會員10在手機的螢幕或是通過充電介面上的螢幕，提供一個電子簽名，之後，資料處理模組520會將此一電子簽名轉換成一個格式化的圖檔，例如：轉換成一個固定長度(h)與寬度(w)的圖檔，以便轉換為512x512格的二維座標，再將此一電子簽名的圖檔進行序列化的處理過程(如圖10a所示)後，將所得到的電子簽名圖檔的一維條碼作為電子簽名的數位憑證，如圖10b的左側圖所示。

資料處理模組520將電子簽名圖檔的一維條碼資訊轉換成一種資料結構格式，以作為第三個數位憑證，其中，本實施例中的第三個數位憑證的資料結構包括：註冊會員的電子簽名、電子簽名圖檔的一維條碼，再加上形成資料結構的時間戳記(Timestamp)這些資料，如圖11a所示，之後，將這第三個數位憑證的資料結構儲存至記憶體模組530中。

接著，本發明的資料處理模組520還可以進一步的選擇對會員手機號、車牌號及電子簽名圖檔的一維碼進行Hash運算，以得到會員手機號碼、車牌號及電子簽名圖檔的「Hash摘要」。因此在本發明的較佳實施例中，其所定義的數位憑證的內容至少包括：一維碼、Hash摘要及時間戳記(Timestamp)這些資料，以作為會員10的數位憑證資料結構，如圖11a所示，並儲存至記憶體模組530中。很明顯的，註冊會員的數位憑證資料結構包括：第一部分(PART1)的會員手機號碼數位憑證，第二部分(PART2)的電動車車牌號數位憑證，以及第三部分(PART3)的會員電子簽名的數位憑證。接著，資料處理模組520再擷取此三個數位憑證資料結構中的「Hash摘要」，用以編輯成一個數位簽章資料結構檔，如圖11b所示，並將數位簽章資料結構檔傳送至會員10的手機中儲存，用以作為一個公開金鑰(public key)。當會員的手機在收到數位簽章資料結構檔之後，即表示已經完成會員註冊，成為一個註冊會員。另外，在本發明的較佳實施例中，在會員完成註冊前，可以選擇以TCP/IP通信協議應用層中的http通信協定來傳遞資訊。

在本發明的一個較佳實施例中，資料處理模組520在取16個位的一維條碼資訊或是取32個位的一維條碼資訊或是取64個位的一維條碼時，程式所取得的一維條碼的第1個位必須是1，以避免亂數產生的起始點位置是大片的空白區域，造成一維條碼都是0的情形產生。

此外，要強調的是，本發明選擇使用降維成一維條碼的處理目的，是要降低數位憑證及數位簽章的資料量，由於一維碼或是Hash摘要的資料量內容都很低，例如：幾百位，故符合本發明使用MQTT通信協定的目的。

本發明在會員10與後台裝置500完成註冊以及取得數位簽章的過程，都是使用TCP/IP通信協議。由於TCP/IP通信協定是屬於混合型密碼防駭、安全通訊協定(SSL)或傳輸層安全協議(TLS)，其本身屬於公認的安全協定，此時，後台裝置500所需要的公認憑證，就可以由會員10所提供的數位簽章來確認。因此，當有駭客在訊息傳遞過程進行竄改、盜用或否認等行為時，都可藉由這些安全認證來防止。

此外，在進行會10員註冊的過程中，會員10通過手機將手機號碼、車牌號碼以及電子簽名圖傳送至後台裝置500後，由資料處理模組520將這些資訊進行程式化並完成圖8a的數位憑證資料結構及圖11b數位簽章資料結構編碼的整個過程，都是在後台裝置500中完成，之後，只會將圖11b的數位簽章資料結構通過TCP/IP通信標準傳送至會員手機中的App儲存，以作為一個公開金鑰。之後，會員10從預約到充電再到付款的過程，就可以通過手機上的這個數位簽章來辨識身分管理。很明顯的，在會員完成註冊後，本發明只會使用數位簽章來做為身份驗證的依據，不再進行個人敏感資訊傳遞，可以降低個人敏感信息被竄改、盜用或否認等行為發生的機率，可以強化個資在於網路資料傳遞時的安全防護。

接著，當會員10完成註冊之後，註冊會員就可以通過手機App向後台裝置500聯繫時，例如：進行充電站預約時，就要將此數位簽章資料檔案以TCP/IP通信協定傳送至後台裝置500，資料處理模組520就會從記憶體模組530中，叫出會員手機識別字的數位憑證的資料結構檔，並擷取此數位憑證資料結構中的一維條碼進行Hash運算，當Hash運算的結果與會員提供的數位簽章中第一部分(PART1)Hash摘要一致時，就判斷此手機的車主是會員10。

當註冊會員通過手機App向充電介面(包括：充電樁240及換電櫃250)聯繫時，例如：準備進行充電時，就要將此數位簽章檔以TCP/IP通信協定傳送至充電介面的物聯網控制器，之後，物聯網控制器以MQTT通信協定將數位簽章資料傳送至後台裝置500，之後，資料處理模組520就會從記憶體模組530中，叫出車牌號數位憑證的資料結構檔，並擷取出車牌號數位憑證資料結構中的一維條碼進行Hash運算，當Hash運算的結果與會員提供的數位簽章中第二部分(PART2)Hash摘要一致時，就判斷出車牌號正確。

當註冊會員通過手機App向充電介面聯繫時，例如：進行充電及付款時，就要將此數位簽章檔以TCP/IP通信協定傳送至充電介面的物聯網控制器，之後，物聯網控制器以MQTT通信協定將數位簽章資料傳送至後台裝置500，之後，資料處理模組520就會從記憶體模組530中，叫出車主電子簽名數位憑證的資料檔案，並擷取車主簽名號數位憑證資料結構中的一維條碼進行Hash運算，當Hash運算的結果與會員提供的數位簽章中第三部分(PART3)Hash摘要一致時，就判斷出車主電子簽名正確。

很明顯的，在本發明的註冊會員的身分管理中，是以車牌號所形成的數位憑證作為會員身分的辨識，更進一步，需要進行交易或是實際支付款項時，還需要提供以簽名圖檔所形成的數位憑證來進行身分的授權，特別要強調的是，這些進行身分辨識以及授權的過程中，相關模組都具有身份驗證(DID)的節點功能，故每一個模組都會使用區塊鏈之超級帳本技術結合物聯網通信架構的實施方式，將其所送出的交易資訊以副本方式分享至每一個模組，故可藉防止駭客在會員交易資訊傳遞過程進行竄改、盜用或否認等行為發生，可以確保會員的個資(包括數位憑證、數位簽章)與電子錢包交易時的資訊安全。

此外，若發生註冊會員的手機遺失、損壞或是更換時，就需要重新進行身分管理內容是包括：主張、證明、辨識及授權。特別要說明的是，在本發明所提供的重新進行身分管理內容中，雖然只有身分的主張(即手機號碼)更改或是更新，但對於會員10身分主張、證明、辨識及授權通過序列化的過程，就可以產生不同的數位憑證或是數位簽證。例如，在重新進行身分管理的過程中，即使車牌相同，甚至於假設電子簽名圖檔也相同時，由於要將二維圖檔的座標轉換為一維條碼的過程中，必須是由程式的亂碼產生器產生x軸的第一亂碼及y軸的第二亂碼，當亂碼不重複，就會使得起始座標點不同，使得降維成一維條碼資訊的數位資訊就不相同，因此，可以確保重新進行身分管理後的數位憑證會不相同。同樣的，重新簽名的電子圖檔在經過降維成一維條碼資訊的數位就不相同，因此，可以確保重新進行身分管理後的數位簽證也會不相同。

當會員10已經通過應用程式(App)完成註冊成為註冊會員後，就可以使用手機120來啟動運營平台並自動的進入預約的程式，而詳細的預約程式及充電程式將在後續的內容中詳細說明。此外，註冊會員也可以在任何時間通過手機App來向後台裝置500線上儲值，儲值後的金額資料處理模組520會以電子錢包格式與會員管理檔案整合並儲存在記憶體模組530中，使得電子錢包在完成充電後的扣款紀錄能夠被完整且安全的紀錄。

在完成上述圖8及圖9的通信架構後，充電站中所有模組運作狀態的資訊都是通過EMS模組260(即代理伺服裝置700)以MQTT通信協定傳遞至後台裝置500中的資料處理模組520及記憶體模組530中，而已經完成註冊的會員10，則可以通過手機以TCP/IP通信協定登錄後台裝置500後，就可以再經過手機上的數位簽章進行身分的授權，用以進行充電預約、完成充電以及付費的過程。其詳細的流程，將會配合後續的圖示來說明。

接下來，本發明將依序說明運營平台的各種運營流程，其中，在說明每一個運營流程的前提是後台裝置500已經完成圖1至圖9中的通信架構。因此，在本發明後續的說明中，會說明每一步驟要進行的內容，也會說明是由哪個設備、裝置或是模組來執行此步驟的內容，對於步驟中使用到的技術特徵僅做必要的說明，而每一技術特徵都已詳細記載於前述說明中，不再重複贅述，合先說明。

接著請參考圖12，是本發明的會員註冊及使用充電站進行充電的運營流程圖。首先，如步驟1210所示，車主可以通過電動車110或是手機120聯網來下載充電平台應用程式(App)。

接著，如步驟1220所示，在完成下載程式並載入電動車110或是手機120並執行後，就可以通過App介面向後台裝置500進行註冊用以完成身分管理的程式，其中，註冊內容必須包括：會員的智慧型通信裝置號碼、車牌號及電子簽名。由於，本發明的會員10的身分管理內容是包括：身分主張是會員10所使用的智慧型通信裝置號碼，例如：手機號碼或是具有用戶身分卡(SIM)的通信裝置。而身分證明是以會員的車牌為目標，特別的是，會員10可以綁定一個或是多個車牌。以及，身分授權是會員10的電子簽名圖檔。

接著，如步驟1230所示，後台裝置500在收到會員10經過電動車110或是手機120傳遞的身分管理內容後，由資料處理模組520對會員手機號、車牌號或是電子簽名圖檔進行轉換成512x512格的座標，其中，是將手機號及車牌號先轉換成QR-Code之後，再轉換成512x512格的座標；或是將電子簽名圖檔化之後，再對圖檔轉換成512x512格的座標，詳細轉換過程請參考圖10a的說明。

再接著，如步驟1240所示，後台裝置500中的資料處理模組520是對會員手機號及車牌號的QR-Code進行程式化的降維處理，以及對電子簽名圖檔進行程式化的降維處理，以分別取得一個一維條碼。例如：從512x512格的一個座標點開始取16個位的一維條碼資訊或是取32個位的一維條碼資訊或是取64個位的一維條碼資訊。其中，經過降維處理的會員手機號及車牌號QR-Code，可以分別得到一個數位憑證，如圖10b右側所示。而經過降為處理的電子簽名圖檔，所得到一個數位憑證，圖10b左側所示。要說明的是，對於將會員手機號、車牌及電子簽名圖檔的序列化過程，因與前述相同，則不再重複贅述。

接著，如步驟1250所示，資料處理模組520將會員手機號碼一維條碼、車牌號一維條碼或是電子簽名圖一維條碼的資訊轉換成一種資料結構格式，以作為數位憑證，其中，本實施例中的數位憑證的資料結構，如圖11a所示，之後，先將會員手機號及車牌號這兩個或是第三個的電子簽名數位憑證資料結構儲存至記憶體模組530中，並且通過TCP/IP通信協議將身分管理中的憑證加密及編碼後，傳送至電動車110或是手機120儲存，並當電動車110或是手機120完成儲存後，就完成了註冊而成為註冊會員。

接著，如步驟1260所示，完成註冊的會員10在充電介面處提出充電要求，通過電動車110或是手機120將數位憑證輸入至充電介面中的物聯網控制器270，其中，經物聯網控制器270會將數位憑證以TCP/IP通信協定傳送至後台裝置500進行比對。在本發明的較佳實施例中，步驟1210至步驟1260可以選擇以TCP/IP通信協議應用層中的http通信協議。

接著，如步驟1270所示，當後台裝置500比對會員10提供的數位憑證是與儲存在模組中的數位憑證相同時，則判斷正確，例如：當收到的手機號碼數位憑證與記憶體模組中的手機號碼數位憑證進行比對，當比對正確後，即允許進行充電。此時，充電介面就會對電動車進行充電程式，如步驟1290所示。若判斷數位憑證為不正確時，則充電介面就會發出拒絕充電資訊，如步驟1292所示。

為了提高資訊安全的協定，可以進一步的要求會員10需要提供數位簽證來授權身分，如步驟1280所示，完成註冊的會員10在充電介面處，通過手機將車牌號數位憑證或是電子簽名數位憑證輸入至充電介面中的物聯網控制器270，其中，經物聯網控制器270會將數位憑證以TCP/IP通信協定傳送至後台裝置500進行比對。當後台裝置500比對會員10提供的數位憑證是與儲存在模組中的數位簽證相同時，則判斷正確，此時，充電介面就會對電動車進行充電程式，如步驟1290所示。若判斷數位簽證為不正確時，則充電介面就會發出拒絕充電資訊，如步驟1292所示。

此外，通過步驟1280還有一個重要的目的，是確證充電模組控制器2450與充電者(即會員10或是電動車110)的智慧合約(Smart Contract)的記載程式，其中，此一Smart Contract的內容記載了實際充電至電動車110的電功率度數以及交易金額，用以作為綠色標章的認證證據。

最後，如步驟1295所示，當充電樁模組240完成充電程式後，充電站能將綠色標章的認證資料，選擇以TCP/IP通信協議應用層中的MQTT通信協議傳送至超級帳本中的每一個身份驗證(DID)節點、綠色標章的第三方認證單位600與後台裝置500中。其中，綠色標章的認證資料包括：發電機(DID1)輸出的功率、儲能電池組(DID2)的輸出的功率、每一個充電樁模組(DID4)的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等全程電功率鏈資訊。而在本發明的較佳實施例中，步驟1295可以選擇以TCP/IP通信協議應用層中的MQTT通信協議傳送綠色標章的認證資料，如圖8或試圖9所示。

此外，在上述流程中，當充電樁模組240形成超級帳本中的具有身份驗證(DID)的節點後，故每一個充電樁所送出的操作狀態都會以副本方式分享至每一個也具有身份驗證(DID)的節點模組，可以確保充電站200中的每一個模組的操作狀態及電功率等資訊不會被竄改、盜用或否認等，可以有效的紀錄會員10的充電資訊進而確保會員10的個資、第三方認證單位600認證綠色標章與使用電子錢包進行交易時的資訊安全。

因為本發明的在會員10註冊時就允許綁定多部電動車110，因此就會取得相應不同車派出的多個不同的數位憑證。很明顯的，本發明的運營平台，適合各種具有車隊運營的企業、單位或是法人(以下簡稱車隊運營單位)，只要統一經過註冊後，車隊運營單位具擁有每一個車牌獨有的數位憑證以及每一個員工的數字簽證。當任何員工使用特定車號的電動車時，車隊運營單位就將特定車號的數位憑證及員工的數字簽證傳遞至員工的手機中。根據前述實施例的說明，當員工使用數位憑證及數字簽證完成充電的過程及記錄，都可以通過身份驗證(DID)的節點以區塊鏈技術來將充電資訊複製或是分享至每一個具有身份驗證節點的模組中。故本發明的運營平台能夠讓車隊運營單位很安全也很完整的進行運營管理，提高車隊運營單位及員工的使用經驗值。

接下來，請參考圖13，是本發明的會員在充電站進行充電的流程圖。首先，如步驟1310所示，註冊會員10通過電動車110或是手機120已經完成特定充電站200的預約後，可以經由導航系統，將電動車開往充電站。其中，註冊會員10已取得數位憑證或是進一步取得數位憑證資的料結構編碼，或是更進一步取得數位簽章。由於取得數位憑證的過程與圖10a及圖10b相同，同時，在取得數位憑證資料結構編碼的過程與圖11a相同，以及取得數位簽章的過程與圖11b相同，故不在贅述。此外，在註冊會員10已經完成充電站200的預約後，後台裝置500就會將註冊會員10的車牌號以TCP/IP通信標準傳送至充電站控制中心(例如：EMS模組260)中。

接著，如步驟1320所示，註冊會員10及電動車到達充電站。

接著，如步驟1330所示，準備進行充電。是當充電站的閘門打開後，充電站控制中心會以TCP/IP的通信協定傳送充電介面位置至會員手機以及傳送車牌資訊至充電介面的物聯網控制器。其中，為了能有效管理充電樁位，充電樁位元上可以進一步的配置有地樁，並且是通過充電樁來管理地樁的升降。例如，當註冊會員10及電動車到達充電樁附近時，可以通過手機上的身分管理來通知充電樁降下地樁。接著，註冊會員10將電動車停妥在充電介面前，準備進行充電。在本發明的較佳實施例中，步驟1310至步驟1330可以選擇以TCP/IP通信協議應用層中的http通信協議。

接著，如步驟1340所示，當註冊會員10將電動車停妥在充電介面前，註冊會員10以手機將數位簽章輸入充電介面，再由充電介面以MQTT通信協定先將數位簽章傳送至完成配對的代理伺服裝置(例如：EMS模組260)後，由代理伺服裝置以MQTT通信協定傳送至台裝置500。之後，由後台裝置500中的資料處理模組520進行判斷輸入的數位簽章中的第二部分Hash摘要是否正確。在此步驟完成後，就能彰顯本發明使用身分管理的方式，可以達到資訊安全提升的要求。例如：因為身分管理內容包括車牌號及由車牌號程的數位憑證。第一層的安全防護是，閘門對預約車牌的辨識，第二層安全防護是由數位憑證來確保準備充電的電動車車牌就是會員預約的電動車。

接著，如步驟1350所示，當後台裝置500判斷數位簽章中的第二部分Hash摘要正確後，後台裝置500會將判斷結果以MQTT通信協定傳送回代理伺服裝置，之後，代理伺服裝置再以MQTT通信協定傳送至充電介面後，則充電介面才能允許會員將配置在充電樁上的充電槍取出。例如：會將辨識正確的資訊顯示在充電樁的螢幕，並由充電樁顯示充電槍可以取出的資訊，或是由換電櫃250的螢幕顯示哪一個電池模組可以取出的資訊。

接著，如步驟1360所示，當註冊會員10將配置在充電樁上的充電槍取出，並將充電槍連接至電動車的充電座，準備進行充電。這樣的程式，可以避免發生充電槍與電動初完成連接後，因為數位簽章沒有通過辨識而無法充電時，對於會員、充電設備、電動車及運營時間都有不利的影響。

再接著，如步驟1370所示，為了提高資訊安全的協定，本發明可以進一步的要求會員10需要提供電子簽名的數位憑證來授權身分。當註冊會員10將充電槍連接至電動車的充電座，準備進行充電時，充電樁會發出資訊，請會員再輸入電子簽名的數位憑證。當註冊會員10以手機將數位簽章輸入充電樁，再由充電樁以MQTT通信協議先將數位簽章傳送至完成配對的代理伺服裝置(例如：EMS模組260)後，由代理伺服裝置以MQTT通信協定傳送至台裝置500。之後，由後台裝置500中的資料處理模組520進行判斷輸入的數位簽章中的第三部分Hash摘要是否正確。接著，當後台裝置500比對註冊會員10提供的數位簽章中的第三部分Hash摘要是與儲存在模組中的數位簽章相同時，則判斷正確，此時，充電介面就會對電動車進行充電程式，如步驟1390所示。若判斷數位簽章中的第三部分Hash摘要為不正確時，則充電介面就會發出終止充電程式的資訊，如步驟1380所示。

如步驟1385所示，為了提高資訊安全的協定，驟1370可以進一步的要求會員10需要提供電子簽名的數位憑證來授權身分，完成註冊的會員10在充電介面處，通過手機將車牌號數位憑證或是電子簽名數位憑證輸入至充電介面中的物聯網控制器270，其中，經物聯網控制器270會將數位憑證以TCP/IP通信協定傳送至後台裝置500進行比對。當後台裝置500比對會員10提供的數位憑證是與儲存在模組中的數位簽證相同時，則判斷正確，此時，充電介面就會對電動車進行充電程式，如步驟1390所示。若判斷數位簽證為不正確時，則充電介面就會發出拒絕充電資訊，如步驟1380所示。

在此步驟完成後，更進一步增加管理金流過程中的檢查與授權扣款，提高運營管理的授權機制。例如：當本發明的後台裝置500確認數位簽章中的第三部分Hash摘要正確後，此時才有權利檢查會員的電子錢包內的金額是否足夠支付充電費用，若電子錢包的餘額足夠時，會在充電樁的顯示幕幕上顯示電子錢包的金額，而這個過程可以避免充完電後無法完成扣款的問題。

此外，通過步驟1385還有一個重要的目的，是確證充電模組控制器2450與充電者(即會員10或是電動車110)的智慧合約(Smart Contract)的記載程式，其中，此一Smart Contract的內容記載了實際充電至電動車110的電功率度數以及交易金額，用以作為綠色標章的認證證據。

最後，如步驟1395所示，當充電樁模組240完成充電程式後，充電站能將綠色標章的認證資料，選擇以TCP/IP通信協議應用層中的MQTT通信協議傳送至傳送至超級帳本中的每一個身份驗證(DID)節點、綠色標章的第三方認證單位600與後台裝置500中。其中，綠色標章的認證資料包括：發電機(DID1)輸出的功率、儲能電池組(DID2)的輸出的功率、每一個充電樁模組(DID4)的輸出的功率以及電動車完成充電後的帳單(即智慧合約)等全程電功率鏈資訊。而在本發明的較佳實施例中，步驟1295可以選擇以 TCP/IP通信協議應用層中的MQTT通信協議傳送綠色標章的認證資料，如圖8或試圖9所示。

很明顯的，在本發明圖13的實施例中，為了達到資訊安全提升的要求，從註冊會員10輸入數位憑章的程式至完成充電的整個過程(包括從步驟1360至步驟1390)，充電樁都會根據圖6及圖7所示的架構，當充電站內的模組都形成超級帳本中的具有身份驗證(DID)的節點後，故每一個模組所送出的操作狀態都會以副本方式分享至每一個模組，可以確保充電站200中的每一個模組操作狀態不會被竄改、盜用或否認等，可以有效的確保充電站200的資訊安全。

最後，在本發明圖13的實施例中，當需要進行交易或是實際支付款項時，通過步驟1280與步驟1385是需要的手段，用以提供以電子簽名圖檔所形成的數位憑證來進行身分的授權。特別要強調的是，這些進行身分辨識以及授權的過程中，相關模組都具有身份驗證(DID)的節點功能，故每一個模組所送出的交易資訊都會以副本方式分享至每一個模組，可藉防止駭客在會員交易資訊傳遞過程進行竄改、盜用或否認等行為發生，可以確保會員的個資(包括數位憑證、數位簽章)與電子錢包交易時的資訊安全。

要再一次強調，以上所述僅為本發明較佳的實施方式，並非用以限定本發明權利的範圍。同時以上的描述，對於相關技術領域中具有通常知識者應可明瞭並據以實施，因此其他未脫離本發明所揭露概念下所完成之等效改變或修飾，應均包含于本發明的專利要求範圍中。