Human systems integration (HSI) is a systems engineering function with the goal of optimizing system performance and cost across the entire system lifecycle. It ensures that the human elements of the system are given at least as much consideration as any other component across the entire project. HSI is a relatively new and often misunderstood term. Here are the basics:
Scope of HSI and its Domains
HSI isn’t a new technical discipline. Rather, it’s the application of systems engineering principles to coordinate the efforts of several established disciplines, including:
- Manpower and Personnel Planning – The number, roles, and skills of personnel it takes to operate/maintain/support the system. Manpower refers to overall quantity of people while personnel refers to their skills and abilities.
- Training – The amount and types of personnel development required to ensure proficient operation/maintenance/support of the system; the design, development, and delivery of personnel development measures.
- Human Factors Engineering – Design of the human interfaces to the system to maximize effectiveness of operation/maintenance/support/training within the capabilities of the identified personnel.
- Human Survivability – Design of the system to minimize the likelihood of personnel casualty through: avoiding detection, preventing attack if detected, preventing system damage if attacked, and preventing human injury/death if the system is damaged. Preventing fratricide can also be a survivability concern.
- Environmental, Safety, and Occupational Health – Design of the system to minimize the system’s negative environmental impact, minimize the environment’s negative impact on the system, maximize safety of operation/maintenance/support, and minimize any negative effect on the health of the public and personnel.
- Habitability – The working conditions and accommodations of the operators/maintainers/support personnel to maximize morale and effectiveness.
The military services refer to these as HSI domains, and each service has slight variations on their included domains and how those domains are defined. However, far too much is made about these distinctions; though the fields which make up HSI are diverse and require multiple skillsets, they are highly interrelated and often overlap.
History
The U.S. Army created the Manpower and Personnel Integration (MANPRINT) program in the 1980s to address human performance and lifecycle cost issues with its systems. MANPRINT achieved significant success with Comanche helicopter1, reducing the engine maintenance toolkit from 134 tools to just 6. Many programs across the Army benefited from the application of this MANPRINT. The common refrain was to “equip the soldier, not man the equipment”2.
The UK Ministry of Defence adopted a similar program in the 1990s, dubbed Human Factors Integration (HFI). The DoD took notice of both HFI and MANPRINT and understood the importance of this approach to modern defense acquisitions. It added HSI to the DoD 5000 series of acquisition regulations with a brief reference in 2007 and a full policy in 2008. The most recent version (as of February 2019) reads:
The Program Manager will plan for and implement HSI beginning early in the acquisition process and throughout the product life cycle. The goal will be to optimize total system performance and total ownership costs, while ensuring that the system is designed, operated, and maintained to effectively provide the user with the ability to complete their mission.
https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500002_dodi_2015.pdf
MANPRINT had developed a number of best practices, guides, tools, and procedures, which served as a model for each of the military services as they developed their own HSI policies and training to comply with the acquisition regulations. There are now a number of great HSI resources across the military services.
Purpose
Discussions of HSI invariably focus on the domains, usually failing to acknowledge the real driving factor behind the initiative and thus leaving the audience wondering why it matters at all. For those unfamiliar with the DoD acquisition system3, HSI seems like unnecessary bureaucracy, more dead weight on already massive projects. HSI actually serves an important purpose for ensuring that system development addresses goals for every stage of the system lifecycle.
In the past, project offices and contractors tended to focus on balancing the system capabilities with the costs of development and production. Projects were evaluated (and contractors were paid) primarily based on these factors, so there wasn’t much incentive to care about the system’s operational and maintenance costs. Additionally, system capabilities assumed near-perfect human operations; any shortcomings between what the system could do and how it actually performed in the field could be attributed to human error. The result was that systems could be costly to operate and/or might not meet the mission needs.
I’ll illustrate with an example. Maybe we’re building an airplane and an analysis determines that adding 5 ft more wingspan would cost $200,000 per aircraft and increase the altitude ceiling by 3,500 ft. We’d look to the mission need and system requirements to determine if that additional capability is worth the cost.
We determine that it is worth the cost and we go ahead with the longer wingspan. An airplane flying at its aerodynamic ceiling can be difficult to keep stable because there is a very small difference between the stall speed and the critical mach limit4. The engineers address this by adding a mach meter to the cockpit and a warning in the manual, problem solved.
A few months after fielding, the aircraft experiences its first catastrophic mishap when the pilot exceeds the limits, just slightly, of the coffin corner; the aircraft stalls and enters a spin from which the pilot is unable to recover. The military quickly issues a policy preventing flights near the maximum altitude while they regroup. Additional training is created specifically to deal with this issue, making qualifying to fly this aircraft more difficult and thus also increasing the personnel washout rate. Both the training and the washouts entail significant costs, but the worst part is that they don’t totally solve the problem. Even with more highly-trained pilots, the mishap rate is higher than originally anticipated, reducing mission effectiveness and increasing costs (including lives lost).
How would HSI have solved this issue? During the initial cost capability analysis, the human systems integrator would have ensured that all of the potential impacts of the increased ceiling were considered. The safety engineer would have identified the increased risk of mishap, the training developer would have analyzed the cost to incorporate coffin corner flight characteristics training, the human factors engineer may have proposed an autopilot to better handle the stability issues, etc. This full analysis early on may have resulted in designing a more robust solution; at the very least, it would have given decisionmakers a more complete picture.
In short, HSI ensures that considerations beyond the immediate system functionality are included in the design. HSI recognizes that the cost/capability tradeoff must take into account human capabilities as well as the system capabilities and all lifecycle costs rather than just the development and production costs. The diagram below illustrates this balance.
Summary
Human-related cost and performance often have the largest impact on the system’s overall success. Yet these factors are often given the least consideration during the design process. HSI makes these impacts explicit, enabling them to be incorporated into engineering tradeoff analyses. Estimations of performance and cost are enhanced. The resulting system is likely to be more cost effective.
Do you have a burning question about HSI? A better way to depict the cost/capability balance? A strong opinion on which domain is most important? There’s a wide open comment box down below, ready for your input.
Footnotes:
- Cancelled prior to production. First Comanche and then Arapaho were slated to replace the Kiowa family of light reconnaissance helicopter. Both were cancelled because they offered similar capabilities to the Apache family and/or unmanned aircraft, but with a much higher unit cost.
- Attributed to Col. Jack A. Pellicci by the New York Times in 1987: https://www.nytimes.com/1987/06/21/business/making-arms-fighting-men-can-use.html
- If that describes you, a good place to start is How the Department of Defense Influences Systems Engineering Practice
- This is sometimes called the ‘coffin corner’ because the stall limit and mach limit make a nice little vertex on the airplane’s performance chart. Wikipedia has more.