Board index FlightGear Development Canvas

FG approach supporting the ARINC-661 standard

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

FG approach supporting the ARINC-661 standard

Postby georgep » Mon May 17, 2010 11:05 am

Hi,
I would like to ask your opinion about an FG approach supporting the ARINC-661 standard (I am unsure if this forum thread is the right one)

Considering the ARINC-661 standard: (quoted from http://en.wikipedia.org/wiki/ARINC_661)
    • Aims to normalize the definition of a Cockpit Display System (CDS), and the communication between the CDS and User Applications (UA) which manage Aircraft avionics functions.
    • The GUI definition is completely defined in Definition Files (DF) holding graphical widgets definition. The widget library is similar to Widgets used in computing.
    • The CDS software (aka ARINC-661 server) is able to create the GUI specified in the DF during initialization without needing to be recompiled if the GUI definition changes.
    • The UA sends Parameter Commands to the CDS and receives User Events from it.
    • The standard is known today to be used for Airbus A380 and A400M CDS development, and also Boeing 787 CDS development. AgustaWestland company will use ARINC 661 for its future helicopters and it is to be implemented in the upgraded Merlin helicopter for the Royal Navy. etc

For a flight simulator the information contained in the bidirectional data traffic (Parameter Commands to the CDS and receives User Events) according to above would be sufficient to control the simulator.

This approach could also be suitable with a modularized, distributed and parallelized implementation of Flight Gear. The issue would support experiments with simulated modern avionic.
georgep
 
Posts: 27
Joined: Tue Mar 30, 2010 8:45 am
Location: Stockholm

Re: FG approach supporting the ARINC-661 standard

Postby HHS » Mon May 17, 2010 12:44 pm

Hi,

From the Forum Rules:
Core development is discussed on the official FlightGear-Devel development mailing list.


And as only very few core developers follows the forum, you should adress your request better on the devel-list.
So here you go: https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: FG approach supporting the ARINC-661 standard

Postby georgep » Mon May 17, 2010 2:52 pm

HHS wrote:Hi,
And as only very few core developers follows the forum, you should adress your request better on the devel-list.
So here you go: https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Ok, I did it. Thanks!
georgep
 
Posts: 27
Joined: Tue Mar 30, 2010 8:45 am
Location: Stockholm

Re: FG approach supporting the ARINC-661 standard

Postby Hooray » Sat Jun 12, 2010 1:46 am

Hi

It is of course true that these types of questions are better asked on the developers mailing list, but still:

I would like to ask your opinion about an FG approach supporting the ARINC-661 standard


How familiar with ARINC 661 are you?
What type and extent of support for ARINC 661 do you envision?

Are you mostly thinking in terms of an I/O protocol to drive external ARINC 661 displays or also in terms of rendering actual graphics (widgets) using ARINC 661 in FlightGear?

While just adding support for an I/O protocol would be relatively simple (with some customizations to the generic protocol system), making FlightGear itself render actual ARINC 661 widgets in FlightGear would be more complicated because it lacks currently the required infrastructure.

That is largely because even though FlightGear's instrument rendering system is pretty flexible and powerful (i.e. XML configurable), it is still purely based on rendering static textures (taken from files in the base package) that can only be dynamically transformed (scaled, rotated) by setting properties in the property tree but which cannot be dynamically created or be drawn to at runtime.

Other instruments -such as the radar- in FlightGear are currently hard coded in C++ using raw OpenGL calls and cannot be customized dynamically at the moment.

This is a known problem and long standing issue, which is also documented in an article on the FlightGear wiki: http://wiki.flightgear.org/index.php/Fl ... s_Cockpits

So there is currently no infrastructure for placing the primitves required for rendering such 2D widgets, which makes it complicated to implement such things.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: FG approach supporting the ARINC-661 standard

Postby ac001 » Tue Jun 22, 2010 2:42 am

ac001
 
Posts: 51
Joined: Thu Sep 03, 2009 5:09 pm
Location: Wales UK
Callsign: peteffs
Version: 2
OS: Ununtu

Re: FG approach supporting the ARINC-661 standard

Postby Hooray » Fri Jun 25, 2010 12:05 pm

To be honest, I think most FlightGear users here, but probably also most FlightGear developers are not really familiar with ARINC 661 or the benefits it may bring to FG.

So, most people will find it hard to provide feedback about your idea without your providing additional background information.
Just linking to wikipedia is probably not enough, without having a background in software engineering and avionics.

If you are looking for community feedback, you will have to provide a less technical description of ARINC 661 itself, but also explain the benefits of supporting ARINC 661 in FlightGear. For example by illlustrating how ARINC 661 support in FlightGear would be useful.

Personally, I am convinced that ARINC 661 support in FlightGear would be very desirable in the long run.
This is because it would not only allow us to create completely new instrument types in FlightGear easily, but also because it would make FlightGear more interesting for professional applications and users, just by using an existing aviation standard.

But also because there is a real software market for ARINC 661 tools, if FlightGear had native ARINC 661 support built into it, it could be used for many interesting projects, such as for example prototyping avionics or creating proof of concept instruments.

See for example:
http://www.disti.com/Products/glstudio/ ... sA661.html
http://www.xpanelsoftware.com/

These packages are pretty expensive software, so FlightGear support would make FlightGear increasingly relevant for serious avionics engineering projects, simply because there are no free alternatives that I know of.

If FlightGear were to be modified to provide ARINC 661 support, the FlightGear community could also use this industry standard to create realistic glass cockpit type avionics, which would be desirable because FlightGear has pretty restricted support for such types of displays at the moment, especially when compared to MS FSX or X-Plane.

I don't know if you read the FlightGear newsletter, but there is currently some work ongoing about improving FlightGear's support for modeling glass cockpit type aircraft.

This work is largely done by the forum user "zakalawe" who is a FlightGear core developer and whose work was recently mentioned in the FlightGear Newsletter issue of March 2010:
http://wiki.flightgear.org/index.php/Fl ... Map_Dialog
http://wiki.flightgear.org/index.php/Map

Zakalawe is one of the few FlightGear core developers who actually maintains his development plan in public, on the wiki: http://wiki.flightgear.org/index.php/Plan-zakalawe and who participates actively in forum discussions here.

And he also maintains a FlightGear clone at gitorious for his work, so it is really easy to track his progress: http://gitorious.com/~zakalawe

Overall, he really has been very responsive and receptive here on the forums about suggestions, feature requests and questions when we were talking about glass cockpit related topics (just do a forum search for "glass", "FMC" or "FMS", he usually joins such discussions very quickly).

The last time we were talking about this here, we were talking about a way to render to textures using Nasal scripts, so that is somewhat different in scope from what you are proposing now.

Zakalawe is also very actively involved in documenting all the related FlightGear components and creating new documentation on the wiki. So he is most certainly the best person to talk to about your plans, because he is intimately familiar with the work going on at the moment.

You could try to get in touch with him by using the PM facility, to send him a private message. I am sure that he can fill you in on any questions that you may have, and maybe you can even find a way to cooperate.

Speaking realistically, implementing support for drawing ARINC 661 widgets in FlightGear would require work on the C++ source code, including some basic OpenGL knowledge as well as experience with cross platform development.

Familarity with the FlightGear code base (or flight simulation in general) would be an added bonus, as would be familarity with ARINC 661 (or at least access to the specs).

There is a list on the wiki about various glass cockpit projects: http://wiki.flightgear.org/index.php/Gl ... t_Projects

One of these being fggc which is supposed to eventually become a modernized version of the original OpenGC project. So this might be a good place to borrow some OpenGL rendering code if needed.

But the minimum pre-requisite for doing this type of work will be to have a working build system which allows you to build FlightGear from source so that you can clone the gitorious repositories in order to work on a topic branch: http://gitorious.com/fg
This however is much easier on Linux systems than on Windows systems. The necessary steps are however documented in the wiki. And depending on your platform, there may be project files already available for your system.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: FG approach supporting the ARINC-661 standard

Postby georgep » Fri Jun 25, 2010 2:34 pm

Hooray,

Unfortunately I am not confident with 661 with the meaning that I have not programmed applications using 661, neither coded any 661 server in C++.I am also new in Flightgear, my intrest being to prototype and simulate an aircraft model.
If FlightGear had native ARINC 661 support built into it, it could be used for many interesting projects, such as for example prototyping avionics or creating proof of concept instruments.


As you wrote, the FG community needs a list of benefits in supporting 661 in FlightGear. Howerer, I believe in your message you provided an excelent argumentation there I cannot add more - some quotes below.
Hooray wrote:hard to provide feedback about your idea without your providing additional background information.
... have to provide a less technical description of ARINC 661 itself, but also explain the benefits of supporting ARINC 661 in FlightGear
...
ARINC 661 support in FlightGear would be very desirable in the long run.
This is because it would not only allow us to create completely new instrument types in FlightGear easily, but also because it would make FlightGear more interesting for professional applications and users, just by using an existing aviation standard.
But also because there is a real software market for ARINC 661 tools, if FlightGear had native ARINC 661 support built into it, it could be used for many interesting projects, such as for example prototyping avionics or creating proof of concept instruments.

George
georgep
 
Posts: 27
Joined: Tue Mar 30, 2010 8:45 am
Location: Stockholm

Re: FG approach supporting the ARINC-661 standard

Postby Hooray » Fri Jun 25, 2010 4:33 pm

Using FlightGear to prototype and simulate an aircraft should work pretty well.
But honestly, I do think that using it for prototyping and simulating ARINC 661 instruments will need a fair amount of work, because FlightGear really "isn't there" yet.

It really depends on your background and/or time (or manpower) budget.
Someone familiar with the corresponding technologies, will probably not need much longer than say 3-6 rainy weekends to add a basic working prototype to FlightGear, with support for a handful of widgets.

I suppose, not being familiar with the source code is not a major problem if you have experience working with other simulation software and C++ source code. The FlightGear source code is generally pretty well-documented and the source tree layout is pretty much self explanatory, too.

And most questions you may face can be answered easily by talking to other developers or contributors, using either the mailing lists, the forums or the IRC channel. This really is a matter of patience, because sometimes questions will remain unanswered and may need to be brought up again to be noticed by the right people at all.

A lack of OpenGL familiarity can be easily compensated for just by looking at existing hard coded instruments and borrowing OpenGL snippets there.
For such a project, things are significantly simplified because all OpenGL rendering will usually take place in GL_ORTHO mode (i.e. 2D).
For doing more fancy things, looking at OpenGC, fggc or other open source OpenGL avionics projects should provide a good library of useful snippets.

However, having access to the ARINC 661 specs will obviously be required to progress any further.
Without access to the specs, and without C++ programming experience, this would be a major effort with a rather steep learning curve.

FlightGear has pretty good XML support, in fact the majority of configuration files use a subset dialect of standard XML for matching the internal property tree data structure. The XML support is provided by the SimGear library.

While not directly specific to ARINC 661 at the moment, there is clearly strong interest in getting this type of functionality added to FlightGear.

If you are interested in working on this, I would suggest to first set up a build system and see if you manage to build FlightGear and its dependencies from source. This in itself can be a complex and daunting task.

The next step would be to clone the gitorious repository and create a topic branch for working on ARINC 661 support. Once you are able to build FlightGear from source, you could have a look into the $FG_SRC/Instrumentation folder:

http://gitorious.org/fg/flightgear/blob ... ion/README
src/Instrumentation/ - gauge and avionics support code

This directory contains code to support gauges, avionics, and other
instruments in FlightGear. The file instrument_mgr.[ch]xx contains a
subsystem group that holds all of the individual instruments. Every
instrument should extend FGSubsystem, and then should be added to the
group in the FGInstrumentMgr constructor.

Code is gradually moving into here from other areas, especially the
src/Cockpit/ directory. Eventually, there will be an XML
configuration file to select what instrumentation modules should be
available, so that different aircraft can have appropriate support.


As you'll see, most instruments follow the MVC pattern in that the rendering logics are separated from the data providers/sources.

What I would do is to create a new hard coded instrument that interprets and renders ARINC 661 XML files in FlightGear.

To create new instruments, you would derive a new C++ class from SGSubsystem and implement the interface (see the header file).
To see how this is done, you could have a look at some of the less complex instruments, like for example the GSDI instrument which is fairly compact in size.

Any newly created instrument types would then need to be added to the instrument_mgr files, search for example for "gsdi" to see how this is done.

So, adding a simple "dummy instrument" that simply prints "hello world" to the console, would just take 5 minutes.

Once you have recompiled the binary, the new instrument type can be directly instantiated just by referring to it in the instrumentation XML file of your aircraft. To see how this is currently done, please see $FG_ROOT/Aircraft/Generic/generic-instrumentation.xml.

This is also where you can see how the instantiated instruments can be parameterized.

To render to textures using OpenGL calls, you will want to take a look into: http://gitorious.org/fg/flightgear/blob ... _gauge.cxx

Which is the main driver that is used by most hard coded instrument types (agradar, groundradar, wxradar).
You will want to take a look at those instruments to see how exactly they draw dynamically to textures.

So, adding a new "arinc661" instrument type that dynamically draws instruments from XML markup, would not even be all that difficult.
One would only need to start with tiny steps, for example by only supporting a limited subset of widgets in the beginning.


Usually, projects like this one start out with a discussion, an idea and some form of document detailing the development plan - this is where the wiki usually comes in, to structurize the workflow and create a roadmap with milestones.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: FG approach supporting the ARINC-661 standard

Postby georgep » Sat Jun 26, 2010 7:14 am

Hooray wrote:[...]However, having access to the ARINC 661 specs will obviously be required to progress any further.
Without access to the specs, and without C++ programming experience, this would be a major effort with a rather steep learning curve.
[...]
Usually, projects like this one start out with a discussion, an idea and some form of document detailing the development plan - this is where the wiki usually comes in, to structurize the workflow and create a roadmap with milestones.

IMHO having 661 specs is a quite central issue in a possible approach. If I remember well, a CD with the last 661 specs is about $500. Just a matter of money.
https://www.arinc.com/cf/store/documentlist.cfm
Last Print: 05/2010
Price (PAPER): $452.00
Price (PDF): $226.00


The other would finding an opensource 661 server and a "general purpose" client in order to no needing code scratch should made easy to evaluate. I know only one guy who promisses that, but I am not shure about his intended schedule (a couple of years or more?).
He even describes the possible approach to create it here (from 2008!)
http://incanusonrails.blogspot.com/2008 ... cript.html

Talking about my self, I once in time wrote some C++ (actually Java and ordinary C) and my knowledge aboout the FG system is very basic. Hower, it would be exciting to participate supposing it would be possible to delimitate everyones contribution in the project.
georgep
 
Posts: 27
Joined: Tue Mar 30, 2010 8:45 am
Location: Stockholm

Re: FG approach supporting the ARINC-661 standard

Postby Hooray » Sat Jun 26, 2010 12:31 pm

I once in time wrote some C++ (actually Java and ordinary C) and my knowledge aboout the FG system is very basic.

To be honest, in many places in FlightGear's source code, C++ use of more modern/advanced features is still fairly limited.

Much of the source code is pretty much implemented as "C with classes and the STL", this applies in particular to the majority of legacy code.
It is only since pretty recently that the FlightGear source code is being modernized, which is mostly caused by new dependencies like OSG or Boost that make use of more advanced C++ techniques, like for example traits.

And there is also a pretty comprehensive amount of introductory information available on C++ programming here: http://wiki.flightgear.org/index.php/Pr ... _Resources

IMHO having 661 specs is a quite central issue in a possible approach. If I remember well, a CD with the last 661 specs is about $500.


I agree, having access to the full ARINC 661 specs would really be required.
But 500 USD for a CD with specs is quite ... hefty. Especially for a single developer without financial backing from a company to work on this.
Even more so in an open source project, where there is simply no funding available for such purposes.


Without access to the ARINC 661 specs, this would be pretty a giant much reverse engineering effort. Which would still be doable, as long as you have access to software for creating valid ARINC 661 XML files (or a huge set of valid files). Just looking at some of the examples (i.e. wikipedia or from the blog you posted), processing the XML should really not be too difficult at all.

Personally, I would also suggest to refrain from trying to support the binary "Definition Files" in the beginning - and instead concentrate on XML only.
This is because it would be much easier to directly work with XML files, without converting them to the binary equivalent "Definition Files".
Given that these binary "Defintion Files" are compiled from XML files, this should not make any real difference at all, but still simplify the development process.


So the costs might be a real hurdle at this point.
One could try to get in touch with standards@arinc.com and ask them if there are any ways for getting access to important details without having to buy a CD for 500 USD.

But given that ARINC 661 support in FlightGear would enable some companies to save some real bucks, it might also be possible to ask for financial support from such companies or organizations that would benefit from such an enhancement, to help sponsor such an effort.

There is some information on ARINC 661 available here: http://www.presagis.com/files/section_p ... %20v07.pdf

Basically, widgets are based on categories (quoting the PDF file):
  • Container: A widget that can contain other widgets to define hierarchical organization or to provide functionality (e.g. MutuallyExclusiveContainer)
  • Graphical Representation: A widget that draws graphics (e.g. PushButton)
  • Text String: A widget that renders text (e.g. PushButton)
  • Interactive: A widget that reacts to interaction from the user (e.g. PushButton)
  • Map Management: A widget related to the rendering of a map inside of an ARINC 661 display (e.g. MapHorz)
  • Dynamic Motion: A widget that can be repositioned while the display is running (e.g. GpLine)

    As we can see from these examples, a widget can belong to more than one category based on its functionality.

The other would finding an opensource 661 server and a "general purpose" client in order to no needing code scratch should made easy to evaluate.


Yes, I absolutely agree that having access to an open source ARINC 661 server would be perfect for this project, but I am simply not aware of any such projects.
If I am not mistaken, the link to the blog you posted is also not specifically about creating just a server component?

But looking at the blog, the author is apparently part of the ARINC 661 committee, so he might be the best person to talk to in order to get access to some more details for implementing ARINC 661. Maybe just an outdated PDF draft that does not cost 500 USD? :lol:

After all, one would not necessarily need access to the latest version of the specs (ARINC 661-4), a working draft would be sufficient to have something to start with, for prototyping purposes.

If you are still interested in working on this, I would try to get in touch with him and maybe even point him to this discussion, because he seems clearly to be interested in this sort of work, so getting some more feedback would surely be valuable.

Maybe he is even interested in teaming up with us to create a generic set of ARINC 661 server/client components, which could in turn be used by related projects, such as a module that allows ARINC 661 XML DF to be rendered directly in FlightGear?

We would mainly need an ARINC 661 kernel that can be linked to different rendering backends (OpenGL/OSG in the case of FG), so that the CDS could be visualized in FlightGear.

Even if the blog writer should not be specifically interested in contributing to FlightGear, teaming up with any ARINC 661 related projects would make sense in my opinion.

I mean, one could also develop the ARINC 661 server/client framework separately and then only interface it with FlightGear by using some form of IPC to remotely render graphics in fgfs, provided by another process. That would ensure that there are no project specific dependencies introduced (FlightGear, XUL etc), so that different projects could implement the rendering backend separately.

This has actually been discussed here several times already, and there is apparently some interest to add such a feature to FlightGear, so other standalone programs may work like a "plugin" that remotely renders graphics in FlightGear.

It is currently not yet possible to create dynamic instruments outside the fgfs process space, to have them rendered in FlightGear.
So while there is currently no network capable rendering API in place, it should be possible to provide such a facilty once a real need arises.

Imagine a scenario where you 1) connect to a running fgfs process using a socket, 2) create a remote rendering context and 3) then draw primitives by issuing 2D drawing commands via a network connection. FlightGear would then dynamically draw to texture, according to the commands it receives from the other process.

So such an enhancement would make it possible to render instruments without having to modify/recompile FlightGear, pretty much like a standalone plugin system.

I am myself interested in this sort of thing, and we were actually talking about something very similar like this just a couple of months ago: viewtopic.php?f=6&t=7383&p=70236

It would be possible to extend the idea even further and provide a way to allow external programs to draw to textures using a socket connection.
I don't think this would need to be too complex in the beginning:

It its simplest form, you would just expose a "SetPixel(x,y,color)" routine.
More complex drawing primitives (e.g. lines, rectangles, circles) could be added later on.

These would then be directly mapped to their corresponding ARINC 661 equivalents, like:

  • GpLine
  • GpRectangle

So the low level ARINC 661 widgets would need to be mapped to the corresponding OpenGL primitives (GL_POINTS, GL_LINES etc), while the more complex widgets (like e.g. MapHorz), would need to be separately implemented (pretty much like the current Map dialog).

While there are many different ideas now for providing 2D drawing support (XML files, Nasal scripts, SVG support, cairo, network, ARINC 661), the common requirement would really be to first have a 2D drawing API in C++.

If you are still interested in working on this, and once you are able to build FG from source, I can provide additional help and pointers for getting started hacking FlightGear. I could for example send you a patch for a simple generic instrument that can be used for drawing to a texture using OpenGL primitives.

Please let us know if you need help setting up a build environment for building FlightGear from source. Make sure to check out the wiki for additional help.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: FG approach supporting the ARINC-661 standard

Postby georgep » Sat Jun 26, 2010 4:05 pm

Thanks, I only found points in I agree too with in your message e.g:
  • refrain from trying to support the binary "Definition Files" in the beginning - and instead concentrate on XML only.
    try to get in touch with standards@arinc.com and ask them if there are any ways for getting access to important details without having to buy a CD for 500 USD.
  • the author is apparently part of the ARINC 661 committee, so he might be the best person to talk to in order to get access to some more details for implementing ARINC 661. Maybe just an outdated PDF draft that does not cost 500 USD? :lol:
  • try to get in touch with him and maybe even point him to this discussion, because he seems clearly to be interested in this sort of work, so getting some more feedback would surely be valuable. Maybe he is even interested in teaming up with us to create a generic set of ARINC 661 server/client components, which could in turn be used by related projects, such as a module that allows ARINC 661 XML DF to be rendered directly in FlightGear?
  • develop the ARINC 661 server/client framework separately and then only interface it with FlightGear... different projects could implement the rendering backend separately.
  • render instruments without having to modify/recompile FlightGear, pretty much like a standalone plugin system.

If you are still interested in working on this, and once you are able to build FG from source, I can provide additional help and pointers for getting started hacking FlightGear. I could for example send you a patch for a simple generic instrument that can be used for drawing to a texture using OpenGL primitives.
Please let us know if you need help setting up a build environment for building FlightGear from source. Make sure to check out the wiki for additional help.

Thank you for the points in learning fg! I also read the presagis syntesis about 661 benefits.
I propose discuss that directly to avoid boring others with off topics about me. In the matter of necessary reading/learning about fg, among other things I miss a picture or presentation, if existent, for fg architecture.
georgep
 
Posts: 27
Joined: Tue Mar 30, 2010 8:45 am
Location: Stockholm

Re: FG approach supporting the ARINC-661 standard

Postby mithrandir3 » Sat Jul 24, 2010 11:34 am

Don't know if it can help, but I have currently developed an ARINC 661 Server in Java (pretty feature complete, and with a good performance, even in full Java). However, it is still not open sourced yet, because even if I mostly developed it in my own time, I had access to ARINC 661 resources given by my employer (the standard itself, and the fact that I'm participating in the committee on behalf of my employer). It should be open sourced now in a relatively short time (but you know how companies are cautious with these matters). If I can help with pointers on how the standard work, no problem.

Also, I'm currently writing a series of tutorials on how it works on one of my blogs here: http://incanusonrails.blogspot.com/. I have also setup a project on java.net to propose a formal model of the standard, I think this also could help, even if now a little outdated: https://arinc661form.dev.java.net/

And yes the binary file format does not add any functionality. It is just designed to be used in real-time safety-critical environments without using any XML parsing at loading. But even if you use XML Definition Files, you only have to parse them once when you load (Design time). After that (Runtime), you only have to understand the communication protocol.
mithrandir3
 
Posts: 5
Joined: Sat Jul 24, 2010 11:22 am
Location: Paris

Re: FG approach supporting the ARINC-661 standard

Postby Hooray » Tue Jul 27, 2010 6:48 am

Hi mithrandir3 !

Sorry for not getting back to you earlier.
Thank you for joining our discussions about ARINC 661, it's really interesting and sounds very promising that you have already a Java implementation of an ARINC 661 server. I really hope that you will be able to release it as open source software.

I was talking to GeorgeP, and he is also considering to use Java for his project - assuming that some form of IPC such as network sockets is used to "talk" to FlightGear, that should really not be a problem at all. There is already a number of Java based applications that are related to FlightGear. Also, Java seems ideally suited for this because it directly satisfies the cross platform requirement. I think there are also various examples for accessing the FlightGear property tree network interface from java in the FlightGear source tree.

We already mentioned your blog and the ARINC 661 tutorials it contains, it is already very useful for planning an ARINC 661 component for FlightGear.
This is particularly so because it is so hard to get access to the specs for actually starting the work. So your materials, expertise and experience are really valuable!

Do you have any specific ideas for interfacing an ARINC 661 servers like yours with a flight simulator?
What do you think about the idea of using a flight simulator for prototyping and simulation ARINC 661 component?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: FG approach supporting the ARINC-661 standard

Postby mithrandir3 » Tue Aug 24, 2010 1:53 pm

Hello Hooray,

I'm sorry too for my late answer, but I was on holidays in Japan until yesterday, and I did not think about logging then ;)

As for the way to be able to communicate to an ARINC 661 Server, the standard does not mandate anything else than having a stream of bytes available from Client to Server and another one from Server to Client. What is standardized is what should be encoded in these streams.

As for the Server I wrote in Java (which - I hope - will soon be Open Sourced), it uses by default a simple TCP or UDP sockets communication (one port for Client to Server, another for the other Server to Client), but it's easy to configure it through an XML configuration file to be able to use more than one port for each direction. For example it can be useful if more than one Client can communicate with the Server, even at the same time, so no particular precautions have to be used on the Client side. It also provide an API which can be based upon to create plugins for managing other communication protocols, or other ways to use TCP or UDP, as long as it still sends or receive packets of bytes.

Additionally, I know that there is a lot more in the standard than what I have discussed on my tutorials. I plan to to explain Client / Server communications more in another tutorial, but if you need informations on other parts of the standard, I can answer here, on my blog, or on the https://arinc661form.dev.java.net/ project. BTW, if you have ideas of ARINC 661 tutorial subjects that could help you, don't hesitate to ask.
mithrandir3
 
Posts: 5
Joined: Sat Jul 24, 2010 11:22 am
Location: Paris

Re: FG approach supporting the ARINC-661 standard

Postby flak » Tue Aug 24, 2010 4:23 pm

Some guy built a simulator using a Arinc -429 interface:

http://www.youtube.com/watch?v=-1pI8bIOxYA
flak
 
Posts: 76
Joined: Mon Feb 22, 2010 5:20 pm
Callsign: Anant
Version: Git
OS: Windows 7

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests