Howto:Systems Modeling

This article or section contains out-of-date information Please help improve this article by updating it. There may be additional information on the talk page.

This article is a stub. You can help the wiki by expanding it.

Hi all, this is just to let you know that I am currently experimenting with gnucap integration into FlightGear. Gnucap is the Gnu Circuit Analysis Package, much like (p)spice or it's derivates. Unlike spice, it's GPL'ed and should give the ability to perform detailed and exact electrical circuit analyses to simulate the electrical system. There is nothing to present so far, but first tests are very promising. My goal is to integrate gnucap in a way, that nodes are presented as properties and in that way accessible from FlightGear. The electrical system will be presented to gnucap as a netlist, so even complex circuits may be processed. http://www.gnucap.org http://www.gnu.org/software/gnucap/ Greetings, Torsten — Torsten Dreyer

The old Electrical System

Issues & Limitations

• The current electrical system is "data driven" rather than hardcoded, but it was designed before nasal existed in FG.
• Electrical systems can vary widely from airplane to airplane. It makes sense to have a few representative examples, but for accurately modeling the particular system on a particular aircraft, you are really going to have to dig in and do some work.
• The current electrical system model has some serious problems due to short sighted design and the designer (me) not fully understanding the problem I was trying to solve. This week I've been taking the Microsoft "big hammer" approach of trying to beat something of dubious quality and poor design into something that actually works and is useful ... using overwhelming force. I'm ready to give up and trash the whole subsystem.
• 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.
• The system can't handle things like battery charging without introducing horrible hacks.
• The system can't do things like balance loads between two alternators, again without horrible hacks.
• Try extracting the information you need to accurately drive an ammeter gauge from the current system ... we will need even more horrible hacks. :-(
• 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.
• 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 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.

Sophisticated Systems Simulations

Here are some ideas about modeling electrical systems that are general enough to handle most airplanes. The base object will probably need to keep a list of suppliers and another list of users. If the state of any component changes it will then be resposible for notifying all of its users. The alternative method, by which every user would check its power supply at every sim-cycle seems wastefull, especially when you have 300+ users. AC components can have any number of suppliers, but generally only use one at a time. DC components can use all their suppliers at the same time. Here are some objects to be derived from the base object: 1) CSD (constant speed drive), which exists between an engine and its generator. The CSD has one supplier, the engine, and one user, a generator. The CSD's function is to spin the generator at a set speed regardless of engine rpm. CSD parameters to monitor are Oil Quantity, Oil Temperature going in from the cooler, and Oil Temperature going out to the cooler. The measure of the CSD's health is the oil temperature Rise (out - in). The CSD has a cockpit switch which can physically disconnect it from the engine in order to protect the engine. The switch is for emergency use only, as once it is used the CSD clutch can only be engaged by a mechanic. 2) Battery, nominally 28 Volt, which will last about 30 minutes if it is the only power source available. It is normally supplied by the battery charger, so if the charger is powered the battery is transparent. 3) Ground Power, supplies 115 Volt, 400 cycle AC power to a "Ground Power Bus". This is plugged into the side of the airplane, and is either there or it isn't. A light in the cockpit advises if its there. 4) APU (auxilliary power unit), which could be derived from a turbine object, but I think that would be a waste. It supplies 115V/400Hz electrics, and usually supplies pneumatics as well. It has a Start/On/Off switch in the cockpit, and an EGT gauge. It burns fuel from one of the airplanes main tanks. 5) EPU, similar to an APU except that it only works (automatically) when regular electrical sources fail. The F-16 EPU has its own hydrazine fuel supply. I don't know if EPU's can supply hydraulics as well. 6) Generator, which supplies 115V/400Hz power to a bus. Supplier is a CSD. You could model the APU generator as an independent object using the APU as a supplier, or you could incorporate the APU generator into the APU model. Generators generally have two switches. The field switch turns the generator on/off. The breaker switch connects/disconnects the generator from its bus. 7) RAT (ram air turbine), like the EPU it usually comes on atomatically, although it can also be activated by a cockpit switch. The RAT falls down into the airstream and supplies 155V/400Hz power. In some airplanes it also supplies hydraulics, or only hydraulics. 8) HPG (hydraulic powered generator) uses a hydraulic motor to spin a generator. This is purely a backup source, used for ETOPS certification, and comes on automatically. 9) Bus, a simple component which only keeps a list of suppliers and a list of users. AC or DC. 10) TR (transformer/rectifier) converts AC to DC. Supplier is one of the AC buses. User is one of the DC buses. 11) Static Inverter converts DC to AC. Used by the battery bus to supply the Standby AC bus. In the event the battery is the only source operating, the Standby AC bus is the only source of AC power. Only essential users are on this bus. 12) Battery charger, supplied by an AC bus (with a backup AC bus also), user is the battery and everything the battery powers. I'll soon draw up a diagram of a typical Boeing electrical system and send it to whoever wants it. Dave Culp — Dave Culp

Favoring Nasal

The current electrical system model was developed before Nasal showed up on the scene. Nasal is a very attractive option for developing aircraft specific subsystem models.

Please see the c172p (our reference aircraft), which is a really interesting/practical example of how nasal can be used to add significantly complex aircraft specific functionality to FlightGear without touching the C++ code base.

Depreceating the old System

We should not use the current system any more to develop new electrical system models. We can leave it in the code base for a while so we don't break existing aircraft designs, but in retrospect it's kind of an embarrassment so eventually it should go. I propose that people needing to develop aircraft specific electrical systems now use a nasal based approach.

The xml based electrical system model is in the process of being abandoned. It's there for backwards compatibility only. I wrote it and realized later that it just didn't have enough capabilities to model anything much beyond a simple single engine aircraft electrical system. It didn't have the capability of correctly driving the panel gauges, properly handling multiple power generation sources (at least for some aircraft) and there were other problems I encountered when I tried to impliment a realistic light-twin engine electrical system.

Nasal advantages

So I decided to abandon the xml based system and recommend that people craft a nasal based electrical system for their aircraft. Electrical systems are very aircraft specific and can often change drastically between serial number ranges of a particular aircraft. Also, the level of detail that a person might want to model can vary dramatically depending on the project and the time.

So I think a nasal based system gives us much more flexibility, and the ability to achieve correct behavior with as much detail as desired. The old xml based data-driven system was extremely tedious to define where as a procedural nasal based system isn't any harder to create.

The original electric system model has some horrible limitations that make it difficult to model electrical systems that are more advanced than what you would find on a C172. In addition, it's really difficult to use this system to accurately drive volt and ammeter type gauges. The underlying circuit modeling just can't handle it.

So *really*, people should be moving away from this old, depricated xml based electrical system model and instead, code up exactly what they need in nasal. The nasal approach is a lot more straight forward, much more flexible, more concise.

It's different though and I figured it would talk folks a little while to adapt to the new system, which is why we didn't just immediately yank the old code.

Long term, every one is going to be a lot better off if they code up their electrical systems in nasal. The c172 should have an example implementation that should be much easier to follow and understand than the xml based example.

In general, Nasal really isn't a bad approach. Many/most of the systems that are common among aircraft are modeled already in the FlightGear code, but things like gear failure and the specific failure modes, system dependencies, work arounds, procedures, etc. can get really aircraft specific. This is where Nasal is really slick. It's very small/tight, and amazingly capable for it's size. It gives you a high degree of programmability, and can be setup so it is specific to your aircraft.

For example, I'm working on a light twin project and one thing I've done recently is to model all the annunciators (similar to the dash board lights in your car.) I'm not aware of any FG airplanes that have annunciators modeled, but these are common in aircraft. We can do them quite easily, but I don't think any aircraft designers have looked into these yet.

For my project I have a couple nasal routines that compute some values derived from the existing properties. With nasal I can test the state of various FG properties, then set a fault/warning condition. In nasal, I can even blink the light for the first 10 seconds. I write the resulting properties into a separate subtree in the global property tree. Finally I created a custom gauge that is driven from these properties.

One thing I've found is that so many of our subsystem have so much configurability and power, you have to stop and think about the best place to impliment something. For instance I wanted a gear horn that would sound when you cut the throttle but the gear is still up. This can be done entirely in the sound configuration file with conditionals (which speaks a lot for the power of the audio subsystem.) Later though I decided I also wanted an annunciator light to give a visual warning of this same condition, so I moved the logic into a nasal routine. That way a single piece of code could drive both the audio and visual warnings rather than replicating the logic in multiple places.

The combination of nasal and configurable systems (with xml conditionals) give us an amazingly powerful system for modeling aircraft and systems. The more I work with these, the more impressed I am.