1. Field of the Invention
This invention pertains generally to wireless communication and, more particularly, to wireless communication networks including wireless devices, such as sensors and/or actuators. The invention also relates to a wireless control or monitoring device for a wireless communication network such as, for example, a wireless sensor network.
2. Background Information
Removing wires from existing and new products (e.g., industrial; residential; commercial) significantly reduces installation time, simplifies the installation process, and reduces cost.
A monitoring and commissioning tool is needed to aid the installation of such products, and following commissioning, to monitor and control various product parameters. However, it is believed that such a tool would become obsolete relatively fast and need to be redesigned in order to support new wireless products. In addition, when the wireless communication protocol used to monitor the products changes, or when a supported protocol is not available in a particular environment, it is believed that such a tool would not function.
Industrial and commercial wireless sensor networks based on Low-Rate Wireless Personal Area Network (LR-WPAN) technologies are emerging as a powerful enabler of cost-effective, distributed systems. These LR-WPAN technologies are increasingly being deployed in monitoring and control applications.
Evolving industrial protocols tend to exhibit certain properties that make them difficult to interoperate with devices based in more recent technologies, like LR-WPAN. Since concepts like self-discovery and self-configuration are common paradigms in these types of devices, it is a logical step to apply some of these principles to increase the added value of this new generation of products.
At the same time, it is believed that the interoperation and integration of these new solutions into an ongoing industrial environment is a subsequent challenge to be solved. Part of this evolution requires the interaction with legacy, but currently maintained, industrial protocols, such as, for example and without limitation, INCOM (INdustrial COMmunications)
An INCOM network provides two-way communication between an INCOM network master and a variety of devices such as, for example, electrical circuit interrupting devices, circuit breakers, digital meters, motor overload relays, monitoring units and a wide range of industrial and electrical distribution products. Control and monitoring is carried out over a communication network consisting of dedicated twisted pair wires. Preferably, a suitable circuit provides a simple, low-cost interface to the communication network. For example, a Sure Chip Plus™ microcontroller, mixed-mode analog-digital application specific integrated circuit (ASIC) including a microprocessor, enables a control, protection or monitoring device to communicate with the INCOM network. This integrated circuit provides various network functions such as, for example, carrier generation and detection, data modulation/demodulation, address decoding, and generation and checking of a 5-bit cyclic redundant BCH error code. Alternatively, suitable INCOM communicating ASICs may be employed such as, for example, an ASIC intended for use with an external microprocessor. INCOM may employ a wide range of modulation techniques and baud rates (e.g., without limitation, FSK (9600 baud); base band (153.2 Kbaud)). Examples of the INCOM network and protocol are disclosed in U.S. Pat. Nos. 4,644,547; 4,644,566; 4,653,073; 5,315,531; 5,548,523; 5,627,716; 5,815,364; and 6,055,145, which are incorporated by reference herein.
For several reasons, industrial protocols, such as INCOM, offer interesting challenges at the time of integration. First, due to market, historical and/or engineering needs, the protocol definition is continuously evolving and different devices often use disjoint variants or subsets of the protocol.
Second, the development and maintenance costs of networking and commissioning tools gets affected, since they have to contain information about all possible devices, legacy and current, in the field.
These characteristics render inefficient the implementation of devices with a predetermined protocol stack. The construction of a device that takes into account all possibilities or variants of the protocol at design time is simply impractical. Considering that the protocol itself is evolving, and devices implementing yet another variant of the protocol are certain to be implemented in the future, this traditional approach is arguably unsustainable.
As experienced many times, the designers of monitoring and control systems often do not have control over the deployment and configuration of future devices to be monitored and controlled.
The act of modifying an application, or system, as it runs is called dynamic reconfiguration. The usefulness of this act has been demonstrated in many applications, like antivirus programs. To support dynamic reconfiguration, the application or distributed system must have several properties. As a brief summary, relevant properties include: (1) the user must be able to concretely define the reconfigurable attributes of the system; (2) there must exist a method to provide to the system the necessary information for reconfiguration from a source external to the system—and this must be synchronized to avoid deadlocks; and (3) all information characterizing the reconfigurable process must be represented and exercised during the reconfiguration process. Essentially, such dynamic reconfiguration must be able to define a set of attributes that characterizes the behavior to reconfigure, and a process to reconfigure it.
An important consideration to take into account is the set of behaviors or states to which the system can be reconfigured, or in other words, supporting reconfigurability by design. Unbounded support for reconfiguration will ultimately defeat the advantages for implementing dynamic reconfiguration in the first place. Therefore, careful consideration should be taken when choosing the set of reconfigurable behaviors.
Accordingly, there is room for improvement in wireless communication networks.
There is also room for improvement in wireless control or monitoring devices for wireless communication networks.
These needs and others are met by embodiments of the invention, which take into account the fact that the information a monitoring and control system has is limited and which enable protocol conversion to be dynamically reconfigurable with respect to a corresponding communication protocol. This allows the monitoring and control system to be upgraded in the field as needed, with minimal effort on the part of the user. For example, the system defines and/or modifies a product profile to support new or updated products without changing a corresponding monitoring and communication tool. This also has the advantage that any changes to the underlying wireless communication protocol and infrastructure are transparent to the user. The system preferably can be used under different operating system platforms, and can accommodate different communication media and different form factors.
In accordance with one aspect of the invention, a wireless communication network comprises: a number of wireless devices; and a wireless control or monitoring device structured to wirelessly communicate with the number of wireless devices, the wireless control or monitoring device comprising: a wireless transceiver, a user output device, a user input device, and a processor cooperating with the wireless transceiver, the user output device, and the user input device, the processor comprising a routine structured to output first information from the number of wireless devices to the user output device, or to input second information from the user input device to the number of wireless devices, wherein the routine is further structured to employ an XML schema to define the first information output from the number of wireless devices to the user output device, or to define the second information input from the user input device to the number of wireless devices.
The number of wireless devices may comprise a converter between a first interface for a first communication protocol and a second interface for a second communication protocol. The first communication protocol may be a standard communication protocol, and the second communication protocol may be a different proprietary communication protocol.
The converter may be structured to communicate using the different proprietary communication protocol with a first proprietary device and a second different proprietary device; the XML schema may define a first request from the wireless control or monitoring device to the first proprietary device and a second different request from the wireless control or monitoring device to the second different proprietary device; and the converter may convert the first request to a corresponding first command to the first proprietary device, and may convert the second different request to a corresponding plurality of second different commands to the second different proprietary device.
The first request may correspond to a first expression corresponding to the first proprietary device; the second different request may correspond to a second different expression corresponding to the second different proprietary device; the first request and the second different request may both correspond to the same user command of a plurality of different user commands from the user input device; the corresponding first command may be one of a plurality of different commands accepted by the first proprietary device; and the corresponding plurality of second different commands may be some of a plurality of different commands accepted by the second proprietary device.
The wireless control or monitoring device may be further structured to commission the number of wireless devices into the wireless communication network.
The routine may be a JAVA application including a plurality of endpoints; the number of wireless devices may be a plurality of wireless devices, each of the plurality of wireless devices corresponding to a first endpoint and a second endpoint of the plurality of endpoints, the first endpoint being a discovery endpoint including first commands for network discovery and device identification, the second endpoint including second commands for the first information.
As another aspect of the invention, a portable wireless control or monitoring device is structured to wirelessly communicate with a number of wireless devices. The wireless control or monitoring device comprises: a wireless transceiver; a user output device; a user input device; and a processor cooperating with the wireless transceiver, the user output device, and the user input device, the processor comprising a routine structured to output first information from the number of wireless devices to the user output device, or to input second information from the user input device to the number of wireless devices, wherein the routine is further structured to employ an XML schema to define the first information output from the number of wireless devices to the user output device, or to define the second information input from the user input device to the number of wireless devices.
A full understanding of the invention can be gained from the following description of the preferred embodiments when read in conjunction with the accompanying drawings in which:
As employed herein, the term “number” shall mean one or an integer greater than one (i.e., a plurality).
As employed herein, the term “processor” means a programmable analog and/or digital device that can store, retrieve, and process data; a computer; a workstation; a personal computer; a microprocessor; a microcontroller; a microcomputer; a central processing unit; a mainframe computer; a mini-computer; a server; a networked processor; or any suitable processing device or apparatus.
As employed herein, EZMApp refers to a ZigBee™ Monitoring Application, which is a JAVA application for display of wireless sensor and/or INCOM data on a personal digital assistant (PDA).
As employed herein, INCOM is the INdustrial COMmunications network for data retrieval from, for example and without limitation, power system meters, relays and trip units.
As employed herein, I4 is an INCOM to 802.15.4 conversion module.
As employed herein, SDIO is Secure Digital Input Output. For example and without limitation, devices that support SDIO (e.g., without limitation, PDAs like the Palm® Treo™; laptops; cell phones) can use relatively small devices designed for the SD form factor, like GPS receivers, Wi-Fi or Bluetooth™ adapters, modems, Ethernet adapters, barcode readers, IrDA adapters, FM radio tuners, TV tuners, RFID readers, digital cameras, or other mass storage media such as hard drives.
As employed herein, P4 is a Palm® Treo™ to 802.15.4 SDIO card.
As employed herein, UML is Unified Modeling Language, which is an Object Management Group (OMG) standard for modeling software. For example and without limitation, UML can be used to model the disclosed wireless communication network 46.
As employed herein, Wireless Sensor Network (WSN) is a wireless communication network that enables smart communication of sensor/actuator devices.
As employed herein, XML is Extensible Markup Language, which is a general-purpose specification for creating custom markup languages. For example, XML is an extensible language because it allows its users to define their own elements, and facilitates the sharing of structured data across different information systems. XML can be employed to serialize data and can provide a structured format that humans and processors can understand.
As employed herein, an XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntax constraints imposed by XML itself. An XML schema provides a view of the document type at a relatively high level of abstraction. Non-limiting examples of XML schema are shown in Tables 1A-1B, 2A-2B and 3A-3B, below. An XML schema can include a plurality of XML strings.
The disclosed ZigBee™ Monitoring Application (EZMapp) is a system that employs autonomic principles to facilitate the transition of traditional industrial environments to a robust and pervasive industrial network.
The invention is described in association with an INCOM proprietary communication protocol and an IEEE 802.15.4 standard communication protocol, although the invention is applicable to a wide range of different communication protocols.
Referring to
The example wireless communication module 6 is an INCOM to 802.15.4 wireless communication board, which provides some of the functions of the I4 module 14′ of
When the I4 module 14′ is installed in a wireless trip unit (not shown, but an INCOM device, such as the trip unit main circuit board 10 is shown in phantom line drawing), a switching regulator 20 converts a +38 VDC control voltage 22 (e.g., without limitation, an internal voltage generated in the trip unit to power peripherals) to +12 V 24. The INCOM transceiver 16 is not employed in this particular configuration, but may be employed if the I4 module 14′ cannot be installed within an INCOM device (not shown). An INCOM integrated circuit 26 communicates directly to a suitable processor radio (e.g., without limitation, a COTS microprocessor and a radio chip) 28 using +5 V INCOM signals 30 of an example 5-wire internal INCOM interface. An external +12 V power supply 32 may alternatively power the I4 module 14′. Hence, the I4 module 14′ can either be powered from the +38 VDC control voltage 22 or the external +12 V power supply 32. An INCOM connector 34 is used to connect to an external INCOM device (not shown) through the example twisted-pair two-wire INCOM field bus (not numbered).
Referring to
The ZigBee™ wireless networking protocol stack model of
The example INCOM integrated circuit 26 is an INCOM encoder/decoder for the example INCOM proprietary communication protocol. An example IEEE 802.15.4 encoder/decoder 57 is for the standard IEEE 802.15.4 communication protocol. A processor 55 is structured to exchange information between the INCOM encoder/decoder 26 and the IEEE 802.15.4 encoder/decoder 57.
As shown in
All example devices in the example wireless sensor network (WSN) 46 of
An XML schema supports data exchange among the various wireless devices 4,2,38,40,42,44,6,14,14′ of
The wireless trip 2 unit XML response is shown below. The wireless trip unit 2 device ID is iiii and the currents are reported as data aaaa=Ia, bbbb=Ib, cccc=Ic, and gggg=Ig:
The XML schema defines and/or modifies a product profile to support new or updated products (e.g., by not otherwise changing the PDA's hardware and software).
Referring to
The interaction between the WSN 46 (
The following describes the functions of the module 6,14,14′ that are a result of it being a reconfigurable protocol converter and the reconfigurable “component” of the module. This describes the dynamically reconfigurable protocol converter for INCOM devices, such as 2′ and 80 of
There is the desire to monitor a set of proprietary devices 78, such as 2′ and 80 of
Of these cases, only the first two are applicable to wireless monitoring and control applications, since all communications performed in the proprietary protocol, P, are performed in response to a user input command.
There is an intermediate module, such as I4 stand-alone module 14 (
The intermediate module 14 communicates with an arbitrary end device, and understands dialogs of interest in an arbitrary end device. For clarity, this is described using set notation in Equations 1 and 2:
∀dεD,Sd⊂MI (Eq. 1)
∃i,jεD|(Si∪Sj)−(Si∩Sj)≠0 (Eq. 2)
wherein:
Equation 1 defines that the set of commands known by the intermediate module 6,14,14′ is a superset of the set of interesting commands that belong to any one end device to which the intermediate module could be connected. Equation 2 provides that different proprietary end devices may have disjoint sets of commands that need to be supported.
Equation 3, below, defines a map, φd, to represent the protocol conversion component of the module 6,14,14′.
φd:MU→Sd where dεD (Eq. 3)
wherein:
Equation 4 defines what is excluded from the map, φ.
Using set and map notation, it is clear to see that in order to support a dynamically updateable command set in the monitoring and control device 4, a map, φd, is implemented such that it is reconfigurable at application run-time for any device d. Equation 4 describes a map with a range that is the superset of all possible devices. The main problem with implementing this map occurs if there exists a user command, c, such that φ(c) exists, but it is not a valid command for d, the current device. There is no graceful method of rejecting such a user command without defining a separate map for each end device, φd. The range of the map φdεD instead only contains commands corresponding to the specific end device that the device 4 is currently connected with. Unsupported commands will map to a “rejection” element, in order that the intermediate module 6,14,14′ can reject any commands that are unsupported by the current end device, d. This also attenuates the size of the individual maps as the set D gets larger, thereby decreasing the time it takes to calculate the mapping. Furthermore, this implies that there is a procedure that selects or builds the map after the device, d, has been identified.
To implement the map described by Equation 3, the set MU (the domain of φd, which is the same for all d) and the set Sd (the range of φd, which is dependant on d) are isolated. Note that these sets contain the dialog information of the monitoring and control device 4 and the end device 2′,80 of
Each user input corresponds to one such XML string. Hence, the set of XML strings corresponding to user inputs is the set of atomic dialogs that corresponds to MU. In monitoring and control systems, it generally seems to be the case that the user inputs directly correspond with atomic dialogs in the open protocol, O.
On the proprietary end device side, the set of atomic dialogs is less apparent, but is still necessary to identify. With proprietary protocols, the same commands often act differently in different contexts. For example, in the INCOM protocol, the amount and content of the data returned by an INCOM 30F command varies based on a parameter which is given to the INCOM device as a separate message after the command. Furthermore, since the proprietary devices, d, are often not designed with a monitoring and control system in mind, the same command in O will correspond with different commands in P based on d. An example of this with P being the INCOM protocol in the I4/P4 monitoring and control system is the user request for voltage. If the module 6,14,14′ is connected to a trip unit, such as 2′, then a voltage in O corresponds to the INCOM command 306 in P. However, if the module 6,14,14′ is connected to a power monitoring device, such as 80, then the request in O corresponds to two INCOM commands, 306 and 307, in P. Therefore, it is not enough to suppose that the individual commands in P correspond to dialogs with respect to the intermediate module 6,14,14′. The extra information about the context of the command must also be included.
Here, a set of proprietary commands in P is employed that correspond to a user request directed at a specific device as the atomic dialog. This includes the INCOM commands in P, any parameters to those INCOM commands, the number and type of INCOM responses to expect from the end device 2′,80, and ordering information. The set of these dialogs that is supported by a specific end device, d, is the set Sd, as was defined above.
Finally, there is information that belongs to both the domain and range of φd. This information is essentially the “transition” from the domain to the range or vice versa. Information is included that describes how the map translates data or parameters received on one end to the other. An example of this in the I4/P4 system is the “status” command. The XML response to this INCOM command is described in Table 6 for the I4 “status” response.
The “status” command corresponds to a 300 command in INCOM, with a 3-byte response. The text in the data field is the data received in the three bytes formatted into the fields aa through gg. The data is expected in this format by the monitoring and control system, so the information to format the data in this fashion is included in the dialog information.
As a non-limiting example, the INCOM Device Status is a bit-mapped response containing the following information: (1) aa=Supplier Division Code; (2) bb=Product ID; (3) cc=Comm. Version; (4) dd=Product State; (5) ee=Remote Open; (6) ff=Powered On; and (7) gg=a Product Defined Status.
With the dialog information having been isolated, the following describes the procedure to organize and represent it in a form that allows inputting the data into the monitoring and control system. Essentially, the expression φd(C)=s is organized and represented for some user command, cεMU, and its corresponding dialogs in protocol P, sεSd, with respect to the end device, d.
The following describes an example format for the organization of the dialog information and the procedure to specifically identify the organization (schema) for an arbitrary system. XML is employed to represent the dialog information discussed above. XML is advantageously employed because it is an open format, is a content based tagging system, and is “human-readable”. These properties are advantageous for the application of providing information to support dynamic reconfiguration to a monitoring and control system. XML is an open format, so it enjoys industry support and, thus, many XML tools are available. Tools exist to aid in the design of the schema that contains the dialog information and technologies, such as XSLT (Extensible Stylesheet Language Transformations is an XML-based language used for the transformation of XML documents into other XML or “human-readable” documents), can be utilized to auto-generate dialog schema from generic documents. Because XML is an open format, the number and quality of these tools will increase with time, as will the technologies associated with XML.
Since XML is content based, applications that use it to store information lend themselves naturally to modular design in terms of upgrading that information. The application searches for the tags of interest to it, and simply ignores tags that are not of interest. This makes it possible to update the dialog information and its organization for new monitoring and control systems and intermediate modules, while ensuring backwards compatibility for older monitoring and control systems and intermediate modules. This creates a continuity between the dynamic reconfiguration processes for different generations of the same monitoring and control system. Therefore, the maintenance process is the same across all systems using the schema.
Finally, XML is human readable. This facilitates the creation of a schema that is not difficult to understand or re-create by a non-specialist. Since it is easy to learn the schema, users can create their own custom dialogs for different devices, commands, or combinations of commands. This alleviates the burden on the manufacturer of the monitoring and control system to support a wide variety of commands. This sort of “opens up” the dynamic reconfigurabilty of the system.
The disclosed system is usable on different operating system platforms since JAVA is portable to different operating systems.
Different communication media and different form factors are accommodated through communications using ZigBee™ driver 82, Bluetooth™ driver 84, and a serial driver 86 as shown in
The example PDA 4 includes a user output device, such as the example display 90, a user input device, such as the example keyboard 92, a processor 94 cooperating with a wireless transceiver, such as the example IEEE 802.15.4 wireless SDIO card (P4) 12, the user output device 90, and the user input device 92. The processor 94 includes a routine, such as the example EZMApp JAVA application 36 (
Non-limiting examples of the various devices 2,2′,38,40,42,44,78,80 include a wireless temperature sensor 38, a wireless humidity sensor 40, a wireless trip unit 2, a wireless vibration sensor 42, a wireless power sentinel 44, an INCOM to IEEE 802.15.4 adapter 6,14,14′, a wireless current sensor (not shown), a wireless meter (not shown), a wireless I/O module (not shown), a wireless indicator (not shown), and a wireless audible alarm (not shown).
The cost of the disclosed system as compared to the cost of writing and testing a new software revision and the cost of releasing dynamic updates is significantly smaller. In addition, final users can now employ systems that are customized to their needs.
The disclosed system enables relatively quick reconfiguration of monitoring and control commands in systems with proprietary protocols, like the example proprietary INCOM, using ZigBee™ as the enabling service for remote monitoring and control, and XML as the language for expressing on-the-fly functionality and user interfacing of legacy industrial devices. The problem solved is the sensible reduction of a priori device information and interaction scenarios as a prerequisite to designing a robust, pervasive industrial network.
While specific embodiments of the invention have been described in detail, it will be appreciated by those skilled in the art that various modifications and alternatives to those details could be developed in light of the overall teachings of the disclosure. Accordingly, the particular arrangements disclosed are meant to be illustrative only and not limiting as to the scope of the invention which is to be given the full breadth of the claims appended and any and all equivalents thereof.
This invention was made with U.S. Government support under Contract No. DE-FC36-04GO14000 awarded by the Department of Energy. The Government has certain rights in this invention.