佈署 IoT Edge 和霧運算技術以開發智慧建築服務
2021年2月19日 星期五
《3S MARKET》這篇報導把物聯網的架構與實作,描寫的非常詳細,雖然在建築的細節上描述不多,但報導中也提及這是個實際驗證,可適用在很多的場域。不知道,有多少人真正看得懂?當然,連這篇都看不懂的人,就別說他真正了解物聯網、Edge 與 Cloud。
事實上這篇報導的描述不難了解,真正物聯網與邊緣運算的挑戰,是在實作。實作真正面臨的,是這些數據處理、融合、分析上的完整度,還有 —— 找到實作的場景!
摘要
基於 SoC 架構的嵌入式系統的進步,使許多商業設備的開發變得足夠強大,足以運行操作系統和複雜的算法。這些設備整合了一組具有連通性、運算能力和成本降低的不同感測器。在這種情況下,物聯網(IoT)的潛力不斷增加,並帶來了其他發展可能性:「事物」現在可以增加數據源附近的運算量;因此,可以在本地系統上,佈署不同的物聯網服務。
這種範例稱為「邊緣運算」,它整合了物聯網技術和雲端運算系統。邊緣運算可以減少感測器與中央數據中心之間,所需的通信頻寬。此方法需要管理感測器、執行器、嵌入式設備,和可能不連續連接到網路的其他資源(例如智慧手機)。這種趨勢對於智慧建築設計非常有吸引力,在智慧建築設計中,必須整合不同的子系統(能源、氣候控制、安全性、舒適性、使用者服務、維護和營運成本)以開發智慧設施。在這項工作中,分析和提出了一種基於邊緣運算範例的智慧服務設計方法。
這種新穎的方法,克服了現有設計中與服務的互操作性,和可伸縮性有關的一些缺點。描述了基於嵌入式設備的實驗架構。能源管理、安全系統、氣候控制和資訊服務,是實施新智慧設施的子系統。
1. 簡介
建築自動化系統使用開放式通信標準和介面,可以整合多種不同的建築控制規則,例如供暖、通風、空調、照明和百葉窗、安全功能和設備。但是,現有建築物通常不具有這些系統。
通常,每種安裝類型都提供特定的服務:供暖通風和空調(HVAC)控制氣候服務,攝影機和感測器提供安全服務等。僅當設計能源管理系統時,不同的子系統相關,但僅透過以下方式,連接建築物的能源管理系統。能源管理服務,集中在專用軟體中。
對於使用者和維護技術人員來說,提供不同服務的不同製造商,發現很難整合新的服務和功能。自動化建築將用於控制和數據採集的軟體,與工業協議和介面整合在一起。此外,將新服務整合到這種解決方案中並不容易,這取決於已安裝軟體的開發。
這些工業發展還為能源管理,提供了雲端連接解決方案和智慧服務。這些服務,也在集中式電腦系統中開發。數據被傳輸到這些系統或雲端進行分析。本文提出使用佈署在物聯網(IoT)技術中的邊緣和霧運算範例,主要有兩個目的:
A. 在自動化和非自動化建築物中,促進新的智慧和可互操作服務的整合(整合)。
B. 允許在建築物的所有子系統之間,分配智慧服務(互操作性)。
透過該建議,可以促進建築物子系統之間的關係。它還促進創建新的智慧服務(例如,新的分佈式智慧控制算法;使用電源管理捕獲的數據,來檢測人類活動;捕獲設備連接的模式辨識,運算可再生電力預測,在安全服務中使用電力數據等)。在這項工作中,我們設計了一個中間軟體的體系結構,該體系結構具有兩個主要層,這些層基於嵌入式設備、IoT 通信協議和硬體支援,來開發人工智慧算法(圖1)。
為了實現這一目標,我們在建築物的設施中添加了兩個概念等級:邊緣節點和霧節點。每個等級都有不同種類的設備和功能。我們佈署並實現了基於層的中間軟體的體系結構,以對模式進行實驗。
本文的組織結構如下:第 2 節回顧了智慧建築技術,建築物中的 IoT 佈署以及邊緣運算範例。第 3 節提出了一種在建築物(自動與否)中佈署邊緣和霧運算範例的方法。第 4 節介紹了進行的實驗。最後,第 5 節介紹了結論和未來的工作。
2. 相關工作
本節介紹與這項工作相關的主要研究領域。首先,我們在分析雲端運算層之後,回顧了基於邊緣運算範例的資源和服務供應。最後,我們研究了實現智慧建築的技術,並在最後的小節中,總結了先前研究的貢獻。
2.1. 邊緣運算資源和服務供應
最近,網路在兩端被標記為「邊緣」和「核心」,以查明處理發生的位置。邊緣端靠近數據源和使用者,核心端由雲端伺服器組成。透過這種方式,邊緣運算範例將運算推送到 IoT 網路的邊緣,以減少數據處理延遲,和發送到雲端的數據數量。基於雲端的後端,可以處理對時間不太敏感,或源設備本身不需要結果的處理請求(例如,物聯網網路狀態下的大數據分析)。
在邊緣運算資源供應方面,正在進行的 Horizon 2020 RECAP 項目,提出了一種整合的雲端 - 邊緣 - 霧端架構,目的在解決應用放置、基礎架構管理和容量供應。雲端/邊緣基礎架構監控功能豐富了應用,基礎架構和工作負載模型,這些模型又被回饋到優化系統中,該系統可以協調應用並持續配置基礎架構。
徐等人進行的研究。 提出了一種用於邊緣運算的實用感知資源分配方法,稱為 Zenith。借助 Zenith,服務提供商可以與邊緣基礎設施提供商,建立資源共享合同,從而允許延遲感知資源調配算法,以滿足其延遲需求的方式,來調度邊緣任務。
邊緣節點資源管理(簡稱 ENORM),是管理邊緣/霧節點資源的框架,可透過監控應用需求,來自動擴展邊緣節點。可以透過靜態優先等級分配,來確定特定應用的優先等級。供應和自動縮放機制,是基於線性搜索的相對簡單的實現。
當源本身是可行動的時,邊緣雲範例也是可行的。 Chen 等人研究了行動設備向邊緣節點(特別是在無線電接入網路邊緣)的智慧運算分流。在這項工作中,作者提供了任務卸載算法,將分佈式運算卸載決策表述,為多使用者運算卸載功能。在同一項工作中,Wang 等人研究了聯合協調卸載任務,到多個邊緣節點的問題,並提出在邊緣等級引入及准入控制,以及兩階段調度方法,與傳統的最近邊緣選擇方法相比,改進了卸載性能。
2.2. 雲端運算服務配置
就社會和行業採用資訊技術而言,雲端運算範例是最具創新性的策略之一。提供的優勢提高了效率,並降低了成本,同時提供了可透過 Internet,普遍存取訪問的按需 IT 資源和服務。
當前,雲端運算服務種類繁多,甚至如何提供,這是一個受到廣泛研究的主題,正在提出許多的方案。甚至有評論總結了雲端運算範例的相關研究。
本小節介紹了有關以下問題的先前工作,這些問題與本手稿的主題有關:(i)安全性; (ii)服務品質(QoS); (iii)提供邊緣服務。
(i)安全是雲端運算中一個具有挑戰性的問題。雲端服務位於應用環境之外,並且超出了防火牆的保護範圍,因此,需要附加的安全層。另外,邊緣和霧運算應用的行動性和異構性,使得難以定義單個過程。因此,需要一種分佈式安全策略。
此外,必須有一個標準化的環境,才能正確解決此問題,並指定霧運算和邊緣設備,如何相互協作。網路邊緣上的多個霧節點之間的敏感數據通信,需要資源受限的事物的輕量級解決方案。另一個與安全性相關的問題是數據位置。在雲端中運行數據分析是很常見的。因此,關於數據安全或隱私的公有雲與私有雲的爭論就出現了。
(ii)分配給雲端應用的資源,通常是根據合同規定的服務水準協議(SLA)所設置的。但是,實際上,由於偶爾執行大量事務,而導致分配的基礎結構飽和,可能會出現瓶頸。為了解決此問題,可以在資源可用時,動態擴展雲端基礎架構。當前,最具創新性的趨勢,目的在建構自動 SLA 合同合規系統。在 Faniyi 和 Bahsoon,以及 Singh 和 Chana 進行的研究中,可以找到與品質服務管理相關建議的詳盡綜述。考慮到這一點,提出了幾種策略來預測,應用的資源需求和 QoS 的要求。最近的工作試圖將安全性和 QoS 問題結合起來,以提供全面的性能指標。
(iii)最後,濫用雲端服務,是該領域的另一個問題。物聯網環境是霧和邊緣設備不斷加入或離開,動態的執行前後關聯。因此必須在網路邊緣提供彈性的服務。為此,在網路的可用設備之間,共享應用工作負載,可以為高階運算應用提供靈活性。提出了可靠的服務供應方法,來為系統提供更高的彈性,並提供靈活和優化的雲端服務。
在本主題中,將雲端框架和中間軟體技術,設置為與雲端層,以及具有不同介面操作系統,和體系結構的設備之間,進行通信的平台。
2.3. 物聯網在建築服務工程中
物聯網開發為在建築物上,開發數位服務提供了新資源。建築物中常見的物聯網應用,包括節能的過程環節、維護改進、雜務自動化和增強安全性。由於全球變暖,建築物的節能是一個重要的課題。
物聯網技術引入智慧建築,不僅可以減少本地溫室氣體排放,還可以將減少溫室效應擴大到更大的領域。目前,物聯網還被用於建築領域,以協助設施管理。物聯網使營運系統能夠提供更準確和更有用的資訊,從而改善營運,並為房客租戶提供最佳體驗。有基於物聯網的建議,這些建議顯示建築系統,如何與雲端進行通信,並分析所獲取的數據,以開發新的業務見解,從而能夠推動真正的增值和更高的績效。
實驗研究顯示,物聯網平台不僅可以改善,工業能源管理系統中實體的互連性,而且可以降低工業設施的能源成本。 FacilitiesNet 表示,建築物聯網(BIoT)正在推動我們獲取資訊,彼此互動和做出決策的方式發生重大轉變。BIoT 不僅與連接性或設備數量有關,而且還與交付實際和相關結果有關。當前,有很多基於物聯網的智慧家庭應用的例子。
然而,智慧設備或「物」,僅僅是連接到網路的設備或嵌入式系統。增值來自設計協調系統,和提供智慧服務,以提供實際收益的能力。這些特徵基本上,取決於對不同類型連接事物的異質性,及其互操作性的管理,並取決於數據處理提供的情報潛力。
Tolga 和 Esra 進行的研究得出的結論是,就智慧家庭系統中的軟體和硬體而言,物聯網技術尚未變得穩定。原因之一,有可能是物聯網技術仍處於發展階段。McEIhannon 所撰寫有關物聯網應用的邊緣雲和邊緣運算的未來,其評論得出了類似的結論。這篇評論提到概念和發展,目前還處於早期階段,從學術和行業的角度來看,許多挑戰都需要解決。
物聯網帶來了新的機會,但許多企業仍在尋求了解和分析,其將如何影響,並與現有的 IT 結構和管理策略整合。為此,必須創建專門的使用模式和技術,來彌合這一差距。
2.4. 發現
以下結論闡明了這項研究建議的新穎之處:
雲端運算作為「實用」的一般概念,非常適合智慧家庭應用的常規需求。但是,在某些情況下,將所有運算都移到雲端中,是不切實際的。
邊緣計算作為一種計算範例而出現,可以在物聯網設備生成的數據附近執行計算。這種範例可能有助於滿足最新應用的安全性和 QoS 的要求。
當前,控制子系統的高級建築設施,通常使用 Internet、IoT 協議和 Web 服務。專有系統是使用標準的 Internet 通信協議設計的,用於管制和監控。先前的工作顯示,基於無線感測器網路、Web 介面和工業控制模式,用於氣候控制、電源管理或安全性的控制系統,使用不同的監視和控制技術。監控應用分析,得自監控和數據採集系統中的這些子系統。對於不同的子系統,有不同的解決方案。考慮到上述情況,本工作中提出的模式,引入了以下新穎元素:
A. 介紹了一種分層架構(整合了邊緣和霧端等級),以及提供子系統之間互操作性,以及在建築物控制中開發智慧服務的方法,該方法使用了邊緣和霧端範例,這些範例將 IoT 協議整合在一起,並在本地 Intranet 中操作 AI 技術,讓雲端服務的通信層,完善了該層的架構。
B. 介紹了一種基於使用者為中心的方法,用於在互操作性需求下設計、驗證和改進新服務。
C. 該提案允許使用可以在已建的建築物中,實施的非專有硬體和軟體系統。
3. 計算模式設計
建築物中的設施子系統分為有照明、氣候、能源、安全、警報、電梯等。在自動化建築中,這些子系統由專門的控制技術控制和監控。在非自動化建築物中,不存在這些服務,並且子系統透過電子和電氣方式進行控制。在這兩種情況下,所有子系統都為建築營運,提供必要的服務。
從邏輯上講,每個子系統都在其場景中起作用,並且不能與其他子系統互操作。嵌入式電子控制器和連接的不同感測器,可以使每個子系統自動化。這些服務都是基於直接反應性控制規則。除了嵌入式控制系統和感測器之外,通信技術(基於 Internet 協議)和新的行動設備還為開發管制、監控和數據訪問服務,提供了新的可能性。
在智慧型動設備上開發,並連接到 Web 伺服器的人機介面和專用應用,是近年來已實現的服務的範例。每個子系統中的專家(氣候、安全性、電源等),都具有可以轉換為專家規則的知識。這些規則被轉換為用於管理、維護、控制、優化和其他活動的控制算法。這些規則是可以,在可程式設備上編程和實現的。但是,它們是靜態的,不會在出現新情況時發生變化,並且不能互操作,也無法適應每個安裝的特性。
例如,氣候或安全專家決定,如何使用標準啟動條件,來配置每個子系統。每個控制規則僅在一個子系統(此範例中為氣候或安全性)中工作,因此,這些子系統之間沒有互操作性。考慮到這種情況,提出的模式有助於並允許,基於不同子系統的互操作性,來整合新的數位服務,並將人工智慧(AI)技術的新服務,引入當前設施。
例如,諸如電梯控制的設施,可以用於安全服務或建築能源管理服務。氣候控制設施,可以與安全子系統整合在一起。整合到模式中的天氣預報軟體系統,可以由能源管理服務,或建築物空調服務使用。
目的是讓每個子系統中的專家,參與設計整合服務,並將所有子系統轉換為可互操作的系統。該模式會開發自動規則,並允許在考慮安裝行為本身的情況下進行決策。該模式基於一個過程,該過程包括四個開發階段(圖2)和分為不同級別的硬體 - 軟體體系結構(圖3)。該體系結構的主要等級,是邊緣等級和霧等級。這兩個層次介紹了在建築物中,應用物聯網技術的新穎性。下面介紹了模式的各個階段(分析、設計、實施和啟動)。
.分析:在此階段確定了不同的專家使用者(氣候、安全、電力、水、能源、管理人員,以及資訊和通信技術(ICT)技術人員)。諮詢專家使用者,以指定需要控制的主要過程。資訊通信技術專家作為整合環節,參與了這一過程。第一種方法產生了設計控制規則,和潛在服務所需的事物(對象)。在此階段,使用以使用者為中心的方法,並捕獲子系統的需求。
.設計:我們提出了一個三層架構(邊緣、霧端和雲端),如圖 3 所示。
.實施和數據分析:在此階段中已安裝和整合了子系統。服務基於每個子系統中的規則,分析事物(對象)生成的數據,以設計基於機器學習的服務。
.啟動:最初,在每個子系統的監督下制訂專家規則。然後,使用回饋過程安裝規則。最後,透過人工智慧技術,可以推斷出自動的和經過調整的規則。
3.1. 分析與設計
專家使用者對此過程,進行不同的審查。以使用者為中心的技術,用於設計整合流程。目的是獲得所需的所有事物(對象),它們之間的關係,以及潛在的服務。一旦指定了事物(對象)和服務,就必須關聯通信協議和控制技術。選擇了物聯網協議和嵌入式控制器;提出了人機介面;指定了邊緣層和霧層及其功能;分析專家規則和智慧服務。最後,提出了維護和操作方法。所有這些任務在專家技術人員,和資訊技術專家之間共享。
結果是事物的定義,它們之間的關係,以及與邊緣和霧層的交互作用。該過程中代表了建築物的所有子系統,數據感測器、執行器、控制器、規則和過程經過設計,可以整合所有子系統。數據集、對象和設備,由物聯網概念表示。事物由具有狀態和配置數據的實體,和前後關聯組成。事物數據位於霧和邊緣節點中,儲存的不同配置中的關聯性。
事物以數據向量表示:[ID、類型、節點、前後關聯情境]。
– ID是辨識碼。
– 類型可以是感測器、執行器、變量、過程、設備、介面、數據儲存,或可以在 IoT 生態系統中寫入、處理、通信、儲存或讀取數據的任何對象。
– 節點指定建築物子系統、功能描述、層類型(邊緣、霧端、通信或雲端)、IoT 協議和時程存取訪問。
– 前後關聯表示在 IoT 生態系統中,用於發布或讀取數據的時間、日期、位置,與其他事物的關係、狀態和訪問頻率。
表 1 是由事物([ID、類型、節點])。所有事物都可以訪問配置文件(CF),以了解如何使用可用數據,以及如何使用適當的訪問權限配置新數據。前後關聯數據位於內建記憶體,或是靜態儲存。使用定義的事物,設計不同的控制規則。這些控制規則是分佈在連接到網路的不同嵌入式系統中,控制過程的一部分。事物表示佈署在安裝的不同子系統中,所有的可用資源。在此等級上,設計師對所有事物進行分析、指定和關聯。基本控制算法是使用此資訊實現的。配置關聯性允許層和設備之間,所有事物的互操作性。
在此階段的另一級設計,必須提出物聯網管理中,使用的節點要求和規範。設計的流程和服務,將在邊緣或模糊節點中實施。必須指定每個節點,以確定其內部功能、通信及其服務。在獲取數據的地方,開發了智慧和處理能力。邊緣和霧層的節點,位於數據感測器、執行器和控制器附近。本文提出的方法,使用具有兩個功能的兩層(邊緣和霧端)。每一層都可以佈署互連節點的網路,以促進互操作性。
邊緣和霧層的功能是:
邊緣層功能:在連接感測器/執行器的嵌入式設備上,開發的控制軟體。某些 AI 算法可以安裝在邊緣節點上。中央處理器(CPU)和計算資源有限。安裝了通信介面,以允許在本地網路中進行整合。
霧層功能:局域網級別的通信、AI 範例、儲存、配置關聯性和監控活動。霧節點透過處理、通信和儲存,來處理 IoT 的Gateway、伺服器設備,或其他設備中的數據。在此等級實施本地、全球的整合服務。利用這些節點的硬體、軟體和通信功能,開發了基於機器學習範例的算法。霧層設備還可以在很少單位的設施或服務中,執行邊緣節點功能。
透過這兩個等級,可以優化建築設施,以獲得不同子系統之間的整合和互操作性。
表 1 顯示了每件事與關聯性配置,和節點規範的關係。節點標識其所屬的子系統(控制、能源、氣候等),層(霧端、邊緣、通信和雲端)及其執行的功能。
3.2. 架構設計
在分析和設計階段,獲得對象(事物)及其關係。規範和要求用於實現每個層。實施取決於提供所需功能的設計,和現有技術(硬體、通信和軟體)。在此階段,開發了一種適合現有設施的體系結構。物聯網協議提供互操作性,而 AI 範例則提供了適應性和優化性。邊緣運算節點用於控制設備,霧運算節點安裝在本地網路節點上。這些等級為配置、安裝和運行新流程,提供了強大的資源。
物聯網協議,傳達所有子系統數據。每個子系統由對象/事物(虛擬等級)組成,安裝為可連接的感測器/執行器/控制器設備(硬體等級)。
物聯網通信中,針對建築場景建立的要求是:標準協議、低功耗、易於存取訪問和維護、支援整合新模組,非專有硬體或軟體,以及低成本設備。
MQTT 協議,是目的在用於提供整合和互操作性資源,異構通信場景的主要物聯網協議之一。該協議被提議作為感測器、執行器、控制器、通信設備,和子系統之間的通信範例。
MQTT 協議的一些主要功能,在不同的著作中有所顯示,這使其特別適合於這項研究。他們之中有一些是:
.它是針對資源受限的場景開發的發布 - 訂閱消息協議。
.它具有低頻寬要求。
.這是一個非常節能的協議。
.編程資源非常簡單,使其特別適合於嵌入式設備。
.具有三個 QoS 等級,它提供了可靠和安全的通信。
MQTT 開發了無所不在的網路,該網路支持 n-m 節點通信模式。任何節點都可以查詢其他節點,並對其進行查詢。在這些情況下,任何節點都可以充當基地台的角色,能夠將其資訊傳輸到遠端處理位置。無處不在的感測器網路(USN)中的節點,可以處理本地數據。如果使用 Gateway,則它們具有全局可訪問性;他們可以提供擴展服務。
節點(邊緣或霧),可以具有本地和全局存取訪問權限。這些設施具有不同的可能性和益處。本地數據處理,對於基本過程控制是必需的,而全局處理則可用於模式檢測和資訊生成。從這個意義上講,擬議的平台使用了組合功能:連接到 IoT 雲端服務,本地網路區域上不同的 USN。在這種情況下,運算層(邊緣或模糊等級)將用作控制流程和雲端服務之間的介面。該層可以在與雲端進行通信之前,進行處理數據。
實現邊緣和霧端運算節點需要執行三個操作:
.連接和通信服務:所有設備必須在同一網路中,並且可以互操作。所有感測器和執行器都可用於開發服務。此活動的一個示例,是在 Internet 上遠端讀取建築物的電源參數、環境條件和開放的天氣預報數據。此活動中應實現其他功能,例如連接的安全性、可靠性和互操作性。
.嵌入式設備(邊緣運算層)中的控制算法和數據處理:在此活動中,這些設備中實現的基本控制規則和數據分析服務,可以開發新功能。此階段可以應用於數據過濾、運算氣候數據或分析功耗、直接反應控製,或使用模式辨識技術檢測事件。
.Gateway 節點(霧運算層)上的高階服務:此等級使用和管理 AI 範例,和 IoT 通信協議。霧運算節點對數據執行智慧分析,對其進行儲存,過濾並將其傳遞到不同等級,以糾正較低級別的新控制措施,或者生成雲端中服務感興趣的資訊。此階段的應用示例,包括分析新模式、預測用水量,或功耗、智慧檢測和其他預測服務。
3.3. 測試與回饋
在測試階段使用標準方法,邊緣和霧層提供不同的功能。提出了針對不同子系統的機器學習模式,並且可以將其安裝在邊緣或霧節點上。必須執行以下操作,來測試機器學習應用:
A. 定義和捕獲數據集:必須辨識、捕獲和儲存主要變量。在不同的建築子系統中,過程數據集是由連接到邊緣層的感測器捕獲的數據。使用通信協議監控和儲存數據集。一個案例是電表,該電表在配電盤中連接到嵌入式設備(邊緣節點),該嵌入式設備傳送電力數據,以在霧節點設備中儲存和處理。
B. 訓練數據集和形式辨識模式。先前數據集的一個子集,用於訓練不同的模式。評估針對從未用於訓練的數據測試模式,此過程的結果已由專家使用者驗證。目的是獲得一組代表性的結果,以了解模式在現實世界中的表現。
C. 實際場景中的驗證:必須在邊緣和霧節點上,實施新的服務和控制算法。這些模式具有用於分析數據,實施特定模式,並使用結果開發最佳參數的算法。在此階段,可以修改或進行改善模式。
D. 用統計術語和模式演變,得出測試結果:基於 AI 算法的模式而將產生近似值,而不是精確的結果。分析應用結果以確定置信度,並允許模式演化。該活動支持開發新的 AI 服務,或對已實現的算法進行修改。有監督的自動更改,是維護和改進系統的過程。此階段的過程,包括所有模式層。
建議對使用邊緣和霧,任何的安裝進行這些活動。如前所述,該模式既可以安裝在既有舊的建築物中,也可以安裝在新建築物中。對於新建築設計,基於建議模式的安裝更易於整合。此外,可以提供的服務的潛力,也使其對於既有建築物具有吸引力。
4.在建築子系統中,實施智慧服務
該模式在預先存在的住宅建築物上,進行了測試。設計和實施電源管理、管制和監控服務。物聯網協議(MQTT 和 HTTP)和 ML 範例,用於建議的層體系結構。基於 KNN 的機器學習方法,和樹決策算法用於管理功耗(家用電器),和可再生能源發電(風能和太陽能)。使用房屋中的霧節點,在雲端平台上實現監控和統計數據。該節點連接到控制可再生,和家用電器子系統的不同邊緣節點。
在圖 6 中,邊緣節點,整合在先前安裝的可再生子系統中。透過邊緣層上的這種新設備、電源管理、安全控制和操作流程得以整合,並且可以與其他子系統互操作。可以設計新的智慧服務。邊緣節點將數據傳輸到霧節點 Gateway,該 Gateway 管理功耗和發電,並控製家用電器。該節點中的輸入,是可再生能源發電的數據。輸出控件是 ON-OFF 開關,用於優化發電、安全性和操作。
4.1. 分析與設計
分析了住宅建築,以設計電源管理,安全和控制服務。 在第一種方法中,所需的主要事物(對象),它們之間的關係和不同的服務,如表 2 所示。
4.2. 執行
分析房屋中的建築子系統,以整合這個執行模式層:邊緣控制、霧服務,與雲端的通信和雲端服務。 選擇了本實驗工作中使用的感測器、執行器和控制過程(事物)。 表 3 列出了使用的嵌入式設備。
家庭服務中的控制過程,需要反應時間和互操作性。人機介面、數據存取訪問和分析服務,是本地和雲端運算上的服務。上面提到的兩個需求,都使用不同的協議處理:控制/通信上的 MQTT,和雲端服務上的 HTTP(RESTful API)是用於整合,並使所有子系統互操作的 IoT 協議。在提出的該層模式中,還使用 MQTT 協議、控制、數據處理,以及使用 RESTful 協議,到雲端的數據通信,來開發機器對機器(M2M)應用。
MQTT 使用開放的消息協議,該協議可以將遙測樣式的數據(即在遠端位置收集的測量結果),以消息的形式,從設備和感測器,沿著不可靠或受約束的網路傳輸,到伺服器(BROKER)。消息是簡單、緊湊的二進制數據包,有效載荷(壓縮的標頭,比超連結傳輸協議(HTTP)少得多的詳細資訊),並且非常適合推送簡單的消息傳遞方案,例如溫度更新或移動通知。例如,消息也可以很好地用於,將受約束的或更小的設備,和感測器連接到 Web 服務。
MQTT 通信協議,使所有對象可以互操作。透過此協議實現的發布者和訂閱者模式,可以互連所有設備和事物。該通信層由安裝在霧節點上的代理設備管理。不同的發布者和訂閱者,在不同的節點上實現。安裝了一個 Gateway 設備(霧節點)和兩個嵌入式控制器(邊緣節點),來控製家用電器和電源管理。事物和流程佈署在所有節點上。
邊緣節點控制子系統,霧節點根據決策樹,以及專家定義的規則,實現 AI 範例。霧設備將數據傳輸到雲端平台,以開發儀表板螢幕,來監看子系統的狀態。
可以開發新的雲端平台服務:事件檢測、機器學習處理、統計分析等。專家使用者設計基本的控制算法。在學習和訓練過程之後,將根據專家系統的結果,對這些算法進行調整和修改。在這項工作中,目標是在不損失生產力的情況下優化資源(控制和能源)。在邊緣或霧節點中,執行不同的控製過程;分類過程和決策樹在霧節點中實現。算法以 Python 語言實現。此語言的開源庫用於不同的應用。
4.3. 佈署與測試
對於現有建築物,邊緣節點交錯插入已安裝的控制器、配電板,以及感測器和執行器中。如果在分析階段指定了新的東西(電錶、氣候和控制器),則會安裝一些新的感測器/執行器。這項工作中佈署的邊緣節點具有以下優點:
.請勿干擾先前的安裝操作。
.他們使用新的專家規則和自動規則,引入新控件。
.他們測試和重新配置,在分析、學習和測試驗證中,設計更新的專家規則。
圖 7. 佈署在配電盤中的節點。 使用 IoT 協議通信,在不同節點中開發數據捕獲、控制算法、數據分析、儲存和通信服務
在電力管理過程中,專家使用者根據電力消耗、發電量、消耗負荷曲線、氣候數據和氣候預測數據,對具有選定流程的時間表,進行可程式處理。邊緣節點捕獲數據,並將其發送到霧節點。
霧節點處理室內和室外環境的日記數據,以及天氣狀況。霧節點還可以捕獲其他感測器數據。對房屋中的這些數據消耗和生成方式,進行檢測和分類。消費和發電結果,作為數據添加,以便與儲存的數據一起進行分析。可以使用機器學習方法開發,作為家用電器或人類活動檢測的智慧服務(圖8)。
4.3.1. 機器學習:數據捕獲過程(邊緣節點)和家用電器分類(霧節點)
連接在主配電盤中的電表,用於捕獲數據,並使用標準的 K 近似值,最近鄰(KNN)分類算法,來開發形式辨識模式。 KNN 是機器學習系統中最常見的方法之一。電表捕獲電流;如果連接了新的家用電器,則電流數據會更改。不同的家用電器具有不同的變化等級。
用於辨識家用電器的不同模式的主要變量,是連接時的電流水準差異。數據捕獲過程流程圖(圖9),顯示了在邊緣節點中實現的算法,以捕獲預處理並傳遞電力數據。
在此過程中,監督階段使用訓練數據集。接下來,真實場景中的驗證,將測試分類模式。家用分類設備將用於不同的服務:人類活動的辨識、負載控制、可再生能源管理、空調、安全性等。在訓練階段,已捕獲了不同的家用電器開機,以獲得一組形式。每個家庭都有一個矩心向量,將用於分類過程中的檢測。如上面所示的算法所示,分類器處理將產生連接時的電流數據作為輸入。KNN 分類過程流程圖(圖10)描述了 KNN 方法,它在霧節點中實現。
4.3.2. 可再生電源管理。控制電力自耗的決策樹
每個建築物都有不同的需求曲線,以及在接入電網方面的特定情況。為此,整合和可互操作的設施,可以實施適用於每種情況的不同解決方案,從而提供對太陽風資源的最佳管理,優化電源效率,簡化管理流程,並實現最高的成本節省。當可再生能源超過消耗的能源時,在使用 AC 耦合到電網的設施中,會出現問題。
在實驗工作中,太陽能在一天的中央時段的能量,大於所消耗的能量(圖11)。但是,在分析了消耗曲線之後,可以在這段時間內連接負載,以避免注入電網。可以透過設計一種算法,來滿足這一要求,該算法可以預測,何時發生此事件,以自動連接不同的負載。利用所有感測器和執行器的整合,和互操作通信,已經開發了在不同節點中,所實現的算法(圖12)。
13. 在電源管理子系統上開發的決策樹。 它由專業使用者設計,並整合在邊緣節點上。該決策樹的目的,在優化可再生能源的使用。
4.3.3. 基於 Edge 和 Fog 節點的 Control Home
圖 14 顯示了安裝在住宅房間中的邊緣節點。 該節點可以控制四個設備(設備),並捕獲感測器數據(功耗、發電量、溫度、濕度等)。該設備可以使用 MQTT 協議進行通信。該協議允許設備之間,進行其他類型的通信:智慧手機、新邊緣節點等。圖 7 和圖 14 顯示了可以在其他建築物中,佈署的標準實現。在所有系統中,都有配電板,這些配電盤佈署了霧節點和邊緣節點,如圖所示。
4.3.4. 使用物聯網協議的雲端服務
雲端服務可以監控,透過霧節點或人機介面(HMI)訪問的數據。 IoT 協議(MQTT)從任何已連接 Internet 的設備推送數據。事件檢測、儲存統計分析等其他服務,完善了該資源的功能。提供類似服務的不同平台,顯示了商用物聯網技術的狀態:Amazon IoT、Microsoft Azure、Ubidots 和 Thingspeak,是提供 IoT 平台的公司一些案例。提供了資源以及客戶端,和 IoT 平台之間的應用程式介面(API)通信,以便可以使用它們。
用於設計儀表板監控和管制的 HMI 資源,是這些平台上的主要實用功能之一。霧節點使用雲端 API 傳達數據和資訊,可以實施其他控制服務。在這些雲端平台上,預先建構了用於監控數據的儀表板設計。使用 API 實用功能,霧節點中的過程處理,會將數據發送到每個儀表板。API 文件指定了在設備、IoT 平台和 Mobile-Alerts Cloud 之間,交換數據的結構,以及用於加速項目的代碼案例和形成資料庫。
圖 15 顯示了在 Ubidots 雲平台上,設計的儀表板。Ubidots是本實驗工作中使用的物聯網平台。該模式可以在實現這些協議的層,和平台中使用不同的標準協議。圖 16 顯示了在雲端平台中,IF 變量 THEN 動作的事件配置。大多數物聯網平台,都提供此功能。
5. 結論
為了設計物聯網系統,越來越多地提出邊緣霧模式。但是,每個範例都提供特定應用領域的解決方案。不同子系統之間的整合和互操作性,可以改善這種情況,並提供更好的服務。這項工作的主要目的,是透過提出一種基於邊緣層和霧層,兩層體系結構的運算模式,來解決這個問題。透過這兩層,可以基於使用邊緣或霧節點中,嵌入式的設備捕獲數據所產生的新型有用資訊,來設計和開發新服務。這些節點使用雲端平台和 IoT 協議(例如 MQTT)。
MQTT 是作為不同層(霧 – 邊緣 – 雲)之間提出的通信協議,並進行實驗的。雲端平台用於開發儀表板的面板資訊和 Internet 上的新服務,例如控制、儲存和通信事件。該平台可用於透過 API,交付不同的服務。
該模式可以在現有建築物和新建築物中,開發這些服務。在這種情況下,要求每個子系統中的專家和專業人員,參與新服務的設計。
為了測試該模式的功能,並顯示如何在實際設施中,實現該模式,在住宅中進行了一項實驗性工作。在此霧和邊緣節點前後關聯中,描述了實現的幾個範例。開發了模式辨識和決策樹方法,以展示人工智慧在設計 IoT 解決方案中的潛力。已安裝服務的結果顯示,邊緣和霧節點佈署,產生了預期中整合和互操作性的好處。
提出的工作演示了,如何將邊緣和霧範例,整合到可以增強其優勢的新架構中,從而擴展了應用領域。該體系結構的主要科學貢獻,是整合、技術的互操作性,及其為開發 AI 服務提供的設施的範例。所有這些改進,都在已開發的實驗的不同示例中顯示。具體的優化和改進,將在以後的工作中進行。此外,使用機器學習平台,和 AI 範例的新控制規則,將確保可以創建和改進新的智慧服務。
附圖:圖1.自動建構子系統和資訊技術環境。
圖2.基於使用者為中心關係的模式。
圖3.通信架構。 每個等級都有不同的功能。 提出了兩個通信等級:IoT(使用消息隊列遙測傳輸(MQTT))和 Web(使用代表性狀態傳輸(REST)協議)。這些協議的層,涵蓋了已建立的整合和互操作性要求。
圖4. 在建築物的現有設施上實施的邊緣霧架構示例:邊緣節點是較低的層次,必須與安裝的設備進行新連接。互連所有子系統的霧節點,是透過整合連接到邊緣節點的新設備來實現的。邊緣和霧節點,可以佈署在所有建築物子系統中。
圖5. 住宅建築中的第一個實驗工作。
圖6. 整合在先前安裝的可再生子系統中,邊緣節點的示例。 該節點可以使用新算法控制 ON-OFF 開關,以管理發電過程,以及通信和監控電源數據。
表1.事物示例描述。寫入 ID、類型和節點數據,以配置 XML 文件。配置關聯性儲存在霧節點中。
表 2. 實驗工作中的分析和設計要求。
表 3. 實驗室內使用的嵌入式設備。
圖 7 顯示了分佈在配電板上的節點(邊緣和霧狀)。在此節點中,設計並安裝了功率計、ON-OFF 開關控件和 AI 服務。
圖 8. 佈署的智慧電源功能。在霧節點中實施的分類過程,可用於檢測電連接和人類活動。可以使用 IoT 通信實現其他服務
圖9. 邊緣節點中捕獲,並預處理的用電量數據;MQTT 協議用於通信數據。另外,其他節點可以使用捕獲的數據,來提供其他智慧服務,佈署了整合和互操作性。
圖10. 分類過程。處理捕獲的電數據以檢測家用電器連接。可以使用 IoT 協議整合,來設計其他智慧服務。
圖11. 該圖顯示了實驗工作中的消耗和生產數據。 在自儲存的電力自備設施中,沒有儲存並且沒有注入電網,所產生的能量必須即時使用,並且不得超過所消耗的能量。 能源經理必須預測此事件,並提前連接電荷。
圖 12. 用電自耗設施中的可再生電源管理。
圖 13 是在電源管理子系統中,開發的算法的示例。 可以在邊緣節點上安裝此過程。該節點獲取氣候數據預測,並預測系統是否可以在不儲存的情況下,使用可再生能源。
圖14. 佈署的邊緣節點。該節點可以使用新算法,控制 ON-OFF 開關,並可以在每個房間或建築物中,通信和監控感測器數據。
圖 15. 在雲平台上配置的儀表板。顯示了風力發電數據和預測風力。
圖 16. 在雲端平台上配置事件的儀表板:IF 事件 THEN 動作。 該服務顯示了,如何使用雲端訪問來控制設施。與霧節點的 Internet 通信,可以控制建築物中的不同子系統,並使用電子郵件,SMS 或其他 Internet 服務來通報事件。
資料來源:https://3smarket-info.blogspot.com/2021/02/iot-edge.html?m=1&fbclid=IwAR0uijX5WdNrfzmGjVsakFGaEsWivPgyH1zumxVr7fwvvgqtdFFTI6jJXS8
「實驗流程圖範例」的推薦目錄:
- 關於實驗流程圖範例 在 台灣物聯網實驗室 IOT Labs Facebook 的精選貼文
- 關於實驗流程圖範例 在 成吉思汗健身俱樂部 進化綜合格鬥中心 Facebook 的最讚貼文
- 關於實驗流程圖範例 在 Taipei Ethereum Meetup Facebook 的精選貼文
- 關於實驗流程圖範例 在 實驗流程圖範例2023-在Facebook/IG/Youtube上的焦點新聞和 ... 的評價
- 關於實驗流程圖範例 在 實驗流程圖範例2023-在Facebook/IG/Youtube上的焦點新聞和 ... 的評價
- 關於實驗流程圖範例 在 只會用Office 畫流程圖?許多人試用過這個後直呼回不去了 的評價
- 關於實驗流程圖範例 在 Word2016 a07 研究流程圖繪製 - YouTube 的評價
- 關於實驗流程圖範例 在 Word 基礎教學17:流程圖製作& SmartArt - YouTube 的評價
- 關於實驗流程圖範例 在 如何在word一鍵生成組織圖、流程圖?不用再一個個圖形線條 ... 的評價
- 關於實驗流程圖範例 在 實驗步驟流程圖 :: 全台大學開課課程資訊網 的評價
- 關於實驗流程圖範例 在 普通化學實驗報告拿高分小撇步之大助不會or懶得告訴你的事 的評價
實驗流程圖範例 在 成吉思汗健身俱樂部 進化綜合格鬥中心 Facebook 的最讚貼文
成吉思汗徵平面設計,歡迎您加入美編團隊,我們希望您具備以下能力:
1. 熟練操作photoshop及illustrator等繪圖軟體(含排版及影像合成等)。
2. 熟悉印刷流程及製作物發包事宜。
3. 色彩配置概念佳、具美感並有能實作出來的創作能力。
4. 能準確抓住文案、活動重點,用設計讓內容容易閱讀。
5. 重視團隊合作、擁有流暢表達能力。
6. 反覆檢查作品的耐心及細心。
7. 面對作品需要修改時,有實驗精神及抗壓能力。
8. 負責任的態度。
工作內容:
提升品牌形象,如:設計行銷平面素材(含banner 、DM、活動海報);商品包裝、場館牆面設計及相關印刷品製成(大圖輸出),以及各類視覺相關設計。
加分項目:
1. 對流行趨勢敏銳,持續更新創作靈感及概念。
2. 對攝影有興趣,有影像實作經驗或懂攝影相關技術(平面或動態都可以)。
3. 對健身產業有興趣(有愛才待得長久)。
待遇:
前2個月
底薪25,000/全勤3,000
第3個月起
底薪30,000/全勤5,000(獎金15,000)
福利制度:
1. 享每月乙次病假/生理假全勤
2. 享每月乙次員工大型聚餐
3. 滿半年正職員工享有育兒津貼3,000元
4. 於非上班時段可任意使用全省《成吉思汗健身俱樂部》訓練器材及課程
上班地點:成吉思汗林口美編總部
上班時間:15:00-23:00 (需配合公司活動出勤)
我們提供作品被看見的平台,也需要您的設計能力幫品牌加分,希望成為夥伴期間,雙方都能各有所獲!
準備好您的履歷及作品集,投遞後經過初步審核,將與合適者儘快聯絡,進行第二階段面試。
請將履歷寄至:aniooo6991@gmail.com(履歷請附作品範例或網站連結,若無提供作品,一概不回覆。)
註:此次徵才面試時,需進行上機考核。
實驗流程圖範例 在 Taipei Ethereum Meetup Facebook 的精選貼文
📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Trust Token API 是一個正在標準化的瀏覽器 API,主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能,以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制,而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。
會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私,這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。
問題
大家應該都有點了一個產品的網頁後,很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面,他怎麼會知道我看了這個產品的頁面?
通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。
當使用者登入 Facebook 之後,Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面,當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時,瀏覽器在載入 SDK 時會再度夾帶這個識別碼,此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式,Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡,從你的瀏覽紀錄推敲喜好,餵給你 Facebook 最想給你看的廣告了。
不過跨站追蹤也不是只能用在廣告這樣的應用上,像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。
雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務,但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢?
這就是今天要講的新 API: Trust Token。
Trust Token API - The Chromium Projects
Trust Token / Privacy Pass 簡介
Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制,可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass,所以兩個運作機制類似,但是實作方式稍有不同。
先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春,不過大致上還是可以了解整個概念。
以 hCaptcha 跟 Cloudflare 的應用為例,使用者第一次進到由 Cloudflare 提供服務的網站時,網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。
當使用者答對問題後,Cloudflare 會回傳若干組 blind token,這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token,這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token,在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token,這個步驟稱為 redeem token。
但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起,也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token,但是在後續瀏覽不同網站時把 token 兌換掉時,Clouldflare 並無法區分哪個 token 是來自 Bob,哪個 token 是來自 Alice,但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。
但這樣的機制要怎麼完成呢?以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。
零知識證明 (Zero-knowledge proof)
零知識證明是一種方法在不揭露某個祕密的狀態下,證明他自己知道那個秘密。
Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的,下面簡單的翻譯一下:
假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉,如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力?我們可以設計一個流程來證明這件事情。
Alice 先把眼睛閉起來,請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候,告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到,但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。
而零知識證明的原理大致上就是這樣,你可以用一個流程來證明你知道某個秘密,即使你不真的揭露這個秘密到底是什麼,以上面的例子來說,這個秘密就是超能力運作的方式。
以上就是零知識證明的概念,不過要完成零知識證明有很多各式各樣的方式,今天我們要介紹的是 Trust Token 所使用的零知識證明:DLEQ。
DLEQ (Discrete Logarithm Equivalence Proof)
說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar),如果是大寫如 G, H則是橢圓曲線上面的點 (Point),如果是 vG 則一樣是點,計算方式則是 G 連續相加 v 次,這跟一般的乘法不同,有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。
DLEQ 有一個前提,在系統中的所有人都知道公開的 G 跟 H 兩個點,此時以下等式會成立:
假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何,並且在這個過程中不揭露 s 真正的數值,此時 Victor 可以產生一個隨機數 c 傳送給 Peggy,而 Peggy 則會再產生一個隨機數 v 並且產生 r,並且附上 vG, vH, sG, sH:
r = v - cs
所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值:
vG = rG + c(sG)vH = rH + c(sH)
我們舉第二個等式作為例子化簡:
vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH
這樣只有 Peggy 知道 s 的狀況下才能給出 r,所以這樣就可以證明 Peggy 確實知道 s。
從簡易到實際的情境
Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境,不過前面的例子就會相對比較天真一點,就請大家一步步的往下看。
基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的,以下參與的角色分為 Client 與 Server,並且都會有兩個階段 issue 與 redeem token。
Scenario 1
如果我們要設計一個這樣可以兌換 token 來確認身分的系統,其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server,Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client,這個產生 sT 的過程稱為 Sign Point,不過實際上運作的原理就是橢圓曲線上的連續加法運算。
SignPoint(T, s) => sT
等到 Client 需要兌換時只要把 T 跟 sT 給 Server,Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。
Issue
以下的範例,左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server,反之亦然。
// Client 發送 T 給 Server, 然後得到 sT
T -> <- sT
Redeem
// Client 要 redeem token 時,傳出 T 與 sT
T, sT ->
問題:Linkability
因為 Server 在 issue 的時候已經知道了 T,所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。
Scenario 2
要解決上面的問題,其中一個方法是透過 Blind Signature 達成。Client 不送出 T,而是先透過 BlindPoint 的方式產生 bT 跟 b,接下來再送給 Server bT。Server 收到 bT 之後,同樣的透過 Sign Point 的方式產生結果,不一樣的地方是情境 1 是用 T,而這邊則用 bT 來作 Sign Point,所以得出來的結果是 s(bT)。
Client:BlindPoint(T) => (bT, b)
Server:SignPoint(bT, s) => sbT
而 Blind Signature 跟 Sign Point 具備了交換律的特性,所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind:
UnblindPoint(sbT, b) => sT
這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了,而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點,同時因為 T 從來都沒有送到 Server 過,所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。
Issue
bT -> <- s(bT)
Redeem
T, sT ->
問題:Malleability
以上的流程其實也有另外一個大問題,因為有交換律的關係,當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT):
BlindPoint(sT) => a(sT), a// a(sT) === s(aT)
此時如果將 aT 跟 s(aT) 送給 Server Redeem,此時因為
SignPoint(aT, s) => s(aT)
所以就可以兌換了,這樣造成 Client 可以無限地用任意數值兌換 token。
Scenario 3
這次我們讓 Client 先選擇一個純數 t,並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T,並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。
因為 redeem 要送出的是 t,上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了,因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到,所以就沒辦法無限兌換了。
Issue
T = Hash(t) bT -> <- sbT
Redeem
t, sT ->
問題:Redemption hijacking
在這個例子裏面,Client 其實是沒有必要傳送 sT 的,因為 Server 僅需要 t 就可以計算出 sT,額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題,如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。
不過在網站上沒講出實際上要怎麼利用這個問題,但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好,而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。
Scenario 4
步驟跟前面都一樣,唯一不一樣的地方是 redeem 的時候原本是傳 t, sT,現在則改傳 t, M, HMAC(sT, M),如果再介紹 HMAC 篇幅會太大,這邊就不解釋了,但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。
這樣的特性在這個情境用很適合,因為 Server 透過 t 就可以計算出 sT,透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。
Issue
T = Hash(t) bT -> <- sbT
Redeem
t, M, HMAC(sT, M) ->
問題:Tagging
這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’,這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。
要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。
Scenario 5
前面的 DLEQ 講解有提到,如果有 Peggy 有一個 s 秘密純量,我們可以透過 DLEQ 來證明 Peggy 知道 s,但是又不透漏 s 真正的數值,而在 Privacy Pass 的機制裡面,Server 需要證明自己每次都用 s,但是卻又不用揭露真正的數值。
在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端,但 Server 端的回應就不一樣了,這次 Server 會回傳 sbT 與一個 DLEQ 證明,證明自己正在用同一個 s。
首先根據 DLEQ 的假設,Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client,而 H 則改用 bT 代替。
回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token,所以附上了一個 DLEQ 的證明 r = v - cs,Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替,此時 client 也有 sbT 也就是 sH):
vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT
這樣就可以證明 Server 依然用同一個 s。
Issue
T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)
Redeem
t, M, HMAC(sT, M) ->
問題:only one redemption per issuance
到這邊基本上 Privacy Pass 的原理已經解釋得差不多了,不過這邊有個問題是一次只發一個 token 太少,應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。
Scenario 7
由於一次僅產生一個 redeem token 太沒效率了,如果同時發很多次,每次都產生一個 proof 也不是非常有效率,而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法,這樣就可以大大的降低頻寬需求。
不過這邊我們就不贅述 Batch DLEQ 的原理了,文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。
Issue
T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)
Redeem
t1, M, HMAC(sT1, M) ->
結論
Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式,期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。
不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去,而協議制定的過程中其實廣告龍頭 Google 也參與其中,希望這份協議還是可以保持中立,盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。
參考資料
IETF Privacy Pass docs
Privacy Pass: The Protocol
Privacy Pass: Architectural Framework
Privacy Pass: HTTP API
Cloudflare
Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)
Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化
Other
Privacy Pass official website
Getting started with Trust Tokens (web.dev)
WICG Trust Token API Explainer
Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用,列了很多零知識證明的源碼參考,但可惜的是 DLEQ 這個演算法講解有錯,讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心,源碼應該是可以參考的,解釋的話需要斟酌一下。
關鍵源碼
這邊我貼幾段覺得很有用的源碼。
privacy pass 提供的伺服器端產生 Proof 的源碼
privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼
github dedis/kyber 產生 Proof 的源碼
[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
實驗流程圖範例 在 實驗流程圖範例2023-在Facebook/IG/Youtube上的焦點新聞和 ... 的推薦與評價
今日課程:流程...,2020年5月26日—如何用PPT画实验流程图的一些照片,在一些科研实验中发表的论文需要绘制流程图,其中,有的期刊不让用直接拍摄的图片,今天小编就 ... ... <看更多>
實驗流程圖範例 在 只會用Office 畫流程圖?許多人試用過這個後直呼回不去了 的推薦與評價
![影片讀取中](/images/youtube.png)
內容綱要00:00 流程圖 製作04:51 組織圖製作06:07 使用便箋本儲存圖形08:15 隱藏子層級圖示09:13 泳道圖製作11:03 固定vs 浮動式連接線12:21 圖層管理 ... ... <看更多>
實驗流程圖範例 在 實驗流程圖範例2023-在Facebook/IG/Youtube上的焦點新聞和 ... 的推薦與評價
今日課程:流程...,2020年5月26日—如何用PPT画实验流程图的一些照片,在一些科研实验中发表的论文需要绘制流程图,其中,有的期刊不让用直接拍摄的图片,今天小编就 ... ... <看更多>