> > 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
- 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
- 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.
[log in to unmask]