EPICS是一套软件工具和应用程序,为构建分布式控制系统提供软件基础设施,以操作诸如粒子加速器、大型实验和主要望远镜等设备。这种分布式控制系统通常由数十台甚至数百台计算机组成,这些计算机通过网络连接在一起,允许它们之间的通信,并从中央控制室甚至通过互联网远程控制和反馈设备的各个部分。
EPICS使用客户机/服务器和发布/订阅技术在不同的计算机之间进行通信。大多数服务器(称为输入/输出控制器或IOC)执行实际的I/O和本地控制任务,并使用通道访问(CA)网络协议将这些信息发布到客户机。CA是专门为使用EPICS的高带宽、软实时网络应用程序而设计的,这也是为什么它可以用于构建由数百台计算机组成的控制系统的原因之一。
最初,所有的EPICS IOC都必须运行在Wind River的vxWorks实时操作系统上,但2004年以来,可以在GUN/Linux、Solaris、MS-Windows、MacOS和RTEMS上运行IOC。可提供便携式软件,允许非EPICS控制系统充当CA服务器。CA客户机能够在各种各样的计算机和操作系统上运行——大多数风格的Unix、GNU/Linux、Windows、RTEMS和VXWorks。
EPICS也是参与软件开发和使用的组织的协作名称。它最初是Los Alamos National Laboratory和Argonne National Laboratory联合编写的,现在被世界各地的许多大型科学设施所使用。开发现在在这些不同的组织之间协作进行,I/O设备支持和客户机应用程序的共享非常多。
EPICS不是一个单一的软件,而是一组软件工具的集合,这些工具协同工作以帮助创建一个控制系统。EPICS的不同部分是在不同的组织、机构、企业开发的,并根据软件的发起人的意愿以不同的许可证分发,而软件的发起人的意愿通常又取决于实验室或其他组织对于此项工作的要求和政策。
所有在Argonne 或Argonne 与Los Alamos合作编写并由APS分发的EPICS代码现在都在EPICS Open license下使用。EPICS Open license源于旧的、更具限制性的EPICS Base license,包括美国能源部要求的某些措辞(这就是为什么我们不能仅使用修改后的BSD许可证)。EPICS旨在遵守Open Source Definition,但目前尚未提交给OSI小组审批。
Beam Telescope:(用于ANL的 IPNS装置)控制系统(由LANL开发)采用了一个运行DEC Windows图形用户界面的Vaxstation,并以CAMAC为分布式数据采集和网络实现平台,这项工作在瑞士Villars的ICALEPCS-87(1987年)会议上展示时,引起了ANL团队和许多其他团队的兴趣。
LANL Toolkit Workshop:1988年在LANL举办的加速器自动化应用工具箱研讨会上,ANL团队的最初成员与来自世界各地的加速器控制人员一起参加了会议。会议进行了热烈的讨论,并为LANL团队指出了开发方向。但是后来这些建议和想法从未得到发展。
GTACS:工具箱研讨会的成果是GTACS(Ground Test Accelerator Control System)系统的开发,该系统体现了研讨会上提出的许多想法,更重要的是,它体现了关键的核心软件和基于工具的设计概念,使其能够用于爆炸式扩展的应用程序阵列中。Jeff Hill、Bob Dalesio等人在LANL的工作是一个坚实的基础。
ANL加入LANL:LANL和ANL团队在加拿大温哥华ICALEPCS-89会议会面,ANL团队有一个APS控制系统要设计开发,希望与LANL-GTA团队合作开发。在合作过程中,他们加深了对GTACS的认识。
GTACS演变成了EPICS:随着ANL团队的人员配备和对GTACS的熟悉,他们开始(并受到LANL团队的鼓励)提出改进建议,以提高GTAC的实用性、便利性和跨平台透明度。最后,为了与多实验室共同开发工作保持一致,并减少混淆,建议对新版本使用更通用的名称,EPICS(Experimental Physics and Industrial Control System)从此诞生了!
EPICS合作开发组织包括5个美国实验室:
EPICS Base 3.14.12.8的核心开发成员是:
EPICS还有数个工业合作伙伴。
EPICS 7.0可以在如下平台开发:
GNU/Linux on Intel, PowerPC or ARM
MacOS X (Darwin) on Intel
MS Windows on x86 or x64 using MS Visual Studio, Cygwin, or MinGW
EPICS 7.0 IOC 可以在如下平台运行:
GNU/Linux on Intel, PowerPC or ARM
MacOS X (Darwin) on Intel
MS Windows on x86 or x64
RTEMS releases up to 4.10.x on any previously supported CPU.
vxWorks 6.8 or later on PowerPC or Intel CPUs.
s7nodave是一款S7 PLC的EPICS的设备驱动程序,它基于Asyn和libnodave,其中libnodave用来与S7或S7兼容的PLC通信。和其它S7 PLC的EPICS设备驱动程序不同,这款设备驱动程序不需要在PLC端编写任何编码,只需要在EPICS records中指定内存地址,并使用被大多数S7 PLC支持的ISO-TCP协议来读取通道数据。
详细信息参见:https://oss.aquenos.com/epics/s7nodave/
随着越来越多的设备和记录支持软件被编写在不同的EPICS应用系统中,以连接不同类型的硬件,很明显不是所有这些模块都能作为EPICS BASE的一部分集中管理和分发。因此,许多支持层软件已经从EPICS BASE上移除,现在单独维护。根据模块的用途,将它们分类为软支持(Soft Support)或硬件支持(Hardware Support)。
软支持模块可以包含一个新的记录类型、纯软件设备支持或一些在IOC中运行但却不容易用特定硬件识别的其他软件。
Steve Lewis提供了最全面的硬件支持列表,如果你想要的设备没有在这里列出,你也可以尝试使用谷歌的网络搜索。
许多使用Linux的PCI板内核驱动程序可以从Comedi项目中获得(推荐使用Asyn驱动层与Comedi连接到EPICS)。
基本操作,一个IOC在同一子网上
假设一个IOC有一个记录“fred”,你想用“caget fred”或类似的CA客户来阅读它。
如果是一个IOC在同一个子网上,事情很简单:
默认情况下,CA客户端将广播名称搜索请求到子网上的UDP端口5064。只要IOC在该子网上的任何计算机上运行,它就应该接收这些搜索请求。然后,服务器和客户机将建立一个TCP连接,并交换数据。
不同计算机上有多个IOC,但子网相同
如果运行多个IOC,每个IOC都在各自的计算机上,在同一子网上,基本广播名称搜索仍将成功,无需更改。
不同子网上的IOC
默认广播名称搜索仅限于运行CA客户端的计算机的子网。要访问一个或多个附加子网上的IOC,需要配置环境变量epis_ca_addr_list。它可以列出每个IOC的特定IP地址,也可以列出其子网的广播地址。但是请注意,路由器通常不会转发广播请求,这意味着使用特定的IP地址。
同一台计算机上有多个IOC
在计算机上启动第一个IOC时,它将监听UDP端口5064上的名称搜索。当在同一台计算机上启动第二个IOC时,它还将监听UDP端口5064上的名称搜索。但是,由于大多数网络内核的限制,只有最后启动的IOC才能实际接收发送到该计算机端口5064的UDP搜索请求。作为一种解决方法,您需要配置epis_ca_addr_列表以使用各自子网的广播地址。
或者,您可以自动设置将绕过问题的IPtables规则。(请参阅如何使通道访问在Linux主机上访问多个软IOC。)
StreamDevice是对具有基于“字节流”的通信接口的设备的通用EPICS设备支持。这意味着可以通过发送和接收字符串来控制设备(从最广泛的意义上来说,包括不可打印的字符,甚至是空字节)。这种通信接口的例子有串行线(RS-232、RS-485,…)、IEEE-488(也称为GPIB或HP-IB)和TCP/IP。StreamDevice附带了一个到asyndriver的接口,它实现了对这些通信接口的低级支持。但它可以被扩展以支持其他总线驱动程序。
StreamDevice支持所有具有设备支持功能的EPICS Base标准记录。也可以编写对新记录类型的设备支持。
StreamDevice 2已在以下位置进行测试:
EPICS采用了Callback机制, 实现网络协议和设备驱动中的异步处理, 在设备数据或状态变化时设备驱动才读取数据, 并传输到网络, 减轻网络通讯负荷和控制器CPU负载。《EPICS控制系统的Callback机制》一文清晰地阐述了这种机制,值得阅读。
以上内容主要摘录自这篇论文,建议获取原论文阅读。
EPICS Sequencer是EPICS的一个组件,可以平滑地集成在EPICS中去。EPICS Sequencer包含SNL编译器和运行时系统,其中SNL(State Notation Language)是一个特定领域的编程语言,用以在EPICS中实现有限状态机(FSM)功能。Sequencer通过EPICS的通道访问功能与运行时数据库连接。EPICS Sequencer是一个免费软件,遵循 EPICS Open License授权。
SNL为实时控制系统中的顺序操作编程提供了一个简单而强大的工具。基于熟悉的状态转换图概念,可以编写程序,而不需要通常的任务调度、事件处理和输入/输出编程的复杂性。
由SNL生成的程序在运行时Sequencer的框架内执行。序列器根据事件将程序驱动到不同状态,并建立与程序的接口,使其能够在多任务环境中执行实时控制。Sequencer还为程序提供服务,例如建立与运行时数据库通道的连接以及处理异步事件。
在工业界,许多设备用OPC(目前是OPC UA)作为通讯协议。但是在实验物理控制系统,EPICS CA是常见的通讯协议,包括报警系统和归档系统。本文介绍三种EPICS和OPC UA系统的集成方法。
三种方法各有利弊,需要根据实际情况做出选择。
《OPC技术在EPICS中的应用》一文值得阅读。
物联网描述的本质是越来越多的使用物品通过网络连接在一起并可使用单个或者多个的终端设备对它们进行各种控制和使用。物联网是在传统互联网基础上延伸和扩展而出的概念,用户端从传统的计算机延伸和扩展到了任何物品与物品之间,而物品则通过各种传感器进行信息采集,然后通过计算设备进行网络信息交换与通信。但是当前移动互联网正处于起步阶段,很多时候无法提供可靠的网络保障,因此,IBM主导并提出了MQTT协议,致力于解决这一方面的问题。
MQTT(Message Queuing Telemetry Transport)是一种基于发布/订阅(publish/subscribe)模式的”轻量级”通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。MQTT最大优点在于,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。使用MQTT可以允许将不同设备(如物联网)的部署轻松地集成到现有的控制系统中。
在一些科学实验装置中,大部分控制系统一开始就以EPICS为基础,后来又选择使用MQTT进行数据采集、离线处理和硬件控制,因此需要开发一种双向桥接MQTT和Channel Access的方法。
Brokhaven 利用PSI/SLS的CAFE C++ Channel Access库,开发了这样一个MQTT-Channel Access桥。虽然在Python或Java中实现这一点是可能的,但是C被选择,因为它提供了更强大的库集。由于需要一个MQTT库,所以选择了Paho库,它支持C/C++以及Python、Java和其他许多库。对于EPICS Channel Access,使用了标准的EPICS便携式Channel Access C库,该库与EPICS Base 3.14一起提供。
MQTT-Channel Access桥由两部分组成:订阅服务器组件和发布服务器组件。在这两种情况下,MQTT消息的格式都是JSON格式。订阅者组件通过MQTT订阅数据值,然后将该值发布到EPICS Channel Access,以便使用EPICS工具对其进行监控和存档。发布者服务器组件通过通道访问获取EPICS进程变量,然后将这些值发布到MQTT代理。这基本上与订阅服务器组件相反。
按照常规,完全的版本号定义分三项:<主版本号>.<次版本号>.<修订版本号>,如 1.0.0。
EPICS版本编号系统经过多年的发展,因此旧版本号可能与最近版本号的含义不完全相同。
需要注意的是,在EPICS中,任何含有0的版本(如3.15.0.1)都是开发者发布,不应用于生产系统。3.15系列中第一个适合生产使用的版本是3.15.1。
目前使用最普遍的EPICS版本是3.1x。还有一个版本EPICS V4,不知多少项目在使用。最新的主要发布的被称为EPICS 7,主要版本号的这种跃升是为了从近年来开发的一个问题中恢复过来,这个问题就是虽然我们开发了一个被称为“EPICS v4”的版本,但该版本根本没有取代Base-3.x,而是建立在v3之上。EPICS 7是Base-3.16代码(具有一些附加功能)和来自EPICS v4的大多数C++模块的组合,我们称之为EPICS 7来表达这两个版本的组合,即EPICS 7 = EPICS 3 + EPICS 4。
以下是一些主要的EPICS版本:
上述系列旁边的描述性术语是什么意思呢?它们中的大多数没有正式的定义,只是说明我们是否仍在为它们开发新特性和/或进行错误修复。这里有一个要点:核心EPICS开发人员为那些仍然使用(或根据合同维护)并且没有标记为“closed”的系列发布。通常只为最新版本系列开发和添加新功能(尽管这部分取决于编写代码的人员),但错误修复和更新的操作系统支持适用于最早的有意义的系列。
那么应该为项目选择上面哪个系列呢?这个选择取决于很多因素。如果您需要使用仅在最新版本系列中可用的功能,那么选择是明确的,但如果不是,而且您对EPICS还比较陌生,那么最好避免使用最新系列,因为教程和/或支持软件(如Asyn或其他驱动程序/设备支持)可能尚未更新,无法在该系列的基础上进行构建。如果您熟悉EPICS,建议您使用较新的系列,因为它将被维护更长时间。
本文旨在说明向EPICS添加新架构所需的主要步骤。
从某个EPICS base的分支(不是主干)下载最新版本的tar文件或快照,然后将其解包。
如果您还不熟悉EPICS,至少要浏览IOC应用程序开发指南的第4章;我们的构建系统与通常的“./configure && make”方法不同。
在linux-x86或solaris-sparc系统上构建你的,这样你就可以知道完全构建的系统的实际外观和行为。 您可以在同一个树中同时构建多个体系结构,这样可以更容易地进行比较。 在linux上,构建指令应该如此简单:
export EPICS_HOST_ARCH=linux-x86
cd <base>
make
在新系统上,要进行类似 setenv EPICS_HOST_ARCH的指令进行系统架构设置,其中HOST_ARCH部分通常采用 – 形式,例如solaris-sparc,linux-x86,windows-x86。
在/configure/os目录中,通过复制和编辑现有体系结构中的文件来创建这些文件:
CONFIG.Common.<arch>
CONFIG.<arch>.Common
CONFIG_SITE.<arch>.Common
我建议先看看darwin-ppc或linux-x86版本; 对于类Unix操作系统,您应该能够使用UnixCommon和/或GnuCommon文件来提供大多数定义和规则。
如果你必须交叉编译那么你需要做更多的工作,这些说明可能略显不足。
在/configure目录中运行’make’应该会成功并创建一个合适的O.目录。
为构建系统创建新文件后,请查看/src/libCom/osi/os子目录 ,这些子目录包含必须特定于操作系统的任何代码; 在许多情况下,posix和default目录可能提供您需要的几乎所有实现。创建一个以OS_CLASS命名的新目录,以放入任何新文件。
可以在/src/libCom目录中运行make来编译新文件。/src/libCom/test子目录中有许多测试(在这里首先运行make)将检查一些OSI实现 – 尝试在Linux或Solaris上运行这些测试以及新的目标操作系统 解正确的输出可能是什么。
一旦libCom正确构建,尝试在顶级目录中运行’make’,看看它能得到什么结果。如果你已经完成了libCom的东西,那么软件的其余部分编译时应该不会出错。
养成使用tech-talk的习惯,不要害怕在这里提出问题并发布您遇到的错误和位置,这里有很多人应该能够提供帮助。
如果您的基础构建没有错误,请按照开发指南中的第2章:入门说明在新体系结构上创建IOC,然后尝试运行它。
更改base/startup/EpicsHostArch和EpicsHostArch.pl以获取新的arch。
如果需要特殊说明,请添加base/documentation/README.。
果有效,请将您的更改发送到 [email protected] ,他们会将您的新架构合并到下一个版本中。
IOC数据库管理记录。记录有字段,例如模拟输入记录“fred”有如下可能的字段:
你用DBR_…请求类型以读取/写入通道的属性。尽管这些被称为“数据库请求类型”DBR_…,但它们实际上应该被称为“通道(channel)”或“属性(property)”请求类型。
Record如何映射到Channel,以及Record的Field如何映射到Channel的属性? 要真正理解这一点,您必须用心阅读源码。 结果在少数但最常见的情况下是有意义的; 在许多其他可能的情况下,它并不总是有意义的。
我们的第一个例子很有意义:你有一个频道“fred”用于AI记录“fred”,并要求Channel Access将其值作为DBR_CTRL_DOUBLE。 您的频道将在dbr_ctrl_double结构中提供其属性,映射到记录的以下字段:
你也可以要求DBR_TIME_DOUBLE并获得
时间戳当然是最后一次更新值的时间,因此它是属于该值的时间戳。 这种情况很有意义。
下一个很好的例子是一个“fred.SCAN”通道,它的类型为ENUM,您可以获得DBR_CTRL_ENUM属性:
这是当前值以及相应的枚举字符串。 但也有
这些是整个“fred”记录的状态和严重性。 其中的“NO_ALARM”/“NO_ALARM”或“READ”/“INVALID”对没有关于SCAN字段的任何内容,仅涉及整个“fred”记录。
现在将一个频道附加到“fred.HOPE”并读取DBR_TIME_DOUBLE:
您会得到一个与该值无关的时间戳。 现在不是HOPR上次更新的时间。
值和单位都可以,但状态和严重性再次是“fred”记录的整体属性,而不是我们所询问的PREC字段的属性。 两个控制限制还给出了PREC字段保持的16位数的范围,即使该范围内的大多数值对该字段没有任何意义。
因此,如果您的频道名称只是一个记录名称,则记录字段到频道属性的映射是有意义的。 在其他情况下,您必须查看记录的源代码以确定您将获得的内容,并且在许多情况下,它不是您可能想要的。
您还必须了解Channel Access无法内省记录(即迭代其所有字段)。 没有DBR_ALL_FIELDS类型,只有一组固定的DBR _…请求,这些请求被硬编码以通过记录类型的代码获取字段的特定记录字段或属性。
Autosave自动将EPICS过程变量(PV)的值保存到服务器上的文件中,并在重新启动IOC(输入输出控制器)时恢复这些值。过程变量(PV)是与机器相关的命名数据(例如状态、回读、设定点、参数)。autosave模块为EPICS PV提供了简单的保存/恢复功能,它包括save_pvs()和restore_pvs()函数以及autosaver类。这些与synApps中的autosave模块类似。这里的读写是通过Channel Access完成的,不需要与单个IOC相关。
AutoSave是一个由两部分组成的操作:运行时保存和启动时恢复。运行时部分(save_restore 任务或线程)由IOC启动文件中的命令启动,并在IOC运行时保持不变。它的主要工作是将PV值保存到服务器上的文件中,但它还支持手动恢复和其他管理操作。引导时间部分(dbrestore.c)在iocInit期间通过EPICS initHook调用。它从运行时部分写入的文件中恢复PV值,并且在iocInit()返回后不会持久。
除自动保存软件外,自动保存模块还包含一个客户端程序asVerify,用于比较写入的自动保存文件与当前PV值。这个程序还可以写一个自动保存文件,从中可以恢复PV值。因为asVerify的一个用途是从有问题的IOC中检索PV值(例如,save_restore任务崩溃),所以asVerify一次只与一个PV连接。这使得asVerify相当慢。在一次试验中,验证包含5000个pv的.sav文件花费了两分钟。
Autosave还包含一个名为configMenu的功能,用于创建、保存、查找、恢复和验证IOC配置(即一组PV值)。configMenu与EPICS备份和恢复工具burt大致相当,但它使用autosave文件,由EPICS PV驱动,因此它可以手动、由软件客户端和其他IOC代码使用。
Autosave还包含一个名为autosaveBuild的功能,用于生成autosave请求文件,作为EPICS函数dbLoadRecords()和dbLoadTemplate()操作的一部分。
这个软件可以以许多不同的方式使用。在EPICS官方网站可以找到如何使用autosave的完整示例。
实验物理和工业控制系统(EPICS)已在许多现场用于执行数据采集、监控、闭环控制、顺序控制和操作优化。EPICS架构最初是由一个具有不同物理和工业控制背景的团队开发的。当前架构代表“标准模型”的一个实例。它提供从任何局域网(LAN)设备到前端控制器的分布式处理和通信。具体来说,EPICS有分布式工作站,用于操作员界面、归档报警管理、排序和全局数据分析。有一个用于点对点通信的局域网和一组支持I/O接口、闭环控制和顺序控制的控制器。
EPICS应用程序通常会产生大量的网络流量,因此标准要求使用高带宽的网络协议。EPICS使用基于TCP/IP的Channel Access(CA)网络协议。Channel Access协议是建立在TCP/IP之上的应用层,它允许许多设备在同一网络上高速通信。Channel Access协议提供了EPICS应用所需的速度、带宽和可靠性水平。
EPICS还实现了客户机/服务器体系结构。Channel Access服务器(CA服务器)可以通过使用输入/输出控制器(IOC)充当现实世界的I/O点。CA服务器以EPICS过程变量(PV)的形式向网络发布数据并从网络中读取数据。相反,Channel Access客户机(CA客户机)监视网络以获取对进程变量的更新。CA客户机的例子包括人机界面(HMI)和数据分析程序,如LabVIEW, Control System Studio。
EPICS还有一些更大的扩展包括视频采样、视频分析,以及对分布在多个IOC上的4 kHz闭环控制的支持。基于工作站的工具经常被开发以适应独特的操作员需求,集成物理代码或利用一些商业软件包。一些例子是用于优化小角度离子源、WingZ、PV波和Mathmatica的自适应神经网络。EPICS软件体系结构为解决超出其能力范围的问题提供了一个灵活的环境。
控制系统应用程序需要为运行值班人员提供良好的界面。EPICS社区开发和维护着成熟稳定的GUI框架,这些框架基于使用经过验证的技术构建。GUI除了具有强大的稳健性要求,满足工业级的解决方案,还需要高度灵活性,适应千变万化的项目需求。
QT和CS-Studio是两个常见的EPICS GUI框架。
QT是用于构建桌面、移动和嵌入式应用程序的C ++平台和生态系统。许多开源和商业应用程序都使用QT,例如Autodesk Maya,Google Earth或VLC,因为它允许在不同的桌面和移动平台(Windows,Max,Linux,Android,iOS,QNX)中编译和部署生成的应用程序。
它以C ++编写,具有几种其他语言的绑定,支持OpenGL加速,HTML渲染器,Web套接字,BlueTooth和NFC支持,QWT图形,数据库绑定器和其他一些功能。它基于信号和插槽的概念,其中的组件订阅可以从其他组件接收信号的插槽。它包括可选工具,如开发IDE(QT Creator),构建系统(qmake)和翻译国际化助手(QT Linguist)。
CS-Studio是一个Eclipse RCP(富客户端平台)编写的应用程序,用于与加速器控制系统(EPICS)通信并在一个环境中集成其他控制系统服务。该应用主要用于设施操作员,允许他们控制和监控他们正在运行的系统。
通过Eclipse RCP插件的机制,它允许每个工厂仅配置产品,包括在其工厂实际部署和使用的功能。该应用程序可以由60多个Eclipse RCP功能和150多个插件组成。它提供了操作员屏幕的开发/设计,有许多小部件可以分析和可视化来自众多传感器的数据,并与归档,报警处理,日志和类似服务无缝集成。它提供了自动执行许多控制系统任务的工具。
2009年之前,Australian Synchrotron控制系统GUI工具包括EDM,MEDM,Delphi,Matlab&LabVIEW。EDM用于加速器,MEDM用于束线,Delphi用于加速器和部分束线,Matlab&LabVIEW主要用于分析而不是控制。
控制组决定选择新的GUI替代者,考虑的因素有:
Qt从众多的候选者中胜出,于是他们开发了EPICS Qt。
EPICS Qt是基于Qt的分层框架,用于通过Channel Access(ca)访问实验物理和工业控制系统(EPICS)数据。它是为控制系统图形界面的快速发展而设计的。
EPICS Qt框架可以通过三种方式使用:
注意,上面有许多变化,例如使用另一个集成开发环境(如Eclipse)或开发新的插件小部件来实现所需的功能,然后在无代码的GUI开发中使用这些小部件。
开发无代码GUI的简易路线图是:
EPICS Qt目前仍得到持续更新和维护。
工业、科研装置中控制系统对可靠性的要求越来越高,冗余是提高控制系统可靠性的重要手段,包括硬件冗余和软件冗余。在基于EPICS的控制系统中,设计和实现冗余IOC(输入输出控制器)是常用的方法。
需要特殊的技术解决方案来同步连续控制过程数据库(如PID)。序列程序的同步需要类似的技术解决方案。所有这些更新机制都必须由冗余监控任务(RMT)进行监控,该任务实现必须满足基本故障转移标准的硬编码专家系统:只有在新状态提供比当前状态更可靠的操作时,才会发生故障转移。
一个冗余的IOC系统由两个IOC组成。IOC之间的通信被实现为支持两个独立的以太网、公共以太网和专用以太网。冗余IOC共享这两个以太网连接,用于监视伙伴的运行状况并同步数据。全局以太网连接,用以监视高级网络服务器(如引导服务器)的可用性。全局以太网使用与公共以太网相同的网络设备。硬件组件的概述如图所示。
软件设计主要有三个要素:冗余监控任务(RMT)、连续控制执行(CCE)和状态表示语言(SNL)执行。需要修改现有应用程序(如snl-executive)以启用同步。这包括来自与硬件通信的驱动程序的状态信息、运行时数据库和SNL程序状态及其内部变量信息。
RMT与IOC合作伙伴建立并保持沟通。利用这两个来源的信息或操作员的命令,它决定何时接受或放弃控制。
为了确定IOC的整体状况,RMT检查重要资源的状态,这些资源称为主要冗余资源(PRR),包括公共以太网、专用以太网、全局以太网、设备驱动程序、CA服务器、扫描任务、CCE、序列器、SNL执行器等。
原则上,要监控的PRR数量是无限的。对于一个灵活和安全的解决方案,选择了一种设计,其中每个资源都有一个线程(PRR控制器)。每个线程执行其检查并将结果保存在控制表中。线程由一个主线程触发,该线程通过观察控制表中的结果来获得(生成)IOC的整体状态。
为了评估RMT本身的状态,RMT触发一个硬件看门狗。这将在RMT故障时重新启动系统。
RMT包含一个状态机,它实现了冗余转换的算法。RMT可以由shell中的可调用函数控制。从配置文件读取配置。
PRR是一个软件组件,可以是EPIC IOC软件的主要组成部分,如CCE和SNL高管。其他PRR是IO驱动程序。所有类型的组件都可以与RMT共享相同的接口。接口的某些部分仅对驱动程序有用。并非所有部分都必须针对特定组件实现。接口将作为组件中定义的函数实现,并可由RMT调用。
RMT可以使用以下函数向驱动程序实例发送命令,或者以公共头文件中定义的格式获取信息。由于驱动程序的许多实例都可以存在,因此函数需要一个指向驱动程序内部数据的指针来控制所需的实例。
对冗余IOC的支持为EPICS社区打开了一个新的控制应用机制。高可用性应用,如低温设备的24/7运行,不再仅仅是商业实施的模式。冗余IOC在当今高可用性需求达到99.8%的设施中也发挥着作用。由于冗余监视器任务的实现独立于EPICS运行时环境,因此也可以将该实现用于其他应用程序。将冗余支持移植到Linux和MAC操作系统将为新的前沿领域带来新的应用。
目前几乎所有加速器控制系统都是在所谓的标准模型的基础上的一种DCS(分布式控制系统)。在标准模型中,控制系统由三层组成:表示层,设备控制层和接口层。
目前加速器控制系统的另一个趋势是为其中间件使用免费工具包。在一些工具包中,EPICS(实验物理和工业控制系统)是最广泛使用的。 EPICS的开放性、免费和完整的功能使其被用于许多科学设施的控制系统,如加速器,望远镜和大型高能实验。 EPICS是在标准模型的基础上设计的, EPICS术语中称为OPI(操作员接口)层的表示层通常由几个工作站和用作操作员控制台的X终端组成。设备控制层由VME IOC(输入/输出控制器)和/或其他类型的计算机组成,以完成数据处理和控制逻辑。接口层由IOC上的I/O模块或接口设备的其他现场总线模块组成。
最近以太网的快速发展使其成为加速器控制系统中的网络事实上的国际标准。越来越多的具有以太网接口的设备控制器已被广泛使用,例如PLC(可编程逻辑控制器),以取代旧的现场总线接口设备控制器。这些基于以太网的设备控制器配备了更多的CPU资源和内存容量,并且已经变得足够智能,可以处理最初由IOC完成的控制逻辑。
现在由于基于以太网的设备控制器的出现,标准EPICS 3层模型变得多余并且显示出一些缺点:
程序的重复:我们将运行时数据库放在IOC上,也在智能设备控制器上安装类似的程序,例如PLC上的梯形图。
避免这些缺点并最大限度地利用智能设备控制器的一个方法是在这些智能设备控制器上实现集成控制软件(在EPICS中称为iocCore的IOC核心程序),从而使现有的智能设备控制器作为独立的IOC工作。我们将这种类型的控制器称为嵌入式EPICS控制器。
从EPICS base 3.14.x开始,iocCore支持不仅可以在VxWorks上运行,还可以运行最新版本的RTEMS,Solaris,Linux,HPUX,Darwin和Windows,并且已经在VxWorks和Linux上运行了一些嵌入式EPICS控制器。但他们都有一些短缺。例如,在Linux上运行的嵌入式EPICS控制器没有任何良好的实时响应,并且在VxWorks上运行的嵌入式EPICS控制器缺乏来自硬件制造商的BSP(板级支持包)支持。
micro-ITRON是一种实时内核,它的优势在于这些智能设备控制器具有用于微型ITRON的BSP,目前已有人在micro-ITRON上实现了嵌入式EPICS控制器。实现在micro-ITRON上运行的嵌入式EPICS控制器之后,可以省略冗余设备控制层。 EPICS架构可以恢复到标准的3层模型,并且可以消除之前提到的缺点。
Linux调度程序支持POSIX.1-2001定义的SCHED_FIFO调度策略。 使用此“实时”策略调度的线程可以在1-99范围内分配优先级(在linux下),其中99表示最高优先级。 由于普通的“非实时”进程以优先级0执行(nice(1)修改“动态优先级”,它只影响具有实时优先级0的进程并在这些进程之间实现公平分时),SCHED_FIFO线程始终能够抢占 “普通进程”(这些使用策略SCHED_OTHER)。 但请注意,除非使用RT_PREEMPT补丁构建linux内核并采取措施将EPICS进程锁定在内存中,否则即使在SCHED_FIFO策略下也不会出现严格确定的延迟,因此将其视为软实时。
为了让EPICS使用SCHED_FIFO实时策略,首先需要检查epics-base/configure/CONFIG_SITE中的以下选项是否设置为“YES”:
# Use POSIX thread priority scheduling (YES or NO)
USE_POSIX_THREAD_PRIORITY_SCHEDULING = YES
如果您发现当前设置为“NO”,则需要在更改为“YES”后重建EPICS base(make clean uninstall; make)。由于使用SCHED_FIFO策略使得在该策略下创建的任何线程的优先级高于使用SCHED_FIFO的任何正常进程,因此需要特殊权限。 在配备pam_security模块的相当新的Linux环境下,没有必要以root身份执行EPICS。 系统管理员可以定义/etc/security/limits.d/下文件中特定用户和/或组可能使用的最大优先级,请参阅limits.conf(5)的联机帮助页。 例如,如果使用以下内容创建文件/etc/security.limits.d/epics.conf(可能需要用户注销并重新登录才能获得新权限):
someuser hard rtprio 20
someuser soft rtprio 0
那么’someuser’创建的进程默认仍然具有优先级0(这是’soft’值),但’someuser’可能会从正在运行的程序(使用系统调用setrlimit(2))将资源限制增加到20,或者在shell中,例如使用bash的ulimit -r实用程序。 请注意,用户进程可以设置和/或降低其硬限制但不会增加它。
需要做三件事:
但是,Linux的sched_get_priority_max(2)系统调用由EPICS用于将EPICS优先级映射到/到linux / pthread优先级,它总是报告最大支持的优先级(99),而不考虑系统强制执行的任何限制(如上所述)。结果是(参见错误#835138),使用大于资源限制的所需优先级创建的线程最终以最低优先级0结束。
变通的方法是:
Nagios是一款开源的免费网络监视工具,能有效监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,打印机等。Nagios具有如下功能:
Nagios在NSLS-II等大型物理实验装置中被成功地用作主机和服务监控和警报系统。 它可以监视主机和服务,在出现问题时提醒用户。Nagios在不同的平台上配置方法不尽相同。
由于性能和可靠性问题,有线连接在加速器控制系统中通常是不可替代的。然而,这些通信链路存在若干缺点,例如在部署或重新配置期间缺乏灵活性以及电线和物理连接器的劣化,特别是在辐射环境中的劣化。本文分析在标准通用有线EPICS系统中引入无线EPICS子网,这涉及研究和选择适当的无线技术、架构、通信策略和安全策略。为了确保所提方法的有效性,需要对结果相关参数进行全面研究,例如吞吐量、安全性、可重复性和整个系统的稳定性。采用无线网络的目的是在不降低当前EPICS控制网络的可靠性、安全性和性能的情况下尽可能多地消除导线。
EPICS是面向大型科学设施的最重要的控制系统之一。该标准是通过实验室之间的合作而诞生和发展的。如今,它为大多数控制需求提供解决方案,并与各种硬件平台(PC,PXI ……)和操作系统(Linux,Windows,VxWorks ……)兼容。 EPICS是一套开源工具、库和应用程序,用于创建软实时分布式控制系统。它是一种基于中间件方法的大物理(Big Physics)标准,在全球范围内用于大型科学工程,如粒子加速器和望远镜。
尽管EPICS是一个成熟的软件框架,但EPICS系统新配置的研究和验证非常有价值,因为新思路拓展了它的发展。本文考虑两种主要方案:仅使用有线连接的EPICS系统的标准体系结构,以及包含无线链路的EPICS系统。通过将它们的可靠性与经典方案进行比较来验证所提出的系统。
为了获得更有价值的结果,测试平台包括两个不同的基于EPICS的系统:第一个使用经典的EPICS IOC,第二个使用集成了LabVIEW RT和EPICS的硬件。
经典的EPICS方法是一组实现了IOC的分布式Linux机器。他们负责将EPICS与控制系统设备(电机,热电偶,数据采集系统,开关等)进行通信。这种方法需要为每个新设备开发驱动程序(或EPICS Device的等效机制),这些Device是EPICS记录(过程变量集)和硬件(或第三方软件)之间的接口。这些驱动程序可以分为两部分:设备支持和驱动程序。第一个是记录和硬件独立的接口。第二个提供对硬件的低级软件访问。这些驱动程序的开发需要C语言概念,EPICS知识(记录,扫描方法,通道访问)以及I/O硬件(I/O寄存器,总线,中断)的经验。这意味着每次将新设备添加到控制结构时都需要额外的努力。
第二种架构包括将LabVIEW与EPICS结合使用。该方法允许避免先前架构的硬件相关开发成本。 NI(NI)硬件和软件支持各种设备和卡,因此无需编写特定的驱动程序。此外,LabVIEW的使用简化了控制结构的开发。 NI提供了一个集成在LabVIEW解决方案中的EPICS服务器,该解决方案基于LabVIEW DSC模块,可在PXI控制器的实时系统上运行。实时控制器发布EPICS PV,从LabVIEW的共享变量中获取数据。该方案显示出有趣的优点,但是,在采用这种工作方法之前,必须对其进行验证。为此,建议在每个测试平台中执行两个并行实现:第一个遵循经典方法,另一个使用LabVIEW。
在第二个测试平台中,将引入基于EPICS的无线链路系统,维护这两种架构。这里研究了更换尽可能多的电缆的可能性,这意味着要分析何时以及在什么情况下可以做到这一点。用于无线通信的有线连接的替换必须满足若干要求,特别是与吞吐量、可重复性和安全性相关的要求。通过将数据采集和控制的结果与从有线结构获得的结果进行比较来验证该体系结构。
在面详细说明每个方案验证的两个实验设置,以及有关实施的一些评价。,目标是以比较的方式测试从EPICS系统中提出的新配置获得的结果。
有线测试平台用于测试EPICS环境
实验设置模拟精简的本地控制器。 这包括数据采集,顺序和控制。 模拟直流电机的两个设施使用NI PXI-7833R多功能卡(包括Virtex II FPGA)实现为硬件环路(HIL)。 利用FPGA提供的并行计算,可以生成一整套信号。 在早期阶段,存在本地控制器中涉及的典型信号,例如互锁信号,诊断等。这些信号将是EPICS系统的过程变量(PV)。 这些信号的产生可以由其他设备(例如信号发生器)执行,但是,为了在同一设备内具有高水平的灵活性,已经选择了FPGA来完成该任务。 产生不同类型的信号(数字,模拟,波形),周期性地改变以及对抗外部干扰。
设置了两个控制系统。 第一个对应于LabVIEW方法,第二个对应于EPIC经典方法。两者都执行相同的控制动作和数据采集,但方式 工作是不同的。 以下段落描述了每个实现:
试验台必须长时间并行地连续操作这两种配置,以获得有关重复性问题的可靠结果。 因此,期望的参数在运行时期间存储在数据库中,用于比较有线和无线方法。系统出现故障时应特别小心,因为可靠性是本实验要解决的最重要问题之一。 此外,还测量了两种方法的不同类型的发布过程变量的性能。
此外,一旦获得并研究了之前的实验结果,我们应该能够进行初步分析,以验证或放弃LabVIEW环境与EPICS一起使用,具有高可靠性要求。
无线通信进入EPICS架构
接下来的任务是研究将无线技术引入EPICS系统的可能性。 无线通信具有许多优点,如降低成本,移动性,可扩展性和易维护性。 有线设备意味着放置的灵活性很小,并且无论何时需要重组或新安装,都需要花费大量资金和精力。 因此,由于性能原因不需要布线,由于实施速度快,无线监控是一个不错的选择。 但是,无论如何,必须在大型科学设施的每个地方确保可靠,快速和安全的通信。 最后,将I/O机器组与操作员站通信的典型以太网电缆替换为无线链路。
此外,这种方法允许开发能够在现代智能手机和平板电脑上运行的移动监控应用程序。 当在工厂级别需要维护操作时,这种应用可以提供帮助,例如故障查找和调试阶段。
在这一点上,提出了两种配置:
在第一个中,选择标准WiFi技术来部署相当于有线版本的测试平台。 IEE 802.11协议在工业中得到广泛应用,其在控制任务中的使用日益提高。 它为所需的需求提供了足够的带宽,并提供了实现不同安全机制的可能性。 该替代方案的实施适合当前的实验。LAN由路由器定义,路由器提供到实验室网络的有线(以太网)和无线(WiFi)通信。
第二步是找到最合适的无线技术来替换EPICS系统中的电缆。 这意味着要深入研究系统要求和不同的无线风味特性,以便选择最适合的性能,可靠性,功耗等技术。无线测试平台将根据所选技术进行部署。
目前,已安装第一版有线测试台并提供初始数据。 此外,使用WiFi技术的无线测试平台预计很快就会开始运行。 但是,在修改可能的技术之后,将实施第二个无线版本,这些技术更适合于使用EPICS网络替换典型环境中的有线连接。
将特别关注无线安全性。 将确保两个物理层之间的接口以避免控制系统的后门。 有效的控制安全策略将被应用并转换为无线环境。
所有这些测试都涉及较少数量的PV和简单的架构,然后提供能够部分验证结论的信息。 出于这个原因,如果初始测试结果鼓励推进本研究,第二阶段将包括更复杂的方案,具有更多的PV和更丰富的硬件配置,包括大量PV的实验。