1. OMG Mailing List
  2. OMG SysML 1.5 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: sysml-rtf
  • Issues Count: 470

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML17-145 Shared parts are still parts SysML 1.4 open
SYSML17-220 Bad reference in section 4.2 SysML 1.6 open
SYSML17-218 Stakeholder constraint is listed twice SysML 1.6 open
SYSML17-181 VerdictKind enumeration missing SysML 1.6 open
SYSML17-84 VerdictKind SysML 1.4 open
SYSML17-68 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 open
SYSML17-52 SysML primitive value types SysML 1.4 open
SYSML17-97 primitive types in SysML Activities SysML 1.4 open
SYSML17-172 ConnectorProperty is redundant SysML 1.5 open
SYSML17-32 Support BDD's for State Machines SysML 1.4 open
SYSML17-174 Connectors are not allowed in bdd SysML 1.5 open
SYSML17-19 Annex B / Figure B.10 SysML 1.0 open
SYSML17-20 Annex B / Figure B.9 SysML 1.0 open
SYSML17-214 Hidden constraints in description of PropertySpecificType SysML 1.6 open
SYSML17-66 InstanceSpecifications for exactly one instance SysML 1.3 open
SYSML17-160 DirectedFeature is confusing SysML 1.5 open
SYSML17-67 InstanceSpecification equality SysML 1.3 open
SYSML17-78 How to refer to properties of an extension? SysML 1.4 open
SYSML17-82 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 open
SYSML17-86 Inability to specify partial allocation and requriements satisfaction SysML 1.3 open
SYSML17-103 SysML Issues on Item Property values in an IBD SysML 1.4 open
SYSML17-117 ElementGroup cannot be source or target of a dependency SysML 1.4 open
SYSML17-125 A discarded resolution still appears in the ballot SysML 1.4 open
SYSML17-134 AllocateActivityPartition should be more formaly related to allocation Relationship SysML 1.4 open
SYSML17-140 Causality of constraints in parametric diagrams SysML 1.4 open
SYSML17-142 Requirement ID should be immutable SysML 1.4 open
SYSML17-143 Expand use of rake symbol for all decompositions SysML 1.4 open
SYSML17-144 Specify a specific part from a collection of parts on an IBD SysML 1.4 open
SYSML17-146 Numeric Literals as constraint block property parameter values SysML 1.4 open
SYSML17-28 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 open
SYSML17-31 Binding Relationships require unit conversions SysML 1.4 open
SYSML17-71 Property Based Requirements SysML 1.3 open
SYSML17-98 ProxyPort with FlowProperties SysML 1.4 open
SYSML17-108 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 open
SYSML17-109 Convention for enumeration not used for ControlValue SysML 1.3 open
SYSML17-119 More than one View() operation allowed SysML 1.4 open
SYSML17-120 Inherit from a conjugated interface block SysML 1.4 open
SYSML17-121 Missing property descriptions for Probability and Rate SysML 1.4 open
SYSML17-122 Property path notation SysML 1.4 open
SYSML17-130 Description of model elements in generated document not consistent with specification SysML 1.4 open
SYSML17-138 Hanging Clauses Throughout SysML 1.4 SysML 1.4 open
SYSML17-150 Owned properties of an InterfaceBlock SysML 1.5 open
SYSML17-154 Clarification of typing a binding connector SysML 1.5 open
SYSML17-158 Statements missing in the abstract syntax description SysML 1.5 open
SYSML17-165 Typo in revised text of issue SYSML16-289 SysML 1.5 open
SYSML17-185 Sample problem diagrams are inconsistent, need to refactor from integrated model SysML 1.5 open
SYSML17-184 Inappropriate character for multiplying symbol with combined units SysML 1.5 open
SYSML17-176 SysML::Trace relationship is not specialized from UML::Trace in the XMI SysML 1.5 open
SYSML17-177 SysML::Refine relationship is not specialized from UML::Refine in the XMI SysML 1.5 open
SYSML17-182 Verdict described incorrecty SysML 1.6 open
SYSML17-175 Do not move deprecated elements SysML 1.5 open
SYSML17-173 Combined call-out notation not allowed SysML 1.5 open
SYSML17-170 DistributedProperty should be abstract SysML 1.5 open
SYSML17-168 DistributedProperty should be abstract SysML 1.5 open
SYSML17-169 Diagram header is not intuitively interpreted SysML 1.5 open
SYSML17-167 Description of AdjunctProperty SysML 1.5 open
SYSML17-163 Excluded UML metaclasses are not formally defined SysML 1.5 open
SYSML17-162 Add signal to constraint [1] for DistributedProperty SysML 1.5 open
SYSML17-161 Add Graphical notation for General Classifier SysML 1.5 open
SYSML17-94 Diagram show inconsistent data SysML 1.3 open
SYSML17-159 Reference Properties do not reference properties SysML 1.5 open
SYSML17-157 Typos/editorials found in the SysML 1.5 specification document SysML 1.5 open
SYSML17-156 Replace UML4SysML::Kernel by UML4SysML::Generalization SysML 1.5 open
SYSML17-153 Replace all occurrences of "has been" by "is" SysML 1.5 open
SYSML17-152 Parameter direction typo in XMI SysML 1.5 open
SYSML17-151 The AdjunctProperty is not clearly described SysML 1.4 open
SYSML17-148 Owning Block definition is unclear SysML 1.5 open
SYSML17-147 Diagram formality confusion SysML 1.4 open
SYSML17-141 "Allocated From" should be "Allocated" SysML 1.4 open
SYSML17-139 Derived attribute should also be read only SysML 1.4 open
SYSML17-137 Missing comment for some attributes SysML 1.4 open
SYSML17-136 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 open
SYSML17-135 No support for dot notation in activity and sequence diagrams SysML 1.4 open
SYSML17-133 Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do. SysML 1.4 open
SYSML17-132 ConnectorProperty notation in wrong section. SysML 1.4 open
SYSML17-131 Parts, references, values compartments in wrong section SysML 1.4 open
SYSML17-129 Definition of SysML stereotypes: association ends versus attributes SysML 1.4 open
SYSML17-128 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 open
SYSML17-127 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 open
SYSML17-126 specializations of requirement should specialize AbstractRequirement SysML 1.4 open
SYSML17-124 ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values SysML 1.4 open
SYSML17-123 Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? SysML 1.4 open
SYSML17-118 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 open
SYSML17-116 [SysML] Semantic variation points SysML 1.4 open
SYSML17-114 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 open
SYSML17-112 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 open
SYSML17-110 Update to Trace Relationship’ SysML 1.4 open
SYSML17-106 Semantics clarification for removing a value from an out Flow Property SysML 1.4 open
SYSML17-101 About Rate, Continuous and Discrete SysML 1.4 open
SYSML17-100 The SysML classification of properties is incomplete SysML 1.4 open
SYSML17-96 Semantics of multiple Dependencies SysML 1.4 open
SYSML17-12 Sample problem: Parts are added directly into package SysML 1.4 open
SYSML17-18 Annex B / B.4.8.3 Activity Diagram (in sample problem) SysML 1.0 open
SYSML17-21 Annex B / Figure B27 SysML 1.0 open
SYSML17-22 Annex B / Figure B.35 SysML 1.0 open
SYSML17-23 Annex B / Figure B.38 SysML 1.0 open
SYSML17-24 Annex B, Figure B.29 SysML 1.0 open
SYSML17-25 Figure B.34 and Figure B.35 SysML 1.0 open
SYSML17-60 Where have stereotypes been defined? SysML 1.4 open
SYSML17-61 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 open
SYSML17-63 TestCase should use PackageMerge SysML 1.2 open
SYSML17-93 Don't use the optional notation for Pins with Allocation SysML 1.3 open
SYSML17-95 Clarification required for Copy relationship SysML 1.3 open
SYSML17-91 Allocated notation on object nodes missing from diagram elements table SysML 1.3 open
SYSML17-90 Allocation tabular notation normative? SysML 1.3 open
SYSML17-89 Figures 15.5 and 15.6 diagram types SysML 1.3 open
SYSML17-88 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 open
SYSML17-80 Missing ownership constraints SysML 1.3 open
SYSML17-87 9.3.2.4 direction of ports SysML 1.4 open
SYSML17-85 Figure 15.8 diagram type SysML 1.3 open
SYSML17-83 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 open
SYSML17-81 Missing type constraints for FullPort SysML 1.3 open
SYSML17-79 Interface blocks and protocols SysML 1.4 open
SYSML17-178 Virtual member representing the whole RTF SysML 1.6 open
SYSML17-77 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 open
SYSML17-76 SysML: References to CreateEvent incorrect SysML 1.4 open
SYSML17-75 Callout notation for port-specific types and initial values SysML 1.3 open
SYSML17-73 9.3.2.9 What is InterfaceBlock? SysML 1.4 open
SYSML17-72 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 open
SYSML17-70 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 open
SYSML17-29 Requirements interchange issue SysML 1.4 open
SYSML16-175 Dubious UUIDs SysML 1.4 open
SYSML16-350 Do not move deprecated elements SysML 1.5 open
SYSML16-483 ConnectorProperty is redundant SysML 1.5 open
SYSML16-482 DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution SysML 1.5 open
SYSML16-481 DistributedProperty should be abstract SysML 1.5 open
SYSML17-171 DistributedProperty shall have an operation that checks whether a value is conform to the constraints of the distribution SysML 1.5 open
SYSML16-465 DistributedProperty should be abstract SysML 1.5 open
SYSML16-464 Description of AdjunctProperty SysML 1.5 open
SYSML16-478 Diagram header is not intuitively interpreted SysML 1.5 open
SYSML17-166 Inconsistency between xmi and pdf for Trace and Refine specializations SysML 1.4 open
SYSML17-164 SysML 1.6 should be based on UML 2.5.1 SysML 1.5 open
SYSML16-404 Add signal to constraint [1] for DistributedProperty SysML 1.5 open
SYSML16-458 Inconsistency between xmi and pdf for Trace and Refine specializations SysML 1.4 open
SYSML16-373 Add Graphical notation for General Classifier SysML 1.5 open
SYSML16-421 Typo in revised text of issue SYSML16-289 SysML 1.5 open
SYSML16-417 SysML 1.6 should be based on UML 2.5.1 SysML 1.5 open
SYSML16-409 Excluded UML metaclasses are not formally defined SysML 1.5 open
SYSML16-371 Reference Properties do not reference properties SysML 1.5 open
SYSML16-372 DirectedFeature is confusing SysML 1.5 open
SYSML16-364 Statements missing in the abstract syntax description SysML 1.5 open
SYSML17-155 Inconsistency in the DirectedRelationshipPropertyPath specification SysML 1.5 open
SYSML16-344 Typos/editorials found in the SysML 1.5 specification document SysML 1.5 open
SYSML16-333 Replace UML4SysML::Kernel by UML4SysML::Generalization SysML 1.5 open
SYSML16-328 Inconsistency in the DirectedRelationshipPropertyPath specification SysML 1.5 open
SYSML16-319 Clarification of typing a binding connector SysML 1.5 open
SYSML16-298 Replace all occurrences of "has been" by "is" SysML 1.5 open
SYSML16-294 Parameter direction typo in XMI SysML 1.5 open
SYSML17-149 FullPort type SysML 1.5 open
SYSML16-288 The AdjunctProperty is not clearly described SysML 1.4 open
SYSML16-264 Owned properties of an InterfaceBlock SysML 1.5 open
SYSML16-263 FullPort type SysML 1.5 open
SYSML16-253 Owning Block definition is unclear SysML 1.5 open
SYSML16-231 Diagram formality confusion SysML 1.4 open
SYSML16-230 Numeric Literals as constraint block property parameter values SysML 1.4 open
SYSML16-228 Shared parts are still parts SysML 1.4 open
SYSML16-189 Derived attribute should also be read only SysML 1.4 open
SYSML16-194 Causality of constraints in parametric diagrams SysML 1.4 open
SYSML16-197 "Allocated From" should be "Allocated" SysML 1.4 open
SYSML16-206 Expand use of rake symbol for all decompositions SysML 1.4 open
SYSML16-204 Requirement ID should be immutable SysML 1.4 open
SYSML16-227 Specify a specific part from a collection of parts on an IBD SysML 1.4 open
SYSML16-169 AllocateActivityPartition should be more formaly related to allocation Relationship SysML 1.4 open
SYSML16-179 Hanging Clauses Throughout SysML 1.4 SysML 1.4 open
SYSML16-176 Missing comment for some attributes SysML 1.4 open
SYSML16-172 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 open
SYSML16-170 No support for dot notation in activity and sequence diagrams SysML 1.4 open
SYSML16-167 Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do. SysML 1.4 open
SYSML16-161 Definition of SysML stereotypes: association ends versus attributes SysML 1.4 open
SYSML16-162 Description of model elements in generated document not consistent with specification SysML 1.4 open
SYSML16-163 Parts, references, values compartments in wrong section SysML 1.4 open
SYSML16-164 ConnectorProperty notation in wrong section. SysML 1.4 open
SYSML16-153 Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? SysML 1.4 open
SYSML16-152 Property path notation SysML 1.4 open
SYSML16-150 Missing property descriptions for Probability and Rate SysML 1.4 open
SYSML16-156 A discarded resolution still appears in the ballot SysML 1.4 open
SYSML16-155 ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values SysML 1.4 open
SYSML16-159 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 open
SYSML16-158 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 open
SYSML16-157 specializations of requirement should specialize AbstractRequirement SysML 1.4 open
SYSML17-115 Can a SysML Full Port be typed by a ValueType? SysML 1.4 open
SYSML16-148 Inherit from a conjugated interface block SysML 1.4 open
SYSML16-147 More than one View() operation allowed SysML 1.4 open
SYSML16-146 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 open
SYSML16-145 ElementGroup cannot be source or target of a dependency SysML 1.4 open
SYSML16-144 [SysML] Semantic variation points SysML 1.4 open
SYSML16-143 Can a SysML Full Port be typed by a ValueType? SysML 1.4 open
SYSML16-142 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 open
SYSML17-113 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 open
SYSML17-111 Abstract syntax for the initial values SysML 1.4 open
SYSML17-107 proxy and full port notation change request SysML 1.4 open
SYSML16-141 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 open
SYSML16-140 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 open
SYSML16-139 Abstract syntax for the initial values SysML 1.4 open
SYSML16-138 Update to Trace Relationship’ SysML 1.4 open
SYSML16-137 Convention for enumeration not used for ControlValue SysML 1.3 open
SYSML16-135 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 open
SYSML16-134 proxy and full port notation change request SysML 1.4 open
SYSML17-104 Pull semantics for flow properties SysML 1.4 open
SYSML17-105 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 open
SYSML16-133 Semantics clarification for removing a value from an out Flow Property SysML 1.4 open
SYSML16-129 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 open
SYSML16-128 Pull semantics for flow properties SysML 1.4 open
SYSML16-127 SysML Issues on Item Property values in an IBD SysML 1.4 open
SYSML17-102 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 open
SYSML17-99 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 open
SYSML16-126 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 open
SYSML16-124 About Rate, Continuous and Discrete SysML 1.4 open
SYSML16-123 The SysML classification of properties is incomplete SysML 1.4 open
SYSML16-121 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 open
SYSML16-120 ProxyPort with FlowProperties SysML 1.4 open
SYSML17-92 Libraries package should be named "SysML Model Libraries" SysML 1.3 open
SYSML16-119 primitive types in SysML Activities SysML 1.4 open
SYSML16-118 Semantics of multiple Dependencies SysML 1.4 open
SYSML16-117 Clarification required for Copy relationship SysML 1.3 open
SYSML16-116 Diagram show inconsistent data SysML 1.3 open
SYSML16-115 Don't use the optional notation for Pins with Allocation SysML 1.3 open
SYSML16-114 Libraries package should be named "SysML Model Libraries" SysML 1.3 open
SYSML16-113 Allocated notation on object nodes missing from diagram elements table SysML 1.3 open
SYSML16-112 Allocation tabular notation normative? SysML 1.3 open
SYSML16-111 Figures 15.5 and 15.6 diagram types SysML 1.3 open
SYSML16-109 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 open
SYSML16-108 9.3.2.4 direction of ports SysML 1.4 open
SYSML16-107 Inability to specify partial allocation and requriements satisfaction SysML 1.3 open
SYSML16-105 Figure 15.8 diagram type SysML 1.3 open
SYSML16-103 VerdictKind SysML 1.4 open
SYSML16-102 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 open
SYSML16-101 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 open
SYSML16-99 Missing type constraints for FullPort SysML 1.3 open
SYSML16-98 Missing ownership constraints SysML 1.3 open
SYSML17-74 clarification, what "part property" is SysML 1.4 open
SYSML16-97 Interface blocks and protocols SysML 1.4 open
SYSML16-96 How to refer to properties of an extension? SysML 1.4 open
SYSML16-95 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 open
SYSML16-93 SysML: References to CreateEvent incorrect SysML 1.4 open
SYSML16-91 Callout notation for port-specific types and initial values SysML 1.3 open
SYSML16-89 clarification, what "part property" is SysML 1.4 open
SYSML17-69 Question about the Activity decomposition in Block Definition Diagrams SysML 1.4 open
SYSML16-88 9.3.2.9 What is InterfaceBlock? SysML 1.4 open
SYSML16-85 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 open
SYSML16-84 Property Based Requirements SysML 1.3 open
SYSML16-83 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 open
SYSML16-82 Question about the Activity decomposition in Block Definition Diagrams SysML 1.4 open
SYSML16-81 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 open
SYSML16-78 InstanceSpecification equality SysML 1.3 open
SYSML17-65 Content of Requirement::/tracedTo SysML 1.4 open
SYSML17-64 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 open
SYSML16-77 InstanceSpecifications for exactly one instance SysML 1.3 open
SYSML16-75 Content of Requirement::/tracedTo SysML 1.4 open
SYSML16-74 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 open
SYSML17-62 Association owning ends SysML 1.2 open
SYSML17-59 Definition of part SysML 1.2 open
SYSML17-58 Item flows can have multiple types but item properties cannot SysML 1.2 open
SYSML16-73 TestCase should use PackageMerge SysML 1.2 open
SYSML16-72 Association owning ends SysML 1.2 open
SYSML16-71 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 open
SYSML16-70 Where have stereotypes been defined? SysML 1.4 open
SYSML16-68 Definition of part SysML 1.2 open
SYSML16-66 Item flows can have multiple types but item properties cannot SysML 1.2 open
SYSML17-57 SysML Issue on Refine limitations SysML 1.4 open
SYSML17-56 Description of Item Flows SysML 1.2 open
SYSML17-55 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 open
SYSML17-54 Blocks cannot own items flows SysML 1.2 open
SYSML16-65 SysML Issue on Refine limitations SysML 1.4 open
SYSML16-64 Description of Item Flows SysML 1.2 open
SYSML16-63 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 open
SYSML16-62 Blocks cannot own items flows SysML 1.2 open
SYSML17-53 Another issue with allocate SysML 1.4 open
SYSML17-51 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 open
SYSML17-50 SysML Issue representation of properties as associations SysML 1.4 open
SYSML17-49 SysML Issue based on UML 15369 SysML 1.4 open
SYSML16-61 Another issue with allocate SysML 1.4 open
SYSML16-60 SysML primitive value types SysML 1.4 open
SYSML16-59 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 open
SYSML16-58 SysML Issue representation of properties as associations SysML 1.4 open
SYSML16-57 SysML Issue based on UML 15369 SysML 1.4 open
SYSML17-48 Figure B.35 object nodes SysML 1.4 open
SYSML17-47 SysML 1.2 Issues: Optional with streaming SysML 1.4 open
SYSML17-46 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 open
SYSML17-45 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 open
SYSML17-44 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 open
SYSML17-43 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 open
SYSML17-42 Flow properties and activity paramters SysML 1.4 open
SYSML16-56 Figure B.35 object nodes SysML 1.4 open
SYSML16-55 SysML 1.2 Issues: Optional with streaming SysML 1.4 open
SYSML16-54 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 open
SYSML16-53 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 open
SYSML16-52 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 open
SYSML16-51 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 open
SYSML16-50 Flow properties and activity paramters SysML 1.4 open
SYSML17-41 Inheriting Allocations SysML 1.4 open
SYSML17-40 Ability for a binding connector to be typed SysML 1.1 open
SYSML17-39 Do parametric bindings observe derived and read-only properties SysML 1.4 open
SYSML17-38 Binding to multiplicity in parametrics SysML 1.1 open
SYSML17-37 callout notation issues SysML 1.4 open
SYSML17-36 Proposal to have a stereotype for reference nested property SysML 1.1 open
SYSML17-35 Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect SysML 1.1 open
SYSML16-49 Inheriting Allocations SysML 1.4 open
SYSML16-48 Ability for a binding connector to be typed SysML 1.1 open
SYSML16-47 Do parametric bindings observe derived and read-only properties SysML 1.4 open
SYSML16-46 Binding to multiplicity in parametrics SysML 1.1 open
SYSML16-45 callout notation issues SysML 1.4 open
SYSML16-42 Proposal to have a stereotype for reference nested property SysML 1.1 open
SYSML16-41 Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect SysML 1.1 open
SYSML17-34 Allocations should not generate dependencies SysML 1.1 open
SYSML17-33 AllocateActivityPartition and UML 2 semantics SysML 1.1 open
SYSML17-30 Representation of nested object nodes in activity diagrams SysML 1.1 open
SYSML16-39 Allocations should not generate dependencies SysML 1.1 open
SYSML16-37 AllocateActivityPartition and UML 2 semantics SysML 1.1 open
SYSML16-36 Support BDD's for State Machines SysML 1.4 open
SYSML16-35 Binding Relationships require unit conversions SysML 1.4 open
SYSML16-32 Representation of nested object nodes in activity diagrams SysML 1.1 open
SYSML16-31 Requirements interchange issue SysML 1.4 open
SYSML17-27 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 open
SYSML17-26 SysML: Align SysML Activities with Foundational UML SysML 1.4 open
SYSML16-30 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 open
SYSML16-29 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 open
SYSML16-28 SysML: Align SysML Activities with Foundational UML SysML 1.4 open
SYSML16-27 Figure B.34 and Figure B.35 SysML 1.0 open
SYSML16-25 Annex B, Figure B.29 SysML 1.0 open
SYSML16-24 Annex B / Figure B.38 SysML 1.0 open
SYSML16-23 Annex B / Figure B.35 SysML 1.0 open
SYSML16-22 Annex B / Figure B27 SysML 1.0 open
SYSML16-21 Annex B / Figure B.9 SysML 1.0 open
SYSML16-20 Annex B / Figure B.10 SysML 1.0 open
SYSML16-19 Annex B / B.4.8.3 Activity Diagram (in sample problem) SysML 1.0 open
SYSML17-17 10.3.1.2 Parametric Diagram: square box notation SysML 1.0 open
SYSML17-16 Item Flows on Activity Diagrams SysML 1.4 open
SYSML17-15 Inferred Allocation on Allocate Activity Partitions SysML 1.4 open
SYSML17-14 Diagram interchange SysML 1.0 open
SYSML17-13 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 open
SYSML16-18 10.3.1.2 Parametric Diagram: square box notation SysML 1.0 open
SYSML16-17 Item Flows on Activity Diagrams SysML 1.4 open
SYSML16-16 Inferred Allocation on Allocate Activity Partitions SysML 1.4 open
SYSML16-15 Diagram interchange SysML 1.0 open
SYSML16-14 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 open
SYSML17-11 It is not allowed in UML to display stereotypes of related elements SysML 1.4 open
SYSML17-10 Lack of notation for units and dimensions on values. SysML 1.4 open
SYSML17-9 BindingConnector end s multiplicity SysML 1.4 open
SYSML17-8 Issue: Nested connector ends SysML 1.4 open
SYSML17-7 standard way to describe a flow of data in sequence diagrams SysML 1.0 open
SYSML16-13 Sample problem: Parts are added directly into package SysML 1.4 open
SYSML16-12 It is not allowed in UML to display stereotypes of related elements SysML 1.4 open
SYSML16-11 Lack of notation for units and dimensions on values. SysML 1.4 open
SYSML16-10 BindingConnector end s multiplicity SysML 1.4 open
SYSML16-9 Issue: Nested connector ends SysML 1.4 open
SYSML16-8 standard way to describe a flow of data in sequence diagrams SysML 1.0 open
SYSML17-6 Block namespace compartment: Are external relationships allowed SysML 1.4 open
SYSML17-5 Timing diagrams SysML 1.0 open
SYSML17-4 the use of <> is still unclear and inconsistent SysML 1.0 open
SYSML17-3 SysML: Generalizing Activites SysML 1.4 open
SYSML17-2 SysML: UML Qualified Associations SysML 1.4 open
SYSML17-1 SysML: Protocol State Machines needed SysML 1.4 open
SYSML16-7 Block namespace compartment: Are external relationships allowed SysML 1.4 open
SYSML16-6 Timing diagrams SysML 1.0 open
SYSML16-5 the use of <> is still unclear and inconsistent SysML 1.0 open
SYSML16-3 SysML: Generalizing Activites SysML 1.4 open
SYSML16-2 SysML: UML Qualified Associations SysML 1.4 open
SYSML16-1 SysML: Protocol State Machines needed SysML 1.4 open
SYSML16-193 Constraint clarification SysML 1.4 open
SYSML16-195 Missing one right parenthesis in the constraint equation SysML 1.4 open
SYSML16-187 ParticipantProperty stereotype is redundant SysML 1.4 open
SYSML16-184 ISO DIS 19514 (JTC1 Comments against SysML 1.4) SysML 1.4 open
SYSML16-122 SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are SysML 1.4 open
SYSML16-110 Ports and Flows SysML 1.3 open
SYSML16-94 Problems with 1.3 Enumeration Literals SysML 1.4 open
SYSML16-43 Flow port compatibility with behavior SysML 1.1 open
SYSML16-4 Section: 9.3.2.5 FlowPort SysML 1.0 open
SYSML16-199 BNF definitions have literals/terminals in italics, which seems to imply that the occurrences of these strings should be in italics, but they are not. SysML 1.4 open
SYSML16-196 layout error for compartment name SysML 1.4 open
SYSML16-168 DeriveReqt constraints multiplicity of Client and Supplier SysML 1.4 open
SYSML16-178 The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes SysML 1.4 open
SYSML16-174 Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 SysML 1.4 open
SYSML16-166 RequirementRelated is present in the summary but no more in the document SysML 1.4 open
SYSML16-87 Port labels inside Port symbol SysML 1.4 open
SYSML16-86 Section 9.3.1.7 SysML 1.4 open
SYSML16-205 SysML Provides Inadequate Support for Reuse of Requirements SysML 1.4 open
SYSML16-192 SysML does not clearly defines how an association defines properties SysML 1.4 open
SYSML16-202 Activity should not be included as graphical node included in activity diagrams SysML 1.4 open
SYSML16-171 xmi:IDs are not convenient SysML 1.4 open
SYSML16-180 AdjunctProperty principal should be a NamedElement SysML 1.4 open
SYSML16-211 Block constraint [4] contains a false statement SysML 1.5 open
SYSML16-177 Incorrect multiplicity for base_xxx properties of most SysML Stereotypes SysML 1.4 open
SYSML16-173 Wrong parameter for Operations in the SysML.xmi SysML 1.4 open
SYSML16-281 Clarify if the usage of qualified associations is allowed SysML 1.5b1 open
SYSML16-280 Association arrowheads should not be forbidden SysML 1.5b1 open
SYSML16-186 The type of ParticipantProperty SysML 1.4 open
SYSML16-188 ParticipantProperty keyword SysML 1.4 open
SYSML16-201 Behavior Diagram Element tables imply diagrams can be nodes SysML 1.4 open
SYSML16-165 Initial values compartment header inconsistent with others SysML 1.4 open
SYSML16-69 Incorrect statement about UML n-aries SysML 1.2 open
SYSML16-67 Compartment labelling rules SysML 1.4 open
SYSML16-44 Need to have an explicit way to bind flow properties or atomic flow ports to block properties SysML 1.1 open
SYSML16-182 NestedConnectorEnd violates UML "roles" constraint SysML 1.4 open
SYSML16-203 Update description about extension of UML SysML 1.4 open
SYSML16-183 SysML specification document cleanups SysML 1.4 open
SYSML16-295 Remove [sic] in block constraints SysML 1.5 open
SYSML16-345 SysML stereotype constraints should be named rather than numbered SysML 1.5 open
SYSML16-337 Compartment headers are missing in figure 8.10 and 8.11 SysML 1.5 open
SYSML16-334 Incorrect diagram header in figure 8.11 SysML 1.5 open
SYSML16-332 EndPathMultiplicity constraint#2 uses a wrong name to refer to a stereotype property SysML 1.5 open
SYSML16-331 UnitAndQuantityKind figure missing block keyword SysML 1.5 open
SYSML16-323 AdjunctProperty constraint#8 can be simplified SysML 1.5 open
SYSML16-310 SysML::Block constraint#3 containts an incorrect assertion about UML SysML 1.5 open
SYSML16-303 References to UML specification in block constraints are not correct SysML 1.5 open
SYSML16-300 Remove sentences about qualified associations in clause 8.3.1.3 SysML 1.5 open
SYSML16-299 Remove the statement about N-ary associations from 8.3.1.3 SysML 1.5 open
SYSML16-181 Binding Connector should not be typed SysML 1.4 open
SYSML16-321 View constraint#3 is incorrect SysML 1.5 open
SYSML16-130 Flow property description: incorrect wording (§9.3.2.7) SysML 1.4 open
SYSML16-125 Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors SysML 1.4 open
SYSML16-104 View and Viewpoint Limitations in support of auto-view generation SysML 1.3 open
SYSML16-90 Is <> keyword (or stereotype) on binding connectors is part of SysML notation? SysML 1.4 open
SYSML16-26 Section: Generalization of stereotyped elements SysML 1.0 open
SYSML16-229 Constant Block Value Properties SysML 1.4 open
SYSML16-395 Binding connectors in internal block diagrams must always show the keyword SysML 1.5 open
SYSML16-387 Equal sign for binding connector SysML 1.5 open
SYSML16-79 Lightweight representations of faults, failures, hazards and off-nominal conditions and behavior SysML 1.2 open
SYSML16-40 Parsing Text in Requirements SysML 1.1 open
SYSML16-38 Inability to represent dependent, independent parameters on constraint properties SysML 1.1 open
SYSML16-34 Requirement constants should be integrated into Model-centric vision of SysmL SysML 1.4 open
SYSML16-33 Section: 8/8.3.2 Inability to efficiently capture datasets SysML 1.1 open
SYSML16-275 Typo in xmi file for orderedMember SysML 1.4 open
SYSML16-314 The association-like notation is ambiguous SysML 1.5 open
SYSML16-399 Nested diagrams in SysML SysML 1.5 open
SYSML16-393 Binding connectors have no keyword syntax in parametric diagrams SysML 1.5 open
SYSML16-382 Allow a Requirement to be contained on Any Diagram SysML 1.5 open
SYSML16-151 Provide support to capture engineering quantities and support intricate calculations SysML 1.4 open
SYSML16-160 Cannot navigate and represent deep nested defining feature in a slot SysML 1.4 open
SYSML16-149 <> should be a reference (dashed box) SysML 1.4 open
SYSML16-136 Update SysML references to UML model library StandardProfileL2 SysML 1.3 open
SYSML16-92 remove figure numbers from diagram frames SysML 1.3 open
SYSML16-154 Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous SysML 1.4 open
SYSML16-342 The statement of InvocationOnNestedPortAction constraint#3 is not appropriate SysML 1.5 open
SYSML16-341 Constraint#2 of the InvocationOnNestedPortAction stereotype is invalid SysML 1.5 open
SYSML16-329 Constraints redundancy in DirectedRelationshipPropertyPath SysML 1.5 open
SYSML16-326 BoundReference constraint#3 is unclear SysML 1.5 open
SYSML16-325 Typo in AdjunctProperty Constraint#10 SysML 1.5 open
SYSML16-106 Constraint [5] should include specializations of Requirement SysML 1.3 open
SYSML16-80 Issue on Block constraint#4 SysML 1.4 open
SYSML16-76 Problems with property-specific types SysML 1.3 open
SYSML16-357 Allocate constraint#1 could be replaced by a redefinition SysML 1.5 open
SYSML16-356 Rate constraint#2 is ambiguous SysML 1.5 open
SYSML16-355 Probability constraint#1 is ambiguous SysML 1.5 open
SYSML16-354 The OCL statement of ConstraintBlock constraint#3 is wrong SysML 1.5 open
SYSML16-353 The constraint#6 of TriggerOnNestedPort could be replaced by a redefinition SysML 1.5 open
SYSML16-352 The statement of TriggerOnNestedPort constraint#5 is wrong SysML 1.5 open
SYSML16-351 The statement of TriggerOnNestedPort constraint#4 is not appropriate SysML 1.5 open
SYSML16-348 ItemFlow constraint#1 implicilty contrains ItemFlow to rely on a binary relation SysML 1.5 open
SYSML16-343 Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition SysML 1.5 open
SYSML16-366 Constraints for Refine and Trace can be improved SysML 1.5 open
SYSML16-365 Copy constraints #2 and #3 shoud be merged together SysML 1.5 open
SYSML16-397 Diagram guidelines uses excluded UML element SysML 1.5 open
SYSML16-389 Change keyword of binding connector from "equal" to "=" SysML 1.5 open
SYSML16-185 Instance for Initial values SysML 1.4 open
SYSML16-198 Most diagram headers in document are not consistent with Appendix A, p 189. SysML 1.4 open
SYSML16-131 Proxy port “complete” specification (§ 9.3.2.12): SysML 1.4 open
SYSML16-100 Incorrect constraint [2] on InterfaceBlock SysML 1.3 open
SYSML16-254 Clarify port usage patterns SysML 1.5 open
SYSML16-468 The constraint#3 of NestedConnectorEnd could be replaced by a redefinition SysML 1.5 open
SYSML16-462 Setting flow properties on blocks with multiple behavioral ports SysML 1.5 open
SYSML16-455 Composite properties allowed for InterfaceBlocks SysML 1.5 open
SYSML16-367 Constraints on Satisfy and Verify should refer to AbstractRequirement SysML 1.5 open
SYSML16-191 Keyword signal in reception compartment is superfluous SysML 1.4 open
SYSML16-226 Arbitrary diagram linkage to model elements SysML 1.4 open
SYSML16-358 Allocate constraint#3 does not make sense SysML 1.5 open
SYSML16-349 ItemFlow constraint#3 does not make sense in every case SysML 1.5 open
SYSML16-274 Most constraints are missing their OCL statement SysML 1.5 open
SYSML16-132 Semantics consistency of conjugated behavior ports SysML 1.4 open
SYSML16-662 Error in the revised text for SYSML16-132 SysML 1.5 open

Issues Descriptions

Shared parts are still parts

  • Status: open  
  • 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
  • Updated: Wed, 20 Mar 2019 11:14 GMT

Bad reference in section 4.2

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Tue, 19 Mar 2019 21:39 GMT

Stakeholder constraint is listed twice

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Tue, 19 Mar 2019 21:34 GMT

VerdictKind enumeration missing

  • Status: open  
  • Source: NIST ( 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
  • Updated: Tue, 19 Mar 2019 10:46 GMT

VerdictKind

  • Key: SYSML17-84
  • Legacy Issue Number: 18312
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Tue, 19 Mar 2019 10:45 GMT

SysML's PrimitiveValueTypes library is missing "value" properties everywhere

  • Key: SYSML17-68
  • Legacy Issue Number: 16876
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Mon, 18 Mar 2019 19:52 GMT

SysML primitive value types

  • Key: SYSML17-52
  • Legacy Issue Number: 15882
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Mon, 18 Mar 2019 19:46 GMT
  • Attachments:

primitive types in SysML Activities

  • Key: SYSML17-97
  • Legacy Issue Number: 18659
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Mon, 18 Mar 2019 19:41 GMT

ConnectorProperty is redundant

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Mon, 18 Mar 2019 19:41 GMT

Support BDD's for State Machines

  • Key: SYSML17-32
  • Legacy Issue Number: 13263
  • Status: open  
  • 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
  • Updated: Mon, 18 Mar 2019 17:44 GMT

Connectors are not allowed in bdd

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Mon, 18 Mar 2019 15:00 GMT

Annex B / Figure B.10

  • Key: SYSML17-19
  • Legacy Issue Number: 12145
  • Status: open  
  • 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
  • Updated: Mon, 18 Mar 2019 14:59 GMT

Annex B / Figure B.9

  • Key: SYSML17-20
  • Legacy Issue Number: 12146
  • Status: open  
  • 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
  • Updated: Mon, 18 Mar 2019 14:55 GMT
  • Attachments:

Hidden constraints in description of PropertySpecificType

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 17 Mar 2019 10:25 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSML17-66
  • Legacy Issue Number: 16652
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Fri, 15 Mar 2019 15:53 GMT

DirectedFeature is confusing

  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:52 GMT

InstanceSpecification equality

  • Key: SYSML17-67
  • Legacy Issue Number: 16653
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Fri, 15 Mar 2019 15:49 GMT

How to refer to properties of an extension?

  • Key: SYSML17-78
  • Legacy Issue Number: 18168
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Fri, 15 Mar 2019 15:48 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: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:46 GMT

Inability to specify partial allocation and requriements satisfaction

  • Key: SYSML17-86
  • Legacy Issue Number: 18434
  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:43 GMT

SysML Issues on Item Property values in an IBD

  • Legacy Issue Number: 18805
  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:42 GMT

ElementGroup cannot be source or target of a dependency

  • Legacy Issue Number: 19595
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 15:39 GMT

A discarded resolution still appears in the ballot

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Fri, 15 Mar 2019 15:38 GMT

AllocateActivityPartition should be more formaly related to allocation Relationship

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Fri, 15 Mar 2019 15:38 GMT

Causality of constraints in parametric diagrams

  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:35 GMT

Requirement ID should be immutable

  • Legacy Issue Number: 19764
  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:31 GMT

Expand use of rake symbol for all decompositions

  • Legacy Issue Number: 19783
  • Status: open  
  • Source: University of Detroit Mercy ( Michael 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
  • Updated: Fri, 15 Mar 2019 15:29 GMT

Specify a specific part from a collection of parts on an IBD

  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:28 GMT

Numeric Literals as constraint block property parameter values

  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:04 GMT

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

  • Key: SYSML17-28
  • Legacy Issue Number: 13154
  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:03 GMT

Binding Relationships require unit conversions

  • Key: SYSML17-31
  • Legacy Issue Number: 13261
  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 15:02 GMT

Property Based Requirements

  • Key: SYSML17-71
  • Legacy Issue Number: 17016
  • Status: open  
  • 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
  • Updated: Fri, 15 Mar 2019 14:56 GMT

ProxyPort with FlowProperties

  • Key: SYSML17-98
  • Legacy Issue Number: 18676
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 14:47 GMT

Deprecate Unit and QuantityKind stereotypes in 1.4

  • Legacy Issue Number: 19062
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Fri, 15 Mar 2019 14:44 GMT

Convention for enumeration not used for ControlValue

  • Legacy Issue Number: 19134
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 14:42 GMT

More than one View() operation allowed

  • Legacy Issue Number: 19623
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 14:01 GMT

Inherit from a conjugated interface block

  • Legacy Issue Number: 19644
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 13:58 GMT

Missing property descriptions for Probability and Rate

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 13:57 GMT

Property path notation

  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Fri, 15 Mar 2019 13:56 GMT

Description of model elements in generated document not consistent with specification

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 13:54 GMT

Hanging Clauses Throughout SysML 1.4

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Fri, 15 Mar 2019 13:48 GMT

Owned properties of an InterfaceBlock

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Fri, 15 Mar 2019 13:43 GMT

Clarification of typing a binding connector


Statements missing in the abstract syntax description

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Fri, 15 Mar 2019 13:34 GMT

Typo in revised text of issue SYSML16-289

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Fri, 15 Mar 2019 13:23 GMT

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

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Thu, 14 Mar 2019 14:46 GMT

Inappropriate character for multiplying symbol with combined units

  • Status: open  
  • 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
  • Updated: Thu, 14 Mar 2019 14:45 GMT

SysML::Trace relationship is not specialized from UML::Trace in the XMI

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 14 Mar 2019 14:40 GMT

SysML::Refine relationship is not specialized from UML::Refine in the XMI

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 14 Mar 2019 14:40 GMT

Verdict described incorrecty

  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 14 Mar 2019 14:40 GMT

Do not move deprecated elements


Combined call-out notation not allowed

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 7 Mar 2019 16:58 GMT

DistributedProperty should be abstract

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 7 Mar 2019 16:44 GMT

DistributedProperty should be abstract

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 7 Mar 2019 16:43 GMT

Diagram header is not intuitively interpreted

  • Status: open  
  • 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
  • Updated: Thu, 7 Mar 2019 16:40 GMT

Description of AdjunctProperty

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 28 Feb 2019 14:48 GMT

Excluded UML metaclasses are not formally defined

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 28 Feb 2019 14:40 GMT

Add signal to constraint [1] for DistributedProperty

  • Status: open  
  • 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
  • Updated: Thu, 28 Feb 2019 14:24 GMT

Add Graphical notation for General Classifier

  • Status: open  
  • Source: Lockheed Martin ( 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
  • Updated: Thu, 28 Feb 2019 14:22 GMT

Diagram show inconsistent data

  • Key: SYSML17-94
  • Legacy Issue Number: 18503
  • Status: open  
  • 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
  • Updated: Wed, 27 Feb 2019 14:42 GMT

Reference Properties do not reference properties

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Thu, 21 Feb 2019 17:01 GMT

Typos/editorials found in the SysML 1.5 specification document


Replace UML4SysML::Kernel by UML4SysML::Generalization

  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Thu, 21 Feb 2019 16:45 GMT

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

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 21 Feb 2019 16:37 GMT


The AdjunctProperty is not clearly described

  • Status: open  
  • 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
  • Updated: Thu, 21 Feb 2019 16:29 GMT

Owning Block definition is unclear

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 21 Feb 2019 16:09 GMT

Diagram formality confusion

  • Status: open  
  • 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
  • Updated: Thu, 14 Feb 2019 15:08 GMT

"Allocated From" should be "Allocated"

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Thu, 14 Feb 2019 14:46 GMT
  • Attachments:

Derived attribute should also be read only

  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Thu, 14 Feb 2019 14:43 GMT

Missing comment for some attributes

  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Thu, 14 Feb 2019 14:37 GMT

SysML XMI typos in UML StandardProfile XMI references

  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 14 Feb 2019 14:37 GMT

No support for dot notation in activity and sequence diagrams

  • Status: open  
  • Source: NASA ( 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
  • Updated: Thu, 14 Feb 2019 14:36 GMT

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

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Thu, 14 Feb 2019 14:31 GMT

ConnectorProperty notation in wrong section.

  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 14 Feb 2019 14:30 GMT

Parts, references, values compartments in wrong section

  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 14 Feb 2019 14:29 GMT

Definition of SysML stereotypes: association ends versus attributes

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 14 Feb 2019 14:26 GMT

Make ItemFlow a specialization of DirectedRelationshipPropertyPath

  • Status: open  
  • Source: NASA ( 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
  • Updated: Thu, 14 Feb 2019 14:22 GMT

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Status: open  
  • Source: NASA ( 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
  • Updated: Thu, 14 Feb 2019 14:19 GMT

specializations of requirement should specialize AbstractRequirement

  • Status: open  
  • Source: NASA ( 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
  • Updated: Thu, 7 Feb 2019 17:00 GMT

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

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 7 Feb 2019 16:52 GMT

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

  • Legacy Issue Number: 19859
  • Status: open  
  • 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
  • Updated: Thu, 7 Feb 2019 16:51 GMT

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

  • Status: open  
  • 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
  • Updated: Thu, 7 Feb 2019 16:39 GMT

[SysML] Semantic variation points

  • Legacy Issue Number: 19489
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 7 Feb 2019 16:37 GMT

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

  • Legacy Issue Number: 19328
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Thu, 7 Feb 2019 16:34 GMT

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

  • Legacy Issue Number: 19321
  • Status: open  
  • Source: PTC ( 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
  • Updated: Thu, 7 Feb 2019 16:29 GMT

Update to Trace Relationship’

  • Legacy Issue Number: 19284
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 7 Feb 2019 16:26 GMT

Semantics clarification for removing a value from an out Flow Property

  • Legacy Issue Number: 18953
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 7 Feb 2019 16:14 GMT

About Rate, Continuous and Discrete

  • Legacy Issue Number: 18735
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Thu, 31 Jan 2019 14:47 GMT

The SysML classification of properties is incomplete

  • Legacy Issue Number: 18709
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Thu, 31 Jan 2019 14:40 GMT

Semantics of multiple Dependencies

  • Key: SYSML17-96
  • Legacy Issue Number: 18623
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 31 Jan 2019 14:16 GMT

Sample problem: Parts are added directly into package

  • Key: SYSML17-12
  • Legacy Issue Number: 11499
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Wed, 30 Jan 2019 18:23 GMT

Annex B / B.4.8.3 Activity Diagram (in sample problem)

  • Key: SYSML17-18
  • Legacy Issue Number: 12144
  • Status: open  
  • 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
  • Updated: Wed, 30 Jan 2019 18:22 GMT

Annex B / Figure B27

  • Key: SYSML17-21
  • Legacy Issue Number: 12147
  • Status: open  
  • 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
  • Updated: Wed, 30 Jan 2019 18:22 GMT

Annex B / Figure B.35


Annex B / Figure B.38

  • Key: SYSML17-23
  • Legacy Issue Number: 12154
  • Status: open  
  • 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

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Wed, 30 Jan 2019 18:22 GMT

Annex B, Figure B.29

  • Key: SYSML17-24
  • Legacy Issue Number: 12160
  • Status: open  
  • 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
  • Updated: Wed, 30 Jan 2019 18:21 GMT

Figure B.34 and Figure B.35

  • Key: SYSML17-25
  • Legacy Issue Number: 12366
  • Status: open  
  • 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.

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Updated: Wed, 30 Jan 2019 18:21 GMT

Where have stereotypes been defined?

  • Key: SYSML17-60
  • Legacy Issue Number: 16112
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    in some figures of the examples provided in Annex, some stereotypes are displayed: <<domain>>, <<external>>, <<diagramDescription>>, … and so on. Can someone tell me where these stereotypes have been defined?

  • Reported: SysML 1.4 — Mon, 28 Mar 2011 04:00 GMT
  • Updated: Wed, 30 Jan 2019 18:21 GMT

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

  • Key: SYSML17-61
  • Legacy Issue Number: 16113
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    the parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete w.r.t. to figure B.30. Is it ok?

  • Reported: SysML 1.4 — Mon, 28 Mar 2011 04:00 GMT
  • Updated: Wed, 30 Jan 2019 18:21 GMT

TestCase should use PackageMerge

  • Key: SYSML17-63
  • Legacy Issue Number: 16286
  • Status: open  
  • Source: KnowGravity Inc. ( 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
  • Updated: Wed, 30 Jan 2019 18:21 GMT

Don't use the optional notation for Pins with Allocation

  • Key: SYSML17-93
  • Legacy Issue Number: 18502
  • Status: open  
  • 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
  • Updated: Wed, 30 Jan 2019 18:18 GMT

Clarification required for Copy relationship

  • Key: SYSML17-95
  • Legacy Issue Number: 18525
  • Status: open  
  • 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
  • Updated: Thu, 24 Jan 2019 17:02 GMT

Allocated notation on object nodes missing from diagram elements table

  • Key: SYSML17-91
  • Legacy Issue Number: 18461
  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 24 Jan 2019 16:45 GMT

Allocation tabular notation normative?

  • Key: SYSML17-90
  • Legacy Issue Number: 18460
  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 24 Jan 2019 16:41 GMT

Figures 15.5 and 15.6 diagram types

  • Key: SYSML17-89
  • Legacy Issue Number: 18459
  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 24 Jan 2019 16:40 GMT

9.3.2.4 direction of ports and their notation (second issue)

  • Key: SYSML17-88
  • Legacy Issue Number: 18441
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Thu, 24 Jan 2019 16:39 GMT

Missing ownership constraints

  • Key: SYSML17-80
  • Legacy Issue Number: 18181
  • Status: open  
  • 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
  • Updated: Thu, 24 Jan 2019 16:38 GMT

9.3.2.4 direction of ports

  • Key: SYSML17-87
  • Legacy Issue Number: 18439
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Thu, 24 Jan 2019 16:36 GMT

Figure 15.8 diagram type

  • Key: SYSML17-85
  • Legacy Issue Number: 18409
  • Status: open  
  • Source: NIST ( 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
  • Updated: Thu, 24 Jan 2019 16:31 GMT

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

  • Key: SYSML17-83
  • Legacy Issue Number: 18268
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Thu, 24 Jan 2019 16:24 GMT

Missing type constraints for FullPort

  • Key: SYSML17-81
  • Legacy Issue Number: 18182
  • Status: open  
  • 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
  • Updated: Thu, 24 Jan 2019 16:21 GMT

Interface blocks and protocols

  • Key: SYSML17-79
  • Legacy Issue Number: 18169
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Thu, 24 Jan 2019 16:14 GMT

Virtual member representing the whole RTF

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Mon, 21 Jan 2019 15:13 GMT

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSML17-77
  • Legacy Issue Number: 17546
  • Status: open  
  • Source: Delligatti Associates, LLC ( 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
  • Updated: Thu, 17 Jan 2019 14:54 GMT

SysML: References to CreateEvent incorrect

  • Key: SYSML17-76
  • Legacy Issue Number: 17467
  • Status: open  
  • 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
  • Updated: Thu, 17 Jan 2019 14:48 GMT

Callout notation for port-specific types and initial values

  • Key: SYSML17-75
  • Legacy Issue Number: 17406
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Thu, 17 Jan 2019 14:45 GMT

9.3.2.9 What is InterfaceBlock?

  • Key: SYSML17-73
  • Legacy Issue Number: 17255
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Thu, 17 Jan 2019 14:38 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: open  
  • Source: Adaptive ( 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
  • Updated: Thu, 17 Jan 2019 14:36 GMT

Error in pending 1.3 diagram 15.6 and elsewhere

  • Key: SYSML17-70
  • Legacy Issue Number: 16947
  • Status: open  
  • 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
  • Updated: Thu, 17 Jan 2019 14:32 GMT

Requirements interchange issue

  • Key: SYSML17-29
  • Legacy Issue Number: 13177
  • Status: open  
  • 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
  • Updated: Thu, 17 Jan 2019 13:58 GMT

Dubious UUIDs

  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    http://www.omg.org/spec/SysML/20150709/SysML.xmi, unlike its predecessors and UML 2.5, defines both xmi:uuid and xmi:id.

    This is a monumental bloat.

    The UUIDs are of dubious utility since the constructive algorithm does not incorporate anything specific to SysML 1.4. Therefore all future SysML serializations must use a different constructive algorithm that guarantees never to repeat the 1.4 UUIDs. (Simplest, never to bloat with UUIDs ever again.)

  • Reported: SysML 1.4 — Sat, 4 Jun 2016 08:12 GMT
  • Updated: Sun, 13 Jan 2019 20:11 GMT

Do not move deprecated elements


ConnectorProperty is redundant

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

DistributedProperty should be abstract

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

DistributedProperty should be abstract

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Description of AdjunctProperty

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Diagram header is not intuitively interpreted

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Inconsistency between xmi and pdf for Trace and Refine specializations

  • Status: open   Implementation work Blocked
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

SysML 1.6 should be based on UML 2.5.1

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Add signal to constraint [1] for DistributedProperty

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Inconsistency between xmi and pdf for Trace and Refine specializations

  • Status: open   Implementation work Blocked
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Add Graphical notation for General Classifier

  • Status: open  
  • Source: Lockheed Martin ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Typo in revised text of issue SYSML16-289

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

SysML 1.6 should be based on UML 2.5.1

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Excluded UML metaclasses are not formally defined

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Reference Properties do not reference properties

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

DirectedFeature is confusing

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Statements missing in the abstract syntax description

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Typos/editorials found in the SysML 1.5 specification document


Replace UML4SysML::Kernel by UML4SysML::Generalization

  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Inconsistency in the DirectedRelationshipPropertyPath specification

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Clarification of typing a binding connector


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

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT


FullPort type

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

The AdjunctProperty is not clearly described

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Owned properties of an InterfaceBlock

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

FullPort type

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Owning Block definition is unclear

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Diagram formality confusion

  • Status: open  
  • 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. On 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 owed 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Numeric Literals as constraint block property parameter values

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Shared parts are still parts

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Derived attribute should also be read only

  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Causality of constraints in parametric diagrams

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

"Allocated From" should be "Allocated"

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT
  • Attachments:

Expand use of rake symbol for all decompositions

  • Legacy Issue Number: 19783
  • Status: open  
  • Source: University of Detroit Mercy ( Michael 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Requirement ID should be immutable

  • Legacy Issue Number: 19764
  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Specify a specific part from a collection of parts on an IBD

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

AllocateActivityPartition should be more formaly related to allocation Relationship

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Hanging Clauses Throughout SysML 1.4

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Missing comment for some attributes

  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

SysML XMI typos in UML StandardProfile XMI references

  • Status: open  
  • Source: NIST ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

No support for dot notation in activity and sequence diagrams

  • Status: open  
  • Source: NASA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Status: open  
  • Source: Thematix Partners LLC ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Definition of SysML stereotypes: association ends versus attributes

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Description of model elements in generated document not consistent with specification

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Parts, references, values compartments in wrong section

  • Status: open  
  • Source: NIST ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

ConnectorProperty notation in wrong section.

  • Status: open  
  • Source: NIST ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Legacy Issue Number: 19859
  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Property path notation

  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Missing property descriptions for Probability and Rate

  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

A discarded resolution still appears in the ballot

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Make ItemFlow a specialization of DirectedRelationshipPropertyPath

  • Status: open  
  • Source: NASA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Resolve inconsistency concerning restricion of ItemFlow type hierarchy

  • Status: open  
  • Source: NASA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

specializations of requirement should specialize AbstractRequirement

  • Status: open  
  • Source: NASA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Can a SysML Full Port be typed by a ValueType?

  • Legacy Issue Number: 19412
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Inherit from a conjugated interface block

  • Legacy Issue Number: 19644
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

More than one View() operation allowed

  • Legacy Issue Number: 19623
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

ElementGroup cannot be source or target of a dependency

  • Legacy Issue Number: 19595
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

[SysML] Semantic variation points

  • Legacy Issue Number: 19489
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Can a SysML Full Port be typed by a ValueType?

  • Legacy Issue Number: 19412
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Legacy Issue Number: 19328
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

classifierBehaviorProperty and adjunctProperty notation

  • Legacy Issue Number: 19326
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Abstract syntax for the initial values

  • Legacy Issue Number: 19286
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT
  • Attachments:

proxy and full port notation change request

  • Legacy Issue Number: 18993
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

classifierBehaviorProperty and adjunctProperty notation

  • Legacy Issue Number: 19326
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Legacy Issue Number: 19321
  • Status: open  
  • Source: PTC ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Abstract syntax for the initial values

  • Legacy Issue Number: 19286
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT
  • Attachments:

Update to Trace Relationship’

  • Legacy Issue Number: 19284
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Convention for enumeration not used for ControlValue

  • Legacy Issue Number: 19134
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Deprecate Unit and QuantityKind stereotypes in 1.4

  • Legacy Issue Number: 19062
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

proxy and full port notation change request

  • Legacy Issue Number: 18993
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Pull semantics for flow properties

  • Legacy Issue Number: 18876
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Legacy Issue Number: 18877
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Semantics clarification for removing a value from an out Flow Property

  • Legacy Issue Number: 18953
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The specification should clarify the semantics from 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties

  • Legacy Issue Number: 18877
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Pull semantics for flow properties

  • Legacy Issue Number: 18876
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

SysML Issues on Item Property values in an IBD

  • Legacy Issue Number: 18805
  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Legacy Issue Number: 18783
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Key: SYSML17-99
  • Legacy Issue Number: 18678
  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

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

  • Legacy Issue Number: 18783
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

About Rate, Continuous and Discrete

  • Legacy Issue Number: 18735
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

The SysML classification of properties is incomplete

  • Legacy Issue Number: 18709
  • Status: open  
  • Source: NASA ( Nicolas 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Legacy Issue Number: 18678
  • Status: open  
  • 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

ProxyPort with FlowProperties

  • Legacy Issue Number: 18676
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Libraries package should be named "SysML Model Libraries"

  • Key: SYSML17-92
  • Legacy Issue Number: 18462
  • Status: open  
  • Source: NIST ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

primitive types in SysML Activities

  • Legacy Issue Number: 18659
  • Status: open  
  • Source: No Magic, Inc. ( 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
  • Updated: Sun, 13 Jan 2019 15:32 GMT

Semantics of multiple Dependencies

  • Legacy Issue Number: 18623
  • Status: open  
  • Source: Airbus Group ( 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
  • Updated: Sun, 13 Jan