Ada Run-time for embedded systems

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

In article <3iftrp$nik@butch.lmsc.lockheed.com> you wrote:
: R.A.L Williams (bill@valiant) wrote:
[snip]
: : A federated architecture is where a collection of intelligent sensors
: : and displays are coordinated by a central computer system (or
: : possibly not!).

: : A modular architecture is where 'relatively dumb' sensors and
: : displays have most of their processing performed by a central computer
: : system.

: I think I mentioned this before, but in the USAF avionics studies leading up
: to the F-22 aircraft (as well as the F-22 aircraft itself), "modular" and
: "federated" were not defined as shown above.

: A federated architecture means that each functional area has its own
: processing "black box." The flight controls might have one black box,
: the navigation system another, and so forth. Sensors and displays could be
: smart or dumb in this architecture.

Yes, this was what I had in mind but you've expressed it rather better.

: A modular architecture uses common, standardized processing elements (hardware
: and software) that are _not_ built for a single functional area. The flight
: controls, for example, could use the same type of module as the stores control. 
: Processing here could be either "centralized" or "distributed" (and in fact
: is often the latter). Again, sensors and displays could be smart or dumb,
: just that there would be an effort to use the standard modules in all
: systems.

OK, but you can extend this concept to gain a further reduction in life-cycle
costs and an increase in reliability. If you consider *all* the processing
functions of the platform to be resident in a single distributed system,
and allow `reconfiguration' across that system then the total number of
redundant units needed to achieve a reliability goal can be reduced. Imagine,
for example, that you calculate you need 60% redundant units of a particular
processor module, but the boxes in your federated architecture have only
two processor cards each, then you need to add two more cards, ie. 100% 
redundant units. OTOH, if you move all the processing to a larger system 
with 10 of that type of card, you can add 6 cards and achieve exactly the 
additional redundancy you need.

The catch is that to take advantage of this technique you have to:
1. make reconfiguration actually work
2. integrate the sw from a number of different boxes into a single system
hence my further points...
 
: : I believe the following changes will have to occur in 'embedded' 
: : applications:

: : (a) Systems must be written to cope with a combination of hot standby
: : techniques and reconfiguration techniques.
: : (b) Techniques for distributed applications will come to the fore.
: : The potential for reconfiguration means that IPC will be the primary
: : communication technique. Moreover, IPC routes will need to 'follow'
: : the applications.
: : (c) Systems will need to support 'multi-processing' as well as
: : 'multi-tasking'. Individual CPU's will need to be able to run several
: : *independent* applications, presumably in their own virtual machines.

: : I'd like to pose a few questions:

: : 1. Do we need to write an operating system to manage reconfiguration
: : etc. or do we rely on Ada run-time support (Annexes C, D and E of the
: : LRM) to provide the needed intercommunication?

: With Ada83, you have to build your own. With Ada95, there will probably still
: be some "custom" features required.

Yes, I'm pretty sure you're right.

: : 2. If we provide an operating system (in my view, we must) what's the
: : split between that and the Ada run-time? At one extreme we have the
: : current 'native' compilers where the Ada run-time has practically no
: : access to hardware, at the other we have current 'cross' compilers
: : where the run-time expects full and exclusive access to hardware.
: : What is the correct tradeoff between portability and efficiency?

: For us, the OS is built on top of the run-time and takes advantage of it.
: Note that our cross-compilers do not expect to have full and exclusive
: access to hardware, although there are constraints.

So how would I achieve my desired aim of multiple independent applications
on a single CPU? If I just merge two applications together, as two tasks
for example, then I've got a single application and I've made the task
of certification that much hardware because of the additional complexity
of the single application.

BTW, which cross compiler(s) are you using? Is there a prospect of Ada95
from the vendor?

: : 3. What happens about validation? As I understand it at present the
: : validation covers a specific compiler generating code to run on a 
: : specific model (or range of models) of target with a specific operating
: : system (or lack of). Presumably if there is a 'standard' embedded
: : reconfigurable operating system this will be easier, at the expense
: : of enduring a camel-like o/s.

: We don't believe a custom OS, the way we implement it, affects validation.
: We don not re-validate with our custom OS. Our customer has no problem with
: this.

OK, with your approach the OS is part of *your* application, not part of
the compiler target platform. I guess I need to think of a way of making
my 'ideal' architecture working with this technique.

: --------------------------------------------------------------------
: Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
: F-22 Computer Resources         Lockheed Fort Worth Co.

: If LFWC or the F-22 program has any opinions, they aren't telling me.

Bill Williams
GEC-Marconi Research Centre.