Section 6.1 is referring to the wrong version of SACM.

Referring to wrong version of SACM

Update to refer to 2.1.

Typo in 11.7 ArguementAsset (abstract) first line of section.

Typo in text of 11.7

Replace "bsse" with "base".

Typo first line of OCL, there is an extra space.

Typo in OCL

Typo first line of OCL, there is an extra space in the word AssuranceCasePackage.

In Section 3.1 Normative References, 3 of the references have been updated and the new versions should be cited.

Section 3.1 Normative References

3 of the references have been updated and the new versions should be cited.

Resolution: Shown in pdf, described below.
Replace:
ISO/IEC 15026-1:2013 Systems and software engineering - Systems and software assurance - Part 1: Concepts and vocabulary, 2013. <https://www.iso.org/iso/catalogue_detail.htm?csnumber=62526>
With:
ISO/IEC 15026-1:2019 Systems and software engineering - Systems and software assurance - Part 1: Concepts and vocabulary, 2019. <https://www.iso.org/standard/73567.html>
Replace:
OMG UML 2.5 Infrastructure Specification formal/15-03-01. <https://www.omg.org/spec/UML/>
With:
OMG UML 2.5.1 Infrastructure Specification formal/17-12-05. <https://www.omg.org/spec/UML/>
Replace:
OMG Meta-Object Facility (MOF) version 2.5 formal/2015-06-05. <https://www.omg.org/spec/MOF/>
With:
OMG Meta-Object Facility (MOF) version 2.5.1 formal/19-10-01. <https://www.omg.org/spec/MOF/>

Annex C repeatedly refers to an "ID". However, nowhere is an "ID" defined.

Section 8.1 page 17, figure 8.1, show that every SACMElement has an optional "gid", and that is subclass ModelElement has an optional "name". Either might be an ID, but I can't find any specific statement making that clear. I'm guessing that the gid is the ID, since otherwise you'd have to match all the possible language strings. However, that should be made clear.

Even more confusingly, an asCited Claim must state a package as well as the claim ID, so it appears that an ID is unique within a package but not between packages. A gid must be unique across the whole model. If IDs are unique across entire model, then in annex C it should made clear that package names are optional in an asCited Claim since they aren't needed to make it unique.

ID for graphical elements - should be name not ID

The figures mistakenly labelled with ID are revised to use name.

The "dot" in SACM 2.1's graphical notations is too small for tool implementation

Graphical Notation Dot too small to work in tools.

Increase "dot" size and update Figures.

The last sentence of the last paragraph of section 12.1 does not look right (not counting the misspelling of the second occurrence of “Artifacts”).

Typo - phrase accidentally repeated.

Remove duplicate text

Typo - phrase accidentally repeated.

Missing "or counter argument" after "counter evidence" in 11.11 Semantics, last line of page.

Missing words in 11.11

Insert missing “or counter argument" after "counter evidence" in 11.11.

Missing line break before "needsSupport" in Enumeration Litterals of 11.8.

Missing line break in 11.8

Add line break before "needsSupport" to separate terms.

In “Enumeration Litterals” of 11.8

“Litterals” mis-spelled.

Typo in text of 11.8

“Litterals” mis-spelled.

In 11.9 Semantics, misspelling – “with in” should be “within”

Typo in 11.9

Replace “with in” with “within”

Wrong package name used in second sentence of 9.3.

Wrong package name used in second sentence of 9.3.

Need to correct package name

Several terms are used in the specification without definition. Specifically: package binding, package interface, participant package, attribute and property. Defining these terms early in the specification will make it much easier for readers to understand the material.

Defining terms used in SACM

Add the following to section 4.

Attribute
A feature of a meta-element with a primitive type, such as integer, real, text, boolean, or date.

Feature
Super class of attribute and reference.

Participant Package
A Participant Package is any Package or Package Interface referenced by a Package Binding.

Package Binding
A Package that has references to at least two Participant Packages and to elements of those Participant Packages and defines the relationships among those elements.

Package Interface
A Package that is used to specify the elements of one Package that are declared “public” and available for use by other Packages.

Reference
A feature of a meta-element whose type is of another meta-element, such as +ParticipantPackage for AssuranceCasePackage

Section 3.2 Non-normative References, 1 of the references have been updated and there is one new reference to add.

Section 3.2 Non-normative References

Shown in pdf, described below.

Replace:
Goal Structuring Notation (GSN) Community Standard, Nov 2011. <http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf>

With:
Assurance Case Working Group. Goal Structuring Notation Community Standard. Technical Report
SCSC‐141BA v2.0, Safety Critical Systems Club, 2018. <https://scsc.uk/SCSC-141B>.

Add to end of list of references:
Model Based System Assurance Using the Structured Assurance Case Metamodel. R. Wei, TP. Kelly*, X. Dai, S. Zhao, R. Hawkins. Elsevier Journal of Systems and Software (JSS), 154, 211-233, 2019.

The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

Flexibility in relationships

The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

The relationship and use of bindings and interfaces are not well described for packages.

Clarify bindings and interfaces

The relationship and use of bindings and interfaces are not well described for packages - propose to add clarifying text for package interface and package binding elements and add an annex with examples.

Sections 8.5 & 10.10 the Constraints sections and for 101.10 the Semantics section too, use the word “property”, which is already defined as another part of the model – need to change to another word to avoid confusion.

Confusing use of the term property

On pages 19 and 30, change the word “property” to “feature”.

Definition of 11.5 ArgumentPackageBinding is unclear. More details needed to make it understandable and the constraints need enhancement to convey model details.

Definition is unclear

Revised to expand description and fixed label in constraints as well as added constrain language.

Need to revise this section to reflect the new version.

Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

Added sentence about the content of SACM 2.2 and revised previous SACM 2.1 content sentence to be past tense. Proposed change in attached pdf.

SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

There are many ways to include such information.

One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

Thank you for your time.

Defer for further discussion

Exchangeable graphic notations are an interesting addition to the SACM exchange standard for assurance cases but need more discussion.

I hope that this is not an erroneously reported issue. I am still very new to reading through OMG specifications and UML diagrams. Forgive me if this is a waste of your time.

It appears that the EMOF and the description of ArgumentAsset in section 11.7 on page 38 list a content composition but that composition is not shown in Figure 11.1.

I hope that this is useful. Thank you for all the great work on standardizing SACM 2.1. It's great to see the version out of Beta!

Figure 11.1 is correct but EMOF and text in 11.7 Associations are incorrect

Updating EMOF file to reflect change and deleting the Associations section from section 11.7 of the SACM specification.

The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

Clarification of use of AssertedContext

The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

Corrections for clarity and readability.