For those of you who did not hear the presentation at the TWG meeting yesterday.

Summary:
- There is not a site wide EPICS process variable (PV) naming convention
- This is potentially problematic for both the accelerator and beamlines 
  as duplicate PV names could accidentally appear.
- No one knew what naming conventions were in use at the APS and what 
  the likelihood for problems was.
- BCDA and ASD Controls with help from 22 sectors surveyed the naming 
  conventions in use.
- The results of the survey show that no catastrophic conflicts currently 
  exist.
- There are some significant conflicts, but these can be accommodated.
- We propose recommendations that would provide a smooth road to a 
  well-defined, site wide naming convention.
- Just knowing where we stand is a huge benefit.

Introduction:
Interestingly, although there is an accelerator naming convention, there 
has never been an attempt at APS to implement a site wide naming 
convention for EPICS process variables. Historically, there was little 
need for such a convention because each beamline was isolated on its own 
subnet, thereby providing complete isolation from other EPICS process 
variables. In effect, each subnet had its own "PV name-space" which did 
not conflict with others. 

In retrospect, this was quite shortsighted. With the advent of PV gateways, reverse 
PV gateways, and liberal use of EPICS_CA_ADDR_LIST  (which directs channel access 
clients to broadcast to multiple subnets), things are becoming increasingly 
complicated and confusing. With these capabilities, the name-spaces have been 
essentially shorted together and, in effect, everyone now shares a common 
name-space (e.g. if two users define a PV with the same name, some configurations 
of gateways/EPICS_CA_ADDR_LIST/clients will break).

Many problems may arise from this combination of name spaces. For example, you have 
an application with a PV named "my:pv" that has been running for years. One day, 
unbeknown to you, a developer on another subnet brings up an ioc with a PV named 
"my:pv". Your application may now start to misbehave even though you have changed 
nothing. It is true that the PV gateways have filters that can block traffic, however 
the filters are already becoming quite complex and are taking increasing amounts of 
time to administer.
 
Although we have not yet fallen into total chaos, we feel it is extremely prudent to 
have a plan for the next 20 years that will avoid such a situation. We wish to be 
proactive rather than reactive.

Survey Results:
We surveyed the PV prefixes in use at the APS. We received responses from twenty-two 
sectors and included the entire set of accelerator PVs.
In general, (with a few exceptions), the conventions in use can be classified as 
follows: -
- 13 sectors use a convention that starts with the sector number 
  (e.g. 9ida, 14BMD, etc)
- 5 sectors use a convention where the prefixes are lower case 
  (pnc*, id*, bwi*, lax*)
- 2 sectors use S##[ID,BM] as a prefix
- 1 sector uses BM, BMT, and ID as prefixes
- 1 sector uses only PVs from APS supplied templates
The exceptions to these stated conventions are: -
- Several sectors use template databases for a machine status link module and bunch 
  clock modules that generate PVs of:
- S$(unit)*
- BL$(S)* 
- A few sectors had PVs that clearly did not follow their convention (test databases, 
  etc.) 

Recommendations:

If we take the following steps: -	
- All �maverick� PVs were corrected
- APS templates for the bunch clock and msl-mrd100 modules were �modified� (which 
  would change PV names)

Then a stated convention could be for beamlines, �All beamline PVs should begin with 
their sector number [preferred] or lower case letters�. 

And for the accelerator, �All accelerator PVs (those on the .2 subnet) should begin 
with capital letters (almost)�
We would be left with the following known exceptions: -For the beamlines
- S10ID* (MRCAT)
- S17ID*, S17BM*  (IMCA-CAT)
- BM*, BMT*, ID*  (SBC)

For the accelerator
- ioc*   (6065)
- Other lower case: (156)
- PV Gateway PVs on subnets; Snn  (11/sector)
These beamlines can be accommodated by having custom filter configurations on their 
gateway machines. They may in future be limited to the number of accelerator PVs 
they can access. This would necessary to prevent name conflicts.

The accelerator controls group would have to rename their PVs to begin with upper case 
letters. This would be done gradually.

Action items:
Beamlines
- Publicize your PV naming convention to whoever might create PVs 
- Correct �maverick� PVs that violate your own convention
- Assist in installing new template databases
- Consider �preferred� convention over self-created

BCDA
- Provide new template databases for APS modules
- Provide a web page describing PV naming conventions and �grandfathered� exceptions
- Provide assistance in converting templates and client applications

Accelerator Systems
- Adapt to and stay consistent with the convention
- Maintain PV Gateway access lists consistent with the conventions
Conclusions:
The preferred convention would be, for beamlines; 
�All beamline PVs should begin with their sector number [preferred] or lower case 
letters�. 

And for the accelerator;
�All accelerator PVs (those on the .2 subnet) should begin with capital letters 
(almost)�

We have gone from a state of ignorance of the PV naming conventions in use at the 
facility to having a good understanding of the conventions used. This in itself is 
a huge benefit. Thank you to everyone who took time to respond to the survey.

We can state a preferred naming convention that covers the vast majority of existing 
cases. With a relatively small amount of work, we can eliminate some of the existing 
exceptions to this convention. Some existing exceptions that break the new convention 
will have to be accommodated. 

The existence of a site wide PV naming convention will be a huge step forward in 
ensuring name conflicts do not occur in future and provides guidance to those creating 
new PVs. This will help to ensure reliability of the accelerator and individual 
beamlines.

Filter configuration of gateway machines will become much easier. Instead of over thirty 
custom configurations, we will have one standard and three custom configurations.

We would like this convention to be adopted by consensus. We feel it benefits everyone. 

Thank you,

John Maclean,
Ned Arnold.