Differences
This shows you the differences between two versions of the page.
| 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. | ||