Closed systems

[jdeas]

I brought this up as I have been through this evolution before. When I started developing microcontrollers the only intercommunication between embedded devices was a parallel bus unless the same manufacture made both units! I saw that grow to where we are now. A mismatch of ?new? proprietary RS-232/422/485 formats to save money and weight. I am not talking about NMEA or our other legacy serial standards from the certified world. They are limited by todays standards but still very valuable. NMEA etc are published specs and most engineers can figure out a way to sniff the line for clues. Troubleshooting these new proprietary bus systems are more of what I would call shotguning. You simply make changes until a miracle happens. (No flames please, some EFIS guys do have practical diagnostic).
Proprietary systems do not have to use proprietary buses or wiring. It is a business choice. There are bus systems that allow for standard and proprietary data to share the same line. By staying proprietary they only increase our risk of being stuck with expensive unserviceable gear. How many of us are comfortable installing a single source proprietary engine in their plane? It appears to me that some EFIS systems would have the same fiscal impact!


A simply example. I want my trim systems to be speed aware. Using a standard bus I already control them but I do not know of any EFIS that can give me their sensor data for airspeed. I want my flaps to warn me when I cross Vso. Again a speed sensor is needed. I want my electrical system to alert me to bulb failures or over current conditions. I want my autopilot to adjust my trims so I don't scare my passenger when I turn it off. In return I want to give the EFIS my flap position, my trim locations, my power status so I can make the most use of my panel space.


Maybe I am just asking the right questions a bit too early in the evolution. Perhaps we will get plenty of service out of the Beta tape deck before we need to replace it. With airframes lasting 50 years I am sure this will be a slower progression than what I am use to.


Regards

[trawlergeek]

ARINC-429 has inherent speed limitations and even abuses in the use of the Labels (which are only somewhat standardized) from airframe to airframe and manufacturer to manufacturer.

AFDX (a deterministic form of Ethernet) is being used in the 787, A380 and other airframes. Why? Bandwidth for the more data intensive "payloads" and increased complexity in the cockpits. (Read _very high_ resolution terrain, displays, and synthetic vision as the motivators across the industry).

I am not sure what is meant by CAT-5 as a protocol. Of course, that is exactly what is being discussed here and why we see issues with many choices made by the EFIS providers. Ethernet as a physical connectoin medium is commonplace. However, it will be difficult to get plain ol' ethernet to work reliably in critical "Level A" applications. Hence, AFDX. THe payloads and protocols employed on ethernet are clearly "custom" in our domain.

Eventually, when integration with off-the shelf certified and experimental use sensors and devices is considered and the EFIS supplier doesn't provide the necessary equipment, compatibility is an enabler for them. Standards are necessary - even if not "pure," to connect with those other sensors.

A429 is more expensive than RS-232, RS-488, and any other trivial serial hardware implementation. The software for A429 is significantly more complicated. Will it be cheaper for us? Yes. You don't want to know how much teh A429 interface contributes to the 430 or 480 costs.

Just like the Raytheons and Furunos (Marine Industry Big Players) and their "proprietary interfaces, buss, and protocols, we will have ours for some time to come.

Is it good for the consumer? I don't think so. Protecting your market share always involves creating barriers for the competition. So how do you convince the EFIS suppliers to open up their standards and seek common ground?

This argument is a lot like the Open Source argument in the software arena. Not everyone sees the path forward the same way. And the argument has been playing for decades.

Best of luck. I support your efforts. However, I only expect limited success.

(besides my RV-9A project and my family. I spend a lot of time at Rockwell Collins as an Avionics Principle Software Engineer here in Melbourne. It can be fun.)

[Rainier Lamers]

Originally Posted by jdeas

I brought this up as I have been through this evolution before. When I started developing microcontrollers the only intercommunication between embedded devices was a parallel bus unless the same manufacture made both units! I saw that grow to where we are now. A mismatch of ?new? proprietary RS-232/422/485 formats to save money and weight. I am not talking about NMEA or our other legacy serial standards from the certified world. They are limited by todays standards but still very valuable. NMEA etc are published specs and most engineers can figure out a way to sniff the line for clues. Troubleshooting these new proprietary bus systems are more of what I would call shotguning. You simply make changes until a miracle happens. (No flames please, some EFIS guys do have practical diagnostic).
Proprietary systems do not have to use proprietary buses or wiring. It is a business choice. There are bus systems that allow for standard and proprietary data to share the same line. By staying proprietary they only increase our risk of being stuck with expensive unserviceable gear. How many of us are comfortable installing a single source proprietary engine in their plane? It appears to me that some EFIS systems would have the same fiscal impact!


A simply example. I want my trim systems to be speed aware. Using a standard bus I already control them but I do not know of any EFIS that can give me their sensor data for airspeed. I want my flaps to warn me when I cross Vso. Again a speed sensor is needed. I want my electrical system to alert me to bulb failures or over current conditions. I want my autopilot to adjust my trims so I don't scare my passenger when I turn it off. In return I want to give the EFIS my flap position, my trim locations, my power status so I can make the most use of my panel space.


Maybe I am just asking the right questions a bit too early in the evolution. Perhaps we will get plenty of service out of the Beta tape deck before we need to replace it. With airframes lasting 50 years I am sure this will be a slower progression than what I am use to.


Regards

Airspeed is one of the labels we transmit as standard on the ARINC (some autopilots need it). It's a fairly easy task to make a ARINC receiver and read the labels directly using a micro, even high speed ARINC - so if you are able to hack around with a micro such as an AVR or PIC it should not be a huge task (but can be a fun one).
In addition to that we send a huge amount of all sorts of data from our USB host ports - if you have a small USB device capable micro you could pick it up. I have not documented this side of our comms yet but will do so if there is interest.

Rainier
CEO MGL Avionics

[Kevin Horton]

Originally Posted by jdeas

A simply example. I want my trim systems to be speed aware. Using a standard bus I already control them but I do not know of any EFIS that can give me their sensor data for airspeed. I want my flaps to warn me when I cross Vso. Again a speed sensor is needed. I want my electrical system to alert me to bulb failures or over current conditions. I want my autopilot to adjust my trims so I don't scare my passenger when I turn it off. In return I want to give the EFIS my flap position, my trim locations, my power status so I can make the most use of my panel space.

The Dynon EFISs push out a bunch of data on a RS-232 serial bus, including airspeed. The data format is published in the operating manual.

[Doug]

I know it is not an EFIS but the GRT EIS4000 pumps out RS232 with airspeed! (Povided itis fitted with the airdata option)
Contact GRT for the data format.
Doug

[jdeas]

Originally Posted by Kevin Horton

The Dynon EFISs push out a bunch of data on a RS-232 serial bus, including airspeed. The data format is published in the operating manual.

Kevin,
This is true of several EFISbut nothing that is muti-master or does not take a bridge micro of some sort. I have asked several EFIS guys about building a bridge but no one was interested.

[Rainier Lamers]

Originally Posted by jdeas

Kevin,
This is true of several EFISbut nothing that is muti-master or does not take a bridge micro of some sort. I have asked several EFIS guys about building a bridge but no one was interested.

You have not talked to us.

What exactly do you want ? Bridge to what ?

Rainier
CEO MGL Avionics

[jdeas]

Rainier,
We have spoken on this before. While your systems do have the advanced hardware to do this, you have only focused on the automotive engine side. If I got this wrong then I apologize.
As far as I know none of your external sensors or displays use CAN for anything other than talking to an existing automotive engine computer (point to point).
I also don't think that any of your external sensors use a standard serial communications system or protocol.

What I am talking about is taking these distributed sensors and actuators and making their data and control open. This takes hardware and a commitment to a protocol standard.

In a reply to an earlier post: This is not strictly open source. This is standards based systems. I don't want to know how Rainier's digital compass works, I want access to its data. While I applaud the open source guys, there are business reasons for both open and closed software. I like open but accept closed if external verification is possible.

Another argument for this is safety. Consider a program error where a compass going over the international date line suddenly locks up
If my second compass was from another vendor then the chances of a software bug ending my flight are diminished to near zero. Is this possible with any existing expEFIS?

[Rainier Lamers]

Originally Posted by jdeas

Rainier,
We have spoken on this before. While your systems do have the advanced hardware to do this, you have only focused on the automotive engine side. If I got this wrong then I apologize.
As far as I know none of your external sensors or displays use CAN for anything other than talking to an existing automotive engine computer (point to point).
I also don't think that any of your external sensors use a standard serial communications system or protocol.

As far as I know, there is no such thing as a standard communications protocol for aviation if we can exclude ARINC 429 and to some extent NMEA.
Apart from these we do have RS232, CAN (both engine and for other use like our autopilot servos), USB (both host and device) and our airtalk link which is similar to LIN.
So we have lots of standards as far as the hardware goes. All of this is useless as a general standard as no standards for "standard" messages exist. So every vendor naturaly implements their own messages and data steams as they need. So far we have been very forthcoming in documenting our communications...

What I am talking about is taking these distributed sensors and actuators and making their data and control open. This takes hardware and a commitment to a protocol standard.

But we are doing that, are we not ?

In a reply to an earlier post: This is not strictly open source. This is standards based systems. I don't want to know how Rainier's digital compass works, I want access to its data. While I applaud the open source guys, there are business reasons for both open and closed software. I like open but accept closed if external verification is possible.

Simply download the SP2 OEM domcumentation - it's all in there and the compass is currently used by dozens of OEM's. Same for the AHRS. Also available on the same data stream is all sorts of other information from the EFIS including primary flight and engine monitoring data. Again, this is openly documented.

Another argument for this is safety. Consider a program error where a compass going over the international date line suddenly locks up
If my second compass was from another vendor then the chances of a software bug ending my flight are diminished to near zero. Is this possible with any existing expEFIS?

Well, this is perhaps a bad example - a compass is completely unaware of things like date lines - it simply measures the magnetic field. But your argument is valid with respect to things like navigation and moving map due to the numeric wrap around from -180 to +180 degrees which presents the software writer with some interesting challenges.

Finally, if you would allow me some comments on standard data on standard hardware interfaces: Even though we have documented a lot of our stuff (and where we have not it's due to either lack of time or lack of interest from those wanting access to the data), this will not result in standards or in anybody else adopting any of our "standards". The reason is quite simple: There is no pressure to do so and every vendors implementation is guaranteed to be different enough to make the existing "potential" standards unsuitable. Like we would have a look at some existing data stream - Lets for example say GRT's EIS stream. We would look at making our system compatible with it - but only as an option, not as primary system as it would not 100% fill our needs. Other vendors would be faced with exactly the same issue.

Rainier
CEO MGL Avionics

[Bubblehead]

Beware of serving two masters! It seems like we are trying to do two ormore things that can be counter one another.

Standards are nice, but can limit creativity. If everyone adopts a standard (DOS) what happens to innovation (Mac). In my "day job" a lot of our products have strict standards. They made sense when developed to fix a problem with product durability or performance, but we are trying to use more advanced materials and the old standards put us at a disadvantage strictly due to the testing requirements. It is really hard to change those specs once adopted because the companies with the "legacy" products work hard to protect their artificial barrier to competition.

The end result is customers are prevented, or as a minimum delayed, from having access to innovative products.

I'm also a big stickler on intellectual property rights. I did not read the article on 100 year software protection, so won't comment, but we spend a lot of blood, sweat and coin to develop products and would not do it if we could not have some IP protection. One of the reasons businesses are slow to sell to India, China and Russia is the real or perceived threat of reverse engineering and ignoring IP rights. The end result is poorer economic performance of the companies selling into those countries, and a reduction in entry into those countries of new companies and products. Both ways people, investors and employees in the first case and customers in the second, loose out.

I'm willing to give up some flexibility of mixxing product lines for further innovation. If someone wants to open up their code to allow third parties to create new apps, that should be their business decision.