Return to Hartley's Projects Page | Project Metadata | Keywords | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
This project supported the Future Force Integrated Support Team (FIST) under the Unit of Action (UA) Program, SMART Director. The UA is an implementation of the Army's Future Combat System (FCS). The FIST was formed and organized to address critical technical and analytical challenges that had been identified throughout the earlier Concept Exploration phases of the UA program. The purpose of the FIST Commonality Pathfinder Project has been to determine the impact of problems caused by insufficient exploitation of commonality and to advise on corrective measures.1
Two of the documents produced by the project are represented here. The first, "Costs of Lack of Commonality," describes the problem that faces the FCS. The second, "Successful Design, Development, and Integration of UA SoS," describes the solution path for solving the problem. The executive summaries for the two documents are given below. The links following the executive summaries are to the full papers, each requiring two pages for their content.
As a part of gaining acceptance and understanding of the need for new methods and approaches to complex systems development, this paper points out problems that have occurred when commonality has not been properly exploited. In the process, we arrive at an understanding of why commonality must be understood and the significance of that understanding and exploitation with respect to Battle Command (BC) and the control and integration of complex systems. There are clear parallels between the examples of past problems in BC and warfare and those that can be expected to arise in the development and application of the Future Combat System (FCS) Unit of Action (UA) System of Systems (SoS) for the warfare spectrum of the future. We present examples from:
military and non-military simulations,
training and analysis simulations,
non-simulation, operational computer systems, both military and non-military, and
lessons learned recorded in the unclassified Center for Army Lessons Learned data.
To be sure, commonality exploitation opportunities arise in both simple and in complex systems; however, the more complex the system, the more difficult is the programmatic challenge of identifying and exploiting commonality, as will be seen in these examples.
There is an array of features, functions, processes, steps, and tasks that define the FCS SoS and that are required to exercise the FCS capabilities. These complex characteristics prescribe a unique and perhaps one-of-a-kind cybernetic concept. As a complex system, the UA SoS will almost certainly exhibit emergent properties and behaviors.2 The shaping of the SoS emergent properties and behaviors must be treated as an operational requirement.
The UA SoS is likely to fail, if there is a lack of attention to systems complexity and a lack of exhaustive commonality exploitation. Without attention to understanding the properties of FCS SOS emergence and without attention to exploitation of commonality, stability is compromised. Without extensive commonality exploitation in the modeling and simulation for, for example, test and evaluation, the overall functionality of the operational SoS will be un-testable as an integrated whole and system failures will be intractable. It is extremely important to mention that this M&S commonality is not separate from, but is wholly related to determinations and exploitations completed for operational systems and vice versa.
This paper does not address the methodology required to solve the problems caused by lack of commonality. That is left for another paper [below].3 This paper raises the visibility of battle command problems, both encountered in the past and expected in the future, in light of modern concepts of system complexity and true (system of system) integration. The examples of this paper are intended to illustrate the currency of commonality problems and their relevance to 'spiraling-out' improvements.
This paper concerns complex systems development and after thorough consideration points out that the current state of the art necessitates a conscientious (open and well engaged) mix of both design and development, each consisting of combinations of approaches with commonality determination at the core of the methodology.
Commonality determination is a process that reveals a deeper understanding of how to successfully design, develop and integrate the Future Combat System (FCS) Unit of Action (UA) System of Systems (SoS). Design and development share the responsibility of accomplishing integration so that functionality will not be compromised and missions jeopardized. Where interdependencies exist in the SoS they must be precisely understood. There is an array of features, functions, processes, steps, and tasks that define the FCS SoS and that are required to exercise the FCS capabilities. These complex characteristics prescribe a unique and perhaps one-of-a-kind cybernetic concept. As a complex system the SoS will almost certainly exhibit emergent properties and behaviors.2 The shaping of the SoS emergent properties and behaviors must be treated as an operational requirement.
Commonality exploitation is more than code, or artifact re-use. The complex characteristics of the SoS share commonalities that involve much more than just code. Thus code reuse is merely one by-product of the SoS analysis needed. Exploiting commonality has benefits for the UA SoS that go far beyond the cost savings that are often argued as the major benefit of code re-use. It appears likely that the UA SoS will fail without explicit treatment of commonality in its broader sense, because without exploitation of the SoS commonalities, the SoS capabilities cannot be achieved and undesirable properties will emerge.
Understanding FCS SoS commonality is a difficult challenge. New methods need to be developed for commonality determination. However, determining what commonalities exist is not enough. The commonalities must be exploited and that means assuring their contribution through design and development. We have found that:
Modern systems engineering methodologies are necessary but not sufficient;
Modern systems development is necessary but not sufficient;
Object Oriented approaches work, but only partially for this unique SoS concept; and
The approaches must come together in ways accounting for the risks of novel combinations of methods, design-to-development gap complexity, and commonality determination complexity.
Effective commonality determination, SoS design, SoS development, and assuring that these processes combine to achieve the expected functionality is a new and multi-dimensioned problem, just as is the commonality determination process. This paper offers description and justification of the beginnings of a new paradigm for designing, developing and integrating the UA SoS. This new paradigm rests on the initial pathfinder commonality project's results, which require confirmation. More work is also needed to refine the paradigm.
The UA SoS is likely to fail, due to lack of attention to systems complexity and lack of commonality exploitation, as described in an earlier paper [above].4 Design and development costs will be higher, due to duplication of effort. Maintenance and failure correction costs will be higher, due to multiple occurrences of similar, but not identical code. SoS performance will be slower, due to loose coupling among the interacting systems. The overall functionality of the SoS will be unpredictable at best, because all complex systems have emergent properties. However, no effort will have been made to design and develop for the desired emergent properties in the present methodology, so far as can be determined to date.
1 Unit of Action (UA) Future Force Integrated Support Team (FIST), "Common C4ISR Representation: SMART-Based Progress for UA Modeling and Simulation (FY04 Report)," November 2004
2 An emergent behavior or emergent property is shown when a number of simple entities (agents) operate in an environment, forming more complex behaviors as a collective. A system made of several things can host properties which the things themselves do not have. Emergent processes or behaviors can be seen in many places, from any multicellular biological organism to traffic patterns or organizational phenomena to computer simulations and cellular automata. The stock market is an example of emergence on a grand scale. (Wikipedia, http://en.wikipedia.org/wiki/Wikipedia)
3 "Successful Design, Development, and Integration of UA SoS: Initial Findings from the Commonality Pathfinder Project"
4 "Costs of Lack of Commonality: Initial Findings from the Commonality Pathfinder Project"
If you arrived here using a keyword shortcut, you may use your browser's "back" key to return to the keyword distribution page.
Return to Hartley's Projects Page