Service provider for providing data, applications and services to embedded devices and for facilitating control and monitoring of embedded devices6601086Abstract A service provider for embedded devices is disclosed for controlling, monitoring and/or updating embedded devices. The service provider includes a computer having communications hardware for communicating over a computer network. The computer also includes a storage device and a processor. The service provider further includes a database of embedded device information that contains information relating to a number of embedded devices. An embedded device communications module is used by the service provider to communicate with a number of embedded devices. The service provider further includes a computer network communications module for communicating with computers via the computer network. In addition, the service provider has a database interface module for accessing the information in the embedded device information database. The service provider may also include an information collection manager for searching the computer network and for accessing and obtaining updated information from the computer network relating to the embedded devices. Certain information in the embedded device information database is linked to certain updated information. A system that is used in combination with the service provider for embedded devices includes a plurality of service providers in electronic communication with a central provider to coordinate communications between embedded devices and service providers for embedded devices. Claims We claim: Description BACKGROUND
TABLE 1
1A Interfaces supported
1B byte ordering type
1C device identification
1D device address
1E software version
1F communication protocol version
1G maximum communication packet size
1H nonvolatile storage flag (indicates yes or no)
1I nonvolatile storage size, starting address
1J static file system flag
1K dynamic file system flag
As illustrated in Table 1, the capabilities table 38 may include an indication of what interface definitions (1A) the embedded device 24 supports. The interface definitions (1A) field and its use will be more fully described herein. The capabilities table 38 may also indicate the byte order type shown at line (1B). This byte ordering type (1B) may indicate whether the embedded device is big endian or little endian. The table 38 may also indicate what the device identification, shown at line (1C), is for that particular embedded device 24. The device address, shown at line (1D), if any, may also be stored in the capabilities table 38. For compatibility purposes, the version numbers, shown at line (1E), for the software being used may also be stored. Similarly the communication protocol version numbers, shown at line (1F), may also be stored. Particulars about the communication may also be stored. For example, as shown in Table 1, the maximum communication packet size, shown at line (1G), may be stored. A nonvolatile storage flag shown at line (1H) may indicate whether there is nonvolatile storage accessible by the embedded device 24. Pertinent information about the nonvolatile storage may also be stored, such as the nonvolatile storage size and its starting address, shown at line (1I). A static file system flag, shown at line (1J), may indicate whether there is a static file system. Similarly, a dynamic file system flag, shown at line (1K), may indicate whether there is a dynamic file system. The capabilities table 38 is useful in that developers or engineers can obtain the capabilities table 38 and ascertain the characteristics and capabilities of the embedded device 24. Device manufacturers 28 may also have other device information 40. For example, if certain embedded devices 24 were known to fail after a period of time, the device manufacturer 28 may have this information. In addition, a manufacturer 28 may be aware of certain parts of an embedded device 24 that are known to wear over time and cause erroneous data. Device manufacturers 28 would probably also be aware of embedded device 24 recalls. As will be appreciated by those skilled in the art, device manufacturers 28 may be aware of a number of other items 42 or things that may be relevant to an embedded device 24. The device manufacturers 28 may make this other information 42 available. FIG. 3 is a block diagram of data or information that may be available from an information provider 30. Information providers 30 are entities that provide any type of data or information. Typically the data or information is provided in a form of electronic communication. FIG. 3 illustrates examples of the data that may be provided by an information provider 30. Weather information 44 may be provided. Date and time information 46 may be provided. Bar code information 48, such as what consumer product is identified by a particular bar code, may also be provided. Status information 50 about a particular item, thing or place may also be provided. Of course, those skilled in the art will appreciate that many other types of information 52 may also be provided. FIG. 4 is a block diagram of data or information that may be collected by a data collector 32 or requestor. Data collectors 32 are entities that collect and/or gather information or data. Typically the data or information is transmitted to the data collector 32 in electronic form. The items shown in FIG. 4 illustrate examples of the data that may be collected by a data collector 32 concerned with monitoring items for a utility company or the like. A meters read 54 piece of data may indicate how many and which meters in a certain area have been read. Billing data 56 may indicate past bills for particular customers and whether they have been paid. Rate information 58 may include various rates and indicate when each rate should be charged and to which customers. Usage data 60 may store past usage information to show peaks and valleys of usage by individual consumers as well as by groups of consumers. Performance information 62 may be information about the various embedded devices 24 and their related components and how they perform in the field, how long they typically last, what types of problems are occurring in the field, etc. Status and/or maintenance data 64 may also be stored. This data 64 may include the current status of the particular embedded devices 24 and/or larger groups of embedded devices 24. It may also include a maintenance history as well as future scheduled maintenance activities. Of course, those skilled in the art will appreciate that other data or information may also be collected by a data collector 32. FIG. 4 is only illustrative of types of information that may be collected and stored by a data collector 32 and is not meant to limit the broad scope and usefulness of the present embodiments. FIG. 5 is a block diagram of the modules and data or information that may used by a controlling/monitoring service 34. A database 66 may be used that includes the embedded devices 24 that need to be controlled and/or monitored. The information in this database 66 may include device identifications, routing information, location, device capabilities, etc. In addition, this database 66 may also include what controlling should be accomplished for each device and the particular control commands that should be sent. Those skilled in the art will appreciate that any data regarding or relating to the embedded devices 24 may be stored in this database 66. Of course, this database 66 may actually be a number of databases or a number of files. A notification database 68 may include owner information and technical contacts. For example, for each device 24 being monitored and/or controlled, there may be an owner listed, who is likely paying for the service, as well as a technical contact person to contact when particular events occur. For example, if an embedded device 24 stops functioning, a controlling/monitbring service 34 may be instructed to immediately contact the technical contact person via pager, e-mail, telephone, etc. A managing module 70 may manage the operation of the controlling and/or monitoring by reading in, or causing to be read it, data that indicates what actions should take place and by writing out, or causing to be written out, any output data. A communications module 72 may handle communications functions. Separate monitoring functions 74 may be accessed and used to monitor the embedded devices 24. For example, a library of monitoring functions 74 may be compiled to access and execute in monitoring various embedded devices 24. Typically, when engineers have developed software to monitor a particular type of embedded device 24, these functions to monitor may be reused in monitoring the same or similar types of embedded devices 24. Similarly, controlling functions 76 may be available and may be reused with similar types of devices 24. FIG. 6 is block diagram illustrating the major hardware components typically utilized in embedded devices 24 or systems and embodiments herein. An embedded device 24 typically includes a processor 78 or embedded computer 78 in electronic communication with input devices 80 and/or output devices 82. The embedded computer 78 is operably connected to input 80 and/or output devices 82 capable of electronic communication with the embedded computer 78, or, in other words, to devices capable of input and/or output in the form of an electrical signal. Sometimes the input and output device(s) 80, 82 and the embedded computer 78 or processor 78 are both housed within the same physical structure. The input and/or output data sent and/or received may be referred to herein as interface data. FIG. 7 is block diagram illustrating the major hardware components typically utilized in an embedded device network 26 and embodiments herein. An embedded device network 26 typically includes a host computer 84 or gateway computer 84 networked together with one or more embedded devices 24. The host computer 84 acts as a gateway between the embedded devices 24 and other computers (e.g., other computers on the computer network 22). In the present embodiments, the systems and methods herein are used to access a networked computer system where a host computer 84 is connected to one or more embedded devices 24. Typically the embedded device 24 includes an embedded computer 78 connected to input and output devices 80, 82. Particularly, in the present embodiments, the embedded computer 78 typically is a microcontroller (not shown). However, it will be appreciated by one skilled in the art that the functions and processing normally carried out by a microcontroller could be carried out by larger processors, whether they are part of a larger controller or part of a typical computer system. The embedded computer 78 is typically remote from the host computer 84 in that the embedded computer 78 and host computer 84 are each computers capable of functioning on their own. The term remote does not necessarily mean that the embedded computer 78 is at a different location than the host computer 84, although in many embodiments the host computer 84 is at a different location than the embedded computer 78. Those elements discussed as being stored and/or implemented by the remote computer 78 could be stored and/or implemented at the host computer 84, in some circumstances. The present systems and methods have broad application to many kinds of computer networks. Generally, embodiments of an embedded devices service provider 20 provide monitoring and/or controlling of embedded devices 24. The embedded computer 78 is operably connected to input and/or output devices 80, 82 capable of electronic communication with the remote computer 78, or, in other words, to devices capable of input and/or output in the form of an electrical signal. The service provider 20 establishes communication with the embedded device 24 to send and/or receive input and/or output data and to thereby interact with embedded devices 24. The gateway 84 or host computer 84 is a broadly defined digital computer. The embedded device 24 or system 24 includes a digital computer but does not have typical input and/or output devices such as a keyboard, mouse, and/or monitor. A computer, as used herein, is any device that includes a digital processor capable of receiving and processing data. A computer includes the broad range of digital computers including microcontrollers, hand-held computers, personal computers, servers, mainframes, supercomputers, and any variation or related device thereof. The input and output devices 80, 82 include any component, element, mechanism, appliance, or the like capable of receiving and/or generating an electronic signal. Examples of devices within the scope of the term device includes a vending machine, a telephone, a door lock, a temperature sensor, a motor, a switch, a light, etc. In current design, the gateway computer 84 is typically an IBM-compatible personal computer running Linux, Microsoft Windows 95/98/2000 or the Microsoft Windows NT operating system. One possible item that may be used with the embodiments herein is a vending machine (not shown). Many vending machines include one or more microcontrollers for controlling different parts of the vending machines. These microcontrollers fall within the scope of embedded computer. The input and output devices include the buttons for selecting items from the vending machine, switches for allowing those items to be dropped down to the user, lights for indicating which items are gone, the change release for releasing any change, etc. As known in the art, this vending machine embodiment includes the input and output devices 80, 82 and the remote computer(s) integrated within the same structure. Those skilled in the art will also realize that the embedded computer 78 may be in a separate structure from its attached input and output device(s) 80, 82. Many of the modern devices do come with embedded microcontrollers, for example, many cellular phones, pagers, and the like come with embedded microcontrollers. The host or gateway computer 84 may be connected to the embedded devices 24 through a variety of connections, including RS 232, RS 485, modem, powerline, wired connection, wireless connection, etc. Similarly, the embedded computer 78 may be connected to various input and output devices 80, 82 through a variety of ways. As stated, typically the remote computer 78 comprises a microcontroller (not shown). Microcontrollers often have input/output ports for communicating with external devices. The specifications of the particular microcontroller often dictate how a device is connected to the microcontroller. Those skilled in the art appreciate how different devices may be connected to computers, whether they are embedded computers, standard desktop computers, mainframes, etc. FIG. 8 depicts a block diagram of the major hardware and software components of an embodiment of an embedded device network 26. As shown, the hardware elements of FIG. 8 correlate with those of FIG. 7. Those skilled in the art will appreciate that there are a variety of ways to interconnect the various hardware components, and that there are various configurations wherein one or more of the hardware elements may be eliminated by moving functionality from one hardware element to another. The present embodiments enable a user to monitor and/or control services provided by the embedded device 24 through the service provider 20. The services of the embedded device 24 may be exposed by the embodiments such that they may be accessed over the computer network 22 and in an efficient manner. In the present embodiments, data from input and/or output devices 80, 82 is read in and/or written out through input/output ports 86. An embedded application program 88 includes the executable instructions that directly interface with these input and/or output ports 86. Usually embedded applications 88 have a main loop which is iterated through over and over. Of course, embedded application developers may write an application that does not have a main loop that is continually iterated through. The principles herein could be applied to those applications not having a main loop and provide substantially the same benefits as are realized in the present embodiments. Users, through software running on the embedded device service provider 20, may wish to access certain services provided by the embedded device 24. Services include different functions, variables, events, and/or files. For example, users may wish to execute particular functions, access certain variables, check on specified events, or access specific files. In current design, the services that a user may need access to are identified and listed. The identification of services also includes information about the certain services. This identification of certain services may be accomplished in a variety of ways. For example, in current design, a table 90 of services may be stored at the embedded computer 78. The services table 90 may be stored as a file, or it may be stored as static data that is compiled with the application 88, or it may be stored on a storage device (not shown) external to the remote computer 78. Those skilled in the art will realize that there are a variety of ways to store basic information about certain services provided by the application code running on the embedded computer 78. Table 2 contains pseudocode illustrating what types of information may be stored in the services table 90.
TABLE 2
2A "FunctionA", function, word, void, &FunctionA
2B "FunctionB", function, int, float, &FunctionB
2C "VarA", variable, int, void, &varA
2D "VarB", variable, string, void, &varB
2E "EventA", event, byte, void, &eventA
2F "EventB", event, int, void, null
2G "FileA", file, void, void, &fileA
2H "FileB", file, void, void, &fileB
As illustrated in Table 2, the services table 90 may include information such as the name or identification of the service, the type of service (e.g., whether it is a function, variable, event, file, etc.), the input parameter type, if any, the return type, if any, and the address of the service. Information about function FunctionA, shown at line (2A), is illustrated indicating that it is a function, it takes a word as an input parameter, it returns nothing (void), and its address is indicated at &FunctionA. Line (2B) illustrates the information about another function, FunctionB. Relevant information about variables are illustrated at lines (2C)-(2D). Information about events is illustrated at lines (2E)-(2F). Events may be any type of data. For example, an event could be a variable, a particular register, an interrupt, etc. Events may be particularly useful for items that occur asynchronously. Examples of asynchronous types of events include an alarm going off or an external LED changing. Information about certain files are illustrated at lines (2G) and (2H). By storing information about certain services at the remote computer 78 or at the embedded device 24, software at the embedded device service provider 20 can readily ascertain what services are available at the embedded device 24. Usually the application code 88 defines the services. The services table 90 functions to provide information about certain services, where the information would be useful to a user at the host computer 84, to the service provider 20 or to a requestor across the computer network 22. A capabilities table 98 may also be provided at the embedded computer 78. In current design, an embedded interface module 92 provides access between the services at the embedded computer 78 and software running at the host computer 84 and/or to software running at the embedded devices service provider 20. In embodiments herein, the interface module 92 uses information in the services table 90 to access the desired service on the remote computer 78. Further, in the presently preferred embodiment, the interface module 92 is reentrant code. The interface module 92 communicates through a communications port 94. In current design, a communications module 96 provides communication using the communications port 94. One skilled in the art will appreciate, however, that the interface module 92 may include the code necessary to directly interface with the communications port 94 at the remote computer 78. The communications module 96 or code provides access to the communications port 94, and ensures that data is given to the communications port 94 in appropriately sized and formatted pieces, and that data received from the communications port 94 is correctly read from the port 94. The host computer 84 includes a communication port 100 in electronic communication with the communications port 94 of the embedded device 24. As discussed earlier, there are a variety of such ports available with computers that are capable of interfacing with a remote and/or embedded computer port. A communication module 102 provides features similar to those provided by the communications module 96 of the embedded computer 78. The communications module 102 correctly formats data that is written to and read from the communications port 100. The host computer 84 provides access to the services provided at the embedded computer 78 and at the embedded device 24. In the present embodiments, a portion of the capabilities table 98, the interfaces supported information, is retrieved from the embedded device 24 and from it a list of the services is created at the host computer 84 and/or at the service provider 20 that substantially corresponds to the services table 90. The list of services at the host computer 84 is referred to in FIG. 8 as services information 104. The services information 104 indicates what services are available at the embedded device 24 and what data types, if any, are used with individual services. This facilitates access via the host computer 84 to the embedded device 24. In current design, a process is initially started on the host computer 84 and/or by the service provider 20 that causes the services information 104 to be created. The device access controller 106 provides this initial direction, in current design. As stated, the embodiments may provide access to the services of the embedded device 24 to computers that are in electronic communication with the computer network 22 and to the service provider 20. To facilitate access by computers, the host computer 84 and/or the service provider 20 may include servers. A web server 108 may be started at the host computer 84 and/or at the service provider 20. The web server 108 may provide a web interface to services at the embedded device 24. For example, the data and/or services of the embedded device 24 may be represented graphically through HTML pages. Thus, the device access controller 106 may create web pages (not shown) from the services available at the embedded device 24, and the web server 108 may service HTTP requests for these web pages. A device access server 110 may also be included at the host computer 84 and/or at the service provider 20 to service client requests for services of embedded devices 24. In current design, the device access server 110 accesses the services information 104 and makes this information available to clients at client computers across the computer network 22 (for example, to data collectors 32 and/or to controlling/monitoring services 34). FIG. 9 illustrates the software and data components that may be utilized in an embodiment of a service provider 20 for embedded devices. The service provider 20 includes a database 112 of embedded device information. This database 112 may be made available to, or made accessible by computers in electronic communication with the computer network 22. Database as used herein means any data structure or structures used to store data. A database may be one or more files, it may be a commercially available database package, etc. The embedded device information database 112 may contain information one skilled in the art would need to provide services to embedded devices 24. The embodiment of the embedded device information database 112 shown in FIG. 9 illustrates what types of data may be stored in the embedded device information database 112. Device interface definitions 114 that define how to communicate or interface with embedded devices 24 may be included. Table 3 contains pseudocode illustrating what types of information may be defined and included in an interface definition 114.
TABLE 3
3A "FunctionA", function, word, void, &FunctionA
3B "FunctionB", function, int, float, &FunctionB
3C "VarA", variable, int, void, &varA
3D "VarB", variable, string, void, &varB
3E "EventA", event, byte, void, &eventA
3F "EventB", event, int, void, null
3G "FileA", file, void, void, &fileA
3H "FileB", file, void, void, &fileB
3I State information
3J Behavior information
3K Other
As illustrated in Table 3, an interface definition may include information such as the name or identification of the service, the type of service (e.g., whether it is a function, variable, event, file, etc.), the input parameter type, if any, the return type, if any, and the address of the service. Information about function FunctionA, shown at line (3A), is illustrated indicating that it is a function, it takes a word as an input parameter, it returns nothing (void), and its address is indicated at &FunctionA. Line (3B) illustrates the information about another function, FunctionB. Relevant information about variables are illustrated at lines (3C)-(3D). Information about events is illustrated at lines (3E)-(3F). Events may be any type of data. For example, an event could be a variable, a particular register, an interrupt, etc. Events may be particularly useful for items that occur asynchronously. Examples of asynchronous types of events include an alarm going off or an external LED changing. Information about certain files are illustrated at lines (3G) and (3H). State information (31) may also be included. The state information (31) may include information defining what various states the embedded device 24 may be in, information defining any state machines of the embedded computer 78, etc. Behavior information (3J) may indicate how the embedded computer 78 will react and behave given a certain set of inputs, outputs and/or states. Of course, other (3K) defining information may be included as well, as those skilled in the art see fit. A device types 112a data structure may contain information about what embedded devices 24 can be accessed and logical groupings of these devices 24. A device capabilities 112b data structure may include information on what capabilities each particular embedded device 24 has, similar to the capabilities table discussed above. Devices registered 112c information may contain information on what embedded devices 24 have been in contact with the service provider 20, which device's services have been paid for, etc. Device locations 112d may indicate where the embedded devices 24 are located, either in geographic terms or in electronic terms (such as, for example, a telephone number, an IP address, routing information, etc.). The information in the embedded device information database 112 may be created without access to the embedded devices 24, or it may be created from information obtained from the embedded devices 24. Embodiments herein may also implement security measures. For example, there may be embedded devices 24-and/or certain services of embedded devices 24 that should only be accessed by an entity holding the proper authority. A more specific example of this is a vending machine. A vending machine may only need to be accessed by particular entities, or it may have certain functions that should only be accessed by an authorized entity, such as, for example, the ability to change the prices on certain items, to drop certain items without payment or to lock certain items so that they may not be purchased. To provide proper authentication and access to embedded devices 24, the service provider 20 may include security codes 112e or information for validating proper client access. User names and passwords may be stored in the security codes 112e data to validate proper authorization. Devices to update 112f information may be a listing of embedded devices 24 that need some type of updating. Forwarding data 112g may include information about where data from or relating to an embedded device 24 should be forwarded. Another database 116 may be used by the service provider 20 to store information relating to entities, information, etc. on the computer network 22, and this database 116 and/or the information in this database 116 may be made available to embedded devices 24. This service information database 116 may include manufacturer locations 116a as well as manufacturer data 116b. In addition, it may store information provider locations 116c and some information data 116d provided by the information providers 30. Data collector locations 116e may be stored along with what data 116f has been requested by the data collector 32. Controlling/monitoring services locations 116g and their requests 116h may be stored. The controlling/monitoring requests data 116h may include schedule data 116i that indicates which devices should be controlled/monitored and how often they should be controlled/monitored. The schedule data 116i may include embedded device identifications and routing data. In addition, other data collected 116j may be stored in the service information database 116. In embodiments herein, the locations stored are in the form of IP addresses, but it will be appreciated by those skilled in the art that other types of data may be stored that would indicate how to contact a particular entity. An information collection manager module 118 may manage the data being stored into and read from the service information database 116. Similarly, an embedded device manager 120 may manage the data being stored into and read from the embedded device information database 112. An administrator module 122 may coordinate the operation of the service provider 20 and the communications between the managing modules 118, 120 and other modules included with the service provider 20. As discussed in relation to FIG. 8, a web server 124 and a device access server 126 may be included in the service provider 20 to facilitate providing services to or for the embedded devices 24. A computer network communications module 128 may handle communications accomplished via the computer network 22. An embedded device communications module 130 may handle communications with the embedded devices 24. The embedded device communications module 130 may include both hardware and software components. For example, if embedded devices 24 are able to dial in directly to the service provider 20, the embedded device communications module 130 may include a modem bank (not shown) as well as communication software to handle the incoming calls and data communications. However, the embedded device communications module 130 may also use other communications hardware that is being shared by other resources. In this case, the embedded device communications module 130 would typically include software to handle the communications that it is to receive. Those skilled in the art will appreciate the many communication packages and alternatives, both hardware and software, that may be utilized in the embodiments of a service provider 20. FIG. 10 is a block diagram illustrating a system 132 for providing services to embedded devices 24. As shown, the system 132 may include a plurality of embedded devices service providers 20 that are coordinated by a central office 134. The central office 134 may also coordinate communications via the computer network 22 with manufacturers 28, information providers 30, data collectors 32 and controlling/monitoring services 34. The individual service providers 20 for embedded devices 24 may be located in various locations to adequately service embedded devices 24 being used in the field. Depending on the particular embedded devices 24, some service providers 20 may need to be more proximate to embedded devices 24. Other service providers 20 may not need to be at a proximate location but may only need an electronic connection, whether physically close to or far away from its embedded devices 24. FIG. 11 is a flow diagram illustrating steps of a method of an embodiment for providing service to a plurality of embedded devices 24. Electronic communications is provided 136 between the service provider 20 for embedded devices and an embedded device 24. A message may then be received 138 from the embedded device 24. The embedded device 24 may then be identified 140 through use of the message received. This identification may either be of the particular embedded device 24 or of the type of embedded device 24. The service provider 20 may access 142 the embedded device information database. In embodiments herein, the service provider 20 is able to identify embedded devices 24 after accessing the embedded device information database 112. Accordingly, those skilled in the art will appreciate that a number of the steps herein may be performed in various orders to accomplish substantially similar results. The service provider 20 may send 144 a transmit message to the embedded device 24 and store 146 device information descriptive of a transaction. Information about the transaction (about the message(s) sent or received) may be used for billing purposes. Other steps may also be performed in practicing present embodiments. For example, newly obtained information from the computer network (to be placed in the service information database 116) may be linked to certain information in the embedded device information database 112. In this way, the service provider 20 will be aware of updated information when dealing with a particular device 24 or type of device. The message received from the embedded device 24 may be parsed to obtain an embedded device identifier, which may be a number, a text string, etc. Methods practiced herein also may use the schedule data of the controlling/monitoring requests to monitor or control embedded devices. FIG. 12 is a flow diagram illustrating steps of a method of an embodiment for providing service to a plurality of embedded devices 24. Requestors (users, companies, or other entities) may ask 148 an embodiment of a service provider 20 to monitor and/or control one or more embedded devices 24. The requestor may provide 150 the locations (whether electronic addresses or physical locations) or identifications of the embedded devices 24 to the service provider 20. The service provider 20 may obtain 152 any data or software updates that may be needed by the embedded devices 24. This may be done by accessing manufacturer's 28 web sites. The service provider 20 may then enter an iterative loop to control/monitor embedded devices 24. The provider 20 may get 154 the next device 24 to monitor or control. Depending on whether this is the first iteration through a particular list of devices to monitor/control, this step may either be getting the next device or getting the first device in a particular list. The service provider 20 may then send 156 a message to the device and establish communications. The provider 20 may then request 158 data, which may be interface data, from the device and store 160 the data obtained. If control has been requested, the service provider 20 may send 162 control data to the device 24. This control data may include directions or instructions for the device 24 to facilitate control. If a requestor has asked for a report or a status, the service provider 20 may send 164 a report or status to the requestor. The service provider 20 may then get the next device and cycle through the steps for each additional device. Commercially available software from emWare, Inc. is used in implementing the present embodiments. emWare, Inc. may be contacted through its web site at www.emware.com. One skilled in the art will appreciate how the commercially available software items from emWare can be used with the present embodiments. The following is a general and basic description of technology of emWare that is used in the present embodiments. emWare's business centers around microcontrollers that manage many electronic devices used in today's world, including telephones, home appliances, office equipment, ATMs, security systems, VCRs, automobiles, etc. These microcontrollers are embedded into millions of intelligent electronic devices. emWare has developed technology and software-which provide distributed network-based device control. emWare's Embedded Micro Internetworking Technology (EMIT) software is designed to move the majority of software off of the embedded microcontroller and distribute it to more capable computers over a network. EMIT has also been developed to leverage existing Internet technologies. Use of EMIT software involves various components including the following: the customer's embedded application, emMicro software (which correlates to the embedded interface module), emGateway software, emNet software (which correlates to the communication modules), and the customer's monitoring/controlling application. Typically, potential customers of emWare already have embedded environments in which they plan to deploy emWare's EMIT software to enhance their monitoring and controlling capabilities. These embedded environments typically include the embedded system, the host computer, and client computers. From the above discussion, it will be appreciated that the present embodiments provide a service provider for embedded devices and/or embedded systems. The embodiments herein may be embodied in other specific forms without departing from their spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative, and not restrictive. The scope of the invention is, therefore, indicated by the appended claims, rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
|
Same subclass Same class Consider this |
||||||||||