U NIVERSITY OF L ISBON
Faculty of Sciences
Department of Informatics
HAZARD LOGGING AND MANAGEMENT SYSTEM
Maria João Roque Barbado Leal
PUBLIC
MASTERS IN INFORMATICS ENGINEERING
Specialization in Information Systems
2010
U NIVERSITY OF L ISBON
Faculty of Sciences
Department of Informatics
HAZARD LOGGING AND MANAGEMENT SYSTEM
Maria João Roque Barbado Leal
PROJECT
Project oriented by Prof. Doctor Pedro Alexandre de Mourão Antunes
and by Eng. Paula Luisa Costa Teixeira Santos
MASTERS IN INFORMATICS ENGINEERING
Specialization in Information Systems
2010
Resumo
No âmbito do sistema de gestão da segurança (SMS), existente nos serviços de controlo de tráfego aéreo, uma variedade de perigos, para os serviços prestados, são identificados e classificados de acordo com seu potencial impacto. Estes perigos precisam ser
seguidos e devem ser geridos de uma forma clara e eficiente, desde a fase de concepção
do sistema, ou de qualquer alteração importante feita nos sistemas em operação, até à
sua retirada de serviço. A principal missão da NAV Portugal é proporcionar serviços de
controlo de tráfego aéreo nas Regiões de Informação de Voo (RIV) de responsabilidade
Portuguesa (Lisboa e Santa Maria), assegurando que as normas nacionais e internacionais
sejam cumpridas nas melhores condições de segurança, optimizando capacidades, e enfatizando a eficiência, não deixando de lado as preocupações ambientais.
Na NAV Portugal este processo ainda é baseado papel e carece de um sistema central
onde toda a informação pode ser armazenada de forma consistente, actualizada e acedida.
Este projecto de nove meses teve como principal objectivo analisar e desenvolver uma
solução para registar perigos e toda a informação associada, tal como acções de mitigação, a frequência aceitável de ocorrências, as próprias ocorrências e os seus impactos.
O sistema de registro e gestão de perigos foi desenvolvido com a supervisão da Eng. Paula
Santos, chefe da área SISQUA (Sistemas de Gestão de Qualidade e Safety). SISQUA é
uma das quatro áreas que compõem o Departamento de Sistemas e Tecnologia da Informação (DSTI). DSTI representa a empresa em assuntos nacionais e internacionais relacionadas com a evolução do ATM. Devido ao papel crítico desempenhado pelos prestadores de serviços de controlo de tráfego aéreo no transporte diário de milhares de pessoas, a NAV Portugal tem implementado um extenso Sistema de Gestão Ambiental e
de Qualidade, em conformidade com os requisitos da NP EN ISO 9001:2008 e NP EN
ISO 14001:2004 (+ Emenda 1: 2006). Este sistema de gestão abrange a prestação de
serviços de navegação aérea em geral e outros serviços relacionados, tais como Gestão
de Informações Aeronáuticas (AIM), das Comunicações, Navegação e Vigilância (CNS),
treinamento e serviços de desenvolvimento de sistemas de ATM. Esta implementação
garante, não só, a uniformidade de procedimentos dentro da organização, mas também a
conformidade com os procedimentos definidos e transparência exigidos pelos auditores
externos.
O projecto levado a cabo neste estágio deve, a qualquer tempo, conseguir dar informação
sobre os perigos que estão associados a um determinado sistema, como eles podem ser
mitigados e se a frequência de ocorrências está dentro do intervalo definido. A solução
teve também que incluir módulos para gestão de utilizadores, backup de dados e login
para garantir o cumprimento do objectivo principal do projecto.
Em termos de desenvolvimento de software, a solução teve que ser desenvolvido de
acordo com, não apenas, os requisitos funcionais, mas também os requisitos não-funcionais,
tais como, uma boa capacidade de integração com outros sistemas e utilização de tecnologias de código aberto, não proprietárias, estáveis, que garantam a disponibilidade de dados
e a sua facilidade de manutenção.
Juntamente com a produção de um sistema de gestão e registo de perigos, este projecto teve como objectivo apresentar toda a documentação necessária para garantir que
as decisões foram documentadas, justificadas e avaliadas. Entre os documentos exigidos
enfatiza-se especialmente o documento de especificações do sistema (DES), o Plano de
Gestão de Testes (TMP), o documento dos testes de aceitação (ATD), o documento sobre
a arquitectura do sistema(SAS) e o manual do utilizador(OH).
Durante a análise de requisitos foi necessário uma representação conceptual dos conceitos
que envolviam o projecto. O modelo entidade-relação (ERM) foi o modelo escolhido pela
sua abordagem top-down. Este modelo foi evoluiu durante a fase de recolha de requisitos
e mostrou ser a mais importante e inovadora realização do projecto.
Após as fases de levantamento de requisitos e definição do modelo de dados, foi essencial
definir abstractamente a estrutura do sistema. A arquitectura do sistema é uma representação conceptual, baseado na captação de diferentes elementos que descrevem a estrutura
do sistema. Uma das principais decisões de arquitectura foi a utilização de serviços Web
incorporando o padrão Model View Controller. Esta abordagem, além de todas as vantagens inerentes, também oferece a cobertura de alguns dos requisitos não-funcionais como,
interoperabilidade ou acesso à Internet para diversos utilizadores com diferentes tipos de
permissões no sistema.
A fim de atingir os requisitos e arquitectura definidos uma variedade de tecnologias foram
escolhidas, como o GWT e SmartGWT para desenvolvimento da camada de interacção
com o utilizador ou o Hibernate para mapeamento da base de dados. Esta decisão teve em
conta que as tecnologias utilizadas tinham de ser livre, permitir a evolução do projecto e
garantir a fiabilidade e disponibilidade dos dados.
Actividades de validação e verificação de produto foram realizadas durante todo o ciclo
de vida do projecto, da validação dos requisitos até a testes de aceitação do produto, para
atingir, tão cedo, como possível a identificação de problemas, ou insuficiências, reduzindo
assim o impacto de mudanças provocadas pela necessidade de correcções, ou adaptações.
Durante os nove meses de estágio foram cumpridos todos os objectivos do projecto, pondo
em prática os conhecimentos adquiridos na universidade com um alto grau de independência e estar em contacto com novas tecnologias, como o GWT e SmartGWT, trabalhar
numa arquitectura orientada a serviços e integrar um ambiente bem estruturado e de assegurada qualidade profissional. O projecto também deu a oportunidade de estudar e
analisar uma área estimulante, que é ainda muito baseados em documentos em papel e em
que a informática pode ter um impacto considerável.
A maior principal do projecto foi a realização de todas as metas no prazo estipulado, devido à sua complexidade e ao facto de que não existirem projectos semelhantes disponíveis
para comparar e obter informações.
Palavras-chave: Gestão de perigos, ATM, NAV Portugal, Safety
Abstract
Under the air traffic services safety management system (SMS) a variety of hazards,
to the provided services, are identified and classified according to their potential impact.
These hazards need to be followed and should be managed in a clear and efficient way,
from a new system design phase, or any important change made in the systems in operation, until their withdrawal from service. In NAV Portugal this process is still paper based
and lacks a central system where all the information can be consistently stored, updated
and accessed.
This project aimed to analyze and develop a solution to register hazards and associated
information, such as mitigation actions, acceptable frequency of occurrence, recorded occurrences and their impacts. This solution must, at any time, report on what dangers are
associated with a given system, how they may be mitigated and if the hazards frequency
of occurrence is within the defined range. Also, the solution had to include a user management, login and data backup modules to ensure the projects main goal accomplishment.
In terms of software development, the solution had to be developed according to, not only,
functional requirements, but also to non-functional requirements, such as, a good capability of integration with other systems and use stable available open source technologies,
that ensured data reliability, availability and maintainability.
Alongside the production of an hazard management and logging system, this project
aimed to produce the required documentation that ensured all decisions were documented,
justified and evaluated. Among the required documentation special emphasis had to be
put on the production of the System Specification Document (DES), on the Test Management Plan (TMP), on the Acceptance Tests Document (ATD), on the System Architecture
Specification (SAS) and on Operating Handbook (OH).
This project has met all its initial goals arousing international interest.
Keywords: NAV Portugal, Hazards Log, Web Services, Safety Management System
Contents
List of Figures
xiv
List of Tables
xvii
1
Introduction
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Document organization . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2
2
Project
2.1 Organization . . . . . . . . . . . . .
2.2 Organizational Structure . . . . . .
2.3 Organizational Quality Management
2.4 Development Methodology . . . . .
2.5 Tasks . . . . . . . . . . . . . . . .
.
.
.
.
.
3
3
4
6
7
8
.
.
.
.
.
.
.
.
.
11
12
13
16
16
17
17
20
22
23
.
.
.
.
25
25
26
26
27
3
4
.
.
.
.
.
.
.
.
.
.
Context Study
3.1 Safety . . . . . . . . . . . . . . . . . .
3.2 Hazards and Occurrences . . . . . . . .
3.3 Risk Classification . . . . . . . . . . .
3.4 Safety Objective . . . . . . . . . . . . .
3.4.1 Safety Objectives Quantification
3.4.2 Qualitative Model . . . . . . .
3.5 Safety Management . . . . . . . . . . .
3.6 Computational Support . . . . . . . . .
3.7 Hazard Logging . . . . . . . . . . . . .
Project Development
4.1 Project Requirements . . . . . . . . .
4.1.1 Users . . . . . . . . . . . . .
4.1.2 Functional Requirements . . .
4.1.3 Non-Functional Requirements
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.2
4.3
4.4
4.5
5
6
Data Model . . . . . . . . . . . . . . . .
4.2.1 Entity-Relationship Model . . . .
4.2.2 Integrity Rules . . . . . . . . . .
4.2.3 Relational Model . . . . . . . . .
4.2.4 Database Model . . . . . . . . .
Architecture . . . . . . . . . . . . . . . .
4.3.1 Web services . . . . . . . . . . .
4.3.2 REST . . . . . . . . . . . . . . .
4.3.3 Model View Controller Pattern . .
Technologies . . . . . . . . . . . . . . .
4.4.1 Google Web Toolkit . . . . . . .
4.4.2 Smart GWT and Smart Client . .
4.4.3 JSON . . . . . . . . . . . . . . .
4.4.4 Hibernate . . . . . . . . . . . . .
4.4.5 Session Management and Cookies
4.4.6 User Privacy and Security . . . .
Tests . . . . . . . . . . . . . . . . . . . .
4.5.1 Unit Tests . . . . . . . . . . . . .
4.5.2 Integration Tests . . . . . . . . .
4.5.3 Acceptance Tests . . . . . . . . .
4.5.4 Test Approval Criteria . . . . . .
Implementation
5.1 Package Organization . . .
5.2 Web Services . . . . . . .
5.2.1 User Management
5.2.2 Data Management
5.2.3 Log Management .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Results
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
30
31
33
34
34
36
38
40
41
41
42
42
43
44
44
45
45
45
50
.
.
.
.
.
53
53
55
56
58
63
65
Glossary
70
x
xii
List of Figures
2.1
2.2
2.3
2.4
2.5
2.6
Flight information region of Portuguese Responsibility[12]
Business Areas[12] . . . . . . . . . . . . . . . . . . . . .
Company’s Organogram. [12] . . . . . . . . . . . . . . .
Diagram illustrating the Unified Process flow. . . . . . . .
Project Activities. . . . . . . . . . . . . . . . . . . . . . .
Project Timing . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
5
7
9
10
3.1
3.2
3.3
3.4
Accident penetrating all defensive layers[24] . . . .
Example - Hazard’s Bow-Tie Diagram[20] . . . . . .
Quantitative Model Hazard Safety Objective Example
FHA report table example . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
19
24
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
Example of a formal use case description. . . . . . .
Early Entity-Relationship Model . . . . . . . . . . .
Final Database Model . . . . . . . . . . . . . . . . .
Platforms and devices . . . . . . . . . . . . . . . . .
Independent Data Layer . . . . . . . . . . . . . . . .
Model View Controller diagram.[30] . . . . . . . . .
Technology Stack Diagram . . . . . . . . . . . . . .
Test Model . . . . . . . . . . . . . . . . . . . . . .
User Management Tests . . . . . . . . . . . . . . . .
Hazard Environment Management Tests . . . . . . .
Hazard Management Tests . . . . . . . . . . . . . .
Example - Add Cause Acceptance Test Specification
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
29
33
35
36
39
40
46
47
48
49
50
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Hazard Management Tests . . . . . . . . . . . . . .
Quantitative Model Hazard Safety Objective Example
Login Screen . . . . . . . . . . . . . . . . . . . . .
Login Activity Diagram . . . . . . . . . . . . . . . .
Add User Screen . . . . . . . . . . . . . . . . . . .
Add Effect Screen . . . . . . . . . . . . . . . . . . .
Add record activity diagram example . . . . . . . . .
View Record Content Screen . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
55
56
57
57
58
59
60
xiii
5.9
5.10
5.11
5.12
Remove Record activity Diagram Example
Remove Record activity Diagram Example
Update Record Activity Diagram Example .
Change System State Screen . . . . . . . .
xiv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
62
63
xvi
List of Tables
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Severity Classification Scheme in ATM [15] . . . . . . . . . . . .
Severity Classification Scheme for ATM specific occurrences [16]
Example - Risk Classification Scheme[18] . . . . . . . . . . . . .
Specification of National Regulatory RCS[35] . . . . . . . . . . .
Specification of ATMSP RCS[35] . . . . . . . . . . . . . . . . .
ATMSP RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for Safety Management Systems[21] . . . . . . . .
Comparative benefits of a positive safety culture[17] . . . . . . .
xvii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
18
18
18
21
22
Chapter 1
Introduction
This chapter provides an overview of the Hazard Logging and Management System developed at NAV Portugal, the Portuguese Air Traffic Management Service Provider, as
part of my nine months internship. This chapter shortly describes the project’s context
and goals. These goals were fully achieved during the internship, having received international recognition. The project as well as a successful personal integration in the
work environment, working team and company’s development methods. As this project
is subject to confidentiality some parts of the final report are not included in this public
version.
1.1
Context
The air traffic services Safety Management System (SMS) defines a variety of hazards and
classifies them according to their potential impact. These hazards need to be followed by
the safety and should be managed in a clear and efficient way, throughout all of the service
life cycle. In NAV Portugal this process is still paper based and lacks a central repository
where all the information can be consistently stored, updated and accessed.
1.2
Goals
This project aimed to analyze and develop a solution to register hazards and all of the
associated information, such as mitigation actions, acceptable frequency of occurrence,
recorded occurrences and their impacts. This solution must be able to, at any time, report
on what dangers are associated with a given system, how they may be mitigated, and if
the hazards frequency of occurrence is within the defined range. Also, the solution had to
include user management and data backup modules.
In terms of software development, the solution had to be developed according to functional requirements, but also to non-functional requirements, including integration with
other systems and adoption of stable open source technologies, ensuring data reliability,
1
Chapter 1. Introduction
2
availability and maintainability.
Alongside the production of an hazard management and logging system, this project
aimed to comply with strict rules requiring that all decisions are documented, justified
and evaluated. Among the required documentation, special emphasis had to be put on
the production of the System Specification Document (DES), the Test Management Plan
(TMP), the Acceptance Tests Document (ATD), the System Architecture Specification
(SAS) and the Operating Handbook (OH).
1.3
Document organization
This document describes in detail the work performed during the nine months internship
at NAV Portugal and is structured as follows.
The following chapter overviews the hosting institution in terms of business areas, structure and quality management principles. It also, explains how the project is inserted in the
organizational context, the adopted development methodologies and the task schedule.
The third chapter presents the problem and its context, the necessary background information and the main concepts used through the project, giving a vital and clear understanding
of the developed work. Safety, hazards, occurrences and hazard logs are key notions that
will be defined it this chapter.
The project development is presented in the fourth chapter, showing and explaining the
outcomes of the requirements gathering and specification phases, data modeling, architecture specification, tests specification and chosen technologies.
The ensuing chapter describes the final implementation decisions, encountered difficulties and the application’s results. Examples of the main functionalities are also given.
The last chapter discusses the project’s outcomes in terms of personal and organizational
gains. This chapter, also discusses the projects future prospectives and possible evolution.
Chapter 2
Project
2.1
Organization
The NAV Portugal’s main mission is to provide air traffic services in the Flight Information Regions (FIR) under Portuguese responsibility (Lisbon and Santa Maria), ensuring
that national and international regulations are complied with in the best safety conditions,
optimizing capacities, and emphasizing efficiency while not neglecting environmental
concerns. The company carries out its work on mainland Portugal and in the autonomous
regions of Azores and Madeira.
Figure 2.1: Flight information region of Portuguese Responsibility[12]
The company’s head offices are situated next to Lisbon Airport, as are the Lisbon Air
Traffic Control Center and the Training Center. The Oceanic Control Center is located
on the island of Santa Maria in the Azores autonomous region. In additional to these two
important centers, NAV Portugal has other infrastructures operating in the control towers
of Lisbon, Porto, Faro, Funchal, Porto Santo, Santa Maria, Ponta Delgada, Horta, and
3
4
Chapter 2. Project
Flores airports and, also, provides air traffic services to Cascais aerodrome.
To fully carry out its air traffic control mission, NAV Portugal operates a considerable
amount of equipment and technical installations (radar, radio and communications stations).[7].
NAV Portugal, as the national Air Navigation service provider participates, representing in some cases the Portuguese State, in organizations related to civil aviation, such as
ICAO (International Civil Aviation Organization), United Nations Organization for Civil
Aviation, worldwide and EUROCONTROL (European Organization for the Safety of Air
Navigation), whose membership includes almost all the European states. NAV Portugal
is also a member of CANSO (Civil Air Navigation Services Organization).
Figure 2.2: Business Areas[12]
2.2
Organizational Structure
To accomplish its mission, NAV Portugal has a welldefined organizational structure,
shown in Fig 2.2 and 2.3. With relevance to this work, we highlight the following units:
• DOPLIS e DOPATL - Ensure the Air Navigation Services provision, respectively,
in the Flight Information Region of Lisbon and the Flight Information Region of
Santa Maria.
5
Chapter 2. Project
Figure 2.3: Company’s Organogram. [12]
• DSEGOP - Responsible for Operating Security System, Procedures, Operational
and Maintenance Routines, Traffic and Technical Indicators and Aeronautical Information Provision Service.
• DSTI e DETPRO – Ensure technical evolution, strategic investments and operational, or technical developments in the ATM and CNS areas, respectively.
• DREL - Human resources management, guaranteeing the necessary resource conditions and availability to pursue the company’s goals.
• DAFIN - Responsible for the economical and financial areas.
• DGQUA - Quality Management System promotion and management, covering also
the environmental aspects.
• GABJUR, GABDES, GABCIM, COGEST e FORMA – Ensure advice to the Board
and other organs of the company, particularly in the areas of legal issues inherent to
the business, the definition of strategy and external positioning, the image diffusion,
consolidation of enterprise culture, activity monitoring and training.
The Hazard Logging and Management System was developed with supervision of Eng.
Paula Santos, head of SISQUA area. SISQUA is one of four areas that compose the Department of Systems and Information Technology (DSTI). DSTI represents the company
in national and international matters related with developments in ATM. DSTI, also conducts technical studies and monitors the operations of Air Traffic Management Support
Systems in compliance with national and international standards. Also, DSTI develops
ATM systems for the ACC (Area Control Center) and control towers.
Chapter 2. Project
6
The department is divided in several areas, including SISINT, SISPRO, SISLOG, SISQUA.
SISINT is responsible for identifying operational requirements, producing functional and
test specifications and performing validation/acceptance tests for the ATM systems. SISPRO is responsible for the systems architecture and its development. SISLOG deals with
logistical issues, like the process of acquisition of hardware. The current project is integrated in the SISQUA (Quality and Safety Management Systems) area, which is responsible for selecting and developing procedures in accordance with national and international
standards. SISQUA also assists and monitors the implementation of procedures defined
by the Quality Management System, and assists and monitors the application of Safety
standards in the development of ATM systems.
This project also included the participation of members of NASO and SEGNA, areas
within DSEGOP for requirement gathering; and members of EUROCONTROL for hazard logging working experience information exchange.
2.3
Organizational Quality Management
Due to the critical role played by Air Traffic Control Service Providers in the transportation of thousands of people every day, NAV Portugal has implemented an extensive Quality and Environmental Management System, in accordance with the requirements of NP
EN ISO 9001:2008 and NP EN ISO 14001:2004 (+ Amendment 1: 2006). This management system covers the air navigation services provision in general and other related
services, such as Aeronautical Information Management (AIM), Communications, Navigation and Surveillance (CNS), Training and ATM Systems development services.
This implementation ensures, not only, the uniformity of procedures within the organization but also the conformance with defined procedures and transparency required by
external auditors.[12]
In this context, the NAV Portugal’s activity is characterized by a set of business processes, called operating procedures and a set of management and support processes. The
operational processes go from marketing and sales to ATM service provision. The support
processes go from human resource management to external relations management.
This project adopted the operational process for System Development Service Provision
(POP 20) and its related procedures. For each POP 20 procedure, there is defined set
of documentation needed; and each document has a template, which has the respective
completion instructions. This approach makes all documents more homogeneous and in
conformity with standards. All documents are reviewed by several people from different
areas, who are related with the project, including the quality department. The produced
documents, if necessary, are updated to include comments from the reviewers. In order
7
Chapter 2. Project
to be approved, all of the produced documentation has to be distributed and reviewed by
members of SISINT, to verify requirements and test specifications, members of NASO
and SEGNA, to verify the system functional and non-functional requirements, and by
members of SISQUA, to verify consistency, completion and traceability.
2.4
Development Methodology
As stated in the previous section, the project development was based on the operation
process for System Development Service Provision (POP 20) The POP 20 procedures a
sequence of activities and their expected outputs, auxiliary information and members responsible for each activity taken. The development methodology roughly translates to the
Unified Software Development Process (USDP).The USDP was chosen for its use-case
driven, architecture-centric, iterative and incremental structure. Also, by applying this
process, software development can produce high-quality software that meets the needs of
its end-users within a predictable schedule.[5]
The USDP applies use-cases to capture soft requirements and to define the content of the
iterations. The architecture is very important for this process being at the heart of the
projects team’s effort to shape the system. The phases of this process (Inception, Elaboration, Construction, Transition) are divided into a series of time-boxed iterations. Each
iteration resorts in an increment, which is a release of the system that contains added or
improved functionality compared with the previous releases.[8]
Figure 2.4: Diagram illustrating the Unified Process flow.
[9]
Chapter 2. Project
2.5
Tasks
The work plan was defined to be accomplished in 9 months.
8
9
Chapter 2. Project
Figure 2.5: Project Activities.
10
Chapter 2. Project
Figure 2.6: Project Timing
Chapter 3
Context Study
Since the early 1950’s, the civil aviation has increasingly become a significant contributor to the overall well-being and economic vitality of individual nations as well as to the
world in general. One of the requirements of carrying out civil aviation activities is to
ensure that a safe, secure, efficient and environmentally sustainable air navigation system
is available, at the global, regional and national levels.[1]
Safety is the first concern of an Air Traffic Services Provider. In 1995, EUROCONTROL
(European Organization for the Safety of Air Navigation) started its Air Traffic Services
Safety Management program, which obliges all member States to implement a clear and
systematic Safety Management System (SMS).
Advanced technologies have improved safety, so that even with substantial increases in
air travel, the number of accidents involving civil transportation tends to be constant. One
of the major contributors to this improvement is the air traffic control (ATC), which has
the primary purpose of separating aircrafts to prevent collisions, to organize and expedite
traffic flow, providing information and support to pilots. Even so, constant research is
needed to discern, monitor and reduce the underlying causes of aircraft accidents.
With a good safety management system, the air traffic service providers may evaluate
and control the effects of hazards associated with ATC. Following up on these hazards,
from the conception phase of a new system until its withdrawal, is necessary and must be
managed in a clear and efficient way.
NAV Portugal wants to maintain and improve its standards, providing an efficient, modern
and lean air traffic service. With this in mind, NAV Portugal has been designing systems
to implement good practices in operational tasks.
Safety is also the most important pillar of air navigation and for this reason NAV Portugal
is continually investing in terms of safety innovation. NAV Portugal’s SMS approaches
11
Chapter 3. Context Study
12
the company’s activities in a systematic way, seeking excellence in the field of safety
management. In the Air Navigation sector, SMS covers all of the services, people, infrastructures, equipment, procedures, rules and information supplied to airspace users.[6].
The SMS is responsible for the identification, analysis and mitigation of possible risks;
and reporting all occurrences so that they may be investigated and corrective measures be
applied.
In the safety management area, there are a variety of concepts that can prove themselves
ambiguous. This chapter aims to give the necessary background information and concepts
avoiding any misconception regarding terms used throughout the project. Safety, hazards,
occurrences and hazard logs are key notions that will be defined it the next sections.
3.1
Safety
While the complete elimination of accidents (and serious incidents) would be desirable,
a one hundred per cent safety rate is an unachievable goal. Failures and errors will occur, despite of the best efforts to avoid them. No human activity or human-made system
can be guaranteed to be absolutely safe, i.e. free from risk. Safety is the state in which
the risk of harm to humans or property damage is reduced to, and maintained at or below an acceptable level, through a continuing process of hazard identification and risk
management.[17]
In many languages, like Portuguese, there is only one word that symbolizes both safety
and security. Although the basic idea is the same for both, the meaning is different.
This lack of direct translation can be fairly confusing when explaining the meaning and
objectives of safety management. The basic idea of both is protecting assets from hazards/threats, creating safe/secure conditions. Safety is protection against hazards, while
security is protection against threats.
Within the field of safety, hazards represent a potential danger for human health and lives,
the environment, production and material objects. Also, an incident is often an unplanned
event produced by human behavior in combination with the environment. In security, an
incident is often the outcome of a set of planned malicious actions triggered by a person or a group’s will. Unlike hazards, threats are not always observable, tangible and
proximate.[10]
Chapter 3. Context Study
3.2
13
Hazards and Occurrences
As defined in the previous section, a hazard is a situation in which there is potential danger for people or the environment.
An occurrence is the actual materialization of a certain hazard. Occurrences can be accidents, or incidents. An incident, or near miss, is an unintended event, or sequence of
events, that do not result in loss but that under different circumstances may have the potential to do so.
Figure 3.1: Accident penetrating all defensive layers[24]
Each hazard has its own causes, conditions, effects, barriers and mitigations.
Causes are events or latent conditions, that lead to a hazard under certain environmental
conditions, e.g. the failure to detect a wrong input, may cause the undetected corruption
of flight data for an aircraft, in an high traffic volume situation.
Having identified the hazards inherent to an activity, it becomes necessary to identify barriers that may provide effective control over these hazards. A barrier may turn access
to dangerous processes or states impossible or difficult (a lockout), may make it difficult
or impossible to leave a safe state or location (a lockin), or may enforce a sequence of
actions or events (an interlock).[11] Barriers may be physical, procedural, administrative
or human.[14]
To prevent hazards from developing into accidents, or to reduce their effects once they occur it is necessary to identify and define mitigations.[13] Risk assessment and mitigation
in Air Traffic Management (ATM) has to be performed by applying a process throughout
the life cycle of the components that form the ATM system. A system is viewed as a
combination of three constituents, humans, rules and procedures and physical equipment
1
The terms "active" and "latent" as applied to errors were coined by James Reason[25] [26]. Active
errors occur at the point of contact between a human and some aspect of a larger system, e.g. a humanmachine interface. Latent errors, in contrast, refer to results or decisions taken by designers, manufacturers
and senior management, this errors are less apparent failures of organization, or design, that contributed to
the occurrence of errors or allowed them to cause harm.
Chapter 3. Context Study
14
(hardware and software).
When performing risk assessment and mitigation in ATM, the emphasis has to be placed
on the process (hazard identification, effects identification and mitigations identification).
However, quantification ensures that clear, unambiguous and agreed risk levels can be
specified with an appropriate level of confidence.[35]
Figure 3.2: Example - Hazard’s Bow-Tie Diagram[20]
The occurrence reports are always very delicate, because they may contain information
about incidents or accidents caused by human error.
Despite the existence of occurrences in this Hazard Logging System, it is not their primary container. The system contains limited information about the occurrences, without
any delicate details. The occurrences are used to have a global idea of the system’s state
and to measure if the frequency of occurrences are within the desired value range. In
time, with this data, the safety management team may see if the barriers and mitigations
are being effective, or if the initial probability of occurrence is realistic. For more detailed
information about a certain occurrence, the system contains references to the source documents, or to the persons responsible for reporting that occurrence. Most of the time the
person responsible for an occurrence is not the person that writes the information in the
system. So, both entities should be modeled.
Both hazards and occurrences have effects, but they may not be the same. Hazards are
theoretical potential dangers, so their effects are the expected, theoretical effects. But the
planned may not be the same as the reality. The total loss of the radar picture for two
minutes, if occurring at a high peak traffic time, can cause a severe incident. But the same
hazard, occurring when there is almost no traffic and the aircrafts are well separated, result in no more then an inconvenience. For this reason, both hazard and occurrences may
have different effects. This makes it easier to see if a hazard leads to the expected effects
and, if not, what and why was the outcome different. Also, the severity of the effects of
hazards and occurrences are classified in a distinct way. The hazards severity is classified
by EUROCONTROL Safety Regulatory Requirement 4 (ESARR 4) and the occurrences
Chapter 3. Context Study
15
severity classification is based in the EUROCONTROL Safety Regulatory Requirement
2 (ESARR 2).
According to ESARR 4, the severity of the effects of hazards in a given environment
shall be determined using the classification scheme shown below in the table 3.1. This
scheme provides a quantitative ranking for the severity/magnitude of the hazard effects
on operations, which may arise from the various ATM System components.
Severity Class 1
2
3
4
5
Effect on
Accidents Serious
Major
Significant No immediate
Operations
incidents incidents incidents
effect on safety
Table 3.1: Severity Classification Scheme in ATM [15]
Usually, as there is no accident/incident causation model, the severity classification relies on a specific argument demonstrating the most probable effect of a hazard under the
worst credible scenario. With the introduction of this project, all effects may, in time, be
classified, instead of only the most probable effect, under the worst credible conditions.
In ESARR02 the severity classification scheme of occurrences is defined according to the
severity of their effect on the ability to provide safe Air Traffic Management Services. The
Severity Classification Scheme consists of categories of severity and for the frequency of
their occurrence. These are combined as a classification matrix whose columns correspond to the frequency categories and rows correspond to the severity categories shown
in table 3.2.
Table 3.2: Severity Classification Scheme for ATM specific occurrences [16]
The Severity Classification Scheme considers the actual frequency of each of these occurrences to enable the determination of the level of effort to be placed into the assessment
of the occurrence, as well as to support the development of trends in safety.
Chapter 3. Context Study
3.3
16
Risk Classification
The aviation industry faces a diversity of risks every day, many of them capable to compromise the viability of an operator, and some even posing a threat to the industry. Daily,
decisions are made in real time, weighing the probability and severity of any adverse consequences implied by the risk against the expected gain of taking the risk.[17]
A risk is the assessed potential for adverse consequences resulting from a hazard. It is the
likelihood that the hazard’s potential to cause harm will be realized. Risk assessment involves consideration of both the probability and the severity of any adverse consequences.
In other words, the loss potential is determined. In carrying out risk assessments, it is
important to distinguish between hazards (the potential to cause harm) and risk (the likelihood and impact of that harm).
A Risk Classification Scheme/Matrix is often very useful, because it specifies the maximum acceptable and tolerable frequencies of occurrence of a (hazard) effect of a certain
severity class per reference unit (flight hour, operational hour, per sector, etc.) It is derived
in accordance with the definition of risk.[18]
Table 3.3: Example - Risk Classification Scheme[18]
3.4
Safety Objective
Safety Objectives are defined in ESARR4 as a quantitative or qualitative statement that define the maximum frequency or probability at which a hazard can be expected to occur.[19]
For this project the definition of Safety Objective (SO) will follow the ED-125. So, a
safety objective is defined as a quantitative statement that defines the maximum frequency
Chapter 3. Context Study
17
or probability at which a hazard can be accepted to occur.[35]
To derive the SO, it is essential to understand also that the ATMSP is obliged to Safety
Targets. Safety Targets (STj ) specify the overall maximum frequency of occurrence of
effects of any type having a given Severity Class j (SCj ), whatever the ATM cause.
3.4.1
Safety Objectives Quantification
There are four models for quantifying SO:
• Quantitative Model - The SO is derived considering all effects, Peij per effect (probability that once a hazardi has occurred, it generates an effect with the severityj of
each hazard and the total number of hazards.)
• Semi-Quantitative Model - The SO is derived by considering the worst credible
effect per hazard, Peij per hazard and the number of hazards.
• Semi-Prescriptive Model - The SO is derived by considering the worst credible
effect, Peij , number of hazards per Severity Class and the airspace complexity.
• Fixed Prescriptive Model - The SO is derived by considering the worst credible
effect and airspace complexity.
The quantitative model was the chosen model for the derivation of the safety objectives for
being the most complete model. This model has some limitations that will be explained
throughout the model application illustration.
3.4.2
Qualitative Model
The quantitative model provides a full alignment with the risk definition, produces safety
objectives more precise and accurate, but also requires a lot of effort in the identification
of all the effects and probabilities.
Firstly, the Risk Classification Scheme (RCS) is derived from the national regulator’s
Safety Target specifications, shown in table 3.4, incorporating an Ambition Factor (AF)
of 10. The Ambition Factor is a number greater or equal to one that is used by the ATMSPs when setting their acceptable Safety Targets by dividing the tolerable Safety Targets
set by the National Regulator(NR) by this AF.[35]
18
Chapter 3. Context Study
Safety Target
ST1
ST2
ST3
ST4
ST5
National Regulator
maximum Safety Target(/fh)
1 E -8
1 E -5
1 E -4
1 E -2
n/a
Table 3.4: Specification of National Regulatory RCS[35]
Safety Target
ST1
ST2
ST3
ST4
ATMSP AF
10
10
10
10
(Max Safety Target /fh)
1 E -9
1 E -6
1 E -5
1 E -3
Table 3.5: Specification of ATMSP RCS[35]
The number of flight-hours per year of this ATMSP is 350000. Hence, the Safety Targets
(ST) can be converted to units of "per year" where:
ST(/year) = ST(/flight hour)* 350000(flight hours per year)
Severity of the effect
SC1
SC2
SC3
SC4
ATMSP Safety Target:
Maximum acceptable
frequency of occurrence
of an effect (/fh)
ST1 = 1 E -9 /fh
ST2 = 1 E -6 /fh
ST3 = 1 E -5 /fh
ST4 = 1 E -3 /fh
ATMSP Safety Target:
Maximum acceptable
frequency of occurrence
of an effect (/y)
ST1 = 35 E -5 /y
ST2 = 35 E -2 /y
ST3 = 35 E -1 /y
ST4 = 350 /y
Table 3.6: ATMSP RCS
Also, the system has the total hazards identified at the ATM service provision level (N),
the total hazards significantly contributing to any kind of STj (Nj ) and their likely effects.
For a particular hazard (Hazard A) the likely effects and their relative probabilities (Pe).
This probability is exemplified in the following figure.
Chapter 3. Context Study
19
Figure 3.3: Quantitative Model Hazard Safety Objective Example
The probability of a hazard leading to a certain effect can prove to be difficult to obtain
due to the mitigations that have to be taken into account. The best way to manage this
difficulty is to work with specialized software for those calculations.
After determining the probability the safety objective is calculated as showed in the previous example:
SOi = min (STj /Peij /Nj ) where j = (1,2,3,4,) is the Severity Class
So, in the case of the example, the maximum frequency of the hazard "A" has to be 7
E -1 occurrences year.
Chapter 3. Context Study
3.5
20
Safety Management
Although air accidents are rare events, less catastrophic incidents occur more frequently.
These less significant events may be harbingers of underlying safety problems. Ignoring
them could pave the way for an increase in the number of more serious accidents. Accidents and incidents cost money. An understanding of the total costs of an accident is
fundamental to understanding the economics of safety. The air transportation industry’s
future may well be predicated on its ability to sustain the public’s perceived safety while
traveling.
The hazards may either become evident after an accident or incident, or may be proactively identified through formal safety assessment before an actual safety event occurs.
Safety management is centered on a systematic approach to hazard identification and risk
management in the interests of minimizing the loss of human life and money through
pro-active measures.
Chapter 3. Context Study
Table 3.7: Requirements for Safety Management Systems[21]
21
Chapter 3. Context Study
22
Safety management is multidisciplinary domain, requiring the systematic application
of a variety of techniques and activities. It builds upon three defining cornerstones:
• A comprehensive corporate approach to safety, building upon a positive safety culture and embracing the organization’s safety policies, objectives and goals, and,
most importantly, senior management’s commitment to safety, always actively seeking to improve.
Table 3.8: Comparative benefits of a positive safety culture[17]
• A formal system for safety oversight. This is needed to confirm the organization’s
continuing fulfillment of its corporate safety policy, objectives, goals and standards.
• Organizational tools to deliver safety standards. Effective organizational tools are
needed to deliver the necessary activities and processes to advance safety.
3.6
Computational Support
Safety management is evidence-based, in that it requires the analysis of data to identify
hazards. Using risk assessment techniques, barriers and mitigations are set for reducing
the potential consequences of the hazards. Strategies to eliminate and mitigate the hazard
potential effects, are then developed and implemented with clearly established accountabilities. The situation is assessed on a continuing basis, and additional measures are implemented as required. The computational support to hazard management will make the
Chapter 3. Context Study
23
process more clear, agile, accessible, promoting collaboration and a better understanding
of safety culture.
3.7
Hazard Logging
A hazard that has not been identified cannot be controlled. Accordingly, an identified hazard that is not easily accessible will hardly be followed. Hazard Logs play an important
role in this last implication. They are most commonly defined as a collection of information about hazards relevant to the system, or product in question. It should act as a central
repository for the management and demonstration of on-going safety activities, containing information on all possible hazards, even ones that are not considered credible. Also,
it should contain the documentary evidence of risk handling, providing vital information
for the construction of safety cases.[3]
Safety cases are an important part of goal-based safety regulations and corporate governance. A safety case is a documented body of evidence that provides a convincing and
valid argument that a system is adequately safe for a given application in a given environment.
Despite the hazard logging activity importance within the safety management being utterly described by guidance material [4] [17], and authors, such as, Richard Maguire [3],
log report component’s description is scarce. Most times, the available material is superficial, miscellaneous and based on paper reports.
The lack of a central and reliable source of information about hazard logging during the
analysis phase, originated an cyclic process of bibliographic study and stakeholders revision, strongly guided by past difficulties, actual FHA reports information, shown in figure
3.6, and regulators requirements.
Chapter 3. Context Study
Figure 3.4: FHA report table example
24
Chapter 4
Project Development
4.1
Project Requirements
Requirements gathering was an essential part of this project, defining the needs and conditions required for the hazard logging and management system. Since NAV Portugal
did not presented a fully developed requirements specification, the requirements were assessed through a series of meetings with the stakeholders, analysis of existing hazard logs
and the study of international standards and requirements. The requirements were documented in the System Specification Document (DES) and approved by the reviewers and
stakeholders. The aim of DES is to document all of the requirements identified during the
analysis phase, translating them into the projects system specifications. This document
also has the goal of identifying all the needs for interfaces, performance, capacity, environment, use, reliability, safety, security, installation, quality and design constraints.
All the requirements were modeled with Enterprise Architect, an UML 2.1 team-based
modeling environment that embraces the full product development life-cycle, offering
high-performance visual tools for business modeling, systems engineering, enterprise architecture, requirements management, software design, code generation, testing and others. Enterprise Architect provides traceability of requirements, analysis and design models throughout the implementation and deployment phases.
Despite the tool’s usefulness, it proved itself very time consuming in the requirements
specification. Also, the existing Enterprise Architect template document had to be completely altered, so that the outcome document was in conformity with the NAV Portugal
rules.
This section summarizes the system requirements (fully documented in the System Specification Document, in the given Annex).
25
Chapter 4. Project Development
4.1.1
26
Users
Four main types of users, with different permission levels, were identified. The main
users are successive specializations of the administration, the user that has access to all of
the system’s functionalities.
4.1.2
Functional Requirements
Functional requirements define the functions of a system, or its component, describing
and capturing them in use cases. Each use case illustrates behavioral scenarios through
one or more functional requirements. For a better understanding, the functional requirements were divided into four modules:
• User Management - Groups all the functionalities related with user registration and
management.
• Hazard Environment Management - Groups all the functionalities related with the
management of hazard ancillary information, such as causes, conditions and barriers. This module helps relieving users from repeatedly writing by hand the same
information. Besides all the CRUD functions it was required more complex functions:
– All records had to be searchable by all the their characteristics, e.g. obtain the
list of all effects of severity 2.
– It was required to know how many hazards were associated with each barrier, cause, condition, mitigation, ESARR 04 severity and effect. It was also
needed to know how many occurrences were associated with each ESARR 02
severity or effect. This enables the user to see, for example, if an identified
effect with a severity 2 was identified in any occurrence.
• Hazard Management - Groups hazard management functionalities. These functionalities include hazard and occurrence addition, with direct addition of auxiliary
information, list filtering, or record removal. Besides all the CRUD functions it was
required more complex functions:
– Both hazards and occurrences had to be searchable by all the their characteristics and associated information to, for example, obtain the list of all the open
hazards for the Lisbon Tower with a certain barrier and mitigation or how
many hazards were identified in the last year for the Lisbon ATM. In the occurrence case, this functions can, for example, show the list all the occurrences
of a certain hazard this year.
– It was required to know how many barriers, causes, conditions, mitigations
and effect were associated with each hazard.
Chapter 4. Project Development
27
• Action Log - Set of functions that allow the administrator and the risk manager
to analyze and perform rollback actions to all the actions performed by the users.
This functions allow not only the user to be more at ease with the system, but
also, to acknowledge if any user is consistently adding or editing incoherently the
information.
In contrast with the Use Case Diagrams, the Use Case Descriptions capture variations of
a Use Case. In this project there are casual use descriptions, summarizing the use case in
a few paragraphs and fully dressed use cases based on a detailed template with fields for
various sections as shown in the next image.
Figure 4.1: Example of a formal use case description.
4.1.3
Non-Functional Requirements
Non-functional requirements specify constraints and features beyond the system operations. For a better understanding, the requirements were divided into several groups:
extensibility, maintainability, performance, quality, security and usability. A fully dressed
description is provided in annex.
The requirements were essential to define the contours of the application and adopted
Chapter 4. Project Development
28
technologies. All the decisions that arose from this requirements are explained in the
following chapters.
4.2
Data Model
One of the most important parts of this project is the definition of an abstract model that
described how hazard data is represented. These models formally define data elements
and relationships among data elements for a domain of interest.
4.2.1
Entity-Relationship Model
During the requirements analysis a conceptual representation of hazard information was
needed. The entity-relationship model (ERM) was the model chosen for its top-down
approach. This scheme evolved during the requirement gathering phase and it was very
useful in meetings, making it simple to understand and interact.
In the first versions of the model, all the information was very disperse representing all
the ideas and information known in each iteration, but without any real organization or
structure.
Chapter 4. Project Development
Figure 4.2: Early Entity-Relationship Model
29
Chapter 4. Project Development
30
As the information was consolidated more stable links were established and the final
structure began to form.
Each hazard affects only a system and a function, different systems have different hazards
with different probabilities of occurring. A hazard can be in three states, open if a hazard
still affects a system, closed if it does not affect any more or when a system is no longer in
use, or undefined if there is a doubt concerning its state. Also, as previously mentioned,
each hazard can have several cases, barriers and occurs in determined conditions.
For each hazard several mitigations can be defined. A department is responsible for carrying out mitigation till a closure date. By that time the status of that mitigation should
be closed.
The occurrences appeared in the model when the necessity for more information about
the hazard was felt. Each hazard can have several occurrences, but an occurrence is only
linked to a hazard. By having the abstract idea (hazard) and the materialization of that
idea (occurrence) it is easier to understand if the safety targets are being met, if the barriers and mitigations are being effective and if the real effects were the expected ones. Also,
new hazards can appear from occurrences they can not attribute a know hazard, being a
good indicator that this occurrence needs to be investigated.
When a hazard is linked to effects with a determined severity the safety objective is automatically calculated. The safety objective value is based on the qualitative model, as
explained in the section 3.4.2.
The occurrence only has the information important for hazard analysis, not containing
confidential information. For that reason there are to entities involved. The system user
responsible for writing the report on the system, and a person responsible for providing
the information,. That way for more detailed information they can contact the responsible
for the information.
4.2.2
Integrity Rules
Integrity rules ensure that data entered into the database are accurate, valid, and consistent.
Any applicable integrity constraints and data validation rules must be satisfied before
permitting any change to the database. During the modeling process, the domain, key,
entity and referential integrity were respected. This means that data predefined types are
respected, too distinct tuples of the same relation can not have the same key value, one
attribute that makes up the primary key can not be null and finally, in a relation, any
foreign key occurrence has to refer to an existent primary key of the other table.
Additional restrictions appeared during the modeling phase:
• In Department, name is candidate key; and in User, name and employeeNumber are
candidate keys.
• In the relation Hazard Effect, the attribute probability can only be filled if the for-
Chapter 4. Project Development
31
eign key is not null. In the Hazard Mitigation relation, the attributes status, closure
date, comment and author can only be filled if the foreign key is not null. In the
Occurrence Effect relation, the attribute comment can only be filled if the foreign
key is not null.
• The foreign key of Occurrence for User and Department can not have null values.
The foreign key of User for Department can not have null value. The foreign key
of Mitigation for Department can not have null value. The foreign key of Effect for
SeverityH can not have null values.
• The foreign key of Effect for SeverityO only may have value different from null
when the given Effect is associated with an Occurrence.
• For all the generalization occurrences, it has to exist an occurrence (ID) in at least
one of the sub-entities. For each occurrence of the generalization, it can only exist
on sub-entity (ID).
4.2.3
Relational Model
The relational model permits the database designer to create a consistent, logical representation of information.
• Causes(identification, description)
• Conditions(identification, description)
• Barriers(identification, description, probEfficacy)
• Mitigations(identification, description)
• Departments(acronym, name, description)
• SeverityH(classification, description)
• SeverityO(classification, description)
• SafetyObjClaSchema(identification, classification)
• User(userName, name, pass, email, permissions, Department.acronym)
• Effect(identification, SeverityH.classification, description)
• Hazard(identification, author, system, function, status, safObj, probability, commentH)
• Occurrence(identification, Hazard.identification, dDescription, description, dateO,
timeO, commentO, Department.acronym, reporter, User.id)
Chapter 4. Project Development
32
• HazardBarrier(Hazard.identification, Barrier.identification)
• HazardCause(Hazard.identification, Cause.identification)
• HazardCondition(Hazard.identification, Conditions.identification)
• HazardEffect(Hazard.identification, Effect.identification, probability )
• HazardMitigation(Hazard.identification, Mitigation.identification, author, responsible, statusM, closureDate, commentM)
• OccurrenceEffect(Occurrence.identification, Effect.identification, commentOE,
SeverityO.classification)
Chapter 4. Project Development
4.2.4
Database Model
Figure 4.3: Final Database Model
33
Chapter 4. Project Development
4.3
34
Architecture
Following the requirements gathering and data model definition phases, it was essential
to abstractly define the system’s structure.
The system architecture is a conceptual representation, based on the abstraction of different architectural details, which mainly intends to describe the structure of the system.
This chapter will address the choices made with regard to the systems architecture and
how this influenced the final solution, as well as why these decisions where taken. A
more in-depth view of the system architecture is provided in the implementation chapter,
along with particular details on the adopted technology.
One of the main architectural decisions that was made is the Web service approach incorporating the Model View Controller pattern. This approach besides all the inherent
advantages, also provides coverage of some of the non-functional requirements like, easy
interoperability between various software applications or Internet access for several users
with different types of system permissions.
4.3.1
Web services
One of the first choices made in regard to the system architecture was the adoption of
a Web-based architecture. This decision proved to be advantageous in terms of system
development and installation/configuration, due to its simplicity. If the architecture had
a traditional solution (thick client), additional steps would have to be taken in regard to
computer installation and configuration, in addition to the lack of platform and device
independence.
Web services provide interoperability between various software applications running on
disparate platforms and locations. Web Services use open standards, data formats and protocols that can be text-based, making it easy for developers to comprehend. By utilizing
HTTP, Web Services can work through many common firewall security measures without
requiring changes to the current firewall filtering rules. Web Services also promote the
reuse of services and components within an infrastructure.[31]
Chapter 4. Project Development
35
Figure 4.4: Platforms and devices
Despite the countless other benefits provided by Web services, there are also some disadvantages in terms of development. Due to lack of state of this type of architecture,
there are some difficulties in the system’s implementation and performance. Many of
these problems can be overcome using the concept of session, offered by programming
languages like Java. Sessions are a set of data temporarily stored on the client’s machine
that is sent to the server whenever the user performs an action, thus overcoming most of
the problems that are state related.
There are several ways to use Web Services, the three most common styles are RPC
(Remote Procedures Call), SOA (Service-Oriented Architecture) and REST (Representational State Transfer). This project uses REST, attempting to describe the architecture
using HTTP, with a set of well-known, standard operations like GET, POST, PUT and
DELETE. Although using HTTP, for communication, the services layer is completely independent of the HTTP protocol. This is achieved by creating a separate service layer
between the actual service and the web browser, which uses HTTP. This intermediate
layer is responsible for translating HTTP messages to an independent data format used
by the services layer. This separation enables other types of clients to easily access the
services layer by simply replacing the HTTP service layer.
Chapter 4. Project Development
36
Figure 4.5: Independent Data Layer
4.3.2
REST
REST-style architectures have clients and servers, where clients initiate requests to servers
and servers process requests and return appropriate responses to clients. Requests and responses are built around the transfer of "representations" of "resources". A resource can
be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a
resource. At any particular time, a client can either be transitioning between application
states or "at rest". A client in a rest state is able to interact with its user, but creates no
load and consumes no per-client storage on the set of servers or on the network.[44] The
client begins sending requests when it is ready to transition to a new state. While one or
more requests are outstanding, the client is considered to be transitioning states. The representation of each application state contains links that may be used next time the client
chooses to initiate a new state transition.[43]
REST was initially described in the context of HTTP, but is not limited to that protocol.
RESTful architectures can be based on other Application Layer protocols if they already
provide a rich and uniform vocabulary for applications based on the transfer of meaningful
representational state. RESTful applications maximize the use of the pre-existing, welldefined interface and other built-in capabilities provided by the chosen network protocol,
and minimize the addition of new application-specific features on top of it. The REST architectural style describes the following six constraints applied to the architecture, while
leaving the implementation of the individual components free to design:
• Client–Server - Clients are separated from servers by a uniform interface. This
separation of concerns means that, for example, clients are not concerned with data
storage, which remains internal to each server, so that the portability of client code
Chapter 4. Project Development
37
is improved. Servers are not concerned with the user interface or user state, so that
servers can be simple and scalable. Servers and clients may also be replaced as long
as the interface is not altered.
• Stateless - The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any state is held
in the client. The server can be stateful, this constraint merely requires that serverside state be addressable by URL as a resource. This not only makes servers more
visible for monitoring, but also makes them more reliable in the face of network
failures, as well as further enhancing their scalability.
• Cacheable - As on the World Wide Web, clients are able to cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable or
not to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server
interactions, further improving scalability and performance.
• Layered System - A client cannot ordinarily tell whether it is connected directly
to the end server, or to an intermediary server. Intermediary servers may improve
system scalability by enabling load balancing and by providing shared caches. They
may also enforce security policies.
• Code on demand - Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this
may include compiled components such as Java applets and client-side scripts such
as JavaScript.
• Uniform interface - The uniform interface between clients and servers, simplifies
and decouples the architecture, which enables each part to evolve independently.
The four guiding principles of this interface are detailed below.
The uniform interface between clients and servers that any REST interface must provide
is considered fundamental to the design of any REST service and has the following characteristics [44]:
• Identification of resources - Individual resources are identified in requests, for example using URIs in web-based REST systems. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server does not send its database, but rather, perhaps, some HTML, XML
or JSON that represents some database records expressed, for instance, in French
and encoded in UTF-8, depending on the details of the request and the server implementation.
Chapter 4. Project Development
38
• Manipulation of resources through these representations - When a client holds a
representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to
do so.
• Self-descriptive messages - Each message includes enough information to describe
how to process the message. For example, which parser to invoke may be specified
by an Internet media type (previously known as a MIME type). Responses also
explicitly indicate their cacheability.[45]
• Hypermedia as the engine of application state - If it is likely that the client will want
to access related resources, these should be identified in the representation returned,
for example by providing their URIs in sufficient context, such as hypertext links.
4.3.3
Model View Controller Pattern
Like many computer systems, the purpose of this project can be reduced to retrieve data
from a data store and display it for the user. After the user changes the data, the system
stores the updates in the data store. Because the key flow of information is between the
data store and the user interface, it is easy to tie them together to reduce the amount
of coding and to improve application performance.[42] However, this seemingly natural
approach has some significant problems:
• The user interface logic and business logic is separated, because interface logic
tends to change more frequently than business logic, especially in Web-based applications. For example, new user interface pages may be added, or existing page
layouts may be shuffled around. After all, one of the advantages of a Web-based
thin-client application is the fact that the user interface can be changed at any time
without having to redistribute the application. If presentation code and business
logic are combined in a single object, it is necessary to modify an object containing
business logic every time you change the user interface. This is likely to introduce errors and require the retesting of all business logic after every minimal user
interface change.[43]
• Designing visually appealing and efficient pages generally requires a different skill
set than does developing complex business logic. So it is desirable to separate the
development effort of these two parts.
• User interface activity generally consists of two parts: presentation and update. The
presentation part retrieves data from a data source and formats the data for display.
When the user performs an action based on the data, the update part passes control
back to the business logic to update the data.
Chapter 4. Project Development
39
• The user interface code tends to be more device-dependent than business logic.
If there is a need to migrate the application from a browser-based application to
support personal digital assistants (PDAs) or Web-enabled cell phones, much of the
user interface code must be replace, whereas the business logic may be unaffected.
A clean separation of these two parts accelerates the migration and minimizes the
risk of introducing errors into the business logic.
• Creating automated tests for user interfaces is generally more difficult and timeconsuming than for business logic. Therefore, reducing the amount of code that is
directly tied to the user interface enhances the testability of the application.[43]
The Model-View-Controller (MVC) pattern separates the modeling of the domain, the
presentation, and the actions based on user input into three separate classes[29]:
• Model - Manages the behavior and data of the application domain, responds to
requests for information about its state (usually from the view), and responds to
instructions to change state (usually from the controller).
• View - Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.
• Controller - Receives input and initiates a response by making calls on model objects. A controller in this web tier performs the interception of HTTP requests, from
the client, translates each request into a specific business operation to be performed,
then invokes the specific operation or delegates it to a handler, helps to select the
next view to be presented to the client and returns the view to the client.
Figure 4.6: Model View Controller diagram.[30]
Chapter 4. Project Development
4.4
40
Technologies
In order to attain the project’s requirements, and architecture a variety of technologies
were chosen. This decisions took into account that the technologies used had to be free,
enable the project’s evolution and data reliability and availability.
This chapter describes and discusses the decisions taken in regard to the chosen technologies. These technologies are represented in the following technology stack diagram.
Figure 4.7: Technology Stack Diagram
Chapter 4. Project Development
4.4.1
41
Google Web Toolkit
Google Web Toolkit (GWT) is an open source development toolkit, created by Google,
for building and optimizing complex browser-based applications. The major GWT components include a Java-to-JavaScript Compiler, GWT Hosted Web Browser, that allows
the developers to run and execute GWT applications in hosted mode, commonly used
for debugging, a JRE emulation library and a GWT Web UI class library, which is a set
of custom interfaces and classes for creating widgets. This allows AJAX applications
to be written in Java and when deployed, the GWT compiles the Java source code into
optimized, stand-alone JavaScript files that automatically run on all major browsers, as
well as mobile browsers for Android and the iPhone. Constructing AJAX applications
in this manner is more productive thanks to a higher level of abstraction on top of common concepts like Document Object Model (DOM) manipulation, a cross-platform and
language-independent convention for representing and interacting with objects in HTML,
XHTML and XML documents, and XMLHttpRequest (XHR) communication.[37]
Google Web Toolkit contains two powerful tools for creating optimized web applications. The GWT compiler performs comprehensive optimizations across codebase inlining methods, removing dead code, optimizing strings, and more. By setting split-points
in the code, it can also segment download into multiple JavaScript fragments, splitting up
large applications for faster start-up time. GWT emphasizes reusable, efficient solutions
to recurring AJAX challenges, namely asynchronous remote procedure calls, history management, bookmarking, Internationalization and cross-browser portability. Google provides a plug-in for Eclipse which handles most GWT related tasks in the IDE, including
creating projects, invoking the GWT compiler, creating GWT launch configurations, validations, syntax highlighting.[37]
4.4.2
Smart GWT and Smart Client
Smart GWT is an open source, GWT based framework, developed by Isomorphic Software, that allows, not only, to use its comprehensive widget library for application UI,
but also to tie these widgets in with the server-side for data management. Smart GWT is
based on the powerful and mature SmartClient library.[38]
SmartClient is a mature library that provides zero-install DHTML/AJAX client engine,
rich user interface components and services, client-server data binding systems. In SmartClient, all presentation duties, and all HTML generation, takes place in the browser. No
HTML generation or presentation duties are handled by the server.
Once a SmartClient application has been loaded, only data is transmitted between the
browser and server. By minimizing server contact, this architecture boosts responsiveness and scalability far beyond what is possible with server-side architectures such as
Chapter 4. Project Development
42
JSF. By minimizing the amount of server-side code, the architecture also improves stability and reliability. Other SmartClient features include object-oriented, JavaScript APIs, a
Model View Controller (MVC) architecture within the browser, which also provides performance and scalability benefits and SmartClient a metadata-driven approach, allowing
the use of standard sources of metadata, such as Java Beans or XML Schema, to configure
SmartClient components.[39]
4.4.3
JSON
The data format used in messaging is JSON which, is a lightweight data-interchange
format. This format is highly intuitive and easy for humans to read and write and very easy
for machines to parse and generate. It is based on a subset of the JavaScript Programming
Language, Standard ECMA-262 3rd Edition - December 1999.[32]
This data format is used for all the messages between the service layer and the HTTP
service layer and partially between th HTTP service layer and the browser.
4.4.4
Hibernate
Hibernate is an object-relational mapping (ORM) library for the Java language that provides a framework for mapping an object-oriented domain model to a traditional relational database. The most often mentioned Hibernate disadvantage is its steep learning
curve, but beyond that fact Hibernate presents several advantages in comparison with Java
Database Connectivity (JDBC) API[40]:
• Persistence for JAVA - Hibernate is flexible and has a powerful ORM solution to
map Java classes to database tables. Hibernate itself takes care of this mapping
using XML files so developers do not need to write code for this.
• Database Dependent Code - Using JDBC to handle persistent data leads to large
amounts of database specific code. The code written to map table data to application objects and vice versa actually serves to map table fields to object properties.
Hibernate provides this mapping itself. The actual mapping between tables and application objects is done in XML files. If there is a change in Database, or in any
table, then the is only a need to change XML file properties.
• Optimize Performance - Caching is retention of data, usually to reduce disk access. With Hibernate, cache is set to application work space. Relational topples are
moved to this cache as a result of query. Automatic Transparent Persistence allows
the developer to concentrate more on business logic rather than this application
code. With JDBC, caching is maintained by hand-coding.
Chapter 4. Project Development
43
• Automatic Versioning and Time Stamping - By database versioning one can be assured that the changes done by one person are not being rolled back by another one
unintentionally. Hibernate enables developers to define version type fields for applications, Hibernate updates version fields of database tables every time relational
topple is updated in form of Java class object to that table. So if two users retrieve
the same topple and then modify it and one user saves this modified topple to the
database, a version is automatically updated for this topple by Hibernate. When the
other user tries to save the updated topple to the database Hibernate does not allow
to save it because this user does not has updated data. In JDBC there is no check
that users have updated data. This check has to be done by the developer.
• Enterprise-Class Reliability and Scalability - Hibernate scales well in any environment, no matter if used in an in-house Intranet that serves hundreds of users or in
mission-critical applications that serve hundreds of thousands. JDBC can not be
scaled easily.
• Eclipse Integration Plug-in - To automatically generate Java code when the Hibernate mapping files are modified, Hibernate Synchronizer was also used. This is a
free Eclipse plug-in for code generation. With this plug-in, objects are created with
generated code in an abstract base class and a user-modifiable extension class. This
enables user code not to get deleted when the generation is performed.[41]
4.4.5
Session Management and Cookies
As already mentioned, due to the chosen stateless server architecture, sessions have to be
introduced in order to provide the minimum state required to ensure system functionality.
For every user that authenticates in the system, a session is created. That session holds
the user information, the last activity timestamp and a generated session id. Cookies are
used to store and notify the client about the chosen session id.
A cookie consists of one or more name-value pairs containing bits of information, which
may be encrypted for information privacy and data security purposes. The cookie is sent
as an HTTP header by a web server to a web browser and then sent back unchanged by
the browser each time it accesses that server. [36]
For security reasons, e.g. to prevent an unauthorized person to reuse an inactive session,
a timestamp is used. The timestamp holds the time of the last action and if that time is
greater than the maximum allowed the session becomes inactive and is removed by the
server.
Chapter 4. Project Development
4.4.6
44
User Privacy and Security
To prevent unauthorized access and ensure the user’s password privacy the bcrypt function is used.
Bcrypt is a cross platform file encryption utility. Encrypted files are portable across all
supported operating systems and processors. Passphrases must be between 8 and 56 characters and are hashed internally to a 448 bit key.[33]
4.5
Tests
Product validation and verification activities were accomplished during all the project life
cycle, from requirements validation until product acceptance, to achieve, as early, as possible the identification of problems, or inadequacies, thus reducing the impact of changes
caused by the need for corrections, or adaptations.
In order to achieve the validation and verification activities, a series of tests and documents were produced. Unitary, integration, acceptance and free tests were applied to the
application.
A Test Management Plan (TMP) was elaborated to describe the test activities described
in the Acceptance Tests Document (ATD), verifying the hazard logging and management
system compliance with the system requirements and specifications described in the System Specification Document (DES).
Also, to assist the development and testing phases, the code was commented, indicating
what product requirement was implemented and information related with the unit tests.
In the case of requirements validation/verification, the documents where revised taking
into account the received comments. During Unit Tests, or Integration Tests, if the result
differed from the expected one, all actions necessary for the correction of the problems
were carried out. The results of the Acceptance Tests were recorded.
Chapter 4. Project Development
4.5.1
45
Unit Tests
Unit testing refers to tests that verify the functionality of a specific section of code, usually done at the function level. In an object-oriented environment, this is usually at the
class level, and the minimal unit tests includes the constructors and destructors.[27]
The goal of unit testing is to isolate each part of the program and show that the individual
parts are correct. A unit test provides a strict, written contract that the piece of code must
satisfy.[28]
In this project, these tests were conducted using a top-down methodology. All components were tested using JUnit, which is a unit testing framework for the Java programming
language. JUnit is one of a family of unit testing frameworks collectively known as xUnit
that originated with SUnit, a unit testing framework for Smalltalk.
4.5.2
Integration Tests
The integration tests were conducted using a bottom-up testing approach, where the lowest level components were tested first, and then used to facilitate the testing of higher
level components. The process was repeated until the component at the top of the hierarchy were tested.
4.5.3
Acceptance Tests
The acceptance tests were made by the author, elements from NASO and Paula Santos, the
project coordinator. All tests were described in the Acceptance Tests Document (ATD).
All the non-functional requirements (with the exception of SAF_DB_DES_SECURITY_Users,
SAF_DB_DES_PERF _StartTime and SAF_DB_DES_AccessTime) were covered in the
free tests session.
46
Chapter 4. Project Development
Figure 4.8: Test Model
The test diagrams and specifications were generated from the information contained in a
database created and maintained using a UML modeling tool, Enterprise Architect and
organized in accordance with the functional requirements:
• User Management Tests - Groups all the functionality tests related with user registration and management. These tests include the creation of a new system user,
altering its information and removing it.
Chapter 4. Project Development
47
Figure 4.9: User Management Tests
• Hazard Environment Management Tests - Groups all the tests of functionalities
related with the management of hazard ancillary information, such as addition, edition and removal of causes, or barrier records. Also, was tested the link between
several tables, by adding a department directly from a mitigation form.
Chapter 4. Project Development
Figure 4.10: Hazard Environment Management Tests
48
Chapter 4. Project Development
49
• Hazard Management Tests- Groups all major functionalities tests. These tests include hazard and occurrence addition, management, filtering mechanisms and some
non-functional requirements.
Figure 4.11: Hazard Management Tests
Each individual test, known as a case, exercised a particular operating condition of the
user’s environment or feature of the system, and resulted in a pass or fail outcome without
Chapter 4. Project Development
50
any degree of success. The test environment was designed to be as close as possible,
to the anticipated user’s environment. These test cases were accompanied by a formal
description of the operational activities and expected results.
Figure 4.12: Example - Add Cause Acceptance Test Specification
4.5.4
Test Approval Criteria
The tests were successful if:
• All steps accomplished with success
The test were successful with deficiencies if:
• A non critical test step failed - one with no impact on the test goal
Chapter 4. Project Development
• The test result does not match the expected result but is acceptable
• A failure is detected which can not be attributed to any specific step
The test were unsuccessful if:
• None of the above criteria applied
51
Chapter 4. Project Development
52
Chapter 5
Implementation
5.1
Package Organization
The project development was divided in accordance with the Model-View-Controller pattern and each division contains several Java packages, as shown in the figure bellow.
To give a better understanding of the general package organization, each package is briefly
explained:
• client.view.menu - Classes used to represent the lateral menu tree.
• client.view.screens - Classes that implement all the interface screens.
• client.controller - All data verification methods. This methods are also shared
with the server in order to prevent inconsistency problems when changes need to
be made. All data added or edited to database passes through validation. The
validation process is partially made directly in the browser and if the validation
passes, remade in the server using the same validation code. In the server validation
is being made at the persistent object level, where each hibernate object calls for
validation whenever it is required. In the browser the validation class is enriched by
graphical elements.
53
54
Chapter 5. Implementation
Figure 5.1: Hazard Management Tests
• client.view.controller.handlers - The events handlers triggered by the user interaction.
• client.view.model - Contains all the dataSources. A DataSource is data-providerindependent description of a set of objects that will be loaded, edited and saved
within the user interface of the application only.
• server.hbm - Persistent objects that map the database tables. The server.hbm.base is
a sub-package where the abstract objects are automatically generated by Hibernate.
• server - Contains the HTTP and JSON communication layer, which are responsible
for colling the final service implementation.
• server.services - All the provided services are implemented in this package.
• server.util - All the generic methods shared by the services, like the Bcrypt and
email methods.
Chapter 5. Implementation
55
Figure 5.2: Quantitative Model Hazard Safety Objective Example
5.2
Web Services
This section describes more in depth all the system Web services, presenting their methods, parameters, responses and final application examples.
56
Chapter 5. Implementation
5.2.1
User Management
Despite user management not being the main focus of the project, one had to be implement
in order to have a functional system. The user management is divided in too parts. The
first is related with user authentication and session management, all implemented in the
Login service. The steps involved in the Login service can be partially seen in the login
activity diagram bellow.
Figure 5.3: Login Screen
57
Chapter 5. Implementation
Figure 5.4: Login Activity Diagram
The second user management part is the user information management. The information
management has functions, such as adding new users, updating their information and
removing them from the system. When a new user is added the system sends an email to
the user with the user name and a temporary password that has to be changed in the first
login. Each user has different system permission, as defined in the requirements, that can
only be changed by the systems administration.
Figure 5.5: Add User Screen
58
Chapter 5. Implementation
Due to the Log service a user can only be deleted if it never did any action that changed
the data base state. This decision enables the system to maintain a consistent state.
5.2.2
Data Management
The data management is the project’s main focus. The information is handled through
a series of user interfaces that enable the user to add, edit, remove and link database
information. The information is divided in to too categories, the hazard’s environment
information and hazard’s management information. The environment information is auxiliary information that is could be manually introduced every time a hazard was added.
This avoids consistency problems, relieves the user and enables the gathering of statistical
information, such as, how many hazards have a certain effect.
Figure 5.6: Add Effect Screen
The activity diagram bellow shows an example of steps taken to add an effect and link it
to a new severity. In the case of the hazard and occurrence addition, the process is more
complex, involving more information.
Chapter 5. Implementation
59
Figure 5.7: Add record activity diagram example
To ease information listing and searching a filter and ordering functions have been implemented across all screens. This enables the user to use various parameters at the same time
in a simple way to obtain the desired results. To achieve the performance requirements
a lazy list fetching mode was implemented, enabling the system to send only a small set
of results each time the user scrolls through the list. Also, the user can chose which list
columns it wants to see.
Chapter 5. Implementation
60
Figure 5.8: View Record Content Screen
When records are to be removed from the system they can not be linked to any other
record. To remove a linked record every link has to be eliminated before the record can
be remove, preventing data inconsistencies. This process is shown in the record remove
activity diagram bellow.
Chapter 5. Implementation
Figure 5.9: Remove Record activity Diagram Example
Figure 5.10: Remove Record activity Diagram Example
61
Chapter 5. Implementation
The main update process steps are defined in the activity diagram bellow.
Figure 5.11: Update Record Activity Diagram Example
62
Chapter 5. Implementation
5.2.3
63
Log Management
Due to information value a Log Management service has been implemented for the administration, that keeps record of every user action that changes the database state in any
way. This given the user more confidence to use the system and at the same time protects
the information.
The user can navigate between system states in read only mode and when the user finds
the desired state, confirms the state change and the system unlocks the database read only
mode, deleting all the onward log entries.
Figure 5.12: Change System State Screen
Chapter 5. Implementation
64
Chapter 6
Results
This project has met all its initial goals arousing international interest. The developed
solution enables the registration of hazards and associated information, such as mitigation actions, acceptable frequency of occurrence, recorded occurrences and their impacts.
This solution, at any time, shows reports on what hazards are associated with a given
system, how they may be mitigated and if the hazards frequency of occurrence is within
the defined range. Also, the solution includes a user management, login and data backup
modules to ensure the projects main goals were accomplishment.
In terms of software development, the solution was developed according to functional
requirements, but also to non-functional requirements, such as, a good capability of integration with other systems and use stable available open source technologies, that ensured
data reliability, availability and maintainability.
Alongside the production of an hazard management and logging system, this project produced the required documentation that ensured all decisions were documented, justified
and evaluated.
During the nine months internship was possible to put in practice the knowledge learned
in the university and be in contact with new technologies such as GWT and SmartGWT,
work in an service oriented architecture integrated in an well structured quality ensured
professional environment. The project, also, gave the opportunity to have independence
while refining, in a work environment, activities, such as, Business Process analysis, requirements gathering and analysis, Functional Specification Documentation development,
Business Requirements definition, Business/Use cases development, Test Cases and Test
Scenarios creation, System Design, Architecture and Technology definition, solution development. This area is very stimulating, still very paper based and i think computer
science can make a real impact in the work process.
The main project’s difficulty was the accomplishment of all the projects goals in the stip65
Chapter 6. Results
66
ulated time, due to its complexity and the fact that there are not similar projects available
to compare and obtain information.
This internship was extended to an year to develop other functionalities that are not
covered in this report, such as list printing or database saving points for FHA reports
record. This application can evolve together with the organization, extending its functions to work, for example, with fault trees, or give more complex statistical report.
This project, also, gave the opportunity to work and participate in international meetings
with EUROCONTROL members that gave the chance to present the project and raise
international interest. The project will be officially presented to international entities in
September.
Chapter 6. Results
68
Glossary
ACC
AF
AIM
ATC
ATD
ATM
Area Control Center
Ambition Factor
Aeronautical Information Management
Air Traffic Control
Acceptance Test Document
Air Traffic Management
CANSO
CNS
Civil Air Navigation Services Organization
Communications, Navigation and Surveillance
DES
DOM
DOPLIS
DSTI
System Specification Document
Document Object Model
Unified Software Development Process
Department of Systems and Information Technology
ERM
ESARR 2
Entity-Relationship Model
EUROCONTROL Safety Regulatory Requirement 2
ESARR 4
EUROCONTROL Safety Regulatory Requirement 4
EUROCONTROL European Organization for the Safety of Air Navigation
FHA
FIR
Functional Hazard Assessment
Flight Information Regions
GWT
Google Web Toolkit
ICAO
IM
IRS
International Civil Aviation Organization
Installation Manual
Interface Requirement Specification
JDBC
Java Database Connectivity
LISATM
Lisbon Air Traffic Management System
69
70
Glossary
MVC
Model View Controller
NAV
NR
Navegação Aérea de Portugal
National Regulator
OH
ORM
Operator’s Handbook
Object-Relational Mapping
Pe
POP 20
Probability
Operational Process for System Development
Service Provision
QMS
Quality Management Systems
RCS
REST
RPC
Risk Classification Scheme
Representational State Transfer
Remote Procedure Call
SAS
SC
SISINT
SISLOG
SISPRO
SISQUA
SISQUA
SMS
SO
SOA
ST
System Architecture Specification
Severity Class
NAV-DSTI- Tests and User Interfaces Area
NAV-DSTI- Logistics Area
NAV-DSTI-Production Area
NAV-DSTI-Quality and Safety Management
Systems Area
Quality and Safety Management Systems
Safety Management System
Safety Objective
Service-Oriented Architecture
Safety Target
TMP
Test Management Plan
USDP
Unified Software Development Process
Bibliography
[1] ATECH – Tecnologias Críticas, Aeroporto de Congonhas Saguão Central, São
Paulo, Brasil
[2] Neil Story, “Safety-Critical Computer Systems”, Prentice Hall, 1996
[3] Richard Maguire, “Safety Cases and Safety Reports”, Ashgate Publishing Company,
December 2006
[4] Eurocontrol, EATM, “Safety Management Handbook”, first edition, September
2005
[5] Sun
https://www.suntrainingcatalogue.com/
eduserv/client/loadCourse.do;jsessionid=
687480B928FCF12227FCC16AD4F8F7B9.tomcat2?coId=hu_HU_
MED-RUP01&coCourseCode=MED-RUP01&l=hu_HU
[6] NAV - Safety http://www.nav.pt/default.aspx?CSeccao=5
[7] NAV http://www.nav.pt/default.aspx?CSeccao=1
[8] Scott Kendall, "The Unified Process Explained", ISBN 0-201-74204-7, 2002
[9] Wikipedia-Unified Software Development Process
http://upload.wikimedia.org/wikipedia/en/0/05/
Development-iterative.gif
[10] Eirik Albrechtsen, "Security vs Safety", Norwegian University of Science and Technology, Department of Industrial Economics and Technology Management, 2003
[11] Nancy G. Leveson, "Safeware, System Safety and Computers", Addison Wesley,
ISBN 0-7506-7689-2, fifth edition, 2001
[12] Armando Rocha, "Manual da Qualidade", NAV Portugal E.P.E., MQ, version 7,
2001
http://www.nav.pt/Ficheiros/12.NAVPortugal_Manual_da_
qualidade.pdf
71
Bibliography
72
[13] Chris Johnson,Glasgow Accident Analysis Group, "Recommendations for Air
Navigation Systems Software", version 1.0
http://www.dcs.gla.ac.uk/~johnson/Eurocontrol/software/
ESARR6_faq01.doc
[14] Department of Energy, Office of Operating Experience Analysis, "Hazard and
Barrier Analysis Guidance Document", 1996
http://mentalmodels.mitre.org/cog_eng/reference_
documents/hazard%20and%20barrier%20analysis%20guide.pdf
[15] EUROCONTROL, Safety Regulatory Requirement 4, "Risk Assessment and
Mitigation in ATM", first edition, 2001
http://www.eurocontrol.int/src/gallery/content/public/
documents/deliverables/esarr4v1.pdf
[16] EUROCONTROL Safety Regulatory Requirement 2, "Severity Classification
Scheme for Safety Occurrences in ATM", first edition, 1999
http://www.eurocontrol.int/src/gallery/content/public/
documents/deliverables/esarr2_awareness_package/
eam2gui1e10ri.pdf
[17] International Civil Aviation Organization, "Safety Management Manual (SMM)",
Doc 9859 AN/460, first edition, 2006
http://www.icao.int/fsix/_Library/SMM-9859_1ed_en.pdf
[18] EUROCONTROL, Safety Assessment Methodology,"Guidance Material: Risk
Classification Scheme", SAF.ET1.ST03.1000-MAN-01-01-03-E, second edition
[19] EUROCONTROL, Safety Assessment Methodology,"Guidance Material: Safety
Objective Classification Scheme", SAF.ET1.ST03.1000-MAN-01-01-03-F, second
edition
[20] EUROCONTROL, Safety Assessment Methodology,"Guidance Material: Methods For Setting Safety Objectives", SAF.ET1.ST03.1000-MAN-01-01-03-G, second
edition
[21] EUROCONTROL, ESARR Advisory Material,"ESARR 3 Guidance to ATM Safety
Regulators", EAM3/GU1, first edition, 2001
[22] Santos, Paula Luísa Costa Teixeira, "Procedimento Operacional - Análise do Sistema", PO-20.22, version 3
[23] Schäbe, H., "The Safety Philosophy Behind the CENELEC Railway Standards",
TÜV Intertraffic, GmbH, Köln, Germany, 2002
Bibliography
73
[24] Antunes, Pedro Alexandre, "Factores Humanos", Interfaces Pessoa Máquina, Science Faculty of Lisbon, 2006
[25] Reason JT., "Human Error", Cambridge University Press, 1990
[26] Reason JT., "Human error: models and management", BMJ. 2000;320:768-770
[27] Binder, Robert, "Testing Object-Oriented Systems: Objects, Patterns, and Tools",
Addison-Wesley Professional. p. 45. ISBN 0-201-80938-9, 1999
[28] Kolawa, Adam; Huizinga, Dorota, "Automated Defect Prevention: Best Practices in Software Management", Wiley-IEEE Computer Society Press. p. 75. ISBN
0470042125, 2007
[29] Burbeck, Steve. "Application Programming in Smalltalk-80: How to use ModelView-Controller (MVC)", University of Illinois in Urbana-Champaign (UIUC)
Smalltalk Archive
[30] Sun Java, Model-View-Controller
http://java.sun.com/blueprints/guidelines/designing_
enterprise_applications_2e/app-arch/app-arch2.html
[31] Ethan Cerami, "Web Services Essentials", O’Reilly & Associates, fist edition, 2002
[32] JSON
www.json.org
[33] Bcrypt
http://bcrypt.sourceforge.net/
[34] Fielding talks about application states
http://tech.groups.yahoo.com/group/rest-discuss/
message/5841
[35] EUROCAE WG-64, ED-125, "Process for Specifying Risk Classification Scheme
and Deriving Safety Objectives in ATM", EUROCAE ED-125, 2009
[36] Wikipedia - Cookie
http://en.wikipedia.org/wiki/HTTP_cookie
[37] Google Web Toolkit
http://code.google.com/webtoolkit/
[38] Smart GWT
http://code.google.com/p/smartgwt/
Bibliography
74
[39] Smart Client
http://www.smartclient.com/
[40] Hibernate
http://www.hibernate.org/
[41] Dipti Phutela, "Hibernate Vs JDBC", Mindfire Solutions
http://www.mindfiresolutions.com/mindfire/Java_
Hibernate_JDBC.pdf
[42] Cavaness, Chuck, "Building web applications with Servlets and JSPs", O’reilly,
ISBN 0-596-00651-9, Second Edition, 2004
[43] James Holmes, "The Complete Reference Struts," McGraw-Hill, ISBN 978-0-07226386-2, Edition 2, 2007
[44] Wikipedia - REST
http://en.wikipedia.org/wiki/Representational_State_
Transfer#cite_note-Fielding-Ch5-0
[45] Chapter 5 of Fielding’s dissertation "Representational State Transfer (REST)"
http://www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.html