TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: "Paul D. Stachour" <[log in to unmask]>
Date: Sun, 11 Jan 1998 22:56:14 -0600
In-Reply-To: <[log in to unmask]> from "Michael Feldman" at Jan 10, 98 12:42:16 pm
Reply-To: "Paul D. Stachour" <[log in to unmask]>
Parts/Attachments: text/plain (65 lines)
> >
> > Mike Feldman asked > Is the flight-deck instrument panel in a 777 a GUI?
> > Is it a real-time embedded system?
> >
> > Asking about complicated systems, the best answer is probably that
> > there is a separable user interface and several embedded systems in a 777.
> Yes, I agree.
> >
> [good points on the benefits of separation of concerns, layering,
> and not tightly coupling interfaces to realtime process control]

Here's some data about Ada and GUI's that you may find interesting.

On the project where I am working now, there are both real-time
and GUI aspects.  This is a data-acquisition and presentation system.
Here's some notes:

  - It interacts with messages from embedded devices (no operator,
    in fact some of the devices are designed to turn themselves off
    after some period of use)
  - It sends and receives messages in real-time to other, similar,
    but not identical systems beloning both to its own organization
    and to other organizations.  These message pose all the usual
    problems of variation in format and content due to the differing
    organization and other situations not discussable in a short space.
  - The system has a variety of operator consoles with data-formats
    ranging from ones as old as single-case characters in a code that
    is not ascii to displays as complex as one showing weather returns
    from a radar to an air-traffic controller at an FAA air traffic
    control center.
  - Most operators have 4 input devices they can use simultaneously
    to indicate what is to be displayed, or how it is to be displayed,
    or what data is to be selected.  One of these input devices requires
    active-management jointly between MMI and the application code so
    tha the operator can see "the state" of processing rather than having
    to guess, as one does with most graphical display applications.
  - It runs as a losely coupled distributed application in "n" processors
    (where "n" is enough to made the co-ordination non-trivial).
    Data is passed back and forth as Ada typed information, thus
    it is less likely that out-of-range and similar errors will creep in.
  - It uses a MMI (man-machine interface) running in several distributed
    tasks to decouple the user-interface from the procesing logic, so that
    an error in the MMI code should not affect the processing logic.
    The MMI is itself decoupled from the other tasks by a method similar
    to the actions described in the Ada95 distributed systems annex so
    that its activities, if in error, will not adversly affect the
    application code.
  - It uses a "when others => log_it" (a good practice in any environment)
    at the top-level of all tasks, but especially the MMI one, to ensure
    that presentation errors don't take down the system. It then continues
    its receipt and processing of MI requests.
  - If a console "crashes" or goes down due to hardware failures,
    the operator must be able to switch to another console, identify
    him/herself, and get their own display data back "very quickly".

And almost all of this (except for a very small portion close to the
hardware) is written in Ada.

Paul Stachour
[log in to unmask]