1 / 59

AFECS

AFECS. Agent Based Framework For Experiment Control Systems … Jeffeson Lab V. Gyurjyan , D. Abbott, G. Heyes , E. Jastrzembski , C. Timmer , E. Wolin. Outline. SOA and intelligent agent technologies cMsg – A Publish/Subscribe inter-process communication channel

nevin
Download Presentation

AFECS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AFECS Agent Based Framework For Experiment Control Systems … Jeffeson Lab V. Gyurjyan, D. Abbott, G. Heyes, E. Jastrzembski, C. Timmer, E. Wolin

  2. Outline • SOA and intelligent agent technologies • cMsg – A Publish/Subscribe inter-process communication channel • ECS framework design criteria • COOL - Control oriented ontology language • Current implementations Vardan Gyurjyan. Jefferson Lab

  3. SOA and intelligent agent technologies

  4. SOA • Style of building reliable systems that deliver functionality as services • Loose coupling between interacting services Vardan Gyurjyan. Jefferson Lab

  5. Service • Atomic unit of an SOA. • Encapsulates logic, data, or process. • Autonomous • Location Transparency • It is defined by the messages it can accept and the responses it can give. Messages can be one-way, synchronous or asynchronous. • They can be integrated to provide higher-level services • It can be completely self-contained, or it may depend on the availability of other services or other resources. Vardan Gyurjyan. Jefferson Lab

  6. Service interaction Service Registry Discover Advertise Service Consumer Service Provider Interact Vardan Gyurjyan. Jefferson Lab

  7. Loose Coupling • Flexibility • Scalability • Replaceability • Fault tolerance Service Registry Discover Advertise Service Provider Consumer 1 Data storage 2 Service Provider 3 Service Provider Services are stateless Vardan Gyurjyan. Jefferson Lab

  8. SO vs. OO • OO advocates tight coupling, i.e. users have static knowledge of the object. • SOA promotes the design of the system in which it is not necessary that requests and responses are handled by the same set of communicating entities. • Service has an internal thread of control. SayHelloWorld Object Service SayHelloWorld “Hello World” “Sorry I am busy” SO OO Vardan Gyurjyan. Jefferson Lab

  9. Goal-oriented creative adaptive persistent mobile social Agent is a service Agent Vardan Gyurjyan. Jefferson Lab

  10. Agent Internal and External Environments Balance External Environment: user, other agents, applications, information sources, their relationships, platforms, servers, networks, etc. Agent Internal Environment: architecture, goals, abilities, sensors, effectors, profile, knowledge, etc. Vardan Gyurjyan. Jefferson Lab

  11. What does it mean? • Intelligent Agent is an entity that is able to keep continuous balance between its internal and external environments (it has at least one goal) in such a way that in the case of imbalance agent can: • change external environment to be in balance with the internal one (creative) • change internal environment to be in balance with the external one (adaptive) • find out and move to another place within the external environment where balance occurs without any changes (mobile) • closely communicate with one or more other agents to be able to create a community, which internal environment will be able to be in balance with the external one (social) Vardan Gyurjyan. Jefferson Lab

  12. cMsg – A Publish/Subscribe inter-process communication system

  13. What is Publish/Subscribe Messaging • Asynchronous, distributed, location transparency • Distinct from client/server • Publisher: publish or send messages to “subjects” • “launch-and-forget” mode • many publishers can publish to the same subject • Subscriber: subscribe to subjects and supply callbacks • “subscribe-and-forget” mode • many subscribers can subscribe to the same subject • A process can be both a publisher and subscriber • a process can even receive messages it produces! Vardan Gyurjyan. Jefferson Lab

  14. subscriber subscribe cMsg system publish subscribe subscriber publisher subscribe subscriber Vardan Gyurjyan. Jefferson Lab

  15. publisher subscriber subject “x” subscribe subscribe subject “x” subject “x” publish subject “x” cMsg system subscribe subscriber publisher subject “x” subject “x” subscribe publisher subscriber Vardan Gyurjyan. Jefferson Lab

  16. cMsg based P2P cMsg Server Publish Subscribe Publish Subscribe Point 1 Point 2 Vardan Gyurjyan. Jefferson Lab

  17. cMsg – status A complete publish/subscribe messaging system • Very simple API • C/C++, Java, C# (in progress) • Many Unix flavors, VxWorks, windows (in progress) • Has some synchronous capabilities • Highly customizable and extendable Vardan Gyurjyan. Jefferson Lab

  18. To send a cMsg message #include <cMsg.hxx> // connect to system via Universal Domain Locator cMsg c(UDL, “myName”, “My description”); c.connect(); // create and fill message cMsgMessage msg; msg.setSubject(“mySubject”); msg.setType(“myType”); msg.setText(“This is my text”); // send message c.send(msg); Vardan Gyurjyan. Jefferson Lab

  19. To receive a cMsg message #include <cMsg.hxx> // connect to cMsg system cMsg c(UDL, “myName”, “My description”); c.connect(); // subscribe to subject/type combination and start receiving c.subscribe(“mySubject”, “myType”, new myCallback(), NULL); c.start(); // do something else… Vardan Gyurjyan. Jefferson Lab

  20. Where callback is: class myCallback : public cMsgCallback { void callback(cMsgMessage *msg, void* userArg) { cout << “Message subject is: " << msg->getSubject() << endl; } }; Vardan Gyurjyan. Jefferson Lab

  21. Vardan Gyurjyan. Jefferson Lab

  22. Vardan Gyurjyan. Jefferson Lab

  23. ECS framework design criteria

  24. Project Goal • Develop a framework for building control systems • open architecture • hierarchical • network distributed • Provide a set of tools to deploy: • test and control systems • alarm systems • control visualization systems, etc. Vardan Gyurjyan. Jefferson Lab

  25. ECS Requirements • Control components of the experiment. • Full description of the experiment components. • Fault tolerance and recovery. • Create and deploy finite state machines. Vardan Gyurjyan. Jefferson Lab

  26. Design Philosophy of AFECS • Pure Java. • Collaborating autonomous agents. • Each agent represents a hardware or software component. • Messages between agents invoke actions. • Agents behave as finite state machines. • Agents communicate with physical components through standard protocols. Vardan Gyurjyan. Jefferson Lab

  27. AFECS Agent Categories • Normative agents administrative agent • Crate and manage all other agents • Environment administration • Supervisor agentsControl groups of Component agents • Component agentsRepresent hardware or software components of the real world control system. N S A Vardan Gyurjyan. Jefferson Lab

  28. Component Agent Agents mimic the state of the real (physical) component, they can invoke actions which change the physical component state. A A A AFECS (control) world. IPC IPC IPC Real world. HV power supply Target system Gas system Vardan Gyurjyan. Jefferson Lab

  29. Inter-Process Communication Channels Agents communicate with their associated physical components using range of communication protocols including: • Tcl-DP (legacy protocol) • cMsg P2P • EPICS channel access protocol • SNMP (simple network management protocol) • JDBC (for database clients) • OS shell interface • DIM (in progress) Vardan Gyurjyan. Jefferson Lab

  30. Supervisor Agent Supervisor agents have discrete states and they respond to messages from other agents (supervisor or component). S DC HV control supervisor agent A A A Agents representing Individual power supplies HV crate 1 HV crate 2 HV crate 3 DC HV crates Vardan Gyurjyan. Jefferson Lab

  31. Agents Groupings • Physical (AFECS container)A java virtual machine (JVM) is an agent container.Container is a process. Agent is a set of threads in the process. • Logical (AFECS domain)Agents are grouped into virtual clusters or domains according to their functions. Agents in eachdomain may be visible to other domains. N S A S S S A A A A Vardan Gyurjyan. Jefferson Lab

  32. Domain • Reduces complexity of large control systems. • Encourages modularity and encapsulation.(only a few agents and their behaviors are visible outside of the domain limits) • Promotes control system hierarchical structure. • Can be redesigned and tested independently, without affecting the rest of the control system.(as long as the behavior of the visible agents remains the same) Vardan Gyurjyan. Jefferson Lab

  33. AFECS Platform Distribution • Agents are physically distributed • at the configuration time • at runtime S S S N A A A A Vardan Gyurjyan. Jefferson Lab

  34. Hierarchy of domains Physical Components Normative Agents NR NA NC A CODA ROC S CODA EMU A Front-End Supervisor agent A EPICS IOC 1 S S A EPICS CAG Grand supervisor S A Trigger soft AFECS Platform S cMsg Trigger hard A Online ANA A IPC IPC IPC IPC WEB GUI/user Vardan Gyurjyan. Jefferson Lab

  35. Physical Component Integration AFECSplatform Administrative domain and container NC NR Description of the control NA Agent Fred Component Fred Vardan Gyurjyan. Jefferson Lab

  36. COOL - Control oriented ontology language Designing a control system requires precise descriptions of physical components and their software abstractions.

  37. Control Oriented Ontology Language • Defines an agent model of the experiment. • Describes functionalities of physical components (state machines) • Describes the semantics of control. • Developed using RDFS. • Is intuitive and human readable. • Can be generated using GUI. Vardan Gyurjyan. Jefferson Lab

  38. What is an Ontology? • An ontology is a specification of a conceptualization. – Tom Gruber • An ontology is a way of representing a knowledge, meaningthat knowledge is formalized in a symbolic form, that is, to find a symbolic expression that can be interpreted. – Klein and Methlie Vardan Gyurjyan. Jefferson Lab

  39. No really what is an Ontology? • An ontology specifies a description of the • Terminology and concepts • Properties explicitly defining the terms, concepts • Relations among concepts • Rules distinguishing concepts, refining definitions and relations (constraints, restrictions, regular expressions) relevant to a particular domain or area of interest. Vardan Gyurjyan. Jefferson Lab

  40. Philosophy of Knowledge Knowledge we have Knowledge we know we don't know Knowledge we are not aware we don't know Vardan Gyurjyan. Jefferson Lab

  41. Formalized Knowledge D1 Vardan Gyurjyan. Jefferson Lab

  42. Domain Ontology Taxonomic Knowledge A novel and poem are books. A book is a document. Domain Ontology document book novel poem Vardan Gyurjyan. Jefferson Lab

  43. Process Ontology Relational Knowledge A document author is a woman. Process Ontology author document woman Vardan Gyurjyan. Jefferson Lab

  44. Interface Ontology Process Ontology author document woman Process Ontology name woman string Process Ontology author document string Vardan Gyurjyan. Jefferson Lab

  45. RDF: Resource Description Framework • RDF is best suited to formalize triple structure of the knowledge base. XML RDF Value Resource Tag Property Object Value Subject Predicate Vardan Gyurjyan. Jefferson Lab

  46. Vardan Gyurjyan. Jefferson Lab

  47. Example <cool:hasComponent rdf:resource="http://COOLHOME/Sms/test#FSMS1"/> <cool:hasComponent rdf:resource="http://COOLHOME/Slc/test#FSLC1"/> <cool:hasRule rdf:resource= "http://COOLHOME/Rules/test#RULE1"/> <cool:hasRule rdf:resource= "http://COOLHOME/Rules/test#RULE2"/> <cool:hasRule rdf:resource= "http://COOLHOME/Rules/test#RULE3"/> <cool:hasSlcOption rdf:resource="http://COOLHOME/Options/test#OPTION"/> Vardan Gyurjyan. Jefferson Lab

  48. Example States <!-- Fake supervisor 1 states --> <rdf:Description rdf:about="http://COOLHOME/States/test#OK"> <cool:hasStateName>FSMS1_Ok</cool:hasStateName> <cool:isFor rdf:resource="http://COOLHOME/Sms/test#FSMS1"/> <cool:hasSeverity>1</cool:hasSeverity> </rdf:Description> <rdf:Description rdf:about="http://COOLHOME/States/test#WARNING"> <cool:hasStateName>FSMS1_Warning</cool:hasStateName> <cool:isFor rdf:resource="http://COOLHOME/Sms/test#FSMS1"/> <cool:hasSeverity>5</cool:hasSeverity> </rdf:Description> <rdf:Description rdf:about="http://COOLHOME/States/test#ERROR"> <cool:hasStateName>FSMS1_Error</cool:hasStateName> <cool:isFor rdf:resource="http://COOLHOME/Sms/test#FSMS1"/> <cool:hasSeverity>10</cool:hasSeverity> </rdf:Description> Vardan Gyurjyan. Jefferson Lab

  49. Example States <!--FSLC1 component states--> <rdf:Descriptionrdf:about="http://COOLHOME/States/test#OFF"> <cool:hasStateName>off</cool:hasStateName> <cool:isForrdf:resource="http://COOLHOME/Slc/test#FSLC1"/> <cool:achevedThroughrdf:resource="http://COOLHOME/Processes/test#PROCESS1"/> </rdf:Description> <rdf:Descriptionrdf:about="http://COOLHOME/States/test#ON"> <cool:hasStateName>on</cool:hasStateName> <cool:isForrdf:resource="http://COOLHOME/Slc/test#FSLC1"/> <cool:achevedThroughrdf:resource="http://COOLHOME/Processes/test#PROCESS2"/> </rdf:Description> <rdf:Descriptionrdf:about="http://COOLHOME/States/test#STANDBY"> <cool:hasStateName>standby</cool:hasStateName> <cool:isForrdf:resource="http://COOLHOME/Slc/test#FSLC1"/> <cool:achevedThroughrdf:resource="http://COOLHOME/Processes/test#PROCESS3"/> </rdf:Description> Vardan Gyurjyan. Jefferson Lab

  50. Example Rules <rdf:Descriptionrdf:about="http://COOLHOME/Rules/test#RULE1"> <cool:ifrdf:resource="http://COOLHOME/States/test#ON"/> <cool:thenMoveTordf:resource="http://COOLHOME/States/test#OK"/> </rdf:Description> <rdf:Descriptionrdf:about="http://COOLHOME/Rules/test#RULE2"> <cool:ifrdf:resource="http://COOLHOME/States/test#STANDBY"/> <cool:thenMoveTordf:resource="http://COOLHOME/States/test#WARNING"/> </rdf:Description> <rdf:Descriptionrdf:about="http://COOLHOME/Rules/test#RULE3"> <cool:ifrdf:resource="http://COOLHOME/States/test#OFF"/> <cool:thenMoveTordf:resource="http://COOLHOME/States/test#ERROR"/> </rdf:Description> <rdf:Descriptionrdf:about="http://COOLHOME/Rules/test#CoFcRule1"> <cool:ifrdf:resource="http://COOLHOME/States/test#ERROR"/> <cool:thenMoveTordf:resource="http://COOLHOME/States/coda_states#CoDownloaded"/> </rdf:Description> <rdf:Descriptionrdf:about="http://COOLHOME/Rules/test#CoFcRule2"> <cool:ifrdf:resource="http://COOLHOME/States/test#WARNING"/> <cool:thenMoveTordf:resource="http://COOLHOME/States/coda_states#CoPrestarted"/> </rdf:Description> <rdf:Descriptionrdf:about="http://COOLHOME/Rules/test#CoFcRule3"> <cool:ifrdf:resource="http://COOLHOME/States/test#OK"/> <cool:thenMoveTordf:resource="http://COOLHOME/States/coda_states#CoActive"/> </rdf:Description> Vardan Gyurjyan. Jefferson Lab

More Related