1. Real-Time Systems Group University of Pennsylvania 5/24/2001 Resource-bound family of real-time process algebras Oleg Sokolsky, Insup Lee Real-Time Systems Group University of Pennsylvania Joint work with Richard Gerber, Duncan Clarke, Hanène Ben-Abdallah, Anna Philippou, Hee-Hwan Kwak, Jin-Young Choi, and many, many others

2. Real-Time Systems Group University of Pennsylvania 5/24/2001 Outline Resource-bound computation Process-algebraic modeling –ACSR –PACSR Future extensions –domain-specific formalisms –resource equivalences and preorders

3. Real-Time Systems Group University of Pennsylvania 5/24/2001 Resource-bound computation Computational systems are always constrained in their behavior Resources capture physical constraints Resources should be used as a primitive notion in modeling and analysis Resource-bound computation is a general framework of wide applicability

4. Real-Time Systems Group University of Pennsylvania 5/24/2001 Domain-specific extensions Different problem domains need different treatments –different nature of resources –different kinds of communication –different kinds of analysis Provide for variations within the general framework of resource-bound computation

5. Real-Time Systems Group University of Pennsylvania 5/24/2001 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.

6. Real-Time Systems Group University of Pennsylvania 5/24/2001 Events Events represent communication –events are instantaneous –point-to-point communication across channels –prioritized access to channels –input and output events

7. Real-Time Systems Group University of Pennsylvania 5/24/2001 Actions Actions represent computation –actions take time –require access to resources –each resource has priority of access –each resource can be used at most once –resources of action A : –idling action

8. Real-Time Systems Group University of Pennsylvania 5/24/2001 Computation model A specification is composed of processes Processes evolve by performing events and actions

9. Real-Time Systems Group University of Pennsylvania 5/24/2001 Syntax for ACSR processes Process terms Process names

10. Real-Time Systems Group University of Pennsylvania 5/24/2001 ACSR semantics Two-level semantics: –A collection of inference rules gives unprioritized transition relation –A preemption relation on actions and events disables some of the transitions, giving a prioritized transition relation

11. Real-Time Systems Group University of Pennsylvania 5/24/2001 Unprioritized transition relation Prefix operators Choice Parallel

12. Real-Time Systems Group University of Pennsylvania 5/24/2001 Unprioritized transition relation (II) Resource-constrained execution Priority-based communication Resource reservation

13. Real-Time Systems Group University of Pennsylvania 5/24/2001 Preemption relation  is preempted by  : action preempts action –no lower priorities: –some higher priorities: – event preempts event –same label, higher priority event preempts action –  with non-zero priority preempts all actions

14. Real-Time Systems Group University of Pennsylvania 5/24/2001 Prioritized transition relation We define when: –there is an unprioritized transition –there is no such that

15. Real-Time Systems Group University of Pennsylvania 5/24/2001 Example Resource conflict: Processes must provide for preemption Unprioritized and prioritized transitions:  

16. Real-Time Systems Group University of Pennsylvania 5/24/2001 Example (cont.) Resource reservation enforces progress 

17. Real-Time Systems Group University of Pennsylvania 5/24/2001 ACSR analysis techniques Prioritized strong and weak bisimulation Reachability analysis and deadlock detection –schedulability analysis A collection of periodic tasks and the scheduler are encoded as ACSR processes Schedulable iff deadlock free Parametric analysis with ACSR-VP –Which combinations of task parameters yield schedulable systems

18. Real-Time Systems Group University of Pennsylvania 5/24/2001 PACSR ACSR extension for fault-tolerant systems Consider physical failures –occur in components modeled by resources Associate a failure probability p r with every resource r –at any time unit, r is down with probability p r or up with probability –failures are independent

19. Real-Time Systems Group University of Pennsylvania 5/24/2001 Resource failures and recoveries An action containing resource r cannot be taken when r is failed Failed resources: Recoveries are modeled by using failed resources in actions

20. Real-Time Systems Group University of Pennsylvania 5/24/2001 PACSR semantics A world W is a set of resources such that Immediate resources of a process imr (P), resources that can be used in the first step Configuration: a process within a world (P,W) –Nondeterministic configurations: W contains all resources from imr (P) or their complements –Probabilistic configurations: otherwise

21. Real-Time Systems Group University of Pennsylvania 5/24/2001 PACSR semantics (II) PACSR semantics gives a transition relation over configurations Nondeterministic transition relation is taken from ACSR, with one exception: Probabilistic transition relation

22. Real-Time Systems Group University of Pennsylvania 5/24/2001 PACSR analysis techniques Probabilistic weak bisimulation Probabilistic reachability and deadlock detection –compute the probability of reaching an event Long-term averages computation –compute performance properties such as task throughput or average latency

23. Real-Time Systems Group University of Pennsylvania 5/24/2001 Future work: other domains Power-sensitive applications –associate power consumption measure with every resource usage –provide for different levels of power consumption Possible technical approach: –multi-capacity resources: r:n –multiple occurrences in actions: –power consumption increases with each occurrence

24. Real-Time Systems Group University of Pennsylvania 5/24/2001 New resource equivalences Two processes can have the same functional behavior but with different patterns of resource use For example: Resource equivalence relation: –along every path, processes exhibit the same I/O behavior consume the same resources Reason about tradeoffs

25. Real-Time Systems Group University of Pennsylvania 5/24/2001 Conslusions Resource-bound specification formalisms proved useful is several problem domains Extensions to other domains will make the approach more widely applicable Easily accommodate other kinds of constraints (size,weight, etc.)