Introduction Partitioning into multiple simpler subsystems - PDF document

Introduction  Partitioning into multiple simpler subsystems Supporting Component-Based  Lower complexity; Development with  Component reuse; Hierarchical Scheduling  Team-base development;  Outsourcing. Introduction Introduction  Partitioning into multiple simpler subsystems  This lesson: we will look at the problem of supporting component-based development from a real-time systems perspective  Lower complexity;  RTOS mechanisms/scheduling algorithms to support temporal  Component reuse; isolation among independently developed applications (software components);  Real-time analysis to ensure predictability in executing the  Team-base development; software components.   In general, supporting component-based development Outsourcing. requires a widespread view including software engineering, system modeling, programming models, component abstraction, etc… Integration Introduction Introduction Hierarchical Scheduling Framework Automotive Example: Engine Control + ABS Server Server Server Server 1 3 n 2 Integr ation without r eser vations Resource Reservation 1

Introduction Introduction Automotive Example: Engine Control + ABS Pr edic table inter fer enc es Integr ation with r eser vations Shared Resources HSF  1  Scheduling mechanisms needed to implement the server Hierarchical Scheduling Framework (HSF)  2b Ready queue  2 R server CPU  2a  3 scheduler  Resource reservation server able to guarantee hard  3 server real-time applications;  Resource sharing protocol supporting resources Tasks are usually not independent: they share shared among tasks running upon different resources! reservation servers. Examples: Data Structures, Peripheral Devices, Common Bounded ‐ Delay Reservation for Open Environment Memory Areas (BROE) Resource Reservation Problems with Reservations  Resource sharing may break isolation: HARD reservation It guarantees that the served application receives at most a budget Q every period P. normal blocking due extra blocking due to to reasource sharing budget exhaustion deadline miss wait  1 The budget is recharged at the Hard-CBS Server  2 server deadline 5 T s server server 4 8 12 16 20 24 S 2 q s 0 2 4 6 8 10 12 14 16 18 20 22 24 26 2

Problems with Reservations Overrun W/ Payback A possible solution: When the budget exhausts inside a critical  Resource sharing may break isolation: section, do nothing. Payback at the next budget replenishment. The major problem is that Isolation is broken! the resource is locked but no task is actually using it Note that the worst-case bandwidth consumption does not change deadline miss  1 wait  1 wait  2  2 T s T s server server S 2 S 2 The budget goes negative Budget payback BROE BROE Check and recharge BROE Design Goals If ( q s   k ) then enter, else recharge the budget at full value Overcome to the problem of budget depletion inside and proportionally postpone the server deadline. critical sections Note that off-line we must guarantee that Q s  max{  k }. • Avoiding budget overruns; checking point • Ensuring bandwidth isolation (i.e., each server  1 � must consume no more than � � � of the processor  2 bandwidth); • Guaranteeing a bounded-delay partition to the server served tasks. S 2 BROE: budget check BROE: budget check  Consider a task  1 accessing a resource � � having  Consider a task  1 accessing a resource � � having  k = 2  k = 2 q(t) = 2 � � � = 2 � � � q(t) = 1 � � � = 2 � � � checking point checking point  1  1 BROE avoids budget overruns server server by performing the budget check 3

BROE: budget check BROE  Consider a task  1 accessing a resource � � having BROE Design Goals  k = 2 Overcome to the problem of budget depletion inside critical sections • Avoiding budget overruns; q(t) = 1 � � � = 2 � � � checking point • Ensuring bandwidth isolation (i.e., each server � must consume no more than � � � of the processor  1 bandwidth); ? • Guaranteeing a bounded-delay partition to the ? served tasks. server BROE: bandwidth guarantee BROE: bandwidth guarantee  When the budget is not enough to complete the  The idea of proportional deadline comes from a critical section, BROE performs a full budget property of EDF scheduling with implicit deadlines; replenishment; � �  Suppose be schedulable with bandwidth (utilization) � � = 0.5  To not violate the server bandwidth, the budget replenishment must be reflected in a proportional � � � � � 1 � � � � � � � 1 deadline postponement ��� � � 8 12 BROE: bandwidth guarantee BROE: bandwidth guarantee  Consider a task  1 accessing a resource � � having  The idea of proportional deadline comes from a  k = 3. Task  1 executes on a BROE server property of EDF scheduling with implicit deadlines; configured with Q=5 and P=10 � �  Suppose be schedulable with bandwidth (utilization) � � = 0.5 � � � � � 1 � � � � � � � 1  2 ���  1 � � 20 server 12 4

BROE: bandwidth guarantee BROE: bandwidth guarantee  Consider a task  1 accessing a resource � � having  Consider a task  1 accessing a resource � � having  k = 3. Task  1 executes on a BROE server  k = 3. Task  1 executes on a BROE server configured with Q=5 and P=10 configured with Q=5 and P=10 According to EDF, � � � is descheduled Proportional deadline shift of  2  2 � � � � �.� � 6 units  1  1 Budget recharged of 3 server server units BROE: bandwidth guarantee BROE  Consider a task  1 accessing a resource � � having BROE Design Goals  k = 3. Task  1 executes on a BROE server Overcome to the problem of budget depletion inside critical sections configured with Q=5 and P=10 • Avoiding budget overruns; The server has executed 8 units in a window of 16 • Ensuring bandwidth isolation (i.e., each server  2 units. The bandwidth � � must consume no more than � � �� � 0.5 has not been � of the processor violated! bandwidth);  1 • Guaranteeing a bounded-delay partition to the 16 served tasks. server BROE: bounded-delay BROE: bounded-delay  To guarantee real-time workload executing upon a  The budget replenishment and the corresponding reservation server, the server must ensure a deadline postponement can easily result in a violation of the worst-case delay ∆� 2�� � �� , if bounded-delay service not properly handled � ∆� 2�� � �� � � 5

BROE: bounded-delay BROE: bounded-delay  Consider a BROE server with Q=4 and P=8  Consider a BROE server with Q=4 and P=8  � � accesses a resource having � � 2  � � accesses a resource having � � 2  1  1 server server BROE: bounded-delay BROE: bounded-delay  Consider a BROE server with Q=4 and P=8  How to solve this problem?  � � accesses a resource having � � 2  The idea is to avoid to let the server execute “ too much earlier ” with respect to its deadline, after a  The worst-case delay ∆� 2�� � �� is violated! budget replenishment This is only an example, in the worst ‐ case the delay can be potentially unbounded! 11 � 2 � � � � 8 11 � 2 � � � � 8  1  1 � � 8 � � 8 � � 8 � � 8 server server BROE: bounded-delay BROE: bounded-delay  To guarantee a bounded-delay of ∆� 2 � � � ,  How to solve this problem? BROE imposes an explicit server suspension  The idea is to avoid to let the server execute “ too much earlier ” with respect to its deadline, after a budget replenishment This execution must be delayed The slack is greater than (P-Q)  1  1 � � 8 � � 8 � � 8 � � 8 server server 6