Systems Modeling Language (SysML)

Systems Modeling Language (SysML)

INCOSE Evaluation: Systems Modeling Language (SysML) SysML Submission Team (SST) 13, 15, 20 December 2005 SST Chair: Sanford Friedenthal [email protected] Topics Introduction MDSD Actions Specification Updates Specification Highlights Sample Problems Language Architecture Compliance Approach Structural Constructs Behavioral Constructs

Cross-cutting Constructs Appendixes HSUV Example from Appendix B Distiller Example (response to D. Oliver example) Summary 2 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 * Available at http://syseng.omg.org/SysML.htm This highlights updates and selected features of the SST SysML Specification v0.98 (ad/2005-1101) A vote for adoption should occur at the next OMG 3 meeting the week of February 13, 2006 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 4 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 Both teams started from a common baseline Differences in process, issue prioritization and resolutions 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 5 SysML Submission Team (SST) Members Industry & Government

Vendors American Systems, BAE SYSTEMS, Boeing, EADS-Astrium, Eurostep, Lockheed Martin, NIST, oose.de, Raytheon, THALES 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 end-users and tool vendors 6 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 7 UML for SE RFP Requirements Summary Structure Behavior

e.g., parametric models, time property Refer to SST Requirements Reqts e.g., requirements hierarchy, traceability Traceability Matrix Verification in Appendix E. e.g., test cases, verification results Other e.g., function-based behavior, state-based behavior Properties e.g., system hierarchy, interconnection e.g., roles, views, relationship types, diagram types Optional e.g., trade studies, other behavior modeling paradigms SST submission provides robust solution that addresses most of the RFP requirements

8 SST Design Principles (Section 4.1) Requirements driven UML reuse 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 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

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 is intended to satisfy the requirements of the UML for SE RFP. 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. 9 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 10 Highlights of SST Approach (2 of 3) Usefulness of the language to practicing SEs 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, moes/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, 11 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 12 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 Review the following chapters in the SST Introduction 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 Language architecture and Compliance

Review the following subsections in each SST chapter Available on INCOSE Evaluators Site or request from SST Chair Provides overview of how language can be used Review the following appendixes as time permits Diagrams Non-Normative Extensions Model Interchange 13 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 14 Language Feature Summary (Refer to SST Highlights & Comparison Matrix 051201-revb) No. Language Feature Impact/PriorityRFP Evaluation Criteria 1 2 3 4 5 6 6a 7 8 9 10 11 12 13 14 15 16 17 18

19 20 21 Language Architecture Compliance Views & Viewpoints Value Types, Units & Dimensions Property Specific Types Instance Diagram Deep Nesting Item Flows Flow Port Features Flow Port Compatibility Rules Parametric Diagram Timing Diagram Allocation Types Allocate Activity Partition Requirement Callout Notation Refine Requirements Relationship Containment Symbol Diagram Conventions MOEs & Objective Function Requirements Classification BNF Notation Chapter Updates H H M H M M H

H M M H M M M H H L M H L M M 6.8.2, 6.8.8, 6.8.11 6.8.11 6.8.5 6.8.2, 6.8.3 6.8.1 6.8.4, 6.8.5 (RFP reqt 6.8.4) 6.8.1, 6.8.10 6.8.1, 6.8.4, 6.8.10 6.8.1, 6.8.2 6.8.1, 6.8.3 6.8.1 6.8.4, 6.8.12 (RFP reqt 6.5.2.4.1) 6.8.1, 6.8.2 6.8.1 6.8.1, 6.8.5 6.8.4 6.8.11 6.8.1, 6.8.2 6.8.3, 6.8.4 6.8.2

6.8.2, 6.8.9 6.8.2 Selected Language Features To Contrast Submissions 15 SysML SST Specification Outline Part III Behavioral Constructs Preface Part I of RFP Response Activities Interactions Part II of RFP Response State Machines Part III of RFP Response Use Cases Part I Introduction Part IV Crosscutting Constructs Scope Allocations Normative references Requirements Additional information

Profiles & Model Libraries Language Architecture Part V Appendices Compliance Diagrams Sample Problem Language Formalism Non-Normative Extensions Part II Structural Constructs Model Interchange (AP233 & Model Elements XMI) Blocks Requirements Traceability Ports and Flows Terms and Definitions Parametrics BNF Diagram Syntax Definitions 16 MDSD Recommendations & Response From INCOSE IW Jan 29-30, 2005 MDSD Recommendations & Response INCOSE 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 explanations RESPONSE: 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 metamodel RESPONSE: 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. 18 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) 19 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 test usability of multiple UI options via vendor prototypes RESPONSE: Made swim lanes explicit form of allocation (Fig 152, Section 15.3.3.3) 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 20 Specification Updates 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 22 Refer to Slide 15: No. 21 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 Understandability of SST Specification v0.98 23 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 24 Refer to Slide 15: No. 21

Specification Updates Technical Content Change Summary Redefined Language Architecture and Compliance approach Structure Behavior Refined/updated activity extensions* Included protocol state machines Cross cutting

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 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 (MOEs)* Refined approach for XMI and AP233 harmonization Updated requirements traceability matrix in Appendix E Identified terms for glossary * Work started prior to split on Aug 30, 2005 Added BNF Diagram Syntax Definition appendix

25 SST Specification Highlights Specification Highlights Language Feature # Specification Topic (From Slide 15) Language Architecture Compliance Approach Structural Constructs Behavioral Constructs Cross Cutting Constructs Appendixes 1 2 3-10, 18 11 12-16, 19 17-20 Refer to the Topic in the Following Slides for Details on the Referenced Language Features from Slide 15 27 Language Architecture Relationship Between SysML and

UML UML 2 UML4SysM L SysML UML UML reused by 2 Reuse SysML SysML extensions to UML (1, 2) UML not required by SysML (UML UML4SysML) SysML Profile 29 SysML Diagram Taxonomy SysML Diagram Behavior Diagram Use Case

Diagram Activity Diagram Requirement Diagram Timing Diagram Sequence Diagram Block Definition Diagram State Machine Diagram Structure Diagram Internal Block Diagram Instance Diagram Parametric Diagram Package Diagram Same as UML 2 Modified from UML 2 New diagram type

30 SysML v0.9 Language Architecture Issues Reuse of UML was imprecisely defined Profile structure was confusing Only partial list of required meta-classes UML2 Profiles chapter not clear on specification and application of UML subset 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 31 Language Architecture Approach Worked with UML2 RTF on profiles approach and used to define language architecture Apply reuse at package level vs metaclass level Create UML2 Subset using merge Reference this subset from the SysML profile Define fine-grained restrictions on features in constraints 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 32 Reuse of UML 2 UML4SysML CompleteActions InformationFlows merge StructuredClasses merge merge Time merge Fragments CompleteStructuredActivities merge merge metamodel UML4SysML merge merge Profiles

merge ExtraStructuredActivities merge reference merge ProtocolStateMachines CompleteActivities modelLibrary StandardProfileL1 import profile SysML PowerTypes SysML Profile Retains UML Integrity 33 SysML Profile Package profile SysML profile Blocks profile Activities modelLibrary Blocks

import profile ConstraintBlocks profile ModelElements modelLibrary ControlValues import profile Ports&Flows profile Allocations profile Requirements Modular & Cohesive Package Structure 34 Applying SysML Profile to a User Model pkg ModelingDomain [Establishing HSUV Model] profile SysML apply {strict} apply {strict} import

modelLibrary SI Unit Types HSUVModel 35 SysML Compliance 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 Didnt fit with UML tool-vendors plans for UML implementation Levels didnt 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 37 Compliance Approach Compliance Levels Introduce compliance levels into UML4SysML Further compliance levels for SysML Profile Each sub-profile is separate compliance level Asserts minimal compliance on UML4SysML level Reuse UML definitions of compliance

Strict subsets of UML compliance levels (L1, L2, L3) Abstract syntax Concrete syntax Compliance Statements No Partial (requires feature support statement) Yes Compliance approach allows vendor to clearly state compliance and users to assess compliance 38 Compliance Summary Example Compliance level Abstract Syntax UML4SysML Level 1 YES YES UML4SysML Level 2 PARTIAL YES

UML4SysML Level 3 NO NO Activities (without Probability) Concrete Syntax YES YES Activities (with Probability) NO NO Allocations PARTIAL PARTIAL Blocks YES YES Constraint Blocks YES

YES Model Elements (without Views) YES Model Elements (with Views) NO YES NO Ports & Flows (w/o Item Flows) YES YES Ports & Flows (with Item Flow) NO NO Requirements YES YES 39 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 pool Note (3): Dont show Blocks::StructuredCompartment notation 40 Structural Constructs

Structural Constructs Model Elements Blocks Ports and Flows Parametrics 42 Model Elements 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 44 Organizing the User Model pkg HSUVModel HSUVUseCases HSUVBehavior DeliverPower Behavior access HSUV Requirements HSUVStructure HSUVAnalysis requirement Performance HSUVInterfaces block Automotive Domain access access HSUVViews access

view OperationalView viewpoint Operational Viewpoint view Performance View viewpoint Performance Viewpoint Package Diagram Used to Organize the Model 45 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 46 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) 47 SST View/Viewpoint Viewpoint as a stereotyped class Functional Viewpoint

viewpoint stakeholders="..." purpose="..." construction rules="..." view Security View Relationship between Viewpoints viewpoint Security Viewpoint View realizes a viewpoint 48 Performance View Example pkg [package] HSUVViews [Performance View] view PerformanceView Performance Viewpoint Drive Car Driver moe HSUValt1.Fuel Economy moe HSUValt1.Quar terMileTime <> Performance id = 2 Text = The Hybrid SUV shall have the braking, acceleration, and off-road

capability of a typical SUV, but have dramatically better fuel economy. viewpoint Functional Viewpoint constraint UnitCostEquation moe HSUValt1.Zero 60Time constraint CapacityEquation moe HSUValt1.Car goCapacity constraint EconomyEquation moe HSUValt1.Cos tEffectiveness viewpoint stakeholders="customer" purpose="Highlight the performance of the system." construction rules="show performance requirements, test cases, MOE, constraint models, etc.; includes functional viewpoint"

testCase EPAFuel EconomyTest 49 Rationale requirement Power deriveReqt requirement PowerSourceManagement rationale Power delivery must happen by coordinated control of gas and electric motors. reference= Hybrid Design Guidance Rationale can link to a trade study or analysis report Rationale can be attached to any Model Element or Relationship to Capture decisions 50 Blocks 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 Structural Foundation for SST Submission 52 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 53 Power Subsystem Breakdown bdd [block] HSUV [PowerSubsystem Breakdown] block WheelHubAssembly block PowerSubsystem lfw block BrakePedal block accelerator block BatteryPack block FuelTankAssembly block PowerControlUnit block InternalCombustionEngine block ElectricalPowerController

block ElectricMotor Generator rfw block FrontWheel block Differential 4 block FuelPump block FuelInjector block Transmission Block Definition Diagram Used to Specify System Hierarchy and Classification 54 Power Subsystem IBD Part ibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator] Enclosing Block epc:ElectricalPower <>

Controller ctrl bp:BatteryPack <> i2:Electric Current i1:Electric Current emg:ElectricMotor Generator I_IEPCData I_IEPCCmd I_TRSMCmd acl:accelerator ctrl trsm:Transmission c3 <> spline rfw:ChassisSubsytem .FrontWheel I_TRSMData I_IEPCData

I_EPCCmd epc trsm ecu:PowerControlUnit ice I_ICECmds torquein:Torque c2 rightHalfShaft I_TRSMData g1:Torque torqueOut:Torque I_TRSMCmd <> ice:InternalCombustionEngine I_ICEData I_ICEData ctrl c1 4 fi:FuelInjector bp:BrakeSubsystem .BrakePedal

Connector I_ICECmds Port:FuelTankFitting <> fuelSupply:Fuel leftHalfShaft fdist Port:ICEFuelFitting ft:FuelTankAssy fp:FuelPump dif:Differential lfw:ChassisSubsytem .FrontWheel fuelDelivery fuelReturn:Fuel Internal Block Diagram Used to Specify Interconnection Among Parts in Context of Enclosing Block 55 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) Value property (typed by value type) Usage of a block in the context of the enclosing block Example - right-front:wheel 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 56 Simple Example of Deep Nesting Connecting a Tire to a Road No need for modeler to specify intermediateenv : Environment

connections ibd block Automotive Domain vehicle : HSUV 2 front : Tire road : Road 2 rear : Tire Deep Nesting Provides Intuitive Modeling of Physical Systems and does not Impose Process 57 Design Values Example bdd Car Design Car 1 2 1 front 2 back Wheel tyrePressure : psi SUV ibd SUV part back : [Wheel]

2 Properties tyrePressure : psi {distribution=Uniform (min=27,max=29)} part front : [Wheel] Properties tyrePressure : psi {distribution=Uniform (min=25,max=27)} 2 [] Indicates partspecific block Supports different values & distributions for each part Design Values Ease Ability to Specify Different Values/Distributions on Parts in Same Context 58 Units and Dimensions ins [package] SI Units metaclass DataType block second:Unit value dimension InstanceSpecification

0..1 stereotype ValueType * block time:Dimension { instance of Dimension from Units model library} bdd [package] SI Unit Types * unit InstanceSpecification 0..1 { instance of Unit from Units model library} s value Real value unit=second dimension=time modelLibrary Blocks block

Unit value Real dimension 0..* 0..1 block Dimension bdd [package] Objects Obj value Complex realPart: Real imaginaryPart: Real values t1:s t2:s Units Tied Explicitly to Dimensions 59 Units Model Library pkg SEToolkit import modelLibrary SI Units

modelLibrary Units z import modelLibrary SI Unit Types Volume Density Length valueType dimension = VolumeDim valueType dimension = DensityDim valueType dimension = LengthDim modelLibrary Physical block PhysicalObject import SIVolume SIDensity

valueType unit= M3 valueType unit = KgPerM3 SILength valueType unit = M density: SIDensity volume: SIVolume supplier: String modelNumber: String serialNumber: String lotNumber: String Model Library Can be Expanded to Address Domain Needs 60 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) . 61 Test Result Instance ins SUV_EPA_Fuel_Economy_Test_Result Satisfies requirmentEmissions TestVehicle1/hsuv:HSUV b12345/ b:BodySubsystem c34567/ c:Chassis Subsytem bk45678/ bk:Brake Subsystem i23456/ int:Interior Subsystem lt56789/ lt:Lighting bSubsystem

Verifies requirmentEmissions testCase testRun060401/ epaTest:EPAFuel EconomyTest p67890/p:PowerSubsystem eid78901/ ice:InternalComb ustionEngine sn89012/ t:transmission sn90123/ emg:ElectricalMot orGenerator VIN = G12345 Example Use of Instance Diagram for Specifying a Unique System Test Configuration and Values 62 Ports and Flows Issues 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 64 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 Support Different Interface Concepts 65 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 Atomic FlowPorts FlowProperty has a direction attribute: in, out, inOut FlowProperties can be typed by ValueTypes, Block, and Signals isConjugate promotes reuse of flowSpecifications

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

Paradigm to Represent What Flows in a Particular Context 67 Power Subsystem IBD ibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator] epc:ElectricalPower <> Controller ctrl bp:BatteryPack Item flow <> i2:Electric Current i1:Electric Current emg:ElectricMotor Generator Flow port I_IEPCData I_IEPCCmd I_TRSMCmd acl:accelerator ctrl trsm:Transmission c3

<> spline rfw:ChassisSubsytem .FrontWheel I_TRSMData I_IEPCData I_EPCCmd epc trsm ecu:PowerControlUnit ice I_ICECmds torquein:Torque c2 rightHalfShaft I_TRSMData g1:Torque torqueOut:Torque I_TRSMCmd <> ice:InternalCombustionEngine I_ICEData

I_ICEData ctrl c1 4 fi:FuelInjector bp:BrakeSubsystem .BrakePedal Connector I_ICECmds Port:ICEFuelFitting Port:FuelTankFitting <> fuelSupply:Fuel leftHalfShaft fdist Client server port ft:FuelTankAssy fp:FuelPump dif:Differential lfw:ChassisSubsytem .FrontWheel

fuelDelivery fuelReturn:Fuel Specifying Interfaces on an IBD in Terms of Connectors, Ports and Flows 68 Parametrics & MOEs/Objective Functions Parametrics Used to express constraints (equations) between value properties Constraint block defined as a simple extension of block 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) 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 Parametrics Scalability Integration with Engr MOEs and objective functions&integrated with Parametrics to support trade studies and engineering analysis Analysis

Validated by Georgia Tech 70 Defining Vehicle Dynamics bdd [package] HSUVAnalysis [Definition of Dynamics] constraint StraightLine VehicleDynamics parameters whlpowr:Real Cd:Real Cf:Real tw:Real acc:Real vel:Real incline:Real constraint PowerEquation Constraints {tp(hp) = whlpowr - (Cd*v) - (Cf*tw*v)}} parameters whlpowr:Real Cd:Real Cf:Real tw:Real tp:Real v:Real i:Real constraint PositionEquation Constraints

{x(n+1)=x(n)+dx(dt)=x(n)+v*dt} {x(n+1)=x(n)+v*5280/3600*dt} constraint VelocityEquation Constraints {v(n+1)=v(n)+dv = v(n) + a*dt} {v(n+1 =v(n)+a*32*3600/5280*dt} parameters dt:Real v:Real x:Real parameters dt:Real v:Real a:Real constraint AccelerationEquation Constraints {a(g) = F/m = P*t/m = (550/ 32)*tp(hp)*delta-t*twi} parameters tw:Real dt:Real tp:Real a:Real Defining Reusable Equations for Parametrics 71 Evaluating Vehicle Dynamics par [constraintBlock] StraightLineVehicleDynamics

tw Cf Cd whlpwr whlpwr incline i Cd Cf tw tw tp PowerEquation tp Accelleration Equation dt acc a v a dt VelocityEquation

value globalTime.delta-t vel v v PostionEquation dt x value HSUV.position Using the Equations in a Parametric Diagram to Constrain the Value Properties 72 Evaluating Measures of Effectiveness par [constraintBlock] MeasuresOfEffectiveness [HSUV MOEs] :EconomyEquation f: Instance of constraint block is identical for each alternative moe HSUValt1.FuelEconomy p1:

q: :MaxAcceleration Analysis moe HSUValt1.QuarterMileTime vc: uc: :UnitCostEquation p3: objectiveFunction :MyObjectiveFunction {CE = Wi*Pi} CE: moe HSUValt1.CostEffectiveness z: moe HSUValt1.Zero60Time :CapacityEquation p2: p4: p5:

moe HSUValt1.CargoCapacity moe HSUValt1.UnitCost MOEs and objective function provide flexible support for trade study analysis that is fully integrated with parametrics 73 Constraint Blocks - Comparison of Block-based vs. Collaboration-based approach Concrete Syntax Abstract Syntax More notational changes to default collaboration notation required to support chosen Constraint Block notation 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 properties Blocks Based Approach Retains Structural Integrity and Simplifies Language 74 Behavioral Constructs Behavioral Constructs Activities Interactions State Machines Use Cases

76 Activities Activities Activities used to specify flow of I/O and control Input/Output represented by object node/pins that are typed by blocks Control flow represent enabling of activity External I/O called a parameter 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 78 SysML EFFBD Profile Refer to Appendix C.1 for Details & Execution Rules effbd act {cc#1} Item 1 2.2 Multi-exit Function 2.4 Function in Multi-exit Construct optional {cc#2} [ before third time ] Item 2 External Input 2.1 Serial Function optional

2.5 Function in an Iterate External Output [ after third time ] Item 3 optional 2.6 Output Function 2.3 Function in Concurrency optional Item 4 Aligning SysML with Proven Systems Engineering Techniques 79 Distiller Example Provided by D. Oliver Dirty water @ 20 deg C Heat Dirty water To 100 deg C Dirty water @ 100 deg C

Steam Boil Dirty water Residue Heat to Dirty water Heat to Boil water and Energy to condense Pure water Condense steam and Drain Residue Disposed residue 80 Distill Water Activity Diagram (Initial) effbd act [activity] DistillWater [Simple Starting Point) coldDirty:H2O

[liquid] Note: these are the same thing! steam:H2O [gas] hotDirty:H2O [liquid] pure:H2O [liquid] recovered:Heat a3:CondenseSteam a1:HeatWater a2:BoilWater a4:DrainResidue recovered:Heat external:Heat hiPress:Residue loPress:Residue Representing Distiller Example in SysML Using EFFBD Profile 81 Distill Water Activity Diagram (Continuous Flow Modeling)

act [activity] DistillWater [Parallell Continuous Activities) loPress:Residue continuous coldDirty:H2O [liquid] continuous steam:H2O [gas] hiPress:Residue continuous recovered:Heat a4:DrainResidue a1:HeatWater a3:CondenseSteam continuous hotDirty:H2O [liquid] a2:BoilWater continuous external:Heat Representing Distiller Example in SysML Using Continuous Flow Modeling continuous pure:H2O [liquid]

82 Interactions 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 84 Black Box Interaction (Drive) sd DriveBlackBox driver:Driver ref hybridSUV:HybridSUV StartVehicleBlackBox par alt controlSpeed ref [self.oclInState(idle)] Idle [self.oclInState(accelerating/cruising)] ref Accelerate/Cruise [self.oclInState(braking)] ref ref ref Brake Steer

Park/ShutdownVehicle UML 2 Sequence Diagram More Scalable by Supporting Control Logic and Reference Sequences 85 Black Box Sequence (StartVehicle) sd StartVehicleBlackBox hybridSUV:HybridSUV ref StartVehicleWhiteBox driver:Driver turnIgnitionToStart 1: StartVehicle() References Lifeline Decom For White Box Interaction Simple Black Box Interaction 86 White Box Sequence (StartVehicle) sd StartVehicleWhiteBox ecu:PowerControlUnit epc:ElectricalPowerController 1: StartVehicle 1.1: Enable

1.2:ready Decomposition of Black Box Into White Box Interaction 87 Trial Result of Vehicle Dynamics tim MaxAcceleration [100 Wheel Horsepower] Satisfies requirementAcceleration 0.5 0.45 Accelleration (g) 0.4 0.35 diagramDescription version=0.1" description=Constant 100 wheel horsepower, 4000 lb vehicle weight, simple drag" reference=Equations of Motion completeness=assumes perfect tire traction 0.3 0.25 0.2 0.15

0.1 0.05 0 0 5 10 15 20 Time (sec) 140 Velocity (mph) 120 100 80 60 40 20 0 0 5 10 15 20 15

20 Lifeline are value properties Time (sec) 1800 1600 Distance (ft) 1400 1200 1000 800 600 400 200 0 0 5 10 Time (sec) Typical Example of a Timing Diagram 88 State Machines 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 90 Operational States (Drive) stm HSUVOperationalStates Off start

keyOff shutOff Refines requirement PowerSource Management Nominal states only Operate Idle stopped accelerate releaseBrake Accellerating/ Cruising Braking engageBrake Abnomal state (accelerator sticks) - abort symbol 91 Use Cases 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 93 Top Level Use Cases uc HSUVUseCases [TopLevelUseCases] HybridSUV Operate the vehicle Driver Insure the vehicle InsuranceCompany Registered Owner Register the vehicle Department Of Motor Vehicles

Maintain the vehicle Maintainer 94 Operational Use Cases uc HSUVUseCases [Operational Use Cases] HybridSUV Start the vehicle extend Drive the vehicle Driver include Accelerate include include Park include Steer Brake 95

Cross-cutting Constructs Cross-cutting Constructs Allocations Requirements Profiles & Model Libraries 97 Allocations 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 99 Different Allocation Representations (Tabular Representation Not Shown) to Element Name1 Element Name2 allocate :ElementName allocate ActivityName from to Element Name3 Allocate Relationship Explicit Allocation of Activity to Swim Lane block

BlockName block BlockName PartName allocatedFrom elementTypeElementName PartName Compartment Notation Callout Notation allocatedFrom elementTypeElementName 100 Requirements 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)

Stereotype of class (abstract) without instances Requirements containment used to specify requirements hierarchy as a collection of requirements (e.g., a specification) Able to specify constraints on what design elements can satisfy the requirement (refer to Appendix C.2) 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, .. 102 Dependencies Used to specify relationships among requirements (other uses as well) Different concept for SEs 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 SEs 103 Example of Derive/Satisfy Requirement Dependencies requirement OffRoadCapability requirement Accelleration requirement CargoCapacity Supplier deriveReqt

deriveReqt deriveReqt Client requirement Power Supplier satisfy Client block PowerSubsystem Arrow Direction Opposite Typical Requirements Flow-Down 104 Requirements & Allocations Alignment V0.9 Issue Inconsistent concrete syntax for cross-cutting relationships Limitations in displaying requirement relationships

Allocations used compartments/callouts, requirements did not Requirements needed to be shown on same diagram as target of relationship > cluttered diagrams Requirements couldnt 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 105 Representing Requirements and Allocation Relationships act ProvidePower [with Swimlane Allocation] allocate ElectricalPowerContr oller allocate ElectricalMotorGener ator a3:Control ElectricPower

a4:Provide ElectricPower continuous eThrottle continuous driveCurrent continuous elecDrivePower ibd [block] PowerSubsystem [Power Functional Allocation] allocatedFrom objectNodedriveCurrent epc:ElectricalPower Controller allocatedFrom activityControl ElectricPower <> emg:ElectricalMotor Generator <> i2:Electric Current i1:Electric Current

allocatedFrom activityConvert ElectricToPower Satisfies requirementAcceleration allocatedTo itemFlowi1:ElectricCurrent Requirements callout notation Allocations callout notation Consistent and Compact Crosscutting Notations 106 Profiles & Model Libraries 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 108 Stereotypes metaclass NamedElement configurationItem Engine stereotype ConfigurationItem author=John Doe version=1.2" lastChanged=Dec12, 2005 author: String version: String lastChanged: Date Defining the Stereotype Applying the Stereotype 109 Appendixes Appendixes

Diagrams Sample Problem Non-Normative Extensions Model Interchange Requirements Traceability Terms and Definitions BNF Diagram Syntax Definitions 111 Appendix A Diagrams Diagram Appendix A Provides general guidelines for the use of diagrams Diagram headings Diagram descriptions

Capturing information about diagrams Diagram usages Naming of diagrams Specifying unique diagram kinds Other general guidelines (e.g. tabular representations, use of rake symbol, ..) 113 Guidelines Example A Diagram Description (refer to App A) Diagram Heading Names (refer to App A) bdd [package] DistillerStructure [Structural Breakdown] block Distiller hx block HeatExchanger bx block

Boiler diagramDescription version=0.1" description=initial structural breakdown of distiller system" reference=TBD completeness=ItemFlows and Connectors elided dv block DrainValve 114 Appendix B Sample Problem Sample Problem Appendix B Highlights selected features of SysML using a Hybrid SUV example Refer to sample problem in later slides 116 Appendix C Non-Normative Extensions

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 118 Appendix D Model Interchange 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 INCOSEs vision for model driven systems engineering 120 Appendix E Requirements Traceability Matrix 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 122

Appendix F Terms and Definitions 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 124 Appendix G BNF Diagram Syntax Definitions 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 126 HSUV Sample Problem SST Appendix B 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 128 Sample Problem Coverage Organizing the model Requirements Behavior Structure Allocating behavior to structure Analyzing performance & MOEs 129

Setting up the User Model pkg ModelingDomain [Establishing HSUV Model] profile SysML apply {strict} apply {strict} import modelLibrary SI Unit Types HSUVModel 130 Organizing the User Model pkg HSUVModel HSUVUseCases HSUVBehavior DeliverPower Behavior access HSUV Requirements HSUVStructure HSUVAnalysis requirement

Performance HSUVInterfaces block Automotive Domain access access HSUVViews access view OperationalView viewpoint Operational Viewpoint view Performance View viewpoint Performance Viewpoint 131 Setting the Context Context Diagram ibd [block] AutomotiveDomain

external driver:Driver system hybridSUV:HybridSUV external :Maintainer external :Environment external :Weather external :Passenger external :ExternalObject external :VehicleCargo external :Road diagramDescription version=0.1" description=Initial concept to identify top level domain entities" reference=Ops Concept Description completeness=partial. Does not include gas pump and other external interfaces. 132 Top Level Use Cases uc HSUVUseCases [TopLevelUseCases]

HybridSUV Operate the vehicle Driver Insure the vehicle InsuranceCompany Registered Owner Register the vehicle Department Of Motor Vehicles Maintain the vehicle Maintainer 133 Operational Use Cases uc HSUVUseCases [Operational Use Cases] HybridSUV Start the vehicle extend Drive the vehicle Driver

include Accelerate include include Park include Steer Brake 134 Black Box Interaction (Drive) sd DriveBlackBox driver:Driver ref hybridSUV:HybridSUV StartVehicleBlackBox par alt controlSpeed ref [self.oclInState(idle)] Idle [self.oclInState(accelerating/cruising)]

ref Accelerate/Cruise [self.oclInState(braking)] ref ref ref Brake Steer Park/ShutdownVehicle 135 Operational States (Drive) stm HSUVOperationalStates Off start keyOff shutOff Refines requirement PowerSource Management Nominal states only

Operate Idle stopped accelerate releaseBrake Accellerating/ Cruising Braking engageBrake Abnomal state (accelerator sticks) - abort symbol 136 Black Box Sequence (StartVehicle) sd StartVehicleBlackBox hybridSUV:HybridSUV ref StartVehicleWhiteBox driver:Driver turnIgnitionToStart 1: StartVehicle() 137 White Box Sequence

(StartVehicle) sd StartVehicleWhiteBox ecu:PowerControlUnit epc:ElectricalPowerController 1: StartVehicle 1.1: Enable 1.2:ready 138 Requirements Breakdown req [package] HSUVRequirements [HSUV Specification] HSUVSpecification requirement Eco-Friendliness requirement Braking requirement Performance requirement FuelEconomy requirement Emissions requirement

Ergonomics requirement OffRoadCapability requirement Accelleration requirement Qualification requirement SafetyTest requirement Capacity requirement CargoCapacity requirement PassengerCapacity requirement FuelCapacity Id = R1.2.1 text = The vehicle shall meet Ultra-Low Emissions Vehicle standards. 139 Requirements Derivation req [package] HSUVRequirements [Requirement Derivation] requirement

Braking requirement FuelCapacity requirement FuelEconomy deriveReqt deriveReqt requirement OffRoadCapability requirement CargoCapacity deriveReqt deriveReqt deriveReqt requirement RegenerativeBraking requirement Accelleration deriveReqt deriveReqt deriveReqt requirement Range requirement Power

RefinedBy HSUVStructure::HSUV. HSUVOperationalStates deriveReqt requirement PowerSourceManagement rationale Power delivery must happen by coordinated control of gas and electric motors. reference= Hybrid Design Guidance 140 Reqts Refinement/Verification req [package] HSUVRequirements [Acceleration Requirement Refinement and Verification] requirement Acceleration refineReqt deriveReqt verify HSUVUseCases: :Accelerate requirement Power testCase Max Acceleration satisfy

block PowerSubsystem 141 Requirements Tables & Trees table [requirement] Capacity [Decomposition of Capacity Requirement] id name 4 4.1 4.2 4.3 text The Hybrid SUV shall carry 5 adult passengers, along with Capacity sufficient luggage and fuel for a typical weekend campout. The Hybrid SUV shall carry sufficient luggage for 5 people CargoCapacity for a typical weekend campout. The Hybrid SUV shall carry sufficient fuel for a typical FuelCapacity weekend campout. PassengerCapacity The Hybrid SUV shall carry 5 adult passengers. table [requirement] Performance [Decomposition of Performance Requirement] id name

2 Performance 2.1 Braking 2.2 FuelEconomy 2.3 OffRoadCapability 2.4 Acceleration text The Hybrid SUV shall have the braking, acceleration, and offroad capability of a typical SUV, but have dramatically better fuel economy. The Hybrid SUV shall have the braking capability of a typical SUV. The Hybrid SUV shall have dramatically better fuel economy than a typical SUV. The Hybrid SUV shall have the off-road capability of a typical SUV. The Hybrid SUV shall have the acceleration of a typical SUV. table [requirement] Performance [Tree of Performance Requirements] id 2.1 2.2 2.2 4.2 2.3 2.4 4.1 name Braking FuelEconomy FuelEconomy FuelCapacity OffRoadCapability Acceleration

CargoCapacity relation deriveReqt deriveReqt deriveReqt deriveReqt deriveReqt deriveReqt deriveReqt id d.1 d.1 d.2 d.2 d.4 d.4 d.4 name RegenerativeBraking RegenerativeBraking Range Range Power Power Power relation id deriveReqt d.2 deriveReqt d.2 deriveReqt d.2

name PowerSourceManagement PowerSourceManagement PowerSourceManagement 142 Context/Enterprise Breakdown bdd [package] HSUVStructure [Automotive Domain Breakdown] domain, block AutomotiveDomain interactions StartVehicleBlackBox StartVehicleWhiteBox driver hybridSUV system, block HybridSUV external Driver external Maintainer external VehicleCargo external Environment external

Passenger external Weather external ExternalObject external Road 143 System Breakdown bdd [block] AutomotiveDomain [HybridSUV Breakdown] system, block HybridSUV block PowerSubsystem block BrakeSubsystem block BodySubsystem block InteriorSubsystem block LightingSubsystem block ChassisSubsytem

4 block BrakePedal block WheelHubAssembly 144 System Internal Block Diagram ibd [block] HybridSUV ChassisSubsytem BodySubsystem InteriorSubsystem BrakeSubsystem LightingSubsystem PowerSubsystem 145 Power Subsystem Breakdown bdd [block] HSUV [PowerSubsystem Breakdown] block WheelHubAssembly block PowerSubsystem

lfw block BrakePedal block accelerator block BatteryPack block FuelTankAssembly block PowerControlUnit block InternalCombustionEngine block ElectricalPowerController block ElectricMotor Generator rfw block FrontWheel block Differential 4

block FuelPump block FuelInjector block Transmission 146 Power Subsystem IBD ibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator] epc:ElectricalPower <> Controller ctrl bp:BatteryPack <> i2:Electric Current i1:Electric Current emg:ElectricMotor Generator I_IEPCData I_IEPCCmd I_TRSMCmd acl:accelerator

ctrl trsm:Transmission c3 <> spline rfw:ChassisSubsytem .FrontWheel I_TRSMData I_IEPCData I_EPCCmd epc trsm ecu:PowerControlUnit ice I_ICECmds torquein:Torque c2 rightHalfShaft I_TRSMData g1:Torque torqueOut:Torque I_TRSMCmd <>

ice:InternalCombustionEngine I_ICEData I_ICEData ctrl c1 4 fi:FuelInjector I_ICECmds bp:BrakeSubsystem .BrakePedal Port:FuelTankFitting <> fuelSupply:Fuel leftHalfShaft fdist Port:ICEFuelFitting ft:FuelTankAssy fp:FuelPump dif:Differential lfw:ChassisSubsytem .FrontWheel

fuelDelivery fuelReturn:Fuel 147 Test Result Instance ins SUV_EPA_Fuel_Economy_Test_Result Satisfies requirmentEmissions TestVehicle1/hsuv:HSUV b12345/ b:BodySubsystem c34567/ c:Chassis Subsytem bk45678/ bk:Brake Subsystem i23456/ int:Interior Subsystem lt56789/ lt:Lighting bSubsystem Verifies requirmentEmissions testCase

testRun060401/ epaTest:EPAFuel EconomyTest p67890/p:PowerSubsystem eid78901/ ice:InternalComb ustionEngine sn89012/ t:transmission sn90123/ emg:ElectricalMot orGenerator VIN = G12345 148 Power Subsystem Interface Defn bdd [block] PowerSubsystem [ICE Interface Definitions] interface I_ICEData getRPM():integer getTemperature():float isKnockSensor():boolean interface I_ICECmds setThrottle(throttlePosition:float):void setMixture(mixture:float):void

149 Fuel System Definition bdd [block] HSUV [PowerSubsystem Fuel Flow Definition] block Fuel temperature:Real pressure:Real block PowerSubsystem block FuelTankAssembly flowProperties in fuelSupply:Fuel out fuelReturn:Fuel block InternalCombustionEngine ICEFuelFitting:FuelFlow <> <> FuelTankFitting:FuelFlow flowProperties out fuelSupply:Fuel in fuelReturn:Fuel flowSpecification FuelFlow flowProperties out fuelSupply:Fuel

in fuelReturn:Fuel 150 Fuel Flow Parametrics par [Block]PowerSubsystem ice.fi.FuelDemand:Rea l ice.ft.FuelFlowRate:Real injectorDemand:Real fuelflow:FuelFlow flowrate:Real constraints {flowrate=press/(4*injectorDemand)} ice.fr.fuel.FuelPressure::Real press:Real 151 Fuel Subsystem Design ibd [block] PowerSubsystem [Fuel Distribution Detail] ice:InternalCombustionEngine fi1:FuelInjector fi2:FuelInjector fi3:FuelInjector

allocatedFrom connectorfdist fi4:FuelInjector allocatedFrom connectorFuelDelivery fra:FuelRail 4 fre:FuelRegulator ft:FuelTankAssy fuelFitting:Fuel p1:Fuel fuelSupplyLine fp:FuelPump fuelSupply:Fuel p2:Fuel fuelReturnLine fuelReturn:Fuel 152 Overall Analysis Context bdd [package] HSUVAnalysis [Analysis Context] constraint CapacityEquation constraint UnitCostEquation

constraint EconomyEquation constraint StraightLine VehicleDynamics block GlobalTime constraints {pcap = Vi} parameters V1:Real V2:Real V3:Real testCase,Interaction MaxAcceleration verify domain, block HSUVStructure:: AutomotiveDomain constraint RollingFriction Equation constraint AeroDragEquation requirement Acceleration

153 Performance View Definition pkg [package] HSUVViews [Performance View] view PerformanceView Performance Viewpoint Drive Car Driver moe HSUValt1.Fuel Economy moe HSUValt1.Quar terMileTime <> Performance id = 2 Text = The Hybrid SUV shall have the braking, acceleration, and off-road capability of a typical SUV, but have dramatically better fuel economy. viewpoint Functional Viewpoint constraint UnitCostEquation moe

HSUValt1.Zero 60Time constraint CapacityEquation moe HSUValt1.Car goCapacity constraint EconomyEquation moe HSUValt1.Cos tEffectiveness viewpoint stakeholders="customer" purpose="Highlight the performance of the system." construction rules="show performance requirements, test cases, MOE, constraint models, etc.; includes functional viewpoint" testCase EPAFuel EconomyTest 154 Evaluating Measures of Effectiveness par [constraintBlock] MeasuresOfEffectiveness [HSUV MOEs] :EconomyEquation

f: Instance of constraint block is identical for each alternative moe HSUValt1.FuelEconomy p1: q: :MaxAcceleration Analysis moe HSUValt1.QuarterMileTime vc: uc: :UnitCostEquation p3: objectiveFunction :MyObjectiveFunction {CE = Wi*Pi} CE: moe HSUValt1.CostEffectiveness z: moe

HSUValt1.Zero60Time :CapacityEquation p2: p4: p5: moe HSUValt1.CargoCapacity moe HSUValt1.UnitCost 155 Evaluating Fuel Economy par [constraintBlock] EconomyEquation value HSUV.PayloadCapacity incline RegenBrake EfficiencyEquation AeroDragEquation volume Cd pcap acc ebpwr

Cd volume acc incline RoadElevProfile PayloadEquation incline psgrWt StraightLine VehicleDynamics cgoWt tw cgoWt Cf value InternalCombustionEngine. ICEEfficiency vel whlpwr ebpwr n_ice acc vel Fuel

whlpwr EfficiencyEquation n_eg n_em mpg mpg tw TotalWeight tw psgrWt vdw fw value HSUV.VehicleDryWeight Cf RollingFriction Equation value ElectricMotorGenerator. GeneratorEfficiency value ElectricMotorGenerator. MotorEfficiency value FuelTank.FuelWeight

156 Evaluating Vehicle Dynamics par [constraintBlock] StraightLineVehicleDynamics tw Cf Cd whlpwr whlpwr incline i Cd Cf tw tw tp PowerEquation tp Accelleration Equation dt acc a v a

dt VelocityEquation value globalTime.delta-t vel v v dt PostionEquation x value HSUV.position 157 Defining Vehicle Dynamics bdd [package] HSUVAnalysis [Definition of Dynamics] constraint StraightLine VehicleDynamics parameters whlpowr:Real Cd:Real Cf:Real tw:Real acc:Real vel:Real incline:Real constraint PowerEquation

Constraints {tp(hp) = whlpowr - (Cd*v) - (Cf*tw*v)}} parameters whlpowr:Real Cd:Real Cf:Real tw:Real tp:Real v:Real i:Real constraint PositionEquation Constraints {x(n+1)=x(n)+dx(dt)=x(n)+v*dt} {x(n+1)=x(n)+v*5280/3600*dt} constraint VelocityEquation Constraints {v(n+1)=v(n)+dv = v(n) + a*dt} {v(n+1 =v(n)+a*32*3600/5280*dt} parameters dt:Real v:Real x:Real parameters dt:Real v:Real a:Real constraint AccelerationEquation

Constraints {a(g) = F/m = P*t/m = (550/ 32)*tp(hp)*delta-t*twi} parameters tw:Real dt:Real tp:Real a:Real 158 Trial Result of Vehicle Dynamics tim MaxAcceleration [100 Wheel Horsepower] Satisfies requirementAcceleration 0.5 0.45 Accelleration (g) 0.4 0.35 diagramDescription version=0.1" description=Constant 100 wheel horsepower, 4000 lb vehicle weight, simple drag" reference=Equations of Motion completeness=assumes perfect tire traction

0.3 0.25 0.2 0.15 0.1 0.05 0 0 5 10 15 20 15 20 15 20 Time (sec) 140 Velocity (mph) 120 100 80 60 40 20

0 0 5 10 Time (sec) 1800 1600 Distance (ft) 1400 1200 1000 800 600 400 200 0 0 5 10 Time (sec) 159 ProvidePower Functional Decomp bdd [activity] Accelerate [Activity and Object Flow Breakdown] activity MeasureVehicle

Conditions activity ProvidePower a1 a4 activity ProvideElectric Power activity ProportionPower activity MeasureVehicle Velocity activity MeasureBattery Condition a2 drivePower activity ProvideGasPower block Power a3 activity ControlElectricPower

elecDrivePower gasDrivePower block GasPower block ElecPower 160 ProvidePower Behavior & Allocation (UserDefined)Swimlane Diagram act ProvidePower [with Swimlane Allocation] allocate PowerControlUnit continuous speed allocate InternalCombustionEngi ne allocate ElectricalPowerContr oller allocate ElectricalMotorGener ator continuous gasDrivePower

a2:ProvideGas Power continuous vehCond continuous gThrottle a3:Control ElectricPower continuous drivePower a4:Provide ElectricPower continuous battCond continuous elecDrivePower continuous eThrottle continuous driveCurrent a1:Proportion Power continuous accelPosition transModeCmd keyOff

allocatedTo itemFlowi1:ElectricCurrent 161 Multiple Allocations shown on IBD ibd [block] PowerSubsystem [Power Functional Allocation] allocatedFrom objectNodedriveCurrent diagramDescription version=0.1" description=allocation of behavior and connectors to elements of power subsystem" reference=null completeness=partial. Power subsystem elements that have no allocation yet have been elided epc:ElectricalPower Controller emg:ElectricalMotor Generator <> <> i2:Electric Current

allocatedFrom activityControl ElectricPower i1:Electric Current allocatedFrom activityConvert ElectricToPower fp:FS_EPC can:CAN_Bus ecu:PowerControlUnit allocatedFrom activityProportion PowerLoad <> epc:IFS_EPC <> <> ice:IFS_ICE etrsm:IFS_TRSM fp:FS_TRSM <>

trsm:Transmission allocatedFrom connectorc1 connectorc2 connectorc3 fp:FS_ICE <> ice:InternalCombustionEngine allocatedFrom activityConvertGasToPower 162 Allocation Table w/Allocation Type table [activity] ProvidePower [Allocation Tree for Provide Power Activities] type activity activity activity activity objectNode name a1:ProportionPower a2:ProvideGasPower a3:ControlElectricPower a4:ProvideElectricPower driveCurrent

end from from from from from relation allocateBehavior allocateBehavior allocateBehavior allocateBehavior allocateFlow end to to to to to type block block block block itemFlow name PowerControlUnit InternalCombustionEngine ElectricalPowerController ElectricalMotorGenerator i1:ElectricCurrent 163

Distiller Example David Oliver 12/7/05 An example to raise questions Dave Oliver Preface System 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. 165 Distiller Example (as provided by D. Oliver) Dirty water @ 20 deg C Heat Dirty water To 100 deg C Dirty water @ 100 deg C

Steam Boil Dirty water Residue Heat to Dirty water Heat to Boil water and Energy to condense Pure water Condense steam and Drain Residue Disposed residue The ovals in the figure are I/O in AP233, items in CORE and I believe object nodes in the submissions. 166 Questions 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? 167 Questions (cont.) 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 168 support? Questions (cont.) 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? 169 Response to Daves Example

Distiller System Distiller System Package Overview pkg [model] Distiller [Model Overview] DistillerRequirements DistillerBehavior UnitTypes DistillerUseCases DistillerStructure ItemTypes Organizing the Model 171 Units Library bdd [package] Unit Types C value unit=degreesCentigrade dimension=temperature kg m value unit=kilogram

dimension=mas s value unit=meter dimension=length kg/m kg/s cal/s value unit=kilogram/meter^2 dimension=pressure value unit=kilogram/second dimension=massflow value unit=calory/second dimension=energyflow Defining the Units 172 Behavior Breakdown bdd [package) DistillerBehavior [Distiller Behavior Breakdown] coldDirty a1 a2

activity HeatWater activity BoilWater a3 a4 hotDirty activity DistillWater steam block ItemTypes::H2O values temp=*C press=kg/m^2 pure external activity CondenseSteam activity DrainResidue recovered block

ItemTypes::Heat hiPress loPress block ItemTypes::Residue Distill Activity Decomposition and Types of Flows 173 H20 States stm [block] H2O Gas Add Latent Heat of Vaporization Remove Latent Heat of Vaporization Liquid Remove Latent Heat of Liquification Add Latent Heat of Liquification Solid 174 Distill Water Activity Diagram (Initial) effbd

act [activity] DistillWater [Simple Starting Point) coldDirty:H2O [liquid] Note: these are the same thing! steam:H2O [gas] hotDirty:H2O [liquid] recovered:Heat pure:H2O [liquid] a3:CondenseSteam a1:HeatWater a2:BoilWater a4:DrainResidue recovered:Heat external:Heat hiPress:Residue loPress:Residue Representing Distiller Example in SysML Using EFFBD Profile 175

Distill Water Activity Diagram (Continuous Activity Modeling) act [activity] DistillWater [Parallell Continuous Activities) loPress:Residue continuous coldDirty:H2O [liquid] continuous steam:H2O [gas] hiPress:Residue continuous recovered:Heat a4:DrainResidue a1:HeatWater a3:CondenseSteam continuous hotDirty:H2O [liquid] a2:BoilWater continuous external:Heat Representing Distiller Example in SysML Using Continuous Flow Modeling

continuous pure:H2O [liquid] 176 Diagram Allocated Behavior act [activity] DistillWater [Swimlane Diagram] allocate hx:HeatExchanger allocate bx:Boiler allocate dx:DrainValve continuous coldDirty:H2O [liquid] loPress:Residue continuous steam:H2O [gas] hiPress:Residue continuous recovered:Heat a4:DrainResidue streaming a1:HeatWater streaming

a3:CondenseSteam continuous hotDirty:H2O [liquid] streaming a2:BoilWater continuous external:Heat continuous pure:H2O [liquid] shutdown Allocating the Activities to Swim Lane that Represent Blocks 177 Distiller System Hierarchy (Top Level) A Diagram Feature Provided by SST Submission (refer to App A) bdd [package] DistillerStructure [Structural Breakdown] block Distiller hx block

HeatExchanger bx block Boiler diagramDescription version=0.1" description=initial structural breakdown of distiller system" reference=TBD completeness=ItemFlows and Connectors elided dv block DrainValve Describing the Distiller System and Its Components 178 Distiller Internal Block Diagram ibd: [block] Distiller [DistillerBlockDiagram - Unallocated] hx:HeatExchanger water_in:H2O bx:Boiler hx_water_out:H2O dv:DrainValve bx_sludge_out:Residue

: sludge_out:Residue : bx_steam_out:H2O heat_in:Heat water_out:H2O Describing the Interconnection of Parts And the Item Flows Between Them 179 Distiller Internal Block Diagram (with Allocations) ibd: [block] Distiller [DistillerBlockDiagram - Allocated] allocatedFrom objectNodecoldDirty:H2O allocatedFrom objectNodehotDirty:H2O hx:HeatExchanger Water_In:H2O allocatedFrom activityHeatWater: activityCondenseSteam: allocatedFrom objectNodehiPress:Residue bx:Boiler

hx_water_out:H2O bx_steam_out:H2O allocatedFrom activityBoilWater: allocatedFrom objectNodeloPress:Residue dv:DrainValve bx_sludge_out:Residue allocatedFrom activityDrainResidue: Sludge_out:Residue allocatedFrom objectNodesteam:H2O Heat_in:Heat Water_out:H2O allocatedFrom objectNodeExternal:Heat allocatedFrom objectNodePure:H2O Showing the Allocations from Activities and Object Nodes to Blocks and Item Flows 180

Heat Exchanger Interface Specs bdd [block] HeatExchanger [HeatExchanger Flow Definition] block Fluid block HeatExchanger values temp=C press=kg/m^2 values thermalEfficiency:Real block Heat values dQ/dt=cal/s vIn:VaporFlow fIn:Fluid qIn:HeatFlow block CoolantSide block CondensorSide fOut:FluidFlow fOut:Fluid

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) And Constraints on Flow Ports 181 Analysis (includes constraints on I/O) par [block] Distiller [Simplified Isobaric Heat Balance Analysis} {Qrate=(th-tc)*mRate/sh)} water_in:H2O mRate value temp value massFlowRate tin sh tout r1 Qrate equivalent

{r1=r2} hx_water_out:H2O value temp SinglePhaseHeatXFR Equation r2 ItemTypes::H2O Qrate value specificHeat condensing: SimplePhaseChange Equation value massFlowRate lh value latentHeat mRate bx_steam_out:H2O value massFlowRate {Qrate=mRate*lh)} r1

water_out:H2O value massFlowRate equivalent {r1=r2} Qrate r2 boiling: SimplePhaseChange Equation lh mRate heat_in:Heat value dQ/dt Defining the Thermal Equations as Constraints on the Flow Properties 182 Analysis Results - Isobaric analysisResult IsobaricHeatBalance1 [Results of Isobaric Heat Balance] 540 540 1 0

dQ/dt condensate-steam cal/sec boiler efficiency dQ/dt in boiler cal/sec 540 1 540 water_out dQ/dt cooling water cal/sec dQ/dt steam-condensate cal/sec condenser efficency heat deficit bx_steam_out 1 6.75 6.75 1 1 20 100 100 100 100 bx_water_in mass flow rate gm/sec temp C hx_water_out 1 540 water_in specific heat cal/gm-C

latent heat cal/cm Note: Cooling water needs to have 6x flow of steam! Need bypass between hx_water_out and bx_water_in! Analysis Results Indicate Need for Modification to Existing Desgin 183 Behavior Breakdown - Revised bdd [package) DistillerBehavior [Revised Distiller Behavior Breakdown] coldDirty a1 a2 hotDirty activity DistillWater steam pure activity HeatWater activity BoilWater

block ItemTypes::H2O values temp=*C press=kg/m^2 hotDirty1 hotDirty2 a3 a4 external activity CondenseSteam activity DrainResidue recovered block ItemTypes::Heat a5 hiPress activity ReturnSome loPress block ItemTypes::Residue New Activity Required To Meet the Need

184 Swim Lane Diagram - Revised act [activity] DistillWater [Revised Swimlane Diagram] allocate hx:HeatExchanger allocate bx:Boiler allocate dx:DrainValve continuous coldDirty:H2O [liquid] loPress:Residue continuous steam:H2O [gas] hiPress:Residue continuous recovered:Heat a4:DrainResidue streaming a1:HeatWater continuous hotDirty:H2O [liquid] streaming

a3:CondenseSteam a5:ReturnSome continuous hotDirty1:H2O [liquid] streaming a2:BoilWater continuous external:Heat continuous pure:H2O [liquid] shutdown continuous hotDirty2:H2O [liquid] New Activity Shown in Swim Lane Diagram 185 Distiller Internal Block Diag Revised ibd: [block] Distiller [Revised DistillerBlockDiagram - Allocated] allocatedFrom objectNodehotDirty2:H2O waste_water:H2O allocatedFrom objectNodecoldDirty:H2O allocatedFrom objectNodehotDirty1:H2O

hx:HeatExchanger Water_In:H2O allocatedFrom activityHeatWater: activityCondenseSteam: allocatedFrom objectNodehiPress:Residue allocatedFrom objectNodeloPress:Residue bx:Boiler dv:DrainValve allocatedFrom activityBoilWater: allocatedFrom activityDrainResidue: bx_sludge_out:Residue Sludge_out:Residue bx_water_in:H2O bx_steam_out:H2O allocatedFrom objectNodesteam:H2O

Heat_in:Heat water_out:H2O allocatedFrom objectNodeExternal:Heat allocatedFrom objectNodePure:H2O Additional Item Flow Required To Support Change 186 Parametric Diagram Thermal Analysis (Revised) par [block] Distiller [Detailed Heat Balance Analysis} waste_water:H2O value massFlowRate water_in:H2O value temp mRate value massFlowRate r3 r1 sum {r1=r2+r3}

tin SinglePhaseHeatXFR Equation tout specificHeat t1 value temp value press p1 t2 p2 value massFlowRate ItemTypes::H2O Qrate r2 bx_water_in:H2O sh latentHeat qin

boiling: PhaseChangeEquation lh rate http://www.spiraxsarco.com/learn/ ?redirect=html/2_15_01.htm bx_steam_out:H2O value temp t1 value press value massFlowRate r1 equivalent {r1=r2} water_out:H2O value temp p1 t2 p2 qout condensing: PhaseChangeEquation

lh rate r2 value press value massFlowRate heat_in:Heat value dQ/dt Revised Thermal Analysis To Support Change 187 Analysis Results Non Isobaric Example analysisResult PhaseChangeEquation [H20 - Mollier Diagram] Update to Analysis Results 188 Summary SST SysML Submission Satisfies Most Requirements in the RFP

Critical Issues Resolved Multi-vendor implementations Our solution Small number of remaining reqts to be addressed along with user/vendor feedback in future revisions Architecturally sound & compatible with UML 2/ XMI Implementable by multiple vendors Meets the needs of SEs Refer to Highlights and Comparison Matrix and these slides to contrast with SysML Partners submission 190

Recently Viewed Presentations

  • A Topical Approach to Life-Span Development, 7

    A Topical Approach to Life-Span Development, 7

    Boys have better visuospatial skills than girls. No differences in math scores. Girls have more negative math attitudes and parents' and teachers' expectations for math competence are biased in favor of boys. Girls score higher than boys in reading and...
  • From last time Waves  Interference Thursday, Sep. 4

    From last time Waves Interference Thursday, Sep. 4

    Thursday, Sep. 4 Phy208 Lecture 2 * Phase difference Waves start in phase Travel different distances (extra path length = ) No longer in phase when combined (Phase diff ) = =2π = /2 =π General reln: Constructive: =2πm Destuctive:...
  • Movie Reviews - Mrs. Brown&#x27;s English Classes

    Movie Reviews - Mrs. Brown's English Classes

    A film reviewer also creates a dialogue. They place a movie in the social context of the times. For example, a good film reviewer in the 80s would have, and did, talk about the sort of hard bodied muscle men,...
  • Triplet Exciton Diffusion in Conjugated Polymers II The

    Triplet Exciton Diffusion in Conjugated Polymers II The

    1 Institute of Nuclear Research, National Academy of Sciences of Ukraine, Prospect Nauky 47, 03680 Kyiv, Ukraine ... Here, the relative contributions of polaronic and disorder effects on Dexter transfer are studied theoretically. Energy l/2 = Polaron binding energy Ep...
  • Chapter 3 Effects of IT on Strategy and Competition

    Chapter 3 Effects of IT on Strategy and Competition

    read data, process them, and format the data into structured reports (e.g., sorting, grouping, summing, and averaging) that are delivered to users. They are used primarily for . assessment. RFM ... Filtering. Grouping Calculating Formatting.
  • Unit 4 - Hutton&#x27;s Honors World History

    Unit 4 - Hutton's Honors World History

    - son of Charles I restored to monarch, continues Stuart family dynasty. Navigation Acts- required all imports to be carried on English ships or ships registered to the country from which the cargo originated. (1663) ... (First Hanover King) (Ruler...
  • Diapositive 1 - imagiLEOnation

    Diapositive 1 - imagiLEOnation

    L'île devint l'île du Mont Royal puis Montréal. La montagne possède trois sommets ou collines : la Grosse Montagne ou colline Mont-Royal, l'Outremont car il fallait passer la première pour y arriver, jadis appelée Pain de Sucre sous le régime...
  • National Council of Canada 47th Annual General Assembly

    National Council of Canada 47th Annual General Assembly

    (based on a poem by Hugo . Assmann) Le Dieu des pauvres est présent . dans les choses ordinaires, dans les mains ouvrières du peuple, dans la lutte qui rend la vie plus belle, dans le travail et dans la...