Xentara basics: Microservices

Industrial automation • By Robert Schachner • May 23, 2025
Xentara provides two primary task types for application integration: - Skills (focused on communication) - Microservices (focused on application logic) These tasks interact through IO Points and are orchestrated by the timing model. As tasks are shared libraries they can be combined in any constellation during the startup phase by the Xentara Core. Tasks are defined in the JSON configuration file as object types with defined IO Points and can be instantiated dynamically at runtime. They are triggered by the timing model, either via event-based mechanisms or through high-precision cyclic timers. Tasks can run independently on dedicated CPU cores or be arranged into pipelines, which in turn can be organized into Tracks. As a modern PREEMPT-RT solution, Xentara enables precise real-time execution, achieving timing Latency in the range of 1 µs — even on platforms such as Intel Atom. This modular architecture supports highly flexible, real-time control and can be seamlessly integrated with fieldbuses, machine learning systems, simulation models, and applications built using various development technologies.
Xentara basics: Microservices

Fundamentals.

 Xentara provides two fundamental Task types for adapting applications:

Skills and Microservices

Skills focus on communication with external systems such as fieldbuses, databases, brokers, and machine learning models. In contrast, Microservices are a simplified variation of centered on application logic developed using various technologies like C/C++, Rust, Python, PLC code, MATLAB/Simulink..

Tasks are executed as shared libraries on Linux or as DLLs on Windows. At the source code level, they are platform-independent thanks to a unified abstraction layer in the Xentara Core. On Linux, this abstraction layer enables differentiation between PREEMPT-RT lockless mechanisms and standard Linux function libraries. This design allows latency precision in the range of approximately 1 µs, even on resource-constrained platforms such as Intel Atom. 

Both task types have access to static and dynamic attributes of IO Points or Data Points, which are organized within Xentara’s hierarchical, object-oriented semantic data model.

Tasks are only executed if they are connected to the Timing Model. The Timing Model is able to handle Tasks with High Precision Timers in a cyclic way or event based according to certain Sources. And Tasks can be handled individually or in sequential pipelines on different processor cores. 

Skills and Microservices as basic Elements of Xentara

Tasks are permanently connected to the Xentara core via different shared Library Interfaces.  And each task can be instantiated as an object as frequently as necessary.

 

Tasks in the Timing Model

To execute Tasks, they have to be connected to the Xentara Timing Model and, if required, safely write into the Data Model. Within the Timing Model Tasks be linked to high-precision cyclic timers and/or event-based triggers for execution.

In addition to a simple activation, tracks can be defined to enable sequential task execution. Tasks can be assigned to dedicated CPU cores, ensuring deterministic runtime behavior. Checkpoints allow synchronization of tasks across different cores.

A distinctive feature of Xentara is its Thread-Optimization. Threads from a shared thread pool manage the whole task execution in Xentara. When tasks are grouped within the same processing pipeline, a single thread executes them without context switching. As a result, entire pipelines with multiple tasks can be processed within just a few microseconds, achieving latencies as low as 1 µs (Intel Atom).

 Skills and microservices in a schedule

Skills and Microservice Stages

The stages are: startup, pre-operational, operational, post-operational, and shutdown.

During the startup phase, the Task connects to Xentara or the data model.  Within that time period, tasks can initialize interfaces, load configuration data. In pre-operational or post-operational mode, tasks are removed from the active timing model but remain linked to Xentara.  For example, fresh data can be loaded during the pre-operational phase so that it can be handled in synchrony with other objects in the operational phase.  

During the shutdown phase, tasks can close their devices and at the end the connection is unplugged, and any necessary memory is released.