Take a DME, say a KN63
This lives (in my case) under the seat, and the reading displays on a KDI572
It also displays on both of my SN3500 EHSIs (top left)
The KN63 install manual (IM) obviously does not show the SN3500 connection – it is from the 1980s. It was installed under the Socata TC, not under an STC.
The SN3500 IM does show the KN63 connection and that IM is FAA approved. So one’s 6 o’clock is covered on that one – especially as I got a gold plated 337 field approval signed off by a US FSDO on that entire installation including the connection(s).
But, some claim, connecting anything to the output(s) of a piece of gear, anything not shown in its IM, is illegal.
Now take another case I have come across very recently.
The GTN750 AML STC requires a direct ARINC429 connection to the KFC225 autopilot, for LPV operation.
Yet Sandel have an FAA approved SN3500 IM which connects a generic LPV GPS (e.g. the GTN750) to the SN3500’s ARINC429 input, and the SN3500’s FCS (meaning: “autopilot”) analog outputs then drive the autopilot, totally transparently, for every valid SN3500 navigation signal (VOR, LOC, GS, LPV GS). It is a very neat approach, which avoids the usual ambiguities in how you use the autopilot for different nav sources.
One UK avionics shop (not one that is known for taking a “liberal” position) says this is not legal. Sandel say it is legal and I am strongly inclined to think they are right – because if they are wrong, every piece of avionics ever made, and no longer supported by updates to its IM (because it is obsolete, because the mfg cannot be bothered, because the mfg doesn’t want to support competitors, or obviously because the mfg cannot possibly document every possible connection to every possible compatible bit of kit) would be limited to connections to equipment of the same era, as shown in its now-orphaned IM, which is a patently absurd position. It would also stop innovation because nobody could bring out any avionics which connects to any pre-existing avionics…
At a simpler level, this argument has been used by some avionics installers to say it is illegal to bring out say the NMEA data coming out of a GPS, on a connector in the panel – because that connector is not shown in the GPS’s IM. They say only connections in the IM are permitted, and since the IM doesn’t list a DB9 connector
it cannot be done.
For additional amusement, one could argue that the AFMS for the DME now ought to be updated because its reading can be seen in more than one place The FSDO who did the field approval didn’t pick up on that one, but I am covered because they signed it off. (Obviously I am not going to write about something illegal ). But nobody is that anal.
Has aircraft certification gone completely up its own back orifice?
Has aircraft certification gone completely up its own back orifice?
It sure looks like it
One factor which deeply disturbs me is that such issues often are no longer resolvable with clear rules and regulations you can point a finger at but are subject to OPINION of either the maintenance organisation or worse the regulator. In which case, two identical airplanes with identical appliances installed can have totally different regulations applied to it.
No wonder headaches are becoming more common…
One factor which deeply disturbs me is that such issues often are no longer resolvable with clear rules and regulations you can point a finger at but are subject to OPINION of either the maintenance organisation or worse the regulator.
The way this has been traditionally handled in US (FAA regulated) aviation is to have just a few unambiguous rules which do not attempt to dive down into every detail. You can’t argue about rules that don’t exist. Commercial companies then use creativity to come up with the best solution and otherwise the courts figure out individual issues when (and if!) it proves necessary. Problems arise when the regulations, and regulators, go too deep.
The traditional Germanic approach may be slightly different than that described Whatever works for you
I think the term “illegal” is the wrong one to use. If two devices interconnect, their interconnection is either covered in the STC of one or the other device. If not, then the data may not be approved data. To get it as approved data, a different process is required which in most cases is the field approval method, although other methods of obtaining approved data are acceptable. Then there is always the question if it is a major or minor modification, as the latter only requires a log book entry. Garmin deals with some of these issues by specifically listing the requirements, for example autopilot interface for autopilots not listed in the install manual/ They do the same for audio panels and some other interfaces.
In the case of interfacing the GTN to the KFC225 autopilot, Arinc 429 for GPSS is a good thing. However, the KFC225 uses the standard analog signals for all navigation except when in GPS mode and Arinc label 121 is available. The KFC225 does not support LPV or any GPS vertical guidance when it detects GPS as the CDI source, so it has to be faked out to believe it is flying an ILS. An alternative discrete signal from the GPS is used for this purpose. The KFC225 also detects the change of source between GPS and simulated Localizer and disconnects approach navigation and goes to ROL/PITCH mode. As a result, to obtain certification with this autopilot to fly a GPS vertically guided approach, the GPS has to be configured for Prompt mode operation. Prompt mode causes a message prompt to occur when a GPS vertical guidance is available, which normally occurs when the FAF becomes the active fix. The pilot must then select the GPS to assert the simulated localizer/GS signals and only then may the pilot command the KFC225 into approach mode. So, I think it would take some analysis to determine if what you want will work. Regardless, unless you add the GPSS capability into the Sandel, I would never disable the built in KFC225 capability. Once a pilot flies with roll steering, particularly with a WAAS GPS, it seems like going back to the stone ages if it isn’t available, auto-slew capability not withstanding.
The SN3500 has roll steering as a firmware option, which converts the ARINC429 roll steering commands into the analog deviations.
On the face of it I can’t see any difference between the resulting behaviour (I mean turn performance) using this, and the behaviour if using a direct GPS-KFC225 connection. AFAICT in both cases the autopilot merely converts the ARINC429 roll data into a roll angle.
The SN3500 roll steering feature works only with an ARINC429 GPS, so they probably just pass the data through
Then there is always the question if it is a major or minor modification, as the latter only requires a log book entry.
Garmin deals with some of these issues by specifically listing the requirements, for example autopilot interface for autopilots not listed in the install manual/ They do the same for audio panels and some other interfaces.
The big question is: are those connections the only ones permitted? And if so, what exact wording in the IM says that, and achieves that as a prerequisite for the STC validity, and isn’t present in every other IM for every other bit of avionics?
You will never know until you fly with roll steering. Auto slew does not have near instant wind correction including rolling out on the wind corrected course the first time without the S turns. It also doesn’t follow curved paths and in particular, it only follows paths defined by the CDI, The roll steering will follow non CDI defined curved paths. It does a marginally acceptable job with turn anticipation, but can’t adjust the path for conditions.
Regardless, roll steering isn’t the reason that I would be concerned with using the Sandel to fly the LPV or LNAV+V vertical guidance.
What would concern you, NCYankee?
This isn’t auto-slew (which I already have) – this is roll steering via ARINC429.
What would concern me is the conflict between GPS and fake ILS that the autopilot requires. This is handled by an additional discrete signal from the GPS. The Sandel would not generate it from the Arinc data. The FAA specifically held up the WAAS vertical guidance with the KFC225 and KAP140 over this issue. One can hook it up to a GNS or GTN and fake the signal without configuring the GPS for Prompt, but as soon as the autopilot detects the source change when the FAF becomes the active fix, the autopilot will disconnect APR mode. One can press the APR button a second time and the autopilot will follow the guidance from that point, but this is considered unacceptable by the FAA, hence the invention of the additional discrete signal and Prompt mode operation of the GPS. There is a separate check mark that applies to the GNS/GTN AFMS when the KFC225/KAP140 autopilot is used.
I spoke to Sandel in detail.
It turns out that the GTN750 puts up a prompt asking if you want to fly the (LPV) approach and you have to confirm that, and it then removes the discrete “GPS active” signal going to the KFC225 so the KFC225 thinks it is flying an ILS – which AIUI is basically what you were saying, NCYankee.
Interestingly, in roll steering mode, the autopilot is in the HDG mode the whole time – enroute and approach. Not NAV mode, like one does with older avionics.
But this was a bit of a digression… I still don’t get the rules on interconnecting equipment not shown in the IM. There cannot be a general prohibition on it, otherwise (as I say above) no new equipment could ever be introduced on the market. So it seems to me that some installers invent prohibitions as it suits them.
Most avionics list give some suggestions for connecting certain equipment, in my opinion it would that be possible to use other (equivalent) equipment.
Other times the installation manuals lists the ONLY equipment that can be used (without additional certification). If that is the case additional certification is required.