Presentation on theme: "Systems Engineering for Systems of Systems"— Presentation transcript:
1 Systems Engineering for Systems of Systems Dr. Judith DahmannThe MITRE Corporation
2 What are the implications for SE? SoS SE ChallengeUS DoD builds and fields large systems employed to support Joint and Coalition operationsConceived and developed independent by Military ServicesAcquisition (and SE) on a system by system basisFocus of DoD investment shifting to broad user capabilities implemented in a networked environmentMix of material and non-material assets which must work together to meet capability objectivesIndividual systems are no longer considered as individual bounded entities and are evolved based on extant capabilitiesComponents in larger, more variable, ensembles of interdependent systems which interact based on end-to-end business processes and networked information exchangeIncreasingly SoS of various types proliferate despite continued focus on individual systemsWhat are the implications for SE?
3 DoD System of Systems SE Guide Effort led by the Office of the Secretary of DefenseCollaborative Approach with DoD, Industry, AcademiaPurpose6 month effort addressing areas of agreement across the communityFocus on technical aspects of SE applicable across SoS management constructsVehicle to capture and debate current SoS experienceAudienceSoS and Program Managers and Lead/Chief EngineersSoS Guide Version .9Develop ‘Boots on the Ground’ basis for Version 1.0Structured reviews with practitionersRefine early draft guide content, identify areas for future studyUpdate findings and release Version 1.0Draft released for comment December 2007~600 comments received in February 2008 (Industry, FFRDCs, Gov’t)Revision reviewed by Senior SE leadership in July 2008Final release in August 2008Version 1.0
4 What does SoS Look Like in the DoD Today? Typically an overlay to ensemble of individual systems brought together to satisfy user capability needsAre not new acquisitions per seCases like FCS are extremely rare and, in practice, still must integrate with legacy systemsSoS ‘manager’ does not control the requirements or funding for the individual systemsMay be in a role of influencing rather than directing, impacts SE approachFocus of SoS is on evolution of capability over timeA functioning SoS takes start-up time but, in steady state, seems well-suited to routine incremental updatesTend to be ongoing efforts to satisfy user capability needs through an ensemble of systemsMay be no clear ‘completion’, blurring sustainment and developmentAre not new acquisitions per seCases like FCS are extremely rare and, in practice, still must integrate with legacy systemsTypically SoS is an overlay, evolving, or enveloping, individual systemsSoS ‘manager’ typically does not control the requirements or funding for the individual systemsMay be in a role of influencing rather than directing, impacts SE approachFocus of SoS is on evolution of capability over timeEnhancing the way current systems work togetherAnticipating change in internal or external effects on SoSAdding new functionality through new systems or changes in existing systemsEliminating systems or re-engineering systems to provide better, more efficient capabilityA functioning SoS takes start-up time but, in steady state, seems well suited to routine incremental updatesOwnership and synchronization issues, contractual issues, trust, time/bandwidthMost military systems are part of an SoS operationallyOnly by exception do we manage and engineer at SoS level
5 SoS SE Guidebook focuses on ‘Acknowledged’ SoS DefinitionsSoS: A set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities [DoD, 2004(1)].Accepted Taxonomy of SoS [Maier, M. 1998]DirectedSoS objectives, management, funding and authority; systems are subordinated to SoSCollaborativeNo objectives, management, authority, responsibility, or funding at the SoS level; Systems voluntarily work together to address shared or common interestVirtualLike collaborative, but systems don’t know about each otherUS DoD Pilots identify a new SoS type:AcknowledgedSoS objectives, management, funding and authority; however systems retain their own management, funding and authority in parallel with the SoSSoS SE Guidebook focuses on ‘Acknowledged’ SoS
6 Characteristics of Acknowledged SoS Top-down direction for an SoS capability concurrent with independent direction and autonomy in system operation and developmentMultiple levels of objectivesMultiple management authorities with independent priorities, funding and development plansMultiple technical authoritiesMuch of SoS functionality is in extant capabilities of the systemsSoS manager and SE do not have control over all the parts of the SoSIn fact, they may not be aware of all the systems which may impact their objectives and both the systems and the objectives may change over time.Why not directed? Not many, bulk are acknowldgedCollaborative and Virtual – No SoS SE teams to work with
7 Management of Acknowledged SoS Independent, concurrent management and funding authority pose management issuesIn defense, a solid governance & management approach is seen as key for SoSIndependent authorities are unlikely to accept direction from a systems engineer they do not controlArgue to make ‘acknowledged’ into ‘directed’ made difficult by ‘multi-mission’ systems which are important to multiple SoSBeyond defense ‘acknowledged’ SoS exist and evolve without top down managementSystems or services are designed to be broadly useful and have as their business objective to support numerous user applicationsThey naturally retain authority over decisions regarding their development and are not likely to agree to limit themselves to one specific customerIndependent, concurrent management and funding authority pose management issuesOverlapping authority over decisions, Need to coordinate inter-program activities, Manage agreements among multiple PMs as stakeholders who do not have a vested interest in the SoSIn defense, a solid governance & management approach is seen as key for SoSIndependent authorities are unlikely to accept direction from a systems engineer they do not controlBeyond defense, however, ‘acknowledged’ SoS exist and evolve without top down managementSystems or services are designed to be broadly useful and have as their business objective to support numerous user applicationsThey naturally retain authority over decisions regarding their development and are not likely to agree to limit themselves to one specific customerTypically attention is focused on management rather than the technical implications for SE (e.g. make acknowledged SoS directed)Unfortunately, the fact that many systems play a role in multiple SoS makes this is particularly difficultManagement issues have technical implications for SE
9 SE Model for SoS Based on 7 Core Elements of SoS SE TranslatingcapabilityobjectivesNewSoS SEroleAssessing(actual)performanceto capabilityobjectivesOrchestratingupgradesto SoSPersistentSoS overlayframeworkUnderstandingsystems &relationships(includes plans)Developing,evolving andmaintainingSoS design/archDeveloping& evolvingSoSarchitectureAddressing newrequirements& optionsAddressing& solutionoptionsSoSupgradeprocessExternalinfluencesMonitoring& assessingchangesExternal Environment
10 SE Processes Support Core Elements DoD Defense Acquisition Guide presents 16 basic SE processesIn an SoS, SE team adapts these processes to execute core SE elementsFocus for SoS SE is on technical management since implementation is in systemsSoS SECore ElementsRqtsDevelLogicalAnalysisDesignSolutionImplementIntegrateVerifyValidateTransitionDecisionTechPlanningAssessRqts MgtRisk MgtConfigMgtData MgtInterfaceTranslating CapabilityObjectivesXUnderstanding Systems& RelationshipsAssessing Performance toCapability ObjectivesDeveloping & Evolvingan SoS ArchitectureMonitoring and AssessingChangesAddress Requirements &Solution OptionsOrchestrating UpgradesTechnical ProcessesTechnical Management ProcessesTranslating capabilityobjectivesUnderstanding systems& relationshipsAssessing performanceTo capability objectivesDeveloping & evolvingSoS architectureMonitoring & assessingchangesAddressing requirementsand solution optionsOrchestrating upgradesto SoS
11 Core Elements of SoS SE (1 of 3) Translating SoS capability objectives into high level requirements over timeSoS objectives based on broad capability objectivesSE team plays strong role in establishing requirements and understanding dynamics of the environmentTranslatingcapabilityobjectivesIdentifying and understanding the systems that impact SoS objectivesFocus on components and dynamics vs boundariesExtends beyond technical to broader context of management, organizational, development plans, funding, etc.Understandingsystems &relationships(includes plans)Monitoring& assessingchangesAnticipating and assessing impacts of potential changes on SoS performanceGiven scope of SoS authority, key to SoS SE is identifying and addressing changes in systems and other areas (e.g. threat) which may impact the SoS
12 Core Elements of SoS SE (2 of 3) Developing and evolving SoS architectureThis includesConcept of operationsSystems, functions and relationships and dependencies, both internal and externalEnd-to-end functionality, data flow and communications within the SoS.Provides the technical framework for assessing options and implications for meeting requirements over timePersistence, tolerance for changeDeveloping,evolving andmaintainingSoS design/archDeveloping& evolvingSoSarchitectureAn architecture is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE Std and DoDAF).The architecture of an SoS is a persistent technical framework for governing the evolution of an SoS over time.
13 Core Elements of SoS SE (3 of 3) SoS requirements and solution optionsRequirements addressed at both SoS & systemsRecommend SoS requirements based on both priority and practicalitySoS and system SE teams identify and assess optionsResult is plan for development for next incrementAddressing newrequirements& optionsAddressing& solutionoptionsOrchestratingupgradesto SoSOrchestrating SoS UpgradesUpgrades implemented by systems under system SE teamsSoS SE team plans, facilitates, integrates and tests upgrades to the SoSDevelopment based on incremental approaches (bus stop, wave) which accommodate asynchronous system developmentsAssessing(actual)performanceto capabilityobjectivesAssessing SoS PerformanceBased on measures of SoS user results applied in different settings (test, exercises, M&S, operations)Opportunity to identify changes and emergent behavior
14 View of SoS Upgrade (1 of 2) Assessingperformanceto capabilityobjectivesFor each incrementRecommendrqts for thisincrementIdAssess SoScapabilitiesand limitationsAddressing newrequirements& optionsAddressing& solutionoptionsOrchestratingupgradesto SoSIdentifycandidatesystems tosupportfunctionsValidate setsof systemsSoSAssess optionsVerify setsof systemsNegotiatewith systemsIntegrate setsof systemsDevelop planCoordinate, monitor and facilitate systems’development, test and evaluationSystems
15 View of SoS Upgrade (2 of 2) UnderstandingSystems &relationshipsDeveloping& EvolvingSoSArchitectureTranslating Capability ObjectivesMonitoring & Assessing ChangesAssessing SoS PerformanceOrchestratingupgradesto SoSAddressing newrequirements& optionsAddressing& solutionoptionsSoSSystemsMultiple, possibly concurrent increments
16 Guide Extract Relationships Among the Core Elements
17 Guide Extract: SE Processes Supporting Each SoS SE Element Technical or Technical Management ProcessRelationship to SoS SE Core ElementLogical Analysis is the process of obtaining sets of logical solutions to improve understanding of the defined requirements and the relationships among the requirements (e.g., functional, behavioral, temporal).Logical Analysis is a key part of Understanding Systems and Relationships. Basic to engineering an SoS is understanding how systems support SoS functionality. In developing a new system, the systems engineer allocates functionality to system components based on a set of technical considerations. In an SoS, the systems engineer develops an understanding of the functionality extant in the systems and how that functionality supports SoS objectives, as a starting point for SoS architecture and evolution. …Risk Management … helps ensure program cost, schedule, and performance objectives are achieved at every stage in the life cycle and to communicate to all stakeholders the process for uncovering, determining the scope of, and managing program uncertainties.Risk management is a core function of SE at all levels. In Understanding Systems and Relationships, the systems engineer assesses the current distribution of functionality across the systems and identifies risks associated with either retaining the status quo or identifying areas where changes may need to be considered. The systems engineer also considers approaches to monitor, mitigate, or address risks. Such risks might include …Configuration Management is the application of sound business practices to establish and maintain consistency of a product's attributes with its requirements and product configuration information.Understanding Systems and Relationships is where the CM process for the “as is” SoS resides and is maintained as the SoS product baseline. In a system the CM process addresses all of the ‘product’s’ features where the system itself is the product. In an SoS, the ensemble of systems and their functionality is the product; the SoS CM depends on the CM of the systems to maintain much of the product information, since the system owner, PM, and system systems engineer normally retain responsibility for their systems. The SoS CM focuses on the linkage to the system CM and crosscutting attributes which pertain to the SoS not addressed by the CM of the systems….
18 What is Working? SoS SE Principles Address organizational as well as technical perspectivesFactor in broader set of consideration into trade space and technical planningFocus on areas critical to the SoSLeave the rest to the systems engineers of the systemsTechnical management approach reflects need for transparency and trust with focused active participationSoS designs are best when open and loosely coupledImpinge on the existing systems as little as possibleAre extensible, flexible, and persistent overtimeContinuous (‘up front’) analysis which anticipates changeDesign strategy and trades performed upfront and throughoutBased on robust understanding of internal and external sources of changeMust address organizational as well as technical perspectivesFoster relationships among the owners and SE of the systems (people)Technical understanding of systems functionality, interrelationships & dependenciesSoS trades factor in objectives, motivations and plans of systemsSoS SE focuses on areas critical to the SoSSE processes applied to SoS issues: CM, Test, Risk, Data…SoS Integrated Master Schedule (IMS) focuses on key synchronization (intersection) points and dependenciesLeaves the rest (as much as possible) to the SEs of the systemsSoS technical management approach reflects need for transparency and trust with focused active participationNot sustainable for all systems to participate in all SoS IPTs in steady stateSoS designs are best when open and loosely coupled, ie.:Impinge on the existing systems as little as possibleProvide systems maximum flexibility to address changing needs of original users and applying technology best suited to those needsAre extensible, flexible, and persistent overtimeAllow the addition or deletion of systems and changes in systems without affecting other systems or the SoS as a wholeContinuous (‘up front’) analysis which anticipates changeDesign strategy and trades performed upfront and throughoutBased on robust understanding of internal and external sources of change
19 Way Ahead Guide is out and in use, offers a first step Highlights the issues of SoS in DoD todayProvides some support for SE teams operating in SoS todayPlan for outreach and educational materialsAssess added guidance for areas such as Systems Engineering PlansEfforts are underway to support update to the guideA follow-up data collection to get an understanding of ‘how to’ level of information from ongoing SoS SE effortsCooperative effort with NDIA M&S Committee to examine promise and experience with M&S to support SoS SESeries of industry exchanges on SoS topics of common interestInternational cooperative efforts are being initiatedExpansion into broader areasSE for Capability Portfolio ManagementNet Centric Enterprise Systems/ServicesFit Sheard’s definition of complex systems:Complex systems are systems that do not have a centralizing authority and are not designed from a known specification, but instead involve disparate stakeholders creating systems that are functional for other purposes and are only brought together in the complex systems because the individual ‘agents’ of the system see such cooperation as being beneficial for them
Your consent to our cookies if you continue to use this website.