[evla-sw-discuss] AMCS Architecture's impact on the OS/Language we choose (and vice versa)

[Kevin Ryan]

Hi all,

Based on concerns and issues raised, I get the feeling that some 
people are still thinking in terms of a central processing type 
monitor and control architecture.  I want to express that we must
think in terms of modularity if we want a flexible system and
what impact this will have on the OS's and language we choose.

I've written information similar to what is presented below and
people have said that they've read it, but I get the feeling that
some have not understood it.  So please take enough time to truly 
understand the few concepts presented below.  You will then find
that issues such as "where will the MIB screens reside" and "where
will the technician plug in his laptop" are not issues at all, 
in fact their answers are obvious and natural.  

Understanding this system will also help us to think along the 
same lines while looking into MIB OS's

If Barry does not mind, maybe we can talk about it at the next
meeting.

Thanks for taking the time.

Kevin

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

More emphasis needs to be placed on supporting the software
architecture of the EVLA AMCS.  Successful AMCS software creation
depends on The following items in the order presented:

1) The language must support the software structure - Object Oriented.
2) The Operating System must support the language.
3) The hardware must support the OS.

Instead we are working exactly backwards from this (albeit, the
RFI issue is responsible for *some* of this backwardsness)

One of the main requirements of the EVLA is that it be flexible.  The
online system must be able to support different types of antennas
operating within the same array.  Different antennas mean differences
in the way their hardware is controlled at the lowest levels (the bit
registers within the hardware components).  These differences preclude
the use of status quo systems that use a single central processor to
control all antenna hardware at the bit level.

The alternative is to let the low level hardware components control
themselves via use of their own embedded processor.  This is called
distributed processing.  This model means that the central computer
needs only to tell the hardware *what* must be done, the embedded
processors in the hardware take care of handling the intimate details
of *how* the control is carried out.  This effectively hides the 'bit' 
requirements from the upper level central computer.  Now different 
antennas types can co-exist in the same array under control of the 
same central computer without the central computer having to know 
about the differences.

Distributed processing (if done properly) results in modularity 
which in turn results in flexibility.

There are a few rules that must be met in order for such a system 
to work:

1)  A module must be completely stand-alone.

2)  Modules can only be aware of themselves and those below them.

3)  Upper level modules cannot know implementation details of lower
    levels.  

    The last two rules cause the following implications:

    1) Command data must specify *what* not how.

    2) Command data must flow from high to low levels (not up or sideways).

    3) Monitor data must flow from low to high levels (not down or sideways).

    4) Monitor data must be generic in nature when crossing levels.

What does this mean to us?

1) Completely independent modules:

  - No module must rely on any other module for operation.  In other
    words, the Antenna Computer will not be needed to operate the
    1st LO. 

   Benefits: A module can be operated, tested, troubleshot, maintained
             without being in the system.  This means Wayne will not need 
             his own version of the antenna control process in order to 
             stimulate the broken 1st LO on his bench.

             Changes and mods can be made to modules with minimal affects
             (and hence minimal regression testing) on the rest of the
             system.

             Different module types/models can be controlled by the same
             central processor without it having to know about their
             differences.
 
2 and 3) Modules aware of themselves and below, and implementation details
         are hidden from upper levels means:

  - MIBS will not be aware of each other, nor will they know the concept
    of an antenna.  No inter-MIB communications.

  - The Antenna Control Process will be aware of its components (LO's,
    servos, etc.) but will only see their 'front panels', not their
    guts.

  - The Logger cannot request that a certain monitor point be logged;
    instead, the monitor point must present himself to the logger at
    the required interval.  Why?  Because the monitor point is an
    implementation detail that the logger is not allowed to know about.

    Consider this contrived example:  The EVLA uses 5V logic in its
    1st LO Synthesizer and needs 2 power supplies to supply the 
    required current.  The NMA antennas will use only a single 3.3V
    power supply.  If the logger asked for monitor points, he would
    have to know about the differences in order to ask for the right
    info from each antenna type.  This is not good.

    In the proposed system, the logger is 'dumb' in that he takes anything
    that conforms to the rules of a datum.  He does not care what it is
    or where it came from.  His job is just to log it.

  - Monitor data screens will be similar to the logger.  Monitor points
    will only be built into 'screens' at the level which they originate.
    (A MIB screen will know about the 5V power supply, but an array
     operators screen will not - this doesn't imply the operator won't
     be able to see the 5V PS from his screen, only that the PS monitor
     point will not be hardcoded into his array GUI).

    Benefits:
     - Operator screens will not be clogged with unnecessary monitor data.
        Each module will keep track of itself and its children.  As long
        as each monitor point that the module watches is OK, there is no
        need to alert the operator.  He will see 27 green blocks on his
        control screen.  When the 1st LO Synthesize 5V Power Supply #1
        smokes in Antenna 13, the operator will see 26 green blocks and
        one red one.  When he selects the red one he will see that that
        the 1st LO block is red, when he selects that, he will see that 
        5V PS #1 has failed.

        This does not mean the operator can't look at every single monitor
        point in the whole system if he wants to (he can certainly select
        every one), it just means he is not forced to.

      - Monitor points can actually be monitored more often and more
        thoroughly because they have a dedicated processor to oversee
        them instead of human wading through a screen full of data.

Why software is so important.

We locked ourselves into a distributed processing modular system when
we selected Ethernet as our field bus.

The above modular system cannot be made by using the concept that a
MIB is only a gateway to a device's registers.  We cannot make a robust 
system of heterogeneous antennas and antenna subcomponents communicating
over Ethernet with Internet protocols, using the idea of a single 
central processor peeking and poking thousands of bits of data to
and from thousands of registers.

The MIBs have to be smart enough to fit this whole system concept of
modularity and distribution of functionality. 

Object oriented development works and works well to speed design,
help ensure 'correctness' and promote software re-use.

The above modular software model is very well defined using OO 
principles.

Java is a very good OO language.  
 - It was originally designed for embedded systems so it can be very small.
 - It was designed for network operations.  Designing networked client
   server programs are almost trivial in Java.
 - It was designed with safety and security in mind 
      - a programmer would have to go out of his way to write to a 
        null pointer.
      - a programmer is forced to resolve all possible exceptions (bad
        things that could cause it to break) at compile time.
 - It was designed.  C++ is a bloated hack job.
 - It has Java Beans which might work quite nicely for our model.  A
   Bean hides details inside itself but presents to the rest of the
   world what it is, what its attributes are and what it can do.  

We have a much higher level interface (TCP/UDP/HTTP/IP over Ethernet)
we need higher level software and OS's to handle this.

I agree with Barry that we should avoid middle-ware if possible.

If we are forced to use C only then we should consider NDDS (middle-ware) 
because IP communications in C will not be trivial.

Conclusion.

Modular design is essential for flexible operation and growth in
a heterogeneous system.

It is no longer questioned that software represents the majority
of the expense of a project in terms of development time and ongoing
maintenance.  

The more capable the language/OS that we choose up front, the less 
expensive and more efficient is the development and maintenance over
the long haul.