Asset Guidelines

These are guidelines that should be followed when building your ARDI system.

These guidelines are suggestions – they are not enforced.

Always properly capitalise your asset names.

It can be difficult to give unique names to your assets, but we suggest always trying to do so. Normally, your ISA-95 or Location hierarchy will give you pointers, particularly if you have sections of your system that you expect to duplicate.

For instance, if you have a system that contains 3 boilers, you should name your boilers “Boiler #1”, “Boiler #2” etc, and also include that detail in items within that boiler (ie. “Boiler #1 Inlet Temp. Transmitter”). This also will have particular advantages when you duplicate items. When you duplicate a section of your ARDI system, any numbers that are written immediately after a hash (#) will be added to.

For example, let’s take a look at this simple three-piece system.

'Boiler #1 > Boiler #1 Tank > Boiler #1 Inlet Temp Tx'

On duplication, “Boiler #1” would be converted to “Boiler #2”.

Thus your duplicated structure would be…

'Boiler #2 > Boiler #2 Tank > Boiler #2 Inlet Temp Tx'

PLCs and other devices with a large amount of I/O should be modelled as a several assets – we normally suggest treating each modular card as a separate asset.

This radically reduces the number of connections involved to a single device, making your system run more efficiently and your relationships easier to visualise.

An asset can only provide one source of live data, and one source of historical data per context, so if you have a complex system such as a server that provides multiple different sources of information, you should consider splitting it up so that you have…

• One asset representing your server hardware
• One asset per virtual server running on that machine (if your server is not virtual, you can skip this)
• One asset for every major service that the server provides.

This design helps clearly indicate what services are hosted where and also means that you can link to a number of simultaneous services provided from a single virtual machine.