如何讓使用者可以方便的從一個入口平台上獲取這些資訊是串起整個應用服務的重要一環，於是Web Service變成最有可能的解決方案之一。
WTRS在2008年第一季對無線感測網路技術的預測評估報告中樂觀的推論在2009年無線感測網路(Wireless Sensor Networks, WSN)相關應用模組的年出貨量會突破1億大關。WSN相關應用數量的擴張在接下來幾年內預估會以倍數方式快速成長。在大量搭配著各式各樣感測元件的WSN硬體裝置在我們生活週遭環境中快速佈建起來時，你能想像我們的生活型態會因為這些感測資訊的大量提供而產生什麼樣的影響與變化嗎？
感測情境
試著想像一下，如果在未來環境裡，大量的感測系統建置已相當完備，當你每日起床準備出門時，你都可以輕易地透過任何形式的網路終端設備得到佈建在目的地的感測器所擷取到的資訊，可能包含了即時的平均溫濕度及今日可能的溫濕度變化預估等等，提供你外出時穿衣的選擇參考。出門時也可透過預定的方式，將沿路地區感測系統的下雨觀測結果以警報方式傳送給你，提醒你出門時將雨具帶上。或許你開車，感測系統會將你先前所預定的幾個可能經過路口的即時車流速度在指定的時間以預報的方式提供你作為行車路徑的選擇參考。另外，像最近颱風季節剛過，颱風來時狹帶著大雨可能帶來不少災情。或許你關心遠在南部的老家有無受到大雨的威脅，於是連上感測網路系統去搜尋老家附近是否有相關的雨量偵測或是河道中是否有水位偵測的感測器佈建，如果有，便可要求感測系統提供相關的觀測資訊或是量測數值，以供瞭解當地的降雨及河流排水情形是否會危及家裡人的安全。或是你已從新聞裡頭知道家鄉地區正在淹水，想進一步了解特定地區的實際狀況也可透過這個感測網路系統來搜尋是否在當地有攝影機可提供相關的即時影像資訊來確定災情的嚴重與否。
這些情境很可能在不遠的未來就能實現，但在此先讓我們來看看要有這樣一個系統需要具備那些條件。由於在我們生活的環境裡像是溫濕度偵測、降雨偵測、車流速度偵測、河流水位偵測及影像擷取系統等等都不斷的在進行建置與佈建。因此相關感測資訊內容的提供自然不是太大的問題。雖然對於一種服務來說，基礎建設是很重要的一環，但以服務能夠提供的角度來看，也許要達到很普遍的感測器佈建時程要拉得久一些，但就服務內容來看，感測器的多樣化及佈建的範圍大小僅是量的問題，只要有需求的刺激，感測器系統的基礎建設想必能夠加速的進行。
整合服務平台的必要性
反過來說，目前得面臨的問題反而是，在大量的感測器基礎建置需求下，沒有一個廠商能夠獨立完成夠多樣及佈建範圍夠廣的感測器系統建置，勢必要透過眾多廠商同時投入才有辦法達成任務，但如何讓不同廠商所建置的感測系統能夠都提供出來整合成一個大系統來提供大範圍的整合服務，則勢必要有一個共通的整合服務平台才能夠達到目的。簡單的來說，雖不要求所有的感測網路服務都由同一個系統提供，但至少要能在各應用服務系統間相互分享在各個區域裡所建置的感測器及從這些感測器上所獲得的感測資訊，相關的應用服務才能做大。故不但要有一個共通感測資料處理平台的存在，讓各系統間的資料可以流通，而且還要要求各系統的感測器都說同樣的語言，如此才可藉由後端系統直接對到感測器來進行資料內容的處理或更進一步來控制感測器的行為。
除此之外，如何讓使用者可以方便的從一個入口平台上獲取這些資訊則是串起整個應用服務的重要一環，於是Web Service變成最有可能的解決方案之一。故在這個時間點上，WSN的前端網路技術已逐漸成熟可以開始往量的發展上來進行，下一步似乎要看後端應用服務的平台是否能早日準備妥當，以因應大量前端感測網路建置後接下來的感測資料分享與擴大應用服務範圍的挑戰。
Sensor Web概念
上述的應用服務情境，早在2003年OGC(Open Geospatial Consortium)所提出來的”Sensor Web”概念中，就已將制訂感測網路的共同標準界面的想法揭露出來。OGC是一個以訂定地理資訊服務及定位服務標準為目標的國際組織，早在1980年代中期因為要整合各地區的地理資料系統(Geographic Information System, GIS)，便開始邀集各方相關的政府機關、業者或學界來參與這方面標準的討論及制定工作。OGC所提出的Sensor Web的概念其實就是要將實體生活中的感測器硬體跟普及化的網路串接起來，讓使用者可以簡單的透過Web作為窗口來找到使用者感興趣區域裡的各種型態的感測器，並且可以藉由Web的操作來擷取並利用這些感測器資料，以增進人們生活的便利。下圖2為OGC用來描述此一概念的說明。
圖2. OGC所提的Sensor Web概念。
(資料來源：OGC white paper)
後來，一直到了2006年OGC開始的Web Services – Phase 4(OWS4)的相關應用先期測試中，才以Sensor Web Enablement(SWE)的規劃將Sensor Web的概念進行落實。OGC裡共有13個標準工作小組，其中SWE標準工作小組主要針對各感測系統間的互通性界面(Interoperability Interfaces)及感測資料的編碼(Encoding)工作，來主導及推動相關標準的制訂與相關測試平台的建立。SWE的目標，是希望達到讓使用者能透過Web的界面來進行感測節點的搜尋、感測資料的擷取及感測節點控制的功能。故在OGC所制訂的SWE標準內容裡，包含了系統的實體功能項目”界面模組”的部分以及資料交換格式的”資料編碼”兩大類共七個主要項目。目前有五個項目的標準訂定已有了初版的標準文件發行，僅剩餘兩個項目尚未完成。SWE標準所訂定的七個目標項目及其功能說明如下：
* Sensor Observation Service(SOS)：此標準主要提供進行感測器量測工作及感測資料擷取的服務，透過SOS模組的窗口，使用者可以從系統中得到所需要的感測資料。此部分標準於2007年10月完成第1.0版的制訂。
* Sensor Planning Service(SPS)：此標準主要提供使用者在終端進行感測資料擷取的工作排程服務。使用者一旦註冊此服務，系統便會自動安排感測節點的工作，並在所預定的時間點進行感測資料的收集工作。此部分標準於2007年8月完成第1.0版的制訂。
* Sensor Alert Service(SAS)：此標準主要提供使用者來設定感測事件警報的服務。使用者一旦設定完成，當所指定的感測資料達到警報發送的條件時，使用者便可得知警報訊息。此部分標準尚在制訂中，目前僅有第0.9版的相關文件提供(2007年5月)。
* Web Notification Service(WNS)：此標準主要提供系統的通知訊息給在終端的使用者，包含排程服務完成通知服務，感測事件警報的通知服務等。此部分標準尚在制訂中，目前僅有第0.1版的相關文件提供，算是這幾個標準中制訂進度較緩慢的項目。
* Observations and Measurements(O&M)：此標準主要在描述感測資料的觀測與量測模型及所獲取資料內容的描述方法。此部分標準已於2007年12月完成第1.0.0版的制訂。
* Sensor Model Language(SensorML)：此標準主要以一般化的模型及XML語法來進行感測器特性與功能的描述。透過共同語法的描述，系統才有辦法辨識各感測器元件的性質及其所能提供的感測資料型態。此部分標準於2007年7月完成第1.0.0版的制訂。
* Transducer Markup Language(TML)：此標準在提供感測資料的轉換描述，並藉由將感測資料與時間及地理位置資訊結合，作為系統準確判斷事件原委的參考，以便提供準確的資料作為決策選擇的依據。此部分標準於2007年7月完成第1.0.0版的制訂。
根據這些標準項目的分工，前四項為建立Sensor Web基礎服務的主要工作模組，透過這些模組所提供的應用程式界面，可以讓使用者透過Web來得到進行感測器搜尋、感測器資料擷取、感測器工作指派、感測資料警示狀況設定及訊息發報通知等服務。後三項的編碼格式標準則是相對的提供了上述服務在操作時的感測器特性描述、感測資料格式內容以及感測資料轉換的相關資訊，以利各種不同的感測元件可以整合在同一個系統中。SWE的內容可以簡單以圖3來說明各標準項目彼此之間的關聯。
以共通語言實現感測情境
有了這些標準，如何能夠發展一個系統來實現我們一開始所描述的生活情境呢？首先，有了SensorML、TML及O&M等相關的共通語言，系統自然就能得知那個地方有那些型式的感測器資源來提供給使用者查詢及利用，於是我們在情境中所指定要取得目的地的溫濕度資料，上班途中行經路口的車流速度，災區河水的水位情形以及家附近淹水情況的影像資訊就可透過統合的系統傳送到使用者手上。而系統中的SOS模組就是用來協助我們獲取感測資料的窗口，讓使用者可透過Web界面直接得到感興趣的感測資料。系統上的SPS模組則是可供使用者設定在指定時間進行指定感測器的資料擷取，並透過SOS將資料送至使用者手上，情境中目的地的溫濕度資料及路口車流速度資料就可以用這種方法來取得。而系統裡的SAS模組則是用來協助使用者進行上班沿途下雨情形的判斷及負責發送下雨警報到系統上。最後，再藉由WNS模組來將SPS模組及SAS模組所得到的訊息告知使用者。所以有了這樣的應用服務平台，我們所談的未來情境就可能輕鬆透過Web的界面來實現。
未來對於SWE標準的開發，可預期的將對WSN的相關應用發展產生不少的影響。對各種感測應用系統的建置廠商來說，它無疑是一個最好的整合平台來將各地區不同性質的感測器系統串接起來，以提供使用者更多元的感測應用服務，其所強調的就是一個分享的概念，透過網路功能及系統分享來將服務無限延伸。對要跨入這個領域的系統整合廠商來說，它讓感測網路應用服務的跨入門檻降低，因為標準的平台提供了完整的感測網路基礎運作服務功能，讓開發人員能夠花較少的時間來完成感測應用相關服務系統的設計與開發工作，亦是一種加速感測應用服務在短時間內迅速普遍的最好方法，也是政府在推動無所不在運算普及的最有利條件。就WTRS對未來感測應用服務樂觀的的預估來看，WSN元件出貨量的提升與應用服務的推廣自然是相輔相成的。當然，對於最大贏家的使用者來說，所有的感測應用服務都能夠在網路上輕鬆獲得，誰說我們未來的生活不會因為感測網路的興起而有巨大的改變呢？難怪早在2003年時，無線感測網路技術便被預測是未來改變世界的十大技術之首。從這裡，你看見未來生活的模樣了嗎？
(本文作者為財團法人資訊工業策進會 網路多媒體研究所 代副主任)
WTRS在2008年第一季對無線感測網路技術的預測評估報告中樂觀的推論在2009年無線感測網路(Wireless Sensor Networks, WSN)相關應用模組的年出貨量會突破1億大關。WSN相關應用數量的擴張在接下來幾年內預估會以倍數方式快速成長。在大量搭配著各式各樣感測元件的WSN硬體裝置在我們生活週遭環境中快速佈建起來時，你能想像我們的生活型態會因為這些感測資訊的大量提供而產生什麼樣的影響與變化嗎？
感測情境
試著想像一下，如果在未來環境裡，大量的感測系統建置已相當完備，當你每日起床準備出門時，你都可以輕易地透過任何形式的網路終端設備得到佈建在目的地的感測器所擷取到的資訊，可能包含了即時的平均溫濕度及今日可能的溫濕度變化預估等等，提供你外出時穿衣的選擇參考。出門時也可透過預定的方式，將沿路地區感測系統的下雨觀測結果以警報方式傳送給你，提醒你出門時將雨具帶上。或許你開車，感測系統會將你先前所預定的幾個可能經過路口的即時車流速度在指定的時間以預報的方式提供你作為行車路徑的選擇參考。另外，像最近颱風季節剛過，颱風來時狹帶著大雨可能帶來不少災情。或許你關心遠在南部的老家有無受到大雨的威脅，於是連上感測網路系統去搜尋老家附近是否有相關的雨量偵測或是河道中是否有水位偵測的感測器佈建，如果有，便可要求感測系統提供相關的觀測資訊或是量測數值，以供瞭解當地的降雨及河流排水情形是否會危及家裡人的安全。或是你已從新聞裡頭知道家鄉地區正在淹水，想進一步了解特定地區的實際狀況也可透過這個感測網路系統來搜尋是否在當地有攝影機可提供相關的即時影像資訊來確定災情的嚴重與否。
這些情境很可能在不遠的未來就能實現，但在此先讓我們來看看要有這樣一個系統需要具備那些條件。由於在我們生活的環境裡像是溫濕度偵測、降雨偵測、車流速度偵測、河流水位偵測及影像擷取系統等等都不斷的在進行建置與佈建。因此相關感測資訊內容的提供自然不是太大的問題。雖然對於一種服務來說，基礎建設是很重要的一環，但以服務能夠提供的角度來看，也許要達到很普遍的感測器佈建時程要拉得久一些，但就服務內容來看，感測器的多樣化及佈建的範圍大小僅是量的問題，只要有需求的刺激，感測器系統的基礎建設想必能夠加速的進行。
整合服務平台的必要性
反過來說，目前得面臨的問題反而是，在大量的感測器基礎建置需求下，沒有一個廠商能夠獨立完成夠多樣及佈建範圍夠廣的感測器系統建置，勢必要透過眾多廠商同時投入才有辦法達成任務，但如何讓不同廠商所建置的感測系統能夠都提供出來整合成一個大系統來提供大範圍的整合服務，則勢必要有一個共通的整合服務平台才能夠達到目的。簡單的來說，雖不要求所有的感測網路服務都由同一個系統提供，但至少要能在各應用服務系統間相互分享在各個區域裡所建置的感測器及從這些感測器上所獲得的感測資訊，相關的應用服務才能做大。故不但要有一個共通感測資料處理平台的存在，讓各系統間的資料可以流通，而且還要要求各系統的感測器都說同樣的語言，如此才可藉由後端系統直接對到感測器來進行資料內容的處理或更進一步來控制感測器的行為。
除此之外，如何讓使用者可以方便的從一個入口平台上獲取這些資訊則是串起整個應用服務的重要一環，於是Web Service變成最有可能的解決方案之一。故在這個時間點上，WSN的前端網路技術已逐漸成熟可以開始往量的發展上來進行，下一步似乎要看後端應用服務的平台是否能早日準備妥當，以因應大量前端感測網路建置後接下來的感測資料分享與擴大應用服務範圍的挑戰。
Sensor Web概念
上述的應用服務情境，早在2003年OGC(Open Geospatial Consortium)所提出來的”Sensor Web”概念中，就已將制訂感測網路的共同標準界面的想法揭露出來。OGC是一個以訂定地理資訊服務及定位服務標準為目標的國際組織，早在1980年代中期因為要整合各地區的地理資料系統(Geographic Information System, GIS)，便開始邀集各方相關的政府機關、業者或學界來參與這方面標準的討論及制定工作。OGC所提出的Sensor Web的概念其實就是要將實體生活中的感測器硬體跟普及化的網路串接起來，讓使用者可以簡單的透過Web作為窗口來找到使用者感興趣區域裡的各種型態的感測器，並且可以藉由Web的操作來擷取並利用這些感測器資料，以增進人們生活的便利。下圖2為OGC用來描述此一概念的說明。
圖2. OGC所提的Sensor Web概念。
(資料來源：OGC white paper)
後來，一直到了2006年OGC開始的Web Services – Phase 4(OWS4)的相關應用先期測試中，才以Sensor Web Enablement(SWE)的規劃將Sensor Web的概念進行落實。OGC裡共有13個標準工作小組，其中SWE標準工作小組主要針對各感測系統間的互通性界面(Interoperability Interfaces)及感測資料的編碼(Encoding)工作，來主導及推動相關標準的制訂與相關測試平台的建立。SWE的目標，是希望達到讓使用者能透過Web的界面來進行感測節點的搜尋、感測資料的擷取及感測節點控制的功能。故在OGC所制訂的SWE標準內容裡，包含了系統的實體功能項目”界面模組”的部分以及資料交換格式的”資料編碼”兩大類共七個主要項目。目前有五個項目的標準訂定已有了初版的標準文件發行，僅剩餘兩個項目尚未完成。SWE標準所訂定的七個目標項目及其功能說明如下：
* Sensor Observation Service(SOS)：此標準主要提供進行感測器量測工作及感測資料擷取的服務，透過SOS模組的窗口，使用者可以從系統中得到所需要的感測資料。此部分標準於2007年10月完成第1.0版的制訂。
* Sensor Planning Service(SPS)：此標準主要提供使用者在終端進行感測資料擷取的工作排程服務。使用者一旦註冊此服務，系統便會自動安排感測節點的工作，並在所預定的時間點進行感測資料的收集工作。此部分標準於2007年8月完成第1.0版的制訂。
* Sensor Alert Service(SAS)：此標準主要提供使用者來設定感測事件警報的服務。使用者一旦設定完成，當所指定的感測資料達到警報發送的條件時，使用者便可得知警報訊息。此部分標準尚在制訂中，目前僅有第0.9版的相關文件提供(2007年5月)。
* Web Notification Service(WNS)：此標準主要提供系統的通知訊息給在終端的使用者，包含排程服務完成通知服務，感測事件警報的通知服務等。此部分標準尚在制訂中，目前僅有第0.1版的相關文件提供，算是這幾個標準中制訂進度較緩慢的項目。
* Observations and Measurements(O&M)：此標準主要在描述感測資料的觀測與量測模型及所獲取資料內容的描述方法。此部分標準已於2007年12月完成第1.0.0版的制訂。
* Sensor Model Language(SensorML)：此標準主要以一般化的模型及XML語法來進行感測器特性與功能的描述。透過共同語法的描述，系統才有辦法辨識各感測器元件的性質及其所能提供的感測資料型態。此部分標準於2007年7月完成第1.0.0版的制訂。
* Transducer Markup Language(TML)：此標準在提供感測資料的轉換描述，並藉由將感測資料與時間及地理位置資訊結合，作為系統準確判斷事件原委的參考，以便提供準確的資料作為決策選擇的依據。此部分標準於2007年7月完成第1.0.0版的制訂。
根據這些標準項目的分工，前四項為建立Sensor Web基礎服務的主要工作模組，透過這些模組所提供的應用程式界面，可以讓使用者透過Web來得到進行感測器搜尋、感測器資料擷取、感測器工作指派、感測資料警示狀況設定及訊息發報通知等服務。後三項的編碼格式標準則是相對的提供了上述服務在操作時的感測器特性描述、感測資料格式內容以及感測資料轉換的相關資訊，以利各種不同的感測元件可以整合在同一個系統中。SWE的內容可以簡單以圖3來說明各標準項目彼此之間的關聯。
以共通語言實現感測情境
有了這些標準，如何能夠發展一個系統來實現我們一開始所描述的生活情境呢？首先，有了SensorML、TML及O&M等相關的共通語言，系統自然就能得知那個地方有那些型式的感測器資源來提供給使用者查詢及利用，於是我們在情境中所指定要取得目的地的溫濕度資料，上班途中行經路口的車流速度，災區河水的水位情形以及家附近淹水情況的影像資訊就可透過統合的系統傳送到使用者手上。而系統中的SOS模組就是用來協助我們獲取感測資料的窗口，讓使用者可透過Web界面直接得到感興趣的感測資料。系統上的SPS模組則是可供使用者設定在指定時間進行指定感測器的資料擷取，並透過SOS將資料送至使用者手上，情境中目的地的溫濕度資料及路口車流速度資料就可以用這種方法來取得。而系統裡的SAS模組則是用來協助使用者進行上班沿途下雨情形的判斷及負責發送下雨警報到系統上。最後，再藉由WNS模組來將SPS模組及SAS模組所得到的訊息告知使用者。所以有了這樣的應用服務平台，我們所談的未來情境就可能輕鬆透過Web的界面來實現。
未來對於SWE標準的開發，可預期的將對WSN的相關應用發展產生不少的影響。對各種感測應用系統的建置廠商來說，它無疑是一個最好的整合平台來將各地區不同性質的感測器系統串接起來，以提供使用者更多元的感測應用服務，其所強調的就是一個分享的概念，透過網路功能及系統分享來將服務無限延伸。對要跨入這個領域的系統整合廠商來說，它讓感測網路應用服務的跨入門檻降低，因為標準的平台提供了完整的感測網路基礎運作服務功能，讓開發人員能夠花較少的時間來完成感測應用相關服務系統的設計與開發工作，亦是一種加速感測應用服務在短時間內迅速普遍的最好方法，也是政府在推動無所不在運算普及的最有利條件。就WTRS對未來感測應用服務樂觀的的預估來看，WSN元件出貨量的提升與應用服務的推廣自然是相輔相成的。當然，對於最大贏家的使用者來說，所有的感測應用服務都能夠在網路上輕鬆獲得，誰說我們未來的生活不會因為感測網路的興起而有巨大的改變呢？難怪早在2003年時，無線感測網路技術便被預測是未來改變世界的十大技術之首。從這裡，你看見未來生活的模樣了嗎？
(本文作者為財團法人資訊工業策進會 網路多媒體研究所 代副主任)
