Advanced Question Integrated Modular Avionics / Flight Computer: Emulate or Simulate?

[Istochnikov]

Hi:

I come to you for asking something that you can sound interesting, difficult or strange:

Like you know, i stopped (at least partially) the development of add-ons (mainly modelling) for learning C++, F90 and LUA for giving a plus for them (you know, cameras, flight instruments, analysers...).

Now the question is: I want to step-up another level. And i decided to do it with an IMA ([ame="http://en.wikipedia.org/wiki/Integrated_Modular_Avionics"]Integrated Modular Avionics[/ame]) / Flight computer system, based on one of three candidates:

1. Motorola 68000 Series (a 16/32 bits processor)
2. Texas Instruments OMAP (32 bits System-on-a-Chip based on an ARM 32 Cortex 8 processor)
3. A custom-made CPU with i'm learning Computer Architecture: the CPUCR Mark 2 (a very simple 8 bits processor)

The purpouse of the IMA/FC is control all the systems of the spaceship independently of the kind (Airplanes, Satellites, Rockets and Manned Spacecraft).

The question is: Is possible create an embedded-DLL that emulates this system? Is a good idea emulate it? or is better simulate it?

I'll put the block diagrams of the IMA-FC.

 

[Urwumpe]

The question is: Is possible create an embedded-DLL that emulates this system? Is a good idea emulate it? or is better simulate it?

Both would be easily possible.

 

[Hielor]

The question is: Is possible create an embedded-DLL that emulates this system?

Yes.

Is a good idea emulate it? or is better simulate it?

Depends upon what you're wanting to get out of the project.

Are you wanting to learn about the intricacies of embedded systems architecture and hardware emulation, and don't care if the project ever actually gets finished? Go with emulation.

Are you wanting to ever actually release an addon anytime in the next six years? Go with simulation.

 

[Urwumpe]

Are you wanting to ever actually release an addon anytime in the next six years? Go with simulation.

I wouldn't be that pessimistic there. If you don't need to produce your own tool chain for the emulator (compilers!) you can be done pretty quickly.

If you need to produce special tools, things slow down slightly.

I would say you can produce a full emulator of a CISC processor alone in about 60 workdays. Including stuff like :hail: esoteric floating point formats.

If you just have around 2 hours every day for coding Orbiter, this means 240 days, almost a year, plus friction by needing to get mentally into coding it.

If you only work on the weekend on it, I would say a year is possible.

 

[Istochnikov]

I have to say that i have the complete CPUCR Mark 2 processor writen in Verilog. This can be a HUGE saving of time (i only need translate the Verilog description to C++ ). Only a question: Are 8 bits enough for emulating the management of spacecraft like Cygnus PCM, the MAKS-OS Shuttle, the Taurus 2 Rocket or even aircraft like Airbus A330?

 

[Urwumpe]

Below 16 bit, you don't even need to ask. :lol:

Some projects still use the MIL-STD-1750A processor.

http://en.wikipedia.org/wiki/MIL-STD-1750A

 

[Istochnikov]

A little review of Motorola's 68000 Programmer's Reference Manual (+630 pags!!!) and ARM Architecture Reference Manual (+1100 pags!!!) made me reconsider the idea of emulating a flight computer...

I'm not saying that i'll abandon the project, but, i'll do the two things. As i want to release add-ons featuring an IMA/EFIS/Flight computer, i should simulate instead to emulate a computer. In fact, this could ease the job, because, writing a program and emulate it (and emulate all the relative stuff. Though i can imaginate this on my head, i need a little more of knowledge -a reject result from my interview at Intel showed me this- for developing an entire computing system at binary level).

The thing i'm thinking about is to develope a simulated modular computer. It has to do:

FOR ROCKETS

• Provide a controlled guidance, following first a preloaded approach on its first phases of the flight and after booster/first stage separation, follow a PEG autopilot.
• Provide a VC using a "simulated control room" (easy to do even in spacecraft 3), With only providing you a "rocketcam view" when you are on the VC
• Failures and self destruction system (or a RSO commanded destruction)
• Simulating Inertial Measuring System: On the VC i can see the path followed by the rocket AND the predetermined path

FOR SATELLITES

• Autopiloting capabilities, for example, for a fly-by probe: When the body of interest approaches, the probe automatically orients their cameras and sensors
• For spacecraft with more than a camera: Autocycling: i want to say: if my probe has 3 cameras: a narrow angle cam, a Wide Angle Cam and, let's say a color cam and a pseudo infrared cam; the probe can take 4 pictures automatically and in a cyclic pattern -WAC, NAC, Color, IR-.
• For Comsats. Automatic Pointing to earth a-la Kulch's SkylinkSat
• For Probes again. Automatic Antennae pointing to earth and solar panels to sun.
• Capability for using low thrust engines (ion) and maintaining a fixed attitude
• The "Control Room" VC
• Failures: For example, an engine blow up (CoNTour, Telstar 401, Mars Observer), Malfunctioning Cameras (noise), Solar Panels that fail to deploy completely...
• Simulated Magnetometers and Soil Analysers (Brian Jones had developed some tech for the Fobos-Grunt Project, but this project now is inactive -by my fault i have to say).
• If the spacecraft is a unmanned capsule (Cygnus PCM, MAKS-OS Unmanned Version, Modified HOTOL, others): Capability for automatic rendezvous with target.
• IMU and GPS Implementation

FOR MANNED SPACECRAFT

• Life Support Systems... A little a-la Dragonfly, A little a-la DG-IV
• The Obvious UMMU/UGGO support
• Controlable Human Machine Interface on VC (something like your SSU, but without the excesive complication... I mean to say, "a Clickable VC version of DG-IV and XR-2 panels" mixed with the realistic programation/interface of AGC and Dragonfly
• Simple Payload Management (I think i can use the Kulch's URMS for this... )
• In case of Minishuttles: Autolanding Capability (For unmanned ones is a must, For manned, is a plus )
• Floating Astronauts!!!
• Failures: Similar to Comsats, Failures to Life Support Systems, Cabin Depresurization
• IMU and GPS

FOR AIRPLANES

• Some features form the manned spacecraft
• Accurate aerodynamics model
• UMMU/UCGO Support -It doesn't matter that a 777 has only 40 passengers, it's orbiter, not a real airline
• Autopilot: Going to the A point to the B point without moving a finger
• IMU and GPS
• Some airplanes had an EFIS merged the Analogic Interfase (Example: Yak 42, Boeing 737-Classic) it's possible?
• Failures: Cabin depressurization, engine fires and explosions...

Some requeriments to simulate one thing could be useful in the others, only i want to know that what feasible could be either simulating or emulating these features on Orbiter

Thanks in advance

 

[Urwumpe]

What about producing a Lua based VM? Essentially your own small Lua run time, independent of Orbiters, that has a special set of API functions for the tasks you plan.

Or maybe even two specialized VMs, that can exchange data, one optimized for autopilot duties, the other for display duties.

 

[Istochnikov]

What about producing a Lua based VM? Essentially your own small Lua run time, independent of Orbiters, that has a special set of API functions for the tasks you plan.

Or maybe even two specialized VMs, that can exchange data, one optimized for autopilot duties, the other for display duties.

HMMM!!! And how can i eat that?... It seems that i have to read a good LUA book...

 

[Keatah]

Aren't there 68000 emu cores freely available? I know for certain there are z80 and 6502 cores for free. What about the ones used from the M.A.M.E. arcade emulator?

I think, imho, you might be best off with simulation, because with emulation you will need to have real avionics code for whatever it is you're emulation.

Or just build your own simulation of whatever it is and don't even worry about a 68xxx or whatever core.

 

[Istochnikov]

Aren't there 68000 emu cores freely available? I know for certain there are z80 and 6502 cores for free. What about the ones used from the M.A.M.E. arcade emulator?

I think, imho, you might be best off with simulation, because with emulation you will need to have real avionics code for whatever it is you're emulation.

Or just build your own simulation of whatever it is and don't even worry about a 68xxx or whatever core.

Well, a painful course of computer architecture made me change my mind, like you could have read some posts ago... the reasons, like you said, are very strong.

My question now resides on Urwumpe's proposal of two interlinked LUA virtual machines nested on the IMA/EFIS module. Though i find interesting the proposal, i don't know (yet) how to implement this

 

[Urwumpe]

I could maybe also soon offer you another alternative... because I became pretty unhappy of the performance of Lua in vector and matrix operations, I started developing a special Virtual Machine for GNC and system management. It is currently just programmed by hex magic during testing and further improving it, the long-distance goal is to have a Ada compiler for this VM.

It is based on SIMD instructions, you can apply most arithmetic operations on up to 16 registers at a time, matrix multiplication up to 4x4 is built-in. Also most instructions are of the form A <= B + C. A VLIW extension of the instruction set is kept open, but makes no good sense as long as it is just a VM... it could just accelerate a few calculations by telling the VM in advance about the intents of the next instructions.

This VM is part of the "Black Dart Forever" project, so you can expect a long wait until you can download a demo of it (at least until I have overcome my perfectionism there), but the hello world phase was already passed.

For the two Lua VMs: Just open two Lua_States* and define a way that suits your concept for exchanging data between them. Every VM gets its own set of C extension functions for its task.