PPT

NCO_yhlee_ 1

Real-time Embedded System Lab, ASU

Real-time SOA

Yann-Hang Lee, Wei-Tek Tsai, and Yinong Chen

Computer Science and Engineering Department

Arizona State University

[email protected]

NCO_yhlee_ 2

Real-time Embedded System Lab, ASU

Future Combat Systems

A large-scale distributed real-time embedded system which is dynamic, survivable, verifiable, reusable, maintainable

NCO_yhlee_ 3

Real-time Embedded System Lab, ASU

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

NCO_yhlee_ 4

Real-time Embedded System Lab, ASU

Process technology

Hardware design productivity

Software productivity

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

+58%

+21%

+8%

NCO_yhlee_ 5

Real-time Embedded System Lab, ASU

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)

NCO_yhlee_ 6

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

Service

provider

Service

broker

Service

consumer

publish

search

bind and

invoke

NCO_yhlee_ 7

Real-time Embedded System Lab, ASU

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

NCO_yhlee_ 8

Service Model of RTSOA

Passive and active services

App_1

Service _1

App_3

App_2

Service_2 Service_3

invoke/request

result

App_1PeriodicService

_1

App_3

App_2

PeriodicService_3

PeriodicService_

2

send(msg)receive

send(msg)

send(msg)

control/conf.

NCO_yhlee_ 9

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

NCO_yhlee_ 10

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

NCO_yhlee_ 11

Schedule Services in RT SOA

Service Binding

message schedulingservice scheduling at each node

traffic volumemsg routing

msg ready time

service ready time

utilization

msg delay computation delay

end-to-end delay

NCO_yhlee_ 12

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

NCO_yhlee_ 13

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

NCO_yhlee_ 14

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

NCO_yhlee_ 15

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

NCO_yhlee_ 16

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

NCO_yhlee_ 17

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

NCO_yhlee_ 18

Real-time Embedded System Lab, ASUReal-time Embedded System Lab, ASU

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

NCO_yhlee_ 19

Real-time Embedded System Lab, ASU

Thanks.

Questions and Comments

Real-time Embedded System Lab, ASU