trakviewpoints project

TRAK SourceForge Projects

Definition

Implementation

TRAK Information

 

 

 

 

 

 

 

 

 

 

 

MVp-04 Assurance

This page reproduces part of the MVp-04 Assurance architecture viewpoint definition from the specification - TRAK00001. TRAK. Architecture Framework. Viewpoints. The page content is therefore subject to the same GNU Free Documentation License terms and conditions - see https://www.gnu.org/licenses/fdl-1.3.html

Most of the content is produced from a model of TRAK produced using a different set of architecture viewpoints!

Version

The TRAK MVp-04 Assurance architecture viewpoint is one of 24 architecture viewpoints defined in TRAK00001. TRAK. Architecture Framework. Viewpoints - current release is dated 2024_07_10.

MVp-04 Assurance Architecture Viewpoint Configuration
Perspective Viewpoint View ID Version Modified
Management MVp-04 MV-04 5 2024-07-10

Summary

The TRAK MVp-04 Assurance architecture viewpoint defines the requirements for the TRAK MV-04 Assurance architecture view. This involves allowed content and minimum acceptable content ('well-formedness' criteria). The TRAK00001. TRAK. Architecture Framework. Viewpoints specification also defines consistency rules that apply to a set of architecture views (an Architecture Description).

The TRAK MVp-04 Assurance architecture viewpoint content is summarised under the following sections:

The TRAK Architecture Viewpoints specification provides are complete definition not only of the MVp-04 Assurance architecture viewpoint but considerations for the architecture description formed from a set of architecture views.

Something needs fixing?

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns.

Stakeholder Concerns

The stakeholder concerns addressed by the MVp-04 Assurance Architecture Viewpoint are : Is the claim supported by evidence?, What are the claims made?, What is the basis of the claim?, . The stakeholders for the MVp-04 Assurance Architecture Viewpoint are :  Acquirer,  Auditor,  Builder,  Developer,  Maintainer,  Operator,  Owner,  Regulator,  User, .

Stakeholder Concerns Addressed by the MVp-04 Assurance Architecture Viewpoint

The TRAK MVp-04 Assurance architecture viewpoint addresses the following concerns:

  • Is the claim supported by evidence?
  • What are the claims made?
  • What is the basis of the claim?

Concerns addressed by all the TRAK architecture viewpoints.

Description

Describes a claim made about any other element with supporting (or opposing) arguments and evidence to establish how and whether a claim is proved or disproved. (as a result of the assessed evidence).

Typical claims for solutions include that a system is safe, fit for purpose and meets its requirements.

Allowed Content

TRAK architecture view content is defined in terms of triples - Node - connector - Node e.g. 'Argument has part Argument' that form short statements about the thing(s) being described.

Example of a 'Argument has part Argument' subject triple for the MV-04 Assurance Architecture View

'Argument has part Argument' is a Statement or Assertion in a MV-04 Architecture View

The rationale for this is explained separately.

Subject Statements (Triples)

These are statements (triples) that describe the subject of the MV-04 Assurance architecture view. Specifically these statements address the concerns for this MVp-04 Assurance architecture viewpoint. These form the basis for the well-formedness section of the MVp-04 Assurance architecture viewpoint.

These involve every metamodel element and may be added as content on any other architecture view. This is why the MV-04 Assurance architecture view is part of the Management Perspective.

There are 99 possible subject statements in total which include 42 metamodel elements ( Architecture Description , Architecture Task , Architecture View , Argument , Capability , Claim , Competence , Concept Activity , Concern , Contract , Document , Enterprise , Enterprise Goal , Event , Evidence , Function , Interaction Element , Item , Item Exchange , Job , Metric , Milestone , Mitigation , Need , Node , Organisation , Physical , Port , Port Connection , Project , Project Activity , Protocol , Requirement , Resource Interaction , Risk , Role , Software , Standard , System , Threat , Vulnerability and Zone ).

The subject statements are split into 4 groups:

Return to the top of the Assurance page.

Identification of Argument

5 possible subject statements:

  • Argument has part Argument
  • Argument opposes Argument
  • Argument opposes Claim
  • Argument supports Argument
  • Argument supports Claim

Return to the top of the MV-04 subject statements (triples).

Identification of Claim

47 possible subject statements:

  • Claim about Architecture Description
  • Claim about Architecture Task
  • Claim about Architecture View
  • Claim about Argument
  • Claim about Capability
  • Claim about Claim
  • Claim about Competence
  • Claim about Concept Activity
  • Claim about Concern
  • Claim about Contract
  • Claim about Document
  • Claim about Enterprise
  • Claim about Enterprise Goal
  • Claim about Event
  • Claim about Evidence
  • Claim about Function
  • Claim about Interaction Element
  • Claim about Item
  • Claim about Item Exchange
  • Claim about Job
  • Claim about Metric
  • Claim about Milestone
  • Claim about Mitigation
  • Claim about Need
  • Claim about Node
  • Claim about Organisation
  • Claim about Physical
  • Claim about Port
  • Claim about Port Connection
  • Claim about Project
  • Claim about Project Activity
  • Claim about Protocol
  • Claim about Requirement
  • Claim about Resource Interaction
  • Claim about Risk
  • Claim about Role
  • Claim about Software
  • Claim about Standard
  • Claim about System
  • Claim about Threat
  • Claim about Vulnerability
  • Claim about Zone
  • Claim has part Claim
  • Claim opposes Claim
  • Claim supports Claim
  • Organisation makes Claim
  • Role makes Claim

Return to the top of the MV-04 subject statements (triples).

Response to Argument

42 possible subject statements:

  • Architecture Description traces to Argument
  • Architecture Task traces to Argument
  • Architecture View traces to Argument
  • Argument traces to Argument
  • Capability traces to Argument
  • Claim traces to Argument
  • Competence traces to Argument
  • Concept Activity traces to Argument
  • Concern traces to Argument
  • Contract traces to Argument
  • Document traces to Argument
  • Enterprise Goal traces to Argument
  • Enterprise traces to Argument
  • Event traces to Argument
  • Evidence traces to Argument
  • Function traces to Argument
  • Interaction Element traces to Argument
  • Item Exchange traces to Argument
  • Item traces to Argument
  • Job traces to Argument
  • Metric traces to Argument
  • Milestone traces to Argument
  • Mitigation traces to Argument
  • Need traces to Argument
  • Node traces to Argument
  • Organisation traces to Argument
  • Physical traces to Argument
  • Port Connection traces to Argument
  • Port traces to Argument
  • Project Activity traces to Argument
  • Project traces to Argument
  • Protocol traces to Argument
  • Requirement traces to Argument
  • Resource Interaction traces to Argument
  • Risk traces to Argument
  • Role traces to Argument
  • Software traces to Argument
  • Standard traces to Argument
  • System traces to Argument
  • Threat traces to Argument
  • Vulnerability traces to Argument
  • Zone traces to Argument

Return to the top of the MV-04 subject statements (triples).

Verification of Claim / Argument

5 possible subject statements:

  • Evidence disproves Claim
  • Evidence has part Evidence
  • Evidence opposes Argument
  • Evidence proves Claim
  • Evidence supports Argument

Return to the top of the MV-04 subject statements (triples).

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns..

Optional Statements (Triples)

These optional statements (triples) for the MV-04 Assurance architecture view provide useful context with respect to a subject or universally allowed statements involving the subject or object (start or finish) elements in the Subject Statements (triples).

Universal statements may be added to any TRAK architecture view and describe typical concepts such as compliance or traceability:

Example of a 'Threat traces to Contract' optional triple for the MV-04 Assurance Architecture View

'Threat traces to Contract' - an optional statement or assertion for the MV-04 Architecture View

These statements address the concerns of their respective architecture viewpoint and will have been created first on these other architecture views.

There are 434 possible statements which may be used to augment the MV-04 Assurance architecture view, split into 5 groups:

Return to the top of the Assurance page.

Context - Roles

8 additional context statements:

  • Job plays Role
  • Organisation plays Role
  • Role extends to Job
  • Role extends to Organisation
  • Role extends to Physical
  • Role extends to Role
  • Role extends to Software
  • Role extends to System

Return to the top of the MV-04 optional statements (triples).

Document Publisher

6 additional context statements:

  • Architecture Description issued by Organisation
  • Architecture View issued by Organisation
  • Contract issued by Organisation
  • Document issued by Organisation
  • Evidence issued by Organisation
  • Standard issued by Organisation

Return to the top of the MV-04 optional statements (triples).

Universal - Applicable Requirements

126 additional context statements:

  • Contract governs Architecture Description
  • Contract governs Architecture Task
  • Contract governs Architecture View
  • Contract governs Argument
  • Contract governs Capability
  • Contract governs Claim
  • Contract governs Competence
  • Contract governs Concept Activity
  • Contract governs Concern
  • Contract governs Contract
  • Contract governs Document
  • Contract governs Enterprise
  • Contract governs Enterprise Goal
  • Contract governs Event
  • Contract governs Evidence
  • Contract governs Function
  • Contract governs Interaction Element
  • Contract governs Item
  • Contract governs Item Exchange
  • Contract governs Job
  • Contract governs Metric
  • Contract governs Milestone
  • Contract governs Mitigation
  • Contract governs Need
  • Contract governs Node
  • Contract governs Organisation
  • Contract governs Physical
  • Contract governs Port
  • Contract governs Port Connection
  • Contract governs Project
  • Contract governs Project Activity
  • Contract governs Protocol
  • Contract governs Requirement
  • Contract governs Resource Interaction
  • Contract governs Risk
  • Contract governs Role
  • Contract governs Software
  • Contract governs Standard
  • Contract governs System
  • Contract governs Threat
  • Contract governs Vulnerability
  • Contract governs Zone
  • Requirement governs Architecture Description
  • Requirement governs Architecture Task
  • Requirement governs Architecture View
  • Requirement governs Argument
  • Requirement governs Capability
  • Requirement governs Claim
  • Requirement governs Competence
  • Requirement governs Concept Activity
  • Requirement governs Concern
  • Requirement governs Contract
  • Requirement governs Document
  • Requirement governs Enterprise
  • Requirement governs Enterprise Goal
  • Requirement governs Event
  • Requirement governs Evidence
  • Requirement governs Function
  • Requirement governs Interaction Element
  • Requirement governs Item
  • Requirement governs Item Exchange
  • Requirement governs Job
  • Requirement governs Metric
  • Requirement governs Milestone
  • Requirement governs Mitigation
  • Requirement governs Need
  • Requirement governs Node
  • Requirement governs Organisation
  • Requirement governs Physical
  • Requirement governs Port
  • Requirement governs Port Connection
  • Requirement governs Project
  • Requirement governs Project Activity
  • Requirement governs Protocol
  • Requirement governs Requirement
  • Requirement governs Resource Interaction
  • Requirement governs Risk
  • Requirement governs Role
  • Requirement governs Software
  • Requirement governs Standard
  • Requirement governs System
  • Requirement governs Threat
  • Requirement governs Vulnerability
  • Requirement governs Zone
  • Standard governs Architecture Description
  • Standard governs Architecture Task
  • Standard governs Architecture View
  • Standard governs Argument
  • Standard governs Capability
  • Standard governs Claim
  • Standard governs Competence
  • Standard governs Concept Activity
  • Standard governs Concern
  • Standard governs Contract
  • Standard governs Document
  • Standard governs Enterprise
  • Standard governs Enterprise Goal
  • Standard governs Event
  • Standard governs Evidence
  • Standard governs Function
  • Standard governs Interaction Element
  • Standard governs Item
  • Standard governs Item Exchange
  • Standard governs Job
  • Standard governs Metric
  • Standard governs Milestone
  • Standard governs Mitigation
  • Standard governs Need
  • Standard governs Node
  • Standard governs Organisation
  • Standard governs Physical
  • Standard governs Port
  • Standard governs Port Connection
  • Standard governs Project
  • Standard governs Project Activity
  • Standard governs Protocol
  • Standard governs Requirement
  • Standard governs Resource Interaction
  • Standard governs Risk
  • Standard governs Role
  • Standard governs Software
  • Standard governs Standard
  • Standard governs System
  • Standard governs Threat
  • Standard governs Vulnerability
  • Standard governs Zone

Return to the top of the MV-04 optional statements (triples).

Universal - Requirement Compliance

126 additional context statements:

  • Architecture Description satisfies Contract
  • Architecture Description satisfies Requirement
  • Architecture Description satisfies Standard
  • Architecture Task satisfies Contract
  • Architecture Task satisfies Requirement
  • Architecture Task satisfies Standard
  • Architecture View satisfies Contract
  • Architecture View satisfies Requirement
  • Architecture View satisfies Standard
  • Argument satisfies Contract
  • Argument satisfies Requirement
  • Argument satisfies Standard
  • Capability satisfies Contract
  • Capability satisfies Requirement
  • Capability satisfies Standard
  • Claim satisfies Contract
  • Claim satisfies Requirement
  • Claim satisfies Standard
  • Competence satisfies Contract
  • Competence satisfies Requirement
  • Competence satisfies Standard
  • Concept Activity satisfies Contract
  • Concept Activity satisfies Requirement
  • Concept Activity satisfies Standard
  • Concern satisfies Contract
  • Concern satisfies Requirement
  • Concern satisfies Standard
  • Contract satisfies Contract
  • Contract satisfies Requirement
  • Contract satisfies Standard
  • Document satisfies Contract
  • Document satisfies Requirement
  • Document satisfies Standard
  • Enterprise Goal satisfies Contract
  • Enterprise Goal satisfies Requirement
  • Enterprise Goal satisfies Standard
  • Enterprise satisfies Contract
  • Enterprise satisfies Requirement
  • Enterprise satisfies Standard
  • Event satisfies Contract
  • Event satisfies Requirement
  • Event satisfies Standard
  • Evidence satisfies Contract
  • Evidence satisfies Requirement
  • Evidence satisfies Standard
  • Function satisfies Contract
  • Function satisfies Requirement
  • Function satisfies Standard
  • Interaction Element satisfies Contract
  • Interaction Element satisfies Requirement
  • Interaction Element satisfies Standard
  • Item Exchange satisfies Contract
  • Item Exchange satisfies Requirement
  • Item Exchange satisfies Standard
  • Item satisfies Contract
  • Item satisfies Requirement
  • Item satisfies Standard
  • Job satisfies Contract
  • Job satisfies Requirement
  • Job satisfies Standard
  • Metric satisfies Contract
  • Metric satisfies Requirement
  • Metric satisfies Standard
  • Milestone satisfies Contract
  • Milestone satisfies Requirement
  • Milestone satisfies Standard
  • Mitigation satisfies Contract
  • Mitigation satisfies Requirement
  • Mitigation satisfies Standard
  • Need satisfies Contract
  • Need satisfies Requirement
  • Need satisfies Standard
  • Node satisfies Contract
  • Node satisfies Requirement
  • Node satisfies Standard
  • Organisation satisfies Contract
  • Organisation satisfies Requirement
  • Organisation satisfies Standard
  • Physical satisfies Contract
  • Physical satisfies Requirement
  • Physical satisfies Standard
  • Port Connection satisfies Contract
  • Port Connection satisfies Requirement
  • Port Connection satisfies Standard
  • Port satisfies Contract
  • Port satisfies Requirement
  • Port satisfies Standard
  • Project Activity satisfies Contract
  • Project Activity satisfies Requirement
  • Project Activity satisfies Standard
  • Project satisfies Contract
  • Project satisfies Requirement
  • Project satisfies Standard
  • Protocol satisfies Contract
  • Protocol satisfies Requirement
  • Protocol satisfies Standard
  • Requirement satisfies Contract
  • Requirement satisfies Requirement
  • Requirement satisfies Standard
  • Resource Interaction satisfies Contract
  • Resource Interaction satisfies Requirement
  • Resource Interaction satisfies Standard
  • Risk satisfies Contract
  • Risk satisfies Requirement
  • Risk satisfies Standard
  • Role satisfies Contract
  • Role satisfies Requirement
  • Role satisfies Standard
  • Software satisfies Contract
  • Software satisfies Requirement
  • Software satisfies Standard
  • Standard satisfies Contract
  • Standard satisfies Requirement
  • Standard satisfies Standard
  • System satisfies Contract
  • System satisfies Requirement
  • System satisfies Standard
  • Threat satisfies Contract
  • Threat satisfies Requirement
  • Threat satisfies Standard
  • Vulnerability satisfies Contract
  • Vulnerability satisfies Requirement
  • Vulnerability satisfies Standard
  • Zone satisfies Contract
  • Zone satisfies Requirement
  • Zone satisfies Standard

Return to the top of the MV-04 optional statements (triples).

Universal - Traceability or Reference

168 additional context statements:

  • Architecture Description traces to Contract
  • Architecture Description traces to Document
  • Architecture Description traces to Requirement
  • Architecture Description traces to Standard
  • Architecture Task traces to Contract
  • Architecture Task traces to Document
  • Architecture Task traces to Requirement
  • Architecture Task traces to Standard
  • Architecture View traces to Contract
  • Architecture View traces to Document
  • Architecture View traces to Requirement
  • Architecture View traces to Standard
  • Argument traces to Contract
  • Argument traces to Document
  • Argument traces to Requirement
  • Argument traces to Standard
  • Capability traces to Contract
  • Capability traces to Document
  • Capability traces to Requirement
  • Capability traces to Standard
  • Claim traces to Contract
  • Claim traces to Document
  • Claim traces to Requirement
  • Claim traces to Standard
  • Competence traces to Contract
  • Competence traces to Document
  • Competence traces to Requirement
  • Competence traces to Standard
  • Concept Activity traces to Contract
  • Concept Activity traces to Document
  • Concept Activity traces to Requirement
  • Concept Activity traces to Standard
  • Concern traces to Contract
  • Concern traces to Document
  • Concern traces to Requirement
  • Concern traces to Standard
  • Contract traces to Contract
  • Contract traces to Document
  • Contract traces to Requirement
  • Contract traces to Standard
  • Document traces to Contract
  • Document traces to Document
  • Document traces to Requirement
  • Document traces to Standard
  • Enterprise Goal traces to Contract
  • Enterprise Goal traces to Document
  • Enterprise Goal traces to Requirement
  • Enterprise Goal traces to Standard
  • Enterprise traces to Contract
  • Enterprise traces to Document
  • Enterprise traces to Requirement
  • Enterprise traces to Standard
  • Event traces to Contract
  • Event traces to Document
  • Event traces to Requirement
  • Event traces to Standard
  • Evidence traces to Contract
  • Evidence traces to Document
  • Evidence traces to Requirement
  • Evidence traces to Standard
  • Function traces to Contract
  • Function traces to Document
  • Function traces to Requirement
  • Function traces to Standard
  • Interaction Element traces to Contract
  • Interaction Element traces to Document
  • Interaction Element traces to Requirement
  • Interaction Element traces to Standard
  • Item Exchange traces to Contract
  • Item Exchange traces to Document
  • Item Exchange traces to Requirement
  • Item Exchange traces to Standard
  • Item traces to Contract
  • Item traces to Document
  • Item traces to Requirement
  • Item traces to Standard
  • Job traces to Contract
  • Job traces to Document
  • Job traces to Requirement
  • Job traces to Standard
  • Metric traces to Contract
  • Metric traces to Document
  • Metric traces to Requirement
  • Metric traces to Standard
  • Milestone traces to Contract
  • Milestone traces to Document
  • Milestone traces to Requirement
  • Milestone traces to Standard
  • Mitigation traces to Contract
  • Mitigation traces to Document
  • Mitigation traces to Requirement
  • Mitigation traces to Standard
  • Need traces to Contract
  • Need traces to Document
  • Need traces to Requirement
  • Need traces to Standard
  • Node traces to Contract
  • Node traces to Document
  • Node traces to Requirement
  • Node traces to Standard
  • Organisation traces to Contract
  • Organisation traces to Document
  • Organisation traces to Requirement
  • Organisation traces to Standard
  • Physical traces to Contract
  • Physical traces to Document
  • Physical traces to Requirement
  • Physical traces to Standard
  • Port Connection traces to Contract
  • Port Connection traces to Document
  • Port Connection traces to Requirement
  • Port Connection traces to Standard
  • Port traces to Contract
  • Port traces to Document
  • Port traces to Requirement
  • Port traces to Standard
  • Project Activity traces to Contract
  • Project Activity traces to Document
  • Project Activity traces to Requirement
  • Project Activity traces to Standard
  • Project traces to Contract
  • Project traces to Document
  • Project traces to Requirement
  • Project traces to Standard
  • Protocol traces to Contract
  • Protocol traces to Document
  • Protocol traces to Requirement
  • Protocol traces to Standard
  • Requirement traces to Contract
  • Requirement traces to Document
  • Requirement traces to Requirement
  • Requirement traces to Standard
  • Resource Interaction traces to Contract
  • Resource Interaction traces to Document
  • Resource Interaction traces to Requirement
  • Resource Interaction traces to Standard
  • Risk traces to Contract
  • Risk traces to Document
  • Risk traces to Requirement
  • Risk traces to Standard
  • Role traces to Contract
  • Role traces to Document
  • Role traces to Requirement
  • Role traces to Standard
  • Software traces to Contract
  • Software traces to Document
  • Software traces to Requirement
  • Software traces to Standard
  • Standard traces to Contract
  • Standard traces to Document
  • Standard traces to Requirement
  • Standard traces to Standard
  • System traces to Contract
  • System traces to Document
  • System traces to Requirement
  • System traces to Standard
  • Threat traces to Contract
  • Threat traces to Document
  • Threat traces to Requirement
  • Threat traces to Standard
  • Vulnerability traces to Contract
  • Vulnerability traces to Document
  • Vulnerability traces to Requirement
  • Vulnerability traces to Standard
  • Zone traces to Contract
  • Zone traces to Document
  • Zone traces to Requirement
  • Zone traces to Standard

Return to the top of the MV-04 optional statements (triples).

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns..

Well-Formedness Criteria

Well-formedness criteria define the minimum acceptable view content based on the subject statements (triples). These criteria are not yet represented within the model of TRAK. Please refer to the MVp-04 Assurance definition within the TRAK00001. TRAK. Architecture Framework. Viewpoints specification.

Presentation Methods

The MV-04 Assurance architecture view may use any of following means to the statements (triples):

Note that a textual presentation is acceptable for any TRAK architecture view.

Examples

Verification of Claim / Argument Example of a MV-04 Assurance Architecture View - MV-04 Describing Compliance of TRAK Architecture Framework Against ISO/IEC/IEEE 42010:2011 6.1 e Architecture Frameworks - Consistency

MV-04 Describing Compliance of TRAK Architecture Framework Against ISO/IEC/IEEE 42010:2011 6.1 e Architecture Frameworks - Consistency

This example illustrates the use of a MV-04 assurance view to describe compliance against requirements supported by arguments and evidence This then enables a Compliance Matrix to be produced.

This particular example describes compliance of TRAK as an architecture framework against ISO/IEC/IEEE 42010:2011 6.1 e wrt consistency with the ISO 42010 conceptual model. Note that the Evidence elements contain the particular piece(s) of textual evidence that support the particular Argument(s).

The requirement structure/hierarchy is described first using a MV-03 Requirements and Standards architecture view.

Produced using a Neo4J graph database (community version) implementation of a TRAK architecture description.

Comments

The MV-04 Assurance architecture view is the master source (origin) on which you first create the following elements or statements:

The supporting (opposing) parts of an Argument or Evidence by inference also support the Claim or Argument respectively to which the top-most ‘whole’ Argument or Evidence is connected. The part Arguments or part Evidences may also support other Argument or Evidence elements.

A counter-claim is established using 'Claim opposes Claim'.

A counter-argument is established using 'Argument opposes Argument' (and is usually followed by (same) Argument opposes Claim).

When the 'acceptance date' attribute of a Claim, Argument or Evidence element is non-null and valid (not in the future) that element is deemed to have been accepted by the assessor of the claim.

Claims can be made against any element in any TRAK perspective. Claims can be made against a concept, the enterprise and its capabilities and goals, against a system and its ability to realise these capabilities. Claims can also be made against a project, its structure or activities (and thence against the introduction or removal from service of a system). Claims can also be made against standards or against a contract and its requirements.

Applied to the solution perspective this viewpoint supports the creation of a structured safety argument ("safety case"). It can also be used for design verification against the requirements for the design where there is a set of claims that the design meets these requirements. In this sense it could be used to describe how the organisation’s processes meet a set of external normative requirements ('Standards' in TRAK).

Neighbouring Architecture Views

The MV-04 Assurance architecture view content may overlap that of the following neighbouring architecture views:

Spotted an error or want to suggest something - create a ticket

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns..

The TRAK architecture viewpoints are subject to the terms of open source license: GNU Free Documentation License (Version 1.3, November 2008) at https://www.gnu.org/licenses/fdl-1.3.html.

Modification Date: 2024-12-21

Eclectica Systems Ltd