Board index FlightGear Development Aircraft Systems

A general approach to systems modeling in Nasal

Modeling aircraft systems, like electrical stuff, hydraulics, pneumatics? Feel free to ask support.

Re: A general approach to systems modeling in Nasal

Postby galvedro » Wed Jan 29, 2014 10:04 pm

After moving to a new house, and flying back and forth to my home country for the Christmas season, it's about time to write an update here.

I am not writing code right now (nor have been since my last post), but I have been doing some research and working on the design board instead. This is the idea I have in mind right now:

I can see an API implemented in C++ that includes a Component interface and a base implementation of InputPort and OutputPort objects. There is also an API function that allows the connection of two Component's by means of their IO ports. With these elements, it is possible to programatically define a network of interconnected Components.

There is also a CompositeComponent implementing the Component interface. A CompositeComponent is defined in terms of other Components, binding them together in a group. A Composite behaves like a normal Component, having its own IOPorts and the classic reset() and update(dt) methods. Composites make it possible to define hierarchies.

The core C++ backend provides a fifth object, an UpdateScheduler. The UpdateScheduler is informed whenever a Component is instantiated, and whenever a connection is made, this allows the scheduler to keep an internal graph representation of all the systems in the simulation and how they are related.

The UpdateScheduler controls when to update each component, by analyzing the internal graph representation. Components may have specific requirements about updates, like "every frame", "10 Hz" or "async" (whenever there is a change in the inputs).

Now, Nasal. Components can be implemented in Nasal as well, using a syntax with a flavor similar to the one I have been showing in this thread. Nasal Components are registered against the scheduler like their C++ friends, and can they play together with them.

I have no idea how to force a Nasal script to conform to a certain interface, but I am toying with the idea of forcing Nasal Components to be defined on individual .nas files and making the framework load each Component individually in a namespace with very limited interfaces. The framework would then wrap the script into a proper object before running any code. Something like this could relief authors from thinking in terms of object oriented programming. It could be as simple as "your Nasal Component must have IOPorts, a reset() function and and update() function defined at the top level, everything else is handled by the framework".

IO Ports do not depend on the property tree, but can be connected to it at will. The example in the previous post showed this working in a Nasal prototype, and the concept would be extended to C++ as well.

Why not bind all ports to the property tree by default? For the same reason that temporary variables are not part of public interfaces. There will be Components defined by connecting other Components together (Composites). It doesn't make sense to expose all the internal connections, it would pollute the prop tree in terms of naming space, raise the memory requirements without justification, and open a door for "illegitimate dependency coupling".

<end of brain dump>

Well. This approach presents a gazillion of challenges, I know, BUT, there is actually some support already in the core, which means that the concept is not that far off.

SGSubsystem, SGSubsystemGroup and SGSubsystemMgr, roughly fill the roles of Component, CompositeComponent and the UpdateScheduler I have just described. The main difference is how component inputs, outputs and their relations are defined.

I am not inventing nothing new either. I started with the idea of trying to do something resembling Simulink, and then discovered a fairy well documented open source project from the Berkley University called Ptolemy II. These guys have tons of information (and java code) on how to achieve something like this (and much, much more).

So, the scope of the project would really be to refactor parts of FG to implement a minimal subset of the Ptolemy II architecture, together with bindings for Nasal and XML. :roll: :?

It won't be ready tomorrow... :D
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 1:55 pm
Location: Sweden

Re: A general approach to systems modeling in Nasal

Postby Hooray » Wed Jan 29, 2014 11:14 pm

I have no idea how to force a Nasal script to conform to a certain interface, but I am toying with the idea of forcing Nasal Components to be defined on individual .nas files and making the framework load each Component individually in a namespace with very limited interfaces. The framework would then wrap the script into a proper object before running any code. Something like this could relief authors from thinking in terms of object oriented programming. It could be as simple as "your Nasal Component must have IOPorts, a reset() function and and update() function defined at the top level, everything else is handled by the framework".


That is basically how Philosopher's MapStructure framework works under the hood, see $FG_ROOT/Nasal/canvas/MapStructure.nas and the *.lcontroller, *.scontroller and *.symbol files in the map sub folder there.
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

Previous

Return to Systems

Who is online

Users browsing this forum: No registered users and 1 guest