jlab data acquisition run control system
DESCRIPTION
JLAB Data Acquisition Run Control System. Jefferson Lab Vardan Gyurjyan. Run-control history. Eiffel C++ Java. Run-control design requirements. Extendable. Network distributed. Platform independent. Software centric. Flexible. Dynamic hierarchical. - PowerPoint PPT PresentationTRANSCRIPT
JLAB Data Acquisition Run Control System
Jefferson Lab Vardan Gyurjyan
Run-control history
Eiffel C++ Java
Run-control design requirements
Extendable. Network distributed. Platform independent. Software centric. Flexible. Dynamic hierarchical. Synchronization via message passing. Real-time hardware actions and knowledge
processing.
Maintainable code replicating the old run-control functionality.
Integration with the detector control and legacy software systems.
Agent properties
Autonomy. Proactive intelligence. Adaptive intelligence. Temporal continuity. Mobility. Rationality/benevolence.
Multi - Agent approach
Distributes computational resource. Accommodates legacy systems. Peer-to-peer model. Global coordination. High performance.
FIPA- Foundation for Intelligent Physical Agents
FIPA framework (http://www.fipa.org). FIPA is a specification NOT an implementation. Directory Facilitator (DF). Agent Management System (AMS). Agent Communication Channel (ACC) . Java Agent DEvelopment framework (JADE) -FIPA
specification JAVA implementation (http://sharon.cselt.it/projects/jade).
Run-Control Platform Architecture
Run-Control Front-End Component Container
NODE 1 NODE 2
RMI Registery
ACC
Co
rte
x
He
pa
tic
Run configuration file.COOL format.
Java RMI
Java DPvxWorksCoda_roc
Communication through message passing.
JVM1 JVM2
Message can contain any arbitrary objects.DF AMS
Stemcell
GU
I Age
nt
Stem
cell
RO
C 1
Thalamus
NODE3
GU
I Age
nt
Java RMI
Slow
Con
trol
GU
I
Slow Control Configuration.COOL file
Stem
cell
HV
Agen
t
HVhardware
COOL- Control Oriented Ontology Language
Based on RDFS (Resource Definition Framework Schema). Control domain knowledge creation and reuse. Knowledge base sharing. Domain knowledge and operational knowledge separation. Domain knowledge analyses. Extensible via XML-namespaces and RDF modularization.
XML or RDF?
After all both are text constructs. Duplet vs. triplet to transfer human knowledge.
Tag Value
XML RDF
Resource Property ValueSubject Predicate Object
COOL taxonomy
Control Component Process Command Data Node Loop Option
Subjects/Objects Predicates
hasOption hasComponent acceptsComponent hasScrupulosity
hasComponentName hasComponentType hasPriority hasProcess Differentiate hasSession hasRunType hasCode hasNode hasFirst hasNext hasInput hasOutput
resultNotify acceptData acceptStatus hasCommand hasCheckWith isPartOf hasData
hasCommandName hasCommandType hasExpectedOk hasTimeOut hasLoop returnData inputdata
hasDataContent hasDataType hasDataCardinality hasTimeStamp hasSemantics
hasNodename hasIP isLocal hasUser hasPasswd
loopRepete loopDelay stopAt
hasDataFile hasDataLimit hasEventLimit hasTokenInterval Splitmb
Extending run-control state machine
Any control process can be defined as a CODA component. Every component can have associated processes. Each process can be attached to the CODA standard state machine transition by means of
isPartOf COOL predicate. COOL process is RDF subclass of the COOL component. Every process has associated COOL command. COOl command can have expectedOk predicate.
Control A >> hasProcess >> BProcess B >> isPartOf >> download
Process B >> hasProcess >> B1
Process B >> hasProcess >> Bn
B1 >> expectedOk >> Output String
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#' xmlns:cool='http://ankaa.jlab.org/~gurjyan/COOL/cool#'>
<cool:Control rdf:ID="JasDataServer"> <cool:hasCategory rdf:resource="http://ankaa.jlab.org/~gurjyan/COOL/cool#internal"/> <cool:hasDependency rdf:resource="#JDSDependency"/> <cool:hasProcess rdf:resource="#StartServer"/> <cool:hasProcess rdf:resource="#MonitorHistogram"/></cool:Control>
<cool:Dependency rdf:ID="JDSDependency"> <cool:hasHardware rdf:parseType="Resource"> <cool:hasIP>129.57.167.14</cool:hasIP> <cool:hasNodeName>clon10.jlab.org</cool:hasNodeName> </cool:hasHardware> <cool:hasLibrary rdf:parseType = "Resource"> <cool:hasName>jas.server.HistogramServer</cool:hasName> <cool:hasLocation>/usr/local/clas/jar/jas.jar</cool:hasLocation> <cool:hasName>hep.analyses.Histogram</cool:hasName> <cool:hasLocation>/usr/local/clas/jar/hep.jar</cool:hasLocation> </cool:hasLibrary> <cool:environment>JAVA</cool:environment></cool:Dependency>
JAS data server description in COOL
<cool:Process rdf:ID="StartServer"> <cool:hasTransaction rdf:parseType="Resource" > <cool:operationType rdf:resource="http://ankaa.jlab.org/~gurjyan/COOL/cool#construct"/> <cool:fnactionName>HistogramServer</cool:functionName> <cool:hasInput rdf:parseType="Resource"> <cool:Type rdf:resource="http://ankaa.jlab.org/~gurjyan/COOL/cool#string"/> </cool:hasInput> </cool:hasTransaction> <cool:repeat>1</cool:repeat></cool:Process>
<cool:Process rdf:ID="MonitorHistogram"> <cool:hasTransaction rdf:parseType="Resource" > <cool:operationType rdf:resource="http://ankaa.jlab.org/~gurjyan/COOL/cool#construct"/> <cool:fnactionName>Histogram</cool:functionName> <cool:hasInput rdf:parseType="Resource"> <cool:Type rdf:resource="http://ankaa.jlab.org/~gurjyan/COOL/cool#string"/> </cool:hasInput> </cool:hasTransaction> <cool:hasTransaction rdf:parseType="Resource" > <cool:functionName>fill</cool:functionName> <cool:hasInput rdf:parseType="Resource"> <cool:Type rdf:resource="http://ankaa.jlab.org/~gurjyan/COOL/cool#long"/> </cool:hasInput> </cool:hasTransaction> <cool:hasCategory rdf:resource= "http://ankaa.jlab.org/~gurjyan/COOL/cool#ondemand"/></cool:Process>
</rdf:RDF>
COOL GUI and knowledge auto-transfer from mSQL to COOL
db2cool
Run-control GUI
Conclusion
Extended graphing and monitoring capabilities. Backwards compatibility between old and new run configuration files. Agent platform administration and fault tolerance. Integration of the foreign processes through DP, vmeServer and Shell interfaces. Process abstraction has been implemented through the newly developed control
oriented ontology language.
Future plans
Integration of the EPICS processes through the channel access interface. Integration of the CAEN HV control systems through the CAEN OPC server
interface. Develop agent supporting JXTA peer to peer specification. Run-control web interface.