An ARINC 661 tutorial: communication

A recent comment on my blog leads me to the necessity of continuing my list of tutorials about ARINC 661 development. Today will be about communication. hmm at least it will be the first of a list of posts on the subject, because if ARINC 661 XML definition is easy to grasp, I can't say the same thing about communications in the ARINC 661 world.

Don't be afraid. It's not because it's particularly complicated, but just because it's a binary communication protocol, so looking at the message can be a little cryptic.

Let's first say that ARINC 661 communication goes both ways: User Applications can ask for widgets (or even Layers) modifications, and the CDS Server will notify the relevant UA of any User event only on the Definition File it manages (remember the part about ApplicationI in my Hello World tutorial). Now you understand why this ApplicationId tag is very important.

Another important thing is that the standard does not mandate any transport protocol. The ARINC 661 communication protocol is just living on any transport protocol we choose. For example, ARINC 661 messages can be transmitted on the very simple UDP protocol, or TCP, or even complex avionics protocols like AFDX for example. On another point of view, one can encapsulate the ARINC 661 messages binary content, for example to add a checksum function to the transmission. ARINC 661 is agnostic on the way datas are transmitted. The only thing that matters is that you have to find somewhere on the network (in a way understood both by the UA and the CDS) the same array of datas.

Before going into the gory binary details, let's categorize what can goes from/to User Applications and CDS. ARINC 661 messages are composed of several binary blocks juxtaposed together called run-time commands (for UA to CDS communication) or Request/Notifications (from CDS to UA communication).

From UA to CDS:

• A661_CMD_SET_PARAMETER: This is the basic command to change the value of one parameter of one widget in the widgets tree (for example, in the my Hello World tutorial, we would be able to change the color of the A661_LABEL widget, or it's text content, etc...).


• A661_CMD_UA_REQUEST: A request from UA to CDS, about a Layer in general (for example activate or inactivate a layer, or render the Layer visible if it was not visible before)

From CDS to UA:

• A661_NOTIFY_WIDGET_EVENT: To notify the UA that a user event has occurred on a widget


• A661_NOTIFY_LAYER_EVENT: To notify the UA that an event has occurred on a Layer


• A661_NOTIFY_EXCEPTION: To notify the UA of any exception occurring for the CDS

Do you want more? More on this in a few days, it's a promise!!

I Hate Mountains will soon be your nightmare

Yes, from the creators of Portal Prelude, this very ambitious campaign will be available in one week now.

Now it took ages for them to create this campaign (which should be awesome by the way). The team leader explained blog after blog how much Valve screwed developers.

hmm.

If you want my point of view (and even if you don't want it, it's my blog, so I do as I please), they were VERY ambitious, and they asked for mod interfaces Valve would never have thought about. I bet they had problems. To quote some of their rants (about Valve):

• "On Portal prelude: We are aware that there is some problems running the game with the free version of Portal on Windows but there's nothing we can do. Do yourself a favor and ask Valve instead, because it's their entire fault. basically there seems to be a problem on the free version of Portal Valve distributed since some days, and their mod is not working anymore since then". So, Valve give Portal for free since one week, and they bash them because since then, their mod is not working anymore?


• "Oh great, the release of The Passing broke our intro camera because they thought it would be funny to modify L4D1 animations. This is great.". And so? They should not modify anything so your still not released work should work?


• "What the fuck is wrong with this game, where the hell is my drawer? ": And you never thought you could have make a mistake, my friend? Once in your life?


• "I don't see where you've seen that there's not so many companies who share their tools with the general public. Today, most (if not all) of the major companies share their tools with the general public as a
  business move. Google, Twitter, Facebook, Epic Games, Paypal, eBay, Amazon, Microsoft, Salesforce, etc. I worked with the tools of all these companies, and the vast majority was top notch, perfectly working, fully documented and behaving as expected". Really? Every time I use Microsoft development tools and APIs, I have to rely to internet forums to make it work well. Unfortunately, a lot of people have the same problems as me.. Google Android API is still a bit under-documented (to say the least). Due to the fact it has a long history, Win32 is really a mess. MFC architecture makes it really VERY difficult to use, and totally cryptic (nothing's logical there). XUL is very poorly documented. This list can goes on an on, and some of these libraries are not free. Basically, if you want to use an API (especially if you don't have access to the sources), you should be prepared to some problems. That's how life's goes on. But that does not make them unusable.


• "This is an horrible process that involves the terrible Faceposer tool."

Now about non-valve things

• "FluxBB creators obviously know nothing about creating easily skinnable style sheets"


• "Dammit, the Twitter plugin on our website isn't updating anymore. What did I do wrong this time? Boy, Wordpress seems so unstable."

That did not prevent them to use the free audio Valve gave them (as for other mappers) for their campaign, like for example "I Hate Mountains".

You get the big picture. And don't say I'm not knowing anything about software development, I've done and I'm still doing a lot, using all kinds of libraries.

So, OK, Valve's SDK could be better documented (still there's the Valve Developer Community, which is free, contrary to MSDN (and don't say that MSDN is clear, it's also a mess, and it cost a lot). But I bet that a lot of people who have problems with the Source SDK won't write in the wiki.

However, enough with this. While I don't like very much the attitude of some of the I Hate Mountains team, I'm sure they are very good at mapping, and that their campaign will be great. They just need to learn a little more humility sometimes.

On google docs

We see a lot of buzz about google docs everywhere on the web these days. There's even a well-known blogger on zdnet writing that Open Office is Dead, because google docs web applications work so well.

Well I have tried to use google docs very recently, and the results were so bad that I will not go back:

• Compatibility of google docs with Office format is abysmal. It just does not work at all, even for very simple documents. Converting a short and very simple Word document in google docs took ages, and the resulting document lost a lot of markers and tags. Converting back the same document to word did not work at all. The resulting document could even not be opened in the last Word version. End of story. It seems that google docs lives in it's own little world, but it really is not enough for an office suite


• On the other hand, conversion from and to MS Office format work very well in open Office, even for huge and very complex documents. I lately had problems with a huge Word document at work which took ages to work with in Word (even Word 2007). I opened it on Open Office at home, lost nothing (same document), worked on it without problems, and then converted it back to Word. Again I lost nothing and all worked very well


• I don't see the point in needing to have constant internet access to work on a document

Seems that google still has a lot of work to do to have a competing Office suite. But they also seem to work on too many things at the same time.

ExoPC: a real PC tablet?

There is a lot of buzz nowadays about exoPC, a future tablet PC which will be available on March according to their developers. Of course, this tablet benefited from a LOT of buzz on the web, because it was announced just after the iPad. It is announced at the same price as the iPad 32 Go, is powered on Windows 7, is capable of USB connectivity, and is also base on a multitouch technology.

Whaow great!!

hmm, let's look at it a little more closely:

• Autonomy: 4 hours vs 10 hours for the iPad, 4 hours is not a lot, but it's understandable, as it uses Windows 7, an admittedly good OS, but not designed for mobile usage. Battery life for Windows 7 is even reportedly not very good, probably because it is designed to use "costly" services such as Aero, and relies originally on DirectX 9 for graphics on regular PC usage


• Weight: 820g vs 680 g for the equivalent iPad model


• Thickness: 2.1 cm vs 1.3 cm for the iPad. I understand that, because the use of Windows 7 makes them need to have a ventilator on-board!!!


• Power: Processor is 1.6 Ghz vs 1 Ghz for iPad, but the absence of a GPU (integrated Intel graphics on-board, probably to reduce price and avoid further reduction of battery life from 4 hours to 1 hours only) is a very bad news for multimedia usage, which is the primary usage for this type of product. Comparisons on the same 3D games between Nexus One and iPhone 3GS were interesting because they showed that despite Nexus One having a more powerful CPU (1 GHz vs 600 Mhz), iPhone was more than twice faster than Nexus One in all configurations.


• Multitouch: hmm, multitouch development is not finished yet for exoPC. What? less than one month before the product is available? By the way, even if it can optionally handle touch screens, Windows 7 is not known to be the king of touch screens or even multitouch technology

Now for non technological impressions:

• First it seems that all the demos that were shown were sent to blogs and Internet news sites directly by the designers themselves. Does not seem very neutral. And you will never see any journalist using the tablet anywhere on the web


• The company which develop and will distribute exoPC is a Canadian company (Quebec). Great, but it's president is a car dealer (!!!)


• When questioned about references for the exoPC company, Jean-Baptiste Martinoli, the man at the origin of the product, gives the name of mioplanet, another small Canadian company. He says: "it enjoys a significant technological heritage including the structure Mioplanet, another company of Rimouski, a very discreet company that delivered innovative solutions worldwide for clients such as HP or Microsoft for nearly 10 years". Problem is that the president of Mioplanet his... himself. This kind of auto-referencing is something which makes me very cautious. And no names for other companies which could be business partners for exoPC has ever been produced


• The product is said by the designer to be presented at CeBIT next month ("Next month, Microsoft will present our product at CeBIT in Germany, one of the largest hi-tech fairs in Europe. And it will do the same during a major speech (keynote) next month in Tokyo"). However, if you search for exoPC on the CeBIT web site, you return nothing...

I bet that this product does not really exist my friends.

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.