PPT
Upcoming SlideShare
Loading in...5
×
 

PPT

on

  • 801 views

 

Statistics

Views

Total Views
801
Views on SlideShare
801
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

PPT PPT Presentation Transcript

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