In looking through the documentation, I could not find an entity contained within a site that allowed identification of floors, rooms, hallways etc. With Haystack, how would I model, say, a medical clinic that contained rooms and hallways, and track location and status of equipment, patients, and medical staff. Also, how would determine the status of rooms (are they ready to use, or do they need to cleaning and supplies restocked?

Just keeping track of temperature and energy usage is not enough to understand the usage of a building, and to schedule the usage to maximize the utility of the building, lower the operational costs, and to maximize occupant satisfaction.

See OmniClass Table 13 Spaces by Function http://www.omniclass.org/tables/OmniClass_13_2006-03-28.pdf

This table is included in the US National BIM Standard v2 and will start showing up in some BIM software.

Construction Operations Building Information Exchange (COBie) for handover from Contractor to Owner should help link equipment (in OmniClass 23) to facility, floor, zones, rooms. And does include long term phases but does not capture up to the minute operational matters such as "ready to use" or if the temperatures are within a specified limit.

If a simple Project Haystack schema could be done to plug in OmniClass 13 for generic room types, allowing for Owner room types, along with basic day to day operational concerns (status, temp, RH, occupied, schedule) - the generic room types alone might provide enough hooks back to COBie if Owners were using this to manage their equipment and warranties over the long term.

Onuma has also done some work with BIM-GIS at California Community Colleges where rooms are colored blue or red if the equipment is operating efficiently which is more real time and web service like.

We started working on this as well, and have some good ideas for how locations might work. We should use this topic to discuss the options.

We need to be able to define, rooms, zones, and which zones are attached to which rooms. There are different types of zones. IE... a vavZone, fcZone, and so on. It would be nice to be able to distinguish between the different zones as well. We might want to find all zones on a certain floor that are served by VAVs, and by a certain AHU. It can be very complex so we need to get this right.

IE... 2 Zones might serve 1 room.

We also need to look at defining where equipment is in the zone. IE... The VAV is located in room2, but the thermostat is in room3. I would also like to get things tagged for plugload, and lights at the same time, so we know where energy is being used.

Also see previous discussion in Topic 43

In topic 43, I see a debate on the definitions of the terms space and zone, but without a resolution. Why don't you just create two some entity types for use in Haystack.

A space - surface or 3 dimensional area with definitions of it's boundaries. And the rub (and what I'm trying to find "an industry standard") is how to define boundaries within a building. Lat/Lon don't seem appropriate. There should be no restrictions on overlaps. However, there should be a way to indicate containment and indicate that a collection of spaces fully represents another space. For example, a collection of hall and room spaces fully represents the space of a floor, and a colection of floors fully represents a building.

A zone - a logical grouping based on a named attribute value.

OmniClass Table 14 Spaces by Form deals with zones. This table is currently being worked on. Whats missing is the ability to link zone to equipment to room to related system parts like switches, plug loads or similar in the specifications - and up to the minute operational status. There is no one industry standard that defines all of these together. The situation is more as Jack Park says - data awaiting proper linkage.

Some comments on zones groups and physical building components, hopefully somewhat of a synopsis on other comments and observations. Zones are logical, rooms and hallways are not. It seems the fundamental distinction of logical and physical guide us in our linkage decisions, 1:1, 1:N and N:M relationships. That is there is nothing preventing physical plant operating 2 zones, maybe not desirable but certainly not preventable. If a given EMS wants to dispatch remote commands based upon zone, vs. physical plant to set the occupied cooling set point for the sales floor zone, that command based upon physical plant setup could also set the occupied cooling set point for the manager’s offices, for instance. However, even with the potential for overlap, it seems compelling to add the zone concept to the haystack vocabulary. (Analytics and zone level operations)

Is there some developments on that topic ?

Personnaly I agree with the zone concept being a logical group... space seems to be a good tag to physically model a building... maybe we could think about some sort of "kind" marker (office, room (hotel), lobby, hall, etc...) for the "space" tag. A lot of spaces are identified by a number... maybe a spaceId tag would fit the need.

floor is absolutely needed (integer)

department would be useful (accounting, engineering, etc...) A department would consist of multiple spaces.

Site

• Floor 0
  • Space 1
  • Space 2
• Floor 1
  • Space

From my point of view, zone would refer to a system (like VAV). Zone would not be used to model the building. It would be used under an AHU to model air diffusion.

spaceRef would then be available to tag equipments...