Flt Simulation
N4790P
Thread Starter
Flt Simulation
I have been involved with flight simulation for over 34 years (hence the handle ZFT – zero flight training) and have experienced the tremendous improvements in both fidelity and reliability.
What aspects of modern (level D standard) flight simulators would you, the ultimate end user like to see improved and what additional features would enhance training?
Thank you.
What aspects of modern (level D standard) flight simulators would you, the ultimate end user like to see improved and what additional features would enhance training?
Thank you.
Guest
Posts: n/a
Hi, ZFT.
I was in a 747-400 simulator a few years ago and it didn't appear to simulate the ability of the IRS's to operate in ATT mode in the air after NAV had been lost. Not sure if it was a level D sim tho'. Is this kind of thing difficult to simulate?
Cheers.
Q.
I was in a 747-400 simulator a few years ago and it didn't appear to simulate the ability of the IRS's to operate in ATT mode in the air after NAV had been lost. Not sure if it was a level D sim tho'. Is this kind of thing difficult to simulate?
Cheers.
Q.
ZFT
I'm surprised that you haven't had one of the more recent complaints about Sim fidelity (or lack of it), the lack of representative sound and vibration cues following engine failure. I seem to recall that one particular real-life incident (UAL?) caused concern in that the crew reported that they had not previously experienced the disorientation effects of very heavy vibration, both physical and visual. Given the standard motion systems in use I suspect that to introduce such effects would place a very heavy burden on the mechanical side of things. Such high frequency direction reversals on the jacks whether they are hydraulic or electrical would, I imagine, be difficult to implement but, impossible???.... I would appreciate your comments.
I'm surprised that you haven't had one of the more recent complaints about Sim fidelity (or lack of it), the lack of representative sound and vibration cues following engine failure. I seem to recall that one particular real-life incident (UAL?) caused concern in that the crew reported that they had not previously experienced the disorientation effects of very heavy vibration, both physical and visual. Given the standard motion systems in use I suspect that to introduce such effects would place a very heavy burden on the mechanical side of things. Such high frequency direction reversals on the jacks whether they are hydraulic or electrical would, I imagine, be difficult to implement but, impossible???.... I would appreciate your comments.
Join Date: Dec 2002
Location: Sussex
Posts: 225
Likes: 0
Received 0 Likes
on
0 Posts
Interesting points. The fact that ATT does not work is either an oversight or shoddy programming. All it requires is to stop the part of the IRS software which updates the nav solution and clear down a few validity flags.
Some years ago I was involved in producing an engine seize malfunction for a military sim. There was a blood curdling graunch and the motion nearly tore itself out of the floor. Had the occupants not been strapped in and wearing bonedomes, there would have been injuries. We were rather pleased with ourselves. Off to site and the mod was installed and submitted to the customer for approval. "Do you like it" says us. "Oh yes indeed" says the customer. "Is it realistic" asks us. "Dunno, never happened in real life" Says the customer.
Basically, there are two ways of getting the information to simulate something -
1/. A mass of instrumentation is installed in the aircraft then you go flying and actually carry out the event.
2/. You ask lots of people what it feels like. You then produce something based on an average of the answers. This is then submitted to customers and is tuned until they are happy.
In the case of an engine catastrophic failure, no one seems keen to let us use method one, and method two is not good because of it's subjective nature. What usually happens is that you can please one pilot but another is less happy. Everyone tends to have a slightly different slant on what should happen.
Still it's fun trying
Some years ago I was involved in producing an engine seize malfunction for a military sim. There was a blood curdling graunch and the motion nearly tore itself out of the floor. Had the occupants not been strapped in and wearing bonedomes, there would have been injuries. We were rather pleased with ourselves. Off to site and the mod was installed and submitted to the customer for approval. "Do you like it" says us. "Oh yes indeed" says the customer. "Is it realistic" asks us. "Dunno, never happened in real life" Says the customer.
Basically, there are two ways of getting the information to simulate something -
1/. A mass of instrumentation is installed in the aircraft then you go flying and actually carry out the event.
2/. You ask lots of people what it feels like. You then produce something based on an average of the answers. This is then submitted to customers and is tuned until they are happy.
In the case of an engine catastrophic failure, no one seems keen to let us use method one, and method two is not good because of it's subjective nature. What usually happens is that you can please one pilot but another is less happy. Everyone tends to have a slightly different slant on what should happen.
Still it's fun trying
N4790P
Thread Starter
Thanks for the constuctive responses.
QAVION
On any level C or D simulator, systems simulation should be perfect. On today’s simulators the simulator manufacturers tend to run the same code as the aircraft computers, albeit on a different hardware platform. As a consequence the simulation should behave identically to the aircraft. Even on older simulators, there is no excuse for less than perfect systems simulation, although this requires far greater attention to detail by both the design engineer and the acceptance pilot to ensure simulator characteristics are as aircraft.
As Synthetic stated, Level D performance characteristics are solely dependant upon the quality/availability of accurate data. Today, there are, in my humble opinion only 2 areas of civil simulation that are not possible to replicate, namely sustained G forces and physical pressurisation cues. All other aspects are just a matter of cost as the technology is available.
Cornish Jack
The engine incident you refer to is in some ways a similar situation to unusual attitude training. No airframe manufacturer will or possible can provide real flight test data and therefore the airframe manufacturer provide engineering test data for the sim manufactures in conjunction with their customers to programme what they believe to be a realistic/representative scenario. Although in this specific case one would hope that the FDR information has been utilised to enhance catastrophic engine failure simulation. (UAL has a particularly well respected sim engineering group and I would imagine that they have already addressed this. Perhaps a UAL –400 pilot would comment)
There are two another engine related area of simulation that I think are particularly poor. On current Level D turboprop simulators propeller aerodynamic simulation, especially during pitch changes and engine failures tends to be unrepresentative. And on all simulators, slip ball simulation is basically cr*p. Again these are airframe manufacturers data issue.
QAVION
On any level C or D simulator, systems simulation should be perfect. On today’s simulators the simulator manufacturers tend to run the same code as the aircraft computers, albeit on a different hardware platform. As a consequence the simulation should behave identically to the aircraft. Even on older simulators, there is no excuse for less than perfect systems simulation, although this requires far greater attention to detail by both the design engineer and the acceptance pilot to ensure simulator characteristics are as aircraft.
As Synthetic stated, Level D performance characteristics are solely dependant upon the quality/availability of accurate data. Today, there are, in my humble opinion only 2 areas of civil simulation that are not possible to replicate, namely sustained G forces and physical pressurisation cues. All other aspects are just a matter of cost as the technology is available.
Cornish Jack
The engine incident you refer to is in some ways a similar situation to unusual attitude training. No airframe manufacturer will or possible can provide real flight test data and therefore the airframe manufacturer provide engineering test data for the sim manufactures in conjunction with their customers to programme what they believe to be a realistic/representative scenario. Although in this specific case one would hope that the FDR information has been utilised to enhance catastrophic engine failure simulation. (UAL has a particularly well respected sim engineering group and I would imagine that they have already addressed this. Perhaps a UAL –400 pilot would comment)
There are two another engine related area of simulation that I think are particularly poor. On current Level D turboprop simulators propeller aerodynamic simulation, especially during pitch changes and engine failures tends to be unrepresentative. And on all simulators, slip ball simulation is basically cr*p. Again these are airframe manufacturers data issue.
Guest
Posts: n/a
"The fact that ATT does not work is either an oversight or shoddy programming. All it requires is to stop the part of the IRS software which updates the nav solution and clear down a few validity flags. "
As I understand it, Synthetic, IRU's will not give you an accurate ATTitude indication unless you are flying relatively straight and level for a certain period of time. Would a D level sim programmer have to model the IRU's to this sort of detail level (showing slight errors in attitude if the aircraft had not been flying straight and level). Or is this what you meant by "nav solution"?
A few years ago, I wanted to see what would happen on a real aircraft when selecting from OFF to ATT whilst in motion (to see what sort of displays I would get). I tried selecting ATT whilst an aircraft was being towed from one gate to another. During the period from selecting from OFF (to ATT) to the horizon appearing on the displays, the aircraft made a sharp right turn. As I recall, the attitude display took about about 45 seconds or more to appear. The displays, without motion, normally take about 30 seconds to appear, so the radical movement , I suspect, was confusing the IRS's. Disappointingly, the horizon showed no abnormalities when it did appear (I was hoping for a 45 degree tilt) Perhaps IRS's in reality don't display a correct horizon unless you have been flying straight and level for some time?
Anyway, I think I'm moving a bit off topic here, so...
Cheers.
Q.
As I understand it, Synthetic, IRU's will not give you an accurate ATTitude indication unless you are flying relatively straight and level for a certain period of time. Would a D level sim programmer have to model the IRU's to this sort of detail level (showing slight errors in attitude if the aircraft had not been flying straight and level). Or is this what you meant by "nav solution"?
A few years ago, I wanted to see what would happen on a real aircraft when selecting from OFF to ATT whilst in motion (to see what sort of displays I would get). I tried selecting ATT whilst an aircraft was being towed from one gate to another. During the period from selecting from OFF (to ATT) to the horizon appearing on the displays, the aircraft made a sharp right turn. As I recall, the attitude display took about about 45 seconds or more to appear. The displays, without motion, normally take about 30 seconds to appear, so the radical movement , I suspect, was confusing the IRS's. Disappointingly, the horizon showed no abnormalities when it did appear (I was hoping for a 45 degree tilt
) Perhaps IRS's in reality don't display a correct horizon unless you have been flying straight and level for some time?Anyway, I think I'm moving a bit off topic here, so...
Cheers.
Q.
Join Date: Dec 2002
Location: Sussex
Posts: 225
Likes: 0
Received 0 Likes
on
0 Posts
Would a D level sim programmer have to model the IRU's to this sort of detail level?
When I made the comment about ATT, I was thinking of the case of the IRU being switched from NAV to ATT, which is a slightly different case. In this case the platform has already been aligned. In your case the platform is forced to align while in motion, which is less accurate, and further degraded by acceleration of the aircraft. Once again, I would expect the sim to reflect this.
In my parlance, the Nav Solution is aircraft position, velocity etc calculated from all of the various nav sensors. By selecting ATT, that particular platform is removed from the calculation
Do a Hover - it avoids G
Join Date: Oct 1999
Location: Chichester West Sussex UK
Age: 91
Posts: 2,206
Likes: 0
Received 0 Likes
on
0 Posts
ZFT
Personally, if I was king for a day I would have all level D sims freeze as the sim went outside the envelope for which the aircraft is cleared. Two reasons for this:
1 To get the attention of the crew in case they did not realise what they had done
2 To stop people using sims to establish what will happen to the aircraft outside the envelope when there is no guarantee that the sim is valid in such circumstances.
I sympathise with Cornish Jack’s need for off putting levels of vibration to be simulated. One US chopper sim I flew did this by shaking the seats rather than the whole cab. You can get very good fidelity like that with minimal mechanical engineering.
Personally, if I was king for a day I would have all level D sims freeze as the sim went outside the envelope for which the aircraft is cleared. Two reasons for this:
1 To get the attention of the crew in case they did not realise what they had done
2 To stop people using sims to establish what will happen to the aircraft outside the envelope when there is no guarantee that the sim is valid in such circumstances.
I sympathise with Cornish Jack’s need for off putting levels of vibration to be simulated. One US chopper sim I flew did this by shaking the seats rather than the whole cab. You can get very good fidelity like that with minimal mechanical engineering.
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes
on
0 Posts
John
Would it not be more logical to freeze the sim when outside the envelope for which the sim has been validated rather than that for which the aircraft is cleared, the two being by no means the same thing. If, as you said, you were allowed to...
Would it not be more logical to freeze the sim when outside the envelope for which the sim has been validated rather than that for which the aircraft is cleared, the two being by no means the same thing. If, as you said, you were allowed to...
Do a Hover - it avoids G
Join Date: Oct 1999
Location: Chichester West Sussex UK
Age: 91
Posts: 2,206
Likes: 0
Received 0 Likes
on
0 Posts
Mad (Flt) Scientist
Sure. Totally agree.
But I do question whether sims really are properly validated outside the flight envelope of the aircraft. Any more than aircraft are flown beyond the design envelope except by chance or error.
The bottom line for me is that with both sims and aircraft a few data points outside the fully investigated envelope don't equal complete knowledge.
But I am sure you know what I mean.
After Nick Warner and his crew were killed in the A330 at Toulouse they found a software routine in part of the autopilot control laws that had up elevator being applied to try to get to a selected height, regardless. And regardless in this context meant even it took the aircraft down to an unflyable speed. The guy who wrote that was acting in isolation. If that can happen in the world's leading organisation for developing such flight software what chance is there that sim programmers don't draw straight lines (or any other unjustified extrapolation that they find handy) when outside the envelope that they believe matters.
Sorry, rant over!
Regards
John
Sure. Totally agree.
But I do question whether sims really are properly validated outside the flight envelope of the aircraft. Any more than aircraft are flown beyond the design envelope except by chance or error.
The bottom line for me is that with both sims and aircraft a few data points outside the fully investigated envelope don't equal complete knowledge.
But I am sure you know what I mean.
After Nick Warner and his crew were killed in the A330 at Toulouse they found a software routine in part of the autopilot control laws that had up elevator being applied to try to get to a selected height, regardless. And regardless in this context meant even it took the aircraft down to an unflyable speed. The guy who wrote that was acting in isolation. If that can happen in the world's leading organisation for developing such flight software what chance is there that sim programmers don't draw straight lines (or any other unjustified extrapolation that they find handy) when outside the envelope that they believe matters.
Sorry, rant over!
Regards
John
Join Date: Nov 2002
Location: middle east
Posts: 101
Likes: 0
Received 0 Likes
on
0 Posts
ZFT
I would like to see sims with a better representation of inertia. It is difficult to quantifly, but i dont believe that a 3 or 400 tonne aircraft can change direction/attitude as quickly as happens in the sim.
This can also be witness during a crosswind landing. In a real heavy, you can fly into the flare crabbed, then kick it straight with rudder and keep the wings level with aileron and the aircraft will track straigh for a short time due to inertia. In our sims it seems that the aircraft drifts immediately.
Another area is the EFATO. The rolling and yawing rates that are generated by non violent control inputs do not seem to be consistent to what you see when flying the line. Once again i cannot quantify this as i have not had a real engine failure yet on this jet.
In my previous company i had much better knowledge of this area, and the sim was nothing like the aircraft, but that was a much lower level of sim, so my observation are not valid for current simulators.
Doug
I would like to see sims with a better representation of inertia. It is difficult to quantifly, but i dont believe that a 3 or 400 tonne aircraft can change direction/attitude as quickly as happens in the sim.
This can also be witness during a crosswind landing. In a real heavy, you can fly into the flare crabbed, then kick it straight with rudder and keep the wings level with aileron and the aircraft will track straigh for a short time due to inertia. In our sims it seems that the aircraft drifts immediately.
Another area is the EFATO. The rolling and yawing rates that are generated by non violent control inputs do not seem to be consistent to what you see when flying the line. Once again i cannot quantify this as i have not had a real engine failure yet on this jet.
In my previous company i had much better knowledge of this area, and the sim was nothing like the aircraft, but that was a much lower level of sim, so my observation are not valid for current simulators.
Doug
Join Date: Feb 2000
Location: Montreal
Posts: 116
Likes: 0
Received 0 Likes
on
0 Posts
I'd be happy if they could even get the basic stuff to work like a real aircraft! I just spent five weeks wrestling with a supposedly level D sim that would not fly an ILS to 200' minimums if any turbulence was insertedl! Not to mention the fact that any resemblance between the ground handling of the sim and the aircraft was purely limited to the fact that the controls actually moved in the correct direction when inputs were made.
Right now (as I understand it) the builders of the sims acquire a "data package" or somesuch for each given aircraft that is supposed to give them all they need to program in all the whozits and whatzits to do their job. Anything outside this, they just seem to go with what makes sense. As a consequence, the same malfunction programmed into two different sims (sometimes those from a different company) can give drastically different warnings, etc.
Somehow the "governing bodies" don't know much about this as they will happily certify based mainly on what the data pack says. I've seen some really basic stuff (like even a gen fail, or a gearbay overheat, or ADC failure) on certified sims give indications that don't even match the basic parameters of what any groundschool graduate has learned.
How does this stuff get by? I realize that there is stiff competition in this industry, but why not make certain things universal (although I hate to suggest that the governments should involve themselves)for a given type and make it mandatory that it be included as a part of the flight parameters?
But of course that's just the rantings of somebody who's been away from home too long...........
Right now (as I understand it) the builders of the sims acquire a "data package" or somesuch for each given aircraft that is supposed to give them all they need to program in all the whozits and whatzits to do their job. Anything outside this, they just seem to go with what makes sense. As a consequence, the same malfunction programmed into two different sims (sometimes those from a different company) can give drastically different warnings, etc.
Somehow the "governing bodies" don't know much about this as they will happily certify based mainly on what the data pack says. I've seen some really basic stuff (like even a gen fail, or a gearbay overheat, or ADC failure) on certified sims give indications that don't even match the basic parameters of what any groundschool graduate has learned.
How does this stuff get by? I realize that there is stiff competition in this industry, but why not make certain things universal (although I hate to suggest that the governments should involve themselves)for a given type and make it mandatory that it be included as a part of the flight parameters?
But of course that's just the rantings of somebody who's been away from home too long...........
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes
on
0 Posts
Data Packages
Our practice as an OEM is to supply the "minimum" ATG cases as part of the data package. We will also flight match the aerodynamic model to the limits of the available aircraft certification data, recognising that the ATG cases are only a sample of the aircraft. We will also provide additional proof of match data as part of the package to validate any unusual characteristics we think might prove contentious during qualification of the sim.
(I'm mainly talking about the flight model here; I'm not so familiar with our systems simulation approach, and that is certainly more fraught with problems of configuration control; generally once the aircraft is in test the likelihood of a significant change to the basic aerodynamics is small, and we can use most if not all of the developemt data to build our models. Systems may still be evolving up to (or even beyond) the certification date, so there's never really a firm, fixed basis for the systems side of the work.)
To some extent the sim manufacturer has to use "seat of the pants" to fill out the inevitable holes in our data; they know (or should) what sort of thing works for training purposes for cases where we will never have the data. To some extent it's an emperor's new clothes situation, in that past practice ends up validating what you do next, because it 'works'. But that's pretty much a definition of engineering
.
While there are undoubtly things the authorities could do better - and not always in the direction of requiring more validation, there are things they could do to make everyone's job a lot easier while sacrificing nothing in terms of fidelity - there is, of course, a qualitative eval by the authorities, it's not just a matter of matching a few manoeuvres and ticking the box. Of course, if the eval pilot has a different opinion as to how things should be than anyone else.....
(I'm mainly talking about the flight model here; I'm not so familiar with our systems simulation approach, and that is certainly more fraught with problems of configuration control; generally once the aircraft is in test the likelihood of a significant change to the basic aerodynamics is small, and we can use most if not all of the developemt data to build our models. Systems may still be evolving up to (or even beyond) the certification date, so there's never really a firm, fixed basis for the systems side of the work.)
To some extent the sim manufacturer has to use "seat of the pants" to fill out the inevitable holes in our data; they know (or should) what sort of thing works for training purposes for cases where we will never have the data. To some extent it's an emperor's new clothes situation, in that past practice ends up validating what you do next, because it 'works'. But that's pretty much a definition of engineering
.While there are undoubtly things the authorities could do better - and not always in the direction of requiring more validation, there are things they could do to make everyone's job a lot easier while sacrificing nothing in terms of fidelity - there is, of course, a qualitative eval by the authorities, it's not just a matter of matching a few manoeuvres and ticking the box. Of course, if the eval pilot has a different opinion as to how things should be than anyone else.....
N4790P
Thread Starter
John Farley
<< Personally, if I was king for a day I would have all level D sims freeze as the sim went outside the envelope for which the aircraft is cleared.>>
John, on just about every sim I’ve even been involved with there is just this freeze function. For want of a better description, ‘Recoverable Crash’ parameters such as excessive G, IAS, Mach, Taxi speeds, Tailstrikes and ‘Irrecoverable Crash’ parameters such as excessive pitch/bank/side force at touchdown are monitored. Typically a Crash page is displayed on the Instructors station when any parameter is exceeded and if not inhibited by Instructor selection, the sim freezes.
Unfortunately from my observations, most instructors do indeed inhibit this feature.
Whilst I have never seen the vibrating seat you describe, it was fairly common for helicopter sims to mount the cockpit on a frame separate from the normal base frame and use a small jack to provide the vibration effect independent of the motion jacks.
Doug
I’m not a Flyt expert. Maybe Mad Scientist who is would respond. Interestingly, whilst there is a tolerance for inertia in sim specs, I can’t seem to find any reference to it in JAR-STD-1A.
All axis rates really should be very representative. As you state, most line pilots will never experience actual engine failures and sim training in this area is their only exposure to this.
Elliot
Appears your sim experience understandably was not a happy one. Sims that perform like this should not remain in service as negative training is received. What does surprise me is that your TRI/TRE didn’t do something about it.
Your comments on systems simulation are very valid. As has been stated before on this thread, there is no excuse for anything less than perfect simulation in these areas. How does this get by? I really don’t know. Assuming it was never correct, the blame must rest jointly between the sim manufacturer, the acceptance team and the initial certification team.
If however the sim fidelity has deteriorated, then my own discipline is solely to blame.
I am very surprised that the sim instructors do not do something about it.
As for your rantings. I disagree. Your comments are entirely justified. Hope you get home soon.
<< Personally, if I was king for a day I would have all level D sims freeze as the sim went outside the envelope for which the aircraft is cleared.>>
John, on just about every sim I’ve even been involved with there is just this freeze function. For want of a better description, ‘Recoverable Crash’ parameters such as excessive G, IAS, Mach, Taxi speeds, Tailstrikes and ‘Irrecoverable Crash’ parameters such as excessive pitch/bank/side force at touchdown are monitored. Typically a Crash page is displayed on the Instructors station when any parameter is exceeded and if not inhibited by Instructor selection, the sim freezes.
Unfortunately from my observations, most instructors do indeed inhibit this feature.
Whilst I have never seen the vibrating seat you describe, it was fairly common for helicopter sims to mount the cockpit on a frame separate from the normal base frame and use a small jack to provide the vibration effect independent of the motion jacks.
Doug
I’m not a Flyt expert. Maybe Mad Scientist who is would respond. Interestingly, whilst there is a tolerance for inertia in sim specs, I can’t seem to find any reference to it in JAR-STD-1A.
All axis rates really should be very representative. As you state, most line pilots will never experience actual engine failures and sim training in this area is their only exposure to this.
Elliot
Appears your sim experience understandably was not a happy one. Sims that perform like this should not remain in service as negative training is received. What does surprise me is that your TRI/TRE didn’t do something about it.
Your comments on systems simulation are very valid. As has been stated before on this thread, there is no excuse for anything less than perfect simulation in these areas. How does this get by? I really don’t know. Assuming it was never correct, the blame must rest jointly between the sim manufacturer, the acceptance team and the initial certification team.
If however the sim fidelity has deteriorated, then my own discipline is solely to blame.
I am very surprised that the sim instructors do not do something about it.
As for your rantings. I disagree. Your comments are entirely justified. Hope you get home soon.
Join Date: Dec 2002
Location: Sussex
Posts: 225
Likes: 0
Received 0 Likes
on
0 Posts
Reading between the lines of what is becoming a very interesting thread, I think the problem may lie in the way that sims are procured. There is obviously the impossible (sustained G motion effect) and the imponderable (sim performance outside the explored), but these only accounts for a very small number of niggles about sims.
In my experience, the situation usualy involves knowledgeable Aircrew who know what they want, and engineers who for the most part, are capable people who take a pride in getting it right. Ideal situation - what can go wrong? Well almost invariably there are at least two layers of bean counters involved in the equation.
I have always found that the shorter the line of communication I have with the end user, the better the job turns out.
Another problem is is the shear magnitude of the task of laying down the exact specifics of every single function of anything as complex as a simulator. May be a solution would be to have 'bedding in' period post acceptance. I think to be fare to both sides, this would have to be chargeable to the customer, but any design change/update required during that time would be at nominal cost rather than at full market premium.
In my experience, the situation usualy involves knowledgeable Aircrew who know what they want, and engineers who for the most part, are capable people who take a pride in getting it right. Ideal situation - what can go wrong? Well almost invariably there are at least two layers of bean counters involved in the equation.
I have always found that the shorter the line of communication I have with the end user, the better the job turns out.
Another problem is is the shear magnitude of the task of laying down the exact specifics of every single function of anything as complex as a simulator. May be a solution would be to have 'bedding in' period post acceptance. I think to be fare to both sides, this would have to be chargeable to the customer, but any design change/update required during that time would be at nominal cost rather than at full market premium.
Interesting point re. the dreaded 'bean counters'. In another life,I was constantly puzzled to find that setting a particular IRS fault was not producing the specified result. It was a long time before a casual remark by one of the Sim Dev engineers revealed the reason.
Because the IRUs were aircraft units, it had been decided to use only two instead of three to save money. The third IR was simulated by software which gave most of the required operating indications BUT NOT the SINGLE unit failure indications - that always came up as a DOUBLE unit failure. Not life threatening, perhaps, but quite frustrating for some time.
In conversation with one of the managers I tried to make the point of the necessity of expenditure on quality training and not cutting corners. I'll leave you to guess the reaction.
It ought to be unnecessary to point out that the cost of poor quality training is measured in body bags.
Because the IRUs were aircraft units, it had been decided to use only two instead of three to save money. The third IR was simulated by software which gave most of the required operating indications BUT NOT the SINGLE unit failure indications - that always came up as a DOUBLE unit failure. Not life threatening, perhaps, but quite frustrating for some time.
In conversation with one of the managers I tried to make the point of the necessity of expenditure on quality training and not cutting corners. I'll leave you to guess the reaction.
It ought to be unnecessary to point out that the cost of poor quality training is measured in body bags.
Join Date: Feb 2000
Location: Montreal
Posts: 116
Likes: 0
Received 0 Likes
on
0 Posts
ZFT
I think the problem IS the TRE's and POI's et al. Too few of them know anything about a given aircraft. Those that do in fact have a type rating on say a CRJ have ever flown the aircraft or worked with it enough to see these differences. Because I do work with one type every day for the manufacturer, I see these things and investigate (as do my collegues). I also fly the aircraft on a semi-regular basis. The local pilot cops (we deal with every authority in the world) seldom even look at the type unless there is a check or a problem.
Unless we complain, there is no intervention. As far as acceptance, they only deal with "does the malfunction do what the button says it will do?" The sim I was using in AUZ is no longer even affiliated with an operating airline, so there is no TRE involved except when the inspector shows up for the checkride on a crew. At least back home I have the advantage of a whole slew of instuctors, inspectors, etc. to keep things honest all the time. Most of the problems arise on the road where the sims are often serviced by local technicians and remote support past that. Then the locals can only report back to the sim manufacturer, and then they investigate when they get a chance, and then if (and only if) there is a discrepancy with the data package, they will fix immediately. If not, they call me back for clarification. Of course by then I'm long gone for another year or so.
So the problem still lies with the sim manufacturers themselves. That's why I wish there was a bit of a push for some standardization.
I think the problem IS the TRE's and POI's et al. Too few of them know anything about a given aircraft. Those that do in fact have a type rating on say a CRJ have ever flown the aircraft or worked with it enough to see these differences. Because I do work with one type every day for the manufacturer, I see these things and investigate (as do my collegues). I also fly the aircraft on a semi-regular basis. The local pilot cops (we deal with every authority in the world) seldom even look at the type unless there is a check or a problem.
Unless we complain, there is no intervention. As far as acceptance, they only deal with "does the malfunction do what the button says it will do?" The sim I was using in AUZ is no longer even affiliated with an operating airline, so there is no TRE involved except when the inspector shows up for the checkride on a crew. At least back home I have the advantage of a whole slew of instuctors, inspectors, etc. to keep things honest all the time.
Most of the problems arise on the road where the sims are often serviced by local technicians and remote support past that. Then the locals can only report back to the sim manufacturer, and then they investigate when they get a chance, and then if (and only if) there is a discrepancy with the data package, they will fix immediately. If not, they call me back for clarification. Of course by then I'm long gone for another year or so. So the problem still lies with the sim manufacturers themselves. That's why I wish there was a bit of a push for some standardization.
N4790P
Thread Starter
Elliot,
Maybe I’m fortunate, but the TREs and TRIs that I deal with. both from the airframe manufacturer and customer airlines tend to be both knowledgeable and very critical.
Like you, I also deal with many authorities and again I find them to be generally pretty good.
Simulated malfunction acceptance is a bit more in depth than "does the malfunction do what the button says it will do?" In the initial phase of simulator production a Malfunction Definition Document and Acceptance Test Manuals are supplied to the end user for approval. These documents detail exactly what the malfunction is and exactly what characteristics simulated systems will exhibit. On more modern simulators this Malfunction Defn Doc is even being linked into the Instructors Station help system. This ensures that the instructor knows just what the malfunction will do. (On older devices it’s unfortunately still a paper exercise).
I too wish there was greater standardisation, not just malfunctions, but across a far broader simulation spectrum. Trouble is that different airlines/Fleet Captains have different requirements.
I don’t entirely agree with your comments about local techs and local support. From my experience once a simulator has been in service for a few years, the local sim engineers tend to be far more knowledgeable about their sims than the manufacturer. Of course the standard of maintenance is dependant upon the resources made available to the sim engineers, but that’s another ‘beancounter’ story………..
Maybe I’m fortunate, but the TREs and TRIs that I deal with. both from the airframe manufacturer and customer airlines tend to be both knowledgeable and very critical.
Like you, I also deal with many authorities and again I find them to be generally pretty good.
Simulated malfunction acceptance is a bit more in depth than "does the malfunction do what the button says it will do?" In the initial phase of simulator production a Malfunction Definition Document and Acceptance Test Manuals are supplied to the end user for approval. These documents detail exactly what the malfunction is and exactly what characteristics simulated systems will exhibit. On more modern simulators this Malfunction Defn Doc is even being linked into the Instructors Station help system. This ensures that the instructor knows just what the malfunction will do. (On older devices it’s unfortunately still a paper exercise).
I too wish there was greater standardisation, not just malfunctions, but across a far broader simulation spectrum. Trouble is that different airlines/Fleet Captains have different requirements.
I don’t entirely agree with your comments about local techs and local support. From my experience once a simulator has been in service for a few years, the local sim engineers tend to be far more knowledgeable about their sims than the manufacturer. Of course the standard of maintenance is dependant upon the resources made available to the sim engineers, but that’s another ‘beancounter’ story………..