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

1. Pharos
Real-Time Operating System for Critical Systems
Introduction

2. Summary
◼ Real-time systems & motivation
◼ Pharos
❑ Time Protection
❑ Memory Protection
❑ Intra-partition communication/synchronization
❑ Inter-partition communication/synchronization
❑ CPUs supported
◼ Future plans

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Real time systems – summary
◼ Now we have a good understanding of real-
time systems
❑ Criticality
❑ Schedulability
❑ Types of threads (periodic/sporadic/aperiodic)

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. ARINC 653 example

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. 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. Pharos – time protection (1)
◼ Pharos supports natively the three types of
threads:
❑ Periodic
❑ Sporadic
❑ Aperiodic

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. 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. Pharos – time protection (4)
WCET monitoring
t
Start Job Deadline
monitoring
Deadline
w1 w2 w3
WCET < w1 + w2 + w3
WCET monitoring

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. CPUs supported
◼ Currently (version 1.3.0) Pharos supports:
❑ ARM 926EJ-S (in Qemu)
❑ ARM Cortex-R5 (in
http://www.ti.com/tool/LAUNCHXL2-570LC43)
❑ ARM Cortex-M4 (in http://www.ti.com/tool/EK-
TM4C129EXL)
◼ Next version (1.4.0) will (hopefully) be using
❑ ARM Cortex-A53

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. 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. More information
◼ Checkout the site:
❑ https://sourceforge.net/projects/rtospharos/
◼ 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
❑ rtos.pharos@outlook.com