The Rail Architecture Framework has been created and been sponsored by the Head of Systems Integration within London Underground.
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:-
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')
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.
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.
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?
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