Study of the Human View

Study of the Human View
By: Pasi A Linnosto
October 2013
Key Words: Enterprise Architecture, Human View, Generalised Enterprise Reference Architecture and
Methodology (GERAM) Lifecycle and Personnel Pentagon.

Pasi A Linnosto
Page 1
TABLE OF CONTENT
1. INTRODUCTION 3
2. LITERATURE REVIEW 6
3. METHODOLOGY 17
4. REVIEW OF THE HUMAN VIEW & GERAM 23
4.1. THE NATO HUMAN VIEW 23
4.2. THE CANADIAN HUMAN VIEW 28
4.3. GERAM LIFE CYCLE 32
5. HUMAN VIEW MAPPED TO GERAM 37
5.1.1. IDENTIFICATION 39
5.1.2. CONCEPT 43
5.1.3. REQUIREMENTS 46
5.1.4. PRELIMINARY DESIGN 59
5.1.5. DETAIL DESIGN 65
5.1.6. IMPLEMENTATION 69
5.1.7. OPERATE 71
5.1.8. DECOMMISSION 73
6. CONCLUSION 75

Pasi A Linnosto
Page 2
FIGURES
Figure 1: Mapping Method....................................................................................................................................22
Figure 2: NATO Human View Metamodel...........................................................................................................24
Figure 3: GERAM Life Cycle ...............................................................................................................................33
Figure 4: GERAM Lifecycle Activity ...................................................................................................................35
Figure 5: Requirements to HV Mapping ...............................................................................................................48
Figure 6: HV-3 Standard Figures ..........................................................................................................................51
Figure 7: Risk Bow-Tie .........................................................................................................................................56
Figure 8: Three Point Estimate..............................................................................................................................58
Figure 9: Preliminary Design to HV Mapping ......................................................................................................59
Figure 10: Organisations Personnel Plot ...............................................................................................................61
Figure 11: HV-E Role to Task Mapping ...............................................................................................................65
Figure 12: Detail Design to HV Mapping .............................................................................................................66
Figure 13: Human Dynamic View schema............................................................................................................70
Figure 14: Career Projection Example ..................................................................................................................72
Figure 15: Decommission to HV Mapping ...........................................................................................................74
TABLE
Table 1: HV Outline of the Canadian....................................................................................................................29
Table 2: List of HV-6 Data Elements....................................................................................................................31
Table 3: Human View Reference Chart.................................................................................................................38
Table 4: System HV-2 Establishment Model ........................................................................................................46
Table 5: System Requirements and HV-9 Human Tasks ......................................................................................49
Table 6: HV-4 model for ATM site-A...................................................................................................................52
Table 7: HV-8 Risk Assessment Table..................................................................................................................57
Table 8: HV-5 Physical Characteristics Flight Strip Control ................................................................................62
Table 9: Sample HV-5 model for RAPCON Operator..........................................................................................63
Table 10: Canadian HV-5 Example.......................................................................................................................64
Table 11: List of Acronyms...................................................................................................................................78

Pasi A Linnosto
Page 3
1. INTRODUCTION
It is assumed that all engineered systems have a human aspect and it’s difficult to think of a system that does not
need a human element to exist. Every system from piloted to unmanned aircraft, a bank’s deposit system, to the
standalone ATM requires people to design, build, maintain and control its function during its life history;
therefore it is difficult to think of any system that doesn’t need some form of human interaction during its life.
The reason why we study the human element in Enterprise Architecture (EA) is because humans play a
significant role in the system. The significance of the human element can be calculated as a cost Handley
concluded in one of her papers’ by stating that “Over the life cycle of most system the human element is
considered the most costly resource” (H. Handley & Smillie, 2010), and the efficient use of resources within a
system can reduce cost across the enterprises’ lifecycle. By ignoring the human element we risk developing
flawed systems.
In July 2007 the North Atlantic Treaty Organization (NATO) Research and Technology Organisation created a
panel to discuss the purpose of multi nation human activities and the role they play in a system. The panel was
named “Human Factors and Medicine Panel 155” was formed to workshop this idea and develop a way to
explicitly represent of unique human attributes. The result was a NATO-wide Human View (HV) model
independent of any specific architectural framework. Because the study into Human Views is relatively new to
the defence Enterprise Architecture frameworks, most of the current military frameworks do not have the
panel’s findings incorporated into their frameworks and therefore do not adequately account for the human
element in their lifecycles (H. Handley & Smillie, 2008). By continuing the study into human view products and
elements, the participants have refined the original NATO findings to a form that could be used to complement
other established defence frameworks such as the Department of Defence Architectural framework (DoDAF)
(Defense, 18 May 2009), Ministry of Defence Architecture Framework (MoDAF) (MoD, 2008) and Department
of National Defence and the Canadian Forces Architecture Framework (DNDAF) (Framework, 2011).
The motivation for conducting this study came from the defence frameworks failure to capture human-centric
design aspects for systems operation and maintenance (H. A. Handley, 2012). The evolution of the study into
Human View for Architectural Frameworks for the military followed with the idea of incorporating elements
and viewpoints for the human aspect into other architectural frameworks.

Pasi A Linnosto
Page 4
Research on the Human View (HV) has predominantly been carried for the defence industries to partially map
Human Views to existing Architectural frameworks including MoDAF (Bruseberg, 2010), DoDAF (H. A.
Handley, 2012) and DNDAF (Coats C, 2013). These efforts delivered ontological models (in form of
metamodels, but not full blown ontological theories), which can be used to mandate specific model types to
populate the human view of the system of interest. The question is therefore, weather non-military Architectural
Frameworks are amenable to use of these human view related concepts, and is so how?
The specific aim of this paper is to take one further step and discover if the ongoing study into Human View is
adaptable to the GREAM lifecycle framework, given its status as the ISO 15704 standard, which describes the
requirements that architectural frameworks should satisfy. To clarify the question: while ISO 15704 clearly
mandates the representation of the human element on an equal footing to the automated element of a system, the
question remains how the Defence Architectural Frameworks’ new development relates to this requirement.
The reason for selecting an enterprise architecture framework for mapping was to cover the widest possible
range for human activities and human interaction across the entire life cycle of the system of interest. During an
enterprise lifecycle the human elements (people / employees / enlisted personnel) will be called upon to plan,
execute, test, monitor and complete actions on the system; therefore the current study into human views should
consider all human activities that take place during the lifecycle of an enterprise. An enterprise lifecycle (i.e. the
lifecycle of the enterprise-as-a-system) comprises many system lifecycles (FAWG, Feb 2001) and it is not
possible to discuss in detail all types of system lifecycles in one dissertation; therefore this study will map
existing HV elements to the GERAM Lifecycle activities and give examples using an Air Traffic Control
System as one example of a system lifecycle where practical examples are needed.
The goal for mapping the HV into a GERAM Lifecycle will be to see if the current study into Human Views is
complete, by mapping human elements to lifecycles an established framework entity such as the ones illustrated
in GERAM. The reason for choosing GERAM as the preferred EA framework was because it mandates the
consideration of both Human and Machine elements in each lifecycle activity for each entity in the enterprise
(called ‘enterprise entity’ in GERAM), thereby enabling this research to be affixed to an established EA
baseline.
A number of HV studies will be considered during this study before selecting the most suitable and
comprehensive Human View concepts to map. (Later in this dissertation we may refer to ‘Human View

Pasi A Linnosto
Page 5
entities’, meaning the human view related concepts in the human view ontology, this is not to be confused with
the concept of ‘enterprise entity’).
The technique used in this paper can be described as Conceptual Analytical Research (Järvinen, 2004). Because
the research compares concepts by using logical arguments and analytical thinking, along with established an
architectural framework (GERAM lifecycle), with the theoretical findings of Human Views research performed
by military architectural framework developers.
This paper will advance the research in Human Views by identifying gaps in the current study suggest clearer
methods or approaches to aid understanding of what is required in each Human View. The answer is likely to
i) Shed light on possible further development that may be needed for ISO15704 and GERAM; and
ii) Identify possible gaps of completeness in the effort of Defence Framework developers, thus the
conclusion of this dissertation may be of use for both communities.

Pasi A Linnosto
Page 6
2. LITERATURE REVIEW
This study will review several efforts to incorporate the Human View (HV) and Architectural Frameworks with
the focus being on the human element in the system, including:
• Human View Products developed by Defence Research and Development Canada (Defence R&D
Canada).
• Generalised Enterprise Reference Architecture and Methodology (GERAM) Version 1.6.3 of 1999,
which is also Annex to ISO15704
• North Atlantic Treaty Organization (NATO) Human View (HV)
• Human View for Ministry of Defence Architecture Framework (MoDAF), United Kingdom
Other HV ontological (and associated views), which formed part of Handleys’ earlier work (H. Handley &
Smillie, 2008) were also reviewed but, not used in this thesis because of their lack of available detailed material.
Ø Maritime Headquarters with Maritime Operations Centre (MHQwMOC) Concept Based Assessment
US
Ø Royal Netherlands Navy (RNLN) Manning Program
Ø Human Systems Integration Human View Dynamic Architect (HIS HVDA) US
Terms used in Enterprise Architecture are not always easily understood. For the purpose of clarification the
following section will define commonly used in the paper and expand on their definition.
Architecture is defined in ANSI/IEE Std 1471-2000 as, “The fundamental organization of a system,
embodied in its components, their relationships to each other and the environment, and the principles
governing its design and evolution”. Architecture is also defined as, “the structure of components, their
interrelationships, and the principles and guidance governing their design and evolution over time” (IEEE
1990) (Stewart, Baker, Pogue, & Ramotar, 2008).
DNDAF Version 1.8 defines Enterprise Architecture as “A collection of strategic information that defines
a business, the information and technologies necessary to operate the business, and the transitional

Pasi A Linnosto
Page 7
processes necessary for implementing new technologies in response to the changing needs of the business.
It is represented through a set of integrated blueprints” (Annex A p13 (Framework, 2011)).
Human Factor Integration (HFI) in the UK, which is the same as Human System Integration (HSI) in
the US, puts people at the centre of attention. The main question asked by practitioners in this field is, “Can
this person/these people, in this job, with this training, perform these tasks, using this equipment, to these
standards, under these conditions?” HFI is a bottom up structure; with the exception of the so-called
‘cognitive work analysis’ (CWA: Vicente 1999: Naikar et al 2003) (Paragraph 3.5 p27 (Bruseberg, 2010)).
Systems Engineering (SE) there are twelve systems engineering roles described by INCOSE. Of the
twelve roles five are Life-Cycle roles and five are Program Management roles, the remaining two are
neither (Sheard, 1996), each of the twelve roles or billet’s are described as a job that has a defined structure
with a one-to one correspondence. Billets may be allocated amongst a group on system engineers who
specialise in a subsystem or a software component. For example, architects ask (and respond to) the
question “ Can these capability requirements be achieved through these operational
activities/nodes/information networks, fulfilled with these technology functions and structure, over these
timescales, given these connectivity standards, technology trends, and organizational structure?”(Paragraph
3.5 p27 (Bruseberg, 2010)).
Architectural Viewpoint: systems of interest need to be considered by various stakeholders, each with a
set of concerns regarding the system. An architectural viewpoint (as defined by IEEE 42010:2011, and
GERAM v1.5 (Bernus & Noran, 2010)) can be used to determine what representation of the system and to
what level is appropriate to answer such stakeholder concerns. The content (or type) of models, which are
necessary to give answers to the questions defined by the viewpoint can be expressed using an ontology that
is often expressed as a metamodel.
A particular set of concerns is the consideration of the role of the human in the system, and may be called a
‘Human Viewpoint’ (using ISO42010 terminology), or using old terminology ‘Human View’ (see below).
An Architectural Product is a specific representation of a particular aspect of that perspective and
typically represented by graphical, textural and tabular items that result from the process of building the
architectural description or model (H. Handley & Smillie, 2008).

Pasi A Linnosto
Page 8
An Architectural View represents a perspective on a given architecture (H. Handley & Smillie, 2008), as
required to be seen by a stakeholder who needs answers to some particular set of concerns.
It is also important to note that an Architectural View will consist of one or more Architectural Products (H.
Handley & Smillie, 2008).
Human View’s (HV) provide a link between SE and HFI combining the two together. A model that is
populated with architectural data is called a view. An organised collection of views is given the name
viewpoints (H. Handley & Smillie, 2008).
According to (H. Handley & Smillie, 2008) an “Architectural framework defines a common approach for
development, presentation and integration of architectural description”. However it is important to note that
using the same architecture framework in different context (different stakeholders and concerns) the actual
architecture viewpoint, products and views may be markedly different, and consequently so would be the
ontologies to be adopted.
The history of Enterprise Architecture in the defence context began in 1996 when the US Department of
Defence Architectural framework was derived as the foundation of a method to design and commission large-
scale system engineering projects. Other nations also developed similar Architectural frameworks to DoDAF
specific for their own military needs such as the Ministry of Defence Architectural Framework United
Kingdome MoDAF and Canadian Department of National Defence Architectural Framework DNDAF.
Typically, these frameworks adopted an integrated metamodel based on the typical architecture viewpoint
considered important for the design and commission of large-scale system engineering projects and their
products. By developing integrated metamodel EA practitioners are able to ensure that data elements defined in
one architectural product are considered in other applicable products. Linking the viewpoints and views in this
fashion ensures that everything is considered for the entire project (H. Handley & Smillie, 2008).
A literature review of the NATO HV metamodel was conducted to find common descriptions for elements that
could be used during the Mapping phase of this paper.
The history of the study into Human View came about with the introduction of a NATO Human View
metamodel that sort to include the Human aspect of systems that was missing in these architectural Frameworks.

Pasi A Linnosto
Page 9
The NATO RTO HFM 155 Human View Workshop panel was formed to formulate an approach to include
Human factors into current Enterprise Architecture (H. Handley & Smillie, 2008).
The Panel’s aim was to document the unique implications humans bring to the system design, which in turn
provided the following five benefits to including the Human View into Enterprise frameworks:
• Enables an understanding of the human role in enterprise architecture
• Provides linkage between manpower, personnel, training and human communication
• Early recognition of human effort in the system being proposed
• Universal acceptance of human elements across international forces
• An improved framework provides a more complete set of attributes for system data.
The results of the NATO RTO HFM 155 Human View Workshop in July of 2008 were the creation of a Human
View (point), which will be discussed in greater detail in section 4.1 of this paper.
In 2004, there was an attempt to incorporate human aspects into Operational View products, as well as similar
attempts both in Canada and the United Kingdom to include Human activity as part of their frameworks was
made. HFI’s were consulted to add manpower, personnel, training, and business factors engineering aspects to
the study. The addition of Dynamic models then showed how the model would change over time and respond to
external stimuli (H. Handley & Smillie, 2008).
The first attempt to utilise the NATO HV model was to build elements that complement MoDAF, to assist in the
creation of a socio-technical system.
The results of the study suggested the inclusion of seven (7) initial elements to represent the Human View (H.
Handley & Smillie, 2008) which are as follows:
HV-A. Capability Constraints - the impact on the system from human factors, ie work hours, training
human endurance.
HV-B. HFI Quality objectives and metrics – A repository of priorities, values and performance criteria to
metrics and targets.
HV-C. Social network structure – Information exchange between human-human, groups and teams.

Pasi A Linnosto
Page 10
HV-D. Organisational dependencies – The individuals positions in the organisation what he/she can and
cannot do.
HV-E. Human function definitions – Defines specific human functions in the system.
HV-F. Human functions to role and competency mapping – Specified requirements and high-level
solutions for Human Resources.
HV-G. Human performance dynamics – Creates predictions, or a set of predictions, for external stimuli
and career growth.
For the next NATO HV model the panel consisted of many different country representatives; all of who used
different architectural approaches tailored to their individual needs. During the workshop similarities between
the architectural approaches were collected to form the NATO Human View products.
The purpose of the NATO Human View is to define human centric roles in a system, by creating a repository of
human operation activities, tasks and communications to complete a task to supports the operational
requirements.
Ms Anne Bruseberg was the next evolution of the Human View metamodel in 2010. The paper significantly
expanded the understanding of Human View with an aim to build elements that complement MoDAF that
would assist in the creation of a socio-technical system (Paragraph 4.1 p31 (Bruseberg, 2010)).
The NATO HV Metamodel discussed in this paper was published by Ms Anna Bruseberg in 2010 for BAE
systems (Bruseberg, 2010). The publication aligns the NATO HV Metamodel to MoDAF and are as follows: -
HV-A. Personnel Availability
HV-B. Quality Objectives and Metrics
HV-C. Human Interaction Structure
HV-D. Organisation
HV-E. Human Functions and Tasks
HV-F. Roles and Competencies
HV-G. Dynamic Drivers of Human Behaviour.

Pasi A Linnosto
Page 11
The NATO HV Metamodel described by Bruseberg has three (3) distinct groups. The first group refers to the
Human Structure and Process and combines HV-A, HV-D to HV-F. The second group refers to the human
aspects of technology and infrastructure (i.e. what to build), which is described in both HV-C, HV-E. The third
group refers to the overarching design aspects in HV-B and HV-G (Page 31 (Bruseberg, 2010)).
Bruseberg described each of the seven NATO viewpoints (Part 2 Table 8 & Section 5.3 to 5.7 (Bruseberg,
2010)) as follows: -
i. The first NATO viewpoint is HV-A Personnel Availability and as the name suggests the central question
asked is, Who could be made available and what personnel process is required?
Bruseberg conducts an analysis in HV-A and defines requirements and formal processes to ensure that
actual people with the right characteristics and in the right numbers are available to fill human roles as part
of a posting or a job.
The HV-A element can be used as a starting point to integrate Human Viewpoints into an existing
Architectural framework’s mandatory metamodel or audit an entity and improve human aspects.
The HV-A viewpoint can also used to determine at the onset what capabilities are available within the
organisation thus highlighting any shortcomings. There may be an excess of employees in the organisation
or a deficiency.
ii. The second NATO viewpoint HV-B Quality Objectives & Metrics asks the central question asked is, How
may human related benefits be expressed and measured? We conduct analysis of HV-B to create a higher
level, specifying the non-functional human-related design objectives in support of the enterprise metrics,
which is critical to cover all needs and to drive HF design efforts from early stages.
Again HV-B is not a good starting point for beginning a project because it requires functional inputs to
analyse. In this view defining suitable quantifiable metrics early is essential for non-functional requirements
specification, and updating is needed as more information becomes available.
iii. The third NATO viewpoint HV-C Human Interaction Structure asks the central question, What are the
human integration structures to be supported by technology solutions? We conduct analysis of HV-C to
discover potential role interaction requirements as the foundation for defining the need for technology
supporting information use, transfer and sharing.

Pasi A Linnosto
Page 12
HV-C provides high-level structural requirements primarily in response to location constraints.
iv. The fourth NATO viewpoint HV-D Organisation asks the central question, What are the required changes
to formal organisational structures and processes? We conduct analysis of HV-D to understand current
post definitions, rank and structure along with unit and team membership.
v. The fifth NATO viewpoint HV-E Human Function and Tasks defines roles between Human and Systems
and asks the question, Which human activities are to be supported by technology functions, and how should
humans and technology complement each other? We conduct analysis of HV-E in order to balance
automation decisions and as the basis for either human design requirements or equipment requirements.
If a human task is not understood the role cannot be defined. Human behaviour metrics are grounded in
human tasks.
vi. The sixth NATO viewpoint HV-F Roles and Competencies asks the central question, Which human role,
skills and characteristics need to be supported, based on the task demands? We conduct analysis of HV-F
to define roles and formally organise post definitions.
vii. The seventh and final NATO viewpoint HV-G Dynamic Drivers of Human Behaviour asks the central
question. What are the time structures, conditions, and scenarios to be supported for different
configurations? We conduct analysis of HV-G to design human related dynamic properties and constraints,
which are closely intertwined with all other design decisions.
A literature review of the Canadian HV metamodel was conducted to find common descriptions for products
that could be used during the Mapping phase of this paper. Some of the publications about Human View
products are not readily available to the public; the most current information is still under development and was
sourced from the Canadian Department of Defence as draft documents.
In 2008 the first Canadian human view metamodel was built for DNDAF under a defence contract and
contained four elements HV-1 to HV-4 (Stewart et al., 2008):
HV-1. The manpower projections – Illustrates the predicted manpower requirements for supporting
projects and programs.
HV-2. The Career Progression Roadmap – Illustrates the potential career progression in the field.

Pasi A Linnosto
Page 13
HV-3. The Individual Training Roadmap – Architectural product illustrates the instruction or education
needed to provide individual employees their job requirements.
HV-4. The Established Inventory – defines the current number of military personnel by rank and job
within each CF establishment.
The 4 products are interdependent; however HV-4 is used to forecast HV-1. Similarly HV-2 and HV-3 products
are interdependent because career path may anticipate job requirements.
The Canadian HV metamodel presented a compact approach to HV while still implementing many of the
previous HV viewpoints found in the NATO Metamodel.
The Canadian approach to Human View was to limit the number of HV products in the architecture and
specifically target decision perspectives on manpower, career progression and training. The intent of these
changes was to help define and describe the role of the human within the system (Stewart et al., 2008).
The System perspective: How do humans impact the system’s automated component?
• Mission performance, safety, supportability and cost
The Human perspective: How does the automated component of the system impact the human component?
• Trade structure, skill gap and training requirements, manning level, career progression, selection and
retention, workload and morale.
The first Defence R&D Canada publication described each of the four Canadian elements as (Stewart et al.,
2008):
i. The first viewpoint HV-1 describes manpower projections; this illustrates the predicted manpower
requirements for supporting projects and programs.
Manpower projections are represented using a Gant chart to show all project groups planned along with
system groups, planned projects.
This information can be used to determine the amount of manpower required by the organization over the
years.

Pasi A Linnosto
Page 14
ii. The second viewpoint is HV-2 the Career Progression Roadmap – Illustrates the potential career
progression in the field.
The first step in producing a career map for the program is to define product data elements for each ‘job’
for decision makers to determine an appropriate strategic career path for personnel in the organization.
The Canadian Military used Military Occupational Structure Analysis, Redesign & Tailoring Project
(MOSART) to create a structure a roadmap. The same approach may not work as easily in civilian life
because people have the freedom to change employers.
iii. The third viewpoint is HV-3 the Individual Training Roadmap – this Architectural product illustrates the
instruction or education needed to provide individual employees their job requirements.
1. Identifying what an individual learns to meet requirements of the task and duty
2. Define performance objectives
3. Determine a learning suitable programed, and environment
4. Identify those who need the qualified learning
When considering learning we also need to determine what contributions learning will make to the project,
and weigh that against cost of the project.
Across the life of the project how will the learning program change, what can be training, what can be
reused and can we leverage off other programs with similar training.
iv. The fourth viewpoint is HV-4 the Established Inventory – defines the current number of military personnel
by rank and job within each CF establishment.
1. The HV-4 product is used to
2. Support forecasting for training
3. Personnel availability. To identify the right person at right time with the right qualifications
Identify gaps in personnel availability, which can be addressed through training, transfers and recruitment
drives.

Pasi A Linnosto
Page 15
For the organisation the total number is often constrained by the Total Paid Strength (TPS) number, which
translates into the amount of budget the organisation, has for the project. It is not cost effective to have an
oversupply of human resource on a single project, or to have an oversupply of personnel waiting to be assigned
an activity. HVs will need to support decision-making on this trade-off allowing the explicit consideration of
supportability of programs across the organisation.
The four viewpoints in the Canadian metamodel are now being superseded by an updated version with ten
elements. Note that NATO and Canadian Human Views discussed in this chapter were eventually not
considered adequate and complete to map into the generalised architectural framework. Although Bruseberg
found that the NATO HV model presented was compatible with MoDAF, I was unable to map the model to
GERAM because they did not possess critical elements described in the first NATO HV Metamodel such as the
Concept element. For this study I used the first NATO Human View model in Section 4.1 and the Canadian
Human View in section 4.2 to map to the Enterprise lifecycle of GERAM described in section 4.3. The method
used to do the mapping is described next in the Methodology section of this paper.
The final part of the literature review was conducted on Handleys’ publication which mapped HV to select
DoDAF viewpoints (H. A. Handley, 2012). In this study Handley was using a ‘data based approach’ with a
focus on data needed to design the system. Architectural products from previous versions were referred to as
models and range from spread sheets, documents, and graphs that make the information easier to understand for
the recipient (because it was in a format common to what was previously used). The Human View would
provide an additional viewpoint in the DoDAF 2.0 model, suggesting that DoDAF 2.0 did not adequately
represent the HV in its current form.
Handley explains that ‘the DoDAF Meta Model (DM2) provides a high-level view of the data normally
collected, organized and maintained in an Architectural Description’.
The DM2 has three (3) levels of abstraction:
1. The Conceptual Data Model (CDM) – high level data
2. The Logical Data Model (LDM) – which adds technical information for clarity
3. The Physical Exchange Specification (PES) – Data types and implementation attributes

Pasi A Linnosto
Page 16
Handley work focuses on CDM to incorporate HV into DoDAF Version 2.0 which is understandable, because it
is normally only for the automated part of the system of interest that an exact specification is necessary of the
form of representation (LDM and PES); for human-interpreted information the conceptual definition has
primacy, the form of representation is often, but not always, less important (e.g. take for example multinational
forces).

Pasi A Linnosto
Page 17
3. METHODOLOGY
As described during the introduction of this study the technique used in this paper is a conceptual analytical
research method (Järvinen, 2004). Normative examples will be used throughout the paper to describe the ‘as is’
HV element mapped to the ‘ought to’ GERAM lifecycle activity and its deliverables. This means that during the
mapping exercise in section 4, the study will examine each HV element against an established Architectural
Framework (the ‘GERAM lifecycle’) to determine if the HV element description is complete or if the HV
element requires additional information to comply with the GERAM / ISO 15704 requirements.
In my research, an initial attempt was made to gather real data, by analysing an upcoming project with the
Australian Defence Department AIR5431 (Defence, 2013) The AIR5431 project is a three phase project to
replacement for the existing Australian Defence Air Traffic System (ADATS), however due to constraints
outside of my control I was unable to attain some of the data.
After reviewing several HV metamodels in section 2, it is now possible to begin the exercise of describing the
main components of the HV study to be mapped to the GERAM Lifecycle.
Before this is done, it has to be clarified what is the relationship of the EA framework (such as GERAM) and
the metamodel(s) investigated.
An EA framework specifies the scope of modelling: e.g. GERAM/ISO 15704 mandates that all aspects of
enterprise need to be representable, whether implemented by automated means of by humans, including
anything done to perform the enterprise’s mandate (the ‘service’), or its management, and whether it is done by
‘hardware’ (i.e., the human with available skills and knowledge) or ‘software’ (i.e., the instructions, policies,
etc.) that control the performance of the human action.
This scope definition does not, however, mandate any particular HV metamodel – it only mandates that for any
particular context one must have a metamodel covering the concerns of stakeholders, and allowing an
integration of facts across architecture viewpoints.
The next section of the study (4) will review the NATO and Canadian Human View metamodels and relate it to
the scope definition of the GERAM lifecycle model. At the time this study was conducted the Canadian Human
View metamodel (selected as most relevant) was still under development. As a result the HV elements were
changed from the original 2008 model (Stewart et al., 2008) for the 2013 model (Coats C, 2013). It is important

Pasi A Linnosto
Page 18
to note that the 2013 model was in draft during the development of this paper and that it could change in the
future. Descriptions from 2008 were applied (where applicable) to the 2013 model where clarification was
required, for instance the individual training roadmap described in HV-3 in the 2008 paper shares similarities
with the 2013 HV-6 training needs and could therefore be utilised to gain a better understanding of training
needs. Again sections from each paper were used to elaborate on the Human View element being described in
the mapping of the HV to GERAM.
The next section (5) will map the human view elements to the GERAM framework and describes how the
militarised NATO military HV and the Canadian HV models related to the GERAM Lifecycle model. During
the mapping exercise attention will be drawn on any gaps in the current study of the human view in military
AFs.
The inclusion of Human View elements into any enterprise lifecycle cannot be viewed as a one size fits all
exercise. GERAM gives us a method to consider many different viewpoints to building or improving a system
throughout its enterprise lifecycle.
Human View elements are considered somewhat independent to one another, that is to say there is no particular
HV element considered to be a starting point or a formal sequence of events the architectural practitioner needs
to follow. However some HV elements do rely on information established in other views as a prerequisite to
completion. Relevant information may already exist in other parts of the organisation and can be used to support
creation of architecture descriptions and, where this is the case we needn’t reproduce the work if it is deemed
adequate by the EA model.
Refer to Figure 1 to see the logical organisation of HV elements between four levels of a lifecycle. Each slither
(level) represents a phase of the lifecycle. ‘Decision level’ incorporates Identification and Concept lifecycle
activities of the GERAM lifecycle.
Essentially, the HV architecture descriptions (products) are produced by life cycle activities, and as such
mapped as deliverables onto the GERAM life cycle.
The main components (HV products) considered in the decision level are HV-1 and HV-2 that is shown grouped
together in a circle.

Pasi A Linnosto
Page 19
The second slither concentrates on the Requirements lifecycle activity in GERAM; again the main products are
HV-3, HV-4, HV-8 and HV-9.
The next slither groups GERAM Preliminary Design (or architectural design) and Detailed Design having HV-
5, HV-6, HV-7 and HV-10 as the main components.
The Manufacture and Operate slither incorporates Build and Operate life cycle activities in the GERAM
lifecycle and captures the NATO HV elements HV-G, HV-H and HV-B2.
The final slither is named Decommission or Replacement has no new HV elements identified, however all HV
elements can be considered depending on the scale of activity and the specifics described in a replacement plan.
The decommission slither is a potential extension target for an integrated defence AF’s metamodel.
Human view elements are present on several levels of the lifecycle model. During the decision level shown in
Figure 1 HV-1 Concept and HV-2 Establishment are the main elements, but we need to also be cognisant of
certain elements within HV-4, HV-9 and HV-10.
Some aspects of HV-4 Manpower Projection have an impact on projects size. Corporate support entities, like
Payroll and Human Resources, provide a service on behalf of an organisation to maintain a healthy work
environment. The difference between supporting a small project with ten people and supporting a large program
with fifty people needs to be identified at the decision level to gauge the level of rigour needed during the
lifecycle. For instance a corporation can apply a monetary test to projects to gauge the level of involvement
necessary. A project below $100k may commence with departmental approval, and projects over $100k require
CEO approval, and projects beyond $1M would need board approval before company commitment can be
made.
Some aspects of HV-9 Human Task need to be considered at the decision level to see if the project is viable,
given strategic direction. Consideration needs to be given at senior levels to determine if the project lies within
the scope of the expertise. An extreme example would be a machine manufacturing company would not
consider diversifying into banking because the staff knowledge and skill requirements are vastly different.
The transmitting of information between people on the project is initially considered in the decision level and
later at the design level. Efficient communication HV-10 ensures people working on the project have the ability
to exchange instructions and ideas easily. For example a company with many offices in different states may

Pasi A Linnosto
Page 20
have skilled management in one city, separate to its primary workforce in another city. This limits their ability
to communicate via emails and telephone but is necessary to understand the cost implications. By merging the
two disciplines into one facility may improve communication but at what cost. High-level HV-10
communication metamodels need to be set up during the Decision level phase of a project.
Later in the Design phase HV-9 Human Task will be refined to accommodate the specific needs of the project.
Personnel will need to adopt new roles and carry out new tasks possibly with a different toolset. For instance an
IT Internet business acquires a project to implement change from Lotus notes to Windows based email. The
Information Technician will need to acquire new skills to work in a Windows based environment.
On the requirements level of the HV-5 Personnel Characteristics along with HV-6 Training, need to be captured
as requirements are verified against the design later during the test phase.
Requirements for physical, sensory and psychological characteristics in HV-5 are captured to identify specific
human skills needed to operate equipment. For example personnel working as ‘Flight Data Controllers’ needs to
exhibit a psychomotor skill to type a twenty-five-letter code into a desktop computer every time a flight strip is
presented by the machine interface. The accuracy needed to reproducing a flight strip is critical; therefore each
reproduction of the flight strip needs a cursory check by a controller before he/she can act upon the command.
In order to minimise the need to correct problems a Flight Data controller needs to produce X amount of flight
strips in Y amount of time with 98% accuracy.
The development of a new system may require some training, not only for the contractor but also for the
customer. Any specific requirements for training needs identified in HV-6 can be captured here.
Requirements set out for HV-9 Human Task will be refined in the design level. As the system is being designed,
refinements to the human interface may be made. For instance during design the developers discover that an
automated system will halve the workload for the human operator checking licence information on a system.
The improvement to the system changes a job description from tracking licences on a system from a four hour
task every month to a one hour task every three months.
On the Design level HV-7 System Safety is considered and then applied and maintained in testing and
manufacture. System developers are cognisant of designing safe systems however this is not always as
straightforward as it sounds, the designs of a system can be inherently unsafe. Take for instance a pair of
scissors; the design of the scissor is inherently unsafe only the correct use of the design will ensure safety. The

Pasi A Linnosto
Page 21
same would apply to manufacturers in defence armament, which are designed to be unsafe to the enemy;
therefore HV-7 System Safety needs to be considered on Design/Test and monitored during the
Manufacture/Operate level.
The final level described in this paper deals with the decommissioning or replacement of the system. Lessons
learned throughout the system lifecycle should be captured and studied before embarking on a replacement
program. The decision to replace a system may be considered in the operational stage of a system lifecycle, the
customer monitoring the effectiveness of the system can make a determination when the existing system needs
to be decommissioned and if necessary replaced (partially or entirely). The same needs to be considered with the
human view; to what level will humans play a role in the next generation system? From conclusions drawn at
this point in the lifecycle, new Identification and Concepts will be formulated, repeating the system lifecycle
activities once again.
Legal descriptions such as Federal, State and Local Government policy along with Military Policy and Doctrine
along with some Occupational Structures and Job Descriptions are not discussed in this paper. System Safety is
not described in great detail because it can be specific to the individual countries’ legislation. Safety will be
discussed generically but ultimately it should be tailored to each location because this study deals with
Enterprise models that can be adopted in any country.
The Human View products have been adopted for program and project oriented work. Corporate entities such as
Human Resources, Finance, Legal services and Leadership positions at the corporate level are referenced for
their existing best practice applications, but not included as activities to be included in this study, and it is
possible that the metamodel and associated architecture descriptions / models would have to be extended to be
able to describe the human aspect of such enterprise activities.

Pasi A Linnosto
Page 22
Figure 1: Mapping Method

Pasi A Linnosto
Page 23
4. REVIEW OF THE HUMAN VIEW & GERAM
Two Human View metamodels the 2008 NATO Human View Metamodel devised by NATO RTO HRM-155
Human View Workshop 2008 (H. Handley & Smillie, 2010) and the most recent Canadian Human View (Coats
C, 2013) are to be examined and mapped against GERAM in this study. Specifically, these two HV metamodel
elements and associated work products, will be examined and mapped to the GERAM Lifecycle model (Bernus,
Nemes, & Schmidt, 2003). This chapter will examine the NATO elements and Canadian HV products along
with GERAM Lifecycle activities prior to mapping them in chapter 5.
4.1. The NATO Human View
The NATO Human View Metamodel considered in this paper will be based on the NATO Metamodel described
by the NATO HFM 155 Panel in (H. Handley & Smillie, 2008) paper. Figure 2 shows a graphical representation
of the NATO Human View and describes how each product interacts with others. The interaction between the
two HV metamodels (NATO HV metamodel and the Canadian HV metamodel) are not discussed in great detail
in this paper, instead products from NATO HV are used to reinforce the understanding of the Canadian HV
elements.
The HV-A Concept product of the Human View is considered as the starting point in Figure 2. It represents a
high level component of the architecture description, to visualise and facilitate the understanding of the human
aspect of the system under consideration. The aim is to understand how the human element will impact the
system performance, and to incorporate the human element into system design for operational context (pages
161-163 (H. Handley & Smillie, 2008)).

Pasi A Linnosto
Page 24
Figure 2: NATO Human View Metamodel
Elements of HV-A include:
• A graphical or pictorial presentation of the human element in the system
• A high level Interface Control Document (ICD) for human machine interaction
• A textural description of the overall human component of the system.
HV-B is the Constraints product that lists the operational human limitations within the system. The reason why
we need to consider constraints is because of the expectations of a design that may exceed the human operator
limitations. This product derives a set of constraint that needs to be documented and understood prior to the
system being developed (page 161).

Pasi A Linnosto
Page 25
The sub products of HV-B include:
HV-B1. Manpower projection; Determine the amount of manpower needed to support and operate the
system being considered.
HV-B2. Career projection: This is unique to the human element because machines do not have aspirations
to better themselves. This sub element describes the number of possible career changes an employee or
enlisted man may follow during the systems life history.
HV-B3. Establishment inventory: Define the as is system by listing all personnel on the current or legacy
system.
HV-B4. Health hazards: Emphasise any significant threats and risks that may result in personnel illness,
injury or death.
HV-B5. Human Characteristics: Illustrate physical characteristics of a human existing in the work
environment.
HV-B6. Personnel Policy: A collection of other significant personnel policies captured in Governance
metrics and the Human Resource department.
HV-C Task, or sometimes referred to as the Function, this product describes the activity or function assigned to
personnel working during the systems life (page 161).
Elements of HV-C include:
• Determine what are the human-related functions in the system
• Justify why functions are to be allocated to a human element or a machine
• Organise the functions in architectural language so we can map human functions and human roles
(HV-D Roles)
• Describe human function (tasks) in terms of Knowledge Skill and Ability (KSA) requirements
• Produce a matrix to illustrate tasks that can be mapped to roles
• Create interface design guidelines on the basis of task requirements.

Pasi A Linnosto
Page 26
In the HV-D Roles product we assign a role to the human interaction within the system, the role represents a job
function that defines authority, responsibility and competencies required to fulfil the position by defining an
individuals position within organisation structure (page 162).
The HV-D element may define attributes such as
• Responsibilities – a form of accountability and commitment. The role will be defined by their
responsibilities
• Authority – access to authority based on the degree of responsibility
• Competencies – Knowledge, skills and attributes that are tangible and measurable
• Multiplicity – Single or multiple human entities. Here the role described may be for a group or team of
individuals
The human network product HV-E refers to communication networks set up between humans in the system. The
presence of a human network can be either set up deliberately by design defined by roles and responsibilities or
the ad-hoc formation of teams between individuals as part of their working relationship (page 162).
HV-E elements include
• Role grouping or team formed - Teams may form by design for example grouping a set of individuals
together or virtual by group of people performing the same function separately.
• Type of interaction –Including, but not limited to collaborate with others, coordinate and supervise
groups or individuals
• Team cohesiveness indicators – trust, share
• Team performance impacts – Group synchronisation along with individuals’ level of engagement.
• Team dependencies – how often members of a team need to interact
• Communication/Technology impact to the team network. Distributed cognition, shared awareness,
common operational picture.

Pasi A Linnosto
Page 27
HV-F product details training requirements; strategy and implementation plan for humans in the system (page
162).
HV-F elements include
• Evaluate as-is training resources for suitability
• Risk of to-be operational and system demands
• Cost and maturity of training for a trade-off analysis
• Address impacts of alternative system and capability designs against the training impacts
• Requirement building to achieve necessary knowledge, skills and ability to support career progression
• Differentiation of basic, intermediate or advanced job training:
o Operational vs. System specific
o Individual vs. Team Training
The metrics product HV-G provides a repository for human related data in the Metamodel. HV-G is a
standalone product that can be incorporated into the Architectural Metamodel from lessons learned on the
legacy project other similar projects (page 162).
Elements of HV-G include
• Human factor value definition levels
• Human performance metrics describing where metrics should be measured
• Acceptable target values
• Human Function to metrics mapping
• Value definition link
• Value to design element mapping
• Methods of compliance

Pasi A Linnosto
Page 28
The 8th
Human Dynamic products HV-H provides a strategic perspective of how humans will operate in the
system, when they are presented with an external stimulus that could manifest itself as a change in technology
or management methods. HV-H describes the dynamic behaviour of human in a system and their affect on other
views. According to Handley and Smillie these dynamic aspects may change over time in state, aspects,
conditions, configuration, performance or as a result of varying conditions and triggering events. The results of
HV-H model determine if the system design meets the strategic performance expectations of the human
resource and “it (HV-H) pulls together definitions from across the human view to be able to communicate
enterprise behaviour” (page 163).
HV-H elements include
• States and state changes
• Conditions – triggering events or situation scenarios. Operational constraints that can be physical like
heat or extreme cold. Time constraints are also taken into consideration at this stage.
• Time units – Timeline, gate process etc.
• Performance measures – workload, decision speed team interaction style, trust and quality of shared
communication.
4.2. The Canadian Human View
The latest Canadian Metamodel has been applied to a practical case study (Coats C, 2013) and at the time of this
paper was still in draft form. It was used because the previous version had only four elements to the metamodel
and as discussed during the Literature Review 2 was not mappable to GERAM, however some aspects such as
the Manpower Projection described does contain information useful to this study.
The HV supplies a taxonomy and defines data elements to be maintained relating to facts about humans, and
their inter-relationships. The Canadian HV does not use propose to use one prescribed modelling language to
create an architectural product. So long as the architectural product (facts) contains the required instance of data
elements and relationships specified in the metamodel, it satisfies the need.
There are ten (10) elements in the Canadian Forces Human View metamodel, each of these views are
summarised in Table 1 and then described in full after the table.

Pasi A Linnosto
Page 29
Table 1: HV Outline of the Canadian
Human View Description
HV-1 Concept A high level pictorial depiction of the human component in the enterprise interest.
HV-2 Establishment A complete list of personnel requirements for the enterprise, including for example
operators, maintainers, trainers, and any other type of primary and supportive staff
required for the proper functioning of the enterprise.
HV-3 Organisation A chart diagram that depicts the organization of all individuals in the enterprise.
An optional tubular depiction of the role, duties and responsibilities, authorities for
key individual in the organization.
HV-4 Manpower
Projection
A graphical or tabular view that describes manpower forecast over the life cycle of
an enterprise.
HV-5 Personal
Characteristics
A tabular depiction of the personal characteristics of all (or key) individuals in the
enterprise, including physical, sensory, psychological, sociological attributes, as
well as knowledge, skills and abilities that are required by the roles to which these
individuals are assigned.
HV-6 Training Needs A tabular summary of individual training and education (IT&E) requirements for
all (or key) individuals in the enterprise.
HV-7 System Safety A tabular summary of safety related management and engineering tasks that are
required to identify prominent and foreseeable risk that may lead to potential acci-
dents or mishaps and threaten the function of the enterprise.
HV-8 Health Hazards A tabular summary of prominent and foreseeable factors that may cause reduced
job performance, illness, injury, and disability for key personnel in the enterprise.
HV-9 Human Tasks A graphical and/or tabular description of the operator tasks that all (or key) indi-
viduals need to perform.
HV-10 Communication A graphical and/or tabular description of key communication requirements for
supporting team functions and performance in the enterprise.
Source: Human View Modelling of the V-CAOC
The author prefers to display a concept of HV-1 as a picture. The HV-2 element is represented as a picture to
allow practicing architects the flexibility to present either a solution or describe the concept of operation and
highlight the main aspects.
As common in most Architectural frameworks the top-level concept models is typically shown as a pictorial
diagram. In some instances the top-level concept model can comprise of a 3D model showing a mock-up of the
final enterprise. The audience for a top-level architectural model is often senior managers or high-ranking
members of the armed forces.
The purpose for a HV-1 model is to provide an overview for the architectural concept being proposed,
highlighting the key human dimension as integrated into the system. Each sub view should identify technology;
infrastructure and business purpose showing how human elements will operate within the system environment.
Consideration needs to be given to both primary and supportive personnel. The types of personnel to be
represented in a specific HV-2 model depend on the purpose of the architecture model. Several basic attributes
such as occupation and rank or classification need to be identified as part of HV-2.

Pasi A Linnosto
Page 30
The purpose for producing an HV-2 model is to describe the basic elements of a socio-technical system, or in
other words, to describe who the individuals within the enterprise are. There are four (4) architectural elements
that need to be identified in HV-4
1. Establishment: a hierarchical structure that list all the people in the enterprise.
2. Position: a portion of the work scope that has been narrowed down for one person to perform as a set
of tasks.
3. Occupation: A grouping of similar duties and tasks having the same competencies.
4. Qualification Level and Rank: Describes the minimum knowledge or skillset that is required by an
individual to fulfil the role that performs a task. Qualification Level refers to the level of formal
training required to hold the position.
There are three (3) suggested steps required to create a HV-2 model:
1. Determine who should be represented in the HV-2 model
2. Generate a list of positions required to support the enterprise
3. Assign a set of attributes required for each position
This view displayed as a chart diagram describes the organisational form, reporting structure or chain of
command. It is recommended that the model including in tabular form duties, responsibilities, and authority for
key individuals in the organisation.
A project lifecycle forecast for the number of positions required to fill all the roles in the enterprise. We should
also take into consideration any HV-4 demand fluctuations during the enterprise lifecycle that will affect
personnel and staffing levels.
The purpose of the HV-4 is to provide a forecast for personnel requirements based on anticipated operational
demands along a timeline horizon. Stakeholders should become involved in the HR planning activity. In this
sub-view forecasts are made at an individual level.

Pasi A Linnosto
Page 31
HV-5 characterised every individual during the enterprise for planning, training and education purposes. HV-5
does this to characterise physical, sensory, physiological and sociological attributes along with Knowledge,
Skill and Abilities (KSA) required to fill each role within the enterprise.
The author acknowledges that existing means of training military personnel is at a high enough level not to
warrant any change. Training in a mature governed organisation will have process and procedures Enterprise
Architects can leverage to create a HV-6 model.
The following three steps are used to create a HV-6 model
1. Identify the position using information in HV-2
2. Collect requirement data on the position from HV-9. See for a list of data elements.
3. Describe the necessary qualifications, skills and experience required for each position.
Table 2: List of HV-6 Data Elements
Data Element Description
Position The name of the position in the enterprise being analysed. The information is availa-
ble from the corresponding HV-2 model.
Rank / Level The required rank level of the position. The information is available from the corre-
sponding HV-2 model.
Occupation (eg MO-
SID)
The Military Occupational Structure Identification Code. The information is available
from the corresponding HV-2 model.
Task/ Sub-Task A list of the tasks a position incumbent is expected to conduct. The mapping between
positions and tasks are available from the HV-9 model.
Qualification Any unique qualifications that are required to perform the tasks expected of the posi-
tion. The analyst can write these in either plain text or they can be captured as either
the military occupational qualifications (e.g., ADFR for a MARS Officer, MOSID
00207) or occupational specialty specifications (e.g., AEEG – Surface Ship Com-
mand).
Skill Any unique skills that will be required to perform the roles/tasks expected of the posi-
tion beyond those expected for a person of the Rank/QL and MOSID.
Experience Any unique experience that will be required to perform the roles/tasks expected of the
position beyond those expected for a person of the Rank/QL and MOSID.
Source: Canadian HV Handbook
HV-7 summarises safety related management and engineering tasks required under the countries general and
legal safety codes. HV-7 is created with a focus to support reporting and tracking functions for System Safety
related issues.

Pasi A Linnosto
Page 32
This sub-view provides a summary of factors that may cause reduced job performance, illness, injury and
disability to personnel working in the enterprise. The health hazard elements are identified and classified as a
risk assessment task (Coats C, 2013).
The HV-9 Human task viewpoint element provides a decomposition of operational activities into tasks. A
description of technologies used to assist the task and the operators title. Mission, Function, Task Analysis
(MFTA) (Baker & Youngson, 2007) information is needed to develop HV-9 models.
For HV-9 teamwork reflects a subset of operational tasks where multiple operators are required to work
interdependently to achieving a common set of operational objectives.
4.3. GERAM Life Cycle
The GERAM framework includes the human aspect in every life cycle phase. As described earlier, this study
aims to determine how it is possible to incorporate defence Human View products into the GERAM lifecycle
framework and more precisely the GERA modelling framework. To do this we need to understand how
GERAM represents the role of the Human in an enterprise entity’s lifecycle.
The GERAM framework is broad in nature so it can describe a wide range of enterprises. Not all views in the
GERAM Lifecycle and associated Modelling Framework need to be used to describe a system instead, the
practicing EA will be able to expand views to describe in detail what is needed and summarise other views
where detail is not required.
The life cycle of an Enterprise is represented in GERAM by a simple diagram shown in Figure 3, which
describes the enterprise life cycle activities of a system. That is from the initial Identification view to the final
decommissioning view for any enterprise (Bernus et al., 2003).
In GERAM all aspects of the Enterprise both Human and Machine are represented, including everything related
to management (command and Control), and operation and whether these are implemented as ‘software’ or
‘hardware’ (notion of software/hardware is extended to both machine and human software/hardware).

Pasi A Linnosto
Page 33
Figure 3: GERAM Life Cycle
Each view needs to be considered in the correct context. When discussing a Software view for Operation in the
Human context we refer to perhaps a procedure that needs to be followed by an operator of a machine reading a
procedure. In contract when discussing the same view for Machine the reference could be to written computer
code.
The first lifecycle activity is the Identification of an activity within enterprise. This phase of the enterprise goes
to determine if for instance a project is suitable for the company to undertake, or if a new technology identified
in the field would warrant further pursuit. The Identification life cycle activity included a set of activities that
describe the boundaries of the enterprise entity (system of interest) and its relationship to of the internal and
external environment. For instance an Aeronautical company may determine that a project to build a new airport
is not in their scope or field of excellence, however the aircraft maintenance and logistical control part of the
project is. When identifying new technologies it is important to define what capabilities your company and

Pasi A Linnosto
Page 34
system have, technology based companies perusing leading edge of technology for an advantage should not over
step their capabilities and end up at the bleeding edge of technology.
The concept phase of the life cycle consists of a set of activities designed to determine (as the name suggests)
the concept of the underlying enterprise. During this phase the identified concept is examined by determining
the vision, values, strategies, objectives, operational concepts, politics, policies and principles, value analysis,
business model and often more.
The requirements phase describes the operational requirements for the activity. This includes both service
and/or manufacturing requirements (both functional information, organisational, and non-functional, such as
legal, ethical or human resources requirements, along with mechanical, control and data management /
command and control requirements.
The Architectural design phase for the enterprise is the phase where planning and preliminary designing
activates is carried out.
The detail design phase is an extension of Design where more design activates are carried out. In most cases the
process will be broken out into several phases, which could include prototyping or partial build cycles along
with test phases, and other activates. The detail design phase takes most of the effort in terms of engineering
manpower, needed in a project to generate a successful outcome.
The Build or Implementation phase generates product of some kind in the life cycle. The activity implements all
the above work to produce a product that meets the original concept. In other words, the activity brings the
concept to life. This may be either by producing hardware from the detail design or producing a working
process/procedure on paper as the final product that will be presented to the customer.
The operation phase sets the design to work in the environment it was intended. This is usually thought of as the
product or machine that operates to produces product.
At the end of the typical lifecycle the enterprise will be decommissioned. In some cases the decommissioning
phase removes the entire project, but more often only some modules are disposed and others are retained,
reused, re-cycled, transferred or re-mission.

Pasi A Linnosto
Page 35
Figure 4: GERAM Lifecycle Activity
When we examine Figure 4we see there are several dimensions or views to the modelling framework of
GERAM and its life cycle model.
Note that the original GERAM document calls these views, which correspond to viewpoints in ISO42010 and
the version 2.0 of the GERAM metamodel. Essentially these ‘views’ specify on a high level, what aspect of the
enterprise entity to model, i.e., the scope of modelling. These view specifications do not determine in detail
exactly what facts about this aspect are necessary to model. This is because which facts are relevant depend on
the context and application. A given application domain, such as defence systems design and commissioning,
will have relevant stakeholder questions, which in turn determine what is the minimum ontology to be shared
among stakeholders. In turn the ontology can be expressed (as a minimum) as a standard metamodel, allowing
the repository of model artefacts to be stored in a repository. What is note worthy is that the metamodel is
therefore essentially the database (conceptual) schema of this repository.
Returning to the GERAM ‘view’ each of the views is there to determine the scope of modelling – i.e. what
needed to be (or may need to be) modelled. Accordingly there are two distinct Purpose Views:
• Customer Service and Production: This sub-view describes if the tasks and everything associated with
those tasks that contribute to the systems mission.
• Management and Control: (Command and Control): This sub-view describes the tasks and everything
associated with those tasks that manage & control the carrying out of the mission.

Pasi A Linnosto
Page 36
Figure 4 also illustrates that model / description of our system of interest must cover as content the following
types of system characterisation (called Model Content Views):
• Organisation: What in the organisation is required to carry out this operation (organisation here means
how the resources of the system of interest map to the function of the system of interest – essentially
the relationship between resources and function (and related information))
• Resource: What Human and/or Machine elements are needed to carry out the task. (Whether it is a
service or management task)
• Information: What information is being used and produced by the system of interest: and what special
instruction is needed by the machine (software code) or human (e.g. policy or procedure)
• Function: What are the transformations of information and material that are involved (e.g. tasks,
processes, procedures, etc…)? This includes forms of operation performed by human and/or machine
conduct to complete the goal of the task
An additional two Manifestation Views in Figure 4 exist laterally which are:
• Hardware: This described any aspect of the physical resource needed to perform the operation that
carries out the enterprise task. This can also be the person who carries out an operation.
• Software: The information resource controlling the execution of the operation. This includes sets of
instruction needed by a human element to carry out the operation.
Within each of the views GERAM in Figure 4 will describe two constituents of any system:
• Machine element: the automated constituents of the system of interest
• Human element: the human constituents of the system of interest (such as an individual, or aggregation
thereof, such as a committee, a team, etc.)
Of particular interest to this dissertation is the description of the Human element of GERAM, with the note that
the above scope definitions define on a high level, what aspects of the Human element are to be considered
(without providing a normative metamodel, which as explained above, is the matter for an application domain,
or context).

Pasi A Linnosto
Page 37
5. HUMAN VIEW MAPPED TO GERAM
A way to map the reviewed defence Human View products and elements to the GERAM modelling framework
is to shown how these products describe a particular view, or combination of views, in GERAM.
The practical use of this mapping is to demonstrate how the latest developments in Human View concepts in
defence satisfy the ISO15704 requirements for architecture frameworks, but equally importantly, the mapping
may be able to highlight avenues for further development – be it the identification of gaps, requiring an
extension to the present HV metamodel, or indeed its simplification.
The 2013 Canadian views in section 4.2 were used in this paper because it was the most recent and up to date
HV study.
The NATO HV Metamodel discussed in section 4.1 was also used to expand the understanding of the HV
element being discussed through the GERAM modelling framework, wherever it was needed for clarity.
NATO HV metamodel elements were also used to when corresponding Canadian HV elements where absent,
showing gaps in the study later.
Where no Human View products or elements were available, GERAM Views were used to highlight the need to
address a gap in HV study and offer a plausible method to address the shortfall.
The GERAM Lifecycle model comprises of eight lifecycle activity types (colloquially called ‘life cycle
phases’), which essentially consider the system of interest on different levels of abstraction.
The Human View Reference chart (Table 3) is a summary of the mapped results for section 5 that shows each
GERAM life cycle activity and associated views mapped to the Canadian and NATO HV metamodel elements
and products.
The reader should note that an Alphanumeric designator symbolise the NATO products (HV-A to HV-G) whilst
a Numeric designator refers to the Canadian elements (HV-1 to HV-10).
A GERAM lifecycle model was followed using a top down approach, starting at Identification activity and
ending with the Decommissioning activity. HV elements from the Canadian model were placed on each
GERAM life cycle level to show how human aspects are modelled across the lifecycle of a system of interest.

Pasi A Linnosto
Page 38
Table 3: Human View Reference Chart
GERAM Lifecycle
Activity
Canadian HV Elements NATO HV Products
Identification Nil Nil
Concept HV-1 Concept HV-A Concept
HV-2 Establishment HV-B3 Establish Inventory
Requirements HV-3 Organisation HV-E Human Network
HV-4 Manpower Projection HV-B1 Manpower Projection
HV-8 Health Hazards HV-B4 Health Hazards
HV-9 Human Tasks HV-C Human Task (Function)
Preliminary Design HV-5 Personnel Characteristics HV-B5 Human Characteristics
HV-D Roles
HV-7 System Safety
Detail Design HV-6 Training Needs HV-F Training
HV-10 Communication HV-E Human Network
Build HV-H Dynamics Nil
Operation Nil HV-B2 Career Projection
HV-G Metrics
Decommission Nil Nil

Pasi A Linnosto
Page 39
5.1.1. Identification
The Canadian and NATO Human View products do not capture Identification information as required in the
GERAM modelling framework’s scope definition. A review of multiple Human View metamodels and
descriptions in section 4 found that non of the Human View metamodels fully considered the Identification
activity or its equivalent in any adequately to satisfy GERAM modelling framework.
During Identification the practicing architect needs to consider the environment and boundaries of the system
being constructed, and different organisation styles may evoke different EA methodologies (approaches). For
instance a Holonic and Fractal organisation will operate differently to a Bionic organisation (Tharumarajah,
Wells, & Nemes, 1998), with different emphasis on the human component.
The nature of the business and how the business operates should be considered to determine if the enterprise
entity presented fits the company’s mode of operation, and the consideration of the human component is
necessary to make such decision. E.g. a surveillance service entity (as a system of interest) may be identified as
being completely automated in its service delivery, with humans only being involved in the management and
control of the service entity (essentially a drone-based surveillance service), or a service based on a manned
aircraft. The suitability of this choice to the intended service regime must be assessed, and one would
obviously consider whether the entity in question is to be completely unmanned or not – the consideration being
made in the context of the entity fitting into a larger system (of systems).
The basic organisational principles based on which a system of interest is envisioned define types of
organisation, and therefore the decision to incorporate in the embedding system and entity of this type is not
solely determined by local optimisation and requirements, but rather by the fact and expectation that the system
of interest should fit into a larger context of systems. Examples of such organisational style choices that may be
made on the identification level are discussed below.
Bionic organisations coordinate tasks much in the same was as cells in the body, where enzymes speed up a
reaction and hormones secretions transform the body to exhibit a reaction. Similar self-managed changes to the
operation performed on the factory floor may be summarised into policies and strategies and revised on a need
to basis, whereupon each level of the organisation is supported by its adjacent level much in the same way cells
are formed in the body, using a bottom up approach in system management (Tharumarajah et al., 1998).

Pasi A Linnosto
Page 40
Fractal organisations can be described as self-organising; self-optimising with self-similarity this again
conforming to a bottom up approach in operation. In a fractal organisation target goals are checked regularly to
ensure all entities within the organisation are closely aligned to meet the set goal (Tharumarajah et al., 1998), an
importantly, the system of interest is expected to fit into the organisational style or the embedding system, and
comply with design principles that would otherwise (from the functional point of view) be seen as arbitrary
constraints.
Holonic organisations can be described as being autonomous where a set of fixed rules or combinations are
applied so as to ensure that higher level autonomous entities are created for autonomous entities (etc.
recursively).
Arthur Koestler coined the term ‘holon’ to describe the fundamental features of complex systems and the
relationship between autonomous wholes and parts. When the environment changes a Holonic organisation will
self-regulate and report back to a central position that in turn adjusts to a new environment. Holonic
organisations utilise both bottom up and top down approaches in systems management (Mathews, 1996),
(Tharumarajah et al., 1998).
Change Management techniques may need to be used when building an Identification model for the system of
interest including the consideration of the human element.
By identifying the type of organisation and the system of interest, we can apply one of several Change
Management techniques to the system. Defence forces typically have the ability to order enlisted personnel to
perform a new task or work on a new system. However the common techniques used by Human Resource
Managers to change an organisation (as described in ‘Leading Change (Kotter, 1996)’) also have a role in
defence circles, the Kotter method could also be applied in Bionic, Fractal and Holonic organisations.
In Leading Change Kotter describes eight steps to successfully applying change, steps one and two are
performed during Identification, later vision and strategy will be considered during Concept, while the
remainder will run in conjunction with the GERAM modelling framework: -
1. Establish a Sense of Urgency, by examining the marketplace and discussing potential crisis along with
any opportunities

Pasi A Linnosto
Page 41
2. Forming a Guiding Coalition, by encouraging like-minded leaders in the organisation to lead the
change
3. Create a Vision, to direct the change effort and help developing strategies
4. Communicate the vision, by using any vehicle available to broadcast the vision to employees
5. Empower others to act on the vision, by removing obstacles which may undermine the change
6. Planning for and creating short term wins, by recognising employees involvement in the improvements
7. Consolidating improvements and producing still more change, by hiring, promoting and developing
staff.
8. Institutionalising the change, by articulating connections between the new behaviour and corporate
success.
Kotters’ approach to Change management may not be suitable for all companies seeking change. For
organisations that take a social approaches to change and consider cultural intellect, may choose to follow the
change management story described in ‘Ubuntu’ (Lundin, 2010), which is the ancient African philosophy that
draws on the fact that we are one human family.
First. It starts with me! Ubuntu needs provocation; each member needs to be provoked in some way to follow
Ubuntu.
First. Build trust by demonstrating respect! A leader puts ‘first things first’.
Second. In Ubuntu the next point is to establish a sense of common purpose.
Third. Build relationships with key employees! By initially targeting those who are already in line with
Ubuntu Think or ‘low hanging fruit’.
Fourth. Lighten up and have fun! Play can energise the workplace for everyone
Fifth. Aims to improve quality of life at work.
When mapping HV products to the GERAM lifecycle we must first consider the type of organisation and the
type of system being built, along with the needs of the particular entity. Conceptual development will take
differing paths depending of the structure of the organisation. Analogues concepts for application definitions in

Pasi A Linnosto
Page 42
Holonic Manufacturing System (HMS) and Fractal Factory (FF) organisations are less direct to the organic
applications of Bionic Manufacturing System (BMS). An example would be the Virtual Combined Aerospace
Operations Centre (VCOAC) project (Wenbu & Curtis, 2013), could be described as BMS where grouped
individuals have multiple operational roles and each group is to a degree is self-managed. Each group works
with a fixed set of guidelines or instructions in process and procedures. In contrast self-organising and self-
regulated organisations of HMS and FF require agile models for conceptual development (Tharumarajah et al.,
1998).
The decision to go ahead with the project is made by considering at the Identification view both the customer
service and product view for the project. For instance there is currently a need to update the Australian Air
Traffic Control System (Defence, 2013), the type of system will depend on the customer’s needs, which is in
this case the Royal Australian Air Force (RAAF). Other interested parties may include but are not limited to the
Australian Government, Air Services Australia (AsA), the Civil Aviation Safety Authority (CASA), relevant
Airport Authorities and the Airline industry. The options for replacing the system can range from, building a
new system to replace the existing system, combining Civil and Military Air Traffic Management (ATM)
systems in Australia, updating legacy hardware or adding additional capability to the current system. These
factors could lead to very different outcomes in system development and impact the way in which the system of
interest is built.

Pasi A Linnosto
Page 43
5.1.2. Concept
The Concept level description is common to all three models mapped in Table 3; the GERAM lifecycle
describes the concept phase as the second level in a lifecycle model, whilst the Canadian HV models list
Concept as the highest level viewpoint that occurs in step one.
It should be noted that the life cycle activity Concept developed in GERAM include the development products
such as Vision, Values, Strategies, Operational Concepts, Policies and Business Plans governing principles to
which the design of the system of interest must adheres.
As listed but in paragraph 4.2 there exist sub-views required for HV-1 that identify technology, infrastructure
and business purpose.
The Concept description in HV-1 offers a high level pictorial description of the system of interest’s human
element but does not offer sufficient detail to cover the vision, values, strategies policies / principles and
business plans. In some instances when architecting organisations with a high maturity level of governance may
already have described / documents / models / etc in place to satisfy Concept development. In this case architect
only needs to confirm and acknowledge the corporate strategy and include them in the products of the lifecycle
framework.
After reviewing the Canadian Human view product it seems that there is a need to generate a HV-2
Establishment table earlier in the lifecycle rather than later.
Several Canadian HV products require the Establishment step of HV-2 as a prerequisite to determine the
workforce structure (Paragraph 2.2.3 (Coats C, 2013)).
There are four (4) elements that need to be identified in HV-2
1. Establishment: a hierarchical structure that list all the people in the enterprise.
2. Position: a portion of the work scope that has been narrowed down so one person can perform all tasks.
3. Occupation: A grouping of similar duties and tasks having the same competencies.
4. Qualification Level and Rank: Describes the minimum knowledge or skillset that is required by an
individual to fulfil the role that performs a task. Qualification Level refers to the level of formal
training required to hold the position.

Pasi A Linnosto
Page 44
There are three (3) suggested steps required to create a HV-2 model.
1. Determine who should be represented in the HV-2 model.
2. Generate a list of positions required to support the enterprise.
3. Assign a set of attributes required for each position.
HV-B3 Establish Inventory maps to HV-2 because it defines the as-is state of the enterprise by listing all
personnel within the organisation prior to change. As-Is architecture models are models that describe baseline
architecture for what exists today. To-Be architectural models or target architecture represents a desired future
state for the architecture. The To-Be model should represent the strategic direction for the project and consist of
a series of milestones that are needed in order to reach the next state; therefore strategic information derived
from as-is data can be used in the Concept activity to form a strategy.
The four architectural products describe an operational concept for the human element; here we can see where
to expand the HV model to conform to the GERAM lifecycle by describing the architectural Vision, Values,
Strategies, Policies and Business Plans. As stated before a mature organisation may have a vision and values
statement as part of the corporate charter that could be used to populate the Concept activity. A Strategic plan
and a Business Plan may also exist and could be incorporated into the Concept activity to align the project with
the enterprise under consideration. The architect will need to determine if suitable principles and policies are in
place before completing this activity.
Principles are higher-level instructions driven by standards that all entities in the organisation should conform
with, for instance the Engineering division of an organisation may have an existing Engineering Management
Plan (EMP) that sets out how engineering work is conducted in the organisation. From the EMP a sub set of
procedures are derived to conduct engineering activities such as rules in the EMP that state that an Engineer
shall conduct design and modification activities for Class 1 and Class 2 Engineering Change Proposals (ECP) in
accordance with an applicable standard. An Engineering Policy should identify how this will occur and who
should be involved. For principles and policy HV-2 correctly identifies who should carry out work but does not
offer sufficient detail on work policy and or business plans.
Once all the GERAM activities are described the mapping will be complete and would strategically align the
enterprise with system to corporate vision, values and goals. When considering the Concept activity in GERAM

Pasi A Linnosto
Page 45
the software component of the model will map to a human element through managing Information Technology.
There are many Governance models that businesses can use to aligning business with Information Technology,
on example is the Luftman model which aligns Information Technology to other functional organisations in
order to achieve a higher level of corporate maturity (Luftman, 2003).
Some organisations may choose to utilise existing policies that are similar to the project under development. In
this case a review of the policies should be made before a decision is made to reuse a policy. Level-5 of the
Luftman model describes an organisation at the highest level of maturity, with scope and architecture that are
optimised using evolved patterns that can be used universally adopted across many platforms. Level-2 of the
Luftman model describes a committed process that is at a lower level of maturity, with scope and architecture
classified as transaction, and only functional integration exists (page 11 (Luftman, 2003)). At a level-2 maturity
organisation processes may look similar on the surface but upon closer inspection are tailored to a single type of
system. An aircraft platform may seem similar to an Air Traffic Management and Control system, however care
must be taken when writing procedures not to tailor the procedures to a single platform. Otherwise the results in
detailed design produce later in the lifecycle will contain ‘not applicable’ or ‘other’ statements in the template
where the engineer cannot find suitable matches to describe the design.
Efficient communication HV-10 should be considered as part of the Concept activity to ensure people working
on the project has the ability to exchange ideas and any known barriers are overcome. This may include
collocating resources in the same building.
An extract tabular representation for a Mock As-Is Air Traffic Control & Management system at an Australian
Deference Air Force installation depicting an HV-2 model is given as an example in Table 4. The table
describes each position, Occupation or Military Rank of the individual, their occupation or title in the
organisation. The last column on the right lists the relevant policy governing each position.

Pasi A Linnosto
Page 46
Table 4: System HV-2 Establishment Model
ID Position Occupation
or Rank
Occupation Policy
01 RAPCON Director SQNLDR Senior Air Traffic Controller Officer Directors Manual
02 TWR Supervisor SQNLDR Air Traffic Controller Officer Controllers Handbook
03 RAPCON Supervisor SQNLDR Air Traffic Controller Officer Controllers Handbook
04 TWR Controller SQNLDR Air Traffic Controller Officer Controllers Handbook
05 RAPCON Controller SQNLDR Air Traffic Controller Officer Controllers Handbook
09 Technical Supervisor FLTSGT Air Traffic Controller Officer TAMM
10 Automation Techni-
cian
FLTSGT Technical Officer TAMM
16 Radar Technician FLTSGT Technical Officer TAMM
17 Voice Communication
Technician
FLTSGT Technical Officer TAMM
Source: Modified example using Canadian HV Handbook
5.1.3. Requirements
Many of the Human View products are touched upon in the Requirements activity. When developing a list of
requirements for a system it is common to develop the Top-level System Specification (TSS) to capture the
higher order products of the system first. The same can be said for Human View elements of the TSS, the
System Engineer delegated to the role of requirements owner (Sheard, 1996) needs to engage in writing high-
level human system specification for the project in parallel with machine view products TSS.
Figure 5 shows all GERAM Sub View can be mapped to Human View products.
• HV-3 Organisation can be mapped to GERAM lifecycle activities purpose view Customer Service and
Product, because it forms part of the product. HV-3 specifies each individual in the enterprise that can
be considered as the relevant content of the enterprise activities operation that will lead to an
operational result. HV-E Human Networks are also partially mapped to this activity because it
describes the integration between humans in the project. The remaining functions of HV-E are later
described in 5.1.5 Detail Design.
• HV-4 Manpower Projection, maps to Resource model content view, in Management and Control
because it describes strategic human resource management structure. HV-4 provides a projection of a
human resource necessary to the enterprise over time. By managing the human element, GERAM

Pasi A Linnosto
Page 47
purpose view activities is satisfied because the content relevant to the view is being managing as it
operates (Chapter 2 par 2.3.1.5.2.2 (Bernus et al., 2003)).
• HV-8 & HV-B4 Health Hazards, maps to Information model content view, in Management and Control
Technology, because it describes mechanising of management and control functions that maintain
human health. Hazards are described as a constraint factors that may reduce job performance (H.
Handley & Smillie, 2010) the information contained in HV-B4 fits the Management and Control
Technology purpose view again because the content relevant to the view is being managing as a risk as
it operates.
• HV-9 & HV-E Human Function and Task, maps to function model content view, in Management and
Control because it describes mechanising of management and control functions for human tasks.
Human Function & Tasks describe what people do relevant to the system function (Bruseberg, 2010)
which is managed and controlled to produce an outcome. By managing the human functions the
GERAM purpose view activities is satisfied, because the content relevant to the view is being
managing as it operates.
GERAM describes the Requirements activity as the development of system operational requirements for the
enterprise. This includes the systems behaviour, informational, process and capability needs for both human and
machine. In section 3 Methodology we discussed how multiple HV products were mapped to the requirements
level in Figure 1.
System requirements for HV-9 Human Task product can be described in tabular form using a simple spread
sheet. For more complex projects, a database can be developed or purchased from a software vendor. Table 5
gives a simple example for System Specification Requirements mapped to Human Task requirements. The
example shows the TSS requirements for an Air Traffic Management & Control system, showing the Human
View requirement for each Machine View requirement.
TSS requirement 12.1 in Table 5 will later be expanded to describe what happens to the system products both
Human and Machine at Decommissioning. HV-9 Human Tasks requires a disposal plan be developed to remove
and environmentally dispose of the machine hardware. This should also describe the number and type of people
needed to remove and dispose of the hardware in a safe manner.

Pasi A Linnosto
Page 48
Figure 5: Requirements to HV Mapping
TSS requirement 12.2 Table 5 in will also be expanded to describe what parts of the system should be retained
for the next generation system. HV-9 requires a transition plan be devised to transfer personnel from the
decommissioned system to the next generation system. This may remain a top-level requirement for now given
that the system is not due for decommissioning until it reaches its fifteenth year mark. Even after fifteen years
the customer may extend the decommissioning date if the system meets the current operational requirements
and can be maintained without degradation in performance.
There are two physical Manifestation views shown in Figure 5 that describe the Hardware and Software views
of the human element. The Hardware view describes a set of instructions for the human by defining skill set
necessary to carry out an activity or work on the system. The Software view describes an employee with the
skillset necessary to operate the system (Chapter 2 par 2.3.1.5.2.4 (Bernus et al., 2003)). The Human Task HV-9
and Human Network HV-E describe requirements necessary to operate or manage the system that satisfies
GERAM physical manifestation views. The views are limited to Requirements, Design and finally during the
Decommission activities in GERAM as shown in the methodical map in Figure 1.

Pasi A Linnosto
Page 49
Table 5: System Requirements and HV-9 Human Tasks
System TSS Requirements Human Factor (Human View) System
(Machine View)No Description No Description Sub Task
1 The system shall have a Tower A
The Tower shall be
manned
15 hours per day Automation
Certified Air Traffic Controllers
Formal class and hours of
operation
Controllers are to take 15 break
every 45 min
Break room close to tower
Controllers are to be briefed
before every shift
Briefing room close to
tower
1.1
There will be a Tower Opera-
tor position
A.1
Tower Controller
(TWR)
TWR controller to be certified
for the position
operation
TWR Controllers are to com-
municate with RAPCON and Air
Traffic
Radio, Call Answer Call,
Hotline
1.2
There will be a Surface
Movement position
A.2
Surface Movement
Controller (SMC)
SMC controller to be certified for
the position
operation
TWR Controllers are to com-
municate with RAPCON and
Surface movement traffic
Hotline
2 There will be a RAPCON B
The RAPCON shall
be manned
20 hours per day Automation
Certified Air Traffic Controllers
operation
Controllers are to take 15 break
every 45 min
Break room close to tower
Controllers are to be briefed
before every shift
Briefing room close to
tower
2.5
There shall be an Approach
position
B.5
Approach Controller
(APP)
APP controller to be certified for
the position
operation
APP Controllers are to com-
municate with TWR and ap-
proaching air craft
Hotline
7
Voice and Data shall be rec-
orded
Automation
7.1
The system shall be capable of
playing back Voice and Data
communication
G.1
The Technical Super-
visor console shall be
manned
Manned while Controllers are on
duty
PABX
7.2
The Voice Data recording
system shall be maintained
G.2
Voice and Data Me-
dium shall be stored
Duty Tech shall archive Voice
and Data medium once capacity
has been reached
Storage Data Base
8
The system shall conform to
Health Hazard code (Aust/NZ
XXXX.xx)
H.1
Personnel shall not be
exposed to airborne
asbestoses dust
Asbestoses shall be contained
IAW Aust/Nz code of operation
xxxx.xx
Work Environment
12.1
The system shall operate for
min 15 years
L.1 Disposal Team Operate IAW (Aust/Nz XXX.xx) Disposal Plan
12.2 L.2 Transition
Operational personnel shall be
relocated to an appropriate posi-
tion
Training Plan

Study of the Human View

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

Similar to Study of the Human View

Similar to Study of the Human View (20)

Study of the Human View