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=0.5 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ff5a9c0d829f6632 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-01 06:49:57 PST Path: nntp.gmd.de!newsserver.jvnc.net!yale.edu!spool.mu.edu!howland.reston.ans.net!pipex!uknet!hrc63!gmrc.gecm.com!valiant.gmrc.gecm.com!bill From: bill@valiant.gmrc.gecm.com (R.A.L Williams) Newsgroups: comp.lang.ada Subject: Ada Run-time for embedded systems Date: 1 Mar 1995 14:49:57 GMT Organization: GEC-Marconi Research Centre Message-ID: <3j21il$lrv@miranda.gmrc.gecm.com> NNTP-Posting-Host: valiant.gmrc.gecm.com X-Newsreader: TIN [version 1.2 PL1] Date: 1995-03-01T14:49:57+00:00 List-Id: 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.