INCOSE Evaluation: Systems Modeling Language (SysML) SysML Submission Team (SST) 13, 15, 20 December 2005 SST Chair: Sanford Friedenthal sanford.friedenthal@lmco.com 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-11-01) A vote for adoption should occur at the next OMG meeting the week of February 13, 2006 3 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 SST broad based team of multiple INCOSE, AP233 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., test cases, verification results Other e.g., requirements hierarchy, traceability Refer to SST Req’ts Traceability Matrix in Appendix E. Verification e.g., parametric models, time property Requirements 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 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, … 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. 1 2 3 4 5 6 6a 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Language Feature Impact/Priority RFP Evaluation Criteria 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 MOE’s & 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 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 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 Section 15.3.3.3) test usability of multiple UI options via vendor prototypes RESPONSE: Made swim lanes explicit form of allocation (Fig 15-2, 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 Specification Updates Refer to Slide 15: No. 21 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 (MOE’s)* 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 Specification Topic Language Feature # (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 UML4SysML 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 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 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 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 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): Don’t 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 47 organization) 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 <<requirement>> 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] epc:ElectricalPower <> Controller ctrl bp:BatteryPack <> i2:Electric Current i1:Electric Current emg:ElectricMotor Generator <> Enclosing Block <> I_TRSMData I_IEPCData I_EPCCmd torquein:Torque c2 rightHalfShaft I_TRSMData g1:Torque torqueOut:Torque <> t1:Torque epc trsm ecu:PowerControlUnit ice rfw:ChassisSubsytem .FrontWheel spline <> ctrl trsm:Transmission c3 t2:Torque I_TRSMCmd <> I_IEPCData I_IEPCCmd acl:accelerator <> I_TRSMCmd dif:Differential ice:InternalCombustionEngine I_ICEData ctrl c1 4 fi:FuelInjector fdist <> Connector bp:BrakeSubsystem .BrakePedal Port:ICEFuelFitting ft:FuelTankAssy Port:FuelTankFitting fp:FuelPump <> fuelSupply:Fuel leftHalfShaft I_ICECmds <> I_ICEData <> I_ICECmds 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 intermediate connections env : Environment 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 [] Indicates part-specific block Properties tyrePressure : psi {distribution=Uniform (min=27,max=29)} «part» front : [Wheel] 2 Supports different values & distributions for each part Properties tyrePressure : psi {distribution=Uniform (min=25,max=27)} 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 «valueType» unit= M3 SIDensity «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 «requirment»Emissions TestVehicle1/hsuv:HSUV b12345/ b:BodySubsystem c34567/ c:Chassis Subsytem bk45678/ bk:Brake Subsystem i23456/ int:Interior Subsystem lt56789/ lt:Lighting bSubsystem Verifies «requirment»Emissions «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 <> i1:Electric Current <> Flow port I_IEPCData I_IEPCCmd I_TRSMCmd acl:accelerator ctrl trsm:Transmission c3 <> I_TRSMData I_IEPCData I_EPCCmd torquein:Torque c2 rightHalfShaft I_TRSMData g1:Torque torqueOut:Torque <> t1:Torque epc trsm ecu:PowerControlUnit ice rfw:ChassisSubsytem .FrontWheel spline <> i2:Electric Current emg:ElectricMotor Generator t2:Torque epc:ElectricalPower <> Controller ctrl bp:BatteryPack Item flow <> ibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator] <> I_TRSMCmd dif:Differential ice:InternalCombustionEngine I_ICEData <> I_ICEData ctrl c1 4 fi:FuelInjector Connector I_ICECmds fdist Client server port <> bp:BrakeSubsystem .BrakePedal Port:ICEFuelFitting ft:FuelTankAssy Port:FuelTankFitting fp:FuelPump leftHalfShaft <> fuelSupply:Fuel <> I_ICECmds lfw:ChassisSubsytem .FrontWheel fuelDelivery fuelReturn:Fuel Specifying Interfaces on an IBD in Terms of Connectors, Ports and Flows 68 Parametrics & MOE’s/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 MOE’s and objective functions integrated with Parametrics to support trade studies and engineering analysis Parametrics Scalability & Integration with Engr 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 Cd Cf tw tw tp incline PowerEquation i tp Accelleration Equation dt acc a v a dt VelocityEquation «value» globalTime.delta-t vel v v dt PostionEquation 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] f: :EconomyEquation Instance of constraint block is identical for each alternative «moe» HSUValt1.FuelEconomy p1: q: :MaxAcceleration Analysis «moe» HSUValt1.QuarterMileTime p3: «objectiveFunction» :MyObjectiveFunction {CE = ∑ Wi*Pi} CE: «moe» HSUValt1.CostEffectiveness z: «moe» HSUValt1.Zero60Time vc: :CapacityEquation uc: :UnitCostEquation p2: p4: p5: «moe» HSUValt1.CargoCapacity «moe» HSUValt1.UnitCost MOE’s and objective function provide flexible support for trade study analysis that is fully integrated with parametrics 73 Constraint Blocks - Comparison of Blockbased 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 multivalued 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 2.4 Function in Multi-exit Construct {cc#1} Item 1 2.2 Multi-exit Function «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 Pure water Condense steam Boil Dirty water Residue Heat to Dirty water Energy to condense Heat to Boil water and 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] 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 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 Decomp 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 «requirement»Acceleration 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 Refines «requirement» PowerSource Management shutOff 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 «elementType»ElementName PartName Compartment Notation Callout Notation allocatedFrom «elementType»ElementName 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 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’s 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 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 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 ibd [block] PowerSubsystem [Power Functional Allocation] «continuous» elecDrivePower allocatedFrom «objectNode»driveCurrent epc:ElectricalPower Controller allocatedFrom «activity»Control ElectricPower <> <> i2:Electric Current i1:Electric Current emg:ElectricalMotor Generator allocatedFrom «activity»Convert ElectricToPower Satisfies «requirement»Acceleration allocatedTo «itemFlow»i1: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 Application of Diagram 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 INCOSE’s 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 & MOE’s 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 Refines «requirement» PowerSource Management shutOff 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 <> i1:Electric Current <> i2:Electric Current emg:ElectricMotor Generator <> I_TRSMData I_IEPCData I_EPCCmd torquein:Torque c2 rightHalfShaft I_TRSMData g1:Torque torqueOut:Torque <> t1:Torque epc trsm ecu:PowerControlUnit ice rfw:ChassisSubsytem .FrontWheel spline <> ctrl trsm:Transmission c3 t2:Torque I_TRSMCmd <> I_IEPCData I_IEPCCmd acl:accelerator <> I_TRSMCmd dif:Differential ice:InternalCombustionEngine I_ICEData <> I_ICEData ctrl c1 4 fi:FuelInjector I_ICECmds bp:BrakeSubsystem .BrakePedal <> fdist Port:ICEFuelFitting ft:FuelTankAssy Port:FuelTankFitting fp:FuelPump leftHalfShaft <> fuelSupply:Fuel <> I_ICECmds lfw:ChassisSubsytem .FrontWheel fuelDelivery fuelReturn:Fuel 147 Test Result Instance ins SUV_EPA_Fuel_Economy_Test_Result Satisfies «requirment»Emissions TestVehicle1/hsuv:HSUV b12345/ b:BodySubsystem c34567/ c:Chassis Subsytem bk45678/ bk:Brake Subsystem i23456/ int:Interior Subsystem lt56789/ lt:Lighting bSubsystem Verifies «requirment»Emissions «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 «connector»fdist fi4:FuelInjector allocatedFrom «connector»FuelDelivery 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 <<requirement>> 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] f: :EconomyEquation Instance of constraint block is identical for each alternative «moe» HSUValt1.FuelEconomy p1: q: :MaxAcceleration Analysis «moe» HSUValt1.QuarterMileTime p3: «objectiveFunction» :MyObjectiveFunction {CE = ∑ Wi*Pi} CE: «moe» HSUValt1.CostEffectiveness z: «moe» HSUValt1.Zero60Time vc: :CapacityEquation uc: :UnitCostEquation 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 Cf «value» ElectricMotorGenerator. GeneratorEfficiency fw RollingFriction Equation «value» HSUV.VehicleDryWeight «value» ElectricMotorGenerator. MotorEfficiency «value» FuelTank.FuelWeight 156 Evaluating Vehicle Dynamics par [constraintBlock] StraightLineVehicleDynamics tw Cf Cd whlpwr whlpwr Cd Cf tw tw tp incline PowerEquation i 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 «requirement»Acceleration 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 «itemFlow»i1:ElectricCurrent 161 Multiple Allocations shown on IBD ibd [block] PowerSubsystem [Power Functional Allocation] allocatedFrom «objectNode»driveCurrent «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 <> <> i2:Electric Current i1:Electric Current allocatedFrom «activity»Convert ElectricToPower <> allocatedFrom «activity»Control ElectricPower emg:ElectricalMotor Generator fp:FS_EPC can:CAN_Bus ecu:PowerControlUnit allocatedFrom «activity»Proportion PowerLoad <> <> <> fp:FS_TRSM <> trsm:Transmission allocatedFrom «connector»c1 «connector»c2 «connector»c3 epc:IFS_EPC ice:IFS_ICE etrsm:IFS_TRSM fp:FS_ICE <> ice:InternalCombustionEngine allocatedFrom «activity»ConvertGasToPower 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 Pure water Condense steam Boil Dirty water Residue Heat to Dirty water Energy to condense Heat to Boil water and 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 support? 168 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 Dave’s 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 kg m «value» unit=degreesCentigrade dimension=temperature «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 hotDirty «activity» DistillWater a2 «activity» HeatWater «activity» BoilWater a3 a4 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 Distill Water – Swim Lane 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 «objectNode»coldDirty:H2O allocatedFrom «objectNode»hotDirty:H2O hx:HeatExchanger Water_In:H2O allocatedFrom «activity»HeatWater: «activity»CondenseSteam: allocatedFrom «objectNode»hiPress:Residue bx:Boiler hx_water_out:H2O allocatedFrom «activity»BoilWater: allocatedFrom «objectNode»loPress:Residue dv:DrainValve bx_sludge_out:Residue allocatedFrom «activity»DrainResidue: Sludge_out:Residue bx_steam_out:H2O allocatedFrom «objectNode»steam:H2O Heat_in:Heat Water_out:H2O allocatedFrom «objectNode»External:Heat allocatedFrom «objectNode»Pure: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 <> qOut:HeatFlow «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 Parametric Diagram – Thermal 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 SinglePhaseHeatXFR Equation sh tout r1 Qrate equivalent {r1=r2} hx_water_out:H2O r2 ItemTypes::H2O Qrate «value» temp «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] mass flow rate gm/sec temp °C water_out bx_steam_out bx_water_in hx_water_out 1 540 water_in specific heat cal/gm-°C latent heat cal/cm 6.75 6.75 1 1 1 20 100 100 100 100 dQ/dt cooling water cal/sec dQ/dt steam-condensate cal/sec condenser efficency heat deficit 540 540 1 0 dQ/dt condensate-steam cal/sec boiler efficiency dQ/dt in boiler cal/sec 540 1 540 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 hotDirty «activity» DistillWater a1 steam a2 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 «objectNode»hotDirty2:H2O waste_water:H2O allocatedFrom «objectNode»coldDirty:H2O allocatedFrom «objectNode»hotDirty1:H2O hx:HeatExchanger Water_In:H2O allocatedFrom «activity»HeatWater: «activity»CondenseSteam: allocatedFrom «objectNode»hiPress:Residue allocatedFrom «objectNode»loPress:Residue bx:Boiler dv:DrainValve allocatedFrom «activity»BoilWater: allocatedFrom «activity»DrainResidue: bx_sludge_out:Residue Sludge_out:Residue bx_water_in:H2O bx_steam_out:H2O allocatedFrom «objectNode»steam:H2O Heat_in:Heat water_out:H2O allocatedFrom «objectNode»External:Heat allocatedFrom «objectNode»Pure: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 req’ts 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 SE’s Refer to Highlights and Comparison Matrix and these slides to contrast with SysML Partners submission 190