The Location Namespace

If you have ties to the real estate business, you know the three most important factors that determine the value of an asset: Location, location, and location. In a similar way, the value of proper location metadata for OTbase, and more generally for the value you'll get out of your OT asset inventory, cannot be overstated.

Getting the location namespace right is by far the biggest issue novice OTbase users struggle with. Therefore, study this section in detail and plan for ample time to get your location hierarchy straight.

Have a solid foundational location hierarchy in place before you import asset data from OTbase Discovery. Do not skip this step and "worry about location later", it will only waste time. If you do want to import discovery data prematurely, be prepared to start over from scratch once you have your location metadata nailed down.

What is location in OTbase, anyway?

In OTbase, location always refers to geolocation. Something you can pinpoint on a map, or floor plan. Something that has GPS coordinates. Examples of locations are:

• North America
• Denver, Colorado
• Building A
• 2nd floor
• Room 122
• Cabinet A553

The following are not examples of locations:

• HMI network
• Water purification
• Legacy OT
• ACME Inc. (subsidiary)

They are functional or organizational entities that you should try to avoid in your location namespace. Don't worry, you can still stick those items to your assets, because OTbase provides multiple metadata dimensions.

Location hierarchy

OTbase lets you express location as a hierarchy. This is extremely useful because it allows for granularity when it comes to filtering asset data, and to access rights. As an example, you'll be able to see all devices in North America, or only the devices in a specific site in North America. The depth of your hierarchy is completely up to you. Therefore, if you wanted to go four or five levels deep, let's say down to cabinets or even racks, that's totally fine.

You build out your location hierarchy by going to INVENTORY then selecting LOCATIONS.

Click on Add to add a location. The Add Location modal window will appear which you can then fill out to create a new location.

For the time being, ignore the ID field.

The new location will appear depending on your starting point. In our example, Miami will be inserted below "USA", as a sublocation. If we wanted to further subdivide the Miami site, we would select the new Miami location and then click on Add.

If you want to move sublocations, for example because you made an error on input, select the sublocation in question and click Edit. In the edit pane, open the path drop-down and choose the location below which you want to insert this location. Then click Save.

Reference locations

You will most likely want to highlight your different sites. This is what the Reference Location attribute is for. Simply select on a location that you want to designate as a reference location, click Edit and set the Reference Location attribute. Thereafter, your location will appear in boldface and will have a Home icon in front of it. In Product Profiles, CVE Profiles etc., assets are grouped by Reference Locations, so it is important to make assignments properly.

Using a hybrid location hierarchy

This article emphasized the benefits of using a location namespace that's purely based on geolocation. It will give you the most flexibility and granularity. Don't worry about other important metadata such as network association, organizational aspects etc. -- all of these can be expressed perfectly fine by using additional metadata dimensions that are covered in the next article in this section.

There is, however, one scenario where you may consider deviating from a pure geolocation namespace: If your organization has been using a hybrid namespace for years, and pretty much everybody is used to it. In that scenario, it might be better to just stick with the tradition rather than enforcing a new system on your coworkers (hint: they will hate you for it).

Whatever system you end up with, make sure that you have buy-in from major stakeholders, usually including multiple departments, before actually coding a location namespace and running with it.