To: Bill Allen
William Colocho
Roger Erickson
Cheryl Hultquist
Peter Schuh
Mike Stanek
Fm:
Spence Clark
Bob Hall
Ginger DeContreras
Re: E-Log Meeting
Operations
and Software Engineering met to discuss the functionality of the new E-log
purloined from Jefferson Labs. There
were discussions of Log Requirements and Support.
Support: SWE expects that E-logs are a fact of the
electronic age we live in, and propose to support one E-log package to the same
standard as the Control System. SWE
would support the Application package and run it on a Sun Solaris system
supported by SCS (ORACLE and SOLARIS updates plus security patches). The whole system rests on ORACLE, which is
the most robust, secure, and reliable of the alternative data base packages. SCS backs up all ORACLE server data and makes
it available essentially into perpetuity.
We
expect that the features of the E-log would evolve over time and be enhanced as
needed. The more we customize the code,
the harder it becomes to pick up enhancement features generated within the
EPICS Collaboration. The more copies of
the E-log we run the greater our maintenance burden. Change requests are considered on a priority
basis as is any/all control system development.
E-log
support and maintenance is not currently vested in any single individual who
supports this package as his/her top priority.
Realistically, one or two developers will work on E-log features on a
priority basis with other control system application projects. If the
application requires substantial support and/or development, it may be
necessary to hire an individual to support the package – time will tell.
Permissions & Security: The package currently lists authorized
users who may write to any of the existing logs resident in the logging
environment. We will look into
implementing separate password control lists for each included log. We will also understand whether it is
feasible to limit changes to the text to the original author or super-user through
user ID and password control.
The
E-log would be visible from within SLAC to any person with a Lab Unix account
and password. Write access would be more
limited in a manner yet to be worked out.
Access from outside the Lab would be limited to those who have access to
the Lab through secure encrypted tunnel protocols (SSH probably).
Log Architecture: The
E-log is set up as a series of logs within a single logging facility. This means that the rules and features of all
the logs are the same. Log entries can
be sent to multiple logs concurrently, and all logs within the system can be
searched integrally for events that may effect other
logs (ie a SPSS entry may explain an accelerator
behavior for). All of the log data is
contained within a single instance of ORACLE.
Introducing
different rules, features, and functionality for each
included log within E-log is a huge software effort. Lots of code has to be developed that
understands what and how to treat entries with different log names. Complexity for users and package maintainers
grows quickly.
Implementing
multiple versions of the basic E-log package for the purpose of creating and
using different features and functionality is possible. Doing so makes maintenance a rapidly growing
headache due to the many similar but different sets of E-log code. Each separate log package uses a separate instance
of the ORACLE database and hence prevents you from easily searching one log in
the context of other logs. Log entries to multiple logs is no longer possible (SPSS has
to make an entry to their SPSS log and the MCC log separately). Upgrades of E-log
or ORACLE have to be implemented separately for each copy of the
application. EPICS Collaboration support
for the underlying package is gone we’re on our own.
JLab uses multiple servers for the E-Log package to continue logging
when some servers are down. This is an
expensive option to temporary paper logs, but is feasible. Multiple version of E-Log on multiple
platforms may not be practical.
Log Data Edits: The
current log structure (implemented by JLab to meet
DOE requirements) does not allow changes to log data after the entry is made
and the ‘enter’ key pressed. Changes and
corrections are made with separate entries made at the time the change is
recognized as necessary.
With
substantial effort, the log software could be modified to allow entries to be
written to a temporary buffer for a period of time (ie
shift plus 1 hour) so that all entries could be edited by the original author
during the shift. This temporary entry
buffer would have to be visible during the course of the shift, and archived
after the shift ends. Details to be
worked out include who closes the log, when the edit window closes, and the
propriety of changing what who knew when.
It is not clear that this implementation meets DOE requirements for
Operations Logs.
There
was some discussion of which users may edit what kinds of entries (superusers & summary editors). This would require code to recognize and
authorize actions among entry authors and special users. Code complexity is unknown until fully
described and implementation options understood.
There
was a request for a SCP user interface (probably TCL-TK) along with the current
WEB user interface. A SCP user interface
is feasible, but often requires substantial support - a more complex and
potentially user friendly interface (with web like capability) would surely
require additional staff. This is a
balance of user friendliness of a key resource (used all day every day) versus
the potentially high maintenance for a GUI tool (either SCP or WEB based or
both).
Features
for spelling checks, scanning, Tablet PC, Screen Grab, and X-windows
interfacing were listed but not discussed.
Links between an E-Log and Artemis were broached but not discussed.
Implementation: E-log facilities have been difficult to
implement in any widely agreed and maintainable form in the past. The current wide range of functionality views
among various user organizations and individual users remains a concern.
Automatic
entries was discussed briefly – probably a feature of significant value. Record recurrent data at shift change or time
increments for log summary purposes.
Operations notes substantial system requirements and changes
before beginning to use the system. The extent
and implications of some of these changes are yet unclear. Implementation priority and sequence are
unknown.
SWE
is concerned about the level of effort to be invested in an E-log system without
agreement among the potential users. Development and maintenance in times of
limited software resources remains an ongoing issue. The JLab Log was
adopted due to the prospect of meeting DOE rules and obtaining a mature package
supported by a similar Lab.