Structured Assurance Case Metamodel Avatar
  1. OMG Specification

Structured Assurance Case Metamodel — All Issues

  • Acronym: SACM
  • Issues Count: 22
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SACM22-13 Referring to wrong version of SACM SACM 2.1 SACM 2.2 Resolved closed
SACM22-19 Typo in text of 11.7 SACM 2.1 SACM 2.2 Resolved closed
SACM22-17 Typo in OCL SACM 2.1 SACM 2.2 Resolved closed
SACM22-9 Section 3.1 Normative References SACM 2.1 SACM 2.2 Resolved closed
SACM22-3 "ID" never defined in Annex C graphical notation. Is it the gid? SACM 2.1 SACM 2.2 Resolved closed
SACM22-26 Graphical Notation Dot too small to work in tools. SACM 2.1 SACM 2.2 Resolved closed
SACM22-25 Remove duplicate text SACM 2.1 SACM 2.2 Resolved closed
SACM22-23 Missing words in 11.11 SACM 2.1 SACM 2.2 Resolved closed
SACM22-21 Missing line break in 11.8 SACM 2.1 SACM 2.2 Resolved closed
SACM22-20 Typo in text of 11.8 SACM 2.1 SACM 2.2 Resolved closed
SACM22-22 Typo in 11.9 SACM 2.1 SACM 2.2 Resolved closed
SACM22-28 Wrong package name used in second sentence of 9.3. SACM 2.1 SACM 2.2 Resolved closed
SACM22-12 Defining terms used in SACM SACM 2.1 SACM 2.2 Resolved closed
SACM22-11 Section 3.2 Non-normative References SACM 2.1 SACM 2.2 Resolved closed
SACM22-16 Flexibility in relationships SACM 2.1 SACM 2.2 Resolved closed
SACM22-15 Clarify bindings and interfaces SACM 2.1 SACM 2.2 Resolved closed
SACM22-14 Confusing use of the term property SACM 2.1 SACM 2.2 Resolved closed
SACM22-18 Definition is unclear SACM 2.1 SACM 2.2 Resolved closed
SACM22-7 Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it. SACM 2.1 SACM 2.2 Resolved closed
SACM22-2 SACM lacks display information for tool interchange SACM 2.1 SACM 2.2 Deferred closed
SACM22-1 Figure 11.1. Missing 'content' composition on ArgumentAsset SACM 2.1 SACM 2.2 Resolved closed
SACM22-24 Clarification of use of AssertedContext SACM 2.1 SACM 2.2 Resolved closed

Issues Descriptions

Referring to wrong version of SACM

  • Key: SACM22-13
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Section 6.1 is referring to the wrong version of SACM.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:18 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Referring to wrong version of SACM

    Update to refer to 2.1.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in text of 11.7

  • Key: SACM22-19
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:32 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in text of 11.7

    Replace "bsse" with "base".

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in OCL

  • Key: SACM22-17
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:29 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in OCL

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

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Section 3.1 Normative References


"ID" never defined in Annex C graphical notation. Is it the gid?

  • Key: SACM22-3
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    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.

  • Reported: SACM 2.1 — Mon, 26 Oct 2020 03:19 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    ID for graphical elements - should be name not ID

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

  • Updated: Tue, 29 Jun 2021 12:55 GMT

Graphical Notation Dot too small to work in tools.

  • Key: SACM22-26
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:46 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Graphical Notation Dot too small to work in tools.

    Increase "dot" size and update Figures.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Remove duplicate text

  • Key: SACM22-25
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:44 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Remove duplicate text

    Typo - phrase accidentally repeated.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Missing words in 11.11

  • Key: SACM22-23
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:41 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Missing words in 11.11

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

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Missing line break in 11.8

  • Key: SACM22-21
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:35 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Missing line break in 11.8

    Add line break before "needsSupport" to separate terms.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in text of 11.8

  • Key: SACM22-20
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In “Enumeration Litterals” of 11.8

    “Litterals” mis-spelled.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:34 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in text of 11.8

    “Litterals” mis-spelled.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in 11.9

  • Key: SACM22-22
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:38 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in 11.9

    Replace “with in” with “within”

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Wrong package name used in second sentence of 9.3.

  • Key: SACM22-28
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Wrong package name used in second sentence of 9.3.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 16:19 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Wrong package name used in second sentence of 9.3.

    Need to correct package name

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Defining terms used in SACM

  • Key: SACM22-12
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:17 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    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

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Section 3.2 Non-normative References

  • Key: SACM22-11
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:16 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Flexibility in relationships

  • Key: SACM22-16
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:26 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Clarify bindings and interfaces

  • Key: SACM22-15
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:24 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Confusing use of the term property

  • Key: SACM22-14
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    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.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:20 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Confusing use of the term property

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

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Definition is unclear

  • Key: SACM22-18
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:30 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Definition is unclear

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

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

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

  • Key: SACM22-7
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need to revise this section to reflect the new version.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 14:37 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

SACM lacks display information for tool interchange

  • Key: SACM22-2
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    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.

  • Reported: SACM 2.1 — Sat, 24 Oct 2020 19:06 GMT
  • Disposition: Deferred — SACM 2.2
  • Disposition Summary:

    Defer for further discussion

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

  • Updated: Tue, 29 Jun 2021 12:55 GMT

Figure 11.1. Missing 'content' composition on ArgumentAsset

  • Key: SACM22-1
  • Status: closed   Implementation work Blocked
  • Source: Dependable Computing, LLC ( Will Hawkins)
  • Summary:

    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!

  • Reported: SACM 2.1 — Fri, 22 May 2020 23:37 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Clarification of use of AssertedContext

  • Key: SACM22-24
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

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

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:42 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    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.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments: