TRAK is a general architecture framework aimed at systems engineers. TRAK provides a set of triples and defines architecture view content to support description of a system of interest. It is based on MODAF 1.2.
History TRAK was originally commissioned by London Underground Limited.IET Forums – TRAK – The Rail Architecture FrameworkRail Value for Money Study. Whole System Programme Management Report. 25 May 2011 https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/4203/realising-the-potential-of-gb-rail-summary.pdf Development started in 2009 and was based on the then current views of architectural description within London Underground which were based on ISO/IEC 42010 and tied to the systems engineering life cycle defined in ISO/IEC 15288.
Although the original intent was to develop a rail-specific architecture framework, in adapting MODAF to suit local needs any defence or domain-specific content was removed. The result was a domain-free metamodel with architecture viewpoints that were only based on representing complex systems.
TRAK was released under open source licenses in February 2010.
It has been formally adopted by the UK Department for Transport who chair the TRAK Steering Group that manages the overall direction, strategy and formal releases of TRAK.
The TRAK development team received a Working Group award.INCOSE 2010 Working Group Award https://www.incose.org/about-incose/incose-recognition/working-group-awards#2010 (photo on the INCOSE Transportation Working Group pageINCOSE Transportation Working Group http://www.incose.org/practice/techactivities/wg/transport/). TRAK was a finalist for the 2011 IET Innovation Awards.IET Innovation Awards 2001 – Finalists http://conferences.theiet.org/innovation/finalists/index.cfm
Terminology Architecture Description Element An individual architecture description object that is used to describe or represent an item of real-world architecture. An architecture description element can appear in an architecture description.TRAK00002 TRAK. Architecture Framework. Metamodel Only Architecture Description Elements are used to form TRAK Architecture Views. An Architecture Description Element may be a node element or a connector element. A connector element and either two node elements are used to form an Architecture Description Tuple.
Architecture Description Tuple A named architecture description element connected by a named relationship to a named architecture description element. i.e. subject – predicate object – the basis of a sentence. e.g. Organisation A 'has part' Job B. It follows the natural language construct of Subject – Predicate – Object – also used in RDF. See Tuple. TRAK requires each tuple to be explicit. The Architecture Description Tuples are defined by the TRAK Metamodel. There are at least 950 Architecture Description Triples or assertions provided by the TRAK metamodel.. An Architecture Description Tuple is the smallest unit of architecture description.
Master Architecture View Each TRAK metamodel node has a master architecture view. Within an architecture description or model each element (individual) has to be created and shown on its master architecture view before it can be used on any other architecture view. For example, before describing functions using, say, 'System performs Function' on a SV-04 Solution Function View the System element would be first created and presented on a TRAK SV-01 Solution Structure View.
Perspective ISO/IEC 42010:2007 refers to an Architectural Perspective as 'Sharing of architectural models also facilitates an "aspect-oriented" style of architectural description'ANSI/IEEE Std 1471 :: ISO/IEC 42010 Recommended Practice for Architectural Description of Software-Intensive Systems A grouping of related and overlapping architectural views.
(Architecture) View ISO/IEC 42010 refers to an architecture view as 'work product expressing the architecture of a system from the perspective of specific system concerns'. A TRAK architecture view is defined as an Architecture Product in the TRAK metamodel. A TRAK architecture view presents a set of Architecture Description Tuples in accordance with its governing viewpoint.
(Architecture) Viewpoint ISO/IEC 42010:2007 – An architecture viewpoint defines a set of conventions (notations, languages and model types) for constructing a certain kind of view. In TRAK an architecture viewpoint is a specification for a single TRAK architecture view. Each TRAK Architecture Viewpoint defines both the allowed content and the minimum acceptable architecture view content as sets of Architecture Description Tuples.
TRAK structure
TRAK is defined in a logical way – that is to say free of any notion of how TRAK is implemented in any tool or any architecture description language.
TRAK has 24 architecture viewpoints which are grouped into 5 perspectives. Each viewpoint belongs to a single perspective and specifies a single view (type). Each viewpoint specifies what sets of types of architectural description element and relationships (tuples) can appear. The architectural description element types and relationships are specified by the TRAK metamodel.
The logical definition of TRAK consists of 3 documents, each of which is an open source project on SourceForge: TRAK00004. TRAK. Architecture Framework. document.TRAK00004. TRAK. Architecture Framework This controls TRAK as a whole. It defines the TRAK Architecture Perspectives, colours, by-laws (rules affecting the design of TRAK), architecture views and architecture descriptions, minimal modelling process. TRAK00001. TRAK. Architecture Framework. Architecture Viewpoints document.TRAK00001 TRAK. Architecture Framework. Architecture Viewpoints This defines the TRAK architecture viewpoints. TRAK00002. TRAK. Architecture Framework. Metamodel document.TRAK00002 TRAK. Architecture Framework. Metamodel This defines the architecture description elements that can appear in a viewpoint definition.
TRAK architecture perspectives TRAK has 5 architecture perspectives, each of which groups together architecture viewpoints and views of an overlapping subject area: Enterprise Perspective Concept Perspective Procurement Perspective Solution Perspective Management Perspective
Enterprise perspective This perspective covers the enduring capabilities that are needed as part of the bigger enterprise. These are high level needs that everything else contributes to and form part of the long-term strategic objectives that need to be managed.
Concept perspective The concept perspective covers the logical view of what is needed in response to the capabilities required by the enterprise in the enterprise perspective. It covers the logical connection of nodes, for example a service control centre, to other nodes with no recognition of how this might be realised either by organisation or technology. It also implies no particular part of a life cycle – it covers everything from concept to disposal ("lust to dust"!).
Procurement perspective The procurement perspective provides a top level view of the solution to the enterprise capability needs outlined in the enterprise perspective and developed in the concept perspective. It provides a way of showing how projects deliver the solutions described in the solution perspective to provide capability. It provides a way of describing time dependency between projects and is an essential for investigating capability gaps.
Solution perspective The solution perspective provides architecture views describing the solution – whether proposed or realised. It covers the parts of 'systems' whether human or machine, their exchanges and protocols. The solution perspective describes how organisations and equipment are organised and governed. The solution perspective describes how the logical requirements outlined in the concept perspective are realised and shows how the solution(s) realise the capability needed by the enterprise and described in the enterprise perspective.
Management perspective The management perspective provides architecture views that describe the architectural task and those relationships that are common across other perspectives. It provides ways of defining the scope and findings of the architectural task – structuring the approach and modelling.
The management perspective provides ways of describing the normative standards that apply. It contains architecture views that provide supporting information to aid the portability and understanding of the model(s).
The TRAK metamodel
The TRAK metamodel is shown below. Note that this is not a controlled copy.
The TRAK metamodel has 53 node elements, 79 connector elements, 118 properties and 101 enumerated property values. The combination of node and connector elements defines c 950 triples forming assertions to describe real world architecture and which may be presented by one or more TRAK architecture views if allowed by the respective architecture viewpoints.
There is an ontology description of the TRAK metamodel elements using RDF at. This is also presented as small set of HTML pages. The ontology description only describes the meaning individual elements with respect to other vocabularies not the triples defining the metamodel.
TRAK Differences vs MODAF 1.2.003 The TRAK Metamodel specification both simplifies and extends the basic concepts within the MODAF 1.2 metamodel. It has removed and redefined stereotypes and any defence-specific constructs have been removed. The TRAK Metamodel specification contains a comparison of the TRAK metamodel at initial release against MODAF 1.2.003. This is also outlined separately.
Significant changes vs MODAF include: the TRAK metamodel is aimed at users (the MODAF M3 is an abstract UML profile intended as a specification for tool vendors to implement MODAF – there is no metamodel for users only fragments of 'simplified metamodel' which aim to represent the more complicated M3). In TRAK the metamodel shown is the master one. The System element is central to TRAK and can represent hard systems and soft systems (in MODAF 1.2.003 System is an artefactMODAF Metamodel 1.2.004 MODAF version 1.2.004 and part of the Physical Architecture and cannot include non physical partsThe MODAF System Viewpoint(SV) 26 April 2010 ) TRAK can represent any type of interface exchange / flow – information, energy or resource TRAK can represent exchange characteristics associated with human resources – Organisations, Jobs and Roles TRAK includes means to represent requirements through the Standard (document/collection) and Requirement (atomic) metamodel elements and enforced by Contract TRAK includes the means to plan and describe the architecture task and architecture description and its organisation as a view (MV-02 Architecture Description Design Record) other types of dependency and associations can be represented – physical, membership, responsibility extent TRAK includes the means to describe assurance cases (including design verification) using the Claim – Argument – Evidence construct TRAK includes the means to describe safety / security – threats/hazards, vulnerabilities, mitigations and risk and causes / impacts TRAK includes n-ary triples where the object of a triple is itself another triple. This includes 'Claim about Architecture Description Tuple'. The MV-04 Assurance architecture view uses 'Claim about (Architecture Description Element satisfies Contract / Requirement/ Standard)' and 'Claim about (Contract / Requirement/ Standard governs Architecture Description Element)' to describe claims of conformance. The 'Event caused by (Event AND / OR / NOT Event)' triples form the basis for describing a fault tree using the SV-11 Solution Event Causes architecture view.