Re: New standards for small and medium sized astronomical observatories

[<Juan.Guzman@csiro.au>]

Dear Piotr,

The Monitoring and Control software system for the ASKAP radio telescope in Australia (http://www.atnf.csiro.au/projects/askap/index.html) is built based on EPICS technologies. You can find some more detailed description of the ASKAP architecture in the past ICALEPCS and SPIE conference papers. As others have mentioned here EPICS is not just a protocol is rather a set of tools built on top of the EPICS Channel Access protocol. Comparing EPICS with DDS and OPC-UA is not a direct fare comparison, as DDS is a specification of data transport and OPC-UA is also a protocol specification. EPICS through the community has to offer a lot of other tools such as Monitoring Archivers, GUI builders, logbooks, configuration databases, etc. putting EPICS more in line with SCADA packages rather than just communication middlewares and protocols.

EPICS (server side) can run on RTOS such as VwWorks and RTEMS. It also can run on low footprint SBC, SoC as long as you can put one of the supported RTOS or Linux. You can create EPICS “IOC” even on National Instruments hardware (using LabView).

In addition to Gemini, of my knowledge EPICS is being used at Keck, JCMT, UKIRT, WHT and recently I learned that it has been used at the “Observatorio Astrofisico de Javalambre (OAJ)” in Spain for their two optical telescopes. Also of my knowledge, ALMA is not using OPC-UA in their control system, instead they use ALMA Common Software and CANbus (as field bus to low level controllers). New instrumentation at the VLT is currently using OPC-UA as a protocol for the instrument control systems. CTA and E-ELT are looking into OPC-UA for their “standard” protocol between high-level control software and hardware (PLC or PAC).

I was also at the SPIE conference in Montreal and it is rather unfortunate that we could not meet face to face.

Feel free to contact me directly if you want to know more about our experience with EPICS.

Kind regards,

  Juan Carlos

Juan Carlos Guzman 
Head of ATNF Software and Computing
Astronomy and Space Science
CSIRO

E juan.guzman@csiro.au T +61 2 9372 4457 M +61 432 699 791 
PO Box 76, Epping, NSW, 1710 | Vimiera & Pembroke Rd, Marsfield, NSW, 2122 Australia
www.csiro.au | www.csiro.au/CASS

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.

From: Piotr Sybilski <sybilski@sybillatechnologies.com>
Organization: Sybilla Technologies
Reply-To: "sybilski@sybillatechnologies.com" <sybilski@sybillatechnologies.com>
Date: Wednesday, 9 July 2014 8:40 am
To: "'Dalesio, Leo'" <dalesio@bnl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Cc: 'Grzegorz Lech' <grzegorz.m.lech@sybillatechnologies.com>, 'Rafał Konrad Pawłaszek' <pawlaszek@sybillatechnologies.com>
Subject: RE: New standards for small and medium sized astronomical observatories

Dear Andrew, dear Lewis and dear Bob

First let me thank you for all your answers. I will try to comment on them below. I will start with Andrew's answer then Lewis' and Bob's.

 

It would be great to have a detailed study comparing all mentioned technologies. They seem to share a lot. However it seems that such a study does not exist and I couldn't find anyone who would use more than one of these technologies to ask her/him questions about the comparison outcome. So I ended up asking questions and will try to make the final decision based on as many facts as possible (hopefully with the smallest bias).

 

Andrew:

> I don't know how you measured those particular characteristics

The table is my personal and of course subjective impression I had after researching the subject of a new protocol for fault tolerant distributed control system.

 

> Since EPICS is not sold commercially its market share is by definition zero

Ok, I agree. I should use the term: "how widely is the technology used" (but it is still ambiguous, we can talk about number of developers, number of projects using it, cost of the projects based on it and so on, my market share question was a general term in which I wanted to know in which fields and how widely is OPC/DDS/EPICS used, I couldn't find many industrial projects based on EPICS, thus my market share rating was low).

 

> it does have quite a lot of users (not very many in the Astronomy community, but there are a few telescopes using it) and commercial companies who can support it

Could you point me to some web pages?

 

> What will be the on-going costs of supporting the other technologies, and how long will you be able to get support for them?

DDS standard is maintained by Object Management Group (25  years of promotion and standardization, CORBA for example). And here comes probably the main difference, as DDS can be used as a real time system, as I understand EPICS is soft-real time.

 

OPC UA is maintained by OPC Foundation (established in 1994 with some big companies supporting it) and is also an open standard for soft-real time.

 

OPC UA and DDS are open standards maintained by well-established multibody organizations with longer than 20 years history, so I suppose they are not going anywhere in next 5-10 years and backward compatibility will be assured (or possible with open source implementations of each standard, also available).

 

> EPICS should allow you to interface to almost any device you can purchase, using either common communications standards or a manufacturer's interface library. We also run on all the main operating systems and CPU architectures, and the Channel Access network protocol interoperates seamlessly between different architectures and software versions.

Could you point me to some example of embedded device with low resources (10K-100KB of memory, 8-bit processor, preferably bare metal distribution), that supports the EPICS? I know that I am pushing the limits, but the optimization (low power consumption) is an important factor for us.

 

And what about communication security, is it possible to authenticate EPICS agents with certificates?

 

Lewis:

> I would say EPICS should get a "very good" for support.

Judging by the quick and detailed response to my question, I would agree :) But for the sake of my study I also need some information about commercial support that Andrew's has mentioned. I also noticed that for example there are few companies working with OPC UA in Poland (and I couldn't find anything for EPICS).

 

> I don't think "Internet of Things" support should be a criteria for choosing your control system framework.

That is probably my bias because I am working also on a project design which should be tagged with this "buzz word" (for the lack of better name). I can really see a great potential in small embedded devices providing us with data and functionality we didn't think about before. This will drive the development of smaller, more efficient platforms supporting better and optimized software implementations. And by this the development of protocol for data exchange and control.

 

> As far as "future," I would say that EPICS is likely to have a long future since it is used heavily at various synchrotron light sources.

Yes, it's used in other areas too, and I think that's good, but the light source adoption alone should make it a good bet in terms of longevity.

That is a good point, as we are looking for solutions that should last more than 10 years.

 

Bob:

>Look at the V4 web site for ideas about a road map.

The most recent information on that I found is:

http://epics-pvdata.sourceforge.net/talks/2011/EPICSv4roadmap.pdf

or am I missing some important part?

 

> We are becoming clear on what is needed to support high level experiment control, data acquisition, data analysis, model based control, and standard services and prototypes of all of them are either deployed or in development.

I think that may be the biggest difference (as all three technologies seem to be data oriented), that EPICS provides full or very consistent package for running the physical experiments in terms you mentioned. Which has pros and cons (pros as we can use familiar environment and software/coding style on many layers of software architecture and cons as some parts of the system may be not easy to replace by other technologies).

 

Could you tell me something about the support for redundancy 1+1, failover, voting and similar fault tolerance patterns in EPICS (as a protocol for data exchange and as a control system).

 

> It may be useful to attend an EPICS meeting if you are truly interested in the completeness of this table.

That would be great, but I must finish my research by the end of the week. And I learned about EPICS only a week ago during a SPIE conference. From my basic survey there where 3 projects presented using OPC UA (for example ALMA - Atacama Large Millimeter Array, CTA - The Cherenkov Telescope Array), two using DDS (for example Very Large Telescope, LSST - Large Synoptic Survey Telescope) and one using EPICS (Gemini).

 

Best regards

Piotr

 

From: Dalesio, Leo [mailto:dalesio@bnl.gov]
Sent: Tuesday, July 8, 2014 11:45 PM
To: sybilski@sybillatechnologies.com; tech-talk@aps.anl.gov
Cc: Grzegorz Lech; 'Rafał Konrad Pawłaszek'
Subject: RE: New standards for small and medium sized astronomical observatories

 

Open source and a large community of developer’s and uses may be an important factor for a scientific facility that needs to run for 25 years. I don’t know about the other two, but EPICS has a very active and supportive community with companies and scientific facilities that offer support to others in the community.

Look at the V4 web site for ideas about a road map. We are becoming clear on what is needed to support high level experiment control, data acquisition, data analysis, model based control, and standard services and prototypes of all of them are either deployed or in development.

It may be useful to attend an EPICS meeting if you are truly interested in the completeness of this table.

Bob Dalesio

 

From:tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Piotr Sybilski
Sent: Tuesday, July 08, 2014 10:43 AM
To: tech-talk@aps.anl.gov
Cc: Grzegorz Lech; 'Rafał Konrad Pawłaszek'
Subject: New standards for small and medium sized astronomical observatories

 

Dear Madam/Sir

I am researching a subject of decoupling hardware and software components in small and medium sized astronomical observatories (up to 2.0 m): removing single point of failures (USB, RS232), introducing new standards and increasing the reliability and availability of observatories. I am software developer and architect for Project Solaris (4 autonomous observatories on 3 continents) and a start-up company working on control software. After a long research and many discussions within the community, we ended up with three solutions on the table:

-          DDS,

-          OPC UA,

-          EPICS.

 

My personal opinion can be summarized in this small table:

	DDS	OPC UA	EPICS
learning curve	steep	steep	steep
price for start-up	good	high	free
feature set	large	very large	very large
Support (community/commercial)	very good	very good	good
market share	high	very high	low
internet of things/future	well established	very well established	unknown
low memory/CPU devices support	good	very good	fair
Roadmap	clear	Clear	unknown

 

The table doesn’t show the clear winner but emphasizes that the DDS and OPC UA have brighter future, higher market share and better support. However I am not very familiar with EPICS, so I am probably missing a few points. Could you point me to the sources or give me more information on the comparison DDS vs OPC UA vs EPICS? During the last SPIE conference in Montreal I finished with votes (projects working and being happy with) 3 for OPC UA, 2 for DDS, 1 for EPICS and 1 for ZeroMQ.

 

I would be grateful for pros and cons of each technology that you can provide (our typical astronomical observatory consist of tens of devices, some of them redundant, real time communication is not required but quick event propagation and QoS is welcomed, some devices are simple sensors, some simple actuators, there are few devices that can produce bursts of data, for example CCD camera can produce 200 MB in one second, the data doesn’t have to be propagated through the system immediately, but shouldn’t choke the communication, some kind of prioritization is welcomed).

 

Best regards

Piotr Sybilski