An embedded web server (EWS) refers to a miniature web server service built on an embedded controller. Combining the advantages of embedded systems , users can directly access information on the EWS through a browser and design their own specific control programs. System developers can also use simple web page editing programs to edit the web pages to be placed on the EWS. This article explores how to effectively develop a web server system platform in the simplest and most cost-effective way. Using ICP DAY's Ethernet embedded controllers I-7188EX/I-8431/I8831 as the hardware platform, an embedded control system with a Web Server architecture is developed. This system not only provides system developers with a simple platform to complete an EWS control system in the simplest way, but also provides an open, advanced control platform, allowing controller designers to add custom control programs to meet the needs of various industrial control applications requiring high performance and easy design and maintenance of embedded servers.
Foreword
In 1969, in response to the Cold War, the U.S. Department of Defense funded BBN (Bolt, Baranet, and Newman) to build the ARPANET network. The ARPANET research program aimed to create a communication network that could maintain interconnectivity even after partial damage, emphasizing "equal peer-to-peer communication between computer hosts." ARPANET used a technique called packet switching, which broke large data packets into smaller packets and assigned each packet its own destination address. Packets could reach the same destination in different orders and along different paths. Upon arrival, the destination computer would reassemble the received packets. This concept is called dynamic routing, and every host on the network plays an equal role. If an enemy wanted to destroy a network connection, they would have to destroy all nearby hosts. ARPANET was later made public, attracting more academic institutions and private companies to participate in research. In 1979, the National Science Foundation (NSF) also began participating in network technology research. In 1985, funding was allocated to help nearly 100 universities connect to the network. In 1986, NSFNET was built, connecting the five major supercomputer centers in the United States with various universities, which led to more and more academic elites joining the research.
To enable computers to connect to each other via a network, certain rules are necessary, hence the emergence of communication protocols. ARPANET initially used the NCP (Network Control Protocol). As network technology became increasingly complex, the incompatibility between networks of different computers, software, and systems became more and more apparent. In 1974, Vint G. Cerf, later known as the "Father of the Internet," and his colleagues began developing a communication protocol that could be used on all computers—the TCP/IP (Transmission Control Protocol and Internet Protocol) used for internet access today. Gradually, a tool for storing and sharing information emerged: the WWW (World Wide Web), invented by Tim Berners-Lee. In 1989, Berners-Lee proposed establishing an information network system within CERN. Initially, this did not receive a response, but he persisted in pursuing his ideal. In 1990, he completed the HyperText Transport Protocol (HTTP), which allows computers to transfer hyperlinked files over the Internet. Furthermore, he designed the addresses for these files on the Internet, which he called URIs (universal resource identifiers), which are now known as URLs (uniform resource locators). Also in late 1990, he completed a browser-like program named World Wide Web, allowing users to browse the data they wanted. To facilitate the development of the Web, the first WWW Symposium was held at CERN on May 24, 1994. At the symposium, the Web was officially named the World Wide Web, and hyperlinked web pages were written in HTML (hypertext markup language), written by Blerley.
Marc Andreesen, an assistant at the National Center for Supercomputing (NCSA), decided to develop a browser with a graphical interface that was easy for users to use. In 1992, he and another colleague at NCSA, Eric Bina, finally developed a new browser, which they named Mosaic. Mosaic was more graphical and easier for general users to use than browsers at the time. In addition, like other browsers, it could also view HTML files. More notably, Mosaic also added image syntax, allowing the web to display images. Although earlier browsers could also display images, text and images required separate files, while Mosaic allowed text, images, and text to be displayed on the same webpage. The graphical interface and buttons made it easier for users to browse the web.
Embedded control systems were originally designed for industrial computers. With the popularization of information products and the rise of digital home appliances, embedded systems have gradually become popular in our daily lives. From information home appliances and network products to portable devices, we can see their traces. One of the characteristics of embedded systems is that they do not require many external components and can complete specific functions on small components. They are stable and small in size. The reason why embedded systems were difficult to popularize in the past was that integrated circuit and process technology could not be broken through. Due to the rapid development of semiconductor electronic technology in recent years, embedded systems have gradually become powerful and inexpensive. In addition, software technology has also continued to advance, so the development of embedded systems is no longer limited to the use of assembly language, but can use higher-level programming languages to develop embedded systems and realize more types of applications [1]. In recent years, the network has developed rapidly. With the continuous expansion of WWW (World Wide Web), the development of other control applications for WWW has been valued, and the role of browsers (IE, Netscape Navigator, etc.) has become the most common client management and monitoring program. Because web browsers can provide graphical interfaces, users can monitor the system status through the Internet. In addition, remote control has become another important topic. Remote control has many advantages, such as: operators can avoid being exposed to dangerous working environments; instructions can be issued to remote control systems without engineers having to arrive at the site immediately. Web-based embedded control platforms combine embedded systems and networks, and can provide real-time data of the control system as well as online control parameter settings. Web-based embedded control platforms can also be used as independent control systems. There are many advantages to using Web-based embedded control platforms, such as: low hardware requirements, low cost, high stability, portability, and the ability to connect to various industrial control devices, which is something that general web servers cannot do [2][3]. This paper not only explores embedded systems in depth, but also discusses the communication technology of the Internet of Things in detail. It will take the I-7188EX of ICP Facility as the research object and design a Web server for an embedded controller. Based on the embedded system, a Web-based embedded control platform will be developed, and the architecture of the Web-based embedded control platform will be studied in depth to explore its performance. This paper explores the performance of integrating a web-based embedded control platform with a distributed control module, using a web-based embedded control platform as an example. Finally, it discusses the characteristics and future development direction of the web-based embedded control platform constructed in this paper.
TCP/IP communication
The TCP/IP protocol suite allows computers of different sizes, from different computer manufacturers, and running different operating systems to communicate with each other. Originally a research project on packet switching networks funded by the US government in the 1960s, it has become the most widely used network between computers in the 1990s. TCP/IP is an open system, and the definition of the protocol suite and the implementation of many related protocols can be obtained publicly for a small fee or even for free. Network protocols are usually developed in layers, and TCP/IP is a combination of different layer protocols, generally considered to be a four-layer system [4], as shown in Figure 1: Each layer has different responsibilities. The following is a brief description of each layer:
(1) Link Layer: Also known as the Data-Link Layer or Network Interface Layers, it typically includes the device drivers in the operating system and the corresponding network adapter card in the computer. These two parts can handle all hardware issues related to the transmission medium connection.
Figure 1 TCP/IP Architecture Diagram
(2) Network Layer: This layer is responsible for the movement of packets throughout the network, such as packet routing. The entire network layer consists of IP (Internet Protocol), ICMP (Internet Control Message Protocol), and IGMP (Internet Group Message Protocol).
(3) Transport Layer: This layer provides the data flow between two hosts for the application layer. The TCP/IP protocol suite has two very different transport protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). TCP provides reliable data transmission between two hosts. Methods include segmenting data from the application software into appropriate sizes before sending it to the network layer; sending an acknowledgment signal upon receiving a packet; and setting a pause time to confirm that the other end has sent an acknowledgment signal. Thus, the application layer no longer needs to separately verify the reliability of the data. UDP provides another, simpler method for the application layer. Only one host sends data packets called datagrams to the other host, but it does not guarantee that the sent data will reach the other host. Additional reliability must be added by the application layer.
(4) Application Layer: This layer handles the details of application software. Many common application software programs have corresponding implementations for almost each layer. Examples include remote login, FTP (File Transfer Protocol), and SMTP (Simple Mail Transfer Protocol). Finally, the TCP/IP protocol suite contains many protocols, as shown in Figures 2, 3, and 4, which respectively illustrate the TCP/IP transmission structure under different circumstances.
Figure 2. Schematic diagram of internal transmission within a single host.
Figure 3. Schematic diagram of FTP transmission using the same network architecture.
Figure 4. Diagram of different network architectures connected via TCP/IP
This paper adopts TCP, the TCP/IP protocol suite, as the main communication protocol for the transport layer because TCP has the characteristics of connection-oriented, reliable, and byte-stream. Connection-oriented: Before the server and client establish a connection, they exchange data to determine the establishment of the connection. Reliability: TCP provides reliability in the following ways: (1) Data is broken down into chunks (chucks) that TCP considers to be of the optimal size before transmission. The Server-Client communication process is shown in Figure 5 below:
Figure 5: Server-Client Communication Flow
HTTP (HyperText Transport Protocol)
HTTP (Hypertext Transport Protocol) has been adopted as the basic communication protocol for the global information network since 1990. It is an application-level communication protocol characterized by its lightweight and high speed, making it particularly suitable for distributed, collaborative hypermedia information systems such as the Web. HTTP is generic, stateless, and object-oriented. It is particularly data-typing and allows negotiation of data representation, so systems built upon it are unaffected by the content of the transmitted data. Although HTTP has been widely used since 1990, there was no unified standard for many years; this ambiguous standard was later commonly referred to as HTTP/0.9.
It wasn't until June 1996 that a document for reference only was published by the HTTP Working Group of the Internet Society, called HTTP/1.0. Although HTTP/1.0 had an official document number (RFC1945)[5], it was only a temporary document with a validity period of six months, and this document expired at the end of 1996. In January 1997, an official document, HTTP/1.1 (RFC2068)[5], was released in time, and only then did HTTP have an official standard draft.
The HTTP standard specifies communication between a user (client) and a server. A user, a program, establishes a connection to the server (another program) according to the HTTP specification to send a "request." A "request" is a request to perform a certain action on a "resource" on a particular server. Upon receiving the request, the server sends back a "response." HTTP/0.9 is a simple "Request/Response" communication standard, its purpose being solely to transmit raw data. The main improvement of HTTP/1.0 is that it allows transmitted data to adopt a MIME-like format; that is, the format of the transmitted data can be specified, and "modifiers" can be used to change the meaning of requests and responses. This greatly expands the scope of HTTP's applications.
The main improvements of HTTP/1.1 are: hierarchical proxies, object caching, persistent connections, and virtual hosts. This paper mainly develops and proves the feasibility of an embedded Web-Server system. Besides being limited by the hardware environment, and given that most browsers support HTTP/1.0, this paper uses HTTP/1.0 as the foundation for its development.
HTTP/1.0 transport format
Like most network communication protocols, HTTP uses a client-server model: the client opens a connection and sends a request message to the server; the server receives the request and sends back a response message, which usually contains the data requested by the client. After the transmission ends, the server closes the connection. HTTP/1.0 uses many formats defined by MIME (Multipurpose Internet Mail Extensions), which can be found in RFC1521 [5]. The request and response message formats are similar and include: (1) an initial line, (2) a message header (zero or more HTTP header fields), (3) a blank line, and (4) an optional message body (e.g., a file, query data, or query output). Each part will be explained separately: Initial line: Initial request line: mainly consists of three parts: method name (to be mentioned later), the locale path of the request resource, and the HTTP version. The basic form is as follows: GET /path/to/file/index.html HTTP/1.0. This section briefly introduces the set of common methods for HTTP/1.0. The set of methods can be expanded, but it cannot be guaranteed that all clients and servers will accept it. The three most commonly used methods are: GET, HEAD, and POST.
(a) The GET Method: Simply put, the GET method requests data (all the information requested in the request message) from the server. During the process, the server will not provide a Text type source, but will convert it into an Entity-body (message body) and put it into the response; unless the source itself is stored and displayed as a text file.
(b) The HEAD Method: The HEAD method is similar to the GET method, but it does not include the Entity-Body part. When using the HEAD method, the server is required to send back status lines and headers, while omitting the message body. This method can be used if you only want to obtain the URI (Uniform Resource Identifier)[6] data of the server source.
(c) The POST Method: In older versions of HTML, the difference between the POST and GET methods was that the former could transmit data through other means, such as CGI scripts. In current HTML, both GET and POST can use CGI scripts. The difference lies in how data is transmitted: GET adds the data to the URL's backend, while POST adds it to the header and then sends it back to the client. This difference will be discussed in sections 2-4 regarding the application of CGI. Figure 6 illustrates the overall architecture of an HTTP message:
Figure 6 HTTP communication format
Initial response line (status line): mainly divided into three parts: HTTP version, response status code, and English description of status code. The basic form is as follows: HTTP/1.0 200 OK, or HTTP/1.0 404 Not Found. List the meanings of common status codes as shown in the table below. (1) Message Headers (HTTP header fields): The entire HTTP header fields include: General-Header, Request-Header, Response-Header, Entity-Header. The header fields format follows certain specifications [4], and the basic format is as follows: field-name:SP[field-value]CRLF SP means a single space; [Field-value] means the header content, and CRLF means the end character (ASCII code). The Message Body (Entity Body): For the request part, it is the data input by the client or the uploaded file; for the response part, it is the data returned to the client after accepting the client's request. When an HTTP message contains data, there are usually additional headers describing that data.
CGI (Common Gateway Interface)
The original HTML language was designed to display static data, allowing users to create rich multimedia content using a simple syntax, much like an advertising billboard. But what if the data users need is time-sensitive and needs frequent updates? Or what if you want to retain user data to make your webpage interactive?
Due to these various needs, CGI was born. CGI stands for Common Gateway Interface. It is a standard interface program that allows your webpage to communicate with a WWW server, achieving interactive effects with users. Furthermore, through CGI programs, you can dynamically generate webpages and display the latest data on the server. When you connect to a CGI object, the file you retrieve is not static data, but a dynamically generated HTML data stream. The returned data can be modified at any time, or react differently to specific user queries. Simply put, a CGI program can dynamically generate WWW webpages, allowing ordinary users to access data within the system via the WWW.
The CGI standard itself mentions that this can be achieved through environment variables, and CGI programs are also capable of accessing data from various existing databases. Therefore, we can see that CGI can be implemented by any programming language, as long as the language has file read and write capabilities. It's worth noting that this approach is also prone to security issues. Figure 7 is a CGI diagram:
Figure 7. CGI schematic diagram
Most web servers currently provide an environment for executing CGI (the path depends on the server settings, usually placed in the cgi-bin path). When a user links to a CGI program using a browser, the browser sends a request (require) to the remote web server through the HTTP communication protocol. The web server then runs an HTTPd process, which searches for the CGI program in the specified directory. If the CGI program exists, HTTPd will start a child process to run the CGI program, thus inheriting all the environment variable settings of HTTPd. This means that the user's input will be transmitted to the web server's HTTPd via the HTTP communication protocol, and then passed to the CGI program via environment variables or the standard input device (STDIN) [6]. The list of environment variables related to the CGI program is as follows:
Design of an embedded web server
In this section, we will explain the embedded web server (hereinafter referred to as EWS) and compare it with a general server. We will also explain the basic requirements and development tools for building a control system based on the EWS platform.
(1) General Web Servers vs. Embedded Web Servers: General web servers are basically designed for standard purposes (e.g., NT servers, Unix), so their requirements for system resources are relatively high, such as more memory, high-speed processors, time-sharing multitasking operating systems, and other resources. Typical EWS have relatively fewer requirements, only a few hundred kilobytes of memory, a low-speed processor, and a simplex operating system, so they have a great advantage in terms of cost and efficiency. EWS can often be used to transmit the status of embedded systems. Through a browser, users can easily obtain the current system status and set the execution results of first-level tasks. EWS can also accept and execute commands sent by users from the browser, achieving the effect of remote control.
(2) Online configuration program: In addition to providing a local management program, general server configuration usually provides a remote browser management program for ease of management. EWS also has the same mechanism, and users can also make relevant parameter settings for EWS remotely through a browser. With EWS (Embedded Web Server), users can make different settings according to the needs of the site through a remote browser [4], such as changes in network communication parameters and changes in the communication method of RS-232 terminal. This convenience can save the administrator from the predicament of having to travel around. Thus, it achieves convenient and humanized management.
(3) Advantages of EWS: There are some embedded web servers on the market that claim to be powerful, but they still require users to write their own programming languages to develop the system. In addition to supporting users to build web servers without writing any languages (basic mode), this EWS system also provides a more flexible way for users to modify and generate their own servers (custom script rules in web pages) (advanced mode).
The operating principle and system requirements of EWS
Typical web servers are designed to display static web pages using fast processors, while EWS is designed to achieve these requirements with limited resources. Therefore, the following key points must be considered.
(1) Communication protocol format: HTTP/1.0 provides information exchange for each connection. The browser sends relevant information to EWS, and the connection is closed after EWS responds. Therefore, during the design process, you only need to consider what information is being transmitted. After EWS takes over, you don't need to pay attention to the subsequent actions. EWS will faithfully execute the connection request and close the connection.
(2) APIs provided by EWS: EWS must provide a response mechanism for designers and provide services for sending HTML web pages to the browser [5]. This part of the required functionality can be achieved using CGI. In this mode, every connection that calls CGI via URL will be directed to the CGI handler. Through CGI, the browser can call and use functions in EWS and return the execution results to the browser. To achieve this functionality, we must develop several CGI functions in a standard CGI format [6] to meet the different needs of the browser.
(3) Structure of EWS: Based on the discussion in the previous section, the entire EWS consists of three parts: HTTP service, CGI service functions, and configuration interface. The overall structure is shown in Figure 8:
Figure 8: EWS Structure
The most crucial part of this architecture diagram is providing HTTP services. This service can receive requests from browsers, and the source of this service must conform to basic HTTP specifications. A typical web server establishes a connection immediately upon receiving a request. However, EWS, being a simplex operating system, operates entirely differently. It first queues requests and then processes them one by one. Therefore, when the number of connections exceeds one, establishing simultaneous connections is not feasible due to system resource constraints. Thus, HTTP services are handled using status symbols.
The interface configuration section provides a browser-based interface for setting EWS's network parameters. This interface allows users to remotely configure EWS's network parameters online. CGI functions handle web page files, which are categorized as static or dynamic. Static files can generally be directly transmitted to the browser via the file system through the HTTP service. Dynamic files, however, require an interpreter to extract the dynamically displayed portions of the web page file, which are then retrieved by the CGI function and sent to the browser. The file system provides EWS with file access rights, essentially offering the functions of opening, reading, and closing files. Through this file system, we can directly perform these three actions on the following file types within EWS: GIF, JPG, BMP, and HTM.
EWS handler
Figure 9 clearly shows the process and steps of HTTP service for connecting. In order to accept multiple connection requests in a simplex operating system, a scheduling program must be built on this system. In this system, a queue is used to store each requesting connection to determine whether to block or continue to accept a new connection. In order to provide greater flexibility, the program is divided into two parts: one is the fixed WebL_100.Lib and the other is User.c. WebL_100.Lib is the core of the entire embedded web server, which provides HTTP service and some other TCP/IP processing mechanisms. User.c is exposed to this server so that users can design and decide how to respond to connection requests coming from Port 80 [7].
Figure 9: EWS Operation Mode
The function of each state is explained below:
Block 1: This block initializes all variables, packet information, and network environment.
Block 2: This block contains two functions that allow designers to write their own custom programs.
Web_Init(): Designers can add variables or commands they want to use in this function. These added programs will only be executed once after the server starts. Designers can add action commands that only need to be executed once. For example, initializing communication ports.
Web_Loop(): Designers can add commands they want to use in this function. These added programs will be executed repeatedly in the main loop after the server starts. Designers can add commands that need to be executed repeatedly in this function. For example: scanning communication port status.
Block 3: Check if there is data on the TCP/IP communication port. If there is data, proceed to Block 5. Otherwise, the program will proceed to Block 4.
Block 4: Update the seven-segment display on the I-7188E, check the watchdog mechanism, and return to Block 2 to check if TCP/IP is receiving data.
Block 5: We implement different response mechanisms based on the online requests from different ports.
Port 80: If a CGI function is called during the current request, the program will execute up to Block 6. If it is just a simple webpage or graphic, the program will execute up to Block 7.
Others: Requires online connections for other ports, such as Ping.
Block 6: Pass variables to the corresponding functions according to the browser's function call. The following are the CGI functions provided for this block: CGI_DPAGE(), CGI_USER(), PRINT_PAGE().
Block 7: Send the data (web page) to the browser. Once complete, the program will return to Block 2.
Software and hardware requirements
In this study, the embedded controller I-7186EX/I-7188EX developed by ICP DAY was used as the execution platform for the control system, as shown in Figure 10. Its core uses an x86 microprocessor with an 80MHz operating frequency, does not support floating-point operations, and has three built-in timers and one watchdog timer. It also supports both software and hardware interrupt functions. For communication, it supports RS232/485 and Ethernet interfaces, allowing data to be downloaded to the embedded controller for application and verification via RS232 or Ethernet. As for the storage devices, it provides 2Kbytes of EEPROM to store the relevant data required for hardware startup; 512Kbytes of Flash ROM is planned to be used partly for the embedded operating system, and the rest is used to store user-developed applications. The feature of being able to be updated via software further meets the user's need to repeatedly modify control parameters and download them to the controller for verification when designing the controller in the future; 512Kbytes of SRAM can be used to store the data obtained during the experiment.
For the embedded operating system, it adopts the MiniOS7 (DOS-like) operating system developed by ICP DOS. Overall, its system architecture is similar to the DOS operating system on a personal computer. Its simplex operating environment ensures that user-developed applications have exclusive execution rights. Combined with the hardware RTC (Real-Time Clock), it forms a real-time operating environment. Regarding I/O expansion, the I-7186EX/7188EX embedded controller provides one X-board I/O expansion slot, allowing the addition of relevant control daughterboards for different control applications. Therefore, its I/O expansion capabilities are more flexible to meet diverse application needs. Notably, each Ethernet embedded controller has an RS-485 communication port, allowing the controller to control a series of ICP DCON series distributed control modules, such as the I-7000, I-8000, and I-87K modules with ICP custom command formats, via the serial communication port.
Figure 10 I-7188EX Embedded Controller and X Board Daughter Card
Design process of embedded web server
Figure 11 shows the development process of the embedded controller's web server established in this study. The steps are as follows: **Hardware Selection:** Select the hardware controller to connect to the EWS, making the EWS the information exchange center between the hardware controller and the browser. **Wiring Hardware:** Set up the entire hardware circuitry, including network and controller connections. **Design Web Page for Purposes:** Design the relevant web page based on the requirements. **Create EWS Firmware:** Customize the response mechanism when the browser receives commands and use a compiler to create the EWS. **Download Files and Run EWS:** Download the relevant files (HTM, Pictures) and the EWS firmware and execute the program.
Figure 11: EWS Design Flow
Practical Exploration
This section will use the following tools to develop an embedded web server (EWS): Hardware: I-7188EX (as EWS), I-7021, I-7012, I-7060D (as web server control devices) [8]. Software: Turbo C++ 1.01 (main program compiler) of Baolan is used to design the application firmware of the embedded controller, while Microsoft's FrontPage is a web page editing software. However, it is worth noting that the MiniiOS7 operating system and MiniiOS7 Utility (download application) of the embedded controller of ICP DAY are the core of the entire controller. In the following paper, the application architecture of EWS will be divided into two types, namely the basic mode architecture and the advanced mode architecture. The basic application mode is based on a pre-designed pre-designed firmware and a web page designed by the user. Finally, the pre-designed firmware and web page are downloaded to the target hardware application through MiniiOS7 Utility. The advanced application mode refers to EWS providing a user-added control program, a customizable EWS firmware, and a user-designed webpage, which can then be used to build a fully customized EWS system.
Basic Model Architecture Description
The basic mode provides a platform where designers do not need to write C language during the development process, enabling them to develop suitable EWS in the fastest time. Figure 12 shows the implementation system of the basic mode of EWS using the distributed control modules I-7012, I-7021, I-7017 and I-7060 produced by ICP DAY.
The main software components of the EWS system platform are as follows:
1. The main program (Firmware) provides HTTP services.
2. Web page components. Includes HTM, GIF, JPG, and BMP components.
3. CGI functions and response mechanisms are included in the firmware, providing CGI-related functions for application use.
In the basic mode, the core of the application system is provided; users only need to download the designed webpage to the controller. The webpage content required for system design in this article is shown in Figure 5, Readinfo.htm. Through the built-in decoding mechanism of the I-7188E embedded web server, designers familiar with webpage design can easily control or read the status of industrial control modules connected to the I-7188E directly using the built-in decoding mechanism. This method allows for the rapid and effective deployment of Ethernet embedded control systems using web server technology. Figure 13 shows the actual execution screen.
Figure 12: Actual circuit connection diagram
Figure 13: Diagrammatical Architecture of Webpage Content and Actual Execution of Interpretation Commands
Advanced mode provides designers with more control over the response mechanism after receiving HTTP requests during development. This mode exposes the User.C section in Figure 14, giving designers greater flexibility in this embedded web server. Similarly, the main software components of the EWS in advanced mode are as follows:
1. Main program (Frimware).
2. Provide HTTP service.
3. Web page components, including HTM, GIF, JPG, and BMP components.
4. CGI functions and response mechanisms are included in the firmware, providing CGI functions that can be called and related functions.
其中在主程序（Frimware）部份，另外开放User.C 供设计人员自行编写程序。在本系统的实作中，会使用到发展的网页直译器，将动态网页中的动态命令字符串直接解译并执行然后使用EWS 所取得的值或参数来取代这些动态命令，系统发展者可根据这些参数来做监控系统的应用。如图14，例如：改变命令字符串并用EWS 从通讯端口中取得的值取代此动态命令。透过解译程序，将动态命令从通讯端口输出并取得回传值然后产生一新的静态网页。最后，再将此新网页回传到浏览器端。执行结果如图15。
图14 客自化程序设计及对应的网页设计
图15: 进阶模式解译命令及执行结果
EWS 效能分析
由于EWS 是属于微型的网页服务器，因此其效能与下列要的变因有关系，网页内容、联机数目，都是决定此EWS 系统重要的因素。以下将针对此三变因作数据上的测试。 网页内容（联机数目为一）： 测试结果数据图形：
联机数目（网页内容为纯文字） 测试结果
in conclusion
由以上结果得知，整个网络运行的效能，影响最大的部份取决于单一网页传递数据量的大小。如果单一网页的数据庞大，针对每一个联机从开始回映到结束响应的时间将会大为增加。嵌入式网页服务器主要的功能大多是针对显示控制器的状态为主，因此联机的反应时间快慢只要是浏览器端可以接受的范围就可以。而配合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 语言结合创造出更弹性的控制系统。
References
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, KK 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
