‘The expectations of life depend upon diligence; the artisan that would perfect his work must first sharpen his tools’


We are the beneficiaries of a fantastic technology that gives us a teaching tool second to none. There is a big BUT coming…….. BUT… the software that drives it always seems to be a ‘BETA’ version, constantly under development and often full of bugs and glitches.. Sometimes these bugs and glitches are obvious and sometimes not. Those that interfere with your lesson are a pain and sometimes force you to develop a ‘work around’ to get the lesson done. Generally customers don’t want to come back tomorrow and sometimes they can’t come back tomorrow so the pressure is on the get the job done regardless – even more pressure on the SFI.

Helicopter simulators are designed and certified to deliver a set flight envelope. The data is gathered from the real aircraft and used to programme the response of the simulator. This does not automatically mean that the sim can be flown to every corner of the flight envelope for the data for many ‘dark’ corners simply won’t be there, or at best will not be reliable enough to allow you, or anyone else, to assume that the end result will represent the way the real aircraft will behave.

Similarly, I am very nervous about introducing malfunctions that cannot be verified on the real aircraft. I have found that the sim can deliver erroneous responses and that can lead to negative training. There is tremendous scope for negative training if the sim’s replication of performance is unrepresentative yet such information is obviously a closely guarded secret because I have yet to come across any guidance on the matter. Maybe that has something to do with the rarity of Test Pilot interaction with the Sim Centre.

It is vital that the SFI is aware that he/she needs to check the facial expression and the hands of the flying pilot. This will give you a window into his handling technique and their mental state and allow the SFI to respond if there is too much pressure.  With the seating configuration in most simulators this may be difficult and regrettably this indicates how little the designer understands this subtle but vital ingredient in the teaching techniques required. The SFI is supposed to be strapped into his seat but this is wishful thinking as it is virtually impossible to teach whilst strapped in to the seat at the IOS. It’s simply not possible to see all you need to see.

Teaching is a task largely undertaken alone. As such it is difficult and sometimes impossible to reap the benefits from the experience of others. The task facing the SFI is no different in this respect. I would therefore like to share a few set-up and tips and tricks that I wish to contribute. I have learnt a few tricks from others over the last nine years so I know that I am not alone in developing my skills during these periods of splendid (near) isolation and trying to find ways to enhance my lessons.

As one who has been at this SFI lark for nearly ten years I think I can say that the case for a software reload before every lesson has been made without equivocation. The accumulation of software bugs during a lesson adds up so that as the day proceeds the chances of a glitch terminating your sortie increases.

The only problem with this strategy is that even the data reloading process can introduce bugs. If this is true, then simulator makers need to strive to improve the fundamentals of the computing systems used for their products. We have all suffered over the years from the vagaries of a Windows based system and it came as a bit of a shock to find that my simulators rely on that rather flaky system.