155
1 INTRODUCTION
The security aspects of robotic research generally
receive much less attention, which can be partly
reflected by the lower number of search results related
to “robotic security” as shown in Table 1. As robotic
systems become more powerful and easily accessible
to the public, the lack of security awareness provides
attackers with growing opportunities to cause massive
damage to lives and properties. The situation is
further exacerbated if we incorporate Robots-as-a-
Service (RaaS) concept and introduce more user types
and complexities to the system. Our work hence
attempts to provide a viable solution that fulfils both
the need for a secure system and the need for online
delivered robotic service.
Table 1. Search terms entered to Google Scholar and the
respective number of returned results.
_______________________________________________
Search terms Number of results in thousands
_______________________________________________
robotics 2150
robotic 1770
robotic system 1520
robotic control 1480
robotic artificial intelligence 440
robotic security 153
_______________________________________________
Teleoperated UVs have been existing for over half
a century and are traditionally deployed in extreme
environments such as nuclear plants, deep-sea, and in
space [13]. With the latest advancement in capabilities
of UVs, teleoperation is getting more involved in
more diverse use-cases to assist human operators [3,
12]. As the number of scenarios where UVs could be
utilised grows, we envision the emergence of a market
spectrum that offers various kinds of robotic services
to customers [21]. These services will likely be
accessible through the internet via standard browsers
to allow for easy access of a wide range of possible
users [19]. On the other hand, up-scaling these
A Web-oriented Architecture for Deploying Multiple
Unmanned Vehicles as a Service
C.N. Au, C. Delea, V.E. Schneider, J, Oeffner & C. Jahn
Fraunhofer Center for Maritime Logistics and Services, Hamburg, Germany
ABSTRACT: Providing a robotic-assisted service in scenarios involving multiple Unmanned Vehicles (UVs) in
possible beyond-visual-Line-Of-Sight (LoS) operations, safety and security are critical concerns. We develop a
web-oriented, human-in-the-loop infrastructure to explore how the service provider can secure their system,
enforce instant access control over dynamic operator-robot connections, and ensure the integrity, availability,
and traceability of communicated data. Our proposed minimal viable solution requires an authentication server
to verify user identity, a back server with a database to handle user requests and state-transition events, and a
RabbitMQ (RMQ) server to trace the origin of data.
http://www.transnav.eu
the International Journal
on Marine Navigation
and Safety of Sea Transportation
Volume 15
Number 1
March 2021
DOI: 10.12716/1001.15.01.15
156
systems will raise challenges related to performance,
security, and safety regulations [26]. The security
aspect of robotics research is often neglected, giving
attackers chances to take over and potentially cause
physical damage [9]. The Robot Operating System
(ROS), for example, though widely used in robotics
research, is not secure enough to be accessed publicly
unless a series of security hardening is done [10].
As an effort to overcome these problems, we
propose a web-based, service layer that is built upon
mature open-source software. There are currently
multiple implementations still under active
development. An early version of our service layer is
implemented in the Robotic Vessels as-a-Service
(RoboVaaS) project, which aims to create a direct
communication channel between the port customers
and professionals that perform five oceanographic
services, such as quay-wall inspection and
environmental data collection [23]. In the European
Union (EU) project Shipping Contributions to Inland
Pollution Push for the Enforcement of Regulations
(SCIPPER) [24], the service layer is named
Environmental Shipping Monitoring Center (ESMC)
and focuses on collecting data from environmental
sensors and provides a web interface for visualising
emission information. In the Horizon 2020 funded
project SEarch, identificAtion and Collection of
marine Litter with Autonomous Robots (SeaClear),
the service layer interfaces with a team of
heterogeneous robots (air- and waterborne) and
assists with marine litter clean-up operations. In
another EU project Risk-aware Autonomous Port
Inspection Drone (RAPID), the service layer is
officially called Command and Control Center which
instantiates a customer service-request web interface
and the operator mission-support interface. In
general, these implementations are designed to be
working closely as an integrated environment with
managers, engineers, operators, and clients, who
expect to track progress and analyse results of services
involving off-shore electronic or robotic systems
without the need to understand intricate details. On
the other hand, the online delivered robotic services
are not focusing on creating external interfaces for
directly commanding robotic systems.
2 APPORACH
We adopted a microservice architecture and split the
whole system into several computational components
which communicate with each other through a set of
well-defined and transparent Application
Programming Interfaces (APIs) over Hypertext
Transfer Protocol (HTTP) protocol. In this way, each
microservice can focus on its core functionalities and
offload computation to other responsible services. For
example, the encryption and decryption of
authentication token are handled solely by the
authentication server. When the back server processes
a user request, it can simply call the decode API of the
auth server to retrieve the user’s identity information
from the token, without the need to implement
another authentication algorithm. Moreover, as
explained in [8], by decoupling the overall system in
microservices, various cloud-based services can be
exploited to fulfil the requirements of the different
users involved in operating complex robotic systems.
The reliability overall is also enhanced since the crash
of a particular microservice does not result in a
complete system meltdown.
We use a centralised approach to manage overall
system states and access control policies of data
channels. Although peer-to-peer communications in a
decentralised setup have less overhead and fewer
dependencies, we believe the service provider should
possess ownership of data channels and have the
power to immediately alter the system state in case of
malicious activities or emergencies. By accessing the
broker services the service provider can also verify the
source and time of any communicated data.
To reduce duplication of effort, we strive to reuse
as much mature and open-sourced technologies as
possible. For example, service logic is mainly written
in Javascript and run in NodeJS servers. User data and
state information are stored in a PostgreSQL database.
This approach allows us to focus on tackling logic that
addresses problems specific to a particular use case.
Interfacing the service layer with other robotic
systems requires services to translate data. For
example, Rosbridge [6] is required to convert data
between the ROS message format and the AMQP or
WebRTC protocols. Another issue associated with
ROS middle-ware or Data Distribution Service (DDS)
is that they do not offer mechanisms to force an
established communication to hang up. Due to these
incompatibilities, our approach is to create a bridge
node and treat it as a single monolithic vehicle.
3 SYSTEM FEATURES
The aspired service layer serves to provide business
logic and to handle data according to a large set of
different use-cases for various sectors and
applications. Our implementation supports the
following functionalities or features:
− Accessibility through internet: The service layer
acts as the frontier facing end-users (or clients) and
should be publicly accessible as a website. It
should follow the latest security standards while
leveraging the capabilities of modern browsers.
For example, communication channels should
conform to secure protocols such as Transport
Layer Security (TLS) and Datagram Transport
Layer Security (DTLS), to prevent eavesdropping
of network packets and to ensure the integrity of
data. To mitigate vulnerabilities related to Cross-
Origin Resource Sharing (CORS), we deploy a
front server that is in essence an Nginx-based
reverse proxy server, to tunnel communications
between client and servers. In this way, the front
server acts as a single point of