This article contributes to an ongoing research project following a Design Science Research (DSR) framework. The project focuses on the development of a conceptual framework that supports designers and military commanders with models and methods, aiming to enhance the understanding and evaluation of military Command and Control systems (C2-systems). Military C2-systems are increasingly dependent on emerging technologies, and this highlights the needs for a conceptual framework to guide integration and development. In this article, we propose an approach to refine the goal model, specifically focusing on low-level goals, within the context of C2 -systems. The overall objective is to validate and refine existing conceptual models, particularly those relating to development aspects. We perform a structured analysis of low-level goals to identify method components for the envisioned framework. By establishing these connections, the article aims to investigate the applicability of existing methods and potential method gaps. Should any disconnects emerge between low-level goals and the method components outlined in the form of a concepts model, this advocates for development of new method components. The findings contribute to practical insights regarding enhancing C2-system design and implementation strategies. The article herby demonstrates applicability of the 4EM method in understanding and refining conceptual models.
The dynamics and unpredictable nature of modern warfare requires a robust development framework that can adapt to rapid changes and new paradigms of warfare [1]. Consequently, there is a need to identify a comprehensive conceptual framework of military Command- and Control systems (C2-systems). As C2-systems increasingly must integrate with emerging technologies, such as AI, robotics, and autonomous systems (RAS) and cyber warfare technologies [2], [3], [4] the need to adapt and refine these frameworks becomes even more urgent. This article, grounded in design science research (DSR), aims to enhance the precision and relevance of goal modeling of C2-systems. This paper aims to refine one of the goals (see goal 3, figure 2) of the C2-systems and to refine existing concepts model, described in [5]. The importance of conceptual models in the military domain extends beyond theoretical utility. These models could be essential in combat operations where the decision-making processes are tightly coupled with technological capabilities. Additionally, conceptual models in the form of enterprise models could be used in the development process, not only to handle the integration of emerging technology into a C2-system, but also to confirm that these integrations are in alignment with applied tactics [6].
To exemplify, when incorporating an AI-based decision support into existing military C2systems, the conceptual model could guide the process from requirement analysis to actual operational system deployment. The conceptual model ensures that all aspects, including operational scenarios, stakeholder feedback, and interoperability with legacy systems, are systematically addressed, thereby improving the overall effectiveness and adaptability of the C2-system [7].
This article builds upon earlier research, particularly the findings outlined in [8], where we identified high-level goals by engaging stakeholders, and in [5], where a preliminary concepts and goal model was outlined. In this article, we suggest a structured analysis of low-level goals to identify method components for the envisioned framework by Employing the 4EM method [9]. This systematic breakdown helps bridge the gap between high-level goals, low-level goals, and requirements. The article contributes to a more comprehensive and integrated development approach of C2-system by identify relations between requirements and the concepts model. This approach represents a step towards identifying requirements, which will be further explored in future works. The scientific contribution lies in demonstrating the applicability of the 4EM framework, offering new insights into its relevance in a military context. Simultaneously, for practitioners, this work aids in evaluating and understanding C2 systems, providing a structured approach when using and improving these systems.
The rest of this paper is structured as follows. In Section 2, we provide a background and overview on related work. Section 3 describes the research approach (DSR) and the principles of decomposition of the goals to requirements. Section 4 presents findings in the form of a decomposed goal models with requirements a table describing the relations between the conceptual model and requirements. Section 5 provides a discussion, and section 6 conclusions and future work.
In [5], the authors describe and discuss a concepts model of a C2-system (see figure 1) that captures
the core components of C2-systems, their interactions, and the impact of emerging technologies
across the military domains. This model, with inspiration from e.g., [10] and [11], highlights the need
to integrate data collection, sense-making, and the planning processes. The model also establishes a
baseline where C2-systems are composed of several conceptual components including people,
processes, communications networks, and command post constellations, all operating within the
framework of multi-domain operations. Consequently, C2-systems are highly dynamic and demand
a holistic approach during design and implementation, especially in the context of Systems of
Systems (SoS) and Socio-Technical Systems (STS) as discussed in earlier articles [8], [
The concepts model is designed taking an interdisciplinary approach that combines insights from military science, different command- and control theoretical frameworks, and information systems (IS) development [5]. This approach is required for enabling the understanding of C2-systems, and for improving their overall functionality in response to evolving operational requirements and technological advancements. It is also highlighting the need to use synergies from collaborations between the military, research agencies, industry, and academia [13].
Future C2-systems must have more flexibility than current systems as they must operate effectively across all operational domains (air, land, sea, space and cyber) [14]. Applying the concepts model into the design of C2-systems will potentially make them more aligned with this need and support time-critical decision-making better.
The development section of the concepts model is colored light-blue, due to the focus of this article.
The goal model, described in [5] and visualized in figure 2 and 3, is outlined to describe high-level goals and their subsequent sub-goals needed for the design, understanding and integration of C2systems. This model connects high-level goals and their corresponding sub-goals, which are essential for integrating new technologies within military C2-systems by providing a structured approach that bridges the concepts model (figure 1) with operational and development strategies [5].
The goal model should be used to analyze goals and sub-goals and how they support and enhance the overarching goal of the C2-system. The large number of sub-goals and the broad spectrum they cover indicates a need to shift from traditional C2-system design to a more integrative and adaptive approach. The socio-technical perspective, that underlines interdependent enhancement of social and technical aspects within a C2-system, is important in understanding this environment [15].
A key feature of the goal model is its emphasis on building on stakeholders’ engagement. By engaging a diverse group of stakeholders through interviews, the development process captures insights about the challenges of integrating new technologies into C2-systems. This approach ensures that the goal model align with real-world requirements and challenges, which improves its relevance [5], [8].
The goal model indicates the need to have an approach were analyzing the C2-system outmatches focusing on optimizing individual components. This approach ensures that all parts of a C2-system work efficiently and support the overarching goal. The overarching goal is refined by AND decomposition relationship into eleven sub-goals. To exemplify, goal 4 (G4) highlights integration between new and legacy systems and the importance of operational continuity, which enhance the overall system capability. Additionally, (G11) underlines the need of continuous evaluation and an improvement mechanism to enable the C2-system to adjust to stakeholder’s feedback.
The goal model not only serves as a tool for C2 -system design, but also as a support when integrating socio-technical principles into military C2-systems. This encourages an environment where emerging technology and the real-world operational needs are in a never-ending dialogue, to enhance the C2-systems capabilities and its adaptability.
The latest research trends in C2-systems development are focusing on understanding the C2-system, with different sub-systems, and the integration of new technologies, to improve combat effectiveness by ensuring coherent coordination of military units and capabilities. This is in response to the complexities of conducting multi-domain operations† (MDO) [14]. In [16], the author delves into the integration of cognitive systems engineering, systems theory, and psychophysiology to support the design of C2-systems. This approach underscores the importance of an integrated analysis to navigate the dynamic and complex nature of military operations.
In [17], the authors discuss how the social and technical domains must interact and why those domains require attention when designing a military C2-system. As future MDO will be complex, this complexity cannot be handled by technology alone [14]. In [18], the complexity of integrating structural and behavioral aspects in C2-system modeling is discussed. The authors highlight the necessity of understanding the structural relationships between the different parts of a C2-system, e.g., comparable with concepts model described in figure 1.
In a series of reports [19], [20], [21], [22], [23], the authors assess the potential and limitations of AI in military applications, such as mission planning, predictive maintenance, wargaming and achieving decision superiority on the battlefield.
In [24], the authors provide an analysis of the future organizational and technical aspects necessary for developing and understanding military C2-systems. They highlight the importance of a dynamic and adaptable C2 development, that can integrate a wide range of stakeholders to address complex and fast changing operational requirements. Consequently, this underscores the necessity to prepare a variety of solutions and configurations that adjusted swiftly in response to evolving threats or a changing operational context. This aligns with our goal-oriented framework, that stress flexibility and stakeholder engagement to improve interoperability and system integration. Additionally, the authors discuss the critical aspect to foster adaptability and innovation among † Multi-domain operations involve coordinating sensors, effectors, and units across multiple domains, like air, land, sea, and space, to handle a complex operational environment. service personnel, including researchers and developers. This perspective harmonizes with our attention on continuous feedback and the iterative refinement.
Overall, the literature, however, reveals a gap regarding the practical implementation of theoretical frameworks [14]. Even a simple C2-system can fail due to a lack of interoperability among the different sub-systems. Here it is important to think beyond mere interoperability, and towards complete integration of every sub-system [25].
This paper is part of a research project aiming to develop conceptual framework, with models and
methods, that would help designers to evaluate and better understand the potential of a SoS, and
how the different sub-systems influence a SoS. The research project applies the DSR framework [26].
The first step of DSR, explicate problem, are described in [
This paper presents the initial steps of the development of the envisioned design artifact. More specifically, we have used the 4EM [6] method to refine the high-level goal into low-level goals, which have been translated into specific requirements for the method. This approach ensures that goals are aligned with the overarching goal, in this case the goal of a military C-2system. In addition, this also allows the identification of specific requirements decomposing high-level goals to low-level goals could also potentially recognize necessary actions to achieve each goal. This level of decomposition is important in complex systems such as military C2-systems.
The decomposition of goals was executed using the 4EM method [9], which provides a structured process for breaking down high-level goals into more detailed sub-goals and finally into specific requirements. To illustrate this process, consider the high-level goal G3 (Develop a framework where stakeholders can use the artefact to simulate the impact of new technology in a military C2-system). The process started with identifying AND/OR relationships to secure that all sub-goals are identified (AND) and that alternative ways to achieving the goal were highlighted (OR). For G3, we exclusively identified AND-decomposition relationships. This initial step involved breaking down G3 into subgoals such as G3.1 (Develop a comprehensive simulation environment for commanders to estimate mission outcomes) and G3.2 (Develop a comprehensive simulation environment for designers and researchers to identify interoperability requirements for new and legacy systems). Each sub-goal was further decomposed into low-level goals by applying the SMART criteria‡ (Specific, Measurable, Achievable, Relevant, and Time-bound). This ensured that each low-level goal aligned with the overall goal. For instance, G3.1 was decomposed into more specific low-level goals such as G3.1.1 (Establish tools for developing realistic scenarios), which was further broken down into G3.1.1.1 (Create a repository of operational scenarios), G3.1.1.2 (Implement real-time data integration into scenarios), and G3.1.1.3 (Develop validation algorithms to ensure scenario realism).
Each low-level goal was then translated into specific requirements to capture the needs of the stakeholders [5]. This translation process aimed to ensure that the resulting requirements would support the development and understanding of C2-systems. For the sub-goal G3.1.1 (Establish tools for developing realistic scenarios), the requirements included R3.1 (The repository shall include a wide range of predefined operational scenarios), R3.2 (The method shall dynamically integrate realtime data feeds), and R3.3 (The validation algorithms shall ensure scenarios reflect realistic operational conditions).
To ensure the objectivity of decisions made during the decomposition process, the process relied on empirical evidence in practical realities and operational contexts. Additionally, one of the co‡ Specific (S), measurable (M), accepted (A), realistic (R) and time-framed (T). authors has a specific expertise§ in military C2-systems, ensuring that the findings are not only theoretically strong but also practically relevant.
In a previous article [5], the authors developed a goal model to address the integration of emerging technologies into military C2-systems. This model describes the high-level goals and decomposes two of these into sub-goals, contributing to an approach to better understanding and improving C2-systems. In this article, the authors continue the decomposition process, focusing on refining goals into low-level goals and finally to specific requirements. This ensures that all aspects of the C2-system are aligned with the overarching goals. However, due to limited space, in this article only one goal is decomposed to requirements. The decomposition result from high-level goal to requirement (for G3) are visualized in figure 4 and 5. § Active army Lieutenant Colonel, experience from commands at different levels.
This section aims to describe and clarify the different parts of the development section of the concepts model, ensuring that the parts development process of the C2-system is cohesively addressed. This relational framework underscores the interconnectedness of requirements and system components, and thereby facilitating a more holistic understanding of C2-system
In the concepts model, C23, Development method, refers to the overall methods for developing architecture and ensures that C2-system development is founded on relevant methodologies. C24 Method component, consist of C24.1 Method component intention, C24.2 Method component guidance and C24.3 Method component modeling language. C24.1 frames the purpose of each method used in the development process, and secure that this method aligns with the overall method. C24.2 provides principles for applying different methods. C24.3 specifies the modeling languages to be used in developing process. C25 Domain modeling component captures the key elements within the specific domain. This includes the definition of domain-specific concepts, i.e., land warfare, to secure that the C2-system is designed and understood within a context of the operational environment and its requirements. C26 Operational and tactical modeling component highlights the operational and tactical aspects of the C2-system, i.e., how the C2-system will support different tactics. It includes tactical decision-making and the integration of new technologies into these processes. This secures that the C2-system is effective in real-world environment. C27 Threat modeling component examines the potential threats that the C2-system might face. It includes for example threat scenarios and secures that the system is resilient and capable of operating under different conditions. C29 Physical component modeling component addresses the physical aspects of the C2-system, as hardware and command posts. It ensures that the physical components are designed to support the operational context. C30 Development process modeling component includes workflows, roles, and responsibilities. It secures that the development process is structured and efficient. C31 Functional modeling component highlights the functional aspects of the C2system and ensures that the system meets the requirements from a functional perspective.
As argued in [5], there is a need for a diverse set of scenarios to cover various operational contexts, i.e., different terrain, opponent, mission, and weather. Hence, G3.1.1 (Establish tools for developing realistic scenarios that test the impact of new technologies in various operational settings) motivates R3.1 (The repository shall include a wide range of predefined operational scenarios) that ensures the simulation environment can use a repository of pre-defined scenarios, which in turn supports the need to be able to model realistic threat settings thus requiring a development method (C23). Additionally, R3.1 supports the need for different scenarios in the development method to ensure coverage of different operational settings in the domain modeling component (C25) and support to the overall agility of the development process modeling component and functional modeling component (C31 and C30). R3.1 also supports the need for realistic threat settings (C27).
Also argued in [5], agility is the capacity to adapt to changing circumstances and this capability must be understood from different perspectives, i.e., tactical/operational perspective, organizational perspective, or development perspective. R3.2 (The method shall dynamically integrate real-time data feeds to ensure scenarios are continuously updated to reflect current operational conditions) strengthen the operational and tactical modeling component (C26) by ensuring scenarios remain relevant and up-to-date and supports the development process modelling component (C30) by providing real-time data for improvement and additionally the functional modeling component (C31) by secure relevant sensemaking. A nearby requirement R3.3, (The validation algorithms shall ensure scenarios accurately reflect realistic operational conditions, enhancing scenario credibility and reliability) supports upholding scenario relevance. This is connected to the concepts model focus on agility. R3.3 secures that scenarios are continually updated with the up-to-date operational data, reflecting present conditions. This means that R3.3 is connected to the development method (C23) as a whole, the development process modeling component (C30) and the method components guidance (C24.2) in the concepts model.
As shown in the concepts model, a C2-system must be functional cross multiple domains, and this affects technological solutions as well as methods and procedures. G3.1.2 (Integrate an interoperability assessment tool into the simulation environment to evaluate how new technologies interact with legacy systems) supports this, given a cross-domain approach. R3.4 (The method shall define and measure specific interoperability metrics, evaluating system compatibility comprehensively) supports understanding and assessing interoperability and connects to (C24.1) the method component intention but also to the domain modeling component (C25), the operational and tactical modeling component (C26) and development process modeling component (C30), by providing a tool to evaluate how well new technologies integrate with legacy systems, ensuring that all components of the C2-system work seamlessly together. Related to R3.4 is R3.5 (The method shall include a robust algorithm for assessing interoperability between new and legacy systems, ensuring seamless integration) and this requirement could be connected to (C24.2) due to the support of an assessment tool to evaluate how well new technologies integrate with legacy systems, and to the physical component modeling (C29) by strengthen compatibility between new and legacy systems. This means the R3.5 also are connected to the development process modeling component (C30).
From a development approach, all perspectives need to be considered, or the performance of the C2-system will be weakened. R3.6 (The method shall provide stakeholders with detailed input options to capture feedback on simulation outcomes) supports the need for this comprehensive approach by providing a mechanism for detailed stakeholder feedback, consequently connected to method component guidance (C24.2) as part of each method component, also to the development process modeling component (C30). An adjacent requirement, R3.7 (The method shall maintain a detailed history of changes and iterations, based on stakeholder feedback, ensuring transparent and traceable development) is also connected to method component guidance (C24.2), and to the development process modeling component (C30) by maintaining a history of changes. Another nearby requirement, R3.8 (The method shall possess capabilities to process feedback, categorize it efficiently, and identify recurring themes and critical issues for systematic improvement), is related to the development process modeling component (C30) by providing systematic feedback and by identifying specific areas for improvement.
As identified when developing the goal model, designers and users must be able to assess the effect of integration of new technology in military C2-systems. Simultaneously, designers must also be able to identify interoperability requirements for new and legacy systems. Requirement R3.9 (The method must include a detailed approach for assessing interoperability requirements within realistic scenarios, ensuring all potential issues are identified and addressed) and R3.10, (The repository shall specifically include scenarios designed to rigorously test interoperability, ensuring robust evaluation of system integration), ensure that interoperability requirements could be assessed. These requirements relate to the domain modeling component (C25), development method (C23) and operational and tactical modeling component (C26).
Similarly related, R3.11 (The model shall simulate a variety of interoperability challenges between new and legacy systems, providing comprehensive testing and validation of system capabilities) connects to domain modeling component (C25) and development process modeling component (C30) to ensure comprehensive testing and validation. C30 X X X X X X X X X
C31 X
The overall analysis of the integration between the concepts model and requirements underscores the need for a comprehensive approach in the design and development of C2-systems. In this section, the authors will discuss the findings and their implications for C2-system development. ** Component in the concepts model.
As highlighted earlier, agility is important in C2-systems. We argue that this is also a valid requirement for including a development process modeling component in the development method. The requirement R3.2, which calls attentions to the integration of real-time data feeds, exemplifies this need for agility. By continuously updating scenarios to reflect current operational conditions, this requirement ensures that the simulation environment remains relevant and up to date. The establishment of a scenario repository (R3.1) is necessary when using different operational contexts and different adversarial actions. This requirement supports the development method (C23), and ensures that the simulation environment is realistic, which is important for the development of a resilient C2-system capable of operating across domains and under various threat conditions. Securing realism of scenarios through validation algorithms is possible by continuously validating scenarios against real-world conditions, and this is supported by R3.3. Realism and agility also mean that the C2-system can provide reliable training environments that prepare users for missions.
The ability to assess and secure interoperability between new and legacy systems will be a key capability of future C2-systems and future capability management methods. Requirements R3.4 and R3.5, focusing on defining interoperability metrics and assessment algorithms, are essential for achieving this interoperability, seamless functionality across all domains. Assessment of interoperability requirements (R3.9) along with rigorous testing of interoperability (R3.10) and simulation of interoperability challenges (R3.11), ensures that all potential integration issues are identified and addressed. Ultimately, the ability to assess and secure interoperability is central for maintaining operational relevant and ensure that new technology improves the effectiveness of the whole C2-system. Incorporating stakeholder feedback through different input options (R3.6), maintaining history of changes (R3.7), and analyzing feedback efficiently (R3.8) are important for the iterative development and continuous improvement. This fostering a development process that is transparent, traceable, and responsive to stakeholder needs, and ensures that the C2-system, and the development methods, improves in accordance with stakeholder expectations. As visualized and highlighted in table 2, there are no requirement connecting to component C24.3 (Method component modeling language). However, at this stage when only one goal (G3) has been decomposed to lowlevel goals and requirements, definitive conclusions cannot yet be drawn.
As C2-systems evolve, so must the methodologies used to develop and refine these systems, ensuring they remain capable of meeting the demands of an increasingly complex and technology-driven battlefield. By continuing the decomposition of the goal model, this article provides one refined goal for the development and improvement of C2-systems. The decomposition of high-level goals into low-level goals and requirements secures that all aspects of the C2-system are aligned with the overall purpose of the C2-system. By connecting each requirement to a specific section of the concepts model, we ensure a structured approach to develop a conceptual framework for designing C2-systems. The connections demonstrate how each requirement supports the different sections outlined in the concepts model, and this ensures a comprehensive and integrated development approach. However, at this stage only one goal is d ecomposed to low-level goals and requirements. The findings of this decomposition suggests that similar in-depth analysis is required for all remaining goals to secure a holistic approach to C2-system development and understanding. Connecting each requirement to specific components of the concepts model ensures a structured development approach that support tracing the theoretical constructs of the envisioned method to practical applications by identifying which method components can support the needed development and where new components may be required. This approach is suitable when dealing with method complexity and will in the next step be extended by identify method chunks [2], [8]. Method chunks are reusable components of methods that provide guidelines and can be clustered into a situationspecific method that are tailored to address interoperability/integration problems. We have identified components and a method for transitioning from high-level goals to requirements. However, this has not been validated by a relevant evaluation. The coming step in this research project is to engage stakeholders to perform this evaluation. Additionally, we will examine existing frameworks, such as NAF††, to search for components that match our concepts model. †† NATO Architecture Framework