Aug 312017

This is one of the best example of system architecture (SA) application. Model is based on The Railway Architecture Framework (TRAK), a general enterprise architecture framework that sets the rules to develop systems architecture models across the aerospace, defense and transport industries, and is based on MODAF. Actual model adopts languages as: Unified Profile for DoDAF and MoDAF (UPDM), UML, SysML.

Model was presented at 27th annual INCOSE international symposium Adelaide, Australia, July 15-20, 2017 by Gary Arabian Systems Architecture and Requirements Manager at Asset Standards Authority.[1]

Download (PDF, Unknown)


The Transport Network Architecture (TNA) is a conceptual model that represents the structure and behavior of the transport system. The expected users of this model are planners, project managers, designers, operators and maintainer. The objective is to provide a robust yet flexible framework for consistent network asset planning and procurement. This will enable transport planners and project delivery teams to develop and acquire innovative solutions across all transport assets and modes.

On initiation of a project, the TNA supports the users in defining the business needs and requirements which determine what is to be achieved in the project and why. The users can use this model as the basis to introduce a solution that describes what the system must do in order to meet the business needs and requirements. The TNA bridges the link between the business needs (i.e. problem domain) and the system needs (i.e. solution domain) through its enterprise and concept perspectives. This model provides users with a visual representation of the traceability between the business needs and goals right down to the system level. [2]

Figure 1 shows the welcome page when opening the TNA model.

Figure 1. ‘Welcome to the Transport Network Architecture v1.0’ screen

Motivation and Rationale

The vision of transport is documented in publicly available strategies and plans on the Transport for New South Wales (TfNSW) website. To achieve this vision, Gary has led the development of the TNA model. The TNA model integrates multiple strategic documents into a structure, visual and relational format that can be used consistently across the cluster.

With the introduction of the Asset Standards Authority (ASA) within TfNSW, and the development of the Authorized Engineering Organization (AEO) framework, it was highly likely that each AEO would interpret standards and approach engineering disciplines differently unless guidance is made available for them to follow. To help ensure that AEOs adopt a uniform approach to engaging with Transport for NSW (TfNSW) for various transport projects, a model-based approach to engineering for the NSW railways was proposed. The principles around this strategy are that there should be an upper level of commonalities. [3]

Why TNA model?

  • Enable innovative solutions
  • Requirement traceability to long term goals
  • Improve quality of requirements
  • Encourage use of model-based approach

Figure 2. Strategy (TNA schema)

TNA  Structure

The structure was developed from the enterprise, concept, management, and solution viewpoints represented in the TRAK metamodel and the boundaries from UML-based design.

Figure 3 shows the high level structure of the TNA, where an ‘enterprise’ view is supported by a ‘concept’ view, that itself is realized by a ‘solution’ view. The engineering disciplines that support the transport network (heavy rail, light rail, bus network, ferry network, and so on) all interconnect and contribute to developing the physical, system or resource items that form the solutions represented in the ‘solution’ view. Alongside this structure is the management information that applies across all layers, capturing requirements and standards as they are specified.

Figure 3. Architecture

In general the TNA is developed through the use of both structural and behavioral modelling approaches. Structural modelling describes the network functions and their relationships, including:

  • functional hierarchy – which describes the functions, not the assets; for example, asset = escalator, function = permit vertical movement
  • physical architecture – which describes how functions are apportioned or deployed to physical systems and assets
  • geographic architecture – which describes how functions and assets are deployed geographically on the transport network

Behavioral modelling uses diagrams to describe how the network functions behave, for example:

  • use case diagrams that describe how functions are grouped within a system and how external ‘actors’ interact with these functions; actors can be humans or external systems
  • sequence diagrams that describe how various functions and actors interact with each other in processes over time
  • activity diagrams show a sequential flow of inputs, outputs and control, specify sequence and conditions for coordinating other behaviors

Modeling Techniques and Specifics

Please refer to document [3] for full description of used techniques. One of the great techniques used in this model is “Diagram identifier scheme”. Model contains a large number of diagrams with a variety of content and for different purposes. This causes problems in being able to identify which diagram should be consulted when looking for particular types of information. The ASA has therefore developed a TNA diagram identifier scheme based on the conventions used on their publications. This scheme (shown in Figure 3) begins with identifying the architecture framework standard set (shown as ‘AF set’ in Figure 3) from which the diagram is based. [3]

Figure 3. TNA diagram identifier scheme

Figure 4. Sample

Figure 5. Diagram name sample

The purpose of the TNA diagram identifier scheme is to quickly convey the intended content of the diagram along with the mode of transport and discipline applied. This multi-dimensional naming convention benefit the user in helping reduce the time required to find the diagram. [3]


[1] Gary Arabian. The Transport for NSW Transport Network Architecture Model, 27th annual INCOSE international symposium Adelaide, Australia, July 15-20, 2017

[2] T MU AM 06011 MO Transport Network Architecture model – package zip model published to view with web browser. Please read Appendix “D” of the below document for instructions on how to download and install the TNA model.

[3] T MU AM 06011 TI Transport Network Architecture – technical information document


Gary Arabian
Systems Architecture and Requirements Manager
Asset Standards Authority
Freight, Strategy and Planning Division Transport for NSW

5.00 avg. rating (98% score) - 1 vote

  2 Responses to “The Transport for NSW Transport Network Architecture Model”

  1. Unfortunately this repeats errors made in several papers released by Wollongong University.

    TRAK has not been known as ‘The Rail Architecture Framework’ for over 6 years – because there are no rail-specific parts to TRAK.

    The terminology used isn’t correct – the terms are used to mean different things. In TRAK, as in ISO/IEC/IEEE 42010:2011 a ‘viewpoint’ is a specification for a view. A ‘view’ is the end artefact produced against that (42010) viewpoint.

    MODAF and DODAF are Architecture frameworks whereas the UML, SysML and the UPDM are Architecture Description languages.

    In MODAF a (MODAF) viewpoint is a collection of view definitions, referred to as views and in MODAF a view might be the end product or the definition of the end product. The diagram identifier schema isn’t therefore valid because it uses viewpoint to mean a collection whereas the TRAK CV-05 artefact is a TRAK::view (and the corresponding viewpoint is the CVp-05, not the CV-05).

    In TRAK there are no solution viewpoints (or views) within the TRAK Concept Perspective. There is a separate Solution Perspective that contains the various TRAK Solution Perspective Viewpoints (which are prefixed with ‘SVp’ not ‘SV’) and therefore Figure 3 is wrong. Figure 3 uses ‘perspective’ as the collection whereas in Figure 4 it is ‘viewpoint’ In Figure 3 a ‘viewpoint’ is the specification for a view whereas in Figure 4 it appears to be a ‘view’.

    Inconsistent use of terms bedevils architecture description and this really doesn’t help.

    What would be interesting is how the specification of a viewpoint is adhered to with respect to the minimum acceptable content and consistency rules.

    • Avatar

      Hi Nic,

      Thanks for your comment and sorry for the delay. I only came across your comment now.
      While TRAK does have the word rail in there, we do emphasise that there is nothing rail specific about it. We began developing the TNA model in the heavy rail mode of transport simply because we had access to heavy rail specific information and subject matter experts. At the time of development of the heavy rail specific model, we envisaged how other transport modes were going to link into the parent generic < concept activities >. This forward thinking approach has allowed us to reuse elements and create specific light rail viewpoints and eventually expand into busses and ferries. E.g. < concept activity > Carry and protect passengers and crew (can be used for all modes of transport).

      Your comment on view and viewpoint (in reference to 42010) is correct. Key stakeholders suggested we define a set of ‘viewpoints’ within a ‘view’ even though it’s shown the other way around in 42010. The conceptual model and definitions from 42010 were explained in each workshop to set the context but many stakeholders saw ‘viewpoint’ subordinate to a ‘view’. After a while, It did become a confusing conundrum until we agreed to proceed with this arrangement as long as the overall use case for the TNA model was satisfied (i.e. elicitation of requirements). Similar situation with the terms ConOps and OpsCon being used interchangeably on projects…

      We have placed the solution view within the concept perspective simply because of the hierarchical nature of the TNA model. The rationale to not including a solution perspective is because this is a generic model and not project specific. There is no single parent < function > (from solution view) as they all stem from their parent < concept activities >. It is possible to create a solution perspective but would be a very laborious mapping exercise. The use case at the time (also current) was to use the functions to elicit ‘system requirements’, the concept activities to elicit ‘business requirements’ and the enterprise goals and capabilities as the high-level ‘business needs’ or rationale to these requirements. As a result, the current structure of the TNA model is being deployed on transport projects and has proven to be fit-for-purpose to date.

      Also FYI, since publishing v1.0, I have expanded the model to include a UPDM operational view to develop Use cases and activity diagrams. The < function > within the model are then mapped to the activities we define through each use case.
      E.g. Use Case – Enter passenger service from depot and operate Light Rail Vehicle (LRV)
      < Activity > perform LRV fitness for service checks
      < function > allow driver to check; HVAC system status, radio systems onboard, operation of lights, access diagnostic data etc…
      < function > Provide guidance to driver to continue the operation
      < function > Allow vehicle to manage automatic tests
      < function > etc…

      These use cases are further improving the model by identifying gaps in the solution views (functions). This approach assists project teams in synthesising a solution that satisfies the business needs and requirements.
      Happy to set up a video conference to explain in more detail.

      A/Systems Engineering Process Specialist

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



Time limit is exhausted. Please reload CAPTCHA.