May 1, 1996 - P.J. Ryan is with the CSIRO Division of Forestry and Forest. Products, PO ...... Bishop, Y.M., S.E. Fienburg, and P.W. Holland, 1975. Discrete ...
An Operational Definition of Context. Andreas Zimmermann, Andreas Lorenz, and Reinhard Oppermann. Fraunhofer Institute for Applied Information Technology.
skills also are important for children's concept development and ... 37â34â27â2 ... during the videotaped practice, and (f) planning with mothers as to how to .... monthly cross-site meetings in which videotapes were coded as a team and.
Nov 6, 2014 - genetic variation affects facial features, these observations com- pellingly support the ... PLOS Genetics | www.plosgenetics.org. 1. November ...
Table III describes all the control and data domain primitives. The GMB simulator. A GMB simulator governs the GMB semantics. 11 This simulator is built upon a.
Sep 27, 2005 - Objective To establish a surveillance network for cardiovascular diseases (CVD) risk factors in industrial settings and estimate the risk factor burden using standardized tools. Methods We conducted a baseline cross-sectional survey (a
*This work was done when the authors where at the Indian Institute of. Technology ... traffic specifications and there are no component (link and/or node) faults.
Apr 18, 2013 - rainfall at Edgecumbe, Barbados. (Burton 1995). Impacts potentially ... Implemented jointly by McGill University, CIMH and 3 partner countries ...
the Berth Allocation Problem (BAP), the Quay Crane. Assignment Problem (QCAP) and the Quay Crane Scheduling. Problem (QCSP). The BAP aims at finding ...
May 2, 2012 - Abstract: We develop a scale-dependent nonlinear input-output ... Preliminary analysis will use archetype interindustry data for US, China and Brazil. ..... To simplify the exposition and save space, we present summary results.
Network defense, and in the military realm, information dominance have been hot topics over the last .... pre-established rules or signatures, to detect or block when an anomalous activity occurs. These tools cannot .... Currently, stove-piped data s
International Journal of Hospitality Management 36 (2014) 197â208. Contents lists ... Architecture and. Building Research Institute, Ministry of the Interior in 2000 report .... dation during the planning and execution of projects. The notion.
By analysing plant disease epidemiology and early warning theory, the conceptual model of early warning on cucumber disease of greenhouse is developed.
SPAM uses a lexicographic sequence tree (Figure 5) for finding sequential patterns. By traversing the ... SPAM was able to find a lot of rules up to a maximum.
Jun 28, 2004 - system for the detection of emerging disease outbreaks. ProMED-mail ... for emerging diseases of the new millennium. A novel disease,.
(SAP) sensor-augmented pump, (T1DM) type 1 diabetes mellitus, (TL) time lag. Keywords: adaptive models, diabetes, early warning system, glucose prediction.
overturn. Similar sensor modules can be attached to the .... n=3) is considered and the vehicles of number n and n-1 are merged and shifted ... If the answer is positive, the given collision is registered .... the test probes. ... As the noise is AWG
Mar 14, 2014 - (Driver Pressure State Impact Response) causal framework  to meet the specific needs of ex ante impact assessment in ..... A single installation of GeoServer  is utilized to create the spatial services for the application. The
of vegetation but there is vegetation on the ground). To reduce the first type of error, S10 single channels (Red, NIR, and SWIR) are needed and provided to the ...
The extraction of road networks from aerial images is one of the current challenges in digital photogrammetry and computer vision. In this paper, we present a ...
connectors provide transfer between different scales and fast computation, by coupling model codes at a deep level in software. A workflow .... results and software are intended to be open access and free of charge, while the costs of .... GIS-determ
The sensors are attached to a metal free X-Y table for taking stand-off ... and 49 ATs. The mine types AP5 and AT3 are metal free. ..... darker shades represents more metal. ..... A remarkable operating point is the point at 50% to 60% detection.
Systems Research Forum Vol. 5, No. 2 (2011) 109141 # .c World Scienti¯c Publishing Company DOI: 10.1142/S1793966611000308
ESTABLISHING AN OPERATIONAL CONTEXT FOR EARLY SYSTEM-OF-SYSTEMS ENGINEERING ACTIVITIES
BRYAN HERDLICK Johns Hopkins University/Applied Physics Laboratory Patuxent River Field O±ce 46579 Expedition Drive Suite 300, Lexington Park, MD, 20653, USA [email protected]
Investigation of the engineering trade-space associated with complex capabilities and system-ofsystems (SoS) solutions is often pursued outside the purview of an over-arching Major Defense Acquisition Program. As a result, many of the mandates associated with the United States Department of Defense (DoD) acquisition process may not be levied upon such activities. However, since establishing an operational context for system or capability development remains a systems engineering best practice, the requirement for a concept of operations document should be given favorable consideration. Unfortunately, the myriad variants of CONOPS in the DoD (and the organizational pedigree associated with each) can generate misunderstanding and disagreement over authorship, ownership, approval authority, and the intended purpose of the document. The title alone can undermine the utility of an operational context document and result in its misinterpretation or rejection. This paper compares guidance on the development of operational concept documents from industry, DoD and U.S. military services and compares them with related documents that are sometimes confused with (or inappropriately substituted for) CONOPS. A new method for establishing an operational context for SoS-based capability development is presented as an alternate to the aforementioned documents. Keywords: CONOPS, concept of operations; CONEMPS, concept of employment; OCD, operational concept description; DRM; DRMP, design reference mission pro¯le; SoS, system of systems; concept development; technology development; engineering development; CBA, capability-based analysis.
1. Introduction Chairman of the Joint Chiefs of Sta® Instruction (CJCSI, 2007) 3710.01 de¯nes a capability as \The ability to achieve a desired e®ect under speci¯ed standards and conditions through a combination of means to perform a set of tasks to execute a speci¯ed course of action." However, the language in the 3710.01 series of instructions speaks more to documenting the requirements associated with a single program rather than articulating the concept of a composite capability that must be achieved through multiple programs. Such a distributed design is, by de¯nition, a system of systems (SoS) and achieves a capability greater than that delivered by the constituent systems acting independently. While it may be successfully argued 109
110 B. Herdlick
that a ¯ghter aircraft or a surface combatant may satisfy the technical de¯nition of a SoS, such examples are normally developed through a singular major defense acquisition program (MDAP) and do not evidence the additional organizational complexity associated with a SoS constructed from multiple MDAPs. The challenges associated with the management and development of such SoS-based capabilities have received much attention in recent years. An article in the journal Systems Engineering, titled \System of Systems Lead System Integrators: Where Do They Spend Their Time and What Makes Them More or Less E±cient" (Lane and Boehm, 2008) o®ers an excellent overview of those challenges and an introduction to 20 other references in the topic area. Within the US Department of Defense (DoD), the O±ce of the Undersecretary of Defense for Acquisition and Technology issued a Systems Engineering Guide for Systems of Systems (ODUSD (A&T)SSE, 2008) to introduce terminology and consolidate applicable best practices. Finally, in the summer of 2009, the International Council on Systems Engineering (INCOSE) proposed a Research Plan (Ferris, 2009) that identi¯ed SoS as one of seven key areas of interest, with speci¯c emphasis on a need for SoSspeci¯c methodology and documentation. This paper o®ers a contribution to the methodology and documentation associated with the development of SoS-based capabilities speci¯cally the establishment of an operational context for early systems engineering activities. In the lexicon of the SoS SE guide, this paper focuses attention on \Acknowledged" SoS. The SoS SE guide cedes that often only some of the characteristics o®ered in the de¯nition of an \Acknowledged" SoS are met. Speci¯cally, the assignment of a \designated manager" and the allocation of \resources for the SoS" may manifest as an ad hoc \coalition of the willing," possibly facilitated by a lead integrator and executed through \creative" funding vehicles. Additionally, while it may be true that \. . .constituent systems retain their independent ownership, objectives, funding, and development and sustainment approaches. . ." it must be stressed that this applies only to previously established, system-speci¯c functionality not associated with the SoS-based capability under development. Finally, the statement that \Changes in the systems are based on collaboration between the SoS and the system" incorrectly implies that a SoS development e®ort is backed by an organizational entity that is similar to the program o±ces responsible for management of the constituent systems that comprise the SoS. In spite of the extensive treatment given SoS challenges in systems engineering professional journals and conferences, and even following the publication of the DoD SoS SE Guidebook, the pursuit of complex capabilities through SoS solutions continues to vex those charged with the management of such e®orts. The development of a SoS-based capability is often a messy, iterative process that alternates between problem de¯nition and exploration of the solution space unavoidable, perhaps, when addressing \Wicked Problems" (Conklin, 2005) but an application for which the linear DoD acquisition processes are ill-suited. As a result, the exploration of SoS solutions is normally pursued outside the purview of a single
Establishing an Operational Context for Early System-of-Systems Engineering Activities 111
over-arching, capability-focused MDAP.a Some excerpts from the DoD Instruction for \Operation of the Defense Acquisition System" (DoDI 5000.2, 2008) are introduced in the following paragraphs to frame the ad hoc approach to SoS development prevalent today in the U.S. DoD. Italics have been introduced by the author for emphasis. It is not uncommon for concept development and technology development activities to be pursued outside the purview of (often as a precursor to) a MDAP. Often, a team comprised primarily of scientists and engineers must craft an operational context to inform concept development, technology development and early engineering development activities. Examples of such e®orts are detailed in the excerpt from DoDI 5000.2, below. Crafting an operational context for an advanced capability especially one that challenges present-day war¯ghting doctrine and tactics requires more than a compilation of existing Concepts of Operations, weapon systems operating manuals, DoD capability/requirements documents, and system speci¯cations. This paper o®ers a method for addressing this challenge. TECHNOLOGY PROJECTS. Joint Experimentation, Defense Advanced Research Projects Agency projects, the Technology Transition Incentive Program, SBIR and Small Business Technology Transfer Programs, the Joint Integration and Interoperability Program, Joint Capability Technology Demonstrations, the Coalition Warfare Program, the Quick Reaction Special Projects/Rapid Reaction Fund, Foreign Comparative Testing, the Defense Acquisition Challenge Program, the Joint Test and Evaluation Program, the Joint Improvised Explosive Devices Defeat O±ce, the Rapid Reaction Technologies O±ce, and Defense Biometrics are some of the activities that facilitate and provide early joint technology and capability de¯nition, development, experimentation, re¯nement, testing, and transition. The USD (AT&L) shall be the MDA [Milestone Decision Authority] for those projects that, if successful, will likely result in an MDAP or MAIS program unless the USD (AT&L) delegates milestone decision authority for a MAIS program.b Early concept and technology development activities for a SoS-based capability often deviate from those associated with a single-system solution that might constitute a candidate MDAP upon completion. In the excerpt immediately below, DoDI 5000.2 highlights steps that still must occur (author's italics) in the development of a SoS solution, but also clearly re°ects the constraints of the traditional acquisition process. Due to the nonlinear nature of complex capability development, the DoD acquisition process for MDAPs often cannot be neatly applied to SoS solutions and a clear break-point (e.g., Milestone B) between technology a The U.S. Army Future Combat System (FCS) is often presented as an exception to this statement. While it makes for an interesting and educational case study in its own right, it has not become a template for successful development, management, or acquisition of SoS-based solutions within DoD. b Department of Defense Instruction 5000.2, USD(AT&L), 2 December 2008 (Enclosure 3, p. 30).
112 B. Herdlick
development (TD) and engineering and manufacturing development (EMD) cannot be identi¯ed. Furthermore, the latitude to permit a system to enter the acquisition process at Milestone C, given satisfaction of EMD exit criteria (second excerpt, below), substantiates the claim that DoD regularly conducts activities from Concept Development through Engineering and Manufacturing Development outside the purview of an MDAP. The project shall exit the Technology Development Phase when an a®ordable program or increment of militarily useful capability has been identi¯ed; the technology and manufacturing processes for that program or increment have been assessed and demonstrated in a relevant environment; manufacturing risks have been identi¯ed; a system or increment can be developed for production within a short timeframe (normally less than ¯ve years for weapon systems); or, when the MDA decides to terminate the e®ort. During Technology Development, the user shall prepare the capability development document (CDD) to support initiation of the acquisition program or evolutionary increment, re¯ne the integrated architecture, and clarify how the program will lead to joint war¯ghting capability. The CDD builds on the ICD and provides the detailed operational performance parameters necessary to complete design of the proposed system. A Milestone B decision follows the completion of Technology Development. ENGINEERING AND MANUFACTURING DEVELOPMENT (EMD) PHASE. The purpose of the EMD Phase is to develop a system or an increment of capability; complete full system integration (technology risk reduction occurs during Technology Development); develop an a®ordable and executable manufacturing process; ensure operational supportability with particular attention to minimizing the logistics footprint; implement human systems integration (HSI); design for producibility; ensure a®ordability; protect CPI [critical protected information] by implementing appropriate techniques such as anti-tamper; and demonstrate system integration, interoperability, safety, and utility. The CDD, Acquisition Strategy, SEP [systems engineering plan], and test and evaluation master plan (TEMP) shall guide this e®ort. EMD begins at Milestone B, which is normally the initiation of an acquisition program. There shall be only one Milestone B per program or evolutionary increment. Each increment of an evolutionary acquisition shall have its own Milestone B unless the MDA determines that the increment will be initiated at Milestone C. At Milestone B, the MDA shall approve the Acquisition Strategy and the acquisition program baseline (APB). The MDA decision shall be documented in an ADM [acquisition decision memorandum]. The tables in Enclosure 4 identify the statutory and regulatory requirements that shall be met at Milestone B. The exploration of SoS engineering trade space, given its nonlinear nature and the asynchronous program timelines of the constituent systems, makes necessary the
Establishing an Operational Context for Early System-of-Systems Engineering Activities 113
simultaneous conduct of concept development (CD), TD and EMD activities. Collaboration between existing program o±ces, platform/system contractors, and organizations from the S&T, R&D, and acquisition engineering disciplines is thus required, and a virtual organization forms that must operate in parallel with the traditional acquisition process as it applies to MDAPs. Without the auspice of an over-arching MDAP for the SoS, however, much of the burden and bene¯t of the formal DoD acquisition process can be missing such as the requirement for a welldeveloped operational context to guide development activities (e.g., a CONOPS document is mandated for MDAPs by the ClingerCohen Act via DoDI 5000.2). However, the fact that DoD acquisition processes and organizations are not well suited to SoS development should not be construed as license for departure from sound systems engineering best practices. Identi¯cation of an operational context for the development of a new SoS-based capability is arguably even more important, as substantiated in the aforementioned DoD SoS SE Guide: Logical Analysis is the ¯rst major step in Developing and Evolving and SoS Architecture. An important starting point is the CONOPS for the SoS. How will the SoS be employed in an operational setting? What are trigger conditions? What is the range of scenarios? Who are the key participants and what are the constraints on their actions? In developing the architecture for the SoS, the SoS systems engineer develops a structured overlay atop the set of constituent systems supporting SoS objectives, addressing key questions about the SoS, including: Which systems provide what functionality to the SoS? What are the end-to-end threads for the SoS? What behavior is expected of the systems? What data need to be exchanged to implement the threads? A key contributor to the DoD SoS SE guide, Judith Dahmann, recently co-authored an article that appeared in the January 2011 issue of IEEE Aerospace and Electronic Systems that further describes a \SoS CONOPS" as follows: The SoS CONOPS describes how the functionality of the systems in the SoS will be employed in an operational setting. The CONOPS is developed by operational users and with active participation from the SoS systems engineers to describe the way users plan to operate and use systems to achieve the objectives, as in°uenced by the various environments and conditions anticipated. It is developed in parallel with the capability objectives. As the capability objectives evolve, the CONOPS should evolve in detail, as well. SoS management and SE teams use the CONOPS to de¯ne the SoS requirements space, to identify aspects of systems which could impact SoS design, and to select performance metrics and test environments, [further characterized by/as:] Multiple system focus. Often developed after constituent systems have been ¯elded; Evolves over time, sometimes substantially.
114 B. Herdlick
While attempting to reinforce sound systems engineering practices during SoS development, both of these excerpts use the term \CONOPS" as an appropriate acronym, but perhaps without consideration for the fact that the term can imply di®erent content and purpose to the participants and stakeholders in the SoS development e®ort. Furthermore, since early SoS development e®orts are often led and conducted by engineers and scientists to include the initial de¯nition of the operational context for the complex capabilities they deliver any associated \CONOPS" constitutes a source of friction and ine±ciency due to disagreement over content, authorship, ownership, approval authority, and the intended use of the document. From a perspective admittedly more focused on the U.S. Navy, this paper compares industry, DoD and service-speci¯c guidance for CONOPS with that for related documents that are sometimes confused with (or inappropriately substituted for) CONOPS. Information elements critical to the development of SoS-based capabilities are identi¯ed and assembled to create a new document that is uniquely suited to early systems engineering activities associated with SoS development. 2. Industry \CONOPS" Guidance on the development of an operational concept or concept of operations (CONOPS) (the terms are often used inter-changeably outside DoD) can be found in many industry references (IEEE, 2007), (INCOSE, 2007) and generally details how a system will be used from the operator/user perspective. For instance, The Handbook of Systems Engineering and Management (Sage and Rouse, 1999) characterizes an \operational concept document (OCD)" as a product that should: \[capture]. . . how the system will be used during the operational phase, [and] the reasons the system has for existing." Development of such a product \. . . depends on a thorough understanding of the missions that the system must perform and the environment that the system will have to operate in. Hence the systems engineer works closely with the users or their representatives to write the operational requirements. Together, they describe the major functions and operational characteristics desired for a system. How the system operates, where in the operating environment the system will be distributed, how long the system must operate, and how e®ective the system' s performance must be are all part of the operational concept. Care is taken not to specify technical solutions but to describe the performance desired of the new or improved system. Usually the operational concept describes the typical mission pro¯les or operational scenarios of the system." 3. CONOPS in the U.S. Navy While CONOPS developed within the U.S. DoD may ¯t the industry-representative de¯nition presented above in most respects, they can often be quite speci¯c as to the
Establishing an Operational Context for Early System-of-Systems Engineering Activities 115
technical solution and supportability aspects a deviation from the above de¯nition. Additionally, DoD CONOPS can also evidence \organizational pedigrees" that can imbue them with an identity that is every bit as important as the content of the document. OPNAV Instruction 5401.9 (DoN, 2010), which details the Navy Concept Generation and Concept Development Program, identi¯es two broad categories of CONOPS within the Navy \acquisition" and \Fleet." Speci¯cally, it states that \[CONOPS can be]. . .a document generated by the O±ce of the chief of Naval Operations (OPNAV) [used in the] Department of the Navy requirements and acquisition governance process or a °eet CONOPS." In a 2006 brie¯ng, the Navy's Fleet Forces Command depicts CONOPS development responsibilities within the Navy, as promulgated by a Navy Corporate Board decision of February 2005. The graphic identi¯es the OPNAV as being responsible for CONOPS that address future requirements (beyond the Future Years Defense Plan; FYDP) with such CONOPS approved by the Chief of Naval Operations (CNO). The Commander of Fleet Forces Command (CFFC) is identi¯ed as the Fleet's consolidated and authoritative voice charged with approval of CONOPS within the FYDP. The Naval Warfare Development Command (NWDC) is responsible for managing the CONOPS enterprise on behalf of the Navy. In Fig. 1, acquisition CONOPS are developed by the organizations in the upper dark-blue ovals, and °eet CONOPS are developed by war¯ghting organizations in the lower dark-blue ovals. This ¯gure indicates that ALL Navy CONOPS (except those associated with real world and training operations which imply yet more CONOPS categories) are tracked by NWDC and validated by CFFC a questionable representation given the myriad variants of CONOPS employed within the Navy's acquisition activities. The validity of this approach to CONOPS development
Fig. 1. (Color online) CONOPS Management Process as de¯ned by the OPNAV Corporate Board, 2005 (from the Fleet Forces Command CONOPS Guidance Brief of October 2006).
116 B. Herdlick
and management is further challenged in application to SoS solution, where existing platforms and systems are modi¯ed and integrated (within the FYDP), and augmented by new systems (within and beyond the FYDP), to deliver increments of war¯ghting utility (within the FYDP) in pursuit of a composite capability that may not be realized until beyond the FYDP. Acquisition and Fleet CONOPS are introduced brie°y in the following paragraphs to support subsequent evaluation of their merits and shortfalls in application to early SoS engineering activities. 3.1. Operational (Fleet) CONOPS Operational CONOPS are described in Joint Publications, instructions from the Joint Chiefs of Sta®, and guiding documents from the individual military services. From the perspective of the Chairman of the Joint Chiefs of Sta®, as re°ected in Instruction (CJCSI, 2006) number 3010.02b, CONOPS in the context of Joint Operating Concepts (JOpsC) and capability-based analysis (CBA) are focused on military operations and the employment of forces beyond the FYDP. This instruction states that \The Secretary of Defense approves a set of threat-based classi¯ed defense planning scenarios (DPSs). They are informed by the e®ects and military capabilities outlined in the JOCs and JFCs to develop classi¯ed blue force CONOPS. The scenarios, in turn, are used during the CBA of JICs [Joint Integrating Concepts]." It further details the role of CONOPS pursuant to the family of JOpsC documents as follows: For JOpsC family development, CONOPS are used to provide the overall understanding of an operation and the broad °ow of tasks assigned to subordinate and/or supporting entities. It presents a joint force commander's plan that synchronizes military capabilities to accomplish the mission for a speci¯c scenario 820 years into the future. CONOPS focus on describing the streams of activities and how the joint force commander might organize and employ forces to accomplish those activities. CONOPS used in the JOpsC family development process are based on DPS or illustrative vignettes: (a) Defense Planning Scenarios. DPSs, written 8–20 years into the future, are used in CBA. These scenarios have classi¯ed CONOPS that provide a high level of speci¯city and de¯ned parameters to aid in robust analysis of capabilities and a comparison of alternate solutions. (b) Illustrative Vignettes. When used in JOpsC, illustrative vignettes provide operational context to describe how a joint force commander might organize and employ forces 8–20 years into the future. These vignettes are used to clarify and increase understanding of the concepts. At the military service level, the U.S. Navy's Fleet CONOPS Writer's Guide states that the Fleet CONOPS Development Team \. . .collaborates with the CNO resource sponsors for supporting information from related studies/analyzes and ensures
Establishing an Operational Context for Early System-of-Systems Engineering Activities 117
consistency with what capabilities are expected within the FYDP." It also depicts Fleet CONOPS as sharing \top-down guidance" with the Concept Development process, and bene¯tting from \lessons learned" from exercises, operational planning documents and \real-world operations" (see Fig. 2). In execution, however, the focus on near term capabilities (i.e., systems currently ¯elded, or soon to ¯eld; within the FYDP) and operational applications is re°ected in the format and content of the two variants of Fleet CONOPS \War¯ghting" and \Platform Wholeness." Subsequent review will reveal that these documents are ill-suited to DoD acquisition and technology development activities. By comparison, the U.S. Air Force de¯nes CONOPS in their Concept of Operations Development Instruction (AFI 10-2801, 2005) as a document that \. . .delineates the highest Service-level concept comprising a commander's assumptions and intent to achieve desired e®ects through the guided integration of capabilities and tasks that solve a problem in an expected mission area." This instruction further states that \. . .Joint Force Commanders employ [AF CONOPS] through Air Expeditionary Forces to ¯ght and win wars." This instruction goes on to identify \the seven" AF CONOPS as: \Global Strike, Global Persistent Attack, Homeland Security, Nuclear Response, Global Mobility, Space and Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance, and Agile Combat Support. This de¯nition re°ects a decidedly operational perspective, and aligns well with CONOPS as described in the U.S. Navy's Fleet CONOPS Writer's Guide (DoN, 2009), but is not intended to directly serve DoD acquisition or technology development activities.
Fig. 2. \Concept to CONOPS to Doctrine" Transition (a variant of Fig. 1-1 from the CFFC Fleet CONOPS Writer's Guide).
118 B. Herdlick
3.1.1. War¯ghting CONOPS In Chief of Naval Operations Instruction (OPNAVINST) 5401.9, the U.S. Navy states that \A Fleet war¯ghting CONOPS [speci¯es] how the °eet will employ current capabilities and/or capabilities that will reach initial operational capability (IOC) within the Future Years Defense Plan." The Fleet CONOPS Writing Guide states that \The primary purpose of a CONOPS is to bridge a concept to delivery of a capability to the war¯ghter." It further de¯nes a Fleet War¯ghting CONOPS as: \A formal document specifying how the Fleet employs current capabilities or will employ capabilities that will reach IOC within the FYDP. . ." and speci¯es that \The primary audience for War¯ghting CONOPS is those who plan and execute the U.S. Navy missions." The U.S. Navy's Fleet CONOPS Writing Guide provides a general format for War¯ghting CONOPS as Appendix C. Topic headings include a letter of promulgation, an executive summary (with a DOTMLPFc focus), purpose/statement of intended use for the document, scope of the document, scenarios and how capabilities may be employed [unique to War¯ghting CONOPS], details on manning and training (if applicable), DOTMLPF considerations, and validation requirements. 3.1.2. Platform wholeness CONOPS OPNAVINST 5401.9 distinguishes a Fleet Platform Wholeness CONOPS from a War¯ghting CONOPS in that it speci¯es \. . .how the Fleet mans, trains, equips and maintains new capabilities that will reach IOC within the FYDP. It informs programs of record (PORs) of the Fleet's needs and intent. The primary audience for the Fleet Platform Wholeness CONOPS is the platform's type commander (TYCOM) and supporting organizations." The Fleet CONOPS Writing Guide provides a general format for Platform Wholeness CONOPS as Appendix C. Topic headings for a Platform Wholeness CONOPS di®er slightly from a War¯ghting CONOPS and include a letter of promulgation, an executive summary (with a DOTMLPF focus), purpose/ statement of intended use for the document, scope of the document, a description of the platform in terms of capabilities and concept (unique to Platform Wholeness CONOPS), an analysis of the operations of the platform (unique), a description of administrative control and operational chain of command (unique), details on manning and training (if applicable), support requirements, DOTMLPF considerations, and validation requirements. Notably, scenario(s) and how a platform may be employed are not topics normally addressed by a Platform Wholeness CONOPS. 3.2. Acquisition CONOPS Many variants of CONOPS are developed within the DoD acquisition construct, and may serve to inform the development of maintenance plans, security processes, c DOTMLPF is an acronym for Doctrine, Organization, Training, Materiel, Leadership, Personnel and Facilities it serves as a tool for quickly referring to those aspects of ¯elding, support and employment that exceed the immediate scope of weapon system design and production.
Establishing an Operational Context for Early System-of-Systems Engineering Activities 119
training programs, or system and capability development. Chairman of the Joint Chiefs of Sta® Instruction 3710.01 de¯nes the Joint Capability Integration and Development System (JCIDS) and associated \requirements" documentation, and limits the scope of an acquisition CONOPS to a timeframe within the FYDP. It states that a (acquisition) CONOPS is intended to detail \. . .how a joint force commander may organize and employ forces in the near term (now through seven years into the future) in order to solve a current or emerging military problem. These CONOPS provide the operational context needed to examine and validate current capabilities and may be used to examine new and/or proposed capabilities required to solve a current or emerging problem." This wording implies the CBA process used to identify war¯ghting capability gaps and prospective solutions, to include an Analysis of Alternatives (AoA). In DoD Instruction 5000.02, such CONOPS are referred to as \preliminary CONOPS" (see excerpt, below) and are introduced as an integral part of the initial requirements development process. Such CONOPS are closely a±liated with an initial capability document (ICD) and precede an AoA. While such a \preliminary CONOPS" may o®er an early articulation of an operational context, it is not intended to provide adequate detail to support technical or engineering development activities. At the Materiel Development Decision review, the Joint Sta® shall present the JROC recommendations and the DoD Component shall present the ICD including: the preliminary CONOPS, a description of the needed capability, the operational risk, and the basis for determining that nonmateriel approaches will not su±ciently mitigate the capability gap. The Director, Program Analysis and Evaluation (DPA&E), (or DoD Component equivalent) shall propose study guidance for the AoA. The National Research Council's U.S. Air Force Study Board (NRC, 2008) further describes a \preliminary" CONOPS as a product that follows concept creation/ identi¯cation, and precedes performance assessments and architecture development. They state that early in the capability development process (i.e., pre-Milestone A), a preliminary CONOPS should be developed that \. . .is a top-level description of how a system and its operators and users will interact to produce the required capability, including operation in a SoS. At Milestone A, the CONOPS needs to be su±cient to ensure that the chosen concept is capable of operating to produce the desired outcomes and time lines. A key precursor of a CONOPS is often a description of the other systems with which the system of interest will be interacting and an understanding of what the user expects the system to do in its operating environment." Given that the \preliminary" CONOPS mentioned in DoDI 5000.2 is introduced as an integral part of the ICD and further discussed in a U.S. Air Force context as a preMilestone A product, it presents as a precursor to the CONOPS mandated for MDAP s by the ClingerCohen act.d d Enclosures 4 and 5 of DoDI 5000.2, taken together, are required to construct the requirement for the \acquisition" CONOPS required for DoD acquisition Milestones.
120 B. Herdlick
The Navy's Fleet CONOPS Writer's Guide depicts \acquisition" CONOPS as any variant of a \concept of operations" that is developed by OPNAV and not approved by Fleet Forces Command. A more speci¯c de¯nition for an acquisition CONOPS may be found in OPNAV Instruction 5401.9 which states that such a document shall o®er \. . .a description of capability employment, sustainment, basing, training and manning to support life-cycle cost estimates." This is quite di®erent from the purpose identi¯ed for Operational (Fleet) CONOPS. Historically, there has been no clear guidance for how best to identify an operational context for technical and early engineering development activities. Recently, however, a draft OPNAV Instruction for a Developmental System Concept of Operations was produced and is under review for approval as of May 2011. OPNAV Instruction 5401.xx (2010) (no ¯nal identi¯er assigned) detail a variant of acquisition CONOPS and identi¯es it as an accompanying document to the capabilities development document (CDD) required at Milestone B for MDAPs. Based on its availability at MS B, it must be presumed suitable as a guide for engineering and manufacturing development e®orts, and satisfactory from the standpoint of the ClingerCohen Act. However, it is not intended as a guide for early concept development and technology development. Furthermore, the instruction (in its draft form) clearly states that it applies to MDAPs, pre-MDAP programs, and Rapid Deployment Capability programs not ad hoc SoS development e®orts executed asynchronously through those MDAPS.
4. CONOPS Surrogates and Imposters In an e®ort to avoid perceived con°ict over content, authorship, ownership, and approval authority, it is not uncommon for other \recognized" documents to be selected as an alternative to a CONOPS if only to a±x a di®erent name to a document with similar content and purpose. The most common CONOPS \surrogates" include \Concepts of Employment (CONEMPS)" and \Design Reference Mission Pro¯les (DRMP)." Other documents that present as contenders for the role of CONOPS include \Concept Development Proposals" and \Operational Concept Descriptions". Each of these prospective alternatives to a CONOPS is introduced brie°y in the following paragraphs to support a subsequent evaluation of their merits and shortfalls in application to early SoS engineering activities. 4.1. Concepts of employment CONEMPS is a term that has been used to identify CONOPS documents developed in support of early system development activities in the DoD acquisition process. As previously mentioned, draft OPNAV Instruction 5401.xx (under review) seeks to replace the term CONEMP with term Developmental System CONOPS as a means to distinguish this variant of CONOPS from those used in the °eet. Confusing the issue, however, are (as an example) CONEMP documents developed by NATO for
Establishing an Operational Context for Early System-of-Systems Engineering Activities 121
the integration of unmanned air systems, and use of the term by the United Kingdom Ministry of Defense which identi¯es CONOPS and CONEMPS as separate documents developed in a sequence of increasing maturity (U.K. MoD, 2005) a relationship opposite to that historically followed within U.S. Navy acquisition channels, as detailed in OPNAVINST 5401.xx.
4.2. Design reference mission pro¯le In a technical brie¯ng of 2002, the Assistant Secretary of the Navy for Research, Development and Acquisition de¯ned a Design Reference Mission Pro¯le (DRMP) as \. . . a time history or pro¯le of events, functions (often referred to as use or operations) and environmental conditions that a system is expected to encounter during its lifecycle, from manufacturing to removal from service use" (ASN(RD&A), 2002). They further detail the content and scope of a DRMP as follows: Proper de¯nition of the DRMP includes not only the expected nominal climatic conditions, but also worst-case, rate of change, synergistic conditions, and conditions of assembly, packaging, handling, shipping, storage, maintenance and transportation. The signi¯cance of induced environments (i.e., environmental conditions that are predominantly man-made or generated by the materiel platform) is often overlooked. Therefore, it is essential that conditions such as repetitive shock or transient vibration caused by gun¯re, °uctuating pressure loadings caused by acoustic noise, aerodynamic turbulence, pyrotechnic shock, near miss shock and electromagnetic environments be considered during the development of the DRMP." \It is important [that the DRMP identi¯es] appropriate values for material design and test related criteria [to include] realistic environmental parameters and material-speci¯c parameter levels associated with environment-related issues and criteria. In 2000, Skolnik and Wilkins detailed the role of a DRMe within the DoD acquisition process and depicted it as a predecessor to the development of concepts and requirements. Speci¯cally, they stated that: The DRM concept seeks to de¯ne the problem, not the solution. Its primary objective is to characterize the threat and operating environment that will serve as the baseline to support systems engineering activities, i.e., requirements de¯nition/re¯nement, concept development/evaluation, trade study analysis, design, test and evaluation, etc. e Additional references for DRM and DRMP are desired, as the di®erence between the two is not clear based on guiding documents available during the creation of this point-paper. Based on the author's experience, the two terms are often used interchangeably, although the term DRM is often used to refer to a more prosaic document with a broader scope (i.e., not limited to just chronological tables of functions and environmental conditions).
122 B. Herdlick
An extract from a \real-world" DRMP purpose statement is presented below to further demonstrate the unique nature of the DRMP. The italicized, underlined text is indicative of the relationship between the DRMP and both the systems engineering process, and the scenarios normally associated with a CONOPS document. Of note, the DRM is presented as a reference for engineering activities and the subsequent development of scenarios it does not, however, contain operational scenarios. Because the [system name removed] is considered an on-demand system, an understanding of when it is required to be operational is needed. Therefore the DRMP has been designed to explain the high level, time-sequenced pro¯le of a single [platform/system] sortie. The DRMP provides a baseline which can be used to assess and establish consistency between the CDD performance requirements and the tactical application of the system. The document also serves as a basis for campaign and mission analyzes. The pro¯le provides a reference mission which can be used as a systems engineering input. Consistent with the CDD's de¯nition of the system, the DRMP also delineates the [platform/system] boundaries and the interface [with] outside systems. By establishing these system boundaries, the DRMP de¯nes the system components which are included in calculating system reliability, maintainability, and availability. The DRMP also provides a baseline de¯nition for mission start time and completion time and identi¯es the timeframe within a mission which is used to calculate an area search rate. Finally, the DRMP provides a mission pro¯le baseline for use in designing scenarios for developmental and operational testing of the [platform/system] as well as supporting what will be considered operational uptime, downtime, and neutral time. The ASN(RD&A) DRMP guide states that \A common method used is a series of charts/matrices that, as a composite, identify and describe, in sequence, the pertinent functions and environments and their parameter ranges." Content is further detailed as addressing a functional and environmental pro¯le. The functional pro¯le is characterized by things such as packaging, handling, shipping and storage prior to use; mission pro¯les while in use; phases between missions such as stand-by or storage; and transfer to and from repair sites and alternate locations. The environmental pro¯le includes natural environmental pro¯les (e.g., temperature, pressure, etc.) and induced environmental pro¯les from things such as external sources (e.g., ECM, gun¯re, acoustics, pyrotechnics), internally generated sources (e.g., heat, vibration, shock), and self-generated sources resulting from contact/interface with the environment. ASN(RD&A) best practices for DRMP development state that: .
Mission Pro¯les cover all system environments during its life cycle including operational, storage, handling, transportation, training, maintenance and production. . Mission Pro¯les are de¯ned in terms of time (duration and sequence), level of severity, and frequency of cycles.
Establishing an Operational Context for Early System-of-Systems Engineering Activities 123 .
Mission and System Pro¯les are detailed by the Government and contractor, respectively, based on natural and induced environments (e.g., temperature, vibration, electromagnetic impulses, shock and electrical transients). . Pro¯les are the foundation for design and test requirements from system level to piece parts, including COTS/NDI. . DRMP environmental pro¯les should not be simply extracted from MIL-HDBK 810, \Environmental Test Methods and Engineering Guidelines," 31 July 1995. . Mission Pro¯les should not be based on average natural environmental conditions; more extreme conditions may more accurately re°ect operational requirements in the place/at the time of use, such as indicated by MIL-HDBK-310 \Global Climatic Data for Developing Military Products," 23 June 1997 and the National Climatic Data Center. DRMP guidance documents do not imply or direct that a DRMP should indicate, detail or otherwise constrain (beyond the impact of mission-speci¯c conditions) the material solution, engineering design, or operational employment of a capability. The scope of a DRMP also excludes justi¯cation for a proposed concept/capability/ system and any presentation of prospective military utility in an operational context (as is common in the vignettes of concept development proposals and the tactical situations normally associated with CONOPS). A DRMP does focus on system boundaries and interfaces with \outside systems." In 2002, ASN (RD&A) identi¯ed the relationship between the DRMP and other acquisition documents in this way: \The DRMP or elements of a DRMP are normally addressed in the following planning and contract documents: Mission needs statement (MNS), operational requirements document (ORD), CONOPS, acquisition plan (AP), systems engineering management plan (SEMP), TEMP, AoA, and Performance Speci¯cations." This statement clearly identi¯es a sequential development process in which the DRM establishes a foundation for subsequent development of CONOPS implying that the two are di®erent, and that the DRM scope is narrower than that of a CONOPS. This paper recommends that DoD guidance be interpreted to limit the DRMP role to that of an authoritative source of functional and environmental considerations for the development of subsequent documents, and that the DRMP should not be tailored to subsume the content or role of other documents. 4.3. Concept development proposal The Navy Concept Generation and Concept Development Program, as detailed in OPNAV Instruction 5401.9, addresses \The encapsulation of ideas into a coherent structure to pursue potential solutions; vetting and validating ideas through analytical studies, workshops, experimentation, war games, and, when required, live force experiments; transition of solutions to responsible agencies for action and to enable implementation." The concept generation process feeds concept development with candidate topics in the form of proposals, often formatted as \white papers."
124 B. Herdlick
Some of the concept development activities detailed in OPNAVINST 5401.9 necessarily form the foundation for further engineering development by the DoD acquisition community in cases where the process is sequential. The instruction o®ers examples of a Concept White Paper as well as general guidance for format and content. Topic headings include: Executive Summary, Purpose, Scope, Military Problem and/or Opportunity, Required Capabilities, Solution, Risks and Mitigation, and Considerations. It is also recommended that a Concept White Paper should conclude with a Plan of Action and Milestones (POA&M). While the content of a Concept White Paper re°ects similarity with many variants of CONOPS, its purpose is quite speci¯c to articulating a concept for future capabilities and OPNAVINST 5401.9 speci¯cally states that the concept generation and concept development (CGCD) process does not develop CONOPS.
4.4. Operational concept description The American National Standards Institute and American Institute of Aeronautics and Astronautics guide for the Preparation of OCDs (ANSI/AIAA G-043-1992; under revision in 2011) identi¯es operational concept description as a technique that results in an OCD. The purpose of the technique is to: .
Describe the system characteristics from an operational perspective. Facilitate understanding of the overall system goals with users (including recipients of the products of the system where applicable), buyers, implementers, architects, testers, and managers. . Form an overall basis for long-range operations planning and provide guidance for development of subsequent system de¯nition documents such as the system speci¯cation and the interface speci¯cation. . Describe the user organization and mission from an integrated user/system point of view. .
The guide goes further to state that the OCD (document) should be developed during concept de¯nition, should be a precursor to system speci¯cations and can serve as a tool in the evaluation of system design. It should also \. . .serve as a reference during system requirements analysis and design phases to provide the necessary framework within which the proposed system design and implementation alternatives can be evaluated." More speci¯cally, section 2.2.2 of the ANSI/AIAA guide states that \The OCD provides a mechanism to trigger questions and raise issues regarding user-related requirements/design trades." The reader is encouraged to refer to ANSI/AIAA G-043-1992 (1992) for a more detailed description of the purpose and merit of an OCD both as a process and a document. The AIAA website for the status of the 2011 OCD update is: www.aiaa.org/tc/se/html/ aiaa ocd guide.html. An Operational Concept Description is also identi¯ed in a Data Item Description (DID) generated by the U.S. Navy Space Warfare Systems
Establishing an Operational Context for Early System-of-Systems Engineering Activities 125
Command (DoN, 2000). Identi¯ed as DI-IPSC-81430A, it o®ers no reference to the ANSI/AIAA guide previously mentioned, but identi¯es similar purpose, content, and format. Of particular interest, it o®ers a more concise outline for an OCD (document) than the ANSI/AIAA guide, and adds elements speci¯c to DoD applications. It is a broad and detailed framework that lends itself well to tailoring, as has been done by a company called Solid Thinking Corporation (www.solidthinking.org) to act as a framework for the development of acquisition CONOPS for the DoD.
5. Analysis of Suitability for the Development of SoS-based Capabilities Given that the development of a SoS-based capability is often conducted outside the normal DoD acquisition framework, the applicability of many of the documents here may be challenged simply on the basis of DoD and service-speci¯c policy there may be no applicable requirement to develop them. However, the application of systems engineering best practices should not be abandoned due to a policy loophole. Each of the documents introduced earlier in this document o®ers a potential (if ill-suited) solution for capturing an operational context for early SoS development activities. The recommended content and format for each of these documents was reviewed for potential service in this role. This analysis focused on content and format proscribed for these documents in DoD and U.S. Navy guidance. The unique aspects of each document, especially as they might bene¯t a SoS development e®ort, are detailed in the paragraphs that follow. Operational or \Fleet" CONOPS o®er a comprehensive description of capabilities and systems being released (or soon to be released) for operational use. They include a letter of promulgation, an executive summary that addresses nonmaterial aspects of operations and support of a system, and a clear statement of the purpose of the document. Individual sections are dedicated to issues associated with doctrine, organization, training, materials, logistics, personnel and facilities (DOTMLPF), operational scenarios (war¯ghting CONOPS only) that demonstrate how a capability or system will be employed, and perceived requirements for operations and experimentation to validate the Fleet CONOPS. Operational CONOPS, however, focus only on capabilities that are to be ¯elded within the FYDP and which have entered latter phases of engineering development. Fleet CONOPS do not address programmatic or technical risks associated with development activities, they do not o®er detailed planning for research and analysis to inform engineering trade decisions, and they do not develop a war¯ghting gap as justi¯cation for a capability (although it may enter the discussion as a necessary context for introducing a new capability to °eet operators). Acquisition CONOPS are developed for MDAPs in satisfaction of the Clinger Cohen Act, and follow a similar format to that of a Fleet CONOPS. However, they di®er signi¯cantly in focus as they are intended to inform the development and
126 B. Herdlick
sustainment of a single system or platform. They identify assumptions to address uncertainty, introduce limitations to address programmatic and technical risk, and identify as constraints any aspects of the problem or solution-space that are considered intractable. Additionally, acquisition CONOPS identify interoperability aspects de¯ned by the existing operational environment (e.g., legacy and soon-to¯eld systems) that must be considered during system design. Unique in an acquisition CONOPS is a discussion of a war¯ghting gap that substantiates a user need and justi¯es the development of a new system. Because an acquisition CONOPS is one document among many mandated for MDAPs, it captures only a small subset of valuable information necessary for technology development and engineering development activities that, in a SoS-based capability, spans multiple systems and platforms. For instance, an acquisition CONOPS need not include a plan for analysis and experimentation activities these are the purview of separate documents such as a test and evaluation strategy, a TEMP, and a modeling and simulation plan. Similarly, an acquisition CONOPS may introduce a functional pro¯le (intended for operational planning and su±ciency considerations), or an environmental pro¯le (a written description of general operating conditions) for the intended system, but it is usually limited in detail and may be augmented by a DRMP. A DRMP or DRM is not required by statute and is not consistently employed across Navy systems commands. It may, however, be employed to augment an acquisition CONOPS with much greater detail on the functions that a system must perform (or have performed on it) and environmental conditions to which it will be exposed during shipping, maintenance and operation. Often presented in a tabular format, the DRMP o®ers a pro¯le of conditions associated with a representative mission that may be referenced for purposes of design. It is perhaps the most well named and tightly focused product introduced in this paper, but its tight focus presents a limitation in application to a SoS-based capability. Speci¯cally, in the context of a MDAP, topics such as a related war¯ghting gap, operational employment considerations, sustainability aspects (e.g., DOTMLPF), programmatic and technical risk, or plans of action for analysis and experimentation are addressed in other documents. Additionally, within a MDAP, the DRMP is developed from the perspective of a single system or platform rather than that of a composite capability achieved through a design that is distributed across multiple platforms or systems. A Concept Proposal precedes logical analysis, technology development and establishment of a MDAP that ultimately delivers an operational system to the war¯ghter. A concept proposal may identify either a war¯ghting gap or an opportunity to achieve a war¯ghting advantage as justi¯cation for considering the development of new systems. The guidance for a Concept Proposal is unique in that it recommends that operational scenarios should address how the system adds value to existing systems and organizations, and what the system(s) will do under boundary conditions and degraded operations (in addition to content otherwise
Establishing an Operational Context for Early System-of-Systems Engineering Activities 127
shared with many CONOPS variants). Since the avenue for delivery of new systems to the war¯ghter predominantly runs through MDAP o±ces,f a Concept Proposal attempts to identify programmatic and development risks that may challenge the transition of a new technology or system to the MDAP(s) responsible for EMD activities, ¯elding and lifecycle support. These topics are not addressed in the development guidelines for acquisition or Fleet CONOPS. Speci¯cally, a Concept Proposal may concern itself with whether the desired capability will work operationally (i.e. it may be technologically feasible and demonstrable, but incredibly complicated and/or di±cult to employ), whether it can be built or developed within reasonable budget and schedule constraints (i.e., a capability that cannot be developed in time to meet a need may be rendered obsolete prior to introduction), whether organizational barriers exist that may preclude successful development and/or ¯elding, and whether the capability will be accepted by the end users and operators (i.e., what con°icts and resistance might complicate adoption of the system or capability). A Concept Proposal also incorporates a plan of action and milestones that identi¯es stakeholders; establishes teams and membership; details requirements for studies, experimentation and demonstration events; re°ects the collection, analysis and presentation of ¯ndings; and highlights resource requirements for near-term activities. A Concept Proposal does not identify a solution (e.g., a technology or a functional decomposition and physical allocation) and is therefore inadequate as a guidance document for technical or engineering development activities. An Operational Concept Description is an industry recognized process and document format that captures many aspects addressed in acquisition and Fleet CONOPS and has latitude to incorporate the content attributed to a DRMP. The guidance for an Operational Concept Description is superior in its detail, especially in its treatment of impacts to the user, acquirer, developer and support agencies during development. Similarly detailed is guidance for addressing supportability aspects, impacts to existing operations and systems, and organizational realignment that might be required roughly equivalent to DoD DOTMLPF considerations. A section dedicated to analysis of the proposed system (i.e., performance characterization) is uniquely suited to the development of SoS-based capabilities in that it focuses on advantages and limitations, as well as alternatives and trade-o®s considered. The Operational Concept Description is also unique in that it calls for functional °ows diagrams, content that o®ers greater technical detail than either acquisition or Fleet CONOPS, and far exceeds the scope and depth of a Concept Proposal.
f Admittedly, this is true even for capabilities achieved through SoS designs, while the constituent
MDAPs may be responsible for the development, modi¯cation and ¯elding of a constituent systems, the development and ¯elding of the SoS-based capability has not been associated with, or assigned to, a single MDAP.
128 B. Herdlick
6. Creating an Operational Context for Early SoS Development Activities In the ¯nal analysis, not one of the documents reviewed here is independently adequate as a means or product for capturing an operational context for development of complex, SoS-based capabilities. They do, however, each have unique and applicable content that can be combined into a new product that is ideally suited for articulating a common operational perspective on an advanced capability. Such a comprehensive vision is required to guide simultaneous concept development, technology development, and engineering/manufacturing development previously identi¯ed as the early Systems Engineering activities associated with exploration and exploitation of the SoS solution space. An enhanced OCD is o®ered as a solution for creating and capturing an operational context for SoS-based capability development e®orts within DoD. The \OCD" title easily distinguishes the new document from the myriad variants of CONOPS already in use, avoiding much of the aforementioned friction and angst associated with documents bearing the \CONOPS" moniker. The OCD recommended in this paper is unique in content and format, but remains true to the de¯nition of an OCD detailed in the Handbook of Systems Engineering and Management and the purpose of an Operational Concept Description presented in the ANSI/AIAA standard. OCD Title and Content: The title of this document OCD derives from industry and U.S. Navy guidance for capturing an operational context for system and capability development activities. An OCD is described in the Handbook of Systems Engineering and Management, as well as ANSI/AIAA G-043-1992. The content of this document has been expanded to adequately address the concept development, technology development and engineering development e®orts that occur simultaneously and iteratively during the exploration and maturation of SoS solutions. Since these SoS-based capabilities may be developed outside the purview of an overarching MDAP, this document incorporates useful information that would otherwise be the purview of other acquisition processes and documentation (e.g., concept proposals, capability-based analyzes, AoA, capability development documents, and acquisition CONOPS among others). OCD Purpose: The OCD is intended as both a framework for collaboration and a knowledge management tool. It should be used to obtain consensus among the acquirer, developer and support and user agencies regarding the operational concept for a proposed SoS-based capability. It is intended to ensure a common understanding of the operational context in which a SoS-based capability is to be employed. The document should serve as a repository for results from performance analysis and engineering trade decisions to provide a foundation for subsequent development of Fleet CONOPS and tactics. It is intended to inform (or re°ect, as appropriate) system and interface speci¯cations and to serve as a reference for the development of operationally representative scenarios for use in model-based development and performance characterization activities such as live demonstrations and/or formal test and evaluation programs.
Establishing an Operational Context for Early System-of-Systems Engineering Activities 129
OCD Relationship to Other Documents: The OCD may leverage existing documentation such as platform-speci¯c CONOPS, tactics techniques and procedures (TTPs), analysis products, requirements documents, trade studies, design reference missions, or technical speci¯cations for system performance. The OCD may serve to align existing documents in the context of a new capability by addressing new interfaces and functions not captured by legacy documentation. The OCD will likely identify new capability-speci¯c requirements that must be satis¯ed by the constituent systems, and will therefore inform and in°uence updates to existing requirements documentation potentially through a common capability-speci¯c annex. The OCD will o®er insight into coordination that must occur to verify capabilities and validate employment concepts for the SoS-based capability. The integration of modeling, simulation, analysis, and test activities across the constituent systems may draw from, or in°uence, existing modeling and simulation (M&S) and test and evaluation (T&E) plans within the associated program o±ces. The OCD will also identify higher-level, integrated functions that require the participation of two or more constituent systems in a build-up approach to a full capability evaluation. While such events should be described in the OCD, a separate integrated T&E planning document at the SoS level will most likely be required to adequately manage the capability characterization activities. SoS-level documents such as a \capability annex" or a \capability characterization plan" are o®ered as prospective companion documents to the OCD, but will not be further developed in this paper. OCD Content and Organization: The enhanced OCD proposed in this paper represents a compilation of relevant content from documents that span concept development, technology development and engineering/manufacturing development activities. The organization of the OCD is outlined below with guidance for content, format, and a notional page count that is intended to necessitate clear, concise language and yield greater utility through readability. Although the page count is a function of the number of systems and employment modes involved in delivering the capability, the 50-page goal was achieved for a capability involving four systems and four employment modes in the ¯rst application of this guidance. Use of appendices is encouraged as a necessary tool for reaching the page limit on the body of the document. Appendices should be a repository for deeper technical and tactical details such as system performance and mission planning considerations. The proposed OCD organization and content for a SoS-based Capability development activity is detailed below. Each recommended section of the OCD derives from one or more of the documents introduced earlier in this paper this information is provided as each section of the OCD is introduced in the outline below. .
Signatures of concurrence/endorsement from program o±ces supplying constituent systems to the SoS, as well as organizations involved in development/ research/analysis activities. Identify author(s) and/or prime integrator responsible for document generation and maintenance. Comments: Not intended to be routed through operational or DoD acquisition channels for approval at service or OSD levels. This document is intended as the product of (and impetus for) a collaborative and rigorous systems engineering e®ort — not a process for authorizing such e®orts. .
Record of Changes Derived from: Naval Aviation Training Operations & Procedures Standardization. Pages: One. Specify by page number and provide a brief description of any changes made to the document after concurrence signatures were secured (i.e., last revision). Identify schedule for regular review and revision. Comments: Changes should be distributed to all constituent program o±ces and supporting organizations. Review and revision is recommended at intervals of no less than 18 months, modi¯ed as necessary to address signi¯cant ¯ndings, engineering trades, etc.
Executive Summary Derived from: Fleet CONOPS. Pages: Four (maximum). Concept/Capability: Two page limit. . . . . .
War¯ghting gap being addressed. Capability proposed. Brief description of SoS solution (identify constituent platforms/systems/ organizations). Critical assumptions/limitations/constraints. Brief review of the timeline for development and ¯elding.
DOTMLPF impacts: Two page limit. .
DOTMLPF considerations are often identi¯ed during complex system integration activities. The OCD can be used as a method for informing stakeholders of implementation and lifecycle support challenges that will ultimately fall to the constituent platforms and systems.
Comments: Information in the executive summary should derive from other portions of the OCD — no new information should be introduced in the Executive Summary.
Establishing an Operational Context for Early System-of-Systems Engineering Activities 131 .
Derived from: Operational Concept Document. Pages: One. Purpose of Document. Title history and precedent. Relationship to other documents. Comments: Wording may be incorporated directly from the paragraphs immediately above.
Mission and Objectives
Derived from: CONOPS (variants). Pages: Eight — two per section, ideally. Mission & Objective. Target Set(s). Threat(s). Current systems/capabilities. .
Description of current capability — NOT the shortfall or war¯ghting \gap".
Comments: This section of the document should serve to provide background for the subsequent section (war¯ghting/capability gap). Liberal use of references is preferred to duplication of information in detail. Only information immediately relevant to the development of the capability (exploration of the SoS design trade space) should be incorporated here — not a full theater/ threat brief. .
War¯ghting Gap Derived from: Concept Proposal. Pages: One. In the context of the previously de¯ned mission/objective, a description of the current or future military PROBLEM for which there is no adequate solution given currently ¯elded or funded capabilities AND/OR an opportunity for signi¯cant advancement in war¯ghting capability that can be achieved through the modi¯cation and integrated application of existing systems. Comments: Reference to applicable Capability-Based Assessments, \trade studies" and other supporting documents is encouraged (if such products are available, and germane to the SoS-based capability being pursued). May include reference to pertinent strategic guidance, and related service-speci¯c or Joint Concepts that also justify the development of the capability.
132 B. Herdlick .
Scope of the Development E®ort Derived from: Concept Proposal. Pages: Two. Intended to constrain the problem and manage expectations/perceptions relative to prospective capabilities and the related solution space. Includes a general timeframe for capability development and ¯elding (by increment, if known). May serve to include or exclude aspects of the problem or solution. Assumptions, Limitations and Constraints that are germane to the development of the SoS-based capability. .
What threats are speci¯cally NOT being addressed by the capability? (some justi¯cation for their exclusion should be o®ered). . What systems or performance is speci¯cally NOT part of the solution space? Comments: This section should also clearly delineate the boundaries of the capability development e®ort. Although the modi¯cation and integration of existing systems can often produce new war¯ghting capabilities that exceed those of the constituent systems — those capabilities will likely ¯eld in increments (a step-wise approach to the complete capability), and performance of the extant systems may constitute a constraint on the engineering trade space that precludes achievement of a \100% solution." Additionally,the asynchronous ¯elding of constituent systems may drive a change to capabilities delivered in any particular increment. Therefore, a minimum set of functions required to achieve a level of military utility in a given increment should be identi¯ed as interim goals (capability development and maturity indicators) during development. .
Derived from: Concept Proposal. Pages: Four. Notional format: Two-Three pages of text and two one-half page pictures. Identify the war¯ghting capability being pursued through a SoS-based solution. Identify SoS constituent platforms/systems and characterize their functions in the context of the SoS-based capability. Identify prospective employment modes (if more than one might exist) that help to frame alternative relationships between platforms/systems and variations on the composite capability delivered through the SoS design. Comment: Emphasize how platforms and systems, acting independently, cannot otherwise achieve the capability. A functional block diagram is encouraged as a method for representing the capability, with physical allocation to SoS
Establishing an Operational Context for Early System-of-Systems Engineering Activities 133
constituent platforms/systems either embedded in the FBD, or captured in a subsequent ¯gure. .
Design Trade Space (Overview)
Derived from: None (Added for SoS-based Capability Development). Reference: Systems Engineering Best Practices. Pages: One per aspect of the trade space. Aspects of trade space may be addressed by constituent systems and interfaces, through roles and information exchanges, and should include critical technical parameters and, if known, associated levels of performance. Deviations from current system functions and performance should be identi¯ed as new \delta requirements". Comments: .
An entire Appendix is dedicated to design trade decisions and another to capability/performance characterization (i.e. test and analysis); therefore, this section should provide an overview only, but should be updated and informed by new information as appropriate. . The level of detail associated with information exchange and system-level \delta requirements"will increase as the SoS solution space is explored. This is necessarily an iterative process for SoS development and will necessitate many updates to this section of the document as engineering trades are made. . Currently ¯elded systems may out-perform MDAP threshold levels identi¯ed in technical speci¯cations. Claiming this performance as fundamental to a new capability constitutes both a \delta requirement" (which should be modi¯ed in the constituent system's requirements documentation) and a programmatic risk that should also be identi¯ed in the \issues and risks"section of this document until properly resolved. .
Operational Scenarios Derived from: Acquisition and Fleet (War¯ghting) CONOPS, Concept Proposal (vignettes). Pages: Three per scenario. Notional format (per scenario): One graphic (one-half page) and Two and onehalf pages of text. Mission/objective for new capability. Mission success criteria. Scenario content (examples; sequence/order as appropriate). .
Prospective employment modes/methods/procedures/sequence. Implied system performance (explicit/derived requirements). . Information exchange, command and control aspects, decision making. .
134 B. Herdlick . . . . . . .
Reference to necessary mission planning or controls and displays (derived requirement). What the system should NOT do (degraded or fail-safe modes). How new system adds value to existing system(s)/organization(s). Operationally accurate (with respect to threat and associated vulnerabilities). How system accomplishes task/mission. Impact of operating environment. How capability will be employed (operator use) ! feeds service exercises and experiments, operational assessments and (if applicable) test and evaluation.
Scenarios SHOULD focus on providing a clear and concise portrayal of how the new capability might be employed, and its war¯ghting merit/military utility. . Scenarios SHOULD NOT attempt to detail the threat and blue-force lay-down for an entire theater, but should provide adequate detail for subsequent development of scenarios for modeling, simulation, test and evaluation purposes. . Scenarios SHOULD NOT duplicate the (amplifying) information provided in other sections of this document, such as functional block diagrams, environmental conditions, etc. .
Derived from: Design Reference Mission Pro¯le. Pages: Two per unique employment mode, as applicable. Notional format: Tables (preferred); outlines, °ow-charts, etc. (optional). A time scale of all unique functions that must be performed on or by the constituent systems to provide support for the SoS-based capability. Comments: .
Should align with previously presented operational scenario(s), and provide much greater detail on required system functionality and performance. . Deviations from current system operation & support pro¯les should be highlighted as \delta requirements." . May make reference to, or be assembled from documentation associated with constituent systems. . If a DRM/DRMP has been developed for the capability,duplication is not recommended (the documents should be compatible and mutually supportive) — however, truly revolutionary capabilities may so advance (or challenge) current system functionality that new pro¯les may be required.
Establishing an Operational Context for Early System-of-Systems Engineering Activities 135 .
Derived from: DRMP. Pages: Two per unique employment mode, as applicable. Notional format: Tables (preferred); outlines, °ow-charts, etc. (optional). A time scale of all unique environments to which the constituent systems will be exposed while providing support/service/functionality to the SoS-based capability. Comments: .
Should align with previously presented operational scenario(s), and provide much greater detail on required system functionality and performance. . Deviations from current system operation and support pro¯les should be highlighted as \delta requirements." . May make reference to, or be assembled from documentation associated with constituent systems. . If a DRM/DRMP has been developed for the capability, duplication is not recommended (the documents should be compatible and mutually supportive) — however, truly revolutionary capabilities may so advance (or challenge) current system functionality that new pro¯les may be required. .
Capability Characterization Strategy
Derived from: None (Added for SoS-based Capability Development). Reference (rough analog): Test and Evaluation Strategy. Pages: Six (one page per topic). Requirements for research and analysis necessary to characterize the performance of the SoS in the context of the desired capability. . . . . . .
Modeling and simulation. System level testing. System integration activities. Operational experimentation. Live demonstrations. Related/additional studies.
This e®ort is unique to the development of a SoS-based capability. This might be viewed as an early approximation of test and evaluation strategy with embedded modeling & simulation. . While early involvement of operational test agencies and T&E commands is both strongly encouraged and critical to the success of the capability development e®ort, it should be stressed and well understood that characterizing the performance of the SoS within the context of war¯ghting gap/operational scenario(sÞ is the purpose of these activities. Initial Operational T&E for the .
136 B. Herdlick
purpose of determining operational e®ectiveness and suitability may have to give way to an Operational Assessment and an Observation of Operational Capability for SoS-based capabilities (this is a topic for future research and innovation). .
Action Plan (Plan of Action and Milestones (POA&M)) Derived from: Concept Proposal. Pages: One per constituent acquisition program, initially, with a goal of a single integrated development schedule. An integrated master schedule (IMS) that spans constituent systems, development and integration e®orts, and all activities related to capability characterization (see above). A priority of recommended changes should be made that identi¯es the achievement of modules or increments of military utility (i.e. \capability worth ¯elding") – a SoS perspective. Comments: Maintaining alignment of the development e®orts being conducted via each of the constituent system program o±ces (and contractors) may constitute the greatest workload and risk associated with a SoS development e®ort. This section of the document will likely demand constant monitoring and re-alignment. Ideally, a lead system integrator (organization or program) may be identi¯ed as responsible for the capability-speci¯c IMS.
Issues and Risks Derived from: Concept Proposal. Pages: One per topic area — about 9 to 10 pages. Expected challenges and obstacles. .
Integration – What interfaces appear to be the most problematic? – How well de¯ned is the functional decomposition and physical allocation? – Is requirements language clear?
Technological – Are technology development requirements well documented? – Can the performance be achieved, and how quickly?
Organizational – Can ¯scal and contractual obstacles be successfully addressed? – Can priorities be assigned/aligned across constituent systems and programs?
Establishing an Operational Context for Early System-of-Systems Engineering Activities 137 .
Stakeholder and User Acceptance – Is the concept/capability well supported? – Will the capability be used, or are other alternatives available/preferred?
Security Environment – Does the proper environment exist? – Can a proper environment be created, and on what timeline?
Information Exchange and Interoperability – What modi¯cations to existing channels and protocols are required? – Are timeliness and accuracy requirements well de¯ned and achievable? – What additional load does the new capability constitute (i.e., bandwidth)? – Are new solutions required?
Development/Modeling, Simulation and Analysis – Can existing models be leveraged, with or without modi¯cation? – What assumptions, limitations and constraints impact their suitability? – What new models, simulations or analysis tools are required?
Demonstration/Live Test – What is the strategy for early T&E involvement, and have the operational test agency and (if appropriate) the Director of Operational Test and Evaluation (DOT&E) accepted the approach as adequate? – Will a capability characterization plan be developed?
– What is required to address necessary changes to doctrine, training, tactics and supportability in response to the introduction of the new capability? Comments: This section is intended to collect initial areas of concern and risk. As the development e®ort proceeds, a more rigorous monitoring/management plan may be more appropriate to ensure that mitigation strategies and resolution e®orts are executed to successful completion. .
Considerations (DOTMLPF) Derived from. Pages: One per topic — about six pages. Topics: .
Doctrine and Operational Paradigm Shift Changes to end-user organization(s)? . Training at the SoS level? . Leadership aspects of SoS employment? .
Comments: As with performance requirements levied on the SoS constituents by the capability, derived requirements for nonmaterial aspects of ¯elding, operations and support must also be considered. Since the development activities for a SoS-based design are usually executed through participating program o±ces and the MDAPs they support, all aspects of DOTMLPF are ultimately distributed as well-necessitating clear articulation and positive communication. .
Appendices Derived from: N/A. Pages: As required. Capability development content may include (but is not limited to). .
Performance Characterization (results of analysis and testing). SoS Design Trade Decisions. . Mission Planning Considerations. . Controls and Displays/Human–Machine Interface. .
Administrative content may include (but is not limited to): .
Terms. Acronyms. . Points of Contact. . References. .
Comments: Appendices should be developed for any information or area of capability development e®ort that would otherwise encumber the main body of the document due to volume and/or level-of-detail. 7. Future Research This paper focused on identifying a method for establishing an operational context for the early systems engineering activities associated with SoS development as it is currently being pursued within the U.S. Navy. The author is currently mapping the content of the proposed OCD to the architecture products in version 2.2 of the DoD Architecture Framework, and ¯nding a high degree of alignment with the new \capability" and \project" viewpoints. Such mutual support is highly desirable. There are a signi¯cant number of opportunities for additional research and innovation in the area of SoS development, management and sustainment. First, T&E in the context of SoS and complex capabilities was identi¯ed in this paper as a related but separate challenge. Although e®orts are underway within the Navy to introduce \capability-based" and/or \mission-based" testing methods, the fact that the National Defense Industrial Association (NDIA) has established a committee to address DoD SoS challenges, and established working groups to address how best to
Establishing an Operational Context for Early System-of-Systems Engineering Activities 139
conduct T&E in the context of SoS, indicates the growing appetite for new solutions in this area. Second, the capture and articulation of SoS-level requirements, to include communication and management of SoS requirements within the U.S. DoD and its constituent services, is another area where innovative solutions might be well received. Finally, should the proposed capability-speci¯c OCD gain broad acceptance, it might be further improved by addressing topic areas normally covered by Technology Transition Agreements, Technology Development Strategies, and similar documents used within the established DoD acquisition process. 8. Summary A detailed operational context is fundamental to the successful development of concepts, technology, and systems. The exploration of the engineering solution space available for the achievement of new war¯ghting capabilities through SoS-based designs is equally dependent on a well-constructed operational context. While conceptof-operations documents are often requested by name, this inaccurately implies a singular de¯nition for CONOPS. The existence of numerous variants of CONOPS, and the organizational pedigree associated with each, can generate disagreement over authorship, ownership, approval authority, and the intended use of the document. Starting with operational and acquisition CONOPS variants, this paper has identi¯ed a number of documents commonly used within the U.S. DoD for capturing the operational context for analysis, system development and employment. A comparison of the content and format associated with each of these documents revealed content that was inconsistent across the documents, but otherwise critical to capturing the operational context during early systems engineering activities. The comparison served to identify the shortfalls of each document in application to the more broad and challenging task of SoS-based capability development as it is practiced in DoD today. A capability-speci¯c OCD was constructed and recommended as a catalyst and framework for SoS development as well as a repository for analysis products and engineering trade space decisions. The content and format of the OCD ensures that it is compatible with subsequent development of CONOPS by either \acquisition" or \°eet" organizations making it a worthwhile investment that supports transition of advanced capabilities to the war¯ghter. The recommended capability-speci¯c OCD may, in fact, be viewed as a superior analog to the \preliminary" CONOPS mentioned (but not further de¯ned or developed) in DoD Instruction 5000.2. Finally, the name OCD distinguishes the product from the many variants of CONOPS, CONEMPS and DRMs currently being applied (or misapplied) throughout DoD, avoiding misperception regarding content, authorship, ownership, and approval authority. References American National Standards Institute/American Institute of Aeronautics and Astronautics, Guide for the Preparation of Operational Concept Documents, ANSI/AIAA G-043-1992 (1992).
140 B. Herdlick
Chairman of the Joint Chiefs of Sta®, Joint Operations Concepts Development Process (JOpsC-DP ), Instruction CJCSI 3010.02B (2006). Chairman of the Joint Chiefs of Sta®, Joint Capabilities Integration and Development System (JCIDS), Instruction CJCSI 3710.01F (2007). Conklin, J. E., Dialogue Mapping: Building Shared Understanding of Wicked Problems (John Wiley & Sons Ltd., 2005), pp. 340. Dahmann, J., Rebovich, G., Lane, J. and Lowry, R., IEEE A&E Systems, 26(1) (2011) 2228. Department of the Air Force and Secretary of the Air Force, Air Force Concept of Operations Development (Instruction 10-2801, Pentagon, Washington, DC, 2005), www.e-publishing. af.mil. Department of Defense, O±ce of the Under Secretary of Defense for Acquisition, Technology and Logistics (USD(AT&L)), Operation of the Defense Acquisition System, DoDI 5000.2 (2008). Department of Defense, O±ce of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems and Software Engineering (ODUSD(A&T)SSE), Systems Engineering Guide for Systems of Systems, Version 1.0. (Washington, DC, 2008). Department of the Navy and Fleet Forces Command (FFC), CONOPS TO DOCTRINE: Shaping the Force From Idea Through Implementation. Fleet CONOPS Guidance Brief (2006). Department of the Navy and Fleet Forces Command (FFC), Fleet CONOPS Writer's Guide, Version 1 (2009). Department of the Navy, O±ce of the Assistant Secretary of the Navy (Research, Development & Acquisition), Technical Brief: Design Reference Mission Pro¯le Development Guidelines, TB # ABM 1002-03 (Pentagon, Washington, D.C., 2002) www.abm.rda.hq.navy.mil. Department of the Navy and O±ce of the Chief of Naval Operations (OPNAV), Navy Concept Generation and Concept Development Program, Instruction 5401.9 (Pentagon, Washington, DC, 2010). Department of the Navy and O±ce of the Chief of Naval Operations (OPNAV), Developmental System Concept of Operations, Instruction 5401.xx (DRAFT) (Pentagon, Washington, DC, 2010). Department of the Navy and Naval Warfare Development Command (NWDC), Guide for Navy Concept Generation and Concept Development Program, Version 1.0 (2010). Department of the Navy and Space Warfare Systems Command (SPAWAR), Data Item Description for Operational Concept Document, DI-IPSC-81430A (2000). Ferris, T., Insight 12(2) (2009) 49. Institute of Electrical and Electronics Engineers, IEEE Guide for Information Technology System De¯nition Concept of Operations (ConOps) Document, IEEE Std 1362-1998 (R2007), (New York, NY, (2007). International Council on Systems Engineering, Systems Engineering Handbook, Version 3.1, Seattle, WA (2007). Lane, J. and Boehm, B., Systems Engineering 11(1) (2008) 8191. National Research Council, U.S. Air Force Studies Board, Pre-Milestone A and Early Phase Systems Engineering: A Retrospective Review and Bene¯ts for Future Air Force Acquisition (2008), http://www.nap.edu/openbook.php?record id=12065&page=78(accessed on 28 March 2011). Sage, A. P. and Rouse, W. B., Handbook of Systems Engineering and Management (John Wiley & Sons, Inc., 1999). Skolnik, F. R. and Wilkins, P. G., Johns Hopkins APL Technical Digest 21(2) (2000) 208216. United Kingdom, Ministry of Defence, Architecture Framework, MODAF M-10-013.
Establishing an Operational Context for Early System-of-Systems Engineering Activities 141
United Kingdom, Ministry of Defence, Acquisition Operation Framework: Capability IntegrationProducts. United Kingdom, Ministry of Defence, MoD Architectural Framework : Concepts & Doctrine Community of Interest Deskbook (Version 1.0) (2005).
Biography Bryan Herdlick is a member of the senior professional sta® at the Johns Hopkins University Applied Physics Laboratory; he assists the Naval Aviation Systems Command with the development of advanced capabilities and complex systems. Bryan is an INCOSE Certi¯ed Systems Engineering Professional with additional certi¯cation in U.S. Department of Defense Acquisition (CSEP-Acq.). Bryan's academic background includes a BS in Electrical Engineering from the University of Dayton and a MS in Applied Physics from the Naval Postgraduate School. He is also a graduate of the U.S. Navy Test Pilot School and a distinguished graduate of the Naval War College. His collateral activities include supporting ABET on accreditation visits as a program evaluator volunteer and teaching Systems Engineering courses for the Johns Hopkins University Whiting School of Engineering.