Model-Based

Systems Engineering:
A Practical Approach

INCOSE San Diego

25 September 2019

Charles H. Patton
CSEP, DTM

Copyright © 2019 by Charles H. Patton

All Rights Reserved
Permission granted to INCOSE to publish and use
 Agenda

• Why invoke Model-Based Systems Engineering?

• What is Model-Based Systems Engineering?

• What we did on the Surrogate SATCOM IRaD

• What should you do?

2
 The Perception?

“Process is not the enemy –

bad process is.”
– Toward Agile Systems
Engineering Processes,
Turner, CrossTalk April 2007)

Practicality Needn’t Be Cumbersome

3
 Why

• Systems Engineering V Model

Regional Feasibility Operations Changes and

Study/Concept Retirement/
Architecture(s) and Maintenance Upgrades Replacement
Exploration
Life Cycle Processes Concept of System
Operations System Validation Plan Validation

System System
System Verification Plan Verification &
Requirements (System Acceptance)
Deployment
Subsystem
High-Level Verification Plan Subsystem
Design (Subsystem Acceptance) Verification

Detailed Unit/Device Unit/Device

Design Test Plan Testing

Software/Hardware Document/Approval
Development
Field Installation
Time Line Implementation
Development Processes

4
 Why (cont.)

• Communication
– Common understanding
• What the system is supposed to do
• What the system parts are called
– Normalized terminology
• How the system is configured
– Define subsystems and components
Collaboration
– Identify interfaces
– Logical and Physical Coordination

• Coordination Communication

– Multiple engineering efforts

• Who’s developing which parts of the system
– Accommodate changes

Effective Development is the Goal

5
 Why (cont.)

• Collaboration
– Develop models
• Requirements: CONOPS, COIs, Missions, etc.
• Architecture: OV1, Block Diagrams, Data Flows, Drawings, etc.
• Operation: Mock-ups, Test and Demo plans, etc.
– From different points of view
• Business Development Collaboration

• Hardware
Coordination
• Software
• Cybersecurity Communication

• Test
• Deployment
• Sustainments, Logistics, Operations and Maintenance

We see things differently

6
 What

• Model-based systems engineering (MBSE) is the formalized

application of modeling to support system requirements, design,
analysis, verification and validation activities beginning in the
conceptual design phase and continuing throughout development and
later life cycle phases

• A model is an approximation, representation, or idealization of

selected aspects of the structure, behavior, operation, or other
characteristics of a real-world process, concept, or system, i.e. an
abstraction

• A model usually offers different views in order to serve different

purposes
– A view is a representation of a system from the perspective of related concerns or
issues

7
 What – Model Examples

• Video games

• Weather maps

• Schedules

• Simulators

• Test Configurations

8
 What – View Examples

• Hardware

• Software Data Link Processor

1
J-SERIES MSG +
K-SERIES MSG
MANAGEMENT MSG

MAP COMMANDS +
J-SERIES MSG + RC ICD
FalconView DRAWING COMMANDS +

• System K-SERIES MSG STATUS MSG 6 SIMULATED USER INPUT

MANAGEMENT RC ICD
MSG CONFIG MSG

– Logical SCNS
Emergency
Operator
Declassification
NAV DATA
Processor Station
– Physical PLATFORM TYPE 5 Invocation
Processor
HSI
4
8
– Operational Tactical Data Processor
2 EDGE TEXT MSGS +
EDGE MISSION MSGS + STATION TEXT MSGS +
EDGE IMAGE MSGS + Message STATION MISSION MSGS +
STATION IMAGE MSGS +
EDGE NAV MSGS +
EDGE STAT & CFG MSGS
Broker STATION NAV MSGS +
Services STATION FUEL MSGS +
STATION STAT & CFG MSGS +
3 STATION TGT SORT MSGS
EDGE FUEL MSGS +
EDGE TGT SORT MSGS

BIT LOG STATION

STAT & CFG
MSGS
BIT Logs BIT LOG
Mission Planner
7

IMAGE Images IMAGE

9
 How

• Operational • Logical
– CONOPS, Missions – Context Diagrams
– COIs, MOEs, MOPs – Architecture Block Diagram
– OV1 – Interconnect Diagrams
– Requirements – Architecture Flow Diagrams
– Test and Demo Plans
• Physical
• Functional – Product Entity Diagram
– Decomposition – Drawings
– Data Flow Diagrams – Equipment Configuration Diagrams
– Use Cases – Checklists

Capture the Thinking

10
 How – Operational

• CONOPS, Missions

• COIs, MOEs, MOPs

• OV1

• Requirements ID COI
Need to increase crop yield for
MOE MOP

1 amount of time and material

used
• Test and Demo Plans 1.1
Crop yields compared to historical
yields under similar conditions
1.1.1 Annual crop yield
Objective
1.1.23.2 Demonstrate exchange of data from ground sensor to central controlCost of station via the sensor network.
soil amendments
1.1.3 Scenario dry run completed. Time (hours) to manage irrigation
Entry Criteria Need to minimize change load simulator calibrated.
Transmission
2 impact on theTest
hostreadiness
irrigation reviewed and approved.
CONCEPT FOR THE PROPOSED SYSTEMExit Criteria
system Data transmitted from sensor, data received at central control station for post-processing and verified
2.1 Percentage change in operability
The RSMS is a hardware and software solutionbyapplied test engineerto an existing irrigation system to monitor soil
Percentage change to physical
2.1.1  General: Sensor data transmission, single channel
conditions and control the application of water-based
Test Scenarios
soil amendments according tointerfaces
 Scenario 1: 25 kHz Tx in sensor network
a tailorable
2.1.2
parametric model. The RSMS can be configured  to accommodate
Scenario present
2: 5 kHz Tx in sensor Percentage
network and short-term forecast change to user interfaces
2.1.3 Percentage change to user instructions
weather conditions. The human-system interface Sensor data logged
(HSI) by central access
provides control station. the monitoring and control
2.2 Data
Test Output Percentage change into componentry
System configuration files.
2.2.1 the parameters of the heuristic model to bestNumber of new parts local
functions, and allows the user to tailor suit on-going
Message latency: Determine average elapsed time between transmission of sensor data from the
2.2.2
conditions. Sensors are hot-swappable,
Data Analysis are easily sourcemoved, andofoperate
sensor and receipt wirelessly.
the sensor data Number
at the central control of replaced parts
station.
2.2.3 Message quality: Sensor data transmitted matches data received. Number of discarded part
11
 How – Functional

• Decomposition
Remote Soil Management System (1.0)
• Data Flow Diagrams

• Use Cases F1.1

Sense
F1.2
Monitor and
F1.3
Deliver F1.4
Data
F1.5
Human-System
Conditions Control Amendments Interface

FOW/CCOW
Sensor F1.1.1 F1.2.1 F1.2.5 F1.3.1 F1.4.1
F1.5.1
SenseROW/RCCOW Receive Manage Configure Adjust Provide
Monitor
Network Soil Conditions Sensor Delivered Adjustment
Config Operations
Conditions DATA Messages Soil Network SYSTEM Content Quantities
CONFIG
F1.2.2
Conditions
F1.2.6 F1.3.2
Loader F1.4.2 F1.5.2
F1.1.2 1
Sense Send Process Receive Receive Configure
Atmospheric Delivery System Delivery Weather Sensor
Test Sensor Conditions DATA Messages Update Messages Data Network

F1.1.3 F1.2.3
FOW/ CHANNEL
F1.2.7 CONTROL + F1.4.3 F1.5.3
Transmit Determine
CCOW MonitorCONTROL
SYSTEM Configure Configure
Conditions Adjustment
ROW/ Operations Model Model
Messages Quantities
RCCOW
F1.1.4 F1.2.4 F1.5.4
Receive Configure
Delivery
REMOTE Remote Configure
Conditions CONTROL Delivery
Messages Control Manage Control Control
REMOTE
System CONTROL
F1.1.5 2
REMOTE
Configure
Sensor CONTROL Control Station
12
 How – Logical

• Context Diagrams
Remote Soil Management System (1.0)

Sensor Network (P1.1) Delivery Station (P1.3)

• Architecture Block Diagram Sensors

A1.1
F1.1.1
F1.1.2 F1.1.5
Delivery
A1.3
F1.3.1
Valve
Cmd
Sense Configure
Sense Soil
Atmospheric Adjust Irrigation
Conditions Sensor
Conditions Delivered System
Conditions Conditions
Content Fault

• Architecture Flow Diagrams

Signal
F1.1.3 F1.1.4 Delivery
Transmit Receive Fault
Cmd
Signal
Conditions Conditions F1.3.2
Conditions
Messages Messages Receive
Delivery
Messages
• Interconnect Diagrams Conditions Fault Signal

Central Control Station (P1.2)

FOW/CCOW Monitoring and Control
A1.2
FOW/CCOW
Delivery Cmd Control
Control
Sensor F1.2.1 F1.2.2
ETHERNET
Module
F1.2.4
RADIO
Module
F1.2.7
ROW/RCCOW Receive ROW/RCCOW
Send Monitor Configure
Network FREQUENCY Amendment
Amendment Conditions Delivery
SYSTEM
Operations
Delivery 1.21.2
Ops
DATA Messages Messages Control
Module
Module Conditions
CONTROL Data

FOW/CCOW
1.1
1.1
Adjustment
Quantities SYSTEM
Delivery
Configuration Config
F1.2.6 F1.2.3 CONFIG F1.2.5

Sensor System Process Determine

SYSTEM
Loader
Configure
Update System Adjustment Sensor
ROW/RCCOW CL-510
CONFIG
Feed
Network Update Quantities
Sensor
Configuration
RemoteNetwork
DATA RSMS REMOTE
CONTROL REMOTE Delivery

Conditions
0 ConfigControl
Config ETHERNET
CONTROL
REMOTE
Configuration

Data Adjustment Human-System Interface Sensor

A1.4 DATA
ETHERNET
F1.4.1
Quantities
A1.5 Loader
Loader
Configuration
CONTROL
Provide REMOTE
F1.5.1
Configure
Control
F1.5.2

Test Sensor DATA Adjustment Monitor

CONTROL
Weather
Quantities Model SYSTEM
Operations
Sensor Station
Data
Field
Field
Data
CONFIG
CL-510 Network

Test Sensor DATA

RADIO
F1.4.2 F1.5.4
Test Sensor Weather
FREQUENCY Module
Receive
ModuleConfigure
Weather
F1.4.3

REMOTE
Configure
F1.5.3

Remote
Configure
Delivery
Feed 1.3
Data 1.3
Model Model
CONTROL
Model Remote Control REMOTE
ETHERNET
Data
Control RADIO
CONTROL
Control FREQUENCY
13
 How – Physical

• Product Entity Diagram

• Drawings

• Equipment Configuration Diagrams Remote Soil Management System (1.0)

Quantity Per Site

Equipment Purpose
Lab Flight
• Checklists Unit under test equipment
Main Processor General system processors P1.2 1 1
P1.1 P1.3
Main software General system functionalityCentral Control 1 1
Sensor Network Delivery Station
Radio Over-the-air connectivity and message processing
Station 1 1
Antenna Over-the-air connectivity - 1
Channel Control processor Configuration and control of the airborne radios and network 1 1
System Control processor Configuration and control of the airborne system 1 1
P1.2.3
Payload Control KVM
P1.1.1 User interface toP1.2.1
the channel and system controllers 1 P1.3.11
Wireless
Sensor
Payload Control software Payload ControlComputer
functionality 1 Valve1
IC +
Transceiver

DA OIC
VO ATA
E

V
Power Converter (270V) Converts input power to 270 VDC 1 1

TA E
D

+
Power Converter (28V) Converts input power to 28 VDC 1 1
Power Distribution Unit Distributes power to DSS hardware components P1.2.4 1 1
P1.1.2 P1.2.2 P1.3.2
Processor rack
DATA Houses theTx/Rx
DSS airborne B-kit equipment Internet DATA - 1
Power Supply Power Supply Tx/Rx Power Supply
Cables Provide connections among hardware Connection X Proc X
DATA Msg Proc Radio Radio Msg DATA
Test equipment
Aircraft Platform for the Airborne Segment - 1
VOICE VOICE
Radio P1.1.3 Users on the network 2 P1.3.32
Wireless Wireless
Remote Payload Controller
Msg Sim Msg Sim
Transceiver Host of the Remote Payload Controller (software) 1 Transceiver 1
14 processor
 Tie It All Together

CONOPS,
Users,
Operational Customers,
Missions,
COIs, OV1s Reqs Leadership Software

Functional Data Flow

Use Cases System Reqs Decomposition Diagrams

Test

Context Architecture Interconnect

Diagrams Flow Diagrams Diagrams

Production Test

Architecture Product Entity Equipment

Block Diagrams
Drawings
Diagram Configuration

15 Hardware
 Questions

16
 Actions for Success

❑ Document and review the system development plan

o SEMP or SEIT Plan (what, who, when)
❑ Document and review system operational concepts
o CONOPS
o Missions
o OV1s
o COIs, MOEs, MOPs
❑ Identify, document, and review operational requirements
❑ Describe, document, and review the system functionally
o Functional Decomposition
o Data Flow Diagrams
o Use Cases
❑ Identify, document, and review system requirements

17
 Actions for Success (cont.)

❑ Describe, document, and review the system at the logical level

o Context Diagrams
o Architecture Block Diagrams
o Interconnect Diagrams
o Architecture Flow Diagrams
❑ Describe, document, and review the system physically
o Product Entity Diagrams
o Drawings
o Equipment Configuration Diagrams
❑ Document and review system test and demo plans and procedures
❑ Create and use checklists

18
19