Middleware with QoS support to control intelligent systems

943 views

Published on

Presentación de la ponencia en el congreso ADVCOMP 2008

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
943
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
25
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Portada. Decir lo de siempre en las portadas de las presentaciones. Este artículo trata de un diseño del middleware, actualmente en fase de validación. Con inspiración en el estándar DDS de OMG con soporte a las políticas de calidad de servicio (y consiguientemente a la calidad de servicio)‏
  • Middleware with QoS support to control intelligent systems

    1. 1. Middleware with QoS support to control intelligent systems <ul><ul><li>José Luis Poza Luján, Juan Luis Posadas Yagüe, José E. Simó Ten </li></ul></ul><ul><ul><li>Institute of Industrial Control Systems </li></ul></ul><ul><ul><li>Polytechnic University of Valencia </li></ul></ul>The Second International Conference on Advanced Engineering Computing and Applications in Sciences (ADVCOMP 2008) September 29 - October 4 Valencia, Spain
    2. 2. Contents <ul><li>Introduction </li></ul><ul><li>Fundamentals </li></ul><ul><ul><li>DCPS </li></ul></ul><ul><ul><li>SWE </li></ul></ul><ul><li>Architecture </li></ul><ul><ul><li>Overview </li></ul></ul><ul><ul><li>Control </li></ul></ul><ul><ul><li>Formal model </li></ul></ul><ul><li>Implementation </li></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Example </li></ul></ul><ul><li>Conclusions </li></ul>
    3. 3. Introduction <ul><li>Challenge </li></ul><ul><ul><li>Management of peer-to-peer quality of service (QoS) for component-based distributed intelligent control systems </li></ul></ul><ul><ul><li>This aspect of distributed systems goes beyond the real-time requirements because involves considerations such as. </li></ul></ul><ul><ul><ul><li>Computational resources availability </li></ul></ul></ul><ul><ul><ul><li>Security </li></ul></ul></ul><ul><ul><ul><li>Control algorithms cooperation </li></ul></ul></ul><ul><ul><ul><li>Stability </li></ul></ul></ul><ul><ul><ul><li>Task control performance </li></ul></ul></ul><ul><ul><ul><li>Redundant information management. </li></ul></ul></ul>
    4. 4. Introduction <ul><li>Communications in distributed systems </li></ul><ul><ul><li>To manage complex component-based distributed intelligent control systems, much more QoS features are needed. </li></ul></ul><ul><ul><li>A way of getting these new features are communications based on </li></ul></ul><ul><ul><ul><li>Message queuing technologies </li></ul></ul></ul><ul><ul><ul><li>Publish-subscribe paradigm </li></ul></ul></ul><ul><ul><ul><li>Control system based on services paradigm </li></ul></ul></ul><ul><ul><li>Standards are useful references to design a middleware </li></ul></ul>
    5. 5. Introduction <ul><li>Fundamentals </li></ul><ul><ul><li>Communications: Data Distribution Service (DDS) provides a system based on publish-subscribe paradigm with ability to manage a large amount of QoS policies. </li></ul></ul><ul><ul><li>Control: Sensor Web Enablement (SWE) allows a simple intelligent control model based on services capable of managing complex sensor networks. </li></ul></ul><ul><li>Architecture </li></ul><ul><ul><li>Joining DDS and SWE standards is interesting because it provides a unique environment to implement a solution to manage component-based distributed intelligent control system, based on the combination of several QoS policies. </li></ul></ul><ul><ul><li>The implementation of this architecture is called Framed Sensor Adapter Control (FSA-Ctrl) whose communication components are based on the DDS model and its control components are based on the SWE model. The QoS merges communications and control components. </li></ul></ul>
    6. 6. Fundamentals: DDS <ul><li>Data Distribution Service (DDS) provides a platform independent model that is aimed to real-time distributed systems, is based on publish-subscribe communications paradigm. </li></ul><ul><li>Publish-subscribe components connect information producers (publishers) and consumers (subscribers) and isolate publishers and subscribers in time, space and message flow. </li></ul><ul><li>To configure the communications, DDS uses QoS policies. </li></ul><ul><ul><li>A QoS policy describes the service behavior according to a set of parameters defined by the system characteristics or by the administrator user. </li></ul></ul><ul><li>DDS specifies two areas: Data-Centric Publish-Subscribe (DCPS) witch is responsible for data distribution and DLRL which is responsible for the data adaptation. </li></ul>
    7. 7. Fundamentals: DDS & DCPS <ul><li>When an producer (component, agent or application) wants to publish some information, should write it in a Topic by means of an component called DataWriter witch is managed by another component called Publisher . Both components, DataWriter and Publisher , are included in another component called DomainParticipant . </li></ul><ul><li>On the other side of the communication, a Topic can be received by two kinds of components: DataReaders and Listeners by means a Subscriber . </li></ul><ul><li>A DataReader provides the messages to application. A Listened sends the messages to the application. </li></ul>
    8. 8. Fundamentals: DCPS & QoS <ul><li>QoS is a concept that defines a set of parameters by which to evaluate a service offered. </li></ul><ul><li>In the field of control architectures, there are many definitions of quality of service. </li></ul><ul><ul><li>Processing viewpoint: QoS represents the set of both: quantitative and qualitative characteristics of a distributed system needed to achieve the functionality required by an application. </li></ul></ul><ul><ul><li>Communications viewpoint: QoS is defined as all the requirements that a network must meet to message flow transport. </li></ul></ul><ul><li>DCPS specification defines 22 different QoS policies that can be classified into four areas </li></ul><ul><li>All components of a DCPS based communication, can establish a set of QoS policies into them independently the others components. </li></ul>
    9. 9. Fundamentals: SWE <ul><li>The main objective of Sensor Web Enablement (SWE) is to provide a new and unique framework of open standards for exploiting Web-connected sensors and sensor systems of all types. </li></ul><ul><li>The components of SWE are divided into two groups: </li></ul><ul><ul><li>Information models: standard specifications in XML and processes interchange messages. </li></ul></ul><ul><ul><li>Services: control components that process the information models. </li></ul></ul><ul><li>Control processes are based on interconnected components. </li></ul><ul><ul><li>These components receive information models from other components and send the process results to other connected components. </li></ul></ul><ul><li>A component is a particular process that transforms information. </li></ul><ul><ul><li>Simple examples of SWE components are sensors, effectors or physical process filters. </li></ul></ul><ul><ul><li>Complex examples of SWE components are control kernels or sensor data fusion algorithms. </li></ul></ul>
    10. 10. Fundamentals: SWE <ul><li>A Process Model is a single component, used within a more complex structure, called a Process Chain . Moreover, a Process Model is based on a Process Method witch acts as a Process Model template. </li></ul><ul><li>A Process Method specifies both the interface and how to implement the Process Model . It also defines inputs, outputs and the operating parameters. </li></ul>
    11. 11. Architecture: overview <ul><li>Frame Sensor Adapter to Control (FSA-Ctrl) is an architecture inspired by DDS and SWE models and is an evolution of an architecture developed by the research group called Frame Sensor Adapter (FSA)‏ </li></ul><ul><li>The architecture has two distinct areas: communications and control. QoS Policies connects both areas. </li></ul><ul><li>The communication layer organizes the LogicalData in a symbolic hierarchical tree structure called Logical Namespace Tree (LNT)‏ </li></ul><ul><li>Control layer organizes the Sensors on a graph, called Logical Sensor Graph (LSG)‏ </li></ul>
    12. 12. Architecture: system control <ul><li>Components witch implements the control system are named Logical Sensors (LS) and contains the control algorithms. </li></ul><ul><ul><li>Logical Sensors may include others Logical Sensors to create complexes Logical Sensors than gives more complex algorithms </li></ul></ul><ul><li>Communication into Logical Sensors can be of two kinds (depending on location in the distributed system)‏ </li></ul><ul><ul><li>Internal: LSG </li></ul></ul><ul><ul><li>External: LNT </li></ul></ul>
    13. 13. Architecture: formal model <ul><li>FSA-Ctrl Architecture model implements communications and control by means a group of classes. </li></ul><ul><li>A group of QoS classes can be associated to every class. </li></ul><ul><li>DCPS and SWE components can be implemented with a set of QoS associated </li></ul>
    14. 14. Implementation: design <ul><li>Application to design an specific LNT and LSG for a control system. </li></ul>LNT design pane Logical Sensor implementation LSG design pane
    15. 15. Implementation <ul><li>Robot Control Navigation </li></ul>
    16. 16. Conclusions <ul><li>FSA-Ctrl is a component-based distributed intelligent control architecture with QoS support. </li></ul><ul><ul><li>Communications based on publish-subscribe paradigm and the DCPS standard endorsed by OMG allows to convert easily the system into another. </li></ul></ul><ul><ul><li>Control based on SWE standard endorsed by OGC allows the high-distributed control algorithms. </li></ul></ul><ul><li>The FSA-Ctrl architecture especially focuses on setting QoS management policies. </li></ul><ul><ul><li>With these policies, the system can make decisions about questions like the discrimination of redundant information. </li></ul></ul><ul><li>The architecture can be applied to evaluate the proper location for the components. </li></ul><ul><ul><li>Since certain control components with a set of QoS restrictions for each, the architecture could distribute automatically the agents’ control processes according to the restrictions. </li></ul></ul>

    ×