INCOSE Evaluation: Systems Modeling Language (SysML)

INCOSE Evaluation: Systems Modeling Language (SysML)
SysML Submission Team (SST) 13, 15, 20 December 2005 SST Chair: Sanford Friedenthal

Topics Introduction MDSD Actions Specification Updates
Specification Highlights Language Architecture Compliance Approach Structural Constructs Behavioral Constructs Cross-cutting Constructs Appendixes Sample Problems HSUV Example from Appendix B Distiller Example (response to D. Oliver example) Summary

Introductory Statement
Two competing specifications* submitted to the OMG on November 14, 2005 from: SysML Submission Team (SST) chaired by S. Friedenthal SysML Partners chaired by C. Kobryn This highlights updates and selected features of the SST SysML Specification v0.98 (ad/ ) A vote for adoption should occur at the next OMG meeting the week of February 13, 2006 * Available at

SysML is Critical Enabler for Model Driven SE
What is SysML? A graphical modeling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 a UML Profile that represents a subset of UML 2 with extensions Supports the specification, analysis, design, verification and validation of systems that include hardware, software, data, personnel, procedures, and facilities Supports model and data interchange via XMI and the evolving AP233 standard (in-process) SysML is Critical Enabler for Model Driven SE

SysML Background UML for SE RFP issued – 28 March 2003
SysML Partners Kickoff meeting – 6 May 2003 Chaired by S. Friedenthal and C. Kobryn 3rd revised submission (v0.9) to OMG – 10 Jan 2005 Addendum stereotypes chapter – 30 May 2005 SysML Submission Team announced split from SysML Partners on August 30, 2005 to finalize the specification Differences in process, issue prioritization and resolutions Both teams started from a common baseline V0.9 plus Addendum Profiles chapter Blocks/Parametrics approach Satisfied most of the requirements of the UML for SE RFP Submitted revised submissions on November 14, 2005 with planned vote for adoption at next OMG meeting in Feb ‘06

SysML Submission Team (SST)
Members Industry & Government American Systems, BAE SYSTEMS, Boeing, EADS-Astrium, Eurostep, Lockheed Martin, NIST, oose.de, Raytheon, THALES Vendors Artisan, EmbeddedPlus, IBM, I-Logix, Mentor Graphics, Sparx Systems, Vitech Corp Neutral Collaborators Deere & Company Georgia Institute of Technology NASA/JPL INCOSE, AP233 SST broad based team of multiple end-users and tool vendors

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

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

SST Design Principles (Section 4.1)
Requirements driven SysML is intended to satisfy the requirements of the UML for SE RFP. UML reuse SysML reuses UML wherever practical to satisfy the requirements of the RFP, and when modifications are required, they are done in a manner that strives to minimize changes to the underlying language. Consequently, SysML is intended to be relatively easy to implement for vendors who support UML 2 or later revisions. UML extensions SysML extends UML as needed to satisfy the requirements of the RFP. The primary extension mechanism is the UML 2 profile mechanism as further refined in the SysML Profiles & Model Libraries chapter of this specification. Partitioning The package is the basic unit of partitioning in this specification. The packages partition the model elements into logical groupings which minimize circular dependencies among them. Layering SysML packages are specified as an extension layer to the UML metamodel. Interoperability SysML inherits the XMI interchange capability from UML. SysML is also intended to be supported by the ISO AP233 data interchange standard to support interoperability among other engineering tools.

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

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, …

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

Evaluating the Specifications
Specifications and RFP available at: Specification review guidance Use the SST Highlights & Comparison Matrix and the following slides to help understand the differences between the submissions Available on INCOSE Evaluators Site or request from SST Chair Review the following chapters in the SST Introduction Language architecture and Compliance Review the following subsections in each SST chapter Overviews Diagram elements (look for completeness) UML extensions (targeted to tool vendors / language implementers) Usage examples (consistent with Appendix B sample problem) Review the SST Sample Problem in Appendix B Provides overview of how language can be used Review the following appendixes as time permits Diagrams Non-Normative Extensions Model Interchange

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 Compliant with UML metamodel Verifiable

Language Feature Summary (Refer to SST Highlights & Comparison Matrix 051201-revb)
No. Language Feature Impact/Priority RFP Evaluation Criteria 1 2 3 4 5 6 6a 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Language Architecture Compliance Views & Viewpoints Value Types, Units & Dimensions Property Specific Types Instance Diagram Deep Nesting Item Flows Flow Port Features Flow Port Compatibility Rules Parametric Diagram Timing Diagram Allocation Types Allocate Activity Partition Requirement Callout Notation Refine Requirements Relationship Containment Symbol Diagram Conventions MOE’s & Objective Function Requirements Classification BNF Notation Chapter Updates H M L 6.8.2, 6.8.8, 6.8.11 6.8.5 6.8.2, 6.8.3 6.8.1 6.8.4, (RFP reqt 6.8.4) 6.8.1, 6.8.1, 6.8.4, 6.8.1, 6.8.2 6.8.1, 6.8.3 6.8.4, (RFP reqt ) 6.8.1, 6.8.5 6.8.4 6.8.3, 6.8.4 6.8.2 6.8.2, 6.8.9 Selected Language Features To Contrast Submissions

SysML SST Specification Outline
Preface Part I of RFP Response Part II of RFP Response Part III of RFP Response Part I – Introduction Scope Normative references Additional information Language Architecture Compliance Language Formalism Part II – Structural Constructs Model Elements Blocks Ports and Flows Parametrics Part III – Behavioral Constructs Activities Interactions State Machines Use Cases Part IV – Crosscutting Constructs Allocations Requirements Profiles & Model Libraries Part V Appendices Diagrams Sample Problem Non-Normative Extensions Model Interchange (AP233 & XMI) Requirements Traceability Terms and Definitions BNF Diagram Syntax Definitions

MDSD Recommendations & 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 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.

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)

MDSD Recommendations & Response (cont.)
Include a model library for Assemblies that includes PhysicalAssembly (properties: supplier, modelNumber, serialNumber, lotNumber) RESPONSE: Example included in Fig in Profiles & Model Libraries chapter. Harmonize concepts, constructs, and usage examples for Allocations make implicit Allocations explicit RESPONSE: Made swim lanes explicit form of allocation (Fig 15-2, Section ) test usability of multiple UI options via vendor prototypes RESPONSE: Multiple UI options explored and incorporated including allocation/requirement compartments, callout, and tabular formats (refer to diagram extensions in and ) Encourage and promote vendor SysML prototypes at INCOSE Symposium vendor exhibits RESPONSE: Multi-vendor prototype demonstrations at INCOSE Symposium in July ‘05 at MDSD and on exhibitor floor

Specification Updates

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

Specification Updates
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

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

Specification Updates Technical Content Change Summary
Refer to Slide 15: No. 21 Specification Updates Technical Content Change Summary Redefined Language Architecture and Compliance approach Structure Unified class and assembly into blocks* Specified property subclasses for part, reference, and value Provided mechanism for part specific subclasses to support design values Replaced quantity with value type, units, dimensions, and distributions Redefined ports to include UML (i.e. client-server) ports and flow ports * Refined item flow semantics and notation Refined parametric notation and semantics (constraint blocks and properties) Updated View/Viewpoint to be consistent with IEEE 1471 Updated diagram taxonomy to include package & instance diagram Behavior Refined/updated activity extensions* Included protocol state machines Cross cutting Refined requirements semantics Refined allocation semantics Harmonized callout notation between requirements and allocations Updated profiles per RTF * Appendixes Updated diagram frames & headings conventions Significantly elaborated sample problem appendix and integrated with usage examples in chapters Refined non-normative extensions for EFFBD profile*, requirements subclasses, and measures of effectiveness (MOE’s)* Refined approach for XMI and AP233 harmonization Updated requirements traceability matrix in Appendix E Identified terms for glossary Added BNF Diagram Syntax Definition appendix * Work started prior to split on Aug 30, 2005

SST Specification Highlights

Specification Highlights
Language Feature # (From Slide 15) Specification Topic 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

Language Architecture

Relationship Between SysML and UML
UML4SysML SysML Profile

SysML Diagram Taxonomy

SysML v0.9 Language Architecture
Issues Reuse of UML was imprecisely defined Only partial list of required meta-classes UML2 Profiles chapter not clear on specification and application of UML subset Profile structure was confusing Contained sub-packages with no extensions Package partitioning was inconsistent with chapters Not tied in with compliance Impacts XMI and Interoperability Ability to integrate UML applications with SysML Ambiguity affects vendor ability to implement

Language Architecture Approach
Worked with UML2 RTF on profiles approach and used to define language architecture Create UML2 Subset using merge Reference this subset from the SysML profile Define fine-grained restrictions on features in constraints Apply reuse at package level vs metaclass level Merge only works at package level Easier to ensure that subset is well-formed with no dangling references Profile structure redefined Consistent with SysML chapter structure Only introduce sub-profile if chapter contains extensions

SysML Profile Retains UML Integrity
Reuse of UML 2 – UML4SysML SysML Profile Retains UML Integrity

Modular & Cohesive Package Structure
SysML Profile Package Modular & Cohesive Package Structure

Applying SysML Profile to a User Model

SysML Compliance

V0.9 Compliance Issues Impact
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

Compliance Approach Compliance Levels
Introduce compliance levels into UML4SysML Strict subsets of UML compliance levels (L1, L2, L3) Further compliance levels for SysML Profile Each sub-profile is separate compliance level Asserts minimal compliance on UML4SysML level Reuse UML definitions of compliance Abstract syntax Concrete syntax Compliance Statements No Partial (requires feature support statement) Yes Compliance approach allows vendor to clearly state compliance and users to assess compliance

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

Feature Support Statement
Compliance Level Detail Abstract Syntax Concrete Syntax Semantics UML4SysML::Level 2 StateMachines::BehaviorStateMachines Note (1) YES Note(2) SysML::Blocks Block Note (3) 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

Structural Constructs

Structural Constructs
Model Elements Blocks Ports and Flows Parametrics

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

Organizing the User Model
Package Diagram Used to Organize the Model

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

IEEE 1471 IEEE 1471 (section 5.3) prescribes that a viewpoint contains: a) A viewpoint name b) The stakeholders to be addressed by the viewpoint c) The concerns to be addressed by the viewpoint d) The language, modeling techniques, or analytical methods to be used in constructing a view based upon the viewpoint e) The source, for a library viewpoint (the source could include author, date, or reference to other documents, as determined by the using organization)

SST View/Viewpoint Viewpoint as a stereotyped class
Relationship between Viewpoints View realizes a viewpoint

Performance View Example

trade study or analysis report
Rationale Rationale can link to a trade study or analysis report Rationale can be attached to any Model Element or Relationship to Capture decisions

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

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

Power Subsystem Breakdown
Block Definition Diagram Used to Specify System Hierarchy and Classification

Power Subsystem IBD Part Enclosing Block Connector Internal Block Diagram Used to Specify Interconnection Among Parts in Context of Enclosing Block

Property Subclasses Property is a structural feature of a block which is further sub-classed in SysML Part property aka. part (typed by a block) Usage of a block in the context of the enclosing block Example - right-front:wheel Value property (typed by value type) Defines a value with units, dimensions, and probability distribution Example - tirePressure:psi {distribution=Uniform (min=27,max=29)} Reference property (typed by a block) A part that is not owned by the enclosing block Example - logical interface between 2 parts

Simple Example of Deep Nesting Connecting a Tire to a Road
No need for modeler to specify intermediate connections ibd block Automotive Domain vehicle : HSUV env : Environment 2 front : Tire road : Road 2 rear : Tire Deep Nesting Provides Intuitive Modeling of Physical Systems and does not Impose Process

Supports different values & distributions for each part
Design Values Example bdd Car Design 1 2 Car Wheel 1 front 2 tyrePressure : psi back SUV ibd SUV [] Indicates part-specific block «part» 2 back : [Wheel] Properties tyrePressure : psi {distribution=Uniform (min=27,max=29)} Supports different values & distributions for each part «part» 2 front : [Wheel] Properties tyrePressure : psi {distribution=Uniform (min=25,max=27)} Design Values Ease Ability to Specify Different Values/Distributions on Parts in Same Context

Units and Dimensions Units Tied Explicitly to Dimensions «block»
ins [package] SI Units «block» second:Unit time:Dimension bdd [package] SI Unit Types s «value» unit=second dimension=time bdd [package] Objects values t1:s t2:s Obj Units Tied Explicitly to Dimensions

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

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) ….

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

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

Ports Approach 2 Distinct Port Types that Support
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

FlowPorts Additional considerations FlowPorts Specification
Simple (natural) way for SEs to specify I/O via the port Address the common case of atomic FlowPorts Allow both signal flow and data/block instance flow FlowPorts Specification I/O is specified using an interface stereotyped FlowSpecification FlowSpecification consists of properties stereotyped FlowProperties FlowProperty has a direction attribute: in, out, inOut FlowProperties can be typed by ValueTypes, Block, and Signals isConjugate promotes reuse of flowSpecifications Atomic FlowPorts It is common that a FlowPort flows a single item type In this case the port is directly typed by the item type (Block or Value) Direction property specify the direction Compatibility rules on ports facilitate interface compatibility

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

Power Subsystem IBD Specifying Interfaces on an IBD
Item flow Flow port Connector Client server port Specifying Interfaces on an IBD in Terms of Connectors, Ports and Flows

Parametrics & MOE’s/Objective Functions

Parametrics Used to express constraints (equations) between value properties Provides support to engineering analysis (e.g. performance, reliability, etc) Reusable (e.g. F=m*a is reused in many contexts) Non-causal (i.e. declarative statement of the invariant without specifying dependent/independent variables) Constraint block defined as a simple extension of block Packages UML constraint so they are reusable and parameterized Constraint and constraint parameters are specified Expression language can be formal (e.g. MathML, OCL …) or informal Computational engine is defined by applicable analysis tool and not by SysML Parametric diagram represents the usage of the constraints in an analysis context Binding of constraint usage to value properties of blocks (e.g. vehicle mass bound to F= m * a) Can use nested notation or dot notation MOE’s and objective functions integrated with Parametrics to support trade studies and engineering analysis Parametrics Scalability & Integration with Engr Analysis Validated by Georgia Tech

Defining Vehicle Dynamics
Defining Reusable Equations for Parametrics

Evaluating Vehicle Dynamics
Using the Equations in a Parametric Diagram to Constrain the Value Properties

Evaluating Measures of Effectiveness
MOE’s and objective function provide flexible support for trade study analysis that is fully integrated with parametrics

Constraint Blocks - Comparison of Block-based vs
Constraint Blocks - Comparison of Block-based vs. Collaboration-based approach Concrete Syntax More notational changes to default collaboration notation required to support chosen Constraint Block notation Abstract Syntax Additional abstract syntax required for deep-nested bindings Need to relax UML Collaboration constraints in order to support deep-nested bindings CollaborationUse does not support inheritance or redefinition Semantics Constraint Blocks can denote objects to represent equations with state Collaboration Use cannot be a defining feature of a slot, so cannot build instance specification hierarchy for blocks with constraints Connectors can specify multiplicities on bindings to multi-valued parameters or properties Blocks Based Approach Retains Structural Integrity and Simplifies Language

Behavioral Constructs

Behavioral Constructs
Activities Interactions State Machines Use Cases

Activities

Activities Activities used to specify flow of I/O and control
Input/Output represented by object node/pins that are typed by blocks External I/O called a parameter Control flow represent enabling of activity Control constructs include decision, merge, fork, join, initial node, activity final, flow final SysML extensions to Activities Alignment of activities with EFFBD Non normative appendix specifies specific execution rules for EFFBD support Does not explicitly support replication and resources Support for continuous flow modeling

SysML EFFBD Profile Refer to Appendix C.1 for Details & Execution Rules Aligning SysML with Proven Systems Engineering Techniques

Distiller Example Provided by D. Oliver
Energy to condense Pure water Dirty water @ 100 deg C Dirty water @ 20 deg C Steam Condense steam and Heat Dirty water To 100 deg C Boil Dirty water and Drain Residue Residue Heat to Dirty water Disposed residue Heat to Boil water

Distill Water Activity Diagram (Initial)
Representing Distiller Example in SysML Using EFFBD Profile

Distill Water Activity Diagram (Continuous Flow Modeling)
Representing Distiller Example in SysML Using Continuous Flow Modeling

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

Black Box Interaction (Drive)
UML 2 Sequence Diagram More Scalable by Supporting Control Logic and Reference Sequences

Black Box Sequence (StartVehicle)
References Lifeline Decomp For White Box Interaction Simple Black Box Interaction

White Box Sequence (StartVehicle)
Decomposition of Black Box Into White Box Interaction

Trial Result of Vehicle Dynamics
Lifeline are value properties Typical Example of a Timing Diagram

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

Operational States (Drive)

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

Top Level Use Cases

Operational Use Cases

Cross-cutting Constructs

Cross-cutting Constructs
Allocations Requirements Profiles & Model Libraries

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

Different Allocation Representations (Tabular Representation Not Shown)
Explicit Allocation of Activity to Swim Lane Allocate Relationship Compartment Notation Callout Notation

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) Able to specify constraints on what design elements can satisfy the requirement (refer to Appendix C.2) Stereotype of class (abstract) without instances Requirements containment used to specify requirements hierarchy as a collection of requirements (e.g., a specification) SST uses cross hairs notation vs black diamond composition to be consistent with containment semantics Requirements relationships based on subclasses of dependency Derive, Satisfy, Verify, Refine, ..

Dependency Relationship Is New Concept for Some SE’s
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

Example of Derive/Satisfy Requirement Dependencies
Supplier Client Supplier Client Arrow Direction Opposite Typical Requirements Flow-Down

Requirements & Allocations Alignment
V0.9 Issue Inconsistent concrete syntax for cross-cutting relationships Allocations used compartments/callouts, requirements did not Limitations in displaying requirement relationships Requirements needed to be shown on same diagram as target of relationship –> cluttered diagrams Requirements couldn’t be shown on internal block diagrams. Basis for cross-cutting relationships seemed inconsistent, and needed to be unified Requirements relationships were built on Trace Allocation relationship was built on Usage

Representing Requirements and Allocation Relationships
Requirements callout notation Allocations callout notation Consistent and Compact Crosscutting Notations

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

Stereotypes Defining the Stereotype Applying the Stereotype

Appendixes

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

Appendix A Diagrams

Diagram Appendix A Provides general guidelines for the use of diagrams
Diagram headings Naming of diagrams Diagram descriptions Capturing information about diagrams Diagram usages Specifying unique diagram kinds Other general guidelines (e.g. tabular representations, use of rake symbol, ..)

Application of Diagram Guidelines Example
A Diagram Description (refer to App A) Diagram Heading Names (refer to App A)

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

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

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 AP233 Both file and API-based SysML-AP233 interchange approaches are supported based on alignment with similar concepts in AP233 Provides gateway to model repositories that are based on schema in use by other engineering disciplines (e.g, mechanical - MCAD) user domains (e.g, DoD architectures – DoDAF/CADM) Supports INCOSE’s vision for model driven systems engineering

Appendix 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 ( ) 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 ( ) not fully implemented per EFFBD semantics

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

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

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

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

Setting up the User Model

Organizing the User Model

Setting the Context

Top Level Use Cases

Operational Use Cases

Black Box Interaction (Drive)

Operational States (Drive)

Black Box Sequence (StartVehicle)

White Box Sequence (StartVehicle)

Requirements Breakdown

Requirements Derivation

Reqts Refinement/Verification

Requirements Tables & Trees

Context/Enterprise Breakdown

System Breakdown

System Internal Block Diagram

Power Subsystem Breakdown

Power Subsystem IBD

Test Result Instance

Power Subsystem Interface Defn

Fuel System Definition

Fuel Flow Parametrics

Fuel Subsystem Design

Overall Analysis Context

Performance View Definition

Evaluating Measures of Effectiveness

Evaluating Fuel Economy

Evaluating Vehicle Dynamics

Defining Vehicle Dynamics

Trial Result of Vehicle Dynamics

“ProvidePower” Functional Decomp

“ProvidePower” Behavior & Allocation

Multiple Allocations shown on IBD

Allocation Table w/Allocation Type

David Oliver 12/7/05 An example to raise questions
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.

Distiller Example (as provided by D. Oliver)
Energy to condense Pure water Dirty water @ 100 deg C Dirty water @ 20 deg C Steam Condense steam and Heat Dirty water To 100 deg C Boil Dirty water and Drain Residue Residue Heat to Dirty water Disposed residue Heat to Boil water The ovals in the figure are I/O in AP233, items in CORE and I believe object nodes in the submissions.

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?

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?

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?

Response to Dave’s Example Distiller System

Distiller System – Package Overview
Organizing the Model

Units Library Defining the Units

Distill Activity Decomposition and Types of Flows
Behavior Breakdown Distill Activity Decomposition and Types of Flows

H20 States

Distill Water Activity Diagram (Initial)
Representing Distiller Example in SysML Using EFFBD Profile

Distill Water Activity Diagram (Continuous Activity Modeling)
Representing Distiller Example in SysML Using Continuous Flow Modeling

Distill Water – Swim Lane Diagram Allocated Behavior
Allocating the Activities to Swim Lane that Represent Blocks

Distiller System Hierarchy (Top Level)
A Diagram Feature Provided by SST Submission (refer to App A) Describing the Distiller System and Its Components

Distiller Internal Block Diagram
Describing the Interconnection of Parts And the Item Flows Between Them

Distiller Internal Block Diagram (with Allocations)
Showing the Allocations from Activities and Object Nodes to Blocks and Item Flows

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

Parametric Diagram – Thermal Analysis (includes constraints on I/O)
Defining the Thermal Equations as Constraints on the Flow Properties

Analysis Results - Isobaric
Analysis Results Indicate Need for Modification to Existing Desgin

Behavior Breakdown - Revised
New Activity Required To Meet the Need

Swim Lane Diagram - Revised
New Activity Shown in Swim Lane Diagram

Distiller Internal Block Diag - Revised
Additional Item Flow Required To Support Change

Parametric Diagram – Thermal Analysis (Revised)
Revised Thermal Analysis To Support Change

Analysis Results – Non Isobaric Example
Update to Analysis Results

Summary

SST SysML Submission Satisfies Most Requirements in the RFP
Small number of remaining req’ts to be addressed along with user/vendor feedback in future revisions Critical Issues Resolved Multi-vendor implementations Our solution Architecturally sound & compatible with UML 2/ XMI Implementable by multiple vendors Meets the needs of SE’s Refer to Highlights and Comparison Matrix and these slides to contrast with SysML Partners submission

INCOSE Evaluation: Systems Modeling Language (SysML)

Similar presentations

Presentation on theme: "INCOSE Evaluation: Systems Modeling Language (SysML)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

INCOSE Evaluation: Systems Modeling Language (SysML)

Similar presentations

Presentation on theme: "INCOSE Evaluation: Systems Modeling Language (SysML)"— Presentation transcript:

Similar presentations

About project

Feedback