Vehicle Tracking System Project - Discussion

Kernel
1

Hello everyone

I wanted to share a project idea I came up with for a vehicle tracking system based on GPS technology. Before I begin, I want to clarify that this is not a homework assignment; it’s just a use case I created to better understand the concept of task scheduling in such a system. I thought it would be great to discuss it here and get your valuable insights.

Project Overview:

  1. GPS Module: To fetch real-time location data (latitude, longitude, altitude, and timestamp) from the vehicle.
  2. Environmental Sensors: To collect temperature and humidity data inside and around the vehicle.
  3. Battery Monitoring: To monitor the vehicle’s battery status and ensure uninterrupted system operation.
  4. Central Server: To receive and process the collected data, provide real-time monitoring, and store historical information.
  5. Tamper Switch: To detect any unauthorized access or tampering attempts with the tracking system.

Task Lists

  1. Task 1 - Get GPS data:
  • Priority: 5 (Highest priority)
    *Task Execution Time: 5 ms
  • Periodic Time: 100 ms
  • This task is responsible for fetching GPS data at a every 100 ms
  1. Task 2 - Get temperature and humidity data:
  • Priority: 4
    *Task Execution Time: 2 ms
  • Periodic Time: 200 ms
  • This task is responsible for obtaining temperature and humidity data from sensors on the
    vehicle. It executes every 200 ms
  1. Task 3 - Get battery status:
  • Priority: 3
    *Task Execution Time: 3 ms
  • Periodic Time: 500 ms
    This task is responsible for fetching the battery status of the vehicle. It runs every 500 ms,
  1. Task 4 - Send data packets to the central server:
  • Priority: 2
    *Task Execution Time: 10 ms
  • Periodic Time: 500ms
    This task is responsible for sending the collected data packets to the central server for further processing. It can scheduled periodically every 500 ms.
  1. Task 5 - Tamper Switch:
  • Priority: 1 (Lowest priority)
    *Task Execution Time: 1 ms
  • Periodic Time: 50 ms
    This task is responsible for monitoring a tamper switch, probably to detect any unauthorized access or tampering with the tracking system. It runs every 50 ms

Now that we have an overview of the project and the tasks, I would greatly appreciate your feedback.

The task scheduling and prioritization play a crucial role in the system’s efficiency and real-time performance. I’m curious to know your thoughts on whether the assigned priorities and deadlines seem appropriate for this use case or if any adjustments are needed?

Looking forward to your valuable input and suggestions!

2

Is it possible to make Tamper Switch monitoring interrupt driven so that instead of waking up periodically unnecessarily, it only runs when an unauthorized access is detected. It can then be of the highest priority. I do not know the details how it works but is it possible that an unauthorized access that happens between two checks goes undetected?

1 Like
3

Thank you for your suggestion! Implementing an interrupt-driven Tamper Switch monitoring is a great idea. It’ll ensure higher priority for detecting unauthorized access.

I don’t know exactly what do you mean by two checks goes undetected?

4

The Tamper Switch task runs every 50ms. Lets say it checks for unauthorized access at t=0ms and finds everything okay. An unauthorized access happens at t=25ms. When this task runs next at t=50ms, will it be able to detect unauthorized access happened 25ms before?

5

Yes, the Tamper Switch task will be able to detect the unauthorized access that occurred at t=25ms when it runs at t=50ms. Even though the task is scheduled to run every 50ms, it will be able to detect any changes in the tamper switch state that occurred during the time interval between its executions.

This is achieved through the use of interrupts, which can trigger the task to run immediately when a specific event, such as unauthorized access, is detected.

6

Thank you for the insightful discussions and feedback. Your input has been incredibly valuable.

I’ve been pondering about a key aspect of the project - determining the expected task execution time for each task in a real-time operating system (RTOS) setup. While I’ve made assumptions about task execution times for now, I’m curious to learn more about the process of accurately measuring and determining these execution times, especially when working with specific hardware like the ESP32.

Could you please share your experiences and knowledge on how one typically goes about measuring and estimating task execution times in an RTOS project?

Any advice, tools, or techniques you recommend would be greatly appreciated.

Thank you once again for your assistance and expertise!"

7

You can use Run Time Stats feature of FreeRTOS - FreeRTOS Run Time Stats.

1 Like
8

Maybe that is what you are looking for: SystemView

1 Like
9

Thank you for the suggestion! I’ll definitely look into utilizing the Run Time Stats feature of FreeRTOS and the vTaskGetRunTimeStats() API to accurately measure task execution times. Your input is much appreciated!

10

From what I’ve learned, Inter-process communication (IPC) is the process by which one task can communicate with another task to exchange their data. For instance, in vehicle tracking system, Task 1 communicates with Task 4 to share GPS data"

However, I want to ensure I’ve got the concept right. Could someone kindly clarify and confirm if my understanding of IPC is accurate? Your guidance is much appreciated!"

11

Yes, your understanding is right.

12

I believe task synchronization is essential for our vehicle tracking system to ensure that only one task share resource at given time to avoide data corruption. I’m deliberating whether a mutex or a semaphore is the right choice.

Could you provide advice on choosing between mutex and semaphore for our specific needs? Your insights are valuable!"

13

Mutexes are used to guard shared resources while semaphores are used to synchronize tasks. The following are some good resources:

14

Thank you for the valuable insights. I’d like to request some specific guidance on choosing between mutex and semaphore. Both mutexes and semaphores seem capable of protecting shared data, but I’m looking to determine which one would be the better fit for our project’s requirements

Your practical experience and guidance would greatly assist in making an informed choice. Thank you in advance for your contributions.

15

This is incorrect - mutex should be used for protecting shard data. A typical code sequence looks like -

Acquire Mutex.
Access Resource.
Release Mutex.

Semaphores are used for task synchronization. I strongly recommend reading the resources I shared.

16

@aggarg, Semaphores CAN be used for mutual exclusion, but suffer some limitations compared to Mutexes. The big advantage of a Mutex is that it supports the concept of “Priority Inheritance” which reduces the problem of "Priority Inversion. Semaphores have the advantage (which can sometimes turn into a limitation) of a more flexible usage pattern.

Priority Inversion occurs when a Low Priority task has a Mutex, that is wanted by a High Priority Task, but while the High Prioity task is waiting, a Middle Prioirty task can run, preventing the Low Priority task from running, thus blocking the High Priority task.

To prevent this, If a task is holding a Mutex, and a Higher Priority task wants it, the Low Priority task is temporarily boosted in Priority to match the Higher Priority task, until it releases the Mutex, thus the Middle Priority Task can’t block it from completing.

Semaphores, because they don’t support the same “Ownership” semantics of a Mutex, can’t implement this method.

2 Likes
17

@richard-damon That is what I wanted to convey. Thank you for correcting and elaborating.

18

If I were to handle this project, I would make “detect any unauthorized access” as the highest priority. Most devices don’t have such feature. Since this feature is involved here, this thing got to pretty serious device.

(Yes, “interrupt driven” would be nice)

And in my opinion, “Periodic Time: 500 ms” for “Get battery status”, that’s not necessary. As the voltage of battery don’t change too fast. Just an opinion.

You said “vehicle tracking system”, but did not mention what type of vehicle? If it’s moving slowly(normal), maybe you can make the whole thing without RTOS. And the cost might be reduced.

Kind Regards,

19

I appreciate your point. To clarify, I’ve assumed this hypothetical project for understanding RTOS concepts. While a slower-moving vehicle might allow for a simpler non-RTOS solution, my focus here is on comprehending RTOS principles. If the system were intended for high-speed or critical applications, an RTOS could become essential. The choice depends on balancing real-time needs

20

From the timing estimates you give, your system is about 10% occupied, which gives a lot of headroom, especially since you don’t seem to have any specific timing requirements. I’d classify it as “soft real-time”.

Aside from the tamper detection issue already discussed, I’d have thought that a top priority task could run every 100 ms; every time it gets a GPS measurement, then every second time it gets temperature and humidity, and every 5th time it gets the battery status.

I’m guessing your central server is remote? such handling is likely to be less predictable (e.g. recovering from comms glitches), so I’d run it at lower priority and make sure that the data packets from the sensors are buffered and timestamped, so that they can be properly ordered at the receiving end.