Xentara Basics: Distributed Real-Time Scheduling

Xentara is a real-time convergence platform that includes both a Timing- and Data Model.  This governs the whole timing for OT and IT tasks. 

Key components are microservices and Skills (commonly called task) and Data Points.

The Timing Model Control extends over local tasks, cores, and systems.  This is the only technique to reliably synchronize software with the determinism of mechanical processes in an automation setting.  The problem is similar in test systems, where the functional scope of a system under test (SUT) is frequently validated only by well-defined and verifiable sampling rates.

Definition.

According to DIN ISO/IEC 2382 Part 9 (processing sequences), "real-time" refers to the functioning of a computer system in which programs for processing incoming data are constantly ready for use in such a way that the processing results are available within a given time frame.  Depending on the application, data can be generated randomly or at specified intervals." 

 Thus, real-time needs are primarily concerned with determinism, not high data flow or fast processing.

 The Xentara Timing Model ensures that even vast amounts of non-time-critical data are processed properly, freeing up computer power for time-critical signals.  However, it also allows you to distribute task pools freely or use machine learning methods to optimize the required temporal behaviour.

Events, Timers, and Named Triggers

 Xentara is a complete event-driven system of networked objects.  All active aspects of Xentara can trigger events:

 Features include I/O points, data points, microservices, tasks, and a timer.

 For example, updating a variable can cause data to be transferred to other nodes or activate other activities or microservices. 

 Timers differ from other types of triggers in that they repeat the triggering process on a regular basis, in this case with an adjustable cycle time.

 Named triggers enable the distribution of individual events to several objects in Xentara at the same time.

Tracks and Pipelines

Within a PLC a simple cyclic Timing organizes the whole application in only 3 Steps:

• Reading Data from I/O
• Processing Data
• Writing Data to I/O

As IT Applications are always Event based, OT Systems can't be used for OT and IT Application. Only the Xentara Timing Model allows such a flexible orchestration of Tasks within Cores for both IT and OT applications. 

The Xentara Timing Model is based on triggers, which can be activated by High-Precision Timers and Events. Events can originate from:

• Application logic within microservices
• On Change events from Data- an-d IO-Points points
• Hardware interrupts via operating system drivers, adapted by a Xentara skills

Such a trigger generally activates all tasks attached to it at the same time.

The following example shows a possible Organization of tasks on two cores with a combination of cyclic Timer and one Event:

 Example of Xentara Scheduler Execution Pipeline

In this example, time progresses along the t-axis. The resolution of the timing model for all steps can be defined in nanoseconds. Experience with a Linux system using the PREEMPT-RT patch and an Intel Atom processor shows a pipeline start latency of approximately 1 µs.

Simultaneously, two segments are executed in parallel:

• Segment A runs on Core 1 with a skill for IO-Link sensors
• Core 2 runs a skill for an EtherCAT fieldbus.

Checkpoint 1, triggered by a cyclic timer, signals the synchronized start across both cores. Threads from the global thread pool are assigned to each core accordingly.

Since the IO-Link skill in Segment A completes before reaching Checkpoint 2, it simply signals that all data has been acquired. The corresponding thread then terminates its activity and returns to the thread pool, making it available for other tasks.

Once the EtherCAT skill in Segment B has finished processing all fieldbus data, the thread checks the status of Segment A. After confirming that all tasks in Segment A are complete, the thread proceeds to execute a machine learning model using the Xentara ONNX interface. This avoids a context switch, saving approximately 3 µs per transition during further processing.

As no checkpoint is defined for the next transition, the same thread continues execution with the control logic task. Within this logic, a decision is made to initiate a database job. An event is triggered that starts a task responsible for collecting all currently available data and writing it to an InfluxDB instance. A new thread is activated for this purpose and returns to the thread pool once the task is complete.

After the logic in Segment C is executed, the task also resumes execution of the EtherCAT skill. Depending on the configuration, the EtherCAT master may now operate only outputs or only drives. With the completion signal sent to Checkpoint 3, the entire pipeline has been executed, allowing the track to return to the track pool.

Thanks to this optimized task execution strategy, the Xentara scheduler saves approximately 10–20 µs per cycle, depending on the processor type. This represents around 10% of the total execution time, depending on application complexity.

This example represents only a simplified timing model. In practice, Xentara is capable of managing thousands of tasks distributed across multiple CPU cores. Tasks can be assigned real-time priority, ensuring they are not interrupted—neither by other tasks nor by the Linux operating system itself.

Additionally, core shielding allows dedicated CPU cores to be reserved exclusively for use within the Xentara Timing Model, guaranteeing deterministic execution and minimizing latency.

In essence, this approach provides an effective solution for converging IT and OT systems on a single hardware platform, fully orchestrated by Xentara.