IET
Decrease font size
Increase font size
Topic Title: TRAK - The Rail Architecture Framework
Topic Summary: Notification of the development/release of an architectural framework for transport / rail (& anything else!)
Created On: 19 August 2009 06:41 PM
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
View similar topics View similar topics
View topic in raw text format. Print this topic.
 19 August 2009 06:41 PM
User is offline View Users Profile Print this message


Avatar for nicplum.
nicplum

Posts: 9
Joined: 03 October 2002

The Rail Architecture Framework has been created and been sponsored by the Head of Systems Integration within London Underground.

Origins
It has it's beginnings in proprietary attempts to establish standards for system architecture. Prior to this there were single views of purely physical architecture. Architectural views of the physical, functional and geographic architectures of the underground were developed and the relationships between views established.

The initial approach didn't, however, make any reference to any external standards. The decision was therefeore taken to adopt IEEE 1471 (see links). Architectural viewpoints (as defined by IEEE 1471) specified the content of each view and the concerns addressed by each view. At this point there was no underlying metamodel defining the types of object and how they related to each other.

A metamodel with a richer langauge for describing rail architecture was needed. There wasn't any obvious architecture framework available within the rail industry and after deliberation it was decided to adapt the MODAF metamodel for use within the rail domain.

The driving needs have been:-
    simplicity
    no more elements or relationships than is absoutely necessary
    pragmatism - adequacy rather than perfection
    recognition of hard and soft 'systems' engineering products e.g. trains, control and signalling
    enabling systems such as busineses
    systems can include people ('human resource')
    supportable by tools


In adapting the MODAF metamodel paradoxically the TRAK metamodel has become domain-independent - 'systems' and the real world only contain a small set of types of 'thing' after all. If there is any domain-specific content then it is likely to be expressed in more detailed views, for example deployment involving geographic overlays. One of the benefits of commonality of metamodels is that architects with different domain background can readily understand and use a different framework.

Status
These are early days. It is in use on the Sub Surface Upgrade Programme (SUP) which is the largest single project being undertaken by LU to upgrade rolling stock and signalling on the Metropolitan, Hammersmith & City, Circle and District underground lines. It is also being used in a study by Birmingham University Centre for Railway Research & Education.

Potential Involvement
We are interested in any offers of help or involvement. One of the problems at the moment is trying to find examples of current rail or transport oriented diagrams/views to see what sort of architectural objects are needed and the sorts of views used to inform view development. What sorts of things are useful? What sorts of dependencies are most critical?


Further Reference
A plugin for the Sparx Systems' Enterprise Architect modelling tool has been developed and is available freely from the SourceForge site.

On this site there is a small section which provides information on the framework, the questions addressed by the views and documents such as the metamodel and a potted views guide. It also includes a UML profile for TRAK.

-------------------------
========
Epitaph: 'Under this sod lies another'

TRAK support: http://www.trak-community.org

TRAK training: http://www.eclectica-systems.co.uk/trak-training
 12 April 2012 06:34 PM
User is offline View Users Profile Print this message


Avatar for nicplum.
nicplum

Posts: 9
Joined: 03 October 2002

Now aiming to look at whether it is sensible to use enterprise architecture views for safety /security and if so how, where are the limitations, how should this support existing practice etc.

See post in the general technical forum.

-------------------------
========
Epitaph: 'Under this sod lies another'

TRAK support: http://www.trak-community.org

TRAK training: http://www.eclectica-systems.co.uk/trak-training
Statistics

See Also:



FuseTalk Standard Edition v3.2 - © 1999-2014 FuseTalk Inc. All rights reserved.