Experimental Physics and
Industrial Control System

Ben Franksen <[email protected]> · Wed, 13 Oct 2010 18:45:27 +0200

On Mittwoch, 13. Oktober 2010, Josh Stein wrote:
> I would like to point out one warning with these embedded scripts -
> there is a very real possibility of breaking some higher level tools
> which rely on 'crawling' the startup command files for information.
> This very issue has just cropped up here at APS when the st.cmd
> structure of a number of our production IOCs was cleaned up during a
> recent 3.14 upgrade.
>
> In essence, some of our crawlers were unable to parse relevant tags
> since they failed to show up in the st.cmd file itself as those tags
> were moved to one or more of the 'sub-scripts'.
>
> For now, the crawlers at APS are being re-written to follow the
> indirection. This is yet another example of how fragile the system
> structure can grow over time; the hooks into various parts actually
> increase the risk of things breaking as time progresses.

Yup. Reverse engineering installed files is a simple and clever solution 
to the practical problem of finding out what is actually installed. But 
*of course* it is liable to break whenever the *structure* of the 
installed stuff changes.

The obvious solution to the dilemma is to create a central service that 
serves as source to both the installed files *and* the big picture 
(e.g. Irmis) and presumably other stuff like alarm handlers etc. But 
how can we design something like that while still retaining the easy 
editability (and the ability to use version control systems) that we 
have with plain text files? This is the million dollar question we have 
been discussing at BESSY ever since it became clear that a growing 
number of Oracle database tables (with a specific set of tables for 
each kind of device/application) is *not* an easily editable and 
maintainable solution in the long run.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System