Mark Walker: Model Based Systems Engineering Initial Stages for Power &AMP; Energy

L. MARK WALKER, ESEP
Model Based Systems Engineering Initial
Stages (for Power & Energy);
“Get It Right in the First Stages”
BCT LLC
410-562-3421c
LMW107@bct-llc.com
http://www.BCT-LLC.com
Copyright © 2015 by Loren M. Walker.

Problem Statement (Purpose for Paper)-
Of Concern is the Lack of Emphasis/Understanding of:
• System Use Cases development with the Stakeholders/Users
• What should be done prior to a Request For Proposal
• And after receiving an RFP
• Transitioning Knowledge/Info between 3 Life Cycle Teams:
• Pre-Development, Development, Operational Support Teams
• Critical Importance of Operational Concept Documents
• Establishing the First Baseline Products (Pre- RFP)
• The Method used to Implement MBSE and SysML, etc. for
Architectures/Models
• E.g. Object Oriented Systems Engineering Method (OOSEM)
2 Copyright © 2015 by Loren M. Walker.
Focus on Understanding the “Problem(s)” to be Solved
E.g. If you were designing a P&E/ICS Resilience & Recovery System

Applications for Power & Energy Systems
Although this presentation is about a method (OOSEM) and MBSE
concepts & architecture models, the information presented
applies to any system development and the need to capture the
customers’ operational needs, goals, objectives, problems, etc.
• For P&E, consider: Total Environment, Customers/Users (Good
& Bad), Problems, Challenges, Failure Modes, etc. as the
information is presented.
Some references included for P&E stress:
• Security and other “Enabling” Systems
• Causal Analyses
• Failure Modes & Effects Analysis
• Diagnostic Systems for Systems and Highly Integrated System
of Systems

Get It Right in the First Stages : Specific Topics
• OOSEM: “Analyze Stakeholder Needs” Activity
• System Use Case Diagrams Overview & Importance in the First
Stage of a Development
• Integrated System Use Cases, Scenarios, Sequence Diagrams
• The “Initial Integrated Architecture/Models”
• The Essential Operational Documents
• Requirements Hierarchy and Relationship to the Integrated
Architecture
• System Life Cycle and the Evolution of the Integrated Architecture &
Development Milestones
• Manpower Resources throughout the Life Cycle
• Get It Right in the First Stages : Questions/Check List

The OOSEM “Analyze Stakeholder Needs”
This presentation is focused on and an expansion of:
• Object Oriented Systems Engineering Method’s Second Activity:
– “Analyze Stakeholder Needs”*
• Development and Analysis of associated SysML TM architecture diagrams
• Critical Importance of the System Use Cases (SysUC) Diagrams and their Driving
Value throughout a system development & Life Cycle
Reducing the Risk of Developing a System that does not meet Stakeholders’ Operational
Needs, Goals and Expectations &
Minimize Catastrophic Events Impacts
P&E Stakeholder Examples:
Energy Customers/homeowner, Maintenance Crews, Software Engineers, Stockholders,
Companies/businesses, …
AND Hackers, Cyber Attackers, Cyber Counter Measures/Personnel, etc.
Environment:
The total environment for the system(s) must also be analyzed and fully addressed in the
System Requirements and Architecture/Models
Includes: Space Weather, HEMP and Cyber Security
5
*Reference: “A Practical Guide to SysML”, second edition, page 445, etal

Figure 17.2 (Object Oriented Systems Engineering
Method)
6
Figure 17.2
*Reference: “A Practical Guide to SysML”, second edition

Figure 17.5 (Analyze Stakeholder Needs Activity)
7
Figure 17.5
*Reference: “A Practical Guide
to SysML”, second edition

Stage 1- The “V” Diagram System Life Cycle
Stages/Phases
8
High Level
Design
Implementation
Hw, Sw, etc. Build
Subsystem
I&T
Detailed
Design
Hw & SW
Unit I&T
*Typical Single System Development Project-
Contract Award through Delivery & Final Acceptance
Stakeholder Needs,
Feasability Studies, Concept
Development
Operation, Maintenance,
Upgrades & Disposal
System
V&V
Ops Con, Needs
Analysis , System
Requirements
Synthesis Iteration
SoS, V&V
CONOPs, Stakeholder
Needs Development , MOE, MOP, KPPs
System
Use
Cases
Ops Con Doc,
Final/Updated
System Use
Cases
Updated Ops Con
Documents, Manuals,
Training, Upgrades,
Updated Architecture &
Models,
……
Blue: Pre & Post Development/Contract
Brown: Development (Contract) activities

System Use Case Diagram Description
(The First Context Diagram)
• SysUCs & SysUC Diagrams with descriptive Information, are used to
capture and help Define Stakeholder Operational Needs & Activities for
ToBe system (also AsIs)
• Used to Transition Operational Needs, Goals, etc. to Systems
Engineering and Related Products
• Capture the Users/Actors (Good & Bad) & relationships to ToBe System
• Key Communications media with All Stakeholders (Operational),
Technical (Developers), Managers, Support….
• Address Stakeholder identified existing shortfalls/gaps, goals, etc. in
current operational capabilities
• SysUCs are the Foundation/Context Diagram for virtually all additional
system engineering products (reqts, architecture, testing, documents,
LCS …..)
Must address All Stakeholders (Good and Bad)

Paper Focus is on SysML UC and Sequence Diagrams
for First Stage Products/Info
10
SysML
Diagram
Para
metrics
New
Behavioral Structural
Activity
State
Machine
Block
Definition
Internal
Block
Seq
uence
Package
Spec-
Oriented
Un-
changed
Modified
Use
Case
Reqts
Key
act sd stm uc req par bdd ibd pkg
Can also use BPMN diagrams
Other SysML diagrams included
in Integrated Architecture
Package

System Use Cases Context & Initial Integrated
Architecture
11
Stakeholder Need
Statements/Reqts
ToBe Operational &
Mission Capabilities
AsIs Shortfalls &
Gaps
Users (good & bad),
Constraints &
Context/Environment
AsIs Information,
Architectures, etc.
System
Use
Cases
Scenarios
Architecture/
Models
Architecture/
Models
Requirements
V&V-Testing
SE LCS Docs
& Products
Acquisition
Strategy
LC Process
Improvement
Concept Documents:
e.g. CONOP
AsIs & ToBe Business
Processes
Initial Integrated
Architecture/Models
Various Source
Driving Products
SE Dvlp/Life Cycle
Products
Training

First Stage: Stakeholders’System UCs, Scenarios &
Sequence Diagrams
12
System Use Cases are a SysMLTM “Spec Oriented” (Requirements) &
Behavior Diagram.
Virtually all SysML and other Architecture diagrams/Models
are Derived From & Map To Stakeholders’ System Use Case Diagrams
SysML 4 Pillars

System Use Cases Diagram (SysUCD)
• The SysUCDs identify All Stakeholder’s top level Operational Needs,
Goals, Perspectives, Problems, Issues, etc. for ToBe System
• The SysUCDs consolidate the:
– Users/Actors and Organizations (Good & Bad), Driving Uses and
Goals, External Objects, Systems/System Functions
– Boundaries: Users (HMI) and System to External Systems and
Interactions (associations)
• Each SysUCs should include Multiple Scenarios (also failure modes,
intruders, etc.)
• Each Scenario includes 1 or more Sequence and other more detailed
Diagram(s) & Models (e.g. BPMN, Activity, etc.)
SysUC Diagrams are First Architecture Context Diagrams and
Foundation for All Architecture Views/Models
How should the following SysUCD be modified to address Space
Weather, HEMP and Cyber Security/Attacks and Counter Measures?

Example System UC Diagram (top level)
‘Support Executive Manager with Financial Information’
14
Key Users &
Orgs (Good
& Bad)
Ext. System
Functions,
Tools, etc.
System Use Cases, Goals, etc.
(Key Functions/Activities)
System
Boundary
Human
Machine
I/F (HMI)
System to
System
I/Fs
Establishes System Boundaries & Operational & Enabling Elements
with Descriptions (i.e. Key Driving Requirements/Topics)
Enabling Sys
Use Cases
with Actors
uc [Package] Getting Started [ExampleFinancialSUCD]
ToBe Financial System Boundary
Provide Executive
Financial Support
Senior Exec
Analysts
Managers
Trainers
Info & DB
Managers
Provide Info & DB
Capabilities
Provide Performance
Capabilities
Provide Training
Capabilities
«actor»
External Financial
System
«actor»
Backup Storage
System
«actor»
Performance
Tools
Trainees
0..*
1..*
1..*
1..*
1
1..*
1..*
1..*
1..*
1..*
1..*
0..1
1..*

Enabling Systems/Subsystems Capabilities
• System Engineers Must include these Capabilities
• Typically not included/identified by customers/users
• Somewhat invisible to the users
• Enabling Systems/Subsystems
• Security
• Safety
• Diagnostic for degradation, failures and maintenance
• Recovery (Rapid and long term)
• Information and Data Management (databases)
• Training
• Maintenance and Life Cycle Support
• Upgrades/fixes h/w and s/w
• Help Desks
• Redundancy (for failures and maintenance)
• Etc.

Some P&E Examples for CIPR Concerns
• Inputs:
• Solar Storm/GMD: Msg inputs from National Space Weather Agency,GMD induced
power changes
• HEMP: Need inputs from E1, E2 and E3, mainly power changes but also msgs from
DoD, DHLS, Local organizations, etc.
• Cyber Attacks: Inputs from NSA, DHLS, etc., cyber attackers & systems’ IT
accesses, SCADA attacks, etc.
• Personnel involved in counter measures and recovery
• Power system managers, engineers (h/w & s/w), customers,
• System Use Cases (the center ovals):
• Include all H/W & S/W counter measures capabilities for CIPR
• Diagnostic systems to monitor system performance
• For SoS applications, include diagnostic systems/subsystems & personnel that monitor
the Threads through the SoS, system failures, etc.
• External Systems Interfaces:
• Interfaces with DHLS, DoD, Info/database Systems, Support (Help Desks), local
communities and Businesses, Home owners, cyber attack and other support
systems, etc.
Your Suggestions?

SysUC, Scenarios and Sequence Diagrams
17
System
Use Case
Scenario 1:
Typical Support
Exec Process
Scenario 2:
Finding Report
Problems
Scenario X
……
Provide Executive
Financial Support
Cyber
Attacks

For the CIPR Concerns, What Scenarios and
Sequence Diagrams would be included?
Some Examples for the Solar Storm/GME Events:
• Scenarios:
• Add Scenarios for the 5 Levels of Events: G1-G5
• Add Sub Scenarios for each of these
• Include the Sequence Diagrams for each of these Scenarios
What are your thoughts for these Scenarios?
• Think about the HEMP and Cyber Security/Attack SysUCs
• How many Scenarios are there?
• How much detail (sub scenarios and text descriptions) are needed for
these?
• Again, each scenario needs the support of a Sequence Diagram(s)

Concept/Operational Documents
• The Concept/Operational Documents are Critical for:
– Understanding the Stakeholders Operational Needs and Goals in User Operational
Terminology
– Capturing all of the System Use Cases, Scenarios and Sequence Diagrams and
supporting descriptive Information at the Start of the Development
– Are Essential for the Life of the Development
– Lead to Training, Testing, Manuals, etc.
• Key Operational Documents Over Life Cycle:
– Pre Development ‘ToBe’ Concept of Operation (CONOP)
• Written by the Stakeholders with SE/Architects Support
- During Development ‘AsIs’ Operational Concept Document Written by the Developer
with the Stakeholder
- Testing, Manuals, Training for the systems Life Support
• It is Critical that the Concept document address All Failure Modes
• Requirements and Architecture/Models must also address Failures
• Consider the development of Diagnostic Subsystems/Systems
• An Integrated set of Requirements and Architecture/Models are essential
for engineering the system and system of systems interrelationships

Requirements Hierarchy-
Top Level From System Use Cases
1. Initial Stakeholder Mission Requirements/Operational Needs/Goals - Captured
in/related to SysUCDs
– System Use Cases Contents (Actors/Users, Use Cases, Ext. System Functions &
Interactions/associations) & Scenarios’ Descriptions & Sequence Diagrams’ symbols
2. Identified Parameters (values) within Scenario descriptions and Sequence Diagrams
(Measures of Performance?)
– Top Level Stakeholder Operational Performance Needs
3. Key Performance Parameters (KPPs)
– Derived from Stakeholder Operational/Performance Needs & Additional Holistic SE
Reqts, All Categories (IEEE 1233, etc.)
4. Technical Performance Measures (TPMs)
– Derived from KPPs by SEs, LC support, etc.
All Requirements Levels must include:
1 Failure Modes (I.e. Space Weather, EMP, Cyber and other failure modes)
2 Comprehensive/Holistic System Life Cycle Support Requirements
3- Requirements for Diagnostic Subsystems Should be included

Use Cases and Evolution of theArchitecture
21
System
Use
Cases
1
2
3

Manpower Resources
• ROI is very high when using highly trained SEs (e.g. MBSE), Process (e.g.
OOSEM, Lean SS…), H/W & S/W, and similar Stakeholder focused SMEs
• Focus on working with Stakeholders to develop SysUCDs, Scenarios, Info and
supporting Architecture models
• Address all Failure Modes and Effects (Environment, Bad Guys, etc.)
• Support Stakeholders- LC Concept/Operational Documents, etc.
• Number of experts needed dependent on project size, complexity, etc. (e.g. 1/4
time to teams of 20+ for one project, many more for SOS programs)
• Support duration dependent on size, complexity, number of deliver stages/phases,
LC phase, etc.
• SE/process support throughout the system’s Life Cycle to address change
(upgrades, interfaces, changing requirements, user rolls, model updates, etc.)
For P&E and the CIPR concerns: Space Weather (GME), EMP, and
Cyber SMEs are critical, in addition to the P&E and Life Cycle Support
Personnel, Management, SMEs, etc.

Each Stage/Milestone of a Development
• Requirements and Architecture Models Evolve Together
• They must be Totally consistent with each other
• Supporting documents are essential for written text & understanding
• Operational Concept Documents (CONOP, OCD, etc.)
• Must be updated to capture ToBe System Use Cases, Detailed Scenario
Descriptions, and supporting Sequence & other architecture Diagrams/Models
• This information is the basis for following system development activities, processes
and products:
• Requirements Analysis and Derived Requirements
• All remaining & evolving SysML Models: Structure, Behavior (Activities,
States…), Parametrics
• All SE Documents: Plans, Testing, Decisions, Training, …..
• Acquisition Strategy
The Information Needed for a Continued Understanding of the
Customers’ Needs Throughout a System’s Life Cycle

Get it Right in the First Stages :
Ex. Questions toAnswer/Check List
• Did the Team do All OOSEM “Analyze Stakeholder Needs” Activities?
• Did the Team Develop the SysUCs’ Purpose, Scope, Objectives, Goals …. with the
Stakeholders?
• Did the Team Develop & Fully Document Actors/Users (Good and Bad), System Use
Cases, Scenarios and Sequence Diagrams with the Stakeholders during each phase?
(e.g. Concept Documents, Support Manuals)
– Stakeholders, Managers and Development Team Approved?
• Did the Team Develop Fully Define & Document the Required Initial Integrated
Architecture & Models (i.e. an Integrated Architecture Package)?
• Do System Use Cases, Scenarios, Sequence Diagrams and Other SysML Architecture
diagrams Map to and fully address the Stakeholders’ Short Comings/Gaps,
Goals/Objectives, Failure Modes & Effects, Catastrophic Events, …?
• Are the Requirements and Integrated Architecture Models Mapped Exactly to each
other and the System Use Cases, …..& Concept Documents?
• Will the follow-on Contractors/Developers/Managers/Testers/Maintainers, etc. produce
Operational Documents & Integrated Architecture at Required for Development
Milestones & Decision points?
 Will the Contract Require the developer to produce the OCD, etc. and associated
Integrated Architecture Models?
 ……….

“Get It Right in the First Stages”
Summary/Conclusions
 Assure the SysUCDs, Scenarios, Sequence & Integrated Architecture
Models are developed/defined Completely, including All Failure Modes
• Initial Architect Development Activity is within the Stakeholder Needs Analysis
(Define Enterprise Use Cases, ….)
• Documenting SysUCs, Scenarios, Sequence & Architecture Models in an
Operational Concept Document (e.g. CONOP) is critical to:
• Effective Decision Making & Risk Reduction at Key LC Milestones
• Develop First Stage Questions and Check List, Verify at Milestones
• Use & Evolution of the Operational Documents to System Disposal
• Assuring various LC teams understand Stakeholders’ Needs & Expectations
(i.e. the Concept Documents)

Examples of NOT Doing it Right in the First Stage
26

Mark Walker: Model Based Systems Engineering Initial Stages for Power &AMP; Energy

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Mark Walker: Model Based Systems Engineering Initial Stages for Power &AMP; Energy

Similar to Mark Walker: Model Based Systems Engineering Initial Stages for Power &AMP; Energy (20)

More from EnergyTech2015

More from EnergyTech2015 (10)

Recently uploaded

Recently uploaded (20)

Mark Walker: Model Based Systems Engineering Initial Stages for Power &AMP; Energy