MBSE with GENESYS 2024

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

Course Material

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-2023 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 GENESYS software product family. Other product names mentioned herein are used for identification purposes only, and may be trademarks of their respective companies.

(Revision Date – December 2023)

Table of Contents Slide

Introduction ......................................................................................................................................1 Decoding MBSE ................................................................................................................................ 26 GENESYS Environment/Walkthrough ................................................................................................ 51 Setting up Your Project ....................................................................................................................89 An Integrated Approach and Timeline for (MB)SE ........................................................................... 101 Defining Need and System Context................................................................................................. 108 Capturing and Structuring the Problem........................................................................................... 113 Archiving your Work ...................................................................................................................... 155 Visualizing Requirements ............................................................................................................... 159 Analyzing Requirements – Concerns and Risks ............................................................................... 174 Generating Artifacts ....................................................................................................................... 205 Continued Requirement Analysis – Typing Requirements .............................................................. 210 GENESYS Utilities ........................................................................................................................... 219 Requirements Traceability and Identification.................................................................................. 238 Defining the System Boundary ....................................................................................................... 245 Working with Images and Presenting Results.................................................................................. 277 Visualizing Physical Architecture .................................................................................................... 286 Leveraging Use Cases ..................................................................................................................... 301 Considering States ......................................................................................................................... 318 Introducing Behavior...................................................................................................................... 327 Seeing Behavior in Practice ............................................................................................................ 340 Defining the Behavioral System Context ......................................................................................... 380 Visualizing Behavior ....................................................................................................................... 397 Coffee Break .................................................................................................................................. 418 From Problem to Solution – Behavioral Threading .......................................................................... 421 Defining Integrated System Behavior.............................................................................................. 450 Analyzing Behavior ........................................................................................................................ 455 Partitioning and Relating Integrated Behavior ................................................................................ 467 Tracing Requirements to Behavior.................................................................................................. 491 Allocating Behavior to Physical Architecture ................................................................................... 498

Refining Physical Connections ........................................................................................................ 532 Verification Requirements and Test Planning.................................................................................. 550 Wrapping Up ................................................................................................................................. 564

Model-Based Systems Engineering with

Version 2023 RevA

1

Administrative Details

• Food – In Person

• Coffee, juice, snacks, etc. • Lunch (arrangements and timing) • Conveniences – In Person

• Restrooms • Telephones

• Schedule

• Preferred start and end time • Breaks

• Lab hours – In Person • Questions and answers

Introductions

2

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 GENESYS 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

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

An Introduction to Systems Engineering

7

8

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

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

What is a System?

• “A set of things working together as parts of a mechanism or an interconnecting network.” ~Webster’s Dictionary • “An arrangement of parts or elements that together exhibit behaviour or meaning that the individual constituents do not.” ~INCOSE • “An interconnected set of elements that is coherently organized in a way that achieves something.” ~Donella Meadows, award-winning systems thinker

12

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

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

“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

The systems engineering team “owns” the architecture

14

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.” Quotes from Team of Teams , 2015

Image credit: US Department of Transportation

16

Complementing – not Replacing –Approaches

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 A SYSTEM is a whole that cannot be divided into independent parts without losing its essential characteristics as a whole.

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

Four Primary SE Activities

B EHAVIORAL A RCHITECTURE

P HYSICAL A RCHITECTURE

V ERIFICATION & V ALIDATION

R EQUIREMENTS

19

3 Systems of Interest

20

An Example: The Vasa - A problem of disjointed System and Component Design (& Program Mgmt)

• Despite being one of the Swedish navy’s biggest achievements and among “the most spectacular warships ever built,” according to Eric H. Kessler, Paul E. Bierly III and Shanthi Gopalakrishnan in The Academy of Management Executive , Vasa sank within twenty minutes of setting sail on August 10, 1628 . • “The warship survived the first blast of wind it encountered on its maiden voyage in Stockholm Harbor,” writes Lucas Laursen for Archaeology . “ But the second gust did it in .”

21

The Vasa: What Happened? • Swedish King, Gustav II Adolf, builds Sweden into one of the most feared powers in Europe.

• Swedish king signs contract with Dutch master shipwright Henrik Hybertsson to build 4 new ships. • Master of Shipwright falls ill. Responsibility passes to his assistant, Hein Jakobsson. • King orders seventy-two 24-pound guns, which was too many to fit on a single gun deck. • Guns were placed on two decks, raising the center-of-gravity • Worrisome test: thirty men run back and forth across the deck & the ship rolled alarmingly. • Under schedule pressure from the king, the ship is ordered to sail anyways.

22

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 3 — Top ‐ Down Hypothetical Project Method 2 — Total Costs Breakdown Method 1 — Bottom ‐ Up Cost Project Phase 1 x 1 x 1 x Requirements 4 x 3 ‐ 4 x 8 x Design 7 x 13 ‐ 16 x 16 x Build 28 x 61 ‐ 78 x 21 x Test 1615 x 157 ‐ 186 x 29 x Operations 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

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

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.2 F4.1

L4.2 L4.1

R4.2 R4.1

F5

L5

R5

F6

F6.2 F6.1

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

Icons made by Freepik from www.flaticon.com

Adapted from Claas, November 2019.

28

Towards MBSE: A Practice in Transition

Future

Traditional

• Specifications • Interface requirements • System design • Analysis & Trade ‐ off • Test plans

Moving from document-centric to model-centric

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

29

What is MBSE? • 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. • MBSE is a technical approach to systems engineering that focuses on creating and exploiting domain models as the primary means of information exchange, rather than on document-based information exchange. • MBSE technical approaches are commonly applied to a wide range of industries with complex systems, such as aerospace, defense, rail, automotive, manufacturing, etc.

Language

Tool

STRATA

30

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

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

31

“Demythify” the Transition: Recognizing What MBSE Is Not

32

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

33

Understanding the Transition: Clarify “Model” in MBSE

34

Focusing on the Foundational Concepts: Model-Based Systems Engineering

Requirements a system’s why

specifies

basis of

verified by

Verification a system’s proof

Physical Architecture a system is

Behavioral Architecture a system does

verified by

verified by

performed by

35

Focusing on the Foundational Concepts: Specifying the Design Envelope

Color Code

Requirement Entity

Functional Entity

Physical Entity

Interface Entity

built from / kind of

Verification Entity

Other Entity

Component

exposes

Port

connected to

Link

includes

36

Focusing on the Foundational Concepts: Defining Functions and Exchanges

Color Code

Requirement Entity

Functional Entity

Resource

Exit

Physical Entity

Interface Entity

captures / consumes / produces

exits by

built from / kind of

Verification Entity

Other Entity

Function

Component

performs

decomposed by

exposes

inputs / outputs

Port

connected to

Item

Link

transfers

decomposed by

includes

37

Focusing on the Foundational Concepts: Considering All States

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

decomposed by

exposes

Event

inputs / outputs

Port

connected to

responsible for

Item

Link

transfers

decomposed by

includes

38

Focusing on the Foundational Concepts: Capturing the Right Problem

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

Event

inputs / outputs

Port

connected to

responsible for

Item

Link

transfers

decomposed by

includes

39

Focusing on the Foundational Concepts: Planning and Tracking Verification

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

decomposed by

includes

40

Focusing on the Foundational Concepts: Capturing the Journey

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

decomposed by

includes

generates

results in

causes

assigned to

Organization

Concern

Risk

41

Focusing on the Foundational Concepts: Engineering with Rigor

Color Code

triggered by

Transition

Requirement Entity

Functional Entity

entered by / exited by

Resource

Exit

Physical Entity

Interface Entity

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Verification Entity

Other Entity

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

constrains / uses parameter from

decomposed by

includes

generates

results in

causes

assigned to

Organization

Concern

Risk

Constraint Definition

42

Comprehensive Systems Design Language

triggered by

Transition

…more than diagrams …more than a data dictionary …more than capture …more than specification …more than the system of interest

entered by / exited by

Resource

Exit

State

captures / consumes / produces

exits by

built from / kind of

incorporates

exhibits

decomposed by

Function

Component

performs

involves / describes

Use Case

decomposed by

elaborated by

includes / extends / kind of

elicits

basis of / specifies

specifies

Requirement

exposes

refined by

verified by

verified by

Event

verified by

inputs / outputs

verified by

Port

Verification Requirement

executed by / executes

verified by

specifies

verified by

connected to

responsible for

Test Configuration

Verification Activity

employs

accomplished by

decomposed by

Verification Event

includes

Item

Link

transfers

constrains / uses parameter from

decomposed by

includes

generates

results in

causes

assigned to

Organization

Concern

Risk

Constraint Definition

43

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

44

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

45

Moving the Focus from Engineering Artifacts to Engineering Systems

46

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

47

Seeing the Impact in One Area: Dynamic Technical Data Packages with Context

• Interface definitions • Incoming and outgoing signals • Required functionality • Design constraints • Associated requirements • Test requirements • Physical and behavioral context • Rationale and design history • Analytical dependencies • Multidimensional traceability

48

Transforming Engineering: A New Manifesto

49

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

50

GENESYS Environment

51

A Black Box View of GENESYS

Capture the what and why of design

Visualize your information your way

Integrate architecture with analysis

52

The GENESYS 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 GENESYS technology empowers engineering teams to build a complete and integrated system definition

53

Leveraging the GENESYS Architecture: A Glass Box View

User Interface, Reports, Scripts, Simulation, API Applications

Model Consumer

Object ‐ oriented .NET object model Data binding support

Client API

WCF (Windows Communication Foundation) stack Provides communication flexibility Process, Machine, LAN, WAN, TCP, HTTP, etc.

Services

Applies fundamental business logic Responsible for model consistency

Database

Persists and retrieves raw data

54

Enabling Real-Time Collaboration through the GENESYS Architecture

Single Computer Genesys.exe

Collaborative

Model Consumer

GENESYS Server

Services

Client API

Database

SQL SERVER (GENESYSCOLLAB) [windows service] GENESYS 2023 Edition Services Host [windows service]

Services

Database

55

GENESYS Systems Metamodel Concepts

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

GENESYS Concept

English Equivalent

GENESYS Example

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

Class / Entity

Common Noun / Particular Noun

Relationship

Verb

Attribute

Adjective

• Description • Number

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

Relationship Attribute

Adverb

Parameter Structure

N/A N/A

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

Viewed as activity diagram or enhanced FFBD

56

Seeing a Partial Systems Engineering Example

DOCUMENT

documents (documented by)

documents (documented by)

• Number • Description • Type

REQUIREMENT • Number • Description • Type • Origin

COMPONENT • Number • Description • Type

specifies (specified by)

FUNCTION

specified by (specifies)

performs (allocated to)

•Number •Description •Duration •Exit Logic

57

GENESYS Walkthrough A quick introduction to the interface

58

Exploring GENESYS

• Launching GENESYS and logging in • Importing a project • Navigating the project explorer • Project properties • Facilities, folders, and entities • Entity property sheet • Diagrams and the diagram toolbox • Exiting GENESYS

59

Launching GENESYS 1. Open the Windows Start menu 2. Select GENESYS #### folder 3. Select GENESYS ####

60

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

61

Reviewing the GENESYS Home Screen

62

Accessing Commands via the Application Menu 1. Click “File” to access the main application menu Commands on the application menu are global

Import and Export load and save project information files to and from the GENESYS repository Information added to a project is saved in real ‐ time to the repository without need for an explicit save or export command

63

Importing a Project File into GENESYS 1. Select the application menu 2. Select Import

3. Navigate to the specified folder 4. Select “Fast Food Sample.gnsx” 5. Click Open

C:\Program Files\Vitech\GENESYS ####\Samples\Project Samples

64

Stepping through the Import Wizard

65

Import Wizard Results

• Click CLOSE

66

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

GENESYS can have multiple projects open simultaneously. Each open project has at least one project explorer open. Closing the last project explorer will prompt to close the project

67

Ribbon Controls and Commands

Application Menu

Navigation Commands

Undo/Redo

Ribbon Tabs

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

68

Specifying Project Properties 1. In the project explorer panel, select “SAMPLE: Fast Food”

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

69

Project Statistics The project statics sheet provides details about the amount of information contained in the project • Number of Entities • Number of Relationships • Number of Related Projects • Number of Cross ‐ Project Entities • Number of Cross ‐ Project Relationships • Number of Cross ‐ Project Entity References • Attributes • Relationships Attributes

70

Navigating within a Project The project explorer panel enables navigation of the project by packages or by classes

Packages allow you to group any blend of entities together for model management and navigation purposes Classes group all entities of a given type together into folders and subfolders 1. Click “Essentials” in the facility drop ‐ down 2. Select “All Classes” The facility drop ‐ down allows you to view a subset of the classes in the project 3. Click “All Classes” in the facility drop ‐ down and select “Essentials”

71

Understanding “Schema” and “Facilities”

• Schema • Collection of all entity classes, attribute definitions, relationship definitions, and parameter definitions that are available to the systems team • Instantiation of the systems metamodel in a database • Facility • Collection of related entity 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 • Verification – classes used for verification definition and tracking

72

Accessing Entities 1. Select Component in the project explorer panel Browser panel shows entities in the selected class / folder An entity is an object that is an instance of a given class definition in the model New entities can be created multiple ways • the New Entity command in the ribbon • the “Create” control at the top of the entity list • double ‐ clicking the class name

73

Accessing Information about an Entity 1. Select “Fast Food System” in the browser panel

Selecting an entity populates the property sheet with all information about the entity

• Attributes • Properties • Parameters • Diagnostics • Views • Relationships

74

Opening a Property Sheet 1. Double ‐ click “Fast Food System” in the browser panel to open the property sheet as a separate window Double ‐ clicking an entity anywhere in GENESYS is a shortcut to open the property sheet The property sheet allows us to • characterize the entity (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

75

Changing an Attribute and Accessing Versions 1. In the project explorer, make a change to the Description attribute 2. Click in the Abbreviation attribute When you change fields or close a window, GENESYS saves the changed value 3. Click the versioning icon at the right of the Description panel 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

76

Exploring Entity Properties 1. Click the “Properties” tab

Properties are tool ‐ dependent fields that GENESYS uses to manage and represent entities

77

Specifying Parameters Parameters are design ‐ dependent variables to manage the numerical values of the design and can be referenced in text attributes 1. Click the “Parameters” tab 2. Click Add/Remove to edit the parameters for the entity New defines a new parameter for this class Copy allows you to copy an existing parameter definition from another class Add allows you to add a predefined parameter for the given class Remove allows you remove a previously assigned parameter

78

Specifying Parameters Parameters allow you to specify • Objective (design targets) • Maximum, Minimum (bounds) • Design (current design value) • Observed (current as ‐ built value) • Precision (as ‐ built tolerancing) The same parameter can be bound to multiple entities using parameter bindings.

79

Leveraging Parameters: Descriptive Text, Computable Numerics Parameters can be inserted into any text field 1. Click the “Attributes” tab 2. Click in the Description panel 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

80

Reviewing Entity 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) Design integrity 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 design integrity checkers are specified as part of the project properties. These can be customized based upon a team’s methodology or schema extensions.

81

Visualizing Completeness and Integrity Checks

Completeness

Design Integrity

82

Seeing Stored Views: Auto-generated Diagrams with Style 1. Click the “Views” tab

Views are the style information for a specific diagram (diagram settings, node size and position, coloring, node template, etc.). GENEYSYS supports multiple views per diagram type allowing you to represent the same diagram multiple ways to address communication and analysis needs. GENESYS automatically stores this information when a diagram is closed. GENESYS applies this information when the diagram is re ‐ opened and automatically updated to reflect the current state of the project. Views can be renamed, opened, and deleted from the views tab

83

Opening Diagram Views Diagrams can be accessed using the diagram tabs at the bottom of the project explorer or the Views ribbon • clicking the tab accesses the view within the project explorer • selecting a diagram via the Views ribbon 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 browser panel 2. Select the Views menu 3. Click BDD to open the block definition diagram

84

Navigating the Diagram Controls

View port (adjust grey region to reposition and scale)

Scale and navigation controls

Insert lists • Constructs • Shapes • Key Entities • All Entities

85

Setting Diagram and Diagram Object Properties 1. Select “Properties” in the toolbox

The properties tab controls the style settings for the diagram and diagram objects (nodes, lines, and shapes)

When nothing is selected, the properties tab controls diagram ‐ level settings • diagram options • default content, coloring, and sizing When one or more diagram objects are selected, the properties control the presentation of those objects (coloring, sizing, use of images)

86

Reviewing the Ribbon Bar for Diagrams

View tab opens new views on the selected entity

Diagram tab manipulates the formatting and content as well as exports graphic files

87

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

Remember that changes made to projects are committed to the repository in real ‐ time so there is no need to save when exiting

88

Setting Up Your Project

89

Getting Started with GENESYS: Configuring Users and Projects

• Creating a new user account

• Creating a new project

• Setting project permissions

• Setting user preferences

90

Accessing the Administrative Tools 1. In the project explorer, select the Utilities ribbon 2. Select Admin Tools (also available from the Home screen) Administrative Tools allow us to manage • Projects • Users • Groups

• Current sessions • Security options • REST API settings • OSLC settings

91

Creating a New User Account 1. In the administrative tools, select the Users tab 2. Select New User 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 two characters long. Passwords must be at least five characters long (password rules may be changed via the Security tab).

92

Editing User Account Properties 1. Select Edit User

The user properties allow you to specify • full name (for descriptive purposes) • email (for change notifications) • description • account disablement (for temporary lockout) • group membership 2. Click OK

93

Specifying Groups Groups tab 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

94

Creating a New Project 1. In the project explorer, select “Home” in the left panel 2. Select “New Project” 3. Set project name (“Geospatial Library Class Project”) 4. Select schema type (“Base Schema ####”) 5. Click OK Base schema and unique entity names must be set during project creation Versioning and audit logging can be changed at any time via the project property sheet

95

Setting Our Project Properties Project properties are settings and descriptive values for a given project 1. (Optional) Enter Organization Name and Organization Address 2. (Optional) Enter Customer Name and Customer Address 3. Set Base Path and External Graphics Path

4. Select Design Integrity Checker These properties will be used when generating documents and for managing external files

Base Path ‐ > C:\Program Files\Vitech\GENESYS #### Graphics ‐ > C:\Program Files\Vitech\GENESYS ####\Bitmaps

96

Editing Project Permissions Project permissions are managed from the Project ribbon or the Projects tab of the Administrative Tools

1. Click Set Permissions 2. Select User or Group 3. Select and set permissions

User/group permissions are set by checking the appropriate boxes for • Read

• Update • Create • Delete • Full Control

97

Editing Permissions at the Folder or Entity Level

If you wish to set permissions for a class, folder, or entity 1. Select the folder or entities of interest 2. Right ‐ click to access the context menu 3. Select the Set Permissions command 4. Set Read, Update, Delete, and/or Full Control to set the permissions for each user/group

98

Editing Permissions at the Attribute Level

If you wish to set permissions for an attribute of an entity 1. Select the folder or entities of interest 2. Right ‐ click to access the context menu 3. Select the Set Attribute Permissions command 4. Select the desired attribute 5. Set Read, Update, Delete, and/or Full Control to set the permissions for each user/group

99

Editing Project and User Preferences

User Preferences – customize the way of working for the user Project Preferences –provide consistency across the project

100

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

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 4. Derive System Threads 3. Capture Originating Architecture Constraints

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

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 3. Capture Component Hierarchy

4a. Allocate Behavior to Components

3a. Refine 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

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