1 Building Controls XML/Web Services Guideline Meeting June 3, 2003 CABA Intelligent & Integrated Buildings Council Sponsored by:

2 Agenda Introductions Proposed committee structure Mission statements Guideline vs standard Resources and funding Assignment of action items Adjourn

3 Introductions Name, Company or Organization Role Interest

4 Proposed Committee Structure Steering Committee - Paul Ehrlich Chair Data Model - Aaron Hanson Chair Services - John Pitcher Chair Security - Peter Manolescue Chair Management - Anno Scholten Chair

5 Mission Statements Guideline in General The mission of the CABA XML Guideline committee is to work cooperatively in an open environment to create a non-binding guideline for the use of Internet communications standards such as XML and Web Services for use in broad facility management. This would include, but not be limited to, control and monitoring of HVAC, Fire Alarm, Security, Card Access, Asset Management, Energy, and other facility related systems. The guideline committee has the intention of working to complete an initial draft by ??. The final work of this group will be provided to standards organizations such as ISO, IAI, OASIS, ASHRAE and others for consideration as the basis for a formal international standard. Members will also be encouraged to utilize the guideline as a de- facto standard.

6 Mission Statements Data Model The subgroup will produce a set of XML Schema documents for defining a common type system. This type system will provide a unified vocabulary upon which additional services and applications can be built with guaranteed interoperability. Examples of types to be defined: - Primitive types - Status - Units of measurement - Control points - Historical trends - Alarms

7 Mission Statements Data Model (cont’d) It is expected that the XML Schemas produced will be used for: - Input and output parameters of web services - Device description languages - Configuration languages Desired goals for the XML Schemas include: - Small predefined "kernel" of types - Ability to extend modularly for applications and manufacture specific types - Easy to map into both the Java and.NET type system

8 Mission Statement Services The services group will need to create use cases and proposed services to deal with those functions that go beyond simple exchange of data. Examples of services include:  Notification of alarms, diagnostics and events  Sharing of schedules and calendars  Exchange of historical information such as trend logs The services group will need to evaluate existing standards for how they are utilizing similar services. They will also need to have a close level of cooperation with both the Data Modeling and Management groups to avoid overlap.

9 Mission Statement Security One of the challenges with facility data that is located on an enterprise wide intranet or the Internet is that there is wide access to data. This is a benefit in that it provides a ready availability of data for control and monitoring. It is also a detriment since it becomes possible for users to intentionally or even inadvertently view or change critical facility information. The goal for the security group is to define the following: Authentication. Verify that a user of data is allowed access to perform the requested functions. Verify that the user is who they say that they are. Encryption. Provide a method to prevent malicious users from viewing data as it moves across the network. The security group will need to evaluate existing IP security models, select viable solutions, and define them to be utilized in a secure yet interoperable manner for use in facility management.

10 Mission Statement Management There are certain functions that need to be supported to configure, validate, and maintain a network of interconnected devices. Many of these functions are part of standard networking (for example DHCP, DNS, etc.). Other functions are more specific to facility management and real time control. Examples of areas to be defined by this group include: Discovery of facility management devices Discovery of available data objects or variables Discovery of supported services Status of a device or sub-system (heartbeat) Device / system backup and restore

11 Guideline vs Standard Guideline would be non-binding Could be used as a defacto standard Would submit to OASIS, IAI, W3C, ISO, ASHRAE and others to become a standard Pros - allows us to move fast, test work, work openly Cons - not a standard, subject to change and revision Discussion?

12 Committee Costs Costs include calls, meetings, coordination, web support We are soliciting a proposal for an administrator Will have proposed costs by July Looking for members to contribute fairly

13 Action Items Need working volunteers for each committee Feel free to sign up with Paul or individual chairs Each group should plan on periodic (weekly or bi-weekly) calls Next in person meeting in September or October

14 Conclusion Questions and comments