SoS Quiz

System of systems (DoD def)

independant and useful systems are integrated winto a larger system which creates a unique result

Heilmeier question

- what is the problem to be addressed

- how is it done today, by whom, and what is wrong with it

- how do you propose to address it

- what is the impact

- what is your plan/approach and how will you be successful

- how long will it take

- what are your midterm/final exams

SoS systems architecture

lays the framework for how all individual systems should work together at a high level through requirements and interfaces (composer)

Engineer

ensures a system/aspect of a system works flawlessly (many disciplines involved for different aspects) (instrument)

Systems integrator

makes sure all subsystems are working well together, balancing them to create heterogeneity (conductor)

how to analyze complex systems with different metrics

requirements are broken down into functions, functions are assigned to systems/subsystems, and function fulfillment can be assessed

system (IEE def)

A set of functional elements organized to satisfy user needs OR A collection of components organized to accomplish a specific function or set of functions

system (INCOSE def)

a combination of interacting elements organized to achieve one or more stated purposes.

system (NASA def)

A set of interrelated components which interact with one another in an organized fashion toward a common purpose

simple system

small number of components which act according to well understood laws

complicated system

large number of components which act according to well understood laws

complex system

large number of components wich can interact in a not well understood manner. System behavior cannot be understood through the sum of its parts.

what type of systems do we model is SoS

complex

systems engineering

definition, design, development, production, and maintenance of functional, reliable, and trustworthy systems with cost and time constraints. engineering the integration of a product.

systems engineering main focus

help define the customer needs and functionality early in a business development cycle.

why is early integration important

reduces cost and schedule overruns

which decisions are most fundamental and difficult to reverse

early decisions

left hand of Vee model

decomposing and defining problem

right hand of Vee model

building up product based on requirements, with integrating and testing at each stage

how does systems engineering compare to software engineering

similar problems and requirements, but much higher testing cost

systems engineering process

- define needs early

- document and trace all requirements

- flow down requirements and allocate as you go

- keep operations/schedule/performance/training/manufacturing in mind

problems with vee

-doesnt accurately capture modeling effects

- sequential, and doesnt capture how verification and design are concurrent processes

- no verification before testing begins (doesn't use digital engineering)

downsides of systems engineering being a document based process

- data is hard to access across different departments

- organizational boundaries mean collaboration isnt guaranteed

- some tools and software are incompatible

- top-down approach means that information about product is implemented after design instead of during

benefit of MBSE

moves to a model centric approach and includes benefits like early/continuous verification and validation

requirement

precise statement of what, how well, and under what conditions something must be done

functional requirement

qualitative

performance requirement

quantitative

architecture

framework/structure that portrays relationships among all the elements of the system, force, or activity.

requirements analysis inputs

- customer needs

- technology base

- outputs

- program requirements

requirements derived from specifications and standards

requirements analysis outputs

architecture, specifications/baseline, systems configuration, decision database

flowdown

how something in a larger context applies to a smaller part, way of creating new requirements

derivation

new knowledge/requirements found during the design process implemented as a requirement, way of creating new requirements

allocation

assigning requirements to parts

three views to express requirements

operational, functional, physical

functional flow block diagram

decomposes system from high down to low levels

N2 diagram

shows interactions between different subsystems and how info is fed between them + external and internal output

state machine

flow chart basically (generally not designed for humans to read and work with)

design synthesis

allocate functions created in the functional analysis to parts or subsystems of the overall system

methods of design synthesis

system dynamics, discrete events, agent based

system of systems (DoD def)

a set of arrangements of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities

system of systems (INCOSE def)

system-of-interest whose system elements are themselves systems; typically, these intail larger scale inter-disciplinary problems with multiple, heterogenous, distributed systems

system of systems (air force)

group of systems each of which individually provides its own mission capacity that can be operated collectively to achieve an independant, and usually larger common mission capability

how does an SoS compare to a single system

- larger in scope

- has emergent behavior

- higher degree of uncertainty

- ambiguous requirement

- continuous SE

- humans in the loop

SoS Engineering

an interdisciplinary approach towards creating the requirements for the systems that go into an SoS

Challenges of SoSE

-broader range of stakeholders

- individual systems may not have been designed for SoS

- significant data, information, and resources all flow between systems

- differing lifecycles

- difficult to conduct testing and evaluation

individual system requirements are unlikely to line up

virtual system of systems

contains emergent late behavior and no central management authority. Ex: information grid, natural disaster response.

collaborative SoS

group of systems that willingly interact together in an SoS to fit some agreed purpose. Generally unmanaged by a single entity. Ex: internet, energy grid

Acknowledged SoS

more organized SoS where central goals management and resources exist but each individual system retains individual ownership and maintains its own funding and objectives. ex: ballistic missiles defense system

Directed SoS

The most managed. Everything is integrated and long term management exists of all the systems within. ex: government

architecture (SoS)

way to describe an SoS. Can define pitfalls and problems early in design. Organizes complex systems. Helps keep trak of element relations. Should be standardized, computer readable, and consistent. Can also be called representation models

SoS modeling challenges

Stochastic nature, complex, nonlinear, heterogenous, independent elements, emergent behaviors, scalability

deductive reasoning

used to make design decisions based on knowledge

stakeholders

- users

- operators

- acquirers

- owners

- suppliers

- developers

- builders

- maintainers

architecture framework

establishing a common practice for the description of elements in an architecture for a specific doman or group of stakeholders

framework examples

DOFAF, NAF, MODAF, TOGAF, ESAAF, 4+1 view model

dodaf framework

has different operational views (OV) showing different levels of a scenario

ov-1

High-Level Operational Concept Graphic puts an operational situation or scenario into context and is a tool for discussion and presentation

OV-2

shows flow of information, resources, and material between some origin and the location where it is required

OV-3

represents the resource flow discussed in OV-2 + more information

OV-4

Organizational Relationships Chart

OV-5a

development of OV-4, shows operation being decomposed as opposed to organization

OB-5b

chronological version of decomposed operation

OV-6a

details rules and restrictions a system operates under

OV-6b

shows completeness, changes, and state changes similar to OV-5b

OV-6c

acts like OV-6b but multiple states concurrently

SV-1

shows what reources and through what interface the resources are passed through for individual systems

SV-2

adds technical detail to SV-1

SV-3

table version of SV-1

SV-4

basically OV-5b aad shows what is stored in each system

SV-5a

connects operational aspects to physical systems. needs OV-5b and SV-4

SV-5b

maps operational aspects to systems themselves

SV-6

log showing what resource is being exchanged, to/from where, and what interface is being used

SV-7

gives further context to characteristics of systems and what resources are being used (needs SV-6)

SV-8

shows how main systems and external systems change and interact over time

SV-9

shows the technological impacts on an SoS' operations. Can be categorized as benign or destructive.

SV-10a

sets rules for systems in terms of resource flows and interfaces

SV-10b

does same as OV-6 but for systems view with order of system state changes due to internal or external input

SV-10c

systems version of OV-6c, shows concurrent or chronological events for all systems

static models

can be created by framework but are not desireable for SoS because it evolves and changes

UAF

unified architectural framework, an architecture framework that attempts to cover a broad range of applications in multiple domains

Strategic structure

breaks a model down into time/state defined phases (overall picture)

Strategic taxonomy

what is an SoS capagle of doing, composition and capability parameters

Strategic connectivity

shows dependencies between planned capabilities for analysis

strategic traceability

behavioral map which shows relationships between capbilities,

strategic parameters

shows environmental and conditions represented in the architecture

strategic constraints

shows limitations, constraints, and eprformance parameters within the architecture

Strategic roadmap

shows deployment of capabilities over time for an organization

strategic phasing

plans milestones effectively for an SoS

operational structure

operational requirements for information exchange between nodes

operational taxonomy

shows all the operations and their characterisitcs

operational processes

shows the relations between operations such as what and who

personnel taxonomy

shows the important elements

personnel structure

how the elemenets are structured and their relations

personnel connectivity

defines the competence of each personnel element. competence is their abilities defined by knowledge, skill, and aptitude

personnel processes

specifies resource functions in relation to their definitions (what does an element consist of inregards to personnel)

personnel states

a graphical view of how those resources respond to events

personnel interaction scenarios

a time ordered event representation

testing

done after a design is complete to verify its finctions

simulation

a model run with some inputs (runs/cases/experiments) during the design phase to mitigate SoSE challenges

why use models

act as analogies. help describe complex/unfamiliar concept in a simple manner. they act as mathematical functions, taking ins ome input and having some outputs