Explanation

This section is more philosophy than anything, but here goes.

Let's choose naming conventions that have the next design revision in mind. Keep in mind the old adage that "no design survives implementation".

We refer to this as crossing the revision boundary. Does the naming convention that you pick today survive the revision or do you need to rename a bunch of stuff.

We'll explain further as we move through this philosophy.

Project Naming

Consider the following when naming a project. It will not be new a year from now so don't name it My New Project. My New Project does not cross the revision boundary because tomorrow it will not be new.

On the other hand. Consider "2018 Studio Modifications".

Does this cross the revision boundary? The answer is a resounding... maybe. If there are no other studio modifications in 2018.

Better would be: "Summer 2018 Studio Modifications".

Drawing Naming

Consider human readable names for your drawings. There is an alarming trend in the industry to use number based drawing names. This works great if you have the secret architectural decoder ring. But come on!

SysNames

The SysName field is an identity field. It is meant to uniquely identify the product within the system. You may have 50 speakers in the project. SPKR-10 should be unique and locatable.

Consider the abstraction you use to prefix your SysName. In the preceding example we used SPKR, but we could have used SPEAKER, or SPK, or SP. Any of which would cross the revision boundary.

But what's wrong with "ATLAS12INCH70V-10"? You ask.

Consider that a couple of things could happen to render this information inaccurate:

1.The product may be back-ordered during install forcing use of a different make/model.

2.The product fails in the field and must be replaced by a new make/model.

Hence the abstraction. We can safely abstract the 10th Atlas 12" 70V speaker to SPK-10 because if any of the make/model information changes we have a valid SysName that crosses the revision boundary.

Alias

It has been our experience that a device may have two names:

1.The engineering name. The name that the technical staff knows this gear by.

2.The operational name or the logical name. The name that the operational staff knows this gear by.

For example:

Consider a facility that has 20 video servers. Some of them are used for ingest and some for playout.

Engineering knows these 20 devices as SRVR-01 thru SRVR-20.

Operations may know SRVR-01 as Ingest Server. They don't care what engineering calls it. They just know what is does for them.

Hence the Alias field.

SRVR-01 can also be known as Ingest Server.

Consider the Alias field to be any one of the following:

•The friendly name.

•The operator known by name.

•The functional name.

•The logical name.

Another use of the Alias field is to describe the source for the downstream device.

Look at the following block diagram.