Insight Tech

增長任何業務可以指許多事項，但終究幾乎都涉及擴展客戶基礎。與許多其他產業不同的是，物聯網開發商通常可利用其基本技術來因應新的應用程式與市場。

雖然從表面上看，應用程式不盡相同，但能夠適應常見技術與方法的能力，為開發商提供了立即擴大市場範圍的機會。人工智慧與影像分析的交會，提供了一個最好的範例。

機器學習與模式識別，再加上影像，已實現資訊作業自動化，使得作業速度更快，而且提高可靠性。而且，邊緣運算把處理工作從資料中心轉移到使用一系列光譜來收集不同類型資訊的攝影機。

認知多媒體分析公司 Graymatics 執行長 Abhijit Shanbhag 說：「長期以來，閉路電視攝影機用於部署在各處，例如，遍佈城市、建築物內部，以及整個機場。」「而這些攝影機的使用，通常就是搭配一位偶爾監看螢幕影像的警衛。」

但是，影像的威力絕對不止是安全。它還能協助簡化作業流程。透過適當的軟體，攝影機可提供一系列資料，無論是協助提升客戶體驗、或是改善工廠生產線品質。

收集資料的能力已經垂手可得。現有軟體之調整和重新導向，開啟了新機會。

交叉驗證與人工智慧技術是關鍵

Graymatics 透過運用強大的演算法、深度學習技術以及智慧型影像分析， 已開發出高度靈活的人工智慧平台 。

該公司的雲端式 G3C.AI 軟體可分析影片串流，快速識別並檢查潛在問題、異常或感興趣事件。它採用即時串流通訊協定 (RTSP) 影像輸入並作處理，將分析送回儀表板或警報。

應用程式介面和程式庫提供開發商及終端使用者使用平台的影像分析功能。然後，一套工具可快速開發圖形使用者介面元件。

納入新客戶受眾的範例，從建築管理開始。自動化停車控制使用攝影機及邊緣運算，以處理車輛車牌的圖像、檢查授權使用者的資料庫、即時監視是否仍有露天停車位，並且允許存取授權人員。

這些基本功能在看似無關的應用中仍屬必要。授權停車與設施取用控制相類似。計算通過建築物人數與監看他們如何通過零售店相類似。而且，在建築工地中識別出安全帽和安全鞋之使用，與認出沿著生產線移動產品之目視可見缺陷，兩者也相去不遠。

Graymatics 透過將基礎技術轉移到不同但類似應用之創新能力，顯示出開發商如何能夠做到垂直成長，例如智慧城市、工廠和零售。

Shanbhag 表示：「一旦我們談論購物中心這類領域，在購物中心裡的每個零售店面，使用我們的分析是個自然的發展。」「建設公司想要在他們的園區內建構這種能力。從園區出發，分析範圍發展到智慧城市，因為需要做的分析有很多重疊。在公司範疇內，建築物又導致到建築工地，而部分建築物是工廠，也需要類似型態的自動化。」

優異的平台和優秀的夥伴

Graymatics 對於這類擴展的關鍵點是，它已經做出一個可以摘錄問題的適當平台。若要保持經濟效率，開發商必須避免浪費時間和資源進行重覆發明。平台儘可能提供常見的核心功能。

Graymatics 可透過這類策略滿足各種需求。其中一種需求，就是用來處理影像的交換人工智慧模組，以達成不同的使用案例，儘管基本概念（可能連大部分程式）與公司在其它地方運用的都相同。另一種則是為新型硬體或一般功能增加全球支援，使得所有應用程式都能存取。

平台僅與它所使用的生態系統同等強大。Shanbhag 表示：「我們透過 Intel^® 技術，例如 Intel^® OpenVINO^™ 工具組、Intel^® Movidius^™ VPUs 以及 IEI TANK AIoT 開發工具組，將我們的軟體進行最佳化。」「G3C.AI 與許多資料庫、影像儲存系統和其他工具相容，使得與現有基礎架構之間有更大的相容性。」

此外，夥伴也相當重要，例如加值配銷商、系統整合商和代理商。因為 Graymatics 僅能處理人工智慧驅動的影像分析，因此透過與其他合適公司合作，保持了轉移到新應用程式的靈活性。

該公司尋找與 Intel 密切合作的夥伴。Shanbhag 表示：「這已經幫助我們加速進入的腳步，並在各種領域中建立一些很好的接受度，而這一開始可能並非第一優先。」

公司用於處理新垂直應用領域之特定流程，因市場的性質而異。例如，在智慧城市中，Graymatics 與主機系統整合商及伺服器夥伴合作。裝置與應用程式使用 G3C.AI 應用程式介面，以取得他們需要的特定演算法。

但是，對於零售店面來說，合作夥伴層次較少。在零售業方面，Graymatics 的要求在於店面攝影機提供影像輸入作 RTSP 連結，然後將影像送到其雲端系統。然後，該公司會向零售商提供一個網路連線網址，內含可回答特定問題資料之儀表板。「例如，在店裡，30-35 歲女客在特定產品顯示幕前關注多少時間？」Shanbhag 表示。

透過有智慧地工作、善用夥伴，並認識到如何將先前已解決的問題運用到新的應用之中，像 Graymatics 這樣的軟體公司，可以找到世界各地的新市場。

5G 網路的優勢佐證資料完備。相較於 4G，在相同的地理空間中，使用者可預期下載速度快 100 倍、延遲低 10 倍，支援的裝置是 500 倍。為因應如雨後春筍般問世的新型應用程式，無論是自動駕駛汽車、送貨無人機，還是擴增實境和 4K/8K 影片串流，這些增強功能應該都大有助益。

然而，為了大規模支援這些新型應用程式，5G 基礎架構究竟將以什麼方式導入，依舊是個問號。另外，為支援效能提升後隨之增加的大量資料，究竟會採用哪些基礎技術，這個問題也是個未知數。

首先，5G 小型基地台的網路處理器（NPU）必須保有餘裕，才能支援未來十年大幅增加的數據使用量。在創新設計技術的輔助下，您現在就能動手設計這類 NPU。

小型 5G 基地台需要改頭換面

小型基地台是低功耗的無線電存取點，可將核心行動電話通訊網路延伸至一般使用者。這類基地台一直是 4G 網路的主力，但獨特之處在於，5G 的裝置和資料流量增加，正如一份 Ericsson 研究指出，每一名使用者的增幅高達 4 倍之多，這樣一來，小型基地台網路處理器就必須超時作業。

小型基地台包含基頻處理用的 FPGA、處理核心網路乙太網備援的 NPU、排程用的 CPU 核心、數據機，以及相關記憶體和 I/O。

有鑑於 5G 工作量需求攀升，需要更強大的力量，某大行動電信業者已就在 5G 小型基地台概念性驗證（PoC）採用 Intel ^® Atom ^® 處理器，著手展開調查。雖然這類處理器提供的運算量較高，但也需要導入不同的架構。為了實現這項目標，該電信業者於是求助於 DFI Inc. 這家高效能運算技術的全球供應商。

5G 小型基地台：時間至上

姑且不論效能上的優勢，Intel^® 處理器在高速資料處理方面引人矚目的一點，就是識別中斷所需的時間。如圖 1所示，FPGA 基頻處理器收到 RF 訊號時，將 80 ns 的脈衝寬度傳送至採用 Intel 處理器的 NPU，以及一個獨立的 5G 模組。另一方面，處理器至少需要 117 個十億分之一秒，才能查出通用型 IO（GPIO）中斷。接下來，Intel SoC 在第一批作業開始前，遇到了中斷延遲。

這件事為什麼重要？時間是網路通訊的真諦。

「每部裝置都必須及時同步，才能確保所有資料與動作都一樣。」DFI 產品管理總監 Ethhan Wowg 解釋。「FPGA 同時向 5G 模組和 NPU 發出訊號時會被 GPIO 中斷。該中斷延遲是從訊號接收算起，到裝置展開第一個動作為止的時間。」

處理器收到訊號時，至少需要等上 20 至 25 μs，才能展開第一個動作，但這段時間實在是太久了。原因在於，5G 規格將程序週期分成「時段」，就這個 5G 小型基地台 PoC 而言，該時段定義為 125 µs。

「在只有 125 µs，延遲為 25 µs 的情況下，一個時段內全部的處理和通訊只剩 100 µs 的時間可以完成。」Wong 表示。

彎曲時間

為了克服這個時間問題，DFI 實作了幾種標準與非標準解決方案。

「我們實作了一個硬體電路，將 80 ns 脈衝寬度延伸為 200 ns，讓我們偵測得到訊號。」Wong 表示。「在軟體方面，我們採用不同的低延遲 Linux 核心，將延遲從偶爾的 40 µs 降到 20 µs，儘量縮短中斷延遲。」

DFI 還將 NPU 和 5G 模組之間的 PCIe 連線最佳化，提升了整體系統效能。但這樣一來，125 µx 的時段內用於處理和通訊的時間依舊稍微不足 100 µs。

儘管該業者基於低成本和低耗電選擇了 16 核心 C3000 處理器，但 SoC 透過 10 個 GbE 連接埠締造的運算效能和資料流量足足有餘，彌補了損失的時間（圖 2）。

為未來擴充 5G

5G 講求的不僅是速度，容量更是關鍵中的關鍵。我們在行動裝置消耗的高頻寬資料與日俱增，加入物聯網的日常用品也愈來愈多，網路勢必得擴展才足以支援。

從 CAPEX 的角度來看，以這一點為前提設計系統是最佳的行動方針。16 核心 C3000 處理器這類 NPU 提供的效能足以因應當今的工作量，也保有餘裕可因應未來日益增加的資料流量。DFI 這類網路硬體專家將 PCIe 訊號最佳化、調整 Linux 軟體堆疊，持續讓這些解決方案更上層樓。

5G 小型基地台網路已部署於全球五大洲。如果您想加入未來的行列，不趁此時更待何時。

請想像一座智慧建築。假設是一間台北市的百貨公司。設施經理注意到今年冬天的電力消耗比平均高出了 17%。

一般人或許乍看之下會將這不合理的高電力花費，歸咎於當月特別寒冷。但進一步分析建築物的營運資料後，該設施經理得知頂樓的暖通空調機內的節能器風門故障且需要維修。在立即修復後，電力費用恢復正常。

雖然這故事聽起來很簡單，但事實並非如此。的確，若將暖通空調機、照明、電力以及其他系統連接到一個智慧、中央控制的智慧平台，建築自動化系統確實有助於最大化效能並降低成本（圖 1）。然而，若想善用此基礎架構，意味著需要從不同子系統中提取資料、將資料彙總，然後建立有用的相關性。

上述的情境只有在克服某些複雜的技術障礙後才可行：

• 資料提取：智慧建築內的不同端點和裝置，大多採用不同的通訊協定進行溝通。然而，它們都必須與單一且統一的智慧建築分析平台做整合。
• 資料彙總：資料擷取後必須標準化；但每套智慧建築系統在產生資料時，可能會使用不同格式、結構式或非結構式、連續時間序列或關聯式，甚至是使用不同單位的資料（例如 kWh 和 ºF/ºC）。
• 資料分析：標準化後的資料必須要經過分析，才能轉化成有用的資訊。遺憾的是，大多數的分析平台都專為特定領域或目的打造，且對於一般用途的使用案例（如智慧建築）來說過於侷限。

而要進行這一切還必須要考量到關鍵利益攸關方。物聯網資料分析的基礎架構通常更著重於資料擷取，卻不夠重視可能使用該資料的人士以及資料用途。

「若能將分析演算法套用到您的資料上，便能讓您偵測可能導致退步的趨勢，或是可能被視為退步的效能損失，」 SkyFoundry 的共同創辦人 John Petze 解釋道。「但假設您辦公室內的室溫為 30 度，您根本不會在乎空調有沒有在吹。嚴格來講，機器並沒有完全壞掉，但對您來說已經算壞掉了。」

資料分析：從擷取轉換成 KPI

SkyFoundry 這家物聯網軟體開發工具供應商，針對智慧型建築設計了 SkySpark 分析平台，有助於業主和作業人員實作有效的資料分析策略，如虎添翼。該解決方案採用「邊緣到雲端」的基礎架構：在邊緣裝置上，該平台提供一套低耗能軟體疊層，可以部署到以 Intel^® 處理器為基礎的物聯網閘道，以及到可執行 Java 虛擬機器 (JVM) 的端點上。這個疊層能從各個現場總線協定（如 BACnet IP、Modbus-TCP、MQTT 以及 OPC UA）擷取資料，並封裝在 Arcbeam（一種叫 WebSocket 型的點對點協定）中。

在雲端中，Arcbeam 會將這些封包傳輸到 SkySpark 多結構化、連續時間序列的 Folio 資料庫中（類似融合記憶體資料庫和如同 SQL 關聯式資料庫的成品）。該技術採用 Project Haystack，這是一項開源語義資料模型標準，提供多種來源的延伸標籤方式，以便在單一資料庫實例中進行標準化。

這些元件能解決在智慧建築這種使用案例中，從多個子系統擷取資料並將其標準化所遇到的技術難題。接下來，要如何運用這些資料呢？這正是最困擾 IT 及作業團隊（尤其是沒有資料科學家或分析人員的團隊）的問題。

SkySpark 利用內建分析功能的資料庫來解決這個問題，該資料庫可用於針對擷取資料執行規則或演算法。專為各行各業以及終端使用案例設計，缺乏或甚至沒有專業知識的使用者也能利用這些內建功能，將原始資料轉化為有用的分析資料。

「分析功能庫」可以執行應用層級的資料分析，省去大樓營運人員在茫茫資料中尋找指標的麻煩。事實上，甚至設定平台，讓指標主動送到營運人員面前。

SkySpark 平台會根據 Folio 資料庫內的資料和搜尋結果，自動產生視覺化圖片、通知以及報告（位於可自訂的控制面板中）。控制面板支援幾乎所有形式下類型的資料，而且使用者透過「View Builder」工具（圖 2）輕鬆點擊進行更動。

接下來，可立即使用的 SkySpark 應用程式，將能協助使用者以最適合手邊使用案例的方式，釋義並呈現分析資料。舉例來說，一個 KPI 應用程式能將興趣點以直覺式的 HTML5 形式呈現，讓讀者更容易理解。

這些應用程式中的即時資料和分析結果，能透過開放 API 輸出給第三方系統，讓現代、先進的物聯網分析資料與現有企業軟體整合。

策略第一，資料第二

像 SkySpark 這樣的靈活分析工具，可以整合至現有的大樓自動化基礎架構，只要確保軟體有足夠的效能、效率、網路與安全性來執行虛擬機器，並可將端點資料連接到雲端上。由於 Intel 處理器技術已在各種 BAS 部署中執行，基本上可以流暢地轉型到有用、資料導向結果的流程。

如此一來，組織便能把資料分析工作的重點，放在尋找對關鍵利益攸關方重要的 KPI 上。但這點說的比做的容易。舉例來說，營運長與財務長可能會想要根據電力消耗、使用率、維修成本以及環境風險因素，來計算不同地點的營運成本。而銷售經理可能會需要參考天氣評估、數位標牌內容、以及這些內容對店內人流的綜合影響。

的確，只要能存取所有的資料，幾乎就可以創造無限的分析成果。面對重生可能性，開始智慧型建築轉型的最佳途徑，就是擬定一項不會耗費巨資的策略。