Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PPT

856 views

Published on

  • Be the first to comment

  • Be the first to like this

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

×