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

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