Equipped-Human Reference Architecture

The successful application of most modern complex systems depends on human components as part of their system architectures. While the complexity of these systems is further complicated due to those human elements, most of these complex system designs may still be well-engineered using traditional systems engineering approaches and methodologies. Reference architectures (RA) are applied in this paper to demonstrate their use for defining systems that are human centered. That is, systems where the human is not the proverbial cog in the architecture rather where the human is the core emphasis of the design. This paper proposes a construct for Equipped-Human Reference Architecture (EHRA) as a useful systems engineering tool for addressing the complexity inherent in developing human centric systems. We assert that well conceived and constructed EHRA could provide a reusable and evolving set of architecture guidelines and constraints that define the complete equipped-human design space. Additionally, well-structured EHRA should be extensible to provide usable systems engineering design tools in order to aid equipped-human systems (EHS) developers when they are designing and evolving specific EHS solution architectures. © 2015 The Authors. Published by Elsevier B.V. Peer-review under responsibility of the scientific committee of Stevens Institute of Technology.


Introduction
Human operated systems are by their very nature complex. However, human-centered systems present designers with engineering challenges that are extremely complex and not well understood. We assert that traditional systems engineering architecting approaches are not robust enough to aid human-systems engineers in managing the added inherent complexity of designing and implementing human-base architectures. This paper introduces and uses Equipped-Human Reference Architecture (EHRA) as a systems engineering approach for managing complexity in human-based system architectures and solutions across the equipped-human design space. The paper begins by reviewing some of the available literature on the subject of reference architecture (RA) followed by a definition of EHRA in the context in which it is presented. Next, a description of the conceptual elements that constitute EHRA are presented and described. After defining the requisite structure of EHRA, a proof-of-concept, Unified Modelling Language (UML) model will be proposed that presents EHRA as a useful systems engineering tool. The proof-of-concept model EHRA will then be used to illustrate the development of EHS solution architecture: police officer.

Literature Review
Reviews of the available academic and professional literature related to reference architecture (RA) were conducted in preparation of this paper. While source literature on the topic of RA is rich, there is clearly not a single accepted ontology that describes RA for all systems engineering applications. RA specifically related to EHS is sparse, if non-existent.
The earliest definitions of RA were found in Engineering Systems Monograph: The Influence of Architecture in Engineering Systems, by Crawley and de Weck et al. where they defined architecture as "a necessary but incompletely understood property of complex engineering systems 1 ", and architecting as, "a necessary but incompletely understood step in creating them 2 ." In 2008, Cloutier and Muller et al. provided a detailed description of RA emphasizing architectural consistency and by defining key guiding principles for business reference architecture 3 .
Much later, in 2013, Muller (alone), proposed a process for developing and maintaining reference architecture entitled, A Reference Architecture Primer, in which he stated that RA, "captures the essence of the architecture of a collection of systems 4 ", and that the, "purpose of a Reference Architecture is to provide guidance for the development of architectures for new versions of the system or extended systems and product families 5 ." All the academic studies propose a process for developing and maintaining reference architecture, which the researchers have used for design and development of the EHRA.
The DoD has developed a Reference Architecture Description in which the purpose of RA is described as, "guidance and direction to the DoD enterprise on the better use of Reference Architectures for guiding and constraining architecture descriptions, developments and usages for current and future capabilities 6 ." In recent years, the United States Navy, Air Force and Army have all adopted RA approaches for developing combat systems. The Air Force developed the Joint Strike Fighter (F-35) with the RA approach of reducing costs and minimizing design risk through the reuse of common components such as the airframe, avionics, communications and weapon systems 7 . More recently, the United States Navy has adopted some of the modularity principles of RA in the design of Littoral Combat Ships. The Navy states that, "the underlying strength of the LCS lies in its innovative design approach, applying modularity for operational flexibility 8 ." Currently, researchers at the Army Natick Soldier Research, Development, and Engineering Center (NSRDEC), in Natick, MA, are developing a systems engineering approach that will enable Soldier System designers to use RA as a means of engineering Soldier Systems. The Army's approach is to, "create an analytical model-based capability through which changes in Soldier as a System (SaaS) inputs (loads, technology/equipment, physiological & cognitive state, stress levels, training, TTPs) may be assessed to predict changes in SaaS and small unit performance in operationally relevant environments. The capability includes the architecture, system models, quantitative analysis tools, supporting infrastructure such as databases, human performance sensors, analysis methods, and comprehensive assessment capabilities 9 ." The NSRDEC approach was the impetus for the exploration of EHRA in this paper.
The Systems and Software Engineering-Architecture Description (ISO/IEC/IEEE 42010) defines a Conceptual Model of Architecture Description. The ISO/IEC/IEEE 42010:2011 Systems and Software Engineering Architecture Description specifies the, "creation, analysis and sustainment of architectures of systems through the use of architecture descriptions 10 . While the IOS/IEC/IEEE 42010 definition does not explicitly define RA, many of the specifications and constructs defined within the description are common to the key elements of RA described by other sources.
Raytheon has defined RA for the architecturally based Command and Control Systems that they have developed for their customers known as the Raytheon Mission Architecture Program (RayMAP). Raytheon states that, "RayMAP is made up of several elements that collectively provide the foundation for solid, disciplined architecture capabilities. RA is being used to promote commonality, reuse, interoperability, increased responsiveness and affordability in system and enterprises 11 ." In 2002, IBM began promoting their Rational Unified Process ® (RUP ® ) which encouraged the adoption of reference architecture, not only to aid in design, but also as an integral part of corporation's business strategy model 12 . The Oracle IM Reference Architecture is a "classically abstract architecture" designed to aid corporations in developing IT infrastructures and processes that allow the company to fully exploit the information that is contained in large data sets. In an article entitled, Inputs of a Big Data Reference Architecture, the author, Sunil S. Ranka, supports Oracles approach for using reference architecture as a starting point for designing and building big data IT exploitation systems 13 .
Mike Rollings, the Enterprise Architectures Research Director at the Burton Group, asserts that, "making architecture relevant in an organization requires more than the application of brute force. It involves relentlessly pursuing business outcomes and applying both influence and integrated governance. This is the only way to improve the decisions influenced by architecture 14 ." WIKIBOOKS explores RA as a construct in the design of a new type of production system, which is capable of self-expansion that they call a Seed Factory. The following excerpt from this publication provides the most accurate description of RA.
[RA is] a high level design for a class of shared solutions, exhibiting their key concepts, relationships, and features. It is a starting point for later stages of design and becomes customized and more detailed for specific applications. A reference design saves effort because each application does not have to repeat the early stages of development. At the architecture level it is used to provide common language and understanding for Stakeholders, parties with an interest in a project. It is also used to identify technology risks and readiness level (TRL), and make early estimates of cost and schedule. It includes system level goals, design principles, an architecture description, high level interactions between elements and the system environment, general element requirements, and element descriptions. Supporting data for reference architecture shows the reasoning for how it was arrived at. It includes data sources, analyses to support concept selection, and tracking from goals to lower elements. Reference architectures should be updated as the system concepts and specific applications become more detailed 15 .

Common RA Concepts
While no single definition of RA would appear to exist, there are several key, common characteristics of RA that are consistently stated throughout the literature. From this review, we propose that the highest-level objective for any RA should be in defining an architecture that describes and bounds the design space of possible solutions architectures. For this paper that design space is defined as any EHS. Additionally, there would appear to be agreement that RA should be expressed as abstractly as possible while also capturing the core elements that are common to any possible solution architecture contained within a design space. RA must capture the key operational and environmental context in which the specific derived solution architectures are intended for use.
RA should be modular and, thus, reusable for designing, or redesigning, disparate solution architectures within a given design space. Next, RA should be capable of evolving by capturing lessons learned from predecessor system solutions and being capable of representing that captured knowledge as usable guidelines and constraints for use by future solution architecture designers.
Finally, RA should provide useful design tools that aid system designers in developing new solution architectures and/or in extending existing solution architectures within the design space of the RA. All these studies recommend development of a RA and give insight on the RA properties and development process. In this paper we use these core principles to define, develop and apply EHRA to the EHS design space.

Definitions
For the purposes of this paper, Equipped-Human Reference Architecture (EHRA) is an abstract representation of the common objects, design guidelines and constraints, which represent the equipped-human design space from which specific Equipped Human Solution (EHS) architectures are derived. Equipped-Human System Solution Architecture (EHS solution architecture) represents a specific instance of EHS system design that is engineered following the principles of the traditional systems engineering Vee lifecycle model.

Elements of the Equipped-Human Design Space
EHS solution architecture describes a human who has been equipped to perform some task(s) in some operational environment or a group of humans who have been equipped to perform some task(s) in some operational environment. The five abstract elements of the equipped-human design space are illustrated in Figure 1 and constitute the Human-Equipment-Task (H-E-T) Framework 16 that defines the design space for EHS. Note that the H-E-T framework is also applicable to groups of similarly equipped-humans such as a fire fighting company or a soldier squad who have been trained to perform combined missions. The five central elements of the Equipped-Human (EH) design space are the human, his/her equipment, the task they are being equipped to perform, the environment in which the task is executed and the EHS objective. It is difficult to think about the EHS and design of the first three elements separately. The equipment depends on the task to be performed, and the environment. The task that can be performed depends on the human's abilities. Each of these elements is interrelated and comprises an integrated EHS. The environment cannot, of course, be "designed" or changed in any sense, but a choice can sometimes be made about the environment in which to conduct a given task. In previous work it has been demonstrated that the interrelationships between these elements server to define the measures of performance (MOPs), measures of effectiveness (MOEs) and technical performance measures (TPMs) of any EHS.
Different human class types can be distinguished by their capabilities, training, and experience (behaviour). For the development of the proposed EHRA in this paper, capabilities, training and experience will be replaced with the terms knowledge, skills and abilities, respectively.
The equipment that comprises the EHS would include that which the equipped-human wears or carries, and also various transport equipment, communications equipment and other equipment necessary to complete his/ her specified tasks. For the development of the proposed EHRA in this paper, equipment types are defined by the characteristics of function, properties and capabilities. The mission will specify tasks that the EHS is intended to address.
The physical environment includes terrain, temperature, moisture level, time of day, water sources, and other conditions define the range of environments a given EHS must operate in to carry out their task. The physical environment can be characterized as urban, remote, sea, air, land, space, etc. Additionally there are operational environment considerations that are human centered. These operational variables include social behaviour aspects of the human entity that must be aligned with the task objectives. Development and Engineering Center (NSRDEC). The illustration depicts how EHRA provides systems engineering guidance for adapting the abstract concepts contained within the H-E-T framework (human, equipment and task) into a Human as a System (HaaS) architectural that provides guidelines, which systems engineers may use, or reuse, to build actual EHS solution architectures. At the highest-level of the EHRA Super Vee Model, the H-E-T framework defines the fundamental abstract blueprint, or strategy, encompassed in all EHS solution architectures. The second-level of the EHRA Super Vee model describes the Systems of Systems (SoS) architectural guidelines and constraints, or EHRA, that are defined in terms of the HaaS architectural construct, or human as an equipment chassis. The third-level of the EHRA Super Vee model describes how EHS system developers use the EHRA HaaS architecture to design specific EHS solution architectures. The EHS solution architecture is the specification and design that allows the systems engineer to build, or extend, specific EHS solution architectures that are derived through the application of the higher-level EHRA HaaS guidelines.

EHRA Super Vee Model
While there are many RA model representations available in the literature, most are too specific and narrowly focused to be adopted for use in describing EHS. As illustrated in Figure 3, the closest RA model approximation to that of the EHRA HaaS Super Vee Model is provided by Cloutier and Muller et al 19

Proof-of-Concept Model
While the EHRA Super Vee Model defines the conceptual application of EHRA for developing EHS solution architectures it does not provide a real systems engineering tool for developing systems. For any RA to be of use to systems engineers, the RA must not only be instantiable, but the RA must also be extensible. Therefore, there must be a mechanism for system developers to add, or extend, specific solutions architecture elements to the RA, which in turn, will aid other systems engineers in defining and building actual EHS solution architectures based on the guidelines provided by the RA. Figure 4 is an illustration of the initial EHRA HaaS UML model that was developed to describe EHRA, during research performed preceding this paper 21 . The EHRA UML HaaS Model attempts to capture the core system components and guidelines that are necessary to define the baseline equipped-human described in the H-E-T framework. Extending the EHRA HaaS UML Model though the use of subclasses allows EHS developers to instantiate specific EHS solution architectures throughout the EHS design space. In general, the EHRA UML Model depicts an architecture that is simple and balanced.

EHRA HaaS UML Model
There are many possible methods for representing RA. These methods include sophisticated relational databases, detailed process diagrams and even simple drawings. Cardwell advocates for the use of Unified Modeling Language (UML) when developing reference architectures 22 .
The EHRA UML HaaS Model, illustrated in Figure 4, attempts to capture the core system components and guidelines that are necessary to define the baseline equipped-human described in the H-E-T framework. Extending the EHRA HaaS UML Model though the use of subclasses allows EHS developers to instantiate specific EHS solution architectures throughout the EHS design space. In general, the EHRA HaaS UML Model depicts an architecture that is simple yet balanced. The UML architecture is abstract enough to capture the concepts described in the H-E-T framework but specific enough to be extended to actual EHS solution architectures through the addition of subclasses that may subsequently be instantiated for actual EHS solution architectures.

EHS Solution Architecture
A well-recognized EHS solution architecture is that of a police officer. Police officers are individual humans who have been equipped and trained to respond to a multitude of different tasks related to law enforcement and public safety. Possible EHS solution architecture: police officers are defined by the example sub-classing, illustrated by the bright blue coloring in Figure 5. A solution architecture that is similar to that of the police officer is the solution architecture: firefighter. Each EHS is trained and similarly equipped to respond to emergency situations. Thus both EHS solution architectures share common solution architecture systems components such as uniforms, radios and CPR training. However, it is unlikely that the solution architecture: firefighter should be equipped with a firearm or that the solution architecture: policeman would ever be trained in operating a fire hydrant and hose. Because of the commonality at the higher level of the EHRA (e.g., emergency response training; hostile environment conditions; etc.), EHS developers can take advantage of these reusable aspects from other EHS when designing similar EHS solution architectures. Regardless of the specific EHS being developed, all EHS share the common system components defined in the EHRA HaaS UML Model, which should be reusable by all EHS developers when developing new EHS solution architectures.

Discussion
Ideally, EHRA provides many advantages for developers of EHS solution architectures. EHRA is intended to provide reusable guidelines and constraints that capture EHS patterns, and allows all developers of EHS to learn and profit from the experience of predecessor design efforts. The ability to reuse past EHS design information can aid system developers in scoping the cost and schedule for developing new EHS solution architectures by focusing systems engineering resources on the areas of the EHS design elements that are new and represent the greatest risk to engineering EHS. Because EHRA provides reusable, time-tested modules for developing EHS solution architectures, the resulting EHS solution architectures should be of high quality and should be extremely dependable and maintainable until changes in human training; equipment technology and/or new missions require a replacement EHS solution architecture to be developed. Additionally, since EHRA should continue to provide current EHS design space engineering information to systems engineers, the resulting in EHS solution architectures that are developed should be very well understood, robust and scalable.
Finally, the use of EHRA may present EHS systems developers with emergent systems engineering techniques that could not be realize using more traditional methods. Practically, the promise of ideal EHRA is still far from being a working, dependable systems engineering tool. However, in the past three years remarkable strides have been made in developing more constrained, specific EHS RA. For example, the NSRDEC has been developing Soldier System Reference Architecture, using the constructs describe in this paper, for engineering Soldier Systems that, focus less on equipment, and provides equal weighting to the soldier's performance and the soldier's mission. EHRA is a higher-level abstraction of the NSRDEC's approach to engineering soldier systems engineering approach.
While the H-E-T Framework provides a novel first step for characterizing EHS, the current lack of understanding about how human will react in a given environment and the scientific community's inability to quantitatively model these emergent human qualities limits the scope of EHRA development and presents the greatest systems engineering challenges for developers of all EHS solution architectures. The EHRA HaaS UML model presented in this paper represents an initial attempt at representing EHRA in a form that is extendable and useable by systems engineering practitioners for developing EHS solution architectures. The model works well to encapsulate the abstract H-E-T concepts into a reusable EHRA HaaS architecture from which actual EHS solution architectures can be derived through extension of the EHRA class structure. The UML model is abstract and is not overly complicated. While there are still ambiguities present in the H-E-T framework with respect to the EHS operational environment, the model structure captures the system context well in relation to operational considerations. The current EHRA UML model may be used to instantiate new EHS solution architectures as demonstrated in the EHS solution architecture: police officer. Finally, the current EHRA UML model is simple, but not too simple.
However, this initial model does have deficiencies. Firstly, the model does not provide EHS system developers with design aids for assessing and measuring EHS solution architecture performance. Additionally the UML model fails to provide a robust mechanism for capturing and representing predecessor EHS development information to EHS system developers. In fact, there is strong evidence that EHRA may not be achievable in the construct of a single systems engineering tool. Rather, it may be necessary and advantageous to have a set of systems engineering tools, such as UML models, databases, and requirements management schema, which when combined present EHS system developers with a robust and complete set of tools that represent more specific EHRA. In the final analysis, the EHS design space may be too broad to be represented by a single EHRA. However, the ultimate value of EHRA may be found to be in its use as a validation tool for more specific EHS RA, such as Soldier Systems Reference Architecture or as Police Officer Systems Reference Architecture.

Summary and Conclusion
In summary, EHRA is an evolving systems engineering construct that could be used by EHS system developers to inform the design, development, deployment, assessment and sustainment of a solution specific complex system architectures that fall within design space of a EHS. EHRA should capture the fundamental concepts of the complete EHS design space as expressed in the H-E-T framework. EHRA should also provide mechanisms to iteratively update and re-present those concepts, so that they can be used, and reused, by different EHS systems developers to build and deploy specific EHS solution architectures. In this paper, the application of EHRA to the systems engineering methodology has been ideally expressed using the EHRA Super Vee model. A practical EHRA HaaS UML model has been presented in this paper that may be used by systems engineers to instantiate EHS solution architectures within the EHS design space.
As an abstraction, the H-E-T framework defines the needs for all EHS. As a model, the EHRA represents EHS as HaaS architecture. As a practical systems engineering tool, the EHRA HaaS architecture provides system developers with a set of general, reusable and evolving systems engineering guidelines and constraints from which any EHS solution architecture may be realized. While there are many practical approaches that may be used to construct RA, this paper presents an EHRA UML modeling approach that is both usable, and reusable, by systems engineering practitioners and is extensible for EHRA developers and maintainers.
In conclusion, EHRA should provide EHS developers with a reusable, modular set of guidelines and constraints for engineering EHS solution architectures across the spectrum of the EHS design space. In order to provide those capabilities to EHS systems engineers, the EHRA construct must encompass the following characteristics: • EHRA should be simple, but not too simple, capturing and representing only those aspects of EHS that are common and necessary to all EHS. • EHRA should capture the operational and environmental context for a given EHS solution architecture.
• EHRA should be in a form that is usable and suitable for practitioners of systems engineering.
• EHRA should provide EHS developers with the necessary design aids for engineering EHS.
• EHRA should be extensible to predecessor EHS solution architectures and instantiatable for the development of new EHS solution architecture within the EHS design space. • EHRA should evolve with changes to the EHS design space as new EHS solution architectures are built to address new missions and/or to incorporate novel technologies so that future EHS developers can reuse the components and information gained through those systems engineering advances in future EHS implementations.
The EHRA HaaS UML model presented in this report demonstrates an initial approach for how EHRA may be represented in the form of a UML model as a useful systems engineering tool, which, in turn, may be used by EHS system developers to instantiate different possible EHS solution architectures across the spectrum of the EHS design space. While additional research and development are still necessary, we believe that the EHRA HaaS UML Model presented in this report represents an important first step for understanding how EHRA may be structured in order to provide a practical and useful system engineering tools for current and future developers of EHS solution architectures.