ABSTRACT

Operational planners and engineers are always on the watch to leverage more advanced Evolutionary Development of technologies as a force multiplier. However, inserting a new technology into an existing System of Systems through System-of-Systems (SoS) architecture is complex due to the interrelationships between operational Systems Architecting and system entities. This article presents systems architecting as an effective means to coherently manage the evolutionary development of SoS arising from technology insertion, and identifies four key aspects of actionable systems architecture outcomes to guide engineering masterplanning and programme implementation.

Pang Chung Khiang Sim Kok Wah Alvin Koh Hian Siang 92

Evolutionary Development of System of Systems through Systems Architecting DSTA HORIZONS DSTA

INTRODUCTION GUIDING TECHNOLOGY As illustrated in Figure 1, the first key the existing manned platform for wide area INSERTION IN SOS activity in the SA approach is to evaluate surveillance in Maritime Security2. In this System of Systems (SoS) can be described the benefits of the new technology and its case, a newly evolved systems architecture potential to expand existing SoS mission as a collection of constituent systems An SoS is too complex to be managed solely has to be defined. objectives. The intent is to determine if which are operationally independent. through quantitative engineering analysis. there will be fundamental shifts in operating Managed independently and distributed Hence, the systems architecting (SA) In the second scenario, the new technology principles and assumptions, arising from geographically, these systems work approach is employed to visualise, has less impact on the existing SoS, hence assimilating the new technology into the collectively to perform unique function(s) conceptualise, plan, create, communicate causing the SoS to evolve to a limited defence capability. There are two possible which cannot be carried out by any and build an SoS (Tan et al., 2006). The extent. An example of the scenario is the architecting scenarios. individual constituent system. Voluntary process of systems architecture evolution replacement of a key constituent system and collaborative interactions among the opens up new possibilities for the existing in the SoS, such as changing an obsolete constituent systems often result in new In the first scenario, significant benefits can SoS. It challenges trade-off considerations platform to a more advanced version. This emergent properties or functions that be derived from the new technology. Thus, by stakeholders and subject matter experts. replacement is likely to result in minimal can serve the primary purpose of the SoS the operations planner has to formulate Consequently, the process creates the change to the ConOps. Since the existing (Maier, 1998). new operating principles and concepts, architectural clarity needed to manage SoS is likely to remain operational with the and involve the systems architect in the complexities objectively. introduction of the new system, the SA SoS evolutionary development can be early stages of identifying SoS performance focus will be on exploring other operational driven by the changing environment, requirements. An example of the scenario A well-designed systems architecture has possibilities presented by the new system technological advancement, or evolving is the use of multiple Unmanned Aerial attributes such as flexibility, adaptability needs of stakeholders. Introducing new and evolving the SoS. Vehicles (UAVs) to complement or replace and evolvability. These attributes create an technologies can lead to changes to the underlying operational strategy or enduring architecture that is forward looking, Concept of Operations (ConOps). Thus, as new systems, technologies or ConOps may Example of disturbance be inserted for the SoS to evolve and adapt to Introduction of new technology existing constituent systems may require (e.g. Multiple UAVs) modifications to derive a different and more the changing environment, latest technology needs or stakeholder requirements. The effective operational capability. Review existing broad level relationships in SoS architecture documentation provides design SoS As Is Ops only Ops - Systems Systems only Managing these changes to the SoS to clarity, records the rationale behind each achieve a new optimal design is not a design consideration and serves as a body of trivial task. As the SoS constituent systems knowledge to manage the evolution of SoS

Reconfigure Insert new technology and Architec Define new organisational are characterised to have managerial and its performance over time. existing modify constituent structure and processes independence (Maier, 1998), there are relationships systems if necessary

different authorities managing the raising, Revised SoS ti ng Sc IMPACT OF TECHNOLOGY for best Only ops Only system- 1 employment operator training and sustenance of INSERTION related changes related changes of new en ario 1 technology respective constituent systems. Since each Changes to overall Changes to overall constituent system is already meeting current A systems architect has to understand the operational framework technical framework (Operational Architecture) (Systems Architecture) needs, it may lack an impetus to assimilate nature of the disturbance caused by the governing SoS evolution governing SoS evolution with the new technology introduced to new technology and how this will affect Architecting Scenario 2 the existing SoS environment to form new the SoS. This knowledge ensures that a capabilities. This adds to the complexity systems architecture study would produce and difficulty of realising and managing an Figure 1. Understanding SA scope and outcome a meaningful outcome to guide the review SoS evolution (US Department of Defense, and update of the engineering master plan. 93 2008). DSTA HORIZONS DSTA 94

Evolutionary Development of System of Systems through Systems Architecting DSTA HORIZONS DSTA

SYSTEMS ARCHITECTING Step Three: Evaluate SoS more. The spiral approach of the SA process Next, guided by desired SoS capability APPROACH FOR Alternatives is illustrated in Figure 3. objectives and the current operating concept, the systems architect works with TECHNOLOGY INSERTION Each option is evaluated thoroughly on its the operations planner to review the higher operational effectiveness, using relevant 3 2 intent of operational needs as well as the Figure 2 shows the DSTA SA process (DSTA Evolve SoS 4 Operational Analysis (OA) techniques as well T e c h Insertion (2) 1 6 challenges, assumptions and limitations SA Primer, 2010). While the SA process as Modelling and Simulation tools. Where 5 of current operations. Subsequently, they guides the development of a new systems 3 possible, the cost of each alternative is also 2 seek innovative ways to best employ the architecture, the same process can also be Evolve SoS 4 assessed. The final technology employment T e c h Insertion (1) 1 6 new technology. For example, a group of applied to evolve existing SoS architecture 5 option(s) or ConOps will then be selected. Periods Time self-synchronising tactical UAVs can due to the insertion of new technologies. Environment 3 2 Develop SoS 4 potentially replace the manned Maritime Step Four: Finalise SoS SoS Mission Objectives 1 6 Patrol Aircraft (MPA) (see Figure 5) for Architectures 5 selected wide area detection and Figure 3. Spiral approach of the SA process Based on the final option selected, the identification of vessels of interest. current SoS architecture design is reviewed to identify the modifications required for the EXAMPLE: MARITIME assimilation of the new technology. The broad SECURITY timeline for implementing these systems upgrades is assessed vis-a-vis the timeline for The application of the SA process for developing the new technology. If necessary, technology insertion is best illustrated interim architectures are established to using an example. In this scenario, consider address any capability shortfall. maritime airborne surveillance which forms Figure 2. Six-step SA process part of the SoS capabilities for maritime A preliminary assessment is conducted on security. the solutions needed for the constituent Figure 5. An example of MPA: C295MPA An overview of the first four steps in the SA (Source: Airbus Military) systems to operate collaboratively. This With the advent of multiple process is as follows: assessment will indicate if the finalised SoS self-synchronising tactical UAVs for The architecture options should not be Step One: Frame the Issue architecture is realisable within the estimated maritime surveillance (see Figure 4), the limited to developing a systems configuration budget. There is a possibility that some of systems architect has to first understand mix (e.g. number of UAVs versus manned Consider a scenario where a new technology the requirements identified in this step3 the value propositions and opportunities patrol aircraft), alternative uses of the is inserted into an operationally stable SoS and cannot be met coherently. In this case, it is created by the new technology. technology in other mission scenarios it is determined that the systems architecture necessary to revert to one of the previous should be explored. For example, instead would evolve to a limited extent. Instead of steps for a second iteration. of employing tactical UAVs for wide area adopting a build-from-scratch approach, it is detection only, it is possible that a few more effective to assess the impact of the The iterative SA process refines the UAVs can break off from the fleet to track technology insertion and explore how best architecture over time, with the increasing a hijacked vessel in counter-piracy operations. to assimilate it into the existing SoS. knowledge of architectural issues and After the ad hoc mission, the UAVs return to interrelationships among constituent the fleet autonomously. Step Two: Develop SoS systems. Once the systems architecture is Alternatives finalised and more accurate cost estimates It is possible to identify more than one are available, development and certification alternative use of the technology. These Innovative ways are sought to employ the 95 new technology. This may require different tasks will be carried out until the SoS Figure 4. An example of tactical UAV: ScanEagle alternatives may be evaluated quickly UAV (Source: The Boeing Company) modifications of the existing architecture. achieves its steady operational state once using heuristics, or may require a deeper DSTA HORIZONS DSTA 96

Evolutionary Development of System of Systems through Systems Architecting DSTA HORIZONS DSTA

assessment using OA techniques. Ideas, current SoS architecture design is reviewed Pre-determined Historical trends Plans Port documents rationales, trade-off considerations and to identify new operational and system Shipping manifest Interim value propositions for the ConOps should linkages required for optimal assimilation Conduct Anormaly assessment general detection be documented where applicable for future of the new technology, thereby ensuring surveillance

references, regardless of the outcome of the end-to-end effectiveness of the SoS. For Standard Operating Procedure evaluation. example, by analysing the activities carried MPA crew Orientate to Orders for and investigate action out by the UAV crew in an Operational anormaly Watch cell Video footage The outcome of the SA process can be Activity Model (see Figure 7), new Take Partner feedback appropriate Report depicted by a High Level Operational applications and system linkages are needed action UAV crew After-action AAR report Concept Graphic, commonly known as to enable collaboration between the crew review (AAR) Quick Analyst Operations View 1 or OV-1. OV-1 provides and other teams. This Operational Activity Response team a high-level illustration of the operating Model is commonly known as Operations Analyst concept of various key systems and agencies, View 5 or OV-5. UAV crew as well as their interactions with the SoS Watch cell UAV crew interacting with: environment. An example of OV-1 is shown Based on the analysis, a logical map of Quick (1) MPA crew (location of anomaly) Response in Figure 6. information exchange requirements among (2) Watch cell (orders) team the operational nodes (including the new (3) Analyst (surveillance coordination) UAV crew The next step in the SA process is to technology) is developed and the terms of (4) Quick response team (surveillance coordination) Figure 7 develop alternative architectures to enable reference are refined. This step allows the Figure 7. OV-5 example for maritime security the different ConOps identified in the systems architect to establish and identify earlier stage. Each alternative architecture touch-points with the new technology is evaluated on its ability to meet the SoS and any new organisational structure that the ConOps. The logical map is usually systems and the interactions among capability objectives. During this stage, the may not have surfaced when formulating documented in the Operational Node them. This analysis helps to determine the Connectivity Description diagram, commonly interoperability (Sim, Foo and Chia, 2008) known as Operations View 2 or OV-2. An requirements of the new technology. A map International Outer Maritime Sea ports example of OV-2 is shown in Figure 8. of the identified systems and connectivity Wide area sensor Surveillance Ring can be captured in a Systems Interaction/ Multiple Inner Maritime OV2 – Information Flow for Wide Area Surveillance tactical UAVs Surveillance Ring Using OV-2 as a guide, the systems architect Interface Description diagram, commonly can conduct an analysis to identify related known as Systems View 1 or SV-1. Narrow Field-of-View Navy sensor Enabling wide area Multiple surveillance using Task Collection multiple tactical Processing, Exploitation tactical UAVs Ad hoc tasking and Dissemination (info only) UAVs Maritime Security Enforcement Node

Surveillance Ad hoc Manned Maritime Air Information Maritime Security Surveillance Node Command Node tasking

Harbour Surveillance In-fight Requirements coordination/ Surveillance control Surveillance Surveillance Information Unmanned Maritime Information Surveillance Air Surveillance Node Maritime Security Command Node Command Node Navy Ground based (UAV Swarm) Ad hoc tasking Mission Internet coastal sensor (for info) status In-fight Tasking request coordination Coast Guard Tasking /control order Air Ops Control MPA Node - Manned Information Coast Guard Air Ops Cmd Node Air Ops Control Sharing Node - Unmanned HQ Maritime Security Tasking among Maritime HQ order Security Partners Ad hoc Command and Control 97 Tasking Operations Support Figure 6. OV-1 example for maritime security Figure 8. OV-2 example for maritime security

8 DSTA HORIZONS DSTA 98

Evolutionary Development of System of Systems through Systems Architecting DSTA HORIZONS DSTA

The rationale behind the selection of requirements effectively. OA can be OA studies may generate new insights (e.g. However, the provision of options comes at a identified systems and the corresponding leveraged to determine the optimal mix sensitivity of mission success with aircraft cost and the systems architect needs to work interaction needs are documented separately and configuration of systems to meet and sensor performance specifications) with operational planners and obtain the for future reference. Based on SV-1, the requirements. In the example of maritime and disprove earlier assumptions. Such necessary approvals. systems architect can derive other high-level security, some key requirements are information can be circulated to the earlier requirements such as information assurance minimal revisit rate and high operational SA stages to adjust the operating concept It is also important for the systems architect requirements. An example of SV-1 is shown availability for the surveillance of an for better employment of the new to engage operational stakeholders while in Figure 9. expected area of operation. In this case, technology. An example of an OA outcome developing operating concepts, so as to OA may study the deployment concept to is shown in Figure 11. This methodology is establish credibility, gather consensus and The new ConOps may require a specific determine the number of UAVs needed to also used for evaluating alternatives. build ownership. While it is necessary to document architectural details for analysis number and mix of systems, including the meet revisit and availability requirements Once the revised SoS architecture is and evaluation, the systems architect can new technology, to meet key operational (see Figure 10). SV1 – Systems Interaction Diagram finalised, the next step in the SA process also generate simplified diagrams of the is to identify possible solutions that enable Operations View and Systems View to allow Sensor C2/Planning Info Users the interactions required to fully assimilate decision makers to understand the SoS Surface Track Ad hoc Chat and Email tasking the new technologies. After the architecture architecture design easily. Surveillance aircraft Planning & Flight and Flying Sqn Control Centre Tasking Collection Tasking Request is verified to be fit and coherent over Plan Flight order Mission C2 System planning C2 system Maritime Security CP system system several iterations, the actual solution and ACTIONABLE SYSTEMS Sortie Plan (detailed) Surface track Flight monitoring In-flight status coordination system decisions are determined during programme ARCHITECTURE OUTCOME /control Maritime Surveillance Ops Maritime C2 implementation. security C2 system system

Ad hoc Surveillance To manage the complexity of SoS UAV GCS tasking Request UAV GCS Flight and (for info) UAV GCS UAV Collection UAV Plan Through the SA process, the systems evolutionary development, a systems system Surface Track Fused Sensor picture architect should remember to design an architecture must serve as a meaningful Sensor data

Sensor Patrol Boat architecture that allows attributes such as guide for subsequent analysis, Fusion Electro Optics system imagery Mission system flexibility, adaptability and evolvability. He or implementation and validation. Hence, the she should anticipate and make provisions to systems architecture requires a consistent Figure 9. SV-1 example for maritime security insert other technologies or systems, thereby and rigorous architecture framework to 2 creating operational options for the future. guide its documentation.

Area CoverageArea Coverage Proportion Proportion

Smaller Larger Platform A Platform B Platform C Proportion Proportion

Measure of Effectiveness

Number of Platforms 99

Figure 10. UAV deployment example for maritime security 3= Figure 11. An example of OA outcome

Figure 11 DSTA HORIZONS DSTA 100

Evolutionary Development of System of Systems through Systems Architecting DSTA HORIZONS DSTA

Existing architecture frameworks, such as desired ConOps, corresponding value design helps to rationalise the impact of an CONCLUSION the US Department of Defense Architecture propositions and critical requirements impending change in the SoS. Information Framework and the UK Ministry of Defence are documented using various types of and considerations on the design, such Evolutionary development is a key Architecture Framework, are gaining illustration (OV-1, OV-2, etc.) and written as design principles, system interactions, characteristic of the SoS and can be popularity in the defence community text. system performances and configurations, triggered by the changing environment, partly due to their introduction of formally are documented to support the analysis technological advancement and evolving defined architectural views and models. Inserting a new technology to meet the SoS as well as the test and evaluation of the needs of the stakeholders. SA is an effective Nonetheless, there are architectural capability objectives may create potential architecture. This ensures that the SoS means to realise and manage the SoS decisions, innovations, engineering operational opportunities in other SoS(s). is verified and validated for its intended evolutionary development arising from trade-offs, assumptions and rationales The assessment of these opportunities capability, and that it has been implemented technology insertion. The DSTA SA process that are not easily captured using should be recorded in the architecture and correctly as well. can be applied to enable innovative ways graphical models. A comprehensive reviewed as part of another SoS construct. of employing the new technology. For the description of an SoS architecture should Hence, the assessment helps to ascertain SoS Demand for SoS architecture to serve as a meaningful include four core aspects as shown in if system provisions should be made for Infrastructure Resources guide to engineering masterplanning Figure 12. interoperability and realisation of the and programme implementation, the SA potential opportunities. Requirements, such as the communication outcome should cover the four key aspects SoS Operations and infrastructure, need to be surfaced early of an SoS Architecture outlined in this article. Capability Overview SoS Design to the relevant governing bodies to strike a balance among competing demands. REFERENCES The overview reveals the high-level The design forms the core of the Otherwise, the identified systems which operational context of the SoS so that architecture. It covers various aspects require these resources may not be usable, Defence Science and Technology Agency. the operations manager and systems to explain how constituent systems are thus affecting the SoS capability performance 2010. DSTA Systems Architecting Primer architect can have a broad and common identified and designed to fit into and be significantly. – Version 1. understanding of the SoS capability. The coherent with the SoS layout. Thus, the

SoS Time Frame, Challenges Maier, M.W. 1998. Architecting Principles for and Limitations Capability Desired operating concept and Critical Systems-of-Systems. Systems Engineering SoS Operations and Objectives value proposition Operational Requirements 1(4): 267-284. Capability Overview Description and value proposition of other operational opportunities due to This aspect provides the SoS programme technology insertion manager with an overview of the transition Sim, K.W., Foo, K.J. and Chia K.B 2008. requirements, challenges and limitations Key SoS Critical systems Key system function and Realising System of Systems Interoperability. design principles performances data flow descriptions of evolving constituent systems. Thus, an DSTA Horizons. Defence Science and List of identified existing and/or implementation timeline can be established SoS Design Systems configuration Technology Agency. New candidate systems (include R&T) mix, quantity and allocation for the newly evolved SoS Architecture. The System deployment Systems interaction intent is to communicate this information concept layout Tan, Y.H., Yeoh, L.W., Pang, C.K. and Sim, to various constituent system owners to K.H. 2006. Systems Architecting for 3G SAF SoS Demand for Demand for scarce resources ensure that stakeholders are fully apprised Communications spectrum demands Transformation. DSTA Horizons. Defence Infrastructure Resources (land, air space, maritime, budget) of the challenges and new limitations. This Science and Technology Agency. aspect should also document the lessons Demand for scarce resources Communications spectrum demands learnt so that important insights are passed SoS Operations and (land, air space, maritime, budget) US Department of Defense. 2008. Systems Capability Overview Demand for scarce resources on for future evolution. Communications spectrum demands Engineering Guide for Systems of Systems. (land, air space, maritime, budget) 101 Figure 12. Key aspects of an actionable SoS architecture DSTA HORIZONS DSTA 102

Evolutionary Development of System of Systems through Systems Architecting DSTA HORIZONS DSTA

ENDNOTES Sim Kok Wah is Assistant Director (DMSA). He leads a team in 1 The phrase “Raising, Training and collaborating with the Singapore Armed Forces (SAF) to plan for future Sustenance” refers to the conceptualisation capabilities. He also oversees the movement to drive productivity and and acquisition of a system, the training of innovation in DMSA and heads a task force to review business processes operators for the system, and finally the for enterprise IT systems. He was previously the Principal Systems Architect sustenance support provided for the system for the domain of Intelligence, Surveillance and Reconnaissance. He to continue functioning according to its was also Chief Executive Officer of Cap Vista Private Limited, which is intended capability. the strategic venture investment arm of DSTA. Under the Public Service Commission – Japanese Monbusho Scholarship, Kok Wah graduated 2 The example is cited for the purpose of with a Bachelor of Engineering (Electrical Engineering) degree from illustration only with no due diligence done Osaka University in 1996, where he received an award for being the for fit, coherence and consistency. top student in the department. He further obtained a Master of Science (Master of Technology) degree and a Master of Business Administration 3 The iterations can also be initiated from the degree from the National University of Singapore in 2000 and 2003 other steps. respectively.

BIOGRAPHY Alvin Koh Hian Siang is a Senior Systems Architect (DMSA). He is involved in a study for large-scale and complex systems architecture. Pang Chung Khiang is Director (DSTA Masterplanning and Systems As a certified Enterprise Architect from Carnegie Mellon University, Architecting). He has extensive experience in aircraft, unmanned air he also has extensive practical experience in systems architecting and vehicles and guided systems. He won the Defence Technology Prize enterprise architecture methodologies. Previously, he led a programme Team (Engineering) Award and the Individual (Engineering) Award in to operationalise the Enterprise Architecture Framework in the defence 1991 and 2008 respectively. He also received the National Day Public domain. He also managed and developed command and control Administration Medal in 1999 (Bronze) and 2008 (Silver). Under the systems for Homeland Security agencies. Alvin obtained a Bachelor of Colombo Plan scholarship, Chung Khiang obtained his Bachelor of Engineering (Electrical and Electronics Engineering) degree with Honours Engineering (Mechanical Engineering) degree with First Class Honours from Nanyang Technological University (NTU) in 1996. Under the DSTA from the University of Adelaide, Australia in 1982, where he also Postgraduate scholarship, he further obtained a Master of Science received the Tubemakers of Australia Prize for Engineering Management. (Communication Software and Networks) degree from NTU in 2006. In 1988, he further obtained two postgraduate degrees, the Master of Science (Aeronautical) degree and Aeronautical Engineer degree from the Naval Postgraduate School, USA, under the Defence Training Technology Training Award. In 2000, he was awarded the Programme for Management Development scholarship for management study in Harvard University, USA.

103 DSTA HORIZONS DSTA