Figure 15. Operational FCS
The FCS UA, as it has been defined in the FCS ORD, will be unique among military systems. It will be designed, tested and evaluated using simulations and it will have embedded simulations in its operational instantiation. Further, the UA will be unique among commercial systems. It is being created using Boeing's experience with designing the very complex systems that comprise the most modern commercial aircraft; however, it will go beyond a single hardware/software system to include numerous, comparably complex, hardware/software systems in a System of Systems.
6.1. Commonality Requirement
The FCS ORD mandates commonality between simulations and the operational software. This requirement sounds reasonable, if not especially important. However, some investigation reveals that this commonality is of critical importance (consider the experience with the robot simulation, described earlier). In addition, modeling and simulation (M&S) pervades both the operational system and the processes needed to produce the system. For example, M&S is a necessary ingredient of testing and evaluation (T&E), as will be seen in Section 6.4. We begin, however, with two brief sections showing the criticality of commonality in simulation.
6.2. Preliminary Example
FCS is based on a network-centric concept. In a network-centric system, the functionality of the entire system is dependent upon the functionalities of the individual subsystems and components and their interactions. The interactions lead to non-linear effects sometimes referred to as 'emergence' that currently cannot be easily modeled and thus not easily anticipated. Experiments with network-centric approaches have shown that while explicit mathematical models of emergence cannot currently be implemented, simulations that capture interactions of systems elements do show the same emergent behaviors that physical systems display. Thus, any simulation used to represent a network-centric system must capture the impact of element interactions so that the non-linear impact of those interactions can be understood.
Since the elemental composition of a network-centric system will be very dynamic because of the variable nature of the environment and the death rate of system elements (this is combat after all), the interactions of system elements will change with resulting nonlinear impact on the overall system functionality. An example of this is the connection between the degree of communications connectivity and the availability of nodes. Loss of nodes in one situation may have no effect on communication connectivity; whereas, loss of only a limited number of nodes could be catastrophic in other situations. This means that, in a communications simulation, there must be commonality of representations of functionality. Otherwise the system-level performance will not be properly reflected when subsystem and component functionality enters and leaves the overall networked system. If there is no commonality of functional representations where such is needed, then there will be no guarantee that the interactions of the functions will result in representative system level behaviors. Thus it is argued that simulation of network centric systems concepts must represent similar functionality with identically coded functions, if at all possible.
A side benefit of the need for functional commonality to support the analysis of network centric systems concepts is that architectural commonality between the simulated system and proposed physical systems results. This precipitates compliance with the ORD requiring operational commonality so that the physical FCS can be used as a simulation tool for training, garrison operations and mission rehearsal.
Additionally, the resulting commonality between the architectures of the physical and simulated systems enables spiral development. Spiral development means, by definition, that parts of the fielded system are at different stages of maturity. And, that some parts of the FCS UA may be available before other elements. However, as seen below, effective testing of the functionality of a subsystem or component requires that the affects of its interactions with other, possibly unavailable, elements of the FCS UA on overall system performance must be evaluated. If operational commonality exists, spirally developed technologies can interact with models of missing system components to evaluate available technologies within a systems context.
6.3. M&S in Training and Analysis
The bulk of this section is concerned with M&S in support of testing and evaluation; however, a short note on other uses for M&S in the FCS system of systems is important. The FCS ORD calls for on-board simulations to support course of action (COA) analysis and to support training. Training simulations are normally expected to match simulation time to real time; however, analysis simulations must run at large multiples of real time to support multiple executions with a minimum time cost. Even with a lower time budget and much lower resolution than that described for the network system simulation above, training simulations have historically had difficulty in maintaining pace with real time. Analysis simulations have to have restricted scope or even lower resolution to satisfy their time requirements. Either the time requirements or the ORD requirement for operational commonality will have to be sacrificed or the FCS computers will have to be much faster than current computers. Sacrificing the time requirements will make the simulations worthless and while future computers can be expected to be faster, the expectation is not sufficient for this requirement. A different type of commonality will be required.
6.4. M&S in Testing and Evaluation
Test and evaluation of a fully operational system is a complex undertaking; however, it has the advantage of having all of the components and all of the connections among the components in existence. Figure 15 illustrates some significant elements of the operational FCS. Each platform will have an embedded computer, with computer systems, various attached physical sensors, and the vehicle's natural capabilities. The computers will be connected via an operational network, providing connections among the vehicles. This system of systems (SoS) will have various properties that are to be tested and evaluated against the desired properties.
Figure 15. Operational FCS
Prior to Full Operational Capability (FOC), test and evaluation is problematic. Some of the vehicles may not exist, which means that their sensors will not be integrated in final fashion, nor will their computers and systems be integrated. Some of the sensors may not exist. The actual network linking the computers will not exist. As Figure 16 shows, the missing parts will have to be simulated or T&E cannot be performed. Note, not only will the missing hardware have to be simulated, but also the missing integration logic and network connections will have to be simulated.
Figure 16. Developmental version of FCS
The previous figures illustrated benign test scenarios. Such scenarios are adequate for testing and evaluating basic capabilities, such as performing maneuvers and communicating; however, they cannot test the functions for which FCS was designed, the functions that are meant to make the Army superior in conflict with opposing forces, superior in the full spectrum of operations anticipated. The FCS is meant to provide superior intelligence concerning non-cooperative opposing forces, cooperative forces and allow the Army to prevail against or benefit from those forces. Figure 17 illustrates one situation against which the testing must ultimately evaluate.
Figure 17. FOC FCS in real conflict
Even with an operational system, T&E does not introduce the system being tested into real conflict in order to evaluate its worth. Yet another simulation (or set of simulations) is required. The opposing force is simulated. Figure 18 illustrates this simulation, with a developmental FCS. The figure also indicates that an additional simulation is required. This additional simulation is the simulation of tactical and operational decisions by all forces and the adjudication of results. It should be noted that some parts or all of these latter two simulations may be performed by humans in conjunction with computer simulations.
Figure 18. Testing developmental version in simulated conflict
6.5. Pervasive Simulations
Table 4 lists the simulations that are implicit in the discussion above. For each simulation, a brief phrase is used to describe what is being simulated. The final column shows that some of the simulations will not be needed in the operational SoS. However, the logic in the simulations for other parts must be identical to the operational logic.
Table 4. Simulations required for T&E
Further, the complete simulations for (all possible?) opposition forces and (all possible?) conflicts are called out in the ORD as required parts of the SoS. Also, a comparable simulation of own forces is implied for the SoS, but not specified. Such a simulation might not be required for T&E; however, it would be required for course of action (COA) analysis in the operational system. A more complete discussion might discover additional required simulations and would amplify the descriptions of the simulations. Additional information is needed to decide on the parts of the simulations that must be part of the final SoS.
However, some points are obvious:
the number and scope of required simulations for FCS use is large;
As has been mentioned earlier, emergent behaviors or properties of complex systems are a concern. However, before we get too excited about emergent behaviors, we do need to consider what behaviors are possible. Can the system initiate actions or only respond to orders? Does the system control dangerous weapons, heavy equipment, international communications capability, or only something as innocuous as the copy machine? If the answer to the first question is that the system only responds to orders, then one worry is that the emergent properties will degrade the proper responses. However, even in this case, if the answer to the second question contains more than innocuous things, then an incorrect response could lead to dangerous activities. However, it appears that the UA SoS will be required to initiate activities in some circumstances in the absence of human input and it definitely controls dangerous weapons and heavy equipment.
7.1. Degraded Responses
There is the possibility that some emergent behavior may cause the system to function sub-optimally, or even to fail. If this occurs, the consequences to the soldiers in the field can be quite serious. For example, a great deal of localized self-similar communication can be anticipated, which could result in localized loss of connectivity. This, in turn, could cause upsets in the routing, so the routing algorithm needs to be carefully designed in order to avoid instability.
7.2. Computer Initiated Actions
Planned computer initiations of actions are certain to be carefully scrutinized; however, the concern is for unplanned initiations. The linkages within the SoS are going to be immensely complex. The concern is that a human initiated action will start machine actions, which could include inappropriate actions if the linkage logic is wrong. There are certain to be locks that require human initiation for action x; however, suppose that in a cascade of machine controlled actions, that first human action is taken as the initiation for all subsequent actions, rather than requiring additional human initiations.
7.3. Commonality Requirement
The simulations of the systems and SoS must have the proposed real logic (commonality), otherwise the T&E will be irrelevant. Problems must be captured in the simulations (as in the robot swarm example, Section 4.6) before systems are fielded.
Commonality is difficult to grasp because nothing in the technology base could be expected to perform in a truly integrated system of systems. It is difficult to grasp even as we anticipate what our technology base will have operational by 2008. What is expected for SOS performance in this current development is as unlike the current systems in evidence today as the space based telescope from the terrestrial telescope. Because of the unique combination of platform capability, performance expectations, technology foreseen, the concept of a system of systems, net centric warfare, and human performance requirements, the need for accomplished, true, robust integration is the underlying enabler.
Commonality is a hard requirement in two senses. It is not a "nice to have" feature; it is a "must" have feature, or "hard" requirement. Commonality in M&S is a "hard" or difficult requirement to meet. The simulations must be built before the hardware and software is built; it is difficult to have commonality with something that doesn't yet exist. This means that the real hardware and software will have to be built using the simulations as templates and sources of code, which has been the reverse of the usual development process. This means that the simulations will have to be built by a combination of simulation experts and by the individual systems experts and such collaboration has shown to be very difficult to achieve. While this does give Army proponents and systems experts the opportunity to address the above unique combination before "it" is installed in operational equipment, such fundamental changes to the ways this has been addressed in the past, to accommodate lack of understanding or technology maturity in the past, evokes a process of denial which cannot be ignored.
8.1. Implications for FCS Embedded Simulation
FCS appears to have two categories of embedded simulation use, although the distinction may not be clear to some. The first use is employing the operational FCS system itself to simulate actual operations in order to train personnel, conduct various aspects of garrison operations, rehearse, and educate leaders. The second use consists of attached simulations that are used to predict the results of courses of action (COA), enabling selection of the best COA. It is not clear whether the use of FCS to simulate itself will necessarily create any commonality of representation issues.
However, the attached COA simulations will have to satisfy needs and uses far more advanced than today's analytical simulations (as opposed to training simulations). Extremely rapid running will be required (on the order of hundreds of replications per minute for a whole battle sequence). These simulations will be required to model the FCS system, the enemy, neutrals, non-FCS US military, the environment impinging upon the SoS, and allies. These simulations will not be trajectory calculating simulations, as in SIMNET. They will have to work to higher performance standards, but may need higher levels of aggregation than CBS, RESA and AWSIM to achieve the required speeds. (With today's computers, that "may" is a "must;" however, in ten years computer speeds might be adequate.) Note the plural in "COA simulations." To date, no one has adequately achieved a single combat model that is adequate for all levels of resolution. The inclusion of Operations Other Than War (OOTW) and asymmetric warfare modeling in the set of COA simulations, too, is beyond the near future. Commonality of representation will certainly be an issue among these models and between these models and FCS. Note that differences of level of aggregation, unless vastly improved techniques are developed, will make strict commonality impossible; however, the algorithms for the aggregated simulations must rest on the same assumptions and concepts as the finest, operational level algorithms.
8.2. Implication for FCS in General
The majority of the problems cited in the set of lessons by Field Artillery involved either the AFATDS or the ADOCS computer systems, or both. Presumably these problems will have been solved prior to the implementation of FCS; however, they represent the kinds of 'normal' problems that can be expected in complex systems. It could be that if these kinds of problems emerge in the UA system of systems, they too will be addressed. However, it may also be that with regard to a system of systems paradigm, such 'testing in', absent a proactive program to address the root causes, will be intractable.
Some systems are simple enough that all possible pathways through the system for all possible use cases can be enumerated and tested. Exhaustive testing is possible and will ensure that the system works as designed. FCS is envisioned as a system of systems, each of which is much too complex for exhaustive testing on its own, much less permitting exhaustive testing of the permutations and combinations of families of systems or the entire UA SoS pathways. It is unlikely that even 2% of the pathways of the SoS could be tested; but even if 2% could be tested, that would leave 98% of the potential dysfunctional attributes unfound. It will be impossible to test quality into the FCS.
On the other hand, we must allow for the possibility that the forces combining to create a unique cybernetic concept, the FCS UA SoS, will provide for the means by which conformance to performance expectations can be accomplished with their own brand of T&E. If T&E can be constructed to identically address the commonality and uniqueness of a SoS, any one properly exhaustive test will be sufficient.
With or without a new brand of T&E, a different paradigm10 exists and has proved its worth. This paradigm was enunciated in a book by Philip B. Crosby11, in which
The concept is simple, prevent problems before they occur. If lack of commonality is understood to be a potential source of problems in a system, design the system to ensure commonality is enforced in that system's development.
This pathfinder project has just begun to understand the potential in the new paradigm represented in the UA and its technology spin-offs to current forces. The creation of a new paradigm of methodology for design and development assurance through a determination process, and the transition from design to development has also just begun.
1 http://clive.canoe.ca/CNEWSHeyMartha9911/10_metric.html
2 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
3 http://www.uwgb.edu/dutchs/UsefulData/UTMFormulas.HTM
4 Hartley, D. S., III, J. D. Quillinan, and K. L. Kruse. Phase I Verification and Validation of SIMNET-T. K/DSRD-116, Martin Marietta Energy Systems, Inc., Oak Ridge, TN, 1990.
5 Bell, Richard E., et al. Battle Simulation Center Technical Support Plan, K/DSRD-1300, Martin Marietta Energy Systems, Inc., Oak Ridge, TN, 1992.
6 D.A. Schoenwald, J. T. Feddema, and F. J. Oppel, "Decentralized Control of a Collective of Autonomous Robotic Vehicles," Proc. 2001 Amer. Control Conf. (Arlington, VA) June 25-27, 2001.
7 J. T. Feddema, D. A. Schoenwald, E. P. Parker, and J. S. Wagner, "Analysis and Control of Distributed Cooperative Systems," Sandia Report SAND2004-4763, Sandia National Laboratories (2004).
8 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)
9 Mulvenna et.al., "Characteristics and Attributes that affect S/MIME Product Interoperability," National Institute of Standards and Technology.
10 Milliken & Company won the prestigious Malcolm Baldridge National Quality Award in 1989 and the European Quality Award in 1993. Winning these awards was the result of changing a culture of "testing in" quality to one of making quality certain.
11 Crosby, Philip B. Quality is Free, McGraw Hill, Mentor Executive Library, 1979.
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