Development of a Transport Network Architecture … of Defense Architecture Framework ... documenting, communicating, ... Development of a Transport Network Architecture Model

Development of a Transport Network Architecture Model

T MU AM 06003 TI

Technical Information

Version 1.0

Issued Date: 16 October 2014

Important Warning This document is one of a set of standards developed solely and specifically for use on the rail network owned or managed by the NSW Government and its agencies. It is not suitable for any other purpose. You must not use or adapt it or rely upon it in any way unless you are authorised in writing to do so by a relevant NSW Government agency. If this document forms part of a contract with, or is a condition of approval by, a NSW Government agency, use of the document is subject to the terms of the contract or approval. This document may not be current. Current standards are available for download from the Asset Standards Authority website at www.asa.transport.nsw.gov.au. © State of NSW through Transport for NSW

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017

T MU AM 06003 TI Development of a Transport Network Architecture Model

Version 1.0 Issued Date: 16 October 2014

Standard governance

Owner: Manager Systems Engineering Process, Asset Standards Authority

Authoriser: Principal Manager Network Standards and Services, Asset Standards Authority

Approver: Director, Asset Standards Authority on behalf of ASA Configuration Control Board

Document history

Version Summary of change

1.0 First issue

For queries regarding this document, please email the ASA at

[email protected]

or visit www.asa.transport.nsw.gov.au

© State of NSW through Transport for NSW

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017



© State of NSW through Transport for NSW Page 3 of 24

Preface

The Asset Standards Authority (ASA) is an independent body within Transport for NSW whose

purpose is to drive excellence in asset standards management by creating opportunities for

increased innovation, while ensuring safety and efficiency in design, construction and delivery.

The ASA is responsible for engineering governance, assurance of design safety and ensuring

the integrity of transport and infrastructure assets.

The ASA promotes and contributes to the development of industry capability by developing and

publishing guidance material in relation to organisation-level competency frameworks,

promoting sustainable development of technical and engineering capability.

This document provides an overview of network architecture and how it applies to TfNSW,

describes the methodology adopted by the ASA in developing a transport network architecture

model for heavy rail, gives a brief snapshot of the draft architecture and discusses the benefits

to TfNSW stakeholders.

The systems engineering group of the ASA has developed this document to share its progress

on developing a model-based systems engineering interpretation of the rail network. This

document has been developed with consultation from the TfNSW cluster and is developed with

reference to published architecture models.

This document aims to provide a single reference and progress update for the development of a

heavy rail transport network architecture model by the ASA.

This document is a first issue.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




Table of contents

1. Introduction............................................................................................................................................5

2. Purpose...................................................................................................................................................5 2.1. Scope ..................................................................................................................................................................... 5

3. Reference documents ...........................................................................................................................5

4. Terms and definitions ...........................................................................................................................6

5. Background............................................................................................................................................7

6. Transport network architecture............................................................................................................7 6.1. Network architecture for TfNSW .......................................................................................................................... 8

7. Approach to development of network architecture ...........................................................................9

8. Model mechanisms................................................................................................................................9 8.1. Architecture model structure ............................................................................................................................. 10

9. Process development..........................................................................................................................11 9.1. Identify scope of work ........................................................................................................................................ 11 9.2. Manage stakeholders.......................................................................................................................................... 12 9.3. Develop architecture model ............................................................................................................................... 13

10. The UK railway architecture framework ............................................................................................15 10.1. Enterprise viewpoint model ............................................................................................................................... 16 10.2. Concept activity viewpoint model...................................................................................................................... 16 10.3. Solution viewpoint model................................................................................................................................... 16

11. Draft NSW heavy rail network architecture.......................................................................................17 11.1. NSW enterprise viewpoint .................................................................................................................................. 17 11.2. NSW concept viewpoint...................................................................................................................................... 18 11.3. NSW solution viewpoint ..................................................................................................................................... 19 11.4. Benefits for NSW stakeholders .......................................................................................................................... 20

12. Network architecture development schedule ...................................................................................21

13. Future direction....................................................................................................................................22

Appendix A - The railway architecture framework......................................................................................23

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




1. Introduction

The Asset Standards Authority (ASA) is working with Transport for New South Wales (TfNSW)

to develop a common transport network architecture that will provide a stable framework for

network asset planning and investment decisions.

2. Purpose

This document describes the purpose, rationale, strategy and schedule of the ASA approach to

developing a transport network architecture.

It aims to provide a common understanding of goals, capabilities and concept activities to

ensure effective engagement by key stakeholders.

2.1. Scope

This document describes the TfNSW methodology of developing an architecture model for the

heavy rail passenger network.

This document focuses on the heavy rail passenger system. The intention is to expand the

scope to include other rail transport modes of rapid transit metro and light rail before including

all TfNSW transport modes, including roads and ferries.

3. Reference documents

International standards

AS/NZS ISO/IEC/IEEE 42010 Systems and software engineering – Architecture description

AS ISO 10007 Quality management systems – Guidelines for configuration management

ISO 15288 Systems and software engineering – System life cycle processes

Other references

Department of Defense Architecture Framework (DODAF); dodcio.defense.gov

INCOSE Systems Engineering Handbook: A guide for system life cycle processes and activities

v.3.2.2, June 2006

Ministry of Defence architecture framework (MODAF); www.gov.uk

NSW Long Term Transport Master Plan 2012

Object Management Group (OMG) Requirements Interchange Format (ReqIF) v1.0.1

OMG Systems Modelling Language (OMG SysML) version 1.3

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




TRAK metamodel, Dec 2013; TRAK Steering Group, chaired by the UK Department of

Transport

4. Terms and definitions

The following terms and definitions apply in this document:

AEO Authorised Engineering Organisation

ASA Asset Standards Authority

architecting process of conceiving, defining, expressing, documenting, communicating,

certifying proper implementation of, maintaining and improving an architecture throughout a

system’s life cycle

DBSE document-based systems engineering

ISO International Organization for Standardization

LTTMP long term transport master plan

LUL London Underground Limited

MBSE model-based systems engineering

MODAF Ministry of Defence architecture framework

OMG Object Management Group

RSSB Rail Safety & Standards Board

SME subject matter expert

subject matter expert a person assessed or recognised as having the highest level of

competence (including knowledge, skills and practical experience) in a particular field or

discipline

SysML systems modelling language

TfNSW Transport for NSW

TRAK The Rail Architecture Framework

UML unified modelling language

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




5. Background

With the introduction of the ASA, and the development of the Authorised Engineering

Organisation (AEO) framework, it was highly likely that each AEO would interpret standards and

approach engineering differently.

To resolve these issues, an approach to engineering for the NSW railways was proposed. The

principles around this strategy were that there should be an upper level of commonalities such

as:

a language that ensures consistency between engineering across disciplines from a

standards and engineering perspective

a type approval process for new and novel systems, equipment and technologies

an understanding of the elements of the NSW railway system

a consistent and collaborative approach to the documentation and presentation of

standards

an ability to clearly link standards to elements in the NSW railway system

an open standards approach to the development of engineering to prevent dependence on

any proprietary system of software or hardware

promoting new international standards and technologies

Furthermore, the approach had to be future-proof to the extent that information captured today

could still be used in the near future.

This document provides an introduction to network architecture modelling. It outlines the

processes that the ASA is using to develop a model and the architecture that the ASA is basing

its model on.

Section 11 provides an overview of the draft network architecture for heavy rail.

6. Transport network architecture

A transport network architecture is an architecture description used to provide multiple points of

view to a whole transport system by expressing fundamental concepts or properties of the

system through its elements. An architecture description captures the conventions and common

practices used across the system for different stakeholders and domains of application. It aims

to provide multiple viewpoints of the system to communicate understanding of the system and

its requirements. Each viewpoint satisfies an audience with an interest in a particular set of

aspects of the system.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




An architecture description assists the understanding of the system’s behaviour, composition

and change, which in turn affect the functional need, operational use and maintenance of the

system.

6.1. Network architecture for TfNSW

Historically, investment projects for TfNSW physical assets have been characterised by poorly-

defined business and system requirements, leading to a weak basis for implementing new or

altered assets. This has led to rework, budget overruns, schedule overruns, commercial

disputes, project delays and cancellations.

The ASA is working towards implementing a model-based systems engineering approach to

assist solution development and acquisition. A model-based systems engineering approach

would ensure that more precise sets of requirements are provided to suppliers with less room

for interpretation.

A transport network architecture model offers a reference framework to define 'solution agnostic'

enterprise goals, network capability, concept activities and functions. The model helps the

following:

creating topic-based network standards

performing network functional analyses

performing network performance analyses

identifying network asset configuration information

The architecture model can be used to support network design and develop network asset

planning practices including:

procuring new or altered assets

establishing robust business requirements

synthesising functional and performance system requirements

The architecture model can support the understanding of inter-relationships and interfaces

between functions, various system elements and components. It will assist specifiers of

requirements for new or altered assets to understand and specify comprehensive business

level, functional level and system level requirements specifications for proposed works.

The network architecture provides the capability to map standards from a management

perspective to functions from a solution perspective into one model. This will assist AEOs in

applying relevant standards.

Figure 1 shows how the network architecture feeds into the network requirements, and how

these both contribute to topic-based standards.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




Network architecture

Network requirements

Topic-based standards

Figure 1 – Architecture, requirements and standards

7. Approach to development of network architecture

The ASA developed an initial, simple architectural model, defined a structure for its

development and developed a process for expanding and clarifying the model into a network-

wide architectural framework.

Architectural models for transport networks have been developed in other countries and

jurisdictions but are new within TfNSW. The ASA approach was to seek best practice from the

international rail industry and other applicable industries.

8. Model mechanisms

The ASA developed an architecture model for heavy rail using ISO 42010 and the INCOSE

Systems Engineering Handbook, which recommend using an architecture description language

(ADL) and architecture framework.

Architecture description languages and architecture frameworks are two mechanisms widely

used in architecting and build on the concepts of architecture description. An architecture

framework establishes a common practice for creating, interpreting, analysing and using

architecture descriptions within a particular domain of application or stakeholder community. An

ADL provides one or more models to frame stakeholder concerns.

The ASA adopted unified modelling language (UML) as its ADL, and the UK railway architecture

framework (TRAK) as its architecture framework.

Section 10 provides a description of the UK TRAK metamodel. Appendix A includes a

schematic of the TRAK metamodel.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




8.1. Architecture model structure

The ASA divided the architecture into manageable sections that would provide a coherent and

structured model. The structure was developed from the enterprise, concept, and solution

viewpoints represented in the UK TRAK model, and the boundaries from UML based design.

The ASA is using systems architecture software that provides the capability to clearly link

standards to elements in the NSW railway system.

Figure 2 shows the high level structure of the ASA draft network architecture model, where an

'enterprise' model is supported by a 'concept' model, that itself is realised by a 'solution'

viewpoint model. The engineering disciplines that support the heavy rail network all interconnect

and contribute to developing the physical, system or resource items that form the solutions

represented in the solution viewpoint.

Enterprise viewpoint model

Concept viewpoint model

Solution viewpoint model

supports

realisesPhysical, system, or

software resource items (inc. new /novel items)

Heavy rail engineering disciplines (inc. other

engineering disciplines )

Figure 2 – Architecture model structure

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




9. Process development

Having defined the tools and the method, the ASA established a process to develop the network

architecture; that comprises identifying the scope, managing stakeholders, and developing the

network architecture framework.

Sections 9.1 through to 9.2 outline the process the ASA is using to develop the heavy rail

network architecture and provides details of its progress. Figure 3 provides a high level

summary of this process.

Figure 3 - Heavy Rail Network architecture development process

9.1. Identify scope of work

The scope of work was defined so that it could be clearly communicated to all stakeholders

before developing the architecture model.

The program management office of ASA worked closely with the individual developing the

architecture model to identify and define the scope of work, produce work lists, project

deliverables and schedules.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




9.1.1. Identify inputs

The first phase was the identification of the inputs and stakeholders that were engaged, both in

general and specific, to the scope of the model development.

9.2. Manage stakeholders

Architectural design needs to meet stakeholder requirements. All stakeholders were engaged to

provide input into the network architecture.

Developing the network architecture involves multiple stakeholders from diverse organisations

and all divisions of TfNSW; making it crucial to have well-placed stakeholder management. This

involved identifying the stakeholders, explaining the goals of the architecture project, defining

their scope and responsibilities and establishing communication protocols.

9.2.1. Identify stakeholders

The stakeholders are typically those who use the architecture model to their benefit or have a

vested interest in it. To address stakeholder needs, a scope of work was identified before

developing any architecture model. The scope of work defined the stakeholders. Examining

existing documentation and subject matter expert guidance helped to reach out to other

stakeholders. The scope of work also defined the stakeholder interfaces, roles and

responsibilities as part of developing the architecture models.

Initially, the stakeholders identified to assist in developing the transport network architecture for

TfNSW were:

ASA Network Standards

ASA Network and Asset Strategy

TfNSW Planning and Programs Division

TfNSW Transport Projects Division

Sydney Trains

TfNSW Customer Experience Division

TfNSW Transport Services Division

Authorised Engineering Organisations representing the wider rail industry

9.2.2. Explain purpose and goals

Stakeholders need to be engaged in the project so that they are available and able to

contribute, that their information and views are accurately captured and relevant, and are able to

provide acceptance of the material.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




The ASA's initial engagement with stakeholders introduced the project; its goals, deliverables,

project background and identified where each stakeholder could contribute. This allowed

stakeholders to understand the work and familiarise themselves with the network architecture

language and principles. The stakeholders were informed of their role, responsibilities,

boundaries and interfaces in the network architecture development process.

The architecture is a functional model and is solution-agnostic. This was clearly communicated

to stakeholders, to allow them to gain better appreciation of the model and bring them into the

mindset of systems engineering.

9.2.3. Define stakeholder scope

The project plan and schedule were presented to the stakeholders so they became familiar with

the deliverables and timelines. Stakeholders became aware of their scope of work and

responsibilities in developing the network architecture.

9.2.4. Establish communications protocols

A communications plan formalised stakeholder engagement and participation to understand

their relevance and input required for the project to develop the architecture models. The

communications plan included determining the frequency and method of involvement with each

stakeholder.

Stakeholders and other working groups for industry were engaged through presentations,

meetings and workshops, as well as ad hoc communications via email and telephone.

A simple correspondence plan was presented to the groups of stakeholders that identified the

forms of communication, key contacts and frequency of formal communications.

9.3. Develop architecture model

Following a defined architecture development process helped to:

develop a final draft that is endorsed and approved by all relevant stakeholders

develop a final draft that stays within the intended scope and timeline

9.3.1. Identify reference materials

Researching completed models, standards and published papers that are based on best

industry practice can provide an idea, basis or whole structure to the network architecture. Input

to the ASA model development came from operational procedures, technical specifications,

domain knowledge, standards and research publications for both current and proposed

systems.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




Having adopted the systems engineering approach from ISO 15288: 2008 later than many

industries and international rail operators, the ASA was provided with an advantage to tap into

resources that assisted its network architecture development.

Before incorporating research documents into the network architecture, the information was

shared with stakeholders for comment and approval.

9.3.2. Establish initial model

Initial models were developed with all relevant stakeholders. The main task was to establish a

model structure. The ASA followed the INCOSE Systems Engineering Handbook, which states

"An initial set of functions is defined to carry out the system's overall mission. Requirements are

derived to quantify how well the functions must be performed and to impose constraints on the

system".

This approach has been adopted throughout the solution-level architecture, where 'concept

activities' outline the 'overall mission process' and supporting functional requirements are

established to define the system.

Because the model includes stakeholders from different organisations and disciplines, it is

important to maintain consistency in terminology and architecture interfaces. All relevant

engineering disciplines were engaged when looking at interfaces to the current scope of work.

9.3.3. Review and refine model

Stakeholders were engaged to review the model. Reviewing the model led to an iterative

process to refine the model through a set of workshops, meetings and independent reviews.

The review process contained the following actions:

remove or add functions for model refinement

maintain consistent terminology

maintain architecture interfaces

ensure reliable sources

discuss thought processes

Note: During the review process, it was important to keep track of any baseline

versions to serve as the basis for defining change, conducting verifications and for

other management purposes. These baselines are required, according to ISO 1000,

for a configuration control board to review the audit trail models that have evolved to

its current state.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




9.3.4. Produce draft model

After the models were reviewed by all stakeholders, the model was changed. The resulting

architecture model contains systems of systems that consider the causal effects any change

makes on the overall system.

Section 11 provides an overview of the draft ASA heavy rail model architecture.

10. The UK railway architecture framework

The ASA based its initial model on the UK-developed 'The Railway Architecture Framework'

(TRAK) metamodel. TRAK is a general enterprise architecture framework that sets the rules to

develop systems architecture models across the aerospace, defence and transport industries. It

was developed by the UK Rail Safety & Standards Board (RSSB) and has been used by

London Underground Limited (LUL) and Network Rail. TRAK is based on ISO 42010 Systems &

Software engineering – Architecture description and derived from the UK Ministry of Defence

Architecture Framework (MODAF).

The model is described through unified modelling language (UML).

The TRAK metamodel provides the opportunity to view the architecture from different viewpoints

namely; management, enterprise, concept, procurement and solution viewpoints.

The transport network architecture can be developed through static or behavioural modelling.

Static modelling describes the network functions and their relationships, including:

functional architecture, 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

Behavioural, or dynamic, modelling, which uses diagrams to describe how the network functions

behave:

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

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




10.1. Enterprise viewpoint model

The TRAK metamodel includes the enterprise viewpoint to cover the enduring capabilities that

are needed to fulfil the goals of the larger enterprise. This viewpoint defines the overall

enterprise and its scope, goals, capabilities, and metrics; and identifies the organisations that

manage and realise them. These are high level needs that everything else contributes to and

form part of the long term strategic objectives. The enterprise view provides a mechanism to link

into higher level goals such as those described in NSW Long Term Transport Master Plan.

In the TRAK architecture, the components that comprise the views are known as 'stereotypes'

and are defined as follows:

enterprise: an organisation having 'bottom line' goals; often a collection of divisions and

organisations

enterprise goal: an objective or target for an enterprise

capability: the ability to do a particular kind of action or the extent of someone's or

something's ability

metric: a measure

organisation: an organised body of people, associated for a particular purpose

standard or document: a formal document that provides requirements, specifications,

guidelines or characteristics that can be used consistently to ensure that materials,

products, processes and services are fit for their purpose

Only the enterprise, enterprise goal, and capability stereotypes are part of the enterprise

viewpoint. The metric, organisation, and standards are part of the management and solution

perspectives.

10.2. Concept activity viewpoint model

The concept viewpoint in the TRAK architecture covers the logical view of what is needed to

support the capabilities in the enterprise viewpoint model. It provides the logical connections

between the solutions and business needs.

TRAK refers to the activities within this viewpoint as 'concept activities' and defines them as "a

high level logical process which is independent of how the activity is carried out".

10.3. Solution viewpoint model

The solution perspective of the TRAK metamodel provides views of the operational solutions to

the concept activities. There could be more than one solution that meets the needs expressed

in the concept viewpoint. This level of the model represents a hierarchical structure of 'functions'

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




which realise 'concept activities'. TRAK defines a function as "an activity which is specified in

context of the resource (human or machine) that performs it".

11. Draft NSW heavy rail network architecture

The ASA is focusing on developing enterprise, concept and solution viewpoint models

described in the TRAK metamodel. The three sections interconnect to make up one overall

heavy rail network architecture:

enterprise viewpoint model, which expresses the high level and enterprise needs and

capabilities of the system

concept viewpoint model, which contains logical processes that describe what is needed to

support the capabilities in the enterprise viewpoint, independent of how the activities are

performed

solution viewpoint model, relates to the engineering disciplines and provides the solutions

that could meet the needs expressed in the concept viewpoint

Figure 4 shows the relationship between the three sections. Figure 5 and Figure 6 show more

detailed extracts of the draft heavy rail architecture.

Capability statement

Concept activity

Concept activity

Solution

Capability statement

Concept activity

Solution Solution Solution

Realises Realises Realises Realises

Supports Supports SupportsSupports

Realises

Enterprise viewpoint

Model

Concept viewpoint

model

Solution viewpoint

model

Figure 4 - Three sections of network architecture

11.1. NSW enterprise viewpoint

The long term strategic objectives of TfNSW provide the business needs for the enterprise view.

TfNSW enterprise goals are derived from the NSW Long Term Transport Master Plan and other

legislative documents.

The enterprise view provides a mechanism to link activities into higher level goals such as

'improve sustainability' or 'improve quality of service'.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




Figure 5 shows some of the stereotypes defined in the draft heavy rail architecture model. A

standard governs an enterprise goal whilst an enterprise aspires to an enterprise goal. This

enterprise goal requires a capability which can either depend on other sub-capabilities and be

quantified by a number of metrics.

Figure 5 - Snapshot of draft NSW heavy rail architecture

11.2. NSW concept viewpoint

The concept viewpoint in the draft NSW architecture comprises a hierarchical structure of

interacting activities that have been grouped into:

asset life cycle management

safety management

environmental management

railway boundary management

various engineering operational activities

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




capacity planning

passenger service operations

11.3. NSW solution viewpoint

Good systems engineering practice divides complex models into manageable portions to reduce

error and confusion. The solution viewpoint model in the draft NSW architecture is based on the

engineering disciplines of the heavy rail network. The reasons for using engineering disciplines

include:

simplicity of maintaining of the model

ease of interpretation of the model

needs and use by TfNSW divisions

The software used by the systems engineering team provides the capability to create a structure

whilst maintaining the communication between the other viewpoints. This allows for the creation

of a single overall model comprising manageable groups.

Figure 6 represents a snapshot showing the enterprise, concept and solution viewpoint

particular to station operations.

Figure 6 - Solutions viewpoint snapshot

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




11.4. Benefits for NSW stakeholders

The network architecture provides different stakeholders with multiple viewpoints of the

transport system and its requirements. The various divisions and business units within TfNSW

can each use the network architecture as a framework for business and operational activities.

The Asset Standards Authority Network Standards group can benefit from the framework to

develop standalone topics, that could apply across multiple disciplines and functions for future

network standards.

TfNSW Planning and Programs Division can use the network architecture as a framework to

develop standard network requirements, which can be selected for each investment project or

program. Business requirements can be based on the enterprise goals, capabilities, metrics,

and concept activities provided by the model.

Transport Projects division awards the contract to develop contract design during which system

requirements will be developed by the contractor. The concept activities and functions provide a

functional framework for system requirements.

Sydney Trains can use this framework to ensure that it fulfils the requirements of its service

level agreements. The enterprise goals, capabilities and concept activities provide a functional

framework for developing performance indicators and other tools for monitoring contract

compliance and operational performance.

Customer Experience division could use the enterprise goals, capabilities and concept activities

to build a management framework that assures TfNSW meets its customer needs.

Asset planning, and managing asset information and configuration data benefit from this

framework. The concept activities and functions provide a functional framework on which to

base asset registers, perform asset planning, and develop asset data and asset classification

structures.

Transport Services division can use this framework to ensure that it fulfils the requirements of its

service level agreement with Sydney Trains. The enterprise goals, capabilities and concept

activities provide a functional framework on which to base and monitor compliance with its

contract; that is, to support planning and procurement of the best possible transport services for

NSW.

The architectural framework provides the wider rail industry, particularly AEOs that contract to

TfNSW, with an overall framework to view and understand the complex nature of the transport

network. The functionality across various engineering disciplines described in the model

supports the capabilities and enterprise goals. The heavy rail transport network architecture

model will provide a functional framework for developing detailed design and implementation

plans and managing system requirements.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




12. Network architecture development schedule

Table 1 shows the ASA schedule for developing a viewpoint for a specific discipline.

Table 1 - Sample schedule of viewpoint development

Task Name Approximate Expected duration

Identify Scope of Work 7 days

Scope priority work list 7 days

Manage stakeholders 26 days

SME engagement 1 day

Develop SME positioning/scoping 15 days

Form technical committees 5 days

Form ad hoc technical working groups (TWG) 5 days

Develop/draft/edit Heavy Rail Transport Network Architecture Model 33 days

Divide engineering discipline into manageable portions 1 day

Develop draft 20 days

Request SME review comments 10 days

Incorporate SME comments 1 day

Finish draft 1 day

Prepare for publishing 23 days

Risk review sign off by risk team 5 days

Prepare pre-approval edit and peer review (technical writer) 5 days

Delivery manager and SME final content review and approval 1 day

Submission for CCB approval 5 days

CCB meeting 1 day

CCB approval form signed off 1 day

Final document ready to be published 5 days

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




13. Future direction

The initial focus of the ASA has been to develop a static class diagram that represents a

functional architecture for rolling stock and station precinct buildings for the passenger network.

There are more aspects that have only been peripherally examined as they interact with the

modelled areas. Continuing the development of the existing areas and then expanding the

scope across the whole network will result in a model that provides multiple views of the system

that are consistent across all domains.

The current focus is on the heavy rail mode of passenger transport. Some of the concepts

captured in the current model need to develop into a generic form so that incorporating other

transport modes can be done using the same methodology. Alternatively, the draft heavy rail

model could be included in a larger architectural framework. The ASA plans to use a multi

phase approach that will begin with including other rail modes of freight rail and light rail before

incorporating other transport modes.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017




Appendix A - The railway architecture framework

Figure 7 shows the TRAK metamodel as published by the TRAK steering group, chaired by the

UK Department of Transport. It illustrates the elements used to make the TRAK models. The

TRAK views that contain these elements are defined by TRAK viewpoints.

A full description and details of the TRAK metamodel is available from

trakmetamodel.sourceforge.net.

Sup

erse

ded

by T

MU

AM

060

11 T

I V1.

0 on

29/

03/2

017

http://trakmetamodel.sourceforge.net/



Figure 7 - TRAK metamodel schematic

© State of NSW through Transport for NSW Page 24 of 24 S

uper

sede

d by

T M

U A

M 0

6011

TI V

1.0

on 2

9/03

/201

7

Documents

Development of a Transport Network Architecture … of Defense Architecture Framework ... documenting, communicating, ... Development of a Transport Network Architecture Model