实验物理与工业控制系统---EPICS

  • EPICS 简介
    • 什么是EPICS？
    • EPICS 授权
    • EPICS的诞生
    • EPICS合作开发
    • EPICS 7.0的开发平台和运行平台
    • s7nodave，S7 PLC的EPICS设备驱动程序
    • IOC支持模块
      • 软支持
      • 硬件支持
  • 如何配置Channel Access
  • StreamDevice简介
  • EPICS的Callback机制
  • EPICS Sequencer简介
  • EPICS和OPC UA之间的通讯
  • MQTT-Channel Access桥
  • EPICS的版本
  • EPICS的移植
  • EPICS中Record、Field、PV和Channel之间的关系
  • EPICS autosave模块简介
  • EPICS的基本架构
  • 支持EPICS的GUI框架CS-Studio和QT
  • EPICS Qt框架简介
  • RMT与IOC冗余
  • EPICS的Python扩展
  • 嵌入式EPICS
  • 软实时(Soft Real-time)EPICS
  • 基于Nagios的EPICS网络监控
  • EPICS与无线网络

EPICS 简介

什么是EPICS？

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不是一个单一的软件，而是一组软件工具的集合，这些工具协同工作以帮助创建一个控制系统。EPICS的不同部分是在不同的组织、机构、企业开发的，并根据软件的发起人的意愿以不同的许可证分发，而软件的发起人的意愿通常又取决于实验室或其他组织对于此项工作的要求和政策。
所有在Argonne 或Argonne 与Los Alamos合作编写并由APS分发的EPICS代码现在都在EPICS Open license下使用。EPICS Open license源于旧的、更具限制性的EPICS Base license，包括美国能源部要求的某些措辞（这就是为什么我们不能仅使用修改后的BSD许可证）。EPICS旨在遵守Open Source Definition，但目前尚未提交给OSI小组审批。

EPICS的诞生

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合作开发

EPICS合作开发组织包括5个美国实验室：

  • Los Alamos National Laboratory
  • Argonne National Laboratory,
  • Lawrence Berkeley Laboratory
  • Superconducting Super Collider Laboratory
  • Continuous Electron Beam Accelerator Facility

EPICS Base 3.14.12.8的核心开发成员是：

  • Martin R. Kraimer, Janet B. Anderson, Andrew N. Johnson (Argonne National Laboratory)
  • W. Eric Norum (Lawrence Berkeley Laboratory)
  • Jeffrey O. Hill (Los Alamos National Laboratory)
  • Ralph Lange, Benjamin Franksen (Helmholtz-Zentrum Berlin)
  • Peter Denison (Diamond Light Source)

EPICS还有数个工业合作伙伴。

EPICS 7.0的开发平台和运行平台

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设备驱动程序

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/

IOC支持模块

随着越来越多的设备和记录支持软件被编写在不同的EPICS应用系统中，以连接不同类型的硬件，很明显不是所有这些模块都能作为EPICS BASE的一部分集中管理和分发。因此，许多支持层软件已经从EPICS BASE上移除，现在单独维护。根据模块的用途，将它们分类为软支持（Soft Support）或硬件支持（Hardware Support）。

软支持

软支持模块可以包含一个新的记录类型、纯软件设备支持或一些在IOC中运行但却不容易用特定硬件识别的其他软件。

硬件支持

Steve Lewis提供了最全面的硬件支持列表，如果你想要的设备没有在这里列出，你也可以尝试使用谷歌的网络搜索。
许多使用Linux的PCI板内核驱动程序可以从Comedi项目中获得（推荐使用Asyn驱动层与Comedi连接到EPICS）。

如何配置Channel Access

  1. 基本操作，一个IOC在同一子网上
    假设一个IOC有一个记录“fred”，你想用“caget fred”或类似的CA客户来阅读它。
    如果是一个IOC在同一个子网上，事情很简单：
    默认情况下，CA客户端将广播名称搜索请求到子网上的UDP端口5064。只要IOC在该子网上的任何计算机上运行，它就应该接收这些搜索请求。然后，服务器和客户机将建立一个TCP连接，并交换数据。

  2. 不同计算机上有多个IOC，但子网相同
    如果运行多个IOC，每个IOC都在各自的计算机上，在同一子网上，基本广播名称搜索仍将成功，无需更改。

  3. 不同子网上的IOC
    默认广播名称搜索仅限于运行CA客户端的计算机的子网。要访问一个或多个附加子网上的IOC，需要配置环境变量epis_ca_addr_list。它可以列出每个IOC的特定IP地址，也可以列出其子网的广播地址。但是请注意，路由器通常不会转发广播请求，这意味着使用特定的IP地址。

  4. 同一台计算机上有多个IOC
    在计算机上启动第一个IOC时，它将监听UDP端口5064上的名称搜索。当在同一台计算机上启动第二个IOC时，它还将监听UDP端口5064上的名称搜索。但是，由于大多数网络内核的限制，只有最后启动的IOC才能实际接收发送到该计算机端口5064的UDP搜索请求。作为一种解决方法，您需要配置epis_ca_addr_列表以使用各自子网的广播地址。

或者，您可以自动设置将绕过问题的IPtables规则。（请参阅如何使通道访问在Linux主机上访问多个软IOC。）

  1. 同一台计算机上但在不同子网上有多个IOC
    结合最后两个点会导致一个问题：要在同一台计算机上访问多个IOC，必须将epis_ca_addr_list设置为该计算机子网的广播地址。但是，如果IOCS的子网与CA客户端的子网不同，则广播搜索数据包通常不会由中间网络路由器转发。
    有几种方法可以解决这个问题：

    • 通道访问网关
      在具有所需IOC的子网上运行的PV网关将使用其EPIC地址列表中该子网上的广播地址，以便它可以到达整个子网上所有IOC，包括在同一台计算机上运行的多个IOC。不同子网上的CA客户机只使用网关的epis_ca_addr_list=ip直接到达网关，这可以通过路由器实现。
      除了建立基本的连接之外，网关还提供IOC负载减少，它可以增加访问安全性，例如限制写访问。
    • CA名称服务器
      您可以在GUI子网中运行一个CA名称服务器，该服务器了解IOC并响应搜索请求；在这种情况下，您不会设置EPIC_ca_addr_列表变量。这几乎相当于运行一个CA网关，但是它的健壮性稍高一些，因为如果名称服务器进程停止，它不会杀死任何现有的连接。
    • UDP广播包中继
      如果您可以访问两个子网上都有网络接口的机器，则可以在机器上运行一个名为udp broadcast packet relay的程序，在子网上转发udp broadcast packet。为了获得最佳性能，您应该运行它两次，一次用于端口5064，另一次用于5065。第一个将在子网之间转发CA搜索请求，而第二个将重新分配CA信标，这有助于在IOC关闭一段时间后更快地重新连接频道。
  2. 防火墙
    防火墙可能需要配置为在端口5064和5065上传递UDP和TCP通信。

StreamDevice简介

StreamDevice是对具有基于“字节流”的通信接口的设备的通用EPICS设备支持。这意味着可以通过发送和接收字符串来控制设备（从最广泛的意义上来说，包括不可打印的字符，甚至是空字节）。这种通信接口的例子有串行线（RS-232、RS-485，…）、IEEE-488（也称为GPIB或HP-IB）和TCP/IP。StreamDevice附带了一个到asyndriver的接口，它实现了对这些通信接口的低级支持。但它可以被扩展以支持其他总线驱动程序。

StreamDevice支持所有具有设备支持功能的EPICS Base标准记录。也可以编写对新记录类型的设备支持。
StreamDevice 2已在以下位置进行测试：

  1. Linux-x86（rh-7.3、rh-9.0、sl-3、sl-5、sl-6、fc-3、fc-5、fc-6）
  2. Solaris SPARC和Solaris SPARC GNU（SUNOS 5.8）
  3. Cygwin-x86（Windows XP、Cygwin 1.5.20）
  4. Win32-x86（Windows XP）
  5. VXWorks-PPC603
  6. VXWorks-PPC604
  7. RTMES

EPICS的Callback机制

EPICS采用了Callback机制, 实现网络协议和设备驱动中的异步处理, 在设备数据或状态变化时设备驱动才读取数据, 并传输到网络, 减轻网络通讯负荷和控制器CPU负载。《EPICS控制系统的Callback机制》一文清晰地阐述了这种机制，值得阅读。

  1. CA协议中的Callback
    OPI和IOC间用以太网连接, 用基于TCP/IP协议的Channel Access 协议通讯。每个通道对应IOC数据库中的一个记录域。CA协议采用客户-服务者模型, OPI作为客户, 请求数据;IOC主要作为服务者, 提供数据, 有时也可作客户要求其他IOC上的数据。OPI为及时掌握设备运行情况, 需不断获取IOC中的最新数据。如果OPI频繁读取IOC数据时， 会占用极大的网络带宽, 甚至造成网络拥堵;如果读取IOC数据频率太低, 则无法及时掌握设备运行情况。这种情况下就用状态变化 (Change of State, COS) 的获取数据方式,即当某I/O设备的数据或状态变化超过指定范围时, IOC才主动向OPI报送数据或状态, 以既使OPI实时监控设备运行情况和运行结果, 又极大地减轻网络的负荷。
  2. IOC中的Callback
    IOC通过设备驱动程序实现对I/O设备的控制和数据获取。但I/O设备操作有时要一段时间。若IOC不停地查询I/O设备的操作状况, 可能会使IOC在该时间段内仅能完成这一个任务, 影响IOC运行和对其它I/O设备的处理。这就希望I/O设备操作完成后, 通过中断方式通知IOC处理。这是一种异步处理的方式。这就是EPICS的IOC中的Callback机制。

以上内容主要摘录自这篇论文，建议获取原论文阅读。

EPICS Sequencer简介

EPICS Sequencer是EPICS的一个组件，可以平滑地集成在EPICS中去。EPICS Sequencer包含SNL编译器和运行时系统，其中SNL（State Notation Language）是一个特定领域的编程语言，用以在EPICS中实现有限状态机（FSM）功能。Sequencer通过EPICS的通道访问功能与运行时数据库连接。EPICS Sequencer是一个免费软件，遵循 EPICS Open License授权。

SNL为实时控制系统中的顺序操作编程提供了一个简单而强大的工具。基于熟悉的状态转换图概念，可以编写程序，而不需要通常的任务调度、事件处理和输入/输出编程的复杂性。

由SNL生成的程序在运行时Sequencer的框架内执行。序列器根据事件将程序驱动到不同状态，并建立与程序的接口，使其能够在多任务环境中执行实时控制。Sequencer还为程序提供服务，例如建立与运行时数据库通道的连接以及处理异步事件。

EPICS和OPC UA之间的通讯

在工业界，许多设备用OPC（目前是OPC UA）作为通讯协议。但是在实验物理控制系统，EPICS CA是常见的通讯协议，包括报警系统和归档系统。本文介绍三种EPICS和OPC UA系统的集成方法。

  1. LabVIEW网关
    第一种办法是开发一个LabVIEW网关，在这种方法中，LabVIEW网关应用程序作为OPC UA服务和EPICS IOC的客户端，这样他们就可以建立通讯了。
  2. EPICS OPC UA设备支持
    第二种集成OPC UA和EPICS的方式是使用BESSY开发的EPICS OPC UA设备支持。这种方法的确定是编程语言只能是C/C++。
  3. 双服务器
    最后一种集成OPC UA和EPICS的方法就是现成的OPC UA服务器库实现EPICS设备支持。该设备支持提供一个OPC UA服务器接口给客户（即设备）。当客户使用OPC UA协议推送新值，设备支持就处理相应的EPICS记录。反之亦然，当一个CA客户推送一个值到EPICS记录，那么设备支持就通过OPC UA订阅机制传递这个值到OPC UA客户端。

三种方法各有利弊，需要根据实际情况做出选择。
《OPC技术在EPICS中的应用》一文值得阅读。

MQTT-Channel Access桥


物联网描述的本质是越来越多的使用物品通过网络连接在一起并可使用单个或者多个的终端设备对它们进行各种控制和使用。物联网是在传统互联网基础上延伸和扩展而出的概念，用户端从传统的计算机延伸和扩展到了任何物品与物品之间，而物品则通过各种传感器进行信息采集，然后通过计算设备进行网络信息交换与通信。但是当前移动互联网正处于起步阶段，很多时候无法提供可靠的网络保障，因此，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代理。这基本上与订阅服务器组件相反。

EPICS的版本

按照常规，完全的版本号定义分三项：<主版本号>.<次版本号>.<修订版本号>，如 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 7.0 (2017-present) – current release series
  • Release 3.16 (2016-2018) – closed
  • Release 3.15 (2014-present) – stable release series
  • Release 3.14 (2002-2018) – closed

上述系列旁边的描述性术语是什么意思呢？它们中的大多数没有正式的定义，只是说明我们是否仍在为它们开发新特性和/或进行错误修复。这里有一个要点：核心EPICS开发人员为那些仍然使用（或根据合同维护）并且没有标记为“closed”的系列发布。通常只为最新版本系列开发和添加新功能（尽管这部分取决于编写代码的人员），但错误修复和更新的操作系统支持适用于最早的有意义的系列。

那么应该为项目选择上面哪个系列呢？这个选择取决于很多因素。如果您需要使用仅在最新版本系列中可用的功能，那么选择是明确的，但如果不是，而且您对EPICS还比较陌生，那么最好避免使用最新系列，因为教程和/或支持软件（如Asyn或其他驱动程序/设备支持）可能尚未更新，无法在该系列的基础上进行构建。如果您熟悉EPICS，建议您使用较新的系列，因为它将被维护更长时间。

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.。
果有效，请将您的更改发送到 core-talk@aps.anl.gov ，他们会将您的新架构合并到下一个版本中。

EPICS中Record、Field、PV和Channel之间的关系

IOC数据库管理记录。记录有字段，例如模拟输入记录“fred”有如下可能的字段：

  • VAL (value)
  • EGU (Engineering Units)
  • TIME (Timestamp)
  • HOPR (High Operator Range)
  • LOPR (Low Operator Range)
  • STAT (Alarm Status)
  • SEVR (Alarm Severity)
  • …
    可以使用数据库（.db）文件或dbgf和dbpf命令来获取和设置记录的字段。
    Channel Access网络协议允许您访问Channel。Channel具有属性。比如Channel“fred”可以具有以下属性：
  • value
  • time stamp
  • units
  • upper control limit
  • lower control limit
  • status
  • severity
  • …

你用DBR_…请求类型以读取/写入通道的属性。尽管这些被称为“数据库请求类型”DBR_…，但它们实际上应该被称为“通道(channel)”或“属性(property)”请求类型。
Record如何映射到Channel，以及Record的Field如何映射到Channel的属性？ 要真正理解这一点，您必须用心阅读源码。 结果在少数但最常见的情况下是有意义的; 在许多其他可能的情况下，它并不总是有意义的。

我们的第一个例子很有意义：你有一个频道“fred”用于AI记录“fred”，并要求Channel Access将其值作为DBR_CTRL_DOUBLE。 您的频道将在dbr_ctrl_double结构中提供其属性，映射到记录的以下字段：

  • value = VAL
  • status = STAT
  • severity = SEVR
  • precision = PREC
  • units = EGU
  • upper_ctrl_limit = HOPR
  • lower_ctrl_limit = LOPR
  • …

你也可以要求DBR_TIME_DOUBLE并获得

  • value = VAL
  • stamp = TIME
  • …

时间戳当然是最后一次更新值的时间，因此它是属于该值的时间戳。 这种情况很有意义。
下一个很好的例子是一个“fred.SCAN”通道，它的类型为ENUM，您可以获得DBR_CTRL_ENUM属性：

  • value = SCAN
  • strs = { “Passive”, “Event”, …, “.1 second” }

这是当前值以及相应的枚举字符串。 但也有

  • status = STAT
  • severity = SEVR

这些是整个“fred”记录的状态和严重性。 其中的“NO_ALARM”/“NO_ALARM”或“READ”/“INVALID”对没有关于SCAN字段的任何内容，仅涉及整个“fred”记录。
现在将一个频道附加到“fred.HOPE”并读取DBR_TIME_DOUBLE：

  • value = HOPR
  • stamp = TIME

您会得到一个与该值无关的时间戳。 现在不是HOPR上次更新的时间。

  • value = PREC
  • units = EGU
  • status = STAT
  • severity = SEVR
  • lower_ctrl_limit=-32768
  • upper_ctrl_limit=32767

值和单位都可以，但状态和严重性再次是“fred”记录的整体属性，而不是我们所询问的PREC字段的属性。 两个控制限制还给出了PREC字段保持的16位数的范围，即使该范围内的大多数值对该字段没有任何意义。
因此，如果您的频道名称只是一个记录名称，则记录字段到频道属性的映射是有意义的。 在其他情况下，您必须查看记录的源代码以确定您将获得的内容，并且在许多情况下，它不是您可能想要的。
您还必须了解Channel Access无法内省记录（即迭代其所有字段）。 没有DBR_ALL_FIELDS类型，只有一组固定的DBR _…请求，这些请求被硬编码以通过记录类型的代码获取字段的特定记录字段或属性。

EPICS autosave模块简介

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）已在许多现场用于执行数据采集、监控、闭环控制、顺序控制和操作优化。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框架CS-Studio和QT

控制系统应用程序需要为运行值班人员提供良好的界面。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多个插件组成。它提供了操作员屏幕的开发/设计，有许多小部件可以分析和可视化来自众多传感器的数据，并与归档，报警处理，日志和类似服务无缝集成。它提供了自动执行许多控制系统任务的工具。

EPICS Qt框架简介

2009年之前，Australian Synchrotron控制系统GUI工具包括EDM，MEDM，Delphi，Matlab&LabVIEW。EDM用于加速器，MEDM用于束线，Delphi用于加速器和部分束线，Matlab&LabVIEW主要用于分析而不是控制。

控制组决定选择新的GUI替代者，考虑的因素有：

  • 跨平台
  • 开源
  • 支持拖放开发能力
  • 支持Channel Access
  • 不需要令人费解的工具
  • 良好的社区支持
  • 可扩展
  • …

Qt从众多的候选者中胜出，于是他们开发了EPICS Qt。

EPICS Qt是基于Qt的分层框架，用于通过Channel Access（ca）访问实验物理和工业控制系统（EPICS）数据。它是为控制系统图形界面的快速发展而设计的。
EPICS Qt框架可以通过三种方式使用：

  • 使用Qt的设计器应用程序和EPICS Qt框架插件设计GUI和QEGui应用程序向用户提供GUI的无代码GUI系统。
  • 使用Qt的集成开发环境和EPICS Qt框架小部件和数据对象进行代码丰富的GUI开发，以设计GUI应用程序。
  • 控制台应用程序开发使用Qt的集成开发环境和EPICS Qt框架数据对象来设计可以访问EPICS数据的控制台应用程序。

注意，上面有许多变化，例如使用另一个集成开发环境（如Eclipse）或开发新的插件小部件来实现所需的功能，然后在无代码的GUI开发中使用这些小部件。

开发无代码GUI的简易路线图是：

  1. 确保已安装：EPICS、Qt和QWT。
  2. 下载源代码：请参阅下面的下载源代码和文档。
  3. 设置构建环境，即发布文件见修改发布文件。
  4. 环境变量见环境变量或环境变量。
  5. 构建框架请参见构建插件库和显示管理器。
  6. 构建qegui（显示管理器）请参见构建插件库和显示管理器。
  7. 设置运行时环境（环境变量）请参见环境变量。
  8. 运行qegui。

EPICS Qt目前仍得到持续更新和维护。

RMT与IOC冗余

工业、科研装置中控制系统对可靠性的要求越来越高，冗余是提高控制系统可靠性的重要手段，包括硬件冗余和软件冗余。在基于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操作系统将为新的前沿领域带来新的应用。

EPICS的Python扩展

  1. CaChannel
    CaChannel是Channel Access的Python接口。CaChannel.ca模块是使用Python/C API编写的，它与caffi具有相同的API。因此，通过设置环境变量CACHANNEL_BACKEND=caffi，CaChannel接口也可以使用caffi.ca。如果不存在EPICS安装或C扩展无法导入，则无法使用。
  2. caffi
    caffi是Channel Access外部功能接口。它使用CFFI调用EPICS Channel Access访问库。这个包提供了Channel Access的直接低级接口，类似于C API。
  3. caproto
    Caproto是EPICS Channel Access协议的一种实现，用于纯Python中的分布式硬件控制，具有“sans-I/O”体系结构。
    Caproto是一个用于构建可以说Channel Access（EPICS）的Python程序的工具包。它包括一个可重用的核心，对通道访问协议进行编码。它还包括一些基于该核心的客户机和服务器实现。这种分层设计的灵感来自于Python社区中编写网络协议的sans-I/O实现的广泛努力。
    Caproto旨在成为EPICS的友好入口。对于那些想更好地了解硬件的工程师们了解更多关于EPICS社区的知识，以及对将其用于业余项目感兴趣的“制造商”来说，EPICS可能是有用的。Caproto也适用于大型实验设备。
  4. cothread
    此模块包含用于使用轻量级Python线程Channel Access的Python绑定
    从2-14版本开始，具有相同代码库的cothread现在完全支持Python 3，不需要应用补丁。
  5. pvaPY
    它是Python和Conda的官方pvAccess绑定。
    此页面提供对最近发布的pvapy模块版本的文档的访问，该版本由epics核心开发人员组维护。
  6. PyEPICS
    Python的EPICS Channel Access。
    PyEPICS是EPICS控制系统的Channel Access库与Python编程语言的接口。PyEPICS包为Python提供了一个基本的EPICS模块，提供了通过CA协议读取和写入EPICS过程变量（PV）的方法。该包包括CA模块中底层通道访问库上的一个较薄且相当完整的层，以及在此基础功能之上构建的更高层次的抽象。
    该包包含一个非常简单的CA接口，类似于Unix命令行工具和EZCA库，函数为epics.caget（）、epics.caput（）、epics.cainfo（）和epics.camonitor（）。这也是一个pv.PV类，它将EPICS过程变量表示为一个功能齐全、易于使用的Python对象。其他模块为CA提供更高级别的编程支持，包括将相关的PV分组到device.Device，在alarm.Alarm中创建报警，并在autosave模块中保存PV值。还支持在wx模块中方便地使用EPICS到wxPython小部件，并支持在Qt模块中使用PyQt小部件

嵌入式EPICS

目前几乎所有加速器控制系统都是在所谓的标准模型的基础上的一种DCS（分布式控制系统）。在标准模型中，控制系统由三层组成：表示层，设备控制层和接口层。
目前加速器控制系统的另一个趋势是为其中间件使用免费工具包。在一些工具包中，EPICS（实验物理和工业控制系统）是最广泛使用的。 EPICS的开放性、免费和完整的功能使其被用于许多科学设施的控制系统，如加速器，望远镜和大型高能实验。 EPICS是在标准模型的基础上设计的， EPICS术语中称为OPI（操作员接口）层的表示层通常由几个工作站和用作操作员控制台的X终端组成。设备控制层由VME IOC（输入/输出控制器）和/或其他类型的计算机组成，以完成数据处理和控制逻辑。接口层由IOC上的I/O模块或接口设备的其他现场总线模块组成。

最近以太网的快速发展使其成为加速器控制系统中的网络事实上的国际标准。越来越多的具有以太网接口的设备控制器已被广泛使用，例如PLC（可编程逻辑控制器），以取代旧的现场总线接口设备控制器。这些基于以太网的设备控制器配备了更多的CPU资源和内存容量，并且已经变得足够智能，可以处理最初由IOC完成的控制逻辑。

现在由于基于以太网的设备控制器的出现，标准EPICS 3层模型变得多余并且显示出一些缺点：

  • 缺乏实时响应：IOC通过以太网与智能设备控制器通信，而IEEE 802.3中定义的以太网不适用于严格的实时工业应用，因为它的通信是非确定性的。
  • 无效的硬件使用：在EPICS中，当我们使用智能设备控制器时，会在IOC上放置一个称为“异步驱动程序”的复杂设备驱动程序来驱动智能设备控制器。昂贵的VME机器仅用作“协议变换器”，将制造商的专有协议转换为EPICS CA（信道访问）协议。

程序的重复：我们将运行时数据库放在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层模型，并且可以消除之前提到的缺点。

软实时(Soft Real-time)EPICS

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实用程序。 请注意，用户进程可以设置和/或降低其硬限制但不会增加它。
需要做三件事：

  • 使用USE_POSIX_THREAD_PRIORITY_SCHEDULING = YES构建EPICS base。
  • 确保您的EPICS应用程序进程具有足够的权限来使用SCHED_FIFO和所需的优先级范围。
  • 为EPICS应用程序进程设置软RTPRIO和硬RTPRIO限制，以使其能够实际使用该权限。 此步骤是必需的，因为以实时优先级运行由给定用户或组创建的所有进程通常是个坏主意。

但是，Linux的sched_get_priority_max（2）系统调用由EPICS用于将EPICS优先级映射到/到linux / pthread优先级，它总是报告最大支持的优先级（99），而不考虑系统强制执行的任何限制（如上所述）。结果是（参见错误＃835138），使用大于资源限制的所需优先级创建的线程最终以最低优先级0结束。
变通的方法是：

  • 应用错误修正（AFAIK问题仍然存在于3.14.12.1中，之后可能会修复）
  • 或确保将RTPRIO限制设置为最大可能值（99）

基于Nagios的EPICS网络监控

Nagios是一款开源的免费网络监视工具，能有效监控Windows、Linux和Unix的主机状态，交换机路由器等网络设备，打印机等。Nagios具有如下功能：

  1. 综合监控

    • 使用单一工具监控应用程序，服务，操作系统，网络协议，系统指标和基础架构组件的功能
    • 强大的脚本API可以轻松监控内部和自定义应用程序，服务和系统
  2. 问题修复
    • 警报确认提供有关已知问题和问题响应的通信
    • 事件处理程序允许自动重启失败的应用程序和服务
  3. 报告
    • 可用性报告确保满足SLA
    • 历史报告提供警报，通知，中断和警报响应的记录
    • 第三方插件扩展了报告功能
  4. 可扩展架构
    • 使用多个API可轻松与内部应用程序和第三方应用程序集成
    • 数百个社区开发的插件扩展了核心Nagios功能
  5. 可视与可感知
    • 整个受监控IT基础架构的集中视图
    • 通过Web界面提供的详细状态信息
    • 快速检测基础设施中断
    • 可以通过电子邮件或短信向技术人员发送警报
    • 升级功能可确保警报通知到达合适的人员
  6. 主动规划
    • 趋势和容量规划插件可确保您了解老化的基础架构
    • 预定的停机时间允许在基础架构升级期间抑制警报
  7. 多租户功能
    • 多用户访问Web界面允许利益相关者查看基础架构状态
    • 特定于用户的视图可确保客户端仅查看其基础结构组件
  8. 稳定，可靠，可信赖的平台
    • 经过十多年的积极发展
    • 缩放以监控数千个节点
    • 故障转移功能可确保对关键IT基础架构组件进行不间断监控
    • 多个奖项，媒体报道和认可证明了Nagios的价值

Nagios在NSLS-II等大型物理实验装置中被成功地用作主机和服务监控和警报系统。 它可以监视主机和服务，在出现问题时提醒用户。Nagios在不同的平台上配置方法不尽相同。

EPICS与无线网络


由于性能和可靠性问题，有线连接在加速器控制系统中通常是不可替代的。然而，这些通信链路存在若干缺点，例如在部署或重新配置期间缺乏灵活性以及电线和物理连接器的劣化，特别是在辐射环境中的劣化。本文分析在标准通用有线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经典方法。两者都执行相同的控制动作和数据采集，但方式 工作是不同的。 以下段落描述了每个实现：

  • 第一个硬件设置包括NI的PXI机箱（PXIe-1082）和运行LabVIEW Real-Time操作系统的PXIe8108控制器（Pharlap ETS）。 带有Virtex 5 FPGA的NI 7853R多功能RIO充当I / O硬件。 控制动作在PXI控制器中运行的LabVIEW程序中定义，其中对HIL直流电机仿真执行PID控制，其等效工厂模型在FPGA上运行，负责仿真信号。 LabVIEW还可通过EPICS IO Server for LabVIEW充当EPICS服务器。 这通过信道访问协议将所需的控制信号发布到EPICS网络，从而创建新的过程变量。 这种方法允许开发人员专注于控制而不必担心驱动程序，因为这些驱动程序随NI硬件和软件一起提供，并且该过程对用户来说几乎是透明的。
  • 第二种设置对应于经典方法，作为参考。 IOC运行在带有Scientific Linux 6的NI PXI-8106嵌入式控制器中.NI PXI-6259 DAQ卡用于I / O任务。 如前所述，对于Linux（SL6）和EPICS，此设备都需要自己的驱动程序。 两者都可以在ITER CODAC核心系统v3.0公共版本中找到。 安装和配置后，即可使用6259卡。 定义了IOC数据库，包括所有系统PV。 设置实现有限状态机的定序器。 通过EPICS PID记录在FSM的运行状态下执行直流电机的PID控制。 其余信号也在此状态下进行管理。

试验台必须长时间并行地连续操作这两种配置，以获得有关重复性问题的可靠结果。 因此，期望的参数在运行时期间存储在数据库中，用于比较有线和无线方法。系统出现故障时应特别小心，因为可靠性是本实验要解决的最重要问题之一。 此外，还测量了两种方法的不同类型的发布过程变量的性能。

此外，一旦获得并研究了之前的实验结果，我们应该能够进行初步分析，以验证或放弃LabVIEW环境与EPICS一起使用，具有高可靠性要求。

无线通信进入EPICS架构
接下来的任务是研究将无线技术引入EPICS系统的可能性。 无线通信具有许多优点，如降低成本，移动性，可扩展性和易维护性。 有线设备意味着放置的灵活性很小，并且无论何时需要重组或新安装，都需要花费大量资金和精力。 因此，由于性能原因不需要布线，由于实施速度快，无线监控是一个不错的选择。 但是，无论如何，必须在大型科学设施的每个地方确保可靠，快速和安全的通信。 最后，将I/O机器组与操作员站通信的典型以太网电缆替换为无线链路。
此外，这种方法允许开发能够在现代智能手机和平板电脑上运行的移动监控应用程序。 当在工厂级别需要维护操作时，这种应用可以提供帮助，例如故障查找和调试阶段。

在这一点上，提出了两种配置：
在第一个中，选择标准WiFi技术来部署相当于有线版本的测试平台。 IEE 802.11协议在工业中得到广泛应用，其在控制任务中的使用日益提高。 它为所需的需求提供了足够的带宽，并提供了实现不同安全机制的可能性。 该替代方案的实施适合当前的实验。LAN由路由器定义，路由器提供到实验室网络的有线（以太网）和无线（WiFi）通信。

第二步是找到最合适的无线技术来替换EPICS系统中的电缆。 这意味着要深入研究系统要求和不同的无线风味特性，以便选择最适合的性能，可靠性，功耗等技术。无线测试平台将根据所选技术进行部署。

目前，已安装第一版有线测试台并提供初始数据。 此外，使用WiFi技术的无线测试平台预计很快就会开始运行。 但是，在修改可能的技术之后，将实施第二个无线版本，这些技术更适合于使用EPICS网络替换典型环境中的有线连接。

将特别关注无线安全性。 将确保两个物理层之间的接口以避免控制系统的后门。 有效的控制安全策略将被应用并转换为无线环境。

所有这些测试都涉及较少数量的PV和简单的架构，然后提供能够部分验证结论的信息。 出于这个原因，如果初始测试结果鼓励推进本研究，第二阶段将包括更复杂的方案，具有更多的PV和更丰富的硬件配置，包括大量PV的实验。

实验物理与工业控制系统---EPICS相关推荐

  1. 为什么工业控制系统需要安全防护？

    一.内因:工业控制系统最早和企业管理系统是隔离的:但近年来为了实现实时的数据采集与生产控制,满足"两化融合"的需求,引入了生产执行系统,即MES系统.MES系统的引入,使工业控制系 ...

  2. 基于plc计算机控制系统,基于PLC的工业控制系统特点的分析

    描述 (文章来源:工控网) PLC自问世以来,发展异常迅猛,其综合了计算机和自动化技术,不仅可以很容易地完成逻辑.顺序.定时.计数.数字运算.数据处理等功能,而且可以通过输入输出接口建立与各类生产机械 ...

  3. 虚拟专题：知识图谱 | 流程工业控制系统的知识图谱构建

    来源:智能科学与技术学报 流程工业控制系统的知识图谱构建 牟天昊1, 李少远1,2 1 上海交通大学电子信息与电气工程学院 2 上海交通大学系统控制与信息处理教育部重点实验室 摘要:近年来,工业控制系 ...

  4. 工业控制系统ICS网络安全简析

    针对信息系统的攻击方法,如感染病毒.DoS等,一般对工业控制系统也可以造成影响,但由于控制系统等特殊性,还有一些针对控制系统等专用的攻击方法,本文对这些针对工业控制系统的专用的网络攻击方法进行简单的介 ...

  5. OT安全|工业控制系统（ICS）六大安全实践

    工业控制系统(ICS)是全球关键基础设施的心脏.随着组织不断以最新进展更新其运营技术(OT),他们还应该意识到这些网络系统所面临的威胁.组织所关注的不仅仅是外部攻击的风险.他们还需要对内部威胁的增长保 ...

  6. CWE 4.7中的新视图：工业控制系统的安全漏洞类别

    本文分享自华为云社区<CWE 4.7中的新视图 -- 工业控制系统的安全漏洞类别>,作者:Uncle_Tom . 1. CWE 4.7 的变化 CWE 今年的第一个版本在 5/1 前发布了 ...

  7. plc服务器作用,工业控制系统以及PLC的简单介绍

    描述 (文章来源:西湖杂谈) 工业控制系统ICS的组件根据其所处的位置,可大致分为两类:控制中心设备和远程站点设备.控制中心设备位于系统控制中心,包括人机界面(HMI).工程师工作站和历史记录服务器( ...

  8. 油气田工业控制系统现状

    石油石化行业综述 石油石化行业分为上游.中游和下游.其中,上游从事的业务包括原油.天然气的勘探.开发,中游主要是油气 的存储与运输,下游则涵盖炼油.化工.天然气加工等流程型业务及加油站 零售等产品配送 ...

  9. 工业控制系统协议相关的安全问题

    工业控制系统 协议相关的安全问题为了增强工控系统的整体安全性 ,有必要改善工业控制系统协议的安全特征.对协议进 行基本的分析将有助于暴露协议中存在的安全问题,进而能够指导安全机制的开发,并最终 合并到 ...

  10. 计算机控制系统的输入输出信号,工业控制系统的输入与输出信号

    工业控制系统的输入输出信号 在工业生产过程中实现计算机控制的前提是,工业生产过程的过程参数.工况逻辑和设备运行条件等物理量必须转化为电信号(电压或电流)或计算机通过传感器或变送器可以识别的逻辑量. 传 ...

最新文章

  1. 作为管理者的你，如何用人？一点建议给你
  2. 深度学习框架 通道顺序
  3. 【剑指Offer】俯视50题之31 - 40题
  4. 使用coding.net上传项目
  5. openstack Q版部署-----安装报错问题
  6. 声明式RESTful客户端在asp.net core中的应用
  7. sle linux lftp禁止匿名登陆_软件测试常用linux命令整理
  8. 【UI/UX】桌面GUI设计
  9. 玩转Docker镜像
  10. 重启/杀死 jobs
  11. 【BZOJ】3396: [Usaco2009 Jan]Total flow 水流 （最大流）
  12. 使用微信小程序生成海报
  13. EasyNLP发布融合语言学和事实知识的中文预训练模型CKBERT
  14. 联想如何打开计算机配置,联想电脑如何进入BIOS以及设置启动菜单
  15. archlinux yaourt使用问题
  16. JAVA random 缺陷_Random在高并发下的缺陷以及JUC对其的优化
  17. 保持良好的人际关系，赢得好人缘的八大诀窍
  18. 【C++】C++静态库和动态库的区别
  19. 英语语法之强调句和倒装
  20. 最近工作中遇到的问题和解决

热门文章

  1. java sof栈泄露_java虚拟机(四)--内存溢出、内存泄漏、SOF
  2. PHP编程学习之路 2
  3. IDEA 中定义自己的TODO 并设置快捷键
  4. 怎么搭建百度网盘目录搜索网站？网盘目录#百度网盘
  5. ROC、PR曲线、AUC值
  6. 《windows核心编程》第6章 线程基础
  7. java记忆翻牌,原生JS实现记忆翻牌游戏
  8. 围棋的基本下法与规则
  9. walking机器人入门教程-gmapping算法建图
  10. Python视觉深度学习系列教程 第二卷 第3章 理解rank-1rank-5精度