Development of
MQTT-Channel
Access Bridge
Jiro Fujita – Creighton University/STAR Experiment1

STAR ExperimentuSolenoidal Tracker At RHICu

Relativistic Heavy Ion Collideru

Brookhaven National Laboratory,Upton, NY, USAu

EPICS is used for the control for themost subsystems from the beginninguu

Mostly EPICS 3.14, but some in older
version…

Control & Monitor roughly 40,000
operating parameters

Image from RHIP Group at UT Austin: http://www.rhip.utexas.edu/

2

MQTT: Message Queue
Telemetry TransportuOriginally developed by IBM and Eurotech in 1999u

IBM & Eurotech donated MQTT to Eclipse project in 2011u

MQTT v3.1.1 is ISO standard as of 2016 (ISO/IEC PRF20922)

uRuns on top of TCP/IP (as well as UDP and ZigBee)u

Relatively simple and easy to write/work withu

Lightweight & low overheaduQuality of Serviceu

Nearly Real-Timeu

Widely used by Internet of Things (IoT) and other placesu

Very different from Channel Access3

MQTT Conceptuu

Message BrokeruActs as a central communication
pointuCan be authenticatedClientsuPublishuu

SubscribeuuDevices could also subscribe to specific information/data (topic)

Topicuu

Devices publish specific information/data (topic)

Routing information to the broker (e.g. “Status”, “Voltage”, “TPC”,“Beamline1”)

Messageu

The “data” that clients publish/subscribesuOnly in ASCII format

4

MQTT Quality of Serviceu

MQTT has concept of Quality of Service (QoS) built-inuuu

QoS0u

It only guarantees a best effort of deliveryuEssentially, no checking

QoS1u

Guarantees at least delivered onceu

It could be delivered more than once

QoS2u

Guarantees delivered once and once onlyu

Safest, but slowest, as requires extra confirmation
Images from HiveMQ: MQTT Essentials
http://www.hivemq.com/blog/mqtt-essentialspart-6-mqtt-quality-of-service-levels
5Motivation & RequirementsuSTAR had adapted DAQ/Offline/Slow Control integration
based on MQTTuCurrent Slow Control is based mostly on EPICS since thebeginning of the ExperimentuuSomebody had to write something to bridge EPICS Channel
Access and MQTT in both direction

EPICS stays as it is for the existing control systems

6

Motivation & Requirements(part 2)uGeneral concept of what has beenproposed at STAR Experimentu

Slow Control resides in STAR protected
network in this diagramu

Send/Receive MQTT messages in JSONu

Receive/Send Slow Control Data inChannel Access

Image from “Bridging EPICS and High-Level Services at STAR”
https://drupal.star.bnl.gov/STAR/comp/db/development/epics_dcs

7Tools used & rationalu

C (or C++)
uuuuu

This was a request from the DAQ expert to the control group

Paho LibraryuAppears to support C/C++ fairly wellu

http://www.eclipse.org/paho

JSON parser libraryu

The message content is in JSON formatuhttps://github.com/json-c/json-c

Apache ActiveMQ Apollo for the message brokeru

The Offline/DAQ integration has already been using Apollo as the message brokeruhttps://activemq.apache.org/apollo

MQTT.fxu

To check MQTT status easily from the office computeru

http://mqttfx.org

8

The first prototype…
u

Written in about 2 weeks, including setting up thebroker and MQTT test programsu

No prior knowledge/experience of MQTTuFairly easy to write a program using MQTTu

Two different componentsuu

Publisher — Channel Access to MQTTu

Subscriber — MQTT to Channel AccessSingle Topic (EPICS_CA) is used for now9Publisher Componentu

Publishes Channel Access data to MQTT brokeru

Written in C using Portable Channel Access libraryuSends Channel Access data in MQTT in JSONuu

EPICSIOCChannelAccess{ "PV": "PVname", "Host": "Hostname", "data": "PV value"}
Host field is needed, as MQTT does not necessary know
where the data really comes from (not really needed inChannel Access)record(ai, "sysuser:aiExample"){field(INP, "sysuser:calcExample.VAL NPP NMS")
field(HOPR, "10"){field(LOPR, "0")"PV": "sysuser:aiExample",field(HIHI, "8")"Host": "epicsIOC1",field(HIGH, "6")
"data": "10 "field(LOW, "4")
}
...
...
sysuser:aiExample.VAL}
Publisher brigde

MQTTBroker
MQTT10Subscriber Componentu

Subscribes data from MQTT broker to EPICS IOC

uWritten in C using Portable Channel Access libraryu

Receives MQTT in JSON, broadcasts in Channel Accessuu{ "PV": "PVname", "Host": "Hostname", "data": "PV value"}
Host field is needed, as MQTT does not necessary know
where the data really comes from (not really needed inChannel Access)

MQTTBroker
MQTT{"PV": "sysuser:aiExample","Host": "epicsIOC1","data": "10"}record(ai, "sysuser:aiExample2"){field(HOPR, "10")field(LOPR, "0")field(HIHI, "8")field(HIGH, "6")field(LOW, "4")...
sysuser:aiExample.VAL...
}

Subscriber brigde

EPICS
IOC
Channel Access11Performance Testingu

Testing was done in sending thousands of MQTT data and/or
Channel Access data per secondsuSeveral computers were involved (all in the local network,some in different subnet)u

EPICS IOC host computersuu

Computer running MQTT bridge programsu

MQTT data sender/receiver computer running simple MQTT
publisher/subscriber program written in Node.jsu

MQTT broker (Apache Apollo) computer in different subnet

u

MQTT monitoring computer (aka my office computer)uu

More than one IOC computers were used for testing

not really needed, but convenient to have one

It appears to withstand both directions at least up to about1000 data/second or sou

Not very quantitative measure, as I had no idea how toquantify the number easily, as there are many different
factors involved (computer performance, network speed, etc)12

Future Planu

Rewrite with C++ using CAFE from PSI/SLSu

Possibly easier to write a code in C++ using CAFE thanportable Channel Access in Cu

Fuse publisher and subscriber into one programuOffline/DAQ group wants use MQTT to view the Slow
Control status via a web browser (and possibly evencontrol in some cases)u

Yet to be tested for real system…

u

Code is available upon request

13

AcknowledgementuUS Department of Energy Office of Science

uSTAR CollaborationuCreighton University College of Arts & Science14