Project

General

Profile

Incorporating IOCs » History » Version 10

Version 9 (Richard Neswold, 06/12/2019 01:44 PM) → Version 10/19 (Zongwei Yuan, 06/12/2019 01:50 PM)

h1. Incorporating IOCs

As of this page's creation date, it is generally accepted that we will officially support EPICS IOCs in our control system. The extent of the support isn't clear but, hopefully, documents like this will spur discussion. This document belongs to the whole department so please add comments, concerns, and corrections. I also encourage everyone to click on the "Watch" link so you get email notifications when this page is edited.

h2. Front-ends

ACNET-based front-ends aren't going away soon; it would be prohibitively expensive to replace every piece of hardware and we need to minimize the impact of operating the accelerator. That being said, there are efforts to upgrade systems to newer versions of VxWorks as well as migrating to Linux using the Erlang-based framework. Programmers preparing to upgrade should seriously consider using EPICS.

What needs to be done?

* Become proficient and knowledgable about EPICS
** We have scheduled training at the end of August (tentatively, 26th - 30th).
* Define (and create?) a build-environment for Fermilab's front-end programmer community
* Determine how IOCs fit our device model
** Do we augment our central database to include PVs?
** How do we manage IOC records?
*** option 1: (proposed by Tim Z)
**** It would be nice to have a tool that we'd use 'one time' to convert IOC records into DABBEL entries if someone delivers us an IOC to integrate
**** Going forward it would be nice to extend D80 & the central database to handle PV unique requirements and then generate all production IOC records out of the central database
**** Jim Patrick mentioned ESS does something along these lines. We can look at their implementation for inspiration.
*** option 2: (?)

h2. Central Services and Applications

Applications and services should be mainly isolated from the differences between ACNET and EPICS front-ends. Of course some apps will drill down through the layers to eventually reach specifics, but these would be the exception rather than the rule. Most applications are looking for accelerator data, which both styles of front-ends provide. The top, two tiers of the control system will use DPM, which hides these differences by providing a consistent API to obtain device data. This DPM API will use the yet-to-be-ratified [[drf:DRF3_RFC|DRF3]] format which slightly generalizes the device specification so that PVs fit naturally.

What needs to be done?

* DPM needs to support channel access so it can communicate with both types of front-ends.
* Finish the [[drf:DRF3_RFC|DRF3]] specification
* CLIB may need minor tweaks to support [[drf:DRF3_RFC|DRF3]].
* Services not using CLIB should migrate towards using DPM directly.
** Synoptic, for example
* Security schema needs to be discussed discussion and implemented, implementation, both for DPM and EPICS applications[1].

----

fn1. It should be noted that EPICS Applications (i.e. EDM, Control System Studio, etc.) are outside the discussion of this document. We're discussing IOC integration.