sign in sign up
<<
Home , Activity diagram, Deployment diagram, Object Management Group, Package diagram, Sequence diagram

OMG Systems Modeling Language (OMG SysML™) Tutorial

11 July 2006

Sanford Friedenthal Alan Moore Rick Steiner

Copyright © 2006 by . Published and used by INCOSE and affiliated societies with permission. Caveat

•This material is based on version 1.0 of the SysML specification (ad-06-03-01) –Adopted by OMG in May ’06 – Going through finalization process

•OMG SysML Website – http://www.omgsysml.org/

11 July 2006 Copyright © 2006 by Object Management Group. 2 Objectives & Intended Audience

At the end of this tutorial, you should understand the: •Benefits of model driven approaches to systems engineering •Types of SysML and their basic constructs • Cross-cutting principles for relating elements across diagrams • Relationship between SysML and other Standards •High-level process for transitioning to SysML

This course is not intended to make you a systems modeler! You must use the language.

Intended Audience: •Practicing Systems Engineers interested in system modeling – Already familiar with system modeling & tools, or – Want to learn about systems modeling •Software Engineers who want to express systems concepts •Familiarity with UML is not required, but it will help

11 July 2006 Copyright © 2006 by Object Management Group. 3 Topics

•Motivation & Background (30) • Overview (135) • SysML Modeling as Part of SE Process (120) –Structured Analysis –Distiller Example –OOSEM –Enhanced Security System Example •SysML in a Standards Framework (20) •Transitioning to SysML (10) •Summary (15)

11 July 2006 Copyright © 2006 by Object Management Group. 4 Motivation & Background SE Practices for Describing Systems Future Past • Specifications

• Interface requirements

• System design

• Analysis & Trade-off

• Test plans

Moving from Document centric to Model centric

11 July 2006 Copyright © 2006 by Object Management Group. 6 System Modeling

Requirements

Start Shift Accelerate Brake Control Power Vehicle Input Equations Dynamics

Mass Properties ModelStructural Model Safety Model Cost Engine Transmission Transaxle Model

Integrated System Model Must Address Multiple Aspects of a System 11 July 2006 Copyright © 2006 by Object Management Group. 7 Model Based Systems Engineering Benefits •Improved communications •Assists in managing complex system development – Separation of concerns –Hierarchical modeling –Facilitates impact analysis of requirements and design changes –Supports incremental development & evolutionary acquisition • Improved design quality –Reduced errors and ambiguity –More complete representation •Early and on-going verification & validation to reduce risk •Other life cycle support (e.g., training) •Enhanced knowledge capture

11 July 2006 Copyright © 2006 by Object Management Group. 8 System-of-Systems

Interactions

Boundaries

Modeling Needed to Manage System Complexity

11 July 2006 Copyright © 2006 by Object Management Group. 9 Modeling at Multiple Levels of the System

MCE (CRC)

MCE (CRC) AWACS MCE (CRC)

LINK 16 LINK 16 AMDPCS

FAAD C3I

LINK 16 LINK 16 Patriot ICC

E-2C AWACS F/A-18

RIVET JOINT MCE

F-15C

ABMOC Subsystem Voice Comm Operator Interface Power Hardware Power Generation Hardware includes MSE SIAP ACDS (CVN) and Distribution Power Data Processing Power Terminal Power TCIM JTIDS Hardware Operational Models Terminal

DDG-51 AEGIS Destroyer Software Power CG EPLRS or SINGARS Force Level Terminal Control System TAOM Power Voice & TADIL-B Data PLGR (GPS)

Patriot ICC Power A2C2 Subsystem Power Operator Interface Voice Comm Power Hardware Power Generation Hardware includes and Distribution MSE Power CEC Information Exchange Requirements - Classified SECRET when filled in Data Processing 12 34567891011 Terminal TCIM Se ndingRe ce iv ing Latency: SA/EngMessage FAAD C3I Voice & TADIL-B Data Rationale/UJTL Number Event/Action Information Characterization Cr itical For m at Class Rem ar k s Hardware Power No de No de Support Err or Rat e Radar measurements to REF: CEC A-spec JTIDS Provide SA/Support OP 5.1.1 Com m Op Info support data fusion compositeHost CEP Yes Binary IAW IDD Secret xx secs/xx secsTable 3-3 xx and % AMDPCS Terminal Engage m e nt s Software tracking Hos t r e qm ts IFF measurements to support Provide SA/Support OP 5.1.1 Com m Op Info data fusion and compositeHost CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Engage m e nt s EPLRS or SINGARS tracking IFF interrogation requests to Terminal Provide SA/Support Res pond w he n Power OP 5.1.1 Com m Op Info support data fusion and Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Engage m e nt s requested Force Level Power com posite tracking Provide SA/SupportID Changes to support data Control System OP 5.1.1 Com m Op Info Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % PLGR Engage m e nt s fusion and composite tracking (GPS) Provide SA/SupportNavigation data to support data REF:CEC SRS and Power OP 5.1.1 Com m Op Info Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Engage m e nt s fusion and composite tracking Hos t Nav. s pe c

Engagement Support Requests Provide SA/Support OP 5.1.1 Com m Op Info to support data fusion andHost CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % AEGIS only Engage m e nt s com posite tracking Track number management to Provide SA/Support Changes sent OP 5.1.1 Com m Op Info support data fusion and Host-CEP CEP-Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engage m e nt s immediately com posite tracking Composite Track State Update Provide SA/Support REF: CEC IDDs for OP 5.1.1 Com m Op Info to support data fusion andCEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engage m e nt s each host com posite tracking Associated Measurement REF: CEC A-spec Provide SA/Support OP 5.1.1 Com m Op Info Reports to support data fusionCEP Host Yes Binary IAW IDD Secret xx secs/xx secsTable 3-3. xx SPY% Engage m e nt s and com posite track ing only IFF Assignments to support Provide SA/Support When assigned OP 5.1.1 Com m Op Info data fusion and compositeCEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engage m e nt s or changed tracking ID recommendationst o Provide SA/Support When assigned Network Plan OP 5.1.1 Com m Op Info support data fusion and CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engage m e nt s or changed CID Criteria composite tracking REF: CEC A-spec Provide SA/SupportSensor cues to support data OP 5.1.1 Com m Op Info CEP Host Yes Binary IAW IDD Secret xx secs/xx secsTable 3-3. xx SPY% Engage m e nt s fusion and composite tracking Network only Network Track Data Receive Network Track Data Track File

11 Correlate Track Correlated Track Files

12 Manage BMDS Track File Data BMDS Track JDN Correlation S/W Network Interface Track Management Module Correlation Module Track File HIC Module Module 13

Request Attempt to Track Data Correlate with Track Data Possible BMDS Track Network BMDS Track File Matches Interface S/W Network Track MSG Track File Request

Track Data Send Track System Models Track Mangement S/W Module HIC File Data

BMDS Track Data Correlate Tracks BMDS Track Data

Correlation Results Session Activated Verify CID, Correlation, and Assoicated Track yes Update Track File Data Data Correlation no / initialize Possible CreateCorrelation New Complete ( Correlation BMDSResults Track ) [ set not null ] / Send Results Idle Network Track File Received ( File Data ) [ number tracks > 0 ] / Input Network Track

Correlating TracksMonitor BMDS Track Display Correlation Receiving Network Track File On entry / match state vectorsProcess Data BMDS Track Data Do / corr state vectors Do / corr LPE On entry / receive file data Do / corr PIP Do / store track data Track MSG Data Send BMDS Do / corr RCS On exit / request matching data Track Data to Do / corr CID JDN System Design<TITLE> On exit / corr BMDS Track # Prepared Track MSG</p><p> corr fail / is new BMDS Track corr success / is corr BMDS Track <META http-equiv="REFRESH" BMDS Track File Request Sent ( Request ) / Pull BMDS Track Files BMDS Track File Data Received ( File Data ) / <!--CSSDATA:966533483--> Correlate Tracks Receiving BMDS Track File Data <SCRIPT src="/virtual/2000/code On entry / receive file data Do / store track data <LINK rel="stylesheet" href="/ <SCRIPT language="javascript"</p><p>Track Mangement Module HIC /current tracks /associated track data manages 1..* /CID data uses 1..*</p><p> assign CID () 1..* JDN recommend CID () 1..* retrieve track file data () display track file data () communicates with ABMOC Subsystem 1 Voice Comm Operator Interface Power 0..* Hardware Hardware includes interface for Power Generation <<entity>> MSE 1 1 1 and Distribution Track File Power <<interface>> Correlation Module Track Number Network Interface Module Data Processing Power CID 0..* algorithm Terminal Power TCIM /State Vector buffer capacity /tracks to be correlated JTIDS /Date-Time correlation data Hardware /msg data Terminal received from decorrelation data send track data () receive msg () parse msg () correlate tracks () Power route msg data () decorrelate tracks () Software build msg () retrieve track data () send msg () send track data () EPLRS or SINGARS Force Level Terminal Control System 1 0..* Power Voice & TADIL-B Data correlates PLGR (GPS) <<entity>> <<entity>> Network Track Customer Power BMDS Track Software License owning element Primary Key <<derived>> Primary Key is subject to Client Call A2C2 Subsystem Received Date-Time /associated data owns traces to /history Customer_ID [PK1] Power local track number Serial_Number [PK1] Primary Key Operator Interface Non-Key Attributes Voice Comm Non-Key Attributes Serial_Number [PK1] [FK]Hardware Power Power Generation Component Models Hardware includes receive () create () Customer_Name store () update () Technical_Contact and Distribution MSE destroy () Purchase_Contact update () send () retrieve ()Customer_Address Power createsData Processing consists of Terminal TCIM Voice & TADIL-B Data Hardware Power JTIDS Software Release Terminal Software Primary Key Tech Support System Entry Version_Number [PK1] Primary Key TSS_Entry_Number [PK1] Non-Key Attributes EPLRS or SINGARS Terminal Windows_Version Power TSS_Description Force Level Power Control System PLGR (GPS) Power Status Location is a Primary Key currently has Primary Key Status [PK1] Status [PK1] [FK]</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 10 Stakeholders Involved in System Acquisition Developers/ Customers Integrators</p><p>Project Managers</p><p>Vendors</p><p>Regulators Testers</p><p>Modeling Needed to Improve Communications</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 11 What is SysML?</p><p>• A graphical modelling 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 </p><p>• Supports the specification, analysis, design, verification, and validation of systems that include hardware, software, data, personnel, procedures, and facilities</p><p>•Supports model and data interchange via XMI and the evolving AP233 standard (in-process)</p><p>SysML is Critical Enabler for Model Driven SE </p><p>11 July 2006 Copyright © 2006 by Object Management Group. 12 What is SysML (cont.)</p><p>• Is a visual modeling language that provides –Semantics = meaning –Notation = representation of meaning • Is not a methodology or a tool –SysML is methodology and tool independent</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 13 UML/SysML Status</p><p>•UML V2.0 –Updated version of UML that offers significant capability for systems engineering over previous versions – Finalized in 2005 (formal/05-07-04)</p><p>• UML for Systems Engineering (SE) RFP –Established the requirements for a system modeling language –Issued by the OMG in March 2003</p><p>•SysML –Industry Response to the UML for SE RFP –Addresses most of the requirements in the RFP –Version 1.0 adopted by OMG in May ’06 / In finalization –Being implemented by multiple tool vendors</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 14 SysML Team Members</p><p>•Industry & Government –American Systems, BAE SYSTEMS, Boeing, Deere & Company, EADS-Astrium, Eurostep, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, THALES •Vendors –Artisan, EmbeddedPlus, Gentleware, IBM, I-Logix, Mentor Graphics, PivotPoint Technology, Sparx Systems, <a href="/tags/Telelogic/" rel="tag">Telelogic</a>, Vitech Corp •Academia –Georgia Institute of Technology •Liaison Organizations –INCOSE, ISO AP233 Working Group</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 15 Diagram Overview Relationship Between SysML and UML</p><p>UML 2 SysML</p><p>SysML UML extensions reused by to UML SysML (SysML (UML4SysML) UML Profile) not required by SysML (UML - UML4SysML)</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 17 SysML Diagram Taxonomy</p><p>SysML Diagram</p><p>Behavior Requirement Structure Diagram Diagram Diagram</p><p>Activity Sequence State Machine <a href="/tags/Use_case/" rel="tag">Use Case</a> Block Definition Internal Block <a href="/tags/Package_diagram/" rel="tag">Package Diagram</a> Diagram Diagram Diagram Diagram Diagram Diagram</p><p>Same as UML 2 Parametric Diagram Modified from UML 2</p><p>New diagram type</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 18 4 Pillars of SysML – ABS Example</p><p>1. Structuresd ABS_ActivationSequence [<a href="/tags/Sequence_diagram/" rel="tag">Sequence Diagram</a>] 2. Behavior bdd [<a href="/tags/Package_(UML)/" rel="tag">package</a>] VehicleStructure [ABS-Block Definition Diagram] stm TireTraction [<a href="/tags/State_diagram/" rel="tag">State Diagram</a>] interaction d1:Traction m1:Brake «block» «block» «block» Detector Modulator Library:: Library::Elec act PreventLockup [ActivityLossOfTraction Diagram] Anti-Lock state Electronic tro-Hydraulic Controller Processor Valve machine detTrkLos()Gripping Slipping ibd [block] Anti-LockController d1 m1[Internal Block Diagram] <a href="/tags/Activity_(UML)/" rel="tag">activity</a>/ «block» «block» DetectLossOf RegainTraction Modulate sendSignal() TractionLoss: function Traction Brake d1:Traction Traction BrakingForce Detector Detector Modulatorc1:modulator modBrkFrc(traction_signal:boolean) interface modBrkFrc() m1:Brake definition use Modulator</p><p> sendAck()</p><p> req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements] par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]</p><p>Vehicle System Braking Subsystem tf: tl: bf: c Specification Specification</p><p>:BrakingForce f: :Accelleration «requirement» «requirement» Equation Equation StoppingDistance Anti-LockPerformance [f = (tf*bf)*(1-tl)] F: [F = ma]</p><p> id=“102” id=”337" a: text=”The vehicle shall stop text=”Braking subsystem shall a: from 60 mph within 150 ft prevent wheel lockup under all on a clean dry surface.” braking conditions.” v: :DistanceEquation :VelocityEquation [v = dx/dt] v: [a = dv/dt] «deriveReqt» x: 3. Requirements 4. Parametrics 11 July 2006 Copyright © 2006 by Object Management Group. 19 SysML Diagram Frames</p><p>•Each SysML diagram represents a model element • Each SysML Diagram must have a Diagram Frame •Diagram context is indicated in the header: –Diagram kind (act, bdd, ibd, seq, etc.) –Model element type (activity, block, interaction, etc.) –Model element name –Descriptive diagram name or view name •A separate diagram description block is used to indicate if the </p><p> diagram is complete, or has elements elided Diagram Description</p><p>Version: Description: Completion status: Header Reference: (User-defined fields)</p><p>«diagram usage» diagramKind [modelElementType] modelElementName [diagramName]</p><p>Contents</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 20 Structural Diagrams</p><p>SysML Diagram</p><p>Behavior Requirement Structure Diagram Diagram Diagram</p><p>Activity Sequence State Machine Use Case Block Definition Internal Block Package Diagram Diagram Diagram Diagram Diagram Diagram Diagram</p><p>Same as UML 2 Parametric Diagram Modified from UML 2</p><p>New diagram type</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 21 Package Diagram</p><p>•Package diagram is used to organize the model –Groups model elements into a name space –Often represented in tool browser •Model can be organized in multiple ways – By System hierarchy (e.g., enterprise, system, <a href="/tags/Component_(UML)/" rel="tag">component</a>) –By domain (e.g., requirements, use cases, behavior) –Use viewpoints to augment model organization •Import relationship reduces need for fully qualified name (package1::class1)</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 22 Package Diagram Organizing the Model</p><p> pkg SampleModel [by diagram type] pkg SampleModel [by level] pkg SampleModel [by IPT]</p><p>Architecture Use Cases Enterprise Team</p><p>Requirements Requirements System Team</p><p>Behavior Logical Design IPT A</p><p>Allocated Structure IPT B Design</p><p>EngrAnalysis Verification IPT C</p><p>By Diagram Type By Hierarchy By IPT</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 23 Package Diagram - Views</p><p> pkg SampleModel [by level] •Model is organized in one hierarchy Enterprise • Viewpoints can provide </p><p>«import» insight into the model using another principle «view» «import» –E.g., analysis view System EngrAnalysis that spans multiple </p><p>«import» levels of hierarchy</p><p>«conforms» –Can specify diagram Logical Design «import» usages, constraints, and filtering rules</p><p>EngrAnalysisViewpoint –Consistent with IEEE Allocated 1471 definitions Design «viewpoint» stakeholders=” ” purpose=” ” methods=” ”</p><p>Verification</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 24 Blocks are Basic Structural Elements</p><p>•Provides a unifying concept to describe the structure of an element or system «block» – Hardware BrakeModulator – Software allocatedFrom –Data «activity»Modulate –Procedure BrakingForce –Facility values –Person DutyCycle: Percentage</p><p>•Multiple compartments can describe the block characteristics – Properties (parts, references, values) – Operations –Constraints –Allocations to the block (e.g. activities) –Requirements the block satisfies</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 25 Block Property Types</p><p>•Property is a structural feature of a block – Part property aka. part (typed by a block) • Usage of a block in the context of the enclosing block • Example - right-front:wheel – Reference property (typed by a block) •A part that is not ownedby the enclosing block (not composition) •Example -logical interface between 2 parts – Value property (typed by value type) •Defines a value with units, dimensions, and probability distribution • Example –Non-distributed value: tirePressure:psi=30 –Distributed value: «uniform»{min=28,max=32} tirePressure:psi</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 26 Using Blocks</p><p>• Based on UML Class from UML Composite Structure –Eliminates association classes, etc. –Differentiates value properties from part properties, add nested connector ends, etc. •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</p><p>Blocks Used to Specify Hierarchies and Interconnection</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 27 Block Definition vs. Usage</p><p>Block Definition Diagram Internal Block Diagram</p><p> bdd [package] VehicleStructure [ABS-Block Definition Diagram] ibd [block] Anti-LockController [Internal Block Diagram] «block» «block» Library:: Anti-Lock Electronic s1:Sensor Controller c2:sensor Processor Interface d1:Traction d1 m1 s1 Detector c1:modulator «block» «block» Interface «block» m1:Brake Traction Brake Sensor Detector Modulator Modulator</p><p>Definition Usage –Block is a definition/type –Part is the usage in a particular context –Captures properties, etc. –Typed by a block –Reused in multiple contexts –Also known as a role</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 28 Internal Block Diagram (ibd) Blocks, Parts, Ports, Connectors & Flows</p><p> ibd [block] Anti-LockController Reference [Internal Block Diagram] Enclosing Property (in, but not of) Block c2:sensor Interface s1:Sensor</p><p>Item Flow c1:modulator d1:Traction Detector Interface Part</p><p>Connector m1:Brake Modulator Port</p><p>Internal Block Diagram Specifies Interconnection of Parts</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 29 Reference Property Explained</p><p>S1 is a reference part in ibd shown in dashed outline box</p><p> ibd [block] Anti-LockController [Internal Block Diagram]</p><p> c2:sensor Interface s1:Sensor</p><p> c1:modulator d1:Traction Interface Detector</p><p> m1:Brake Modulator</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 30 SysML Port</p><p>•Specifies interaction points on blocks and parts –Supports integration of behavior and structure • Port types –Standard (UML) Port •Specifies a set of operations and/or signals •Typed by a UML interface –Flow Port •Specifies what can flow in or out of block/part •Typed by a flow specification</p><p>2 Port Types Support Different Interface Concepts</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 31 Port Notation</p><p> provided interface (provides the operations)</p><p>Standard Port</p><p> required interface (calls the operations)</p><p>Flow Port</p><p>Flow Port item flow</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 32 Delegation Through Ports</p><p>•Delegation can be used to ibd [block]Block1[delegation] preserve encapsulation of </p><p> block Child1: • Interactions at outer ports of Block1 are delegated to ports </p><p> of child parts Child2: •Ports must match (same kind, types, direction etc.) •(Deep-nested) Connectors can break encapsulation if required (e.g. in physical system modeling)</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 33 Parametrics</p><p>•Used to express constraints (equations) between value properties –Provides support for engineering analysis (e.g., performance, reliability) •Constraint block captures equations –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 u a) Parametrics Enable Integration of Engineering Analysis with Design Models</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 34 Defining Vehicle Dynamics</p><p>Defining Reusable Equations for Parametrics</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 35 Vehicle Dynamics Analysis</p><p> par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]</p><p> v.chassis.tire. v.brake.abs.m1. v.brake.rotor. Friction: DutyCycle: BrakingForce: v.Weight:</p><p> tf: tl: bf: m:</p><p>:BrakingForce f: :Accelleration Equation Equation {f = (tf*bf)*(1-tl)} F: {F = m*a}</p><p> a: a:</p><p> v: :DistanceEquation :VelocityEquation {v = dx/dt} v: {a = dv/dt}</p><p> x:</p><p> v.Position:</p><p>Using the Equations in a Parametric Diagram to 11 July 2006Constrain Copyright © 2006 Value by Object PropertiesManagement Group. 36 Behavioral Diagrams</p><p>SysML Diagram</p><p>Behavior Requirement Structure Diagram Diagram Diagram</p><p>Activity Sequence State Machine Use Case Block Definition Internal Block Package Diagram Diagram Diagram Diagram Diagram Diagram Diagram</p><p>Same as UML 2 Parametric Diagram Modified from UML 2</p><p>New diagram type</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 37 Activities</p><p>•Activity used to specify the flow of inputs/outputs and control, including sequence and conditions for coordinating activities •Secondary constructs show responsibilities for the activities using swim lanes •SysML extensions to Activities – Support for continuous flow modeling –Alignment of activities with Enhanced Functional Flow Block Diagram (EFFBD)</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 38 <a href="/tags/Activity_diagram/" rel="tag">Activity Diagram</a> Notation</p><p>Activity</p><p> act MonitorTraction</p><p>WheelRevs Action</p><p>Initial Decision Calculate Node Wheel Velocity [loss of Angular Velocity of traction] Calculate Calculate Modulation Modulation Fork Traction Frequency Speed Fr e que nc y [else]</p><p>Calculate Car Control Velocity Flow Object Flow SpeedoInput Flow Activity Final Final Node Activity Node Pin Parameter Node</p><p>•Join and Merge symbols not included •Activity Parameter Nodes on frame boundary correspond to activity parameters 11 July 2006 Copyright © 2006 by Object Management Group. 39 Activity Diagrams Pin vs. Object Node Notation • Pins are kinds of Object Nodes –Used to specify inputs and outputs of actions –Typed by a block or value type – Object flows connect object nodes •Object flows between pins have two diagrammatic forms –Pins shown with object flow between them –Pins elided and object <a href="/tags/Node_(UML)/" rel="tag">node</a> shown with flow arrows in and out act PreventLockup [Activity Diagram] act PreventLockup [Activity Diagram] Pins must have same characteristics Traction DetectLossOf Loss: Modulate DetectLossOf Modulate (name, type Traction BrakingForce TractionLoss: Traction Traction BrakingForce Loss: etc.)</p><p>Pins ObjectNode 11 July 2006 Copyright © 2006 by Object Management Group. 40 Explicit Allocation of Behavior to Structure Using Swimlanes act PreventLockup [Activity Diagram]</p><p>DetectLossOf Modulate Activity Diagram TractionLoss: Traction BrakingForce (without Swimlanes)</p><p> act PreventLockup [Swimlane Diagram]</p><p>«allocate» «allocate» :TractionDetector :BrakeModulator</p><p>Activity Diagram DetectLossOf Modulate TractionLoss: (with Swimlanes) Traction BrakingForce</p><p> allocatedTo «connector»c1:modulatorInterface</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 41 SysML EFFBD Profile EFFBD - Enhanced Functional Flow Block Diagram</p><p>Aligning SysML with Classical Systems Engineering Techniques</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 42 Distill Water Activity Diagram (Continuous Flow Modeling)</p><p>Continuous Flow</p><p>Interruptible Region Representing Distiller Example in SysML Using Continuous Flow Modeling 11 July 2006 Copyright © 2006 by Object Management Group. 43 Activity Decomposition</p><p> act PreventLockup [Activity Diagram] bdd PreventLockup [Activity Breakdown]</p><p>«activity» PreventLockup Traction a1:DetectLossOf Loss: a2:Modulate Traction BrakingForce a1 a2 Traction Loss: «activity» «activity» DetectLossOf ModulateBrak Traction ingForce</p><p>Definition Use</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 44 Interactions</p><p>•Sequence diagrams provide representations of message based behavior –represent flow of control –describe interactions •Sequence diagrams provide mechanisms for representing complex scenarios –reference sequences –control logic –lifeline decomposition •SysML does not include timing, interaction overview, and communications diagram</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 45 Black Box Interaction (Drive)</p><p> sd DriveBlackBox</p><p> driver:Driver vehicleInContext:HybridSUV</p><p> ref StartVehicleBlackBox</p><p> par</p><p> alt controlSpeed [state = (idle)]</p><p> ref Idle</p><p>[state = (accelerating/cruising)]</p><p> ref Accelerate/Cruise</p><p>[state = (braking)]</p><p> ref Brake</p><p> ref Steer</p><p> ref Park/ShutdownVehicle</p><p>UML 2 Sequence Diagram Scales by11 Supporting July 2006 Control Copyright © Logic 2006 by Objectand Manag Referenceement Group. Sequences 46 Black Box Sequence (StartVehicle)</p><p>References Lifeline Decomposition For White Box Interaction</p><p>Simple Black Box Interaction</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 47 White Box Sequence (StartVehicle)</p><p>Decomposition of Black Box Into White Box Interaction</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 48 Trial Result of Vehicle Dynamics</p><p>0.5 0.45 0.4</p><p>) 0.35 0.3 0.25 0.2</p><p>Accelleration (g 0.15 0.1 0.05 0 Lifeline are 05101520 Time (sec) 140</p><p>120 value properties</p><p>100</p><p>80</p><p>60 Velocity (mph) 40</p><p>20</p><p>0 05101520 Time (sec) 1800 1600 1400 1200 1000 Timing Diagram Not 800</p><p>Distance (ft) 600 400 Part of SysML 200 0 05101520 Time (sec)</p><p>Typical Example of a Timing Diagram 11 July 2006 Copyright © 2006 by Object Management Group. 49 State Machines</p><p>•Typically used to represent the life cycle of a block •Support <a href="/tags/Event_(UML)/" rel="tag">event</a>-based behavior (generally asynchronous) –Transition with trigger, guard, action –State with entry, exit, and do-activity –Can include nested sequential or concurrent states –Can send/receive signals to communicate between blocks during state transitions, etc.</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 50 Operational States (Drive)</p><p> stm HSUVOperationalStates</p><p>Off keyOff/</p><p> start[in neutral]/start engine shutOff/stop engine Nominal states only</p><p>Operate</p><p>Transition notation: Idle trigger[guard]/action accelerate/ when (speed = 0)</p><p> releaseBrake/</p><p>Accelerating/ Braking Cruising</p><p> engageBrake/</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 51 Use Cases</p><p>•Provide means for describing basic functionality in terms of usages/goals of the system by actors •Common functionality can be factored out via include and extend relationships •Generally elaborated via other behavioral representations to describe detailed scenarios •No change to UML</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 52 Operational Use Cases</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 53 Cross-cutting Constructs</p><p>•Allocations •Requirements</p><p>SysML Diagram</p><p>Behavior Requirement Structure Diagram Diagram Diagram</p><p>Activity Sequence State Machine Use Case Block Definition Internal Block Package Diagram Diagram Diagram Diagram Diagram Diagram Diagram</p><p>Same as UML 2 Parametric Diagram Modified from UML 2</p><p>New diagram type</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 54 Allocations</p><p>•Represent general relationships that map one model element to another •Different types of allocation are: –Behavioral (i.e., function to component) –Structural (i.e., logical to physical) –Software to Hardware – . •Explicit allocation of activities to structure via swim lanes (i.e., activity partitions) •Both graphical and tabular representations are specified</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 55 Different Allocation Representations (Tabular Representation Not Shown)</p><p>Element Name2 «allocate» Element Name1 «allocate» Element Name3</p><p>Allocate Relationship Explicit Allocation of Activity to Swim Lane</p><p>«block» BlockName</p><p>PartName</p><p> allocatedFrom «elementType»ElementName</p><p>Compartment Notation Callout Notation</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 56 SysML Allocation of SW to HW</p><p>• In UML the <a href="/tags/Deployment_diagram/" rel="tag">deployment diagram</a> is used to deploy artifacts to nodes •In SysML allocation on ibd and bdd is used to deploy software/data to hardware</p><p> ibd [node] SF Residence</p><p>«node» SF Resid ence In stallation</p><p>* 2 «hardware» «hardware» «hardware» : Optical Sensor : Video Camera : Alarm</p><p>«hardware» : Site Processor «hardware» allocatedFrom : NW Hub «hardware» «software» Device Mgr : DSL Modem allocatedFrom «software» Event Mgr «software» SF Comm I/F «software» Site Config Mgr «software» Site RDBMS «software» Site Status Mgr «software» User I/F 2 «software» User Valid Mgr «hardware» : DVD-ROM Drive allocatedFrom «data» Video File</p><p>«hardware» «hardware» : User Console : Site Hard Disk allocatedFrom «data» Site <a href="/tags/Database/" rel="tag">Database</a></p><p>11 July 2006 Copyright © 2006 by Object Management Group. 57 Requirements</p><p>• The «requirement» <a href="/tags/Stereotype_(UML)/" rel="tag">stereotype</a> represents a text based requirement –Includes id and text properties –Can add user defined properties such as verification method –Can add user defined requirements categories (e.g., functional, interface, performance) •Requirements hierarchy describes requirements contained in a specification •Requirements relationships include DeriveReqt, Satisfy, Verify, Refine, Trace, Copy</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 58 Requirements Breakdown</p><p> req [package] HSUVRequirements [HSUV Specification]</p><p>HSUVSpecification RefinedBy «useCase» HSUVUseCases::Accelerate</p><p>«requirement» «requirement» Eco-Friendliness Performance «requirement» Power</p><p>«deriveReqt»</p><p>«requirement» «requirement» «requirement» Braking FuelEconomy Accelleration</p><p>«requirement» Emissions</p><p>Id = “R1.2.1” VerifiedBy SatisfiedBy text = “The vehicle shall meet Ultra-Low «testCase» MaxAcceleration «block» PowerSubsystem Emissions Vehicle standards.”</p><p>Requirement Relationships Model the Content of a Specification 11 July 2006 Copyright © 2006 by Object Management Group. 59 Example of Derive/Satisfy Requirement Dependencies</p><p>Supplier</p><p>Client</p><p>Client depends on supplier (i.e., a change in supplier Supplier results in a change in client) Client</p><p>Arrow Direction Opposite Typical Requirements Flow-Down 11 July 2006 Copyright © 2006 by Object Management Group. 60 Problem and Rationale</p><p>Problem and Rationale can be attached to any Model Element to Capture Issues and Decisions</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 61 Stereotypes & Model Libraries</p><p>•Mechanisms for further customizing SysML •Profiles represent extensions to the language –Stereotypes extend meta-classes with properties and constraints •Stereotype properties capture metadata about the model element –Profile is applied to user model –Profile can also restrict the subset of the meta-model used when the <a href="/tags/Profile_(UML)/" rel="tag">profile</a> is applied •Model Libraries represent reusable libraries of model elements</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 62 Stereotypes</p><p>Defining the Stereotype Applying the Stereotype</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 63 Applying a Profile and Importing a Model Library</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 64 Cross Connecting Model Elements 1. Structure 2. Behavior</p><p> ibdibd [block][block] Anti-LockControllerAnti-LockController satisfies act PreventLockup [Swimlane Diagram] [Internal[Internal BlockBlock Diagram]Diagram] «requirement» Anti-Lock «allocate» «allocate» Performance act PreventLockup:TractionDetector [Activity Diagram] :BrakeModulator ibd [block] Anti-LockController [Internal Block Diagram]d1:TractionDetector</p><p> allocatedFrom c1:modulator c1:modulator «activity»DetectLosd1:Traction te Interface a InterfaceInterface OfTractionOf TractionDetector oc c1:modulator all interface DetectLossOf Modulate TractionLoss: m1:BrakeModulatorm1:Brake Traction BrakingForce Modulator allocatedFrom allocatedFrom «ObjectNode» «activity»Modulate«activity»Modulate TractionLoss: BrakingForceBrakingForce value allocatedTo values «connector»c1:modulatorInterface DutyCycle: Percentage binding satisfy par [constraintBlock][constraintBlock] StraightLineVehicleDynamicsStraightLineVehicleDynamics [Parametric[Parametric Diagram]Diagram] req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements] v.chassis.tire. v.brake.abs.m1. v.brake.rotor. Friction: DutyCycle: BrakingForce: v.Weight: par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram] Vehicle System Braking Subsystem Specification Specification tf:tf: tl:tl: bf: m:c</p><p> f: «requirement» «requirement» :BrakingForce:BrakingForce f:f: :Accelleration:Accelleration Equation Equation StoppingDistance Anti-LockPerformance F: [f[f == (tf*bf)*(1-tl)](tf*bf)*(1-tl)] F: [F[F == ma]ma] id=“102”id=“102” id=”337" text=”The vehicle shall stop text=”Braking subsystem a: from 60 mph within 150 ft shall prevent wheel lockup a: on a clean dry surface.” under all braking conditions.” v: VerifiedBy SatisfiedBy :DistanceEquation:DistanceEquation :VelocityEquation:VelocityEquation «interaction»MinimumStopp «block»Anti-LockController [v[v == dx/dt]dx/dt] v: [a[a == dv/dt]dv/dt] ingDistance «deriveReqt» x:</p><p>«deriveReqt» v.Position: 3. Requirementsverify 4. Parametrics 11 July 2006 Copyright © 2006 by Object Management Group. 65 SysML Modeling as Part of the SE Process Distiller Sample Problem Distiller Problem Statement</p><p>•The following problem was posed to the SysMLteam in Dec ’05 by D. Oliver: • Describe a system for purifying dirty water. –Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger –Boil dirty water is performed by a Boiler –Drain residue is performed by a Drain –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. • A crude behavior diagram is shown. Energy to Pure Dirty water condense Dirty water Steam water @ 20 deg C @ 100 deg C Condense steam Heat Dirty water and Boil Dirty water and To 100 deg C Drain Residue Residue Heat to Dirty Disposed water Heat to Boil residue water</p><p>What are the real requirements? How do we design the system? 11 July 2006 Copyright © 2006 by Object Management Group. 68 Distiller Types</p><p>Batch Distiller</p><p>Continuous Distiller</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 69 Distiller Problem – Process Used</p><p>•Organize the model, identify libraries needed •List requirements and assumptions •Model behavior –In similar form to problem statement –Elaborate as necessary •Model structure –Capture implied inputs and outputs • segregate I/O from behavioral flows –Allocate behavior onto structure, flow onto I/O •Capture and evaluate parametric constraints –Heat balance equation •Modify design as required to meet constraints</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 70 Distiller Problem – Package Diagram: Model Structure and Libraries</p><p> pkg [model] Distiller [Model Overview]</p><p>DistillerRequirements DistillerUseCases bdd [package] ValueTypes</p><p>«valueType» Real</p><p>DistillerBehavior DistillerStructure</p><p>«valueType» «valueType» «valueType» «valueType» temp press massFlowRate dQ/dt unit = ºC unit = N/m^2 unit = gm/sec unit = cal/sec ValueTypes ItemTypes dimension = dimension = dimension = dimension = temperature pressure massFlowRate heatFlowRate</p><p>«valueType» «valueType» «valueType» efficency specificHeat latentHeat</p><p> unit = null unit = cal/(gm*ºC) unit = cal/gm dimension = dimension = dimension = efficency specificHeat latentHeat</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 71 Distiller Example Requirements Diagram req [package] DistillerRequirements </p><p>Source</p><p>«requirement» OriginalStatement</p><p>Id = S0.0 text = Describe a system for purifying dirty water. -Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger -Boil dirty water is performed by a Boiler. Drain residue is performed by a Drain. 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.</p><p>«requirement» «requirement» «requirement» PurifyWater HeatExchanger WaterProperties</p><p>Id = S1.0 Id = S2.0 Id = S5.0 text = The system shall text = Heat dirty water and text = water has properties: density 1 purify dirty water. condense steam are performed by gm/cm3, temp 20 deg C, specific heat a Counter Flow Heat Exchanger 1cal/gm deg C, heat of vaporization 540 cal/gm. «requirement» Boiler</p><p>Id = S3.0 «requirement» WaterInitialTemp text = Boil dirty water is performed by a Boiler. Id = S5.1 «deriveReqt» text = water has an «rationale» «requirement» initial temp 20 deg C The requirement Drain for a boiling function and a Id = S4.0 boiler implies that text = Drain residue is performed by the water must be a Drain. purified by distillation</p><p>«requirement» DistillWater</p><p>Id = D1.0 text = The system shall purify water by boiling it. 11 July 2006 Copyright © 2006 by Object Management Group. 72 Distiller Example: Requirements Tables</p><p> table [requirement] OriginalStatement [Decomposition of OriginalStatement]</p><p> id name text S0.0 OriginalStatement Describe a system for purifying dirty water. S1.0 PurifyWater The system shall purify dirty water. S2.0 HeatExchanger Heat dirty water and condense steam are performed by a S3.0 Boiler Boil dirty water is performed by a Boiler. S4.0 Drain Drain residue is performed by a Drain. S5.0 WaterProperties water has properties: density 1 gm/cm3, temp 20 deg C, S5.1 WaterInitialTemp water has an initial temp 20 deg C</p><p> table [requirement] PurifyWater [Requirements Tree]</p><p> id name relation id name Rationale The requirement for a boiling function and a boiler S1.0 PurifyWater deriveReqt D1.0 DistillWater implies that the water must be purified by distillation</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 73 Distiller Example – Activity Diagram: Initial Diagram for DistillWater</p><p>•This activity diagram applies the SysML EFFBD profile, and formalizes the diagram in the problem statement.</p><p>Energy to Pure Dirty water condense Dirty water Steam water @ 20 deg C @ 100 deg C Condense steam Heat Dirty water and Boil Dirty water and To 100 deg C Drain Residue Residue Heat to Dirty Disposed water Heat to Boil residue water</p><p>Activities (Functions) Control (Sequence) Things that flow (ObjectNodes)</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 74 Distiller Example – Activity Diagram: Control-Driven: Serial Behavior</p><p>Batch Distiller 11 July 2006 Copyright © 2006 by Object Management Group. 75 Distiller Example – Block Definition Diagram: DistillerBehavior bdd [package] DistillerBehavior [Distiller Behavior Breakdown]</p><p>«activity» DistillWater a1 a2</p><p>«activity» «activity» HeatWater BoilWater Need to Activities consider phases (Functions) a3 a4 of H20 «activity» «activity» CondenseSteam DrainResidue</p><p>Control (not shown on BDD) Things that flow (ObjectNodes) 11 July 2006 Copyright © 2006 by Object Management Group. 76 Distiller Example – State Machine Diagram: States of H2O</p><p> stm [block] H2O</p><p>Gas</p><p>Add Latent Heat Remove Latent Heat of Vaporization of Vaporization States</p><p>Liquid</p><p>Add Latent Heat Remove Latent Heat of Liquification of Liquification Transitions Solid</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 77 Distiller Example – Activity Diagram: I/O Driven: Continuous Parallel Behavior</p><p> act [activity] DistillWater [Parallell Continuous Activities)</p><p> loPress:Residue coldDirty:H2O [liquid] steam:H20 hiPress:Residue [gas]</p><p> recovered:Heat</p><p> a4:DrainResidue a1:HeatWater a3:CondenseSteam</p><p> hotDirty:H2O [liquid] a2:BoilWater pure:H2O external:Heat [liquid]</p><p>Continuous Distiller 11 July 2006 Copyright © 2006 by Object Management Group. 78 Distiller Example – Activity Diagram: No Control Flow – Simultaneous Behavior</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 79 Distiller Example – Activity Diagram (with Swimlanes): DistillWater Parts</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 80 Distiller Example – Block Definition Diagram: DistillerStructure</p><p>Generic Subsystems Usage Names (Blocks) 11 July 2006 Copyright © 2006 by Object Management Group. 81 Distiller Example – Block Definition Diagram: Heat Exchanger Flow Ports</p><p> bdd [package] DistillerStructure [Structural Breakdown] «block» «block» Fluid Heat «block» values values Distiller temp:ºC dQ/dt:cal/s press:kg/m^2</p><p>Constraints</p><p>(on Ports) hx1 drain bx1</p><p> f2Out:Fluid in:Fluid «block» HeatExchanger hIn:Fluid fIn:Fluid «block» «block» Boiler qIn:Heat Valve out:Fluid cIn:Fluid constraints {cIn.temp <= 220} f1Out:Fluid {cIn.press <= 150} {cOut.temp <= 220} {cOut.press <= 150} {hIn.temp <= 400} hOut:Fluid {hIn.temp <= 1000} cOut:Fluid {hIn.temp <= 400} {hIn.temp <= 1000}</p><p>Generic Things Flow Ports Generic Subsystems That Flow (typed by things that flow) (Blocks) (Blocks) 11 July 2006 Copyright © 2006 by Object Management Group. 82 Distiller Example – Internal Block Diagram: Distiller Initial Design</p><p> ibd: [block] Distiller [DistillerBlockDiagram - ItemFlows]</p><p> m1:H2O m2:H2O s1:Residue s2:Residue</p><p> hx1:HeatExchanger bx1:Boiler drain:Valve</p><p> m3:H2O</p><p> q1:Heat</p><p> m4:H2O</p><p>Parts Flow Ports Connectors Things That Flow (Blocks used In Context in context) (ItemFlows) 11 July 2006 Copyright © 2006 by Object Management Group. 83 Distiller Example –Internal Block Diagram: Distiller with Allocation</p><p> ibd: [block] Distiller [DistillerBlockDiagram - ItemFlows]</p><p> allocatedFrom allocatedFrom allocatedFrom allocatedFrom «objectNode»coldDirty:H2O «objectNode»hotDirty:H2O «objectNode»hiPress:Residue «objectNode»loPress:Residue</p><p> m1:H2O m2:H2O s1:Residue s2:Residue</p><p> hx1:HeatExchanger bx1:Boiler drain:Valve</p><p> allocatedFrom allocatedFrom allocatedFrom «activity»a1:HeatWater «activity»a2:BoilWater «activity»a4:DrainResidue «activity»a3:CondenseSteam</p><p> m3:H2O</p><p> q1:Heat</p><p> m4:H2O allocatedFrom allocatedFrom allocatedFrom «objectNode»External:Heat «objectNode»steam:H2O «objectNode»Pure:H2O</p><p>Allocation Compartment Allocation Callout</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 84 Distiller Example – Parametric Diagram: Heat Balance Equations</p><p> par [block] Distiller [Simplified Isobaric Heat Balance Analysis} Parts or {Qrate=(th-tc)*mRate/sh)} water_in:H2O ItemFlows mRate: temp:ºC sh: tin: SinglePhaseHeatXFR Equation massFlowRate: gm/sec tout: r1: Qrate: equivalent hx_water_out:H2O {r1=r2} water_in:H2O r2: Qrate: specificHeat: temp:ºC Value cal/(gm*ºC) condensing: lh: massFlowRate: SimplePhaseChange latentHeat: Properties gm/sec Equation cal/gm</p><p> mRate: bx_steam_out:H2O</p><p> massFlowRate: Note: Underline = gm/sec {Qrate=mRate*lh)} these are invariant r1: properties of all equivalent uses of H2O {r1=r2} Qrate: water_out:H2O r2: massFlowRate: boiling: lh: gm/sec Constraints SimplePhaseChange Value Equation Constraint Bindings mRate: callouts heat_in:Heat</p><p> dQ/dt>:cal/ sec</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 85 Distiller Example – Heat Balance Results</p><p> table IsobaricHeatBalance1 [Results of Isobaric Heat Balance] Satisfies «requirement» specific heat cal/gm-°C 1 WaterSpecificHeat latent heat cal/cm 540 Satisfies «requirement» WaterHeatOfVaporization</p><p>Satisfies «requirement» WaterInitialTemp water_in hx_water_out bx_water_in bx_steam_out water_out mass flow rate gm/sec 6.75 6.75 111 temp °C 20 100 100 100 100</p><p> dQ/dt cooling water cal/sec 540 dQ/dt steam-condensate cal/sec 540 Note: Cooling water condenser efficency 1 needs to have 6x flow of steam! heat deficit 0 Need bypass between hx_water_out and dQ/dt condensate-steam cal/sec 540 bx_water_in! boiler efficiency 1 dQ/dt in boiler cal/sec 540</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 86 Distiller Example – Activity Diagram: Updated DistillWater</p><p> act [activity] DistillWater [Revised Swimlane Diagram]</p><p>«allocate» «allocate» «allocate» «allocate» loPress:Residue hx1:HeatExchanger feed:Vave bx1:Boiler drain:Valve</p><p>«continuous» coldDirty:H2O [liquid] «continuous» «continuous» a4:DrainResidue recovered:Heat steam:H2O [gas] «continuous» pure:H2O [liquid] «streaming» «streaming» a1:HeatWater a3:CondenseSteam «streaming» hiPress:Residue a2:BoilWater «continuous» hotDirty:H2O «continuous» hotDirty2:H2O [liquid] «continuous» hotDirty1:H2O [liquid] [liquid] «continuous» external:Heat ShutDown a5:DivertFeed</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 87 Distiller Example – Internal Block Diagram: Updated Distiller</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 88 Distiller Example – Use Case and Sequence Diagrams seq OperateDistiller [Operational Sequence]</p><p>«<a href="/tags/Actor_(UML)/" rel="tag">actor</a>» «block» :User :Distiller uc DistillerUseCases [Operate Distiller]</p><p>TurnOn Operate Distiller Distiller</p><p>PowerLampOn User</p><p>OperatingLampOn</p><p> loop alt</p><p>LevelHighLampOn</p><p>DrainingLampOn</p><p>LevelLowLampOn</p><p>TurnOff</p><p>PowerLampOff 11 July 2006 Copyright © 2006 by Object Management Group. 89 Distiller Example – Internal Block Diagram: Distiller Controller</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 90 Distiller Example – State Machine Diagram: Distiller Controller</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 91 Sample - Artisan Tool 11 July 2006 Copyright © 2006 by Object Management Group. 92 OOSEM – ESS Example System Development Process</p><p>System Modeling Activities</p><p>Component Modeling Activities</p><p>Integrated Product A Recursive V process Development (IPD) is that can be applied to essential to improve multiple levels of the communications system hierarchy</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managon 2000ement – 2003 Group. & INCOSE 2004-2006 94 Systems Modeling Activities - OOSEM</p><p>Analyze Needs Major SE Development Activities</p><p>•Mission use cases/scenarios •Enterprise model Define System Requirements</p><p>•System use cases/scenarios •Elaborated context •Req’ts diagram Define Logical Optimize & Architecture Evaluate Alternatives •Logical architecture</p><p>Synthesize •Engr Analysis Models Physical •Trade studies Validate & Architecture Verify System •Node diagram •HW, SW, Data architecture •Test cases/procedures Common Subactivities</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managon 2000ement – 2003 Group. & INCOSE 2004-2006 95 Enhanced Security System Example</p><p>• The Enhanced Security System is the example for the OOSEM material –Problem fragments used to demonstrate principles –Utilizes Artisan RTS™Tool for the SysML artifacts</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managon 2000ement – 2003 Group. & INCOSE 2004-2006 96 ESS Requirements Flowdown</p><p> req [package] ESS Requirements Flowdown «trace» «document» ESS Enterprise Models Market Needs</p><p>«trace»</p><p>«requirement» «satisfy» ESS System Models ESS System Specification id# = SS1 «refine»</p><p>«requirement» IntruderDetection «requirement» R111 id# = SS102 txt = System shall id# = SS111 «deriveReqt» detect intruder entry «satisfy» and exit ...</p><p>ESS Logical Design Models «requirement» «refine» satisfiedBy ESS Logical Requirements Entry/Exit Subsystem verifiedBy id# = LR1 Entry/Exit Detection Test «satisfy» «deriveReqt»</p><p>«requirement» ESS Allocated Design ESS Allocated Requirements Models id# = AR1 «refine»</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managon 2000ement – 2003 Group. & INCOSE 2004-2006 97 Operational View Depiction</p><p> bdd [package] Enterprise (As Is)</p><p>Central Monitoring Station As-Is</p><p>Comm Network</p><p>Residence</p><p>Dispatcher Intruder</p><p>Police</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managon 2000ement – 2003 Group. & INCOSE 2004-2006 98 ESS Enterprise As-Is Model</p><p> bdd [package] ESS Enterprise (As Is) Domain As-Is</p><p>* * «enterprise» Residence Enterprise As-Is</p><p>1</p><p>Customer As-Is Intruder</p><p>«system» «external» «external» Sec Sys Comm Network Emergency Services As-Is</p><p>1 * Site Installation Central Monitoring As-Is Station As-Is</p><p>Dispatcher Police</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managon 2000ement – 2003 Group. & INCOSE 2004-2006 99 ESS Operational Enterprise To-Be Model</p><p> bdd [package] ESS Enterprise (To Be) Domain «enterprise» * * To-Be ESS Operational Enterprise</p><p>«moe» OperationalAvailability = {>.99} «moe» MissionResponseTime = {<5 min} Intruder «moe» OperationalCost = {TBD} «moe» CostEffectiveness «external» MonitorSite () 1..* 1..* Emergency Services DispatchEmergencyServices () * Protected Site ProvideEmergencyResponse () Assess Report () Report Update () Customer Dispatch Police ()</p><p>* «system» «external» ESS Comm Network *</p><p>* Responder * «external» Dispatcher «external» Property Physical Environment</p><p>«external» «external» Single-family Residence «external» Business Multi-family Residence Police Fire Paramedic</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 100 System Use Cases - Operate</p><p> uc [package] System Use Cases</p><p>Activate/Dea- ctivate «include» Operate</p><p>«include» «extend»</p><p>Respond Monitor Site</p><p>Respond to Respond to Respond to Break-In Fire Medical</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 101 System Scenario: Activity Diagram Monitor Site (Break-In) act Monitor Site (break in) «actor» «system» «external» Intruder ESS Emergency Services</p><p>System On Enter Property Status Update System Off</p><p>DetectEntry</p><p>ValidateEntry</p><p>Validated Entry</p><p>Conduct Theft</p><p>[Alert] GenerateAlarm ReportEntry</p><p>Exit Property Assess Report</p><p>InternalMonitor</p><p>[Alert]</p><p>DetectExit</p><p>Report Update Dispatch Police</p><p>ReportExit [Alert]</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 102 ESS Elaborated Context Diagram</p><p> ibd [domain] Domain-To-Be</p><p>: EmergencyServicesIn «external» «system» : Emergency Services : EmergencyServicesOut : ESS «perf» Power = {<100 watts} «perf» Reliability «phys» SiteInstallDwg «store» EventLog : CustomerOut : CustomerIn «store» SystemState DetectEntry () : Customer DetectExit () ReportEntry () ReportExit () GenerateAlarm () ValidateEntry () : AlarmSignal : IntruderSignal InternalMonitor () DetectFire () : Intruder DetectMedicalEmergency () RequestUserID () «external» ValidateUserID () : Property : Power : Door Input : Window Input SetTimer () ActivateSystem () ProtectPrivacy () Status Update () «external» DetectFault () : Physical Environment : Envronmental_In</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 103 ESS Logical Design – Example Subsystem</p><p> subsystem Entry/Exit Subsystem ibd [subsystem]Entry/Exit Subsystem</p><p>: Door Input m+n : SensedEntry «logical» «logical» : Entry/Exit Monitor : Entry Sensor : Door Input : SensedExit : Entry/Exit Alert Status : Window Input</p><p> m+n «logical» : Window Input : Event Monitor «logical» : Alert Status : Exit Sensor «store» : Event Log</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 104 ESS Logical Design (Partial)</p><p> ibd [system] ESS</p><p>: AlarmSignal «logical» : Window Input : Alarm Generator «logical» : Entry Sensor : SensedEntry : Door Input : AlarmCmd</p><p>: BIT «logical» : Entry/Exit Monitor : Alert Status «logical» : Alarm I/F</p><p>: Window Input : Entry/Exit Alert Status «logical» : SensedExit : Exit Sensor «logical» : Event Monitor : Door Input «logical» : Alert Status : Emergency Monitor «store» : Event Log : BIT : EmergencyData</p><p>«logical» : BIT «logical» «logical» : Perimeter Sensor : Fault Mgr : Emer Serv I/F : Emergency ServicesOut</p><p>: BIT : Fault</p><p>: FaultReport : Lamp «logical» «logical» «logical» : Environment Sensor : Customer Output Mgr : Customer I/F</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 105 ESS Allocation Table (partial)</p><p>• Allocating Logical Components to HW, SW, Data, and Procedures components Logical Components</p><p>Entry Perimeter Entry/Exit Event Site Customer Customer System Alarm Type Sensor Exit Sensor Sensor Monitor Monitor Comms I/F Event Log I/F Output Mgr Status Fault Mgr Generator Alarm I/F</p><p>«software» Device Mgr X</p><p>SF Comm I/F X</p><p>User I/F X</p><p>Event Mgr XX</p><p>Site Status Mgr X</p><p>Site RDBMS XX</p><p>CMS RDBMS X</p><p>«data» Video File X</p><p>CMS Database X</p><p>Site Database XX</p><p>«hardware» Optical Sensor XX</p><p>DSL Modem X</p><p>User Console X</p><p>Video Camera X</p><p>Physical Components Physical Alarm X</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 106 ESS Deployment View</p><p>ESS ibd [system] ESS «node» «node» * : Central Monitoring Station : MF Residence Installation «hardware» «hardware» : Help Desk Client : Phone Lines «node» * «hardware» «hardware» : Business Installation : MS LAN «external» : Application Server : Comm Network allocatedFrom «software» MS Comm I/F «internal actor» : SF Residence Installation * «software» MS Event Monitor : Help Desk Operator «software» PS Report Mgr «hardware» «software» PS Request Mgr : PS Comm «software» Site Interface Mgr * 2 I/F «hardware» «hardware» «hardware» : Optical Sensor : Video Camera : DSL Modem</p><p>«hardware» : DB Server «hardware» «hardware» : Site Processor : NW Hub «hardware» allocatedFrom : Alarm «hardware» «software» CMS RDBMS allocatedFrom allocatedFrom «hardware» : CM Server «data» CMS Database «software» Device Mgr «software» SF Comm I/F : Video Server «software» Event Mgr allocatedFrom «software» Site Config Mgr «software» S/W Distrib Mgr «software» Site RDBMS «software» System CM «software» Site Status Mgr «software» User I/F «software» User Valid Mgr 2 «hardware» : DVD-ROM Drive allocatedFrom «data» Site Database «hardware» «hardware» : Site Hard Disk : User Console allocatedFrom «data» Site Database</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 107 ESS Parametric Diagram To Support Trade-off Analysis</p><p> par [block] EnterpriseEffectivenessModel {CE= Sum(w1*u(OA)+w2*u } «moe» (MRT)+w3*u(OC)) MissionResponseTime</p><p> of1 : ObjectiveFunction</p><p>CE «moe» MRT «moe» OperationalAvailability CostEffectiveness OA OC</p><p>«moe» OperationalCost</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 108 Entry/Exit Test Case</p><p> sd Entry/Exit Detection Test</p><p>Description «testComponent» «sut» «sut» «sut» «sut» :IntruderEmulator «hardware» «hardware» «hardware» «hardware» Door[1] Window[4] :Site Processor :DSL Modem /:Optical Sensor /:Optical Sensor</p><p> seq seq Intruder enters through front Enter door Door sensor detects entry : SensedEntry New alert status sent to central IntruderEntry : system Alert Status Intruder leaves through lounge Exit window Window sensor detects exit : SensedExit Changed alert status sent to Intruder Exit : central system Alert Status</p><p>11 July 2006Copyright Copyright© Lockheed © 2006 Martin by Corporati Object Managementon 2000 – 2003 Group. & INCOSE 2004-2006 109 OOSEM Browser View Artisan Studio™ Example</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 110 Copyright © Lockheed Martin Corporation 2000 – 2003 & INCOSE 2004-2006 SysML in a Standards Framework Systems Engineering Standards Framework (Partial List)</p><p>Process Standards EIA 632 ISO 15288 IEEE 1220 CMMI</p><p>Architecture FEAF DoDAF MODAF Zachman FW Frameworks Implemented Modeling Implemented SADT Methods HP OOSE SADT Other By Tools</p><p>Modeling & IDEF0 SysML UPDM HLA MathML Simulation Standards System Modeling Simulation & Analysis</p><p>Interchange & <a href="/tags/Metamodeling/" rel="tag">Metamodeling</a> MOF XMI STEP/AP233 Standards</p><p>Data Repository</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 112 ISO/IEC 15288 System Life Cycle Processes</p><p>Enterprise Processes Project Processes Technical Processes</p><p>5.3.2 5.5.2 Stakeholder Reqts Enterprise Environment 5.4.2 Definition Process Management Process Project Planning Process 5.5.3 5.3.3 Reqts Analysis Process Investment 5.4.3 Management Process Project Assessment 5.5.4 Process 5.3.4 Architectural Design Process System Life Cycle 5.5.5 Processes Management 5.4.4 Implementation Process Project Control Process 5.3.5 5.5.6 Quality Integration Process Management Process 5.4.5 5.5.7 Decision-Making Process 5.3.6 Verification Process Resource Management Process 5.4.6 5.5.8 Risk Management Transition Process Process Process 5.5.9 Agreement Processes Validation Process 5.4.7 5.5.10 Configuration Management 5.2.2 Operation Process Process Acquisition Process 5.5.11 5.4.8 Maintenance Process 5.2.3 Information Management Process 5.5.12 Supply Process Disposal Process</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 113 Standards-based Tool Integration with SysML</p><p>Systems Modeling Other SE Engineering Tool Tools Model/Data Interchange 2 SV4 OV</p><p>• ..... • ..... - • ..... • - - AP233/XMI - - - - OV7 TV2 - - •..... • - •..... • •..... ------AP233/XMI ------</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 114 Participating SysML Tool Vendors</p><p>• Artisan •EmbeddedPlus –3rd party IBM vendor • Sparx Systems •Telelogic (includes I-Logix) •Vitech</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 115 UML Profile for DoDAF/MODAF (UPDM) Standardization</p><p>•Current initiative underway to develop standard profile for representing DODAF and MODAF products –Requirements for profile issued Sept 05 –Final submissions expected Dec ‘06 •Multiple vendors and users participating •Should leverage SysML</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 116 Transitioning to SysML Using Process Improvement To Transition to SysML</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 118 Integrated Tool Environment</p><p>Project Management</p><p>SoS / DoDAF / Business Process Modeling</p><p>System Modeling SysML</p><p>Software Modeling Hardware Modeling</p><p>CM/DM Product Data Management Management Requirements UML 2 VHDL, CAD, .. Validation & Verification Specialty Engineering Analysis Engineering Performance Analysis</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 119 Summary and Wrap up Summary</p><p>•SysML sponsored by INCOSE/OMG with broad industry and vendor participation •SysML provides a general purpose modeling language to support specification, analysis, design and verification of complex systems –Subset of UML 2 with extensions –4 Pillars of SysML include modeling of requirements, behavior, structure, and parametrics •OMG SysML Adopted in May 2006 •Multiple vendor implementations announced •Standards based modeling approach for SE expected to improve communications, tool interoperability, and design quality </p><p>11 July 2006 Copyright © 2006 by Object Management Group. 121 References</p><p>•OMG SysML website – http://www.omgsysml.org •UML for Systems Engineering RFP –OMG doc# ad/03-03-41 •UML 2 Superstructure –OMG doc# formal/05-07-04 •UML 2 Infrastructure –OMG doc# ptc/04-10-14</p><p>11 July 2006 Copyright © 2006 by Object Management Group. 122</p> </div> </div> </div> </div> </div> </div> </div> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.1/jquery.min.js" integrity="sha512-aVKKRRi/Q/YV+4mjoKBsE4x3H+BkegoM/em46NNlCqNTmUYADjBbeNefNxYV7giUp0VxICtqdrbqU7iVaeZNXA==" crossorigin="anonymous" referrerpolicy="no-referrer"></script> <script src="/js/details118.16.js"></script> <script> var sc_project = 11552861; var sc_invisible = 1; var sc_security = "b956b151"; </script> <script src="https://www.statcounter.com/counter/counter.js" async></script> <noscript><div class="statcounter"><a title="Web Analytics" href="http://statcounter.com/" target="_blank"><img class="statcounter" src="//c.statcounter.com/11552861/0/b956b151/1/" alt="Web Analytics"></a></div></noscript> </body> </html>