The document discusses applying a service-oriented architecture (SOA) approach to real-time embedded systems. Key challenges include meeting timing constraints for service invocations in distributed systems and scheduling services across nodes. The authors propose a real-time SOA model with periodic and aperiodic services. They also describe techniques like rate-monotonic scheduling and pinwheel scheduling to assign priorities and allocate bandwidth to ensure bounded message delays and meet end-to-end deadlines. Ontologies are suggested to generate plans from reusable templates for different application domains. While SOA for real-time systems faces issues, the authors believe the approach can be effective if models and optimization methods are tailored to application requirements and service semantics.

1. 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

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. 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

4. 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%

5. 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

6. 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

7. 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

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_1 Periodic Service _1 App_3 App_2 Periodic Service_3 Periodic Service_2 send(msg) receive send(msg) send(msg) control/conf.

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

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

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. 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

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

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

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

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

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

18. 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

19. Thanks. Questions and Comments Real-time Embedded System Lab, ASU Real-time Embedded System Lab, ASU