OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — All Issues

  • Acronym: SysML
  • Issues Count: 116
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML17-99 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.7 Deferred closed
SYSML17-95 Clarification required for Copy relationship SysML 1.3 SysML 1.7 Deferred closed
SYSML17-80 Missing ownership constraints SysML 1.3 SysML 1.7 Deferred closed
SYSML17-81 Missing type constraints for FullPort SysML 1.3 SysML 1.7 Deferred closed
SYSML17-89 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.7 Deferred closed
SYSML17-91 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.7 Deferred closed
SYSML17-92 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.7 Deferred closed
SYSML17-85 Figure 15.8 diagram type SysML 1.3 SysML 1.7 Deferred closed
SYSML17-90 Allocation tabular notation normative? SysML 1.3 SysML 1.7 Deferred closed
SYSML17-75 Callout notation for port-specific types and initial values SysML 1.3 SysML 1.7 Deferred closed
SYSML17-94 Diagram show inconsistent data SysML 1.3 SysML 1.7 Duplicate or Merged closed
SYSML17-93 Don't use the optional notation for Pins with Allocation SysML 1.3 SysML 1.7 Duplicate or Merged closed
SYSML17-77 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-109 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-71 Property Based Requirements SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-86 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.7 Closed; Out Of Scope closed
SYSML17-66 InstanceSpecifications for exactly one instance SysML 1.3 SysML 1.7 Closed; Out Of Scope closed
SYSML17-67 InstanceSpecification equality SysML 1.3 SysML 1.7 Closed; Out Of Scope closed
SYSML16-100 Incorrect constraint [2] on InterfaceBlock SysML 1.3 SysML 1.6 Duplicate or Merged closed
SYSML16-136 Update SysML references to UML model library StandardProfileL2 SysML 1.3 SysML 1.6 Closed; No Change closed
SYSML16-76 Problems with property-specific types SysML 1.3 SysML 1.6 Resolved closed
SYSML16-106 Constraint [5] should include specializations of Requirement SysML 1.3 SysML 1.6 Duplicate or Merged closed
SYSML16-92 remove figure numbers from diagram frames SysML 1.3 SysML 1.6 Resolved closed
SYSML16-104 View and Viewpoint Limitations in support of auto-view generation SysML 1.3 SysML 1.6 Closed; No Change closed
SYSML16-110 Ports and Flows SysML 1.3 SysML 1.6 Resolved closed
SYSML16-78 InstanceSpecification equality SysML 1.3 SysML 1.6 Deferred closed
SYSML16-77 InstanceSpecifications for exactly one instance SysML 1.3 SysML 1.6 Deferred closed
SYSML16-91 Callout notation for port-specific types and initial values SysML 1.3 SysML 1.6 Deferred closed
SYSML16-84 Property Based Requirements SysML 1.3 SysML 1.6 Deferred closed
SYSML16-99 Missing type constraints for FullPort SysML 1.3 SysML 1.6 Deferred closed
SYSML16-98 Missing ownership constraints SysML 1.3 SysML 1.6 Deferred closed
SYSML16-95 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.6 Deferred closed
SYSML16-107 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.6 Deferred closed
SYSML16-105 Figure 15.8 diagram type SysML 1.3 SysML 1.6 Deferred closed
SYSML16-114 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.6 Deferred closed
SYSML16-113 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.6 Deferred closed
SYSML16-112 Allocation tabular notation normative? SysML 1.3 SysML 1.6 Deferred closed
SYSML16-111 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.6 Deferred closed
SYSML16-117 Clarification required for Copy relationship SysML 1.3 SysML 1.6 Deferred closed
SYSML16-116 Diagram show inconsistent data SysML 1.3 SysML 1.6 Deferred closed
SYSML16-115 Don't use the optional notation for Pins with Allocation SysML 1.3 SysML 1.6 Deferred closed
SYSML16-137 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.6 Deferred closed
SYSML16-121 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.6 Deferred closed
SYSMLR-79 Problems with property-specific types SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-88 Property Based Requirements SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-81 InstanceSpecification equality SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-80 InstanceSpecifications for exactly one instance SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-96 remove figure numbers from diagram frames SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-95 Callout notation for port-specific types and initial values SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-99 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-121 Clarification required for Copy relationship SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-110 Constraint [5] should include specializations of Requirement SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-109 Figure 15.8 diagram type SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-108 View and Viewpoint Limitations in support of auto-view generation SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-111 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-104 Incorrect constraint [2] on InterfaceBlock SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-103 Missing type constraints for FullPort SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-102 Missing ownership constraints SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-125 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-120 Diagram show inconsistent data SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-119 Don't use the optional notation for Pins with Allocation SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-114 Ports and Flows SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-118 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-117 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-116 Allocation tabular notation normative? SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-115 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-143 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-142 Update SysML references to UML model library StandardProfileL2 SysML 1.3 SysML 1.5 Deferred closed
SYSML14-46 Expanded Usage Examples for Viewpoints SysML 1.3 SysML 1.4 Resolved closed
SYSML14-45 Concern Relation Limitations SysML 1.3 SysML 1.4 Resolved closed
SYSML14-43 SysML DI SysML 1.3 SysML 1.4 Resolved closed
SYSML14-42 Any notation available for internal parts should apply to ports SysML 1.3 SysML 1.4 Resolved closed
SYSML14-48 Deprecated Elements update for Views and U&QK SysML 1.3 SysML 1.4 Resolved closed
SYSML14-47 Align initial clauses with UML 2.5 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-44 Annex A corrections SysML 1.3 SysML 1.4 Resolved closed
SYSML14-22 SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit SysML 1.3 SysML 1.4 Resolved closed
SYSML14-21 N-ary Allocation needs better definition, or deletion SysML 1.3 SysML 1.4 Resolved closed
SYSML14-10 9.3.2.8 FullPort SysML 1.3 SysML 1.4 Resolved closed
SYSML14-9 9.3.2.4 DirectedFeature , constraint 4 - what is inherited method??? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-20 ControlOperator stereotype should also extend the CallBehaviorAction metaclass SysML 1.3 SysML 1.4 Resolved closed
SYSML14-19 Requirements should be disallowed from typing other elements SysML 1.3 SysML 1.4 Resolved closed
SYSML14-16 SysML Issue Lower bounds on multiplicity not consistent with diagram SysML 1.3 SysML 1.4 Resolved closed
SYSML14-18 SysML Issue: State Machine Notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-17 SysML Issue: SysML Issue: Activitiy Switched on diagrams SysML 1.3 SysML 1.4 Resolved closed
SYSML14-15 Wrong compartment names SysML 1.3 SysML 1.4 Resolved closed
SYSML14-14 Full ports compartment SysML 1.3 SysML 1.4 Resolved closed
SYSML14-23 Conjugation of full ports question SysML 1.3 SysML 1.4 Resolved closed
SYSML14-13 Figure 9.8 - can roles be ports?? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-12 Figure 9.7 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-11 9.3.2.10 InvocationOnNestedPortAction SysML 1.3 SysML 1.4 Resolved closed
SYSML14-4 Part 1 of the specification SysML 1.3 SysML 1.4 Resolved closed
SYSML14-3 Issues with XMI for SysML 1.3 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-1 Constraint Blocks cannot have parameters SysML 1.3 SysML 1.4 Resolved closed
SYSML14-2 Addition of derived property notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-8 ports with flow properties are displayed the same as flow ports in SysML 1.1? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-7 9.1 InterfaceBlock - unnamed compartment SysML 1.3 SysML 1.4 Resolved closed
SYSML14-6 Table 9.1 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-5 Section 9.3.1.6 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-36 QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of unit SysML 1.3 SysML 1.4 Resolved closed
SYSML14-35 View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g)) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-34 SysML ISO-80000-1 libraries need update per 18269, 18435 and 18681 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-33 Navigation through non-properties SysML 1.3 SysML 1.4 Resolved closed
SYSML14-32 SysML: Unts and QualityKind SysML 1.3 SysML 1.4 Resolved closed
SYSML14-31 QUDV's support for measurement scales is impractical SysML 1.3 SysML 1.4 Resolved closed
SYSML14-30 View and Viewpoint Property Limitations (from Issue 18391 a) and f)) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-41 Wrong quantityKind for unit radian SysML 1.3 SysML 1.4 Resolved closed
SYSML14-40 Signal flow property description (§9.3.2.7) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-39 notation for inherited features SysML 1.3 SysML 1.4 Resolved closed
SYSML14-38 Addign a Behavior Compartment for Blocks SysML 1.3 SysML 1.4 Resolved closed
SYSML14-37 Missing/wrong elements in diagram table (InformationFlows) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-25 QUDV Unit/QuantityKind name redundancy SysML 1.3 SysML 1.4 Resolved closed
SYSML14-24 propertyPath property should be defined once and reused SysML 1.3 SysML 1.4 Resolved closed
SYSML14-27 9.3.2.4 direction of ports and their notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-26 Use of "inherited method" in section 9.3.2.4 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-29 Refine relationship contextualization SysML 1.3 SysML 1.4 Resolved closed
SYSML14-28 Activity model library package SysML 1.3 SysML 1.4 Resolved closed

Issues Descriptions

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Key: SYSML17-99
  • Legacy Issue Number: 18678
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the Constraints section the specification states the following:

    'An Action appearing in an “AllocateActivityPartition” will be the /client (from) end of an “allocate” dependency. The element that represents the “AllocateActivityPartition” will be the /supplier (to) end of the same “allocate” dependency.'

    For Actions owned by an Activity and shown inside the partition, this constraint is clear. However, if you have a StructuredActivityNode inside a partition and that StructuredActivityNode owns an Action, how many Allocate dependencies should there be? Should there be:

    a) One allocate from the StructuredActivityNode only?
    b) One allocate dependency from the StructuredActivityNode and one from the Action inside the StructuredActivityNode?

    To make things clearer, instead of the constraints section saying:

    'An Action appearing IN an "An Action appearing in an “AllocateActivityPartition”'

    It should say something along the lines of:

    'An Action referenced in the "node" role of an “AllocateActivityPartition”'

    This would remove the ambiguity of what "in" means and allow users to decide when Allocate dependencies are created.

  • Reported: SysML 1.3 — Fri, 19 Apr 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Clarification required for Copy relationship

  • Key: SYSML17-95
  • Legacy Issue Number: 18525
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    There's a few issues with the Copy relationship as described in the specification.

    1. It's unclear what constraint 3 means. What are subrequirements (nested or derived)?

    2. How do you match subrequirements in the slave to subrequirements in the master?

    3. There's no constraint on the number of Copy relationships that a slave Requirement can be involved in (e.g. one Requirement could be the slave of two different master Requirements). What happens to the "text" tag if there are multiple masters?

    4. There's no constraint stopping a Requirement from being directly or indirectly a master of itself. Shouldn't there be?

  • Reported: SysML 1.3 — Mon, 4 Mar 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Missing ownership constraints

  • Key: SYSML17-80
  • Legacy Issue Number: 18181
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The FlowProperty stereotype can current be applied to any Property in SysML. However, this leaves it open to applying the stereotype to Ports (inc. extensions of Ports) and Properties owned by non-Blocks. This doesn't seem to match the intent of the specification so constraints need to be added

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Missing type constraints for FullPort

  • Key: SYSML17-81
  • Legacy Issue Number: 18182
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Ports stereotyped as FullPort can currently be typed by anything a normal Port can be typed by. This isn't the intent of the specification, so constraints should be added.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figures 15.5 and 15.6 diagram types

  • Key: SYSML17-89
  • Legacy Issue Number: 18459
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figures 15.5 (Example of flow allocation from ObjectFlow to Connector) and 15.6 (Example of flow allocation from ObjectFlow to ItemFlow) have ibds on the right, but those ibds have blocks instead of parts in them. Are they supposed to be a bdds? The blocks show parts, but the compartment doesn't say "structured" (same for Figure 15.8).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Allocated notation on object nodes missing from diagram elements table

  • Key: SYSML17-91
  • Legacy Issue Number: 18461
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Allocations, the Diagram Element table is missing the notation for allocated object nodes shown in Figure 15.7 (Example of flow allocation from ObjectNode to FlowProperty).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Libraries package should be named "SysML Model Libraries"

  • Key: SYSML17-92
  • Legacy Issue Number: 18462
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The spec headings refer to model libraries using the adjective "model", so the package name should include it also. The name should start with "SysML" since it is separate from the SysML package.

  • Reported: SysML 1.3 — Sun, 17 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Figure 15.8 diagram type

  • Key: SYSML17-85
  • Legacy Issue Number: 18409
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 15.8 (Example of Structural Allocation) is an ibd, but has blocks instead of parts in it. Is it supposed to be a bdd?

  • Reported: SysML 1.3 — Fri, 27 Jun 2014 11:16 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Allocation tabular notation normative?

  • Key: SYSML17-90
  • Legacy Issue Number: 18460
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The clause Allocations, Usage Example, Tabular Representation is in the normative part of the spec, but refers to a tabular notation in Annex C, which isn't normative. Is the tabular notation normative?

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Callout notation for port-specific types and initial values

  • Key: SYSML17-75
  • Legacy Issue Number: 17406
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification allows property-specific types and property-specific initial values. Ports are just a special kind of property. Thus it would be possible to model port-specific types and values. The only problem is, that it is not possible to show the specifics of these types or the initial values within an internal block diagram, as would be the case for a property.

    Suggested addition to the spec

    • property-specific types and initial values also apply to ports [would not be forbidden now, but just to clarify this point]
    • A callout notation can be used in an ibd for ports with a port-specific type or initial value. It shows the same information as the compartments for properties.
    • Table 8.3: Example for call-out notation

    Maybe this notation could also be used on block definition diagrams, and in this case for properties as well. Then there should be a sentence in chapter 8.1.1.1 and an example in Table 8.2.

  • Reported: SysML 1.3 — Tue, 5 Jun 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Diagram show inconsistent data

  • Key: SYSML17-94
  • Legacy Issue Number: 18503
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Diagrams C.35, C.36 and C.37 show inconsistent allocation between the displayed items, yet the text would seem to imply that they're supposed to show the same relationships.

    In C.35, the allocation is from an ObjectNode symbol called "DriveCurrent" (which I believe equates to an ObjectFlow - name unknown) to an ItemFlow called "i1".

    In C.36, the allocation is from an ObjectNode called "DriveCurrent" to a Connector (name unknown).

    In C.37, the allocation is from an ObjectFlow called "o6" to a Connector called "epc-emg.1".

    There are a number of issues:

    1. ObjectNode is an abstract specialization of ActivityNode and as such you can't have any instances of them in a model. Any reference to an ObjectNode should be removed.

    2. The allocation should consistently be from ObjectFlow "o6" to either ItemFlow "i1" or Connector "epc-emg.1".

    3. In order to make it clear that the same items are being related, the names of the ObjectFlow and the Connector/ItemFlow should be shown on all diagrams. Currently the ObjectFlow and the Connector names are not shown.

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Update diagrams based on integrated example model

    Merged with SYSML17-185 which collects all issues regarding annex D.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Don't use the optional notation for Pins with Allocation

  • Key: SYSML17-93
  • Legacy Issue Number: 18502
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure C.35 uses the optional notation for Pins (i.e. >[]> instead of []->[]). The allocation callout note is anchored to the object node symbol which makes it ambiguous as to which dictionary item(s) are being allocated. It could be one of the following:

    + the origin and destination pins
    + the object flow
    + the common type of the pins

    Since it's unclear what is being allocated, it would make more sense to show the Pins on the diagram and link the callout note to the relevant item(s) (I believe it's supposed to go to the ObjectFlow).

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merged with SYSML17-185

    Merged with SYSML17-185 which collects all issues regarding annex D.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSML17-77
  • Legacy Issue Number: 17546
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    There is a contradiction in the SysML spec. regarding whether constraint parameters-as properties of constraint blocks-may use the derived indicator, "/".

    Pg. 84 of the spec. clearly states the original intent of the SysML Development Team with respect to constraint blocks: "The block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine."

    On pg. 86, however, the spec. states textually that constraint parameters are properties of constraint blocks: "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks."

    There is no metamodel fragment in the spec. that shows that the stereotype SysML::ConstraintParameter extends the metaclass UML4SysML::Property. The text on pg. 86 (quoted above) conveys this.

    As a result of this (implied) extension relationship, we would have to conclude that a constraint parameter could use the derived indicator, "/", to convey that it is a dependent variable in the constraint expression.

    This stands in contradiction, however, to the intended non-causal, non-directional nature of constraint blocks as expressed on pg. 84.

    Proposed Resolutions:

    1) Add a metamodel fragment to the spec. that clearly shows the extension relationship from SysML::ConstraintParameter to UML4SysML::Property.
    2) Add a constraint to the SysML::ConstraintParameter stereotype disallowing the use of the derived indicator, "/", on constraint parameters.

  • Reported: SysML 1.3 — Wed, 8 Aug 2012 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Constraint parameters do not need to be constrained to not be derived

    A constraint parameter is a normal property of a constraint block that is not typed by a constraint block. Therefore, it can also be defined as a derived property. According to the UML definition of derived properties, some constraint parameters might be derived:

    "If a Property has isDerived = true, it is derived and its value or values may be computed from other information."

    It seems not to be useful to make the distinction of derived and non-derived properties, but there is no need to forbid them, and it does not contradict the non-causal nature of constraints blocks.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Convention for enumeration not used for ControlValue

  • Legacy Issue Number: 19134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The convention

    Enumeration types: always end with “Kind” (e.g., “DependencyKind”)

    is not used for the ControlValue enumeration. It should be named ControlValueKind.

  • Reported: SysML 1.3 — Thu, 5 Dec 2013 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Convention for enumeration not used for ControlValue

    The issue affects version 1.3. It was resolved in the meantime (see SysML 1.6).

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Property Based Requirements

  • Key: SYSML17-71
  • Legacy Issue Number: 17016
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In SysML today requirements can be represented in a model only in a textual form. Being textually based these requirements often introduce ambiguity, are often redundant with other model element properties, and lack a formally making it difficult to leverage directly in parametric and other analysis efforts.
    This issue suggests an alternative means of representing requirement in the model environment without using a pure text string. The alternative means is referred to as Property Based Requirement (PBR). PBR defines a requirement mathematically and defines a set of requirement properties. The goal is declare other types of model elements as requirements and apply these properties to those model elements.

    A PBR theory is described in a paper called “Toward a Property Based Requirements Theory: System Requirements Structured as a Semilattice” by Patrice Micouin. This technique is further elaborated in a paper called “Requirements Management within a Full Model-Based Engineering Approach” by Yves Bernard

  • Reported: SysML 1.3 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Property Based Requirements

    The issue was resolved with SysML 1.4 and the new SysML element AbstractRequirement that enables the definition of different model elements being a requirement.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Inability to specify partial allocation and requriements satisfaction

  • Key: SYSML17-86
  • Legacy Issue Number: 18434
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocate and requirements relationships (e.g., satisfy, verify, derive) do not explicitly state the degree to which these relationships apply. For example, a satisfy relationship may imply a model element may fully satisfy, partially satisfy, or not satisfy at all a particular requirement at a point in the design process. However, there is no standard way to refer to this partial vs complete satisfaction. A similar issue applies to the verify and derive relationships.

    Note: Similar issues apply to allocate relationships where the allocate may indicate that the element is fully or partially allocated to another element.

    The SysML spec should consider incorporating a tagged value to indicate 0, partial or complete on these relationships.

  • Reported: SysML 1.3 — Fri, 8 Feb 2013 05:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Inability to specify partial allocation and requriements satisfaction

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSML17-66
  • Legacy Issue Number: 16652
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    InstanceSpecifications describe sets of instances, including the empty set, but some applications need to describe exactly one instance. SysML should have InstanceSpecifications that are constrained to describe exactly one instance, like the owlIndividual stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: InstanceSpecifications for exactly one instance

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

InstanceSpecification equality

  • Key: SYSML17-67
  • Legacy Issue Number: 16653
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Multiple InstanceSpecifications can describe overlapping sets of instances, and some application need to specify whether the sets overlap. For InstanceSpecifications that specify exactly one instance, this indicates whether they describe the same instance, like the sameAs stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: InstanceSpecification equality

    New features are out-of-scope for SysML 1.7 and should be covered by SysML v2 if necessary for SysML.

  • Updated: Thu, 22 Dec 2022 13:45 GMT

Incorrect constraint [2] on InterfaceBlock

  • Legacy Issue Number: 18183
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [2] specifies that "Interface blocks cannot have composite properties that are not ports". However, in order to show FlowProperties, typed by ValueTypes and owned by InterfaceBlocks, you need to be able to have composite properties.

    The constraint at the moment is too strict and needs to be changed to allow certain composite properties.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Reword constraint#2

    Modify constrain#2 as suggested and in order to merge with issue SYSML16-455 as well, as part of SYSML16-274:
    Revised text:
    Interface blocks' composite properties are either ports, value properties or flow properties_

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Update SysML references to UML model library StandardProfileL2

  • Legacy Issue Number: 19123
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The UML model library "StandardProfileL2" is called "StandardProfile" since UML 2.5. The new library also include the StandardProfileL3 library.

    Update the references in the SysML specification (chapter 4.2, 5.1.1, 17) and check whether SysML should also include the StandardProfileL3 stereotypes that are now part of the StandardProfile library.

  • Reported: SysML 1.3 — Mon, 25 Nov 2013 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    SysML references to UML StandardProfile

    The references to the UML StandardProfile were already fixed with SysML 1.4.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Problems with property-specific types

  • Key: SYSML16-76
  • Legacy Issue Number: 16636
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Definition of a property-specific type cannot be shown on a bdd. This would require, at least, a defined name for the block or value type that types the property, such as one based on the property name.

    No runtime semantics is given. Presumably all instances of a property-specific type are values of the property it types, but this isn't said anywhere. It the property it types is an end of an association, this could be expressed by a lower multiplicity greater than zero on opposite end.

    No examples of property specific types are given.

    CB, 2018-05-03: Address interaction with property subsetting/redefinition. For example redefinition that doesn't change the PST will cause it to be owned twice, because is repeated in the redefining property.

    The requirements for property-specific types to be anonymous, singly generalized, and owned by the owner of the property they type don't appear to be necessary. Naming is useful for managing PSTs, multiple generalization is useful for reusing property defaults and other characteristics on multiple PSTs, and package ownership enables the same PST to be used on multiple properties that have the same type.

    The description of the property-specific types refers to:

    "local specializations of referenced typed" (Section 8.3.1.1 Block Definition Diagram) and

    "starting classifier of the property-specific type." (Section 8.3.2.7 PropertySpecificType)

    The terms "local", "referenced type", "starting classifier nof the property specific type" are undefined and not deducible from other text.

    The following sentence is a tautology (ie, adds nothing to the spec):

    "The PropertySpecificType stereotype is automatically applied to the "classifier that types a property with a propertyspecific type. (Section "8.3.2.7 PropertySpecificType)"

    because a property with a property specific type is one where the property type has the PropertySpecificType applied.

    Section 8.3.1.1 (Block Definition Diagram) at the end says the name of the property specific type can be included in brackets, but constraint [2] of PropertySpecificType says they are anonymous.

    The discussion of compartments on internal properties in Section 8.3.1.2 (Internal Block Diagram) can be simplified by removing the discussion of property-specific types.

  • Reported: SysML 1.3 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    PST clarifications, minor corrections

    The purpose of this resolution is to clarify the semantics of the PropertySpecificType stereotype and to fix minor issues with its current description

  • Updated: Mon, 1 Apr 2019 18:17 GMT
  • Attachments:

Constraint [5] should include specializations of Requirement

  • Legacy Issue Number: 18410
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [5] states:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement»."

    This would seem to stop Requirements from owning Classes stereotyped by specializations of Requirements (for example, ExtendedRequirement from D.2.2 Stereotypes), which seems too limiting. I'd suggest this is reworded to:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement» or one of its specializations"

  • Reported: SysML 1.3 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.6
  • Disposition Summary:

    Fix constraint#5

    Fix constraint#5 as suggested, as part of SYSML16-274
    revised text:
    A nested classifier of a class stereotyped by Requirement or one of its specializations shall also be stereotyped by Requirement or one of its specializations

  • Updated: Mon, 1 Apr 2019 18:17 GMT

remove figure numbers from diagram frames

  • Key: SYSML16-92
  • Legacy Issue Number: 17423
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Remove figure numbers where they still exist within the SysML diagram frame tab. As content is reshuffled in the document, figure numbers inside the diagrams can become out-of-sync with the figure numbers in the document, as is currently the case for figures C.35 and C.37. Maintain the figure number only in the figure caption, not redundantly within the diagram itself.

    Diagrams that include figure numbers in the diagram frame tab include 4.2, 4.3, 17.5, C.35, C.36, and C.37.

  • Reported: SysML 1.3 — Tue, 12 Jun 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Remove figure numbers from diagram names

    Some figure numbers in diagram names are still there in SysML 1.5, and they are out-of-sync with the numbering in the document.

    To decouple them we remove all numberings from the diagrams as proposed.

    The following mentioned figures are already fixed in SysML 1.5:
    Figure 4.2., Figure 4.3

    Figure C.35 is D.38, and C.36 is D.39 in SysML 1.5

  • Updated: Mon, 1 Apr 2019 18:17 GMT

View and Viewpoint Limitations in support of auto-view generation

  • Legacy Issue Number: 18391
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

    At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.
    The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:
    Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
    View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.
    Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.
    Some of the limitations that have been identified include the following:
    a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.)
    The viewpoint method does not include provisions for specifying the language for the methods. Adding the ability to designate the language would clarify viewpoint.
    b) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application.
    c) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders.
    d) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information.
    A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is described below.
    In a simple example, different subviews may correspond to different sections of a document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata ).
    In this example, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents.
    e) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others.
    f) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.
    g) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).

  • Reported: SysML 1.3 — Mon, 28 Jan 2013 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.6
  • Disposition Summary:

    View and Viewpoint for auto-view generation

    The View and Viewpoint elements were changed with SysML 1.4 to address the points mentioned in the issue.

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Ports and Flows

  • Legacy Issue Number: 18458
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The title of section 9.4.2 includes the term "Flow Ports", which is deprecated. I think it should be "Flow properties". Maybe an editing instruction for a 1.3 issue exists for this, not sure.

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.6
  • Disposition Summary:

    Revise title for section 9.4.2

    Replace the title of section 9.4.2 which is currently "Flow ports and Item Flows" by "Ports and Item Flows"

  • Updated: Mon, 1 Apr 2019 18:17 GMT

InstanceSpecification equality

  • Key: SYSML16-78
  • Legacy Issue Number: 16653
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Multiple InstanceSpecifications can describe overlapping sets of instances, and some application need to specify whether the sets overlap. For InstanceSpecifications that specify exactly one instance, this indicates whether they describe the same instance, like the sameAs stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSML16-77
  • Legacy Issue Number: 16652
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    InstanceSpecifications describe sets of instances, including the empty set, but some applications need to describe exactly one instance. SysML should have InstanceSpecifications that are constrained to describe exactly one instance, like the owlIndividual stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:17 GMT

Callout notation for port-specific types and initial values

  • Key: SYSML16-91
  • Legacy Issue Number: 17406
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification allows property-specific types and property-specific initial values. Ports are just a special kind of property. Thus it would be possible to model port-specific types and values. The only problem is, that it is not possible to show the specifics of these types or the initial values within an internal block diagram, as would be the case for a property.

    Suggested addition to the spec

    • property-specific types and initial values also apply to ports [would not be forbidden now, but just to clarify this point]
    • A callout notation can be used in an ibd for ports with a port-specific type or initial value. It shows the same information as the compartments for properties.
    • Table 8.3: Example for call-out notation

    Maybe this notation could also be used on block definition diagrams, and in this case for properties as well. Then there should be a sentence in chapter 8.1.1.1 and an example in Table 8.2.

  • Reported: SysML 1.3 — Tue, 5 Jun 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Property Based Requirements

  • Key: SYSML16-84
  • Legacy Issue Number: 17016
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In SysML today requirements can be represented in a model only in a textual form. Being textually based these requirements often introduce ambiguity, are often redundant with other model element properties, and lack a formally making it difficult to leverage directly in parametric and other analysis efforts.
    This issue suggests an alternative means of representing requirement in the model environment without using a pure text string. The alternative means is referred to as Property Based Requirement (PBR). PBR defines a requirement mathematically and defines a set of requirement properties. The goal is declare other types of model elements as requirements and apply these properties to those model elements.

    A PBR theory is described in a paper called “Toward a Property Based Requirements Theory: System Requirements Structured as a Semilattice” by Patrice Micouin. This technique is further elaborated in a paper called “Requirements Management within a Full Model-Based Engineering Approach” by Yves Bernard

  • Reported: SysML 1.3 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Missing type constraints for FullPort

  • Key: SYSML16-99
  • Legacy Issue Number: 18182
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Ports stereotyped as FullPort can currently be typed by anything a normal Port can be typed by. This isn't the intent of the specification, so constraints should be added.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Missing ownership constraints

  • Key: SYSML16-98
  • Legacy Issue Number: 18181
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The FlowProperty stereotype can current be applied to any Property in SysML. However, this leaves it open to applying the stereotype to Ports (inc. extensions of Ports) and Properties owned by non-Blocks. This doesn't seem to match the intent of the specification so constraints need to be added

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSML16-95
  • Legacy Issue Number: 17546
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    There is a contradiction in the SysML spec. regarding whether constraint parameters-as properties of constraint blocks-may use the derived indicator, "/".

    Pg. 84 of the spec. clearly states the original intent of the SysML Development Team with respect to constraint blocks: "The block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine."

    On pg. 86, however, the spec. states textually that constraint parameters are properties of constraint blocks: "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks."

    There is no metamodel fragment in the spec. that shows that the stereotype SysML::ConstraintParameter extends the metaclass UML4SysML::Property. The text on pg. 86 (quoted above) conveys this.

    As a result of this (implied) extension relationship, we would have to conclude that a constraint parameter could use the derived indicator, "/", to convey that it is a dependent variable in the constraint expression.

    This stands in contradiction, however, to the intended non-causal, non-directional nature of constraint blocks as expressed on pg. 84.

    Proposed Resolutions:

    1) Add a metamodel fragment to the spec. that clearly shows the extension relationship from SysML::ConstraintParameter to UML4SysML::Property.
    2) Add a constraint to the SysML::ConstraintParameter stereotype disallowing the use of the derived indicator, "/", on constraint parameters.

  • Reported: SysML 1.3 — Wed, 8 Aug 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Inability to specify partial allocation and requriements satisfaction

  • Legacy Issue Number: 18434
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocate and requirements relationships (e.g., satisfy, verify, derive) do not explicitly state the degree to which these relationships apply. For example, a satisfy relationship may imply a model element may fully satisfy, partially satisfy, or not satisfy at all a particular requirement at a point in the design process. However, there is no standard way to refer to this partial vs complete satisfaction. A similar issue applies to the verify and derive relationships.

    Note: Similar issues apply to allocate relationships where the allocate may indicate that the element is fully or partially allocated to another element.

    The SysML spec should consider incorporating a tagged value to indicate 0, partial or complete on these relationships.

  • Reported: SysML 1.3 — Fri, 8 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Figure 15.8 diagram type

  • Legacy Issue Number: 18409
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 15.8 (Example of Structural Allocation) is an ibd, but has blocks instead of parts in it. Is it supposed to be a bdd?

  • Reported: SysML 1.3 — Fri, 27 Jun 2014 11:16 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Libraries package should be named "SysML Model Libraries"

  • Legacy Issue Number: 18462
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The spec headings refer to model libraries using the adjective "model", so the package name should include it also. The name should start with "SysML" since it is separate from the SysML package.

  • Reported: SysML 1.3 — Sun, 17 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Allocated notation on object nodes missing from diagram elements table

  • Legacy Issue Number: 18461
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Allocations, the Diagram Element table is missing the notation for allocated object nodes shown in Figure 15.7 (Example of flow allocation from ObjectNode to FlowProperty).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Allocation tabular notation normative?

  • Legacy Issue Number: 18460
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The clause Allocations, Usage Example, Tabular Representation is in the normative part of the spec, but refers to a tabular notation in Annex C, which isn't normative. Is the tabular notation normative?

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Figures 15.5 and 15.6 diagram types

  • Legacy Issue Number: 18459
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figures 15.5 (Example of flow allocation from ObjectFlow to Connector) and 15.6 (Example of flow allocation from ObjectFlow to ItemFlow) have ibds on the right, but those ibds have blocks instead of parts in them. Are they supposed to be a bdds? The blocks show parts, but the compartment doesn't say "structured" (same for Figure 15.8).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Clarification required for Copy relationship

  • Legacy Issue Number: 18525
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    There's a few issues with the Copy relationship as described in the specification.

    1. It's unclear what constraint 3 means. What are subrequirements (nested or derived)?

    2. How do you match subrequirements in the slave to subrequirements in the master?

    3. There's no constraint on the number of Copy relationships that a slave Requirement can be involved in (e.g. one Requirement could be the slave of two different master Requirements). What happens to the "text" tag if there are multiple masters?

    4. There's no constraint stopping a Requirement from being directly or indirectly a master of itself. Shouldn't there be?

  • Reported: SysML 1.3 — Mon, 4 Mar 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Diagram show inconsistent data

  • Legacy Issue Number: 18503
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Diagrams C.35, C.36 and C.37 show inconsistent allocation between the displayed items, yet the text would seem to imply that they're supposed to show the same relationships.

    In C.35, the allocation is from an ObjectNode symbol called "DriveCurrent" (which I believe equates to an ObjectFlow - name unknown) to an ItemFlow called "i1".

    In C.36, the allocation is from an ObjectNode called "DriveCurrent" to a Connector (name unknown).

    In C.37, the allocation is from an ObjectFlow called "o6" to a Connector called "epc-emg.1".

    There are a number of issues:

    1. ObjectNode is an abstract specialization of ActivityNode and as such you can't have any instances of them in a model. Any reference to an ObjectNode should be removed.

    2. The allocation should consistently be from ObjectFlow "o6" to either ItemFlow "i1" or Connector "epc-emg.1".

    3. In order to make it clear that the same items are being related, the names of the ObjectFlow and the Connector/ItemFlow should be shown on all diagrams. Currently the ObjectFlow and the Connector names are not shown.

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Don't use the optional notation for Pins with Allocation

  • Legacy Issue Number: 18502
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure C.35 uses the optional notation for Pins (i.e. >[]> instead of []->[]). The allocation callout note is anchored to the object node symbol which makes it ambiguous as to which dictionary item(s) are being allocated. It could be one of the following:

    + the origin and destination pins
    + the object flow
    + the common type of the pins

    Since it's unclear what is being allocated, it would make more sense to show the Pins on the diagram and link the callout note to the relevant item(s) (I believe it's supposed to go to the ObjectFlow).

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Convention for enumeration not used for ControlValue

  • Legacy Issue Number: 19134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The convention

    Enumeration types: always end with “Kind” (e.g., “DependencyKind”)

    is not used for the ControlValue enumeration. It should be named ControlValueKind.

  • Reported: SysML 1.3 — Thu, 5 Dec 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Legacy Issue Number: 18678
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the Constraints section the specification states the following:

    'An Action appearing in an “AllocateActivityPartition” will be the /client (from) end of an “allocate” dependency. The element that represents the “AllocateActivityPartition” will be the /supplier (to) end of the same “allocate” dependency.'

    For Actions owned by an Activity and shown inside the partition, this constraint is clear. However, if you have a StructuredActivityNode inside a partition and that StructuredActivityNode owns an Action, how many Allocate dependencies should there be? Should there be:

    a) One allocate from the StructuredActivityNode only?
    b) One allocate dependency from the StructuredActivityNode and one from the Action inside the StructuredActivityNode?

    To make things clearer, instead of the constraints section saying:

    'An Action appearing IN an "An Action appearing in an “AllocateActivityPartition”'

    It should say something along the lines of:

    'An Action referenced in the "node" role of an “AllocateActivityPartition”'

    This would remove the ambiguity of what "in" means and allow users to decide when Allocate dependencies are created.

  • Reported: SysML 1.3 — Fri, 19 Apr 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.6
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Mon, 1 Apr 2019 18:16 GMT

Problems with property-specific types

  • Key: SYSMLR-79
  • Legacy Issue Number: 16636
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Definition of a property-specific type cannot be shown on a bdd. This would require, at least, a defined name for the block or value type that types the property, such as one based on the property name.

    No runtime semantics is given. Presumably all instances of a property-specific type are values of the property it types, but this isn't said anywhere. It the property it types is an end of an association, this could be expressed by a lower multiplicity greater than zero on opposite end.

    No examples of property specific types are given.

    The requirements for property-specific types to be anonymous, singly generalized, and owned by the owner of the property they type don't appear to be necessary. Naming is useful for managing PSTs, multiple generalization is useful for reusing property defaults and other characteristics on multiple PSTs, and package ownership enables the same PST to be used on multiple properties that have the same type.

    The description of the property-specific types refers to:

    "local specializations of referenced typed" (Section 8.3.1.1 Block Definition Diagram) and

    "starting classifier of the property-specific type." (Section 8.3.2.7 PropertySpecificType)

    The terms "local", "referenced type", "starting classifier nof the property specific type" are undefined and not deducible from other text.

    The following sentence is a tautology (ie, adds nothing to the spec):

    "The PropertySpecificType stereotype is automatically applied to the "classifier that types a property with a propertyspecific type. (Section "8.3.2.7 PropertySpecificType)"

    because a property with a property specific type is one where the property type has the PropertySpecificType applied.

    Section 8.3.1.1 (Block Definition Diagram) at the end says the name of the property specific type can be included in brackets, but constraint [2] of PropertySpecificType says they are anonymous.

    The discussion of compartments on internal properties in Section 8.3.1.2 (Internal Block Diagram) can be simplified by removing the discussion of property-specific types.

  • Reported: SysML 1.3 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Property Based Requirements

  • Key: SYSMLR-88
  • Legacy Issue Number: 17016
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In SysML today requirements can be represented in a model only in a textual form. Being textually based these requirements often introduce ambiguity, are often redundant with other model element properties, and lack a formally making it difficult to leverage directly in parametric and other analysis efforts.
    This issue suggests an alternative means of representing requirement in the model environment without using a pure text string. The alternative means is referred to as Property Based Requirement (PBR). PBR defines a requirement mathematically and defines a set of requirement properties. The goal is declare other types of model elements as requirements and apply these properties to those model elements.

    A PBR theory is described in a paper called “Toward a Property Based Requirements Theory: System Requirements Structured as a Semilattice” by Patrice Micouin. This technique is further elaborated in a paper called “Requirements Management within a Full Model-Based Engineering Approach” by Yves Bernard

  • Reported: SysML 1.3 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

InstanceSpecification equality

  • Key: SYSMLR-81
  • Legacy Issue Number: 16653
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Multiple InstanceSpecifications can describe overlapping sets of instances, and some application need to specify whether the sets overlap. For InstanceSpecifications that specify exactly one instance, this indicates whether they describe the same instance, like the sameAs stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSMLR-80
  • Legacy Issue Number: 16652
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    InstanceSpecifications describe sets of instances, including the empty set, but some applications need to describe exactly one instance. SysML should have InstanceSpecifications that are constrained to describe exactly one instance, like the owlIndividual stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

remove figure numbers from diagram frames

  • Key: SYSMLR-96
  • Legacy Issue Number: 17423
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Remove figure numbers where they still exist within the SysML diagram frame tab. As content is reshuffled in the document, figure numbers inside the diagrams can become out-of-sync with the figure numbers in the document, as is currently the case for figures C.35 and C.37. Maintain the figure number only in the figure caption, not redundantly within the diagram itself.

    Diagrams that include figure numbers in the diagram frame tab include 4.2, 4.3, 17.5, C.35, C.36, and C.37.

  • Reported: SysML 1.3 — Tue, 12 Jun 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Callout notation for port-specific types and initial values

  • Key: SYSMLR-95
  • Legacy Issue Number: 17406
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification allows property-specific types and property-specific initial values. Ports are just a special kind of property. Thus it would be possible to model port-specific types and values. The only problem is, that it is not possible to show the specifics of these types or the initial values within an internal block diagram, as would be the case for a property.

    Suggested addition to the spec

    • property-specific types and initial values also apply to ports [would not be forbidden now, but just to clarify this point]
    • A callout notation can be used in an ibd for ports with a port-specific type or initial value. It shows the same information as the compartments for properties.
    • Table 8.3: Example for call-out notation

    Maybe this notation could also be used on block definition diagrams, and in this case for properties as well. Then there should be a sentence in chapter 8.1.1.1 and an example in Table 8.2.

  • Reported: SysML 1.3 — Tue, 5 Jun 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSMLR-99
  • Legacy Issue Number: 17546
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    There is a contradiction in the SysML spec. regarding whether constraint parameters-as properties of constraint blocks-may use the derived indicator, "/".

    Pg. 84 of the spec. clearly states the original intent of the SysML Development Team with respect to constraint blocks: "The block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine."

    On pg. 86, however, the spec. states textually that constraint parameters are properties of constraint blocks: "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks."

    There is no metamodel fragment in the spec. that shows that the stereotype SysML::ConstraintParameter extends the metaclass UML4SysML::Property. The text on pg. 86 (quoted above) conveys this.

    As a result of this (implied) extension relationship, we would have to conclude that a constraint parameter could use the derived indicator, "/", to convey that it is a dependent variable in the constraint expression.

    This stands in contradiction, however, to the intended non-causal, non-directional nature of constraint blocks as expressed on pg. 84.

    Proposed Resolutions:

    1) Add a metamodel fragment to the spec. that clearly shows the extension relationship from SysML::ConstraintParameter to UML4SysML::Property.
    2) Add a constraint to the SysML::ConstraintParameter stereotype disallowing the use of the derived indicator, "/", on constraint parameters.

  • Reported: SysML 1.3 — Wed, 8 Aug 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Clarification required for Copy relationship

  • Key: SYSMLR-121
  • Legacy Issue Number: 18525
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    There's a few issues with the Copy relationship as described in the specification.

    1. It's unclear what constraint 3 means. What are subrequirements (nested or derived)?

    2. How do you match subrequirements in the slave to subrequirements in the master?

    3. There's no constraint on the number of Copy relationships that a slave Requirement can be involved in (e.g. one Requirement could be the slave of two different master Requirements). What happens to the "text" tag if there are multiple masters?

    4. There's no constraint stopping a Requirement from being directly or indirectly a master of itself. Shouldn't there be?

  • Reported: SysML 1.3 — Mon, 4 Mar 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Constraint [5] should include specializations of Requirement

  • Key: SYSMLR-110
  • Legacy Issue Number: 18410
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [5] states:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement»."

    This would seem to stop Requirements from owning Classes stereotyped by specializations of Requirements (for example, ExtendedRequirement from D.2.2 Stereotypes), which seems too limiting. I'd suggest this is reworded to:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement» or one of its specializations"

  • Reported: SysML 1.3 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Figure 15.8 diagram type

  • Key: SYSMLR-109
  • Legacy Issue Number: 18409
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 15.8 (Example of Structural Allocation) is an ibd, but has blocks instead of parts in it. Is it supposed to be a bdd?

  • Reported: SysML 1.3 — Fri, 27 Jun 2014 11:16 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

View and Viewpoint Limitations in support of auto-view generation

  • Key: SYSMLR-108
  • Legacy Issue Number: 18391
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

    At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.
    The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:
    Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
    View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.
    Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.
    Some of the limitations that have been identified include the following:
    a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.)
    The viewpoint method does not include provisions for specifying the language for the methods. Adding the ability to designate the language would clarify viewpoint.
    b) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application.
    c) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders.
    d) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information.
    A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is described below.
    In a simple example, different subviews may correspond to different sections of a document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata ).
    In this example, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents.
    e) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others.
    f) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.
    g) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).

  • Reported: SysML 1.3 — Mon, 28 Jan 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Inability to specify partial allocation and requriements satisfaction

  • Key: SYSMLR-111
  • Legacy Issue Number: 18434
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocate and requirements relationships (e.g., satisfy, verify, derive) do not explicitly state the degree to which these relationships apply. For example, a satisfy relationship may imply a model element may fully satisfy, partially satisfy, or not satisfy at all a particular requirement at a point in the design process. However, there is no standard way to refer to this partial vs complete satisfaction. A similar issue applies to the verify and derive relationships.

    Note: Similar issues apply to allocate relationships where the allocate may indicate that the element is fully or partially allocated to another element.

    The SysML spec should consider incorporating a tagged value to indicate 0, partial or complete on these relationships.

  • Reported: SysML 1.3 — Fri, 8 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Incorrect constraint [2] on InterfaceBlock

  • Key: SYSMLR-104
  • Legacy Issue Number: 18183
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [2] specifies that "Interface blocks cannot have composite properties that are not ports". However, in order to show FlowProperties, typed by ValueTypes and owned by InterfaceBlocks, you need to be able to have composite properties.

    The constraint at the moment is too strict and needs to be changed to allow certain composite properties.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Missing type constraints for FullPort

  • Key: SYSMLR-103
  • Legacy Issue Number: 18182
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Ports stereotyped as FullPort can currently be typed by anything a normal Port can be typed by. This isn't the intent of the specification, so constraints should be added.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Missing ownership constraints

  • Key: SYSMLR-102
  • Legacy Issue Number: 18181
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The FlowProperty stereotype can current be applied to any Property in SysML. However, this leaves it open to applying the stereotype to Ports (inc. extensions of Ports) and Properties owned by non-Blocks. This doesn't seem to match the intent of the specification so constraints need to be added

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Key: SYSMLR-125
  • Legacy Issue Number: 18678
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the Constraints section the specification states the following:

    'An Action appearing in an “AllocateActivityPartition” will be the /client (from) end of an “allocate” dependency. The element that represents the “AllocateActivityPartition” will be the /supplier (to) end of the same “allocate” dependency.'

    For Actions owned by an Activity and shown inside the partition, this constraint is clear. However, if you have a StructuredActivityNode inside a partition and that StructuredActivityNode owns an Action, how many Allocate dependencies should there be? Should there be:

    a) One allocate from the StructuredActivityNode only?
    b) One allocate dependency from the StructuredActivityNode and one from the Action inside the StructuredActivityNode?

    To make things clearer, instead of the constraints section saying:

    'An Action appearing IN an "An Action appearing in an “AllocateActivityPartition”'

    It should say something along the lines of:

    'An Action referenced in the "node" role of an “AllocateActivityPartition”'

    This would remove the ambiguity of what "in" means and allow users to decide when Allocate dependencies are created.

  • Reported: SysML 1.3 — Fri, 19 Apr 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Diagram show inconsistent data

  • Key: SYSMLR-120
  • Legacy Issue Number: 18503
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Diagrams C.35, C.36 and C.37 show inconsistent allocation between the displayed items, yet the text would seem to imply that they're supposed to show the same relationships.

    In C.35, the allocation is from an ObjectNode symbol called "DriveCurrent" (which I believe equates to an ObjectFlow - name unknown) to an ItemFlow called "i1".

    In C.36, the allocation is from an ObjectNode called "DriveCurrent" to a Connector (name unknown).

    In C.37, the allocation is from an ObjectFlow called "o6" to a Connector called "epc-emg.1".

    There are a number of issues:

    1. ObjectNode is an abstract specialization of ActivityNode and as such you can't have any instances of them in a model. Any reference to an ObjectNode should be removed.

    2. The allocation should consistently be from ObjectFlow "o6" to either ItemFlow "i1" or Connector "epc-emg.1".

    3. In order to make it clear that the same items are being related, the names of the ObjectFlow and the Connector/ItemFlow should be shown on all diagrams. Currently the ObjectFlow and the Connector names are not shown.

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Don't use the optional notation for Pins with Allocation

  • Key: SYSMLR-119
  • Legacy Issue Number: 18502
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure C.35 uses the optional notation for Pins (i.e. >[]> instead of []->[]). The allocation callout note is anchored to the object node symbol which makes it ambiguous as to which dictionary item(s) are being allocated. It could be one of the following:

    + the origin and destination pins
    + the object flow
    + the common type of the pins

    Since it's unclear what is being allocated, it would make more sense to show the Pins on the diagram and link the callout note to the relevant item(s) (I believe it's supposed to go to the ObjectFlow).

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Ports and Flows

  • Key: SYSMLR-114
  • Legacy Issue Number: 18458
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The title of section 9.4.2 includes the term "Flow Ports", which is deprecated. I think it should be "Flow properties". Maybe an editing instruction for a 1.3 issue exists for this, not sure.

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Libraries package should be named "SysML Model Libraries"

  • Key: SYSMLR-118
  • Legacy Issue Number: 18462
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The spec headings refer to model libraries using the adjective "model", so the package name should include it also. The name should start with "SysML" since it is separate from the SysML package.

  • Reported: SysML 1.3 — Sun, 17 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Allocated notation on object nodes missing from diagram elements table

  • Key: SYSMLR-117
  • Legacy Issue Number: 18461
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Allocations, the Diagram Element table is missing the notation for allocated object nodes shown in Figure 15.7 (Example of flow allocation from ObjectNode to FlowProperty).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Allocation tabular notation normative?

  • Key: SYSMLR-116
  • Legacy Issue Number: 18460
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The clause Allocations, Usage Example, Tabular Representation is in the normative part of the spec, but refers to a tabular notation in Annex C, which isn't normative. Is the tabular notation normative?

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Figures 15.5 and 15.6 diagram types

  • Key: SYSMLR-115
  • Legacy Issue Number: 18459
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figures 15.5 (Example of flow allocation from ObjectFlow to Connector) and 15.6 (Example of flow allocation from ObjectFlow to ItemFlow) have ibds on the right, but those ibds have blocks instead of parts in them. Are they supposed to be a bdds? The blocks show parts, but the compartment doesn't say "structured" (same for Figure 15.8).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Convention for enumeration not used for ControlValue

  • Key: SYSMLR-143
  • Legacy Issue Number: 19134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The convention

    Enumeration types: always end with “Kind” (e.g., “DependencyKind”)

    is not used for the ControlValue enumeration. It should be named ControlValueKind.

  • Reported: SysML 1.3 — Thu, 5 Dec 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Update SysML references to UML model library StandardProfileL2

  • Key: SYSMLR-142
  • Legacy Issue Number: 19123
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The UML model library "StandardProfileL2" is called "StandardProfile" since UML 2.5. The new library also include the StandardProfileL3 library.

    Update the references in the SysML specification (chapter 4.2, 5.1.1, 17) and check whether SysML should also include the StandardProfileL3 stereotypes that are now part of the StandardProfile library.

  • Reported: SysML 1.3 — Mon, 25 Nov 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.5
  • Disposition Summary:

    Defer

    Postponed to the next RTF

  • Updated: Thu, 6 Apr 2017 13:49 GMT

Expanded Usage Examples for Viewpoints

  • Key: SYSML14-46
  • Legacy Issue Number: 18988
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The resolutions to issues 18719 and 18653 have provided some refinements to viewpoint modeling. The current usage examples in appendix C for viewpoint modeling provide only a limited demonstration of viewpoint modeling. Some of the refinements such as ordered view hierarchies, expose relationships methods and concerns.

  • Reported: SysML 1.3 — Fri, 4 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution adds to previous resolutions made in response to issue (18653). A
    summary of the proposed changes in this resolution include:
    4. Expansion of the examples of modeling viewpoint stakeholders, concerns and
    methods
    5. View expose elements modeling
    6. View hierarchy modeling
    The current examples need to be expanded and corrected to be consistent with
    these other resolutions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Concern Relation Limitations

  • Key: SYSML14-45
  • Legacy Issue Number: 18986
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    SysML 1.3 supports the description of concerns for stakeholders and viewpoints. When modeling stakeholders and viewpoints and their respective concerns the viewpoint identifies the sub-set of the stakeholders concerns that are addressed by the viewpoint. The issue is that since these properties are currently typed by strings in the stereotype for stakeholder and viewpoint, they must be redundantly stated in both stakeholder and viewpoint description. This allows the description text to potentially diverge or conversely burden the model developer with having to change the model in 2 places.

  • Reported: SysML 1.3 — Fri, 4 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution adds to previous resolutions made in response to issue 18653. A
    summary of the proposed changes in this resolution is simply to type concern with
    the meta-class “comment” rather than string. This allows the concerns to be reusable
    but still be a simple string.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML DI

  • Key: SYSML14-43
  • Legacy Issue Number: 18983
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    UML 2.5 added support for diagram interchange. The SysML specification does not talk about diagram interchange, although modifications and extensions of the UML DI are needed.

  • Reported: SysML 1.3 — Thu, 3 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This issue is addressed by adding an informative annex for SysML DI that extends
    UML DI to support modeler options introduced by SysML, including in Annex A, and
    to explain how to apply SysML DI as needed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any notation available for internal parts should apply to ports

  • Key: SYSML14-42
  • Legacy Issue Number: 18949
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    There is a need to apply the additional notation to ports that is used for other internal properties. In particular, we need to add compartments to represent the internal properties of ports so they can be connected to.

  • Reported: SysML 1.3 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution adds notation to ports, nested ports, and their definitions to be
    consistent with other property and type notations, that includes compartments with
    graphical and textual representations of structure and behavior. This also includes
    the extensions used in parametric diagrams to represent value properties as
    rectangles so they can be bound to.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deprecated Elements update for Views and U&QK

  • Key: SYSML14-48
  • Legacy Issue Number: 19078
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The Deprecated Elements Annex should not imply deprecation of Views and Viewpoints, even though it has a transition procedure to SysmL 1.4. It should include a transition procedure for U&QK.

  • Reported: SysML 1.3 — Sun, 10 Nov 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    In the Deprecated Elements Annex, remove Views and Viewpoints from the Diagram
    Elements tables added by the resolution of 18719. Add transition procedure for
    SysML 1.4 Units and QuantityKinds. In the introduction, clarify that the Annex
    contains transitions procedures for elements that are not deprecated.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Align initial clauses with UML 2.5

  • Key: SYSML14-47
  • Legacy Issue Number: 19077
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Clauses 2-5 should be aligned with UML 2.5 and updates in SysML 1.4. For example, references to UML 2.4, compliance levels, Diagram Definition, and SysML DI.

  • Reported: SysML 1.3 — Sun, 10 Nov 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    remove references to “Superstructure” and update UML clause references for UML
    2.5. Replace StandardProfileL2 in Architecture package diagrams with
    StandardProfile, and add diagram for non-normative packages, including SysML DI

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A corrections

  • Key: SYSML14-44
  • Legacy Issue Number: 18984
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex A contains the following statements, which conflict with the UML notation:

    • a rake symbol may appear in call behavior actions. In UML, the rake symbol is mandatory.
    • a rake symbol on a state indicates that it references a state machine defined in another diagram. In UML, a “state composition” symbol is used for this purpose.

    Moreover, Annex A does not reflect the fact that the SysML DI can be used for diagram usages.

  • Reported: SysML 1.3 — Thu, 3 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This issue is addressed by removing references to call behavior actions and state machine
    references in A.2, and removing the note stating that there is no diagram metaclass in UML

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit

  • Key: SYSML14-22
  • Legacy Issue Number: 18269
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind.

    There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK.
    Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself.
    This notation could suggest that one could change the tag/values shown on the value property itself.

    It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself.
    This tool-specific practice in fact suggests that there is a missing capability; that is:

    QUDV unit and quantityKind could be specified on
    the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them)
    The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind)
    A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property)
    However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit.
    Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property.
    This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType)

    Suggest the following:

    Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind
    Add a new stereotype: ValueProperty extending UML::Property with:
    ValueProperty::unit : QUDV::Unit[0..1]
    ValueProperty::/effectiveUnit : QUDV::Unit[0..1] – it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type
    ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] – it is derived from the ValueType::quantityKind of the type of the ValueProperty.
    Add a new stereotype: QuantityValue extending UML::ValueSpecification with:
    QuantityValue::unit : QUDV::Unit[0..1]
    QuantityValue::/unitConstraint : QUDV::Unit[0..1] – if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit
    Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue

  • Reported: SysML 1.3 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution addresses the issue of the duplication of the concepts of Unit and
    QuantityKind between the SysML profile and the QUDV library by introducing a new,
    3rd model library called UnitAndQuantityKind. A separate resolution will address the
    issue of the notation for ValueType, including TypedElements (e.g. Property,
    ValueSpecification) typed by a ValueType.
    Since the SysML Architecture figures 4.2 and 4.3 need to be updated to reflect the
    addition of a new model library, this resolution also addresses the inaccuracies
    reported in issue 18456 where these figures only showed one of the 2 model
    libraries, PrimitiveValueTypes, omitting the 2nd library, ControlValues. Also, part of
    18456 involves showing the <<ModelLibrary>> stereotypes that should have been
    applied to each of SysML’s model libraries. As indicated in SysML 1.3, section 17.2,
    a SysML Model Library is a UML Package with the UML
    StandardProfileL2::ModelLibrary stereotype applied. Due to tool limitations, the BDD
    diagrams for the 2 SysML model libraries in this resolution show the UML notation for
    StandardProfileL2::ModelLibrary, that is <<ModelLibrary>> rather than the SysMLspecific
    notation which would be <<modelLibrary>> or “bdd [modelLibrary]” in the
    diagram frame. These notation details may change editorially without affecting the
    substance of the resolution.
    Originally, SysML 1.0 and 1.1 had a single concept of Unit and a single concept of
    Dimension. The duplication began in SysML 1.2 at the specification level where the concept of Dimension was renamed to QuantityKind as part of an alignment with the
    new ISO 80000-1 standard and a new conceptual model of Quantities, Units,
    Dimensions and Values (QUDV) was introduced only in the document as Annex C.5.
    The specification-level duplication became a practical problem in SysML 1.3 where
    the QUDV conceptual model became available as a non-normative machinereadable
    XMI artifact. With SysML 1.3, users and tool vendors have several options
    for modeling definitions of Units and QuantityKinds:

    • use the normative SysML stereotypes from the Blocks chapter
    • use the non-normative QUDV libraries from Annex D.4
    • use both in combination (e.g., apply the <<Unit>> stereotype to
      InstanceSpecifications classified by QUDV::Unit)
      These options multiply the cost of developing and maintaining libraries of Unit and
      QuantityKind definitions. The 3 different options above apply for defining a Unit or a
      QuantityKind. This means that there are 9 different options for defining the same pair
      of Unit/QuantityKind. Within the International System of Units alone, there are 20
      decimal prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has
      14 parts; part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table
      5 and 6 in Table 6). Thus, a complete library of all legitimate pairs of
      Unit/QuantityKind in scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed
      units and quantity kinds. It would be counter-productive and prohibitively expensive
      to attempt supporting nearly 10x different options of defining the same 1,260 pairs for
      just ISO 80000-1. SysML needs to adopt one option. Which one?
      Since the SysML Unit and QuantityKind stereotype provide a strict subset of the
      functionality of the QUDV Unit and QuantityKind concepts, this resolution effectively
      replaces the SysML::Blocks:: {Unit,QuantityKind} stereotypes with their QUDV Block
      counterparts. That is, SysML::Blocks::Unit changes from being a Stereotype to being
      a Class stereotyped by SysML’s Block. Similarly, SysML::Blocks::QuantityKind
      changes from being a Stereotype to being a Class stereotyped by SysML’s Block.
      Having changed the nature of Unit and QuantityKind from a Stereotype to a Class
      means that Unit and QuantityKind are M1-level classes, not M2-level stereotype
      extensions of metaclasses, it is important to clarify how the new Class-based Unit
      and QuantityKind concepts are intended to be used for defining particular Units and
      QuantityKinds.
      In principle, there are three ways to define Units and QuantityKinds:
      1. as M1-level InstanceSpecifications classified by
      SysML::Blocks::{Unit,QuantityKind}

      2. as M1-level Classes specializing SysML::Blocks::

      {Unit,QuantityKind}

      3. as M1-level Classes that are instances of M2-level metaclasses Unit and
      QuantityKind The third approach is outside the scope of the nature of SysML as a profile (a profile
      cannot define new metaclasses).
      The second approach requires fairly sophisticated tool support for specializing the
      associations between SysML::Blocks::Unit and SysML::Blocks::QuantityKind.
      Modeling association specialization is a challenging topic in UML because the
      mechanisms involved (i.e., generalization, redefinition, subsetting) have subtle
      distinctions (e.g., subsetting and redefinition are, respectively, in the domain of
      extensional vs. intentional semantics respectively) and the consequences of their
      combinations are difficult to analyze (e.g., disjoint vs. overlapping specialization).
      These modeling challenge carry over to definitions of new ValueTypes where the
      associations between ValueType and Unit/QuantityKind have to be specialized as
      well. The specialization approach is particularly challenging to understand because it
      inherently leads to asking questions about the meaning of the class-based
      specializations of Unit/QuantityKind and about the existence and meaning of
      instances of these classes.
      The first approach based on InstanceSpecifications approach avoids the complexity
      of the Class-based specialization of the 2nd approach. However, this
      InstanceSpecification-based approach requires careful attention about the UML tool
      support for modeling link instances of associations. In particular, such links must be
      fully specified with slots for each association’s end property regardless of its
      ownership by the association or classifier typing the opposite end. This tool support is
      important for the unambiguous interpretation of an InstanceSpecification classified by
      an Association as a representation of an instance of that Association between the
      InstanceSpecifications interepreted as representations of instances of the related
      Classifiers typing the ends of that Association.
      This resolution adopts the first approach, i.e., the M1-level InstanceSpecification
      based paradigm for defining Units and QuantityKinds. To maintain the separation
      between the normative SysML profile and the non-normative QUDV conceptual
      model, this resolution splits the QUDV::Unit and QuantityKind in two parts:

    • the part corresponding to the SysML 1.3 Unit/QuantityKind stereotypes that
      will be refactored into Block definitions in a new UnitAndQuantityKind model
      library
    • the rest that is unique to QUDV and that will be refactored as a specialization
      of the corresponding blocks from the UnitAndQuantityKind model library
      Because this resolution effectively promotes the QUDV concepts of Unit and
      QuantityKind into the normative SysML profile, the normative specification of these
      concepts is aligned to the publicly available VIM3 document instead of the non-public
      ISO-80000-1 document.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

N-ary Allocation needs better definition, or deletion

  • Key: SYSML14-21
  • Legacy Issue Number: 17562
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    An unnumbered constraint on the Allocate relationship states: "A single «allocate» dependency shall have only one client (from), but may have one or many suppliers (to)."

    The use or meaning of this n-ary relationship is not described. An informal survey of RTF members indicated that this n-ary allocation capability has not been implemented in any tool, nor has it been used by practitioners.

    Note that Satisfy relationship (see 16.3.2.6) serves a similar purpose to Allocate, but does not require an n-ary implementation.

    Removal of the n-ary requirement on Allocate would simplify efforts to unify SysML relationship dependencies. This requirement should either be 1) rationalized, elaborated and applied consistently across similar SysML relationships, or 2) deleted to facilitate ongoing SysML improvements.

  • Reported: SysML 1.3 — Thu, 23 Aug 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    To simplify SysML, the 1.4 RTF resolved to remove n-ary allocations from the
    specification. The functionality that might be enabled by n-ary allocations can be
    supported by constraints across multiple binary allocations.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.3.2.8 FullPort

  • Key: SYSML14-10
  • Legacy Issue Number: 17254
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.8 FullPort - in description it says it cannot be conjugated. 1. Why? 2. Why there is no constraint for that?
    what constraint 2 means? when binding connector is connector to proxy port?

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    See Issue 18278 (Conjugation of full ports question) for the answer to the question
    about full port conjugation.
    The reason for constraint 2 is that if we have a binding connector between a full port
    and a part of the owning block that is not a port, it means the full port is no longer a
    separate element of the system. Fulls ports bound to proxy ports are still separate
    elements of the system because proxy ports do not specify separate elements of the
    system. Constraint 2 should be generalized to cover all cases.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???

  • Key: SYSML14-9
  • Legacy Issue Number: 17253
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.4 DirectedFeature , constraint 4 - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all?
    constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties???
    what does it mean "the meaning of direction"?? how direction is visible on port? what happens on nested ports when owning port is conjugated? example is needed.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The text of this issue was split into issues 18438, 18439, and 18441 so that the
    multiple issues raised could be addressed in separate resolutions. All the text in this
    issue is contained in one of these newer issues, so this original source issue is no
    longer needed.
    Disposition: See issues 18438, 18439, and 18441 for resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ControlOperator stereotype should also extend the CallBehaviorAction metaclass

  • Key: SYSML14-20
  • Legacy Issue Number: 17549
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Table 11.1 on pg. 93 shows that the «controlOperator» stereotype can be applied to a call behavior action (when that call behavior action calls an activity that also has the «controlOperator» stereotype applied). However, the metamodel fragment on pg. 104 and the stereotype description on pg. 105 do not support that. Currently the spec. states that SysML::ControlOperator only extends UML4SysML::Behavior and UML4SysML::Operation, not UML4SysML::CallBehaviorAction. This would be appropriate, though, and seems to be in keeping with the original intent of the SysML Development Team given that it appears in Table 11.1

    Proposed Resolution: Add another extension relationship from SysML::ControlOperator to UML4SysML::CallBehaviorAction.

  • Reported: SysML 1.3 — Fri, 10 Aug 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    This diagram extension is illustrated in Figure 11.2 (CallBehaviorAction notation) and
    explained in the text above it. The metamodel is not extended.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Requirements should be disallowed from typing other elements

  • Key: SYSML14-19
  • Legacy Issue Number: 17529
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The concept of Requirement, as intended in the original SysML specification, included the notion that textual requirements only have meaning in their original context. Requirements thus should not provide a source of inheritance. This precludes their use as classifiers for typing other Requirements or any other model elements. The 5 constraints listed at the end of section 16.3.2.3 are currently insufficient to enforce this concept.

    Recommend adding a 6th constraint, precluding a class stereotyped by <<requirement>> from typing any other model element.

  • Reported: SysML 1.3 — Thu, 26 Jul 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Add a 6th constraint to the text as recommended in the summary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML Issue Lower bounds on multiplicity not consistent with diagram

  • Key: SYSML14-16
  • Legacy Issue Number: 17443
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In SysML 1.3

    11.3.1.1 Activity constraints

    “The lower multiplicity at the part end must be zero.”

    The diagram above Figure 11.1 on the previous page does not indicate 0 as the lower end. The default for a composition relationship at the part end is 1..1 and does not include 0.

    However, as you fix the diagram consider eliminating the constraint 3.

    I believe this constraint has been eliminated from UML 2.5 (in the works). The proper constraint is something like. (Conrad will know what’s in the UML spec). If the part end action starts running when the parent activity is started, and continues until the parent activity is ended, then the minimum multiplicity is non-zero. Otherwise, the lower multiplicity at the part end must be zero.

    Whether the constraint is fixed or not, the diagram must include a lower end of zero.

    Recommended fix, eliminate the constraint and fix the diagram

    11.3.1.4.1 Constraint 3

    Similar to above. The BDD in Figure 11.5 would need to explicitly be marked to allow for 0.

    This constraint was not changed in UML. Recommend the diagram be fixed

  • Reported: SysML 1.3 — Mon, 18 Jun 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Remove Constraint [3] in 11.3.1.1.1 (Notation) for the reasons filed. Figures 11.1 and
    11.5 show generic notation. They aren’t examples, so do not need to have
    multiplicities.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML Issue: State Machine Notation

  • Key: SYSML14-18
  • Legacy Issue Number: 17445
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    13.1 Table 13.1

    The state machine decomposition symbol (which looks like eyeglass – not a rake) is not given

    13.2 Table 13.2

    The notation that comes from transition-focused state machines is included in the table. However, the notion that looks like:

    (via entry point name)

    is not indicated.

  • Reported: SysML 1.3 — Mon, 18 Jun 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Supply identified missing notation in table 13.1 and table 13.2 In addition, supply
    missing notation for StateMachineDiagram and cleanup composite state notation in
    table 13.1 (so that lines leave on axis).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML Issue: SysML Issue: Activitiy Switched on diagrams

  • Key: SYSML14-17
  • Legacy Issue Number: 17444
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In SysML 1.3 C.4.8.2

    Diagram C.34

    The «activity» ProvideElectricPower is switched with «activity»ControlElectricPower. If you switch them now, you’ll be consistent with Figure C.35

  • Reported: SysML 1.3 — Mon, 18 Jun 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Switch the two activities names and association end names.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong compartment names

  • Key: SYSML14-15
  • Legacy Issue Number: 17372
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Compartments "part" and "reference" must be renamed to "parts" and "references" in Figure 9.7 Usage example of proxy and full ports

  • Reported: SysML 1.3 — Thu, 17 May 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    Figure 9.7 in the formal SysML 1.3 specification was already corrected to use the
    standard compartment names.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Full ports compartment

  • Key: SYSML14-14
  • Legacy Issue Number: 17371
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Spec says: "Full ports can appear in block compartments labeled “full ports.” The keyword «full» before a property name indicates the property is stereotyped by FullPort. "
    a) "full ports." should be changed to "full ports". (without dot inside)
    b) does it say that even in full ports compartment keyword <<full>> is used? Or it is used near port symbol, when NOT in compartment? It should be clarified.
    c) there is no single example of this notation - nor in Table 9.1 - Graphical nodes defined in Block Definition diagrams nor in any other diagram example in spec.
    d) the same issues with "proxy ports" compartment.

  • Reported: SysML 1.3 — Thu, 17 May 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conjugation of full ports question

  • Key: SYSML14-23
  • Legacy Issue Number: 18278
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Clause 9.3.2.8, FullPort - in description it says it cannot be conjugated. 1. Why?

    This issue is a portion of issue 17254 (9.3.2.8 FullPort) and is filed to allow it to be addressed separately from the rest of 17254, and for the resolution of 17254 to ignore this portion of issue

  • Reported: SysML 1.3 — Fri, 23 Nov 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The reason for constraining the full port from being conjugated is mentioned in
    9.3.2.8 – first paragraph last sentence:
    Full ports also cannot be conjugated, because behaviors defined on their
    types are defined independently of the ports these types might be used on.
    Constraint [4] reflects this (“Full ports cannot be conjugated (isConjugated=false).”).
    The wording of the text above could be improved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9.8 - can roles be ports??

  • Key: SYSML14-13
  • Legacy Issue Number: 17258
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Figure 9.8 - can roles be ports?? or ports be association ends???? Is it new SysML notation? Where it is described??? Did we voted?
    Tools does not support that.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9.7

  • Key: SYSML14-12
  • Legacy Issue Number: 17257
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    reference properties "sp" in all subtypes must redefine "sp" from block P.
    also, p1, p2, p3 in Plug Design 1 - are they redefining or not? if yes, must be

    {redefines}

    used, if not, how <<proxy>> appears there?

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Add the suggested redefinition notations

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.3.2.10 InvocationOnNestedPortAction

  • Key: SYSML14-11
  • Legacy Issue Number: 17256
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Constraint [2] is incorrect. What does it mean "owned by the target object" ?what is object? Also, target is always the context of activity. Port can be not only owned, but inherited too.
    [3] incorrect too - it can be inherited, not owned only.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Revise the text as indicated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Part 1 of the specification

  • Key: SYSML14-4
  • Legacy Issue Number: 17246
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Part 1, there is a paragraph that says, in the context of describing the origins of SysML

    Currently it is common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers.

    This is not currently correct. It should be changed to.

    It was then common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML has started to unify the diverse modeling languages currently used by systems engineers.

  • Reported: SysML 1.3 — Mon, 19 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    In SysML 1.3, the time-relative reference of "Currently" in the first sentence was
    removed as an editorial change, so that this sentence now begins simply, "It is
    common practice ..." The sentence that follows, stating that SysML is intended to
    unify diverse modeling languages, in a manner similar to UML, does not accurately
    reflect the variety of ways that SysML can help integrate languages in a Model Based
    Systems Engineering environment. The recently completed SysML-Modelica
    Transformation Specification is an example of the use of SysML to provide a systems
    engineering context for the content expressed by another language, but not to unify
    the full content of such a language.
    Change the text of this paragraph to indicate that the goals of SysML are both to
    unify languages used by systems engineers and to support a wider range of
    discipline- and domain-specific languages.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues with XMI for SysML 1.3

  • Key: SYSML14-3
  • Legacy Issue Number: 17161
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    I am working through some examples for MEF as you suggested.

    When I look at the XMI for SysML 1.3, I find the following anomalies:

    1. The model library PrimitiveValueTypes is a Package owned by the SysML Profile. This is what the XMI says but it is not shown as such in figure 4.3 in the SysML specification.

    2. The PrimitiveValueTypes Package does have the SysML profile applied to it, but it does not have any stereotypes applied to the various DataTypes. Surely there should be elements of the following form in there:

    <sysml:ValueType xmi:id="Stereotype1" base_DataType="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-Real" />

    In order for such elements to be legal, the sysml xmlns needs to be declared. Also it’s somewhat unclear to me whether those elements should be children of the outer XMI element, or of the contained SysML package element.

  • Reported: SysML 1.3 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    These issues were raised on a draft version of proposed XMI for SysML 1.3. They
    were already resolved in the final, published version of SysML 1.3 XMI.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraint Blocks cannot have parameters

  • Key: SYSML14-1
  • Legacy Issue Number: 16594
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It looks the Parametrics chapter is inconsistent about properties of constraint blocks. In one place it says they must be constraint properties, and in others it says they do not need to be. I assume constraint blocks can have properties that are not constraint properties, and these properties are informally called "parameters", is that right? If not, how are constraint parameters represented?

    Specifically (in the beta2, inherited from 1.2):

    • Section 10.3.2.2 (ConstraintProperty), Constraints subsection says "[2]The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock."
    • Section 10.3.1.1 (Block Definition Diagram), Parameters Compartment subsection, says "Properties of a constraint block should be shown either in the constraints compartment, for nested constraint properties, or within the parameters compartment", which presumably means parameters are properties that are not constraint properties.
    • Section 10.3.2.1 (ConstraintBlock):

    Constraints Compartment subsection, says "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks"

    Constraints, "[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, ..."

  • Reported: SysML 1.3 — Thu, 13 Oct 2011 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    The removal of the ConstraintProperty stereotype by the resolution for Issue 12130
    eliminates one of the references raised by this issue. As noted by the issue,
    properties of a constraint block may be either constraint parameters or constraint properties that hold nested usages of constraint blocks. The remaining language is
    consistent with these two basic categories for the properties of a constraint block.
    Disposition: See issue 12130 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Addition of derived property notation

  • Key: SYSML14-2
  • Legacy Issue Number: 17120
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The derived property notation was originally included in SysML and removed. This notation is very helpful and should be restored. An example of how this is used can be found in Figure 7.2.1 of the 2nd edition of "A Practical Guide to SysML".

  • Reported: SysML 1.3 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Several notations on features of blocks were left out of the original SysML
    submission and addressed by subsequent issues. During the original SysML FTF,
    Issue 10381 listed several of these additional notations to be considered. Following is
    the original text of this issue originally received October 3, 2006:
    Include examples of additional feature notations in the diagram elements table
    for Blocks. Examples of UML notations that have not been excluded by SysML
    include a "/" for derived features, underline for static features, and optional
    visibility characters "+" "-" "#" "~".
    Voting on a resolution of this issue was completed by the original SysML FTF on
    February 23, 2007, as documented in the SysML FTF final report (OMG document
    ptc/2007-03-19). This resolution added the underline notation for static features to
    Table 8.1 in the Blocks chapter, but explicitly excluded the additional notations raised
    by the issue. From the issue resolution in the FTF report, "After discussion by the
    FTF, the “/” notation for derived features and visibility characters "+" "-" "#" "~" are not
    being included in SysML V1.0."
    This resolution was based on email discussion and a straw poll that occurred on the
    original FTF mailing list, in which there was debate as to which of these notations
    stemmed from software engineering practices and which belonged in a systems
    engineering context.
    Experience since then has clearly indicated that systems engineering modelers find
    the derived notation useful to indicate properties that can be fully calculated based on
    other properties. For example, they can indicate performance measures or other
    objective criteria that can be rolled up from subsystems to a higher system level, or to
    indicate dependent vs. independent values in a network of constraints. To reflect the uses of this UML notation in SysML models, and the expectation that it
    be available even though it was excluded the last time it was directly considered, add
    an example of the "/" derived property notation to Table 8.1 in the Blocks chapter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ports with flow properties are displayed the same as flow ports in SysML 1.1?

  • Key: SYSML14-8
  • Legacy Issue Number: 17252
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ports with flow properties are displayed the same as flow ports in SysML 1.1? Can we say this clearly?
    is <> notation based on flow properties only? How about directed features? Can we use the same notation to show direction?
    <> notation is used on WHAT port types? proxy ? or full or even simple ports?
    What notation (reversed?) is on conjugated port? How about nested port, when parent is conjugated?

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    The arrows only relate to flow properties (just like flow ports) – they do not relate to
    required/provided. We don't need to say "like flow ports" since flow ports were
    removed from the chapter and shifted to Annex B. According to table 9.1, any port
    typed by a type with a flow property can have this notation (since it is shown for Port).
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.1 InterfaceBlock - unnamed compartment

  • Key: SYSML14-7
  • Legacy Issue Number: 17250
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.1 InterfaceBlock - unnamed compartment?? why not "operations"? What is "void" ??? no such primate type in sysml. Better example needed.

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    SysML compartments can be unnamed, but should not be used in the specification
    for clarity. The void type should be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 9.1

  • Key: SYSML14-6
  • Legacy Issue Number: 17249
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:
    • why Integer property is under "properties" compartment? why not "value properties"?
  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    This is consistent with chapter 8 – value properties can appear in properties
    compartments.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.3.1.6

  • Key: SYSML14-5
  • Legacy Issue Number: 17247
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.1.6 The fill color of port rectangles is white and the line and text colors are black. - Notation CAN'T be related to colors

  • Reported: SysML 1.3 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Remove the following sentences from §9.3.1.6:
    The fill color of port rectangles is white and the line and text colors are black.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of unit

  • Key: SYSML14-36
  • Legacy Issue Number: 18724
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    SysML issue 18692 raised the problem of reuse of definitions of Units and QuantityKinds across SystemOfUnit and SystemOfQuantities respectively.
    For example, the SI SystemOfUnits has 7 base units: meter, kilogram, second, ampere, kelvin, mole and candela.
    These base units are in 1-1 correspondence with base quantity kinds in the ISQ: length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. (See SysML 1.3, Figure D.5).

    The association between Unit and QuantityKind where a QuantityKind is the Unit::primaryQuantityKind for a given Unit is redundant with the choice of SystemOfUnits::baseUnit and SystemOfQuantities::baseQuantityKind.
    For example, in the context of the SI, length as a baseQuantityKind of the ISQ is the "primary quantity kind" for metre as a baseUnit in the SI.
    Conversely, length as a baseQuantityKind of the ISQ is not the "primary quantity kind" for kilometre in the SI because kilometre is not a baseUnit of the SI.

    From a reuse perspective, it should be possible to define a coherent, non-SI SystemOfUnit whose baseUnits are the same as those of the SI except for replacing metre with kilometre.
    This non-SI SystemOfUnit would be coherent with respect to the ISQ because length, as a baseQuantityKind of the ISQ would still be the "primary quantity kind" for kilometre as a baseUnit of this non-SI SytemOfUnit.
    To support this flexibility of reuse of Unit and QuantityKind definitions, it is necessary to eliminate the Unit::primaryQuantityKind association from QUDV and instead derive the "primary quantity kind" of a given Unit in the context of a particular SystemOfUnit.

    Furthermore, such a non-SI SystemOfUnit could define "inch" as a QUDV::LinearConversionUnit by reference to metre. In SysML 1.3 QUDV, this would require "inch" to specify that its Unit::quantityKinds are length.
    This is redundant with the fact that metre already specifies length as its Unit::quantityKinds.
    This redundancy could lead to inconsistencies if users define derived units and forget to specify their Unit::quantityKind or do so differently than the Unit::quantityKind of their referenced unit.
    The only kind of Unit where it is logically necessary to specify Unit::quantityKind is for QUDV::SimpleUnit. In all other cases, the Unit::quantityKind collection can be derived.
    For example, for any kind of ConversionBasedUnit, it can be derived by following ConversionBasedUnit::referenceUnit and querying that Unit for its quantityKind collection.
    For a DerivedUnit, it can be derived by following DerivedUnit::factor and UnitFactor::unit and querying the Units for their quantityKind collections.

  • Reported: SysML 1.3 — Fri, 17 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    see pages 255 - 258 of ptc/2013-12-08 for details

  • Updated: Fri, 6 Mar 2015 20:58 GMT

View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g))

  • Key: SYSML14-35
  • Legacy Issue Number: 18719
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

    At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.
    The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:
    Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
    View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.
    Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.
    Some of the limitations that have been identified include the following:
    a) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application.
    b) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders.
    c) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information.
    A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is included below.

    In the above example, different subviews correspond to the different sections of the document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata).

    In the example above, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents.
    d) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others.

    e) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).

  • Reported: SysML 1.3 — Wed, 15 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    summary of the proposed changes in this resolution include:
    1. Extend View from Class instead of Package to enable means for referencing
    views.
    2. Add a presentation property to Viewpoint whose value(s) is/are the presentation
    format for the view.
    3. Establish a relationship between an instance of a view and an instance of the
    model that the view is intended to represent.
    General Background
    It should be noted that SysML’s choice of Viewpoint and View is consistent with
    industry standard definitions, and should be maintained. The intent of this resolution
    is to preserve the basic view and viewpoint concepts, and only make changes
    needed to refine the modeling elements based on industry experience applying these
    concepts.
    Expose
    The expose relationship was added to address scalability issues with package import
    as described in part b of this issue. Package import is not sufficient for dealing with
    large models because it may require a large number of import relationships to identify
    the imported elements in the package serving as a view.
    The expose relationship resolves this issue by relating the view only to model
    elements that correspond to access points to initiate the model queries performed by
    the viewpoint method. The viewpoint method determines what additional elements or
    other data will actually be part of the view relative to this access point.
    The expose relationship extends generalization. This enables the viewpoint method
    to be inherited by the view so that it represents the constructor of the view.
    View Class
    The change of view from a package to a class resolves part c of this issue. It may be
    necessary or desirable to reference other views in order to construct a view that
    conforms to a viewpoint. This results in a hierarchy of views that provides an ordered
    traversal through the views. This ordering is necessary to understand the story the
    views tell about the model.With view as a class, properties can be made for these
    view references allowing the distinction of the different view trees within the hierarchy. Additionally, view as a class supports the concept that a view instance is a
    specific artifact that is presented to the stakeholder.
    Presentation Attribute
    The presentation property was added to address issue a). In many organizations,
    stakeholders or internal standards may require explicit rules for presentation such as
    specific styles, colors and fonts defined in a stylesheets, file formats, and other
    specifications. This property is intended to provide a flexible approach that supports
    this need..

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML ISO-80000-1 libraries need update per 18269, 18435 and 18681

  • Key: SYSML14-34
  • Legacy Issue Number: 18707
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The ISO-80000-1 libraries need to be updated according to the resolutions of issues 18269, 18435 and 18681 in SysML 1.4 ballots 4 and 5.

  • Reported: SysML 1.3 — Sat, 11 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Prior to resolving 18269, there was a duplication of Unit and QuantityKind in SysML
    1.3 that had a corresponding duplication of non-normative libraries for a subset of
    ISO 80000-1:
    http://www.omg.org/spec/SysML/20120401/ISO-80000-1-QUDV.xmi
    http://www.omg.org/spec/SysML/20120401/ISO-80000-1-SysML.xmi
    As explained in the discussion of 18269, the duplication of Unit and QuantityKind
    makes completing these libraries expensive due to the combinations implied in ISO-
    80000-1: Within the International System of Units alone, there are 20 decimal
    prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has 14 parts;
    part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table 5 and 6
    in Table 6). Thus, a complete library of all legitimate pairs of Unit/QuantityKind in
    scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed units and quantity
    kinds.
    Following the resolution of 18269, the two ISO 80000-1 libraries from SysML 1.3 are
    merged into a single ISO 80000 library based on the non-normative QUDV model;
    that is, definitions of ISO 80000 units and quantity kinds are modeled as M1-level
    InstanceSpecifications classified by a kind of QUDV::Unit and QUDV::QuantityKind
    respectively.
    The name of the library is changed from ISO 80000-1 to just ISO 80000 to reflect the
    fact that the tables from which the SysML 1.2 and 1.3 ISO 80000-1 libraries came
    from are in fact summaries of units and quantities defined across several ISO 80000
    parts. For example, Table 1 in ISO 80000-1 shows the 7 base units and base
    quantities of the SI and ISQ respectively. These units and quantities come from ISO
    80000 parts 3,4,5,6,7 and 9. Annex D.4 previously showed diagrams for the ISO-80000-1-SysML library. D.4 is
    updated to show the library of units, prefixes and quantities referenced in ISO-80000-
    1 Tables 1 through 5 and from parts of Table 2 from the SI Brochure, which is not
    included in ISO 80000-1, but the contents of which was included in previous versions
    of SysML. Altogether, previous versions of SysML included definitions of units and
    quantities traceable to a small subset of ISO 80000 parts: 3,4,5,6,7,9 and 10. For
    SysML 1.4, the coverage is expanded to include all of the normative definitions of
    parts 3,4,5,6. The coverage of parts 7,9,10 remains the same. This resolution also
    includes the definition of units for bit, byte and octet and related quantities and binary
    prefixes from ISO 80000-13.
    This resolution addresses a problem reported by Hans-Peter de Koning about the
    typing of Linear and AffineConversionUnit factors and offset which were previously
    typed by Rational but should be typed by Number. This problem affects the precise
    definition of the degree as a unit of plane angle, which is not representable as a
    Rational (1 degree = Pi/180 radian).
    This resolution depends on the resolution of 18692 and 18724 in ballot 6; however,
    this resolution adds a capability for distinguishing derived units whose factors are
    reduced (e.g., joule) or not (e.g., kelvin joule per kelvin). Mathematically, a nonreduced
    derived unit is equivalent to a reduced derived unit (e.g., joule = kelvin joule
    per kelvin). This is used rarely (there are 152 derived units in total; 140 are reduced;
    only 12 are non-reduced). For the few cases where it’s been used, the justification
    stems from two general principles:

    • Ensure that all the QUDV-based derived units and quantities are
      mathematically derived in the same way as the derivations shown in their
      corresponding ISO 80000 definitions.
    • Ensure that the dependencies among the QUDV-based models of ISO 80000
      parts reflect the normative dependencies from the corresponding ISO 80000
      documents.
      The only exception to the dependency principle stems from the dual definition of a
      unit, watt per square metre, in two ISO 80000 parts (5 and 6) that have no normative
      dependency to one another (parts 5 and 6 normatively depend on ISO 80000 parts 3
      and 4). The QUDV-based model has part 6 depend on part 5.
      In SysML 1.3, Figure D.7 showed the definition of a unit named ‘catalytic activity’ for
      a quantity kind named ‘katal’. Even though this appears in ISO 80000-1, Table 3,
      there is no indexed definition of this unit or quantity kind in any ISO 80000 part. Since
      all the units and quantity kind definitions in SysML 1.4 have an indexed definition in
      some part of ISO 80000, SysML 1.4 does not include ‘catalytic activity’ nor ‘katal’.
      Note about the tables of units and quantity kinds (Figure tables D8 and D11 through
      D23): The complete details pertaining to the QUDV-based definition of each unit and each
      quantity kind are available in the machine-readable file for the ISO 80000 library. The
      symbols for these units and quantity kinds have been reproduced in Presentation
      MathML on a best-effort basis according to the ISO 80000 documents.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigation through non-properties

  • Key: SYSML14-33
  • Legacy Issue Number: 18704
  • Status: closed  
  • Source: NASA ( Mr. Chris Delp)
  • Summary:

    Many UML elements are semantically equivalent to properties, but are not properties in the abstract syntax, such as behavior parameters, activity variables and call behavior actions. This means they cannot be used with deep nested connectors and other elements requiring property navigation. Add stereotypes based on properties that have "runtime" instance values for these elements.

  • Reported: SysML 1.3 — Thu, 9 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Revise as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML: Unts and QualityKind

  • Key: SYSML14-32
  • Legacy Issue Number: 18692
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Currently, QuanttiyKind can only be part of 1 SystemOfQuantities.

    This seems wrong. For example, wouldn’t the amp and abamp, one is the SI unit and other being the emu-cgs unit of current, have the same quantity kind, current, but they might be in different SystemofQuantities.

    This exclusive association would prevent reusing existing definitions of Units & QuantityKinds for custom systems.

  • Reported: SysML 1.3 — Wed, 1 May 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This issue involves three problems related to reuse:
    1) Currently, multiplicities between Unit (resp. QuantityKind) and SystemOfUnits
    (resp. SystemOfQuantities) prevent reusing the same definitions of Units and
    Quantities across multiple systems of these.
    2) Defining units and quantity kinds as specializations of others is an important
    reuse use case.
    3) Defining units for quantities of dimension one due to such quantities
    representing a number of entities or a ratio of two quantities of the same kind.
    In both cases, Per ISO 80000-1 and VIM, the coherent derived unit for such
    quantities is the number one. This raises the question whether there is a unit
    “one” or not.
    (1) Enabling reuse:
    The resolution of issue 18681 in ballot 5 showed an updated Figure D.8 where the
    association-owned end multiplicities made it clear that, as of SysML 1.3, a Unit and a
    QuantityKind can be associated to at most one SystemOfUnits and
    SystemOfQuantities respectively even though these associations are non-composite.
    In practice, the 0-1 multiplicity on these associations precludes reusing existing
    model library definitions of Units and QuantityKinds such as ‘metre’ and ‘length’ from
    SysML’s ISO 80000-1 model library. There are three forms of reuse:
    a) reusing the same definition in different systems b) defining a system to include all the definitions from another system
    c) defining a system to reuse selected definitions from another system
    For the first form of reuse, the 0-1 association-owned end multiplicities need to be
    relaxed to 0..*. For the second and third form of reuse, it is necessary to introduce
    new associations for a system of units or quantities to include or reuse zero or more
    other system of units or quantities.
    (2) Reuse and specialization for general quantities and units
    Currently, QUDV provides limited support for defining a quantity kind as a
    specialization of another (see ISO 80000-1, 3.1 and 3.2 Notes for examples).
    Unfortunately, this capability is only available for a SpecializedQuantityKind. This
    means that, for example, it is not possible to define a DerivedQuantityKind as a
    specialization of another QuantityKind. A similar capability is needed for Units: for
    two quantity kinds QK1 and QK2, if QK1 is a specific quantity kind for the generic
    quantity kind QK2, then the unit U1 corresponding to QK1 ought to be a specific unit
    for the generic unit U2 corresponding to QK2.
    (3) Reuse and specialization related to quantities of dimension one
    This involves two cases:
    a) Derived quantities of dimension one
    Derived quantities that are intrinsically defined as indexes, levels, numbers or
    ratios all have dimension one (see ISO 80000-1, 3.8 and Annexes A3, A4).
    Specializing quantities of dimension one motivates adding a capability for
    specializing the corresponding units. For example, ISO 80000-1 3.8 and 3.9
    mention radian as an example of a derived unit for a quantity of dimension 1
    (i.e., plane angle whose dimension is length/length). However, it is also
    possible to define a SystemOfUnits/ Quantities in which radian is defined as a
    base unit for plane angle, a base quantity. In such a system, there is no
    UnitFactor nor any QuantityKindFactor available to determine that plane angle
    is a quantity with dimension one unless it is explicitly asserted.
    b) Quantities representing a number of entities
    Quantities that intrinsically represent a number of entities have dimension one;
    however such quantities carry more information than just a number per ISO
    80000-1, 3.8 Note 4. Accounting for this information requires adding a
    capability for designating a particular Unit as the unitary value for quantity
    representing a number of entities.
    This resolution addresses all 3 aspects of reuse described above by refactoring
    QUDV to:

    • enable defining a Unit or QuantityKind as a specialization of possibly multiple
      Units or QuantityKinds respectively, designate a Unit as representing a unit count of entities,
    • designate a QuantityKind as representing a number of entities,
    • designate a QuantityKind as representing a quantity of dimension one.
      This refactoring helps avoid defining a unit “one” explicitly as the unit for all quantities
      of dimension one. Doing so would have resulted in a widely reused unit “one” that
      would carry no useful information (ISO 80000-1, 3.8 Note 2). Instead, the explicit
      “quantity of dimension one” designation capability puts the emphasis on defining a
      meaningful unit for such a quantity.
      See the resolution to issue 18724 which addresses the potential problems involved in
      reusing systems of units and quantity kinds as well as the need for refactoring the
      modeling of Unit::primaryQuantityKind. For changes pertaining to
      Unit::primaryQuantityKind, see the resolution to issue 18724
  • Updated: Fri, 6 Mar 2015 20:58 GMT

QUDV's support for measurement scales is impractical

  • Key: SYSML14-31
  • Legacy Issue Number: 18681
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales:

    D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM))

    D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale)

    D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high".

    In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property.

    Unfortunately, this requires defining the "priority" measurement scale twice:

    Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition
    For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to “low”, “medium” and “high”
    From a metrology standpoint, both definitions of “priority” can be related to a definition of a Unit and a definition of a QuantityKind:

    • The QUDV-based definition of “priority” can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV “priority” scale (See SysML 1.3, Figure D.8 in section D.5.2)
    • The ValueType-based definition of “priority” can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2)

    From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of “priority” is clearly useful for typing value properties and specifying their values.

    Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since:

    • A SysML::ValueType Enumeration really defines a “scale”, thereby alleviating the need for a separate QUDV::Scale concept.
    • The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a “scale”, thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept.

    Nicolas.

  • Reported: SysML 1.3 — Sun, 21 Apr 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Follow the proposed suggestion except that providing explanations for modeling
    “scales” using SysML ValueTypes and SysML Enumeration ValueTypes is
    postponed until after peer review.
    This resolution builds on the resolution to issue 18269 from SysML 1.4 Ballot 4 and
    issue 18435 from SysML 1.4 Ballot 5.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

View and Viewpoint Property Limitations (from Issue 18391 a) and f))

  • Key: SYSML14-30
  • Legacy Issue Number: 18653
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Source:

    Jet Propulsion Lab (Chris Delp – Christopher.L.Delp@jpl.nasa.gov)

    INCOSE (Sanford A. Friedenthal – safriedenthal@gmail.com)

    Summary:

    This issue represents issues a) and f) from Issue 18391 – View and Viewpoint Limitations in Support of Auto-View Generation. An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

    At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.

    The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:

    Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.

    View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.

    Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.

    Some of the limitations that have been identified include the following:

    a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.)

    b) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.

  • Reported: SysML 1.3 — Thu, 11 Apr 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The following resolution is proposed for ballot 5. The other issues will be addressed
    in a separate ballot.
    Relative to issue a), the current viewpoint property for method is typed by string. The
    following changes are intended to enable the viewpoint method to be specified by a
    Behavior.
    Relative to issue b), the current viewpoint property for stakeholder is typed by a
    string. The following changes are intended to enable stakeholder to be represented
    by a Stakeholder stereotype that extends classifier, so that it can be reused.
    In addition, the current viewpoint property for language is typed by a string. The
    following change types language by string, but adds clarification that this string
    represents the language metamodel or profile URI.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong quantityKind for unit radian

  • Key: SYSML14-41
  • Legacy Issue Number: 18910
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In fig D.6 the quantityKind of the unit radian should be plane angle instead of radian

  • Reported: SysML 1.3 — Sat, 14 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Discussion:
    It seems that due to a copy&paste error the unit radian has a wrong quantityKind
    value.
    Disposition: See issue 18707 for resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Signal flow property description (§9.3.2.7)

  • Key: SYSML14-40
  • Legacy Issue Number: 18908
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    description of Signal flow property has the sentence: “ […] imply sending and/or receiving of a signal usage”. It seems that the word “usage” is not convenient here and is confusing. It should be removed.

  • Reported: SysML 1.3 — Thu, 12 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Subclause 9.3.2.7, Description subsection, third paragraph, relates flow properties
    typed by signals to sending signals as follows:
    Flow properties of type Signal imply sending and/or receiving of a signal
    usage. [snip] An “out” FlowProperty of type Signal means that the owning
    Block may send the signal via connectors and an “in” FlowProperty means
    that the owning block is able to receive the Signal.
    The text above does not require implementations to do anything special for flow
    properties typed by signals beyond what is normally done for flow properties,
    because it says “may”. Removing the text would not prevent implementations from
    adding semantics as the text describes, because the specification would not disallow
    it. However, the text implies alternative conforming implementations that should be
    called out, but with more specific language referring to signal events. The revised text
    should not require or prevent signals from being sent due to flow properties, because
    this would invalid existing implementations unnecessarily.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

notation for inherited features

  • Key: SYSML14-39
  • Legacy Issue Number: 18891
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Notation for inherited features. UML 2.5 has introduced a notation for inherited features. This notation is completely relevant to SysML, and should be added to the diagram elements tables. It applies to blocks, value types, signals, and other classifiers

  • Reported: SysML 1.3 — Wed, 11 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution includes provisions to add the UML 2.5 inherited features to SysML
    1.4. The following text is from the UML 2.5 specification (ptc/13-08-16) section 9.2.4:
    Members that are inherited by a Classifier may be shown on a diagram of that Classifier by
    prepending a caret ’^’ symbol to the textual representation that would be shown if the
    member were not inherited. Thus the notation for an inherited Property is defined like this:
    <inherited-property> ::= ’^’ <property>
    where <property> is specified in 9.5.4.
    Similarly, the notation for an inherited Connector is defined like this:
    <inherited-connector> ::= ’^’ <connector>
    where <connector> is specified in 11.2.4.
    Analogous notations may be used for all NamedElements that are inheritedMembers of a
    Classifier to indicate that they are inherited.
    Inherited members may also be shown in a lighter color to help distinguish them from noninherited
    members. A conforming implementation does not need to provide this option.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Addign a Behavior Compartment for Blocks

  • Key: SYSML14-38
  • Legacy Issue Number: 18889
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    SysML blocks currently include additional compartments labeled namespace and structure. This provides significant value to present various aspects of a block on a block definition diagram.

    It would be very valuable to extend the standard compartments to enable representation of behavior. The request is to include a labeled compartment called 'behavior' to contain the classifier behavior and/or any other owned behaviors in this compartment.

  • Reported: SysML 1.3 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution includes provisions to add labeled behavior compartments to blocks
    and parts that can include textual representations of classifier and owned behaviors.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing/wrong elements in diagram table (InformationFlows)

  • Key: SYSML14-37
  • Legacy Issue Number: 18846
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 9.1, ItemFlow: The concrete syntax shows elements from an ibd. But table 9.1. is about bdd.

    SysML also includes the concept of InformationFlows from UML (compliance level 3). The concrete syntax for an InformationItem or InformationFlow is missing.

  • Reported: SysML 1.3 — Thu, 1 Aug 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The concrete syntax column in the Table 9.1 row for Item Flow was a copy and paste
    mistake in the final published version of SysML 1.3. It did not correctly implement the
    resolution for Issue 16635 in ballot 4 of the SysML 1.3 RTF. The correct figure
    appears in the SysML 1.3 RTF Final Report (ptc/2011-11-08), but not in the beta
    specification (convenience) documents that accompanied this final report (ptc/2011-
    11-09 and ptc/2011-11-10).
    Correct the concrete syntax column which appears in the ItemFlow row of Tables 9.1
    and 9.2 to contain the figures already approved by the SysML 1.3 RTF in its
    resolution of Issue 16635.
    This resolution only corrects the error in producing the correct version of SysML 1.3,
    as raised by the first paragraph of this issue. This urgent fix should not be delayed by
    the question raised by the second paragraph of this issue, on whether the UML
    concept and concrete syntax for InformationFlows is included in SysML.
    The second paragraph of the issue is correct that SysML specification does not show
    all forms of UML concrete syntax for UML InformationItem and InformationFlow. In
    particular, UML has dashed-line notations for information flows and items, as well as
    «flow» , «information», and «representation» keywords, which were never included in
    SysML from its original submission.
    A separate issue can be raised to address support for UML information flows, or to
    update the contents of Clause 5, which contains the tables that define the current
    SysML 1.3 compliance levels.
    Note that the compliance definitions in Clause 5 will need to be updated in any event
    to reflect the change in UML 2.5 that “The compliance levels L0, L1, L2, and L3 have been eliminated, because they were not found to be useful in practice.” (UML 2.5
    FTF convenience documents, ptc/2013-09-05 and ptc/2013-09-06.) Again, separate
    issues can be filed to address the need for these additional changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QUDV Unit/QuantityKind name redundancy

  • Key: SYSML14-25
  • Legacy Issue Number: 18435
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind:

    <Unable to render embedded object: File (--[if !supportLists]-->a) <) not found.-[endif]->by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification)

    <Unable to render embedded object: File (--[if !supportLists]-->b) <) not found.-[endif]->by the property Unit::name and QuantityKind::name

    This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind

  • Reported: SysML 1.3 — Sun, 10 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    The duplication is indeed unnecessary. In fact, the none of the definitions of Units
    and QuantityKinds in the ISO-80000-1-QUDV library have slots for the Unit::name or
    QuantityKind::name properties. Remove Unit::name and QuantityKind::name.
    This duplication also applies to:

    • QUDV::Prefix
    • QUDV::SystemOfUnits
    • QUDV::SystemOfQuantities
      This resolution builds on the resolution to issue 18269 from SysML 1.4 Ballot 4.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

propertyPath property should be defined once and reused

  • Key: SYSML14-24
  • Legacy Issue Number: 18407
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction have exactly the same property (propertyPath). It should be defined once in a generalization of NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction

  • Reported: SysML 1.3 — Sun, 3 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Introduce an abstract stereotype for propertyPath that generalizes
    NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction.
    Constrain the specialized stereotypes to apply to connector ends, triggers, and
    invocation actions, respectively.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.3.2.4 direction of ports and their notation

  • Key: SYSML14-27
  • Legacy Issue Number: 18440
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.4 What does it mean "the meaning of direction"?? how direction is visible on port?
    This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

  • Reported: SysML 1.3 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Disposition: See issue 18439 for resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of "inherited method" in section 9.3.2.4

  • Key: SYSML14-26
  • Legacy Issue Number: 18438
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.4 DirectedFeature, constraint [2] - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all?

    This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

  • Reported: SysML 1.3 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Constraint [2] should be reworded

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Refine relationship contextualization

  • Key: SYSML14-29
  • Legacy Issue Number: 18561
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    We need a specialization of the UML standard <<refine>> stereotype within SysML in order to be able to contextualize the corresponding relationships instances just like the resolution to issue #14447 specifies for the <<trace>> stereotype.

  • Reported: SysML 1.3 — Thu, 14 Mar 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Do as suggested. For in-deep discussion about contextualization, refer to issue
    #14447.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity model library package

  • Key: SYSML14-28
  • Legacy Issue Number: 18456
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The model library for Activities should be in a new package inside the SysML::Activities package. Figure 11.9 (Control values) does not have a frame, but Figure 8.7 (Model library for primitive value types) does. They should be consistent.

  • Reported: SysML 1.3 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Disposition: See issue 18269 for resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT