TDT4735 System Development
Identifying the risks involved in the
design of a safety-critical system for
an Urban Search and Rescue robot.
Jean Paul Franky Friquin
c December 19, 2005
!
Supervisor: Professor Tor Stålhane
Adviser: Siv Hilde Houmb
Faculty of Information Technology, Mathematics and Electrical
Engineering
Department of Computer Science and Information Technology
Norwegian University of Science and Technology
Trondheim, Norway
Abstract
This report 1 describes the qualitative research to identify the requirements in
building a safety-critical system for an Urban Search and Rescue Robot(USAR).
The approach used in this research is the case study of a USAR robot model
searching for survivors on a one-floored-level building. The robot model is built
of Lego Mindstorms parts and equipped with a camera relaying real-time images to
a workstation. This document summarises the development life cycle of a safetycritical system based on the international standard IEC 61508 for safety-related
systems, and CORAS standard platform for risk assessment. The PHA and HazOp
analyses carried out to identify and analyze the risks are presented as well some as
an insight into the implementation of the robot model.
keywords: rescue, USAR, robotics, safety, safety-critical system, security, risk, Risk
Management, hazard, PHA, HazOp, IEC 61508, CORAS, Lego Mindstorms.
1
i
Preface
This report documents the work done in the course TDT4735 Software
Engineering, an indepth study course at the Norwegian University of Technology
and Science(NTNU). The course is part of the ninth semester of the Masters degree
programme at the Department of Computer and Information Science, IDI. This
report has been written using the MiKTeX version of LATEX.
I would like to thank my supervisor Prof T.Stålhane at the System Engineering
Group at IDI for general guidance and help in carrying out the PHA and Hazop
analyses. I extend my gratitude to Siv Hilde Houmb for invaluable feedback and
support throughout the course and providing me with relevant literature and contact
persons. I would also like to thank PhD candidate Pavel Petrovic for helping me with
the implementation of the system, Prof. Tore Lindmo from the physics Department
at NTNU for advice on the physical setup of the robot and PhD candicates Per
Trygve Myhrer and Jon Arvid Børretzen for their contribution in the brainstorming
sessions.
December 19, 2005
Trondheim, Norway.
Jean Paul Franky Friquin
iii
Contents
Preface
iii
Table of Contents
v
1 Introduction
1
1.1 Motivation and background . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 Project context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4 Objective of this work . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.5 Report outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Pre-study
7
2.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2 Management of risks, safety and security . . . . . . . . . . . . . . . . 10
2.3 Tools for Risk analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Lego Mindstorms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 RCX’s programming environment . . . . . . . . . . . . . . . . . . . . 28
3 Requirement Specification
31
3.1 Description of the system . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Use cases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . 41
v
4 Risk Analysis
43
4.1 Concept and Overall Scope definition . . . . . . . . . . . . . . . . . . 43
4.2 Preliminary Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Risk Interpretation and Classification . . . . . . . . . . . . . . . . . . 44
4.4 Safety Requirements Specification . . . . . . . . . . . . . . . . . . . . 46
5 Design
57
5.1 Functional requirements evaluation . . . . . . . . . . . . . . . . . . . 57
5.2 Risk management process - Step 5 Design. . . . . . . . . . . . . . . . 60
5.3 Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4 System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Implementation
67
6.1 Choosing a programming environment . . . . . . . . . . . . . . . . . 67
6.2 Physical assembly of Usario . . . . . . . . . . . . . . . . . . . . . . . 69
6.3 Physical setup of site . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.4 Programming Usario . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7 Results
77
8 Own contribution
79
8.1 RCX communicating through wireless ethernet . . . . . . . . . . . . . 79
9 Conclusion and further work
81
9.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.2 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A List of Abbreviations
83
B PHA introduction
85
C PHA presentation
95
vi
D PHA Session sheet
99
E Hazop introduction
103
F Hazop Session Sheet
117
Bibliography
127
vii
List of Figures
1.1 Model of the site with robot navigating . . . . . . . . . . . . . . . . .
3
2.1 The Risk Management Process of AS/NZS 4366 [20] . . . . . . . . . 12
2.2 The Safety-security life cycle [13] . . . . . . . . . . . . . . . . . . . . 13
2.3 Diagram illustrating the relationship between safety and security. . . 19
2.4 An example of a Fault Tree. . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 The RIS 2.0 kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 The Robotics Command Explorer . . . . . . . . . . . . . . . . . . . . 23
2.7 The IR communications tower . . . . . . . . . . . . . . . . . . . . . . 23
2.8 The touch sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9 The light sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.10 The motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.11 The Lego Vision Command . . . . . . . . . . . . . . . . . . . . . . . 27
2.12 The Dlink wireless internet camera . . . . . . . . . . . . . . . . . . . 27
3.1 Illustration of the USAR model on a one-floor building. . . . . . . . . 33
4.1 FTA for WLAN communication disruption. . . . . . . . . . . . . . . 50
5.1 UML 2 deployment diagram for Usario . . . . . . . . . . . . . . . . . 62
5.2 Diagram showing the actors and their communication flow. . . . . . . 64
5.3 Overall architecture of the system. . . . . . . . . . . . . . . . . . . . 65
6.1 Front view of Usario . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2 Back view of Usario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
ix
6.3 Side view of Usario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4 Top view of Usario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5 The experiment site . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6 Screen shot of user program showing two humans detected . . . . . . 75
6.7 Screen shot of user program . . . . . . . . . . . . . . . . . . . . . . . 75
8.1 Input/output port of DCS5300G [49] . . . . . . . . . . . . . . . . . . 80
x
List of Tables
2.1
factors affecting choice between analog and digital cameras . 26
2.2
Comparison between analog and digital cameras . . . . . . . . 26
3.1 short description of main use cases . . . . . . . . . . . . . . . . . . . 35
3.2
Use Case 1 - Logging in into the system . . . . . . . . . . . . . 35
3.3
Use Case 2 - On/Off RCX . . . . . . . . . . . . . . . . . . . . . . 36
3.4
Use Case 3 - On/Off camera . . . . . . . . . . . . . . . . . . . . . 36
3.5
Use Case 4 - Detect objects . . . . . . . . . . . . . . . . . . . . . 37
3.6
Use Case 5 - Identify objects . . . . . . . . . . . . . . . . . . . . 37
3.7
Use Case 6 - Determine status . . . . . . . . . . . . . . . . . . . 37
3.8
Use Case 7 - Follow line . . . . . . . . . . . . . . . . . . . . . . . 38
3.9
Use Case 8 - RCX sending message to PC program . . . . . . 38
3.10 Use Case 9 - PC program sending message to RCX . . . . . . 39
3.11 Use Case 10 - Camera sending message to PC program . . . 39
4.1
Likelihood of occurence . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2
Severity of consequence . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3
Interpretation of risk classes from IEC61508 . . . . . . . . . . 46
4.4
Classification of risks from IEC61508 . . . . . . . . . . . . . . . 46
4.5
The safety requirement specification . . . . . . . . . . . . . . . . 47
4.6
The identified safety nodes in the safety-related system. . . . 49
4.7
Risk level of each safety nodes (part 1 of 2) . . . . . . . . . . . 51
4.8
Risk level of each safety nodes (part 2 of 2) . . . . . . . . . . . 52
xi
4.9
Critical Risks to be treated . . . . . . . . . . . . . . . . . . . . . 53
6.1 The lego parts used. . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2 Internet camera network settings . . . . . . . . . . . . . . . . . . . . 74
6.3 Table showing appropriate system files in appendix . . . . . . . . . . 74
xii
Chapter 1
Introduction
1.1
Motivation and background
Natural disasters and catastrophes are of those events that leave unforgettable scenes
of misery. The consequences are scenes of tragedies leaving a consequent number of
casualties at the affected sites. They have considerable and non-negligible impact
on the lives of the people. Earthquakes, avalanches, floods, cyclones, tornadoes and
more recently tsunamis, or even airplane crashes, explosions like in the recent waves
of terror in London [41], the United States [42], Bali,Indonesia [43] or the middleeast [44] are a few of them. In the seconds following those tragic events, collapsed
buildings, landslides, injured people, dead bodies and fire are standard scenes of
desolation. Human lives are lost, some are left stranded, habitats and building
institutions are completely wiped out or reduced to ruins. In such emergency
situations, different groups of people are deployed in an attempt to attend to the
survivors as quickly as possible. Policemen, firemen, medical staff and others,
cooperate to save lives and to protect structural infrastructures as they evacuate
victims to safety. They make quick decisions under stress and try to get victims to
safety at their own risk. They must gather information about the location and status
of victims and the stability of the structures as quickly as possible so that medical
teams and fire fighters can enter the disaster site and help the victims. Traditionally,
all of these tasks are performed mostly by humans and trained dogs, often in very
dangerous and risky situations. However, the World Trade Center disaster on the
11th of September, 2001 [42] saw the use of “Urban Search And Rescue” (section 2.1)
robots in rescue operations [34]. Since then, more mobile robots have been proposed
to help and to perform tasks that neither humans, dogs nor existing tools can do.
Therefore, there is a need for specially developed robots that can give rescuers that
extra edge in their quest for saving lives.
1
2
1.2
CHAPTER 1. INTRODUCTION
Project context
This project gives an insight of the risks involved in the development of software
for Urban Search and Rescue robots. An empirical research method is carried out
to establish a preliminary list of safety and security specifications that need to be
satisfied in the development of software for USAR robots.
The case study model is a robot capable of navigating around a site, and
reporting the position of eventual survivors to a server machine. The model
simulates a search and rescue operation. It is built mostly of Lego Mindstorms
components which will search, detect and locate human beings scattered around
the site. The disaster scene is re-created to a smaller scale using cardboard for the
walls (see implementation- Physical setup of site, section 6.3), Lego bricks or other
objects representing debris and upturned furniture, and one or more humans (dead,
injured or trapped), represented by specific and predetermined coloured bricks. Fig
1.1 illustrates the arena in which the model robot will be performing. The robot will
be moving in an anticlockwise direction, visiting all rooms around the site. It has to
distinguish between different objects in its vision and identify humans (represented
by small toy figures), and report back to a server machine their respective locations.
The robot should have sufficient autonomy to move around the disaster site providing
a realtime image and sound of the scene, together with some path recognition
intelligence. Wireless technology will be extensively used as communication channel
between the robot and client/server machine.
1.3
Problem definition
In a real case environment, the conditions at a disaster area are extreme with many
unknown parameters. Under such circumstances, the robot will be subject to a series
of hazards and risks that might affect its performance. Victims may be covered in
debris and somehow trapped in between objects, which decreases the robot’s chances
for detection and rescue. Communication with the server might suddenly drop or
even be lost. Hackers might break into the robotics software system thus jeopardizing
the entire rescue operation.
Therefore, critical safety and security measures have to be implemented to
avoid such situations and ensure the safe running of the operation. The rescue
robots must detect and report the position of ALL human beings (either dead or
alive). The chances for communication failure between the robot and the operator
has to be reduced to a minimum. The system has to be shielded against malicious
attacks.
1.4. OBJECTIVE OF THIS WORK
Figure 1.1: Model of the site with robot navigating
1.4
Objective of this work
The objective of this project is to
3
4
CHAPTER 1. INTRODUCTION
1. investigate the safety aspects of a USAR robot.
2. establish a preliminary list of safety specifications that need to be satisfied in
developing safety-critical systems for USARs.
A robot model (later named ‘Usario’) will be built to give further insight of a
USAR robot in a rescue operation. The model will be a semi-autonomous mobile
robot with hardware components (mechanics, electronics and sensors) and software
systems (user interfaces and navigation, planning and coordination module).
1.5
Report outline
This section provides an overview of the 9 chapters of this report document, each of
which are described below.
Chapter 1: Introduction. This chapter introduces this report with the
scope, objectives and problem definition.
Chapter 2: Pre-study. This chapter explores the existing USAR robots
and organisations dealing with rescue robotics. The technical equipment used in
the robot model is presented. The chapter also includes an introduction to hazard
analysis and the management of risks.
Chapter 3: Requirement specification. This chapter presents the
requirements of the robot model. Use case scenarios and both functional and nonfunctional requirements are presented.
Chapter 4: Risk Analysis. This chapter describes and evaluates the PHA,
Hazop and the FTA.
Chapter 5: Design. This chapter presents an evaluation of the requirements
specification, the design of the system and an architecture of the sytem.
Chapter 6: Own Contribution. This chapter describes the findings about
an alternative communication medium between the RCX and the camera.
Chapter 7: Implementation. This chapter describes and evaluates the
choice of a programming language. It also describes the physical asembly of the
1.5. REPORT OUTLINE
5
robot and concludes with the physical site up of the site.
Chapter 8: Results. This chapter lists the risks involved in the design of a
USAR robot.
Chapter 9: Conclusion and further work. This chapter discusses areas
for further work and concludes the project.
Chapter 2
Pre-study
This chapter explores the background behind USAR robots. In section 2.1 Related
work, an overview of the main actors in the industry is presented. Section 2.2,
Risk management highlights the key concepts for risk analysis in terms of safety
and security. This also includes two sets of terminologies for terms used in this
report, along with a general comparison between safety and security. Finally,
a description of the most common Lego Mindstorms parts, the communication
technology used and a description of the avaialable programming environments,
conclude this chapter.
2.1
Related work
Urban Search And Rescue (USAR) robots. Boosted by the positive
contribution of robots in the World Trade Center disaster, search and rescue robotics
is increasingly gaining interest from both academia and industry. Presently, there are
numerous private companies, universities and some government institutions that are
actively involved in the development of USAR robots. The first part of this section
(section 2.1.1) presents a list of some of the main actors in the field. This is by no
means an exhaustive list and there are several other relevant USAR robots available.
The second part (section 2.1.2) highlights some robotics competitions intended for
the general public, together with some groups of interest.
2.1.1
USAR robot development
USAR robot builders can be divided into three distinct groups; university researchers, private companies (here referred to as the ‘industry’) and government
7
8
CHAPTER 2. PRE-STUDY
institutions. All three are introduced below.
University research:
1. The University of South Florida, through its Center for Robot-Assisted Search
and Rescue(CRASAR) developed a USAR robot to assist first-aid workers by
providing sound and images of places where dogs and/or humans cannot reach.
The robot was first used during the World Trade Center disaster, but had
unfortunately neither found nor rescued any survivor. However, it has shown
some great potential as described in the National Geographic article [34].
2. Carnegie Mellon University’s National Robotics Engineering Consortium
(NREC), a part of the Robotics Institute in the School of Computer Science,
has contributed a lot in the field of robotics. In February 2005, they
completed a highly successful prototype development program that validated
their technology which included conducting mobility and scout demonstrations
of their system, which is known as the Gladiator Tactical Unmanned Ground
Vehicle (GTUGV) [38]. In these demonstrations, the Gladiator prototype met
all key system performance parameters, as well as other critical requirements.
3. As early as in 1995, Kobe University from Japan had their Utility Vehicle
for Search (UVS), involved during the Hanshin-Awaji earthquake. The
UVS consists of several homogeneous small robots linked together and
that can climb over obstacles. They have also developed a simulator for
Robocup-Rescue (see section 2.1.2), a simulation league that focuses more on
coordination rather than victim detection and issues individual robots must
solve [39].
Industry:
1. iRobots Corporation [31] is a private-owned company that develops robots
for both the consumer market and the military. The military R-gator and
packbot are their two most relevant contributions in USAR robots category.
2. Inuktun Services Ltd [32] is a canadian company that manufactures and
markets steerable crawler robots. These robots are equipped with cameras
and crawlers which provide detailed video output using variable lighting with
pan, tilt and zoom controls.
Government institutions:
1. The NASA is a pioneer and key leader in the development of robotics. It
has developed, among other robots, Urbie to investigate urban environments
contaminated with radiation, biological warfare, or chemical spills [33].
2.1. RELATED WORK
9
2. The United States Department of Defence is a big player in the robotics market. In many of its key robotics programs, the United Defense Incorporation is
the sole-source prime contractor and systems integrator [40]. The department
also hires and contracts other companies.
2.1.2
Robotics competitions
• The RoboCup Soccer competition, founded in 1995 is an international
research and education effort. Its purpose is to foster Artificial Intelligence
(AI) and robotics research by providing a standard problem where a wide
range of technologies can be integrated and examined. The ultimate goal of
RoboCup is that by the middle of the 21st century, a team of fully autonomous
humanoid robot soccer players shall be able to play a soccer game against
human world champions[35]. The first edition of the competition took place
in 1997 in Japan, and has since been held every year.
• RoboCup Rescue project is a contest that focuses on the use of robotics
as an aid in rescue operations. Its intention is to promote research and development in disaster rescue by involving multi-agent team work coordination,
physical robotic agents for search and rescue, information infrastructures,
personal digital assistants, standard simulator and decision support systems,
evaluation benchmarks for rescue strategies and robotic systems that are all
integrated into a comprehensive system in the future [35].
RoboCup Rescue is a child competition of RoboCup Soccer that started in
2001 [36]. It is divided into three leagues:
1. The RoboCup Rescue Robot League is a competition entirely
devoted to designing, building and programming of semi-autonomous and
autonomous USAR robots.
2. The RoboCup Rescue Simulation League is a competition that
focuses on group coordination during disaster rescue operations. A
generic urban disaster simulation environment is constructed on network
computers and every participant cooperates with many others, most often
from other disciplines, to coordinate and conduct a rescue operation.
3. Robocup Junior is a project-oriented educational initiative that sponsors local, regional and international robotic events for young students.
It is designed to introduce RoboCup to primary and secondary school
children, as well as undergraduates, who do not have the resources to
get involved in the senior leagues. The focus in the Junior league is on
education and it is divided into three categories: soccer, dance and rescue
[37].
10
CHAPTER 2. PRE-STUDY
2.2
Management of risks, safety and security
The main objective of an USAR robot during a rescue operation is to detect and
report the location of survivors as a complementary aid to rescuers. However, during
this period of time, the robots are faced with uncertainty and risks, as very few of
them operate in a risk free environment. The use of good risk management strategies
and tools can therefore influence the outcome of the operation. By identifying,
assessing and controlling the risks involved, one creates a sense of confidence and
safety about the operation. Therefore risk, safety and security management are
concrete issues that have to be dealt with to ensure the proper running of the
operation, and an overview of which, is presented in the next sub-sections.
2.2.1
Risk Management
The Australian Standard AS/NZS 4360 is a well-known standard for risk management [20]. It provides a generic framework for the establishment and
implementation of the risk management process. Since it is independent of any
specific industry, it should be read in conjunction with domain-relevant standards.
2.2.1.1
Terminology
This section describes the risk management terminology used in this report and is
based on AS/NZS 4360 [20]. None of them have been changed or modified from
the original definitions.
• Risk - the potential that a given threat will exploit vulnerabilities of an asset
or group of assets and thereby cause harm.
• Risk analysis - a systematic use of available information to determine how
often specified events may occur and the magnitude of their consequences.
• Risk assessment - the overall process of risk analysis and risk evaluation.
• Risk evaluation - the process used to determine risk management priorities
by comparing the level of risk against predetermined standards, target risk
levels or other criteria.
• Risk identification - the process of determining what can happen, why and
how.
2.2. MANAGEMENT OF RISKS, SAFETY AND SECURITY
11
• Risk management - the culture, processes, and structures that are directed
towards the effective management of potential opportunities and adverse
effects.
• Risk management process - the systematic application of management
policies, procedures and practices to the tasks of establishing the context,
identifying, analyzing, evaluating, treating, monitoring and communicating
risks.
• Risk treatment - selection and implementation of appropriate options for
dealing with risk.
2.2.1.2
Risk Management process
The risk management process provides a framework for identifying risks and deciding
how to treat them. It is specified in AS/NZS 4360: 1999 ( [20]) and should be
integrated into all aspects of the operation. The goal of this process is to eliminate
or reduce the risks in order to minimize potential losses. Focus is laid on prevention
rather than remediation. The process is divided into establishing the context,
identifying, analysing, evaluating, treating, monitoring and communicating risks.
An illustration of the process is shown in figure 2.1 and briefly described below.
The context is established in the first phase of the process. This includes
the strategic and risk management context, as well as criteria and structure of the
analysis. The second phase is the identification of risks which answers the “what”
and the “how” risks happen. In the “Analyze Risk” phase, the level of risk is
determined based on estimates of likelihood and consequence of the risks. The
risks are then evaluated against the predefined acceptance criteria. Risks that are
not accepted must be treated, which is done in the final phase of the process. An
overview of the techniques used for risk analysis is presented in sections 2.3.1 and
2.3.2.
The risk management process is an iterative process. In addition to iterations
among the above mentioned phases, the whole process iterates through two
additional and parallel sub processes. Monitoring and review is important to ensure
that changes do not alter the risk priorities, and that the management plan remains
relevant [20]. Communication and consultation ensures a two-way dialogue between
stakeholders in order to ensure a common understanding of the risk issues [20].
The risk management process should be applied early in the design phase of a
new project. Safeguards are significantly less expensive to implement in the design
phase than they would be, if included, during or after the implementation phase.
However, risk management is not a one-time task. It is an ongoing activity and
12
CHAPTER 2. PRE-STUDY
Figure 2.1: The Risk Management Process of AS/NZS 4366 [20]
should also be an integrated part of the development process, as well as part of
the planning process when significant changes are made on existing systems. Risk
management can be supported by life-cycle methods, which define project phases
and deliverables. Figure 2.2 illustrates the safety-security lifecycle [13].
2.2. MANAGEMENT OF RISKS, SAFETY AND SECURITY
Figure 2.2: The Safety-security life cycle [13]
13
14
CHAPTER 2. PRE-STUDY
2.2.2
Safety Management
2.2.2.1
Introduction
According to the definition provided by Nancy G. Leveson [3], safety is defined as
the freedom from accidents or losses. However, Lawrence in [3] argues that absolute
safety is impossible and defines safety as [13]
“Safety is defined as a judgement of the acceptability of risk, and risk
in turn, as a measure of the probability and severity of harm to human
health. A thing is safe if its attendant risks are judged to be acceptable.”
2.2.2.2
Terminology
This section describes the safety terminology used in this report. None of them have
been changed or modified from the original definitions.
• accident - an undesired and unplanned (but not necessarily unexpected)
event that results in (at least) a specified level of loss [3].
• control system - used to monitor and protect a safety critical system [13].
• error - see system error.
• fault - abnormal condition that may cause a reduction in, or loss of, the
capability of a functional unit to perform a required function [17].
• failure - termination of the ability of a functional unit to perform a required
function [17].
• harm - physical injury or damage to the health of people either directly or
indirectly as a result of damage to property or to the environment [17].
• hazard - a state or set of conditions of a system (or an object) that, together
with other conditions in the environment of the system, will lead inevitably to
an accident (or event) [3].
• hazardous situation - circumstance(s) in which a person is exposed to
hazard(s) [17].
• incident - an unintended event or sequence of events that does not result in
loss, but, under different circumstances, has the potential to do so [3].
• hazardous event - hazardous situation which results in harm [17].
2.2. MANAGEMENT OF RISKS, SAFETY AND SECURITY
15
• interlock mechanism - mechanism which ensures that potentially hazardous
actions are only performed at times when they are safe [3].
• monitoring system - management part of a control system [3].
• protection system - a system that uses sensors to detect fault conditions
and produce outputs to mitigate their effects [3].
• risk - is anything that threatens the ability of the robot to accomplish its
mission [3].
• safeguard - a practice, procedure or mechanism that reduces risk [15].
• safety - freedom from accidents or losses [3].
• safety critical system - A computer, electronic or electromechanical system
whose failure may cause injury or death to human beings [3].
• safety life cycle - necessary activities involved in the implementation
of safety-related systems, occurring during a period of time that starts
at the concept phase of a project and finishes when all of the electrical/electronic/programmable electronic safety related systems, other technology safety-related systems and external risk reduction facilities are no longer
available for use [18].
• safety requirements specification - specification containing all the requirements of the safety functions that have to be performed by the safety-related
system [3].
• stakeholder - an individual, team or organisation (or classes thereof) with
interest in, or concerns relative to, a system [19].
• system - a set of components that acts together as a whole to achieve some
common goal, objective or end [3].
• system failure - the non-performance of the system or component to
perform its intended function for a specified time under specified environmental
conditions [3].
• system environment - a set of components that is not part of the system
but whose behaviour can affect the system state.
• system error - design flaw or a deviation from a desired or intended state
[3].
• threat - a set of circumstances that has the potential to cause loss or harm
to humans and property [15].
16
CHAPTER 2. PRE-STUDY
2.2.3
Security Management
A security policy framework is necessary to support the security infrastructure
required for the secure movement of sensitive information between a robot and
a monitoring system. Moreover, to ensure the secure operation of this kind of
infrastructure, it is essential to have some well-founded practice for the identification
of security risks and application of appropriate controls to manage risks. This
practice can be formalized and (semi-)automated by the use of formal methods and
tools which increase the reliability of the system specification (and therefore users’
confidence in it). This is important because the security of the system is largely
dependent upon the accuracy of its specification. To be truly beneficial, the risk
analysis framework must be granular enough to produce a customisable roadmap of
which problems exist, and to rank them in order of severity, which facilitates making
decisions about which ones to deal with first.
2.2.3.1
Introduction
According to the International Standards Organization (ISO) standard number
13335 [15], security is defined as a computer related system which comprises all
aspects related to defining, achieving and maintaining confidentiality, integrity,
availability, non-repudiation, accountability, authenticity and reliability. This
section describes the security terminology used in this report.
• asset - anything that has value to the organisation [15].
• accountability - the property that ensures that the actions of an entity may
be traced uniquely to the entity [4].
• attack - a deliberate attempt to break into a system with malicious intentions
[4].
• authenticity - the property that ensures that the identity of a subject or
resource is the one claimed to be [4].
• availability - the property that authorized users have access to information
and associated assets when required [4].
• confidentiality - property that ensures that information is accessible only to
those authorized to have access [4].
• control - a protective measure [4].
2.2. MANAGEMENT OF RISKS, SAFETY AND SECURITY
17
• information security - preservation of confidentiality, integrity, availability,
authenticity, reliability, accountability and non-repudiation [4].
• IT security policy - rules, directives and practices that govern how assets,
including sensitive information, are managed, protected and distributed within
an organization and its systems [15].
• Information system - consists of people, machines and methods for
collecting, processing, transmitting and disseminate data [13].
• integrity - the property that safeguards the accuracy and completeness of
information and processing methods [16].
• non-repudiation - the property that ensures the ability to prove an action
or event has taken place, so that its event or action cannot be repudiated later
[4].
• risk - is anything that threatens the ability of the robot to accomplish its
mission.
• security - see information security.
• security critical system - system whose assets contain vulnerabilities that
might be exploited.
• threat - a set of circumstances that has the potential to cause loss or harm
to humans and property [15].
• reliability - the property of consistent intended behaviour [15]
• vulnerability - a weakness in the security system [4]. e.g. procedures, design
or implementation that might be exploited to cause harm or loss.
• weakness - a flaw or a weak point [4].
2.2.4
Relationship between safety and security
Safety and security are two terms that are different but very closely related.
Confusion exists when one tries to define and categorise them. By outlining and
comparing their similarities and differences , one clarifies doubts and allows a sound
understanding and interpration of the terms.
The similarities between safety and security are:
18
CHAPTER 2. PRE-STUDY
(a) Both deal with threats and risks; safety is about threats to life or property
and security is about threats to the privacy or IT security policy.
(b) Both involve negative requirements or constraints that may conflict with
important system goals.
(c)Both involve protection against losses (although the types of losses may be
different)
(d) Both involve global system properties that are difficult to deal with outside
of a system context.
(e)Both involve requirements that are considered of capital importance in
deciding whether they can and should be used, i.e. particular high levels of assurance
may be needed, and testing alone is insufficient to establish those levels.
(f)Both qualities involve aspects of a system that are regulated by government
agencies or licensing bureaus where approval is dependent on whether the system
does anything useful or is economically profitable.
The differences between safety and security are:
(a) Safety issues are those hazards that will affect the system from within
the system itself while security threats are external to the system, found in the
environment that some way or another do affect the system.
(b) While security focuses on malicious intentions and actions, safety is more
concerned with well-intended actions that do not perform as expected.
(c) Traditional emphasis in security has been on preventing unauthorized
access to classified information, as opposed to preventing more general malicious
activities. However, it is worth to be noted that if an accident or loss event is
defined to include unauthorized disclosure, modification and withholding of data,
then security becomes a subset of safety.
Figure 2.3 shows the relationship between Safety and Security, the system
being the focal point. It is influenced by safety hazards from within the system
itself and by security hazards, which are external to the system.
2.3
2.3.1
Tools for Risk analysis
Risk analysis from a safety standpoint
The most common risk analysis methodologies used within the development of
safety critical systems are Preliminary Hazard Analysis (PHA) [46], Hazard and
Operability Analysis(HazOp) [46], Fault Tree analysis (FTA) [46], and Failure
Modes, Effects and Criticality Analysis (FMECA) [46] and are each briefly described
as follows;
2.3. TOOLS FOR RISK ANALYSIS
19
Figure 2.3: Diagram illustrating the relationship between safety and security.
1. Preliminary Hazard Analysis (PHA) is an initial study of the potential
hazards of a system used in the early stages of system design. It focuses
on (1) identifying apparent hazards, (2) assessing the severity of potential
accidents that could occur involving the hazards, and (3) identifying safeguards
for reducing the risks associated with the hazards. This technique focuses on
identifying weaknesses early in the system life-cycle, thus avoiding the hassle
of major redesign if the hazards were discovered at a later stage [47].
2. Hazard and Operability Analysis (HazOp) is a technique for identifying
and analysing the hazards and operation concerns of a system [12]. The
HAZOP analysis technique uses a systematic process to (1) identify possible
deviations from normal operations and (2) ensure that appropriate safeguards
are in place to help prevent accidents. The HAZOP technique uses special
adjectives (such as “more”, “less”, “no”, etc.) combined with process
conditions (such as speed, flow, pressure, etc.) to systematically consider all
credible deviations from normal conditions. The adjectives, called guidewords,
are a unique feature of HAZOP analysis [47].
20
CHAPTER 2. PRE-STUDY
3. Fault Tree Analysis (FTA) is an analysis technique that uses visual models
to specify the logical relationships between equipment failures, human errors,
and external events that can combine to cause specific accidents. Figure 2.4
shows an example of a fault tree [47] using notation from the Fault Tree
symbols in N.Leveson’s Safeware [3].
Figure 2.4: An example of a Fault Tree.
4. Failure Modes, Effects and (Criticality) Analysis (FME(C)A) FMEA
is a qualitative reasoning approach that is best suited for reviews of mechanical
and electrical hardware systems. The FMEA technique (1) considers how the
failure modes of each system component can result in system performance
problems and (2) ensures that appropriate safeguards against such problems
are in place. A quantitative version of FMEA is known as failure modes,
effects, and criticality analysis (FMECA) [47].
2.3.2
Risk Analysis from a security standpoint
CORAS is a platform for Risk Analysis of Security-critical Systems and is an EU/IST
project within the 5th framework programme, which satisfies security requirements.
It is a practical framework for a precise, unambiguous and efficient risk analysis,
by exploiting the synthesis of risk analysis methods with object-oriented modelling,
(semi-)formal methods and tools, in order to improve the security, risk analysis and
2.4. LEGO MINDSTORMS
21
security policy implementation of security-critical systems. Since the infrastructure
of the USAR robot model is making use of the public ethernet and infrared light
for communication, it is primordial to make this infrastructure totally secure and
unassailable [46]. However, in practice no system is and will be 100% secure.
2.4
Lego Mindstorms
The Lego Mindstorms 2.0 or Robotics Inventions System(RIS) is a member of the
family of Lego products embracing computer-controlled robotics. The kit includes
two motors, two touch sensors, one light sensor, more than 700 Lego bricks, and a
robot brain called the Robotics Command Explorer (RCX). The motors and sensors
give Lego models the ability to move and sense external conditions. Like Lego itself,
the concept is simple and brilliant as it allows users to piece together a robotic
creation using standard Lego parts such as bricks, pulleys and gears .
Figure 2.5: The RIS 2.0 kit
RIS also includes software for programming robots, a graphical environment
called RCX Code where robot programs are created by snapping together functional
blocks, just like snapping together Lego bricks. Completed programs are then
downloaded and stored on the RCX via an infrared link. The RCX Code is
great enough for non-programmers to program the RCX, but it is quite limited
in developing more complex applications.
2.4.1
Components of Lego Mindstorms
The most important and relevant parts in our discussion are:
1. The Robotics Command Explorer, RCX represents the robotic brain and is a
large brick that contains a micro-controller that gives Lego robots the ability to
22
CHAPTER 2. PRE-STUDY
be mobile without being connected to a computer. Fig 2.6 shows an illustration
of the RCX, and its various parts are:
• RCX Central Processing Unit. The RCX brick encloses a Hitachi
H8/3292 series micro-controller. The H8 is capable of running at a clock
rate of between 10 MHz and 16 MHz, and the RCX uses the highest clock
rate of 16 MHz. This is extremely low compared to modern processors
that run at speeds higher than 1000 MHz but it is fast enough for most
functions such as turning motors on and off, reading input from sensors
and computing the next logical move.
• ROM. The micro-controller chip contains 16 Kilobytes of ROM and
512 kB of RAM. It contains algorithms for downloading the firmware,
displaying data on the LCD screen and communicating with sensors.
• RAM. The brick has 32 kB of external RAM which is sufficient enough
for most robotic programs. There are two components stored in the
RAM; the firmware and user functions. The firmware is basically an
extension of the ROM but it can be upgraded or replaced to provide
different functionalities.
• Input ports. There are three input ports that capture data from Lego
sensors like touch sensors, light sensors, temperature and rotation sensors.
• Output ports. The brick contains three output ports, mostly used to
control controllable devices(called actuators) like motors.
• Buttons. There are four buttons on the brick:
(a) On-Off enables to turn the power on or off.
(b) Run starts the execution of the current program stored in the RCX.
(c) View. With standard Lego firmware, this button triggers the display
of time, input and output sensors.
(d) Program is used to select the program to be executed from a
maximum of five programs.
• IR port. The IR port is the clear black surface at the top of the
RCX brick. Its primary function is to allow two-way communication,
by sending and receiving data from a computer. It can also be used to
communicate with one or more robots within a group.
• Speaker. The speaker is not visible from the outside of the brick. It is
located behind the LCD and can produce a variety of simple sounds of
variable frequency and duration.
• LCD. The LCD screen displays the value of the input sensors or any
numerical output that a program wishes to display.
2.4. LEGO MINDSTORMS
23
Figure 2.6: The Robotics Command Explorer
• Battery. The six 1.5 V dc batteries provide the necessary power to the
RCX and account for almost half of the total weight and volume of the
RCX.
2. Infrared Serial Communications Tower. The IR tower establishes a
wireless link between the computer and the RCX. It is essentially responsible
for data communication between the PC and the RCX brick. It allows
programs to be downloaded to the RCX and later executed(run) by the RCX.
The IR tower uses infrared signals to send messages and it does not require
any battery but is constantly connected to the computer via an USB cable.
Figure 2.7: The IR communications tower
Figure 2.8: The touch sensor
3. Sensors. Input sensors detect data from the real world and send data back to
the RCX. In addition to input sensors, it has three internal sensors: a timer(to
keep track of time), an RCX message holder (to receive messages from other
communicating devices) and user defined variables. Light and touch sensors
24
CHAPTER 2. PRE-STUDY
are included in the standard 2.0 kit while rotation and temperature sensors
are not.
• Lego touch sensor. Touch sensors would usually make part of front,
rear or even side bumpers.Bumpers are essential components of a robot
in motion in order to detect and avoid collisions accordingly. The touch
sensor is the most basic sensor available in the Lego collection, and
consists of a small push button built onto the end of a 2x3 brick. Both
depress and release of the switch are detected by the RCX, and when in
touch sensor mode (or boolean mode), the values 0 or 1 are returned.
• Lego light sensor. The light sensor is a standard part of the Lego
Mindstorms 2.0 kit that is mostly used for measuring the intensity of light
that enters the tiny lens on the front of the sensor. It can also be used to
distinguish dark objects from light. The light sensor has a small red lightemitting diode(LED) that illuminates the scene in front of the sensor. It
reads values from 0 to 100, with 100 being the brightest. The basic idea is
to send a light towards an object and record the corresponding percentage
of light reflected back.
4. Motors. The kit includes two 9-volt motors, which have internal gears
connected to an electric motor that increase the torque to the shaft. This
results in slower shaft rotation and unfortunately, these motors have only one
speed of rotation. It is possible to decrease the power to a motor, but this only
makes the output weaker and more likely to stall. The only way to change
speed and keep power at 100% is to use additional gears externally to further
alter the speed of the shaft.
Figure 2.9: The light sensor
Figure 2.10: The motor
2.4. LEGO MINDSTORMS
2.4.2
25
Robot Vision.
In order to navigate through the site to accomplish its mission, the robot needs to
be equipped with a camera whose function will be to detect and identify objects in
the path of the robot.
2.4.2.1
Camera technologies
There are two types of camera available on the market: Analog and digital.
1. Analog. In analog technology, a wave is recorded or used in its original
form. So, in an analog video camera, a signal is taken straight from the
microphone/camera and laid onto tape. The input wave is an analog wave,
and therefore the wave on the tape is analog as well. That wave on the tape can
be read, amplified and sent to a speaker/screen to produce the sound/image.
2. Digital. In digital technology, the analog wave is sampled at some interval,
and then converted to bits and bytes that are stored in the digital device. The
sampling rate is on average 44,000 samples per second. To output the data,
the bytes are converted into a voltage wave that approximates the original
wave.
Table 2.1 describes the factors affecting our choice between analog and digital
cameras while table 2.2 shows a comparison between the two.
Conclusion: Both analog and digital offer more or less the same facilities
except for the compression, reliability and communication with the RCX. We
therefore opt for the use of a digital camera in our robot model.
2.4.2.2
Camera models
This section describes two digital cameras that could be used in our robot model.
• Lego Vision Command Camera. Lego offers a digital camera with an in-built
microphone connected to the USB port of a computer that can be used for
light, colour, and movement recognition. The camera [50] being part of the
Lego products set, can thus be easily mounted on a Mindstorms robot. The
camera (shown in figure 2.11) delivers still pictures and streaming video at a
maximum resolution of 352x288(Y channel) and 176x144(U and V channels)
respectively, which matches the other average web-cameras.
26
CHAPTER 2. PRE-STUDY
Factor
Quality of sound/image
Compression of images,
pictures and sound
Error checking/recovery
Communicate with RCX
Wireless technology
Battery supply
Description
The quality of image and sound needs to be
good enough resolution for colour detection.
Any resolution below 320x240 is
unacceptable.
The size of data must be of the least
size possible to be transferred.
Reliability is an important issue.
Risk of data loss must be minimised.
Communication between the RCX and
camera will definitely enhance performance.
The robot needs to be free from cables
to increase mobility.
A battery supply implies no power chord
attached to the robot.
Table 2.1: factors affecting choice between analog and digital cameras
Factor
Quality of sound/image
Compression of images,
pictures and sound
Error recovery
Error checking
Communicate with RCX
Wireless technology
Battery supply
Analogue camera
good
Digital camera
good
no
no
no
no
yes
yes
yes
yes
yes
yes
yes
yes
Table 2.2: Comparison between analog and digital cameras
• D-Link wireless internet camera DCS-5300G is a model of D-Link in the
wireless internet camera range [49]. It is a digital surveillance system that
connects to an Ethernet or wireless broadband network to provide remote video
and audio. Using the 802.11g wireless technology, the DCS-5300G (shown
in figure 2.12) has an inbuilt web-server and communicates at a maximum
wireless signal of up to 54Mbps. Access and control of the DCS-5300G is
made using any browser (e.g. Internet Explorer version 6, Firefox 1.5 Release
Candidate 1), or even telnet and FTP.
Conclusion: The USB cable in the Lego Vision Command will keep the robot
physically tied up to the host computer. Although USB cables can be of several
2.4. LEGO MINDSTORMS
27
Figure 2.11: The Lego Vision Command
Figure 2.12: The Dlink wireless internet camera
meters long, robots get easily entangled as they move around. The DCS5300G
camera is on the other hand wireless and capable of outputting to a siren. Directing
28
CHAPTER 2. PRE-STUDY
this output to the RCX instead, could satisfy the communication requirement with
the RCX (see Own contribution - section 8.1). Therefore, the D-link DCS5300G is
our choice for the robot vision.
2.4.3
Robot setup
Up to a maximum of three motors and three sensors can be attached simply by
snapping special ‘wire bricks’ on the RCX. The infrared port is used to communicate
with the desktop computer. Internally, the RCX contains 16KB of ROM and
32KB of RAM. The ROM contains low-level routines for the motors and sensors.
RAM must be loaded with firmware, also provided by Lego but can eventually
be substituted by an alternate package. The default firmware contains a bytecode interpreter, which can run programs downloaded from RCX Code. Section 2.5
provides more details about alternate programming packages.
2.4.4
Communication Technology
The communication technology wrapping up the robot model is the 802.11g
wireless LAN standard and InfraRed communication technology. The RCX brick
communicates, i.e. receives from and sends messages to a pc via a USB lego tower
(see Infrared Serial Communications Tower - section 2). The wireless internet
camera is a camera with its own IP address (10.120.31.16) and named DCS5300G
available only to the IDI computers at NTNU. It can be be accessed by TCP/IP
from within a browser and/or telnet/ftp for communication purposes. However, the
use of wireless communication represents a security threat as it increases the robot’s
vulnerability to malicious attacks.
2.5
RCX’s programming environment
There are two categories of alternate programming environments for the RCX. The
first uses the default firmware on the RCX and provides alternate programming
environments on the desktop computer. An example is NQC, a popular environment
that enables development of robot programs using C-like source files. Those files
are compiled and downloaded to the RCX, but it is still the default RCX firmware
that runs the programs. The second class of alternate programming environment
uses replacement firmware and also provides a set of PC-side tools for programming.
Examples of such programming languages are pbForth, legOS, leJOS, and TinyVM,
all of which are described hereunder.
2.5. RCX’S PROGRAMMING ENVIRONMENT
2.5.1
29
NQC
Created by Dave Naum, NQC (which stands for Not Quite C) [26] is the most
widespread development tool for the RCX. It is based on a simplified version of
the C language and is a command-line executable file. NQC is a multi-platform
program running on windows, Mac and Unix-like systems. It works on the default
RCX firmware and takes advantage of its stability and reliability, while at the same
time giving the user a lot more computational power.
2.5.2
pbForth
PbFORTH [25], which stands for Programmable Brick FORTH, was one of the
first replacement packages available for the RCX. It supports programming the
RCX using FORTH [24] and enables downloading a kernel to the RCX and has
a command-like terminal interface. PbFORTH allows full access to program the
LCD and buttons. The major strengths of PbFORTH coding is that it is efficient,
powerful and portable [6] but on the other hand, two main disadvantages of the
environment are known. The use of floating point numbers is not possible and
pbFORTH does not come with an uploader, which means that it must use the NQC
firmware uploader to upload to the RCX brick.
2.5.3
legOS
LegOS [2]is the Lego Operating system and is known as the most powerful and
fastest development tool for the RCX . When using legOS, the code is executed
directly on the Hitachi controller. Hence all limitations of the original RCX
interpreter is bypassed. Furthermore, the full power of the hardware is unleashed by
linking system routines to programs written in C or C++, which legOS compiles and
runs in place of the default RCX firmware. The combination of a strong language like
C and the ability to control every device at a very low level, means that programs
can be executed at a high speed. However, it does have drawbacks. First, the
installation and compilation of legOS in windows systems is not so trivial (based
on own experience). As in pbFORTH, no floating-point numbers are available and
only the most basic classes and methods are offered by the API [2].
2.5.4
leJOS
LeJOS [27], is a Java environment for the RCX and provides a replacement to the
default RCX firmware. It is an open source project and is currently available on
30
CHAPTER 2. PRE-STUDY
both Windows and Unix systems. It offers the possibility of being combined with
Java OO programming language. It is portable, reliable and offers multithreading.
However, it is worth to be noted that leJOS, unlike Java, does not provide garbage
collection facilities.
2.5.5
TinyVM
TinyVM [28], is a small Java Virtual machine which has been replaced by leJOS.
It can be thought of as the leJOS micro edition. It is basically a compact Java
virtual machine that features an API with native methods that provide access
to the RCX hardware resources. Only a subset of the Java API is supported
including threads, recursion, synchronization, arrays and exceptions and lacks the
most complex features of a complete Java system - the virtual machine has access
to only part of the Java API. Moreover, tinyVM does not support floating-point
numbers.
2.5.6
Evaluation and conclusion
The reader is referred to section choosing a programming environment - 6.1.
Chapter 3
Requirement Specification
This chapter describes the requirements of the robot model to be implemented. The
model will enable us to have a better understanding of the safety and security issues
in the design and builiding of a USAR. First, a short description of the system for
the model is presented in section 3.1. Section 3.2 presents the use case diagrams,
which are used to depict the overall functionality of the system and the actors
involved. Functional requirements are presented in section 3.3 and non-functional
requirements in section 3.4 .
For the remainder of this report:
1. All human beings (both dead or alive) or animals, will be referred to as humans.
This is done in view of greater convenience and easier reference.
2. The robot model will be referred to as “Usario” . In creole, a dialect of
French, the suffix ‘-io’ in words means small or diminished and therefore Usario,
in creole, means “small USAR”. The objective is to avoid confusion, easier
reference and greater convenience when the robot is referenced which could be
the robot used as model, a USAR or any other robot.
3.1
Description of the system
Usario, the model, is a mobile robot searching for survivors and cadavers in a
collapsed building. It is a semi-autonomous Lego Mindstorms robot capable of
relaying sound and images of the scene to an operator sitting in front of a computer.
The critical issue is that Usario must detect ALL bodies or survivors in all the rooms
it visits, in other words it must detect humans whenever there are humans in the
vicinity. In addition, Usario must be able to correctly report both its position and
31
32
CHAPTER 3. REQUIREMENT SPECIFICATION
the position of the humans identified. Figure 3.1 shows Usario in action. The
RCX program is downloaded to the RCX by the use of the Lego USB tower,
connected to the server. Usario navigates around a one-floored site by following
a black-coloured line (represented by the blue line in the diagram) on the floor.
The camera is constantly sending images of the scene (using 802.11g) to the server
via the wireless access point. As soon as human survivors are within sight of the
camera, the camera’s colour recognition function detects the status of the humans
(characterized by a green or red toy figure). At the same time, a message is sent by
the camera to the RCX, to inform the latter about the identification of the victim.
The RCX is programmed to emit two different sounds:
1. A single beep for a cadaver (characterised by a red toy figure).
2. A double beep for a survivor (characterised by a green toy figure).
At the same time, an authorised user connected to the server(802.11b or 802.11g)
follows the movements of Usario on his own screen.
note: Because of time constraints, the physical environment of Usario is limited
to a flat-surfaced one-level floor of a building.
3.2
Use cases
This section describes the actors and use cases of the system. Each use case
represents a functionality performed by the system and shows how actors interact
with this functionality.
3.2.1
Actors
Actors are represented by stick persons in the sequence diagrams. In UML, an actor
is defined as an object that exists outside the scope of the system and that interacts
with the system. An actor can be a human user, a device with which the system
must interact, or a legacy software system [10].
• Operator. The operator interacts with the system when booting or shutting
down devices, when taking control over Usario, or even when stopping the
robot.
• GUI. This is a simple graphic user interface where the following are displayed
to an operator:
3.2. USE CASES
Figure 3.1: Illustration of the USAR model on a one-floor building.
33
34
CHAPTER 3. REQUIREMENT SPECIFICATION
– Live image of the site. The image, as seen by the robot’s camera, is
displayed in real time on the user’s screen. This is to enable quick human
intervention and decision.
– Notification of object detection and object identification. To increase the
probability of detecting threats, an explicit notification needs to be done
whenever an object is detected and identified.
– Notification of status and position of humans. This measure improves
the efficiency of the rescuers as appropriate resources (like time and
equipment) can be properly allocated.
– Battery level of RCX/web camera. Explicitly displaying the battery
level of the battery-powered components enables a better management
of Usario’s power requirements.
– State of motors/sensors. Display of the appropriate functions of the
motors and sensors contribute to easier and quicker fault identification of
these components.
– message from/to RCX. Displaying all commands and messages that are
sent to and data received from Usario, increases the awareness of the
operator.
– Joystick to control Usario. A joystick pad should be made available to
the operator to easily control and steer Usario whenever there is need to.
• PC program. The PC program is a java program installed on the control
unit side. Its main function is to process raw data from the web camera and
messages from the RCX, and channel appropriate information to the back up
machine and to user(s) of the system.
• RCX program. The RCX program is a java program loaded onto the RCX
for capturing data from the inputs and forward it to the controlling unit.
• Web camera. The web camera is the camera mounted in front of Usario to
capture images and sound of the site.
• RCX. See 2.4.1- RCX.
• Backup. Back up is a dedicated computing machine for backup of data and
information from the rescue operation.
3.2. USE CASES
3.2.2
35
Use case Specifications
A brief description of the main use cases are given in table 3.1 to model the
interaction between user and robot. Tables 3.2 to 3.11 show a few selected use
case specifications with focus on safety and/or security aspects.
Use case
On/Off RCX
Detect objects
Identify objects
Determine status
Follow line
Avoid obstacle
Report position
Short description
The RCX can be started or shut down
by the operator.
Objects can be detected by the web camera.
Objects can be identified as either humans or
non-humans, in that case them being obstacles.
The status of humans being dead or alive can be
determined by the web camera.
The light sensor detects and follows a line on the
floor as means of navigation.
Usario attempts to go around an obstacle
by following its ’wall’.
The IR tower reports position of humans detected.
Table 3.1: short description of main use cases
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
A user logs into the system through the GUI.
Operator, GUI
1. The operator is not logged in into the system.
2. The operator login is valid and authentic.
The operator is logged in to the system.
1.Operator provides his public key.
2. Operator keys in his userid and password.
1.Operator does not have public key nor valid userid.
2. Operator does not have access to the system.
Table 3.2: Use Case 1 - Logging in into the system
36
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
CHAPTER 3. REQUIREMENT SPECIFICATION
Usario is booted on by pressing the On/Off and the
’Run’ buttons on the RCX.
Operator, RCX
The RCX is not booted on.
Usario starts searching for humans.
1.The operator pushes the On/Off button on the
RCX.
2.The operator pushes the ’Run’ button on the
RCX.
3.The RCX is booted.
4. Usario starts searching for humans.
Usario is booted on by network signals.
[not implemented]
Table 3.3: Use Case 2 - On/Off RCX
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
Web camera is booted on by pressing the
ON/OFF button on the camera itself.
Operator, web camera
The Web camera is not booted on.
Image is displayed at the operators desk.
1.The operator pushes the On/Off button on the
camera.
2.Image is displayed at the operators desk.
Camera is booted on by network signals.
Table 3.4: Use Case 3 - On/Off camera
3.2. USE CASES
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
37
The camera detects object(s) in its
view.
Web camera, operator, PC program, GUI
An object lies in the camera’s view.
Object location is reported.
1.The camera detects an object.
2.Usario stops moving.
3.Usario reports object location.
4. System attempts to identify object type.
1.The camera does not detect object.
2.Operator detects object.
3. Operator takes control over Usario through the
GUI.
Table 3.5: Use Case 4 - Detect objects
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
The camera identifies object in its view.
Web camera, operator, PC program
1. An object lies in the camera’s view.
2. Camera has detected the object.
Object is identified.
1.PC program identifies object type.
2.Usario is instructed on next step.
Alternative flow
Table 3.6: Use Case 5 - Identify objects
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
The PC program determines the status of
the humans.
Web camera, PC program
Object has been identified as human.
Human is identified as dead or alive.
1. PC program identifies status of human.
2. RCX reports position of human to PC program.
Alternative flow
Table 3.7: Use Case 6 - Determine status
38
CHAPTER 3. REQUIREMENT SPECIFICATION
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
Usario moves by following a line drawn on the floor.
Light sensor, RCX, PC program, Operator
RCX and PC program are both up running.
Usario moves forward, following the line.
1.The light sensor collects light data from the floor.
2. The data is interpreted by the RCX.
3. Usario is instructed on the direction to follow.
1. Line is not detected by sensor.
2. Operator takes control over Usario.
[Not implemented]
Table 3.8: Use Case 7 - Follow line
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
Usario is reporting on the position of a detected
victim.
RCX, Operator, PC program, camera
RCX knows its own position.
RCX knows position of victim.
Communication with PC is established.
PC and operator are aware of the positions of Usario
and victim.
1.RCX determines its own position.
2.RCX determines the position of the victim.
3.RCX sends a message, via the camera, to PC
informing about the position of the
victim.
1.Communication is not established.
2.RCX tries repeatedly to send message over
a determined amount of time.
Table 3.9: Use Case 8 - RCX sending message to PC program
3.2. USE CASES
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
39
PC is sending some control requests to the RCX.
PC, operator, RCX, camera.
Communication between RCX and PC is established.
RCX receives message and acknowledges receipt.
1.PC requests communication with RCX.
2.RCX accepts offer to receive message.
3.message is sent to RCX .
1.Communication is not established.
2.PC tries repeatedly to send message over
a determined amount of time.
Table 3.10: Use Case 9 - PC program sending message to RCX
Brief Description
Actor
Pre-conditions
Post conditions
Basic flow
Alternative flow
camera is sending some messages to the PC.
PC, operator, camera.
Communication between camera and PC is
established.
PC receives message and acknowledges receipt.
1.Camera requests communication with PC.
2.PC accepts offer to receive message.
3.message is sent to PC .
1.Communication is not established.
2.Camera tries repeatedly to send message over a
d etermined amount of time.
Table 3.11: Use Case 10 - Camera sending message to PC program
40
3.3
CHAPTER 3. REQUIREMENT SPECIFICATION
Functional requirements
This section presents the functional requirements of the system. These functional
requirements are derived from the use case scenarios of section 3.2. The requirements
are numbered, with the abbreviation F preceding the number.
F 1: Navigation
Usario shall be able to:
F 1.1 turn right.
F 1.2 turn left.
F 1.3 move forward.
F 1.4 move backward.
F 1.5 follow a coloured line.
F 1.6 avoid obstacles.
F 2: Detection
The camera vision of Usario shall be able to:
F 2.1 detect objects.
F.2.2 detect humans.
F 3: Identification
The camera vision of Usario shall be able to:
F 3.1 determine the status of the humans (dead(red colour) or alive(green)).
F 3.2 capture image of the victims.
F 3.3 capture sound from the environment.
F 4: Localization
The RCX of Usario shall be able to:
F 4.1 determine its own position.
F 4.2 determine the position of the humans.
F 5: Reporting
The RCX of Usario shall be able to:
F 5.1 report its own position.
F 5.2 report the location of the identified humans.
F 6: Communication
The RCX of Usario shall be able to:
F 6.1 communicate with the PC controller through the IR tower.
F 6.2 communicate with the camera through a simple 4-pin flat cable.
The camera vision of Usario shall be able to:
F 6.3 communicate with the PC controller through wireless LAN.
F 6.4 Communicate with the RCX through a flat cable.
F7: Access
3.4. NON-FUNCTIONAL REQUIREMENTS
41
The system shall
F 7.1 validate and give access to authorized personel only.
F 8: Power
Usario shall:
F 8.1 be self-powered (by batteries).
F 8.2 be wireless.
F 9: Speed
Usario shall:
F 9.1 move at a reasonable speed.
3.4
Non-functional requirements
The section presents the non-functional requirements of the system. These
requirements place restrictions on the robotics system and the development process,
as well as specifying external constraints that should be met. The requirements are
numbered, with the abbreviation N proceeding the number and are divided into the
following categories:
N1 Environment
Usario shall not :
N 1.1 bump into objects.
N 1.2 hurt humans.
N 1.3 aggravate condition of victim(s).
N 1.4 damage property.
N2 Reliability
Usario shall not :
N 2.1 be operated/interfered/manipulated by unauthorised personel.
N3 Maintainability
Usario shall :
N 3.1 be easily modified for maintainance purposes.
N4 Upgradability
Usario shall :
N 4.1 be easily upgradabable, by use of plug-in components.
Chapter 4
Risk Analysis
“Risk is a combination of the likelihood of an accident and the severity
of the potential consequences. Risk increases if either the likelihood
or the magnitude of loss increases as long as the other component
does not decrease proportionally. Different factors may affect these two
components of risk.” N.Leveson [3]
To ensure the design of a safety critical system, the risk management process has
been carried out in this project. It has been introduced in the pre-study phase
(section “Risk management”, 2.2 and “Tools for risk analysis” section 2.3) and it’s
application is documented in this chapter. First, the Concept and overall scope
definition begins our discussion followed by a presentation of the risk analyses
performed (section 4.2), which are thereafter assessed.
4.1
Concept and Overall Scope definition
The first two steps in the development of a safety critical
system is the definition of concept and overall scope. The
main scope of this thesis is to enquire into the safety
and security domains in order to specify the safety and
security requirements of a USAR robot. This is done by
performing risk analysis on a robot model, study the results
and thereafter extrapolate the results to a USAR robot.
43
44
CHAPTER 4. RISK ANALYSIS
4.2
Preliminary Analysis
This section, together with Appendix B , Appendix C and
Appendix ?? describes the brainstorming sessions held to
gather specific information in order to develop a safety
critical system.
1. PHA. A preliminary Hazard Analysis was conducted
in mid-October 2005 to investigate the safety and
security aspects of a USAR robot in action. There were
4 participants in this brainstorming session. A word
document (see Appendix B) describing the objectives
of the session along with some introductory information of the project was
made available (prior to the meeting) to each participant. An overview of the
project and system was presented (see Appendix C) at the very beginning of
the session and the result of the PHA session is found at Appendix ??.
2. Hazop. A hazards and operability analysis was made
in mid-November 2005. The four participants were the
same as in the PHA and was carried out in sessions
of two hours over two days. The user is referred
to appendix E and appendix F for more detailed
information. Note: While conducting the PHA and
hazop sessions, it was found that the ‘likelihood of
occurence’ and ‘severity of consequence’ were different
for Usario and for a robot in real life. Therefore,
observations on both were made but those on ‘the robot
on real life situation’ taken had more weightage in the
analysis.
4.3
Risk Interpretation and Classification
As specified in AS/NZS 4360:1999, the interpretation and classification of risk is
to be performed in the third sub-process. In the IEC 61505 development life cycle
(see fig 2.1), it is related to the activities in phase 3, Hazard and Risk Analysis. To
estimate the level of consequence and likelihood of each risk, various techniques were
applied. The estimation of consequence was measured as the level of impact to the
environment and the likelihood as the probability of occurence. The term catastropic
means complete failure of the system. This work focuses on functional safety and
categorises the consequence and likelihood according to this domain. Table 4.1
4.3. RISK INTERPRETATION AND CLASSIFICATION
45
and table 4.2 are extracts from Safety-critical computer systems [7] describing the
categories used in IEC 61508. The terms are originally based on a categorization
proposed by the U.S Ministry of Defence in 1995.
Category
Frequent
Probable
Occasional
Remote
Improbable
Incredible
Definition
Likely to be continually experienced.
Likely to occur often.
Likely to occur several times.
Likely to occur some time.
Unlikely, but may exceptionally occur.
Extremely unlikely to occur at all, given the assumption
recorded about the domain and system.
Table 4.1: Likelihood of occurence
Category
Catastrophic
Critical
Marginal
Negligible
Definition
At least one death or damage to property.
Multiple and/or severe injuries, or severe
occupational illnesses.
A single severe injury or occupational illness
and/or multiple minor injuries or minor occupational
illnesses.
At most a single minor injury or minor occupational
illness.
Table 4.2: Severity of consequence
This categorisation imposes a rough qualificative classification of the impact
on the environment. The IEC 61508 draft does not explicitly define the classes. Still,
the definitions are appropriate for safety situations. The classifications have been
adjusted accordingly to match the specific needs. The probability ranges remain
however applicable to all situations.
Each risk has been characterized by these two factors and have have been
classified acording to their properties. The classes differ in the degree of seriousness
and are easy-to-understand illustrations of types of risks that we are willing to accept
or not. The classes are presented in table 4.3 and Table 4.4.
Classifying the identified risks enabled the system developers to rank and
evaluate the risks. For example, risks of class I will not be accepted and need
further evaluation while class IV is negligible and can be accepted.
Note that the preceding tables provide a qualitative classification of risks. As
indicated in [21], the use of qualitative risks analysis has several weaknesses. The
46
CHAPTER 4. RISK ANALYSIS
Risk Class
Class I
Class II
Class III
Class IV
Interpretation
Intolerable risk.
Undesirable risk, and tolerable only if risk reduction is
impracticable or if the costs are grossly disproportionate
to the improvement gained.
Tolerable risk if the cost of the risk reduction would exceed
the improvement gained.
Negligible risk.
Table 4.3: Interpretation of risk classes from IEC61508
Frequent
Probable
Occasional
Remote
Improbable
Incredible
Catastrophic
I
I
I
II
III
IV
Critical
I
I
II
III
III
IV
Marginal
I
II
III
III
IV
IV
Negligible
II
III
III
IV
IV
IV
Table 4.4: Classification of risks from IEC61508
methods’ Achilles’ heel is the subjective basis upon which they reside. In these cases,
subjective probabilities reflect the beliefs of reality. Hence, the evaluation was made
dependent on the experience of the brain-storming session members.
After the estimation and determination of risk classes and which risks are
acceptable and not, risk treatment must be considered. According to the accept
criteria defined for the system, various treatment methods must be avaluated.
4.4
Safety Requirements Specification
In this specification phase, it is worthwhile noting that the safety requirements
identified in this preliminary analysis are used in the following risk management
phases as a basis for further analysis.
The IEC 61508 standard focuses only on the safety aspect of the systems and
not on the basic functionality. Neither of the regular non-functional requirements
are covered. However, both functional and non-functional requirements will be
embodied into the requirements when composing the safety design of the system.
Using the PHA as a basis, a list of safety requirements can be drawn up and are
summarized in table 4.5.
4.4. SAFETY REQUIREMENTS SPECIFICATION
Component
Usario shall
The camera shall communicate
The control system shall
47
Safety Requirement
1. navigate throughout the entire site.
2. notify the control system about its own
position.
3. notify the control system about detected
objects.
4. notify the control system about the status
of the detected objects.
5. notify the control system about the location of the detected objects.
6. send real time images and sound of the
scene to the control system.
7. operate independently in case of control
system failure.
8. communicate through WLAN.
1.through WLAN.
2.with the RCX.
1. maintain communication at all times
with Usario.
2. take steering control over Usario whenever
necessary.
3. backup data (sound, images and object
locations) as often as possible.
4. monitor the battery charge of Usario.
5. provide acces to validated and authenticated users only.
6. display all messages of Usario on a controller window.
7. send control signals to Usario to ensure
that camera and RCX are working properly.
8. display all messages and data sent by
Usario on a controller window.
Table 4.5: The safety requirement specification
These safety requirements shall ensure safe system behaviour and indicate
that the components have the required functionality to perform necessary safety
actions whenever humans are detected. The safety requirements concern the main
components identified in the PHA; Usario (i.e. Motors, the light sensors, IR tower,
the RCX processor, the camera), the control system and the communication channel.
These hold the esssential functionalities of the system.
48
4.4.1
CHAPTER 4. RISK ANALYSIS
Risk Management
The risk management phase consists of four processes (see section 2.2.1.2): identify
risks, analyse the risks (determine likelihood and consequences), evaluate them, and
propose risk treatment options. These are described in the following sub-sections.
4.4.1.1
Identify Risk
The most appropriate technique for risk management
depends on the type of system and its complexity. In our case
study to analyse the risks, we have chosen to make an initial
HazOp followed by a FTA because these two techniques
complement each other. An initial study will help to iendtify
top-events and related events used as a basis for the fault tree
analysis. Then, the FTA is performed to identify how these
events relate to each other and perform both a quantitative and qualitative analysis
if necessary. The CORAS technique also uses this technique.
Hazop. HazOp was introduced in section 2.3 and is presented in detail in
Appendix E and Appendix F. Predefined guidewords and study nodes were used
with associated attributes in order to cover a wide range of possible hazards. A
few study nodes used are summarised in table 4.6 and are based on the results of
the Preliminary Hazards Analysis (Appendix ??). The ‘N.A’ abbreviation is used
to indicate irrelevant combinations of the guideword and study node. The tables in
appendix F show the HazOp study carried out on these nodes. A set of predefined
guidewords (defined in Appendix E) was applied on each study node. However, not
all combinations of guidewords and study nodes were applicable which resulted in
some guidewords not being used.
FTA. In the introduction to this sub phase, we proposed the combination of
HazOp and FTA as a complementary approach for identifying risks. Making a FTA
for all the risks identified in the HazOp is too time consuming to perform. Therefore,
only one example regarding the vulnerability of the WLAN component is presented.
Figure 4.1 illustrates the FTA for this component.
4.4. SAFETY REQUIREMENTS SPECIFICATION
Study Node
Turn
Move
Follow
Detect
Determine status
Determine position (of robot)
Determine position (of vistims)
Reporting
Communicate (RCX with PC)
Communicate (Camera with PC)
49
Description
The robot’s ability to turn sideways.
The robot’s ability to move either
forward or backward.
The robot’s ability to follow an
object (e.g. a line)
The robot’s ability to recognise the
presence of objects on its path.
The robot’s ability to determine
whether the victim is dead or alive.
The robot’s ability to locate itself
in the site
The robot’s ability to locate victims
in the site.
The robot’s ability to send data to
control unit.
The ability of RCX and control
unit to communicate with each other
The ability of camera and PC to
communicate with each other
Table 4.6: The identified safety nodes in the safety-related system.
4.4.1.2
Analyze Risk
Based on the HazOp in the previous phase, the identified risks need to be analysed
in order to separate them in terms of likelihood and consequences. This will form
the basis for a priority factor where the most critical risks are voted special concern
in the design and implementation.
The analysis of the identified risks determines the risk likelihood and severity
consequence which constitute the basis for the estimation of the overall level of
risk. The risk categorization and classification tables are adopted from IEC 61508
[17]. This analysis attempts to identify the most superficial and obvious hazards,
and is not analyzed in more details.
Table 4.7 and Table 4.8 show how the risk class of each safety node is
determined. It is worth to mention that the estimation of likelihood and consequence
is based on a subjective interpretation of the system. Hardware specifications and
the inter-relationship between the components are unknown and the estimation of
overall level of risk can therefore be based on some possibly unreliable assumptions.
50
CHAPTER 4. RISK ANALYSIS
Figure 4.1: FTA for WLAN communication disruption.
4.4.1.3
Evaluate Risk
The categorization of risks according to their likelihood and consequence enable
the determination of the overall level of risk for each identified level of hazard. In
evaluating risks, one considers which of the risks are acceptable and which are not
acceptable. This level of risk is based on a scale of I to IV, one being the most
critical hazard and IV the least critical. In this case study, risk level of III and IV
will be considered as acceptable, while risks of level I and II are rejected and are
considered unacceptable. In other words, the acceptance criteria is set to risk class
II and all risks of class I and II need to be treated accordingly. Table 4.9 shows a
summary of the risks considered to be unacceptable.
4.4. SAFETY REQUIREMENTS SPECIFICATION
Attribute
Guide Word
Turn
No
More/less
Before/after
Other than
early/late
As well as
Reserve
No
Other than
Less
More
As well as
Reverse
After
No
Part of
More
As well as
Reverse
Other than
Early / late,
before/after
No / less
More
As well as
Part of
Late
Before / After
No
Move
Follow
Detect
Determine status
Likelihood
of Occurence
Improbable
Improbable
Improbable
Improbable
Remote
N.A
N.A
Remote
Improbable
Improbable
Improbable
Improbable
Improbable
Improbable
Remote
Improbable
Improbable
Improbable
Improbable
Improbable
Improbable
Improbable
Occasional
Remote
Remote
probable
Remote
Remote
Improbable
51
Severity of
consequence
catastrophic
catastrophic
catastrophic
catastrophic
critical
N.A
N.A
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
critical
critical
Negligible
critical
critical
critical
Risk Level
Table 4.7: Risk level of each safety nodes (part 1 of 2)
III
III
III
III
III
N.A
N.A
II
III
III
III
III
III
III
II
III
III
III
III
III
III
III
I
III
III
III
III
III
III
52
CHAPTER 4. RISK ANALYSIS
Attribute
Guide Word
Determine
position of
robot
No
more/less
part of
other than
As well as
reverse
Early / late
before / after
No
More / less
Other than
part of
Early / late
before / after
No
More / less
part of
Early / late
before / after
reverse
No
More / less
as well as
part of
Early / late
Before / after
reverse
other than
No
less
part of
as well as
reverse
other than
early / late
before / after
More
determine
position of
human
Reporting
RCX
communicate
with PC
Camera
communicate
with PC
Likelihood
of Occurence
frequent
occasional
occasional
occasional
N.A
occasional
occasional
occasional
probable
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
N.A
N.A
improbable
improbable
improbable
N.A
N.A
N.A
N.A
N.A
N.A
Severity of
consequence
catastrophic
critical
critical
critical
N.A
critical
critical
critical
catastrophic
critical
critical
critical
critical
critical
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
N.A
N.A
critical
critical
critical
N.A
N.A
N.A
N.A
N.A
N.A
Risk Level
I
II
II
II
N.A
II
II
II
I
III
III
III
III
III
II
II
II
II
II
II
II
II
II
II
II
II
N.A
N.A
III
III
III
N.A
N.A
N.A
N.A
N.A
N.A
Table 4.8: Risk level of each safety nodes (part 2 of 2)
4.4. SAFETY REQUIREMENTS SPECIFICATION
Attribute
Guide Word
Turn
Move
Follow
Detect
Determine
position of
robot
determine
position of
human
Reporting
RCX
communicate
with PC
53
Severity of
consequence
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
critical
critical
critical
critical
critical
critical
catastrophic
Risk Level
No
No
No
No / less
No
more/less
part of
other than
reverse
Early / late
before / after
No
Likelihood
of Occurence
Remote
Remote
Remote
Occasional
frequent
occasional
occasional
occasional
occasional
occasional
occasional
probable
No
More / less
part of
Early / late
before / after
reverse
No
More / less
as well as
part of
Early / late
Before / after
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
remote
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
catastrophic
II
II
II
II
II
II
II
II
II
II
II
II
Table 4.9: Critical Risks to be treated
II
II
II
I
I
II
II
II
II
II
II
I
54
CHAPTER 4. RISK ANALYSIS
4.4.1.4
Treat Risk
Based on the evaluation of the risks (section 7) and table 4.9, unacceptable risks
have to be treated accordingly. Preventive measures to protect the system from
attacks and to reduce the risk of hazards are done on the following components:
1. Battery/power. Batteries are a critical issue for the smooth running of the
robot. Low or dead batteries can cause the robot to malfunction as:
(a) motors run at a slower torque which in turn affects the movement of the
robot, and
(b) the transmission capabilities of the RCX to send messages/signals
decrease, thereby jeopardising the entire mission.
Therefore, batteries of both the RCX and camera need to be fully charged at
the start of every rescue mission.
2. Light sensor. The importance to have a fully functioning light sensor in
Usario is by no doubt, a critical issue. Usario is entirely reliable on working
light sensor(s) to be able to follow a line, and hence navigate around the
site. As a measure of precaution, stain-free sensors and loose connection(s)
have to be verified before every rescue mission. However, in a real-life
situation, navigation would most probably be reliant on other more advanced
components (like indoor GPS for example) which would make discussion about
this component irrelevant. Instead, focus should then be set on the component
responsible for navigation functionality of the USAR.
3. Camera. Usario’s vision relies solely on the proper functioning of the camera.
(a) Positioning.The positioning of the camera on the robot is an essential
component in object detection. Optimum robot vision is achieved by
correct placement of the camera. Placed too high above the ground would
prevent objects close to the robot to be determined. Placed too close to
ground level, would prevent some objects placed above ground level to
be detected. Intensive testing and measurement about the camera has to
be made to determine the optimum position.
(b) Lens. The camera lens could be at some point in time be covered with
dirt or liquid. Use of wipers to clean the lens could prove determinant
as it is almost impossible to manually wipe off the lens during a rescue
mission.
4. RCX. The RCX ensures the safe running of most of Usario’s basic functionalities.
4.4. SAFETY REQUIREMENTS SPECIFICATION
55
(a) Communication.
• It is of primordial importance to maintain communication between
the RCX and the control unit at all times. One employed tactic would
be to keep the communication channel busy at all times, such that
the tower does not ‘sleep’ during a mission. This could for example
be achieved by making the RCX sending empty data packets to the
control unit.
• The positioning of the tower in relation to the moving robot affects
communication. In order to achieve maximum coverage of the RCX
tower, the latter is to be placed above the site protoype while the IR
port of the RCX is placed in an upright position.
• Since we are dealing with a distributed object-oriented system, we
need to make use of a secure communication link between the RCX
and the control unit to ensure integrity for information in transit.
This can be ensured by encrypting the communication link, which is
WLAN using TCP/IP as the communication protocol.
Important note: Although, the RCX fulfills our needs for this case
study, it is most unlikely that it will be used in a real rescue mission. The
RCX of Usario is one of the biggest flaws in the system. This is because
the communication channel of the RCX is using Infra Red light which
is a poor medium of communication. Infra Red light communication is
restricted to straight line transmission under good lighting conditions.
The RCX has to be placed on a straight line, within a two-metre radius,
facing the RCX tower and with no obstacles in between them. In addition
to these woes, an increase in light conditions interferes with the data
transmission.
(b) Connections. All the wires need to be thoroughly checked before the
rescue mission. All connections made to the input and output ports have
to be properly checked for loose connections.
(c) Buttons. Under laboratory conditions, buttons provide easy access to
functions such as on/off, view, run and program. However, in a real
life situation, it becomes a security hazard. Therefore, easily accessible
buttons should be avoided to avoid the risk of being tampered by objects
and/or humans.
5. Control unit. The control unit is also an important component of the system
and is one of the main targets in attacks. To reduce the risk of attacks:
(a) The control unit should restrict and validate access only to authorized
and authentificated personel. Logins and passwords should be used to
56
CHAPTER 4. RISK ANALYSIS
authorize access to the control unit while public/private keys could be
used to authenticate users.
(b) The personel should be able to access data within an appropriate level.
Different functions should be made available to different categories of
users; some operators might only view the images sent, others could steer
the robot and some view/change some functions - all depending on the
user’s rights.
(c) Backup of data should be made as often and quickly as possible to a
remote database machine which is at a different location from the crash
site.
Chapter 5
Design
This chapter presents an evaluation of the requirements specification (see Functional
requirements - section 3.3) and the design of the system described using a
combination of UML diagrams and Entity-Relationship diagrams. Section 5.3
includes two deployment diagrams describing the system. Finally, an architecture
of the sytem is presented in setion 5.4.
5.1
Functional requirements evaluation
This section provides an evaluation of the requirements specification presenting
challenges and possible solutions. The evaluation is organised according to the
requirements specification; one section per component, evaluating each and every
requirement. This evaluation lead us to the preliminary design of Usario and a basis
of discussions for a Hazards and Operability Analysis.
• F 1: Navigation
Usario shall be able to: (F 1.1) Turn right, (F 1.2) Turn left
This requirement is easily satisfied by adjusting the motor power to the sides,
reducing one side to the minimum and increasing the other side accordingly.
Therefore, decreasing power to the left motor, and increasing the right makes
the robot turn left. The reverse is done to turn right.
Usario shall be able to: (F 1.3) Move forward, (F 1.4) Move backward
The functions ‘Motor.A.forward’ and ‘Motor.A.backward’ from the platform
josx.platform.rcx in the lejos API [29] enable the robot to move in both
directions.
Usario shall be able to: (F 1.5) Follow a coloured line
Based on the contrast between the two extreme colours white and black, it is
57
58
CHAPTER 5. DESIGN
possible to implement a program to follow a line. The values of the light sensor
reading a white object, and then a black line can be easily determined. These
values are noted and are matched against the actual reading of the light sensor
(refer to lego light sensor in section 2.4.1) when Usario is in action. The idea
is then to move (turn) Usario towards the opposite colour as its value differs
from the middle value (threshold).
For short; Let Black value reading (in percent) = B and White value reading
(in percent)= W,
i.e. threshold=(W + B)/2, where B < W (The reading for a black value is
always smaller than that of a white value)
then if B < threshold, move right (towards white side)
else if W > threshold, move left (towards black line).
Usario shall be able to: (F 1.6) Avoid obstacles
To be able to avoid obstacles, the robot has first to detect and recognise the
objects in its line of path. Given the complexity of this task and the fact that
this requirement is time consuming, I prefer to postpone its implementation
for the next version of Usario.
• F 2: Detection
The camera vision of Usario shall be able to: (F.2.1) Detect objects
To recognize general obstacles using the camera will require quite advancced
applications. However, a solution might be to make the camera ‘learn’
some objects. Every representation of humans and walls have to be fed
into the camera so as to recognize the object as a non-human or non-wall,
and thereby deducting that the object is an obstacle. Owing to a limited
supply in manpower and time constraints, I postpone this requirement to be
implemented in the next version of Usario.
The camera vision of Usario shall be able to: (F.2.2) Detect humans
This detection function can be implemented using a mix of both existing open
source codes (e.g Open computer vision library [51]) and tailor made ones (e.g
Petrovic’s colour detection [52] & [53]). The basic idea is to access the frames
generated by the camera with the use of telnet. The images or canvases are
then scanned for each pixel and an algorithm selects those areas that have a
certain percentage of red or green pixels. Note that every pixel has a mixture
of Red, Green and Blue values and that a certain combination of these RGB
values will give pixels within a certain range of colour.
• F 3: Identification
The camera vision of Usario shall be able to: (F 3.1) determine the status of
the humans (dead(red colour) or alive(green colour)), (F 3.2) Capture image
of the victims. (F 3.3) Capture sound from the environment.
Red toy figures have arbitrarily been chosen to represent corpses and green
5.1. FUNCTIONAL REQUIREMENTS EVALUATION
59
figures to represent survivors. The strategy to implement the identification
requirement is very similar to the one described in F2 above. Capturing image
of the victim(s) is possible as we do have access to the images at the internet
camera server by telnet. Sound, is then just a matter of sending a continuous
stream of data to the pc.
• F 4: Localisation
The RCX of Usario shall be able to: (F 4.1) determine its own position
Locating an object within the site turns out to be a demanding task. A counter
could have been implemented to record the travel time of Usario but it would
not be a good reference to location. To be able to locate an object, Usario
has to be referenced to one or more fixed points as anchor points. Explicitly
placing some coloured objects as fixed points around the site does not seem to
be an appealing solution as we would like to simulate the search to be as close
as possible to a real-life search. Thus, the disaster scene should be a new and
undiscovered place i.e in a real-life situation, there would be no opportunity
to go around the site and place some anchor points. There has recently been
new advances in the field of GPS systems that are able to locate objects inside
buildings up to a degree of accuracy of millimetres [54]. However, we feel that
it is NOT crucial to have a full implementation of the localisation requirement
and that the objectives of this experiment can still be met.
The RCX of Usario shall be able to: (F 4.2) determine the position of the
humans
The same arguments as those in requirement F 4.1 apply. Therefore,
localization is not implemented in this project.
• F 5: Reporting
The RCX of Usario shall be able to: (F 5.1) report its own position
A beep sound emitted by the RCX and/or a message sent to the server would
be enough in this experiment. The RCX-beeping when it has identified an
object would mean that it is possible for the camera to send a message to the
RCX. If the camera is able to send a message to the RCX, it must also be
possible to send a message to the server via a wireless access point. If the
location could be determined, then the message content would simply be the
location of the robot itself.
The RCX of Usario shall be able to: (F 5.2) report the location of the identified
humans
The same arguments as those for requirement F 5.2 apply.
• F 6: Communication
The RCX of Usario shall be able to: (F 6.1) Communicate with the PC
controller through the IR tower
60
CHAPTER 5. DESIGN
As Usario is mobile, the RCX is placed on the robot’s top, facing the ceiling.
The IR tower is also placed on top of the site to maximise its coverage area
(see parts placement, section 6.2).
The camera vision of Usario shall be able to: (F 6.2) Communicate with the
camera through a simple 4-pin flat cable.
Since the camera can output a signal to a siren, the camera is made to output
to the RCX instead. The Input/output connector of the camera is used as
an input and output to the RCX trough a free input slot. This function is
described in more details in “Own contribution-RCX communicating through
wireless ethernet”, section 8.1.
The camera vision of Usario shall be able to: (F 6.3) Communicate with the
PC controller through wireless LAN
The DCS5300G (see Camera models - D-Link wireless internet camera, section
2.4.2.2) is a wireless internet camera capable of communicating at 54 Mbps,
using 802.11g specification standard [55].
The RCX of Usario shall be able to: (F 6.4) Communicate with the RCX
through a flat cable.
The same arguments as those for requirement F 6.2 apply.
• F 7: Access
The system shall: (F 7.1) Validate and give access to authorized personel only.
Access to sound and viewing of images is restricted to users who have a valid
user id and password.
• F 8: Power
Usario shall: (F 8.1) be self-powered (by batteries)
Both the camera and RCX are powered by AA batteries. Originally, the
camera was designed to be powered by an AC power chord, it has been replaced
by 10 rechargeable AA batteries. The RCX2.0 is a model that comes along
with six AA batteries. (See Components of Lego Mindstorms - battery 2.4.1.)
Usario shall: [F 8.2) be wireless
Usario is wireless as per requirements F6.
• F 9: Speed
Usario shall: (F 9.1) move at a reasonable speed
The speed of Usario is controlled using the functions ‘Motor.A.setPower(x)’
and ‘Motor.C.setPower(x)’ from the platform josx.platform.rcx in the lejos
API [29], where x varies between 1 and 7, 1 being the lowest.
5.2
Risk management process - Step 5 Design.
5.3. DEPLOYMENT DIAGRAM
61
Based on the preliminary functional requirements of section
3.3, the risk management process using CORAS framework
was performed early on Usario. At each stage of the process,
the identified hazards have been used to redesign Usario
accordingly. Despite the fact that several hazards have been
found critical and needed to be treated, some were only
considered during the design phase and not treated. They
could not be implemented due to time limitations.
5.3
Deployment diagram
This section presents the design of the system by the use of deployment diagrams.
A deployment diagram based on UML 2 is presented in the first part followed by an
informal deployment diagram to show the communication flow within the system.
5.3.1
UML 2 Deployment diagram
A UML deployment diagram [56] depicts a static view of the hardware of the system,
the installed software on that hardware, and the middleware used to connect the
components to one another.
Figure 5.1 presents an example of a fully rendered UML 2 deployment
diagram for Usario. The three-dimensional boxes represent nodes, either software
or hardware. Connections between nodes are represented with simple lines, and are
assigned stereotypes such as WLAN, LAN and direct cable to indicate the type of
connection.
5.3.2
UML 2 Deployment diagram showing interaction between actors
Figure 5.2 is an informal deployment diagram showing the communication flow
between all the actors of the system. The actors are the same as those specified
in section 3.2.1. The main components of Usario communicate by a flat cable while
Usario itself communicates with the control unit by Wireless LAN. Communication
between the user terminal and the control unit can be both by wired or wireless
ethernet. The preferred means of communication between the Backup pc and the
control unit is by wired ethernet, 802.11g.
62
CHAPTER 5. DESIGN
Figure 5.1: UML 2 deployment diagram for Usario
5.4
System architecture
The robot model consists of three computing units:
• RCX - A Lego RCX running on Hitachi H8300 CPU.
5.4. SYSTEM ARCHITECTURE
63
• camera - An internet camera with an inbuilt webserver.
• PC unit - A standard PC unit capable of executing programs and
communicating through both wired and wireless ethernet.
There are three communication interfaces: between the RCX and camera, between
the RCX and control unit and between the camera and the control unit. The RCX
communicates with the control unit in two ways: (1) through the IR tower and
(2) via the camera through wireless ethernet. Figure 5.3 depicts the architecture
of the software and hardware components of Usario. The lowest layer of the
architecture contains the data link and physical layers of the OSI Model, the
hardware components and wireless ethernet. The operating systems of both Usario
and the PC are contained in the layer composed of the network and Transport layers
along with the LNP (Layered Networking Protocol) contained in the LeJos package.
The top row represents the session, presentation and application layers, and contain
the applications residing in the RCX, control unit as well as the Telnet interfaces.
The IR and the LNP is contained in the application layer of the PC, while in the
RCX, LNP is contained in the network layer. The class Linefollower represents the
RCX program which allows Usario to navigate throughout the site. It uses the class
WifiCommRCX to send data to the camera and communicates with the IR tower
(connected to the PC by a USB cable) through the LNP. On the other side, the PC
program consists of TestDetect, Detect, WifiCommPC and IdentifyHuman. The
Detect class is a C++ compiled DDL file which enables the TestDetect java class
to specify colour parameters for colour detection. IdentifyHuman is a java class
that completes the object recognition and detection function. The TestDetect class
also contains a function to access images from the camera by Telnet. Finally, the
WifiCommPC is the class responsible for wireless communication, mainly with the
RCX.
64
CHAPTER 5. DESIGN
Figure 5.2: Diagram showing the actors and their communication flow.
5.4. SYSTEM ARCHITECTURE
Figure 5.3: Overall architecture of the system.
65
Chapter 6
Implementation
This chapter describes and evaluates the choice of a programming language. It also
describes the physical asembly of the robot and concludes with the physical site up
of the site.
6.1
Choosing a programming environment
After having described the different alternatives of programming environments for
the RCX in section 2.5, the following sub-sections evaluates each of them and justifies
the choice of the programming language to be used.
6.1.1
Evaluation criteria
The choice of a programming language is a key issue in the development of safety
critical systems. Some languages offer safety enhancing language features, such as
good exception handling mechanisms, while others have been found to be error
prone. Based on N. Storey’s Safeware [7], there are three considerations in the
choice of a programming language.
1. Characteristics of the language. According to N. Storey’s [7], Carre
has identified several characteristics of a programming language that has
implications for the safety of a system:
• logical soundness: is there a sound, unambiguous definition of the
language?
67
68
CHAPTER 6. IMPLEMENTATION
• complexity of definition: complexity in the definitions of the language
features result in complexity within compilers and other support tools,
which can lead to errors.
• expressive power: can program features be expressed easily and efficiently?
• security and integrity: can violations of the language definitions be
detected before execution?
• verifiability: does the language support verification?
• bounded space and time requirements: can it be shown that time and
memory constraints will not be exceeded?
She claims that even a programming language that is developed specifically
for use in critical applications, may not be an ideal language when analyzed
with respect to these characteristics. This is because many of the above
factors are in conflict, like having great expressive power often makes the
language complex, which increases the problems of verification and security.
Even though no programming language is “safer” than others, some languages
are more suitable than others for the production of critical software because
they make it easier to produce reliable code.
2. Availability and quality of support tools. It is also important to consider
the development tools available to support a language. The quality of the
compiler is specially important. N.Storey [7] states that validation must be
a requirement for the compiler in the safety-critical systems. A validation
of a compiler is a process that is performed to determine conformity to the
language standard and such validation does not guarantee the correctness of
the code generated by the compiler.
3. Expertise within the development team. Programmers that are familiar
with a programming language are more likely to make fewer mistakes and be
more productive in this language.
6.1.2
Evaluation of available programming languages
Following the evaluation in criterias listed in section 6.1.1, the three most suitable
programming languages for this project are Java , C and FORTH. Based on the
criteria of expertise and experience within the development team, FORTH is ruled
out. In a technical report about assessment of Java as a programming language [14],
Java is evaluated as regards to safety and it was found that it has both strengths
and weaknesses. Java provides excellent means of modularizing and structuring
6.2. PHYSICAL ASSEMBLY OF USARIO
69
problems. Furthermore, Java supports concurrent execution of multiple threads and
some synchronization mechanisms. Java’s main weaknesses are that reference types
are not generally amenable to static checking, side effects can occur in expression,
and some returned values may quietly be discarded. Moreover, the formal definitions
and semantics that exist in Java are mainly concerned with parts of the language.
Timing analysis is also difficult to perform on Java code, as is resource usage analysis.
In M.Barr’s “Is C passing?” [8], C is compared to Java with respect to what Barr
considers as the three most essential qualities of a language that should ensure
safety. These qualities are the ability to support exceptions, strict syntax rules and
being strongly typed. Barr found that C fails on the first two counts, while Java
meets all three requirements. In addition, Java offers language-level support for
multi-threading which according to Barr enhances program portability.
6.1.3
Conclusion
Based on this evaluation, Java is the logical choice as programming language for
Usario. It seems natural to me to use Java to program the RCX rather than use C
or Forth. Of course, there’s nothing wrong with these programming environments
but Java has outlived its initial hype and has grown steadily to become a standard
object-oriented programming language.
6.2
Physical assembly of Usario
The following shows a list of parts used for the assembly of Usario (see section
components of Lego Mindstorms - 2.4.1 and Robot vision- section 2.4.2 for more
details), the modifications made to the DCS5300G camera, and a short discussion
about the placements of the components.
• Lego parts. The lego parts used in the building up of Usario is shown in
table 6.1. 2
• Internet camera: D-link DCS-5300G. The standard Dlink internet
camera came with a power cord, which means that the camera had to be
constantly powered up using that cable, which defeated our objective of being
wireless. The power specified was ‘12VDC 1.5A’ [49], which was just enough to
be replaced by 10 rechargeable AA batteries. The camera was then configured
through the CD program that it originally came along with.
2
The number is undefined because the quantity has not been recorded.
70
CHAPTER 6. IMPLEMENTATION
Name
RCX 2.0
Lego motors
Light sensor
USB Tower
lego bricks & parts
Quantity
1
2
1
1
N.A 2
Table 6.1: The lego parts used.
Figure 6.1: Front view of Usario
• PC components. The PC unit used is a notebook computer running at a
clock speed of 2.0 GHz and Microsoft Windows XP as operating system. It
contains the control unit program, the user program and it has appropriate
sound and graphics card. The pc unit is also internet connectable using both
cable and wireless technologies.
• Power. Six 1.5V AA batteries for the RCX, 10 1.5 AA batteries for the
webcamera supply the necessary power required.
• Part placements. The RCX is placed on top of Usario, constantly facing
upwards towards the ceiling. Also, the RCX is placed on the back of Usario to
counteract the weight of the camera, which is placed at the front end. Some
6.2. PHYSICAL ASSEMBLY OF USARIO
71
Figure 6.2: Back view of Usario
Figure 6.3: Side view of Usario
lego blocks of heavy mass are used to balance weight on both ends. The center
of gravity of Usario should then be lying along the vertical axis of the wheels.
72
CHAPTER 6. IMPLEMENTATION
Figure 6.4: Top view of Usario
• physical dimensions The dimensions of Usario are: 280mm X 170mm X
190mm (length X width x height), and weighs 935 grams.
6.3
Physical setup of site
The essential details of the experiment site is described as follows:
• Humans Dead humans are represented by some red troll figures found in
children’s toy boxes. Alive humans have however been constructed using green
lego bricks.
• Site dimensions The prototype site dimension is 1.4m X 1.6 m. The site floor
has 4 rooms, with one entry/exit point. Figure 6.5 shows the site model.
• Material. Some teck wood has been used to make both the outer walls of the
site and separating walls which will simulate rooms.
• Placement of IR tower. The IR tower is configured to operate in long range
distance and is placed on top of the site, suspended by wires from the ceiling,
6.4. PROGRAMMING USARIO
73
Figure 6.5: The experiment site
and is connected to a portable pc by use of a USB cable. This strategy of
positioning the tower is to allow a maximum coverage area by the tower.
• Communication. The PC used for the control unit is equipped with both wired
and wireless Ethernet facilities.
• Wireless Access point. The camera is using the faculty’s wireless access point.
A request was made to the network administrator and the camera was granted
10.120.31.16 as IP address. The settings for the control unit are shown in table
6.2.
6.4
Programming Usario
Table 6.3 shows the main system files of Usario. The main files together with
their requirements are listed and together with the other files are available on the
accompanying CD. Figures 6.6 and 6.7 show some screen shots of the site as seen
74
CHAPTER 6. IMPLEMENTATION
Item
Hostname
IP address
Subnet mask
IP Gateway
SSID
WEP key
Operating mode
wireless channel
Description
The name of DCS5300G
to be used for wireless
LAN communication
IP address
Subnet mask
Gateway address
The name of the
Wireless LAN network
to be used
The character string
to be used as the
key for encrypting data
transmission over the
wireless LAN
Infrastructure mode
or ad hoc demo mode
channel between 1 and 11
Default setting
DCS5300G
10.120.31.16
255.255.255.0
10.120.31.1
IDIlab
toysrus
ad hoc
1
Table 6.2: Internet camera network settings
on a user terminal.
Requirement
Navigation
Detection
Communication
filename
Linefollower.java
TestDetect.java
WifiCommRCX.java
WifiCommPC
Table 6.3: Table showing appropriate system files in appendix
6.4. PROGRAMMING USARIO
Figure 6.6: Screen shot of user program showing two humans detected
Figure 6.7: Screen shot of user program
75
Chapter 7
Results
This chapter summarises the identified safety and security requirements that need
to be satisfied in the development of USAR robots. These requirements have been
identified in the risk management process, but are not an exhaustive list as further
analysis and testing will reveal more system hazards. The following results list
describes the identified safety specifications and the security issues. Note that
most of the critical hazards (class types I and II) that have been identified, have
been treated accordingly, while the other specifications have only been recorded
during the conduct of the experiment (purely based on observation and marked as
‘Observation’.
Based on the table 4.9 in section Evaluate Risk - , the safety requirements
for the design of an Urban Search and Rescue robot are:
1. Robot MUST detect all humans wherever there are humans.
requirement)
(Detect
2. Robot must be able to navigate throughout the entire site.(Turn, move,
follow requirements)
3. Robot must be able to notify control unit about its own position at any time.
(Report requirement)
4. Robot must be able to notify control unit about the location of victims within
the shortest delay.(Report requirement)
5. Communication must be error-free and reliable.(Communication requirement)
6. Access to data must be controlled.(Communication requirement)
77
78
CHAPTER 7. RESULTS
7. There should not be any buttons easily available to unauthorized personel to
tamper with. (Observation)
8. Battery/power level must always be monitored. (Move requirement)
9. Robot MUST NOT bump into humans. This would injure or deteriorate
victims conditions. (Detect requirement)
10. Robot must back up on its original track in case of some malfunctions or
physical damages.(Turn, move, follow requirement)
11. Robot must use the least time possible to accomplish its mission. (Turn,
move, follow, report, locate requirement)
12. In case robot fails to perform according to established procedures, operator
must take control over the system.(Observation)
13. Robot must operate independently in case of component/system failure.
(Observation)
Whereas the security requirements are
1. Only authorized personnel can have access to the system. The use of login
and password is recommended.(Validation requirement)
2. Access to the system is restricted to an authorized personnel holder of a private
key or certificate (Authentication requirement).
3. Make use of virtual private network so as to ensure an encrypted tunnel
of communication shutting down the threat of hackers tapping into the
system.(Reliability, integrity requirements)
4. Back up of data must be done as often and quickly as possible.(Observation)
5. Back up server must be at a different location, other than on site.(Observation)
Chapter 8
Own contribution
This chapter describes one major finding while conducting this experiment. According to the Lego company official website [22], the Lego RCX processor usually
communicates with another computing unit solely by the use of IR light, related
by an IR tower. This communication medium turned out to be rather unstable
and unreliable for the purpose of this experiment. However, an alternative way of
communication was found and is further described.
8.1
RCX communicating through wireless ethernet
While installing and configuring the D-link DCS-5300G w/802.11g, it was found that
the camera has an Input/Output connector i.e. it is designed to output a signal to a
siren when it is configured to detect motion. Extract from D-link’s product manual
[49], page 6 & 7;
“... The DCS-5300G provides a terminal block with two pairs of
connectors situated on the back panel. One pair is for input and the
other for output. The I/O connectors provide the physical interface to
send and receive digital signals to a variety of external alarm devices. ...
”
This leads to the conclusion that this same input/output port could instead be
used to send and receive data from another device, like the RCX. This provides an
alternative to the unreliable communication via the IR tower.
79
80
CHAPTER 8. OWN CONTRIBUTION
Recall that the RCX has a maximum of three inputs (See ‘input ports’ 2.4.1).
The inputs of the RCX become the output of the camera and the input of the
camera is connected to one of the outputs of the RCX (since two of three available
outputs are connected to the motors). Consequently, the implementation of an
alternative communication between the RCX and the camera is implementable,
thereby eliminating the use of the unreliable Infra red communication medium.
Therefore, the system is modified to accomodate the connection between the
RCX and the DCS5300G camera. The camera is connected by a 4-pin flat cable to
the RCX, and both are now communicating to the server only by wireless signals.
However, programs are still downloaded to the RCX by using the Lego IR tower.
The picture 8.1 shows the Input/Output port of the camera where the 4 pin cable
is plugged into for communication with the RCX.
Figure 8.1: Input/output port of DCS5300G [49]
Chapter 9
Conclusion and further work
9.1
Conclusion
The emergence of new technologies and progress in the field of science is turning
USAR robots into even more efficient, reliable and powerful tools than they are
today. However, despite a high level of sophistication, 100 % safety and security
will never be achieved in any system but still it is worth trying to build a safety
critical system. The use of robotics is gaining in importance in rescue operations
as characterised by their increasing use as a complementary aid to rescuers. Using
Lego Mindstorms to model a USAR robot, gave us a better insight about the safety
and security aspects of USAR robots. This simulation experiment brought forward
some valuable information (see Results 7) one would need to build a safety critical
system for a USAR robot. In this project, I have dealt with only a one-floor crash
site but in a real life situation, crashed sites are far more complex and unpredictable.
9.2
Further work
While performing this experiment, some aspects of the robot have been found to
have an improvement potential. Improving these aspects could make our robot even
more performant. In a future assignment, more focus and efforts could be put into
the following:
(a) to find a quicker, more reliable and safer communication medium between
robot software system, camera and PC program. A possible solution could
be the use of a specific transport protocol like Profibus [45]. It is a low
level communication channel that is standardised in IEC61508 for safety
81
82
CHAPTER 9. CONCLUSION AND FURTHER WORK
automation.
(b) to implement a navigation system to keep track of the position of the travelling
robot within this context. Indoor GPS could be an alternative to the Line
follower for a navigation system as it would also enable localisation of objects
and the robot itself, and be used to avoid obstacles.
(c) to find an alternative to touch sensors as it is impractical to have the same degree
of sensitivity as it collides with different types of objects. (i.e for humans and
small dangerous objects,sensitivity must be set to very high otherwise it would
bump into them. For bigger objects, like debris/obstacles sensitivity should
be low otherwise it would be a waste of time to avoid small obstacles while
the robot could go over them.
(d) to equip the robot with a lighting system so as to enable the robot to operate
in poor light conditions.
(e) to improve on the physical building up of the robot. The robot should be able
to climb over obstacles and have better wheels for better grip of the ground
floor (like the wheels of a tanker or a ‘caterpillar’). An alternative could be
to acquire the crawler robot of Inuktun services [32] and modify the software
system accordingly.
More challenging:
(f ) In addition to a better localisation system, a software could be implemented
to enable 3D visualisation of the site. A three dimensional map would help
resucers to get a quicker and more accurate picture of the rescue site.
(g) As a safety precaution, an improved mechanism for detection of humans should
be considered. In addition to object detection by camera, one could consider
detecting humans by Carbon Dioxide, temperature or even by the presence
of blood. There are a wide range of sensors on the market that are made
to detect specific gases, temperature and some recognition of liquids. An
improved detection mechanism could be by detecting the presence of Carbon
Dioxide and/or the use of heat sensors.
Appendix A
List of Abbreviations
AS/NZS - Australian Standard /New Zealand Standard
FMEA - Failure Modes and Effects Analysis
FTA - Fault Tree Analysis
GPS - Global Positioning System
HazOp - Hazards and Operability Analysis
IEC - International Electrotechnical Commission
IP - Internet protocol
IR - Infra Red
LAN - Local Area Network
LNP - Layered Network Protocol
NASA - National Aeronautics and Space Administration
OS - Operating System
OSI - Open System Interconnection
PHA - Preliminary Hazard Analysis
PC - Personal Computer
RCX - Robotics Command Explorer
SSID - Service Set Identifier
UML - Unified Modeling Language
USAR- Urban Search and Rescue
WEP - Wired Equivalent Privacy
WLAN - Wireless LAN
83
Appendix B
PHA introduction
85
86
APPENDIX B. PHA INTRODUCTION
87
88
APPENDIX B. PHA INTRODUCTION
89
90
APPENDIX B. PHA INTRODUCTION
91
92
APPENDIX B. PHA INTRODUCTION
93
Appendix C
PHA presentation
95
96
APPENDIX C. PHA PRESENTATION
97
98
APPENDIX C. PHA PRESENTATION
Appendix D
PHA Session sheet
99
100
APPENDIX D. PHA SESSION SHEET
101
102
APPENDIX D. PHA SESSION SHEET
Appendix E
Hazop introduction
103
104
APPENDIX E. HAZOP INTRODUCTION
105
106
APPENDIX E. HAZOP INTRODUCTION
107
108
APPENDIX E. HAZOP INTRODUCTION
109
110
APPENDIX E. HAZOP INTRODUCTION
111
112
APPENDIX E. HAZOP INTRODUCTION
113
114
APPENDIX E. HAZOP INTRODUCTION
115
116
APPENDIX E. HAZOP INTRODUCTION
Appendix F
Hazop Session Sheet
117
118
APPENDIX F. HAZOP SESSION SHEET
119
120
APPENDIX F. HAZOP SESSION SHEET
121
122
APPENDIX F. HAZOP SESSION SHEET
123
124
APPENDIX F. HAZOP SESSION SHEET
125
126
APPENDIX F. HAZOP SESSION SHEET
Bibliography
[1] G.Ferrari. Lego Mindstorms with Java Syngress Media, 2002.
[2] B.Bagnall. Core Lego Mindstorms programming Prentice Hall, 2002.
[3] Nancy G. Leveson. Safeware: System safety and computers Addison-Wesley
Publishing Company, Inc. 1995.
[4] Charles P. Pfleeger. Security in Computing Prentice Hall,2003.
[5] Blen Bruce. Security in distributed computing Prentice Hall,1997.
[6] D.Baum. Definitive guide to lego programming Apress, 2000.
[7] N. Storey. Safety-critical computer systems Addison-Wesley,1996.
[8] Michael Barr. Is C passing? embedded.com, May 2002.
[9] Marvin Rausand. Risiko Analyse: veiledning til NS 5814 Tapir Trykk, 1991.
[10] B.P.Douglas. Doing hard time: Developing real-time systems with UML, objects,
frameworks, and patterns. Addison-Wesley, 1999.
[11] M. Fowler. UML Distilled Second edition: A brief guide to the standard object
modeling language. Addison-Wesley, 1999.
[12] Felix Redmill, M.Chuddleigh, J.Catmur. System Safety: Hazop and Software
HAZOP John Wiley & sons , 1999.
[13] Karine Sørby. Relationship between security and safety in a security-safety
critical system: Safety consequences of security threats IDI, NTNU, 2003.
[14] Jagun Kwon, Andy Wellings and Steve King. Assessment of the Java
programming lanugage for use in High Integrity Systems. Technical report.
Department of Computer science, university of York, UK. 2002.
127
128
BIBLIOGRAPHY
[15] ISO/International Electrotechnical Commission 13335, Information Technology. Guidelines for the management of IT security. Available from
http://www.iso.ch
[16] ISO/International Electrotechnical Commission 17799, Information Technology. Code of practice for information security management. 2000.
[17] International Electrotechnical Commission. Functional safety of Electrical/Electronic/Erogrammable electronic (E/E/PE) Safety Related Systems.
2000.
[18] International Electrotechnical Commission. Functional safety of Electrical/Electronic/Programmable electronic safety related systems, part 1: General
requirements. 1998.
[19] Institute of Electrical and Electronics Engineers, Inc. Recommended practice
for Architectural Description of Software-Intensive Systems.
[20] Strathfield: Standards, Australia Australian/New Zealand Standard S/NZS
4360:1999 Risk Management.
[21] Institutt for Energiteknikk, NTNU, 2001 State-of-the-art and Evaluation of
Established Risk Analysis for their Applicability to Security-Critical Systems.
[22] Lego inc. Lego Mindstorms home Available from http://mindstorms.lego.
com/eng/default.asp accessed 15.09.2005.
[23] http://www.lugnet.com accessed August 15.09.2005.
[24] http://www.forth.org/ accessed August 15.09.2005.
[25] http://www.hempeldesigngroup.com/lego/pbForth/homePage.html
accessed August 2005
[26] http://bricxcc.sourceforge.net/nqc/ accessed August 15.09.2005.
[27] leJOS Available from http://lejos.sourceforge.net/ accessed August
15.09.2005.
[28] TinyVM - Java VM for Lego Mindstorms RCX Available from http://
tinyvm.sourceforge.net/ accessed August 15.09.2005.
[29] leJOS API Available from http://lejos.sourceforge.net/apidocs/index.
html accessed August 2005
BIBLIOGRAPHY
129
[30] Jonathan Knudsen. Imaginations run wild with Java Lego robots Available
from http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-lejos_
p.html accessed 15.09.2005.
[31] iRobots inc. Robots for the real-world. Available from http://www.irobot.com
accessed 27.09.2005
[32] Inuktun Services Ltd. Inuktun Services Available from http://www.inuktun.
com/ Accessed 27.09.2005
[33] NASA. Urbie- Urban Robot project Available from http://robotics.jpl.
nasa.gov/tasks/tmr/homepage.html accessed 27.09.2005
[34] National geographic News. Search-and-Rescue Robots Tested at New York
Disaster Site Available from http://news.nationalgeographic.com/news/
2001/09/0914_TVdisasterrobot.html Accessed 27.09.2005
[35] RoboCup. Robocup official site Available from http://www.robocup.org/
Accessed 27.09.2005
[36] RoboCup Rescue. RoboCup Rescue official page Available from http://www.
rescuesystem.org/robocuprescue/ Accessed 27.09.2005
[37] RoboCupJunior. RoboCup Junior official page Available from http://www.
robocup.org/junior/index.html 27.09.2005
[38] Carnegie Mellon press Carnegie Mellon press release Available from http://
www.cmu.edu/PR/releases05/050210_marines.html Accessed 30.09.2005
[39] Kobe University. Utility Vehicle for Search version IV Available from http:
//www.rescuesystem.org/robocuprescue/UVS.pdf Accessed 30.09.2005
[40] BAE systems. BAE systems Available from http://www.uniteddefense.com/
Accessed 30.09.5002
[41] BBC news. London attacks Available from http://news.bbc.co.uk/
1/shared/spl/hi/uk/05/london_blasts/html/default.stm
Accessed
11.09.2005
[42] BBC news. 11 September Available from http://news.bbc.co.uk/cbbcnews/
hi/find_out/guides/newsid_2209000/2209407.stm Accessed 11.09.2005
[43] BBC news. Bali bomb attack Available from http://news.bbc.co.uk/1/hi/
world/asia-pacific/4300274.stm Accessed 11.09.2005
130
BIBLIOGRAPHY
[44] BBC news. Terror attack in Egypt Available from http://www.
somethingjewish.co.uk/articles/1216_terror_attack_in_egy.htm
Accessed 11.09.2005
[45] http://www.knowthebus.org/fieldbus/profibus.asp
[46] Risk Analysis, Assessment and Management Available from http://www.nr.
no/~abie/RiskAnalysis.htm Accessed 06.10.2005
[47] Risk-based Decision-making Guidelines: vol 3 Available from http://www.
uscg.mil/hq/g-m/risk/e-guidelines/RBDM/html/vol3/00/v3-00.htm Accessed 12.10.05
[48] Jacob’s Sverdrup. Preliminary Hazard Analysis Available from http://www.
sverdrup.com/safety/pha.pdf Accessed 13.10.05
[49] Dlink. Wireless Security camera-DCS-5300G Available from http://www.
dlink.com/products/?pid=342 Accessed 07.11.05
[50] Lego inc. Lego Mindstorms- vision command Available from http://http:
//mindstorms.lego.com/eng/products/vc/index.asp Accessed 07.11.05
[51] SourceForge.net Open computer vision library Available from http://
sourceforge.net/projects/opencvlibrary/ Accessed 07.10.05
[52] Petrovic. Pavel Petrovic homepage Available from http://www.idi.ntnu.no/
~{}petrovic/ Accessed 25.09.2005
[53] AI group IDI, NTNU. AI Group - Eval. Available from http://www.idi.ntnu.
no/grupper/ai/eval/software.html Accessed 07.11.05
[54] The university of Texas at Austin. RRG Research Indoor GPS Metrology System
and Modular Robot Metrology and Calibration Available from http://www.
robotics.utexas.edu/rrg/research/metrology/ Accessed 11.11.2005
[55] IEEE. IEEE 802.11, The Working Group for Wireless LANs Standards
Available from http://grouper.ieee.org/groups/802/ Accessed 05.12.2005
[56] Agile Alliance Inc. Agile Modeling (AM) Home Page: Effective Practices for
Modeling and Documentation Available from http://www.agilemodeling.
com/ Accessed 12.12.2005
[57] Frank van Diggelen & Charles Abraham . Indoor GPS: The No-Chip Challenge
- GPS World Available from http://www.gpsworld.com/gpsworld/article/
articleDetail.jsp?id=3053 Accessed 11.09.2005
Index
access, 60
accident, 14
accountability, 16
asset, 16
attack, 16
authenticity, 16
availability, 16
intoduction, 20
harm, 14
hazard, 14
hazardous event, 14
hazardous situation, 14
HazOp
intoduction, 19
humans
definition, 31
camera
models, 25
Dlink, 27
Lego, 25, 27
technology, 25
communication, 59
concept
definition, 43
confidentiality, 16
control, 16
control system, 14
identification, 58
Implementation, 67
programming, 73
site setup, 72
incident, 14
information security, 17
Information system, 17
integrity, 17
interlock mechanism, 15
IR tower, 23
IT security policy, 17
design
system architecture, 62
deployment diagram, 61
system design, 57
detection, 58
Dlink
Internet Camera, 26, 27
Java, 30, 68, 69
Lego
motors, 24
sensors, 23
light sensor, 24
touch sensor, 24
Vision Command, 27
Lego Mindstorms, 21
legOS, 29
leJOS, 29
localisation, 59
error, 14
failure, 14
fault, 14
FMEA
introduction, 20
FTA
131
132
monitoring system, 15
navigation, 57
non-repudiation, 17
NQC, 29
pbForth, 29
PHA
intoduction, 19
power, 60
Preliminary requirements
Evaluation, 57
programming environment, 28
protection system, 15
RCX
programming environment, 28
reliability, 17
reporting, 59
Requirements
Functional, 40
Non-Functional, 31, 41
requirements
preliminary requirements evaluation, 57
risk, 10, 15, 17
Risk Analysis, 43
Analyze risk, 49
classification of risks, 44
interpretation of risks, 44
Preliminary analysis, 44
Risk identification, 48
Risk management, 10, 48
Risk management terminology, 10
safety requirements specification,
46
safeguard, 15
Safety
definition, 14, 15
introduction, 14
life cycle, 15
INDEX
requirements specification, 15, 46
Safety Management, 10, 14
system, 15
system error, 15
terminology, 14
Safety critical system, 15
scope
definition, 43
Security
definition, 16
introduction, 16
Security management, 10, 16
terminology, 16
security critical system, 17
speed, 60
stakeholder, 15
System
description, 31
environment, 15
failure, 15
Safety critical system, 15
system
system architecture, 62
threat, 15, 17
TinyVM, 30
UML, 57
Urban Search And Rescue Robots, 1
USAR, 1, 7
development of, 7
Usario
name, 31
Use case, 32
actors, 32
specifications, 35
vision, 25
vulnerability, 17
weakness, 17