Features / Overview of the TRAK Metamodel

The TRAK Metamodel provides the tuples that are used to describe the things that appear in TRAK Views (each of which is specified by a TRAK Viewpoint - see the TRAK Viewpoints project site).

Metamodel Provides Triples - Statements or Assertions - to Describe Architecture e.g. a Threat Expoits a Vulnerability which results in a Risk

A tuple is formed from one or more triples, each consisting of either one or two node or block elements and a single connector or relationship element e.g.

triples:

Software has Vulnerability
Threat (synonym Hazard) exploits Vulnerability
Vulnerability results in Risk
Role requires Competence
Requirement has part Requirement - to describe a requirement structure / hierarchy

More complex statements - architecture description tuples - assertions or sentences can be formed by chaining triples together:

Role requires Competence to conduct Function
Resource performs Function poses Threat exploits Vulnerability results in Risk with
- (a different) Resource exposed to (same) Risk - TRAK allows you to describe both the thing causing the Threat and the thing impacted by the vulnerability to that threat.
Evidence supports Argument supports Claim about Architecture Description Element and possibly hence
- Evidence proves Claim about Architecture Description Element

TRAK is also unique as an architecture framework because the TRAK metamodel provides n-ary tuples - tuples where the object is itself a triple.

Application - Describing Assurance Cases

N-ary tuples are useful in assurance cases where claims of conformance are made against standards or atomic requirements. Assurance cases are used to describe what are sometimes termed 'safety cases'. In all the examples a Claim is made and then supported by a structured set of Arguments which in turn are supported by one or more Evidence items (CAE = "Claim-Argument-Evidence).

TRAK Metamodel Provides N-ary Tuples to Describe Assurance Assertions

Assurance assertions and assurance cases are described using a TRAK MV-04 Assurance architecture view.

Application - Describing Fault Trees

N-ary tuples are useful for describing fault trees where an event is caused by a combination of 2 or more child events.

The traditional presentation of a fault tree uses IEC 61025 notation where nodes representing events are attached to nodes ('gates') representing mathematical logic operations - AND, OR, NOT, XOR etc..

Classic Presentation of Fault Tree - One Top Event Occurs if Any One Child Events Occurs

This fault tree can be represented using a set of n-ary tuples in Turtle using a TRAK SVp-11 Solution Event Causes architecture view. Note that using 'block and line' notation below is only an approximation since attaching something to an individual connector or node separately triple does not the same meaning as attaching to the whole triple.

In the accurate representation using Turtle the combinational Event E002. 'Overun Causes' Event is represented by a graph which is then the object of 'Event caused by' subject and predicate representing parent Event G019.

TRAK Metamodel Provides N-ary Tuples to Describe a Fault Tree - Block and Line Approximation

Event trees are described using a TRAK SV-11 Solution Event Causes architecture view.

Metamodel Characteristics

The TRAK Metamodel :-

is agnostic of any software notation - it is solution-independent
- it defines what is required in terms of blocks, connectors, tuples and properties not how to implement them in a notation or architecture description language (ADL) such as the UML or the SysML etc.
defines a set of assertions or statements (approximately 900 possible assertions)
- in english language
- that can be read without needing to understand technical notations
- that form paths or routes or indeed "sentences", that
  - can be chained together e.g. Organisation makes Claim about Role requires Competence to conduct Function, Job plays Role extends to System
  - can be used to derive meaning
  - can be used to to check consistency of the view or architecture description content
  - support queries to check or produce artefacts such as compliance matrices, interface definition etc.
provides a rich structured language to describe systems (configured with people and technology) and their context in the" Residual World"

The fundamental defining part of an metamodel is a triple - a combination of node - connector - node e.g. Claim about Standard. A metamodel is different and distinct from an ontology or a taxonomy in this respect - more details.

The TRAK metamodel is neither an ontology nor a taxonomy but it does contain both an ontology and also a taxonomy.

The individual bits - each node element, each connector element, each property and each value are also described as part of an ontology description using OWL and RDF. This is not a metamodel description - no ontology description describes the triples that define the metamodel.

Some short descriptions of parts of the TRAK metamodel are provided by way of an introduction:-

Claim, Argument and Evidence tuples

Parts of the TRAK Metamodel

Properties

Every TRAK metamodel element that may appear in a TRAK architecture view has at the very least the properties of an Architecture Description Element - the generic parent of all architecture description elements. Many elements have additional properties on top of this to allow useful information to be held in a TRAK architecture description.

All of the properties are defined using standard accepted ontology sources such as the Oxford English Dictionary (OED), Dublin Core Metadata etc. for example the 'approval authority' property of the Architecture Description metamodel element:

Property	Definition	Use / Application	Applies To
approval authority	The entity that officially commends, sanctions or endorses. OED “approve (v.1), sense I.6.a” doi:10.1093/OED/9502413840, “authority (n.), sense II.2” doi:10.1093/OED/7868334486	Architecture description design record. Typically an individual, a role or an organisation or a combination.	Architecture Description

TRAK00002. TRAK. Metamodel

Definition of the 'approval authority' Property of an Architecture Description Element

Property Values

Enumerated values of properties are defined in a similar way. The following shows the definition for the value 'mandatory' that is used by the 'compliance level required' property for the Requirement metamodel element:

Value	Definition	Use / Application	Properties
Mandatory	Identifies that compliance or conformance is compulsory. OED 'mandatory (adj.), sense 2' doi:10.1093/OED/5246072936	Classifier. Equivalent to 'shall'	compliance level required