jira.skatelescope.org · web viewdocument no.: revision: date: ska-tel-sko-0000000. c. 2020-08-13....

Name Designation Affiliation Signature

Authored by:

S. LloydNetwork and

IT Security Specialist

SKA Organisation Date:

Owned by:

S. LloydNetwork and

IT Security Specialist

SKA Organisation

Date:

Approved by:

N. ReesHead of

Computing and Software

SKA Organisation

Date:

Released by:

N. ReesHead of

Computing and Software

SKA Organisation

Date:

NETTERRAIN ADMINISTRATION PROCESS

Document Number.......................................................................SKA-TEL-SKO-0000000Document Type..........................................................................................................DTERevision..........................................................................................................................Author..............................................................................................................Sam LloydDate...............................................................................................................2020-08-13Document Classification..........................................................................UNRESTRICTEDStatus....................................................................................................................... Draft

DOCUMENT HISTORYRevision Date Of Issue Engineering Change

NumberComments

A 2020-07-30 - First draft release for internal review

B 2020-08-11 - Incorporates comments from Nick Rees, Richard Oberland, and Pete Lewis. Added a section regarding the

use of JIRA. Added a section regarding NetTerrain standards for Editors.

C 2020-08-13 - Applied changes/comments from reviewers. Added references to all tables and figures. Added Flow Chart.

Re-organised document headings to improve the document structure.

DOCUMENT SOFTWAREPackage Version Filename

Word processor MS Word Word 2016 document.docx

Block diagrams

Other

ORGANISATION DETAILSName SKA Organisation

Registered Address Jodrell Bank Observatory

Lower Withington

Macclesfield

Cheshire

SK11 9DLUnited Kingdom

Registered in England & WalesCompany Number: 07881918

Fax. +44 (0)161 306 9600Website www.skatelescope.org

© Copyright 2020 SKA Organisation.

This work is licensed under a Creative Commons Attribution 4.0 International License.

Document No.:Revision:Date:

Error: Reference source not foundError: Reference source not foundError: Reference source not found

Error: Reference source notfound

Author: Error: Reference source notfound

of 24

http://creativecommons.org/licenses/by/4.0/

TABLE OF CONTENTS1 INTRODUCTION............................................................................................5

1.1 Purpose of the document......................................................................................................51.2 Scope of the document..........................................................................................................5

2 REFERENCES................................................................................................52.1 Applicable documents...........................................................................................................52.2 Reference documents............................................................................................................5

3 NETTERRAIN EDITOR REQUIREMENTS...............................................................6

4 IDENTIFY ACCESS REQUIREMENTS.....................................................................7

5 CHANGE CONTROL PROCESS...........................................................................85.1 Implementing Bulk Imports or Performing Major Changes...................................................95.2 Change Validation and Acceptance Requirements..............................................................105.3 NetTerrain Change Control JIRA Project Requirements.......................................................115.4 NetTerrain Change Control Flow Chart................................................................................13

6 NETTERRAIN BACKUP REQUIREMENTS.............................................................13

APPENDIX 1 - NETTERRAIN STANDARDS FOR EDITORS...........................................156.1 SKA Category for Node, Racks, Devices, and Links...............................................................156.2 Standard Object Attributes..................................................................................................156.3 NetTerrain Hierarchy...........................................................................................................16

6.3.1 Physical Locations........................................................................................................176.3.2 Physical Connectivity...................................................................................................17

6.4 Naming Convention.............................................................................................................176.5 Display and Formatting........................................................................................................17

6.5.1 Page Size......................................................................................................................186.5.2 Default Displayed Attributes........................................................................................186.5.3 Optional Displayed Attributes......................................................................................186.5.4 Location Boundaries with Diagrams.............................................................................186.5.5 Page Templates............................................................................................................196.5.6 SKA Devices in the Catalogue.......................................................................................196.5.7 SKA Connectivity Links.................................................................................................19

6.6 Master Objects, Aliasing, and Instances..............................................................................20





of 24

LIST OF FIGURES

Figure 1: NetTerrain Change Control JIRA Kanban Board....................................................................12Figure 2: NetTerrain Change Control Flow Chart.................................................................................13Figure 3: NetTerrain Naming Convention Shortcode Example............................................................17Figure 4: NetTerrain Location Boundaries Example.............................................................................18Figure 5: NetTerrain Device Colour Coding Example...........................................................................19Figure 6: NetTerrain Connectivity Links Colour Convention................................................................20Figure 7: NetTerrain Vendor Equipment Example...............................................................................20

LIST OF TABLES

Table 1: NetTerrain Access Permissions................................................................................................8Table 2: NetTerrain Change Control JIRA Ticket Fields........................................................................12Table 3: NetTerrain Change Control JIRA Workflow............................................................................12Table 4: NetTerrain Standard Object Attributes..................................................................................16Table 5: NetTerrain Physical Location Hierarchy.................................................................................17

LIST OF ABBREVIATIONS

CDR..............................Critical Design Review

CIN................................Configuration Information Number

ECP...............................Engineering Change Proposal

GMT..............................Greenwich Mean Time

HQ.................................Headquarters

ICD................................Interface Control Document

ID...................................Identification

IT...................................Information Technology

JIRA..............................Work Management Tool (software)

PBS...............................Product Breakdown Structure

SKA...............................Square Kilometre Array

TDT...............................Telescope Delivery Team

WBS..............................Work Breakdown Structure





of 24

1 Introduction

The SKA Observatory network design is currently spread across multiple documents, such as sub-element design documents, interface control documents, multiple diagrams, and spreadsheets. As the network design matures, it will become more difficult to manage and identify gaps and issues using the current documentation set. To help resolve this issue the SKA has purchased NetTerrain, which is a powerful database-driven network design tool that will be used to consolidate the network designs submitted by each sub-element. It will be used to produce a single coherent network design for the entire observatory and will be used as the single source of truth for the SKA Observatory design. It is important to ensure that the information contained within NetTerrain is accurate and up to date, otherwise it will limit the utility of the tool.

1.1 Purpose of the document

This document aims to define how changes are implemented and includes measures to validate the design within the tool to achieve and maintain its accuracy.

1.2 Scope of the document

This document defines the process and requirements for editing the SKA reference design in NetTerrain.

2 References2.1 Applicable documents

The following documents are applicable to the extent stated herein. In the event of conflict between the contents of the applicable documents and this document, the applicable documents shall take precedence.

[AD1] None

2.2 Reference documents

The following documents are referenced in this document. In the event of conflict between the contents of the referenced documents and this document, this document shall take precedence.

[RD1] SKA NetTerrain Admin Guide, Graphical Networks, https://graphicalnetworks.com/[RD2] NetTerrain User Guide, Graphical Networks, https://graphicalnetworks.com/[RD3] SKA-TEL-SKO-0001002 SKA1 Naming and Identification Marking Information

Standard[RD4] SKA-TEL-SKO-0001042 SKA1 Locations Structure





of 24

https://graphicalnetworks.com/

https://graphicalnetworks.com/





of 24

3 NetTerrain Editor RequirementsIt is important to ensure the Element CDR designs are entered first, to establish the baseline design that was used during System CDR. Once this design baseline has been entered, all approved ECP changes can then be implemented. NetTerrain Change Control JIRA tickets must be created for all changes and these changes must be agreed with the relevant design authorities prior to implementation.

The undo functionality within NetTerrain is limited. If a large area of the design is deleted or modified incorrectly, or a bulk import is not successful, the only way to resolve this is to restore the entire system to the previous night’s backup, which would also remove any changes made by other editors since the previous backup. This must be taken into consideration when implementing changes.

Ideally, it is better to have a limited number of users that can edit the SKA design in NetTerrain. This is because:

it is easier to maintain change control with a small number of editors it is easier to maintain consistency throughout the design it reduces the risk of mistakes and the need to roll back to a previous backup a small number of editors can become highly skilled using the tool as they will use it

regularly

Training must be completed before any user is granted editor rights to the live SKA design. Training should consist of official training from Graphical Networks (cost permitting), plus access to official administrative/user guides [RD1, RD2], and/or in house training from existing editors to maintain consistency across the entire SKA design. Prior to being granted editor access to the live SKA design, all potential editors must use the sandbox to hone their newly acquired NetTerrain skills.

All editors must also follow the NetTerrain standards for editors defined in Appendix 1 of this document to ensure consistency throughout the SKA design

A dedicated NetTerrain administrator/controller should be established to manage and monitor all changes to the SKA design in NetTerrain under the guidance of the Network Architect. The NetTerrain administrator/controller will have full administrator rights to the entire SKA design and be responsible for:

The management and implementation of the change control process described in this document.

Liaising with the Configuration Manager and other SKA project stakeholders. Working with the Network Architect, Configuration Manager, and TDT Management to

prioritise the input of the element design baseline and subsequent ECPs into NetTerrain. Implementing design changes. Applying any administrative and cosmetic changes ensuring consistency across the entire

design. Working with the Network Architect to monitor and track changes completed by all editors

to identify mistakes, gaps, and unauthorised changes. Assigning the appropriate access permissions for editors.





of 24

Creating objects in the device catalogue and making them available to all editors.

A minimal number of people should be assigned permission to create all of the required objects and pages within NetTerrain, as this will provide consistency across all objects and pages and ensure the appropriate fields and templates have been created and mandated for each object or page (i.e. PBS numbers, power fields, serial numbers, naming convention [RD3], location structure [RD4], etc). This will also aid in the generation of reports as field names must be consistent across objects.

4 Identify Access RequirementsWhen granting editor access to multiple users, access should be restricted to the specific areas of the SKA design each editor is required to modify, as this reduces the risk of mistakes and unauthorised changes.

Before granting additional users edit access, the following requirements need to be identified:

the pages and sub-pages lower in the hierarchy, they need to edit if the editor can be given a dedicated page(s) that they have full access too (i.e. a cloud in

the main page that drills down to an area they can edit) the pages that need to be modified by multiple editors the SKA design boundaries/responsibilities of the editor

Once the appropriate pages have been identified, edit access can be granted to those pages. All other pages must be set to read only.

If an editor can be provided with a dedicated page(s), the NetTerrain Administrator/Controller must create this page(s) and provide edit access. Again, all other pages they are not required to edit must be restricted to read only for that editor.

Where the same pages must be edited by multiple editors, the NetTerrain administrator/controller must monitor these shared pages to maintain overall control to ensure accuracy or address any issues. Access can be restricted at the object level if required.

Interface boundaries and responsibilities must be defined and agreed for each editor where required. The appropriate design authorities must agree with these boundaries. If applicable, they should line up with the Interface Control Documents (ICDs) and Work Breakdown Structure (WBS).

NetTerrain access permissions are defined in the table below, along with details of who should be assigned each role:

Role Description Assigned to:

AdminHas full administrative access and can create users and groups, access audit trail reports, and change global settings.

NetTerrain Administrator/Controller

and IT Team

Power User Has full edit access and can manage the catalogue.Network Architect and

NetTerrain Administrator/Controller





of 24

Editor Has full permission to make any modifications to the project, but cannot create objects. Editors

UpdaterCan modify object properties but cannot add new objects, move them on a diagram, or delete them from a database.

Not currently used

Annotator Can add or delete their own comments. All other information is accessed in read only mode.

Can be assigned to users as required

Read Only Can view data and diagrams but cannot make any modifications. Most users

Diagram Read Only

Can view data and diagrams, but not the properties or settings of any objects. Not currently used

No AccessUsed to disable user access or restrict access to certain parts of the project. Former editors must not be deleted as their audit history will also be deleted.

Relevant users/access requirements

Table 1: NetTerrain Access Permissions

Each role inherits the access permissions of the roles defined underneath it (apart from No Access). The Admin, Power User, and Editor roles require an editor license. All other roles do not utilise an Editor license.

5 Change Control ProcessAll editors must follow the change control process. Changes must only be made if they have an associated NetTerrain Change Control JIRA Ticket. NetTerrain must also be included as part of the ECP process. The Configuration Manager must be informed when ECPs have been implemented in NetTerrain.

The NetTerrain administrator/controller is responsible for ensuring the Configuration Manager and Network Architect are kept up to date with progress and ensure that the SKA design is constantly monitored to track changes and identify mistakes or gaps.

The process below must be followed when making changes to the live SKA design within NetTerrain:

1. As per the current SKA Change Control process, all design authorities assess and review proposed ECPs.

2. The Configuration Manager raises a NetTerrain Change Control JIRA ticket when an ECP is approved and links the ticket to the original ECP. This NetTerrain Change Control JIRA ticket is assigned to the NetTerrain administrator/controller.

NetTerrain Change Control JIRA tickets must also be created for all other required changes, as the tickets act as a change log. These tickets must also be assigned to the NetTerrain administrator/ controller.





of 24

3. The NetTerrain administrator/controller automatically receives a notification once the NetTerrain Change Control JIRA ticket has been raised.

If multiple changes are received, the NetTerrain administrator/controller prioritises the implementation of each change in agreement with the Network Architect. The Network Architect may need to discuss these changes with the Configuration Manager and TDT Management. The ‘To Do’ column in the JIRA NetTerrain Change Control Kanban board must list the changes in priority order.

4. The NetTerrain administrator/controller, with assistance from the Network Architect, arranges and attends an initial meeting with the relevant design authorities and technical specialists to discuss the changes of each NetTerrain Change Control JIRA Ticket. The detailed changes are agreed by all parties and recorded in detail in the NetTerrain Change Control JIRA ticket.

5. The NetTerrain administrator/controller either makes the changes themselves or seeks assistance from another editor. One editor must take ownership and implement the changes required for an individual NetTerrain Change Control JIRA ticket.

Bulk imports or complex or major changes must be tested using the sandbox prior to being implemented on the live SKA design using the process described in section 5.1 below.

Only one change should be implemented at a time in case one change impacts another change. Where there are instances where changes are completely non-related, they can be implemented simultaneously. This is at the discretion of the NetTerrain administrator/ controller and/or Network Architect.

The NetTerrain editor that has been assigned to make the changes must record all activity and progress in the relevant NetTerrain Change Control JIRA ticket and include the URLs of the affected NetTerrain pages. This progress is monitored by the NetTerrain administrator/controller.

The ‘Change Reference’ attribute on the affected object(s) must be populated with the NetTerrain Change Control JIRA ticket number for traceability.

6. Once a change has been implemented, a formal technical review must be conducted with all affected parties. The aim of this review is to agree the changes that have been implemented in NetTerrain or identify any further modifications or errors.

7. The NetTerrain Change Control JIRA ticket must only be marked as done when the change has been implemented, formally reviewed, and approved.

8. The Configuration Manager must be notified when ECPs have been implemented, reviewed, and approved in NetTerrain. As the Configuration Manager will be listed as the Reporter for each ECP related ticket in JIRA, they should automatically receive a notification of changes made to the ticket, including when the ticket has been marked as done.

9. As NetTerrain is the single source of truth, any affected documents (i.e. ICDs) must be updated to align with the changes in NetTerrain.

If editors perform unauthorised changes or fail to comply with the change control process their edit access will be revoked.





of 24

5.1 Implementing Bulk Imports or Performing Major Changes

Bulk imports should be avoided unless absolutely necessary, as they can have a significant impact to the overall SKA design, and potentially cause issues that may take a while to identify or remain unnoticed. Before performing bulk imports or making major or complex changes to the live SKA design, they must first be tested in the sandbox to ensure the change does not negatively impact the rest of the SKA design information.

A major change is defined as a large change that significantly impacts the overall SKA design. A bulk import is defined as any import from a spreadsheet, regardless of the amount of information contained within the spreadsheet. The risk is the spreadsheet itself.

The process below must be followed in addition to the change control process above for bulk imports or major changes:

1. Ensure a copy of the current live SKA design has been restored to the sandbox.

2. Test the bulk import or major change in the sandbox and verify that it doesn’t break any other areas of the design.

3. If the bulk import fails, repeat the previous two steps until the import is successful.

4. Arrange a meeting with the affected technical design authorities, technical specialists, and system engineers to review the bulk import or major changes in the sandbox and ensure they are happy with the changes.

5. If the previous review was successful, freeze all other changes to the live SKA design, ensure the live SKA design has been backed up, and perform the bulk import or major change. The import log file must be checked and stored for future reference.

IMPORTANT: if multiple changes have been made to the live SKA design since step 1 was completed repeat steps 1 and 2 prior to importing it into the live SKA design. Alternatively, freeze all changes to the live SKA design.

6. Test the bulk import or major change on the live SKA design and verify that it hasn’t broken any other areas of the design.

7. Continue following the change control process from step 5 onwards.

All editors must be notified a day in advance before any bulk import or major changes are due to be implemented, to ensure that no other changes are implemented until the bulk import or major change has been completed and tested. This reduces the risk of other editors’ work being deleted if the system must be restored to the previous days backup.

5.2 Change Validation and Acceptance Requirements

Once a NetTerrain Change Control JIRA ticket has been raised, either due to an approved ECP or other change, the NetTerrain administrator/controller must arrange a meeting with the affected parties, such as technical specialists and systems engineers. The goal of this meeting is to define and agree the detailed design changes that will be implemented in NetTerrain relating to the change. All actions and agreed detailed design changes must be recorded in the NetTerrain Change Control JIRA





of 24

ticket during the meeting. This will allow the NetTerrain Change Control JIRA ticket to be assigned to another editor, if required, and provide enough detail for them to implement the change.

Once a change has been implemented in NetTerrain, a formal technical review must take place. Ideally, implemented changes should be reviewed on an individual basis, although they can be grouped if appropriate. This technical review should include the people who are affected by the change, such as:

Project Managers System Engineers Technical Specialists Domain Specialists Operations Team Representative Science Team Representative RAMs and Logistics Representative Configuration Management

The NetTerrain administrator/controller will provide a detailed overview of the changes generated by the change to all attendees. All meeting participants will have the opportunity to review and comment on the changes. The goal of this meeting is to review and approve the detailed changes. If the changes are not agreed and further actions are generated from this review meeting, they must be recorded in the NetTerrain Change Control JIRA ticket. A subsequent meeting must be held to review and approve the additional changes.

These meetings should break down the silo’s currently in place by ensuring all affected parties work together to agree a solution. This solution is then visible to all.

5.3 NetTerrain Change Control JIRA Project Requirements

A NetTerrain Change Control JIRA project has been created to record all changes that need to be implemented to the SKA design in NetTerrain. A ticket must be created within this project for each NetTerrain change. The NetTerrain Change Control JIRA ticket fields are described below:

Field Title Field Description

Issue Type This is always set to Change.

Summary Title of change.

Description Brief description of the change.

Assignee Person the ticket has been assigned to. Should be the NetTerrain administrator/controller in the first instance.

Priority Set to either Low, Medium, High, or Highest. There must only be one ticket ranked as Highest at any one time.

Labels Labels can be assigned if required.





of 24

Linked Issues This can be used to link to an ECP JIRA ticket, or specific SAFe feature or story.

Attachment Can add attachments if required.

Action AgreedContains the detailed changes agreed during the initial review meeting. Must also contain the URLs of the affected NetTerrain pages.

Blocked Reason If a ticket is blocked enter the reason in this field.

Conclusion Contains the meeting notes from the final review meeting.

Reviewer AcceptanceStates whether the changes have been accepted, rejected, or accepted with reservation. If a change is rejected, further work must be completed and reviewed.

Comments Must be used to record progress and provide status updates.

Table 2: NetTerrain Change Control JIRA Ticket Fields

The NetTerrain Change Control JIRA project workflow is described in order below:

Ticket Status Status Definition

Default status when ticket is created.

The ticket is ready to be actioned in priority order.

Initial meeting to take place to agree all of the required changes with the relevant technical specialists. All required changes are added to the ‘Actions Agreed’ field in the JIRA ticket.The changes are being implemented. All progress is documented in the JIRA ticket on a regular basis in the ‘Comments’ activity area.Progress cannot be continued due to external dependencies or an issue has been identified. A reason must be entered in the ‘Blocked Reason’ field in the JIRA ticket.Final technical review meeting to take place to review and approve the changes. The outcome of the technical review meeting must be recorded in the ‘Conclusion’ field in the JIRA ticket.All changes have been implemented and have been agreed/ approved during the final technical review.A change is no longer required. This must be agreed with the Configuration Manager, TDT Management, or Network Architect as appropriate.

Table 3: NetTerrain Change Control JIRA Workflow

The NetTerrain Change Control JIRA Kanban board layout is shown below:





of 24

Figure 1: NetTerrain Change Control JIRA Kanban Board

5.4 NetTerrain Change Control Flow Chart

A flow chart describing the high level NetTerrain Change Control process is below. This flow chart also associates the change control process with the NetTerrain Change Control JIRA project workflow.





of 24

Figure 2: NetTerrain Change Control Flow Chart

6 NetTerrain Backup RequirementsNetTerrain is backed up on a regular basis by Graphical Networks. The current backup schedule is:

Daily overnight backups which are kept for 30 days The daily backup taken on the last day of the month is retained for 12 months

Graphical Networks can perform ad hoc backups on request. Ad hoc backups can be conducted to record SKA design baselines.

Graphical Networks can restore previous backups to the sandbox on request. This is useful for testing bulk imports or major changes to the current SKA design configuration, reviewing previous baselines, and user training.Graphical Networks are also able to create multiple instances of NetTerrain for us to use (in addition to production and the sandbox).





of 24

Graphical Networks are based in the USA (GMT – 4 hrs), so time zone differences need to be taken into consideration when making ad hoc backup and restore requests.





of 24

APPENDIX 1 - NetTerrain Standards for EditorsThe following sections describe how information must be entered into NetTerrain to ensure consistency across the entire design. The NetTerrain administrator/controller must ensure that these standards are being followed.

6.1 SKA Category for Node, Racks, Devices, and Links

All SKA object classes i.e. Nodes, Racks, Devices, and Link types entered into the database must be assigned the “SKA” category. This makes it easier to find SKA products and information, and to create new or cloned objects.

6.2 Standard Object Attributes

The attributes that must be included when new SKA category objects are created are described in the table below:

Field NameApplicable

Object Type

Description Example Value

Name All Objects Name of the object in the database. CAM001

Type All Objects Type of object e.g. a generic 42U rack, or Cloud node SKA 1U

ID All Objects Object unique ID assigned by NetTerrain 24000000003771

DescriptionAll SKA

category Objects

Description of the object. CPF Data Centre (DC)

CommentsAll SKA

category Objects

Allows reviewer to add text comments Typical Power value should be 545W

Shortcode

All SKA category Objects except Links

Short code for object as defined in the SKA Naming Convention Document (SKA-TEL-xxx). Used by the Hierarchy ID field

MUX001

Hierarchy ID

All SKA category Objects except Links

Auto generated value based on the parent tree Shortcode values. Useful to display the objects hierarchical position in the database

ZA-LOS-CPF001-DC-G2-MUX001

ViewAll SKA

category Objects

Used with Override function to change the appearance of an object in the diagram dependent on its value

CSP-SDP

PBS CINAll SKA

category Devices

SKA Product Breakdown Structure (PBS) Configuration Identification Number (CIN)

346-060000





of 24

PBS NameAll SKA

category Devices

SKA Product Breakdown Structure (PBS) Name Muxponder

Peak Power [W] All Devices Peak (Maximum) electrical power

consumption of a device in Watts 903

Typical Power

All SKA category Devices

Typical electrical power consumption of a device in Watts 722

HeightAll SKA

category Devices

Height of a device in rack mountable units (U) 6U

Change Reference

All SKA category Objects

Hyperlink display text and URL to JIRA TIMS tickets/Change Proposal site

[TIMS-xx](https://jira.skatelescope.org/

issues/?filter=-4)Change Status All SKA

category Objects

4 possible change status values, each providing a coloured override marker on the displayed object.

“” – no marker, “New” – Red triangle, “Completed, Not Approved” – Amber

triangle, “Completed, Approved, Closed” –

Green triangle

Physical Layer

Protocol

“SKA Logical”

Link

Physical layer protocol running over the logical connection. 12 possible values, each providing a different coloured line colour override on the displayed link.

100GE

Service“SKA

Logical” Link

Service running over the logical connection. 14 possible values, each providing a different coloured line colour override on the displayed link.

Visibility

Instances“SKA

Logical” Link

Number of actual instances of the single link shown 8

Interface ID

“SKA Logical”

Link

SKA Interface Control Document (ICD) interface ID for the link that forms the interface between to objects

I.S1M.DDBH_NSDN.001

Document Reference All SKA

category Objects

Hyperlink display text and URL to document reference site

[SKA-TEL-LFAA-0500035](https://ska-

aw.bentley.com/SKAProd/Framework/

Object.aspx?o=15033&t=3&i=view)

To“SKA

Logical” Link

Name of object connected to one end of the link DTN001

From“SKA

Logical” Link

Name of object connected from one end of the link ASW001

Table 4: NetTerrain Standard Object Attributes





of 24

6.3 NetTerrain Hierarchy

The NetTerrain database is currently split into two distinct areas at the top level which represent the SKA design. One area focuses on the physical locations (building locations, room layouts, rack layouts, rack contents) and the other describes the physical connectivity (how devices are connected to each other). The hierarchy is based on the location structure [RD4] and naming convention [RD3] standards.

6.3.1 Physical Locations

The physical locations hierarchy has the following structure.

Hierarchy Tier Object Class and Type Example Name/DescriptionTier 1 (Top Level) Tier 2 Node: World SKA Physical Locations Tier 3 Node: Country South Africa (ZA) Physical Locations Tier 4 Node: Zone Losberg (LOS) Tier 5 Node: Building (SKA) CPF at Losberg Tier 6 Node: Room CPF Data Centre (DC) Tier 7 Rack: SKA Generic 42U G2 Tier 8 Device: SKA 6U Muxponder Tier 9 Card: Tier 10 Port:

Table 5: NetTerrain Physical Location Hierarchy

6.3.2 Physical Connectivity

Cloud type nodes are used to contain physical connectivity diagrams in the database. The user can double click on the cloud to drill down to the next detailed level of the diagram. Cloud containers must be used to simplify a network diagram to avoid large page sizes and small objects and font sizes. There are no restrictions on the use of Cloud containers. They may represent sections of a network, or types of equipment, or even user specific views of the database information.

6.4 Naming Convention

The Shortcode field within an SKA object must be populated with a value as defined in the Naming and Identification Marking Information Standard [RD3]. The Hierarchy ID field will display a value that represents a concatenation of Shortcodes belonging to the objects parent diagrams. In this way, the position of the object in the database hierarchy can be displayed. This may be useful, for example, to determine a devices building, room, and rack location.

Muxponder example … ZA-LOS-CPF001-DC-G2-MUX001





of 24

Figure 3: NetTerrain Naming Convention Shortcode Example

6.5 Display and Formatting

The following page sizes, display attributes, location boundaries, and templates must be used across all aspects of the SKA design.

6.5.1 Page Size

The default page size is US Letter. A3 and A2 can be used but is not recommended due to the browser screen size and visibility with zooming in too far. Variations in page sizes are at the discretion of the NetTerrain administrator/controller.

6.5.2 Default Displayed Attributes

The PBS Name and CIN must be displayed for all objects.

6.5.3 Optional Displayed Attributes

Optional attributes can also be displayed in pages if there is space to do so and the information is relevant. Optional attributes can include the number of instances of links, interface ID numbers, and free text.

6.5.4 Location Boundaries with Diagrams

Network location boundaries must be displayed as grey dashed line boxes. This makes it easier to identify equipment located within a particular location (inside the grey box) and identifies what external equipment they connect to (outside the grey box). Equipment shown outside the local location boundary must have their location labelled with blue italic text, as shown below.





of 24

Figure 4: NetTerrain Location Boundaries Example

6.5.5 Page Templates

Page templates must contain the SKA logo in the top left hand corner and the name or description field value the diagram field on the outside of the page margins. This provides the maximum space available within the drawing area whilst still identifying the location.

6.5.6 SKA Devices in the Catalogue

Until a vendor is chosen for each device, generic SKA devices have been created to represent the products as shown in the Critical Design Review (CDR) baseline documentation across all elements. As each rack mountable product has an associated height, generic SKA device types have been created for the various height devices across all designs. For example, SKA 1U, SKA 2U, and SKA 6U. The colour of the device is chosen by selecting the appropriate element option in the View field, for example NSDN is shown in blue and the timescale sub-system is shown in pink. Each sub element should be assigned a specific colour to make it easier to identify sub element devices.





of 24

Figure 5: NetTerrain Device Colour Coding Example

6.5.7 SKA Connectivity Links

SKA connectivity links are used to connect all objects in the SKA Physical Connectivity network diagrams. The appearance of the line can be changed to show the Physical Layer Protocol or Service running across the connection by changing the View field value. See table below:-





of 24

Figure 6: NetTerrain Connectivity Links Colour Convention

Real devices used only when vendor chosen and network configuration available. See UK HQ examples with physical connectivity down to the port level.

Figure 7: NetTerrain Vendor Equipment Example

6.6 Master Objects, Aliasing, and Instances

For consistency and where possible, the physical location network representation of the network must be drawn first, before the physical connectivity one. The first representation of the network in NetTerrain is known as the master node. Alias copies can then be made from the master node.

It is recommended that aliases are used when there are multiple instances of an object with the same design configuration, as this allows changes to be made that can be synchronised across all occurrences in the database. However, these aliases will need to be changed into unique objects





of 24

when variations occur across locations. For example, when switches are deployed at difference locations with different IP addresses or port connectivity.





of 24