[evla-sw-discuss] The "In Use" flag - Devices, the Executor

[Bill Sahr]

I know Pete's busy with the T304/305 and the DTS module coming.
Hichem is debugging the CMP, and Rich is working hard & fast on
screens for the Operator's, but I don't want this issue to get
lost.  So, I give below an email from Barry on the topic.

Given the above, I don't feel I can push, at this time, for a
specific date for implementation of this item.  However, what we
have been calling the 'in use" flag needs to remain on our screens
as an item to be implemented sooner rather than later.  The longer
we wait, the more painful it will be since it involves updates to
all MIBs.  Please also recall the comments of John Ford from the
EVLA M&C Hardware Review - that GBT put off the implementation
of equivalent functionality and now sorely regrets it.

BTW, see the 3rd to the last paragraph - the one sentence mention of
what is becoming a much needed lockout for the connection to the
Executor.

Bill

-------- Original Message --------
Subject: Re: MIB Issues
Date: Mon, 14 Mar 2005 08:16:20 -0700 (MST)
From: Barry Clark <bclark at aoc.nrao.edu>
To: pwhiteis at nrao.edu, rmoeser at nrao.edu, hbenfrej at nrao.edu, bsahr at nrao.edu
CC: bclark at nrao.edu, ksowinsk at nrao.edu, bbutler at nrao.edu

I would like to retreat a bit about what is needed to implement a lockout
to prevent accidental interference with an observation.  Some of the
earlier desiderata I talked about would be difficult to implement with
current structures, and do not seem to me to be worth the trouble.

To recapitulate the requirements, we need something that prevents
accidental interference with the function of a device, and do not
need at this level to attempt to deter malicious attacks.  And even
detering accidental interference need not be foolproof, but merely
pretty good.  And, unlike safety lockouts, there needs to be some
way of removing a lock if the owner absentmindedly goes home with
his lock in place.

I suggest just a mild generalization of the current VLA software's
Take/Give/Use commands.  The main generalization is to extend them
to Devices, instead of the whole antenna.

So one needs a system of passwords, and the implementation in the Device
of a command saying "use this password".  Then, any further "set"
commands would be ignored, unless they contained the named password.
There would need to be an equivalent "don't use a password" command,
to allow the entity reserving the Device to pass it along to somebody
else.

These commands would, by convention, never be used for a MIB device,
so that, if one is suitably desperate, one can always recover command
by saying "set mib.reboot=1".  For the CMP, rebooting the whole works
seems a little drastic, so we probably need a mechanism for stopping
and restarting single Devices.  (Or we can wait until somebody yells
at us for having had to reboot the CMP.)  Or, since we aren't worried
about malice, we might simply make the current password a monitor point.

A similar system needs to be in place for the AntennaServers, and, since
we have the opportunity, it should be built in on day one.

For the Devices, we might consider making having the password simply
be the inet address of the requesting computer.  This has the advantage
that it requires no change to the existing message formats, and the
getHostName() (executed at the time the lock is requested) could be
displayed as a monitor point to provide a clue to the probable name
and/or location of the lock owner.  This would, though be a nuisance
for a Servelet or jsp based browser, since the lock would be open to
everybody using the servelet unless an associated Applet issued the lock.

Devices would by default be locked to the Executor (or to the AntennaServer,
when it comes along).  So the scenario is:
Tech calls operator, says "I want to work on the T399 at antenna 32".
Operator, through Executor interface, tells Executor "Release lock on
    T399 at antenna 32."
To prevent being preempted by commands from the Executor, tech says to
    T399 "lock yourself to me."
After finishing his investigation, tech tells T399 "unlock yourself."
Tech calls operator, says "I'm done with the T399."
Operator, through Executor interface, tells Executor "Lock the T399 at
    antenna 32."  (Or maybe, just for kicks, "Lock all the Devices on
    antenna 32.")

A similar sort of lockout for the connection to the Executor should be
implemented soon, also.  We should at least settle on a design ASAP.

As part of a general cleanup I'm doing to AntennaPhysical, it is trivial
to provide a method to enable/disable sending of commands to any device,
and I shall do so, although it is not clear to me how this fits into
the general picture.

Do we need a flag "Device locked to somebody other than Executor"?
I'm inclined to say not, since we need the "Device has not yet done
what I commanded" flag anyway, and I think that should handle things.