EPICS .NET is the Experimental Physics and Industrial Control System toolkit for .NET Framework 4.0 and above. It is an open-source, distributed control and computing library (source code at GitHub) that I have developed during my work as the lead developer of T.A.C. control & computing systems. Written in C#, this control toolkit consists of three sub components: EPICS .NET Library, EPICS Simulator, and User Interface.
The EPICS .NET is a library based on Microsoft .NET Framework, which provides connectivity options for an entire control network with the publish/subscribe paradigm within a client/server architecture. This library is in full compliance with Argonne National Laboratory's C based EPICS implementation and its channel access protocol. In addition, the library contains many more innovations, which help utilize modern network hardware. The EPICS simulator is used to simulate, Turkish Accelerator Center IR Free Electron Laser, which is essentially a particle accelerator, meant to create very intense laser light. With this simulator, the full functionality of the control network and accelerator operation can be simulated with a certain degree of physical reality. Finally, the user interface serves as the human-machine interface to operate an entire control system build upon EPICS .NET. I have used this toolkit throughout the T.A.C. IR-FEL project while designing and developing the entire control system (see here). The rest of this article describes the concepts of distributed control, publish/subscribe paradigm, etc. and EPICS .NET project's foundation on top of these concepts. You will also find videos, use cases for the particle accelerator simulator, and control system user interface, developed along with this distributed control and computing library.
Distributed computing requires low latency and high-speed node-to-node communication. Normally this would require source and destination node IPs to be known by the application at the run time. To remove the burden of dealing with node IPs and resource IDs (or the GUIDs) of the programmer, EPICS .NET Library was developed for this project. This library deals with all the low-level details of TCP/IP and UDP connections between nodes, beaconing, broadcasting, packet transmission and losses, and many more of small but critical functions of distributed computing. Abstracting away all the low-level technical details, developers can focus on the functionality rather than heft technical issues. This library is essentially a .NET Framework compatible version of conventional EPICS (Experimental Physics and Industrial Control System) libraries and tools. On the other hand, it is not a direct port of legacy EPICS. Since the latest major release of EPICS, software was almost 10 years ago and continuous advances in computer sciences resulted in new and innovative technologies. One of the most important of those technologies, Microsoft .NET Framework, makes up the foundation of this brand new distributed control and computing library. Leveraging the full potential of .NET Framework, EPICS .NET Library makes use of many essential tools like Windows Communication Foundation for communication routines, PLINQ and Task Parallel Library for task and data parallelism, ADO.NET and Entity Framework for distributed database tasks, ASP.NET for data publishing, and many more of libraries that are offered natively with the framework. In addition, many of the programming techniques offered by the CLR (like generic programming for type safety or extension methods and classes for backwards compatibility) and advanced C# programming constructs and language features are used throughout the library. The library is written purely in C# with 100% managed code thus maintaining full CLI compatibility. This way, along with this library any available .NET programming language can be used (C#, Visual Basic, C++/CLI, LISP .NET, IronRuby, IronPhthon, and many more). This library is fully compliant with .NET Framework 4.0 and upcoming Mono 2.8 with minor modifications.
EPICS .NET Library uses a typical soft real-time distributed computing model. One major concern of building a real-time system on a system that runs on CLR which behaves just like the Java virtual machine, with lots of memory garbage collection going on randomly, was unpredictable pauses in the runtime engine due to garbage collection. This concern is pretty much eased with the introduction of garbage collector notifications in .NET 3.5 SP1, which gives the opportunity to pass on the control tasks to other control nodes or local applications instances in the face of an upcoming garbage collection session. In addition, the background garbage collector introduced in .NET 4.0 eliminates the random pauses in the applications threads with some minor limitations.
The distributed computing model used by the EPICS .NET Library should not be confused with parallel computing. In a parallel computing system, a single workload is distributed to a farm of computers, which is totally separate from what this library uses. EPICS .NET distributes the center of operation (i.e. the brain of the system) to separate nodes in order to maintain scalability and fail-safety. The task parallelism is achieved locally on each node using the System.Threading.Tasks.Parallel library thus quad core processors of nodes are utilized at full capacity. Note that each node runs its own copy of the library at its private memory space and processor. There is no shared memory system is involved in the system, this way the failure of a node does not disturb the operation of the rest of the system. With the absence of shared memory, each node communicates via passing messages to each other.
EPICS .NET Library fall in the client-server model of distributed computing architectures. Each input/output controller node is turned separately into clients and servers so each node is capable of requesting or sending information. Each system resource can be published on the EPICS network (which is a TCP/IP connection for node-to-node communications and UDP connection for beaconing and broadcasting). What is described by a resource may be the CPU usage data or the memory usage statistics or a signal flowing through an analog/digital converter attached to the system. Since the library uses publish/subscribe messaging paradigm for passing messages on the network any input or output signal collected or created by the input/output controllers can be published on the network with a unique identifier. Consequently, any node wishing to monitor a data for changes just needs to be aware of that resource’s unique identifier. This removes the need from the accessors to know the IP address of the target node or the GUID or the resource to be accessed. Therefore, within the EPICS network, each resource is a freely floating entity where each node may monitor for changes or use the resource’s data for internal calculations. Once the network is flooded with freely floating resources, it closely resembles a database with freely accessible records. Due to this, EPICS network is sometimes called a real-time distributed database. To take things a step further, any resource published on the network is also called an EPICS record! To access records on the network, channels are used (which are a part of the channel access protocol). Extensive information on the mechanics of resource publishing through the input/output nodes is given in the flowing sections.
The class diagram above depicts the EpicsRecord and EpicsChannel types and their inheritance hierarchy. EPICS channels provide the node-to-node communication between the server (the node that is publishing a resource) and the client (a node that is requesting a specific resource). Thinking about the fact that each input/output controller node is a server as well as a client, lots and lots of channels are creating in each node. To remove some of the overhead of creating and destroying channels, each channel is recycled and reused for queued operations. Once created, a node can use a channel to access any resource published at the network. A very basic example to usage of a channel is:
var localClient = new EpicsClient();
var memoryUsageResource = localClient.CreateChannel("MyIOCNode:MemoryUsage");
Console.WriteLine(memoryUsageResource.Get());
Here an EpicsClient type is used to create an EpicsChannel, which then accesses a remote resource (memory usage of the remote computer in this case) and displays it at the system console. As it is obvious, there is no information present in the code either about the IP address of the remote node or the GUID of the system resource that is being accessed. Knowledge about the unique EPICS record name, which acts as a unique identifier, and the node name is enough. Publishing a specific resource at the network is also as simple as accessing it.
var myIOCNode = new EpicsServer();
var memoryUsage = myIOCNode.GetEpicsRecord"MyIOCNode:MemoryUsage");
memoryUsage.VAL = System.Diagnostics.PerformanceCounter("Memory", "Available MBytes");
Here the control node is named as “MyIOCNode” and an EPICS server is created on the node and a resource” MemoryUsage” is created and published on the EPICS network. The memory usage statistic is fetched easily via .NET Framework’s System.Diagnostics class. Based on this very simple client/server architecture, a very complex distributed system can be created with minimal effort. As it is apparent, all of the low-level details on the ongoing message passing processes are hidden from the programmer. All the complex details of network communications are handled by codecs which are the deciphers of the channel access protocols which is how EPICS based applications understand requests from each other.
Almost all of the human-machine interactions occur at software level thus providing the users with a solid interface is essential. The main goal of this user interface is to provide the means for effective operation and control of the machines and gather the feedback signals on a single screen, which aids the operator in making operational decisions. Although almost all of the control procedure is automated, variations in the scientific experiment scenarios compel constant supervision of the diagnostic monitors where the information presented must be crystal-clear. Again, consistency and usability is up to par with the rest of the system so at every step of the control, the users will be met with a familiar interface. It is important to note that just like any other control software developed for the IR-FEL facility, this HMI software makes extensive use of our EPICS .NET Library to communicate with the rest of the distributed control system.
One of the reasons for developing an EPICS library natively in C# programming language with Microsoft .NET Framework 4.0 was to be able to benefit from the unmatched UI capabilities of Microsoft Visual Studio 2010 in combination with Developer Express Windows Forms UI components. As a side note, Windows Forms was chosen as the UI base rather than the brand new Windows Presentation Foundation 4.0, due to its maturity and suitability for industrial grade applications with its proven stability. Developer Express UI components were used to enhance the user experience, regarding the fact that they are considered to be the best UI components available for WinForms, for their stability and functionality.
Each beam line component is visualized by its unique set of graphics describing the status of that component/equipment at a given time. Some of the beam line elements require manual activation to gain functionality. To enable quick access to the provided functionalities, small buttons are places on top of some components so the operator can quickly close a gate valve, set the aperture or drive the beam profile monitor mirrors into the beam line.
Below is an introductory video of the user interface and simulator in operation. Currently the video narrative is only in Turkish. Also, you may want to go into full-screen mode while watching because the original video resolution is quite high and the video has quite a bit of details. Also note that I refer to T.A.C. IR-FEL project as T.A.R.L.A. (Turkish Accelerator and Radiation Laboratory at Ankara).
You may always get the latest source-code from the GitHub. At the same location, you will also find the installer for the simulator and the user interface applications, which you can install to your computer to get a taste of how they function together. You can use the ‘Discussion’ and ‘Issue Tracker’ tabs to ask questions or submit bug reports. Note that the interface is dependent on DevExpress WinForms libraries, so you will need to download and install them too to be able to compile the project. If Visual Studio complains about missing UI libraries, just remove and re-add them from the GAC. For your further questions, you can always use GitHub's issue tracker and open a new issue.
This project extends PSI EPICS C# protocol implementation. Licensed under GPLv3 license.