In the second part of this feature, Dick Downs discusses the challenges associated with Test and Evaluation (T&E) of Helmet-Mounted Systems (HMS), including the regulatory implications of the presentation of critical flight information, with a focus on large rotorcraft and the presentation of flight symbology.

The Helmet-Mounted Display – Vader would be proud….

There are several advanced Helmet Mounted Systems (HMS) in service, leveraging the latest display technologies, including flight data and synthetic vision elements overlaid onto on- and off-helmet sensor video, all presented on a see-through (Type 2) visor and integrated into a lightweight and balanced helmet; a truly 24-hour capability in a single Helmet Equipment Assembly (HEA). Pilots can select multiple combinations of mission/phase-tailored symbology sets, including terrain/obstacle, weapons and tactical data, for true ‘heads-out’ operation – a real game-changer for both fixed- and rotary-wing operations. However, the sheer deluge of information that can be injected directly into the pilot’s eyeline must be managed, particularly in terms of human processing and the limited real estate available in the human foveal FoV. In any mission, there are priorities requiring different presentations, exemplified by fixed Head-Down and Head-Up Displays (HDD/HUD), but trying to (literally) cram all of the content of flight, navigation, tactical and Electronic Warfare (EW) displays into an HMS, in any combination, creates conflict, therefore priorities must be identified, with options and ‘non-negotiables’ established, for individual display formats. Moreso than any other display in the modern military cockpit and especially considering a retrofit application to an existing platform, the integration must be prepared to go back to first principles at every proposed format – ‘What is the display being used for?’. 

As mentioned in the first part of this article, if we look at the evolution of HMD/S from a regulatory perspective, and particularly from a civil certification POV, the previous generation of HMD, with direct-view (Type1) Night Vision Goggles (NVG) and clip on monocular display might invoke some degree of consternation, especially in the area of the display of flight symbology, where ‘advisory only’ might be considered an (almost literally) ‘get out of jail’ card. However, simply applying a purely civilian approach to risk, constrained by clearly inadequate assumptions regarding operational use, is not acceptable to the military, especially if the full benefit to tactical operations is to be realised. As usual, the military still needs to own (and fully understand) its risk.

However, this can lead to grey areas in the integration of HMS, particularly when the insertion of capability significantly leads (civil or military) regulatory and certification oversight – at this stage, the gatekeepers are very much the Test and Evaluation (T&E) establishment. Unfortunately, and evidenced by a few major acquisition programmes, Developmental- and Operational T&E (DT&E/OT&E), mostly separate processes, with separate personnel, don’t always fulfil the ambition of a Combined Test Team (CTT – remember that?) and crews can find themselves hidebound by lack of specific training and/or prior/unhelpful experience, particularly those who operated with the aforementioned clip-on NVG/HUD combination. Add in a pinch of misconception, my favourite being ‘reduces workload’, and an HMS flight debrief can look like John Wick’s just arrived looking for his dog!

Lots of Research, not so much Regulatory Guidance?

In fairness, the speed of introduction Helmet Mounted technologies has often outstripped the ability of the regulatory framework, and associated T&E process, to keep up. Indeed, when I first starting teaching HMS T&E, it was apparent from the demand that there was a need for specific training in this area. At the time, there was far less regulatory guidance than today, so we reverted to traditional engineering process, the basis of which was a thorough literature review, covering historical (lessons), technical (guidance) and research (analysis). This activity feeds into requirements capture, but I found also serves to ‘open the mind’, particularly when dealing with a group of Test Pilots (TPs) – a major part of a full-blown HMS T&E effort will be focussed on perception, cognition and workload, none of which are served particularly well by operational ‘baggage’.

In this respect it’s worth mentioning the importance of carefully selecting the operator group for HMS test. While it’s a given the sample will never be large enough, it’s tremendously important to get the mix right. Developmental TPs will have been thoroughly trained in the implementation of workload analyses, including a variety of tools such the Bedford Scale, NASA TLX etc, while Operational TPs, or Operational Evaluation aircrew, may have already had experience of HMD/S, some of it recently on frontline operations.  Both sides of the house bring ‘opinions’ which can seriously affect any evaluation. None will likely have had training in the finer aspects of cognition, so guiding expertise in this area is required from within the broader test team or via specialist external resource.  A new/novel symbology set may have the benefit of thousands of hours of development, including training, so it would be a shame to have (an inevitably) time-limited flight evaluation ruin the work. It’s also critical, especially in the face of a small sample size, to be prepared to modify the process (ask ‘better’, more pointed questions) and filter out prejudices, many of which are easy to predict based on a review of relevant experience. Sounds manipulative? Absolutely, but robustly justified and properly documented, including the baseline safety case, this process can make the difference between actually fielding a game changing technology, or ending up in a descending spiral of late-stage test failure. The bottom line is train your test crews….

So, we’ve got an eye on the gatekeepers, but what about the requirements? One would hope Operational and System Requirements (ORs/SRs) will be defined, but, again, a thorough review, ideally where we link each requirement to its associate Means of Compliance (MOC), is advised, and gives T&E a chance to ensure coherence.

Define the Process

First things first then - is there any regulatory information that might help, in particular with Primary Flight reference? Very much an area of regulatory cross-over, so it’s worth taking a canter though extant Certification Specifications (CS), especially as the civilian side develops its specific MOC. As usual, careful consideration is required, and not all of this information will be relevant, or desirable, for military operations. However, for our aforementioned large helicopter, EASA CS 29.1301/1302/1309, 29.773 and an EASA Special Conditions (SC) paper HMD29-01, plus 14 CFR 29.773(c) (which is slightly ahead of the CS), and AC-29.2C CHG 7 MG16, provide an abundance of guidance….and pitfalls. Of these, HMD29-01 seems to gather the various parts of the CS; with respect to PFD:

“The design of the HMD installation should be such that the HMD functions as intended in all anticipated flight attitudes, aircraft configurations and environmental conditions for which it is approved.”

“The visual display design should not cause perceptual or cognitive problems or undue eye strain for the user in any lighting conditions, including night or day operations.”

“As the HMD displays primary flight information, it is considered a de facto PFD while the pilot is using it, even if it is not the pilot’s sole display of this information. The pilot should be able to easily interpret the primary flight information; it should not be ambiguous or confusing when compared to the information on other flight deck displays.”

“Primary flight information displayed on the HMD should comply with all the requirements associated with such information in CS 29, with particular regard to CS 29.1303 for flight and navigation instruments and CS 29.1333(b) for the operational requirements of those systems. CS 29.1321 specifies the requirements for arranging primary flight information”.

For the military, 29.1321 illustrates where civilian certification requirements, on the face of it, cannot be met – references to pilot eyeline “grouped and centred…about the vertical plane of forward visibility”, will clearly not work for weapon aiming and other mission phases. These conflicts should be gathered assiduously. While emphasising the point that civilian certification requirements are not binding, but, and especially in the case of mishap, they will inevitably be referenced, it is therefore important that the military process takes account of such requirements in its own safety case. Most importantly, this process also indicates where Military T&E will need to ‘take up the slack’ to prove the intent of this and other potentially conflicting CS can be met with Alternative MOC (AMOC). This process also highlights where any modification/addition/deletion to the system due to future upgrades may need to revisit qualification.

So, having situated the civilian CS, and, where difficult to meet specifically, their intent, we can feed this into the requirements capture process to (eventually) churn out a system specification and testing requirements.

The Hardware 

HMS bring a raft of new/evolving technologies, including all-digital night vision, high-brightness image sources and image blending/fusion, which, as part of a safety-critical system, must be considered as part of the Systems Engineering (SE) process. The hierarchy of Design Assurance Level (DAL), described by RTCA DO-178B (software) and DO-254 (hardware), almost universally employed by the military for complex avionic systems, defines Assurance Levels, where E is the least critical, and A is the most critical. DAL A, requiring the most stringent certification, implies a greater cost than DAL E, reportedly around 40%, but I would suggest this is a low figure where HMS is concerned. Coming back to our focus on display of flight data, this is obviously critical, therefore DAL A is required. Taking this to its logical (civilian) conclusion, if we wanted to integrate an HMS into our aircraft, it would be great if It the proposed system came with a Technical Standing Order (TSO) for design and production? However, and for a number of very good reasons for military applications, it won’t, so we fall back to -178 and -254 compliance to DAL A. The subject of DAL vs. HMS is a significant discussion itself, but for now, I’ll leave this as the benchmark for the technical specification, and highlight my observation regarding the TopOwl HMS/D in Part 1 - “high level of integrity to use TopOwl Digital Display as a Primary Reference”.

Returning to the example of TopOwl in Part 1, if this HMS/D has been qualified onto other platforms, including the NH90, then surely the acquisition process, including military certification for CS 29 large rotorcraft, will be simple? Well, simpler, potentially, but again, the devil is in the detail. Copying another operator’s installation and certification conditions rather flies in the face of fundamentals such as certification basis (in civilian parlance) – is it relevant to the new application? Does an existing user operate the system in the same way? Are there differing training regimes/experience levels?

The support of the platform OEM in the integration is almost indispensable for an installation such as TopOwl; to fully realise the benefits, the HMS must be fully integrated with a plethora of onboard systems. At a technical level, where system requirements and associated test processes are defined, there is a significant amount of work to properly understand the abovementioned ‘build the system right’. Symbology content and presentation, albeit important, is just a small part of the overall effort:

The above is merely a taster, the full list is considerably bigger! That said, I hope the above conveys the extent of the task and the potential for interconnected, and ‘hidden’ issues, which includes the implications of ‘display formats’ which includes flight data; unsurprisingly, we may have to find a home for our PFD in every HMS display presentation. I’ve highlighted environment and workload analysis as obvious corollaries, although the trade space is actually much larger.

.