Adelard is the company behind the concept of using Claims, Arguments and Evidence to develop safety assurance cases. They’ve done a sound job in explaining rationale and developing a systematic approach so it was only natural to want to understand the metamodel behind this, particularly as they seem to be the first to have introduced the [Claim - Argument - Evidence (CAE)][1] construct in describing software safety assurance.

Adelard’s Safety Assurance Metamodel

Argument supports Claim’ seems straightforward enough.

The first problem is ‘Subclaim’. A ‘sub’-anything is not a new type or metamodel element - it simply identifies a position in a hierarchy (much like ‘subsystem’ does). A Subclaim is really therefore a Claim ... beneath a Claim. We can therefore remove Subclaim and simplify.

Adelard’s Safety Assurance Metamodel - Simplified to Remove Subclaim

We then have ‘Claim is a (sub)claim of Argument’ which makes no sense. If Adelard wanted to assert this they should really have the relationship between Claim and Argument.

What is a Claim of an Argument? An Argument makes no Claims. It may support or oppose a Claim. If an Argument makes Claims then it isn’t an Argument - a single type - it is a composite type which is no longer simply an Argument. If you absolutely needed to you could state ‘Argument has part Claim’.

The definition on the Adelard site for Claim is:

Claim…  ‘a statement asserted within the argument that can be assessed to be true or false.

This cannot be true because it requires that a Claim is always part of an Argument - it has no independent existence (which is inconsistent with the metamodel). It does support the proposed ‘Argument has part Claim’ triple however.

We then have ‘Evidence is evidence for Subclaim’ which becomes ‘Evidence is evidence for Claim’. ‘is evidence for’ doesn’t tell us whether the evidence supports the Claim or opposes it so it really isn’t very helpful.

All of this is a bit of a muddle of a metamodel. A sub claim can be represented by ‘Claim has part Claim’. A sub-Argument is similarly ‘Argument has part Argument’ Both of these are recursive relationships involving a single entity / concept. What isn’t how the ASCAD tool really implements the original metamodel i.e. whether it constrains the allowed relationships. This is a problem because if the metamodel is wrong and is implemented in the tool then the semantics of any assurance model built will also be wrong. This is why application developers need to be transparent and share with us their underlying (implementation-free) model so we can scrutinise it. Ironically effective assurance cannot work without the underlying metamodel being publicly visible.

Another problem is that the definitions aren’t really consistent with the metamodel diagram shown. The text states:

Argument… This element is optional, but often it is good practice to include to explain the approach to satisfying the parent claim.

If the approach to supporting a claim is straightforward or well understood by the intended audience, it is permissible to simply link directly from the supporting claim.

What isn’t clear is whether the metamodel has an additional ‘Evidence supports Claim’ triple (in addition to the displayed ‘Evidence is evidence for Claim’) or whether they are inconsistent references to the same triple. From a practical level it is poor practice not to outline your arguments because in the early days of a design it helps to outline the Claims and supporting Arguments and discuss these with your regulator or Assessor, for example, to explain how and why the design has been partitioned. Having arguments is therefore a necessary part of the system design at an architectural level and also helps early design reviews internally.

Simply rationalising using the Adelard definitions then produces the following.

Adelard’s Safety Assurance Metamodel - Simplified Based on the Text Definitions

which still isn’t particularly good in terms of semantic assertions. The following is a lot clearer and caters for situations where Arguments oppose Claims and Evidence opposes Arguments. You can also then add ‘Claim opposes Claim’ to describe a counter-claim. You could also add ‘Argument opposes Argument’ - a counter-argument and ‘Claim opposes Claim’ - a counter-claim.

Improved Claim Argument Evidence (CAE) Assurance Metamodel

For many of these reasons this is why for TRAK we created a [metamodel that was more consistent and expressive for assurance][2] allowing many more statements / assertions to be made. It not only allows support for Arguments and Claims but opposition and also can describe the outcome i.e. the acceptance by the Assessor that a Claim is proved or disproved.Importantly, the Claims can be attached to any model element. A model of the system of interest using TRAK can therefore combine this with an assurance model of the system of interest - they are simply views on a single integrated model. It can also then be used to produced typical design verification artefacts such as a Compliance Matrix.

TRAK Assurance Metamodel Fragment based on Claim, Argument and Evidence (CAE)

Everyday Examples of Assurance

Typical examples of assurance which can be modelled include:-

• design assurance / design verification. In this case the claim is that the design meets requirement 12345, followed by a reasoned set of arguments. Following the verification method this is supported by evidence.
• process assurance. You might want to claim conformance for your (system engineering) processes with one or more international standards e.g. [ISO/IEC/IEEE 15288][3], [ISO/IEC/IEEE 42020][4]
• design integrity. Making a set of claims and supporting arguments concerning the architecture, separation, and resilience features to support structuring an assurance case.

References

• [1]: https://www.adelard.com/asce/choosing-asce/cae.html - Adelard Safety Assurance Metamodel. Accessed 27th-July-2018.
• [2]: https://trakmetamodel.sourceforge.io/claim_argument_evidence_CAE.html - ‘TRAK Metamodel - Claim, Argument and Evidence Tuples’. Accessed: 06-Feb-2020.
• [3]: https://www.iso.org/standard/63711.html - ‘ISO/IEC/IEEE 15288:2015 Systems and Software Engineering - System Life Cycle Processes’, ISO/IEC/IEEE 15288:2015, May 2015.
• [4]: https://www.iso.org/standard/68982.html - ‘ISO/IEC/IEEE 42020:2019 Software, Systems and Enterprise - Architecture Processes’, ISO/IEC/IEEE 42020, Jul. 2019. .