${taskforce.name} Avatar
  1. OMG Task Force

SysML 1.7 RTF — All Issues

Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML17-640 Typo in brief description about Activity Diagram SysML 1.6 open
SYSML17-639 Element Name Incorrectly Shown as InternalBlockDiagram - Should be Dependency SysML 1.6 open
SYSML17-636 Conform as a Generalization is Incorrect - A View is Not a Viewpoint / 'is a' Does Not Equate to Conform SysML 1.5 open
SYSML17-637 View is not a Viewpoint SysML 1.5 open
SYSML17-500 Artifacts and «document» SysML 1.6 open
SYSML17-638 UML::Artifact is Excluded But Specification Doesn't State With What Documents/Artifacts Are to Be Represented with Instead SysML 1.7b1 open
SYSML17-635 Risk, Source and Verification Method Are Attributes of Any / All Requirements Not Just an Extended Requirement SysML 1.5 open
SYSML17-634 Issues with SysML 1.7 XMI SysML 1.6 open
SYSML17-132 ConnectorProperty notation in wrong section. SysML 1.4 SysML 1.7 Deferred closed
SYSML17-147 Diagram formality confusion SysML 1.4 SysML 1.7 Deferred closed
SYSML17-140 Causality of constraints in parametric diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-136 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 SysML 1.7 Resolved closed
SYSML17-135 No support for dot notation in activity and sequence diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-162 Add signal to constraint [1] for DistributedProperty SysML 1.5 SysML 1.7 Deferred closed
SYSML17-133 Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do. SysML 1.4 SysML 1.7 Deferred closed
SYSML17-154 Clarification of typing a binding connector SysML 1.5 SysML 1.7 Deferred closed
SYSML17-155 Inconsistency in the DirectedRelationshipPropertyPath specification SysML 1.5 SysML 1.7 Deferred closed
SYSML17-153 Replace all occurrences of "has been" by "is" SysML 1.5 SysML 1.7 Deferred closed
SYSML17-161 Add Graphical notation for General Classifier SysML 1.5 SysML 1.7 Deferred closed
SYSML17-169 Diagram header is not intuitively interpreted SysML 1.5 SysML 1.7 Deferred closed
SYSML17-175 Do not move deprecated elements SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-184 Inappropriate character for multiplying symbol with combined units SysML 1.5 SysML 1.7 Deferred closed
SYSML17-214 Hidden constraints in description of PropertySpecificType SysML 1.6 SysML 1.7 Deferred closed
SYSML17-163 Excluded UML metaclasses are not formally defined SysML 1.5 SysML 1.7 Deferred closed
SYSML17-171 DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution SysML 1.5 SysML 1.7 Deferred closed
SYSML17-164 SysML 1.6 should be based on UML 2.5.1 SysML 1.5 SysML 1.7 Resolved closed
SYSML17-149 FullPort type SysML 1.5 SysML 1.7 Deferred closed
SYSML17-271 Typos/editorials found in the SysML 1.6 specification document SysML 1.6 SysML 1.7 Resolved closed
SYSML17-237 Precise Semantics for SysML SysML 1.6 SysML 1.7 Resolved closed
SYSML17-170 DistributedProperty should be abstract SysML 1.5 SysML 1.7 Deferred closed
SYSML17-168 DistributedProperty should be abstract SysML 1.5 SysML 1.7 Duplicate or Merged closed
SYSML17-99 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.7 Deferred closed
SYSML17-104 Pull semantics for flow properties SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-95 Clarification required for Copy relationship SysML 1.3 SysML 1.7 Deferred closed
SYSML17-97 primitive types in SysML Activities SysML 1.4 SysML 1.7 Deferred closed
SYSML17-114 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 SysML 1.7 Deferred closed
SYSML17-111 Abstract syntax for the initial values SysML 1.4 SysML 1.7 Deferred closed
SYSML17-123 Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? SysML 1.4 SysML 1.7 Deferred closed
SYSML17-113 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 SysML 1.7 Deferred closed
SYSML17-116 [SysML] Semantic variation points SysML 1.4 SysML 1.7 Deferred closed
SYSML17-105 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 SysML 1.7 Deferred closed
SYSML17-112 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 SysML 1.7 Deferred closed
SYSML17-106 Semantics clarification for removing a value from an out Flow Property SysML 1.4 SysML 1.7 Deferred closed
SYSML17-102 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 SysML 1.7 Deferred closed
SYSML17-124 ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values SysML 1.4 SysML 1.7 Resolved closed
SYSML17-127 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 SysML 1.7 Deferred closed
SYSML17-128 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 SysML 1.7 Deferred closed
SYSML17-118 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 SysML 1.7 Deferred closed
SYSML17-115 Can a SysML Full Port be typed by a ValueType? SysML 1.4 SysML 1.7 Deferred closed
SYSML17-129 Definition of SysML stereotypes: association ends versus attributes SysML 1.4 SysML 1.7 Deferred closed
SYSML17-131 Parts, references, values compartments in wrong section SysML 1.4 SysML 1.7 Deferred closed
SYSML17-126 specializations of requirement should specialize AbstractRequirement SysML 1.4 SysML 1.7 Deferred closed
SYSML17-72 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 SysML 1.7 Deferred closed
SYSML17-80 Missing ownership constraints SysML 1.3 SysML 1.7 Deferred closed
SYSML17-65 Content of Requirement::/tracedTo SysML 1.4 SysML 1.7 Deferred closed
SYSML17-81 Missing type constraints for FullPort SysML 1.3 SysML 1.7 Deferred closed
SYSML17-56 Description of Item Flows SysML 1.2 SysML 1.7 Deferred closed
SYSML17-54 Blocks cannot own items flows SysML 1.2 SysML 1.7 Deferred closed
SYSML17-83 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 SysML 1.7 Deferred closed
SYSML17-88 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 SysML 1.7 Deferred closed
SYSML17-89 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.7 Deferred closed
SYSML17-96 Semantics of multiple Dependencies SysML 1.4 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-87 9.3.2.4 direction of ports SysML 1.4 SysML 1.7 Deferred closed
SYSML17-84 VerdictKind SysML 1.4 SysML 1.7 Deferred closed
SYSML17-92 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.7 Deferred closed
SYSML17-58 Item flows can have multiple types but item properties cannot SysML 1.2 SysML 1.7 Deferred closed
SYSML17-110 Update to Trace Relationship’ SysML 1.4 SysML 1.7 Deferred closed
SYSML17-100 The SysML classification of properties is incomplete SysML 1.4 SysML 1.7 Deferred closed
SYSML17-107 proxy and full port notation change request SysML 1.4 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-37 callout notation issues SysML 1.4 SysML 1.7 Deferred closed
SYSML17-42 Flow properties and activity paramters SysML 1.4 SysML 1.7 Deferred closed
SYSML17-36 Proposal to have a stereotype for reference nested property SysML 1.1 SysML 1.7 Deferred closed
SYSML17-44 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 SysML 1.7 Deferred closed
SYSML17-43 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 SysML 1.7 Deferred closed
SYSML17-40 Ability for a binding connector to be typed SysML 1.1 SysML 1.7 Deferred closed
SYSML17-38 Binding to multiplicity in parametrics SysML 1.1 SysML 1.7 Deferred closed
SYSML17-41 Inheriting Allocations SysML 1.4 SysML 1.7 Deferred closed
SYSML17-64 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 SysML 1.7 Deferred closed
SYSML17-46 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 SysML 1.7 Deferred closed
SYSML17-47 SysML 1.2 Issues: Optional with streaming SysML 1.4 SysML 1.7 Deferred closed
SYSML17-53 Another issue with allocate SysML 1.4 SysML 1.7 Deferred closed
SYSML17-45 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 SysML 1.7 Deferred closed
SYSML17-51 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 SysML 1.7 Deferred closed
SYSML17-49 SysML Issue based on UML 15369 SysML 1.4 SysML 1.7 Deferred closed
SYSML17-50 SysML Issue representation of properties as associations SysML 1.4 SysML 1.7 Deferred closed
SYSML17-48 Figure B.35 object nodes SysML 1.4 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-69 Question about the Activity decomposition in Block Definition Diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-79 Interface blocks and protocols SysML 1.4 SysML 1.7 Deferred closed
SYSML17-5 Timing diagrams SysML 1.0 SysML 1.7 Deferred closed
SYSML17-34 Allocations should not generate dependencies SysML 1.1 SysML 1.7 Deferred closed
SYSML17-31 Binding Relationships require unit conversions SysML 1.4 SysML 1.7 Deferred closed
SYSML17-35 Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect SysML 1.1 SysML 1.7 Deferred closed
SYSML17-16 ItemFlows support on Activity & Interaction Diagrams SysML 1.4 SysML 1.7 Deferred closed
SYSML17-14 Diagram interchange SysML 1.0 SysML 1.7 Deferred closed
SYSML17-33 AllocateActivityPartition and UML 2 semantics SysML 1.1 SysML 1.7 Deferred closed
SYSML17-15 Inferred Allocation on Allocate Activity Partitions SysML 1.4 SysML 1.7 Deferred closed
SYSML17-4 the use of <> is still unclear and inconsistent SysML 1.0 SysML 1.7 Deferred closed
SYSML17-28 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 SysML 1.7 Deferred closed
SYSML17-27 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 SysML 1.7 Deferred closed
SYSML17-166 Inconsistency between xmi and pdf for Trace and Refine specializations SysML 1.4 SysML 1.7 Resolved closed
SYSML17-519 PDF Specification of SystemOfQuantities not consistent with XMI SysML 1.6 SysML 1.7 Resolved closed
SYSML17-429 Figure E-6 is identical with E-5 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-185 Sample problem diagrams are inconsistent, need to refactor from integrated model SysML 1.5 SysML 1.7 Resolved closed
SYSML17-94 Diagram show inconsistent data SysML 1.3 SysML 1.7 Duplicate or Merged closed
SYSML17-493 Missing relationship between SystemOfUnits and Units SysML 1.6 SysML 1.7 Resolved closed
SYSML17-13 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 SysML 1.7 Deferred closed
SYSML17-9 BindingConnector ends multiplicity SysML 1.4 SysML 1.7 Deferred closed
SYSML17-8 Issue: Nested connector ends SysML 1.4 SysML 1.7 Deferred closed
SYSML17-510 The description of the semantics for the Overwrite stereotype is not consistent SysML 1.6 SysML 1.7 Resolved closed
SYSML17-63 TestCase should use PackageMerge SysML 1.2 SysML 1.7 Duplicate or Merged closed
SYSML17-7 standard way to describe a flow of data in sequence diagrams SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML17-222 Typo: Constraint name 8 of Adjunct Property SysML 1.6 SysML 1.7 Resolved closed
SYSML17-173 Combined call-out notation not allowed SysML 1.5 SysML 1.7 Duplicate or Merged closed
SYSML17-492 The NoBuffer specification makes a wrong statement about the UML semantics SysML 1.6 SysML 1.7 Resolved closed
SYSML17-427 Fix figure e-5 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-255 BDD representation of activity hierarchy SysML 1.5b1 SysML 1.7 Closed; No Change closed
SYSML17-458 QUDV: PrefixedUnit has no quantity kind SysML 1.6 SysML 1.7 Resolved closed
SYSML17-499 NoBuffer has no effect if it is applied on an input pin SysML 1.6 SysML 1.7 Closed; No Change closed
SYSML17-21 Annex B / Figure B27 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-23 Annex B / Figure B.38 SysML 1.0 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-22 Annex B / Figure B.35 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-25 Figure B.34 and Figure B.35 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-61 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-60 Where have stereotypes been defined? SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-24 Annex B, Figure B.29 SysML 1.0 SysML 1.7 Duplicate or Merged closed
SYSML17-12 Sample problem: Parts are added directly into package SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-521 PDF Specification of SystemOfUnits not consistent with XMI SysML 1.6 SysML 1.7 Resolved closed
SYSML17-355 'Figure 15-4: Behavior Allocation' multiple issues in the diagram and the supporting text SysML 1.6 SysML 1.7 Resolved closed
SYSML17-2 SysML: UML Qualified Associations SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-453 Figure E.8 depicts instance specifications with invalid slots SysML 1.6 SysML 1.7 Resolved closed
SYSML17-447 QUDV: SystemOfUnits constraint systemOfQuantitiesIncludesAllUnitsQuantityKinds not documented in PDF SysML 1.6 SysML 1.7 Resolved closed
SYSML17-29 Requirements interchange issue SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-460 Figure E.11: Make it a package diagram and update the URI's SysML 1.6 SysML 1.7 Resolved closed
SYSML17-445 QUDV: Constraints [1] and [2]of SystemOfUnits are operations SysML 1.6 SysML 1.7 Resolved closed
SYSML17-74 clarification, what "part property" is SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-449 QUDV: SystemOfUnits::accessibleQuantityKinds() is a copy & paste error SysML 1.6 SysML 1.7 Resolved closed
SYSML17-441 SimpleQuantityKind::dependsOnQuantityKinds() not specified as a redefinition SysML 1.6 SysML 1.7 Resolved closed
SYSML17-451 QUDV: Documentation of SystemOfUnits::getUnit() is missing SysML 1.6 SysML 1.7 Resolved closed
SYSML17-465 Figure E.19 not consistent with XMI SysML 1.6 SysML 1.7 Resolved 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-172 ConnectorProperty is redundant SysML 1.5 SysML 1.7 Resolved closed
SYSML17-506 Annex D (Sample problem) should illustrate a nominal usage of the corresponding version of SysML SysML 1.6 SysML 1.7 Resolved closed
SYSML17-251 Syntactical clarification for ConstraintBlock SysML 1.6 SysML 1.7 Duplicate or Merged closed
SYSML17-73 9.3.2.9 What is InterfaceBlock? SysML 1.4 SysML 1.7 Resolved closed
SYSML17-103 SysML Issues on Item Property values in an IBD SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-439 Return parameters of operations in annex E.5.2 have wrong parameter direction SysML 1.6 SysML 1.7 Resolved closed
SYSML17-148 Owning Block definition is unclear SysML 1.5 SysML 1.7 Resolved closed
SYSML17-11 It is not allowed in UML to display stereotypes of related elements SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-409 Figure 8-1: Wrong property notation SysML 1.6 SysML 1.7 Resolved closed
SYSML17-433 QUDV::LinearConversionUnit constraint isInvertible=true SysML 1.6 SysML 1.7 Resolved closed
SYSML17-431 QUDV::AffineConversionUnit constraint isInvertible=true SysML 1.6 SysML 1.7 Resolved closed
SYSML17-421 Description of SysMLStructureDiagram is missing SysML 1.6 SysML 1.7 Resolved closed
SYSML17-297 Figure 11-14 is identical with figure 11-13 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-411 Figure 9-5 is identical with figure 9-4 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-443 QUDV: dependOnUnits() operation is not redefined SysML 1.6 SysML 1.7 Resolved closed
SYSML17-415 Incorrect placement of sections in chapter 17 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-425 Section C.3.2.3 should not be a section, but only a headline without numbering SysML 1.6 SysML 1.7 Resolved closed
SYSML17-417 Figure 13-1 shows two identical names in the same namespace SysML 1.6 SysML 1.7 Resolved closed
SYSML17-419 Figure 12-1 shows two identical names in the same namespace SysML 1.6 SysML 1.7 Resolved closed
SYSML17-423 Remove second constraint of SysMLBehaviorDiagram SysML 1.6 SysML 1.7 Resolved closed
SYSML17-59 Definition of part SysML 1.2 SysML 1.7 Closed; No Change closed
SYSML17-435 QUDV.xmi: Prefix::symbol multiplicity should be 0..1 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-137 Missing comment for some attributes SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-139 Derived attribute should also be read only SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-52 SysML primitive value types SysML 1.4 SysML 1.7 Resolved closed
SYSML17-1 SysML: Protocol State Machines needed SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-317 Incorrect description of SysMLBlockDefinitionDiagram SysML 1.6 SysML 1.7 Resolved closed
SYSML17-109 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-141 "Allocated From" should be "Allocated" SysML 1.4 SysML 1.7 Resolved closed
SYSML17-6 Block namespace compartment: Are external relationships allowed SysML 1.4 SysML 1.7 Resolved closed
SYSML17-30 Representation of nested object nodes in activity diagrams SysML 1.1 SysML 1.7 Closed; No Change closed
SYSML17-232 Table 8.3: Row ActorPart shows Actor SysML 1.6b1 SysML 1.7 Closed; No Change closed
SYSML17-310 Figure 9-5 and 9-4 are the same SysML 1.6 SysML 1.7 Resolved closed
SYSML17-152 Parameter direction typo in XMI SysML 1.5 SysML 1.7 Resolved closed
SYSML17-150 Owned properties of an InterfaceBlock SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-17 10.3.1.2 Parametric Diagram: square box notation SysML 1.0 SysML 1.7 Resolved closed
SYSML17-39 Do parametric bindings observe derived and read-only properties SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-18 Annex B / B.4.8.3 Activity Diagram (in sample problem) SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML17-76 SysML: References to CreateEvent incorrect SysML 1.4 SysML 1.7 Resolved closed
SYSML17-101 About Rate, Continuous and Discrete SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-55 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 SysML 1.7 Closed; No Change closed
SYSML17-62 Association owning ends SysML 1.2 SysML 1.7 Closed; No Change closed
SYSML17-289 Allocate: Error in operation bodies SysML 1.6 SysML 1.7 Resolved closed
SYSML17-266 UML::ExceptionHandler should be part of SysML SysML 1.6 SysML 1.7 Resolved closed
SYSML17-3 SysML: Generalizing Activites SysML 1.4 SysML 1.7 Resolved closed
SYSML17-145 Shared parts are still parts SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-218 Stakeholder constraint is listed twice SysML 1.6 SysML 1.7 Resolved closed
SYSML17-70 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-220 Bad reference in section 4.2 SysML 1.6 SysML 1.7 Resolved closed
SYSML17-10 Lack of notation for units and dimensions on values. SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-26 SysML: Align SysML Activities with Foundational UML SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-160 DirectedFeature is confusing SysML 1.5 SysML 1.7 Resolved closed
SYSML17-181 VerdictKind enumeration missing SysML 1.6 SysML 1.7 Resolved closed
SYSML17-151 The AdjunctProperty is not clearly described SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-159 Reference Properties do not reference properties SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-239 AllocateActivityPartition: Reference to UML specification is wrong SysML 1.6b1 SysML 1.7 Resolved closed
SYSML17-156 Replace UML4SysML::Kernel by UML4SysML::Generalization SysML 1.5 SysML 1.7 Resolved closed
SYSML17-176 SysML::Trace relationship is not specialized from UML::Trace in the XMI SysML 1.5 SysML 1.7 Resolved closed
SYSML17-177 SysML::Refine relationship is not specialized from UML::Refine in the XMI SysML 1.5 SysML 1.7 Resolved closed
SYSML17-182 Verdict described incorrecty SysML 1.6 SysML 1.7 Resolved closed
SYSML17-157 Typos/editorials found in the SysML 1.5 specification document SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-167 Description of AdjunctProperty SysML 1.5 SysML 1.7 Duplicate or Merged closed
SYSML17-120 Inherit from a conjugated interface block SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-117 ElementGroup cannot be source or target of a dependency SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-122 Property path notation SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-134 AllocateActivityPartition should be more formaly related to allocation Relationship SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-125 A discarded resolution still appears in the ballot SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-142 Requirement ID should be immutable SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-144 Specify a specific part from a collection of parts on an IBD SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-143 Expand use of rake symbol for all decompositions SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-174 Connectors are not allowed in bdd SysML 1.5 SysML 1.7 Resolved closed
SYSML17-146 Numeric Literals as constraint block property parameter values SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-158 Statements missing in the abstract syntax description SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-130 Description of model elements in generated document not consistent with specification SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-165 Typo in revised text of issue SYSML16-289 SysML 1.5 SysML 1.7 Closed; No Change closed
SYSML17-121 Missing property descriptions for Probability and Rate SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-57 SysML Issue on Refine limitations SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-68 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 SysML 1.7 Duplicate or Merged closed
SYSML17-178 Virtual member representing the whole RTF SysML 1.6 SysML 1.7 Closed; Out Of Scope closed
SYSML17-71 Property Based Requirements SysML 1.3 SysML 1.7 Closed; No Change closed
SYSML17-32 Support BDD's for State Machines SysML 1.4 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-98 ProxyPort with FlowProperties SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-20 Annex B / Figure B.9 SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML17-78 How to refer to properties of an extension? SysML 1.4 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
SYSML17-138 Hanging Clauses Throughout SysML 1.4 SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-108 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-119 More than one View() operation allowed SysML 1.4 SysML 1.7 Closed; No Change closed
SYSML17-82 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 SysML 1.7 Closed; Out Of Scope closed
SYSML17-19 Annex B / Figure B.10 SysML 1.0 SysML 1.7 Closed; No Change closed
SYSML17-536 Typo: Constraint name 8 of Adjunct Property (again) SysML 1.6 open
SYSML17-515 Statement about UML semantics of ActivityPartitions is wrong SysML 1.6 open
SYSML17-494 wrong statement about UML semantics of partitions SysML 1.6 open
SYSML17-463 QUDV: Specification of PrefixedUnit should have a QuantityKind SysML 1.6 open
SYSML17-512 Added BehavioralFeatures to AdjuctProperty SysML 1.6 open
SYSML17-365 Meta-ticket: SysML-1.6: Specification body (only) figure inconsistencies and errors and related text inconsistencies SysML 1.6 open
SYSML17-252 ConstraintBlock: abstract syntax consistency SysML 1.6 open
SYSML17-507 wrong name on Figure 9-6 SysML 1.6 open
SYSML17-504 Why are FlowProperties not included in FlowDirectionKind SysML 1.6 open
SYSML17-505 The FeatureDirectionKind to which the constraint belongs is wrong SysML 1.6 open
SYSML17-502 FlowProperties as aggregations SysML 1.6 open
SYSML17-498 NoBuffer: Clarify when a token is considered "refused" SysML 1.6 open
SYSML17-233 Comments in the XMI have no annotated elements SysML 1.6b1 open
SYSML17-265 Stereotype Rate extends ObjectNode in the XMI, but not in the abstract syntax in the specification SysML 1.6 open
SYSML17-490 no longer existing "primaryQuantityKind" shown in diagram E.8 SysML 1.6 open
SYSML17-489 Removes references to UML4SYSML from the SysML diagrams SysML 1.6 open
SYSML17-485 Mentioned stereotype «distributedDefinition» does not exist SysML 1.6 open
SYSML17-488 FinalState should be an exitPoint Pseudostate SysML 1.6 open
SYSML17-487 connector properties should be in compartment SysML 1.6 open
SYSML17-486 Behavioral Ports and Nesting SysML 1.6 open
SYSML17-483 DistributedProperty definition has to be reveiwed SysML 1.6 open
SYSML17-482 The circle plus notation is for members, not ownedElements SysML 1.6 open
SYSML17-481 Consistency with Effects and Ports SysML 1.6 open
SYSML17-479 Association Rules SysML 1.6 open
SYSML17-227 About Block constraint "3" removed by SysML v1.6 SysML 1.6 open
SYSML17-480 Problems with Flows SysML 1.6 open
SYSML17-478 AcceptChangeStructuralFeatureEventAction SysML 1.6 open
SYSML17-467 Implementation of non-normative extensions cannot be used in other OMG specifications SysML 1.6 open
SYSML17-475 move to SystemOfQuantities SysML 1.6 open
SYSML17-474 rename getKindOfQuantitiesForMeasurementUnit SysML 1.6 open
SYSML17-473 OCL is not syntatically correct see ->allUnits() SysML 1.6 open
SYSML17-472 wrongfully copied SysML 1.6 open
SYSML17-471 OCL with SpecializedQuantityKind needs to be changed SysML 1.6 open
SYSML17-469 ControlValue to ControlValueKind SysML 1.6 open
SYSML17-468 Changes to Annex D sample problem figures may impact on some specification body figures SysML 1.6 open
SYSML17-366 Need constraint for inverted provided/required Interfaces (InterfaceRealization and Usage) on ~InterfaceBlock SysML 1.6 open
SYSML17-464 Constraint Typos SysML 1.6 open
SYSML17-454 QUDV: Unknown property primaryQuantityKind SysML 1.6 open
SYSML17-462 SysML model URI in the specification document SysML 1.6 open
SYSML17-455 Suggest capability to list :features on Pin symbols and on elided Pin "ObjectNode" rectangle symbol SysML 1.6 open
SYSML17-456 Suggest capability to list :features on ItemFlows in a rectangle symbol over a Connector or Association line SysML 1.6 open
SYSML17-357 Suggest introduce strict diagram policy: avoid "elided Pin" ObjectNode notation in Activity Diagrams in all revised and future specification figures SysML 1.6 open
SYSML17-438 Body conditions of operation in QUDV model should be Boolean expressions SysML 1.6 open
SYSML17-437 QUDV::PrefixedUnit: Redefinition of quantityKind SysML 1.6 open
SYSML17-430 Issues in figure E-7 SysML 1.6 open
SYSML17-414 7_composition_acyclic wrong SysML 1.6 open
SYSML17-351 If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8 SysML 1.6 open
SYSML17-408 orderedMember in ElementGroup should be {ordered} SysML 1.6 open
SYSML17-406 AbstractRequirement needs to be consistent SysML 1.6 open
SYSML17-405 Description for getSatisfies SysML 1.6 open
SYSML17-404 Parameter names mismatch in ~InterfaceBlock::areConjugated(Property, Property) SysML 1.6 open
SYSML17-401 Suggest introduce an operation to obtain the magnitude of a value property in a given compatible Unit (to afford equality comparison) SysML 1.6 open
SYSML17-399 Taken literally the text and OCL of constraint '6_valueproperties_composite' imply that every FlowProperty typed by a ValueType should have AggregationKind 'composite' SysML 1.6 open
SYSML17-400 Property types 'Four general categories of properties of blocks are recognized in SysML ...' does not cover FlowProperty SysML 1.6 open
SYSML17-367 InterfaceBlock: OCL constraint 2_no_part is missing FlowProperty check for cases where a FlowProperty is not typed by a ValueType SysML 1.6 open
SYSML17-395 Compartments for Connectors and Participants SysML 1.6 open
SYSML17-394 Suggest not allow an AssociationBlock to type a BindingConnector used for pure proxying SysML 1.6 open
SYSML17-386 All kinds of errors in Fig. 8-17 SysML 1.6 open
SYSML17-348 Figure 8-17: Vehicle specialization: multiple inconsistencies SysML 1.6 open
SYSML17-388 constraint needed SysML 1.6 open
SYSML17-393 Relationship should be specified for Stakeholder to a View SysML 1.6 open
SYSML17-392 Adjunct allows for additional notation on CallBehaviorActions SysML 1.6 open
SYSML17-391 What are redefined BoundReferences SysML 1.6 open
SYSML17-390 EndPathMultiplicity and BoundReference Ordered and Unique SysML 1.6 open
SYSML17-389 Lower and Upper Explained SysML 1.6 open
SYSML17-387 Lower and Upper are constrained SysML 1.6 open
SYSML17-385 Statement about EndPathMultiplicity SysML 1.6 open
SYSML17-384 BoundReference Specificity SysML 1.6 open
SYSML17-383 BoundReference Diagram is wrong SysML 1.6 open
SYSML17-382 Unclear English Statement SysML 1.6 open
SYSML17-377 Make Annex E Optional but Normative SysML 1.6 open
SYSML17-372 Figure E.6 QUDV Units Diagram display exactly the same content as Figure E.5 QUDV Concepts Diagram SysML 1.6 open
SYSML17-347 The 'initialValues' compartment needs to be renamed 'contextValues' and they need to be referred to as 'context-specific values' SysML 1.6 open
SYSML17-371 Suggest primary/replica as alternative to master/slave terminology for Copy relationship SysML 1.6 open
SYSML17-370 SysML-1.6: Refers to both 'composite requirement' and 'compound requirement' SysML 1.6 open
SYSML17-369 BindingConnector constraint 1_compatible_types: Use of OCL conformsTo contradicts definition of compatibility of connected ProxyPort, does not admit per Feature compatibility or compatibility via a union of connected features SysML 1.6 open
SYSML17-368 9.3.2.13 ProxyPort 'When a proxy port is connected to a single internal part ...' extend to include ' or port on an internal part' SysML 1.6 open
SYSML17-361 SysML-1.6: text on Requirement 'Test and procedure conditions' is mangled in 'Figure 16-2: Requirements Derivation' (was OK in SysML-1.5) [also affects Figure 16-6] SysML 1.6 open
SYSML17-362 'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it as 'an example of a compound requirement' SysML 1.6 open
SYSML17-349 'Figure 9-6: Usage example of ports with provided and required features' does not expose any directed features SysML 1.6 open
SYSML17-350 SysML-1.6 does not leverage redefinition of 'sp:Surface' on 'Figure 9-7: Usage example of proxy and full ports'. And does not show direction of flows on Ports symbols SysML 1.6 open
SYSML17-352 Figure 9-16 and Figure 9-17 'Usage example of item flow decomposition': multiple inconsistencies SysML 1.6 open
SYSML17-353 The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator SysML 1.6 open
SYSML17-354 Edge for [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow SysML 1.6 open
SYSML17-364 Suggest additional main body figure illustrating context-specific values (initialValues) compartment used for deep system configuration SysML 1.6 open
SYSML17-329 Inconsistent incoming ObjectFlow and outgoing ControlFlows on the DecisionNode in Figure 11.12 - Continuous system example 3 'Enable on Brake Pressure > 0' SysML 1.6 open
SYSML17-356 'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not allocate to a FlowProperty and multiple other minor issues SysML 1.6 open
SYSML17-360 Fig D.41 should be bdd with instance specs & slot values, not ibd with default values SysML 1.6 open
SYSML17-363 SysML-1.6: DeriveReqt: OCL constraint directions client vs supplier SysML 1.6 open
SYSML17-358 Trivial: consistency: Either show the [metaclass] on all Stereotype symbols or none in 'Figure 16-1: Abstract Syntax for Requirements Stereotypes' SysML 1.6 open
SYSML17-339 Figure D.24 Parametric Diagram does not explicitly show «equal» keyword or '=' on BindingConnectors SysML 1.6 open
SYSML17-344 Typo: 'not' should be 'nor' in '... not is this always even desirable' SysML 1.6 open
SYSML17-343 Typo: references to FuelTankAssy should be FuelTankAssembly for consistency with Figure D.25 SysML 1.6 open
SYSML17-334 Typo: 'Various other model elements may be necessary to help develop a derived requirement, and these model element' plural missing SysML 1.6 open
SYSML17-336 Typo: Missing end parentheses bracket: '(described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams)' SysML 1.6 open
SYSML17-330 Typo: 'with is owned by the AutomotiveDomain block.' SysML 1.6 open
SYSML17-342 Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)' SysML 1.6 open
SYSML17-341 Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.' SysML 1.6 open
SYSML17-338 Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification» SysML 1.6 open
SYSML17-332 'Figure D.7 - Elaborating Black Box Behavior' some OCL missing, State names in oclInState() should be capital first letter, and display of name of alt fragment SysML 1.6 open
SYSML17-345 SysML-1.6: Figure D.25 has the type Fuel for both an in Port and an out Port on FuelTankAssembly (and it is not ideal to have same name as the Classifier that flows) SysML 1.6 open
SYSML17-346 7.3.2.3 Expose refers to 'The method' without referencing Viewpoint SysML 1.6 open
SYSML17-340 Typo: 'Binding connectors, as defined in Clause 8 are used ...' missing comma SysML 1.6 open
SYSML17-333 Typo: 'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.' should be 'deletes' SysML 1.6 open
SYSML17-337 Typo: 9.3.2.8 FlowProperty 'A flow propertys values' SysML 1.6 open
SYSML17-335 For Connectors in IBD Figure D.4 to be typed by implied anonymous Associations need define them in BDD Figure D.15 between 'HybridSUV' and: 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment' SysML 1.6 open
SYSML17-331 In Figure D.2 Real appears to be owned by the Automotive Value Types ModelLibrary (with no explicit ElementImport) SysML 1.6 open
SYSML17-307 Lots of ControlValues that should be ControlValueKinds SysML 1.6 open
SYSML17-319 It should not be allowed to modify an AdjunctProperty SysML 1.6 open
SYSML17-316 Duplicated sentence SysML 1.6 open
SYSML17-315 Unexpected word 'Figure' in Figure 4-2 name SysML 1.6 open
SYSML17-314 Unexpected section number SysML 1.6 open
SYSML17-313 Clarify that contraint parameters are value properties SysML 1.6 open
SYSML17-308 7_cannot_redefine_boundreference is too constrained SysML 1.6 open
SYSML17-306 Aggregation multiplicities not correct SysML 1.6 open
SYSML17-300 SysML 1.6 statement is too strong SysML 1.6 open
SYSML17-299 Caveat is not specific for UseCases SysML 1.6 open
SYSML17-293 Introduction to 9.1.3 Proxy Ports and Full Ports might be interpreted as SysML only permitting Full and Proxy Ports (not standard ports) SysML 1.6 open
SYSML17-298 Continuous and Discrete need to be on FlowProperties as well SysML 1.6 open
SYSML17-296 No Creation and Destruction Event in Current UML SysML 1.6 open
SYSML17-295 Figure 9.5 missing, duplicates 9.4 SysML 1.6 open
SYSML17-290 Remove reference to non-existing properties allocatedFrom and allocatedTo SysML 1.6 open
SYSML17-286 Remove notation form ActorPart SysML 1.6 open
SYSML17-284 Conjugation Stereotype SysML 1.6 open
SYSML17-285 is the stereotype <<~InterfaceBlock>> SysML 1.6 open
SYSML17-283 Need Bound References Compartment SysML 1.6 open
SYSML17-274 Parameters and Variables don't make sense SysML 1.6 open
SYSML17-248 The definition of AdjunctProperty SysML 1.6 open
SYSML17-234 QUDV library inconsistently uses SysML::Libraries::PrimitiveValueTypes SysML 1.6b1 open
SYSML17-278 AbstractRequirement: direction of /tracedTo wrong in Attributes description SysML 1.6 open
SYSML17-277 Description of getRefines() has typo and inconsistent singular vs plural SysML 1.6 open
SYSML17-276 Description of getRefines() restricts returned elements to AbstractRequirement [0..*] but the OCL static query does not (effectively NamedElement [0..*]) SysML 1.6 open
SYSML17-275 Parts is too restrictive SysML 1.6 open
SYSML17-273 Missing guard brackets in example activity diagram 11-12 SysML 1.6 open
SYSML17-261 How to interpret non-Navigation SysML 1.6b1 open
SYSML17-258 No changebars in SysML 1.6b1 open
SYSML17-257 Proposal: patent-friendly part/element numbering system with compliant solid line SysML 1.6b1 open
SYSML17-250 Should <> have a capital V? SysML 1.6b1 open
SYSML17-249 Duplicate Elements in Table SysML 1.6b1 open
SYSML17-243 Refine / Trace relationship operations are too restrictive SysML 1.6b1 open
SYSML17-242 VerdictKind should also have the literal none SysML 1.6b1 open
SYSML17-231 ProxyPort property "matching" SysML 1.6 open
SYSML17-229 cannot model and validate physical connections SysML 1.4 open

Issues Descriptions

Typo in brief description about Activity Diagram

  • Status: open  
  • Source: OTIS Elevator Company ( pradeep miriyala)
  • Summary:

    In 3.2.1, the statement "11 Activities - Defines the extensions to UML 2 activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams. The activity diagram is used to describe the slow of control and flow of inputs and outputs among actions." mentions "slow of control".
    It should have been "flow of control".

    After correction, it shall be,
    "11 Activities - Defines the extensions to UML 2 activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams. The activity diagram is used to describe the flow of control and flow of inputs and outputs among actions."

  • Reported: SysML 1.6 — Wed, 25 Oct 2023 13:09 GMT
  • Updated: Tue, 7 Nov 2023 15:59 GMT

Element Name Incorrectly Shown as InternalBlockDiagram - Should be Dependency

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The first row of Table 8-4 shows element InternalBlockDiagram - for a connector whose Abstract Syntax ref is UML4SysML::Dependency.

    This is incorrect - it should be a Dependency connector element - identical to first row in Table 8-2

  • Reported: SysML 1.6 — Tue, 29 Aug 2023 13:23 GMT
  • Updated: Wed, 30 Aug 2023 15:28 GMT

Conform as a Generalization is Incorrect - A View is Not a Viewpoint / 'is a' Does Not Equate to Conform

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    A Conform relationship is a generalization between a view and a viewpoint.

    This is semantically incorrect. Assuming that viewpoint is being used in ISO 42010 sense (no stated anywhere within the specification so this is an error if true as the common use of 'viewpoint' is not the same as that in the standard) - a viewpoint is a specification against which a view is prepared (and interpreted). A view is not a viewpoint. What's has effectively been said is that a design that conforms to a requirement document is a requirement document.

    In the reverse sense if I want to define that an oak (tree) is an oak I wouldn't then state an Oak (tree) conforms to a Tree.

    If you need to state the conformance relationship between view and viewpoint SysML provides somewhere a 'satisfy' stereotype.

    The history of the OMG misrepresenting or misunderstanding what a 42010::viewpoint is in their documents over the years is woeful.

  • Reported: SysML 1.5 — Sun, 4 Jun 2023 09:16 GMT
  • Updated: Fri, 14 Jul 2023 20:07 GMT

View is not a Viewpoint

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The View conform Viewpoint relationship is shown as a Generalization. This then states that a View is a Viewpoint which is incorrect. A Viewpoint in ISO/IEC/IEEE 42010 terms is a specification against which a View is prepared and interpreted.

    I suspect that this is another example of a long held error where View was described as an instance of a Viewpoint. It isn’t. This has never been true in the international standard.

  • Reported: SysML 1.5 — Tue, 20 Jun 2023 11:15 GMT
  • Updated: Fri, 14 Jul 2023 20:07 GMT

Artifacts and «document»

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    the statement from v. 1.5 (section A.2)

    SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements.

    was removed from 1.6... but 1.6 retained Artifact in its UML4SYSML set...

    I think, either remove Artifact or put the statement back in

  • Reported: SysML 1.6 — Thu, 4 Nov 2021 16:13 GMT
  • Updated: Fri, 14 Jul 2023 19:59 GMT

UML::Artifact is Excluded But Specification Doesn't State With What Documents/Artifacts Are to Be Represented with Instead

  • Status: open   Implementation work Blocked
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    In Table 4.2 UML::Artifact is defined as excluded.

    In previous versions there was a paragraph Figure A.4 - 'SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. '

    This, whilst contradicting the exclusion of Artifact from SysML did at least define how artifacts/documents were to be represented. Now there is absolutely nothing other than we can't use Artifact.

    How are we supposed to represent a document? As there are few to no specialisation hierarchies in the specification it's almost impossible to see the thinking and, say, where / how deployedDocument fits into a taxonomy.

    I'm trying to create a SysML profile and I need to represent a Document, Standard, Contract etc - all artifacts in the UML sense but no idea what I should now be using in a SysML profile.

  • Reported: SysML 1.7b1 — Sat, 24 Jun 2023 11:11 GMT
  • Updated: Fri, 14 Jul 2023 19:56 GMT

Risk, Source and Verification Method Are Attributes of Any / All Requirements Not Just an Extended Requirement

  • Status: open  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The verifyMethod, source and risk attributes are only available for extended requirements i.e. a straight vanilla Requirement has no associated verification method or risk. This doesn't reflect reality / the actual taxonomy and has nothing to do with the sub-classification of a requirement as physical, functional etc. i.e. these are attributes of the parent Requirement not the child extended requirement. It also then requires that a SE has to subclassify before they can ascribe a risk level or verification method.

    Even looking at the definiton of extendedRequirements this definition has nothing to do differentiation in terms of an ontology - only the means to do things. 'A mix-in stereotype that contains generally useful attributes for requirements'

    It also means that if the SE has a requirement that doesn't fit into the OMG classification schema i.e. none of the existing categories then they cannot easily assign these attributes (e.g. a requirement to conform to a standard isn't a design constraint, isn't functional etc). These common attributes should be present without forcing the SE to subclassify before they are available.

  • Reported: SysML 1.5 — Fri, 26 May 2023 11:10 GMT
  • Updated: Thu, 15 Jun 2023 12:48 GMT

Issues with SysML 1.7 XMI


ConnectorProperty notation in wrong section.

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The diagram extension in the second paragraph of 8.3.2.6 (ConnectorProperty), should be in 8.3.1.2 (Internal Block Diagram).

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:47 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Diagram formality confusion

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    Annex A "Diagrams", whilst /informative/, sets out a confusing definition of the diagram types.

    On the one hand, there are nine SysML diagram types that have "model elements and corresponding concrete syntax", with each diagram kind cross referenced to the specific clause defining a specific part of the SysML modelling language. So for example an activity diagram "represents" (by virtue of the appropriate nodes and paths) the model elements and connectors described in the Activities clause (clause 11).

    On the other hand, there is the weaselly statement "Although the [diagram]taxonomy provides a logical organization for the various major kinds of diagrams, it does not preclude the careful mixing of different kinds of diagram types". A similar remark can be found in UML 2.5 in the form of a note in it's Annex A "Diagrams" section:
    "NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioural elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced."

    So, despite Annex A being informative, it creates at least two possible interpretations for tools to implement:
    1. A diagram can present representations of any model element and connector, or
    2. Only the specific model elements associated directly with a diagram kind (according to Annex A) can be represented on a diagram with a specific kind.

    Case 1 would allow all manner of diagrammatic mixing of model elements from the different semantic clauses, even when these clauses do not allow for any logical connection. However, it might allow an activity diagram to show a «Block» with an owned activity model. It would also allow a use case diagram to include a «Block» connected with a communications path to a use case node (since neither the use case or block clauses seem to set out a constraint to prevent this in the model).

    Case 2 would only allow the model elements from the directly associated clause along with the model elements that are common to all diagrams. This is a strict implementation, but may have consequences where more flexibility would have been desired. For example a modeller using Blocks, or user stereotyped classes, for stakeholder modelling would find that they cannot use these model elements directly on a use case diagram where only use case and actor model element types can be represented.

    The standard should also consider the practicalities of modelling tool design and usability considerations. Case 1 would imply just one diagram implementation and a large model element library (or tool bar) for the user to work with (in a model creation through the diagram paradigm). Whereas, case 2 requires distinct implementation of the diagram kinds along with their implied constraints of which model elements can be added to them, although it does mean that the model element library (or tool bar) is quite specific to each diagram kind.

    Without standardising what each diagram kind can contain, there will be no possibility of model interchange that includes the diagrams.

    On a final note, the explicit exclusion of the Profile diagram from UML seems strange because defining and working with Stereotypes is a common (albeit advanced) modelling concept in MBSE, but to do it requires specific modelling concepts (and their associated nodes and paths). Hence, the current suggestion that this is done with package diagram would seem to suggest that the aforementioned diagram case 1 was being implied.

    Suggested change (with a strict diagram syntax leaning):
    1. Make Annex A normative and remove the diagram mixing statement: "it does not preclude mixing different kinds of diagram types"
    2. Review each of the modelling clauses 8 through to 16 to check that they completely define the set of model elements and connectors that are useful to make available to modellers on the associated diagram kind. That is make explicit what is otherwise inferred by the lack of a constraint. E.g. that use case model elements can (or cannot) be connected to Blocks (or other forms of stereotyped classes) with a communication path connector.
    3. Add the UML Profile diagram to the list of SysML diagrams.

  • Reported: SysML 1.4 — Mon, 27 Feb 2017 12:56 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Causality of constraints in parametric diagrams

  • Status: closed  
  • Source: Kenntnis ( Richard Welling)
  • Summary:

    Having occasion to review all outstanding constraint block issues, I have read more closely the overview and find that the last paragraph on page 97 of the SysML 1.4 specification has significant problems. It also is the only mention in the SysML spec of constraint causality. This proposal is an attempt to clarify that paragraph while addressing concerns about constraint causality, affecting SYSMLR-99, SYSMLR-47, and SYSMLR-38. This is the paragraph as written:

    SysML identifies and names constraint blocks, but does not specify a computer interpretable language for them. The interpretation of a given constraint block (e.g., a mathematical relation between its parameter values) must be provided. An expression may rely on other mathematical description languages both to capture the detailed specification of mathematical or logical relations, and to provide a computational engine for these relations. In addition, 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.

    • The first sentence is not describing constraint blocks but rather a language for constraint expressions.
    • The second sentence again says, “block” when it is clearly referring to expressions, but then, says an “interpretation…must be provided.” By whom? Presumably by the tool provider but that's not clear.
    • The third sentence seems to say “An expression may rely on other mathematical description languages…to provide a computational engine for these relations.” It is clearly not the language that provides the computational engine but the tool implementing the language.
    • The treatment of causality is puzzling. Why was non-causality specified when causality is always at least implicit? In the F = m*a example, F is implicitly the dependent variable while a = F/m would indicate a as dependent. If the intent was to make causality non-mandatory to simplify the modeler’s task, then one could say parameters are assumed to be non-causal unless specified explicitly as such.
    • Michael Chonoles proposal (SYSMLR-47) to interpret parameters bound to derived values as dependent (output) and those bound to read-only values as independent (input) is not only useful but it should be noted that MagicDraw notates derived properties in recursive parametric diagram patterns and these clearly represent dependent variables. This is standard UML notation.

    Replace the above paragraph with the following:

    Constraint expressions may rely on any suitable mathematical description language to capture the detailed specification of mathematical or logical relations between parameters. The syntax and interpretation of the language and its associated computational engine are a tool responsibility. By default, constraints are assumed to be non-causal and do not necessarily specify dependent or independent variables, in which case specific dependent and independent variables may be defined by initial conditions and determined by the computational engine. Alternatively, dependent and independent variables (constraint parameters) may be expressed by designating their bound values as, respectively, derived ("/" prefix) or {read-only}.

    Move this paragraph to be the fourth paragraph on page 97, after paragraph starting with "Parametric diagrams include..." and before the paragraph starting with "Time can be modeled..." This places it in a logical flow that follows discussions of constraint blocks, constraints, and bindings.

  • Reported: SysML 1.4 — Sun, 22 Nov 2015 00:40 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML XMI typos in UML StandardProfile XMI references

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    http://www.omg.org/spec/SysML/20150709/SysML.xmi, I think when SysML specializes UML's standard profile, uses "_base" instead of "-base" in the reference. Here are a couple examples, might be more:

    1) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine_base_Abstraction"/>
    should be :
    <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Refine-base_Abstraction"/>

    2) <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace_base_Abstraction"/>
    should be:
    <redefinedProperty href="http://www.omg.org/spec/UML/20131001/StandardProfile.xmi#Trace-base_Abstraction"/>

  • Reported: SysML 1.4 — Sun, 21 Feb 2016 15:01 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    To be fixed

    To fix the XMI as requested

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

No support for dot notation in activity and sequence diagrams

  • Status: closed  
  • Source: GfSE e.V. ( Mr. Robert Karban)
  • Summary:

    The SysML notation does not provide a way to display nested properties as life lines on sequence diagrams or swimlanes/partitions on activity diagrams.

    Supporting dot notation would enable the user of sequence diagrams to reference nested properties and facilitate the construction of swimlanes on activity diagrams where the user now has to construct nested swimlanes.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 20:42 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Add signal to constraint [1] for DistributedProperty

  • Status: closed  
  • Source: Bombardier Transportation ( Karsten Koechlin)
  • Summary:

    At the moment the stereotype distrubtedProperty is only allowed to be applied to properties of classifier stereotyped by Block or ValueType.
    We would like to apply the distributedProperty stereotype also to properties of classifier stereotyped by Signal.
    Reason: The properties of a block are transmitted by signal properties, the properties of the signal should also reflect the distribution.

  • Reported: SysML 1.5 — Mon, 22 Jan 2018 12:43 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do.

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    An inconsistency has been noted among requirement dependencies. «copy» and «deriveReqt» are the only requirement dependencies that do NOT have an operation to 'get' the supplier end («refine», «satisfy», «verify») or the client end («trace») of the dependency. The reason for this inconsistency is not clear.

  • Reported: SysML 1.4 — Thu, 24 Mar 2016 16:30 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Clarification of typing a binding connector


Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Some DirectedRelationshipPropertyPath constraint definitions assume that the relationship on which this stereotype is applied is binary but there is no formal constraint enforcing it.

  • Reported: SysML 1.5 — Thu, 10 Aug 2017 12:27 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Replace all occurrences of "has been" by "is"

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

    In several places of the SysML specification document the term "has been" is used. It should be replaced by "is".

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 07:44 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Add Graphical notation for General Classifier

  • Status: closed  
  • Source: Sierra Nevada ( Mr. Charles Galey)
  • Summary:

    The usage of Generalization in SysML is a key part of establishing Domain Specific Languages and contexts for models. In particular it has great ability to establish reusability within our models. However, the only mechanism via which we can visually denote the nature of an object is via non-normative extensions to M2 via stereotypes such as <<Car>> or other examples. This is undesirable, we should have the ability (on classes and parts typed by those classes) to optionally display the General (or any General class of a Block) classifier of a Block on BDD's, IBD's and Parametric diagrams. This will, greatly enhance the readability of our diagrams, remove the complexity of implementing M2 stereotypes simply designed for visualization, and expose via the diagram usage of reusable libraries to make the foundation of our models.

    Example Format might be (in ASCII art):

    ------------
    <<Block>>
    [Car]
    Porsche
    --------------

  • Reported: SysML 1.5 — Fri, 20 Oct 2017 05:22 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Diagram header is not intuitively interpreted

  • Status: closed  
  • Source: INCOSE / SSI ( Troy Peterson)
  • Summary:

    The SysML diagram header is not easily interpreted. Suggest a new format that provides the same information and content but following the typical naming convention used in SysML - i.e. name:Type

    Suggestion/Example:

    From:
    req [Package] Auto_Specification [Automobile System Requirements]

    To:
    Automobile System Requirements:req | Auto_Specification:Package

    Optional format adds "[req]" as an option to turn on to in bold or white text on a black background filling the header box around the diagram kind "req" in this case. Image examples provided to Rick Steiner and Sandy Friedenthal in separate communications.

    [req] Automobile System Requirements:req | Auto_Specification:Package

  • Reported: SysML 1.5 — Thu, 13 Sep 2018 04:34 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Do not move deprecated elements

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    Between SysML 1.2 and SysML 1.3, some stereotypes were deprecated
    This deprecation was done by moving Stereotypes from their original package to a new "DeprecatedElements" package.

    Changing the qualified names of these stereotypes may break some code in tooling. Ideally the deprecation should be indicated without changing the element.

    SysML 1.3 : http://www.omg.org/spec/SysML/20120401/SysML.xmi
    SysML 1.2 :http://www.omg.org/spec/SysML/20100301/SysML-profile.uml

  • Reported: SysML 1.5 — Mon, 11 Sep 2017 15:08 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    No change

    That's not an issue about the specification but about the way of working. Request registred and agreed

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

Inappropriate character for multiplying symbol with combined units

  • Status: closed  
  • Source: Schindler Aufzüge AG ( Markus WALKER)
  • Summary:

    Some of the combined units use a period character instead of a multiply symbol. An example is the unit ‹newton metre› where the symbol is ‹N.m›. In contrary, other units make use of the middle dot character, e.g., ‹kilogram metre squared per second›, using the symbol ‹kg · m 2/s›.

    The SI Guide prescribes to use a middle dot or a thin space or if not ambiguous no character to combine different units that are multiplied.

  • Reported: SysML 1.5 — Fri, 22 Feb 2019 16:04 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Hidden constraints in description of PropertySpecificType

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

    The description of the PropertySpecificType states:

    The PropertySpecificType stereotype can be applied to classifiers that type exactly one property and that are owned by the owner of that property. Classifiers with this stereotype applied shall be generalized by at most one
    other classifier.

    The constraint section covers only "can be applied to classifiers that type exactly one property". The other constraints

    "that are owned by the owner of that property."
    and
    "Classifiers with this stereotype applied shall be generalized by at most one
    other classifier."

    are missing.

  • Reported: SysML 1.6 — Sun, 17 Mar 2019 10:25 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Excluded UML metaclasses are not formally defined

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

    Table 4.1. excludes several UML metaclasses from SysML. However, figure 4.2 shows that the SysML profile imports the whole UML. Instead, the SysML profile should use the metamodelReference and metaclassReference properties to import only the included elements.

  • Reported: SysML 1.5 — Fri, 9 Feb 2018 12:54 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution

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

    While it is not possible to check if a value conforms to, for example, uniform or mean distribution, it is possible to check, if it conforms to constraints of the specified distribution. For example, the minimum and maximum values of a uniform distribution.

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 17:14 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML 1.6 should be based on UML 2.5.1

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

    SysML should be based on the newest available UML specification. Current UML specification is version 2.5.1. SysML 1.5. is still based on UML 2.5.

  • Reported: SysML 1.5 — Fri, 23 Feb 2018 14:29 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fix it

    Agreed, to take care about it for SysML 1.7

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

FullPort type

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Split from SYSML16-86:

    What is the type of FullPort? Spec says nothing

  • Reported: SysML 1.5 — Thu, 16 Mar 2017 07:42 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Typos/editorials found in the SysML 1.6 specification document

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

    This issue is dedicated to collect all typos and editorials we find in the SysML1.6 specification document. See linked annotated PDF for the list.

    -------------------------------------------------------------------------------------------------------
    >>> Note to RTF Chairs: do not schedule this issue for voting before the last ballot of the RTF; until then we update the list in the issue description if we find new typos <<<
    -------------------------------------------------------------------------------------------------------

  • Reported: SysML 1.6 — Tue, 10 Dec 2019 17:40 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Fixed typos/editorials in SysML 1.6

    This resolution fixes all typos summarized in the issue.

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

Precise Semantics for SysML


DistributedProperty should be abstract

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

    The DistributedProperty itself does not make sense. As specified in the specification specific distributions should be defined as subclasses of the DistributedProperty stereotype. Therefore, the stereotype should be abstract.

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 17:05 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

DistributedProperty should be abstract

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The DistributedProperty stereotype should be abstract since it needs to be specialized in order to be usable.

  • Reported: SysML 1.5 — Mon, 7 May 2018 12:45 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    duplicate

    Duplicate by SYSML17-170

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

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

Pull semantics for flow properties

  • Legacy Issue Number: 18876
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Currently in SysML, flow properties have “Push” semantics (cf. sub-clause 9.3.2.7): writing to a flow property with direction out, propagates value to matching flow property at opposite end of the connector. This implies that there is a behavior running on the part from the “out” side.

    “Pull” semantics could be useful as well: the value propagation is the result of a read made on the flow property with direction in to the matching property at the opposite end of the connector.
    This implies that there is a behavior running on the part from the “in” side.

    SysML should introduce a semantic variation point on this topic, and/or some specific notations/abstract syntax

  • Reported: SysML 1.4 — Mon, 19 Aug 2013 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    To be addressed by SysML v2

    This kind of topic shall now be deferred to SysMLv2

  • 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

primitive types in SysML Activities

  • Key: SYSML17-97
  • Legacy Issue Number: 18659
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    In SysML, value property types are restricted to be a ValueType.
    I see the problem with incompatible and inconsistent types in customer models, as Activities have no restrictions and still use UML primitive types as pin and parameter types.

    Did I miss something in the spec, or types used in Activity are not restricted to be ValueTypes?

    Also, did we fix VerdictKind to be a ValueType? I don't remember.

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

    Defer

    Issue deferred

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

Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics

  • Legacy Issue Number: 19328
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Background:

    SysML 1.3 introduced significant changes to SysML ports
    MBSE methodologies based on SysML 1.2 need to be updated for SysML 1.3 and
    later

    A summary of syntactic and semantic variations for SysML 1.4 ports is an
    important component for tailoring an MBSE methodology as an extension of
    SysML 1.4
    Independent of a particular MBSE methodology, such a summary is an
    important guide for users and tool implementors.
    For users, such a summary would help understand the capabilities and
    limitations of a particular SysML tool implementation
    For tool implementers, such a summary would help understand what
    capabilities need to be implemented to support SysML

    Issue:

    The SysML 1.4 specification lacks a compact summary of the range of
    syntactic variations allowed for SysML 1.4 ports
    and the corresponding semantics for these syntactic variations

    The SysML RTF should provide a catalogue of the syntactic factors that
    induce the syntactic and semantic diversity of SysML ports

    As of SysML 1.4, known factors include, but are not necessarily limited to:

    1) SysML Port Kind

    ­

    {proxy, full, uncommitted}

    2) SysML Port Type

    ­

    {InterfaceBlock, Block, ConstraintBlock}

    3) UML Interaction modality

    ­(UML::Port::isService, UML::Port::isBehavior)

    4) SysML Port Features & nesting

    ­Behavioral features:

    {operation, reception}

    ­Structural features:

    {value, flow, reference, part, constraint, binding, participant, connector, distributed, endPathMultiplicity, boundReference, adjunct, classifierBehavior} {property, port}

    5) Nested SysML Ports (kind, type, modality, features)

    6) Optional feature direction

    {provided, required, provided+required}

    7) SysML Port Connectivity

    ­Internal vs. external connectors
    ­UML Connector kind (assembly, delegation)
    ­SysML Connector kind (binding, non-binding)
    ­SysML Connector type

    {none, UML::Association, SysML::Block + UML::AssociationClass}

    ­SysML Association Block-typed Connector features & nesting
    (same as SysML Port Features & nesting)

    8) SysML ItemFlow

    ­Distinguishing what may flow in general vs. what actually flows in a
    context

  • Reported: SysML 1.4 — Thu, 3 Apr 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Abstract syntax for the initial values

  • Legacy Issue Number: 19286
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The abstract syntax supporting the specification of initial values for properties of SysML block has to be clarified and aligned with the intended semantics.

    In SysML 1.4, §8.3.1.2.8 says: “A compartment with a label of “initialValues” may be used to show values of properties belonging to a containing block.

    These values override any default values that may have been previously specified on these properties on their originally

    defining block”

    While §8.3.2.3 says: “An entire tree of context-specific values can be specified on a containing block to carry values of nested

    properties as shown on an internal block diagram”, then: “If a property belonging to a block has a specification of initial values for any of the properties belonging to its type, then

    the default value of that property must be a UML InstanceValue element. This element must reference a UML

    InstanceSpecification element created to hold the initial values of the individual properties within its usage context. The

    instance specification must be unnamed and owned by the same package that owns the outermost containing block for

    which the initial values are being specified”

    If the specification of an initial value is “context specific”:

    · It cannot be specified using the default value of a property

    · It should be possible to distinct initial value depending on the context, i.e. we need a resolution mechanism to know which initial value has to be used

  • Reported: SysML 1.4 — Fri, 21 Mar 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property?

  • Legacy Issue Number: 19859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section E.4 (non-normative) defines the objectiveFunction stereotype to describe objective functions for use in trade studies. However, whereas Table E.5 defines the objectiveFunction stereotype to extend (or rather generalize) ConstraintBlock, this seems to be inconsistent with the parametric diagram on the same page where the objectiveFunction stereotype is (seems to be [*]) applied to the a constraintProperty instead.
    Given the fact that constraintProperty is only 'loosely' defined in the spec (i.e. it is not part of the xmi file), the only viable alternative seems to be that objectivefunction extends uml::Property and adds the necessary constraints in order to warrant the fact that the type of the uml::Property is (stereotyped by) a ConstraintBlock...

    Please clarify the definition of the objectiveFunction stereotype.

    [*] Since there is no formal notation defined for objectiveFunction, one can of course merely guess...

  • Reported: SysML 1.4 — Mon, 30 Nov 2015 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    To fix the XMI generator, as appropriate

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

classifierBehaviorProperty and adjunctProperty notation

  • Legacy Issue Number: 19326
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I cannot find new SysML 1.4 ClassifierBehaviorProperty and AdjunctProperty notation details, such as :

    1. what keyword should be used? <<classifierBehaviorProperty>> which is very long, or maybe shorter version <<classifierBehavior>> ? <<adjunctProperty>> ?

    2. In what block compartments should it appear? Under generic “properties” or maybe should have their own new compartments?

    3. Should we show “principal” value on adjunctProperty box? If so, showing only the name is not so useful as showing an element kind too, like <<callBehaviorAction>> or <<parameter>>, so user can understand what it represents.

  • Reported: SysML 1.4 — Wed, 2 Apr 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

[SysML] Semantic variation points

  • Legacy Issue Number: 19489
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Kind: Clarification

    Description:

    The current specification of SysML allows, in some places, variations on the semantics. For a part of them it is intentional because the standard does not want to enforce a specific one among others possible, for another part it is not and may result from ambiguities in the text which will have to be fixed.

    It would be useful to explicitly and exhaustively identify the list of intentional semantic variation points so that users can easily see the choices they have to make and state them clearly.

  • Reported: SysML 1.4 — Thu, 26 Jun 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Legacy Issue Number: 18877
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    For “regular” properties, UML semantics in UML is “non-depletive”: the ability to read their value does not depend on the number of time they have been read previously. A “depletive” semantics would implies that a value is no more available once it has been read

    SysML does not say anything about this for flow properties.

  • Reported: SysML 1.4 — Mon, 19 Aug 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

URI for the SysML Profile given in section E.3 is wrong

  • Legacy Issue Number: 19321
  • Status: closed  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    At the end of section E.4 on page 245:
    "The namespace for the standard profile is: http://schema.omg.org/spec/SysML/20090817/SysML-profile.xmi."

    Should this be referred to as a URI, not the namespace? Perhaps should simply reference the cover page of the spec since the one given here is out of date.

  • Reported: SysML 1.4 — Mon, 31 Mar 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Semantics clarification for removing a value from an out Flow Property

  • Legacy Issue Number: 18953
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The specification should clarify the semantics for removing a value from an “out” Flow Property. Since “removing” something is considered to be a “write”, can we assume that it is propagated to a connected and matching “in” Flow Property, if any?

  • Reported: SysML 1.4 — Mon, 30 Sep 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML says nothing about how to deal with multiplicity for flow properties matching

  • Legacy Issue Number: 18783
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    SysML says nothing about how to deal with multiplicity for flow properties matching

  • Reported: SysML 1.4 — Thu, 20 Jun 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The ISO-80000 library has numerous instances of the SysML::ValueType stereotype applied on data types. They are intended to specify the corresponding units and quantity kinds.

    According to SysML, both unit and quantityKind properties of the ValueType stereotype shall be InstanceSpecifications.

    However in http://www.omg.org/spec/SysML/20150709/ISO-80000 all of them refer to the data type the stereotype is applied to rather than to the expected instance specifications. This could result from a bug in the ID generation algorithm used for SysML 1.4

    Example

    <SysML.Blocks:ValueType xmi:id="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029.stereotypeApplication_SysML.package_packagedElement_Blocks.stereotype_packagedElement_ValueType">
        <base_DataType xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <quantityKind xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/>
        <unit xmi:idref="ISO-80000.package_packagedElement_ISO80000-9_Physical_Chemestry_and_Molecular_Physics.package_packagedElement_Quantities.package_packagedElement_amount_of_substance_concentration.dataType_packagedElement_amount_of_substance_concentration_u0028zettamole_per_cubic_metre_u0029"/></SysML.Blocks:ValueType>
    
  • Reported: SysML 1.4 — Tue, 9 Aug 2016 13:05 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    To fix the xmi generator

    To fix the XMI generator, as appropriate

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

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Status: closed  
  • Source: GfSE e.V. ( Mr. Robert Karban)
  • Summary:

    Issue:
    The descriptions in the specification are inconsistent regarding the constraints of what can actually flow over a connector.
    The ItemFlow is used to constrain what actually flows w/r/t the flow properties which specify what can flow.
    In other sections the specifications suggest that the ItemFlow actually loosening the constraint by allowing more general types to be flowing.

    Description:
    These are the inconsistent parts in the specification:

    9.3.2.11 ItemFlow, p86 states:
    An ItemFlow describes the flow of items across a connector or an association. It may constrain the item exchange between blocks, block usages, or ports as specified by their flow properties.

    9.3.2.11 ItemFlow, p87 states:
    Each classifier of conveyed items on an item flow must be the same as, a specialization of, or a generalization of at least one flow property type on each end of the connected block usages.

    9.4.6 Item Flow Decomposition, p95
    Item flows can also be more general than the actual flow, as shown by the connector on the right. The water distiller produces distilled water, but the item flow is for any kind of fluid. The connection to the water heater is
    compatible because it accepts any kind of water, including distilled. The item flow does not require the heater to accept any kind of fluid, because the source of flow is still producing water, regardless of the generality of the item flow.

    Figure 9.15, p95 - Usage example of item flows in internal block diagrams
    Item Flow is Fluid.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 19:14 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Make ItemFlow a specialization of DirectedRelationshipPropertyPath

  • Status: closed  
  • Source: GfSE e.V. ( Mr. Robert Karban)
  • Summary:

    Issue:
    When ItemFlow connects (deeply) nested or inherited properties (e.g. ports or parts) we cannot uniquely identify the sources and targets in its context.

    Description:
    This is similar to other relationships which specialize DirectedRelationshipPropertyPath, e.g. "The Allocate stereotype
    specializes DirectedRelationshipPropertyPath to enable allocations to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets."

    The DirectedRelationshipPropertyPath stereotype based on UML DirectedRelationship.
    Stereotype <<ItemFlow>> extends UML metaclass UML4SysML::InformationFlow which specializes DirectedRelationship.

  • Reported: SysML 1.4 — Tue, 13 Sep 2016 18:48 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Table 12.1 has incorrect "int" typed arguments (4x)

  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    1) SysML convention is to use Capitalized types. These use lower case

    2) There is no "int" within SysML. The correct type is "Integer". While it is possible that an "Int" was defined in a model, in this case it is misleading readers to think that SysML uses Int as opposed to Integer.

  • Reported: SysML 1.4 — Thu, 11 Sep 2014 04:46 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Can a SysML Full Port be typed by a ValueType?

  • Legacy Issue Number: 19412
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Several users at JPL have been asking me about this particular combination.
    I can't find anything in the 1.4 spec precluding typing a full port by a value type.

    Have I missed anything?

  • Reported: SysML 1.4 — Mon, 12 May 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Definition of SysML stereotypes: association ends versus attributes

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

    Some properties of the SysML stereotypes are defined by associations and others by simple properties. It should be consistent and clearly defined how to define the stereotype properties.

    For example, propertyPath of ElementPropertyPath is defined by an association. boundEnd of BoundReference is defined by a simple property.

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:19 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Parts, references, values compartments in wrong section

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Parts, references, and values compartments are described in Subclause 8.3.2.3 (Block), but should with the diagram extensions for BDDs (Subclause 8.3.1.1) with the others.

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:52 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

specializations of requirement should specialize AbstractRequirement

  • Status: closed  
  • Source: GfSE e.V. ( Mr. Robert Karban)
  • Summary:

    They specialize requirement and therefore do not allow to have properties.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 19:51 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML

  • Key: SYSML17-72
  • Legacy Issue Number: 17210
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML. Furthermore they are not even defined as instances of PrimitiveType despite their XMI id.

    For example we have:

    <packagedElement xmi:type="uml:DataType"
    xmi:id="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-String"
    name="String"/>

  • Reported: SysML 1.4 — Sat, 3 Mar 2012 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

Content of Requirement::/tracedTo

  • Key: SYSML17-65
  • Legacy Issue Number: 16373
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    In the specification the content of the derived property “Requirement::tracedTo” is defined as follows:

    • /tracedTo: NamedElement [*]

    Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client.

    As «copy» «deriveReqt» «verify» and «satisfy» inherit from “Trace”, does this means that /tracedTo also list all elements that are the supplier of a «copy» «verify» «satisfy» «deriveReqt» relationship for which this requirement is a client ?

  • Reported: SysML 1.4 — Mon, 18 Jul 2011 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

Description of Item Flows

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

    Description of item flow and its attributes should explain that "assign" means "realization", change "usage" to "instance", and convey items rather than classifiers.

  • Reported: SysML 1.2 — Tue, 25 Jan 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Blocks cannot own items flows

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

    Blocks cannot own items flows, because UML NameSpace abstractly owns NamedElement. Consider specializing on blocks to own item flows.

  • Reported: SysML 1.2 — Tue, 25 Jan 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML stereotype notation creates ambiguity about to which element is the stereotype applied

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

    The SysML notation allows a stereotype <<S>> applied to an element E1 to be shown as the notation for a different element E2 related to E1 in some way.

    Example: 11.3.1.2 CallBehaviorAction and Figure 11.2:

    Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as

    shown in Figure 11.2.

    What this means is that if a CallBehaviorAction shows a stereotype <<S>>, then it is unclear whether <<S>> is applied to the CallBehaviorAction itself or to the behavior that the CallBehaviorAction calls.

    This ambiguity is problematic for users reading SysML diagrams as indicated by SysML issue 17549:

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

    More generally, the SysML spec needs to be reviewed where this stereotype notation can result in this kind of ambiguity.

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

    Defer

    Issue deferred

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

9.3.2.4 direction of ports and their notation (second issue)

  • Key: SYSML17-88
  • Legacy Issue Number: 18441
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties???

    More specifically – can port be stereotyped as directed feature/flow property, what types of properties can be stereotypes with these stereotypes?

    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.4 — Mon, 11 Feb 2013 05: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

Semantics of multiple Dependencies

  • Key: SYSML17-96
  • Legacy Issue Number: 18623
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    SysML defines or uses some relationship based on the UML Dependency metaclass. It is possible to specify multiple dependencies having with the same client or supplier. The user can rely on this capability for various purposes. The point is that there is no standard semantics for such constructs. This must be clarified.

  • Reported: SysML 1.4 — Mon, 8 Apr 2013 04: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

9.3.2.4 direction of ports

  • Key: SYSML17-87
  • Legacy Issue Number: 18439
  • 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.4 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

VerdictKind

  • Key: SYSML17-84
  • Legacy Issue Number: 18312
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I just realized that Requirements::VerdictKind enumeration in SysML profile is NOT a ValueType, so I can't use it in SysML model to type my values.

    Does everyone agree that it shall have ValueType stereotype applied?

    We should make sure all datatypes we provide are ValueTypes.

  • Reported: SysML 1.4 — Wed, 12 Dec 2012 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

Item flows can have multiple types but item properties cannot

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

    Item flows can have multiple types but item properties cannot

  • Reported: SysML 1.2 — Wed, 23 Feb 2011 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Update to Trace Relationship’

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

    I potentially found a mistake in the latest SysML specification. It can be found on page 144. The “Trace Dependency” and the “TraceCallout” are introduced on this page. Usually these two visualizations should show the same aspect of a SysML model. Unfortunately the “Trace Dependency” is only introduced between two requirements whilst the “TraceCallout” is shown between a requirement and a more general NamedElement. I think the named element should be allowed in both cases in the client role of the trace dependency. ADDITIONAL TEXT

    The trace stereotype as defined in 16.3.2.7 does not constrain either end of the trace relationship than the having one client and one supplier.

    16.3.2.7 Trace
    Description
    The Trace stereotype specializes UML4SysML Trace and DirectedRelationshipPropertyPath to enable traces to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.
    Constraints
    [1] The Trace stereotype may only be applied to dependencies.
    [2] Dependencies with a Trace stereotype or one of its specializations applied must have exactly one client and one supplier.

    From the UML 2.5 Standard Profile, the UML4SysML::Trace extends Abstraction, which subclasses Dependency. Dependencys are directed relationships between Named Elements. Therefore, the SysML::Trace can have any Named Element as its ends.

    The diagram elements Table 16.2 on pg 144 should be clarified.

    Also, in section 16.3.2.7, the trace relationship has specific definitions for Requirements:

    Operations
    [1] The query getTracedFrom() gives all the requirements that are clients (from end of the concrete syntax) of a Trace
    relationship whose supplier is the element in parameter. This is a static query.
    Trace::getTracedFrom(ref : NamedElement) : Set(Requirement )

    {query, static}

    getTracedFrom=Requirement.AllInstances()>select(traceTo>includes(ref))

    The query getTracedFrom() could be more general and query all NamedElements and not only Requirements.

  • Reported: SysML 1.4 — Fri, 14 Mar 2014 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

The SysML classification of properties is incomplete

  • Legacy Issue Number: 18709
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    SysML 1.3 section 8.3.2.2 Block says:

    SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType.
    …
    A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.

    In SysML, we also have Signals.
    In UML, Signals can have properties.

    How does SysML then classify properties defined in a Signal?

    A very strict reading of the SysML spec would suggest that a Signal cannot have any kind of SysML property because a Signal is neither a SysML Block nor a SysML ValueType.
    However, this is clearly too restrictive in practice.

    I propose expanding SysML's classification of properties to include SysML Blocks, ValueTypes and Signals.
    This leads to another question:

    What are the legal types of a property belonging to a Signal?

    I propose restricting such properties to be typed by SysML ValueTypes only. This corresponds to the practical situation where a Signal carries a data payload – I.e., it is a message with some data content.
    Allowing a property belonging to a Signal to be typed by a SysML Block or Signal leads to semantic problems — what would it mean to send / receive such signals?

  • Reported: SysML 1.4 — Mon, 13 May 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

proxy and full port notation change request

  • Legacy Issue Number: 18993
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    After ˜1 year of using new proxy and full ports, our customers are not happy with using <<proxy>> and <<full>> keywords/labels for port kind identification.

    In real life, multiple labels on ports makes modeling a nightmare (see image below).

    In MagicDraw, we use different colors - full port has the same color as part, when proxy port is different, but it is not enough. Diagram may be printed in B&W too.
    What do you think about the idea to change proxy port graphical notation, by adding some special icons or using a dashed line for example?

  • Reported: SysML 1.4 — Wed, 9 Oct 2013 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

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 issues

  • Key: SYSML17-37
  • Legacy Issue Number: 14575
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I'm trying to prepare requirements for "callout" notation changes in MagicDraw SysML diagrams and trying to remove tool-specific notation.

    The SysML spec says that each allocatedTo or allocatedFrom property will be expressed as «elementType» ElementName.
    It looks simple at a first glance, but later SysML spec is a total mess:

    "For uniformity, the «elementType» displayed for the /allocatedTo or /allocatedFrom properties should be from the following list, as applicable. Other «elementType» designations may be used, if none of the below apply.

    «activity», «objectFlow», «controlFlow», «objectNode» «block», «itemFlow», «connector», «port», «flowPort», «atomicFlowPort», «interface», «value»

    Note that the supplier or client may be an Element (e.g., Activity, Block), Property (e.g., Action, Part), Connector, or BehavioralFeature (e.g., Operation). For this reason, it is important to use fully qualified names when displaying / allocatedFrom and /allocatedTo properties. An example of a fully qualified name is the form (PackageName::ElementName.PropertyName). "

    So, looking at the predefined list it is clear that:
    For the Activity or other "clean" UML element it is an metaclass name in lowercase.
    for let's say ItemFlow or FlowPort is is an stereotype name in lowercase.
    That's ok.

    But what is <<atomicFlowPort>> ? Port with <<flowPort>> stereotype applied which has isAtomic=true.
    What is <<value>> ? Property which has Type with <<ValueType>> stereotype applied.

    In the example below (Figure 15.4) it has allocation of actions to parts and it uses another one <<elementType>> which is not described - <<part>>.
    What is <<part>> ? The Property with AggregationKind = composite?

    Also, full qualified names and <<elementTypes>> are used incorrectly in this Figure or I don't understand how it should be used.
    For example:
    <<block>> Block4.Part5 - why it is <<block>>, but not <<part>> ???
    <<part>> Part2:Block1 - why part name is before block name? It should be displayed as (PackageName::ElementName.PropertyName) as described above.

    I believe, all these rules and exceptions should be described somewhere

  • Reported: SysML 1.4 — Thu, 22 Oct 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Flow properties and activity paramters

  • Key: SYSML17-42
  • Legacy Issue Number: 15176
  • Status: closed  
  • Source: Françse ( Caron)
  • Summary:

    The SysML flow properties specify elementary flows (nature and direction) that can cross the boundary of a block through a port.

    According to the functional approaches of systems engineering, an entering flow when getting over the boundary of a block is handled as an input by at least one function of the block. An outgoing flow getting out the boundary of the same block is produced as an output by at least one function.

    Activity diagrams are used for carrying out functional graphs with SysML. Inputs and outputs of SysML activities are specified by parameters. Nevertheless SysML does not seem to provide any mean to relate activity input / output parameters to the flow properties. This entails that the unfortunate SysML developers, after having made careful and strenuous efforts for specifying the block interfaces with flow properties and ports, have no other solution than to redo exactly the same work for specifying the inputs / outputs of the functional architecture as activity parameters (or vice-versa). Moreover, there is no mean to ensure consistency in the SysML model between the flow properties and the activity parameters and neither between the ports and the activity pins.

    A solution would be to enable to use flow properties like parameters as activity inputs / outputs.

  • Reported: SysML 1.4 — Fri, 16 Apr 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Proposal to have a stereotype for reference nested property

  • Key: SYSML17-36
  • Legacy Issue Number: 14055
  • Status: closed  
  • Source: International Business Machines ( Mr. Eldad Palachi)
  • Summary:

    When one needs to reference a value of a specific property of part in a composition hierarchy in order to bind it to a constraint parameter, one uses the dot notation shown in section 8.3.1.2. (Example: a box labeled myCar.myEngine.currentTemp in a parametric diagram). When such a box is binded to a constraint parameter a nested connector end may be used to reference this property in the context of the composition hierarchy. However this poses a serious implementation issue for tools since until the box is binded it has no real model element behind it, also if one copies this box or the diagram to another hierarchy in the model then the tool has to complicated analysis. We propose to have a stereotype for reference nested property similar to nested connector end in which the path in the composition hirerchy is specified (i.e. propertyPath: Property [1..*] (ordered) - like in section 8.3.2.6). This will make it easier for tools to implement backed by the standard meta-model.

  • Reported: SysML 1.1 — Sun, 5 Jul 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal

  • Key: SYSML17-44
  • Legacy Issue Number: 15295
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 36, 8.3.1.1 Default «block» stereotype on unlabeled box is not always optimal

    Original Text

    Default «block» stereotype on unlabeled box
    If no stereotype keyword appears within a definition box on a block definition diagram (including any stereotype property compartments), then the definition is assumed to be a SysML block, exactly as if the «block» keyword had appeared before the name in the top compartment of the definition.

    Comment

    I question whether this is always desirable, e.g.,

    1) if the diagram had the «functional hierarchy» diagram usage stereotype applied, wouldn’t the default be «activity»,

    2) if the containing block is an activity block, wouldn’t «activity» be the right default

    Type: Clarification/Fix

    Add sentences that say: If the bdd diagram has a «diagram usage» specified (such as «functional hierarchy»), a different default (such as «activity») can be used.

    If the bdd diagram is for an activity block, the default stereotype elements is «activity»

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML 1.2 Issue Viewpoint referencing other viewpoints properties

  • Key: SYSML17-43
  • Legacy Issue Number: 15293
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 26

    Original Text

    7.3.2.5 Viewpoint

    Description

    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

    Comment

    How is the highlighted sentence done? There are no examples. I see examples of Viewpoint with a dependency on another Viewpoint, but no references for the individual fields (e.g., language and methods). Are the fields populated in an inheritance manner. Can they be overridden? Does it only work if the fields are blank on the dependant Viewpoint?

    Type: Clarification

    Add example and clarify rules

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Ability for a binding connector to be typed

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

    A binding connector used in parametrics should allow for decomposition via association blocks in a similar way that other connectors support decomposition. The specification currently includes a constraint on Block that precludes this as follows: “The number of ends of a connector owned by a block must be exactly two. (In SysML, a binding connector is not typed by an association, so this constraint is not implied entirely by the preceding constraint.)”

  • Reported: SysML 1.1 — Sat, 20 Feb 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Binding to multiplicity in parametrics

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

    In parametrics, one cannot currently bind a constraint parameter in a constraint expression to a multiplity. For example, one may need to include the number of tires in the constraint expression that constraints braking force. However, if the model includes a Vehicle, composed of Tire with multiplicity 4, one must be able to access the number of tires (i.e. the multiplity) in the expression.

  • Reported: SysML 1.1 — Thu, 21 Jan 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Inheriting Allocations

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

    The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. A constraint could be applied to either the allocate or allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier. The issue to be resolved is whether a subclass of a classifier with «allocatedTo» and/or «allocatedFrom» properties should inherit those properties

  • Reported: SysML 1.4 — Tue, 22 Dec 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Can Enumerations be used on parametric diagrams for typing constraint parameters

  • Key: SYSML17-64
  • Legacy Issue Number: 16304
  • Status: closed  
  • Source: MAHLE International GmbH ( Andreas Korff)
  • Summary:

    when participating in the discussions on the draft ballot 3 on the SysML 1.3 spec, we observed that there is a need for clarification. The question was about whether Enumerations can be used on parametric diagrams for typing constraint parameters. The spec defines:

    From 8.3.2.10

    SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation. … A SysML ValueType may define its own properties and/or operations, just as for a UML DataType. See Section 8.3.2.2, “Block” for property classifications that SysML defines for either a Block or ValueType.

    ValueTypes can be used to type constraint parameters. Since ValueTypes extend UML DataTypes, and Enumerations are a subtype of DataType, Enumerations might be used. Since Blocks could be used as types of constraint parameters as well, the implication that any subtype of a UML datatype might lead to the implication that any subtype of UML classifier could be used here as well (e.g. activity or StateMachine), which is of course not meant.

    We need to constrain this definition better

  • Reported: SysML 1.4 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Continuous flows in non-streaming situations with >1 multiplicities

  • Key: SYSML17-46
  • Legacy Issue Number: 15298
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML 1.2 Issues: Continuous flows in non-streaming situations with >1 multiplicities

    11.3.2.1 Continuous

    It’s a bit unclear how continuous flows work in non streaming situation, especially with high multiplicities.

    If a continuous flow arrives at a pin with a multiplicity of 2, it would appear that the 1st and 2nd value arriving at the pin would be captured. If the flow is also continuously valued, the two values would be same. The difference between two adjacent samples goes to zero if the delta time between samples goes to zero (assuming differentiability).

    Type: Fix

    To make this capability useful, we’ll need to add a sampling rate to be able to use continuous with >1 multiplicity. If we don’t the specification should have a caveat for >1 multiplicity and differentiable input values.

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML 1.2 Issues: Optional with streaming

  • Key: SYSML17-47
  • Legacy Issue Number: 15299
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Sysm 1.2 Optional with «streaming»

    Page 92

    11.3.2.6 Optional

    Does optional on an input mean optional to start the activity or optional for the activity to finish? Consider an «optional» streaming input.

    Does optional on an output mean optional to appear at the end of the activity or optional for it ever to appear? Consider an «optional» streaming output..

    We need to have all the possibilities for streaming; it probably should have two multiplicities for each streaming parameter

    Starting Multiplicity: number of tokens that must appear for the activity to start

    Total Multiplicity: number of tokens that must appear over the lifetime of the activity

    Ending Multiplicity: number of tokens that must appear at the end of the activity

    Total Multiplicity: number of tokens that must appear over the lifetime of the activity

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Another issue with allocate

  • Key: SYSML17-53
  • Legacy Issue Number: 15884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that’s ok according to the current SysML specification.

    However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context

    and not be valid in another context.

    I’ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn’t work. MagicDraw doesn’t allow blocks to be owner of a allocate.

    I’m not sure whether it is a tool issue or if I’ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I’m not sure if that’ll solve

    my problem.

    Any ideas?

  • Reported: SysML 1.4 — Thu, 9 Dec 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML 1.2 Issues: DistributedProperties on Activates

  • Key: SYSML17-45
  • Legacy Issue Number: 15296
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Page 45 Distributed Properties on Activities

    Original Text

    8.3.2.4 DistributedProperty

    Constraints

    [1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.

    Comment

    As I read this, on a BDD, if we have activities, the properties of the activities cannot be distributed properties, because activities are not stereotyped as block

    Type: Fix

    Rewrite this constraint,

    [1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block, Activity, or ValueType.

  • Reported: SysML 1.4 — Mon, 21 Jun 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML Issue on Multiplicity of Use Case Communication Associations

  • Key: SYSML17-51
  • Legacy Issue Number: 15875
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysMl does not give any example of using multiplicity on the relationships between actors and use cases. This is part of UML as shown in Figure 16.11.

    Apparently, the "official" interpretation of SysML is that if there is no example, it is not part of SysML. This incompatibility means that standardize training, books, etc, on Use Cases can not be applied to SysML. And the notation is of value.

  • Reported: SysML 1.4 — Mon, 6 Dec 2010 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML Issue based on UML 15369

  • Key: SYSML17-49
  • Legacy Issue Number: 15728
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A new keyword was added for attributes in UML,

    {id}

    . This concatenation of all such attributes within a class (block) for an instance must be unique.

    While this will mostly be used by database developers, it’s also a domain model analysis property, e.g, Social Security Number for a US citizen, Mac Address, etc. As such, it may be useful to some SysML modelers.

  • Reported: SysML 1.4 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML Issue representation of properties as associations

  • Key: SYSML17-50
  • Legacy Issue Number: 15730
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In UML, there appears to be consistent representing of attributes as regular associations from the owning class. SysML, in similar circumstances, represents value properties as composite associations. We should try to understand what UML is saying (and perhaps push back on them) and consider the value of consistency.

  • Reported: SysML 1.4 — Thu, 14 Oct 2010 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Figure B.35 object nodes


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

Question about the Activity decomposition in Block Definition Diagrams

  • Key: SYSML17-69
  • Legacy Issue Number: 16945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.).

    For example I use that extensively in the FAS methodology (Functional Architectures for Systems).

    I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that.

    When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the

    activities in the model? I think it must do that. Unfortunately tools seems to have a different behavior.

  • Reported: SysML 1.4 — Sun, 8 Jan 2012 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Interface blocks and protocols

  • Key: SYSML17-79
  • Legacy Issue Number: 18169
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The practical usage of port implies the ability to specify a protocol, especially when operations or receptions are provided but not only (this can be true with flow properties too).

    The UML::Interface metaclass (at L3) has a specific property to define a protocol. Note that this protocol is not an owned behavior but only a specification of conformance characteristics.

    I believe we should add something similar to our InterfaceBlock stereotype, even if we do not include UML protocol state machines.

  • Reported: SysML 1.4 — 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

Timing diagrams

  • Key: SYSML17-5
  • Legacy Issue Number: 10642
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Timing diagrams are missing in SysML. They are an important diagram for several engineering disciplines. For example I know a project from the automotive/robotic domain that won't use SysML, because of the missing timing diagrams. Timing diagrams will improve the acceptance of SysML in engineering disciplines.

  • Reported: SysML 1.0 — Mon, 5 Feb 2007 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Allocations should not generate dependencies

  • Key: SYSML17-34
  • Legacy Issue Number: 13840
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Allocations should not generate dependencies The Allocate stereotype extends the Abstraction UML meta-class, which is a Dependency. It is in contradiction with the following description (cf. p133: "This concept requires independent models if “function” (behavior) and “form” (structure)") If we refere to EIA-632 the logical solution that will be allocated to the physical solution only depends from upstream requirements. In some cases, one may have some (upstream) requirements to use a given implementation platform, but this cannot be considered generic and anyway the dependendcy is still on the requirement not directly on the platform. A logical solution makes abstraction of the implementation to focus on issues strictly related to the missions of the system. Then, by definition a logical solution is semantically dependent from the need and not from the implementation. In most times, several logical solutions are possible. Their are more or less effective against each of their requirements, that's why the design work includes tradeoff activities. Saying that a given logical solution is not convenient to be implemented on a given platform doesn't mean that it's not a logical solution to the need. More, the current stereotype implementation biases the impact analysis. The objective of this analysis is to parse the model and to report what model elements should be reviewed (i.e. are potentially impacted) in case of modification of a given model element to preserve the model integrity and consistency. If the platform is modified, what has first to be checked is whether or not the modified elements of the platform can still play the role they have been assigned by the allocation (with the required QoS, etc...). If the answer is "yes", then nothing to do. If the answer is "no", then they are several potential choices: a) if possible modify the allocations only, b) select another logical solution (i.e. modify it) and define the new allocations, b) select another platform and define the new allocations. This is matter of tradeoff. The only point that has always to be checked is the allocations. Then the only "thing" that actually depends on the "from" and "to" sides of an allocation is the allocation itself.

  • Reported: SysML 1.1 — Fri, 27 Mar 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Binding Relationships require unit conversions

  • Key: SYSML17-31
  • Legacy Issue Number: 13261
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Binding relationships are used between model element properties and parameter in the constraint blocks, similarly they are used between constraint blocks.

    These constraint blocks are intended to be reusable.

    However connecting constraint blocks from different sources does not usually work unless the units are the same. Model element values may also not be using tehehe same units.

    A reasonable solution is to indicate the scaling factor on the binding relationship. This could be done in several ways. One way would be to indicate a simple assignment equations between the two parameter names.

    Currently

    x----------------------------------Y

    Proposed

    Y=100*x

    x-----------------------------------------Y

    Instead of using a constant 100, we could used a named constant such as cmPm

    If both ends of the binding relationship were identically named, we need to add an arrow to indicate the souce and target sidel

    à

    X=cmPM*X

    X-----------------------------------------X

    This would indicate that the left side X must be multipled by the cmPm to give the left side x

    This approach allows us to handle more complex conversions by including the ability to add/sub constants

    C=5/9*(F-32)

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect

  • Key: SYSML17-35
  • Legacy Issue Number: 13942
  • Status: closed  
  • Source: NASA ( Jeff Estefan)
  • Summary:

    Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect. Replace <<requirement>> Client with Named Element (no stereotype). Figure 16.1 (top of pg. 148): Recommend adding Refine stereotype (as specialization of Trace stereotype); otherwise note that it comes directly from UML metaclass rather than as a UML extension. Recommend reordering specializations of trace in alphabetical order on UML class diagram (e.g., Copy, DeriveReq, [Refine], Satisfy, Verify). Section 16.3.2: Should reintroduce Refine relationship description and contraints, even though a UML metaclass and not an extension. It is an important relationship with respect to requirements. Perhaps introduce prior to Sect 16.3. Section 16.3.2.3 (middle of pg. 150): Change cardinality of /derived: Requirement attribute from [0..1] to [*]. Also, add right bracket to cardinality of /master: Requirement attribute. Currently shows as [0..1 with not closing right bracket.

  • Reported: SysML 1.1 — Fri, 29 May 2009 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

ItemFlows support on Activity & Interaction Diagrams


Diagram interchange

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

    SysML needs the capability to interchange diagrams in addition to model data. The concrete syntax complliance should include a requirement to comply with diagram interchange in a similar way that the infrastructure specifciation does. The following is included in section 2.3 of the Infrastructure Spec under Concrete Syntax Compliance: - the ability to output diagrams and to read in diagrams based on the XMI schema defined by the Diagram Interchange specification for notation at that level. This option requires abstract syntax and concrete syntax compliance. The proposal is to add the same requirement as above to section 5.3 as a second bullet under the concrete syntax compliance.

  • Reported: SysML 1.0 — Mon, 19 Nov 2007 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

AllocateActivityPartition and UML 2 semantics

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

    In Allocations, AllocateActivityPartition, Constraints, the second paragraph says the AllocateActivityPartition stereotype does nopt preserve the semantics of of UML 2 ActivityPartition, and that partitions with AllocateActivityPartition do not have responsibility for invoking the actions in them. I think there is no conflict with UML 2 semantics, because UML 2 ActivityPartition only requires performing the actions to be the responsibility of the element represented by the partiion, not the invoking of the action. This seems compatible with allocation.

  • Reported: SysML 1.1 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Inferred Allocation on Allocate Activity Partitions

  • Key: SYSML17-15
  • Legacy Issue Number: 12123
  • Status: closed  
  • Source: Raytheon ( Rick Steiner)
  • Summary:

    When an allocation relationship is depicted on an activity diagram using Allocate Activity Partitions, it is unclear if the allocation relationship is from the Action Node to the Part represented by the partition (direct allocation), or from the Activity typing the Action Node to the Block typing the Part (Inferred allocation). Since in practice it has become necessary to represent both conditions, this portion of the SysML specification should be modified to incorporate some graphical indication to distinguish them.

  • Reported: SysML 1.4 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

the use of <> is still unclear and inconsistent

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

    The figure and added text describing the use of <<extend>> is still unclear and inconsistent. As agreed, converting Start the vehicle to an <<include>> and Park to <<extend>> will correct the confusion and make the added text unnecessary.

  • Reported: SysML 1.0 — Mon, 4 Dec 2006 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML: Operations on Activities need to be callable (e.g., start, restart, cancel)

  • Key: SYSML17-28
  • Legacy Issue Number: 13154
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysM:L: Operations on Activities need to be callable (e.g., start, restart, cancel)

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

SysML: Activity Properties should be accessible in Activity diagrams for decision making

  • Key: SYSML17-27
  • Legacy Issue Number: 13153
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML: Activity Properties should be accessible in Activity diagrams for decision making

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Inconsistency between xmi and pdf for Trace and Refine specializations

  • Status: closed   Implementation work Blocked
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    While generating code for a custom sub-profile of SysML 1.4, we got some issues (as far as I can tell the same apply for SysML 1.5)
    You can see the discussion here https://bugs.eclipse.org/bugs/show_bug.cgi?id=530565

    After some internal discussions (thanks Patrick and Jérémie for your time), here are our conclusions:

    In the normative SysML 1.4 XMI Refines and Trace stereotype are implemented as follows :

    1. Refine
    ­ Specializes SysML::Blocks::DirectedRelationshipPropertyPath.
    ­ Extends UML::Abstraction.

    • This extension is a specialization of Abstraction_Refine extension.
    • This extension is a specialization of DirectedRelationship_DirectedRelationShipPropertyPath extension.
      2. Trace
      ­ Specializes SysML::Blocks::DirectedRelationshipPropertyPath.
      ­ Extends UML::Abstraction.
    • This extension is a specialization of Abstraction_Trace extension.
    • This extension is a specialization of DirectedRelationship_DirectedRelationShipPropertyPath extension.

    [Issue 1] The profile design is not aligned with the content of the normative PDF for [SysML 1.4]. Indeed, in this latter:
    1. Refine specializes StandardProfile::Refine and SysML::Blocks::DirectedRelationshipPropertyPath.
    2. Trace specializes StandardProfile::Trace and SysML::Blocks::DirectedRelationshipPropertyPath.
    However, to the best of our knowledge, there are no indications regarding the specializations of the existing extensions relationships.

    [Issue 2] The profile design is not conformant to [UML 2.5]. Indeed, both Refine and Trace have a base_Abstraction property redefining :
    1. SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship and StandardProfile::Refine::base_Abstraction (Refine case).
    2. SysML::Blocks::DirectedRelationshipPropertyPath::base_DirectedRelationship and StandardProfile::Trace::base_Abstraction (Trace case).
    However, according to [UML 2.5] a property cannot be redefined if it is not inherited (see constraint “redefined_property_inherited” in section 9.9.17.7 in [UML 2.5]). Hence, it is not allowed to specify that StandardProfile::Refine::base_Abstraction or StandardProfile::Trace::base_Abstraction are redefined since Refine and Trace do not specialize StandardProfile::Refine and StandardProfile::Trace.

    [Remark] The usage of the “extension specialization” pattern used to define both Refine and Trace within SysML shall be rationalized. To us, the two main points for using that pattern were:
    1. To avoid the usage of multiple inheritance in Refine /Trace definitions.
    2. Enable the owned extension ends (i.e., the one owned by the newly defined extensions relationships) to redefine the owned extension ends for StandardProfile::Trace, StandardProfile::Refine and SysML::Blocks::DirectedRelationshipPropertyPath.

  • Reported: SysML 1.4 — Tue, 10 Apr 2018 14:04 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Add the missing generalizations

    The reporter is right; those generalization are missing in the model defining the profile and have to be added.

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

PDF Specification of SystemOfQuantities not consistent with XMI

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

    The operations and constraints in section E.5.2.15 SystemOfQuantities are not consistent with the definition in the XMI.

  • Reported: SysML 1.6 — Sat, 9 Apr 2022 18:03 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Sync section 5.2.15 with XMI

    The XMI is based on the QUDV model, which is the single source of truth. Therefore, the documentation of the operations and constraints in section 5.2.15 must be updated to be in sync with the XMI. This will be achieved thanks to the document generation.

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

Figure E-6 is identical with E-5

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

    Figure E-5 and E-6 are identical. Replace figure E-6 with the figure E-6 from the SysML 1.5 specification.

    Figure E-6 contains some issues:

    • Should be a bdd instead of pkg
    • Unit::dependsOnUnits is a reference property and should be displayed in a separate compartment with headline "references"
    • Multiplicity at ends of associations between Unit and SystemOfUnits are 0..1 in figure E-5, but 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
    • Multiplicity quantityKind (association between Unit and QuantityKind) is 1..* in figure E-5, and 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
  • Reported: SysML 1.6 — Sat, 17 Apr 2021 17:31 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Update figures E-5 and E-6

    Figure E-5 and E-6 are identical. Replace figure E-6 with the figure E-6 from the SysML 1.5 specification.

    Figure E-6 contains some issues:

    • Should be a bdd instead of pkg
    • Unit::dependsOnUnits is a reference property and should be displayed in a separate compartment with headline "references"
    • Multiplicity at ends of associations between Unit and SystemOfUnits are 0..1 in figure E-5, but 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
    • Multiplicity quantityKind (association between Unit and QuantityKind) is 1..* in figure E-5, and 0..* in figure E-6 in SysML 1.5 and also 0..* in figure E-5 in SysML 1.5
  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:

Sample problem diagrams are inconsistent, need to refactor from integrated model

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The diagrams in Annex D are in many ways inconsistent with each other. Fixing existing issues with each individual diagram will tend to make this problem worse, instead of better. For consistency's sake, the set of diagrams in Annex D needs to be generated from an integrated model as existing issues are addressed.

  • Reported: SysML 1.5 — Fri, 8 Mar 2019 19:15 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Replace 1.6 Annex D with 1.7 Annex D generated from integrated model.

    Two documents attached:
    1. Annex D generated from the 1.7 integrated model in TWC (SysML 1.x Specification [trunk] #1206.
    2. SYSML17-185 Resolution Document, generated from the same model (#1210) with tables showing each issue resolved & the effected diagram(s), then each of the 41 figures in both final form and annotated to show which changes have been made. Note that figures without annotated diagrams have not substantially changed from 1.6.

  • 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

Missing relationship between SystemOfUnits and Units

  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The units shown in figure E.15 to E.18 don't have a link to the SystemOfUnits shown in the same diagram. There has been a link in SysML 1.5, albeit erronously, because there is no direct link. An indirect link exists along the included SystemOfUnits. I think it makes sense to show these indirect links. Otherwise the unconnected SystemOfUnits shown makes no sense in the diagram.
    Suggestion: Add the intermediary SystemOfUnits.

  • Reported: SysML 1.6 — Mon, 27 Sep 2021 11:45 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Change the diagrams

    Replace diagrams

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

SysML: Interaction diagram and Data-based comm of SysML

  • Key: SYSML17-13
  • Legacy Issue Number: 11627
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:
    Original Description:

    Here is a question on the usage of sequence diagrams with SysML, more specially with blocks that communicate via flow ports. Within UML, Message is associated with signature of either a Signal or an Operation (see constraint 2 on Message meta class, p. 492 of the UML2 superstructure spec.).

    In SysML, blocks introduce an alternative for communication between blocks w.r.t. to usual UML2 composite structures: flow ports are basically dedicated to support data-based communication between blocks in contrast of UML2 that does not support such kind of communication between composite structures.
    In this case, a Message within an interaction should be able to refer either a DataType, a Block, a ValueType if the communication happen between two atomic flow ports, or to a FlowSpecification if the communication happen between two non-atomic port.

    I did not see anything related this issue within the SysML spec. Do I miss something or is it something missing in the SysML doc?

    Description revised, in a hope to capture the essence of the question being asked, using the language of SysML V1.6:

    Summary of Problem Statement:
    Here is a question on the usage of sequence diagrams with SysML, more specially with blocks that communicate via Ports.

    SysML introduces methods of data exchanges with Blocks thru the use of Flow Properties and Interface blocks, which can then be used, to illustrate data exchanges on Sequence Diagrams. On the other hand, UML 2.0 uses Classes, & InformationFlows to convey data exchanges.

    Question:
    How can data exchange between Part Properties and/or Actors using ValueType, Blocks & Signals be illustrated on a Sequence Diagram, while using Full Ports & Proxy Ports?

  • Reported: SysML 1.4 — Mon, 22 Oct 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

BindingConnector ends multiplicity

  • Key: SYSML17-9
  • Legacy Issue Number: 11333
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The semantics of the Binding Connector is described as follow :

    “8.3.2.10 Binding Connector

    Description

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. If the properties at the ends of a binding connector are typed by a DataType or ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties. If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance.”

    So, I understand that definition if the multiplicity of the properties linked by the binding connector is 0..1 or 1. But what happen is the upper bound of the multiplicity is greater than 1? If for example, it is 0..* ? And moreover, what happen when the multiplicity of both property is different, as for example on one end 0..1 and on the other end 1 ? In this case, as according to the previous definition, the value of both properties has to be equal, what happen to the value of the proiperty which multiplicity is 1 when the other property is not yet defined?

  • Reported: SysML 1.4 — Tue, 28 Aug 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

Issue: Nested connector ends

  • Key: SYSML17-8
  • Legacy Issue Number: 11276
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Nested connector ends:

    "Connectors may be drawn that cross the boundaries of nested properties to connect to properties within them."

    That's an important feature of SysML.

    "The ability to connect to nested properties within a containing block requires that multiple levels of decomposition be
    shown on the same diagram."

    I think that's a problem in practice. Often I don't want to see the nested properties in the diagram.
    I propose to add a notational feature to show that a connector end is connected with a nested property without
    showing that property.

    For example we could draw the connector to the border of the surrounding property and attach the stereotype <<nested>>
    as a short form of <<nestedConnectorEnd>> and optionally the propertyPath.

    What do you think?

  • Reported: SysML 1.4 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Deferred — SysML 1.7
  • Disposition Summary:

    Defer

    Issue deferred

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

The description of the semantics for the Overwrite stereotype is not consistent

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The illustration given as part of the description of the Overwrite stereotype does not match the semantics defined by fUML.

    Indeed, and except in very specific situation input pins never "store" tokens. So, applying the Overwrite stereotype to an input pin does not have practical effect in most cases.

  • Reported: SysML 1.6 — Wed, 16 Feb 2022 16:55 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fix the illustration given in the SysML specification

    In the sentence referred by the issue, just replace "input pin" by "output pin"

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

TestCase should use PackageMerge

  • Key: SYSML17-63
  • Legacy Issue Number: 16286
  • Status: closed  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    The stereotype «TestCase» is primarily specified in the UML Testing Profile (UTP) and should not be defined by SysML redundantly (or even inconsistently). Rather it should be separated in a dedicated package in SysML and a PackageMerge be specified. This would properly add the properties of a «TestCase» specified in SysML to the "base" «TestCase» specified in UTP.

  • Reported: SysML 1.2 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

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

standard way to describe a flow of data in sequence diagrams

  • Key: SYSML17-7
  • Legacy Issue Number: 11117
  • Status: closed  
  • Source: International Business Machines ( Mr. Eldad Palachi)
  • Summary:

    I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario

  • Reported: SysML 1.0 — Wed, 4 Jul 2007 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Already possible

    It is allowed by the standard, already.

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

Typo: Constraint name 8 of Adjunct Property

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

    Name of constraint 8 is "8_callAction_composite_and_consitent_type",
    but should be "8_callAction_composite_and_consistent_type".

  • Reported: SysML 1.6 — Thu, 21 Mar 2019 17:35 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Typo: Constraint name 8 of Adjunct Property

    Fix the typo as proposed.

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

Combined call-out notation not allowed

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

    Figure D.25 depicts a allocate call-out notation that represents more than one call-out relationship. I don't think that it is allowed.

  • Reported: SysML 1.5 — Thu, 29 Nov 2018 09:36 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

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

The NoBuffer specification makes a wrong statement about the UML semantics

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The sentence that says: “When the stereotype is not applied, the semantics are as in UML, specifically, tokens arriving at an object node that are refused by outgoing edges, or action for input pins, are held until they can leave the object node” is false. This is not the semantics UML specifies. Buffering is provided only for token satisfying the guard but that are not numerous enough to satisfy the “weight” condition.

  • Reported: SysML 1.6 — Wed, 6 Oct 2021 15:25 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    The sentence is correct, but restates UML semantics.

    The sentence is correct. Buffering of tokens in Pins is possible in UML. The weight is not the only reason, why the outgoing ObjectFlow might refuse to accept tokens. If the guard is not satisfied, tokens are not discarded but buffered.

    However, the second part of the sentence restates UML semantics. In terms of a clean separation of the specifications UML and SysML, the second part is removed and the sentence is changed to "When the stereotype is not applied, the semantics are as in UML."

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

Fix figure e-5

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

    Figure E-5 QUDV Concepts Diagram has several minor issues:

    • Should be a bdd instead of pkg diagram
    • Diagram name should not include the diagram number E-5
    • The notation of the owner in the block rectangle is not SysML conform
    • Diagram is not a vector graphic
    • Block QuantityKind has additional unknown stereotype <<Migration>>
  • Reported: SysML 1.6 — Sat, 17 Apr 2021 08:31 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fixed figure E-5

    Editorial fixes: change diagram type from package to bdd; remove diagram number from diagram name; assure that final graphic in the PDF is a vector graphic

    The stereotype "Migration" seems to be a forgotten part of the work on the QUDV elements. It can be removed.

    The information about the owner of the blocks is less important and would cost a lot of diagram space, if the package frames were included or the blocks had full qualified names. Therefore, that information is removed from the diagram.

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

BDD representation of activity hierarchy

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

    I would question whether it was correct to change section 11.3.1.1 "Activity" by replacing the BDD representation of activity hierarchy (as per v1.3) with adjunct action properties (introduced in v1.4). Whilst the latter is possible with the AdjunctProperty facility, the prior method, inherited from UML, is still valid. That is, unless the UML activity hierarchy is expressly deprecated from SysML. Even then, it will leave end users with the question of what the additional benefit is of the adjunct property as applied to call behaviour actions.

  • Reported: SysML 1.5b1 — Thu, 19 Sep 2019 15:45 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Closed, no change: Restrict bdd presentation of activities

    There is no need that SysML restricts the modeling of activities in block definition diagrams like it is allowed by UML rules. The paragraph above Figure 11-1 in 11.3.1.1.1 says "Properties with AdjunctProperty applied ... can be used", it doesn't say they must be used.

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

QUDV: PrefixedUnit has no quantity kind

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

    In figure E-9, the prefixed unit kilogram has two quantity kinds mass.

    However, PrefixedUnit redefines the quantityKind property and sets the multiplicity to 0. It should not have a quantityKind.

  • Reported: SysML 1.6 — Fri, 23 Apr 2021 06:11 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove quantityKind links for kilogram in Figure E-9

    A PrefixedUnit has not quantity kinds. The slots respectively links from kilogram to mass should be removed.

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

NoBuffer has no effect if it is applied on an input pin

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to the UML semantics for Activities execution, token will be placed on input pins of an action only when this action accept them. So there will be no case where token in a input pin will be "refused".

    As a consequence, applying the "NoBuffer" stereotype on an input pin will not have any effect, conversely to what the description sub clause of that stereotype suggests (in section 11.3.2.4).

    Proposal: clarify that "NoBuffer" should not be applied on input pins.

  • Reported: SysML 1.6 — Wed, 3 Nov 2021 16:48 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    No change

    No Buffer may actually has an effect on an input pin if that one is part of a structured node.

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

Annex B / Figure B27

  • Key: SYSML17-21
  • Legacy Issue Number: 12147
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.27: <<view>> Package "steals ownership" of MOEs, Actor, UseCase and Requirement Severity Critical since there is currently no sensible way to implement <<view>> in tools ! In Figure B.27 - Establishing a Performance View of the User Model It is not at all clear how the MOEs, Actor, UseCase and requirement should be shown as directly within the view without the view package "stealing ownership". Appears to break constraint: '7.3.2.4 View [1] A view can only own element import, package import, comment, and constraint elements.' See also example images in Magicdraw UML SysML Plugin at: http://school.nomagicasia.com/node/127 http://school.nomagicasia.com/files/images/Figure%20B.27%20-%20Establishing%20a%20Performance%20View%20of%20the%20User%20Model.png Note that this relates to:: Issue 11500: <<view>> as Package extension is very bad idea (sysml-rtf), No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus@magicdraw.com nerijus@nomagic.com) '<<view>> as Package extension is very bad idea. Package is used for ownership, so it is not possible to show the same elements in different packages (as different point of view)'

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

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

Annex B / Figure B.38

  • Key: SYSML17-23
  • Legacy Issue Number: 12154
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.38: property names of p:[PowerSubsystem] inconsistent w.r.t. other figures
    Figure B.38 gives p:[PowerSubsystem] with parts: em: [ElectricMotor] t: [Transmission] ice: [InternalCombustionEngine]
    Figure 9.3 shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController)
    Figure 9.6 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController)
    Figure 15.10 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine emg:ElectricalMotorGenerator (ecu:PowerControlUnit) (epc: ElectricalPowerController) (can:CAN_Bus)
    Figure B.18 BDD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine em: ElectricalMotorGenerator pcu:PowerControlUnit (epc: ElectricalPowerController) ..

    For consistency Figure B.38 should show p:[PowerSubsystem] with parts: emg: [ElectricMotor] (not 'em') trsm: [Transmission] (not 't') ice: [InternalCombustionEngine] Also, Figure B.18 should show PowerSubsystem with part: ecu:PowerControlUnit Visit also analysis at: http://school.nomagicasia.com/node/149

    Update 03/25/2019: Added newlines for readability

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

  • 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

Annex B / Figure B.35


Figure B.34 and Figure B.35

  • Key: SYSML17-25
  • Legacy Issue Number: 12366
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    FigureB34 shows an Activity decomposition with:

    • an <<activity>> ControlElectricPower owning part Property 'elecDrivePower:ElecPower'.
    • an <<activity>> ProvideElectricPower without any owned part Properties.

    FigureB35 shows:

    • an Action 'a3:ControlElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> driveCurrent'
    • an Action 'a4:ProvideElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> elecDrivPower'

    The translation of ObjectFlows in FigureB35 to part Properties in the Activity decomposition FigureB34 is thus inconsistent.

    Update: 03/25/2019, added newlines for easier reading

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

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

parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete


Where have stereotypes been defined?


Annex B, Figure B.29

  • Key: SYSML17-24
  • Legacy Issue Number: 12160
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    In Figure B.29 'delta-t' is shown with solid-line (AggregationKind 'composite'), it should be shown with a dashed line (AggregationKind 'none') to be consistent with Figure B.26 BDD for EconomyContext.

  • Reported: SysML 1.0 — Sun, 6 Jan 2008 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

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

Sample problem: Parts are added directly into package

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

    Parts are added directly into package. B27 - <<moe>> element that is a part is displayed inside of a package <<view>>

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-185

    This issue is tracked and resolved in the integrated Annex D model that is required by SYSML17-185.

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

PDF Specification of SystemOfUnits not consistent with XMI

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

    The operations and constraints in section E.5.2.16 SystemOfUnits are not consistent with the definition in the XMI.

  • Reported: SysML 1.6 — Sat, 9 Apr 2022 18:09 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Sync section 5.2.16 with XMI

    The XMI is based on the QUDV model, which is the single source of truth. Therefore, the documentation of the operations and constraints in section 5.2.16 must be updated to be in sync with the XMI. This will be achieved thanks to the document generator.

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

'Figure 15-4: Behavior Allocation' multiple issues in the diagram and the supporting text

  • Status: closed  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The title of the section is:

    15.4.1 Behavior Allocation of Actions to Parts and Activities to Blocks

    There is in fact no allocation of an Activity to a Block, there is an allocation of an Activity6 to a Part7.

    From p. 177:

    Specific behavior allocation of Actions to Parts are depicted in Figure 15-4.

    But the diagram includes an allocation from an Activity6 to a Part7 (that it is a part is confirmed by the «part» keyword in the allocatedTo callout).

    The allocation to Activity6 comes from a nested part ..

    The allocation is from the Activity6 to a part ...

    The use of part names 'Part5', 'Part7' with Capitals is confusing. It is much clearer to have property names that are lowerCase. If they must have names with Capitals then the Blocks that type them should be shown (see attached image).

    The use of the part name 'Block1' as the allocation target for Action1 is beyond confusing when there is a block Block1 in the same diagram.

    ASIDE: I wish the RTF diagram contributors would adopt a policy across the entire specfication of using lowerCamelCase (no spaces) for all block properties and UpperPascalCase (no spaces) for all Blocks

    The diagram figure is low resolution and needs to be replaced.

    The following may be in part MagicDraw/Cameo 19SP3 tool issues:

    • The path callout in the Note for the allocatedTo on Activity6 in the tool is '«part» Block4::Block7::part7'; the spec has '«part» Block4.Part5.Part7'
    • The tool could not (as far as I can tell) display the qualified name corresponding to Part:Block1 for the header in a swimlane
  • Reported: SysML 1.6 — Wed, 1 Jul 2020 03:34 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Behavior Allocation

    Correct the text in following way:

    Specific behavior allocation+s+ of Actions to Parts and Activities to Blocks are depicted in Figure 15-4.

    The allocation to Activity6 from action1 comes from goes to a nested part, and uses the attributes of DirectedRelationshipPropertyPath to specify the path of properties to reach that part. The sourceContext targetContext of the allocation is Block4 Block 0 and the sourcePropertyPath targetPropertyPath is (Part5) part1. Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation.

    Replace the diagram with this one:

    This diagram can be found in the specification model in the teamwork cloud under Element ID
    mdel://_19_0_4_58401de_1632821659221_739603_774

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

SysML: UML Qualified Associations

  • Key: SYSML17-2
  • Legacy Issue Number: 10048
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML currently discards UML 2.1 qualified associations (see 8.3.1.4) as not being of interest to the SE community.

    I contest this on two grounds –

    1) a. Qualifiers are used expressively and meaningfully to explain domain situations that have nothing to do with data modeling. For example, when I say a baseball roster had 9 members and that there are 9 positions to fill, I am not explicitly saying that there is one person per position. Qualifiers allow me to clarify this piece of the real world and would be very useful on a BDD.

    b. Qualifiers are also used idiomatically with generalization discriminators to tie parallel generalization structures together. They are capable of modeling situations, such as when there are many types of missiles, each with their own launcher type.

    c. Qualifiers are also used to indicate addressing schemes and mechanisms. For example, by placing an operation/activity etc that returns a type in a qualifier, one can specify the mapping or prioritization /ordering algorithm. Specifying such algorithms may be the SE’s job, when it part of an equation report, algorithm development. This could fit into SysML and support allocation to functional (target prioritization scheme, best antenna-signal function) and structural components (packet routers). This is fully in the spirit of what practicing SEs do and would round out the capability of SysML.[Note that this capability could be delayed for a later SysML, the other parts should be addressed sooner]

    2) Qualifiers appear to be part of small part of UML that is incompatible with use with a SysML strict profile mechanism. Imagine a model done in strict SysML, then brought into UML, where a qualifier is added to the relationship, changing the multiplicity at one end. If the model is then brought back into (strict) SysML and the qualifier is then dropped, the multiplicity cannot be automatically restored (or determined from the model). Because of this, qualifiers must be forbidden in UML in such contexts

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Closed because a rationale is missing

    In principle, it would be possible to introduce qualified associations, since it is part of UML. It was discussed several times in previous issues and we agreed that it should be covered by SysML v2.

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

Figure E.8 depicts instance specifications with invalid slots

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

    Figure E.8 depicts instance specifications with a slot "name". None of the classifiers of the instance specification define the appropriate structural feature for the slot.

  • Reported: SysML 1.6 — Tue, 20 Apr 2021 10:37 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove invalid slots or replace them with another one

    The types of the instance specifications in figure E-8 and E-9 have no property "name". It seems that the author mixed it up with the name of the instance specification.

    An exception are the instance specifications SI and ISQ in figure E-8. The name slot should be replaced by "description" which is a property of SystemOfUnits and SystemOfQuantities.

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

QUDV: SystemOfUnits constraint systemOfQuantitiesIncludesAllUnitsQuantityKinds not documented in PDF

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

    The constraint SystemOfUnits::systemOfQuantitiesIncludesAllUnitsQuantityKinds is specified in the QUDV.xmi, but not mentioned in the PDF in section E.5.2.16.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 16:53 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Specify constraint SystemOfUnits::systemOfQuantitiesIncludesAllUnitsQuantityKinds in section E.5.2.16

    It seems that the description of the constraint systemOfQuantitiesIncludesAllUnitsQuantityKinds has been overseen in section E.5.2.16 and should be added in the constraint subsection.

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

Requirements interchange issue

  • Key: SYSML17-29
  • Legacy Issue Number: 13177
  • Status: closed  
  • Source: ProSTEP iViP Association ( Steven Vettermann)
  • Summary:

    Information for facilitating the partner integration within the specification and requirements definition process (requirements interchange) are missing (e.g. meta information like version, access rights).

    Remark: There is a specification already addressing this topic, the Requirements Interchange Format (RIF). It is available for download as ProSTEP iViP Recommendation PSI 6 at www.prostep.org. This specification was introduced to the SE DSIG by Rupert Wiebel from HOOD (a paper is available) and presented by Dr. Steven Vettermann from ProSTEP iViP and discussed at the ManTIS meeting on December 11th.

  • Reported: SysML 1.4 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Facilitating partner integration is out of scope of SysML

    The reporter asks for additional elements in SysML to facilitate requirement interchange. Although this would be useful for SysML, it is out of scope.

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

Figure E.11: Make it a package diagram and update the URI's


QUDV: Constraints [1] and [2]of SystemOfUnits are operations

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

    In section E.5.2.16, the constraint [1] specifies the body condition of operation isCoherent() and constraint [2] the body condition of operation isCoherent(du).

    So, the specifications should be moved to the operation section and not be listed in the constraint section.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 16:20 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    QUDV::SystemOfUnits: Move body conditions from constraint to operation section

    The body conditions constraint [1] and constraint [2] for isCoherent() and isCoherent(du:DerivedUnit) should be moved to the operation section after the constraint section.

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

clarification, what "part property" is

  • Key: SYSML17-74
  • Legacy Issue Number: 17307
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    The NEW issue - clarification, what "part property" is, as new port types typed by Blocks changed everything, they fit into "part properties" definition.
    SysML 1.3, Page 43 : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. "

  • Reported: SysML 1.4 — Fri, 13 Apr 2012 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Part Property

    Part Property are defined by a composite relationship between block "<<Block>>" elements, in section 8.3.2.4 SysML v 1.6. As for the special cases, they are further defined in the appropriate sections....example the constraint block section 10.1.

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

QUDV: SystemOfUnits::accessibleQuantityKinds() is a copy & paste error

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

    The operation SystemOfUnits::accessibleQuantityKinds() specified in section E.5.2.16 is not mentioned in the QUDV.xmi and is identical with the operation of same name in SystemOfQuantities in the previous section E.5.2.15.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 17:02 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove accessibleQuantityKinds() from SystemOfUnits

    It seems that the documentation of SystemOfUnits::accessibleQuantityKinds() was added by accident to the description in section E.5.2.16. It is a copy of the operation in section E.5.2.15.

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

SimpleQuantityKind::dependsOnQuantityKinds() not specified as a redefinition

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

    SimpleQuantityKind::dependsOnQuantityKinds() redefines the operation QuantityKind::dependsOnQuantityKinds(), but the redefinition is neither specified in the PDF nor in the QUDV.xmi.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 11:20 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    SimpleQuantityKind::dependsOnQuantityKinds() redefines QuantityKind::dependsOnQuantityKinds()

    The redefinition of the inherited operation dependsOnQuantityKinds() should be specified.

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

QUDV: Documentation of SystemOfUnits::getUnit() is missing

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

    The operation SystemOfUnits::getUnit() in the QUDV.xmi in not mentioned in section E.5.2.16.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 17:12 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    QUDV: Add documentation of SystemOfUnits::getUnit()

    Add the documentation of SystemOfUnits::getUnit() specified in the QUDV.xmi in section E.5.2.16

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

Figure E.19 not consistent with XMI

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

    The constant numbers in figure E.19 are not consistent with the ISO-80000.xmi

  • Reported: SysML 1.6 — Fri, 7 May 2021 17:50 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Update figure E.19

    The elements depicted in figure E.19 are not part of the ISO-80000.xmi model anymore. The figure should be updated to depict the current content of the model.

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

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

ConnectorProperty is redundant

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

    The ConnectorProperty is redundant. The same feature is provided by AdjunctProperty.

    see slide 17: http://tinyurl.com/ybvdx6ew

  • Reported: SysML 1.5 — Thu, 27 Sep 2018 18:26 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Deprecate ConnectorProperty

    The AdjunctProperty with a connector as principal provides the same capability as the ConnectorProperty. To continue to be backward compatible, the stereotype ConnectorProperty will not be removed, but marked as deprecated in the specification.

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

Annex D (Sample problem) should illustrate a nominal usage of the corresponding version of SysML

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Considering the purpose of the sample problem, it shall be adjusted so that it reflects a nominal usage of SysML. Usage of obsolete concept/stereotypes shall be replaced without further justification.
    This includes, for instance, the replacement of "UML standard port"/Interfaces by proxy ports/InterfaceBlocks.

    Hence, and even if we will try to keep the sample problem as close as possible to its previous version, some figures of even some parts of it will change, as appropriate with regard to the illustration objective.

    The goal of this issue is to get a global RTF agreement on this.

  • Reported: SysML 1.6 — Thu, 6 Jan 2022 16:54 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Agree on this update principle

    Per this resolution, and as requested by the issue, we allow the subgroup in charge of the Annex D "Sample problem" to apply changes on it in order to keep it in synchronization with the SysML specification it is part of and in order to make sure it provides an appropriate illustration of a common usage of it.

    Changes related to this concerns will be gathered in a single resolution to a specific issue about "keeping the sample model up-to-date" so that the RTF will still be asked for a global approval of them.

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

Syntactical clarification for ConstraintBlock

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    There is no clear statement saying how the expression that specifies the constraint is managed, even if we can imagine that the intent was to use the ownedRule for that purpose it's not formally stated.

    Assuming ownedRule is used, it's not specified either how to deal with ConstraintBlocks that would have more than one ownedRule (since the current specification only consider "one" constraint only)

  • Reported: SysML 1.6 — Thu, 5 Sep 2019 14:35 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merge with SYSML17-252

    The resolution to issue SYSML17-252 implies resolving this one first. For that reason its is convenient to merge them and to provide a common resolution that is specified as a resolution proposal for SYSML17-252

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

9.3.2.9 What is InterfaceBlock?

  • Key: SYSML17-73
  • Legacy Issue Number: 17255
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    9.3.2.9 What is InterfaceBlock? Where is description? Description is the same as constraint [1] text now.
    InterfaceBlock is kind of Block, so, can it be used everywhere Block is used? e.g. part of the FullPort.

    Constraint [2]. Does it mean Interface block can't have value properties and e.g. constraint properties?
    Constaint [3] - does it mean "proxy ports" ? if so, it could be more clear text to say "InterfaceBlock can own proxy ports only"
    constraint [4] - it must be constraint[4] for FullPort???

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

    Improve the description

    We propose to improve the Description sub-clause of 9.3.2.10 Interface Block by highlighting the definition first, then a bit about their usage.

    Issues about the constraints have already been fixed

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

SysML Issues on Item Property values in an IBD

  • Legacy Issue Number: 18805
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The SysML spec does not give any notation for (or example of) specifying the values of an item property participating in an item flow. For example, if water flows in multiple places in the distiller, each should be able to have a specified temperature and dissolved matter % (perhaps as distributions).

    Perhaps a variant of a property specific type would work, perhaps a callout approach would work.

    It possible, it would be desirable to allow for multiple item properties:item flows to have the same name within an ibd, as this would be a natural modeling approach (e.g., all the pipes covey the same thing, but with different values).

  • Reported: SysML 1.4 — Tue, 9 Jul 2013 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: SysML Issues on Item Property values in an IBD

    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

Return parameters of operations in annex E.5.2 have wrong parameter direction

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

    The return parameters of the operations in annex 5.2 have the parameter direction "in" in the QUDV.xmi, but should have parameter direction kind "return".

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 09:21 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Set parameter direction kind of return parameters to "return"

    The specification PDF is correct, but not the QUDV.xmi.

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

Owning Block definition is unclear

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The definition of owning block for proxy port given in the description sub-section of 9.3.2.7 FlowProperty is unclear and misleading. It should be reworded and moved to the ProxyPort description

  • Reported: SysML 1.5 — Thu, 2 Mar 2017 15:41 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove the sentence between parenthesis

    The sentence will be removed

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

It is not allowed in UML to display stereotypes of related elements

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

    Stereotypes, tags and constraints are displayed on elements that can’t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references):
    a) Stereotypes
    i. Block stereotypes are displayed on parts
    ii. Block stereotypes are displayed on object nodes
    iii. Parameter stereotypes are displayed on ActivityParameterNode
    iv. Behavior or operation stereotypes are displayed on CallActions
    b) Tags
    i. Block allocations are displayed on parts
    ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype
    c) Constraints
    i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30)

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    No change

    The reporter makes a confusion between the stereotype and the keyword symbol (<<xxx>>) that is usually used for representing that a stereotype is applied on the element on which this keyword appears, but not always (see UML 2.5.1 Annex C).

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

Figure 8-1: Wrong property notation

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

    The properties notation depicted in figure 8-1 is not correct. If the type is not shown, also the ':' is not shown according to the property notation BNF given in the UML specification in section 9.5.4:

    <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

    {‘ <prop-modifier > [‘,’ <prop-modifier >]* ’}

    ’]

  • Reported: SysML 1.6 — Sun, 21 Mar 2021 16:58 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Figure 8-1: Updated property notation

    If a property is depicted without a type, the ':' is not shown. The property syntax is defined in section 9.5.4 of the UML 2.5.1 specification:

    <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity-range> ‘]’] [‘=’ <default>] [‘

    {‘ <prop-modifier > [‘,’ <prop-modifier >]* ’}

    ’]

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

QUDV::LinearConversionUnit constraint isInvertible=true

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

    The QUDV model contains a constraint "invertible: isInvertible=true" for LinearConversionUnit, but is not mentioned in the specification document. I propose to add it to the description in section E.5.2.7.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 05:26 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Add constraint description to LinearConversionUnit

    The constraint forces that the inherited property isInvertible is set to true. It is part of the QUDV.xmi, but not described in the specification document.

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

QUDV::AffineConversionUnit constraint isInvertible=true

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

    The QUDV model contains a constraint "invertible: isInvertible=true" for AffineConversionUnit, but is not mentioned in the specification document. I propose to add it to the description in section E.5.2.1.

  • Reported: SysML 1.6 — Sun, 18 Apr 2021 11:17 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Add constraint description to AffineConversionUnit

    The constraint forces that the inherited property isInvertible is set to true. It is part of the QUDV.xmi, but not described in the specification document.

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

Description of SysMLStructureDiagram is missing

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

    In appendix B, the description stereotype SysMLStructureDiagram in figure B.3 is missing in section B.2.

  • Reported: SysML 1.6 — Tue, 13 Apr 2021 09:24 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Added description for SysMLStructureDiagram

    The description of the abstract stereotype SysMLStructureDiagram is missing and should be added.

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

Figure 11-14 is identical with figure 11-13


Figure 9-5 is identical with figure 9-4

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

    The figure 9-5 is identical with 9-4. It should be the attached figure.

  • Reported: SysML 1.6 — Mon, 22 Mar 2021 13:14 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Replace with figure 9-5

    Figure 9-5 is identical to figure 9-4.

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

QUDV: dependOnUnits() operation is not redefined

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

    The QUDV blocks DerivedUnit, ConversionBasedUnit, and SimpleUnit define each a dependsOnUnits() operation which should be a redefinition of the inherited Unit::dependsOnUnits() operation.

    The redefinition is neither specified in PDF nor in the QUDV.xmi.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 12:52 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Redefine dependsOnUnits() operation

    The QUDV blocks DerivedUnit, ConversionBasedUnit, and SimpleUnit define each a dependsOnUnits() operation and inherit the Unit::dependsOnUnits() operation. The definition of the redefinition is missing in the PDF and the QUDV.xmi.

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

Incorrect placement of sections in chapter 17

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

    Section 17.2 contains a subsection 17.2.1.1, but no subsection 17.2.1.

    Section 17.2.1.1 as well as 17.2.2.1, 17.2.2.2, and 17.2.2.3 cover content from UML and does not add SysML specific information.

  • Reported: SysML 1.6 — Mon, 5 Apr 2021 12:52 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    *Rearrangement of sections in chapter 17 *

    The sections mentioned in the issue description repeat content from the UML specification. It is sufficient to repeat the notation in the diagram table. Therefore, the sections 17.2.1.1, 17.2.2.1 - 17.2.2.3 should be deleted.

    The section 17.2.1 is missing. It got lost after SysML 1.4, and should be added again.

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

Section C.3.2.3 should not be a section, but only a headline without numbering

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

    Section C.3.2.3 Semantic Variation Points should not be a section with its own numbering. It is just a headline like "Description" in section C.3.2.2.

    The FlowPort was a stereotype of SysML 1.2. In the SysML 1.2 specification document, the section "Semantic Variation Point" was also only a unnumbered headline of the section about FlowPort.

  • Reported: SysML 1.6 — Thu, 15 Apr 2021 14:19 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove section numbering C.3.2.3

    It seems that the numbering was introduced by accident in SysML v1.3 and should be removed.

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

Figure 13-1 shows two identical names in the same namespace

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

    In figure 13-1, the upper left state machine has two adjunct properties of the same name.

    I propose to simply rename the properties to "submachine state name1" and "submachine state name2".

  • Reported: SysML 1.6 — Mon, 5 Apr 2021 16:36 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Rename identical adjunct properties

    It is allowed to have two states with the same name, but not two adjunct properties. The adjunct property "submachine state name" must be renamed.

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

Figure 12-1 shows two identical names in the same namespace

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

    In figure 12-1, the upper left interaction has two adjunct properties of the same name.

    I propose to simply rename the properties to "interaction use name1" and "interaction use name2".

  • Reported: SysML 1.6 — Thu, 8 Apr 2021 16:06 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Rename identical adjunct properties

    It is not allowed to have two adjunct properties of the same name owned by a namespace.

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

Remove second constraint of SysMLBehaviorDiagram

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

    The second constraint of the SysMLBehaviorDiagram is a copy of the second constraint of SysMLActivityDiagram.

  • Reported: SysML 1.6 — Tue, 13 Apr 2021 09:28 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove second constraint of SysMLBehaviorDiagram

    Resolve the copy&paste error by removing the second constraint of SysMLBehaviorDiagram.

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

Definition of part

  • Key: SYSML17-59
  • Legacy Issue Number: 16058
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The current definition of "part" includes
    ports. Is that intended?

  • Reported: SysML 1.2 — Fri, 11 Mar 2011 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Definition of a "Part" SysML v1.2, includes ports

    The current Definition of a "part" includes ports, is this intentional?

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

QUDV.xmi: Prefix::symbol multiplicity should be 0..1

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

    In the QUDV.xmi, the multiplicity of Prefix::symbol is 1 while the specification in section 5.2.8 defines a 0..1 multiplicity.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 05:31 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Fix multiplicity of Prefix::symbol in XMI

    The multiplicity of Prefix::symbol in the XMI should be set to 0..1 as specified in the PDF.

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

Missing comment for some attributes

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    There are some elements that don't have any comment in the SysML.xmi file.
    (The list can be found at the end of the description)

    Our tooling is using these comments to automatically generate documentation

    Small question: Is the xmi file available for contribution? Maybe on a GitHub repository?

    Here is the list
    SysML.package_packagedElement_Activities.stereotype_packagedElement_Probability_ownedAttribute.probability
    SysML.package_packagedElement_Activities.stereotype_packagedElement_Rate_ownedAttribute.rate
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.sourceContext
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.sourcePropertyPath
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.targetContext
    SysML.package_packagedElement_Blocks.stereotype_packagedElement_DirectedRelationshipPropertyPath_ownedAttribute.targetPropertyPath
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.definitionURI
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.description
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_QuantityKind_ownedAttribute.symbol
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.definitionURI
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.description
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.quantityKind
    SysML.package_packagedElement_Libraries.package_packagedElement_UnitAndQuantityKind.class_packagedElement_Unit_ownedAttribute.symbol
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.criterion
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.member
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.name
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.orderedMemeber
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_ElementGroup_ownedAttribute.size
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concern
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Stakeholder_ownedAttribute.concernList
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_View_ownedAttribute.stakeholder
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Viewpoint_ownedAttribute.concern
    SysML.package_packagedElement_ModelElements.stereotype_packagedElement_Viewpoint_ownedAttribute.presentation
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_ChangeStructuralFeatureEvent_ownedAttribute.structuralFeature
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_DirectedFeature_ownedAttribute.featureDirection
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_InvocationOnNestedPortAction_ownedAttribute.onNestedPort
    SysML.package_packagedElement_Ports_u0026Flows.stereotype_packagedElement_TriggerOnNestedPort_ownedAttribute.onNestedPort

  • Reported: SysML 1.4 — Mon, 9 May 2016 15:51 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Closed, no change: Missing comments in XMI

    The current XMI for SysML 1.6 includes all the descriptions of the stereotypes and stereotype features. The model that was used to generate the XMI is the same model that was used to generate the stereotype descriptions in the specification PDF document.

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

Derived attribute should also be read only

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    In the xmi file representing the profile, that can be found here:
    ptc/2015-07-05 http://www.omg.org/spec/SysML/20150709/SysML.xmi

    The derived attributes should also be set to read-only:
    <ownedAttribute xmi:id="SysML.package_packagedElement_Requirements.stereotype_packagedElement_Requirement_ownedAttribute.master" xmi:uuid="org.omg.sysml.SysML.package_packagedElement_Requirements.stereotype_packagedElement_Requirement_ownedAttribute.master" xmi:type="uml:Property">
    <name>master</name>
    <isDerived>true</isDerived>
    ...
    </ownedAttribute>

    In Papyrus SysML 1.1 version, the derived attributes have been set to read-only.
    It will be the same for SysML 1.4 implementation. See https://git.eclipse.org/r/#/c/71034/2/core/org.eclipse.papyrus.sysml14/resources/profile/SysML.profile.uml

    It would be good to provide for SysML 1.5 either the profile with readonly or specify in the norm what should be implemented for the write access

  • Reported: SysML 1.4 — Thu, 28 Apr 2016 10:42 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Derived properties are not required to be read-only

    The UML specification allows that derived properties are changeable:

    ----------------------------
    Section 9.5.3:
    Derived Properties are often specified to be read-only (i.e., clients may not directly change values). But where a derived Property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived Property. The derivation for a derived Property may be specified by a constraint.
    ----------------------------

    A derived property can change if a value of the derivation expression changes.

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

SysML primitive value types

  • Key: SYSML17-52
  • Legacy Issue Number: 15882
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    We have issues with SysML primitive value types - Real, Integer, Boolean, String etc.

    The problem is that these types are not inherited from corresponding UML primitive types - Real, Integer, Boolean, String.
    That means, UML tool can't understand, what kind of ValueSpecification should be created for values of properties typed by these value types.
    Should it be LiteralString or LiteralInteger or OpaqueExpression?
    Constraints can't check if slot values are compatible with property types, as it is not clear what kind of value specification it should be also.
    There are issues in parametrics solving also, as values must be compatible with property types.

    I think, SysML primitives must be directly inherited from UML primitives - Real subtype of UML Real, String subtype of UML String etc.

  • Reported: SysML 1.4 — Wed, 8 Dec 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Specialize SysML primitive values types from UML primitive value types

    The SysML primitive values types have no relationship to the UML primitive value types and there is also no relationship to the Literal metaclasses. Therefore, it is not possible to define values for properties typed by a SysML primitive value type.

    A solution is to inherit the SysML primitive value types from the appropriate UML primitive value types.

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

SysML: Protocol State Machines needed

  • Key: SYSML17-1
  • Legacy Issue Number: 10047
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The current document eliminates Protocol State Machines on the grounds of simplification. See Section 13

    However, this leaves a hole in the capabilities of SysML. Currently, SysML supports UML interfaces (provided and required), which can’t have state machines to define them.

    It is an important part of designing systems interfaces (SE terminology) to define the details of the (UML/SysML) Interfaces. These details include the allowed ordering of messages. As we are not allowed to use behavior state machines and the standard solution, that of, protocol state machines are not included, we can’t properly do interface engineering within SysML

    If some other solution/work-around is proposed (which I don’t recommend) the explanation of how to accomplish this should be in the spec.

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Protocol State Machines deferred to SysML v2

    Table 4-1 excludes the model element ProtocolStatemachines from the UML4SysML subset. The impact of introducing ProtocolStatemachines in SysML v1 is too big for v1 and out of scope for an RTF.

    The need for ProtocolStatemachines was already sent to the team working on SysML v2. They identified a high coverage with the SysML v2 RFP requirement INF 1.07.1.

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

Incorrect description of SysMLBlockDefinitionDiagram

  • Status: closed  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Description mentions SysMLBlockDefinitionDiagram stereotype extends UMLPackageDiagram whereas it extends UMLClassDiagram according to Figure B.3 page 219.

  • Reported: SysML 1.6 — Fri, 27 Mar 2020 06:00 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: SysMLBlockDefinitionDiagram extends UMLClassDiagram

    The SysML Diagram Interchange stereotype SysMLBlockDefinitionDiagram extends UMLClassDiagram (see figure B.3). Section B2.3 incorrectly states that SysMLBlockDefinitionDiagram extends UMLPackageDiagram.

  • 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

"Allocated From" should be "Allocated"

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    The term "Allocated From" associated with the From end of an allocation relationship is confusing when it appears in compartment or callout notation. Nerijus mentions numerous user complaints about this. A more intuitive and meaningful term would be simply "Allocated", which when appearing in a compartment label implies that the subject element has the listed elements in the compartment allocated to it.

  • Reported: SysML 1.4 — Thu, 19 Nov 2015 15:49 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolved: Rename "allocatedFrom"

    The term "allocatedFrom" in the allocate compartment or callout notation is confusing for many model users. After a discussion the RTF decided to rename it to "allocatedElements".

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

Block namespace compartment: Are external relationships allowed

  • Key: SYSML17-6
  • Legacy Issue Number: 11011
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The block namespace compartment shows a bdd of the elements that are part
    of the namespace of the block.

    Is it allowed to show relationships from a block inside that compartment to
    a external block? The relationship could be in the model, but can I show it
    in the diagram?

    I think it should be allowed. I don't see any problems.

  • Reported: SysML 1.4 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Clarified that external relationships from and to block namespace compartment are allowed

    Replace the first paragraph of the section with the revised text.

    Text with change marks:
    A compartment with the label “namespace” may appear as part of a block definition to show blocks and other NamedElements that are defined in the namespace Namespace of a containing block. This compartment may contain any of the graphical elements of a block definition diagram. All blocks or other named elements NamedElements that are defined shown in this compartment belong to the namespace Namespace of the containing block, provided this is legal. Elements that cannot be owned by a Block, like Dependencies, can still be shown in the compartment, but without implications for their owner. Relationships between Elements inside and outside of the block’s Namespace may also be shown. Since the relationship is then half outside of the compartment, no conclusion about ownership can be drawn from the diagram.

  • Updated: Thu, 22 Dec 2022 13:45 GMT
  • Attachments:
    • rationale.pptx 550 kB (application/vnd.openxmlformats-officedocument.presentationml.presentation)

Representation of nested object nodes in activity diagrams

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

    Issue: Representation of nested object nodes in activity diagrams. Discussion: It is desirable to be able to represnt nesting of object nodes on activity diagrams to reflect one or more levels of nested properties of the classifier that types the object node. For example, if water is shown as an object node, and it is desired to refer to the temperature of water, then it should be possible to reflect this property on the activity diagram using the notations that are used on ibd's. In particular, one may want to use either a nested rectangle to represent the property, or the dot notation. Proposed update. In the diagram extensions for activity diagrams in Section 11.3.1.4, add a clarifying statement that nested properties of the classifier that types an object node can be represented on activity diagrams either using the nested rectangle notation or the dot notation similar to the use of nesting on ibd's and parametric diagrams.

  • Reported: SysML 1.1 — Wed, 31 Dec 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Corresponding actions shall be used

    • There are two possible cases we see where we would need to work on parts from a whole: (a) the part remains owned by the whole and we just need a reference on it to focus the folowwing behavior on this part, or (b): the part is "dismounted" from the whole (i.e. the ownership changes) and then tit is flowing apart from the whole. In both cases it's necessary to specifiy the appropriate action to be performed:
    • in case (a): actions like "UnmarshallAction" or "ReadStructuralFeatureAction" can be used. Alternatively the "transformation" property of an ObjectFlow can be used. Note that this transformation shall be "side effect free".
    • in case (b): we would use "RemoveStructralFeatureValueAction" for transferring ownership

    We propose a "Closed, no change" resolution.

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

Table 8.3: Row ActorPart shows Actor

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

    The row ActorPart in table 8.3 should depict SysML::Blocks::PartProperty typed by UML4SysML::Actor, but it shows an Actor.

  • Reported: SysML 1.6b1 — Sat, 18 May 2019 17:37 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Resolution: Show properties typed by Actor in ActorPart row of table 8.3

    The row ActorPart in table 8.3 shows Actor elements instead of properties typed by an Actor.

    SYSML17-286 asks for removing the row ActorPart from the table.

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

Figure 9-5 and 9-4 are the same

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 9-5 (Item Flow Stereotype) is the same as Figure 9-4 (Provided and Required Features).

  • Reported: SysML 1.6 — Thu, 5 Mar 2020 15:39 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Replace figure 9.5

    The figure 9.5 is by accident identical with figure 9.4 and must be replaced.

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

Parameter direction typo in XMI


Owned properties of an InterfaceBlock

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Split from SYSML16-86:

    What are possible owned properties of the InterfaceBlock? Values, FlowProperties? other? In 9.1 InterfaceBlock it is not flow nor value

  • Reported: SysML 1.5 — Thu, 16 Mar 2017 07:43 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Owned properties of an InterfaceBlock

    InterfaceBlock constraint 2_no_part defines the possible owned properties.

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

10.3.1.2 Parametric Diagram: square box notation

  • Key: SYSML17-17
  • Legacy Issue Number: 12131
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    10.3.1.2 Parametric Diagram: clarify applicability of square box notation to constraint parameters (or otherwise) SysML1.0, 10.3.1.2 Parametric Diagram: 'Small square box notation for an internal property A value property may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a value property may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of property boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where an internal property box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the innermost property.' It is not clear whether 'value property' here is meant to refer to a constraint parameter. Also, the term 'internal property' does not exclude, for example, nested constraints, leaving open the possibility of drawing nested constraint properties using square box notation, which is surely not intended. The following suggests that only constraint parameters - not value properties - are intended: SysML1.0, , 10.3.2.1 ConstraintBlock: '[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, binding connectors between its internally nested constraint parameters, constraint expressions that define an interpretation for the constraint block, and general-purpose model management and crosscutting elements.' Rewrite SysML1.0, 10.3.1.2 Parametric Diagram, replacing all references to 'value property' and 'internal property' with 'constraint parameter': 'Small square box notation for a constraint parameter A constraint parameter may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a constraint parameter may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of constraint parameter boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where a constraint parameter box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the constraint parameter.'

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Clarify square box notation in parametric diagrams

    The paragraph 10.3.1.2 in SysML 1.0 is identical with the text in paragraph 10.3.1.2.3 in SysML 1.6. The reporter is right that the statements are misleading. It is intended to specify the notation of constraint parameters.

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

Do parametric bindings observe derived and read-only properties

  • Key: SYSML17-39
  • Legacy Issue Number: 15003
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Do parametric bindings observe derived and read-only constraints on properties?

    .

    In SysML if I bind a read-only property value to a parameter, I would expect that any evaluation of the parametric model would not be able to update the property value. If I wanted to have such a value calculated, I would expect to take off the read-only constraint

    Similarly, if I bind a derived property value to a parameter, I would expect that any evaluation of the parametric model would not use that value as an input, but only as an output.

    However, this is answered (and I hope it is answered positively), the SysML specification should clarify this behavior

  • Reported: SysML 1.4 — Fri, 22 Jan 2010 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    ConstraintBlock is a constraint no a mechanism

    A ConstraintBlock is intended to represent a constraint that can happen to be met or violated. Tools vendors providing simulation facilities may want to implement a synchronization mechanism based on it but it's not required by this specification. If such a mechanism is provided, it is expected that either the tool will enforce the constraint or will notify a constraint violation if any. But again, this is not part of this specification.

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

Annex B / B.4.8.3 Activity Diagram (in sample problem)

  • Key: SYSML17-18
  • Legacy Issue Number: 12144
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    B.4.8.3 Activity Diagram (EFFBD): refers to allocations to parts instead of blocks SysML1.0: 'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail) Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34. It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block.' In fact the AllocateActivityPartitions in Figure B.35 represent blocks, not part Properties typed by blocks.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Already fixed

    This issue does not appears anymore in the specification

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

SysML: References to CreateEvent incorrect

  • Key: SYSML17-76
  • Legacy Issue Number: 17467
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In UML 2.4.1, the equivalent to createEvent and desturctionEvent are now called messages. This should be followed in SysML. This changes the text in the 1st row of Table 12.1 on page 116, but it may impact other places also.

  • Reported: SysML 1.4 — Sat, 7 Jul 2012 04:00 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: References to create and destruction messages

    The referenced elements UML4SysML::CreationEvent and UML4SysML::DestructionEvent do not exist. Table 12-1 must be updated.

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

About Rate, Continuous and Discrete

  • Legacy Issue Number: 18735
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In the figure shown below, Continous and Discrete stereotypes seems to be applied an ActivityParameterNode of an Activity. However, those aforementioned stereotype do not extend ActivityParameterNode but only Parameter and ActivityEdge. Is it an error?

    In the same order, <<continuous>>, <<discrete>> and <<rate>> are also applied on something called “Object Node”? However, <<Rate>> seems not to extend any node.

  • Reported: SysML 1.4 — Thu, 23 May 2013 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Duplicate of SYSML17-265

    SYSML17-265 is also about Rate extending ObjectNodes.

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

IBD notation doesn't distinguish item properties from connector labels

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

    Item properties and connector labels both appear in colon notation near the center of an assocation. How do you tell the difference?

  • Reported: SysML 1.2 — Tue, 25 Jan 2011 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Stereotype keyword can be used

    There is still the possibility to show the <<ItemFlow>> stereotype keyword. By doing this there no ambiguity anymore and no change is required.

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

Association owning ends

  • Key: SYSML17-62
  • Legacy Issue Number: 16263
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Associations in SysML should be able to own their ends. Otherwise modelers can't add an association between blocks in model libraries they do not have permission to modify. They also cannot create association that are non-navigable in both directions, which might be useful for directing flows across them into flows contained by the association as a block.

  • Reported: SysML 1.2 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Already fixed

    Associations own their non-navigable ends

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

Allocate: Error in operation bodies

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

    The body condition of the Allocate::getAllocatedFrom()
    getAllocatedFrom = Allocate.allInstances()->select(to = ref).from
    should be
    getAllocatedFrom = Allocate.allInstances()->select(supplier = ref).client

    to and from are no stereotype or metaclass properties. The appropriate properties are client and supplier defined in the metaclass "Dependency".

    Accordingly change the Allocate::getAllocatedTo() body condition as well as the name "getAllocatedFrom" to "getAllocatedTo":

    getAllocatedTo = Allocate.allInstances()->select(supplier = ref).client.

  • Reported: SysML 1.6 — Thu, 13 Feb 2020 16:19 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolved: Error in operation body conditions of getAllocatedFrom() and getAllocatedTo()

    The body condition of the Allocate::getAllocatedFrom() and Allocate::getAllocatedTo() operations are not correct. Fix them as proposed in the issue description.

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

UML::ExceptionHandler should be part of SysML

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

    According to chapter 4.1 of the SysML 1.6 specification document, RaiseExceptionAction is part of SysML, but the ExceptionHandler is not part of UML4SysML.

    It makes sense to have a complete exception mechanism in SysML, for example, to model exceptional conditions like the violation of a constraint.

    Throwing an exception is not restricted to software, but a useful logical concept of modeling flow behaviors. For instance, it is also included in BPMN.

  • Reported: SysML 1.6 — Thu, 21 Nov 2019 11:30 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Add UML::ExceptionHandler to SysML

    The UML::ExceptionHandler element is missing in SysML and must be added to UML4SysML.

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

SysML: Generalizing Activites

  • Key: SYSML17-3
  • Legacy Issue Number: 10058
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Section 11 should show an example of generalization/specialization of Activiites when then are being shown in a bdd.

  • Reported: SysML 1.4 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Add example about generalizing activities

    Add a new block definition diagram (figure 11-15) depicting a activity generalization.

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

Shared parts are still parts

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The standard treats non-composite aggregation (white diamond) as the poor cousin of composite aggregation (black diamond) by lumping it into a group of block properties called “references”. (6th paragraph in section 8.3.2.3 Block.) So whilst parts (composite aggregation) have their own compartment, non-composite aggregates have to share a compartment with all of the reference block properties. This also occurs on the IBD with all the types of references being drawn with a dashed rectangular frame. At the very least I would propose that non-composite parts are called reference-parts (as opposed to “owned” parts for the composite ones) and are given their own compartment.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:10 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Shared parts are still parts

    New features respectively removing 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

Stakeholder constraint is listed twice

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

    The Stakeholder constraint 1_not_association is listed twice in the specification document and the XMI.

    One constraint is named "1_not_association" the other one "not_association".

    Remove the "not_association" constraint.

  • Reported: SysML 1.6 — Tue, 19 Mar 2019 21:34 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Stakeholder constraint is listed twice

    Remove the duplicated constraint "not_association".

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

Error in pending 1.3 diagram 15.6 and elsewhere

  • Key: SYSML17-70
  • Legacy Issue Number: 16947
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Figure 15.6 in pending SysML 1.3, on the left side of the diagram, the object-flow, labeled objectflow3 is a dashed line. From table 11.2, object flows always use solid lines (though control flow can use either solid or dashed).

    This was also wrong in SysML 1.2, though the diagram number was then 15.5.

    Thanks to Geoffrey Shuebrook who pointed this out to me,.

  • Reported: SysML 1.4 — Mon, 9 Jan 2012 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Wrong object flow notation

    In SysML 1.6, Figure 15.5. and 15.6. depict the object flow with a solid line.

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

Bad reference in section 4.2

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

    At the end of section 4.2 is an unresolved reference:

    "UnitAndQuantityKind, see Erreur : source de la référence non trouvée"

    Replace it with

    UnitAndQuantityKind, see 8.3.3.2

  • Reported: SysML 1.6 — Tue, 19 Mar 2019 21:39 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Bad reference in section 4.2

    Add the correct reference to the bullet point.

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

Lack of notation for units and dimensions on values.

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

    Lack of notation for units and dimensions on values. There are no samples at all

  • Reported: SysML 1.4 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Notation for units and dimensions - already resolved

    The notation for units and dimensions was added in SysML 1.6 as a resolutions for issue SYSMLR-330.

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

SysML: Align SysML Activities with Foundational UML

  • Key: SYSML17-26
  • Legacy Issue Number: 13152
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SysML: Align SysML Activities with Foundational UML

  • Reported: SysML 1.4 — Thu, 11 Dec 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Align SysML Activities with fUML

    There is no misalignment between SysML Activities and fUML.

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

DirectedFeature is confusing

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The intended use for the <<DirectedFeature>> stereotype is not at all clear from its specification in section 9.3.2.4 in SysML 1.5. To be clear, the current description describes what it is, but not why it is required, or how a modeller might use it. Moreover, it is not clear whether it specifically applies to ports (since its part of the section that specifies the language facilities for ports and flows (section 9), or whether it relates to features (properties?) of a block that are not ports.

    The issue was discussed at the RTF meeting of 2017-10-12 as a result of discussing issue http://issues.omg.org/browse/SYSML16-108. There was little consensus on what DirectedFeature is, although Conrad suggested the following (being my interpretation of what was said):
    A DirectedFeature of a block describes whether the block implements that feature (it's "provided") or that the feature is represents a conceptually virtualised feature as an "assumption" that something else in the model will provide it. The fulfilment of the required assumption with an actually provided realisation of that feature is by a connector between the required and the provided features.

    The problem with this interpretation is that it seems to have nothing to do with ports! There is of course further scope for confusion with the UML notation of provided and required interfaces on UML ports.
    At the very least, some examples that clearly illustrate what problem DirectedFeature solves and the types of model elements that it is to be applied to would help a lot.

  • Reported: SysML 1.5 — Thu, 12 Oct 2017 16:39 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Improved description of DirectedFeature

    The description in SysML 1.6 has improved quite considerably. However it can be further improved by slightly modifying the way the corresponding text is structured and by clarifying that any feature are implicitly "provided" if no DirectedFeature stereotype is applied

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

VerdictKind enumeration missing

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    VerdictKind appears in a constraint on TestCase and in Table 4.3 (SysML stereotypes, blocks, valuetypes, and datatypes), but isn't defined in the spec. I should be in a model library, like ControlValueKind (see 11.3.3.1 Package ControlValues).

  • Reported: SysML 1.6 — Mon, 21 Jan 2019 15:20 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    *Resolution: Add enumeration VerdictKind *

    The enumeration VerdictKind is missing in the specification document. It used in the constraints of the TestCase and it is part of the SysML.xmi.

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

The AdjunctProperty is not clearly described

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The benefit of the recently introduced Adjunct Property is not clearly stated in the standard. The current description is somewhat baffling and a recent discussion amongst learned members of the SysML RTF revealed further uncertainty.
    The standard's development needs to be sensitive to the general criticism that SysML is too complex. Thus language features that are described from their purely functional/implementation point of view neither inform the user community what they are for or, as seems to be the case here, make it clear that this part of the language that is a solution to a problem inherited from UML that modelling tools need to implement and end users need not be too concerned with.
    I would also question whether it was correct to change section 11.3.1.1 "Activity" by replacing the BDD representation of activity hierarchy (as per v1.3) with adjunct action properties (introduced in v1.4). Whilst the latter is possible with the AdjunctProperty facility, the prior method, inherited from UML, is still valid. That is, unless the UML activity hierarchy is expressly deprecated from SysML. Even then, it will leave end users with the question of what the additional benefit is of the adjunct property as applied to call behaviour actions.

  • Reported: SysML 1.4 — Fri, 28 Apr 2017 12:53 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    AdjunctProperty not clearly defined: Resolution provided by other issue resolutions

    Split the issue to SYSML17-248 and SYSML17-255.

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

Reference Properties do not reference properties

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    A reference property of a Block may only be typed by (i.e. "reference") another Block. There is no current mechanism for a reference property to explicitly reference a part property of a different block. See Figure D.16 for example; the PowerSubsystem Block is assumed to be referencing the part property of the BrakeSubsystem typed by BrakePedal. This is a logical conclusion since there is only one part property typed by BrakePedal, but if there were multiple part properties typed by BrakePedal, the reference property of the PowerSubsystem Block would be ambiguous.

    Practical use of reference properties has consistently implied that a particular part property CAN be referenced (i.e. "a part property owned by another block"), but no mechanism for this is explicitly provided in SysML. Also, there does not appear to be any constraint on instance semantics of reference properties that might clarify this ambiguity at the instance level.

    See also SYSML16-42 and SYSML16-228.

  • Reported: SysML 1.5 — Tue, 17 Oct 2017 00:17 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Reference properties do not reference properties

    Discussed during May 16th, 2019, RTF meeting:

    We believe that the requested capabilities are already provided by the current SysML version. There are multiple ways to represent such constructs:

    1. A binding connector and optionally a BoundReference property can be used
    2. Derived attribute and/or an operation
    3. Specific properties that subset the collection (assuming the types of the properties owners conform to one another)
    4. Using proxy ports with appropriate connectors

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

AllocateActivityPartition: Reference to UML specification is wrong

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

    The second constraint of the stereotype AllocateActivityPartition references a section in the UML specification:

    "To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic."

    Subclause 12.3.10 does not exist. It is probably 15.6.3.1 in UML 2.5.1.

    I propose to remove the subclause reference number.

  • Reported: SysML 1.6b1 — Wed, 26 Jun 2019 12:50 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    AllocateActivityPartition: Reference to UML specification

    The subclause number references an older version of the UML specification. It is hard to manage those links between separate specifications. Therefore, we follow the proposal of the issue author to remove the absolute reference.

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

Replace UML4SysML::Kernel by UML4SysML::Generalization

  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Benoit Maggi)
  • Summary:

    In SysML 1.5 pdf document ( p 147 Table 14.2- Graphical paths included in Use Case diagrams)

    Latest element in the table :

    • Path name: Generalization
    • Concrete Syntax : ->
    • Abstract Syntax Reference : UML4SysML::Kernel
      => it should be UML4SysML::Generalization

    Also present in SysML 1.4 pdf version

  • Reported: SysML 1.5 — Wed, 30 Aug 2017 15:13 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Proposal: Replace UML4SysML::Kernel with UML4SysML::Generalization

    The abstract syntax reference is not correct as pointed out by the reporter of the issue and must be resolved as proposed.

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

SysML::Trace relationship is not specialized from UML::Trace in the XMI

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

    The SysML::Trace stereotype is a specialization of the UML::Trace stereotype defined in the StandardProfile.

    In the SysML XMI the SysML::Trace stereotype has no generalization relationship to the UML::Trace stereotype. It is just a stereotype extending UML::Abstraction.

  • Reported: SysML 1.5 — Tue, 15 Jan 2019 09:53 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Model generalization from stereotype SysML::Trace to UML::Trace

    The XMI is not conform to the written specification. The generalization relationship between the SysML::Refine and the UML::Refine stereotypes as specified in figure 16.1 is not defined in the XMI.

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

SysML::Refine relationship is not specialized from UML::Refine in the XMI

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

    The SysML::Refine stereotype is a specialization of the UML::Refine stereotype defined in the StandardProfile.

    In the SysML XMI the SysML::Refine stereotype has no generalization relationship to the UML::Refine stereotype. It is just a stereotype extending UML::Abstraction.

  • Reported: SysML 1.5 — Tue, 15 Jan 2019 09:55 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Model generalization from stereotype SysML::Refine to UML::Refine

    The XMI is not conform to the written specification. The generalization relationship between the SysML::Refine and the UML::Refine stereotypes as specified in figure 16.1 is not defined in the XMI.

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

Verdict described incorrecty

  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 16.1 (Requirements, Overview, search on "verdict") refers to "A verdict property of a test case", but verdicts are return parameters, which aren't properties (unless this means an adjunct).

  • Reported: SysML 1.6 — Mon, 21 Jan 2019 15:24 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Resolution: Describe verdict as return parameter

    The verdict is not a property, but a return parameter of a test case. See 16.3.2.6 for the definition of a test case.

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

Typos/editorials found in the SysML 1.5 specification document

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    This issue is dedicated to typos and editorials we find in the SysML1.5 specification document.

    Any finding has to be recorded as an annotation added to a shared PDF document available on the OMG SVN server at: http://www.omgwiki.org/repos/SysML/trunk/Documents/formal-17-05-01(annotated).pdf

    >>> Note to RTF Chairs: do not schedule this issue for vote before the last ballot of the RTF <<<

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 14:14 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    1.6 is done

    to be replace by a new issue similar to this one but about 1.6 rather than 1.7

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

Description of AdjunctProperty

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The first sentence of the description of the Adjunct property stereotype does not make sense:
    "The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states"

  • Reported: SysML 1.5 — Mon, 7 May 2018 12:13 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Merged with SYSML17-248

    Discussed during RTF meeting, Sep. 19th:
    SYSML17-248 is also about clarifying the definition of an AdjunctProperty.

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

Inherit from a conjugated interface block

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

    Figure 9.7 shows that the types of parts that are connected with binding connectors with proxy ports inherit from the proxy port types. That assures that all the features of the interface block type of the proxy port are implemented by the part.

    However in practice you typically have for most proxy ports also a connected conjugated proxy port. You can't inherit from a conjugated interface block and therefore must manually define a conjugated version of the interface block. In summary that supersedes the concept of conjugation.

  • Reported: SysML 1.4 — Fri, 17 Oct 2014 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Inherit from a conjugated interface block

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

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

ElementGroup cannot be source or target of a dependency

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

    The stereotype ElementGroup extends the base class comment which is not a NamedElement. Therefore a ElementGroup can't be source or target of a dependency and it is not possible to use an ElementGroup for instance with a trace or satisfy relationship.

  • Reported: SysML 1.4 — Sun, 7 Sep 2014 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: ElementGroup cannot be source or target of a dependency

    It is not possible to resolve the issue without a major change of the model element or a change of the UML. The addressed problem was already discussed when the ElementGroup element was created. There is no solution with the underlying UML.

    It can be resolved with SysML v2.

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

Property path notation

  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    SysML spec says:

    The name of the referenced property is built by a string of names separated by “.”, resulting in a form of path name that identifies the property in its local context.

    The problem is that in real-life models properties/parts are unnamed. In this case, it is not clear how property path should look like, or looks like this:
    name1…..value or vehicle….value where intermediate properties are unidentifiable.

    A proposed solution would be to use type name if part name is not specified.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:14 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Property path notation

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

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

AllocateActivityPartition should be more formaly related to allocation Relationship

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Assuming an AllocateActivityPartition is used to specify allocations, the element created in the model to represent it should be more formally linked to the corresponding Allocate relationships.

  • Reported: SysML 1.4 — Thu, 11 Feb 2016 15:33 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: AllocateActivityPartition should be more formaly related to allocation Relationship

    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

A discarded resolution still appears in the ballot

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Resolution SYSML-331 was discarded from ballot#8, replaced by SYSMLR-359 then added to ballot#9.

    However in ballot#9, SYSMLR-331 still appears beside SYSMLR-359 with all the votes casted in the ballot#8!

    It's rather confusing because, in addition, JIRA said that we already voted for this ballot, which is not true!

    Can we fix this?

    Thanks

  • Reported: SysML 1.4 — Fri, 21 Oct 2016 05:56 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: A discarded resolution still appears in the ballot

    The issue is about a Jira bug, and not about SysML

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

Requirement ID should be immutable

  • Legacy Issue Number: 19764
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Requirement IDs, as currently specified by the standard and implemented by vendors, are not adequate to ensure robust traceability outside MBSE models. The standard describes ID as "The unique Id of the requirement”. I would suggest replacing this sentence with "The unique and immutable Id of the requirement." This immutable characteristic is key to ensure robust traceability throughout a project with external stakeholders and documents.

    The current practice of using a hierarchical number for the ID is bad practice that should be discouraged, because a hierarchical ID will necessary change when the hierarchy is refactored, which is almost guaranteed to happen. This breaks traceability. I recognize that there is also a need for a hierarchical ID, mainly to be used to sort requirement tables properly using this property. For that use case, I would suggest a new ID called HID with the following description: “A unique hierarchical identifier, used to organize requirements within a package”

    Since we now have two different IDs that serve two different purposes, we should give guidance for which one should be used as the prefix in front of the name, depending of the context. My suggestion is as follows:

    • In a traceability context, the ID should be the prefix shown in front of the name. For example, when showing the table column "Derived From", the ID should be the prefix shown, not the HID.
    • In a hierarchical context (for example, in the containment tree), the HID should be shown as the prefix in front of the name.
    • When in doubt, use the ID in preference over HID.
  • Reported: SysML 1.4 — Fri, 29 May 2015 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Requirement ID should be immutable

    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

Specify a specific part from a collection of parts on an IBD

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    There is no way of saying which part from a collection (i.e. a plural cardinality/multiplicity) is being shown and hence there is no clear and unambiguous way of showing multiple parts from a collection separately on an IBD. E.g. the spokes on a wheel is easily modelled in a BDD as a collection of spokes, but not easily set out in an IBD, whereas, individually named (by role) spokes can be set out in an IBD, but, for more than a few, this becomes awkward to show on a BDD.
    For at least ordered collections (i.e. plural multiplicities) of parts (aggregate roles) the traditional use of square bracket array notation could be used, e.g. mypart[10] would refer to the 10th instance of part collection called "mypart". For unordered collections a selector (i.e. query) would be required.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 17:47 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Specify a specific part from a collection of parts on an IBD

    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

Expand use of rake symbol for all decompositions

  • Legacy Issue Number: 19783
  • Status: closed  
  • Source: University of Detroit Mercy ( Mr. Michael J. Vinarcik)
  • Summary:

    I’d like to advocate for rakes on Call Operation nodes (that have associated methods) in the next SysML rev. We’re using operations extensively because they inherit nicely and have inputs/output parameters. By moving to Call Operations from Call Behaviors, we lose the rake that’s a visible sign you can drill deeper…so by using Call Operations with methods instead of Call Behaviors, we lose that visual cue.
    I put a stereotype with icons on the nodes as a fix, but I’d love to see it as a native function.

    I suggest that rake symbols should be expanded to include call operations on activity diagrams with methods attached (or any other situation in which drill-down is available).

  • Reported: SysML 1.4 — Tue, 9 Jun 2015 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Expand use of rake symbol for all decompositions

    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

Connectors are not allowed in bdd

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

    Figure D.23 depicts two blocks with ports that are connected by a connector.

  • Reported: SysML 1.5 — Thu, 29 Nov 2018 09:33 GMT
  • Disposition: Resolved — SysML 1.7
  • Disposition Summary:

    Remove illegal connector/association

    Figure D.23 had, up through SysML 1.6, a bdd with a connector between the ports of two blocks. SysML 1.6 diagram was a slight modification of this, with an association between the blocks that was rendered through the ports. This is more legal, but ambiguous and doesn't meet the original intent. This proposal includes a replacement diagram without the offending connector. The diagram was generated out of the same model that generated the SysML 1.6 diagram, but with the association removed.

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

Numeric Literals as constraint block property parameter values

  • Status: closed  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    It would be very useful to have the ability to have literal values as parameter values to a constraint block property. (Helps with reuse of constraint blocks.) Even better, to be able to use named constants from a (shared) library package (i.e. a different namespace), which could combine a description of the value with quantity and unit attributes.

  • Reported: SysML 1.4 — Fri, 24 Feb 2017 18:26 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Numeric Literals as constraint block property parameter values

    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

Statements missing in the abstract syntax description

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description of stereotypes in the abstract syntax is missing all the "base_xxx" attributes that refer to the instances of extended elements. However this is required in order to specify the corresponding multiplicity and redefinition, if any.

    In addition, it should also be specified whether the corresponding stereotype is "required" or not. At that time, the only way to know it is to parse the normative XMI file.

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 07:18 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Statements missing in the abstract syntax description

    The issue was already fixed in SysML 1.6.

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

Description of model elements in generated document not consistent with specification

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

    The document that is generated from the model file defining the SysML profile contains descriptions of the model elements that are not consistent with the specification.

    Some description texts are completely missing, some are incomplete, and some have a different text than in the specification document.

  • Reported: SysML 1.4 — Mon, 26 Sep 2016 11:10 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Description of model elements in generated document not consistent with specification

    It is not a SysML issue, but an issue of the document generation tooling.

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

Typo in revised text of issue SYSML16-289

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

    Typos in revised text for Annex C

    • Change "C.1.1 and C.1.2" to "C.1.2 and C.1.3".
    • Change "C.5 through C.7" to "C.4 through C.7".
  • Reported: SysML 1.5 — Mon, 5 Mar 2018 20:42 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Typo in revised text of issue SYSML16-289

    The typo refers to a typo in a revised text of a SysML 1.6 issue and is not in SysML 1.6 specification.

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

Missing property descriptions for Probability and Rate

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

    The stereotypes Probability and Rate in the Activities chapter have no description of their properties.

  • Reported: SysML 1.4 — Mon, 2 Jan 2017 13:01 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Missing property descriptions for Probability and Rate

    The issue was resolved in SysML 1.6.

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

SysML Issue on Refine limitations

  • Key: SYSML17-57
  • Legacy Issue Number: 16016
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The text description of how the refine relationship can be used disagrees with formal restrictions.

    On page 126, 2nd paragraph, the text says.

    “The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.”

    This allows a refine relationship to be

    [Requirement] ß1..*[Model element]

    Or

    [Requirement] à [Model element]

    However, Figure 16.1 only has

    /refinedBy:Named Element[*] as property for a Requirement

    Thus it is not possible to have a requirement refine a model element.

    This is confirmed by Figure 16.2, which in showing the tags for a NamedElement

    Has /refines Requirement [*]

    This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around).

    So problem 1.

    The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence:

    The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.

    Problem 2

    The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word “diagram” from the text

    Final wording

    The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement.

    Additional comment.

    It’s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement.

  • Reported: SysML 1.4 — Wed, 9 Feb 2011 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Refine limitations

    The refine relationship is not limited to only refine Requirement model elements. As mentioned in the cited text "it may be used to show how a text-based requirement refines a model element".

    The conclusion that this is not possible, because there is no appropriate derived property in the Requirement stereotype is not correct. However, the issue is for SysML 1.4. In SysML 1.6 the AbstractRequirement has a derived property to cover the model elements that are refined by a requirement.

    A diagram is a metaclass in UMLDI. Problem 2 in the issue description is not correct.

    The final comment in the issue description addresses a problem that is not relevant anymore since the ability of specifying many-to-many relationships like refine, satisfy, or verify was removed in a previous SysML version.

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

SysML's PrimitiveValueTypes library is missing "value" properties everywhere

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

    For SysML 1.3, has anyone tried to specify the value of a SysML::ValueType ?

    If you haven't done so, please try to do this carefully – i.e., don't just assume that Real x = "42.0" is enough!

    You'll realize then that the SysML 1.3 spec doesn't provide the capability to specify the actual value for any of the SysML::Libraries::PrimitiveValueTypes

    SysML::Libraries::PrimitiveValueTypes::Boolean
    SysML::Libraries::PrimitiveValueTypes::Integer
    SysML::Libraries::PrimitiveValueTypes::Real
    SysML::Libraries::PrimitiveValueTypes::String

    Since we can't specify the actual real value of a SysML Real, we can't specify the realPart or the imaginaryPart of a SysML Complex number either!

    SysML::Libraries::PrimitiveValueTypes::Complex::realPart :
    SysML::Libraries::PrimitiveValueTypes::Complex::imaginaryPart

    What is missing is an actual "value" attribute whose type then must be from the UML PrimitiveTypes library since it's the only capability in UML/SysML we have to specify an actual "value" via the Literal[X] metaclasses in UML.

    SysML::Libraries::PrimitiveValueTypes::Boolean::value : PrimitiveTypes::Boolean – an actual value can be specified as a UML::LiteralBoolean
    SysML::Libraries::PrimitiveValueTypes::Integer::value : PrimitiveTypes::Integer – an actual value can be specified as a UML::LiteralInteger
    SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real – an actual value can be specified as a UML::LiteralReal
    SysML::Libraries::PrimitiveValueTypes::String::value : PrimitiveTypes::String – an actual value can be specified as a UML::LiteralString

    SysML::Libraries::PrimitiveValueTypes::Complex can remain as-is since it inherits the capability
    to specify an actual value for its realPart & imaginaryPart attributes thanks to SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real

    I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes.

    I believe that this is a new issue for SysML 1.3.

  • Reported: SysML 1.4 — Mon, 5 Dec 2011 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.7
  • Disposition Summary:

    Duplicate of SYSML17-52 and SYSML17-234

    Duplicate of SYSML17-52 and SYSML17-234

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

Virtual member representing the whole RTF

  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Would it be possible to create a special member in the RTF with no voting right (i.e. "assistant") , whose has the sysml-rtf@omg.org for email address?

    By adding it to the "watch this issue" list it would then become possible to notify the whole RTF automatically.

  • Reported: SysML 1.6 — Thu, 17 Jan 2019 13:48 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Not a SysML issue

    This is a JIRA feature request that was wrongly reported as a SysML issue. It is replaced by SUP-498

  • 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

Support BDD's for State Machines

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

    One very powerful organizational technique of SysML is the pairing of definitional diagrams with usage diagrams

    BDD (for Blocks) IBDs

    BDD (for Activities) ACTs

    BDD (for Constraint Blocks) PARs

    The BDD form identifies the elements (structural, functional, constraint) and the 2nd form assembles the elements using detailed design techniques suitable for the element form.

    It would be convenient and symmetric to support a similar diagram for for State Machines

    BDD(for States) STMs

    In the past, Class diagrams for States (in UML 1.x) were used. However, it appears that UML 2.x has deleted the ability to use inheritance relationships among states. Though we could look to UML to fix this, I believe it is possible to model state->substate relationships as compositions without a change to UML to produce a satisfactory conclusion.

  • Reported: SysML 1.4 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Support BDD's for State Machines

    StateMachine can be depicted in block definition diagrams since they are a specialization of Behavior that is a specialization of Class.

  • 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

ProxyPort with FlowProperties

  • Key: SYSML17-98
  • Legacy Issue Number: 18676
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I struggle to use proxy port with flow properties. One idea is to use a behavioral port and to bind the flow properties with the behavior parameters. In chapter 9.3.2.7 about FlowProperties the spec states:

    The binding of flow properties on ports to behavior parameters can be achieved in ways not dictated by SysML. One approach is to perform name and type matching. Another approach is to explicitly use binding relationships between the ports properties and behavior parameters or block properties.

    What are port properties? A port has no properties, but the type of the port, e.g. a InterfaceBlock. And these properties are the same for any usage of the InterfaceBlock and I can’t use context-specific binding relationships.

  • Reported: SysML 1.4 — Thu, 18 Apr 2013 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: ProxyPort with FlowProperties

    The bindings between port properties and, for example, adjunct properties for behavior parameters are context-specific. The statement in the issue text "I can't use context-specific binding relationships" is wrong.

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

Annex B / Figure B.9

  • Key: SYSML17-20
  • Legacy Issue Number: 12146
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.9: clarify turnIgnitionToStart message on driver:Driver Is it supposed to be a message to self ? If so please include message to self path, otherwise explain,

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Diagram is changed as of formal/17-05-01

    Reporter tagged this from formal/07-09-01 referring to diagram B.9.

    As of formal/15-06-03 the issue remains but the diagram has changed name to D.9.

    In formal/17-05-01 the ambiguous name symbol was deleted from the diagram and so the issue can be closed with no change.

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

How to refer to properties of an extension?

  • Key: SYSML17-78
  • Legacy Issue Number: 18168
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    For a practical usage it is required to be able to refer to a property of a stereotype application, for instance as target or source of an allocation relationship. This need is somewhat similar to that of referencing a nested property but we shall make sure the solution selected for the Common Reference Path will be able to address this case too.

  • Reported: SysML 1.4 — Mon, 2 Apr 2012 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: How to refer to properties of an extension?

    A resolution would require new features of SysML.

    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

Hanging Clauses Throughout SysML 1.4

  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    ISO/IEC Directives Part 2 2016 clause 22 states than each and every clause and subclause of the spec should be numbered, and hanging clauses should be avoided. Any numbered clause containing text or figures than that has a subordinate numbered clause becomes a hanging clause, because it does not have a unique number assigned to it.

    List of known hanging clauses in SysML 1.4 (exclusive of un-numbered ‘subpart’ text on pages 1, 19, 103, 145, and 185):
    6.2 page 17
    7.1 page 21
    7.3.2 page 26 (figure only)
    8.3.1.1 page 42
    8.3.1.2 page 44
    8.3.2 page 47 (figures only)
    8.3.3.1 page 59 (figure only)
    8.3.3.2 page 60 (figure only)
    9.1 page 71
    9.3.2 page 79 (figures only)
    10.3.2 page 100 (figure only)
    11.1 page 105
    11.3.1 page 114
    11.3.2 page 117 (both text and figure)
    11.3.3.1 page 121 (both text and figure)
    12.3.1 page 133
    15.3.2 page 150 (figure only)
    15.4 page 152 (both text and figure)
    15.4.2 page 153 (both text and figure)
    16.3.2 page 164 (figure only)
    16.4 page 168
    17.2.1 page 176 (figure only)
    17.2.2 page 178 (figure only)
    B.2 page 194 (figure only)
    C.1 page 203
    E.5.2 page 254 (both figures and text)
    E.6.5 page 286 (both figure and text)
    Annex F (no paragraph number)
    G.4 page 318

  • Reported: SysML 1.4 — Thu, 18 Aug 2016 15:39 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Hanging Clauses Throughout SysML 1.4

    The issue affects SysML 1.4 and was fixed in the meantime (see SysML 1.6.).

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

Deprecate Unit and QuantityKind stereotypes in 1.4

  • Legacy Issue Number: 19062
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Instead of deleting the Unit and QuantityKind stereotypes according to the 18269 resolution in SysML 1.4 ballot 4, I suggest moving these stereotypes to the SysML::DeprecatedElements package.

    Without doing this, a SysML 1.4 tool that opens a SysML 1.3 model will have to convert InstanceSpecifications stereotyped by SysML 1.3 Unit or QuantityKind into InstanceSpecifications classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind respectively.

    Even if a SysML 1.4 tool alerts the user that this migration has happened, it will not be possible to discern InstanceSpecifications classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind due migration from SysML 1.3 vs. deliberate choice.

    A better migration strategy would be to convert SysML 1.3 Unit/QuantityKind-stereotyped InstanceSpecifications into SysML 1.4 InstanceSpecifications that are both:
    stereotyped by SysML::DeprecatedElements::Unit/QuantityKind
    Classified by SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind
    The former leaves a persistent indication that the InstanceSpecifications have been partially migrated.
    The latter represents a partial migration to SysML 1.4 Units/QuantityKinds; that is, the user can complete the migration by classifying these InstanceSpecifications with concrete SysML Blocks that specialize SysML::Libraries::UnitAndQuantityKind::Unit or QuantityKind respectively.

  • Reported: SysML 1.4 — Fri, 1 Nov 2013 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: Deprecate Unit and QuantityKind stereotypes in 1.4

    The issue asked for another solution than voted in a ballot for SysML 1.4. It is too late for this issue since the model elements were deleted in SysML 1.4.

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

More than one View() operation allowed

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

    The viewpoint constraint about the View() operation allows more than one View() operation:

    [2] The property ownedOperation must include at least one operation named “View” with the UML Create stereotype
    applied.

    It is not specified what happens if there is more than one View() operation. For example:

    • In which order are they performed? If only one View() operation is performed it is not defined which one.
    • The wording of the derived property method is only about one operation ("of the operation").

    As long no one has a good use case to have more than View() operation I propose to change constraint [2] to:

    [2] The property ownedOperation must include exactly one operation named “View” with the UML Create stereotype
    applied.

  • Reported: SysML 1.4 — Sat, 27 Sep 2014 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Proposal: More than one View() operation allowed

    The namespace semantic requires that there are only unique View() operations defined. They can have the same name, but must differ in the list of parameters. The call of the View() operation clearly selects exactly one View() operation.

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

Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • Key: SYSML17-82
  • Legacy Issue Number: 18193
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

  • Reported: SysML 1.4 — Mon, 22 Oct 2012 04:00 GMT
  • Disposition: Closed; Out Of Scope — SysML 1.7
  • Disposition Summary:

    Proposal: Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane

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

    The AllocateActivityPartition allocates Actions only.

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

Annex B / Figure B.10

  • Key: SYSML17-19
  • Legacy Issue Number: 12145
  • Status: closed  
  • Source: No Magic ( Darren Kelly)
  • Summary:

    Figure B.10: justify/clarify 'StartVehicle' from outside in terms of UML Please clarify how UML4SysML supports the drawing of a 'StartVehicle' message from the boundary of a ref Interaction.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.7
  • Disposition Summary:

    Issue clarified by UML 2.5 and made irrelevent by SysML 1.6

    The original issue of this was with the formal gate on the sequence diagram Figure D.10.

    SysML 1.5 has Figure D.10 with a formal gate with an async StartVehicle message. This is supported by UML 17.2.4.6 "A formal Gate is just a point on the inside of the frame, as the end of a message. They may have an explicit name (see Figure 17.4)."

    SysML 1.6 has deleted the message originating from the diagram frame in general. This also solves this issue with no change.

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

Typo: Constraint name 8 of Adjunct Property (again)

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Duplicate of SYSML17-222 for which the resolution does not resolve anything!

  • Reported: SysML 1.6 — Wed, 29 Jun 2022 15:15 GMT
  • Updated: Wed, 29 Jun 2022 15:16 GMT

Statement about UML semantics of ActivityPartitions is wrong

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic.

    However, the UML says in clause 15.6.3.1 (which is the current number of the referenced section):

    Behaviors invoked within the partition are the responsibility of instances of the Classifier that the partition represents.

    Let me paraphrase this:
    SysML: "UML says Classifiers are responsible for invoking behaviors"
    UML: "Classifiers are responsible for behaviors"

    I guess invoking a behavior was confused with carrying out a behavior.

    My suggestion: It is not necessary to restate UML semantics in SysML. Since it cannot be expressed in ocl anyway, the complete constraint can be removed.

  • Reported: SysML 1.6 — Wed, 6 Apr 2022 18:44 GMT
  • Updated: Wed, 20 Apr 2022 16:04 GMT

wrong statement about UML semantics of partitions

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    Contraints 2_not_uml_semantics [...]. Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. To depict this kind of direct responsibility, the modeler is directed to the UML 2 standard, sub clause 12.3.10, "ActivityPartition," Semantics topic.

    This is not what UML specifies. Instead it says in "ActivityPartition", Semantics topic:

    Behaviors invoked within the partition are the responsibility of instances of the Classifier that the partition represents.

    That means, the instances of the represented element are responsible for carrying out the Behavior, not for invoking it. The context of the Activity owning the action is doing that - partitions have no effect on this.

  • Reported: SysML 1.6 — Tue, 28 Sep 2021 12:15 GMT
  • Updated: Wed, 20 Apr 2022 16:04 GMT

QUDV: Specification of PrefixedUnit should have a QuantityKind

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The redefinition of Unit::quantityKind property by PrefixeUnit::noQuantityKind with multiplicity 0 is wrong.

    The ConversionBasedUnit class should redefine quantityKind so that it is derived from the one defined by its referenceUnit.

  • Reported: SysML 1.6 — Thu, 29 Apr 2021 15:47 GMT
  • Updated: Sun, 10 Apr 2022 07:34 GMT

Added BehavioralFeatures to AdjuctProperty

  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

    Add UML::BehavioralFeature (UML::Operation or UML::SignalReception) to the allowed list of UML metaclasses of SysML::AdjunctProperty.principal, thus allowing a visual symbol (association) as well as fUML implementable way of accessing runtime instances of these behaviors through the structures that have them as their context. You could add them to the same constraint as CallAction, using the UML::BehavioralFeature.method as the constraining metaproperty . Also add an “or” to the constraint to allow SignalReception to get to it’s Signal metaproperty instead, or just create a new constraint separate for SignalReceptions.

  • Reported: SysML 1.6 — Mon, 14 Mar 2022 21:39 GMT
  • Updated: Thu, 17 Mar 2022 15:02 GMT

Meta-ticket: SysML-1.6: Specification body (only) figure inconsistencies and errors and related text inconsistencies

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    For issues with figures and diagrams and directly related text in the main specification body (only).

    Excludes diagrams from Annex D (but includes those diagrams in the text body that should be consistent with the Hybrid SUV sample problem).

    Includes diagrams that are not related to the Hybrid SUV sample problem.

    To prevent issue explosion, please report minor issues as single comments here.

    Please link more substantial issues related to main spec body figures and related text to this meta-ticket.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 12:54 GMT
  • Updated: Thu, 3 Mar 2022 17:55 GMT

ConstraintBlock: abstract syntax consistency

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Even if their respective specified semantics indicate that UML::Constraint::constrainedElement and the constraint parameters of a ConstraintBlock are similar, there is currently no constraint enforcing their consistency

  • Reported: SysML 1.6 — Thu, 5 Sep 2019 14:37 GMT
  • Updated: Sat, 12 Feb 2022 00:17 GMT
  • Attachments:

wrong name on Figure 9-6

  • Status: open  
  • Source: Performant Data LLC ( Mike)
  • Summary:

    The port on the ecu:PowerControlUnit of type ~ICE that links to the InternalCombustionEngine should be named "ice", not "ctrl", in order to match the text description of the figure.

  • Reported: SysML 1.6 — Fri, 7 Jan 2022 07:18 GMT
  • Updated: Mon, 10 Jan 2022 15:38 GMT

Why are FlowProperties not included in FlowDirectionKind

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Why can I not create something that requires a flow of
    fuel to operate?... this would require me to do something
    like

    flow properties
    reqd out gas:Gasoline

    Why would we exclude this?

  • Reported: SysML 1.6 — Tue, 9 Nov 2021 14:03 GMT
  • Updated: Thu, 25 Nov 2021 19:02 GMT

The FeatureDirectionKind to which the constraint belongs is wrong

  • Status: open  
  • Source: digiproto ( wuyanwen)
  • Summary:

    2_specializations_are_constraintblocks in FeatureDirectionKind should belong to 10.3.2.1 ConstraintBlock。

  • Reported: SysML 1.6 — Wed, 10 Nov 2021 02:55 GMT
  • Updated: Wed, 24 Nov 2021 15:31 GMT

FlowProperties as aggregations

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    2_no_part Interface blocks composite properties are either ports, value properties or flow properties.
    self.base_Class.ownedAttribute->select(a|a.isComposite)->forAll(a | a.oclIsKindOf(UML::Port) or a.oclIsKindOf(ValueType))

    This OCL does not cover all of FlowProperties... FlowProperties can be typed by ValueTypes, Signals, or Blocks... so it does not cover Signals or Blocks (so presumably Signal and Block typed FlowProperties can only be aggregates, which I think is wrong)

    Presumably, an AggregationKind=shared of FlowProperties means that the block does not own the Flow but has a reference to that flow... (this is not really specified well or talked about in the standard)...

    But the issue is that if you want a FlowProperty that is typed by Block or Signal... you can not because of this OCL... it has to be a ValueType... I think this is wrong

  • Reported: SysML 1.6 — Thu, 4 Nov 2021 16:29 GMT
  • Updated: Thu, 4 Nov 2021 17:45 GMT

NoBuffer: Clarify when a token is considered "refused"

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The SysML specification says (section 11.3.2.4, description sub-clause):
    "tokens arriving at the node are discarded if they are refused by outgoing edges"

    But the condition fro considering that a token is "refused" is specified neither in that specification nor in the UML specification.

    Proposal:
    Assume that a token is refused when its availability has been checked by an action that has an edge incoming from the node where this token is stored but not accepted by this action, whatever the reason.

  • Reported: SysML 1.6 — Wed, 3 Nov 2021 16:38 GMT
  • Updated: Thu, 4 Nov 2021 16:31 GMT

Comments in the XMI have no annotated elements

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The comments in the XMI that specify the documentation of the stereotypes and stereotype attributes do not annotate the elements they document.

  • Reported: SysML 1.6b1 — Fri, 7 Jun 2019 06:50 GMT
  • Updated: Thu, 21 Oct 2021 14:58 GMT

Stereotype Rate extends ObjectNode in the XMI, but not in the abstract syntax in the specification

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to figure 11.8, the stereotype Rate extends UML4SysML::Parameter and UML4SysML::ActivityEdge.

    In SysML.xmi, you can find a third extension of UML4SysML::ObjectNode. The Association Ends section in the specification also lists the ObjectNode extension:

    Association Ends
    • base_ActivityEdge : ActivityEdge [0..1]
    • base_ObjectNode : ObjectNode [0..1]
    • base_Parameter : Parameter [0..1]

    The diagram table in the activity chapter provides a concrete syntax for object nodes with stereotype Rate applied.

    Besides that, the extension of ObjectNode is not mentioned in the specification.

    If it is correct, that Rate extends ObjectNode:

    • Add extension in figure 11.8.
    • Provide semantic

    If it is not correct:

    • Remove extension from XMI and association ends section
    • Remove concrete syntax from diagram table
  • Reported: SysML 1.6 — Thu, 14 Nov 2019 16:26 GMT
  • Updated: Thu, 21 Oct 2021 14:55 GMT

no longer existing "primaryQuantityKind" shown in diagram E.8

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    SYSML14-36 removed the attribute primaryQuantityKind. In Figures E.8 - E.10 it is still shown. Additionally there is a constraint that uses it: SystemofUnits constraint 1 on page 296.

  • Reported: SysML 1.6 — Thu, 23 Sep 2021 12:27 GMT
  • Updated: Thu, 23 Sep 2021 14:11 GMT

Removes references to UML4SYSML from the SysML diagrams

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Discussed by the RTF on Sep 9, 2021:

    The notation showing UML4SYSML as the namespace of metaclasses imported from UML does not conform to the UML definition of a qualified name.

    The simple name of the metaclasses shall be used instead

  • Reported: SysML 1.6 — Thu, 9 Sep 2021 17:19 GMT
  • Updated: Thu, 9 Sep 2021 17:19 GMT

Mentioned stereotype «distributedDefinition» does not exist

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    This has already been an issue of the first version and is marked as beeing resolved in SYSML-112. I checked all versions and found it everywhere. Obviously the change was forgotten.

    It also affects table 11.1 on page 133 which shows "rate=constant, rate=distribution". While you can argue, that these are just names of InstanceSpecifications, the names suggest that they are meant to be values with this non existing stereotype. I think they should be changed to a rate value like "10/s". This table is also subject to changes in SYSML17-270. These changes should be coordinated.

  • Reported: SysML 1.6 — Fri, 20 Aug 2021 15:43 GMT
  • Updated: Thu, 9 Sep 2021 15:10 GMT

FinalState should be an exitPoint Pseudostate

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Statemachine ReadAmountSM is shown with an EndState on its border. This is not possible. The diagram is a partial copy of figure 14.13 in the UML-specification, where it is an exitPoint Pseudostate.

  • Reported: SysML 1.6 — Mon, 30 Aug 2021 10:03 GMT
  • Updated: Wed, 8 Sep 2021 13:50 GMT

connector properties should be in compartment

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Connector properties must be composite (there is a constraint) and therefore are to be shown in the "parts" compartment. In table 8.2 they are shown in the "references" compartment.

  • Reported: SysML 1.6 — Tue, 24 Aug 2021 13:30 GMT
  • Updated: Wed, 8 Sep 2021 13:49 GMT

Behavioral Ports and Nesting

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    If you have multiple nested ports and one is a behavioral port... does that mean that all the path of ports is behavioral?... the standard should have some statement concerning this

  • Reported: SysML 1.6 — Sun, 22 Aug 2021 14:45 GMT
  • Updated: Wed, 8 Sep 2021 13:48 GMT

DistributedProperty definition has to be reveiwed

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    There are issues in the referenced sections

  • Reported: SysML 1.6 — Wed, 25 Aug 2021 15:30 GMT
  • Updated: Wed, 25 Aug 2021 15:30 GMT

The circle plus notation is for members, not ownedElements

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    In table 7-2 the circle plus notation is noted as referencing the abstract syntax UML4SysML::Package::ownedElement. Actually, according to the UML specification, it refers to Package::member. Conformant tools can optionally limit it to packagedElements, which is a subset of ownedMember. This excludes comments,which could be ownedElements but not ownedMembers.

  • Reported: SysML 1.6 — Tue, 17 Aug 2021 12:37 GMT
  • Updated: Tue, 17 Aug 2021 22:17 GMT

Consistency with Effects and Ports

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    There is the fact that a Trigger can define a port (or nested ports in SysML)... Activities add the ability to do Call/Sends using "via <port>" (and SysML adds in how to do it with nested ports)... there is nothing in StateMachines that allow Effects to be sent through specific ports... this needs to be added in for consistency

  • Reported: SysML 1.6 — Mon, 16 Aug 2021 14:07 GMT
  • Updated: Mon, 16 Aug 2021 15:37 GMT

Association Rules

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Taking the rules in SysML...
    "SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity, to cover the specific case of a unidirectional reference that defines no named property for navigation in the inverse direction. SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel."

    and the fact that if you can navigate to something you also own it in SysML... then one can derive a rule...

    "if it does not have a navigation on the end, it can not be named"

    context: Association
    inv: memberEnd→ forAll(m |  a.navigableOwnedEnd.excludes(m) implies m.name = null)

    I think this needs to be in the Standard

  • Reported: SysML 1.6 — Wed, 11 Aug 2021 17:47 GMT
  • Updated: Mon, 16 Aug 2021 15:19 GMT

About Block constraint "3" removed by SysML v1.6

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Mr. Ed Seidewitz caught this:
    While researching a question forwarded to me by Sandy, I noticed what seems to be an inconsistency in the SysML 1.6 specification. SysML 1.5 included the following constraint under the Block stereotype:

    [3] In the UML metamodel on which SysML is built, any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association must [sic] not have a name and may not be defined as a navigable owned end of the association. (While the Property has a “name” property as defined by its NamedElement superclass, the value of the “name” property, which is optional, must be missing.)

    However, this constraint has been removed from the SysML 1.6 spec (and it is not included in the XMI).

    Issue SYSML16-310, which was merged into the resolution of SYSML16-274, addresses this constraint. In the comments on 310, Yves made a suggestion to remove the constraint, but then added a subsequent comment that reads: “Discussed during RTF weekly meeting on Sep 21: Ok for deleting the fits part of the sentence: "In the UML metamodel on which SysML is built" but any other change requires a separate issue” (SYSM16-310 - comment-17892, 21/Sep/17). There is also an earlier comment on the resolution to SYSML16-295 that notes “We had a discussion about constraint[3]. It seems the be not correct. Yves or Conrad will file an issue about that.” (SYSML16-295/SYSML16-297 - comment-17815, 31/Aug/17])

    But I cannot find any separate issue that was actually filed to remove constraint 3. The constraint was simply not included in the revised text in the resolution of SYSML16-274, and hence ended up being left out of the SysML 1.7 beta spec.

    So, there does not seem to be an apparent intent of the RTF to remove this constraint in SysML 1.6. Indeed, the following paragraph remains in the description section of subclause 8.3.2.3 Block in the 1.6 spec:

    “SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity, to cover the specific case of a unidirectional reference that defines no named property for navigation in the inverse direction. SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel.”

    This is text certainly no longer true without constraint 3, and I would have expected it to have been removed or updated if there had actually been an affirmative resolution to remove the constraint.

  • Reported: SysML 1.6 — Thu, 11 Apr 2019 13:24 GMT
  • Updated: Mon, 16 Aug 2021 15:19 GMT


AcceptChangeStructuralFeatureEventAction

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The two pins are not named... so there is no standard way of defining which is the before pin and which is the after.... would suggest you standardize the names "before" and "after"

  • Reported: SysML 1.6 — Fri, 6 Aug 2021 00:24 GMT
  • Updated: Mon, 9 Aug 2021 14:57 GMT

Implementation of non-normative extensions cannot be used in other OMG specifications

  • Status: open   Implementation work Blocked
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The extensions for SysML are of value to the general community, however, because they are not delivered in a machine readable and refrencable way, they cannot be used as a basis either for making normative to another specification and/or extended by another specification. There are issues as well for model interchange because of the lack of a normative form.

    It is suggested that SysML specification change the extensions to normative but optional profile and to further describe a compliance in which if the non-normative extensions are used, the whole profile shall be used and only changed by extension of that profile. There should also be recommendations for migrating from vendor implementation of extensions to the new normative version.

    The reason for this request is that the CubeSat System Reference Mode Profile (CSRM Profile)l used the non-normative extensions as a basis to further extend into the CubeSat domain. Unfortunately the use of the vendor supplied extensions were not from a compliant profile. The CSRM Profile team was forced to copy the extensions into the CSRM Profile in order to extend and use the extensions. This creates the danger that the CSRM Profile adds copies of the extension into a vendor's SysML implementation implementation and can cause interoperability issues.

    At this time, the CSRM Profile is pre-finalization and we could convert to a compliant version rather than the copy of the extensions we created. We would like this treated as a priority fix to allow for the creation of an XMI for refere3nce by our specification.

  • Reported: SysML 1.6 — Thu, 17 Jun 2021 13:30 GMT
  • Updated: Thu, 29 Jul 2021 16:09 GMT

move to SystemOfQuantities

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    this
    [1] The query accessibleQuantityKinds() gives all the QuantityKinds directly defined in the SystemOfQuantities or transitively in any included or used SystemOfQuantities.
    allAccessibleQuantityKinds() : QuantityKind[0..*]

    {unique}

    body: allAccessibleSystemOfQuantities()>collect(quantityKind)>flatten()->asSet() inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

    should be under SystemOfQuanties

  • Reported: SysML 1.6 — Tue, 20 Jul 2021 17:23 GMT
  • Updated: Wed, 21 Jul 2021 14:06 GMT

rename getKindOfQuantitiesForMeasurementUnit

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    getKindOfQuantitiesForMeasurementUnit should be renamed getQuantityKindsForMeasurementUnit

  • Reported: SysML 1.6 — Tue, 20 Jul 2021 17:11 GMT
  • Updated: Wed, 21 Jul 2021 14:05 GMT

OCL is not syntatically correct see ->allUnits()

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

  • Reported: SysML 1.6 — Tue, 20 Jul 2021 16:13 GMT
  • Updated: Wed, 21 Jul 2021 14:05 GMT

wrongfully copied

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    this statement

    includedSystemOfUnits: SystemOfUnits[0..*] Including a SystemOfQuantities means including all of the QuantityKind it defines and includes from other SystemOfQuantities

    should reflect Units rather than SystemOfQuantities

  • Reported: SysML 1.6 — Mon, 19 Jul 2021 21:33 GMT
  • Updated: Tue, 20 Jul 2021 13:21 GMT

OCL with SpecializedQuantityKind needs to be changed

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    OCL with SpecializedQuantityKind needs to be changed

  • Reported: SysML 1.6 — Sun, 18 Jul 2021 16:15 GMT
  • Updated: Tue, 20 Jul 2021 13:20 GMT

ControlValue to ControlValueKind

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    UML::Behavior.allInstances()>forAll(b | not (ControlOperator.allInstances().base_Behavior>includes(b) xor b.ownedParameter >exists(p | p.type=SysML::Libraries::ControlValues::ControlValue))) and UML::Operation.allInstances()>forAll(o | not (ControlOperator.allInstances().base_Operation->includes(o) xor o.ownedParameter ->exists(p | p.type=SysML::Libraries::ControlValues::ControlValue)))

    TO

    UML::Behavior.allInstances()>forAll(b | not (ControlOperator.allInstances().base_Behavior>includes(b) xor b.ownedParameter >exists(p | p.type=SysML::Libraries::ControlValues::ControlValueKind))) and UML::Operation.allInstances()>forAll(o | not (ControlOperator.allInstances().base_Operation->includes(o) xor o.ownedParameter ->exists(p | p.type=SysML::Libraries::ControlValues::ControlValueKind)))

  • Reported: SysML 1.6 — Fri, 18 Jun 2021 13:02 GMT
  • Updated: Wed, 23 Jun 2021 15:43 GMT

Changes to Annex D sample problem figures may impact on some specification body figures

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Changes to Annex D sample problem model (since SysML1.6) may impact on some spec body figures. Possibly impacted diagrams include:

    Figure 8-12 - Block diagram for the Wheel Package (WheelHubAssembly)

    Figure 8-13: Internal Block Diagram for WheelHubAssembly

    Figure 8-15: Vehicle decomposition

    Figure 8-16: Vehicle internal structure (BoundReference example)

    Figure 8-17: Vehicle specialization

    Figure 9-6: Usage example of ports with provided and required features

    Figure 11-11: Continuous system example

    Figure 11-13: Example block definition diagram for activity decomposition

    Figure 11-14: Example block definition diagram for object node types

    Figure 15-9: Allocation Matrix showing Allocation for Hybrid SUV Accelerate Example

    Figure 16-2: Requirements Derivation

    Figure 16-3: Links between requirements and design

    Figure 16.4: Requirement satisfaction in an internal block diagram

    Figure 16-5: Use of the copy dependency to facilitate reuse

    Figure 16-6: Linkage of a Test Case to a requirement (and Figure 16-7)

    In some cases this may also impact text that refers to these examples.

  • Reported: SysML 1.6 — Thu, 17 Jun 2021 14:54 GMT
  • Updated: Thu, 17 Jun 2021 14:55 GMT

Need constraint for inverted provided/required Interfaces (InterfaceRealization and Usage) on ~InterfaceBlock

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML-1.6 supports Interfaces provided/required (InterfaceRealization and Usage) by a Block, including an InterfaceBlock.

    Given that UML-style Port conjugation is not supported in SysML-1.6, a mechanism for inversion of provided/required Interfaces is needed.

    While Figure D.19 does not show the Port types, it does show provided/required Interfaces on Ports, and it is implied by other diagrams in the sample problem that those Ports that have inverted provided/required Interfaces are typed by ~InterfaceBlocks.

    A constraint should be added to 9.3.2.15 ~InterfaceBlock corresponding to the inversion of any required/provided Interfaces on the original InterfaceBlock.

  • Reported: SysML 1.6 — Fri, 3 Jul 2020 09:25 GMT
  • Updated: Thu, 17 Jun 2021 14:40 GMT

Constraint Typos

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    allAccessibleQuantityKinds() : QuantityKind[0..*]

    {unique}

    body: allAccessibleSystemOfQuantities()>collect(quantityKind)>flatten()->asSet() inv SoU3_3: getEffectiveSystemOfQuantities() = null or let aqk : Set(QuantityKind) = getEffectiveSystemOfQuantities().allQuantityKinds() in ->allUnits() ->forAll(u | aqk>includesAll (getKindOfQuantitiesForMeasurementUnit(u)))

    notice the "in ->allUnits()" ... something wrong here

  • Reported: SysML 1.6 — Tue, 20 Apr 2021 19:38 GMT
  • Updated: Fri, 30 Apr 2021 13:33 GMT

QUDV: Unknown property primaryQuantityKind

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The operation SystemOfUnits::isCoherent() and the figure E.8 uses a property "primaryQuantityKind" which is not defined in E.5.

  • Reported: SysML 1.6 — Tue, 20 Apr 2021 14:33 GMT
  • Updated: Thu, 29 Apr 2021 17:17 GMT

SysML model URI in the specification document

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Section §2 of the SysML specification should mention the URI of all the models (normative and non-normative) that are produced as part of a SysML version (i.e. those for which the URL is given on the front page)

  • Reported: SysML 1.6 — Thu, 29 Apr 2021 15:31 GMT
  • Updated: Thu, 29 Apr 2021 15:31 GMT

Suggest capability to list :features on Pin symbols and on elided Pin "ObjectNode" rectangle symbol

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML already has the capability to list :features (such as :values, :operations etc.) in compartments on Property and Port symbols in IBDs.

    The same capability could be introduced for Pin symbols in Activity Diagrams to reveal :features of the types of Pins.

    UML2.5.1 describes also an elided Pin notation where a single rectangular "ObjectNode" symbol along with two arrows (not edges) represents two Pins of identical type and a single ObjectFlow edge (in the underlying model). This notation does not have good support in all tools. It could however also benefit from the ability to list :features on that "ObjectNode" symbol (where the type is the type of the 2 Pins it actually represents).

  • Reported: SysML 1.6 — Wed, 21 Apr 2021 03:41 GMT
  • Updated: Wed, 21 Apr 2021 16:28 GMT

Suggest capability to list :features on ItemFlows in a rectangle symbol over a Connector or Association line

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This ticket is a re-imagining of (partial resurrection of) a proposal from Michael Chonoles that I strongly supported:

    https://issues.omg.org/browse/SYSML17-103

    https://issues.omg.org/browse/SYSML17-208

    If the RTF chairs truly consider any new features out-of-scope this can be bumped to SysMLv2, but as Conrad wrote under SYSML17-208:

    I think SysML 1.x should address this. It will be a long time before SysML2 is a finalized OMG spec. We should be supporting modelers in the meantime with small upgrades like this.


    SysML already has the capability to list :features (such as :values, :operations etc.) in compartments on Property and Port symbols in IBDs. Indeed, this notation has proved one of the most popular advantages of SysML over UML.

    The same capability could be introduced for ItemFlows, which could be extended to optionally support representation as a rectangle symbol on Connectors lines and Associations lines (or wherever ItemFlows may be shown), with compartments for listing :features.

    In the case where the ItemFlow does not have an itemProperty, the rectangle could appear much like a Block symbol (but over a relevant line).

    In the case where the ItemFlow has an itemProperty, the rectangle could appear much like a Property symbol (but over a relevant line).

    In both cases the header of the rectangle could show the direction arrow for the ItemFlow.

    In both cases the ability to display defaults for value properties would be extremely useful.

    (Variations on the notation would have to cope with situations where there is more than one applied ItemFlow.)

  • Reported: SysML 1.6 — Wed, 21 Apr 2021 04:11 GMT
  • Updated: Wed, 21 Apr 2021 04:12 GMT

Suggest introduce strict diagram policy: avoid "elided Pin" ObjectNode notation in Activity Diagrams in all revised and future specification figures

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    I suggest that diagram submitters never ever again use the infamous "elided Pin notation" for ObjectNode anywhere in the spec, as it is widely misunderstood and the tool support for it is poor (broken).

    This concerns not only the Annex D sample problem, but all other Activity Diagrams in all figures in the spec.

    The problematic "elided Pin" notation as described in UML-2.5.1 :

    'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'

    The relevant UML-2.5.1 Figure 15.9 ObjectFlow notations is attached.

    Please note how it describes the notation as two object flow arrows (notational symbols that do not correspond one-to-one to ActivityEdge elements, but rather to one ObjectFlow edge). Note also how it says there are two Pins in the underlying model.

    At least one tool implements this notation incorrectly and uses 2 ObjectFlows and a CentralBufferNode instead of two arrows and a rectangular symbol representing any ObjectNode sub-type.

    I appreciate the OMG JIRA is not intended for personal remarks, but I can't begin to explain how much time wrangling with broken "elided Pin" ObjectNode notation in one tool has cost me, time which could be better used contributing to the specification. I ask you all to please vote yes for this in a ballot soon so that I can contribute more.

    DK

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 11:31 GMT
  • Updated: Wed, 21 Apr 2021 03:47 GMT
  • Attachments:

Body conditions of operation in QUDV model should be Boolean expressions

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The body conditions of the QUDV operations in section E.5.2 are not specified as Boolean expressions. They specify only the computation of the return value.

    If the return parameter is named "result" they should be stated as

    result = <computation of return value>

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 06:36 GMT
  • Updated: Mon, 19 Apr 2021 06:36 GMT

QUDV::PrefixedUnit: Redefinition of quantityKind

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    QUDV::PrefixedUnit redefines quantityKind to set the multiplicity to 0:

    noQuantityKind : QuantityKind [0]

    It would be better to define a constraint instead:
    self.quantityKind = null

    The property noQuantityKind is specified in the XMI, but not mentioned in the PDF.

  • Reported: SysML 1.6 — Mon, 19 Apr 2021 05:42 GMT
  • Updated: Mon, 19 Apr 2021 05:42 GMT

Issues in figure E-7

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure E-7: QUDV QuantityKinds has the following issues:

    • Should be a bdd instead of pkg
    • Remove diagram number and icon from header
    • Remove owner from blocks
    • Association between Dimension and SystemOfQuantities: Multiplicity end systemOfQuantities is 1..* in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
    • Association between QuantityKind and QuantityKindFactor: Multiplicity end quantityKind is 1 in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
    • Association between DerivedQuantityKind and QuantityKindFactor: Multiplicity end DerivedQuantityKind is 1 in SysML 1.6 and 0..* in SysML 1.5. There is no documented change between SysML 1.5 and SysML 1.6.
  • Reported: SysML 1.6 — Sat, 17 Apr 2021 18:14 GMT
  • Updated: Sat, 17 Apr 2021 18:14 GMT

7_composition_acyclic wrong

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    I agree with this that this should be the intent... "Within an instance of a SysML Block, the instances of properties with composite aggregation shall form an acyclic graph"... but I believe the OCL statement restricts the types and not the instances... I will give an example... it should restrict an instance from being a part of itself... but is should not restrict a Type having a part of the same type (which I believe this does)... take for example something that says System has a composition to itself whose navigation end is named "subSystem"... this says that a System can contain other Systems as a part "subsystem"... this should be legal... but a system1:System cannot contain itself as a subsystem of itself... that should be illegal... I believe that your constraint, constrains the Type (which it should not) and therefore the instance... but it should only constrain the instance and not the type...

  • Reported: SysML 1.6 — Sat, 27 Mar 2021 13:33 GMT
  • Updated: Thu, 1 Apr 2021 17:19 GMT

If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8: Water Delivery association block

    Although it is explained in the text, I have had many clients and training customer unnecessarily imitate it.

    It [EDIT: the «port» keyword] is introduced in Figure 9-8, and then never used in any of diagrams that follow.

    If it must stay, it should be made clear that it is a user-defined stereotype keyword.

    BTW: I address this in my own models by using conventions for Port type naming: I_Contract, F_FlowStuff etc.

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 07:45 GMT
  • Updated: Tue, 16 Mar 2021 07:50 GMT

orderedMember in ElementGroup should be {ordered}

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    orderedMember in ElementGroup should be

    {ordered}
  • Reported: SysML 1.6 — Wed, 24 Feb 2021 14:05 GMT
  • Updated: Mon, 1 Mar 2021 11:27 GMT

AbstractRequirement needs to be consistent

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The pattern used through out the standard is with an Association End so Attribute base_NamedElement should be an association end and not an attribute

  • Reported: SysML 1.6 — Wed, 24 Feb 2021 15:22 GMT
  • Updated: Wed, 24 Feb 2021 17:20 GMT

Description for getSatisfies

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The Description for getSatisfies should be similar to that of getVerifies

    The query getSatisfies() gives all the requirements that are suppliers ( "to" end of the concrete syntax ) of a «Satisfy» relationships whose client is the element in parameter. This is a static query.

  • Reported: SysML 1.6 — Wed, 24 Feb 2021 15:04 GMT
  • Updated: Wed, 24 Feb 2021 15:15 GMT

Parameter names mismatch in ~InterfaceBlock::areConjugated(Property, Property)

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The parameter names in the signature of that operation are "p1" and "p2" respectively while "a1" and "a2" are used in the statement of the body condition

  • Reported: SysML 1.6 — Mon, 22 Feb 2021 09:58 GMT
  • Updated: Mon, 22 Feb 2021 09:58 GMT

Suggest introduce an operation to obtain the magnitude of a value property in a given compatible Unit (to afford equality comparison)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Spawned from SYSML17-31 to help support comparisons for BindingConnector.

    Suggest introduce an operation to obtain the magnitude of a value property in a given compatible Unit (to afford equality comparison)

    A compatible Unit is any Unit that has the same fundamental Dimensions as the Unit of the value property for which the magnitude is to be obtained. It need not be (but typically would be) from the same Unit system.

    [EDIT: See attached Wolfram Mathematica example with CompatibleUnitQ example]

    Equality of values of value properties at the ends of a BindingConnector can be compared via the proposed operation:

    • The case where the two value properties have the same Unit from the same system is trivial.
    • In the case where the two value properties have compatible Units (same fundamental Dimensions) from the same system but different scaling factors (say g vs kg), a simple scaling must be performed.
    • In the case where the two value properties have compatible Units (same fundamental Dimensions) from different systems (say ft vs km), a conversion and possibly also a scaling must be performed.

    This proposal does not restrict tools to use any particular choice of Unit when performing equality comparisons.

    This proposal specifically only supports comparison of values of value properties with compatible fundamental Dimensions, but does not involve quantity kind.

  • Reported: SysML 1.6 — Thu, 14 Jan 2021 22:25 GMT
  • Updated: Fri, 15 Jan 2021 06:29 GMT
  • Attachments:

Taken literally the text and OCL of constraint '6_valueproperties_composite' imply that every FlowProperty typed by a ValueType should have AggregationKind 'composite'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Although the name of the constraint 6_valueproperties_composite suggests it is only intended for value properties, the text and OCL of the constraint imply that a FlowProperty typed by a ValueType should also have AggregationKind composite:

    ‘If a property owned by a SysML Block or SysML ValueType is typed by a SysML ValueType, then the aggregation attribute of the property shall be "composite."’

    self.base_Class.ownedAttribute->select(a| ValueType.allInstances().base_DataType ->includes(a.type))->forAll(a|a.isComposite())
    

    Note also that the following specification text on p.53 under 8.3.2.4 Block if taken literally would mean that any FlowProperty typed by a ValueType is a value property:

    'A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.'

  • Reported: SysML 1.6 — Thu, 14 Jan 2021 01:58 GMT
  • Updated: Thu, 14 Jan 2021 21:38 GMT

Property types 'Four general categories of properties of blocks are recognized in SysML ...' does not cover FlowProperty

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From SysML-1.6 8.3.1.2.1 Property types p.43 :

    'Four general categories of properties of blocks are recognized in SysML: parts, references, value properties, and constraint properties. (See 8.3.2.4 for definitions of these property types.)'

    Elsewhere 'parts' and 'references' are described as being typed by Blocks, but a FlowProperty typed by a Block is not typically listed in the corresponding compartments.

    A FlowProperty need not be typed by a ValueType, and is not typically understood to be a value property so is not covered by 'value properties' (see however SYSML17-399).

    The same issue arises on p.53 under 8.3.2.4 Block:

    SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType. A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. Constraint properties are further defined in Clause 10. A port is another category of property, as further defined in Section 9. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. Part, reference, value, and constraint properties may be shown in block definition compartments with the labels "parts," "references," "values," and "constraints" respectively. Properties of any type may be shown in a "properties" compartment or in additional compartments with user-defined labels.

    Because FlowProperty can be typed by ValueType, Block or Signal it is not covered well by the above; every attempt to handle the cases applied to any of the above results in "definition whack-a-mole"

  • Reported: SysML 1.6 — Thu, 14 Jan 2021 06:34 GMT
  • Updated: Thu, 14 Jan 2021 06:34 GMT

InterfaceBlock: OCL constraint 2_no_part is missing FlowProperty check for cases where a FlowProperty is not typed by a ValueType

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.99

    2_no_part

    Interface blocks composite properties are either ports, value properties or flow properties.

    self.base_Class.ownedAttribute->select(a|a.isComposite)->forAll(a |
    a.oclIsKindOf(UML::Port) or a.oclIsKindOf(ValueType))

    EDIT: Needs to also check whether is a FlowProperty of a valid type other than ValueType, noting from SysML-1.6 FlowProperty:

    '1_restricted_types A FlowProperty shall be typed by a ValueType, Block, or Signal.'

  • Reported: SysML 1.6 — Sat, 4 Jul 2020 14:50 GMT
  • Updated: Thu, 14 Jan 2021 06:05 GMT

Compartments for Connectors and Participants

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The Standard is not clear about compartments for Connectors and Participants... it is presumed that since Connectors has a OwnedConnectors in the metamodel in UML... that a "connectors" compartment is implied (but the standard should probably state as much to make sure tools are consistent)... there could also be a <<connector>> compartment according to the standard... so this needs to be consistent... there is nothing about Participants... so presumably they go into "properties" compartment... or a <<participants>> compartment... they are could be references (because they are composite) but one may not want to mix them in with references (I would not want to, but the standard may want to grant a compartment called "participants" for the purpose)

  • Reported: SysML 1.6 — Sat, 31 Oct 2020 16:26 GMT
  • Updated: Tue, 17 Nov 2020 16:50 GMT

Suggest not allow an AssociationBlock to type a BindingConnector used for pure proxying

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This issue report illustrates two separate (but apparently related) issues:

    DISCLAIMER: The example shown for modelling an electronics jack or socket in electronics is not an approach advocated by this reporter. It is however a frequently used or attempted approach.

    Primary issue: When a BindingConnector used to indicate pure proxying is typed by an AssociationBlock, the AssociationBlock can be used to undermine the claimed equality of the proxy, at least when nested Ports are involved.

    In the attached example, the L and R channels of a stereo system have been swapped by the AssociationBlock (which swapping is invisible at the level of the BindingConnector it types).

    It is proposed that constraint(s) be introduced for BindingConnector and/or AssociationBlocks, along with improved explanations for ParticipantProperty, to prevent the typing of BindingConnectors by AssociationBlocks used for pure proxying.

    (AssociationBlocks are otherwise very useful, it is not suggested here that their use should be otherwise prevented.)

    A 2nd issue was identified by John Brush of 7Sigma. In the situation as modelled, tools report that the innermost BindingConnectors (owned by the AssociationBlock) between the nested Ports have invalid flow directions.

    That issue can be avoided by instead using a non-behavioral Port or a FullPort with additional inner-facing nested Ports to model the jack/socket, however that 2nd issue may be a valid concern for some other modelling cases.

  • Reported: SysML 1.6 — Tue, 10 Nov 2020 02:32 GMT
  • Updated: Tue, 10 Nov 2020 02:44 GMT

All kinds of errors in Fig. 8-17

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    1. Vehicle should have a compartment labeled "bound references" rather than just "references"
    2. According to constraint 7 in BoundReference
    "BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"
    so Vehicle Model 2 should not have <<boundReference>>, endPathMultiplicity is ok... but should have lower and upper defined for the example
    3. This diagram should be an example of how multiplicity on the property and lower and upper can differ

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:36 GMT
  • Updated: Sat, 7 Nov 2020 00:45 GMT
  • Attachments:

Figure 8-17: Vehicle specialization: multiple inconsistencies

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From SysML-1.6:

    'The specialization on the lower left restricts the number of cylinders to four, requires a light roll bar, and a total of 24 lug bolts over all the wheels. '

    In block Vehicle Model 1:

    • The multiplicity of cylinderBR should be [4] not [*]
    • Multiplicity of rollBarBR should be [1] not [*] and it has no redefined type for the 'light roll bar' (it would also help if the parent block Vehicle and the sub-blocks all showed the types on their properties).
    • Multiplicity of lugBoltBR in the spec figure is [6..8], it should be [6]

    'The specialization on the lower right restricts the number of cylinders to between six and eight, rules out any roll bar, and limits lug bolts per wheel to between 6 and 7, by giving the end path upper and lower values.'

    In block Vehicle Model 1:

    • Multiplicity of rollBarBR should be [0] not [*]
    • EndPathMultiplicity is applied to rollBarBR instead of lugBoltBR
    • It's also not entirely clear (to me) whether the multiplicity of lugBoltBR should be [*].

    The annotated attachment shows an attempt at improving it (but is not offered as a resolution figure).

  • Reported: SysML 1.6 — Sun, 28 Jun 2020 13:55 GMT
  • Updated: Sat, 7 Nov 2020 00:37 GMT
  • Attachments:

constraint needed

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    perhaps a specification is needed that says that lower and upper are the same as lower and upper of the multiplicity if they are not specified or not initialized... that way, if tools are asking what is lower and upper they will get something relevant

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:42 GMT
  • Updated: Wed, 28 Oct 2020 16:29 GMT

Relationship should be specified for Stakeholder to a View

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:
    • How do you tie a view to a stakeholder, should specify a type of relationship
  • Reported: SysML 1.6 — Tue, 27 Oct 2020 19:17 GMT
  • Updated: Wed, 28 Oct 2020 16:26 GMT

Adjunct allows for additional notation on CallBehaviorActions

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Currently with CallBehaviorActions there is no way to specify that there are only so many instance that can be executed if one has an instance of an Activity... if that action is marked as isReentrant=true.. but with adjuncts one can specify that an adjunct property has multiplicity (which restricts min/max number of instances)... it would be nice if that could also be shown on an Activity diagram by allowing multiplicities in the upper right corner of an appropriate Action that specifies these multiplicities

  • Reported: SysML 1.6 — Mon, 26 Oct 2020 21:18 GMT
  • Updated: Tue, 27 Oct 2020 19:39 GMT

What are redefined BoundReferences

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    What compartment does a property go into that redefines a BoundReference... note that such a property can not be stereotyped as BoundReference so presumably, it can not go into that compartment... so is it a reference? (but it does not fit the definition because it is not the end of an association)... there is just the properties compartment...

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 18:57 GMT
  • Updated: Tue, 27 Oct 2020 19:39 GMT

EndPathMultiplicity and BoundReference Ordered and Unique

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    BoundReference is ordered and nonunique... this is not the default and should be shown in the diagrams...
    Since EndPathMultiplicity is a redefine of BoundReference if it is applied by itself... then each
    EndPathMultiplicity has to also be ordered and nonunique... this should be explained... and should be a constraint in EndPathMultiplicity

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 15:07 GMT
  • Updated: Tue, 27 Oct 2020 19:38 GMT

Lower and Upper Explained

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    I believe the reason Lower and Upper were added into the standard was to allow for multiplicities that did not follow the multiplicity rules of the standard... I have an example... and I think an example should be in the standard to clarify this mystifying need for lower and upper... because it is not clear really why they are needed...

    suppose I have the following
    part1[3..4]
    part2[3..7]
    part3[4..6]

    and I want to bind a BoundReferece x to part1.part2.part3 in block y... now I can take several approaches...
    1. <<boundReference>> x:Part3 [*[ - this removes the double maintenance problem when multiplicities of the paths change does not restrict anything
    2. <<boundReference>> x:Part3 [36..168] - this mimics the multiplicities of the path, so really no restriction
    3. <<boundReference>> x:Part3 [2..10] - this restricts the number of part3s that there can be at the end of that path

    option 3 could have also been specified as
    <<boundReference>> x:Part3 [*]

    {lower=2,upper=10}

    now block z specializes block x and I have another property a such that
    <<endPathMultiplicity>> a:Part3[*[

    {redefines x,lower=5,upper=20}

    but this only works if x has multiplicity * otherwise
    <<endPathMultiplicity>> a:Part3 [5..20[

    {redefines x}

    if x is <<boundReference>> x:Part3 [2..10] does not work
    because 5..20 is not a restriction of 2..10

    This is why lower and upper can be different (but constrained by) the multiplicity

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 14:00 GMT
  • Updated: Tue, 27 Oct 2020 19:38 GMT

Lower and Upper are constrained

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    There should be a constraint in EndPathMultiplicity which states that Lower is no less than the lower on the multiplicity and that upper is no greater than the upper on the multiplicity

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:38 GMT
  • Updated: Tue, 27 Oct 2020 19:37 GMT

Statement about EndPathMultiplicity

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    constraint 1 in EndPathMultipliticity
    "Properties to which EndPathMultiplicity is applied shall be related by redefinition to a property to which BoundReference is applied."
    and constraint 7 in BoundReference says
    "BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"

    so if there is a endPathMultiplicity applied... it must be to a property, not a BoundReference, but to one redefining a boundReference
    ... this should be explicitly stated in the standard... otherwise it is not obvious

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:29 GMT
  • Updated: Tue, 27 Oct 2020 19:36 GMT

BoundReference Specificity

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    A BoundReferrence must be more general in multiplicity than the property it binds to... but there is nothing in the constraints that specify this... the lower and upper limit the number in that specific Type

    Also, the best practice for BoundReference is to make its multiplicity * so there is not the double maintenance issue if any multiplicity changes along the path it is bound to... this should be specified

    Also, specify that lower, upper of BoundReference restricts the multiplicity of the property it is bound to... and there should be example showing how the multiplicity of BoundReference can be different than the values of lower,upper and why

    also, the statement "Properties to which BoundReference is applied shall be the role of a connector end of at least one binding connector, or generalized by such a property through redefinition" especially "or generalized by such a property through redefinition" is not clear as to what is being generalized

    also, an example of when nonuniqueness would come into play would be good in the standard

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:26 GMT
  • Updated: Tue, 27 Oct 2020 19:36 GMT

BoundReference Diagram is wrong

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Block1 should have two compartments one reference and one bound reference (for property11)... property11 in Block2 is not correct as a redefine because it widens rather than restricts the multiplicity of property11 in Block1...property11 in block1 would need to have a multiplicity of *

  • Reported: SysML 1.6 — Sun, 25 Oct 2020 13:12 GMT
  • Updated: Tue, 27 Oct 2020 19:35 GMT

Unclear English Statement

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The OCL is probably clear but the English is not...

    4_same_owner
    Properties with AdjunctProperty applied shall be owned by an element that owns the principal, at least indirectly, or one of that elements specializations.

    could be read as "Properties with AdjunctProperty applied shall be owned by a specialization of the element that owns the principal"

    or "Properties with AdjunctProperty applied shall be owned by an element whose specialization owns the principal"

  • Reported: SysML 1.6 — Thu, 1 Oct 2020 23:37 GMT
  • Updated: Tue, 27 Oct 2020 19:30 GMT

Make Annex E Optional but Normative

  • Status: open  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    Currently Annex E of the SysML spec is called "Non-Normative Extensions" and marked "Informative". However, the content of Annex E is widely implemented and used, and recently also referred to by other submissions as normative reference. It would therefore make much sense to make the Annex E normative, but optional (via a Compliance clause). This would still leave implementers the freedom to implement Annex E, or to ignore it. However, if implemented, then it must precisely follow the specification. This would improve interoperability and exchangeability of the Annex E items, and would make the content of Annex E referable by other submission.

    To achieve this change, the Annex E title and Overview sub-clause need to be changed, and an additional bullet point inserted into Clause 5.2:

    "Optional extension conformance. A tool may implement the specifications of Annex E in its entirety, or implement selected specifications from Annex E at the discretion of the tool implementer. If so, then any implementation must follow the specifications provided by Annex E exactly."

  • Reported: SysML 1.6 — Tue, 29 Sep 2020 23:10 GMT
  • Updated: Thu, 8 Oct 2020 00:44 GMT

Figure E.6 QUDV Units Diagram display exactly the same content as Figure E.5 QUDV Concepts Diagram

  • Status: open  
  • Source: KARL STORZ SE & Co. KG ( Marting Bohring)
  • Summary:

    In Version SysML 1.5 the QUDV Units diagram presented the other Unit Types. In Version SysML 1.6 the Units Diagram displays the same content as the Concepts Diagram.
    AS a result the Units Diagram of SysML Version 1.5 has disappeared

  • Reported: SysML 1.6 — Wed, 15 Jul 2020 11:50 GMT
  • Updated: Tue, 21 Jul 2020 20:50 GMT

The 'initialValues' compartment needs to be renamed 'contextValues' and they need to be referred to as 'context-specific values'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    I have never liked the term 'initial values' or the compartment name 'initialValues' for what were originally called 'context-specific values'.

    I propose instead they be called 'context-specific values' because that is what they in fact are (values within the context of a top-level configuration block), and a compartment 'contextValues'.

    In most cases the values as used have nothing to do with "initial". Even the spec example Figure D.41 has nothing to do with initial, it is about a test configuration.

    I helped supervise development and testing of this feature many years ago in the MagicDraw tool (along with Nerijus at No Magic). It was the first tool to implement the feature. Back then we referred to the feature as context-specific values (and it used to be called that in the tool menu).

    I have been using this feature a lot for some years with real world clients. Nearly all of them find the term 'initialValues' completely confusing, especially after just having been introduced to the 'defaultValue' concept.

    Case: Am using SysML for a construction group. They use initialValues to describe multiple "deep" configurations of buildings in different modes and customer configurations. They find the term initialValues completely confusing.

    Case: The mobile phone initialValues sample available for MagicDraw/Cameo is in fact a "deep" configuration example (and an excellent one) and has nothing to do with "initial values".

    I also have a course session dedicated to how to use this feature for "deep" configuration of systems. Attendees find the term 'initialValues' completely confusing, I tell them to call it 'contextValues' instead.

    And as for time? If you want to use the feature to show the value state of a system at different times: t0, t1, t2, t3 in different block contexts you can't; because the compartment name 'initialValues' makes it sound like every time slice is the initial time t0.

    It truly has to go. It does not work. The compartment name 'contextValues' works for all cases.

    I have even taken to "painting over" the term 'initialValues' in some diagrams.

    This SysML feature/capability itself is extremely important and useful; it's an absolutely critical extension over UML.

  • Reported: SysML 1.6 — Sun, 28 Jun 2020 00:41 GMT
  • Updated: Mon, 6 Jul 2020 17:11 GMT

Suggest primary/replica as alternative to master/slave terminology for Copy relationship

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Suggest primary/replica as alternative to master/slave terminology for Copy relationship.

    The term 'slave' appears on p.181:

    The use of namespace containment to specify requirements hierarchies precludes reusing requirements in different contexts since a given model element can only exist in one namespace. Since the concept of requirements reuse is very important in many applications, SysML introduces the concept of a slave requirement. A slave requirement is a requirement whose text property is a read-only copy of the text property of a master requirement. The text property of the slave requirement is constrained to be the same as the text property of the related master requirement. The master/slave relationship is indicated by the use of the copy relationship.

    And p.188:

    getMaster () : AbstractRequirement [0..*]
    bodyCondition: Copy.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier

    p.189

    A Copy dependency created between two requirements maintains a master/slave relationship between the two elements for the purpose of requirements re-use in different contexts.

    The change would also require changing all references to '/master' to '/primary'.

    In 2014 Drupal CMS adopted the term primary/replica.

    The terminology master/slave has recently been removed from the Python language.

    There are some other options recently adopted by technology companies, but they do not play as nicely with the Copy relationship as 'primary/replica'.

  • Reported: SysML 1.6 — Mon, 6 Jul 2020 09:24 GMT
  • Updated: Mon, 6 Jul 2020 09:24 GMT

SysML-1.6: Refers to both 'composite requirement' and 'compound requirement'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.181

    16.1 Overview
    ...
    A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism. This relationship enables a complex requirement to be decomposed into its containing child requirements. A composite requirement ..

    p.191

    16.3.2.5 Requirement
    ...

    Compound requirements can be created by using the nesting capability of the class definition mechanism. The default interpretation of a compound requirement, unless stated differently by the compound requirement itself, is that all its subrequirements shall be satisfied for the compound requirement to be satisfied.
    ...

    Might be best to choose just one term 'compound requirement' or 'composite requirement

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 14:00 GMT
  • Updated: Sun, 5 Jul 2020 14:01 GMT

BindingConnector constraint 1_compatible_types: Use of OCL conformsTo contradicts definition of compatibility of connected ProxyPort, does not admit per Feature compatibility or compatibility via a union of connected features

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    EDIT: from SysML-1.6 p.52:

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.'

    SysML-1.6 p.52 states:

    1_compatible_types

    The two ends of a binding connector shall have either the same type or types that are compatible so that equality of their values can be defined.

    self.base_Connector.end->at(1).role.type.conformsTo(self.base_Connector.end
     ->at(2).role.type) or self.base_Connector.end
     ->at(2).role.type.conformsTo(self.base_Connector.end->at(1).role.type)
    

    OCL-1.4 states concerning conformsTo:

    8.2.1 Type Conformance

    The type conformance rules are formally underpinned in the Semantics sub clause of the specification. To ensure that the rules are accessible to UML modelers they are specified in this sub clause using OCL. For this, the additional operation conformsTo(c : Classifier) : Boolean is defined on Classifier. It evaluates to true, if the self Classifier conforms to the
    argument c.

    ...

    [2] Classes conform to superclasses and interfaces that they realize.
    context Class
    inv : self.generalization.general->forAll (p |
    (p.oclIsKindOf(Class) or p.oclIsKindOf(Interface)) implies
    self.conformsTo(p.oclAsType(Classifier)))
    

    As far as this submitter can tell, there is no sense in which OCL conformsTo is not Type-based at the level of a Classifier.

    This renders numerous desirable ProxyPort connection scenarios invalid.

    Case: A ProxyPort of InterfaceBlock type PP1 and an internal part property of block type Standalone, where PP1 and StandalonePart have identical Feature signatures, but do not share a Type relationship.

    From SysML-1.6 p.52:

    9.3.2.13 ProxyPort

    ...

    When a proxy port is connected to a single internal part, the connector shall be a binding connector, or have the same semantics as a binding connector (the value of the proxy port and the connected internal part are the same; links of associations typing the connector are between all objects and themselves, and no others).

    Whether one uses a BindingConnector or a Connector with the same semantics, the reported constraint renders the Connection from proxy port :PP1 to internal part :Standalone invalid, even though all Features match, because there is no type "value" equivalence.

    Consider now from p.103:

    When a proxy port is connected to multiple internal parts, the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features, and treating flows and invocations from outside the aggregate as if they were to those parts, and flows and invocations it receives from those parts as if they were to the outside.

    ASIDE: The spec could make clearer in the above whether the Connectors that are used for such multiple connections are NOT BindingConnectors

    An attempt to work around it using multiple Connectors from the proxy port :PP1 to at least all of the Property features of internal part :Standalone - which are themselves 'parts' in the UML sense - also leads to a contradiction w.r.t:

    the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features ..

    The attempt was to aggregate the Property features themselves, not their features.

    And even if the above were to work, it does not address the compatibility with Operations, and is also highly impractical in tools when there are many Properties to bind (collect).

    The complexity and number of possible contradictions explodes when indeed connections are made to multiple parts.

    What is needed is a completely different definition of compatibility that is not bound in any way to types, but primarily to matching Features (including Operations, Receptions and Properties) by "collecting" the Features via Connectors to their owners.

    This would then support common engineering scenarios where subsets of Features of internal parts are aggregated and then "exported" via a single exposed Port.

    This would greatly reduce the number of Connectors needed, and would make validation in tools much easier. Type-based compatibility can still be kept, but it is just a special case of Feature-wise compatibility.

    The Property features of internal part :Standalone clearly count as 'multiple internal parts'. Assuming regular Connectors are used (but not BindingConnectors) from proxy port :PP1 to every Property of internal part :Standalone

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 09:28 GMT
  • Updated: Sun, 5 Jul 2020 11:34 GMT

9.3.2.13 ProxyPort 'When a proxy port is connected to a single internal part ...' extend to include ' or port on an internal part'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.103

    Proxy ports can be connected to internal parts or ports on internal parts, identifying features on those parts or ports that are available to external blocks.

    And:

    When a proxy port is connected to a single internal part, the connector shall be a binding connector, or have the same semantics as a binding connector ...

    The 2nd sentence would more consistent if it included ' or port on an internal part' thus:

    When a proxy port is connected to a single internal part or port on an internal part, the connector shall be a binding connector, or have the same semantics as a binding connector ...

  • Reported: SysML 1.6 — Sun, 5 Jul 2020 08:45 GMT
  • Updated: Sun, 5 Jul 2020 08:45 GMT

SysML-1.6: text on Requirement 'Test and procedure conditions' is mangled in 'Figure 16-2: Requirements Derivation' (was OK in SysML-1.5) [also affects Figure 16-6]

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure 16-2: Requirements Derivation

    In SysML-1.5 Requirement text was:

    (a) IBT: <= 65 °C (149 °F), <= 100 °C (212 °F). (b) Test surface: PFC of at least 0.9.

    In SysML-1.6 p.195 Requirement text does not have comparison operators.

    Tested in Adobe Reader and Mac Preview on a Mac.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 08:54 GMT
  • Updated: Thu, 2 Jul 2020 13:16 GMT
  • Attachments:

'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it as 'an example of a compound requirement'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.195

    SysML-1.6: Figure 16-2: Requirements Derivation indeed shows DeriveReqt examples, but the spec text refers to it as 'an example of a compound requirement'.

    Either: The spec text needs to say is also an example of DeriveReqt

    Or: The figure needs to be renamed to something like: Figure 16-2: Requirements Derivation and compound requirements

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 09:05 GMT
  • Updated: Thu, 2 Jul 2020 13:15 GMT

'Figure 9-6: Usage example of ports with provided and required features' does not expose any directed features

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    All the diagram shows is some port types and their conjugated types.

    It would be more instructive if the ports on the diagram used the capability to show the underlying directed features of the blocks that type the ports.

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 05:54 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

SysML-1.6 does not leverage redefinition of 'sp:Surface' on 'Figure 9-7: Usage example of proxy and full ports'. And does not show direction of flows on Ports symbols

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML-1.6 spec figure 'Figure 9.7 - Usage example of proxy and full ports'.

    Does not leverage redefinition of sp:Surface, which is shown as redefined in many blocks but nothing is actually redefined.

    Some earlier spec versions did leverage the redefinition, see also the attachment for similar done in a tool.

    Also, it does not show direction of flows on the ports (but this notation is optional).

  • Reported: SysML 1.6 — Mon, 29 Jun 2020 06:36 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

Figure 9-16 and Figure 9-17 'Usage example of item flow decomposition': multiple inconsistencies

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.115:

    Figures 9.16 and 9.17 are examples of item flow decomposition that modelers might choose...

    Should be 'Figures 9-16 and 9-17'

    p.115:

    In Figure 9-16, the item flow classifier (EnginePart) is a supertype of the classifiers of the item flows in the decomposition. The flow properties are all in the types of the nested ports ...

    But it does not show those flow properties in the lower BDD (compare with attachment 1).

    It would make sense to show the flow property direction indicators in the structure compartment of A1 in the lower BDD.

    Minor/optional: If the parent ports do not have any flow properties in this example, it might be better to not show the flow direction indicator in the parent port in Figure 9-16, even though the flow direction for each nested port within each parent port is in the same direction. Then, for contrast, the flow direction indicators can be shown on the parent ports of Figure 9-17, noting they have explicit flow properties.

    p.115 and p.116:

    In Figure 9-17, the item flow classifier (Engine) composes the classifiers of the items flows in the decomposition from Figure 9-17.

    This should probably be 'from Figure 9-16'.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 00:29 GMT
  • Updated: Thu, 2 Jul 2020 13:04 GMT

The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.147 Figure 11-10: Continuous system example 1 shows an object flow with an object token of type ControlValue (should probably be ControlValueKind) from a ControlOperator Enable on Brake Pressure > 0 to Monitor Traction.

    The notation shown is consistent with UML-2.5.1 "elided Pin" notation:

    'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'

    The relevant UML-2.5.1 Figure 15.9 ObjectFlow notations is attached.

    Please note how it describes the notation as two object flow arrows (notational symbols that do not correspond one-to-one to ActivityEdge elements, but rather to one ObjectFlow edge). Note also how it says there are two Pins in the underlying model.

    At least one tool implements this notation incorrectly and uses 2 ObjectFlows and a CentralBufferNode instead of two arrows and a rectangular symbol representing any ObjectNode sub-type

    SysML-1.6 p.146 states:

    Brake pressure information also flows to a control operator that outputs a control value to enable or disable the Monitor Traction behavior. No pins are used on Monitor Traction, so once it is enabled, the continuously arriving enable control values from the control operator have no effect, per UML semantics.

    It is not permissible in UML-2.5.1 to have 'No pins used on Monitor Traction'. And if there were no Pins, it is not clear how {contro\l} is indicated in Figure 11-10, because, from UML-2.5.1:

    Control Pins are shown with the textual annotation {control} placed near the Pin symbol.

    If there are 'No pins used on Monitor Traction' the {control} notation can't be supported.

    Further: SysML-1.6 p.127 states:

    A control value is an input or output of a control operator ..

    If there is any sense in which it can be "input" to another type of Action (the controlled one), this should also be stated.

    On SysML-1.6 p.140 it is not made clear what 'control parameters' are:

    Pins for control parameters are regular pins, not UML control pins.

    If they are parameters of a Behavior with the ControlOperator stereotype applied this should be clearly stated. Otherwise, the (necesssary) {control} input Pin required on Monitor Traction in Figure 11-10 could be considered to have an underlying "control parameter" that contradicts the above rule.

    A partial solution (apart from suggested expansions of the explanatory text) would be to at least use an explicit {control} Pin on Monitor Traction and remove the claim that it has no Pins.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 10:09 GMT
  • Updated: Thu, 2 Jul 2020 13:03 GMT
  • Attachments:

Edge for [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The edge for the [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow (it is currently dashed):

    From UML-2.5.1:

    edges

    The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows.

  • Reported: SysML 1.6 — Tue, 30 Jun 2020 11:49 GMT
  • Updated: Thu, 2 Jul 2020 13:03 GMT

Suggest additional main body figure illustrating context-specific values (initialValues) compartment used for deep system configuration

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    It has been suggested that sample Figure D.41 should not be an IBD but a BDD with objects (instances).

    A new spec example (not related to Annex D Hybrid SUV problem) is then required.

    Suggest use mobile phone camera configuration example (known to me and a tool vendor).

    Submitter willing to provide spec-friendly diagram(s) and supporting spec text.

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 11:18 GMT
  • Updated: Thu, 2 Jul 2020 13:01 GMT

Inconsistent incoming ObjectFlow and outgoing ControlFlows on the DecisionNode in Figure 11.12 - Continuous system example 3 'Enable on Brake Pressure > 0'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The 'Figure 11.12 - Continuous system example 3' for the Activity 'Enable on Brake Pressure > 0' shows a single incoming ObjectFlow from the ActivityParameterNode pressure : Brake Pressure to a DecisionNode with two outgoing ControlFlows (shown dashed) with guards vs Brake Pressure.

    It is not indicated whether the incoming ObjectFlow is a DecisionNode::decisionInputFlow. Assuming it is or is not both lead to contradictions vs the UML-2.5.1 spec.

    First, assume that is it not a decisionInputFlow. Then according to UML-2.5.1 it is then the primary incoming edge:

    A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge.

    But this means the reported figure immediately contradicts:

    If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows.

    Because in the reported figure clearly there is a mix of a single incoming ObjectFlow and 2 outgoing ControlFlows.

    Let us then instead assume that the incoming ObjectFlow is a decisionInputFlow. The UML spec then seems to require that there be an additional ControlFlow (that is not present in the reported figure).

    Some related UML-2.5.1 spec quotes and constraints:

    edges
    The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows.

    incoming_outgoing_edges
    A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge.

    decisionInputFlow : ObjectFlow [0..1] (opposite A_decisionInputFlow_decisionNode::decisionNode)
    An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode.

    If the primary incoming edge of a DecisionNode is an ObjectFlow, and the DecisionNode does not have a decisionInput or decisionInputFlow, then the value contained in an incoming object token may be used in the evaluation of the guards on outgoing ObjectFlows.

    This is clearly not consistent with the reported figure, which has outgoing ControlFlows.

    The following seems to imply that decisionInputFlow is always accompanied by another incoming edge, but this is not (as far as I can tell) made explicit elsewhere as a constraint:

    If a DecisionNode has a decisionInputFlow, then a token must be offered on both the primary incoming edge and the decisionInputFlow before the token from the primary incoming edge is offered to the outgoing edges.

    [ASIDE: The UML-2.5.1 might be inconsistent when referring to 'incoming' w.r.t. decisionInputFlow (but this does not explain away the inconsistency in the reported SysML spec figure). The DecisionNode::decisionInputFlow does not subset ActivityNode::incoming:ActivityEdge[0..*], but it is sometimes referred to as an incoming edge.]

    An additional consideration is why outgoing ControlFlows are being used in the first place. The UML-2.5.1 does not seem to explicitly reject the use of incoming ObjectFlows on a ValueSpecification (although at least one tools declares InputPins on them to be invalid). It is not clear to this reporter that ObjectFlows with Probability could not be used to activate the ValueSpecifications for enable/disable (even though the reported spec figure for this version seems to have been changed to used dashed-line ControlFlows, compared with previous SysML spec versions).

    [EDIT:DK: Axel explained: 'ValueSpecificationActions can in fact have no InputPins (the attribute input is a derived union and ValueSpecificationActions don't define a subset of it).']

    It seems to this reporter that there are 2 solutions to the reported inconsistency:

    1. Somehow use an additional ControlFlow to the DecisionNode, and declare the existing Brake Pressure incoming ObjectFlow to be a decisionInputFlow.

    2. "Revert" the outgoing edges to be ObjectFlows [NOT permitted]

  • Reported: SysML 1.6 — Mon, 15 Jun 2020 04:47 GMT
  • Updated: Thu, 2 Jul 2020 12:58 GMT

'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not allocate to a FlowProperty and multiple other minor issues

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    In SysML-1.6 p.179: Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty

    The diagram does not show any allocation to a FlowProperty.

    Also:

    • It does not show the allocatedFrom for 'Action2' on Block7
    • It does not make sense naming the BDD 'Block0' if that block is not shown in the diagram

    There are allocations from Actions (usage level) to Blocks (definition level); whether that is an error is a matter of opinion, as it would seem SysML permits it. I suggest, however, that the spec figures completely avoid such "cross-level" allocations in the spec figures.

    May I once again suggest (plead, beg) diagram submitters to not (never ever again) use the infamous "elided Pin notation" for ObjectNode anywhere in the spec, as it is widely misunderstood and the tool support for it is poor (broken).

    An example diagram in the MagicDraw tool including explicit Pins is included. The naming conventions is different from the spec figures.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 11:20 GMT
  • Updated: Thu, 2 Jul 2020 12:57 GMT

Fig D.41 should be bdd with instance specs & slot values, not ibd with default values

  • Status: open  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    Figure D.41 is unchanged from SysML 1.0. The purpose of the figure was to illustrate how part serial numbers can be handled in SysML, but it was created without any practical experience in instance specification slot values. Instance slot values provide a more concrete representation of instance-level values such as serial numbers. A serial number should never be treated as a default value, because each serial number needs to be unique.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 17:13 GMT
  • Updated: Thu, 2 Jul 2020 11:19 GMT

SysML-1.6: DeriveReqt: OCL constraint directions client vs supplier

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.190: please check OCL directions:

    1_supplier_is_requirement

    The supplier shall be an element stereotyped by a subtype of
    AbstractRequirement.AbstractRequirement.allInstances().base_NamedElement->includesAll(self.base_Abstraction.client)

    2_client_is_requirement

    The client shall be an element stereotyped by a subtype of
    AbstractRequirement.AbstractRequirement.allInstances().base_NamedElement->includesAll(self.base_Abstraction.supplier)

  • Reported: SysML 1.6 — Thu, 2 Jul 2020 09:45 GMT
  • Updated: Thu, 2 Jul 2020 09:45 GMT

Trivial: consistency: Either show the [metaclass] on all Stereotype symbols or none in 'Figure 16-1: Abstract Syntax for Requirements Stereotypes'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The Stereotype symbols for AbstractRequirement and Requirement show their [metaclass], the others do not.

  • Reported: SysML 1.6 — Wed, 1 Jul 2020 13:39 GMT
  • Updated: Wed, 1 Jul 2020 13:39 GMT

Figure D.24 Parametric Diagram does not explicitly show «equal» keyword or '=' on BindingConnectors

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    If the Connectors in the Figure D.24 'Defining Fuel Flow Constraints (Parametric Diagram)' are BindingConnectors suggest explicitly show «equal» keyword or '='.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 00:13 GMT
  • Updated: Wed, 24 Jun 2020 07:04 GMT

Typo: 'not' should be 'nor' in '... not is this always even desirable'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From p.174:

    It is acknowledged that this concept does not support a standard object-oriented paradigm, not is this always even desirable.

    The 'not' should probably be 'nor'

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 04:24 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: references to FuelTankAssy should be FuelTankAssembly for consistency with Figure D.25

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.254:

    The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine.

    Figure D.25 has FuelTankAssembly.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 04:03 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: 'Various other model elements may be necessary to help develop a derived requirement, and these model element' plural missing

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Plural missing in:

    'Various other model elements may be necessary to help develop a derived requirement, and these model element may be related by a «refinedBy» relationship.'

    Should be:

    'Various other model elements may be necessary to help develop a derived requirement, and these model element*s* may be related by a «refinedBy» relationship.'

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 22:22 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: Missing end parentheses bracket: '(described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams)'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    SysML-1.6 p.249:

    Note that the interactions DriveBlackBox and Stac4rtVehicleBlackBox (described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams), are depicted as owned by the AutomotiveDomain block.

    There is a missing end ')'

    (The issue with 'Stac4rtVehicleBlackBox' already caught under SYSML17-271)

  • Reported: SysML 1.6 — Sun, 21 Jun 2020 02:57 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Typo: 'with is owned by the AutomotiveDomain block.'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This diagram represents the “DriveBlackBox” interaction, with is owned by the AutomotiveDomain block.

    Should be:

    This diagram represents the “DriveBlackBox” interaction, which is owned by the AutomotiveDomain block.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 00:11 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Need Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)'

    This is implied by p.254:

    The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine ...

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 03:41 GMT
  • Updated: Wed, 24 Jun 2020 06:46 GMT

Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    From SysML-1.6 p.254:

    Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.

    The Figure D.24 shows these value properties: 'fuelFlowRate', 'fuelDemand' and 'fuelPressure' (all lowerCamelCase). The text does not match those value property names.

    The Figure D.24 shows these bound constraint parameters: 'flow rate' (with a space), 'injectorDemand' and 'press'. Suggest also constraint parameter 'flow rate' should be consistently named in the diagram 'flowRate' (no space and lowerCamelCase).

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 02:10 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification»

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure D.23 has FuelFlow stereotyped by the DEPRECATED «flowSpecification»

    Known already to Marlin and Rick

  • Reported: SysML 1.6 — Mon, 22 Jun 2020 07:40 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

'Figure D.7 - Elaborating Black Box Behavior' some OCL missing, State names in oclInState() should be capital first letter, and display of name of alt fragment

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure D.7 Elaborating Black Box Behavior for the “Drive the Vehicle” Use Case (Sequence Diagram)

    The OCL for the ref fragment for Idle appears to be missing in the SysML 1.6 figure version (was present in the SysML 1.5 version).

    The referenced State name should have capital first letters to match the States in Figure D.1. From OCL-1.4:

    The operation oclIsInState(s) results in true if the object is in the state s. Possible states for the operation oclIsInState(s) are all states of the statemachine that defines the classifier's behavior. ...

    [EDIT: Actually, SysML-1.6 makes explicit that the Interaction DriveBlackBox is owned by the AutomotiveDomain block,
    so the ‘self’ won’t be the same context as for the StateMachine (so it might not be able to reference those States directly).]

    The name of the alt fragment 'controlSpeed' does not appear in the SysML-1.6 figure (it did in SysML-1.5 ). This may be deliberate. And it can't (as far as I can tell) be shown in MagicDraw/Cameo anyway. But it's a bit confusing when referenced here:

    The conditions for each alternative in the alt controlSpeed sub clause are expressed in OCL, and relate to the states of the HybridSUV block, as shown in Figure D.8.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 01:25 GMT
  • Updated: Wed, 24 Jun 2020 06:45 GMT

SysML-1.6: Figure D.25 has the type Fuel for both an in Port and an out Port on FuelTankAssembly (and it is not ideal to have same name as the Classifier that flows)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)

    Has the type Fuel for both an in Port and an out Port on FuelTankAssembly

    And it is not ideal to have same name Fuel as the Classifier Fuel that flows.

    I happen to use the prefix convention F_ for Ports that have flows (only) of one Classifier, so in this case F_Fuel and ~F_Fuel

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 06:36 GMT
  • Updated: Wed, 24 Jun 2020 06:44 GMT

7.3.2.3 Expose refers to 'The method' without referencing Viewpoint

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    7.3.2.3 Expose

    ...
    The view and the model elements related to the view are passed to the constructor when it is invoked. The method describes how the exposed elements are navigated to extract the desired information.

    Although it is explained (somewhat) under 7.1.1. View and Viewpoint, it would be clearer if it said something like:

    The method of the Viewpoint the View conforms to describes how the exposed ...

    Otherwise it reads like a View has a method.

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 12:20 GMT
  • Updated: Tue, 23 Jun 2020 12:20 GMT

Typo: 'Binding connectors, as defined in Clause 8 are used ...' missing comma

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    p.123 Has:

    Binding connectors, as defined in Clause 8 are used ...

    Should probably be (note comma after 'Clause 8,'):

    Binding connectors, as defined in Clause 8, are used ...

    This is the pattern used in UML-2.5.1.

    Hope this one is not too trivial to raise as a ticket. Worth establishing a convention/policy

  • Reported: SysML 1.6 — Tue, 23 Jun 2020 00:54 GMT
  • Updated: Tue, 23 Jun 2020 01:02 GMT

Typo: 'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.' should be 'deletes'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    'Deleting the container requirement deleted the nested requirements, a functionality inherited from UML.'

    Should probably be:

    'Deleting the container requirement deletes the nested requirements, a functionality inherited from UML.'

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 21:58 GMT
  • Updated: Tue, 23 Jun 2020 01:02 GMT

Typo: 9.3.2.8 FlowProperty 'A flow propertys values'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    A flow propertys values

    Should be:

    A flow property's values

  • Reported: SysML 1.6 — Mon, 22 Jun 2020 07:07 GMT
  • Updated: Mon, 22 Jun 2020 07:07 GMT

For Connectors in IBD Figure D.4 to be typed by implied anonymous Associations need define them in BDD Figure D.15 between 'HybridSUV' and: 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The SysML-1.6 spec states:

    'The associations among the classes may represent abstract conceptual relationships among the entities, which would be refined in subsequent diagrams.'

    'Note how the relationships in this diagram are also reflected in the Automotive Domain Model Block Definition Diagram, Figure D.15.'

    Actually, they aren't, the BDD Figure D.15 only shows non-navigable composition Associations between the Automotive Domain block and the owned Properties, which appear in the IBD Figure D.4 as Property symbols.

    The Connectors in the spec figure have labels like 'x1:', 'x2:', etc. This seems to imply the existence of anonymous Assocations (between 'HybridSUV' and 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment'), but they are not defined in Figure D.15.

  • Reported: SysML 1.6 — Sun, 21 Jun 2020 01:41 GMT
  • Updated: Sun, 21 Jun 2020 03:26 GMT
  • Attachments:

In Figure D.2 Real appears to be owned by the Automotive Value Types ModelLibrary (with no explicit ElementImport)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    In 'Figure D.2: Defining value Types and units to be used in the Sample Problem' the Real appears to be owned by the Automotive Value Types ModelLibrary.

    This might be intended (it might intend to imply there is an ElementImport); if this is the case maybe it should be made explicit somewhere (in a diagram or in text).

    Otherwise, it should be drawn outside the ModelLibrary.

  • Reported: SysML 1.6 — Wed, 17 Jun 2020 00:17 GMT
  • Updated: Wed, 17 Jun 2020 00:17 GMT

Lots of ControlValues that should be ControlValueKinds

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Lots of ControlValues that should be ControlValueKinds

  • Reported: SysML 1.6 — Fri, 28 Feb 2020 05:06 GMT
  • Updated: Mon, 15 Jun 2020 05:11 GMT

It should not be allowed to modify an AdjunctProperty

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As described in the specification, AdjunctProperties are clearly intended for representing as properties things that should have been defined as such but that are not for historical reasons.

    However, even if it can actually be convenient to use read actions adjunct properties, it is not clear what is the semantics of using write actions on them. In addition, per its description, it is clear that and an adjunct property is derived from its principal.

    Base on the above, constraints shall be added in order to: (1) require an adjunct property to be derived, and (2) prevent using a adjunct property as the target of write action

  • Reported: SysML 1.6 — Thu, 30 Apr 2020 12:42 GMT
  • Updated: Thu, 30 Apr 2020 15:32 GMT

Duplicated sentence

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    The following sentence appears both before the bullet items list and as the first item in the bullet items list.

    "In the context of the definition of a SysML Stereotype, the name refers to the definition of a UML::PrimitiveType in the UML 2 PrimitiveTypes library"

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 04:51 GMT
  • Updated: Fri, 3 Apr 2020 18:51 GMT

Unexpected word 'Figure' in Figure 4-2 name

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Figure 4-2 name is "SysML Extension of UMLFigure".
    The word "Figure" at the end of the legend is not expected.

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 04:47 GMT
  • Updated: Fri, 3 Apr 2020 18:51 GMT

Unexpected section number

  • Status: open  
  • Source: Mentor, a Siemens Business ( Fabien Launay)
  • Summary:

    Section number 17.2.1.1 is used whereas section 17.2.1 does not exist

  • Reported: SysML 1.6 — Wed, 25 Mar 2020 02:36 GMT
  • Updated: Fri, 3 Apr 2020 18:50 GMT

Clarify that contraint parameters are value properties

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description given for ConstraintBlock makes it implicit that constraint parameter are value properties but there is no formal constraint about it.

  • Reported: SysML 1.6 — Thu, 12 Mar 2020 14:38 GMT
  • Updated: Thu, 12 Mar 2020 14:38 GMT

7_cannot_redefine_boundreference is too constrained

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Standard says.... "BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied"

    This constraint seems very arbitrary... BoundReference could be used akin to an alias... which allows one to use it as another layer of indirection... BoundReferences should be allowed to refer to other BoundReferences so if the "other BoundReference" changes one does not have to change the first one which refers to it

  • Reported: SysML 1.6 — Sun, 1 Mar 2020 16:36 GMT
  • Updated: Mon, 2 Mar 2020 15:58 GMT

Aggregation multiplicities not correct

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Statement... "That is: "0..1" if the attribute has a composite aggregation and "0..*" otherwise"

    The standard specifies that...
    "8.3.1.1.10 Default multiplicities
    SysML defines defaults for multiplicities on the ends of specific types of associations. A part or shared association has a default multiplicity of [0..1] on the black or white diamond end. A unidirectional association has a default multiplicity of 1 on its target end. These multiplicities may be assumed if not shown on a diagram. To avoid confusion, any multiplicity other than the default should always be shown on a diagram."

    so the assumption would be 0..1 not 0..* on the otherwise part... UML has the same thing

  • Reported: SysML 1.6 — Thu, 27 Feb 2020 18:21 GMT
  • Updated: Mon, 2 Mar 2020 15:57 GMT

SysML 1.6 statement is too strong

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    SysML says...
    “Unless a type of diagram element is shown in some form in one of the SysML diagram elements tables, or in a usage example in one of the normative SysML clauses, it is not considered to be part of the subset of UML included within SysML, even if the UML metamodel packages support additional constructs. For example, SysML imports the entire Dependencies package from UML, but it includes diagram elements for only a subset of the dependency types defined in this package.”

    so does that mean all of the actions in common behavior are not there (even though they are explicit included in the tables in the first chapter?)

    I think the statement above in SysML does not include everything... if this is what is wanted then UML4SysML needs to be changed to be only the things in the diagrams in the standard...

  • Reported: SysML 1.6 — Tue, 25 Feb 2020 03:18 GMT
  • Updated: Tue, 25 Feb 2020 14:52 GMT

Caveat is not specific for UseCases

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The current standard says:

    "The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property."

    But this is not totally true... the Communication Path in Use Cases is modeled as an Association and it has no navigability shown, which means it is navigable on both ends, which means ownership on both ends, but the ends are UseCases and Actors which are BehavioredClassifiers which do not have attributes, so this statement in the standard must be added to, to

    (this should go in a sentence in the standard after the sentence cited)
    allow Association to own both end of the association ends if one end is either an Actor or a UseCase.

    I state either because SysML deriving most of its UseCase semantics from UML... an Actor can be associated to a Classifier in a UseCase per UML... and a UseCase can be associated to another UseCase in UML provided that UseCase is not specifying the same Subject... this is specified in UML 2.5.1 in section 18.1.4

    "UseCases may have other Associations and Dependencies to other Classifiers"

    also 18.2.1.4 says "An Actor can only have Associations to UseCases, Components, and Classes. Furthermore these Associations
    must be binary."

    and 18.2.5.6 "UseCases cannot have Associations to UseCases specifying the same subject"

  • Reported: SysML 1.6 — Fri, 21 Feb 2020 14:40 GMT
  • Updated: Tue, 25 Feb 2020 14:51 GMT

Introduction to 9.1.3 Proxy Ports and Full Ports might be interpreted as SysML only permitting Full and Proxy Ports (not standard ports)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The following sentence under 9.1.3 Proxy Ports and Full Ports can cause confusion:

    SysML identifies two usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    It may be read as SysML only permitting Proxy Port and Full Port.

    I suggest it could be improved by adding the one word 'additional':

    SysML identifies two additional usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    Or more verbosely, something like:

    Apart from standard UML port usage, SysML identifies two additional usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).

    My experience is that some new SysML users (in part because of the way some tool menus work) get the impression that one somehow should not being standard ports at all in SysML, which is completely wrong.

    Some tools seem to assume (incorrectly) that just because SysML introduces Proxy and Full Port that one is always supposed to use one of them instead of a standard port, and they hide standard ports from some menus.

    I absolutely advocate the use (where appropriate) of standard ports still, especially early on during modelling. External clients of a port are not supposed to care ("know") anyway, it's ultimately an implementation detail.

    The SysML spec itself (as of SysML 1.6) is currently very clear on this:

    • 'Ports that are not specified as proxy or full are simply called "ports."'
    • 'Proxy and full ports support the capabilities of ports in general, but these capabilities are also available on ports that are not declared as proxy or full.'
    • 'Modelers can choose between proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology.'
    • 'Modelers have the option of applying stereotypes for proxy and full ports to indicate whether ports are specifying features of their owners and internal parts (proxy), or for themselves separately (full).'
    • 'Using existing blocks with ports only requires knowing the port types ...'
    • 'Modelers can apply stereotypes for proxy and full ports at any stage of model development, or not all if the stereotype constraints are not needed.'
    • 'Figure 9-7 happens to use unstereotyped ports on a general block distributed to users, and stereotyped ports on its specializations for implementation, but the modelers might have not used stereotypes at all ...'
    • 'Unstereotyped ports do not commit to whether they are proxy or full, and do not prevent or dictate future application of the stereotypes'

    etc.

    (There are also considerations when using Ports from readonly libraries.)

  • Reported: SysML 1.6 — Sat, 15 Feb 2020 01:10 GMT
  • Updated: Mon, 24 Feb 2020 03:17 GMT

Continuous and Discrete need to be on FlowProperties as well

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Continuous and Discrete need to be on FlowProperties as well as Parameters and ActivityEdge

  • Reported: SysML 1.6 — Thu, 20 Feb 2020 20:03 GMT
  • Updated: Thu, 20 Feb 2020 20:08 GMT

No Creation and Destruction Event in Current UML

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    UML4SysML::CreationEvent
    UML4SysML::DestructionEvent

    There is no Creation or Destruction Event in the current UML

  • Reported: SysML 1.6 — Thu, 20 Feb 2020 15:10 GMT
  • Updated: Thu, 20 Feb 2020 17:26 GMT

Figure 9.5 missing, duplicates 9.4

  • Status: open  
  • Source: Georgia Institute of Technology ( Mr. Marlin Ballard)
  • Summary:

    In this version of the spec, "Figure 9-5: Item Flow Stereotype" is a duplicate of "Figure 9-4: Provided and Required Features" and does not show the ItemFlow stereotype. The correct figure is present in 1.5 (pp85) and the 1.6beta (pp92) versions of the spec.

  • Reported: SysML 1.6 — Mon, 17 Feb 2020 21:34 GMT
  • Updated: Tue, 18 Feb 2020 15:55 GMT

Remove reference to non-existing properties allocatedFrom and allocatedTo

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section 15.3.1.5 states:
    "For brevity, the «elementType» portion of the allocatedFrom or allocatedTo property may be elided from the diagram."

    The properties "allocatedFrom" and "allocatedTo" do not exist. Change the sentence to:

    "For brevity, the «elementType» portion of the allocatedFrom or allocatedTo section may be elided from the diagram."

  • Reported: SysML 1.6 — Thu, 13 Feb 2020 16:21 GMT
  • Updated: Thu, 13 Feb 2020 16:21 GMT

Remove notation form ActorPart

  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Table 8.3 has a row giving notation for an "Part Property typed by an actor". However since actors cannot have the Block stereotype applied, properties they type cannot be part properties as defined in the SysML specification Clause 8.3.2.4 Block, (p53)). So, this row shall be removed

  • Reported: SysML 1.6 — Thu, 6 Feb 2020 16:59 GMT
  • Updated: Thu, 6 Feb 2020 16:59 GMT

Conjugation Stereotype

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in the Algorithm given in section C.7, they refer to a stereotype named Conjugation (<<conjugates>>) which is also referred to in the resolution information... but that Stereotype does not appear in the standard

  • Reported: SysML 1.6 — Tue, 4 Feb 2020 13:25 GMT
  • Updated: Wed, 5 Feb 2020 20:03 GMT

is the stereotype <<~InterfaceBlock>>

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    is the stereotype on a conjugate block <<~InterfaceBlock>> or <<InterfaceBlock>> not specified in the Standard and very confusing from what information is given in the standard

    I find the whole thing wrong... one should have a stereotype <<InterfaceBlock>> that has the attribute original in it... and remove <<~InterfaceBlock>> ... it works just the same without the confusion... one would need to make original [0..1]... or better yet, one could say that every InterfaceBlock must have an implicitly (possibly created by tool) or explicitly created by the modeler conjugate InterfaceBlock which is in the Model

    one could instead add in the stereotype <<conjugates>> which keeps that information as well... but then there needs to be a constraint in the standard that keeps conjugates and original in sync.. but this would be acceptable to be able to show this in a model

    by the way, there are places in the standard (examples) where it is not original as the attribute

  • Reported: SysML 1.6 — Tue, 4 Feb 2020 13:39 GMT
  • Updated: Wed, 5 Feb 2020 19:51 GMT

Need Bound References Compartment

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in Block1 and Block2, compartments need to be Bound References

  • Reported: SysML 1.6 — Wed, 29 Jan 2020 20:37 GMT
  • Updated: Mon, 3 Feb 2020 16:45 GMT

Parameters and Variables don't make sense

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:
    • diagram was lifted it looks like from UML... the header is UML not SysML needs to be fixed
    • the semantics are unknown, what message can be sent between an in and an inout primitve... would suggest that these are standardized, like set,get messages
    • this shows Parameters and Arguments, but does not show Variables which should be added
  • Reported: SysML 1.6 — Wed, 22 Jan 2020 13:17 GMT
  • Updated: Mon, 27 Jan 2020 10:51 GMT

The definition of AdjunctProperty

  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The definition of AdjunctProperty states that "The AdjunctProperty stereotype can be applied to properties to constrain their values to the values of connectors typed by association blocks, call actions, object nodes, variables, parameters, interaction uses, and submachine states." However, the practical application to a modeler of these different types of adjunct properties is not made explicit in the text.

    For example, adjuncts of behavior parameters allows a block's behavior to be bound to its value properties, or those in its ports, and thus solves a long standing problem in the language prior to SysML 1.4.

    But when it comes to adjunct properties of activity object nodes the practical application is hard to determine and at the same time it breaks encapsulation by making the behavior's internal state visible and may have a significant impact on the efficiency of model simulation and generated code. The same concerns apply to activity variables.

    I am also mystified about the practical application for adjunct properties of interaction uses and sub-machine states (but not a state machine's states). It would be very useful to have a block property that enumerates the current state of an associated state-machine, but as it stands this is not possible by any means that I am aware of (other then by doing it explicitly inside the state-machine's model).

    Discuss.

  • Reported: SysML 1.6 — Wed, 21 Aug 2019 16:30 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

QUDV library inconsistently uses SysML::Libraries::PrimitiveValueTypes

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes.

    I believe that this is a new issue for SysML 1.3.

  • Reported: SysML 1.6b1 — Thu, 13 Jun 2019 14:34 GMT
  • Updated: Mon, 27 Jan 2020 00:16 GMT

AbstractRequirement: direction of /tracedTo wrong in Attributes description

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    This is the wrong way round:

    /tracedTo : NamedElement [0..*]
    Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.(derived)

    However the operation statement is correct:

    getTracedTo () : NamedElement [0..*]
    bodyCondition:Trace.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier
    

    See also attached image in a tool.

    Compare with consistent verifiedBy, satisfiedBy:

    /satisfiedBy : NamedElement [0..*]
    Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier.(derived)

    getSatisfiedBy () : NamedElement [0..*]
    bodyCondition:Satisfy.allInstances()->select(base_Abstraction.supplier=self).base_Abstraction.client
    

    /verifiedBy : NamedElement [0..*]
    Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier.(derived)

    getVerifiedBy () : NamedElement [0..*]
    bodyCondition:Verify.allInstances()->select(base_Abstraction.supplier=self).base_Abstraction.client
    

    It seems it was correct in SysML1.4:

    /tracedTo: NamedElement [*]
    Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client.

    The error may have been introduced during other changes.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 02:37 GMT
  • Updated: Thu, 23 Jan 2020 02:41 GMT
  • Attachments:

Description of getRefines() has typo and inconsistent singular vs plural

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    In the statement of getRefines():

    getRefines (in ref : NamedElement) : AbstractRequirement [0..*]

    The query getRefines() gives all the requirements that are suppliers ("to"end of the concrete syntax) of a «Refine» relationships whose client is the element in parameter. This is a static query.

    There should be a space in:

    "to"end

    So:

    "to" end

    There are mistakes in the use of singular vs plural, the operation description should read:

    The query getRefines() gives all the requirements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the element in parameter. This is a static query.

    If the suggestion SYSML17-276 is adopted the above could be rewritten to state:

    The query getRefines() gives all the named elements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the named element in parameter.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 02:03 GMT
  • Updated: Thu, 23 Jan 2020 02:05 GMT

Description of getRefines() restricts returned elements to AbstractRequirement [0..*] but the OCL static query does not (effectively NamedElement [0..*])

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    The attached image was initially for analysis of SYSML17-57

    In UML2.5.1 the client(s) and supplier(s) of an Abstraction (including Trace stereotype) are always NamedElements.

    There are no additional constraints placed on the type of the client or supplier of the SysML Refines.

    The description of the operation getRefines() restricts the return elements to AbstractRequirement[0..*]

    getRefines (in ref : NamedElement) : AbstractRequirement [0..*]

    The query getRefines() gives all the requirements that are suppliers ("to"end of the concrete syntax) of a «Refine» relationships whose client is the element in parameter. This is a static query.

    (Typos in the above are addressed in a separate issue report.)

    But the OCL static query does not, and effectively returns NamedElement [0..*]

    bodyCondition:
         Refine.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
    

    As examined under SYSML17-15, all of the following are currently valid (see also attached image):

    • Any NamedElement refines a Requirement.
    • A Requirement refines another Requirement.
    • A Requirement refines any NamedElement.
    • Any NamedElement refines another NamedElement.

    Tools correctly implementing the static OCL query permit display (or callout) of getRefined() on any NamedElement.

    It has to be decided whether:

    Option1: The static OCL query should have the return type filtered to only AbstractRequirement (not preferred by this submitter)

    Option2: Loosen the restriction on the description of the return type of getRefined() to the NamedElement[0..*] (preferred by this submitter)

    While Option2 may seem to depart from the initial spirit of the SysML Refines extension within the context of Requirements, it is more consistent with the general UML use of Refines between any (in SysML a pair only) of NamedElements. If this is done, the description also need to be rewritten thus (including typo fixes and fix of plural vs singular):

    The query getRefines() gives all the named elements that are suppliers ("to" end of the concrete syntax) of «Refine» relationships whose clients are the named element in parameter.

    This submitter see no reason why the use of NamedElement[0..*] throughout can't be adopted. Modellers using SysML Refines for Requirement are not impacted, and modellers using Refines for more general purposes would still have access to the useful getRefines().

    The above also implies moving Refines out of the Requirements chapter entirely (into, for example, Model Elements), with a description of the more general use of Refines, but also then describing the typical usage of it for Requirements refinement in the Requirements chapter.

  • Reported: SysML 1.6 — Thu, 23 Jan 2020 01:47 GMT
  • Updated: Thu, 23 Jan 2020 02:05 GMT
  • Attachments:

Parts is too restrictive

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    the standard says
    ""The Sequence diagram describes the flow of control between actors and systems (blocks) or between parts of a system... lifelines into their constituent parts."

    But lifelines can be parts, references, parameters, arguments, variables

    also think one needs to make the distinction between Actors that are parts of the block and Actors that are external to the block because they can be represented as lifelines as well

    also should specify that because an interaction in definition is not tied to a particular block (but the context is derived when executed by a block)... there is no way of telling whether something is a part or a reference at definition time... therefore every head of a lifeline is should as solid and no distinction (like a dotted line for a head) is made in interaction diagrams

  • Reported: SysML 1.6 — Wed, 22 Jan 2020 13:28 GMT
  • Updated: Wed, 22 Jan 2020 13:49 GMT

Missing guard brackets in example activity diagram 11-12

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The guard Brake Pressure > 0 in figure 11-12 on page 148 has no enclosing square brackets.

  • Reported: SysML 1.6 — Tue, 21 Jan 2020 16:44 GMT
  • Updated: Tue, 21 Jan 2020 16:44 GMT

How to interpret non-Navigation

  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    An “X” on a single end of an association to indicate that an end is not navigable has similarly been dropped

    Does this statement mean that SysML has no concept of non-Navigation (only unspecified)... or does it mean that if you
    have an association end A has no Navigation shown, end B has Navigation shown... then End A should be interpreted as
    being non-Navigatable...

    The standard would indicate this as it says "has been similarly dropped" which means it is not shown but it is there all the same...

  • Reported: SysML 1.6b1 — Sat, 9 Nov 2019 15:53 GMT
  • Updated: Mon, 11 Nov 2019 19:57 GMT

No changebars in

  • Status: open  
  • Source: Aerospace Corporation ( Mr. Ryan Noguchi)
  • Summary:

    The version of the specification document that is supposed to have changebars does not appear to have any changebars or redlines. This makes it unnecessarily difficult to find out what has changed since the released 1.5 spec.

  • Reported: SysML 1.6b1 — Tue, 8 Oct 2019 18:16 GMT
  • Updated: Thu, 10 Oct 2019 19:18 GMT

Proposal: patent-friendly part/element numbering system with compliant solid line

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    National patent offices require patent drawings in a very specific format. The “parts” of an invention must typically be numbered consistently, and always indicated with a solid line from each part number to the part.

    I have found many applications can be represented well as SysML Parts Property symbols, and with convenient correct propagation of part numbers across diagrams (Single Source of Truth).

    I have been re-appropriating Comment for this using the following diagramming “hack" in the MagicDraw/Cameo tool:

    • Use the Documentation field of a Part Property to hold each unique part number.
    • Use the Retrieve Documentation feature to display that part number in a Comment symbol (which is stereotyped «Documentation»).
    • The HACK: hide the border of the Comment by making it white against white background, and also hide the stereotype.

    But then you have to use an external image editing tool to tediously make the dashed lines all solid to meet the patent office's requirements.

    Note that UML2.5.1 states:

    'The connection to each annotatedElement is shown by a separate dashed line.’

    A refinement of this proposal might involve creating a special new dedicated SysML element to achieve this, with a dedicated attribute for carrying the numbering.

    It is beyond the scope of this initial proposal to specify how the capability might be achieved.

    The proposal is not limited to numbering and indicating SysML Part Properties typed by Blocks, it could be applied to other Element kinds, but Part Properties lend themselves immediately to the purpose.

    This proposal does not yet elaborate on how the numbering sequence might be handled (largely a tool feature matter).

    The section '7 Model Elements' is a candidate for specification of the new proposed element.

    [Diagrams illustrating the required result will be provided via JIRA once the proposal issue ticket is raised]

    Reference: IP Australia: Best Practice Guide: Appendix: Examples of Drawings: https://www.ipaustralia.gov.au/sites/g/files/net856/f/best_practice_guide_appendix_iv.pdf

  • Reported: SysML 1.6b1 — Mon, 23 Sep 2019 17:35 GMT
  • Updated: Tue, 24 Sep 2019 15:56 GMT

Should <> have a capital V?

  • Status: open  
  • Source: Boeing ( Alan Lee)
  • Summary:

    I'm not sure if this is actually an issue (I think it is). There are 2 keywords in Figure E.10: Spring Length Example; <<valueType>> and <<ValueType>>. Wondering if it is the same keyword and the latter should be lowercase v.

  • Reported: SysML 1.6b1 — Wed, 21 Aug 2019 16:29 GMT
  • Updated: Tue, 3 Sep 2019 18:47 GMT

Duplicate Elements in Table

  • Status: open  
  • Source: Boeing ( Alan Lee)
  • Summary:

    Elements starting from Namespace Compartment to InstanceSpecification (9 items Elements total) is listed twice in the 8.2.1 Block Definition Diagram: Table 8.1.

  • Reported: SysML 1.6b1 — Wed, 21 Aug 2019 16:03 GMT
  • Updated: Tue, 3 Sep 2019 18:46 GMT

Refine / Trace relationship operations are too restrictive

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Refine::getRefines(in ref : NamedElement) : AbstractRequirement should return NamedElement according to the definition of the refine stereotype in section 16.1. The body condition of the operation is not consistent with the return type AbstractRequirement.

    There is no constraint that restricts that one end of the refine relationship must be an element of type AbstractRequirement.

    Trace::getTracedFrom(in ref: NamedElement) : AbstractRequirement should return NamedElement according to the definition of the trace stereotype. The body condition should be updated as well from AbstractRequirement to NamedElement.

    The sentence in section 16.1 "A generic trace requirement relationship provides a general-purpose relationship between a requirement and any
    other model element." is too restrictive with regard to the definition of the trace stereotype.

  • Reported: SysML 1.6b1 — Thu, 8 Aug 2019 16:04 GMT
  • Updated: Thu, 8 Aug 2019 16:04 GMT

VerdictKind should also have the literal none

  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    As defined in the UTP element Verdict, the SysML VerdictKind should also define an enumeration literal none:

    none The test case has not been executed yet.

    When a test case is not executed yet or just invoked, its verdict is none. None indicates that no communication between
    test components and the SUT has been carried out yet. None is the weakest verdict. It is never set by the tester directly.

  • Reported: SysML 1.6b1 — Thu, 8 Aug 2019 07:58 GMT
  • Updated: Thu, 8 Aug 2019 07:59 GMT

ProxyPort property "matching"

  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    [From email to sysml-rtf@omg.org 7-May-2019, and discussed at the SysML RTF meeting 9-May-2019.]

    The situation of a proxy port's InterfaceBlock having multiple flow properties, and may be also multiple value properties, leads to the vexing question of how they all get paired up with [the] port's owning blocks' features. Putting aside behaviour ports (isBehavior=true), the most straightforward solution would be to use a binding connector between each feature in the proxy port and the actual features in the owning block. However, I find the public draft of SysML 1.6 to still not be completely clear on this matter, despite its improvements to the chapter on ports and flows.

    The section on FlowPorperty (9.3.2.8) refers to property matching (2nd paragraph), but does not contextualise when property matching might occur. Most of what it states makes perfect sense in the context of connected proxy ports, especially when the ports have the same type (i.e. an InterfaceBlock) and one port is conjugated. However, it becomes remarkably unclear what it means when matching is applied to the proxy port and its owning block's flow properties.

    The section on Proxy Ports (9.3.2.13), replaces the later part of the first paragraph with a subsequent paragraph to spell out how a proxy port relates to its owning block, but seems to do this in a weak way by stating "This can be achieved in several ways. For instance by...", which sounds informative, rather than normative. Nevertheless it does state "by binding it to a fully specified internal part or by having all its properties individually bound to internal parts."

    If a proxy port is bound to an internal part, is there a need for the port's type to match that of the bound part? If not, what are the rules for feature matching?

    If a proxy port's "properties [are] individually bound to internal parts", then dose the meaning of "part" extend to the block's value properties and flow properties? (I wouldn't ordinarily consider them to be parts.) If not then where does it state that these properties can be bound?

  • Reported: SysML 1.6 — Thu, 9 May 2019 14:13 GMT
  • Updated: Thu, 9 May 2019 14:13 GMT

cannot model and validate physical connections

  • Status: open  
  • Source: US Navy - Naval Information Warfare Center - Atlantic ( Stuart Pearce)
  • Summary:

    I’d like to model the physical connection from a device to another device. It appears SysML 1.4 does not allow this natively or easily. I’ve discussed this issue with Russell Peak, Georgia Tech and he agrees that it is a short coming of SysML.

    For example:
    I have a computer with a power cord that I would like to model to verify the correct connectors are on it. The wall receptacle is typically a 5-15R for North America, the matching power cord connection is a 5-15P. The computer typically has a C13R power receptacle and the power cord plug would be a C13P. I can add ports to my block in an ibd for the receptacle and plug ends, but I cannot validate that a good connection is 5-15R=5-15P for the wall end or C13R=C13P for the computer end.
    This will apply for all types of physical connections, copper data, fiber data, pipe, tube, etc.

    If there is a working group for this area I will be glad to work with them.

  • Reported: SysML 1.4 — Mon, 22 Apr 2019 10:40 GMT
  • Updated: Wed, 24 Apr 2019 15:50 GMT