From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2952cd2eee81a211,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-01 07:22:17 PST Path: nntp.gmd.de!Germany.EU.net!wizard.pn.com!satisfied.elf.com!news.mathworks.com!udel!gatech!howland.reston.ans.net!news.sprintlink.net!pipex!uknet!hrc63!gmrc.gecm.com!valiant!bill From: bill@valiant (R.A.L Williams) Newsgroups: comp.lang.ada Subject: Ada Run-time for embedded systems Date: 1 Feb 1995 15:22:17 GMT Organization: GEC-Marconi Research Centre Message-ID: <3go8v9$k97@miranda.gmrc.gecm.com> NNTP-Posting-Host: valiant.gmrc.gecm.com X-Newsreader: TIN [version 1.2 PL1] Date: 1995-02-01T15:22:17+00:00 List-Id: In article Marin David Condic wrote: : "R.A.L Williams" 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