Ada Run-time for embedded systems

[bill@valiant (R.A.L Williams)]

In article <INFO-ADA%95012709113992@VM1.NODAK.EDU> Marin David Condic wrote:

: "R.A.L Williams" <BILL@VALIANT.BITNET> writes:
: >
: >Does anyone know anything about running multiple applications on
: >a single embedded processor or, more to the point, N applications
: >on M processors, where N > M and, if a processor fails, several
: >of the applications may get moved around.
: >
: I worked on a project very much like this called ICNIA when I was
: with Singer Electronics in New Jersey. TRW was the prime. This
: was a radio that was designed to run "radio applications"
: (Narrowband, TCAS, JTIDS, etc...) across multiple processors and
: be able to reconfigure itself in the event of hardware failures.

Yes, we did some work on ICNIA-like systems some years ago, only we
were concentrating on the problems of the radio front-end and the
subsequent signal processing.

: The only way we could make it work at the time (and I don't know
: that anything has changed) was to have a "custom operating
: system" which executed "applications" written in JOVIAL. (We were
: planning to migrate to Ada as soon as we could get a good
: compiler or the government quit believing that excuse.) I don't
: think there was any easy way of mapping this sort of thing to Ada
: tasks - we had to get right down to the bits and bytes of
: operating system writing in order to get the behavior we wanted.

Yes, I was coming to the same conclusion myself. The catch with Ada
is, of course, that for the compiler to be validated, the vendor has
to specify the target and operating system. If I cobble together my
own system, come to that, if I cobble together my own hardware, I
no longer have a validated compiler. Now, you and I understand the
practical limits within which this is acceptable, but can we convince
a pen-pusher (sorry, QA engineer/contract administrator :-)?

: >Assuming that the applications are COTS (Commercial Off The Shelf)
: >programs, as may increasingly become the case, what happens about
: >the Ada run-time? COTS software will probably be supplied by
: >multiple independent vendors, so I can't make the usual assumption
: >that 'application' = 'task' and then rely on the tasking system
: >to solve my problems. Basically, I'm assuming that COTS applications
: >will be non-cooperative.
: >
: I've never heard of COTS software applications for embedded
: computers. What exactly are you trying to do? Run Windows NT on a
: missile navigation system? ;-) Seriously, a little more info on
: what you're trying to do might help suggest a solution.

No, don't forget that if equipment vendors sell sensors, for example,
to a system integrator, they will probably be asked to supply support
software. You get a driver with the super-whizzy VGA card on your
PC don't you? I forsee (== have been told to work on the assumption that..)
avionics systems, both civil and military, will be going this way in future.

As to what I'm trying to do: the questions I'm asking are aimed at a
medium term research project to evolve 'modular avionics' solutions
for future products. So, at the moment I'm not actually trying to do
anything, I'm just trying to evaluate what problems I'm going to face
in the future.

It seems to me that the way to get 'modular anything' to work is by
imposing standards. Standards for interfaces between hardware modules,
standards for interface between software modules. The Ada run-time is
just (an important) one of those interfaces. If an operating system is
going to be an enabling technology for the modular approach then we
need to get a standard for that if possible. It's all very well to
say 'POSIX' and assume that everything's alright, but POSIX isn't
actually an operating system, its mostly a set of API's and a list
of utility programs/commands. 

I'm hoping that, by starting the debate now we, in the industry, may
know which way to go when development/production contracts start to
come out. At the moment, this is still research (ASAAC, A3P, EUCLID).


Thanks for your feedback Marin.

Bill Williams