> > > > 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]