RE: New standards for small and medium sized astronomical observatories

["Hill, Jeff" <johill@lanl.gov>]

Ø  as I understand EPICS is soft-real time

 

On an RTOS based IOC a hybrid approach is common where device driver threads are properly scheduled for essential time critical activities at a priority above the EPICS database processing. The record processing is scheduled next, and the Channel Access network activities are at the lowest priority. The pre-emptive RTOS scheduling provides proper types of degradation when the CPU is saturated. When I am designing a DAQ system I tend to place the time critical activities in a simple software that I can easily understand, and then after the data are properly packaged schedule them to lower priority threads.

 

My limited understanding is that KECK uses an interrupt driven EPICS record processing to maintain some of their time critical loops for many years now.

 

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

 

Nowadays large external memories are inexpensive so I am guessing that you are considering some type of integrated CPU chip with embedded RAM?

 

We run EPICS on the Altera FPGA embedded Nios2 softcore, which might qualify as bare metal and or low power consumption, depending on hardware choices. The amount of memory for the softcore is dependent on the size of FPGA external DRAM chip chosen; we chose 125 MB.

 

My configuration of the RTEMS netdemo application {compact real time kernel, network kernel } would not fit in 100KB, and this is sans EPICS.  The netdemo object code appears to require more like 500 KB. I believe that RTEMS has a reputation for being a fairly compact RTOS, but a complete implementation of the network kernel probably requires more space. I also have the c++ libraries and additional bells and whistles configured into RTEMS so YMMV.

 

Jeff

 

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Piotr Sybilski
Sent: Tuesday, July 08, 2014 4:41 PM
To: 'Dalesio, Leo'; tech-talk@aps.anl.gov
Cc: 'Grzegorz Lech'; 'Rafał Konrad Pawłaszek'
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