ConceRTOS
ConceRTOS is a modern development framework for embedded systems. It consists of a hard real-time operating system (RTOS) including libraries, an OS Abstraction Layer (OSAL) and a Hardware Abstraction Layer (HAL) to provide maximum flexibility and accelerate application development.
Flexibility
Modularity, OS- and hardware abstraction layers and dependency injection combine to provide great flexibility and continuity in your development.
Speed
Develop your prototype based on our pre-tested libraries and flexible framework to reduce time to market and required iterations.
Low Power
Energy efficient by design - it is not just an afterthought. Every aspect is optimized for low power usage and optimally suited for wearables and other battery-powered applications.
Medical
The framework is being implemented in medical devices. We know the required documentation effort and are comfortable working within your existing Quality Management System.
Over-the-Air
The framework includes libraries for secure Firmware-Over-The-Air (FOTA) updates. Profit from our expertise to implement automatic rollbacks and sophisticated encryption.
How It Works.
Modular Embedded Development Framework
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, giving you maximum flexibility and freedom to change specific system components.
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 lines or controllers for smart home applications, illumination and ultra-low power sensor nodes.
ConceRTOS Microkernel (MK)
The OSAL abstracts the implementation of building blocks of embedded operating systems (Executor, Memory Manager, SPI, etc.). 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 like wearables or IoT devices. It allows the developers to only include what is really needed resulting in lean and lightweight code.
Ecosystem components facilitate seamless integration with existing applications (e.g. Android, iOS, Python, Servers, ERP-systems). The ConceRTOS Microkernel is designed for safety-critical applications. Preemptive scheduling and advanced memory management guarantee deterministic limits for event handling.
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.
ConceRTOS Libraries.
ConceRTOS contains a signal processing framework, which provides the necessary tools to efficiently handle sensor data. It includes a storage component to save results on the flash memory.
The framework is based on the publish-subscribe pattern. Subscribers can also be multicast enabled publishers, which allows building tree structures for data processing. The diagram on the right shows and example tree for the processing of data from an accelerometer.
It is often necessary to add time stamps to sensor data as basis for further analysis. The signal processing framework automatically adds the correct timestamp right after the values are received from the sensor. It also estimates the exact sample rate, since sensors are often self-timed.
Another very useful feature are gates. They allow to interrupt the data flow to their subscribers e.g. to avoid running an algorithm based on unsuitable data. The gates contain pre- and post-buffers. The pre-buffer, for example, allows processing data further down the tree, which was recorded before the activation of the gate.
To allow Bluetooth devices to establish secure connections and roam between infinite gateways, we provide libraries to implement TLS-based end-to-end encryption with authentication during manufacturing / provisioning of the device.
Based on Public Key Infrastructure (PKI), two pairs of public / private keys are generated, while both the server and the device each get the public key of one and the private key of the other pair. For every session between the device and the server, a separate encryption key is generated based on these two pre-shared keys.
Consequently, the gateways only serve as a pipe and are completely interchangeable during a session, resulting in roaming with infinite gateways and perfect forward secrecy. Standard Bluetooth protocols only allow to establish trust from point-to-point. This means your devices would have to remember authentications for each gateway in the network.
ConceRTOS is ready for secure firmware over-the-air updates. Updates can be distributed to devices either directly over the internet or via a gateway (e.g. smartphone).
New firmware can be pulled by devices according to the following process. First, the active firmware asks the Device Hub, 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 fail-safe with an automatic rollback. If the upgrading process is interrupted due to power loss, for example, the bootloader recognizes that the upgrade was not successful, keeps running on the old firmware and restarts the update process.
This update process can be adapted to specific customer requirements like dispensing with encryption or using an external flash memory.
ConceRTOS includes a REST server, which allows accessing data on the device like accessing data from a RESTful web service. This makes it very easy for application developers to communicate with devices running ConceRTOS.
ConceRTOS uses asynchronous (non-blocking) communication and comes with JSON encoders/decoders. The REST server supports create, read, update and delete operations. On the client-side, libraries are available for Python (Windows, Mac, Linux), Android and iOS.
The endpoints on the server-side (device) are modular and independent of each other. Each endpoint provides access to specific functionalities 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 for components can be persisted in a key/value store. Strings are used as keys and the value is binary (incl. JSON support).
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 settings.
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. Consistent versioning ensures that the application is well-prepared for future setting migration procedures.
ConceRTOS provides a hardware abstraction layer for some commonly used communication protocols like SPI, I2C and UART. Drivers and other components can be developed against this abstraction and can therefore easily be ported to another microcontroller architecture.
ConceRTOS Microkernel.
ConceRTOS uses a preemptive scheduler without critical sections / locks. All core services of the RTOS are designed with lockless data structures to minimize the amount of constraints on the application. The lockless nature combined with advanced memory management prevents priority inversion, which is crucial for safety critical applications. Otherwise, a low priority task (e.g. patient data logger) could block the execution of a high priority task (e.g. patient alarm).
Some RTOS 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 specific shared resources. 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. However, it can still be interrupted by hardware interrupts to guarantee deterministic maximum times for task execution after an interrupt occurred.
ConceRTOS comes with two built-in memory allocators, which are optimized 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 flexibly. 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. Potential priority inversions of tasks are prevented by the block memory allocator.
Advanced Memory Allocator: The advanced block memory allocator splits the available memory up into equally sized chunks. This allocator needs no memory lock and the time to allocate is deterministic. The maximum size of allocatable memory for a data structure is equal to the chunk size.
Custom Memory Allocator: Implement against the standardized memory allocator interface and use your own memory allocator.
Both built-in 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 has complete control over which memory allocator is used by injecting the desired memory allocator into the firmware components.
ConceRTOS uses a tickless idle mode. This means that while the processor is idling, it doesn’t need to periodically check for work to be done. A quartz timer is used to wake the processor up, if needed.
A lot of energy can be saved in between tasks by shutting down the processor and other components. Whenever possible, ConceRTOS runs in the lowest power mode available from the microcontroller to ensure maximum energy efficiency. The challenge is to decide, whether it is reasonable to put the processor into idling between tasks or if the time is too short to safe energy considering the amount needed to wake the processor back up.
ConceRTOS uses so called “Power Governors” to decide, which power management policy is optimal. Power management policies are a combination of wake up deadline and power management mode (e.g. low latency, lowest power). 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.
To further improve energy efficiency, ConceRTOS allows controlling (e.g. shutdown while not needed) external resources like flash memory or communication modules.
External resources often depend on other internal (MCU) or external resources. Multiple related power zones form dependency trees, which allow the representation of interrelationships.
Each Power Zone contains an “Entry Recipe” and an “Exit Recipe”. “Exit recipes” could for example contain instructions to shut down certain resources.
