In the resolution to issue 14447 and 18407 in SysML 1.4 ballot 4, the metamodel figure is out of synch with the element descriptions, in particular for the source and target properties. The resolution to 18407 doesn't have revised text explaining when sourceContext and targetContext are needed.

Modify the metamodels figures to align with the element description for
DirectedRelationshipPropertyPath, and replace references to source and target
classifiers to source and target contexts. Explain when they are needed.

The resolutions to issues 18719 and 18653 have provided some refinements to viewpoint modeling. The current usage examples in appendix C for viewpoint modeling provide only a limited demonstration of viewpoint modeling. Some of the refinements such as ordered view hierarchies, expose relationships methods and concerns.

This resolution adds to previous resolutions made in response to issue (18653). A
summary of the proposed changes in this resolution include:
4. Expansion of the examples of modeling viewpoint stakeholders, concerns and
methods
5. View expose elements modeling
6. View hierarchy modeling
The current examples need to be expanded and corrected to be consistent with
these other resolutions.

SysML 1.3 supports the description of concerns for stakeholders and viewpoints. When modeling stakeholders and viewpoints and their respective concerns the viewpoint identifies the sub-set of the stakeholders concerns that are addressed by the viewpoint. The issue is that since these properties are currently typed by strings in the stereotype for stakeholder and viewpoint, they must be redundantly stated in both stakeholder and viewpoint description. This allows the description text to potentially diverge or conversely burden the model developer with having to change the model in 2 places.

This resolution adds to previous resolutions made in response to issue 18653. A
summary of the proposed changes in this resolution is simply to type concern with
the meta-class “comment” rather than string. This allows the concerns to be reusable
but still be a simple string.

UML 2.5 added support for diagram interchange. The SysML specification does not talk about diagram interchange, although modifications and extensions of the UML DI are needed.

This issue is addressed by adding an informative annex for SysML DI that extends
UML DI to support modeler options introduced by SysML, including in Annex A, and
to explain how to apply SysML DI as needed.

There is a need to apply the additional notation to ports that is used for other internal properties. In particular, we need to add compartments to represent the internal properties of ports so they can be connected to.

This resolution adds notation to ports, nested ports, and their definitions to be
consistent with other property and type notations, that includes compartments with
graphical and textual representations of structure and behavior. This also includes
the extensions used in parametric diagrams to represent value properties as
rectangles so they can be bound to.

The Deprecated Elements Annex should not imply deprecation of Views and Viewpoints, even though it has a transition procedure to SysmL 1.4. It should include a transition procedure for U&QK.

In the Deprecated Elements Annex, remove Views and Viewpoints from the Diagram
Elements tables added by the resolution of 18719. Add transition procedure for
SysML 1.4 Units and QuantityKinds. In the introduction, clarify that the Annex
contains transitions procedures for elements that are not deprecated.

Clauses 2-5 should be aligned with UML 2.5 and updates in SysML 1.4. For example, references to UML 2.4, compliance levels, Diagram Definition, and SysML DI.

remove references to “Superstructure” and update UML clause references for UML
2.5. Replace StandardProfileL2 in Architecture package diagrams with
StandardProfile, and add diagram for non-normative packages, including SysML DI

Annex A contains the following statements, which conflict with the UML notation:

• a rake symbol may appear in call behavior actions. In UML, the rake symbol is mandatory.
• a rake symbol on a state indicates that it references a state machine defined in another diagram. In UML, a “state composition” symbol is used for this purpose.

Moreover, Annex A does not reflect the fact that the SysML DI can be used for diagram usages.

This issue is addressed by removing references to call behavior actions and state machine
references in A.2, and removing the note stating that there is no diagram metaclass in UML

In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind.

There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK.
Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself.
This notation could suggest that one could change the tag/values shown on the value property itself.

It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself.
This tool-specific practice in fact suggests that there is a missing capability; that is:

QUDV unit and quantityKind could be specified on
the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them)
The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind)
A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property)
However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit.
Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property.
This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType)

Suggest the following:

Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind
Add a new stereotype: ValueProperty extending UML::Property with:
ValueProperty::unit : QUDV::Unit[0..1]
ValueProperty::/effectiveUnit : QUDV::Unit[0..1] – it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type
ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] – it is derived from the ValueType::quantityKind of the type of the ValueProperty.
Add a new stereotype: QuantityValue extending UML::ValueSpecification with:
QuantityValue::unit : QUDV::Unit[0..1]
QuantityValue::/unitConstraint : QUDV::Unit[0..1] – if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit
Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue

This resolution addresses the issue of the duplication of the concepts of Unit and
QuantityKind between the SysML profile and the QUDV library by introducing a new,
3rd model library called UnitAndQuantityKind. A separate resolution will address the
issue of the notation for ValueType, including TypedElements (e.g. Property,
ValueSpecification) typed by a ValueType.
Since the SysML Architecture figures 4.2 and 4.3 need to be updated to reflect the
addition of a new model library, this resolution also addresses the inaccuracies
reported in issue 18456 where these figures only showed one of the 2 model
libraries, PrimitiveValueTypes, omitting the 2nd library, ControlValues. Also, part of
18456 involves showing the <<ModelLibrary>> stereotypes that should have been
applied to each of SysML’s model libraries. As indicated in SysML 1.3, section 17.2,
a SysML Model Library is a UML Package with the UML
StandardProfileL2::ModelLibrary stereotype applied. Due to tool limitations, the BDD
diagrams for the 2 SysML model libraries in this resolution show the UML notation for
StandardProfileL2::ModelLibrary, that is <<ModelLibrary>> rather than the SysMLspecific
notation which would be <<modelLibrary>> or “bdd [modelLibrary]” in the
diagram frame. These notation details may change editorially without affecting the
substance of the resolution.
Originally, SysML 1.0 and 1.1 had a single concept of Unit and a single concept of
Dimension. The duplication began in SysML 1.2 at the specification level where the concept of Dimension was renamed to QuantityKind as part of an alignment with the
new ISO 80000-1 standard and a new conceptual model of Quantities, Units,
Dimensions and Values (QUDV) was introduced only in the document as Annex C.5.
The specification-level duplication became a practical problem in SysML 1.3 where
the QUDV conceptual model became available as a non-normative machinereadable
XMI artifact. With SysML 1.3, users and tool vendors have several options
for modeling definitions of Units and QuantityKinds:

• use the normative SysML stereotypes from the Blocks chapter
• use the non-normative QUDV libraries from Annex D.4
• use both in combination (e.g., apply the <<Unit>> stereotype to
  InstanceSpecifications classified by QUDV::Unit)
  These options multiply the cost of developing and maintaining libraries of Unit and
  QuantityKind definitions. The 3 different options above apply for defining a Unit or a
  QuantityKind. This means that there are 9 different options for defining the same pair
  of Unit/QuantityKind. Within the International System of Units alone, there are 20
  decimal prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has
  14 parts; part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table
  5 and 6 in Table 6). Thus, a complete library of all legitimate pairs of
  Unit/QuantityKind in scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed
  units and quantity kinds. It would be counter-productive and prohibitively expensive
  to attempt supporting nearly 10x different options of defining the same 1,260 pairs for
  just ISO 80000-1. SysML needs to adopt one option. Which one?
  Since the SysML Unit and QuantityKind stereotype provide a strict subset of the
  functionality of the QUDV Unit and QuantityKind concepts, this resolution effectively
  replaces the SysML::Blocks:: {Unit,QuantityKind} stereotypes with their QUDV Block
  counterparts. That is, SysML::Blocks::Unit changes from being a Stereotype to being
  a Class stereotyped by SysML’s Block. Similarly, SysML::Blocks::QuantityKind
  changes from being a Stereotype to being a Class stereotyped by SysML’s Block.
  Having changed the nature of Unit and QuantityKind from a Stereotype to a Class
  means that Unit and QuantityKind are M1-level classes, not M2-level stereotype
  extensions of metaclasses, it is important to clarify how the new Class-based Unit
  and QuantityKind concepts are intended to be used for defining particular Units and
  QuantityKinds.
  In principle, there are three ways to define Units and QuantityKinds:
  1. as M1-level InstanceSpecifications classified by
  SysML::Blocks::{Unit,QuantityKind}

  2. as M1-level Classes specializing SysML::Blocks::

  {Unit,QuantityKind}

  3. as M1-level Classes that are instances of M2-level metaclasses Unit and
  QuantityKind The third approach is outside the scope of the nature of SysML as a profile (a profile
  cannot define new metaclasses).
  The second approach requires fairly sophisticated tool support for specializing the
  associations between SysML::Blocks::Unit and SysML::Blocks::QuantityKind.
  Modeling association specialization is a challenging topic in UML because the
  mechanisms involved (i.e., generalization, redefinition, subsetting) have subtle
  distinctions (e.g., subsetting and redefinition are, respectively, in the domain of
  extensional vs. intentional semantics respectively) and the consequences of their
  combinations are difficult to analyze (e.g., disjoint vs. overlapping specialization).
  These modeling challenge carry over to definitions of new ValueTypes where the
  associations between ValueType and Unit/QuantityKind have to be specialized as
  well. The specialization approach is particularly challenging to understand because it
  inherently leads to asking questions about the meaning of the class-based
  specializations of Unit/QuantityKind and about the existence and meaning of
  instances of these classes.
  The first approach based on InstanceSpecifications approach avoids the complexity
  of the Class-based specialization of the 2nd approach. However, this
  InstanceSpecification-based approach requires careful attention about the UML tool
  support for modeling link instances of associations. In particular, such links must be
  fully specified with slots for each association’s end property regardless of its
  ownership by the association or classifier typing the opposite end. This tool support is
  important for the unambiguous interpretation of an InstanceSpecification classified by
  an Association as a representation of an instance of that Association between the
  InstanceSpecifications interepreted as representations of instances of the related
  Classifiers typing the ends of that Association.
  This resolution adopts the first approach, i.e., the M1-level InstanceSpecification
  based paradigm for defining Units and QuantityKinds. To maintain the separation
  between the normative SysML profile and the non-normative QUDV conceptual
  model, this resolution splits the QUDV::Unit and QuantityKind in two parts:

• the part corresponding to the SysML 1.3 Unit/QuantityKind stereotypes that
  will be refactored into Block definitions in a new UnitAndQuantityKind model
  library
• the rest that is unique to QUDV and that will be refactored as a specialization
  of the corresponding blocks from the UnitAndQuantityKind model library
  Because this resolution effectively promotes the QUDV concepts of Unit and
  QuantityKind into the normative SysML profile, the normative specification of these
  concepts is aligned to the publicly available VIM3 document instead of the non-public
  ISO-80000-1 document.

An unnumbered constraint on the Allocate relationship states: "A single «allocate» dependency shall have only one client (from), but may have one or many suppliers (to)."

The use or meaning of this n-ary relationship is not described. An informal survey of RTF members indicated that this n-ary allocation capability has not been implemented in any tool, nor has it been used by practitioners.

Note that Satisfy relationship (see 16.3.2.6) serves a similar purpose to Allocate, but does not require an n-ary implementation.

Removal of the n-ary requirement on Allocate would simplify efforts to unify SysML relationship dependencies. This requirement should either be 1) rationalized, elaborated and applied consistently across similar SysML relationships, or 2) deleted to facilitate ongoing SysML improvements.

To simplify SysML, the 1.4 RTF resolved to remove n-ary allocations from the
specification. The functionality that might be enabled by n-ary allocations can be
supported by constraints across multiple binary allocations.

9.3.2.8 FullPort - in description it says it cannot be conjugated. 1. Why? 2. Why there is no constraint for that?
what constraint 2 means? when binding connector is connector to proxy port?

See Issue 18278 (Conjugation of full ports question) for the answer to the question
about full port conjugation.
The reason for constraint 2 is that if we have a binding connector between a full port
and a part of the owning block that is not a port, it means the full port is no longer a
separate element of the system. Fulls ports bound to proxy ports are still separate
elements of the system because proxy ports do not specify separate elements of the
system. Constraint 2 should be generalized to cover all cases.

9.3.2.4 DirectedFeature , constraint 4 - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all?
constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties???
what does it mean "the meaning of direction"?? how direction is visible on port? what happens on nested ports when owning port is conjugated? example is needed.

The text of this issue was split into issues 18438, 18439, and 18441 so that the
multiple issues raised could be addressed in separate resolutions. All the text in this
issue is contained in one of these newer issues, so this original source issue is no
longer needed.
Disposition: See issues 18438, 18439, and 18441 for resolution

Table 11.1 on pg. 93 shows that the «controlOperator» stereotype can be applied to a call behavior action (when that call behavior action calls an activity that also has the «controlOperator» stereotype applied). However, the metamodel fragment on pg. 104 and the stereotype description on pg. 105 do not support that. Currently the spec. states that SysML::ControlOperator only extends UML4SysML::Behavior and UML4SysML::Operation, not UML4SysML::CallBehaviorAction. This would be appropriate, though, and seems to be in keeping with the original intent of the SysML Development Team given that it appears in Table 11.1

Proposed Resolution: Add another extension relationship from SysML::ControlOperator to UML4SysML::CallBehaviorAction.

Discussion:
This diagram extension is illustrated in Figure 11.2 (CallBehaviorAction notation) and
explained in the text above it. The metamodel is not extended.
Disposition: Closed, no change

The concept of Requirement, as intended in the original SysML specification, included the notion that textual requirements only have meaning in their original context. Requirements thus should not provide a source of inheritance. This precludes their use as classifiers for typing other Requirements or any other model elements. The 5 constraints listed at the end of section 16.3.2.3 are currently insufficient to enforce this concept.

Recommend adding a 6th constraint, precluding a class stereotyped by <<requirement>> from typing any other model element.

Add a 6th constraint to the text as recommended in the summary.

In SysML 1.3

11.3.1.1 Activity constraints

“The lower multiplicity at the part end must be zero.”

The diagram above Figure 11.1 on the previous page does not indicate 0 as the lower end. The default for a composition relationship at the part end is 1..1 and does not include 0.

However, as you fix the diagram consider eliminating the constraint 3.

I believe this constraint has been eliminated from UML 2.5 (in the works). The proper constraint is something like. (Conrad will know what’s in the UML spec). If the part end action starts running when the parent activity is started, and continues until the parent activity is ended, then the minimum multiplicity is non-zero. Otherwise, the lower multiplicity at the part end must be zero.

Whether the constraint is fixed or not, the diagram must include a lower end of zero.

Recommended fix, eliminate the constraint and fix the diagram

11.3.1.4.1 Constraint 3

Similar to above. The BDD in Figure 11.5 would need to explicitly be marked to allow for 0.

This constraint was not changed in UML. Recommend the diagram be fixed

Remove Constraint [3] in 11.3.1.1.1 (Notation) for the reasons filed. Figures 11.1 and
11.5 show generic notation. They aren’t examples, so do not need to have
multiplicities.

13.1 Table 13.1

The state machine decomposition symbol (which looks like eyeglass – not a rake) is not given

13.2 Table 13.2

The notation that comes from transition-focused state machines is included in the table. However, the notion that looks like:

(via entry point name)

is not indicated.

Supply identified missing notation in table 13.1 and table 13.2 In addition, supply
missing notation for StateMachineDiagram and cleanup composite state notation in
table 13.1 (so that lines leave on axis).

In SysML 1.3 C.4.8.2

Diagram C.34

The «activity» ProvideElectricPower is switched with «activity»ControlElectricPower. If you switch them now, you’ll be consistent with Figure C.35

Switch the two activities names and association end names.

Compartments "part" and "reference" must be renamed to "parts" and "references" in Figure 9.7 Usage example of proxy and full ports

Discussion:
Figure 9.7 in the formal SysML 1.3 specification was already corrected to use the
standard compartment names.
Disposition: Closed, No Change

Spec says: "Full ports can appear in block compartments labeled “full ports.” The keyword «full» before a property name indicates the property is stereotyped by FullPort. "
a) "full ports." should be changed to "full ports". (without dot inside)
b) does it say that even in full ports compartment keyword <<full>> is used? Or it is used near port symbol, when NOT in compartment? It should be clarified.
c) there is no single example of this notation - nor in Table 9.1 - Graphical nodes defined in Block Definition diagrams nor in any other diagram example in spec.
d) the same issues with "proxy ports" compartment.

No Data Available

Clause 9.3.2.8, FullPort - in description it says it cannot be conjugated. 1. Why?

This issue is a portion of issue 17254 (9.3.2.8 FullPort) and is filed to allow it to be addressed separately from the rest of 17254, and for the resolution of 17254 to ignore this portion of issue

The reason for constraining the full port from being conjugated is mentioned in
9.3.2.8 – first paragraph last sentence:
Full ports also cannot be conjugated, because behaviors defined on their
types are defined independently of the ports these types might be used on.
Constraint [4] reflects this (“Full ports cannot be conjugated (isConjugated=false).”).
The wording of the text above could be improved.

Figure 9.8 - can roles be ports?? or ports be association ends???? Is it new SysML notation? Where it is described??? Did we voted?
Tools does not support that.

No Data Available

reference properties "sp" in all subtypes must redefine "sp" from block P.
also, p1, p2, p3 in Plug Design 1 - are they redefining or not? if yes, must be

used, if not, how <<proxy>> appears there?

Add the suggested redefinition notations

Constraint [2] is incorrect. What does it mean "owned by the target object" ?what is object? Also, target is always the context of activity. Port can be not only owned, but inherited too.
[3] incorrect too - it can be inherited, not owned only.

Revise the text as indicated

In Part 1, there is a paragraph that says, in the context of describing the origins of SysML

Currently it is common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers.

This is not currently correct. It should be changed to.

It was then common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML has started to unify the diverse modeling languages currently used by systems engineers.

In SysML 1.3, the time-relative reference of "Currently" in the first sentence was
removed as an editorial change, so that this sentence now begins simply, "It is
common practice ..." The sentence that follows, stating that SysML is intended to
unify diverse modeling languages, in a manner similar to UML, does not accurately
reflect the variety of ways that SysML can help integrate languages in a Model Based
Systems Engineering environment. The recently completed SysML-Modelica
Transformation Specification is an example of the use of SysML to provide a systems
engineering context for the content expressed by another language, but not to unify
the full content of such a language.
Change the text of this paragraph to indicate that the goals of SysML are both to
unify languages used by systems engineers and to support a wider range of
discipline- and domain-specific languages.

I am working through some examples for MEF as you suggested.

When I look at the XMI for SysML 1.3, I find the following anomalies:

1. The model library PrimitiveValueTypes is a Package owned by the SysML Profile. This is what the XMI says but it is not shown as such in figure 4.3 in the SysML specification.

2. The PrimitiveValueTypes Package does have the SysML profile applied to it, but it does not have any stereotypes applied to the various DataTypes. Surely there should be elements of the following form in there:

<sysml:ValueType xmi:id="Stereotype1" base_DataType="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-Real" />

In order for such elements to be legal, the sysml xmlns needs to be declared. Also it’s somewhat unclear to me whether those elements should be children of the outer XMI element, or of the contained SysML package element.

These issues were raised on a draft version of proposed XMI for SysML 1.3. They
were already resolved in the final, published version of SysML 1.3 XMI.
Disposition: Closed, no change

It looks the Parametrics chapter is inconsistent about properties of constraint blocks. In one place it says they must be constraint properties, and in others it says they do not need to be. I assume constraint blocks can have properties that are not constraint properties, and these properties are informally called "parameters", is that right? If not, how are constraint parameters represented?

Specifically (in the beta2, inherited from 1.2):

• Section 10.3.2.2 (ConstraintProperty), Constraints subsection says "[2]The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock."

• Section 10.3.1.1 (Block Definition Diagram), Parameters Compartment subsection, says "Properties of a constraint block should be shown either in the constraints compartment, for nested constraint properties, or within the parameters compartment", which presumably means parameters are properties that are not constraint properties.

• Section 10.3.2.1 (ConstraintBlock):

Constraints Compartment subsection, says "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks"

Constraints, "[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, ..."

Discussion:
The removal of the ConstraintProperty stereotype by the resolution for Issue 12130
eliminates one of the references raised by this issue. As noted by the issue,
properties of a constraint block may be either constraint parameters or constraint properties that hold nested usages of constraint blocks. The remaining language is
consistent with these two basic categories for the properties of a constraint block.
Disposition: See issue 12130 for disposition

The derived property notation was originally included in SysML and removed. This notation is very helpful and should be restored. An example of how this is used can be found in Figure 7.2.1 of the 2nd edition of "A Practical Guide to SysML".

Several notations on features of blocks were left out of the original SysML
submission and addressed by subsequent issues. During the original SysML FTF,
Issue 10381 listed several of these additional notations to be considered. Following is
the original text of this issue originally received October 3, 2006:
Include examples of additional feature notations in the diagram elements table
for Blocks. Examples of UML notations that have not been excluded by SysML
include a "/" for derived features, underline for static features, and optional
visibility characters "+" "-" "#" "~".
Voting on a resolution of this issue was completed by the original SysML FTF on
February 23, 2007, as documented in the SysML FTF final report (OMG document
ptc/2007-03-19). This resolution added the underline notation for static features to
Table 8.1 in the Blocks chapter, but explicitly excluded the additional notations raised
by the issue. From the issue resolution in the FTF report, "After discussion by the
FTF, the “/” notation for derived features and visibility characters "+" "-" "#" "~" are not
being included in SysML V1.0."
This resolution was based on email discussion and a straw poll that occurred on the
original FTF mailing list, in which there was debate as to which of these notations
stemmed from software engineering practices and which belonged in a systems
engineering context.
Experience since then has clearly indicated that systems engineering modelers find
the derived notation useful to indicate properties that can be fully calculated based on
other properties. For example, they can indicate performance measures or other
objective criteria that can be rolled up from subsystems to a higher system level, or to
indicate dependent vs. independent values in a network of constraints. To reflect the uses of this UML notation in SysML models, and the expectation that it
be available even though it was excluded the last time it was directly considered, add
an example of the "/" derived property notation to Table 8.1 in the Blocks chapter.

ports with flow properties are displayed the same as flow ports in SysML 1.1? Can we say this clearly?
is <> notation based on flow properties only? How about directed features? Can we use the same notation to show direction?
<> notation is used on WHAT port types? proxy ? or full or even simple ports?
What notation (reversed?) is on conjugated port? How about nested port, when parent is conjugated?

Discussion:
The arrows only relate to flow properties (just like flow ports) – they do not relate to
required/provided. We don't need to say "like flow ports" since flow ports were
removed from the chapter and shifted to Annex B. According to table 9.1, any port
typed by a type with a flow property can have this notation (since it is shown for Port).
Disposition: Closed, no change

9.1 InterfaceBlock - unnamed compartment?? why not "operations"? What is "void" ??? no such primate type in sysml. Better example needed.

SysML compartments can be unnamed, but should not be used in the specification
for clarity. The void type should be removed.

• why Integer property is under "properties" compartment? why not "value properties"?

Discussion:
This is consistent with chapter 8 – value properties can appear in properties
compartments.
Disposition: Closed, no change

9.3.1.6 The fill color of port rectangles is white and the line and text colors are black. - Notation CAN'T be related to colors

Remove the following sentences from §9.3.1.6:
The fill color of port rectangles is white and the line and text colors are black.

SysML issue 18692 raised the problem of reuse of definitions of Units and QuantityKinds across SystemOfUnit and SystemOfQuantities respectively.
For example, the SI SystemOfUnits has 7 base units: meter, kilogram, second, ampere, kelvin, mole and candela.
These base units are in 1-1 correspondence with base quantity kinds in the ISQ: length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. (See SysML 1.3, Figure D.5).

The association between Unit and QuantityKind where a QuantityKind is the Unit::primaryQuantityKind for a given Unit is redundant with the choice of SystemOfUnits::baseUnit and SystemOfQuantities::baseQuantityKind.
For example, in the context of the SI, length as a baseQuantityKind of the ISQ is the "primary quantity kind" for metre as a baseUnit in the SI.
Conversely, length as a baseQuantityKind of the ISQ is not the "primary quantity kind" for kilometre in the SI because kilometre is not a baseUnit of the SI.

From a reuse perspective, it should be possible to define a coherent, non-SI SystemOfUnit whose baseUnits are the same as those of the SI except for replacing metre with kilometre.
This non-SI SystemOfUnit would be coherent with respect to the ISQ because length, as a baseQuantityKind of the ISQ would still be the "primary quantity kind" for kilometre as a baseUnit of this non-SI SytemOfUnit.
To support this flexibility of reuse of Unit and QuantityKind definitions, it is necessary to eliminate the Unit::primaryQuantityKind association from QUDV and instead derive the "primary quantity kind" of a given Unit in the context of a particular SystemOfUnit.

Furthermore, such a non-SI SystemOfUnit could define "inch" as a QUDV::LinearConversionUnit by reference to metre. In SysML 1.3 QUDV, this would require "inch" to specify that its Unit::quantityKinds are length.
This is redundant with the fact that metre already specifies length as its Unit::quantityKinds.
This redundancy could lead to inconsistencies if users define derived units and forget to specify their Unit::quantityKind or do so differently than the Unit::quantityKind of their referenced unit.
The only kind of Unit where it is logically necessary to specify Unit::quantityKind is for QUDV::SimpleUnit. In all other cases, the Unit::quantityKind collection can be derived.
For example, for any kind of ConversionBasedUnit, it can be derived by following ConversionBasedUnit::referenceUnit and querying that Unit for its quantityKind collection.
For a DerivedUnit, it can be derived by following DerivedUnit::factor and UnitFactor::unit and querying the Units for their quantityKind collections.

see pages 255 - 258 of ptc/2013-12-08 for details

An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.
The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:
Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.
Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.
Some of the limitations that have been identified include the following:
a) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application.
b) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders.
c) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information.
A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is included below.

In the above example, different subviews correspond to the different sections of the document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata).

In the example above, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents.
d) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others.

e) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).

summary of the proposed changes in this resolution include:
1. Extend View from Class instead of Package to enable means for referencing
views.
2. Add a presentation property to Viewpoint whose value(s) is/are the presentation
format for the view.
3. Establish a relationship between an instance of a view and an instance of the
model that the view is intended to represent.
General Background
It should be noted that SysML’s choice of Viewpoint and View is consistent with
industry standard definitions, and should be maintained. The intent of this resolution
is to preserve the basic view and viewpoint concepts, and only make changes
needed to refine the modeling elements based on industry experience applying these
concepts.
Expose
The expose relationship was added to address scalability issues with package import
as described in part b of this issue. Package import is not sufficient for dealing with
large models because it may require a large number of import relationships to identify
the imported elements in the package serving as a view.
The expose relationship resolves this issue by relating the view only to model
elements that correspond to access points to initiate the model queries performed by
the viewpoint method. The viewpoint method determines what additional elements or
other data will actually be part of the view relative to this access point.
The expose relationship extends generalization. This enables the viewpoint method
to be inherited by the view so that it represents the constructor of the view.
View Class
The change of view from a package to a class resolves part c of this issue. It may be
necessary or desirable to reference other views in order to construct a view that
conforms to a viewpoint. This results in a hierarchy of views that provides an ordered
traversal through the views. This ordering is necessary to understand the story the
views tell about the model.With view as a class, properties can be made for these
view references allowing the distinction of the different view trees within the hierarchy. Additionally, view as a class supports the concept that a view instance is a
specific artifact that is presented to the stakeholder.
Presentation Attribute
The presentation property was added to address issue a). In many organizations,
stakeholders or internal standards may require explicit rules for presentation such as
specific styles, colors and fonts defined in a stylesheets, file formats, and other
specifications. This property is intended to provide a flexible approach that supports
this need..

The ISO-80000-1 libraries need to be updated according to the resolutions of issues 18269, 18435 and 18681 in SysML 1.4 ballots 4 and 5.

Prior to resolving 18269, there was a duplication of Unit and QuantityKind in SysML
1.3 that had a corresponding duplication of non-normative libraries for a subset of
ISO 80000-1:
http://www.omg.org/spec/SysML/20120401/ISO-80000-1-QUDV.xmi
http://www.omg.org/spec/SysML/20120401/ISO-80000-1-SysML.xmi
As explained in the discussion of 18269, the duplication of Unit and QuantityKind
makes completing these libraries expensive due to the combinations implied in ISO-
80000-1: Within the International System of Units alone, there are 20 decimal
prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has 14 parts;
part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table 5 and 6
in Table 6). Thus, a complete library of all legitimate pairs of Unit/QuantityKind in
scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed units and quantity
kinds.
Following the resolution of 18269, the two ISO 80000-1 libraries from SysML 1.3 are
merged into a single ISO 80000 library based on the non-normative QUDV model;
that is, definitions of ISO 80000 units and quantity kinds are modeled as M1-level
InstanceSpecifications classified by a kind of QUDV::Unit and QUDV::QuantityKind
respectively.
The name of the library is changed from ISO 80000-1 to just ISO 80000 to reflect the
fact that the tables from which the SysML 1.2 and 1.3 ISO 80000-1 libraries came
from are in fact summaries of units and quantities defined across several ISO 80000
parts. For example, Table 1 in ISO 80000-1 shows the 7 base units and base
quantities of the SI and ISQ respectively. These units and quantities come from ISO
80000 parts 3,4,5,6,7 and 9. Annex D.4 previously showed diagrams for the ISO-80000-1-SysML library. D.4 is
updated to show the library of units, prefixes and quantities referenced in ISO-80000-
1 Tables 1 through 5 and from parts of Table 2 from the SI Brochure, which is not
included in ISO 80000-1, but the contents of which was included in previous versions
of SysML. Altogether, previous versions of SysML included definitions of units and
quantities traceable to a small subset of ISO 80000 parts: 3,4,5,6,7,9 and 10. For
SysML 1.4, the coverage is expanded to include all of the normative definitions of
parts 3,4,5,6. The coverage of parts 7,9,10 remains the same. This resolution also
includes the definition of units for bit, byte and octet and related quantities and binary
prefixes from ISO 80000-13.
This resolution addresses a problem reported by Hans-Peter de Koning about the
typing of Linear and AffineConversionUnit factors and offset which were previously
typed by Rational but should be typed by Number. This problem affects the precise
definition of the degree as a unit of plane angle, which is not representable as a
Rational (1 degree = Pi/180 radian).
This resolution depends on the resolution of 18692 and 18724 in ballot 6; however,
this resolution adds a capability for distinguishing derived units whose factors are
reduced (e.g., joule) or not (e.g., kelvin joule per kelvin). Mathematically, a nonreduced
derived unit is equivalent to a reduced derived unit (e.g., joule = kelvin joule
per kelvin). This is used rarely (there are 152 derived units in total; 140 are reduced;
only 12 are non-reduced). For the few cases where it’s been used, the justification
stems from two general principles:

• Ensure that all the QUDV-based derived units and quantities are
  mathematically derived in the same way as the derivations shown in their
  corresponding ISO 80000 definitions.
• Ensure that the dependencies among the QUDV-based models of ISO 80000
  parts reflect the normative dependencies from the corresponding ISO 80000
  documents.
  The only exception to the dependency principle stems from the dual definition of a
  unit, watt per square metre, in two ISO 80000 parts (5 and 6) that have no normative
  dependency to one another (parts 5 and 6 normatively depend on ISO 80000 parts 3
  and 4). The QUDV-based model has part 6 depend on part 5.
  In SysML 1.3, Figure D.7 showed the definition of a unit named ‘catalytic activity’ for
  a quantity kind named ‘katal’. Even though this appears in ISO 80000-1, Table 3,
  there is no indexed definition of this unit or quantity kind in any ISO 80000 part. Since
  all the units and quantity kind definitions in SysML 1.4 have an indexed definition in
  some part of ISO 80000, SysML 1.4 does not include ‘catalytic activity’ nor ‘katal’.
  Note about the tables of units and quantity kinds (Figure tables D8 and D11 through
  D23): The complete details pertaining to the QUDV-based definition of each unit and each
  quantity kind are available in the machine-readable file for the ISO 80000 library. The
  symbols for these units and quantity kinds have been reproduced in Presentation
  MathML on a best-effort basis according to the ISO 80000 documents.

Many UML elements are semantically equivalent to properties, but are not properties in the abstract syntax, such as behavior parameters, activity variables and call behavior actions. This means they cannot be used with deep nested connectors and other elements requiring property navigation. Add stereotypes based on properties that have "runtime" instance values for these elements.

Revise as suggested

Currently, QuanttiyKind can only be part of 1 SystemOfQuantities.

This seems wrong. For example, wouldn’t the amp and abamp, one is the SI unit and other being the emu-cgs unit of current, have the same quantity kind, current, but they might be in different SystemofQuantities.

This exclusive association would prevent reusing existing definitions of Units & QuantityKinds for custom systems.

This issue involves three problems related to reuse:
1) Currently, multiplicities between Unit (resp. QuantityKind) and SystemOfUnits
(resp. SystemOfQuantities) prevent reusing the same definitions of Units and
Quantities across multiple systems of these.
2) Defining units and quantity kinds as specializations of others is an important
reuse use case.
3) Defining units for quantities of dimension one due to such quantities
representing a number of entities or a ratio of two quantities of the same kind.
In both cases, Per ISO 80000-1 and VIM, the coherent derived unit for such
quantities is the number one. This raises the question whether there is a unit
“one” or not.
(1) Enabling reuse:
The resolution of issue 18681 in ballot 5 showed an updated Figure D.8 where the
association-owned end multiplicities made it clear that, as of SysML 1.3, a Unit and a
QuantityKind can be associated to at most one SystemOfUnits and
SystemOfQuantities respectively even though these associations are non-composite.
In practice, the 0-1 multiplicity on these associations precludes reusing existing
model library definitions of Units and QuantityKinds such as ‘metre’ and ‘length’ from
SysML’s ISO 80000-1 model library. There are three forms of reuse:
a) reusing the same definition in different systems b) defining a system to include all the definitions from another system
c) defining a system to reuse selected definitions from another system
For the first form of reuse, the 0-1 association-owned end multiplicities need to be
relaxed to 0..*. For the second and third form of reuse, it is necessary to introduce
new associations for a system of units or quantities to include or reuse zero or more
other system of units or quantities.
(2) Reuse and specialization for general quantities and units
Currently, QUDV provides limited support for defining a quantity kind as a
specialization of another (see ISO 80000-1, 3.1 and 3.2 Notes for examples).
Unfortunately, this capability is only available for a SpecializedQuantityKind. This
means that, for example, it is not possible to define a DerivedQuantityKind as a
specialization of another QuantityKind. A similar capability is needed for Units: for
two quantity kinds QK1 and QK2, if QK1 is a specific quantity kind for the generic
quantity kind QK2, then the unit U1 corresponding to QK1 ought to be a specific unit
for the generic unit U2 corresponding to QK2.
(3) Reuse and specialization related to quantities of dimension one
This involves two cases:
a) Derived quantities of dimension one
Derived quantities that are intrinsically defined as indexes, levels, numbers or
ratios all have dimension one (see ISO 80000-1, 3.8 and Annexes A3, A4).
Specializing quantities of dimension one motivates adding a capability for
specializing the corresponding units. For example, ISO 80000-1 3.8 and 3.9
mention radian as an example of a derived unit for a quantity of dimension 1
(i.e., plane angle whose dimension is length/length). However, it is also
possible to define a SystemOfUnits/ Quantities in which radian is defined as a
base unit for plane angle, a base quantity. In such a system, there is no
UnitFactor nor any QuantityKindFactor available to determine that plane angle
is a quantity with dimension one unless it is explicitly asserted.
b) Quantities representing a number of entities
Quantities that intrinsically represent a number of entities have dimension one;
however such quantities carry more information than just a number per ISO
80000-1, 3.8 Note 4. Accounting for this information requires adding a
capability for designating a particular Unit as the unitary value for quantity
representing a number of entities.
This resolution addresses all 3 aspects of reuse described above by refactoring
QUDV to:

• enable defining a Unit or QuantityKind as a specialization of possibly multiple
  Units or QuantityKinds respectively, designate a Unit as representing a unit count of entities,
• designate a QuantityKind as representing a number of entities,
• designate a QuantityKind as representing a quantity of dimension one.
  This refactoring helps avoid defining a unit “one” explicitly as the unit for all quantities
  of dimension one. Doing so would have resulted in a widely reused unit “one” that
  would carry no useful information (ISO 80000-1, 3.8 Note 2). Instead, the explicit
  “quantity of dimension one” designation capability puts the emphasis on defining a
  meaningful unit for such a quantity.
  See the resolution to issue 18724 which addresses the potential problems involved in
  reusing systems of units and quantity kinds as well as the need for refactoring the
  modeling of Unit::primaryQuantityKind. For changes pertaining to
  Unit::primaryQuantityKind, see the resolution to issue 18724

The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales:

D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM))

D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale)

D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high".

In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property.

Unfortunately, this requires defining the "priority" measurement scale twice:

Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition
For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to “low”, “medium” and “high”
From a metrology standpoint, both definitions of “priority” can be related to a definition of a Unit and a definition of a QuantityKind:

• The QUDV-based definition of “priority” can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV “priority” scale (See SysML 1.3, Figure D.8 in section D.5.2)

• The ValueType-based definition of “priority” can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2)

From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of “priority” is clearly useful for typing value properties and specifying their values.

Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since:

• A SysML::ValueType Enumeration really defines a “scale”, thereby alleviating the need for a separate QUDV::Scale concept.

• The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a “scale”, thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept.

Nicolas.

Follow the proposed suggestion except that providing explanations for modeling
“scales” using SysML ValueTypes and SysML Enumeration ValueTypes is
postponed until after peer review.
This resolution builds on the resolution to issue 18269 from SysML 1.4 Ballot 4 and
issue 18435 from SysML 1.4 Ballot 5.

Source:

Jet Propulsion Lab (Chris Delp – Christopher.L.Delp@jpl.nasa.gov)

INCOSE (Sanford A. Friedenthal – safriedenthal@gmail.com)

Summary:

This issue represents issues a) and f) from Issue 18391 – View and Viewpoint Limitations in Support of Auto-View Generation. An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.

The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:

Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.

View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.

Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.

Some of the limitations that have been identified include the following:

a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.)

b) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.

The following resolution is proposed for ballot 5. The other issues will be addressed
in a separate ballot.
Relative to issue a), the current viewpoint property for method is typed by string. The
following changes are intended to enable the viewpoint method to be specified by a
Behavior.
Relative to issue b), the current viewpoint property for stakeholder is typed by a
string. The following changes are intended to enable stakeholder to be represented
by a Stakeholder stereotype that extends classifier, so that it can be reused.
In addition, the current viewpoint property for language is typed by a string. The
following change types language by string, but adds clarification that this string
represents the language metamodel or profile URI.

In fig D.6 the quantityKind of the unit radian should be plane angle instead of radian

Discussion:
It seems that due to a copy&paste error the unit radian has a wrong quantityKind
value.
Disposition: See issue 18707 for resolution

description of Signal flow property has the sentence: “ […] imply sending and/or receiving of a signal usage”. It seems that the word “usage” is not convenient here and is confusing. It should be removed.

Subclause 9.3.2.7, Description subsection, third paragraph, relates flow properties
typed by signals to sending signals as follows:
Flow properties of type Signal imply sending and/or receiving of a signal
usage. [snip] An “out” FlowProperty of type Signal means that the owning
Block may send the signal via connectors and an “in” FlowProperty means
that the owning block is able to receive the Signal.
The text above does not require implementations to do anything special for flow
properties typed by signals beyond what is normally done for flow properties,
because it says “may”. Removing the text would not prevent implementations from
adding semantics as the text describes, because the specification would not disallow
it. However, the text implies alternative conforming implementations that should be
called out, but with more specific language referring to signal events. The revised text
should not require or prevent signals from being sent due to flow properties, because
this would invalid existing implementations unnecessarily.

Notation for inherited features. UML 2.5 has introduced a notation for inherited features. This notation is completely relevant to SysML, and should be added to the diagram elements tables. It applies to blocks, value types, signals, and other classifiers

This resolution includes provisions to add the UML 2.5 inherited features to SysML
1.4. The following text is from the UML 2.5 specification (ptc/13-08-16) section 9.2.4:
Members that are inherited by a Classifier may be shown on a diagram of that Classifier by
prepending a caret ’^’ symbol to the textual representation that would be shown if the
member were not inherited. Thus the notation for an inherited Property is defined like this:
<inherited-property> ::= ’^’ <property>
where <property> is specified in 9.5.4.
Similarly, the notation for an inherited Connector is defined like this:
<inherited-connector> ::= ’^’ <connector>
where <connector> is specified in 11.2.4.
Analogous notations may be used for all NamedElements that are inheritedMembers of a
Classifier to indicate that they are inherited.
Inherited members may also be shown in a lighter color to help distinguish them from noninherited
members. A conforming implementation does not need to provide this option.

SysML blocks currently include additional compartments labeled namespace and structure. This provides significant value to present various aspects of a block on a block definition diagram.

It would be very valuable to extend the standard compartments to enable representation of behavior. The request is to include a labeled compartment called 'behavior' to contain the classifier behavior and/or any other owned behaviors in this compartment.

This resolution includes provisions to add labeled behavior compartments to blocks
and parts that can include textual representations of classifier and owned behaviors.

Table 9.1, ItemFlow: The concrete syntax shows elements from an ibd. But table 9.1. is about bdd.

SysML also includes the concept of InformationFlows from UML (compliance level 3). The concrete syntax for an InformationItem or InformationFlow is missing.

The concrete syntax column in the Table 9.1 row for Item Flow was a copy and paste
mistake in the final published version of SysML 1.3. It did not correctly implement the
resolution for Issue 16635 in ballot 4 of the SysML 1.3 RTF. The correct figure
appears in the SysML 1.3 RTF Final Report (ptc/2011-11-08), but not in the beta
specification (convenience) documents that accompanied this final report (ptc/2011-
11-09 and ptc/2011-11-10).
Correct the concrete syntax column which appears in the ItemFlow row of Tables 9.1
and 9.2 to contain the figures already approved by the SysML 1.3 RTF in its
resolution of Issue 16635.
This resolution only corrects the error in producing the correct version of SysML 1.3,
as raised by the first paragraph of this issue. This urgent fix should not be delayed by
the question raised by the second paragraph of this issue, on whether the UML
concept and concrete syntax for InformationFlows is included in SysML.
The second paragraph of the issue is correct that SysML specification does not show
all forms of UML concrete syntax for UML InformationItem and InformationFlow. In
particular, UML has dashed-line notations for information flows and items, as well as
«flow» , «information», and «representation» keywords, which were never included in
SysML from its original submission.
A separate issue can be raised to address support for UML information flows, or to
update the contents of Clause 5, which contains the tables that define the current
SysML 1.3 compliance levels.
Note that the compliance definitions in Clause 5 will need to be updated in any event
to reflect the change in UML 2.5 that “The compliance levels L0, L1, L2, and L3 have been eliminated, because they were not found to be useful in practice.” (UML 2.5
FTF convenience documents, ptc/2013-09-05 and ptc/2013-09-06.) Again, separate
issues can be filed to address the need for these additional changes

SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind:

<Unable to render embedded object: File (--[if !supportLists]-->a) <) not found.-[endif]->by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification)

<Unable to render embedded object: File (--[if !supportLists]-->b) <) not found.-[endif]->by the property Unit::name and QuantityKind::name

This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind

The duplication is indeed unnecessary. In fact, the none of the definitions of Units
and QuantityKinds in the ISO-80000-1-QUDV library have slots for the Unit::name or
QuantityKind::name properties. Remove Unit::name and QuantityKind::name.
This duplication also applies to:

• QUDV::Prefix
• QUDV::SystemOfUnits
• QUDV::SystemOfQuantities
  This resolution builds on the resolution to issue 18269 from SysML 1.4 Ballot 4.

NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction have exactly the same property (propertyPath). It should be defined once in a generalization of NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction

Introduce an abstract stereotype for propertyPath that generalizes
NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction.
Constrain the specialized stereotypes to apply to connector ends, triggers, and
invocation actions, respectively.

9.3.2.4 What does it mean "the meaning of direction"?? how direction is visible on port?
This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

Disposition: See issue 18439 for resolution

9.3.2.4 DirectedFeature, constraint [2] - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all?

This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.

Constraint [2] should be reworded

We need a specialization of the UML standard <<refine>> stereotype within SysML in order to be able to contextualize the corresponding relationships instances just like the resolution to issue #14447 specifies for the <<trace>> stereotype.

Do as suggested. For in-deep discussion about contextualization, refer to issue
#14447.

The model library for Activities should be in a new package inside the SysML::Activities package. Figure 11.9 (Control values) does not have a frame, but Figure 8.7 (Model library for primitive value types) does. They should be consistent.

Disposition: See issue 18269 for resolution