====Asset Guidelines====

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

These guidelines are suggestions – they are not enforced. 

===Asset Naming===
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'''

===Massively Connected Devices===

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.

===Servers & Services===
An asset can only provide one source of live data, and one source of historical data per [[ardiuserguide:contexts|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.