AutomatedBuildings.com
Article - April 2002
[Home Page]

Innovations in Comfort, Efficiency, and Safety Solutions.
Belimo

(Click Message to Learn More)

Web Services - The Next Level

Just like the next level in a video game, moving our Building Automation Industry Information and Interaction to the evolving WEB SERVICES LEVEL changes everything, new rules, new power, and a new Information Model.

Ken Sinclair
  AutomatedBuildings.com


What are Web Services?

IBM says, "Web services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally, the World Wide Web."

Microsoft's description is more succinct, "a Web service is programmable application logic, accessible using standard Internet protocols,"

Others define Web services as a business logic or information made available using the XML (Extensible Markup Language)-based SOAP (Simple Object Access Protocol).

Securing Buildings News

Technologies and protocols have been developed that can integrate existing business processes and resources and make them available over the Web. Users looking for tools to develop Web services have new integrated environments to choose from that offer everything from Web servers to application development tools.

Why am I telling you about Web Services?

Our industry is starting to become very aware of these trends. I will use the following article as an example but others on our web site are suggesting similar direction. The article is from our January issue of AutomatedBuildings.com and is called Information Model: The Key to Integration http://www.automatedbuildings.com/news/jan02/art/alc/alc.htm  by Eric Craton, Product Development and Dave Robin, Software Development at http://www.automatedlogic.com/ 

It States:

Web services are a new breed of Web application. They are self-contained, modular applications that can be run over the Internet and can be integrated into other applications. Web services perform functions that can be anything from simple requests to complicated business processes. For example, a weather bureau could offer a Web service that allows a building automation system to automatically retrieve temperature forecast data for use by various control algorithms. Similarly, the building automation system itself could offer a Web service that allows a tenant's accounting system to obtain up-to-the-minute figures on energy consumption. In the past, this type of data exchange would require a custom, "hard coded" data request to retrieve information that already existed in the host computer. A Web service, on the other hand, is a way to allow any authorized client to actually run an application on the host computer and generate data that didn't previously exist. In our accounting example, the tenant's computer would provide information on the inclusive dates and building areas, and the Web service host computer would calculate and return the energy consumption data.

contemporary The article further states: 

Since BACnet and EIB objects and LonMark functional profiles are information models, and XML is a modeling language, we could express these high level information models in XML and in so doing make them compatible with the emerging Web services architecture. 

Goes on: 

If each building automation protocol developed its own XML model, however, we would have similar but incompatible system models. Today's problems of translating from one protocol to another at the building controller level would become tomorrow's translation problems at the Web services level. What's needed is a unified system model, in XML, that can be used by any building automation protocol. 

Concludes:

XML, TCP/IP, or even Web services alone cannot provide interoperability between vendors. In order for interoperability to occur, vendors must not only agree on HOW they will communicate, but also on WHAT they will communicate. Because they include a high-level abstraction of what information is to be communicated, BACnet, EIB, and LonMark all provide the WHAT component of interoperability. By combining these information models with XML, and expanding the objective to include other non-HVAC related aspects of the facility, Web services can provide an information platform that is high-level, cross-platform, cross-discipline, and multi-vendor. A new initiative is needed to define a comprehensive information model for the facility. 

AutomatedBuildings.com very much agrees with the direction of this article and others on our site and has responded by creating an online forum http://automatedbuildings.com/webservices.htm  to assist the evolution of the Web Services Information Model. 

An overview pictorial uses a simple, possible web services application to allow industry stakeholders to quickly grasp the reach of the Web Services level of information and interaction. It is hoped that this starting point and our linked resources will open the industry minds to the importance of opening dialog now on how an Industry Web Services Information Model could evolve. 

A first cut has been made at Guidelines, Probable Industry Applications, an Industry Call to Action, plus Links to Known Resources. Your input is important. Please share your views as to the best method of creating Information Model Guidelines. Email us at WebServicesModel@AutomatedBuildings.com 

Published March 2002  Engineered Systems


opsys
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources