GENERAL ARTICLES

 

System of systems engineering - the link between operational needs and system requirements^#

 

 

C.J. Smith^{I, *} ; R. Oosthuizen^II; H. Harris^III; J.P. Venter^IV; C. Combrink^V; J.H.S. Roodt^VI

^IInteroperability Development Environment Council for Scientific and Industrial Research, South Africa. csmith@csir.co.za
^IIMonzé Consultants, South Africa monze@mweb.co.za
^IIIInteroperability Development Environment Council for Scientific and Industrial Research, South Africa. hharris@csir.co.za
^IVInteroperability Development Environment Council for Scientific and Industrial Research, South Africa. hharris@csir.co.za
^VInteroperability Development Environment Council for Scientific and Industrial Research, South Africa. ccombrin@csir.co.za
^VIStone To Stars Limited, New Zealand stonetostars@gmail.com

 

 

---

ABSTRACT

Recently, defence capability development practices have moved towards approaches that include capability-based planning and traditional systems engineering methodologies. Internationally, defence force capability development efforts struggle to bring together intended capability &planning and actual systems on the ground [15], [18]. Smith & Oosthuizen [1] showed that the Capability Life Cycle and System Life Cycle can be unified through the use of System of Systems Engineering methodologies that include Joint Concept Development and Experimentation, Joint Architecture Management, Joint Knowledge Management, and Joint Operational Force Employment. The challenge is to ensure that the actual systems fielded accurately reflect the intended capability; requirements for traceability between the intended capability and the fielded systems must be preserved in the capability decomposition process. This paper proposes a capability decomposition approach that addresses this challenge.

---

OPSOMMING

Tendense in die ontwikkeling van militêre vermoë wêreldwyd neig na die toepassing van vermoë-gebaseerde beplanning ter ondersteuning van tradisionele stelselingenieurswese metodologieë. Die proses in weermagte wêreldwyd blyk ontoereikend te wees, gegewe die gaping tussen die beplande stelsels en die bewese oplossings [15], [18]. Smith en Oosthuizen [1] het getoon dat die vermoëlewensiklus en stelsellewensiklus saamgebring kan word deur die aanwending van stelsel-van-stelsels ingenieurswese metodologieë, insluitend gesamentlike konsepontwikkeling en eksperimentering, gesamentlike argitektuurbestuur, gesamentlike kennisbestuur, en gesamentlike operasionele magsaanwending. Daarstelling van naspeurbaarheid tussen beplande vermoë en stelselbehoeftestellings in die vermoë dekomposisieproses, is die uitdaging. Die outeurs stel 'n vermoë-dekomposisieproses voor wat hierdie uitdaging aanspreek.

---

 

 

1. INTRODUCTION

Defence forces and associated defence capabilities are risk management instruments of national governments worldwide that ensure national safety, national sovereignty, and territorial integrity. In order to provide transparency of government spending, a rigorous process relating defence capability to national security objectives is imperative.

The process for developing a defence capability must provide clear traceability between strategic defence objectives and defence resources employed to achieve those objectives in conventional warfare or 'operations other than war' (OOTW).

Section 2 of this paper provides the reader with an overview of current defence capability development processes. Section 3 introduces the problem statement. The main concepts of System of Systems Engineering (SoSE) are introduced in section 4, following which section 5 elaborates on current issues, trends, requirements, and possible approaches to new capability development processes. Section 6 provides a novel approach to capability development, drawing on the SoSE approach of section 4 and on proposed ways forward defined in section 5. Section 7 provides a summary diagram of the proposed process, while section 8 alludes to future work required in this area.

 

2. CURRENT DEFENCE CAPABILITY DEVELOPMENT PROCESSES

An outline of a typical defence force capability development process [6] is given in Figure 1.

 

 

The capability development process translates mission-based defence force operational objectives into force structure elements (FSEs), which define the capabilities and systems that a defence force should put in place in order to achieve government's security objectives.

Force structure can be defined as "the entire capability required to prepare, provide and support the operational capability during operations" [11]. It is the responsibility of the chiefs of defence force services and divisions. Derived from this definition, an FSE is defined as a part (or element) of the required capability to prepare, provide, and support an operational capability, and can be assigned to a specific defence force service or division.

Figure 2 summarises a typical defence acquisition process (in the South African context) as described in [17] and prescribed through the DAP1000 [3]. This defines the systems engineering (SE) process followed for systems acquisition in the defence environment. The process begins with a required operational capability (ROC) requirement, provided as an input to the acquisition process managed by the Department of Defence (DOD) Defence Materiel Division (DMD) and its acquisition agency, the Armaments Corporation of South Africa (ARMSCOR).

ROCs are generated by defence force services and divisions, and portray FSE requirements derived in the defence force capability management and capability development environments.

 

3. PROBLEM STATEMENT

Due to changes in the global threat environment, future defence forces require more mission flexibility and adaptability in order to respond quicker and more effectively to threats that are unconventional, asymmetric, and unpredictable.

In order to enable rapid force design adaptations, responsive capability development processes are required to support trade-offs between new capability requirements (ROCs). Present capability development processes provide neither rigour nor transparency in capability decomposition to support quick response.

Alternative FSE options to solve capability requirements should also take into account aspects such as new technologies, modifications to current systems, and leasing of systems. In some cases a disconnect is observed between FSEs and ROCs - as, for example, has been experienced by the Canadian Defence Force [15]. A closer relationship is required between capability planning and the systems acquired to realise such capabilities [1]. So typical defence force capability development processes require re-assessment.

An SoSE approach is taken to propose a unification of capability-based planning and traditional systems engineering. Functional relationships between capabilities and systems are exploited as a means to ensure scientifically-based traceability and transparency in the process of deriving the operational effectiveness of the defence capability that is designed to achieve national security objectives.

A fresh approach to capability development was proposed in [1] to provide unification between capability planning and systems acquired to realise planned capabilities. The approach is depicted- in Figure 3². It is within this context that this paper re-assesses the decomposition of capability requirements, with a view to providing traceability between capability requirements and actual defence force systems functionality.

 

 

4. SYSTEM OF SYSTEMS ENGINEERING

A system of systems (SoS) is defined as "an open set of complementary, interacting systems with properties, capabilities and behaviours of the whole SoS emerging both from the systems and from their interactions" [20].

SoSE is defined as the "cross-system and cross-community process that ensures the development and evolution of mission-oriented capabilities to meet multiple stakeholders' evolving needs across periods of time that exceed the lifetimes of individual systems" [21].

Within the context of unifying capability development and system development, SoSE provides a means to decompose capability-based planning outputs into the inputs required for system development [1].

The delineation between capability engineering, SoSE, and systems engineering (SE) is indicated in Figure 3 by 'hand-shake' interactions. This shows that traditional silo-performed hand-over process interaction is not effective in the system of systems environment due to the complexity and emerging properties of highly integrated systems and joint capability employment.

In the SoSE domain, mission-based assessment of the defence capability effectiveness is conducted (scenario by scenario) through concept development and experimentation. This activity can only be performed through modelling and simulation of the As-Is and To-Be defence capability.

An As-Is representation (referred to as 'baseline') of the defence capability is thus required. The baseline is established through developing and maintaining models of the As-Is defence capability and architecture. Extensive architecture management is required, with reference models and reference implementations of defence infrastructure that allow for modelling and simulation of proposed scenarios.

Gaps identified in the current defence capability are quantified, and prototype solutions to remove such gaps can be defined and evaluated, leading to the establishment of a To-Be baseline.

Current defence capability development processes do not incorporate SoSE. It is suggested that SoSE, with its ability to perform capability trade-off studies in an affordable modelling and simulation environment, can contribute vastly toward optimising defence capability requirements.

Such abilities also allow the planners of operations to test their planned mission designs before deploying them in the field. Combining lessons learnt in the field with lessons learnt in simulation allows further exploitation of the defence capability to quantifiably meet national objectives. For this, operational knowledge management techniques are required.

Based on NATO trends [13], modelling and simulation are key tools for SoSE in support of

• System architectures management;
• Concept development and experimentation;
• Support of acquisition, test, and evaluation;
• Support for training and exercises;
• Support for agile operations and command;
• Support for enabling the human dimension in network-enabled capabilities.

The primary aim of SoS modelling and simulation is to expose the emerging properties of a SoS within the context of a proposed concept of operations (CONoPS). It allows for the early functional representation of critical command, control, communication and intelligence (C3I) processes and resources that form the basis of interoperability. At the same time, it requires the development of models of several physical entities that are needed to achieve the desired behaviour (how they operate) and functionality (what they deliver) [23]. Risks can be identified early, during the development of formal requirements, with the implied reduction in cost later in the life cycle.

The chosen approach to the modelling of complex systems is crucial to the success of the final SoS. Although military and most social systems are essentially hierarchical, it is acknowledged that this hierarchical nature does not imply that simple decomposition is possible. This is a result of what Cilliers calls the nonlinearity of the cross-cutting connections between them [24]. And, finally, it must be acknowledged that truly complex systems are adaptive, and models must make provision for this. The credibility of such models is often questioned. In many instances the models are phenomenological in nature. However, once it can be shown that the conceptual models are valid, it is possible to use modern techniques (such as agent-based modelling combined with event-based approaches) to develop computer models that exhibit a "satisfactory range of accuracy consistent with the intended application of the model" [25].

Done properly, the models are bound by the SoS context or domain of application and the use cases (between the constituent systems and into the enveloping world use space). Such models can be tested in 'fit for purpose' scenarios where the simulators run in real time, or where the models are exercised and their outputs used as inputs to other real world processes or physical equipment.

It is important to note that using modelling and simulation does not negate the need for typical real world experimentation and testing; it forms part of the iterative cycle of development that includes concept development, model building, and testing that ultimately leads to production or procurement [26].

Despite the fact that current defence capability development processes (as shown in Figure 1) are derived from sound logical and researched thought, it is believed that a re-evaluation of current capability development processes is necessary, based on the advantages that SoSE can provide.

 

5. CAPABILITY DEVELOPMENT OBSERVATIONS AND INTERNATIONAL TRENDS

Overarching international trends in defence capability development have seen a focus on support for joint operations. With this in mind, initial efforts focused on jointness at all costs; but it has been found that an approach that reflects a balance between joint and service-specific tasks provide an improved management efficiency and effectiveness of the national defence capability [7]. Other observations include:

5.1 New capability areas

A focus on net-centric or electro-magnetic capabilities has become a part of defence capability lists; and these are managed as such for the US and Australian defence forces, as shown in [7] and [8].

5.2 Use of 'effect'

The US DoD capability relationship model has come under scrutiny, due to its inability to relate defence 'effects' to capabilities. Based on [5], an 'effect', in this context, is the physical or behavioural state of a particular operational environment. Professor Milan Vego of the Us Naval War College has led the charge against the use of 'effects', arguing that such things are too vague to be the basis of military planning, and that 'effects' in the effects-based operations sense are simply unpredictable.

It can be argued that the 'effects' decomposed from operational objectives, as shown in Figure 1, are not effective. When a 'desired effect' is based on an arbitrary selection from a standardised 'effects list' without rigorous analysis and trade-offs, the deduced capabilities can similarly become an arbitrary collection of capabilities.

An improved decomposition logic has been proposed that decomposes operational objectives to purely functional capability definitions. A capability is then defined as being "the ability to achieve a desired effect under specified standards and conditions through a combination of means and ways across the POSTEDFIT³ to perform a set of tasks to execute a specific mission" [16]. Kerr et al. [16] also illustrate how effects and functional attributes are directly relatable.

5.3 A need for CONOPS

The tasks mentioned in the definition of capabilities must also relate to the CONOPS, which includes joint operating concepts, joint enabling concepts, and joint integrating concepts.

CONOPS provide the essential context within which a mission and its associated tasks are performed; and context is important in defining appropriate measures (measures of effectiveness, measures of performance, etc.).

Functional requirements for tasks are derived from the specific mission goals, within the context of the CONOPS. Simply put, the functionality of constituent systems and the subsequent behaviour of the SoS must be consistent with the required outcomes and the doctrine.

5.4 Functional capability area definitions

For sensible relationships that enable the decomposition and translation of military objectives to CONOPS or tasks, it has become imperative to define capabilities in a purely functional, generic, reusable, and stable manner. A model for such a joint capability list was first proposed in 2003 in a US joint defence capability study, also referred to as the Aldridge study.

The study recommended dividing capabilities along functional or operational lines, but favoured functional categories because there were fewer of them. This approach provides capability definitions that:

a) are more enduring;

b) are less likely to change due to new technologies or emerging threats;

c) minimise redundancies in capability decomposition;

d) provide clearer boundaries to assign systems;

e) improve management ability to develop and implement capabilities planning.

Lower tier capability area definitions were added later as a decomposition of these capability areas [5].

These capability definitions have become the lexicon (vocabulary), and are used as a common language for capability development in order to align capability related discussions in the US DoD and to assign responsibilities to organisations for certain tasks that relate to capabilities.

5.5 Move to service-orientated capability-based planning

The use of tasks or FSEs linked to capabilities has been the primary way of assigning responsibilities to defence force services and divisions in the decomposition and acquisition (realisation) of capability requirements. Typically, these responsibilities are rigidly based on specifically-defined missions and scenarios.

As stated before, future defence forces require more mission flexibility and adaptability in order to respond effectively to threats that are unconventional, asymmetric, and unpredictable. An approach being investigated within the SANDF Interoperability Development Environment adopts services-orientated architectures (SOA) domain concepts, defined in [9] as "an architectural paradigm and discipline that may be used to build infrastructures enabling those with needs (consumers) and those with capabilities (providers) to interact via services across disparate domains of technology and ownership".

Adoption of SOA concepts in the capability-based planning environment is proposed in order to improve definitions of the capability responsibilities of defence force services and divisions. In this context, services and divisions will be responsible for providing certain services to support joint operations. The SOA concept implies the establishment of detailed standards in order to provide guidance about how service providers integrate, interoperate, and collaborate with one another. This is critical in order to ensure that systems developed for the services and divisions are able to support integrated joint operations within a common, defined joint CONOPS.

When the 'functional' services that can be rendered are known to force employment authorities, the impact of not having a specific service available can be managed through alternative service providers. The impact of the availability of services can also be related to impacts on national security objectives through the use of a capability lexicon.

If new scenarios or CONOPS are considered, existing 'functional' services can be related to these operational problems to define possible system solutions. Through this process, capability gaps can be identified and translated into requirements to adapt current service needs, allowing service providers to adapt their systems through modification, acquisition of new systems, or other alternatives.

5.6 Architecture management

Numerous approaches to defence architecture management have been adopted internationally to support capability development. Some of these frameworks include the US Department of Defence Architecture Framework (DoDAF), the UK Ministry of Defence Architecture Framework (MODAF), and their unification with the NATO Architecture Framework (NAV) in the Unified Profile for DoDAF and MODAF (UPDM) architecture framework. These frameworks have, however, come under severe scrutiny concerning their value within capability development. General consensus shows that the key to effective architecture management is an appropriate taxonomy within the development of architecture products, and strict enforcement of adherence to it. This taxonomy aims to ensure a common lexicon that explicitly describes concepts, capabilities, and systems, while reducing ambiguity and interpretation issues.

Numerous difficulties have been experienced when different organisations implement different taxonomies, making it impossible to compare capability options and solutions.

For this reason, the importance of a common capability lexicon is again highlighted in an attempt to provide commonality between architecture products, thus allowing the comparison of capability options and solutions.

 

6. PROPOSED CAPABILITY DEVELOPMENT DECOMPOSITION

With the above in mind, the following decomposition for capability development is proposed, along with comparisons with current methods.

6.1 Stepl: From national security objectives to military strategic objectives

In South Africa, government's national security objectives are summarised in national and international objectives derived from [2]. These objectives translate into three main military strategic objectives for the SANDF, highlighted in the SANDF military strategy [2] and DoD overarching strategic statement [14]:

6.1.1 Defence against aggression

The provision of self-defence against any external aggression that endangers the stability of South Africa, in accordance with international law.

6.1.2 Promoting security

'Promoting security' means providing external deployment or support to enhance security in support of decisions by the executive that include international, regional and sub-regional security obligations, search and rescue, disaster relief, and maritime support.

6.1.3 Supporting the people of South Africa

Supporting the population of South Africa through operations other than war, when the responsible state departments do not have the capacity to do so.

This decomposition is derived and agreed at government level, based on current national security risks. Security objectives are long-term, but they can adapt over time. The present objectives have endured for almost 10 years: they were first published in the South African DoD strategic business plan of 2003 [19].

6.2 Step 2: From military strategic objectives to missions

A typical approach to translating military strategic objectives to missions follows a process of deriving required strategic capabilities (means) from the military strategic objectives (ends), using mission-based concepts (ways) [2], [11].

This is an accepted method, and should directly relate to required capabilities. As shown in Figure 1, missions can be decomposed into specific 'objects', which in turn create requirements for specific 'effects'.

As mentioned in paragraph 5.2, the use of 'effects' creates a difficult relationship for decomposition to link missions and capabilities. Based on lessons learnt in the US DoD [5], it makes sense to decompose missions directly to capabilities. These capability definitions must, however, be purely functional in nature in order to ensure that the decomposition retains scientific logic.

If capability definitions are purely functional, the relation to 'effects' is implicitly captured. In this context, capability is defined as "the ability to achieve a desired effect under specified standards and conditions through a combination of means and ways across the POSTEDFIT⁸ to perform a set of tasks to execute a specific course of action", as suggested in paragraph 5.2.

The link between missions and capabilities thus provides the 'ways' and 'means' to achieve the desired 'end'. These missions should be endorsed as the overarching military missions by joint force employment authorities.

6.3 Step 3: Missions to joint capability areas

As alluded to in paragraph 5.4, the US Joint Capability Area (JCA) lexicon was created as a common vocabulary for capability development, to align capability-related discussions and to assign responsibilities to organisations for certain tasks that relate to capabilities. A high level overview of the JCA lexicon up to third tier decomposition, as refined in 2θ1θ, appears in : Table 1 of the Appendix [7].

The JCA lexicon is purely functional in nature, and covers all required defence capabilities for force employment and force preparation. JCAs include non-operational capabilities such as acquisition, research and development, human resource management, defence partnerships, and corporate management capabilities. It should also be noted that the JCAs include a net-centric capability, as mentioned in paragraph 5.1. This list is also able to accommodate tactical, operational, and strategic scenarios, and to provide sufficient direction to specify first-order user system (POSTEDFIT⁸, TEPID-OIL, DOTMLPF or PRICIE) specifications.

When examining the missions (ways) required to support military strategy objectives (ends), it is observed that the JCA lexicon (means) becomes a functional capability list to pick from at the lower tiers, in order to relate the required functions needed to perform a mission.

It is in this environment that SoSE can contribute in the establishment of optimal linkages between the mission requirements and the functional capabilities that would be most effective in performing missions. Such analyses should be scenario-based and include the development of accompanying CONOPS.

Based on the US DoD [12], missions can be decomposed into tasks (joint or service-specific) through context provided in the form of a CONOPS. This context allows defence force services and divisions to understand the context within which they have to operate jointly when they develop system requirements (described in step 5). It is thus required to develop CONOPS in conjunction with the development of probable missions. The CONOPS should address all levels of operations (strategic, operational, and tactical) and clearly differentiate the functions that are needed at each level of operation. For the purposes of this paper, missions are decomposed into service oriented tasks through the JCA lexicon, as will be explained in Step 4.

When a specific functional requirement is identified for the execution of a mission, and this function is not addressed in the JCA lexicon, a functional capability gap is identified. Such functional requirements should be made transparent by adding them to the JCA lexicon.

When missions (evaluated on a scenario basis) can be logically related to functional capabilities, the maintaining of a As-Is baseline of defence capability architecture becomes achievable. This in turn allows development of reference models and implementations to relate 'functional' services, as will be discussed in Step 4.

When comparing the JCA lexicon to capability lists of most traditional defence forces, a number of observations can be made. Traditional lists typically contain a mixture of functional and operational capabilities, which are grouped in relation to common domains. The logical relationships between capabilities and missions are very difficult to identify, and can become overly subjective. This can be attributed to the mixture of functional and operational capabilities, and to a lack of capability decomposition into deeper tiers of capability. Creating sensible architecture products for such capability lists becomes impossible if a single taxonomy is not followed by all architecture stakeholders throughout the DoD.

6.4 Step 4: Joint capability areas (JCAs) to service orientated tasks

It is interesting to note that different and often opposite approaches to capability decomposition are followed internationally. It is evident from Figure 1 that traditional practices are to develop tasks and decompose these into capabilities. In [4], however, objectives are decomposed to effects, effects to capabilities, and capabilities to tasks.

The sequence of derivation, however, becomes flexible when a functional common denominator is used to create the links between missions and tasks. Without such a functional common ground, it is not possible to translate operational needs into system requirements. A purely functional common ground is essential to allow logical decomposition. This is why the functional JCA lexicon was chosen to allow appropriate decomposition into first-order system requirements, namely services oriented tasks (SOT). This paper thus proposes to decompose from capabilities to SOT.

SOT implies the use of an SOA approach, as defined in paragraph 5.5, to define the service tasks that can be allocated to service providers. It is implied that the functional capabilities of the JCAs be decomposed to SOT that are assigned to defence force services and divisions. Service providers are thus made responsible for providing services to other participants in operations within the context of a defined joint CONOPS.

Defence force services and divisions are responsible for developing 'functional' services allocated to them by defining the requirements for their systems, platforms, or command and control applications within the required capability framework (e.g. POSTEDFIT⁸, TEPID-OIL, DOTMLPF, PRICIE, etc.) to provide these services in standardised ways that allow for interoperability and alignment with JCAs.

This approach requires architecture management, as part of SoSE, to link services provided by service providers to the functions defined in the JCAs and linked to the achievement of specific missions. This requires service models of defence force systems in the form of a joint As-Is baseline, which can be maintained through architecture products (reference views), reference models and reference implementations of current defence force systems.

In SoSE, a key success factor is the ability to ensure the integration and interoperability of defence systems by defining clear standards of how systems interoperate in the context of a joint operational mission, based on common and sufficiently diverse scenarios and integrated CONOPS.

The availability of an As-Is baseline provides the way clearly to identify capability gaps where 'functional' services are not available to support a specific JCA capability. Proposed solutions can be modelled and simulated, or prototyped and inserted into As-Is baselines, to create possible ToBe baselines. The defined capability gap solution can then be addressed by acquiring new systems, adapting current systems, leasing options, or any other suitable alternatives.

6.5 Step 5: Service oriented tasks to system requirements

With the SOT approach, system requirements become the responsibility of an organisation. In this case, the responsible organisation could be any of the defence force services or divisions. The organisation is responsible for decomposing the SOT into a POSTEDFIT that can provide the required 'functional' service. In order to align these developments, a joint CONOPS is required to provide guidance and context for the service provider to develop the correct SOT with doctrine to support joint operations. This new approach will force system owners to keep in mind that the system is only as important as the services it can provide to stakeholders.

Interoperability standards derived from architecture management guide the service provider in ensuring interoperability with other service providers. Depending on the nature of the SOT, CONOPS can include joint operating concepts, joint enabling concepts, and joint integrating concepts.

System requirements should relate to 'functional' services that the system should provide, as well as to the 'functional' services that the system requires from other SOTs to fulfil its role in the context of a Joint CONOPS. This implies that each system has server and client requirements that relate directly to the JCA lexicon. When there is a denial of some services, the impact on other systems and on the overall capability becomes traceable.

This approach furthermore supports modelling of SoS behaviour through understanding the sensory services, effecting services and command and control services associated with a system, and how it supports other systems within the context of a proposed CONOPS.

Duvenhage & Le Roux [22] showed that a distributed parallel and soft real-time simulation architecture - one that employs a publish-subscribe framework, and is layered on a peer-to-peer transport control protocol (TCP)-based message-passing architecture - can successfully be applied in SoS virtual simulation. With this architecture, a fully-populated scenario (translating to 177 entities requiring processing in that specific case) could execute in soft real-time.

In the South African context, the initial system requirements of the SANDF are captured in ROCs that trigger the DAP1000-based acquisition process. Decomposition of the ROC, which includes all components of a POSTEDFIT, is performed by the DoD DMD in conjunction with SANDF services and divisions and ARMSCOR. The recommendations in this paper do not impact on this process.

 

7. SUMMARY

This paper proposes an approach to capability decomposition that incorporates SoSE and interoperability approaches in the capability development process, as illustrated in Figure 4. This approach aims to decompose defence operational requirements to defence system requirements in a traceable way, using a common functional capability lexicon.

 

 

8. FUTURE WORK, AND EVALUATION OF THE PROPOSED PROCESS

This paper proposes a defence capability development process based on new approaches and international best practice that include SoSE, network enabling concepts, and interoperability concepts for optimised joint defence capabilities. It also proposes an enhanced capability development process that rigorously and traceably decomposes national defence objectives to system requirements.

The proposed process must be verified and validated, which is not a trivial matter. In order to evaluate the proposed process, a SoSE capability is required with concept development and experimentation, architecture management, and knowledge management abilities, as described in [1]. In addition, the necessary modelling and simulation capabilities alluded to in paragraph 4 and in [13] are required.

The SANDF's Interoperability Development Environment, hosted at the Council for Scientific and Industrial Research (CSIR), is embarking on developing some of these abilities in conjunction with the SANDF.

For further work, it is thus proposed to evaluate the process outlined in this paper in conjunction with currently-employed capability development processes, and to perform a trade-off study to quantify scientifically the advantages and disadvantages.

 

REFERENCES

[1] Smith, C.J. & Oosthuizen, R. 2011. Applying systems engineering principles towards developing defence capabilities, International Conference on Industrial Engineering, Systems Engineering and Engineering Management for Sustainable Global Development. 103, pp 1-13.         [ Links ]

[2] Janssen, B.R. 2003. South African National Defence Force military strategy. Department of Defence Joint General Publication JGP 201. DS/CCS/D STRAT/R/302/2/1.         [ Links ]

[3] Verster, S.J. & Griesel, D. 2004. Process and procedure for the acquisition of armaments - DAP1000. Department of Defence Joint Defence Publication. DS/ACQ/R/302/6/P.         [ Links ]

[4] Joint Capability Area Management Plan. 2010. US DoD, Deputy Secretary of Defense.         [ Links ]

[5] Capability Based Assessment User Guide. 2009. US DoD Force Structure, Resources and Assessments Directorate. Version 3.         [ Links ]

[6] Oosthuizen, R. 2011. Shaping joint air defence for future missions - Back to basics, South African Joint Air Defence Symposium.         [ Links ]

[7] US Defence Joint Capability Area Management System. 2010. JCAMSv 1.1.0. http://jcams.penbaymedia.com/jcas.cfm.         [ Links ]

[8] Westwood, C. 2011. Joint capability coordination and capability development. Military Communications and Information Systems Conference. Australian Defence Force.         [ Links ]

[9] Nickull, D., Reitman, L., Ward J. & Wilber, J. 2007. Service oriented architecture (SOA) and specialized messaging patterns. Technical White Paper.         [ Links ]

[10] SANDF. 2011. South African National Defence Force Capability Master List. Issue 4.1.         [ Links ]

[11] Oosthuizen, R. & Roodt, J.H.S. 2009. Capability development - Processes, methodologies and analytical tools. Council for Scientific and Industrial Research.         [ Links ]

[12] Universal Joint Task Manual. 2011. Chairman of the Joint Chiefs of Staff Manual. CJCSM 3500.04F. United States Defense Force.         [ Links ]

[13] NATO Research and Technology Organisation. 2010. Guide to modelling & simulation for NATO network-enabled capability.         [ Links ]

[14] SANDF. 2011. DoD overarching strategic statement for the fiscal years 2011/12-2015/16. http://www.dod.mil.za/documents/SecDef%20%20Strat%20Plans%202011/Overarching%20Document %20e.pdf        [ Links ]

[15] Lizotte, M., Bernier, F., Mokhtari, M., Couture, M., Dussault, G., Lalancette, C., Lemieux, F. & Lam, S. 2004. Towards a capability engineering process. Defence R&D Canada.         [ Links ]

[16] Kerr, C., Phaal, R. & Probert, D. 2006. A framework for strategic military capabilities in defence transformation, 11th ICCRTS Track 9: Network Centric Metrics. http://www.dodccrp.org/events/11th_ICCRTS/iccrts_main.html.         [ Links ]

[17] Schür, O.A. 2007. Presentation on Department of Defence acquisition process. Revised acquisition priorities and strategic industry requirements. South African Aerospace, Maritime and Defence Industries Association. http://www.amd.org.za/docs/Acquisition_Process_-_30_Aug_07.pdf.         [ Links ]

[18] Neaga, E.I., Henshaw, M. & Yue, Y. 2009. The influence of the concept of capability-based management on the development of the systems engineering discipline. 7th Annual Conference on Systems Engineering Research 2009.         [ Links ]

[19] SANDF. 2003. South African Department of Defence Strategic Business Plan. http://www.dod.mil.za/documents/strategicbusinessplan/DODStratPlan03to06.pdf         [ Links ]

[20] Hitchins, D.K. 2007. What's in a System-of-Systems? http://www.hitchins.net/SystemofSystem.pdf         [ Links ]

[21] Kaplan, J.M. 2006. A new conceptual framework for net-centric, enterprise-wide, system-of-systems engineering. National Defense University Center for Technology and National Security Policy. http://www.ndu.edu/CTNSP/docUploaded/DTP%2030%20A%20New%20Conceptual%20Framework.pdf        [ Links ]

[22] Duvenhage, B. & Le Roux, W.H. 2007. A peer-to-peer simulation architecture. Council for Scientific and Industrial Research. High Performance Computing & Simulation (HPCS'07) Conference, Prague, Czech Republic.         [ Links ]

[23] Brooker, S. 2002. The role of early C4I Modelling in SBA. Smi's Third Annual Simulation Based Acquisition Conference.         [ Links ]

[24] Cilliers, P. 2002. Boundaries, hierarchies and networks in complex systems, International Journal of Innovation Management.         [ Links ]

[25] Society for Computer Simulation Technical Committee on Model Credibility. 1979. Terminology of model credibility, Report of SCS Technical Committee, Simulation.         [ Links ]

[26] Grover, H. 2002. Applying simulation to acquisition, Smi's third annual simulation-based acquisition conference.         [ Links ]

 

 

* Corresponding author.
# This article is an extended version of a paper presented at the 2011 ISEM conference.
2 The SANDF systems hierarchy has eight levels. SoSE focuses on the transitions between L8, L7, and L6 requirements [17], [3].
3 POSTEDFIT refers to the components of a user system, which include personnel, organisation, sustainment, training, equipment, doctrine, facilities, information, and technology in the South African context [17]. Similar constructs are used by other nations: for example, TEPID-OIL (UK MoD lines of development) [15], DOTMLPF (US DoD) [4], [16], and PRICIE (Canadian Department of National Defence) [16].