# Defining and characterizing the operational context for human systems integration

Alexandre Disdier, Dimitri Masson, Marija Jankovic, Guy-andré Boy

► To cite this version:

Alexandre Disdier, Dimitri Masson, Marija Jankovic, Guy-andré Boy. Defining and characterizing the operational context for human systems integration. Systems Engineering, 2024, 10.1002/sys.21775. hal-04681904

HAL Id: hal-04681904

https://hal.science/hal-04681904v1

Submitted on 30 Aug 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Defining and Characterizing the Operational Context for Human Systems Integration

Alexandre Disdier¹,²,³, Dimitri Masson², Marija Jankovic¹, Guy-André Boy¹,²

¹Industrial Engineering Laboratory, Paris Saclay University, CentraleSupélec, France

²ESTIA-Recherche, ESTIA Institute of Technology, France

³Research Lab, CS GROUP, France

August 30, 2024

## Abstract

Many efforts from multiple academic and industrial disciplines have studied the notion of context. The systems engineering and human systems integration fields, however, lack a generalized definition and characterization of context, in particular the operational context of complex sociotechnical systems. This paper reviews context definitions and builds a generalized definition of the operational context of complex sociotechnical systems. The objective is then to identify and extract context properties which are often implicit in the literature and do not necessarily appear in the definitions. However, eliciting them is helpful for understanding what context is made of, how it relates to complex sociotechnical systems comprising human and non-human agents, and how an early understanding of the operational context can prove valuable to designing efficient and robust systems. Our analysis is followed by an example of how our definition and derived properties apply to the case study of the design of a remote and virtual air traffic control center.

*Operational Context, Complex Sociotechnical Systems, Human Systems Integration, Remote and Virtual Towers*

## 1 Introduction

Human Systems Integration (HSI)⁵¹ is an interdisciplinary approach to Systems Engineering (SE) that does not focus solely on technology but strives to integrate with it both human and organizational aspects as early as possible during a system of interest lifecycle¹³. A proper HSI effort may improve system performance and minimize design and production costs. This is because HSI methods and tools try to tackle the fact that a complex sociotechnical system may exhibit emergent properties at operation time that were not anticipated at design time, leading to expensive redesigns of the entire system or part of it.

Emergent properties arise because there are intricate relationships between the humans and machines that constitute complex systems. The term *complexity* refers here to the complexity of systems as defined in the Systems Engineering Body of Knowledge (SEBoK)⁶²: "*complexity is a measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it*". In addition, the INCOSE Complexity Primer⁶⁴ directly relates the complexity of
systems with the need to "maximize description of emergent properties in scenarios and mission definition". It also states that "emergence will not be observed until the system is considered as a whole". In particular, the nature and the evolution of the relationships between the elements of a system are challenging to predict before the system is immersed into its operational context. Designing a complex system in an HSI way should therefore include a context elicitation phase during which contextual information of the system of interest is derived, even though this system has yet to be fully integrated or even produced. However, context is not a properly defined concept, as the literature gives multiple definitions depending on the research or industrial domain. The wide variety of use cases in which context has been studied has also led to an inconsistent view of context properties, how context influences overall system behavior, and what context is made of in the first place⁶.

The goal of this paper is twofold. The first objective is to provide a generalized definition of the operational context derived from the broad spectrum of definitions found in the literature, which is yet applicable to our HSI-related issue of designing complex sociotechnical systems. The second objective is to aggregate the different properties that characterize context from the same literature. We apply these identified properties to a case study of the design of a remote and virtual Air Traffic Control (ATC) center, which aim is to regulate air traffic of a distant airfield without the need for a control tower in situ.

The remainder of this paper is structured as follows. Section 2 describes our selection process of the literature contributions and discusses their inclusion into our analysis. Section 3 explores the literature from different research domains and builds a generalized definition of the operational context. Section 4 describes each property of context we identified and justifies its relevance for an HSI approach to the design of complex sociotechnical systems. Section 5 illustrates the application of the definition and properties to our remote and virtual center case study. Section 6 concludes the paper.

## 2 Selection of the review sources

Context is a topic covered by various domains. Simply searching academic databases for papers containing the word "context" yields too many results to be exploitable. Many are also irrelevant to our study since "context" is often used as a transitional word, like "in the context of". Therefore, we queried six databases and prompted them to output all papers of any type from all years that contained the word "context" in the publication title, abstract and keywords (Table 1). We kept only papers related to the Industrial and Multidisciplinary Engineering fields and papers whose metadata and body mention at least once the terms "systems engineering", "human systems integration", "human-computer interaction" or "human factors". Based on the title and abstract, we kept only papers whose context is the primary topic of interest. Papers that were too specialized (e.g. "surgery context" or "fishing context") were excluded. After the removal of duplicates, 37 papers were left. Sixteen of these papers give their own definition of context. The others either give no definition or use one from another paper from our corpus.
<table><caption>Table 1: Number of SE context-related papers obtained after each database query</caption><thead><tr><th>Database</th><th># output papers</th><th># relevant papers</th></tr></thead><tbody><tr><td>IEEE Xplore</td><td>431</td><td>8</td></tr><tr><td>Web of Science</td><td>224</td><td>3</td></tr><tr><td>Scopus</td><td>247</td><td>19</td></tr><tr><td>ScienceDirect</td><td>118</td><td>3</td></tr><tr><td>Systems Engineering Journal (Wiley)</td><td>41</td><td>3</td></tr><tr><td>INCOSE Papers & Presentations Library</td><td>19</td><td>1</td></tr><tr><td><strong>Total</strong></td><td><strong>1080</strong></td><td><strong>37</strong></td></tr></tbody></table>

We found that most of the 37 papers obtained analyze context from a specialized and technocentric viewpoint, but very few study the notion of context from a high-level and holistic approach to SE and HSI. The dominant specialized engineering domains in this corpus include Cyber-Physical Systems, Artificial Intelligence, Information Systems, Design Processes, Computer Science and Ubiquitous Computing.

Therefore, we started from this corpus and extended it to include other papers from other disciplines. In particular, the study of context has roots in the Linguistics and Cognitive Engineering domains. The series of *International and Interdisciplinary Conferences on Modeling and Using Context (CONTEXT)*† has provided us with a valuable source of high-level discussions on context and how it relates to Social Sciences, Human Activity Analysis and Engineering. We identified 44 sources that we added to our initial corpus of 37 papers and ended up with a total of 81 exploitable sources, 44 giving an explicit definition of context. Table 2 gives an overview of the disciplines covered by our corpus, as well as the number of definitions provided per discipline. Appendix A lists the 44 definitions we obtained.

# 3 Towards a definition of the operational context of complex sociotechnical systems

## 3.1 Brief overview of context literature

Multiple approaches have been taken when it comes to context research. Bazire's earlier comparative study of context definitions found in the literature⁶ demonstrates a lack of a consensual definition, primarily because the notion of context transcends multiple research and industrial areas. Some studies gave an attempt to provide a formal definition of context. McCarthy⁴⁷, for instance, constructs a theory of contexts that revolves around symbolic propositional sentences such as *ist(c, p)*, meaning that proposition *p* holds in context *c* (e.g. *ist("fog around airport", "controller's visibility is reduced")). Subsequent works built upon McCarthy's work to formalize context as first-class objects, especially in Artificial Intelligence (AI), as Akman did in the field of Natural Language Processing (NLP)³. Another significant amount of research regarding context definition and representation is software-centric as it comes mainly from context-aware computing³⁹. Strang⁶⁶ and Koc⁴⁰ provide surveys and comparisons of common context modelling techniques for distributed systems, namely *key-value models*, *markup scheme models*, *graphical models*, *object-oriented models*, *logic based models* and *ontology based models*. Other related areas interested in context include ambient intelligent systems⁴¹,

<footnote>†https://link.springer.com/conference/context</footnote>
<table><caption>Table 2: Selected sources statistics per domain</caption><thead><tr><th>Research domain</th><th># papers</th><th># definitions</th></tr></thead><tbody><tr><td>Context-Aware Computing</td><td>8</td><td>4</td></tr><tr><td>Computer Science</td><td>7</td><td>5</td></tr><tr><td>Design Processes</td><td>6</td><td>3</td></tr><tr><td>Systems Engineering</td><td>7</td><td>1</td></tr><tr><td>Complex Systems</td><td>5</td><td>4</td></tr><tr><td>Cognitive Sciences</td><td>5</td><td>4</td></tr><tr><td>Business Processes</td><td>5</td><td>1</td></tr><tr><td>Artificial Intelligence</td><td>4</td><td>1</td></tr><tr><td>Requirements Engineering</td><td>4</td><td>2</td></tr><tr><td>Ubiquitous Computing</td><td>4</td><td>2</td></tr><tr><td>Systems of Systems</td><td>4</td><td>2</td></tr><tr><td>Human-Computer Interaction</td><td>3</td><td>2</td></tr><tr><td>Cyber-Physical Systems</td><td>3</td><td>3</td></tr><tr><td>Social Sciences</td><td>2</td><td>1</td></tr><tr><td>Information Systems</td><td>2</td><td>0</td></tr><tr><td>Intelligent Systems</td><td>2</td><td>2</td></tr><tr><td>Miscellaneous</td><td>10</td><td>7</td></tr><tr><td><strong>Total</strong></td><td><strong>81</strong></td><td><strong>44</strong></td></tr></tbody></table>

human-computer interaction², and cyber-physical systems¹⁶,²¹. Almost all of these works take a distributed system architecture point of view and treat context as a set that comprises objects, situations or information which somehow interact with and influence the system. The system is aware of its context by the means of multiple sensors which continuously gather and process data from the system's environment.

Some research contributions are concerned with the study of context with respect to human activity and behavior. Two examples of interrelated context representations commonly found in the literature are Contextual Graphs (CxGs) and Contextual-Based Reasoning (CxBR). Brézillon¹⁵ introduces CxGs as a formalism for representing reasoning in context. With the CxG paradigm, context is defined as the sum of three types of knowledge: *external knowledge*, *contextual knowledge* and *proceduralized context*. External knowledge comprises all the information that is irrelevant to the execution of a task performed by an agent. Conversely, contextual knowledge includes all the contextual elements whose *instantiation* (i.e. values) matter and may influence task execution. Proceduralized context is the subset of contextual knowledge extracted and processed by an agent performing some task at a given time. These three elements are not static: they evolve through time and depend on the current *focus*, meaning that they differ according to the task currently processed by one or several agents.

A complementary paradigm for CxG context engineering (and not necessarily a competing one according to the comparative study done by Lorins⁴⁴) is embodied by CxBIR, as presented by Stensrud⁶⁵. CxBIR models are one example of object-oriented models that aim to make context agents modular and adaptable to the task being realized. CxBIR models are particularly tailored to tactical situations in which some agents must make real-time decisions. In CxBIR, an agent performs a *mission* to achieve a set of *goals*, bounded by some *constraints* and partitioned by several *contexts*. CxBIR emphasizes that only a fraction of context is relevant to an agent performing a task at a time.
This relevant fraction is called the *active context*. Environmental conditions and agent stimuli can change the active context at any time. The conditions for transitioning from one context to another are encapsulated into *context-transition logic* and *sentinel rules*. Gonzalez³⁰ illustrates practical applications of CxBR implementations and emphasizes that CxBR is strongly tied to yet another context reasoning approach from Turner called *Context-Mediated Behavior (CMB)*⁶⁷, which in turn has roots in *Case-Based Reasoning*³⁶,⁷⁰.

SE and HSI-related resources often refer to context: the NASA Human Systems Integration Handbook⁵¹ talks about the *operational context* or *mission context*. The INCOSE SE Handbook⁶⁹ treats context as a synonym for *operating environment* that includes an *operational environment*, a *threat environment* and a *resource environment*, as well as *collaborating and competing systems*. However, thorough context studies from these fields are sparse and seldom conclusive. The SEBoK references Flood's definition²⁶ stating that context "describes the system relationships and environment, resolved around a selected system-of-interest". Context is then described as a "diagram defining the highest level view of a system in its environment". It is what the system of interest interacts with through its external interfaces. ISO/IEC/IEEE 29148:2011³⁴ states that those interactions can be described by operational scenarios ("a scenario is a step-by-step description of how the proposed system should operate and interact with its users and its external interfaces under a given set of circumstances."). However, the problem is that modeling context at the highest level only is insufficient. The next section will introduce our approach, which consists in modeling context at several hierarchical levels of the system. Especially, we want to model the change of contextual element values as operational scenarios describing the system behavior progress. In other words, we want to model changes happening within the context, whereas the literature only model changes happening within the system itself.

## 3.2 Operational context definition

As Mena⁷ points out, "defining and studying context depends closely on the domain, and application nature". The objective of this section is to synthesize the many context definitions found in the literature and build an HSI-related generalized definition of the operational context of a system. Most context definitions of our corpus are related to the context of some system or product. However, they are often too specific to the use case in which they are being discussed and thus can hardly be generalized to all systems, particularly complex sociotechnical systems. Some other works address context from a higher-level conceptual viewpoint, trying to define it in general. However, these works, in turn, often produce too broad definitions to be applicable to any particular case study. In this respect, Dey's contribution is one of the most cited ones²³. Dey defines context as "any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves". Winograd⁷¹ adds that something is in context "because of its operational relevance at a given time, not because of its inherent properties".

We synthesized the 44 context definitions from our corpus in order to build a generalized context definition of the operational context of complex sociotechnical systems. The list of the 44 definitions used are listed in appendix A. We extracted the meaningful words or groups of words found in each definition and aggregated them according to how strongly they are related. For each lexicon found, we also counted how many times it appeared in the definitions. We then assigned a name to each resulting group of lexicons based on the most frequently used term in the group. We clustered the groups that were related and adapted the most-frequently used terms to use a terminology that fits the SE and HSI terminology. These third-level terms are what we eventually used in our built definition. Table 3 presents the results of this process.
<table><caption>Table 3: Terminology built from context definitions in the literature. Each number in parentheses indicates how many occurrences of the word or group of words have been found in our corpus of definitions.</caption><thead><tr><th>Our terminology</th><th>Most-frequently used terminology</th><th>Literature terminology</th></tr></thead><tbody><tr><td rowspan="3">relevant contextual elements</td><td>environment</td><td>environment(8), not explicit(3), physical environment(2), external(2), surrounding(1), encircling(1), nearby(1), social environment(1), psychological environment(1), outside(1), place(1), emergent(1), where(1)</td></tr><tr><td>elements</td><td>elements(7), information(5), time(4), location(2), knowledge(1), space(1), lighting(1), noise level(1), network connectivity(1), communication costs(1), communication bandwidth(1), social situation(1)</td></tr><tr><td>relevant</td><td>relevant(9), of interest(3), subset(2), domain(1), part of the world(1)</td></tr><tr><td rowspan="2">agent</td><td>user</td><td>user(5), person(2), who(2), actor(2), human(2), agent(2), individual(2), role(1)</td></tr><tr><td>entity</td><td>entity(7), system(7), object(5), product(3), thing(3), something(2), application(2), computer(2), resources(2), equipment(1), hardware(1), software(1), artifact(1), what(1), structures(1), materials(1)</td></tr><tr><td>focus</td><td>focus</td><td>focus(3), specific(3), subject(2), [object] of interest(1), object being processed(1), particular(1), given(1), concept(1), current(1)</td></tr><tr><td rowspan="2">function</td><td>behavior</td><td>behavior(6), task(3), activity(3), operation(3), process(1), execution(1), action(1), computation(1)</td></tr><tr><td>goal</td><td>goal(3), purpose(1), scope(1), service(1), completion(1), mission(1), problem(1)</td></tr><tr><td>influence</td><td>influence</td><td>influence(3), constraint(3), be depended upon(2), affect(1), threat(1), enable(1), implications(1), sensitivity(1), induction(1), adaptation(1), changing(1)</td></tr><tr><td>help explain</td><td>help explain</td><td>help explain(1), solve(1), characterize(1), learn(1), understand(1), classify(1), perceive(1), predict(1), recognize(1), interpret(1), describe(1), reason(1), infer(1), sense(1), meaning(1)</td></tr><tr><td>situation</td><td>situation</td><td>situation(9), circumstance(5), state(3), underpinnings(2), physical state(1), conceptual state(1), characteristics(1), background(1), setting(1)</td></tr><tr><td>event</td><td>conditions</td><td>conditions(4), factors(2), patterns(2), event(1), happening(1), stimuli(1), causes(1)</td></tr></tbody></table>
Building upon this classification, we establish and use the following definitions:

- *Context* is a historical sequence of situations, triggered by events, that influence and help explain the behavior of a focus.

- A *focus* is a couple (*structure*, *function*), where a structure is formed by a *system*, and a *function* is defined by a role and resources to achieve some goal.

- A *situation* is the set of all surrounding contextual element values that are relevant to the focused system's goal at a given time.

- A *contextual element* is a variable that can hold any pre-defined value.

- An *event* is what triggers the transition from one situation to another by altering contextual elements values.

These definitions are graphically illustrated in Figure 1. The figure clarifies how context, situations, events, focus and contextual elements interrelate.

<figure><img src="image_2.png" /><figcaption>Figure 1: A generalized operational context representation</figcaption></figure>

What immediately stems from these definitions is that context is inherently related, to but different from a situation and an event. Furthermore, context can only be specified relative to some focus object. The focus is a system performing a function in the sense of the HSI literature, meaning that a function has a role and a set of enabling resources¹⁰. Defining context as a sequence of situations also emphasizes its dynamic nature and the importance of looking at past contextual element values to understand the behavior of a system at a given time. Section 4 will further detail all these context properties.
# 4 Context characterization

The sources from our corpus often discuss context in their respective application domains but without providing an explicit definition or characterization of it. The properties of context ought to be elicited mainly from the engineering literature in order to start building a framework of complex sociotechnical system design where context can be understood even before system deployment. Following the same process as our semantic analysis for constructing a generalized context definition, we aggregated the implicit and explicit properties of system context emerging from the literature. We obtained six main context properties, listed in Table 4, that we define and explain in this section. We justify for each property its relevance to HSI. However, before we analyze each property individually, we first review the definition of a system according to the HSI literature.

<table><caption>Table 4: Overview of context properties</caption><thead><tr><th>Context property</th><th>Symbology</th><th>Short description</th></tr></thead><tbody><tr><td>Specific</td><td></td><td>Context is always relative to some focus, defined as a couple (structure; function).</td></tr><tr><td>Curated</td><td></td><td>Only a few contextual elements have a real relevance to the system and its behavior.</td></tr><tr><td>Holistic</td><td></td><td>The whole system's context is more than the individual contexts of its subsystems.</td></tr><tr><td>Transient</td><td></td><td>Context is not static and definitive, but changes through time.</td></tr><tr><td>Entangled</td><td></td><td>Context affects the system's resources, and the system's behavior affects context.</td></tr><tr><td>Persistent</td><td></td><td>A contextual element's former value can still have a relevance to the current situation.</td></tr></tbody></table>

## 4.1 The HSI's view of a system

A system in HSI is defined as an entity equipped with cognitive capabilities¹¹. A system is strongly related to the notion of *agent* in the AI literature, and the two terms are often used interchangeably⁴⁸. A system in the sense of HSI is a System of Systems (SoS) as long as it is composed by at least two different entities. More precisely, a system (or agent) has a structure and one or several functions¹¹.
A structure can be a human, a machine or a component of either (e.g. an eye is a structure associated with the cognitive function "seeing"). Hitchins defines a function from a SE viewpoint as *"an action, a task, or an activity performed to achieve a desired outcome."*. The HSI literature completes this definition and states that a function has a role, a context of validity, and resources, which can be systems themselves, hence recursively defining a system as a SoS. Therefore, in this paper, we will always adopt a multi-agent, SoS viewpoint when it comes to studying systems and their behavior.

It should be noted that following this definition of a system, human and organizational stakeholders are not entities that interface with the system in the traditional SE sense. Instead, they are subsystems themselves, each with their own set of subsystems comprising their own structures and functions. These subsystems are not necessarily independent from one another, as the relationships between systems, subsystems and environments is porous⁴⁵. The consequence of this is that in HSI, we often don't make a distinction between a *system*, an *agent*, a SoS or an integrated system. Figure 2 gives a representation of a SoS in the sense of HSI.

<figure><img src="image_3.png" /><figcaption>Figure 2: A system is recursively defined as having a structure and functions, each function having resources which are systems. Hence a system is a system of systems. A focus within this hierarchy of systems is a couple (*structure*, *function*)</figcaption></figure>

* Every possible focus is associated with a context.
In the remainder of this section, we will detail each of the six properties and clarify their relevance to the problem of designing complex sociotechnical systems.

## 4.2 Context is specific

Brézillon¹⁴ characterizes context as "*the dressing of a focus*" to denote that changing one or more contextual element values (what he calls "the dressing") may affect the behavior of some actor (what he calls "the focus"). "*Focus*" here refers to whatever is affected by changes in the context. Since we base ourselves on the HSI definition of a system (Subsection 4.1), we define the focus as a couple (structure, function). Therefore, the context of a given focus comprises the contextual elements that can change the behavior of this focus (i.e. of the structure when it performs its function). Hence contextual elements are to be defined at each level of the system, for each structure and one of its assigned functions. Specifying a structure alone is insufficient information to determine the context. For instance, the relevant contextual information for a ground controller (the system) trying to log into the ATC database (the function) vastly differs from that for the same controller giving a departure clearance to a pilot. Therefore, the context is specific to a structure's function.

We saw in Subsection 4.1 that a system is recursively defined as a structure with functions being themselves systems. A focus is the specification of one system within the overall SoS hierarchy along with one of its assigned functions. The system performs an activity to achieve the role of one of its functions. The relevant contextual information of the focus is any information that influences and helps explain this activity. Conversely, the activity of the focused system may impact their surrounding contextual elements. Section 5 will illustrate through an example how context and systems' activities interrelate.

## 4.3 Context is curated

Dey²³ uses the word "relevant" in his definition to denote that he is only interested in situations that matter to a given application and its users. Similarly, we treat context as a partition of real-world knowledge into multiple pieces of information, called contextual elements, from which only a slight amount is relevant to explain and influence the state and behavior of a system. We call this set of relevant contextual elements a situation. A situation is a *curated* view of the contextual information which is relevant to a focus at a given moment in time. In any event, tracking all possible contextual elements and their values at a given time would be an unachievable task. As Giunchiglia²⁹ puts it, "*reasoning is usually performed on a subset of the global knowledge base; we never consider all we know but only a very small subset of it*". Benerecetti⁸ talks about *partiality* of the representation of the world.

Other authors also use the word "relevance" in their context definitions. Henricksen³¹ defines the context of a task as "*the set of circumstances surrounding it that are potentially of relevance to its completion*". Zimmermann⁷² states that "*the activity predominantly determines the relevancy of context elements in specific situations*". A common trait of these definitions is that context is relevant only with respect to a *task* or an *activity*. Tasks and activities in HSI are two interrelated but distinct concepts. A task in HSI is what is prescribed to be done by a system, whereas an activity is what is effectively done by the system in operation¹¹. Nevertheless, this close relationship between context and tasks or activities may be linked to recent HSI endeavors that sought to understand the behavior of a system procedurally rather than declaratively⁹. In other words, one ought to first investigate the use of a system rather than its architecture if one wants to understand what contextual information may or may not be relevant. Scenario-Based Design (SBD) techniques⁵⁷ are considered to be interesting to explore in order to support this approach.
## 4.4 Context is holistic

The HSI's recursive definition of a system induces us to adopt a multi-agent, multi-scale SoS viewpoint as we already discussed in Subsection 4.1. We could study the context of any function of any system within the SoS architecture tree, thus identifying numerous focuses of interest. Of course, two different focuses can share relevant contextual elements in their respective situations at a given time. Wissen⁶⁸ states that two actors can share the same context elements, which are grouped in what he calls *shared internal context* and *shared external context*. For instance, the choice of a particular Standard Instrument Arrival (STAR) strategy for an approaching aircraft will affect the behavior of all the controllers assigned to this particular flight. In other words, the Ground Controller and the Tower Controller, which are two distinct subsystems of the "Control Tower" system, share in their respective contexts the "Arrival Strategy" contextual element. Similarly, since both controllers are subsystems of the "Control Tower" system, the "Arrival Strategy" contextual element is also part of the context of the function "Guide aircrafts upon arrival" from the "Control Tower" system. Consequently, the context for a system and one of its associated function defined at a certain level of the SoS hierarchy is *partially* defined by the contexts of the subsystems of that system. The context of the higher-level system is then a context composed of the contexts of the subsystems. Similarly to the notions of SoS and function of functions, context at a particular system level may then be viewed as a context of contexts.

However, such a recursive context model should be treated with caution, as the context of a focus cannot *entirely* be defined as the sum of its subcontexts. Indeed, Shah⁶³ introduces the emergence of system contexts and argues that the context of a system is "*neither the union nor the intersection of its constituents*". This is because some contextual elements can prove relevant to a high-level context although were not within the subsystems' nested contexts. Conversely, the relevance of nested contextual elements can fade away when the corresponding focus is no longer considered in isolation. As an example, consider an isolated remote ATC center whose meteorological data is entirely captured locally. The accuracy of the instruments from the local weather station is a relevant contextual element to this center's context. If, however, the local center gets inoperable, then the remote center needs to connect to the national weather forecast services. In this case, the accuracy of the instruments from the local weather station is no longer critical for the center to be operable, since the weather data is now streamed directly from the national forecast facilities. Therefore, the corresponding contextual element value (i.e. the accuracy of the instruments) is no longer relevant to the context of the newly-created system which comprises the remote center and the national station. On the other hand, the quality of data link transmissions from the national services to the remote center is a new emerging contextual element that is relevant to this system. Hence, context is holistic in the sense that the context can differ based on how subsystems inherit properties and contexts from higher-level systems and functions, and how context emerges as technologies, humans and organizations are being integrated.

## 4.5 Context is transient

SE often synonymizes context with environment, which contains anything external to the system of interest. Context is thus defined once by static block or use case diagrams that only encapsulate the relationships between these external entities and the system. However, our definition suggests that context is dynamic and must be reevaluated in permanence at operation time. Wissen⁶⁸ backs up this idea and states that actors (i.e. systems) constantly reevaluate their context with respect to their set of appropriate behaviors. The same author refers to context variations as *changes*, *transformations*, *shifts* or *switches* according to whether the changing context is internal or external to the actor's interpretation of their environment, as well as the significance of the variation. Actors
can also influence other actors' contexts through *negotiation* processes triggered by social-cultural constraints. In our definition, we encapsulate this notion of context variation as an event that alters the value of one or more contextual elements, hence triggering the transition from one situation to another. Context is always moving.

Brézillon's CxG formalism that we mentioned in Subsection 3.1 strongly relies upon the observation that human activity changes according to the values of contextual elements. CxG help model the realization of some task in terms of a series of *diagnoses* and *actions*. Actions, in particular, introduce changes in the situation or knowledge about the situation. The CxG approach seems compelling to our HSI problem. Indeed, one key point of the theory is that there is a difference between task models and practice models¹⁴. Task models describe the theoretical tasks that need to be executed by agents to achieve a specific set of objectives. However, what the agents actually perform (the practice model) may differ from the task model. This discrepancy directly aligns with the distinction made in the HSI literature between a prescribed task and an effective activity. HSI advocates for performing Human-in-the-loop Simulation (HITLS)⁵⁸ on virtual environments to witness how human activity may differ from what the system designers initially anticipated. We add that what drives human activity to such unanticipated and emerging behavior is the lack of foresight at design time on the operational context surrounding the system and its subsystems.

## 4.6 Context is entangled

Context is entangled with the system it refers to as context has long-term and short-term impacts on how the system behaves, and the system's behavior impacts context. Zimmermann⁷² points out that "*human entities change their goals very frequently depending on quickly appearing conditions or decisions*". In our definition, we link these conditions to events that transition context from one situation to another. An event can be external (the condition for the occurrence of the event comes from outside the boundary of the system, e.g. weather changes the visibility of the track) or internal (the event is a consequence of a decision made by a system, e.g. a controller makes the crash barrier on the track rise).

Being in a different situation means that some contextual elements have shifted their values. A contextual element value is changed due to an internal or external event. Shifting a contextual element's may put constraints⁶⁸ or develop opportunities on the system's resources (e.g. disconnecting a local remote center from the national weather forecast services is a constraint on the resources available to the center). Therefore, context is strongly related to "*what resources are nearby*", as stated by Schilit⁶⁰. Gal²⁷ further establishes a relationship between tasks, goals and resources.

As such, shifting the values of contextual elements directly affects the system's available resources. When a resource becomes unavailable because of the evolution of context, the function it serves can either no longer be ensured or must be adjusted to cope with the new situation, depending on the severity scale of the event and its resulting situation. Nwiabu⁵³ classifies situations as either *normal*, *warning* or *danger* according to their effects on the goal attainment status of the users of a context-aware system. We will use the more general terms *nominal*, *off-nominal* and *emergency* to qualify a situation and the human activity that results from it.

## 4.7 Context is persistent

Nwiabu's work about situation awareness in context-aware case-based decision support⁵³ asserts that building an understanding of the current situation of a system implies that "*the system must keep a finite history of the time-space information on the state of the environment of the entities*". We enlarge this claim by stating that the past values of *any* contextual element may have an incidence on
the understanding of the current situation. We thereby emphasize the difference between a situation,
a context and, to some extent, an event: our definition characterizes a situation as a set of values
affected to a cluster of contextual elements *at a given time*, whereas context is a *persistent* entity
which may have a long-term impact on the system. Giunchiglia<sup>29</sup> claims that "*a situation is the
complete state of the universe at an instant of time*". However, Giunchiglia then treats context as
the subset of this state which is used during a given reasoning process from an individual.

Our approach is slightly different, as we only keep in our definition of a situation the elements of
the state that actually *matter* to our focus. We then encapsulate the sequence of situations through
time within what we call context. The advantage of this view is that previous situations (i.e. previous
states) are recorded and can be considered during reasoning and decision-making processes carried
out by a system. Furthermore, it is in line with the principles of Case-Based Reasoning (CBR)
systems in which a problematic situation is solved by utilizing the specific knowledge from previous
situations (known as *cases*)<sup>1</sup>. Finally, we treat an event as a singularity in time that triggers the
transition from one situation to another, as with to the notion of *context-transition logic* in the
CxBR paradigm<sup>30</sup>.

5 Case study: modeling context for air traffic operations

In an ATC tower environment, our intuition is that context revolves around a certain amount of
information, including environmental conditions (e.g. weather and visibility), nominal, off-nominal
and emergency events leading to accordingly different types of short and long-term situations (e.g.
an aircraft is about to enter the responsibility area of the approach controllers, an obstacle is on
the runway, or air traffic is higher than usual), and internal state knowledge (e.g. state of the track
fusion servers). Many related contextual elements should be identified during system acquisition.
Context influences operations (e.g. ILS<sup>‡</sup> landing should be mandatory when the airspace is too
foggy), and operations influence context (e.g. the pilot receives a touch-and-go instruction from
a controller, thereby extending their flight duration for another couple of minutes). Furthermore,
knowledge of most contextual elements can prove entirely irrelevant for specific tasks but turns out
necessary for others (e.g. time of day certainly has an impact on track lighting configuration but
does not influence user logging to the authentication server). The relevancy of contextual elements
really depends on the choice of focus.

Should we consider a remote ATC environment, context is an even more complex matter to deal
with, as the operational context of the relocated controllers is no longer the same as the airfield
environmental context. The human and machine agents located in the vicinity of the remote center
should construct a robust situation awareness<sup>25</sup> of the distant airfield configuration (Figures 3a and
3b). Since HSI effort should consider the needs of every human stakeholder and not only end-users,
we might also think about the training process and how we should design the training center for
a new ATC system. Such a center would yet exhibit a new context environment (Figure 3c) with
different constraints and opportunities.

An HSI approach to the modeling of ATC operations would involve the elicitation of AS-IS and
TO-BE scenarios constructed in close collaboration with the Subject Matter Expertss (SMEs). We
already established in Section 4 that modifying the context affects the availability of the system's
resources, and altering the resources may have a consequence on the feasibility of the underlying
functions, thereby breaking the whole resource hierarchy. Therefore, comprehending context shifts
and their impact on the system's operation is crucial to understanding the overall system's behavior.
Therefore, our scenario elicitation stage should be followed by a scenario contextualization stage that

<footnote>‡ILS: *Instrument Landing System*</footnote>
<figure><img src="image_4.png" /><figcaption>Figure 3: Different ATC paradigms yield different context configurations</figcaption></figure>

enriches the scenarios' information to capture the sensitivity of human activities to their operational context.

Figure 4 gives an example of a simple ATC system decomposed as a resource tree of systems with their structures and functions. The ATC tower is the highest-level system of systems whose primary function is to regulate air and ground traffic. To be carried out, this function needs resources which are the subsystems of the tower, namely the approach room and the glass cab on top. The cab itself is a system with a function (regulate traffic within a 20 km radius). This function has two resources: the ground controller (GC), who supervises the control between the tower and the track, and the tower controller (TC), who controls what happens on the track. To this end, the TC requires the cognitive resource of having direct visibility over the track. It should be noted that the further we go down the tree, the more granular and specific the resources are. The leaves eventually amount to essential physical and cognitive functions¹⁰. When we construct these resource trees along with the scenarios in collaboration with the experts, we should also attach to each resource in the hierarchy a sensitivity level to the values of contextual elements. For instance, if the weather contextual element is set to "heavy fog", the "Visualize" resource needed by the TC to carry out their "Control track" function will become unavailable. As such, the TC can no longer appropriately perform their duty, and we should collaborate further with the SMEs to refine the underlying scenarios and accommodate them to this new constraint. Moreover, since context is persistent, we should always have in mind that a resource may be impacted by the previous values of a contextual element (e.g. a rainy weather an hour ago will affect the landing and departure procedures for as long as the track is wet). Thus, a resource's availability should always be checked against a log of past contextual element values.

# 6 Conclusion

The design of complex sociotechnical systems can no longer rely solely on technological considerations but ought to regard the human and organizational dimensions of the system during operation¹². The present work is a step towards this end and builds an early understanding of the operational context of these systems in support of the design of such systems. We synthesized many discussions on context from different literature domains and constructed from them a generalized HSI-oriented definition of context. We complemented this definition by providing six immutable properties of
<figure><img src="image_5.png" /><figcaption>Figure 4: A simple ATC SoS</figcaption></figure>

the operational context of complex sociotechnical systems, namely that context is specific, curated, holistic, transient, entangled and persistent.

We aim to develop this model further and integrate it with previous works on HSI methodologies and tools which harness SBD and HITLS techniques to capture as much contextual knowledge as possible before the system is manufactured and operationalized. Our eventual goal is to develop a full methodology and a supporting software tool for the acquisition of contextualized scenarios built in close collaboration with SME. Contextualizing the expert AS-IS scenarios should highlight how context affects the resources of the systems in the performance of their duties. Knowledge of the affected resources should help designers and SME appropriately reallocate functions and create new TO-BE scenarios that will depict the use of a future system of interest.
References

[1] AAMODT, A., AND PLAZA, E. Case-based reasoning: Foundational issues, methodological variations, and system approaches. *AI Communications* 7 (08 2001), 39–59.

[2] AGARWAL, N. K. What do we mean when we talk about context? In *2018 IEEE 34th International Conference on Data Engineering Workshops (ICDEW)* (2018), pp. 29–32.

[3] AKMAN, V., AND SURAV, M. The use of situation theory in context modeling. *Computational Intelligence* 13, 3 (1997), 427–438.

[4] ANALYTI, A., THEODORAKIS, M., SPYRATOS, N., AND CONSTANTOPOULOS, P. Contextualization as an independent abstraction mechanism for conceptual modeling. *Information Systems* 32, 1 (2007), 24–60.

[5] BALABKO, P., AND WEGMANN, A. Context based reasoning in business process models. In *Proceedings Fifth IEEE Workshop on Mobile Computing Systems and Applications* (2003), ., pp. 120–128.

[6] BAZIRE, M., AND BRÉZILLON, P. Understanding context before using it. In *Modeling and Using Context* (Berlin, Heidelberg, 2005), A. Dey, B. Kokinov, D. Leake, and R. Turner, Eds., ., Springer Berlin Heidelberg, pp. 29–40.

[7] BEN MENA, T., BELLAMINE-BEN SAOUD, N., BEN AHMED, M., AND PAVARD, B. Towards a methodology for context sensitive systems development. In *Modeling and Using Context* (Berlin, Heidelberg, 2007), B. Kokinov, D. C. Richardson, T. R. Roth-Berghofer, and L. Vieu, Eds., ., Springer Berlin Heidelberg, pp. 56–68.

[8] BENERECETTI, M., BOUQUET, P., AND GHIDINI, C. Contextual reasoning distilled. *J. Exp. Theor. Artif. Intell.* 12 (07 2000), 279–305.

[9] BOY, G., AND MOREL, C. The machine as a partner: Human-machine teaming design using the prodec method. *Work* 73 (10 2022), 1–17.

[10] BOY, G. A. *Cognitive Function Analysis*. 01 1998.

[11] BOY, G. A. Human systems integration and design. In *Handbook of Human Factors and Ergonomics*, G. Salvendy and W. Karwowski, Eds. John Wiley & Sons, Ltd, 2021, ch. 2.

[12] BOY, G. A. An epistemological approach to human systems integration. *Technology in Society* 74 (2023), 102298.

[13] BOY, G.-A., AND KENNEDY, G. *Human Systems Integration Primer Volume One. INCOSE*. G. Eds, San Diego, CA, USA, 2023.

[14] BRÉZILLON, P. Task-realization models in contextual graphs. In *Modeling and Using Context* (Berlin, Heidelberg, 2005), A. Dey, B. Kokinov, D. Leake, and R. Turner, Eds., ., Springer Berlin Heidelberg, pp. 55–68.

[15] BRÉZILLON, P. Context modeling: Task model and practice model. In *Modeling and Using Context* (Berlin, Heidelberg, 2007), B. Kokinov, D. C. Richardson, T. R. Roth-Berghofer, and L. Vieu, Eds., ., Springer Berlin Heidelberg, pp. 122–135.
[16] BRINGS, J., DAUN, M., HILDEBRANDT, C., AND TÖRSLEFF, S. An ontological context modeling framework for coping with the dynamic contexts of cyber-physical systems. In *Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development* (2018), ,. SCITEPRESS - Science and Technology Publications, Lda, p. 396–403.

[17] CADAVID, G., AND ZAPATA, L. *Ergonomic/Human Factors in the Design Process*. Methodological Tool for Characterization of the User, vol. 485. 01 2016, pp. 505–513.

[18] CHEBBA, A., BOUABANA-TEBIBEL, T., AND RUBIN, S. H. Context in ontology for knowledge representation. In *International Conference on Computer Science, Applied Mathematics and Applications* (2015), .

[19] CROWLEY, J. L. Context driven observation of human activity. In *Ambient Intelligence* (Berlin, Heidelberg, 2003), E. Aarts, R. W. Collier, E. van Loenen, and B. de Ruyter, Eds., ., Springer Berlin Heidelberg, pp. 101–118.

[20] CRYSTAL, D. *A Dictionary of Linguistics and Phonetics*. Blackwell Publishing, 1991.

[21] DAUN, M., AND TENBERGEN, B. Context modeling for cyber-physical systems. *Journal of Software: Evolution and Process* (2022), e2451.

[22] DENIS, M., AND SABAH, G. *Modèles et concepts pour la science cognitive*. Presses universitaires de Grenoble, 1993.

[23] DEY, A. K. Understanding and using context. *Personal Ubiquitous Comput. 5*, 1 (2001), 4–7.

[24] EDMONDS, B. The pragmatic roots of context. In *Modeling and Using Context* (Berlin, Heidelberg, 1999), P. Bouquet, M. Benerecetti, L. Serafini, P. Brézillon, and F. Castellani, Eds., ., Springer Berlin Heidelberg, pp. 119–132.

[25] ENDSLEY, M. Toward a theory of situation awareness in dynamic systems. *Human Factors: The Journal of the Human Factors and Ergonomics Society* 37 (03 1995), 32–64.

[26] FLOOD, R. L., AND CARSON, E. *Dealing with complexity: an introduction to the theory and application of systems science*. Springer Science & Business Media, 1993.

[27] GAL, Y., GROSZ, B., PFEFFER, A., SHIEBER, S., AND ALLAIN, A. The influence of task contexts on the decision-making of humans and computers. In *Modeling and Using Context* (Berlin, Heidelberg, 2007), B. Kokinov, D. C. Richardson, T. R. Roth-Berghofer, and L. Vieu, Eds., Springer Berlin Heidelberg, pp. 206–219.

[28] GARCIA ESTRADA, J., AND RESTREPO, J. Context modelling in a collaborative virtual reality application as support to the design process. .

[29] GIUNCHIGLIA, F. Contextual reasoning. *Epistemologia* 16 (09 1997).

[30] GONZALEZ, A. Modeling human actions through context. *Modélisation et utilisation du contexte* 17 (05 2017).

[31] HENRICKSEN, K., INDULSKA, J., AND RAKOTONIRAINY, A. Generating context management infrastructure from high-level context models. In *Proceedings of the Fourth International Conference on Mobile Data Management* (2002), .

[32] HOUDÉ, O. *Vocabulaire de sciences cognitives*. Presses universitaires de France, 2003.
[33] HUSSEIN, M., HAN, J., AND COLMAN, A. An approach to model-based development of context-aware adaptive systems. In *2011 IEEE 35th Annual Computer Software and Applications Conference* (2011), pp. 205–214.

[34] IEEE. Systems and software engineering – life cycle processes – requirements engineering. *ISO/IEC/IEEE 29148:2011(E)* (2011).

[35] ISO. Iso 9241-11:1998(en).

[36] JALALI, V., AND LEAKE, D. A context-aware approach to selecting adaptations for case-based reasoning. In *Modeling and Using Context* (2013), P. Brézillon, P. Blackburn, and R. Dapoigny, Eds., Springer Berlin Heidelberg, pp. 101–114.

[37] JAOUADI, I., DJEMAA, R., AND BEN-ABDALLAH, H. A generic metamodel for context-aware applications. *Advances in Intelligent Systems and Computing 1089* (01 2015), 587–594.

[38] KIM, Y., AND LEE, S.-W. Service design for product-service systems using context-based activity modeling. In *International Conference on Engineering Design (ICED13)* (10 2011), .

[39] KNAPPMEYER, M., KIANI, S. L., FRÀ, C., MOLTCHANOV, B., AND BAKER, N. Contextml: A light-weight context representation and context management schema. In *Proceedings of the 5th IEEE International Conference on Wireless Pervasive Computing* (2010), ., IEEE Press, p. 367–372.

[40] KOÇ, H., HENNIG, E., JASTRAM, S., AND STARKE, C. State of the art in context modelling – a systematic literature review. In *Advanced Information Systems Engineering Workshops* (2014), L. Iliadis, M. Papazoglou, and K. Pohl, Eds., ., Springer International Publishing, pp. 53–64.

[41] KOFOD-PETERSEN, A., AND CASSENS, J. Explanations and context in ambient intelligent systems. In *Modeling and Using Context* (2007), B. Kokinov, D. C. Richardson, T. R. Roth-Berghofer, and L. Vieu, Eds., ., Springer Berlin Heidelberg, pp. 303–316.

[42] LIEBERMAN, H., AND SELKER, T. Out of context: Computer systems that adapt to, and learn from, context. *IBM Systems Journal* 39, 3.4 (2000), 617–632.

[43] LONGUEVILLE, B., AND GARDONI, M. A survey of context modeling: Approaches, theories and use for engineering design research. The Design Society.

[44] LORINS, P., BRÉZILLON, P., AND GONZALEZ, A. Context-based decision making: Comparison of cxbr and cxgs approaches.

[45] LUHMANN, N. Differentiation of society. *The Canadian Journal of Sociology / Cahiers canadiens de sociologie* 2, 1 (1977), 29–53.

[46] MAGUIRE, M. Context of use within usability activities. *International Journal of Human-Computer Studies* 55, 4 (2001), 453–483.

[47] MCCARTHY, J. Notes on formalizing context. In *Proceedings of the 13th International Joint Conference on Artificial Intelligence - Volume 1* (1993), IJCAI’93, ., Morgan Kaufmann Publishers Inc., p. 555–560.

[48] MINSKY, M. L. *The Society of Mind*. Simon & Schuster, New York, 1988.
[49] MITSUHASHI, D., KANNO, T., INOUE, S., KARIKAWA, D., NONOSE, K., ASATANI, K., AND FURUTA, K. Symbolic context model for resilience engineering. In *Advances in Safety Management and Human Performance - Proceedings of the AHFE 2021 Virtual Conferences on Safety Management and Human Factors, and Human Error, Reliability, Resilience, and Performance, 2021* (2021), P. Arezes and R. Boring, Eds., Lecture Notes in Networks and Systems, ., Springer Science and Business Media Deutschland GmbH, pp. 35-43.

[50] MORDECAI, Y., AND CRAWLEY, E. F. Towards context-awareness in model-based requirements engineering. In *2021 IEEE International Systems Conference (SysCon) (2021)*, ., pp. 1-8.

[51] NASA. *Human Systems Integration Handbook*. NASA, November 2021.

[52] NEMOTO, Y., UEI, K., SATO, K., AND SHIMOMURA, Y. A context-based requirements analysis method for pss design. *Procedia CIRP 30* (2015), 42-47. 7th Industrial Product-Service Systems Conference - PSS, industry transformation for sustainability and business.

[53] NWIABU, N., ALLISON, I., HOLT, P., LOWIT, P., AND OYENEYIN, B. Situation awareness in context-aware case-based decision support. In *2011 IEEE International Multi-Disciplinary Conference on Cognitive Methods in Situation Awareness and Decision Support (CogSIMA)* (2011), pp. 9-16.

[54] PASCOE, J. Adding generic contextual capabilities to wearable computers. In *Digest of Papers. Second International Symposium on Wearable Computers (Cat. No.98EX215)* (1998), ., pp. 92-99.

[55] PIMENTA, M., AND BARTHET, M.-F. Context modelling for a usability oriented approach to interactive systems requirements engineering. In *Proceedings IEEE Symposium and Workshop on Engineering of Computer-Based Systems* (1996), ., pp. 315-321.

[56] POLZER, H., DELAURENTIS, D. A., AND FRY, D. N. Multiplicity of perspectives, context scope, and context shifting events. In *2007 IEEE International Conference on System of Systems Engineering* (2007), ., pp. 1-6.

[57] ROSSON, M. B., AND CARROLL, J. M. *Scenario-Based Design*. L. Erlbaum Associates Inc., 2002, p. 1032-1050.

[58] ROTHROCK, L., AND NARAYANAN, S. *Human-in-the-loop simulations*. Springer, 2011.

[59] SCHARFSTEIN, B.-A. *The Dilemma of Context*. NYU Press, 1989.

[60] SCHILIT, B., ADAMS, N., AND WANT, R. Context-aware computing applications. In *First Workshop on Mobile Computing Systems and Applications* (1994), pp. 85-90.

[61] SCHOENBERG, M. *Context in Complex Systems Governance*. 01 2022, pp. 209-240.

[62] SEBOK EDITORIAL BOARD. Guide to the Systems Engineering Body of Knowledge (SEBoK), version 2.8. Hoboken, NJ: The Trustees of the Stevens Institute of Technology, 2023. [Online; accessed 18 Oct 2023 08:05:35 UTC].

[63] SHAH, N., RHODES, D., AND HASTINGS, D. Systems of systems and emergent system context.

[64] SHEARD, S., COOK, S., HONOUR, E., HYBERTSON, D., KRUPA, J., MCEVER, J., MCKINNEY, D., ONDRUS, P., RYAN, A., SCHEURER, R., ET AL. A complexity primer for systems engineers. *INCOSE Complex Systems Working Group White Paper 1*, 1 (2015), 1-10.
[65] STENSRUD, B., BARRETT, G., AND GONZALEZ, A. Context-based reasoning: A revised specification. In *The Florida AI Research Society* (01 2004), .

[66] STRANG, T., AND LINNHOFF-POPIEN, C. A context modeling survey. In *Proceedings of the Workshop on Advanced Context Modeling, Reasoning and Management as Part of UbiComp* (2004), .

[67] TURNER, R. M. *Context-Mediated Behavior*. Springer New York, 2014, pp. 523–539.

[68] VAN WISSEN, A., KAMPHORST, B., AND VAN EIJK, R. A constraint-based approach to context. In *Modeling and Using Context* (2013), P. Brézillon, P. Blackburn, and R. Dapoigny, Eds., ., Springer Berlin Heidelberg, pp. 171–184.

[69] WALDEN, D. D., ROEDLER, G. J., AND FORSBERG, K. Incose systems engineering handbook version 4: updating the reference for practitioners. In *INCOSE International Symposium* (2015), vol. 25, Wiley Online Library, pp. 678–686.

[70] WATSON, I., AND MARIR, F. Case-based reasoning: A review. *The Knowledge Engineering Review* 9, 4 (1994), 327–354.

[71] WINOGRAD, T. Architectures for context. *Hum.-Comput. Interact.* 16, 2 (2001), 401–419.

[72] ZIMMERMANN, A., LORENZ, A., AND OPPERMANN, R. An operational definition of context. In *Modeling and Using Context* (2007), B. Kokinov, D. C. Richardson, T. R. Roth-Berghofer, and L. Vieu, Eds., ., Springer Berlin Heidelberg, pp. 558–571.

# A Definitions of context used

The 44 definitions of context used throughout this paper are listed below:

## Context-Aware Computing

- *Three important aspects of context are: where you are, who you are with, and what resources are nearby. Context encompasses more than just the user's location, because other things of interest are also mobile and changing. Context includes lighting, noise level, network connectivity, communication costs, communication bandwidth, and even the social situation; e.g., whether you are with your manager or with a co-worker.*<sup>60</sup>

- *Elements for the description of this context information fall into five categories: individuality, activity, location, time, and relations. The activity predominantly determines the relevancy of context elements in specific situations, and the location and time primarily drive the creation of relations between entities and enable the exchange of context information among entities.*<sup>72</sup>

- *The context is the information about the entities that are relevant to the system operation and/or adaptation.*<sup>33</sup>

- *One or more entities that represent context elements that are considered relevant to the interaction between the user and the application.*<sup>37</sup>
## Computer Science

- Context can be considered to be everything that affects the computation except the explicit input and output.⁴²

- Something is context because of the way it is used in interpretation, not due to its inherent properties. The information is context only if there is some action by the user and/or computer whose interpretation is dependent on it, but otherwise is just part of the environment.⁷¹

- A context is defined as a network of situations. A situation network is interpreted as a specification for a federation of processes to observe humans and their actions.¹⁹

- Context is that which constrains something without intervening in it explicitly. Context is the focus of an actor.¹⁵

- A set of objects, within which each object has a set of names and possibly a reference: the reference of the object is another context which “hides” detailed information about the object.⁴

## Design Processes

- A set of relations between the elements of the triad {Artifact-Human-Environment}.²⁸

- Something that encircles and gives a sense to another thing.⁴³

- The context is described by the goal context, the relevant structures, the physical context, and psychological context.³⁸

## Systems Engineering

- Context includes an operational environment, a threat environment and a resource environment, as well as collaborating and competing systems.⁶⁹

## Complex Systems Engineering

- Context describes the system relationships and environment, resolved around a selected system-of-interest. [It is a] diagram defining the highest level view of a system in its environment.²⁶

- The abstraction of those elements of the circumstances in which a model is learned, that are not used explicitly in the production of an inference or prediction when the model is later applied, that allows the recognition of new circumstances where the model can be usefully applied.²⁴

- Context at a high level of abstraction depends on a triplet < Domain, Entity, Problem >. In other words, within a specific given domain, an entity has (or is subject to) a problem, requires a context to solve it.⁷

- Context is the set of circumstances, factors, conditions, or patterns that enable or constrain execution of the system.⁶¹
## Cognitive Sciences

- The subset of the complete state of an individual that is used for reasoning about a given goal.²⁹

- All that may influence a given process whom first causes are known.²²

- A set of situational elements in which the object being processed is included.³²

- The context acts like a set of constraints that influence the behavior of a system (a user or a computer) embedded in a given task.⁶

## Business Processes

- Context is the set of collaborating roles along with their state and behavior.⁵

## Artificial Intelligence

- A context represents a situation, based on environmental conditions and agent stimuli, which induces a certain agent behavior specific to that mission.⁶⁵

## Requirements Engineering

- Context is the set of emergent situational characteristics that influences or is influenced by the activity.⁵⁵

- "A set of spatial-temporal elements related to the person or product. In addition, these spatial and/or temporal elements are called contextual elements".⁵²

## Ubiquitous Computing

- The context of a task is the set of circumstances surrounding it that are potentially of relevance to its completion.³¹

- Context serves two purposes. Initially it is used as a focusing lens on the part of the world that can be perceived. Here the context limits the parts of the knowledge that the system uses to classify the situation. The second use of context is in the context sensitivity layer, where context is viewed as a lens that focuses the part of the system's knowledge that is to be used to satisfy the goal of the situation.⁴¹

## Systems of Systems Engineering

- An operational context can be defined as the interrelated conditions which exemplify a system's state of being and which describe its purpose, scope, and meaning for services it may offer.⁵⁶

- The external entities and conditions that need to be taken into account in order to understand system behavior.⁶³
## Human-Computer Interaction

- Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.²³

- The context of an actor's information behavior consists of elements such as environment, task, actor-source relationship, time, etc. that are relevant to the behavior during the course of interaction and vary based on magnitude, dynamism, patterns and combinations, and that appear differently to the actor than to others, who make an in-group/out-group differentiation of these elements depending on their individual and shared identities.²

## Cyber-Physical Systems

- Context is the subset of physical and conceptual states of interest to a particular entity.⁵⁴

- Context is what resides outside the system boundary and is of relevance for the system and its development process.¹⁶

- Context comprises all objects that are of relevance to the system or its development. It is what cannot be changed during development.²¹

## Social Sciences

- That which environs the object of our interest and helps by its to explain it.⁵⁹

## Intelligent Systems

- A context is a class of situations that has implications for an agent's behavior.⁶⁷

- The "context", as referred to through its name, is a representation of the situations where a concept can be found. It describes the external environment of the concept. A concept can be used to express different "things" and has then different characteristics based on its current situation.¹⁸

## Miscellaneous

- A general term used to refer to specific parts of an utterance (or text) near or adjacent to a unit which is the focus of attention.²⁰

- Whom the product was designed for, what it will be used for and where it will be used.⁴⁶

- Context [of use] includes users, tasks, equipment (hardware, software and materials) and physical and social environments in which a product is used.³⁵

- The activity context refers to the fabricated environment that serves as the stage for human activities. It is conformed by those factors that have a positive or negative influence on the user - environment adaptation process.¹⁷

- "Context" is a synonym for "circumstance," "situation," and "background." It refers to the material, moral, or logical underpinnings of any subject.⁴⁹
- *Material, moral, or logical underpinnings of any subject.*<sup>50</sup>
- *A time and setting in which an event happens.* (Cambridge Dictionary)