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

SysML RTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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
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-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-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-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-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-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-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-131 Section: 11.3.2.2 ControlOperator UML 2.1.1 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-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-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-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-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-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-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-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-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-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-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-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

Issues Descriptions

09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port

  • Legacy Issue Number: 12222
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Experience modelling a wide range of heterogeneous systems has proven that the representation of logical channels as information flows across connections between flowports nested within standard ports is a very useful idiom. It would help if this possibility is explicitly stated in both 9.3.2.3 FlowPort, 9.3.2.7 Standard Port, and illustrated in specification figures. Example: a software application acquires encoded signals representing physical positon and rotation via a high-level software API to a low-level A./D card in a computer. The software application is connected to an A/D module subject to a contract represented by an Interface provided by a standard port (subject ot a protocol). The flow of information corresponding to logical acquired channels can be well represented as flowports nested within the standard port of the A/D module. This example is illustrated in detail at: http://school.nomagic.com/node/194 It is marked as 'significant' because without this idiom of nesting flowports on standard ports it is impossible or very difficult to model a wide range or real-world systems.

  • Reported: SysML 1.0 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 18:08 GMT

Missing tags in XMI

  • Legacy Issue Number: 12548
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The XMI is missing the tags for declaring the namespace and prefix for serializing instances of the stereotypes

  • Reported: SysML 1.0 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue is resolved by using the same procedures for preparing the published
    artifacts for SysML1.3 as the procedures used for preparing the published
    artifacts for UML2.4.1, including StandardProfileL2/L3.
    Disposition: See issue 15876 for disposition

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

The href should reference the URI for the UML elements

  • Legacy Issue Number: 12547
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The href should reference the URI for the UML elements. This may need the namespace for UML4SysML to match that of UML

  • Reported: SysML 1.0 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    SysML1.3 follows the same process used for publishing the artifacts in the 2.4.1
    series of UML, MOF and XMI where references to elements defined in external
    artifacts use the full document URL of the external artifact. Moreover, there is no
    longer a separate UML4SysML artifact – all references to UML metaclasses are
    in terms of the full document URL to the UML2.4.1 metamodel.
    Disposition: See issue 15876 for disposition

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

type should be cmof:Class not uml:Class

  • Legacy Issue Number: 12546
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    1. The XMI for the SysML has references to the metamodel as follows:

    <packagedElement xmi:type="uml:Stereotype" xmi:id="Rate" name="Rate">
    <ownedAttribute xmi:type="uml:Property" xmi:id="Rate-base_Parameter" name="base_Parameter" association="Parameter_Rate">
    <type xmi:type="uml:Class" href="UML4SysML-metamodel.xmi#Parameter"/>

    The type should be cmof:Class not uml:Class

  • Reported: SysML 1.0 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue is no longer relevant for SysML1.3 since SysML1.3 extends UML2.4.1
    which, altough still a CMOF metamodel, is nonetheless represented as a
    UML2.4.1 model. Therefore, in the SysML1.3 XMI, all references to UML
    metaclasses are in terms of their UML representation, not CMOF.
    Disposition: See issue 15876 for disposition

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

4.2: StandardProfileL2 uses elements not supported by SysML

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

    SysML imports the UML StandardProfileL2. It contains useful stereotypes like modelLibrary. But it also includes stereotypes that extend UML elements that are not supported by SysML like artifact or component. Some stereotypes extend Class. From the viewpoint of SysML they should be an extension of stereotype Block. That's a conflict in the SysML language architecture. Proposal: Remove import of StandardProfileL2 and define a SysML specific standard profile.

  • Reported: SysML 1.0 — Thu, 22 May 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Since SysML1.3 extends UML2.4.1 whose StandardProfileL2 library is published
    as a normative artifact, it is no longer necessary for SysML to define its own
    Trace stereotype; SysML can use StandardProfileL2::Trace instead. However,
    except for StandardProfileL2::Metaclass which is used to denote classes that are
    part of a metamodel, the SysML specification does not specifically identify any
    other stereotype from StandardProfileL2 in its scope.
    Within the strict definition of SysML where only the metaclasses in the
    UML4SysML subset are allowed, several stereotypes from StandardProfileL2
    cannot be used with SysML because they extend classes outside the
    UML4SysML subset. Thus, File, Document, Executable, Library, Script and
    Source are excluded because they extend Artifact, and Entity, Implement,
    Process, Service and Subsystem are excluded because they extend Component.
    See resolution to issue 15876 for further details.
    Disposition: See issue 15876 for disposition

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

Section: 08 Blocks, Annex B, Annex C

  • Legacy Issue Number: 12435
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    It is not enough to refer simply to (p.180): 'The «system» and «external» stereotypes are user defined, not specified in SysML,' Although already raised as Issue 12257, this new Issue submission (by a different submitter) makes the constructive suggestion that the 'user defined' stereotypes by defined in non-normative extension Section in the Annex C. It is not acceptable that a specification dedicated to systems engineering does not even have at least a well-defined non-normative definition of a <<system>> and <<system context>> ! These need to be upgraded to a non-normative Annex, and then introduced properly through the example. I see no reason why the figures should not use non-normative stereotypes as long as they are defined in an Annex and clearly. This is not the case for <<system context>>, <<system>>, <<external>>, <<domain>>, <<subsystem>>, yet these are truly crucial for even basic systems engineering, and the examples (which use them well) make little sense without them. There is a very nice summary of C.2 Requirements Diagram Extensions. and those requirement categories have proved very useful already. I have made a small summary and guide here: http://school.nomagic.com/node/396 Block extensions (non-normative) As recommended through SysML1.0 examples: * «system» top-level block to be used in a system context * «subsystem» grouping (usually physical) within a system * «external» outside the top-level system (yet affecting it) * «domain» provides a common context for a system and externals * «system context» a particular context for a system and externals Note my definitions for <<domain>> vs. <<system context>>. I suggest that at least «system context» should have a tag: system:<<system>>[1] <<domain>> could then extend <<system context>>. Visit also: http://school.nomagic.com/node/415

  • Reported: SysML 1.0 — Sat, 10 May 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    As noted by the issue,Section B.4.2.1, Internal Block Diagram - Setting Context,
    includes the following sentence:
    The «system» and «external» stereotypes are user defined, not specified
    in SysML, but help the modeler to identify the systemof interest relative to
    its environment.
    Many forms of non-normative stereotypes could be developed to distinguish
    particular user modeling distinctions and practices. The issue itself notes possibly
    different stereotypes (such as «domain») than those used in the example. The
    availability of user-defined stereotypes to make such distinctions is clearly
    indicated by the example.Rather than incorporating a particular set of
    stereotypes directly in the SysML specification, the original submission
    deliberately left these open-ended to support possibly different modeling needs.
    Multiple sets of these stereotypes could be developed as part of separately
    distributed model libraries. Since the SysML specification is primarily concerned
    with the definition of the core SysML language, the omission of further detailed
    specification of user-model stereotypes is in keeping with the scoping decisions
    of the material to be maintained as a direct part of the SysML specification.
    Disposition: Closed, no change

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

NestedConnectorEnd multiplicity typo in Fig 8.5

  • Legacy Issue Number: 12377
  • Status: closed  
  • Source: Georgia Institute of Technology ( Russell Peak)
  • Summary:

    There appears to be a typographical error in Fig 8.5 re: the multiplicity of a NestedConnectorEnd propertyPath. This figure says [2..*], whereas Section 8.3.2.6 says [1..*]. === Specifics: In the SysML 1.0 document (formal/2007-09-01), Fig 8.5 entitled "Abstract syntax extensions for SysML connector ends" shows this for NestedConnectorEnd: - propertyPath: Property [2..*] (ordered) However, Section 8.3.2.6 NestedConnectorEnd has a different multiplicity: - propertyPath: Property [1..*] (ordered) Section 8.3.2.6 seems to be the correct version, as it provides further explanation including stating "The connector end property is not included in the propertyPath list, but instead is held by the role property of the UML ConnectorEnd metaclass.", which is consistent with a multiplicity of [1..*]. The severity of this issue is deemed "Significant" because tool implementations that follow the figure versus ones that follow the section text (which has already occurred) will be incompatible. === Proposed Resolution: Change the multiplicity in Fig 8.5 from [2..*] to [1..*].

  • Reported: SysML 1.0 — Thu, 10 Apr 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Correct the multiplicity in Fig 8.5.

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

p.46 under 8.3.2.4 DistributedProperty

  • Legacy Issue Number: 12365
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    On p.46 under 8.3.2.4 DistributedProperty it is stated that: '[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.' There are however, as far as I can tell, no examples of a DistributedProperty or specialisation thereof applied to a value property that is not within a block. A candidate examp[le might include a variation on a Complex <<ValueType>> (cf. Figure 8.7 - Model Library for Blocks) with distributions applied to the real and imaginary parts (being represented by value properties, and thus admitting application of DistributedProperty stereotype, or substereotype).

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Following is the discussion from a previous deferred resolution by the SysML 1.1
    RTF:
    There are many specialized cases of SysML diagram and model elements
    which are not currently covered either by usage examples in the
    specification chapters or in Annex B, Sample Problem. A candidate
    example as suggested, either by itself or included in other examples,
    could be considered in future revisions of the specification.
    This is one of many specialized usage cases not covered by examples in the
    SysML specification. Examples of DistributedProperty stereotypes applied to
    elements of a structured ValueType raise no inherent difficulties of notation or
    usage, and so do not cross a threshold of priority to be included in the
    specification itself. Such examples would be entirely appropriate to include in
    tutorial materials about the SysML language.
    Disposition: Closed, no change

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

DistributedProperty

  • Legacy Issue Number: 12364
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    On p.46 under 8.3.2.4 DistributedProperty it is stated that: '[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.' It does not however state whether a DistributedProperty [Property] may only be applied to a value property (a "block property" typed by a ValueType or DataType) or other Property variations. All examples of the application of DistributedProperty show it applied to a value property. This has implications for sorting into block compartments in BDDs; if a DistributedProperty [Property] may only be applied to a value property then it will always be sorted into the 'values' compartment. It also has implications for aggregation; since a value property must have AggregationKind 'composite', a DistributedProperty will also have AggregationKind 'composite'.

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    As the issue states, examples of DistributedProperty are shown only for ValueType. Since all details of a probability distribution are left to a user-defined subtype of the DistributedProperty stereotype, however, such a stereotype could be applied to a stereotype typed by a block, such as a part or reference property. Such a stereotype could be defined, for example, to express probabilities of different cases of the block instances referenced by the property. For example, a distribution on the expected number of occurrences could be specified for a property with multiplicity greather than one.
    By not restricting the kind of property to which the DistributedProperty may be applied, the current text does not limit its application. A statement limiting it to a value property would contradict the lack of restriction intended by the current stereotype. The constraint does not refer to the type of the property itself but to the Block or ValueType which must own the property.
    The issue further states the implications that properties with a DistributedProperty stereotype could appear in different compartments or could have different values of AggregationKind. All these implications flow naturally from the lack of any restriction on the kind of property to which the stereotype can be applied.
    The Blocks chapter currently lacks any reference to Annex C.5, Distribution Extensions. Section 8.3.2.4 is the natural place in the Blocks chapter where such a reference could be added. This reference can also indicate that the annex defines distributions only on value properties, without suggesting that DistributedProperty stereotypes are necessarily limited to value properties. Such usage is currently the main expected use of DistributedProperty, but there is no need to restrict it from other possible uses. Moreover, it relies only on standard stereotype extension mechanisms, with no custom notation, so all its implications are those which flow naturally from an independent stereotype.

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

08. Blocks: The 'values' compartment for a part Property in an IBD

  • Legacy Issue Number: 12363
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    There should be a definition of the role of the 'values' compartment for display of "current values" (for representing the entire value state of a system within a unique value context) and/or "deep configuration" values indepedendent of the PropertySpecificType concept, which may be seen as only one possible way of carrying values for assignment to the 'values' compartment in and IBD. Another strategy employing values in Slots of InstanceSpecifications that are related to targeted part Properties by a Property[*] path and then mapped to the targeted part Properties would achieve the same 'values' idiom in and IBD without indication of the implied subtype using [brackets]. When the 'values' are carried by redefined defaultValue : ValueSpecification[0.1] of redefined properties of an implied [PropertySpecificType] the bracket notation should still be used (inviting also indication of other redefinitions that can't be achieved using mapping of InstanceSpecifications, such as operation and constraint redefinitions). In particular, the following paragraph from p.53 (illustrated in Figure 8.11 - SUV EPA Fuel Economy Test) should be rewritten to admit other solutions: "In SysML, one approach is to capture system configurations by creating a context for a configuration in the form of a context block. The context block may capture a unique identity for the configuration, and utilizes parts and part-specific types to express property design values within the specification of a particular system configuration. Such a context block may contain a set of parts that represent the block instances in this system configuration, each containing specific values for each property. This technique also provides for configurations that reflect hierarchical system structures, where nested parts or other properties are assigned design values using property-specific types. The following example illustrates the approach.": While Figure 8.11 - SUV EPA Fuel Economy Test could remain with [PropertySpecificType] notation as an indication of that strategy, there should be an equivalent figure showing the same 'values' compartment and a similar top-level value context block, however without the [brackets] notation on part types, and without any reference to the PropertySpecificType solution. The title of Figure 8.11 should be clearly marked to indicated use of the PropertySpecificType solution and notation. Visit also: http://school.nomagic.com/node/331

  • Reported: SysML 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

08.Blocks: compartment for property-specific defaultValue should be renamed

  • Legacy Issue Number: 12361
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    As discussed at the OMG TM SysML RTF on Th 13Mar2008. The 'defaultValue' compartment should be renamed 'initialValue' (or perhaps 'initialValues'). The static (class level) default values of a given Block's properties may be overridden on instantiation and initialization of a part Property usage of that Block by the using context. The concept of "initial values" is more consistent with the programmatic practice, and it serves to highlight the difference between the UML2 defaultValue (of a Property within a class) and the (re)initialisation of a SysML value Property on usage of its Block as a part Property within a higher context, by assignment of a property-specific initial value. The label 'initial values' is also consistent with the UML2.1.1 specification description of the role of the defaultValue attribute of 7.2.44 Property: "If there is a default specified for a property, this default is evaluated when an instance of the property is created in the absence of a specific setting for the property or a constraint in the model that requires the property to have a specific value. The evaluated default then becomes the initial value (or values) of the property." Further, the concept of "initial values" emphasises the evolving value state of a system. The "initial value" is then merely a single value slice within a series of values states. Configuration is a special case of "initial value". Example: when a Car leaves a factory it is "initialised" to a luxury, sports, or family configuration. The concept of "initial value" compartment is complemented by the suggestion of a "current values" or simply "values" compartment for recording the value state of an evolving system. (See related issues submitted by Darren Kelly.) This suggestion promotes support of animation of SysML systems, and also encompasses aspects of static configuration consistently.

  • Reported: SysML 1.0 — Mon, 31 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

08.Blocks, 8.2.2 Internal Block Diagram:

  • Legacy Issue Number: 12353
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    As discussed at the OMG TM SysML RTF on Th 13Mar2008. Assumes the property-specific 'defaultValue' compartment has been renamed to 'initialValue' (or perhaps 'initialValues'), as suggested in a previous issue submission. The case of a property-specific 'initialValues" compartment (as in Table 8.3 - Graphical nodes defined in Internal Block diagram) and also deeply nested "initial values" is well complemented by a "values" or "currentValues" compartment, as illustrated for the test results in Figure 8.11 - SUV EPA Fuel Economy Test. Together, the "initialValues" and "values" compartments illustrate usefully the evolution of the value state of a system used within an additional top-level "value slice" context. Tool vendors would be free to show one, both, or none of these two complementary compartment in part Properties of an IBD. This strategy promotes progress towards animation of systems, and also enables comparison of special configurations with an "initial" configuration/state. This suggestion represents a useful unification of concepts already present in the SysML specification.

  • Reported: SysML 1.0 — Fri, 21 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue was raised prior to the SysML 1.1 adoption of the "initialValues"
    compartment on properties on an ibd to specify context-specific initial property
    values, and the SysML 1.2 adoption of UML instance specifications to specify
    current or sample property values of specific block instances. Full support of
    UML instance specifications was chosen by SysML 1.2 to support more complete
    specification of instances, including links between instances, than a
    "currentValues" compartment could directly support. The suggested capability
    would be redundant with the capability already adopted by SysML 1.1 and
    SysML 1.2.
    Disposition: Closed, no change

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

SysML needs instance specs

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

    SysML needs instance specs capabilities for several reasons

    1) compatibility with UML and many users' expectations
    2) ability to do animation
    3) ability to show particular values at a time
    4) educational value / illustration value

    No need for a new diagram type, instances can appear on block and sequence diagrams.

  • Reported: SysML 1.0 — Thu, 13 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No practical substitute has been found for the use of instance specifications to
    specify examples, test cases, and other occurrences of blocks defined in SysML
    user models. Because SysML tool implementations are based on UML
    implementations, diagram support for instance specifications can be simply a
    matter of relaxing any constraints that would disable access to these elements
    from within a strict SysML subset. Instance specifications are already included in
    the SysML metamodel to support other elements of SysML such as the Unit
    stereotype and the initial values compartment.
    Because SysML already defines a taxonomy of its standard diagram types
    (summarized in Annex A and defined in the specification chapters), use of
    instance specifications in SysML must be identify a diagram context where they
    could appear. While they might appear in more than one diagram context, the
    simplest approach for uniformity in user models is to rely on a single context
    where they could be shown. Instead of defining an entirely new diagram context,
    the block definition diagram is a natural place to show either the definitions of
    blocks or instances specifications of these blocks, or any mixture of both. Since all the required metamodel elements for instance specifications are already
    present in SysML, the inclusion of their existing UML-based notation can be
    specified merely by including their diagram elements in the table of graphical
    elements which can be shown on block definition diagrams

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

SysML unnecessarily restricts aggregation of datatypes

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

    The 6th constraint on blocks is written as follows:

    [6] If the aggregation attribute of a property owned by a SysML block is equal to “composite” or “shared,” then the type of the property must be a block

    This constraint, as written, limits the use of solid or hollow diamond aggregation relationships from a block to "own" only other blocks.

    1) This is not what the original intent was. Apparently it was to prevent the use of aggregation relationships from a block to own dataTypes or valueTypes.
    As written, it is overly restrictive for its intent

    2) Even the intent is overly restrictive. UML modelers have (for years) modeled the relationship between a class and its attributes as an aggregation relationship.True, software developers have occasionally used the distinction between composite/shared as implementation clues which are unimportant to SysML concerns. However, even though the SysML distinction between an association, aggregation, or composition relationship to a property is irrelevant, the variation of notation allows modelers to use the style they are most familiar with. In addition, for models that move from SysML to UML and back, it allows the preservation of the software hints. It also leverages existing training and educational material on models.

    I recommend dropping this constraint completely. At the most, add a sentence in the description section explaining that using the composite/shared relationship to properties has no implementation meaning.

  • Reported: SysML 1.0 — Mon, 10 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: More constraints for flow ports

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

    The flow port and the flow specification need more constraints and clarification statements. What does it mean to type a flow port with a block that realizes many flow specifications? What does it mean to type a port with block that realizes many interfaces including some flow specifications? Is it allowed that a flow specification is part of a realization relationship? How to define a complex flow port that uses more than one flow specification?

  • Reported: SysML 1.0 — Mon, 10 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Any property (including flow ports) that are typed by a classifier that realizes
    multiple interfaces (including flow specifications) means the value will support the
    features of all the interfaces. This is UML semantics that is not necessary to
    restate in SysML. Flow specifications are based on interfaces, and participate in
    realization relationships like any other interface. A classifier can realize multiple
    interfaces, including flow specifications. This is UML syntax that is not necessary
    to restate in SysML.
    Disposition: Closed, no change

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

Section: 8.3.2.1

  • Legacy Issue Number: 12268
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    1) The definition of Constraint [5] for Block in section 8.3.2.2 is defined as "The following constraint under section [...] in the UML Superstructure Specification is removed by SysML: [...]". 2) The UML 2.1.2 Superstructure Specification states in section 18.1.2 under 'Extensibility': "It is not possible to take away any of the constraints that apply to a metamodel such as UML using a profile, [...]". 3) In Section 6 of the SysML-Specification, it is stated that "The SysML specification is defined by using UML 2 specification techniques. These techniques are used to achieve the following goals in the specification. Correctness [...] The specification technique used in this specification describes SysML as a UML extension that is defined using stereotypes and model libraries." The points 1), 2) and 3) together are a contradiction.

  • Reported: SysML 1.0 — Mon, 10 Mar 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The referenced text from the introductory section of Chapter 6 is incorrect.
    SysML is defined using not only stereotypes and model libraries, but additional
    techniques including diagram extensions as well as the removal of a specific
    existing UML constraint, as noted by the issue. The initial statement that "The
    SysML specification is defined by using UML 2 specification techniques" is
    incorrect since some of these extension techniques are not provided by UML 2.
    The second statement that "These techniques are used to achieve the following
    goals in the specification" is incorrect since the specification techniques used are
    not sufficient to achieve the listed goals. Remove this introductory section entirely
    to avoid misleading statements and to eliminate the contradition noted by the
    issue.

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

moe should be removed from section 7.4 or added to the standard

  • Legacy Issue Number: 12258
  • Status: closed  
  • Source: Northrop Grumman ( Darin Supel)
  • Summary:

    Section 7.4, part of the standard, utilizes the <<moe>> stereotype. <<moe>> is not part of the standard. Annex C, where <<moe>> is defined, states "This annex describes useful non-normative extensions to SysML that may be considered for standardization in future versions of the language." The standard should not be infected with non-standardized stereotypes. <<moe>> should be removed from section 7.4 or added to the standard.

  • Reported: SysML 1.0 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

remove homemade stereotypes

  • Legacy Issue Number: 12257
  • Status: closed  
  • Source: Northrop Grumman ( Darin Supel)
  • Summary:

    Don't the authors find it embarrassing that their solution to a sample problem isn't even compliant with their own specification? In section B.4.2.1, its states "The «system» and «external» stereotypes are user defined, not specified in SysML,...". I don't care what excuse the authors come up with, "user defined" stereotypes should not be used. The concept of "user defined" or just "making up" stereotypes is inconsistent with the concept of profiles. By standard, «system» and «external» must be in a profile since they are not standard UML keywords nor stereotypes. The authors need to remove homemade stereotypes from their example or add them to the profile. The removal of the homemade stereotypes will likely prove the current specification inadequate.

  • Reported: SysML 1.0 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Icons for FlowPort

  • Legacy Issue Number: 12256
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    I would suggest changing the icons you have chosen for FlowPort. Hence, in the following picture extracted from the spec., ac and dc are understood respectively as input and output flow port.

    But, if I move dc on left hand side of the rectangle denoted Transformer, ac on the right, dc becomes an input and ac becomes an output. I suggest you to adopt the ones defined within MARTE (see following picture).

  • Reported: SysML 1.0 — Mon, 3 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Chapter 2: UML version

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

    OMG SysML 1.0 is an extension of UML 2.1.1. The next version OMG SysML 1.1 should be an extension of UML 2.2 to avoid a gap between these two closely related standards. According to UML 2.2 SysML should support OMG XMI 2.2 instead of XMI 2.1.

  • Reported: SysML 1.0 — Sun, 2 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Since the RTF of the UML 2.2 has not finished its work, it is too early to define OMG SysML as an extension of UML 2.2. It is not possible to analyse the impact.
    However, there is a minor mistake in the UML4SysML definition. UML4SysML imports the UML StandardProfileL1 which doesn't exist in UML. It should be the StandardProfileL2.

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

Section: annex A.1, Activities

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

    Designating a Diagram Frame with a the name of a Stereotyped Model Element Type: Annex A (Diagrams) is not explicit on how to designate a diagram frame with a model element type that has a stereotype applied. If, for example, a diagram is intended to represent a package which has been stereotyped as a model library, one would expect the diagram header to reflect the model library as the designated model element type. The naming of diagram header is defined beginning on pg 173 in Annex A.1, and does not clarify this. The proposed resolution is to allow the name of the stereotype or the name of the base class to be used as the name of the model element type in the diagram header. For the previous example, the name of the model element type could either be [package] or [model library].

  • Reported: SysML 1.0 — Sun, 2 Mar 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Update text per below to allow a stereotype name to appear in the diagram header as the name of the model element type. Also, ensure consistency with this notation throughout the spec. The control operator in the activities chapter needs to be modified in table 11.1 and in the usage example in Figure 11.2.

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

Section: Chapter 7: Viewpoint

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

    The viewpoint should use a Behavior element to describe the construction of the view instead of methods and languages. Concrete behaviors could be SysML elements like Activity or Interaction. Or construction rules specified in any language using a OpaqueBehavior element

  • Reported: SysML 1.0 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 08 Blocks: suggest need Quantity stereotype and definition

  • Legacy Issue Number: 12219
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    stereotype for a Quantity is required. The current Unit, Value, Dimension system in SysML is incomplete without the crucial concept of Quantity. A physical or industrial Quantity is independent of a choice of unit and value as measured or stated. A Quantity has a Dimension, which can be fundamental (as in the SI system), or derived (according to industrial needs). A Quantity DOES NOT have a Unit, and it DOES NOT have a relationship to a given unit systems, although it may be allocated a default unit within a given system. The statement/measurement of a Quantity is given as a value relative to a chosen Unit. A Quantity is represented in SysML by a value property (typed currently by a ValueType, although a strong case can be made for typing by a value property directly by a Unit).

  • Reported: SysML 1.0 — Tue, 12 Feb 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue points out that Quantity is a distinct concept from either Unit or
    Dimension, even though SysML currently defines stereotypes only for Unit,
    Dimension, and a ValueType to type values that may have a unit and/or
    dimension.
    To resolve these issues, and to clarify terminology to be used in a consistent way
    not only for SysML, but for its alignment and close partnership with MARTE, an
    extensive effort has been made to model the underlying concepts as defined by
    the most recent and authoritative sources. A new Annex C.5 provides a
    comprehensive model, expressed in terms of SysML blocks, for the interrelated
    concepts pertaining to quantities, units of measure, conversions among units,
    and dimensional analysis within systems of quantities.
    The new Annex C.5 is non-normative and is intended to fill two basic roles. One
    is a detailed conceptual model of the quantities domain, that, with the aid of
    examples built as instances of the blocks in this model, thoroughly expresses
    and defines the concepts which the SysML quantities-related stereotypes were support for capturing and documenting systems of units and quantities
    comprehensively in a form suitable for dimensional analysis.
    SysML 1.0 deliberately provided only minimal stereotypes to identify and name
    units and/or dimensions associated with value types. It did not provide further
    support for defining and documenting them including their relationships to each
    other. Practical use of this modest capability has shown that comprehensive
    documentation of units and related concepts is an important requirement for
    quantity values to be defined unambiguously and used in consistent ways.
    Although Annex C.5 provides much more comprehensive support for defining
    and organizing unit and quantity-related concepts in reusable domain-specific
    libraries than SysML 1.0 did, minimal changes are made to the normative parts of
    SysML 1.x for incorporating the new concepts. The principal change is to
    rename the current SysML stereotype “Dimension” to “QuantityKind.” The
    current definition of Dimension in SysML 1.1 as ”a kind of quantity that may be
    stated by means of defined units,” closely matches the QuantityKind concept in
    Annex C.5, while Dimension is reserved for a more specialized relationship
    between quantity kinds in the context of a system of quantities. To align with this
    terminology and avoid any misleading implications of the current name, this
    resolution makes a single name change from the SysML 1.1 Dimension
    stereotype to QuantityKind and relaxes the restrictive constraints on Dimension
    that no longer apply to the QuantityKind concept.
    In addition to issue 12219, this resolution addresses two issues previously
    deferred in SysML 1.1:
    Issue 11600, “SysML dimensions,” pointed out inconsistencies in Unit,
    Dimension, and ValueType constraints and statements. The relaxation of
    constraints on Dimension (now renamed QuantityKind), Unit, and ValueType,
    and related changes to the text included in the resolution for this issue should
    resolve those inconsistencies. The resolution for Issue 11600 is therefore being
    merged into the resolution for this issue.
    Issue 12128, “8.3.2.9 Unit, 8.3.2.10 ValueType,” proposed a new metamodel
    based on a class hierarchy for Unit and ValueType to express “the underlying
    physical and mathematical principles of a dimensioned quantity represented by a
    value subject to chosen units.” Since the resolution for this issue includes an
    overall roadmap for the same goals and includes changes to Unit, ValueType,
    and QuantityKind with optional support for defining systems of units and
    quantities, the resolution of this issue encompasses a resolution for Issue 12128
    as well. Although the present resolution does not adopt the solution proposed in Issue 12128, the scope of issue 12219 subsumes that of 12128 and provides
    multiple ways to support the key concepts requested in 12128, as part of
    incremental and compatible changes for SysML 1.x.

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

Suggest permit UML2.1.1 Component for use as parasitic element wrapper Comp

  • Legacy Issue Number: 12163
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s There are at least three applications of the UML2 Component which I consider very beneficial to practical UML-based systems engineering: 1st: I make extremely heavy use of the technique of stereotyped <<composition>>, <<inhertance>>, <<specialisation>> "wrapper" Components to graphically and logically organise model elements in BDDs (and in class diagrams) "parastically", i.e. without stealing ownership of the contained elements. Especially the <<composition>> wrapper Component is very powerful for diagramming and organising hierarchical assemblies of complex systems. In such cases the wrapping Component has Realizations to the wrapped elements, which can be further leveraged to trace the logical groupings. The recipe is consistent with the UML2.1.1 superstructure (although it is not supported in all UML tools). I contend the wrapper Component strategy should be made officially available to those SysML users who wish to use it (at least as a permitted option). 2nd:If one permits the UML2.1.1 Component the SysML <<requirement>> stereotype can be applied to Components so that Requirements can be graphically nested, which is far more graphically stable than just diagramming Class <<requirement>> Dependencies, and can be consistently applied in combination with the existing relationship stereotypes between SysML requirements. 3rd: Components are far better suited to creating orthogonal, parasitic <<views>> of packaged elements than the Package or Model, which both steal ownership.

  • Reported: SysML 1.0 — Mon, 7 Jan 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s Discussion:
    SysML currently lacks capability to represent system views that define parts or
    other substructure differently than other system views. As noted by the issue,
    any declaration of ownership or other other model structure in one view cannot
    conflict with such declarations in other views. The View stereotype of Package
    defined in Chapter 7, Model Elements, only selects elements for inclusion in any
    one view, and does not support additional structure which may differ across
    views. The proposal to consider Component as a basis for “orthogonal, parasitic
    <<views>>” is an interesting possibility, but goes beyond the scope of
    incremental change that can be considered in an RTF. Addition of such a fundamental capability to SysML, and a UML profile which bases this capability
    on UML Component, could be considered in response to an RFP for a major new
    version of SysML.
    Disposition: Closed, no change

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

10.Constraint, Figure 10.3

  • Legacy Issue Number: 12159
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

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

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

    Discussion:
    Figure 10.3 will be replaced with a reference to Figure B.29 as part of the
    resolution for Issue 13976, “Example figures in chapters are redundant with
    Annex B sample problem.” Issue 12160 raised this same issue on Figure B.29.
    Disposition: See issues 12160 and 13976 for disposition

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

Section: 8.3.2.1

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

    Clarify that a binding connector can have nested connector ends like a regular connector. In particular, clarify that a binding connector can bind to parameters of a nested constraint property, without having to bind to an intermediate parameter of the outer constraint property. A binding connector can clearly bind to a nested value property using the dot notation or directly to a value property nested within parts.

  • Reported: SysML 1.0 — Thu, 3 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Add sentences to provide the requested clarification. Also remove redundant language from 8.3.2.2 Block now that a separate BindingConnector stereotype has been defined.

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

Section: 9.3.2

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

    NAME - JUNCTION PORT Limited ability to model certain typs of physical interfaces in SysML such as mechanical, electrical, optical, and thermal, where the interface does not explicitly represent a flow or a service. An example is the mechanical interface between two parts at their mating surface. An approach was included in a recent paper called "Modeling Continuous System Dynamics in SysML" by Thomas Johnson, Jonathan Jobe, Christiaan Paredis, Roger Burkhart, Proceedings of the IMECE 2007, Nov ' 2007, which is available on the omg sysml website. A stereotype for a junction is introducted to model a mechanical interface (Flange in Fig 4). This concept can be applied more generally to model a mechanical interface. The proposal is to stereotype a port as a <<junction port>> that is typed by a Junction, which would also be a stereotype. The junction would have properties such as a position, and force, and include constraints on its properties such as conservation of mass flow, energy flow, etc. Several subclasses of junction can be defined for mechanical, electrical, thermal, optical, other electromagnetic interfaces, each of which may have different constraints applied. The concstraints can be used in parametrics.

  • Reported: SysML 1.0 — Thu, 3 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 11628 for resolution

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

Annex B, Figure B.18, Figure B.19

  • Legacy Issue Number: 12155
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    The composing owner of FrontWheel is never made clear It is clear from Figure B.18 - Defining Structure of Power Subsystem (Block Definition Diagram) and Figure B.19 - Internal Structure of the Power Subsystem (Internal Block Diagram) that ChassisSubsystem.FrontWheel is shared by PowerSubsystem, and that FrontWheel is a specialisation of WheelHubAssembly.. However nowhere is it made clear which block is the composing owner of FrontWheel (although we may guess that it is ChassisSubsystem). The polymorphic substitution of FrontWheel for WheelHubAssembly is never explained.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Discussion:
    Polymorphic substitution is not implied, and elaboration of composing ownership
    of frontWheel would add unnecessary complexity to the example without specific
    benefit.
    Disposition: Closed, no change

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

Annex / Figure B.37

  • Legacy Issue Number: 12153
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B.37: the elements allocated from are of type Action, not Activity In table Figure B.37 allocations are made from the following Actions (activity usages): a1:ProportionPower a2:ProvideGasPower a3:ControlElectricPower a4:ProvideElectricPower The 1st column shows them incorrectly as of type Activity. NB: this issue relates to and/or duplicates: Issue 11497: Mixed action and activity concepts (sysml-rtf)

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

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B36

  • Legacy Issue Number: 12151
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B36: ice:InternalCombustionEngine should be allocated from ProvideGasPower, not ConvertGasToPower Figure B36 shows 'ice:InternalCombustionEngine' allocated from '<<activity>> ConvertGasToPower'. Figure B35 shows Action 'a2:ProvideGasPower' allocated to '<<block>> InternalCombustionEngine'. The table in Figure B37 shows Action 'a2:ProvideGasPower' (incorrectly typed as an Activity) allocated to '<<block>> InternalCombustionEngine'. For consistency Figure B36 should show 'ice:InternalCombustionEngine' allocated from Action 'a2:ProvideGasPower'.

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

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B.36

  • Legacy Issue Number: 12150
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B36: ecu:PowerControlUnit should be allocated from ProportionPower, not ProportionPowerLoad Figure B36 shows 'ecu:PowerControlUnit' allocated from '<<activity>> ProportionPowerLoad'. Figure B.35 shows Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'. Figure B.37 table shows 'a1:ProportionPower ' allocated to part Property 'ecu:PowerControlUnit'. For consistency Figure B.36 should show Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'.

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

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B36

  • Legacy Issue Number: 12149
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B.36: shows allocations to part Properties, not to Blocks as in Figure B.35 Figure B.35 shows allocations of actions to swimlanes representing blocks. Figure B.36 shows allocations of activities to part properties. Figure B.35 should probably shows allocations of actions to part properties. Figure B.36 should probably show the same allocations of actions to part properties.

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

    Disposition: See issue 11497 for disposition

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

Annex B / Figure B.36

  • Key: SYSML11-99
  • Legacy Issue Number: 12148
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure B.36 emg:ElectricalMotorGenerator should be allocated from a4:ProvideElectricPower not ConvertElectricToPower Figure B.36 shows 'emg:ElectricalMotorGenerator' allocated from <<activity>> ConvertElectricToPower Figure B.35 shows Action 'a4:ProvideElectricPower' allocated to '<<block>> ElectricalMotorGenerator'. The table in Figure B.37 shows 'a4:ProvideElectricPower' (incorrectly typed as an Activity) allocated to '<<block>> ElectricalMotorGenerator'. For consistency Figure B.36 should show 'emg:ElectricalMotorGenerator' allocated from Action 'a4:ProvideElectricPower'.

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

    Disposition: See issue 11497 for disposition

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

Annex B / B.4.8.3 Activity Diagram

  • Key: SYSML11-98
  • Legacy Issue Number: 12143
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    B.4.8.3 Activity Diagram (EFFBD): refers incorrectly to objectFlows in BDD Figure B.34 SysML1.0: 'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail) Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34' In fact Figure B.34 is a BDD, so it can't show 'objectFlows'. It shows the Blocks that type the ObjectFlows.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Annex B / B.4.5.4 Block Definition Diagram

  • Key: SYSML11-97
  • Legacy Issue Number: 12142
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    B.4.5.4 Block Definition Diagram: Should say 'white diamond (shared AggregationKind)' not 'white diamond (composition)' SysML1.0: 'B.4.5.4 Block Definition Diagram - Power Subsystem .. Note how the of white diamond (composition) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.' The choice of the word 'composition' in combination with the white diamond is unfortunate, as it implies 'composite' AggregationKind. Rewrite to say 'white diamond (shared AggregationKind)' rather than 'white diamond (composition)': 'Note how the of white diamond (shared AggregationKind) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.'

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Annex B, B.4.4.3 Requirement Diagram

  • Key: SYSML11-96
  • Legacy Issue Number: 12141
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    SysML1.0, p.188: 'B.4.4.3 Requirement Diagram - Acceleration Requirement Relationships Figure B.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements. The “refineReqt” relation, introduced in Figure B.12, ..' Should read '"refine" relation'.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Annex B/B.4.1.2 Package Diagram

  • Key: SYSML11-95
  • Legacy Issue Number: 12140
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    B.4.1.2 Package Diagram: <<access>> should be <<import>> SysML1.0: 'B.4.1.2 Package Diagram - Showing Package Structure of the Model .. The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «access» relationship.' In fact Figure B.3 shows <<import>> relationships.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

15.3.2.3 AllocateActivityPartition

  • Key: SYSML11-94
  • Legacy Issue Number: 12139
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    15.3.2.3 AllocateActivityPartition(from Allocations): /supplier (from) /client (to) wrong way round >From SysML1.0 15.3.2.3 AllocateActivityPartition(from Allocations): 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (from) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (to) end of the same «allocate» dependency.' Should read: 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (to) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (from) end of the same «allocate» dependency.' Note that a similar mixup was reported for 15.3.2.2 Allocated(from Allocations): 'Issue 11501: Wrong ends of Allocate relationship used in Allocated definition (sysml-rtf) Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")'

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Above suggestion is incorrect; the action should be the client (from) end. Revise
    text consistent with resolution to issue #11501.

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

11. Activities

  • Key: SYSML11-93
  • Legacy Issue Number: 12138
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    I suggest general policy for SysML: prefer Pins over ObjectNodes in all possible cases Use of ObjectNodes is problematic for many reasons, including: - In UML2.1.1 ObjectNode is abstract ! Tool vendors are thus forced to choose an arbitrary concrete placeholder (like <<CentralBufferNode>>, which is invalid). Use of Pins avoid this problem. - ObjectNodes are graphically less stable than Pins, as on has to manage the placement of ObjectNodes between Actions and two paths. - It is easier to trace type compatibility of connections between between Pins representing typed Parameters than across two paths via an ObjectNode with no binding to Parameters. - The placement of ObjectNodes on swimlanes boundaries (like in Figure B.35) is contrived and graphically unstable. Experience has shown that Pins are far easier to read, verify, and manage, and they correspond well to the idioms of signal processing known to engineers. I recommend that they be used in ALL SysML diagrams wherever possible, and that this be adopted as SysML policy, to the advantage of systems engineers, educators, and tool vendors alike.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

11 Activities, Figure 11.10

  • Key: SYSML11-92
  • Legacy Issue Number: 12137
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure 11.10 Suggest use output Pin from <<controlOperator>> 'Enable On Brake Pressure > 0' typed by ControlValue The <<controlOperator>> action ':Enable on Brake Pressure > 0' does not show an output Pin corresponding to an output Parameter of type ControlValue that must exist for the Behavior Enable on Brake Pressure > 0. From SysML1.0: '11.3.2.2 ControlOperator ,, Constraints [1] When the «controlOperator» stereotype is applied, the behavior or operation must have at least one parameter typed by ControlValue. If the stereotype is not applied, the behavior or operation may not have any parameter typed by ControlValue.' It would make sense (and be clearer) if the «controlOperator» had an output Pin typed by ControlValue. Below we see the diagram adapted to use an output Pin typed by ControlValue: http://school.nomagicasia.com/node/109 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Revise as suggested.

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

11.Activities, Figure11.10

  • Key: SYSML11-91
  • Legacy Issue Number: 12136
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Figure11.10 suggest use anonymous, typed Pins for clear indication of flowing information type and to support

    {stream} Parameter t is difficult and/or inconsistent to show the {stream}

    indication of the Action ':Driving' without an output Pin corresponding to an underlying output Parameter of Behavior 'Driving' satisfying the 'isStream=true' condition. Indeed Table 11.1 - Graphical nodes included in activity diagrams shows only Actions with Pins and the

    {stream}

    indicator for UML4SysML::Parameter.isStream The following image shows Figure 11.10 adapted to use Pins throughout (except for ControlValue input to the controller Action 'Monitor Traction'): http://school.nomagicasia.com/node/108 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png NB: this issue submissions is marked as 'significant' because the I consider it extremely important that the SysML effort advertises the clear advantages of Pins whereever possible to the benefit of tool vendors and end users.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

11 Activities, Figure 11.10


11.Activities/11.3.2.8 Rate/Figure 11.8

  • Key: SYSML11-89
  • Legacy Issue Number: 12134
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    The «rate» stereotype has a property 'rate' of type ValueSpecification 11.3.2.8 Rate yet InstanceSpecification in Figure 11.8 SysML1.0, 11.3.2.8 Rate: 'The «rate» stereotype has a rate property of type ValueSpecification.' However Figure 11.8 shows 'rate' with type InstanceSpecification. (Also, the 'rate' property should be clearly defined as an Attribute of <<rate>> in 11.3.2.8 Rate.)

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The has a rate property of type ValueSpecification. The values of properties stereotyped by "rate" must be instances, see next to last sentence of Section 11.3.2.8 (Rate). The metamodel is enough to show "rate" is an attribute of "rate".

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

11 Activities, 11.2.1 Activity Diagram

  • Key: SYSML11-88
  • Legacy Issue Number: 12133
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Table 11.1 and Table 11.2: appear to contradict constraint that <<discrete>> and <<continuous>> should not be both applied SysML 1.0, 11.3.2.3 Discrete: '[1] The «discrete» and «continuous» stereotypes cannot be applied to the same element at the same time.' However Table11.1 and Table 11.2 Rate examples appear to show both «discrete» and «continuous» applied to the same element at the same time, and Table 11.1 appears to show overloaded tagged values

    {rate=constant}

    and

    {rate=distribution}

    . Resolution: change Table11.1 and Table 11.2 to show dedicated examples of «discrete» and «continuous» stereotype usage.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

10 Constraint Blocks, 10.3.2.1 ConstraintBlock

  • Key: SYSML11-87
  • Legacy Issue Number: 12132
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    10 Constraint Blocks and 10.3.2.1 ConstraintBlock: parameters never clearly defined SysML1.0, 10 Constraint Blocks: 'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block define the parameters of the constraint.' The above does not make clear that parameters are properties that can be typed by a ValueType (yet are not value properties), and it does not exclude nested contraints, which are properties typed by a <<ConstraintBlock>> (although other sentences elsewhere in the specification do make that clearer). Also, it is not clear whether a constraint parameter can be typed by a block (although there are no examples of such in the figures). Rewrite to specify what constraint parameters are: 'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block typed by a ValueType, Unit, or DataType define the parameters of the constraint.' SysML1.0, 10.3.2.1 ConstraintBlock: '.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.' Rewrite to explain what constraint parameters are: '.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used. Constraint parameters are properties of a Constraint Block that are typed by either a ValueType, a Unit, or a DataType.' (NB: the resolutions suggested here depends on the unit, value, dimension metamodel being changed to admit the application of Unit as a type.) This matter could be greatly simplified by including a ConstraintParameter stereotype as a point of documentation and specification

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    SysML does not restrict the type of parameters to which constraint blocks may be
    applied. Even though the typical examples apply parametric constraints to value
    parameters, such as mathematical expressions that constrain numeric property
    values, constraint blocks may also be applied to structural properties such as parts or
    reference properties.
    Reword the explanatory sentence referenced by the issue from the final introduction
    paragraph to avoid suggesting that constraint parameters are the only kind of
    property a constraint block may contain. Also, avoid language that excludes recursive
    definition of constraint blocks, in which a nested constraint property references the
    same constraint block being defined.

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

10.3.2.2 ConstraintProperty

  • Key: SYSML11-86
  • Legacy Issue Number: 12130
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    10.3.2.2 ConstraintProperty: rewrite constraint [2] so does not refer to 'a SysML Block that is typed by a ConstraintBlock' SysML1.0, 10.3.2.2 ConstraintProperty: 'A constraint property is a property of any block that is typed by a constraint block. .. [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock.' These may both be misinterpreted as applying to "any block that is typed by a constraint block" and "a SysML Block that is typed by a ConstraintBlock" rather than a constraint property typed by a constraint block. Rewrite so that the type condition clearly applies to the owned constraint property, not the owning block, thus: 'A constraint property is a property that is typed by a constraint block and is owned by a block. . [2] The ConstraintProperty stereotype must be applied to any property that is typed by a ConstraintBlock.' (Note that the first constraint already makes it clear that a constraint property is owned by a SysML Block: '[1] A property to which the ConstraintProperty stereotype is applied must be owned by a SysML Block'.)

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The ConstraintProperty stereotype expresses a condition that can be entirely derived
    from other information in the metamodel, in this case a property of a block that is
    typed by a ConstraintBlock. Property stereotypes are not defined for other categories
    of property, such as part, reference, or value properties.
    The constraints which currently appear under Section 10.3.2.2 ConstraintBlock, only
    serve to define the ConstraintProperty category. A definition of the term “constraint
    property” can be provided by language under 10.3.2.1 ConstraintBlock, similar to
    how categories of part, reference, and value properties are defined under Section
    8.3.2.2 Block.
    OMG Issue No: 12130 Disposition: Resolved
    SysML 1.4 RTF Report Page 25 of 341
    Discussion in previous RTF's suggested that a consistent policy be adopted for
    “calculated stereotypes” which only classify existing elements. Tools are still free to
    establish internal stereotypes or other means to carry such information, but since no
    other such calculated stereotypes remain in SysML, the consistent policy is to
    remove the ConstraintProperty stereotype from the normative specification. Impact
    on existing implementations should be minimal since they may still preserve such a
    stereotype if it is useful to their implementation, but this specific stereotype would no
    longer be required by the specification.
    In the stereotypes for measures of effectiveness defined in Table D.5, require that
    the base element for the «objectiveFunction» stereotype be a ConstraintBlock, as
    stated in the immediately preceding text: "The objective function is a stereotype of a
    ConstraintBlock and the measure of effectiveness is a stereotype of a block
    property."

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

10.3.2.2 ConstraintProperty

  • Key: SYSML11-85
  • Legacy Issue Number: 12129
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    10.3.2.2 ConstraintProperty: add constraint that the AggregationKind must be 'composite' Add a constraint: [3] A property to which the ConstraintProperty stereotype is applied must have AggregationKind 'composite'

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Issue 12130, “clarify constraint with OCL as well as text”, drops the
    ConstraintProperty stereotype altogether, after analysis of potential OCL
    indicated that the constraints added no new information but only served to define
    the constraint property category of block properties. A constraint specifying the
    AggregationKind of a constraint property (defined simply as any property of a
    block typed by a ConstraintBlock) is still appropriate to add, but can no longer
    placed under the ConstraintProperty stereotype as recommended by this issue.
    Instead, this constraint is being added under the ConstraintBlock stereotype
    under Section 8.3.2.1.

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

Section: 11.3.2.2 ControlOperator

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

    What happens if a control value from a control operator stops the following action and there are no more tokens left and no actions are active? Does this terminates the execution of the activity? What if the control value suspends the action? Who can resume the action? There are no more tokens and running actions.

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

08 Blocks, 8.3.2.9 Unit, 8.3.2.10 ValueType

  • Key: SYSML11-84
  • Legacy Issue Number: 12128
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute This strategy provides a compact and elegant metamodel for units and values, and expresses well the underlying physical and mathematical principles of a dimensioned quantity represented by a value subject to chosen units. Value properties can then be sensibly typed by either a Unit or a ValueType. In the case where a ValueType has a Unit, the constraint still applies that the dimension of the ValueType must be the same as the dimension of the Unit. See also analysis image and commentary at: http://school.nomagicasia.com/node/126

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

    Disposition: See issue 12219 for disposition

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

8.3.1.2 Internal Block Diagram

  • Key: SYSML11-83
  • Legacy Issue Number: 12127
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    .3.1.2 Internal Block Diagram: p.40: assert that value properties must be owned with AggregationKind 'composite' This would be consistent with the following from 8.3.1.2 Internal Block Diagram, Property types: ".. A part or value property is always shown on an internal block diagram with a solid-outline box. A reference property is shown by a dashed-outline box, consistent with UML .." Rewrite to include assertion that value properties must always be owned with AggregationKind 'composite': ".. A part or value property has AggregationKind 'composite' and is always shown on an internal block diagram with a solid-outline box. A reference property has AggregationKind 'none' or 'shared' and is shown by a dashed-outline box, consistent with UML .." (Please note also that this case also illustrates why it would be useful to have a clear stereotypes like ValueProperty throughout the SysML specification, as it affords a canonical point of documentation for such assertions and constraints.)

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

8 Blocks, 8.3.1.2 Internal Block Diagram, 8.3.2.2 Block

  • Key: SYSML11-82
  • Legacy Issue Number: 12126
  • Status: closed  
  • Source: No Magic, Inc. ( Darren Kelly)
  • Summary:

    There are at least 4 kinds of properties of blocks: parts, references, values, constraints Constraint properties do not take part in the assembly hierarchy of blocks. Although they are of type Block via ConstraintBlock and have AggregationKind 'composite' they should not be considered "parts". SysML1.0, 8 Blocks: 'A block can include properties to specify its values, parts, and references to other blocks.' Rewrite to include constraint properties: 'A block can include properties to specify its values, parts, references to other blocks, and constraint properties.' SysML1.0, 8.3.1.2 Internal Block Diagram, Property types: 'Three general categories of properties are recognized in SysML: parts, references, and value properties' Rewrite to include constraint properties: 'Four general categories of properties are recognized in SysML: parts, references, value properties, and constraint properties.' SysML1.0, 8.3.2.2 Block, Description: 'SysML establishes three standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classifed as a part property. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, and value properties may be shown in block definition compartments with the labels “parts,” “references,” and “values” respectively. Properties of any type may be shown in a “properties” compartment.' Rewrite to include constraint properties: 'SysML establishes four standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classified as a part property (excluding constraint properties, which are typed by a Constraint Block). A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, value properties, and constraint properties, may be shown in block definition compartments with the labels “parts,” “references,” “values”, and "constraints" respectively. Properties of any type may be shown in a “properties” compartment.' Note also minor spelling correction: classifed -> classified.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Rewrite to include constraint properties as a fourth kind of property of a SysML Block, and to refer to Chapter 9 and Chapter 10 for more detail about ports and constraint properties. Include properties owned by a SysML ValueType within these classifications, so that uniform rules will apply to them on internal block diagrams. Change the aggregation attribute of a value property to composite aggregation to be consistent with their solid box notation on an internal block diagram. Update constraint [6] on Block to reflect the composite aggregation of a value property. Fix an incorrect internal section reference and correct minor spelling corrections.

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

Allocation Callout to Item Flow is Ambiguous

  • Key: SYSML11-81
  • Legacy Issue Number: 12124
  • Status: closed  
  • Source: Raytheon ( Rick Steiner)
  • Summary:

    An allocation callout, when anchored to an Item Flow on an Internal Block Diagram, is unclear. If the Item Flow has an Item Property, then the allocation could be to the Item Flow itself, the Item Property, or the Item Property type (Conveyed Classifier). Recommendation: develop a compact graphical notation to distinguish the target of the allocation when a callout is used with any graphical depiction of an Item Flow.

  • Reported: SysML 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Per resolution on issue #13945, an item flow supports only one item property, not
    multiple item properties. The ambiguity presented above thus becomes
    academic, there is no practical distinction between allocating to the item flow and
    allocating to the item property.
    Disposition: Closed, no change

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

Section: 9.3.2

  • Key: SYSML11-80
  • Legacy Issue Number: 11961
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    in Figure 9.1 Port Stereotypes,the Flow Specification that extends UML4SysML::Property should be a Flow Property and not a Flow Specification.

  • Reported: SysML 1.0 — Mon, 31 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Fix the diagram to the below figure.

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

Chapter Blocks/Section 8.3.2.6

  • Key: SYSML11-79
  • Legacy Issue Number: 11895
  • Status: closed  
  • Source: EmbeddedPlus Engineering Inc ( Kumar Marimuthu)
  • Summary:

    I am trying to support PropertySpecificType in our SysML Toolkit and I hit some road block while trying to implement the same. I have had some discussion with Sandy last week regarding the same but I quiet don’t get how this can be supported without some additional constructs to the PropertySpecificType stereotype. Below are the lists of questions I have: When a default value is provided for the property type, then a type derived from the original type should be created and its default value should be set as the new deafult value of the property. The property type should be displayed in square brackets which would indicated that the type is a specialized type. There can be more than one specialization of the same class, in such case there is no construct to store which specialization is associated with which property? This additional construct is very much needed because there is no way to know whether the specialization is created by SysML for PropertySpecificType or whether it is created by user? What happens in case of multi-level hierarchy? (If Class2 inherits Class1, and property1 is typed by Class2 & the default value at property1 is changed the resultant propertyspecifictype is Class3. Should the tool show property1:[Class2] or property1:[Class1]). Why is the PropertySpecificType extends UML2::Classifier and not UML2:Type? PropertySpecificType was introduced to provide specific default values to properties in Internal Block Diagram. Why not use the InstanceSpecification from UML2? Below Diagram shows how this is supported in UML2.

  • Reported: SysML 1.0 — Wed, 26 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Stakeholder and Concern

  • Key: SYSML11-78
  • Legacy Issue Number: 11823
  • Status: closed  
  • Source: No Magic, Inc. ( Andrius Strazdauskas)
  • Summary:

    Stakeholder and Concern should be first class elements.
    This is needed for UPDM modelers, that will likely will be reusing SysML View/Viewpoint structure.

  • Reported: SysML 1.0 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Now that UPDM has completed finalization, it has no specific requirements for
    reuse of these SysML elements. SysML relies on informal documentation strings
    to define a viewpoint, including not only stakeholder and concern but also
    purpose, languages, and methods. For consistency, these supporting elements
    of a viewpoint can continue to rely on the current string-based approach.
    Disposition: Closed, no change

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

Section: 8.3.1.2 Internal Block Diagram Extensions

  • Key: SYSML11-77
  • Legacy Issue Number: 11819
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Please provide a notation variant that allows to show block stereotypes at property elements typed by those blocks in an ibd. Similar to the notation variant that CallBehaviorActions can show the stereotypes of the called Behavior element. For example a common approach is to define stereotypes for discipline specific elements like <<hardware>>, <<software>>, <<mechanic>>, and so on. It is important to see the information in a bdd and ibd. It is circumstantial and superfluous to define two stereotypes for blocks and properties.

  • Reported: SysML 1.0 — Fri, 14 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The internal block diagram already allows any compartment of a block or value type that types a property to be shown within the property box on the diagram. Section 8.3.1.2 Internal Block Diagram, subsection "Compartments on internal properties" specifies, "SysML permits any property shown on an internal block diagram to also show compartments within the property box. These compartments may be given standard or user-customized labels just as on block definitions."
    A valid use of this option is to show a stereotype compartment, with or without any stereotype properties, as one of the compartments on the property box. This provides an existing graphical option to display the stereotype for a block or value type that types a property on an ibd.
    While the specifications places no restrictions on the compartments from the property type that may be shown on the property, in practice this could lead to confusion or ambiguity as to whether a compartment shown belongs to the property or to the type. The potential for such ambiguity is even higher if the property were to specify a property-specific type, since then the compartment could be used to define or redefine new features specific to the definition of the property itself.
    To remove any ambiguity for a compartment shown on a property, a graphical convention can be established to clearly mark and indicate a compartment whose contents are entirely the contents of the type of the property.
    Such a convention takes advantage of the customizability of compartment labels, and their definition as purely notational options on diagrams which are not defined formally anywhere in the SysML metamodel, is to use a special form of compartment label for these "type-derived" labels.
    For consistency with other aspects of ibd syntax, in which a ":" character separates a property name from its type, or which can precede the type when no property is shown, the recommended convention is to precede the "type-derived" compartments shown on an ibd with a colon.
    The revised text below establishes the colon prefix convention on a compartment label for any compartment which only displays contents of its type.
    Issue 11496, "It is not allowed in UML to display stereotypes of related elements," also noted the use of "secondary references" on both activities and blocks, including allocations on parts. Chapter 11 Activities already provides specific diagram extensions to display stereotypes of a defining element on a CallBehaviorAction, ObjectNode, or parameter. The colon prefix can also be used on an "allocatedFrom" or "allocatedTo" compartment label, as defined in Chapter 15 Allocations, to distinguish an allocation already established on the type of property from the property itself. At least some of the cases itemized by Issue 11496 are covered either by the explicit diagram extensions on activities or the use of compartments from a property type on an ibd.

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

Section 7.1

  • Key: SYSML11-76
  • Legacy Issue Number: 11814
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The current paragraph describes comments as follows: "Comments can be associated with any model element and are quite useful as an informal means of documenting the model. The comment is not included in the model repository." If comments and their extensions (e.g., rationale, problem, etc) are not stored in the model repository, then they would not be retrievable when the model is next opened. This would make filling them out a waste of time. Please determine what is meant here and correct it.

  • Reported: SysML 1.0 — Wed, 12 Dec 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The sentence "The comment is not included in the model repository." is not correct. The comment element is part of the metamodel and it's instantiations are stored in the repository.

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

Rate stereotype attribute

  • Key: SYSML11-75
  • Legacy Issue Number: 11691
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Figure 11.8, page 98, defines a "rate" stereotype attribute typed as InstanceSpecification.
    In section 11.3.2.8, page 101, one can read "The rate stereotype has a rate property of type ValueSpecification".
    There seems to be an inconsistency here.

    I assume the relevant type for the "rate" stereotype attribute is ValueSpecification. Please can you confirm?

  • Reported: SysML 1.0 — Tue, 27 Nov 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 16.2.1

  • Key: SYSML11-74
  • Legacy Issue Number: 11656
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The callout notation used in the Diagram Elements tables in 16.2.1 of the Requirements Chapter (pg 144-146)is inconsistent with the callout noation in the Diagram Elements tables in 15.2.1 of the Allocation chapter (pg 130). The text in the callout in Requirements starts with a capital letter and the text in the callout in Allocations starts with lower case. Make them consistent.

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

    No Data Available

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

Section: 8.3.2.2

  • Key: SYSML11-73
  • Legacy Issue Number: 11655
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    A block stereotype should be applied to any subclass of a block. Add a constraint to the block stereotype in 8.3.2.2 to reflect this.

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

    Add the suggested constraint not only to Block, but also to ValueType and ConstraintBlock.
    Issue 12255 is also being closed as duplicate with this one. It referred more generally to "Generalization of stereotyped elements" but all the examples it raised were within Blocks or related stereotypes, which is within the scope of this resolution

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

Section: 11.4

  • Key: SYSML11-72
  • Legacy Issue Number: 11654
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    There is reference to timelines in 11.1.5. This is widely considered a critical capability for SysML, but there is not example in the spec. Add a usage example of an activity diagram with timing constraints and the corresponding timing diagram as referred to in 11.1.5.

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

    Revise to show an example if timing constraints on activity diagrams. The portion of the issue concerning timing diagrams is not addressed by this resolution. It can be refiled as a separate issue.
    A specialized notation for time and duration constraints (e.g., straight lines and arrows associated with the constraints) and more sophisticated examples (e.g., illustration of the time and duration Observation concepts of the Simple Time Model) in Activity diagrams, as supported by UML sequence diagrams, can be considered in separated issues.

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

Section: 16.3.2.7

  • Key: SYSML11-71
  • Legacy Issue Number: 11652
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The verify relationship currently constraints one of its ends to be a test case. There have been several cases where this is too restrictive. In particular, sometimes it is useful to verify a requirement via analysis and leverage parametrics. In this case, it one may want to verify the reuqirement using a constraint block, block, or constraint property. The proposal is to delete the constraint that a requirement can only be verified with a test case which reads as follows: [2]The client must be an element stereotyped by «testCase» or one of the «testCase» subtypes. In addition, the description should be changed as follows: From: A Verify relationship is a dependency between a requirement and a test case that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) test case to the (supplier) requirement. To: A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) to the (supplier) requirement. There were two changes to the above description text. add 'or other model element', delete 'test case'

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

    Accept the proposal to delete the constraint.

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

Section: 9.3.2.

  • Key: SYSML11-70
  • Legacy Issue Number: 11651
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    In 9.3.2.7, the Standard Port is listed as a stereotype, yet it is not shown as an extension in Figure 9.1. The Standard Port should either be included in Figure 9.1 as a stereotype or removed from the list of stereotypes in 9.3.2.7. Since the only change is a change of name, I propose leaving it in as a stereotype, but clarifying that the only extension is a name change.

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

    1) Remove StandardPort from the list of stereotypes in 9.3.2.7. The content of section 9.3.2.7 already exist in section 9.1.1 albeit phrased differently. The text of section 9.3.2.7 is merged with section 9.1.1 with no loss of information.
    2) As a side-effect, all references to the abstract syntax element "SysML::Ports&Flow::StandardPort" are changed to "UML4SysML::Port" in Table 9.1 and 9.2
    3) Finally, a section 9.3.2.5 is added to explain that the name change from "Port" to "StandardPort". This section is also used to explain the "StandardPort" compartment introduced in Table 9.1

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

Section: 9.4

  • Key: SYSML11-69
  • Legacy Issue Number: 11650
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The outline indenture for the Atomic Flow Ports (9.4.1.1) and non Atomic Flow Ports (9.4.1.2)usage examples is incorrect. They should be 9.4.2 and 9.4.3 respectively.

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

    Update indentures per above

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

SysML Interactions

  • Key: SYSML11-68
  • Legacy Issue Number: 11648
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    In the notation table for sequence diagrams there is no reference to interaction parameters, or to arguments of interaction uses.

  • Reported: SysML 1.0 — Thu, 15 Nov 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Supply identified missing notation in table 12.1.

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

Section: 5.1

  • Key: SYSML11-67
  • Legacy Issue Number: 11629
  • Status: closed  
  • Source: ( Fred Waskiewicz)
  • Summary:

    Replace horrific long UML URL with short form: http://doc.omg.org/formal/2007-02-03

  • Reported: SysML 1.0 — Tue, 23 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Implement the requested form of URL reference.
    For consistency with references elsewhere in the spec, include the URL form of reference only in Chapter 2 Normative References, and refer to specifications only by name elsewhere in the spec

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

SysML:Ports can't be blocks

  • Key: SYSML11-66
  • Legacy Issue Number: 11628
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Apparently from 9.3.2.3 while you can type a flowport by a block, that block indicates the things that flow over the port.

    A more intuitive interpretation would be that the flowport is a block. Most flowports appear to be physical things that may convey blocks.

    Without the ability to indicate the physical thing that is the block, you lose the ability to specify it, reuse it, define it, etc.

    It’s much more intuitive to indicate that the flowport is a

    US-110voltACmale

    In addition, for example, in Figure B.19. There are flowpoints named

    Port:FuelTankFitting

    Port:ICEFuelFitting

    Based on section 9.3.2.3, these flowports convey Fittings, not Fuel.

    There needs to be a way, preferably graphically, that would indicate that the type of Flowport is a block, and in that block, allow for the definitiaojn of what flows.

  • Reported: SysML 1.0 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Ports are properties, so cannot be blocks, but the resolution of issue 13178
    clarifies that some ports represent a new, potentially physical, element in the
    system (full ports). These can be typed by blocks that have flow properties as
    well as other kinds of properties, as suggested above. Some ports do not
    represent a new element in the system (proxy ports). Flow specifications and
    non-atomic flow ports are deprecated.as redundant.

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

Section: Appendix E

  • Key: SYSML11-65
  • Legacy Issue Number: 11626
  • Status: closed  
  • Source: ( Fred Waskiewicz)
  • Summary:

    The following text cites two OMG documents: "The OMG SysML requirements traceability matrix traces this specification to the original source requirements in the UML for Systems Engineering RFP (ad/2003-03-41). The traceability matrix is included by reference in a separate document (ptc/2007-03-09)." Someone unfamiliar with the OMG process has no way of knowing how to obtain these two documents. They should be cited by URL; e.g., http://doc.omg.org/ptc/2007-03-09

  • Reported: SysML 1.0 — Mon, 22 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Use URL references as suggested.

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

Address potential points of convergence between MARTE and SysML

  • Key: SYSML11-64
  • Legacy Issue Number: 11623
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Address potential points of convergence between MARTE and SysML The MARTE profile supports modeling and analysis of real-time and embedded systems. Some of the concepts defined in this specification are applicable to Systems Engineering practices and can be of interest to SysML users. Early interactions between the SysML and MARTE partners have allowed to identify convergence points: - support for value expressions and constraint expressions using a dedicated language - formalisation of a time model, including the notion of clock to measure time - definition of metamodel elements for units and dimensions As discussion goes on, other convergence points may be identified and added to this list. Working on an alignment between MARTE and SysML has been identified as an important opportunity for both groups.

  • Reported: SysML 1.0 — Thu, 18 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Following is the discussion from a previous deferred resolution by the SysML 1.1
    RTF:
    Much useful interaction and review of material from both MARTE and
    SysML has occurred within the RTF, especially on topics such as
    definition of quantity types, models of time, the need for value
    specifications, and the need to align allocations. Some opportunities for
    alignment can continue to be addressed in resolutions to other, more
    specific issues. This more general issue, however, will also be deferred,
    so that many remaining opportunities for alignment can continue to be
    pursued. Some specific areas of possible alignment, such as support for
    expressions in the MARTE Value Specification Language (VSL), are
    premature until the MARTE specification has completed its finalization.
    Ongoing discussion and development of potential common elements is
    continuing to occur between the SysML and MARTE RTF's. This generic
    placeholder issue should now replaced by specific issues that address specific
    points of alignment between the two specifications.
    Disposition: Closed, no change

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

Section: 8/3

  • Key: SYSML11-63
  • Legacy Issue Number: 11622
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Mapping of PropertySpecificType to the UML metamodel requires further explanation Chapter 8 introduces the notion of property-specific type to assign values to parts inside an ibd. Section 8.3.1.1 defines a notation for property-specific types. Section 8.3.2.8 provides a definition of the <<propertySpecificType>> stereotype and gives elements on how this concept maps to the UML metamodel. However, this section does not explicitly define: 1) where are stored the actual values? One may understand that a default value of a property owned by a class, which is stereotyped as <<propertySpecificType>>, is considered as a property-specific value. This property-specific value may be considered as an instance of a property owned by the refrenced block. It is not clearly stated though. 2) how does a property-specific type relate to the referenced block ? In other words, if a class is stereotyped as <<propertySpecificType>>, which feature of this class points to the referenced block? We may need to add a paragraph in section 8.3.2.8 that provides answers to questions.

  • Reported: SysML 1.0 — Thu, 18 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    A property-specific type defines a new specialization of a single existing classifier, which was used to type a single property in the definition of a block which owns that property. The PropertySpecificType stereotype is used in the SysML metamodel to distinguish a classifier created by this mechanism from classifiers created by all other forms of user definitions.
    Within the property-specific type, new or redefined properties or other features such as operations may be defined. Within a property defined within a property-specific type, one option is to specify a default value. As the resolutions for issues 10473 and 11502 indicate, however, an initialValues compartment may be used instead of a property-specific type if all that is needed are context-specific values and not a more customized definition of the classifier that types a property.
    If the property-specific type is used to define a feature that carries its own default value, that default value is specific to that property. The default value of a property owned by a classifier carries its value by means of a UML ValueSpecification. It is not considered as an instance of the property, and the classifier provides only the definitions of its properties and not any instance to be referenced.
    The suggestion to add a paragraph to Section 8.3.2.8 to better explain the PropertySpecificType stereotype is valid, and Issue 11308 also requested somewhat less obscure explanation of the meaning of this stereotype. A full explanation of the representation of the metamodel representation of a property-specific type would benefit from examples of metaclass instances that could be represent specific example models, but the SysML specification does not currently include such metamodel instance examples. The revised text below is intended as an initial start toward a somewhat less opaque explanation, but falls short of full metamodel examples or other forms of explanations which could still be considered for future revisions of the spec.

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

SysML specification for containment relationship

  • Key: SYSML11-62
  • Legacy Issue Number: 11612
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    this about the interpretation of the the containment
    relationship and its
    implementation on the tool side.

    We are using MagicDraw 14.0 and SysML 1.1sp2.

    As soon as a containment relationship is created between two
    requirements the
    contained requirement is automatically relocated to the package
    of the container. This prevents distribution of requirements
    in different
    packages, in particular if a contained requirement belongs to
    a subsystem.
    I would like to properly distribute them.

    We have a requirement A which contains requirement B and C.
    A is a requirement on very high level of the system which is decomposed into
    requirements B and C on a subsystem level.
    To avoid to have all requirements together (because B and C
    belong to the
    subsystems) we want to put A, B and C in different packages
    but still have
    the containment relationship (as foreseen by the SysML spec.)
    that's why I think it is different from a package containment. They
    are not the same.

  • Reported: SysML 1.0 — Mon, 15 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

SysML dimensions

  • Key: SYSML11-61
  • Legacy Issue Number: 11600
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Inconsistency among valuetype/unit/dimension

    In Figure 8.4 p 43, the following multiplicities are given

    A valutype may (0..1) have a unit and may have a (0..1) dimension

    A unit may (0..1) have a dimension.

    On page 49. there is a constraint

    Constraints

    [1]If a value is present for the unit attribute, the dimension attribute must be equal to the dimension property of the referenced unit.

    This would mean that if the unit’s dimension is null, then the valutype’s dimension must also be null. This seems overly constraining.

    In 8.4.2, it says

    Because a unit already identifies the type of quantity, or dimension, that the unit measures, a value type only needs to identify the unit to identify the dimension as well.

    This statement seems to say the unit must have a dimension, and the valuetype’s dimension can be null even though the unit’s is not. This statement therefore disagrees with the Figure 8.4 and the constraint on page 49

  • Reported: SysML 1.0 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.1
  • Disposition Summary:

    Discussion:
    This issue is being deferred as part of the same overall discussion and
    consideration noted under the resolution for Issue 12128, “8.3.2.9 Unit, 8.3.2.10
    ValueType.” As noted there, the scope of any potential changes to the current
    ValueType, Unit, and Dimension metamodel has ended up beyond the workload
    that could be completed during this RTF. Relaxing the current constraints, as well
    as extensions or changes to the current model, should continue to be evaluated
    for future versions of SysML. In the meantime, a workaround could be to define
    new units if necessary to carry different dimensions. The statement in Section 8.4.2 is in a usage example for the definition of value
    types with SI units. It is not intended to imply that a unit must have a dimension,
    just that if a unit does already identify a dimension, the dimension need not also
    be specified. This language could be further clarified if needed in future updates
    of the specification.
    Disposition: See issue 12219 for disposition

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

SysML -- Fix for Fig 9.4 p70.

  • Key: SYSML11-60
  • Legacy Issue Number: 11599
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    On Fig 9.4 p 70. the I_ICEData I/F has the following services defined on the cntrl (the engine)

    getRPM():Integer

    getTemperature():Real

    isKnockSensor():Boolean

    These names make sense if the interface was a provided interface on the engine.

    However, the I_ICEData interface on the engine is a REQUIRED interface.

    The interface should be defined something more along the lines of…

    hereIsRPM(:Integer)

    hereIsTemperature(:Real)

    hereIsKnockSensor(:Boolean)

    as the engine is using this interface to tell the PowerControlUnit the current values of those properties.

    This problem is duplicated later in Figure B.20 on p 194

  • Reported: SysML 1.0 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

8.3.1.3 UML Diagram Elements not Included in SysML Block Definition Diagram

  • Key: SYSML11-59
  • Legacy Issue Number: 11591
  • Status: closed  
  • Source: No Magic, Inc. ( Andrius Strazdauskas)
  • Summary:

    "An “X” on a single end of an association to indicate that an end is “not navigable” has similarly been dropped, as has the use of a small filled dot at the end of an association to indicate an owned end of an association."

    In this text I see two mistakes:

    1. "filled dot" notation is used for ends owned by associated classifier, not owned by association (an opposite situation).

    2. "owned end of an association" does not mean it is not navigable. Association has "navigableOwnedEnds" property for navigable owned ends.

  • Reported: SysML 1.0 — Tue, 2 Oct 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Correct the descriptions of the UML notations which SysML excludes.
    The statement about an "X" on the end of an association does seem consistent with this statement from the UML Superstructure spec, under 7.3.3 Association, "Notation" subsection:
    A small x on the end of an association indicates the end is not navigable.

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

optional parameter section

  • Key: SYSML11-58
  • Legacy Issue Number: 11523
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Is it allowed to attach the optional stereotype to outgoing parameters? The definition mentions only ingoing parameters: "This means the parameter is not required to have a value for the activity or any behavior to begin execution."

  • Reported: SysML 1.0 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Amend the cited sentence to indicate optional out parameters do not need to have values to end execution.

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

PropertySpecificType concept is highly ineffective and suboptimal

  • Key: SYSML11-57
  • Legacy Issue Number: 11502
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    PropertySpecificType concept is highly ineffective and suboptimal. It requires to redefine all structure from very root context if some deep nested part should use different configuration. So one should redefine all car internal structures if one bolt should be changed or color should be different

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Wrong ends of Allocate relationship used in Allocated definition

  • Key: SYSML11-56
  • Legacy Issue Number: 11501
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Writer of this issue correctly points out an inconsistency between the text in section 15.3.1.1, 15.3.2.1, and 15.3.2.2, with respect to the client and supplier ends of the allocation relationship. Text will be modified to resolve this inconsistency.

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

View as Package extension is very bad idea

  • Key: SYSML11-55
  • Legacy Issue Number: 11500
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    View as Package extension is very bad idea. Package is used for ownership, so it is not possible to show the same elements in different packages (as different point of view)

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

<>

  • Key: SYSML11-54
  • Legacy Issue Number: 11498
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    <<continuous>> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too.

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Mixed action and activity concepts

  • Key: SYSML11-53
  • Legacy Issue Number: 11497
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Mixed action and activity concepts. B.35, B.36, B.37 - concepts of activity and action are mixed (action is allocated, but activity is in tabular notation)

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Update referenced figures to represent allocation of usage (Action to Part).
    Update figure B.35 to use colon notation for the part represented by the
    AllocateActivityPartitions. Note that this proposal also resolves issues #12148,
    12149, 12150, 12151 and 12153

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

Constraint parameter notation conflicts with UML private ports notation

  • Key: SYSML11-52
  • Legacy Issue Number: 11495
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Constraint parameter notation conflicts with UML private ports notation. How to distinguish between part and ports if notation is the same?

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This issue is being deferred because no proposed resolution was voted on during
    the schedule of the SysML 1.3 RTF.
    Disposition: Deferred The private port notation, in which a port located inside a containing rectangle had
    more restricted visibility than ports placed on the boundary of the rectangle, was
    included in UML 2.0 but removed in subsequent UML revisions. SysML specifies that
    all ports be placed on the rectangle boundary.
    SysML specifies its own specific notation for constraint properties and their constraint
    parameters within a parametric diagram, in which the constraint parameter must be
    shown flush inside the boundary of a constraint property.
    The constraint property also has its own specific notation as a round-cornered
    rectangle. No conflict with any UML notation is present within this specific diagram
    context.
    Disposition: Closed, no change

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

Association branching is not defined in UML

  • Key: SYSML11-51
  • Legacy Issue Number: 11494
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Association branching is not defined in UML. Mapping is not clear. Composition tree is not defined in UML, mapping is not clear.

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Uppercase/lowercase problems

  • Key: SYSML11-50
  • Legacy Issue Number: 11492
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Uppercase/lowercase problems. Stereotype names are defined in upper case, but in diagrams are displayed in lower case (e.g. Block and <<block>>). Attributes(tags) are displayed in uppercase in diagrams, but are defined in lower case in the specification.

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

<> is displayed as dependency (in examples)

  • Key: SYSML11-49
  • Legacy Issue Number: 11491
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    <<satisfy>> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used)

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

    Discussion:
    A resolution for this issue was never completed during the SysML 1.1 RTF, but
    the issue raised was resolved by Issue 11269 in SysML 1.1. Issue 11269 had
    the identical title, «satisfy» is displayed as dependency, and had the following
    description:
    It is not explicitly mentioned that SysML changes the notation for the
    satisfy relationship. It is a stereotyped realization relationship and should
    be notated as a dashed line with a triangular arrowhead. But SysML uses
    a simple arrowhead.
    The change made by resolution of 11269 was to change «satisfy» to be a
    stereotype of Trace rather than Realization (the same as the DeriveReqt, Verify,
    and Copy dependencies), which resolved the discrepancy in the notation.
    This issue should have been resolved by the SysML 1.1 RTF as
    Duplicate/merged with Issue 11269. To correct the oversight, this resolution will
    close the issue as part of the SysML 1.2 RTF.
    Disposition: See issue 11269 (in the SysML 1.1 RTF Report) for
    disposition

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

Requirements are abstract

  • Key: SYSML11-48
  • Legacy Issue Number: 11490
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Requirements are abstract (isAbstract must be true). However name of the requirement are not displayed in italic as defined in UML notation

  • Reported: SysML 1.0 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    (This discussion is elaborated from RTF Telecon Minutes 2008-02-13 &
    2008-02-13)
    This issue asks that the name of a requirement be in italics, in keeping with the rules on UML classes when isAbstract is True. This raises the following questions:
    1. Do requirements need to be abstract? In order to answer this, we need to address the following.
    2. Do requirements need subclasses? SysML does not currently support any form of subclassing of requirements.
    3. How robustly do requirements need to support properties? Are static properties necessary?
    One philosophy considers that if requirements had any features such as properties, they could be only static features that applied to the entire requirement class and not to any instance, which was part of the rationale for the isAbstract = True constraint.
    If static properties were supported on SysML requirements, along with adding specialization (subclassing) relationships between requirements, they could support a more complete form of property-based requirements in addition to their current support for text-based requirements. This would more closely parallel the requirements capability in STEP AP233, which has support for both text- and property-based requirements. It would also allow performance requirements to be stated by defined property values that could participate in parametrics or other analysis.
    In the original submission, however, the SysML model of requirements has been left deliberately simple without further detail for modeling the system itself, in part so SysML would more closely match the scope and structure of typical requirements specifications which have simple containment models of text-based statements. Associating properties with requirements relied on linking requirements to highly abstract models of system structure, built using SysML blocks, and providing a skeleton model of system structure to which properties would belong. This is appropriate because the properties are typically of the system, rather than of the requirement, e.g. "the car shall weigh less than 3000lb" implies that weight is a property of the car. This approach also provides a more extensive means to capture properties and other details of an evolving system very early in its specification process. This option remains available in SysML to model greater detail about requirements that need to go to a greater level of detail or precision.
    This remains a clear and consistent approach to SysML requirements, and should not be reconsidered at this time. The decision of this resolution is not to add any additional support for requirements subclassing or properties in this revision of SysML. Separate issues could be raised for future revisions of SysML to consider adding requirements subclassing or properties, but such an addition is outside the scope of this issue, which seeks only to make the font of requirement names consistent with the isAbstract attribute.
    Given the lack of subclassing for SysML requirements, the constraint on isAbstract has no added semantics and could be constrained either way. The main issue at this point is simply whether the names of requirements should be in italics or not. Forcing the names into italics, to be consistent with the current constraint, would change the notation defined by the current specification and used in all the current requirements examples. Removing the current constraint will allow tools to keep the name consistent with the setting of the isAbstract attribute. The same resolution should apply to Viewpoint in Chapter 7, which has the same constraint on the isAbstract attribute.

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

Question on PropertySpecificType

  • Key: SYSML11-47
  • Legacy Issue Number: 11308
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    Can anybody elaborate on the following definition of PropertySpecificType : “The PropertySpecificType stereotype is automatically applied to a classifier created by the notation for a property-specific type for a property belonging to a SysML Block or ValueType. It identifies these classifiers so that they may be managed along with the property that they type.”

    It is quite obscure to me to understand its meaning?

  • Reported: SysML 1.0 — Tue, 28 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 8.3.2 Unit/Dimension Notation

  • Key: SYSML11-46
  • Legacy Issue Number: 11275
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I miss a explicit statement that SysML changes the standard notation for instance specifications. According to that the name of dimensions and units must be underlined

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    As the issue notes, the notation that SysML defines for Dimension and Unit differs the standard UML notation for InstanceSpecification. Revise the subsection for Unit and Dimension under 8.3.1 Diagram Extensions to describe the specific notation that SysML defines for these two elements. Revise the text for how stereotype properties of Unit and ValueType reference these elements.

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

Section: Annex A: Diagrams

  • Key: SYSML11-45
  • Legacy Issue Number: 11274
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The list of diagram kinds and abbreviations should contain the non-normative table and matrix diagram kinds

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The table and matrix diagram kinds are rarely mentioned in appendix A. To have a complete overview of all diagram kinds they should be added to the bullet lists.

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

Section: 16 Requirements

  • Key: SYSML11-44
  • Legacy Issue Number: 11271
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The nesting of requirements has the semantics that the upper requirement is fulfilled if all it's sub-requirements are fulfilled. In addition we need a mechanism to express a xor between sub-requirements sets to support variant modeling. If a requirement can be satisfied by different system components, these system components have different technically requirements. These requirements are sub-requirements, but a subset of them that relates to one of the system components is sufficient to fulfill the upper requirement. It is not necessary to fulfill all sub-requirements

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Issue may be accomplished by modeling style (e.g. use package containment for
    “x-or” instead of requirement containment). No need to encumber SysML with
    Boolean operators for requirement satisfaction or containment.
    Disposition: Closed, no change

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

Section: 8.3.2.8 ValueType

  • Key: SYSML11-43
  • Legacy Issue Number: 11270
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The types of the attributes dimension and unit must be Dimension and Unit instead of ValueType according to Fig 8.4.

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Fix the type of the unit and dimension attributes on ValueType as suggested, and to match that abstract syntax shown in Figure 8.4.

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

Section: 16 Requirements

  • Key: SYSML11-42
  • Legacy Issue Number: 11269
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    It is not explicitly mentioned that SysML changes the notation for the satisfy relationship. It is a stereotyped realization relationship and should be notated as a dashed line with a triangular arrowhead. But SysML uses a simple arrowhead.

  • Reported: SysML 1.0b1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The desired notation is that a "satisfy" dependency be displayed with an open arrowhead like all the other dependencies between SysML requirements. Rather than specialize Realization, which carries its notation of a closed arrowhead, change the the abstract syntax shown in Figure 16.1 to have Satisfy specialize UML Trace, like all the other dependencies defined in this figure.

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

Section: 11.3.1.1

  • Key: SYSML11-41
  • Legacy Issue Number: 11118
  • Status: closed  
  • Source: International Business Machines ( Eldad Palachi)
  • Summary:

    Using black-diamond composition for functional decomposion is confusing and misleading since the owner Activity does not contain other activity in the sense that they have the same life span and obvuisly since different CallVehavior are used to invoke the activities, these activites may actually be carries out one after the other. We propose that either another relationship is used to signify functional decomposition or a hierarchy of Activity Diagrams should be used.

  • Reported: SysML 1.0b1 — Wed, 4 Jul 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Chapter 7-17

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

    Add clarification and precision to the specification by replacing the natural language constraints with OCL constraints. This is a general issue that applies to constraints on stereotypes within Chapters 7-17 of the specification. It is appropriate to address this on a priority basis to selected constraints that are ambigous due to their natural language representation, and where OCL can reduce their ambiguity.

  • Reported: SysML 1.0 — Wed, 6 Jun 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    In keeping with the request to “address this on a priority basis to selected
    constraints,” SysML 1.2 is beginning to include its first limited set of OCL
    constraints to supplement the current natural language statements of constraints.
    In addition to an OCL constraint included in the resoluton of Issue 12129 in
    Chapter 10 Constraint Blocks, this resoluton includes an OCL constraint for one
    more existing constraint.
    Since continuing to supply OCL versions of constraints will be an ongoing effort
    over multiple revisions of SysML, new versions of this issue should continue to
    be raised for consideration by future RTF’s. This issue number, however, is
    being resolved so that it can provide a place to provide the statement of a
    specific OCL constraint not included in any other issue resolution.

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

Namespace compartment for blocks

  • Key: SYSML11-39
  • Legacy Issue Number: 11066
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    We build the structure of a system on the block definition level by composition
    and not by namespace containment. We also use this approach in the sample problem.
    Therefore I would like to use a block compartment to show a bdd of all owned elements
    by composition and not by namespace containment. I don't know any good example where to
    use the namespace compartment or the namespace containment relationship.

    Should we change the namespace compartment to a owned element compartment?
    Do you know good examples when to namespace containment vs. composition?

    By the way the concrete syntax of the namespace containment in the sysml spec isn't
    defined in the uml specification

  • Reported: SysML 1.0 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 11.3.2.2

  • Key: SYSML11-38
  • Legacy Issue Number: 10641
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    What happens if a control value disables an action within an activitz and no other actions are active and no more tokens are present?

  • Reported: SysML 1.0b1 — Sat, 3 Feb 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Appendix B

  • Key: SYSML11-37
  • Legacy Issue Number: 10602
  • Status: closed  
  • Source: Thematix Partners LLC ( Rick Steiner)
  • Summary:

    Figure B.16, B.18, and B.26 do not use white diamond notation for referenced properties. Please update these figures to use white diamond

  • Reported: SysML 1.0b1 — Sat, 20 Jan 2007 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    1.1 spec (“shared AggregationKind” – text update per issue 12142). Updating
    Figure B.16 should be done for consistency. Figure B.26 does not immediately
    lend itself to “shared AggregationKind”, so will remain unchanged.

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

SysML doesn't explicitly support the modeling of alternative models

  • Key: SYSML11-36
  • Legacy Issue Number: 10587
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    SysML doesn't explicitly support the modeling of alternative models for example for trade studies as requested by the UML for Systems Engineering RFP. Models and Packages are not useful, because they don't allow to exclude elements. For example to specify a xor between requirements (if reqA is used, then don't use req B). Same for blocks and other model elements.

  • Reported: SysML 1.0b1 — Thu, 11 Jan 2007 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    This issue was previously deferred by the SysML 1.1 RTF with the following
    discussion at that time:
    A full resolution of this issue is beyond the scope of an RTF. The issue is
    being deferred, however, so that additional explanatory material could be
    considered in a future RTF to clarify the scope of modeling supported by
    SysML or to suggest possible workarounds. A full resolution of this issue
    could be considered in an RFP for SysML 2.0.
    Addition of support for modeling of alternative models was considered to be
    beyond the scope of an RTF, so this issue is being closed. Requirements or
    proposals to add such support can be considered under a future RFP.
    Disposition: Closed, no change

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

Section 16.3.2.3

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

    We do not agree with a systematic propagation rule of sub-requirements when copying requirements. That introduces useless constraints in contractual contexts that have their own rules.

  • Reported: SysML 1.0b1 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Agreed. Propagation rule is unnecessary and should be deleted

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

15.2.1Representing Allocation on Diagrams

  • Key: SYSML11-34
  • Legacy Issue Number: 10539
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Allocation arrows direction seems to be opposite to UML dependency rules. We do ne think it is a good idea ?

  • Reported: SysML 1.0b1 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Related to issue 11501 (resolved in RTF 1.1), and 12139, making the spec
    consistent. The arrowhead must always represent the “AllocatedTo” end of
    the dependency, since any other direction would be counterintuitive, and the
    derived property of the model element at the arrowhead end must be
    “AllocatedFrom XXX”, where XXX is the model element at the other end of the
    allocation dependency. Similar concept to “Trace” relationship - see issue 10343.
    Which end of the dependency is client and which is supplier is unimportant in
    practice, and invisible to the user. Allocation is based on Abstraction (UML 2.1.2
    Superstructure Section 7.3.1), which accommodates various directionality and
    mappings. Linguistic merits of directionality may be debated, but at this point
    Table 15.1 and Section 15.2.2 are consistent and no further changes are
    required.
    Disposition: Closed, no change

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

7.1 Overview

  • Key: SYSML11-33
  • Legacy Issue Number: 10538
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    As previously mentioned in our 2004 review; a rationale must be considered as a class, that has its own lifecycle and its own access rights.
    It is not only a simple UML comment extension.

  • Reported: SysML 1.0b1 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Lifecycle and access right management is out of scope of SysML. The resolution
    has been discussed with the author of the issue who agrees to close the issue
    without any change.
    Disposition: Closed, no change

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

Constraint parameter stereotype

  • Key: SYSML11-32
  • Legacy Issue Number: 10524
  • Status: closed  
  • Source: ( Fraser Chadburn)
  • Summary:

    Can anybody clarify the definition of a constraint parameter for me?

    To quote the SysML spec:
    [1]The type of a constraint property must be a constraint block.

    So a constraint parameter is not a constraint property typed by a value type or something like that...

    To quote again:

    "A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block define the parameters of the constraint."

    So does this mean that a parameter is a block property (or an ordinary property)?

    Would it make sense to add a <<constraint parameter>> stereotype to constraint blocks? Has this been suggested or does it make sense?

  • Reported: SysML 1.0b1 — Wed, 13 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Figure 17.4.2

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

    In Figure 17.4.2’s explanation, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an “isEncapsulated” property (defined elsewhere in the spec).

    This is very confusing. The text should be corrected to indicate that all properties of the Block stereotype (e.g., “isEncapsultated), even if not indicated on the diagram, would be inherited by the stereotypes «system» and «context» An alternative fix that also corrected the diagram would perhaps be better but more effort.

  • Reported: SysML 1.0b1 — Mon, 18 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    In Figure 17.6, replace Block symbol with the Block stereotype definition shown in Figure 8.2.
    In the paragraph after Figure 17.6, remove "(in this case none)" from the 4th sentence.

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

Section: figure 17.6

  • Key: SYSML11-30
  • Legacy Issue Number: 10511
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It is unclear in this diagram what the element that this bdd is for (a package?) However, the elements on this diagram are metaclass and stereotype elements, which I believe are the wrong metalevel for bdd diagrams. This is really a notional metaclass diagram indicating how SysML might be extended, but it is not a SysML diagram itself

  • Reported: SysML 1.0b1 — Sat, 9 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The best solution is to use package diagrams to describe profiles.

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

Section: Annex A

  • Key: SYSML11-29
  • Legacy Issue Number: 10510
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Annex A, the bdd is indicated that it can only be for blocks, pkgs, and constraint blocks. [A previous issue was raised that this list should include activities]. This list is incomplete; it should probably include all SysML-allowed stereotypes (and extensions) of class (perhaps classifier), including signal, actor, interface, etc. Even if such elements are not allowed to be model elements for the diagram, they should be explicitly allowed as elements on a bdd. Similarly the allowed elements for and on an ibd should be clarified.

  • Reported: SysML 1.0b1 — Sat, 9 Dec 2006 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    The above reference to Annex A (Section A.1 pg 173) is not referring to model
    elements that can appear on a block definition diagram, internal block diagram or
    any other diagram. It is referring to the type of model element that is represented
    by the frame of the diagram. As a result, this is a misinterpretation of the content.
    It is felt that the description is adequately clear, so no change is required.
    The type of model elements that can appear on a diagram are specified in the
    applicable chapter as described in the last paragraph on pg 172 in Annex A.
    Disposition: Closed, no change

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

Section: 17.4.2

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

    In the explanation for Fig 17.4.2, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an "isEncapsulated" property, described elsewhere in the specification (p. 46) This is very confusing. The text should be corrected to indicate that the property isEncapsulated of the Block Stereotype is inherited by the stereotype system and concept

  • Reported: SysML 1.0b1 — Fri, 8 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Disposition: See issue 10517 for disposition

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

Section: 11 Activities

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

    Several places in the spec, it is indicated that behaviors can be shown on block and class diagrams. As SysML does not support class diagrams, it should be changed to block diagrams only. See text on 11.1.1.1; 11.3.1.1(3x);11.3.1.4

  • Reported: SysML 1.0b1 — Mon, 4 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Use ""block" instead of "class" unless specifically referring to UML.

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

Section: 11 Actibities

  • Key: SYSML11-26
  • Legacy Issue Number: 10501
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Brake is spelled Break twice on this page, once in the paragraph between the figures and once in figure 11.141

  • Reported: SysML 1.0b1 — Mon, 4 Dec 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Chapter 8, Blocks, instance specifications for default values

  • Key: SYSML11-25
  • Legacy Issue Number: 10473
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    The exclusion of UML concrete syntax for Instance Specifications has resulted in the inability to assign default values to properties of blocks using anything other than simple text strings for value properties. Consider reintroducing UML concrete syntax for UML InstanceSpecification into one or more SysML diagram types so that more complex default values can be assigned.

  • Reported: SysML 1.0b1 — Mon, 27 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Change the specification of the defaultValue compartment to base its internal metamodel representation on UML InstanceValue, and to decouple the representation of context-specific property values entirely from property-specific types. Also rename the compartment to "initialValues" to more accurately indicate the ability of these compartments to provide values which are assigned in a local property-specific context to override of any existing default or initial values defined on underlying blocks that may type a property.
    As background, this issue was previously deferred by the FTF with the following discussion comments:
    The defaultValue compartment on an internal block diagram does provide at least one available option for assigning default values to structured values, as discussed in the subsection "Default value compartment" under 8.3.1.3 Internal Block Diagram. Creating a graphical compartment on an internal block diagram to assign values to properties defined on a block definition diagram may be more cumbersome than a textual syntax, but tools may be able to streamline the linkage to the default value for usability. In particular, the use of a "structure" compartment on a block definition would allow the default value to be shown next to a properties compartment where a property is defined.
    Other work in OMG is currently underway that may define a standardized form of textual syntax for value specifications. SysML could consider such a textual syntax for property values in future versions.
    The scope of this resolution is to clarify the graphical syntax and internal metamodel for the "initialValues" compartment that may be shown on properties on an internal block diagram. Other issues, such as 12277 and 12353, request additional support for display of context-specific values using forms of concrete syntax for UML InstanceSpecification or else additional forms of compartments on properties on an ibd. These issues are being deferred, but can be reconsidered in the future following this initial step to clarify the initialValues compartment, as included in the scope of this resolution. Other forms of textual syntax for complex values, such as the MARTE Value Specification Language (VSL), could also be considered by future issue resolutions following the current RTF.
    Issue 11502, "PropertySpecificType concept is highly ineffective and suboptimal," has its own resolution of Closed, no change, but this resolution is based partly on the ability of the initialValues compartment to remove one of the major reasons why property-specific types might need to be used. Instead, use of the more complicated property-specific type mechanism can be reserved for cases in which new or redefined features are really needed in a new specialized property-specific type, rather than merely an assignment of local values. See the resolution for Issue 11502 for more information.
    Issues 12361, "defaultValue should be renamed initialValue(s)," and 12363, "Decouple 'values' compartment for a part Property in an IBD from PropertySpecificType" record some of the history of working discussions by the RTF on the defaultValue compartment issue, as well as additional perspective. All specific changes to the specification are being consolidated under this issue, so these two other issues are being closed as having their resolutions merged under this one.

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

Section: 6.1 Levels of Formalism

  • Key: SYSML11-24
  • Legacy Issue Number: 10472
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Add a brief statement to Section 6.1, Levels of Formalism, to clarify that SysML reuses UML instance semantics, adapted as necessary for description of systems. A brief statement of UML instance semantics can be found in the UML Superstructure specification (ptc/06-04-02) under 6.4.2, Semantic Levels and Naming, under the paragraph labeled "Instance level."

  • Reported: SysML 1.0b1 — Mon, 27 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Following is the paragraph labed "Instance level," which now appears in the
    section numbered 6.3.2 in the UML 2.4 Superstructure Specification:
    Instance level – These are the things that models represent at runtime.
    They don’t appear in models directly (except very occasionally as detailed
    examples), but they are necessary to explain the semantics of what
    models mean. These classes do not appear at all in the UML2 metamodel
    or in UML models, but they underlie the meaning of models. We provide a
    brief runtime metamodel in the Common Behavior chapter, but we do not
    formally define the semantics of UML using the runtime metamodel. Such
    a formal definition would be a major amount of work.
    Since SysML already includes the semantics of existing UML elements, except
    as specifically changed or extended by SysML, this existing language (which has
    not changed since UML 2.1) applies to SysML.
    SysML already includes the following statement in Section 6.1, which leaves
    open the option to consider further semantics in the future, but in the meantime
    leaves them open just as does UML:
    SysML is specified using a combination of UML modeling techniques and
    precise natural language to balance rigor andunderstandability. Use of
    more formal constraints and semantics may be applied in future versions
    to further increase the precision of the language.
    Given the generality of both the UML and SysML statements about formal
    semantics, no change is required to the current version of the SysML
    specification. A new issue could be raised if future versions of UML adopt a
    formal specification of semantics that would also need to be adapted or reflected
    by SysML, but such an issue should be raised against specific future changes to
    UML.
    Disposition: Closed, no change

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

Section: 9, 16, C

  • Key: SYSML11-23
  • Legacy Issue Number: 10471
  • Status: closed  
  • Source: edgewater.ca ( Cory Bialowas)
  • Summary:

    Inconsistent use of "sub-type" and "subtype". UML2 and SysML spec in general use subtype, there are a few instances of "sub-type" in the SysML spec (chapters 9, 16, and C), should be replaced with subtype.

  • Reported: SysML 1.0b1 — Fri, 24 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Change remaining occurrences of "sub-type" to "subtype". The OMG Available Specification for SysML 1.0 no longer contains any occurrences of "sub-type" in Chapter 16, but occurrences do still remain in Chapter 9 and Annex C.

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

SysML: nout-->inout

  • Key: SYSML11-22
  • Legacy Issue Number: 10446
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In SysML 9.3.2.4, the possible flow directions include

    nout

    based on later usage, this is incorrect for

    inout.

  • Reported: SysML 1.0b1 — Thu, 9 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: 7.3.2.5 Viewpoint

  • Key: SYSML11-21
  • Legacy Issue Number: 10427
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Viewpoint.Purpose[1] should probably be Purpose[*] to be consistent with the other attributes of Viewpoint. Perhaps [1..*] if needs to be mandatory.

  • Reported: SysML 1.0b1 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    No Data Available

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

Section: Annex G

  • Key: SYSML11-20
  • Legacy Issue Number: 10380
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Update Annex G to accurately specify the graphical and textual notations supported by the current SysML specification. Currently, an editorial note at the top of Annex G notes that the Annex contents are to be updated for specific diagram types during the finalization phase of the specification. Resolve the diagram types for which BNF syntax productions will be provided, and make sure that these match the notations documented in the corresponding SysML chapters.

  • Reported: SysML 1.0b1 — Tue, 3 Oct 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Annex G no longer exists in the SysML 1.0 specification. Formerly, it held BNF Diagram Syntax Definitions, but this annex was dropped by the FTF. A new Diagram Definition RFP may provide a more complete framework in which to define concrete syntax for SysML and other UML-based languages, but a separate issue should be raised to add such concrete syntax definitions when appropriate
    Disposition: Closed, no change

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

Section: Appendix B.4.5

  • Key: SYSML11-19
  • Legacy Issue Number: 10374
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The CAN_Bus shown in the ibd B.22 is missing in figure B.18.

  • Reported: SysML 1.0b1 — Wed, 27 Sep 2006 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    Recommend no change. Fig B.18 & B.19 are consistent. The CAN bus is a
    design refinement introduced after figure B.19,and does not need to be included
    in earlier figures.
    Disposition: Closed, No Change

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

How to use property specific types for atomic flow ports?

  • Key: SYSML11-18
  • Legacy Issue Number: 10371
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I would like to model an atomic flow port at a block "Battery".
    The base type is Volt (value type).
    Now I would like to show that the value is 12,5V in this context.

    If I use a property specific type, I can't show the constant value
    in my diagram. The name of my atomic flow port is:

    out:[Volt]

    Where can I show the value 12,5?

  • Reported: SysML 1.0b1 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This is issue is closed without change because atomic flow ports are deprecated
    in the resolution of issue 13178.
    Disposition: Closed, no change

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

Section: 16.3.2.4 RequirementRelated (from Requirements)

  • Key: SYSML11-17
  • Legacy Issue Number: 10343
  • Status: closed  
  • Source: ( Fraser Chadburn)
  • Summary:

    The names of tracedTo and tracedFrom appear counter-intuitive. On a <<requirement>> (p144)... /tracedTo: NamedElement[*] Derived from all elements that are the client of a <<trace>> relationship for which this requirement is a supplier. On a <<requirementRelated>> (p145)... \tracedFrom: Requirement[*] Derived from all requirements that are the supplier of a <<trace>> relationship for which this element is a client. If a trace dependency ends at a requirement therefore, it would be listed on the <<requirement>> with the property name 'tracedTo'. It is thought that most users wouldexpect this property to be called 'tracedFrom' instead. Should we swap the names of these properties around to avoid this confusion?

  • Reported: SysML 1.0b1 — Mon, 11 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Table 16.2 is correct, spec is inconsistent. 16.3.2.3 and 16.3.2.4 should be
    updated to correct attributes associated with the trace relationship.

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

Section: 9.3.2.8 ItemFlow

  • Key: SYSML11-16
  • Legacy Issue Number: 10342
  • Status: closed  
  • Source: ( Fraser Chadburn)
  • Summary:

    FlowPorts can be typed by (p64): · Block · DataType · FlowSpecification · Signal · ValueType FlowProperties (which are owned by FlowSpecifications) can be typed by (p65): · Block · DataType · Signal · ValueType Yet ItemFlows can only be typed by (p66): · Block · ValueType Since FlowPorts and associated Flow Specifications define “what can flow” between the block and its environment. Whereas ItemFlows specify “what does flow” in a specific usage context. It therefore proposed that the ItemFlows constraint section is updated to include DataType and Signal, as well Block and ValueType (i.e. same as FlowProperties). Note: It is assumed that having an ItemFlow typed by a flow specification would make no sense, since the item properties have direction on them that would have to be interpreted in relation to the direction of the item flow arrow. Is this assertion correct?

  • Reported: SysML 1.0b1 — Mon, 11 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Change the constraint on the conveyed classifier of items flows to be the same
    as the constraint on item properties. In answer to the question, item flows can
    convey items that have flow properties, but these flow properties apply to the
    item itself, not the source and target of the flow.

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

Semantic of default value in the scope of a DistributedProperty

  • Key: SYSML11-15
  • Legacy Issue Number: 10143
  • Status: closed  
  • Source: International Business Machines ( Laurent Balmelli)
  • Summary:

    in paragraph 8.3.2.3, the semantic of a default value for a DistributedProperty is not specified. My suggestion is that the default values should be a realization of the random variable following the distribution. It would be nice to have an example in the paragraph too, for instance: <<uniform>>

    {min=0,max=2} p:Real=2 <<uniform>>{min=0,max=2}

    p:Real=1.2 but not: <<uniform>>

    {min=0,max=2}

    p:Real=2.3

  • Reported: SysML 1.0b1 — Mon, 28 Aug 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Any value assigned to a property must lie within the values having non-zero
    probabilities as defined by an applied DistributedProperty stereotype. These
    constraint semantics are inherent in the concept of a probability distribution, and
    apply to the default or initial value along with all other values.
    How any further patterns of probabilities can expected to be observed, however,
    is currently unspecified by SysML. For example, the probabilities might be seen
    across the property values of different instances, or within a succession of values
    carried by a single instance. A specific user model must specify any such further
    interpretation of its applied property value distributions.
    Until or unless the SysML specification addresses more specific cases of how a
    user model must interpret its property value distributions, it is premature to
    preclude any interpretation that a model might apply. Different interpretations
    may be appropriate for different models, each of which may document any
    specific timing or scope for the values which may occur under the probability
    distribution.
    As referenced by section 8.3.2.3, some initial examples of distributed property
    stereotype definitions and their application in a user model are already provided
    in Annex C.6.
    Disposition: Closed, no change

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

constraints on viewpoint, 7.3.2.5

  • Key: SYSML11-14
  • Legacy Issue Number: 10098
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the constraints on viewpoint, 7.3.2.5, the plural form of the prosperities is used. I believe they should be in the singular.

    Constraints

    …

    [2]The property ownedOperations must be empty.

    [3]The property ownedAttributes must be empty.

    …

  • Reported: SysML 1.0b1 — Tue, 8 Aug 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The submitter is correct

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

Table 14.1 Use Case Diagram

  • Key: SYSML11-13
  • Legacy Issue Number: 10097
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Table 14.1 Use Case Diagram, the abstract syntax reference for the Subject notation is given as “Role name on Qualifier”. This does not appear correct

  • Reported: SysML 1.0b1 — Tue, 8 Aug 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    While the UML 2.x spec may not yet be consistent, it appears that the term "role name" has been replaced by "association end name".

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

SysML:Architecture

  • Key: SYSML11-12
  • Legacy Issue Number: 10073
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    For an SE to specify an Architecture, it is often necessary to specify reusable architectural patterns. SysML as currently formed does not appear to support the reusable definition of architecture tied to particular systems. It may be necessary to include some of UML 2.1 Template and Collaboration packages to support this capability.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Discussion:
    This issue was previously deferred by the SysML 1.1 RTF with the following
    discussion at that time:
    A full resolution of this issue is beyond the scope of an RTF. The issue is
    being deferred, however, so that additional explanatory material could be
    considered in a future RTF to clarify the scope of modeling supported by
    SysML or to suggest possible workarounds. A full resolution of this issue
    could be considered in an RFP for SysML 2.0.
    Addition of support for specifying reusable architectural patterns was considered
    to be beyond the scope of an RTF, so this issue is being closed. Requirements
    or proposals to add such support can be considered under a future RFP.
    Disposition: Closed, no change

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

SysML: << and >> vs < and >

  • Key: SYSML11-11
  • Legacy Issue Number: 10061
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Whenever possible, the spec should use the correct symbols « and » which are easily available in Visio

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    All remaining occurrences of << and >> have already been replaced by « and ».
    Disposition: Closed, no change

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

SysML: Missing arrow on figure 16.8

  • Key: SYSML11-10
  • Legacy Issue Number: 10060
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    On figure 16.8 there should be up-arrow pointing to the Accelerate state from the decision node

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Replace figure 16.8 with attached figure. Caption is unchanged

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

SysML: Interfaces on Flow Ports

  • Key: SYSML11-9
  • Legacy Issue Number: 10059
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Interfaces on Flow Ports

    It’s not clear how to model complex ports that partake of both service and physical flow characteristics. For example, I could use communicate in morse code over a hydraulic line. This would be modeled normally as a standard (service) port, except for the medium.

    Or I can use in-band signaling over a communication line (as it used to be on a telephone lines).

    In such cases, I’d like to be able to attach interfaces (with the set of operations) to a flow port.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    This is addressed in the resolution of issue 13178 by enabling blocks typing ports
    to have flow properties, where the blocks can support operations and receptions
    or realize interfaces that do the same.

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

SysML: Use Cases

  • Key: SYSML11-8
  • Legacy Issue Number: 10057
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The text in 14.1 should briefly discuss that for System Engineers, run-time optionality is not the typical distinction for indentifying extensions. If we wanted to draw a flow chart, we would use an activity diagram.

    It is usually more relevant to identify as extensions those use cases that not are needed to reach the goal of the base use case. This allows the System Engineers to use the dependency graph among the use cases to help determine production/test/delivery order.

    This also makes it clear to the reviewer which features are considered optional and which are not. At the SE level, this is more important that than flagging those features that sometimes invoked and sometimes not invoked.

    Please clarify with this use at the SE level

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Instead of a long discussion on the differences between SW and SE perspectives
    on use cases, we add some words to clarify the SE goal/requirement-oriented
    perspective, trying to avoided use of UCDs as flow charts. This approach leaves
    open the possibility of compatibility with SW approaches.
    In addition, a minor grammatical error is fixed.
    Revised Text:

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

Section: Requirements - Figure 16.1

  • Key: SYSML11-7
  • Legacy Issue Number: 10042
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Requirements, Figure 16.1, Requirement has properties with Requirement as type. But instances of stereotypes are not property values. Perhaps this is supported in UML as part of stereotypes with associations to stereotypes. If not, the type should be UML4SysML::Class, with the constraint that the values of the properties are stereotyped by Requirement.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Discussion:
    Stereotypes as property types are permitted as part of associations to stereotypes. Section 18.3.6 Profile of the UML 2.1.2 Superstructure spec contains the following paragraph:
    Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass.
    Disposition: Closed, no change

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

Section: Ports and Flows - Behavioral flow ports

  • Key: SYSML11-6
  • Legacy Issue Number: 10033
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Behavioral flow ports. In Ports and Flows, FlowPort 9.3.2.5, Description, the fourth and sixth paragraph seem to give contradictory defintions of behavioral flow ports. The second refers to the UML isBehavior semantics. The fourth refers to "relaying" to properties or parameters, but doesn't explain what that means. If the two paragraphs are referring to the same thing, then presumably a block behavior is a classifier behavior, and since that behavior executes while the block instance exists, relaying to the parameters requires those parameter to be streaming, in the sense of CompleteActivities. The semantics of relaying properties is unrelated to UML behavior ports.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Change the following paragraph in section 9.3.2.3:
    "Flow ports relay items to/from the associated connector to/from properties of the owning block or parameters of the block behavior if the port is not connected to an internal link that may relay the items to an internal part of its owner. This means that every flow property contained within a flow port is bound to a property owned by the block or a parameter of the block behavior."
    To:
    "Flow ports relay items to their owning block or to a connector that connects them with their owner's internal parts (internal connector).
    The isBehavior attribute inherited from UML port is interpreted in the following way: if isBehavior is set to true, then the items are relayed to\from the owning block. More specifically, every flow property within the flow port is bound to a property owned by the port's owning block or to a parameter of its behavior. If isBehavior is set to false, then the flow port must be connected to an internal connector which in turn related the items via the port. The need for isBehavior is mainly to allow specification of internal parts relaying items to their containing part via flow ports"
    Add the following constraint:
    [5] If a flow port is not connected to an internal part then isBehavior should be set to true.

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

Section: Blocks - BOM properties

  • Key: SYSML11-5
  • Legacy Issue Number: 10020
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    BOM properties. In Blocks, BlockProperty, 8.3.2.2, Description, third paragraph, seems to be trying to address the request for bill of material properties. If so, these are properties whose values are all the objects in the composite of a given type. They are derived from all the other block properties of that type. Eg, all the resistors needed to assemble an circuit board.

  • Reported: SysML 1.0b1 — Sat, 29 Jul 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The referenced section no longer exists in SysML 1.0. The BlockProperty stereotype was removed and its descriptive material incorporated in 8.3.2.2 Block. The previous text referenced by issue is no longer included in the resulting text. The referenced paragraph in the Final Adopted Specification, ptc/06-05-04, previously read:
    Parts may be used to show all the components from which a larger system is built. Consistent with UML, however, SysML currently does not provide any means to indicate whether all the parts which make up a larger system are either shown on a particular diagram or contained within a model. Various forms of diagram or model annotation, such as a Diagram Description note as shown in Annex A, may be used to communicate completeness of a diagram or model to a user.
    Since this text no longer exists in the 1.0 specification, this issue no longer applies. If there is a need to define a concept of Bill of Material properties within SysML, either by description or by additional metamodel elements, a new issue requesting changes to the current text could be raised and considered within future revisions of SysML.
    Disposition: Closed, no change

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

Section 16.3.1.1

  • Key: SYSML11-4
  • Legacy Issue Number: 9779
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

    Add more precision to table spec in terms of what rows, columns mean (refer to SP spec). Also, enlarge table elements so they are readable.

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.1
  • Disposition Summary:

    Discussion:
    SysML should not specify the layout and format of tables. There has never been
    any intent to standardize them in SysML 1.x. Legibility of example tables will be
    improved as each is modified in response to other changes.
    Disposition: Closed, no change

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

constraints section 9.3.2.4

  • Key: SYSML11-3
  • Legacy Issue Number: 9778
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

    Specify matching rules that enable flow ports and client server ports to be connected.

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Following is the discussion from a previous deferred resolution by the SysML
    FTF:
    It was felt that there is a need for experience in SysML prior to making
    such a change or extension. Deferred for future consideration.
    This issue is being deferred because no proposed resolution was voted on during
    the schedule of the SysML 1.3 RTF.
    Disposition: Deferred The new proxy ports and full ports defined in SysML 1.3 allow a mixture of
    inputs/outputs (using flow properties) and services (using directed features and
    provided/required interfaces). Flow ports have been deprecated. As a result there is
    no need for matching rules between flow ports and ports anymore.
    Disposition: Closed, no change

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

Section 16.4.2

  • Key: SYSML11-2
  • Legacy Issue Number: 9771
  • Status: closed  
  • Source: International Business Machines ( Jack Low)
  • Summary:

    Redraw visio to improve look. FTF Issue - General issue of style of uniform diagrams

    .

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    Considerable improvement was made to the diagrams included in the OMG Available Specification for 1.0, produced after the FTF Convenience Document was completed. Issues of uniformity and consistent quality to diagrams are expected to continue as part of ongoing editorial cleanup of the spec. Since the issue refers to the now-completed FTF, it should be closed. Further fixes can be completed either by ongoing editorial work or by issues raised against specific diagrams.
    Disposition: Closed, no change

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

Page 16

  • Key: SYSML11-1
  • Legacy Issue Number: 9763
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    "This section is very difficult to understand, in particular for non-OMG
    people. Please add a clarifying paragraph here.
    "

  • Reported: SysML 1.0b1 — Thu, 25 May 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.1
  • Disposition Summary:

    The primary readers intended by this chapter are tool vendors responsible for implementations that comply with the SysML specification and user specialists responsible for evaluating compliance of tools. This audience is expected to have extensive familiarity with the other OMG specifications which SysML extends.
    Additional explanatory material could be added either to this chapter or elsewhere, but edits would best be driven by specific suggestions after greater experience with the compliance levels and their UML dependencies has been gained.
    Disposition: Closed, no change

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