Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to deal with the real-time requirements of embedded systems?

The real-time requirements of embedded systems are one of the key factors for their successful operation. Real-time requirements involve ensuring that the system can respond and perform tasks within a predetermined time. This article will discuss how to deal with the real-time requirements of embedded systems and illustrate it with specific cases and parameters.

1. Classification of real-time requirements

Before dealing with the real-time requirements of embedded systems, it is first necessary to understand the classification of these requirements:

Hard Real-Time Systems: These systems require tasks to be completed within a specified time. For example, flight control systems on airplanes must operate within strict time constraints, otherwise catastrophic consequences may result.

Soft Real-Time Systems: These systems are more flexible in the timing of tasks, but still need to be completed within a reasonable time. Video streaming is an example where a slight delay may be acceptable, but too much delay will degrade the user experience.

2. Processing of hard real-time systems

For hard real-time systems, real-time requirements are critical. Here are some ways to handle the real-time requirements of hard real-time systems:

Task priority assignment: Assign tasks to different priorities to ensure that critical tasks are executed within the scheduled time.

Task Scheduling Algorithm: Use an appropriate task scheduling algorithm such as Shortest Job First (SJF) or Earliest Deadline First (EDF) to maximize time requirements.

Hardware support: Use specialized hardware, such as a real-time operating system or coprocessor, to improve task response times.

3. Processing of soft real-time systems

For soft real-time systems, the real-time requirements are relatively flexible, but still need to be processed. Here are some ways to handle the real-time requirements of soft real-time systems:

Task Optimization: Optimize a task's algorithm to reduce execution time and thus better meet time constraints.

Buffering and Prediction: Use buffers to handle bursts of load while predicting system load to better prioritize tasks.

Resource management: Ensure reasonable allocation of system resources to avoid excessive competition, resulting in tasks not being completed on time.

Case Study: Automotive Anti-Lock Braking System (ABS)

Let’s use a car’s anti-lock braking system (ABS) as an example of how to handle real-time requirements.

Hard real-time requirements: ABS must quickly adjust brake pressure when the wheels are about to lock. This is a hard real-time requirement, as delays can cause the vehicle to lose control.

Task priority: The ABS system divides braking tasks into different priorities. With hardware support, the highest priority task (preventing wheel lock) has the shortest response time.

Real-time operating system: ABS systems usually run on a real-time operating system to ensure that tasks can be executed on time.

In this case, the ABS system uses a variety of methods to meet its hard real-time requirements and ensure that the vehicle remains safe during emergency situations.

In summary, the real-time requirements of embedded systems can be met through appropriate task allocation, scheduling algorithms and hardware support. Different types of systems and applications may require different methods to ensure tasks are completed within time constraints. Therefore, understanding and handling real-time requirements is an important part of embedded system design.
 
Can we see some examples? I mean, recently I was making a project on gas leakage notifier. An MQ-2 gas sensor was connected to an ESP8266. When the gas density crossed a threshold level, the ESP8266 sent a WhatsApp message. To my disappointment, I noticed that I did not receive the message immediately when the value crossed the threshold level. That means the project was not behaving as a real-time one. How to solve such problems?
 
@tepalia02:

Your description is not very precise.

To my disappointment, I noticed that I did not receive the message immediately when the value crossed the threshold level.
What does "immediately" mean? nanoseconds? within one minute?
"not receive" .. is probably hitting the point. I mean the ESP is responsible for sending the sessage ... but your message travels various paths, each adding delay. So the ESP can not determine when you "receive" the message.

And how did you test it? How do you know it was not "immediately"?

"Real time" is a vague description.
It may mean to do ADC sampling with 1M sapmple per second .. not missing a single value.
It could also mean to perform an FFT and draw the chart on a display once per second. ... of the above sampled data.

"Real time" for a tsunami warning system may be in the order of minutes.

Klaus
 
Thank you for responding. I was monitoring the gas sensor value in serial monitor. According to my program, when the gas sensor value equals or exceeds 400, the ESP8266 will send a whatsapp message. I saw the gas sensor value exceeding 400 in the serial monitor. But I received the message after approximately 1 minute or more.
 
Hi,

Again: The ESP is not reponsible for when you receive the message.

So you have to check when the ESP SENDS the message.

Klaus
 
A real-time system executes time-critical tasks synchronously within defined interrupt cycles.

Priority-based execution ensures high-priority tasks are handled first. The goal is to minimize latency and meet strict timing constraints for critical operations.

In 1977, I was on a team to create a robotic remote for moving and driving an eddy current probe and then collecting the data. This is now called Supervisor Control And Data Acquisition or SCADA. The operations of the interfaces for telemetry were all synchronous and the data had to be ready to send for each frame of data to send and receive so the MC6800 used real-time coded interrupts to process all the 128 inputs and 128 outputs according to the required latency for each port. For more complex tasks, now there are RTOS or real-time OS's but this was done in machine code.

In 1979, I worked for a different telecom R&D company and we used real-time IRQ's of 1.5 ms because this was the synchronous time for 1 frame of 24 channels of 64 kbaud voice or data. This meant in order to have no latency, each repeater stage of the network did not buffer the audio or data but synchronous all the upstream channels into one of the unused available channels based on concentration ratios for allocation. It also meant each upstream Tx would have to delay their data by a fraction of a clock bit so everyone was received at the same time as detected by the upstream concentrator. The bit rate was the North American standard for DS1 (nee T1) at 1.544 Mbps full duplex. The real-time IRQ's were necessary to synchronize voice & data to the DS1 stream time slots. A supervisory channel handled real-time messages according to priorities and latency tolerances in organized stacks with pointers. This included Fire and burglar alarms, automated meter readings (AMR), video text, opinion polling, graphic weather maps etc. It was called Project IDA for MTS and we were Interdiscom Systems Ltd in Winnipeg.

It's hard to believe, we once had more than 60 dB SNR clear audio back then with 99.99% uptime and now we have to put up with 20 dB SNR with companded, compressed, and distorted audio with frequent dropouts. Now our neighbour has tons of buried unused twisted pair copper, replaced with high-speed mobile or high-speed asynchronous internet trunks.

Then there is Real Time with Bill Maher (lol)
 
Thank you for responding. I was monitoring the gas sensor value in serial monitor. According to my program, when the gas sensor value equals or exceeds 400, the ESP8266 will send a whatsapp message. I saw the gas sensor value exceeding 400 in the serial monitor. But I received the message after approximately 1 minute or more.
Are you using IFTTT or MQTT as intermediary to generate the message ? Even this bellies the fact you are
in a packet based system that intrinsically has latency, and in your case the message has to be
processed and redirected. Basically you are using a shared resource system, eg. routers and switches,
and latency inherent.


Unless of course you are doing this entirely on a local network, and then the router delays will be
prominent in the latency.


Regards, Dana.
 
Are you using IFTTT or MQTT as intermediary to generate the message ? Even this bellies the fact you are
in a packet based system that intrinsically has latency, and in your case the message has to be
processed and redirected. Basically you are using a shared resource system, eg. routers and switches,
and latency inherent.


Unless of course you are doing this entirely on a local network, and then the router delays will be
prominent in the latency.


Regards, Dana.
I am using an API named 'callmeBOT'
--- Updated ---

Hi,

Again: The ESP is not reponsible for when you receive the message.

So you have to check when the ESP SENDS the message.

Klaus
Thank you, sir.
 
I would contact them and ask them what they expect for latency thru
their servers.

1697967549827.png



Regards, Dana.
 

LaTeX Commands Quick-Menu:

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top