MBSE with CORE 100821

Model-Based System Engineering with CORE ® Model-Based Systems Engineering with CORE TM

Course Material t ri l r

Vitech Corporation 2070 Chain Bridge Road Suite 100 Vienna, Virginia 22182-2536 703.883.2270 www.vitechcorp.com 2270 Kraft Drive Suite 1600 Blacksburg, VA 24060 540.951.3322 www.vitechcorp.com

Copyright © 1995-2021 Zuken Vitech Inc. All rights reserved.

No part of this document may be reproduced in any form, including, but not limited to, photocopying, translating into another language, or storage in a data retrieval system, without Vitech’s prior written consent.

Restricted Rights Legend

Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7013 or subparagraphs (c)(1) and (2) of the Commercial Computer Software - Restricted Rights at 48 CFR 52.227-19, as applicable, or their equivalents, as may be amended from time to time.

Zuken Vitech Inc. 2270 Kraft Drive, Suite 1600 Blacksburg, VA 24060 540.951.3322 www.vitechcorp.com

is a trademark of Zuken Vitech Inc. and refers to all products in the CORE

software product family.

Other product names mentioned herein are used for identification purposes only, and may be trademarks of their respective companies.

(Revision Date – January 2021)

Model-Based Systems Engineering

with

Version 2021

1

Administrative Details

• Food

• Coffee, juice, snacks, etc. • Lunch (arrangements and timing)

• Conveniences • Restrooms • Telephones • Schedule

• Preferred start and end time • Breaks

• Lab hours • Questions and answers

Introductions

2

MBSE with CORE

Overall Course Objectives

• Introduce a model-based systems engineering approach that consistently delivers success • Demonstrate how to implement this approach using a systems engineering environment • Solve a sample problem while at the same time, generating representative systems engineering artifacts and documentation • Provide systems engineering knowledge and skills to take back to your team members, project, and organization

3

A Roadmap for This Course

• Setting critical context • Introducing systems engineering • Decoding MBSE • Seeing CORE in action • Taking an integrated approach to (MB)SE • Understanding the problem • Capturing requirements • Visualizing requirements • Filtering, sorting, and documenting • Beginning analysis: concerns and risks

4

MBSE with CORE

A Roadmap for This Course, cont.

• Defining the system context (a black box view) • Defining the system boundary • Visualizing physical architecture • Adding tools to our toolkit • Working with use cases

• Considering states • Introducing behavior • Visualizing behavior

5

A Roadmap for This Course, cont.

• Transitioning from problem to solution • Leveraging threads • Defining integrated behavior • Tracing requirements • Allocating behavior • Defining physical architecture and interfaces • Considering verification and test • Addressing special topics • Wrapping up

Please raise questions and offer perspectives as they occur!

6

MBSE with CORE

An Introduction to Systems Engineering

7

8

MBSE with CORE

Image credit: Alisa Farr for Letter27. farrimages.com

Image credit: www.baaa-acro.com

Image credit: 7Wonders

Image credit: MotorTrend

9

Seeing the Mismatch: Modern Conditions and Classic Approaches

We tend to assume that technological advances will enable us to do what we have always done, only better. However these same technologies imbue our operating environment with escalating non-linearity, complexity, and unpredictability.

Attempts to control complex systems by using the kind of mechanical reductionist thinking … breaking everything down into component parts, or optimizing individual elements … tend to be pointless at best or destructive at worst.

10

MBSE with CORE

Understanding Systems Challenges in Today’s World

Exceeding the capabilities of traditional siloed approaches • System scale

• Mission complexity • Technical complexity • Project team complexity • Dynamic complexity

SE Vision 2025. Copyright © 2014 by INCOSE. All rights reserved.

Image credit: Alisa Farr for Letter27. farrimages.com

11

Defining “System”

System

A system is an arrangement of parts or elements that together exhibit behavior or meaning that the individual constituents do not. INCOSE

An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.

Segment

EIA-632

Subsystem

• A System ‘ is a thing that contains interconnected smaller things, interacts with other things in a larger thing, and does something.’ • has structure, in a larger structure (‘physical’ context) • performs purposeful actions • time sequence of collective actions = behavior • behavior observed at interfaces (‘functional’ context) • “… a system is, and a system does …”

Assembly

Part

12

MBSE with CORE

Systems Engineering

Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.

INCOSE

13

Definitions of Systems Engineering

“Systems engineering is a (thought) process employed in the evolution of a need into an ultimate deployment.” Source: Blanchard and Fabrycky, 2nd edition, 1990 “Systems engineering is the structured, multidisciplinary development of creating complex systems while minimizing risks and satisfying the customer.” Source: INCOSE 1992

SIMILAR • S tate the problem, • I nvestigate alternatives, • M odel the system, • I ntegrate, • L aunch the system, • A ssess performance, and • R e-evaluate

The systems engineering team “owns” the architecture

14

MBSE with CORE

Differing Viewpoints: Subject Matter Experts and Systems Engineers

SMEs view their scope as the largest, most significant, most difficult

SMEs bring essential insights into the “art of the possible”

The systems engineer balances the perspectives yielding a capable, cost effective, and timely system

15

Connecting across the Project: Technical Detail within the Greater Context

“Functioning in an interdependent environment requires that every team possess a holistic understanding of the interaction between all the moving parts.”

“People can only be empowered if they have enough context to make good decisions.”

Image credit: US Department of Transportation

Quotes from Team of Teams , 2015

16

MBSE with CORE

Complementing – not Replacing – Approaches

A SYSTEM is a whole that cannot be divided into independent parts without losing its essential characteristics as a whole.

ANALYTIC THINKING applies an analytic method to separate a system down into its constituent parts. Analytic thinking attempts to explain the behavior of these parts, and then attempts to aggregate this understanding into an understanding of the whole SYSTEM THINKING considers problems and solutions in terms of how the interactions of the parts, and the parts with the whole and its environment, create the properties of the whole. Systems Engineers need to rethink their problem-solving approach in general and innovation in particular – this is system thinking. For further information on systems thinking see The Fifth Discipline by Peter Senge and various publications from Russell Ackoff

17

When to Do Systems Engineering?

The System Life Cycle Model (ISO 15288)

Highest level of SE intensity is concentrated in these phases

SE focus in later stages centers on Operation, Maintenance, Sustainment

Utilization & Support Stage

Concept Stage

Development Stage

Production Stage

Retirement Stage

Lifecycle performance effects the next version

Systems engineering applies across all phases of the lifecycle

18

MBSE with CORE

Four Primary SE Activities

P HYSICAL A RCHITECTURE

B EHAVIORAL A RCHITECTURE

V ERIFICATION & V ALIDATION

R EQUIREMENTS

19

Three Systems

20

MBSE with CORE

Failure to Think Systemically

21

Failure to Think Systemically

Blackwater Wildlife Preserve

22

MBSE with CORE

Why Do Systems Engineering: The Financial Case

• Cope with complexity • Avoid omissions • Avoid invalid assumptions • Make informed, defensible decisions • Manage change • Design most efficient, economic, and robust solution • Achieve greater design control

Method 1 —

Method 2 —

Method 3 —

Hypothetical Project

Total Costs

Top-Down

Breakdown

Project Phase

Bottom-Up Cost

Requirements

1 x

1 x

1 x

Design

8 x

3 - 4 x

4 x

Build

16 x

13 - 16 x

7 x

Test

21 x

61 - 78 x

28 x

Operations 29 x 157 - 186 x 1615 x Source: Error cost escalation through the project life cycle - NASA Johnson Space Center

It is not hard to know when system engineering fails, because when something important goes wrong it usually makes the news fast. INCOSE

23

Enabling Project Success: The Motivation for SE

✓ Understanding the problem

✓ Integrating the team

✓ Defining the seams

✓ Addressing the gaps

✓ Guarding the why

Image Credit: Defense Acquisition University

24

MBSE with CORE

Enabling Project Success: The Motivation for SE

SE Criticality Increases as Projects become Complex

All Projects Benefit from SE

Projects that apply SE best practices perform better than projects that do not

25

Decoding MBSE What model-based systems engineering is and what it isn’t

26

MBSE with CORE

Classical Engineering in a Complicated World

R

F

L

R1

F1

L1

F2

R1.1

L1.1

F2.1

R1.2

L1.2

F2.2

R2

L2

F3

L3

R2.1

F3.1

L3.1

R2.2

F3.2

L3.2

R2.3

F3.3

L3.3

R3

F4

L4

R4

F4.1

L4.1

R4.1

F4.2

L4.2

R4.2

F5

L5

R5

F6

F6.1

F6.2

R EQUIRED

B EHAVIOR

P HYS A RCH

C ONCEPT

D EVELOPMENT

27

From Static Products to Intelligent Systems of Systems

Smart, Connected Product

Systems of Systems

Product

Smart Product

Product System

Electro-mechanical

Cyber

Connected

Coordinated

Collaborating

Adapted from Claas, November 2019.

Icons made by Freepik from www.flaticon.com

28

MBSE with CORE

Towards MBSE: A Practice in Transition

Future

Traditional

•

Specifications

ATC

Pilot

Airplane

•

Interface requirements

Request to proceed

Authorize

Initiate power-up

• System design

Power-up

Report Status

Direct taxiway

•

Analysis & Trade-off

Initiate Taxi

Executed cmds

•

Test plans

Moving from document-centric to model-centric

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

29

Models and MBSE

Model: a graphical, mathematical (symbolic), physical, or verbal representation or simplified version of a concept, phenomenon, relationship, structure, system, or an aspect of the real world. www.businessdictionary.com

Model: a physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process. DoD5000.59-M 1998

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. INCOSE SE Vision 2020, September, 2007

Much of the confusion in MBSE is the ambiguity in “model”. If everything is a model, everything qualifies as MBSE.

30

MBSE with CORE

“Demythify” the Transition: Recognizing What MBSE Is Not

31

Understanding the Transition: From Ambiguity to Clarity, “One Idea in One Place”

32

MBSE with CORE

Understanding the Transition: Clarify “Model” in MBSE

33

Identifying the Foundation for MBSE and More: The Systems Metamodel Requirements a system’s why

basis of

specifies

verified by

Verification a system’s proof

Behavioral Architecture a system does

Physical Architecture a system is

verified by

verified by

performed by

34

MBSE with CORE

Identifying the Foundation for MBSE and More: The Systems Metamodel

Color Code

Requirement Element

Functional Element

built from / kind of

Physical Element

Interface Element

Component

Verification Element

Other Element

exposes

Port

connected to

Link

includes

35

Identifying the Foundation for MBSE and More: The Systems Metamodel

Color Code

Resource

Exit

Requirement Element

Functional Element

captures / consumes / produces

exits by

built from / kind of

Physical Element

Interface Element

Component

Function

performs

Verification Element

Other Element

decomposed by

inputs / outputs / triggered by

exposes

Port

connected to

Link

Item

transfers

includes

decomposed by

36

MBSE with CORE

Identifying the Foundation for MBSE and More: The Systems Metamodel

triggered by

Transition

Event

entered by / exited by

Color Code

Resource

Exit

Requirement Element

Functional Element

State

captures / consumes / produces

exits by

built from / kind of

exhibits

incorporates

Physical Element

Interface Element

decomposed by

Component

Function

performs

Verification Element

Other Element

decomposed by

inputs / outputs / triggered by

exposes

Port

connected to

responsible for

Link

Item

transfers

includes

decomposed by

37

Identifying the Foundation for MBSE and More: The Systems Metamodel

triggered by

Transition

Event

entered by / exited by

Color Code

Resource

Exit

Requirement Element

Functional Element

State

captures / consumes / produces

exits by

built from / kind of

exhibits

incorporates

Physical Element

Interface Element

decomposed by

Component

Function

performs

Verification Element

Other Element

elaborated by

involves / describes

Use Case

decomposed by

includes / extends / kind of

basis of / specifies

inputs / outputs / triggered by

elicits

specifies

Requirement

exposes

refined by

Port

connected to

responsible for

Link

Item

transfers

includes

decomposed by

38

MBSE with CORE

Identifying the Foundation for MBSE and More: The Systems Metamodel

triggered by

Transition

Event

entered by / exited by

Color Code

Resource

Exit

Requirement Element

Functional Element

State

captures / consumes / produces

exits by

built from / kind of

exhibits

incorporates

Physical Element

Interface Element

decomposed by

Component

Function

performs

Verification Element

Other Element

elaborated by

involves / describes

Use Case

decomposed by

includes / extends / kind of

basis of / specifies

inputs / outputs / triggered by

elicits

specifies

Requirement

exposes

refined by

verified by

verified by

verified by

verified by

Port

Verification Requirement

basis of / specifies

verified by

specifies

verified by

connected to

Test Configuration

Test Activity

employs

responsible for

accomplished by

decomposed by

Verification Event

includes

Link

Item

transfers

includes

decomposed by

39

Identifying the Foundation for MBSE and More: The Systems Metamodel

triggered by

Transition

Event

entered by / exited by

Color Code

Resource

Exit

Requirement Element

Functional Element

State

captures / consumes / produces

exits by

built from / kind of

exhibits

incorporates

Physical Element

Interface Element

decomposed by

Component

Function

performs

Verification Element

Other Element

elaborated by

involves / describes

Use Case

decomposed by

includes / extends / kind of

basis of / specifies

inputs / outputs / triggered by

elicits

specifies

Requirement

exposes

refined by

verified by

verified by

verified by

verified by

Port

Verification Requirement

basis of / specifies

verified by

specifies

verified by

connected to

Test Configuration

Test Activity

employs

responsible for

accomplished by

decomposed by

Verification Event

includes

Link

Item

transfers

includes

decomposed by

generates

results in

causes

assigned to

Organization

Concern

Risk

40

MBSE with CORE

Identifying the Foundation for MBSE and More: The Systems Metamodel

triggered by

Transition

Event

entered by / exited by

Color Code

Resource

Exit

Requirement Element

Functional Element

State

captures / consumes / produces

exits by

built from / kind of

exhibits

incorporates

Physical Element

Interface Element

decomposed by

Component

Function

performs

Verification Element

Other Element

elaborated by

involves / describes

Use Case

decomposed by

includes / extends / kind of

basis of / specifies

inputs / outputs / triggered by

elicits

specifies

Requirement

exposes

refined by

verified by

verified by

verified by

verified by

Port

Verification Requirement

basis of / specifies

verified by

specifies

verified by

connected to

Test Configuration

Test Activity

employs

responsible for

accomplished by

decomposed by

Verification Event

includes

Link

Item

transfers

constrains / uses parameter from

includes

decomposed by

generates

results in

causes

assigned to

Organization

Constraint Definition

Concern

Risk

41

Identifying the Foundation for MBSE and More: The Systems Metamodel

…more than diagrams

…more than a data dictionary

…more than capture

…more than specification

…more than the

system of interest

42

MBSE with CORE

Essential Characteristics of the Systems Model

A system is a whole that cannot be divided into independent parts without losing its essential characteristics as a whole. It follows from this definition that, a system’s essential defining properties are the product of the interactions of its parts, not the actions of the parts considered separately. Therefore, when a system is taken apart, or its parts are considered independently of each other, the system loses its essential properties. Furthermore, when performance of each part taken separately is improved, the performance of the system as a whole may not be, and usually isn’t. --Russell Ackoff

43

What MBSE is All About

• Making system descriptive and analytical models explicit , coherent , consistent , and actionable • Evolution from low-fidelity representations in documents to higher-fidelity, richer representations • Improved granularity of knowledge capture for management, analysis, and learning • One architectural model connecting multiple analytical models • Leveraging models for communication and analysis • Developing an “authoritative source of truth” for system design and specification • Ensuring consistent design and specification (when done well) • Providing an explicit system model to engineering teams An evolution – not revolution – in thinking and approach… An evolution that offers transformative results

44

MBSE with CORE

Moving the Focus from Engineering Artifacts to Engineering Systems

45

Aligning across the Engineering Enterprise Right Data, Right Place, Right Time, Right Presentation

Customer

Program Mgt.

Configuration Management

Chief Engineer

Publications

Hardware

Training & Personnel

Software

Environmental

Systems Engineering Team

Safety

Operations

Reliability, Availability, Maintainability

Maintenance

Logistics

Manufacturability

Test

Security

46

MBSE with CORE

Transforming Engineering: A New Manifesto

47

SE, MBSE, and Digital Engineering

Digital Engineering critical enabler for the modern engineering enterprise MBSE connective tissue of the Digital Engineering environment Systems Engineering technical connective tissue of the project team

48

MBSE with CORE

CORE Environment

49

CORE Concept of Operations

Data Interchange Files

Keyboard Entry, Data Extractors, & Parsers

SE Expertise

Inputs

Model

C.1

Perform Customer Functions

Customers

products

status

requests

0

AND

Operate Image Management System

AND

Image Management...

data

tasking

C.2

Perform Collector Functions

Collectors

Formal Specifications

Custom Reports, Queries, & WEB Publishing

Views

50

MBSE with CORE

The CORE Technology

• Systems metamodel • Provides a structure to capture and communicate all aspects of the system through a proven information model • Reflects the language of the systems engineer • System design repository • Contains and preserves the integrity of the system model • Exposes the current state of engineering to the entire engineering team • View “generators” • Guarantees consistency and integrity of all design artifacts • Updates to any view result in automatic updates to all other affected views managing the bookkeeping so that the team can focus on engineering

The CORE technology empowers engineering teams to build a complete and integrated system definition

51

CORE Product Configuration

52

MBSE with CORE

CORE Systems Metamodel Concepts

Systems metamodel (also known as the System Definition Language) is an extended natural language in ERA format

CORE Concept

English Equivalent

CORE Example

• Requirement Accept Requests • Function Accept And Format Request • Component Command Center Subsystem • Requirement basis of Functions • Functions are allocated to Components

Class / Element

Common Noun / Particular Noun

Relationship

Verb

Attribute

Adjective

• Description • Number

Resource consumed by Function • Amount • Acquire Available (hold partial)

Relationship Attribute

Adverb

Parameter

N/A

Design-dependent variables (mass, size, reliability, etc.)

Structure

N/A

Viewed as activity diagram or enhanced FFBD

53

Seeing a Partial Systems Engineering Example

DOCUMENT

documents (documented by)

documents (documented by)

• Number • Description • Type

REQUIREMENT

COMPONENT

• Number • Description • Type • Origin

specifies (specified by)

• Number • Description • Type

FUNCTION

specified by (specifies)

performs (allocated to)

• Number • Description • Duration • Exit Logic

54

MBSE with CORE

CORE Walkthrough A quick introduction to the interface

55

Exploring CORE

• Launching CORE and logging in • Importing a project • Navigating the project explorer • Project properties • Facilities, folders, and elements • Element property sheet • Diagrams and the diagram palette • Exiting CORE

56

MBSE with CORE

Launching CORE

1. Open the Windows Start menu 2. Select CORE 9 folder 3. Select Empty Repository

57

Logging into CORE 1. Enter your password (“admin” is the default password for the Administrator account) 2. Click Login You can select your repository (local or CORE server) We will use the Administrator account in class, but you should not use this account on a day-to-day basis

58

MBSE with CORE

Registering for Technical Resources

59

Reviewing the CORE Home Screen

60

MBSE with CORE

Accessing Commands via the File Menu

1. Click File to access the file menu Commands on the file menu are global Import and Export load and save project information files to and from the CORE repository When working locally, information is stored in memory and the repository must be periodically saved or exported When connected to a CORE Server, information added to a project is saved in real-time to the repository without need for an explicit save or export command

61

Importing a Project File into CORE

1. Select the File menu 2. Select Import > CORE Data File 3. Navigate to the specified folder 4. Select “Fast Food Sample.xml” 5. Click Open

C:\Program Files (x86)\Vitech\CORE 9\Data\Samples

62

MBSE with CORE

Stepping through the Import Wizard

63

Opening SAMPLE: Fast Food Project 1. Click Open Project 2. Select the project 3. Click Open

CORE can have multiple projects open simultaneously. Each open project has at least one project explorer open.

64

MBSE with CORE

Menus and Toolbars

More Commands including toolbar editor

Context-Sensitive Commands (highlighted or shaded based on current selection)

CORE icon reference guide (accessible from Help > Documentation) and tool tips are is an essential resources when learning the toolbar

65

Specifying Project Properties 1. In the project panel, select “Properties ” The project property sheet provides top- level information on the project and its configuration • Organization information • Customer information • External file paths • Completeness and integrity checkers • Project configuration settings

66

MBSE with CORE

Navigating within a Project

The project panel enables navigation of the project by packages or by classes Packages allow you to group any blend of elements together for model management and navigation purposes Classes group all elements of a given type together into folders and subfolders 1. Click the plus sign in front of “All Classes” to expand the facility class list Facilities allow you to view a subset of the classes in the project 2. Click the minus sign in front of “All Classes” to collapse the facility class list

67

Understanding “Schema” and “Facilities”

• Schema • Collection of all element classes, attribute definitions, relationship definitions, and parameter definitions are available to the systems team • Instantiation of the systems metamodel in a database • Facility • Collection of related element classes grouped together for visibility • Subset of the total schema • All Classes – all classes

• Essentials – primary classes used for basic systems engineering • Program Management – classes used for program management • Systems Engineering – classes used for systems engineering • Document Management – primary classes used in generating specifications • Verification – classes used for verification definition and tracking

68

MBSE with CORE

Accessing Elements 1. Select Component in the project panel Elements panel shows elements in the selected class / folder An element is an object corresponding to a given class definition in the model New elements can be created multiple ways • the New Element command in the toolbar • the New > Element command in the Data menu • the Insert key • double-clicking the class name

69

Accessing Information about an Element

1. Select “Fast Food System” in the elements panel Selecting an element populates the property sheet with all information about the element • Main attributes • Secondary attributes • Parameters • Diagnostics • Relationships • Views

70

MBSE with CORE

Opening a Property Sheet

1. Double- click “Fast Food System” in the element panel to open the property sheet as a separate window Double-clicking an element anywhere in CORE is a shortcut to open the property sheet The property sheet allows us to • Characterize the element (the upper region) • see the valid relationships types (the lower-left region) • see the current relationships and their attributes (the lower-right region) 2. Close the property sheet

71

Changing an Attribute and Accessing Versions

1. In the project explorer, make a change to the Description attribute 2. Click in the Doc. PUID attribute When you change fields or close a window, CORE stores the changed value 3. Click the versioning icon at the left of the Description pane The version dialog allows you to access and restore previous versions. Project administrators determine which attributes should be versioned. 4. Click OK to close the version dialog

72

MBSE with CORE

Exploring Secondary Element Attributes

1. Click the “Secondary” tab Secondary attributes are additional

information of interest about the element as well as tool-dependent fields that CORE uses to manage and represent elements Project administrators determine which attributes are shown on the Main Attributes tab and which are shown on Secondary

73

Specifying Parameters

1. Click the “Parameters” tab 2. Click Add/Remove to edit the parameters for the element Parameters are design-dependent variables to manage the numerics of the design and can be referenced in text attributes Parameters allow you to specify an objective value (design target) New defines a new parameter for this class

74

MBSE with CORE

Leveraging Parameters: Descriptive Text, Computable Numerics Parameters can be inserted into any text field

1. Click the “Main Attributes” tab 2. Click in the Description pane 3. Right-click to access the context menu a) Select Insert Parameter b) Select the parameter previously added or create a New Parameter The selected parameter field is inserted into the text using markup language. The parameter value can only be edited via the parameters tab, but the value in the text field will be automatically updated. When output in a report or on a diagram, the markup language is hidden

75

Reviewing Element Diagnostic Errors

1. Click the “Diagnostics” tab Completeness errors reflect where attributes are incomplete or relationships don’t exist (e.g., a leaf -level Requirement that does not trace into the solution architecture) Consistency errors reflect inconsistencies in the descriptive architecture (e.g., an Item between Functions that is not properly mapped to a connecting Link ) The desired completeness and consistency checkers are specified as part of the project properties. These can be customized based upon a team’s methodology or schema extensions.

76

MBSE with CORE

Visualizing Completeness and Consistency Checks

Completeness

Consistency

77

Opening Diagram Views

Diagrams can be accessed using the diagram tabs at the bottom of the project explorer, the Data >> Element menu, or the Views toolbar • clicking the tab accesses the view within the project explorer • selecting a diagram via the Views toolbar or menu opens the diagram in a separate window The commands and behavior are the same whether you use a diagram tab or a separate window 1. Ensure “Fast Food System” is selected in the elements panel 2. Click the “Structure BDD” tab to open the block definition diagram

78

MBSE with CORE

Navigating the Diagram Controls

Views toolbar to open diagrams on the selected element

Insert lists •

Constructs Key Entities All Entities

• •

Diagram Elements table

79

Setting Diagram Properties

1. Select View > Local Diagram Options or the Diagram Options toolbar button The diagram options control the style settings for the diagram and diagram objects 2. Click the “Use Local Icon Settings” checkbox Local icon settings allows you to override project preferences for diagram formatting Options such as color and font style for a given diagram object are controlled by selecting the object(s) and using the controls in the toolbar

80

MBSE with CORE

Reviewing the Presentation Diagram Toolbar

Toggle Frame / Image

Collapse Node

Set Hierarchy

Expand Node

Set Layout

Toggle Bold

Toggle Italic

Toggle Display Grid

Align Nodes Auto-size Nodes

Set Text Color

Diagram Options

Set Line Color

Set Icon Template

Set Fill Color

Change Scale Set Display Mode

Set Image

Show / Hide Display Object Clear Custom Colors and Sizing

81

Exiting CORE

When you want to end your session 1. Select the application menu 2. Select the Exit command

If you are working locally and have made changes, you will be prompted to save your repository If you have not made changes, you will be told that all changes have been saved, and you will be prompted to confirm you wish to exit

82

MBSE with CORE

Setting Up Your Project

83

Getting Started with CORE: Configuring Users and Projects

• Creating a new user account

• Creating a new project

• Setting project permissions

• Setting project and user preferences

84

MBSE with CORE

Accessing the Administrative Tools

1. In the project explorer, select the Tools > Administrative Tools Administrative Tools allow us to manage • Projects • Users • Groups • Current sessions

85

Creating a New User Account 1. In the Tools panel, select “Users” 2. Click the New User toolbar button The New User dialog specifies the username

and password for the account 3. Enter “ JDoe “ as the username 4. Enter “Welcome” as the password 5. Click OK Usernames must be at least three characters long. Passwords must be between five and sixteen characters long.

86

MBSE with CORE

Editing User Account Properties

1. Double- click “ JDoe ” to edit the user properties The user properties allow you to specify • full name (for descriptive purposes) • description • email (for change notifications) • account disablement (for temporary lockout) • user privileges (system administrator and project creation) 2. Click OK

87

Specifying Groups

Groups allows you to • Create a new group • Edit properties and membership for a group • Delete a group Best practice for managing permissions is • Set up user accounts • Set up groups • Assign users to groups • Assign permissions to groups, not users

1. Close the Administrative Tools

88

MBSE with CORE

Creating a New Project

1. In the project explorer, select “Home” in the left pane 2. Select “New Project” 3. Set project name (“Geospatial Library Class Project”) 4. Select schema type (“Base Schema v90”) 5. Click OK Permission level and base schema must be set during project creation Versioning and audit logging can be changed at any time via the Administrative Tools

89

Setting Our Project Properties Project properties are settings and descriptive values for a given project

1. Set Base Path and External Graphics Path 2. Click the “Secondary” tab to browse the additional project properties 3. (Optional) Enter Organization Name and Organization Address 4. (Optional) Enter Customer Name and Customer Address These properties will be used when managing external files and for generating documents

Base Path -> C:\Program Files (x86)\Vitech\CORE 9 Graphics -> C:\Program Files (x86)\Vitech\CORE 9\Bitmaps

90

MBSE with CORE

Editing Project Permissions Project permissions are managed from the Projects tab of the Administrative Tools or from the Project menu • Click Project > Manage > Set Project Permissions • Selection User or Group • Select and set permissions User/group permissions are set by checking the appropriate boxes for • Read • Write • Create Element • Folder • Administrator

91

Editing Permissions at the Element Level

If you wish to set permissions for an element 1. Select the elements of interest 2. Right-click to access the context menu 3. Select the Set Permissions command 4. Click Read, Write, Delete, and/or Administrator to set the permissions for each user/group

92

MBSE with CORE

Editing Permissions at the Attribute Level

If you wish to set permissions for a attributes of an element

1. Select the elements of interest 2. Right-click to access the context menu 3. Select the Manage > Set Attribute Permissions command 4. Select the desired attribute 5. Click Read, Write, Deny Read, or Deny Write to set the permissions for each user/group

93

Editing Project Preferences

Project Preferences provide consistency across the project

94

MBSE with CORE

Editing User Preferences

User Preferences customize the way of working for the user

95

Saving Your Work

96

MBSE with CORE

CORE File Types

• The File > Save Repository and Save Repository As commands save all information as a repository file (.c90) • Fast, binary save • Can reopen the CORE with that repository by double-clicking the .c90 file • Not intended for sharing • The File > Export > CORE Data File command generates an XML file for exchange and archival purposes (.xml) • Slower, ASCII-based save • Used to exchange data with other CORE users • Can specify what content to export • Other File > Export commands provide additional flexibility

Regularly save your repository (the frequency is a function of your pain threshold). Export your project periodically (e.g., daily, weekly, at baseline points, etc.)

97

Exporting from the CORE Repository

Export your project periodically (e.g., daily, weekly, at baseline points, etc.)

98

MBSE with CORE

Predefined Export Options with Complete Flexibility • Project Backup – all project data (default option) • Project Baseline – project backup with change history cleared upon import

• Project Database Changes – change history • Project Template – schema & utilities, no data • Project Schema – changes to the systems metamodel • Users and Groups – all user & group definitions • Full Repository Backup – all projects, users, groups, scripts, and reports • Advanced Options – customize your export

99

Save Your Work

Either 1. Save your repository or 2. Export a CORE Data File (recommended)

100

MBSE with CORE

An Integrated Approach and Timeline for (MB)SE

101

An Integrated, Layered Approach to (MB)SE

Dgn V&V

BEH

REQ

ARCH

Level Of Detail

Source Documents

LEVEL 1

Dgn V&V

BEH

REQ

ARCH

LEVEL 2

Dgn V&V

BEH

REQ

ARCH

LEVEL n

102

MBSE with CORE

Behavioral Architecture (glass box perspective)

Operational Architecture

Physical Architecture

System Definition (black box perspective)

Enterprise Perspective

BASIS OF

ALLOCATED TO

REQ

ARCH

BEH

C ON

R ISK

UC

UC

P ROBLEM S PACE

S OLUTION S PACE

103

SE Activities Timeline for Top-Down Design

0. Define Need & System Concept

Activity bars represent movement of “center of gravity” of systems engineering team (concurrent engineering is assumed)

1. Capture & Analyze Orig. Requirements

2. Define System Boundary

3. Capture Originating Architecture Constraints

4. Derive System Threads

5. Derive Integrated System Behavior

6. Derive Component Hierarchy

7. Allocate Behavior to Components

SCHEDULE

8. Define Internal Interfaces

9. Select Design

10. Perform Effectiveness & Feasibility Analyses

11. Define Resources, Error Detection, & Recovery Behavior

12. Develop Verification & Validation Requirements/Plans

13. Generate Documentation and Specifications

104

MBSE with CORE

SE Activities Timeline for Reverse Engineering

8. Update System Boundary

then modify top-down

Find the top,

7a. Modify Requirements & Architecture Constraints

7. Derive As-Built System Requirements

6. Derive As-Built System Threads

6a. Modify System Threads

5. Aggregate to As-Built System Behavior

5a. Modify & Decompose System Behavior

4. Derive As-Built Behavior of Components

4a. Allocate Behavior to Components

3a. Refine Component Hierarchy

3. Capture Component Hierarchy

2a. Define Interfaces

2. Capture Interfaces

SCHEDULE

1. Define System Boundary

9. Select Revised Design

10. Perform Effectiveness & Feasibility Analyses

11. Capture Error Detection, Resource, & Recovery Behavior

12. Develop Verification & Validation Requirements/Plans

13. Generate Documentation and Specifications

105

High-Level Overview of Steps We Will Follow

• Capture requirements • Analyze requirements • Define the system boundary • Analyze use cases and threads • Define integrated behavior • Trace requirements • Define physical architecture • Allocate behavior • Analyze interfaces • Defining verification and validation

106

MBSE with CORE

Essential Tasks Before You Start

Plan the activity • Prepare a Systems Engineering Plan (e.g., SEP) • Capture process, method, and tool guidance, including conventions • Tailor the plan to your project Make sure you assign responsibility • Define the people who retain authority over the system requirements, behavioral architecture, physical architecture, interfaces, and test and integration plan

107

Step 0: Defining Need and System Context Outside our scope, inside our responsibility

108

MBSE with CORE

Seeking the Enterprise Perspective: Defining Purpose, Context, Effectiveness

• Answer what the system is trying to achieve, why, and how well • Learn about the situation • Align the stakeholders and the team • Get commitment to action • Enables • Eliminating costly, complex unnecessary features • Adding simple features that bring great value • Identifies and addresses entangled social and technical issues

109

Appreciating the Enterprise Perspective: Insights from Andrew McNaughton / HS2

• “Why” is not an engineering decision • The why behind your system is business, social, or political • Consultation (listening) • The only way you get permission • The only way to get engagement • Requires engaging the other party on their terms • From their perspective • In their notation • "95% of evidence is why we didn't do something" • Decisions, process, and evidence will be challenged

110

MBSE with CORE

Understanding the Operational Architecture: What the System Will Do and Why • Defines the missions and in what scenarios • Interactions with other systems & environment • Measures of operational performance for interactions • Operational concept (how the system will perform its mission & how it will fulfill its purpose) • Considers sunny and rainy day scenarios • Reflects who will use the system and how it will

evolve over time • Operator context • Perception of value • …

111

Requirement

refined by

Capturing and Structuring the Problem

112

MBSE with CORE

Requirements Capture in Context

0. Define Need & System Concept

Activity bars represent movement of “center of gravity” of systems engineering team (concurrent engineering is assumed)

1. Capture & Analyze Orig. Requirements

2. Define System Boundary

3. Capture Originating Architecture Constraints

4. Derive System Threads

5. Derive Integrated System Behavior

6. Derive Component Hierarchy

7. Allocate Behavior to Components

SCHEDULE

8. Define Internal Interfaces

9. Select Design

10. Perform Effectiveness & Feasibility Analyses

11. Define Resources, Error Detection, & Recovery Behavior

12. Develop Verification & Validation Requirements/Plans

13. Generate Documentation and Specifications

113

Where Do You Find Requirements? Reflections of Enterprise Perspective and Operational Architecture

• System Concept Paper • Executive Order • Concept of Operations • Statement of Work • Vendor Package/Contract • Preliminary Specification

• Change Request Trade Study Report • Standards (MIL-STD or Commercial) • Meeting Minutes (approved)

• Business Plan • Market Analysis

114

MBSE with CORE

Desired Characteristics of Requirement Statements

• Necessary – remove it if the statement is not needed • Implementation independent – state what is required, not how the requirement is met • Unambiguous – generates a common understanding • Complete – can be understood in isolation

• Singular – addresses one thought • Feasible – is inherently possible • Verifiable – can confirm the requirement is satisfied • Correct – properly expresses the stakeholder expectation • Conforming – conforms in look and feel to organizational standards Additional information available in INCOSE Guide for Writing Requirements

115

Desired Characteristics of Requirement Sets

• Complete – represents the full definition of the stakeholder expectations • Consistent – reconciled and individual statements do not conflict with one another • Feasible – can be satisfied by a solution that is obtainable within life cycle constraints • Bounded – establish the system scope and do not address subjects outside that scope • Structured – organized such that sub-sets of requirement statements can be identified

Additional information available in INCOSE Guide for Writing Requirements

116

MBSE with CORE

Overview Picture of the Geospatial Library (GL)

Customers

Image Collectors

Geospatial Library

117

Reviewing the Geospatial Library Source Document

See Handout

118

MBSE with CORE

Capturing and Decomposing Originating Requirements

• Capture the source document • Extract top-level or parent source requirements capturing source attributes (paragraph title, paragraph number, origin, etc.) • Provide traceability from the source document to the parent originating requirements • Decompose composite source requirements being careful not to change the meaning • Provide traceability from each parent requirement to its children • Continue the decomposition of requirements into “children” until each leaf-level requirement is a single, verifiable statement

119

Capturing Requirements: A Visual Perspective

• Objective is source requirements in single, verifiable statements (decompose composite requirement statements) • Record source requirement statement in the description attribute of a Requirement • Reflect traceability between source document and first level Requirement with documents/documented by relationship • Maintain traceability between parent Requirement and child Requirement with the refined by/refines relationship

documented by

Source Document

System

documents

X

Parent Requirements

refined by

refined by

Child Requirements

refined by

Leaf node Requirements trace to other elements

120

MBSE with CORE