Thanks for the response. Let me offer some ideas and comments to consider. First, I do have a concept on how to measure system latency; however, I was hoping that there would be an easier approach. Here's what I mean: Prepar3D, if I consider it a "blackbox" closed system, should have quantifiable data from Lockheed on system latency. Obviously, the "time" it takes for the system (P3D) to output a response is a function of hardware (PC) processing which Lockheed has no control but can be measured based P3D's minimum PC system requirements. In other words, based on your minimum computer requirements, can P3D take an input from an USB device (assuming standard device such as USB 2.0) and deliver a response within the 300 mS ATD requirement? I would say it would be very easy for Lockheed to measure this since you are directly dealing with the P3D source code. For example, using a PC at the specified minimum performance requirements, a step input is made into an axis at time0, at some "recognizable" threshold, a change is noted at time1. The difference in time is the latency. This could be published. I believe that ESP published a conformity statement for someone based around this concept already. I have it somewhere.
I believe USB sends its data at about 250 Hz (I could be wrong) but my guess is that it is fast. In our CPT, there are no accessible USB connectors to "pull" so I'm not sure what an inspector would "pull" to get a notification. I think that such is an irrelevant test. Say I have a pitch potentiometer connected to to USB controller which is faithfully reporting to the PC the pitch control position and then the wiper randomly fails and physically disconnects. The input now floats to some level but the USB just keeps reporting, but no "notification" would be given by the "monitoring system" - it's just a pitch change not a loss of a USB device.
I'm not an expert on the AC, but I can only find the requirement for start-up tests and no requirement beyond the start-up test. After running, the following applies:
"Remain in the approved configuration during the training session. Authorized ATD instruction may not proceed after a malfunction of the ATD system has occurred. The operator must correct the ATD malfunction and repeat the start-up test described in paragraph c of this section before resuming authorized instruction."
As far as I can tell, the AC does not require that the system report the error after start-up. The key words are "...during the training..." and that if a malfunction occurs you can't continue until it's fixed. I also can't find a requirement in the AC that swapping USB ports must be accommodated. I can think of many sims that have no accessible USB cables. I'd be asking the inspector to show me where that requirement exists.
From a customer position, it doesn't seem that the customer should prove to Lockheed that its software has latency less than 300 mS. I'd like to suggest that Lockheed measure and publish the latency based on P3D's minimum PC requirements. I's also like to suggest that your team look at enhancing P3D to have a self-test function at start-up similar to X-plane Professional. This would solve certification barriers, add a dimension to your product line, and minimize a need and costs to send out people an ATD manufacturer to validate test data. It seems that what is said requires that the ATD manufacturer now has to prove the compliance to both Lockheed and the FAA if they want to use P3D. Those are big barriers.
I love the product but I need an easy solution for qualification. Please feel free to correct any misunderstandings that I have or errors in my analysis. |