Re: 2026 white paper on EPICS vs commercial SCADA software

[Diego Omitto via Tech-talk <tech-talk at aps.anl.gov>]

Javi,
Thanks for the reply. The IOC restart clarification makes sense.

On OPC-UA, I understand the scoring better now, native support without a bridge or gateway. However, I'd still gently push back a bit there. The ITER gateway is mature and actively used; it just doesn't come from a vendor. Scoring that lower than something shipped natively feels like it's measuring delivery model more than actual capability, even if that wasn't the intent.

Thanks too for clarifying the legacy point, that the assessment is about the cost of maintaining custom developments over time rather than the framework itself. That makes sense, though I'd argue that risk isn't unique to EPICS. Any heavily customized deployment, commercial or open source, carries some version of that same dependency on specific people and institutional knowledge. "Legacy" still feels like a strong word for what's really a maintenance and staffing consideration.

I think this is really the heart of it for me. The paper, read in full, is more careful and nuanced than Figure 3 or Table 3 suggest on their own. But those figures are exactly what's being lifted out and circulated internally as standalone evidence, without the surrounding discussion or caveats. That's not really something you can control once a paper is out in the world, but it's worth knowing how it's landing outside the academic context it was written for.

Really appreciate you taking the time to engage with the community on this directly. This kind of open discussion is exactly what keeps these comparisons useful and grounded, rather than getting reduced to a couple of figures out of context.

Cheers,

Diego

On Tue, Jun 30, 2026 at 6:12 AM Javier Cruz Miranda via Tech-talk <tech-talk at aps.anl.gov> wrote:

Dear colleagues,
I am one of the authors of the paper to which you refer. Thank you for your interest in our work. I would like to offer a few clarifications that I hope may be useful.

None of the authors belong to the DONES consortium. Our positions are purely academic. We have no corporate interest, preference, or external support of any kind. Despite the long tradition of some of the authors in open software and hardware communities, we have endeavored to provide unbiased results while avoiding oversimplification of the many challenges addressed in this contribution.

Our work was developed within the scope of WPENS under the EUROfusion framework and, as such, is limited to research, comparative studies, proposals, feasibility and proof-of-concept tests in areas of possible interest to IFMIF-DONES. These kinds of activities are complex, technically and methodically speaking but valuable discussions to continue the advancement of science and technology. Their outputs can offer nuanced analysis that the engineers responsible for the final design of the DONES control system may or may not find useful, as they see fit.

The context of the comparison is important. Using the control systems of that facility as baseline case, this study focuses particularly on the requirements and needs of the central CODAC system, which in that case comprise services such as monitoring/HMI, alarm and data management, etc. We fully agree that the knowledge gained and experience in this project and in LIPAc are fundamental. This was taken into account, and precisely this is one of the reasons why this study concludes by suggesting a hybrid architecture of control systems, using an industrial SCADA system for the central monitoring and control, while keeping EPICS at the local control level in order to benefit from the best of both worlds. This hybridisation of EPICS with industrial SCADA systems is, in fact, one of our main lines of research, and it is illustrated in some of the publications referenced in the article.

The conclusions were not reached by the authors alone. The evaluation reflects the opinions and experiences of vendors, development companies, and users consulted across a wide range of expertise, including people with long experience in both EPICS and industrial SCADAs. A voting system was used for all criteria to mitigate individual bias. The scores were not binary; they expressed assessments based on availability of options, ease of implementation, maturity of native support, and similar factors. It is also worth noting that most of the scores do not concern EPICS Base itself, but rather other components of the ecosystem and integration considerations.

A few brief technical clarifications in response to specific comments:
-    Regarding OPC-UA: the EPICS Device Support module for OPC-UA is an excellent tool that has, in fact, inspired much of our own work. The criterion in the study assessed whether a framework provides native support for this protocol without requiring a separate bridge, gateway, or custom development. In fact, what the point of the considered rq list really assessed was the possibility of using industrial and market standards in general; OPC UA being one of them.
-    Regarding the IOC restarts comment: this referred to structural or configuration changes, not to property value updates, which we are aware can be handled through the mentioned mechanisms. In any case, this point carries limited weight in the overall conclusions.
-    Most of our laboratory setups are built on EPICS 7 and pvAccess, and we are well aware of the significant progress they represent. The a ssessments in some questions concern not the technical quality of the framework, but the practical implications of maintaining custom developments over time, including challenges related to updates, support, and dependency on specific individuals or software versions. We are aware that customizations are needed in these scientific and particular scopes and, as said, one of our lines of research is directed precisely at integrating such custom solutions with industry standards, to facilitate the adoption of new technologies; key specially when we talk of small-medium facility with limited engineering resources.

Finally, as a personal opinion: the fact that some industrial solutions score higher in certain functional areas does not diminish EPICS. If anything, I think that studies of this kind can help identify areas where new lines of work — on interoperability, maintainability, or total cost— may be worth pursuing. These are dimensions that purely technical comparisons do not always address adequately.

Thank you again for your interest and for the constructive nature of the discussion.

Kind regards,
   Javi.

---
Javier Cruz Miranda
University of Granada

 

---------- Forwarded message ---------
De: Diego Omitto via Tech-talk <tech-talk at aps.anl.gov>
Date: mié, 24 jun 2026 a las 20:20
Subject: Re: 2026 white paper on EPICS vs commercial SCADA software
To: Evans, Richard K. (GRC-H000) <richard.k.evans at nasa.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>

Subject: Re: Comparative SCADA evaluation - IFMIF-DONES paper

Hi Rich,

I read the paper and have a few specific concerns.

I noticed a factual error in the operational critique: the authors claim that changing a variable property in EPICS requires restarting the IOC database. Runtime field modification via caput, dbpf, and autosave/restore is standard practice. This is not a minor point. If the evaluators did not know this, the scoring in Table 2 reflects unfamiliarity with the framework, not its actual capabilities.

This also undermines the paper's characterization of EPICS as a legacy framework. EPICS 7 introduced PVAccess as a first-class protocol with structured data types, high-throughput streaming, and normative types that go well beyond what OPC-UA offers in accelerator contexts. The ecosystem around it is actively developed.

More damaging to the paper's credibility: it cites the ITER OPC-UA/EPICS gatewa y as prior art for the CODAC-MPS integration problem, then penalizes EPICS in the scoring for limited OPC-UA support. The solution they acknowledge exists was excluded from the evaluation.

Finally, the paper does not address the most obvious question: LIPAc, the direct operational prototype of IFMIF-DONES, runs EPICS. I don't see an explanation for why a framework adequate for the prototype is suddenly inadequate for the full facility.

That omission says more about the motivation behind this study than the scoring does.

Best,
Diego

 

On Wed, Jun 24, 2026 at 1:29 PM Evans, Richard K. (GRC-H000) via Tech-talk <tech-talk at aps.anl.gov> wrote:

Dear EPICS community,

I recently came across a new whitepaper that present a comparative evaluation of EPICS against various commercial SCADA platform alternatives. The evaluation uses a set of requirements that they state are representative of the IFMIF-DONES plant currently being constructed in Escúzar, Granada, Spain.  The paper is linked below.  If you have a moment and are inclined, please take a look at Table 2 and Figure 3 and let me know if you feel that EPICS has been rated accurately/fairly.

"A comparative study of industrial and open-source SCADAs to optimize the design of control systems for the IFMIF-DONES plant"
https://urldefense.us/v3/__https://www.researchgate.net/publication/403928088_A_comparative_study_of_industrial_and_open-source_SCADAs_to_optimize_the_design_of_control_systems_for_the_IFMIF-DONES_plant__;!!G_uCfscf7eWS!dLrszc_F4-MNU6rvR6_tBzD-oxGJWgrejzopanOX1p9BNsJxyEPjxFevbkdTX0hdTvbTDWos84abzN6ViuHnARMNORgosr0r$

Note - Figure 3 shows EPICS as seriously deficient as compared to commercial SCADA software, but then I saw what they said on Table 2 requirement #17 wrt video and it doesn't seem like they fully understood EPICS well enough to give it an honest rating. 

The paper is being circulated within my organization as strong evidence that EPICS is a poor option as a control system SCADA for a facility.  Any insights this community can provide in explaining the possible motivations of  the authors and/or highlighting any clear bias or incorrect assessments that the paper may contain would be much appreciated.

Thanks in advance.
- Rich Evans
  NASA Armstrong Test Facility
  Sandusky, Ohio