Multi-user example

This example features a campus of two multi-tenant buildings: Westerre I and Westerre II. The Niagara system monitors each building’s lighting systems and HVAC equipment. The example illustrates how to structure hierarchies in a Supervisor station for three users: facilities manager, system integrator, and operations center.

Figure 11. Multi-user hierarchies on a station

Facility Manager hierarchy	Systems Integrator hierarchy	Operations Center hierarchy

Facility Manager hierarchy - To monitor usage for the entire building as well as by floor, the facility manager prefers that the data to be displayed by floor. Each floor expands in a similar fashion to Floor 1 in the screen capture. Westerre II follows the same structure.
NOTE: This hierarchy definition is the one that is fully explained in this example topic.
Systems Integrator hierarchy - The systems integrator, whose main interest is monitoring device performance, prefers to view the same data by device.
Operations Center hierarchy - Finally, the operations center monitors the data by tenant and individual office.

Definition for Facility Manager hierarchy

Now that you know the goal, here is what the hierarchy structure looks like for the Facility Manager:

Figure 12. Facility Manager hierarchy definition

All tags, including implied (default) and dictionary tags are available for constructing hierarchies. The table that follows explains each of six levels for the Facility Manager’s hierarchy definition. After studying this example you should be able to understand the hierarchies for the Systems Integrator and Operations Center. The level names (left column) were set up by the hierarchy designer.

Level name	Property	Where set up	Result
Campus_GroupLevel	`Group By`: demo:campus	Value tag on each building component; the value of campus is “Westerre Complex”	“Westerre Complex” appears as the first node in the hierarchy under “Facility Manager”
site_QueryLevel	`Query Context`: siteId=hs:id	Implied tag on each building component: hs:Id={identifier}, where {identifier} is a unique string that identifies the site	Sets siteId equal to the value of the site’s hs:id and passes siteId down to the next level in the hierarchy definition
	`Query`: hs:site	Marker tag on each building component	Identifies the component as a location, causing the site names to appear as nodes under “Westerre Complex”
floor_GroupLevel	`Group By`: demo:floor	Value tag on each office: demo:=Floor {n}, where {n} is 1, 2, 3 or 4	Identifies the floor on which each office is located, causing the floor to appear in the hierarchy
office_QueryLevel	`Query Context`: officeId=hs:id	hs:Id={identifier}, (where {identifier} is a unique string that identifies the office) is an implied tag on each office.	Sets officeId equal to the value of the office’s hs:id and passes officeId down to the next level in the hierarchy definition.
	`Query`: demo:office	Marker tag on each office	Identifies the component as an office, causing the office names to appear as nodes under each floor in the hierarchy
	`Query`: hs:siteRef={siteId}	siteRef is a name, value tag on each office. The value of this tag is the hs:id of the site (building) in which the office is located.	Compares the hs:siteRef tag on the office) with the siteId passed down from the site_QueryLevel. A match ensures that the office appears under the correct building in the hierarchy.
equip_QueryContext	`Query`: hs:equip	On each device	Identifies the device as a piece of equipment. This tag causes the equipment names to appear as nodes under each office in the hierarchy.
	`Query`: demo:officeRef={officeId}	officeRef is a name/value tag on each device. The value of this tag is the hs:id of the office in which the device is located.	Compares the demo:officeRef tag on the equipment with the officeId passed down from the office_QueryLevel. A match ensures that the equipment appears under the correct office in the hierarchy.
	`Query Context`: equipId=hs:id	hs:Id={identifier} , (where {identifier} is a unique string that identifies the office) is an implied tag on each office.	Sets equipID to the value of the device’s hs:id and passes equipId down to the next level in the hierarchy definition.
history_QueryLevel	`Query`: n:point	Implied tag on each point.	Returns data from all device points.
	`Query`: n:history	Implied tag on each point.	Returns all histories for the device.
	`Query`: hs:equipRef={equipId}	Name, value tag on each point. The value of this tag is the hs:id of the device in which the point is located.	Compares the hs:equipRef tag on each point with the equipId passed down from the equip_QueryLevel. A match ensures that the point appears under the correct device in the hierarchy.

About assigning hierarchies to Roles

Roles have a Viewable Hierarchies property. By assigning a hierarchy to a specific role you are able to control the visibility of the entire hierarchy (and grouping elements within the hierarchy). Only the users assigned to that role are able to view the hierarchy.

NOTE: Users with the Admin role can always view all hierarchies and due to their super user permissions can view everything under those hierarchies. All other users are assigned permissions to view one or more hierarchies via their role(s).