Ubuntu Core and Kura:

A framework for IoT gateways

October 2018

Abstract
Ubuntu Core is an important revolutionary step for Ubuntu. Whilst building
upon Linux traditions, Ubuntu Core focuses on predictability, reliability
and security while at the same time enabling developer freedom and control.
It provides a trusted platform to deploy edge gateway solutions, such as Kura,
an extensible open source IoT Edge Framework based on Java/OSGi.

The Linux distribution model, whilst established and well understood for
computing, has some limitations when it comes to IoT devices, or more specifically,
IoT edge gateway devices. With such devices operating largely unattended, due to
often being located in remote or hard to access areas, there is a greater demand
for a system that offers both high levels of robustness and security. Therefore
having a standard Linux distribution as the base is often not the optimal choice.

Although it is possible to use a standard Linux distribution, the project can often
be made more challenging due to the more generalist nature of these. In essence,
whilst they are capable of doing the job, it will likely lead to problems and greater
complexity, putting the success of the project at risk in the process. Such systems
usually lack a clear update story, creating security risks caused by an unmaintained
system. Updates are often deferred because they are identified as risky operations,
without a good recovery path. This makes such systems an unsuitable fit for
unattended devices.

Although it doesn’t provide a solution to the aforementioned issues, Eclipse Kura

does offer a solution when looking for an industrial gateway framework. Kura, is
an OSGi based application framework for machine to machine service gateways.
However, whilst Kura provides a framework on which to build a gateway product,
it does not address the problems presented by standard Linux distributions, and it
requires a more solid operating system on which to build on. This is where Ubuntu
Core and the innovative snap packaging comes in to play. Snap packages are self
contained, working across a wide range of Linux distributions and they are
updated via atomic operation. Ubuntu Core is a Linux distribution, built entirely
from snap packages, allowing transactional updates to each key component.

IoT gateways are positioned between edge systems and the cloud, performing
such functions as; protocol translation, data processing/storage/filtering,
and device security. The gateway allows for the efficient collection and secure
transportation of data from devices, remote users and applications.
 Description
Background: IoT gateways

The IoT gateway market has been growing at a fast pace in recent years and
continues to grow even more rapidly – mostly due to increasing demand for big
data collection and analytics. According to a global study by Technavio in 2017,
the industrial IoT gateway market alone will grow to around $1.4 billion by 2021.
The wider picture being that without IoT gateways, the economic impact of
the IoT industry may not be fully realised. Consulting firm McKinsey puts that
impact as being between $3.9 trillion to $11.1 trillion a year by 2025 making it,
an opportunity that shouldn’t be undermined by using unsuitable tools.

According to the Technavio report, the main reasons for growth in this
market are:

• A rising need to achieve competitive advantages

• New technical advancements and capabilities in industrial IoT gateways

• Increased amount of data generation due to industrial IoT use cases

Advances in miniaturisation, power efficiency, cost and a much better set of

software stacks to choose from are also contributing to the growth of IoT
gateway adoption as a whole.

One such software stack that has greatly simplified the process of developing
an IoT gateway product is Eclipse Kura. Kura is a gateway development platform
that provides the frameworks, APIs, tools, examples and documentation needed
to create a new IoT gateway from scratch.

However, there is one major component missing from Kura that is essential, a
base operating system to run on the hardware that Kura will run on top of –
which is where Ubuntu Core comes in.

Before discussing the security features and design of Kura and Ubuntu Core, it
is helpful first to understand the history and background of Kura, Ubuntu Core,
and snaps.

2
 Snap package
Snaps are a new packaging system developed with IoT deployments in mind.
A snaps is a compressed file system encapsulating an application, its services,
assets and all required dependencies. A deployed snap is dynamically mounted
upon installation and is read-only by design.

Snaps operate in the following way:

• The system orchestrator ensures integrity of the snap package before it is

introduced to the system, making sure the installed snap is the same as
published by the developer. Each snap bundles all necessary dependencies
which, provides the developer with a more predictable runtime environment
compared to traditional package deployments.

• Snaps run confined under a restrictive security sandbox. The security policies
and snap store policies work together to allow developers to quickly update
their applications and to provide security to end users.

• A snap can exchange content and functions with other snaps according to fine
grained policies controlled by the system and configured by an administrator.
A snap can have one or more services, clients or graphical interfaces.

• All required permissions per service and application are described by a snap’s
metadata. It also defines the services and content that a snap exposes to
other snaps.

• Snaps can implement hooks to respond to changes. Hooks are invoked by

the system for events such as change of configuration, install, removal, rollback
or upgrade to new revision.

• Each snap has a dedicated writable area per user and per revision as well as
common, as depicted below.

Snap has own writable space (services & per users) and (versioned & unversioned)

Versioned writable area Versioned User writable area

$SNAP_DATA $SNAP_USER_DATA

Common writable area Common User writable area

$SNAP_COMMON $SNAP_USER_COMMON

SERVICE SERVICE CLI GUI

snap code & assets

(squashfs, RO bind-mounted in /snap/<snap_name>/<revision>)
$SNAP

3
 Ubuntu Core
Ubuntu Core is a minimalist edition of Ubuntu built entirely from snaps
(see below). It is a lightweight, transactionally updated OS, where every
application is installed and confined from others. It is designed to run securely
on autonomous machines, devices and other internet-connected digital things.

The main focus of Ubuntu Core is to provide a robust, faster and more reliable
system, with stronger security guarantees for installed applications and
registered users. Thanks to snap packaging, the OS itself and every application
has atomic transactional upgrades, all of which can be rolled back if needed.
Each snap has a unique signature which is verified by the system in order to
ensure what is running on the device is exactly what the developer has published.
The base system of Ubuntu Core is a very minimal system that consists of three
different parts: the kernel, gadget and core – which are all packaged and
delivered as snap packages.

Confined applications packages as a snap

Minimal OS packaged as snap Gadget

KERNEL

Clearly defined Kernel and BSP packaged as snap

• The kernel snap contains the linux kernel and the board support package,
enabling all the specifics of underlying hardware.

• The gadget snap declares the hardware capabilities of the particular device.
It defines the boot process and the needed dependencies. It can declare
pre-assigned access to snaps needed to use this hardware.

• The core snap contains a minimalistic core operating system. It is distributed

and maintained by Canonical.

4
 OSGi
The OSGi (Open Services Gateway initiative) alliance was founded in 1999
by Adobe, IBM, Oracle, Eclipse and Eurotech. This alliance promotes a modular
service platform for Java.

OSGi addresses some of the main weaknesses of Java, such as a lack of modularity.
A Java virtual machine (VM) is not intended to run modular code, instead, each
application should have its own dedicated VM instance. This causes a problem
when one needs to add an additional application, since application upgrades
cannot be done seamlessly. As every application runs in its own VM, it has to be
packaged with all necessary dependencies. Additionally, Java JAR files do not
include metadata to provide consistent versioning.

OSGi builds on top of Java, adding this desired modularity. It provides full control
over applications which can be independently installed, uninstalled, started and
stopped without needing to reboot. OSGi applications still use Java’s JAR
packaging, but add metadata to track versioning.

OSGi has a simple high level layered architecture described in the following figure:

Services

Security
Bundles
Life Cycles

Modules

Execution Environment

Java VM

Native Operating Systems

The following list contains a short definition of the terms:

• Bundles – OSGi components made by developers.

• Services – Connects Bundles in a dynamic way by offering a publish-find-bind

model for plain old Java objects.

• Life Cycle – An API to install, start, stop, update, and uninstall Bundles.

• Modules – Defines how a bundle can import and export code.

• Security – Based on Java security architecture, provides infrastructure to deploy

and manage bundles running in fine grained controlled environment.

• Execution Environment – Defines what methods and classes are available

in a specific platform.
5
 OSGi components act as black boxes, hiding the underlying implementation.
They expose functionality through service registration which can then be
discovered by other bundles. It brings multiple benefits, allowing for better
testing, reusability of components, faster modular builds and manageable
deployments to mention some.

Bundles can be installed/updated/removed dynamically by the framework. Each

bundle consists of Java classes and additional resources. Those can be optionally
shared, if defined by a bundle’s manifest, and consequently imported by another
bundle. By default, OSGi will hide the contents of a JAR package.

OSGi provides an API for a bundle’s lifecycle management. Through this API,
bundles can be installed, uninstalled, started, stopped or updated. Bundles rely
on the Modules layer for class loading, but they add an API for runtime
management. Correct operation of the environment is ensured by an extensive
dependency mechanism provided by the life cycle layer.

OSGi provides the Service Java interface which is implemented by a bundle in

order to register a service with the service registry. Such a service can be found
a by client in the registry.

At the current time, there is no adequate alternative to the OSGi framework.

Some solutions address certain limitations of OSGi but leave other aspects
unaddressed.

6
 Kura
Kura was developed as a response to the growing number of custom
solutions addressing custom hardware and software by providing a standard
repeatable platform. It aims to provide a service gateway model that operates
on the edge of a Machine to Machine (M2M) deployment. It acts as aggregator
and controller.

Kura aggregates open source implementations for all of the most common
services needed by M2M applications. It aims to provide a developer abstraction
layer on top of hardware and networking subsystems. As such, it enables rapid
development and deployment of IoT gateway applications.

Kura is developed as an open source project, and as such, does not come with
support, which is often required for commercial deployments due to size, scale,
and security requirements. Eurotech, the main contributor of Kura, develops and
supports the commercial offering - Everyware Software Framework (ESF). ESF is
an enterprise ready IoT edge framework based on Kura that uses the same
packaging system as Kura and who’s services developed for Kura are compatible
with ESF, allowing for a seamless transition.As depicted below, Kura runs on top
of Java Virtual Machines and leverages the OSGi framework. Components of Kura
are developed as OSGi services exposing a service API. Services can raise events
consumed by subscribed services.

Kura is mostly developed in Java, however, its implementation is not limited to

Java alone and can access native components in an underlying operating system
through the Java Native Interface (JNI).

There are two flavours of Kura, a full featured version and a no network (nn)
version stripped of all network configuration capabilities.

Applications
Remote
Access

Your Application Your Application

Kura Wires

Connectivity and Delivery Asset Management

Management
Updates

Cloud Services Data Services MQTT Paho Asset

Remote Management

Administration GUI

Network Configuration Drivers

Cellular, Wi-Fi, Firewall, Port Link Monitors OPC UA Modbus
Ethernet Forwarding
Configuration
Management

CANbus S7
Basic Gateway Services
DB Service Device Profile
Clock Service Watchdog Custom Protocols

Device Abstraction
javax.com GPS Position
javax.usb GPIO / SPI / PWM / 12C
java HID APIs w/ udev access javax.bluetooth / BLE jdk.dio

OSGi Application Container (Eclipse Equinox, Concierge)

Java SE 7 / 8 (OpenJDK)

7
 Out of the box Kura supports the following services:

- I/O services
- Data services
- Cloud services
- Configuration services
- Remote management
- Networking
- Watchdog services
- Web administration interface

I/O Services: I/O services include serial port, USB, Bluetooth, position service,
clock service and low level GPIO, I2C, SPI, PWM access. Data services provide
an abstraction for storing telemetry data and its publishing to remote servers.
Depending on data type, access can be provided using javax, OSGi I/O connection
or Kura API.

Cloud Services: Cloud services provide a simple way to share a single cloud
connection between multiple other services running on a gateway. A cloud
service has a simple interface to manage communication with a remote server.
It is not limited to publish-subscribe scenarios only; it also supports more complex
scenarios such as request, response or remote resource management. Cloud
service supports multiple IoT cloud providers, including Microsoft Azure IoT Hub,
Amazon AWS IoT, and Eclipse Kapua. This adds flexibility to manage multiple
data flows from a single IoT gateway, for example separating command and
message flow from telemetry data.

Data Services: Data services provide store functionality for telemetry data
collected by other services running on a gateway. Collected data can be also
published to remote servers, based on defined rules. Data service has simple to
use API abstracting underlying technologies. The default messaging library is
provided by Eclipse Paho and its MQTT client.

Configuration Services: The configuration service builds on top of

ConfigurationAdmin and MetaType Service provided by OSGi. It is used to manage
configuration of all OSGi components which implements ConfigurableComponent
marker interface and are registered under the OSGi container.

On top of the existing OSGi functionality it provides an easy way to access the
current configuration of ConfigurableComponent with its full ObjectClassDefinition.
It also allows for the creation of snapshots and rollbacks of a current configuration.
Furthermore it also provides ability for remote configuration management
through CloudService.

Remote Management: Remote management builds on top of the Cloud Service

and Configuration service. As the name suggests, it provides remote management
services for applications running on an IoT gateway. Applications can not only
be configured, but installed applications can be updated or removed, new
applications can be deployed. Framework can also provide solicited or unsolicited
messaging interaction with an application running on the gateway.

8
 Networking: Kura provides a network configuration API to manage and configure
available network interfaces. Apart from the usual ethernet and wifi networks
interfaces it also supports Cellular modems, and firewall configuration.

Since version 3.0 Kura implements Kura Wires, a visual tool providing an
implementation of the Dataflow programing model which allows application
logic to be expressed as a directed graph. This provides a developer an easy way
to prototype a solution while working with a high level of abstraction without
sacrificing flexibility.

Watchdog Service: Watchdog Service provides a way for critical services to

register watchdog. Hardware watchdog can be leveraged, if the underlying
hardware provides it. Registered service is then required to periodically check
in in order to reset the watchdog reboot timer, otherwise watchdog service
assumes registered service is not responding and reboots the device in attempt
to resolve the issue.

Web Administration Interface: Apart from remote management, Kura also

implements a web administration interface. This is a web-based console providing
an interface to configure an underlying IoT gateway. Beside configuration it also
provides an interface to install, upgrade, or remove additional packages, manage
configuration snapshots, control additional drivers, to mention some.

Kura wires can be also accessed through the administration interface. An example
of the web administration interface is shown in the following figure.

9
 Solution
Kura and ESF are often deployed on YOCTO, if a cost effective solution is required.
On some architectures support for Debian, Rasbian, or RHEL [3] is available in
Kura. The update process is often manual, with an inherited level of risk during
the update process this leads to a need to find a balance between the risk of an
update versus the risk of an outdated system.

Additionally, not all Linux distributions are available on all supported architectures,
making a complex deployment even more complicated with a need to maintain
different systems.

Snap packaging combined with Ubuntu Core addresses the problems listed above.
Ubuntu Core is supported on all 4 major architectures [4], while snap packaging
provides abstraction from different hardware platforms. Ubuntu Core provides
Kura with a secure and robust delivery mechanism, that is especially suitable
when considering unattended deployments.

Kura
Confined Kura framework as a snap buez

Minimal OS packaged as snap Gadget

KERNEL

Clearly defined Kernel and BSP packaged as snap

Kura is deployed on Ubuntu Core system as a snap, defining the minimal

deployment package. Kura snap bundles in all necessary dependencies to render
network configuration and control connected hardware.

Deploying Kura on Ubuntu Core systems is a simple task consisting of an install request to
snapd service, as demonstrated below:

$ snap install kura

kura 4.0.0 installed

Snap executable acts as the client to the snapd service, requesting installation of the Kura
snap on the system. Alternatively, a request can be sent to the snapd service over a
RESTful API.

10
 For large deployments it is more convenient to create a flashable image with the Kura
snap pre-installed, allowing for a one-step deployment.

$ ubuntu-image --extra-snaps=kura pc-amd64.model

ubuntu-image is a tool to build Ubuntu images, where --extra-snaps parameter defines a list
of snaps to be preinstalled on the final Ubuntu Core image. pc-amd64.model is the target
device in the model description [1]

Using Ubuntu Core as a secure and robust platform is not restricted to Kura or ESF as
other OSGi based projects can be easily ‘snapped’ and deployed as snaps on top of Ubuntu
Core, forming robust and secure solutions. One example of another OSGi based application
deployed as a snap is the home automation software openHAB [2]

References
[1] Model assertion
[2] openHAB
[3] REHL: RedHat Enterprise Linux
[4] https://developer.ubuntu.com/core/get-started

Further reading:
More information on snaps
More information on Kura
Taking charge of the IoT’s security vulnerabilities
Key considerations when choosing a robot’s operating system
Establishing a software defined IoT business model
Ubuntu Core manages 25m data points a minute
Fing snaps up 30,000 customers with a secure, future-proof IoT device

© Canonical Limited 2018. Ubuntu, Kubuntu, Canonical and their associated logos are the registered trademarks
of Canonical Ltd. All other trademarks are the properties of their respective owners. Any information referred
to in this document may change without notice and Canonical will not be held responsible for any such changes.
Canonical Limited, Registered in England and Wales, Company number 110334C Registered Office:
12-14 Finch Road, Douglas, Isle of Man, IM99 1TT VAT Registration: GB 003 2322 47