Since I raised the topic of point naming conventions in my
previous post, I thought I would go ahead and share a couple of
additional concepts I think are important when considering point
Point Names versus Point Descriptors
Most current technology control systems utilize both a point
name and a point descriptor to identify and clarify the function of
any particular point. The slide below illustrates the
differences between the two in terms of where they typically reside
in many control system.
There was a point in time where systems simply worked with point
names; there were no descriptors, mostly because there was not
enough memory to support them. As technology evolved, memory
allocations became more generous, especially at the network and
operator workstation level. But at the controller level,
memory still could be a limitation, especially if you wanted to
structure your system so that the older controllers in the product
line could use the same infrastructure, programming language, and
support tools as your newer controllers.
What all of this means is that if you are working directly
at the controller out in the field with a service tool, you may not
be able to see the point descriptor, just the point name. The
descriptor typically resides at a higher level in the control
system and is matched up with the point name for presenting
information to the operator looking at the system from the operator
work station. Ideally, you should try to use this to your
advantage so the two complement each other.
The point name will likely be limited to a short
character string and be a bit cryptic. Adopting
standard abbreviations and using upper and lower case characters if
possible can go a long way toward making even cryptic points more
user friendly. For example I think it is easier to decipher
versus AH1LVGTM; the upper and
lower case letters kind of guide my eye into breaking up the
abbreviations in the first case.
The point descriptor will likely have a larger
character string associated with it, allowing a more
robust description of the point to be provided. Still
consistency is important. For instance, are the sensors in
the discharge of the fan Leaving Air
Temperature sensors or Discharge Air
Temperature Sensors? Or, are your Chilled Water Pumps
CHWP-1, etc. or are they CWP-1, or CHP-1,
etc.? There really is no right or wrong answer here.
But if you keep things consistent, most operators would agree that
it makes there job easier and also makes it less likely that they
will make a mistake, especially in the heat of a crisis.
If you have more than 10 of something, it can be highly
desirable to number them 01, 02, 03 … 10,
11, 12 … 20 etc. rather than 1, 2,
3, … 10 ,11, 12 … 20. This is because in most
computers, numbering the first way will sort like this:
Numbering the second way will sort like this.
It can be easy to miss an alarm on AHU2 when it is buried down
the list after AHU19. You expect it to be at the top of
the list and when it isn’t you may assume all is well when in fact,
there is a problem.
The bottom line is that taking the time to set up a naming
convention can be time very well spent, either at the beginning of
a project or at the beginning of a major control system
upgrade. In reference to Michael Ivanovich’s recent post
controls industry feeling disenfranchised by the current
commissioning process, this may be an area where you as a
control contractor could help make a difference. By taking
the time to develop a naming convention and then making it freely
available to consultants, owners, commissioning providers, and even
your competition, you will be taking a step to level or even
elevate the playing field, which is good for everyone. And in
the process, you will probably make yourself stand out a bit from
the others, which can’t hurt if someone is considering purchasing
your product line.