Ada and embedded system reconfiguration

Ada and embedded system reconfiguration

[R.A.L Williams]

Recent rumblings in the procurement departments of both DoD and MoD
are indicating that the long term future for military procurement
programmes is in reconfigurable modular systems. (See for example
the reports from the A3P programme, the ASAAC programme, the US Navy
Advanced Avionics Architecture programme etc. etc..... sorry, I don't
have good references to these, can anyone else help?). A related
move is towards the greater adoption of software reuse and COTS
code.

I've been thinking about the practicalities of implementing these
techniques and I have a number of points that I'd like to start
a discussion on.

Now, my understanding of reconfiguration in modular systems goes 
something like this:

A platform has one main computer system which runs ALL (well, nearly
all - safety critical is probably out, but the coffee vending machine
is definitely in) software applications. Normally this approach would 
be regarded as madness, but here's where the clever bit comes in.
The main system is based on a distributed architecture with sufficient
redundancy built in that, in the event of a hardware failure a 
reallocation of tasks to processors can take place and system 
availability is maintained *transparently* to the operators. The cost
benefit of this approach is that instead of taking a platform off-line
to repair a single subsystem, the repair can wait until scheduled
maintenance takes place. The savings in overall life-cycle costs
are thought to be enormous. Naturally, sufficient power and I/O
bandwidth must be provided to make this a feasible design. Note that
this is *not* the same as putting the redundancy into each application,
the so-called 'federated' architecture approach. If you do the
MTBF sums it generally turns out that the modular approach uses
less hardware/power/space/weight than the federal approach.

Let's look at this system architecture from the point of view of the
system integrator and see how Ada implementations may fit in. The system 
integrator has been presented with a collection of software packages, 
mostly from different companies, some of it legacy or COTS code, and 
his task is to make all of these work together on a reconfigurable system.
Now, I can see a number of potential problems, specifically with Ada
code, but I see no reason why many of them wouldn't also occur in
other languages:

1. 'Implementation Defined ...' problems. Given that the system 
integrator can specify a target processor to all the contractors
how compatible are the internal representations generated by different
compilers (don't forget legacy, COTS and reused code) ? If there
are incompatibilities then it seems that the system integrator may
need to specify a compiler as well. What does this do to s/w reuse?

2. The Ada Run-time system structure can cause problems. My experience
of Ada cross compilers is that the code and the run-time are targetted
at a SINGLE application running on a SINGLE processor. The run-time
ties itself in to the interrupt vector table and a whole host of
target specific bits. Now, I suppose that we could write our 'distributed
operating system', which will be necessary to make this reconfiguration
work, to provide each application with a virtual machine. I'm not
sure how efficient this would be and how far-ranging it would need to
be. UNIX, for example, provides a virtual machine for each process, but
that machine has no notion, in general, of 'real-time' or interrupts.
The 80386 CPU, on the other hand, has a virtual machine mode, but that
works by emulating a 'subset' machine. I'm not aware of any systems
where the full architecture of the target is apparently avaialable to
every virtual machine. Does anyone have any idea of the pros and cons
of this?

3. Another way of dealing with the Ada run-time might be to simply
rewrite it. The snag here is that, unless we have mandated a specific
compiler for the platform, we may have to rewrite several. Another
snag, which is not a technical problem, but may be a contractual one
is compiler validation. As I understand it, cross compilers are
validated to run on a specific hardware target with, by implication,
a specific run-time system. Now either of the two approaches to
integrating multiple applications would, it seems to me, invalidate
the compiler. Now, that doesn't stop the system working--but it might
stop the customer paying for it!!

I haven't had a chance (or time!) to play with it yet, but Ada9x
certainly looks like a great improvement on Ada83. In particular the
Systems, Real-time and Distributed programming annexes are a move
in the right direction; but do thay go far enough to support 
reconfiguration, and what will the performance hit be?

Of course, there are no 'magic bullets'. Other languages: C, C++, Eiffel
etc. will all suffer to some degree from the problems outlined above
(except, of course, validation!)

So there we have it:

Are ADA, reconfiguration and software reuse mutuall exclusive? Discuss.


		Bill Williams

-----------------------------------------------------------------------

My employer disclaims any responsibility for my diseased ramblings

Re: Ada and embedded system reconfiguration

[Paul Pukite]

R.A.L Williams  <bill@uk.co.gec-mrc> wrote:
 > Are ADA, reconfiguration and software reuse mutuall exclusive? Discuss.

If your question concerns feasibility: Yes, you can do portable, distributed 
processor reconfiguration using Ada.  If you want first-hand info...

My company did work on the Pave Pillar/AARTS (Ada avionics real-time 
software) program for the US Air Force.  We supplied the Ada expert 
system module for reconfiguring the loadable program units depending on 
mission mode and failures of the clustered processors (we called it the 
RRM -- redundancy and reconfiguration manager).

I developed the RRM module with PC Ada and then cross-compiled directly to 
the 1750A for their testbed. It should also work with the 6800,etc targets.  
So mixing processor types is not considered a real problem. You just 
have to have the binary images available to load on the matching CPU.

(The primary contractors did the main AARTS work and did a commendable
job. You really appreciate Ada and good design when you have to 
integrate with someone else's code.)

We finished the project up in 1992. You can find references to the Pave 
Pillar project (including this) in the NAECON proceedings from that year.

What's the problem with doing it with Ada?  Nothing, as far as I can
tell. You need a commitment, and then you just do it!

--
Paul Pukite (pukite@daina.com)
DAINA Engineering  612/781-7600
4111 Central, Mpls MN 55421-2953