PPT

681 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
681
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

PPT

  1. 1. Real-time SOA <ul><ul><li>Yann-Hang Lee, Wei-Tek Tsai, and Yinong Chen </li></ul></ul><ul><ul><li>Computer Science and Engineering Department </li></ul></ul><ul><ul><li>Arizona State University </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul>Real-time Embedded System Lab, ASU
  2. 2. Future Combat Systems Real-time Embedded System Lab, ASU A large-scale distributed real-time embedded system which is dynamic, survivable, verifiable, reusable, maintainable
  3. 3. Trends of Real-time Embedded Systems <ul><li>Wide-spreading </li></ul><ul><li>Distributed, connected, and heterogeneous </li></ul><ul><li>Mission and safety critical </li></ul><ul><li>Quality of the products </li></ul><ul><ul><li>portable/reusable, reliable/dependable, interoperable, predictable (schedulable), and secured </li></ul></ul><ul><li>Software extensive </li></ul><ul><li>Examples: </li></ul><ul><ul><li>Home and factory automation, transportation </li></ul></ul><ul><ul><li>Communication (PCS, wire and wireless) and sensor networks </li></ul></ul><ul><ul><li>Medical devices – monitoring and implantable </li></ul></ul><ul><ul><li>Defense applications – Network centric warfare and future combat system </li></ul></ul>Real-time Embedded System Lab, ASU
  4. 4. Building RT Embedded Systems <ul><li>Advances in general-purpose computers </li></ul><ul><ul><li>PCs are powerful, cheap, and versatile </li></ul></ul><ul><ul><li>Information processing is ubiquitous </li></ul></ul><ul><li>Thanks for the increase in productivity </li></ul>Real-time Embedded System Lab, ASU Process technology Hardware design productivity Software productivity +58% +21% +8%
  5. 5. Distributed Embedded Software <ul><li>Characteristics </li></ul><ul><ul><li>Network centric, concurrent operations, time and environment dependent </li></ul></ul><ul><li>Embedded software development </li></ul><ul><ul><li>80% programs in embedded system is with C/C++ and15% in assembly </li></ul></ul><ul><ul><li>the same thing that has been done more than 30 years (Ada?) </li></ul></ul><ul><li>Software complexities </li></ul><ul><ul><li>inherent and cannot be eliminated, i.e. algorithm, concurrency, etc. </li></ul></ul><ul><ul><li>accidental (due to technology or methods used), i.e. memory leaks </li></ul></ul><ul><li>What can we do? </li></ul><ul><ul><li>abstraction (e.g. modeling) </li></ul></ul><ul><ul><li>automation (e.g. code generation, composition) </li></ul></ul>Real-time Embedded System Lab, ASU
  6. 6. Service-Oriented Architecture <ul><li>Service as an abstraction for </li></ul><ul><ul><li>discovery </li></ul></ul><ul><ul><li>composition </li></ul></ul><ul><ul><li>invocation </li></ul></ul><ul><li>SOA represents a paradigm shift away from the “software application” to the ‘software-as-a-service” model </li></ul><ul><li>Based on connectivity of the sites that provide services </li></ul>Real-time Embedded System Lab, ASU Service provider Service broker Service consumer publish search bind and invoke
  7. 7. Real-time Perspectives in SOA <ul><li>Invocations of services must be completed within specific timing constraints </li></ul><ul><ul><li>should include network delay, and data marshalling overhead. </li></ul></ul><ul><li>How about the semantics of embedded applications </li></ul><ul><ul><li>Never-ending operation: periodic or aperiodic </li></ul></ul><ul><ul><li>Event-driven or time-driven </li></ul></ul><ul><ul><li>Asynchrony –- signals, events, transfer of control </li></ul></ul><ul><ul><li>Concurrency – invoke more than one services at the same time </li></ul></ul><ul><li>Must be based on a distributed real-time architecture </li></ul>Real-time Embedded System Lab, ASU
  8. 8. Service Model of RTSOA <ul><li>Passive and active services </li></ul>App_1 Service _1 App_3 App_2 Service_2 Service_3 invoke/request result App_1 Periodic Service _1 App_3 App_2 Periodic Service_3 Periodic Service_2 send(msg) receive send(msg) send(msg) control/conf.
  9. 9. Service Model of RTSOA <ul><li>Basic functional service model </li></ul><ul><li>Real-time properties of services </li></ul><ul><li>Quality of service: </li></ul><ul><ul><li>Minimum and maximal response times </li></ul></ul><ul><ul><li>Service capacity (such as a number of service invocations that can be accepted per unit of time) </li></ul></ul><ul><ul><li>Degree of concurrency (the maximal number of service consumers that the service provider can be bounded to simultaneously) </li></ul></ul><ul><ul><li>Cost and required resource </li></ul></ul><ul><li>Communication as a service </li></ul><ul><ul><li>guaranteed message delay or bandwidth reservation </li></ul></ul>
  10. 10. Execution Model of Real-time SOA <ul><li>System model: services are distributed in multiple nodes which are connected by networks </li></ul><ul><li>Task model: a sequence of services executed in several nodes </li></ul><ul><li>Possible precedence constraint between consequent services </li></ul><ul><li>Service allocation and scheduling </li></ul><ul><li>End-to-end delay: execution times of services and message delays </li></ul><ul><li>Jitter control: when a service can be released </li></ul>
  11. 11. Schedule Services in RT SOA Service Binding message scheduling service scheduling at each node traffic volume msg routing msg ready time service ready time utilization msg delay computation delay end-to-end delay
  12. 12. Generalized RMS for Distributed Scheduling <ul><li>Assign periodic execution for each required service at its host node </li></ul><ul><li>Partition end-to-end deadlines to each service and communication </li></ul><ul><li>Synchronized period for each service </li></ul><ul><li>Rate-monotonic or deadline monotonic scheduling to determine priorities at each node </li></ul><ul><li>Bandwidth allocation to ensure bounded message delays. </li></ul><ul><li>Schedulability test </li></ul>
  13. 13. Cyclic Scheduling (Time-based) <ul><li>Time triggering in TMO </li></ul><ul><ul><li>A synchronized clock </li></ul></ul><ul><ul><li>Tasks are scheduled in cyclic manner at each node </li></ul></ul><ul><ul><li>Control the jitter (earliest and latest instants) </li></ul></ul><ul><li>Pinwheel scheduling </li></ul><ul><ul><li>A task set with harmonic periods can have 100% schedulability utilization </li></ul></ul><ul><ul><li>Transfer the periods into harmonic numbers </li></ul></ul><ul><ul><li>Use pinwheel scheduling at each node </li></ul></ul><ul><ul><li>Distance constraints at each pipelined stage </li></ul></ul><ul><ul><li>Pinwheel phase alignment to minimize end-to-end delay </li></ul></ul>
  14. 14. Real-Time Communication <ul><li>To achieve an end-to-end delay bound for messages </li></ul><ul><li>Difficulties: </li></ul><ul><ul><li>distributed queueing --- distributed scheduler </li></ul></ul><ul><ul><li>efficient use of bandwidth </li></ul></ul><ul><ul><li>non-preemptable </li></ul></ul><ul><ul><li>buffer requirement </li></ul></ul><ul><ul><li>interaction between consecutive link servers </li></ul></ul><ul><li>Typical approaches: scheduling based on assigned priority or reserved bandwidth </li></ul><ul><ul><li>Reserve a suitable bandwidth during admission control </li></ul></ul><ul><ul><li>Packet-by-packet generalized processor sharing ( PGPS ) to schedule packets according to the simulated finishing time </li></ul></ul>
  15. 15. Optimal Composition <ul><li>Following discovery, determine how a plan should be realized if multiple services exist. </li></ul><ul><li>A typical optimization problem with </li></ul><ul><ul><li>Objectives: minimize cost (resource usage, vulnerability) </li></ul></ul><ul><ul><li>Constraints: deadlines, jitters, number of service nodes. </li></ul></ul><ul><li>Global or local optimization </li></ul><ul><li>How practical of the approaches </li></ul><ul><ul><li>scalability </li></ul></ul><ul><ul><li>dynamic composition due to mission requirement, external event, and mobility </li></ul></ul><ul><ul><li>effectiveness </li></ul></ul><ul><ul><li>the availability of information </li></ul></ul>
  16. 16. A Practical Approach <ul><li>Levels of service quality </li></ul><ul><ul><li>service threads from a fixed pool </li></ul></ul><ul><ul><li>invocation frequency or periodicity </li></ul></ul><ul><ul><li>resolution, bandwidth, and resource allocation </li></ul></ul><ul><li>Restriction of accessing to various levels </li></ul><ul><li>When compositing a plan, </li></ul><ul><ul><li>a partial search (breath or depth first) while reserving the resources the requestor is allowed </li></ul></ul><ul><ul><li>basically, a greedy approach </li></ul></ul><ul><li>Cached and canned services </li></ul><ul><li>Backup and duplicated services </li></ul>
  17. 17. Ontology for RTSOA <ul><li>Consider smart home applications </li></ul><ul><ul><li>All houses are different with different appliance and residence </li></ul></ul><ul><ul><li>Can plans be developed for each house and its residence </li></ul></ul><ul><li>Ontology: a knowledge base for the specific application domain </li></ul><ul><ul><li>generic services and application templates </li></ul></ul><ul><ul><li>key words and relations </li></ul></ul><ul><li>Based on registration information, plans can be </li></ul><ul><ul><li>generated and composited </li></ul></ul><ul><ul><li>re-evaluated for service mobility </li></ul></ul>
  18. 18. Summary <ul><li>Software development is a tough job, it is more difficult for RTES </li></ul><ul><ul><li>many emerging requirements </li></ul></ul><ul><ul><li>it is the design of the systems </li></ul></ul><ul><ul><li>what else other than C & C++, or Ada </li></ul></ul><ul><li>Is SOA ready for distributed real-time embedded applications </li></ul><ul><ul><li>the goals: abstraction and automation </li></ul></ul><ul><ul><li>SOA overhead, optimization and real-time issues – can be solved to certain degrees </li></ul></ul><ul><ul><li>how effective: depends upon the application domains </li></ul></ul><ul><ul><li>service semantics and models: can be tailored to specific application domains </li></ul></ul><ul><ul><li>SOSE: service-oriented system engineering </li></ul></ul>Real-time Embedded System Lab, ASU Real-time Embedded System Lab, ASU
  19. 19. <ul><li>Thanks. </li></ul><ul><li>Questions and Comments </li></ul>Real-time Embedded System Lab, ASU Real-time Embedded System Lab, ASU

×