Patent Application
20130275856
The present invention generally relates to the field of process control systems. More specifically, the present invention relates to a method, system, and apparatus for providing an interface to data available within a process control system, such as a programmable logic controller.
A programmable logic controller (“PLC”) is an electronic device utilized to perform industrial process and machine control. In general, a PLC works by examining a number of inputs and, depending upon the state of the inputs, adjusting the state of one or more outputs. A user enters a program, usually via “ladder” logic or some other programming means, that provides the desired results. Because of the high degree of reliability associated with PLC operation, PLCs are utilized in countless real-world applications, such as machining, packaging, assembly, material handling, and others.
A PLC typically consists of a central processing unit (“CPU”), memory areas, and appropriate circuitry for receiving input and providing output. The memory areas typically contain information regarding the status of the industrial process that the PLC is controlling. For instance, a memory area contain data regarding the number of cans of tomatoes that have passed a certain point on a conveyor belt during the previous 30 seconds. Because access to this type of information is very important to the operator of a PLC, several types of devices have been developed to gain access to it.
One type of device for accessing data contained in the memory of a PLC is the traditional operator interface (“OI”). A traditional OI is a hardware unit that includes a display and a key panel that is intended for plant floor use. An OI connects directly to a PLC and be programmed, through the use of custom configuration software, to display data screens regarding the PLC operation. The OI also permit a user to control aspects of the operation of the PLC. In general, once programmed, an OI is the primary interface to the PLC for the user. However, the OI does have some limitations. In particular, while an OI is exceptionally useful for controlling and accessing a PLC in an area that is physically close to the PLC, an OI cannot provide remote access to PLC data. Moreover, because custom configuration software must be utilized to program the display and control functions of the OI, it can be expensive and time consuming to reprogram the OI to display different data screens.
Another type of device for accessing data contained in the memory of a PLC is a larger solution system, a human machine interface (“HMI”) or man machine interface (“MMI”). An HMI or MMI package is a software package that can be configured and run on a personal computer (“PC”) set up for that purpose. It can then remotely access the required PLCs to gather and control PLC system data. This solution has limitations as well. This software solution is a larger scale implementation requiring expensive PC hardware and additional interface equipment. The HMI and MMI packages generally support higher level and more complex control and visualization functionality. The packages are generally sold by a license per seat, and are a higher end, and more expensive, solution than local OI.
Another type of device for accessing data contained in the memory of a PLC is a World Wide Web (“Web”) server. In a typical implementation, a hardware Web server module is created that comprises a physically small but conventional server computer. The Web server module connects to the PLC via a backplane bus interface or another type of interface. The Web server module usually has an Ethernet or other type of interface that allows that Web server module to reside on the Internet. The Web server can receive and respond to requests for Web pages containing data regarding the operation of the PLC. In this manner, data regarding the operation of the PLC can be provided to any computer that is equipped with a Web browser.
Web server modules utilized to provide data regarding the operation of a PLC are also not without their drawbacks. The biggest drawback of such Web server modules is the difficulty in creating and modifying the Web site that is provided by the Web server module, as well as associating the PLC data with table entries or non-text renderings within the markup language format. This process is typically an arduous one that involves an operator creating each of the Web pages of the Web site using a standard markup language, such as the hyper-text markup language (“HTML”) or the extensible markup language (“XML”), and possibly a programming language such as JAVA® from Sun Microsystems. While PLC operators are typically well versed in ladder logic, HTML, XML, and JAVA are typically foreign topics. Therefore, creation of the Web pages to be served by the Web server module be a time consuming and expensive process.
Once the Web pages to be served by the Web server module have been created, they are typically transferred to the Web server module. The Web server module uses non-volatile memory to store the Web pages and any associated information, like graphics. Typically, a standard file system is created within the non-volatile memory, with all the HTML contents for a page rendering stored there. In this manner, the Web server module can access the Web pages in a traditional fashion as requests are received. Because of the small physical size requirements for a rack-mounted Web server module and the high price of non-volatile memory, the amount of memory in the Web server module be severely limited. This limited memory directly limits the number of Web pages and the complexity of the Web pages that be stored within, and served by, the Web server module.
Therefore, in light of the above, there is a need for a method, system, and apparatus for providing data regarding the operation of a control system that does not require a user to create a Web site using a markup language. There is a further need for a method, system, and apparatus for providing data regarding the operation of a control system that stores data defining the Web site in a manner that requires less memory than storing conventional markup language Web pages.
The present invention satisfies the needs described above by providing a method and system for providing data regarding the operation of a control system, such as a PLC, that does not require a user to create a Web site using a markup language. Moreover, the present invention meets the above needs by providing a method and system for providing data regarding the operation of a control system that stores data defining the Web site in a manner that requires less memory space than storing conventional markup language Web pages. The present invention also provides a method and system for providing data regarding the operation of a control system that includes additional advantages not found in the prior art.
Generally described, the present invention provides a Web server module that is associated with a control system. According to one actual embodiment of the present invention, the Web server module be electrically connected to a backplane of a PLC and receive power and signal information directly from the PLC over the backplane. The Web server module also be connected to the PLC or other type of control system through a serial port, or other network interface port. The Web server also be integrated within a PLC or system controller. The Web server module contains a memory operative to store a non markup language Web site database that completely defines the Web site. Because the Web site database is not stored as markup language documents, it is typically much smaller in size than a similar Web site stored as markup language documents.
The present invention also comprises a computer system operative to receive non-markup language configuration data from a user defining the Web site. This information is stored as a Web site database and is transmitted to the Web server module from the computer system. The Web server module can then utilize the Web site database to dynamically generate a markup language Web page when requests are received.
More specifically described, the present invention comprises a Web server module and a Web server module configuration application. The Web server module is associated with a PLC and is operative to receive data regarding the operation of the control system. The Web server module be connected to the PLC or other type of control system via a backplane interface, a serial port interface, or other type of interface. The Web server module stores a Web site database that completely defines a Web site in a non-markup language format. The Web server module configuration application receives user input to create the Web site database. The Web site database is then transmitted to the Web server module. When a request is received at the Web server module for a Web page, the Web server module utilizes the Web site database to dynamically generate the requested Web page.
The Web site database includes a security profile map that defines a security level and other privilege information for one or more users. When a request is received at the Web server module, the Web server module identifies a user associated with the request and determines if the user is authorized to receive the Web page based upon privileges in the security profile map associated with the user. If the user is authorized to receive the Web page, the Web server module dynamically generates the Web page data and transmits it to the user in response to the request.
The present invention also comprises an apparatus, system, and computer-readable medium for providing data regarding the operation of a control system.
The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
As described briefly above, the present invention provides a method, system, and apparatus for providing data regarding the operation of a control system. According to one actual embodiment of the invention, a system is provided that comprises a Web server module associated with a PLC. The Web server module connect to the PLC through one of several different interfaces to obtain data regarding the operation of the PLC. The Web server module also comprise an interface upon which requests are received for a Web site that provides data regarding the operation of the PLC.
The Web site provided by the Web server module is defined utilizing a remote computer system and a Web server module configuration application. The Web server module configuration application provides an easy-to-use interface for defining the Web site provided by the Web server module. The Web server module configuration application does not require a user to define the Web site using markup language. Rather, the Web server module configuration application allows a user to define the Web site using easy-to-use menus and interfaces.
Once the Web site has been defined, a Web site database is transmitted to the Web server module. The Web server module utilize the Web site database to dynamically generate markup language pages when requests are received. Because the Web site database is not stored as markup language files, the Web site database takes up considerably less memory space than conventional files stored in file systems on conventional Web servers. Additional aspects regarding several illustrative embodiments of the present invention will be apparent from the following
Turning now to the figures, in which like numerals represent like elements, several actual embodiments of the present invention will be described. Referring now to
In the actual embodiment of the invention described herein, the PLC 24 includes an expansion chassis having one or more available slots 25A-25N for receiving I/O modules. According to one actual embodiment of the present invention as shown in
The Web server module 22 comprises a compact but fully functional Web server. As known to those skilled in the art, Web servers typically receive requests for Web pages and respond to those requests. In order to receive such requests, the Web server module 22 include an Ethernet port 30 for receiving requests via the Internet 20. As is well known to those skilled in the art, the Internet 20 comprises a collection of networks and routers that use the transmission control protocol/Internet protocol (“TCP/IP”) to communicate with one another.
The Internet 20 typically includes a plurality of local area networks and wide area networks that are interconnected by routers. Routers are special purpose computers used to interface one local area network or wide area network to another. Communication links within the local area networks be twisted wire pair, or coaxial cable, while communication links between networks utilize 56 KBPS analog telephone lines, 1 MBPS digital T-1 lines, 45 MBPS/T-3 lines, or other communications links known to those skilled in the art. Furthermore, computers such as the Web server module 22 can be remotely connected to either the local area networks or the wide area networks via a permanent network connection or via a modem 30 connected to the Web server module 22 through a RS-232 port 32, and the public switched telephone network 28. It will be appreciated that the Internet 20 comprises a vast number of such interconnected networks, computers, and routers. Additional details regarding the architecture and operation of the Web server module 22 will be described below with respect to
According to one aspect of the present invention, a remote computer 26 be utilized to connect to the Web server module 22 through the Internet 20. As described above, the remote computer 26 utilize a persistent connection to the Internet 20 or utilize a modem 30 to connect through the public switch telephone network 28 to the Web server module 22. The remote computer 26 comprises a standard personal computer and be utilized to perform several functions. First, the remote computer 26 be utilized to execute a Web server module configuration application. The Web server module configuration application comprises an application program that provides an easy-to-use interface for creating the Web site stored in the Web server module 22. As will be described in greater detail below, the Web server module configuration application 48 creates a non-markup language Web site database that describes the Web site served by the Web server module 22. When a user has completed creation of the Web site, the Web server module configuration application transmits the Web site database to the Web server module 22. The Web site database then be used by the Web server module 22 to dynamically generate markup language Web pages in response to requests. Additional details regarding the Web server module configuration application 48 will be provided below with respect to
The remote computer 26 also be utilized to access the Web site available from the Web server module 22. The remote computer 26 utilize a standard Web browser application program, such as INTERNET EXPLORER® available from MICROSOFT CORPORATION, or NETSCAPE NAVIGATOR® available from NETSCAPE. The remote computer 26 can request and receive Web pages generated by the Web server module 22 in a conventional fashion. No additional software or application programs need to be installed on the remote computer 26 in order to request, receive, and display the Web pages. Additional details regarding the architecture and operation of the remote computer 26 will be provided below with respect to
Turning now to
Turning now to
The mass storage device 44 is connected to the CPU 32 through a mass storage controller 42 connected to the bus 34. The mass storage device 44 and its associated computer-readable media, provide non-volatile storage for the computer. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed by the remote computer 26. By way of example, and not limitation, computer-readable media comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer. This definition of computer-readable media also applies to the media contained within the Web server module 22 described herein.
A user enter commands and information into the remote computer 26 through input devices 62, such as a touch screen, a scanner, a keyboard, or a mouse. Other input devices include a microphone, keyboard, joystick, game pad, satellite dish, or the like. These and other input devices 62 are often connected to the CPU 32 through a serial input controller 60 that is coupled to the system bus 34, but be connected by other interfaces, such as a game port or a universal serial bus (“USB”). A display 58 also be driven by a display controller 56 connected to the system bus 34. In addition to the display 58, the remote computer 26 include other peripheral output devices not shown in
As described briefly above, the remote computer 26 operate in a networked environment using logical connections to a Web server module 22 through the Internet 20. The remote computer 26 connect to the Internet 20 through a network controller 52. Alternatively, the remote computer 26 include a modem (not shown) and use an Internet service provider (“ISP”) to establish communications with the Internet 20. It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the remote computer 26 and the Web server module 22 be used.
A number of program modules be stored in the mass storage device 44 and RAM 36, including an operating system 46 such as the WINDOWS NT® operating system from MICROSOFT® CORPORATION of Redmond, Wash. The mass storage device 44 and RAM 36 also store a Web browser application 50. The Web browser application 50 comprises a conventional Web browser application such as MICROSOFT′S INTERNET EXPLORER® or NETSCAPE NAVIGATOR®. As will be described in greater detail below, the Web browser application 50 be utilized to navigate a Web site provided by the Web server module 22.
The mass storage device 44 and RAM 36 also store a Web server module configuration application 48. The Web server module configuration application 48 provides a user interface for designing and creating the Web site that is served by the Web server module 22. Rather than require a user to program in a markup language, the Web server module configuration application 48 allows a user to create a Web site by providing selections on a number of display screens. The Web server module configuration application 48 stores the user-made selections in a Web site database and transmits this database to the Web server module 22. The Web server module 22 then utilizes the contents of the Web site database to dynamically generate markup language pages when a request is received. Additional details regarding the operation of the Web server module configuration application 48 will be described below with reference to
Turning now to
Turning now to
The CPU core 80 provides the controller, code memory, data memory, and a real time clock with battery-backed non-volatile RAM. According to the actual embodiment of the invention described herein, the CPU core 80 comprises a NET SILICON NET+ARM-40 application specific integrated circuit (“ASIC”). This ASIC is a highly-integrated circuit based on an ARM-7 32 bit processor, and includes access to several peripherals. In particular, the CPU core 80 includes a 32-bit RISC industry standard ARM 7 processor, two asynchronous serial ports with all handshaking signals, a DRAM controller with glueless DRAM interface, glueless flash memory interface, 15 general purpose 32-bit registers, IEEE 802.3 compliant 10 base-T/100 base-TX MAC Controller with MII interface, and additional features known to those skilled in the art. Other similar CPU cores are known to those skilled in the art and be utilized to implement aspects of the present invention.
Firmware for controlling the operation of the Web server module 22 as well as the Web server application itself reside in flash memory 82. According to the actual embodiment of the invention described herein, 4 512 K×16 flash integrated circuits are used to obtain the quantity of code space required. The architecture arranges the flash as two individual banks, of 512 K×32 each. A RAM memory 84 is also provided for general use. According to the embodiment of the present invention described herein, 2 4M×16 synchronous DRAMs provide the general use RAM memory. These devices sit on the system bus and are configured as a 4 M×32 wide SDRAM memory space.
An integrated real time clock and non-volatile RAM 92 is also provided. According to the actual embodiment of the present invention described herein, a single device providing a 32K×8 low power SRAM, year 2000-compliant real-time clock, 32.768 kHz crystal, and a 10-year lithium battery is utilized. This device is addressed like a standard 8-bit SRAM and resides on the system bus. The real-time clock information is located in the top eight memory locations of the SRAM.
A backplane interface ASIC 86 is also provided to enable the CPU core 80 access to the PLC 24 backplane 64. An electrical connection is made between the Web server module 22 and the PLC backplane 64 through the use of a backplane connector 88 which is electrically connected to the backplane interface ASIC 86. The ASIC require an external SRAM 90 for data storage. The SRAM 90 acts as a shared RAM that can be utilized by both the PLC 24 and the Web server module 22.
An RS-232/RS-485 transceiver 98 is also electrically connected to the CPU core 80. The RS-232/RS-485 transceiver 98 supports full handshaking in its RS-232 configuration to allow connectivity to external hardware such as modems and printers. The RS-485 hardware is also supported for connectivity to PLCs 24 via RS-485 based protocols. An RJ45-type connector 100 is also provided for connecting to external devices.
An Ethernet physical layer integrated circuit (“IC”) 94 is also connected to the CPU core 80 for providing an IEEE 802.3 compliant 10 base-T/100 base-TX Ethernet communications port. This port has four major components: an integrated circuit to handle the 10 base-T/100 base-TX physical layer requirements, an isolation transformer to handle a 1500v RMS isolation requirement, a precision 25 mHz crystal for Ethernet timing, and an RJ45 connector 96 for the physical connection to a twisted pair cable.
The Web server module 22 is supplied power from a +5 volt backplane power supply according to one embodiment of the invention. According to another embodiment of the invention, the Web server module 22 receives power from an external +5 volt power supply. Additionally, LEDs 102 provide status information regarding the operation of the Web server module 22 and the Ethernet physical layer IC 94.
Turning now to
The flash memory 82 also contains a module configuration database 110. This database includes an Ethernet database providing information for the Ethernet controller and a serial port database that provides information regarding the configuration of the serial port. The flash memory 82 also includes a Web site database, also called a screen database 112, that fully defines the Web site to be served by the Web server module 22. As described in greater detail below, the application program executing on the Web server module 22 utilizes the contents of the screen database 112 to dynamically generate markup language Web pages.
The screen database 112 comprises a form map 116, a screen map database 118, a table definition map 120, a tag database 122, a register to tag map 124, and a graphics database 126. The form map is utilized by the Web server module 22 to process incoming form posts or other similar write requests. Those incoming posts can be in the form of user inputs to the Web server via the browser, such as button presses or update requests. Additional details regarding the form map 116 are described below with reference to
The table definition map 120 contains information for the style and header details associated with each table defined and included within a page, defined in the screen map database. The table definition map 120 is described below with reference to
The register to tag map 124 comprises a mapping of the PLC to Web server type data words to the tag database 122. The register to tag map 124 is used by the firmware to effectively retrieve incoming data from the PLC 24. Additional details regarding the register to tag map 124 are described below with reference to
Turning now to
Turning now to
As shown in
Referring now to
Turning now to
As shown in
As mentioned above, the tag info data structure 152A include an alarm offset and an event offset. The alarm offset is a pointer to an alarm attribute object which defines conditions upon which an alarm should be generated and other alarm specifications for the particular tag. For instance, an e-mail notification, a pager notification, or a printed report be generated when the value of a tag satisfies the condition set forth in the alarm attribute object. An event attribute object provide similar functionality for providing notifications that a particular event has occurred, for the particular tag.
Turning now to
The purpose of the register to tag map 124 is to correlate register data incoming to the Web server directly to tag definitions defined by the user in the tag database 122. Of the data types accessible, there are single bit types, 8 bit types, 16 bit types, and 32 bit types, all which can be mapped into the shared RAM 90 associated with the backplane interface ASIC 86. Bit types are segmented to the first several registers of the type X file type register map 154. A similar type Y file type register map 155 exist. Multiple file type register maps exist as defined by the backplane or other communication interface definition and/or the PLC processor. The register to tag map 124 then includes offsets to word data objects 156A-156N and bit data objects 157A-157N, for each file type supported. The word data object map 156A defines the number of words used within the file type map, and for each 8 bits in the shared RAM 90 segmented for non-bit type usage (as shown in the type X file type register map 154 under ‘other types’), an entry exists defining the access type and the tag index. Similarly for the bit data object map 157A-157N, a definition of the number of words used for bits is provided, and then for each bit, an entry exists defining the access type and the tag index. This provides a correlation from the registers incoming to the Web server, to the tag database 122. When the data is read it can then be evaluated appropriately and placed in the local RAM 84.
Referring now to
The structure of the graphics database 126 comprises an element describing the total number of graphics, a graphics name offset, and a graphic container offset. The graphic name offset describes the offset from the beginning of the graphics database 126 to the base of the graphic name object 158. Similarly, the graphic container offset identifies the offset that, when added to the value of the base of the graphics database 126, will give the base to the graphics container object. In this manner, entries in the graphics database 126 point to a graphic name 158 and graphic container 160A.
The graphic container 160A identifies the total number of bytes for a graphic and actually includes the data defining the graphic. In this manner, each of the graphics to be utilized in the Web site provided by the Web server module 22 be contained in a single database. The graphics database 126 is parsed by the Web server module 22 when responding to requests for Web pages and the appropriate graphic is extracted. This process will be described in greater detail below.
Turning now to
The security screen 164 provides an authentication mechanism to determine whether a user is authorized to view the predefined Web site 162. The user be asked to provide a login name and password in order to gain access to the predefined Web site 162. Once the user has been authenticated, the user is presented with a main menu screen 168. The main menu screen presents links to other menu screens and data screens. In particular, the main menu screen 168 provides links to a security profile screen 170A, an Ethernet status screen 170B, a serial port status screen 170C, a “Who's on-line?” screen 170D, a data access menu 170F, an alarm screen 170G, and an event screen 170H.
The security profile screen 170A be utilized by system administrators to change the access rights for the users of the Web server module 22. The Ethernet status screen 170B provides basic status information for the Ethernet connection as well as status of the physical Ethernet port on the Web server module 22. The serial port status screen 170C provides similar information for the serial port of the Web server module 22. The “Who's on-line?” screen 170D provides the identity of other users currently logged into the Web server module 22. The alarm screen 170G provides access to the current alarm table resident in the Web server module 22. The alarm table includes information such as the state, tag name, condition, value, and acknowledgment information for defined alarms. Similar information for events also be obtained through the event screen 170H. A link from the screens 170A-170H exists to return the user back to the main menu screen 168.
The data access menu 170F provides access to data access screens 174A-174N. Data access screens 174A-174N provide table-oriented read/write data, 20 tags defined per screen, in this example. If the user wishes to add or modify the tag definitions, the table definitions, the various page contents, the graphics, or the linkages, the Web server module configuration application 48 must be utilized. Those skilled in the art should appreciate that the predefined Web site 162 comprises a baseline Web site for the Web server module 22. It is intended that a user will utilize the Web server module configuration application 48 to customize the predefined Web site 162 to a specific application. Moreover, the types of screens described as being included with the predefined Web site 162 include other types of data, status, and administration screens known to those skilled in the art.
Referring now to
A power up initialization task 198 is executed in response to a warm or cold start of the Web server module 22. The power up initialization task 198 initializes all necessary memory and code for the operation of the Web server module 22. When the power up initialization task 198 has completed, the HTTP server task 176 is executed. The HTTP server task 176 provides the main functionality for dynamically generating markup language pages in response to validated HTTP requests. The HTTP server task 176 performs such functionality both for outgoing markup page data and for incoming form post requests. The HTTP server task 176 is described in greater detail below with reference to
The PLC communications maintenance task 196 provides functionality for interfacing with the PLC backplane 64. The PLC communications maintenance task 196 provides a read data task that maintains incoming data from the PLC 24 to the Web server module 22. The read data task continually accesses the incoming Web server registers from the PLC 24, compares them to their last current state, and moves data appropriately. If the particular registers are defined as alarms or events, then notifications are issued to the appropriate alarm or event queue through the PLC communications maintenance task 196 read cycle. The PLC communications maintenance task 196 also includes a write data task. This task takes messages from a write message queue and writes the properly formatted outgoing data through the backplane communication mechanism for transmission to the PLC 24.
A bite task 194 is also provided for manufacturing testing and verification of the Web server module 22. Alarm support 192 is also provided to maintain a first-in/first-out alarm queue in NVRAM. Support functions include adding an alarm, acknowledging an alarm, deleting an alarm, and providing alarm queue data to the HTTP server task 176. Similarly, event support 190 functionality is also provided to maintain a first-in/first-out event queue. Support functions include adding an event, deleting an event, and providing event data to the HTTP server task 176. A check online status task 186 is also provided that determines whether users are currently online with the Web server module 22. The check online status task 186 maintains an online database identifying those users that are currently online. If a request or response is not received from a user within a predefined period of time, the check online status task 186 will change an entry in an online database to indicate that the user is no longer online. The security profile support mechanism 188 accesses both the security profile database 113 and the online database to grant access to the Web server module 22 based upon incoming data requests. Tag database support 184 is also provided to allow easy access to the information within the tag database 122 stored in flash memory and the values for each tag stored in RAM. An LED maintenance task 204 is also provided that executes to periodically update the LEDs 102 of the Web server module 22. Serial port database support 182 and Ethernet database support 180 are also provided for providing access to the serial port data table and the Ethernet data table, respectively. A communication support task 178 is also provided to support sending and receiving messages through the serial port 32 or the Ethernet port 30. A real time clock task 202 is also provided for maintaining the internal time and date as needed for by the Web server system.
Referring now to
As known to those skilled in the art, the HTTP protocol is typically stateless. This means that when a client browser issues a request, the Web server issues a response, and the session is terminated. No state information is typically maintained about a client browser request. However, the Web browser 50 utilized in the actual embodiment of the present invention described herein utilizes a script to periodically request a page from the HTTP server task 176. In this manner, the HTTP service task 176 through the check online status task 186 can maintain the state of each connection.
The HTTP server task functionality in the current implementation is based upon a package commercially available from NETSILICON, INC., and is an application available with the NET+OS operating system functional with the NET+ARM-40 microprocessor ASIC. The HTTP server task 176 generally comprises two interface routines. The use of the two “APP PRE PROCESS URL” and “APP SEARCH URL” allow the application to initialize, validate, and reply to a browser page content or form post request. The “APP PRE PROCESS URL” routine 208 authenticates the request and initializes the HTTP server for the proper MIME type content for the requested data. The “APP PRE PROCESS URL” routine 208 will be described below with reference to
Turning now to
If, at state 1504, it is determined that the requested file does exist within the screen database 112 and that the requested file type is a graphic file, the state machine 1500 transitions to state 1508. At state 1508, access is initialized within the HTTP server for the .GIF type, for the requesting handle. If, at state 1504, it is determined that the requested file is contained in the screen database 112 and the requested file is a markup language file or a tag, the state machine 1500 transitions to state 1510, where access is initialized properly within the HTTP server for the .HTM type, for the requesting handle. Turning now to
If, at state 1604, it is determined that the request is for a markup language file, the state machine 1600 transitions to state 1610. At state 1610, an index is made into the screen map database 118 to locate the requested file. The state machine 1600 then transitions to state 1618 where the requested file is issued. An illustrative routine for issuing the screen data is described below with reference to
If, at state 1604, it is determined that the incoming server request comprises a form posting, the state machine 1600 transitions to state 1612. At state 1612, the posted form is then further validated and placed on a queue to be written to memory. An illustrative routine for posting form and tag data is described below with reference to
Referring now to
At states 1704, 1706, and 1708, the appropriate screen and contents for the requested page are identified within the screen map database 118. Once the location of these objects have been identified, the individual objects contained on the requested screen be rendered. The rendering takes place at steps 1712A-1712M, where the HTML for a header, footer, text, menu, graphic, horizontal rule, address, title, background color, clock, anchor list, text break, or logout button, respectively are rendered. Additionally, a table be rendered at state 1714. An illustrative routine for rendering a table is described below with reference to
Referring now to
From state 1806, the state machine 1800 continues to state 1808, where the type of table to be rendered is determined. If an Ethernet or serial port status table is to be rendered, the state machine 1800 transitions to state 1810, where the HTML for a fixed table data comprising the Ethernet status or serial port status table is rendered. An illustrative routine for rendering HTML for a fixed table is described below with reference to
If, at state 1808, it is determined that an alarm, event, security profile, or online status table is to be rendered, the state machine 1800 transitions to state 1812. At state 1812, HTML for queued table data is rendered. An illustrative routine for rendering queued table data is described below with reference to
If, at state 1808, it is determined that the requested table is a table containing ASIC data, the state machine 1800 transitions to state 1814. At 1814, HTML for a table having variable data is rendered. An illustrative routine for rendering variable table data is described below with reference to
Referring now to
Referring now to
From state 2008, the state machine 2000 transitions to state 2010, where the column width, alignment, and style data is obtained for the current column entry. From 2010, the state machine 2000 transitions to 2018, where the HTML for the current cell is rendered with the appropriate data. If additional cells need to be rendered, the state machine 2000 transitions back to state 2010, where additional cells are rendered as described above. If no additional cells need to be rendered in the current row, the state machine 2000 continues to state 2020. If additional rows are to be displayed, the state machine 2000 transitions back to state 2006. If all rows have been displayed, the state machine transitions from state 2020 to state 2024, where it ends.
Referring now to
From state 2106, the state machine 2100 transitions to state 2108 where the type of table to be displayed is identified. If an alarm table is to be displayed, the state machine 2100 transitions to state 2110, where the alarm data is retrieved. If an online status table is to be displayed, the state machine 2100 transitions to state 2114, where the online status data is retrieved. If the table to be displayed is an event table, the state machine transitions to state 2112, where the appropriate event data is retrieved. If the table to be displayed is a profile table, the state machine 2100 transitions to state 2109 where the profile data is retrieved.
From states 2110, 2114, 2112, and 2109, the state machine 2100 transitions to state 2116. At state 2116, the HTML tag for a cell in the appropriate table is rendered. If additional data types in the current row exist to be rendered, the state machine transitions back to state 2108. If the end of row has been reached, however, the state machine 2100 transitions to state 2118, where an end of row tag is issued. If more rows exist to be displayed, the state machine transitions back to state 2104. If, however, all rows have been displayed, the state machine transitions from state 2118 to state 2120 where which rows have been displayed are updated as necessary. The state machine 2100 then transitions to state 2121, where it ends.
Referring now to
Referring now to
At state 2310, the source for the table to be posted is obtained. The state machine 2300 then transitions to state 2312, where the user privileges for the particular type of data to be posted is validated. If the user does not have valid privileges, the state machine 2300 transitions to state 2325 where an error message is generated. If the user does have valid privileges, the state machine 2300 transitions from state 2312 to state 2314. At state 2314, the mapping information mapping the posted tag data to the appropriate memory register within the PLC 24 is obtained. The state machine then transitions to state 2316, where the posted string data is converted into an appropriate numerical type to be posted. The state machine 2300 then transitions to state 2318 where the data type is validated. If the data type is invalid, the state machine transitions to state 2325 where an error is provided. If the data type is valid, the state machine transitions to state 2320, where the posted data is placed in a write queue to be written to the backplane interface ASIC 86 and, subsequently, to the PLC 24. From state 2320, the state machine 2300 transitions to state 2326, where it ends.
If, at state 2308, it is determined that the form type is for a function posting, the state machine 2300 transitions from state 2308 to state 2322. At state 2322, the privileges for the user are validated. If the user does not have valid privileges, the state machine 2300 transitions to state 2325 where an error message is provided. If the user's privileges are valid, the state machine transitions to one of states 2324A-2324N, depending on the type of posting made. The states 2324A-2324N correspond to posting of forms for clearing ethernet counters, clearing serial port counters, fast update, acknowledging selected alarms, deleting selected alarms, acknowledging all alarms, deleting selected events, modifying security privileges, setting a real time clock, uploading table contents, uploading alarm queue contents, uploading event queue contents, logging a user onto a session, or logging a user out of a session, respectively. From each of the states 2324A-2324N, the state machine 2300 transitions to state 2326, where it ends.
Similarly, a read data task 222 continuously executes to pull data from the type X data file 70 stored in the shared RAM and to store the data in the local read data table 84 for quick access. In order to pull data from the shared RAM in this manner, the read data task 222 communicates with the ARM controller 80 and the backplane ASIC 86. An illustrative state machine for providing a read data task will be described below with reference to
Referring now to
Referring now to
The state machine 2700 begins at state 2702, where a new write message queue entry is retrieved from the write message queue 236 and evaluated. Using the tag database 122, the state machine 2700 then transitions to state 2704, where the file data is written to the appropriate location, either the backplane ASIC 86 or the shared RAM space 70 or 72. If the tag database 122 indicates alarm or event conditions have been met, entries are made into those queues, respectively. From state 2704, the state machine 2700 transitions to state 2706, where the message buffer is cleared. The state machine 2700 then transitions back to state 2702 where the write message queue is examined for more messages to evaluate. If the queue is empty, the state machine 2700 transitions to state 2707 and ends.
Turning now to
Turning to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
The screen 308 shown in
From the foregoing, it should be appreciated that the present invention provides a Web server module 22 that can interface with a PLC 24 to provide a Web site, including data regarding the operation of the PLC 24. The present invention also provides a Web server module configuration application 48 that allows a user to completely define the operational characteristics of the Web server module 22 and the Web site to be provided. The Web server configuration application 48 does not require the user to understand markup language or programming. Rather, the user utilize the Web server module configuration application 48 to configure the Web server module 22 by simply selecting and modifying a number of predefined Web pages. Additional pages and associated page linkages can be added at the user's discretion. The user then configure these Web pages in a simple and intuitive manner for their own particular application.
While an illustrative embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.
This application is a continuation of U.S. Provisional patent application Ser. No. 09/842,366, filed Apr. 24, 2001, which claims the benefit of U.S. Provisional Patent Application No. 60/199,207, filed Apr. 24, 2000. These applications are expressly incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60199207 | Apr 2000 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09842366 | Apr 2001 | US |
| Child | 13668084 | US |
