1 / 99

A family of resource-bound process algebras for modeling and analysis of embedded systems

A family of resource-bound process algebras for modeling and analysis of embedded systems. Insup Lee 1 , Oleg Sokolsky 1 , Anna Philippou 2 . 1 SDRL (Systems Design Research Lab) RTG (Real-Time Systems Group) Department of Computer and Information Science University of Pennsylvania

lixue
Télécharger la présentation

A family of resource-bound process algebras for modeling and analysis of embedded systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A family of resource-bound process algebras for modeling and analysis of embedded systems Insup Lee1, Oleg Sokolsky1,Anna Philippou2 • 1SDRL (Systems Design Research Lab) • RTG (Real-Time Systems Group) • Department of Computer and Information Science • University of Pennsylvania • Philadelphia, PA 2Department of Computer Science University of Cyprus Nicosia, CY ETAPS 2002

  2. Outline • Embedded systems • Resource-bound computation • Resource-bound process algebras • ACSR (Algebra of communicating shared resources) • PACSR (Probabilistic ACSR) • P2ACSR (Probabilistic ACSR with power consumption) • ACSR-VP (ACSR with Value-Passing) • Conclusions ETAPS 2002

  3. Embedded Systems • Difficulties • Increasing complexity • Decentralized • Safety critical • End-to-end timing constraints • Resource constrained • Non-functional: power, size, etc. • Development of reliable and robust embedded software ETAPS 2002

  4. Properties of embedded systems • Adherence to safety-critical properties • Meeting timing constraints • Satisfaction of resource constraints • Confinement of resource accesses • Supporting fault tolerance • Domain specific requirements • Mobility • Software configuration ETAPS 2002

  5. Real-time Behaviors • Correctness and reliability of real-time systems depends on • Functional correctness • Temporal correctness • Factors that affect temporal behavior are • Synchronization and communication • Resource limitations and availability/failures • Scheduling algorithms • End-to-end temporal constraints • An integrated framework to bridge the gap between concurrency theory and real-time scheduling ETAPS 2002

  6. Scheduling Problems • Priority Assignment Problem • Schedulability Analysis Problem • Soft timing/performance analysis (Probabilistic Performance Analysis) • End-to-end Design Problem • Parametric Analysis • End-to-end constraints, intermediate timing constraints • Execution Synchronization Problem • Start-time Assignment Problem with Inter-job Temporal Constraints • Fault tolerance: dealing with failures, overloads ETAPS 2002

  7. Scheduling Factors • Static priority vs dynamic priority • Cyclic executive, RM (Rate Monotonic), EDF (Earliest Deadline First) • Priority inversion problem • Independent tasks vs. dependent tasks • Single processor vs. multiple processors • Communication delays ETAPS 2002

  8. Example: Simple Scheduling Problem CPU1 CPU2 CPU3 • ( period, [ e-, e+ ] ), where e- and e+ are the lower and upper bound of execution time, respectively. • Goal is to find the priority of each job so that jobs are schedulable • Considering only worst case leads to scheduling anomaly J2,2 J1,1 J1,2 (12, [1,2]) (4, [1,2]) (4, [1,2]) J3,1 J2,1 (4, [2,3]) (12, [1,3]) ETAPS 2002

  9. J1,1 J2,1 J1,1 J2,1 J1,1 CPU2 4 8 12 J3,1 J3,1 J2,2 J3,1 CPU1 4 8 12 Example (2) CPU2 CPU3 CPU1 J2,2 J1,1 J1,2 (12, [1,2]) (4, [1,2]) J3,1 J2,1 (4, [1,2]) (4, [2,3]) (12, [1,3]) LetJ1,1 J2,1andJ2,2  J3,1 Consider worst case execution time for all jobs, i.e., Execution time E1,1= 2,E2,1= 3, E2,2 = 2,E3,1 = 3 ETAPS 2002

  10. CPU1 CPU2 CPU3 J2,2 J1,1 J1,2 (12, [1,2]) (4, [1,2]) J3,1 J2,1 (4, [1,2]) (4, [2,3]) (12, [1,3]) J1,1 J2,1 J1,1 J1,1 CPU2 4 8 12 J3,1 missed its deadline J3,1 J2,2 CPU1 4 8 12 Example (3) With same priorities, J1,1 J2,1andJ2,2  J3,1 Let execution time E1,1 = 1,E2,1 = 1,E2,2 = 2,E3,1 = 3 So with the priority assignment of J1,1 J2,1andJ2,2  J3,1, jobs cannot be scheduled and scheduling problems are in general NP-hard ETAPS 2002

  11. End-to-end Design Problem • Given a task set with end-to-end constraints on inputs and outputs • Freshness from input X to output Y (F(Y|X)) constraints: bound time from input X to output Y • Correlation between input X1 and X2 (C(Y|X1,X2)) constraints: max time-skew between inputs to output • Separation between output Y (u(Y) and l(Y)) constraints: separation between consecutive values on a single output Y • Derive scheduling for every task • Periods, offsets, deadlines • priorities • Meet the end-to-end requirements • Subject to • Resource limitations, e.g., memory, power, weight, bandwidth ETAPS 2002

  12.  25  14  12  10 [ 5,7 ] [ 3,4 ] Job1 Job2 s1 s1+e1 s2 s2+e2 Example: Start-time Problem Start-time Assignment Problem with Inter-job Temporal Constraints Goal is to statically determine the range of start times for each job so that jobs are schedulable and all inter-job temporal constraints are satisfied. ETAPS 2002

  13. Example: power-aware RT scheduling • Dynamic Voltage Scaling allows tradeoffs between performance and power consumption • Problem is how to minimize power consumption while meeting timing constraints. • Example: three tasks with probabilistic execution time distribution ETAPS 2002

  14. Our approach and objectives • Design formalisms for real-time and embedded systems • Resource-bound real-time process algebras • Executable specifications • Logic for specifying properties • Design analysis techniques • Automated verification techniques • Parameterized end-to-end schedulability analysis • Toolset implementation ETAPS 2002

  15. Resource-bound computation • Computational systems are always constrained in their behaviors • Resources capture physical constraints • Resources should be supported as a first-class notion in modeling and analysis • Resource-bound computation is a general framework of wide applicability ETAPS 2002

  16. Resources • Resources capture constraints on executions • Resources can be • Serially reusable: • processors, memory, communication channels • Consumable • power • Resource capacities • Single-capacity resources • Multiple-capacity resources • Time-sliced, etc. ETAPS 2002

  17. Process Algebras • Process algebras are abstract and compositional methodologies for concurrent-system specification and analysis. • “Design methodology which systematically allows to build complex systems from smaller ones” [Milner] ETAPS 2002

  18. Process Algebras • A process algebra consists of • a set of operators and syntactic rules for constructing processes • a semantic mapping which assigns meaning or interpretation to every process • a notion of equivalence or partial order between processes • a set of algebraic laws that allow syntactic manipulation of processes. • Ancestors • CCS, CSP, ACP,… • focus on communication and concurrency ETAPS 2002

  19. Advantages of Process Algebra • A large system can be broken into simpler subsystems and then proved correct in a modular fashion. • A hiding or restriction operator allows one to abstract away unnecessary details. • Equality for the process algebra is also a congruence relation; and thus, allows the substitution of one component with another equal component in large systems. ETAPS 2002

  20. ACSR • ACSR (Algebra of Communicating Shared Resource) • A real-time process algebra which features discrete time, resources, and priorities • Timeouts, interrupts, and exception handling • Two types of actions: • Instantaneous events • Timed actions ETAPS 2002

  21. Events • Events represent non-time consuming activities • events are instantaneous: crash • point-to-point synchronization ETAPS 2002

  22. Events • Events • have priorities: • have input and output capabilities or ETAPS 2002

  23. Actions • Actions represent activities that • take time • require access to resources • each resource usage has priority of access • each resource can be used at most once • resources of action A: • idling action: • Examples: {(cpu,2}}, {(cpu1,3),(cpu2,4)}, {(semaphore,5)} ETAPS 2002

  24. Syntax for ACSR processes • Process terms • Process names ETAPS 2002

  25. Constant and Nil C is a constant that represents the process algebra expression P P = NIL P does nothing ETAPS 2002

  26. Prefix Operators P performs timed action A and then behaves as Q P = A:Q P performs event (a,n) and then behaves as Q P = (a,n).Q EXAMPLE ETAPS 2002

  27. Choice P can choose nondeterministically to behave like Q or R P = Q+R EXAMPLE ETAPS 2002

  28. Parallel Composition P is composed by Q and R that may synchronize on events and must synchronize on timed actions P = Q || R EXAMPLE ETAPS 2002

  29. Scope Q may execute for at most t time units. If message a is produced, control is delegated to R, else control is delegated to S. At any time T may interrupt. EXAMPLE ETAPS 2002

  30. P behaves just as Q but resources in I are no longer visible to the environment Hiding/Restriction P = [Q]I P behaves just as Q but labels in F are no longer visible to the environment P = Q\F EXAMPLE ETAPS 2002

  31. ACSR semantics • Gives an unambiguous meaning to language expressions. • Semantics is operational, given by a set of semantic rules. • Example of a labeled transition system: Labeled transition system Semantic rules ACSR specification ETAPS 2002

  32. ACSR semantics • Two-level semantics: • A collection of inference rules gives the unprioritized transition relation • A preemption relation on actions and events disables some of the transitions, giving a prioritized transition relation ETAPS 2002

  33. Prefix operators • Choice • Parallel Unprioritized transition relation ETAPS 2002

  34. Resource-constrained execution • Priority-based communication • Resource closure Unprioritized transition relation (II) ETAPS 2002

  35. Examples • Resource conflict • Processes must provide for preemption • Unprioritized transitions: ETAPS 2002

  36. Unprioritized transition relation (III) ETAPS 2002

  37. Example • A Scheduler rc rc kill  Sched Sched Sched ETAPS 2002

  38. To take priorities into account in the semantics we define the relation  is preempted by  : • An action  preempts action  iff • no lower priorities: • some higher priorities: • it contains fewer resources • e.g. • An event preempts an action iff •  with non-zero priority preempts all actions e.g. • An event preempts another event iff • same label, higher priority e.g. Preemption relation ETAPS 2002

  39. Prioritized transition relation • We define when • there is an unprioritized transition • there is no such that • Compositional ETAPS 2002

  40. Example • Unprioritized and prioritized transitions:   ETAPS 2002

  41. Example (cont.) • Resource closure enforces progress  ETAPS 2002

  42. A a a B C c b D E  A a B b c C D Bisimulation • Observational equivalence is based on the idea • that two equivalent systems exhibit the same • behavior at their interfaces with the environment. • This requirement was captured formally through • the notion of bisimulation, a binary relation on • the states of systems. • Two states are bisimilar if for each single • computational step of the one there exists an • appropriate matching (multiple) step of the other, • leading to bisimilar states. ETAPS 2002

  43. Prioritized strong equivalence • An equivalence relation is congruence when it is preserved by all the operators of the language. • This implies that replacement of equivalent components in any complex system leads to equivalent behavior. • Strong bisimulation over is a congruence relation with respect to the ACSR operators. ETAPS 2002

  44. Equational Laws • Equational laws are a set of axioms on the syntactic level of the language that characterize the equivalence relation. • They may be used for manipulating complex systems at the level of their syntactic (ACSR) description. • There is a set of laws that is complete for finite state ACSR processes: ETAPS 2002

  45. Fixed-priority scheduling in ACSR • A set of I tasks with periods pi and execution times ei, sharing the same CPU (resource cpu), where deadline equals period: • each task receives the start signal from the scheduler and begins executing • in each step, the task uses the resource cpu or idles if preempted • Priority of CPU access is based on the process index Taski = (start?,0) . Pi,0 +  : Taski i = {1,…,I} Pi,j = j < ei  (  : Pi,j + {(cpu,i)} : Pi,j+1) + j= ei  Taskii = {1,…,I} j = {0, ei} ETAPS 2002

  46. Scheduling and checking deadlines • Each task is controlled by an actuator process (intuitively, a part of the scheduler) • Starts execution of a task by sending start • Keeps track of deadlines • a task can accept start only after it completes execution in the previous period Actuatori = (starti!, i). Ai,0i = {1,2} Ai,k = k < pi  : Ai,k+1 + k = pi  Actuatorii = {1,2}, k = {0,pi} Jobi = (Taski|Actuatori)\starti ETAPS 2002

  47. Rate-monotonic scheduling • Order the task processes according to their periods • tasks with higher rates have higher indices and thus higher priorities • Compose the task processes and analyze for deadlock • the collection of tasks is schedulable iff there is no deadlock RM = (Job1|…|Jobn)[cpu] ETAPS 2002

  48. Dynamic-priority scheduling • Unlike fixed-priority scheduling, such as RM, the priority of a task changes with time • Earliest Deadline First (EDF) scheduling: priority of a task increases as it nears its deadline: πi = dmax − (pi − t) dmax= max(p1,…,pn) • An EDF task: Taski = (start?,0) . Pi,0,0 +  : Taski, i = {1,…,I} Pi,j,t = j < ei  (  : Pi,j,t+1 + {(cpu, dmax−(pi−t))} : Pi,j+1,t+1) + j= ei  Taskii = {1,…,I} j = {0, ei} t = {0, pi} ETAPS 2002

  49. Probabilistic ACSRfor soft real-time scheduling analysis ETAPS 2002

  50. PACSR (Probabilistic ACSR) • ACSR extension for probabilistic behaviors. • Objective : • formally describe behavioral variations in systems that arise due to failures in physical devices. • Since failing devices are modeled by resources we associate a failure probabilityp(r) with every resource r • at any time unit, r is down with probability p(r) or up with probability 1-p(r) • failures are assumed to be independent ETAPS 2002

More Related