[evla-sw-discuss] MIB software architecture

[Barry Clark]

It seems to me useful to distinguish between things associated with
the MIB proper and things associated with the Device that lives in
the MIB, because we will likely want to directly transport the Device
to other environments, and there are some functions which are unique to
the MIB, and therefore untransportable.

----------

First the functions associated with the MIB:

double getTime();
returns the double MJD+fraction

functions that return information from the slot identification flash

struct sockaddr_in  *getEtheraddress();

additional slot flash stuff I'd like to see:

char *getLocation();
returns a string like "AN11", or "CB", or "AOC"

short getDeviceType();
returns a Device Identifier

Tasks associated with the MIB:

- Task that listens on a socket that might receive a message saying
"reboot yourself", "shut down the Device", or "reinitialize Device".

- Task that listens on a socket for a message saying "When this message
was sent, the time was....".  It would leave this information for use
of the getTime() function, along with the system timer reading when the
message was received.

- Task that listens on a socket for a message saying "I want to send you
a new set of software to store in your program flash."

These guys all need to be higher priority than anything in the Device.
They could be, but don't have to be, implemented as a single task listening
to a single socket.

There would also be a heartbeat ISR associated with the MIB.  This would
record the system timer reading for the use of the getTime() function, 
and might optionally release a task associated with a complex Device.

--------------

There are three principal types of objects in the MIB:  Device, MonitorPoint,
and CommandPoint.  The paradigm is a single Device in the MIB, but code 
*requiring* this should be avoided.  There will be many MonitorPoints and 
CommandPoints in the MIB.  Devices, MonitorPoints, and CommandPoints should 
be conceived to be static.  That is, a single Device and full set of 
MonitorPoints and CommandPoints will be created at Device initialization
time, and will be destroyed at Device shutdown time, with no additional ones
being added or destroyed in between.

There are four tasks associated with the generic Device, spawned at Device 
initialization.  Three make and send DeviceDataRecords, a task for each
of the "attention" addresses in the DDR.  (These could  be a single task,
but I think priority ordering might be useful, to keep the screen driving
task from interfering with the other two.  The three tasks probably run
the same code, with a different timing queue for the MonitorPoints.)  
One task would listen to the service port, accept commands from it, interpret 
them, and respond accordingly.  Additional tasks may be associated with 
specific Devices, which inherit from the generic Device.

The command listener would pass commands to the separate CommandPoints,
by calling an action routine.  If the command will take some time to
execute, the CommandPoint code should spawn a task to execute it, and
return immediately.

Some commands will be directed to the Device itself.  The ones that come
immediately to mind are listed below:
- Set all archive logging rates to default
- Set all observing layer logging rates to default
- Set all screen logging rates to default
- Set all screen logging off
- Set archive logging of a named monitor point to a given queue
- Set observing layer logging of a named monitor point to a given queue
- Set screen logging of a named monitor point to a given queue
- Set archive logging of a named monitor point to a given queue
- Respond with a list of known MonitorPoints
- Respond with a list of known CommandPoints
- Respond with the properties of a given MonitorPoint
- Respond with the properties of a given CommandPoint
- Set "Device in_use/not_in_use by observing layer"
- Send default values to all CommandPoints