Ada Run-time for embedded systems

Ada Run-time for embedded systems

[R.A.L Williams]

I've posted articles along these lines several times before but
perhaps someone will bite this time...

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.

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.

Need there be a separate copy for each application or does anyone 
know of any commercially available compilers that support multiple, 
semi-independent applications with a single instance of the run-time?

If there are multiple copies, how do I cope with the links into
hardware that most existing run-times seem to require on embedded
systems? (Running a copy of the OS/360 VM environment is probably
not an option :-)

Any comments out there? 

Bill Williams

Re: Ada Run-time for embedded systems

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Ada Run-time for embedded systems
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



"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.

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.

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

Pax,
Marin

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "There is no reason anyone would want a computer in their home."

        --  Ken Olson, president, chairman and founder of Digital
            Equipment Corp., 1977.
===============================================================================

Re: Ada Run-time for embedded systems

[Theodore E. Dennison]

bill@valiant (R.A.L Williams) wrote:
>
> I've posted articles along these lines several times before but
> perhaps someone will bite this time...
> 
> 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.
> 
> Assuming that the applications are COTS (Commercial Off The Shelf)
..
> 
> Any comments out there? 

Yeah; "Yuuuuuck!"

I have done something similar running under VMS, but not embedded.

You have an EMBEDDED system running several COTS applications at once?
May God have mercy on your soul...


T.E.D.

Re: Ada Run-time for embedded systems

[Garlington KE]

CONDIC@PSAVAX.PWFL.COM wrote:
: 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.

Actually, there's a lot of COTS being used in embedded systems these days;
it's just that "embedded" means more than those weaselly little processors
used in avionics like ICNIA (or like I still use today :). For example,
C3I workstations are often called "embedded" systems since they are part of
a larger system. Many of these environments use extensive COTS databases,
display managers, etc.

BTW, even the Ada version of ICNIA uses a custom OS, although things have
improved somewhat since the JOVIAL days...

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

Ada Run-time for embedded systems

[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

Re: Ada Run-time for embedded systems

[Robert I. Eachus]

In article <3h2rg8INNhhp@RA.DEPT.CS.YALE.EDU> griest-tom@cs.yale.edu (Tom Griest) writes:

   (I said:) 

  >>   Get real.  For example, both the J-STARS and AWACS aircraft have
  >>workstations as part of the "embedded" radar systems in aircraft.

  > This statement is not completely accurate.  I cannot speak for AWACS,
  > but I do know something about JSTARS.  JSTARS has a "Radar Subsystem".
  > It is separate and distinct from the Operations and Control (O&C)
  > Subsystem which contains the workstations.  There are no workstations
  > in the Radar Subsystem.

    They are an embedded part of the radar system, but not the radar
subsystem.  Fine, so much for hairsplitting.

  > Clearly there is no "law" that states that an embedded system cannot
  > have a display, or even a workstation interface.  The evolution of
  > the technology is such that it is now becoming common practice to
  > "bolt on" front-end workstations on many systems.  The question is:
  > "should these be considered part of the embedded system, or just a
  > computer that communicates with an embedded system?"  The traditional
  > idea of an embedded computer is one in which the computer is dedicated
  > to IMPLEMENTING the functions of some non-data processing system.

    The dividing line IS clear, but not from the outside.  If the
characteristics of the workstation affect the SYSTEM design, and
analysis of the system behavior include the behavior of the
workstation, then the workstation is a part of the system.  If any
workstation acceptable to its user will do, then it is not part of the
system.  I've worked on both types.

  > There probably is no "clean" definition of what an embedded computer
  > is.  Maybe the technology has made the term obsolete.  When your
  > TV's set-top box will be able to plot your stock investments as well
  > as change the channel from a remote "clicker" command, will
  > it be an embedded computer or a general processor?

    A computer can be both an embedded computer and a general purpose
processor.  In many embedded systems the "spare" capacity of a
real-time embedded computer is made available at lower priority for
miscellaneous tasks.

 > Maybe we can expand the definition of "embedded" to all computers
 > and then using the rationale that Ada was designed for "embedded"
 > computers, we can expand its market to all computers!  :-)

   Not quite, but more and more general purpose computer systems are
really embedded computers in disguise.  For example, many workstations
are also an integral part of a corporate network.  (And many aren't.
If the network goes down or is seriously impaired if a particular
computer malfunctions, then that computer is an embedded part of the
network.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada Run-time for embedded systems

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
:    Of course this gives a whole new meaning to "safety-critical
: real-time applications."  Proving to the customers satisfaction that a
: glitch in the LAN won't launch ordinance is only part of the
: problem--you have to prove also that it won't prevent the launch when
: needed.  For anti-missile weapons, both are safety critical as well as
: mission critical.

Interesting. In most of the projects I've worked, the latter case would
not be considered "safety-critical" as the ability to respond against a 
threat is groundruled out of the definition. However, a denial of service
situation would be considered security-critical...

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

Re: Ada Run-time for embedded systems

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Ada Run-time for embedded systems
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



"Theodore E. Dennison" <dennison@ESCMAIL.MMC.ORL.COM> Writes:
>
>l107353@cliffy.lfwc.lockheed.com (Garlington KE) wrote:
>>
>> Actually, there's a lot of COTS being used in embedded systems these days;
>> it's just that "embedded" means more than those weaselly little processors
>> used in avionics like ICNIA (or like I still use today :). For example,
>> C3I workstations are often called "embedded" systems since they are part of
>> a larger system. Many of these environments use extensive COTS databases,
>> display managers, etc.
>>
>Gimme a break!
>
>Show me someone who refers to a workstation setup as an "embedded
>system" and I'll show you someone who is trying to pad his resume'.
>
I have to agree. While one might easily call a workstation based
application "realtime" it's hard to imagine it as being
"embedded". If you define "embedded" losely enough, you could
call a payroll application on an IBM mainframe a "realtime",
"embedded" system. After all, it's "embedded" in a factory system
which semi-automatically takes raw materials in at one end of the
building and squirts out widgets from the other end. And it
happens in "realtime" because paydays happen on the 1st and 15th.
And they're "hard" deadlines in that missing them could result in
a riot which would destroy the widget producing platform...

I don't know how y'all would like to define what an "embedded"
system is, but I'd say that if it has a screen, QWERTY keyboard
and a mouse, we're _probably_ not talking about one.

Pax,
Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "I have traveled the length and breadth of this country and talked
    with the best people, and I can assure you that data processing is
    a fad that won't last out the year."

        --  The editor in charge of business books for Prentice
            Hall, 1957.
===============================================================================

Re: Ada Run-time for embedded systems

[Garlington KE]

CONDIC@PSAVAX.PWFL.COM wrote:

: I don't know how y'all would like to define what an "embedded"
: system is, but I'd say that if it has a screen, QWERTY keyboard
: and a mouse, we're _probably_ not talking about one.

"Probably" is right! The Automated Target Handoff System in the AFTI/F-16
aircraft has a screen (head-down display), an alpha-numeric keyboard (for
sending messages to the target designator on the ground), and a mouse (a
cursor slew on the stick). A user interface is _not_ a determinant of
"embedded." Furthermore, "Embedded" and "Real-time" have nothing to do with
each other.

: Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
: M/S 731-93                                      Technet:    796.8997
: Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
: P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
: West Palm Beach, FL 33410-9600

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

Re: Ada Run-time for embedded systems

[Chris Warack <sys mgr>]

In article <INFO-ADA%95020710124203@VM1.NODAK.EDU>, CONDIC@PSAVAX.PWFL.COM writes:
|> From: Marin David Condic, 407.796.8997, M/S 731-93
|> Subject: Re: Ada Run-time for embedded systems
|> Original_To:  PROFS%"SMTP@PWAGPDB"
|> Original_cc:  CONDIC
|> 
|> 
|> 
|> "Theodore E. Dennison" <dennison@ESCMAIL.MMC.ORL.COM> Writes:
|> >
|> >l107353@cliffy.lfwc.lockheed.com (Garlington KE) wrote:
|> >>
|> >> Actually, there's a lot of COTS being used in embedded systems these days;
|> >> it's just that "embedded" means more than those weaselly little processors
|> >> used in avionics like ICNIA (or like I still use today :). For example,
|> >> C3I workstations are often called "embedded" systems since they are part of
|> >> a larger system. Many of these environments use extensive COTS databases,
|> >> display managers, etc.
|> >>
|> >Gimme a break!
|> >
|> >Show me someone who refers to a workstation setup as an "embedded
|> >system" and I'll show you someone who is trying to pad his resume'.
|> >
|> I have to agree. While one might easily call a workstation based
|> application "realtime" it's hard to imagine it as being
|> "embedded". If you define "embedded" losely enough, you could
|> call a payroll application on an IBM mainframe a "realtime",
|> "embedded" system. After all, it's "embedded" in a factory system
|> which semi-automatically takes raw materials in at one end of the
|> building and squirts out widgets from the other end. And it
|> happens in "realtime" because paydays happen on the 1st and 15th.
|> And they're "hard" deadlines in that missing them could result in
|> a riot which would destroy the widget producing platform...

That's true, but embedded isn't defined that loosely.  According to
DoD, that's a data processing system.

An embedded system is a critical part of a weapon system (at least from
the DoD perspective).  For example:

You have several large satellite tracking antennas attached to a room full
of receivers, demuxes, and decommutators, attached to a network of work
stations (with or without keyboards and monitors) attached to a communications
processor attached to a dedicated network.  Hanging off the work stations is
another network of user stations based on a work station with two or three
monitors, keyboard, keypad, and pointing device.  The sole purpose of all of
this stuff is to control some satellites and process the data they collect.

That, is an embedded system...  albeit a very big one.

The only reason the main processing work stations have keyboards and monitors
is diagnostics, on-machine control, and maintenance.  It's easier that way.

The reason to use work stations is obvious ----- cost.

|> I don't know how y'all would like to define what an "embedded"
|> system is, but I'd say that if it has a screen, QWERTY keyboard
|> and a mouse, we're _probably_ not talking about one.

But you might be... :-)  Also think Air Traffic Control, submarines, and 
ships as well as satellite ground stations.

I doubt you can argue for a clear, black and white distinction between
embedded and non-embedded.  In USAF, anyways, it seems pretty easy.  If
it's general purpose or data processing (does IM or DP stuff), then its
not embedded.  In the rest of the world, I don't think it'd be that easy.

-- 
Christopher A. Warack, Capt, USAF
Computer Science Department, US Air Force Academy

cwarack@kirk.usafa.af.mil                (719) 472-2401

Re: Ada Run-time for embedded systems

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Ada Run-time for embedded systems
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



Garlington KE <l107353@CLIFFY.LFWC.LOCKHEED.COM> Writes:
>
>: I don't know how y'all would like to define what an "embedded"
>: system is, but I'd say that if it has a screen, QWERTY keyboard
>: and a mouse, we're _probably_ not talking about one.
>
>"Probably" is right! The Automated Target Handoff System in the AFTI/F-16
>aircraft has a screen (head-down display), an alpha-numeric keyboard (for
>sending messages to the target designator on the ground), and a mouse (a
>cursor slew on the stick). A user interface is _not_ a determinant of
>"embedded." Furthermore, "Embedded" and "Real-time" have nothing to do with
>each other.
>
O.K. I *did* include the "Probably" proviso for a good reason -
there's always exceptions.

I've worked on avionics which have had CRT displays for the pilot
and buttons which they could push to get behavior from the
system - I'd still call that "embedded" even though it
technically speaking has a screen and a keyboard. I think you're
missing my point:

Plugging a Sun/Unix workstation into an aircraft via a 1553 bus
does not seem to me to constitute an "embedded" system - even
though, as you observe, it might very well be considered a
"realtime" system.

I think my point was to observe that the word "embedded" and the
word "realtime" tend to get abused rather badly and this can
confuse the discussion - especially as it related to the original
theme of COTS on "embedded" machines. I'd still like to ask if
anyone has an effective definition of either term such that it
can exclude from the discussion IBM mainframe payroll programs.
(Of course, there are always us obstinate Philidelphia Lawyers
who'd argue the point just to be arguing something! ;-)

I personally think some of the attributes of an "embedded
computer" probably (and note my equivocation - PROBABLY) ought to
include the following:

    * It is physically contained within a machine or device.

    * The purpose of the machine or device is something other
      than computing.

    * The computer controls or influences or monitors the
      behavior of the machine or device.

    * The computer is dedicated to and specifically designed for the
      control/influence/monitoring of the machine or device.

    * The computer's software is dedicated to and specifically
      designed for the control/influence/monitoring of the
      machine or device.

    * Both the computer and it's software are optimized for their
      designed task. (Id est, neither contains stuff which isn't
      related to the task, except by accident.)

I don't know if anyone else would consider this list sufficient
or accurate, but if you'd accept these points as significant, it
makes it difficult to talk about IBM-PClones running MS-DOS being
"embedded" computers. It also reduces - if not eliminates - the
possibility of COTS being installed on an "embedded" machine.

Pax,
Marin

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "There are like two kinds of jobs: One is called 'Jobs,' which is
    for jobs that suck, and the other kind is called 'Careers,' which
    also suck, but for longer."

        --  Beavis & Butt-Head
===============================================================================

Re: Ada Run-time for embedded systems

[Robert I. Eachus]

In article <INFO-ADA%95020912464180@VM1.NODAK.EDU> CONDIC@PSAVAX.PWFL.COM writes:

  > Plugging a Sun/Unix workstation into an aircraft via a 1553 bus
  > does not seem to me to constitute an "embedded" system - even
  > though, as you observe, it might very well be considered a
  > "realtime" system...

  > I think my point was to observe that the word "embedded" and the
  > word "realtime" tend to get abused rather badly and this can
  > confuse the discussion - especially as it related to the original
  > theme of COTS on "embedded" machines. I'd still like to ask if
  > anyone has an effective definition of either term such that it
  > can exclude from the discussion IBM mainframe payroll programs.
  > (Of course, there are always us obstinate Philidelphia Lawyers
  > who'd argue the point just to be arguing something! ;-)

    I'd have to go back to the early eighties to get the "official"
definition of embedded computer, but the way I usually think of it is,
if the computer can be used to directly point a weapon, or a radar, or
another type of sensor, it is embedded.

    Of course, recent developments in the area of controlling
astronomical telescopes via the Internet are starting to blur even
that line.  (Similarly, SCIS, which only passes messages should
probably be thought of as an embedded communications system.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada Run-time for embedded systems

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
:     I'd have to go back to the early eighties to get the "official"
: definition of embedded computer, but the way I usually think of it is,
: if the computer can be used to directly point a weapon, or a radar, or
: another type of sensor, it is embedded.

I think this might exclude a lot of airborne systems like: HUDs, flight
controls, sensor fusion processors, etc... 

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

Ada Run-time for embedded systems

[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.

Re: Ada Run-time for embedded systems

[Garlington KE]

R.A.L Williams (bill@valiant.gmrc.gecm.com) wrote:
: 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.

Dynamic reconfiguration of this type sounds good in theory, and was studied
in some of the pre-F22 avionics trades, but it turns out there are a lot
of "gotchas" in terms of additional bus structures, software complexity,
etc. 

The other issue is, in what context are we using the word "reliability"? If
you mean mission reliability, then given current technology, in a lot of
cases redundant hardware isn't needed. If we are talking about safety-critical
systems, then other factors such as reconfiguration time start to be a problem.

: The catch is that to take advantage of this technique you have to:
: 1. make reconfiguration actually work

Not just work, but in practice it usually has to work deterministicly. It
ain't easy in the general case.

: 2. integrate the sw from a number of different boxes into a single system
: hence my further points...

You have to do this in an integrated architecture, whether dynamic
reconfiguration is used or not. This is happening today.

: : 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.

The OS (and the hardware) establish partitions in which each application
runs. A system-wide table is built and fed into the OS which describes how
to treat each partition with respect to priority, etc. Each application
(and the OS) is a seaprate load image.

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

The CIP avionics uses the ICC compiler. We don;t know if Ada95 will be
supported yet for our use.

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