N

Nomex Maximus

Well Known Member
From the "Closed Systems" thread :

jdeas said:
. . .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.
Click to expand...

I am just opening this thread for discussions about what kind of avionic architectures and avionics busses would be good for experimental aircraft.

I am of the opinion that there need to be two styles of busses in the airplane - one, a high reliability point to point network capable of typically 100 kbit bandwidth useful for controlling servos and passing small frequent data values and a second high speed high bandwidth bus that allows anything up to and including digital audio and video streams and large files to be transferred between subsystems.

I am assuming a clean technical slate here - much or most of the hardware has not been designed or invented yet.

Brainstorming is welcome. Fire away.

--NM
 
Last edited:
the base should be something like ethernet
(they're using a modified standard of it for the new big airliners as well)
every unit simply needs to be plugged into like a 8port switches and you're all set what data is concerned.
the only other connections being sensors (if not smart/distributed) and power.

maybe a lightweight version with thinner cables. but the rj45 is quite a good plug for that application.


rgds,
bernie
 
What would be the most appropriate bus and why do this at all

John,
Glad to see I'm not the only one looking this over. Not trying to steal your thread but I though I would send this rather long winded write up on the two different network styles I have considered and what I am doing. Hope it brings in more comments and eventually some progress for all. I also invite constructive criticism on my approach.

Most existing bus systems (including Ethernet) are based on communications between two or more known devices. To speak to a device you must broadcast the message to the network or know the specific address of the device you wish to contact. Unless you support ancillary services like name severs or dhcp, these address must be hard coded and known by all their playmates. These are basically 'address based' systems. You can send messages point to point or broadcast to all and let the individuals devices decide in software if the message applys to them. There really isn't much in between*.

CAN bus is different from most bus systems I have worked with. The CAN system can send messages based on address but stopping there would be a waste in applying the protocol. In CAN your transmitters and receivers listen for 'labels' on a common bus. Any device can send any label and any receiver can be asked to listen for specific label/s. CANaerospace supplies a standard set of labels and data types making things even easier. In some ways this can be con screwed into saying all CAN messages are broadcast but in reality only receivers keyed to receive specific labels see the message. The individual systems are not interrupted by messages they don't need. Once your EFIS sends the airspeed, any known or unknown system that wants that information can be configured to listen for it. Adding compliant equipment is easier as the system is completely distributed and none of the original units need to change for new gear to start receiving and transmitting data. It is also a daisy chain setup. No homerun cat-5 or active switches/hubs to go bad.

Why do I want this?

Consider trim servos. A smart trim system should be able to protect itself from a stuck trim switch, protect itself from motor stalls due to end of travel or binding, and report its health and trim position to the pilot. Several people already make smart trim modules but to date they need 5 or more wires point to point the length of the airframe. Add the autopilots ability to alter your trim and now you added another chunk of wire between the AP (or servo) and the trim system.
Expand this mess to the flaps (stuck switch, safety over speed protection, position and health).
Now the Lat Trim. Now the lights and strobe system.
Now we have an airframe that is as intelligent as an economy car but if wired traditionally it will not be a lightweight and there would be 100s of connections! I also don't want my control panel to look like a chrism *** tree. Too many things I should be looking at outside the windows. This is why I would love to see the existing EFIS guys integrate airframe sensors and actuators into an open system. They already own the prime real estate. Lets use it to the fullest.

So far I have investigated several RS-422/485 protocols, Ethernet, and CAN for my project. All of them can be made to work but only CAN was designed from the ground up for transportation systems. CANaerospace is also the only aviation standard that I can find being used by Boeing, Airbus, and other majors that can be properly scaled for our small airframes and budgets. I am installing a CAN system to control my lights, trim systems, and flaps. It is a single bus given that none of these systems will cause a catastrophic end to my flight. The radio stack, engine, and any other critical flight systems will be wired in a traditional manor. This is simply because I do not have the time to develop the twin bus system and test all the failure scenarios and build my airframe.



*Yes Ethernet guys, there is multi cast but that is even more overhead!
 
My take is on several buses due to legacy requirements. This is for the time being unavoidable.

Absolutely required:
RS232. NMEA and some COM/NAV COM radios. Also things like FLARM and PCAS.

Nice to have:
ARINC 429
Mainly for some autopilots but also for connection to NAV radios and GPS receivers (in particular the certified stuff).

Great potential but completely underutilised:
CAN bus, in particular the CAN-Aerospace implementation which is open standard and still alows for custom messages for special purposes. CAN is ideal for control networks (since it has been designed for that), is robust and tolerant and also does well on the EMI side of things due to slew rate control.

Ethernet, well...
Now, for high speed file transfer or data pipes ethernet is the obvious choice - but, I don't think this should form part of an avionics standard for smaller aircraft. If you need something like ethernet in a small aircraft, it would be most likely a small specialized application that would not have general use. It's likely going to be point to point. One item that has not been mentioned regarding ethernet: It can be a bugger when it comes to EMI unless you use glass fibre. I don't think ethernet has a place in an EFIS aimed at smaller aircraft.

Video feeds, which will become relatively common use in smaller aircraft soon (watch our space) are great for things like FLIR, "rear view", "forward view" for some tail draggers, flight path recording (down looking camera). Here you would like to stick with things like good old composite video (up to a point) to give you a vast range of cheap and high quality image sources to connect to your EFIS.

Rainier
 
Higher level protocol layers...

What I want from an ethernet setup is mostly the speed and simplicity. For most things I can imagine simple broadcast UDP will suffice. Since ethernet is well understood and easily available it seems like a good choice - sufficient high speed so that I don't have to worry about having enough bandwidth to do whatever I want. And, if I decide that I want to run more sophisticated protocols then that option is wide open to me.

Yes, ethernet TCP/IP does much more than we need and is not optimal for what we probably want here but the tradeoffs (overhead for simplicity) are worth it in my mind. I am also sort of assuming a dual redundant network and I am also assuming that normally this network will be very lightly loaded and that certain message forms will have high priority over others. What I *really* want is the high bandwidth of ethernet with a few modifications to allow for priority of messages and bus control. But another advantage of ethernet TCP/IP is that I can just plug in any laptop PC into the network to debug it.

But what I really want to explore is a set of protocol layers on top of the TCP/IP - I guess that would be the application layer. If I were to advocate ethernet TCP/IP for a bus architecture then I would want to have agreement about not only the form of the data exchanged (standard data formats for integers, floating points, text, etc) but also the types of messages that will be exchanged and the styles or types of message interactions that can be accomodated. I want any device - subsystem - whatever to be able to have certain conversations with any other device. For example:

1) what are you / this is what I am
2) what can you do / this is what I can do
3) what is your status / this is my status
4) what format do you want my data /provide your data in this format
5) send me the following data items on the following schedule

and so on. The idea is that no subsystem needs to know anything about any other system until the systems are powered up. Once powered up they will interact and exchange their startup and operating parameters and will discover each others capabilities. Smart flight management programs can then figure out what capabilities the aircraft has and assist the pilot appropriately.

I still like the idea of combining all of this with the CANaerospace bus - allow devices to be discovered and configured and interact via the ethernet and direct the CAN to be used for the lower level data transfers.

How might this style of avionics work? Well, each major subsystem would have two network jacks on the back. Installing the device is simply a matter of mounting it and connecting at least one network port to the network. Doesn't matter much which one. And then connect the power. Suppose you had the following units:

1) a comm/nav radio box
2) a flight management computer
3) two display panels
4) a transponder box
5) a gps receiver
6) a file server (holds map databases, etc)
7) an audio processor (like an audio panel but more)
8) a user interface panel (mounted near the center or right console, is configurable in realtime to allow the pilot to command the avionics)
9) a safety monitor computer (monitors bus traffic and can shutdown or restart failing system and alert the pilot to such)

(the only things that *need* to be on the control panel are the display computers)

When powered on, each subsystem advertises itself and either waits for someone else to ask for its services (like the radio) or it looks for devices it needs (like the flight management computer). Let's take the flight management computer (FMC). It is a plain box somewhere in the airplane (doesn't have to be behind the CP). It powers on and starts looking for displays, radios, NAV systems, transponders, a user interface device and a file server. By being able to query the other devices it finds out on the network it is able to configure itself to control the displays and accept input from the user interface panel and control the radios and transponder to serve the pilot - all without knowing anything beforehand about what equipment was installed in the airplane. By querying the file server it can get XML congfiuration files and flight plans in order to further setup the airplane as needed for the flight at hand.

The radios are software defined radios and simply transmit their audio streams as VOIP to the audio processor. Your headphones plug into the audio processor and the audio processor sends your digitized voice wherever it is needed. The audio processor is able to interact with the other devices just like the FMC does, so it knows that it needs to find radios and intercoms and cockpit voice recorders and how to ask around to find whatever is available.

If devices fail to power up or fail in flight then the system adapts without further interaction. Everything is simple plug and play. Everything knows how to interact with everything else in the airplane.

Every avionics device in the airplane then has typically at most five connections on the back: two ethernet ports, two CAN ports and a power connector (in addition to antennas and sensor/servo connections). And in many cases you would really need only two - the ethernet and the power. Want to add a new device to the airplane? Just physically mount it and connect two cables. Simple.
 
Last edited:
Thinking a bit smaller

John
I believe we are coming at this with different goals in mind. While it would be great to have all the manufactures conform to one standard I just don't see it happening anytime soon. I can see using Ethernet technology to feed a tablet computer from an image server or to capture a data stream from an existing EFIS or perhaps even a web cam. I do not see it moving into the extremities of the airframe to monitor and control actuators. The majors make it work with Ethernet hardware but I doubt the protocol or software they use looks much like regular Ethernet traffic.
My focus has been a neglected corner of the larger picture. Currently there are serviceable standards for basic avionics. Most of the EFIS guys already support them and have no reason to move forward.
What is lacking is airframe support. When it comes to the airframe I don't know of any homebuilt aircraft that is wired differently than a 1970's vintage automobile. Some have gone to solid state switches but the basic concepts of point to point power connections for each object and limited or no feedback still rules.
If you are making car payments, then it's a good bet that a CAN bus will alert you when your door is open or a lamp burns out. Further proof would be that the vast majority of engine control systems are CAN based.
I am sure that CAN is on the radar for the EFIS guys. Even if they never expand to the airframe they will need it for alternate engine technology. What would be nice is if they (like the automotive industry) could agree on a basic or at least compatible way of using the technology before it becomes as varied as the serial protocols in use today. If they can't we will be stuck with point to point wiring harnesses and crossing our fingers that the horse we bet on stays in business.
 
Interesting topic

Hi guys, in reading through your thoughts there is one thing that comes to mind in either case. I have used MIL-1553 (which I am not advocating here) but one fundamental feature was a "lightning" tolerant bus. It used transformer coupling and also prevented bus contention. One other thing is don't forget the following that I lifted from an CANaerospace web site.

CAN and safety critical applications:
Does it match?
? The probability of an undetected data corruption for CAN is around 1 * 10-13 per message
transmission. Assuming 100% bus load (around 8.000 messages per second at 1 Mbps),
this will result in a probability of 2.9 * 10-6 undetected failures per flight hour.
? While this figure is better than for most other bus system available today, it shows that
CAN (like all other buses) will require data bus redundancy for flight safety critical
systems, especially for those requiring fail-operational behaviour.
? The (hardcoded) CAN protocol has demonstrated excellent reliability in more than 100
million chips installed today. CAN networks are usually exposed to a harsh environment.
? Due to the high quantities the cost, size and weight of CAN interfaces is significantly
lower than that of any other bus system. Therefore, adding a second or even third bus for
redundancy will not cause unacceptable penalties.

When you start talking trim or other flight controls don't forget you need the ultimate in reliability. Also, don't forget that software can trump the best hardware around (don't ask me how I know ;-) I'm an EE) Remember it may not only be your bacon in that plane. The design needs to be solid.

Having said all that... keep up the brainstorming.

Paul
N694BP reserved.
 
jdeas said:
John
I am sure that CAN is on the radar for the EFIS guys. Even if they never expand to the airframe they will need it for alternate engine technology.
Click to expand...

Yes JD, you are quite correct.
What we are finding however, now that we are allready interfacing to engines via CAN (for example the new Rotorway engine), it seems that every manufacturer of engines bases their communications only very loosly on existing standards (like J1939) making the standard non-functional for all practical purposes.
This is sad.
We are using CAN engine monitoring in the following way:
As you know, we use a variety of remote engine monitoring modules we call "RDAC" (Remote data aquistion computer). We have expanded on this with a new little module we call uCAN. It looks like a RDAC to our systems but has a CAN interface (and RS232 just in case) on the other side. The uCAN is barely larger than a box of matches.

Right, what am I getting at ?
Well, we are going to make uCAN open source together with a sample application and we will even include a free custom compiler. Why ? We would like to give those that can (no pun intended) a chance to connect just about any CAN based engine monitor or control system - as long as they have basic programming skills and a knowledge of at least some of the CAN messages for their engines.
As the "other side" of the uCAN is also known, this can be used perhaps in future with some other EFIS systems as well (we don't mind).

Please note that we are keeping engine related CAN seperate from our CANAerospace link with is standard fit in our Odyssey, Voyager and (soon) Explorer systems.
Also you can connect up to two uCAN systems and still use one of our RDACs (in case you need to monitor something that is not available on the engines CAN bus).

But I am getting carried away. Post is too long. My appologies. Will stop now and go up for breakfast.

Rainier
CEO MGL Avionics
 
More than a common bus and more than servo control

What we need is a bus that gives us ethernet-like speed and bandwidth with the option of higher level protocols but simpler addressing. It looks like CANaerospace does not do the latter very well. What I am hoping for is a bus that gives 1553-like determinism and TCP/IP-like flexibility. In the absence of such a bus I am content to try and make ordinary ethernet meet my needs.

But what I also want is a system where components or subsystems can do more than just repetitively blast out a few parameters and where those parameters are not in message forms that are peculiar to each individual manufacturer. I want smarter subsystems - and an overall system-level protocol that allows subsystems to interact with each other. Just having a standard bus is not enough - we need a standard method of interaction between avionics units.

Keep in mind where I am coming from in my thinking here - I am assuming a clean technical slate here where much or most of the hardware has not been designed or invented yet. Before I got interested in aviation I was thinking about amateur radio, What I wanted there was a simple black box - no knobs or dials or meters on the front just a black box with an ethernet port and an antenna connector and a power connection on the back. Everything the radio does to the RF signals would go through the data port on the back leaving all the user interface to be handled by any PC you might have on the network. This would be in sharp contrast to what most amateur radio transceivers do now - they have a simple RS-232 connector on the back which allows a small subset of radio commands to be exchanged with the radio. Not too much you can do with an RS-232 port and that completely limts what you can do with the radio - it can pretty much only be a radio sitting on a desk being controlled by a human playing with its buttons and knobs.

Same thing with most modern avionics - as designed they can pretty much only sit on a front panel waiting for a pilot to push buttons. Perhaps they can output data in such a way as for that data to be used with a few other systems (like an autopilot) but the ability to interact with other systems that they were not designed for is almost non-existent. Even with modern airliners like the 787 the software architecture is frozen at system integration time - want to add a new subsystem? It will take months of engineering analysis and a new software release to support the new subsystem (which is understandable with an airliner undergoing FAA certification). This is in contrast to an architecture that is designed from the beginning to safely interact with any new subsystem - an architecture that specifies how subsystems interact with each other rather than one that simply says that they use a common bus.

So how does this relate to building and equipping and RV? Let's say I were to buy a new mode S ADS-B transponder. To use it, all I would have to do is mount it in the aircraft, connect the antenna, connect the power and connect the network. Since I already supposedly have a display system in the airplane and a mission computer of some sort I should just be able to turn on the avionics bus and see from the display that the mission computer found a transponder and a source/sink of ADS-B data and knows what to do with it. Then I want to go and fly.

--NM
 
Last edited:
Monolithic or subsystems

John,
As a programmer these are all cool ideas but somewhat impractical for a small group of engineers to safely implement. A monolithic design of this size would be very difficult to test all the failure modes in. What I would suggest is create a road map to where you want to go along with milestones where the subsystems can be installed and tested.
I decided to go CANaero. I still feel it is the most practical implementation for actuators and sensors in such a small airframe yet it is impractical for much else.
Using Ethernet for an image server or installing wireless for a tablet display are neat ideas. With the low cost solid state disk drives I don't see why this can't be done now. Approach plates, weather updates, etc could be funneled through such a system to the tablet and be a real benefit.
I would just rather see a CANaero to Ethernet firewall/bridge to keep the systems safe from each other.
 
jdeas said:
John,
As a programmer these are all cool ideas but somewhat impractical for a small group of engineers to safely implement. A monolithic design of this size would be very difficult to test all the failure modes in. What I would suggest is create a road map to where you want to go along with milestones where the subsystems can be installed and tested.
I decided to go CANaero. I still feel it is the most practical implementation for actuators and sensors in such a small airframe yet it is impractical for much else.
Using Ethernet for an image server or installing wireless for a tablet display are neat ideas. With the low cost solid state disk drives I don't see why this can't be done now. Approach plates, weather updates, etc could be funneled through such a system to the tablet and be a real benefit.
I would just rather see a CANaero to Ethernet firewall/bridge to keep the systems safe from each other.
Click to expand...

As I said at the beginning, I am working from a clean technical slate. And as another of my colleagues once said of avionics software, "I will go to any length to be lazy." What he meant by that was that it always paid off for him to solve the biggest problems he could in software.

And as I have also said, it's all about the architecture. Design a smart architecture and you can do orders of magnitude more than if you limit yourself to just fixing the smallest problems at hand. This is not a monolithic design I am talking about here, far from it. It is object oriented and allows the problem to be solved more easily by smaller better defined components. Testing an object oriented system is far easier than any other I am aware of. I don't see why it would be impractical - if I have the time and energy to do it I will.

For example, can I put a software defined radio (such as GNU Radio) on an embedded linux card and program it to automatically track VORs? Sure. And then I just have to write some code to implement the protocol dialogs I wrote about earlier. Since that code is largely portable between subsystems once I write it for one system I have it for most of the others. Can I write a skeletal FMS program working through the same protocol? Sure. So now with relatively little effort (weeks or months part time) I now have a rudimentary FMS talking to a automated NAV radio. Can I write something similar for a display computer? Sure, I've done that thing before. Again, not that big of a project.

I think the whole thing is quite do-able. Profitable? Well, if it were I'd quit my day job. But it would be a worthy technical acheivement...
 
We should both keep our day jobs

John,
I am talking clean slate here. I write a lot of Ethernet based software and very little CAN. I have Ethernet based controllers that I could just drop in. If anything I am spending much more time supporting a smaller simpler network topography based on fit, function, and simplicity.
When I started thinking about this project I was looking at Ethernet and POE. I can only relate that to the old saying ?If you only have a hammer, you tend to see every problem as a nail?. I may yet have Ethernet in my airframe but unless I have to cram a computer in my wingtip, I doubt it will expand past the fuse.
 
Software updates

I'm kind of old school when it comes to airplanes. Prior to finishing my -9, it had been over 10 years since I flew a plane with an electrical system. My 1941 T-craft didn't even have a starter, so being able to push a button and watch the prop spin was a big deal for me. Navigation was with a compass and a chart. Heck if you got lost or busted some airspace going 95 mph then you probably shouldn't be flying.

Now that the -9 is flying I have to keep software up to date on my EFIS, EMS, GSP, and both mags. That's a lot of 'stuff' to keep up with.

The GPS, EFIS, and EMS all interact, which causes me some concern. The EFIS and EMS lost connectivity for some reason (easy enough to reset) and I forced a reset on my GPS but forgot to change the output code back prior to going flying so it didn't communicate with my EFIS.

Now, if I had more things interacting on a bus, even the most minor of changes would require complete testing of every system and every function on every system prior to going flying. This is more important for those of you who go IFR (I'm VFR only) and personally, I would much rather fly than play with the CPU's in my plane. This from a 20+ year IT guy.

Flying for me is my escape, I hope not to bring too much of the office up there with me. That said, I do like the technology in my plane but don't really want to spend every second testing and upgrading it.

Just one guy's opinion.
 
Understanding your pain

Bill,
I feel your pain but consider the technology your using. Remeber Ethernet 10 years ago? What you are using in your aircraft may be even older.
Not playing with the settings is a primary reason for using a standard. I don't want to ask vendor X how to make their system work with Vendor Y and Z. If they are compliant it works:)
This thread started with a question, Can the EFIS guys use an open standard? If they did we would both win. No special setups, reduced wiring, and better system feedback
 
You must log in or register to reply here.