Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Description and Real-Time Systems and Motivation for Pharos RTOS.
Updated to Pharos 1.4.0

Published in: Software
  • Login to see the comments

  • Be the first to like this


  1. 1. Pharos Real-Time Operating System for Critical Systems Introduction
  2. 2. Summary ◼ Real-time systems & motivation ◼ Pharos ❑ Time Protection ❑ Memory Protection ❑ Intra-partition communication/synchronization ❑ Inter-partition communication/synchronization ❑ CPUs supported ◼ Future plans
  3. 3. Real-time systems criticality ◼ Real-time systems can be classified according to their criticality. Some examples: ❑ Highly critical ◼ Attitude control on an airplane ❑ Medium critical ◼ Emergency light ❑ Low critical ◼ Infotainment on an automobile ❑ Non critical ◼ Web-site
  4. 4. Real-time systems criticality ◼ The exact level of criticality is defined according to the standard followed. ◼ For example: ❑ Aviation: DO178C classifies from DAL-A (highest criticality) to DAL-E (lowest criticality)
  5. 5. Critical and non-critical systems ◼ Both critical and non-critical can sometimes co-exist on the same system ◼ Usually placed on different CPUs/Boards ◼ Highly critical systems are typically well- behaved and “simple” (~10K LOCs) ◼ Non-critical systems are typically a “mess” and complex (>1M LOCs) ◼ They sometimes share the same resources
  6. 6. RTOS vs OS ◼ Low critical systems use extensively an Operating System (e.g. Linux, Windows) ◼ Highly critical systems many times also use a a Real-Time Operating System (RTOS) which has some special conditions
  7. 7. RTOS Main features ◼ There are many different definitions of what a RTOS is supposed to do ◼ “Main” features are: ❑ Fixed-priority preemptive scheduler ◼ CPU is running always the highest priority ready thread ❑ Fast critical sections ◼ interrupts disabled for “short” amount of time) ❑ Deterministic ◼ each call takes a known maximum amount of time (e.g. semaphore obtain)
  8. 8. RTOS Other features ◼ “Secondary” features ❑ Health monitoring ◼ Check if deadlines were missed and allow the application to deal with them ❑ “Good” API ◼ Semaphores with priority inheritance/ceiling algorithms ◼ Message queues ◼ Events ◼ Interrupt processing ❑ Support a wide variety of CPUs
  9. 9. RTOS Partitioning ◼ Even other features are useful, such as dividing the application into partitions ◼ Partitioning features ❑ Memory protection ◼ Don’t allow a part of the application (e.g. driver for CAN) mess with the memory area of another part of the application (e.g. TCP/IP stack) or the RTOS kernel itself ❑ Time protection ◼ Each partition or thread could have an amount of time to execute in, no matter what the rest of the systems does ❑ Inter-partition communication/synchronization ◼ Allow a partitions to communicate with each other ◼ If not bounded, an erroneous partition could overload another partition with unwanted communication
  10. 10. RTOS Scheduling ◼ Objective ❑ Give equation to make sure all deadlines are met Examples: ◼ RMS (CPU% < 70%) ◼ EDF (CPU% < 100%) ◼ Response time analysis (Ra < Da) ◼ Equation depends (heavily) on the scheduler used ◼ Examples ❑ Rate monotonic scheduler ❑ Earliest Deadline First ❑ Fixed priority ❑ Preemptive vs non-preemptive
  11. 11. Threads ◼ Threads are typically classified as: ❑ Periodic ◼ Period (Ti) ◼ Deadline (Di) ◼ Job worst case execution time (ci) ◼ First release instant (ri) ❑ Sporadic ◼ Minimum Inter-arrival Time (MITi) ◼ Deadline (Di) ◼ Job worst case execution time (ci) ❑ Aperiodic
  12. 12. Periodic thread t Deadine Deadline Period Deadline Start Job Deadine Thread executing in several instances of time (depending on when other threads are executing) Second time the thread is executing. This time the thread is faster (maybe some calculations are done faster) t
  13. 13. Sporadic thread t 1st job start 1st Deadline 2nd job Start MIT Activate sporadic thread (before MIT has elapsed) MIT 3rd job Start MIT Activations of the sporadic thread (e.g. Interrupt occurred and relased a semaphore) 2nd Deadline MIT from 1st job already elapsed, so the thread is activated right away (and the deadline as well) Have to wait for the MIT from the 2nd job to elapse before activating the thread
  14. 14. Aperiodic thread ◼ Aperiodic threads can execute whatever they like, there is no definition for maximum execution time, period, whatever ◼ For this reason they are normally not considered in real-time systems
  15. 15. Thread Priority ◼ Fixed ❑ Priority does not change with time (with perhaps some exceptions, like the semaphore ceiling) ❑ Easier to implement ❑ “Easy” for programmer to define the priority ◼ Dynamic ❑ priority changes with time ❑ Harder to implement ❑ How to define the priority? Based on deadline, laxity, etc ◼ If deadline, not all threads can have a deadline (for example, aperiodic threads by definition don’t have a deadline)
  16. 16. Preemptiveness ◼ Preemptive ❑ If a higher priority thread becomes ready, the RTOS switches the CPU to that thread => the highest priority ready thread is always executing ❑ Mutual exclusion must be ensured by the programmer ◼ Non-preemptive ❑ The thread must explicitly relinquish the CPU to change to another thread => the highest priority read thread may not be always executing ❑ Mutual exclusion does not need to be programmed using semaphores
  17. 17. Rate Monotonic Scheduler – RMS ◼ One of many possible algorithms for fixed-priority ◼ The RMS only defines the priority of the threads based on their period: the lower the period, the higher the priority ❑ Therefore the original version of RMS only considers periodic threads ❑ Extensions were made for sporadic threads, where the period is replaced by the MIT ◼ In an application with only periodic threads, is the optimum scheduler ❑ in the sense that if it there is any algorithm to define the priorities with all threads being schedulable, then the RMS will also give a schedulable set of threads ◼ Simplified schedulability equation (with preemption) ❑ %CPU < 69%
  18. 18. Fixed priority schedulers ◼ Repeat: the RMS only defines the priority of the threads based on their period ◼ You can define the priority of yours threads as you wish, but the RMS schedulability equation will NOT be applicable ◼ Instead you could use the Response-Time Analysis (RTA) schedulability equations
  19. 19. Response-Time Analysis – RTA ◼ Calculate the Response Time (Ri) of each thread and see if it is lower than the Deadline (Di): ◼ Use iterations to solve the equation:
  20. 20. Earliest Deadline First – EDF ◼ All threads need to have a deadline ◼ The thread with the nearest deadline will be using the CPU ◼ How to define a deadline for threads that typical don’t have one? Examples: video, TCP/IP comm ◼ Schedulability equation is easy (with preemption): ❑ %CPU < 100%
  21. 21. RTOS Scheduler – EDF vs RMS ◼ Myth: EDF is “better” than Rate Monotonic (RMS) ❑ The origin for this myth is that the most used schedulability equation for the EDF and RMS ❑ EDF: CPU% < 100% ❑ RMS: CPU% < 70% ❑ But there are other schedulability analysis that can (or not, depending on the system) allow the CPU% to increase to 100% using the RMS
  22. 22. Real time systems – summary ◼ Now we have a good understanding of real- time systems ❑ Criticality ❑ Schedulability ❑ Types of threads (periodic/sporadic/aperiodic)
  23. 23. Real-time systems mixing criticality – ARINC 653 ◼ In some systems it is possible to mix critical and non-critical systems in the same CPU. ◼ Example: ❑ ARINC 653 ◼ In ARINC 653, each partition has a pre- defined time slot and its threads can only execute on that slot
  24. 24. ARINC 653 example
  25. 25. ARINC 653 questions ◼ Some questions arise with this fixed partition scheduling: ❑ Q: How to respond to an external event quickly? ❑ A: Polling ❑ Q: Doesn’t that waste a lot of time? ❑ A: Yes, it does ❑ Q: What happens if a partition does not have anything to do, that is, it is idle? ❑ A: Its time slot is wasted
  26. 26. Pharos ◼ Pharos is a RTOS that tries to solve these questions while maintaining the very good mixed-criticality feature of ARINC 653 ◼ But how to ensure time protection and still give a good responsive system (and not waste time doing idle tasks)?
  27. 27. Pharos – time protection (1) ◼ Pharos supports natively the three types of threads: ❑ Periodic ❑ Sporadic ❑ Aperiodic
  28. 28. Pharos – time protection (2) ◼ Pharos allows the application to configure periodic threads with: ❑ Period ❑ Worst case execution time (WCET) ❑ Release instant ❑ Deadline ◼ If a periodic thread attempts to use more execution time than the configured WCET, Pharos will stop it and raise an error to the application ◼ This ensures that periodic threads CANNOT execute longer than they are supposed to
  29. 29. Pharos – time protection (3) ◼ Pharos allows the application to configure sporadic threads with: ❑ MIT ❑ Worst case execution time (WCET) ❑ Deadline ◼ If a sporadic thread attempts to use more execution time than the configured WCET, Pharos will stop it and raise an error to the application ◼ This ensures that sporadic threads CANNOT execute longer than they are supposed to
  30. 30. Pharos – time protection (4) WCET monitoring t Start Job Deadline monitoring Deadline w1 w2 w3 WCET < w1 + w2 + w3 WCET monitoring
  31. 31. Pharos – time protection (5) ◼ By ensuring that neither periodic nor sporadic threads can execute for more time than they are supposed to, the architect has the means to mix different level criticality systems ◼ The architect still needs to make sure that the system is schedulable, in particular to the higher criticality partitions (would also need to do this in ARINC case as well)
  32. 32. Pharos – time protection (6) ◼ An application could have: ❑ High priority non-critical periodic/sporadic threads ❑ And in the same CPU have ❑ Low priority highly-critical periodic/sporadic/aperiodic threads ❑ And still guarantee that no matter what, the highly critical threads will ALWAYS have time to execute ❑ Of course, supposing that the period/MIT and WCET of the non-critical threads obeys some pre- calculated criteria
  33. 33. Pharos – memory protection (1) ◼ Pharos supports the concept of partitions where each partition is composed by a set of: ❑ Threads ❑ Semaphores ❑ Message queues ❑ Etc ◼ Each partition has its own memory area, defined at compilation time ◼ Pharos ensures through the CPU MMU/MPU that a partition cannot access memory areas where it is not configured to do so
  34. 34. Pharos – memory protection (2) ◼ Each partition can: ❑ Access the code area to execute the source code ❑ Access its own partition memory area ❑ Access the shared data area ❑ Optionally access other memory areas (you can configure the application which memory areas Code Partition 1 data Partition 2 data Partition 3 data Shared data area Pharos Kernel data initialized data (data section) zero-initialized data (bss section) non-initialized data (new uss section) 0x00000000 Flash }RAM I/O }SPI area I2C area Blueetooth area CAN area Ethernet area } Each partition has access to its own data area and optionally (configurable) to I/O memory areas.. .
  35. 35. Pharos – memory protection (3) ◼ How to do the source code? PARTITION_0_SECTION uint32_t variableInPartition0Data = 4; PARTITION_0_SECTION_USS uint32_t variableInPartition0Uss; PARTITION_0_SECTION_BSS uint32_t variableInPartition0Bss; PARTITION_1_SECTION uint32_t variableInPartition1Data = 3; SHARED_SECTION uint32_t variableInSharedSectionData = 432;
  36. 36. Intra-partition API ◼ Within each partition, threads use: ❑ Semaphores ◼ Mutex ◼ Ceiling semaphore ◼ Counting semaphore ❑ Light-weight Message Queues ◼ A extremely fast message queue that does a zero-copy transfer within the same partition ❑ Events ◼ 32 bit events sent to a thread to unblock it ❑ Timers ◼ Software timers that execute a handler at specified instants in time ❑ Critical sections ◼ Specified functions that are executed in user space with interrupts disabled (useful for drivers) ❑ Clock ❑ Health monitoring ◼ Discover when a deadline was missed, an execution time overrun, an invalid memory access was performed, etc ❑ Interrupt management ◼ Configure interrupt handlers, interrupt priority, wake-up CPU, etc ❑ I/O memory area ◼ Configure which memory areas the partition has access to
  37. 37. Inter-partition communication/synchronization ◼ Partition can communicate with each other trough: ❑ Heavy weight message queues ◼ A 2-copy message queue to transfer information from one partition to another ❑ Resource ◼ A pre-defined function executes on the partition owner of the resource protected by a ceiling semaphore ensuring mutual exclusion ❑ Channel queue ◼ A extremely fast message queue (zero-copy) to transfer information from one partition to another using the MMU/MPU to give/remove permissions from one partition to another ❑ Inter-partition calls ◼ You can call directly a function on another partition with a different stack, on the memory context of the called partition but in the time context of the calling thread ❑ I/O memory area / shared memory ◼ You can use a configurable memory area to shared memory between partitions
  38. 38. Inter-partition protection (1) ◼ Imagine a low critical partition starts sending messages to a high critical partition message queue ❑ This could cause the high critical partition to overload and stop performing its task ◼ Pharos must protect this from occurring
  39. 39. Inter-partition protection (2) ◼ Pharos protects each inter-partition communication device (e.g. Message queue, channel, IPC, etc) by allowing the application to define a “filter” function for it ◼ Before accessing the communication device, Pharos will invoke the filter which will allow (or not) the communication to take place ◼ The filter function is executed with a separate stack, in the memory context of the called partition but still in the time context of the caller thread
  40. 40. Precautions ◼ Some precautions are required when implementing your application: ❑ Aperiodic threads ◼ Pharos cannot protect the execution time of these threads. You have to make sure they don’t interfere in an unforeseen way with the rest of the system (perhaps lower the priority of these threads) ❑ Interrupt handlers & Timer handlers ◼ They are executed in the context of an interrupt and hence in “kernel” mode. You have to define statically the handlers to be executed ❑ Critical sections ◼ They are executed with interrupts disabled, so make them as fast as possible to not damage the schedulability too much
  41. 41. CPUs supported ◼ Currently (version 1.3.0) Pharos supports: ❑ ARM 926EJ-S (in Qemu) ❑ ARM Cortex-R5 (in ❑ ARM Cortex-M4 (in TM4C129EXL) ◼ Next version (1.4.0) will (hopefully) be using ❑ ARM Cortex-A53
  42. 42. Future plans ◼ We don’t have a pre-defined rigid roadmap ◼ We have some ideas where we want to take Pharos to, but no guarantees we can take it there ◼ At this moment, Pharos is maintained solely as a hobby by a couple of enthusiastic software developers ◼ If you have inputs/ideas/whatever we would love to know/discuss them with you
  43. 43. What else? ◼ Check the User Manual for a complete description of the features offered by Pharos ◼ Many things were not discussed here. Examples: ❑ How to configure interrupts? (spoiler: each CPU has its own configuration method to maximize the options available on the CPU) ❑ How to configure partition memory areas? (spoiler: based on the MMU/MPU or with direct access) ❑ How to create drivers? (spoiler: drivers are normal partitions where you define the I/O memory areas needed, critical sections and interrupt handlers)
  44. 44. More information ◼ Checkout the site: ❑ ◼ It has a: ❑ User Manual (check in files) ❑ Wiki (some initial steps when learning Pharos) ❑ Discussion (make your questions here) ❑ Ticket system ❑ SVN source code ◼ Or you can address us directly through ❑