- Email: [email protected]
Design of the Eurofighter human machine interface
Design of the Eurofighter Human Machine Interface Chris J. SMITH
Every new generation of fighter aircraft presents new challenges for the various design disciplines that are involved in their development; the current generation of fighters - Eurofighter, Rafale, and F22 - are no different in this respect. We look to using new structural materials, a d v a n c e d flight control systems, and ever better a n d more comprehensive sensors to extend the system's overall performance and c a p a bility. Thisp a p e r looks at the area of cockpit design - the "how do we keep the pilot in real control of his tasks" part of the total p a c k a g e of the aircraft a n d weapons system design. O
perational requirements for the typical modem fighter are daunting, requiring very high levels of airframe and engine performance, to give high agility coupled with good range and endurance, and good weapon load carriage, coupled with extremely capable avionics. These provide the pilot with accurate data on all aspects of his mission and enhance the overall effectiveness of the aircraft by providing optimum performance in a variety of operational roles. Add to that an increasing concern over acquisition and life cycle costs - which can dramatically affect the basic design process as well as the risks associated with the development programme, and we introduce the ingredients for numerous design team conflicts between engineering and commercial requirements. We can expect our 21st Century Wonderfighter to be fitted with at least a powerful multi-mode radar, an infrared air-to-air tracker, an infra-red imager, data link (the command and control requirements of modem multiaircraft tactics are only manageable with a comprehensive data link), a powerful defensive aids suite with passive sensing over a wide frequency range, powerful wide band Electronic
Counter Measures (ECM) jammers, chaff, flares and decoys. For precision air-to-surface work with smart munitions, an electro-optical acquisition/ tracking device with laser designator will be fitted with a largely self-contained and ideally passive navigation system. Finally, V/UHF communications radios must be fitted, capable of secure, ECM resistant, operation. To aid visual acquisition of threats and to enhance situational awareness, a helmet-mounted display will be required. There are usually few other cockpit requirements specified, other than general statements requiring "low pilot workload", and the detailed cockpit design is therefore left to the manufacturer.
(DLCP); 3 identical 15cm Multifunction Head Down Displays (MHDD) with programmable soft keys around the sides; a left glareshield allows the pilot his main input and control interface for data entry, modification and mission management; the right glareshield provides the pilot with reversionary and communication information; left and right consoles are designed primarily for start-up, shutdown and emergency operations and should not be regularly used during flight (figure 2). Flight control is via a central control column and conventional twin throttle arrangement. An intelligent warning panel is mounted close to the pilot's right knee.
The Eurofighter cockpit
Modern cockpit design issues
The Eurofighter multi-role weapon system has been designed as a single seat, twin-engined aircraft (figure 1) where particular emphasis has been put on ensuring that the cockpit environment will allow the pilot to operate most efficiently throughout his required roles, workloads, experience levels etc. The primary items include a wide angle Head Up Display (HUD) sitting atop a Data Link Control Panel
Data volume With sensors providing target detection over a much larger volume than before, the pilot could be swamped by sheer volume of data. Furthermore, a single target may be detected by several sensors, further exacerbating the amount of data thrown into the system - for example, a hostile threat may be seen by the radar, the infra red tracker,
IBI
........................................................................................................................................................................................................................... Th! ee_.New..Eu
ropea.n,_Fighter....Airc,
and the defensive aids system, and also reported via the data link net from other aircraft.
Density of controls There are potentially a large number of controls required, given the number of individual sensors and other equipments- for example, a modem multimode radar, even using a good degree of automation, can still require the pilot to input or vary over 20 different parameters. Situational
awareness
As well as operating the "offensive" systems, the pilot must maintain situational awareness, both globally - where he is in relation to geographic or tactical features, where the friendly forces are - and immediately - where the aircraft is in relation to the ground and other aircraft in the immediate vicinity. Added to that, the pilot has to maintain his mental picture of where he is in relation to his recovery airfield or the refuelling tanker, while considering his remaining fuel state, altitude and current rate of fuel usage. This is a highly dynamic mental exercise, and has traditionally been one of the most difficult and demanding skills the pilot has to master.
Heads in/heads out spite of all our modem avionic advancement, the traditional fighter pilot's adage - "he who sees In'st wins" - is still very valid: early visual acquisition of targets provides a huge advantage. Making the correct balance between head in work - where Beyond Visual Range (BVR) requirements dictate working the systems and concentrating on the displays - and head out visual searching for targets in air-to-air and air-to-ground environments is another difficult and demanding skill. In
Workload In fact, all the preceding items are just aspects of the potential for excessive
Figure I. Eurofighter DA2. (Doc. British Aerospace) pilot workload in the cockpit: a capable and well-trained pilot can achieve acceptable performance in any of these aspects, or in any other area of aircraft operation, if he can apply sufficient concentration to them - the problem comes when several aspects combine and the pilot has insufficient mental and cognitive capacity to sort out and complete the tasks. Modem history is still full of examples of aircraft flying into sea or ground while the pilot was concentrating on system operation to the detriment of awareness of ground proximity. Successful cockpit design is only achievable if it contains pilot workload within sustainable levels while still allowing the pilot to operate the aircraft effectively. Some of the other issues considered in the overall design include: the control of electronic emissions, the degree of autonomous decision making capability required, and the integration and compatibility requirements with other coalition forces etc.
Modern cockpit design trends We can significantly reduce workload by letting the system carry out many "housekeeping" tasks. With an accurate navigation system, which includes data not just on where 1 am but also where I'm going and the route I'm taking, plus knowledge of my fuel ~1~
AIR
& SPACE
state, fuel flow and performance data, it's a simple computing task for the system to tell me when it's time to go home, or to monitor my actual fuel against what has been planned. I can easily store large amounts of text or graphical data; instead of carrying a comprehensive checklist to deal with failures, I can store all that data within the system, and let the system find the right procedures for me when a failure occurs via an intelligent warnings system that indicates the urgency of the warning. We can also use the powerful computing capacity to process the data before displaying it in the most appropriate form; sensor fusion is the prime example. This data is not just the traditional target range, bearing and heading, but also other parameters including identity (derived perhaps from radar signatures, data link and passive radar warning systems). The design principle is summarised as "the right information, in the right form, at the right time". Finally, we can reduce to a minimum the amount of work the pilot carries out as a result of making one action. For example, to carry out a bomb attack against a pre-planned ground target, all the pilot should have to do is satisfy the weapon aiming commands and keep the release commit button pressed so the system can release the stores at the optimum time. EUROPE
• VOL.
I ° No
3 -
1999
hter Human Machine Interface All this implies a large amount of automation within the system, which alarms pilots in two ways. First, the design philosophy must be that the automation is there to liberate the pilot to concentrate on tactics, not to intrude in or take over that tactical thinking. Secondly, it is essential that the pilot can easily and quickly change or over-ride the automation, without immediately losing key data. This second requirement perhaps sounds easy to say but difficult to implement, but Eurofighter experience suggests that it is achievable through tight control of where automation starts and stops. "Automation" may infer lower pilot workload but pilot capacity released by the intelligent application of automation will very often be used for additional tasking, rather than just improving the pilot's - and system's performance on the present tasks. Further, carefully constructed automation is, of necessity, a compromise to cater for different levels of operator skill, experience and tasking. We therefore need a layered approach to where we automate functions, so that, for example, an inexperienced pilot can use "high" automation to allow him to concentrate on tactics and flying and let the system provide him with simple data, while experienced and highly trained pilots can interact more with the system, and benefit from more subtle aspects of automation, to optimise system performance for any particular tactical scenario.
The hardware Cockpit displays The detailed choice of display surfaces is driven by the cockpit space available (often a compromise with other requirements in the design), the readability requirements, and the operational roles of the aircraft. As a generaiisation, the main display surfaces will need to be large - at least 15cm square colour, and night vision
equipment compatible. Current aircraft use conventional shadow mask TV displays, but LCD technology has matured to provide high luminance, sunlight readable high resolution colour liquid crystal displays suitable for a fighter cockpit and providing benefits from the lower power requirements, reduced heat output, and smaller cockpit volume requirements.
Helmet Mounted Displays Similarly, Helmet Mounted Display (HMD) technology is now maturing to give high quality binocular displays, with wide fields of view and good optical quality, with positioning sensing accuracy good enough to permit accurate correlation of night vision video with the outside world. There are two possible design approaches for including an HMD in the cockpit: Design the cockpit displays independently from the HMD, and use the HMD primarily as a simple pointing and cueing device (i.e. a helmet mounted sight). The advantage of this approach is that the helmet itself is simpler and cheaper and the symbology present in front of the pilot is kept to a minimum. It is also achievable with today's technology Design the HMD as an integral part of the cockpit, and use the HMD to display - when appropriate - key information that the pilot will only otherwise see by looking in. This is an advantage particularly in close visual combat, when the pilot's sightline is often very different from the aircraft flight path and well away from the internal cockpit displays. Given that any new fighter will require integral Night Vision Enhancement (NVE) systems, and that these must be provided on the helmet with a consequential weight increase, the second approach maximises the potential of the HMD. However, it does require a rigorous discipline in design symbology and minimising display clutter, and it is still - at today's technology - a demanding technical challenge to fit
m
all the necessary hardware into a helmet assembly that the pilot can use in a 9g turning fighter.
Voice output If we use automation to relieve the pilot of routine cockpit administration, we need a comprehensive warning system to cue the pilot when something requires his attention. The pilot needs to know about more than just systems failures (which will produce "warnings" in the conventional sense) - we can reduce his monitoring workload by prompting him about speed limits, fuel states, configuration cues, and many other parameters. If we use a voice-based warning and status system, he can get the information without looking into the cockpit, a major advantage during most tactical flying.
Voice input Similarly, if we can replicate many of the head down in-cockpit control tasks by using voice input commands, the pilot can spend significantly more time with his hands on the stick and throttle and his eyes out of the cockpit watching targets. The development of Direct Voice Input (DVI) has encouraged us to reconsider conventional Hands-on-Throttle-and-Stick (HOTAS) philosophy because of the sheer intuitive - and reliable - nature of this evolving technology. HOTAS usage has traditionally been based around prioritisation, availability, vehicle dynamics and speed of operation defining a list of critical controls that must be available under all conditions, e.g. radar air-combat modes, weapon selection, radio transmit etc. However, there is a physical limit to the number of switches that can be contained within the confines of a usable stick and throttle arrangement given the size range of the fighter pilots' hands. The flexibility of DVI now allows us to execute other important, time critical, but not so frequently required functions without recourse to either
......................................................................................................ThreeNew.EuropeanFighterAircr ...................................................................................................................... conventional controls via multimoded head down displays or introducing new switches - multi-moding is not a good design feature in time critical, pressurised situations. Thus, if the optimisation of a FLIR picture whilst flying at low level was considered important enough for HOTAS controls (e.g. Zoom, Lock etc), then it would require dedicated switches, thus reducing those available for other tasks, say in a more highly dynamic environment. DVI is ideal in this context and comes very naturally to a pilot who only has to translate his natural thoughts, e.g. FLIR ZOOM into words. Voice, Throttle and Stick (VTAS) philosophy is now an intrinsic part of our design process.
How to manage development of the design Traditionally, the software used to control the various individual system components and drive the necessary displays and controls has been designed on paper (in the form of Software Requirements Documents) and is only seen in operation for the first time on the avionics system test rig. The test rig is built to house the prototype hardware equipments, to allow test and validation of equipment prior to fit to the aircraft. Invariably, problems are discovered with moding or system interfacing at this stage, which often result in the need for modification of equipment (time and money permitting) or significant loss of function or limitation in performance during the early part of the development programme while the problems are belatedly addressed. The test rig is also the first time the test and development aircrew will have seen the system in anything like operating form, and they will most certainly identify numerous moding problems and difficulties. More important, there are usually major problems in overall cockpit workload - caused by
Figure 2. Eurofighter Cockpit. (Doc. BritishAerospace) moding or control deficiencies - that only become apparent at this stage. Finding problems this late - after hardware is built and software is written is inefficient and expensive, and is usually the root cause of programme delays and cost overruns. The subsequent development programme then tends to become a recovery exercise, rather than a proving and refining exercise. However, the same computing power that allows the team to make the major changes in cockpit design described above also provides us with very powerful simulation and rapid prototyping tools. The key tool is a comprehensive simulation of the weapons system, including a representative simulation of the actual cockpit layout, displays and controls, in an environment that allows aircrew to "fly" and operate the systems against representative simulated threats. The simulation must use rapid prototyping software control techniques, to allow us to very rapidly AIR
&
SPACE
alter and adjust the proposed system design. The design process becomes as follows: 1. The overall system architecture is defined, from consideration of current and predicted operational requirements, the requirements capture process itself, equipment involved, and the performance required, and then split into a number of sub-systems for ease of handling. 2. An initial moding and control design for each sub-system is done by a small team, comprising all the necessary specialists - systems analysts, software and hardware engineers, human factors engineers, and aircrew. The design is "informal" at this stage and is written down as draft concept moding papers, and given to the simulation engineers to implement in the weapons system simulation. 3. Test aircrew evaluate the design in the simulator, this will inevitably EUROPE
• VOL.
I
•
No
3
-
1999
hter Human Machine Interface highlight problems with the design. Initially, it may only be possible to evaluate individual sub-systems, but given the right level of resources within the teams - the simulation can be rapidly developed to integrate the various system components. 4. Aircrew highlighted problems are then addressed by a small specialist "hit team". The word small is highlighted - it is crucial that the team comprises only those directly associated with the problem, plus the aircrew, and that the team members have the authority to define and agree any necessary changes. 5. Simulation engineers implement the changes and the system is re-evaluated. Any further problems are addressed as in the previous stage. 6. The process is repeated until a satisfactory design is achieved: note, this does not necessarily mean to the aircrew's satisfaction - a proper balance between operational, engineering, and commercial requirements must be made. This again demands that the team members involved in this design iteration process have a broad understanding of the overall programme and operational requirements, and the authority to make the necessary design changes and compromises. 7. The agreed design is then documented and formally agreed to act as a common design baseline from which detailed software and hardware requirements may be written and provided to equipment sub-contractors. A highly integrated cockpit and weapon system can potentially result in a complex system architecture. Although the small "hit team" can address the major integration issues, the sheer complexity of the system can mean that a lower level software process within the design could restrict the planned development. It is therefore essential that highly structured, efficient - and ideally automated traceability and configuration control tools are embedded and maintained such that the effects of any proposed
changes can be rapidly promulgated and assessed. This also has a major impact on the flight trials programme. In the past, major moding and systems integration problems were not discovered until real hardware was flown, and the development programme therefore included a significant amount of system hardware and software development. Because the bulk of moding and integration problems are discovered on the simulation and not in the aircraft, the cost of fixing these problems is dramatically reduced. In Eurofighter, we estimate the cost ratio between simulator fixing and on-aircraft fixing is 1:1000, and that does not include any consequential costs resulting from programme delays while waiting for revised aircraft software. With this design process, we can expect little software development to be required (and that is restricted to ironing out software "bugs" rather than fundamental changes to system design). The development programme then concentrates on the evaluation of hardware performance Aircrew involvement at every stage of the design process is crucial. Achieving the design aim of producing an operationally effective system within the constraints of timescales and budgets always requires a compromise between operational, commercial and engineering demands.
What next? However, we can do a lot more by developing our process further. The weakness of the process I've just described is that we still convert the design, developed in detail in the simulator, into paper, for conversion back into real aircraft software. That aircraft software writing process takes hundreds of thousands of man-hours, to produce the same outputs from real hardware that we've already seen in the simulation. We need to develop our software tools to the stage where
El
we can automate the transition from rapid prototyping software (easy to use, very flexible, but of much too low integrity to use in an aircraft) into aircraft standard software. Of course, the safety and integrity requirements of the real aircraft software are such that we must rigorously test the software before clearing it for use in the aircraft: this task can take from several weeks for a small change to part of the load to a year for a major software update. Since any changes resulting from development work also require prolonged clearance procedures, the rate of progress towards good quality, efficient and effective system performance becomes driven by clearance requirements, rather than design and development requirements. We must therefore also increase the automation of software testing, so that we can significantly reduce the time required to get our new software into the aircraft, and reduce the man-hours associated with quality control and software clearance while retaining very good software quality. Given these resources, I can then add 2 other steps to the design process: 8. Produce aircraft standard software from developed and formally agreed simulation software. 9. Clear the aircraft software through quality control procedures and fit into aircraft. If problems are discovered during these 2 steps, they are fed back into the design process at step 5. There are 2 major benefits from this approach: The system development programme timescale risks are significantly reduced, because we then have the ability to implement changes in short timescales. No matter how good the design, there will always be problems that only appear when the aircraft is flown or it maybe necessary to change displays, controls and moding software to offset some deficiency in the equipment hardware design. We must be able to correct these problems
............................................................................!hree. ..............NewEuro .................... quickly, particularly if we have already reduced the available development time and money because of our confidence in the basic system design. Subsequent software revisions, due to new operational requirements or the addition of new facilities or hardware, can be incorporated quickly, cheaply, and at low additional technical risk. This is of operational significance to the Customer, who - in the nature of military development - always wants his aircraft to do more than they were originally designed for. It is also of great benefit to the Company, since it reduces the costs associated with developing export variants of the aircraft and makes it more saleable.
Summary The demands on a modem multi-role fighter can impose severe workload requirements on the pilot unless his working space is optimised for his own skills and strengths. In designing the Eurofighter cockpit, we have considered those aspects that affect his workload at all stages of flight and have developed the Human Machine Interface through a combination of hardware and software models and simulations. Modem computing power can be used to model very accurately our design,
and then the models used rapidly to develop the design under operationally representative conditions. The speed with which we can do this, using rapid prototyping techniques controlled by a small but skilled team, allows us to define a design in great detail well before hardware and software is actually written and procured. This provides several major advantages: significantly reduced development risk and timescales; a more flexible, adaptable and marketable product; and the Customer, who can make operator input to the design much earlier than ever before in the design process, will have much greater confidence that the system will meet operational requirements when it goes into service. In parallel with the development of automated traceability and
it,
AIR
&
SPACE
n.F!ghter.Aircr
.
configuration control tools, this design process heralds a radical improvement in the quality and timeliness of weapon system - and cockpit - design. The costs associated with this design process, mainly associated with the provision of high quality simulation and the skills required to utilise the equipment efficiently are far outweighed by the reduced development programme costs and risks. The Eurofighter programme has used part of the described design process, and we are looking at ways to extend it further. What we have already done has produced an aircraft with a maturity and a quality of cockpit moding that are dramatically better at this stage in the development programme than any I have ever seen. We know the process works, our task now is to make it even better. []
EUROPE
• VOL.
I
•
No
3 -
1999
Every new generation of fighter aircraft presents new challenges for the various design disciplines that are involved in their development; the current generation of fighters - Eurofighter, Rafale, and F22 - are no different in this respect. We look to using new structural materials, a d v a n c e d flight control systems, and ever better a n d more comprehensive sensors to extend the system's overall performance and c a p a bility. Thisp a p e r looks at the area of cockpit design - the "how do we keep the pilot in real control of his tasks" part of the total p a c k a g e of the aircraft a n d weapons system design. O
perational requirements for the typical modem fighter are daunting, requiring very high levels of airframe and engine performance, to give high agility coupled with good range and endurance, and good weapon load carriage, coupled with extremely capable avionics. These provide the pilot with accurate data on all aspects of his mission and enhance the overall effectiveness of the aircraft by providing optimum performance in a variety of operational roles. Add to that an increasing concern over acquisition and life cycle costs - which can dramatically affect the basic design process as well as the risks associated with the development programme, and we introduce the ingredients for numerous design team conflicts between engineering and commercial requirements. We can expect our 21st Century Wonderfighter to be fitted with at least a powerful multi-mode radar, an infrared air-to-air tracker, an infra-red imager, data link (the command and control requirements of modem multiaircraft tactics are only manageable with a comprehensive data link), a powerful defensive aids suite with passive sensing over a wide frequency range, powerful wide band Electronic
Counter Measures (ECM) jammers, chaff, flares and decoys. For precision air-to-surface work with smart munitions, an electro-optical acquisition/ tracking device with laser designator will be fitted with a largely self-contained and ideally passive navigation system. Finally, V/UHF communications radios must be fitted, capable of secure, ECM resistant, operation. To aid visual acquisition of threats and to enhance situational awareness, a helmet-mounted display will be required. There are usually few other cockpit requirements specified, other than general statements requiring "low pilot workload", and the detailed cockpit design is therefore left to the manufacturer.
(DLCP); 3 identical 15cm Multifunction Head Down Displays (MHDD) with programmable soft keys around the sides; a left glareshield allows the pilot his main input and control interface for data entry, modification and mission management; the right glareshield provides the pilot with reversionary and communication information; left and right consoles are designed primarily for start-up, shutdown and emergency operations and should not be regularly used during flight (figure 2). Flight control is via a central control column and conventional twin throttle arrangement. An intelligent warning panel is mounted close to the pilot's right knee.
The Eurofighter cockpit
Modern cockpit design issues
The Eurofighter multi-role weapon system has been designed as a single seat, twin-engined aircraft (figure 1) where particular emphasis has been put on ensuring that the cockpit environment will allow the pilot to operate most efficiently throughout his required roles, workloads, experience levels etc. The primary items include a wide angle Head Up Display (HUD) sitting atop a Data Link Control Panel
Data volume With sensors providing target detection over a much larger volume than before, the pilot could be swamped by sheer volume of data. Furthermore, a single target may be detected by several sensors, further exacerbating the amount of data thrown into the system - for example, a hostile threat may be seen by the radar, the infra red tracker,
IBI
........................................................................................................................................................................................................................... Th! ee_.New..Eu
ropea.n,_Fighter....Airc,
and the defensive aids system, and also reported via the data link net from other aircraft.
Density of controls There are potentially a large number of controls required, given the number of individual sensors and other equipments- for example, a modem multimode radar, even using a good degree of automation, can still require the pilot to input or vary over 20 different parameters. Situational
awareness
As well as operating the "offensive" systems, the pilot must maintain situational awareness, both globally - where he is in relation to geographic or tactical features, where the friendly forces are - and immediately - where the aircraft is in relation to the ground and other aircraft in the immediate vicinity. Added to that, the pilot has to maintain his mental picture of where he is in relation to his recovery airfield or the refuelling tanker, while considering his remaining fuel state, altitude and current rate of fuel usage. This is a highly dynamic mental exercise, and has traditionally been one of the most difficult and demanding skills the pilot has to master.
Heads in/heads out spite of all our modem avionic advancement, the traditional fighter pilot's adage - "he who sees In'st wins" - is still very valid: early visual acquisition of targets provides a huge advantage. Making the correct balance between head in work - where Beyond Visual Range (BVR) requirements dictate working the systems and concentrating on the displays - and head out visual searching for targets in air-to-air and air-to-ground environments is another difficult and demanding skill. In
Workload In fact, all the preceding items are just aspects of the potential for excessive
Figure I. Eurofighter DA2. (Doc. British Aerospace) pilot workload in the cockpit: a capable and well-trained pilot can achieve acceptable performance in any of these aspects, or in any other area of aircraft operation, if he can apply sufficient concentration to them - the problem comes when several aspects combine and the pilot has insufficient mental and cognitive capacity to sort out and complete the tasks. Modem history is still full of examples of aircraft flying into sea or ground while the pilot was concentrating on system operation to the detriment of awareness of ground proximity. Successful cockpit design is only achievable if it contains pilot workload within sustainable levels while still allowing the pilot to operate the aircraft effectively. Some of the other issues considered in the overall design include: the control of electronic emissions, the degree of autonomous decision making capability required, and the integration and compatibility requirements with other coalition forces etc.
Modern cockpit design trends We can significantly reduce workload by letting the system carry out many "housekeeping" tasks. With an accurate navigation system, which includes data not just on where 1 am but also where I'm going and the route I'm taking, plus knowledge of my fuel ~1~
AIR
& SPACE
state, fuel flow and performance data, it's a simple computing task for the system to tell me when it's time to go home, or to monitor my actual fuel against what has been planned. I can easily store large amounts of text or graphical data; instead of carrying a comprehensive checklist to deal with failures, I can store all that data within the system, and let the system find the right procedures for me when a failure occurs via an intelligent warnings system that indicates the urgency of the warning. We can also use the powerful computing capacity to process the data before displaying it in the most appropriate form; sensor fusion is the prime example. This data is not just the traditional target range, bearing and heading, but also other parameters including identity (derived perhaps from radar signatures, data link and passive radar warning systems). The design principle is summarised as "the right information, in the right form, at the right time". Finally, we can reduce to a minimum the amount of work the pilot carries out as a result of making one action. For example, to carry out a bomb attack against a pre-planned ground target, all the pilot should have to do is satisfy the weapon aiming commands and keep the release commit button pressed so the system can release the stores at the optimum time. EUROPE
• VOL.
I ° No
3 -
1999
hter Human Machine Interface All this implies a large amount of automation within the system, which alarms pilots in two ways. First, the design philosophy must be that the automation is there to liberate the pilot to concentrate on tactics, not to intrude in or take over that tactical thinking. Secondly, it is essential that the pilot can easily and quickly change or over-ride the automation, without immediately losing key data. This second requirement perhaps sounds easy to say but difficult to implement, but Eurofighter experience suggests that it is achievable through tight control of where automation starts and stops. "Automation" may infer lower pilot workload but pilot capacity released by the intelligent application of automation will very often be used for additional tasking, rather than just improving the pilot's - and system's performance on the present tasks. Further, carefully constructed automation is, of necessity, a compromise to cater for different levels of operator skill, experience and tasking. We therefore need a layered approach to where we automate functions, so that, for example, an inexperienced pilot can use "high" automation to allow him to concentrate on tactics and flying and let the system provide him with simple data, while experienced and highly trained pilots can interact more with the system, and benefit from more subtle aspects of automation, to optimise system performance for any particular tactical scenario.
The hardware Cockpit displays The detailed choice of display surfaces is driven by the cockpit space available (often a compromise with other requirements in the design), the readability requirements, and the operational roles of the aircraft. As a generaiisation, the main display surfaces will need to be large - at least 15cm square colour, and night vision
equipment compatible. Current aircraft use conventional shadow mask TV displays, but LCD technology has matured to provide high luminance, sunlight readable high resolution colour liquid crystal displays suitable for a fighter cockpit and providing benefits from the lower power requirements, reduced heat output, and smaller cockpit volume requirements.
Helmet Mounted Displays Similarly, Helmet Mounted Display (HMD) technology is now maturing to give high quality binocular displays, with wide fields of view and good optical quality, with positioning sensing accuracy good enough to permit accurate correlation of night vision video with the outside world. There are two possible design approaches for including an HMD in the cockpit: Design the cockpit displays independently from the HMD, and use the HMD primarily as a simple pointing and cueing device (i.e. a helmet mounted sight). The advantage of this approach is that the helmet itself is simpler and cheaper and the symbology present in front of the pilot is kept to a minimum. It is also achievable with today's technology Design the HMD as an integral part of the cockpit, and use the HMD to display - when appropriate - key information that the pilot will only otherwise see by looking in. This is an advantage particularly in close visual combat, when the pilot's sightline is often very different from the aircraft flight path and well away from the internal cockpit displays. Given that any new fighter will require integral Night Vision Enhancement (NVE) systems, and that these must be provided on the helmet with a consequential weight increase, the second approach maximises the potential of the HMD. However, it does require a rigorous discipline in design symbology and minimising display clutter, and it is still - at today's technology - a demanding technical challenge to fit
m
all the necessary hardware into a helmet assembly that the pilot can use in a 9g turning fighter.
Voice output If we use automation to relieve the pilot of routine cockpit administration, we need a comprehensive warning system to cue the pilot when something requires his attention. The pilot needs to know about more than just systems failures (which will produce "warnings" in the conventional sense) - we can reduce his monitoring workload by prompting him about speed limits, fuel states, configuration cues, and many other parameters. If we use a voice-based warning and status system, he can get the information without looking into the cockpit, a major advantage during most tactical flying.
Voice input Similarly, if we can replicate many of the head down in-cockpit control tasks by using voice input commands, the pilot can spend significantly more time with his hands on the stick and throttle and his eyes out of the cockpit watching targets. The development of Direct Voice Input (DVI) has encouraged us to reconsider conventional Hands-on-Throttle-and-Stick (HOTAS) philosophy because of the sheer intuitive - and reliable - nature of this evolving technology. HOTAS usage has traditionally been based around prioritisation, availability, vehicle dynamics and speed of operation defining a list of critical controls that must be available under all conditions, e.g. radar air-combat modes, weapon selection, radio transmit etc. However, there is a physical limit to the number of switches that can be contained within the confines of a usable stick and throttle arrangement given the size range of the fighter pilots' hands. The flexibility of DVI now allows us to execute other important, time critical, but not so frequently required functions without recourse to either
......................................................................................................ThreeNew.EuropeanFighterAircr ...................................................................................................................... conventional controls via multimoded head down displays or introducing new switches - multi-moding is not a good design feature in time critical, pressurised situations. Thus, if the optimisation of a FLIR picture whilst flying at low level was considered important enough for HOTAS controls (e.g. Zoom, Lock etc), then it would require dedicated switches, thus reducing those available for other tasks, say in a more highly dynamic environment. DVI is ideal in this context and comes very naturally to a pilot who only has to translate his natural thoughts, e.g. FLIR ZOOM into words. Voice, Throttle and Stick (VTAS) philosophy is now an intrinsic part of our design process.
How to manage development of the design Traditionally, the software used to control the various individual system components and drive the necessary displays and controls has been designed on paper (in the form of Software Requirements Documents) and is only seen in operation for the first time on the avionics system test rig. The test rig is built to house the prototype hardware equipments, to allow test and validation of equipment prior to fit to the aircraft. Invariably, problems are discovered with moding or system interfacing at this stage, which often result in the need for modification of equipment (time and money permitting) or significant loss of function or limitation in performance during the early part of the development programme while the problems are belatedly addressed. The test rig is also the first time the test and development aircrew will have seen the system in anything like operating form, and they will most certainly identify numerous moding problems and difficulties. More important, there are usually major problems in overall cockpit workload - caused by
Figure 2. Eurofighter Cockpit. (Doc. BritishAerospace) moding or control deficiencies - that only become apparent at this stage. Finding problems this late - after hardware is built and software is written is inefficient and expensive, and is usually the root cause of programme delays and cost overruns. The subsequent development programme then tends to become a recovery exercise, rather than a proving and refining exercise. However, the same computing power that allows the team to make the major changes in cockpit design described above also provides us with very powerful simulation and rapid prototyping tools. The key tool is a comprehensive simulation of the weapons system, including a representative simulation of the actual cockpit layout, displays and controls, in an environment that allows aircrew to "fly" and operate the systems against representative simulated threats. The simulation must use rapid prototyping software control techniques, to allow us to very rapidly AIR
&
SPACE
alter and adjust the proposed system design. The design process becomes as follows: 1. The overall system architecture is defined, from consideration of current and predicted operational requirements, the requirements capture process itself, equipment involved, and the performance required, and then split into a number of sub-systems for ease of handling. 2. An initial moding and control design for each sub-system is done by a small team, comprising all the necessary specialists - systems analysts, software and hardware engineers, human factors engineers, and aircrew. The design is "informal" at this stage and is written down as draft concept moding papers, and given to the simulation engineers to implement in the weapons system simulation. 3. Test aircrew evaluate the design in the simulator, this will inevitably EUROPE
• VOL.
I
•
No
3
-
1999
hter Human Machine Interface highlight problems with the design. Initially, it may only be possible to evaluate individual sub-systems, but given the right level of resources within the teams - the simulation can be rapidly developed to integrate the various system components. 4. Aircrew highlighted problems are then addressed by a small specialist "hit team". The word small is highlighted - it is crucial that the team comprises only those directly associated with the problem, plus the aircrew, and that the team members have the authority to define and agree any necessary changes. 5. Simulation engineers implement the changes and the system is re-evaluated. Any further problems are addressed as in the previous stage. 6. The process is repeated until a satisfactory design is achieved: note, this does not necessarily mean to the aircrew's satisfaction - a proper balance between operational, engineering, and commercial requirements must be made. This again demands that the team members involved in this design iteration process have a broad understanding of the overall programme and operational requirements, and the authority to make the necessary design changes and compromises. 7. The agreed design is then documented and formally agreed to act as a common design baseline from which detailed software and hardware requirements may be written and provided to equipment sub-contractors. A highly integrated cockpit and weapon system can potentially result in a complex system architecture. Although the small "hit team" can address the major integration issues, the sheer complexity of the system can mean that a lower level software process within the design could restrict the planned development. It is therefore essential that highly structured, efficient - and ideally automated traceability and configuration control tools are embedded and maintained such that the effects of any proposed
changes can be rapidly promulgated and assessed. This also has a major impact on the flight trials programme. In the past, major moding and systems integration problems were not discovered until real hardware was flown, and the development programme therefore included a significant amount of system hardware and software development. Because the bulk of moding and integration problems are discovered on the simulation and not in the aircraft, the cost of fixing these problems is dramatically reduced. In Eurofighter, we estimate the cost ratio between simulator fixing and on-aircraft fixing is 1:1000, and that does not include any consequential costs resulting from programme delays while waiting for revised aircraft software. With this design process, we can expect little software development to be required (and that is restricted to ironing out software "bugs" rather than fundamental changes to system design). The development programme then concentrates on the evaluation of hardware performance Aircrew involvement at every stage of the design process is crucial. Achieving the design aim of producing an operationally effective system within the constraints of timescales and budgets always requires a compromise between operational, commercial and engineering demands.
What next? However, we can do a lot more by developing our process further. The weakness of the process I've just described is that we still convert the design, developed in detail in the simulator, into paper, for conversion back into real aircraft software. That aircraft software writing process takes hundreds of thousands of man-hours, to produce the same outputs from real hardware that we've already seen in the simulation. We need to develop our software tools to the stage where
El
we can automate the transition from rapid prototyping software (easy to use, very flexible, but of much too low integrity to use in an aircraft) into aircraft standard software. Of course, the safety and integrity requirements of the real aircraft software are such that we must rigorously test the software before clearing it for use in the aircraft: this task can take from several weeks for a small change to part of the load to a year for a major software update. Since any changes resulting from development work also require prolonged clearance procedures, the rate of progress towards good quality, efficient and effective system performance becomes driven by clearance requirements, rather than design and development requirements. We must therefore also increase the automation of software testing, so that we can significantly reduce the time required to get our new software into the aircraft, and reduce the man-hours associated with quality control and software clearance while retaining very good software quality. Given these resources, I can then add 2 other steps to the design process: 8. Produce aircraft standard software from developed and formally agreed simulation software. 9. Clear the aircraft software through quality control procedures and fit into aircraft. If problems are discovered during these 2 steps, they are fed back into the design process at step 5. There are 2 major benefits from this approach: The system development programme timescale risks are significantly reduced, because we then have the ability to implement changes in short timescales. No matter how good the design, there will always be problems that only appear when the aircraft is flown or it maybe necessary to change displays, controls and moding software to offset some deficiency in the equipment hardware design. We must be able to correct these problems
............................................................................!hree. ..............NewEuro .................... quickly, particularly if we have already reduced the available development time and money because of our confidence in the basic system design. Subsequent software revisions, due to new operational requirements or the addition of new facilities or hardware, can be incorporated quickly, cheaply, and at low additional technical risk. This is of operational significance to the Customer, who - in the nature of military development - always wants his aircraft to do more than they were originally designed for. It is also of great benefit to the Company, since it reduces the costs associated with developing export variants of the aircraft and makes it more saleable.
Summary The demands on a modem multi-role fighter can impose severe workload requirements on the pilot unless his working space is optimised for his own skills and strengths. In designing the Eurofighter cockpit, we have considered those aspects that affect his workload at all stages of flight and have developed the Human Machine Interface through a combination of hardware and software models and simulations. Modem computing power can be used to model very accurately our design,
and then the models used rapidly to develop the design under operationally representative conditions. The speed with which we can do this, using rapid prototyping techniques controlled by a small but skilled team, allows us to define a design in great detail well before hardware and software is actually written and procured. This provides several major advantages: significantly reduced development risk and timescales; a more flexible, adaptable and marketable product; and the Customer, who can make operator input to the design much earlier than ever before in the design process, will have much greater confidence that the system will meet operational requirements when it goes into service. In parallel with the development of automated traceability and
it,
AIR
&
SPACE
n.F!ghter.Aircr
.
configuration control tools, this design process heralds a radical improvement in the quality and timeliness of weapon system - and cockpit - design. The costs associated with this design process, mainly associated with the provision of high quality simulation and the skills required to utilise the equipment efficiently are far outweighed by the reduced development programme costs and risks. The Eurofighter programme has used part of the described design process, and we are looking at ways to extend it further. What we have already done has produced an aircraft with a maturity and a quality of cockpit moding that are dramatically better at this stage in the development programme than any I have ever seen. We know the process works, our task now is to make it even better. []
EUROPE
• VOL.
I
•
No
3 -
1999