OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — All Issues

  • Acronym: SysML
  • Issues Count: 44
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML12-16 Merge UML DataType into SysML ValueType SysML 1.1 SysML 1.2 Resolved closed
SYSML12-15 Lack of Structured Activity Node and other Activity features Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-10 SysML/Modelica Integration Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-9 Port Decomposition of a Flow Specification Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-8 Section: 11.3.2 Inability to name interruptible activity regions SysML 1.1 SysML 1.2 Resolved closed
SYSML12-7 Section: 4.2, 11.2.1 SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-13 Parametrics and Depletable Stores SysML 1.1 SysML 1.2 Resolved closed
SYSML12-12 SysML synchronization with UML/XMI version updates Discussion SysML 1.1 SysML 1.2 Resolved closed
SYSML12-14 Use cases in SysML are more similar to Requiremetns than Behavioral diagrams SysML 1.1 SysML 1.2 Resolved closed
SYSML12-5 Section: 9.3.2.4 Constraint about "in" flow properties SysML 1.1 SysML 1.2 Resolved closed
SYSML12-4 More than one constraint block of the same type in a parametric diagram SysML 1.1 SysML 1.2 Resolved closed
SYSML12-6 Section: 11.3.1.1, 11.3.1.4, 11.4 SysML 1.1 SysML 1.2 Resolved closed
SYSML12-11 Ambigous line crossings SysML 1.1 SysML 1.2 Resolved closed
SYSML12-17 "trigger[guard]\activity" should be "trigger[guard]/activity" SysML 1.1 SysML 1.2 Resolved closed
SYSML12-40 Including Behavior Port Notation SysML 1.1 SysML 1.2 Resolved closed
SYSML12-39 Streamlined notation for representing system variance SysML 1.1 SysML 1.2 Resolved closed
SYSML12-38 Ambiguous Block Hierarchy SysML 1.1 SysML 1.2 Resolved closed
SYSML12-37 Non-atomic flow ports use property type incorrectly SysML 1.1 SysML 1.2 Resolved closed
SYSML12-35 Wrong type in fig. 15.11 SysML 1.1 SysML 1.2 Resolved closed
SYSML12-34 Ports use property type incorrectly SysML 1.1 SysML 1.2 Resolved closed
SYSML12-43 Constraining a decomposition hierarchy SysML 1.1 SysML 1.2 Resolved closed
SYSML12-36 15.3.2.2 Allocated(from Allocations) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-42 Extending Ports to Support Non-flow Properties SysML 1.1 SysML 1.2 Resolved closed
SYSML12-33 Overly restrictive statement regarding ports in blocks chapter SysML 1.1 SysML 1.2 Resolved closed
SYSML12-41 Including Property Notation for Redefinition and Subsetting SysML 1.1 SysML 1.2 Resolved closed
SYSML12-44 Typing Flow Properties and Item Properties as Enumerations SysML 1.1 SysML 1.2 Resolved closed
SYSML12-3 use of derived in Requirements SysML 1.1 SysML 1.2 Resolved closed
SYSML12-2 11.4 Activity Usage Sample: ControlOperator has regular pins SysML 1.1 SysML 1.2 Resolved closed
SYSML12-1 Section: 11.3.1.1 Activity in bdd SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-24 Notation for multiple item flows SysML 1.1 SysML 1.2 Resolved closed
SYSML12-23 Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct SysML 1.1 SysML 1.2 Resolved closed
SYSML12-25 Example figures in chapters are redundant with Annex B sample problem SysML 1.1 SysML 1.2 Resolved closed
SYSML12-29 SysML issue based on UML Issue 11160: Namespace URI for Standard Profile(s) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-28 SysML Issue based on UML Issue 10044: Profile Structure Diagrams are missing from Annex A SysML 1.1 SysML 1.2 Resolved closed
SYSML12-22 Using composite association between activities SysML 1.1 SysML 1.2 Closed; No Change closed
SYSML12-21 Chapter 7.3.1.1 Update comment stereotype diagram extension SysML 1.1 SysML 1.2 Resolved closed
SYSML12-32 SysML RTF: 11.4 Activity Usage Sample: ControlOperator has regular pins (2) SysML 1.1 SysML 1.2 Resolved closed
SYSML12-31 UML4SysML: Architecture & Compliance with UML subset SysML 1.1 SysML 1.2 Resolved closed
SYSML12-19 Participant Property constraint #6 not correct. SysML 1.1 SysML 1.2 Resolved closed
SYSML12-18 Fig. 11.10: Pin of ControlOperator SysML 1.1 SysML 1.2 Duplicate or Merged closed
SYSML12-27 Representing multiple item flows on the same connector SysML 1.1 SysML 1.2 Duplicate or Merged closed
SYSML12-26 The information in Annex D regarding AP233 needs to be updated SysML 1.1 SysML 1.2 Resolved closed
SYSML12-20 Connector Property value text. SysML 1.1 SysML 1.2 Resolved closed
SYSML12-30 SysML Issues based on UML 13080 New proposal for conjugate types for port SysML 1.1 SysML 1.2 Resolved closed

Issues Descriptions

Merge UML DataType into SysML ValueType

  • Key: SYSML12-16
  • Legacy Issue Number: 13345
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Even though SysML ValueType includes all the capabilities of UML DataType, plus its own optional extensions, SysML currently both of these separately in its diagram elements and abstract syntax. This adds unnecessarily to the complexity of the specification (where both DataType and ValueType must be mentioned in multiple places) and to the language that the SysML user must learn. It's inconsistent with other renaming of UML elements by SysML, in which the neutral SysML term (e.g. Block) replaces the UML term (e.g. Class). Just as SysML Block replaces the UML term Class, there's no reason the SysML term ValueType can't replace the UML term DataType. Statement of OCL constraints and metamodel and diagram syntax specifications can be simplified as a result.

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

    Because ValueType includes all capabilities UML DataType, plus its own optional
    extensions, no user need for keeping them both was identified during discussions
    within the RTF. In SysML user models, there’s no reason that the SysML term
    ValueType can’t replace the UML term DataType, in the same way that the
    SysML term Block replaces the UML term Class. In both cases, the substitute
    terms were chosen to be less software-specific than possibly appropriate for use
    by system modelers. Regardless of this rationale, consolidating to just ValueType
    simplifies the language including the specification of diagram elements and
    constraints.

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

Lack of Structured Activity Node and other Activity features Discussion

  • Key: SYSML12-15
  • Legacy Issue Number: 13328
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Certain activity constructs were left out of UML4SysML to reduce complexitiy of the language, butBased on usage of activity diagrams, some of these constructs are now viewed as useful. One example is structured activity nodes. Others include the parameter affect. Proposed Resolution: Update Fig 4.2 andd Table 4.1 to include additional packages in UML4SysML that support the useful constructs such as structured activity node which is included in "CompleteStructuredActivities". Also, update the diagram element tables in Table 11.1 to reflect these new constructs.

  • Reported: SysML 1.1 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Table 4.1 (Detail of UML Reuse) says StructuredActivities is included in SysML,
    but Figure 4.2 (SysML Extension of UML) should be updated to include it (the
    figure includes the Composite Structures package for StructuredActivities), and
    structured activities should be included in the Activities chapter diagram elements
    table.

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

SysML/Modelica Integration Discussion

  • Key: SYSML12-10
  • Legacy Issue Number: 13179
  • Status: closed  
  • Source: Georgia Institute of Technology ( Chris Paredis)
  • Summary:

    In order to begin to more fully leverage SysML, it must be integrated with various execution languages. Modelica is a highly expressive execution language to support physics based analysis and simulation, which has been standardized through the Modelica Association. Initial feasibility indicates a high degree of compatibility between SysML and Modelica. A standard mapping between SysML and Modelica is needed to enable this capability. In addition, it is expected that some refinement/extensions of SysML may be required to more fully integrate with Modelica. Recommendation: Perform an initial mapping between SysML and Modelica. Identify any refinements/extensions to SysML to support the mapping. Prepare a non-normative annex to the SysML specification that captures this mapping.

  • Reported: SysML 1.1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    A separate specification for a "SysML-Modelica Transformation" is currently
    being finalized by OMG. This specification has taken over the specification of a
    mapping between the two languages and goes far further than originally
    suggested by this issue. The working groups for SysML and the SysML-Modelica
    Transformation are continuing to work together, and will raise specific issues
    against SysML as necessary to support the transformation capability.
    Disposition: Closed, no change

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

Port Decomposition of a Flow Specification Discussion

  • Key: SYSML12-9
  • Legacy Issue Number: 13178
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Port Decomposition of a Flow Specification Discussion. There has been continued need to be able to decompose ports. One approach is to decompose a flow specification. In order to more readily accomplish this, a flow specification steretoype should subclass block instead of extending interface. This would enable many of the block constructs to be used, such as nested connector ends, the dot notation, and other features. A nested connector ends would allow direct connections to the flow properties of flow specifications. Dot notation could be applied to refer to the flow properties. In addition, to enable further levels of decomposition, a flow property should be able to be typed by a Flow Specification. The notation should also be clarified to allow for flow ports typed by flow specifications to show the port with the nested flow properties, and futher levels of nesting as required. As an additional comment, a connector to the port that is typed by the flow specification can be allocated to sub connectors that connect directly to the flow properties to support the concept of connector decomposition. Recommendation. 1. Modify Figure 9.1 to show the Flow Specification stereotype subclassing block rather than extending Interface. 2. Modify Flow Property in 9.3.2.4 to allow it to also be typed by a Flow Specification. This should be reflected in the Description and Constraint 1. 3. Modify Flow Specification in 9.3.2.5 to note that Flow Specifications can be decomposed (not sure this is necessary, but it might be good to clarify). 4. Modify the text for the diagram extension to flow port in 9.3.1.1 to describe that a flow port that is typed by a flow specification can be notated with the port symbol that nests the flow properties. Also note that a connector can connect directly to these flow properties using nested connector ends, and that the dot notation can be applied to refer to the flow properties. Finally, note that flow properties can be nested more than one level.

  • Reported: SysML 1.1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This issue is resolved by loosening UML constraints on connectors to enable
    thems to connect to ports nested on ports, recursively, and provide a notation for
    nested ports. It clarifies that item flows can be typed by association blocks
    containing connectors between nested ports. Issues 10059, 11628, 12914, and 14086 are also resolved, see those issues for
    more information.

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

Section: 11.3.2 Inability to name interruptible activity regions

  • Key: SYSML12-8
  • Legacy Issue Number: 13157
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: Inability to name interruptible activity regions. Discussion. Interruptible regions are useful constructs in SysML to enable termination of activity nodes. This is useful in a variety of cases, such as when one wants to terminate actions with streaming and continuous flows. In more complex behaviors with multiple interruptible regions, it is desired to be able to identify these regions by name. This may be useful when defining the owned behavior of a block with an activity that has multiple interruptible regions that represnt behavior in a similar way to state machines, where an accept event action may cause the behavior of the block to transition to another interruptible region of its behavior. Proposed resolution: An interruptible region in UML and SysML is currently an activity group which subclasses element. Create a stereotype of interruptible region called name interruptible region that subclasses Named Element (a similar approach is applied to activity partitions in UML

  • Reported: SysML 1.1 — Sun, 14 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This is addressed in UML 2.3. Assume this revision of SysML will be based on
    UML 2.3, and update the Activities diagram table in SysML.

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

Section: 4.2, 11.2.1

  • Key: SYSML12-7
  • Legacy Issue Number: 13156
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: SysML support for Foundational UML to support execution of activities Discussion. Need to include the foundational subset of UML in the UML4SysML to support activity execution. This includes constructs suchas structured activity nodes in complete structured activities, which is a capability that is a useful addittion to SysML. Proposed Resolution. Update Figure 4.2 and Table 4.1 to included structured activities, extra structured activities and complete structured activities along with any other packages in UML4SysML needed to support the Foundational UML Subset. In addtion, update the diagram elements in Tables 11.1-11.3 to reflect the additional activity constructs including the structured activity node.

  • Reported: SysML 1.1 — Sun, 14 Dec 2008 05:00 GMT
  • Disposition: Closed; No Change — SysML 1.2
  • Disposition Summary:

    Resolution:
    If the modeler stays within fUML, the model will execute. Some of SysML is not
    in fUML (eg, streaming), and some of fUML is not in SysML (expansion regions),
    but if the modeler stays with the intersection of fUML and SysML, the model will
    be executable and SysML-compliant.
    Disposition: Closed, no change

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

Parametrics and Depletable Stores

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

    Though we recently changed SysML to allow depletable stores, there appears to be some open issues about what they are and how to handle them with Parametrics properly.

    Is the name of the depleteable store that property of the owning block whose values change? (and can be used in Parametrics) Or does the depleteable store have a property (perhaps with a standard name) that is the changing value. Is the depleteable store a variable property or a part with a variable property?

  • Reported: SysML 1.1 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

SysML synchronization with UML/XMI version updates Discussion

  • Key: SYSML12-12
  • Legacy Issue Number: 13196
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: SysML synchronization with UML/XMI version updates Discussion: Since SysML was originally published, both UML and XMI specifications have been updated. It is important to maintain synchronization between SysML and these specifications since SysML leverages both of them. Proposed Resolution: Update Section 2 to reflect the current version of UML and XMI. An assessment of the changes to UML and XMI should be made, and a determination of the impact on the SysML specification. The SysML specification should be updated accordingly.

  • Reported: SysML 1.1 — Wed, 31 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Specific issues continue to be raised to address specific points of dependence of
    SysML on UML. The SysML specification itself has replaced specific version
    references to UML to simply "UML 2" so that references do not have to be
    changed to reflect the dependencies on which any given version of SysML
    depends, with the exception of material in Chapter 4, Language Architecture.
    This generic issue should be replaced by more specific ones that raise known
    issues in which future versions of SysML may need further revision to address
    dependencies on UML.
    Disposition: Closed, no change

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

Use cases in SysML are more similar to Requiremetns than Behavioral diagrams

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

    There is a non-normative diagram indicating a hierarchy of SysML diagram types. In this diagram we follow the UML convention of treating Use Cases as behavioral diagrams. The exact reason for this is unclear, and appears to be tied up with collaborations.

    However, in SysML system engineers (and many s/w eng in UML) treat use cases as a way of capturing goals, capabilities, purposes, and as a technique to organize (and find) requirements. In this way, it is more understandable to the typical SysML user to treat both Use case Diagrams and Requirements Diagrams as belonging to the same category. I have verified this by teaching SysML to students both ways – and the common UCD/REQ approach is thought to be more understandable.

    One approach would be to consider the new category Requirement Diagrams, and Use Case and Text-base Requirements as the individual requirements. Another would be to make a new category of Specification Diagrams and use Use Case and Requirements as the individual types.

  • Reported: SysML 1.1 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The above approach represents a reasonable approach to restructuring this
    Diagram Taxonomy. However, this taxonomy is intended to be more of a
    conceptual organization of the SysML diagrams, and is not a precise
    representation. There may in fact be many ways to categorize the diagrams in a
    conceptual and informal diagram taxonomy. As a result, this resolution will add a
    clarification to the non-normative Diagram Annex that other diagram taxonomies
    can be included, and include the categorizing of the use case diagram and
    requirements diagram as an example.

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

Section: 9.3.2.4 Constraint about "in" flow properties

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

    Constraint [2] says: [2]An “in” FlowProperty value cannot be modified by its owning block. What is the owning block of the flow property? The flow property is owned by the flow specification which is a type of a flow port which is owned by a block. Is this block the "owning block"? Why is the owning block not allowed to change a in flow property? Shouldn't that be defined by the readOnly property instead of the direction?

  • Reported: SysML 1.1 — Tue, 7 Oct 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This is addressed in the resolution of issue 13178 with clarified wording in the
    description of flow properties

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

More than one constraint block of the same type in a parametric diagram

  • Key: SYSML12-4
  • Legacy Issue Number: 12853
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I'm just experimenting with the parametric diagram and detected a problem. I'm not sure
    if it is a SysML problem or if I am the problem.

    A block A has a composition relationship to a constraint block with multiplicity * and property name cstr.
    I like to use the constraint property cstr in a parametric diagram of block A multiple times.
    That doesn't work, because the constraint property occurs only once in the diagram.

    I don't like to define a constraint property for every usage of the constraint in the parametric
    diagram, because it's not two or three times, but really many many times I want to use the constraint.
    I think of something like the selector in sequence diagrams, i.e. the name of the constraint
    property in the parametric diagram is cstr[1] : MyConstraintBlock, cstr[2] : MyConstraintBlock, and so on.

    What do you think? Am I completely wrong?

  • Reported: SysML 1.1 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

Section: 11.3.1.1, 11.3.1.4, 11.4

  • Key: SYSML12-6
  • Legacy Issue Number: 13155
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: Ability to capture performance properties of activities and bind to parameters in parametrics. Discussion. Need to clarify that performance properties of activities and other behaviors, such as the time, reliability, and accuracy associated with performing an activity, can be captured as part of the definition and use of an activity or the types of its object nodes in a way similar to value properties of blocks. Further clarification should be provided that these properties can be bound to parameters in parametric diagrams to support performance analysis. Activities (and other behaviors) can be captured on a bdd as shown in Figures 11.1, 11.5, 11-13 and 11-14. In section 11.3.1.1 and 11.3.1.4, the interpretation of activities and object nodes on bdd's is defined, and in section 11.3.1.4. Proposed resolution: Additional clarification should be provided in the above sections, that properties of activities and other behaviors can also be represented on their definitions on a bdd, and that the value properties are like any other value property, enabling them to be bound to parameters in parametric diagrams.

  • Reported: SysML 1.1 — Sat, 13 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Add clarifications for Activities, as indicated above. The clarification for Object
    Nodes is already in the Object Node section of Diagram Extensions.

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

Ambigous line crossings

  • Key: SYSML12-11
  • Legacy Issue Number: 13190
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Issue: Ambigous line crossings Discussion: When two lines cross, there can be ambiguity associated with the line path. This applies to any line including flows, associations, and connectors and other relationships represented by edges. A solution to remove ambiguity that is used in various schematic diagrams to address the same issue is to add include a curve in the lline path at the intersection. Proposed Resolution: In the Diagram Appendix on pgs 175-176, and a diagram guideline to include the curve to a crossing line path to avoid ambiguity. Consider making this a normative requirement. This will require an additional clarification statement for the Non Normative annexes.

  • Reported: SysML 1.1 — Tue, 23 Dec 2008 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Update the Guidelines in the Diagram Annex in Section A.2 to include an
    alternative. ”jumping over “ notation for line crossings to avoid ambiguity, similar
    to what has been used in electrical schematics. This is indicated by a small
    semicircle at the line crossing. This can be applied to any edge in any SysML
    diagram including flows, associations, connectors, and other relationships. It
    should be noted that this is currently a presentation option for UML associations
    as specified in the UML Superstructure specification (formal/09-02-02 pg 43).

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

"trigger[guard]\activity" should be "trigger[guard]/activity"

  • Key: SYSML12-17
  • Legacy Issue Number: 13465
  • Status: closed  
  • Source: Logica ( Tis Veugen)
  • Summary:

    "trigger[guard]\activity" should be "trigger[guard]/activity"

  • Reported: SysML 1.1 — Sun, 8 Feb 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

Including Behavior Port Notation

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

    The behavior port notation to support the isBehavior=true condition on a port is needed to more explicitly model parts that execute the behavior directly. Refer to Figure 9.17 of the UML Superstructure Specification (v2.3).

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

    Agree with the need

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

Streamlined notation for representing system variance

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

    System variants are often required to modify a system in order to satisfy evolving needs, and to support product lines with varying applications and environments. System variants have some components in common and some components that may be unique for each variant. SysML currently includes some capability to address variants, such as a property-specific type for specifying a variant usage of a component (i.e., block) in a local context, redefinition for redefining the type of the component, and generalization sets for specifying alternative components. However, what it lacks is a convenient mechanism and notation for describing variations that occur in deeply nested contexts within blocks.

    Issue
    System Variants
    Classical product configuration management evaluates whether the change to an assembly affects the next higher assembly in terms of its form, fit, or function. If there is no change to its form, fit, or function, the modification does not propagate up the hierarchy (Note: This should be confirmed). In order to ensure there is no adverse impact to the next higher assembly, one must establish criteria to evaluate the impact of the change on the next higher assembly, and then evaluate the impact of the change against the criteria.

    Figure 1 describes the baseline block hierarchy for a Vehicle; in the following paragraphs we will discuss how to address variants of this baseline system.

    Figure 1 - Definition of the baseline configuration for a vehicle
    In considering variance, one first checks to see if the change to a component affects the interface of the next higher level assembly. For example, in Figure 1, if the number of lugbolts is changed from 6 to 8, this could impact the interface to the braking disc. In addition, one must evaluate other potential impacts due to form, fit, and function. For example, if the weight of the bolt changes, the impact may propagate up the hierarchy to affect the overall vehicle weight. Or if the modified bolt has a lower stress rating, it may impact the safety of the vehicle. These impacts need to be understood to make a determination of whether the modification to the lugbolt impacts the next higher assemblies and the vehicle as a whole. If the change propagates up the system level, then each higher level of the assembly that is impacted must be subclassed (e.g., this may correspond to a new model number) to represent the variant assembly.
    Representing Variants using Block Definition Diagrams

    When a system variant results from changes in its components, the variant system model must include representations of the variations at each level of the system hierarchy from the system level down to the component level where the changes occur. The example in Figures 2 illustrates the SysML solution when a modification to a lugbolt results in a variant to the automobile at each level of the system hierarchy. In Figure 2, a change to the lug bolt (i.e. LugBolt A) propagates up the system hierarchy resulting in a variant to the wheel, to the chassis (or equivalent next assembly), and to the vehicle. The variant system hierarchy includes Vehicle A, Chassis A, Wheel A, and LugBolt A as subclasses of the baseline system elements.

    Figure 2 ­ Varying all levels of the system hierarchy

    The following reference provides further information on a general approach to capturing variants: “Extended Generic Product Structure: An Information Model for Representing Product Families by Sean Callahan.” This short paper can be found at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_published.pdf and a longer version at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_extended.pdf.

    System Variants Using Property-Specific Types

    In Figure 2, 4 new types were introduced. If there is no impact to the form, fit, or function of the higher elements in the assembly, then modeling these intermediate assemblies using new types can be very cumbersome. There is a need for a more streamlined approach to capturing variations in deeply nested parts that do not affect intermediate level assemblies.

    At first glance, the property-specific type concept in SysML seems to fit the bill. As shown in Figure 3, using property-specific types, the replacement part is shown using dot notation on the IBD for Vehicle A, without the need for the user to explicitly represent Chassis A, etc. on the corresponding BDD.

    Figure 3 - Use of property-specific types to capture variants

    However, as can be seen, the redefinition clause in the part symbol does not give a clear indication of the location of the part being redefined, nor is there a notation on a BDD for showing this replacement part.

    Note: Figures were not able to be included with this posting but are available on the SysML v1.2 RTF Wiki

  • Reported: SysML 1.1 — Tue, 1 Dec 2009 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    This RTF declines to add specialized notation for variants.
    Disposition: Closed, no change

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

Ambiguous Block Hierarchy

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

    There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies.

  • Reported: SysML 1.1 — Sun, 4 Oct 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The figures above have only one (unambiguous) underlying model, but directed
    relationships, such as dependencies, linked to c1 (or c2) would be ambiguous. It
    would not be possible from the underlying model alone (without the notation) to tell
    whether the directed relationship was referring to values of c1 properties on
    instances of B that are values of the b1 property on instances of A, or values of the b2 property on instances of A, because directed relationships do not currently
    support property paths, as connector ends do when NestedConnectorEnd is applied.
    Introduce an abstract stereotype of DirectedRelationship with property paths for their
    sources and targets, that generalizes SysML Stereotypes based on
    DirectedRelationship or its specializations

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

Non-atomic flow ports use property type incorrectly

  • Key: SYSML12-37
  • Legacy Issue Number: 14424
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Non-atomic flow ports use the type of
    the port for an interface with
    properties specifying the type of things
    that flow. If the various types of
    things flowing are intended to flow at
    the same time, then flow specifications
    aren't needed. This can be done with an
    atomic port flowing objects supporting
    the interface. If the the various types
    of things flowing are meant to flow at
    different times, this is isn't UML
    semantics, or at least is very
    unintuitive from an engineering point.
    This can be done either with 1) an
    atomic port flowing a supertype of the
    various types of things that flow 2) the
    association mentioned in in the first
    paragraph having multiple types, which
    the semantics defined to be union of the
    types.

  • Reported: SysML 1.1 — Wed, 16 Sep 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Ports typed by flow specifications do not mean that items supporting the interface
    are flowing. This is clarified in the resolution to issue 13178.
    Disposition: Closed, no change

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

Wrong type in fig. 15.11

  • Key: SYSML12-35
  • Legacy Issue Number: 14238
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The type in the allocation matrix must be action instead of activity.

  • Reported: SysML 1.1 — Mon, 31 Aug 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Discussion:
    Fig. 15.11 was deleted in SysML 1.2, removing redundancy with Annex B.
    Fig. B.37 (Fig. C.37 in SysML 1.3) is the same figure, but the issue noted here was
    fixed in the resolution to Issue 11497 in SysML 1.2.
    Disposition: Closed, no change

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

Ports use property type incorrectly

  • Key: SYSML12-34
  • Legacy Issue Number: 14086
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Ports use property type incorrectly. Atomic flow ports use the type of the port for the type of thing flowing. This doesn't fit common usage in engineering design, for example, a port that is a faucet through which water flows. The type of thing flowing isn't the type of the port, it should be associated to the ports by the stereotype. Non-atomic flow ports use the type of the port for an interface with properties specifying the type of things that flow. If the various types of things flowing are intended to flow at the same time, then flow specifications aren't needed. This can be done with an atomic port flowing objects supporting the interface. If the the various types of things flowing are meant to flow at different times, this is isn't UML semantics. This can be done either with 1) an atomic port flowing a supertype of the various types of things that flow 2) the association mentioned in in the first paragraph having multiple types, which the semantics defined to be union of the types.

  • Reported: SysML 1.1 — Sun, 19 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The atomic port portion of this issue is addressed in the resolution of issue 13178
    by deprecating atomic flow ports. See resolution of issue 14424 regarding nonatomic
    flow ports.

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

Constraining a decomposition hierarchy

  • Key: SYSML12-43
  • Legacy Issue Number: 15077
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    There is a need for a robust mechanism to constrain a system decomposition hierarchy to reflect only selected groupings of parts as motivated by the following example. In particular, assume a rack assembly is composed of a chassis and a set of circuit cards. The rack assembly is constrained by which cards can be inserted in which slots. This includes an optical card in an optical slot, an ethernet card in an ethernet slot and a general slot that can accommodate either an ethernet card or an optical card (source is Nathan Sowatskey example). In addition, a particular rack configuration may include a specific number of each type of slot and card. The need is to constrain the hierarchy to only allow these combinations parts. Generalization sets, redefinition, and other mechanisms can help, but require considerable modeling that is cumbersome. The desired capability is to be able to include a constraint in the rack assembly that constrains the allowable instances of the rack assembly. It is also desirable to specify constraints on nested parts using the dot notation. (Refer to related issue 14998 binding to multiplicity in parameterics).

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

    No Data Available

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

15.3.2.2 Allocated(from Allocations)

  • Key: SYSML12-36
  • Legacy Issue Number: 14239
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Although explicitly stated that other designations may be used the list should contain at least <<action>>, <<operation>> and <<property>>. Allocation with actions and properties as related elements are shown in the examples in the specification.

  • Reported: SysML 1.1 — Mon, 31 Aug 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The proposed change is not required, but adds clarity.

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

Extending Ports to Support Non-flow Properties

  • Key: SYSML12-42
  • Legacy Issue Number: 15076
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    There is a need to model a broader range of interfaces which extend beyond the current capability of standard ports and flow ports in SysML. One example is the physics based interfaces that are found in Modelica referred to as across and through variables. An example is in an electrical circuit where the interface can be defined in terms of the current and voltage parameters at each input and output node of a circuit. In Modelica, the interface between two components enables Kirchoffs Laws to be imposed on these interfaces such that the voltage on the on the connecting ports are equal, and the sum of the currents on the connecting ports sum to zero. SysML needs to be able to accommodate this type of interface more directly. One possible approach is to extend the concept of a Flow Specification to accommodate other types of properties, such as across and through variables, and not be limited to flow properties.

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

    Disposition: See issue 11628 for resolution

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

Overly restrictive statement regarding ports in blocks chapter

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

    Overly restrictive statement regarding ports in blocks chapter. The following statement in section 8.3.2.2 in the Blocks Chapter is overly restrictive. "A port that is typed by a Block is a special case of a part property, as further defined in Chapter 9, Ports and Flows.". A port is a special class of property that can be typed by classifiers other than blocks. The recommendation is to generalize the wording as follows: A port is another category of property, as further defined in Chapter 9, Ports and Flows.

  • Reported: SysML 1.1 — Sat, 18 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

Including Property Notation for Redefinition and Subsetting

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

    The property notation from UML to support redefinition and subsetting should be included in SysML explicitly. This notation is not currently included in the diagram element tables in the Blocks Chapter. Refer to property notation in Section 7.3.44 of the Superstructure Specification (v2.3).

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

    Include property subsetting and redefinition in the Block Definition diagram element
    tables.

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

Typing Flow Properties and Item Properties as Enumerations

  • Key: SYSML12-44
  • Legacy Issue Number: 15117
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    There is an inability to type a flow property or item property by an enumeration. This issue surfaced when Nathan Sowatskey was attempting to model a VLAN network.

  • Reported: SysML 1.1 — Wed, 3 Mar 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Flow properties can be typed by enumerations. They can be typed by
    ValueTypes, which is a stereotype based on UML Datatype, a generalization of
    UML Enumerations.
    Disposition: Closed, no change

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

use of derived in Requirements

  • Key: SYSML12-3
  • Legacy Issue Number: 12751
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    16.3.2.3:

    (2) /derived: Requirement [0..1]
    Derived from all requirements that are the client of a «deriveReqt»
    relationship for which this requirement is a supplier.

    I don't think we can write OCL to derive this value, at least not
    without knowledge of the population of Requirements in which this
    instance is situated. How would we navigate from this object, a
    Requirement, to that population? I note that the version of the
    profile XMI I am using doesn't declare this property as derived. It
    appears that at least one SysML tool provider didn't derive it, but
    maintains it in their tool and XMI.

    I think something like the above criticism can be leveled against all
    of the
    attributes /satisfiedBy, /verifiedBy, /tracedTo, /derived, /derivedFrom, /refinedBy, /master
    that are declared derived in the spec 08-05-16. Perhaps we ought to
    remove the '/' and use a word other than "derived" in describing
    these attributes.

    Likewise 16.3.2.4 RequirementRelated attributes should not be declared
    derived.

    It may be the case that the OMG needs to be clearer regarding what it
    means by "derived." There are attributes whose definition can be
    expressed in OCL and there are attributes whose value can only be
    found by some (perhaps vaguely specified) analysis of the Model (if
    Model is the correct context!). The latter notion is, I think, what
    you intend throughout Clause 16. That's fine, except I don't think
    the attributes for which this notion applies should be annotated with
    the slash. Further, it may be useful to identify what population is
    being considered when using terms like "all requirements."

  • Reported: SysML 1.1 — Thu, 7 Aug 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    RelatedRequirement properties are actually derived since their values are calculated
    from existing relationships linking requirements with other kinds of model elements.
    The intent of such derived properties is to specify how some characteristics of
    interest can be queried from their owner. For instance a requirement can be property is to model that, given a specific requirement, it is possible to know the
    element linked to it through a <<satisfy>> relationship.
    Nevertheless, the way to retrieve the actual value of those derived property is
    currently specified in an informal manner only. This part of the specification can be
    improved by adding the corresponding OCL queries.
    Since many of those derived values require getting data across non navigable
    association end in the metamodel, the practical way to compute them is to browse all
    possible candidate instances and select those of interest. When OCL is used for that
    purpose we rely on the allInstances() operation that is predefined for each class. The
    Annexe A: “Semantics” of the OCL v2.3.1 specifies the scope to be considered:
    • “Object models provide information used as context for OCL expressions and
    constraints” (§A.1, p193)
    • Object models are defined as structures gathering a set of classes and for
    each of those classes sets of: attributes, operations, associations and
    generalizations (cf. §A.2.1, p193 and following pages)
    • A system state is defined as the snapshot of a system at a particular moment
    in time. Given an object model M (as defined above), a system state for that
    object model has a finite set of objects sCLASS with sCLASS(c) representing the
    subset of all objects of a given class c. Such a system provide the complete
    context for evaluating an OCL expression (except post and pre conditions, see
    §A.3.1.3, p201)
    • In such a context, the interpretation of the allInstances() called on a class c is
    specified to be equal to sCLASS(c) (cf. §A.4.4.2, p208)
    From a practical point of view, the object model on which a tool shall scope the
    evaluation of an OCL expression is the one resulting from loading the topmost
    UML::Model element that ultimately contains the context defined for that OCL
    expression.

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

11.4 Activity Usage Sample: ControlOperator has regular pins

  • Key: SYSML12-2
  • Legacy Issue Number: 12576
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Output pin of a control operator is not a control pin as shown in fig. 11.10. It should be a regular pin typed by ControlValue.

  • Reported: SysML 1.1 — Wed, 16 Jul 2008 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Agreed, and the control flow in Monitor Traction should be a control pin.

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

Section: 11.3.1.1 Activity in bdd

  • Key: SYSML12-1
  • Legacy Issue Number: 12560
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The semantics of composition between activities refers to synchronous calls. What happens if the activity is called asynchronously? Is it possible to show that activity in the bdd, too? What is the relationship to the calling activity?

  • Reported: SysML 1.1 — Fri, 27 Jun 2008 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.2
  • Disposition Summary:

    Resolution:
    Asynchronous calls start a new execution of the called behavior, but there is
    usually no link between the new execution and the calling execution (the caller
    invokes, but after that doesn't communicate with the called behavior execution).
    If this is needed for some applications, the caller execution can instantiate the
    called activity as a class/block, and link the new instance (the new called
    execution) to the caller execution via an association. This association would be
    composite if the called execution is started synchronously, and non-composite if
    it is started asynchronously (using StartObjectBehaviorAction in both cases).
    This seems like too much detail of UML to cover in the SysML spec for an
    uncommon usage scenario. The filer agrees to close with no change.
    Disposition: Closed, no change

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

Notation for multiple item flows

  • Key: SYSML12-24
  • Legacy Issue Number: 13945
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Notation for multiple item flows. The UML specification provides a compact notation for multiple information items flowing in the same direction. A similar notation should be provided in SysML, but this is not explicitly called out. Recommendattion. Add a sentence at the end of section 9.3.1.4 which describes diagram extensions for item flows consistent with the UML approach that reads "When several item flows having the same direction are represented, only one triangle is shown, and the list of item flows, separated by a comma is presented." Also, include the multiple item flow notation in the Item Flow entry in Table 9.1.

  • Reported: SysML 1.1 — Mon, 1 Jun 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Accept proposed resolution with text that describes diagram extensions for
    multiple item flows consistent with the UML approach, and with some additional
    constraints on ItemFlow. Note that an item flow can have only one conveyed
    classifier. A future revision should consider a constraint that “An ItemFlow must
    have a single item property” since the item flow and item property should be
    viewed as a single concept in SysML

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

Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct

  • Key: SYSML12-23
  • Legacy Issue Number: 13928
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype <<partition> with the model elements enclosed, or it could leverage the SysML callout notation as an example.

  • Reported: SysML 1.1 — Sat, 9 May 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    It is convenient to be able to group model elements based on modeler-defined
    criteria. Simple examples are groups of elements that may be associated with a
    particular release, or with a legacy design. Unfortunately, there is no metaclass in
    UML that supports such a concept of collection. The word “group” is preferred to
    “partition” in the resolution since the concept of partition would suggest that
    participations in those groups are mutually exclusive while this limitation is not
    desirable.
    UML packages are a means to organize model elements. They have the convenient
    semantics except that they imply ownership, whereas it is requested to have no
    limitation on the number of groups an element can belong to. Instead, this proposal
    extends the UML::Comment metaclass for that purpose. The provided mechanism is
    intended to specify groups of model artifacts and should not be extrapolated for
    representing groups of runtime elements.
    A Comment may be owned by any kind of element and has no semantic side-effect.
    It can designate grouped elements using its annotatedElement association, and the
    criterion applicable to any element of the group can be defined via its body property. Annotated elements are not owned by the Comment. Thus, built on a
    UML::Comment, an ElementGroup does not own its members. There is no limitation
    on the number of Comments that can annotate a given element. Thus, any element
    can participate in an unlimited number of groups.
    Adding an element to a group does not modify it. Then, an element cannot hold any
    information about the groups it is member of. Instead a static query
    allGroups(e:Element) is provided for that purpose. It returns the set of
    ElementGroups a given element is member of.
    Note that a group may have some groups among its elements (annotated elements
    may be any kind of element, including UML::Comment).
    The members of an ElementGroup may optionally be ordered.
    The resolution to issue #18653 provides through the concepts of “View and
    Viewpoint” the means to compute collections of element as the result of an arbitrary
    query applied to a model or to a part of a model. An element group is distinct from
    view and viewpoint in that a) element groups provide a means to create persistent
    collections of elements, and b) membership of an ElementGroup is asserted rather
    than computed. The ElementGroup::member property is derived from the collection
    of annotated element. The way this property is derived cannot be modified by the
    modeler. Thus, View/Viewpoints and ElementGroup are disjoint concepts. However,
    View/Viewpoints can leverage ElementGroup for constructing views.
    Since an element group is expected to have a name, and the proposed base class
    (i.e., comment) is not a named element, an ElementGroup::name property is added
    to the ElementGroup stereotype.

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

Example figures in chapters are redundant with Annex B sample problem

  • Key: SYSML12-25
  • Legacy Issue Number: 13976
  • Status: closed  
  • Source: University of Arizona ( Mr. Rick Steiner)
  • Summary:

    Example figures in chapters are redundant with Annex B sample problem. This creates document maintenance issues. Figures 7.3, 8.11, 9.5, 9.6, 10.2, 10.3, 12.1, 12.2, 12.3, 13.1, 14.1, 14.2, 15.9, and 15.10 are all duplicated in Annex B. It is recommended that these diagrams are removed from chapters in part II and IV of the spec, and instead specifically reference the appropriate diagrams out of Annex B, thus making the specification easier to maintain.

  • Reported: SysML 1.1 — Wed, 10 Jun 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Delete redundant figures, but leave captions to act as notes referencing figures in
    Appendix B. This conveniently avoids extensive changes to the body text.

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

SysML issue based on UML Issue 11160: Namespace URI for Standard Profile(s)

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

    The SysML specification does not define the correct namespace URI for the standard profile(s) - it should.

  • Reported: SysML 1.1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    No Data Available

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

SysML Issue based on UML Issue 10044: Profile Structure Diagrams are missing from Annex A

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

    UML 2.1 added a new structural diagram type, Profile Diagram for the purposes of containing the profile-defining elements. SysML either should be made consistent or should explicitly indicate that the diagram is not part of SysML

  • Reported: SysML 1.1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The Profile Diagram was proposed as a new SysML diagram since it was added
    to UML to support profile definitions. However, the Superstructure Specification,
    Table 18.1 and Table 18.2, does not require that profiles be defined on a profile
    diagram. The diagram elements needed to specify a profile can be represented
    on any structure diagram. As a result, it is recommended not to add a profile
    diagram in SysML to limit the number of diagram kinds, and that profile
    definitions be represented on package diagrams.
    The following text was originally proposed as part of the resolution for this issue,
    but did not fit as part of the scope of Annex A. It could be considered as part of a
    future revision of SysML, for example as part of Chapter 17, Profiles and Model
    Diagrams:
    ... extra caution is warranted regarding the intent of a profile diagram as
    explained below. ...
    As far as UML is concerned, a profile can extend the UML metamodel
    instead of the UML4SysML subset of UML metamodel. However, a profile
    extending the UML may not be compatible with the SysML profile that
    extends the UML4SysML subset of the UML. For example, a stereotype
    called <<AssociationWithNavigableEnds>> extending UML::Association
    with a constraint to the effect that the association ends are navigable and
    also owned directly by the association would clearly be incompatible with
    the <<Block>> stereotype of SysML per 8.3.2.2. For such cases where the
    user intent is clearly in extending the UML4SysML subset of the UML in a
    manner that is compatible with the SysML stereotypes and their
    constraints, it is important that a SysML tool provides support for
    distinguishing user-defined profiles extending the UML metamodels and user-defined profiles extending the UML4SysML subset of the UML in a
    manner that is compatible with respect to the SysML stereotypes and their
    constraints.
    Revised Text:
    On p. 171, Annex A.1, change the third paragraph, currently:
    SysML does not use all of the UML diagram types such as the object
    diagram, communication diagram, interaction overview diagram, timing
    diagram, and deployment diagram. This is consistent with the approach
    that SysML represents a subset of UML. In the case of deployment
    diagrams, the deployment of software to hardware can be represented in
    the SysML internal block diagram. In the case of interaction overview and
    communication diagrams, it was felt that the SysML behavior diagrams
    provided adequate coverage for representing behavior without the need to
    include these diagram types. Two new diagram types have been added to
    SysML including the requirement diagram and the parametric diagram.
    with the following:
    SysML does not use all of the UML diagram types such as the object
    diagram, communication diagram, interaction overview diagram, timing
    diagram, deployment diagram, and profile diagram. This is consistent with
    the approach that SysML represents a subset of UML. In the case of
    deployment diagrams, the deployment of software to hardware can be
    represented in the SysML internal block diagram. In the case of interaction
    overview and communication diagrams, it was felt that the SysML
    behavior diagrams provided adequate coverage for representing behavior
    without the need to include these diagram types. In the case of the profile
    diagram, profile definitions can be captured on a package diagram, which
    is also allowed in SysML. Two new diagram types have been added to
    SysML including the requirement diagram and the parametric diagram.

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

Using composite association between activities

  • Key: SYSML12-22
  • Legacy Issue Number: 13924
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Using composite association between activities. The actual nature of the properties corresponding to the association end is not clear. Either it is a CallBahaviorAction and then it is not an instance of associated activity, or it is an activity execution and then the association should be derived beacause it depends on the CallBehaviorActions owned by the activity. Proposed resolution: State that composite associations between activities are always derived from the CallBehaviorAction owned by the activity.

  • Reported: SysML 1.1 — Thu, 7 May 2009 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.2
  • Disposition Summary:

    Resolution:
    When an Activity property corresponds to a CallBehaviorAction of another
    Activity, the value at “runtime” is an instance of the called activity (it can’t be an
    instance of the CallBehaviorAction, since Actions are not Classifiers). This value
    is not derived from anything else, it’s a new instance of the activity, a new
    execution (associations themselves are not derived, only their instances/links).
    This information is in the section on CallBehaviorAction. At the time the section
    on CallBehaviorAction was written, it was decided not to require a one-to-one
    correspondence between property names and CallBehaviorActions, even though
    that would typically be true.
    Comment from filer:
    Except if i miss something, the only way to create an instance of an
    activity from another activity is to execute an invocation action. That is: an
    activity execution won't instanciate any other activity if it doesn't own the
    corresponding invocation action, and conversely any execution of an
    CallBehaviorAction will instantiate the corresponding behavior. Then, for a
    given Activity, owned invocation action (e.g. CallBehaviorAction) and
    activity instance owned by composition are actually not independent. If no
    constraint is defined between these two properties the activity definition
    can be inconsistent. That's why I suggest that composite associations
    between activities should be derived. The two composition associations
    you describe above are at different metalevels. The link between Activity
    and CallBehaviorAction is specified by an M2 (metamodel) association
    and the link itself exists at M1 (user model). The link between Activity and Activity (due to invocation) is specified at M1 and
    the link itself exists at M0 (runtime). The constraints between these two
    associations is semantics, in the mathmatical sense, and is described in
    UML/SysML in natural language (see Executable UML for a mathematical
    specification of semantics). The constraints in the UML/SysML spec in the
    Constraints sections are syntactic, that is, between M2 and M1.
    Disposition: ClosedNoChange

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

Chapter 7.3.1.1 Update comment stereotype diagram extension

  • Key: SYSML12-21
  • Legacy Issue Number: 13854
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML 2.2 defines a presentation option for stereotypes for comments. There is no need to repeat that option in SysML. There is no need for a tool vendor to support a UML presentation option to be compliant with the specification. Since SysML depends on the presentation option the chapter 7.3.1.1 should be updated to state that the presentation option is required.

  • Reported: SysML 1.1 — Sun, 5 Apr 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    UML 2.2 defines the presentation option for stereotypes for comments. SysML
    also defines it as a diagram extension, because it wasn’t mentioned in UML 2.1
    which is the basis for SysML 1.1. Due to the update of UML there is no longer a
    need to keep the diagram extension in SysML.
    It is not necessary to explicitly mention that the presentation option isn’t optional
    in SysML. The notation of the affected model elements rationale and problem is
    clearly defined in table 7.1.

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

SysML RTF: 11.4 Activity Usage Sample: ControlOperator has regular pins (2)

  • Key: SYSML12-32
  • Legacy Issue Number: 14079
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Summary:

    This issue is a complement to issue #12576 that deal only with the output pin.
    A control operator should have a regular input pin typed by ControlValue in fig. 11.10.

  • Reported: SysML 1.1 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Control operators typically output control values to affect other actions, based on
    inputs that are not control values. In Figure 11.10, the input is Brake Pressure, which
    the control operator uses to determine whether the enable to disable Monitor
    Traction.
    Disposition: Closed, no change

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

UML4SysML: Architecture & Compliance with UML subset

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

    The compliance levels defined for UML 2.1.1 and UML 2.2 merge UML::CommonBehaviors::Communications at L1 instead of at L2 in SysML 1.1 as specified in table 5.2 (Metamodel packages added in Level 2). With UML::CommonBehaviors::Communications at L2, it is not possible to properly define UML::Actions::BasicActions at L1 because UML::Actions::BasicActions::SendSignalAction::signal : UML::CommonBehaviors::Communications::Signal [1] becomes ill-formed at L1.
    The UML::CommonBehaviors::Communications package is also absent from table 4.1 (Detail of UML Reuse) in SysML 1.1, clause 4.2 (Architecture).

  • Reported: SysML 1.1 — Sat, 4 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Update clauses 4.2 (Architecture) and 5.1 (Compliance with UML subset) to
    reflect merging UML::CommonBehaviors::Communications at SysML’s L1.
    It is not clear what is the purpose of Figure 4.2 as it shows a combination of L2
    and L3 content from Table 5.2 and 5.3.

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

Participant Property constraint #6 not correct.

  • Key: SYSML12-19
  • Legacy Issue Number: 13666
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Participant Property constraint #6 not correct. In Blocks, UML Extensions, Stereotypes, Participant Property, remove constraint 6 (the one resrtricting the upper multiplicity of the end property). End properties of associations can have any multiplicity. See example in Figures 8.13 and 8.14, where the deliveredTo end of a participant property has multiplicity 1..*.

  • Reported: SysML 1.1 — Mon, 9 Mar 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    The constraint is misstated. The ParticipantProperty is a property of the
    association block, and it is this property to which the multiplicity constraint should
    apply. Each link of the association block has a value of the participant property
    which refers to one instance contained in the referenced end of the association.

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

Fig. 11.10: Pin of ControlOperator

  • Key: SYSML12-18
  • Legacy Issue Number: 13503
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The outpin of the control operator in fig. 11.10 is a control pin. But pins of control operators must be normal pins. The action Monitor Traction has no input pin.

  • Reported: SysML 1.1 — Fri, 13 Feb 2009 05:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.2
  • Disposition Summary:

    Resolution:
    This is a duplicate of 12576.
    Disposition: See issue 12576 for disposition

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

Representing multiple item flows on the same connector

  • Key: SYSML12-27
  • Legacy Issue Number: 14033
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Representing multiple item flows on the same connector. The specification should clarify the notation for representing multiple item flows with the same direction on a connector. In particular, UML allows for multiple information items to be represented with a single triangle, along with the list of the information item names spearated by a comma (refer to Figure 17.6 of the Superstructure Spec). A similar notation should be provided to represent multiple items flows in SysML. Proposal resolution: Recommend adding the following sentence at the end of section 9.3.1.4. " When several item flows having the same direction are represented, one triangle can be shown, along with the list of item flows separated by a comma." Also, add a constraint to 9.3.1.4 as follows" 1. If the ItemFlow has an itemProperty, there must be one conveyed classifier which matches the type of the item property.

  • Reported: SysML 1.1 — Sun, 28 Jun 2009 04:00 GMT
  • Disposition: Duplicate or Merged — SysML 1.2
  • Disposition Summary:

    Disposition: See issue 13945 for disposition

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

The information in Annex D regarding AP233 needs to be updated

  • Key: SYSML12-26
  • Legacy Issue Number: 14032
  • Status: closed  
  • Source: NIST ( Ms. Allison Barnard Feeney)
  • Summary:

    Out of Date Annex D.4: The information in Annex D regarding AP233 needs to be updated. AP233 to be released as DIS and this section needs to be revised to reflect changes to AP233.

  • Reported: SysML 1.1 — Fri, 26 Jun 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    see ptc/2009-08-13 for details

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

Connector Property value text.

  • Key: SYSML12-20
  • Legacy Issue Number: 13667
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Connector Property value text. In Blocks, UML Extensions, Stereotypes, Connector Property, Description, first paragraph, last sentence, the current text implies all instances of association blocks will be values of the connector property. The value is actually the subset of those due to the connector. Suggestion: - remove "exactly those" - replace "that are instances" with "(instances)".

  • Reported: SysML 1.1 — Mon, 9 Mar 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    Simplify the wording of this sentence further to refer directly to instances of the
    association block. Association blocks are blocks with regular instances, not
    merely links. Links cannot ordinarily be referenced by properties of a class, but
    because association classes in UML specialize both Association and Class, they
    can be referenced like all other class instances. Also modify the wording “that
    exist due to instantiation of the block” to allow creation as part of a block at any
    time during its lifetime, not merely at the time of instantiation.

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

SysML Issues based on UML 13080 New proposal for conjugate types for port

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

    The UML rtf’s response to this issue was to add an “isConjugated:Boolean” to the Port definition. This renders superfluous the SysML addition of the conjugated flag on flow ports. The SysML flag needs to be removed. In addition, the notation has changed to use a ~

  • Reported: SysML 1.1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    1. Remove isConjugated:Boolean from SysML since it is not needed anymore.
    2. Deprecate (but still maintain for backward compatibility) the current notation
    of conjugated flow ports and add the same notation as the new UML
    suggests.

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