Measure latency for embedded systems with this open source tool

When it comes to time synchronization for embedded systems in a distributed architecture, there are "soft" use cases (typical, everyday devices) and complex, or "hard," use cases (car brake systems, aerospace). It's easy to see that a hard use case has unique requirements and a low tolerance for latency. To put it another way, hard use cases have hard, real-time constraints.

Latency is the bitter enemy of real-time computation. Latency, in the context of a critical real-time application, is the time between data generation and data reception. The reality is that when there is an interconnected network of several systems, there's latency.

[ Related read Edge computing: Latency matters ]

What's the difference between soft and hard real-time use cases?

A soft use case is easy to manage. Here are some examples of soft use cases:

• A washing machine with a detergent dispenser that needs to be refilled after every wash.
• A printer that needs to be refilled with paper.
• A car that needs to be refilled with gasoline or recharged with electricity.

Hard cases, however, are complicated to synchronize and complex to connect. The following are examples of hard use cases:

• Car braking systems where no other system (such as steering) can interfere or cause latency.
• Nuclear power plants where a sensor must send back a status report in real-time to enable decision-making without disruption from another component of the system.
• A rocket, which must be able to correct its trajectory in real-time to avoid being compromised by external elements such as weather conditions.

How the embedded world deals with real-time

Consistent latency is no guarantee when working with distributed (multi-MCU) critical and real-time environments. If there happens to be many collisions in a system, a message could be delayed multiple times, dramatically and unpredictably increasing latency. In such a situation, younger (newer) data could arrive before older data, compromising the system's integrity.

Image by:

(Nicolas Rabault, CC BY-SA 4.0)

Typically, there is no real-time clock (RTC) in the embedded world because that requires a power source, which isn't always possible, and even if there were one, the system would lose time measurement in the event of a power disruption. The same problem is true when you try to update time from the Internet.

In embedded systems, nothing handles time tracking when a system is off, and nothing synchronizes time when the system powers on. In most cases, the timeline starts when the system starts.

Luos allows timelines management

While it is physically impossible to remove latency completely, monitoring it is important to guarantee data validity. By measuring latencies in real-time, the open source Luos engine, released under the Apache2 license, uses the latency value to know the real, local date of an event. There's no global timeline, just a delta between data generation and consumption. Luos precisely measures that delta with any network.

Luos is an open source software and a modular methodology to simplify the creation and sharing of embedded features. Luos encapsulates hardware and software functions as microservices so that each electronic device has a set of functions that communicate and recognize each other but remain independent.

Without Luos, the developer must synchronize timelines. It's up to the developer to control latency and to update the dates on each system so that each one has the same time repository. It's hard to do and uses a lot of resources.

With distributed latency-based time synchronization, a developer no longer needs to work with a global timeline, which is often difficult, given that each node has a different timeline. Luos consolidates these timelines to avoid having one "correct" point in time and instead allows each system to have control. This design is completely multi-master. The reference timeline is the local timeline of the node the developer is looking through. Luos is able to remap an event date across the node's local timeline by measuring latency.

Real-time developers are used to working with a global timeline and might question whether the method used by Luos is accurate, given such critical use cases. The answer is yes because the nodes communicate and all have the same level of information without having a centralized master. It's as if synchronization were happening each time data is modified in the global system.

[ Get the eBook, Open source data pipelines for intelligent applications ]

How Luos works

Technically, Luos computes latency. Across nodes a sum of delays exists, including the source latency, the target latency, and the network latency. Luos evaluates that information and sums it up to remap the information on the local timeline using a timestamp.

It is possible to measure an event in the past or the future. Thus, Luos can use the measurement for data collection and for precisely programmed commands.

Do you want to get started with Luos and embedded systems? Go deeper with Luos on Luos.io.