Tango Controls 是一个面向对象的分布式控制系统框架，它定义了通信协议、应用程序程序员接口 (API)，并提供了一组工具和库来构建控制系统软件。它是围绕 devices 和 device classes 的概念构建的。
devices 由 device servers 创建。device servers 是实现 device classes 的进程。device classes 为每个类实现 state machine 、command(actions or methods)、pipes and attributes(data fields) 。因此，每个设备都具有state、零个或多个命令、零个或多个管道以及零个或多个属性。device classes 负责将硬件通信协议转换为 Tango Controls 通信。通过这种方式，您可以控制和监视所有设备，如电机、阀门、示波器等。设备类可用于实现任何算法或充当任何其他软件程序或系统的邮箱。
Tango Controls 旨在管理小型和大型系统。每个系统都有一个集中的（MariaDB/MySQL）数据库。数据库存储设备服务器启动时使用的配置数据，并通过存储动态网络地址充当名称服务器。数据库充当需要记忆的动态设置的永久存储。每个 Tango Control 系统都有一个数据库并由其 Tango Host 识别。一个大系统可以由数以万计或设备组成（尚未达到极限）。该协议支持系统的系统，即API 支持从多个系统对设备的透明访问。
Tango Controls 通信协议定义了系统的所有组件如何相互通信。 Tango 使用 CORBA 进行同步通信，使用 ZeroMQ 进行异步通信。这些协议的详细信息通过 API 和高级工具对 Tango 的开发人员和用户隐藏。
简化的 Tango Device Server Model #
| Block | Description |
|---|---|
| Device | TANGO device server object model 定义的抽象概念；它可以是一个硬件（互锁位）、硬件集合（连接到步进电机的屏幕）、逻辑设备（锥度）或所有这些的组合（加速器）。 |
| TANGO Class | 从面向对象编程的概念来看，这是开发人员必须实现的主要类。 |
| Device Server | 服务器（也称为设备服务器）是一个进程，其主要任务是向一个或多个客户端提供一项或多项服务。为此，服务器必须将大部分时间花在等待循环中，等待客户端连接到它。这些设备托管在服务器进程中。服务器能够托管多种类型的设备。简而言之，它是一个导出可用于接受请求的设备的过程。另请参阅术语表、设备服务器实例。 |
| Device Property | 存储在Tango 数据库中的配置参数。属性可以分配给设备类、设备或设备接口的元素（属性、 命令、管道）。属性也可以与设备无关——此类属性称为自由属性。Tango Controls系统的元素在启动期间经常使用属性值。这些通常提供配置硬件连接或调整用户首选项所需的信息。 |
| Attribute | 属性代表系统中的一个或多个过程值。它可能具有不同的格式或维度，例如标量 (0D)、频谱 (1D) 或图像 (2D)。该属性允许根据程序员定义的访问来读取和/或写入这些值。这些值可能具有不同的数据类型。此外，属性还提供一些元数据，例如属性质量、时间戳或配置属性。如需完整列表，请参阅手册。特定设备可用的属性列表由其类定义。 |
| Pipe | 管道允许从设备读取结构化数据和/或向设备写入结构化数据。数据可以由几种基本 Tango 数据类型构建。数据的结构由设备类定义并且不固定。它可以在运行时由设备本身更改，也可以根据客户端的请求根据 管道提供的set_pipe_config操作进行修改。设备可用的管道列表由其 设备类定义。 |
| Event | 事件是任何分布式控制系统的关键部分。他们的目标是提供一种快速高效的沟通机制。标准的CORBA通信范例是同步或异步的双向调用。对于对价值观始终感兴趣的客户来说，事件驱动的通信范式是一种更高效、更自然的编程方式。 |
| Command | 命令是用户可以在设备上调用的操作（例如SwitchOn、SwitchOff）。它还涉及到OOP（面向对象编程）中的一种具体方法。 Tango Controls 允许命令获取输入参数 (argin) 并返回值 (argout)。特定设备的可用命令列表由其设备类别定义。 |
| State | 设备可能处于运行时确定的某种状态。设备的状态可以反映与其连接的设备的状态或者以其他方式确定。该行为由实现状态机的设备类定义 。状态可以定义当前可用的属性、命令和管道操作。 Tango Controls 将设备可能处于的一组状态限制为 14 种：ON, OFF, CLOSE, OPEN, INSERT, EXTRACT, MOVING, STANDBY, FAULT, INIT, RUNNING, ALARM, DISABLE, and UNKNOWN |
| Status | 以格式化的 ascii 字符串表示的设备状态。 |
| Block | Attribute | Description |
|---|---|---|
| Device | domain/family/member | To identify the device |
| Left Block | Right Block | Multiplicity | Description |
|---|---|---|---|
| Device | TANGO Class | 1 | 每个设备都属于 Tango 类 |
| Attribute | Event | 0..* | 一个属性可以有多个关联事件 |
| Device | DeviceProperty | 0..* | 一台设备可以有多个关联的设备属性 |
| DeviceServer | Device | 1..* | 每个设备服务器内部都有许多设备 |
| TANGO Class | Attribute | 0..* | 一个 TANGO Class 可以有多个关联属性 |
| TANGO Class | Command | 0..* | 一个 TANGO Class 可以有多个关联命令 |
| TANGO Class | Pipe | 0..* | 一个 TANGO Class 可以有多个关联的 Pipe |
Tango object 命名（device, attribute and property） #
Tango 设备名称是一个包含三个字段的名称。字段分隔符是 / 字符。第一个字段名为 domain，第二个字段名为 family，最后一个字段名为 member。tango 设备名称如下所示：domain/family/member。
它是一种分层表示法。成员指定族中的哪个元素。该系列指定域内的设备类型。域对与其所属 accelerator/experiment 部分相关的设备进行分组。在ESRF，一些机器控制系统的域名是SR（存储环）、TL1（传输线1）或SY（同步加速器助推器）。对于实验，ID11 是属于插入 device 11 后面的实验的所有设备的域名。以下是 ESRF 中使用的 Tango 设备名称的一些示例：
sr/d-ct/1：电流互感器。域部分是sr，表示存储环。系列部分是诊断/电流互感器的d-ct，成员部分是 1fe/v-pen/id11-1：领域部分是fe代表前端。系列部件是v-pen，用于 vacuum/penning，成员名称是 id11-1，以指定这是插入设备 11 之后前端部件上的第一个仪表
Full object name #
如上所述的设备名称不足以涵盖所有 Tango 用法，例如没有数据库或多控制系统设备访问的设备服务器。通过命名模式，我们还必须能够命名属性和属性。因此，完整的命名模式是
[protocol://][host:port/]device_name[/attribute][->property][#dbase=xx]
protocol, host, port, attribute, property and dbase fields 是可选的。这些字段的含义是：
protocol: 指定使用哪种协议（Tango 或 Taco）。Tango是默认设置。#dbase: xx 支持的值为yes和no。该字段用于指定该设备是由使用或不使用数据库启动的设备服务器提供服务的设备。默认值为dbase=yes。host:port: 根据 dbase 值，该字段具有不同的含义。如果dbase=yes（默认），则host为控制系统数据库服务器运行的主机，port为数据库服务器端口。它的优先级高于TANGO_HOST环境变量定义的值。如果dbase=no，则host是为设备提供服务的设备服务器进程运行所在的主机名，port 是设备服务器进程端口。attribute: 属性名property: 特性名- 仅当创建用于远程访问设备的
DeviceProxy对象时，host:port和dbase=xx字段才是必需的。->字符用于指定属性名称。
关于 CORBA 您应该了解的 10 件事 #
- 您无需了解 CORBA 即可使用 TANGO
- CORBA 是通用对象请求代理架构的缩写，它是由对象管理组 (OMG)定义的标准
- CORBA 使得用不同语言编写并在不同计算机上运行的软件之间能够进行通信
- CORBA应用程序由许多对象组成；对象正在运行提供功能并可以代表现实世界中某些事物的软件
- 每个对象都有一个类型，该类型是用称为 IDL（接口定义语言）的语言定义的
- 一个对象有一个接口和一个实现：这是 CORBA 的本质，因为它允许互操作性。
- CORBA 允许应用程序请求分布式对象执行操作，并将操作结果返回给发出请求的应用程序。
- CORBA 基于远程过程调用模型
- TANGO 设备是一个 CORBA 对象
- TANGO 设备服务器是一个 CORBA 应用程序
Tango Server #
Tango 控制系统是一个抽象概念，代表一组基于通用技术：Tango 的“微服务”。 Tango 本身是 CORBA/ZMQ 的面向控制/命令的专业化。 CORBA 支持在网络互连机器上运行的软件总线的概念。它提供对连接到总线的任何软件对象（或微服务）的透明访问，并通过二进制网络协议（基于 CORBA 和ZMQ）。
该设备是Tango的核心概念。这个概念可以直接与微服务的概念联系起来：1 个设备 = 1 个微服务
一个设备可以代表：
- 设备（例如：电源），
- 一套设备（例如：由同一控制器驱动的一组4个电机），
- 一组软件功能（例如：图像处理），
- 代表子系统的一组设备
设备层次结构 #
Tango 控制系统可以分层组织。
- 在较低级别，我们找到与设备相关的基本设备。例如：真空泵、电机、I/O 卡
- 在更高的层面上，这些设备是逻辑的。这些设备基于较低级别的设备，管理并代表控制系统的子集。这通常是一组具有高级控制功能的设备的综合视图（功能可以在几个基本设备上执行一系列操作）。例如，一个高级设备实现了复杂的功能。无论硬件如何，该设备通常都会不断发展。因此，有必要将与逻辑功能相关的职责和与硬件接口相关的职责分开和隔离。
可以从每个级别的每个设备访问任何其他设备。下图说明了设备层次结构的概念：
沟通范式 #
Tango 提供三种通信范例：同步、异步和发布-订阅调用。
在同步和异步范例中，调用由联系服务器的客户端发起。服务器处理客户端的请求并将答案发送给客户端或抛出客户端捕获的异常。此范例涉及两个网络调用来接收单个答案，并要求客户端主动发起请求。客户端发起的调用可以通过两种机制完成：
- 客户端等待（并被阻止）服务器发送答案或直到达到超时的同步机制
- 客户端发送请求并立即返回的异步机制。它没有被阻止。它可以自由地做任何它必须做的事情，比如更新图形用户界面。客户端可以选择通过调用 API 特定调用来检查回复是否到达来检索服务器答案，或者通过请求在客户端收到服务器答案时执行回调方法来检索服务器答案。
如果客户端需要在每次更改时或定期了解某个值，则他有义务每次轮询服务器以获取值的更新。这在网络带宽和客户端编程方面都效率不高。为此，发布-订阅事件通信更加高效。
- 发布-订阅通信范例是一种更高效、更自然的编程方式。在这种范例中，客户在事件（值）中注册一次他的兴趣。事件可以是值的更改、固定频率的定期更新或存档事件。此后，每次发生事件时，服务器都会通知客户端。这种范例避免了客户端轮询，将其释放出来做其他事情，速度很快并且可以有效地利用网络。
类、设备和设备服务器 #
有时，有关设备、设备服务器和 Tango 类等概念的语言存在误用。
- DeviceClass类：定义接口和状态机的类。
- 设备类：实现设备控制的类。
- Device：Device 类的实例，提供对 DeviceClass 类的服务的访问。
- 设备服务器：执行一个或多个 Tango 类的进程（设备服务器）。
一个设备服务器可以托管多个设备类，每个类可以在同一设备服务器内实例化一次或多次。对于单个设备服务器中运行的类的最大数量或实例的最大数量，没有具体的规则。
在特定情况下，由于硬件或软件接口的限制，并不总是可以在同一设备服务器中运行设备类的多个实例：
- DLL的使用情况：有些DLL不能被同一进程的两个线程使用。
在其他情况下，在同一设备服务器中运行多个设备会很有用：
- 电机案例： 4个电机的单轴控制器。
设备
– 查阅文档
设备属性
– 查阅文档
设备命令
– 查阅文档
设备状态
设备状态是将其集成到控制系统中的关键要素。因此，在设备实现中管理状态转换时应该非常小心。
设备状态必须在任何时候都反映它所代表的系统的内部状态。状态应该代表客户请求所做的任何更改。
这是至关重要的信息。事实上，客户端将主要或仅使用此信息来确定系统的内部状态。
可用的状态仅限于：ON, OFF, CLOSE, OPEN, INSERT, EXTRACT, MOVING, STANDBY, FAULT, INIT, RUNNING, ALARM, DISABLE, and UNKNOWN
最重要的是确保设备在状态转换方面的行为是可预测的。
特性
– 查阅文档
应用程序接口 #
虽然 TANGO 客户端确实可以仅使用 CORBA API 进行编程，但 CORBA 对 TANGO 一无所知。这意味着客户端必须了解从 TANGO 数据库检索 IOR 的所有详细信息、要在线发送的附加信息、TANGO 版本控制等。这些详细信息可以而且应该包含在 TANGO 应用程序程序员接口 (API) 中。该 API 在 C++ 中作为库实现，在 Java 中作为包实现。 API 使 TANGO 客户端易于编写。 API 由以下基本类组成：
- DeviceProxy 这是真实设备的代理
- DeviceData 用于封装通过命令从设备发送/接收数据
- DeviceAttribute 通过属性封装从设备发送/接收的数据
- 组是一组设备的代理
除了这些主要类之外，许多其他类还提供 TANGO 功能的完整接口。下图是使用 TANGO 的典型客户端/服务器应用程序的图。
在服务器和客户端启动阶段使用数据库来建立客户端和服务器之间的连接。
客户端和服务器之间使用API进行通信 #
通过 API，可以请求在设备上执行的命令或使用所实现的两种通信模型之一来读取/写入设备属性。这两个模型是：
- 客户端等待（并被阻止）服务器发送答案或直到达到超时的同步模型
- 异步模型。在此模型中，客户端发送请求并立即返回。它没有被阻止。它可以自由地做任何它必须做的事情，比如更新图形用户界面。客户端可以选择通过调用 API 特定调用来检查回复是否到达来检索服务器答案，或者通过请求在客户端收到服务器答案时执行回调方法来检索服务器答案。
在 TANGO 版本 8 之前，TANGO 使用 CORBA OMG COS 通知服务来生成事件。 TANGO 使用通知服务的omniNotify 实现。 omniNotify 是与 TANGO 也使用的omniORB CORBA 实现结合开发的。通知服务的核心是通知守护进程。 omniNotify 守护进程是从设备服务器接收事件并将其分发到所有订阅的客户端的进程。为了分配事件负载，每个主机有一个通知守护进程。服务器将其事件发送到本地主机上的守护程序。客户端和服务器从 TANGO 数据库获取主机的 IOR。
下图是 Tango 8 之前版本的 Tango 事件系统示意图。
从 Tango 8 开始，实施了新的事件系统设计。这个新设计基于 ZMQ 库。 ZMQ 是一个允许用户创建通信系统的库。它实现了几种众所周知的通信模式，包括发布/订阅模式，这是新 Tango 事件系统的基础。使用此库，不再需要单独的通知服务，并且仅可通过客户端和服务器进程进行事件通信，从而简化了整体设计。从 Tango 8.1 开始，设备和客户端之间的事件传播可以使用多播协议来完成。这样做的目的是减少网络带宽的使用和设备服务器端的 CPU 消耗。请参阅“高级功能”一章以获取有关此功能的所有详细信息。
下图是从 Tango 版本 8 开始的 Tango 版本的 Tango 事件系统示意图。
