I think Bob gave a pretty good summary. Even tho I came from
a very different perspective (e.g. spending more of my career
*not* using EPICS than using EPICS), I found myself agreeing
with his observations and conclusions - especially about being a
"very old guy"
Just to put things in perspective, here is a link to the 1970
edition
of "Brookhaven Highlights", which includes an article on the
*upgrade* to the computer control system of the AGS (also
available on Google books).
https://www.dropbox.com/s/feov3wdzdaj3pvj/Brookhaven_Highlights.pdf
TL;DR - prior to the upgrade, pdp-8 industrial computers were
used for local control functions. After the upgrade, a centralized
pdp-10 was used to aggregate the pdp-8 controls. Depending on
your perspective, you might say this was an early distributed
control
system, or the opposite - an early version of a single,
centralized
database of all control parameters.
Even in this era, people recognized the benefit of reconfigurable
toolkits. I never worked on the pdp-10 myself, but my
understanding
was that there was a single configuration file (called a device
definition
file) at the core of the control system. It functioned much like
an EPICS
.db file - giving parameters a name, a H/W address, scale factors,
etc.
Prior to about the late 80s, there wasn't really widespread,
uniform
commodity hardware on which to deploy control systems. Windows
and Mac OS/s were not capable enough. UNIX was highly fragmented.
Even networking was fragmented (DECNET, AppleTalk, IPX protocols,
token ring, ethernet hardware, etc.). VAX/VMS had a strong
following, but
did everything their own proprietary way. Only SUN (and to some
extent Apollo) were both capable and very willing to embrace open
standards.
VME was not widely used before the 1987 version of the standard.
I cut my teeth on Multibus, iNTEL's PLM language, and iRMX OS.
Even then, it was recognized that large-scale distributed systems
were
only manageable if they were based on toolkits and could be
centrally reconfigurable. Even tho my iRMX systems were
PROM-based,
I developed a protocol for downloading executable code directly
into RAM,
so that I wouldn't need to manually replace PROM chips to
distribute
S/W enhancements.
What that means is that any facility that had computer controls
prior to
that time had some bespoke control system, and some (SLAC, BNL)
even designed bespoke LAN systems. I suspect some facilities may
have
designed/built computers as well. As Bob said - this took a lot of
engineering and a lot of coding (for not much return by today's
standards).
Many of us breathed a sigh of relief when we could design/build
distributed control systems using SUN OS, 10Mb/s (shared)
ethernet,
VME and VxWorks. Others backed the centralized approach, typically
based on VAX/VMS. In either case, we were able to focus more on
domain-specific H/W and S/W, and start using systems and S/W
provided
by others to make everything work together.
For the first time, collaboration with other institutes was
possible, but not
necessarily embraced - even between institutes with similar
perspective
on appropriate control system architecture. My recollection may
well be
off-base, but I think of the APS as the first large-scale new
facility that
whole-heartedly embraced (and depended on) control system
collaboration.
During this era, both EPICS and TACO (which evolved into Tango)
were
developed and shared among facilities. Tango remained in the
province
of synchrotron light sources, but EPICS branched out into a
variety of
facilities, including telescopes (and even industrial systems).
Fast forward to the present, I can comment on RHIC -
RHIC itself *could* use EPICS, but RHIC is part of an
accelerator
complex. In addition to the the baggage still being carried due to
its
nearly 50-year history of computer controls, the complex has some
requirements which are not readily met by EPICS - to do with the
simultaneous
operation of the various accelerators in the complex to serve many
science programs. The controls S/W and the high-level apps are
designed
to make each science program feel like they have exclusive control
of
whatever accelerators they are using, and the underlying S/W
manages
the scheduling of the interleaving of the operations of the
accelerators.
I have heard of efforts to implement this in EPICS under the name
"flavored
records" - but it has never become mainstream, and I doubt it ever
will. Even,
so - it takes more than just flavoring the records - the flavor
would have to
be understood and honored by high-level apps, like EDM, channel
archiver, etc.
For that reason, I doubt EPICS will ever be used for the
accelerator complex
which includes RHIC. It is then a difficult argument to make to
use one control
system for RHIC, and another for the rest of the complex -
especially while the
complex *still* carries baggage. Although the pdp-10 is gone,
there are still
a handful of Multibus systems in critical roles!
However, it is hard for me to imagine building a new, dedicated
purpose
machine with anything *other* than EPICS. To me it would be like
deciding to
write a brand new computer operating system to rival LINUX. There
may be
some arguments to do so, but it is so much work, there had better
be
some outstanding benefit to justify undertaking the effort and
risk.
High-level S/W, OTOH, is more like writing a new web browser than
writing a
new operating system. I doubt that there will ever be convergence
on a
one-size-fits-all solution for every facility. CSS seems to have
the most
momentum today, but I remember when Netscape had the most
momentum...
I hope this stroll down memory lane was interesting to someone
other than me.
If not, thanks for indulging me -- larry
On 9/16/2013 3:01 PM, Emmanuel Mayssat wrote: