Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ardiadminguide:location [2016/08/02 05:21]
optrix
ardiadminguide:location [2019/01/23 04:50] (current)
optrix
Line 11: Line 11:
 In this example, the sensor is //inside// Cabinet 1A, which itself is in Building B, which is in turn in our main site.  In this example, the sensor is //inside// Cabinet 1A, which itself is in Building B, which is in turn in our main site. 
  
-Note that not all of your assets in your location hierarchy need to be //​physical//​ assets. In many cases, a site may be broken up into logical areas that encompass a number of buildings (or a building will be broken into areas that encompass multiple machines). These are excellent [[:​logical_assets]] to create and place in your location hierarchy.+Note that not all of your assets in your location hierarchy need to be //​physical//​ assets. In many cases, a site may be broken up into logical areas that encompass a number of buildings (or a building will be broken into areas that encompass multiple machines). These are excellent [[logical assets|logical assets]] to create and place in your location hierarchy.
  
 The location hierarchy is special, as it's used to create the [[ardiuserguide:​full name|full name]] of your asset. The location hierarchy is special, as it's used to create the [[ardiuserguide:​full name|full name]] of your asset.
 +
 +It also determines what assets are visible in the 3D environments created by ARDI-VE.
 +
 +===Understanding the Location Hierarchy===
 +
 +A common question is 'Do I put asset '​A'​ inside asset '​B'​ in my location hierarchy?'​
 +
 +The answer lies in how you //speak// about your assets. ​
 +
 +Let's try a few sample phrases.
 +
 +----
 +
 + //The **pump** is **part of** the **water distribution system**//
 +
 + //The **level switch** is **part of** the **tank**//
 +
 +Language such as **in**, **inside** and **part of** will almost certainly mean you should put one inside the other.
 +
 +----
 +
 +//The **pump** is **next to** the **tank**//.
 +
 +//The **valve** is just **up from** the **pump**//
 +
 +Language such as **next to**, **near**, **upstream from** etc. are letting you know what asset it's //near//, but not what it is actually part of. In these cases, you don't connect the two with the Location hierarchy - in most cases, they'​ll be connected by other, physical relationships anyway.  ​
 +
 +----
 +
 +//The **level transmitter** is **attached to** the **tank**//
 +
 +Some language - such as **attached to**, **welded on to** etc - can be a a grey area. 
 +
 +To help you resolve these questions, it's best to ask yourself "//are the assets directly connected in other ways?//"​
 +
 +So let's take a look at an example.
 +
 +There'​s a tank that has both a level transmitter and an air-valve attached to it.
 +
 +Since level transmitter measures the level //of the tank//, they are obviously connected. In this case, the transmitter **should** be part of the tank on in the Location hierarchy (it should also have a [[Monitors|monitors]] relationship with the tank as well).
 +
 +However, the air valve has been attached to the tank purely out of convenience - the air passing through the valve doesn'​t go to or come from the tank, the tank was just a very convenient mounting location. In this case, the valve **should not** be considered part of the tank in the Location hierarchy - instead, place under the system it is part of.