Board index FlightGear Development Aircraft Flight dynamics model

Encrypted aircraft dynamics

Good sims require good FDMs (the "thing" that makes an aircraft behave like an aircraft).

Encrypted aircraft dynamics

Postby Soitanen » Thu Aug 28, 2014 2:22 pm

Hi!

I have proprietary dataset for one aircraft. It's possible to create the most realistic dynamics in JSBSim, but due to license restriction I don't want to show original values and tables used for FDM. Is it possible to create encrypted .xml file, that will be included in main JSBSim file like:
Code: Select all
<system file="aerodata"/>
But will be opened on simulator loading to use?
Boeing 737-300. Reworked cockpit, FDM, autopilot and much more. WIP.
Boeing 737-800. WIP. Canvas PFD and ND.
Antonov An-24B. Made from scratch. Very good FDM. 3D model by Adrian. WIP.
Project Russia (some cities, based on OSM with custom objects).
Soitanen
 
Posts: 489
Joined: Sat Jun 16, 2012 7:50 am
Location: Saint-Petersburg, Russia
Version: git
OS: Linux Mint 17

Re: Encrypted aircraft dynamics

Postby Hooray » Thu Aug 28, 2014 3:00 pm

Technically, anything is possible if you're willing to modify the C++ code, as long as you comply with the open source license - i.e. legal requirements, which kinda makes the whole effort pretty pointless, because once you start distributing your fgfs/jsbsim setup to some entity, you'd also be required to comply with the GPL/LGPL. Also see the whole "DRM" debate in the devel list archives.

You could work around such issues by using some 3rd party tools such as TrueCrypt, or by simply keeping your data on a server and providing an API on top of the data - but otherwise, it will be pretty straightforward for any technically-inclined person to work around such mechanisms and acquire the real data without too much effort.

Personally, I'd try to see if there's some legal workaround possible, such as using the data to create some form of interpolated/extrapolated subset of it, which should still be much better than anything we have got in FG, without having to distribute/use the real thing.

Otherwise, I'd consider using the client/server-based FDM approach discussed at: http://wiki.flightgear.org/Technical_Re ... _Simulator

Note that this doesn't necessarily have to imply that you actually have to use some kind of internet-based server - the "server" could just as well be a locally running FDM server runnning in its own address space and communicating with FG via IPC. Which would mean that you could even include such data without being bound by the terms of the GPL/LGPL. FlightGear already supports external proprietary FDMs via the netFDM struct, and it should be fairly easy to leverage, and extend, this mechanism for these purposes.

Subject: FDM tcp server communicating with multiple instances of fgfs
Hooray wrote:we've been toying with the idea of having a central FDM server for years, see: http://wiki.flightgear.org/images/1/1e/ ... ecture.pdf

However, things were never designed to work this way (neither fgfs, fgms or our FDMs...)
So this may obviously require a bit of tinkering, and being able to patch & re-build stuff from source would help definitely.

I recently played a bit with JSBSim, and that should be "relatively" straightforward to expose over network: http://wiki.flightgear.org/Implementing ... nother_FDM

That should be possible to expose over the existing interface: http://wiki.flightgear.org/Implementing ... ace:_FGFDM
http://wiki.flightgear.org/Property_Tre ... _FGNetCtrl

For a "fdm server", you would probably want to modify fgms slightly, because you would be sending control stuff to fgms, which would then forward it to its own FDM instance (or several instances running multi-plexed). You'll also need some kind of hand-shake between fgfs<->fgms that requests a certain FDM, which could -for starters- simply set up controls/netfdm slaving afterwards.

The most generic method would be using the concept of a property server and then exchanging just the /controls properties with the fgms process, which would forward things to jsbsim/yasim, and compute FDM outputs, which would be returned to fgms/fgfs. A simple workaround/prototype might be extending fgms to support netFDM and netCtrls directly, it would be a huge hack, but could work pretty quickly.

https://www.draw.io/#LFlightGear%20FDM%20Server
Image

Your design has the added advantage that you don't need to pass through fgms, i.e. having a completely different FDM server using the existing I/O protocols would be easier fo rsure

http://wiki.flightgear.org/Remote_Properties
http://wiki.flightgear.org/Distributed_ ... FlightGear
http://wiki.flightgear.org/Distributed_ ... Simulation
http://wiki.flightgear.org/FlightGear_H ... chitecture)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Encrypted aircraft dynamics

Postby daveculp » Thu Aug 28, 2014 9:02 pm

Some years back I considered adding to JSBSIM the ability to load aircraft from hard - coded data that would be compiled in. That would be necessary for using JSBSIM as part of an application that was competitive in nature, like a racing or fighting sim. I hadn't contemplated encrypting the data, since it would be inaccessible to most users. Of course cheaters can always find a way, and the source would contain the encryption method.

This would be a start though. The biggest roadblock will be the infinite haggling over what parameters are needed to "adequately" define the model.
User avatar
daveculp
 
Posts: 505
Joined: Sun Feb 24, 2013 2:50 am
Location: Las Vegas, USA
Callsign: DCulp
Version: 2017.3.1
OS: Ubuntu 17.10

Re: Encrypted aircraft dynamics

Postby Alant » Thu Aug 28, 2014 9:48 pm

If JSBsim (or Nasal for that matter) could include a compiler that would solve this particular problem, as well as offering the tantalising prospect of faster run-time code. Pre-compiled (e.g. DDS) textures are already in use within Flightgear.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Encrypted aircraft dynamics

Postby Hooray » Thu Aug 28, 2014 9:58 pm

JSBSim should already be using STL data structures for most things - so there's probably not too much to be gained by "pre-compiling" stuff, unless you're talking about some kind of serialization scheme that would primarily address the parsing overhead, i.e. not too relevant at run-time.
Nasal is a different beast - anything can be done there obviously because it's entirely turing-complete, but any kind of encryption scheme would be "open" - even if added as an hard-coded extension function. Personally, I don't quite see the need for DRM in FlightGear (or even JSBSim) - but supporting a serialization scheme would not be difficult, and compressing/encrypting the whole thing also wouldn't be very difficult.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Encrypted aircraft dynamics

Postby Alant » Thu Aug 28, 2014 10:35 pm

Yes, a compiler does the parsing just once.

I am a dinosaur from the Fortran age when I had to optimise my programs at the machine code level so that they would fit in the memory and run in the allowable time frame. This XML stuff seems somewhat wasteful of resources - and it is hard to follow.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Encrypted aircraft dynamics

Postby hvengel » Thu Aug 28, 2014 10:59 pm

Hoorays point is that the data is parsed from the XML into dynamic look up tables (IE. STL). The only resources used beyond that needed to make the FDM function is the overhead of pulling the data out of the XML into memory. That would have to happen no matter what form the data was in.

Although there may be better ways to store the data than XML if you are unconcerned about human interaction with the data. I think that making the data human readable/editable is the main point of using XML. It may be overly verbose but it works and there are standard libraries for reading/parsing XML files so this makes using it for data input fairly simple. This benefits both FlightGear and JSBSim in terms of limiting the complexity of handling configuration data. In addition there are a limited number of standardized formats for this type of thing such as JSON and all of those that are human readable/editable have many of the same issues as XML.

Full function FDMs are complex and understanding the XML used to configure a complex FDM is a very minor issue and anyone who actually understands a full function FDM will have very few issues with the XML part of this.
hvengel
Retired
 
Posts: 1127
Joined: Sun Dec 24, 2006 5:35 am
Location: Minden Nevada

Re: Encrypted aircraft dynamics

Postby Alant » Thu Aug 28, 2014 11:18 pm

No. I am not going to get involved in a discusion about modern day computing, which is way over my head.

It is a shame that a few lines af Fortran from an old autopilot of mine now take up a few pages of XML. (i.e. Just the same as it did in machine code when I tried to hand optimise the compiled code ;-) )

Such is progress.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Encrypted aircraft dynamics

Postby Hooray » Thu Aug 28, 2014 11:32 pm

right, XML is extremely verbose - especially FlightGear's way of using XML, which is primarily due to the way the property tree works internally.
However, let's keep in mind what XML is supposed to be used for (data MARKUP), and what it is being used for in FlightGear, especially FDMs: as a poor-man's programming language.
Obviously, a real coding language is much more expressive than XML - but XML's verbosity and form make it accessible to non-coders, of which we have many ... I don't think those people would be too happy having to use C, C++, Nasal or Fortran instead of XML :D
JavaScript/JSON could be easily supported in Nasal, too - but we don't see many people using Nasal that way. Also, Nasal performance will be inferior to XML-based data structures parsed into STL containers.
Abstraction layers come at a price obviously. But in this particular case it's simply because JSBSim doesn't support "real" scripting, but only XML-based building blocks that need to be chained together.
Meanwhile, the FG AP/PID system (its building blocks!) has even become superior in comparison to JSBSim.

Progress is mainly about accessibility - we wouldn't be having 300+ aircraft/FDMs in FlightGear if people had to literally "code" their FDMs - not because they couldn't do it, but just because they think that coding is some highly technical skill - without realizing that coding in an ill-suited markup language dialect (aka "XML") is making things more difficult (and verbose) than necessary.
Most of the people who have developed complex FDM/AP systems obviously have demonstrated that they have the mental capacity to also work in terms of actual "code" - it's mostly syntax that differs after all, but concepts will remain similar (loops, counters, functions, inputs/outputs, state management and stages).

Funnily, complex systems like these are easily modeled in purely functional programming languages, which would be quite a bit more advanced than most/any C++ or Nasal code we have - GLSL may be a different beast due to its concurrent nature - but people claiming that they cannot be bothered to "learn coding" while creating massive FDMs and JSBSim systems are only really fooling themselves, because they've already become coders in niche "coding language" based on XML and aerodynamics/control theory building blocks :mrgreen:
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Encrypted aircraft dynamics

Postby Jabberwocky » Fri Aug 29, 2014 12:53 am

And still, planes defined in Java would be cool ...
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Encrypted aircraft dynamics

Postby KL-666 » Fri Aug 29, 2014 1:06 am

As Hooray says, xml is DATA markup. Let's leave xml at being data and put the logic in code. I know there is a tendency to put some or more logic steering information in xml. But the result is an interpreter like definciency in runtime resource cost.

Kind regards, Vincent
KL-666
 
Posts: 781
Joined: Sat Jan 19, 2013 2:32 pm

Re: Encrypted aircraft dynamics

Postby Hooray » Fri Aug 29, 2014 1:08 am

Not sure, why you'd want to do that - but if you post the corresponding Java code, it should be straightforward to either turn it into C++ or even Nasal (as long as you don't use any fancy Java-specific APIs) :mrgreen:

Usually, people will go to great lengths to discuss their own favorite languages - but ultimately, FlightGear is highly domain specific, so no matter the implementation language (C++, Java or Nasal), certain things will inevitably look fairly similar - some contributors have been pushing for perl/python support for years, seeing all kinds of flaws with Nasal - without realizing that the interfacing side would almost certainly look pretty much the same, i.e. in terms of extension functions/APIs to deal with other subsystems -like the property tree- and that's pretty much where most of the problems come from - because of the way our main loop is structured, i.e. the language itself doesn't matter as much (we'd be having the same problems if people were using python, perl, or ruby) - with python, there's even a GIL (global interpreter lock), whereas Nasal is -at least conceptually designed to be threadsafe- so, yeah - the GC issue we wouldn't necessarily have if we had Lua support, but otherwise, short of running such subsystems in another process/address space, we'd not be in a much better position.
Java vs. C++ is another debate though, mainy because of the whole concurrency/multi-threading issue we've been seeing in FlightGear in the last years, and the number of low-level worker threads getting added, with little or nor serialization/synchronization taking place - such things are harder to miss in languages with higher-level concurrency support, such as Java or Ada.

When FlightGear was originally designed, JVM/JRE performance was not very impressive - these days, it could actually be a pretty good foundation for a flight simulator, especially a multi-platform simulator:

Subject: co-piloting
Hooray wrote:People like David Megginson (property tree, XML etc) even stated that they would have preferred FlightGear to be written in Java (portability etc), but it simply wasn't feasible in the 90s to develop a flight simulator in Java providing more than 10 fps :D

https://www.mail-archive.com/flightgear ... 05812.html
David Megginson wrote:I'd love to do FlightGear in Java (framerate be damned), but since I get little support, I can settle for C++.


Fast forward 1.2 decades later, we'd actually be fine with a Java-based FlightGear these days, and certain problems/bottlenecks wouldn't even be there, while refactoring would be a joy :D
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Encrypted aircraft dynamics

Postby adrian » Fri Aug 29, 2014 1:23 pm

What does thread safety have to do with Pythons GIL? :shock:
Python is inherently thread safe, and infinetly superior to Nasal, otherwise I'd be writing code in Nasal instead of Python.
Also, there are a great number of high performance flight simulators written entirely in Java, since at least 2001.
Btw, the main reason for using XML is validation, not the fact that it's more readable.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 3:15 pm

Re: Encrypted aircraft dynamics

Postby Hooray » Fri Aug 29, 2014 1:39 pm

This wasn't meant to suggest that Python is inferior to Nasal - obviously such a comparison would be pathetic, given the momentum of the python community.
The GIL is a real bottleneck in Python, which is why people have been working towards python implementations without a GIL - obviously, this does have to do with thread-safety because the GIL is used to synchronize Python VM threads running bytecode concurrenctly because concurrent memory access is not (yet) thread-safe in Python. See the Python developer docs for details, e.g.:
https://wiki.python.org/moin/GlobalInterpreterLock
In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython's memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)

CPython extensions must be GIL-aware in order to avoid defeating threads. For an explanation, see Global interpreter lock.

The GIL is controversial because it prevents multithreaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck.

However the GIL degrades performance even when it is not a bottleneck. Summarizing those slides: The system call overhead is significant, especially on multicore hardware. Two threads calling a function may take twice as much time as a single thread calling the function twice. The GIL can cause I/O-bound threads to be scheduled ahead of CPU-bound threads. And it prevents signals from being delivered.


Thus, the GIL addresses issues that -in this form- don't exist in Nasal itself - even though we're prevented from using Nasal accordingly because the FlightGear integration layer prevents 99% of all extension functions to be thread safe - but given cppbind, it should be possibly to explicitly serialize things at the API/bindings level eventually.

Using XML has many theoretical advantages - but DTDs and schemas are not really widely utilized in the FlightGear ecosystem - in fact, not even the PropertyTree parser does really validate anything - which is mainly due to the loosely-coupled nature of the PropertyList XML format, which is just a container for key/value pairs - and one of the main reasons why our support for backward compatibility suchs so much - C++ code dealing with PropertyList XML files (but also others) is basically never validating the files that are processing - the best case scenario is having some -usually outdated- DTD floating around for one specific subsystem. JSBSim is in a slightly better position here - but otherwise, we're really only using a fraction of XML in FlightGear, and are usually mis-using XML, too.

The only thing that is really validated is if a file is a valid XML file and if it has the top-level PropertyList root element - otherwise, there are thousands of ways for users to screw up because we really aren't using XML the way it was intended to be used
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Encrypted aircraft dynamics

Postby onox » Fri Aug 29, 2014 4:28 pm

Hooray wrote in Fri Aug 29, 2014 1:08 am:Usually, people will go to great lengths to discuss their own favorite languages - but ultimately, FlightGear is highly domain specific, so no matter the implementation language (C++, Java or Nasal), certain things will inevitably look fairly similar - some contributors have been pushing for perl/python support for years, seeing all kinds of flaws with Nasal - without realizing that the interfacing side would almost certainly look pretty much the same, i.e. in terms of extension functions/APIs to deal with other subsystems -like the property tree- and that's pretty much where most of the problems come from - because of the way our main loop is structured


In some ways this is true, but still, Nasal is very limited, it is like going to back to the stone age, having to fight with sticks and stones. Some tiny problems I noticed for example is that you cannot do setprop("/some/property", true) or return true. You have to write A <= B and B <= C instead of A <= B <= C. No proper API for manipulating data structures and regular expressions :(

Hooray wrote in Fri Aug 29, 2014 1:08 am:Java vs. C++ is another debate though, mainy because of the whole concurrency/multi-threading issue we've been seeing in FlightGear in the last years, and the number of low-level worker threads getting added, with little or nor serialization/synchronization taking place - such things are harder to miss in languages with higher-level concurrency support, such as Java or Ada.


Since when does Java have high-level concurrency support? O_o I don't consider the synchronized keyword and the notify mechanism high-level. The language has mutual exclusion, but data is encapsulated by convention only, wait-notify mechanism doesn't prevent livelocks and it has no guards/barriers.

Hooray wrote in Fri Aug 29, 2014 1:08 am:When FlightGear was originally designed, JVM/JRE performance was not very impressive - these days, it could actually be a pretty good foundation for a flight simulator, especially a multi-platform simulator


Java does have good performance these days, but due to the GC it will always eat so much memory. If you don't want good high-level support for concurrency and real-time systems, no sound generics, no mixup of organizational units and objects, no separation of specification and body, no pre and post conditions or predicates, no representation clauses for precise data representation, no ability to model scalars, no range restrictions, no modular arithmetic, no named parameters, no easy way to import/export functions from/to C/C++, Oracle, no GPL licensed compiler part of GCC, then by all means choose Java. Otherwise Ada is a much better choice :)
Last edited by onox on Fri Aug 29, 2014 4:47 pm, edited 1 time in total.
onox
Retired
 
Posts: 431
Joined: Fri Jun 20, 2014 3:45 pm

Next

Return to Flight dynamics model

Who is online

Users browsing this forum: No registered users and 1 guest