前 言
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
