Control de Procesos
OPC: OLE para control
La evolucin de la
automatizacin a lo largo de los
ltimos aos ha difuminado la
frontera entre las distintas capas
de la pirmide industrial. El
aumento de la importancia que
se concede al intercambio de
informacin ha llevado al objeto
del presente artculo: OPC. OPC
es un estndar que define un
interfaz para la comunicacin
entre mltiples fuentes de datos.
A lo largo de este artculo
trataremos de explicar qu es
OPC y qu aporta al mundo de la
automatizacin desde el punto de
vista de las tres partes
involucradas en este mundo, los
fabricantes de tecnologa, las
ingenieras de automatizacin y
los clientes finales.
68
de procesos
Ingeniera de Sistemas y Servicios, S.A.
1. Introduccin
1.1. Por qu surge OPC
mismo sistema (integraciones hori-
Si analizamos someramente lo
que ha sido la evolucin de la au-
tomatizacin a lo largo de estos
aos, podemos observar cmo el
cambio ha sido revolucionario, in-
cluso a nivel de concepto, sobre
qu se considera que es tener una
planta automatizada.
La arquitectura de un proceso
industrial incluye los siguientes ni-
veles (Fig. 1):
- Nivel de campo o de dispositi-
vos.
- Nivel de control o de proceso.
- Nivel de datos o de negocio.
Figura 1. Hoy en da existe una imperiosa
Niveles en la necesidad de integracin, que, sim-
arquitectura
de un proceso
industrial.
J. Villarrubia Torcal
Grupo Delta
plificando mucho, no es ni ms ni
menos que establecer una comuni-
cacin entre sistemas diferentes o
entre los distintos niveles de un
zontal y vertical).
Inicialmente, esta comunicacin
se haba venido abordando me-
diante el desarrollo de drivers.
Esto obligaba a tener un conoci-
miento del medio fsico que sus-
tentaba la comunicacin as como
del lenguaje o protocolo, propieta-
rio generalmente del fabricante.
Los fabricantes de hardware in-
tentaron resolver estos problemas
desarrollando sus propias libreras
software, que aportaban a los desa-
rrolladores de sistemas unas API's
(Application Programming Inter-fa-
ces). Este paso, si bien facilita la tan
ansiada integracin, mantiene una
dependencia del fabricante, que
ahora tambin lo es de software.
El planteamiento ptimo para re-
solver estos problemas es dibujar
una lnea que separe a los proveedo-
res de hardware-software de los in-
tegradores de sistemas: un estndar.
Veamos un ejemplo de cmo
abordar el desarrollo de una aplica-
cin de visualizacin de informa-
cin proveniente del nivel de con-
trol: antes, si se deseaba obtener in-
formacin de unos PLCs 1 y 2 so-
bre una red A, se desarrollaba la
aplicacin cliente sobre el protoco-
lo de comunicaciones A (Fig. 2). Si
en otro proyecto se deseaba realizar
una aplicacin similar, pero variaba
el nivel de control, era preciso desa-
Ingeniera Qumica
www.alcion.es

rrollar otra aplicacin cliente que
implementase el tipo de comunica-
cin B correspondiente al DCS
afectado (Fig. 3). Volviendo a ini-
ciar este planteamiento, si existe un
servidor estndar de datos, nuestra
aplicacin cliente ser capaz de
adaptarse a las distintas fuentes de
informacin a las que nos queramos
conectar (Fig. 4).
Esto es OPC, que est diseado
para permitir a las aplicaciones
cliente acceder a los datos del nivel
de campo de una manera consis-
tente. En cierto modo, podramos
decir que OPC aporta el plug&play
del mundo de los ordenadores al
mundo de la automatizacin.
1.2. Historia
Figura 3.
Cuando en 1990 surge Windows
3.0, se hace posible, en una plata-
forma "barata", correr mltiples
aplicaciones simultneamente.
Windows proporcion un meca-
nismo estndar para el intercambio
de datos en tiempo real: DDE
(Dynamic Data Exchange).
Las principales limitaciones de
DDE aparecieron pronto:
- Robustez.
- No soporte en red.
- Limitado ancho de banda.
Las mejoras a este sistema apa-
recieron de la mano de distintos fa-
Figura 2. bricantes involucrados en el objeti-
Desarrollo de vo de lograr avanzar en la integra-
una aplicacin cin de sistemas: Wonderware, fa-
cliente sobre
bricante del sistema SCADA In-
un protocolo de
comunicaciones touch, cre el NetDDE, que trataba
con varios PLCs de resolver los problemas de sopor-
te en red y el FastDDE para au-
mentar la capacidad de intercambio
de datos; Rockwell cre el
AdvanceDDE, etc. Pero todos estos
permanecan como software pro-
pietarios y, por tanto, esto impeda
adquirir el estatus de estndar.
En esta poca, la tecnologa para
dar soporte al enlazado e incrusta-
cin de objetos se denomin OLE
1.0 (Object Linking & Embedding),
que es la tcnica que todos hemos
utilizado para crear documentos
compuestos, en Microsoft Office.
En 1992 surge COM (Compo-
Desarrollo de
nent Object Model). Es una especi-
otra aplicacin ficacin que establece cmo cons-
cliente sobre truir componentes que se pueden in-
una red de tercambiar dinmicamente. Ba-sn-
comunicaciones dose en COM, se desarroll OLE
con un DCS
2.0. Ahora, OLE, que ya no son si-
glas de nada, incluye adems OLE
Custom Controls (OCXs) y OLE
Automation (se define automatiza-
cin en Microsoft como el uso del
interfaz IDispatch, de forma que
lenguajes de escritura (script lan-
guages) puedan tener acceso a cual-
quier componente COM). OLE 2.0
surge, por tanto, como el sustituto
de DDE: ms robusto, ms flexible
y con un ms eficiente uso de la red.
En esta misma poca, un grupo
que se autodenominaba WinSEM
(Windows in Science, Engineering
and Manufacturing) comenz a
reunirse en las instalaciones de
Control de procesos
Microsoft en Redmond. Los miem-
bros de este grupo procedan del
mundo del control y la supervisin
industrial, con Microsoft actuando
como catalizador.
En 1994, haba un claro inters
en el uso de las tcnicas OLE (re-
almente COM) para mover datos
de proceso entre aplicaciones, en
(casi) tiempo real. En particular,
los fabricantes de SCADA's vieron
la posibilidad de estandarizar el in-
terfaz entre el ncleo del SCADA
y los drivers que eran los actuales
responsables de la adquisicin de
datos. Potencialmente esto poda
beneficiar tanto a los fabricantes
de SCADA's, como a los fabrican-
tes de hardware:
- El fabricante de SCADA no
necesitara invertir recursos en es-
cribir drivers.
- El fabricante de hardware slo
debera proporcionar un nico dri-
ver, que podra trabajar con todo el
software de Windows.
La propuesta ms interesante
fue expuesta por US Data en mar-
zo de 1995. Aunque hoy ese docu-
mento, comparado con las actuales
especificaciones de OPC, se vera
ridculamente simple, contiene la
clave de los principales conceptos
actuales de OPC.
Tras el primer documento, los
progresos hacia el estndar fueron
muy lentos. Se vio que, en lugar de
todo el grupo incluido en
WinSEM, un pequeo y ms enfo-
cado grupo era necesario para ase-
gurar la creacin de un estndar.
Este grupo fue el origen del OPC
Task Force.
Este grupo, formado por Fisher-
Rosemount, Intellution, Intuitive
Technologie, OPTO 22 y Rockwell
Software, con Microsoft en el nico
papel de soporte y consulta, emiti
un primer borrador en diciembre de
1995 , que fue presentado en la lti-
ma reunin del WinSEM en
Redmond en enero de 1996. Tras un
primer rechazo, debido a una per-
cepcin inicial de que un grupo de
lite haba monopolizado el esfuer-
zo de la estandarizacin, la respues-
ta al borrador fue bastante favorable
y muy constructiva.
julio/agosto 02
69
 INGENIERIA QUIMICA
La versin 1.0 de la OPC
Specification fue emitida el 29 de
agosto de 1996 y los primeros pro-
ductos comerciales aparecieron
apenas un ao despus. Se tom la
decisin de que la especificacin
OPC deba ser gestionada por una
organizacin independiente y sin
nimo de lucro, la OPC Foundation.
En 1997 se publica una versin
corregida 1.0A de la OPC Data
Access Specification, que es como
se denomina ahora.
A mediados de 1998, el apoyo
generalizado a OPC lo confirm
como el estndar de la industria.
1.3. Objetivo
Introducidos los conceptos ms
bsicos y generales, el objetivo del
presente artculo es familiarizar al
lector con la estructura de OPC y
su aplicacin, as como con la tec-
nologa sobre la que se sustenta.
2. Descripcin
2.1. Conceptos de COM
Como ya hemos mencionado al
analizar la evolucin histrica de
OPC, esta tecnologa se sustenta
sobre COM (Component Object
Model). Por tanto, y para entender
mejor los conceptos que vamos a
manejar ms adelante, dediquemos
unos momentos a conocer COM.
En 1992 surge COM, como ya
se ha dicho, y basndose en COM,
se desarroll OLE 2.0.
Aunque COM es en s mismo in-
dependiente del lenguaje de progra-
macin, el lenguaje de programa-
cin elemental en el que nos vamos
a basar es C++, que es el lenguaje en
el que estn escritos la mayora de
componentes. Programando COM
directamente con C++, se entienden
ms cosas que si se emplean otros
lenguajes como Visual Basic o Java.
COM proporciona el estndar
que componentes y clientes siguen
para asegurar que ellos pueden tra-
bajar juntos.
70
es algo ms. Es una estructura de
Figura 4.
En lugar de construir una apli-
cacin de forma monoltica, es pre-
ferible construirla a base de com-
ponentes. La manera ms sencilla
y rpida de desarrollar una aplica-
cin es no desarrollndola, sino
reutilizando software.
Todos los desarrolladores sabe-
mos que es buena la reutilizacin
de software, pero esto es ms fcil
de decir que de hacer. Uno de los
errores de la reutilizacin de cdi-
go ha sido tratar de reutilizarlo em-
pleando el propio cdigo fuente.
Un componente es una pieza de
software reutilizable, pero de for-
ma binaria. Los componentes de-
ben encapsular los detalles sobre
cmo estn implementados. El uso
de los componentes se hace a tra-
vs de interfaces (Fig. 5).
Si volvemos a los planteamien-
tos de integracin antiguos, con
API's, ya habra sido una avance
importante que esos interfaces fue-
sen estndar, de forma que el mis-
mo cdigo simplemente se debiese
ligar contra una librera u otra.
Sin embargo, COM da un paso
ms: los componentes se ligan di-
nmicamente. Los componentes
COM son DLL's (Dinamic Link
Library) o EXE's.
COM es ms que una especifi-
cacin. COM tiene un API, la li-
brera COM, que proporciona ser-
vicios de gestin de componentes
que son tiles para todos los clien-
tes y componentes.
Hasta ahora hemos empleado la
palabra interface para referirnos a
las funciones que poda exportar
una librera; en COM, un interface
memoria especfica, que contiene
una matriz de punteros a funcio-
nes. Cada elemento de la matriz
contiene la direccin de la funcin
implementada por el componente.
En COM, los interfaces lo son
todo. Para un cliente, un compo-
nente es un conjunto de interfaces.
A menudo, el cliente slo conoce
los interfaces que el componente
soporta.
Acceso de Decir que un componente es s-
aplicaciones
clientes a
lo la implementacin de un interfaz
diversas fuentes no tiene mucho sentido. Despus
de datos a de todo, un interfaz sin implemen-
travs de tacin no hace nada. Sin embargo,
un servidor OPC
un componente puede ser elimina-
do de una aplicacin y reemplaza-
do por otro componente, y mientras
ste soporte los mismos interfaces
que el antiguo componente, la apli-
cacin seguir funcionando.
En COM, los interfaces no cam-
bian nunca. Una vez que un inter-
faz ha sido publicado, debe perma-
necer siempre igual. En lugar de
cambiar un interfaz existente, para
actualizar un componente, se debe
crear un nuevo interfaz y aadirlo
al componente. Esto es fundamen-
tal para que pueda funcionar el
avance de versiones.
Polimorfismo es la habilidad de
diferentes objetos de ser tratados
de la misma forma. Si dos compo-
nentes distintos soportan el mismo
interfaz, el cliente puede usar el
mismo cdigo para manipular am-

bos componentes. El cliente puede,
por tanto, tratar a los diferentes
componentes polimrficamente.
Mltiples interfaces facilitan el
polimorfismo. Cuantos ms interfa-
ces soporten un componente, ms
pequeos deben ser stos. Un inter-
faz pequeo representa un nico
comportamiento, mientras que un
interfaz grande representa muchos
comportamientos. Cuantos ms
comportamientos represente un in-
terfaz, ms especfica es la situa-
cin en que se usar. Cuanto ms
especfico sea un interfaz, ms po-
dr ser reutilizado por distintos
componentes. Si un interfaz no es
reutilizado, el cdigo que usa ese
interfaz no puede ser reutilizado.
Una caracterstica adicional de
COM son los objetos conectables,
que proporcionan interfaces 'sa-
lientes' a sus clientes adems de
sus interfaces 'entrantes', de forma
que los objetos y sus clientes pue-
dan establecer una comunicacin
bidireccional.
2.2. Estructura de OPC
a diversos
OPC es un conjunto de interfa-
ces COM que permiten intercam-
biar datos entre distintas fuentes.
Los objetivos en el diseo de
OPC fueron:
- Fcil de implementar.
- Flexible para acomodarse a las
necesidades de mltiples fabrican-
tes.
- Proporcionar un alto nivel de
funcionalidad.
- Permitir una operatividad efi-
ciente.
La arquitectura de un sistema
OPC est basada en el tradicional
esquema cliente/servidor.
Los interfaces COM de los ob-
jetos OPC son implementados por
OPC Servers.
Un OPC Client puede conectar-
se a OPC Servers proporcionados
por uno o ms fabricantes, utilizan-
do para ello las interfaces definidas
Figura 5. en la especificacin (Fig. 6).
Uso de
componentes
Estas interfaces pueden ser de
a travs de
interfaces dos tipos:
- Obligatorias: son las que todo
OPC Server debe implementar pa-
ra que sea considerado como tal.
- Optativas: ofrecen capacida-
des adicionales; el fabricante pue-
de optar por incluirlas o no.
De cualquier modo, si un OPC
Server ofrece una cierta interfaz,
debe implementar todos los mto-
dos que estn definidos para esa
interfaz.
El servidor suministrado por el
fabricante de hardware determina
los dispositivos y datos a los cuales
el servidor tiene acceso: los nom-
bres de los datos y los detalles so-
bre cmo el servidor fsicamente
accede a los datos.
La OPC Foundation, que en la
actualidad cuenta con ms de 250
Figura 6.
Conexin de
un OPC Client
Vendor A
OPC Servers
OPC Client
Control de procesos
miembros procedentes de los prin-
cipales lderes mundiales en con-
trol y supervisin de procesos in-
dustriales, tiene como uno de sus
objetivos prioritarios la publica-
cin de especificaciones para la in-
dustria, tan rpido como sea posi-
ble. Con esto en mente, el alcance
de los primeros documentos se ha
limitado a las reas comunes a to-
dos los fabricantes:
- OPC Data Access: proporcio-
na acceso a datos en tiempo real (v
2.05, enero 2002).
- OPC Alarms & Events: pro-
porciona informacin de ocurren-
cia de un evento o alarma especfi-
co (v 1.02, noviembre 1999).
- OPC Historical Data Access:
proporciona acceso a los datos his-
tricos almacenados (v 1.1, enero
2001).
Posteriormente se emitieron:
- OPC Batch: para el envo de
recetas y su monitorizacin (v 1.0
abril 2000).
- OPC Security: para la identifi-
cacin de los clientes (v 1.0 octu-
bre 2000).
Ahora se est trabajando en la
versin 3.0 de OPC Data Access,
en OPC XML y en OPC Data
eXchange.
OPC Data Access proporciona
un mecanismo eficiente de lectura
y escritura de datos entre una apli-
cacin y un dispositivo de control
de procesos.
Un servidor de acceso a datos
OPC comprende varios objetos: el
servidor, el grupo y el tem (Fig. 7).
El objeto servidor mantiene infor-
OPC
Server
OPC
Server
Vendor B
OPC
Server
Vendor C
julio/agosto 02
71
 INGENIERIA QUIMICA
Servidor
Grupo 1
macin sobre el servidor y sirve
como contenedor para objetos de
grupos OPC. Un objeto OPC
Group mantiene informacin sobre
s mismo y proporciona el mecanis-
mo para contener y organizar lgi-
camente tems OPC.
Un grupo proporciona al cliente
una forma lgica de organizar los
datos. Hay dos tipos de grupos, p-
blicos y locales o privados. Los p-
blicos son para compartir a travs
de mltiples clientes, y los priva-
dos son locales a un cliente deter-
minado.
Dentro de cada grupo se pueden
definir uno o ms OPC Items. El
OPC Item representa la conexin a
la fuente de datos, pudiendo tratar-
se de cualquier tipo de dato, desde
un simple valor booleano, hasta
una cadena de caracteres.
La mayora de los servidores
OPC de acceso a datos proporcio-
nan un "explorador de tems", que
permite conocer la estructura jerr-
quica de sus datos y facilita la adi-
cin de tems a los grupos.
A la hora de leer y escribir valo-
res de los tems, se definen mto-
dos sncronos y asncronos, siendo
los primeros adecuados para apli-
caciones simples, mientras que los
segundos se deben utilizar en pro-
cesos complejos, que requieran el
intercambio de gran cantidad de
informacin con la mxima efi-
ciencia.
Adems, en la especificacin
OPC de acceso a datos, se definen
una serie de parmetros configura-
bles, como la tasa de actualizacin,
la actividad, o los porcentajes de
72
Figura 7.
Arquitectura
de los objetos
de un servidor
OPC
Grupo 2
Item 1
Item 2
Item 3
banda muerta, que ayudan a crear
aplicaciones cliente que aprove-
chen al mximo las capacidades
del servidor.
OPC Alarm & Events permite
que los clientes sean notificados de
la ocurrencia de un evento deter-
minado o una condicin de alarma.
En OPC una alarma es una con-
dicin anormal, un caso especial
de una condicin, entendindose
por condicin el estado de uno de
los objetos contenidos por el OPC
Event Server. Las alarmas o condi-
ciones pueden ser de estado nico
o multiestado.
Por otro lado, un evento es un
una ocurrencia detectable, que tie-
ne significado para el OPC Server,
el dispositivo que representa y sus
Clientes OPC. Un evento puede o
no estar asociado a una condicin.
Los eventos pueden ser:
- Simples: no relacionados con
estados.
- Tracking: indican la realiza-
cin de una operacin y el alcance
de un objetivo.
- Condition: son alarmas
El cliente se 'suscribe' a las alar-
mas o eventos de los que quiere ser
notificado.
OPC Historical Data Access
proporciona acceso a los datos his-
tricos almacenados por los servi-
dores. Con el objetivo de integrar
datos todos los niveles de negocio,
los datos histricos deben conside-
rarse como otro tipo de datos.
Hay varios tipos de servidores
de histricos:
- Simples servidores de tenden-
cias: simples registros de tiempo,
valor y calidad.
- Complejos tratamientos de da-
tos. Proporcionan resumen de datos,
funciones de anlisis como medias,
mnimos, mximos, etc. Pueden so-
portar actualizaciones de datos e
historia de las actualizaciones.
OPC Batch proporciona un con-
junto de interfaces para facilitar la
creacin, gestin y supervisin de
procesos por lotes (recetas). Se ba-
sa en la norma IEC 61512-1.
OPC Security permite que los
servidores OPC puedan identificar
a los clientes que acceden a ellos y
configurar sus permisos y niveles
de acceso. Se definen tres niveles
de seguridad:
- Sin seguridad.
- Seguridad bsica.
- Seguridad extendida.
OPC XML posibilita el uso de
OPC a travs de Internet. La prime-
ra versin de la especificacin, cu-
ya aparicin es inminente, utiliza el
protocolo SOAP (Simple Object
Access Protocol), que es indepen-
diente de la plataforma utilizada,
para el intercambio de mensajes en
formato XML entre procesos.
OPC Data eXchange est en pro-
ceso de desarrollo. El estndar
OPCDX proporcionar intercambio
de datos y comunicaciones entre
servidores en redes de tipo Ethernet,
independientemente del protocolo
utilizado. Para la elaboracin de la
primera especificacin, se ha creado
un grupo de trabajo, en el que, ade-
ms de la OPC Foundation, partici-
pan organizaciones como Control-
Net International, Fieldbus Founda-
tion, Open DeviceNet Vendor Asso-
ciation y PROFIBUS International.
Las especificaciones OPC siem-
pre contienen dos conjuntos de in-
terfaces:
- Custom Interface.
- Automation Interface.
Las especificaciones dicen lo
que los interfaces son, el compor-
tamiento que se espera de ellos, no
la implementacin de los mismos.

Como toda implementacin
COM, la arquitectura de OPC es
un modelo cliente /servidor, donde
el componente OPC Server pro-
porciona un interfaz a los objetos
OPC y los gestiona.
OPC Servers estn escritos en
C/C++. Un OPC Client que se desa-
rrolle en C++ deber emplear el
Custom Interface, mientras que un
cliente que se desarrolle en Visual
Basic deber emplear el Automation
Interface, debiendo usar un OPC
Automation Wrapper, que acte co-
mo pasarela entre ambos conjuntos
de interfaces (Fig. 8).
2.3. Arquitectura distribuida
Figura 8.
Avancemos ahora un paso ms
all y analicemos cmo se plantea
la arquitectura distribuida.
Si en el pasado, el uso de un dri-
ver propietario estaba restringido a
una nica aplicacin, ya hemos
visto que ahora se puede acceder
al mismo OPC Server desde dife-
rentes aplicaciones OPC Clients.
Avanzando ms, el acceso al OPC
Server es an ms flexible. La ca-
pacidad de multi-cliente no slo
cobra ventaja en el PC local en que
reside el servidor, sino que puede
ser usada remotamente por medio
de DCOM (Distributed COM).
DCOM apareci por vez primera
en agosto de 1996 en el marco de
Windows NT 4.0. Se puede enten-
der como una extensin de COM
que permite la comunicacin entre
objetos que se encuentran en m-
quinas distintas, a travs de una
Red de Area Local (LAN), de una
Red de Area Extensa (WAN), o in-
cluso de Internet.
DCOM oculta por completo la
ubicacin de un componente, ya se
encuentre en el mismo proceso o
en una mquina a miles de km. de
distancia. En todos los casos, la
forma en la que el cliente se conec-
ta al componente y llama a sus m-
todos es idntica.
Evolucionamos desde que el
cliente y el servidor residan en las
misma mquina, hacia la conecta-
bilidad con un servidor residente
en otra mquina (Fig. 9).
Control de procesos
OPC Automation OPC Automation
Aplicacin
VB Interfase Wrapper Local o Remoto
OPC Server
(Compartido por varios
clientes)
Aplicacin
C++ Server Data Cache
OPC Custom Interface
Dispositivo fsico
Dato
Arquitectura
de OPC
COM y DCOM fueron creados Como resultado de este plantea-
por Microsoft para operar sobre un miento, uno de los temas que ms
sistema operativo Windows, aun- preocupan, tanto a desarrolladores
que en la actualidad existen empre- como a consumidores de productos
sas que han desarrollado versiones OPC, es la seguridad de sus aplica-
de DCOM para otros sistemas ope- ciones distribuidas.
rativos y plataformas.
Afortunadamente, con DCOM
Pero cmo puede un cliente sa- se pueden implementar aplicacio-
ber qu servidores OPC residen en nes distribuidas de forma segura,
una determinada mquina? Para re- sin necesidad de aadir ningn c-
solver este problema, la OPC digo extra. As como el modelo de
Foundation suministra un compo- programacin DCOM encapsula la
nente denominado OPCENUM, localizacin de un componente,
que se comporta como un "explora- tambin encapsula sus requeri-
dor de servidores OPC" y que ofre- mientos de seguridad. De esta for-
ce al cliente una lista de los servi- ma, el mismo cdigo binario utili-
dores disponibles en la mquina. zado en un entorno de una sola m-
Figura 9.
Evolucin
desde cliente
y servidor en
la misma
mquina
hacia
mquinas
distintas
julio/agosto 02
73
 INGENIERIA QUIMICA
quina, donde no se aplican consi-
deraciones de seguridad, se puede
usar en un entorno distribuido con
un alto nivel de seguridad.
Para conseguir esta transparen-
cia en cuanto a seguridad, DCOM
permite que los desarrolladores y
los administradores de las mqui-
nas configuren los requisitos de se-
guridad de cada componente.
Cuando un cliente efecta una
llamada a un mtodo o crea una ins-
tancia de un componente, DCOM
obtiene el nombre de usuario de di-
cho cliente, asociado con el proce-
so; Windows NT garantiza la auten-
ticidad de esta credencial de usua-
rio. A continuacin, DCOM pasa
este nombre de usuario a la mqui-
na o proceso en el que corre el com-
ponente. DCOM de la mquina en
la que reside el componente se en-
carga de validar el nombre de usua-
rio: chequea la lista de control de
acceso para el componente. Si el
nombre de usuario del cliente no es-
t incluido en esta lista (ya sea di-
rectamente o indirectamente como
un miembro de un grupo de usua-
rios), DCOM simplemente rechaza
la llamada antes incluso de que el
componente se entere.
Una vez que el usuario ha sido
autentificado, DCOM define dos
tipos de seguridad:
- Seguridad de activacin, que
controla qu clientes pueden acce-
der a un determinado componente.
- Seguridad de llamada, que
controla qu clientes pueden efec-
tuar llamadas a los mtodos del
componente.
La configuracin de estas segu-
ridades implica modificar los valo-
res del registro de Windows, con
los riesgos y complicaciones que
ello implica. Para facilitar esta la-
bor, DCOM ofrece la herramienta
DCOMCNFG.
De esta forma, DCOM propor-
ciona un mecanismo de seguridad
extremadamente eficiente, que
permite que los programadores
creen aplicaciones distribuidas se-
guras sin tenerse que preocupar en
implementar esta seguridad.
74
Cualquier proveedor de seguridad LIBRO
soportado por Windows NT puede
ser usado con el mecanismo de se- Control
guridad de DCOM.
automtico
4. Conclusiones de Procesos
Con la amplia aceptacin de la
industria, OPC ofrece muchos be-
neficios:
- Los fabricantes de hardware:
Slo tienen que hacer un con-
junto de componentes software
que ser utilizado por todos los
clientes en sus aplicaciones, con lo
que incrementan su cuota de mer-
cado, ya que ahora sus dispositivos
son abiertos para comunicarse con
cualquier aplicacin.
Autor: Carlos A. Smith
- Los desarrolladores de soft-
ware:
No tenemos que reescribir dri- Edicin: 2000
vers por los cambios o aadidos Espaa: 48
que hayan podido surgir en una Resto de Europa: 66
nueva versin de hardwar. Slo de- Resto del Mundo: 84 $
bemos conocer un 'API' indepen- Pginas: 717
dientemente de los diferentes ele- Referencia: 1168
mentos de campo que queramos
Espaa: 4% IVA incluido
integrar.
- Los clientes finales:
Eleccin de hardware y softwa- Pedidos:
re de manera independiente, de
forma que tienen ms posibilida-
des de eleccin de su proveedor de Telfono:
sistemas integrados de gestin.
914 402 923
Fax:
914 402 931
Internet:
www.alcion.es
Correo:
EDITORIAL ALCION
Medea, 4
28037 MADRID
PUEDE CONSULTAR EL INDICE
EN INTERNET: www.alcion.es