Systems Modeling Language (SysML)

INCOSE Evaluation: Systems Modeling Language (SysML)

SysML Submission Team (SST)

13, 15, 20 December 2005

SST Chair: Sanford [email protected]

2

Topics Introduction MDSD Actions Specification Updates Specification Highlights

Language Architecture Compliance Approach Structural Constructs Behavioral Constructs Cross-cutting Constructs Appendixes

Sample Problems HSUV Example from Appendix B Distiller Example (response to D. Oliver example)

Summary

3

Introductory Statement Two competing specifications* submitted to the

OMG on November 14, 2005 from: SysML Submission Team (SST) chaired by S.

Friedenthal SysML Partners chaired by C. Kobryn

This highlights updates and selected features of the SST SysML Specification v0.98 (ad/2005-11-01)

A vote for adoption should occur at the next OMG meeting the week of February 13, 2006

* Available at http://syseng.omg.org/SysML.htm

4

What is SysML? A graphical modeling language in response to the UML

for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 a UML Profile that represents a subset of UML 2 with

extensions

Supports the specification, analysis, design, verification and validation of systems that include hardware, software, data, personnel, procedures, and facilities

Supports model and data interchange via XMI and the evolving AP233 standard (in-process)

SysML is Critical Enabler for Model Driven SE SysML is Critical Enabler for Model Driven SE

5

SysML Background UML for SE RFP issued – 28 March 2003

SysML Partners Kickoff meeting – 6 May 2003 Chaired by S. Friedenthal and C. Kobryn

3rd revised submission (v0.9) to OMG – 10 Jan 2005 Addendum stereotypes chapter – 30 May 2005

SysML Submission Team announced split from SysML Partners on August 30, 2005 to finalize the specification

Differences in process, issue prioritization and resolutions

Both teams started from a common baseline V0.9 plus Addendum Profiles chapter Blocks/Parametrics approach Satisfied most of the requirements of the UML for SE RFP

Submitted revised submissions on November 14, 2005 with planned vote for adoption at next OMG meeting in Feb ‘06

6

SysML Submission Team (SST)

Members Industry & Government

American Systems, BAE SYSTEMS, Boeing, EADS-Astrium, Eurostep, Lockheed Martin, NIST, oose.de, Raytheon, THALES

Vendors Artisan, EmbeddedPlus, IBM, I-Logix, Mentor Graphics, Sparx Systems, Vitech Corp

Neutral Collaborators Deere & Company Georgia Institute of Technology NASA/JPL INCOSE, AP233

SST broad based team of multiple SST broad based team of multiple end-users and tool vendorsend-users and tool vendors

7

SST Philosophy Deliver solution to the users without delay

SysML 0.90 widely regarded as an “80% solution” Systems engineering users demanding this

language Incorporate user and vendor feedback in future

revisions Provide sufficient features to make the

language useful for systems engineers Reuse UML at the package level to maintain

language integrity Limit fine grain selection of UML elements at this

time

8

UML for SE RFPRequirements Summary

Structure e.g., system hierarchy, interconnection

Behavior e.g., function-based behavior, state-based behavior

Properties e.g., parametric models, time property

Requirements e.g., requirements hierarchy, traceability

Verification e.g., test cases, verification results

Other e.g., roles, views, relationship types, diagram types

Optional e.g., trade studies, other behavior modeling

paradigmsSST submission provides robust solution SST submission provides robust solution

that addresses most of the RFP requirementsthat addresses most of the RFP requirements

Refer to SST Req’ts Traceability Matrixin Appendix E.

9

SST Design Principles (Section 4.1) Requirements driven

SysML is intended to satisfy the requirements of the UML for SE RFP. UML reuse

SysML reuses UML wherever practical to satisfy the requirements of the RFP, and when modifications are required, they are done in a manner that strives to minimize changes to the underlying language. Consequently, SysML is intended to be relatively easy to implement for vendors who support UML 2 or later revisions.

UML extensions SysML extends UML as needed to satisfy the requirements of the RFP.

The primary extension mechanism is the UML 2 profile mechanism as further refined in the SysML Profiles & Model Libraries chapter of this specification.

Partitioning The package is the basic unit of partitioning in this specification. The

packages partition the model elements into logical groupings which minimize circular dependencies among them.

Layering SysML packages are specified as an extension layer to the UML

metamodel. Interoperability

SysML inherits the XMI interchange capability from UML. SysML is also intended to be supported by the ISO AP233 data interchange standard to support interoperability among other engineering tools.

10

Highlights of SST Approach (1 of 3) Coherent and consistent language

architecture essential for integration with UML, model interchange, and standardized implementations Utilizes UML solution for specifying profiles

(e.g. subsetting UML via reference metamodel)

Reuse UML at the package level (vs. metaclass) to avoid breakage and maintain language integrity

Compliance approach that allows vendor to clearly state compliance and users to assess compliance Consistent with UML Unambiguous compliance points

11

Highlights of SST Approach (2 of 3) Usefulness of the language to practicing

SE’s Maintain basic capability for modeling

physical systems deep nesting, design values with distributions, units

tied in with dimensions, instance diagram for unique configurations, item flows, moe’s/objective function integrated with parametrics, timing diagram, explicit allocation for swim lanes (activity partitions), requirements refinement via models, …

Ensure understandability Distinct flow port notations, requirements callout

notation, elaborated diagram element tables, diagram conventions, …

12

Highlights of SST Approach (3 of 3)

Multi-vendor solution (Artisan, EmbeddedPlus/IBM, I-Logix, Sparx Systems) that is being implemented

Leverages broad based specification author team to maintain quality and completeness across chapters This includes chapters that were reused by the

other submission team such-as activities, allocations, and profiles & model libraries

13

Evaluating the Specifications Specifications and RFP available at:

http://syseng.omg.org/SysML.htm Specification review guidance

Use the SST Highlights & Comparison Matrix and the following slides to help understand the differences between the submissions

Available on INCOSE Evaluators Site or request from SST Chair Review the following chapters in the SST Introduction

Language architecture and Compliance Review the following subsections in each SST chapter

Overviews Diagram elements (look for completeness) UML extensions (targeted to tool vendors / language

implementers) Usage examples (consistent with Appendix B sample problem)

Review the SST Sample Problem in Appendix B Provides overview of how language can be used

Review the following appendixes as time permits Diagrams Non-Normative Extensions Model Interchange

14

UML for SE RFP Evaluation Criteria 6.8.1 Ease of use 6.8.2 Unambiguous 6.8.3 Precise 6.8.4 Complete 6.8.5 Scalable 6.8.6 Adaptable to different domains 6.8.7 Capable of complete model

interchange 6.8.8 Evolvable 6.8.9 Process and method independent 6.8.10 Compliant with UML metamodel 6.8.11 Verifiable

15

Language Feature Summary(Refer to SST Highlights & Comparison Matrix 051201-revb)

Language ArchitectureComplianceViews & ViewpointsValue Types, Units &

DimensionsProperty Specific TypesInstance DiagramDeep Nesting Item FlowsFlow Port FeaturesFlow Port Compatibility RulesParametric DiagramTiming DiagramAllocation TypesAllocate Activity PartitionRequirement Callout NotationRefine Requirements

RelationshipContainment SymbolDiagram ConventionsMOE’s & Objective FunctionRequirements ClassificationBNF NotationChapter Updates

HHMHMMHHMMHMMMHHLMHLMM

6.8.2, 6.8.8, 6.8.116.8.116.8.56.8.2, 6.8.36.8.16.8.4, 6.8.5 (RFP reqt 6.8.4)6.8.1, 6.8.106.8.1, 6.8.4, 6.8.10 6.8.1, 6.8.26.8.1, 6.8.36.8.16.8.4, 6.8.12 (RFP reqt

6.5.2.4.1)6.8.1, 6.8.26.8.16.8.1, 6.8.56.8.46.8.116.8.1, 6.8.26.8.3, 6.8.46.8.26.8.2, 6.8.96.8.2

Language Feature Impact/PriorityRFP Evaluation Criteria

Selected Language Features To Contrast SubmissionsSelected Language Features To Contrast Submissions

1234566a789101112131415161718192021

No.

16

SysML SST Specification Outline Preface

Part I of RFP Response Part II of RFP Response Part III of RFP Response

Part I – Introduction Scope Normative references Additional information Language Architecture Compliance Language Formalism

Part II – Structural Constructs Model Elements Blocks Ports and Flows Parametrics

Part III – Behavioral Constructs Activities Interactions State Machines Use Cases

Part IV – Crosscutting Constructs Allocations Requirements Profiles & Model Libraries

Part V Appendices Diagrams Sample Problem Non-Normative Extensions Model Interchange (AP233 &

XMI) Requirements Traceability Terms and Definitions BNF Diagram Syntax Definitions

MDSD Recommendations & ResponseFrom INCOSE IW Jan 29-30, 2005

18

MDSD Recommendations & ResponseINCOSE IW – Jan ‘05 Improve SysML tutorial

emphasize 5 Core diagrams and be driven by Requirements diagrams

replace UML-specific definitions with domain-specific explanations present update at INCOSE Symposium (MDSD plenary)

RESPONSE: Will continue to elaborate and refine current tutorial material and make available when adoption begins in February.

Increase readability of SysML specification for engineers and tool vendors

replace UML-specific definitions with domain-specific explanationsRESPONSE: Current specification includes a superset of terms in

Appendix F that includes definitions from the UML for SE RFP, UML 2, and the SysML extensions. This superset needs to distilled and refined to include the relevant terms needed for the tool vendors and end users.

include a domain metamodelRESPONSE: Use the SE Concept Model to express basic domain

concepts. Will work with INCOSE MDSD to capture additional key SysML concepts such as usage/roles, etc.

19

MDSD Recommendations & Response (cont.) Include a model library for Requirement taxonomy

RESPONSE: Updated requirements taxonomy (refer to Appendix C.2)

include MeasureOfEffectiveness (MOE; properties: weight, optimizationDirection)

RESPONSE: Defined an MOE stereotype which integrates with parametrics to support engineering analysis (refer to Appendix C.3)

MOE may also include a complementary Parametric construct to effect MOE constraints

RESPONSE: Defined a general purpose objective function stereotype which integrates with parameterics to support engineering analysis and optimization (refer to Appendix C.3)

20

MDSD Recommendations & Response (cont.) Include a model library for Assemblies that includes

PhysicalAssembly (properties: supplier, modelNumber, serialNumber, lotNumber)

RESPONSE: Example included in Fig 17-10 in Profiles & Model Libraries chapter.

Harmonize concepts, constructs, and usage examples for Allocations

make implicit Allocations explicit RESPONSE: Made swim lanes explicit form of allocation (Fig 15-

2, Section 15.3.3.3) test usability of multiple UI options via vendor prototypes

RESPONSE: Multiple UI options explored and incorporated including allocation/requirement compartments, callout, and tabular formats (refer to diagram extensions in 15.3.1 and 16.3.1)

Encourage and promote vendor SysML prototypes at INCOSE Symposium vendor exhibits

RESPONSE: Multi-vendor prototype demonstrations at INCOSE Symposium in July ‘05 at MDSD and on exhibitor floor

Specification Updates

22

Progress On Issues Resolved open issues from v0.9

Resolved previously identified critical issues

Resolved 237 issues from original issue list

4 deferred/5 to incorporate into v1.0

Incorporated issue resolutions into v0.98

23

Specification Updates Updated Specification Outline Refined chapters

Simplified chapter organization Improved overviews, descriptions, diagram

extensions, and usage examples Elaborated diagram element tables to

include more complete concrete syntax Aligned usage examples with sample

problem appendix Updated for consistency with language

architecture and compliance approach

Enhanced Completeness, Consistency and Enhanced Completeness, Consistency and Understandability of SST Specification v0.98Understandability of SST Specification v0.98

Refer to Slide 15: No. 21

24

SysML Specification Outline - Authors Preface Part I – Introduction – Alan Moore/Sandy Friedenthal Part II – Structural Constructs

Model Elements - Tim Weilkiens with inputs from Roger Burkhart Blocks - Alan Moore with inputs from Roger Burkhart Ports and Flows - Eran Gery Parametrics – Alan Moore with inputs from Roger Burkhart

Part III – Behavioral Constructs Activities – Conrad Bock Interactions – Cory Bialowas/Bran Selic State Machines - Cory Bialowas/Bran Selic Use Cases – JD Baker

Part IV – Crosscutting Constructs Allocations – Rick Steiner Requirements – Laurent Balmelli Profiles & Model Libraries – Alan Moore

Part V Appendices Diagrams – Sandy Friedenthal Sample Problem – Rick Steiner Non-Normative Extensions – Conrad Bock/Sandy Friedenthal Model Interchange (AP233 and XMI) – Bran Selic, Dwayne Hardy/David Price Requirements Traceability – Sandy Friedenthal Terms and Definitions – Sandy Friedenthal BNF Diagram Syntax Definitions – Roger Burkhart

25

Specification UpdatesTechnical Content Change Summary Redefined Language Architecture and Compliance approach Structure

Unified class and assembly into blocks* Specified property subclasses for part, reference, and value Provided mechanism for part specific subclasses to support design values Replaced quantity with value type, units, dimensions, and distributions Redefined ports to include UML (i.e. client-server) ports and flow ports * Refined item flow semantics and notation Refined parametric notation and semantics (constraint blocks and properties) Updated View/Viewpoint to be consistent with IEEE 1471 Updated diagram taxonomy to include package & instance diagram

Behavior Refined/updated activity extensions* Included protocol state machines

Cross cutting Refined requirements semantics Refined allocation semantics Harmonized callout notation between requirements and allocations Updated profiles per RTF *

Appendixes Updated diagram frames & headings conventions Significantly elaborated sample problem appendix and integrated with usage examples

in chapters Refined non-normative extensions for EFFBD profile*, requirements subclasses, and

measures of effectiveness (MOE’s)* Refined approach for XMI and AP233 harmonization Updated requirements traceability matrix in Appendix E Identified terms for glossary Added BNF Diagram Syntax Definition appendix

* Work started prior to split on Aug 30, 2005

Refer to Slide 15: No. 21

SST Specification Highlights

27

Specification Highlights

Language Architecture Compliance Approach Structural Constructs Behavioral Constructs Cross Cutting

Constructs Appendixes

123-10, 181112-16, 1917-20

Language Feature #(From Slide 15)Specification Topic

Refer to the Topic in the Following Slides for DetailsRefer to the Topic in the Following Slides for Detailson the Referenced Language Features from Slide 15on the Referenced Language Features from Slide 15

Language Architecture

29

Relationship Between SysML and UML

UML 2

UML 2Reuse(1, 2)

UMLreused by

SysML

UMLnot required

by SysML(UML -

UML4SysML)

SysMLextensions to

UML

SysMLUML4SysML

SysML Profile

30

SysML Diagram TaxonomySysML Diagram

StructureDiagram

BehaviorDiagram

Use CaseDiagram

ActivityDiagram

Internal BlockDiagram

Block DefinitionDiagram

SequenceDiagram

State MachineDiagram

TimingDiagram

ParametricDiagram

RequirementDiagram

Modified from UML 2

New diagram type

Instance Diagram

Package Diagram

Same as UML 2

31

SysML v0.9 Language Architecture Issues

Reuse of UML was imprecisely defined Only partial list of required meta-classes UML2 Profiles chapter not clear on specification and

application of UML subset Profile structure was confusing

Contained sub-packages with no extensions Package partitioning was inconsistent with chapters

Not tied in with compliance Impacts

XMI and Interoperability Ability to integrate UML applications with

SysML Ambiguity affects vendor ability to implement

32

Language Architecture Approach Worked with UML2 RTF on profiles approach

and used to define language architecture Create UML2 Subset using merge Reference this subset from the SysML profile Define fine-grained restrictions on features in

constraints Apply reuse at package level vs metaclass

level Merge only works at package level Easier to ensure that subset is well-formed with no

dangling references Profile structure redefined

Consistent with SysML chapter structure Only introduce sub-profile if chapter contains

extensions

33

Reuse of UML 2 – UML4SysML

«profile»SysML

«reference»

«metamodel»UML4SysML

Fragments«merge»

CompleteActivities

ExtraStructuredActivities

CompleteStructuredActivities

InformationFlowsCompleteActions Time

Profiles

ProtocolStateMachines

StructuredClasses

«merge»

«merge»

«merge»«merge»«merge»«merge»

«merge»

«merge»

«merge»

«modelLibrary»StandardProfileL1

«import»PowerTypes

«merge»

SysML Profile Retains UML IntegritySysML Profile Retains UML Integrity

34

SysML Profile Package

«profile»SysML

«profile»ConstraintBlocks

«profile»Blocks

«profile»Activities

«modelLibrary»Blocks

«modelLibrary»ControlValues

«profile»Ports&Flows

«profile»Requirements

«profile»Allocations

«profile»ModelElements

«import»«import»

Modular & Cohesive Package StructureModular & Cohesive Package Structure

35

Applying SysML Profile to a User Model

pkg ModelingDomain [Establishing HSUV Model]

«modelLibrary»SI Unit Types

«import»

«profile»SysML

HSUVModel

«apply»{strict}

«apply» {strict}

SysML Compliance

37

V0.9 Compliance Issues

Criteria for basic/advanced choice unclear Basic/Advanced approach too coarse for likely

vendor and user community Difficult for non-UML tools to state compliance Didn’t fit with UML tool-vendors plans for UML

implementation Levels didn’t reflect break down of SysML language

domains Compliance based on Concrete Syntax

Impact Difficult to get closure on Basic/Advanced subsets Users unable to get simple compliance

statements from SysML tool vendors Hard to partition abstract syntax for compliance

38

Compliance Approach Compliance Levels

Introduce compliance levels into UML4SysML Strict subsets of UML compliance levels (L1, L2, L3)

Further compliance levels for SysML Profile Each sub-profile is separate compliance level Asserts minimal compliance on UML4SysML level

Reuse UML definitions of compliance Abstract syntax Concrete syntax

Compliance Statements No Partial (requires feature support statement) YesCompliance approach allows vendor to clearly state Compliance approach allows vendor to clearly state

compliance and users to assess compliancecompliance and users to assess compliance

39

Compliance Summary ExampleCompliance level Abstract Syntax Concrete Syntax

UML4SysML Level 1 YES YES

UML4SysML Level 2 PARTIAL YES

UML4SysML Level 3 NO NO

Activities (without Probability) YES YES

Activities (with Probability) NO NO

Allocations PARTIAL PARTIAL

Blocks YES YES

Constraint Blocks YES YES

Model Elements (without Views) YES YES

Model Elements (with Views) NO NO

Ports & Flows (w/o Item Flows) YES YES

Ports & Flows (with Item Flow) NO NO

Requirements YES YES

40

Feature Support Statement

Feature Support Statement

Compliance Level Detail Abstract Syntax

Concrete Syntax

Semantics

UML4SysML::Level 2 StateMachines::BehaviorStateMachines Note (1) YES Note(2)

SysML::Blocks Block YES Note (3) YES

Note (1): States and state machines are limited to a single region. Shallow history pseudostates not supported Note (2): FIFO queueing in event poolNote (3): Don’t show Blocks::StructuredCompartment notation

Structural Constructs

42

Structural Constructs Model Elements Blocks Ports and Flows Parametrics

Model Elements

44

Model Elements Includes fundamental modeling

constructs such as model elements, packages, and dependencies

Used to organize model Package diagram used to group model

elements into a name space SysML extension for view and viewpoint

Rational stereotype can be applied to any model element to capture decision

45

Organizing the User Modelpkg HSUVModel

HSUVViews

HSUVRequirementsHSUVStructureHSUVBehavior

DeliverPowerBehavior

HSUVAnalysis

«view»Performance

View

«viewpoint»Performance

Viewpoint

«access»«block»Automotive

Domain

«view»OperationalView

«viewpoint»OperationalViewpoint

«access»

«access»

HSUVUseCases

HSUVInterfaces«requirement»Performance

«access»

Package Diagram Used to Organize the ModelPackage Diagram Used to Organize the Model

46

Views and Viewpoints Consistent with IEEE 1471 Viewpoint represents stakeholders,

their concerns/purpose/intent, and construction rules for specifying a view

View is a read only mechanism that captures the model subset that addresses the stakeholder concerns Realizes the viewpoint Relationships between model elements

established in model and not between views

47

IEEE 1471 IEEE 1471 (section 5.3) prescribes that a

viewpoint contains: a) A viewpoint name b) The stakeholders to be addressed by the

viewpoint c) The concerns to be addressed by the

viewpoint d) The language, modeling techniques, or

analytical methods to be used in constructing a view based upon the viewpoint

e) The source, for a library viewpoint (the source could include author, date, or reference to other documents, as determined by the using organization)

48

SST View/Viewpoint

Viewpoint as a stereotyped class

«viewpoint»stakeholders="..."purpose="..."construction rules="..."

Functional Viewpoint

«view»Security View

«viewpoint»Security Viewpoint

View realizes a viewpoint

Relationship between Viewpoints

49

Performance View Examplepkg [package] HSUVViews [Performance View]

«view»PerformanceView

Driver

Drive Car «viewpoint»stakeholders="customer"purpose="Highlight the performance of thesystem."construction rules="show performancerequirements, test cases, MOE, constraintmodels, etc.; includes functional viewpoint"

Performance Viewpoint

«viewpoint»Functional Viewpoint

id = 2Text = The Hybrid SUVshall have the braking,acceleration, and off-roadcapability of a typical SUV,but have dramatically betterfuel economy.

<<requirement>>Performance

«moe»HSUValt1.CostEffectiveness

«moe»HSUValt1.Fuel

Economy

«moe»HSUValt1.Zero

60Time

«moe»HSUValt1.CargoCapacity

«moe»HSUValt1.Quar

terMileTime

«constraint»EconomyEquation

«constraint»UnitCostEquation

«constraint»CapacityEquation

«testCase»EPAFuel

EconomyTest

50

Rationale

«requirement»PowerSourceManagement

«requirement»Power

«deriveReqt»

«rationale»Power delivery must happen by coordinatedcontrol of gas and electric motors.reference= “Hybrid Design Guidance”

Rationale can be attached to any Model Element or Rationale can be attached to any Model Element or Relationship to Capture decisionsRelationship to Capture decisions

Rationale can link to atrade study or analysis report

Blocks

52

Blocks Highlights Unification of classes and

assemblies Property subclasses Deep nesting Design values Specification of value types with

units, dimensions, and probabilities Instance diagrams

Resolution of Blocks Issues Resulted in Solid Resolution of Blocks Issues Resulted in Solid Structural Foundation for SST SubmissionStructural Foundation for SST Submission

53

Blocks Unify Class & Assembly from v0.9 Blocks provides a unifying concept to

describe the structure of an element Based on UML class from UML Composite Structures

Block definition diagram describes the relationship among blocks (e.g. composition, association, classification, ..)

Internal block diagram describes the internal structure of a block in terms of its properties and connectors

Behavior can be allocated to blocks

54

Power Subsystem Breakdownbdd [block] HSUV [PowerSubsystem Breakdown]

«block»PowerSubsystem

«block»ElectricMotor

Generator

«block»FrontWheel

«block»accelerator

«block»FuelTankAssembly

«block»Differential

«block»Transmission

«block»InternalCombustionEngine

«block»FuelInjector

lfw

4

«block»BatteryPack

«block»ElectricalPowerController

«block»PowerControlUnit

«block»FuelPump

«block»BrakePedal

«block»WheelHubAssembly

rfw

Block Definition Diagram Used to Specify System Block Definition Diagram Used to Specify System Hierarchy and ClassificationHierarchy and Classification

55

Power Subsystem IBDibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator]

emg:ElectricMotorGenerator

trsm:Transmission

ice:InternalCombustionEngine

acl:accelerator

ecu:PowerControlUnit

ft:FuelTankAssy

dif:Differential

rfw:ChassisSubsytem.FrontWheel

lfw:ChassisSubsytem.FrontWheel

Port:FuelTankFitting

Port:ICEFuelFitting

fuelDelivery

torqueOut:Torque

torquein:Torque

spline

fuelSupply:Fuel

epc:ElectricalPowerController

bp:BatteryPack

i1:ElectricCurrent

i2:ElectricCurrent

fp:FuelPump

fi:FuelInjector

fdistbp:BrakeSubsystem.BrakePedal

<>

<>

<><>

4

fuelReturn:Fuel

<>

<>

<>

<>

g1:Torque

t2:T

orqu

e

t1:Torque

ice

ctrl

I_ICECmds

I_ICECmds

ctrl

ctrl

I_ICEData I_ICEData

trsmepc

c3

c2

c1

I_IEPCCmdI_IEPCData

I_IEPCDataI_EPCCmd

I_TRSMData

I_TRSMCmd

I_TRSMCmd

I_TRSMData

<><>

<>

rightHalfShaft

<><>

<>

leftHalfShaft

Internal Block Diagram Used to Specify Interconnection Internal Block Diagram Used to Specify Interconnection Among Parts in Context of Enclosing BlockAmong Parts in Context of Enclosing Block

Part

Connector

EnclosingBlock

56

Property Subclasses Property is a structural feature of a block

which is further sub-classed in SysML Part property aka. part (typed by a block)

Usage of a block in the context of the enclosing block Example - right-front:wheel

Value property (typed by value type) Defines a value with units, dimensions, and

probability distribution Example - tirePressure:psi {distribution=Uniform

(min=27,max=29)} Reference property (typed by a block)

A part that is not owned by the enclosing block Example - logical interface between 2 parts

57

ibd block Automotive Domain

env : Environment

road : Road

vehicle : HSUV

2

front : Tire

2

rear : Tire

Deep Nesting Provides Intuitive Modeling of Deep Nesting Provides Intuitive Modeling of Physical SystemsPhysical Systems and does not Impose Process and does not Impose Process

Simple Example of Deep NestingConnecting a Tire to a Road

No need for modeler to

specify intermediateconnections

58

Design Values Example

«part» 2

back : [Wheel]

PropertiestyrePressure : psi {distribution=Uniform (min=27,max=29)}

«part» 2

front : [Wheel]

PropertiestyrePressure : psi {distribution=Uniform (min=25,max=27)}

ibd SUV

Car

SUV

Wheel

tyrePressure : psi21

back

21

front

bdd Car Design

[] Indicates part-specific block

Supports different values & distributions

for each part

Design Values Ease Ability to Specify Different Design Values Ease Ability to Specify Different Values/Distributions on Parts in Same ContextValues/Distributions on Parts in Same Context

59

Units and Dimensions«metaclass»

DataType

«stereotype»ValueType

InstanceSpecification

InstanceSpecification0..1

0..1

*

dimension

unit

{ instance of Dimension from Units model library}

{ instance of Unit from Units model library}

value

*

«modelLibrary»Blocks

«block»Unit

«block»Dimension

«value»Real

dimension

0..* 0..1

realPart: RealimaginaryPart: Real

«value»Complex

bdd [package] SI Unit Types

«value»unit=seconddimension=time

s

ins [package] SI Units

«block»second:Unit

«block»time:Dimension

bdd [package] Objects

valuest1:st2:s

Obj

«value»Real

Units Tied Explicitly to DimensionsUnits Tied Explicitly to Dimensions

60

Units Model Library

z

pkg SEToolkit


«import» «modelLibrary»Units

«valueType»dimension = VolumeDim

Volume

«valueType»unit = KgPerM3

SIDensity

«valueType»unit= M3

SIVolume

«valueType»dimension = DensityDim

Density«modelLibrary»Physical«valueType»

dimension = LengthDim

Length

«valueType»unit = M

SILength

«import»density: SIDensityvolume: SIVolumesupplier: StringmodelNumber: StringserialNumber: StringlotNumber: String

«block»PhysicalObject

«modelLibrary»SI Units

«import»

Model Library Can be Expanded Model Library Can be Expanded to Address Domain Needsto Address Domain Needs

61

SST Instance Diagram Instances are a fundamental aspect of

UML classes which is the foundation for blocks

Instances provide a means for uniquely identifying a member of a “class” (block) System configuration with unique serial

number/id Specific examples with unique values Specific items under test with test results

(e.g. failed item for causal analysis) ….

62

Test Result Instanceins SUV_EPA_Fuel_Economy_Test_Result

Satisfies«requirment»Emissions

VIN = G12345

TestVehicle1/hsuv:HSUV

p67890/p:PowerSubsystem

c34567/c:ChassisSubsytem

bk45678/bk:Brake

Subsystem

i23456/int:InteriorSubsystem

lt56789/lt:Lighting

bSubsystem

b12345/b:BodySubsystem

eid78901/ice:InternalComb

ustionEnginesn89012/

t:transmissionsn90123/

emg:ElectricalMotorGenerator

«testCase»testRun060401/

epaTest:EPAFuelEconomyTest

Verifies«requirment»Emissions

Example Use of Instance Diagram for Specifying Example Use of Instance Diagram for Specifying a Unique System Test Configuration and Valuesa Unique System Test Configuration and Values

Ports and Flows Issues

64

Ports V0.9 Issue

Did not have ability to specify what can flow in or out of a block (I/O)

Did not include UML port capability Impact

Could not specify what flows in or out of a block independent of its usage

e.g. fluid can flow in or out of a tank Did not meet needs of service oriented

designs and integration with software

65

Ports Approach Ports represent block interaction points via which Blocks

provide or consume data/material/energy or services Support specification of interfaces on a block

independent of a specific usage (e.g. this component requires 110 volts of power input)

Approach is to specialize two port types Flow ports

Port type specifies what can flow in our out of block/part A connection point through which there is a flow of

information, material, or energy (I/O) Typically asynchronous flow where producer is not aware

when/who consumes the flow Client server ports

Service oriented (request-reply) peer2peer interaction Typically synchronous communication Specified similar to UML2.0 ports using required/provided

interfaces detailing the set of provided/required services Allow signal exchanges for compatibility

2 Distinct Port Types that Support2 Distinct Port Types that SupportDifferent Interface ConceptsDifferent Interface Concepts

66

FlowPorts Additional considerations

Simple (natural) way for SEs to specify I/O via the port Address the common case of atomic FlowPorts Allow both signal flow and data/block instance flow

FlowPorts Specification I/O is specified using an interface stereotyped FlowSpecification FlowSpecification consists of properties stereotyped FlowProperties

FlowProperty has a direction attribute: in, out, inOut FlowProperties can be typed by ValueTypes, Block, and Signals isConjugate promotes reuse of flowSpecifications

Atomic FlowPorts It is common that a FlowPort flows a single item type In this case the port is directly typed by the item type (Block or

Value) Direction property specify the direction

Compatibility rules on ports facilitate interface compatibility

67

Item Flows Approach Distinct from what can flow via the port

specification Supports compact and intuitive modeling of

physical flows Supports top down description of flows without

imposing behavioral method (e.g. activities, state, interactions)

Is aligned with behavior thru refinement and allocation Facilitates flow allocations from an object node,

message, or signal from a behavioral diagram Properties of item flow can be specified and

constrained in parametric diagram

Item Flow Representation is Classical SE Modeling Item Flow Representation is Classical SE Modeling Paradigm to Represent What Flows in a Particular ContextParadigm to Represent What Flows in a Particular Context

68



trsm:Transmission


acl:accelerator


ft:FuelTankAssy

dif:Differential




Port:ICEFuelFitting

fuelDelivery

torqueOut:Torque

torquein:Torque

spline

fuelSupply:Fuel


bp:BatteryPack

i1:ElectricCurrent

i2:ElectricCurrent

fp:FuelPump

fi:FuelInjector


<>

<>

<><>

4

fuelReturn:Fuel

<>

<>

<>

<>

g1:Torque

t2:T

orqu

e

t1:Torque

ice

ctrl

I_ICECmds

I_ICECmds

ctrl

ctrl

I_ICEData I_ICEData

trsmepc

c3

c2

c1

I_IEPCCmdI_IEPCData

I_IEPCDataI_EPCCmd

I_TRSMData

I_TRSMCmd

I_TRSMCmd

I_TRSMData

<><>

<>

rightHalfShaft

<><>

<>

leftHalfShaft

Client server port

Flow port

Item flow

Specifying Interfaces on an IBDSpecifying Interfaces on an IBD in Terms of Connectors, Ports and Flowsin Terms of Connectors, Ports and Flows

Connector

Parametrics & MOE’s/Objective Functions

70

Parametrics Used to express constraints (equations) between value

properties Provides support to engineering analysis (e.g. performance,

reliability, etc) Reusable (e.g. F=m*a is reused in many contexts) Non-causal (i.e. declarative statement of the invariant without

specifying dependent/independent variables) Constraint block defined as a simple extension of block

Packages UML constraint so they are reusable and parameterized Constraint and constraint parameters are specified Expression language can be formal (e.g. MathML, OCL …) or

informal Computational engine is defined by applicable analysis tool and

not by SysML Parametric diagram represents the usage of the constraints in

an analysis context Binding of constraint usage to value properties of blocks (e.g.

vehicle mass bound to F= m * a) Can use nested notation or dot notation

MOE’s and objective functions integrated with Parametrics to support trade studies and engineering analysis

Parametrics Scalability & Integration with Engr Parametrics Scalability & Integration with Engr Analysis Validated by Georgia TechAnalysis Validated by Georgia Tech

71

Defining Vehicle Dynamicsbdd [package] HSUVAnalysis [Definition of Dynamics]

parameterswhlpowr:RealCd:RealCf:Realtw:Realtp:Realv:Reali:Real

Constraints{tp(hp) = whlpowr - (Cd*v)- (Cf*tw*v)}}

«constraint»PowerEquation

parameterstw:Realdt:Realtp:Reala:Real

Constraints{a(g) = F/m = P*t/m = (550/32)*tp(hp)*delta-t*twi}

«constraint»AccelerationEquation

parametersdt:Realv:Reala:Real

Constraints{v(n+1)=v(n)+dv = v(n) + a*dt}{v(n+1 =v(n)+a*32*3600/5280*dt}

«constraint»VelocityEquation

parametersdt:Realv:Realx:Real

Constraints{x(n+1)=x(n)+dx(dt)=x(n)+v*dt}{x(n+1)=x(n)+v*5280/3600*dt}

«constraint»PositionEquation

parameterswhlpowr:RealCd:RealCf:Realtw:Realacc:Realvel:Realincline:Real

«constraint»StraightLine

VehicleDynamics

Defining Reusable Equations for ParametricsDefining Reusable Equations for Parametrics

72

Evaluating Vehicle Dynamicspar [constraintBlock] StraightLineVehicleDynamics

AccellerationEquation

VelocityEquation

PostionEquation

PowerEquation

«value»globalTime.delta-t

whlpwr twCd Cf

tp

tp

dt

dt

dt

tw

tw

a

a

v

v

acc

vel

Cf

Cd

whlpwr

v

x

«value»HSUV.position

incline

i

Using the Equations in a Parametric Diagram to Using the Equations in a Parametric Diagram to Constrain the Value PropertiesConstrain the Value Properties

73

Evaluating Measures of Effectiveness

par [constraintBlock] MeasuresOfEffectiveness [HSUV MOEs]

«objectiveFunction»

:MyObjectiveFunction{CE = ∑ Wi*Pi}


«moe»HSUValt1.FuelEconomy

«moe»HSUValt1.Zero60Time


«moe»HSUValt1.QuarterMileTime

Instance ofconstraint block isidentical for eachalternative

«moe»HSUValt1.UnitCost

:EconomyEquationf:

:MaxAccelerationAnalysis

q:

z:

:CapacityEquationvc:

:UnitCostEquationuc:

p4:

p1:

p2:

p3:

p5:

CE:

MOE’s and objective function provide flexible support for MOE’s and objective function provide flexible support for trade study analysis that is fully integrated with parametricstrade study analysis that is fully integrated with parametrics

74

Constraint Blocks - Comparison of Block-based vs. Collaboration-based approach Concrete Syntax

More notational changes to default collaboration notation required to support chosen Constraint Block notation

Abstract Syntax Additional abstract syntax required for deep-nested

bindings Need to relax UML Collaboration constraints in order to

support deep-nested bindings CollaborationUse does not support inheritance or

redefinition Semantics

Constraint Blocks can denote objects to represent equations with state

Collaboration Use cannot be a defining feature of a slot, so cannot build instance specification hierarchy for blocks with constraints

Connectors can specify multiplicities on bindings to multi-valued parameters or propertiesBlocks Based Approach Retains Structural Integrity Blocks Based Approach Retains Structural Integrity

and Simplifies Languageand Simplifies Language

Behavioral Constructs

76

Behavioral Constructs Activities Interactions State Machines Use Cases

Activities

78

Activities Activities used to specify flow of I/O and

control Input/Output represented by object

node/pins that are typed by blocks External I/O called a parameter

Control flow represent enabling of activity Control constructs include decision, merge, fork,

join, initial node, activity final, flow final SysML extensions to Activities

Alignment of activities with EFFBD Non normative appendix specifies specific

execution rules for EFFBD support Does not explicitly support replication and

resources Support for continuous flow modeling

79

SysML EFFBD Profile

ExternalInput

ExternalOutput

2.1 SerialFunction

2.2 Multi-exitFunction

2.3 Function inConcurrency

Item 1

2.4 Function inMulti-exitConstruct

2.5 Function inan Iterate

[ before third time ]

Item 2

«optional» [ afterthirdtime ]

2.6 OutputFunction

«optional»

Item 3

Item 4

«optional»

«optional»

{cc#1}

{cc#2}

«effbd»act

Aligning SysML with Proven Systems Engineering Techniques Aligning SysML with Proven Systems Engineering Techniques

Refer to Appendix C.1 for Details & Execution Rules

80

Dirty water@ 20 deg C

Heat Dirty waterTo 100 deg C

Heat to Dirtywater

Boil Dirty water

Dirty water@ 100 deg C Steam

Residue

and

Condensesteam

DrainResidue

Purewater

Disposedresidue

and

Heat to Boilwater

Energy tocondense

Distiller Example Provided by D. Oliver

81

Distill Water Activity Diagram (Initial)

«effbd»act [activity] DistillWater [Simple Starting Point)

a1:HeatWater a2:BoilWater

a3:CondenseSteam

a4:DrainResidue

coldDirty:H2O[liquid]

hotDirty:H2O[liquid]

steam:H2O[gas]

pure:H2O[liquid]

hiPress:Residue loPress:Residueexternal:Heatrecovered:Heat

recovered:Heat

Note: these arethe same thing!

Representing Distiller Example in SysMLRepresenting Distiller Example in SysMLUsing EFFBD Profile Using EFFBD Profile

82

Distill Water Activity Diagram (Continuous Flow Modeling)

act [activity] DistillWater [Parallell Continuous Activities)

a1:HeatWater

a2:BoilWater

a3:CondenseSteam

a4:DrainResidue

«continuous»coldDirty:H2O

[liquid]

«continuous»hotDirty:H2O

[liquid]

«continuous»steam:H2O

[gas]

«continuous»pure:H2O

[liquid]

hiPress:Residue

loPress:Residue

«continuous»external:Heat

«continuous»recovered:Heat

Representing Distiller Example in SysMLRepresenting Distiller Example in SysML Using Continuous Flow Modeling Using Continuous Flow Modeling

Interactions

84

Interactions Sequence diagrams provide

representations for message based behavior Represents flow of control

Less effective than activities for representing inputs from multiple sources

UML 2 sequence diagrams significantly more scalable by providing reference sequences, control logic, and lifeline decomposition

Timing diagrams provide representations for typical system timelines and value properties vs time

No change to UML Minor clarification on continuous time

representations

85

Black Box Interaction (Drive)sd DriveBlackBox

par

alt controlSpeed

driver:Driver hybridSUV:HybridSUV

refStartVehicleBlackBox

refPark/ShutdownVehicle

refSteer

refAccelerate/Cruise

refBrake

refIdle

[self.oclInState(idle)]

[self.oclInState(accelerating/cruising)]

[self.oclInState(braking)]

UML 2 Sequence Diagram More Scalable UML 2 Sequence Diagram More Scalable by Supporting Control Logic and Reference Sequencesby Supporting Control Logic and Reference Sequences

86

Black Box Sequence (StartVehicle)

sd StartVehicleBlackBox

driver:DriverhybridSUV:HybridSUV

ref StartVehicleWhiteBox

1: StartVehicle()

turnIgnitionToStart

Simple Black Box InteractionSimple Black Box Interaction

References Lifeline DecompFor White Box Interaction

87

White Box Sequence (StartVehicle)

sd StartVehicleWhiteBox

ecu:PowerControlUnit epc:ElectricalPowerController

1.1: Enable

1: StartVehicle

1.2:ready

Decomposition of Black BoxDecomposition of Black BoxInto White Box InteractionInto White Box Interaction

88

Trial Result of Vehicle Dynamics

tim MaxAcceleration [100 Wheel Horsepower]

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0 5 10 15 20

Time (sec)

Acc

elle

rati

on

(g

)

0

20

40

60

80

100

120

140

0 5 10 15 20

Time (sec)

Velo

city

(m

ph

)

0

200

400

600

800

1000

1200

1400

1600

1800

0 5 10 15 20

Time (sec)

Dis

tan

ce

(ft)

Satisfies«requirement»Acceleration

«diagramDescription»version=”0.1"description=”Constant100 wheel horsepower,4000 lb vehicle weight,simple drag"reference=”Equations ofMotion”completeness=”assumesperfect tire traction”

Typical Example of a Timing DiagramTypical Example of a Timing Diagram

Lifeline arevalue properties

State Machines

90

State Machines Supports event based behavior (generally

asynchronous) Transition with event, guard, action State with entry, exit and do-activity Can include nested sequential or concurrent

states Two types of state machines

Behavior state machines is typical use Protocol state machines used to specify

sequence of operations or signals Can be used as a specification on a port

No change to UML

91

Operational States (Drive)stm HSUVOperationalStates

Operate

Idle

Accellerating/Cruising

Braking

engageBrake

accelerate stopped

releaseBrake

shutOff

Off

start

keyOff

Refines«requirement»PowerSourceManagement

Abnomal state(acceleratorsticks) - abortsymbol

Nominalstates only

Use Cases

93

Use Cases Provides means for describing

basic functionality in terms of usages of system by actors

Generally elaborated via other behavioral representations to describe detailed scenarios

No change to UML

94

Top Level Use Casesuc HSUVUseCases [TopLevelUseCases]

HybridSUV

Driver

Operate thevehicle

Maintain thevehicle

Maintainer

Insure thevehicle

Register thevehicle

InsuranceCompany

DepartmentOf MotorVehicles

RegisteredOwner

95

Operational Use Casesuc HSUVUseCases [Operational Use Cases]

HybridSUV

Driver

AccelerateDrive the vehicle

Steer

Brake

«include»

«include»

«include»

Park «include»

«extend»

Start the vehicle

Cross-cutting Constructs

97

Cross-cutting Constructs Allocations Requirements Profiles & Model Libraries

Allocations

99

Allocations Provides general relationship to map one

model element to another Includes specific subclasses of allocation

with constraints on their usage Behavioral Structural Flow

Explicit allocation of activities to swim lanes (e.g. activity partitions)

Graphical and/or tabular representations

100

Different Allocation Representations(Tabular Representation Not Shown)

ElementName1

ElementName3

to

ElementName2

from

«allocate»

to

«allocate»:ElementName

ActivityName

Explicit Allocation ofActivity to Swim Lane

Allocate Relationship

Callout NotationCompartment Notation

«block»BlockName

PartName

allocatedFrom«elementType»ElementName

«block»BlockName

allocatedFrom«elementType»ElementName

PartName

Requirements

102

Requirements Requirements represents a text based

requirement Minimal properties specified for id and text based on

user feedback Stereotype mechanism used to categorize

requirements (e.g. functional, physical) Able to specify constraints on what design elements can

satisfy the requirement (refer to Appendix C.2) Stereotype of class (abstract) without instances

Requirements containment used to specify requirements hierarchy as a collection of requirements (e.g., a specification)

SST uses cross hairs notation vs black diamond composition to be consistent with containment semantics

Requirements relationships based on subclasses of dependency

Derive, Satisfy, Verify, Refine, ..

103

Dependencies Used to specify relationships among

requirements (other uses as well) Different concept for SE’s with arrow direction

reversed from typical requirements flow-down Refer to next slide

Represents a relationship between client and supplier elements Client depends on supplier

A change in supplier results in a change in client Application to requirements: A change in

requirement (supplier) results in a change in design element that satisfies it (client) or requirement derived from it (client)

Dependency Relationship Is New Concept for Some SE’sDependency Relationship Is New Concept for Some SE’s

104

Example of Derive/Satisfy Requirement Dependencies

Client

Supplier


«requirement»Accelleration

«requirement»CargoCapacity

«requirement»OffRoadCapability

«deriveReqt» «deriveReqt» «deriveReqt»


«satisfy»Client

Supplier

Arrow Direction Opposite Typical Requirements Flow-DownArrow Direction Opposite Typical Requirements Flow-Down

105

Requirements & Allocations Alignment V0.9 Issue

Inconsistent concrete syntax for cross-cutting relationships

Allocations used compartments/callouts, requirements did not

Limitations in displaying requirement relationships

Requirements needed to be shown on same diagram as target of relationship –> cluttered diagrams

Requirements couldn’t be shown on internal block diagrams.

Basis for cross-cutting relationships seemed inconsistent, and needed to be unified

Requirements relationships were built on Trace Allocation relationship was built on Usage

106

Representing Requirements and Allocation Relationships

act ProvidePower [with Swimlane Allocation]

«allocate»ElectricalPowerContr

oller

«allocate»ElectricalMotorGener

ator

a3:ControlElectricPower

«continuous»eThrottle

a4:ProvideElectricPower

«continuous»driveCurrent

«continuous»elecDrivePower

allocatedTo«itemFlow»i1:ElectricCurrent

ibd [block] PowerSubsystem [Power Functional Allocation]

allocatedFrom«activity»ConvertElectricToPower


allocatedFrom«activity»ControlElectricPower


i1:ElectricCurrent

i2:ElectricCurrent

allocatedFrom«objectNode»driveCurrent

<> <>


Consistent and Compact Crosscutting NotationsConsistent and Compact Crosscutting Notations

Allocations callout notationRequirements callout notation

Profiles & Model Libraries

108

Stereotypes & Model Libraries Mechanisms for further customizing

SysML Profiles

Use of stereotype to extend meta-classes with properties and constraints

Stereotype properties capture metadata about the model element that is not instantiated

Profile is applied to user model Profile can also restrict the subset of the

model that is applied Model Libraries represent reusable

libraries of model elements

109

Stereotypes

«metaclass»NamedElement

«stereotype»ConfigurationItem

author: Stringversion: StringlastChanged: Date

Defining the Stereotype Applying the Stereotype

«configurationItem»Engine

author=”John Doe”version=”1.2"lastChanged=Dec12, 2005

Appendixes

111

Appendixes Diagrams Sample Problem Non-Normative Extensions Model Interchange Requirements Traceability Terms and Definitions BNF Diagram Syntax Definitions

Appendix ADiagrams

113

Diagram Appendix A Provides general guidelines for the

use of diagrams Diagram headings

Naming of diagrams Diagram descriptions

Capturing information about diagrams Diagram usages

Specifying unique diagram kinds Other general guidelines (e.g. tabular

representations, use of rake symbol, ..)

114

Application of Diagram GuidelinesExample

bdd [package] DistillerStructure [Structural Breakdown]

«block»Distiller

«block»HeatExchanger

«block»Boiler

«block»DrainValve

dvbxhx

«diagramDescription»version=”0.1"description=”initial structuralbreakdown of distillersystem"reference=”TBD”completeness=”ItemFlowsand Connectors elided”

A Diagram Description(refer to App A)

Diagram Heading Names(refer to App A)

Appendix BSample Problem

116

Sample Problem Appendix B Highlights selected features of

SysML using a Hybrid SUV example Refer to sample problem in later

slides

Appendix CNon-Normative Extensions

118

Non-Normative Extensions Appendix C Provides set of non-normative

extensions that may become normative in future revisions EFFBD profile Requirements categories Measures of effectiveness (moe) and

objective function

Appendix DModel Interchange

120

Model Interchange Appendix D SysML Model Interchange Standards

XMI AP233

XMI is the means for model exchange between SysML conformant tools

SysML Profile metamodel defined in XMI 2.1 To be provided when XMI issues are sufficiently resolved in ballot

12 (TBD) Model interchange with non-MOF/UML tools supported

using ISO-10303 AP233 Both file and API-based SysML-AP233 interchange approaches

are supported based on alignment with similar concepts in AP233

Provides gateway to model repositories that are based on schema in use by

other engineering disciplines (e.g, mechanical - MCAD) user domains (e.g, DoD architectures – DoDAF/CADM)

Supports INCOSE’s vision for model driven systems engineering

Appendix ERequirements Traceability Matrix

122

Requirements Traceability Appendix E Provides traceability from SysML to requirements

in UML for SE RFP Section 6.2.1, of the RFP states "Submitters may

provide partial responses to these requirements, along with a roadmap to address the complete requirements."

Most requirements satisfied in v0.9 Matrix updated to be consistent with SST v0.98

Small number of mandatory requirements in 6.5 deferred to v2.0

Modeling of verification (6.5.4.4) limited to “test case”. Initial analysis showed “test case” is key element to integrate with UML testing profile

Modeling of “Problem” (6.5.5) deferred to address causal analysis

Modeling of “replication” and “resources” under function (6.5.2.1.3) not fully implemented per EFFBD semantics

Appendix FTerms and Definitions

124

Terms & Definitions Appendix F Consists of a superset of terms from

UML for SE RFP UML 2 SysML v0.9 SysML v0.98

Will provide distilled list to support tool vendor implementation and user glossary Reuse terms & definitions as-is Refine others to be consistent with

chapters Delete others

Appendix GBNF Diagram Syntax Definitions

126

BNF Diagram Syntax Definitions App G A formalism provided by Deere &

Company (R. Burkhart) to support a more precise mapping between the language abstract syntax / semantics and the concrete syntax (notation)

Initial input provided for Model Elements, Blocks, and Constraint Blocks chapters Provided valuable mechanism to define more

complete diagram syntax tables Will be considered for broader

application in future revisions

HSUV Sample ProblemSST Appendix B

128

Sample Problem Examples The following examples are extracted

from Appendix B of the SST Specification Highlights selected features of SysML Modeling artifacts from typical SE process

Slide ordering does not represent process sequence

Visio used as a vendor neutral format Refer to Appendix B for a more complete

description of the sample problem Contact the vendor reps on SST to see

their SysML implementations and sample problem demo

129

Sample Problem Coverage Organizing the model Requirements Behavior Structure Allocating behavior to structure Analyzing performance & MOE’s

130

Setting up the User Model

pkg ModelingDomain [Establishing HSUV Model]


«import»

«profile»SysML

HSUVModel

«apply»{strict}

«apply» {strict}

131

Organizing the User Modelpkg HSUVModel

HSUVViews

HSUVRequirementsHSUVStructureHSUVBehavior

DeliverPowerBehavior

HSUVAnalysis

«view»Performance

View

«viewpoint»Performance

Viewpoint

«access»«block»Automotive

Domain

«view»OperationalView

«viewpoint»OperationalViewpoint

«access»

«access»

HSUVUseCases

HSUVInterfaces«requirement»Performance

«access»

132

Setting the Context«Context Diagram»

ibd [block] AutomotiveDomain

«external»:Environment

«external»:Maintainer

«external»:Road

«diagramDescription»

version=”0.1"description=”Initial concept to identify top leveldomain entities"reference=”Ops Concept Description”completeness=”partial. Does not include gaspump and other external interfaces.”

«external»:ExternalObject

«external»driver:Driver

«external»:Passenger «external»

:VehicleCargo

«system»hybridSUV:HybridSUV

«external»:Weather

133

Top Level Use Casesuc HSUVUseCases [TopLevelUseCases]

HybridSUV

Driver

Operate thevehicle

Maintain thevehicle

Maintainer

Insure thevehicle

Register thevehicle

InsuranceCompany

DepartmentOf MotorVehicles

RegisteredOwner

134

Operational Use Casesuc HSUVUseCases [Operational Use Cases]

HybridSUV

Driver

AccelerateDrive the vehicle

Steer

Brake

«include»

«include»

«include»

Park «include»

«extend»

Start the vehicle

135

Black Box Interaction (Drive)sd DriveBlackBox

par

alt controlSpeed

driver:Driver hybridSUV:HybridSUV

refStartVehicleBlackBox

refPark/ShutdownVehicle

refSteer

refAccelerate/Cruise

refBrake

refIdle

[self.oclInState(idle)]

[self.oclInState(accelerating/cruising)]

[self.oclInState(braking)]

136

Operational States (Drive)stm HSUVOperationalStates

Operate

Idle

Accellerating/Cruising

Braking

engageBrake

accelerate stopped

releaseBrake

shutOff

Off

start

keyOff

Refines«requirement»PowerSourceManagement

Abnomal state(acceleratorsticks) - abortsymbol

Nominalstates only

137

Black Box Sequence (StartVehicle)

sd StartVehicleBlackBox

driver:DriverhybridSUV:HybridSUV

ref StartVehicleWhiteBox

1: StartVehicle()

turnIgnitionToStart

138

White Box Sequence (StartVehicle)

sd StartVehicleWhiteBox

ecu:PowerControlUnit epc:ElectricalPowerController

1.1: Enable

1: StartVehicle

1.2:ready

139

Requirements Breakdownreq [package] HSUVRequirements [HSUV Specification]

«requirement»Eco-Friendliness

«requirement»Performance

«requirement»Capacity«requirement»

Ergonomics

«requirement»Braking

«requirement»FuelEconomy



Id = R1.2.1text = The vehicle shall meet Ultra-LowEmissions Vehicle standards.

«requirement»Emissions

«requirement»PassengerCapacity

«requirement»FuelCapacity


HSUVSpecification

«requirement»Qualification

«requirement»SafetyTest

140

Requirements Derivationreq [package] HSUVRequirements [Requirement Derivation]

«requirement»Braking

«requirement»FuelEconomy

«requirement»RegenerativeBraking

«requirement»PowerSourceManagement


«deriveReqt»«deriveReqt»

«deriveReqt»

«deriveReqt»



«requirement»FuelCapacity


«requirement»Range

«deriveReqt»«deriveReqt»

«deriveReqt» «deriveReqt» «deriveReqt»

RefinedByHSUVStructure::HSUV.HSUVOperationalStates

«rationale»Power delivery must happen by coordinatedcontrol of gas and electric motors.reference= “Hybrid Design Guidance”

141

Reqts Refinement/Verificationreq [package] HSUVRequirements [Acceleration Requirement Refinement and Verification]

«requirement»Acceleration

HSUVUseCases::Accelerate


«refineReqt»

«satisfy»


«deriveReqt»

«testCase»Max Acceleration

«verify»

142

Requirements Tables & Trees

table [requirement] Performance [Tree of Performance Requirements]

table [requirement] Performance [Decomposition of Performance Requirement]

table [requirement] Capacity [Decomposition of Capacity Requirement]

id name text

4 CapacityThe Hybrid SUV shall carry 5 adult passengers, along with sufficient luggage and fuel for a typical weekend campout.

4.1 CargoCapacityThe Hybrid SUV shall carry sufficient luggage for 5 people for a typical weekend campout.

4.2 FuelCapacityThe Hybrid SUV shall carry sufficient fuel for a typical weekend campout.

4.3 PassengerCapacity The Hybrid SUV shall carry 5 adult passengers.

id name text

2 Performance

The Hybrid SUV shall have the braking, acceleration, and off-road capability of a typical SUV, but have dramatically better fuel economy.

2.1 BrakingThe Hybrid SUV shall have the braking capability of a typical SUV.

2.2 FuelEconomyThe Hybrid SUV shall have dramatically better fuel economy than a typical SUV.

2.3 OffRoadCapabilityThe Hybrid SUV shall have the off-road capability of a typical SUV.

2.4 AccelerationThe Hybrid SUV shall have the acceleration of a typical SUV.

id name relation id name relation id name2.1 Braking deriveReqt d.1 RegenerativeBraking2.2 FuelEconomy deriveReqt d.1 RegenerativeBraking2.2 FuelEconomy deriveReqt d.2 Range4.2 FuelCapacity deriveReqt d.2 Range2.3 OffRoadCapability deriveReqt d.4 Power deriveReqt d.2 PowerSourceManagement2.4 Acceleration deriveReqt d.4 Power deriveReqt d.2 PowerSourceManagement4.1 CargoCapacity deriveReqt d.4 Power deriveReqt d.2 PowerSourceManagement

143

Context/Enterprise Breakdownbdd [package] HSUVStructure [Automotive Domain Breakdown]

interactionsStartVehicleBlackBoxStartVehicleWhiteBox

«domain, block»AutomotiveDomain

«system, block»HybridSUV

«external»VehicleCargo

«external»Driver

«external»Maintainer

«external»Passenger

«external»Environment

«external»Road

driver

hybridSUV

«external»Weather

«external»ExternalObject

144

System Breakdownbdd [block] AutomotiveDomain [HybridSUV Breakdown]

«system, block»HybridSUV


«block»BrakePedal

«block»ChassisSubsytem

«block»BrakeSubsystem

«block»InteriorSubsystem

«block»LightingSubsystem

«block»BodySubsystem


4

145

System Internal Block Diagram

ibd [block] HybridSUV

PowerSubsystem

ChassisSubsytem BrakeSubsystem

InteriorSubsystem

LightingSubsystem

BodySubsystem

146

Power Subsystem Breakdownbdd [block] HSUV [PowerSubsystem Breakdown]


«block»ElectricMotor

Generator

«block»FrontWheel

«block»accelerator


«block»Differential

«block»Transmission


«block»FuelInjector

lfw

4

«block»BatteryPack

«block»ElectricalPowerController

«block»PowerControlUnit

«block»FuelPump

«block»BrakePedal


rfw

147



trsm:Transmission


acl:accelerator


ft:FuelTankAssy

dif:Differential




Port:ICEFuelFitting

fuelDelivery

torqueOut:Torque

torquein:Torque

spline

fuelSupply:Fuel


bp:BatteryPack

i1:ElectricCurrent

i2:ElectricCurrent

fp:FuelPump

fi:FuelInjector


<><>

<><>

4

fuelReturn:Fuel

<>

<><>

<>

g1:Torque

t2:T

orqu

e

t1:Torque

ice

ctrl

I_ICECmds

I_ICECmds

ctrl

ctrl

I_ICEData I_ICEData

trsmepc

c3

c2

c1

I_IEPCCmdI_IEPCData

I_IEPCDataI_EPCCmd

I_TRSMData

I_TRSMCmd

I_TRSMCmd

I_TRSMData

<><>

<>

rightHalfShaft

<><>

<>

leftHalfShaft

148

Test Result Instanceins SUV_EPA_Fuel_Economy_Test_Result

Satisfies«requirment»Emissions

VIN = G12345

TestVehicle1/hsuv:HSUV

p67890/p:PowerSubsystem

c34567/c:ChassisSubsytem

bk45678/bk:Brake

Subsystem

i23456/int:InteriorSubsystem

lt56789/lt:Lighting

bSubsystem

b12345/b:BodySubsystem

eid78901/ice:InternalComb

ustionEnginesn89012/

t:transmissionsn90123/


«testCase»testRun060401/

epaTest:EPAFuelEconomyTest

Verifies«requirment»Emissions

149

Power Subsystem Interface Defn

bdd [block] PowerSubsystem [ICE Interface Definitions]

getRPM():integergetTemperature():floatisKnockSensor():boolean

«interface»I_ICEData

setThrottle(throttlePosition:float):voidsetMixture(mixture:float):void

«interface»I_ICECmds

150

Fuel System Definitionbdd [block] HSUV [PowerSubsystem Fuel Flow Definition]

temperature:Realpressure:Real

«block»Fuel

«flowProperties» out fuelSupply:Fuel in fuelReturn:Fuel

«flowSpecification»FuelFlow


«flowProperties» in fuelSupply:Fuel out fuelReturn:Fuel


«flowProperties» » out fuelSupply:Fuel in fuelReturn:Fuel


FuelTankFitting:FuelFlow

ICEFuelFitting:FuelFlow<>

<>

151

Fuel Flow Parametricspar [Block]PowerSubsystem

constraints

{flowrate=press/(4*injectorDemand)}

fuelflow:FuelFlow

press:Real

injectorDemand:Real

ice.fr.fuel.FuelPressure::Real

ice.fi.FuelDemand:Real

flowrate:Real

ice.ft.FuelFlowRate:Real

152

Fuel Subsystem Designibd [block] PowerSubsystem [Fuel Distribution Detail]


ft:FuelTankAssy

fuelSupplyLine

fuelSupply:Fuel

fp:FuelPump

fi1:FuelInjector

4

fuelReturn:Fuel

fre:FuelRegulatorfra:FuelRail

p1:Fuel

p2:FuelfuelReturnLine

fi2:FuelInjector

fi3:FuelInjector

fi4:FuelInjector

allocatedFrom«connector»fdist

fuelFitting:Fuel

allocatedFrom«connector»FuelDelivery

153

Overall Analysis Contextbdd [package] HSUVAnalysis [Analysis Context]


«constraint»RollingFriction

Equation

«constraint»AeroDragEquation


VehicleDynamics

«testCase,Interaction»MaxAcceleration

«requirement»Acceleration

«verify»

«block»GlobalTime


«domain, block»HSUVStructure::

AutomotiveDomain

parameters

V1:RealV2:RealV3:Real

constraints

{pcap = ∑ Vi}


154

Performance View Definitionpkg [package] HSUVViews [Performance View]

«view»PerformanceView

Driver

Drive Car «viewpoint»stakeholders="customer"purpose="Highlight the performance of thesystem."construction rules="show performancerequirements, test cases, MOE, constraintmodels, etc.; includes functional viewpoint"

Performance Viewpoint

«viewpoint»Functional Viewpoint

id = 2Text = The Hybrid SUVshall have the braking,acceleration, and off-roadcapability of a typical SUV,but have dramatically betterfuel economy.

<<requirement>>Performance


«moe»HSUValt1.Fuel

Economy

«moe»HSUValt1.Zero

60Time


«moe»HSUValt1.Quar

terMileTime




«testCase»EPAFuel

EconomyTest

155

Evaluating Measures of Effectiveness

par [constraintBlock] MeasuresOfEffectiveness [HSUV MOEs]

«objectiveFunction»

:MyObjectiveFunction{CE = ∑ Wi*Pi}


«moe»HSUValt1.FuelEconomy

«moe»HSUValt1.Zero60Time


«moe»HSUValt1.QuarterMileTime

Instance ofconstraint block isidentical for eachalternative

«moe»HSUValt1.UnitCost

:EconomyEquationf:

:MaxAccelerationAnalysis

q:

z:

:CapacityEquationvc:

:UnitCostEquationuc:

p4:

p1:

p2:

p3:

p5:

CE:

156

Evaluating Fuel Economypar [constraintBlock] EconomyEquation

StraightLineVehicleDynamics

RollingFrictionEquation

AeroDragEquation

TotalWeight

PayloadEquation

cgoWtpsgrWt

psgrWt

volume

volume

vdw fw

«value»FuelTank.FuelWeight

Cd

Cd

tw

tw

tw

Cf

Cf

FuelEfficiencyEquationwhlpwr

accacc

vel mpgRoadElevProfile

incline

incline

RegenBrakeEfficiencyEquation

vel

incline

ebpwr

ebpwr

n_em

acc

n_ice

n_eg

«value»HSUV.PayloadCapacity

pcap

mpg

cgoWt

whlpwr

«value»HSUV.VehicleDryWeight

«value»ElectricMotorGenerator.GeneratorEfficiency

«value»ElectricMotorGenerator.MotorEfficiency

«value»InternalCombustionEngine.ICEEfficiency

157

Evaluating Vehicle Dynamicspar [constraintBlock] StraightLineVehicleDynamics

AccellerationEquation

VelocityEquation

PostionEquation

PowerEquation

«value»globalTime.delta-t

whlpwr twCd Cf

tp

tp

dt

dt

dt

tw

tw

a

a

v

v

acc

vel

Cf

Cd

whlpwr

v

x

«value»HSUV.position

incline

i

158

Defining Vehicle Dynamicsbdd [package] HSUVAnalysis [Definition of Dynamics]

parameterswhlpowr:RealCd:RealCf:Realtw:Realtp:Realv:Reali:Real

Constraints{tp(hp) = whlpowr - (Cd*v)- (Cf*tw*v)}}

«constraint»PowerEquation

parameterstw:Realdt:Realtp:Reala:Real

Constraints{a(g) = F/m = P*t/m = (550/32)*tp(hp)*delta-t*twi}

«constraint»AccelerationEquation

parametersdt:Realv:Reala:Real

Constraints{v(n+1)=v(n)+dv = v(n) + a*dt}{v(n+1 =v(n)+a*32*3600/5280*dt}

«constraint»VelocityEquation

parametersdt:Realv:Realx:Real

Constraints{x(n+1)=x(n)+dx(dt)=x(n)+v*dt}{x(n+1)=x(n)+v*5280/3600*dt}

«constraint»PositionEquation

parameterswhlpowr:RealCd:RealCf:Realtw:Realacc:Realvel:Realincline:Real


VehicleDynamics

159

Trial Result of Vehicle Dynamics

tim MaxAcceleration [100 Wheel Horsepower]

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0 5 10 15 20

Time (sec)

Acc

elle

rati

on

(g

)

0

20

40

60

80

100

120

140

0 5 10 15 20

Time (sec)

Velo

city

(m

ph

)

0

200

400

600

800

1000

1200

1400

1600

1800

0 5 10 15 20

Time (sec)

Dis

tan

ce

(ft)


«diagramDescription»version=”0.1"description=”Constant100 wheel horsepower,4000 lb vehicle weight,simple drag"reference=”Equations ofMotion”completeness=”assumesperfect tire traction”

160

“ProvidePower” Functional Decompbdd [activity] Accelerate [Activity and Object Flow Breakdown]

«activity»MeasureVehicle

Conditions

«activity»ProvidePower

«activity»MeasureVehicle

Velocity

«activity»MeasureBattery

Condition«activity»

ProvideGasPower«activity»

ControlElectricPower

«activity»ProportionPower

«activity»ProvideElectric

Power

a4

a3a2

a1

drivePower

«block»Power

«block»GasPower

«block»ElecPower

gasDrivePowerelecDrivePower

161

“ProvidePower” Behavior & Allocation

«(UserDefined)Swimlane Diagram»act ProvidePower [with Swimlane Allocation]

«allocate»PowerControlUnit

«allocate»InternalCombustionEngi

ne

«allocate»ElectricalPowerContr

oller

«allocate»ElectricalMotorGener

ator

a1:ProportionPower

a3:ControlElectricPower

a2:ProvideGasPower

«continuous»speed

«continuous»battCond

«continuous»eThrottle

«continuous»gThrottle

a4:ProvideElectricPower

«continuous»driveCurrent

«continuous»elecDrivePower

«continuous»gasDrivePower

«continuous»accelPosition transModeCmd

keyOff

«continuous»drivePower

«continuous»vehCond

allocatedTo«itemFlow»i1:ElectricCurrent

162

Multiple Allocations shown on IBDibd [block] PowerSubsystem [Power Functional Allocation]

allocatedFrom«activity»ConvertElectricToPower


trsm:Transmission

allocatedFrom«activity»ConvertGasToPower


allocatedFrom«activity»ProportionPowerLoad

ecu:PowerControlUnitepc:IFS_EPC

fp:FS_ICE

allocatedFrom«activity»ControlElectricPower


i1:ElectricCurrent

i2:ElectricCurrent

fp:FS_EPC

fp:FS_TRSM

allocatedFrom«objectNode»driveCurrent

allocatedFrom«connector»c1

«connector»c2 «connector»c3

can:CAN_Bus

ice:IFS_ICE

etrsm:IFS_TRSM

<>

<>

<>

<>

<>

<>

<>

<>

«diagramDescription»version=”0.1"description=”allocation ofbehavior and connectors toelements of power subsystem"reference=”null”completeness=”partial. Powersubsystem elements that haveno allocation yet have beenelided”

163

Allocation Table w/Allocation Type

table [activity] ProvidePower [Allocation Tree for Provide Power Activities]

type name end relation end type nameactivity a1:ProportionPower from allocateBehavior to block PowerControlUnitactivity a2:ProvideGasPower from allocateBehavior to block InternalCombustionEngineactivity a3:ControlElectricPower from allocateBehavior to block ElectricalPowerControlleractivity a4:ProvideElectricPower from allocateBehavior to block ElectricalMotorGeneratorobjectNode driveCurrent from allocateFlow to itemFlow i1:ElectricCurrent

Distiller Example

David Oliver12/7/05

An example to raise questions

165

Dave Oliver PrefaceSystem View Interconnection

In my experience of watching the development of OMT in GE and then UML, it appeared that the many views introduced were not fully interrelated. The view represented facets of reality, yet they did not fully provide the interconnections that exist in reality.

This example is presented to help ask similar questions about SysML for the current review. Consider an activity model for distilling dirty water. A crude EFFBD is shown.

166

Dirty water@ 20 deg C

Heat Dirty waterTo 100 deg C

Heat to Dirtywater

Boil Dirty water

Dirty water@ 100 deg C Steam

Residue

and

Condensesteam

DrainResidue

Purewater

Disposedresidue

and

Heat to Boilwater

Energy tocondense

Distiller Example(as provided by D. Oliver)

The ovals in the figure are I/O in AP233, items in CORE and I believe object nodes in the submissions.

167

Q1: what is the list entities in the submission can be object nodes?Q2: would the water, steam, etc be Blocks?Q3: How would heat be represented?

The water has properties: vol = 1 liter, density 1 gm/cm3, temp 20 deg C, specific heat 1cal/gm deg C, heat of vaporization 540 cal/gm.

Q4: do the submissions allow the application of parametrics to the object nodes to calculate the heat required to heat the water, boil the water, and condense the water?

Questions

168

The questions above relate only to the activity diagram (EFFBD). One does not have a design until the activities are allocated to physical thins, probably Blocks.

Allocate heat dirty water and condense steam to a block Counter Flow Heat Exchanger

Allocate boil dirty water to a block Boiler

Allocate drain residue to a block Drain

These allocations require that particular interconnections exist among these three blocks.

Q5: How does the language support or enforce the existence of the required interconnections among blocks? Does the engineer have to build this correctly without language support?

Questions (cont.)

169

These allocations require that the object nodes are identical to the flows or interface specifications (the labels) associated with these interconnections.

Q6: How does the language support or enforce the identity between the object nodes and the labels associated with the interconnections? Does the engineer have to build this correctly without language support?

Questions (cont.)

Response to Dave’s ExampleDistiller System

171

Distiller System – Package Overview

pkg [model] Distiller [Model Overview]

DistillerBehavior DistillerStructure

UnitTypes

DistillerRequirements DistillerUseCases

ItemTypes

Organizing the ModelOrganizing the Model

172

Units Librarybdd [package] Unit Types

«value»unit=degreesCentigradedimension=temperature

ºC

«value»unit=kilogram/meter^2dimension=pressure

kg/m²

«value»unit=calory/seconddimension=energyflow

cal/s

«value»unit=meterdimension=length

m

«value»unit=kilogramdimension=mass

kg

«value»unit=kilogram/seconddimension=massflow

kg/s

Defining the UnitsDefining the Units

173

Behavior Breakdownbdd [package) DistillerBehavior [Distiller Behavior Breakdown]

«activity»DistillWater

«activity»HeatWater

«activity»BoilWater

«activity»CondenseSteam

«activity»DrainResidue

valuestemp=*Cpress=kg/m^2

«block»ItemTypes::H2O

«block»ItemTypes::Heat

a2a1

a4a3

coldDirty

steam

hotDirty

pure

external

recovered

«block»ItemTypes::Residue

hiPress

loPress

Distill Activity Decomposition and Types of FlowsDistill Activity Decomposition and Types of Flows

174

H20 Statesstm [block] H2O

Solid

Liquid

Gas

Add Latent Heatof Vaporization

Remove Latent Heatof Vaporization

Remove Latent Heatof Liquification

Add Latent Heatof Liquification

175

Distill Water Activity Diagram (Initial)

«effbd»act [activity] DistillWater [Simple Starting Point)

a1:HeatWater a2:BoilWater

a3:CondenseSteam

a4:DrainResidue

coldDirty:H2O[liquid]

hotDirty:H2O[liquid]

steam:H2O[gas]

pure:H2O[liquid]

hiPress:Residue loPress:Residueexternal:Heatrecovered:Heat

recovered:Heat

Note: these arethe same thing!

Representing Distiller Example in SysMLRepresenting Distiller Example in SysML Using EFFBD Profile Using EFFBD Profile

176

Distill Water Activity Diagram (Continuous Activity Modeling)

act [activity] DistillWater [Parallell Continuous Activities)

a1:HeatWater

a2:BoilWater

a3:CondenseSteam

a4:DrainResidue


[liquid]


[liquid]


[gas]


[liquid]

hiPress:Residue

loPress:Residue



Representing Distiller Example in SysMLRepresenting Distiller Example in SysML Using Continuous Flow Modeling Using Continuous Flow Modeling

177

Distill Water – Swim Lane DiagramAllocated Behavior

act [activity] DistillWater [Swimlane Diagram]

«streaming»a1:HeatWater

«streaming»a2:BoilWater

«streaming»a3:CondenseSteam

a4:DrainResidue


[liquid]


shutdown

«allocate»hx:HeatExchanger

«allocate»bx:Boiler

«allocate»dx:DrainValve


[liquid]


[gas]


[liquid]

hiPress:Residue

loPress:Residue


Allocating the Activities to Swim LaneAllocating the Activities to Swim Lane that Represent Blocksthat Represent Blocks

178

Distiller System Hierarchy (Top Level)

bdd [package] DistillerStructure [Structural Breakdown]

«block»Distiller


«block»Boiler

«block»DrainValve

dvbxhx

«diagramDescription»version=”0.1"description=”initial structuralbreakdown of distillersystem"reference=”TBD”completeness=”ItemFlowsand Connectors elided”

Describing the Distiller System and Its ComponentsDescribing the Distiller System and Its Components

A Diagram FeatureProvided by SST Submission

(refer to App A)

179

Distiller Internal Block Diagramibd: [block] Distiller [DistillerBlockDiagram - Unallocated]

hx:HeatExchanger

:

bx:Boiler

:

dv:DrainValve

hx_water_out:H2O

bx_steam_out:H2O

water_in:H2O bx_sludge_out:Residue sludge_out:Residue

water_out:H2O

heat_in:Heat

Describing the Interconnection of PartsDescribing the Interconnection of PartsAnd the Item Flows Between ThemAnd the Item Flows Between Them

180

Distiller Internal Block Diagram(with Allocations)

ibd: [block] Distiller [DistillerBlockDiagram - Allocated]

allocatedFrom «activity»HeatWater: «activity»CondenseSteam:

hx:HeatExchanger

allocatedFrom «activity»BoilWater:

bx:Boiler

allocatedFrom «activity»DrainResidue:

dv:DrainValve

hx_water_out:H2O

bx_steam_out:H2O

Water_In:H2O bx_sludge_out:Residue Sludge_out:Residue

Water_out:H2O

Heat_in:Heat

allocatedFrom«objectNode»coldDirty:H2O

allocatedFrom«objectNode»hotDirty:H2O allocatedFrom

«objectNode»hiPress:ResidueallocatedFrom«objectNode»loPress:Residue

allocatedFrom«objectNode»steam:H2O

allocatedFrom«objectNode»Pure:H2OallocatedFrom

«objectNode»External:Heat

Showing the Allocations from ActivitiesShowing the Allocations from Activitiesand Object Nodes to Blocks and Item Flowsand Object Nodes to Blocks and Item Flows

181

Heat Exchanger Interface Specsbdd [block] HeatExchanger [HeatExchanger Flow Definition]

valuestemp=ºCpress=kg/m^2

«block»Fluid

valuesthermalEfficiency:Real


«block»CoolantSide

«block»CondensorSideqOut:HeatFlow

qIn:HeatFlow

<>

fIn:Fluid

fOut:Fluid

vIn:VaporFlow

fOut:FluidFlow

valuesdQ/dt=cal/s

«block»Heat

Constraints {temp <= 220 ºC,press <= 150 kg/m^2}

Constraints {temp <=400 ºC, press <= 1000 kg/m^2}

Describing the kind of things that can Flow (Fluid, Heat)Describing the kind of things that can Flow (Fluid, Heat)And Constraints on Flow PortsAnd Constraints on Flow Ports

182

Parametric Diagram – Thermal Analysis(includes constraints on I/O)par [block] Distiller [Simplified Isobaric Heat Balance Analysis}

water_in:H2O

«value»temp

heat_in:Heat

«value»dQ/dt

«value»massFlowRate

hx_water_out:H2O

«value»temp


bx_steam_out:H2O


water_out:H2O


equivalent{r1=r2}

r1

r2

equivalent{r1=r2}

r1

r2

SinglePhaseHeatXFREquation

tout

sh

mRate

Qrate

tin

condensing:SimplePhaseChange

Equation

lh

Qrate

mRate

boiling:SimplePhaseChange

Equation

lh

Qrate

mRate

ItemTypes::H2O

«value»specificHeat

«value»latentHeat

{Qrate=(th-tc)*mRate/sh)}

{Qrate=mRate*lh)}

Defining the Thermal EquationsDefining the Thermal Equationsas Constraints on the Flow Propertiesas Constraints on the Flow Properties

183

Analysis Results - Isobaric«analysisResult»

IsobaricHeatBalance1 [Results of Isobaric Heat Balance]

specific heat cal/gm-°C 1latent heat cal/cm 540

wat

er_i

n

hx_w

ater

_out

bx_w

ater

_in

bx_s

team

_out

wat

er_o

ut

mass flow rate gm/sec 6.75 6.75 1 1 1temp °C 20 100 100 100 100

dQ/dt cooling water cal/sec 540dQ/dt steam-condensate cal/sec 540condenser efficency 1heat deficit 0

dQ/dt condensate-steam cal/sec 540boiler efficiency 1dQ/dt in boiler cal/sec 540

Note: Cooling waterneeds to have 6x flowof steam!Need bypass betweenhx_water_out andbx_water_in!

Analysis Results Indicate Need for Analysis Results Indicate Need for Modification to Existing DesginModification to Existing Desgin

184

Behavior Breakdown - Revised

bdd [package) DistillerBehavior [Revised Distiller Behavior Breakdown]

«activity»DistillWater

«activity»HeatWater

«activity»BoilWater

«activity»CondenseSteam

«activity»DrainResidue

valuestemp=*Cpress=kg/m^2

«block»ItemTypes::H2O

«block»ItemTypes::Heat

a2a1

a4a3

coldDirty

steam

hotDirty

pure

external

recovered

«block»ItemTypes::Residue

hiPress

loPress«activity»ReturnSome

a5

hotDirty1

hotDirty2

New Activity Required To Meet the NeedNew Activity Required To Meet the Need

185

Swim Lane Diagram - Revised

act [activity] DistillWater [Revised Swimlane Diagram]

«streaming»a1:HeatWater

«streaming»a2:BoilWater

«streaming»a3:CondenseSteam

a4:DrainResidue


[liquid]


shutdown

«allocate»hx:HeatExchanger

«allocate»bx:Boiler

«allocate»dx:DrainValve


[liquid]


[gas]


[liquid]

hiPress:Residue

loPress:Residue


a5:ReturnSome

«continuous»hotDirty1:H2O

[liquid]

«continuous»hotDirty2:H2O

[liquid]

New Activity Shown in Swim Lane DiagramNew Activity Shown in Swim Lane Diagram

186

Distiller Internal Block Diag - Revised

ibd: [block] Distiller [Revised DistillerBlockDiagram - Allocated]

allocatedFrom «activity»HeatWater: «activity»CondenseSteam:

hx:HeatExchanger

allocatedFrom «activity»BoilWater:

bx:Boiler

allocatedFrom «activity»DrainResidue:

dv:DrainValve

bx_water_in:H2O

bx_steam_out:H2O

Water_In:H2O bx_sludge_out:Residue Sludge_out:Residue

water_out:H2O

Heat_in:Heat

allocatedFrom«objectNode»coldDirty:H2O allocatedFrom

«objectNode»hotDirty1:H2OallocatedFrom«objectNode»hiPress:Residue

allocatedFrom«objectNode»loPress:Residue

allocatedFrom«objectNode»steam:H2O

allocatedFrom«objectNode»Pure:H2OallocatedFrom

«objectNode»External:Heat

waste_water:H2O

allocatedFrom«objectNode»hotDirty2:H2O

Additional Item Flow Required To Support ChangeAdditional Item Flow Required To Support Change

187

Parametric Diagram – Thermal Analysis (Revised)par [block] Distiller [Detailed Heat Balance Analysis}

water_in:H2O

«value»temp

SinglePhaseHeatXFREquation

tout

sh

mRate

Qrate

condensing:PhaseChangeEquation

rate

lh

qout

boiling:PhaseChangeEquation

lh

qin

tinItemTypes::H2O

specificHeat

latentHeat

heat_in:Heat

«value»dQ/dt

t1

p1t2p2

t1

p1t2p2

http://www.spiraxsarco.com/learn/?redirect=html/2_15_01.htm


bx_water_in:H2O

«value»temp

«value»press


bx_steam_out:H2O

«value»temp

«value»press


water_out:H2O

«value»temp

«value»press


rate

sum{r1=r2+r3}

r1

r2

equivalent{r1=r2}

r1

r2

waste_water:H2O


r3

Revised Thermal Analysis To Support ChangeRevised Thermal Analysis To Support Change

188

Analysis Results – Non Isobaric Example

«analysisResult»PhaseChangeEquation [H20 - Mollier Diagram]

Update to Analysis ResultsUpdate to Analysis Results

Summary

190

SST SysML Submission Satisfies Most Requirements in the RFP

Small number of remaining req’ts to be addressed along with user/vendor feedback in future revisions

Critical Issues Resolved Multi-vendor implementations Our solution

Architecturally sound & compatible with UML 2/ XMI Implementable by multiple vendors Meets the needs of SE’s

Refer to Highlights and Comparison Matrix and these slides to contrast with SysML Partners submission

Systems Modeling Language (SysML)

Technology

uml extensions sysml

sysml background uml

uml reuse sysml reuses

uml metamodel

uml profile

subsetting uml

subset of uml

process sysml