前言

隨著台灣e化、m化、以及u化腳步的演進，嵌入式系統已被廣泛應用在各個領域，包括工業應用、生活與建築自動化、多媒體應用等等，這也讓無線感測網路（Wireless Sensor Network；WSN）這個概念越來越常見。例如不論是使用Bluetooth、UWB（Ultra Wide Band）、ZigBee乃至於RFID等等協定，只要是使用無線通訊，包括兩個以上的節點（Node），每個節點配合一至多個感測器（Sensor），這樣都可以廣義的被歸納在屬於「無線感測網路」的範疇內。

由WSN的應用需求來看，似乎較可以用由上到下（Top-down）的方式來了解各個細節，並研究可能衍生的問題。因此，在介紹WSN各個層面的關鍵技術時，相關應用案例的輔助說明也是非常重要的；亦即以技術分析為核心、應用介紹為輔，進而可清楚勾勒WSN的輪廓。

簡介WSN發展現況和解決方案

WSN是先由美國國防部（DAPRA）資助、以UC Berkeley以及UCLA為首進行研究並開發應用，國外的平台提供商大概則有Crossbow Technology、Moteiv、Scalable Network Technologies（SNT）、以及Dust Networks等。

Crossbow利用UC Berkeley的Mica節點，配合Intel的Stargate閘道器，在Cisco以及Intel的贊助下，開發了提供使用者佈建WSN所需的軟體工具與平台。

另一家Moteiv也是由UC Berkeley的技術團隊成立，並沿用TinyOS系統，提供使用者快速佈建的解決方案。SNT則是根據UCLA的GloMoSim模擬程式，提供了一套可混合模擬有線與無線網路的QualNet模擬器。這套模擬器能有效幫助使用者針對複雜的異質網路進行分析，協助規劃和評估效能。Dust Networks則是由包括UC Berkeley教授Kris Pister的團隊所創立，提供給使用者很快就能上手使用的「 黑盒子式」硬體平台。藉由XML RPC標準，使用者即可命令閘道器讀取節點資料，而節點也會根據佈建時的設定自行組成網路。

從應用佈建的觀點而言，Crossbow與Moteiv應用TinyOS相關系統，可以發展的彈性非常大，適合掌握網路架構與系統技術的服務提供商。而Dust Networks提供較為單純的使用者介面，以利使用者專心發展應用層面，而不必去對網路層多做瞭解。兩套解決方案都各有市場，使用者可依據自身技術背景以及應用需求選擇。

台灣廠商單位包括華寶、台達電、資策會與工研院等都有提供完整的WSN平台，今年國科會也極力推動WSN開放平台，希望藉由開放原始碼的力量，統一WSN應用平台的開發規格。

目前在WSN解決方案部分，還有很多的應用都是使用特殊規格的通訊協定。例如Dust Networks的Smart Dust，即是使用特殊自有規格的無線通訊協定。另外在實際佈建方案上，Honeywell在辦公室與住宅自動化已經有推出使用ZigBee的無線感測網路解決方案。台灣的識方科技則是針對監控與安全相關的應用提供相關解決方案。整體而言，居家自動化與安全監控算是感測網路的應用重點，不過在無線化方面則是尚未找到利基，故仍未開始大量佈建應用。

簡介WSN平台硬體與系統架構

根據WSN的特性來看，整個應用平台的幾個關鍵模組、其中相關技術內容如下。

處理器

WSN的節點，為了因應低功率的消耗條件，通常都使用低耗電的8位元處理器。此類型節點也不會由軟體去執行複雜的通訊協定堆疊（protocol stack），也不會進行太過繁複的即時運算。但因為on-chip運算的耗電量遠低於無線傳輸，若在反應時間允許的情況下，可以盡量利用各種前處理的演算法來減少使用無線傳輸的時間與頻寬。8051、Microchip的PIC、Atmel的AVR、以及Freescale的MC1321x系列，都是目前在WSN應用上廣被採用的處理器解決方案。

德州儀器（TI）也推出了一款16位元的MSP430處理器，雖然運作時脈較低，但是卻非常省電，目前Tmote等硬體平台都使用MSP430作為運算處理器。但是若要讓處理器直接面對於ZigBee網路協定，同時還要加上一些即時的前處理運算，對於8位元處理器的效能來說可能會有所不足。因此Intel的Mote2、Jennic的JN5121、以及工研院的CX32都是以32位元處理器為主，配合可以再進一步微調的軟體網路協定，不但可以加強整個網路的容錯性，也提供更多的計算能力來完成可能的資料前處理以及更多智慧型的即時判斷。

無線通訊基礎硬體模組（PHY、Mac）

目前WSN並沒有特別規定使用的無線通訊基礎硬體以及通訊協定，在基礎硬體模組方面，許多廠商皆是以IEEE 802.15.4或是自訂標準來實現WSN。

至於在RF設計方面，目前國外的Chipcon、Freescale、Microchip、Atmel、Nordic以及Jennic等都有自行開發支援IEEE 802.15.4相關RF模組。台灣則有達盛電子開發自有的IEEE 802.15.4 RF模組。

天線設計與其他干擾考量

WSN的使用環境，會因為不同應用可能產生相當大的差異，天線設計在整個WSN的應用建置非常重要，例如野外環境監測的感應節點位置可以固定， 但可能因節點之間佈建距離較長因素，需要使用加強型的指向性天線並調整發射功率。再者，外在環境因素會影響無線通訊的品質，這包括轉動設備與周圍高壓電流的干擾、水氣干擾2.4GHz頻段、以及WiFi和其他在2.4GHz頻段使用的設備干擾等等，都會影響整體WSN的效能。因此如何針對不同應用，設計或變更可對應配合的天線、並選擇適當的發射功率，已是WSN平台設計考慮的重要項目之一。

網路通訊協定（Network Protocol）

節點與閘道器之間的通訊拓譜（topology）部分，以往很多WSN的應用都是單純以IEEE802.15.4來實作點對點（point to point）以及單點對多點（star）的網路。近年來Zigbee網路通訊協定代表著網路通訊規格趨向智能化的方向，並針對不同的應用功能制定profile，以達到提升效能與低耗電作用。

Zigbee聯盟由HomeRF聯盟分出後，便有許多廠商加入參與，主要推動廠商有Chipcon、Freescale、Honeywell、Motorola、Philips、Samsung、Siemens、TI等等。在台灣目前也有工研院、資策會以及達盛電子（Ubec）等投入。

Zigbee硬體裝置基本上分為協同器（Coordinator）、全功能裝置（Full Function Device）以及精簡功能裝置（Reduced Function Device）。Zigbee在PHY以及MAC層都是建構於IEEE 802.15.4協定上，而網路拓譜則可以是星狀（Star）或是任意（Mesh）型態。Zigbee網路由協同器建立子網路的拓譜，並具有自我容錯功能，因此在應用方面深具彈性、且具有強度（robustness）。

感測器（Sensor）

感測器大略可分為類比式與數位式感測器，基本上動作方式可能相同，例如透過化學的偵測器或是機械的力學作用等、然後造成電流或是電壓的變化， 類比式感測器就是直接將這個電流或是電壓的變化輸出，而數位式感測器則內建一個類比數位轉換器（A／D Converter）來將感測器測得結果以數位方式傳送。針對不同應用，WSN的感知節點上會使用不同的感測器，諸如荷重、扭力器、光感應器、溫度濕度感測器、位移器、速度與加速度器等等。

IEEE 1451規格

由於感測器廣泛被應用在工業控制、自動化、飛行器與航空、建築與土木、甚至在生化科技等領域，因此如何制訂智慧型轉換器介面規格（Smart Transducer Interface Standards），讓感測器能順利地與網路、系統、處理器或是另一套感測器進行界接，以降低開發複雜度與研發成本，此即是IEEE 1451制訂的主要目的。

IEEE 1451的精神在於轉換器電子資料表單（Transducer Electronic Data Sheets；TEDS），此表單就是在轉換器上的一個記憶體裝置，紀錄轉換器ID、校正、量測資料、量測範圍以及製造相關資訊等等。藉由此電子資料表單資訊，讓使用者在使用有線或是無線連接情況下，都可以利用共通的介面存取感測器的數值。

目前IEEE 1451家族有從0到6編號、共7個working group正在進行研究與規格制訂。其中，與WSN關係密切的IEEE 1451.5，定義了轉換器與具有網路功能的應用處理器（Network Capable Application Processor）的介面，以及轉換器上具有無線通訊功能的轉換器電子資料表單規格。簡言之，大家可以把IEEE 1451.5看成是運作在protocol stack上的應用層。基於大家所熟悉的802.11（Wi-Fi）、802.15.1（Bluetooth）、以及802.15.4（Zigbee）等通訊協定，去制訂發現感測器、通訊、以及讀取轉換器電子資料表單的相關規格。

目前欲克服推廣IEEE 1451的難題在於，如何降低提供TEDS功能所衍生出來的額外成本。感測器若提供TEDS晶片功能，成本可能會提高10％到15％。雖然一些供應商認為，整體測量系統的成本會偏重於資料擷取系統（Data Logger）以及相關軟體部分，但目前IEEE 1451推動進度緩慢，代表市場反應確實仍在觀望。不過今年3月，IEEE 1451.5無線感測器規格已經被IEEE協會認可為Full-Use Standard，往後應會鼓勵許多通訊系統整合業者紛紛加入WSN的應用層面。

閘道器（Gateway）硬體平台

閘道器一般需要接收由節點回傳的資料，並轉交給後端資料中心或是主機，因此閘道器通常都有電源供應（plugged power），並連接至較為快速的網路如Ethernet、Wi-Fi或ADSL。硬體平台本身多以32位元處理器為主，配合Linux或是其他功能較為強大的作業系統，提供橋接（bridging）資料的服務。

WSN的感測資料處理

WSN資料處理特性

目前市面上的無線感測平台，多以無線模組為基礎元件，加上使用者所選用的通訊堆疊，提供一個可以進行無線通訊的終端節點（End Node）。根據不同應用，這些節點可能配備不同的感測器。無線感測裝置的耗電量、硬體與通訊的可靠度，都是需留意的重點。針對不同的應用與情境，系統解決方案提供者需要去定義感測時間長度以及週期，除了會影響感測的正確性，也會對硬體平台的耗電量產生影響，也因為訂定方式因地制宜，所以難有通用準則。不過擷取資料後的處裡，使用者可用Open Geospatial Consortium（OGC）組織所制訂的開放規格來進行討論。

應用SWE規格的感測器服務

最初OGC組織是以地理資訊系統的web化出發，希望把大地監控等相關地理資訊應用，透過web簡單介面讓使用者輕鬆瞭解使用，不過這些規格其實是可以廣義地擴展應用到WSN領域，因此Sensor Web Enablement（SWE）規格也逐漸完成。

使用者可將SWE規格視為許多web service服務的組合。若IEEE 1451系列規格是要制定感測器與系統、或是通訊網路之間的介面（TEDS），那麼SWE則是想提供一個從感測網路使用者或是管理者的眼光所看到的需求。由(圖一)可知，SWE對於感測網路提供四種基礎服務，分別是感測器觀察服務（Sensor Observation Service；SOS）、感測器排程規劃服務（Sensor Planning Service；SPS）、網頁介面通知服務（Web Notification Service；WNS）以及感測器警示服務（Sensor Alert Service；SAS）。

《圖一　SWE基礎服務示意圖 》 資料來源：工研院ITRI

SOS感測服務

感測器觀察服務（SOS）主要回覆使用者感測平台所具有的能力以及所配備的感測器功能，並進一步接受使用者的查詢。溝通規格則是以一套XML的延伸語法SensorML進行資料交換，這裡以一個在工廠內監控馬達振動的WSN範例來說明，如(圖二)所示。

《圖二　工廠內監控馬達振動的WSN範例 》 資料來源：工研院ITRI

例如，使用者希望知道過去5個月馬達振動的紀錄，因此對SOS服務提出Get Observation的要求。透過web形式的使用者介面，使用者送出「回傳過去5個月平均振動的數值」此一訊息。這個要求被轉換成SensorML形式後，傳送到馬達監控WSN後台系統，後台系統就從歷史紀錄中取出相關數值，再轉換為SensorML回傳。事先定義的SensorML介面，可以讓WSN所需要的客製化使用者介面迅速地被製作出來，而WSN的應用多樣且少量，此一共通化規格能讓WSN的發展更為快速。

SPS與SAS感測服務

有了SOS這個例子，我們就可以很快的了解其他服務的涵義。感測器排程規劃服務（SPS）就是提供使用者規劃感測動作項目。例如範例中的馬達振動感測系統，每星期就進行一次感測工作，每次進行十分鐘紀錄。要求規定後，馬達監控WSN後台系統就會評估感測系統狀況，並回覆使用者此次排程內容。根據排程使用者可以訂閱馬達振動警告，當測量到馬達的振動超過一定數值，便發出警訊通知使用者注意，這就是感測器警示服務（SAS），如(圖三)所示。

《圖三　SPS與SAS感測服務示意圖 》 資料來源：工研院ITRI

WNS感測服務

另外使用者排程完畢之後，感測系統所測量的結果都可以透過網頁介面通知服務（WNS）告知使用者，其結果也可以透過不同的介面如手機簡訊或是email等方式來顯現。與SOS相比，SOS像是一個根據SensorML進行「查詢－＞回覆」的機制，而WNS則是提供多樣的告知功能，讓使用者完成感測工作排程之後透過不同方式收到通知。

(圖四)是在工研院內部工廠所佈建的一個案例圖示。管理者可以經由WNS服務，定期收到工廠內部溫溼度與一氧化碳數值；工廠安全監控主機可以透過SOS與SPS服務收集感測器的資料；公共安全與消防人員就會由SAS提供警示服務，在發現有不正常狀態出現的時候，即時反應與支援。

《圖四　工研院內部工廠佈建SWE感測服務網路示意圖 》 資料來源：工研院ITRI

SWE規格的優勢

此由OGC組織提出的SWE規格，最主要是根據web-base service概念，以一套已提供完整定義的SensorML，訂定命令與訊息交換格式。在WSN環境中，此規格能讓系統業者在面對各種應用時，於微調自己的軟體元件以後，便可即時迅速提出相對應的系統解決方案與介面應用內容，並且能和其他使用OGC的SWE規格產品互相界接，並且反過來加速WSN的應用廣度。

展示使用者介面

在使用介面端，目前Microsoft提供一套SensorMap介面，SensorMap，能讓使用者建立具有地理位置資訊的感測器，如IP-Camera、溫度計等等，並讓感測器的結果直接在Microsoft的地圖圖資上讀取，並提供過濾與搜尋等功能，如(圖五)所示。

《圖五　具有地理位置資訊感測功能的使用介面 》 資料來源：Microsoft Research

結合地理資訊位置的感測器網路，雖然不見得是以無線通訊為後端，但是這個使用者介面倒是提供一個不錯的思考點：WSN佈建成千上萬的感測器時，使用者介面該如何呈現，如何能讓使用者迅速找到相關感測資料，這些都是需要進一步去整合的課題。

工研院WSN領域的發展現況

工研院目前積極從應用端角度開發WSN的解決方案，目前針對工業以及家庭應用多有著墨，馬達振動、橋樑傾斜、工廠安全防災、家庭自動化與安全監測等應用，都會是發展重點。

在底層技術方面，工研院使用Chipcon CC2430／CC2431的RF晶片，並自行開發與ZigBee相容並提升網路強度與通訊可靠度的通訊堆疊。(圖六)展示工研院自行整合開發的WSN硬體平台，分別有Chipcon CC2430／CC2431為核心的RF模組、USB模組、以及具有感測器延伸介面並可使用9V電池的WSN節點模組，適合廠商或使用者針對WSN進一步應用開發與整合。

《圖六　工研院自行整合開發的WSN硬體平台 》 資料來源：工研院ITRI

另外還有功能較強以ARM／Linux為主的32位元power node模組，適合想要研究通訊堆疊、或是需要快速整合不同感測器、並且以Linux系統為主開發的學界或是系統整合商。

工程應用實例：橋樑監控自動化

以前的佈建方式

台北橋橋墩的監控方式，原本採用有線加上兩個傾斜感測器，讓感測器訊號可透過延伸到橋面的纜線，讓工程人員在現場讀取，如(圖七)所示。

《圖七　有線感測方式的橋墩監控現場 》 資料來源：工研院ITRI

若需被監控的橋樑數量多，工程人員往返各檢測點的時間就會拉長，緊急狀況需在短時間內對多座橋樑進行檢測的要求便無法達到。自動化WSN橋樑監測透過統一的後端介面軟體，免牽線不用到場，簡便的附掛式佈建能夠發揮無線通訊功能的效益。

WSN橋墩監控應用

(圖八)即為三聯科技、台北科技大學、以及工研院合作的WSN應用示意圖，已在台北橋實際示範佈建。

《圖八　佈建於台北橋的WSN應用現場示意圖 》 資料來源：工研院ITRI

此WSN佈建設施使用與原本在橋墩上同型號的傾斜感測器，利用感測節點上類比轉換數位（Analog to Digital；A2D）的處理功能，將感測器的數值轉換為數位訊號以後，透過2.4GHz無線傳輸RF裝置回傳至主機端紀錄。（圖八）箭頭所標示處，即為無線感測節點的佈建位置，資料主機設置於橋頭並提供電源。為求測試數據與平台的穩定度，無線感測節點每2分鐘就由感測器收集一筆資料傳回，測量頻率以及電源消耗模式可於大量佈建時再進行最佳化調整，並按ZigBee特性進一步規劃整個應用佈建架構。

有鑑於每個橋墩都需要受到監控，工程人員把每個無線感測節點平行於橋面走向的方式佈建，以避免無線訊號被橋墩遮蔽。同一排的無線感測節點可以利用接力（Relay or Hopping）特性，協助距離資料主機較遠的節點傳送資料。由於2.4GHz頻段很容易受到水氣影響的因素，因此在實地測試時，最好是以下雨時的通訊範圍作為考量，無線裝置本身也需注意避免直接日照高溫導致運作不正常的變數。若資料主機可透過ADSL或是3G網路卡提供上網功能，工程人員則能在任意存取網路的地方，觀察所有無線感知節點的最新狀況。

WSN佈建需先現場勘驗

WSN應用環境所需關照的複雜變數可見一斑。天線及整體網路的強度常受到環境影響，包括金屬遮蔽物、水氣、高壓電流干擾等等，因此WSN佈建作業事先需作現場勘查與相關測試。但是相較於單價較無彈性的無線通訊裝置、單晶片模組、或是通訊協定，若能結合應用Domain Knowledge提供解決方案，不但進入障礙高，相對而言也可以獲得較高獲利。

結語

無線RF以及硬體平台市場競爭激烈，使用者介面的後端軟體系統以及解決方案技術非常關鍵，將會決定廠商能否在WSN領域脫穎而出。若WSN應用的解決方案提供者，能結合具有Domain Knowledge的服務提供廠商，合作由應用方面建構進入障礙，並配合相關營運模式，應可開拓另一片不同於大量生產與殺價的藍海天地。

（作者為工研院資訊通訊研究所網際網路平台架構組副經理）