#29 performance database/prediction

open
nobody
5
2012-10-31
2006-03-11
Anonymous
No

hi, for an upcoming university project I would like to
add autoflight/fms functionality to a flightgear aircraft.
Two essential features for this project would be a
working implementation of the VNAV SPD/PTH and LNAV modes.
However, in real life the flight management computer
uses a performance database that contains tables
describing the aircrafts performance in various
situations (configuration,weight,fuel,altitude,winds etc)
Without such data it is practically impossible to be
able to predict whether the aircraft can accomplish
certain waypoints/restrictions. Particularly the VNAV
PATH and SPEED modes are quite tricky without any such
data. So, I was wondering if there is any way to have
JsbSim sort of predict the performance it can provide
to the simulator.
Thanks

Discussion

  • Logged In: NO

    this sounds interesting but not very feasible or even
    possible with the current code base, however if you know
    what sort of data you require you could possibly try to use
    a jsbsim instance in standalone mode in order to create the
    corresponding tables from "virtual flight tests" in certain
    flight regimes using the same flight data model, you could
    then serialize the data to XML and read it into Flightgear
    for various situations and try to look up the values in
    order to interpolate/extrapolate missing data.
    However, in order to come up with the corresponding data you
    would probably really have to use jsbsim in an automated
    fashion, so that you literally execute dozens of scripted
    test flights to come up with the performance tables,
    otherwise your data will be far too vague.
    In this regard it would be interesting whether anybody knows
    of sources for an average test flight, that is what sort of
    maneuvers are flown and what data is derived from these
    tests (and how?).

    Concerning support for direct runtime calculations of a
    performance database, I am not even sure what this would
    entail for the jsbsim side of things. I guess, one would
    have to provide some sort of backwards-solver with an API to
    be able to poll the FDM for aircraft performance that's
    possible in certain regimes?

     
  • Logged In: NO

    interestingly, the EuroControl data is freely available for
    research projects and similar efforts (theoretically you
    could even base a completely new FDM on it!), however its
    license is incompatible with the GPL-so it wouldn't be
    really viable to use(release) the BADA data with FlightGear
    or JSBsim.
    But basically all this stuff should be possible with a
    working FDM model, so that you can do the full trajectory
    prediction using tables filled with data that was gained by
    running scripted test flights (or possibly even based on
    data that's dynamically obtained while running the
    simulator, so that each session dynamically augments the
    perf database for the corresponding aircraft IF FDM config&
    engine config are identical).

    Initially, you'd mainly be interested in "reaction times"
    for different maneuvers (climb/descent,
    accelerate/decelerate, leveling off, turning), then you'd
    want to couple this data for different situations (speeds
    (IAS/TAS),weight/balance, aircraft configuration
    (flaps/slats,speedbrakes, gear,SE vs. ME), weather
    (temperature&humidity).

    However, this sort of data would probably not really be
    suited to be stored in XML format: in order to be able to
    interpolate between such sets of data, you'll want to be
    able to query a real database, that is something like SQLite
    would come in extremely handy, as you would then merely have
    to query the different tables for data using data from other
    tables as primary key, so that only relevant data will be
    returned from the database:

    GWT -> IAS -> ALTITUDE -> OAT -> W&B -> PITCH -> ROLL -> YAW
    -> WINDS etc

    much of the data that isn't applicable in the corresponding
    context could be simply omitted, so that the db would only
    return relevant data for dynamically building the proper tables.

     
  • Logged In: NO

    While I do not know for sure, I do not think that the
    performance database in itself is such a complicated beast,
    I mean the Boeing 744 AOM does not really mention much about
    the FMC databases (nav&perf), however what it says it that
    the performance database includes drag/engine coefficients
    for various aircraft configurations.

    Also, I seem to recall that the perf database itself is
    relatively small (just several kb), so it certainly doesn't
    contain lots of flight test tables, but rather only a very
    limited subset of the data required to mathematically come
    up with an sufficient approximation, however personally I
    would be at a complete loss as to how to make sense of such
    figures in the context of FMC operations, I mean the process
    would have to work something like this:

    1) get next waypoint and optional wpt constraint from FMC
    2) pass the wpt/constraint to the solver

    3) have the solver query the performance db to determine if
    the waypoint/constraint can be made or not
    4) if it can be made: determine required steps to make the
    waypoint (i.e. increase or decrease IAS/VFPS/ROLL, request
    drag -and so on)

    the tricky part is #3&#4, I do not think this can be
    implemented without having at least a degree in maths or
    preferably using someone's help who's done sth. like this
    before.

     
  • Logged In: NO

    at least for the flightgear side of things, you won't want to have this implemented purely for one particular FDM engine, as there are other (possibly even proprietary) FDM engines in use with FG, thus I think it would be prudent to consider a more abstract high level implementation WITHIN FG, which only makes use of a very well defined set of hooks to actually provide said capability within the scope of the simulator, otherwise I'm sure that you would inevitably see most modern FMS/glass cockpit aircraft being exclusively implemented using the only FDM engine that provides this data.

    also, a cooperative effort (i.e. with the yasim developer) would encourage a truly modular implementation with an emphasis on commonalities between the various supported FDM engines.

    Michael

     
  • Logged In: NO

    ed2k://|file|EuroControl%20Commercial%20Aircraft%20Performance%20Summaries%20-%20performance.pdf|179407|B8B236ACC03745B603EDF9140BF94EFF|/

     
  • Jon S. Berndt
    Jon S. Berndt
    2008-01-07

    Logged In: YES
    user_id=144031
    Originator: NO

    I've seen the use of simple simulation within a simulation, where performance data is being calculated. It was not within JSBSim, however. This is an interesting prospect. Nobody has ever done this, up to now. My initial reaction was pessimistic. However, the flight control components within JSBSim are fairly capable, and you are permitted to define arbitrary functions. So, my guess at this time is, yes, you should be able to set up JSBSim to calculate some performance data. It may be a lot of work, but it should be possible.

    Jon

     
  • Logged In: NO

    this is exactly the sort of stuff that is clearly suitable to help opensource projects setting themselves apart from proprietary solutions and the underlying facility (performance db) would also be required to implement FMS support in Flightgear.

     
  • Logged In: NO

    not sure whether this really requires the use of simulation within simulation, given that other flight simulators (and real aircraft, too) simply use tables of flight data to come up with probable performance capabilities.

     
  • Logged In: NO

    well, this might make for an interesting google summer of code project for 2008, possibly under the umbrella of flightgear, assuming that flightgear is indeed going to become a registered GSoC project as recently suggested on the fg-devel mailing list. This could work like the KDE project, where related projects and dependencies are automatically eligible to make project suggestions under the umbrella of the KDE project. Thus, jsbsim being basically a FG dependency could also send in suggestions for new projects.
    As previously discussed, this sounds like a rather revolutionary feature and having it in flightgear would undoubtedly improve those parts in the simulator that try to simulate airliners and modern jet/glass cockpit aircraft.

     
  • at least for the flightgear side of things, you won't want to have this
    implemented purely for one particular FDM engine, as there are other
    (possibly even proprietary) FDM engines in use with FG, thus I think it
    would be prudent to consider a more abstract high level implementation
    WITHIN FG [...]

    then, how about an API/hook in FG FDMs that allows the FDM to be sort of "queried" for performance data, where the FDM would internally decide if it can "solve". So, let's say you pass the current aircraft state (weight & balace, speeds, direction, orientation) to the API call, which in turn responds with an array of tables with dynamically created flight test data, so that these tables could then be used to see if a certain constraint can be made, by looking up the parameters for the current situation.

    vnav scenario:
    "flying in the 737-300 at 15000 ft, at 250 ktias, 30 nm inbound on the 0100 SFO radial to land on 28R"
    constraints:
    fly at max 250 ktias below 10.000 FT
    pass 16.1 nm DME fix (SFO) at 4100 ft (or above)
    pass 12 nm DME fix (SFO) at 3200 ft (or above)
    pass 7.4 nm DME fix (SFO) at 1800 ft (or above)

    so there would be several constraint types (altitude, airspeed, time) and the solver would look up possibilities by querying the table and see what's necessary to make a certain constraint

     
  • in VNAV mode, flying the aircraft ist actually mostly about making a certain constraint, which can be defined as a GRADIENT (wikipedia).
    So, the fmc has to determine the gradient (i.e. loss of altitude over a certain distance above ground) between two waypoints and see if it can make them with current config (vertical speed and speed over ground). If it can't make the gradient, groundspeed and/or vertical speed have to be changed, possibly even by adding drag (like the gear or flaps, this is something the AFS cannot do on its own but instead it tells the crew "drag required").

    So far this is much more trivial than it's been discussed here so far.
    However, difficulty comes into the play once the flight management system has to know how long it takes to accelerate/decelerate groundspeed and vertical speed, that is the MOMENTUM of a mass having a certain direction and speed in 3D space. And yes this would indeed be something that's best obtained from flight test data or dynamically created tables.

    Still it's not rocket science, the most relevant parameters to use for the lookup operation would be known by the FDM, namely:
    weight & balance, groundspeed, power settings, aircraft config, vertical speed, air density, temperature

    So it would mostly come down to having the FDM provide all this data (for a certain configurable flight enevelope, of say 1-700 kts,1-500 metric tons, 1-30.000 ft, 0-105% power et cetera) in some sort of 2D graph structure.

     
  • This could be useful:

    "The FMS contains computation resources, input and output processing resources, and access to a
    navigation database and, for more sophisticated ones, access to the aircraft performance database.
    A typical navigation database contains a regional or worldwide library of ground-based NAVAID ('s),
    waypoints, airports and runways, and en-route airways as well as company routes.
    The performance database is generated using the aircraft’s performance and flight manuals. It
    provides data for time and fuel consumption computations based on weight, altitude and speed, as
    well as data for take-off and landing speeds computations based on weight, runway length and
    altitude, flaps and slats position, and obstacle height and distance." (http://www.intentproject.org/deliverables/INTENT_D3-1_v04_22-05-03_P.pdf)

    http://www.ae.gatech.edu/people/jpclarke/cda/workshop2/presentations/Miller.pdf
    http://www.aero-pack.de/aviation/BOEING737/B737NG-Flight_Management_and_Navigation.pdf

     
  • Hi, I know this thread is almost 4 years old, but you might find the following file useful which contains lots of details (including formulas) on computing vnav/lnav performance data:
    http://www.davi.ws/avionics/TheAvionicsHandbook_Cap_15.pdf

    It seems, the data that would be required to implement this for jsbsim is readily available

     
  • FWIW, 8 yrs ago FlightGear core developer David Luff also suggested the use of a "lookup table" API for getting only a subset of relevant values from a running FDM instance without updating the FDM at full 120 hz.

    In that case, specifically for providing AI aircraft with realistic in-flight behavior, where only certain data would be required, but where it would still be desirable to simulate an AI aircraft by using a real FDM:

    http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08690.html

     
  • There is a related document from NASA AMES RESEARCH:

    EDA Trajectory Prediction Process
    4D trajectory predictions form the cornerstone of
    CTAS/EDA. Trajectory predictions are generated based
    on aircraft state, flight-path intent, aircraft-performance
    models, and predicted atmospheric state (winds and
    temperatures aloft). The initial position, velocity and
    altitude of each flight are estimated from the best source
    available (flight plan, radar track, or data link). The
    flight-path intent is defined as a series of waypoints
    defining the path to the destination. This intent is based
    on the aircraft’s current state, flight plan, local Air-
    Traffic-Control (ATC) procedures, and CTAS heuristics
    that relate the aircraft’s current state to the flight plan
    and local procedures. The local procedures are defined
    in a CTAS navigation database in terms of altitude,
    airspeed, and course restrictions. Special functions and
    a controller-friendly graphical user interface ensure that
    EDA predictions are consistent with controller intent.
    CTAS trajectories are synthesized in two steps. First, a
    horizontal track is generated by connecting the
    waypoints with a series of straight-line and circular turn
    segments. As for an FMS, waypoints are modeled as
    either "fly-by" or "fly-over" according to local airspace
    adaptation data. The turn segments are based on a
    parameterized bank angle and an estimated average
    ground-speed for the turn. This ground-speed is based
    on an airspeed profile and a wind estimate along a
    simple kinematic altitude profile. The airspeed profile
    is either inferred from a combination of the flight plan,
    controller input, radar tracking, and the CTAS database,
    or dynamically selected by EDA for flow-rateconformance
    advisories. Second, the altitude and time
    profiles are computed by integrating a set of simplified
    point-mass equations of motion along the established
    ground track. A detailed set of aircraft-performance
    models are used to define the thrust, drag, and speed
    envelope for each aircraft type. The atmosphere is
    modeled with a 3D grid of wind, temperature, and
    pressure [5]. A detailed description of the CTAS
    trajectory-synthesis process is presented in [6].

    http://www.atmseminar.org/seminarContent/seminar3/papers/p_084_AGOADM.pdf

     
  • Hi

    I am affiliated with a UAV project where we would need a capability to compute an emergency descent path to reach a safe landing site. While this project is not related to flight gear or glass cockpits, having an interface to compute performance numbers would be very useful from our point of view:

    The idea would be sort of run a solver in reverse mode, where we enter data that we know (mass, energy, drag, lift, density, OAT etc) and in turn get the maximum range of the aircraft from a fdm simulation.

    • Mirco