A standard CDU framework for FlightGear

From FlightGear wiki
Revision as of 12:57, 3 February 2012 by Scotth1 (talk | contribs)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
  • Last updated: 01/2012
  • Contributors:


Introduction

As of 01/2012, we are unfortunately approaching a situation where we are having too many different CDU implementations with little (or none) reuse and sharing of existing code - at the moment, there are least 4-5 different projects:


All of them implemented in Nasal. Now, what we really need is someone to examine all versions and see if/how they could be combined, unified and eventually integrated, so that we end up with a single version that is well understood, can be well documented and well-maintained, usable by all aircraft developers, catering for all different needs.

There's a fair share of common features required for pretty much any CDU/MCDU, especially these SHARED low level requirements are largely identical among these FMS front ends.

For example, this includes instantiating an addressable "screen region" and providing hooks to write alphanumeric text to it, as well as dealing with events, i.e. for key handling.

So, ideally, we could come up with a layered design where generic CDU components could be identified to allow people instantiating and parametrizing CDU-related components. Nasal's OOP support is powerful enough to allow people to override such features easily.

Aircraft specific differences are best addressed by parametrization during CDU-instantiation, rather than by duplicating redundant code.


In real-life, there are only like 3 different FMS/FMC/CDU implementations for airliners:

  • Thales
  • Honeywell
  • Smiths Industries (now GE Aviation)

And the same units from one manufacturer are often used in different aircraft (eg: A320, MD-11, 757 and 767 all use the same Honeywell FMS). The majority of the database format is covered by an ARINC standard.

For smaller aircraft (like biz-jets, turboprops and military trainers) one also has to consider other manufacturers like:

  • Barco
  • Esterline
  • Universal Avionics Systems


It is OK to have different initial implementations, all the versions we have at the moment have different ways of implementing different functionality. We could say this is exploring the problem-space.

But we are getting closer to building up a set of requirements that could be built into a common set of instruments and functions...

We are thinking of one "framework" of sorts for connecting a 3D model of the CDU to the property tree, and another framework for it's internal software, both with provisions for customising.

There are two distinct streams:

  • the first is the physical representation of a keypad, screen etc, this is either the traditional LED grid screen, some specialised function keys and general letter/number keypad, the second type of physical representation is the newer LCD monitor type, such as used on 787 and A380 and a few others. This includes page flow, text management and key management.
  • The second stream is the back-end processes of the FMS, calculating flight plans, lateral/vertical guidance and interfacing with the route manager and autopilot.

Well, even if you were to find 100 different manufacturers of CDUs, FMCs and FMS there'd still be a great deal of shared functionality and shared requirements, i.e. things that would be identical among ALL implementations, such as addressing a 2D screen region, rendering formatted text at certain coordinates, responding to key events, querying a navigational datatbase, making certain geospatial calculations.

So, yes, the idea is to come up with a list of these shared requirements and find the greatest common denominator for each component so that a set of layered frameworks can be created, to enable users to reuse code as much as possible, while still being able to customize and parametrize functionality as required.

Some things are currently not yet possible/feasible to do from scripting space (i.e. they require new scripting hooks) , but there are many things that are quite possible already and which should eventually be standardized, i.e. by coming up with a dedicated Nasal module that handles all details and which can be reused by aircraft developers easily.

We need to come up with our own module by getting all people to communicate their requirements, so that the existing designs can be reviewed and improved eventually. This is more complex work than coming up with some workaround from scratch, but it's more worthwhile in the long run.

In many aspects, FlightGear follows implicitly the MVC pattern already - simply because of the property tree, which already causes a separation of concerns to a certain degree.

Architecture

Provided below are some design option architectures. This is completely a wishlist on my behalf and very very draft. FGMCDUOverview.png

Page Definition Markup

The Markup (XML based) for the page definition should encapsulate both the layout of page components, and the flow of actions. Pages can retrieve property values and call nasal functions.

 <?xml version="1.0"?>
 <page>
 <title>Page Title</title>
 <body>
   <group>
     <group style="valign:left; width:50%">
       <row>
         <text style="valign: left; size: 12pt; colour: red">Literal Text</text>
       </row>
       <row>
         <text style="size: 12pt; colour: green">${/instrumentation/flightdirector/myproperty}</text>
         <text style="size: 12pt; colour: red">#{NasalModule.nasalObject.function()</text>
       </row>
     </group>
     <group style="valign: right; width: 50%">
       <row>
         <text style="valign: left; size: 12pt; colour: #1169C0">Destination:</text>
         <input value="${/instrumentation/flightdirector/dest-airport}" style="colour: green; width: 150px"/>
       </row>
     </group>
     <group style="halign: bottom">
       <row>
         <button style="valign: left; background-colour: #E0E0E0" action="NasalModule.nasalObject.function()">Lookup</button>
         <button style="valign: right; background-texture: Aircraft/MyAircraft/Tetxtures/button-texture.png" action="page2">Next Page</button>
       <row>
     </group>
   </group>
 </body>
 </page>


Components

References