General information

Communication Driver Name: ICCPDual
Current Version: 9.12
Implementation DLL: T.ProtocolDriver.ICCPDual.dll
Protocol: ICCP tase2 Standard protocol
Interface: Custom TCPIP
Description: O módulo de comunicação ICCPDual implementa as duas formas de uso do protocolo ICCP: Estação cliente para a comunicação com estações servidoras compatíveis com este protocolo, e estação Servidora para atender às solicitações de estações Clientes. Também permite a utilização como função dual, incluindo em um mesmo canal de comunicação as duas funçõesThe ICCPDual communication module implements both forms of use of the ICCP protocol: Client Station for communication with server stations compatible with this protocol, and Server station to meet requests from Client stations. It also allows the use of dual function, including the two functions in the same communication channel.
Protocol Options: Funções definidasDefined functions, log, e modo do endpoint TcpIpand TcpIp endpoint mode.
Max number of nodes: Até dois para um mesmo canal, sendo um de cada modo de comunicaçãoUp to two for the same channel, one of which is one of each communication mode
PC Hardware requirementsRequirements: Standard PC Ethernet interface board;
PC Software requirements: ActionNET system.

Apresentação

Presentation

Also known as ICCP, o IEC 60870 parte 6 pertence ao conjunto de padrões IEC 60870 que são usados para controle remoto, monitoramento e telemetria nas redes de telecomunicações de sistemas elétricos (potência) e nas aplicações de controle de centros de energia. O padrão IEC 60870-6 é baseado na teoria do perfil funcional. Uma descrição dos perfis funcionais, sua classificação e definição é retirada da part 6 belongs to the IEC 60870 set of standards used for remote control, monitoring, and telemetry in electrical system (power) telecommunications networks and power center control applications. The IEC 60870-6 standard is based on functional profile theory. A description of functional profiles, their classification and, their definition is taken from IEC 60870-6-1.
Um perfil para o Telecontrol Application Service Element A profile for telecontrol application service element 2 (TASE.2) é conhecido como is known as ICCP - Inter-Control Center Communications Protocol. TASE.2 na camada de aplicação é definido no padrão in the application layer is defined in the IEC 60870-6-503 . Este padrão define o protocolo da camada de aplicação para que cumpra os requisitos de cooperação funcional. Ele também define os requisitos para as camadas de apresentação e relação que fornecem o standard. This standard defines the application layer protocol to meet the functional cooperation requirements. It also describes the requirements for the presentation and relationship layers that provide TASE.2.
O protocolo The TASE.2 é baseado em MMS (protocol is based on Manufacturing Message Specification (MMS). As funções básicas do ICCP são especificadas como um conjunto dos chamados "Blocos de Conformidade".
Nesta implementação o protocolo ICCP suporta as funções dos blocos The essential functions of the ICCP are specified as a set of so-called "Compliance Blocks.”
In this implementation, the ICCP protocol supports the functions of blocks 1 2, 4 e and 5

1. Periodic system data: status points, analog points, quality flags, date and time record, value change counter. Binding objects to track ICCP sessions.

2. Extended dataset condition monitoring: Provides reports by exception capacity for the data types that block 1 can transfer periodically.

3. Transfers of Large Blocks of Data; Not implemented;

4. Information Messages

5. Device Control.-

Funcionamento geral

No protocolo ICCP, as funções de cliente e servidor são bem definidas. Nesta implementação o mesmo módulo pode ser usado para definir um nodo com o papel de cliente ou de servidor. Pode-se definir para o canal somente a função cliente, ou somente a função servidora, ou mesmo pode-se definir dois nodos, no mesmo canal para incluir na mesma conexão tcp ip as duas atividades, de forma completamente independente uma da outra.

Modo Servidor

Neste modo de utilização, implementando o lado Servidor, o módulo inicia e aguarda a conexão de um cliente para a comunicação.
Durante sua atividade, obtém os dados em tempo real atuais no Action.NET e os envia sob solicitação ou através de um mecanismo de emissão de reportes não solicitados.
Entre as funções e características incluídas estão:

• Definição dos dados, denominados de pontos de indicação

• Modelo de dispositivo (comandos)

• Conjuntos de dados (Data Sets, obter / definir / criar / excluir / obter diretório)

• Transferência de conjunto de dados, Data Sets Transfers (intervalo, RBE, ...)

• Mensagens de Informação

• Tabelas Bilaterais

• Conexões seguras (TLS) ou não seguras

• Blocos de conformidade 1, 2, 4 e 5

Modo Cliente

No modo Cliente o módulo tenta estabelecer uma conexão Tcp Ip à uma estação servidora para iniciar comunicação de dados com ela.
Sua função principal é a de prover as funções para acessar os dados de um servidor específico.
Implementa facilidades de solicitar dados da estação servidora através de operações de leitura e amostragens periódicas e ou estabelecer e habilitar no servidor um modo de transferência de dados não solicitados.
Entre as funções e características principais encontradas no cliente estão:

• Navegar no modelo de dados do servidor (browsing);

• Criar no cliente o Modelo de Dados do servidor

• Ler e escrever pontos de indicação

• Enviar comandos, pontos de ajuste (set points) e tags (cartões) para dispositivos (Control Points)

• Solicitar a criação de data sets dinâmicos no servidor

• Ler conjuntos de dados (Data Sets)

• Configurar conjuntos de transferência (DS Transfer Sets)

• Ativar / desativar conjuntos de transferência de mensagens instantâneas (IM)

• Ativar / desativar conjuntos de transferência DS (Data Sets)

• Receber relatórios de conjunto de transferência

Modelo de Dados do ICCP Servidor

Modelo de dados

O modelo de dados do servidor DataModel, é constituído de domínios Domains, pontos de indicação Indication Points, dispositivos (Control Points), conjuntos de dados DataSets e conjuntos de transferência DS Transfers Sets.
Em TASE.2, as variáveis ​​são objetos com nomes (Named Objects) que fazem parte do espaço de endereçamento do servidor. As variáveis ​​podem ser variáveis ​​do sistema (como "Bilateral_Table_ID", "Supported_Features", ...), pontos de indicação, equipamentos de proteção e dispositivos.
As variáveis ​​podem ter dois "escopos". O escopo VCC ou um escopo específico de domínio (ICC) definida pelo usuário. Variáveis ​​de escopo VCC não fazem parte de nenhum domínio TASE.2 e são visíveis a todos os clientes.

Domínios

As variáveis ​​do escopo VCC são identificadas apenas pelo nome da variável. Variáveis ​​de escopo de domínio são identificadas pelo nome de domínio e o nome da variável. Domain e Variable Name.
Um domínio TASE.2 é representado por um Domain Name. O objeto de domínio pode conter todos os tipos de pontos de dados, conjuntos de dados e conjuntos de transferência.
Um objeto de domínio é a primeira coisa a ser criada dentro de um modelo de dados. Na tabela de endereçamento Points, para cada tag Action.NET no endereço ICCP será incluído o par
<Domínio>/<Nome da variável>, desta forma, separados por uma barra.
Para cada Modelo de Dados (para cada canal de comunicação Action.NET ICCP) somente poderá ser criado um domínio.
Para o caso de variáveis incluídas no escopo VCC o endereçamento não usa domínio. É como se fosse um domínio vazio. O endereço terá a forma: <Nome da variável>.
A seguir são listados os objetos de dados existentes para o ambiente ICCP TASE.2

Pontos de indicação

TASE.2 suporta diferentes tipos de pontos de indicação (Indication Points).
A versão mais simples são valores booleanos, inteiros ou flutuantes (reais) simples. Opcionalmente, um ponto de indicação pode ter, além de seu valor ou estado:

• Campo de qualidade que consiste em Flags indicativos de qualidade

• Campo de data/ hora (Timestamp normal ou estendido) que pode representar timestamps de data / hora em segundos ou milissegundos

• Campo COV (contador de mudanças de valor, ou Change Of Value

Os seguintes tipos básicos são suportados:

• STATE - Estado (assumindo os valores 0,1, 2 ou 3)

• STATE_SUPPLEMENT - Suplemento de estado.

• DISCRET - valores inteiros de até 32bits.

• REAL – Valores em ponto flutuante em 32 bits.

Existem três tipos diferentes de pontos de controle:

• Comandos – Para o controle de dispositivos digitais, representados por tags de Action.Net de pontos de escrita como chaves e disjuntores.

• Envio de Tags Device Service - cartões de impedimento/bloqueio

• Pontos de ajuste discretos – set points para tags inteiros (32bits)

• Pontos de ajuste reais – set points para tags double (floating point) de 32 bits.

Além disso, existem duas classes de controle:

• Select Before Operate (SBO) - Selecione antes de operar. Neste modo, primeiro o cliente deve enviar uma mensagem de "seleção" para "armar" o ponto de controle. Quando selecionado, o cliente deve enviar uma mensagem "operar" antes do tempo limite selecionado.

• Direct - Direto. Neste modo, o controle consiste no envio de um simples comando "operar".

DataSets e DataSets Transfer Sets

Conjuntos de dados são listas de variáveis ​​ (variáveis ​​de sistema e pontos de dados) que podem ser lidas ou gravadas com uma única solicitação de leitura ou gravação pelo cliente. Eles também são a base para as ações de transferência não solicitada de Data sets.

Os data sets podem ser estaticamente definidos no Servidor ou podem ter sua criação feita de modo dinâmico no servidor, por solicitação do Cliente.

Um conjunto de dados pode conter as seguintes variáveis ​​de sistema (de escopo de domínio):

• Transfer_Set_Name - O nome do conjunto de transferência associado (consiste no nome de domínio e no nome do conjunto de transferência)

• DSConditions_Detected - Condições que causaram o relatório de conjunto de transferência

• Event_Code_Detected - O código do evento do relatório

• Transfer_Set_Time_Stamp - O carimbo de data / hora definido pelo momento transferência (em segundos)

Na implementação do módulo servidor, sempre que for declarado um DataSet serão incluídas estas variáveis de sistema no conjunto de dados.

Mensagens de informação (Information Messages)

O mecanismo de mensagens de informação é constituído por um conjunto de transferência de mensagem de informação (IM) e nos buffers de mensagem de informação.
O conjunto de transferência de mensagens de informação é um mecanismo específico de associação entre cliente e servidor que (quando habilitado pelo cliente) envia mensagens de informação do servidor para o cliente. A transmissão da mensagem é acionada pelo servidor. As mensagens de informação podem ser específicas do VCC ou do domínio ICC, definido no servidor e cliente.
As mensagens de informação podem conter dados textuais ou dados binários arbitrários. O comprimento das mensagens de informação é limitado pelos buffers de informação disponíveis e pelo tamanho máximo da PDU MMS.
As mensagens informativas só serão enviadas a um cliente quando a Tabela Bilateral ou Bilateral Table o permitir. Com a tabela bilateral, as mensagens de informação são restringidas por seus parâmetros de referência de informação, referência local e escopo (ICC ou VCC).
Deverá ser definida uma tag Action.Net do tipo texto para suportar a troca de mensagens de informação. Veja mais detalhes na secção sobre Endereçamento de pontos.

Tabelas Bilaterais (Bilateral Table)

A tabela bilateral (BLT) é criada pelo servidor, definindo um domínio e consiste nos seguintes elementos:

• O ID da Tabela bilateral - Um nome único para identificar a BLT.

• A referência de aplicativo do cliente (ap-title e ae-qualifier) – utilizada para identificação entre servidor e cliente para a criação de uma conexão. Veja na definição das estações dos Nodes. No servidor a BLT é criada usando o definido como ap-title remoto, isto é o ap-title local do cliente.

• Um nome de Domínio TASE.2 específico. O lado cliente pode acessar todos os objetos do domínio incluído na tabela, sem restrições.

• Uma lista de especificações de controle de acesso de ponto de dados, não incluídos no domínio.

• Se um ponto de dados do escopo do VCC não fizer parte desta lista, ele não estará acessível para o cliente associado.
  As Tabelas bilaterais constituem uma parte importante do mecanismo de controle de acesso.

• Se nenhum BLT for definido, as decisões de controle de acesso serão baseadas exclusivamente nos direitos de acesso definidos para o ponto de dados. Esses direitos de acesso são iguais para todos os clientes.

• Se forem definidas tabelas bilaterais, as decisões de controle de acesso serão baseadas nos direitos de acesso definidos para o ponto de dados e naqueles definidos na tabela bilateral para o cliente solicitante.

• Se um ponto de dados não fizer parte da tabela bilateral para o cliente solicitante, a solicitação será negada e uma resposta "acesso ao objeto negado" será enviada ao cliente.

• Se um ponto de dados for especificado no BLT para um cliente, o acesso só será permitido se for permitido na especificação de controle de acesso do ponto de dados e na especificação de controle de acesso no BLT.

Operações executadas pelo Cliente

Toda a tarefa de criação do modelo de dados é feita no módulo Servidor.

O Módulo cliente faz o browse do Modelo de Dados do servidor e cria listas de variáveis e de data sets a partir dos dados do servidor, para usar na requisição de leituras.
Localmente, pela leitura de sua tabela Points cria as tabelas de correspondência entre as tags Action.NET e os nomes de variáveis ICCP, recebidos do servidor.

As operações de leituras serão feitas periodicamente, de acordo com tempos de periodicidade de amostragens definidos na configuração dos nodes do canal usando este protocolo. Se estes tempos de periodicidade forem definido com Zeros, as operações de amostragem não serão executadas.

Alternativamente o Cliente pode definir e parametrizar Reportes , ou Ds Transfer Sets, para que o servidor envie os dados de forma não solicitada, a partir de critérios definidos. Para estas transferências pode usar data sets definidos estaticamente no servidor, ou criar dinamicamente data sets em tempo de execução.

Leituras por amostragem

Basicamente existem três operações de leituras partindo do cliente:

• Solicitação de leitura de todos os pontos digitais (STATE e STATE_SUPLEMENT)

• Solicitação de leitura de todos os pontos analógicos (REAL e DISCRETE)

• Solicitação de leitura de data sets pré-definidos no servidor. O conteúdo, isto é, as variáveis que virão em cada data set são as definidas no servidor, pelas especificações na tabela Points do servidor.

• Solicitação ao servidor da criação de data sets dinâmicos, pelo envio de uma lista de variáveis, e posterior solicitação de leitura destes data sets.

Data Sets Transfer Sets

Neste protocolo está disponível a funcionalidade de Data Sets Transfer Sets ou reporte não solicitado de dados.
Através dele é feita a solicitação pelo cliente, para a configuração no servidor, de um DS Transfer Set associado a um data set, e sua ativação.

O Data set a ser usado pelo Transfer Set pode seu um pre-definido no servidor ou pode ser um recém criado a pedido do cliente ( data set dinâmico).

O cliente solicita ao servidor um Transfer Set disponível, associa-o a um data set, e faz a configuração paramétrica do DS Transfer Set. Após isto faz a ativação do transfer set. Então o servidor inicia o envio espontâneo, de acordo com critérios configurados, dos dados dos data sets definidos no modelo de dados do servidor.

O cliente passa então a receber espontaneamente os dados vindos do servidor, na forma de Reports, sem necessitar executar pedidos de leitura (polling).
Os Reports são ações de envio de um conjunto de dados de variáveis constantes do dada set correspondente, executadas de acordo com os critérios de disparo destas ações. Cada Report, é identificado por um número de sequência, uma data/hora de publicação e pela causa de sua execução.

Comandos

O cliente pode enviar comandos para o servidor. Para isto devem ser configurados no cliente e no servidor Control Points para comandos de estados (abrir, fechar, etc.) ou para envio de set points de pontos analógicos. Também podem ser enviados Cartões de Serviço para devices ( cartões) de impedimento.
O disparo destes comandos é feito pela alteração de estado ou valor, dos tags Action.NET associados aos nomes destes Control Points no servidor.

Escrita em Pontos de indicação

Para os pontos de indicação (não Control Points), também é possível a operação de escrita sob demanda.
Nesta operação, os pontos de indicação para os quais se deseja escrita nos correspondentes existentes no servidor deve-se definir na tabela points, no Cliente, o campo Access Type como Write.
No servidor o Access Type deverá ser do tipo Read ou WriteSlave. Estes pontos não podem e não devem ser definidos como pertencentes a data sets.
A escrita será disparada pelo cliente a cada vez que houver alteração no estado ou valor do conteúdo destes pontos.

1. Sending key commands and set pointssetpoints to analog points to the client station

General operation

In the ICCP protocol, the client and server roles are well defined. In this implementation, the same module can be used to define a node with the client or server role. You can define for the channel only the client function, or only the server function, or even you can define two nodes, in the same channel to include in the same connection tcp ip the two activities, completely independent of each other.

Usually the data transfer from a server to a client is done by transfer sets. For the measurement and status data data set transfer sets (DSTS) are used. Transfer sets provide a mechanism for automatic data transfer. The client doesn’t have to poll the data points because the server will automatically send new data when a data point changes or on a periodic base.

Data set transfer sets are used to transfer the data of a data set. The data sets can either be predefined by the server or the client can create the data set after connection by online services. The data sets created by online services are called dynamic data sets.

The server provides for each domain a number of DSTSs. These transfer sets can be reserved by the client with the getNextDSTransferSet service. The client can then configure the transfer set parameters (transfer conditions, timeouts, period, …​) and then enable the transfer set.

So in general the process can look like below:

• the client connects to the server

• the client reserves a transfer set by the getNextDSTransferSet service

• the client creates a data set with the required indication points and protection equipment data points

• the client assigns the new data set to the transfer set

• the client enables the transfer set

• the server send the data set data to the client on events or periodically

If required a client can use different transfer sets (e.g. if you need different period times for different kind of data).

Data transfer from a client to a server usually consists of sending commands or set points. The receiver of the commands and set points are devices. Devices are part of the server data model.

A TASE.2 application can also be client and server at the same time to use the transfer mechanisms in both directions.

Server Mode

In this mode of use, by implementing the Server side, the module starts and waits for a client to connect to their communication.
During your activity, you get the current real-time data on Action.NET and send it on request or through an unsolicited reporting mechanism.
Among the functions and features included are:

• Definition of data called indication points

• Device model (commands)

• Datasets (Data Sets, get/set/create/delete/get directory)

• Data Set Transfer Transfers (Range, RBE, ...)

• Information Messages

• Bilateral Tables

• Secure (TLS) or non-secure connections

• Compliance blocks 1, 2, 4 and 5

Client Mode

In Client mode, the module attempts to establish a TcpTCP Ip connection to a server station to initiate data communication with it.
Its main function is to provide the functions to access the data of a specific server.
Implements facilities for requesting data from the server station through periodic read and sampling operations, and either to establish and enable an unsolicited data transfer mode on the server.
Among the main functions and characteristics found in the client are:

• Navigate the server data model (browsing);

• Create the Server Data Model on the client

• Read and write referral points

• Send commands, setpointsoffsets, and tags to devices (Control Points)

• Request the creation of dynamic data sets on the server

• Read datasets (Data Sets)

• Set up transfer sets (DS Transfer Sets)

• Turn instant messaging (IM) on/off sets

• Enable/disable DS transfer sets (Data Sets)

• Receive transfer set reports

ICCP Server Data Model

Data model

The server data model DataModel is made up of areas Domains, points of indication Indication Points, devices (Control Points), datasets Datasets and transfer sets DS Transfers Sets.
In TASE.2, variables are objects with names (Named Objects) that are part of the server address space. The variables can be system variables (such as "Bilateral_Table_ID", "Supported_Features", ...), indication points, protective equipment, and devices.
Variables can have two "scopes". The scope VDC or a user-defined domain-specific scope (ICC). Scope variables VDC are not part of any TASE.2 domain and are visible to all clients.

Domains

Scope variables VDC are identified only by the variable name. Domain scope variables are identified by the domain name and the name of the variable. Domain and Variable Name.
A TASE.2 domain is represented by a Domain Name. The domain object can contain all types of data points, datasets, and transfer sets.
A domain object is the first thing to create within a data model. In the addressing table Points, towards each tag Action.NET, the ICCP address will be included the
<Domínio>/<Variable name>, thus separated by a bar.
For each Data Model (for each communication channel Action.NET ICCP) can only be created one domain.
For the case of variables included in the VCC scope, addressing does not use the domain . It's like an empty domain. The address will have the form: <Variable name>.
The following are listed the existing data objects for the ICCP TASE environment.2

Indication points

TASE.2 supports different types of indication points (Indication Points).
The simplest version is simple boolean, integer, or floating (real) values. Optionally, a point of indication can have, in addition to its value or state:

• Quality field consisting of Flags quality indicators

• Date/time field (Timestamp normal or extended) that can represent date/time timestamps in seconds or milliseconds

• Cov field (value change counter, or Change Of Value

The following basic types are supported:

• STATE - State (assuming values 0.1, 2 or 3)

• STATE_SUPPLEMENT - State supplement.

• DISCRET - integer values up to 32bits.

• REAL - Floating-point values at 32 bits.

Device Models (Control Points)

There are three different types of control points:

• Commands – For the control of digital devices, represented by Action.Net tags of writing points such as keys and circuit breakers.

• Sending Device Service Tags - offside/blocking cards

• Discrete adjustment points - set points for integer tags (32bits)VCC

• Real adjustment points - set points for 32-bit double (floating point) tags.

In addition, there are two control classes:

• Select Before Operate (SBO) - Select before operating. In this mode, the client must first send a "selection" message to "arm" the control point. When selected, the client must send an "operate" message before the selected timeout.

• Direct Straight through. In this mode, the control consists of sending a simple "operate" command.

DataSets and DataSets Transfer Sets

Datasets are lists of variables (system variables and data points) that can be read or written with a single read or write request by the client. They are also the basis for unsolicited data set transfer actions.

Data sets can be statically defined on the Server, or they can be created dynamically on the server, at the client's request.

A dataset can contain the following (domain scope) system variables:

• Transfer_Set_Name - The name of the associated transfer set (consists of the domain name and the transfer set name)

• DSConditions_Detected - Conditions that caused the transfer set report

• Event_Code_Detected - The event code of the report

• Transfer_Set_Time_Stamp - The timestamp set by the transfer moment (in seconds)

In the server module implementation, each time a DataSet is declared, these system variables will be included in the dataset.

Information Messages

The information messaging engine consists of an information message transfer (IM) set and information message buffers.
The information message transfer set is a specific mechanism of client-server association that (when enabled by the client) sends information messages from the server to the client. The message transmission is triggered by the server. Information messages can be vcc or ICC domain-specific, defined on the server and client.
Information messages may contain textual data or arbitrary binary data. The length of the information messages is limited by the available information buffers and the maximum size of the MMS PDU.
Informational messages will only be sent to a customer when the Bilateral Table or Bilateral Table alallowslow it. With the bilateral table, information messages are restricted by their parameters of information reference, local reference and, scope (ICC or VCC).
A text-Action.Net tag should be set to support the exchange of information messages. See more details in the section on Point addressing.

Bilateral Tables

The two-sided table (BLT) is created by the server, defining a domain and, consists of the following elements:

• The ID bilateral Table - A unique name to identify the BLT.

• The application references customers (Ap-title and AE-Qualifier) - used for identification between server and client for the creation of a connection. See in the the application references server is created using the one defined as remote ap-title, i.e. the local ap-title of the client.

• A name of Domain Specific TASE.2. The client side can access all objects in the domain included in the table without restrictions.

• A list of data point access control specifications, not included in the domain.

• If a VCC scope data point is not part of this list, it is not accessible to the associated client.
  Bilateral tables are an important part of the access control mechanism.

• If no BLT is defined, access control decisions are based solely on the access rights defined for the data point. These access rights are the same for all clients.

• If bilateral tables are defined, access control decisions are based on the access rights defined for the data point and those defined in the bilateral table for the requesting client.

• If a data point is not part of the two-sided table for the requesting client, the request is denied and an "access to object denied" response is sent to the client.

• If a data point is specified in the BLT for a client, access is only allowed if it is allowed in the data point access control specification and in the access control specification in the BLT.

There

Operations performed by the Client

The entire task of creating the data model is done in the Server module.

The Client Module browses the Server Data Model and creates lists of variables and data sets from the server data, to use in the read request.
Locally, by reading your table Points creates the matching tables between the Action.NET and the names of ICCP variables received from the server.

Read operations will be performed periodically, according to sampling periodicity times defined in the configuration of the Nodes channel using this protocol. If these periodicity times are set to Zeros, sampling operations are not performed.

Alternatively, the Client can define and parameterize Reports, or Ds Transfer Sets, so that the server sends the data in an unsolicited manner, based on defined criteria. For these transfers you can use statically defined data sets on the server, or dynamically create data sets at run time.

Sample readings

Basically there are three operations of Readings starting from the customer:

• Request to read all digital points(STATE and STATE_SUPLEMENT)

• Request to read all analog pointsdata (REAL and DISCRETE)

• Request to read from data sets pre-defined on the server. The content, that is, the variables that will come in each date set are those defined on the server, by the specifications in the Points table of the server.

• Request to the server to create data sets by sending a list of variables, and later requesting reading of these data sets.

Data Sets Transfer Sets

In this protocol is available the functionality of Data Sets Transfer Sets or unsolicited reporting of data.
Through it is made the request by the client, for the configuration on the server, of a DS Transfer Set associated with a data set, and its activation.

The Data set to be used by the Transfer Set can be a pre-defined on the server or it can be a newly created on request of the client (dynamic data set).

The client requests the server for an available Transfer Set, associates it with a data set, and parametrically sets the DS Transfer Set. After this makes the activation of the transfer set. Then the server starts spontaneously sending, according to configured criteria, the data set data defined in the server data model.

The client then spontaneously receives the data from the server, in the form of Reports, without having to perform polling requests.
The Reports are actions of sending a set of variable data contained in the corresponding given set, executed according to the triggercriteria of these actions. Every Report, is identified by a sequence number, a publication date/time, and the cause of its execution.

Commands

The client can send commands to the server. For this they must be configured on the client and on the Control Points server for state commands (open, close, etc.) or for sending set points from analog points. Service Cards can also be sent to offside devices.
The triggering of these commands is done by changing the state or value of the tags Action.NET to the names of these Control Points on the server.

Written in Referral Points

For referral points (not Control Points), the write-on-demand operation is also possible.
In this operation, the indication points for which you want to be written in the corresponding ones on the server must be defined in the points table, in the Client, the Access Type field as Write.
On the server the Access Type must be of the type Read or WriteSlave. These points cannot and should not be defined as belonging to data sets.
The writing will be fired by the client each time there is a change in the state or value of the content of these points.