[evla-sw-discuss] [Fwd: [evla-mc] More on MIBs...]

[Bill Sahr]

-------- Original Message --------
Subject: [evla-mc] More on MIBs...
Date: 05 Dec 2001 17:36:58 -0700
From: Boyd Waters <bwaters at aoc.nrao.edu>
To: Kevin Ryan <kryan at zia.aoc.NRAO.EDU>
CC: gvanmoor at bclark.aoc.NRAO.EDU,
browen at bclark.aoc.NRAO.EDU,kryan at bclark.aoc.NRAO.EDU,
ghunt at cv3.cv.nrao.edu,bwaters at bclark.aoc.NRAO.EDU,
bclark at bclark.aoc.NRAO.EDU,wkoski at bclark.aoc.NRAO.EDU,
gpeck at bclark.aoc.NRAO.EDU,pnapier at bclark.aoc.NRAO.EDU,
rperley at bclark.aoc.NRAO.EDU,ksowinski at bclark.aoc.NRAO.EDU,
pperley at bclark.aoc.NRAO.EDU,phicks at bclark.aoc.NRAO.EDU,
fowen at bclark.aoc.NRAO.EDU,tcornwell at bclark.aoc.NRAO.EDU,
Brent.Carlson at nrc.ca,Peter.Dewdney at nrc.ca, bsahr at cv3.cv.nrao.edu,
bclark at zia.aoc.NRAO.EDU,kryan at ozone.aoc.NRAO.EDU
References: <200111271623.JAA01508 at ozone.aoc.NRAO.EDU>

EVLA M&C SOFTWARE ARCHITECTURE - SOME USE CASES

OK, I am emphatically not a hardware guy. But here's my attempt to
clarify Kevin's "Tech Laptop to MIB" diagram. Also there are some
scenarios which I hope will shed light on the use of the MIB software:


  off-board computer        on-board computer
 +-------------------+
 |  **               |   +-----+
 | /  \ __  MIB  ========| MIB |
 | \  /    DRIVER========|     |
 |  **               |   +-----+
 +-------------------+
    

Here, we have a software object ( the O-shaped thing at the left) of
some sort which talks to the MIB via a MIB driver. The software object
and the MIB driver are running on the same computer (on the left) and
the MIB is a seperate computer (on the right).

The connection between the MIB driver and the MIB (denoted by == ) is
Ethernet, protocol to be decided.

The connection between the software object and the MIB Driver is to
be decided; it's a software call. Maybe it's in-process (simply
calling a linked library, a function call) or maybe the MIB driver
runs in a seperate process from the softare object. Probably it's
in-process.

Anyhow, here's the key talking point:

This diagram describes the Tech Computer just as well as it describes
the Array Control Computer.


Define the object that talks to the MIB, via the MIB driver, to be
a MIB object. That is, it's a software representation of that
particluar MIB.

You can implement non-time-critical MIB behavior in the MIB object
running on the "off-board computer" -- that is, the MIB object gives
you lots of flexibility about different MIBs.

The MIB driver simply implements the communications protocol.



SCENARIOS


Here are three scenarios which (I hope) illustrate the use of this
system:



ARRAY CONTROL

Actor:  Array Control Computer (ACC), an automated computer system

 The Array Control Computer runs software that is models the array,
 and therefore this software contains a number of Antenna objects
 which model each antenna in the array.

 An Antenna Object may contain MIB Objects (each of which talks to an
 individual MIB) OR an Antenna Object may implement behaviour and talk
 to the MIBs without delegating to an object; there's nothing to
 prevent an Antenna Object from implementing its methods by making
 low-level, simple calls to the MIB driver to tell its various devices
 what to do.

 But the key point to recognize is that the Antenna object can go
 either way -- users of the Antenna Object do NOT need to know how the
 MIB functions are called.



ANTENNA DIAGNOSTICS

Actor: A technician using a laptop diagnostic computer

 A Technician's computer should be able to run the same Antenna
 Objects as the ACC.

 But there's nothing to stop you from creating diagnostic software
 that calls the MIB Driver directly. Probably there will be MIB
 objects which help to build the diagnostic software; when so used,
 these should almost certainly be the same MIB software objects that
 are used in the production system. 

But there is NOTHING stopping you from sending bytes over the Ethernet
to the MIB - nothing in the software, that is. This will in fact be a
possible diagnostic procedure. If such a procedure becomes de rigeur
for a MIB, for a particluar problem, however, then the procedure
should be "captured" by the diagnostic software.

That is, continuous refinement of the diagnostic tools must be
encouraged, and diagnostic heuristics should be captured, wherever
possible, by the software tools, for re-use in other parts of the
system.

So the technicians will develop procedures that find their way into
the operator consoles. Same software.



MIB SOFTWARE  DEVELOPMENT

Actor: A software/hardware engineer.

In order to create the MIB Driver (and potentially any MIB Objects in
software), the engineer must be able to talk to the MIB directly.

If the MIB understands Ethernet frames out of the box, then the
engineer's computer will use an Ethernet to communicate with the MIB
during MIB driver development.

Once the MIB Driver is written, all software development for the MIB
and the "off-board" computers will use this MIB Driver.

If there is a need for extra functionality in the communications
channel, this will be added to the MIB Driver. That is, no software
(besides the MIB Drvier itself) will talk to a MIB via "raw" byte
streams -- all software must go through the driver.

-- boyd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nsmail3C17EC6E4F5161E
Type: application/pgp-signature
Size: 233 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/evla-sw-discuss/attachments/20011212/ac3effc0/attachment.sig>