 |
Claims  |
|
|
We claim:
1. A system for providing information about a remote device to a client workstation, the system comprising:
a micro-server for transmitting the information to the client workstation, the micro-server defining an application programming interface for interfacing with the remote device to access the information from the remote device and for abstracting
the details of transmitting the information to the client workstation, the remote device initializing the micro-server by providing, via a function call defined by the application programming interface, at least one pointer to at least one callback
function for accessing the information, the micro-server accessing the information by calling the at least one callback function.
2. The system of claim 1 wherein the micro-server comprises a TCP/IP application programming interface for accessing a TCP/IP protocol stack.
3. The system of claim 1 further comprising: a system services application programming interface for providing the micro-server with access to system services from the remote device.
4. The system of claim 1 wherein the micro-server comprises an HTTP protocol server for satisfying interactive HTTP requests from the remote client workstation.
5. The system of claim 4 wherein the micro-server comprises a synthesized HTML server for providing a dynamic copy of an HTML version of a web page served by the HTTP protocol server.
6. The system of claim 1 further comprising: a data image for caching data from the remote device for reducing the number of application programming interface function calls made by the micro-server to access remote device information.
7. The system of claim 1 wherein the micro-server comprises: a TCP/IP based server for satisfying TCP/IP based requests from the client workstation.
8. The system of claim 1 wherein the micro-server comprises: a hyperlink to a website associated with the remote device.
9. The system of claim 1 wherein the micro-server comprises: a web site associated with the remote device.
10. The system of claim 9 wherein the web site comprises: a home page for publishing the remote device's parametric data.
11. The system of claim 9 wherein the web site comprises: a control page for providing authorized individuals access to the remote device's control functions.
12. The system of claim 9 wherein the web site comprises: a maintenance page for providing access to the remote device's maintenance data.
13. The system of claim 12 wherein the maintenance page comprises: a hyperlink to online maintenance documentation.
14. The system of claim 9 wherein the web site comprises: a maintenance page for providing access to the remote device's maintenance functions.
15. The system of claim 9 wherein the web site comprises: an administration page for allowing authorized individuals to set operating characteristics of the remote device.
16. The system of claim 9 wherein the web site comprises: a discover page for supplying information to the client workstation during automatic discovery.
17. The system of claim 1 further comprising: a default applet server for providing default applets to the client workstation for interfacing with the remote device from the client workstation.
18. The system of claim 1 further comprising: a time server for providing current time information to the system, the time information being maintained based at least in part upon universal coordinated time.
19. The system of claim 1 further comprising: a maintenance server for providing non-volatile storage for the remote device's maintenance records, the non-volatile storage being hyperlinked from the remote device.
20. The system of claim 1 further comprising: an auto-discovery and view server for automatically
detecting a micro-server-enabled device being coupled to an interface and
publishing micro-server-enabled device data to the client workstation.
21. The system of claim 1 further comprising: a local applet server for retrieving device-specific applets from a server associated with the remote device and for making the applets available to the client workstation.
22. The system of claim 1 further comprising: a browser for interacting with the remote device.
23. The system of claim 1 further comprising: a client-side application programming interface for providing the client workstation with a software interface to the remote device.
24. The system of claim 1 wherein at least a portion of the information is organized as addressable variables.
25. A remote device capable of providing information about itself to a client workstation, the remote device comprising:
a micro-server for transmitting the information to the client workstation while abstracting communication protocol details from the remote device's control software;
an application programming interface for providing an interface between the remote device's control software and the micro-server, the control software initializing the micro-server by providing, via a function call defined by the application
programming interface, at least one pointer to at least one callback function for accessing the information, the micro-server accessing the information by calling the at least one callback function;
a hardware Ethernet interface; and
a TCP/IP protocol stack for interfacing between the micro-server and the hardware Ethernet interface.
26. The remote device of claim 25 further comprising: a computer capable of supporting a standard operating system environment.
27. A micro-circuit board for providing information about a remote device to a client workstation, the micro-circuit board comprising:
a micro-server for transmitting the information to the client workstation while abstracting communication protocol programming details from the remote device's control software;
an application programming interface for providing an interface between the remote device's control software and the micro-server, the control software initializing the micro-server by providing, via a function call defined by the application
programming interface, at least one pointer to at least one callback function for accessing the information the micro-server accessing the information by calling the at least one callback function;
a hardware Ethernet interface; and
a TCP/IP protocol stack for interfacing between the micro-server and the hardware Ethernet interface.
28. A system for providing information about a remote device to a client workstation, the system comprising:
a first processor for running the remote device's control software and a first side of an application programming interface ("API");
a second processor for running micro-server software and abstracting communication protocol details from the first processor by running a second side of the API, the control software initializing the micro-server by providing, via a function call
defined by the API, at least one pointer to at least one callback function for accessing the information, the micro-server accessing the information by calling the at least one callback function and transmitting the information to the client workstation,
the second processor accessing a TCP/IP stack to interface with the hardware Ethernet interface; and
a hardware interface between the first processor and the second processor.
29. A system for providing information about a remote device to a client workstation, the system comprising:
a processor for running remote device control software and a first side of an application programming interface ("API"), the processor being mounted on a PC circuit board, the PC circuit board being insertable into a computer;
a computer for abstracting communication protocol details from the processor by running micro-server software including a second side of the API, the control software initializing the micro-server by providing, via a function call defined by an
application programming interface, at least one pointer to at least one callback function for accessing the information, the micro-server accessing the information by calling the at least one callback function and transmitting the information to the
client workstation, the computer having a hardware Ethernet interface and a TCP/IP stack for interfacing with the hardware Ethernet interface; and
a hardware interface between the processor and the computer.
30. A method for providing information about a remote device to a client workstation comprising the steps of:
providing to a micro-server, via a function call defined by an application programming interface, at least one pointer to at least one callback function;
accessing the information from the first device via the at least one callback function;
organizing the information into a format compatible with a communication protocol in preparation for making the information available to the client workstation;
making the information available to the client workstation; and
abstracting the communication protocol from the remote device.
31. A system for accessing remote device data and communicating the data to a client workstation, the system comprising:
a remote device having an original equipment manufacturer ("OEM") software component for controlling operation of the remote device and a micro-server software component;
the micro-server software component for transmitting the remote device data to the client workstation, the micro-server software component having an original equipment manufacturer application programming interface ("OEM API") for allowing the
OEM software to initialize the micro-server software, the initialization including the OEM software providing one or more callback functions to the micro-server software component to allow the micro-server software component to access OEM software
component data through one or more functions defined by the OEM API, the OEM API abstracting micro-server software component implementation of networking protocol details from the OEM software component.
32. The system of claim 31 wherein the micro-server software component comprises non-blocking threads for returning processor control to the OEM software component without delays associated waiting for external events to occur.
33. The system of claim 31 wherein the micro-server software component is a binary software library linked to the OEM application.
34. The system of claim 31 wherein the micro-server software component includes a client-side refresh mode of operation that automatically updates a page displayed at the client workstation at fixed time intervals.
35. The system of claim 31 wherein the micro-server software component comprises an OEM data cache component for caching OEM data accessed by the micro-server software component thereby reducing overhead associated with frequent OEM API function
calls. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to providing information from a first device to a second device. More particularly, this invention relates to a micro-server system comprising a micro-server capable of being embedded into and/or associated with industrial
equipment and/or consumer devices/products and capable of publishing information about such equipment and/or devices/products to thin clients running standard web browser software.
2. Statement of Related Art
Industrial process information is typically collected and used primarily through the offerings of a handful of key industrial information collection companies, or through internal home-brew solutions. Both approaches are costly to implement
because the collecting architecture is very specific to the individual devices and to the whole process. Almost all the transport protocols are proprietary, and much of the media used to interconnect these devices, like RS-485, DeviceNet, and the like,
are either proprietary or are limited to connecting only these kinds of devices. For a very remotely located device, options for connection can be severely limited.
In addition, most prior art solutions are hard-wired to the process, and a central host collects and manages device data, as is shown in FIG. 1. A central host is not a natural place for this information. The data is more timely, accurate, and
meaningful at the device to which the data pertains.
Should the process change, re-wiring or re-instrumenting of prior art systems is typically needed. Re-programming the host is an enormous task fraught with the potential for bringing the whole process to a halt. The proprietary software that
communicates with the host is usually licensed for, and installed on, each client computer, representing a big investment even from the update management perspective alone.
A significant drawback of such prior art systems is that if the host fails or is unreachable for any reason, all tactical and strategic data becomes unavailable.
Therefore, it is an object of this invention to simultaneously remove the host computer, as shown in FIG. 2 in which micro-server is abbreviated .mu.Server, remove the need for customer programming, unify the network fabric throughout factories
and offices (Ethernet), provide secure access to any effector or device in the process from any workstation in the enterprise, and reduce the total cost of ownership.
It is an additional object of this invention to prevent information about a device from being maintained on a centralized host computer and to allow such information to reside in the actual device itself. With the information residing in the
device itself, if the device is moved, its data moves with it. If the device is replaced, the new device can automatically publish its new data according to the principles of this invention.
It is a further object of this invention to enable devices to come on line and be browsable by a browser when the devices are shipped from the OEM. According to the principles of this invention, such devices could be capable of providing
operational data, limits, suggested maintenance cycles, specifications, links to the manufacturer's web site for detailed drawings, and literally whatever other information that the OEM desires.
Typically, original equipment manufacturer ("OEM")software professionals do not program with the Windows Application Programming Interface ("API"), and therefore almost never write code for a network. Typically, however, they are very familiar
with the embedded software necessary to monitor and control industrial devices.
It is therefore a further object of this invention to abstract and encapsulate the highly complex TCP/IP network layer and Internet Web services to provide a simple, yet comprehensive, API in the "embedded" problem space, with which most OEM
software professionals are familiar. It is a further object of this invention to publish information about the industrial equipment, also referred to as the device data, to an enterprise or the world as a web page on the corporate Intranet or the larger
Internet.
SUMMARY OF THE INVENTION
A system for providing information about a first device to a second device. A micro-server interfaces with the first device to access the information from the first device. The information is then organized and formatted compatible with a
communication protocol in preparation for making the information available to said second device. The information is made available to the second device while abstracting the communication protocol from the first device.
The system could include: an OEM application programming interface ("API") for interfacing between the first device's software layer and the micro-server; a TCP/IP stack for interfacing with a hardware interface; a TCP/IP API for providing access
to the TCP/IP protocol stack; a hardware Ethernet interface; a system services API for providing the micro-server access to system services from the first device; an HTTP protocol server for satisfying interactive HTTP requests; a browser for interacting
with the first device; a TCP/IP-based server for satisfying TCP/IP-based requests; a hyperlink to a website associated with the first device; a web-site associated with the first device; a default applet server for providing default applets to the second
device to interface with the first device; a time server for providing current time information; an auto-discovery and view server for automatically detecting the first device being coupled to an interface; and a browser for interacting with the first
device.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates a prior art architecture including a centralized host computer for collecting industrial process information.
FIG. 2 illustrates a possible architecture, consistent with the principles of this invention, for publishing industrial process information.
FIG. 3 illustrates a simplified example system in accordance with the principles of this invention.
FIG. 4 is a simplified block diagram showing several subsystems of a micro-server according to this invention.
FIG. 5 illustrates several possible server/client types of combinations according to this invention.
FIG. 6 illustrates three primary communication paths between a micro-server-enabled device and client-side software.
FIG. 7 is a sample Read (Default) page.
FIG. 8 is a sample Control page.
FIG. 9 is part 1 of a sample Maintenance page, also referred to as a Maint page.
FIG. 10 is part 2 of the sample Maintenance page.
FIG. 11 is a sample Administration page, also referred to as a Admin page.
FIG. 12 is a partial sample of a Discover page.
FIG. 13 illustrates a three party model for online access to micro-server-enabled device documentation.
FIG. 14 is a simplified flowchart illustrating processing performed by a micro-server during micro-server initialization.
FIG. 15 is a simplified flowchart illustrating processing performed by a micro-server while getting run control from the device with which it is associated.
FIG. 16 is a simplified flowchart illustrating processing performed by a micro-server for executing a system thread.
FIG. 17 is a simplified flowchart illustrating TCP server thread processing by a micro-server.
FIG. 18 is a simplified flowchart illustrating HTTP server thread processing by a micro-server.
FIG. 19 is a simplified flowchart illustrating client subscription processing by a micro-server.
DETAILED DESCRIPTION
The operation of the micro-server is similar to that of a general-purpose web server. For example, FIG. 3 shows a remote thermostat device 300, labeled Temp Sensor in FIG. 3, equipped with a micro-server 302, labeled .mu.Server in FIG. 3,
connected to the same Ethernet network 304 as a client workstation 306. The workstation could be used to monitor the remote temperature and/or to adjust the set point of the thermostat 300. The remote device contains two software components: (1) the
OEM code 308 that performs the actual control functions and (2) the software of micro-server 302, which communicates with network clients. In this example, the workstation computer is considered a thin client, running no special software. All
interactions with the remote micro-server-equipped thermostat device 300 is accomplished via a standard web browser program such as Netscape Communicator or Microsoft Internet Explorer. The micro-server-enabled thermostat device 300 could publish a
standard web page containing the current temperature. Another page could be used to set the desired set point. Tremendous flexibility arises from the fact that multiple users, both local and far away, can access, view and change the information in the
same manner without any special software, subject to configurable security measures.
Whenever a remote user accesses a micro-server-enabled device's web page, the micro-server software makes appropriate function calls to the OEM code to retrieve current information. Having done so, the micro-server incorporates the current
information into the web page and sends the updated page to the requesting client machine. Similarly, whenever the user wishes to modify a control parameter, such as the set point of thermostat 300, a user could enter the desired temperature into a text
box and submit the new information to micro-server 302. The micro-server 302 could then make appropriate function calls to the OEM code in order to change the setting.
In a first preferred embodiment of the invention, the micro-server is implemented in software. The micro-server could be provided to the OEM as a binary software library linked to the OEM application. Both the traditional static linking and the
newer dynamic linking (DLL) methods are possible. In this embodiment, the OEM software could be linked with the micro-server libraries, which would then become an integral part of the micro-server-enabled device's embedded software. The micro-server
software could then be placed in the non-volatile medium in the OEM's hardware, such as EPROM or EEPROM.
The arrangement of characteristics listed in Table 1, below, could be used. As will be apparent to those skilled in the art, other suitable arrangements could also be used without departing from the scope of this invention.
TABLE 1 ______________________________________ Characteristics of the First Preferred Embodiment Characteristic Description ______________________________________ OEM software contained in OEM hardware micro-server software contained in
OEM hardware TCP/IP stack contained in OEM hardware Ethernet Interface in OEM hardware OEM side of OEM-micro-server API OEM code micro-server side of OEM-micro- micro-server server API code ______________________________________
In a second preferred embodiment, the micro-server could be an embedded-micro circuit board small enough to fit inside of the control box of a piece of industrial technology like a motor, a pump, a valve, or some other piece of process equipment. Of course, such an embedded-micro circuit board could also be placed into other types of devices and products, such as, consumer products. OEM software could be accommodated in the same board. In addition to the OEM and micro-server code, the software
could include a TCP/IP protocol stack. As used in this specification and the appended claims, communication protocol dependent terms such as TCP/IP, HTTP, Ethernet, and the like, and means for supporting such protocols such as TCP/IP network protocol
stack, and the like, are used for illustrative purposes only and should not be construed as limiting this invention to those particular protocols. As will be apparent to those skilled in the art, other appropriate communication protocols could also be
used without departing from the scope of this invention. The hardware could include Ethernet support.
The characteristics of the second preferred embodiment of this invention could be arranged as in Table 2 below. As will be apparent to those skilled in the art, other suitable arrangements could also be used without departing from the scope of
this invention.
TABLE 2 ______________________________________ Characteristics of the Second Preferred Embodiment Characteristic Description ______________________________________ OEM software contained in hardware controller card micro-server software
contained in hardware controller card TCP/IP stack contained in hardware controller card Ethernet Interface in hardware controller card OEM side of OEM-micro-server API OEM code micro-server side of OEM-micro- micro-server server API code
______________________________________
In a third preferred embodiment, the micro-server could be a software component intended to run on a full WINDOWS platform (/95, /98, &/or /NT) or any other available operating system. This embodiment is useful in situations where the OEM's
control platform is a computer capable of supporting a standard operating system environment. The operating system could provide TCP/IP support, and the computer's hardware could provide Ethernet connectivity. The characteristics of the third preferred
embodiment of this invention could be arranged as in Table 3 below. As will be apparent to those skilled in the art, other suitable arrangements could also be used without departing from the scope of this invention.
TABLE 3 ______________________________________ Characteristics of the Third Preferred Embodiment Characteristic Description ______________________________________ OEM software contained in OEM computer Micro-server software contained in
OEM computer TCP/IP stack contained in OEM operating system or add-on Ethernet Interface in OEM computer OEM side of OEM-micro-server OEM code API Micro-server side of OEM-micro- micro-server code server API
______________________________________
In a fourth preferred embodiment, the invention comprises hardware that does not contain the OEM code, the OEM code being embedded in its own hardware. The micro-server software is contained in its own micro-controller, with an Ethernet
interface and an external hardware interface (e.g., serial, parallel, PC-104, etc.) to connect the micro-server's micro-controller to the OEM's micro-controller. In this embodiment, the OEM-to-micro-server API abstracts the hardware interface between
the OEM hardware and the micro-server hardware. This embodiment is particularly useful for retrofitting existing devices for web operation.
The characteristics of the fourth preferred embodiment of this invention could be arranged as in Table 4 below. As will be apparent to those skilled in the art, other suitable arrangements could also be used without departing from the scope of
this invention.
TABLE 4 ______________________________________ Characteristics of the Fourth Preferred Embodiment Characteristic Description ______________________________________ OEM software contained in OEM hardware Micro-server software contained in
hardware controller card TCP/IP stack contained in hardware controller card Ethernet Interface in hardware controller card OEM side of OEM-micro-server API OEM code on OEM hardware Micro-server side of OEM-Micro- micro-server code on hardware
server API controller card ______________________________________
A fifth preferred embodiment of this invention could use an embedded micro-controller built on a PC circuit board (ISA, PCI, etc.) that can be plugged into another computer. The micro-controller could contain the micro-server software and the
TCP/IP network protocol stack. The OEM code could run on the computer that has the PC circuit board plugged into it.
TABLE 5 ______________________________________ Characteristics of Fifth Embodiment Characteristic Description ______________________________________ OEM software contained in OEM computer micro-server software contained in plug-in hardware
card TCP/IP stack contained in plug-in hardware card Ethernet Interface in plug-in hardware card OEM side of OEM-micro-server API OEM code on OEM hardware Micro-server side of OEM-micro- micro-server code on plug-in server API hardware card
______________________________________
Each of the preferred embodiments comprises three Application Programming Interfaces ("APIs"): an OEM API, a TCP/IP stack API, and a System Services API. These APIs are suitable for use with current networking technology. It will be apparent to
those skilled in the art that the concepts taught herein may be applied using API's other than those herein described and that the same or other API's may be used in connection with networking protocols developed in the future without departing from the
scope of this invention.
The OEM API is used by the OEM software to configure the micro-server. The OEM API is also used to exchange data between the OEM software and micro-server software. The OEM API abstracts the micro-server to the OEM layer. The fundamental
purpose of the OEM API is to provide a high level of abstraction for the micro-server from the OEM programmer's perspective. This allows the programmer to remain focused on the embedded application without having concern for the details of making the
application web-enabled.
The OEM API is divided into five primary groups: (1) initialization group; (2) callback functions group; (3) system services group; (4) TCP/IP pass through group; and (5) scheduling group. An alphabetically organized listing of a micro-server
OEM API functions including a synopsis of the call, the appropriate declaration, a narrative description of all arguments, the return value and associated usage notes are attached as Appendix A to this specification.
The OEM API Initialization group comprises a series of functions, which are called by the OEM software on power-up of the embedded device in order to inform the micro-server about variables which may be queried. For instance, a micro-server
enabled servo-valve of the type typically used in chemical processing could be capable of providing data on its current setting (0-100%), fluid flow rate, and temperature. To make this data accessible to the outside world, the OEM program could
advertise it to a co-embedded micro-server by executing a separate call to an appropriate API initialization function. Each such call could provide the name of the
variable, e.g., Flow Rate, the units of measure, and a pointer to a callback function to be used by the micro-server to retrieve the value of that variable.
The OEM program could also execute similar API functions to inform the micro-server about its control points. The example servo-valve could have a single control point: the desired setting (0-100%). It could therefore make an appropriate call
via the API to provide information about this control point and to provide a callback function that could be used to adjust this setting.
The OEM API callback functions advertised to the micro-server by the OEM software, could be used by the micro-server to retrieve the values of the OEM variables or to change device settings. The micro-server calling these callback functions will
typically make up the bulk of interaction between the OEM software and the micro-server. Significantly, the OEM software is typically essentially unaware that the micro-server is making these calls. This is consistent with the desired abstraction of
the micro-server from the embedded OEM software.
Preferably, the micro-server software is completely portable. Therefore, it typically does not make any assumptions regarding the presence or functionality of an underlying operating system. In order to provide the micro-server with very
rudimentary system services, for example, access to non-volatile storage or timer services, the OEM software provides these to the micro-server, again, via callback functions. This occurs during initialization. As is similar to the data and control
callback functions discussed above, the execution of these system callback functions is transparent to the OEM program.
In a standard micro-server-enabled device, the OEM software would not generally talk directly to TCP/IP clients. Such communications are typically handled by the micro-server and are invisible to the OEM software. The OEM API does, however,
provide the ability for the OEM software to open a TCP server port and service special requests directly. When such requests arrive on the specified port, the micro-server passes them through to the OEM software. This occurs via a callback mechanism
similar to those discussed above. The responses from the OEM software to the originating client are passed through the microserver in the opposite direction.
The scheduling group of the OEM API is comprised primarily of a function that is used by the OEM software to run the microserver software after the microserver has been initialized. The OEM software or hardware typically would make arrangements
to allow the micro-server to run periodically. Since most embedded applications generally do not have an underlying operating system, the execution of the micro-server is typically controlled by either calling it periodically via a function from the OEM
API scheduling group. Such a function call could occur, for example, by explicit periodic calls from the OEM software or by attaching the function to a timer interrupt.
In addition to the OEM API, each preferred embodiment comprises a second API, the TCP/IP stack API, which is used by the micro-server to communicate with the underlying TCP/IP stack. The TCP/IP API could be standardized to conform to the Winsock
1.1 interface standard. As will be apparent to those skilled in the art, other suitable interface standards may also be used without departing from the scope of this invention. The TCP/IP API abstracts the TCP/IP protocol stack to the micro-server.
Each preferred embodiment also comprises a third API, the System Services API, which is used to provide the limited service required by the micro-server. Since the micro-server is preferably software platform independent, the System Services API
may be defined by the OEM code via the OEM API. As a consequence, the System Services API typically will not be usable by the micro-server until the initialization is complete. The System Services API provides the system services to the micro-server,
while abstracting from the micro-server the details of providing such services.
The system services used by the micro-server during operation may be provided either by an underlying operating system or by the OEM code itself. The entity providing the services is typically transparent to the micro-server.
FIG. 4 is a simplified block diagram showing possible components of a micro-server. The OEM API is depicted by bold double-ended arrow 400. The System Services API is depicted by bold double-ended arrow 402. The TCP/IP API is depicted by bold
double-ended arrow 404.
System services 406 provides the system services required by the micro-server. This software is abstracted from the micro-server's point of view and may be either a part of the native operating system or part of the OEM software layer. Embedded
OEM Software layer 408 communicates with device-specific hardware, except for the Ethernet hardware interface. Device hardware 410 may include sensors and other inputs, effectors or other outputs, and the like. The Ethernet hardware interface could be
included in this layer, but is preferably accessible only from the TCP/IP stack. The main body 412 of the micro-server could comprise: micro-server-OEM API 414; micro-server-TCP/IP API 416; synthesized HTML 418; OEM data image 420; HTTP server 422; and
TCP/IP based server 424.
Micro-server-OEM API 414 is an interface that could be used primarily by the OEM layer 408 to configure the micro-server and by the micro-server to exchange data with the OEM layer. The TCP/IP protocol stack could be used for communications over
an Ethernet. TCP/IP protocol stack as used in this specification and the appended claims is not intended to be limited by the TCP/IP protocol. Rather, TCP/IP protocol is merely illustrative, and not intended to limit the scope of this invention to
TCP/IP protocol. Other suitable protocols could be used without departing from the scope of this invention. Micro-server-TCP/IP API 416 is used by the micro-server to access the TCP/IP protocol stack 426.
Synthesized HTML 418 can contain a dynamic copy of the HTML version of the web pages served by HTTP server 422 to a client. OEM data image 420 can cache the OEM layer data in order to minimize callback requests from the micro-server. Stale OEM
data can be automatically refreshed. HTTP protocol server 422, also referred to as HTTP server, can be used by the micro-server satisfy interactive HTTP request typically from thin browser-based clients. TCP/IP Based Server 424 could be used by the
micro-server to satisfy TCP/IP based requests from clients executing default applets, manufacturer-supplied applets, client-side API software, or other TCP/IP-based software.
Each of the preferred embodiments is capable of five primary operating modes, as shown in the following table:
TABLE 6 ______________________________________ Micro-Server Operating Modes Mode Operating Mode Client Software ______________________________________ 1 HTTP Server Standard interactive browser. 2 HTTP Server with Client- Standard
interactive browser side Refresh 3 TCP/IP Server Default applet, OEM-provided applet, Client-side API, Custom client 4 TCP/IP Server with Server- Default applet, OEM-provided side Push applet, Client-side API, Custom client 5 TCP/IP Pass-through OEM-provided applet ______________________________________
FIG. 5 depicts several possible server/client types of combinations according to the principles of this invention. The five micro-server operating modes are depicted by the boxes on the left side of FIG. 5. They are: HTTP server 500; HTTP
server with client-side refresh 502; TCP/IP Server 504; TCP/IP Server with server-side push 506; and TCP/IP pass through mode OEM server 508. The five operating modes function as follows.
HTTP server 500 is the most common mode used in interactive access to a micro-server-equipped device from a thin-client workstation running a web browser. When a user lands on a desired device's default page, an appropriate HTML description of
the current state of the device is dynamically configured by the micro-server and the resulting page is displayed on the client work station's screen. This information is typically not updated dynamically, and the user typically would click on the
browser's RELOAD button to cause an update to occur. As depicted in FIG. 5, HTTP server typically operates in conjunction with a standard browser 510. A standard browser could include, but is not limited to, Netscape Communicator or Microsoft Internet
Explorer. Either of these products, as well as many others both commercially available and custom designed, are capable of providing a sufficiently interactive client interface to access micro-server pages.
HTTP server with a client-side refresh 502 is similar to the HTTP server mode 500 except that the page displayed in the browser is continually updated at fixed time intervals. HTTP server with client-side refresh will typically be available if
the micro-server-equipped device has been appropriately configured by the user. This mode also typically depends on a client-side refresh configured into the HTML description of the page being viewed. HTTP server with client-side refresh 502 typically
operates in conjunction with a standard browser 510, as shown in FIG. 5.
The TCP/IP server mode 504 is non-interactive. Data is exchanged between a client program on the remote workstation and a TCP/IP server within the micro server. As shown in FIG. 5, client applications which typically use this mode include: (1)
a default client-side micro-server applet which determines the micro-server-equipped device's configuration and configures itself 512; (2) an OEM-provided applet which adheres to the standard micro-server TCP/IP application packet format 514; or (3) a
micro-server client-side API application 516.
A default applet 512 is a software entity provided by an applet server. Once acquired by a client, it becomes a part of the client browser and it will typically be capable of displaying device data in a convenient, graphical manner. The default
applet could be written according to a standard micro-server application-to-application protocol definition and could communicate directly with the TCP/IP server within a micro-server. Since this communication takes place within the micro-server,
underneath the OEM API, which provides networking abstraction, it is typically invisible to the OEM layer.
An OEM-provided applet 514 is functionally equivalent to the default applet, but may provide a richer set of functions. It could be acquired from the OEM either directly or via an applet procurement agent. The OEM-provided applet could
communicate with the micro-server in different modes. If written to the standard micro-server application-to-application protocol definition, it communicates directly with the TCP/IP server within the micro-server, just like a default applet discussed
above. The OEM could also write the applet to use a different application-to-application protocol. In this case, the applet would communicate with the OEM layer via the TCP/IP pass through mode 508. This method would typically be discouraged because,
under such circumstances, the micro-server would no longer provide full networking abstraction to the OEM software.
The Client-side API 516 is a software entity that can execute on the client machine and provide programmatic access to micro-server functions via an API. The Client-side API could use the TCP/IP server within the micro-server. In addition to
handling ad-hoc requests from client applications, it is sufficiently intelligent to listen for broadcast messages from micro-servers to which it subscribes.
TCP/IP server with server-side push 506 is a mode similar to the standard TCP/IP server mode 504 but includes a limited push or broadcast capability to automatically initiate update data transfers to a limited number of selected clients. Data
transfer destinations as well as trigger issues that initiate them may be user configurable. Judicious use of this option can result in significant savings in network traffic. As shown in FIG. 5, TCP/IP server with server-side push typically operates
with the same types of client-side entities as the standard TCP/IP server mode.
TCP/IP pass through 508 is a mode intended for special cases outside of the scope of normal micro-server operation. A specific example of the use of this mode is a scenario in which an OEM supplied applet 518 is running under the client-side
browser, communicating with a specialized TCP/IP server in the OEM application itself. In this scenario, the micro-server simply passes all received TC | | |
