UAST * and Evolving Systems of Systems in the Age of the Black Swan Part 1: Class 1 and Class 2 Agile System Concepts

1. UAST * and Evolving Systems of Systems in the Age of the Black Swan Part 1: Class 1 and Class 2 Agile System Concepts “The overall concept of operations for UAST must […be] an evolutionary model that takes into account the rapid advancement of technology development in UAS. In aggregate, the UAS technology sector advantage is manifesting on a time scale of 2-4 months for next generational improvements.DoDI 5000.2 E 12.7 states, ‘Program managers shall employ a Modular Open Systems Approach (MOSA) to design for affordable change, enable evolutionary acquisition, and rapidly field affordable systems that are interoperable in the joint battle space.’ BAA UAST0002, A-4 UAST Concept of Operations, p 54. Excerpts from a presentation atUAST Tutorial Session, ITEALVC Conference,12 Jan 2009, El Paso, TX. * UAST: Unmanned Autonomous Systems Test

2. A Note on Black Swans • The Black Swan metaphor is used currently to signify a low probability but catastrophic event. Popular usage emphasizes this low probability. • What is ignored in many examples of recent black swan eventsis that they have been enabled by situational evolution, andwill occur with increasing frequency. • It is accurate to see them as unprecedented…having rarely if ever occurred before. • It is inaccurate, in many cases,to think they are equally unlikely to occur again. • Contributing elements of situational evolution: • Globalism, ubiquitous networks, technological literacy, empowered individuals, 4th and 5th generation warfare, complex interconnected systems, … read: Nassim Nicholas Taleb, The Black Swan, Random House, 2007 see: www.charlierose.com/view/interview/9713

3. Unmanned (Autonomous) Systems

4. Weight 3 grams. 10 cm tip-to-tip. Speed 5 m/sec. Flies 3 mins on 1 gram battery. Dragonfly-like Micro Air Vehicle (MAV) July 2008 www.delfly.nl/?site=DIII&menu=media&lang=nl 0.4 gram camera and transmitter of the DelFly micro

5. World's Largest Truck Goes Robotic http://dsc.discovery.com/news/2008/11/06/monster-robot-truck.html • Nov. 6, 2008 -- The largest truck in the world is about to become the largest robotic vehicle in the world. • Computer scientists from Carnegie Mellon University have teamed up with engineers from Caterpillar to automate the 700-ton trucks, which are made to haul loads up to 240 tons from mines. • That's nearly two million pounds of metal, fuel and stone powered by a 3,550-horsepower, 24-valve engine moving at up to 42 miles per hour, with software and a robot at the wheel. Fully automated mining trucks promise to reduce maintenance costs while increasing productivity. By running at peak capacity 24 hours a day, seven days a week, the trucks could be up to 100 percent more productive (Hack these and send an army of them on your own mission – a James Bond plot?)

6. Problems to Address in UAS Test • Situation… • UAS technology advancement is accelerating on a broadening front. • UAS technology is becoming truly autonomous. • Impatient demand for replacing the human in harm’s way. • Testing must deal with… • Behaviors of lethal UAS that interact with their environment. • Groups that will cooperate on joint missions (swarms/teams/etc). • Groups composed of different types/technologies/ages . • Very large groups. • Ensuring safety of testers and test facilities. • Ensuring safety of surrounding communities and properties. • Expected emergent behaviors – these are necessary and hopefully good. • Expected unintended consequences – these are inevitable and may be good. • Completion in 60 days or less, or the warfighter will use it untested.

7. Increasing Gap BetweenNeed and Capability situation complexity cut-over requirements established for gen n+1 requirements established for gen n+2 develop capability complexity effectivenessgap sysgenn+2 ROI failure systemgenerationn+1 neverquite goodenough systemgenerationn over designed initially Time

8. Defining Agility and Migration Using the term as intended in the 1991 OSD funded Lehigh study and subsequent research: • Agility is effective responseunder conditions of uncertainty There are at least three components to agility: • situational awareness, • decisive choice making and • the ability to respond The latter aspect is what we deal with here Migration is the crossing of a changein basic infrastructure, be it technical, organizational or strategic.

9. Contemporary Context Next-generation challenges are demandingnew architectures… • Force Transformation is the U.S. military’s response to next-generation warfare • Service Oriented Architectures is Enterpriseresponse to next-generation competition Significant in both is the objective of a change that enables future change Instead of perpetuating the scrap and replace cycle, an architecture is envisioned that facilitates migration through successive next generations

10. * RAP – 7 Thought-Guiding Frameworks • Response requirements categories (4 reactive and 4 proactive elements): Reactive: correction, variation, expansion, reconfiguration Proactive: creation, improvement, migration, modification • Response performance metrics (4 elements): Response: cost, time, quality, scope • Response-enabling design principles (10 elements): • Encapsulation, Compatibility, Reusability, Redundancy/Diversity, Scalability, Distributed, Loose, Deferred Commitment, Self-Organizing, Evolving Standards • Design quality principles (3 elements): Requisite Variety, Parsimony, Harmony • An overarching architectural philosophy (3 elements): Reusable modules Reconfigurable in a Scalable architecture (RRS) • System integrity responsibilities (4 elements): Module Inventory, System Re-configuration Module Evolution/Mix, Infrastructure Evolution • An architectural conceptual pattern: Drag-and drop modules in a plug-and-play infrastructure *RAP: Response Ability Principles

11. RAP – 7 Thought-Guiding Frameworks • Response requirements categories (4 reactive and 4 proactive elements): Reactive: correction, variation, expansion, reconfiguration Proactive: creation, improvement, migration, modification • Response performance metrics (4 elements): Response: cost, time, quality, scope • Response-enabling design principles (10 elements): • Encapsulation, Compatibility, Reusability, Redundancy/Diversity, Scalability, Distributed, Loose, Deferred Commitment, Self-Organizing, Evolving Standards • Design quality principles (3 elements): Requisite Variety, Parsimony, Harmony • An overarching architectural philosophy (3 elements): Reusable modules Reconfigurable in a Scalable architecture (RRS) • System integrity responsibilities (4 elements): Module Inventory, System Re-configuration Module Evolution, Infrastructure Evolution • An architectural conceptual pattern: Drag-and drop modules in a plug-and-play infrastructure current focus

12. Proactive Response Categories Domain Definition and General Issues General Characteristics Creation (and Elimination) Make or eliminate something. Issues are generally involved with the development of something new where nothing was before, or the elimination of something in use. Proactive changes are generally triggered internally by the application of new knowledge to generate new value. They are still proactive changes even if the values generated are not positive and even if the knowledge applied is not new – self initiation is the distinguishing feature here. A proactive change is usually one that has effect rather than mere potential; thus, it is an application of knowledge rather than the invention or possession of unapplied knowledge. Proactive change proficiency is the wellspring of leadership and innovative activity. Improvement Incremental improvement. Issues are generally involved with competencies and performance factors, and are often the focus of continual, open-ended campaigns. Proactive Migration Foreseen, eventual, and fundamental change. Issues are generally associated with changes to supporting infrastructure, or transitions to next generation replacements. Modification (Add/Sub Capability) Addition or subtraction of unique capability. Issues are generally involved with the inclusion of something unlike anything already present, or the removal of something unique. From: Response Ability – The Language, Structure, and Culture of Agile Enterprise

13. 4 Integrity Responsibility Elements • The “active” parts of the infrastructure • System assembly: Assembly of modules into on-demand system configurations suitable for addressing unique response needs (unit tests, UAS swarm tests, heterogeneous UASoS tests). • Module inventory: Maintaining ready-for-use sufficient inventory of modules (testing people, test procedures, test monitors, reusable test suites, etc) • Module evolution/mix: New module addition and upgrade as new capabilities are needed (new tester skills, new test modules, new test procedures, new test equipment, etc) • Infrastructure evolution: improvements to existing rules and standards, new rules and standards, elimination of obsolete rules and standards, etc. The “passive” parts of the infrastructure are the interoperability standards

14. Agile System: Class 1Reconfigurable architectural concept pattern: drag-and-drop, plug-and-play (UAST) Drag-and-Drop Reusable Components personnel tests equipment DoD ranges sensors

15. Agile System: Class 1Reconfigurable architectural concept pattern: drag-and-drop, plug-and-play (UAST) Drag-and-Drop Reusable Components personnel tests equipment DoD ranges sensors Examples of Typical Reconfigurable/Scalable System Configurations Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

16. Agile System: Class 1Reconfigurable architectural concept pattern: drag-and-drop, plug-and-play (UAST) Drag-and-Drop Reusable Components personnel tests equipment DoD ranges sensors Examples of Typical Reconfigurable/Scalable System Configurations High Level Arch Plug-and-Play Evolving Passive Infrastructure Rules/Standards/Principles Training Stds Security Stds Safety Stds Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

17. Agile System: Class 1Reconfigurable architectural concept pattern: drag-and-drop, plug-and-play (UAST) Drag-and-Drop Reusable Components personnel tests equipment DoD ranges sensors Plug-and-Play Evolving Active Infrastructure Responsible-Party Designation System assembly: Who? Examples of Typical Reconfigurable/Scalable System Configurations High Level Arch Plug-and-Play Evolving Passive Infrastructure Rules/Standards/Principles Training Stds Security Stds Safety Stds Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

18. Agile System: Class 1Reconfigurable architectural concept pattern: drag-and-drop, plug-and-play (UAST) Drag-and-Drop Reusable Components personnel tests equipment DoD ranges sensors Plug-and-Play Evolving Active Infrastructure Responsible-Party Designation Component inventory: Who? System assembly: Who? Examples of Typical Reconfigurable/Scalable System Configurations High Level Arch Plug-and-Play Evolving Passive Infrastructure Rules/Standards/Principles Training Stds Security Stds Safety Stds Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

19. Agile System: Class 1Reconfigurable architectural concept pattern: drag-and-drop, plug-and-play (UAST) Drag-and-Drop Reusable Components personnel tests equipment DoD ranges sensors Component mix: Who? Plug-and-Play Evolving Active Infrastructure Responsible-Party Designation Component inventory: Who? System assembly: Who? Examples of Typical Reconfigurable/Scalable System Configurations High Level Arch Plug-and-Play Evolving Passive Infrastructure Rules/Standards/Principles Training Stds Security Stds Safety Stds Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

20. Agile System: Class 1Reconfigurable architectural concept pattern: drag-and-drop, plug-and-play (UAST) Drag-and-Drop Reusable Components personnel tests equipment DoD ranges sensors Component mix: Who? Plug-and-Play Evolving Active Infrastructure Responsible-Party Designation Component inventory: Who? System assembly: Who? Infrastructure evolution: Who? Examples of Typical Reconfigurable/Scalable System Configurations High Level Arch Plug-and-Play Evolving Passive Infrastructure Rules/Standards/Principles Training Stds Security Stds Safety Stds VR Immersion Stds Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

21. Agile System: Class 2Reconfiguring architectural concept pattern: drag-and-drop, plug-and-play (UASoS) Drag-and-Drop Reusable Components UAS mission coordination tasks sensors Component mix: What? Plug-and-Play Evolving Active Infrastructure Systemic Regulation Component inventory: What? System assembly: What? Infrastructure evolution: What? Examples of Typical Reconfigurable/Scalable System Configurations Engagement Stds Plug-and-Play Evolving InterOp Passive Infrastructure Rules/Standards/Principles Cooperation Stds Behavior Stds Comm Stds Ethical Stds Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

22. Multi-Range UAS Testing System (highly stylized architectural concept pattern) From: Embedding Agile Security in Systems Architecture, 2008. INSIGHT 12(2):14-17, INCOSE www.parshift.com/Files/PsiDocs/Pap090701Incose-EmbeddingAgileSecurityInSystemArchitecture.pdf As an emergent property security does not come in a separate box, e.g., personnel are security trained, equipment is self-secure. UAST Program Manager component mix: 1 Four active responsibilities, each with embedded security personnel as integrated collaborative team members. procedures tests personnel test equip ranges …et al. sensors Range Master component inventory: 2 Test Manager test sys assembly: 3 UAST Program Manager infrastructure evolution: 4 sub-sys test full system test swarm system test Test system assembly is constrained by test configuration standards informed by security policy. active passive INFRASTRUCTURE security policy 5 Security policy informs all other passive infrastructure standards, and evolves simultaneously with each. HLA interop stds test config stds safety stds UAS policy/stds indicative configurations of test varieties Security is embedded in architecture at points 1-5. Additionally, encapsulated components have internal security distrustful of other components in general.

23. “On How Agile Systems Gracefully Migrate Across Next-Generation Life Cycle Boundaries” www.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf Crossing Next-Generation Life Cycle Boundaries for Home Entertainment Technology Migration Modules Integrity Management signal tuners content sources (TIVO,P2P) speakers playback units (tape, CD, DVD) ) video displays (TV, computer) amplifiers Mfgrs Component mix: Stores Component inventory: User/Owner System assembly: Industry Assocs Infrastructure evolution: Active Infrastructure Passive Video media Audio tape Net in/out Physical connection Analog interconnect Power Video/Surround Rules/Standards Digital/Internet ‘90s roughly… ‘40s/’50s ‘00s

24. “On How Agile Systems Gracefully Migrate Across Next-Generation Life Cycle Boundaries” www.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf Crossing Next-Generation Life Cycle Boundaries for Internet Protocol Migration Modules Integrity Management filters (eg IDS, Firewall) appliances (eg, xml) DNS Servers switches end points, NICs, NOMs routers Vendor Community Component mix: Vendor Community Component inventory: Subnet Owners System assembly: IETF Infrastructure evolution: Active Infrastructure IPv6 era IPv4 era NCPera Passive NCP Wire standards TCP/IPv4 Wireless stds Rules/Standards Optical stds IPv6 ’80s/’90s rough operational start… ’70s ’00/’10s

25. Lessons from Home Entertainment and Internet Migration • Both employ strict capabilities-based encapsulation. This is necessary, and facilitates migration by enabling functional swap-out, upgrade, and retirement independently and asynchronously. • Both employ a stable passive infrastructure of form-and-content interconnect standards, which is structured to facilitate open-ended augmentation over time with both additional and alternate-option standards. This is necessary, and facilitates migration enabling capability and capacity additions. • Both employ an active infrastructure of stable responsibilities for the evolution of both components and passive infrastructure. This is necessary, and facilitates migration by sustaining controlled evolution.

26. Relating Home Entertainment and Internet Agile Migration toForce Transformation and SOA Initiatives • The difference between a Class 1 and Class 2 RAP-based agile system is centrally-controlled sustainment vs. self organizing sustainment. • In Class 1 systems specific people with centralized sustainment responsibilities can be named, in Class 2 systems sustainment is caused by the equilibrium-seeking self-reorganization of decentralized interactions among autonomous agents. • Home Entertainment fits more a Class 1 profile – the owner that configures systems very centrally controls the system configuration, and has little effect or influence on owners of other Home Entertainment systems. • Internet Protocol fits more a Class 2 profile – there is a greater degree of coupling between the migration-deciding agents. As subnets opt for IPv6 profiles, other interconnected subnets may become shunned for services of lesser security or less optimal interaction. • SOA and Home Entertainment environments share a characteristic that may be useful in guiding SOA adoption plans. Both occur in relative isolation to their greater communities, and resemble a Class 1 agile system. • Force Transformation, on the other hand, has an environmental profile more like the Internet Protocol model. Both have sizable sub-groups with interdependent couplings – looking somewhat like an ecological system in the large. (demonstrating domain independence of principles)

27. Force Transformation (demonstrating domain transference of principles) Force Transformation is a massive undertaking, on many functional fronts within each military force as well as across the many independent but interdependent military forces of Army, Navy, Air Force, Marines, and Coast Guard. Force Transformation is predicated on developing far more intimate interoperability than currently exists. The magnitude of the effort necessarily requires an asynchronous adoption for economic, cultural and technological reasons as a minimum – without any disruption of capability. The military has a tradition of controlled mandated actions that may not serve well in either the initial adoption or the subsequent continual evolution intended. The model of Internet Protocol migration that relies on pulling self-organized adoption with enticing benefit, rather than forcing a change that may be incompatible with the reality of the status quo, might well provide both economic and speed-of-adoption advantages.

28. SOA Adoption (demonstrating domain transferrence of principles) Adoption and subsequent migratory evolution of SOA within an enterprise is largely a local (enterprise) decision, with little interdependence on when and what other enterprises choose to do. Though enterprises are increasingly networked to each other electronically as well as strategically, SOA is largely an internal infrastructure for enterprise IT support of business practices. Perimeter gateways of various types are standard methods for reconciling inter company transactions. The nature of the SOA infrastructure nevertheless must conform to greater community common/universal standards if maximum and sustainable access to component services of benefit are to be realized. This raises a cautionary flag on brand-unique infrastructure employment, as well as enterprise- or brand-unique service interfaces.

29. Domain Independent Principles Can Inform UAST ConOps system • Systems in Context Class 2 (federated?) testing enterprise Class 2 systems under test environment (an ecology) Politics Technology Govt Procedures Mil procedures Military reality Competitors Enemies systems Class 1 testingsystem(s) UAST UASoS systems

30. Relating Agile Development to Agile Operationswww.parshift.com/Files/PsiDocs/Pap080404Cser2008DevOpsMigration.pdf PerceivedEffectiveness 100% In-agile system Agile system would continue ROI, but does age, and can suffer strategy-lapse integrity failure Development Development Operation Time Delivery life-cycle end Agile Systems Gracefully Migrate Across Next-Generation Boundarieswww.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf Module MixModifications InfrastructureMigration PerceivedEffectiveness 100% agile system Development Gen 1 Operation Gen 2 Operation Time Delivery