ARQUITECTURA

William Barrios Salcedo williambarrios@hotmail.com Carrera 19 No 21-50 Santaf de Bo ot!" Colombia

Resumen
Aqu se define y describe la arquitectura propuesta para un sistema de manufactura orientado a objetos realizado por el Manufacturing Domain Task Force (Mfg DTF) del consorcio bject Management !roup ( M!)" #ste documento define el t$rmino arquitectura% presenta &arios aspectos relacionados con la arquitectura propuesta y finalmente se dan tres ejemplos de arquitectura e'istentes para los sistemas de manufactura"

(alabras cla&e (key)ords)* Arquitectura, Arquitectura de aplicacin, Plataforma, Sistemas de aruitectura, SEMATECH, CIM SA, M!E, STEP"

I"

Introduccin

#l Mfg DTF creado en enero de +,,- tiene como misi.n alentar la aparici.n a un costo razonable% oportuna y comercialmente disponible e interoperable de los componentes de soft)are en el campo de la manufactura a tra&$s de la tecnologa / 01A" 2as acti&idades del Mfg DTF intenta dirigir sus esfuerzos en las 3reas relacionadas con todo el ciclo de &ida de los productos desde el desarrollo% a tra&$s de la producci.n y m3s all3 del soporte y la re4manufacturaci.n" (ara entender bien lo que se propone este grupo 5ay que comprender primero los problemas que enfrenta la manufactura actualmente" #n primer lugar% las arquitecturas de los sistemas de manufactura se 5an caracterizado por ser infle'ibles% centralizadas y monolticas% dic5os dise6os las &ol&ieron incapaces de responder r3pidamente a los cambios en algunos aspectos como definici.n de procesos% las ordenes de los clientes% in&entarios y dise6os de productos" Adicionalmente presenta otras dificultades como el flujo de informaci.n que debe ocurrir en tiempo real y conflictos de integraci.n como por ejemplo entre 5ombre y m3quina" /omo puede comprenderse el Mfg DTF colabora en el desarrollo de las tecnologas orientadas a objetos (meta final del M!) que puedan soportar aplicaciones distribuidas e

interoperables para los requerimientos de la industria% pudiendo solucionar los problemas anteriormente e'puestos" 2a arquitectura presentada para los sistemas de manufactura es un punto de referencia com7n para todas las acti&idades futuras de este grupo"

II"

#efiniciones

8na arquitectura% es una estructura% unificaci.n o forma co5erente% o un arreglo ordenado% sin embargo% se define para los prop.sitos de este documento como la unificaci.n o forma co5erente de un sistema computacional de manufactura integrada" 8na arquitectura orientada a objetos es simplemente una que se describe en t$rminos de objetos% clases% atributos% ser&icios% etc" 8n sistema de manufactura es un sistema computacional el cual proporciona soporte a la empresa de manufactura"

III" $a arquitectura
2a siguiente figura representa el modelo de ni&el superior propuesto para la arquitectura de un sistema de manufactura orientado a objetos*

ARQUITECTURA #E AP$ICACI %

P$ATA& RMA #E AP$ICACI %

SISTEMAS #E ARQUITECTURA #ste modelo en particular es muy abstracto y de alto ni&el" 0equerimientos especficos de manufactura no pueden ser e'trados de $l" #n realidad este modelo es aplicable a la mayora de sistemas computacionales y no solamente a los sistemas de manufactura

orientados a objetos" 9o obstante% de esta forma se establece se establece el conte'to para una discusi.n apropiada y se identifican las 3reas de trabajo para el Manufacturing DTF"

A" $a arquitectura de aplicacin"

2a arquitectura de aplicaci.n es un modelo de polticas y procesos de negocios que un sistema intenta lle&ar a cabo" 8na arquitectura de aplicaci.n no necesariamente incluye los mecanismos para desarrollar las polticas y los procesos" #n realidad no es una obligaci.n que una arquitectura de aplicaci.n sea implementada en un sistema computacional" la arquitectura de aplicaci.n puede ser implementada como un conjunto polticas de operaci.n y procedimientos los cuales son realizados por 5umanos" #n t$rminos de sistemas de manufactura% la arquitectura de aplicaci.n es un completo% consistente% conciso y co5erente modelo de una empresa de manufactura" #sta arquitectura debe direccionar las 3reas de procesos de negocios ya identificadas y que sin listadas a continuaci.n para recordarlas* Mercadeo y soporte de producto" Dise6o del producto (laneaci.n de la producci.n peraciones de producci.n Distribuci.n y logstica !esti.n de negocios !esti.n de la calidad

2as especificaciones de estos procesos deben ser muc5o m3s detalladas para proporcionar un modelo de una empresa de manufactura con las caractersticas mencionadas" 2a arquitectura de aplicaci.n tambi$n debe ser descrita en t$rminos de objetos% clases% atributos% ser&icios% etc" #l Manufacturing DTF 5a ya identificado los siguientes resultados relacionados con esta secci.n de la arquitectura* 9o e'iste un modelo semejante% elaborado completamente% disponible a ning7n precio" #l manufacturing DTF debe construir por lo tanto la mayor parte sino todo el modelo el mismo% o en colaboraci.n con otros grupos del M!" /ada manufactura actualmente in&olucrada puede tener diferentes polticas o procesos de negocios" #sto causa el dilema de que la arquitectura de aplicaci.n debe

ser bastante abstracta para ser ampliamente aplicable y a la &ez bastante especfica para proporcionar bases firmes para la definici.n de la plataforma de aplicaci.n" 2a moti&aci.n de los interesados en participar con la construir un modelo completamente elaborado de la empresa manufacturera debe ser del Manufacturing DTF ni de la M!" Algunos conceptos de la arquitectura de aplicaci.n son especficos de un 3rea en particular" (or ejemplo% cuando se tiene una clase que representa a los clientes a tra&$s de un reporte% puede ser especifica del 3rea de mercadeo y soporte de producto% mientras que una clase representando un &ector de tensi.n de un elemento finito en un an3lisis estructural puede ser especfico del 3rea de :ngeniera" M3s importante% sin embargo es que algunos de los conceptos est3n fraccionados a tra&$s de m7ltiples 3reas% como son parte% listado de materiales y estaci.n de trabajo" #sto impone la necesidad de ser e'tremadamente cuidadosos en la integraci.n de las especificaciones de estas 3reas" 2a arquitectura de aplicaci.n puede imponer requerimientos en el an3lisis y dise6o de la fuerza de tareas para proporcionar m$todos de an3lisis suficientemente robustos para capturar las caractersticas m3s importantes de los procesos y polticas de negocios de los sistemas de manufactura"

'" Sistemas de arquitectura"

2os sistemas de arquitectura son un modelo de un mecanismo de automatizaci.n" #ste puede ser establecido sin obser&ar las m7ltiples potenciales arquitectura de aplicaci.n que $l puede soportar" Aunque 5ay muc5as alternati&as de sistemas de arquitectura 7tiles% el modelo seleccionado por el Manufacturing DTF es la Arquitectura para la !esti.n de bjetos ( MA) del M!" (" Componentes del MA

#n un alto ni&el el MA contiene las 3reas descritas en su gua ; M! ,<d= e incluye los siguientes componentes* / 01A% /ommon bject 0equest 1roker Arc5itecture% / 01Aser&ices% pre&iamente conocido como bject >er&ices% / 01A facilities% pre&iamente /ommon Facilities% Aplication bjects"

)" Potenciales ampliaciones para la manufactura #l manufacturing DTF tiene ya identificados los siguientes resultados relacionados con las interfaces :D2 y el modelo de sistemas de arquitectura adoptados por el M!* 2as especificaciones de tecnologa e'istentes M! pueden no ofrecer suficientes ser&icios que permitan la automatizaci.n eficiente y econ.mica del modelo de empresa manufacturera" Algunas de las ya probadas tecnologas robustas capaces de soportar los requerimientos de la manufactura no tienen interfaces a objetos e igualmente &iolan los principios b3sicos de la apro'imaci.n orientada a objetos al separar los datos de las operaciones" 8na re&isi.n preliminar de las especificaciones e'istes de / 01Aser&ice y / 01Afacilities re&elan la necesidad del estudio de dic5as especificaciones para 5acerlas compatibles con las necesidades de la manufactura" (ara un mayor detalle un estudio puede ser necesario% sin embargo% a continuaci.n aparece un listado inicial*

2a especificaci.n e*ternali+ation ser,ice puede ser re&isada para &alidar como el estado de los objetos es pro&edo dentro del sistema de manufactura" 2a especificaci.n namin- ser,ice puede ser re&isada para asegurarse que $sta soporta la ruta de manufactura de las entidades identificadas" #l futuro lo--in- ser,ice puede ser re&isado para asegurarse que este soporta los tipos de seguimiento de inspecci.n necesario en la manufactura" 2a aplicabilidad del transaction ser,ice debe ser re&isado" 2a capacidad del securit. ser,ice para soportar la autenticidad de m7ltiples y serializados usuarios del mismo objeto o facilidad debe ser re&isada" 8n s.nc/roni+ation ser,ice entre datos redundantes puede ser requerido por razones de ejecuci.n% especialmente dentro del conte'to de la empresa &irtual" 8n /eart0eat ser,ice puede ser requerido para 5acer posible el monitoreo del estado de las acti&idades de componentes crticos en el sistema" #l 12 pen S.stem Mana-ement propuesto puede ser re&isado" 2a especificaci.n e'istente del E,ent %otification Ser,ice debe ser e&aluada para asegurarse que el paradigma publicidad?subscripci.n promo&ido por el M! satisface los requerimientos de la manufactura" #l futuro Collections Mana-ement Ser,ice y Quer. Ser,ice deben ser estudiados para asegurarse que la ejecuci.n de operaciones en colecciones% y la

consulta de miembros de colecciones satisface los requerimientos de la manufactura"

Rule Mane-ement and 3or4flo5 Mana-ement deben ser estudiados para determinar como la noci.n de trabajo puede ser soportada dentro de las empresas de manufactura" tros futuros / 01Aser&ices deben ser &igilados incluyendo el Arc/i,e Ser,ice% Confi-uration Mana-ement% $ife C.cle Ser,ices y Starup and Reco,er. Ser,ices" Calidad del ser,icio

6"

2a calidad del ser&icio consiste en &arias propiedades o caractersticas que un ser&icio puede ofrecer en diferentes ni&eles% las cuales se &uel&en factores de discernimiento en la selecci.n de una especificaci.n o de una implementaci.n" (ara soportar las necesidades de manufactura% ser&icios de objetos% facilidades de objetos y aplicaci.n de objetos el sistema de arquitectura debe ser seleccionado y medido de acuerdo a las mnimas calidades de ser&icio siguientes* Funcionamiento 4 n7mero de transacciones o mensajes por segundo% posibilidad de responder en tiempo real%""" /onfiabilidad 4 significa tiempo en fallar% significa tiempo en reparar%""" #scalabilidad 4 n7mero de sistemas% objetos% instancias%""" /onsumo de recursos 4 cantidad de memoria y espacio de disco requerido para soportar los ser&icios de la facilidad"

C" Plataforma de aplicacin"

Dic5o simplemente% una plataforma de trabajo es un reusable" 8na plataforma de trabajo pude ser considerada como un esqueleto% un dise6o muy general de la aplicaci.n particular en un 3rea" 8na plataforma de trabajo orientada a objetos es una colecci.n de reusables% abstracciones de colaboraci.n de objetos% ser&icios y protocolos" 2as relaciones son definidas entre estas abstracciones para proporcionar un dise6o total" 8na plataforma de trabajo proporciona la infraestructura de soft)are que permite la composici.n de clases de plataformas de trabajo e'istentes" 2a utilizaci.n ocurre cuando una clase es creada como una subclase de una plataforma de clases" 8na plataforma proporciona un ambiente com7n para la integraci.n de aplicaciones y la partici.n de la informaci.n en el 3rea de un problema dado" 2os protocolos de la plataforma son una plataforma independiente% y deben estar en un lenguaje independiente en lo posible% esto permite su interoperabilidad y portabilidad a tra&$s de sistemas 5eterog$neos" :dealmente solo una parte de la plataforma de implementaci.n es plataforma dependiente"

8na de las principales metas del Manufacturing DTF es la de mantener la plataforma de aplicaci.n de manufactura definida (en el M! :D2) la cual puede ser&ir como una especificaci.n de tecnologa recomendada para la integraci.n automatizada de los sistemas de manufactura" #l Manufacturing DTF 5a ya identificado las siguientes tareas relacionadas con esta secci.n de la arquitectura* 2a di&isi.n de los conceptos de arquitectura de aplicaci.n a tra&$s de m7ltiples 3reas puede probablemente implicar la misma di&isi.n de la plataforma de aplicaci.n" #sto no es necesariamente corresponde uno a uno entre los conceptos del modelo de empresas de manufactura y 3reas de aplicaci.n% y la partici.n de la plataforma de aplicaci.n 2a enorme in&ersi.n requerida por los pro&eedores para reconstruir una aplicaci.n de manufactura e'istente dentro de la forma definida por una plataforma de aplicaci.n introduce una significati&a barrera para su &iabilidad comercial" 2a plataforma de aplicaci.n puede imponer requerimientos en el an3lisis y dise6o de la fuerza de tareas para proporcionar m$todos de dise6o que sean suficientemente robustos para capturar estas importantes caractersticas" (ara promo&er la adopci.n de una plataforma base entre los pro&eedores de sistemas de manufactura y la comunidad de usuarios puede implicar emprender por parte del DTF el desarrollo de un cuerpo significati&o de material educacional dimensionado para este auditorio especfico"

I!" E7emplos de arquitecturas e*istentes

A" El modelo de manufactura de SEMATECH
>#MAT#/@ (Tecnologa para manufactura de semiconductores) es un consorcio de los productores de semiconductores en #stados 8nidos% est$ se 5a caracterizado con el mejoramiento en los procesos y equipos de manufactura para semiconductores% una de las cla&es del $'ito de >#MAT#/@ es el desarrollo de mejores sistemas de manufactura% as 5a construido una plataforma de aplicaci.n que esta dirigido a proporcionar el mnimo conjunto de abstracciones de objetos en manufactura necesarias para construir compatibles e instalables aplicaciones para las facilidades de la manufactura de semiconductores" 2os siguientes resultados se 5an alcanzado respecto a esta arquitectura"

2a arquitectura de aplicaci.n tras la plataforma de aplicaci.n de >#MAT#/@ no esta formalmente especificada en forma completa% consistente% concisa y co5erente" #n particular% las aplicaciones pueden solamente concordar si las sem3nticas y &arios componentes son compatibles" #sto es difcil de determinar donde la lnea de abstracci.n es mezclada entre la generalizaci.n y la especializaci.n" #ste es un problema gen$rico de la definici.n de una plataforma y no especfico de >#MAT#/@" Aunque >#MAT#/@ 5a definido su plataforma en t$rminos del MA% este 5a declarado que la implementaci.n de la plataforma de ser&icios no es necesariamente orientada a objetos"

'" CIM SA
/:M >A (Arquitectura de sistemas abiertos para la manufactura integrada por computador) es el resultado de un fuerte consorcio auspiciado por el (rograma #strat$gico #uropeo para Tecnologa de :nformaci.n" 2a principal meta de /:M >A es permitir la integraci.n de las empresas en &ista del constante cambio y e&oluci.n de las operaciones en las empresas debido a fuerzas e'ternas e internas" /:M >A proporciona una Arquitectura de >istema Abierto que describe la realidad mundial de las empresas de manufactura" #stos modelos descripti&os permiten al usuario final la planeaci.n% dise6o% control% monitoreo% optimizaci.n de los sistemas empresariales dentro de la necesidad de conocimiento especializado de tecnologa de informaci.n" /:M >A proporciona los siguientes tres conceptos interrelacionados para lograr estas metas* (" Plataforma de Modelamiento CIM SA (roporciona una Arquitectura de 0eferencia para modelar todos los ambientes industriales por el cual las arquitecturas para industrias de manufactura especificas pueden ser deri&adas" 2a Arquitectura de 0eferencia es un conjunto de bloques construidos para describir los procesos de la empresa% su funcionamiento y comportamiento din3mico% informaci.n disponible y usada% recursos disponibles y usados% e interrelaciones de informaci.n y recursos" #ste proporciona las definiciones de los bloques construidos en un modelo de lenguaje orientado al usuario que permite la representaci.n com7n y la comprensi.n de los modelos empresariales" (ermite al usuario trabajar con un subconjunto del modelo % a tra&$s de las &istas del modelo por el ocultamiento del todo y muestra solamente los aspectos seleccionados"

)" Am0ientes CIM SA (ara mantener una clara separaci.n entre las tareas asociadas con el ciclo de &ida de los productos y las tareas asociadas con el ciclo de &ida del sistema empresarial% /:M >A proporciona dos ambientes de ejecuci.n mutuamente independientes* #l Ambiente de peraciones de la #mpresa y el Ambiente de :ngeniera de la #mpresa"

6" Infraestructura de Inte-racin CIM SA #ste proporciona los mecanismos para integrar componentes 5eterog$neos y tambi$n ser el medio para el control de los procesos del ciclo de &ida del producto y de la empresa" (roporciona un conjunto de ser&icios dirigidos a la ejecuci.n de los modelos conforme a los conceptos de modelamiento de /:M >A" /:M >A estructura las operaciones de la empresa dentro de un conjunto de procesos inter4operando para el intercambio de consultas y resultados"

C" Arquitectura de las Empresas de Manufactura !irtuales 8M!E9

2a Arquitectura de las MA# fue definida por el consorcio 9:::( como un mecanismo para proporcionar un ambiente de colaboraci.n empresarial el cual permite a clientes% pro&eedores y a cada competidor construir r3pidamente una compa6a &irtual para fabricar un producto especfico" 9:::( esta definiendo los protocolos para la arquitectura MA#% con la que se facilita la r3pida composici.n y descomposici.n de una empresa &irtual" MA# esta soportado por el M!Bs/ 01Aser&ices y / 01Afacilities" #sto consiste en un mercado &ertical de facilidades para los ser&icios de la Manufactura :ntegrada por /omputador (/:M)% una colecci.n de ser&icios que soporta la distribuci.n de productos usando el est3ndar >T#( y un n7mero de ser&icios que pueden construirse sobre el /:M y el >T#( para 5acer posible las empresas &irtuales"

A" Ser,icios de STEP

MA# /ontienen tres ni&eles de ser&icios >T#(* #l ni&el + proporciona la ubicaci.n transparente para el intercambio de arc5i&os >T#( #l ni&el C soporta el dise6o de alto ni&el% datos de objeto del producto acti&o" #l contenido de los datos para estos objetos son definidos en lenguaje #D(0#>> y las operaciones son descritas en M!Bs :D2"

#l ni&el E encapsula el #st3ndar de Acceso de :nterfaces de Datos (>DA:) del est3ndar >T#( con las :nterfaces :D2"

'"

tros ser,icios . facilidades M!E

tros ser&icios incluidos con la arquitectura MA# son* MA# Data /onfiguration Management >er&ice 4 estos ser&icios soportan la configuraci.n y almacenamiento de los datos del producto" Agentes ((ersonal asistente% agentes de grupo colaborador% y agentes de informaci.n especfica) MA# >er&icios de transporte" MA# >er&icios de internet MA# >er&icio de >esi.n% un ser&icio de gesti.n de usuarios trabajando en el ambiente durante y entre las cone'iones de los ser&icios de las MA#" MA# !estor de aplicaci.n% un ser&icio que gestiona el registro e in&ocaci.n de 5erramientas y aplicaciones" #l MA# monitor% un ser&icio que robustece la consistencia global y e'actitud de las operaciones de las MA# aplicando reglas y restricciones globales" #2 MA# >istema de gesti.n de la 1ase de /onocimiento (F1M>)% lo cual se necesit. para el control de operaciones de las MA#% incluyendo la gesti.n y facilidades de consulta para la base de conocimiento"

!"

Conclusiones
2a arquitectura planteada es muy interesante cabe decir que aunque como dice el mismo te'to% es muy abstracta% tambi$n es un buen punto de partida para el trabajo futuro ya que son muc5os los elementos que se pueden deri&ar de ella" 2as e'periencias tomadas de otras arquitecturas en manufactura reflejan que cuando se tiene en cuanta el trabajo desarrollado por otros se identifican f3cilmente nue&os rumbos a tomar% dificultades que se deben afrontar y errores por e&itar" (arece ser que el modelo planteado puede ser una soluci.n efecti&a a las necesidades de las empresas manufactureras y solo en el futuro pr.'imo se &erificar3 si es una opci.n importante a considerar"

!I" Referencias

; M!% +,,-=

bject Management !roup" GManufacturing #nterprise >ystemsG" Febrero , de +,,-"