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

All Issues

  • All Issues
  • Name: sysml-rtf
  • Issues Count: 766

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML16-399 Nested diagrams in SysML SysML 1.5 open
SYSML16-397 Diagram guidelines uses excluded UML element SysML 1.5 open
SYSML16-395 Binding connectors in internal block diagrams must always show the keyword SysML 1.5 open
SYSML16-393 Binding connectors have no keyword syntax in parametric diagrams SysML 1.5 open
SYSML16-389 Change keyword of binding connector from "equal" to "=" SysML 1.5 open
SYSML16-139 Abstract syntax for the initial values SysML 1.4 open
SYSML16-319 Clarification of typing a binding connector SysML 1.5 open
SYSML16-90 Is <> keyword (or stereotype) on binding connectors is part of SysML notation? SysML 1.4 open
SYSML16-181 Binding Connector should not be typed SysML 1.4 open
SYSML16-26 Section: Generalization of stereotyped elements SysML 1.0 open
SYSML16-143 Can a SysML Full Port be typed by a ValueType? SysML 1.4 open
SYSML16-387 Equal sign for binding connector SysML 1.5 open
SYSML16-84 Property Based Requirements SysML 1.3 open
SYSML16-132 Semantics consistency of conjugated behavior ports SysML 1.4 open
SYSML16-382 Allow a Requirement to be contained on Any Diagram SysML 1.5 open
SYSML16-366 Constraints for Refine and Trace can be improved 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-100 Incorrect constraint [2] on InterfaceBlock SysML 1.3 open
SYSML16-348 ItemFlow constraint#1 implicilty contrains ItemFlow to rely on a binary relation SysML 1.5 open
SYSML16-357 Allocate constraint#1 could be replaced by a redefinition SysML 1.5 open
SYSML16-351 The statement of TriggerOnNestedPort constraint#4 is not appropriate SysML 1.5 open
SYSML16-343 Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition SysML 1.5 open
SYSML16-345 SysML stereotype constraints should be named rather than numbered SysML 1.5 open
SYSML16-274 Most constraints are missing their OCL statement 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-331 UnitAndQuantityKind figure missing block keyword SysML 1.5 open
SYSML16-332 EndPathMultiplicity constraint#2 uses a wrong name to refer to a stereotype property SysML 1.5 open
SYSML16-310 SysML::Block constraint#3 containts an incorrect assertion about UML SysML 1.5 open
SYSML16-323 AdjunctProperty constraint#8 can be simplified 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-295 Remove [sic] in block constraints SysML 1.5 open
SYSML16-201 Behavior Diagram Element tables imply diagrams can be nodes SysML 1.4 open
SYSML16-344 Typos/editorials found in the SysML 1.5 specification document SysML 1.5 open
SYSML16-198 Most diagram headers in document are not consistent with Appendix A, p 189. SysML 1.4 open
SYSML16-183 SysML specification document cleanups SysML 1.4 open
SYSML16-182 NestedConnectorEnd violates UML "roles" constraint 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-50 Flow properties and activity paramters 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-329 Constraints redundancy in DirectedRelationshipPropertyPath SysML 1.5 open
SYSML16-341 Constraint#2 of the InvocationOnNestedPortAction stereotype is invalid 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-371 Reference Properties do not reference properties SysML 1.5 open
SYSML16-373 Add Graphical notation for General Classifier SysML 1.5 open
SYSML16-372 DirectedFeature is confusing SysML 1.5 open
SYSML16-108 9.3.2.4 direction of ports SysML 1.4 open
SYSML16-367 Constraints on Satisfy and Verify should refer to AbstractRequirement SysML 1.5 open
SYSML16-365 Copy constraints #2 and #3 shoud be merged together SysML 1.5 open
SYSML16-364 Statements missing in the abstract syntax description SysML 1.5 open
SYSML16-355 Probability constraint#1 is ambiguous SysML 1.5 open
SYSML16-350 Do not move deprecated elements SysML 1.5 open
SYSML16-349 ItemFlow constraint#3 does not make sense in every case SysML 1.5 open
SYSML16-264 Owned properties of an InterfaceBlock SysML 1.5 open
SYSML16-109 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 open
SYSML16-130 Flow property description: incorrect wording (§9.3.2.7) SysML 1.4 open
SYSML16-358 Allocate constraint#3 does not make sense SysML 1.5 open
SYSML16-356 Rate constraint#2 is ambiguous SysML 1.5 open
SYSML16-354 The OCL statement of ConstraintBlock constraint#3 is wrong SysML 1.5 open
SYSML16-294 Parameter direction typo in XMI SysML 1.5 open
SYSML16-342 The statement of InvocationOnNestedPortAction constraint#3 is not appropriate SysML 1.5 open
SYSML16-321 View constraint#3 is incorrect SysML 1.5 open
SYSML16-186 The type of ParticipantProperty SysML 1.4 open
SYSML16-203 Update description about extension of UML SysML 1.4 open
SYSML16-188 ParticipantProperty keyword SysML 1.4 open
SYSML16-165 Initial values compartment header inconsistent with others SysML 1.4 open
SYSML16-154 Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous SysML 1.4 open
SYSML16-339 2017-08-31 Weekly meeting minutes 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-148 Inherit from a conjugated interface block 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-211 Block constraint [4] contains a false statement SysML 1.5 open
SYSML16-191 Keyword signal in reception compartment is superfluous 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-177 Incorrect multiplicity for base_xxx properties of most SysML Stereotypes SysML 1.4 open
SYSML16-180 AdjunctProperty principal should be a NamedElement SysML 1.4 open
SYSML16-168 DeriveReqt constraints multiplicity of Client and Supplier SysML 1.4 open
SYSML16-171 xmi:IDs are not convenient SysML 1.4 open
SYSML16-173 Wrong parameter for Operations in the SysML.xmi SysML 1.4 open
SYSML16-166 RequirementRelated is present in the summary but no more in the document SysML 1.4 open
SYSML16-48 Ability for a binding connector to be typed SysML 1.1 open
SYSML16-179 Hanging Clauses Throughout SysML 1.4 SysML 1.4 open
SYSML16-318 2017-07-20 Weekly meeting minutes SysML 1.5 open
SYSML16-314 The association-like notation is ambiguous SysML 1.5 open
SYSML16-131 Proxy port “complete” specification (§ 9.3.2.12): SysML 1.4 open
SYSML16-185 Instance for Initial values SysML 1.4 open
SYSML16-298 Replace all occurrences of "has been" by "is" SysML 1.5 open
SYSML16-228 Shared parts are still parts SysML 1.4 open
SYSML16-229 Constant Block Value Properties SysML 1.4 open
SYSML16-204 Requirement ID should be immutable SysML 1.4 open
SYSML16-226 Arbitrary diagram linkage to model elements SysML 1.4 open
SYSML16-230 Numeric Literals as constraint block property parameter values SysML 1.4 open
SYSML16-253 Owning Block definition is unclear SysML 1.5 open
SYSML16-39 Allocations should not generate dependencies SysML 1.1 open
SYSML16-172 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 open
SYSML16-167 Copy, DeriveReqt don't have operations, but Refine, Satisfy, Trace, Verify do. SysML 1.4 open
SYSML16-227 Specify a specific part from a collection of parts on an IBD SysML 1.4 open
SYSML16-231 Diagram formality confusion SysML 1.4 open
SYSML16-263 FullPort type SysML 1.5 open
SYSML16-275 Typo in xmi file for orderedMember SysML 1.4 open
SYSML16-288 The AdjunctProperty is not clearly described SysML 1.4 open
SYSML16-254 Clarify port usage patterns SysML 1.5 open
SYSML16-174 Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 SysML 1.4 open
SYSML16-87 Port labels inside Port symbol 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-86 Section 9.3.1.7 SysML 1.4 open
SYSMLR-155 Precise expression of requirements SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-154 Need to define Requirement Relationship compartment SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-208 Satisfy, Verify and DeriveReqt could be used with non-requirement elements SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-278 JTC1 JP3 023 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-270 JTC1 JP18 015 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-271 JTC1 JP20 016 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-269 JTC1 JP19 014 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-324 update constraints to set sourceContext and targetContext of «DirectedRelationshipPropertyPath» SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-330 There is no notation for units on properties and values SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-263 JTC1 JP12 008 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-332 Property path with unnamed properties is unreadable SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-248 ParticipantProperty multiplicity SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-268 JTC1 JP17 013 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-265 JTC1 JP13 010 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-246 Add example of PBR using Block SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-267 JTC1 JP16 012 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-287 TriggerOnNestedPort constraint [5] makes no sense SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-286 TriggerOnNestedPort constraint [6] makes no sense SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-48 SysML 7.3.2.5 Viewpoint SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-258 JTC1 JP8 003 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-262 JTC1 JP10 007 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-266 JTC1 JP15 011 SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-264 JTC1 JP14 009 SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-279 JTC1 JP4 024 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-261 JTC1 JP11 006 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-259 JTC1 JP7 004 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-260 JTC1 JP9 005 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-275 JTC1 JP24 020 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-276 JTC1 JP2 021 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-277 JTC1 JP5 022 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-272 JTC1 JP21 017 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-273 JTC1 JP22 018 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-274 JTC1 JP23 019 SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-153 reception compartment not addressed SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-1 SysML: Protocol State Machines needed SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-130 What kind of elements can diagrams be for?. SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-216 Table 8.1 Block compartment header misplaced and other formatting problems and inconsistencies SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-257 JTC1 JP6 002 SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-126 Forked association notation ill-formed SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-85 SysML diagrams show only SysML-stereotyped elements SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-231 16.3.2.4 Requirement Operations OCL Inconsistent SysML 1.4 SysML 1.5 Resolved closed
SYSMLR-74 Multiassociation SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-51 Allocate of Actions or of Activities SysML 1.4 SysML 1.5 Duplicate or Merged closed
SYSMLR-256 JTC1 JP1 001 SysML 1.4 SysML 1.5 Closed; No Change closed
SYSMLR-10 BindingConnector SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-14 SysML: Interaction diagram and Data-based comm of SysML SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-9 Issue: Nested connector ends SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-12 It is not allowed in UML to display stereotypes of related elements SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-13 Parts are added directly into package SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-11 Lack of notation for units and dimensions on values. SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-2 SysML: UML Qualified Associations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-8 Section: 12. Interactions SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-4 Section: 9.3.2.5 FlowPort SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-7 Block namespace compartment: Are external relationships allowed SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-6 Timing diagrams SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-5 Section: Figure 14.2 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-3 SysML: Generalizing Activites SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-18 10.3.1.2 Parametric Diagram SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-22 Annex B / Figure B27 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-24 Annex B / Figure B.38 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-19 Annex B / B.4.8.3 Activity Diagram SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-23 Annex B / Figure B.35 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-26 Section: Generalization of stereotyped elements SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-21 Annex B / Figure B.9 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-20 Annex B / Figure B.10 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-25 Annex B, Figure B.29 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-15 Section: 5.3 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-16 Inferred Allocation on Allocate Activity Partitions SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-17 Item Flows on Activity Diagrams SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-38 Inability to represent dependent, independent parameters on constraint properties SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-36 Support BDD's for State Machines SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-37 AllocateActivityPartition and UML 2 semantics SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-35 Binding Relationships require unit conversions SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-34 Requirement constants should be integrated into Model-centric vision of SysmL SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-32 Representation of nested object nodes in activity diagrams SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-31 Requirements interchange issue SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-33 Section: 8/8.3.2 Inability to efficiently capture datasets SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-27 Figure B.34 and Figure B.35 SysML 1.0 SysML 1.5 Deferred closed
SYSMLR-30 SysML: Operations on Activities need to be callable (e.g., start, restart, cancel) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-29 SysML: Activity Properties should be accessible in Activity diagrams for decision making SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-28 SysML: Align SysML Activities with Foundational UML SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-45 callout notation issues SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-52 Flow properties and activity paramters SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-53 SysML 1.2 Issue Viewpoint referencing other viewpoints properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-47 Do parametric bindings observe derived and read-only properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-49 Ability for a binding connector to be typed SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-46 Binding to multiplicity in parametrics SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-50 Inheriting Allocations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-39 Allocations should not generate dependencies SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-41 Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-42 Proposal to have a stereotype for reference nested property SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-40 Parsing Text in Requirements SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-44 Need to have an explicit way to bind flow properties or atomic flow ports to block properties SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-43 Flow port compatibility with behavior SysML 1.1 SysML 1.5 Deferred closed
SYSMLR-56 Continuous flows in non-streaming situations with >1 multiplicities SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-57 SysML 1.2 Issues: Optional with streaming SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-62 SysML primitive value types SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-61 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-59 SysML Issue based on UML 15369 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-60 SysML Issue representation of properties as associations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-58 Figure B.35 object nodes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-70 Definition of part SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-54 SysML 1.2 Issues: Default stereotype on unlabeled box is not always optimal SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-55 SysML 1.2 Issues: DistributedProperties on Activates SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-75 Association owning ends SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-67 SysML Issue on Refine limitations SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-71 Incorrect statement about UML n-aries SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-65 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-64 Blocks cannot own items flows SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-73 parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-72 Where have stereotypes been defined? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-66 Description of Item Flows SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-68 Item flows can have multiple types but item properties cannot SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-69 Compartment labelling rules SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-63 Another issue with allocate SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-84 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-88 Property Based Requirements SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-86 Question about the Activity decomposition in Bloc Definition Diagrams SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-87 Error in pending 1.3 diagram 15.6 and elsewhere SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-89 SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-79 Problems with property-specific types SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-77 Can Enumerations be used on parametric diagrams for typing constraint parameters SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-83 Issue on Block constraint#4 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-82 Lightweight representations of faults, failures, hazards and off-nominal conditions and behavior SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-76 TestCase should use PackageMerge SysML 1.2 SysML 1.5 Deferred closed
SYSMLR-78 Content of Requirement::/tracedTo SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-80 InstanceSpecifications for exactly one instance SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-81 InstanceSpecification equality SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-99 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-95 Callout notation for port-specific types and initial values SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-96 remove figure numbers from diagram frames SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-98 Problems with 1.3 Enumeration Literals SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-101 Interface blocks and protocols SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-100 How to refer to properties of an extension? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-97 SysML: References to CreateEvent incorrect SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-94 Is <> keyword (or stereotype) on binding connectors is part of SysML notation? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-92 9.3.2.9 What is InterfaceBlock? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-90 Section 9.3.1.7 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-93 clarification, what "part property" is SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-91 Port labels inside Port symbol SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-121 Clarification required for Copy relationship SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-113 9.3.2.4 direction of ports and their notation (second issue) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-112 9.3.2.4 direction of ports SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-108 View and Viewpoint Limitations in support of auto-view generation SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-106 SysML stereotype notation creates ambiguity about to which element is the stereotype applied SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-111 Inability to specify partial allocation and requriements satisfaction SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-110 Constraint [5] should include specializations of Requirement SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-104 Incorrect constraint [2] on InterfaceBlock SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-107 VerdictKind SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-103 Missing type constraints for FullPort SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-109 Figure 15.8 diagram type SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-105 Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-102 Missing ownership constraints SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-127 SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-120 Diagram show inconsistent data SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-125 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-119 Don't use the optional notation for Pins with Allocation SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-124 ProxyPort with FlowProperties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-123 primitive types in SysML Activities SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-115 Figures 15.5 and 15.6 diagram types SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-117 Allocated notation on object nodes missing from diagram elements table SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-118 Libraries package should be named "SysML Model Libraries" SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-122 Semantics of multiple Dependencies SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-116 Allocation tabular notation normative? SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-114 Ports and Flows SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-144 Update to Trace Relationship’ SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-138 Semantics consistency of conjugated behavior ports SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-134 Pull semantics for flow properties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-142 Update SysML references to UML model library StandardProfileL2 SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-135 Depletive/non-depletive semantics of ReadStructuralFeatureActions on FlowProperties SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-137 Proxy port “complete” specification (§ 9.3.2.12): SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-143 Convention for enumeration not used for ControlValue SysML 1.3 SysML 1.5 Deferred closed
SYSMLR-136 Flow property description: incorrect wording (§9.3.2.7) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-132 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-128 The SysML classification of properties is incomplete SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-131 Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-129 About Rate, Continuous and Discrete SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-158 More than one View() operation allowed SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-156 ElementGroup cannot be source or target of a dependency SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-157 Table 12.1 has incorrect "int" typed arguments (4x) SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-148 Need clarification about possible configurations of the new ports introduced in SysML 1.3 and of their semantics SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-145 Abstract syntax for the initial values SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-141 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-140 proxy and full port notation change request SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-147 classifierBehaviorProperty and adjunctProperty notation SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-150 [SysML] Semantic variation points SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-146 URI for the SysML Profile given in section E.3 is wrong SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-139 Semantics clarification for removing a value from an out Flow Property SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-149 Can a SysML Full Port be typed by a ValueType? SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-133 SysML Issues on Item Property values in an IBD SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-159 Inherit from a conjugated interface block SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-160 <> should be a reference (dashed box) SysML 1.4 SysML 1.5 Deferred closed
SYSML16-127 SysML Issues on Item Property values in an IBD SysML 1.4 open
SYSML16-170 No support for dot notation in activity and sequence diagrams SysML 1.4 open
SYSML16-196 layout error for compartment name SysML 1.4 open
SYSML16-205 SysML Provides Inadequate Support for Reuse of Requirements SysML 1.4 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-193 Constraint clarification SysML 1.4 open
SYSML16-195 Missing one right parenthesis in the constraint equation SysML 1.4 open
SYSML16-184 ISO DIS 19514 (JTC1 Comments against SysML 1.4) SysML 1.4 open
SYSML16-187 ParticipantProperty stereotype is redundant SysML 1.4 open
SYSML16-94 Problems with 1.3 Enumeration Literals 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-43 Flow port compatibility with behavior SysML 1.1 open
SYSML16-4 Section: 9.3.2.5 FlowPort SysML 1.0 open
SYSML16-126 SysML says nothing about how to deal with multiplicity for flow properties matching SysML 1.4 open
SYSML16-120 ProxyPort with FlowProperties SysML 1.4 open
SYSML16-98 Missing ownership constraints SysML 1.3 open
SYSML16-97 Interface blocks and protocols SysML 1.4 open
SYSML16-91 Callout notation for port-specific types and initial values SysML 1.3 open
SYSML16-61 Another issue with allocate SysML 1.4 open
SYSML16-66 Item flows can have multiple types but item properties cannot SysML 1.2 open
SYSML16-64 Description of Item Flows SysML 1.2 open
SYSML16-62 Blocks cannot own items flows SysML 1.2 open
SYSML16-169 AllocateActivityPartition should be more formaly related to allocation Relationship SysML 1.4 open
SYSML16-88 9.3.2.9 What is InterfaceBlock? 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-134 proxy and full port notation change request SysML 1.4 open
SYSML16-63 IBD notation doesn't distinguish item properties from connector labels SysML 1.2 open
SYSML16-99 Missing type constraints for FullPort SysML 1.3 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-123 The SysML classification of properties is incomplete SysML 1.4 open
SYSML16-34 Requirement constants should be integrated into Model-centric vision of SysmL SysML 1.4 open
SYSML16-175 Dubious UUIDs SysML 1.4 open
SYSML16-176 Missing comment for some attributes SysML 1.4 open
SYSML16-149 <> should be a reference (dashed box) SysML 1.4 open
SYSML16-56 Figure B.35 object nodes SysML 1.4 open
SYSML16-68 Definition of part SysML 1.2 open
SYSML16-125 Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors SysML 1.4 open
SYSML16-145 ElementGroup cannot be source or target of a dependency SysML 1.4 open
SYSML16-124 About Rate, Continuous and Discrete SysML 1.4 open
SYSML16-119 primitive types in SysML Activities 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-111 Figures 15.5 and 15.6 diagram types SysML 1.3 open
SYSML16-105 Figure 15.8 diagram type SysML 1.3 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-89 clarification, what "part property" is SysML 1.4 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-40 Parsing Text in Requirements SysML 1.1 open
SYSML16-189 Derived attribute should also be read only SysML 1.4 open
SYSML16-206 Expand use of rake symbol for all decompositions SysML 1.4 open
SYSML16-232 2017-02-22 Weekly meeting minutes SysML 1.5 open
SYSML16-164 ConnectorProperty notation in wrong section. SysML 1.4 open
SYSML16-163 Parts, references, values compartments in wrong section SysML 1.4 open
SYSML16-162 Description of model elements in generated document not consistent with specification SysML 1.4 open
SYSML16-161 Definition of SysML stereotypes: association ends versus attributes SysML 1.4 open
SYSML16-160 Cannot navigate and represent deep nested defining feature in a slot SysML 1.4 open
SYSML16-157 specializations of requirement should specialize AbstractRequirement SysML 1.4 open
SYSML16-156 A discarded resolution still appears in the ballot SysML 1.4 open
SYSML16-152 Property path notation 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-144 [SysML] Semantic variation points 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
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-138 Update to Trace Relationship’ SysML 1.4 open
SYSML16-137 Convention for enumeration not used for ControlValue SysML 1.3 open
SYSML16-136 Update SysML references to UML model library StandardProfileL2 SysML 1.3 open
SYSML16-135 Deprecate Unit and QuantityKind stereotypes in 1.4 SysML 1.4 open
SYSML16-121 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 open
SYSML16-118 Semantics of multiple Dependencies SysML 1.4 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-107 Inability to specify partial allocation and requriements satisfaction SysML 1.3 open
SYSML16-104 View and Viewpoint Limitations in support of auto-view generation 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-96 How to refer to properties of an extension? SysML 1.4 open
SYSML16-92 remove figure numbers from diagram frames SysML 1.3 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-81 SysML's PrimitiveValueTypes library is missing "value" properties everywhere SysML 1.4 open
SYSML16-80 Issue on Block constraint#4 SysML 1.4 open
SYSML16-79 Lightweight representations of faults, failures, hazards and off-nominal conditions and behavior SysML 1.2 open
SYSML16-78 InstanceSpecification equality SysML 1.3 open
SYSML16-77 InstanceSpecifications for exactly one instance SysML 1.3 open
SYSML16-76 Problems with property-specific types 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
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-65 SysML Issue on Refine limitations 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
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-49 Inheriting Allocations SysML 1.4 open
SYSML16-59 SysML Issue on Multiplicity of Use Case Communication Associations SysML 1.4 open
SYSML16-60 SysML primitive value types SysML 1.4 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
SYSML16-38 Inability to represent dependent, independent parameters on constraint properties 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-33 Section: 8/8.3.2 Inability to efficiently capture datasets SysML 1.1 open
SYSML16-32 Representation of nested object nodes in activity diagrams SysML 1.1 open
SYSML16-31 Requirements interchange issue 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-14 SysML: Interaction diagram and Data-based comm of SysML 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-155 ISO-80000 ValueType stereotype applications have wrong unit and quantityKind values SysML 1.4 open
SYSML16-151 Provide support to capture engineering quantities and support intricate calculations SysML 1.4 open
SYSML16-153 Does the objectiveFunction stereotype generalizes the ConstraintBlock stereotype or UML::property? SysML 1.4 open
SYSML16-190 2016-03-31 Online meeting minutes SysML 1.4 open
SYSML16-200 2015-10-15 Online meeting minutes SysML 1.4 open
SYSML16-197 "Allocated From" should be "Allocated" SysML 1.4 open
SYSML16-150 Missing property descriptions for Probability and Rate SysML 1.4 open
SYSML16-194 Causality of constraints in parametric diagrams SysML 1.4 open
SYSML16-18 10.3.1.2 Parametric Diagram: square box notation SysML 1.0 open
SYSML16-19 Annex B / B.4.8.3 Activity Diagram (in sample problem) 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-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-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
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
SYSMLR-285 Incorrect multiplicity for base_xxx properties of most SysML Stereotypes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-281 The XMI file isn't conform to the pdf specification for Refine and Trace stereotypes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-169 Spec document inconsistent with Normative profile XMI file ptc/2013-12-11 SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-334 No support for dot notation in activity and sequence diagrams SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-289 Wrong parameter for Operations in the SysML.xmi SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-243 Dubious UUIDs SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-225 SysML XMI typos in UML StandardProfile XMI references SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-238 Missing comment for some attributes SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-163 RequirementRelated is present in the summary but no more in the document SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-338 Cannot navigate and represent deep nested defining feature in a slot SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-328 Resolve inconsistency concerning restricion of ItemFlow type hierarchy SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-326 Make ItemFlow a specialization of DirectedRelationshipPropertyPath SysML 1.4 SysML 1.5 Deferred closed
SYSMLR-247 specializations of requirement should specialize AbstractRequirement SysML 1.4 SysML 1.5 Deferred closed
SYSML11-132 09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port SysML 1.0 SysML 1.1 Resolved closed
SYSML13-61 Invocations of required behavior features without going through ports SysML 1.2 SysML 1.3 Resolved closed
SYSML14-49 Metamodel error in 14447 and 18407 OCL 2.3.1 SysML 1.4 Resolved closed
SYSML11-90 11 Activities, Figure 11.10 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-89 11.Activities/11.3.2.8 Rate/Figure 11.8 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-88 11 Activities, 11.2.1 Activity Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-87 10 Constraint Blocks, 10.3.2.1 ConstraintBlock SysML 1.0 SysML 1.1 Resolved closed
SYSML11-86 10.3.2.2 ConstraintProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-85 10.3.2.2 ConstraintProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-97 Annex B / B.4.5.4 Block Definition Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-96 Annex B, B.4.4.3 Requirement Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-95 Annex B/B.4.1.2 Package Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-94 15.3.2.3 AllocateActivityPartition SysML 1.0 SysML 1.1 Resolved closed
SYSML11-93 11. Activities SysML 1.0 SysML 1.1 Resolved closed
SYSML11-92 11 Activities, Figure 11.10 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-91 11.Activities, Figure11.10 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-111 Section: annex A.1, Activities SysML 1.0 SysML 1.1 Resolved closed
SYSML11-110 Section: Chapter 7: Viewpoint SysML 1.0 SysML 1.1 Resolved closed
SYSML11-109 Section: 08 Blocks: suggest need Quantity stereotype and definition SysML 1.0 SysML 1.1 Resolved closed
SYSML11-108 Suggest permit UML2.1.1 Component for use as parasitic element wrapper Comp SysML 1.0 SysML 1.1 Closed; No Change closed
SYSML11-107 10.Constraint, Figure 10.3 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-106 Section: 8.3.2.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-105 Section: 9.3.2 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-124 p.46 under 8.3.2.4 DistributedProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-123 DistributedProperty SysML 1.0 SysML 1.1 Resolved closed
SYSML11-122 08. Blocks: The 'values' compartment for a part Property in an IBD SysML 1.0 SysML 1.1 Resolved closed
SYSML11-121 08.Blocks: compartment for property-specific defaultValue should be renamed SysML 1.0 SysML 1.1 Resolved closed
SYSML11-120 08.Blocks, 8.2.2 Internal Block Diagram: SysML 1.0 SysML 1.1 Resolved closed
SYSML11-119 SysML needs instance specs SysML 1.0 SysML 1.1 Resolved closed
SYSML11-130 Missing tags in XMI SysML 1.0 SysML 1.1 Resolved closed
SYSML11-129 The href should reference the URI for the UML elements SysML 1.0 SysML 1.1 Resolved closed
SYSML11-128 type should be cmof:Class not uml:Class SysML 1.0 SysML 1.1 Resolved closed
SYSML11-127 4.2: StandardProfileL2 uses elements not supported by SysML SysML 1.0 SysML 1.1 Resolved closed
SYSML11-126 Section: 08 Blocks, Annex B, Annex C SysML 1.0 SysML 1.1 Resolved closed
SYSML11-125 NestedConnectorEnd multiplicity typo in Fig 8.5 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-118 SysML unnecessarily restricts aggregation of datatypes SysML 1.0 SysML 1.1 Resolved closed
SYSML11-117 Section: More constraints for flow ports SysML 1.0 SysML 1.1 Resolved closed
SYSML11-116 Section: 8.3.2.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-115 moe should be removed from section 7.4 or added to the standard SysML 1.0 SysML 1.1 Resolved closed
SYSML11-114 remove homemade stereotypes SysML 1.0 SysML 1.1 Resolved closed
SYSML11-113 Icons for FlowPort SysML 1.0 SysML 1.1 Resolved closed
SYSML11-112 Section: Chapter 2: UML version SysML 1.0 SysML 1.1 Resolved closed
SYSML11-104 Annex B, Figure B.18, Figure B.19 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-103 Annex / Figure B.37 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-102 Annex B / Figure B36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-101 Annex B / Figure B.36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-100 Annex B / Figure B36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-99 Annex B / Figure B.36 SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-98 Annex B / B.4.8.3 Activity Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-131 Section: 11.3.2.2 ControlOperator UML 2.1.1 SysML 1.1 Resolved closed
SYSML11-83 8.3.1.2 Internal Block Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-82 8 Blocks, 8.3.1.2 Internal Block Diagram, 8.3.2.2 Block SysML 1.0 SysML 1.1 Resolved closed
SYSML11-81 Allocation Callout to Item Flow is Ambiguous SysML 1.0 SysML 1.1 Closed; No Change closed
SYSML11-80 Section: 9.3.2 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-79 Chapter Blocks/Section 8.3.2.6 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-78 Stakeholder and Concern SysML 1.0 SysML 1.1 Closed; No Change closed
SYSML11-77 Section: 8.3.1.2 Internal Block Diagram Extensions SysML 1.0 SysML 1.1 Resolved closed
SYSML11-76 Section 7.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-75 Rate stereotype attribute SysML 1.0 SysML 1.1 Resolved closed
SYSML11-74 Section: 16.2.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-73 Section: 8.3.2.2 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-72 Section: 11.4 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-71 Section: 16.3.2.7 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-70 Section: 9.3.2. SysML 1.0 SysML 1.1 Resolved closed
SYSML11-69 Section: 9.4 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-68 SysML Interactions SysML 1.0 SysML 1.1 Resolved closed
SYSML11-67 Section: 5.1 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-66 SysML:Ports can't be blocks SysML 1.0 SysML 1.1 Resolved closed
SYSML11-65 Section: Appendix E SysML 1.0 SysML 1.1 Resolved closed
SYSML11-64 Address potential points of convergence between MARTE and SysML SysML 1.0 SysML 1.1 Resolved closed
SYSML11-63 Section: 8/3 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-84 08 Blocks, 8.3.2.9 Unit, 8.3.2.10 ValueType SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-62 SysML specification for containment relationship SysML 1.0 SysML 1.1 Resolved closed
SYSML11-61 SysML dimensions SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-60 SysML -- Fix for Fig 9.4 p70. SysML 1.0 SysML 1.1 Resolved closed
SYSML11-59 8.3.1.3 UML Diagram Elements not Included in SysML Block Definition Diagram SysML 1.0 SysML 1.1 Resolved closed
SYSML11-58 optional parameter section SysML 1.0 SysML 1.1 Resolved closed
SYSML11-57 PropertySpecificType concept is highly ineffective and suboptimal SysML 1.0 SysML 1.1 Resolved closed
SYSML11-56 Wrong ends of Allocate relationship used in Allocated definition SysML 1.0 SysML 1.1 Resolved closed
SYSML11-48 Requirements are abstract SysML 1.0 SysML 1.1 Resolved closed
SYSML11-47 Question on PropertySpecificType SysML 1.0 SysML 1.1 Resolved closed
SYSML11-46 Section: 8.3.2 Unit/Dimension Notation SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-45 Section: Annex A: Diagrams SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-44 Section: 16 Requirements SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-43 Section: 8.3.2.8 ValueType SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-55 View as Package extension is very bad idea SysML 1.0 SysML 1.1 Resolved closed
SYSML11-54 <> SysML 1.0 SysML 1.1 Resolved closed
SYSML11-53 Mixed action and activity concepts SysML 1.0 SysML 1.1 Resolved closed
SYSML11-52 Constraint parameter notation conflicts with UML private ports notation SysML 1.0 SysML 1.1 Resolved closed
SYSML11-51 Association branching is not defined in UML SysML 1.0 SysML 1.1 Resolved closed
SYSML11-50 Uppercase/lowercase problems SysML 1.0 SysML 1.1 Resolved closed
SYSML11-49 <> is displayed as dependency (in examples) SysML 1.0 SysML 1.1 Duplicate or Merged closed
SYSML11-42 Section: 16 Requirements SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-41 Section: 11.3.1.1 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-40 Section: Chapter 7-17 SysML 1.0 SysML 1.1 Resolved closed
SYSML11-39 Namespace compartment for blocks SysML 1.0 SysML 1.1 Resolved closed
SYSML11-38 Section: 11.3.2.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-37 Section: Appendix B SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-29 Section: Annex A SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-28 Section: 17.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-27 Section: 11 Activities SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-26 Section: 11 Actibities SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-25 Chapter 8, Blocks, instance specifications for default values SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-24 Section: 6.1 Levels of Formalism SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-10 SysML: Missing arrow on figure 16.8 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-9 SysML: Interfaces on Flow Ports SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-8 SysML: Use Cases SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-7 Section: Requirements - Figure 16.1 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-6 Section: Ports and Flows - Behavioral flow ports SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-5 Section: Blocks - BOM properties SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-36 SysML doesn't explicitly support the modeling of alternative models SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-35 Section 16.3.2.3 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-34 15.2.1Representing Allocation on Diagrams SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-33 7.1 Overview SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-32 Constraint parameter stereotype SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-31 Figure 17.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-30 Section: figure 17.6 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-16 Section: 9.3.2.8 ItemFlow SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-15 Semantic of default value in the scope of a DistributedProperty SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-14 constraints on viewpoint, 7.3.2.5 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-13 Table 14.1 Use Case Diagram SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-12 SysML:Architecture SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-11 SysML: << and >> vs < and > SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-23 Section: 9, 16, C SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-22 SysML: nout-->inout SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-21 Section: 7.3.2.5 Viewpoint SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-20 Section: Annex G SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-19 Section: Appendix B.4.5 SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-18 How to use property specific types for atomic flow ports? SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-17 Section: 16.3.2.4 RequirementRelated (from Requirements) SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-4 Section 16.3.1.1 SysML 1.0b1 SysML 1.1 Closed; No Change closed
SYSML11-3 constraints section 9.3.2.4 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-2 Section 16.4.2 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML11-1 Page 16 SysML 1.0b1 SysML 1.1 Resolved closed
SYSML14-40 Signal flow property description (§9.3.2.7) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-39 notation for inherited features SysML 1.3 SysML 1.4 Resolved closed
SYSML14-38 Addign a Behavior Compartment for Blocks SysML 1.3 SysML 1.4 Resolved closed
SYSML14-37 Missing/wrong elements in diagram table (InformationFlows) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-36 QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of unit SysML 1.3 SysML 1.4 Resolved closed
SYSML14-35 View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g)) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-34 SysML ISO-80000-1 libraries need update per 18269, 18435 and 18681 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-33 Navigation through non-properties SysML 1.3 SysML 1.4 Resolved closed
SYSML14-32 SysML: Unts and QualityKind SysML 1.3 SysML 1.4 Resolved closed
SYSML14-31 QUDV's support for measurement scales is impractical SysML 1.3 SysML 1.4 Resolved closed
SYSML14-30 View and Viewpoint Property Limitations (from Issue 18391 a) and f)) SysML 1.3 SysML 1.4 Resolved closed
SYSML14-29 Refine relationship contextualization SysML 1.3 SysML 1.4 Resolved closed
SYSML14-28 Activity model library package SysML 1.3 SysML 1.4 Resolved closed
SYSML14-27 9.3.2.4 direction of ports and their notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-26 Use of "inherited method" in section 9.3.2.4 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-25 QUDV Unit/QuantityKind name redundancy SysML 1.3 SysML 1.4 Resolved closed
SYSML14-24 propertyPath property should be defined once and reused SysML 1.3 SysML 1.4 Resolved closed
SYSML14-23 Conjugation of full ports question SysML 1.3 SysML 1.4 Resolved closed
SYSML14-22 SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit SysML 1.3 SysML 1.4 Resolved closed
SYSML14-21 N-ary Allocation needs better definition, or deletion SysML 1.3 SysML 1.4 Resolved closed
SYSML14-20 ControlOperator stereotype should also extend the CallBehaviorAction metaclass SysML 1.3 SysML 1.4 Resolved closed
SYSML14-19 Requirements should be disallowed from typing other elements SysML 1.3 SysML 1.4 Resolved closed
SYSML14-18 SysML Issue: State Machine Notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-17 SysML Issue: SysML Issue: Activitiy Switched on diagrams SysML 1.3 SysML 1.4 Resolved closed
SYSML14-16 SysML Issue Lower bounds on multiplicity not consistent with diagram SysML 1.3 SysML 1.4 Resolved closed
SYSML14-15 Wrong compartment names SysML 1.3 SysML 1.4 Resolved closed
SYSML14-14 Full ports compartment SysML 1.3 SysML 1.4 Resolved closed
SYSML14-13 Figure 9.8 - can roles be ports?? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-12 Figure 9.7 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-11 9.3.2.10 InvocationOnNestedPortAction SysML 1.3 SysML 1.4 Resolved closed
SYSML14-10 9.3.2.8 FullPort SysML 1.3 SysML 1.4 Resolved closed
SYSML14-9 9.3.2.4 DirectedFeature , constraint 4 - what is inherited method??? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-8 ports with flow properties are displayed the same as flow ports in SysML 1.1? SysML 1.3 SysML 1.4 Resolved closed
SYSML14-7 9.1 InterfaceBlock - unnamed compartment SysML 1.3 SysML 1.4 Resolved closed
SYSML14-6 Table 9.1 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-5 Section 9.3.1.6 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-4 Part 1 of the specification SysML 1.3 SysML 1.4 Resolved closed
SYSML14-3 Issues with XMI for SysML 1.3 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-48 Deprecated Elements update for Views and U&QK SysML 1.3 SysML 1.4 Resolved closed
SYSML14-47 Align initial clauses with UML 2.5 SysML 1.3 SysML 1.4 Resolved closed
SYSML14-46 Expanded Usage Examples for Viewpoints SysML 1.3 SysML 1.4 Resolved closed
SYSML14-45 Concern Relation Limitations SysML 1.3 SysML 1.4 Resolved closed
SYSML14-44 Annex A corrections SysML 1.3 SysML 1.4 Resolved closed
SYSML14-43 SysML DI SysML 1.3 SysML 1.4 Resolved closed
SYSML14-42 Any notation available for internal parts should apply to ports SysML 1.3 SysML 1.4 Resolved closed
SYSML14-41 Wrong quantityKind for unit radian SysML 1.3 SysML 1.4 Resolved closed
SYSML14-2 Addition of derived property notation SysML 1.3 SysML 1.4 Resolved closed
SYSML14-1 Constraint Blocks cannot have parameters SysML 1.3 SysML 1.4 Resolved closed
SYSML13-60 sentence introduced in §9.1 by the resolution to issue #16280 is confusing SysML 1.2 SysML 1.3 Resolved closed
SYSML13-59 Wrong multiplicity for Requirement in stereotype description SysML 1.2 SysML 1.3 Resolved closed
SYSML13-58 Rate does not support the examples SysML 1.2 SysML 1.3 Resolved closed
SYSML13-57 Improvements to QUDV for SysML v1.3 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-56 InvocationOnNestedPortAction and TriggerOnNestedPort SysML 1.2 SysML 1.3 Resolved closed
SYSML13-55 Provided and required feature abbreviations SysML 1.2 SysML 1.3 Resolved closed
SYSML13-54 Owning block terminology SysML 1.2 SysML 1.3 Resolved closed
SYSML13-53 Broadcasting along connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-52 Events for property value changes SysML 1.2 SysML 1.3 Resolved closed
SYSML13-51 Contextualized item flows SysML 1.2 SysML 1.3 Resolved closed
SYSML13-50 Proxy port owning block definition should refer to internal structure SysML 1.2 SysML 1.3 Resolved closed
SYSML13-49 Association decomposition in diagram element tables SysML 1.2 SysML 1.3 Resolved closed
SYSML13-48 Item flow property values SysML 1.2 SysML 1.3 Resolved closed
SYSML13-47 Clarify open and closed meaning of port types vs other property types SysML 1.2 SysML 1.3 Resolved closed
SYSML13-46 Binding connectors may not have constraint parameters on any end SysML 1.2 SysML 1.3 Resolved closed
SYSML13-45 Full ports should not be conjugated SysML 1.2 SysML 1.3 Resolved closed
SYSML13-44 Internal fanout from proxy ports should be clarified SysML 1.2 SysML 1.3 Resolved closed
SYSML13-43 Proxy ports should not have connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-42 Flow properties on blocks typing internal parts SysML 1.2 SysML 1.3 Resolved closed
SYSML13-41 Non-behavioral ports on behavioral ports SysML 1.2 SysML 1.3 Resolved closed
SYSML13-40 TriggerOnNestedPort refers to onPort instead of port SysML 1.2 SysML 1.3 Resolved closed
SYSML13-39 InvocationOnNestedPortAction and TriggerOnNestedPort notation not extended SysML 1.2 SysML 1.3 Resolved closed
SYSML13-38 Ports that have behavior ports should be behavioral SysML 1.2 SysML 1.3 Resolved closed
SYSML13-37 Flow property semantics only defined for external connectors SysML 1.2 SysML 1.3 Resolved closed
SYSML13-36 Block shown as metaclass SysML 1.2 SysML 1.3 Resolved closed
SYSML13-35 Owning block undefined SysML 1.2 SysML 1.3 Resolved closed
SYSML13-34 Internal and external connectors undefined SysML 1.2 SysML 1.3 Resolved closed
SYSML13-33 onNestedPort should enable sending directly to target SysML 1.2 SysML 1.3 Resolved closed
SYSML13-32 Provided / required operations & receptions SysML 1.2 SysML 1.3 Resolved closed
SYSML13-31 Sample problem using deprecated conjugated port notation SysML 1.2 SysML 1.3 Resolved closed
SYSML13-30 Ownership of item flow properties SysML 1.2 SysML 1.3 Resolved closed
SYSML13-29 Clarifications to flow port resolution SysML 1.2 SysML 1.3 Resolved closed
SYSML13-28 Connectors should not link ports in block definition diagram elements SysML 1.2 SysML 1.3 Resolved closed
SYSML13-27 Remove colons from item flow classifiers in decomposition examples SysML 1.2 SysML 1.3 Resolved closed
SYSML13-26 Flow property compatibility rules should not be dependent on item flow SysML 1.2 SysML 1.3 Resolved closed
SYSML13-25 Clarify that item flow decomposition examples are not methodology SysML 1.2 SysML 1.3 Resolved closed
SYSML13-24 Water association decomposition example should be in ports SysML 1.2 SysML 1.3 Resolved closed
SYSML13-23 Missing cross references in Deprecated Elements Annex SysML 1.2 SysML 1.3 Resolved closed
SYSML13-22 Deprecated elements package SysML 1.2 SysML 1.3 Resolved closed
SYSML13-21 typo in diagram C. 15 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-20 Test Context appears in XMI but not in Profile Spec SysML 1.2 SysML 1.3 Resolved closed
SYSML13-19 Clarification when Allocated Stereotype is applied SysML 1.2 SysML 1.3 Resolved closed
SYSML13-18 Claify partWithPort vs. NestedConnectorEnd SysML 1.2 SysML 1.3 Resolved closed
SYSML13-17 NestedConnectorEnd propertyPath should be non-unique SysML 1.2 SysML 1.3 Resolved closed
SYSML13-16 partWithPort change from UML needs to be clearly stated SysML 1.2 SysML 1.3 Resolved closed
SYSML13-15 NestedConnectorEnd constraints SysML 1.2 SysML 1.3 Resolved closed
SYSML13-14 NestedConnectorEnd constraints refer to metaclass SysML 1.2 SysML 1.3 Resolved closed
SYSML13-13 Appendix F out of date SysML 1.2 SysML 1.3 Resolved closed
SYSML13-12 Define the SysML profile as referencing UML and replace the UML4SysML subset with OCL constraints SysML 1.2 SysML 1.3 Resolved closed
SYSML13-11 SysML Issue based on UML 15370 -- Package has optional URI SysML 1.2 SysML 1.3 Resolved closed
SYSML13-10 SysML Issue based on UML 14062 -- Stereotypes/keywords and upper/lowercase SysML 1.2 SysML 1.3 Resolved closed
SYSML13-9 SysML 1.2 - Blocks SysML 1.2 SysML 1.3 Resolved closed
SYSML13-8 Structure Compartment shows blocks instead of parts SysML 1.2 SysML 1.3 Resolved closed
SYSML13-7 SysML 1.2, ch 12 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-6 SysML 1.2 Issues: Missing constraint on Rationals SysML 1.2 SysML 1.3 Resolved closed
SYSML13-5 SysML 1.2 Issues: Definition of Overwrite SysML 1.2 SysML 1.3 Resolved closed
SYSML13-4 SysML 1.2 Issues: Activity's sub-activities should be able to have mandatory multiplicity SysML 1.2 SysML 1.3 Resolved closed
SYSML13-3 SysML 1.2 Issues: Structure compartment wrong in spec SysML 1.2 SysML 1.3 Resolved closed
SYSML13-2 SysML 1.2 Section 16.4.4 SysML 1.2 SysML 1.3 Resolved closed
SYSML13-1 properties allocatedFrom and allocatedTo should be capitalized SysML 1.2 SysML 1.3 Resolved closed
SYSML12-27 Representing multiple item flows on the same connector SysML 1.1 SysML 1.2 Duplicate or Merged closed
SYSML12-26 The information in Annex D regarding AP233 needs to be updated SysML 1.1 SysML 1.2 Resolved closed
SYSML12-25 Example figures in chapters are redundant with Annex B sample problem SysML 1.1 SysML 1.2 Resolved closed
SYSML12-24 Notation for multiple item flows SysML 1.1 SysML 1.2 Resolved closed
SYSML12-23 Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct SysML 1.1 SysML 1.2 Resolved closed
SYSML12-22 Using composite association between activities SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-21 Chapter 7.3.1.1 Update comment stereotype diagram extension SysML 1.1 SysML 1.2 Resolved closed
SYSML12-43 Constraining a decomposition hierarchy SysML 1.1 SysML 1.2 Resolved closed
SYSML12-42 Extending Ports to Support Non-flow Properties SysML 1.1 SysML 1.2 Resolved closed
SYSML12-41 Including Property Notation for Redefinition and Subsetting SysML 1.1 SysML 1.2 Resolved closed
SYSML12-40 Including Behavior Port Notation SysML 1.1 SysML 1.2 Resolved closed
SYSML12-39 Streamlined notation for representing system variance SysML 1.1 SysML 1.2 Resolved closed
SYSML12-38 Ambiguous Block Hierarchy SysML 1.1 SysML 1.2 Resolved closed
SYSML12-37 Non-atomic flow ports use property type incorrectly SysML 1.1 SysML 1.2 Resolved closed
SYSML12-36 15.3.2.2 Allocated(from Allocations) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-35 Wrong type in fig. 15.11 SysML 1.1 SysML 1.2 Resolved closed
SYSML12-20 Connector Property value text. SysML 1.1 SysML 1.2 Resolved closed
SYSML12-19 Participant Property constraint #6 not correct. SysML 1.1 SysML 1.2 Resolved closed
SYSML12-18 Fig. 11.10: Pin of ControlOperator SysML 1.1 SysML 1.2 Duplicate or Merged closed
SYSML12-17 "trigger[guard]\activity" should be "trigger[guard]/activity" SysML 1.1 SysML 1.2 Resolved closed
SYSML12-16 Merge UML DataType into SysML ValueType SysML 1.1 SysML 1.2 Resolved closed
SYSML12-15 Lack of Structured Activity Node and other Activity features Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-14 Use cases in SysML are more similar to Requiremetns than Behavioral diagrams SysML 1.1 SysML 1.2 Resolved closed
SYSML12-13 Parametrics and Depletable Stores SysML 1.1 SysML 1.2 Resolved closed
SYSML12-12 SysML synchronization with UML/XMI version updates Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-11 Ambigous line crossings SysML 1.1 SysML 1.2 Resolved closed
SYSML12-10 SysML/Modelica Integration Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-9 Port Decomposition of a Flow Specification Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-8 Section: 11.3.2 Inability to name interruptible activity regions SysML 1.1 SysML 1.2 Resolved closed
SYSML12-7 Section: 4.2, 11.2.1 SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-6 Section: 11.3.1.1, 11.3.1.4, 11.4 SysML 1.1 SysML 1.2 Resolved closed
SYSML12-34 Ports use property type incorrectly SysML 1.1 SysML 1.2 Resolved closed
SYSML12-33 Overly restrictive statement regarding ports in blocks chapter SysML 1.1 SysML 1.2 Resolved closed
SYSML12-32 SysML RTF: 11.4 Activity Usage Sample: ControlOperator has regular pins (2) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-31 UML4SysML: Architecture & Compliance with UML subset SysML 1.1 SysML 1.2 Resolved closed
SYSML12-30 SysML Issues based on UML 13080 New proposal for conjugate types for port SysML 1.1 SysML 1.2 Resolved closed
SYSML12-29 SysML issue based on UML Issue 11160: Namespace URI for Standard Profile(s) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-28 SysML Issue based on UML Issue 10044: Profile Structure Diagrams are missing from Annex A SysML 1.1 SysML 1.2 Resolved closed
SYSML12-5 Section: 9.3.2.4 Constraint about "in" flow properties SysML 1.1 SysML 1.2 Resolved closed
SYSML12-4 More than one constraint block of the same type in a parametric diagram SysML 1.1 SysML 1.2 Resolved closed
SYSML12-3 use of derived in Requirements SysML 1.1 SysML 1.2 Resolved closed
SYSML12-2 11.4 Activity Usage Sample: ControlOperator has regular pins SysML 1.1 SysML 1.2 Resolved closed
SYSML12-1 Section: 11.3.1.1 Activity in bdd SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-44 Typing Flow Properties and Item Properties as Enumerations SysML 1.1 SysML 1.2 Resolved closed

Issues Descriptions

Nested diagrams in SysML

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Are nested diagrams allowed in SysML?

    I could not find any description that it is allowed. However, figure E.31 shows an example of nested diagrams: a parametric diagram is shown in a block definition diagram.

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 10:02 GMT
  • Updated: Thu, 18 Jan 2018 10:02 GMT

Diagram guidelines uses excluded UML element

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Appendix A.2 Guidelines (for Diagrams) says:

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

    However, the artifact model element is excluded from SysML and cannot be used (see table 4.1).

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 09:55 GMT
  • Updated: Thu, 18 Jan 2018 09:55 GMT

Binding connectors in internal block diagrams must always show the keyword

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    According to table 8.4 it is allowed to show a binding connector without keyword <<equal>>. In that case it is identical with the normal Connector and makes the diagram ambiguous. The keyword should be mandatory.

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 09:47 GMT
  • Updated: Thu, 18 Jan 2018 09:47 GMT

Binding connectors have no keyword syntax in parametric diagrams

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    According to table 10.2. a binding connector in a parametric diagram is depicted as a solid line without a keyword.

    Figure E.31 shows a binding connector in a parametric diagram with keyword <<equal>>.

    I propose to remove the keyword in figure E.31 and to add a section below 10.3.1.2 Parametric Diagram to say that the binding connector keyword is not shown in parametric diagrams.

  • Reported: SysML 1.5 — Thu, 18 Jan 2018 09:33 GMT
  • Updated: Thu, 18 Jan 2018 09:33 GMT

Change keyword of binding connector from "equal" to "="

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The keyword "equal" needs a lot of space in a diagram. It would be better to have shorter notation for binding connectors.

    The proposal is to use the equal sign = instead of the keyword with guillements <<equal>>.

  • Reported: SysML 1.5 — Wed, 17 Jan 2018 15:55 GMT
  • Updated: Thu, 18 Jan 2018 09:17 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: Wed, 17 Jan 2018 16:12 GMT
  • Attachments:

Clarification of typing a binding connector


Is <> keyword (or stereotype) on binding connectors is part of SysML notation?

  • Key: SYSML16-90
  • Legacy Issue Number: 17373
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Is <<equal>> keyword (or stereotype) on binding connectors is part of SysML notation? Figure 9.7 Usage example of proxy and full ports

  • Reported: SysML 1.4 — Thu, 17 May 2012 04:00 GMT
  • Updated: Wed, 17 Jan 2018 15:56 GMT

Binding Connector should not be typed

  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The Specification says

    A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.

    What would be the meaning of an Association used as a type for this Connector? I fail to see one. Should there be a Constraint, that doesn't allow a type for a Binding Connector?

    Suggestion
    Add following Constraint to the Binding Connector definition
    inv: type = null

  • Reported: SysML 1.4 — Fri, 26 Feb 2016 17:33 GMT
  • Updated: Tue, 19 Dec 2017 12:09 GMT

Section: Generalization of stereotyped elements

  • Key: SYSML16-26
  • Legacy Issue Number: 12255
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The generalization of model elements, e.g. blocks, does only affect the instances (from Generalization definition: Each instance of the specific classifier is also an indirect instance of the general classifier.). Doesn't that mean that stereotypes of a block and it's properties are not inherited by sub-blocks? If yes all informations about flow ports, units and so on get lost. They are not inherited by the sub-blocks.

  • Reported: SysML 1.0 — Sun, 2 Mar 2008 05:00 GMT
  • Updated: Thu, 14 Dec 2017 16:50 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: Thu, 14 Dec 2017 16:46 GMT

Equal sign for binding connector

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Would be useful to siupport an equal sign (=) for binding connectors. The current keyword is fine, but not very compact.

  • Reported: SysML 1.5 — Thu, 14 Dec 2017 16:35 GMT
  • Updated: Thu, 14 Dec 2017 16:35 GMT

Property Based Requirements

  • Key: SYSML16-84
  • 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: Thu, 14 Dec 2017 15:23 GMT

Semantics consistency of conjugated behavior ports

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

    Per the definition of behavior proxy ports, they have their owner for value. This implies that a classifier typing a port is a classifier for the owner of the port as well. However, when that classifier specifies directed features or flow properties, these feature specifications shall be interpreted so that their directions are reverted if the port is conjugated (isConjugated=true). The point is that, if the owner is not itself a port, there is no means to specify that such an interpretation applies. Thus, assuming one needs to refer to the owner as the instance realizing the port, it will be required to explicitly use (and then model) a classifier specifying the corresponding feature in the opposite direction. This makes the useful conjugation concept unusable in practice.

    The implementation of the conjugation concept should be modified so that it is not limited to port and applicable to block definitions as well.

  • Reported: SysML 1.4 — Wed, 25 Sep 2013 04:00 GMT
  • Updated: Thu, 14 Dec 2017 13:13 GMT

Allow a Requirement to be contained on Any Diagram

  • Status: open  
  • Source: Office of the Secretary of Defense ( Laura Hart)
  • Summary:

    Strict implementation of a Requirement, which is based on a Class, restricts the expected usage of a requirement on diagrams that do not allow the visualization of a class. Not all tools enforce this, but those that do (MD), restrict the desired approaches to addressing requirements traceability and communication.

  • Reported: SysML 1.5 — Thu, 7 Dec 2017 00:44 GMT
  • Updated: Thu, 7 Dec 2017 00:44 GMT

Constraints for Refine and Trace can be improved

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Refine constraint#1 states:

    The Refine stereotype shall only be applied to dependencies

    and Refine constraint#2 states:

    Dependencies with a Refine stereotype or one of its specializations applied shall have exactly one client and one supplier.

    • SysML::Refine specializes StandardProfile::Refine that extends UML::Abstraction. So the constraints should refer to UML::Abstraction rather than to UML::Dependency
    • constraint#1 could be replaced by a redefinition

    The same with the SysML::Trace stererotype

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 08:46 GMT
  • Updated: Thu, 30 Nov 2017 16:52 GMT

The constraint#6 of TriggerOnNestedPort could be replaced by a redefinition

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The constraint#6 of TriggerOnNestedPort could be advantageously replaced by making base_Trigger a redefinition of base_Element property

  • Reported: SysML 1.5 — Wed, 13 Sep 2017 06:37 GMT
  • Updated: Thu, 30 Nov 2017 16:34 GMT

The statement of TriggerOnNestedPort constraint#5 is wrong

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The constraint#5 of TriggerOnNestedPort states:


    The type of the port at the last position of the onNestedPort list must own or inherit the port of the stereotyped invocation action.

    This constraint should refer to the stereotyped trigger.

  • Reported: SysML 1.5 — Wed, 13 Sep 2017 06:33 GMT
  • Updated: Thu, 30 Nov 2017 16:33 GMT

Incorrect constraint [2] on InterfaceBlock

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

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

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

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Updated: Thu, 30 Nov 2017 12:41 GMT

ItemFlow constraint#1 implicilty contrains ItemFlow to rely on a binary relation

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    ItemFlows constraint#1 implicitly implies that the corresponding InformationFlow has no more than one target and one source:

    A Connector or an Association, or an inherited Association shall exist between the source and the target of the
    InformationFlow.

    However this is not explicitly stated. Constraint#1 should be improved or a specific constraint shall be added.

  • Reported: SysML 1.5 — Tue, 12 Sep 2017 13:45 GMT
  • Updated: Thu, 23 Nov 2017 16:57 GMT

Allocate constraint#1 could be replaced by a redefinition

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Allocate constraint#1 states:

    The Allocate stereotype shall only be applied to abstractions

    Could be removed if its base_Abstraction property redefines the base_DirectedRelationship property it inherits from DirectedRelationship
    PropertyPath

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 09:14 GMT
  • Updated: Thu, 23 Nov 2017 16:31 GMT

The statement of TriggerOnNestedPort constraint#4 is not appropriate

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The TriggerOnNestedPort constraint#4 is stated:

    The first constraint of ElementPropertyPath shall apply to onNestedPort

    Such a reference to another constraint that, in addition, requires substituting words in order to be contextualized is not appropriate. It shall be properly stated in a straightforward way.

  • Reported: SysML 1.5 — Wed, 13 Sep 2017 06:25 GMT
  • Updated: Thu, 23 Nov 2017 16:30 GMT

Constraint#5 InvocationOnNestedPortAction could be replaced by a redefinition

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    the constraint#5 of InvocationOnNestedPortAction stereotype states:


    InvocationOnNestedPortAction shall only be applied to invocation actions

    This is because it inherits from ElementPropertyPath the ability to be potentially applied to any UML::Element.

    However we could easily restrict this by making its base_InvocationAction property a redefinition of the base_Element property of its parent.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 07:51 GMT
  • Updated: Thu, 23 Nov 2017 16:18 GMT

SysML stereotype constraints should be named rather than numbered

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In the current SysML specification, every constraint defined as part of a stereotype is identified by a number.

    However the ownedRule property is not ordered. So this numbering does not make sense. Using meaningful names for all those constraints - just like UML does - would be more appropriate.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 14:28 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Most constraints are missing their OCL statement

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Only few constraints specified in SysML v1.5 have a corresponding formal OCL statement. Even if not all of them can be expressed using SysML, most of them could. This would help clarifying then and will remove ambiguity that shall remain in their English description.

  • Reported: SysML 1.5 — Thu, 23 Mar 2017 17:18 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Compartment headers are missing in figure 8.10 and 8.11

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The figure 8.10 shows a compartment of the value type Complex without a compartment header. According to table 8.1, it should be labelled with "properties".

    Figure 8.11 shows two blocks with a unlabelled compartment. Add the compartment header "values".

  • Reported: SysML 1.5 — Thu, 31 Aug 2017 11:56 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Incorrect diagram header in figure 8.11

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The diagram header should show the model element type and name.

    bdd [modelLibrary] UnitAndQuantityKind [Unit and QuantityKind library]

  • Reported: SysML 1.5 — Thu, 31 Aug 2017 11:46 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

UnitAndQuantityKind figure missing block keyword

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Figure 8.11 (Model library for Unit and QuantityKind), Unit and QuantityKind are blocks (at least according to the XMI), but they don't
    have the block keyword showing.

  • Reported: SysML 1.5 — Fri, 18 Aug 2017 18:31 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

EndPathMultiplicity constraint#2 uses a wrong name to refer to a stereotype property

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    EndPathMultiplicity constraint#2 states:

    {quotes}
    endPathLower shall be non-negative{quotes}

    However, there is no such property defined for the EndPathMultiplicity stereotype. Obviously, the intent is to constrain EndPathMultiplicity::lower

  • Reported: SysML 1.5 — Thu, 24 Aug 2017 07:36 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

SysML::Block constraint#3 containts an incorrect assertion about UML

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    SysML::Block constraint#3 states the following


    In the UML metamodel on which SysML is built, any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association must [sic] not have a name and may not be defined as a navigable owned end of the association. (While the Property has a “name” property as defined by its NamedElement superclass, the value of the “name” property, which is optional, must be missing.)

    However there is no constraint in UML requiring that ends owned by the association have empty names. SysML can possibly require it but the added value is not obvious. I suggest focusing this constraint on the link between navigability and end ownership:

    Any instance of the Property metaclass that is typed by a block (a Class with the «block» stereotype applied) and which is owned by an Association may not be defined as a navigable owned end of the association.

  • Reported: SysML 1.5 — Thu, 6 Jul 2017 11:49 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

AdjunctProperty constraint#8 can be simplified

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    AdjunctProperty constraint#8 is partly redundant with constraint#3 since both require that the Property on which this stereotype is applied has a composite aggregation when the principal is typed by a CallAction.

    Constraint#8 could be simplified by not requiring it again and by focusing on the type of AdjunctProperties that have CallActions as principals. Also, it should be reworded to avoid using parenthesis.

  • Reported: SysML 1.5 — Thu, 3 Aug 2017 13:45 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

References to UML specification in block constraints are not correct

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The Block constraint [5] quotes the UML specification. The reference to UML specification section 9.3.6 is not correct. The correct chapter number is 11.8.

    The block constraint [9] quotes the UML specification. The reference to UML specification section 9.3.7 is not correct. The correct chapter number is 11.8.

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 08:15 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Remove sentences about qualified associations in clause 8.3.1.3

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Remove the sentences

    "Qualified associations, shown in SysML by an open box at the end of an association path with a property name inside, are
    a specialized feature of UML that specifies how a property value can represent an identifier of an associated target. This
    capability, while useful for data modeling, does not seem essential to accomplish any of the SysML requirements for
    support of systems engineering."

    These sentences are partly incorrect (qualified associations are not shown in SysML), cover only an opinion, and could easily lead to misunderstandings. On the other side it only adds a minimal value.

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 08:02 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Remove the statement about N-ary associations from 8.3.1.3

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Remove the sentence "N-ary associations, shown in UML by a
    large open diamond with multiple branches, can be modeled by an intermediate block with no loss in expressive power." from the specification.

    N-ary associations are still excluded by the second sentence in the clause. The sentence to be removed added a motivation for the exclusion, but the statement "with no loss in expressive power" is not correct.

  • Reported: SysML 1.5 — Tue, 6 Jun 2017 07:52 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Remove [sic] in block constraints

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Remove the string "[sic] " in the constraints on Block.

  • Reported: SysML 1.5 — Mon, 5 Jun 2017 11:22 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Behavior Diagram Element tables imply diagrams can be nodes

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Filed for JD.
    The Diagram Element tables for the behavior chapters are captioned:
    "Graphical nodes included in <behavior> diagrams"
    and each have a row for an entire diagram, rather than just elements of the diagrams. This implies diagrams can be nodes in other diagrams, for example that an activity diagram can be in another activity diagram without an intervening call behavior action, which isn't true.

  • Reported: SysML 1.4 — Fri, 9 Oct 2015 12:55 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Typos/editorials found in the SysML 1.5 specification document


Most diagram headers in document are not consistent with Appendix A, p 189.

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

    The majority of diagrams with frames have problems with their headers.
    The types of problems are as follows:
    1) Just the diagram type (no element name, type, diagram type)
    2) Stereotypes in the header (not in the diagramusage field)
    3) Use of element type not listed in the Appendix (e.g., activity)
    4) Can't tell if the text field is an element name or a diagram name
    5) All text, not just the diagram type, is bold.
    6) Non-obvious element type (block, package, ?)

    These problems make the spec look like it was carelessly made. When the results are ambiguous or unclear, it encourages sloppy modeling by users.

  • Reported: SysML 1.4 — Thu, 5 Nov 2015 22:02 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT


NestedConnectorEnd violates UML "roles" constraint

  • Legacy Issue Number: 19813
  • Status: open  
  • Source: Anonymous
  • Summary:

    UML's constraint "UML::Connector::role" specifies that ConnectorEnds need to point to roles/parts owned by the Connector's structuredClassifier (direct or inherited).

    The specification draft 1.0 contained an explicit statement that SysML relaxed a limited number of the UML constraints ("roles" being one of them). This was e.g. mentioned in 0.11 on page 4 of document ad/2006-03-01.

    In the current 1.4 beta, section 4.4 "Extension Mechanisms" doesn't mention contraint relaxation as one of the applied techniques.

    Moreover, the specification of NestedConnectorEnd (8.3.1.2.6, 8.3.2.11) does not mention this relaxation either.

    Without a formal statement about this relaxation, I would conclude that the SysML spec conflicts with the UML spec.

  • Reported: SysML 1.4 — Tue, 30 Jun 2015 04:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Incorrect statement about UML n-aries

  • Key: SYSML16-69
  • Legacy Issue Number: 16093
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Section 8.3.1.3 (UML Diagram Elements
    not Included in SysML Block Definition
    Diagrams) says "N-ary associations,
    shown in UML by a large open diamond
    with multiple branches, can be modeled
    by an intermediate block with no loss in
    expressive power." An intermediate
    block cannot capture multiplicities that
    would be on an the ends of an n-ary
    association. These multiplicities are
    for the links from end to end, rather
    than from intermediate object to end, as
    they would be with an intermediate
    object. However, intermediate blocks
    can specify the number of links each end
    might participate in for any of the
    other n-1 ends, which is not possible
    with n-ary associations. The
    expressiveness of n-aries and
    intermediate blocks is overlapping,
    rather than equivalent.

  • Reported: SysML 1.2 — Tue, 22 Mar 2011 04:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Compartment labelling rules

  • Key: SYSML16-67
  • Legacy Issue Number: 16057
  • Status: open  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Suggest these compartment rules:

    • Italics
    • Plural
    • All lower case
    • Words separated by spaces
  • Reported: SysML 1.4 — Fri, 11 Mar 2011 05:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Flow properties and activity paramters

  • Key: SYSML16-50
  • Legacy Issue Number: 15176
  • Status: open  
  • Source: Françse ( Caron)
  • Summary:

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

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

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

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

  • Reported: SysML 1.4 — Fri, 16 Apr 2010 04:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Need to have an explicit way to bind flow properties or atomic flow ports to block properties

  • Key: SYSML16-44
  • Legacy Issue Number: 14059
  • Status: open  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    Need to have an explicit way to bind flow properties or atomic flow ports to block properties. Currently section 9.3.2.3 lacks such rules. Such rules would allow a consistent way to relay data via flow ports to the properties of blocks and also would allow a convenient way to transmit values via flow port by changing a value of a property owned by the block.

  • Reported: SysML 1.1 — Wed, 8 Jul 2009 04:00 GMT
  • Updated: Sat, 18 Nov 2017 00:57 GMT

Constraints redundancy in DirectedRelationshipPropertyPath

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The 4 first constraints of DirectedRelationshipPropertyPath are defined as follows:

    [1]sourceContext shall have a value when source is a property, otherwise it shall not have a value.
    [2]targetContext shall have a value when target is a property, otherwise it shall not have a value.
    [3]source shall be a property when sourcePropertyPath has a value.
    [4]target shall be a property when targetPropertyPath has a value.

    #1 implies #3 and #2 implies #4, so #3 and #4 are redundant and should be deleted.

  • Reported: SysML 1.5 — Thu, 10 Aug 2017 12:38 GMT
  • Updated: Thu, 16 Nov 2017 17:11 GMT

Constraint#2 of the InvocationOnNestedPortAction stereotype is invalid

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    InvocationOnNestedPortAction constraint #2 states:

    The port at the first position in the onNestedPort list shall be owned (directly or via inheritance) by a block that types the target pin of the invocation action, or one of the block’s generalizations

    However the InvocationAction metaclass has no "target" pin, only some of its subclasses have.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 07:14 GMT
  • Updated: Thu, 16 Nov 2017 17:09 GMT

BoundReference constraint#3 is unclear

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    BoundReference constraint#3 states the following:

    The role of boundEnd shall be a property accessible by navigation from instances of the block owning the property to which BoundReference is applied, but shall not be the property to which BoundReference is applied, or one that it is related to by redefinition.

    It's not clear what "navigable" means here. Please clarify.

  • Reported: SysML 1.5 — Tue, 8 Aug 2017 15:18 GMT
  • Updated: Thu, 16 Nov 2017 16:36 GMT

Typo in AdjunctProperty Constraint#10

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The constraint#10 of AdjunctProperty is specified by the following sentence, which does not make sense:

    Properties with AdjunctProperty applied that have a Variable or Parameter applied shall have a lower multiplicity the same as or lower than the lower multiplicity of the Variable or Parameter, and an upper multiplicity the same as or higher than the upper multiplicity of the Variable or Parameter.

    In addition the statement could be simplified since this should be extended to any AdjunctProperty for which the principal is a kind of MultiplicityElement

  • Reported: SysML 1.5 — Tue, 8 Aug 2017 12:35 GMT
  • Updated: Thu, 16 Nov 2017 16:23 GMT

Constraint [5] should include specializations of Requirement

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

    Constraint [5] states:

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

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

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

  • Reported: SysML 1.3 — Tue, 5 Feb 2013 05:00 GMT
  • Updated: Thu, 16 Nov 2017 16:19 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: Tue, 7 Nov 2017 23:42 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: Tue, 31 Oct 2017 13:57 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: Wed, 18 Oct 2017 10:57 GMT

9.3.2.4 direction of ports

  • 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, 12 Oct 2017 08:48 GMT

Constraints on Satisfy and Verify should refer to AbstractRequirement

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Constraints owned by either Satisfy or Verify stereotype still refer to the SysML::Requirement stereotype while they should have been modified so that they refer to the AbstractRequirement stereotype added in 1.5

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 09:34 GMT
  • Updated: Mon, 25 Sep 2017 21:27 GMT

Copy constraints #2 and #3 shoud be merged together

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Copy constraint#2 states:

    The text property of the client requirement is constrained to be a read-only copy of the text property of the supplier requirement.

    While Copy constraint#3 states:

    Constraint [2] is applied recursively to all subrequirements.

    They should be merged in one unique constraint so that the requested recursivity could be formally stated in OCL using an helper operation

  • Reported: SysML 1.5 — Thu, 21 Sep 2017 08:33 GMT
  • Updated: Mon, 25 Sep 2017 21:25 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: Mon, 25 Sep 2017 21:20 GMT

Probability constraint#1 is ambiguous

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Probability constraint#1 states:


    The «probability» stereotype shall only be applied to activity edges that have decision nodes or object nodes as sources, or to output parameter sets.

    This is ambiguous since ParameterSets have no direction, only their parameters have.

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 07:48 GMT
  • Updated: Thu, 21 Sep 2017 15:48 GMT

Do not move deprecated elements


ItemFlow constraint#3 does not make sense in every case

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    ItemFlow constraint#3 makes the implicit assumption that both source and target of an ItemFlow are properties:

    itemProperty shall be a property of the common (possibly indirect) owner of the source and the target.

    However they can be Classifiers as well.

  • Reported: SysML 1.5 — Tue, 12 Sep 2017 14:06 GMT
  • Updated: Thu, 21 Sep 2017 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: Thu, 21 Sep 2017 14:42 GMT

9.3.2.4 direction of ports and their notation (second issue)

  • 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, 21 Sep 2017 14:29 GMT

Flow property description: incorrect wording (§9.3.2.7)

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

    The description of the semantics related to the direction (in, ou, inout) incorrectly refers to contained “blocks” instead of properties and the description for “inout” is inconsistent (cannot be instantiated )

  • Reported: SysML 1.4 — Thu, 12 Sep 2013 04:00 GMT
  • Updated: Thu, 21 Sep 2017 13:59 GMT

Allocate constraint#3 does not make sense

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Allocate constraint#3 states:


    If subtypes of the «allocate» dependency are introduced to represent more specialized forms of allocation, then they shall have constraints applied to supplier and client as appropriate.

    This is neither clear nor verifiable. It should be removed

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 09:20 GMT
  • Updated: Thu, 21 Sep 2017 07:24 GMT

Rate constraint#2 is ambiguous

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Rate constraint#2 states:

    The rate of a parameter shall be less than or equal to rates on edges that come into or go out from pins and parameters nodes corresponding to the parameter

    This is ambiguous since SysML::Rate::rate is typed by UML::InstanceSpecification for which "less than or equal to" is not defined

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 08:49 GMT
  • Updated: Thu, 21 Sep 2017 07:23 GMT

The OCL statement of ConstraintBlock constraint#3 is wrong

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    ConstraintBlock constraint#3 states:


    Any property of a block that is typed by a ConstraintBlock shall have composite aggregation.

    And the following OCL statement is provided


    self.ownedAttribute->forAll(p | p.type.oclIsKindOf(ConstraintBlock) implies p.aggregation = #composite)

    The OCL is invalid and wrong since "self" refers to the stereotype instance while this is the property typed by the ConstraintBlock which is constrained

  • Reported: SysML 1.5 — Thu, 14 Sep 2017 06:52 GMT
  • Updated: Thu, 21 Sep 2017 07:22 GMT


The statement of InvocationOnNestedPortAction constraint#3 is not appropriate

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The InvocationOnNestedPortAction constraint#3 is stated:

    The first constraint of ElementPropertyPath shall apply to onNestedPort

    Such a reference to another constraint that, in addition, requires substituting words in order to be contextualized is not appropriate. It shall be properly stated in a straightforward way.

  • Reported: SysML 1.5 — Thu, 7 Sep 2017 07:23 GMT
  • Updated: Wed, 13 Sep 2017 06:25 GMT

View constraint#3 is incorrect

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    the constraint#3 of the SysML::View stereotype states the following:

    The derived values of the stakeholder attribute shall be the names of the classifiers stereotyped by Stakeholder that are [...]

    However the View::stakeholder attribute is typed by SysML::Stakeolder[*] and not by String, as in SysML versions before 1.4. We probably missed it in 1.4.

  • Reported: SysML 1.5 — Thu, 3 Aug 2017 09:06 GMT
  • Updated: Thu, 7 Sep 2017 14:20 GMT

The type of ParticipantProperty

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SysML spec says:

    The types of participant properties can be elided if desired.

    But constraints says:
    [5] A property stereotyped by ParticipantProperty must have the same type as the property referred to by the end attribute.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:11 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

Update description about extension of UML

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The description on page 12 how SysML extends UML is based on UML 2.4. The package structure of UML has changed from UML 2.4 to UML 2.5. The bullet list must be updated accordingly. For instance SysML::ModelElements does not extend UML classes, but beside others UML common structures.

  • Reported: SysML 1.4 — Thu, 17 Sep 2015 09:02 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

ParticipantProperty keyword

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SysML spec says:
    The keyword «participant» before a property name indicates the property is stereotyped by ParticipantProperty.

    Why and how SysML can redefine how stereotype is represented?
    According the UML spec, stereotype is represented by showing its original name in <<>>.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 18:32 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

Initial values compartment header inconsistent with others

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    SysML compartment headers are usually all lower case with spaces separating words, but for initial values it's "initialValues". Suggest changing it to "initial values".

  • Reported: SysML 1.4 — Fri, 23 Sep 2016 21:38 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT

Block, Constraint [4]: Block-typed properties must be defined by an association is superfluous

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Constraint [4] of a Block says:

    [4] In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association.
    (An inverse end of this association, whether owned by another block or the association itself, must always be
    present so there is always a metamodel element to record the inverse multiplicity of the reference.)

    The referenced constraint in the UML metamodel does not exist. The UML specification says:

    A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not. This convention is not enforced by UML.

    I propose to remove the constraint [4], i.e. to allow to model part properties without an association. The reduces the number of model elements (1 property versus 2 properties + 1 association), makes the model simpler for the model builder and user, and reduces the effort for model maintenance.

    In particular it is valuable when using generalization and redefinition. Without an association an inherited property could simply be redefined. An inherited property defined by an association that should be redefined, requires to create a new association that specializes the association and lots of redefinitions. That makes modeling very cumbersome.

  • Reported: SysML 1.4 — Fri, 12 Feb 2016 09:41 GMT
  • Updated: Sat, 2 Sep 2017 00:06 GMT
  • Attachments:

2017-08-31 Weekly meeting minutes

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Attendees: Julio, Laura, Dave, Conrad, Tim, Rick, Yves
    Agenda:

    • Ballot#5
    • Ballot#6
    • Issue/Resolution discussions

    1 Ballot#5
    Will close Sep 2nd 02:00am CEST. 14 votes out of 20 so far.

    2 Ballot#6
    Will be created: Sep 7th
    Will Open for vote: Oct 5th
    Will Close: Oct 21t

    3 RTF Deadline Extension
    We would like to propose extending this RTF by two cycles (i.e. up to June 2018). We need a motion for that to be voted by the AB at the New Orleans meeting. @Yves-> to send an email to the RTF mailing list to inform about it to see whether there are objections about.

    4 Issue resolutions review
    The following issues (and corresponding resolution proposals) were presented and discussed during this meeting (follow corresponding links for details):
    SYSML16-337, SYSML16-334, SYSML16-331, SYSML16-299, SYSML16-300

    @Yves -> to create a global issue for gathering typos and editorial that will be voted in the last RTF ballot.

    5 Next meeting

    • Online- Thursday Sep 7th, 11am ET.
  • Reported: SysML 1.5 — Thu, 31 Aug 2017 16:05 GMT
  • Updated: Thu, 31 Aug 2017 16:05 GMT

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: Wed, 30 Aug 2017 15:17 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: Thu, 10 Aug 2017 12:44 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: Thu, 3 Aug 2017 08:00 GMT

Clarify if the usage of qualified associations is allowed

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    It seems that the SysML specification wants to exclude the usage of qualified associations. However, it only says that it does not seem to be essential to use them:

    "Qualified associations, shown in SysML by an open box at the end of an association path with a property name inside, are a specialized feature of UML that specifies how a property value can represent an identifier of an associated target. This capability, while useful for data modeling, does not seem essential to accomplish any of the SysML requirements for
    support of systems engineering." (8.3.1.3, SysML 1.5)

    It is still unclear if qualified associations are allowed or not.

  • Reported: SysML 1.5b1 — Wed, 26 Apr 2017 07:35 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Association arrowheads should not be forbidden

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The SysML specification excludes the usage of association arrowheads:

    "The use of navigation arrowheads on an association has been simplified by excluding the case of arrowheads on both ends, and requiring that such an association always be shown without arrowheads on either end." (8.3.1.3, SysML 1.5).

    However, arrowheads are commonly used in SysML modeling. There are also examples of usages in the SysML specification itself, for example, figure D.15.

  • Reported: SysML 1.5b1 — Wed, 26 Apr 2017 07:31 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Block constraint [4] contains a false statement

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Constraint#4 specified for the Block stereotype states the following:
    In the UML metamodel on which SysML is built, a Property that is typed by a block must [sic] be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.)

    However there is no such a constraint in UML metamodel. Firstly, the concept of "block" is not part of UML, and secondly there is not even an equivalent constraint for UML::Properties typed by a UML::Class. Typing a UML::StructuredClassifier::ownedAttribute with a Class is legal

  • Reported: SysML 1.5 — Thu, 26 Jan 2017 09:26 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Keyword signal in reception compartment is superfluous

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The resolution of issue SYSMLR-153 describes the reception compartment of blocks that was not yet covered by SysML. The notation of SYSMLR-153 is identical with the notation defined in the UML specification.

    The signal keyword before the reception is superfluous. The reception compartment already unambiguously depicts that only receptions are shown.

    I propose to remove the keyword <<signal>> from the notation.

  • Reported: SysML 1.4 — Sun, 28 Feb 2016 16:36 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

SysML does not clearly defines how an association defines properties

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    In section 8.3.1.3 the SysML specification excludes the dot notation of the association that shows the ownership of the defined properties.

    But the SysML specification does not specify how the ownership of properties is defined. There are different usages of the association relationship like composition in bdd, actor/use case relationship or in conceptual bdds. Different usages require different ownerships of the defined properties.

    Proposal:
    Define a default and allow the dot notation if the modeler wants to define it differently.

  • Reported: SysML 1.4 — Fri, 5 Feb 2016 12:17 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Activity should not be included as graphical node included in activity diagrams

  • Legacy Issue Number: 19836
  • Status: open  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Table 11.1 includes a set of concrete syntax symbols that are "graphical nodes included in activity diagrams." One of these represents an Activity diagram. Activity diagrams do not include activities as one of the possible nodes in the meta-model. I suggest you remove that line of the table to make is clear that Activity Diagrams do not contain activities.

  • Reported: SysML 1.4 — Thu, 24 Sep 2015 04:00 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Incorrect multiplicity for base_xxx properties of most SysML Stereotypes

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In the current version of SysML.xmi, all the stereotype properties referring to the element to which the stereotype is applied (the so-called "base_xxx" ones) have [0..1] multiplicities, except for the following stereotypes: FlowSpecification (deprecated), FlowPort (deprecated) and TriggerOnNestedPort.

    Basically, these multiplicities shall be [1..1] except for stereotypes that may be applied to more than one metaclass. That is for SysML: TestCase, Rate, Probability and ControlOperator

  • Reported: SysML 1.4 — Wed, 10 Aug 2016 11:01 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

AdjunctProperty principal should be a NamedElement

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

    The specification says:

    Attributes
    • principal : Element [1]

    [2]Properties to which AdjunctProperty applied must have the same name as the principal.

    A name isn't mandatory for an UML Element.

    => principal type should be NamedElement

  • Reported: SysML 1.4 — Thu, 4 Aug 2016 14:25 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

DeriveReqt constraints multiplicity of Client and Supplier

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

    Here are the constraints for DeriveReqt

    [1]The supplier must be an element stereotyped by «requirement» or one of «requirement» subtypes.
    [2]The client must be an element stereotyped by «requirement» or one of «requirement» subtypes.

    DeriveReqt extends Abstraction and an Abstraction can have many NamedElement as Client and Supplier.

    7.3.12 Dependency (from Dependencies)
    client: NamedElement [1..*]
    supplier: NamedElement [1..*]

    Here are some options:

    • add a constraint to restrict to 1 NamedElement in Client and Supplier
    • Stereotype required only on the first NamedElement
    • Stereotype required on all NamedElement
  • Reported: SysML 1.4 — Fri, 20 May 2016 15:06 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

xmi:IDs are not convenient

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The xmi:IDs used in SysML related XMI files we publish are not convenient.
    They are too big and too sensitive to model change.

    We need to come back to something more compact and more robust

  • Reported: SysML 1.4 — Mon, 12 Sep 2016 13:44 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Wrong parameter for Operations in the SysML.xmi

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In the current version of SysML.xmi, none of the operation parameter is serialized with its direction. Which means that they all have the default direction, i.e.: "in". This is of course wrong for all the return parameters. By the way, as serialized, the operations have no return parameter and so no type.

  • Reported: SysML 1.4 — Thu, 11 Aug 2016 13:53 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

RequirementRelated is present in the summary but no more in the document

  • Legacy Issue Number: 19757
  • Status: open  
  • Source: Anonymous
  • Summary:

    RequirementRelated is present in the summary (16.3.2.4) but no more in the document

    => The problem put all the section 16.3.2 in disorder

    Also RequirementRelated is still present (as Deprecated) in the profile I'm working with
    (The one that will be used in eclipse-Papyrus).

  • Reported: SysML 1.4 — Mon, 11 May 2015 04:00 GMT
  • Updated: Wed, 2 Aug 2017 00:51 GMT

Ability for a binding connector to be typed

  • Key: SYSML16-48
  • Legacy Issue Number: 15079
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

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

  • Reported: SysML 1.1 — Sat, 20 Feb 2010 05:00 GMT
  • Updated: Fri, 28 Jul 2017 08:16 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: Thu, 27 Jul 2017 21:15 GMT

2017-07-20 Weekly meeting minutes


The association-like notation is ambiguous

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In our discussion about SYSML16-308, Conrad Bock pointed out that the association-like notation provided by UML is ambiguous.

    See below:

    In the figure below the "size" attribute is not part of an association this is only an "association-like" notation that UML allows. The point is that there in no multiplicity and the opposite side because there is no corresponding role. By the way, multiplicity on this opposite side is not constrained (i.e. it is "0..*") while with a "true" association, multiplicities that are not shown are often interpreted by some reader to be "1..1" (even if the UML specification explicitly say that: "If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model")

    In order to fix this we can either:

    • propose a better notation
    • deprecate this notation
  • Reported: SysML 1.5 — Mon, 10 Jul 2017 07:17 GMT
  • Updated: Wed, 12 Jul 2017 06:53 GMT
  • Attachments:

Proxy port “complete” specification (§ 9.3.2.12):

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

    if a proxy port P1 has a nested proxy port P1::P2 and both are non-behavioral, does it mean that both P1 and P1::P2 must be explicitly connected to internal parts? If P1 is just a logical group of nested proxy ports, there may be no sense to connect P1 per se internally (but it makes sense to connect P1 externally).

  • Reported: SysML 1.4 — Thu, 12 Sep 2013 04:00 GMT
  • Updated: Tue, 4 Jul 2017 00:38 GMT
  • Attachments:

Instance for Initial values

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SysML spec says:
    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.

    There is no reason why instance should be unnamed or must be owned in particular package, the same as blocks are defined in. Opposite, it would be very useful to use named instances and other packages for ownership.

    Proposal : remove both redundant constraints from the text.

  • Reported: SysML 1.4 — Mon, 20 Jun 2016 21:17 GMT
  • Updated: Tue, 13 Jun 2017 09:03 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: Tue, 6 Jun 2017 07:44 GMT