Model-Based

Systems Engineering:

A Practical Approach

25 September 2019

Charles H. PattonCSEP, DTM

INCOSE San Diego

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)

3

Practicality Needn’t Be Cumbersome

Why

• Systems Engineering V Model

4

System Validation Plan

RegionalArchitecture(s)

Feasibility Study/Concept

ExplorationConcept ofOperations

SystemRequirements

High-LevelDesign

DetailedDesign

Software/HardwareDevelopment

Field Installation

Operationsand Maintenance

SystemValidation

SystemVerification &Deployment

SubsystemVerification

Unit/DeviceTesting

Changes andUpgrades

Retirement/Replacement

System Verification Plan(System Acceptance)

SubsystemVerification Plan

(Subsystem Acceptance)

Unit/DeviceTest Plan

Life Cycle Processes

ImplementationDevelopment Processes

Time Line

Document/Approval

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

– Identify interfaces

– Logical and Physical

• Coordination

– Multiple engineering efforts

• Who’s developing which parts of the system

– Accommodate changes

5

Effective Development is the Goal

Collaboration

Coordination

Communication

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

• Hardware

• Software

• Cybersecurity

• Test

• Deployment

• Sustainments, Logistics, Operations and Maintenance

6

We see things differently

Collaboration

Coordination

Communication

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

• System

– Logical

– Physical

– Operational

9

Data Link Processor1

Message

Broker

Services3

Operator

Station

HSI4

FalconView6

EDGE TEXT MSGS +

EDGE MISSION MSGS +

EDGE IMAGE MSGS +

EDGE NAV MSGS +

EDGE STAT & CFG MSGS

STATION TEXT MSGS +

STATION MISSION MSGS +

STATION IMAGE MSGS +

STATION NAV MSGS +

STATION FUEL MSGS +

STATION STAT & CFG MSGS +

STATION TGT SORT MSGS

MAP COMMANDS +

DRAWING COMMANDS +

SIMULATED USER INPUT

Tactical Data Processor2

J-SERIES MSG +

K-SERIES MSG

EDGE FUEL MSGS +

EDGE TGT SORT MSGS

J-SERIES MSG +

K-SERIES MSG

MANAGEMENT MSG

MANAGEMENT

MSG

RC ICD

STATUS MSG

RC ICD

CONFIG MSG

SCNS

Processor5

NAV DATA

ImagesIMAGE IMAGE

Mission Planner7

BIT LOGBIT Logs

BIT LOG STATION

STAT & CFG

MSGS

Emergency

Declassification

Invocation

Processor8

PLATFORM TYPE

How

• Operational

– CONOPS, Missions

– COIs, MOEs, MOPs

– OV1

– Requirements

– Test and Demo Plans

• Functional

– Decomposition

– Data Flow Diagrams

– Use Cases

• Logical

– Context Diagrams

– Architecture Block Diagram

– Interconnect Diagrams

– Architecture Flow Diagrams

• Physical

– Product Entity Diagram

– Drawings

– Equipment Configuration Diagrams

– Checklists

10

Capture the Thinking

How – Operational

• CONOPS, Missions

• COIs, MOEs, MOPs

• OV1

• Requirements

• Test and Demo Plans

11

ID COI MOE MOP

1

Need to increase crop yield for

amount of time and material

used

1.1Crop yields compared to historical

yields under similar conditions

1.1.1 Annual crop yield

1.1.2 Cost of soil amendments

1.1.3 Time (hours) to manage irrigation

2

Need to minimize change

impact on the host irrigation

system

2.1 Percentage change in operability

2.1.1Percentage change to physical

interfaces

2.1.2 Percentage change to user interfaces

2.1.3 Percentage change to user instructions

2.2 Percentage change in componentry

2.2.1 Number of new parts

2.2.2 Number of replaced parts

2.2.3 Number of discarded part

CONCEPT FOR THE PROPOSED SYSTEMThe RSMS is a hardware and software solution applied to an existing irrigation system to monitor soil

conditions and control the application of water-based soil amendments according to a tailorable

parametric model. The RSMS can be configured to accommodate present and short-term forecast

weather conditions. The human-system interface (HSI) provides access to the monitoring and control

functions, and allows the user to tailor the parameters of the heuristic model to best suit on-going local

conditions. Sensors are hot-swappable, are easily moved, and operate wirelessly.

Objective 3.2 Demonstrate exchange of data from ground sensor to central control station via the sensor network.

Entry Criteria

Scenario dry run completed.

Transmission load simulator calibrated.

Test readiness reviewed and approved.

Exit Criteria Data transmitted from sensor, data received at central control station for post-processing and verified by test engineer

Test Scenarios

General: Sensor data transmission, single channel

Scenario 1: 25 kHz Tx in sensor network

Scenario 2: 5 kHz Tx in sensor network

Test Output Data Sensor data logged by central control station.

System configuration files.

Data Analysis

Message latency: Determine average elapsed time between transmission of sensor data from the source sensor and receipt of the sensor data at the central control station.

Message quality: Sensor data transmitted matches data received.

How – Functional

• Decomposition

• Data Flow Diagrams

• Use Cases

12

Remote Soil Management System (1.0)

F1.1

Sense

Conditions

F1.2

Monitor and

Control

F1.3

Deliver

Amendments

F1.5

Human-System

Interface

F1.4

Data

F1.3.1

Adjust

Delivered

Content

F1.3.2

Receive

Delivery

Messages

F1.2.1

Receive

Conditions

Messages

F1.2.3

Determine

Adjustment

Quantities

F1.2.2

Send

Delivery

Messages

F1.2.5

Configure

Sensor

Network

F1.2.4

Configure

Delivery

Control

F1.1.1

Sense

Soil

Conditions

F1.1.3

Transmit

Conditions

Messages

F1.1.4

Receive

Conditions

Messages

F1.4.2

Receive

Weather

Data

F1.4.3

Configure

Model

F1.4.1

Provide

Adjustment

Quantities

F1.5.2

Configure

Sensor

Network

F1.5.4

Configure

Delivery

Control

F1.5.1

Monitor

Operations

F1.5.3

Configure

Model

F1.1.5

Configure

Sensor

F1.2.6

Process

System

Update

F1.2.7

Monitor

Operations

F1.1.2

Sense

Atmospheric

Conditions

Manage

Soil

Conditions1

Manage

System2

CHANNEL CONTROL +

SYSTEM CONTROL

DATA

Sensor

Network

FOW/CCOW

ROW/RCCOW

DATA

Config

LoaderSYSTEM

CONFIG

Test Sensor

Remote

Control

Control Station

REMOTE

CONTROL

REMOTE

CONTROL

REMOTE

CONTROL

FOW/

CCOW

ROW/

RCCOW

ETHERNETRADIO

FREQUENCY

RADIO

FREQUENCY

CL-510

CL-510

ETHERNET

ETHERNET

ETHERNET

RADIO

FREQUENCY

Amendment

Module1.1

Config

Loader

Control

Module1.2

Sensor

Network

Test SensorRemote

Control

Field

Module1.3

Amendment

Module1.1

Config

Loader

SYSTEM

CONFIG

Control

Module1.2

FOW/CCOW

DATA

Sensor

NetworkROW/RCCOW

FOW/CCOW

ROW/RCCOW

SYSTEM

CONTROL

DATATest SensorRemote

Control

REMOTE

CONTROL

Field

Module1.3

REMOTE

CONTROL

DATA

SYSTEM

CONFIG

REMOTE

CONTROL

RSMS0

Config

LoaderSYSTEM

CONFIG

DATA

Sensor

Network

FOW/CCOW

ROW/RCCOW

Test Sensor DATA

Remote

Control

Control

Station

REMOTE

CONTROL

REMOTE

CONTROL

REMOTE

CONTROL

How – Logical

• Context Diagrams

• Architecture Block Diagram

• Architecture Flow Diagrams

• Interconnect Diagrams

13

Remote Soil Management System (1.0)

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

Central Control Station (P1.2)

SensorsA1.1

Monitoring and ControlA1.2

DeliveryA1.3

Human-System InterfaceA1.5

DataA1.4

Weather

Feed

Irrigation

System

F1.3.1

Adjust

Delivered

Content

F1.3.2

Receive

Delivery

Messages

F1.2.1

Receive

Conditions

Messages

F1.2.3

Determine

Adjustment

Quantities

F1.2.2

Send

Delivery

Messages

F1.2.5

Configure

Sensor

Network

F1.2.4

Configure

Delivery

Control

F1.1.1

Sense Soil

Conditions

F1.1.3

Transmit

Conditions

Messages

F1.1.4

Receive

Conditions

Messages

F1.4.2

Receive

Weather

Data

F1.4.3

Configure

Model

F1.4.1

Provide

Adjustment

Quantities

F1.5.2

Configure

Sensor

Network

F1.5.4

Configure

Delivery

Control

F1.5.1

Monitor

Operations

F1.5.3

Configure

Model

F1.1.5

Configure

Sensor

System

Update

Feed

F1.2.6

Process

System

Update

Fault

Signal

Valve

Cmd

Conditions

Conditions

Conditions

Conditions

Delivery

Cmd

Delivery Cmd

Adjustment

Quantities

Delivery

Configuration

Sensor

Configuration

Sensor

Configuration

Delivery

Configuration

F1.2.7

Monitor

Operations

Fault

Signal

Ops

Data

Model

Data

Model

Data

Weather

Data

Adjustment

Quantities

Conditions

Fault Signal

F1.1.2

Sense

Atmospheric

Conditions

Conditions

How – Physical

• Product Entity Diagram

• Drawings

• Equipment Configuration Diagrams

• Checklists

Remote Soil Management System (1.0)

P1.1

Sensor Network

P1.3

Delivery Station

P1.2

Central Control

Station

P1.1.1

Sensor

P1.1.2

Power Supply

P1.1.3

Wireless

Transceiver

P1.3.1

Valve

P1.3.2

Power Supply

P1.3.3

Wireless

Transceiver

P1.2.1

Computer

P1.2.2

Power Supply

P1.2.3

Wireless

Transceiver

P1.2.4

Internet

Connection

14

DATA Tx/Rx Tx/Rx

Msg Proc

DATA

VOICE

Radio

VOICE

DATA

+VO

ICE

DATA

+

VO

ICE

DATA

Msg Sim

Msg Proc DATA

Msg Sim

Radio

Equipment Purpose Quantity Per Site

Lab Flight

Unit under test equipment

Main Processor General system processors 1 1

Main software General system functionality 1 1

Radio Over-the-air connectivity and message processing 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

Payload Control KVM User interface to the channel and system controllers 1 1

Payload Control software Payload Control functionality 1 1

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

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

Power Distribution Unit Distributes power to DSS hardware components 1 1

Processor rack Houses the DSS airborne B-kit equipment - 1

Cables Provide connections among hardware X X

Test equipment

Aircraft Platform for the Airborne Segment - 1

Radio Users on the network 2 2

Remote Payload Controller processor

Host of the Remote Payload Controller (software) 1 1

Test

Production

Tie It All Together

15

Software

Context

Diagrams

Use Cases

CONOPS,

Missions,

COIs, OV1s

Functional

Decomposition

Data Flow

Diagrams

Architecture

Block Diagrams

Product Entity

Diagram

Architecture

Flow Diagrams

Interconnect

Diagrams

DrawingsEquipment

Configuration

Operational

Reqs

System Reqs

Hardware

Users,

Customers,

Leadership

Test

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