COMPONENTS

The server implements client/server architecture. The components include:

• Configuration

• Runtime

• Administration

• Event Log

CONFIGURATION

Client/Server interface that is used to modify the runtime project. The Configutation
can be launched by multiple users and supports remote Runtime configuration.

CSV IMPORT AND EXPORT

This server supports the import and export of TAG DATA in a "Comma Separated
Variable (CSV)" File(archivo). When using CSV import and export, tags are created
quickly in the desired application.

RUNTIME

The Runtime is the Server Component that starts as a SERVICE by default. Client can
connect to the runtime remotely or locally

ADMINISTRATION

The Administration is used to VIEW and/or MODIFY Settings and Launch Applications
that pertain to user management and the server. By default, the Administration is
started and sent to the System Tray (bandeja del sistema) when a user account logs
onto the operating system.

PROJECT

The Project file contains the CHANNEL, DEVICE, AND TAG definitions as well as
preferences and other saved settings.

EVENT LOG

The Event Log SERVICE collects INFORMATION, WARNING, ERROR, and SECURITY
events. These events are sent to the Configuration's EVENT LOG window for viewing.
PROCESS MODES

The Runtime process mode can be changed while the server is running; however, doing
so while a client is connected interrupts the connection for a short period. The modes
of operation are:

• SYSTEM SERVICE

• INTERACTIVE

SYSTEM SERVICE

By default, the server is installed and runs as a service. When System Service is
selected, the Runtime does not requiere user intervention and starts when the
operating system opens. This provides USER INDEPENDENT ACCESS to the server by
the clients.

INTERACTIVE

When Interactive is selected, the Runtime REMAINS STOP UNTIL A CLIENT ATTEMPTS
CONNECT TO IT. Once started, it runs until ALL CLIENTS have disconnected and then
shuts down. The Runtime also SHUTS DOWN IF the user account logs off the operation
system.

Note: The Runtime process mode may be changed to meet client applications' needs
through the Administration settings dialogs.

System Service is required for the following conditions:

• When iFIX is required to run on an operating system while UAC is enabled.

Interactive is required for the following conditions:

• When a communication interface (such as DDE) must exchange information

with the user desktop and the server is installed on Windows Vista, Windows
Server 2008, or later operating systems.
INTERFACES AND CONNECTIVITY

This communications server simultaneously supports the CLIENT/SERVER

TECHNOLOGIES listed below. CLIENT APPLICATIONS can use any of these technologies
to access data from the server at the same time:

OPC DA

Supported Versions: 1.0a; 2.05a; 3.0

Overview

“OPC” stand for Open Productivity and Connectivity in industrial automation and the
enterprise systems that support industry. It is a client/server technology where one
application acts as the server (providing data) and another acts as a client (using data).

OPC is composed of a series of standards specifications: OPC Data Access (DA) is the
most prolific standard. OPC DA is a widely accepted industrial communication standard
that enables data exchange between multi-vendor devices and control applications
without proprietary restrictions. An OPC server can communicate data continuously
among PLCs on the shop floor, RTUs in the field, HMI stations, and software
applications on desktop PCs. OPC compliance makes continuous real-time
communication possible (even when the hardware and software are from different
vendors.)

OPC Data Access 1.0a was the original specification developed by the OPC Foundation
in 1996. Although it continues to be supported by many of the OPC client applications
in use today, OPC Data Access 2.0 enhanced OPC better utilizes the underlying
Microsoft COM technology.

OPC Data Access 3.0 is the latest version of the OPC DA interface

OPC AE

OPC UA

OPC .NET

DDE

Supported Formats

CF_Text
XL_Table

Advanced DDE

Overview

Although this server is first and foremost an OPC server, there are still a number of
applications that require Dynamic Data Exchange (DDE) to share data. As such, the
server provides access to DDE applications that support one of the following DDE
formats: CF_Text ; XL_Table, and Advanced DDE.

CF_Text and XL_Table are standard DDE formats developed by Microsoft for use with
all DDE aware applications.

Advance DDE is a high-performance format supported by a number of client

applications specific to the industrial market.

CF_Text and XL_Table

The DDE format CF_Text is the standard DDE format as defined by Microsoft. All DDE
aware applications suppor the CF_Text format. XL_Table is the standard DEE format as
defined by Microsoft that is used by Excel

Advanced DDE

Advanced DDE is the DDE format defined by Rockwell Automation (Allen-Bradley).

Today, all Rockwell client applications are Advanced DDE aware. Advanced DDE is a
variation on the normal CF_Text Format, wich allows larger amounts of data to transfer
between applications at higher rates of speed (and with better error handling).

Requirements

For the DDE interface to connect with the server, the Runtime must be allowed to
interact with desktop. (INTERACTIVE process mode)

FastDDE/SuiteLink

Overview

FastDDE is a DDE format defined by Wonderware Corporation. It allows larger amounts

of data to transfer between applications at higher speed (and with better error
handling) than generic DDE. SuiteLink is a client/server communication method that
has succeeded FastDDE. It is TCP/IP based and has improved bandwidth and speed.
Both FastDDE and SuiteLink are supported by all Wonderware client applications.
Note: The Wonderware connectivity toolkit is used to simultaneously provide OPC and
FastDDE/SuiteLink connectivity while allowing for quick access to device data without
the use of intermediary bridging software

For security reasons, it is recommended that users utilize the most recent WonderWare
DAServer Runtime Components. For more information and available downloads, refer
to the Invensys Global Technical Support WDN website

Requirements: For the FastDDE interface to connect with the server, the Runtime must
be allowed to interact with the desktop.

iFIX Native Interfaces

Thin-Client Terminal Server

ThingWorx Native Interface

Settings— User Manager

The User Manager controls client Access to the project’s objects (which are the
channels, devices, tags, etc.) and their corresponding functions. The User Manager
allows permissions to be specified by user groups. For example, the User Manager can
restrict the Data Client user access to project tag data base on its permissions from the
Anonymous Clients user group. The User Manager can also transfer user information
between server installations through its import/export functions.

The User Manager has three built-in groups that each contains a built-in user. The
default groups are:

Administrators

Server Users

Anonymous Clients

The default users are:

Administrator

Default User

Data Client

Users cannot rename or change the description fields. Neither the default groups nor
the defaults users can be disable

Note: Although the Administrator’s settings cannot be changed, additional

administrative users can be added.

VOC: BIND: enlazar; obligar; atar; ligar; encuadernar; ceñir; unir a; vincular con; ribetear;
aprisionar; apretar; trabarse; estreñir; endurecer; hacer; fraguar; tener fuerza
obligatoria; recogerse; ratificar; encordar; rematar; agavillar; liar. <verbos>
<sustantivos>: el lazo; el atasco; la lata.

Config API Service --- Configuration

Enable

Choose Yes to enable the Configuration API Server. If disabled (No); the service runs,
but does not bind to the HTTP and HTTPS Ports and clients CANNOT Access the server.

Enable HTTP: Select NO to limit data transfer to only secure/encrypted protocols and
endpoints. Select Yes to allow unencrypted data transfer.

• HTTP is only recommended for INTERNAL NETWORKS because user

authentication is transmitted as PLAIN TEXT.

• To prevent external Access over unsecure HTTP, this port should be blocked by
the Windows firewall.

HTTP Port

Specify the TCP/IP port for the REST client to communicate over uncrypted HTTP. The
valid range is 1 to 65535. HTTP and HTTPS ports must not match. The default port
number of 57412.

HTTPS Port

Specify the TCP/IP port for the REST client to communicate over secure HTTP. The valid
range is 1 to 65535. HTTP and HTTPS ports must not match. The default port number of
57512.

CORS Allowed Origins

Specify an approved “White-list” of comma-separated DOMAIN specifications that may

access the Configuration API Server for Cross Origin Resource Sharing (CORS) requests.

Restore Defaults:

Click to blue link to the right to restore the default HTTP and HTTPS port values.

View in Browser

Click the blue address link to the right to open the Configuration API documentation
landing page in a browser.

View in Browser(SSL)
Click the blue address link to the right to open the Configuration API documentation
landing page in a browser via the secure URL.

TRANSACTION LOGGING.

Arquitectura Cliente/Servidor

Cliente

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al

servidor, se le conoce con el término front-end.

El Cliente normalmente maneja todas las funciones relacionadas con la manipulación y

despliegue de datos, por lo que están desarrollados sobre plataformas que permiten
construir INTERFACES GRÁFICAS DE USUARIO (GUI), además de acceder a los servicios
distribuidos en cualquier parte de una red.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

• Administrar la interfaz de usuario

• Interactuar con el usuario

• Procesar la lógica de la aplicación y hacer validaciones locales

• Generar requerimientos de bases de datos

• Recibir resultados del servidor

• Formatear resultados

Servidor

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún

recurso administrado por él. Al proceso servidor se le conoce con el término back-end.
El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las
“REGLAS DEL NEGOCIO” y los recursos de datos.

Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:

• Aceptar los requerimientos de bases de datos que hacen los clientes.

• Procesar requerimientos de bases de datos

 • Formatear datos para transmitirlos a los clientes.

• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de

datos.

Características de la arquitectura Cliente/Servidor

Las características básicas de una arquitectura Cliente/Servidor son:

• Combinación de un cliente que interactúa con el usuario, y un servidor que

interactúa con los recursos compartidos. El proceso del cliente proporciona la
interfaz entre el usuario y el resto del sistema. El proceso del servidor actúa
como un motor de software que maneja recursos compartidos tales como bases
de datos, impresoras, módems, etc.

• Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto
a recursos de cómputo como velocidad del procesador, memoria, velocidad y
capacidades del disco e input-output devices (I/O)

• Se establece una relación entre procesos distintos, los cuales pueden ser
ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo
de la red.

• Existe una clara distinción de funciones basada en el concepto de “servicio”,

que se establece entre cliente y servidores.

• La relación establecida puede ser de muchos a uno, en la que un servidor puede

dar servicio a muchos clientes, regulando su acceso a recursos compartidos.
 • Los clientes corresponden a procesos activos en cuanto a que son éstos los que
hacen peticiones de servicios a los servidores. Estos últimos tienen un carácter
pasivo ya que esperan las peticiones de los clientes.

• No existe otra relación entre clientes y servidores que no sea la que se establece
a través del intercambio de mensajes entre ambos. El mensaje es el mecanismo
para la petición y entrega de solicitudes de servicio.

• El ambiente es HETEROGÉNEO. La plataforma de hardware y el sistema

operativo del cliente y del servidor no son siempre la misma. Precisamente una
de las principales ventajas de esta arquitectura es la posibilidad de conectar
clientes y servidores independientemente de sus plataformas.

• El concepto de ESTABILIDAD tanto horizontal como vertical es aplicable a

cualquier sistema Cliente/Servidor. La ESCALABILIDAD horizontal permite
agregar más estaciones de trabajo activas sin afectar significativamente el
rendimiento. La escalabilidad vertical permite mejorar las características del
servidor o agregar múltiples servidores.

Ventajas del esquema Cliente/Servidor

Entre las principales ventajas del esquema Cliente/Servidor están:

• Unos de los aspectos que más ha promovido el uso de Sistemas

Cliente/Servidor, es la EXISTENCA DE PLATAFORMAS DE HARDWARE CADA VEZ
MÁS BARATAS. Esta constituye a su vez una de las más palpables ventajas de
este esquema, la posibilidad de utilizar máquinas considerablemente más
baratas que las requeridas por una solución centralizada, basada en sistemas
grandes. Además, se pueden utilizar COMPONENTES, tanto de hardware como
de software, DE VARIOS FABRICANTES, lo cual contribuye considerablemente a
la reducción de costos y favorece la flexibilidad en la implantación y
actualización de soluciones.

• El esquema Cliente/Servidor facilita la integración entre sistemas diferentes y

comparte información permitiendo, por ejemplo, que las máquinas ya
 existentes puedan ser utilizadas pero utilizando interfaces más amigables al
usuario. De esta manera, podemos integrar PCs con sistemas medianos y
grandes, sin necesidad de que todos tengan que utilizar el mismo sistema
operacional.

• Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos

bajo este esquema tienen mayor interacción y más intuitiva con el usuario. En el
uso de interfaces gráficas para el usuario, el esquema Cliente/Servidor presenta
ventaja, con respecto a uno centralizado, de que no es siempre necesario
transmitir información gráfica por la red pues esta puede residir en el cliente, lo
cual permite aprovechar mejor el ancho de banda de la red.

• Una ventaja adicional del uso del esquema Cliente/Servidor es que es más rápido
el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear las
herramientas existentes (por ejemplo, los servidores de SQL o las herramientas
de más bajo nivel como los SOCKETS o el RPC).

• La estructura inherente modular facilita además la INTEGRACIÓN DE NUEVAS

TECNOLOGÍAS y el CRECIMIENTO DE LA INFRAESTRUCTURA COMPUTACIONAL,
favoreciendo así la ESCALABILIDAD de las soluciones.

• El esquema Cliente/Servidor contribuye, además, a proporcionar, a los

diferentes departamentos de una organización, soluciones locales, pero
permitiendo la integración de la información relevante a nivel global.

Desventajas del esquema Cliente/Servidor

Entre las principales desventajas del esquema Cliente/Servidor están:

• El MANTENIMIENTO de los sistemas es MÁS DIFÍCIL pues la interacción de

diferentes partes de hardware y de software, distribuidas por distintos
proveedores, lo cual dificulta el diagnóstico de fallas.
 • Se cuenta con muy ESCASAS HERRAMIENTAS para la administración y ajuste del
desempeño de los sistemas.

• Es importante que los clientes y los servidores UTILICEN EL MISMO

MECANISMO (por ejemplo, SOCKETS O RPC), lo cual implica que deben tener
MECANISMOS GENERALES QUE EXISTAN EN DIFERENTES PLATAFORMAS.

• Además, hay que tener ESTRATEGIAS para el MANEJO DE ERRORES y para

mantener la CONSTENCIA DE LOS DATOS.

• La SEGURIDAD de un esquema Cliente/Servidor es otra preocupación

importante. Por ejemplo, se deben hacer VERIFICACIONES en el cliente y en el
servidor.

• El DESEMPEÑO es otro de los aspectos que se deben tener en cuenta en el

esquema Cliente/Servidor.

• PROBLEMAS de este estilo pueden presentarse CONGESTIÓN en la red,

dificultada de TRÁFICO de datos, etc.

MODELO CLIENTE SERVIDOR EN EL SISTEMA MEXVOX ---- ActiveX ¿?

ARQUITECTURA CLIENTE/SERVIDOR

SERVIDOR: ROL que desempeña un equipo ofreciendo un conjunto de servicios a los

clientes, tales como manejo de archivos, impresión, páginas web, direccionamiento de
correo electrónico, actualización de BD y control de acceso,

CLIENTE: ROL que desempeña un equipo demandando servicios de los servidores, pero
también puede realizar procesamiento local, tales como desplegar páginas web,
mostrar ventanas y generar correo electrónico.

Eventualmente un mismo equipo puede desempeñar ambos roles

TAREAS se pueden distribuir entre estos ROLES:

• PRESENTACIÓN: SOFTWARE que permiten PRESENTAR en forma adecuada los

RESULTADOS de una APLICACIÓN, p. ej.: Ventanas en Windows, páginas web en
un navegador.

• APLICACIÓN: SOFTWARE que entrega un resultado útil para el usuario (LÓGICA

DEL NEGOCIO), P.EJ. Consulta de una factura, valorización de un inventario.

• ADMINISTRACIÓN DE DATOS: manejo de los datos (en una BD) que sirven a las
aplicaciones de la lógica de negocio, p ej. Datos de los productos de una factura,
productos en inventario.
CLIENTE: cualquier usuario o programa que quiere realizar una operación sobre el
sistema. Para apoyarlo, el sistema debe tener una CAPA DE PRESENTACIÓN a través de
la cual el usuario puede enviar las operaciones y obtener un resultado.

LÓGICA DE LA APLICACIÓN: establece QUÉ OPERACIONES se pueden realizar sobre el

sistema y CÓMO se llevarán a cabo, Se encarga de HACER CUMPLIR las REGLAS DE
NEGOCIO y establece los PROCESOS DE NEGOCIO, servidores con la lógica codificada,
etc.

ADMINISTRADOR DE RECURSOS: trata con la ORGANIZACIÓN DE LOS DATOS

necesarios (almacenamiento, indexación y recuperación) para apoyar la lógica de la
aplicación. Ej BD relacional, BD en XML, archivo Excel, o cualquier otro sistema con
capacidades de CONSULTA y PERSISTENCIA.
• Cada cuadro representa una parte del sistema. Cada flecha es una conexión
entre dos partes del sistema.

• Cuantas más cajas, más MODULAR es el sistema: más oportunidades para la

DISTRIBUCIÓN y el PARALELISMO. Esto permite ENCAPSULACIÓN, diseño
basado COMPONENTES, la reutilización.

• A más cajas, a más flechas: más SESIONES (CONEXIONES) deben mantenerse,

más coordinación es necesaria. El sistema se vuelve más complejo de controlar y
gestionar.

• A más cajas, mayor será el número de decisiones de contexto y pasos

intermedios que pasar antes de llegar a los datos. El rendimiento se resiente
considerablemente.

• Los diseñadores de sistemas tratan de EQUILIBRAR la capacidad de los equipos

implicados y las ventajas y desventajas de las diferentes arquitecturas.
 • La CAPA DE PRESENTACIÓN, LÓGICA DE APLICACIÓN y GESTIÓN DE
RECURSOS se construye como una entidad monolítica.

• Usuario/programas acceden al sistema acceden al sistema a través de

terminales de pantalla,

• Pero lo que se muestra y cómo aparece es CONTROLADO POR EL

SERVIDOR.

• Llamadas terminales tontas.

• Esta era la arquitectura típica de las aplicaciones de MAINFRAME, ofreciendo

varias ventajas:

• Flujo de control sin decisiones de contexto (todo sucede dentro del

sistema).
 • Todo está CENTRALIZADO; gestión y control de los recursos es más fácil.

• Diseño altamente optimizado al ELIMINA LA SEPARCIÓN ENTRE LAS

CAPAS.

Al hacerse las computadoras más poderosas, la CAPA DE PRESENTACIÓN se mueve al

cliente. Esto tiene varias ventajas:

• Los clientes son INDEPENDIENTES ENTRE SÍ: se puede tener varias capas de
presentación dependiendo de lo que cada cliente quiere hacer.

• Se puede aprovechar la potencia de cálculo en la máquina cliente teniendo

capas de presentación más sofisticadas. Esto también AHORRA RECURSOS de la
máquina SERVIDOR.

• Se introduce el concepto de API (APPLICATION PROGRAM INTERFACE). Una

interfaz para invocar el Sistema DESDE EL EXTERIOR.
 • El administrador de recursos sólo tiene un cliente: la LÓGICA DE LA APLICACIÓN.
Esto AYUDA mucho con el RENDIMIENTO ya que NO HAY CONEXIONES NI
SESIONES PARA MANTENER,

El Middleware es un NIVEL DE INDIRECCIÓN entre los CLIENTES y las demás CAPAS DEL
SISTEMA.

Se introduce una CAPA ADICIONAL de la lógica de negocio (APLICACIÓN) que abarca

todos los sistemas subyacentes.

De esta manera, un sistema middleware:

• Simplifica el DISEÑO de los CLIENTES mediante la REDUCCIÓN DEL NÚMERO DE

INTERFACES.

• Proporciona un acceso transparente a los sistemas subyacentes.

• Actúa como PLATAFORMA para la FUNCIONALIDAD INTER-SISTEMA y la lógica
de aplicación de alto nivel

• Se encarga de LOCALIZAR LOS RECURSOS, el ACCESO a ellos, y la RECOLECCIÓN

de resultados.

• En un sistema de tres niveles, las tres capas están completamente separadas.

• Para algunos, un sistema basado en middleware es una arquitectura de 3 capas.

Esto es un poco simplista, pero es correcto conceptualmente ya que los
sistemas subyacentes pueden ser tratados como cajas negras.

• Los sistemas de 3 niveles tienen las mismas ventajas que un sistema de

MIDDLEWARE y también sus desventajas.
 • En la práctica, las cosas no son tan simples como parecen… hay varias capas
ocultas que no son necesariamente triviales; ej. Los WRAPPERS.

Protocolo DDE
• Realizar e implementar comunicaciones de manera más eficiente usando un
protocolo de comunicación dinámico bajo el ambiente de Windows

• Es un protocolo de comunicaciones entre aplicaciones, desarrollado por

Microsoft.

• DDE es un sistema estándar en WINDOWS de muy sencillo uso

• Tiene una estructura de C/S

• El intercambio de información se realiza a través de una memoria.

• Permite que una aplicación pueda ejecutar los comandos de la otra.

Aplicaciones DDE
La comunicación entre aplicaciones que usan el protocolo DDE, establecen una
ESTRUCTURA DDE. Esta estructura es:
CLIENTE: programa que puede recibir datos DDE
SERVIDOR: programa que puede enviar datos al bus DDE
CLIENTE/SERVIDOR: programa que puede enviar/recibir datos a la vez.
MONITOR: puede acceder a mensajes, sin modificaciones

Comunicaciones DDE
Se basa en una convención de tres tipos de parámetro:
1. Aplicación: nombre del archivo del programa.
2. Tópico: ruta completa del proyecto desde el cual se lee
 3. Elemento: Nombre de la variable que se va a leer (Tag Name)

Los parámetros anteriores constan de: (InTouch)

Aplicación: VIEW
Tópico: TAG NAME
Elemento: NOMBRE DEL TAG NAME QUE SE QUIERE ENLAZAR

Configuración (WONDERWARE INTOUCH)

• Se crea un ACCESS NAME para poder enlazar datos vía DDE de otras
aplicaciones a InTouch
• Para crear el ACCESS NAME:
Menu Special- Acces Name-Add
• A cada Access name se puede asociar una aplicación y un tópico

• Access: Nombre del Enlace: se puede asociar a una aplicación y a un tópico.

• Node Name: solo se usa cuando la comunicación también será con otra PC. Se
deja en blanco si la COM es entre aplicaciones internas al PC

• Application Name: Nombre de la aplicación de la que se quiere leer (PJ: EXCEL)

• Topic Name: Nombre del tópico del que se requiere leer (pj: nombre del archivo
EXCEL del que se quiere leer)

• Enable Secondary: Permite establecer un ACCESS NAME Secundario.

MICROSOFT ACCESS 2016

• Extensión.mbd
• Base de datos. Herramienta que permite crear rápidamente APLICACIONES DE
BASE DE DATOS basadas en el explorador. Se almacenan automáticamente en la
BASE DE DATOS de la NUBE.

• Integrar con varias fuentes de datos:

1. Integra los datos entre Access y APLICACIONES de línea de negocio

La Biblioteca de conector en Access ofrece muchas formas de integrar

DATOS DE APLICACIÓN y FUENTES DE DATOS que dirigen la empresa.

Los escenarios integrados por las fuentes de datos modernas generan

OBJETOS VISUALES e información agregados en la interfaz familiar de
ACCESS.

2. ALMACENAR DATOS EN SQL

Almacenar los datos en SQL Server y Microsoft Azufre SQL. Para permitir
una mayor:
• Confiabilidad
• Seguridad sólida
• ESCALABILIDAD
• Facilidad de Administración a largo plazo

Las aplicaciones ACCESS ahora usan la sintaxis ACCESS

ESTÁNDAR y un BACK-END CRÍTICO, tanto si se trata de una
Implementación local como en la nube.
Product Overview

KEPServerEx is the industry’s leading connectivity platform that provides a single

source of industrial automation data to all of your applications. The platform
design allows users to connect, manage, monitor, and control diverse automation
devices and software applications through one intuitive user interface.

KEPServerEX leverages (aprovecha, potencia, apalanca, influencia) OPC (the

automation industry’s standard for interoperability) and IT-centric communication
protocols (such as SNMP, ODBC, and web services) to provide users with a single
source for industrial data.

Features

KEPServerEX provides critical technical features that enable accessibility,

aggregation, optimization, connectivity, security, and diagnostics. Expand the
topics below to learn more about these features.

Accessibility

KEPServerEX provides data access for client applications (such as MES and
SCADA) and IoT and Big Data analytics software via OPC, proprietary protocols
(including GE NIO, SuiteLink/FastDDE, and Splunk), IT protocols (including MQTT,
REST, ODBC, and SNMP), and flow measurement export to common Oil & Gas
industry formats.

OPC

OPC is the leading standard for industrial automation connectivity. KEPServerEX

supports the OPC Unified Architecture (OPC UA) specification and many of the
OPC Classic specifications, including OPC Data Access (OPC DA), OPC Alarms
and Events (OPC AE), and OPC Historical Data Access (OPC HDA).

Automation Interfaces

KEPServerEX offers preferred data access for leading automation software,

including iFIX by GE Intelligent Platforms (NIO) and InTouch by Wonderware
(SuiteLink/FastDDE).
IT Interfaces

KEPServerEX supports multiple interfaces for integration with IT applications,

including ODBC for logging information to a database and SNMP for providing
information to a Network Management System (NMS). With the advent of IoT and
Big Data applications, KEPServerEX now includes the ability to communicate with
Splunk software and Cloud services via the Industrial Data Forwarder for Splunk. It
also provides data access for the ThingWorx platform, enabling you to develop
and deploy smart-connected solutions for the IoT.

Cloud Interfaces

With the IoT Gateway, KEPServerEX can seamlessly stream real-time industrial
control data directly into Big Data and analytic software for Business Intelligence
and Operational Excellence. Its customizable data format supports most MQTT and
REST applications—enabling users to choose the vendors and communication
methodologies right for their system. The ThingWorx Native Interface also provides
data to the ThingWorx platform using the secure ThingWorx AlwaysOn™ protocol
for high throughput.

Exporters

Some applications require information to be made available from a file or

database. This information is typically exported at a predefined rate and includes
both current and historical data. KEPServerEX has the ability to export historical
Electronic Flow Measurement (EFM) data (via the EFM Exporter advanced plug-in)
or historical trend data (via supported drivers) to files and/or databases.

OPTIMIZATION

KEPServerEX optimizes communications and reduces network and device load via
data conditioning and reduction, customized load balancing, and protocol-
specific optimization.

Data Conditioning and Reduction

In addition to providing raw values to connected applications, KEPServerEX can

perform linear or square root scaling, basic arithmetic expressions, and apply
deadbands. These features utilize minimal bandwidth and resources by providing
only the most critical updates.

Redundancy

KEPServerEX is used in critical applications where highly-reliable systems are

required for maximum uptime. It includes the ability to define redundant network
paths, primary and secondary data sources, and applicable failover criteria.
Load Balancing

In large networks that have many devices and applications requiring information,
flexible control is necessary to allow for customized load-balancing of data
collection and information flow. KEPServerEX provides tools to schedule the
frequency of communications and throttle the demand across the network.

Communications

KEPServerEX optimizes communications with devices by aggregating identical

requests from different applications whenever possible. Multiple demands on data
can be batched together into the fewest requests possible. These optimizations
are unique to each protocol and are designed to reduce network overhead and
device processing.

Machine-to-Machine Linking

In a typical industrial automation network, devices and controllers must

communicate with one another even if they are not from the same manufacturer
or do not support the same protocol. KEPServerEX provides the ability to establish
links between data values in different data sources, allowing Machine-to-Machine
(M2M) communications as close to the device as possible.

Programmatic Changes

KEPServerEX provides a REST-based API that enables users to remotely apply

programmatic changes to the configuration via third-party client applications
(including SCADA, HMI, IoT applications, and simple web applications). These
changes include adding, editing, reading, and deleting objects (such as channels,
devices, and tags) in the server. The Configuration API enables programmers to
create simple webpages where users can identify the properties that change, and
then programmatically create the channels, devices, and tags to the company
standard. It also enables the use of templates to standardize creation and naming
among different types of devices—ensuring consistency and increasing user
efficiency.

AGGREGATION

KEPServerEX simplifies the configuration of connected applications by providing a

single point of entry to all information- eliminating the need to purchase, operate,
troubleshoot, and maintain multiple disparate solutions for discrete connectivity.

Centralized Platform

KEPServerEX can support connections to thousands of data sources and provide

information to hundreds of applications. The platform design simplifies the
configuration of the connected applications by providing a single point of entry to
all information. KEPServerEX also enables troubleshooting and issue diagnosis,
provides control to the access of information based on user roles, and the ability to
restrict the frequency of communications over bandwidth-limited telemetry-based
environments.

Unified Configuration

KEPServerEX provides a unified configuration for managing connectivity to any

data source. Anything can be added, configured, or deleted while the server is
on-line and operational. Users can configure projects manually using a step-by-
step wizard or programmatically through the export and import of XML and CSV
files, and via REST calls over the Configuration API.

Data Storage and Retention

KEPServerEX is capable of archiving the real-time data it collects to local storage.

By leveraging the Local Historian advanced plug-in, applications can access this
historical data (via OPC HDA) for future analysis. KEPServerEX can also store
information in any ODBC-compliant database using the DataLogger advanced
plug-in, which has a store-and-forward capability for when a database is
unreachable or unable to process the information fast enough.

CONNECTIVITY

KEPServerEX supports the broadest range of drivers available, including current

and legacy devices across various verticals, a variety of wired and wireless
network mediums, and connectivity to databases, custom software applications,
and other OPC servers.

Driver-Based Access

KEPServerEX offers the broadest range of drivers available, supporting devices

across various verticals within industrial automation. While most drivers act as
masters that initiate requests, there are many drivers that can emulate a device
where communications are driven by a controller. KEPServerEX drivers also support
a variety of wired and wireless network mediums for Ethernet, serial, and
proprietary networks. Although most drivers connect directly with hardware
devices, some are designed to connect with other applications—such as
databases, custom software applications, or other OPC servers.
Simulation

As systems are configured, components must be implemented and tested before

the entire system becomes available. KEPServerEX allows any data source to be
placed into simulation mode prior to deployment. In addition, the Memory Based
driver can be configured to create a range of static and dynamic data points. The
Advanced Simulator driver can leverage a database and its contents to drive
application-specific simulation data into connected applications.

Telemetry Enviroments

Industrial automation equipment can be deployed in a dry and heated factory,

but it can also be installed inside a vehicle, on a remote pipeline, or in a well or
pump station. In these remote environments, there are often a variety of telemetry
solutions in use like cellular, radio, or satellite modems. KEPServerEX supports these
telemetry configurations and provides additional ways to optimize
communications through virtual networks, timing parameters, device demotion,
and by scheduling communications across devices.

Rapid Deployment

As automation networks have grown from ten controllers to thousands of

controllers, tools that aid and accelerate deployment are critical to a solution’s
success. KEPServerEX provides many tools that speed the deployment of new
devices, including Automatic Tag Generation (ATG) and Device Discovery (when
supported by the device and communication protocols). Users can also export,
manipulate, and import an XML project file to programmatically define the
configuration.

SECURITY

KEPServerEX includes a variety of tools that control user access to the server, data
source, or data values, regulate read/write access, provide the ability to connect
or disconnect client applications, and support the configuration of secure data
tunnels.

Configuration

Access to the KEPServerEX configuration can be restricted through the User

Manager. This tool allows the administrator to define user groups and users with
restricted access to certain project configuration tasks, and also provides the
ability to disconnect client applications.
Runtime

There are various tools available within KEPServerEX to control user access to the
server, data source, or data values. The Security Policies advanced plug-in limits
access based on OPC UA user credentials while supporting default handling for
anonymous users (both OPC UA and other client interfaces). The ability to
dynamically address information can be disabled, limiting user access to tags
defined within the project. KEPServerEX supports a number of secure client
standards including SNMP (v3 security), OPC UA, and OPC DA (DCOM security) to
further restrict access to the server, as well as a number of secure device protocols
to meet the requirements of DNP3, SNMP, and OPC UA data sources. Secure data
tunnels can be configured by leveraging multiple KEPServerEX instances at remote
endpoints to pass data through firewalls and meet authentication and encryption
requirements across the Internet.

DIAGNOSTICS

KEPServerEX isolates device and application communications for troubleshooting,

offering OPC diagnostics for real-time and historical views of OPC events.
KEPServerEX also supports communications diagnostics to capture the protocol
frames transferred between the server and any device.

OPC Diagnostics

OPC Diagnostics provide a real-time and historical view of OPC events between
any OPC client and the server, including method calls made by the client or
callbacks made by the server. The ability to view actual communications and
responses is invaluable when troubleshooting client accessibility. The diagnostics
tools within KEPServerEX greatly speed deployment and reduce downtime.

Communications Diagnostics

Communication Diagnostics provide real-time capturing of the protocol frames

transferred between the server and any device, as well as indications on the
driver's performance. All read and write operations can be viewed or tracked
directly in an OPC client application using built-in diagnostics tags. This is useful
when modifying key communication parameter settings (such as baud rate, parity,
or Device IDs), because corrections are immediately visible.
Third-Party Diagnostics Integration

Diagnostics information can be viewed within KEPServerEX and by third-party

applications. Diagnostics information is provided through system-defined tags and
accessible to the same clients connecting to the data sources. KEPServerEX logs
event information, which is accessible within the configuration tool or to any
application that supports the OPC Alarms and Events specification.

APPLICATION CONNECTIVITY

The KEPServerEX connectivity platform offers simultaneous accessibility to client

applications through an ever-growing list of supported industry standards,
proprietary technologies, and native client interfaces. Expand the topics below to
learn more.

DDE NATIVE INTERFACE

Dynamic Data Exchange (DDE) allows applications to share data in a

Microsoft Windows environment. As such, the server provides access to DDE
applications that support one of the following DDE formats:

 CF_Text and XL_Table are standard DDE formats developed by

Microsoft for use with all DDE-aware applications.
 Advanced DDE is a variation of the normal CF_Text format defined by
Rockwell Automation that allows large amounts of data to transfer
between applications at higher rates of speed.
 Network DDE (Net DDE) is the standard for remote DDE connection as
defined by Microsoft that uses the CF_Text format.

Supported Formats: CF_Text, XL_Table, Advanced DDE, Network DDE

FASTDDE/SUITELink Native Client Interface

FastDDE is a DDE format defined by Wonderware Corporation that enables large

amounts of data to transfer between applications at higher speed (and with
better error handling) than generic DDE. SuiteLink is a client/server communication
method that has succeeded FastDDE. It is TCP/IP-based and has improved
bandwidth and speed. Both FastDDE and SuiteLink are supported by all
Wonderware client applications.
IFIX Native Client Interface

The iFIX native client interface simplifies the connection task by allowing a direct
connection to the local iFIX application without the use of the iFIX OPC Power Tool.
When supported, this interface also has the ability to refine the connection
between the server and the iFIX Process Database (PDB).

En la nube (CLOUD):

Splunk

The Splunk API enables the streaming of real-time industrial data into
Splunk® software and Cloud services.

SNMP

Simple Network Management Protocol (SNMP) is a protocol developed by the

Internet Architecture Board for exchanging information between network devices.

REST

The Representational State Transfer (REST) protocol is a stateless model for

accessing resources on the server via requests.

MQTT

The Message Queuing Telemetry Transport (MQTT) protocol is a publish/subscribe

protocol designed for SCADA and remote networks. It focuses on minimal
overhead (2-byte header) and is recommended when bandwidth is limited.

ODBC

Open Database Connectivity (ODBC) is an open standard API developed by

Microsoft for accessing a database (such as Microsoft Access, dBase, Excel, and
more).

OPC.NET

OPC .NET is a family of APIs provided by the OPC Foundation that leverage
Microsoft's .NET technology and allow .NET clients to connect to the server.
KEPServerEX supports OPC .NET 3.0 WCF, formally known as OPC Xi. Unlike
other OPC .NET APIs, OPC .NET 3.0 uses Windows Communication
Foundation (WCF) for connectivity, avoiding DCOM issues and providing
secure communication via multiple communications bindings,
consolidation of the OPC Classic interfaces, and the simple development,
configuration, and deployment of Windows environments.
KEPServerEX adds OPC .NET 3.0 support using a customized version of the
OPC .NET 3.0 WCF Wrapper supplied by the OPC Foundation.

Supported Versions: 1.20.2

OPC ALARMS AND EVENTS

OPC Alarms and Events (AE) is a specification developed by the OPC

Foundation to standardize the way that alarm and event information is
shared among systems. Using the standard, AE clients can receive alarms
and event notices for equipment safety limits, system errors, and other
abnormal situations.

Supported Versions: 1.0 and 1.10

OPC DATA ACCESS (DA)

"OPC" stands for Open Platform Communications in industrial automation

and the enterprise systems that support industry. It is a client/server
technology where one application acts as the server (providing data) and
another acts as a client (using data).

OPC is composed of a series of standards specifications. OPC Data Access

is the most prolific and enables data exchange between multi-vendor
devices and control applications without proprietary restrictions. An OPC
server can communicate data continuously among PLCs on the shop floor,
RTUs in the field, software applications on desktop PCs, and much more.
OPC compliance makes continuous real-time communication possible
(even when the hardware and software are from different vendors).

OPC Data Access 1.0a was the original specification developed by the
OPC Foundation in 1996. Although it continues to be supported by many of
the OPC client applications in use today, OPC Data Access 2.0 Enhanced
OPC better utilizes the underlying Microsoft COM technology. OPC Data
Access 3.0 is the latest version of the OPC DA interface.

Supported Versions: 1.0a, 2.05a, 3.0

OPC Historical Data Access (HDA)

The OPC Historical Data Access (HDA) specification defines query methods
and analytics that may be applied to historical data. It defines behaviors for
many well-known aggregates, which are methods that summarize data
values over a particular time domain at the time of data retrieval. It can be
used to create a simple trend data server and more complex data
compression and analysis servers that are capable of providing summary
data, history updates, history data annotations, and backfilling.

Supported Versions: 1.20.

OPC Unified Architecture (UA)

OPC Unified Architecture is an open standard created by the OPC

Foundation with help from dozens of member organizations. It offers a
secure method for remote client-to-server connectivity without depending
on Microsoft COM or DCOM technology and has the ability to connect
securely through firewalls and across the Internet, WAN, or LAN. Kepware’s
implementation of the UA server supports optimized binary TCP and the DA
data model.

Supported Version: 1.02 optimized binary TCP

Thin-Client Terminal Server

Windows Remote Desktop (formerly called Terminal Services) is a Microsoft

Windows component that allows users to access data and applications on a
remote computer over a network. It also enables communications servers to be
configured via remote client machines.

*** ThingWorx Native Interface

The ThingWorx Native Interface provides real-time, bi-directional industrial controls

data to the ThingWorx® Industrial Innovation Platform via the ThingWorx
AlwaysOn™ protocol. Users can quickly and easily connect and configure
ThingWorx-developed applications to KEPServerEX. ThingWorx services enable users
to browse, read, write, and interact with KEPServerEX.