1. AGENT BASED FRAMEWORK FOR EXPERIMENT CONTROL SYSTEMS … JEFFESON LAB V. GYURJYAN, D. ABBOTT, G. HEYES, E. JASTRZEMBSKI, C. TIMMER, E. WOLIN AFECS

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 Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

3. SOA and intelligent agent technologies

4. SOA Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Style of building reliable systems that deliver functionality as services Loose coupling between interacting services

5. Service Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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.

6. Service interaction Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Service Registry Service Provider Service Consumer Discover Advertise Interact

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

8. SO vs. OO Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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 “Hello World” OO SO Object Service SayHelloWorld “Sorry I am busy”

9. Agent is a service Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab creative adaptive mobile social persistent Goal-oriented Agent

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

11. What does it mean? Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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)

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! Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

14. publisher publish subscriber subscribe cMsg system subscribe Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

15. publisher publish subject “x” subscriber subscribe cMsg system subscribe subject “x” publisher subject “x” publisher subject “x” Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

16. Publish Subscribe Publish Subscribe Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab cMsg Server cMsg based P2P Point 1Point 2

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 Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

18. #include // 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); To send a cMsg message Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

19. #include // 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… To receive a cMsg message Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

20. class myCallback : public cMsgCallback { void callback(cMsgMessage *msg, void* userArg) { cout getSubject() << endl; } }; Where callback is: Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

21. Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

22. Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

23. ECS framework design criteria

24. Project Goal Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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.

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

26. Design Philosophy of AFECS Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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.

27. AFECS Agent Categories Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Normative agents administrative agent  Crate and manage all other agents  Environment administration Supervisor agents Control groups of Component agents Component agents Represent hardware or software components of the real world control system. N S A

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

29. Inter-Process Communication Channels Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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)

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

31. Agents Groupings Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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 each domain may be visible to other domains. S AAAA S S NSA

32. Domain Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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)

33. AFECS Platform Distribution Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Agents are physically distributed  at the configuration time  at runtime S AAAA S S N

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

35. Physical Component Integration Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Component Fred NC NA NR Agent Fred Description of the control Administrative domain and container AFECS platform

36. DESIGNING A CONTROL SYSTEM REQUIRES PRECISE DESCRIPTIONS OF PHYSICAL COMPONENTS AND THEIR SOFTWARE ABSTRACTIONS. COOL - Control oriented ontology language

37. Control Oriented Ontology Language Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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.

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

39. No really what is an Ontology? Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab 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.

40. Philosophy of Knowledge Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Knowledge we have Knowledge we know we don't know Knowledge we are not aware we don't know

41. Formalized Knowledge Subject Ontology Domain Ontology Taxonomic Knowledge Process Ontology Relational Knowledge Interface Ontology Assertional KnowledgeMonday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab D2 D4 D5 D6 D7 D8 D9 D1

42. Domain Ontology Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab A novel and poem are books. A book is a document. document book novelpoem Domain Ontology Taxonomic Knowledge

43. Process Ontology Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab A document author is a woman. documentwoman Process Ontology Relational Knowledge author

44. Interface Ontology Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab documentwoman Process Ontology author womanstring Process Ontology name documentstring Process Ontology author

45. RDF: Resource Description Framework RDF is best suited to formalize triple structure of the knowledge base. Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Tag Value XMLRDF ResourcePropertyValue SubjectPredicate Object

46. Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

47. Example Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

48. Example States FSMS1_Ok 1 FSMS1_Warning 5 FSMS1_Error 10 Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

49. Example States off on standby Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

50. Example Rules Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

51. AFECS COOL Specific Tools Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab GUI using COOL to build configuration files describing control system. db2cool: converts current CODA config database to COOL config files. sml2cool: translates state manager language config files to COOL config files.

52. COOL editor view 1 Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

53. COOL editor view 2 Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

54. One other COOL Example Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab <rdf:RDF' xmlns:cool='http://coda.jlab.org/COOL/cool#' > false /tmp/test.dat cMsg ROC Roc1 44 cMsg RCS R1ExternalProcess 77 shell predownload emacs

55. AFECS Implementations Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab New run control for the JLAB data acquisition system. (V. Gyurjyan, et al. “Jefferson Lab Data Acquisition Run Control System”, Proceeding of the CHEP conference. CERN-2005-002, Volume 1, page 151.) CLAS experiment web based monitoring system. http://clasweb.jlab.org/clasonline/rc/hallB/e-cr.htm http://clasweb.jlab.org/clasonline/rc/hallB/e-cr.htm

56. Run-Control GUI view 1 Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

57. Run-Control GUI view 2 Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

58. Afecs message browser Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab

59. Conclusions Monday, October 19, 2015 Vardan Gyurjyan. Jefferson Lab Java based framework for designing and implementing hierarchical, distributed control systems with intelligent agents. Encourages abstraction, encapsulation, and modularity. Provides a special ontology language (COOL) to describe hierarchical control structure, control logic, and state machines. Has been successfully used to develop run control system for the JLAB data acquisition system, and CLAS experiment web based monitoring system.