嵌入式網頁服務器（Embedded Web Server: EWS）所指的是在嵌入式控制器上建立一個微型的網頁伺服的服務。結合嵌入式系統的優點，使用者可以直接透過瀏覽器來取得在EWS 上的信息之外，還可以自行設計特定的控制程序。而系統發展者也可以使用簡便的網頁編輯程序來編輯要放置于EWS 上的網頁。本文探討如何在最簡易的方式及低廉的成本下有效的發展網頁服務器的系統平臺。并采用泓格科技公司的Ethernet 嵌入式控制器I-7188EX/I-8431/I8831 為硬件平臺，發展一具Web Server 架構的嵌入式控制系統，如此的系統不謹可以提供系統發展者用最簡單的方式去完成一個EWS 的控制系統的簡單模式平臺，也可以提供一個開放式的進階控制平臺，讓控制器設計者可以加入自定的控制程序，以滿足各種工業控制上具有高效能及易于設計及維護的嵌入式服務器。

前 言

1969 年因應冷戰時期，美國國防部出資BBN（Bolt, Baranet and Newman）公司架設了ARPANET 網絡。ARPANET 網絡研究計劃的目的正是希望能創造出一個通訊網路，這個網絡即使遭到部分的破壞，還是可以互相聯系，并強調「各計算機主機間平等的對等通訊」。ARPANET 網絡使用的是一種稱為分封交換的技術，把較大的數據切割成較小的封包，并且將每個封包給予各自的目的地地址。封包可以用不同的順序及路徑到達相同的目的地。到達后，再由目的地的計算機將所收到的封包予以重新組合起來。這種觀念稱之為動態路由，在網絡上的每臺主機都扮演同樣的角色。如果敵人想摧毀某一網絡聯機的話，必須摧毀附近所有的主機才能得逞。爾后ARPANET 開始對大眾公開，吸引了更多學術單位及私人企業投入研究。一九七九年美國國家科學基金會（NSF）也開始參與網絡技術研究。一九八五年撥款協助近一百所大學連上網絡，一九八六年布建 NSFNET 將全美五大超級計算機中心和各大學連結在一起，使得越來越多的學術界菁英加入了這項研究。

想讓每一臺計算機能以網絡相互連結，必須透過某種規則，因此就有所謂的通訊協議（protocol）出現。ARPANET 剛開始所采用的網絡通訊協議是NCP（network control protocol）。在網絡技術越來越復雜時，不同計算機、不同軟件、不同系統的網絡之間無法兼容的問題越來越明顯。一九七四年，后來被稱為「Internet 之父」的文特•瑟夫（Vint G. Cerf）和同伴開始研發一套能通行于所有計算機上的通訊協議，那就是現在計算機上網所使用的TCP/IP（transmission control protocol and internet protocol）。漸漸地，一個能用來儲存信息、分享信息的工具產生了，就是由勃勒李（Tim Berners-Lee）所發明的WWW（world wide web）。一九八九年勃勒李提出了在CERN 內部建立一套信息網的系統。起初并未獲得響應，但他依然展開自己的理想。一九九○年他完成了超文件傳輸通訊協議（HyperText Transport Protocol ,HTTP），計算機可以利用HTTP 在Internet 上傳輸超級鏈接文件。此外，為這些文件在Internet 上的地址做了設計，他稱這個地址為URI（universal resource identifier），這也就是目前我們所熟知的URL（uniform resource locator）。同時在一九九○年末，他也完成了類似瀏覽器的程序，并取名為World Wide Web，讓使用者可以透過此程序瀏覽他想要的數據。為了讓Web能發展得更順利，第一屆WWW 研討會于一九九四年五月二十四日在CERN 舉行。會中正式將Web 定名為World Wide Web，并且超級鏈接網頁以勃勒李所寫的超級鏈接標示語言HTML（hypertext markup language）來撰寫。

在美國高速計算機中心（Natiomal Center for Supercornputing, NCSA）兼任助理的馬克．安德森（Marc Andreesen），決定發展圖形化的接口，且能讓使用者輕易上手的瀏覽器。一九九二年，他和NCSA 里另一名同事艾利克．比那（Eric Bina），終于開發出一套新的瀏覽器，并且命名為Mosaic。Mosaic 比起當時的瀏覽器更具圖形化且較容易為一般使用者接受。此外，和其它瀏覽器一樣，也可以瀏覽HTML 文件。更特別的是，Mosaic 還加入了image（影像）的語法，也就是讓Web也可以顯示出影像圖片。雖然早先的瀏覽器也可以顯示圖片影像，但是文字與影像需要不同的檔案，而Mosaic 則可以讓文字、圖片影像都在同一個網頁中，圖形化接口及按鈕讓使用者可以更方便地瀏覽網頁。

嵌入式控制系統最初是為了工業計算機而設計，在信息產品普及與數字家電興起后，嵌入式系統已逐漸普及到我們日常生活中，從信息家電、網絡產品，到可攜式裝置，都看得到它的蹤跡。嵌入式系統的特色之一是不需要很多外接的零配件，能在小面積組件上完成特定功能，具有穩定、小尺寸等特點。過去嵌入式系統較難普及的原因，是因為集成電路和制程技術尚無法突破。由于近年來半導體電子技術發展快速，因此嵌入式系統逐漸變為功能強大而價格低廉；此外，軟件技術也不斷的進步，使得嵌入式系統的發展不再局限于使用匯編語言，且能使用更高階的程序語言來發展嵌入式系統，而實現更多型態的應用[1]。 近年來網絡快速發展，隨著WWW（ World Wide Web）持續不斷的擴張，針對WWW 發展其它方面的控制應用是受到重視的，而瀏覽器（IE、Netscape Navigator etc.）的角色也就變成最普遍的客戶端管理及監控程序。因為網頁瀏覽器可以提供圖型接口，使用者可以透過Internet 監控系統狀態。此外，遠程控制成為另一項重要的課題。遠程控制具有許多優點，例如：操作人員可以避免暴露在危險的工作環境中；可以對于遠方控制系統下達指令，而工程人員不必在第一時間抵達現場。Web-based 嵌入式控制平臺結合了嵌入式系統與網絡，除了可以提供控制系統的實時數據外，也能提供在線控制參數設定。而Web-based 嵌入式控制平臺亦可作為獨立的控制系統。使用Web-based 嵌入式控制平臺的優點很多，例如：硬件的需求性低、低成本、高穩定度、具可移植性、可連接多種工業控制設備，這是一般網頁服務器無法做到的[2][3]。 本論文不僅對嵌入式系統作深入探討，而且對www 的通訊技術亦有詳細討論，并且將以泓格科技公司的I-7188EX 為研究對象，賓務性的設計出一個嵌入式控制器之Web 服務器。并以嵌入式系統為基礎發展Web-based 嵌入式控制平臺，針對Web-based 嵌入式控制平臺架構作深入研究，探討執行效能。并以Web-based嵌入式控制平臺，實際結合分散控制模塊的整合應用，探討Web-based 嵌入式控制平臺與控制系統結合的效能表現。最后并探討本文所建構的Web-based 嵌入式控制平臺的特性與未來發展方向。

TCP/IP 通訊

TCP/IP 通訊協議組允許不同尺寸、不同計算機廠商出廠及執行不同操作系統的計算機彼此通訊。原為60 年代由美國政府資助關于封包交換（Packet switching）網絡的研究計劃，90 年代已成為計算機間使用最廣的網絡。TCP/IP 為一開放性系統，通訊協議組的定義及許多相關協議的實作，均可公開取得且只需少許費用，甚至免費。網絡協議通常以層（Layers）發展，TCP/IP 就是不同層協議的組合，一般認為是四層系統[4]，如圖1 所示： 每一層都有不同職責。以下針對每層簡略敘述：

（1）鏈接層（Link Layer）：亦稱為數據鏈結層（Data-Link Layer）或網絡接口層（Network Interface Layers）,通常包含了在操作系統中的裝置驅動程序，以及計算機中相對應的網絡適配卡。此兩部份可以處傳輸媒介連接的所有硬件問題。

圖1 TCP/IP 架構圖

（2）網絡層（Network Layer）：是扮演處里整個網絡中封包的移動，例如封包的繞送（Routing）。整個網絡層由IP（Internet Protocol）、ICMP（Internet Control Message Protocol）、IGMP（Internet Group Message Protocol）組成。

（3）傳輸層（Transport Layer）：此層替應用層提供了在兩個主機（Host）間的數據流。在TCP/IP 協議組中有兩個極大差異的傳輸協議：TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。TCP 提供兩主機間可靠的數據傳輸。所采用的方法如將應用軟件傳過來的數據分割成適當大小，再傳給網絡層；收到封包時發出確認收到的信號；設定暫停時間確定另一端已送出確認收到信號等。如此應用層便不在需要另外確認數據的可靠度。UDP 提供應用層另一較簡單的方式。僅由一臺主機送出稱為數據報（Datagram）的數據封包到另一臺主機，但并不保證送出的數據能夠到達另一臺主機。若需要額外增加可靠度須由應用層加入。

（4）應用層：此層處理應用軟件的細節。許多普通的應用軟件對于各層幾乎都有對應實作。如遠程登入、FTP（File Transfer Protocol）、SMTP（the Simple Mail Transfer Protocol）等。最后TCP/IP 協議組中有許多的協議，如圖2、圖3、圖4 分別表示不同情況下TCP/IP傳輸結構。

圖2 單一主機內部傳輸示意圖

圖3 FTP 相同網絡架構傳輸示意圖

圖4 不同架構網絡透過TCP/IP 連結架構圖

本文采用TCP/IP 通訊協議組中的TCP 通訊協議做為傳輸層（Transport Layer）主要的通訊協議，因為TCP 具有聯機導向、可信賴以及字節流的特性。聯機導向（connection-oriented）：當Server 端與Client 端建立聯機前會作數據的交換，以確定聯機的建立。信賴度：TCP 利用以下幾種方式提供信賴度：（1）數據被分解成TCP 認為最佳大小的區塊（chuck）后傳送。如下圖5 顯示之Server-Client 通訊流程：

圖5: Server-Client 通訊流程

HTTP（HyperText Transport Protocol）

HTTP（HyperText Transport Protocol）自1990 年以來就被全球信息網采用為基礎通訊協議，它是一種應用階層（Application-level）的通訊協議，特性是輕便、快速，特別適合如Web 這種分布式、合作式的超媒體信息系統。HTTP 具通用性（generic）、無記憶性（stateless），且為對象導向，HTTP 特別具有數據型態（typing），并可協商數據表征（data representation），所以依此建造的系統可以不受傳輸數據內容的影響。HTTP 雖早自1990 年起就已被普遍使用，但過去許多年并無統一規范，此項不明確的規范后來通稱為HTTP/0.9。

直到1996 年6 月一份僅供參考的文件方才由Internet Society 的HTTP Working Group 出版，稱為HTTP/1.0。HTTP/1.0 雖有正式文號（RFC1945）[5]，但僅為一臨時性文件，有效期為六個月，此文件到1996 年年底已到期。到1997 年一月，一份正式的文件，HTTP/1.1（RFC2068）[5]適時出爐，至此HTTP 才算有了一份正式的標準草案。

HTTP 規范用戶（client）與服務器（server）之間的通訊，用戶是一個程序，它按照HTTP 的規范建立一個通達服務器（另一個程序）的連結（connection）以送出其「要求」（request）；所謂「要求」就是對在某一服務器上的「資源」（resource）請其做某種動作，服務器收到要求后，則將其「回復」（response）送回。HTTP/0.9 是一個簡單的「Request/Response」通訊規范，其目的僅在傳輸原數據。HTTP/1.0主要的改進在于允許所傳輸的資料可以采取類似MIME 的格式，也就是說，可以指定所傳輸數據的格式，信息也可以允許使用「修飾語」（modifiers）改變要求與回復的運作意義。如此一來就大大的擴展HTTP 可應用的范圍。

HTTP/1.1 主要的改進在：具分層架構的代行者（hierarchical proxies）、傳送對象的暫存（caching）、常續的連結（persistent connections）、擬真主機（virtual hosts）。本論文主要發展并證明Web-Server 嵌入式系統的可行性，除了受限于硬件環境外，且絕大部分的Browser 支持HTTP/1.0，所以本論文采用HTTP/1.0 作為發展基礎。

HTTP/1.0 傳輸格式

就像大部分的網絡通訊協議，HTTP 使用client-server model：Client 端開啟1個連結（connection）并送出request message 到server 端；server 端接收到后回傳response message，此message 通常包含client 端所要求的數據，在結束傳輸后server 關閉此連結。Http/1.0 使用了許多由MIME（Mutipurpose Internet Mail Extensions）定義的格式，可參照RFC1521 文件[5]。Request 和response message格式相似，包含：（1）an initial line, （2）Message header（zero or more HTTP header fields）, （3）a blank line , （4）an optional message body （e.g. a file, or query data, or query output）。對于每一部分，將分別加以說明：Initial line：Initial request line：主要分為三個部分，method name（將于稍后提到）、request resource 的區域路徑、和HTTP 版本。基本形式如下：GET /path/to/file/index.html HTTP/1.0 在此簡單介紹HTTP/1.0 的指令集（the set of common method）。指令集可以擴充，但不能保證可以讓所有的client 端與server 端接受。而最常使用的指令有三種：GET、HEAD、POST。

（a）The GET Method：簡單來說，GET method 就是對server 端要求data（所有在request message 所要求的信息），在過程中server 端不會給予Text 型態source，而是轉換成Entity-body（message body）放入response 中；除非source 本身即是以text 文件方式儲存顯示。

（b）The HEAD Method：HEAD method 與GET method 大致相同，但是不會有Entity-Body 的部分。即使用HEAD method 對于server 端要求回傳status lines 和headers 而省略message body。若只想取得server 端source 的URI（Uniform Resource Identifier）[6]數據可使用此方法。

（c）The POST Method：在之前舊版的HTML 語法，POST method 與GET method的差異性在于前者可透過其它方式傳輸數據，例如CGI script. 目前的HTML 語法GET 與POST 皆可使用CGI script。而兩者間的差異在于傳輸數據時，GET于URL 后端加入傳送數據；而POST 則是放入Header，再回傳給client 端。此部分的差異將于2-4 小節CGI 的應用部分討論。圖6 表示HTTP message 整體架構：

圖6 HTTP 通訊格式

Initial response line（status line）：主要分為三個部分， HTTP 版本, response status code，及status code 的英文描述。基本形式如下： HTTP/1.0 200 OK，or HTTP/1.0 404 Not Found 列出常見status code 所代表的涵義，如下表 （1）Message Headers（HTTP header fields）： 整個HTTP header fields 包含：General-Header、Request-Header、Response-Header、Entity-Header。Header fields 格式遵循了一定的規范[4]，基本格式如下： field-name:SP[field-value]CRLF SP 是表示a single space;[Field-value]是表不header 內容，而CRLF 是表示結束字符（ASCII code）。 The Message Body（Entity Body）： 對于request 部分，為client 端輸入的數據或上傳的檔案；對于response 部分，為接受client 端要求，回送client 端要求的資料。而當HTTP message 包含有數據的時候，通常會有另外的Headers 描述此數據。

CGI （Common Gateway Interface）

原始的HTML 語言是設計用來展現靜態的數據，它讓人使用一種簡單的語法展現出豐富的多媒體數據，就像廣告廣告牌一樣。如果使用者需要的數據具有時效性，必需時常更新，這時該怎么辦呢? 又或者你想留下使用者的數據，讓你的網頁能跟使用者達到互動的效果，這時又該如何?

由于上述種種需求，于是就誕生了CGI。CGI 是Common Gateway Interface 的縮寫，中文翻做『共通網關接口』。它是一種標準接口程序，能讓你的網頁跟WWW server 溝通，達到跟使用者互動的效果。而且透過CGI 程序，可以讓你動態的產生網頁，秀出server 上的最新數據。當你連結到一個CGI 對象時，你取回的文件并非是一份靜態數據，而是一個藉由程序動態產生的HTML 數據流。傳回來的資料可以隨時更改，或者針對使用者的特殊查詢而有不同的反應。簡單來說，CGI 程序就是能夠動態產生WWW 網頁，并讓一般使用者經由WWW 取用系統內的數據。

CGI 本身制訂的標準有提到可以藉由環境變量來達成此目的，而且CGI 程序也有能力取得現存在各類數據庫里的數據。因此我們可以發現，CGI 可以由任何語言程序來實現，只要語言程序具有讀寫檔案的能力。直得一提的是這樣的方式也容易有安全性上的問題。圖7 為CGI 示意圖：

圖7 CGI 示意圖

目前的web-server 絕大多數都有提供執行CGI 的環境（路徑端看server 設定，一般放在cgi-bin 的路徑下）。當使用者用瀏覽器link 到一個CGI 程序時，瀏覽器會透過HTTP 這個通訊協議，送出一個請求（require）給遠程（remote）的Web server，Web server 就會跑一個HTTPd process，這個process 會去找指定的目錄下有沒有這個CGI 程序，如果有的話HTTPd 會啟動一個child process 來跑這個CGI 程序，也因此繼承了HTTPd 所有的環境變量設定。這也就是說使用者所輸入的要求會經由HTTP 通訊協議傳送到Web server 的HTTPd，再經由環境變量或標準輸入裝置（STDIN）傳遞給CGI 程序[6]。CGI 程序相關的環境變量列表于下：

嵌入式網頁服務器的設計

本節中，我們將說明嵌入式網頁服務器 （以下簡稱為EWS）并與一般的服務器做一比較。同時，也將說明建立以EWS 為平臺的控制系統的基本需求以及發展工具。

（1）一般網頁服務器 vs. 嵌入式網頁服務器：一般網頁服務器基本上都是為了標準用途所設計的 （例如：NT servers、Unix ），因此它們對系統資源的需求也相對提高，如：較多的內存、高速的處理器、具分時多任務的操作系統以及其它的資源。而典型的EWS 需求則相對的少，只要數百K 的內存、低速的處理器、單工的操作系統，所以在成本及效益上反而占了極大的優勢。EWS 通常可以用來傳遞嵌入式系統的狀況，透過瀏覽器使用者可以很容易的取得目前系統狀態、設定一級作業的執行結果。EWS 同時也可以接受使用者從瀏覽其傳送過來的命令并加以執行，達到遠程控管的效果。

（2）在線設定程序：一般的服務器設定除了提供本機上的管理程序，為了管理的方便性通常也會提供遠程瀏覽器端的管理程序，在EWS 上也擁有同樣的機制，使用者也可以透過瀏覽器從遠程直接對EWS 做相關的參數設定。藉由EWS（嵌入式網頁服務器），使用者可以透過遠程的瀏覽器針對現場的需求做不同的設定[4]，例如：網絡通訊參數的變化以及RS-232 端的通訊方式改變，這個便利性可以免除管理者必須四處奔波的窘境。進而達到管理的方便及人性化。

（3）EWS 的優勢：市面上有一些嵌入式網頁服務器，雖然號稱功能強大但卻還是免不了需要使用者自行編寫程序語言來開發系統。本EWS 系統除了支持使用者在建立網頁服務器時不須編寫任何語言外（基本模式），它還提供更具有彈性的方式讓使用者自行去修改并產生自己的服務器（自訂網頁中的Script 規則）（進階模式）。

EWS 的運作的原理及系統需求

一般網頁服務器主要是設計透過快速的處理器來顯示靜態網頁，而EWS 的設計重點卻是如何在有限的資源中達到這些要求。因此，以下的重點是必須考慮。

（1）通訊協議的格式：HTTP/1.0 針對每一個聯機提供信息的交換，透過瀏覽器傳送相關的信息到EWS，在EWS 做出反應后就關閉此聯機。因此，設計的過程中只要考慮傳送的信息是什么，而后續的動作待EWS 接手后，就可以不去關注，EWS 會將此一聯機需求忠實的執行完畢并關閉此一聯機。

（2）EWS 提供的API：EWS 必須提供設計人員相關的響應機制并且提供HTML網頁傳送到瀏覽器端的服務[5]。這個部份的需求的功能，可以采用CGI 的方式來達成。在這種模式下，每一個透過URL 呼叫CGI 的聯機將被導引到CGI 的處理程序中，透過CGI 的方式將會使得瀏覽器端可以呼叫及使用EWS 中的函式，并將執行結果回傳到瀏覽器。為了達到這種功能，我們必須在符合標準的CGI格式下發展數個CGI 函數[6]，供給瀏覽器端的不同需求。

（3）EWS 的結構：基于上一節的討論，整個發展的EWS 包含3 個部份：HTTP 服務、CGI 服務函數、設定接口。整個結構如圖8 所示：

圖8: EWS 結構

本結構圖最重要的一個部份在于提供HTTP 服務，此服務可以接收來自瀏覽器端的要求，而這個服務的來源則必須符合基本的HTTP 規格才可以。一般的網頁服務器，在接收到要求時就會立刻建立一個聯機，而EWS 因為是單工操作系統，所以它的運作方式完全不同，它會先將要求排入一個等待隊列，然后一個一個去完成。因此，當聯機數大于一個以上時，因為系統資源的關系，同時建立聯機的方式為不可行的，所以對于HTTP 的服務會采用在狀態記號方式來處理。

設定接口的部份，將會提供瀏覽器操作接口的方式以設定EWS 的網絡相關參數，此接口提供使用者在遠程可以直接的對EWS 做網絡參數的在線設定。CGI函數，網頁文件分為靜態及動態顯示文件，靜態文件部分基本上可以直接由HTTP 服務透過檔案系統傳遞到瀏覽器端，動態文件則必須先經過解譯的程序將網頁文件中需要以動態顯示的部份，由CGI 函數取得后傳送到瀏覽器端。檔案系統，提供EWS 對檔案存取的權利，基本上提供檔案的開啟、讀取以及關閉這三種功能。透過這種檔案系統，我們可以直接在EWS 上直接對以下檔案類型做這三項動作：GIF、JPG、BMP、HTM。

EWS 的處理程序

在圖9 中明顯的呈現出HTTP 服務對聯機所執行的流程及步驟。為了達到在單工操作系統中接受多個聯機需求的目的，必須在此系統上架構排程序的作業程序。在此系統中，采用一個隊列專門來儲存每一個要求的聯機，來決定新的聯機是要阻斷或是繼續接受。而整個程序中，為了提供更大的彈性，此程序切割成兩個部份，一個是固定不變的WebL_100.Lib 另外一個是User.c。其中，WebL_100.Lib為整個嵌入式網頁服務器的重心，它提供了HTTP 的服務以及些其它的TCP/IP處理機制。而User.C 為此服務器開放出來讓使用者可以自行設計并決定響應從Port 80 傳入的聯機要求[7]。

圖9: EWS 運作方式

以下說明每一個狀態的功能：

Block 1: 此區塊會將所有的變量、封包信息以及網絡環境初始化。

Block 2: 此區塊包含兩個函數，這兩個函數提供給設計者自行編寫自訂的程序。

Web_Init（）：設計人員可以在此函數中加入想要使用的變量或命令，而這些加進去的程序在服務器啟動后只會被執行一次，設計者可以加入一些只要執行一次的動作命令。例如：初始化通訊端口。

Web_Loop（）：設計人員可以在此函數中加入想要使用的命令，而這些加進去的程序在服務器啟動后會在主循環中不斷被執行次，設計者可以加入一些要重復不斷執行的命令在這個函數中。例如：掃描通訊端口狀態。

Block 3: 檢查TCP/IP 通訊端口是否有數據，如果有數據，會向下執行Block5。否則的話程序會往Block4 執行。

Block 4: 更新I-7188E 上的七段顯示器，并檢查看門狗機制并回到Block 2 檢查TCP/IP 是否有資料進來。

Block 5: 根據來自不同Port 的需求聯機我們做不同的反應機制。

Port 80: 如果連現需求中呼叫CGI 函數程序會執行到 Block 6。如果只是單純的網頁或是圖形的話程序會執行到 Block 7。

Others: .其它不同Port 的需求聯機。如：Ping。

Block 6: 依照瀏覽器端的呼叫函數，將變量傳遞到對應的函數中。以下為此方塊提供的CGI 函數。 CGI_DPAGE（） CGI_USER（） PRINT_PAGE（）

Block 7: 將數據（網頁）傳送到瀏覽器端。完成后，程序將回到Block 2。

軟件與硬件的需求

在本研究中采用了由泓格科技公司所研發之型號I-7186EX/I-7188EX 的嵌入式控制器作為控制系統的執行平臺，如圖10 所示。它的運算核心采用了由x86 微處理器，運算頻率為80MHz，不支持浮點運算能力，內建有3 個定時器 （Timer）及1 個看門狗定時器（Watchdog Timer），同時支持軟件及硬件的中斷功能。在通訊部份則支持RS232/485、Ethernet 三種接口，可透過RS232 或Ethernet 下載至嵌入式控制器上進行應用及驗證。至于在儲存裝置上，它提供了2Kbytes 的EEPROM 存放硬件開機時所需的相關數據；512Kbytes 的Flash ROM 則規劃一部份作為嵌入式操作系統之用，其余的部份則用來存放使用者所自行開發的應用程序，同時可透過軟件方式進行更新的特性，更滿足了使用者未來在此系統上進行控制器設計時，反復修改控制參數并下載至控制器驗證的需求；512Kbytes 的SRAM 則可用來存放實驗過程中所獲得的數據。

在嵌入式操作系統的部份，采用了由泓格科技公司所自行研發的MiniOS7（dos-like）操作系統，整體上來說，它的系統架構相似于個人計算機上的DOS 操作系統，其單工的作業環境可以確保使用者所開發的應用程序得以獨占系統的執行權，再搭配硬件上的RTC （Real-Time Clock），構成了一實時的作業環境；I/O 的擴充方面，I-7186EX/7188EX 嵌入式控制器提供了1 個X board 的I/O擴充插槽，可視不同的控制應用場合添加相關的控制子板，因此，在I/O 的擴充能力上勢必更具有彈性，方能滿足不同的應用需求。值得注意的是，每一EtherNet的嵌入式控制器都有RS-485 通訊端口，因此控制器都可以透過串行通訊端口去控制泓格公司之一系列之分散控制模塊DCON 系列產品，例如I-7000, I-8000 及I-87K 之泓格自定命令格式之模塊。

圖10 I-7188EX 嵌入式控制器及X board 子卡

嵌入式網頁服務器的設計流程

如圖11 所示為本研究中所建立的嵌入式控制器的Web server 之開發流程。其步驟如下： Choice Hardware 選擇要與EWS 連接的硬件控制器，讓EWS 作為硬件控制器與瀏覽器端的信息交換中心 Wiring Hardware 將整個硬件線路建置好，包含網絡及控制器的連接 Design Web page for purpose 針對需求設計相關的網頁 Create the firmware of EWS 自訂由瀏覽器端接收命令時，要做的響應機制并使用編譯器建立EWS Download files and run EWS 下載相關的檔案（HTM、Pictures）以及EWS 韌體并執行程序

圖11: EWS 設計流程

實作探討

本節將以為了發展嵌入式網頁服務器（EWS），發展工具如下：硬件部分：I-7188EX（作為EWS）、I-7021、I-7012、I-7060D（作為網頁服務器控制的設備）[8]。軟件部分是采用寶蘭的 Turbo C++1.01（主程序編譯器）去設計嵌入式控制器之應用韌體程序，而微軟的FrontPage 是用一個網頁編輯軟件。但值得注意的是泓格科技的嵌入式控制器的MiniOS7 操作系統及MiniOS7 Utility（下載應用程序）則是整個控制器的核心。在以下本論文將把EWS 的應用架構分為二種，即是基本模式架構與進階模式架構，而基本應用模式是架構在一個已經設計好的內定fireware 及使用者自行設計之網頁，最后只要將內定fireware 及網頁透過MiniOS7 Utility 下載至目標硬件應用即可。而進階應用模式是指EWS 可以提供一個使用者自行加入控制程序，提供一個可以客制化之EWS 韌體，再加上使用者自行設計之網頁，即可以架構出一個完全客制化EWS 系統。

基本模式架構說明

基本模式，提供設計人員在開發的過程中完全不需要編寫到C 語言的平臺，能以最快速的時間中開發適合的EWS，圖12 為利用泓格公司所生產的分布式控制模塊I-7012 I-7021 I-7017 I-7060 來作為EWS 基本模式實作系統。

在EWS 系統平臺中，主要組成軟件組件有以下幾部分：

1.主程序（Firmware），提供HTTP 服務。

2.網頁組件。含HTM、GIF、JPG、BMP 組件。

3.CGI 函式及響應機制，包含在Firmware 里面，提供CGI 相關函式可供應用。

在基本模式中提供應用系統的核心,使用者只需將所設計的網頁下載至控制器上即可。在本文中設計系統所需的網頁內容,如圖五，Readinfo.htm。透過I-7188E內嵌式網頁服務器所內建的解譯機制，設計人員只要熟知如何設計網頁，也可以很簡單的透過內建的解譯機制，直接控制或讀取連接在I-7188E 上的工業控制模塊的狀態。透過這個方式，可以快速有效建置Ethernet 嵌入式控制系統在網頁伺服技術上的應用。圖13 為實際執行的畫面

圖12: 實作線路連接圖

圖13: 網頁內容及實際執行解譯命令運作圖階模式架構說明

進階模式，提供設計人員在開發的過程中想要自行控制接收到HTTP 需求聯機后所做的響應機制，此模式開放圖14 中的User.C 部分，讓設計人員對此嵌入式網頁服務器有更大的彈性空間。同樣的進階模式的EWS 主要組成軟件組件有以下幾部分：

1.主程序（Frimware）。

2.提供HTTP 服務。

3.網頁組件，含HTM、GIF、JPG、BMP 組件。

4.CGI 函式及響應機制，包含在Firmware 里面，有CGI 可供呼叫以及相關的函數。

其中在主程序（Frimware）部份，另外開放User.C 供設計人員自行編寫程序。在本系統的實作中，會使用到發展的網頁直譯器，將動態網頁中的動態命令字符串直接解譯并執行然后使用EWS 所取得的值或參數來取代這些動態命令，系統發展者可根據這些參數來做監控系統的應用。如圖14，例如：改變命令字符串并用EWS 從通訊端口中取得的值取代此動態命令。透過解譯程序，將動態命令從通訊端口輸出并取得回傳值然后產生一新的靜態網頁。最后，再將此新網頁回傳到瀏覽器端。執行結果如圖 15。

圖14 客自化程序設計及對應的網頁設計

圖15: 進階模式解譯命令及執行結果

EWS 效能分析

由于EWS 是屬于微型的網頁服務器，因此其效能與下列要的變因有關系，網頁內容、聯機數目，都是決定此EWS 系統重要的因素。以下將針對此三變因作數據上的測試。 網頁內容（聯機數目為一）： 測試結果 數據圖形：

聯機數目（網頁內容為純文字） 測試結果

結 論

由以上結果得知，整個網絡運行的效能，影響最大的部份取決于單一網頁傳遞數據量的大小。如果單一網頁的數據龐大，針對每一個聯機從開始回映到結束響應的時間將會大為增加。嵌入式網頁服務器主要的功能大多是針對顯示控制器的狀態為主，因此聯機的反應時間快慢只要是瀏覽器端可以接受的范圍就可以。而配合I-7188E 嵌入式網頁服務器，有下列的優點：

1.系統建置的快速，結合I-7188E所提供的函式庫，能在最短的時間中設計出需求的功能。比起傳統式的網頁服務器需要花費大量的時間，更適合工業控制上應用網頁監控設計人員。

2.低成本與高效率，整個建置系統的成本，并提供WebL_100.Lib 函式庫提供系統發者所需的功能。因此，在軟件開發成本上已經為設計人員做最有效的抑制。

3. 突破傳統的Client-Server，傳統的Client-Server 機制，通常必須在客戶端安裝特定的Client 軟件。在使用對象固定的狀況下，這并不會照成多大的困擾。一旦Clent對象不確定而又無法一一安裝，這時透過I-7188E 架設的網頁服務器就可以適時的發揮功效，目前的PC 都已內建瀏覽器程序，只要將Client 的PC 與I-7188E內嵌式網頁服務器一同架設在網絡上，這個問題即可迎刃而解。

本文所探討的Ethernet 嵌入式控制器之WWW 應用平臺，不但突破以往工業控制無法直接以Web 方式操控的限制，更提供多種不同模式的發展平臺。應用此發展平臺，除了無遠弗屆的Web 操作外，還能與C 語言結合創造出更彈性的控制系統。

參考文獻

McCombie, B., “Embedded Web servers now and in the future,” Reat-Time Magazine, no.1 March 1998, pp. 82-83. Wilson, A., “The Challenge of embedded Internet,” Electronic Product Design,January 1998,pp. 31-2, 34. Ian Agranat, “Embedded Web Servers in Network Devices,” CommunicationSystem Design, March 1998, pp. 30-36. W.Richard Stevens, TCP/IP Illustrated Volume1, Addison－Wesley Publishing Company. ,1994. C. Wellens, K. K. Auerbach, “Towards Useful Management,” The Simple Times,4（3）:1-6, July 1996. W3C,”HTML 4.0 Specification,” Internet Draft REC-html40-19980424, HTML Working Group, Apr 1998. Edwards, Nigel, Owen Rees, “Performance of HTTP and CGI,” ASNA. ICPDAS [7188E/843X/844X/883X/884X TCP/IP Library User’s Manual] , Taiwan,2001/07 ICPDAS [7188EN Hardware User’s Manual] , Taiwan, 2001/07