Upload
evan-richard
View
237
Download
1
Embed Size (px)
Citation preview
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
«modelLibrary»SI Unit Types
«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
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
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.CostEffectiveness
«moe»HSUValt1.FuelEconomy
«moe»HSUValt1.Zero60Time
«moe»HSUValt1.CargoCapacity
«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»Power
«requirement»Accelleration
«requirement»CargoCapacity
«requirement»OffRoadCapability
«deriveReqt» «deriveReqt» «deriveReqt»
«block»PowerSubsystem
«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
emg:ElectricalMotorGenerator
allocatedFrom«activity»ControlElectricPower
epc:ElectricalPowerController
i1:ElectricCurrent
i2:ElectricCurrent
allocatedFrom«objectNode»driveCurrent
<> <>
Satisfies«requirement»Acceleration
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]
«modelLibrary»SI Unit Types
«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
«requirement»OffRoadCapability
«requirement»Accelleration
Id = R1.2.1text = The vehicle shall meet Ultra-LowEmissions Vehicle standards.
«requirement»Emissions
«requirement»PassengerCapacity
«requirement»FuelCapacity
«requirement»CargoCapacity
HSUVSpecification
«requirement»Qualification
«requirement»SafetyTest
140
Requirements Derivationreq [package] HSUVRequirements [Requirement Derivation]
«requirement»Braking
«requirement»FuelEconomy
«requirement»RegenerativeBraking
«requirement»PowerSourceManagement
«requirement»Power
«deriveReqt»«deriveReqt»
«deriveReqt»
«deriveReqt»
«requirement»Accelleration
«requirement»CargoCapacity
«requirement»FuelCapacity
«requirement»OffRoadCapability
«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
«block»PowerSubsystem
«refineReqt»
«satisfy»
«requirement»Power
«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»PowerSubsystem
«block»BrakePedal
«block»ChassisSubsytem
«block»BrakeSubsystem
«block»InteriorSubsystem
«block»LightingSubsystem
«block»BodySubsystem
«block»WheelHubAssembly
4
145
System Internal Block Diagram
ibd [block] HybridSUV
PowerSubsystem
ChassisSubsytem BrakeSubsystem
InteriorSubsystem
LightingSubsystem
BodySubsystem
146
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
147
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
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/
emg:ElectricalMotorGenerator
«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
«block»PowerSubsystem
«flowProperties» in fuelSupply:Fuel out fuelReturn:Fuel
«block»FuelTankAssembly
«flowProperties» » out fuelSupply:Fuel in fuelReturn:Fuel
«block»InternalCombustionEngine
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]
ice:InternalCombustionEngine
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»EconomyEquation
«constraint»RollingFriction
Equation
«constraint»AeroDragEquation
«constraint»StraightLine
VehicleDynamics
«testCase,Interaction»MaxAcceleration
«requirement»Acceleration
«verify»
«block»GlobalTime
«constraint»UnitCostEquation
«domain, block»HSUVStructure::
AutomotiveDomain
parameters
V1:RealV2:RealV3:Real
constraints
{pcap = ∑ Vi}
«constraint»CapacityEquation
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.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
155
Evaluating Measures of Effectiveness
par [constraintBlock] MeasuresOfEffectiveness [HSUV MOEs]
«objectiveFunction»
:MyObjectiveFunction{CE = ∑ Wi*Pi}
«moe»HSUValt1.CostEffectiveness
«moe»HSUValt1.FuelEconomy
«moe»HSUValt1.Zero60Time
«moe»HSUValt1.CargoCapacity
«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
«constraint»StraightLine
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)
Satisfies«requirement»Acceleration
«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
emg:ElectricalMotorGenerator
trsm:Transmission
allocatedFrom«activity»ConvertGasToPower
ice:InternalCombustionEngine
allocatedFrom«activity»ProportionPowerLoad
ecu:PowerControlUnitepc:IFS_EPC
fp:FS_ICE
allocatedFrom«activity»ControlElectricPower
epc:ElectricalPowerController
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
«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
177
Distill Water – Swim Lane DiagramAllocated Behavior
act [activity] DistillWater [Swimlane Diagram]
«streaming»a1:HeatWater
«streaming»a2:BoilWater
«streaming»a3:CondenseSteam
a4:DrainResidue
«continuous»hotDirty:H2O
[liquid]
«continuous»recovered:Heat
shutdown
«allocate»hx:HeatExchanger
«allocate»bx:Boiler
«allocate»dx:DrainValve
«continuous»coldDirty:H2O
[liquid]
«continuous»steam:H2O
[gas]
«continuous»pure:H2O
[liquid]
hiPress:Residue
loPress:Residue
«continuous»external:Heat
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»HeatExchanger
«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»HeatExchanger
«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
«value»massFlowRate
bx_steam_out:H2O
«value»massFlowRate
water_out:H2O
«value»massFlowRate
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
«continuous»hotDirty:H2O
[liquid]
«continuous»recovered:Heat
shutdown
«allocate»hx:HeatExchanger
«allocate»bx:Boiler
«allocate»dx:DrainValve
«continuous»coldDirty:H2O
[liquid]
«continuous»steam:H2O
[gas]
«continuous»pure:H2O
[liquid]
hiPress:Residue
loPress:Residue
«continuous»external:Heat
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
«value»massFlowRate
bx_water_in:H2O
«value»temp
«value»press
«value»massFlowRate
bx_steam_out:H2O
«value»temp
«value»press
«value»massFlowRate
water_out:H2O
«value»temp
«value»press
«value»massFlowRate
rate
sum{r1=r2+r3}
r1
r2
equivalent{r1=r2}
r1
r2
waste_water:H2O
«value»massFlowRate
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