Architecting the Problem Space – Model-Based User Needs ......Architecting the Problem...

Architecting the Problem Space - Model-Based User Needs Analysis Tuesday, 01 July 2014

David Harvey and Tommie Liddy INCOSE IS 2014

AEROSPACE

CONCEPTS

Architecting the Problem Space –Model-Based User Needs Analysis

David Harvey and Tommie LiddyAerospace Concepts

Tutorial Outline• Format – Lecture and tutorial exercise mix• Classic Model-Based Systems

Engineering introduction– What is a system, which system and what is

Systems Engineering– Systems Engineering and Model-Based

Systems Engineering• Applying MBSE to user needs analysis

and beyond– Capability and capability system requirements

(key to the problem space)– Classic MBSE to support capability focus– Stakeholders, views and architectures– Case study Part 1 – Operational scenario

analysis– Case study Part 2 – High-level solution and

system requirements• Conclusion

Aerospace Concepts Pty Ltd © 2014 2Architecting the Problem Space – INCOSE IS 2014



Administrative Details

• Facilities and safety• Schedule: 10:00 – 17:00

– Lunch: 12:10 – 13:30– Afternoon break: 14:55 – 15:30– Additional breaks if needed

• Questions as they occur– may be deferred (but not forgotten!)

• Introductions


Who Are We?Aerospace Concepts Pty Ltd

• Systems engineering in aerospace, defence &related domains, specialising in:– Model Based Systems Engineering (MBSE) and capability

development– Flight Safety Analysis (aerospace modelling and simulation)– Engineering Management System development

• Main team of 20 plus ‘ecosystem’ ofspecialists on contract– Guidance – Space vehicle design– Human factors – Communications eng.– Failure analysis – Military operations

• Aerospace Research– Driving force in the Antarctic Broadband program– Quantum computing

4Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014



Now for you!

• Name• Organization / Role• What you hope to get from the tutorial


AEROSPACE

CONCEPTS

Classic Model-BasedSystems Engineering

Module 1

Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014



SYSTEMS ENGINEERINGINTRODUCTION


• A System ‘is a thing, which contains smaller interconnected things, andexists in a larger thing, where it interacts with other things, to do something.’– is: a collection of components connected by links to form a

purposeful entity within a larger context (aka system environment)• components and links = structure

– does: performs functions to process items, transforming inputs tooutputs while responding to controls, consuming or producingresources & (usually) creating by-products and/or waste

• time sequence of functions and items = behaviour– behaviour is observed at external interfaces seen in the system

context– interfaces are comprised of links that transfer external items

• driven by external stimulus and response functions• performed by external components joined by the interfaces

• “… a system is, and a system does …

• “and a system evolves” 8

… will be, … will do… was , … did

Current: “as is”Future: “to be”Past: “as was”

form

function

fit

What is a System?



Which System..?

Martin, James N., The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems,Fourteenth Annual International Symposium of the International Council On Systems Engineering (INCOSE), June 2004


Context Systemdefines theproblem

Deployed Systemmodifies theContext System

What is Systems Engineering? (1)Systems Engineering is an engineering discipline whose responsibility iscreating and executing an interdisciplinary process to ensure thatcustomer and stakeholder needs are satisfied in a high quality,trustworthy, cost efficient and schedule compliant manner throughout asystem's entire life cycle.

INCOSE


INCOSE SE Handbook 2012



What is Systems Engineering? (2)

• Based on systems thinking• Discussing, examining and modelling the real

world

• Cross-discipline• Bridging the gap between fields of knowledge

• Interconnectivity• Knowing how separate systems fit together in a

larger context


History of Systems Engineering

• Formal origin in the1930s with Britishmulti-disciplinaryteam to analyse airdefence system

• Developed sincethen initially inaerospace anddefence – now morewidespread

• Driving factors– Complexity– Precision– Rapid development


INCOSE SE Handbook 2012



Systems Engineering Activity AreasRequirements Domain

Architecture Domain

Behavior Domain

Test & Evaluation Domain


Systems Engineering Process

Requirements Analysis:Defined Problem

Functional Analysis:Logical Solution

Architecture Synthesis:Design Solution

RequirementsLoop

Design Loop

Systems Analysis&Process Control

Stated Need

Solution Specification

‘Logical’ model– what thesystem does

VerificationFeedback

‘Physical’ model- how the systemis structured

Constraint Analysis:Design Limitations

derived from MIL-STD-499B (Draft)




Managing Complexity withHierarchies

• Decompositionand Aggregationto managecomplexity

• From universedown toindividualcomponent


Decomposition, Iteration& Recursion

SYSTEM

SUBSYSTEM

ELEMENT feedback

derivation and allocation

Iterativerepeat process at a level

Recursivesame process atsuccessive levels




MODEL-BASED SYSTEMSENGINEERING


Constraints

VerificationStandards

Trade Studies

MOEsCOIs

Interfaces

Risks

TraceabilityValidation

Architecture

DecisionsPerformance

ReviewsChange

Management

Capabilities andRequirements

Documents and Specifications

Product or ProcessArchitecture

Complexity in relationships often hiddenInconsistencies result in problems

Courtesy Vitech Corp.




Model-Based Approach


Systems Engineering in Transition

Specifications

Interface requirements

System design

Analysis & Trade-off

Test plans

AirplaneATC Pilot

Request to proceed

Authorize

Power-up

Initiate power-up

Direct taxiway

Report Status

Executed cmds

Initiate Taxi

Future

Reprinted from INCOSE Model-Based Systems Engineering Workshop, February 2010

Traditional

Moving from document-centric …… to model-centric




Essential Components of MBSE

• A declared metamodel– Structure and semantics– Textual and graphical– Explicit, context-free language for communication– Problem, solution, and management dimensions

• Defined mappings / projections– ‘Fit for purpose’ views– Documentation and design artefacts– Other work products

• A process or methodology


What Makes an MBSE Model?

• Metamodel– Language – clear and unambiguous– Structure – behavior expressed in

relationships• Presentation

– Ways to express content, direct from themodel

• Content– Information built within the structure using

the language22Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014



MBSE Concepts

• The model is essential, it is:‘the single source of truth’

• The model encompasses the systemdesign and specification

• The model is provided to subsequentteams throughout the product lifecycle

• Required system specifications aregenerated from the model, complete andconsistent


Evolution of MBSE

• Good Systems Engineering is inherentlymodel based (holistic approach)

• Two major factors led to need for toolsupport1. Increasing complexity of projects vs

understanding capacity• Metcalfe’s Law (Metcalfe 1973) vs Miller’s

‘Magical Number’ (Miller 1955)• Outsourcing (Sparrow & Wegner 2011)

2. Teams of Systems Engineers




Tool Support Evolution

MBSE tools can be used to support SE that is either focusedon the documents required or the system model


SE Centricity and Basis




Document-Centric SE

• The engineer’s focus is onproduction of documents –not the definition of theproblem and appropriatesystem solution

• No reference to a centralmodel

• Lack of enforcedconsistency and informationreuse

• Documents still useful forcommunication(see Logan & Harvey 2011)

Suggested by Estafan 2008


Model-Centric SE

• Model development is thesystems engineer’s majorfocus

• Model ‘of’ and ‘about’ asystem contained within amodel of the context

• Key artefact becomes themodel, but documents canbe used to:– Capture information– As fit-for-purpose outputs

from the model for reviewand approval

Derived from Estafan 2008




One Integrated Model

DataDataDataData

verified by

Source Requirements Domain

Architecture Domain

Behavior Domain

V&V Domain

verified by

Originating requirementstrace to behavior

Originating requirements trace to physical components

Behavior is allocated tophysical components

verified by

DataData


System Schema Segment

transfers

comprised of

responsible for

SystemArchitecture

Domain

Interface

Link

decomposed by

decomposed by

inputs /outputs /

triggered by

performs

connectedto

built fromComponent

specifiesRequirement

refined by

SelectedClasses

documents

SelectedClasses

refined byDocument(Standard)

joins

basis of

InterfaceElement

RequirementElement

PhysicalElement

FunctionalElement

Color Code

specifies

Exit

Resource

Selected Classes

captures /consumes /produces

exitsby

includesOrganization

• “Top-down” system analysis &design process (example)

– Identify governing Standards, drivingRequirements and responsibleOrganizations if given

– Identify top level Component (theSystem) which performs top levelFunction within the System Context

– Decompose Functions, capturingbehavior through use of Resources,control flows, triggering and Exit logicand identifying input and output Itemsand performance Requirements (MOP)

– Develop system breakdown structure,with Components connected by Linksthat comprise Interfaces and transferItems

– Allocate atomic Functions to atomicComponents

• Produce component Specificationsand other report Documents

Perf Char

exhibitsFunction

Item




MBSE Concurrent Activities

Process Inputs

Process Outputs

CORE Repository

SourceRequirements

Analysis• Originating Rqmts.

• Issues and Decisions• Risks

DesignValidation and

Verification• Analysis

• Verification Methods• Test Plans

Architecture/Synthesis

• System Architecture• Components • Interfaces

• Constraints• Allocated Rqmts

Functional/Behavior Analysis

• System Behavior Models• Data Inputs/Outputs• Control/Sequencing• Performance Rqmts.

Topdown

Bottomup

Middle out


A Model-Based ApproachSupporting ‘Fit for Purpose’ Views




The Automatic Generation ofRepresentations and Work Products

RequestLink

CommandLinkReturn Link

CollectorProduct Link

Customers Collectors

Geospatial Library System

RequestLink

CommandLinkReturn Link

CollectorProduct Link

Customers Collectors

Geospatial Library System

Views are projections of the model. Choose the views that servethe purpose and drive them from a single, integrated model.


Model-Based, Model-Centric

• Focus on the information of and about the system– Traceability

• Links established and maintained as part of the approach– Consistency

• ‘Single source of truth’• Internal consistency

– Adaptability• Any number of views or documents can be produced as

snapshots of slices of the model– Robustness & information sharing

• System information made explicitly clear• Domain specialist views are possible – without neglecting the

interconnected nature of domains




MBSE is Not a Silver Bullet…• Rubbish in, rubbish out• Complete automation is not possible, nor

desirable, input and review needed• It is not easy

– MBSE doesn’t make your life easier.– MBSE done badly = bad SE = poor outcomes

• However, it makes projects more successful inthe long-run– less chance of schedule and cost overruns– greater chance of delivering the right capability– greater management of interfaces


AEROSPACE

CONCEPTS

Applying MBSEto user needs analysis and beyond

Module 2

Architecting the Problem Space – INCOSE IS 2014Aerospace Concepts Pty Ltd © 2014



CAPABILITYDirected Action


Stakeholder Needs andOperational Concepts

• Shared vision ofstakeholders

• Mission requirement(s)• Collection of scenarios

involving externalsystems

0. Define Need & System Concept

ISO/IEC 15288* Stakeholder Requirements Definition

*ISO/IEC (2008) 15288:2008, Systems and Software Engineering—System Life Cycle Processes.




Capability System

• Capability [Requirement] – the Need– the capacity or ability to achieve a particular effect …– may be described in terms of the nature of the effect and how,

when, where and duration it is produced.• Capability System – the Solution

– a useful combination of elements required to deliver capability,• Doctrine, Organization, Training,• Materiel System,• Leadership, Personnel, Facilities and Policy…

DOTmLPF-P

cf: UK DLOD – ‘TEPID OIL + I’, andAUS Fundamental Inputs to Capability (FICs)


DOTmLPF-P• DOTmLPF-P is defined in the Joint

Capabilities Integration DevelopmentSystem (JCIDS) process

• The DOTmLPF-P model representscategories of “solutions” required tocreate an operational capability

• DOTmLPF-P is a key authoritativeintellectual tool in DoD’s efforts toimprove efficiency and effectiveness




Capability

The ability to achieve a desired effect underspecified standards and conditions throughcombinations of means and ways to perform aset of tasks. It is defined by an operational user andexpressed in broad operational terms in the formatof a joint or initial capabilities document or a jointdoctrine, organization, training, materiel, leadershipand education, personnel, and facilities (DOTMLPF)change recommendation.

DoDAF v1.5


Where Does Capability Fit?

Aerospace Concepts Pty Ltd © 2014 42

DoDAF v2.0

Architecting the Problem Space – INCOSE IS 2014



Capability System Requirements

• Capture end-user and other stakeholders views of thecapability – what they achieve and what they do

• Derive their needs of the enabling capability system –in which some of them are a constituent element!

• Develop a solution-class concept for the CapabilitySystem that addresses those needs

• Derive the capability requirements for the capabilitysystem elements; and for which solutions are todeveloped and tested – for all of the DOTmLPF-Pelements, not just the major (materiel) systems!


‘Traditional’ System Acquisitionand Systems Engineering

Stakeholderrequirements

definitionInstallation

& validationOperational

systemProgram

engineering

definition

Systemrequirements

definition

Systemrequirements

definition

Componentdevelopments

Architecturaldesign

Architecturaldesign

Integratedconfiguration

items

Componentrequirements

Componentdesign

Componentbuild & test

Components


items

Reporting, metrics &management control

Productengineering

Productengineering



Deliveredsub-systems

Deliveredcomponents

Multiple projects

“Local” user &organizationalrequirements


Proposedcharacteristics

Integration&

verification

Integration&

verification

Multiple projectsAllocatedrequirements


Allocatedrequirements

ProposedcharacteristicsAllocated

requirements


CUSTOMER

SystemRequirementsdefinition

Architecturaldesign

Integratedsystem

Integration&

Single project atthe systems level

Productengineering



verificationSUPPLIERS




A System

Maritime missile defencecapability enabled by anintegrated detection, controland engagement system

Classical systems engineering focuseson designing a best solution (system)for a bounded, controlled problem:i.e. system-centric analysis, design andintegration

Single Performer (aka Operational Node),many activities;single system, many functions.


System of Systems

DETECT

ENGAGECONTROL

Networked detection,control and engagementcapability:collaborating systems

Network Centric Warfare; Network Enabled Capability

The Network

Increasing complexity of the system requires a new approachto capability development and employment.




System of Systems Acquisition

Statement ofNeed

Installation &validation

OperationalCapability

ProgramEngineering

CUSTOMER Statement ofNeed

OperationalSystem

Architecturaldesign

IntegratedSoS

Multiple projects atthe SoS level

CapabilityEngineering



OperationalConcept

Architecturaldesign

Operationalconcept

Installation &validation

Systemrequirements

definition

Systemrequirements

definition

Componentdevelopments

Architecturaldesign

Architecturaldesign

Integratedsystems

Componentrequirements

Componentdesign

Componentbuild & test

Components


items


Productengineering

Productengineering



Deliveredsystems

Deliveredcomponents

Multiple projects




Integration&

verification

Integration&

verification

Multiple projectsAllocatedrequirements


Allocatedrequirements

ProposedcharacteristicsAllocated

requirements






Solution Synthesis:Physical Solution

RequirementsLoop

Design Loop

Systems Analysis&

Process Control

Stated Needs and Constraints

System Requirements

‘Logical’ model:system behavior

Verification

‘Physical’model: system

structure


Systems Engineering Process




Capability Definition Process


‘Physical’model:

operationalstructure

Mission Analysis:Objectives and Tasks

Activity Analysis:Capability Concept

Capability Design:Capability [System] Solution

Needs Loop

Architecture Loop

Operational Analysis&

Process Control

Strategic Goals and Limitations

Capability [System] Requirements

‘Logical’ model:operationalbehavior

Validation

Constraint Analysis:Capability Limitations


Model-Based System DefinitionConcurrent Activities


Process Inputs:• Source Rqmts.• Change Requests

1

s1.Make

Collection

Request

AND

2

s1.Accept &

Format Request

3

s1.Check

Product

Inventory

AND

4

s1.Get Product

From Inventory

5

s1.Provide

Product to User

C.1

Universe

External System

C.2

Customers

External System

C.3

Collectors

External System

SYS.1

Collection

Management ...

System

S.1.1

Analysts

Human

S.1.2

Command

Center

Subsystem

S.1.3

Work Stations

Subsystem

3.1

General

Requirements

3.1.1

Accept

Requests

3.1.2

Retain Inventory

3.1.3

Control Multiple

Sensors

AutomatedDocumentGeneration

Process Outputs:• System RequirementsDocuments

• System Design Model• Exports to Other Tools

CORE System DesignRepository

SourceRequirements

Analysis• Originating Rqmts.

• Issues and Decisions• Risks

DesignValidation and

Verification• Analysis

• Verification Methods• Test Plans

Architecture/Synthesis

• System Architecture• Components • Interfaces

• Constraints• Allocated Requirements

Functional/Behavior Analysis

• System Behavior Models• Data Inputs/Outputs• Control/Sequencing• Performance Rqmts.




Model-Based Capability DefinitionConcurrent Activities


Process Inputs:• Guidance• CONOPS

1

s1.Make

Collection

Request

AND

2

s1.Accept &

Format Request

3

s1.Check

Product

Inventory

AND

4

s1.Get Product

From Inventory

5

s1.Provide

Product to User

C.1

Universe

External System

C.2

Customers

External System

C.3

Collectors

External System

SYS.1

Collection

Management ...

System

S.1.1

Analysts

Human

S.1.2

Command

Center

Subsystem

S.1.3

Work Stations

Subsystem

3.1

General

Requirements

3.1.1

Accept

Requests

3.1.2

Retain Inventory

3.1.3

Control Multiple

Sensors

Process Outputs:• Operational

RequirementsDocuments

• Operational ArchitectureViews

• Exports to Other Tools

CORE CapabilityDesign Repository

Source DataAnalysis• User Needs

• Policies and Regulations• Issues and Decisions

• Risks

OperationalValidation

• Analysis• Validation Methods

• Test Concepts

CapabilityDesign

• Operational Architecture• Orgs, Roles, Nodes•Interaction Needlines

• Allocated Needs

Activity Analysis• Operational Behavior Models• Information Inputs/Outputs

• Control/Sequencing• Effectiveness Measures

AutomatedDocumentGeneration


Operational & System Definition Recursion

52




Systems Analysis&

Process Control


Mission Analysis:Defined Goals


Operational DesignCapability Solution

Systems Analysis&

Process Control


CapabilitySystem

Requirements

SystemRequirements

verification

validation

validation

measures ofperformance

measures ofeffectiveness

operational architecture

system architecture

Mission

SystemSolution



Capability System Engineering


Mission Analysis:Defined Goals


Operational DesignCapability Solution

Systems Analysis&

Process Control


Doctrine Solution




Systems Analysis&

Process Control


Organization Solution




Systems Analysis&

Process Control


Training Solution




Systems Analysis&

Process Control


Leadership Solution




Systems Analysis&

Process Control


Personnel Solution




Systems Analysis&

Process Control


Facilities Solution




Systems Analysis&

Process Control


Policy Solution




Systems Analysis&

Process Control


Materiel System




Systems Analysis&

Process Control


Capability System: The combination ofthe DOTMLPF elements – Doctrine,Organization, Training, Materielsystem, Leadership and education,Personnel, Facilities and Policy.


ARCHITECTUREDefinition and Description




What is an ‘Architecture’?

• Architecture: the fundamental organizationof a system embodied in its components,their relationships to each other and to theenvironment and the principles guiding itsdesign and evolution, where:– fundamental organization means essential,

unifying concepts and principles– system includes application, system, platform,

system of-systems, enterprise, product line, ...– environment is developmental, operational,

programmatic, … context of the system


ISO/IEC/IEEE 42010:2011, Systems and softwareengineering — Architecture description


conforms to

What is an Architecture Description?

Aerospace Concepts Pty Ltd © 2014

Mission

System

fulfills

Environment Architectureinfluences

inhabits

ArchitecturalDescription RationaleStakeholder

Concern Viewpoint View

LibraryViewpoint

Model

has an

has

hasidentifies

selectsorganizedby aggregates

provides

described by

consists ofmethodsfor

has source

covers

addresses

ISO/IEC/IEEE 42010:2011

Architecting the Problem Space – INCOSE IS 2014 56



Views and Viewpoints


http://en.wikipedia.org/wiki/Multiview_orthographic_projection

Multiple views;How many viewpoints?


What is an Architecture Framework?

• An architecture framework establishes a common practice forcreating, interpreting, analyzing and using architecturedescriptions within a particular domain of application orstakeholder community.

ISO/IEC/IEEE 42010:2011

• Architecture is often equated with structure. This might even betrue, given a sufficiently general notion of structure. This issuegoes to the heart of the Standard, which rests on two principles:– (I) The fundamental concepts of systems are increasingly non-

physical and increasingly removed from what has been traditionallycalled "structure". In this tradition, "structure" usually refers to thecomponents and organization of physically identifiable things, suchas hardware entities or software objects such as modules.

– (II) All architecture views of the system are of equal importance.The Standard does not assume that a physical-structural view isprimary or that it can be used to derive other views or properties ofthe system.

http://www.iso-architecture.org/42010/faq.html#whstruct




US DOD Architecture Framework


C4ISR1996-97

28 May 2009


DoDAF 2 Viewpoints


From DoDAF 2.0 Volume 1: Introduction, Overview, and Concepts Manager Guide, May 28, 2009




DoDAF Meta-model


DoDAF Viewpoint Definitions (1)• All Viewpoint -overarching aspects of architecture context

• Capability Viewpoint - capability requirements, delivery timing, anddeployed capability

what, when and who has it/will get it• Operational Viewpoint - operational scenarios, activities, and

requirements that support capabilitiesmission, tasks, who, op roles and activities, when, where, how

• Project Viewpoint - relationships between operational and capabilityrequirements and the various projects being implemented

capability development plan• Services Viewpoint - design for solutions articulating the Performers,

Activities, Services, and their Exchanges, providing for or supportingoperational and capability functions

logical support for operationsAerospace Concepts Pty Ltd © 2014 62Architecting the Problem Space – INCOSE IS 2014



DoDAF Viewpoint Definitions (2)• Systems Viewpoint - design for solutions articulating the systems,

their composition, interconnectivity, and context providing for orsupporting operational and capability functions

physical support for operations• Data and Information Viewpoint - data relationships and alignment

structures satisfying capability and operational requirements, systemengineering processes, and systems and services

• Standards Viewpoint - applicable operational, business, technical,and industry policies, standards, guidance, constraints, and forecasts


One Model – Many Views




CASE STUDY – PART 1Operational scenario analysis


Case Study

• Generate a set of views that describe thearchitecture of the Emergency Medical ServicesCoordination Capability

• Use a mix of view ‘models’ i.e. templates– Text, table, and / or graphic– Traditional views and SysML diagrams– Handouts progressively provide an example of

model-based capability analysis and systemdefinition


• Document-Based, Model-Centric SystemsEngineering– Could move to Model-Based by using Systems

Engineering tool support



Emergency MedicalServices Coordination


EmergencyMedical Services

Coordination??

SystemCenter

Capability

?????


Capability Definition Questions

• Why does it do it?– goal and objectives => mission

• Who uses it? Who is impacted by it?– organization elements and relationships

• Where is it used?– locations, logical and / or physical

• When is it used?– time, sequence, major events, cycles

• How is it used?– processes and procedures, behavior

• What is in it & what does it do?• How is this achieved?


OperationalAnalysis

“Black Box”context analysis

Solution ConceptSolution Design




Operational Schema Segment

Operational Viewpoint:• model captures

operational elements,the tasks andactivities, and resourceflow exchanges usersneed to achieve theirgoals and tasks - themission

• views visualize thecaptured data


achieves

Architecturecomposed of

OperationalArchitecture

Domain

NeedLine(Op I’face)

transfers

decomposed by

OperationalItem

decomposed by

exits by

inputs / outputs /triggered by

captures /consumes/

produces

performsconnected to /thru

guides

SelectedClasses

achieves

built from Performer(Op Node)

Exit

Resource

responsible for

Selected Classes

includesGuidance

achieves

OperationalTask

includes

Missionincludes

refined by

Capability

basis ofOperational

Activity

Organizationassignedto


Operational AnalysisMethodology and Outputs


OV1

High-Level OperationalConcept Graphic

OrganizationRelationshipsChart

Operational ResourceFlow (Needlines)

Needline Information Exchange Information Exchange Performance

OV2 Ref Source Activity Destination Category Content Services SizeSim User

QtyFreq Latency

ExchangeType

Security Criticality InteropNotes

1 needline AAR - GenericADF Aircraft

Air to AirRefueller(V1)

Refuel ADFaircraft inflight

Generic ADFAircraftCommand(V1)

Conduct ofOperations

Coord Info ElectronicData

Very small 1-3 On demand(3-6 per day)

Near RT Duplex - S S Essential Joint,Coalition

1 needline AAR - GenericADF Aircraft

Air to AirRefueller(V1)

Refuel ADFaircraft inflight

Generic ADFAircraftCommand(V1)

Conduct ofOperations

Coord Info Low QualityVoice

30 min radiocircuit

1-3 On demand(3-6 per day)

voice Half duplex S Essential Joint,Coalition

2 needline AEW&C - MROC MobileRemoteOperationsCentre (V1)

Conductmobileregionaloperations

AEW&C (V1) Conduct ofOperations

Fightercontrol rebro

Low QualityVoice

30 min radiocircuit

1-10 On demand voice Half duplex S Essential Joint,Coalition

Key radios (relay function to CAP)

2 needline AEW&C - MROC tbd tbd ROC MROC ISR/BM AEW&CRadar PlotData

ElectronicData

large 1-3 Continuous Near RT Simplex S Essential Joint

2 needline AEW&C - MROC AEW&C (V1) DistributeAEW&Ctrack data

ROC MROC ISR/BM AEW&CTrack Data

Electronicdata

medium 1-3 On demand(3-6 per day)

Near RT Simplex S Essential Joint

3 needline AOC - WOC AirOperationsCommand(V1)

Plan andmanage airoperations

Generic WingOperationsCentre (V1)Generic WingOperationsCentre (V1)

Commandand Control

refer togeneric TG-TU C2






Duplex - S refer togeneric TG-TU C2

Essential refer togeneric TG-TU C2

It is assumed that CAOC information distribution to a WOCis equivalent in magnitude to the exchange of informationbetween the Genericly described Task Group to Task Unitlink.This IER references the 'Generic C2' analysis at the startof this document.

4 needline Generic MissileController - FOSOW

GenericFOSOWController(V1)

Control andupdateFOSOWflight pathpost launch

FOSOW (V1)FOSOW (V1)

SystemTelemetry

missilecontrol data,targetupdates

ElectronicData

small 1-3 On missiondemand, 1-10 per day

RT Duplex - S S Essential Joint Data transmission requried is 9.2kbits for 30 mins.

An operationalconcept provides amission overviewthat involves theusers of a system ofinterest …

… users who haveformal (command)relationships andoperational roles …

… that constitute theperformers which, toachieve mission-necessaryoperational tasks,exchangeoperationalinformation …

… and the informationexchange has variousattributes and meetscertain performancecriteria.

… which is produced orconsumed by theoperational activities thatachieve the operationaltasks performed byperformers …

OV4 OV2 OV5b OV3

OperationalActivity Model

OperationalResource Flow

Operational activity (hierarchy): OV5aOperational rules, transitions and timelines: OV6

Operational Architecturerepresented byOperational Views




Operational Scenario Analysis

“Matthew collapses at work. His colleague,John contacts the Emergency MedicalServices (EMS). Alan, an EMS specialistcall-center operator, takes the call …”


FormalOrganization Performer

acts as OperationalActivities

performs

Needline OperationalItems

connected by exchange

transferredby

OperationalNeed

results in


Organizational Relationships


OrganizationType: <……>Role: <…….>

Organization Organization

‘controls’ ‘coordinates’

‘Theatre Company’ includes a ‘Person’ with ‘Role:Actor’ who becomes a ‘Character’ in a ‘StagePlay’.

The Person (organization) as Actor (role)“performs” as the Character (performer) in theStage Play (operational scenario).




Operational Interaction


connectedto

Performer

Needline akaOperational Interface

OrganizationType: <……>Role: <…….>

responsible for

Static View“formal” organization

Dynamic View“working” organization,

scenario dependent

Needed Interactions

Operational Item

transfers

‘Resource’ FlowsArchitecting the Problem Space – INCOSE IS 2014

EMSCC Scenario Analysis:Who?


Turn over and draw an EMSCC Organization DiagramArchitecting the Problem Space – INCOSE IS 2014

Scenario Major medical emergency – all services requiredOrganization Elements and Performers

Person Organization / Description [has] Role(s)[acts as]

Performers(s)

Alan Emergency medical servicescall-center operator

Emergency medicalservice coordinator

Call Taker /Operator



Organization as Hierarchy

75

includes/included in)

coordinates with/coordinated by)

Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014

Organization as ‘Spider’ Diagram




Organization traced to Performer

77Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014

The Organization

is responsible for

The Performer(s)

Operational Connectivity –Resource Flows


performs

inputs,outputs

transfers

connected to

Performer Operational Activity

Needline Operational Item

Operational Tasks

achieve

Mission achieve




Interaction, Activities and Flows:Where, When and How?


Scenario Major medical emergency – all services requiredOperational Connectivity

Needline Description PerformersInfo Transferred

between Performers

Caller -Operator

Telephone link between thecaller and the EmergencyMedical Services

Caller /OperatorPatient Symptoms,Request for furtherdetails, etc…

Performer Hierarchy




Operational Connectivity


Interaction, Activities and Flows:Where, When and How?


Scenario Major medical emergency – all services requiredOperational Activities and Information Flow

Activity Description PerformerInput Item(Resource)

Output Item(Resource)

Report medicalemergency

Contact EmergencyMedical Services (EMS) Caller Patient

Symptoms

Receive Call Takes the EMS call Operator PatientSymptoms

Request forfurther details,



Behavior Diagrams – EFFBD*


*Enhanced FunctionalFlow Block Diagram

Time-sequencedActivity = Behavior


SysML Activity Diagram




Timeline


DoDAF OV-3 – Operational ResourceFlow


Blank attributes – missing information?

Data can be readily reviewed in this view and formatArchitecting the Problem Space – INCOSE IS 2014



Operational Data Metamodel

OV-3

OV1 OV6a

OV-5a,bOV-6b,cOV-2

OV4

OperationalInterfaces

performs

connectedto

inputs/outputs

transfers

Mission

achieved byresponsible for

results in

Critical OperationalIssuesgenerates

achieved byassigned to

Guidance(Policy & Doctrine)

guides

Business Limitations& Constraints

External Fileaugmented by

Organizations<role(s)>

OperationalNodes

OperationalActivities

OperationalTasks

OperationalItems

Operational Needs& Constraints

OV-3: Operational Resource Flow MatrixOV-4: Organizational Relationships ChartOV-5a: Operational Activity DecompositionTree

Views generated from data model:OV-1: High-Level Operational ConceptOV-2: Operational Resource FlowDescription

OV-5b: Operational Activity ModelOV-6a: Operational Rules ModelOV-6b: State Transition DescriptionOV-6c: Event-Trace Description87

Operational (User) Needs Derivation


Performer[Op Node]

Needline OperationalItem

OperationalActivity

performs

connected to inputs/outputs/triggered by

transfers

Organization<role(s)>

responsiblefor

(User) Requirement<Origin: operational>

<Type: functional/performance/constraint>

results in

”An organization element acting in it’s operational role [i.e. as a performer]performs operational activity(s) and interacts with other performers to achieve amission and / or operational tasks. Effective performance of that activity needs

particular capability characteristics.”

Mission/Op Task

achieves

Capability

refines

assigned to requires

‘Measure ofEffectiveness’

exhibitsIT




Operational / User Needs Derivation:What?

89

Scenario Major medical emergency – all services required

Operational Needs (User Requirements)

Performer Activity Need(s) EffectivenessOperator Receives Call Operator needs notification of

incoming emergency call.

Operator needs to accept CallWithin time specified.

Percentage of calls answeredwhen an operator is available.

Call wait time less than 30secs for 99% of calls

Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014

User Needs – SysML Reqts Diagram




CASE STUDY – PART 2Functions, requirements and system synthesis


IEEE1220 Systems EngineeringPlan




IEEE1220 Requirements Analysis

93

User needs and other stakeholder requirements analysis

System Requirements AnalysisAerospace Concepts Pty Ltd © 2014

IEEE1220 Functional Context Analysis


To:Requirements analysis

Functional Design

Functional Requirements Analysis




SV-7

SV-6

SV-1/SV-2SV-4/SV-10

System Requirements Model


SystemConstraints

SystemRequirements

Functions System

specifies

performedby

Items

refined by

Links

[External]Interfaces

comprise

PerformanceCharacteristic

(MOP)

transferredby

connected to

exhibits

VerificationRequirements

inputs/outputs

OperationalNeeds &

Constraints

BusinessLimitations

& Constraints

basis of

specified by

verified by

joinedto

ExternalSystem(s)connects

joins

Views generated from data model:SV-1 Systems Interface DescriptionSV-2 Systems Resource Flow DescriptionSV-4 Systems Functionality DescriptionSV-6 Systems Resource Flow MatrixSV-7 Systems Measures MatrixSV-10a Systems Rules ModelSV-10b Systems State Transition DescriptionSV-10c Systems Event-Trace Description


System Schema Segment

MBCD– 8

-96

transfers

comprised of

responsible for

SystemArchitecture

Domain

Interface

Link

decomposed by

decomposed by

inputs /outputs /

triggered by

performs

connected to

built fromComponent

specifiesRequirement

refined by

SelectedClasses

documents

SelectedClasses

refined by

Document(Standard)

joins

basis of

InterfaceElement

RequirementElement

PhysicalElement

FunctionalElement

Color Code

specifies

Exit

Resource

Selected Classes


exitsby


• “Top-down” system analysis &design process (example)

– Identify governing Standards, drivingRequirements and responsibleOrganizations if given

– Identify top level Component (theSystem) which performs top levelFunction within the System Context

– Decompose Functions, capturingbehavior through use of Resources,control flows, triggering and Exit logicand identifying input and output Itemsand performance Requirements (MOP)

– Develop system breakdown structure,with Components connected by Linksthat comprise Interfaces and transferItems

– Allocate atomic Functions to atomicComponents

• Produce component Specificationsand other report Documents

Perf Char

exhibitsFunction

Item




Functions and Requirements:How this is achieved


Scenario: Major medical emergency – all services requiredFunction and Performance Requirements (System Requirements)

User Need Function(s) Performance RequirementOperator needsnotification ofincomingemergencycall.

Provide aural alarm Audio level abovexxdBA

The EMS operator station shallprovide an aural alarm at aninitial level for xx dBAescalating to yy dBa over 10sec period.

From Operational to System Space




End-to-end Analysis Thread


The OperationalActivities result inUser Needs which formthe basis of systemFunctions specified byRequirements

IEEE1220 System Functional Design




IEEE1220 System Synthesis


Much ‘analysis’ in ‘design’

Analysis of Alternatives

*Architecting the Problem Space – INCOSE IS 2014

IEEE1220 System Design


Much ‘analysis’ before‘Final Design’



Requirements Analysisand System Design


Enterprise

User Org

Other S’holders

Op Nodes Op Activities

Op ItemsOp Interfaces

Op Needs

Constraints

*System

External Systems

Interfaces

LinksItems

Mission

*Functions/Perf

Requirements

Document

Op Tasks

Limitations

*System*Functions/Perf

ComponentsSub-functions

User needs and otherstakeholder requirements

System requirementsanalysis

Functional Analysisand System Synthesis


The Model Framework

104

Exit

Resource

Selected Classes


exits by


transfers

comprised of

responsible for

implemented by

implemented by

implemented by

implemented by

Architecture composed of

achievescomposed of

NeedLine

transfers

inputs / outputs/ triggered by

achieves

OperationalArchitecture

Domain

decomposed by

decomposed by

exits bycaptures / consumes

/ produces

performs

connected to

documents

SelectedClasses

achieves

built fromPerformer

refined by

Document(Guidance)

OperationalTask

includes

Mission

includes

Op Activity

Op Item

SystemArchitecture

Domain

Interface

Link

Function

decomposed by

Itemdecomposed by

inputs / outputs/ triggered by

performs

connectedto

built fromComponent

Requirement

refined by

SelectedClasses

documents

SelectedClasses

refined byDocument(Standard)

joins

basis of

InterfaceElement

RequirementElement

PhysicalElement

FunctionalElement

Color Code

specifies

System ofInterest


‘enables’

refined byCapability

basis of

implemented by

State

Mode

Event

Transition

OperationalNeeds




AEROSPACE

CONCEPTS

Summary

Conclusions and beyond


CONCLUSION




Tutorial Summary• Introduced classic systems engineering process and a model-

based systems engineering method• Discussed architecture definition frameworks and their

application to the problem space analysis• Applied MBSE methods to the problem space (exploratory

research and conceptual design)– from goal identification through to needs definition to solution

concept• Gained practical experience in developing an information model

and derivation of user needs and other stakeholderrequirements– Emergency Medical Services Capability

Appreciation of the opportunities and challenges in adopting anMBSE method as a structured and explicitly defined approach for

user and other stakeholder requirements analysis.Aerospace Concepts Pty Ltd © 2014 107Architecting the Problem Space – INCOSE IS 2014

Closing thoughts• All good systems engineering is and always was

model-based– Documents are still an important part of MBSE– With the rise in complexity of projects and teams, MBSE tool

support is required

• Always ask Why, Who, Where, When, How & What• Symmetry between the system and operations

schema segments, the process and techniques are(almost) the same!

• Using the best available tool helps do the bestpossible job




Model Based Systems Engineering

If you doubt thepower of modelbased systemdescriptions,without using yourhands, or simileor metaphor,describe a spiralstaircase (tosomeone who hasnever seen one)


Upcoming 2-Day MBCD Course

Model-Based Conceptual Design –A Practical Approach

Date: Wednesday 9 to Thursday10 July 2014

Location: Washington DCFees: $995 USD per person

For more details go to:www.eventbrite.com

and search ’conceptual design’

Enter the promotional code‘matesrates’ for 25% off

110



MODEL-BASED MODEL-CENTRICAPPROACH


Tool Support for Model-BasedApproach

• Today we have focused on document-based model-centric approach– Here is an example of a model-based

model-centric approach to the sameproblem…




QUESTIONS?

Aerospace Concepts Pty Ltd © 2014 Architecting the Problem Space – INCOSE IS 2014 113

Thank You!For additional information contact:

David HarveyAerospace Concepts

PO Box 3005Port Adelaide SA 5015AUSTRALIA

+61 403 757 [email protected]




References (1)

• DoDAF 1.5,http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_Volume_II.pdf

• DoDAF 2.0http://dodcio.defense.gov/TodayinCIO/DoDArchitectureFramework.aspx

• Estafan, J., “Survey of Model-Based Systems Engineering MBSE Methodologies”INCOSE MBSE Initiative, 2008,(http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf) Accessed 16Aug 2011.

• Friedenthal, Moore and Steiner 2009, A Practical Guide to SysML: The SystemsModeling Language

• Haskins, C., Systems Engineering Handbook: A Guide for Systems CycleProcesses and Activities, SE Handbook Working Group INCOSE, Version 3.2.2,October 2011.

• IEEE, IEEE Standard for Application and Management of the SystemsEngineering Process, IEEE 1220-2005, Reaffirmed 2011

• ISO, Systems and Software Engineering—System Life Cycle Processes, ISO/IEC(2008) 15288:2008, March 2008.

• ISO, Systems and software engineering — Architecture description,ISO/IEC/IEEE 42010:2011, November 2011.


References (2)

• Logan, P. & Harvey, D., “Architecting the Problem Space: an ArchitectureFramework-based Method for Definition of User Requirements”, 4th Asia-PacificConference on Systems Engineering (APCOSE 2010), Keelung, Taiwan, October2010.

• Logan, P. & Harvey, D., “Documents as Information Artefacts in a Model BasedSystems Engineering Methodology”, 5th Asia-Pacific Conference on SystemsEngineering (APCOSE 2011), Seoul, Korea, October 2011.

• Martin, James N., The Seven Samurai of Systems Engineering: Dealing with theComplexity of 7 Interrelated Systems, Fourteenth Annual InternationalSymposium of the International Council On Systems Engineering (INCOSE), June2004

• Metcalfe, R., “Packet Communication”, Massachusetts Institute of Technology(MIT) Project MAC Technical Report MAC TR-114, December 1973.

• Miller, G., “The Magical Number Seven, Plus or Minus Two Some Limits on OurCapacity for Processing Information”, Psychological Review Vol. 101, No. 2,pp.343-352, May 1955.

• Sparrow, B, Liu, J. & Wegner, D., “Google Effects on Memory: CognitiveConsequences of Having Information at Our Fingertips”, Science: 333 (6043),pp.776-778, August 2011.

• SysML specification v1.3, 2012, OMG (www.omgsysml.org)




AEROSPACE

CONCEPTS

End


Architecting the Problem Space – Model-Based User Needs ......Architecting the Problem...

Documents

Transcript of Architecting the Problem Space – Model-Based User Needs ......Architecting the Problem...