eBuilding: An overview of key eBuilding features There are certain aspects to eBuilding that are not readily distinguishable from competitive products by persons unfamiliar with fundamental Internet data exchange technologies. These features will quickly become apparent as key advantages in the eBuilding product design, as more and more businesses look to conduct business and execute distributed control strategies using the Internet. 1. eBuilding as an Internet Appliance As with most new marketing terms, there are a number of definitions of “Internet Appliance”. We view the idea of an Internet Appliance as a device that is easily Internet accessible, in terms of its presentation to a user interface or data interface. Since an Internet connection is typically provided by any one of a number of outside sources, such as an ISP running DSL or a cable company using cable modems, Teletrol chose the most common denominator connection scheme, 10/100 Mbps Ethernet. For configuration, software download and data access, our appliance assumes that we have a connection to the Internet that is Ethernet based and passes the same protocol used for the delivery of web pages, HTTP. Virtually every company or home Internet connection today supports HTTP. Many competitive products rely on earlier technologies that need other external equipment to pack and unpack the data, before using the Internet as the transportation medium. Only locations that have this equipment are then capable of accessing the data. In other competitive products, protocols essential to their device communication require that corporate firewalls be opened and security compromised in order to exchange data over the Internet. The reason many of these shortcomings exist in competitive products is because most of the technologies upon which they were built were designed to operate in a single LAN environment. While these technologies are excellent choices for LAN-based data exchange, they do not adequately address the needs of an Internet-based system. Click here for a larger image   2. XML and Microsoft’s .NET Before Microsoft went public with their .NET initiative, the eBuilding design was already well underway with the same technologies (XML and SOAP) that Microsoft has featured as key to their continued success. Teletrol selected XML as the way to represent the state of the system, configure the system, and deliver data from the system to third party devices, regardless of the operating system or hardware platform. eBuilding can easily deliver real-time or historical data, energy consumption for example, to any server that has a way to capture the XML data, handle it and store it locally. XML fits well with many business systems that are already in place. There is no need for expensive or proprietary software for data conversion, or to purchase a specific piece of hardware or database software. SOAP extends the functionality of XML by allowing XML formatted data to invoke a program on a remote server, creating a true Internet-based distributed software component system. For example, a server that monitors and controls demand reduction strategies for facilities scattered throughout the United States is located in Toronto. SOAP allows an individual eBuilding controller to send data to the Toronto server and ask it to review its strategy, based on specific local conditions. The Toronto server has access to information from all the sites and from other related servers, and it can make decisions according to aggregated real-time conditions at all of the sites. The Toronto server then delivers data to the original eBuilding controller to invoke a specific action algorithm, and it continues to run with that information until it needs to make the next adjustment. 3. Object Oriented Technology “Object oriented” is a term typically used to describe how software programs are written, whereas an object oriented design will deliver much more than just making programs easier to create. For years, software engineers wrote monolithic programs that were not inherently reusable, because the entire project or process was modeled as a single, large piece of code. Internally, it may have consisted of smaller routines, but there were no clear and enforced divisions between the code that ran lighting schedules, for example, and the code that ran air handlers. Changing the code in one routine could cause unanticipated problems with the other. The goals of an objected oriented design are to effectively decouple many of the dependencies between the different routines in the system, and to take advantage of that decoupling so individual physical devices can be modeled as objects in software. Each object contains programming detailing how it operates, and parameters, which customize its behavior. In HVAC, if we create a pump object, we can encode all of the software necessary to make the pump operate properly and access parameters that customize its operation, such as lead/lag sequencing, flow characteristics and the values of its high and low limit safety shutoff points. 4. Programming Language Once object oriented technology is employed to represent in software the individual elements of any control system, HVAC or otherwise, they are easily recognizable to the user as the actual devices they are modeling, not as so many lines of undocumented software. Teletrol’s eBuilding programming language combines an object-oriented approach very naturally with a graphical interface, so that each object in the physical system is represented in the programming language as a separate block or graphic. A pump in the real world may have three inputs and two outputs; the pump object on the programming screen will likewise have three inputs and two outputs. Connecting the software objects together with lines mimics how they are connected with wires or pipes in the real world facility. Beyond that, entire groups of objects can be combined into larger objects or systems, making the program faster and easier to create. An air handler and the associated VAV boxes for the 2nd Floor can be grouped into an object called “Floor 2”; that object can then be duplicated over many times to create similar objects representing Floor 3 through Floor 10. Beyond the simplicity and power in programming, the object-based approach allows the operator to replace a chiller object representing Manufacturer 1’s product with a chiller object representing Manufacturer 2’s product. These chillers can behave in very different ways, but if the interfaces between the chiller objects and the other objects in the system are consistent, the programming changes would be minimal. By combining this with eBuilding’s ability to remotely and automatically load programs to field mounted controllers, Teletrol can develop a modeling system for energy or maintenance monitoring that is self-updating as the intelligence contained in each of the objects is updated. For example, when you determine that there is a more efficient or cost effective way to control your chillers, eBuilding will allow you to create that object, replace it in your programs, then update all of the controllers overnight, to realize savings from the new model immediately. While some competitors have graphical programming languages, few have an object-oriented approach that truly divides the programming among software objects that represent the physical devices in the system. This design feature is the key to many of the planned advances in eBuilding beyond the year 2001.

· Products · Case Studies · Services & Support · Teletrol News · About Teletrol · Contact Us · Home ·

If you have any questions, comments, or problems regarding this service, please contact us at [email protected].
Copyright ©2002 Teletrol Systems Inc. All rights reserved. Legal Disclaimer

Teletrol Systems Inc., Technology Center, 286 Commercial Street, Manchester, NH 03101
Main Number: (603) 645-6061, Fax Number: (603) 645-6174, e-mail: [email protected]