[jdeas]

Is it possible for an EFIS manufacture to come up with a buisness plan where their systems can use existing standards for communications and/or protocols?

Closed systems scare me. Closed systems in a cottage industry scare me more.I have been paid several times over the years to "reverse" engineer systems from companies that stopped supporting them, went under, or simply needed to augment capabilities. It's not cheap.

In the spirit of experimental aviation I do wish one of these guys would see the value in open sourced developments and dare I say, experiment? MGL came close but then I guess the lawyers got in the way.

 

[Rick_A]

Seems like there are standards to me.

I only know what I've learned wiring up my panel but it seems to me that there are common standards in the world of avionics and EFIS's.

I had no problem getting my Garmin avionics to work with the GRT EFIS. I was also pleasantly surprised when I discovered that my MVP-50 sends all it's data to the GRT's - all it took was one wire and a little bit of software configuration.

 

[Ironflight]

Rick is right - there is already a fair amount of commonality in the data transfer world - RS-232 and a lot of common formats.

I understand what JD is saying as well - once you get inside the boxes, each manufacturer is pretty much unique! I think that we are still in the Beta/VHS phase of the technology (but with a whole lot more choices) and the best will survive as the weak fall by the wayside....

Paul

 

[lawspud]

I get your point. No-one wants to be a Betamax guy in a VHS world. Or HD-DVD in a Blu-Ray...

On the other hand, I'm not sure what you envision for tomorrow's cockpit. If you're looking for a true open system, then every modern gauge would encode its data on a common standard, whether an EFIS, a remote ADAHRS, a digital "steam gauge", or any other unit collecting data. That data is then put out on a standard bus, available for any other avionic to access and use for its own purpose.

If that's the concept, I like it. A lot.

It just seems somewhat unrealistic in an extreme niche industry like experimental GA equipment. Getting these very busy, presumably low margin businesses to communicate and collaborate with their competitors seems extraordinarily optimistic. I suppose Garmin could set a de facto standard (and perhaps has, to a certain degree), but they have even less incentive to pursue an open standard than the mom-n-pop experimental guys do.

Additionally, it seems like an unrelated issue to Dynon's AP servos (and, no, I'm not trying to beat a dead horse). Given the fact that the autopilot programming must be specifically designed to control its assigned servo, it is not unreasonable to have a limited or proprietary selection to choose from.

But if one thing is clear, it is that the Big Cheese(s) of several of these companies read this board. Maybe this is our opportunity to get them thinking about the value of a standard encoding bus. No more DSAB, proprietary CAT5 link, or other odd-ball standard that will fade into the mists of time (five years from now).

That standardization could easily lead to more customers, more development paths, and more profit for the canny businessman. Or to nightmare technical support problems, delayed product rollout, and new proprietary sub-standards. Or both.

 

[SteinAir]

But if one thing is clear, it is that the Big Cheese(s) of several of these companies read this board. Maybe this is our opportunity to get them thinking about the value of a standard encoding bus. No more DSAB, proprietary CAT5 link, or other odd-ball standard that will fade into the mists of time (five years from now).

That standardization could easily lead to more customers, more development paths, and more profit for the canny businessman. Or to nightmare technical support problems, delayed product rollout, and new proprietary sub-standards. Or both.

BINGO! I like the above quote. Truth be told...a number of the mfgrs indeed do get along supremely well. I have a picture from last years OSH at my booth when Rob Hickman (AFS), Todd S (GRT), Jim Younkin (TruTrak), Jerry Hansen (Trio), Greg Richter (BMA), Mark S (PS Eng), David B (Avionics Systems) and a Garmin Engineer all standing around shooting the breeze together in one place. I've titled to photo "The OSH Potsdam Convention)!

I've also had beers with a number of the same people assembled around a fire at my campsite telling lies. As a whole, the above guys all get along surprisingly well, all respect each other and actually do talk/work with each other quite regularly. They are all small businesses, all homebuilders/airplane guys and all have a passion for aviation at their core. You won't find a better bunch of "big cheeses" than the guys above. Now of course a few other mfgrs have decided to go it on their own....I'm not saying that's bad, just that they prefer a different sandbox.

I've found a way to get along with most of the pretty well. Some of them obviously have more of an aviation passion while others have a business passion, but in the end there are a lot of great products that come from these peoples brains. I wish I was half as smart as most of them!

My 2 cents a usual.

Cheers,
Stein

 

[lawspud]

I can't say I'm surprised that there's mutual respect and/or friendship. Based on the posts that I've seen here and elsewhere from some of the people that you mentioned, they truly care about their products and this community. A wonderful combination.

And we have as much of an interest in supporting their work and products as they do. One of the (many) things that keeps me building vs. buying a Cessna/Piper/Beech product is the fact that I can build a "modern" airplane with their products. Or, on the other hand, I can buy my grandpa's certificated plane with the same kind of money.

There will no doubt be some trickle-down benefit from their work into certified GA, both with cost and capability. That IS one of the points of the experimental category in the first place, after all. The question is whether or not Open Source can be made practical and profitable for our vendors. After all, a bankrupt AFS (or TruTrak, or whatever) won't be advancing our interests any more than their own.

 

[Rainier Lamers]

I get your point. No-one wants to be a Betamax guy in a VHS world. Or HD-DVD in a Blu-Ray...

On the other hand, I'm not sure what you envision for tomorrow's cockpit. If you're looking for a true open system, then every modern gauge would encode its data on a common standard, whether an EFIS, a remote ADAHRS, a digital "steam gauge", or any other unit collecting data. That data is then put out on a standard bus, available for any other avionic to access and use for its own purpose.

If that's the concept, I like it. A lot.

Ahem,
ARINC 429 ?
No, it does not have to cost the earth. Pretty complete amount of information that can be made available in a pretty robust manner.

It just seems somewhat unrealistic in an extreme niche industry like experimental GA equipment. Getting these very busy, presumably low margin businesses to communicate and collaborate with their competitors seems extraordinarily optimistic. I suppose Garmin could set a de facto standard (and perhaps has, to a certain degree), but they have even less incentive to pursue an open standard than the mom-n-pop experimental guys do.

Additionally, it seems like an unrelated issue to Dynon's AP servos (and, no, I'm not trying to beat a dead horse). Given the fact that the autopilot programming must be specifically designed to control its assigned servo, it is not unreasonable to have a limited or proprietary selection to choose from.

But if one thing is clear, it is that the Big Cheese(s) of several of these companies read this board. Maybe this is our opportunity to get them thinking about the value of a standard encoding bus. No more DSAB, proprietary CAT5 link, or other odd-ball standard that will fade into the mists of time (five years from now).

That standardization could easily lead to more customers, more development paths, and more profit for the canny businessman. Or to nightmare technical support problems, delayed product rollout, and new proprietary sub-standards. Or both.

Well,
one problem with standards at the specific level that you are refering to is that it may limit things and our current experimental EFIS avionics is loaded with innovation that does not want to be limited by anything.

As an asside, servos are getting pretty sophisticated. So are ours. However, when we release our servos for the MGL autopilot (shortly after Osh if all goes well), we WILL PUBLISH the protocol. It is based on the industry standard CAN interface.

Regarding comments on open source which attracted mention of MGL, don't count us out just yet. We have moved one important step closer to this nirvana. This has been a goal for me since I first started the Enigma and yes, there have been all sorts of reasons (good ones) why we just could not do it as fast as we wanted or even in the way we wanted (yes, you are right about the lawyers). But we have learned that there is more than one way to skin a lion (we do big cats here).
One option we are looking at is to open the system for a new open source application that does not use any of our software and that is open from the word "go". It does mean that we are not allowed to contribute (for legal liability reasons) but who knows - it may just work.
But one must not underestimate the task of writing such a beast - our current Enigma system is edging towards one million lines of source code and Odyssey has even more !

As an aside, you may know that South Africa is one of the strongest supporters of open source Linux (no we don't use it) in the form of the Ubuntu Linux distribution. Ubuntu is a local word for "sharing".

Rainier
CEO MGL Avionics

 

[lawspud]

Thanks for the input, Mr. Lamers. That's exactly what I was looking for.

I will admit that I'm simply not familiar with the bus systems that are currently available. A trip to Wikipedia tells me that ARINC 429 certainly seems like the type of standard we're talking about. But the issue remains that there is a lack of support for interoperability. At least at this end of the GA spectrum.

Several of the EFIS products charge extra for an ARINC module. Others (yours, for example), integrate it into the base product. But from what I can tell, these inputs are typically limited in purpose. Accept incoming GPS or nav data. Output AP and comm data. So far as I know, all of these products are designed for serial data distribution rather than hub distribution.

Has there been any industry discussion of a more broad integration or an easier data distribution system? In the future will I have an MGL Odyssey that can compare its heading info with my Dynon D10A through the ARINC bus? Or have all of my flight instruments send their data to a "router" box behind the panel for distribution to the network? Note that this is a serious question. I truly don't know if these things exist in GA, even at the Boeing level.

It just strikes me that the complexity of the power and data wiring is as dated as the Lycosaur motors that people complain about so much. Companies like Vertical Power seem to be addressing the power side of things. If the data guys can do something similar, it sure seems like Stein's job would be a whole lot easier, our panels would be cleaner and more reliable, and our flight information would be more trustworthy.

 

[rfinch]

Rick is right - there is already a fair amount of commonality in the data transfer world - RS-232 and a lot of common formats.

I read the OP as bringing up much more than common data transfer protocols. I think he's ultimately referring to intellectual property rights and the tension between creators and buyers of IP.

The tension has existed for hundreds of years and is embodied in the USA constitution:

Article I, Section 8, Clause 8 of the United States Constitution, known as the Intellectual Property Clause and the Progressive Clause, empowers the United States Congress “To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."

Unfortunately Congress has long sided with the creators, extending copyright to well over 100 years! And letting software be patented.

The Open Source movement, pioneered by Richard Stallman of the Free Software Foundation, is a reaction against excessive protection of IP which results not in the "Progress of Science and useful Arts", but maximum corporate profits (well, maybe not, but that's what they think) and minimum progress.

Since software has different IP properties than writings or physical inventions, I'd like to see Congress create some new laws to accomodate it. Specifically require source code escrow and allow software to be patented only for, say, 5 years. But they're too busy investigating baseball players and other urgent matters for the national well being.

There is precedent for clever end users to develop their own open source application software for hardware. Got an MP3 player? It came with its own proprietary playing and downloading program, but you can download and install an open source program, Rockbox, for many MP3 players; considered superior to the proprietary program by many. It can actually help manufacturers because they can devote their resources to improving hardware and let the open source community provide a robust application program for their product.

Unlikely, I suppose, for the same to happen with our EFIS displays, but I fully sympathize with the OP's concerns. Perhaps the more progressive EFIS manufacturers will at least put their proprietary software into escrow in case they go bankrupt and can't maintain it anymore.

 

[Rainier Lamers]

Thanks for the input, Mr. Lamers. That's exactly what I was looking for.

I will admit that I'm simply not familiar with the bus systems that are currently available. A trip to Wikipedia tells me that ARINC 429 certainly seems like the type of standard we're talking about. But the issue remains that there is a lack of support for interoperability. At least at this end of the GA spectrum.

Several of the EFIS products charge extra for an ARINC module. Others (yours, for example), integrate it into the base product. But from what I can tell, these inputs are typically limited in purpose. Accept incoming GPS or nav data. Output AP and comm data. So far as I know, all of these products are designed for serial data distribution rather than hub distribution.

Has there been any industry discussion of a more broad integration or an easier data distribution system? In the future will I have an MGL Odyssey that can compare its heading info with my Dynon D10A through the ARINC bus? Or have all of my flight instruments send their data to a "router" box behind the panel for distribution to the network? Note that this is a serious question. I truly don't know if these things exist in GA, even at the Boeing level.

It just strikes me that the complexity of the power and data wiring is as dated as the Lycosaur motors that people complain about so much. Companies like Vertical Power seem to be addressing the power side of things. If the data guys can do something similar, it sure seems like Stein's job would be a whole lot easier, our panels would be cleaner and more reliable, and our flight information would be more trustworthy.

No, there is no industry body to handle standards as far as EFIS's are concerned outside of ARINC.
One problem with ARINC is the fact that you have to buy the documents that detail the labels and they are not cheap. The second problem is that the documents are quite bad and generally do not mention how data is to be created - they only show the format of the data in the label. This means that sometimes the data itself is open to interpretation. Sometimes the docs are incomplete (ARINC 735 TIS information for example).

It is not a single hub data bus - but that is not a bad thing. You can connect several receivers to a single transmitter. From a redundancy point of view the ARINC 429 is not a bad system. You can loose a transmitter or a connection but that does not mean that the entire system is down (for example in an airliner).

Cost wise ARINC 429 tends to be expensive due to the dedicated ARINC interface chips and line drivers which are low volume silicon and thus pricey. We worked around this by implementing the ARINC using a fast embedded processor dedicated to the task and used suitable operational amplifiers to implement the line drivers. Effectively we "bit bang" the ARINC. While this required a lot of work to get right it costs perhaps less than 10% of the normal price and this is the reason that from now on all EFIS's we do include ARINC 429 (1 tx and 3 x rx including high speed modes).

Apart from that we use USB for inter panel communication (if you have more than one panel) and CAN for interface to autopilot servos and a number of onboard monitoring and control systems currently in planning or development.

Our old Airtalk link is a low data rate, very easy to use multimaster link (similar to LIN) but is now only used to connect AHRS and compass and it also provides a data link to some of our older monochrome panels.

Then of course there are RS232 interfaces...

It may seem "over the top" to have this many interfaces but it actualy does make some sense. Certain applications either just use a fixed mode of communication (such as NMEA uses RS232) or are ideally implemented using a certain hardware layer.

Rainier
CEO MGL Avionics

 

[jdeas]

Speed of change

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]

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]

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]

Simple Example

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]

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]

MGL support of CAN

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]

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.

 

[jdeas]

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.

The protocol I am working with is CAN aerospace or ARINC 825. It has been around for many years and has been used by NASA, Boeing, and Airbus for subsystems. While I have settled on this standard for my actuators, I am not suggesting this is the best or only choice. It is simply a 'standard' that I can quote to others who want to use the devices.

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.

This is true to some extent but using something like ARINC 825 would not be a problem. There are places for proprietary data in that specification. Data specific to you application can still use this spec and yet still allow more general data like GPS information to be generated or ingested by others. You proprietary data would travel over the same line. This is kind of like saying you would not use ethernet because your data would not fit in a packet!

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. .

Just the opposite can be true. I use Mac for sound editorial, Windows for office applications, and Linux for servers. What ties them together is a common communications scheme (Ethernet). They are all good solid systems but each one has their own particular strong points. All three would be worth less without a way to exchange data with the other.

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. .

Again I have to disagree in part. Making a system closed in the first place is done when a standard does not exist or to create that 'artificial barrier'. The reason I started this thread was to point that fact out. IMHO at least one usable open standard does exist. I am questioning if a business plan can exist that allows the EFIS guys to use these standards. The advantages for the end user would be numerous.


Use Ethernet as an example. Mac and Windows does not publish their Ethernet drivers while Linux does yet they can exchange information.

 

[Rainier Lamers]

The protocol I am working with is CAN aerospace or ARINC 825. It has been around for many years and has been used by NASA, Boeing, and Airbus for subsystems. While I have settled on this standard for my actuators, I am not suggesting this is the best or only choice. It is simply a 'standard' that I can quote to others who want to use the devices.

Now that is usefull stuff !
I must admit, I never looked at this as it seemed "big boy" stuff - but what the hey, why not ?
Our CAN bus use is at its infancy so I might as well make it compatible.
Busy seeing what Google can find for me...

Thanks, that is good contribution.

Rainier
CEO MGL Avionics

 

[jdeas]

Now that is usefull stuff !
I must admit, I never looked at this as it seemed "big boy" stuff - but what the hey, why not ?
Our CAN bus use is at its infancy so I might as well make it compatible.
Busy seeing what Google can find for me...

Thanks, that is good contribution.

Rainier
CEO MGL Avionics

http://www.Stockflightsystems.com maintains the specifications. They have been very good about replying to questions regarding the use of this specification for exp use.

 

[Nomex Maximus]

Avionics "Standards"...

Hello all,

I am just scanning this discussion on my lunch break. I have a few comments.

In avionics, architecture is everything and it needs to start in software, not hardware or systems. You need to look at the whole airplane and think in terms of a clean slate as to what the airplane can or should be able to do. In my experience that never ever happens.

We have a vast supply of standards for how avionics are to work provided to us by the good folks at ARINC. But ARINC serves the commerical aviation world and its standards are driven by what makes sense for airliners. What makes sense for airliners does not make sense for an RV. Take ARINC 429 for example. Yes, it is an avionics standard - developed in the 1980s. Would you want your equipment to be limited by 1980's ideas of performance? (BTW, ARIINC 429 gives you a choice in speeds 11.5 kbit per second or (woooooo) 100 kbit per second. Purty pathetic by modern digital standards.)

The thinking in most cockpits is that you have this big collection of disparate indicators and devices all doing their own little things... and somehow the pilot is supposed to integrate all of the different bits of information into the flight picture and is supposed to manipulate all the different controls to fly the airplane. There is no unified approach to the display of information or the control the the whole airplane, thus, it is unlikely you will see a common standard emerge about who to interconnect all of these things. Why? Because there is no overall architecture to drive it. Architecture is everything.

In the experimental market, I cannot believe there ever will be a standard avionics architecture. It doesn't even exist in the commercial or military world. Even if it did exist in the military or commerical avionics world, that architecture almost certainly would not be well suited to our smaller aircraft or the type of flying we do. If you want a standard avionics architecture in your RV you are going to have to invent it yourself. At best, discussions like this will lead to collaboration of interested builders who may decide to work together at a common instrument system panel or flight system.

As to data busses, I have difficulty understanding why plain ol ethernet will not work adequately for most anything we would ever need in an RV. Yes, I am aware of all the reasons why it won't be used in an airliner, but I am sure that an appropriate implementation of software drivers and proper design of network links can make it fully satisfactory for what we need. So there's your physical layer, what else do you need? Simply publish the message definitions for the UDP messages to be exchanged.

Ideally there would be an object oriented decomposition of the avionics into classes of devices and specializations of devices. Classes of sensors, servos, displays, mission computers, radios, human interface devices, etc, are identified and common functionality factored out and common messaging is defined amongst them. The rest is just coding. I hear of all the wiring that has to go on behind the instrument panels and I have a hard time understanding why it needs to be much more that power lines and a few ethernet cables.

Just my thoughts. I still think I want a classic steam gauge layout in mine.

--NM

 

[Nomex Maximus]

Two more little tidbits to consider...

Assuming a standard ethernet data buss there are two concepts to consider in developing an avionics architecture.

1) XML Configurability. It should be possible for any device to access a system configuration XML file and determine what messages and what message formats it should send and receive. This can happen at system startup. Thus one manufacturer sells an AHRS unit and another sells a mission computer. The two do not have to know about each others products, but only need to be able to read an XML file and be able to read and form their messages according to the data found in the XML file.

Thus, to add a new unit to your airplane you simply add an entry to the system XML file as provided by the new units manufacturer and connect the new unit to the ethernet hub of your choice. When you power the new unit on it will ask around for the system XML file and read who it is to communicate with. Other units will see that there is a new unit and will send the appropriate messages to the new unit as specified in the system XML file.

2) Introspection. One device ought to be able to ask another device, "What are you?" or answer the question "What do you do?" If this capability is implemented then device truly become "plug and play" - the developer of the mission computer software doesn't even need to know about a technology not yet invented when he designs the mission computer software - he only needs to know how to handle a device of the same class of devices (i.e, a new NAV device or a new comm device or a new vision aid device, etc).

--NM

 

[jdeas]

My reason to reject Ethernet

John,
I have pondered this myself. The architecture must be considered on a systems level before you can define a communications system. When I first starting looking at this as a pet project I was thinking of using POE Ethernet as a basis. In the end I rejected Ethernet due to single point failure concerns and cost. Ethernet is very appropriate for several areas. Linking EFIS heads together is a prime example but
I didn't feel it was appropriate for our general airframes. The big boys do use Ethernet but with special switches and redundant hardware that would be very hard to produce for our group.
I found CANaerospace and its successor AINC 825 when I researched NASA's AGAPE project. The protocol has its roots in experimental and GA aircraft. It also had advanced into subsystems with the majors so I decided to dig a bit deeper. AINC 825 is not a legacy bus like 429. There are no hard to find transformers or chip sets. It is based on the same CAN bus hardware used in millions of cars and industrial equipment over the last 10 years.

Consider the hardware's primary design goal as a hardened serial bus for transportation systems and industrial applications. Add to that a protocol made for experimental aviation (NASA) and you have a good foundation for development. Pretty much everything you asked for is already in AINC 825. The ability to ask a device what it is and what it can do exist as part of the standard. Unlike Ethernet, definitions on device failover and backup data is also addressed in the specification although it is sometimes written as best engineering practices.

If anyone else has researched this area I would love to hear their comments. I am steering way clear of EFIS displays and sensory overload in this thread. How the EFIS guys choose to communicate information to the pilot is a very subjective subject. I just feel my widgetX trim system should be able to get airspeed information from fidgetY. What is done with that exchanged information is up to the architect of widgetX.


*I too will have steam gauges as part of my dash. When designing a failover system it's best to get as far away from the primary system as possible!

 

[Nomex Maximus]

A pleasant conversation about avionics in your airplane...

Consider the following dialog going on as you start up your airplane. You have a mission computer driving several displays and radios, listening to several user interfaces and a new device has just been added to the buss - a chronosymplastic infidebulator (CI) (a new NAV device that uses a technology not yet invented).

Mission Computer (MC): Hello, identify yourselves.
...
CI: I am unit CI-4209.
...
MC: CI-4209 what class device are you?
CI: I am a NAV unit.
MC: What are your capabilities?
CI: I can provide lat/lon with +/- 3 inch accuracy. I can provide velocity and acceleration vectors at 100 hertz accurate to..."
MC: What formats do you provide?
CI: JCB-2001, JCB-2002, JCB-4004.
MC: Provide your output in JCB4004 format at 10 hertz. Send it to device DISPLAY-001 and DISPLAY-002. Provide your status to me at 20 hertz in JCB-2002 format.
...
CI: DISPLAY-001,Display-002 we are at N42.608 W85.617...
...

There could be additional queries and exchanges defined to further the interactions - "Perform your built in test" or "What is your status?" or "Stop transmitting to device X" and so on.

--NM

 

[Nomex Maximus]

I have a copy of the 825 standard; I am looking at it. Quick scan - CAN "high speed" is 1Mbit/second - sort of slow when you figure I can go down to Best Buy and get Gigabit ethernet for a just a few dollars. Of course there is much more to the whole choice... and (again just a quick scan of the spec) it looks like the payload size is sort of small per frame...

The reason I choose to talk about ethernet is that it has about all the bandwidth you'd ever need and development and diagnostics are simple and straight forward - just plug it into the LAN your PC is on. The point I am making is that the wiring behind the control panel ought not be much more phyiscally complicated than connecting ethernet and power cables.

 

[jdeas]

I have a copy of the 825 standard; I am looking at it.

The reason I choose to talk about ethernet is that it has about all the bandwidth you'd ever need and development and diagnostics are simple and straight forward - just plug it into the LAN your PC is on. The point I am making is that the wiring behind the control panel ought not be much more phyiscally complicated than connecting ethernet and power cables.

I agree but there are steps between 100khz and 1Ghz data systems. The issue would be cost and single point failure. CAN runs to 1Mhz and when integerated into controllers has a very light processor load. It also does not require a central controller or hub. This is why I would support point to point Ethernet to exchange data between EFIS screens but not to somthing like a trim servo.

 

[Nomex Maximus]

I am assuming multiple redundance in my system... two or more mission computers, or subordinate computers that can take over if the big one(s) fail, also multiple networks that are reconfigurable if failures are detected. And a pilot that can land the airplane without any of this at all.

 

[jdeas]

Does the hardware really fit the job?

Just musing a bit on your concept. In a distributed system how much traffic would be moved between systems? Are we streaming video from the wingtips or just turning on and receiving the status of the landing lights? Unless there are big data sources or sinks in several areas of the airframe is Ethernet the answer. If a commodity computer with an Ethernet port will be at every location then yes. If a microcontroller is at every location is the answer the same?($$) I feel there are valid points but the additional complexity and overhead of Ethernet and a server or desktop OS possibly outweigh the advantages when extended to the airframe as a whole.

My concept is to share actuator control and sensor data throughout the airframe using a standard that already exist. One that uses current technology, has deterministic delivery, fault tolerance, somewhat simple and light weight, and is extendable enough for the existing EFIS guys to accept as practical.

 

[Nomex Maximus]

I see your point. I work on big systems everyday and perhaps what I am proposing is overkill.

I want to have so much bandwidth that I don't have to worry about overrunning a frame or with configuring the network to make sure everything will have the time to get through. Especially if the network we are talking about is "cheap" as ethernet would be and also if the network is simple and makes my life easier as a developer.

I can look at $200 microcomputers that already have ethernet built in - so if I want the data concentrator in the wing to do more than just control some servos I can. Backup mission computer or system safety monitor perhaps. I want to be able to do file transfers when needed. Streaming video is a possibility. I just don't want to be limited by the network. And the idea of just plugging in an ordinary laptop and be able to get to any device in the airplane for diagnostics is also something I like about the ethernet approach.

It doesn't have to be ethernet. It could be the 825 interface but I just think that approach is a bit limiting.

 

[jdeas]

First step is the hardware

It doesn't have to be ethernet. It could be the 825 interface but I just think that approach is a bit limiting.

It is limiting but at the same time what is a practical goal? My take is to follow the crowd when possible. Look at the automotive industry. They went with CAN and LIN over Ethernet. Same with many industrial applications. Why? Start with the hardware. The CAN hardware specification is on line at Bosch. Read through it with an eye towards processor load and redundancy. Then look at what it would take to make Ethernet as stable on an embedded system. Also look at the cost of implementation and the data load expected. Finally consider the distributed nature of the bus. No central control location or computer is needed.

For me the combination of inexpensive embedded processors with CAN built in, millions of cars a year being built with these chips, and an existing ARINC standard for the protocol makes this a prime candidate for development. Now if I could only get the EFIS guys to play nice.

 

[Rainier Lamers]

It is limiting but at the same time what is a practical goal? My take is to follow the crowd when possible. Look at the automotive industry. They went with CAN and LIN over Ethernet. Same with many industrial applications. Why? Start with the hardware. The CAN hardware specification is on line at Bosch. Read through it with an eye towards processor load and redundancy. Then look at what it would take to make Ethernet as stable on an embedded system. Also look at the cost of implementation and the data load expected. Finally consider the distributed nature of the bus. No central control location or computer is needed.

For me the combination of inexpensive embedded processors with CAN built in, millions of cars a year being built with these chips, and an existing ARINC standard for the protocol makes this a prime candidate for development. Now if I could only get the EFIS guys to play nice.

I have to agree with JD.
CAN is as near to bullet proof as it gets and simply an ideal medium for a distributed control system which is exactly what we are after.
CAN is certainly not suitable or even intended for the transfer of large data files or live video steams - but that is hardly an issue in this context.
If you were to have the need for a live digital video feed, surely this would be a point to point thing ? Why let the trim or servo or some part of an engine monitor be involved with something that also carries video ? No that would not do.
I can only see disadvantages using Ethernet (regardless of speed). Cabling is more expensive and critical (think of EMI), you need a hub and there is little in the way of fault tolerance without additional effort and cost.

No, CAN is definitely the way to go and yes, the CAN Aerospace implementation which thankfully is open format deserves support (Thanks for that JD).

This does not preclude use of Ethernet, ARCNet or whatever other *net you can think of for specialized connections requiring high bandwidth, if such is ever needed (which is doubtfull).

Rainier
CEO MGL Avionics

 

[Nomex Maximus]

Simplicity - Adaptability - Expandability

I see your points about CAN and a distributed control system.

I am thinking about things like live video and audio streams to/from the ground, software defined radio and software defined navigation, live telemetry, live remote control, and being able to send files from one subsysem to another, image transfers, etc. But most of all I am thinking that I want to be able to just plug something new into the avionics and have it work without further concern with bandwidth or protocols. I don't ever want to be limited by the network. I am also thinking that I can buy a simple 8 bit controller that already has ethernet TCP/IP and a webserver (use it for ground diagnostics!) on it for less than $200, so why would I want to screw around with RS232, or something else that is not much more advanced? I don't see the weight or complexity difference between CAN and ethernet to be that much especially when ethernet is in many cases COTS... am I greatly mistaken?

Like I said, I don't ever want to be limited by the network. Here at work we are developing a 737 with a bomb bay. It has a bunch of new equipment in the back of the airplane that needs data from the FMS. The FMS has several ARINC 429 busses that broadcast the data that was thought to be sufficient for most users, unfortunately now we need to add more data items to the bus. Rewiring the airplane is not an option. Unfortunately, the requirements for rates of data transmission given exceed the bus capability. And we are talking about less than 400 data items per second (!) I don't want to have those kind of limitations in my airplane.

 

[breister]

I see your points about CAN and a distributed control system.

I am thinking about things like live video and audio streams to/from the ground, software defined radio and software defined navigation, live telemetry, live remote control, and being able to send files from one subsysem to another, image transfers, etc. But most of all I am thinking that I want to be able to just plug something new into the avionics and have it work without further concern with bandwidth or protocols. I don't ever want to be limited by the network. I am also thinking that I can buy a simple 8 bit controller that already has ethernet TCP/IP and a webserver (use it for ground diagnostics!) on it for less than $200, so why would I want to screw around with RS232, or something else that is not much more advanced? I don't see the weight or complexity difference between CAN and ethernet to be that much especially when ethernet is in many cases COTS... am I greatly mistaken?

Like I said, I don't ever want to be limited by the network. Here at work we are developing a 737 with a bomb bay. It has a bunch of new equipment in the back of the airplane that needs data from the FMS. The FMS has several ARINC 429 busses that broadcast the data that was thought to be sufficient for most users, unfortunately now we need to add more data items to the bus. Rewiring the airplane is not an option. Unfortunately, the requirements for rates of data transmission given exceed the bus capability. And we are talking about less than 400 data items per second (!) I don't want to have those kind of limitations in my airplane.

I'm on the software side, but in the business world not the engineering side. While this conversation is interesting, I would ask the silly question: "What is the business problem we are trying to solve?"

It sounds like we have some pretty good standards for data transmission formats of non-video data. And, apparently, this is sufficient for 99% of our aviation needs without adopting a more complicated buss architecture.

There is zero Return on Investment for developing a repeatable / standardized solution for edge cases. This is the realm where proprietary formats are not only acceptable, but actually preferable - until there is sufficient demand, which translates to clear definition, of the problem to be solved, there is no good reason to develop a "standard."

My 2 cents.

Bill

 

[Nomex Maximus]

It is not a silly question. If you just want to command a frequency to a radio or a trim setting to a servo then you don't need a high bandwidth anything.

If you want to do more (and I do) then high bandwidth is desirable.

I sort of suspect from the way this conversation is going that the 825 standard might actually be the way to go. And it would be a good thing if we could get the manufacturers of all the avionics gadgets to agree. I am for it.

If this standard were to catch on then I would separate out the high bandwidth stuff from the low.

 

[jdeas]

Not a practical example

I see your points about CAN and a distributed control system.

I am thinking about things like live video and audio streams to/from the ground, software defined radio and software defined navigation, live telemetry, live remote control, and being able to send files from one subsysem to another, image transfers, etc. But most of all I am thinking that I want to be able to just plug something new into the avionics and have it work without further concern with bandwidth or protocols. I don't ever want to be limited by the network. I am also thinking that I can buy a simple 8 bit controller that already has ethernet TCP/IP and a webserver (use it for ground diagnostics!) on it for less than $200, so why would I want to screw around with RS232, or something else that is not much more advanced? I don't see the weight or complexity difference between CAN and ethernet to be that much especially when ethernet is in many cases COTS... am I greatly mistaken?

No, you're on the mark about Ethernet. It has become a simple matter to implement Ethernet all to way down to 8-bit controllers. Even with this though you still need a phy layer IC and transformer to complete the interface. In addition your controller must have a valid TCP/IP stack. A stack that can handle UDP,TCP, and snmp is not trivial and takes a substantial amount of processor overhead and memory on an embedded controller. When the network gets busy it's easy to overwhelm small controllers. I have systems up to 150 controllers on a single subnet. Managing those systems after a power interruption takes some interesting bandwidth control algorithms!
I have to agree with you from a service perspective. Many laptops are even doing away with their RS-232 ports. An Ethernet or USB port would be a nice way to interface a diagnostic system. My only problem with that is wasting space in my controllers for the USB or Ethernet software overhead. CAN to USB adapters do exist so I would go that route.

I see your points about CAN and a distributed control system.
Like I said, I don't ever want to be limited by the network. Here at work we are developing a 737 with a bomb bay. It has a bunch of new equipment in the back of the airplane that needs data from the FMS. The FMS has several ARINC 429 busses that broadcast the data that was thought to be sufficient for most users, unfortunately now we need to add more data items to the bus. Rewiring the airplane is not an option. Unfortunately, the requirements for rates of data transmission given exceed the bus capability. And we are talking about less than 400 data items per second (!) I don't want to have those kind of limitations in my airplane.

Change out ARINC 429 for ARINC 825 and see how you do.

It is interesting that you mention uplink/downlink issues. In every system I have seen the bottleneck is the radio link. For that reason the primary focus is data compression more than the speed of the copper bus. I have seen great pains to use mp3,mpeg4,H.264 etc data compression at the sensor source as opposed to full bandwidth data across the airframe then compressed at the radio link. This is simply due the fact that video and audio need very specific compression routines. General computer compression routines like that found in radio links do a bad job of compressing rich media content.

 

[jdeas]

There are reasons for the vendor and end user

I'm on the software side, but in the business world not the engineering side. While this conversation is interesting, I would ask the silly question: "What is the business problem we are trying to solve?"

This thread is drifting as the original question was can the EFIS guys find a reason to use a standard communications bus. For the the end user it would allow them to purchase the best compliant compass or airspeed detector and know that their EFIS can use the data.
It also protects the user from ending up with an expensive paperweight if the vendor goes under.

From the Vendor side, it removes the vacum from around their system. Consider GPS modules, they do not have to supply all the sensors unless they want to. They can leave some of these items to third party development if the business plan looks like a looser. Think how slow EFIS development would be if they had to roll their own NAV/COM etc. I am just considering the expansion of this concept to the airframe.

 

[penguin]

First lets figure out what we really want to do?

Guys,

Are you trying to solve the wrong problem? Are we taking plug & play a little too far? I'm thinking about the redundancy in the systems we're talking about; perhaps its desirable to have the air data system and attitude system tied quite tightly to the flight display - less chance for corruption on some open bus. I really dislike the idea of driving autopilot servos via anything other than discrete lines or a dedicated bus, and I can't see the benefit of using a bus in an RV - at high cruise speeds the autopilot probably has sufficient authority to break the airplane, I really wouldn't want the slightest chance that the bus might be corrupted.

The area where open standards, buses and architectures might be useful is in nav systems, but the problem I see is that nav radios are produced by very few people so the only devices that might play are GPSs and display systems. Lets get the top level systems design correct first - ie figure out what is useful to do - before diving into the low level implementation. My view is that fast updates of fresh basic flight data is what any EFIS should do as a primary function, and should protect at all costs. Then layer in all the bells and whistles of the nav pages. If you could plug & play airspeed or magnetic sensors I don't think that basic function could be assured, and I wouldn't be interested in buying one.

Pete

 

[penguin]

If you just want to command a ... trim setting to a servo then you don't need a high bandwidth anything..

Nomex, are you sure you really want to be commanding your trim system over a bus? Buses are great for some things - you've pointed out some great examples - but trim? Not for me, thanks.

Pete

 

[Nomex Maximus]

. . . In addition your controller must have a valid TCP/IP stack. A stack that can handle UDP,TCP, and snmp is not trivial and takes a substantial amount of processor overhead and memory on an embedded controller. Change out ARINC 429 for ARINC 825 and see how you do.

It is interesting that you mention uplink/downlink issues. In every system I have seen the bottleneck is the radio link. For that reason the primary focus is data compression more than the speed of the copper bus. I have seen great pains to use mp3,mpeg4,H.264 etc data compression at the sensor source as opposed to full bandwidth data across the airframe then compressed at the radio link. This is simply due the fact that video and audio need very specific compression routines. General computer compression routines like that found in radio links do a bad job of compressing rich media content.

I am not really thinking of implementing the whole stack - just broadcast UDP messages which should be little more than loading a message buffer and sending. However, I could use one of those $200 8 bits that I have mentioned as a portal for any non-critical TCP/IP that needs to be sent out of the airplane (like to ground equipment, or an internet link). But between subsystems (like a mission computer and a display computer or a user interface computer) UDP would be what I would like to be able to use.

As for radio, I am thinking in terms of using amateur radio for air to ground data links and there I am thinking of high bandwidth.

Hope I am not drifiting too far off the topic.

 

[jdeas]

I'll take the bus

Yea, may sound weird but I would rather have a bus control my trim system. I had a project years ago where a rocket enthusiast wanted a new system to safely launch their rockets. Until that time they were using two wires or an analog transmitter. This system was very basic but in the end that is what made it unsafe. A sporadic signal could easily launch the thing. My solution was to replace the system with a wireless serial link. Now the local system on the pad could only fire the rocket after receiving a very specific bi-directional stream of data. With that change the safety factor went way up.

I see the same thing with the trim system. In my design I don't have 5 wires leading from the cockpit to the elevator trim (2)motor (3)position. I have power and a serial bus feeding a local controller in the tail. This reduces the number of wires and puts the failsafe closer to the operation. If the software is written well and allowances are being made for lost communications then I would take this over the traditional setup. Only a properly configured command would alter the trim. Bad commands or lost communications would do nothing or program the unit to a failsafe location. Let's see a stuck trim button do that! Additionally digital systems are kinda a yes/no proposition. You would have a high probability of getting correct trim data or no trim data. To me this is better than possibly wrong trim data due to a loose connection.
My guess is all the autopilot servos have local failsafes like this already as they have many of the same issues as a bus. They have to do the right thing when they lose contact with their controller.

 

[breister]

This thread is drifting as the original question was can the EFIS guys find a reason to use a standard communications bus. For the the end user it would allow them to purchase the best compliant compass or airspeed detector and know that their EFIS can use the data.
It also protects the user from ending up with an expensive paperweight if the vendor goes under.

From the Vendor side, it removes the vacum from around their system. Consider GPS modules, they do not have to supply all the sensors unless they want to. They can leave some of these items to third party development if the business plan looks like a looser. Think how slow EFIS development would be if they had to roll their own NAV/COM etc. I am just considering the expansion of this concept to the airframe.

Ok I get that, but bringing it home to consumer group represented by this forum I'm not convinced that a common bus is the answer for every device and info distribution problem. I'm certainly in favor of standards and software improvement (shameless plug - visit Atlanta SPIN, a "spin"-off of the Software Engineering Institute) - but I also know that the challenges of a "common way of doing things" sometimes outweigh the theoretical benefits - almost always in the short term, and sometimes even in the long term as technologies come and go.

The current crop of EFIS vendors have done an excellent job of documenting their inputs and outputs - MUCH better than the certified side always does (try locating an Installation Manual for a GNS 480 - it's a State Secret!). Since the TYPES of inputs and outputs they give and receive are fairly standard already, we are 90% of the way there. A Buss architecture has the potential to be a single point of failure, and therefore the system will not degrade "gracefully" in the event of that particular item failing. On the other hand, a serial output can be routed to multiple receivers - and any single wire failure except the source results in only one receiver being denied that signal. That provides pretty good reliability for an aircraft environment.

I guess what I'm saying is, I'm not convinced that there is a one-size-fits-all solution out there. There are plenty of standards, and each seems to be appropriate for a particular setting. If there is a true need for a NEW standard, it will most likely be one that solves a LOT of existing problems - not just a few.

 

[breister]

Yea, may sound weird but I would rather have a bus control my trim system. I had a project years ago where a rocket enthusiast wanted a new system to safely launch their rockets. Until that time they were using two wires or an analog transmitter. This system was very basic but in the end that is what made it unsafe. A sporadic signal could easily launch the thing. My solution was to replace the system with a wireless serial link. Now the local system on the pad could only fire the rocket after receiving a very specific bi-directional stream of data. With that change the safety factor went way up.

I see the same thing with the trim system. In my design I don't have 5 wires leading from the cockpit to the elevator trim (2)motor (3)position. I have power and a serial bus feeding a local controller in the tail. This reduces the number of wires and puts the failsafe closer to the operation. If the software is written well and allowances are being made for lost communications then I would take this over the traditional setup. Only a properly configured command would alter the trim. Bad commands or lost communications would do nothing or program the unit to a failsafe location. Let's see a stuck trim button do that! Additionally digital systems are kinda a yes/no proposition. You would have a high probability of getting correct trim data or no trim data. To me this is better than possibly wrong trim data due to a loose connection.
My guess is all the autopilot servos have local failsafes like this already as they have many of the same issues as a bus. They have to do the right thing when they lose contact with their controller.

In your example, the servo is controlled by a serial line and has a power line - it is a smart device. I like that (and it appears to be similar to the Dynon autopilot solution) - but I don't see how that makes it a bus? Typically, a serial line has ONE source and N receivers. A Bus has n sources and n receivers, and involves some kind of arbitration (controlled time slots to be the sender, as in token ring; packet collision management, as in ethernet; etc.).

Are you saying you would be ok with n sources on the serial line feeding your pitch servo? That would make me a little nervous...

On the other hand, if you DO go down the IP path you should consider wireless (unless you're worried about getting jammed while airborn). Wireless network controllers are now so ubiquitous that the price is quite reasonable; and many have co-processors and buffers in them to reduce the CPU load of the parent device(s). Now, THAT would be a nice way to transport both high and low bandwidth data in your airplane - eliminate the wires! But, you would still want to be careful that each device that must talk to each other device is "registered," so that a passing aircraft doesn't inadvertantly supply information that is INcorrect for YOUR airplane (e.g. transponder starts reporting Jumbo747's altitude - you get busted for being at the wrong altitude!). Registering each device in your "system" can be almost as tedious as hard-wiring each device together - but does have the advantage that you can't burn yourself on the iron....

 

[jdeas]

I should have given a better example..

In your example, the servo is controlled by a serial line and has a power line - it is a smart device. I like that (and it appears to be similar to the Dynon autopilot solution)
....................
Are you saying you would be ok with n sources on the serial line feeding your pitch servo? That would make me a little nervous...

Not like the Dynon. That is a point to point. I only gave a single example with the pitch trim. Expand the pitch trim to include lat trim servo and flaps.
For CAN Arbitration/Collision are handled in a priority scheme and is handed by the hardware itself. No software stack like Ethernet etc. Timeslots are created as part of the installation so they are deterministic (also part of the spec)

The comment on the pitch servo sounds like you expect an 'analog' control of some sort. Not at all. Just like the launcher example and the Dynon servo, only specific commands are accepted and processed. Sending random hash should impact nothing. If you have a trim switch on you dash and on each stick you already have three devices feeding your trim system. Any of the 6 contacts could send the trim to its edge.

In any event I think this thread is done. I don't see the exp EFIS guys expanding to the airframe anytime soon or using anything beyond a 'defacto' standard. If anyone would like to talk about working on a bus based airframe I would love to start a new thread on the subject.

 

[microflight]

Is it possible for an EFIS manufacture to come up with a buisness plan where their systems can use existing standards for communications and/or protocols?

Closed systems scare me. Closed systems in a cottage industry scare me more.I have been paid several times over the years to "reverse" engineer systems from companies that stopped supporting them, went under, or simply needed to augment capabilities. It's not cheap.

In the spirit of experimental aviation I do wish one of these guys would see the value in open sourced developments and dare I say, experiment? MGL came close but then I guess the lawyers got in the way.

Michael Stock suggested that I get in touch with you. I live in Goleta and would like to meet with you and see what you have done with CANAerospace. I am the industry editor on ARINC 825. More specifically to your request 825 is an open standard for commercial and general aviation. Its resemblance to CANAerospace is like a twin. I may be reached at 240 432 6612