ConceRTOS is a modern development framework for embedded systems. It consists of a hard real-time operating system (RTOS) including libraries accelerating the development of applications, an OS Abstraction Layer and a Hardware Abstraction Layer.

ConceRTOS consists of a hard-real time operating system, an OS Abstraction Layer (OSAL) and a Hardware Abstraction Layer (HAL). The OSAL and the HAL decouples the application logic from the hardware and from the actual OS implementation.

ConceRTOS is deployed in a wide range of products ranging from wearables, therapeutic and medical devices to industry applications like process monitoring in pharma production or controllers for smart home applications, illumination and ultra-low power sensor nodes.

You want firmware not a framework?

ConceRTOS Microkernel (ConceRTOS MK)

The OSAL abstracts the implementation of building blocks of embedded operating systems (Executor, Memory Manager, SPI, ...). This leads to great flexibility regarding the actual implementation of the functionality.

When developing with ConceRTOS OSAL, developers are not bound to use any specific OS. It is possible to implement some or all the functionality (e.g. Memory Manager) from scratch ("bare metal"). Additionally, one can use implementations of an RTOS or use a combination of both: custom code and off-the-shelf modules. It is also possible to use an operating system like Linux. This allows to run and debug code directly on the host machine which increases efficiency of the development process.

ConceRTOS MK is a ConceRTOS OSAL compatible RTOS implementation. With its modular architecture, it was uncompromisingly designed for ultra-low-power applications (Wearables, IoT devices, ...). It allows the developers to only include what is really needed resulting in lean and lightweight code.

Modularity and Dependency Injection

ConceRTOS OSAL compatible implementations can be integrated into the application using dependency injection.

The modularity and the OSAL of ConceRTOS enables fast prototyping without the loss of this investment in a first development cycle. Early and simple versions of modules can easily be replaced at a later stage by injecting a more sophisticated version (e.g. ConceRTOS Microkernel medical grade module).

ConceRTOS Microkernel

Pre-emptive Scheduling

Lockless pre-emptive scheduling

By default, ConceRTOS uses a pre-emptive scheduler without critical sections / locks. In fact, all core RTOS services are designed with lock-less data-structures, putting the lowest amount of constraints on the application. The lockless nature combined with the advanced memory management solution prevents priority inversion. This is very important for safety critical applications. If priority inversion would be possible, a low priority task (e.g. patient data logger) could block the execution of a high priority task (e.g. patient alarm).

Some RTOSs solve this problem on the thread mode level only, but not on the handler mode level, where for example data structures for tasks are managed. ConceRTOS has no critical sections on the handler mode level. This guarantees deterministic maximum latency to interrupt a running task and create a task with higher priority.

When developing an application with ConceRTOS it is still possible to make use of critical sections. The framework provides a locking mechanism which allows the user to protect access to shared resources with a very high granularity. If a task is inside the critical section, another task will have to wait entering the same critical section until the owning task has left it. But it can still be interrupted by hardware interrupts to guarantee deterministic maximum times for task execution after an interrupt occurred.

Memory Management

Modular Memory Management

ConceRTOS comes with two built in memory allocators, which are highly optimised for low power and resource usage. To guarantee maximum flexibility, developers are free to use those or develop their own.

Simple Memory Allocator: Memory can be allocated in a flexible way. There are no restrictions regarding the minimal or maximal size of memory allocation. To ensure memory consistency, this allocator uses a global lock on the memory. This could lead to priority inversion of tasks - the block memory allocator prevents this.

Block Memory Allocator: The advanced memory allocator splits the available memory up into equally sized chunks. This allocator needs no memory lock and time to allocate is deterministic. The maximum size of memory that can be allocated for a data structure is equal to the chunk size.

Both memory allocators support memory quotas. A quota can be assigned to each allocator. This prevents failures from one allocator (e.g. memory leak) to affect other allocators.

The developer always has complete control over which memory allocator is used. He can inject the desired memory allocator into the firmware components.

Power Management

Power Governors and Power Zones

ConceRTOS uses a tickless idle mode. This means that when the processor is idling it doesn't need to periodically check if there is work to do. A timer quartz is used to wake up the processor if needed.

A huge amount of energy saving potential exists in-between tasks when the processor and other components can be shut down. Whenever possible ConceRTOS runs in the lowest power mode available from the microcontroller to ensure maximum energy efficiency in-between tasks. The challenge is to decide, whether it is reasonable to put the processor into idling in-between tasks or if the time is too short to safe energy (waking the processor up also uses energy).

ConceRTOS uses so called "Power Governors" to decide what power management policy should be applied. Power management policies are made up out of a wake up deadline and a power management mode (e.g. lowest power, low latency). Each governor has information regarding upcoming tasks. At the end of each task the power manager asks all the governors to negotiate an optimal power management policy for the current situation. The power manager then executes this policy depending on the available execution modes and wake up times of the MCU.

Power Zones

To further improve energy efficiency ConceRTOS also allows to control (e.g. shutdown when not needed) external resources (e.g. flash memory, communication modules). External resources often depend on other internal (in MCU) or external resources. Multiple related power zones form dependency trees which allow the representation of relationships between resources. Each Power Zone contains an "Entry Recipe" and an "Exit Recipe". "Exit recipes" could for example contain instructions to shut down certain resources.

ConceRTOS Libraries

Signal Processing

Easy Signal Processing and Storage

ConceRTOS contains a signal processing framework which provides the necessary tools to efficiently handle sensor data. It includes a storage component to support storing the results in the flash memory.

The framework is based on the publish and subscribe pattern. Subscribers can also be multicast enabled publishers, which allows to build tree-structures for processing data. The diagram on the right shows, what such a tree to process data from an accelerometer could look like.

To get the desired information out of sensor data, it is often necessary to add timestamps. The signal processing framework automatically adds the correct timestamp right after the values were received from the sensor. It also estimates the exact sample rate (sensors are often self-timed).

Another very useful feature is gates - they allow to interrupt the dataflow to their subscribers. This can be useful, if for example the execution of an algorithm after the gate is not useful with the currently received data. The gates contain pre- and post-buffers too. The pre-buffer allows to process data further down the tree, that was recorded before the gate was activated.

REST Framework / API

RESTful Interface for Easy Communication

ConceRTOS includes a REST server which allows to access data on the device like accessing data from a RESTful webservice. This makes it very easy for application developers to communicate with devices running ConceRTOS.

The endpoints on the server-side (device) are modular and independent of each other. Each endpoint provides access to some functionality or data.

High Level Abstraction

Based on the REST client, ConceRTOS comes with various higher level libraries to help developers communicate with the devices. They include the following functionality:

Live Stream

Signal Storage

Firmware Update

Device Management Server API

Settings Management

Versioned Settings for Easy Migration

Settings for components can be persisted in a key/value store. Strings are used as keys and the value is binary but supports JSON.

The Settings Manager has an internal API for the components and is optimized for flash memory. Components have CRUD rights on their own settings and use the REST API component to allow external devices to change the settings for a component.

The Settings Manager is fail safe. Even in case of a power failure, partial settings are not stored. The API of the settings manager requires the developer to assign a version to each setting. By thinking about versioning upfront, the application will already be prepared for future setting migration procedures.

Hardware Abstraction

Modular Component Development

ConceRTOS provides a hardware abstraction layer for some of the commonly used communication protocols like SPI, I2C, UART, etc. Drivers and other components can be developed against this abstraction and therefore easily be ported to another microcontroller architecture.

SFOTA

Secure Firmware-Over-the-Air Updates

With ConceRTOS it is possible to update the firmware securely over the air. Either directly over the internet or via a gateway (e.g. smartphone).

First, the active firmware asks the DMS (Device Management Server) if there is a newer firmware available for this device. If this is the case, the firmware is downloaded and stored in a second flash memory. Before transmitting the firmware, it is encrypted on the server-side using a unique key. The encrypted firmware can only be decrypted by the device it is intended for.

The upgrading process is failsafe. If for example, the upgrading process is interrupted due to power loss, the bootloader will recognize that the upgrade hasn’t been successful and start over again.

Other bootloading scenarios are also possible and can be implemented if necessary (e.g. without encryption or the use of external flash memory).