Triquetrum delivers an open platform for managing and executing scientific workflows. The goal of Triquetrum is to support a wide range of use cases, ranging from automated processes based on predefined models, to replaying ad-hoc research workflows recorded from a user's actions in a scientific workbench UI. It will allow to define and execute models from personal pipelines with a few steps to massive models with thousands of elements.

Besides delivering a generic workflow environment, Triquetrum also deliverd extensions with a focus on scientific software. There is no a-priori limitation on target scientific domains, but the current interested organizations are big research institutions in materials research (synchrotrons), physics and engineering.

The integration of a workflow system in a platform for scientific software can bring many benefits :

• the steps in scientific processes are made explicitly visible in the workflow models (i.o. being hidden inside program code).
  Such models can serve as a means to present, discuss and share scientific processes in communities with different skills-sets
• allow differentiating for different roles within a common tools set : software engineers, internal scientists, visiting scientists etc
• promotes reuse of software assets and modular solution design
• technical services for automating complex processes in a scalable and maintainable way
• crucial tool for advanced analytics on gigantic datasets
• integrates execution tracing, provenance data, etc.

The implementation will be based on the Ptolemy II framework from UC Berkeley.

MDHT delivers a standard object-oriented alternative to proprietary development methodologies and tooling used to specify and implement most healthcare industry standards. There are three primary categories of users for MDHT tools: authors of healthcare industry interoperability standards, certification or testing authorities who validate that an Electronic Health Record (EHR) system produces XML or JSON files that comply with the standard, and software developers that implement adapters or applications that produce and consume healthcare data. MDHT defines healthcare-specific UML profiles to specify the interoperability standards and delivers model editing tools that are optimized for clinical informatics users, including a customized interface for the UML profile extensions. MDHT also delivers UML publishing tools that are used to generate specification documents that are ready for submission to standards organizations. Finally, the tooling includes model transformations that leverage  EMF and OCL to generate Ecore models and Java code used by healthcare implementers.

What makes healthcare information models different?  Why don't we simply use general-purpose UML tools?

• Constraint-based modeling approach
  • Most healthcare standards create a base "reference model" and then define templates/profiles/archetypes with lists of constraints on a class from the reference model. For example, in the C-CDA implementation guide, a Vital Sign template includes constraints on the base CDA Observation class. We model this template using a UML subclass, but many constraints cannot be represented using standard UML, especially terminology constraints for coded attributes.
• Clinical Terminology
  • Creating clinical information models usually involves searching very large and complex terminology systems (i.e. ontologies) such as SNOMED CT or LOINC, creating or evaluating value sets of terminology codes, and assigning these as constraints on attributes in a UML class. MDHT includes specialized editing tools for using these terminology systems, and transformation to runtime Java libraries that support application developers and constraint validation.
• Generate domain-specific Java classes for templates/profiles/archetypes
  • For example, generate a VitalSign class for implementers, but serialize/deserialize XML or JSON instance data that conforms to the base reference model schema type for CDA or FHIR Observation.
  • Annotate the generated Ecore model to enable customized serialization and deserialization of instances, and validate that instances of the base reference model satisfy constraints indicated by the assigned template ID.
• Users of modeling tools are often clinical informatics specialists, not familar with UML or software engineering
  • The modeling tools must enable users to edit and review clinical information models, with terminology value set constraints, while remaining focused on the clinical content and not overwhelmed by model formalisms.

Visualization is a critical part of science and engineering projects and has roles in both setting up problems and post-processing results. The input or "construction" side can include things like constructing 3D geometries or volume meshes of physical space and the post-processing side can include everything from visualizing those geometries and meshes to plotting results to analyzing images to visualizing real data to almost everything else imagineable. There are numerous technologies for performing these tasks and most of them, with the exception of SWT-XY-GRAPH, are unavailable natively in the Eclipse ecosystem.

This work proposes to develop new visualization technologies based on the needs of projects in the working groups and to provide a framework for integrating these and third-party visualization technologies seemlessly with the workbench. The integration framework, which is part of the initial contribution that will be moved from the Eclipse Integrated Computational Environment (ICE), uses pluggable OSGi services to standardize the way that all integrated visualization products interact with the platform. Several abstractions are made for common elements such as plots and construction canvases and editable properties are provided by the implementations. Each visualization service realizes a standard interface (IVizService) that provides factory methods for constructing the widgets.

This work also proposes to develop a standalone, executable Eclipse product (flavor), complete with its own perspective and views, that can be downloaded by users and in which all of the integrated capabilities may be used in a pure visualization context. This insures that the project will be able to stand as its own product without being a kind of hidden project that is integrated into other projects.

Development of Swing/AWT Widget

The development of Swing/AWT widgets is beyond the scope of this work, although there is nothing in the design that fundamentally prevents such a development. Contributions from the community that extend the platform to support Swing/AWT widgets are welcome but will not be pursued.

Examples

The picture below shows some of the proposed capabilities that would be part of this project. The collage shows a 3D constructive solid geometry created interactively in the top left, a domain-specific view of a nuclear reactor plant in the bottom left, 2D plots of neutron scattering data in the top right and a 3D view of a prismatic cell battery, commonly used in phones and laptops, with its temperature as a function of time color mapped onto it in the bottom right.

The plot of neutron scattering data is rendered using SWT-XY-GRAPH, but all of the other images are provided by third party services that are integrated with the visualization service framework. The view of the battery is actually rendered by VisIt, a third party tool for 3D visualization and post-processing that is written in C/C++ and executes as a separate process.

The next picture shows some of the proposed imaging capabilities in the initial contribution, courtesy of Marcel Austenfeld from his Bio7 project (http://bio7.org/). It shows a standard United States National Institutes of Health sample image for ImageJ, specifically, according to their website:

"This image is made from a Molecular Probes demo slide:

   Cells: bovine pulmonary arthery endothelial cells
   Blue: nucleus stained with DAPI
   Green: Tubulin stained with Bodipy FL goat anti-mouse IgG
   Red: F-Actin stained with Texas Red X-Phalloidin"

This project allows user interface to be created from beans or graphs of beans. The user interface available has standard widgets which have few dependencies to reuse. For instance there are widgets for editing numbers with bounds validation, units and that allow expressions of other boxes. There are widgets for entering a range of values and expanding out bean graphs to complete Design of Experiments work.

The API will be simple to use, have great widgets for science and be fast for huge field lists. So even though it is a minnow in the world of models, data binding and UI generation, it has some strong points.

Screenshots from three of the examples:

Cloud Foundry Tools provide an extensible framework and common UI to deploy applications to different Cloud Foundry targets, and it is a framework that closely integrates with Web Tools Platform (WTP) and Eclipse. It allows application scaling and services management from the same Eclipse-based IDE where applications are developed. Applications can also be debugged on Cloud Foundry using the built-in Eclipse debugger. This makes it very convenient for developers to work on applications running on CF.

The Cloud Foundry Tools are not specialized to just work with a specific Cloud Foundry platform. It allows users to set various Cloud Foundry targets, may it be public Cloud Foundry-based platforms like Pivotal Web Services, IBM Bluemix, or others.

Project hawkBit aims to create a domain independent back end solution for rolling out software updates to constrained edge devices as well as more powerful controllers and gateways connected to IP based networking infrastructure. Devices can be connected to the hawkBit server either directly through an optimized interface or indirectly through federated device management servers.

hawkBit is device and communication channel neutral by means of supporting:

• Software and Operating system updates for M2M gateways (typically but bot necessarily running Linux) and
• Firmware updates for embedded devices

both for

• cable or
• over the air (OTA) connected devices

Features at a glance:

• A device and software repository.

• Artifact content delivery.

• Software update and roll out management.

• Reporting and monitoring.

• Interfaces:

  • for direct device control.

  • for IoT solutions or applications to manage the repository and the roll outs.

  • for device management federation (i.e. indirect device control)

  • and a user interface to operators to manage and run the roll outs.

Eclipse Collections is a collections framework for Java. It has JDK-compatible List, Set and Map implementations with a rich API, additional types not found in the JDK like Bags, Multimaps and set of utility classes that work with any JDK compatible Collections, Arrays, Maps or Strings. The iteration protocol was inspired by the Smalltalk collection framework.

Eclipse Collections started off as an open source project on GitHub called GS Collections.  GS Collections has been presented at the JVM Language Summit in 2012 and JavaOne in 2014.  There are two articles (part one and part two) on InfoQ.com showing some of the capabilities of the collections framework through examples.  A performance comparison between the parallel lazy implementations of Java 8, Scala and GS Collections was presented at QCon New York in 2014.  A set of memory benchmarks is available here.   

The OMR project consists of a highly integrated set of open source C and C++ components that can be used to build robust language runtimes that will support many different hardware and operating system platforms. These components include but are not limited to: memory management, threading, platform port (abstraction) library, diagnostic file support, monitoring support, garbage collection, and native Just In Time compilation.

The long term goal for the OMR project is to foster an open ecosystem of language runtime developers to collaborate and collectively innovate with hardware platform designers, operating system developers, as well as tool and framework developers and to provide a robust runtime technology platform so that language implementers can much more quickly and easily create more fully featured languages to enrich the options available to programmers.

Planned functionality:

1. Thread Library

2. Port Library

3. Garbage Collection

4. Diagnostic support

5. Just In Time Compiler

6. Tooling interfaces

7. Hardware exploitation (e.g. RDMA, GPU, SIMD, etc.)

8. Any technology implementing capabilities that can be reused in multiple languages, including source code translators, byte code or AST interpreters, etc.

• Telemetry
  Data flowing upstream (left to right) from devices to the back end to a consumer like a Business Application or the Device Management component usually consists of a small set of discrete values like sensor readings or status property values. In most cases these messages are one-way only, i.e. devices sending this kind of data usually do not expect a reply from the back end.
• Command & Control
  Messages flowing downstream (right to left) from back end components like Business Applications often represent invocations of services or functionality provided by connected devices, e.g. instructions to download and apply a firmware update, setting configuration parameters or querying the current reading of a sensor. In most cases a reply to the sent message is expected by the back end component.

• Secure message dispatching
• Support for different message exchange patterns
• Used for cloud service federation
• Provides interfaces to support implementation of protocol adaptors which allow:
  • Sending telemetry data
  • Receiving device control messages (from applications/solutions)
  • Registering authorized consumers of telemetry data received from connected devices

January is a set of libraries for handling numerical data in Java. It is inspired in part by NumPy and aims to provide similar functionality.

• Familiar. Provide familiar functionality, especially to NumPy users.
• Robust. Has test suite and is used in production heavily at Diamond Light Source.
• No more passing double[]. IDataset provide a consistent object for basing APIs on with significantly improved clarity over using double arrays or similar.
• Optimized. Optimized for speed and getting better all the time.
• Scalable. Allows handling of data sets larger than available memory with "Lazy Datasets".
• Focus on your algorithms. By reusing this library it allows you to focus on your code.

For a basic example, have a look at the example project: BasicExample.java

Browse through the more advanced examples.

• NumPy Examples show how common NumPy constructs map to Eclipse Datasets.
• Slicing Examples demonstrate slicing, including how to slice a small amount of data out of a dataset too large to fit in memory all at once.
• Error Examples demonstrate applying an error to datasets.
• Iteration Examples demonstrate a few ways to iterate through your datasets.
• Lazy Examples demonstrate how to use datasets which are not entirely loaded in memory.

The edge devices connected to the Cloud that constitute the Internet of Things (IoT) require support for building blocks, standards and frameworks like those provided by the Eclipse Foundation projects: Californium, Paho, Leshan, Kura, Mihini, etc.
Because of the large deployment of Java technology in the Cloud, on the PC, mobile and server sides, most projects above are implemented in Java technology.

Deploying these technologies on embedded devices requires a scalable IoT software platform that can support the hardware foundations of the IoT: microcontrollers (MCU). MCU delivered by companies like STMicroelectronics, NXP+Freescale, Renesas, Atmel, Microchip, etc. are small low-cost low-power 32-bit processors designed for running software in resource-constraint environments: low memory (typically KB), flash (typically MB) and frequency (typically MHz).

The goal of the Edje project is to define a standard high-level Java API called Hardware Abstraction Layer (HAL) for accessing hardware features delivered by microcontrollers such as GPIO, DAC, ADC, PWM, MEMS, UART, CAN, Network, LCD, etc. that can directly connect to native libraries, drivers and board support packages provided by silicon vendors with their evaluation kits.

To achieve this goal, the Edje project also defines the minimal set of API required for delivering IoT services, leveraging largely-deployed technologies, and meeting performance and memory constraints of IoT embedded devices. Edje defines the Edje Device Configuration (EDC). Care has been taken to make the EDC a proper subset of the different Java runtime environments found in Android, J2SE, J2ME, OSGi Minimum and others. This project presents the packages and API that constitute the core of EDC, defines the minimal foundation that iot.eclipse.org projects can rely on, and still compatible with economical constraints of the IoT: footprint. EDC covers the standard packages part of the Java core language (java.lang, java.io, …).

OPC Unified Architecture is an interoperability standard that enables the secure and reliable exchange of industrial automation data while remaining cross-platform and vendor neutral. The specification, currently version 1.03, is developed and maintained by the OPC Foundation with the guidance of individual software developers, industry vendors, and end-users. It defines the interface between Clients and Servers, including access to real-time data, monitoring of alarms and events, historical data access, and data modeling.

Whiskers is a JavaScript client for the SensorThings API. The SensorThings API is an OGC (Open Geospatial Consortium) standard that allows IoT (Internet of Things) devices and their data to be connected; a major goal is to foster a healthy and open IoT ecosystem, as opposed to one dominated by proprietary information silos.

JavaScript is ubiquitous, powering client-side web applications and server-side services alike. The availability of an open source client library is an important step in the adoption of the OGC SensorThings standard, as it makes development quicker and easier. Whiskers aims to make SensorThings development easy for the large and growing world of JavaScript developers.

Papyrus-xtUML is a tool which supplies the capability to edit, execute and translate xtUML models.  Executable, translatable UML (xtUML) is an extension to UML based upon the Shlaer-Mellor Method of Model-Driven Architecture (MDA), which supports a powerful approach to Model-Driven Development (MDD). Papyrus-xtUML provides the system design community with access to xtUML editing, execution and translation capabilities, along with a forum to advance the use of this methodology.

Papyrus-xtUML specializes in editing UML such that platform-independent models are precisely defined to enable interpretive execution (early test) from the first edit.  The execution technology is built-in to the editor and runs partial models without compilation.  Model compilers translate xtUML into target-specific code for various architectures in C, C++, SystemC, Java (and other programming languages) and into documentation in HTML, DocBook and other formats.

Papyrus-xtUML collaborates within the Papyrus Industrial Consortium and PolarSys which pursue providing a cohesive solution set for systems modeling for complex cyber-physical systems.

EclEmma is a free Java code coverage tool for Eclipse, available under the Eclipse Public License.

It brings code coverage analysis directly into the Eclipse workbench:

• Fast develop/test cycle: Launches from within the workbench like JUnit test runs can directly be analyzed for code coverage.

• Rich coverage analysis: Coverage results are immediately summarized and highlighted in the Java source code editors.

• Non-invasive: EclEmma does not require modifying your projects or performing any other setup.

Introduction

Scientific facilities operating high end hardware, for instance robots, motorized stages and detectors, have well defined layers for integrating these devices. For instance it is possible for a call to be made to move a motor or expose a detector (similar to taking an image with a digital camera). Examples of these control layers are the EPICS framework, and the TANGO framework. These frameworks are open source and in wide use at facilities around the globe. Facilities also require low latency operation, for instance a fast acting motor and a detector may need to coordinate specialized hardware. For people not familiar with this idea, one example of this is the Zebra box which combines an ARM processor with an FPGA and can orchestrate hardware times down to the nanosecond scale. There is also a device called TFG.

Detailed Design

Introduction

The project will be divided into a services layer to provide the scanning features, an example user interface layer implemented in RCP/jface (users may choose to use another UI layer) (this UI will be used at Diamond Light Source) and a cpython/jython layer for easily scripting the scans.

Server and Clients

The services layer may be operated on a separate server and messages passed between the client and server with a messaging system provided by the project. The scanning project does not prescribe exactly how services are used however if they are started in an OSGi container, declarative services will work. If they are not some manual ‘wiring together’ might be required. One possible arrangement of the services for scanning is shown below. This arrangement is site specific to Diamond Light Source and represents a possible deployment of the services layer and integrating it to analysis in DAWN (outside the scope of this project) in this case using a server. Different facilities would use the various services in this project different ways.

Services Layer

IPointGeneratorService

The point generator service takes a model and provides a generator, IPointGenerator, which gives each nD point in the scan. So for instance in a mapping scan, each point has a x,y stage value for the two-dimensional scan.

Image showing a spiral scan path over a 2D stage

Generators may be nested (unlimited) to provide complex scans. For instance it is possible to combine a grid with temperature step scan. Generators may be added by extension point so that scan paths not envisaged by the developer of the service can be added. Generators may be added by cpython/jython to allow users to define experimental specific scan procedures, including logic to be executed for each point.

IRunnableDeviceService

This service returns devices, IRunnableDevice, which conform to a state machine for driving scans. It is used to run a scan and is the core interface for scanning. It returns the top level scan which uses a point generator to define each scan point. It returns each device in the scan, for instance 2D detectors or devices driving EPICS Area Detector or a Malcolm Device, conform to this interface and pass through the states defined.

See http://pymalcolm.readthedocs.io/en/latest/arch/statemachine.html

AcquisitionDevice (IRunnableDevice)

When doing a CPU scan the Java-based runnable device uses a thread pool to manage the scan. It combines a move with a detector readout to maximize the scan speed. So for scanning one point we have:

_|....|________   run() Tell detector(s) to collect current position

______|.....|___  write() Tell detector(s) to write data,

______|.............|___ setPosition() move motor(s) to next position

IDeviceConnectorService

Provides a connection to devices which are to be scanned. The devices take part in the scan by setting/getting value so they represent things like motors, temperature controllers and goniometer angles. Each device connected to must conform to a simple interface called IScannable.

IScannable<T> … {

 public T getPosition() throws Exception;

 public void setPosition(T value, IPosition position) throws Exception;

 ...

}

IEventService

An event system is required to receive scan requests, notify the user of scan progress and maintain queues. The event service provides the following models:

• Publish/Subscribe   (events like scan finished)

• Submit/Consume    (queues like those for running scans)

• Request/Response (ask the server a question such as how many detectors)

This event system is also used to manage analysis algorithms which are outside the scope of the scanning project.

IMalcolmService

To make it really easy to talk to any hardware, a middleware layer has been designed called ‘Malcolm’ which bridges between hardware and the runnable device interface/state machine. Malcolm is outside the scope of the scanning project. Malcolm devices which implement IRunnableDevice are made available from it using the IMalcolmService internally to the IRunnableDeviceService. (Malcolm is similar in this respect to TANGO and it may be desirable in future to allow TANGO devices to be scanned and/or allow the scanning device to conform to a TANGO device.)

NeXus Builder Service

The NexusBuilderFactory is used in the scanning to write legal NeXus HDF5 files. NeXus is a self-describing binary file format used in many facilities to record large numerical data efficiently. The DAWN product can read any correctly written NeXus file and provides a large armoury of tools with which to analyse data, for example running fast analysis pipelines on clusters. Devices can be integrated with NeXus by implementing a declarative interface called INexusDevice.

Other Services

There are several other services for connecting to python, running scripts etc. which are included in the project.

User Interface Layer

The project provides user interface parts for visualizing the queues of scans. It also provides a simple scan builder perspective, called ‘Scanning’, which allows a scan to be created and run. This perspective will work without configuration to the scanning project and execute mock devices provided in the project examples. The user interface allows a scan to be defined and configured with available devices and then submitted to the scanning service using the event service. This allows scans to be received on a server if one is implemented. This may be desirable if the client and acquisition are separate, for instance in the case of a remote thick client or a web client.

There is also be an example called ‘X-Ray Centering’ which shows a simple submit/consume using the scanning project. This example requires DAWN libraries to be available because it uses the DAWN plotting system as a service. In the future it may be desirable to remove this dependency as the dawnsci project intends to release plotting separately.

Scripting Layer

The scripting layer is intended to provide a python API which is easy to use and drives the runnable device service. It can submit scans to the scan queue or to be directly run. It uses a ScanRequest object on the java side of the service which is identical to the user interface. The doc from the mscan method is shown here which defines how it works.

Usage:

mscan(scan model(s), detector model(s))

   A simple usage of this function is as follows:

   > mscan(step(my_scannable, 0, 10, 1), det=mandelbrot(0.1))

   The above invokation says "please perform a mapping scan over my scannable

   from 0 to 10 with step size 1, collecting data from the 'Mandelbrot'

   detector with an exposure time of 0.1 seconds at each step".

   You can specify multiple detectors with a list (square brackets):

   > mscan(..., det=[mandelbrot(0.1), another_detector(0.4)])

   You can specify a scannable or list of scannables to monitor:

   > mscan(..., mon=my_scannable, ...)  # or:

   > mscan(..., mon=[my_scannable, another_scannable], ...)

   You can embed one scan path inside another to create a compound scan path:

   > mscan([step(s, 0, 10, 1), step(f, 1, 5, 1)], ...)

   The above invocation says "for each point from 0 to 10 on my slow axis, do

   a scan from 1 to 5 on my fast axis". In fact, for the above case, a grid-

   type scan would be more idiomatic:

   > mscan(grid(axes=(f, s), step=(1, 1), origin=(0, 0), size=(10, 4)), ...)

   By default, this function will submit the scan request to a queue and

   return immediately. You may override this behaviour with the "now" and

   "block" keywords:

   > # Don't return until the scan is complete.

   > mscan(..., ..., block=True)

   > # Skip the queue and run the scan now (but don't wait for completion).

   > mscan(..., ..., now=True)

   > # Skip the queue and return once the scan is complete.

   > # For some beamlines now=True, block=True may need to be defaulted in localstation.

   > mscan(..., ..., now=True, block=True)

NeXus Writing

It is important to ensure that writing of NeXus files is performant. Diamond Light Source have partially funded the new SWMR (“swimmer”) functionality in HDF5 which ensures that one process may write to a file, quickly, while other processes read from the same binary file. This is HDF5 library version 2.10 and has been tested with the scanning project. The project has been designed for devices to write correct NeXus records by implementing a single interface i.e. it should be straightforward to add devices. Other file formats would be out of the scope of the initial phase of the project but would be desirable in the future depending on those willing to be involved with the project.

Current Deployment

The project is deployed at Diamond Light Source and is intended to be the backbone of the next generation of data acquisition at the facility. A screenshot of a user interface developed using the project is included below to show how scanning can be reused. The user interface is for mapping experiments, these experiments per-se are outside the scope of the scanning project and their user interfaces not included however the controller and model from scanning are used to deliver a mapping functionality at Diamond Light Source.

Example of polygonal scanning in a mapping experiment

The following diagram provides a functional architecture of the Eclipse Kapua project.

Device Connectivity

The connectivity of the devices is managed through a multi-protocol message broker. In the initial contribution, the protocol for the device connectivity will be the IoT protocol MQTT. The broker supports other protocols including AMQP and WebSockets for application integration.

The device connectivity module is responsible to authenticate connections, enforce the appropriate authorization – for example in the topic namespace – and maintain a Device Registry. The Device Registry stores the device profile, the device connection status and the device connection log. It also enables device organization through custom attributes and tags.

Message Routing

The stream of data published by the devices may have different consumers. Certain messages, like command and control messages, are meant to be consumed by the Device Management component; other messages, like the telemetry data are meant to be archived in the IoT Platform or re-directed to other systems. The Message Routing component allows for flexible handling of message streams avoiding hard coded behaviors through configurable massage routes.

Device Management

Through the Device Management component, the IoT platform can perform remote operations on the connected devices. The IoT platform exposes an open contract towards the devices being managed with no assumption on the device software stack. In the initial contribution, the device management contract is based on an open application protocol over MQTT. Such protocol is already implemented by the Eclipse Kura project. With such protocol, the IoT platform can:

• Introspect and manage the device configuration
• Manage the device services including service start and stop operations
• Manage the device applications including application install, update, and remove
• Execute remote OS commands on the device
• Get and set device attributes and resources
• Provision initial configuration of the devices

In its evolution and future community contributions, Eclipse Kapua may adopt additional device management protocols like the emerging LWM2M standard

Data Management

Eclipse Kapua can archive the telemetry data sent by the devices into a persistent storage for application retrieval. A reference message payload is defined which allows for a timestamp, a geo position, strongly typed message headers and an opaque message body. The chosen encoding is based on an open Google Protocol Buffers grammar.

In the initial contribution, a NoSQL data storage is used to allow for a flexible indexing of the telemetry messages. Incoming messages are stored and indexed by timestamp, topic, and originating asset. The NoSQL storage allows for indexing of the message headers.

Data Management also keeps a Data Registry which maintains the topics and the metrics that received incoming traffic.

Security

A foundation layer maintains the security aspects of the IoT platform like the management of tenants, accounts and users. The account model supports a hierarchical access control structure. Following Role Based Access Control (RBAC), user identities can be defined and associated with one or more permissions guaranteeing the principle of "least privilege". Devices connect to the platform using the credentials of one of these user identities or through SSL authentication. 

Application Integration

For integration with existing applications, Eclipse Kapua offers modern Web Services API based on Representational State Transfer (REST). The REST API exposes all the platform functionality, including device management and data management. The REST API also offers a "bridge" to the MQTT broker enabling the routing of commands from applications to devices without a specific connection to the message broker. Technologies such as REST/Comet/WebSockets are included allowing real-time display of data published by the devices in web pages and mobile dashboards. 

Administration Console

Eclipse Kapua features a web-based administration Console to perform all device and data management operations. A screenshot of the administration Console is shown below.