DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE DE CONTROL PARA UN

CENTRO DE MECANIZADO CNC

PEDRO FERNANDO GIFFUNI SALAZAR

Monografía para optar al título de

Ingeniero Mecánico

Director

FERNANDO MEJÍA UMAÑA

Ingeniero Mecánico

UNIVERSIDAD NACIONAL DE COLOMBIA

FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA MECÁNICA

SANTAFÉ DE BOGOTÁ, D. C.

1996

AGRADECIMIENTOS

El autor expresa sus agradecimientos a:

ANDRES DIAZ GONZALEZ, Ingeniero electrónico y Profesor del Departamento

de Fisica de la Universidad Nacional de Colombia.

FERNANDO MEJIA UMAÑA, Ingeniero Mecánico y Director de la Investigación.

ii

CONTENIDO

pág.

INTRODUCCIÓN 11

1. CONFORMACIÓN DE UN SISTEMA DE

MANUFACTURA AUTOMATIZADA 16

1.1 EL CONTROL NUMÉRICO POR COMPUTADOR 16

1.2 ECONOMÍA EN LA MANUFACTURA 18

1.3 ESQUEMA CLÁSICO 21

1.4 ESTRUCTURA CIM 23

1.5 CONTROL NUMÉRICO DIRECTO: DNC 27

iii

pág.

1.5.1 El DNC Convencional 29

1.5.2 Direct CNC Network (DCN) 30

2. REDES PARA MANUFACTURA: MAP Y TOP 33

2.1 DESARROLLO HISTÓRICO 34

2.2 EL MODELO OSI 37

2.3 APLICACIONES OSI 41

2.3.1 File Access Transfer and Management (FTAM). 42

2.3.2 Correo Electrónico. 42

2.3.3 Terminales Virtuales. 43

2.3.4. Otras Aplicaciones. 43

2.4 VERSIONES COMERCIALES DE REDES OSI 44

2.5 PARTICULARIDADES DE MAP Y TOP 45

2.6 EL NIVEL FÍSICO 46

2.6.1 Nivel Físico TOP 47

iv

pág.

2.6.2 Nivel Físico MAP 48

2.7 SERVICIOS MAP Y TOP 49

2.8 EL NIVEL DE APLICACIÓN EN MAP 51

2.8.1 Aplicaciones MAP 52

2.8.2 Manufacturing Message Specification (MMS) 54

3. MODELO DEL CONTROLADOR NUMÉRICO 59

3.1 LA UNIDAD DE EJECUCIÓN 60

3.2 LA UNIDAD CONSOLA 62

4. PROGRAMACIÓN DE UNA MÁQUINA HERRAMIENTA

CNC 64

4.1 CONTROLES 64

4.2 INSTRUCCIONES OPERACIONALES 66

4.3 INFORMACIÓN DE PROGRAMACIÓN 70

4.3.1 Información Geométrica 70

v

pág.

4.3.2 Información Tecnológica 72

4.4 ESTRUCTURA GENERAL 73

4.5 POSTPROCESADORES Y CLDATA 75

5. DESARROLLOS ANTERIORES EN LA UNIVERSIDAD

NACIONAL 81

5.1 PROTOTIPO DE UNA MESA POSICIONADORA 81

5.2 CONTROLADORES NUMÉRICOS 83

5.2.1 Controladores Superior Electric© 83

5.2.2 Controlador U.N. 86

6. EL SOFTWARE DE CONTROL 93

6.1 SELECCIÓN DEL AMBIENTE DE PROGRAMACIÓN 93

6.2 DISEÑO DEL SOFTWARE 96

6.2.1 Ventajas de la Programación Orientada a Objetos 97

6.2.2 Estructura del Programa 98

vi

pág.

6.2.3 Consideraciones Técnicas 99

6.3 EL CONTROLADOR DE DISPOSITIVOS 100

6.4 EL CONTROLADOR DE EVENTOS 104

6.5 LA CONSOLA 105

6.6 FUNCIONAMIENTO DEL PROGRAMA 107

7. CONCLUSIONES 109

REFERENCIAS BIBLIOGRÁFICAS 114

ANEXOS 116

vii

LISTA DE FIGURAS

pág.

Figura 1. Modelo Jerárquico de una Instalación de

Manufactura Automatizada. 25

Figura 2. Estructura Común de una Implementación

CNC. 28

Figura 3. Variantes de Sistemas DNC. 29

Figura 4. Comparación entre Dos Estrategias de Control

Numérico. 31

Figura 5. Configuración Típica MAP-TOP. 36

Figura 6. El Nivel de Aplicaciones en MAP. 54

viii

pág.

Figura 7. Esquema de un Dispositivo de Manufactura

Virtual (VMD). 55

Figura 8. Modelo Moreaux de un Controlador Numérico. 61

Figura 9. Ejemplo de una Configuración de Hardware

Generalizada. 66

Figura 10. Jerarquía de las Instrucciones Operativas. 67

Figura 11. CLDATA Convencional vs. BCL. 79

Figura 12. Mesa Posicionadora del Convenio SENA-UN. 82

Figura 13. Controlador MX 2000. 84

Figura 14. Arreglo de Controladores Superior Electric. 85

Figura 15. Esquema de Funcionamiento del Controlador U. N. 87

Figura 16. Interrupción con el Protocolo Traducido. 88

Figura 17. Configuración Usada en el Controlador U. N. 89

Figura 18. Listado de ComDev.h. 101

Figura 19. Cuadro de Diálogo para Configurar el Puerto. 104

ix

Figura 20. Imagen del Menu de Edición en la Aplicación. 106

Figura 21. Imagen del Programa Final en el Ambiente Gráfico

de Windows 95™. 107

x

LISTA DE TABLAS

pág.

Tabla 1. Representación de los Niveles OSI. 40

Tabla 2. Suites de Protocolo MAP y TOP. 50

Tabla 3. Instrucciones Operacionales Comunes. 69

Tabla 4. Códigos G Comúnmente Usados. 71

Tabla 5. Algunos Códigos M. 73

xi

Resumen

Durante el desarrollo del proyecto se investigaron las estrategias adecuadas para obte-

ner una estructura de control automatizado en una empresa metalmecánica. Con este

fin se obtuvieron modelos en bloques de un controlador numérico genérico y del mane-

jo de la información en una planta industrial, y se identificó la necesidad de distribuir la

inteligencia de la planta donde ésta se requiere.

Se investigaron diversos avances tecnológicos como el control numérico directo y las

redes industriales, que pueden ser decisivos en el momento de seleccionar la estrategia

de manufactura que usará un planta industrial competitiva.

Como resultado de la investigación se utilizó la programación orientada a objetos co-

mo una herramienta adecuada para implementar un programa de computador capaz de

controlar diversos dispositivos de manufactura.

Al final se incluye el programa con todo su código fuente y una copia del informe en

formato postscript.

INTRODUCCIÓN

En la historia de la humanidad hay periodos de grandes cambios en que se modifican

los rumbos de las generaciones: la revolución industrial y la revolución electrónica son

dos momentos históricos que presentan esa característica y que han impulsado el desa-

rrollo tecnológico y el avance de la ingeniería. Siguiendo el espíritu de estas grandes

revoluciones hay una tendencia creciente por incorporar nuevas tecnologías al proceso

de producción con la esperanza de tener algún día un proceso en que la única interac-

ción del ser humano con su fábrica sea la de diseñar.

Por supuesto, la revolución industrial y la electrónica no son las primeras ni las últimas

expresiones de cambio en la humanidad: hoy en día se vive en el mundo una revolu-

ción informática, donde no sólo prima la capacidad de acción sino la oportunidad de la

información.

Entendiendo que todo proceso moderno de manufactura involucra un problema de

transporte y procesamiento de información, es fácil comprender la necesidad de dar un

13

enfoque nuevo a los proyectos de manufactura automatizada. Dentro de este marco,

las empresas mejoran sus canales de comunicación y adquieren redes informáticas so-

fisticadas para mejorar su proceso productivo y, por supuesto, responder mas rápido a

las necesidades del mercado.

En el caso particular de la Universidad Nacional, si bien la universidad posee un lide-

razgo natural en el área de la manufactura, comprobado por sus diversos convenios y

proyectos, el problema del manejo de la información no se ha tratado como problema

central en ningún proyecto de grado de manufactura automatizada.

Dentro del convenio SENA-UN, por ejemplo, se han venido diseñando dispositivos

para un centro de mecanizado de tal suerte que con una dirección adecuada de los

proyectos de grado se logre completar una máquina funcional. De acuerdo con las

limitaciones que usualmente tienen las entidades públicas, esta estrategia puede ser la

única que se puede seguir, sin embargo la falta de comunicación entre los diversos

grupos de trabajo hace necesario que cada grupo asimile los progresos de los demás

grupos o que recurra a rediseñar lo que los demás han construido. Si bien el problema

no es inmanejable, la situación se agrava a medida que el proyecto adquiere más carac-

terísticas multidisciplinarias.

El software del sistema de control es el elemento que relaciona los desarrollos de cada

disciplina involucrada: el software debe acceder toda la funcionalidad de la máquina y

14

hacerla disponible al usuario final. Inicialmente se pensó que el problema del software

debería ser solucionado exclusivamente por ingenieros de sistemas, sin embargo la

aceptación que tal software pueda tener a largo plazo depende de la facilidad con éste

software se adapte a la tecnología propia del sector metalmecánico, por lo cual se ha

entendido que la estructura inicial debe ser propuesta por un ingeniero mecánico.

El objetivo de este proyecto de grado es el de plantear un modelo del software de alto

nivel que gobierne un centro de mecanizado genérico, y de esta forma aporte linea-

mientos para futuros desarrollos en la Universidad Nacional. Para cumplir este objeti-

vo esencial, se estudiaron las diversas tecnologías utilizadas en los países industrializa-

dos de tal forma que se mantuvieran las normas técnicas vigentes y obtener una solu-

ción compatible con la tecnología externa. Un objetivo secundario, el diseño de un

prototipo del software para controlar la mesa posicionadora XY, constituye una guía

importante para las etapas posteriores del proceso investigativo.

En el primer capítulo, Conformación de un Sistema de Manufactura Automatizada, se

analizan diversos aspectos económicos del proceso de manufactura y se presenta un

modelo de distribución de planta que permite estandarizar las comunicaciones en los

procesos de manufactura.

15

El segundo capítulo recoge el espíritu del primero y trata el tema de las redes indus-

triales. El tema de este capítulo es una aporte completamente nuevo que se deriva de

la revolución informática actual.

El tercer capítulo, Modelo del Controlador Numérico, presenta los fundamentos

esenciales para la construcción del software de manufactura: en él se presenta un mo-

delo con las características de un controlador numérico genérico y su software de

control.

El cuarto capitulo, Programación de una Máquina Herramienta CNC, presenta todos

los factores que se deben tener en cuenta para interactuar con una máquina de control

numérico. Toda la información de este capitulo está normalizada, lo cual facilita la mi-

sión de unificar conceptos frente al diseño actual.

En el último capitulo se presenta el software que se diseñó, junto con una descripción

breve de las herramientas utilizadas. Más importante que el programa mismo, se pre-

sentan los criterios de diseño y se presenta un modelo que se ajusta a las necesidades

del problema estudiado.

Los tres anexos merecen una presentación especial. Aunque estos documentos fueron

modificados para mantener un formato estándar, se respetaron algunos aspectos de los

documentos originales como el espaciado.

16

El anexo A es la norma básica que se sigue internacionalmente para adecuar redes in-

dustriales a las redes ordinarias que usan TCP-IP. El documento es de libre distribu-

ción.

El anexo B es un documento que describe el protocolo MMS. Este documento, de di-

fícil consecución, sirve de guía para un futuro desarrollador en el momento de utilizar

una red de comunicación industrial. El documento es de libre distribución siempre que

su contenido sea respetado integralmente y no se use para fines comerciales.

El anexo C presenta el conjunto de instrucciones de una máquina herramienta dispo-

nible comercialmente: es importante en cuanto presenta un protocolo típico basado en

las normas ISO. Estas normas se obtuvieron durante un curso en el SENA.

CONFORMACIÓN DE UN SISTEMA DE MANUFACTURA AUTOMATIZADA

1.1 EL CONTROL NUMÉRICO POR COMPUTADOR

El desarrollo de la electrónica industrial y de los computadores en los últimos años ha

traído consigo nuevas opciones en los métodos de manufactura tradicional. El control

numérico por computador (CNC), en particular, pretende aprovechar el manejo numé-

rico avanzado de los computadores para automatizar una buena parte de la manufactu-

ra moderna. Tales desarrollos han cambiado la forma misma en que se concibe el pro-

ceso de producción metalmecánico, haciendo el proceso cada vez más automático.

En la actualidad se consiguen comercialmente máquinas mandrinadoras, cepilladores,

robots industriales, rectificadoras, fresadoras, prensas, tornos, cizallas taladradoras y

plegadoras de control numérico. Debido a su alto costo estas máquinas se usan para

una labor específica; sin embargo, por su flexibilidad, llama a la atención el creciente

uso de los centros de mecanizado. Un centro de mecanizado es una máquina que po-

18

see un gran número de herramientas y un cambiador automático, de ésta forma se

puede obtener una gran variedad de funciones en la misma máquina. Cambiar la confi-

guración de herramientas de una máquina CNC provee una habilidad para cambiar la

capacidad de producción.

Entre las ventajas de una máquina de control numérico se encuentran:

• Alta precisión y buenos terminados gracias al control automático del proceso. Se

reducen, además los tiempos muertos y se aumenta la velocidad de posicionamiento

de la máquina.

• Repetitividad de algoritmos que permiten la producción en serie de piezas: basta

recuperar un programa ya almacenado para poder fabricar una pieza particular.

• Independencia a errores del operario, especialmente en piezas que requerirían gran

concentración al ser fabricadas por otros medios.

Entre las desventajas se encuentran:

• El elevado costo del puesto de trabajo.

• Mayor dificultad al planear el trabajo debido a la dificultad en adaptar una máquina

a cualquier necesidad: el ser humano entiende el problema y plantea alternativas.

No hay, entonces, una metodología predeterminada que nos diga cuando o que caso es

mejor adoptar un sistema CNC. La tecnología actual presenta gran dinamismo: no solo

19

aparecen y desaparecen nuevas tecnologías constantemente, sino que las condiciones

del mercado varían, siendo necesario mantenerse al tanto de los nuevos desarrollos. La

estrategia a seguir debe ser la de aprovechar la flexibilidad que puede dar el software

para resolver los problemas que tradicionalmente tienen las máquinas herramientas.

Manufactura flexible implica capacidad flexible, y ésta se obtiene con mano de obra

flexible, personal experto en diversas áreas, o con maquinado flexible, máquina con

variedad de herramientas.

No siempre utilizar una máquina CNC es la solución óptima para una empresa: la ex-

periencia de un operario es un valuarte muy importante que no es incompatible con las

nuevas tecnologías. La tendencia actual indica que en materia de automatización, una

empresa ya conformada obtiene mejores resultados al mejorar primero su planeamien-

to de operaciones y su gestión de producción.

1.2 ECONOMÍA EN LA MANUFACTURA

En los últimos años se ha presentado una creciente competencia entre las industrias

norteamericanas, europeas y japonesas. El caso del Japón llama la atención entre los

economistas por tratarse de un país pobre en recursos naturales que perdió una guerra

20

mundial. El éxito inicial de los productos japoneses en los diversos mercados del se

explicó por una combinación entre un mercadeo eficiente y una mano de obra barata,

sin embargo los sueldos japoneses eventualmente pasaron los sueldos norteamericanos

por lo que esta explicación perdió vigencia. Una explicación posterior se dió en la efi-

ciencia de los procesos productivos, pero ni siquiera los procesos norteamericanos de

máxima eficiencia, denominados Advanced Manufacturing Tecnology (AMT), han lo-

grado productos con el nivel de aceptación en el consumidor que tienen los productos

japoneses. Hoy en día1 se considera que la supremacía japonesa no se debe a que sus

procesos sean mas eficientes que los de los competidores sino que simplemente son

más eficaces.

En un estudio sobre el ámbito colombiano, realizado por Oscar Marulanda y Camilo

Rubio2, sobre la asimilación de nuevas tecnologias en el sector metalmecánico, se pre-

sentan estadísticas oficiales del DANE y se estima que entre 1968, año en que llegó la

primera maquina herramienta de control numérico (MHCN), y 1982 se habían incor-

porado menos de 50 MHCN en el país. La baja adquisición es, según los autores, de-

bida al bajo costo de la mano de obra en el país y la estructura industrial. Una apertura

económica tiene una influencia fuerte, especialmente en el sector de las autopartes, y

se presenta como un arma de doble filo: por un lado se desestimula la producción na-

1 Ver Lowry, J. “Japan: a lead to follow?”, CADCAM International, 1988, 7, (12), pp 19-21.

2 Marulanda O. y C. Rubio. “Impacto de la tecnología microelectrónica en la industria metalmecánica de Co-lombia”. OFICEL, Bogotá (Informe de Investigación), 1983

21

cional debido al bajo costo que permiten los altos índices de producción en los países

industrializados, por otra parte facilita la entrada de nuevos fabricantes de MHCN, es-

pecialmente los fabricantes orientales que ofrecen maquinas pequeñas y relativamente

baratas, más acordes con lo requerido en las empresas nacionales medianas y grandes.

Existen varias estrategias de diseño para minimizar los costos de manufactura, aumen-

tando así la competitividad y las ganancias. Boothroyd3 plantea dos reglas básicas: di-

señar de tal manera que se usen tantos elementos normalizados como sea posible, y

minimizar la cantidad de mecanizado con el preformado de la pieza. Estas reglas po-

drían resumirse en un principio general: evitar mecanizar.

En una operación con velocidad de corte constante y en desbaste, el costo de produc-

ción por elemento terminado es:

C = Mt + MKv + Mt v (Mt + C )vpr I-1

r-1

r-1/ n

c t(1-n)/ n

t

donde M = Costo total de máquina y mano de obra

tI = Tiempo improductivo

K = Constante de la operación

vr = Velocidad de corte para la vida de herramienta, tr

tct = Tiempo de cambio de herramienta

Ct = Costo de una herramienta afilada

v = Velocidad de corte

n = constante que depende del material de la herramienta 3 Bootroyd, Geoffrey, Fundamentos del corte de Metales y de las Máquinas Herramientas, Bogotá, McGraw Hill.

22

En un centro de mecanizado se pretende optimizar cada uno de estos factores, espe-

cialmente el tiempo de cambio de herramienta tct, y el tiempo improductivo tI, para

obtener un mecanizado eficiente.

La mejora en velocidades de mecanizado, y en particular la eliminación de los tiempos

muertos son la clave para conseguir un proceso económicamente eficiente. Lógica-

mente, la eficiencia del proceso no garantiza el éxito económico pero marca la pauta

para aumentar la rentabilidad.

1.3 ESQUEMA CLÁSICO

La tecnología del control numérico por computador se mezcla con otras estrategias

diversas que tienden a lograr el esquema conocido como Computer Integrated Manu-

facturing (CIM). CIM es la participación coordinada de los computadores en todas las

fases de la manufactura. El objetivo final es lograr una infraestructura con el máximo

nivel de automatización en la que sea más sencillo pasar del diseño original a la pieza

fabricada.

23

Aunque las bondades del control numérico no requieren de ninguna otra tecnología o

de la aplicación de alguna estrategia de producción, este se ve fortalecido al aplicar di-

chos principios. Los resultados, por tanto, son mejores cuando las tecnologías moder-

nas se combinan con nuevas estrategias de producción. En empresas que no requieren

excesivo personal administrativo es más barato comenzar implementando las estrate-

gias de producción modernas, como JIT y Kanban, para después combinarlas con la

innovación tecnológica. El objetivo es aumentar la productividad y por tanto aumentar

las ganancias a través de la creciente automatización de los sistemas productivos co-

rrientes.

Es usual encontrar fábricas que usan tecnologías viejas que han sido reemplazadas

paulatinamente con tecnologías nuevas. En las plantas nuevas, este no es el caso ge-

neral; las maquinas herramientas tradicionales, aunque mas baratas, son reemplazadas

por máquinas mas especializadas y modernas. Por la flexibilidad de estas máquinas, y

su alto costo, es claro que se deben reducir los tiempos muertos para recuperar rápi-

damente la inversión inicial. En estos casos, la planeación de la producción es de gran

relevancia y antecede la decisión de adquirir el equipo.

En Colombia las redes industriales son tecnologías aún lejanas, por lo que se tiende a

hacer énfasis solo en la planeación de recursos de materiales. Dentro de las nuevas

tecnologías tenemos redes industriales, el diseño asistido por computador, la manufac-

24

tura asistida por computador, y las herramientas de planeación de la producción. Al-

gunas de estas tecnologías se han estabilizado, como es caso de Manufacturing Auto-

mated Protocol (MAP), mientras que otras, como el Computer Assisted Production

Planning (CAPP), están aún en una etapa de investigación.

1.4 ESTRUCTURA CIM

Para que CIM actúe como un sistema homogéneo es necesario que cada sector discre-

to de la industria tenga acceso a cualquier información que requiera. Una solución

sencilla a un problema tan complicado consistió en almacenar toda la información del

proceso en una sola base de datos centralizada que podría ser consultada por todos los

subsistemas de manufactura. Esta teoría resultó poco viable por las siguientes razones:

• Aún con la tecnología actual, se duda que una base de datos pueda almacenar todos

los detalles actualizados del proceso.

• De existir la base de datos, la respuesta sería muy lenta por la cantidad de procesos

e información involucrada.

25

• Cada función realizada por el subproceso requiere solo una pequeña porción de la

información disponible.

• La administración y el mantenimiento de tal sistema serían complejas e inmaneja-

bles.

La dificultad de implementar todas las funciones requeridas en un solo sistema y la ne-

cesidad de mantener el control del proceso cerca de donde éste se realiza han mostra-

do la necesidad de distribuir el sistema de información.

La calidad del sistema de comunicaciones es vital para el correcto desarrollo de una

estrategia CIM: una herramienta adecuada, pero no la única, es usar redes locales para

transmisión digital.

Las funciones realizadas por un sistema de información en un ambiente industrial se

pueden clasificar de acuerdo a un modelo jerárquico como el propuesto por el Natio-

nal Institute of Standards and Technology4, NIST, de los Estados Unidos5. En la ar-

quitectura propuesta hay cuatro componentes básicos: el control de los sistemas de

manufactura, la administración de la información distribuida, los sistemas de comuni-

caciones, y la interfaze con usuarios. De estos cuatro puntos, el más importante es el

4 El National Bureau of Standards (NBS), fue reemplazado posteriormente por NIST.

5 McLean C., Mitchell M. y Barkmeyer E. A Computer Arquitecture for Small-Batch Manufacturing, IEEESpectrum, n. 5, Mayo 1983

26

control de los sistemas de manufactura, ya que de este se derivan algunas característi-

cas en los demás.

En este modelo se ordenan los módulos de control de acuerdo a una jerarquía. Cada

control recibe comandos únicamente de una jerarquía superior, pero puede redireccio-

nar algunos comandos al nivel inmediatamente inferior. De esta manera, los procesos

se reciben en un nivel superior y se dividen en subpartes mas sencillas a medida que se

desciende en la jerarquía para realizar operaciones de bajo nivel.

El comportamiento de un sistema de manufactura debe ser adaptivo y determinístico;

por tanto la estructura de control será una jerarquía de controles realimentados que se

modelan e implementan como máquinas de estado. El sistema de control resultante es,

entonces, un procesador complejo de todas las entradas, salidas, estados, y transicio-

nes de estado de cada subsistema en el proceso de manufactura.

En todo caso se debe tener en cuenta un ciclo de control, es decir la variable tiempo,

que garantice que el subproceso mantenga su estado dentro de límites aceptables.

27

En el modelo de control jerárquico aparecen cinco niveles: facilidades, taller, celdas,

estaciones de trabajo, y herramientas. Cada nivel contiene uno o varios controles que,

a su vez, se pueden subdividir en subniveles o módulos.

1.4.1 Facilidades. El sistema más alto de control compromete tres subsistemas: inge-

niería de manufactura, administración de la información y gerencia de producción. La

ingeniería de manufactura provee interfaces de usuario para el diseño asistido por

Instalación Física(Facilidades)

Taller

Celdas

Estaciones deTrabajo

Herramientas

Red de Transmisión

Nodos deComunicaciones

Robot Fresadora

Estación de

Fresado

Buffer de Partes

Celda Virtual 1

Robot

Taller de Máquinas

Máquina Inspec-

ción

Estación de Inspec-

ción.

Facilidad

Buffer de Partes

Taller de Ensamble

Celda Virtual N

RobotCarro - Robot

Estación de

Trabajo N

Transportador

Nivel CIM

Figura 1. Modelo Jerárquico de una Instalación

de Manufactura Automatizada.

28

computador, al igual que la planeación de los procesos de producción. La administra-

ción de la información provee interfaces y soporte para inventarios, distribución de los

pedidos, y reabastecimiento. La gerencia de producción hace seguimiento de los pro-

yectos importantes e identifica la capacidad de producción y sus requerimientos o ex-

cesos. La información de planeación en este nivel se utiliza para dirigir el sistema de

control del taller en el siguiente nivel.

1.4.2 Taller. Este nivel es el responsable por el manejo en tiempo real de los recursos

y labores a través de dos módulos: gerencia de funciones y gerencia de recursos. El

primero programa las órdenes de trabajo, el mantenimiento de equipos, y los servicios

de soporte en taller. El segundo módulo asigna las estaciones de trabajo, las herra-

mientas y los materiales a la celdas de manufactura y los procesos específicos de pro-

ducción.

1.4.3 Celdas. Los controladores de este nivel controlan la secuencia de trabajo en

partes similares o ensamblajes, incluyendo manipulación de materiales y calibración. Al

definirse, en el nivel anterior, los materiales, recursos, y procesos necesarios, queda

configurada una celda virtual de manufactura. La celda se denomina “virtual” porque

en este caso no se trata de un agrupamiento físico específico en la planta, sino de un

29

agrupamiento lógico. Los módulos dentro de este nivel son de gran inteligencia, ya

que deben analizar la disponibilidad de recursos, reportar el progreso de los trabajos y

llevar registros de las labores realizadas en las estaciones de trabajo.

1.4.4 Estaciones de Trabajo. Este nivel dirige y coordina grupos de equipos dispo-

nibles en la planta. El controlador prepara la secuencia de trabajo en los equipos, te-

niendo en cuenta la preparación de la pieza, los procesos de corte, el desplazamiento

del material entre máquinas, la inspección y la limpieza.

1.4.5 Herramientas. Los controladores están conectados directamente a una variedad

de equipos que realizan todo el trabajo físico. Usualmente se encuentran robots, má-

quinas herramientas de control numérico, máquinas de medición, sistemas de distribu-

ción, y dispositivos de almacenamiento.

1.5 CONTROL NUMÉRICO DIRECTO: DNC

30

Los Programable Logic Controllers (PLC´s) y los controladores numéricos CNC son

herramientas que han estado presentes durante muchos años, y su permanencia depen-

de del nivel que alcance la tecnología de los microcomputadores. La tendencia crecien-

te es tener controladores numéricos tan poderosos que reemplacen los controladores

lógicos programables PLC, estos controladores pueden ser máquinas dedicadas, de

manera análoga a un PLC, o puede ser una tarjeta electrónica en una estación de traba-

jo.

El DNC, o control numérico directo, es una herramienta que ha ganado gran populari-

dad por el éxito que se ha tenido usando CAD/CAM para realizar contornos tridimen-

Controlador Numérico

Máquina Herramienta

CN

Almacenamiento

Secundario

Consola Operario

Producto Terminado

CAD/CAM

CAPP

Producción

Figura 2. Estructura Común de una

Implementación CNC

31

sionales. Si bien los programas que se generan a partir de las trayectorias de los pro-

gramas CAD/CAM son inmensos, la memoria de un controlador numérico es muy pe-

queña y se requiere un método de control que permita la alimentación progresiva de la

información.

1.5.1 EL DNC CONVENCIONAL

El DNC consta de tres componentes: el control numérico en la máquina herramienta,

el computador, y la línea serial que los conecta.

(a) DNC Mínimo. (b) DNC con Red Local.

Figura 3. Variantes de Sistemas DNC.

32

Aunque estos tres componentes son la esencia del DNC, el ambiente típico de desarro-

llo tiene muchos otros factores: el transporte de la información entre el centro

CAD/CAM y el computador del DNC puede ser un factor importante a considerar.

Aunque el mensajero ha sido el sistema tradicional de transportar la información, los

ambientes de alta producción adoptaron redes de área local (LANs) de alta velocidad

para transportar esta información.

1.5.2 DIRECT CNC NETWORK (DCN)

Un cable serial convencional transporta la información a una velocidad de 960 caracte-

res por segundo, mientras una red local transporta fácilmente un millón de caracteres

por segundo. Esta diferencia, con mejora de casi mil veces en el transporte de la in-

formación, hace pensar en aprovechar ese ancho de banda en otras aplicaciones

(regulación del proceso, información de audio, vídeo, etc..) pero también sugiere una

perspectiva más interesante: la conexión directa del controlador a la red y la subse-

cuente desaparición de las etapas intermedias de transporte.

33

En el caso de maquinados tridimensionales sofisticados esta tecnología es casi una ne-

cesidad por la excesiva cantidad de comandos requeridos a medida que se aumentan

los detalles: algunos programas pueden alcanzar los 100 M bytes.

Por tratarse de una tecnología reciente, la desventaja de este sistema es el alto costo

inicial: el costo de poner un controlador en red puede alcanzar los 12,000 dólares por

máquina si ésta no viene con la instalación adecuada. En la mayoría de los casos, sin

embargo, este costo se puede pagar muy rápidamente en eficiencia.

MáquinaCNC

PC DNC

LAN1,000,000Car./seg.

RS 232360 Car./seg.

EstaciónCAD/CAM

LAN1,000,000Car./seg.

Diagramas de Flujo:DNC vs. DCN

DNC DCN EstaciónCAD/CAM

MáquinaCNC

Figura 4. Comparación entre dos Estrategias

de Control Numérico.

34

Como vemos en la figura, al usar una LAN para transportar la información se están

siguiendo los lineamientos Kanban de disminuir pasos innecesarios.

En el enlace físico de un sistema DNC se deben verificar cotidianamente las siguientes

condiciones:

1. La integridad del cableado (de longitud limitada) y los aislamientos.

2. La velocidad de transmisión o tasa baud.

3. El protocolo.

4. Corrección de errores y recuperación.

5. El formato de la información.

Para optimizar el flujo de información se requiere además un preprocesamiento de la

información y un esquema de compresión de información.

Una red de CNC directo elimina los dos últimos pasos y tiene preconfigurados los as-

pectos relativos a integridad del cable, tasa baud, protocolo y corrección de errores.

Mientras en un cable RS232 se llena de ruido o se pierde información antes de 15 me-

tros, una red local se mantiene libre de errores por más de un kilómetro. Con el exce-

sivo ancho de banda de una LAN se pueden usar formatos mas engorrosos y se pueden

incluir comentarios en los programas.

Para el grupo de trabajo existen ventajas adicionales al usar una LAN para transportar

la información: para el programador el controlador se comporta como un disco duro

35

externo o una impresora remota donde se manda información, para el operario no ha-

brán interrupciones y se podrá seguir con las labores con menos tiempos muertos.

La escogencia entre un sistema DNC o un sistema DCN depende de la infraestructura

de la empresa y del tipo de producción que se realiza. Los sistemas DCN son demasia-

do recientes y por este motivo muchas empresas prefieren esperar que la tecnología se

estabilice. En la actualidad la necesidad de redes industriales de bajo nivel, denomina-

das también buses de campo, han hecho que diversas entidades como ISO, IEC, IFC, y

entidades locales de países industrializados estudien la normalización de estos siste-

mas. Las normas ISO relativas a buses VME están disponibles localmente.

REDES PARA MANUFACTURA: MAP Y TOP

El Manufacturing Automated Protocol, MAP, es una red de área local, LAN, diseñada

específicamente para el ambiente de manufactura en planta. Diversos fabricantes han

ofrecido redes informáticas que pretenden no solo agilizar el trabajo en la celda de

manufactura, sino también proveer un enlace de comunicación directa entre las divi-

siones de la planta. La gran desventaja de estas LANs consistió en que fueron redes ce-

rradas, es decir, poseían una implementación propia del fabricante y no se podían co-

municar entre sí.

2.1 DESARROLLO HISTÓRICO

Hacia el final de la década de los 70’s la empresa General Motors poseía 20,000 pro-

gramadores controlables, 2,000 robots y 40,000 dispositivos inteligentes, y sólo un

37

15% de sus dispositivos tenían capacidad de conectarse entre sí. No solo las máquinas

de distinta marca tenían problemas para comunicarse: los fabricantes no se preocupa-

ban por mantener compatibilidad entre los distintos modelos. Esta falta de conectivi-

dad electrónica llevo a que se formaran diversas islas de automatización dentro de la

misma planta, por lo cual requirieron puentes adicionales para comunicarlas.

En 1973, basándose en el proyecto de grado de un estudiante de postgrado de MIT, la

corporación Xerox lanzó al mercado la red de área local (LAN) Ethernet. Ethernet fue

adoptada rápidamente por diversos fabricantes, incluyendo la compañía Intel que desa-

rrollo un controlador para ella en un circuito integrado.

A principios de los 80´s, General Motors (GM) encontró que sus los costos en redes

alcanzaron el 50% del valor total de los gastos requeridos en automatización. Ante

este hecho la compañía inició un equipo de trabajo con participantes ajenos a General

Motors para desarrollar una solución al problema de la diversidad de fabricantes. Una

parte importante de la red de GM era la necesidad de automatizar el sistema de robots

en las líneas de ensamble de tal forma que todo estuviera en LAN. Debido a que las lí-

neas de ensamble se desplazan a una razón fija, GM consideró importante conocer de

antemano el límite superior del tiempo de respuesta en el caso de peor transmisión.

Para facilitar la interconexión entre distintos tipos de redes se decidió especificar una

red abierta basada en un conjunto específico de estándares de comunicaciones entre

38

computadores que tuviera concordancia el modelo OSI. Open Systems Interconnect

(OSI) es un modelo de referencia para comunicación entre computadores que está dis-

ponible internacionalmente. La implementación de los estándares seleccionados y la

arquitectura de red se conoció posteriormente como la red de área local MAP.

Después del primer documento publicado de MAP en octubre de 1982, se han desa-

rrollado tres versiones: V1.0 en 1984, V2.0-2.2 en 1985-86, y la V3.0 en 1987. La

rápida evolución de MAP, aproximadamente una versión por año, se debió a la evolu-

ción simultánea del modelo OSI, y al surgimiento de nuevas tecnologías y funciones

MAP. A partir de la versión 3.0, se decidió dar un tiempo de espera antes de lanzar

una nueva versión para dar tiempo a que se estableciera la tecnología: las versiones

anteriores de MAP todavía se distribuyen pero no son compatibles con la V3.0. Como

la especificación la provee un usuario (General Motors) se tiene independencia del

proveedor, con lo que se espera interconectividad entre diversos equipos y fabricantes.

Con posterioridad a MAP, IBM escogió la red de área local token ring como su están-

dar. Ante la proliferación de LAN´s (Ethernet, Token Bus, y Token Ring) el Instituto

de Ingenieros Eléctricos y Electrónicos, IEEE, decidió que tres estándares son mejo-

res que ninguno, y los normalizó todos, de tal suerte que se definieron los estándares

IEEE 802.3 (Ethernet), IEEE 802.4 (Token bus) y IEEE 802.5 (Token Ring).

39

Al protocolo de automatización en manufactura, MAP, posteriormente se le sumo Te-

chnical Office Protocol (TOP), con el objetivo de interconectar todas las áreas de

automatización, oficina y planta, en un solo estándar. TOP surgió debido al interés por

parte de Boeing en normalizar el trabajo en oficina. Boeing seleccionó Ethernet debido

a la inmensa base instalada comercialmente en esta red, teniendo en cuenta que no te-

nia necesidad de mantener líneas de producción como GM.

En las implementaciones actuales, MAP funciona sobre un cable de banda ancha en un

bus de señal pasante, es decir Token Bus, mientras TOP corre en banda base, em-

pleando Detección de Colisión de Múltiple Sentido de Portadora, es decir Ethernet.

Aunque MAP y TOP difieren en el nivel más bajo de conexión, GM y Boeing han tra-

bajado juntos para garantizar la interconectividad entre sus redes. La relación entre

MAP y TOP se entiende mejor estudiando el esquema que sigue a continuación:

Figura 5. Configuración Típica MAP-TOP.

40

Se observa que las máquinas herramientas están conectadas a un red MAP mientras

que las celdas de manufactura se unen por redes TOP.

2.2 EL MODELO OSI

Proveer comunicaciones confiables en procesos distribuidos entre computadores su-

ministrados por varios vendedores sobre multiplicidad de medios que se pueden en-

contrar a varios metros, o a varios kilómetros, es un problema muy complicado. Como

marco para solucionar este problema, la International Standards Organization (ISO)

definió Open Systems Interconnect (OSI), consistente en una arquitectura, una especi-

ficación de servicios, y una especificación de protocolos. La arquitectura define los

objetos que componen la red OSI y define el modelo de referencia en niveles. La arqui-

tectura también define los servicios que provee cada nivel, pero no como se implemen-

tan. La especificación del protocolo describe las reglas especificas para el intercambio

de información y los procedimientos para interpretar esta información.

41

El modelo OSI de interconexión de computadores no se desarrolló de la noche a la

mañana: se basó en diversos protocolos que aún están vigentes. Dos redes que sirvie-

ron para modelar OSI son: TCP-IP, y SNA. Transfer Control Protocol - Internet

Protocol, TCP-IP, es el protocolo usado en la red mundial Internet y tiene como ven-

taja su popularidad y el hecho de ser el soporte de red nativo en máquinas UNIX.

Systems’ Network Architecture, SNA, es un protocolo creado por IBM para comunicar

todos los modelos, antiguos y nuevos, de sus servidores y computadores personales.

SNA es una arquitectura más complicada que TCP-IP, pero ofrece mucho más que el

simple transporte de datos: de aquí OSI adoptó el concepto de capas.

Los criterios para la selección de las capas son:

1. Una capa debe ser creada cuando se necesita un nivel de abstracción distinto.

2. Cada capa debe cumplir una función bien definida

3. La función de cada capa se debe escoger respetando los protocolos normalizados

internacionalmente.

4. Las fronteras entre capas se deben escoger para minimizar el flujo de información a

través de las interfaces.

42

5. El número de capas debe ser lo suficientemente grande para que en la misma capa

no se realicen funciones distintas, y lo suficientemente pequeño para que la arqui-

tectura no sea inmanejable.

El modelo de referencia en capas es el resultado de dividir el conjunto de las funciones

complejas, necesarias para la interconexión, en siete capas, o niveles, manejables con-

ceptualmente. En este modelo cada capa (N) usa los servicios que provee la capa an-

terior (N-1) y añade los servicios que son propios de su capa, creando así un nivel

nuevo de servicios para la capa superior. La capa siete proveerá un conjunto de servi-

cios resultante de combinar los servicios de todas las capas anteriores.

Todas las capas se comunican con sus contrapartes en la máquina remota, pero como

toda la información pasará por el medio físico, es decir la capa inferior, se hace nece-

saria una compatibilidad completa entre todas las capas para lograr la comunicación.

Los siete niveles, o capas, que define OSI, están dados en la tabla 1.

43

Tabla 1.

Representación de los Niveles OSI

Capa Nivel Descripción

Nivel de Aplicación 7 Debido a que no hay más niveles, sirve de en-lace de toda la cadena y provee los elementosde transferencia de archivos, los servicios co-munes de aplicaciones, y el servicio de directo-rio.

Nivel de Presentación 6 Dos aplicaciones en sistemas heterogéneos,con distintos mecanismos de codificación,conjuntos de caracteres, longitudes de palabra,valores de rango de números reales, etc., debencompartir el mismo lenguaje (protocolo) paracomunicarse.

Nivel de Sesión 5 Ayuda al nivel superior permitiendo a todas lasaplicaciones el control, la organización y el sin-cronismo del diálogo en una forma consistente.

Nivel de Transporte 4 Determina el control de flujo, haciendo usoefectivo del servicio de red disponible y, sobretodo, manteniendo la integridad de la informa-ción.

Nivel de Red 3 Habilita la interconexión entre varias subredes.El direccionamiento del nivel de red es usadopara enrutar a través de las subredes hacia eldestino final.

Enlace de Información 2 Convierte la capa no estructurada de informa-ción que provee el nivel físico en un canal decomunicaciones confiable orientado a mensa-jes.

Nivel Físico 1 Es nivel más bajo en el modelo, provee losmedios mecánicos, físicos, eléctricos y proce-dimentales para facilitar la transmisión entresistemas.

44

Más que una especificación, el modelo OSI proporciona una base sobre la cual se de-

sarrollan aplicaciones de uso general que comparten un ambiente sofisticado. Cada

uno de los niveles tiene su propia norma ISO, sin que su incumplimiento afecte la vali-

dez del modelo.

2.3 APLICACIONES OSI

El nivel de Aplicación, capa 7, es el puerto de acceso del programador a todos los

servicios de la red OSI. Los programas de aplicación que deseen intercambiar infor-

mación con otro programa de aplicación, usando OSI, deben primero identificarse en

la red y después establecer una asociación. La asociación es, en terminología OSI, un

circuito virtual, análogo a una conexión telefónica, entre las dos aplicaciones que se

comunican sobre las capas OSI. Cuando el intercambio de información se completa, la

asociación se termina y el circuito virtual se rompe.

No se entrará en detalles sobre las aplicaciones disponibles en el modelo OSI porque la

bibliografía disponible es suficientemente extensa y se encuentran implementaciones

públicas, pero es importante entender lo que se puede hacer con una red OSI. En al-

45

gunos servicios, específicamente el correo electrónico, se está siguiendo la norma ISO

para garantizar el intercambio mundial de información.

2.3.1 File Access Transfer and Management (FTAM). Las dos aplicaciones más

comunes en cualquier red de computadores son la transferencia de datos y el acceso a

archivos remotos. La necesidad de transferir archivos se presenta en distintos ámbitos,

desde un archivo de dibujo que debe ser accedido por varios ingenieros hasta la nece-

sidad de utilizar almacenamiento que unidades que no lo poseen. Para efectos de la red

se considera que el sistema donde están los datos es el servidor mientras que hay va-

rios clientes interesados en intercambiar información.

Usualmente cada máquina almacena su información de manera distinta, por lo que se

necesita una aplicación que esconda los detalles del sistema de archivos y que haga

transferencias de manera normalizada. Esta normalización es la función fundamental

del protocolo OSI y se accede a través de FTAM.

2.3.2 Correo Electrónico. Los primeros implementadores de redes pensaron, equivo-

cadamente, que los servicios en tiempo real serían los mas usados. El correo electróni-

co, en que un usuario envía un mensaje que el destinatario puede leer su correo cuan-

do vuelva a conectarse a su máquina, es el servicio más usado en todas las redes. El

46

correo electrónico, o e-mail, debe su popularidad a su velocidad y a la posibilidad de

almacenar los mensajes de manera cómoda.

El correo electrónico es un caso particular de la transferencia de archivos con dos dife-

rencias importantes: el servicio va dirigido a humanos, no a máquinas, y hay una es-

tructura especial que se debe tener en cuenta; destinatario, encabezado, fecha, etcéte-

ra. La aplicación OSI se denomina MOTIS, Message-Oriented Text Interchange

Systems, y comprende todo el proceso que sigue el correo desde su composición hasta

su destrucción.

2.3.3 Terminales Virtuales. Por alguna razón la normalización de las sesiones con

terminales ha sido un completo fracaso. Cada terminal identifica una serie de caracte-

res especiales, denominados secuencias de escape, para controlar las modalidades de

vídeo y los caracteres invisibles. Hay una serie de normas de para estos caracteres;

ANSI, VT100, TN3270, etcétera, pero no se ha logrado un consenso. El resultado es

que muchas teclas no responden y la conexión es inútil.

OSI ha decidido normalizar una estructura de datos que almacene todas las caracterís-

ticas de la pantalla y dejar que cada implementador de pantalla se preocupe por man-

tener el comportamiento. Esta estructura de datos es denominada una terminal virtual.

47

2.3.4. Otras Aplicaciones. Existen otras aplicaciones normalizadas o en proceso de

normalizarse. Algunas aplicaciones son muy generales mientras que algunas se aplican

a industrias específicas. Uno de los servicios más importantes que se catalogan en este

grupo son los servicios de directorio, en que un servidor mantiene toda la información

que facilita la ubicación de los demás sistemas en la red.

Al implementar las aplicaciones OSI, se observó que habían elementos en común en

casi todas las aplicaciones. Estos elementos se agruparon en dos paquetes que no ac-

túan directamente pero que forman parte del nivel de aplicación:

1. El Aplication Common Service Element, ACSE, provee los servicios necesarios pa-

ra el establecimiento y terminación de asociaciones. Este elemento es usado por to-

dos las aplicaciones que requieren mantener una conexión.

2. Commitment, Concurrency, and Recovery, CCR, coordina las interacciones entre

varios sistemas de tal forma que nunca fallen. Este elemento es usado por las apli-

caciones que requieren confiabilidad.

2.4 VERSIONES COMERCIALES DE REDES OSI

48

El modelo OSI es todavía un campo de activa investigación: es la base del protocolo

Z39.50 para intercambio de información, el directorio X500 y el servicio Simple

Network Management Protocol (SNMP), entre otras aplicaciones. Hoy en día, existen

muchas aplicaciones, comerciales y de dominio público, que proveen servicios típicos

OSI: la entidad que coordina la normatividad de estas aplicaciones es el National Insti-

tute of Standards and Technology, NIST.

Una herramienta que se desarrolló para estudiar OSI es el ISO Development Environ-

ment, ISODE. ISODE es una implementación libre, es decir sin propietario, de las ca-

pas superiores del modelo OSI; se puede ejecutar en todas las versiones de UNIX de

Berkeley (4.2, 4.3, 4.4) y de AT&T (SVR2, SVR3, SVR4). El código fuente, y las

aplicaciones ISODE se consiguen libremente hasta la versión 8.0 en la red mundial In-

ternet. Como el desarrollo de este tipo de herramientas implica tiempo y gastos, des-

pués de la versión 8.0 se formó el consorcio ISODE6 y se restringió la distribución de

nuevas versiones, con contadas excepciones, a sus miembros. La Universidad Nacional

de Colombia adelantó las gestiones necesarias para recibir una licencia de este produc-

to.

6 ver http://www.isode.com

49

2.5 PARTICULARIDADES DE MAP Y TOP

MAP y TOP se basan en el modelo OSI, pero han adicionado aplicaciones especializa-

das, y se han propuesto como normas para la industria. ACSE, FTAM y el servicio de

directorio se soportan en MAP y TOP, pero no se soporta CCR en ninguna y en MAP

el soporte de terminal virtual es sólo parcial.

Una colección de protocolos, uno por capa, como MAP o TOP, es comúnmente de-

nominado una pila de protocolos (en inglés stack), o una suite de protocolos. Como

en las demás redes OSI, a medida que se asciende en la pila se obtienen funciones cada

vez más sofisticadas. De la siete capas, los dos más importantes para el diseñador de

aplicaciones en una red MAP son el nivel Físico, y el nivel de Aplicación; el resto de

niveles son transparentes para el usuario final.

2.6 El Nivel Físico

El nivel Físico, capa 1, se encarga de los requerimientos mecánicos y eléctricos rela-

cionados con la transmisión de bits tales como niveles de voltajes, cables de señales, y

técnicas de señalización.

50

A partir de MAP 3.0 se definió la banda ancha como mecanismo para permitir diversas

conexiones simultáneas. El nivel físico es de la mayor importancia cuando la red MAP

todavía no está instalada: en este caso el diseñador debe decidir si se requiere, o no, la

capacidad multicanal de banda ancha, o si bastará la capacidad de una portadora sen-

cilla que es más barata. Una decisión de este tipo se toma pensando en los planes es-

tratégicos a largo plazo y no solamente sobre la base de la necesidad inicial. Una po-

sibilidad, por ejemplo, es usar el ancho de banda que sobra para transmitir vídeo, au-

dio, y otras redes locales.

2.6.1 Nivel Físico TOP

La red TOP ha usado desde un principio tarjetas Ethernet para su nivel físico, aunque

posteriormente se añadió Token Ring7. Ethernet es un producto que cumple con la

norma IEEE 802.3 y por tanto parte de una topología de conexión a lo largo de una

línea. Existen dos tipos de cable coaxial que se usan para Ethernet: Ethernet grueso y

Ethernet delgado. Ethernet grueso es físicamente parecido a una manguera de jardín

amarilla con marcas cada 2.5 metros para mostrar donde van los taps. Ethernet delga-

do es mucho menos grueso pero solo sirve para distancias menores. Ambos tipos de

Ethernet son compatibles entre sí.

7 Token Ring se añadió a TOP en 1987.

51

Los niveles lógicos son tres: todo valor superior a 0.85 voltios se identifica como un

nivel alto, todo valor menor a -0.85 voltios es un nivel bajo, y todo valor intermedio

comprende un estado inactivo. Un bit 0 es un nivel alto seguido de uno bajo y un bit 1

es un nivel bajo seguido de uno alto, esta técnica llamada Manchester encoding permi-

te determinar cuando termina o comienza un bit.

La descripción técnica del protocolo es 1-persistent CSMA/CD, por este término se

entiende que cuando una estación desea transmitir información debe escuchar en el

cable y podrá transmitir solo si hay silencio. En caso que dos estaciones transmitan du-

rante el mismo intervalo de tiempo la colisión será detectada y se deberá repetir la

transmisión después de un tiempo que se determina de manera aleatoria. Por este mé-

todo es consiguen velocidades de transmisión entre 1 y 10 Mbps.

2.6.2 Nivel Físico MAP

La respuesta en tiempo aleatoria, típica de Ethernet, hizo necesaria una nueva imple-

mentación de red local que garantizara una respuesta en los problemas de tiempo real.

La red token bus usa como medio físico un cable coaxial de 75-ohms de banda ancha,

similar al usado para televisión. Se permiten sistemas de cable sencillo o cable dual: en

el cable dual cada cable se usa para transmisión en un solo sentido y se consigue ma-

yor eficiencia.

52

Al igual que en Ethernet, la topología de red es una línea con varias estaciones col-

gando de ella. A diferencia de un anillo, esta topología es más conveniente en una

planta porque la comunicación no se puede suspender para añadir o retirar una esta-

ción.

Token Bus tiene dos diferencias importantes con Ethernet:

• A pesar de distribuirse físicamente en línea, en Token Bus la configuración lógica de

las estaciones las hace comportarse como si estuvieran en anillo. Cada estación solo

conoce la dirección de sus vecinas inmediatas.

• Las estaciones toman turnos, según el anillo lógico, para transmitir la información

pertinente por lo que las colisiones no deben existir, y se puede determinar el tiem-

po de respuesta.

2.7 Servicios MAP y TOP

Tanto MAP como TOP siguen estrechamente el modelo OSI pero se diferencian en el

medio físico pues, como se sostuvo anteriormente, MAP usa token bus mientras TOP

usa Ethernet o Token Ring. Para obtener compatibilidad entre ambos, se acordó usar

el mismo protocolo para el nivel 2 en ambas redes.

53

En la tabla se puede observar la gran similaridad entre MAP y TOP, identificándose

entre paréntesis el número de la norma ISO que identifica cada protocolo.

Otro protocolo que coincide (véase Tabla 2) es el de Transporte clase 4. Este proto-

colo es muy similar al usado en la red militar ARPANET, hoy parte de Internet. La ra-

zón para esta similaridad radica en que años de experiencia en internet-ARPA ha de-

mostrado que el método de datagramas es más flexible y robusto para conectar múl-

tiples redes heterogéneas. Para que toda la información sea transmitida por un solo ca-

nal se acostumbra dividirla en paquetes: cada una de éstas unidades de información

Tabla 2.

Suites de Protocolo MAP y TOP

Capa MAP TOP

7 FTAM DS MMS FTAM DS VTP MHS

6 Protocolo de Presentación OSI(8823)

Protocolo de Presentación OSI(8823)

5 Protocolo de Sesión OSI (8327) Protocolo de Sesión OSI (8327)

4 Transporte orientado a cone-xión Clase 4 (8073)

Transporte orientado a conexiónClase 4 (8073)

3 Modo sin conexión (8473) Modo sin conexión (8473)

2 Control de Enlace Lógico(8802/2)

Control de Enlace Lógico(8802/2)

1 Token bus (8802/4) Ethernet(8802/3)

Token Ring(8802/5)

54

debe poseer información asociada a cada capa, de allí el término datagrama. Las in-

formaciones de identidad y destino son relevantes en cada paquete para poder proveer

el enrutamiento, así como también es necesario un mecanismo de detección de errores:

todo sistema de información tiene una probabilidad de error, por lo que se debe mane-

jar un protocolo que retransmita la información en caso de ser necesario. En el caso de

ARPA se supuso que la red no era confiable, especialmente durante una guerra, y se

deseaba que los paquetes de información pudieran seguir rutas alternas. El haber pen-

sado la red de esta manera, es decir con una capa de transporte robusta pero compleja,

ha hecho posible que MAP y TOP puedan enlazarse a casi cualquier tipo de red.

2.8 EL NIVEL DE APLICACIÓN EN MAP

MAP y TOP implementan un subconjunto de las aplicaciones del modelo OSI. Como

el objetivo de OSI es comunicar computadores distintos, solo se especificaron proto-

colos de comunicación entre máquinas; nunca se impuso limitaciones a los diseñadores

de aplicaciones. Bajo estas condiciones, lo único importante es que el software cumpla

su función y esto usualmente ocurre de alguna manera que depende de la máquina

particular.

55

Para los diseñadores de MAP, era inaceptable tener que cambiar los programas tan

pronto se adquiriera una nueva tarjeta MAP; es decir no debería haber dependencia

entre máquinas. Por este motivo, los diseñadores de MAP decidieron dar condiciones

adicionales a las de OSI y para ello dedicaron 2300 páginas en la especificación MAP.

El resto de este capitulo es dedicado casi con exclusividad a MAP ya que es la red más

relacionada con la manufactura en planta.

2.8.1 Aplicaciones MAP

La especificación MAP define cinco contextos de aplicaciones: Private, Manufactu-

ring Message Specification (MMS), File Transfer Access Management (FTAM),

Administración de la Red, y Servicios de Directorio. De estos cinco, el programador

de aplicaciones usa, típicamente, los primeros tres:

• Private: es el más simple de los contextos; provee acceso directo al Application

Common Service Element (ACSE), y al nivel de Presentación (capa 6). Un progra-

ma de aplicación establece una asociación de contexto privado con otro programa

para intercambiar información sin estructura.

• Manufacturing Message Specification (MMS): soporta el intercambio de mensajes

entre el programa de aplicación y los dispositivos de la planta tales como controla-

dores numéricos, robots, y controladores lógicos programables. El intercambio de

56

información se da en formatos de mensajes definidos de acuerdo a la capacidad del

dispositivo particular.

• File Transfer Access Management (FTAM): este contexto soporta operaciones del

programa de aplicación sobre archivos que pueden estar en cualquier parte de la

red. Ejemplos de funciones de alto nivel son: copia de archivos, mover, borrar, leer

atributos, y cambiar atributos. Ejemplos de funciones FTAM de bajo nivel son:

abrir, cerrar, crear, borrar, leer, y escribir.

La versión 3.0 de MAP define un Application Service Element (ASE) para cada uno

de estos contextos, que provee el servicio requerido en cada caso. Para que cada pro-

grama de aplicación use los servicios específicos de contexto, provistos por el ASE, se

ha definido una Application Programming Interface (API). Los API´s están definidos

en términos de llamadas de funciones al contexto ASE y los bloques de control de in-

formación para pasar parámetros específicos de función entre el programa de aplica-

ción y el ASE de contexto.

57

2.8.2 Manufacturing Message Specification (MMS)

La aplicación que marca claramente la diferencia entre MAP y las demás redes ISO,

incluyendo TOP, es la Especificación de Mensajes de Manufactura, MMS. Este proto-

colo está especificado en la norma ISO 9506 y sus normas compañeras. MMS es un

sistema de mensajes, aceptado internacionalmente, para el intercambio de datos en

tiempo real e información de supervisión de control entre dos dispositivos en red o

Físico

Enlace

Red

Medio Físico

Transporte

Sesión

Presentación

Nivel de Aplicación

ACSE

ASE ASE ASE

Privado FTAM MMS(API) (API) (API)

Figura 6. El Nivel de Aplicaciones en MAP.

58

aplicaciones de computador. En esencia, con MMS se pueden accionar o detener re-

motamente dispositivos de manufactura.

VMD

Dominio 1

Capacidad1

Dominio 2

Dominio 3

Capacidad2

Función EjecutivaInvocaciones

de Programa

Figura 7. Esquema de un Dispositivo

de Manufactura Virtual (VMD).

El núcleo de MMS está compuesto por la definición de un dispositivo virtual de manu-

factura, VMD, y 84 servicios que sirven para manipular toda la información relativa a

este dispositivo. La especificación es extensa y, como es de esperarse, la norma es

muy técnica en sus definiciones. Aunque se ha definido una especificación más com-

pacta, llamada MicroMMS, la mayoría de los fabricantes prefieren proveer solo un

subconjunto de los 84 servicios según sus necesidades.

59

El dispositivo virtual consta de cuatro elementos básicos: una función ejecutiva, capa-

cidades, invocaciones de programas y dominios:

• Una capacidad es una descripción que provee el fabricante, en forma cadena de

caracteres, para identificar los recursos de su maquina: un controlador, por ejem-

plo, puede estar conectado a varias máquinas herramientas y por tanto tener varias

capacidades.

• Los dominios son recursos necesarios para ejecutar la función especifica: memoria,

disco, etc.

• Las invocaciones de programa son conjuntos de elementos, instrucciones o infor-

mación que coordinan las actividades a realizar para completar la función.

Al sofisticado VMD se le suma otro objeto; el Event Object Manager (EOM), cuya

función es la de coordinar toda la comunicación entre los diversos interesados, usua-

rios locales y en red, y el VMD. Por supuesto, estos objetos son imaginarios; abstrac-

ciones que representan dispositivos verdaderos o sus comportamientos.

Aunque MMS es independiente de la función realizada y del desarrollador del disposi-

tivo o aplicación, existen normas compañeras con la ISO 9056 que determinan carac-

terísticas específicas para robots, PLC’s y controladores numéricos. Ralph Ma-

ckiewicz, vicepresidente de Cisco, ha trabajado varios años con MMS y ha donado

60

gentilmente el documento que se incluye en el Anexo B, donde se describe con mayor

profundidad el protocolo MMS. Este documento es un aporte importante por la difi-

cultad de encontrar documentación cualitativa sobre este protocolo.

Pese a la gran utilidad de usar un modelo cliente-servidor en un proceso de manufactu-

ra, y a la normatividad existente, la utilización de MMS se ha visto limitada por dos

factures:

1. Los productos MMS son, en general, costosos. Muchos productos son desarrolla-

dos para computadores o redes de fabricantes específicos.

2. Muchos dispositivos de manufactura no poseen soporte para MMS debido a la

complejidad del protocolo: en general, solo los dispositivos más costosos y sofisti-

cados poseen MMS.

Aunque no se posea una red MAP, MMS puede ser implementada sobre otras redes,

por lo cual conviene tenerlo en cuenta en futuros desarrollos de dispositivos. Una po-

sibilidad flexible y eficaz es usar el protocolo TCP-IP, el más usado en las redes co-

merciales, para implementar servicios OSI: una implementación de este tipo se ha pro-

puesto como estándar para permitir una transición de Internet a una futura red OSI.

En el Anexo A se presentan los lineamientos RFC 10068, en los que se basan este tipo

8 N.A: RFC significa Request For Comments; es un documento de libre distribución destinado a definir normas

de Internet.

61

de desarrollos. Raymond Seng-Sim Cheah, Bo-Sung Lee y Long Lim9, de la Universi-

dad Tecnológica de Nanyang, Singapur, parten de ISODE para implementar MMS

sobre una internet. Una implementación de este tipo presenta todas las ventajas que

tiene una red de manufactura y evita la inversión costosa en tarjetas Token Bus.

9 CHEAH, LEE y LIM, Implementing Manufacturing Message Specification Services and Protocol Using ISO

Development Environment, IEEE TENCON’93 Beijing

MODELO DEL CONTROLADOR NUMÉRICO

En el proceso de diseño del software deseado hay dos pasos necesarios: el modela-

miento del sistema a controlar y la determinación de las necesidades del software. Am-

bos temas se relacionan demasiado por lo que se decidió estudiarlos de manera parale-

la.

El modelo de control planteado por Michel Moreaux10 de la École Polytechnique Fe-

derale de Lausanne11 presenta varias características a tener en cuenta:

1. Se identifica el control como un problema con requerimientos en tiempo real, lo

cual obliga a considerar el sincronismo por encima de la respuesta en tiempo.

2. Se identifica una jerarquía en las operaciones que se deben cumplir.

10 Michael Moreaux, A CNC model well-suited for the requirements of CNC software construction environment.

Proceedings of CompEuro 93, Paris, Francia, 1993.

11 http://litsun.epfl.ch

63

3. Se divide la responsabilidad del control en dos unidades: una consola, responsable

de interactuar con el operario, y una unidad ejecutiva responsable de controlar el

proceso acorde con lo dictado por la consola.

Se considerarán, entonces, dos entidades distintas: el controlador numérico propia-

mente dicho y una consola desde la cual el operario controla el proceso. Esta división

nos permite independizar el problema del control por parte del operario del controla-

dor numérico que se posee: de lograrse construir una consola genérica, el operario no

tendría que preocuparse por el equipo específico que esta manejando y tampoco se re-

queriría conocer los detalles de implementación del controlador.

3.1 LA UNIDAD DE EJECUCIÓN

Los requisitos básicos de la unidad de ejecución son:

• Traducir los programas de código ISO CNC a un código sencillo de enviar al co-rrector de la herramienta.

• Corregir la trayectoria de la herramienta seleccionada.

• Administrar la secuencia de las distintas operaciones de mecanizado.

• Controlar los dispositivos auxiliares: lubricación, cambiador de herramientas, etc.

64

• Generar la trayectoria.

• Controlar los ejes.

• Comunicarse con la red, si ésta existe.

Como se ve, la unidad de ejecución es la de mayor responsabilidad durante el proceso:

esta responsabilidad es aún mayor cuando se opera remotamente o de manera autó-

noma ya que la consola, y a veces el operario, desaparece.

En el modelo de Moreaux, el controlador numérico está compuesto por una jerarquía

de Máquinas de Estado Finito: es decir, células especializadas con funciones específi-

cas cuyo estado se puede determinar con un número finito de variables. Los niveles

más altos de esta jerarquía están constituidos por los sistemas de comunicación, y los

niveles más bajos por las unidades de operación.

65

Aquí se pretende distribuir inteligentemente los controles de tal forma que cada unidad

tenga lo exclusivamente necesario para cumplir su función. Al mantener los controles

muy sencillos se obtiene una disminución en los costos de los equipos y se le da mayor

flexibilidad al sistema.

3.2 LA UNIDAD CONSOLA

Los requisitos básicos de la consola genérica son:

Comandos

Máquina de Estado

Finito

Unidad FuncionalCorr.Herr.

Máquina de Estado

Finito

Unidad FuncionalCamb.Her

Máquina de Estado

Finito

Unidad Funcional

Eje X

Unidad FuncionalTrad. ISO

Unidad Consola

Nivel Superior

(Raíz)

Niveles Inferiores (hojas)

UnidadesFuncionales

Figura 8. Modelo Moreaux de un Controlador Numérico.

66

• Desplegar los parámetros de maquinado.

• Crear, desplegar y editar programas de partes escritos en código ISO CNC.

• Proveer herramientas gráficas para la programación de las partes.

• Almacenar programas de partes y descripciones de herramientas.

• Activar los elementos auxiliares y proveer información de su estado.

• Ajustar los parámetros de los controladores de los ejes.

• Cargar los programas para su ejecución.

• Almacenar y desplegar información estadística para su uso posterior.

• Realizar procedimientos de chequeo.

Se observa que entre los requerimientos que le hacemos a la consola no está el de pro-

veer utilidades CAD: usualmente la consola está en un ambiente de taller que no es

apropiado para diseñar.

Pese a no tener funciones tan exigentes como la unidad ejecutiva, la unidad de consola

marca la diferencia en el momento de vender la máquina. La sencillez de uso y una ex-

celente presentación son las características más importantes a tener en cuenta en esta

unidad.

En realidad hay dos tipos de consolas que se deben distinguir: la consola integrada al

controlador, y la consola que opera en una unidad independiente. Esta distinción es

importante porque ambas unidades están sometidas a condiciones distintas e interac-

tuan de manera diferente con el operario: las consolas integradas al controlador son,

usualmente, más primitivas en cuanto a sus servicios gráficos. Las unidades indepen-

67

dientes son, comúnmente, PC´s o terminales adaptadas para que funcionen con el

controlador numérico. Las unidades modernas basadas en PCs vienen dotadas con un

mouse: tal dispositivo no es el más adecuado para un ambiente de taller por lo que

siempre se deben ofrecer alternativas como teclados o pantallas touchscreen.

La división entre unidad ejecutiva y consola surge naturalmente ya que ambas unida-

des frecuentemente están divididas físicamente. La consola también tiene divisiones,

pero éstas son mucho mas sutiles: a nivel funcional sabemos que el acto de editar una

programa es muy distinto al de ejecutarlo. Tenemos, por tanto, dos unidades funciona-

les distintas, un editor y un controlador en software, que deben interactuar de manera

cercana.

PROGRAMACIÓN DE UNA MÁQUINA HERRAMIENTA CNC

4.1 CONTROLES

Los controles son el corazón de la máquina herramienta: entre más fácil sea controlar

la máquina mas fácil será ponerla a producir.

Un área que puede causar confusión, al seleccionar una MHCN, es la velocidad de la

máquina. Es posible alcanzar movimientos rápidos de hasta 0.5 m/s, sin embargo, no

todas las partes lo requieren: el ciclo de producción se beneficiará si el proceso apro-

vecha los movimientos de alta velocidad la mitad o más del tiempo.

Las relaciones de contorneado pueden ser de hasta de hasta 1,000 bloques por segun-

do. Es posible, sin embargo, que algunas máquinas anuncien altas velocidades de

contorneado y no las puedan alcanzar: en una máquina que este conectada con DNC a

una razón de 38,400 baudios, realizando movimientos sencillos X y Y, la velocidad de

comunicación limita la máquina a 250 bloques/segundo. Si el sistema usa WindowsTM,

69

o algún otro ambiente gráfico, la velocidad será aún menor, debido a la existencia de

otras tareas que ocupan al computador. Es de notar que el aumento de velocidad y las

mejoras en los sistemas operativos actuales tienden a reducir este efecto, pero las re-

comendaciones de los fabricantes siguen orientadas a dedicar un computador por con-

trolador CNC. Los bajos precios de los computadores justifican esta decisión.

La mayoría de las máquinas CNC comerciales usan controladores compatibles con Fa-

nucTM: las máquinas más costosas usan los controladores Fanuc originales pero, debi-

do a los altos costos de esta marca, los fabricantes han optado por producir sus pro-

pios controladores y hacerlos compatibles.

Aunque la mayoría de los controladores usan códigos G para ejecutar los movimientos

de la máquina, hay programas de mayor nivel que facilitan la carga de programación:

los programas CAM son capaces de generar movimientos y superficies complejas,

mientras otros programas usan ambientes gráficos con iconos y preguntas. Si el siste-

ma es propio del centro de mecanizado el operario deberá aprender varios sistemas

distintos, dependiendo de las máquinas que estén en uso. Existen códigos gráficos

normalizados para los centros de control numérico convencionales pero son de poca

utilidad en los ambientes de programación.

70

4.2 INSTRUCCIONES OPERACIONALES

El reporte técnico TR-6132 de la ISO, relativo al protocolo de comunicaciones de un

controlador numérico. plantea un procesador de control y diversos dispositivos que se

interconectan con él.

Teletipo

Estación Oper.

Memoria/Disco

Cinta Mag.

CRT/Teclado

Cinta Perf.

Procesador de Control

HostDNC

Comm.(Modem)

Figura 9. Ejemplo de una Configuración

de Hardware Generalizada.

Tal controlador debe soportar una serie de comandos para que se pueda cumplir el

trabajo que desea el operador. Estos comandos se envían en un programa de control

numérico que se compone de la información del programa para la máquina, es decir

71

los códigos G, y de instrucciones operativas. Las instrucciones operativas se separan

de la información del programa por los paréntesis que las encierran. Estos paréntesis,

de hecho, actúan como señales de encendido y apagado de una modalidad específica

de control.

Las instrucciones operativas son comandos de bajo nivel, en forma mnemónica, que

definen operaciones internas para controlar el procesamiento de la información o con-

figurar el controlador. Las instrucciones operativas no bastan, por sí solas, para gene-

rar acciones en la máquina de control numérico.

Las instrucciones operacionales están organizadas en una sencilla jerarquía de acuerdo

a su funcionalidad.

Comandos de Edición

Comandos para Manejo de Archivos

Comandos Universales

Selector de Modalidad

Comandos de Control de

Máquina

Figura 10. Jerarquía de las Instrucciones Operativas

72

Como se observa en la figura, no habrá acceso a ningún comando operativo hasta

tanto no se seleccione esa modalidad específica. Para seleccionar alguna modalidad

ésta debe activarse directamente en el controlador y usarse con el teclado, o deben

enviarse los comandos entre paréntesis junto con el resto del programa.

Los comandos, llamados mnemónicos por su similaridad al lenguaje de máquina de un

computador, permiten la manipulación de los datos almacenados y de los dispositivos

secundarios. A continuación se presentan los significados de algunos mnemónicos co-

munes, aclarándose que el fabricante esta en libertad de añadir o retirar algunas in-

trucciones por lo cual se debe consultar los comandos y sus parámetros en el manual

del equipo.

73

12 En la tabla no se presentan los parámetros de las instrucciones ni se describe en detalle su funcionamiento, se

recomienda, para este efecto, consultar ISO TR 6132 y las norma complementarias.

Tabla 3.

Instrucciones Operacionales Comunes12

Comandos Universales

EDT Subnivel de Edición

FIL Subnivel de Manipulación de Archivos

MCH Subnivel de Máquina

END Finalizar Modalidades

DIS Despliegue

Modalidad de Manipulación de Archivos

DEL Eliminar Líneas

FND Encontrar Texto

INS Insertar Texto

LST Listar Líneas

RPL Reemplazar

Modalidad de Dispositivo

AMn Memoria Auxiliar

DS Almacenamiento de Disco

KB Teclado de Consola

MT Cinta Magnética

PP Unidad de Ponchado

PR Lectora de Perforado

74

4.3 INFORMACIÓN DE PROGRAMACIÓN

4.3.1 Información Geométrica

La mayoría de los fabricantes ofrecen programación en códigos G, un lenguaje que

usa códigos predefinidos para controlar los movimientos de la máquina. Los códigos

G estan normalizados por la ISO-EIA en la norma ISO 6983 “Numerical control of

Machines”. Se debe notar que la mayoría de fabricantes americanos tratan de cumplir

esta norma pero hacen variaciones y modificaciones de acuerdo a las características

propias de su producto.

Los códigos G son usados para especificar movimiento, caso en que se denominan

códigos G de eventos, o para realizar funciones en el controlador CNC, caso en el que

se llaman códigos G preparatorios. Existen códigos G para eventos especiales que de-

notan operaciones más complejas como roscados.

Algunos controladores recientes toman medidas de anticipación al cambiar las condi-

ciones de operación. Un ejemplo típico es disminuir la velocidad de mecanizado cuan-

do se va a dar un cambio brusco de sección, de esta manera se provee un mejor termi-

nado en la pieza.

75

En la tabla 4 se presentan los códigos G más comúnmente usados.

Tabla 4.

Códigos G Comúnmente Usados

Código Descripción Tipo de

Código

G00 Movimiento Lineal Rápido. Evento

G01 Movimiento Lineal a una razón definida. Evento

G02 Movimiento en arco en sentido horario. Evento

G03 Movimiento en arco en sentido antihorario. Evento

G41/42 Valores de longitud y diámetro de la herra-mienta.

Preparación

G43 Selección de longitud de la herramienta. Preparación

G53-G59 Valores de fijación del material. Preparación

G70 Sistema ingles (medidas en pulgadas). Preparación

G71 Sistema Internacional. Preparación

G90 Posicionamiento absoluto (respecto a un ceroconocido).

Preparación

G91 Posicionamiento incremental desde el últimopunto programado.

Preparación

Por supuesto, no basta con especificar la operación que se desea para que ésta sea

realizada; se requieren parámetros que incluyen longitudes o posiciones. Para denotar

76

estos parámetros los comandos G, y algunos otros comandos que se describirán mas

adelante, usan palabras y registros.

Las palabras constan de un índice que el controlador identifica (X, Y, Z, Y, J, etc.) se-

guido de un valor. Por ejemplo, la palabra Y2.45 le indicaría al controlador que debe

desplazarse a la posición 2.45 sobre el eje Y. Además del rango que poseen todas las

palabras, se debe considerar el formato y si se usa, o no, el punto decimal, lo cual de-

pende del sistema de unidades seleccionado anteriormente.

Los registros son valores almacenados en el controlador con anterioridad. Usualmente

se designan usando una letra distinta a la de las palabras válidas (H, D, etc.) y un nú-

mero entre 0 y 99. Los registros son usados solo por algunos códigos G y son muy

útiles para almacenar propiedades de las herramientas.

4.3.2 Información Tecnológica

Además de los comandos que realizan las operaciones de mecanizado el integrador del

control, la persona que incluye el controlador en la máquina CNC, define códigos M

que se utilizan para realizar funciones diversas. La norma EIA original no especifica

códigos M, pero la norma ISO se mencionan algunos. En la tabla 5 se presentan algu-

nos códigos M comunes.

77

El comando M06, cambio de herramienta, algunas veces viene precedido por un co-

mando T que identifica la herramienta que se debe preparar. Las máquinas que cuentan

con cambiador automático de herramientas, ATC13, seguirán operando sin interrup-

ción, pero las que no lo tienen se retraen y detienen su funcionamiento para que el

operario cambie la herramienta y dé la señal de proseguir.

4.4 ESTRUCTURA GENERAL

13 ATC significa Automatic Tool Changer

Tabla 5.

Algunos Códigos M

Código Descripción

M02 / M30 Fin del Programa CNC.

M03 Encender husillo, sentido horario.

M04 Encender husillo, sentido antihorario.

M05 Apagar husillo.

M06 Cambio de herramientas.

M08 Abrir llave de refrigerante.

M09 Cerrar llave de refrigerante.

78

Los programas NC deben ser estructurados de tal forma que el programa funcione de

manera segura, confiable y consistente cada vez que se ejecute. Algunos controladores

requieren un comando % al comenzar el programa. El programa usualmente debe ini-

ciar con lo que se denomina un bloque de seguridad: este bloque debe incluir códigos

G que configuran la maquina en los modos de operación deseados. El bloque de segu-

ridad debe definir las unidades, o si se están usando coordenadas incrementales o abso-

lutas, también se deben tener en cuenta valores iniciales como la longitud de la herra-

mienta.

Muchos de los pasos del bloque de seguridad se repiten durante los cambios de he-

rramienta: apagar o prender el refrigerante y posicionar las piezas. Cuando se desea

seguir usando la misma herramienta para una operación distinta se usa un cambio nulo

de herramienta, es decir se omiten el comando M06 y los comandos que especifican la

herramienta. Esta acción tiene la virtud de permitir la continuación del programa NC

desde el punto de cambio de herramienta en caso de que alguna herramienta se rompa

y se deba comenzar a maquinar el vacío.

La mayoría de los controles almacenan el estado definido en el programa anterior y no

es necesario volver a programar todos los datos, esta facilidad, muy apreciada en la

época de las cintas perforadas, se denomina modalidad.

79

El siguiente paso es definir los movimientos deseados para fabricar la pieza. Las má-

quinas CNC solo pueden hacer dos tipos de movimientos: lineales y circulares. Las

formas más complicadas deberán componerse, necesariamente de secciones circulares

o rectas. Los movimientos lineales se realizan a dos velocidades distintas: una veloci-

dad alta, denominada movimiento rápido que se utiliza comúnmente para posicionar la

herramienta, y un movimiento a la velocidad predefinida durante el cual habrá desbaste

de material. El movimiento circular se refiere a cualquier movimiento que comprenda

desplazamiento sobre un arco a un radio dado. El movimiento circular también se divi-

de en dos: uno en el sentido de las manecillas del reloj y otro contrario al sentido de

las manecillas.

Después de terminar las operaciones, el final del programa debe apagar el refrigerante

y el husillo, y la herramienta debe regresar a su hogar. Usualmente se debe dar un co-

mando adicional, M02, para indicar el fin del programa.

Lógicamente, hay importantes diferencias entre los comandos que requiere una fresa-

dora, un torno, o un controlador numérico genérico: estas diferencias se reflejan en la

implementación misma del conjunto de instrucciones que puede recibir la máquina

CNC. El Anexo A resume los comandos básicos de las maquinas M3T del Centro Co-

lombo-Italiano en el Servicio Nacional de Aprendizaje, SENA.

80

4.5 POSTPROCESADORES Y CLDATA

Un problema que se enfrenta en la planta de hoy es la falta de normalización de los

formatos de control numérico. Si bien los códigos G se usan indistintamente en tornos

y fresadoras, estos no son iguales en todas las maquinas herramientas; más aún, el

software de distintas máquinas no es intercambiable por diferencias en las interfaces y

la representación interna de la información.

Las dificultades por interfaces entre los sistemas CAD/CAM y el equipo NC de la

planta frecuentemente comienzan en la etapa del postprocesador: el postprocesador es

software especial que se encarga de cambiar el formato de la salida de un programa, o

de un sistema computarizado NC, al formato exacto que requiere el sistema o el dis-

positivo máquina-herramienta.

El sistema que se usa para asistir el proceso numérico, usualmente un paquete CAM,

produce siempre un archivo CLDATA, es decir, un archivo de información cutter lo-

cation (CL) con los datos requeridos para definir la trayectoria y el movimiento de la

herramienta de corte.

La información CLDATA no incluye las características individuales y dinámicas de la

máquina herramienta que se va a utilizar, por lo que el archivo CL debe ser procesado

81

y convertido al formato específico del sistema particular; es decir, debe ser postproce-

sado. Lógicamente, sistemas distintos requerirán postprocesadores distintos, lo cual

quiere decir que entre mayor variedad de combinaciones máquina-herramienta haya en

la planta, mas postprocesadores se requerirán. Obtener post-procesadores puede ser

problemático: usualmente son costosos por la dificultad de su implementación y re-

quieren personal técnico para mantenerlos o brindarles soporte.

En un intento por solucionar algunos de estos problemas, se desarrolló el formato

normalizado de control numérico EIA RS-949 denominado Binary Cutter Location,

BCL. La idea original fue normalizar el formato CLDATA generado por procesadores

Automated Programmed Tool, APT, y usarlo como entrada común para máquinas he-

rramientas. Diversas instituciones de normalización, incluyendo DIN, ofrecen norma-

tividad de CLDATA, pero BCL tiene la virtud de no estar restringido a sistemas APT;

se puede usar además con programas CAD/CAM y lenguajes de programación NC que

generan archivos intermedios CL.

El precursor de este movimiento fue la compañía Rockwell International, que en 1974

poseía siete sistemas distintos, con 13 formatos de cinta y 23 postprocesadores. En

1975 se comenzó la unificación del formato de entrada a los postprocesadores, consis-

tente en un formato con palabras de 32 bits, y en 1980 se propuso este formato como

82

una norma oficial de la industria, aunque el documento final solo fue publicado en

1983 por la Electronic Industries Asociation, EIA.

El protocolo, en esencia, resulta de utilizar APT para generar código binario de 32

bits: como el código binario se compone de unos y ceros es independiente del código

alfanumérico de la máquina en que se procesa. La norma ISO no esta disponible aún

en Colombia y adquirirla implica pagar portes de nacionalización, además de los im-

puestos normales.

Las ventajas de BCL son:

• Elimina el costo y la dificultad de adquirir, corregir, y mantener un gran número de

postprocesadores.

• Soluciona los problemas de incompatibilidad del programa NC dando como resul-

tado portabilidad de programas entre máquinas herramientas.

Los sistemas de programación NC producen salidas en diversos formatos pero actual-

mente hay pocos vendedores de software CAD/CAM que soportan RS-494 como op-

ción de salida. Una solución para este problema es el desarrollo o adquisición por

parte del usuario de una utilidad de conversión CL.

La figura 11, a continuación. ilustra el proceso que se sigue tradicionalmente y el re-

sultante al usar BCL.

83

Un conversor CL da formato a los datos de rutas de mecanizado en el software exis-

tente para que sea compatible con el especificado por la norma RS-494. Como las co-

ordenadas se calculan en tiempo real en la máquina BCL, el conversor usará menos re-

cursos de procesamiento que el postprocesador convencional y producirá programas

más cortos.

post procesador

Programa para NC

CNC 1

Programa Fuente

Procesador NC

Información CL

post procesador

Programa para NC

CNC 2

post procesador

Programa para NC

CNC 3

(a) Postprocesadores Convencionales.

RS- 494 CNC 1

Programa Fuente

Procesador NC

Información CL

Utilidad de Conversión

BCL

Programa BCL para Máquinas

RS-494

RS-494 CNC 2

RS-494 CNC 3

(b) RS-494 BCL.

Figura 11. CLDATA Convencional vs. BCL.

84

Para los usuarios que no poseen máquinas compatibles con BCL no se justifica actuali-

zar la máquina sólo para usar BCL, por lo que también se consiguen unidades de pos-

tproceso de BCL para la máquina individual.

Gracias a la gran demanda de la industria aerospacial, el sistema BCL esta ampliamen-

te difundido en los Estados Unidos. Algunas empresas que lo soportan son: Cincinatti

Milacron, Allen Bradley, Automation Intelligence, y Justice Peterson & Associates,

además de algunas empresas de CAD/CAM. En Europa, en cambio, el sistema está

muy poco difundido y pocas empresas lo conocen.

DESARROLLOS ANTERIORES EN LA UNIVERSIDAD NACIONAL

5.1 PROTOTIPO DE UNA MESA POSICIONADORA

Durante los últimos años el Servicio Nacional de Aprendizaje, SENA, y el Departa-

mento de Ingeniería Mecánica de la Universidad Nacional (U. N.) han trabajado con-

juntamente en diversos proyectos de manufactura automatizada.

La experiencia entre las dos instituciones ha sido fructífera; en particular se ha cons-

truido una mesa posicionadora con sus controles electrónicos.

Aunque el proyecto ha sido un éxito en cuanto a la eficacia de la máquina, la mesa

posicionadora está lejos de poderse comercializar debido a los altos costos que com-

prenden los controladores usados, y a que se debe trabajar más en su eficiencia y con-

fiabilidad.

86

Se ha pretendido diseñar progresivamente un centro de mecanizado pero, como es

común en los proyectos de investigación, los objetivos no se han definido con preci-

sión; y éstos han ido evolucionando con el proyecto. El problema de los controladores,

en particular, ha sido tratado por dos proyectos de grado distintos.

En el primer proyecto de grado se diseñó y construyó, el hardware y software para

controlar la mesa posicionadora. Aunque el resultado fue exitoso, se han presentado

problemas por la dificultad de poner por escrito todas las experiencias obtenidas du-

rante el proceso investigativo. Otro inconveniente grave de este proyecto es que el

software solo sirve para el controlador para el cual fue diseñado y no hay posibilidades

de adaptarlo fácilmente a los controladores comerciales que se han adquirido con

posterioridad.

Figura 12. Mesa Posicionadora del Convenio SENA-UN.

87

En el proyecto de grado Selección y Prueba de Controlador y Manejador para los

Motores de Paso de la Mesa Posicionadora, se investigaron controladores comercia-

les que se acomodaran a las necesidades del proyecto. En este proyecto se optó por

usar productos de la compañía Superior Electric por ser la única con representación y

distribución de sus productos en Colombia. Desafortunadamente, el tiempo ha demos-

trado que esta opción no fue ni la más barata, ni la más adecuada para las necesidades

del proyecto.

5.2 Controladores Numéricos

Los controladores numéricos son el núcleo del centro de mecanizado, ya que ellos re-

ciben las instrucciones generadas por el usuario y controlan las herramientas por lo

que deben estudiarse con cuidado.

5.2.1 Controladores Superior Electric©©

Dos controladores de la empresa Superior Electric, con referencias SS-2000 y MX-

2000, se adquirieron en el Departamento de Ingeniería Mecánica con el propósito de

estudiar la funcionalidad de los controladores comerciales típicos.

88

Los dos controladores son similares en su funcionamiento y se diferencian en la capa-

cidad que tiene el MX-2000 para controlar más de un motor simultáneamente y en la

posibilidad de programar este último usando instrucciones de BASIC. El controlador

en sí es sencillo de describir: consta de una unidad central y una serie de interfaces pa-

ra motores, además de dos interfaces seriales (RS232 y RS485) para conectar a un pa-

nel de operador o un computador.

Figura 13. Controlador MX 2000.

Según el fabricante, el MX 2000 es un controlador autónomo basado en tecnología de

32 bits que permite un control económico de múltiples ejes con motores de paso o

servos. Ofrece salidas para ocho codificadores incremental, comunicaciones seriales,

entradas y salidas analógicas y digitales, switches BCD y expansión a OPTO-22.14

14 fuente: Superior Electric, http://www.industry.net/c/mn/03txf

89

La gran ventaja de estos controladores es que pueden operar independiente del com-

putador central, denominado host, una vez se ha cargado la información relevante.

Como se ve en la figura 14, también es posible hacer arreglos con controladores de la

misma marca y coordinarlos todos desde el mismo host.

Figura 14. Arreglo de Controladores

Superior Electric.

Cada controlador se identifica con un número de índice que se puede fijar en cada

controlador, por lo que cada controlador responderá únicamente a los comandos que

le corresponden. Para la programación del controlador se utiliza un puerto serial de

9600-38400 baudios, usando el protocolo de control Xon/Xoff.

90

Como se trata de un sistema comercial se desconoce la metodología de diseño y los

detalles de su operación por lo que se presta, para su estudio, al modelamiento tradi-

cional de caja negra.

La programación del controlador SS-2000 es sencilla y se aproxima a la norma EIA

RS274-D, es decir que usa los códigos G, y permite modos y parámetros de control,

códigos H y L. Para almacenamiento interno usa dos buffers de 255 caracteres, donde

llegan todos los comandos que se van a procesar con excepción de algunos comandos

H que son explícitamente de ejecución inmediata. El modelo MX 2000 también puede

usar comandos del lenguaje de programación BASIC con diversas funciones trigono-

métricas y expresiones booleanas para que el usuario defina sus propias unidades de

programación.

Durante el desarrollo de este proyecto, se puso a disposición del Departamento una

versión demo del paquete XYZPRO que funciona adecuadamente para dispositivos que

usan el puerto serial.

Este controlador es muy flexible pero tiene una desventaja grande, además de su cos-

to, y es que un puerto de 9600 baudios no es una velocidad alta para los estándares

actuales.

91

5.2.2 Controlador U.N.

El primer controlador electrónico de motores para la mesa posicionadora XY, fue di-

señado como parte de un proyecto de grado. Dentro de los objetivos de este proyecto

se tuvo el de mantener el sistema lo más económico posible, es así que se utilizó un

PC 8086, y los integrados para interface periférica de Intel (8049H). Este controlador

comprende un diseño compacto de control numérico directo: una tarjeta ISA que se

incorpora al computador y provee la interfaze entre los manipuladores de los motores

de paso y el computador. La figura 15 presenta los bloques considerados en el diseño

del controlador.

PC Tarjeta PPI Protocolo

Microcon- trolador

Microcon- trolador

Microcon- trolador

Secuencia- dor

Secuencia- dor

Secuencia- dor

Manejador

Manejador

ManejadorMotor

1

Motor 2

Motor 3

Figura 15. Esquema de Funcionamiento del Controlador U. N.

92

Para controlar el flujo de datos se utilizó una interrupción y para proveer el transporte

de datos se usaron direcciones de acuerdo con las especificaciones de los integrados

usados.

Figura 16. Interrupción con el Protocolo

Traducido.

Se observa que el proceso de traducción esta tomando información muy similar a la

que comprende un formato CLDATA para convertirla en un nuevo protocolo que es

característico del controlador escogido. En este caso se habría podido prescindir de los

códigos G para enviar las instrucciones directamente al controlador.

93

Comunicación

Comunicación

Manejador del Motor

Ejecución

Traducción

Interfase Hombre-Máquina Disco

Motor

Interfase F ís ica

PC

Microcontrolador

Figura 17. Configuración Usada en el

Controlador U. N.

Una forma alternativa de ver el controlador numérico se observa en la figura 17. En

este esquema se evidencia la importancia del protocolo escogido: el formato con que

se envían los datos al control numérico lleva de manera implícita los requerimientos de

los microcontroladores, y debe corresponder a las necesidades del usuario final. El

protocolo escogido por el grupo de trabajo en este caso consistió en paquetes com-

94

puestos por los datos de desplazamiento y velocidad en los tres motores. Estos datos

se conocen, en principio, en términos de unidades de unidades del sistema internacio-

nal, pero deben ser traducidas a unidades que entiendan los microcontroladores; es

decir, deben ser pasos o demoras del motor, y además se debe estipular el sentido de

giro. Esta conversión la hace el PC, no la tarjeta controladora, por lo que se realiza

antes de la comunicación.

La comunicación no requiere un sistema sofisticado para transportar la información: la

corrección de errores no es necesaria para este protocolo porque no hay distancia

apreciable entre los elementos y tampoco hay ruido considerable. De haberse escogido

usar los puertos seriales, se habría tenido que usar algún esquema para corregir los

errores inherentes a los sistemas de comunicaciones, y necesariamente se habría tenido

que aumentar la información transmitida con un código de verificación, disminuyendo

así la velocidad con que se alimenta el control numérico.

Después de leer el informe de grado, y observar las opciones de compilación, se dedu-

ce que las limitaciones de los computadores existentes durante la realización del pro-

yecto influyeron en el diseño del software de manera significativa. El computador que

se usa hoy en día en ese controlador es un 80286 con coprocesador numérico y moni-

tor monocromático, computador que es considerado obsoleto pero muy superior al

95

8086 en que se diseñó originalmente el software. Una leve mejora en rendimiento se

consigue recompilando el código fuente con el siguiente comando:

Directorio:\> tpc /B /$E- /$D- /$G+ cnc

El programa, cnc.pas, queda entonces optimizado para nuevas arquitecturas disponi-

bles: como mínimo un 80286 con coprocesador numérico.

Hay dos niveles de software que se deben considerar: Un nivel superior correspondien-

te a la interface hombre-máquina y la traducción de códigos G al formato usado en el

controlador, y un nivel básico encargado de enviar la información de velocidad y po-

sición a los controladores de los motores. El nivel superior se escribió en Turbo Pas-

cal con algunas rutinas en Assembler mientras que el nivel básico está conformado por

rutinas en lenguaje de máquina que están en una memoria Erasable Programable

Read Only Memory (EPROM) y se produjeron exclusivamente con lenguaje Assem-

bler.

Al pasar este programa de nivel superior por un conversor especial entre Pascal y C,

llamado p2c, sobresalió la existencia de código Assembler en prácticamente todas las

operaciones sobre la máquina de CN. El uso de Assembler, opción ofrecida por Turbo

Pascal, tiene como ventaja la sencillez para realizar operaciones de bajo nivel, y por

consiguiente una dramática mejora en la velocidad de ejecución. Desafortunadamente,

el código en assembler tiene efectos nocivos sobre la portabilidad del programa, es

96

decir, este programa no funcionará en arquitecturas distintas y se tendrían que hacer

modificaciones importantes para usarlo con un compilador distinto.

El controlador diseñado en la U. N. tiene grandes desventajas; no se controla el error

acumulado15 ni hay posibilidades de realimentación, pero también tiene grandes virtu-

des y cumple eficientemente la función para la cual fue diseñado; provee un manejo

eficiente de la mesa posicionadora. Se sale de los objetivos planteados un estudio de-

tallado de este controlador, pero se debe destacar que es el único sistema que posee-

mos que se puede desarmar, estudiar y probar sin restricciones.

Si comparamos el costo de este controlador con el costo de un equipo comercial de

similares características, podemos obtener una relación cercana a 1:10, por lo que se

puede concluir que vale la pena continuar esta línea de investigación.

15 Aparentemente el código para corregir el error mecánico no funciono adecuadamente y por eso el código co-

rrespondiente esta comentariado en el programa resultante.

EL SOFTWARE DE CONTROL

El sistema ideal debe resolver todas las necesidades de la unidad consola planteadas

por el grupo de trabajo de Michel Moreaux. Adicionalmente sería ideal proveer un

sistema genérico que permita la operación de todos los controladores numéricos dis-

ponibles y que soporte acceso desde una red de manufactura. No se tiene conocimien-

to de software con estas características, pero se sabe que de existir tendría un costo

elevado.

6.1 SELECCIÓN DEL AMBIENTE DE PROGRAMACIÓN

El mercado nacional tiene limitaciones en cuanto a los lenguajes de programación que

se pueden adquirir de acuerdo al Sistema Operativo sobre el cual correrá la aplicación.

En todo caso es importante tener en cuenta la portabilidad del programa, es decir, la

98

posibilidad de utilizar el mismo programa en otro sistema operativo, inclusive otra má-

quina, sin reescribirlo todo. Un lenguaje que permite una alta portabilidad es C: este

lenguaje viene con la mayoría de sistemas UNIX y está implementado en casi todos, si

no todos, los sistemas operativos. Una ventaja adicional del C es la posibilidad de ha-

cer manipulaciones de bajo nivel.

Una necesidad que surgió tempranamente fue la de usar una metodología orientada a

objetos para desarrollar el software. Hay diversos lenguajes que se prestan para traba-

jar con orientación a objetos, se destacan: SmallTalk, Simula, Modula, ADA y

LabView. Todos estos lenguajes son difíciles de conseguir localmente. Las implemen-

taciones modernas de los lenguajes tradicionales han optado por adoptar modificacio-

nes que faciliten este tipo de programación.

El lenguaje C, por si solo, no provee una estructura que permita usar OOP pero se han

desarrollado extensiones que permiten esta funcionalidad. Una de estas extensiones,

probablemente la más usada, es C++. Bjarne Stoustrup16 de los laboratorios AT&T

Bell desarrollo el lenguaje C++ con el objetivo de proveer un C mejor que el C. El re-

sultado final es un lenguaje en el que se puede usar código ANSI C y adicionalmente

se pueden definir y usar objetos.

16 STROUSTRUP BJARNE, The C++ Programming Language, Ed. Addison Wesley, Segunda Edición

99

El lenguaje C++ se escogió para el prototipo de esta implementación por ser muy co-

mún y por la posibilidad de seguir usando el código C indistintamente.

El sistema operativo más adecuado para desarrollar este tipo de aplicaciones es UNIX:

su ambiente gráfico permite portabilidad entre máquinas distintas, es multitarea, mul-

tiusuario, y además es posible conseguir implementaciones públicas de MicroMMS y la

suite de protocolos OSI. En el mundo UNIX no sólo hay muchos programas gratuitos

sino que el sistema operativo mismo se puede conseguir sin costo alguno.

Pese a las enormes ventajas que tiene UNIX, en nuestro medio el sistema operativo

más usado es MS-Windows y es poco viable, comercialmente, desarrollar el software

en un sistema distinto. Actualmente, solo Windows NT Workstation tiene una estabili-

dad suficiente para el trabajo continuo en una fábrica.

Visual Basic, otra herramienta que se estudió demostró ser mas fácil de manejar, pero

no proveía las opciones de control a bajo nivel que se requerían. Para efectos de la

implementación prototipo, se utilizó Visual C++, una implementación de C++ de Mi-

crosoft que provee bibliotecas especializadas (MFC) para el desarrollo de aplicaciones

gráficas que se planearon para permitir el acceso a 32 bits de los microprocesadores

actuales.

Con la definición del sistema operativo y el lenguaje de programación queda definido

un entorno de programación particular; se considera que en este ambiente se tienen

100

todas las facilidades, de alto y de bajo nivel, para realizar el desarrollo deseado de tal

forma que no es necesario recurrir a herramientas adicionales. No se descarta, sin em-

bargo, que sea deseable combinar el programa con otra utilidad escrita en Visual Ba-

sic.

6.2 DISEÑO DEL SOFTWARE

Claramente el problema de diseñar un software de control numérico requiere conocer

las necesidades del usuario final: la solución adecuada debe proveer la flexibilidad su-

ficiente para permitir que el software evolucione con las necesidades del cliente.

El software a diseñar debe soportar DNC, pero ante todo su estructura debe permitir

la implementación de las nuevas tecnologías que se han mencionado. Este problema

particular requiere, entonces, proporcionar un modelo de tamaño variable que esté en

capacidad de evolucionar de acuerdo a las necesidades del mercado.

La metodología seguida consistió en mantener el prototipo lo más sencillo posible para

después añadirle opciones más avanzadas. Esta metodología estuvo acorde con las ne-

cesidades actuales del Departamento de Mecánica ya que no se cuenta con una red de

manufactura en la cual se puedan realizar pruebas. El camino para la inclusión de una

101

red de este tipo, sin embargo, quedó abierto porque se obtuvieron algunos progra-

mas17 de libre distribución, y se reportaron al exterior los errores que se presentaron al

ponerlas a funcionar en algunas estaciones UNIX de la universidad.

6.2.1 Ventajas de la Programación Orientada a Objetos

La programación orientada a objetos (Object Oriented Programming, OOP), también

denominada programación por simulación, parte de definir unidades con identidad y

funciones propias llamadas objetos, y expresar las interacciones entre estos objetos en

el programa. La programación orientada a objetos se dio a conocer en el desarrollo de

ambientes gráficos, como el de Machintosh* , en que se modelan los elementos de

acuerdo a su función: carpetas, escritorios, canecas, etc...

El concepto de objeto es intuitivo y se presenta naturalmente en el problema estudia-

do: en esencia todos los bloques dentro de cada diagrama de este documento se pue-

den considerar objetos.

La ventaja al usar OOP radica no sólo en facilitar la interacción con el hombre en el

ambiente gráfico; también se mejora el mantenimiento del programa ya que es más

17 ISODE y MicroMMS se mencionaron en el cápitulo de Redes de Manufactura.

* Machintosh es una marca registrada de Apple Computer.

102

sencillo reparar, o actualizar, el código correspondiente a un elemento identificable y

no el conjunto de procedimientos resultantes en la programación tradicional.

Las herramientas básicas, ofrecidas por C++, que se usaron para obtener el modelo

deseado fueron la modularidad y la abstracción de la información

La modularidad consiste en la posibilidad de escribir toda la información relacionada

en una unidad independiente dentro del programa: se puede tener código para funcio-

nes relacionadas sin mezclarlo con el resto del programa. Esta característica se usó al

escribir la implementación de los dispositivos de manufactura en un archivo indepen-

diente: en el futuro, un implementador de dispositivos nuevos sabrá que en este archi-

vo encontrará toda la información que necesita y no la buscará desde el principio hasta

el final del programa.

La abstracción de la información se refiere a la posibilidad de escribir funciones que se

pueden usar en el resto del programa sin necesidad de describir los detalles internos de

la función: de esta manera se pueden hacer cambios sobre la función sin necesidad de

modificar todo el programa. C++ permite, adicionalmente, sobrecargar las funciones

de tal forma que si se necesita usar la una función para manipular información distinta

a la de otra función ya definida, el programa sabrá que función ejecutar de acuerdo a

los parámetros que se envíen. Si, por ejemplo, se usa una función para enviar números

a la pantalla y otra para enviar caracteres, basta ponerle el mismo nombre a las dos y el

103

computador decide que función usa de acuerdo a los valores que se den en tiempo de

ejecución.

6.2.2 Estructura del Programa

La metodología de Booch18 es una de las estrategias preferidas para diseñar software

con un enfoque orientado a objetos: aunque esta metodología no se siguió de manera

estricta se siguieron los lineamientos generales.

La primera etapa consistió en la identificación de los objetos presentes en el problema:

• El dispositivo de manufactura: debe recibir la información y procesarla, en reali-

dad se trabajará con un controlador de dispositivos. Hay una estrecha relación con

el VMD definido por MMS.

• El Controlador de Eventos: Es el encargado de coordinar las actividades de ma-

nufactura de acuerdo a los mensajes que le envían otros objetos.

• La consola: la unidad que interactúa directamente con el operario, comprende un

ambiente gráfico agradable y herramientas básicas de configuración.

18 Grady Booch, Object-oriented development, IEEE Transactions on Software Engineering, SE-12(2):211-221.

1986

104

Estos tres objetos constituyen el núcleo del software considerado: hay otros objetos

derivados del ambiente gráfico que se pueden considerar partes de la consola, como el

editor de codigo CNC, los botones de control y los cuadros de diálogo.

6.2.3 Consideraciones Técnicas

De los tres objetos considerados el usuario sólo necesita conocer la unidad consola: en

la medida de lo posible no se debe reportar el manejo interno a menos que ocurra un

error de ejecución. Los otros dos objetos, el controlador del dispositivo, y el controla-

dor de eventos son responsables del manejo en tiempo real del dispositivo, y pese a ser

transparentes para el usuario deben ser partes muy robustas.

Debido a las debilidades inherentes a Windows, y la mayoría de los sistemas operati-

vos, siempre existe la posibilidad de algún error en tiempo de ejecución, por este moti-

vo se prefirió proveer una consola muy primitiva y dejar la edición de código CNC a

editor especializados. Al independizar estas funciones mejora la confiabilidad porque

las acciones sobre el editor no afectarán la ejecución del proceso.

105

6.3 EL CONTROLADOR DE DISPOSITIVOS

De los dos dispositivos que se podían diseñar, un dispositivo serial para el controlador

MX-2000 y un controlador para el controlador U.N., se escogió escribir un controla-

dor serial genérico que sirva para controlar el MX-2000. Esta decisión se tomó por la

dificultad de rediseñar el software del controlador U.N. y por la poca normalización

que se manejó en el software de ese proyecto. Al escribir un software para el puerto

serial se cubre una variedad de dispositivos comerciales que incluye el MX-2000.

Un archivo de encabezado es un archivo que contiene la descripción del módulo pero

no tiene los detalles del codigo usado: es lo único que requiere saber un futuro usuario

del objeto. El encabezado del módulo de control por el puerto serial se presenta a

continuación (Figura 18). Se debe notar que, por su extensión, no se incluye el listado

completo del programa pero el código fuente se incluye en el disquete que acompaña

esta documentación.

106

// comdev.h : header file// Código estandar MS#define WIN31 // this is a Windows 3.1 application#define USECOMM // yes, we need the COMM API

#include <windows.h>#include <string.h>

#define ASCII_BEL 0x07 //Algunas definiciones utiles#define ASCII_BS 0x08#define ASCII_LF 0x0A#define ASCII_CR 0x0D#define ASCII_XON 0x11#define ASCII_XOFF 0x13/////////////////////////////////////////////////////////////////////////////// CComDev window

class CComDev : public CWnd{friend class CPadView; //Se declara la vista como clase amiga del dispositivo// Constructionpublic:

CComDev();

// Attributesprotected:

LPSTR Comm,BaudRate,Parity,DataBits,StopBits; // Información privadaint idComDev;DCB settings;

// Operationsprotected:

void SetDCB(); //Prepara la estructura DCB requerida para la configuración

// Implementationpublic:

void CCommDev(); //Inicia los valores del controladorvoid SetBaud(LPSTR); //Las funciones Set* se proveen como referenciavoid SetParity(LPSTR); //para comunicarse con otros objetosvoid SetData(LPSTR);void SetStop(LPSTR);void Open(); //Abre y configura el puerto de Comunicacionesvoid Close(); //Cierra el puerto de Comunicacionesvoid Write(LPSTR); //Escribe una linea en el puerto de Com.virtual ~CComDev(); //Cierra el puerto antes de salir

// Generated message map functionsprotected:

//{{AFX_MSG(CComDev)// NOTE - the ClassWizard will add and remove member functions here.

//}}AFX_MSGDECLARE_MESSAGE_MAP()

};

/////////////////////////////////////////////////////////////////////////////Figura 18. Listado de ComDev.h.

107

El dispositivo ComDev tiene que cumplir una serie de funciones esenciales:

• Debe almacenar el estado del dispositivo por medio de una estructura privada lla-

mada el Data Control Block, DCB. Esta estructura almacena, en formato compri-

mido, los datos de conexión, es decir el puerto seleccionado, la velocidad de

transmisión, la paridad, el protocolo, etcétera.

• Debe preparar el dispositivo para recibir mensajes cuando sea necesario.

• Debe realizar la transmisión, garantizando la correcta retransmisión en caso de

errores.

• Debe cerrar el dispositivo cuando no se vaya a usar más, lo cual también implica

desocupar el buffer de memoria interna.

En la programación estructurada tradicional cada uno de estos pasos correspondería a

un procedimiento específico, en el caso de la programación orientada a objetos cada

proceso enunciado corresponde a una función miembro de la clase19 genérica

CComDev.

El creador de Visual C++ no consideró necesario proveer objetos para el manejo de

los puertos seriales: el soporte de este dispositivo se da a través del Windows Software

Development Kit (SDK), unas librerías en C que se deben incluir en el programa. El

19 En la terminología del C++ una clase es la definición de la variable que representa un objeto.

108

software habría funcionado igual si se hubieran usado estas funciones directamente pe-

ro se prefirió unir todas estas funciones bajo un mismo objeto, de esta manera se le da

una identidad al dispositivo y se abre la posibilidad de usar una característica especial

de la programación orientada a objetos: la herencia.

La herencia permite, por ejemplo, definir una clase VMD que tiene valores y funcio-

nes que la identifican, y adicionalmente se puede derivar una clase CommDev que he-

reda las propiedades de la clase VMD y añade o retira algunas propiedades. De la clase

CommDev, a su vez, se puede derivar una clase MX_2000 que contenga las caracte-

rísticas adicionales de un controlador MX-2000 y utilice las propiedades del dispositi-

vo serial utilizando el código ya probado.

Esta metodología de diseño ahorra mucho tiempo a futuros implementadores porque

no tienen necesidad de rediseñar el código y sus adiciones correrán automáticamente.

Si se desea, por ejemplo, crear una clase ContUN para el controlador U.N. se puede

usar la clase VMD para derivar la nueva clase y se tendrá compatibilidad con varias

funciones ya escritas.

Otra ventaja de crear la clase CommDev fue la definición de una clase amiga para el

cuadro de diálogo de configuración. Una clase amiga es una clase que puede acceder

a los datos privados de una clase distinta. Ocultar la información es elegante y evita

109

accesos erróneos sobre variables restringidas pero en casos especiales, como el cambio

de configuración, es conveniente poder modificar datos privados de un objeto.

Figura 19. Cuadro de Diálogo para Configurar

el Puerto.

6.4 EL CONTROLADOR DE EVENTOS

La gran debilidad de OOP es el manejo en tiempo real: el enfoque de objetos no ga-

rantiza respuesta en un tiempo determinado. Windows maneja los procesos concurren-

tes dándoles tiempo cada vez que el programador envía una señal: la estrategia es en-

110

viar señales cada vez que se termine una labor predefinida. Se consideró que esta es-

trategia no era la adecuada para el problema estudiado porque implicaba darle la prio-

ridad a lo que hiciera el operario en la consola y no al proceso de transmisión.

En este punto, se optó por una solución primitiva pero práctica: mientras se transmite

no se puede hacer nada más. El microprocesador se dedica únicamente a realizar, lo

más eficazmente posible, la transmisión: de esta forma se consigue garantizar la

transmisión en tiempo real.

El controlador de eventos definido en MMS tiene sentido en cuanto hay varios usua-

rios, varios trabajos por realizar, o una red. El soporte de red MAP para Windows no

esta disponible y Windows sólo permite que un proceso a la vez acceda al dispositivo.

Ante éstas condiciones no es necesario implementar un controlador de eventos: con el

manejo interno de mensajes que provee el compilador de Visual C++ es suficiente. El

compilador de Visual C++ añade y retira el código de los mensajes automáticamente

cuando se usa el Class Wizard, una herramienta para organizar el programa

6.5 LA CONSOLA

Usualmente una consola provee una serie de comandos de control y un ambiente có-

modo para la manipulación de procesos que se desean transmitir. Aquí se debió tener

111

en cuenta las exigencias planteadas por el modelo Moreaux. Si bien se deseaba mante-

ner esta unidad muy sencilla, se implementaron las funciones básicas:

• Facilidades de carga y descarga de archivos externos CNC.

• Opciones para corregir, adicionar, o borrar partes del programa.

• Opción de cambiar la configuración del dispositivo

• Posilidad de acceder al resto del entorno y hacer intercambios de información con

otros programas.

En realidad la consola aprovecha los objetos disponibles en las Microsoft Foundation

Classes, MFC, del Visual C++ y tiene todas las funciones características del entorno

Windows: se pueden abrir varios documentos, cambiar el tipo de letra, imprimir, cor-

tar, pegar, etc. Cada opción es descrita en español cuando se va a seleccionar, y tam-

bién existe la alternativa de usar el teclado en vez del mouse.

112

6.6 FUNCIONAMIENTO DEL PROGRAMA

El programa se llamó DNCPad, ya que funciona similar a un editor de texto corriente

pero además ofrece acceso a un dispositivo de manufactura DNC. El manejo del dis-

positivo es transparente para el usuario, por lo que no se requiere una explicación de-

tallada del programa.

Figura 20. Imagen del Menu de Edición en la Aplicación.

113

El usuario final puede editar su propio programa DNC o cargarlo desde otra utilidad y

mandarlo al dispositivo de manufactura. En caso de tener problemas durante el proce-

so, es posible enviar sólo la parte del programa que faltó por ejecutar, ahorrándose así

tiempo valioso. El manejo del programa es bastante intuitivo por ser una aplicación de

Windows.

Figura 21. Imagen del Programa Final en el Ambiente Gráfico

de Windows 95™™.

CONCLUSIONES

Considerando la bibliografía estudiada, la manufactura automatizada en la Universidad

Nacional presenta un atraso tecnológico de por lo menos cinco años frente a la tecno-

logía actual. Existen diversas causas para este atraso, pero sobresalen la poca demanda

de la industria nacional y la escasa inversión del estado en la investigación tecnológica.

Por supuesto, la Universidad Nacional refleja la realidad del país y una de sus misiones

es generar profesionales que se adapten bien al entorno en que éste se desarrolla: para

el estado carece de sentido invertir en profesionales que no serán contratados. La tec-

nología avanza muy rápidamente y las empresas se limitan a esperar los nuevos adelan-

tos provenientes del exterior; como resultado no existe una demanda interna de ma-

quinaria que justifique un alto desarrollo en manufactura automatizada. Del estudio

expuesto en el numeral 1.2 se deduce que la comunidad académica no está en capaci-

dad de lograr avances tecnológicos importantes si no cuenta con el apoyo decidido del

sector privado, y en particular del sector metalmecánico.

115

Otro factor que ha afectado el desarrollo tecnológico de la manufactura automatizada

en la Universidad Nacional es la demora con que la información llega al país. Hoy está

disponible en el país mucha información reciente relativa a la manufactura automatiza-

da, que no era posible conseguir hace unos años, pero aún hay factores coyunturales

que frenan el acceso a la información. Los avances en redes de computadores, las ba-

ses de datos en CDROM y la necesaria normalización de los procesos industriales han

hecho que sea posible reducir la brecha tecnológica entre los países desarrollados y los

subdesarrollados, pero la tecnología más reciente siempre permanece en las industrias

y universidades extranjeras hasta que alcanza una madurez que garantiza su comercia-

lización.

La creación del postgrado en manufactura automatizada es un signo alentador ante la

perspectiva de colaborar en el desarrollo industrial del país. Si bien el país estará obli-

gado a comprar tecnología del exterior por mucho tiempo, más importante que adqui-

rirla es saberla manejar con inteligencia para solucionar eficientemente las necesidades

de la industria. El postgrado puede forjar una cultura de industria automatizada que el

país requiere.

Las redes de manufactura surgen como una solución novedosa a las dificultades de

comunicación propias de una planta. Si bien las redes industriales sólo se encontraban

en empresas como General Motors, la tendencia mundial es aplicar la tecnología de la

116

red internet a nivel interno, consolidándose el concepto de una intranet. Es de espe-

rarse que estas intranets lleguen a formar parte directa del proceso de manufactura si-

guiendo las normas que se han establecido para redes MAP y TOP.

Los desarrollos anteriores en la Universidad Nacional, concretamente la mesa posicio-

nadora y el controlador numérico, demuestran que es viable hacer construcciones fun-

cionales en la universidad y es de esperarse que se logren diseños competitivos si se

logra coordinar todos los esfuerzos con una sola metodología. Desafortunadamente

los esfuerzos de los años recientes no han tenido siempre la misma orientación y las

conclusiones de un proyecto particular no son aplicables a los demás. Es claro que el

diseño de un centro de mecanizado es un proyecto a largo plazo que requiere la con-

currencia de diversas ramas de la ingeniería, por lo que la adopción de normas y una

adecuada documentación de cada subproyecto son las claves fundamentales del éxito.

Si bien las normas ISO no delimitan el proceso de diseño, dan unos requerimientos

básicos que deben tenerse en cuenta. Por ejemplo: la normatividad de los lenguajes

ISO-CNC, también denominados códigos G, se debió gobernar el desarrollo el contro-

lador numérico U.N., como el protocolo en que se almacena la información no es

acorde a la norma, los programas escritos para fabricar piezas con este controlador no

sirven para la máquina industrial convencional.

117

En general, los ambientes gráficos tienen una serie de ventajas en cuanto a flexibilidad

ya que permiten una interacción cercana entre todas las aplicaciones, de allí la tenden-

cia a preferirlos, pero también tienen un efecto nocivo sobre el rendimiento general del

equipo ya que exigen más recursos, y especialmente más tiempo de ejecución. Aunque

el costo de los equipos ha estado disminuyendo dramáticamente en los últimos años,

se debe tener cuidado en garantizar que el equipo y el sistema operativo puedan con-

trolar los procesos asignados en tiempo real. En el caso de Windows, la opción más

práctica es dedicar todo el tiempo del microprocesador a realizar los trabajos críticos,

en el caso de UNIX se puede usar el soporte de procesamiento concurrente para brin-

dar una solución más elegante.

La programación orientada a objetos, OOP, se plantea como la metodología más ade-

cuada para obtener diseños portables y fáciles de mantener. Se debe notar, sin embar-

go, que el manejo de funciones de bajo nivel y los procesos en tiempo real requieren

un tratamiento especial en tales ambientes. C++ brindó facilidades para programar

funciones de bajo nivel.

Al diseñar software de control numérico es necesario tener en cuenta la posibilidad de

hacer mejoras o modificaciones al software ya que la tecnología cambia rápidamente.

El programa de control DNCPad puede ampliarse, en un futuro, para soportar DCN

sin hacer cambios excesivos, ya que el modelo propuesto le permite al diseñador del

118

dispositivo definir las funciones básicas de comunicaciones de su dispositivo sin tener

que preocuparse por la interacción con el usuario. El diseñador del dispositivo debe

limitarse a escribir el código que envía la línea con comandos CNC al controlador nu-

mérico donde será procesada.

El costo de un programa comercial para control numérico es elevado, y su costo au-

menta de acuerdo a los dispositivos que se soportan. En estos programas no es posible

añadir más dispositivos ni hacer mejoras a medida que la tecnología avanza porque el

código fuente no está disponible, por lo que se demuestran enormes beneficios al dise-

ñar software genérico para controladores numéricos y hacerlo disponible en el medio

académico.

Un requisito importante para el software de control numérico es la posibilidad de inte-

ractuar con la demás aplicaciones del ambiente gráfico. El programa que se construyó,

DNCPad, permite intercambios de información con el editor de programas CNC de

XYZPRO y con las demás aplicaciones disponibles comercialmente.

ANEXO A.

RFC 1006 ISO Transport Service on top of the TCP V. 3

Network Working Group Marshall T. Rose, Dwight E. CassRequest for Comments: RFC 1006 Northrop Research and Technology CenterObsoletes: RFC 983 May 1987

ISO Transport Service on top of the TCPVersion: 3

Status of this Memo

This memo specifies a standard for the Internet community. Hosts on the Internet that choose to im-plement ISO transport services on top of the TCP are expected to adopt and implement this standard.TCP port 102 is reserved for hosts which implement this standard. Distribution of this memo is un-limited.

This memo specifies version 3 of the protocol and supersedes [RFC983]. Changes between the proto-col as described in Request for Comments 983 and this memo are minor, but are unfortunately in-compatible.

1. INTRODUCTION AND PHILOSOPHY

The Internet community has a well-developed, mature set of transport and internetwork protocols(TCP/IP), which are quite successful in offering network and transport services to end-users. TheCCITT and the ISO have defined various session, presentation, and application recommendationswhich have been adopted by the international community and numerous vendors. To the largest ex-tent possible, it is desirable to offer these higher level directly in the ARPA Internet, without disrup-

120

ting existing facilities. This permits users to develop expertise with ISO and CCITT applicationswhich previously were not available in the ARPA Internet. It also permits a more graceful conver-gence and transition strategy from TCP/IP-based networks to ISO-based networks in the medium-andlong-term.There are two basic approaches which can be taken when "porting" an ISO or CCITT application to aTCP/IP environment. One approach is to port each individual application separately, developing lo-cal protocols on top of the TCP. Although this is useful in the short-term (since special-purpose in-terfaces to the TCP can be developed quickly), it lacks generality.

A second approach is based on the observation that both the ARPA Internet protocol suite and theISO protocol suite are both layered systems (though the former uses layering from a more pragmaticperspective). A key aspect of the layering principle is that of layer-independence. Although this sec-tion is redundant for most readers, a slight bit of background material is necessary to introduce thisconcept.

Externally, a layer is defined by two definitions:

• a service-offered definition, which describes the services provided by the layer and the interfaces itprovides to access those services; and,

• a service-required definitions, which describes the services used by the layer and the interfaces it

uses to access those services.

Collectively, all of the entities in the network which co-operate to provide the service are known asthe service-provider. Individually, each of these entities is known as a service-peer.

Internally, a layer is defined by one definition:

• a protocol definition, which describes the rules which each service-peer uses when communicatingwith other service-peers.

Putting all this together, the service-provider uses the protocol and services from the layer belowto offer the its service to the layer above. Protocol verification, for instance, deals with proving thatthis in fact happens (and is also a fertile field for many Ph.D. dissertations in computer science).

The concept of layer-independence quite simply is:

• IF one preserves the services offered by the service-provider • THEN the service-user is completely naive with respect to the protocol which the service-peers use

For the purposes of this memo, we will use the layer-independence to define a Transport Service Ac-cess Point (TSAP) which appears to be identical to the services and interfaces offered by theISO/CCITT TSAP (as defined in [ISO8072]), but we will in fact implement the ISO TP0 protocol ontop of TCP/IP (as defined in [RFC793,RFC791]), not on top of the the ISO/CCITT network protocol.Since the transport class 0 protocol is used over the TCP/IP connection, it achieves identical functio-nality as transport class 4. Hence, ISO/CCITT higher level layers (all session, presentation, andapplication entities) can operate fully without knowledge of the fact that they are running on a

121

TCP/IP internetwork.

2. MOTIVATION

In migrating from the use of TCP/IP to the ISO protocols, there are several strategies that one mightundertake. This memo was written with one particular strategy in mind.

The particular migration strategy which this memo uses is based on the notion of gatewaying betweenthe TCP/IP and ISO protocol suites at the transport layer. There are two strong arguments for thisapproach:

1. Experience teaches us that it takes just as long to get good implementations of the lower levelprotocols as it takes to get implementations of the higher level ones. In particular, it has been ob-served that there is still a lot of work being done at the ISO network and transport layers. As a re-sult, implementations of protocols above these layers are not being aggressively pursued. Thus,something must be done "now" to provide a medium in which the higher level protocols can bedeveloped. Since TCP/IP is mature, and essentially provides identical functionality, it is an idealmedium to support this development.

2. Implementation of gateways at the IP and ISO IP layers are probably not of general use in the

long term. In effect, this would require each Internet host to support both TP4 and TCP. As such,a better strategy is to implement a graceful migration path from TCP/IP to ISO protocols for theARPA Internet when the ISO protocols have matured sufficiently.

Both of these arguments indicate that gatewaying should occur at or above the transport layer serviceaccess point. Further, the first argument suggests that the best approach is to perform the gatewayingexactly AT the transport service access point to maximize the number of ISO layers which can be de-veloped.

NOTE: This memo does not intend to act as a migration or intercept document. It is intendedONLY to meet the needs discussed above. However, it would not be unexpected that theprotocol described in this memo might form part of an overall transition plan. The des-cription of such a plan however is COMPLETELY beyond the scope of this memo.

Finally, in general, building gateways between other layers in the TCP/IP and ISO protocol suites isproblematic, at best.

To summarize: the primary motivation for the standard described in this memo is to facilitate theprocess of gaining experience with higher-level ISO protocols (session, presentation, and applica-tion). The stability and maturity of TCP/IP are ideal forproviding solid transport services independentof actual implementation.

3. THE MODEL

122

The [ISO8072] standard describes the ISO transport service definition, henceforth called TP.

ASIDE: This memo references the ISO specifications rather than the CCITT recom-mendations. The differences between these parallel standards are quite small, and can beignored, with respect to this memo, without loss of generality. To provide the reader withthe relationships:

Transport service [ISO8072] [X.214]Transport protocol [ISO8073] [X.224]

Session protocol [ISO8327] [X.225]

The ISO transport service definition describes the services offered by the TS-provider (transport ser-vice) and the interfaces used to access those services. This memo focuses on how the ARPA Trans-mission Control Protocol (TCP) [RFC793] can be used to offer the services and provide the interfaces.

For expository purposes, the following abbreviations are used:

TS-peer a process which implements the protocol described by this memo

TS-user a process talking using the services of a TS-peer

TS-provider the black-box entity implementing the protocol described by this memo

For the purposes of this memo, which describes version 2 of the TSAP protocol, all aspects of[ISO8072] are supported with one exception:

Quality of Service parameters

In the spirit of CCITT, this is left "for further study". A future version of the protocol will most likelysupport the QOS parameters for TP by mapping these onto various TCP parameters.

+-----------+ +-----------+| TS-user | | TS-user |+-----------+ +-----------+ | | | TSAP interface TSAP interface | | [ISO8072] | | |+----------+ ISO Transport Services on the TCP +----------+| client |-----------------------------------------| server |+----------+ (this memo) +----------+ | | | TCP interface TCP interface | | [RFC793] | | |

123

The ISO standards do not specify the format of a session port (termed a TSAP ID). This memo man-dates the use of the GOSIP specification [GOSIP86] for the interpretation of this field. (Please refer toSection 5.2, entitled "UPPER LAYERS ADDRESSING".)

Finally, the ISO TSAP is fundamentally symmetric in behavior. There is no underlying client/servermodel. Instead of a server listening on a well-known port, when a connection is established, the TS-provider generates an INDICATION event which, presumably the TS-user catches and acts upon.Although this might be implemented by having a server "listen" by hanging on the INDICATIONevent, from the perspective of the ISO TSAP, all TS-users just sit around in the IDLE state until theyeither generate a REQUEST or accept an INDICATION.

4. THE PRIMITIVES

The protocol assumes that the TCP[RFC793] offers the following service primitives:

Events

connected - open succeeded (either ACTIVE or PASSIVE)connect fails - ACTIVE open faileddata ready - data can be read from the connectionerrored - the connection has errored and is now closedclosed - an orderly disconnection has started Actionslisten on port - PASSIVE open on the given portopen port - ACTIVE open to the given portread data - data is read from the connectionsend data - data is sent on the connectionclose - the connection is closed (pending data is sent)

This memo describes how to use these services to emulate the following service primitives, which arerequired by [ISO8073]:

Events

N-CONNECT.INDICATION - An NS-user (responder) is notified that connection establishment is in progress

N-CONNECT.CONFIRMATION - An NS-user (responder) is notified that the connection has been established

N-DATA.INDICATION - An NS-user is notified that data can be read from the connection

N-DISCONNECT.INDICATION - An NS-user is notified that the connection is closed

124

Actions

N-CONNECT.REQUEST - An NS-user (initiator) indicates that it wants to establish a connection

N-CONNECT.RESPONSE - An NS-user (responder) indicates that it will honor the request

N-DATA.REQUEST- An NS-user sends data

N-DISCONNECT.REQUEST - An NS-user indicates that the connection is to be closed

The protocol offers the following service primitives, as defined in [ISO8072], to the TS-user:

Events

T-CONNECT.INDICATION - a TS-user (responder) is notified that connection establishment is in progress

T-CONNECT.CONFIRMATION - a TS-user (initiator) is notified that the connection has been established

T-DATA.INDICATION - a TS-user is notified that data can be read from the connection

T-EXPEDITED DATA.INDICATION - a TS-user is notified that "expedited" data can be read from the connection

T-DISCONNECT.INDICATION - a TS-user is notified that the connection is closed

Actions

T-CONNECT.REQUEST- a TS-user (initiator) indicates that it wants to establish a connection

T-CONNECT.RESPONSE- a TS-user (responder) indicates that it will honor the request

T-DATA.REQUEST- a TS-user sends data

T-EXPEDITED DATA.REQUEST- a TS-user sends "expedited" data

125

T-DISCONNECT.REQUEST - a TS-user indicates that the connection is to be closed

5. THE PROTOCOL

The protocol specified by this memo is identical to the protocol for ISO transport class 0, with the fo-llowing exceptions:

- for testing purposes, initial data may be exchanged during connection establishment

- for testing purposes, an expedited data service is supported

- for performance reasons, a much larger TSDU size is supported

- the network service used by the protocol is provided by the TCP

The ISO transport protocol exchanges information between peers in discrete units of information ca-lled transport protocol data units (TPDUs). The protocol defined in this memo encapsulates theseTPDUs in discrete units called TPKTs. The structure of these TPKTs and their relationship toTPDUs are discussed in the next section.

PRIMITIVES

The mapping between the TCP service primitives and the service primitives expected by transportclass 0 are quite straight-forward:

network service TCP

CONNECTION ESTABLISHMENT

N-CONNECT.REQUEST open completes

N-CONNECT.INDICATION listen (PASSIVE open) finishes

N-CONNECT.RESPONSE listen completes

N-CONNECT.CONFIRMATION open (ACTIVE open) finishes

DATA TRANSFER

N-DATA.REQUEST send data

N-DATA.INDICATION data ready followed by read data

CONNECTION RELEASE

N-DISCONNECT.REQUEST close

126

N-DISCONNECT.INDICATION connection closes or errors

Mapping parameters is also straight-forward:

network service TCP

CONNECTION RELEASE

Called address server's IP address (4 octets)

Calling address client's IP address (4 octets)

all others ignored

DATA TRANSFER

NS-user data (NSDU) data

CONNECTION RELEASE

all parameters ignored

CONNECTION ESTABLISHMENT

The elements of procedure used during connection establishment are identical to those presented in[ISO8073], with three exceptions.

In order to facilitate testing, the connection request and connection confirmation TPDUs may ex-change initial user data, using the user data fields of these TPDUs.

In order to experiment with expedited data services, the connection request and connection confirma-tion TPDUs may negotiate the use of expedited data transfer using the negotiation mechanism speci-fied in [ISO8073] is used (e.g., setting the "use of transport expedited data transfer service" bit in the"Additional Option Selection" variable part). The default is not to use the transport expedited datatransfer service.

In order to achieve good performance, the default TPDU size is 65531 octets, instead of 128 octets.In order to negotiate a smaller (standard) TPDU size, the negotiation mechanism specified in[ISO8073] is used (e.g., setting the desired bit in the "TPDU Size" variable part).

To perform an N-CONNECT.REQUEST action, the TS-peer performs an active open to the desiredIP address using TCP port 102. When the TCP signals either success or failure, this results in an N-CONNECT.INDICATION action.

127

To await an N-CONNECT.INDICATION event, a server listens on TCP port 102. When a clientsuccessfully connects to this port, the event occurs, and an implicit N-CONNECT.RESPONSE actionis performed.

NOTE: In most implementations, a single server will perpetually LISTEN on port 102, handingoff connections as they are made

DATA TRANSFER

The elements of procedure used during data transfer are identical to those presented in [ISO8073],with one exception: expedited data may be supported (if so negotiated during connection establish-ment) by sending a modified ED TPDU (described below). The TPDU is sent on the same TCP con-nection as all of the other TPDUs. This method, while not faithful to the spirit of [ISO8072], is true tothe letter of the specification.

To perform an N-DATA.REQUEST action, the TS-peer constructs the desired TPKT and uses theTCP send data primitive.

To trigger an N-DATA.INDICATION action, the TCP indicates that data is ready and a TPKT isread using the TCP read data primitive.

CONNECTION RELEASE

To perform an N-DISCONNECT.REQUEST action, the TS-peer simply closes the TCP connection.

If the TCP informs the TS-peer that the connection has been closed or has errored, this indicates anN-DISCONNECT.INDICATION event.

6. PACKET FORMAT

A fundamental difference between the TCP and the network service expected by TP0 is that the TCPmanages a continuous stream of octets, with no explicit boundaries. The TP0 expects information tobe sent and delivered in discrete objects termed network service data units (NSDUs). Although otherclasses of transport may combine more than one TPDU inside a single NSDU, transport class 0 doesnot use this facility. Hence, an NSDU is identical to a TPDU for the purposes of our discussion.

The protocol described by this memo uses a simple packetization scheme in order to delimit TPDUs.Each packet, termed a TPKT, is viewed as an object composed of an integral number of octets, of va-riable length.

NOTE: For the purposes of presentation, these objects are shown as being 4 octets (32 bits wide).This representation is an artifact of the style of this memo and should not be interpreted asrequiring that a TPKT be a multiple of 4 octets in length.

128

A TPKT consists of two parts: a packet-header and a TPDU. The format of the header is constantregardless of the type of packet. The format of the packet-header is as follows:

where:

vrsn 8 bits

This field is always 3 for the version of the protocol described in this memo.

packet length 16 bits (min=7, max=65535)

This field contains the length of entire packet in octets, including packet-header. This permits a ma-ximum TPDU size of 65531 octets. Based on the size of the data transfer (DT) TPDU, this permits amaximum TSDU size of 65524 octets.

The format of the TPDU is defined in [ISO8073]. Note that only TPDUs formatted for transport class0 are exchanged (different transport classes may use slightly different formats).

To support expedited data, a non-standard TPDU, for expedited data is permitted. The format usedfor the ED TPDU is nearly identical to the format for the normal data, DT, TPDU. The only diffe-rence is that the value used for the TPDU's code is ED, not DT:

After the credit field (which is always ZERO on output and ignored on input), there is one additionalfield prior to the user data.

TPDU-NR and EOT 8 bits

Bit 7 (the high-order bit, bit mask 1000 0000) indicates the end of a TSDU. All other bits should beZERO on output and ignored on input.

Note that the TP specification limits the size of an expedited transport service data unit (XSDU) to 16octets.

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| vrsn | reserved | packet length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| header length | code |credit |TPDU-NR and EOT| user data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ... | ... | ... | ... || ... | ... | ... | ... || ... | ... | ... | ... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

129

7. COMMENTS

Since the release of RFC983 in April of 1986, we have gained much experience in using ISO trans-port services on top of the TCP. In September of 1986, we introduced the use of version 2 of theprotocol, based mostly on comments from the community.

In January of 1987, we observed that the differences between version 2 of the protocol and the actualtransport class 0 definition were actually quite small. In retrospect, this realization took much longerthan it should have: TP0 is is meant to run over a reliable network service, e.g., X.25. The TCP canbe used to provide a service of this type, and, if no one complains too loudly, one could state that thismemo really just describes a method for encapsulating TPO inside of TCP!The changes in going from version 1 of the protocol to version 2 and then to version 3 are all relative-ly small. Initially, in describing version 1, we decided to use the TPDU formats from the ISO trans-port protocol. This naturally led to the evolution described above.

8. REFERENCES

[GOSIP86] The U.S. Government OSI User's Committee. "Government Open Systems Intercon-nection Procurement (GOSIP) Specification for Fiscal years 1987 and 1988."(December, 1986) [draft status]

[ISO8072] ISO. "International Standard 8072. Information Processing Systems -- Open SystemsInterconnection: Transport Service Definition." (June, 1984)

[ISO8073] ISO. "International Standard 8073. Information Processing Systems -- Open SystemsInterconnection: Transport Protocol Specification." (June, 1984)

[ISO8327] ISO. "International Standard 8327. Information Processing Systems -- Open SystemsInterconnection: Session Protocol Specification." (June, 1984)

[RFC791] Internet Protocol. Request for Comments 791 (MILSTD 1777)(September, 1981)

[RFC793] Transmission Control Protocol. Request for Comments 793 (MILSTD 1778)(September, 1981)

[RFC983] ISO Transport Services on Top of the TCP. Request for Comments 983 (April, 1986)

[X.214] CCITT. "Recommendation X.214. Transport Service Definitions for Open Systems In-terconnection (OSI) for CCITT Applications." (October, 1984)

[X.224] CCITT. "Recommendation X.224. Transport Protocol Specification for Open SystemsInterconnection (OSI) for CCITT Applications." (October, 1984)

[X.225] CCITT. "Recommendation X.225. Session Protocol Specification for Open SystemsInterconnection (OSI) for CCITT Applications." (October, 1984)

ANEXO B.

An Overview to the Manufacturing Message Specification

By:

Ralph Mackiewicz

(c) Copyright 1994. Ralph Mackiewicz. All Rights Reserved. Permission is hereby granted by theauthor for any individual or educational institution to copy and distribute this document freely provi-ded that 1) the document, or any copy thereof, is not used for commercial purposes, 2) is not copied,used or distributed by a commercial organization or company, and 3) that appropriate credit(including the copyright notice) be given in all reproductions and any other usage. Other rights maybe granted by written permission of the author.

DISCLAIMER: This document is provided "as is" without warranty of any kind. While the informa-tion contained herein is thought to be accurate at the time of publication, the author accepts no liabili-ty or responsibility of any kind for any use of this document.

OVERVIEW OF MMS:

What is MMS?

MMS (Manufacturing Message Specification) is an internationally standardized messaging system forexchanging real-time data and supervisory control information between networked devices and/orcomputer applications in a manner that is independent of: 1) the application function being perfor-med or 2) the developer of the device or application. MMS is an international standard(ISO 9506) that is developed and maintained by Technical Committee Number 184 (TC184), Indus-trial Automation, of the International Organization for Standardization (ISO).

The messaging services provided by MMS are generic enough to be appropriate for a wide variety ofdevices, applications, and industries. For instance, the MMS Read service allows an application ordevice to read a variable from another application or device. Whether the device is a ProgrammableLogic Controller (PLC) or a robot, the MMS services and messages are identical. Similarly, applica-tions as diverse as material handling, fault annunciation, energy management, electrical

117

power distribution control, inventory control, and deep space antenna positioning in industries as va-ried as automotive, aerospace, petro-chemical, electric utility, office machinery and space explorationhave put MMS to useful work.

The History of MMS

In the early 1980s a group of numerical controller (NC) vendors, machine builders and users workingunder the auspices of committee IE31 of the Electronic Industries Association (EIA) had developeddraft standard proposal #1393A titled "User Level Format and Protocol for Bi-directional Transfer ofDigitally Encoded Information in a Manufacturing Environment". When the General Motors Corpo-ration began its Manufacturing Automation Protocol (MAP) effort in 1980 they used the EIA-1393Adraft standard proposal as the basis for a more generic messaging protocol that could be used for NCs,programmable logic controllers (PLC), robots and other intelligent devices commonly used in a ma-nufacturing environments. The result was the Manufacturing Message Format Standard (MMFS).MMFS was used in the MAP Version 2 specifications published in 1984. During theinitial usage of MMFS it became apparent that a more rigorous messaging standard was needed.MMFS allowed too many choices for device and application developers. This resulted in severalmostly incompatible dialects of MMFS. Furthermore, MMFS did not provide sufficient functionalityto be useful for the Process Control Systems (PCS) found in continuous processing industries.With the objective of developing a generic and non-industry specific messaging system for communi-cations between intelligent manufacturing devices the MMS effort was begun under theauspices of Technical Committee Number 184, Industrial Automation, of the International Organiza-tion for Standardization (ISO).

The result was a standard based upon the Open Systems Interconnection (OSI) networking model ca-lled the Manufacturing Message Specification (MMS). A Draft International Standard (DIS) versionof MMS was published in December 1986 as ISO DIS 9506. The DIS version of MMS (Version 0)overcame the problems with MMFS but had not yet been advanced to the status of anInternational Standard (IS). Faced with a publication deadline of November 1988 the MAP technicalcommittees referenced the DIS version of MMS for the MAP V3.0 specification. In December 1988the IS version of MMS (Version 1) was released as ISO 9506 parts 1 and 2. It was not until after thedevelopment of backwards compatibility agreements by the National Institute of Standards and Te-chnology (NIST) that the IS version of MMS was referenced by the MAP V3.0 specifications.

The MMS Standard

The MMS standard (ISO 9506) is jointly managed by Technical Committee Number 184, IndustrialAutomation, of ISO and the International Electrotechnical Commission (IEC) and consists of two ormore parts (see "Companion Standards"). Parts 1 and 2 define what is referred to as the "core" ofMMS. Part 1 is the service specification. The service specification contains a definition of 1) theVirtual Manufacturing Device, 2) the services (or messages) exchanged between nodes on a network,and 3) the attributes and parameters associated with the VMD and services. Part 2 is the protocolspecification. The protocol specification defines the rules of communication which includes 1) the se-quencing of messages across the network, 2) the format (or encoding) of the messages, and 3) the in-teraction of the MMS layer with the other layers of the communications network. The protocol speci-fication utilizes a presentation layer standard called the Abstract Syntax Notation Number One(ASN.1 - ISO 8824) to specify the format of the MMS messages.

MMS provides a rich set of services for peer-to-peer real-time communications over a network. MMShas been used as a communication protocol for many common industrial control devices like CNCs,PLCs, robots. There are MMS applications in the electrical utility industry such as in Remote Termi-

118

nal Units (RTU), Energy Management Systems (EMS) and other Intelligent Electronic Devices (IED)like reclosers and switches. Most popular computing platforms have MMS connectivity available ei-ther from the computer manufacturer or via a third party. Some of the computer applications availa-ble include Application Programming Interfaces (API), graphical monitoring systems, gateways, anddrivers for spreadsheets, word processors, Application Enablers (A/Es) and relational data base ma-nagement systems (RDBMS). MMS implementations support a variety of communications links in-cluding Ethernet, Token Bus, RS-232C, OSI, TCP/IP, MiniMAP, FAIS, etc. and can connect to manymore types of systems using networking bridges, routers, and gateways.

Benefits of MMS

MMS provides benefits by lowering the cost of building and using automated systems. In particular,MMS is appropriate for any application that requires a common communications mechanism forperforming a diversity of communications functions related to real-time access and distribution ofprocess data and supervisory control. When looking at how the use of a common communicationsservice like MMS can benefit a particular system it is important to evaluate the three major affects ofusing MMS that can contribute to cost savings: 1) Interoperability, 2) Independence and 3) Access.

Interoperability is the ability of two or more networked applications to exchange useful supervisorycontrol and process data information between them without the user of the applications having tocreate the communications environment. While many communication protocols can provide some le-vel of interoperability, many of them are either too specific (to brand/type of application or device,network connectivity, or function performed -- see Independence below) or not specific enough(provide too many choices for how a developer uses the network).

Independence allows interoperability to be achieved independent of:

• The Developer of the Application. Other communications schemes are usually specific to a parti-cular brand (or even model in some cases) of application or device. MMS is defined by indepen-dent international standards bodies with participation from many leading industry experts andvendors.

• Network Connectivity. MMS becomes THE interface to the network for applications thereby iso-

lating the application from most of the non-MMS aspects of the network and how the networktransfers messages from one node to another.

• Function Performed. MMS provides a common communications environment independent of the

function performed. An inventory control application accesses production data contained in acontrol device in the exact same manner as an energy management system would read energy con-sumption data from the same device.

Data Access is the ability of networked applications to obtain the information required by an applica-tion. Although virtually any communications scheme can provide access to data at least insome minimal manner, they lack the other benefits of MMS particularly Independence (see above).

MMS is rigorous enough to minimize the differences between applications performing similar orcomplimentary functions while still being generic enough for many different kinds of applicationsand devices. Communications schemes that are not specific enough can result in applications that allperform similar or complimentary functions in different ways. The result is applications that cannotcommunicate with each other because the developers all made different choices when implementing.While many communications schemes only provide a mechanism for transmitting a sequence of bytes

119

(a message) across a network, MMS does much more. MMS also provides definition, structure andmeaning to the messages that significantly enhances the likelihood of two independently developedapplications interoperating. MMS has a rich set of features that facilitate the real-time distribution ofdata and supervisory control functions across a network in a client/server environment that can be assimple or sophisticated as the application warrants.

Justifying MMS

The real challenge in trying to develop a business justification for MMS (or any network investment)is in assigning value to the benefits given a specific business goal. In order to do this properly it isimportant to properly understand the relationship between the application functions, the connectivityfunctions and the business functions of the network.

In order to assign value to the use of MMS it is important to first understand the role that MMS playswith respect to applications. MMS, as an application layer protocol, provides applicationservices to the business functions, not connectivity services. It is common to view the network simplyas a mechanism to transfer messages (connectivity only). That view hides the value of the applicationfunctions because they become indistinguishable from the business applications which must thenprovide the network application functions. However, the costs are still there. Justifying MMS requi-res that the user recognize the value provided by the network application functions in facilitating inte-roperability, independence and access to data.

In some cases the benefit of the common communications infrastructure MMS provides is only reali-zed as the system is used, maintained, modified, and expanded over time. Therefore a justificationfor such a system must look at life cycle costs versus just the purchase price. It is also important notto underestimate the cost associated with developing, maintaining, and expanding theapplication functions that have to be created if MMS is not used. A key element in assigning value isunderstanding that the business functions are what provide value to the enterprise. The cost of thecustom network application functions directly reduces the amount of effort (i.e. cost) that can be pla-ced on developing, maintaining, and expanding the business functions. With MMS, the communica-tions infrastructure is built once and then re-used by all the business functions.

MMS Application Services

The key feature of MMS is the Virtual Manufacturing Device (VMD) model. The VMD model spe-cifies how MMS devices , also called servers, behave as viewed from an external MMS client appli-cation point of view. MMS allows any application or device to provide both client and server func-tions simultaneously. In general the VMD model defines:

• objects (e.g. variables) that are contained in the server, • the services that a client can use to access and manipulate these objects (e.g. read or write a va-

riable), and • the behavior of the server upon receipt of these service requests from clients.

The remainder of this overview of MMS will provide a summary of the objects defined by the VMDmodel and the MMS services provided to access and manipulate those objects. While the range ofobjects and services is broad, a given device or application need only implement whatever subset ofthese objects and services that are useful in that situation. A more detailed discussion of the MMS

120

VMD model and the various MMS objects and their services will be presented following this over-view.

VMD Object

The VMD itself can be viewed as an object to which all other MMS objects are subordinate (variables,domains, etc. are contained within the VMD). MMS provides services such as Status, UnsolicitedSta-tus, and Identify for obtaining information and status about the VMD. It also provides services likeGetNameList and Rename for managing and obtaining information about objects defined in theVMD.

Variable and Type Objects

MMS provides a comprehensive and flexible framework for exchanging variable information over anetwork. The MMS variable access model includes capabilities for named, unnamed (addressed), andnamed lists of variables. MMS also allows the type description of the variables to be manipulated asa separate MMS object (named type object). MMS variables can be simple (e.g. integer, boolean,floating point, string, etc.) or complex (e.g. arrays and structures). The services available to accessand manage MMS variable and type objects are very powerful and include services for:

Read and Write services allow MMS client applications to access the contents of Named Variables,Unnamed Variables, and Named Variable List objects.

The InformationReport service allows a server to report the contents of a variable to a remote client inan unsolicited manner.

Define, delete, and get attribute services are available for both variables and types to allow clients tomanage the variable access environment.

Service options allow groups of variables to be accessed in a single MMS request, allow large arraysand complex structures to be partially accessed (alternate access), and allow clients to recast variabletypes and complex structures to suit their needs (access by description).

Program Control Objects (Domains and Program Invocations)

The VMD execution model defines two objects for controlling the execution of programs within theVMD. A MMS domain is defined as an object that represents a resource within the VMD (e.g. thememory in which a program is stored). A program invocations is defined as a group of domains theexecution of which can be controlled and monitored. Some of the features of the services the VMDexecution model provides for MMS clients are:

• Services for commanding a VMD to upload/download their domains to/from a MMS client or filein a filestore system (either in the VMD or external to the VMD)

• Services for a VMD to request a domain upload/download from a client. • Start, Stop, Reset, Resume, and Kill services for controlling the execution of program invocations. • Services for deleting, creating, and obtaining the attributes of domains and program invocations. • State changes in program invocations can be linked to MMS events.

121

Event Objects

The MMS event management model defines several named objects consisting of:

• event conditions: an object that represents the state of an event (i.e. active or idle), • event actions: an object that consists of the action that should be taken by the VMD upon the oc-

currence of a change in state of the event condition, and • event enrollments: an object that represents which MMS clients should be notified upon a change

in state of an event condition.

The event management model provides a rich set of services for MMS clients:

Services for notifying clients about events and for clients to acknowledge these notifications.

Services for obtaining summaries of event conditions and event enrollments (called alarm summa-ries).

Services for deleting, defining, obtaining the status and attributes of, and controlling event condi-tions, event actions, and event enrollments.

Semaphore Objects

MMS semaphores are named objects that can be used to control access to other resources and objectswithin the VMD. For instance, a VMD that controls access to a setpoint (a variable) for a control lo-op could use semaphores to only allow one client at a time to be able to change the setpoint. (e.g. withthe MMS Write service). The MMS semaphore model defines two kinds of semaphores. Token se-maphores are used to represent a specific resource within the control of the VMD. Pool semaphoresconsist of one or more named tokens each representing a similar but distinct resource under the con-trol of the VMD. MMS provides semaphore services allow MMS clients to:

Take control of and relinquish the control of semaphores.

Define, delete, and get the attributes or status of semaphores.

Journal Objects

A MMS journal is a named object that represents a time based record, or log, of data. Each entry ina journal can contain the state of an event, the value of a variable, or character string data (called an-notation) that the VMD, or a MMS client, enters into the journal. Services available allow journals tocreated, read, deleted, and cleared (in whole or in part).

Operator Station Object

The operator station is an object that represents a means of communicating with the operator of theVMD via a keyboard and display. An Output service is available to display an alpha-numeric stringon a text display. An Input service is available to obtain alpha-numeric keyboard input with and wi-thout a text prompt on the display.

122

Files

An annex of MMS provides a simple set of services for transferring, renaming, and deleting files in aVMD. A FileDirectory service is provided to obtain a list of available files.

THE VIRTUAL MANUFACTURING DEVICE (VMD) MODEL

The primary goal of MMS was to specify a standard communications mechanism for devices andcomputer applications that would achieve a high level of interoperability. In order to achieve this goalit would be necessary for MMS to define much more than just the format of the messages to be ex-changed -- a common message format, or protocol, is only one aspect of achieving interoperability. Inaddition to protocol, the MMS standard also provides definitions for:

• Objects. MMS defines a set of common objects (e.g. variables, programs, events, etc.) and definesthe network visible attributes of those objects (e.g. name, value, type, etc.).

• Services. MMS defines a set of communications services (e.g. read, write, delete, etc.) for acces-

sing and managing these objects in a networked environment. • Behavior. MMS defines the network visible behavior that a device should exhibit when processing

these services.

This definition of objects, services, and behavior comprises a comprehensive definition of how devi-ces and applications communicate that MMS calls the Virtual Manufacturing Device (VMD) model.The VMD model only specifies the network visible aspects of communications. The internal detail ofhow a real device implements the VMD model (i.e. the programming language, operating system,CPU type, input/output (I/O) systems, etc.) are not specified by MMS. By focusing only on thenetwork visible aspects of a device, the VMD model is specific enough to provide a high level of inte-roperability while still being general enough to allow innovation in application/device implementa-tion and making MMS suitable for application across a range of industries and devices types.

A key aspect of the VMD model is the client/server relationship between networked applicationsand/or devices. A server is a device or application that contains a VMD and its objects (variables,etc.). A client is a networked application (or device) that asks for data or an action from the server. Ina very general sense, a client is a network entity that issues MMS service requests to a server. A ser-ver is a network entity that responds to the MMS requests of a client. While MMS defines theservices for both clients and servers, the VMD model defines the network visible behavior of serversonly.

Many MMS applications and MMS compatible devices provide both MMS client and server func-tions. The VMD model would only define the behavior of the server functions of those applications.Any MMS application or device that provides MMS server functions must follow the VMD modelfor all the network visible aspects of the server application or device. MMS clients are only requiredto conform to rules governing message format or construction and sequencing of messages (the proto-col).

"Real" and "Virtual" Devices and Objects

123

There is a distinction between a real device (e.g. a PLC, CNC, or robot) and the real objects containedin it (e.g. variables, programs, etc.) and the virtual device and objects defined by the VMD model.Real devices and objects have peculiarities (a.k.a. product features) associated with them that are uni-que to each brand of device or application. Virtual devices and objects conform to the VMD modeland are independent of brand, language, operating system, etc. Each developer of a MMS serverdevice or MMS server application is responsible for "hiding" the details of their real devices and ob-jects, by providing an executive function. The executive function translates the real devices and ob-jects into the virtual ones defined by the VMD model when communicating with MMS client appli-cations and devices. Because MMS clients always interact with the virtual device and objects definedby the VMD model, the client applications are isolated from the specifics of the real devicesand objects. A properly designed MMS client application can communicate with many differentbrands and types of devices in the same manner because the details of the real devices and objects arehidden from the MMS client by the executive function in each VMD. This virtual approach to des-cribing server behavior does not constrain the development of innovative devices and product featuresand improvements. The MMS VMD model places constraints only on the network visible aspects ofthe virtual devices and objects, not the real ones.

MMS Device and Object Modeling

The implementor of the executive function (the application or device developer) must decide how to"model" the real objects as virtual objects. The manner in which these objects are modeled is criticalto achieving interoperability between clients and servers among many different developers. Inappro-priate or incorrect modeling can lead to an implementation that is difficult to use or difficult to inte-roperate with.

For instance, take the situation of a PLC that contains a ladder program (a real object). The MMSimplementor (the designer of the executive function) wishes to allow external client applications tocopy the program from the PLC to another computer. For the purposes of this example we shallassume that the MMS VMD model gives the implementor the choice of modeling the ladder programobject as a variable or domain object (both virtual objects). The choice of which virtual object to mapto the real ladder program object is critical because MMS provides a set of services to manipulate va-riables that are quite different from the services used to manipulate domains. Variables can be readindividually or in a list of typed data. Domains can be copied in whole only. If the ladder program ismodeled as a MMS variable it makes the task of performing a simple copying of the program com-plex because the nature of the ladder program data (typically a large block of contiguous memory)would result in an extremely large variable that would be difficult to access easily. If the ladder pro-gram is modeled as a domain, there are specific MMS services provided for uploading and downloa-ding the large blocks of untyped data typical of ladder programs. An incorrect modeling choice canmake the real object difficult to access.

In some cases it makes sense to represent the same real object with two different MMS objects. Forinstance, a large block of variables may also be modeled as a domain. This would provide the MMSclient the choice of services to use when accessing the data. The variable services would give access tothe individual elements in the block. The domain services would allow the entire block to beread/uploaded or written/downloaded as an element of a program invocation (see the batch controllerexample of page 16).

Companion Standards

In many cases the relationship between the real objects and the virtual objects can be standardized fora particular class of device or application (e.g. a PLC or PCS). Developers and users of these real de-

124

vices can define more precisely how MMS is applied to a particular class of device or application.The result is a companion standard. In general, companion standards perform the following func-tions:

• Define the mapping of real objects to the VMD model for a particular class of device. For instan-ce, the companion standard for process control systems would define the relationships betweenreal objects such as setpoints, alarm limits and proportional-integral-derivative (PID) control lo-ops to MMS domains, variables, and program invocations.

• Provide additional definition of the behavioral characteristics of the VMD model for particular

classes of devices. For instance, the actions a PLC takes when receiving a MMS Start or Stop ser-vice request is very different from the actions taken by robots to these same service requests.

• Define additional network visible attributes for common objects. For example, the PLC companion

standard defines additional status information for use in the MMS Status and UnsolicitedStatusservices.

• Define additional objects and services that are unique to a particular class of device. The robot

companion standard contains a definition of the VMDStop service different from the core MMSStop service.

• Define object naming and usage conventions for a particular class of device. For instance, stan-

dardized names and other naming conventions for common objects.

A companion standard, after proceeding through all the committees and work needed to become anISO international standard, becomes a companion of the MMS standard as an additional part. Therobot companion standard is ISO 9506 part 3, the NC companion standard will be ISO 9506 part 4,the PLC companion standard will be ISO 9506 part 5, and the PCS companion standard will be ISO9506 part 6.

The reader should be aware that, for most systems, companion standards are not necessary even whenusing devices for which companion standards exist. The core MMS services defined in parts 1 and 2of MMS provides sufficient standardization to achieve interoperability in most cases. Furthermore,aspects of the companion standards such as object naming, usage, and modeling conventions can beused in a core MMS application without having to implement the entire companion standard.

MMS Objects

MMS defines a variety of objects that are found in many typical devices and applications requiringreal-time communications. A list of these objects is given below. For each object there are correspon-ding MMS services that let client applications access and manipulate those objects. The model forthese objects and the services available are described in more detail later.

- VMD. The device itself is an object

- Domain. Represents a resource (e.g. a program) within the VMD.

- Program Invocation. A runnable program consisting of one or more domains.

- Variable. An element of typed data (e.g. integer, floating point, array, etc.)

125

- Type. A description of the format of a variable's data.

- Named Variable List. A list of variables that is named as a list.

- Semaphore. An object used to control access to a shared resource.

- Operator Station. A display and keyboard for use by an operator.

- Event Condition. An object that represents the state of an event.

- Event Action. Represents the action taken when an event condition changes state.

- Event Enrollment. Which network application to notify when an event condition changes state.

- Journal. A time based record of events and variables.

- File. A file in a filestore or fileserver.

- Transaction. Represents an individual MMS service request. Not a named object.

Object Attributes and Scope

Associated with each object are a set of attributes that describe that object. MMS objects have a nameattribute and other attributes that vary from object to object. Variables have attributes like, name, va-lue, type, etc. while other objects, program invocations for instance, have attributes like name andcurrent state.

Subordinate objects exist only within the scope of another object. For instance, all other objects aresubordinate to, or contained within, the VMD itself. Some objects, such as the operator station objectfor example, may be subordinate only to the VMD. Some objects by be contained within other objectssuch as variables contained within a domain. This attribute of an object is called its scope. The ob-ject's scope also reflects the lifetime of an object. An object's scope may be defined to be:

- VMD-Specific. The object has meaning and exists across the entire VMD (is subordinate to theVMD). The object exists as long as the VMD exists.

- Domain-Specific. The object is defined to be subordinate to a particular domain. The object willexist only as long as the domain exists.

- Application-Association-Specific. Also referred to as AA-Specific. The object is defined by theclient over a specific application association and can only be used by that specific client. Theobject exists as long as the association between the client and server exists.

The name of a MMS object must also reflect the scope of the object. For instance, the object name fora domain-specific variable must not only specify the name of the variable within that domain but alsothe name of the domain. Names of a given scope must be unique. For instance, the name of a variablespecific to a given domain must be unique for all domain specific variables in that domain. Some ob-jects, such as variables, are capable of being defined with any of the scopes described above. Others,like semaphores for example, cannot be defined to be AA-specific. Still others, like operator stations

126

for example, are only defined as VMD-specific. When an object like a domain is deleted, all the ob-jects subordinate to that domain must also be deleted.

The VMD Object

The VMD itself is also an object and has attributes associated with it. Some of the network visibleattributes for a VMD are:

- Capabilities. A capability of a VMD is a resource or capacity defined by the real device. There canbe more than one capability to a VMD. The capabilities are represented by a sequence ofcharacter strings. The capabilities are defined by the implentor of the VMD and providesuseful information about the real device or application.

- Logical Status. Logical status refers to the status of the MMS communication system for the VMDwhich can be:

STATE-CHANGES-ALLOWED, NO-STATE-CHANGES-ALLOWED or ONLY-SUPPORT-SERVICES-ALLOWED.

- Physical Status. Physical status refers to the status of all the capabilities taken as a whole which canbe equal to:

OPERATIONAL, PARTIALLY-OPERATIONAL, INOPERABLE or NEEDS-COMMISSIONING.

VMD Support Services

- Status. This confirmed service is used by a client to obtain the logical and physical status of theVMD. The Status and UnsolicitedStatus service also supports access to implementationspecific status information (called local detail) defined by the implementor of the VMD.

- UnsolicitedStatus. This unconfirmed service is used by a server (VMD) to report its status to a clientunsolicited by the client.

- GetNameList. This confirmed service allows a client to obtain a list of named objects defined withinthe VMD.

- Identify. This confirmed service allows the client to obtain information about the MMS implemen-tation such as the vendor's name, model number, and revision level.

THE VMD EXECUTION MODEL

The VMD model has a flexible execution model that provides a definition of how the execution ofprograms by the MMS server can be controlled. Central to this execution model are the definitions ofthe domain and program invocation objects.

Domains

The MMS domain is a named MMS object that is a representation of some resource within the realdevice. This resource can be anything that is appropriately represented as a contiguous block of un-typed data (referred to as load data). In many typical applications domains are used to represent areasof memory in a device. For instance, a PLC's ladder program memory is typically represented as a

127

domain. Some applications allow blocks of variable data to be represented as both domains and va-riables.MMS provides no definition for, and imposes no constraints on, the content of a domain. To do sowould be equivalent to defining a "real" object (i.e. the ladder program). The content of the domain isleft to the implementor of the VMD. In addition to the name, some of the attributes associated withMMS domains are:

- Capabilities. Each domain can optionally have a list of capabilities associated with it that conveysinformation about memory allocation, input/output characteristics and similar informationabout the real device. The capabilities of a domain are represented by a sequence of imple-mentor defined character strings.

- State. The state of a domain can be LOADING, COMPLETE, INCOMPLETE, READY, or IN-USEas well as other intermediate states.

- Deletable. This attribute indicates whether the domain is deletable via the DeleteDomain service. Adomain that can be downloaded is always deletable. Nondeletable domains are pre-existingand pre-defined by the VMD and cannot be downloaded.

- Sharable. This attribute indicates if the domain can be shared by more than one program invocation(see the example batch controller on page 16).

MMS provides a set of services that allow domains to be uploaded from the device or downloaded tothe device. The MMS domain services do not provide for partial uploads or downloads (exceptas potential error conditions) nor do they provide access to any subordinate objects within the domain.The set of services provided for domains is summarized below:

- InitiateDownloadSequence These services are used to download a domain. The- DownloadSegment InitiateDownloadSequence service commands the VMD- TerminateDownloadSeq. to create a domain and prepare it to receive a download.

- InitiateUploadSequence These services are used to upload the contents- UploadSegment of a domain to a MMS client.- TerminateUploadSequence

- DeleteDomain. This service is used by a client to delete an existing domain, usually before initiating a download sequence.

- GetDomainAttributes. This service is used to obtain the attributes of a domain.

- RequestDomainDownload These services are used by a VMD to request that a- RequestDomainUpload client perform an upload or download of a domain in the VMD.

- LoadDomainContent These services are used to tell a VMD to download (load)- StoreDomainContent or upload (store) a domain from a file. The file may be local to the VMD or may be contained on an external file server.

128

Program Invocations

It is through the manipulation of program invocations that a MMS client controls the execution ofprograms in a VMD. Program invocations can be started, stopped, reset, etc. by MMS clients. A pro-gram invocation is an execution thread which consists of a collection of one or more domains. Simpledevices with simple execution structures may only support a single program invocation containingonly one domain. More sophisticated devices and applications may support multiple program invoca-tions containing several domains.

As an example, consider how the MMS execution model could be applied to a personal computer(PC). When the PC powers up, it downloads a domain called the operating system into memory.When you type the name of the program you want to run and hit the <return> key, the computerdownloads another domain (the executable program) from a file and then creates and runs aprogram invocation consisting of the program and the operating system. The program by itself cannotbe executed until it is bound to the operating system by the act of creating the program invocation. Inaddition to the program invocation's name the attributes of a program invocation are:

- State. The state of a program invocation can be NON-EXISTENT, IDLE, RUNNING, STOPPED,and UNRUNNABLE as well as other intermediate states.

- List of Domains. The list of domains that comprise the program invocation.

- Deletable. Indicates if the program invocation is deletable via the DeleteProgramInvocation service.

- Reusable. Reusable program invocations automatically reenter the IDLE state when the program in-vocation arrives at the end of the program. Otherwise, program invocation in theRUNNING state must be Stopped then Reset in order to bring it back to the IDLE state.

- Monitored. Monitored program invocations utilize the MMS event management services to informthe MMS client when the program invocation leaves the RUNNING state. Monitored pro-gram invocations have an event condition object defined with the same name as the pro-gram invocation.

- Execution Argument. This is a character string passed to the program invocation using the Start orResume service. The execution argument is used to pass data to the program invocation li-ke parameters in a subroutine call.

The MMS services for program invocations allow clients to control the execution of VMD programsand to manage program invocations as follows:

- CreateProgramInvocation. This is used by a client to create a program invocation.

- DeleteProgramInvocation. This service is used to delete a program invocation.

- GetProgramInvocationAttributes. This service returns the attributes of the program invocation to therequesting client.

- Start These services are used by a client to cause the program- Stop invocation to change states.

129

- Reset- Resume- Kill

THE VARIABLE ACCESS MODEL

MMS Variables

A real variable is an element of typed data that is contained within a VMD. A MMS variable is avirtual object that represents a mechanism for MMS clients to access the real variable. Thedistinction between the real variable (which contains the value) and the virtual variable (which repre-sents the access path to the variable) is important. When a MMS variable is deleted, onlythe access to the variable is deleted, not the actual real variable. When a MMS variable is created it isthe access path that is created, not the real variable. MMS defines two types of virtual objects for des-cribing variable access:

- Unnamed Variable Object. An unnamed variable object describes the access to the real variable byusing a device specific address. MMS includes unnamed variable objects primarily for compatibilitywith older devices that are not capable of supporting names. An unnamed variable object is a directmapping to the underlying real variable that is located at the specified address. The attributes of theunnamed variable object are:

- Address. This is the key attribute of the unnamed variable object.

- MMS Deletable. This attribute is always FALSE for an unnamed variable object. Unnamed variableobjects cannot be deleted because they are a direct representation of the "real" variable loca-ted at a specific address in the VMD.

- Type Description. This attribute describes the type (format and range of (values) of the variable.

- Named Variable Object. The named variable object describes the access to the real variable by usinga MMS object name. MMS clients need only know the name of the object in order to accessit. Remember that the name of a MMS variable also specifies the scope (see page 12) of theobject. In addition to the name a named variable object has the following attributes:

- MMS Deletable. This attribute indicates if access to the variable can be deleted via the DeleteVa-riableAccess service.

- Type Description. This attribute describes the type (format and range of values) of the variable.

- Access Method. If the access method is PUBLIC, it means that the underlying address of the na-med variable object is visible to the MMS Client. In this case the same variable can be ac-cessed as an unnamed variable object.

Addresses

A MMS variable address can take on one of several forms. Which specific form that is used by aspecific VMD, and the specific conventions used by that address form, is determined by the imple-mentor of the VMD based upon what is most appropriate for that device. The possible forms for aMMS variable address are:

130

- Numeric. A numeric address is represented by an unsigned integer number (e.g. 103).

- Symbolic. A symbolic address is presented by a character string (e.g. "R001" or "N7:0").

- Unconstrained. An unconstrained address is presented by a untyped string of bytes.

In general, it is recommended that applications utilize named variable objects instead of the addressesof unnamed variable objects wherever feasible. Address formats vary widely from device to device.Furthermore, in some computing environments, the addresses of variables can change from one run-time to the next. Names provide a more intuitive, descriptive and device independent access methodthan addresses.

Named Variable Lists

MMS also defines a named variable list object that provides an access mechanism for grouping bothnamed and unnamed variable objects into a single object for easier access. A named variable list isaccessed by a MMS client by specifying the name (which also specifies its scope) of the named va-riable list. When the VMD receives the Read service request from a client, it reads all the individualobjects in the list and returns their value within the individual elements of the named variable list.Because the named variable list object contains independent subordinate objects, a positive confirma-tion to a Read request for a named variable list may indicate only partial success. Thesuccess/failure status of each individual element in the confirmation must be examined by the clientto ensure that all of the underlying variable objects were accessed without error. In addition to its na-me and the list of underlying named and unnamed variable objects, named variable list objects alsohave a MMS deletable attribute that indicates whether or not the named variable list can be deletedvia a DeleteNamedVariableList service request.

Named Type Object

The type of a variable indicates its format and the possible range of values that the variable can take.Examples of type descriptions include 16-bit signed integer, double precision floating point, 16 cha-racter string, etc. MMS allows the type of a variable to be either 1) described or 2) defined as a sepa-rate named object called a named type. A described type is not an object. It is a binary description ofthe type in a MMS service request (i.e. Read, Write, or InformationReport) that uses the Access byDescription service option. The named type object allows the types of variables to be defined andanaged separately. This can be particularly useful for systems that also use the DefineNamedVariableservice to define names and types for unnamed variable objects. Other attributes of the named typeobject include:

- MMS Deletable. This parameter indicates if the named type can be deleted using a DeleteName-dType service request.

- Type Description. This describes the type in terms of complexity (simple, array, or structured), for-mat (integer, floating point, etc.), and the size or range of values (16-bit, 8 characters, etc.)

Type Description

The specification for a MMS type description is very flexible and can describe virtually any data for-mat in use today. As mentioned earlier, the type description specifies the format of a variable and the

131

range of values that that variable can represent. MMS defines three basic formats for types: 1) sim-ple, 2) array and 3) structured:

- Simple. Simple types are the most basic types and cannot be broken down into a smaller unit viaMMS. The other type forms (arrays and structures) are constructed types that can eventua-lly be broken down into simple types. Simple type descriptions generally consist of theclass and size of the type. The size parameter is usually defined in terms of the number ofbits or bytes that a variable of that type would comprise in memory. The various classes ofsimple types defined by MMS consists of:

- BOOLEAN. Booleans are generally represented as a single byte with either a zero (FALSE) ornon-zero (TRUE) value. There is no size parameter for Boolean types.

- BIT STRING. A Bit String is a sequence of bits. The size of a Bit String indicates the number ofbits in the Bit String.

- BOOLEAN ARRAY. A Boolean Array is also a sequence of bits where each bit represents TRUE(1) or FALSE (0). Differs from an array of Booleans in that each element in a BooleanArray is represented by a single bit while each element in an array of Booleans is represen-ted by a single byte. The size parameter specifies the number of Booleans (number of bits)in the Boolean Array.

- INTEGER. MMS Integers are signed integers. The size parameter specifies the number of bits ofthe integer.

- UNSIGNED. The Unsigned type is identical to the Integer type except that it is not allowed to takeon a negative value. Because the most significant bit of an Integer is essentially a sign bit,an Unsigned with a size of 16 bits can only represent 15-bits of values or values of 0through 32,767.

- FLOATING POINT. The MMS definition for floating point is modeled after the IEEE 754 stan-dard but can accommodate any number of bits for the format and exponent width includingthe single and double precision floating point formats commonly in use today.

- REAL. This type is a representation of floating point numbers conforming to the ISO 8824 stan-dard.

- OCTET STRING. An Octet String is a sequence of bytes (called an "octet" in ISO terminology)with no constraint on the value of the individual bytes. The size of an Octet String is thenumber of bytes in the string.

- VISIBLE STRING. Unlike the Octet String type, the Visible String type only allows each byte tocontain a printable character. Although these character sets are defined by ISO 10646, theyare compatible with the common ASCII character set. The size of the Visible String is thenumber of bytes in the string.

- GENERALIZED TIME. This is a representation of time specified by ISO 8824. It provides milli-second resolution of date and time.

132

- BINARY TIME. This is a time format specified by MMS and represents either 1) time of day by avalue which is equal to the number of milliseconds from midnight or 2) date and time by avalue that is equal to the time of day and the number of days since January 1, 1984.

- BCD. Binary Coded Decimal format is where four-bits are used to hold a binary value of a singledigit of zero to ten. The size parameter is the number of decimal digits that the BCD valuecan represent.

- OBJECT IDENTIFIER. This is a special class of object defined by ISO 8824 that is used to definenetwork objects.

- Array. An array type defines a variable that consists of a sequence of multiple identical (in formatnot value) elements. Each element in an array can also be an array or even a structured orsimple variable. MMS allows for arbitrarily complex nesting of arrays and structures. Thelevel of complexity that a VMD can support is defined by its nesting level. An array ofsimple variables (e.g. an array of Integers) requires a nesting level of 1. An array of anarray or an array of structured variables, each consisting of simple variables, requires anesting level of 2.

- Structures. A structured type defines a variable that consists of a sequence of multiple, but not ne-cessarily identical, elements. Each individual element in a structure can be of a simpletype, an array, or another structure. MMS allows for arbitrarily complex nesting of structu-res and arrays. A structured variable consisting of individual simple elements requires anesting level of 1. A structured variable consisting of one or more arrays of structures con-taining simple variables requires a nesting level of 3.

Variable Access Services

- Read. The Read service is used by MMS clients to obtain the values of named, unnamed, or a namedvariable list objects (hereinafter "Variables").

- Write. The Write service is used by MMS clients to change the values of Variables.

- InformationReport. This service is used by a VMD to report the values of Variables to a MMS clientin an unsolicited manner. It is roughly equivalent to sending a Read response to a clientwithout the client having issued the Read request. The InformationReport service can beused to eliminate polling by client applications or as an alarm notification mechanism. TheVMD could directly report changes in the value of Variables, alarm conditions, or evenchanges in state of the VMD or program invocations to clients by using the Information-Report service. MMS does not require the use of the InformationReport service for thispurpose, it is simply one of the many potential applications of the service.

- GetVariableAccessAttributes. This service is used by MMS clients to obtain the access attributes ofa single named or unnamed variable object. The access attributes are the type (either a na-med type or type description), the MMS deletable attribute and the address for unnamedvariables. The address of named variables is optional and is only returned if the address isknown and visible.

- DefineNamedVariable. This service allows MMS clients to create a named variable object corres-ponding to a real VMD variable that can be represented by an unnamed variable object.Once defined subsequent access to the unnamed variable object can be made via the named

133

variable. This service also allows the MMS client to optionally specify a type definition forthe named object that may be different from the type inherently defined for the unnamedvariable object.

- DeleteVariableAccess. This service is used to delete named variable objects where the MMS deleta-ble attribute is TRUE. The service provides options for deleting only specific named varia-ble objects or all named variable objects of a specified scope (VMD, domain, or AA-specific).

- DefineNamedVariableList These services are used to create,- GetNamedVariableListAttributes delete and obtain the attributes- DeleteNamedVariableList (i.e. the list of underlying named and unnamed variable objects) of named variable list objects.

- DefineNamedType. This service is used by a MMS client to create a new named type by specifyingthe type name (including scope), MMS deletable and type description attributes.

- DeleteNamedType. This service is used to delete an existing named type where the MMS deletableattribute is TRUE. The service provides options for deleting only specific named type ob-jects or all named type objects of a specified scope (VMD, domain, or AA-specific).

- GetNamedTypeAttributes. This service is used by a MMS client to determine the MMS deletableand type description attributes of a specific named type object.

Variable Access Service Features

The Read, Write and InformationReport services provide several features for accessing Variables. Theuse of these service features, described below, by MMS clients can provide enhanced performance andvery flexible access to MMS Variables.

Access by Description is supported for unnamed variable objects only. It allows the MMS client todescribe the variable by specifying both an address and a type description. These variables are calleddescribed variables. The described type may be different from the type inherently defined for the un-named variable object. This can be useful for accessing data in devices where the device's memoryorganization is simplistic. For example, many PLCs represent their data memory as a largeblock of 16-bit registers (essentially signed integers). Some applications may store ASCII string datain these registers. By using a described variable a MMS client can have the data stored in these regis-ters returned to it as a string instead of as a block of signed integers.

List of Variables. This feature allows a list of named variable, unnamed variable, and named variablelist objects to be accessed in a single MMS Read, Write, or InformationReport service. Care must betaken by the client to ensure that the resultant MMS service request message does not exceed themaximum message size (or maximum segment size) supported by the VMD. This option also requiresthat a client examine the entire response for success/failure for each individual element in the list ofVariables.

Access Specification in Result is an option for the Read service that allows a MMS client to requestthat the variable's access specification be returned in the Read response. The access specificationwould consist of the same information that would be returned by a GetVariableAccessAttributes ser-vice request.

134

Alternate Access allows a MMS client to 1) partially access only specified elements contained in alarger arrayed and/or structured variable, and 2) rearrange the ordering of the elements contained instructured variables.

THE EVENT MANAGEMENT MODEL

In a real sense an event, or an alarm, is easy to define. Most people have an intuitive feel for what cancomprise an event within their own area of expertise. For instance, in a process control application itis common for a control system to generate an alarm when the process variable (e.g. temperature)exceeds a certain preset limit called the high alarm threshold. In a power distribution application analarm might be generated when the difference in the phase angle of the current and voltage wave-forms of a power line exceeds a certain number of degrees. The MMS event management model pro-vides a framework for accessing and managing the network communication aspects ofthese kinds of events. This is accomplished by defining three named objects that represent 1) the stateof an event (event condition), 2) who to notify about the occurrence of an event (event enrollment)and 3) the action that the VMD should take upon the occurrence of an event (event action).

For many applications, the communication of alarms can be implemented by using MMS servicesother than the event management services. For instance, a simple system can notify a MMS clientabout the fact that a process variable has exceeded some preset limit by sending the process variable'svalue to a MMS client using the InformationReport service. Other schemes using other MMS servicesare also possible. When the application is more complex and requires a more rigorous definition ofthe event environment in order to ensure interoperability, the MMS event management model shouldbe used.

Event Condition Object

A MMS event condition object is a named object that represents the current state of some real condi-tion within the VMD. It is important to note that MMS does not define the VMD action (orprogramming) that causes a change in state of the event condition. In the process control example gi-ven above, an event condition might reflect an IDLE state for when the process variable was not ex-ceeding the value of the high alarm threshold and an ACTIVE state when the process variable didexceed the limit. MMS does not explicitly define the mapping between the high alarm limit and thestate of the event condition. Even if the high alarm limit is represented by a MMS variable, MMSdoes not define the necessary configuration or programming needed to create the mapping betweenthe high alarm limit and the state of the event condition. From the MMS point of view, the change instate of the event condition is caused by some autonomous action on the part of the VMD that is notdefined by MMS. The MMS event management model defines two classes of event conditions:

- Network Triggered. A network triggered event condition is triggered when a MMS client specifica-lly triggers it using the TriggerEvent service request. Network triggered events do not havea state (their state is always DISABLED). They are useful for allowing a MMS client tocontrol the execution of event actions and the notifications of event enrollments.

- Monitored. A monitored event condition has a state attribute that the VMD sets based upon somelocal autonomous action. Monitored event conditions can have a Boolean variable associa-ted with them that is used by the VMD to evaluate the state. The VMD periodically evalua-tes this variable. If the variable is evaluated as TRUE, the VMD sets the event condition

135

state to ACTIVE. When the Boolean variable is evaluated as FALSE, the VMD sets theevent condition state to IDLE. Event conditions that are created as a result of a CreatePro-gramInvocation request with the Monitored attribute TRUE, are monitored event condi-tions but they do not have an associated Boolean variable.

In addition to the name of the event condition (an object name that also reflects its scope) and its class(NETWORK TRIGGERED or MONITORED), MMS defines the following attributes for bothnetwork triggered and monitored event conditions:

- MMS Deletable. This attribute indicates if the event condition can be deleted by using a DeleteE-ventCondition service request.

- State. This attribute reflects the state of the event condition and can be IDLE, ACTIVE, orDISABLED. Network triggered events are always DISABLED.

- Priority. This attributed reflects the relative priority of an event condition object with respect to allother defined event condition objects. Priority is a relative measure of the VMD's proces-sing priority when it comes to evaluating the state of the event condition as well as the pro-cessing of event notification procedures that are invoked when the event condition changesstate. A value of zero (0) is the highest priority. A value of 127 is the lowest priority. Avalue of 64 is the "normal" priority.

- Severity. This attribute reflects the relative severity of an event condition object with respect to allother defined event condition objects. Severity is a relative measure of the affect that achange in state of the event condition can have on the VMD. A value of zero (0) is the hi-ghest severity. A value of 127 is the lowest. A value of 64 is for event conditions with"normal" severity.

Additionally, MMS also defines the following attributes for Monitored event conditions only:

- Monitored Variable. This is a reference to the underlying Boolean variable whose value the VMDevaluates in determining the state of an event condition. It can be either a named or unna-med variable object. If it is a named object it must be a variable with the same name (andscope) of the event condition. If the event condition object is locally defined or it was defi-ned via a CreateProgramInvocation request with the monitored attribute TRUE, then thevalue of the monitored variable reference would be equal to UNSPECIFIED. If the monito-red variable is deleted, then the value of this reference would be UNDEFINED and theVMD should disable its event notification procedures for this event condition.

- Enabled. This attribute reflects whether a change in the value of the monitored variable (or the stateof the associated program invocation if applicable) should cause the VMD to process theevent notification procedures for the event condition (TRUE) or not (FALSE). A client candisable an event condition by changing this attribute via an AlterEventConditionMonito-ring service request.

- Alarm Summary Reports. This attribute indicates whether (TRUE) or not (FALSE) the event condi-tion should be included in alarm summary reports in response to a GetAlarmSummaryRe-port service request.

136

- Evaluation Interval. This attribute specifies the maximum amount of time, in milliseconds, betweensuccessive evaluations of the event condition by the VMD. The VMD may optionally allowclients to change the evaluation interval.

- Time of Last Transition to Active These attributes contain either- Time of Last Transition to Idle the time of day or a time sequence number of the last state transitions of the event condition. If the event condition has never been in the IDLE or ACTIVE state, then the value of the corresponding attribute shall be UNDEFINED.

Event Condition Services

- DefineEventCondition These services are used by MMS- DeleteEventCondition clients to create event condition- GetEventConditionAttributes objects, to delete event condition objects (if the MMS Deletable attribute is TRUE) and to obtain the static attributes of an existing event condition object respectively.

- ReportEventConditionStatus. This service allows a MMS client to obtain the dynamic status of theevent condition object including its state, the number of event enrollments enrolled in theevent condition, whether it is enabled or disabled, and the time of the last transitions to theactive and idle states.

- AlterEventConditionMonitoring. This service allows the MMS client to alter the priority, enable ordisable the event condition, enable or disable alarm summary reports and to change theevaluation interval if the VMD allows the evaluation interval to be changed.

- GetAlarmSummary. This service allows a MMS client to obtain event condition status and attributeinformation about groups of event conditions. The client can specify several filters for de-termining which event conditions to include in an alarm summary.

Event Actions

An event action is a named MMS object that represents the action that the VMD will take when thestate of an event condition changes. An event action is optional. When omitted, the VMD would exe-cute its event notification procedures without processing an event action. An event action, when used,is always defined as a confirmed MMS service request. The event action is attached or linked with anevent condition when an event enrollment is defined. For example, an event action mightbe a MMS Read request. If this event action is attached to an event condition (by being referenced inan event enrollment), when the event condition changes state and the event condition is enabled, theVMD would execute this Read service request just as if it had been received from a client. Except thatthe Read response (either positive or negative) is included in the EventNotification service requestthat is sent to the MMS client defined for the event enrollment. A confirmed service request must beused (i.e. Start, Stop, Read, etc.). Unconfirmed services (e.g. InformationReport, UnsolicitedStatus,and EventNotification) and other services that must be used in conjunction with other services (e.g.

137

domain upload-download sequences) cannot be used as event actions. In addition to its name, anevent action has the following attributes:

- MMS Deletable. When TRUE it indicates that the event action can be deleted via a DeleteEventAc-tion service request.

- Service Request. This attribute is the MMS confirmed service request that the VMD will processwhen the event condition that the event action is linked with changes state.

Event Action Services

- DefineEventAction These services are used by MMS clients- DeleteEventAction to create, delete (if the MMS Deletable- GetEventActionAttributes attribute is TRUE) and to obtain the attributes of an event action object respectively.

- ReportEventActionStatus. This service allows a MMS client to obtain a list of names of event en-rollments that have referenced a given event action.

Event Enrollments

The event enrollment is an named MMS object that ties all the elements of the MMS event manage-ment model together. The event enrollment represents a request on the part of a MMS client to benotified about changes in state of an event condition. When an event enrollment is defined, referencesare made to an event condition, an event action (optionally) and the MMS client towhich EventNotification should be sent. In addition to its name, the attributes of an event enrollmentare:

- MMS Deletable. If TRUE, this attribute indicates that the event enrollment can be deleted via a De-leteEventEnrollment service request.

- Event Condition. This attribute is the name of the event condition about which the event enrollmentwill be notified of changes in state.

- Transitions. This attribute indicates the state transitions of the event condition for which the VMDshould execute its event notification procedures as follows:

DISABLED-TO-ACTIVEDISABLED-TO-IDLEIDLE-TO-ACTIVEIDLE-TO-DISABLEDACTIVE-TO-IDLEACTIVE-TO-DISABLEDANY-TO-DELETED

- Notification Lost. If this attribute is TRUE, it means that the VMD could not successfully completeits event notification procedures due either to 1) some local resource constraint or pro-blem or 2) because the VMD could not establish an association to the client specified inthe event enrollment definition. Further transitions of the event condition will be ignoredfor this event enrollment as long as these problems persist.

138

- Event Action. This optional attribute is a reference to the event action that should be processed bythe VMD for those state transitions of the event condition specified by the event en-rollment's transitions attribute.

- Client Application. This attribute is a reference to the MMS client to which the EventNotificationservice requests should be sent for those transitions of the event condition specified by theevent enrollment's transitions attribute. This attribute should only be defined if the VMDsupports third party services. This attribute is omitted if the duration of the event en-rollment is CURRENT.

- Duration. This attribute indicates the lifetime of the event enrollment. A duration of CURRENTmeans the event enrollment is only defined for the life of the association between theMMS client and the VMD (similar to an object with application association specific sco-pe). If the association between the VMD and the client is lost and there is no client appli-cation reference attribute for the event enrollment (client application reference is omittedfor event enrollments with duration = CURRENT), then the VMD is not capable of re-establishing an application association in order to send an EventNotification to the client.If the duration of the event enrollment is PERMANENT, then the application associationbetween the VMD and the client can be terminated without affecting the event en-rollment. In this case, when a specified state transition occurs, the VMD will automati-cally establish an application association with the specified client.

- State. The state of an event enrollment indicates IDLE, ACTIVE, DISABLED and a variety of otherstates that represent the status of the event notification procedures being executed by theVMD.

- Alarm Acknowledgment Rules. attribute specifies the rules of alarm acknowledgment that the VMDshould enforce when determining the state of the event enrollment. If anacknowledgment to an EventNotification service request is required, the act of acknowle-dging (or not acknowledging) the Event Notification shall affect the state of the event en-rollment. The various alarm acknowledgment rules are summarized as follows:

- NONE. No acknowledgments are required and they shall not affect the state of an event enrollment.These types of event enrollments are not included in alarm enrollment summaries.

- SIMPLE. Acknowledgment shall not be required but acknowledgments of transitions to theACTIVE state shall affect the state of the event enrollment.

- ACK-ACTIVE. Acknowledgment of event condition transitions to the ACTIVE state shall be requi-red and shall affect the state of the event enrollment. Acknowledgments of other transi-tions are optional and shall not affect the state of the event enrollment.

- ACK-ALL. Acknowledgments are required for all transitions of the event condition to the ACTIVEor IDLE state and shall affect the state of the event enrollment.

- Time Active Acked These attributes reflect the time of the last- Time Idle Acked acknowledgment of the Event Notification for

state transitions in the event condition to theACTIVE or IDLE state corresponding to the eventenrollment.

139

Event Enrollment Services

- DefineEventEnrollment These services are used by MMS clients to- DeleteEventEnrollment create, delete (if the MMS Deletable attribute- GetEventEnrollmentAttributes is TRUE) and to obtain the static attributes of an event enrollment object.

- ReportEventEnrollmentStatus. This service allows the client to obtain the dynamic attributes of anevent enrollment including the notification lost, duration, alarm acknowledgment rule andstate attributes.

- AlterEventEnrollment. This service allows the client to alter the transitions and alarmacknowledgment rule attributes of an event enrollment.

- GetAlarmEnrollmentSummary. This service allows a MMS client to obtain event enrollment andevent condition information about groups of event enrollments. The client can specify seve-ral filters for determining which event enrollments to include in an alarm enrollmentsummary.

Event Notification Services

MMS provides services for notifying clients of event condition transitions and acknowledging thoseevent notifications as follows:

- EventNotification. This is an unconfirmed service that is issued by the VMD to the MMS client tonotify the client about event condition transitions that were specified in an event en-rollment. There is no response from the client. The acknowledgment of the notification ishandled separately. The

EventNotification service would include a MMS confirmed service response (positive or negative) ifan event action was defined for the event enrollment.

- AcknowledgeEventNotification. This confirmed service is used by a MMS client to acknowledge anEventNotification sent to it by the VMD. The client specifies the event enrollment name,the acknowledgment state, and the transition time parameters that were in the EventNotifi-cation request that is being acknowledged.

- TriggerEvent. This service is used to trigger a Network Triggered event condition. It gives the clienta mechanism by which it can invoke event action and event notification processing by theVMD. For instance, a client can define an event condition, event action, and event en-rollments that refer to other MMS clients. When the defining client issues a TriggerEventservice request to the VMD it will cause the VMD to execute a MMS service request (theevent action) and send these results to other MMS clients via the EventNotification service.

THE SEMAPHORE MANAGEMENT MODEL

In many real-time systems there is a need for a mechanism by which an application can control accessto a system resource. An example might be a workspace that is physically accessible to several robots.Some means to control which robot (or robots) can access the workspace is needed. MMS defines twotypes of semaphores for these types of applications: 1) Token Semaphores and 2) Pool Semaphores.

140

Token Semaphores

A token semaphore is a named MMS object that can be a representation of some resource within thecontrol of the VMD to which access must be controlled. A token semaphore is modeled as a collectionof tokens that MMS clients take and relinquish control of using MMS services. This allows bothmultiple or exclusive ownership of the semaphore. When a MMS client owns the token, it providessome level of access to the underlying resource. An example might be where two users want to chan-ge a setpoint for the same control loop at the same time. These users could use a MMS token sema-phore containing only one token to represent the control loop in order to coordinate their accessto the setpoint. When the user "owns" the token, they can change the setpoint. The other would haveto wait until ownership is relinquished.

A token semaphore can also be used for the sole purpose of coordinating the activities of two MMSclients without representing any real resource. This kind of "virtual" token semaphore looks andbehaves the same except that they can be created and deleted by MMS clients using the DefineSema-phore service.

Because semaphores either represent a real resource or are used for the purpose of coordinating acti-vities between two or more MMS clients, the scope of a semaphore cannot be AA-Specific. Ifan object's scope is AA-Specific there can be only one client. Also, AA-Specific objects only exist aslong as the application association exists while real resources must exist outside the scope of any gi-ven application association. In addition to its name the token semaphore has the following attributes:

- Deletable. If TRUE it means that the semaphore does not represent any real resource within theVMD and can therefore be deleted by a MMS client via the DeleteSemaphore service.

- Number of Tokens. This attribute indicates the total number of tokens contained in the token sema-phore.

- Owned Tokens. This attribute indicates the number of tokens whose associated semaphore entrystate is OWNED.

- Hung Tokens. This attribute indicates the number of tokens whose associated semaphore entry stateis HUNG.

Pool Semaphores

A pool semaphore is similar to a token semaphore except that the individual tokens are identifiableand have a name associated with them. These named tokens can optionally be specified by the MMSclient when issuing TakeControl requests. The pool semaphore itself is a MMS object. The namedtokens contained in the pool semaphore are not MMS objects. They are representations of a real re-source in much the same way an unnamed variable object is. The name of the pool semaphore is sepa-rate from the names of the named tokens. Pool semaphores can only be used to represent some realresource within the VMD. Therefore, pool semaphores cannot be created or deleted using MMS ser-vice requests and cannot be AA-Specific in scope. In addition to the name of a pool semaphore thefollowing attributes also are defined by MMS:

- Free Named Tokens. The named tokens for which no associated semaphore entry exists.

- Owned Named Tokens. The named tokens for which the associated semaphore entry state isOWNED.

141

- Hung Named Tokens. The named tokens for which the associated semaphore entry is HUNG.

Semaphore Entry

When a MMS client issues a TakeControl request for a given semaphore the VMD creates an entry inan internal queue that is maintained for each semaphore. Each entry in this queue is called a sema-phore entry. The attributes of a semaphore entry are visible to MMS clients and provide informationabout the internal semaphore processing queue in the VMD. The semaphoreentry is not a MMS object. It only exists from the receipt of the TakeControl indication by the VMDuntil the token control of the semaphore is relinquished or if the VMD responds negativelyto the TakeControl request. The semaphore entry reflects the state of the relationship between theclient and the semaphore. Several of the attributes of the semaphore entry are specified by theclient in the TakeControl request. These attributes are:

- Entry ID. This is a number assigned by the VMD to distinguish one semaphore entry from another.The Entry ID is unique for a given semaphore.

- Named Token. Valid only for pool semaphores. It contains the named token that was optionally re-quested by the client in a TakeControl request or, if the semaphore entry is in the OWNEDor HUNG state, it is the named token that the VMD assigned as a result of a TakeControlrequest.

- Application Reference. This is a reference to the MMS client application that issued the TakeCon-trol request that created the semaphore entry.

- Priority. This attribute indicates the priority of the semaphore entry with respect to other semaphoreentries. Priority is used to decide which semaphore entry in the QUEUED state will begranted a token (or named token) when multiple requests are outstanding. The value (0 =highest priority, 64 = normal priority, and 127 = lowest priority) is specified by the clientin the TakeControl request.

- Entry State. The entry state attribute represents the relationship between the MMS client and thesemaphore by one of the following values:

- QUEUED. This means that a TakeControl request has been received but has not been responded toby the VMD. The client is waiting for control of the semaphore.

- OWNED. The VMD has responded positively to the TakeControl request and the client now ownsthe token (or named token).

- HUNG. This state means that the application association over which the MMS client issued theTakeControl request has been lost and the Relinquish if Connection Lost attribute isFALSE. A MMS client can take control of a semaphore entry in the HUNG state by issuinga TakeControl request with the preempt option TRUE and by specifying the MMS client topreempt (via the application reference attribute).

- Relinquish if Connection Lost. If this attribute is TRUE the VMD will relinquish control of the se-maphore if the application association for the MMS client that owned the token for this

142

semaphore entry is lost or aborted. If FALSE, the semaphore entry will enter the HUNGstate if the application association is lost or aborted.

- Control Timeout. This attribute is specified by the client in the TakeControl request and indicatesmany milliseconds the client should be allowed to control the semaphore once control isgranted. If the client has not relinquished control using a RelinquishControl request whenthe control timeout expires, the semaphore entry will be deleted and control of the sema-phore will be relinquished. If the control timeout attribute is omitted in the TakeControlrequest then no control timeout will apply for that semaphore entry.

- Abort on Timeout. This attribute is specified by the client in the TakeControl request and indicatesif the VMD should abort the application association with the owner client upon a controltimeout.

- Acceptable Delay. This attribute is specified by the client in the TakeControl request and indicateshow many milliseconds the client is willing to wait for control of the semaphore. If

control is not granted during this time, the VMD will respond negatively to the TakeControl re-quest. If the acceptable delay attribute is omitted from the TakeControl request then theclient is willing to wait indefinitely.

Semaphore Services

- TakeControl. Used by a client to request control of a semaphore.

- RelinquishControl. Used by a client to release control over a semaphore that the client currently hascontrol of.

- DefineSemaphore These services are used by clients to- DeleteSemaphore define and delete token semaphores that are used solely for coordinating the activities of two or more clients.

- ReportSemaphoreStatus These services are used to obtain the- ReportPoolSemaphoreStatus status (number of total, owned and hung tokens) of token and pool semaphores.

- ReportSemaphoreEntryStatus. This service is used by a client toobtain the attributes of semaphore entries corresponding to aspecified state.

OTHER MMS OBJECTS

Operator Stations

An operator station is a MMS object that can be used to represent character based input and outputdevices that may to attached to the VMD for the purpose of communicating with an operator local tothe VMD. MMS defines three types of operator stations:

143

- Entry. An entry only operator station consists of an input device only. This may be a keyboard orperhaps a bar code reader. The input data must be of the type Visible String consisting ofalpha-numeric characters only.

- Display. A display only operator station consists of a character based output display that can displayVisible String data (no graphics or control characters).

- Entry-Display. This type of operator stations consists of both a entry station and a display station.

Because the operator station is a representation of a physical feature of the VMD, it exists beyond thescope of any domain or application association. Therefore, MMS clients access the operatorstation by name without scope. MMS allows for any number of operator stations for a givenVMD. The services used by MMS clients to perform operator communications are:

- Input. MMS clients use this service to obtain a single input string from an input device. The servicehas an option for displaying a sequence of prompts on the display if the operator station isan entry-display type of operator station.

- Output. This service is used to display a sequence of output strings on the display of the operatorstation.

Journals

A MMS journal represents a log file that contains a collection of records (called journal entries) thatare organized by time stamps. Journals are used to store time based records of tagged variable data,user generated comments or combination of events and tagged variable data. Journal entries contain atime stamp that indicates when the data in the entry was produced (not when the journal entry wasmade). This allows MMS journals to be used for applications where a sample of a manufactured pro-duct is taken at one time, analyzed in a laboratory off-line, and then at a later time placed into thejournal. In this case the journal entry time stamp would indicate when the sample was taken.

MMS clients read the journal entries by specifying the name of the journal (which can be VMD-Specific or AA-Specific only) and either 1) the date/time range of entries that the client wishesto read or 2) by referring to the entry ID of a particular entry. The entry ID is a unique binary identi-fier assigned by the VMD to the journal entry when it is placed into the journal.

Each entry in a journal can be one of the following types:

- Annotation. This type of entry contains a textual comment. This is typically used to enter a com-ment regarding some event or condition that had occurred in the system.

- Data. This type of entry would contain a list of variable tags and the data associated with those tagsat the time indicated by the time stamp. Each variable tag is a 32-character name that doesnot necessarily refer to a MMS variable (although it might).

- Event-Data. This type of entry contains both variable tag data and event data. Each entry of this typewould include the same list of variable tags and associated data as described above alongwith a single event condition name and the state of that event condition at the time indica-ted by the time stamp.

The services available for MMS journals are as follows:

144

- ReadJournal. This service is used by a client to read one or more entries from a journal.

- WriteJournal. This service is used by a client to create new journal entries in a journal. A journalentry can also be created by local autonomous action by the VMD without a client using theWriteJournal service.

- CreateJournal These services are used by a client to- DeleteJournal create and delete (if the journal is deletable) journal objects. The CreateJournal service only creates the journal. It does not create any journal entries (see ReadJournal).

- InitializeJournal. This service is used by a client to delete all or some of the journal entries that are in a journal. For instance, a client can use InitializeJournal to delete old journal entries that are no longer of any interest.

Files

MMS also provides a set of simple file transfer services for devices that have a local file store but donot support a full set of file services via some other means. For instance, many robot implementationsof MMS use the file services for moving program (domain) files to the robot from a client application.The MMS file services support file transfer only, not file access. Although these file services are defi-ned in an annex within the MMS standard, they are widely supported by most commercial MMS im-plementations. The services for files are described below:

- FileOpen. This service is used by a client to tell the VMD to open a file and prepare it for a transfer.

- FileRead. This service is used to obtain a segment of the file's data from a VMD. The client wouldcontinue to issue FileOpen requests until the VMD indicates that all the data in the file hasbeen returned. The number of bytes returned in each FileRead response is determined sole-ly by the VMD (and can vary from one FileRead response to the next) and is not contro-llable by the client.

- FileClose. This service is used by a client to close a previously opened file. It is used after all thedata from the file has been read or can be used to discontinue a file transfer before it iscompleted.

- ObtainFile. This service is used by a client to tell the VMD to obtain a file. When a VMD receivesan ObtainFile request it would issue FileOpen, FileRead(s) and FileClose service requeststo the client application that issued the ObtainFile request. The client would then have tosupport the server functions of the FileOpen, FileRead, and FileClose services. A thirdparty option is available (if supported by the VMD) to tell the VMD to obtain the file fromanother node on the network using some protocol (which may or may not be MMS).

- FileRename These services are used to rename, delete,- FileDelete and obtain a directory of files on the- FileDirectory VMD respectively.

145

MMS CONTEXT MANAGEMENT

MMS provides services for managing the context of communications between two MMS nodes on anetwork. These services are used to establish and terminate application associations and for handlingprotocol errors between two MMS nodes. The node that initiates the association with another node isreferred to as the calling node. The responding node is referred to as the called node.

In a MMS environment, two MMS applications establish an application association between themsel-ves using the MMS Initiate service. This process of establishing an application association consists ofan exchange of some parameters and a negotiation of other parameters. The exchanged parametersinclude information about restrictions that pertain to each node that are determined solely by that no-de (e.g. which MMS services are supported). The negotiated parameters are items where thecalled node either accepts the parameter proposed by the calling node or adjusts it downward as it re-quires (e.g. the maximum message size). The calling application issues an Initiate service request thatcontains information about the calling node's restrictions and a proposed set of the negotiatedparameters. The called node examines the negotiated parameters and adjusts them as necessary tomeets its requirements and then returns the results of this negotiation and the information about it'srestrictions in the Initiate response. Once the calling node receives the Initiate confirmation the appli-cation association is established and other MMS service requests can then be exchanged between theapplications.

Once an application association is established either node can assume the role of client or server in-dependent of which node was the calling or called node. For any given set of MMS services oneapplication assumes the client role while the other assumes the role of server or VMD. Whether ornot a particular MMS application is a client, server (VMD), or both is determined solely by the deve-loper of the application.

Associations vs. Connections

Although many people may refer to network connections and application associations interchangeablythere is a distinct difference. A connection is an attribute of the underlying network layers that repre-sents a virtual circuit between two nodes. For instance, telephone networks require that two partiesestablish a connection between themselves (by dialing and answering) before they can communicateat all. An application association is an agreement between two networked applicationsgoverning their communications. It is analogous to the two parties agreeing to use a particular lan-guage and to not speak about religion or politics over the telephone. Application associations existindependent of any underlying network connections (or lack thereof).

In a connection oriented environment the MMS Initiate service is used to signal to the lower layersthat a connection must be established. The Initiate service request is carried by the network throughthe layers as each layer goes through its connection establishment procedure until the Initiate indica-tion is received by the called node. The connection does not exist until after all the layers in both no-des have completed their connection establishment procedures and the calling node has received theInitiate confirmation. Because of this, the association and the connection occursimultaneously in a connection oriented environment.

In a connectionless environment, it is not strictly necessary to send the Initiate request before two no-des can actually communicate. In an environment where the Initiate service request is not used beforeother service requests are issued by a MMS client to a VMD, each application must have all the

146

knowledge regarding the other application's exchanged and negotiated parameters via some localmeans (e.g. a configuration file). This foreknowledge of the other MMS application's restrictions isthe application association from a MMS perspective. Whether an Initiate service request is used ornot, application associations between two MMS applications must exist before communications cantake place. In some connectionless environment such as MiniMAP, MMS nodes still use the Initiateservice to establish the application association before communicating.

Context Management Services

- Initiate. This service is used to exchange and negotiate the parameters required for two MMS appli-cations to have an application association.

- Conclude. This service is used by a client to request that a previously existing application associa-tion be terminated in a graceful manner. The conclude service allows the server to declineto terminate the association due to ongoing activities such as a download sequence or filetransfer.

- Abort. This service is used to terminate an application association in an ungraceful way. Becausethe server does not have the opportunity to decline an abort, an abort may result in the lossof data. Although the MMS standard does not provide any protocol for an Abort service,most MMS implementations use other network services for providing this service.

- Cancel. This service is used by a client to cancel an outstanding MMS service request (e.g. Take-Control) that has not yet been responded to by the server.

- Reject. This service is used by either the client or server to notify the other MMS application that ithad received an unsupported service request or a message that was not properly encoded.

FOR MORE INFORMATION PLEASE CONTACT THE AUTHOR AT:

Ralph MackiewiczSISCO, Inc.6605 19-1/2 Mile RoadStelring Heights, MI 48314 USAT: +810-254-0020F: +810-254-0053E: ralph@sisconet.com (company) 75776.1400@compuserve.com (personal)

ANEXO C.

Resumen de los Comandos Aceptados por las Máquinas E. C. S. del Centro Co-

lombo-Italiano Americo Vespucci en el SENA

Códigos GG00 Desplazamiento en marcha rápidaG01 Interpolación lineal, dim. medioG02 Interpolación circular, sentido horarioG03 Interpolación circular, sentido antihorarioG04 Parada temporizadaG05 Parada suspensiva

G08/09 Aceleración/desaceleraciónG10 Interpolación lineal, dimensión grandeG11 Interpolación lineal, dimensión pequeña

G13-15 Elección de ejesG17-19 Elección de planos

G20 Rotación AutomáticaG22 Posicionamiento con desaceleración y paradoG33 Roscado constanteG38 Cambio de herramienta, auto inclusoG39 Cambio de herramienta, auto exclusoG40 Anulación de la corrección de herramienta

G41-44 Modo interpolación motociclista, corrección de la herramientaG61 Macro de repetición de partes de programaciónG62 Macro para repetición de ciclos fijosG63 Macro de roscadoG64 Macro de desbaste cuadriláteroG66 Macro de desbaste generalizadoG72 Posicionamiento en rápidoG74 Posicionamiento en maquinado

148

G78 Inicio del ciclo de medidaG79 Final del ciclo de medidaG80 Anulación del ciclo fijoG81 TaladradoG83 Taladrado profundo con salida

G83 04 Taladrado profundo con roturaG84 MachoG85 AlezadoG94 Velocidad de avance cte.G95 Velocidad de rotación constanteG96 Velocidad de corte constante

Códigos MM00 Parada de programaM01 Parada opcionalM02 Fin de programaM03 Rotación del mandril en sentido horarioM04 Rotación del mandril en sentido antihorarioM07 Refrigerante 1M08 Refrigerante 2M09 Apagar refrigerantesM13 M8 + M3M14 M8 + M4M19 Rotación del mandril por gradosM30 Fin del Programa

M40-44 Gamas de velocidadM80 Suspensión de ciclos fijos