From: "Ampere K. Hardraade" <[EMAIL PROTECTED]>
> Why should the electrical system be made generic?

It shouldn't.  There is a whole class of physical systems that
act as a network with two valued paths.  Voltage/Current,
Pressure/Velocity, Density/Massflow, some aerodynamics, etc etc.

All of these systems need to be solved as a network in order
to capture interactions, without hard coding solution paths.

> All these system are basically different forms of moving something 
> from point A, through medium B, to point C.

The problem with that approach is that you have to allow for
(a) the amount of thing being used at B varying when C turns off,
(b) sometimes, stuff can be flowing from C to A and to B, etc.

> implementation can be as simple as *b = &a; (in C's terms).

I don't think so ...
one of the reasons I gave up on FGFS as a failure modelling
simulation for training purposes is that the various buses
do not manage combinatorial failures and side effects right.
You can hard code the stuff, but it may not cover all cases.

From: "Curtis L. Olson" <[EMAIL PROTECTED]>
> 3a. The system is very complex with a lot of subtle interactions and 
> side effects.  It's unclear for someone new coming into the project 
> exactly how it works and what you have to do to build a successful 
> electrical system model.

I think the most important thing is to capture the network that drives
the interactions for the general case, so we have confidence that the
model will be correct for any situation, and then leave it to a 
dedicated "solver" to infer what the decision tree is at any time.

> 4a. What we really need is someone who actually understands all this 
> stuff to build a better data driven electrical system model using a 
> better, more flexible approach.  I am told that SPICE is a good example 
> of doing this right, but I'm a computer scientist with very little EE 
> knowledge or ability.  Circuits strike fear into my heart.

If the developers want to do it using a circuit solver, which I think
is probably the right way to go, I'd be happy to provide an object
oriented definition of what we need to have in the property tree.

Separately to that, I can write up what the circuit solver has to do.
It isn't particularly complicated, providing you're not trying to 
cover all the things that can happen to semiconductors/transistors
when designing logic chips that run reliably at gigahertz speeds.
It's that high end stuff that makes a SPICE codebase complicated.

> 4b. An alternate approach would be to write a "procedural" electrical 
> system model for each specific aircraft using nasal.  But is there a way 
> to have  a "default" nasal function that can be overwritten by an 
> aircraft specific function?  I am almost favoring the nasal approach 
> here for many of these aircraft specific subsystems.

I don't have an opinion about this, having not used nasal seriously.
Can it be used to write a modular solver that propagates both ways?

> I realize this expands the discussion rather than focussing it, but I'm 
> getting really frustrated with the inabilities of the current electrical 
> system to do things like model battery charging (without trying to 
> charge itself and other goofy things), model ammeter gauges (i.e. 
> measure current flow between two different points in the "network"), do 
> load balancing between multiple alternators and a host of more complex 
> things.  I like the idea of a v2.0 electrical system that is similar to 
> the current system, but designed by someone who knows what the 
> H-E-double toothpicks they are doing (obviously not me.)  But in the 
> mean time, nasal would be a quick and dirty approach to getting a fairly 
> functional electrical system up and running pretty quickly.

A final thought that might help y'all decide what to do ...

As I see it, the _most_ important thing is to ensure that the method
used to describe how the model works will be understandable to aircraft
mechanics who have no programming experience.  Those are the people who
really know what the electrical system wiring looks like and what has
to be added into a model.  If they cannot read the computer parsable
description in the aircraft file, they will be unable to find mistakes.

Now: _if_ you decide that this should be the driving consideration 
and there are no technical obstacles that inherently for the decision
for us, please build two versions of the same electrical system and
I'll collaborate with the FAA to get the local avionics shops to let
us know which they can understand better.  They should be interested
in supporting us because it's in their interests to have a good
training tool.  Both their techs (who can look through our files) and
for their pilot customers (who persist in operating stuff wrongly).

I suggest the C172 electrical system, with _all_ switches, breakers,
interior lights, and all avionics loading their respective bus.
C172s have a really simple system; fits on a single sheet of paper.
It's a handy test case before trying to do the 747 or similar.

Flightgear-devel mailing list

Reply via email to