ACTIVIDAD 6

TRABAJO COLABORATIVO 1





JAMER ZARATE VERGARA
CARLOS MARIO HOYOS
JOSE ALEXANDER GUTIERREZ
FREDDY MURILLO





GRUPO:
208021_11





TUTOR:
ALEXANDER FLORES








UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA (UNAD)
ESCUELA DE CIENCIAS BSICAS E INGENIERA
PROGRAMA INGENIERA ELECTRNICA
BARRANQUILLA ATLNTICO
2014

INTRODUCCION


En este trabajo se realiza un resumen de detalles tcnicos de los protocolos
industriales de comunicacin comnmente usados. Un protocolo industrial es aquel
que es insertado dentro de los dispositivos electrnicos, que participan en el control
de procesos o de la manufactura para darles capacidad de comunicar datos del
proceso u otros de manera ptima. Aunque muchos son propietarios, tienden con el
tiempo a convertirse en protocolos de uso generalizado por su aceptacin en el
mercado.

Este trabajo pretende exponer los fundamentos de los protocolos ms importantes
tales como el HART, y los puramente digitales como ASCII, BSAP y MODELO OSI.

































Protocolo HART

La mayora de los dispositivos inteligentes de campo instalados alrededor del
mundo son compatibles con HART. Pero algunos de los nuevos en el campo de la
automatizacin pueden necesitar una actualizacin sobre esta poderosa tecnologa.
En pocas palabras, el Protocolo HART (transductor remoto direccionable en red) es
el estndar mundial para enviar y recibir informacin digital a travs de cables
analgicos entre dispositivos inteligentes y el sistema de control o de monitoreo.
Ms especficamente, HART es un protocolo bidireccional de comunicacin que
suministra acceso de datos entre instrumentos inteligentes de campo y sistemas
centrales. Un sistema central puede ser cualquier aplicacin de software desde el
dispositivo de mano o laptop del tcnico hasta el control de procesos de una planta,
gestor de activos, seguridad u otro sistema que use cualquier plataforma de control.

UNA ACTUALIZACIN DIGITAL PARA PLANTAS EXISTENTES

La tecnologa HART ofrece una solucin confiable a largo plazo para operarios de
planta que buscan los beneficios de dispositivos inteligentes con comunicacin
digital que est incluida en la mayora de los dispositivos en instalacin. Sin
embargo, en muchos casos, la mayora de las aplicaciones no pueden actualizar
sus sistemas de automatizacin existentes con un sistema que pueda aceptar los
datos digitales suministrados por el Protocolo HART.
Debido a que hoy en da la mayora de las redes de automatizacin en operacin
se basan en el cableado analgico tradicional de 4 a 20 mA, la tecnologa HART
desempea un papel fundamental porque la informacin digital se comunicar al
mismo tiempo con la seal de 4-20 mA. Si sta, no habra comunicacin digital.

UNA FUNCIN DIGITAL CRTICA

La Tecnologa HART es fcil de usar y muy confiable cuando se usa para poner en
servicio y calibrar dispositivos inteligentes as como para diagnstico contino en
lnea.
Hay varias razones para que una unidad central se comunique con los dispositivos
inteligentes.


stas incluyen:

Configuracin o reconfiguracin del dispositivo
Diagnstico del dispositivo
Identificacin y correccin de problemas del dispositivo
Lectura de valores de medicin adicionales suministrados por el dispositivo
Estado de operacin y bienestar del dispositivo
Mucho ms: Hay muchas ventajas por utilizar la tecnologa HART y ms usuarios
estn reportando beneficios en sus proyectos en forma continua.

Muchos aos de xito y la obtencin de estos beneficios explica por qu la
tecnologa HART es el ms grande de todos los protocolos de comunicacin,
instalado en ms de 30 millones de dispositivos en todo el mundo.
Si usted ha usado una lnea telefnica terrestre y observado la pantalla del
identificador de llamadas para saber quin llama, ya conoce la mitad de lo que hace
el Protocolo HART, identifica quin llama. En una red de automatizacin industrial
"quin" es un dispositivo inteligente de campo basado en un microprocesador.
Adems de permitir que dichos dispositivos inteligentes de campo "llamen a casa",
la comunicacin HART permite al sistema central enviar datos al instrumento
inteligente.
HART surgi a finales de la dcada de 1980 sobre la base de la misma tecnologa
que llev a la identificacin de llamadas de telefona analgica. Ha experimentado
un desarrollo continuo, hasta e incluyendo los productos de automatizacin ya a la
venta con funcin de comunicacin HART inalmbrica integrada.

Cmo funciona HART

HART es un acrnimo en ingls para Transductor Remoto Direccionable en Red.
El Protocolo HART usa la norma Bell 202 Modulacin por desplazamiento de
frecuencia o MDF (FSK en ingls) para empalmar seales digitales de comunicacin
a bajo nivel sobre 4 a 20 mA.

Figura 1. Modulacin por desplazamiento de frecuencia (MDF)

Esto permite la comunicacin bidireccional en campo y hace posible la transmisin
de informacin adicional ms all de slo las variables normales de proceso
comunicadas de y hacia un instrumento inteligente de campo. El Protocolo HART
se comunica a 1200 bps sin interrumpir la seal de 4 a 20 mA y permite a la
aplicacin central (maestra) obtener dos o ms actualizaciones digitales por
segundo de un dispositivo inteligente de campo. Ya que la seal digital MDF es de
fase continua no hay interferencia con la seal de 4 a 20 mA.
La Tecnologa HART es un protocolo maestro/servidor, lo cual significa que un
dispositivo inteligente de campo (servidor) slo habla cuando le habla un maestro.
El Protocolo HART se puede utilizar en diversos modos, como punto a punto o
multipunto para transmitir informacin hacia y desde los instrumentos inteligentes
de campo y el control central o los sistemas de monitoreo.
La comunicacin HART se produce entre dos dispositivos habilitados con HART,
tpicamente un dispositivo de campo inteligente y un sistema de control o monitoreo.
La comunicacin se produce mediante un cable de instrumentacin de calidad
estndar y el uso de prcticas de cableado y terminacin estndar.
El protocolo HART proporciona dos canales de comunicacin simultneos: la seal
analgica de 4 a 20 mA y una seal digital. La seal de 4 a 20 mA comunica el valor
primario medido (en el caso de un instrumento de campo) con el circuito de corriente
4 a 20 mA, el estndar ms rpido y ms fiable de la industria. Informacin adicional
del dispositivo se comunica mediante una seal digital que se superpone a la seal
analgica.
La seal digital contiene la informacin del dispositivo incluyendo el estado del
dispositivo, diagnstico, valores medidos o calculados adicionales, etc. Juntos, los
dos canales de comunicacin proporcionan una solucin completa de comunicacin
de campo muy robusta a bajo costo que es fcil de usar y configurar.

Figura 2. Dos canales de comunicacin

El Protocolo HART suministra hasta dos maestros (primario y secundario). Esto
permite usar maestros secundarios como comunicadores de mano sin interferir con
las comunicaciones desde y hasta el maestro primario, es decir, el sistema de
control / monitoreo.

Figura 3. Maestros primarios y secundarios
El protocolo HART permite toda la comunicacin digital con los dispositivos de
campo en configuracin de red punto a punto o multipunto:

Figura 4. Configuracin Punto a Punto

Configuracin Multipunto

Tambin hay una opcin de modo de comunicacin "rfaga" donde un solo
dispositivo servidor puede transmitir continuamente un mensaje de respuesta
estndar HART. Con este modo de comunicacin rfaga opcional son posibles
mayores tasas de actualizacin y el uso normalmente se limita a la configuracin
punto a punto.



Figura 5. Configuracin Multipunto


Beneficios de usar la comunicacin HART

Los ingenieros que operan en entornos de automatizacin anloga no necesitan
mencionar las palabras "si slo" como en "si slo pudiera obtener la informacin del
dispositivo sin tener que ir al sitio" o "si slo pudiera cargar esta informacin de
configuracin de ese transmisor de presin a mi PC".
Los usuarios alrededor del mundo que han obtenido los beneficios de comunicacin
HART saben que pueden tener visibilidad rpida y fcil a dispositivos en el campo
al usar dispositivos de calibracin, de prueba y computadoras porttiles equipadas
con HART. De hecho, los diagnsticos, pruebas y configuracin de dispositivos
nunca han sido tan fciles.
Sin embargo, muchos an no han obtenido los mayores beneficios de la tecnologa
HART que resultan de conexiones de tiempo completo con la gestin en tiempo real
de activos y/o sistemas de control.

La tecnologa HART le puede ayudar a:

Aprovechar las capacidades de un juego completo de datos de di spositivos
inteligentes para mejoras operativas.
Tener advertencia temprana de variaciones en el rendimiento de dispositivos,
productos o procesos.
Acelerar el tiempo de identificacin y correccin de problemas entre el diagnstico
y la solucin.
Validar en forma continua la integridad de los circuitos y estrategias del sistema de
control / automatizacin.
Aumentar la productividad del equipo y disponibilidad del sistema.

Aumentar la disponibilidad de la planta

Integrar dispositivos y sistemas para deteccin de problemas previamente no
detectables.
Detectar en tiempo real problemas de conexin de dispositivos y/o procesos.
Minimizar el impacto de desviaciones al tener advertencias nuevas y oportunas.
Evitar el alto costo de paros o interrupcin de procesos no programados.


Reducir los costos de mantenimiento

Verificacin rpida y validacin de circuitos de control y configuracin de
dispositivos.
Uso de diagnstico remoto para reducir las pruebas de campo innecesarias.
Captura de datos de tendencias de rendimiento para diagnstico de mantenimiento
predictivo.
Reduccin del inventario de refacciones y costos de administracin de dispositivos.

Mejorar el cumplimiento reglamentario

Activar la documentacin automatizada para datos de cumplimiento.
Facilitar la prueba de paros automticos de seguridad.
Elevar el nivel de integridad de seguridad (SIL) con diagnsticos avanzados.
Tomar ventaja de dispositivos inteligentes multivariables para informes ms
precisos y completos.

Las caractersticas estndar de la tecnologa Hart van desde la compatibilidad
simple con las redes anlogas de 4 a 20 mA existentes a una amplia seleccin de
productos:

Compatibilidad con alambrado de 4 a 20 mA estndar
Transmisin simultnea de datos digitales
Simplicidad a travs de interfases por mens intuitivos
Reduccin de riesgo a travs de un protocolo robusto y preciso
Facilidad de implementacin para mxima efectividad de costo "de entrada"
Amplia seleccin de productos, con dispositivos compatibles y aplicaciones de
software de la mayora de los proveedores de automatizacin de procesos
Independencia de plataforma para interoperatividad total en entornos
multiproveedor

Soporte alrededor del mundo por los principales proveedores

La mayora de los principales proveedores de instrumentacin de procesos y
sistemas de control del mundo, que abarcan a la mayora de las soluciones de la
industria, ofrecen soporte activo para la tecnologa HART. Hay ms de 990
dispositivos registrados en 20 categoras de dispositivos manufacturados por ms
de 230 miembros de la Fundacin de Comunicacin HART.

Lenguaje para Descripcin de Dispositivo (DDL) y Descripciones de
Dispositivos (DD)


Qu es una Descripcin de Dispositivo?

Una Descripcin de Dispositivo o DD es un archivo
electrnico de datos preparado de conformidad con las
especificaciones del Lenguaje para Descripcin de
Dispositivo que describe las caractersticas y funciones
especficas de un dispositivo inclusive detalles de mens y
caractersticas de la pantalla grfica que ser usada por las
aplicaciones centrales (inclusive dispositivos porttiles de
mano) para entrar a todos los parmetros y datos en el
dispositivo correspondiente.

Biblioteca DD

La Fundacin de Comunicacin HART administra una
biblioteca de Descripciones de Dispositivos de Fabricantes.
La Biblioteca DD se actualiza y publica cada trimestre. Los
servicios de suscripcin a la Biblioteca DD estn disponibles
para todos los miembros de la Fundacin de Comunicacin
HART


Especificaciones HART

El Protocolo HART se desarroll a finales de la dcada de 1980 y fue transferido a
la Fundacin HART a principios de la dcada de 1990. Desde entonces se ha
actualizado varias veces. Cuando se actualiza el protocolo, se hace de manera que
asegura la compatibilidad con versiones anteriores. La versin actual del Protocolo
HART es la revisin 7.3. El "7" denota el nivel de revisin mayor y el "3" denota el
nivel de revisin menor.
El Protocolo HART implementa la arquitectura jerrquica 1, 2, 3, 4 y 7 del modelo
de protocolo de 7 niveles de Interconexin de Sistemas Abiertos (OSI):
El Nivel Fsico HART est basado en la norma Bell 202, usa la modulacin por
desplazamiento de frecuencia (MDF) para comunicarse a 1200 bps. Las frecuencias
de seal que representan los valores de bit 0 y 1 son 2200 y 1200 Hz
respectivamente. Esta seal se superpone a un nivel bajo en la seal de medicin
analgica de 4 a 20 mA sin causar ninguna interferencia con la seal analgica.
El nivel de Enlace de Datos HART define un protocolo maestro-servidor - en uso
normal, un dispositivo de campo slo contesta cuando le hablan. Puede haber dos
maestros, por ejemplo, un sistema de control como maestro primario y un
comunicador porttil HART como maestro secundario. Las reglas de tiempo definen
cuando puede cada maestro iniciar una transaccin de comunicacin. Se pueden
conectar hasta 15 o ms dispositivos servidores a un par individual de cable
multipunto.
El Nivel de red suministra enrutamiento, seguridad de punta a punta y servicios de
transporte. ste gestiona "sesiones" para comunicacin de punta a punta con los
dispositivos correspondientes.
El nivel de transporte: El Nivel de Enlace de Datos asegura que las
comunicaciones sean propagadas correctamente de un dispositivo a otro. El Nivel
de Transporte se puede usar para asegurar que la comunicacin de punta a punta
sea correcta.
El Nivel de Aplicacin define los comandos, respuestas, tipos de datos e informes
de estado respaldados por el Protocolo. En el Nivel de Aplicacin, los comandos
pblicos del protocolo se dividen en cuatro grupos principales:

1. Comandos universales - suministran funciones que se pueden implementar en
todos los dispositivos de campo
2. Comandos de Prctica Comn - suministran funciones comunes para muchos, pero
no para todos los dispositivos de campo
3. Comandos Especficos para Dispositivo - suministran funciones que son nicas para
un dispositivo de campo en particular y son especificadas por el fabricante del
dispositivo
Comandos para Familia de Dispositivos - suministran un juego de funciones
estandarizadas para instrumentos con tipos particulares de medicin y permiten el
acceso genrico total sin usar comandos especficos para un dispositivo.


PROTOCOLO BSAP

Es un protocolo con una topologa tipo rbol con un mximo de seis niveles y 127
nodos por nivel.
Cada nodo puede controlar hasta 127 dispositivos remotos, tiene una direccin
nica basada en su posicin en la red y puede ser maestra de los niveles inferiores
y o esclava de los niveles superiores.
Cumple con el Modelo ISO/OSI en las cuatro primeras capas.

Caractersticas

Control por Caracteres
Transmisin Sincrnica/Asincrnica, HDX/FDX
Topologa Tipo rbol
Carcter bsico codificado en ASCII sin dgito de paridad
Interfaces: RS-232C, RS-422A, RS-423A y RS-485
Velocidades de Transmisin: 150 a 9600 bps
Medios de Transmisin: par trenzado, cable coaxial, radio

Protocolo y Jerarqua

Protocolo BSAP



Estructura Jerrquica del Protocolo BSAP



Comunicacin Par a Par

La comunicacin Par a Par es un mecanismo para la transferencia de bloques de
datos entre dos nodos adyacentes en la red. En el entorno BSAP se tienen los
denominados Mdulos ACCOL Maestro/Esclavo que permiten efectuar la
transferencia. Los mdulos se ejecutan peridicamente a la velocidad de la
correspondiente tarea ACCOL, y las peticiones se pasan al entorno BSAP para su
interconexin. Cuando un Mdulo Esclavo recibe un comando desde un Mdulo
Maestro, la tarea es ejecutada de inmediato.




Formatos

Mensajes Locales

Los mensajes locales son aquellos que no tiene que pasar a travs de ningn nodo
para llegar a destino. Por definicin, el primer nodo en recibir un mensaje es el nodo
de destino. En este caso se aplican las direcciones locales (a nivel de enlace)







Formato para Mensajes Locales



PROTOCOLOS ASCII

El cdigo ASCII consiste en una tabla numrica que asocia un cdigo numrico de
7 bits consecutivos, el cdigo binario formado por unos y ceros, a cada una de las
letras, nmeros y otro tipo de caracteres (signos de puntuacin, smbolos,
caracteres especiales, etc.). Esta codificacin es la que permite trabajar con
ordenadores y que stos se comuniquen entre ellos, mediante dicho cdigo binario.
Los primeros usos del cdigo binario se atribuyeron a las comunicaciones de larga
distancia de Samuel Morse, a la telegrafa en general y a los avances de Bell. ste
ltimo haba puesto en marcha un cdigo de 6 bits. En la dcada de 1960, el cdigo
ASCII (American Standard Code for Information Interchange) pas a ser el nuevo
estndar. Fue creado en 1963 por el Comit Estadounidense de Estndares y
estuvo basado en el alfabeto latino. Ms tarde, en 1967, se incluyeron las
minsculas, y se redefinieron algunos cdigos de control para formar el cdigo
conocido como US-ASCII. Fue actualizado por ltima vez en 1986.
El cdigo ASCII utiliza 7 bits para representar los caracteres aunque a menudo se
llama incorrectamente ASCII a cdigos de caracteres de 8 bits. Como por ejemplo,
el estndar ISO-8859-1, una extensin que utiliza 8 bits para proporcionar
caracteres adicionales usados en idiomas distintos al ingls, como el espaol.
Muchos de los caracteres de control ASCII servan para marcar paquetes de datos
o para controlar protocolos de transmisin de datos. Tambin idearon los caracteres
de separacin para su uso en sistemas de cintas magnticas. En la actualidad
define cdigos para 33 caracteres no imprimibles que tienen efecto sobre cmo se
procesa el texto, ms otros 95 caracteres imprimibles que les siguen en la
numeracin. En total, 127 ms el carcter espacio.
Otros rganos de estandarizacin han publicado cdigos de caracteres que son
idnticos a ASCII. Estos cdigos de caracteres reciben a menudo el nombre de
ASCII, a pesar de que ASCII se define estrictamente solamente por los estndares
ASA/ANSI.

El cdigo ASCII es utilizado por multitud de sistemas informticos actuales para
representar textos para el control y gestin de dispositivos que hacen uso del texto.
Por ejemplo, el teclado. Es un mtodo que gracias a cadenas de bits y una serie de
smbolos, permite la comunicacin, procesado y almacenamiento entre dispositivos
digitales. El nombre ms apropiado para este cdigo de caracteres es US-ASCII.

El protocolo ASCII controla la transferencia de datos entre una estacin local y un
partner de comunicacin, en un acoplamiento punto a punto al nivel bajo. El
protocolo ASCII est contenido en el nivel de transmisin de bits del modelo de
referencia ISO-OSI.
La estructura de los telegramas es completamente especfica del usuario, de forma
que es posible la creacin de telegramas propios basndose en el protocolo ASCII.
Desde el punto de vista de la recepcin, simplemente hay que definir un criterio final
para los telegramas a recibir.
Con ayuda del protocolo ASCII, se pueden enviar y recibir datos con cualquier
estructura (todos los caracteres imprimibles de la tabla ASCII).

Caractersticas del protocolo ASCII libre:

Valores bsicos Rango de valores
Rango de datos por servicio Hasta 4096 Bytes por telegrama
Nmero de posibles enlaces por cada CP 1 por interfase (conexin punto a punto)

Ventajas del protocolo:

Se puede utilizar muy bien con sistemas ajenos
Adecuado para cantidades de datos medias (<= 4096 Bytes)
Muy buen rendimiento, ya que no hay ni cabecera ni elaboracin de ningn
procedimiento
Protocolo libre para la transferencia de todos los formatos de carcter

Desventaja del protocolo:

La transferencia de datos no se acusa
Seguridad de datos baja (distancia Hamming = 1, ya que slo se utiliza el bit de
paridad)
Necesita la llamada coordinada de las funciones de envo y recepcin en ambas
partes

Advertencia:

Informacin general sobre la comunicacin a travs de SIMATIC S7, as como la
descripcin exacta sobre el protocolo ASCII, est disponible en la pgina del
Customer Support con nmero ID 20982954.

FTP.
El protocolo FTP o file transfer protocol (protocolo de transferencia de archivos)
tiene como objetivo principal varios puntos, como son, promover el compartir
archivos entre computadoras (programas y datos), alentar el uso remoto de las
computadoras, y transferir datos de una forma segura y optima por computadora.
FTP ms que para ser usado por un usuario directamente es para que los
programas lo usen entre ellos para comunicarse.
Con este tipo de forma de hacer las cosas le ayudamos al usuario para que no tenga
que preocuparse por el tipo de computadora con la cual tiene contacto, sean
microcomputadoras, micro, mini o simples computadores personales. Gracias a
este tipo de protocolo no se necesita saber mucho y se pueden lograr muchas
cosas.
El protocolo ha ido evolucionando demasiado en todos estos aos desde que se
creo, este empez en 1.971 con un modelo de transferencia llamado RFC 141 en
MIT. Fue hasta despus de muchas revisiones que lleg a RFC 265 cuando ya se
le considero como un protocolo de transferencia de archivos completo entre HOSTs
(o servidores de archivos) de ARPHANET. Finalmente un documento declarando
un FTP oficial se public cuando se llego a RFC 454.
El FTP cambio mucho pero al final de la edicin de RFC 765 se incluy alguno de
los que son ahora los comandos de este protocolo:
CDUP (change to parent directory).
SMNT (structure mount).
STOU (store unique).
RMD (remove directory).
MKD (make directory).
PWD (print directory).
SYST (system).
Existen tres tipos de datos en la transferencia por FTP, el tipo ASCII, EBCDIC,
IMAGEN.
El tipo ASCII es el ms comn, se usa cuando se transfieren archivos de texto en el
cual el SENDER debe convertir cualquiera que sea su estructura de archivos interna
al formato genrico de 8 bits, y el RECEIVER a su propio formato.
El EBCDIC es el ms eficiente cuando ambos equipos lo usan como formato propio,
se representa tambin en 8 bits pero de forma EBCDIC, la diferencia se da en la
forma de reconocer los cdigos de los caracteres.
IMAGEN es cuando se empaca todo lo que se quiere enviar en cadenas seguidas
de paquetes de 8 bits, esto es no importa el formato en que internamente se maneje
la informacin, cuando se va enviar se tiene que hacer una conversin de 8 en 8
bits y cuando el que recibe tiene todo el paquete, el mismo debe codificarlos de
nuevo para que la transmisin sea completada.
En FTP se consideran tres tipos deferentes de archivos. Estos son FILE-
STRUCTURE (donde no hay estructuras internas y el archivos es considerado una
secuencia continua de bytes), RECORD-STRUCTURE (donde los archivos
contienen puros registros iguales en estructura) y PAGE-STRUCTURE (donde los
archivos contienen paginas enteras indexadas separadas).
Al establecer una conexin por FTP se debe tomar en cuenta que el mecanismo de
transferencia consiste en colocar bien la transferencia de datos en los puertos
adecuados y al concluir la conexin estos puertos deben ser cerrados
adecuadamente. El tamao de transferencia es de 8 bits, en ambos. El que va a
transferir, debe escuchar desde el puerto hasta que el comando enviado sea
recibido y este ser el que de la direccin de la transferencia. Una vez recibido el
comando y establecido una transferencia del servidor a que solicita se inicializa la
comunicacin de la transferencia para verificar la conexin, esta es una cabecera
con un formato especfico, despus de esto se comienza a enviar las tramas de 8
bits sin importar el tipo de datos que sea (antes mencionado), y al finalizar se enva
otra trama cabecera ya establecida confirmando la transferencia completada.
Existen tres modos de transferencia en FTP como son el STREAM MODE, BLOCK
MODE y COMPRESSED MODE.
Algunos de los comandos mas usados en FTP son los siguientes:
Comandos de acceso
USER NAME (USER)
PASSWORD (PASS
ACCOUNT (ACCT)
CHANGE WORKING DIRECTORY (CWD)
CHANGE TO PARENT DIRECTORY (CDUP)
REINITIALIZE (REIN)
LOGOUT (QUIT)
Comandos de transferencia
DATA PORT (PORT)
PASSIVE (PASV)
FILE STRUCTURE (STRU)
TRANSFER MODE (MODE)
Comandos de servicio
RETRIEVE (RETR)
STORE (STOR)
STORE UNIQUE (STOU)
APPEND (with create) (APPE)
ALLOCATE (ALLO)
RENAME TO (RNTO)
ABORT (ABOR)
DELETE (DELE)
REMOVE DIRECTORY (RMD)
MAKE DIRECTORY (MKD)
PRINT WORKING DIRECTORY (PWD)
LIST (LIST)
HELP (HELP)
Algunos de los cdigos usados en la transferencia son los siguientes, estos cdigos
no son ms que mensajes enviados por el protocolo:
Cdigos normales
200 Command okay.
500 Syntax error, command unrecognized. This may include errors such as
command line too long.
501 Syntax errors in parameters or arguments.
202 Command not implemented, superfluous at this site.
502 Command not implemented.
503 Bad sequence of commands.
504 Command not implemented for that parameter.
110 Restart marker reply. In this case, the text is exact and not left to the particular
implementation; it must read:
211 System status or systems help reply.
212 Directory status.
213 File status.
214 Help message. On how to use the server or the meaning of a particular non-
standard command. This reply is useful only to the human user.
215 NAME system type. Where NAME is an official system name from the list in the
Assigned Numbers document.
120 Service ready in nnn minutes.
220 Service ready for new user.
221 Service closing control connection. Logged out if appropriate.
421 Service not available, closing control connection. This may be a reply to any
command if the service knows it must shut down.
125 Data connection already open; transfer starting.
225 Data connection open; no transfer in progress.
425 Can't open data connection.
226 Closing data connection. Requested file action successful (for example, file
transfer or file abort).
426 Connection closed; transfer aborted.
227 Entering Passive Mode (h1, h2, h3, h4, p1, p2).
230 User logged in, proceed.
530 not logged in.
331 User name okay, need password.
332 Need account for login.
532 Need account for storing files.
150 File status okay; about to open data connection.
250 Requested file action okay, completed.
257 "PATHNAME" created.
350 Requested file action pending further information.
450 Requested file action not taken. File unavailable (e.g., file busy).
550 Requested action not taken. File unavailable (e.g., file not found, any access).
451 Requested action aborted. Local error in processing.
551 Requested action aborted. Page type unknown.
452 Requested action not taken. Insufficient storage space in system.
552 Requested file action aborted Exceeded storage allocation (for current directory
or dataset).
553 Requested action not taken. File name not allowed.
Cdigos de mensajes con operaciones numricas
110 Restart marker reply.
120 Service ready in nnn minutes.
125 Data connection already opens; transfer starting.
150 File status okay; about to open data connection.
200 Command okay.
202 Command not implemented, superfluous at this site.
211 System status or system help reply.
212 Directory status.
213 File status.
214 Help message. On how to use the server or the meaning of a particular non-
standard command. This reply is useful only to the human user.
215 NAME system type. Where NAME is an official system name from the list in the
Assigned Numbers document.
220 Service ready for new user.
221 Service is closing control connection. Logged out if appropriate.
225 Data connection open; no transfer in progress.
226 Closing data connection. Requested file action successful (for example, files
transfer or file abort).
227 Entering Passive Mode (h1, h2, h3, h4, p1, p2).
230 User logged in, proceed.
250 Requested file action okay, completed.
257 "PATHNAME" created.
331 User names okay need password.
332 Need account for login.
350 Requested file action pending further information.
421 Service not available, closing controls connection. This may be a reply to any
command if he service knows it must shut down.
425 can't open data connection.
426 Connection closed; transfer aborted.
450 Requested file action not taken. File unavailable (e.g., file busy).
451 Requested action aborted: local error in processing.
452 Requested action not taken. Insufficient storage space in system.
500 Syntax error, command unrecognized. This may include errors such as
command line too long.
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
504 Command not implemented for that parameter.
530 Not logged in.
532 Need account for storing files.
550 Requested action not taken. File unavailable (e.g., file not found, no access).
551 Requested action aborted: page type unknown.
552 Requested file action aborted. Exceeded storage allocation (for current directory
or dataset).
553 Requested action not taken. File name not allowed.
HTTP.
El protocolo HYPER TEXT TRANSFER PROTOCOL (protocolo para la
transferencia de hipertextos) es para todos los sistemas de informacin distribuidos
que tengas la necesidad de mostrar la informacin y pasarla por una comunicacin
normal haciendo uso de las ligas de este lenguaje. La primera versin de este
lenguaje (http 0.9) se uso desde 1.990.
El protocolo fue implementado inicialmente para WWW en 1.991 como una iniciativa
de software y se denomin http 0.9. El protocolo completo fue definido en 1.992 e
implementado en marzo de 1.993.
HTTP 1.0. esta especificacin prev las caractersticas bsicas del protocolo.
HTTP 1.1. la primera versin no est aun habilitada, pero las especificaciones son
muy similares a la anterior.
HTTP-NG next generation of HTTP, es un protocolo binario con nuevas
caractersticas para un acceso ms rpido usando TCP. Este es el ltimo HTTP en
la actualidad, es ms complejo que un 0.9.
El protocolo encierra cierta terminologa como:
Conexin. Es el circuito virtual establecido entre dos programas en una red de
comunicacin con el proceso de una simple comunicacin.
Mensaje. Esta es la unidad bsica, estos consisten en una secuencia estructurada
que es transmitida siempre entre los programas.
Servidor. El que presta el servicio en la red.
Proxy. Un programa intermedio que acta sobre los dos, el servidor y el cliente.
IPX/SPX
El internetwork packet exchange, sequence packet exchanged es un protocolo
usado y registrado por la compaa mundial de redes NOVELL.
NFS.
El network file system (sistema de archivos de red) es un sistema distribuido para
archivos, este es para las redes heterogneas, con este protocolo, el usuario solo
ve un directorio cuando esta dentro de la red, claro que tiene ramas dentro pero no
puede ver ms arriba de el nivel en el que se entra, tal ves los archivos dentro esta
estructura del directorio ni siquiera esta en la misma computadora.
POP3.
El protocolo Post office protocol versin 3 es netamente un protocolo para la
administracin de correo en Internet. En algunos nodos menores de Internet
normalmente es poco prctico mantener un sistema de transporte de mensajes
(MTS). Por ejemplo, es posible que una estacin de trabajo no tenga recursos
suficientes (hdd, entre otros) para permitir que un servidor de SMTP y un sistema
local asociado de entrega de correo estn residentes y continuamente en ejecucin.
De forma similar, puede ser caro mantener una computadora personal
interconectada a una red tipo IP durante grandes cantidades de tiempo.
A pesar de esto, a menudo es muy til poder administrar correo sobre estos nodos,
y frecuentemente soportan un user agent (agente de usuario) para ayudar en las
tareas de manejo de correo. Para resolver este problema, un nodo que s sea capaz
de soportar un MTS ofrecer a estos nodos menos dotados un servicio MAILDROP
(es el lugar en el sistema con el MTS donde el correo es almacenado para que los
otros nodos puedan trabajar con l sin necesidad de mantener su propio MTS. El
protocolo de oficina de correos est destinado a permitir que una estacin de trabajo
acceda dinmicamente a un MAILDROP en un HOST servidor de forma til y
eficiente. Esto significa que el protocolo POP3 se usa para permitir a una estacin
de trabajo recobrar correo que el servidor tiene almacenado.
POP3 no est destinado a proveer de extensas operaciones de manipulacin de
correo sobre el servidor; normalmente, el correo es transmitido y entonces borrado.
IMAP4 es un protocolo ms avanzado y complejo.
De aqu en adelante el trmino host cliente se refiere a un host haciendo uso del
servicio POP3 y host servidor al que ofrece este servicio. Inicialmente, el host
servidor comienza el servicio POP3 leyendo el puerto 110 TCP. Cuando un host
cliente desea hacer uso del servicio, establece una conexin TCP con el host
servidor. Cuando la conexin se establece, el servidor POP3 enva un saludo.
Entonces, el cliente y el servidor POP3 intercambian comandos y respuestas
respectivamente hasta que la conexin se cierra o es abortada.
Los comandos en el POP3 consisten en una palabra clave (keyword), posiblemente
seguida de uno o ms argumentos. Todos los comandos terminan con un par CRLF.
Las palabras clave y los argumentos consisten en caracteres ASCII imprimibles. Las
palabras clave son de una longitud de tres o cuatro caracteres, mientras que cada
argumento puede ser de hasta 40 caracteres de longitud.
Las respuestas en el POP3 consisten de un indicador de estado y una palabra clave
posiblemente seguida de informacin adicional. Todas las respuestas acaban en un
par CLRF. Las respuestas pueden ser de hasta 512 caracteres de longitud,
incluyendo el CRLF de terminacin. Tambin existen dos indicadores de estado,
positivo o afirmativo (+OK) y negativo (-ERR). Los servidores deben enviarlos en
maysculas.
Las respuestas a ciertos comandos son multilnea (una respuesta compuesta de
varias lneas). En estos casos despus de enviar la primera lnea de la respuesta y
un CRLF, se enva cualquier lnea adicional, cada una termina en un par CRLF.
Cuando todas las lneas de la respuesta han sido enviadas, se enva una lnea final,
que consiste en un octeto de terminacin y un par CRLF. Si alguna lnea de la
respuesta multilnea comienza con el octeto de terminacin, se ponen bites de
relleno precedidos por el byte de terminacin en esa lnea de la respuesta. De aqu
en adelante una respuesta multilnea termina con los cinco bytes CRLF.CRLF. Al
examinar una respuesta multilnea, el cliente comprueba si la lnea comienza con el
byte de terminacin. Si es as y si siguen otros bytes a excepcin del CRLF, el primer
byte de la lnea o de terminacin es ignorado. De este modo se el CRLF sigue
inmediatamente al carcter de terminacin, entonces la respuesta desde el servidor
POP termina y la lnea conteniendo CRLF no es considerada como parte de la
respuesta multilnea.
Una sesin POP3 progresa a travs de una serie de estados a lo largo de su vida.
Una vez la conexin TCP ha sido abierta y el servidor de POP3 ha enviado el
saludo, la sesin entra en el estado de autorizacin. En este estado, el cliente debe
identificarse al servidor de POP3. Una vez el cliente lo ha hecho satisfactoriamente,
el servidor adquiere los recursos asociados al maildrop del cliente, y la sesin entra
en el estado de transaccin. En este estado, el cliente realiza una serie de
solicitudes al servidor de POP3. Cuando el cliente ha emitido el comando de
finalizacin (QUIT) la sesin entra en el estado de actualizacin. En este estado, el
servidor de POP3 libera cualquiera de los recursos adquiridos durante el estado de
transicin, se despide y la conexin TCP se cierra.
Un servidor debe responder a comandos no reconocidos, no implementados, o
sintctica mente incorrectos con un indicador negativo de estado (respuesta
negativa). Tambin debe responder con un indicador negativo de estado cuando la
sesin se encuentra en un estado incorrecto. No hay un mtodo general para que
el cliente distinga entre un servidor que no implementa un comando opcional y un
servidor que no esta dispuesto o es incapaz de procesar el comando.
Un servidor de POP3 puede disponer de un temporizador o cronmetro de
inactividad (autologout inactivity timer). Tal cronmetro debe ser de por lo menos 10
minutos de duracin. La recepcin de cualquier comando desde el cliente durante
este intervalo reinicia la cuenta de este cronmetro. Cuando el cronmetro llega a
los diez minutos, la sesin no entra en el estado de actualizacin. Entonces, el
servidor debera cerrar la conexin TCP sin eliminar ningn mensaje y sin enviar
ninguna respuesta al cliente.
USER nombre
Argumentos: una cadena identificando un mailbox, el cual solo tiene significado para
el servidor
Restricciones: solo puede darse en el estado de autorizacin despus del saludo o
de los comandos USER o PASS sin xito.
Definicin: Para autentificar usando la combinacin de los comandos USER y
PASS, el cliente debe primero emitir el comando USER. Si el servidor responde
afirmativamente (+OK), entonces el cliente puede responder con el comando PASS
para completar la autentificacin, o el comando QUIT para finalizar con la conexin.
Si el servidor responde negativamente (-ERR) al comando USER, el cliente puede
emitir un nuevo comando de autenticacin o bien el comando QUIT.
El servidor puede devolver una respuesta afirmativa incluso a pesar de que no exista
ningn mailbox. El servidor puede devolver una respuesta negativa si el mailbox
existe, pero no permitir la autenticacin.
PASS cadena
Argumentos: palabra de acceso al mailbox
Restricciones: solo puede darse en el estado de autorizacin inmediatamente
despus de un comando USER satisfactorio.
Definicin: Cuando el cliente el comando PASS, el servidor utiliza el par de
argumentos de los comandos USER y PASS para determinar si al cliente se le debe
dar acceso al maildrop apropiado.
Ya que el comando PASS tiene exactamente un argumento, un servidor de POP3
puede tratar los espacios como parte del password en lugar de como separadores
de argumentos.
APOP nombre digest
Argumentos: una cadena identificando un mailbox y una cadena digest MD5
Restricciones: solo puede darse en el estado de autorizacin despus del saludo o
de los comandos USER o PASS sin xito.
Definicin: Normalmente, cada sesin POP3 comienza con intercambio
USER/PASS. Esto tiene como resultado una clave de acceso especfica enviada a
travs de la red. Para un uso intermitente del POP3, no conlleva un riesgo
considerable. Sin embargo, muchas implementaciones de cliente POP3 conectan al
servidor regularmente para comprobar si hay correo nuevo. Adems, el intervalo de
iniciacin de la sesin puede ser del orden de 5 minutos. Por lo tanto, el riesgo de
que la clave de acceso sea capturada es alto.
Se requiere un mtodo alternativo de autenticacin que no implique el envo de
claves de acceso a travs de la red. Esta funcionalidad la proporciona el comando
APOP.
Un servidor que implemente el comando APOP incluir una marca de tiempo
(timestamp) en sus "saludos". La sintaxis de la marca de tiempo corresponde al
"msg-id" en la RFC 882 (actualizada por RFC 973 y despus por RFC 1982), y debe
ser diferente cada vez que el servidor enva un saludo. Por ejemplo, en una
implementacin UNIX en la cual un proceso UNIX separado es el encargado de
cada instancia de servidor, la sintaxis de la marca de tiempo podra ser: process-
ID.clock@hostname, donde process ID es el valor decimal del PID del proceso,
clock es el valor decimal del reloj del sistema, y hostname es el nombre de dominio
del host donde el servidor est funcionando.
El cliente recibe esta marca de tiempo y emite un comando APOP. El parmetro
nombre tiene el mismo significado que el parmetro nombre del comando USER.
EL parmetro digest se calcula aplicando el algoritmo MD5 (RFC 1321) a una
cadena consistente en una marca de tiempo (incluyendo <) seguido de un secreto
compartido. Este secreto compartido es una cadena conocida solo por el cliente y
el servidor. Se debe tener un gran cuidado para prevenir una revelacin no
autorizada del secreto, ya que su conocimiento puede permitir a cualquier entidad
hacerse pasar por el usuario. El parmetro digest es un valor de 16 bytes que se
enva en formato hexadecimal, utilizando caracteres ASCII en minsculas.
Cuando el servidor recibe el comando APOP, verifica el digest proporcionado. Si el
digest es correcto, el servidor enva una respuesta afirmativa y la sesin entra en el
estado de transaccin. Si no, enva una respuesta negativa y la sesin permanece
en el estado de autorizacin.
Notar que conforme incrementa la longitud de los secretos compartidos, aumenta la
dificultad de derivarlos. Como tales, los secretos compartidos deben ser cadenas
largas (considerablemente ms largas que el ejemplo de 8 caracteres mostrado
abajo).
AUTH mecanismo
Argumentos: una cadena que identifique un mecanismo de autenticacin IMAP4
(definicin en IMAP4-AUTH).
Restricciones: slo puede darse en el estado de autorizacin.
Definicin: El comando AUTH se refiere a un mecanismo de autenticacin al
servidor por parte del cliente. Si el servidor soporta este mecanismo, lleva a cabo el
protocolo para la identificacin del usuario. Opcionalmente, tambin procede con un
mecanismo de proteccin para las subsiguientes interacciones del protocolo. Si este
mecanismo de autentificacin no es soportado, el servidor debera rechazar el
comando AUTH enviando una respuesta negativa.
El protocolo de autentificacin consiste en una serie de cuestiones por parte del
servidor y de unas respuestas del cliente, especficas de este mecanismo de
autentificacin. Una pregunta del servidor, es una lnea que consiste en un carcter
"+" seguido de un espacio y una cadena codificada en base 64. La respuesta del
cliente es una lnea que contiene otra cadena codificada en base 64. Si el cliente
desea cancelar la autentificacin, debe emitir una lnea con un nico "*". Si el
servidor la recibe, rechazar el comando AUTH.
Un mecanismo de proteccin proporciona integridad y privacidad a la sesin del
protocolo. Si se utiliza un mecanismo de proteccin, este ser aplicado a todos los
datos que se enven en la conexin. El mecanismo de proteccin tiene efecto
inmediatamente despus de que un CLRF concluya con el proceso de autenticacin
del cliente y de la respuesta positiva del servidor. Una vez el mecanismo de
proteccin se hace efectivo, el flujo de bytes de comandos y respuestas se procesa
en buffers de ciphertext (texto cifrado). Cada buffer es transferido en la conexin
como un flujo de bytes seguidos de un campo de 4 bytes que representan la longitud
de los siguientes datos. La longitud mxima de los bferes de ciphertext se define
en el mecanismo de proteccin.
No es necesario que el servidor soporte algn mecanismo de autentificacin, y
tampoco es necesario que los mecanismos de autentificacin soporten mecanismos
de proteccin. Si un comando AUTH falla, la sesin permanece en el estado de
autorizacin y el cliente puede probar con otro AUTH o bien con otro mecanismo
como la combinacin USER/PASS, o el comando APOP. En otras palabras, el
cliente puede pedir tipos de autentificacin en orden decreciente de preferencia, con
USER/PASS o APOP como ltimos recursos.
SI el cliente completa la autentificacin satisfactoriamente, el servidor de POP3
emite una respuesta afirmativa y se entra en el estado de transaccin.
TOP mensaje
Argumentos: un nmero de mensaje, que si aparece no se puede referir a ningn
mensaje marcado como borrado; y un nmero no negativo de lneas.
Restricciones: solo puede darse en el estado de transaccin.
Definicin: Si el servidor emite una respuesta positiva, entonces sta es multilnea.
Despus del +OK inicial, el servidor enva las cabeceras del mensaje, la lnea en
blanco separando las cabeceras del cuerpo, y luego el nmero de lneas del cuerpo
del mensaje.
Si el nmero de lneas requeridas por el cliente es mayor del nmero de lneas del
cuerpo, el servidor enva el mensaje entero.
UIDL [mensaje]
Argumentos: un nmero de mensaje opcional. Si est presente no debe referirse a
un mensaje marcado como borrado.
Restricciones: solo puede darse en el estado de transaccin.
Definicin: Si se da un argumento, el servidor emite una respuesta afirmativa con
una lnea que contiene informacin del mensaje. Esta lnea se llama unique-id
listing.
Si no se da ningn argumento y el servidor emite una respuesta afirmativa, la
respuesta dada es multilnea. Despus del +OK inicial, por cada mensaje en el
maildrop, el servidor responde con una lnea con informacin de ese mensaje.
Para simplificar el anlisis, todos los servidores deben tener un mismo formato de
unique-id listing, que consiste en el nmero de mensaje, un espacio y el unique-id
del mensaje. Despus no hay ms informacin.
El unique-id listing de un mensaje es una cadena arbitraria determinada por el
servidor, que consiste en 70 caracteres entre 0x21 y 0x7E (hexadecimal), los cuales
identifican nicamente un mensaje en el maildrop y los cuales permanecen a lo largo
de las distintas sesiones. Esta persistencia es requerida incluso si la sesin termina
sin entrar en el estado de actualizacin. El servidor nunca debera rehusar el unique-
id en un maildrop dado a lo largo de todo el tiempo de existencia de la entidad que
usa el unique-id.
Mientras que generalmente es preferible para implementaciones de servidor
almacenar los unique-id en el maildrop, la especificacin tiene la intencin de
permitir que los unique-id sean calculados como trozos del mensaje. Los clientes
deberan de ser capaces de manejar una situacin en la que se den dos copias
idnticas de un mensaje en un maildrop con el mismo unique-id.
SCP.
El modo SCP o simple communication protocol, es un protocolo simple que deja al
servidor y al cliente tener mltiples conversaciones sobre una TCP normal, esto
como es evidente declara que el protocolo SCP necesita montarse sobre es SCP.
Este protocolo esta diseado para ser simple de implementar.
El servicio principal de este protocolo es el control del dialogo entre el servidor y el
cliente, administrando sus conversaciones y agilizadas en un alto porcentaje, este
protocolo le permite a cualquiera de los dos establecer una sesin virtual sobre la
normal.
La descripcin de un formato de comunicacin en las cabeceras enviadas por la red
es la siguiente.

TCP/IP.
Este protocolo, el transfer communication protocol/Internet protocol, es el ms
usado actualmente en lo que a Internet se refiere. El TCP/IP es un conjunto de
protocolos de comunicacin, es decir convenciones particulares, creadas para
permitir la colaboracin y la particin de recursos entre ms ordenadores
conectados entre s en la que est definida como red o network. Internet es en
absoluto la ms grande entre todas las redes que existen, debido a que logra
conectar entre s ordenadores personales y redes de menor amplitud en todo el
mundo. Sobre Internet, de hecho, puede usted encontrar en conexin los
ordenadores de instituciones del gobierno, militares, universidades y empresas
privadas. Lo que permite a mquinas tan distintas por hardware y por prestaciones,
comunicarse entre s de manera casi transparente es el TCP/IP. Este constituye un
tipo de lenguaje universal comprendido y utilizado por todas las mquinas que
cooperan en red.
Estas son algunas definiciones de base. El nombre ms apropiado para indicar este
conjunto de protocolos, es Internet protocol suite, es decir coleccin de protocolos
de Internet. El TCP y el IP son dos protocolos que pertenecen a esta coleccin.
Puesto que stos son tambin los protocolos ms conocidos, ha entrado en el uso
comn Llamar TCP/IP a toda la familia, aunque en algunas ocasiones una
generalizacin parecida puede resultar un error. Cualquiera sea su nombre el
TCP/IP representa una familia de protocolos, proveen a la gestin de las funciones
de bajo nivel, que son necesarias para la mayora de las aplicaciones. El TCP y el
IP pertenecen a los protocolos de bajo nivel. Sobre esta base, se desarrollan otros
protocolos que gestionan funciones particulares como enviar correo electrnico o
conexin remota.
Todo esto est generalmente simplificado en un modelo cliente/servidor, en el cual
el servidor se identifica con el ordenador que proporciona un servicio especfico, a
travs del network y en el cual el trmino cliente se identifica con el ordenador que
explota este servicio, aunque con la palabra cliente incluya tambin aquellos
programas que uno utiliza para tener acceso a estos mismos servicios (netscape).
El TCP/IP es un conjunto de protocolos a capas o niveles. Por ejemplo, cuando se
quiere enviar un correo a travs de Internet, lo primero que se necesita es definir un
protocolo especfico para el correo, o sea, un conjunto de reglas unvocamente
reconocidas por todos los ordenadores conectados en red, y el cual tendr la tarea
de coger la carta que hay que enviar, aadirle el emisor y el destinatario enviarla a
quien corresponda. Esto ltimo es la tarea del protocolo especfico de gestin del
correo, que podra ser comparado al de una persona a la que un amigo muy
ocupado le deja una carta y ella se encarga de ponerla en el sobre, escribir los datos
de expedicin y echarla al correo.
Evidentemente, si slo existiese esta figura la carta se quedara eternamente en el
buzn sin que nadie se preocupase de hacerla llegar a su destino. Sin embargo,
nuestro amigo muy ocupado tendra suerte ya que existe una camioneta del servicio
de correos que dos veces al da vaca el buzn y transporta las cartas que all
encuentra a un lugar donde sern clasificadas y diferenciadas; all su preciossima
carta ser cuidada y mimada hasta que llegue al buzn del destinatario.
Para continuar con el paralelismo del ejemplo, diremos que el TCP/IP representa el
sistema de transporte de Internet. En particular, el TCP se preocupa de 'empaquetar'
bien todos los datos que le son suministrados por los protocolos de nivel superior;
es posible que los subdivida en ms partes si resultasen demasiado largos para un
solo envo en red; asimismo recuerda lo que ha sido enviado, se acuerda de volver
a enviarlo en el caso en que se hubiera perdido y controla que todo se realice de
forma transparente para el usuario.
Ya que este tipo de operaciones es de uso general y es necesario tanto para enviar
correo como para enviar ficheros u otras cosas, se ha pensado en hacer un
protocolo propio, que pueda ser utilizado por muchos otros. Es precisamente por
este motivo por lo que hemos definido protocolo de bajo nivel.
El TCP, sin embargo, no es el protocolo de nivel ms bajo desde el momento en
que ste utiliza el IP para realizar determinadas acciones. De hecho, a pesar de que
el TCP sea muy utilizado, existen protocolos que prefieren no usarlo y que para
funcionar slo necesitan las funciones que puede ofrecer incluso el ms humilde IP.
Este tipo de organizacin 'a capas' permite una gran eficiencia y un menor gasto de
recursos.
Para terminar con un ejemplo, el envo de un mensaje de correo electrnico a travs
de Internet utiliza un sistema compuesto por cuatro capas:
Un protocolo de alto nivel especfico para el correo 2.El protocolo TCP que es
utilizado tambin por otros protocolos de alto nivel 3.El protocolo IP que se ocupa
de la especfica tarea de tomar los paquetes y enviarles a su destino 4.El protocolo
del hardware especfico, que se utiliza para la transmisin y la recepcin de los
datos
A este punto se nos aparece claro el motivo por el que el conjunto de los protocolos
de Internet es llamado genricamente TCP/IP. De hecho, estos son los protocolos
ms utilizados y de los que slo pueden prescindir muy pocos protocolos de un nivel
ms alto.
Antes de terminar esta exposicin general sobre el funcionamiento del TCP/IP es
necesario introducir el concepto de data grama (datagram), que representa cada
uno de los paquetes de informaciones que es enviado a travs de la red. Como ya
hemos dicho antes, un conjunto de informaciones demasiado largo que es
subdividido en paquetes ms pequeos, precisamente llamados data grama, que
viajan individualmente en la red. Esto significa que si un fichero que se debe enviar
es subdividido en 10 data gramas secunciales, no est dicho que el cuarto llegue
antes que el sptimo, desde el momento en que ste puede perderse o tomar un
camino equivocado. Ser una tarea de los diversos protocolos el hacer que dicho
paquete sea enviado nuevamente y colocado en el correcto orden secuencial a su
llegada a destinacin.
Y ahora, para evitar los ataques de los "puristas" diremos que a pesar de que los
trminos, data grama y paquete son muy a menudo utilizados como sinnimos, en
realidad existe una diferencia. Mientras el data grama es especfico del TCP/IP y
representa la mnima unidad lgica utilizable por los diversos protocolos, el paquete
es una entidad fsica bien presente para quien administra una red de tipo Ethernet.
En el caso, por lo dems muy frecuente, que en un paquete viaje un solo data
grama, la diferencia es slo terica pero existen tambin especficas
configuraciones hardware de red que utilizan paquetes de dimensin menor
respecto al del data grama individual. Entonces sucede que una data grama se
descompone en ms paquetes durante el envo a la red especfica y que sea
recompuesto a su llegada, de forma absolutamente transparente respecto al mismo
data grama que... 'no se da cuenta' de haber sido descompuesto y luego
recompuesto. Es evidente cmo en dicha situacin los trminos paquete y data
grama no coinciden. Es una buena medida, por tanto, acostumbrarse a utilizar el
trmino data grama cuando se habla del TCP/IP.





ELMODELO OSI
En 1.984, la organizacin internacional de estandarizacin (ISO) desarroll un
modelo llamado open systems interconection (OSI, interconexin de sistemas
abiertos), el cual es usado para describir el uso de datos entre la conexin fsica de
la red y la aplicacin del usuario final. Este modelo es el mejor conocido y el ms
usado para describir los entornos de red. La arquitectura por capas que presenta el
modelo OSI proporciona las siguientes ventajas.
Reduce la complejidad. El entendimiento de cmo se realiza la interconexin y
operacin entre dos computadores se hace mucho ms sencillo cuando el modelo
se presenta por capas, esta divisin trae consigo sencillez en el aprendizaje de cada
uno los procesos involucrados en esta comunicacin y transferencia de informacin.
Estandariza las interfaces. El estndar OSI plantea un modelo en el cual un dato
pasa de un host a otro a travs de varios niveles o capas, estas se encargan de una
parte especfica tanto en la parte de codificacin como transporte y envi. Bajo este
esquema una debe proveer servicios a la capa superior e inferior, para lo cual se
debe establecer una interfaz nica y estndar entre cada una de las capas. No
importa el trabajo o la tecnologa bajo la cual la capa opere, siempre habr una
interfaz estndar para interactuar con las diferentes capas.
Facilita la ingeniera modular. Este modelo trae una gran ventaja cada vez ms
aprovechada, la posibilidad de disear equipos de comunicacin divididos en
mdulos, cuya tarea est orientada a cada una de las funciones de los niveles OSI.
Se logra entonces una modularidad que facilita el desarrollo de la tecnologa
independientemente en cada una de las partes que la componen.
Asegura la tecnologa nter operable. El hecho que las interfaces Sean III estndar
entre cada una de las capas y la misma modularidad, permite que diferentes
tecnologas se desarrollen en las capas, sin que se presente incompatibilidad entre
stas. Lo que logra, es entonces, una alta interoperabilidad entre cada tecnologa,
permitiendo el desarrollo por diferentes cambios tecnolgicos.
Acelera la evolucin. La ingeniera modular es fuerte en este sentido, es decir,
provee la forma para que cada ente que la compone se desarrolle por separado.
Aqu en los niveles OSI, tambin se presenta este hecho. Esta divisin a la que nos
hemos referido, ha permitido que cada capa se desarrolle vertiginosamente.
Simplifica la enseanza y el aprendizaje. Este esquema tambin provee una forma
fcil de ensear y aprender el proceso de comunicacin Inter redes. Algo un poco
complicado en los esquemas anteriores.
El modelo OSI se presenta en 7 capas, enumeradas desde la inferior (capa No. 1
fsica) hasta la superior (No.7 aplicacin). A continuacin la explicacin de cada una
de ellas. La grafica que se da a continuacin ayudara a dar una idea del
funcionamiento de las capas:


CAPA FISICA.
La capa fsica del modelo OSI es la que se encarga de las conexiones fsicas de la
computadora hacia la red, en este nivel estn, por ejemplo, los estndares de cable
de par trenzado que se deben usar para conectar una red, la forma en que las
antena de microondas deben estar orientadas para comunicarse, y las
caractersticas de propagacin de ondas radiales. Define la conexin fsica de la
red.
CAPA DE ENLACE DE DATOS.
Entrega los datos entre un nodo y otro en un enlace de red. La capa de enlace de
datos, provee la transmisin de los bits en frames de informacin, es quien checa
que los bits lleguen libres de errores a su destino y controla las secuencias de
transmisin y los acuses de recibo de los mensajes recibidos. Tambin se encarga
de retransmitir los paquetes o frames que no han sido acusados por el otro
extremo.

Tambin este nivel controla el flujo de informacin entre dos nodos de la red.
Este nivel solo se encarga de la transmisin y recepcin de datos entre dos nodos
colindantes, y no es quien redirige o re-enruta paquetes (ese es el siguiente nivel,
el nivel de red).
La capa de enlace provee la transmisin fsica a travs del medio. Maneja el control
de errores, la topologa de la red, y el control del flujo. Esta capa se encarga de
preparar los datos antes de enviarlos a travs del medio fsico.
Un ejemplo del nivel de enlace de datos es el estndar de ETHERNET o el de ATM.
CAPA DE RED
Las capas tres y cuatro manejan lo que comnmente conocemos como networking
o manejo de red. Es aqu donde se definen las rutas, destinos y caminos de llegada
de un punto a otro de la red. Esto es comnmente lo que manejan las capas de
TCP/IP. Todo lo referente a los ROUTERS, BRIDGES, IP ADDRESS, IP MASK,
ETC pertenecen a este nivel.
Un destino es un punto valido en la red donde los mensajes pueden llegar y ser
enviados. Para llegar a un destino, debe de existir una ruta de comunicacin, por lo
general los puntos aislados de la red solo apuntan a una direccin default (que se
llama el default gateway). En una red pequea esto significa el ROUTER ms
cercano. Este Router tiene las direcciones ms conocidas de la red y el enlace que
conduce a ellas. Si la direccin que se le manda no es conocida por el ROUTER,
este tambin tiene un default gateway que es un ROUTER en una red ms grande,
as se va pasando de ROUTER a ROUTER MAYOR, hasta llegar al Internet
backbone, que es una red de SUPER ROUTERS que tienen todas las direcciones
de Internet y el SUPER ROUTER ms cercano a ellas.
Las funciones de esta capa tambin pueden ser capaces de reconfigurar la red para
que los datos fluyan por un camino u otro si es que un enlace se cae.
Esta capa finalmente determina el mejor camino para mover los datos de un lugar
a otro.
Maneja el direccionamiento de los dispositivos y supervisa la ubicacin de los
dispositivos en la red. Los enrutadores operan en esta capa.




CAPA DE TRANSPORTE.
Ahora, si mandamos un archivo grande, este archivo deber de ser dividido en
pedazos que puedan ser transmitidos por la red, estos pedazos viajan por la red y
al llegar al destino deben ser acomodados de la manera en que fueron enviados
(pueden desacomodarse por que pueden tomar diferente ruta se acaso una se
congestiona o se cae). La forma de reacomodar los paquetes, cuanto tiempo y como
esperar por ellos son las funciones de la capa 4.
Esta capa segmenta y reensambla los paquetes de datos en un bloque de datos en
un bloque de datos. Se encarga de la interconexin de los equipos. Aqu es donde
se negocia el inicio y terminacin de una comunicacin y la cantidad de paquetes a
enviar. Algunas de sus funciones ms importantes son las siguientes:
Segmenta las aplicaciones de las capas superiores.
Establece una conexin extremo-extremo.
Enva segmentos de un host extremo a otro.
Opcionalmente, asegura la confiabilidad de los datos.
Se encarga de la conexin, reconocimiento, transmisin.

CAPA DE SESIN.
La capa de sesin es la encargada de ordenar o decidir a donde deben de ir los
datos, adems, indicar cuantos datos se enviaran o recibirn en cierto destino de la
red. Una comunicacin en la red tiene dos tipos. Con conexin lgica (conection
oriented, como el TCP) o sin conexin lgica entre los nodos (conection less como
el UDP). En la comunicacin con conexin primero se establece una conexin lgica
(una serie de mensajes se envan para saber primero si es que podemos establecer
la comunicacin entre los nodos). Una vez que la comunicacin ha sido establecida,
entonces los datos fluyen entre los dos destinos de la red. Cuando la comunicacin
ya no es necesaria entonces la conexin se libera.
La capa de sesin establece, mantiene y maneja las sesiones entre las aplicaciones.
Es una comunicacin interhost.
CAPA DE PRESENTACIN.
Un protocolo de comunicaciones debe ser diseado para que diferentes versiones
y sistema lo puedan usar, de modo que los datos se deben de tener en un formato
definido y documentado. Por ejemplo una pgina de HTML debe tener campos
como el puerto, la direccin URL, y el texto del mensaje. Esos campos sern
transmitidos como bits y bytes y hay un documento (el estndar de HTML) que me
indica en que parte del mensaje va cada pedazo de la pagina. Precisamente de esto
es lo que se encarga la capa de presentacin, recibe bits y bytes de las aplicaciones
y las formatea de modo que sean octetos entendibles en una red. Recibe un
mensaje con octetos de una red y los decodifica para que se conviertan en bits y
bytes de una aplicacin. Esta capa provee la representacin de datos y el formateo
del cdigo. Asegura que los datos que recibe de la red puedan ser utilizados por la
aplicacin, y asegura que la informacin enviada por la aplicacin pueda ser
transmitida en la red.
CAPA DE APLICACIN.
Todas las capas anteriores en el modelo OSI sirven como infraestructura de
telecomunicaciones. Por si solas no hacen nada ms que mantener en buen estado
el camino para que fluyan los datos, la capa que hace posible que una red se pueda
usar es la capa de aplicacin.
Es aqu donde lo visible y lo ms orientado a es usuario se genera. A esta capa
pertenecen por ejemplo los Web browser, el FTP, el e-mail, el telnet, las
presentaciones de shockwave, los java applets y dems.
Una aplicacin en java solo tiene que saber en que direccin y en que puerto se
localiza el nodo remoto y ordenar a las dems capas (por medio de un TCP API)
que vayan a ese nodo remoto y le enven informacin.
La capa de aplicacin provee servicios de red a las aplicaciones de los usuarios.
Por ejemplo, una aplicacin de un procesador de palabras es servida por los
servicios de transferencia de archivos en esta capa. La aplicacin es lo que es
tangible para el usuario en el monitor, es el programa que se ejecuta.
















CONCLUSIONES


El protocolo HART es un protocolo abierto, basado en el estndar 4-20 mA, que
tiene cierta cantidad de aos en el mercado.

Actualmente ah industrias cuyo dispositivos no estn comunicados ni conectados
en red. Este problema se soluciona poniendo en red a todos los dispositivos y
configurndolos mediante un protocolo Fielbus o Profibus, ya que estos tienen
mayor cobertura en cuanto a un proceso propiamente dicho.





































BIBLIOGRAFIA


http://www.infoplc.net/files/documentacion/comunicaciones/infoPLC_net_Historia_
Comunicaciones_Industriales.pdf
http://www.aie.cl/files/file/comites/ca/articulos/agosto-06.pdf
http://neutron.ing.ucv.ve/revista-e/No4/RCI.html
https://www.youtube.com/watch?v=bynszU6OhY4
http://sp.hartcomm.org/protocol/about/aboutprotocol_what.html