SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

CODA run-control

erno avatar
erno
16 diapositives · 354 Views · Sep 08, 2014

CODA run-control. JLAB DAQ Group V. Gyurjyan C. Timmer A. Smith New Horizons governor school. Run-control history. Eiffel C++ Java. Run-control design requirements. Extendable. Network distributed. Platform independent. Software centric. Flexible. Dynamic hierarchical.

CODA run-control - slide 1
01 / 16CODA run-control
1 / 17

Télécharger la présentation

CODA run-control
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. CODA run-control JLAB DAQ GroupV. Gyurjyan C. Timmer A. Smith New Horizons governor school

  2. Run-control history • Eiffel • C++ • Java

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

  4. Agent properties • Autonomy. • Proactive intelligence. • Adaptive intelligence. • Temporal continuity. • Mobility. • Rationality/benevolence.

  5. Multi - Agent approach • Distributes computational resource. • Accommodates legacy systems. • Peer-to-peer model. • Global coordination. • High performance.

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

  7. Run-Control Platform Architecture Communication through message passing. Message can contain any arbitrary objects. JVM1 JVM2 NODE3 HV hardware

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

  9. XML or RDF? • After all both are text constructs. • Duplet vs. triplet to transfer human knowledge. XML RDF Tag Value Resource Subject Predicate Property Object Value

  10. COOL taxonomy Subjects/Objects Predicates • Control • Component • Process • Command • Data • Node • Loop • Option • 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 • hasDataFile • hasDataLimit • hasEventLimit • hasTokenInterval • Splitmb • hasOption • hasComponent • acceptsComponent • hasScrupulosity • loopRepete • loopDelay • stopAt

  11. 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 >> B Process B >> isPartOf >> download B1 >> expectedOk >> Output String Process B >> hasProcess >> B1 Process B >> hasProcess >> Bn

  12. JAS data server description in COOL <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> <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>

  13. COOL GUI and knowledge auto-transfer from mSQL to COOL db2cool

  14. Run-control GUI

  15. Conclusion • New run-control is ready to be released. • 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.