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

[email protected]

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

Prov ide Executiv e

Financial Support

Senior Exec

Analysts

Managers

Trainers

Info & DB

Managers

Prov ide Info & DB

Capabilities

Prov ide Performance

Capabilities

Prov ide 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 the Architecture

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 to Answer/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