3) Implement the response time analysis, and overall scheduleability.
3) Implement the response time analysis, and overall schedulability test.
4) Generate report on the alaysis results, this could be as a generated html (or xml and use same xml redering engine) or however you feel like results are best reported and visualized, as discussed in class.
4) Generate report on the alaysis results, this could be as a generated html (or xml and use same xml rendering engine) or however you feel like results are best reported and visualized, as discussed in class.
5) Integrate your analysis to the “trustit” framework (KLEE + automated test bed). The complete testbed will be provided later.
...
...
@@ -12,13 +12,13 @@
Start by reading 1, 2 and 3:
1) [A Stack-Based Rersource Allocation Policy for Realtime Processes](https://www.math.unipd.it/~tullio/RTS/2009/Baker-1991.pdf), which refers to
1) [A Stack-Based Resource Allocation Policy for Realtime Processes](https://www.math.unipd.it/~tullio/RTS/2009/Baker-1991.pdf), which refers to
2) [Stack-Based Scheduling of Realtime Processes](https://link.springer.com/content/pdf/10.1007/BF00365393.pdf), journal publication based on technical report [3] of the 1991 paper. The underlying model is the same in both papers.
3) [Rate Monotonic Analysis](http://www.di.unito.it/~bini/publications/2003BinButBut.pdf) , especially equation 3 is of interest to us. (It should be familiar for the real-time systems course you have taken previously.)
## Prestentation
## Presentation
Make a git repo of your solution(s) with documentation (README.md) sufficient to reproduce your results.
...
...
@@ -36,13 +36,13 @@ A task `t` is defined by:
A resource `r` is defined by:
-`π(r)` the highest priority of any task accessing `r`
-`π(r)` the resource ceiling, computed as the highest priority of any task accessing `r`. SRP allows for dynamic priorities, in our case we have static priorities only.
For SRP based analysis we assume task to perform a finite sequence of operations (run-to-end or run-to-completition sematintics). During execution, a task can claim a resources `Rj` in nested fashion, sequentially re-claim resources is allowed but NOT re-claiming an already held resource.
For SRP based analysis we assume a task to perform/execute a finite sequence of operations/instructions (aka. run-to-end or run-to-completion semantics). During execution, a task can claim resources `Rj`... in nested fashion. Sequential re-claim of resources is allowed but NOT re-claiming an already held resource (in a nested fashion, since that would violate the Rust memory aliasing rule).
E.g., a possible trace for a task can look like:
`[t:...[r1:...[r2:...]...]...[r2:...]...]`, where `[r:...]` denotes a critical section of task `t` holding the resource `r`. In this case the task starts, and at some point claims `r1` and inside the critical section claims `r2` (nested claim), at some point it exits `r2`, exits `r1` and continues exectuting where it executes a critical section on `r2`, and then finally executes until completion.
`[t:...[r1:...[r2:...]...]...[r2:...]...]`, where `[r:...]` denotes a critical section of task `t` holding the resource `r`. In this case the task starts, and at some point claims `r1` and inside the critical section claims `r2` (nested claim), at some point it exits `r2`, exits `r1` and continues executing where it executes a critical section on `r2`, and then finally executes until completion.
## Grade 3
...
...
@@ -50,13 +50,13 @@ Analysis:
### 1. Total CPU utilization
WCET for tasks and critical sections
Worst Case Execution Time (WCET) for tasks and critical sections
In general determining WCET is a rather tricky, in our case we adopt a measurement based technique, that spans all possible paths of the task. Tests triggering the execution paths are automatically generated by symbolic execution. To correctly take concurrency into account resource state is treated symbolically. Thus, for a critical section, the resource is given a fresh (new) symbolic value for each critical section. Inside the critical section we are ensured exclusive access (and thus the value can be constrained). The resource model can be further extended by contracts (as shown by the `assume_assert.rs` example).
In general determining WCET is rather tricky. In our case we adopt a measurement based technique, that spans all feasible paths for the task. Tests triggering the execution paths are automatically generated by symbolic execution. To correctly take concurrency into account resource state is treated symbolically. Thus, for a critical section, the resource is given a fresh (new) symbolic value for each critical section. Inside the critical section we are ensured exclusive access (and thus the value can be further constrained inside of the critical section). The resource model can be further extended by contracts (as shown by the `assume_assert.rs` example).
We model hardware (peripherals) as shared resources (shared by the environment), with*atomic* read/write/modify. Rationale, we must assume that the state of the hardware resources may be changed at any time, thus only *atomic* access can be allowed.
We model hardware (peripherals) as shared resources (shared by the environment) as being*atomic*(with read/write/modify operations only). Rationale, we must assume that the state of the hardware resources may be changed at any time, thus only *atomic* access can be allowed.
For now, we just assume we have the WCETs information, in terms of `start` and `end` time-stamps (`u32`) for each section `[_: ... ]`. We represent that by the `Task` and `Trace` data structures in `common.rs`.
For now, we just assume we have complete WCETs information, in terms of `start` and `end` time-stamps (`u32`) for each section `[_: ... ]`. We represent that by the `Task` and `Trace` data structures in `common.rs`.
### Total CPU request (or total load factor)
...
...
@@ -79,7 +79,7 @@ In general the response time is computed as.
-`B(t)` is the blocking time for task `t`, and
-`I(t)` is the interference (preemptions) to task `t`
For a task set to be scheduleable under SRP we have two requirements:
For a task set to be schedulable under SRP we have two requirements:
-`Ltot` < 1
-`R(t)`<`D(t)`,foralltasks.(`R(t)`>`D(t)` implies a deadline miss.)
...
...
@@ -94,10 +94,14 @@ Implement a function that takes a `Task` and returns the corresponding blocking
A task is exposed to interference (preemptions) by higher priority tasks. Intuitively, during the execution of a task `t` (`Bp(t)`) each higher priority task `h` (`P(h)`>`P(t)`) may preempt us (`Bp(t)`/`A(h)` rounded upwards) times.
We can make the over approximation `Bp(i)` = `D(i)` (assuming the worst allowed *busy-period*).
We can over approximate the *busy period* `Bp(i)` = `D(i)` (assuming the worst allowed *busy-period*).
As a technical detail. For the scheduling of tasks of the same priority, the original work on SRP adopted a FIFO model (first arrived, first served). Under Rust RTFM, tasks are bound to hardware interrupts. Thus we can exploit the underlying hardware to do the actual scheduling for us (with zero-overhead). However the interrupt hardware, schedules interrupts of the same priority by the index in the vector table. For our case here we can make a safe over approximation by considering preemptions from tasks with SAME or higher priority (`P(h)` >= `P(t)`).
Implement a function that takes a `Task` and returns the corresponding preemption time.
...
...
@@ -110,21 +114,21 @@ Finally, make a function that iterates over the task set and returns a vector wi
The *busy-period* is in `7.22` computed by a recurrence equation.
Implement the requrrence equation starting from the base case `C(t)`. The requrrence might diverge in case the `Bp(t) > A(t)`, this is a pathological case, where the task becomes non-schedulable, in that case terminate the requrrence. You might want to indicate that a non feasible response time have been reached by using the `Result<u32,())>` type or some other means e.g., (`Option<u32>`).
Implement the recurrence relation (equation) starting from the base case `C(t) + B(t)`. The recurrence might diverge in case the `Bp(t) > D(t)`, this is a pathological case, where the task becomes non-schedulable, in that case terminate the recurrence (with an error). You might want to indicate that a non feasible response time have been reached by using the `Result<u32,())>` type or some other means e.g., (`Option<u32>`).
You can let your `preemption` function take a parameter indicating if the exact solution or approximation should be used.
## Grade 4
Here you can go wild, and use your creativity to present task set and results of analysis in the best informative manner. We will discuss some possible visualisations during class.
Here you can go wild, and use your creativity to present task set and results of analysis in the best informative manner. We will discuss some possible visualizations during class.
## Grade 5
If you aim for the highest grade, let me know and I will hook you up with the current state of the development. The goal is to derive the task set characterisation by means of the automated test-bed, (test case generation + test runner based on the `probe.rs` library.) All the primitives are there, and re-implementing (back-porting) previous work based on `RTFM3` is mostly an engineering effort.
If you aim for the highest grade, let me know and I will hook you up with the current state of the development. The goal is to derive the task set characterization by means of the automated test-bed, (test case generation + test runner based on the `probe.rs` library.) All the primitives are there, and re-implementing (back-porting) previous work based on `RTFM3` is mostly an engineering effort.
---
## Resurces
## Resources
`common.rs` gives the basic data structures, and some helper functions.
...
...
@@ -132,9 +136,9 @@ If you aim for the highest grade, let me know and I will hook you up with the cu
## Tips
For workning with Rust, the standard library documentation is excellent, and easy to search (just press S). For most cases, you will find examples on inteded use, and cross referencing is just a click away.
When working with Rust, the standard library documentation [std](https://doc.rust-lang.org/std/) is excellent and easy to search (just press S). For most cases, you will find examples on intended use and cross referencing to related data types is just a click away.
Use the `generate` example to get started. Initially you may simlify it further, reduce the number of tasks/and or resources. Make sure you understand the helper functions given in `common.rs`, (your code will likely look quite similar). You might want to add further `common` types and helper functions to streamline your development, along the way.
Use the `generate` example to get started. Initially you may simplify it further by reducing the number of tasks/and or resources. Make sure you understand the helper functions given in `common.rs`, (your code will likely look quite similar). You might want to add further `common` types and helper functions to streamline your development, along the way.
Generate your own task sets to make sure your code works in the general case not only for the `Tasks` provided. Heads up, I will expose your code to some other more complex task sets.
...
...
@@ -144,14 +148,14 @@ Generate your own task sets to make sure your code works in the general case not
In this part of the course, we have covered.
- Software robustness. We have adopted Rust and Symbolic Execution to achieve guarenteed memory safety and defined behavior (panic free execution). With this at hand, we have a strong (and theoretically underpinned) foundation for improved robustness and reliablity proven at compile time.
- Software robustness. We have adopted Rust and Symbolic Execution to achieve guaranteed memory safety and defined behavior (panic free execution). With this at hand, we have a strong (and theoretically underpinned) foundation for improved robustness and reliability proven at compile time.
- Real-Time Scheduling and Analysis. SRP provides an execution model and resource menagement policy with outstanding properties of race-and deadlock free execution, single blockning and stack sharing. Our Rust RTFM framework provides a correct by construction implementation of SRP, exploiting zero-cost (software) abstractions. Using Rust RTFM resource management and scheduling, is done by directly by the hardware, which allows for efficiency (zero OH) and predictability.
- Real-Time Scheduling and Analysis. SRP provides an execution model and resource management policy with outstanding properties of race-and deadlock free execution, single blocking and stack sharing. Our Rust RTFM framework provides a correct by construction implementation of SRP, exploiting zero-cost (software) abstractions. Using Rust RTFM resource management and scheduling, is done by directly by the hardware, which allows for efficiency (zero OH) and predictability.
The SRP model is amenable to static analysis, which you have now internalised through an actual implementation of the theoretical foundations. We have also covered methods for Worst Case Execution Time analysis by cycle accurate measurements, which in combination with Symbolic Exectution for testcase generation allows for high degree of automation.
The SRP model is amenable to static analysis, which you have now internalized through an actual implementation of the theoretical foundations. We have also covered methods for Worst Case Execution Time (WCET) analysis by cycle accurate measurements, which in combination with Symbolic Execution for test-case generation allows for high degree of automation.
- Energy Consumption is roughly proportional to the supply voltage (due to static leakage), and exponential to the frequency (due to dynamic/switching activity). In the case of embedded systems, low-power modes allows part of the system to be powered down while retaining sufficient functionality to wake on external (and/or internal) events. In sleep mode, both static and dynamic power dissipation is minimized typically to the order of uAmp (in comparison to mAmp in run mode).
- Energy Consumption is roughly proportional to the supply voltage (static leakage/dissipation), and exponential to the frequency (dynamic/switching activity dissipation). In the case of embedded systems, low-power modes allow parts of the system to be powered down while retaining sufficient functionality to wake on external (and/or internal) events. In sleep mode, both static and dynamic power dissipation is minimized typically to the order of uAmp (in comparison to mAmp in run mode).
Rust RTFM adopts an event driven approach allowing the system to automatically sleep in case no further tasks are eligable for scheduling. Morover, leveraging on the zero-cost abstractions in Rust and the guarentees provided by the analysis framework, we do not need to sacrifice correnctness/robustness and reliability in order to obtain highly efficient executables.
Rust RTFM adopts an event driven approach allowing the system to automatically sleep in case no further tasks are eligible for scheduling. Moreover, leveraging on the zero-cost abstractions in Rust and the guarantees provided by the analysis framework, we do not need to sacrifice correctness/robustness and reliability in order to obtain highly efficient executables.
Robust and Energy Efficient Real-Time Systems for real, This is the Way!
