OTbase uses names and identifiers to refer to OT devices, locations, systems, and other items. It is important to define a useful namespace for this purpose, because it makes a big difference for users and their capability to find what they are looking for. This activity should be completed before populating OTbase Inventory.
It wouldn't make much sense for OTbase to provide a fixed namespace as most corporations already have one -- at least partially. This is where the problem lies. Before you introduced a global OT asset management system, there was no need for a tight nomenclature when referring to OT devices, systems, locations and so on. A specific cabinet, for example, may just have been referred to as "Cabinet A", since the scope of documentation was local, for one building or site, and the reference may only have appeared in a humble Excel spreadsheet.
Things change dramatically with scale, when you absolutely must have a namespace that allows you to refer items of which you may have many, at multiple locations. The task at hand then becomes to extend an existing corporate OT namespace into terminology that can be used to inventory and retrieve hundreds of thousands of devices. Here are some tips on how to get there.
Avoid funny characters
In theory you can use all kinds of special characters in names and identifiers, but it's not a good idea. Consider the following in order to avoid problems:
Don't use national language characters. You will run into problems with proper display on various user interfaces, and your coworkers in other countries may run into trouble when entering search terms etc.
Don't use underscores. Depending on the type of display, an underscore can be hard to distinguish from a space character (" "), causing input errors. Consider using a dot, colon, or dash instead. The use of slashes is discouraged because you might give the people who write code to process REST API output from OTbase a hard time, as slashes are used in compound location names.
Understanding locations
Locations are probably the most important part of your namespace as many users get them wrong in the beginning, leading to cumbersome and unnecessary re-work.
A location in OTbase is something that you can point out on a map, or floor plan. You could take a photo of it. For example, a location could be a country, a specific site, room, or cabinet. A location could not be a network. Even if you are tempted to specify a network as a location, don't.
Locations in OTbase are ordered hierarchically, where the definition of the hierarchy is completely up to you. You can start with continents if you want to, or with sites -- just what happens to be most useful for you.
The location hierarchy is built of location names that you can arrange hierarchically by moving them around in the location tree. So for example if you have a site called Houston, it might be placed under Texas (assuming that there are other sites in Texas). Within Houston, there may be buildings, rooms, cabinets and such. In very general terms, a quite elaborate location namespace could include:
Continents -- Regions -- Countries -- Areas -- Cities (sites) -- Buildings -- Floors -- Rooms -- Cabinets
Note: that you can use areas or regions on different levels. For example, if it makes sense for you to divide a building or room (such as a production hall) in different sub-locations, you could introduce an area. Example: Building 3 / North side.
You will always need a location identifer to reference a location in OTbase (except for the rare occasion that you manually enter device data). Your location identifier usually is less verbose as it's often not intended for intuitive understanding but rather than a lookup symbol. For the example above, the location identifier might look like "B3-N".
Location identifiers are critical for correct mapping of automatically discovered assets in OTbase Discovery to the "right" location in OTbase Inventory. Discovery knows only about location IDs. It does not know about location names and hierarchies. It is in Inventory that you map a location ID, which is usually provided by Discovery, to its proper place in the location hierarchy. The benefit of this approach is that you can always re-arrange your location hieararchy without changing anything in Asset Discovery.
Device identifiers and names
A device identifier in OTbase is used to reference one particular device. The device identifier allows for a quick way to pull configuration data for a device either by using the quick search function in Inventory, or using the REST API.
The device identifier is automatically assigned by OTbase during import of Discovery data and uses the pattern Discovery node name + "." + device type + enumerator.
Note that you can change device identifiers to whatever you like unless your identifier is unique (OTbase Inventory will check this for you). In order to maintain device identity across ID changes you can use the device reference, which is also automatically assigned by OTbase but cannot be changed by the user.
The device name is preset by OTbase either with the host name or DNS name (if one was detected by OTbase Discovery) or with the device ID. You can change the device name to whatever you want, and it doesn't have to be unique. If you don't want to lose the DNS name / host name but want to assign your own reference, the best way to do this would be to use the device identifier, which also has the advantage that it yields fast queries.
Device groups
Device groups in OTbase provide a means to group multiple devices in respect to a shared characteristic. Device groups are hierarchical and primarily intended for better search and filter capabilities. They are not preset by OTbase and don't affect device identifiers.
When defining device groups it is helpful to have a good idea of what you want to achieve. For example, device groups can refer to technical and organizational characteristics ("IT/network") or to vendors and products ("Rockwell/PLCs"). Note that once you have chosen a specific path, there is usually no way back. So for example, if you have chosen the technical approach, you can still code vendors, but they would reside in the lower levels of the hierarchy, resulting in some vendors showing up in multiple branches.
Network names and groups
Assigning names and groups to your networks will greatly help users in finding what they are looking for. By default, Asset Discovery will assign the IP address of the network to its name. However this can and should be changed. A network name can already be specified in Asset Discovery, but it can be overwritten in Asset Center.
Bad network names are:
- The IP address of the network -- think about 192.168.0.0/24. You will probably have multiple networks with that address, making it difficult for users to find what they are looking for.
- A totally generic name, such as Ethernet or WiFi.
- The location of the network. It will be automatically assigned by OTbase Discovery anyway.
- The VLAN ID of the network. It will, too, be automatically assigned by OTbase Discovery anyway.
Good network names are names that give the user a hint at the function, or other specific characteristics of the network, such as HMI network line 12.
Network groups allow you to group networks that share similar characteristics and make those characteristics easy to grasp. Typical network groups are Realtime I/O, Non-Realtime I/O, Safety, Office, WiFi, and so forth.
System IDs, names, and groups
The system concept in OTbase is one of its strongest features because it allows users to see OT devices not on an atomic level but as higher aggregations where multiple devices work in concert and depend on each other. A typical example of an OT system is a production line, or distributed control system.
The system name should provide a catchy short description of the system, whereas the system ID can represent a corporate identifier that you may already use for the system.
You can use system groups to highlight various system categories, such as support systems (pressurized air, water, vacuum, ...), or different product types ("Candy bars", "Pet food", ...).
Aim at consistency
Once that your namespace is defined and documented, make sure that everybody uses it, rather than to invent their own. This particularly applies to situations where OTbase is used in multiple sites, maybe in different countries. One way to accomplish this would be to define location names and IDs before actually importing device data from those locations, giving those who configure OTbase Asset Discovery the ultimate documentation of which terminology to use in Asset Center.
Make sure that your namespace won't get messed up
Many parts of your namespace, when implemented in OTbase Asset Center, require a specific authorization to change.
Users must be member of a user group with read/write permission in order to be able to change network groups, locations and so forth. Make sure that only a handful of users actually have this permission because it is very easy to totally mess up your asset inventory by making funny changes to the namespace.
Comments
0 comments
Please sign in to leave a comment.