The Hybrid Sports Utility Vehicle (SUV) sample problem

This tutorial trail presents the SysML Hybrid Sports Utility Vehicle sample problem adapted from Annex B of the OMG SysML1.0 specification in the MagicDraw UML SysML Plugin (MD SysML). The purpose is primarily to demonstrate how to emulate the SysML sample problem in MD SysML - as well as identifying problem areas and power options specific to MD SysML - so it is highly annotated with Comments. Your first reference should always be the SysML1.0 specification.

Please start here.

The following Comment stereotypes are used to indicate material quoted from the SysML1.0 specification (and thus subject to the OMG SysML's copyright conditions):

<<SysML1.0>> text quoted from the main chapters of the SysML 1.0 specification

<<SysML1.0: sample>> text quoted from the Annex B Hybrid Sports Utility Vehicle sample problem

Special thanks also to Rick Steiner for his work on the original Hybrid SUV sample and for feedback.


Visit also:

Introduction to the Hybrid Sports Utility Sample project for MD SysML

Welcome to the SysML Hybrid Sports Utility Vehicle sample project tutorial trail for the MD SysML Plugin.

In the dowloadable sample project many of the diagram elements are navigable via MagicDraw's powerful hyperlinking
facility. There is also a convenient project <<sitemap>> of diagrams, which corresponds to this eSchool tutorial trail.

Navigation tips: for the MD SysML sample

Shows how MagicDraw UML diagram hyperlinks and stereotyped «next» Dependencies between diagrams are used to create the sample tutorial trail.


TIP: in MagicDraw UML you can assign a diagram as the default hyperlink of a symbol by just dragging the diagram from the browser onto the symbol ! This is a very powerful and convenient way to make your projects navigable.

Profiles used in the MD SysML sample

Did you know that the MagicDraw SysML plugin exploits MagicDraw UML's unique Domain Specific Language (DSL) customisation engine ?

Figure B.2 - Defining ValueTypes and Units to be used in the sample problem

Note that (unlike the specification Unit examples) Units here are given verbose names, rather than being named after the unit symbols.

Some ValueTypes are named after general kinds of quantities within the domain; these are used in the sample problem for parametric equations.

Other ValueTypes are named to indicate (as far as possible) the usual symbols of their Units; these are used in the specification examples for blocks with physical values.

WARNING: there are some inconsistencies in the use of ValueType and Unit names in the SysML1.0 specification examples.

Visit also:

Figure B.3 - Establishing Structure of the User Model using Packages and Views (Package Diagram)

A package diagram of the Hybrid SUV system.  The diagrams has been organised to roughly reflect, from left-right, a typical engineering process.There are also some additions to the sample, like the Configuration package exploring property-specific initial values for usages of Blocks as part.

Note that in MagicDraw UML packages can be hyperlinked to diagrams (such as SysML package diagrams).

Figure B.4 - Establishing the Context of the Hybrid SUV System using a User-Defined Context Diagram

Note that improved support for images within part shapes and background/overlay images is planned.

Figure B.5 - Establishing Top Level Use Cases for the Hybrid SUV

Note my recommendation that a UML <<subsystem>> 'operation' be used to logically collect UseCases for the "operate vehicle" usage. The 'operation' subsystem then also owns the grouped Use Cases in the containment browser, giving a tidier model, as well as providing a convenient navigation point to the next diagram showing only the operational use cases.

Figure B.6 - Establishing Operational Use Cases for Drive the Vehicle

Note that a UML «subsystem» within the Hybrid SUV UseCaseModel has been used, rather than just loose grouping of the UseCases in a diagram usage. The "Drive the Vehicle" case is hyperlinked to an elaborating sequence diagram. One can also navigate back up to the top-level Use Case Model (which contains this Use Case subsystem).  

Figure B.7 - Elaborating Black Box Behavior for the Drive the Vehicle Use Case

Sequence diagram demonstrating OCL bindings to states defined in a statechart diagram for the related finite state machine (visit next image). 

Figure B.8 - Finite State Machine Associated with Drive the Vehicle

Note callout of refined block apparently not yet supported.

Figure B.9 - Black Box Interaction for Start Vehicle, referencing White Box Interaction

Sorry, I am not sure how all of the notations in the SysML spec diagram should be interpreted, suggestions welcome.

Visit also:

Figure B.10 - White Box Interaction for StartVehicle

The external message 'StartVehicle' from outside is "imported" to the pcu:PowerControlUnit lifeline.

Note also consistent naming 'pcu' not 'ecu'.

Figure B.11 - Establishing HSUV Requirements Hierarchy (containment)

My experience is that these kinds of containment diagrams are not graphically robust. For large numbers of requirements they become very difficult to manage. Typical graphical problems include:

For alternatives consider non-standard SysML strategies such as:

These alternatives are illustrated in the following diagrams.

Figure B.11a HSUV Requirements: Alternative: use <<containment>> wrapper Components

In MagicDraw one can use Components as logical and graphical wrappers WITHOUT STEALING OWNERSHIP by placing a Component in the diagram and moving other elements into it. This is effective technique for organising diagrams. Since in this example the «requirement»s are organised by containment, the wrapper Components have been stereotyped as  «containment» wrappers.

While this is already more graphically stable and the concepts better quarantined than the previous diagram using only containment operators, it does requires some extra work. See however next how to apply «requirement» directly to a Component (non-standard).

Figure B.11b HSUV Requirements: Alternative: stereotype UML Components as SysML <<requirement>>s (non standard)

Since a UML Component is a Class it can be stereotyped by the SysML «requirement» stereotypes. This yields very graphically robust requirements diagramming and organisation. Although not official SysML it works very well in the MagicDraw SysML Plugin. In fact this is how I use SysML requirements for all of my "feature-oriented" developments ! You can even use a «feature» stereotype, where Features «satisfy» Requirements SysML-style ! Include hyperlinks directly from your MD SysML requirements model to the entries of an issue-tracking system like JIRA and you have a very powerful requirements and feature tracing system. This really works !

Figure B.12 - Establishing Derived Requirements and Rationale from Lowest Tier of Requirements Hierarchy

I recommend that you package the main (non derived) system specification requirements in their own containment tree COMPLETELY DECOUPLED FROM (not preempting) specific system blocks; you may then package specific derived requirements near the system blocks they relate to (and they may name those specific system blocks they relate to).

Consider the main system specification requirements a type of contract that (possibly many) specific block designs (with their derived requirements) must meet. For example, one might require that a vehicle system can brake from 100 km/h to 0 km/h within 100m. One solution might involve disc brakes (and a DiscBrake block with derived requirements on the disc material) and another solution might use a drag-car parachute (and a BrakingParachute block with derived requirements on the parachute material).

TIP: you should be able to load your main system specification requirements as a read-only module into a separate design solution project !

Figure B.13 - Acceleration Requirement Relationships

I have chosen to contain the Acceleration UseCase in a UML subsystem Component called operation. 

Note also a minor ERROR in the spec sample, there is no <<refineReqt>> relationship, only <<refine>>.

Figure B.15 - Defining the Automotive Domain (Automotive Domain Breakdown)

To callout owned behaviors in MagicDraw use a regular note and select Show Element Properties then use Edit Compartment->Element Properties then choose 'Owned Behavior'.

Figure B.16 - Defining Structure of the Hybrid SUV System (Hybrid SUV Breakdown)

Note how I use a resized parent to visually "bracket" its composed items. It makes it much easier to read, and makes it easier to manage the composition associations. Better still, consider employing <<composition>> wrapper Components as shown in the next image (not standard SysML).

I don't recommend that you name EverySubsystem the way shown in the spec sample; simply apply the «subsystem» stereotype and display it. Motto: "trust the stereotype"

Figure B.16a - Alternative: using «composition» wrappers for assemblies

This is the BIG TRICK for working with complex hierarchical systems !

In this alternative I use "parasitic" «composition» wrapper Components to visually reinforce the assembly structure. My experience is that for complex real-world systems it is very difficult and fiddly to diagram without such wrappers. To use a Component as a composition wrapper, create a Component and place it on the diagram then move an assembly block (parent) and its composed children into the wrapper on the diagram. THE OWNERSHIP OF THE BLOCKS WILL NOT BE AFFECTED. (By contrast, if you move blocks in the containment browser into a Component it will "steal" ownership of the blocks.)

The process can be repeated throughout the system, so that one can then easily move and organise any assembly and its children throughout the composition hierarchy. You can now move the «composition» wrappers around the diagram and it moves its assembled hierarchy, which is much easier than working with multi-select. You can also navigate the composition tree as components in the browser ! Very cool; very useful. This technique also promotes a systematic diagramming and engineering process. Don't leave home without it !

Note how the non-composed references are also now clearly distinguished from the composed ones.

TIP: use a faint border style for the wrapper components.

TIP: Create a wrapper style under Options->Project_Options->Symbols_properties_style using clone style.

TIP: Drag the BDD diagram icon onto the «composition» wrapper to make it the active diagram hyperlink target; make the IBD the active diagram hyperlink target of the wrapped Block.

DISCLAIMER: this is not standard SysML, however it is supported in MagicDraw's SysML Plugin.

Figure B.17 - Internal Structure of Hybrid SUV

I don't recommend that you name the Connectors to indicate the names of the connected elements in the way shown in the spec sample. If one changes the name of a connected part then one also has to change the names of (possibly many) connectors, thus reducing the degree of model-driven engineering and increasing error-prone manual maintenance. It also makes the diagrams more cluttered.

I also don't recommend that you name EverySubsystem this way; much better to apply the «subsystem» stereotype and display it. Motto: "trust the stereotype".


TIP: In MagicDraw you can drag the IBD or BDD of a Block onto parts that are typed by that Block to make them the default hyperlink target for that part (so one can just "open the part up" by clicking on it). Together with MagicDraw's diagram icons this makes is easy to make the entire project (and system) navigable.

Figure B.18 - Defining Structure of Power Subsystem (PowerSubsystem Breakdown)

TIP: In BDDs showing complex assemblies place non-composed (only shared or referenced) blocks on the other side from the composed blocks to distinguish them. This suggests "inside" vs. "outside" w.r.t. each assembly. This can help grouping if the shared Block is composed by another Block in the same diagram.

Figure B.19 - Internal Structure of the Power Subsystem (Alternative 1 - Combined Motor Generator)

TIP: Provided/required interface "lollipops and forks" in IBDs are now directly supported in MD SysML 15.5. Use the Display Required Interfaces and Display Provided Interfaces context menu items from a Port in an IBD.

I don't recommend that you name the Connectors to indicate the names of the connected elements in the way shown in the spec sample. If one changes the name of a connected part then one also has to change the names of (possibly many) connectors, thus reducing the degree of model-driven engineering and increasing error-prone manual maintenance. It also makes the diagrams more cluttered.

Figure B.19a PowerSubsystem BDD: part and port design with required/provided interfaces

Advanced topic: supplement your IBD with a preparatory BDD

Before making a complex IBD, I recommend that you make first a BDD with the elements that will become connected parts to explore the types, ports, and required/provided interfaces with MagicDraw's classifier-level interface dependency wiring (ball and socket notation).

You may find yourself moving back and forth between the IBD and BDD as your design converges. You can place the IBD diagram icon on the BDD and the BDD diagram icon on the IBD to help you move back and forth between these "two sides of the same coin".

Figure B.20 - Interfaces Typing StandardPorts Internal to the Power Subsystem (ICE Interface Definitions)

The sense of the operation signatures in the spec sample are clearly wrong, and have been renamed here (and parameters correctly introduced). In the PowerSubsystem IBD of Figure B.19 the interface I_ICEData is provided via a port of pcu:PowerControlUnit, it is required via a port of ice:InternalCombustionEngine so that it can put/send data.

Visit also:

Figure B.21 - Initially Defining Flow Specifications for the CAN Bus

Although the MD SysML Plugin does not support a dedicated «flowProperties» compartment and dedicated 'in'/'out' indicators, the required information can be displayed using a combination of:

This diagram has been extended over the spec sample diagram to include the elements that will depend on these flow specifications.

Figure B.22 - Consolidating Interfaces into the CAN Bus (CAN Bus Description)

Figure B.23 - Elaborating Definition of Fuel Flow (Power Subsystem Fuel Flow Definition)

Extended to illustrate (using dependencies) the flowSpecifications that are applied.

Note that although (SysML1.0 9.3.2.4 FlowProperty):

'[2] An “in” FlowProperty value cannot be modified by its owning block.'

an "in" flow property defined must still be modifiable by other elements, so it is not marked here as a 'readOnly' Property:

'For Block, Data Type and Value Type properties, setting an “out” FlowProperty value of a block usage on one end of a connector will result in assigning the same value of an “in” FlowProperty of a block usage at the other end of the connector, provided the flow properties are matched.'


WARNING: The sense of direction of both the Return and Supply seems the wrong way round in both the Block flow properties and the FlowSpecification in the original spec figure (they are correctly reversed here).

Visit also:

Figure B.24 - Defining Fuel Flow Constraints

Extended to include detailed spec quotes on constraint properties and representation of contraints properties in parametric diagrams.

Each connector has been stereotyped as a «BindingConnector»


TIP: Use Selected Nested Part to choose a deeply nested property of a part within the context.

FuelFlow.constraint

(used in Figure B.24)

Figure B.25 - Detailed Internal Structure of Fuel Delivery Subsystem (Fuel Distribution Detail)

Advanced topic: allocations to/from connectors in MagicDraw's SysML Plugin

The allocations from Connector fdist to these refining elements were made by creating an incoming Allocate relationship under the Relations section of the specification dialog of each targeted element, from which one can navigate to the fdist Connector as the source of the allocation.

Visit also:

Figure B.26 - Defining Analyses for Hybrid SUV Engineering Development (Analysis Context)

Note also the specification of «ValueType» GlobalTime, which is referenced as property 'delta-t'. The spec sample diagram does not state whether this is a Block or a ValueType, however it can be inferred from the BindingConnectors to parameter dt:Time in Figure B.29 that 'delta-t' must be compatible with «ValueType» Time.

Note the use of non-standard «composition» wrapper Components to organise and graphically stabilise the hierarchies.

Visit also:

Figure B.27 - Establishing a Performance View of the User Model

The diagram has been extended to show the stereotypes involved.

 WARNING: There are a number of errors in the packaging of elements in the PerformanceView in the spec sample.

Figure B.28 - Defining Measures of Effectiveness and Key Relationships (HSUV MOEs)

WARNING: The definition of parameters of CapacityEquation in Figure B.28 of the spec sample is inconsistent w.r.t. Figure B.26

Figure B.29 - Establishing Mathematical Relationships for Fuel Economy Calculations

Note:

Visit also:

Figure B.30 - Straight Line Vehicle Dynamics Mathematical Model

Note:

CAVEAT: only callout of constraints on a ConstraintBlock - not via the constraint block usage - is currently supported.

Figure B.31 - Defining Straight-Line Vehicle Dynamics Mathematical Constraints

In MD SysML, UML-style "inline" {constraints} are displayed in the header, consistent with the SysML1.0 spec, which states:

8.3.1.1 Block Definition Diagram ..

Constraints compartment

'SysML defines a special form of compartment, with the label “constraints,” which may contain one or more constraints owned by the block. A constraint owned by the block may be shown in this compartment using the standard text-based notation for a constraint, consisting of a string enclosed in brace characters. The use of a compartment to show constraints is optional. The note-based notation, with a constraint shown in a note box outside the block and linked to it by a dashed line, may also be used to show a constraint owned by a block.'

Future versions of the MD SysML Plugin will support a 'constraints' compartment for nested constraints (constraint properties of constraint blocks):

'A constraints compartment may also contain declarations of constraint properties owned by the block. A constraint property is a property of the block that is typed by a ConstraintBlock, as defined in Chapter 10, “Constraint Blocks.”'

Visit also:

Concerning types of values in this diagram:

There is still some contention in the SysML community about the correct use of Unit and/or ValueType to type value properties and the spec samples are inconsistent in this regard.

In the MD SysML Plugin version of the Hybrid SUV sample these ValueTypes have been named like the kinds of domain quantities they represent, as in the Annex B of the sample, for use in parametric diagrams. Note however that in other diagrams in the SysML1.0 specification (not in Annex B) there are value types that are named after the symbol of their units, so that value properties typed by them read like most scientist and engineers would expect., namely as representations of quantities with measured or stated values relative to a Unit scale.

Figure B.33 - Behavior Model for Accelerate Function

Note:

Figure B.33a - Behavior Model for Accelerate Function: alternative using Pins

TIP: I recommend that you use Pins rather than ObjectNodes wherever possible.

Here Figure B.33 has been adapted to use input/output Pins with <<continuous>> flows rather than ObjectNodes.

Additions to the SysML1.0 sample model are indicated with the stereotype <<alternative>> are are coloured purple.

Figure B.34 - Decomposition of Accelerate Function (Activity and Object Flow Breakdown)

The decomposition associations were generated using the Activity Decomposition Wizard tool
under the Analyze menu (which at the time of writing it is still a bit buggy), and then tuned "by hand":

These known problems are being addressed.


I have once again used <<composition>> "wrapper" Components to visually reinforce activity node and objectflow structure.

Figure B.35 - Detailed Behavior Model for Provide Power (with Swimlane Allocation)

CAVEAT: the interruptible region could not be properly combined with swimlanes in MagicDraw, the "containment" of the swimlanes by the interruptible region in the image below is graphically contrived.

ADVICE: avoid the contrived placement of object flows on swimlane partitions as shown in the SysML1.0 sample figure, it is graphically unstable ! Prefer instead typed, named, input/output pin pairs (which can be stereotyped as <<continuous>>). You can even allocate meaningfully to/from the pins. In general, I advise MD SysML and MagicDraw UML users to adopt Pin pairs over ObjectFlows wherever possible!

Figure B.36 - Flow Allocation to Power Subsystem (Power Functional Allocation)

WARNING: there are a number of errors in both the allocations and block names in the SysML1.0 specification sample.

Note consistent naming 'pcu:PowerControlUnit'. 

Figure B.38 - Special Case of Internal Block Diagram Showing Reference to Specific Properties (Test Results) [NOT SUPPORTED]

CAVEAT: Display of values for block property parts typed by property-specific types are not supported yet in the MD SysML Plugin 15.5. Instead, the assignment of values is emulated using the SysML plugin's property-specific initial values mechanism applied to property-specific subtypes and slots of instance specifications typed by those subtypes. See the associated BDD following for manual definition of property-specific types for this diagram.

Future versions of MagicDraw's SysML plugin will support on-the-fly creation of
property-specific types and a values compartment in block properties in IBDs.

WORKAROUND for Property-Specific Types for Hybrid SUV test results

Advanced topic

Property specific types are defined manually here for use in Figure B.38.
This diagram is for analysis purposes only, it is NOT expected that
users attempt this technique, the method shall be automated.

Future versions of MagicDraw's SysML plugin will
support on-the-fly creation of property-specific types

 

Hybrid SUV Sample: additional diagrams

Some additional diagrams are included that relate to aspects of the spec sample from Annex B.

Decomposition of Activity Operate Car: using Activity Decomposition Hierarchy Wizard

Shows how the Activity Decomposition Hierarchy Wizard under the Analyze menu can be used to automate the translation of owned CallBehaviorActions and ObjectNodes references via ObjectFlows in Activity diagrams into Associations with Properties typed by Activities (which typed the CallBehaviorActions) and Blocks (which typed the ObjectNodes). I fine tuned the result graphically.

Figure 10.2 Definition of constraint blocks on a block definition diagram

Visit nearly identical diagram from Annex B: Figure B.31 - Defining Straight-Line Vehicle Dynamics Mathematical Constraints

Figure 11.10 - Continuous system example 1: Operate Car

 WARNING: advanced topic: includes detailed analysis of a complex diagram with many issues

There are many difficulties representing the original SysML1.0 spec figure 11.10 in MD SysML 15, including:

  • MD SysML15 can't draw object flows from the the fork to the action :Braking,
    I have used control flows as a workaround for now. (One definitely should be able to have object flows into and out of a fork and/or join in UML2.1.1, as long as one does not mix object and control flows.)
  • One can't easily show the {stream} from :Driving to :BrakePressure indicating that the parameter has 'isStream=true' without a Pin (indeed the spec Figure is inconsistent in this matter, the examples in Table 11.1 - Graphical nodes included in activity diagrams under UML4SysML::Parameter.isStream shows actions with Pins and {stream}).

I recommend that you ALWAYS use typed Pins in these situations; see the examples in green in the images below using Pins typed by 'BrakePressure' and expressing the 'isStream=true' condition of the underlying Parameter using the {stream} notation.

Another problem is that the default concrete object node in MagicDraw is a CentralBufferNode, which should not be related directly to an Action. However, the UML2.1.1 spec is inconsistent on this matter:

12.3.38 ObjectNode (from BasicActivities, CompleteActivities)

An object node is an abstract activity node that is part of defining object flow in an activity.

12.3.16 CentralBufferNode (from IntermediateActivities)

A central buffer node is an object node for managing flows from multiple sources and destinations. A central buffer node accepts tokens from upstream object nodes and passes them along to downstream object nodes. They act as a buffer for multiple in flows and out flows from other object nodes. They do not connect directly to actions.

The UML2.1.1 does not provide a sensible concrete ObjectNode for participation in flows, which is a major problem for tool vendors. Once again, using typed Pins solves this problem in MD15, too, for when using Pins there is no need to incorrectly assume a CentralBufferNode. I also consider using Pins a cleaner notation than ObjectNodes managed by two object flows to and from the ObjectNode.

Why doesn't the spec figure show a typed Pin with control
tokens flowing out of the <<controlOperator>> ? The spec in fact asserts that such a <<controlOperator>> must have at least one Parameter of type ControlData (being part of the activities ModelLibrary):

11.3.2.2 ControlOperator

..

Constraints
[1] When the «controlOperator» stereotype is applied, the behavior or operation must have at least one parameter typed by ControlValue.
If the stereotype is not applied, the behavior or operation may not have any parameter typed by ControlValue.

Since <<controlOperator>> is applied to ':Enable on Brake Pressure > 0' its Behavior should have an output Parameter typed by ControlValue, so it makes good sense for it to also have an output Pin corresponding to that ControlValue output Parameter (as shown in green as an alternative). By contrast, since the controlled Action ':Monitor Traction' does not have the <<controlOperator>> applied its Behavior may not have an input Parameter of type ControlValue, and so it may not have a Pin of type ControlValue.

Please visit also my "improved" version of the Figure 11.10 using Pins whereever possible.

WARNING: the SysML1.0 spec figure notation for actions typed by activities is confusing, use instead anonymous CallBehaviorActions as I have done here.

Figure 11.10 - Continuous system example 1: Operate Car (adapted to use Pins, no annotations)

In this version I have used Pins wherever possible/permitted to improve on the SysML1.0 specification figure. All information is correctly conveyed, and contend that the diagram is easier to understand.

Figure 16.3 - Requirements Derivation_ Safety Test

Figure 16.4 - Links between requirements and design: MasterCylinderSafety

Figure 8.8 - Block diagram for the Wheel Package (WheelHubAssembly)

In practice it is extremely difficult to manage assemblies of complex hierarchical systems in BDDs like this.
It is graphically very unstable, it is difficult to organise parents and children, and it does not make sense to
have children near or overlapping with elements belonging to different parents as shown in the spec sample.

Prefer instead my simple yet powerful (though non standard) recipe using <<composition>> Component
wrappers to graphically and logically group elements of assemblies recursively (see next image).

Figure 8.8 - WheelHubAssembly: alternative: how to use: composition wrappers

Dr Darren says: "Years of experience modelling complex hierachical systems in UML and SysMLhave taught
me that the only sensible and practical way to organise diagrams of assemblies is to use wrapper Components."

This is the BIG TRICK for working with complex hierarchical systems !

In this alternative I use parasitic <<composition>>
"wrapper" Components to visually reinforce the assembly structure.
Experience shows that for complex real-world systems it is very
difficult and fiddly to diagram without such wrappers. To use a
Component as a <<composition>> wrapper, create a Component and place it on
the diagram then move an assembly block (parent) and its composed
children into the wrapper on the diagram. THE OWNERSHIP OF THE BLOCKS WILL NOT BE AFFECTED. (By contrast, if you move blocks in the containment browser into a Component it will steal ownership of the blocks.)

The process can be repeated throughout the system, so that one can then
easily move and organise any assembly and its children throughout the
composition hierarchy. You can now move the composition wrappes around
the diagram and it moves its assembled hierarchy. Very cool, very
useful, and much easier than working with multi-select. This technique
also promotes a systematic diagramming and engineering process.

Note how the non-composed references are also now clearly distinguished from the composed ones.

TIP: create your own <<composition>> stereotype for the wrapper Components.

TIP: use a faint border style for the wrapper components.

TIP: Create a wrapper style under Options->Project_Options->Symbols_properties_style using clone style.

DISCLAIMER: this technique is not standard SysML, however it is supported in the MagicDraw's SysML Plugin.

 

Figure 8.9 - Internal Block Diagram for WheelHubAssembly

Demonstrates nested connectors.

HOWTO use property-specific default values: Hybrid SUVs with different size wheels

Shows how to assign the values that the attributes of part properties should take in a given context.

Default Values for small Hybrid SUV vehicle

The small HSUV has small Wheels and WheelAssembly parts.

Default values are assigned from the values of slots of instances shown.
(The depencies from the parts to the instances are for illustration only,
they show which instances were assigned to the parts.)

Default Values for large Hybrid SUV vehicle

The large HSUV vehicle has larger Wheel and WheelAssembly parts.
Default values are assigned from the values of slots of instances shown.
(The dependencies from the parts to the instances are for illustration only,
they show which instances were assigned to the parts.)

In this example we show the parts using deeply nested property notation
(dot separated paths).

 

Allocation Tree for Provide Power Actions

MagicDraw UML's dependency matrix facility can be exploited to trace allocations.

Hybrid SUV (OMG RTF versions, no annotations, no MagicDraw symbols)

This INCOMPLETE version of the Hybrid SUV sample is primarily for the OMG SysML working groups.

The diagrams are tuned for possible inclusion in the SysML specification:

  • There are no MD diagram icons or stereotype icons
  • The diagrams are similar to - however not identical to - the current SysML spec diagrams

The diagramming style differs significantly in at least the following regards:

  • MagicDraw UML does not support aggregation trees, so instead "bracketing" of composed parts using resizing of the composing parent is used. The use of aggregation trees as shown in the spec. diagrams is in any case discouraged, as it is extremely graphical fragile
  • Where possible "elided Pin" notation for object flows is avoided; explicit Pin pairs are always used instead
    • Note that the ObjectNode is abstract, and that the rectangular node symbol that appears in "elided pin" notation is NOT an object node; it stands for two Pins !

Figure B.03: HSUV Model

Notes:

  • "columns" of related packages arranged to better reflect systems engineering process:
    • left to right from Requirements through Structure to Behavior and Test
  • extra packages Test and Configuration
  • ValueTypes and FlowTypes model libraries isolated in ModellingDomain package independent of Hybrid SUV

Visit also detailed annotated version of Figure B.3 with explanations and amendments to SysML1.0 spec.


TIP: I recommend against naming packages verbosely to include a reusable name as prefix:

HSUVStructure, HSUVBehavior, HSUVAnalysis, HSUVViews...

Instead, simply "trust the owner name" and display it with the packages:

Structure (HSUV), Behavior (HSUV), Analysis (HSUV), Views (HSUV)

The top-level "system package" then reads more like a Class with "one of each thing" in it, and if you rename the top-level "system package" all diagrams catch it, and you won't have to rename all the subpackages.

Figure B.16: HybridSUV Breakdown

Notes:

  • shared aggregation (white diamond) from PowerSubsystem to bkp:BrakePedal and wha:WheelHubAssembly
  • MD can't do "aggregation trees", instead it shows bracketing using resize:
  • Note 'bkp' Property name appears twice (was once in SysML1.0)
  • Note 'wha' Property name appears twice (was none in SysML1.0)
  • Note «Rationale» handle is to the Property multiplicity, not the Association
  • AutomotiveDomain is consistently marked as a Domain block

Visit also the annotated version of Figure B.16

Figure B.17: HybridSUV

Visit also annotated version: Figure B.17 - Internal Structure of Hybrid SUV

Figure B.18: Alternative 1 - Combined Motor Generator

Visit also annotated version: Figure B.19 - Internal Structure of the Power Subsystem

Figure B.18: PowerSubsystem breakdown

Notes:

  • Shared aggregation (white diamond) from PowerSubsystem to bkp:BrakePedal and rfw:FrontWheel,lfw:FrontWheel, and also from FuelTankAssembly to fuel:Fuel
  • MD can't do "aggregation trees", so instead it shows bracketing using resize:
  • Owner HybridSUV is consistently marked as a System block
  • There is a fuel:Fuel property name
  • The Generalization from FrontWheel to WheelAssembly is in the same sense as the aggregating Associations from PowerSubsystem
    • think of it as the PowerSubsystem receiving information (reusing) first by aggregation, then by specialization.
  • The pcu:PowerControlUnit Property has a consistent acronymn

Visit also the annotated version of Figure B.18.

WARNING: This kind of "associative composition" diagram does not scale well
and I discourage its use for systems engineering except for very simple cases !
  • it is not at all graphically stable
  • it is not robust against additions, name changes, structural changes
  • it is VERY difficult to move a group of composed elements (with wrapper Components it becomes very easy)
  • it does not easily reflect a system's topology or geometry (whereas composite structure can)

You are much better off using a "composite structure" approach (SysML IBD) alone, reserving the class diagram (SysML BDD) only for a "focus" diagram for each Block, possibly using a "hybrid" diagram exploiting the structure compartment. If you really must do it then:

Figure B.21: CAN Bus FlowSpecifications

Visit also annotated version (with explanation of tagged values and note callouts): Figure B.21 - Initially Defining Flow Specifications for the CAN Bus

Figure B.22: CAN Bus description

Note consistently named 'pcu:PowerControlUnit' (rather than 'ecu').

Visit also: annotated version Figure B.22 - Consolidating Interfaces into the CAN Bus (CAN Bus Description)

Figure B.23: PowerSubsystem Fuel Flow Definition

Visit also (for remarks about inconsistent directions in the SysML1.0 sample spec original) annotated version: Figure B.23 - Elaborating Definition of Fuel Flow (Power Subsystem Fuel Flow Definition)

Figure B.24: Defining Fuel Flow Constraints

Visit also annotated version (with explanation of property path and how to create nested property symbols): Figure B.24 - Defining Fuel Flow Constraints

Figure B.26: Analysis Context

Notes:

  • shared aggregation (white diamond) to AutomotiveDomain from context blocks
  • stereotypes shown throughout for clarity
  • UML constraints shown UML-style in {brackets} near the symbol name for CapacityEquation
  • The composed elements of EconomyContext have actually been organised
    graphically with a transparent (white) composition wrapper Component !

Visit also:

Figure B.29: EconomyContext

Figure B.29 - Establishing Mathematical Relationships for Fuel Economy Calculations (Parametric Diagram)

Notes:

  • delta-t:GlobalTime[1] dashed consistent with shared ownership by EconomyContext in Figure B.26 HSUVAnalysis [Analysis Context]
  • lower case symbols used throughout for all property names
  • consistent property path names like: ad.hsuv.p.emg.generatorEfficiency
    • SysML1.0 example had: ad.HSUV.Powersybsystem.ElectricalMotorGenerator.GeneratorEfficiency
  • a port name is NOT followed by a colon ":" in MD SysML:
    • since MD SysML ConstraintParameter extends Port (to reuse small box notation) gets same conventions
  • word-wrap used on selected value properties

Visit also:

Figure B.33: Accelerate

Note that it is not possible in MD SysML to show the Behavior type without a colon ':' before the Behavior name.

Visit also:

Figure B.34: Activity and ObjectFlow breakdown

Figure B.34 - Decomposition of “Accelerate” Function (Block Definition diagram)

Notes:

  • the part property elecDrivePower:ElecPower is now correctly owned by ProvideElectricPower (not by ControlElectricPower as in SysML1.0).
  • part properties gasDrivePower:GasPower and elecDrivePower:ElecPower are (in the MD SysML sample model) owned by ProvideGasPower and ProvideElectricPower respectively, whereas the corresponding "object flows" gasDrivePower:GasPower and elecDrivePower:ElecPower in Figure B.35 are owned by a "higher" activity ProvidePower
    • THIS IS A FUNDAMENTAL FLAW WITH THE ACTIVITY DECOMPOSITION STRATEGY
  • consistent with "object flows" gThrottle and eThrottle in Figure B.35, part properties gThrottle:Throttle and eThrottle:Throttle have been introduced, along with a block Throttle (one could argue that a ValueType would be a better choice for typing this)

Figure B.35: with Swimlane Allocation (with elided Pin notation)

Figure B.35 - Detailed Behavior Model for “Provide Power” (Activity Diagram)

Notes:

  • ERROR: it is not possible in MD SysML15.1 to draw a control flow from an initial state to an interruptible region
  • Please DO NOT emulate this diagram in MD SysML:
    • The use of "elided Pin" notation with "object nodes" is discouraged
    • Placing "object nodes" on the border between swimlanes is graphically unstable and poor modelling practice
    • The use of a DecisionNode to "split" vehCond is questionable, as is the use of a MergeNode to drivePower

Visit also:

Figure B.35: with Swimlane Allocation (with explicit Pin notation)

Adapted from Figure B.35 - Detailed Behavior Model for “Provide Power” (Activity Diagram). Attempt at using explicit Pins.

Note:

  • the question arises how to best go about allocating to/from the flow "between" Pins.
  • the use of MergeNode and DecisionNode as shown is questionable

Figure B.36: Power Functional Allocation

Visit also: