Mbs SDK 8.2 Features

ProSyst Gateway Software

mBS SDK 8.2 Features

Bosch Software Innovations

Overview of revisions

INST/PSY Anastas Chobanov Status: July 2017

mBS SDK 8.2

Overview of revisions

Date Changes/Comments Author

18-07-2017 Migrated the doc to the new layout and did some minor version-wise changes. Anastas Chobanov

Content

1 INTRODUCTION ...... 4

2 OSGI RUNTIME ...... 5

2.1 Supported OSGi Specifications ...... 5 2.1.1 OSGi Core Release 5 Specification ...... 5 2.1.2 OSGi Compendium Release 5 and OSGi Residential 4.3 Specifications ...... 6 2.1.3 Supported Java Virtual Machines ...... 8

2.2 Core Extensions ...... 9

2.3 IoT Extension ...... Error! Bookmark not defined.4

2.4 I/O Extensions...... Error! Bookmark not defined.4

2.5 Persistence Extension ...... Error! Bookmark not defined.5

2.6 Tooling Extension ...... Error! Bookmark not defined.5

2.7 Remote Access Extension ...... Error! Bookmark not defined.6

2.8 Test Execution Environment...... Error! Bookmark not defined.6

2.9 Remote Management Extension ...... Error! Bookmark not defined.7

3 ECLIPSE PLUG-INS ...... 18

3.1 mToolkit ...... Error! Bookmark not defined.8

3.2 mBProfiler...... Error! Bookmark not defined.0 3.2.1 Supported Platforms for mBProfiler Agent ...... Error! Bookmark not defined.1

3.3 System Plug-ins ...... Error! Bookmark not defined.3

4 OSGI RUNTIME VALIDATOR ...... 24

5 ADDONS ...... 25

5.1 Board Support Packages ...... 25

6 APPENDIX A: RESOURCES ...... 26

1 Introduction mBS SDK provides the ProSyst OSGi stack and a number of additional features for various use cases as well as a powerful toolset for Eclipse and a validation pack. mBS SDK consists of three main components:

 OSGi Runtime. Contains our implementation of the OSGi standard and a set of functional ProSyst components. In the next sections, we will also use the name “mBS Runtime” for this component. The purpose of the OSGi Runtime is to serve as the base for tailoring runtime images for specific target devices. Typically, these images represent a subset of the features provided by the mBS Runtime, which covers the requirements for the target device without keeping unnecessary components.  Eclipse Plug-ins. A powerful set of tools to aid the development, testing and profiling of OSGi-based applications both in an emulated runtime environment and directly on the target device.  OSGi Runtime Validator. Supplies the option to validate the components of the OSGi Runtime on a specific target platform. The validation comprises functional as well as non- functional (performance and stability) tests.

2 OSGi Runtime

2.1 Supported OSGi Specifications

2.1.1 OSGi Core Release 5 Specification ProSyst’s OSGi Runtime fully implements the OSGi Core Specification, Release 5, including all optional features. The supported features are outlined in the following table.

OSGi Core Release 5 Features Supported Security Layer  Module Layer  Life Cycle Layer  Service Layer  Resource API Specification  Bundle Wiring API Specification  Framework Namespaces Specification  Start Level API Specification  Framework API Specification  Framework Launcher API Specification  Conditional Permission Admin Service Specification  Permission Admin Service Specification  URL Handlers Service Specification  Resolver Hook Service Specification  Bundle Hook Service Specification  Service Hook Service Specification  Weaving Hook Service Specification  Tracker Specification  Bundle Hook Service Specification 

2.1.2 OSGi Compendium Release 5 and OSGi Residential 4.3 Specification The mBS Runtime fully implements most of the features of the OSGi Compendium Release 5 Specification and the OSGi Service Platform Residential Specification, Release 4, Version 4.3. The support for each feature outlined in the following table is related to its version within the specification to which it belongs. For convenience, all features are numbered and ordered as they appear in the corresponding specification.

Features OSGi Specifications OSGi Compendium OSGi Residential Release 5 Release 4.3 2 – Residential Device Management Tree Specification  3 – TR-157 Amendment 3 Software Module Guidelines  100 – Remote Services  101 – Log Service Specification   102 – Http Service Specification   103 – Device Access Specification   104 – Configuration Admin Service Specification   105 – Metatype Service Specification   106 – Preferences Service Specification  107 – User Admin Service Specification   108 – Wire Admin Service Specification  109 – IO Connector Service Specification  110 – Initial Provisioning Specification   111 – UPnP Device Service Specification   112 – Declarative Services Specification   113 – Event Admin Service Specification   114 – Deployment Admin Specification  115 – Auto Configuration Specification  116 – Application Admin Specification  117 – Dmt Admin Service Specification   119 – Monitor Admin Service Specification  120 – Foreign Application Access Specification  121 – Blueprint Container Specification  122 – Remote Service Admin Service Specification  123 – JTA Transaction Services Specification 

125 – JDBC Service Specification  126 – JNDI Services Specification  127 – JPA Service Specification  128 – Web Applications Specification  130 – Coordinator Service Specification  131 – TR069 Connector Service Specification  132 – Repository Service Specification  133 – Service Loader Mediator Specification  134 – Subsystem Service Specification  135 – Common Namespaces Specification  136 – Resolver Service Specification  701 – Tracker Specification  702 – XML Parser Service Specification   703 – Position Specification  704 – Measurement and State Specification  999 – Execution Environment Specification 

Legend:

 The feature is supported  The feature is not supported The feature is not part of the specification

2.1.3 Supported Java Virtual Machines The following table outlines the JVMs that mBS SDK is tested on and is known to run on.

Java Virtual Machines

Desktop JVMs Oracle Java SE (7, 8)

Embedded JVMs Oracle Java SE Embedded (7, 8) full and compact profiles

JBED full and compact profiles

Azul full and compact profiles

Oracle Java SE (older versions)

1 JVMs known to run on Skelmir CEE-J ® VM

Atego Aonix Perc® Ultra

phoneME Advanced

Kaffe VM

JamVM

JamaicaVM

Kiffer Open Mika

GNU Compiler for Java

CacaoVM

Open JDK

Microdoc J9 2.4

Android Runtime (Dalvik VM)

2.2 Core Extensions

The heart of mBS Runtime is the implementation of the OSGi Core Specification. This section covers the extensions to this specification and the other special features that make our OSGi environment unique.

Security

Together with the full implementation of the OSGi security model, mBS Runtime offers the following optimizations and unique characteristics:

 Proper usage of doPriviledged blocks (based on the support of the OSGi security model).  Optimized permission checks – Installed bundles can be divided in two groups: core and application. Core bundles permission checks can be bypassed assuming that they are always trusted.  Support of signed bundles.  Enhanced policy management – The OSGi specification introduces a security paradigm based on the Java Security Model. However, as this model is very complicated, configuring the security policy of an OSGi environment is a difficult task. mBS Runtime eases security configuration by providing a flexible policy management, based on signers and functional groups of bundles. OSGi security policies can be preset in the runtime, or configured on the fly via command line or Web-based administration interfaces.  Certificate management – mBS Runtime supports integration with certificate storage for verifying the trust of the components being installed.  Protection of system packages and properties.

Resource Management

 Management of resources used by bundles – mBS Runtime provides the unique resource management capability to restrict the consumption of a specific resource type (threads, CPU2, memory, sockets2 and data storage space) for a group of bundles or for a single bundle. If the limits are violated, then the bundle(s) will be stopped. This feature can also be used to check how much memory or CPU is used by the bundle(s) building an application.  Management of resources consumed by the JVM process – as the mBS Runtime is executed by the JVM of the underlying device platform, faults originated by the JVM itself or by an extension running on top of it might lead to serious complications in the whole OSGi system. To handle such potential problems, mBS Runtime provides a special native agent capable of monitoring the system resources (CPU and memory) consumed by the

1 mBS SDK is known to run on these JVMs although they are not extensively tested.

2 The implementation depends on the specific JVM that is used and can be developed on demand.

host JVM process. If the predefined limits are reached, then this agent will restart the process.

Availability and Protection  Exception handling in the OSGi Framework – mBS Runtime provides protection from exceptions that come from problematic bundles. Try-catch blocks are used everywhere the framework calls bundle code or uses APIs that allocate memory and can cause out-of- memory errors.  Hanging listeners – When a hung listener is detected, mBS Runtime starts a new thread to continue operation. The old thread associated with the listener is blocked or destroyed (depending on the used JVM) and the listener can be optionally placed in a blacklist.  Bundle Callbacks – mBS Runtime invokes bundle callback methods (such as BundleActivator.start or BundleActivator.stop.) in separate threads, and monitors the state of these threads so that application code will not block the operation of the entire OSGi environment.  Threads of “malicious” bundles – Usually, a bundle starts new threads when activated. These threads must be then disposed upon bundle stop. However, it might happen that the threads continue their execution after the bundle is stopped. To avoid potential thread issues, mBS Runtime provides a JVM-specific mechanism to destroy such threads.  Fault management – mBS Runtime contains a fault manager activated when critical faults arise.  Uncaught exceptions handling – mBS Runtime can be configured to use a third party service for handling cases of uncaught exceptions in a way most suitable for the underlying platform.  Crash protection of data files – The device running mBS Runtime can crash or can be suddenly switched off. To handle such situations, mBS Runtime protects the integrity of the data files created by the framework and by the system bundles so that the system will remain usable after the restart.  Lazy activation and deactivation – Lazy activation and deactivation of bundles is based on the lazy activation policies they declare. By using this feature the system can have stable startup time. mBS Runtime also provides a Network Daemon that can trigger the activation of a bundle in case of a specific network event. Configurability

 Modular Architecture – The design of mBS Runtime, including the OSGi framework implementation and the core bundles, is based on modularity. Taking advantage of this, it is possible to use and configure only the modules needed for a particular system using a smaller set of bundles.  System bundle extendibility – To save memory and startup time by using a common class loader, mBS Runtime allows appending the content of specific bundles to the system bundle. For example, this feature is suitable for core bundles providing the most important functionality of the system as they usually are rarely updated or do not need updates at all.  Plenty of options for tuning – To easily model the desired behavior for a specific platform, mBS Runtime provides a lot of configurable options in the form of system properties or of properties in the OSGi Configuration Admin.  Generation of images most optimal for the JVM – mBS Runtime provides the option to create an optimal image for a specific JVM. In particular, the runtime offers a plenty of JVM- specific startup scripts and OSGi framework modifications as well as specific system

bundles (serverxxxx.jar-s) for several Oracle JDK versions, IBM J9, Dalvik, etc. The only thing left to do in order to complete the image is to include the required bundles.  Provided scripts and the necessary Java code for packaging the OSGi Runtime as an Android APK.

Storage

 Different storage types – mBS Runtime has a special storage abstraction, which hides the way in which it stores framework system files, bundle JAR files and bundle data files. It is possible to develop a third party storage implementation, tailored to a specific device platform or to special requirements. For example, a special storage could store class files of bundles in an optimized JVM class database.  Running the OSGi image from Read Only file systems – The mBS Runtime image on the target device can be divided in static and dynamic parts. The static one will include the OSGi framework, the bundles from the base boot configuration and the relevant startup scripts. The dynamic one will comprise the bundles that are additionally installed on top of the base configuration, and the storage data files. The static part of the image can be transferred onto a read-only file system.  JVM-specific code formats – Most of the time and memory consumed by the JVM process during framework’s startup is in class loading. To reduce resource use, mBS Runtime supports optimized code formats of certain JVMs such as JXE for J9 and DEX for Android’s Dalvik VM.  Distributed storage – The storage of the OSGi framework can be separated in multiple directories. Thus only the most important part of the storage could be saved in the internal flash memory and the rest could be mounted on an external flash card whose plug-in/plug- out would be automatically detected. And as most embedded systems use flash memory, which suffer from a limited number of write cycles, additional “Flash memory agnostic” feature provides a mechanism to minimize the write operations in the device file system.

Transactional Behavior

For production cases it is vital not to leave the system in an inconsistent state. To meet the requirements of such systems, the main operations in the OSGi framework and core bundles of mBS Runtime are performed in an atomic way. In detail, the result from an operation is fully applied only if the execution is successful. mBS Runtime also allows executing several related operations (e.g. install, configure and start a specific bundle) in a single transaction.

Native Agent

In most embedded environments it is very important to have a system capable of self-recovery from errors. Of course, certain error cases can only be handled by showing the error screen to the user. To satisfy this requirement, mBS Runtime contains a native agent offering the following self-recovery features:

 JVM lifecycle management  Fault management  Launch of the OSGi environment in debug and profiling mode (if the respective debug and profiling agents are available in the JVM)

 Support of early restore points like backup and factory storage  OS and process monitoring  Integration with management protocols for remote diagnostics

Administration

 A CLI interface offering an extensive set of commands is available for administration of the OSGi platform locally, through Telnet or from within Eclipse.  A special Web-based application provides control over the most important aspects of the OSGi runtime.

Fig.1: Administration of the mBS Runtime via Web Admin Console

Extensive Logging. mBS Runtime provides detailed log information about the operation of the framework and the core bundles. It also offers a common utility for formatting and persistence of messages. In addition, a special type of logs called measurements can be used for evaluating the performance of the runtime. In order to provide developers with a familiar and powerful logging API, the mBS Runtime now integrates the SLF4J logging framework.

Localization. Both types of strings, system (logs, exception messages, console commands help, manifest and configuration dictionaries) and user-defined, can be localized.

OS Utilities. A set of OS-related utilities solves specific real-world problems ProSyst has faced. For example, the native timer utility, which provides a Java API for accessing the monotonic system timer, useful with JVMs which do not provide an implementation of System.nanoTime(). By using this timer the OSGi applications are able to receive reliable events reflecting system time changes. Another example is the process utility which provides an optimized way to execute or monitor OS processes.

Optimizations for Embedded Systems. Embedded systems which mBS Runtime is targeted for have extremely strict requirements for CPU usage, memory usage, startup time, stability, self-recovering, etc. mBS Runtime owns a rich arsenal of optimizations related to such requirements and the previously mentioned features are only a small part of it.

ProSyst - Specific Services. In addition to the OSGi-defined system services, mBS Runtime owns a set of features that provide valuable additional functionalities. For example:

 The Restart Manager service provides means for controlled mBS Runtime restarts.  The Update Manager enables updates of the images of the OSGi runtime, JVM or operating system (requires additional support from the device). It does it in cooperation with the native agent (mBSA application).  The Software Admin abstracts the download and installation of components in different formats, and returns information about the installed components. Remote management agents or a local application might use this functionality to force download and installation of OSGi-aware applications.  The Backup Admin provides bundles with a way to backup their current data, and to restore their state from a backup point. This service can be used to preserve the state of the OSGi Runtime even on operations that would lead to purging the OSGi cache.  The Alert Service provides bundles with ways to raise and lower alerts. Remote management agents or local applications might check the currently raised alerts and take appropriate measures.  The Platform State Service provides extended information about the current state of the OSGi Runtime, As an example of using the Platform State Service, a remote management agent can start updating one or more bundles in the runtime and set a custom "updating" state, and a GUI based end user interface can react by temporarily blocking user operations and displaying an appropriate message. Policy Admin. The Policy Admin module provides an extension to the OSGi Framework's security infrastructure and facilitates convenient management and creation of security policies. The Policy Admin enables platform operators to define Identities and Functions, which these Identities can access. Identities based on code signing and User Admin are supported out of the box, while more custom Identity Providers can be added easily. Functions are defined as a group of Java 2 permissions, which allows for an easy, coarse-grained policy management. Multiple heterogeneous Identities (local users, local code, remote code, etc.) on the call stack can be identified, supported and authorized. Similarly to the classic Java 2 and OSGi security, the policy is enforced during local API access, but the Policy Admin also provides pluggable authorization of remote API endpoints (JSON-RPC and REST endpoints are supported out-of- the-box). Policies can be defined both programmatically and declaratively (via human- readable files), and can be modified dynamically.

Software Admin. The Software Admin module handles the download and installation of software components on the OSGi framework and takes care for their lifecycle management. The software components can contain simple or complex content depending on the relationship of the resources they contain. The components can be distinguished by their software type and unique identifier in the scope of the specific software type. In addition to the component installation and lifecycle management, the Software Admin also enables the creation of new software types to represent new software components.

2.3 IoT Extension

Functional Items Manager (FIM). The Functional Item Management module is a general abstraction that provides a common way for representing different types of functionalities and also managing different types of controllable modules (devices, user groups, automation, cloud services, UI widgets). This module works with a concept known as Functional Item which is the main unit of the ProSyst IoT platform and as such provides an identical pattern for controlling divergent modules.

 A Functional Item is an atomic unit with a set of properties that represent Functional Item state a set of operations that define the actions that could be executed (i.e. the operations that define the functional item behavior).  The Functional Items empower the OSGi framework-based applications to perform tasks related to different APIs and layers (devices, UI logic, etc.) in a uniform way.  Each Functional Item is registered in the OSGi environment as a service using the Whiteboard pattern which enables the creation of dynamic applications that include the use of Declarative Services and easy building of Blueprint-based applications.  Support for synchronous and asynchronous invocation of property setter methods and operations.  Support for security permissions that manage the access privileges to Functional Item members.  Support for groups of Functional Items based on their capabilities and physical location. This provides the opportunity for users to create a custom Functional Item that manages, controls and automates a system of multiple Functional Items.  Support for remote services that provide remote access to Functional Items objects and management of applications that are outside of the OSGi framework. There are two types services available: JSON-RPC compliant interface that allows remote access for user applications RESTful Web Service with http binding and JSON serialization.  The module has JavaScript Client API that provides easy to use JavaScript API supporting Web developers in defining client interactive UI models on the server and generating them from the client side. Units of Measurement Framework. The Units of Measurement Framework module provides a set of interfaces for handling and converting units presented in a uniform manner. Through the use of a base entity known as Quantity, this module has support for different units of different system of units and enables conversion of values from one unit and scale to another.

2.4 I/O Extensions

The mBS Runtime also offers a set of additional functional extensions:

Serial and Parallel. The Serial and Parallel Module allows the use of serial and parallel ports available in the OSGi environment. These can be physical ports (e.g. with DB9 serial connections) or USB-to-Serial devices, (e.g. FTDI, cp210x) which provide virtual serial ports for the attached USB device.

USB. Provides a ProSyst - developed implementation of the javax.usb API for communication with USB devices. This implementation has been specifically written with the dynamic OSGi environment in mind. The underlying native library is libusb-1.0, which is widely adopted and supports a wide range of operating systems and devices.

Bluetooth LE. Provides support for the Bluetooth Low Energy (LE) wireless technology in the OSGi Runtime. It enables users with access to Bluetooth LE devices from within the OSGi environment and also ways to adjust and exchange information among several Bluetooth LE devices through the Generic Access Profile (GAP), Generic Attribute Profile (GATT) and Attribute Protocol (ATT).

Bluetooth PerAdmin. The role of the Bluetooth PerAdmin module is to discover the capabilities of the attached USB Bluetooth controller in the Peripherals module and to create proxy configurations for appropriate stack(s), according to the discovered capabilities.

Peripherals. The Peripherals module is used to automatically handle mounting/un-mounting of peripheral devices via their respective interconnect interface (USB and UPnP are currently supported). The Peripherals Module lets you do actions such as listing, adding, removing, enabling, or disabling peripheral devices, so it can be seen as an equivalent of the device manager in an operating system. These actions can be performed either through console commands or from the Web Admin Console.

Network Services. The Network Manager module represents the available network adapters which are the network interfaces that allow devices to connect to a gateway via cable or wireless. There are several types of network adapters depending on the type of networks (LAN or WAN) and their access type (Ethernet or Wireless for LAN; DSL, POTS, Cable or Ethernet for WAN).

DevStreams. Through this module the mBS Runtime allows capturing, analyzing and displaying, saving or playing back data communicated over serial ports and TCP sockets. The captured data can be forwarded to a decoder (Frame Analyzer) to be decoded and then displayed in human readable format. Saving the captured data in a file and emulating the exchange of data over serial ports or TCP sockets (using data previously saved in a file) are also among the features of the DevStreams module.

2.5 Persistence Extension

Database. Delivers database support to the OSGi Runtime, based on the SQLite database and JDBC driver.

2.6 Tooling Extension mBS Runtime provides ways to communicate management information with the Eclipse plug- ins of the SDK and also with mBProfiler. iAgent Client. The iAgent Client communicates management information between mBS Runtime and the SDK’s Eclipse plug-ins so as to provide a development environment supporting the full cycle for creation and deployment of OSGi applications within Eclipse. mBProfiler Agent. An in-process shared library that communicates with the JVM through a two-way function call interface - JVMPI (JavaTM Virtual Machine Profiler Interface) for J2SE 5

or earlier, or JVMTI (JavaTM Virtual Machine Tool Interface) for J2SE 6 or later. Combined with the mBProfiler feature of the Eclipse-based SDK, this allows for comprehensive profiling of Java applications (both OSGi and non-OSGi) running on target device.

2.7 Remote Access Extension mBS Runtime provides means for remote communication with the modules of the OSGi runtime and support for subscribing for remote events and receiving notifications.

JSON-RPC. The JSON-RPC module provides remote interface for communication with the OSGi Runtime modules. It is implemented on top of HTTP/HTTPS to provide the groundwork for a highly scalable and easy to manage Web platform. The module is capable of exporting new remote services with remote methods and has support for JSON-RPC requests and responses as well as for notifications and remote events subscription through long polling and Web sockets. Also, it supports authorization and authentication for remote calls through the Policy Admin. Includes out of the boxhandlers for common OSGi Runtime functions like BackupAdmin, UserAdmin etc.

REST. RESTful Web Services Module enables support for exposing JAX-RS 1.x complaint RESTful web services in OSGi via integration of Apache Wink 1.4 JAX-RS RESTful container supporting JSR 311: JAX-RS: The Java API for RESTful Web Services. Resource representations are transferred using JSON serialization format via integration of Jackson 2.4 JAX-RS provider which supports typed and untyped serialization and deserialization of a wide variety of Java types. Support for subscribing for remote events and receiving notifications is enabled via long polling in a RESTful manner, and via Web Sockets. Support for securing and controlling the access to exposed resources and remote events is enabled via integration with Policy Admin, remote clients can be associated with an identity based on the remote user in the HTTP session and access to resources and remote events can be controlled via a policy defined for that identity.

2.8 Test Execution Environment

Each software development process at some point comes to a stage of testing. There are many different ways to check whether an application or a module works as expected. mBS Runtime contains the Test Execution Environment (TEE) which is a test case execution environment used for automation and optimization of testing processes. TEE is a Java-based software system which contains a set of bundles allowing the execution of OSGi-aware test cases that test the OSGi bundles that have been developed. Typically, OSGi-aware test cases test provided services or exported packages of a given OSGi bundle and can follow different test models. TEE is responsible for the installation of OSGi-aware test cases and their execution. Moreover, TEE generates comprehensive user-friendly reports containing the results of the test case execution.

2.9 Remote Management Extension mBS Runtime also contains a set of features related to remote management from a backend system such as mPower Remote Manager (mPRM) from ProSyst:

mPRM Management Agent. This agent is specifically designed to work with the mPRM backend system. By using the messaging protocols of mPRM the agent offers the following benefits to the users of the remote management system:

 Full lifecycle management (install, start, stop, update and uninstall) of OSGi bundles, OSGi- aware applications, Android applications and Linux native packages.  Intelligent management of OSGi-based configurations, permissions, logs, etc.  Push deployment of software components.  Remote monitoring and diagnostics of the OSGi environment as well as of the underlying native platform.  Restart of the OSGi framework or of the underlying device operating system with clean or ready storage.  Update of the mBS Runtime image, JVM or device firmware.  Remote management of devices accessible through the Home Device Manager abstraction. The agent is not included in mBS Runtime but can be downloaded from mPRM during initial provisioning. It can also be included in the OSGi target image if required.

OMA-DM. The OMA-DM module offers full-featured functionality of a SyncML client, including support of the OMA device management version 1.2. The use of this module allows bundles to be remotely managed over adopted standards, such as the OMA DM.

3 Eclipse Plug-ins

The mBS SDK plug-ins extend the Eclipse environment with a user-friendly toolkit for development of OSGi-compliant applications and for running them on runtime emulation or directly on the target device. mBS SDK plug-ins are divided in the following main groups: mToolkit. Represents a collection of convenient tools for deployment and management of OSGi-compliant bundles on OSGi Runtimes straight from within the Eclipse Workbench. mBProfiler. Assists developers in improving the efficiency of applications by exploring different aspects of the performance of a Java program, associated with JVM’s consumption of the available platform resources (CPU, memory and threads).

System plug-ins. Offers a set of supplementary features helping developers in constructing applications for concrete images of mBS Runtime.

3.1 mToolkit

Developers can use mToolkit to perform the following advanced tasks:

Fig. 2: Deploying Eclipse bundles on mBS Runtime via mToolkit

 Manage OSGi environments on remote devices including bundle installation and update, examination of the installed components in a tree-like manner, etc.  Model and build OSGi Runtime images that best fit the requirements of the target device platform.  Create and generate new images based on existing images that can be tailored according to the user preferences.  Support for generating images in Android application package format (APK).  Launch the OSGi Runtime on a target device in normal, debug or profile mode.  Start an OSGi Runtime emulation on a development PC, for example to examine the cooperation between certain functional bundles. The emulation can be in normal, debug or profile mode too.  Include in runtime images or deploy on them content developed in the form of Maven Eclipse projects.  Check the compatibility of Java applications, including OSGi Runtime emulations, on the PERC, CEE-J (Skelmir VM) and phoneME (CVM) JVMs, which are specially designed to operate on device platforms.  Share content by utilizing the mPRM software repository directly from the Eclipse IDE. Users can download bundles from mPRM and add them to the Eclipse Target Platform, and upload bundles from the Eclipse workspace back to the repository.  Integration of the TEE manager in Eclipse's JUnit view and support for JUnit4 and Maven projects in the TEE manager.  Support for creating and executing of JUnit3 and JUnit4 test-cases for mBS OSGI environment and importing JUnit XML reports in Eclipse.  Support for providing detailed information for the bundle signer's certificate chain in OSGi management.

3.2 mBProfiler mBProfiler provides the following functionality related to evaluating the resource usage by the OSGi Runtime on the target device and by the applications it hosts

Fig. 3: Using mBProfiler to monitor resource usage on a target device

 OSGi profiling support  Memory consumption measurement

 Memory stack frames tracing  CPU loads profiling  Momentary heap allocation information  Thread state progress statistics  Visual representation of JVM’s workloads by different parameters  Tracking the stack traces of active threads and the monitors they use.  Source code reference  Garbage collection during profiling  Remote profiling  Profiling only of a particular stage or a combination of several stages from the program life cycle  Using different target environments  Saving the profiling information for further examination  Exporting the profiling information in text or XML format  Support for Java 8 for the mBProfiler Agent

3.2.1 Supported Platforms for mBProfiler Agent The following table lists the support for the mBProfiler Agent and its requirements to operate on different hardware, operating systems and JVMs.

System Components mBProfiler Agent Requirements

Hardware 100 MHz processor

0.5 MB RAM

OS Microsoft Windows CE, XP, Vista, 7, 8 & 10

Linux

Mac OS X (10.10-10.12)

BSD (on request)

QNX (on request)

VxWorks (on request)

Solaris (on request)

JVM3 Oracle Java SE 1.2 to 1.6 build 3 for JVMPI

Oracle Java SE 1.5 and above for JVMTI

Oracle Java SE Embedded

phoneME Advanced MR2 (only for Linux)

IBM J9 2.3, 2.4

Skelmir CEE-J® VM 2.x, 3.x, 4.x

Aonix Perc® Ultra 5.x, 6.x

3 JVM should support JVMPI or JVMTI Oracle 1.6 b14 or above should be used for 64-bit support.

3.3 System Plug-ins

The System Plug-ins provide the following components for creating applications based on the mBS Runtime features: mBS SDK Target Platform. Introduces a custom mBS Target Platform to the Eclipse Plug-in Development environment. It enables developers to use all features of Eclipse PDE while developing bundles aimed to run at the mBS Runtime.

Target Image Descriptors. Represent a set of pre-defined OSGi Runtime images containing the functional components for the most typical production use cases. Developers can use the image descriptors to generate a ready runtime and deploy it on devices, to emulate a runtime on a PC or to design own images based on the pre-defined ones.

4 OSGi Runtime Validator

OSGi Runtime Validator provides means for evaluation of a specific target image including:

Functional Validation. Running a ready set of tests for verification of the features in the mBS Runtime image on the target platform. These tests cover both the OSGi Framework implementation and the other ProSyst-delivered bundles. Functional validation can be used not only to examine functionality but also to verify performance and stability.

Performance Validation. Running a functional test with included performance measurements.

Stability Validation. Running continuously specific functional tests.

5 Addons

5.1 Board Support Packages

To achieve the full potential of the OSGi runtime, it is often required to have a few native components integrated in the runtime. These include a component that takes care for the communication with the serial port and USB, a native agent that monitors and controls the execution of the whole runtime process, etc. The native components of the OSGi runtime can be customized for various embedded platforms with different hardware characteristics. This customization is achieved in the form of board extensions that are provided as an add-on to the SDK. The SDK comes with the native components and scripts that are necessary to support tailoring images on Raspberry Pi, but board extensions for other platforms can be prepared as well upon client request based on a purchased support package or an order for professional services

6 Appendix A: Resources

You can find more resources about the mBS SDK at the following links: http://dz.prosyst.com – ProSyst’s Developer Zone http://dz.prosyst.com/devzone/OtherFields – An overview of mBS SDK and user manuals of its components.