An ARINC 661 tutorial: Hello World

After the general overview and an architecture presentation, this is the third post about the ARINC 661 standard.

Let's continue by a little Hello World. Following the tradition, we will want to show a "Hello World!" label. But to make this example a little more interesting, we will put it in a container.

You should remember that all graphic stuff in ARINC 661 is performed in the CDS side (the ARINC 661 Server). Also the definition of the GUI is stored in a Definition File (DF) which is used by the CDS at initialization. There are two "flavors" of DFs: The binary version (which was the only one which was defined at the beginning of the standard), and the XML version, which was mainly devised to simplify Definition File editing (but as all the informations provided in the binary DFs are also there in the XML DFs, nothing prevent to use them also in a ARINC 661 Server).

We will probably cover binary DFs in another part of this tutorial, but for now, we will use XML Definition Files to explain how the standard works.

So are you ready. Let's dive into our first ARINC 661 Definition File guys!

It's a simple Hello World so we will only define one very simple DF. OK, let's go:

<?xml version="1.0"?>
  <!DOCTYPE a661_df SYSTEM "a661.dtd">
  <a661_df library_version="0" supp_version="2">
    <model>
      <prop name="ApplicationId" value="1"/>
    </model>
    <a661_layer>
      <model>
        <prop name="LayerId" value="5"/>
        <prop name="ContextNumber" value="0"/>
        <prop name="Height" value="10000"/>
        <prop name="Width" value="10000"/>
      </model>
      <a661_widget name="SamplePanel" type="A661_PANEL">
        <model>
          <prop name="WidgetIdent" value="1"/>
          <prop name="Enable" value="A661_TRUE"/>
          <prop name="Visible" value="A661_TRUE"/>
          <prop name="PosX" value="0"/>
          <prop name="PosY" value="0"/>
          <prop name="SizeX" value="10000"/>
          <prop name="SizeY" value="10000"/>
          <prop name="StyleSet" value="STYLESET_DEFAULT"/>
        </model>
        <a661_widget name="Hello World Label" type="A661_LABEL">
           <model>
             <prop name="WidgetIdent" value="2"/>
             <prop name="Anonymous" value="A661_FALSE"/>
             <prop name="Visible" value="A661_TRUE"/>
             <prop name="PosX" value="5000" />
             <prop name="PosY" value="5000" />
             <prop name="SizeX" value="1500" />
             <prop name="SizeY" value="1000" />
             <prop name="StyleSet" value="STYLESET_DEFAULT" />             
             <prop name="MaxStringLength" value="20" />
             <prop name="Alignment" value="A661_CENTER" />
             <prop name="LabelString" value="Hello World!" />
             <prop name="ColorIndex" value="black" />
             <prop name="RotationAngle" value="0.0" />
             <prop name="MotionAllowed" value="A661_TRUE" />
           </model>
        </a661_widget>
      </a661_widget>
    </a661_layer>
  </a661_df>

OK, now lets go to the details.

<?xml version="1.0"?>
  <!DOCTYPE a661_df SYSTEM "a661.dtd">

Well like all XML documents, it begins with the declaration of the DTD for ARINC 661. Nothing much to say here. Here the DTD is assumed to be in the file system, but there's nothing particular about the DTD declaration in the standard.

  <a661_df library_version="0" supp_version="2">

The supplement (or release) version of the standard. Tne standard is currently at supplement 3. This allows to define for which version the DF was defined.

    <model>
      <prop name="ApplicationId" value="1"/>
    </model>

The first interesting thing here. The ARINC 661 standard defines a concept of Applications, or User Applications (see the previous post). A User Application can send or receive messages to/from the Server. And there is a gold rule: Each Definition File defines widgets (I will explain how later in this post), but the widgets defined in this Definition File are managed by one Application only. That way, we are sure that will be no resource conflicts on who is able to change the state of a widget. This is an important feature which may simplify certification of an ARINC 661 Cockpit Display System, but also allows ARINC 661 implementation to live peacefully in the context of Integrated Modular Avionics (such as ARINC 653). So here we define the identification of the Application which will manage this Definition File content (of course an Application can manage more than one DF).

    <a661_layer>
      <model>
        <prop name="LayerId" value="5"/>
        <prop name="ContextNumber" value="0"/>
        <prop name="Height" value="10000"/>
        <prop name="Width" value="10000"/>
      </model>

Here we have the declaration of a Layer, which is the top-most element in the ARINC 661 widget hierarchy. A Definition File contains one or more Layers, but a Layer is not a widget, which means that it is not possible to include a layer as a child of another. hmm almost but we will look after that later (in another post).
Height and Width are optional, because a Layer being not a Widget, defining its size is just a hint (in the XML File, it may be used by for editors). The ContextNumber is something used in runtime, we will also left it in another post.

      <a661_widget name="SamplePanel" type="A661_PANEL">
        <model>
          <prop name="WidgetIdent" value="1"/>
          <prop name="Enable" value="A661_TRUE"/>
          <prop name="Visible" value="A661_TRUE"/>
          <prop name="PosX" value="0"/>
          <prop name="PosY" value="0"/>
          <prop name="SizeX" value="10000"/>
          <prop name="SizeY" value="10000"/>
          <prop name="StyleSet" value="STYLESET_DEFAULT"/>
        </model>

Our top-most widget in the Layer (we also can have more than one top-most elements in a Layer, we just chose here to have only one of them). For each widget declaration we have its name and most importantly, its type, here A661_PANEL. The widget type just points on one fixed widget type defined in the ARINC 661 Standard. A661_PANEL is a container which can have a Look and Feel. In fact it's exactly the ARINC 661 definition of a Panel.
Another very important part of each widget identify is its WidgetId, which must be unique for each Layer. Apart from this identification, our panel has a position and a Size
I know what question you will ask: all of this is very good, but were is its background color, its border color and all this stuff? Well Look and Feel is not in the Definition of the GUI, as in all well-defined widget toolkits. Unfortunately the standard does not standardize the Look and Feel definition itself.
Not completely. It allows to define the style of the widget, using a keyword or a number. That way, if you have defined elsewhere several styles for your widget, you can point to it in your Definition File, by using the property StyleSet.

        <a661_widget name="Hello World Label" type="A661_LABEL">
           <model>
             <prop name="WidgetIdent" value="2"/>
             <prop name="Anonymous" value="A661_FALSE"/>
             <prop name="Visible" value="A661_TRUE"/>
             <prop name="PosX" value="5000" />
             <prop name="PosY" value="5000" />
             <prop name="SizeX" value="1500" />
             <prop name="SizeY" value="1000" />
             <prop name="StyleSet" value="STYLESET_DEFAULT" />             
             <prop name="MaxStringLength" value="20" />
             <prop name="Alignment" value="A661_CENTER" />
             <prop name="LabelString" value="Hello World!" />
             <prop name="ColorIndex" value="black" />
             <prop name="RotationAngle" value="0.0" />
             <prop name="MotionAllowed" value="A661_TRUE" />
           </model>
        </a661_widget>

After that it is very simple. You understand that the label (type: A661_LABEL of course) is a child of the A661_PANEL container. As was already the case for the StyleSet, the Font used to draw the label is a pointer to a Font resource defined elsewhere. The Alignment of the label use one of several already fixed enumeration values, but this should be straithforward. And MaxStringLength is something that will be useful at runtime. It defines the maximum number of characters that the label can accept (if modified by the User Application), and it ensures that no memory allocation will be necessary after the Server initialization (something not allowed in certified environments). ColorIndex and RotationAngle and MotionAllowed are also easy to understand.

Two last things to know: In ARINC 661, the reference point is at the bottom left corner, rather than at the two left as in other widget toolkits (or in OpenGL). So the Y axis goes up and not down. And all lengths are defined in 100th of millimeters rather than in pixels, which ensures that the definition will look the same on different monitors. Which is why you can see in this example rather big values for Widths and Heights.
And now a screen shot of the result with a Java-like Look & Feel for the panel:

An ARINC 661 tutorial: architecture

Well I promised a second part in my first introductory blog to ARINC 661. That's it.
The following image is a a rough diagram on how ARINC 661 works at design time and at runtime:

• The ARINC 661 Server (also called ARINC 661 Kernel), which is a part of the Cockpit Display System (CDS) is initialized with a set a ARINC 661 Definition Files. Remember that they are the equivalent of XUL or HTML Files, which means that the code of the Server is completely generic, and that any set of DFs can be used to start the Server. Hence the Server GUI code is not hard coded.


• At runtime, the System Applications (called user Applications or UA in the standard) are able to communicate to the Server to change widget parameters that were created at initialization. From the other side, the Server send to the User Application user events on widgets (such as clicks on buttons, change of text fields, etc...)

The format of a Definition File is completely defined in the standard. The "base format" is binary based (for the computer savvy, with Big-Endian ordering, to be sure that it's the same in any architecture). But the standard also defines an XML format.

The low-level network communication is not defined by the standard (allowing to use any relevant network transport protocol, such as ARINC 429, AFDX, or even simpler protocols such as UDP or TCP. But the content of the messages send from/to the Server or the User Application are also formally defined by the standard.

This architecture allows for very cool things, which are new for avionics systems: It is possible to define a Cockpit GUI completely on standard PC hardware and OS, and even to test it (at least on the CDS side), and then deploy the GUI definition (the Definition Files) on the real avionics system without any change.

An ARINC 661 tutorial: an introduction

For those of you who don't know what ARINC661 can mean (and I bet that's the majority of those who will read this post, if there are any of course), I suggest you go to the Wikipedia article for ARINC 661. As it is written:
ARINC 661 is a standard which 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 binary Definition Files (DF).

The CDS software is constituted of a kernel which is able to create the GUI hierarchy specified in the DF during initialization, thus not needing to be recompiled if the GUI definition changes.

Which must trigger something for those of you who are familiar with HTML, or even better, familiar with XUL, the Mozilla declarative interface language.

XUL made it possible to define the user interface of Firefox once in a XML file and run Firefox on every possible platform, rather than having to hard-code it for each platform, which would have been extremely burdensome and error prone. Rather than that, the Mozilla people thought better. They defined a grammar to define generic UI components (panels, buttons, sliders, etc...), and only had to implement each of these small components on the different platform they wanted to support. Oh and the engine which could assemble these components together. Smart idea. You only have to look at how Firefox has become a reference in the browsers world.

Well in the case of XUL the engine which assemble the widgets is called Gecko, and each specific UI is defined in a XUL XML file (well you can do a lot more than that, like defining your own widget templates for example, but we don't need to look into all of this now).

Let's say that ARINC 661 uses a Definition File (DF), which is the equivalent of the XUL file, and the engine is called ARINC 661 kernel or CDS (Cockpit Display System).

Well there are some differences: As it is designed to be used in avionics, ARINC 661 is designed to work in real-time systems, and a CDS must be DO-178B compliant. For this reasons there are some major differences between languages such as XUL and ARINC 661.

But don't be upset by this disclaimer. At the core, these languages share a lot of similarities, and ARINC 661 is not overly complex at its core. Which does not mean that it does not have its own subtleties BTW.


I realize that this post is already too long for an introduction. Let's close it to say a few other things about this standard before delving into details:

• ARINC 661 is an ARINC standard, used to standardize avionics concepts. Another very well know ARINC standard is ARINC 429, which is, as wikipedia says, the technical standard for the predominant avionics data bus used on most higher-end commercial and transport aircraft.


• ARINC 661 is not an academic document. It was at the basis of the Airbus A380 Cockpit GUI development, and is also seemingly used for other Airbus aircrafts. It is also used by Boeing, for example for the 787 development


• Last but not least, I am a member of the ARINC 661 committee

Stay connected and I hope that I will have time to draft the second part soon.

Seems that Miguel De Icaza is not neutral anymore

Miguel De Icaza's recent post for October 5 is written as an answer to what he said was a personal attack by Richard M. Stallman, but he is not very honest when doing that. One example:

Richard Stallman frequently conjures bogeymen to rally his base. Sometimes it is Microsoft, sometimes he makes up facts and sometimes he even attacks his own community

The he makes up facts sentence is linked to a post on the FSF website by RMS where he publicly acknowledged that he made a mistake about Mac OS X. So contrary to what De Icaza's is saying, this post is an example of RMS integrity.

So how do you call what De Icaza's is trying to do then? hmm unfortunately I don't have very kind words for this kind of behavior. And it seems that I'm not the only one. Now Miguel De Icaza has gone too far.

From one comment on slashdot: RMS has a single line that can be seen as an ad-hominem. Your piece is almost entirely an ad-hominem. Enough said.

Sadly it seems that he is now objectively an advocate for Microsoft, regardless of the cost for free software, regardless of the cost for us users and developers. I now have my answer: I can't trust him anymore.

Is Miguel De Icaza neutral toward Microsoft ?

As you may or may not know, Miguel De Icaza is a well-known developer who is the head of the Mono project, an open source project which attempt (and succeed, at least partially) to reimplement Microsoft's .NET Framework.

Miguel De Icaza and Novell are helped by Microsoft for Mono development (for example, Microsoft Microsoft's Test suites or specification details, elements that were exclusively given to Novell, and are and will be not released to other developers. Also, Microsoft has declared it would not sue anyone using Mono users for patent infringement, providing they obtained it through Novell. I agree that it's maybe a matter of personal Point of View to judge that these are details, or are important limitations. However, it is also true that no developer could evolve Mono implementation with the same tools and help that Novell has, and even that those who would try to do that may be pursued by Microsoft for patent infringement.

So much for the context. Now Microsoft launched a new open source foundation called the Codeplex foundation. This foundation has many of Microsoft people at its head, but there's also a few non Microsoft people, including Miguel De Icaza himself.

Miguel De Icaza posted an article on his blog to announce this, and also to say that he thought it was a very good move on behalf of Microsoft. Needless to say, there were a lot of comments on this post, some positive, some very negative, even sometimes inflammatory.

I posted a comment myself, which was not inflamatory, but just said that I was still dubious of this move by Microsoft (I did not discuss De Icaza's involvement). Reasons I gave were:

• At the same time, Microsoft tried to sell patents related to Linux to patent trolls, only luckily these patents could be bought "just in time" by the Open Invention Network.


• Microsoft gave recently some GPL source code concerning Hyper V (a Windows Server virtualization) drivers, to the Linux kernel, but it appeared soon that this code was buggy to the point of being almost unusable. Also Microsoft does not answer any questions asked by the kernel developers about this code, which may force these developers to drop it from the kernel codebase.

In substance, I said that I trusted acts more than prose and that Microsoft acts still were not Open Source friendly at all.

hmmm my comment was deleted without warning from the blog. Why? I don't now, but this makes me now discussing Miguel De Icaza's involvement with Microsoft (something I did not do before, even in this comment).

Update: Miguel De Icaza just stated the cases where he deletes comments on his blog. Mine does not fall into these categories...

Beware of differences between .NET and Mono

First, for those who don't know of what I'm talking about here, Mono is an open source implementation of .NET, and Moonlight (built on Mono) is an open source implementation of Silverlight. Though being (I bet it's not by accident) unclear about the legal situation of those who use Mono or Moonlight (two Novell products), Microsoft push Mono and Moonlight because it shows that .NET can work out of the box on Linux. Great.

Let's look at this a little more. I just read the last post from Jimmy Schementi's blog, a Microsoft developer who participate in the building of IronRuby, a .NET implementation of Ruby. The Microsoft team only works on the Microsoft .NET stack, but when IronRuby followers signal them bugs on Mono or Moonlight, they try fix the bug. At the end IronRuby is more or less working on Mono and Moonlight, meaning that it is working on Linux too. But.

This is the impression you have at first. But not all is working out of the box, and not because IronRuby still is in its 0.9 version. There's things that work in .NET but won't in Mono (Microsoft is in .NET 4.0, but Mono currently tracks the 2.0 version, and some things can not be emulated in Mono because it is to much tied to Windows), there's things that work in Silverlight and not in Moonlight (Moonlight is an implementation of Silverlight 2, but Silverlight has already reached version 3).

The contrary is also true. Mono and Moonlight allow things that can not be done on the "regular" .NET framework.

So beware if you think that code written for .NET / Slverlight will work out of the box. It won't, except if you are extra careful of using only things that are also available on the open source re-implementation. It reminds me of the differences between the Microsoft Java implementation and Sun's Java. It could work, or it could not work, depending on the situation.

But in these days it was not legal. Now it is, Microsoft has the right to do what it wants with .NET. I'm OK with that, but I also have the right not to play with all these .NET goodies. Right ?

P.S.: I have nothing against Jimmy Schementi's article. My only concern is that separating what works on one, two, or both implementation is not very clear in his post.

Office 2007 rant

OK,OK, always wining I know. My company works with another which use Office 2007 extensively, but we still use Office 2003. Previously, our IT did not provide us any tool to convert from the .x formats to the old one (This has changed now).

However, we have at work a program which allows employees to buy Office Pro for their home for a very inexpensive price. I bought it (but did not installed the 207 versions of the apps) thinking it could be handy. And so it did. No more for the context.

So I installed Word, PowerPoint and Excel, and was able to open the .pptx file that I received at work. Fine.

Except that I never used the Ribbon before. The beginning were not easy, as nothing was in a place I was used for in the previous Office 2003 version (the one I use at work everyday). After a while I get used to it, but I still don't think it's entirely a good change:

• No more direct access to the old File menu, you have to go through the new oversized Office button to access to all File actions different from the simplest save (and you are not saved from numerous clicks to do what you want)


• Very difficult to customize what as replaced the toolbar. For example with Office 2003 if you often used at the same time basic editing tools (such as the brush to copy text attributes in word or PowerPoint), and revision features, it was very easy to have both at the same time; now you have to go through a tedious process of customizing the interface (which is absolutely not what you want to do) to achieve the same result. Bottom line is: yo don't do it and you switch a million of times from one tab to the other.


• Knowing where an action is is not always easy.


• And why, why designing such a huge cryptic Microsoft button for the File actions? It means that nobody will be able to stick to the same UI for the similar actions for accessing to File actions in their own apps. One more time, it seems that Microsoft did something only to erase every possible competition.

Remember this post: I talked about my two first open Source projects:

• MDIFramework aim to provide a ready-to-use desktop application infrastructure in Java. I mainly created this project because I always reused the same piece of code in my own work, so I wanted to have a generic library instead. I thought it was better to open source it, so that's what I've done.


• MDIUtilities is a utility library with various classes in the swing, IO, geometry, etc... fields. There's tons of other libraries in the open, but it is not always easy when all you want is a small library to provide utility classes. Sometimes you could end-up with tons of different libraries, for which you only use few classes.

Well these two projects have both been bumped to 0.3 version. In the hope it can be useful...

About MDIFramework, maybe you will say: Why not using Eclipse ? Well Eclipse is a huge framework. When you develop with Eclipse in mind, you are in the Eclipse ecosystem, and you end with a lot of Eclipse dependencies. That can be a good thing, but if you want to keep control on your work, and avoid to bear the burden of too many dependencies (or limit the size of your install), you should look elsewhere. Plus Eclipse does not handle everything for you.
But why not using appframework ? Unfortunately (for the moment) appframework does not manage several things that are handled by MDIFramework:

• Plugins


• dynamic menus


• storing / retrieving non GUI parameters between sessions


• managing FileTypes

...And MDIFramework was created before appframework even existed on the Web (2006).

Microsoft, what are you doing with .NET ?

It seems that the size of the .NET framework is increasing with every update. Last auto update seems to be at a bloated 250 MB !!!(RTM was approximately 200 MB, but remember it is only a SP1 update !!). It's funny that people keep criticizing Java for the size of its download, when Java 6 JRE is less than 15 MB. Plus you can download only the kernel (less than 5 MB), which is enough to play any Java applets, and if you need more, other parts of the JRE will be loaded as you need them.

It reminds me of Acrobat Reader, which is now more than 30 MB (only to be able to view PDF Files !!), it has become so bloated with unneeded options as time passes that opening a PDF document now takes ages, even with modern hardware !!! Adobe, what do you think ?

Steps to improve wikipedia

I have just been repeatedly insulted by a user on wikipedia with such terms as "you really are just talking gibberish now", "Your accusations of original research are pathetic", "I cannot believe I wasted my time on these arguments believing you to at least be rational", "you're a complete hypocrite", or "I am sorry you don't possess the intelligence...".

Well it's the first time it happens for me, and I'm really editing in wikipedia for some years now, so it's not such big deal (I'm sure it can / will happen to everyone after a while), but it made me think about things that could improve editing in this project. This will not change anything in cases like mine now (sadly there's people like that everywhere), but I'm trying to look more generally than just around my little problem):

• make it mandatory to register, so as it would really be possible to block vandals (again this is NOT related to my case, as the user insulted me, but he clearly is NOT a vandal). I remember a case when various IP addressed obviously coming from the same origin kept vandalizing various articles, but the address changed because it must have been an internet cafe or a school, so it was really impossible to block it, even using IP)


• allow to see the IP for any registered accounts (except in special cases of course, related to people wanting to be protected when posting, such as in some countries when posting on internet can be dangerous from their well-being). This would then be easier to detect people payed to post for various companies

XUL for Java: stucked (for the moment)

Remember This post: I just created a new java.net project to allow to use XUL declarative scripts out of the box with Java, and allow to bind them at will with Java code or even other scripting languages as well. The code comes from another project were it was working very well, but after extracting it from this project, I still have a big big problem with accessing some Javascript code from the XUL script (which makes the whole thing unusable of course for the moment). I know it's a trivial problem because the same use case works like a charm in the original implementation, I must have deleted the wrong line of code somewhere...