HANSA_Configuration Management and Document Control Process

HELLENIC AIR NAVIGATION SUPERVISORY AUTHORITY

Configuration Management And Document Control Process

Edition Number : 2.0

Edition Date : 24 April 2012

Status : Approved

Configuration Management And Document Control Process 2

DOCUMENT IDENTIFICATION SHEET

DOCUMENT DESCRIPTION

Document Title

HANSA


PROGRAMME REFERENCE INDEX: EDITION: 2.0

EDITION DATE: 24 April 2012

Abstract

The HANSA requires a Configuration Management System to be put in place that efficiently controls the

documentation produced or received by the HANSA as part of its functioning.

This process defines the steps to be followed by personnel of the National Supervisory Authority when

reviewing configuration items (CIs), either produced by the HANSA or received from a third party (for example

as part of an application for certification).

Keywords

CONTACT PERSON: M.Panagiotopoulos TEL: 210 8984 101

UNIT:HANSA SECTION C

Planning, Legal support

& International Relations

DOCUMENT STATUS AND TYPE

STATUS CLASSIFICATION

Working Draft � General Public ⌧

Draft � EATMP �

Proposed Issue � Restricted �

Released Issue ⌧

ELECTRONIC BACKUP

INTERNAL REFERENCE NAME:

HOST SYSTEM MEDIA SOFTWARE

Type: MS WORD 2007

Media Identification:


DOCUMENT APPROVAL

The following table identifies the persons who have developed the document

as well as all authorities who have successively approved the present issue of

this document.

AUTHORITY NAME AND SIGNATURE DATE

HANSA DIRECTOR

Michael Panagiotopoulos

24 April 2012

AUTHOR OF THE

PROCESS

Head of the

Certification and

Service Provision

oversight for Air

Traffic, Meteorology

& Aeronautical

Information Section

Evangelos Malikoutis

24 April 2012


TABLE OF CONTENTS

1 Introduction 5

1.1 Purpose ....................................................................................................................................................5

1.2 Intended Audience...................................................................................................................................5

1.3 Document Structure.................................................................................................................................5

2 Scope 5

3 Context 6

3.1 Mission Statement ...................................................................................................................................6

3.2 Overall View .............................................................................................................................................6

3.3 Relation to other processes .....................................................................................................................6

3.4 Terminology .............................................................................................................................................7

3.5 Roles.........................................................................................................................................................8

4 Configuration management PROCESSES 8

4.1 Triggers.....................................................................................................................................................8

The need to develop or formally review a configuration item produced within the HANSA or sent to the

HANSA by a third party........................................................................................................................................8

4.2 Activities-Steps.........................................................................................................................................8

4.2.1 Responsibilities.................................................................................................................................8

4.2.2 Configuration Management – Processes and Practices .................................................................10

4.2.3 Configuration Management – Government Requirements ...........................................................12

4.2.4 Document Review Process .............................................................................................................12

4.2.5 Review – Internal HANSA documentation .....................................................................................12

4.2.6 Review – Third party documentation.............................................................................................13

4.2.7 Document Review Form.................................................................................................................14

4.2.8 Identification, versioning and labelling ..........................................................................................15

4.2.9 Exemptions.....................................................................................................................................19

4.2.10 Implementation..........................................................................................................................19

REFERENCE DOCUMENTS 20

GLOSSARY 22

CHANGE RECORD 23

ANNEX 1 24


1 Introduction

1.1 Purpose

The purpose of this process is to define the steps to be followed when performing a formal review of

a configuration item produced within the HANSA or sent to the HANSA by a third party. The process

shall ensure that the HANSA documents in a systematic and consistent manner and establishes a

consistent trace of how review comments have been resolved.

This process shall apply to any configuration item subject to formal HANSA review.

The HANSA quality manager allocated in the SQS Oversight Section is responsible for auditing the

application of this process. Furthermore, the HANSA quality manager shall monitor the need for

updating the process in order to avoid recurring problems, to correct misleading or inaccurate

descriptions etc.

The Head of the Planning, Legal Support and International Relations section is responsible for the

process being introduced into the HANSA organization and making sure it is applied throughout the

different management levels of the HANSA.

1.2 Intended Audience

The audience of this document is potentially the HANSA and the HCAA ANSP staff.

1.3 Document Structure

This document is structured as follows:

1. Introduction;

2. Scope;

3. Context;

4. Configuration Management Process

Reference Docs;

Glossary;

Change record;

Annexes

2 Scope

The proper functioning of the HANSA is based on a well-established set of regulations and processes.

As the impact of such regulations on external organisations can have paramount importance for their

continued existence, the HANSA is obliged to implement a strict configuration management system

which ensures that the necessary approval is obtained prior to the release of any documentation and

that subsequent changes are controlled with equal care.

The HANSA shall be able to produce in all cases the latest, approved version of any official document,

together with a trace of the revision history.


For this purpose the HANSA has established a set of configuration management processes and

practices – the configuration management system, which shall be applied for the production, release

and control of documentation related to its work, internal or external.

This document, among others, includes a general introduction to the configuration management

system implemented in the HANSA and gives applicable references to associated processes and

instructions.

3 Context

3.1 Mission Statement

This process defines the steps to be followed when performing a formal review of a

configuration item produced within the HANSA or sent to the HANSA by a third

party.

3.2 Overall View

The Configuration Management System (CMS) includes three main components:

1. Configuration management processes and practices describing the day-to-day practical

aspects of configuration management within the HANSA. This includes for example processes

related to:

a. Identification, versioning and labelling of documentation;

b. Documentation archiving and retrieval;

c. Classification of documentation – handling of commercially sensitive information;

d. Document Review.

2. Configuration Management tools, specifying which manual or automated tools are to be

used when producing configuration items to be controlled. This includes for example tools

related to:

a. Establishing a text document, spreadsheets, sending and received mails or other tools for

office automation;

b. Control of data for licenses, certificates, etc.;

c. Control of archives, including documents in hard copy or soft copy;

3. Processes and practices to be applied by the HANSA.

Tools which have been authorised for use within the HANSA are defined in the following

sub-process: Configuration Management Tools and their Use.

This document also describes which tools are to be used for each type of work.

3.3 Relation to other processes

All processes.


3.4 Terminology

ANS

ANSP

ASM

ATC

ATFM

ATM

Air Navigation Services means air traffic services (ATS), communication, navigation & surveillance services (CNS), aeronautical information services (AIS) and meteorological services for air navigation (MET)

Air Navigation Service Provider. means any public or private entity providing air navigation services for general air traffic

AirSpace Management. A planning function with the primary objective of maximising the utilisation of available airspace by dynamic time-sharing and, at times, the segregation of airspace among various categories of airspace users on the basis of short-term needs

Air Traffic Control (ATC) service means Area Control service (ACC), Approach control service (APP) or aerodrome control service (TWR)

Air Traffic Flow Management. A function established with the objective of contributing to a safe, orderly and expeditious flow of air traffic by ensuring that ATC capacity is utilised to the maximum extent possible, and that the traffic volume is compatible with the capacities declared by the appropriate air traffic service providers

Air Traffic Management. The aggregation of the airborne and ground-based functions (Air Traffic Services (ATS), AirSpace Management (ASM) function and Air Traffic Flow Management (ATFM) function) required to ensure the safe and efficient movement of aircraft during all phases of operations

ATM system The part of the ANS/ATM system composed of a ground based ATM component and an airborne ATM component. The ATM system includes human, technical systems and processes, ATS, ASM & ATFM

ATS Air Traffic Services. A generic term meaning variously, Air Traffic Control (ATC)

service, Flight Information Service (FIS), Air Traffic Advisory Service, Alerting service

Constituents A document issued by a Member State in any form complying with national law,

which confirms that an ATM service provider meets the requirements for providing

a specific service.

Corrective action Action to eliminate –or, at least, mitigate- the cause of a detected non-conformity or

other undesirable situation.

CI Configuration Item

CM Configuration Manager

CMS Configuration Management System

Designation The process by which States designate ANSPs to provide Air Traffic Services within

specific airspace blocks in respect of the airspace under their responsibility.

NSA

National Supervisory Authority. A body nominated or established by States,

independent of service providers -at least at functional level= and according to the

existing regulatory framework, certifying the providers and supervising the

implementation of requirements applicable to the provision of ATM/ANS.


Process A set of interrelated or interacting activities which transforms inputs into outputs.

Regulation The adoption, enactment and implementation of rules for the achievement of stated

objectives by those to whom the regulatory process applies.

System A combination of technical systems, processes and human resources organised to

perform a function.

Technical system The aggregation of airborne and ground-based constituents, as well as space-based

equipment that provides support for ATM services for all phases of flight.

Verification Confirmation through the provision of objective evidence that specified

requirements have been fulfilled.

3.5 Roles

Role Description Allocated Staff

Responsible for the process being

introduced into the HANSA

Responsible for the process being

introduced into the HANSA

organization and making sure it is

applied throughout the different

management levels of the HANSA.

The Head of the

Planning, Legal

Support and

International

Relations section

Responsible for auditing the

application of this process .

The HANSA

quality manager

allocated in the

SQS Section

4 Configuration management PROCESSES

4.1 Triggers

The need to develop or formally review a configuration item produced within the HANSA or

sent to the HANSA by a third party.

4.2 Activities-Steps

4.2.1 Responsibilities

The configuration management system is established, maintained and supervised by the Planning,

Legal Support and International Relations section under the responsibility of the Head of this unit.

The Head of this section will act as the project Configuration Manager and has the overall

responsibility for the configuration management performed within the HANSA, including:

• Planning the implementation of an efficient Configuration Management System, including

processes and practices to be applied by the HANSA and the manual or automated tools to be

used.


• Monitoring the application of the configuration management system and its processes and

practices within the HANSA, identifying the need for additional processes or practices or

changes/adjustments to existing processes.

• Monitoring the efficiency of the operations manual or automated tools used.

• Plan and prepare the transfer of authority for configuration items from the HANSA to the

relevant authorities (e.g. Ministry) in such cases where the documentation was produced by

the HANSA but issued by another authority.

• Planning for the necessary coordination of processes and practices between HANSA and

external entities (for example in respect to EC Declaration of Verification of Systems).

• The Head of the section has the authority to direct the efforts of the configuration

management organisation to such activities deemed necessary for fulfilling the configuration

management requirements. Also, the Head of the section has the authority to perform the

necessary audits and inspections to verify the application of configuration management within

the HANSA and issue such directives or instructions necessary to ensure the proper

management of any configuration item.

• When using his authority, the Head of the administrative section shall ensure the necessary

coordination with the Head of the HANSA and the Heads of other sections.

• The responsibility for the day-to-day configuration control will be placed upon the secretariat of

the administrative section. These responsibilities include:

• Only allowing documents that fulfil the configuration management requirements to be

introduced into the configuration management system and/or released from such.

• Maintaining management of the central and/or local libraries (hard or soft), including release of

documentation when revisions are to be made by the different sections.

• Maintaining systems for security related to sensitive documents (including personal details,

commercially sensitive information etc.) and which access to such documentation is restricted to

authorised personnel only.

• A system is put in place to train new personnel in the configuration management system and to

provide refresher training of/information to existing staff in case of changes to existing processes

and practices.

• Further responsibilities are defined in the specific processes and practices, but will include

normal secretarial functions such as:

• Archiving

• Copying

• Filing

• Security

• Destruction

• Release notices etc.

• The Head of each section is responsible for ensuring that personnel in their section are

applying the configuration management system and respecting processes and practices that

are to be followed.


4.2.2 Configuration Management – Processes and Practices

Processes and practices within configuration management consist of a set of rules to be followed

when producing and maintaining documentation for the functions in the HANSA. These processes

and practices can be divided into two main groups:

• Processes, which are applicable to all personnel working in the HANSA. These processes define

documents identified labelling, versioning, specific layout of the documents review and approval

processes, security label of documents, etc.

• Processes, which are applicable to personnel performing specific tasks. These processes define

documents archiving, retrieval from archives for modifications etc.

The main aspects of these processes are described below.

The HANSA will manage many different types of configuration “items” and there is an initial

need for defining which of these items are subject to formal configuration management.

The process lists, which items are to be placed under configuration control. In general, this covers:

• Formal documentation issued by the HANSA as part of the function and to be used by or provide

information to external entities. This covers documentation such as regulations, directives,

formal letters, audit plans, audit reports, annual reports, minutes of meetings, certificates,

external queries and some of the HANSA processes. Special attention shall be put on Safety

Oversight Records as defined in the process.

• Internal documentation issued by the HANSA as part of the function but for internal purposes

only. This covers documentation such as memorandums, formal notices or briefs from the

management, minutes of internal meetings, job descriptions, business plans etc.

• Electronic mails, including attachments, in so far as these items are not already covered by 1 or 2

above. While most mails will not be subject to configuration control, mails which express the

views of the HANSA on any subject matter shall be subject to configuration control (also approval

and classification).

• Software, which is used within the HANSA e.g. various software applications for office

automation, Windows, software for managing licenses and certificates, etc. The management will

mainly ensure that all authorised software is registered together with the license document,

documentation packs, configuration files (set-up files as applicable) etc.

• Hardware used within the HANSA to support different types of software provided to different

posts in the HANSA and for administrative purposes. The configuration management will mainly

ensure that any piece of hardware is registered as official HANSA property together with

equipment numbers, part numbers, etc.

Excluded from the configuration management system are working papers, notes and sketches

produced for use within the HANSA only and without substance for the functioning of the HANSA.

This also includes internal and external mail communication unless it includes official views, opinions,

agreements or other aspects binding for the HANSA.

In case of uncertainty regarding whether a particular configuration item shall be controlled, the Head

of the administrative section should be consulted.

This process defines precisely how different types of documentation shall be designed in respect to

layout etc. This mainly covers documentation, which is intended for external use (such as regulations,

letters, minutes of meetings, plans and reports etc.) or which is part of the process to be used by the

HANSA and which therefore has a formal status.


The layouts may be extended with an explanation about which sections a document should include

and which information should be included in the different sections (skeleton documents).

When using office automation tools, the configuration management function will provide the

necessary layouts and skeletons in soft copy for use in the different authorised tools.

A key feature in any configuration management system is the correct and consistent identification,

labelling and versioning of documentation, so documents can be fully recognised and the official

status of the document can be seen from the document itself (draft or formally issued document)

The identification requires any document, and any page of a document, to clearly state what the

particular document covers e.g. a certain regulation, a certain process etc. The process includes a

specification of the different types of documentation that can be produced. The identification also

includes rules for the naming of soft copies in order to identify the document and its constituents

(such as embedded figures, lists etc.). The labelling specifies how the information defining the

document shall be presented - partly in the document, partly on any soft copy media - for formal

distribution. This also covers how document classification shall be presented in the document and

likewise. Versioning includes requirements for the identification of the document; a draft or issue

and the sequence of the document in its history. For example versioning works with a format like

xx.yy, where xx defines the issue, and yy defines the draft. Version 02.00 is thus the second formal

issue of the document, while 02.04 is the fourth draft of an update of the document based on issue

02.

This process is the core of a configuration management system and has to be strictly applied

throughout the organisation. Use of the standard layouts and skeletons should ensure that this

process is applied.

The HANSA could obtain information from external sources which includes personal or company

confidential information and which may be misused if made available to unauthorised personnel or

external entities. For this purpose, a process has been defined for regulating how documentation

shall be classified.

The classification scheme covers the following groups in general:

• Public, which means that the document is intended for access from the general public and may

even have been produced with the purpose of general distribution for a wider external audience.

• Unclassified, which means that there is no restriction on the access to the document from within

the HANSA, but does not mean that the document is for the general public. It will typically be an

internal HANSA document to be used by HANSA personnel for conducting their work.

• Commercially sensitive, this means that the document includes sensitive information about a

commercial enterprise (for example a service provider) and the distribution of the document

must be limited. Access to such document is restricted to a certain group of people, even within

the HANSA, on a need to know basis.

• Personal sensitive, which means that the document includes sensitive information about an

individual person (for example an air traffic controller) and the distribution of the document shall

be limited. Access to such a document is restricted to a very limited group of people, even within

the HANSA, and on a need to know basis.

Further details and the exact classification scheme are included in the process.


Whenever a formal review of a document has to be performed by the HANSA staff the review has

to be documented in a formal manner, in a way, which provides not only the original review

comment, but also provides the trace of how a review comment has been resolved.

4.2.3 Configuration Management – Government Requirements

As a public administration operating under the laws of the Republic of Greece, the HANSA will have

to comply with government requirements in respect to official documentation.

The requirements have been taken into consideration when designing the HANSA configuration

management processes and practices and do not require special attention from personnel (other

than the personnel responsible for keeping the configuration management system updated to reflect

changes in such government requirements).

4.2.4 Document Review Process

Scope

This part describes in detail how configuration items shall be formally reviewed, and how traces are

established to document how review comments have been resolved.

Purpose

The process of formal review can be initiated in several ways:

• The configuration item (regulation, process, etc.) can have been produced within the HANSA

and a review has to be performed before it becomes final and ready for approval and formal

review.

• The configuration item (notification of change, including attached documentation, application

for certification, including attached documentation) can have been produced by a third party

and sent to the NSA with the purpose of having HANSA evaluation, assessment and/or

conclusion.

• Whenever a configuration item is received from a third party, it will be entered into the

configuration management system, and sent to the section responsible for the subject matter.

• Whenever a configuration item is produced within the HANSA and is ready for formal review, it

will be sent to the configuration manager for registration. In parallel, the document will be

sent by the section responsible for the subject matter to those other sections or staff member

who shall review the configuration item, with a request to perform a formal review.

• The underlying standard for the production of documents, drawings etc. within the HANSA

shall be as defined in ….., which aims to ensure that the identification, versioning and labelling

of the documents are performed.

4.2.5 Review – Internal HANSA documentation

Whenever a HANSA document is to be subject for formal review, the following steps will

apply:

• The Author (for HANSA documentation) forwards the configuration item to the Configuration

Management function together with a Document Review Form (with the appropriate fields

filled in), noting who shall review the configuration item and the deadline for provision of

comments.

• The Author includes a description of the focus of the review, e.g. a review instructions, which

also shall guide the reviewers in respect to important matters to be considered, other relevant

documentation that should be considered when reviewing the document, etc.


• The Configuration Manager distributes the draft document to assigned reviewers within

HANSA together with the Document Review Form, noting the deadline for provision of

comments to the draft document.

• Each reviewer fills in a Document Review Form and returns the Document Review Form to the

Configuration Management function before the deadline. Only written comments included in

the Document Review Form will be taken into consideration.

• The Configuration Management function sends all Document Review Forms (one from each

reviewer) to the Author for commenting. Prior to sending the Document Review Forms to the

HANSA the section may coordinate comments internally, remove duplicate comments, clarify

comments, which are ambiguous, inconsistent, incorrect, etc. so that only relevant comments

are passed on to the Author.

• The Author will combine the Document Review Forms into one document including all

comments raised against a draft document.

• The Author will - comment by comment - reply in the Document Review Form noting whether

the comment is accepted or rejected (and why). In parallel an updated draft document will be

produced to show corrections made. In the event that a comment cannot be accepted, the

Author will contact the reviewer and discuss the comment and the reason for its rejection to

reach a preliminary agreement.

• The fill-in Document Review Form and the updated draft document will be sent to the

Configuration Management function, who will distribute the documents to the reviewers. Each

reviewer will check the Authors reply and the associated updates in the document, and

approve or reject the change. In case of rejection it shall be noted why a proposed change is

rejected. It may be decided to perform the check on a joint meeting to speed up the process.

Once the check has been completed, the Document Review Form will be sent via the

Configuration Management function to the Author.

• The Author shall address any change, which has been rejected and adjust the change in the

draft document accordingly. This process will continue until the Author has satisfactorily

addressed all comments.

• Once the changes associated with all the comments have been approved, then the document

is ready for approval. The Configuration Management function will send the document to the

approving manager for formal approval (signature).

• Once the approval is returned to the Configuration Management function, the Configuration

Management system will be updated, noting for formal approval of the document.

4.2.6 Review – Third party documentation

Whenever the subject to be reviewed has been prepared by a third party (e.g. a service

provider), the following steps will apply:

• The Configuration Management function will, upon receipt of the document, register the

document in the Configuration Management system, and send the document to the section

responsible for the subject matter.

• The section responsible will prepare a document review form and provide this to the reviewers

together with the document.

• The section will combine the Document Review Forms into one document including all

comments raised against a draft document. The section shall coordinate comments internally,

remove duplicate comments, clarify comments which are ambiguous, inconsistent and

incorrect etc., so only relevant comments are retained.

• The fill-in Document Review Form will be sent to the Configuration Management function,

which includes the document in the Configuration Management system as the formal HANSA

response to the particular document.


The Document Review Form may be sent to the third party for commenting or may be used internally

within the HANSA to keep trace of the HANSA view on the document.

4.2.7 Document Review Form

The Document Review Form is presented in Annex 2. The Form consists of three main parts: Revision

History, Document Information and Review Comments.

Revision History

The Revision History shall be filled in / updated each time the document is updated. The fields shall

be used as follows:

• The column [Rev] states revision no. of the DRF in any state of the review process, e.g. “00.01”.

• The column [Review date] states date for which the work of the review process was done, e.g.

“1995-06-28”.

• The column [Reviewer] contains a concatenation of company’s initials, reviewer’s name and in

brackets reviewer’s initials, e.g. “HCAA/REV”.

• The column [Information] contains information for work performed for this revision of the

DRF, e.g. “First draft”, “more DRF items added” or “Response given”.

• The column [Filename] contains filename of the DRF at the appropriate revision of the DRF,

e.g. “DRF19016.DOC”.

Document Information

The Document Information part will normally have been filled in by the party who forwards a

document for review. The fields shall be used as follows:

• The field [Document title] contains the title of the document being under review, e.g. “Project

Management Plan”.

• If only a part of the document is under review, the field [Volume/Chapter/pages] contains

which volume, chapter or pages are being under review, e.g. ”Volume 1, Chapter 3.2“, “pages

11-16, 18-44” or “n/a”.

• The field [Document no.] contains document number or identifier, e.g. “PMP SRFCYP (113)”.

• The field [Issue no.] contains the issue number of the document being under review, e.g.

“01.01” or “draft 2b”.

• The field [Issue date] contains the date of issue for the document being under review in the

form of “YYYY-MM-DD”, alternatively “MMM YYYY” (e.g. 2010-03-25, alternatively MAR 2010).

• The field [Filename(s)] contains the filename of document being under review, where such is

known.


Review Comments

This part shall include the actual review comments to the document being reviewed. The fields shall

be used as follows:

• The column [Item no] is a unique number for each DRF item (or row), which is sequential, starting

with 1.

• The column [Reference] contains a description of, which part of the text the comment relates, e.g.

- “General” applies generally for the entire document

- “3.2 (1)” applies for chapter 3.2, section 1

- “5 (general)” applies generally for chapter 5

- “page 4, lines 7-9” applies for lines 7 to 9 on page 4

- “6.3 (figure)” applies for figure in chapter 6.3

- “A1340332311BS” applies for a requirement

- “Header” applies for the Header

• The column [Reviewer] contains the reviewer’s initials, as stated in the revision history (see

chapter 4.1).

• The column [Reviewer comments] contains as clearly as possible the statement for the reviewed

text. To the extent possible, the reviewer shall state what action should be performed in order to

satisfy the reviewer, e.g. “This section shall include ...”. The more imprecise the comment, the

more difficult it is to address the comment in an adequate manner.

• The above four columns are the mandatory information (as for DRF items) required at the first

stage of reviewing a document. The remaining three columns are used for updating purposes,

tracing which action has been taken on a specific comment.

• The column [incl. (Y/N)] indicates whether or not the given statement is implemented/taken care

of in the updated document. If the Author implements/ takes care of the statement provided, this

field would contain a “Y”, otherwise the field will include a “N”.

• The column [Authors response] contains the Author’s response to the statement of each DRF

item. In case a “N” has been included in the column before, this column will include the

explanation as for why the comment should not be taken into consideration.

• The column [Reviewers check] indicates the reviewer response to the Author’s response. If the

reviewer accepts the response given by the Author, this field would contain a “YYYY-MM-DD: OK”,

otherwise the field shall include a statement describing the disagreement. This field will, together

with the [Author response], document the discussions held on a particular item. E.g. if the

reviewer disagrees with the Author the reviewer will note in his field: “YYYY-MM-DD: Statement”.

If the Author continues to wish to discuss the issue, he will note in his field: “YYYY-MM-DD:

Statement”. This process may continue until an agreement has been achieved1.

4.2.8 Identification, versioning and labelling

This paragraph describes in detail how documents shall be identified, how the version numbering

scheme shall be used and how the documents shall be labelled.

Identification

The identification of a document includes the following attributes:

a) Document (document type)

b) Document Id

1 It is recommended, that if an agreement is not achieved in the first round, then a meeting will be held to agree the way forward on remaining comments as the process otherwise may take a considerable amount of time.


c) File name

d) Author

e) Approved by

f) Date

g) Revision nr (version)

h) Reference

i) Classification

The use of these attributes is defined in the following sections.

Document type

The type of the document shall be taken from the list of allowed document types.

Document id

All documents, drawings, plans, schedules etc. produced by HANSA staff, which are not

entirely for personal use only, shall be numbered according to HANSA requirements as

follows:

The format of the identification shall be:

<org> <HANSA><number>.<xx>.<tool>.

<org> shall be the unit within the project organisation to which the staff member belongs to.

The following possibilities exist:

MGT HANSA Management

OPS Function for Operational Oversight

TEC Function for Technical Oversight

LEG Function for Legal support and International Relations

PER Function for Personnel Licensing, Finance & Training Oversight

SQS Function for Safety, Quality and Security Oversight

IOP Function for Interoperability Oversight

ADM Function for Administrative Support

All documents shall start the identification with HANSA, followed by a sequence number

which is drawn from the document registry (running number starting with 00001 to 99999). If

a document is embedded in a main document, the document shall carry the identification of

the main document, with a subordinate number <xx> added, running from 01 to 99, which

identifies the embedded document (e.g. a drawing included in the main document). <xx> for

the main document will always be <00>.

<tool> shall be one of the following acronyms:

DOC (Words for Windows)

DRW (Designer drawings)

MPP (Microsoft Project)

MSA (Microsoft Access)

PDF (Acrobat reader format)

PS (PostScript file, for printing only)

PPT (Microsoft Power Point)

XLS (Excel)

The tools to be used are defined in the associated reference.

File name

The file name of the document shall consist of the following fields from the document

identity: <HANSA><number>.<xx>.<tool>.

Author

Author shall include the first and last name of the author responsible for the document,

together with the phone number (including the country code) and the e-mail(s) where the

author can be reached in case of any problems.


Approved by

Approved by shall include the staff member who has approved the release of the document.

This will normally be one of the following:

• H/HANSA (Head of HANSA);

• H/ATS (Head of A’ Section, Certification & Service Provision Oversight for ATS, AIS & MET);

• H/CNS (Head of B’ Section, Certification & Service Provision Oversight for CNS);

• H/PLI (Head of C’ Section, Planning, Legal Support & International Relations);

• H/PLI (Head of D’ Section, Safety, Quality & Security Oversight);

• H/HRF (Head of E’ Section, Human Resources & Financial Oversight);

• H/IOP (Head of ST’ Section, Oversight for Interoperability of Systems & Procedures);

For documents with only the author’s approval, this field shall be left empty.

Note: even though there is a review function for any official document being issued, and all

formal documentation must be approved by the quality manager in order for it to be

officially released by the HANSA, the QM shall not be included in this field. It must be the

person with the responsibility for the area in which the document is produced.

Date

Date shall be given in ISO format as YYYY-MM-DD, e.g. 1994-12-24.

Revision

This field shall include the number of the revision.

Reference

This field shall include the document reference, e.g. which segment of the HANSA work the

document relates to e.g.:

REG for Regulation

PRO for Process

DIR for Directive

CER for Certification

APP for Approval

ADO for Adoption

MEM for Memo

REP for Report

MIN for Minutes of Meeting

AGE for Agenta

INV for Invitation

MEE for Meeting

PLA for Plan

REQ for Requirement

SPE for Specification

Classification

This field shall state the classification of the document.possible classifications:

• Commercially Sensitive

• Personally Sensitive

• Public

• Unclassified.

Versioning


Versioning of documents shall consist of two numbers - the issue number and the draft number - in

the format <xx>.<yy>.

<xx> is the issue number, which only goes up when a document has been formally approved and

released by the HANSA. The issue number starts with 00 and goes up to 99.

<yy> is the draft number, which goes up each time the document is updated. The draft number starts

with 01 and goes up to 99.

When an issue is final and is to be forwarded for approval and release, the author shall change the

version number to e.g. 01.00.

When a final issue is updated, the first draft version of the document shall be given version number

e.g. 01.01 and when released again a new number e.g. 02.00.

Labelling

Labeling relates to media, paper and discs.

Paper

Standard labeling of documents shall be ensured by the use of standard document layouts. This

covers the following types of documents:

• Large documents, with front page, revision history, distribution list, list of contents etc.

• Small documents, with title and revision history only

• Letters

• Faxes

• Minutes of Meetings

• Announcements of meetings

• Document review forms

• Problem reports

• Handover notes (for QAR only)

• Rejection notes (for QAR only)

• Registration Notes (for QAR only)

• Document archive front sheet (for Administration only)

Most of the standard documents exist in different versions, depending of the classification of the

document e.g. Public.

The use hereof is mandatory.

Disc or removable storage

Discs used for soft copies of formal project documentation shall be labelled with a marker and

include the following information:

a) Disc number, which shall be in the format <HANSA><org><number> where:

b) <org> is the name of the organisation owning the discs, e.g. OPS, TEC, etc.

c) <number> is the sequence number of the discs

d) Title, which shall give an indication of the content of the discs and may state document type

e) Responsible, which shall be the person responsible for the discs (initial only)

f) Creation data, which shall be the date of the oldest file on the disc

g) Classification, which shall indicate the highest classification of any document stored on the

discs

Note: classified documents may have specific restrictions as to storage on media other than paper.

Document types

When selecting the name for the document, the following document types shall be used:


1. Budget

2. Clarification

3. Contract

4. Directive

5. Drawing

6. Handbook

7. Information

8. Instruction

9. List

10. Memo (Memorandum)

11. Minutes (Meeting minutes)

12. Notice

13. Plan (Plan of any kind, e.g. Audit Plan)

14. Process

15. Regulation

16. Report

17. Request

18. Schedule

19. Specification

20. Requirement

4.2.9 Exemptions

The Head of HANSA can grant exemptions from this process. Exemptions will be very limited.

4.2.10 Implementation

This section shall define when the process becomes effective and includes a definition of any

transitional arrangements.

This process comes into force on the 24 April 2012.


20

REFERENCE DOCUMENTS

[1] ESARR 1 ”Regulation on National ATM Safety Regulatory Framework”, by EUROCONTROL

[2] EAM 3/GUI 1 ESARR 3 Guidance to ATM Safety Regulators – “Explanatory Material on

ESARR 3 Requirements”, issued by EUROCONTROL

[3] EAM 3/GUI 2 ESARR 3 Guidance to ATM Safety Regulators – “Safety Regulatory Aspects

of the ESARR 3 Implementation in Small Organisations”, issued by EUROCONTROL

[4] EAM 3/GUI 3 ESARR 3 Guidance to ATM Safety Regulators – “ESARR 3 and Related Safety

Oversight”, issued by EUROCONTROL

[5] SRC Policy Doc 3, EUROCONTROL

[6] ESARR 3 Use of Safety Management Systems by ATM Services Providers, issued by

EUROCONTROL

[7] ESARR 2 Safety Regulatory Requirements: Reporting and Assessment of Safety

Occurrences in ATM, issued by EUROCONTROL

[8] ESARR 4 Risk Assessment and Mitigation in ATM, issued by EUROCONTROL

[9] ESARR 5 Safety Regulatory Requirements for ATM Services Providers, issued by

EUROCONTROL

[10] ESARR 6 Safety Regulatory Requirements for Software ATM, issued by EUROCONTROL

[11] EAM 3/AMC Acceptable Means of Compliance with ESARR 3, issued by EUROCONTROL

[12] EAM 3/ICAO Consistency between ESARR 3 and ICAO SARPs, issued by EUROCONTROL

[13] REGULATION (EC) No 549/2004, “The framework Regulation”, 10/3/2004

[14] REGULATION (EC) No 550/2004, “The service provision Regulation”, 10/3/2004

[15] REGULATION (EC) No 551/2004, “The airspace regulation”, 10/3/2004

[16] REGULATION (EC) No 552/2004, “The interoperability Regulation”, 10/3/2004

[17] REGULATION (EC) No 2096/2005, “Common Requirements for the provision of air

navigation services, 20 December 2005

[18] Commission Regulation (EC) 2042/2003 of 20 November 2003 on the continuing

airworthiness of aircraft and aeronautical products, parts and appliances, and on the

approval of organisations and personnel involved in those tasks (notably the drafting has

considered Annex II, “Part-145”)

[19] EASA Organisations Certification Process, adopted on 3 February 2004 by means of the

EASA Management Board Decision 3-2004 concerning the general principles related to

certification processes to be applied by the EASA Agency for issuing certificates for

organisations.

[20] IAF Guidance on the Application of ISO/IEC Guide 66, Issue 2, Dec. 2001

[21] EUROCONTROL EAM 1/GUI 1, Edition 1.0


[23] EUROCONTROL ESARR 2, Edition 2.0





21

[27] EUROCONTROL EAM 2/COD 1, Edition 3.0

[28] EUROCONTROL EAM2/COD 2, Edition 2.0

[29] EUROCONTROL EAM 4/GUI 1, Edition 1.1 (Draft)






[35] EU Council Directive 94/56/EC, 21 November 1994

[36] EU Directive 2003/42/EC of the European Parliament and of the Council 13 June 2003


22

GLOSSARY

AAND Area Air Navigation Department

ACC Area Control Centre

AFIS Aerodrome Flight Information Service

AIP Aeronautical Information Publication.

ANS Air Navigation Services

ANSP Air Navigation Service Provider

ASM

ATC

AirSpace Management

Air Traffic Control

ATCO Air Traffic Controller

ATFM

ATM

Air Traffic Flow Management

Air Traffic Management

ATS Air Traffic Services

ATSEP Air Traffic Safety Engineering Personnel

CM Configuration Manager

CMS Configuration Management System

DG Director General

EFQM European Foundation for Quality Management

FAA Federal Aviation Administration

GDAN General Director of Air Navigation

HANSA Hellenic Air Navigation Supervisory Authority

HCAA Hellenic Civil Aviation Authority

HQ Headquarter

NSA National Supervisory Authority

SES Single European Sky

SLA Service Level Agreement

SMM Safety Management Manual

SMS

SQS

Safety Management System

Safety-Quality-Security


23

CHANGE RECORD

Revision

Date

Pages/Sections

Affected

Edition-

Revision

Remarks

1.0 01/02/2007 All

2.0 24/04/2012 All


ANNEX 1

PROCESSES AND PRACTICES

This section lists all processes and instructions that are to be used by the HANSA in discharging their

responsibilities. The list includes document id, title, revision and date of issue of the valid document.

HANSA PROCESSES

Doc. ID Title Rev Date

1. HANSA_Air Navigation Service Providers Certification 3.0 15 May 2012

2. HANSA_Air Navigation Service Providers Designation 1.0 1 Feb. 2007

3. HANSA_ ATM/ANS Training Organisations/ Providers Certification 1.0 4 Apr. 2012

4. HANSA_ ANSP_ATM/ANS Safety Oversight 2.0 1 Feb. 2010

5. HANSA_ ANSP_ATM/ANS Quality Oversight 1.0 15 Jan. 2010

6. HANSA_ANSP_ATM/ANS Security Oversight 1.0 16 May 2012

7. HANSA_ANSP_Interoperability Oversight 1.0 15 Jan. 2010

8. HANSA_ANSP_Financial Oversight 2.0 12 Apr. 2012

9. HANSA_ANSP_Human Resources & ATM/ANS Personnel Oversight 2.0 17 Apr. 2012

10. HANSA_ANSP_ASM/ATFM Oversight 1.0 7 May 2012

11. HANSA_Management of Air Traffic Controllers Licences 1.0 5 Jan. 2012

12. HANSA_Configuration Management & Document Control 2.0 16 May 2012

OTHER SUPPORTING DOCUMENTATION

Doc. ID Title Rev Date

Date post:	28-Oct-2014
Category:	Documents
Upload:	hellenic-air-navigation-supervisory-authority
View:	33 times
Download:	0 times

HANSA_Configuration Management and Document Control Process

Documents