Diseño de Componentes Software - PDF

ESCUELA TCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIN
UNIVERSIDAD DE CANTABRIA
Trabajo Fin de Carrera
DISEO DE COMPONENTES SOFTWARE DE TIEMPO REAL
Para acceder al Ttulo de
INGENIERO DE TELECOMUNICACIN
Pedro Javier Espeso Martnez Diciembre - 2002
ndice
I. TECNOLOGA DE PROGRAMACIN BASADA EN COMPONENTES ................................. I.1. Componentes software ...................................................................................................... I.2. Entornos normalizados de desarrollo de componentes software ...................................... I.2.1. EJB (Enterprise Java Bean) ................................................................................ I.2.2. COM+ (Component Object Model) ................................................................... I.2.3. CORBA (Common Object Request Broker Architecture) ................................. I.3. Metodologa de diseo de aplicaciones basadas en componentes .................................... I.4. Componentes software de tiempo real .............................................................................. I.5. Entorno MAST de modelado , diseo y anlisis de sistemas de tiempo real ................... I.6. Perfil CBSE_MAST ......................................................................................................... I.7. Objetivos del proyecto ...................................................................................................... II. ESPECIFICACIN Y DISEO FUNCIONAL DE COMPONENTES ....................................... II.1. Componentes e interfaces ................................................................................................ II.2. Especificacin de una interfaz ......................................................................................... II.3. Especificacin de componentes ....................................................................................... II.4. Proceso de automatizacin de la gestin de componentes ..............................................
1 1 4 4 5 7 9 11 13 15 22 26 26 28 35 42
III. MODELO DE TIEMPO REAL DE LOS COMPONENTES ....................................................... 44 III.1. Modelo de tiempo real de una aplicacin basada en componentes ............................... 44 III.2. Descripcin de la plataforma WINDOWS NT .............................................................. 45 III.3. Modelo de tiempo real de la plataforma WINDOWS NT .............................................. 48 III.4. Estimacin de los valores de los parmetros del modelo de la plataforma .................... 53 III.4.1. FP_Processor .................................................................................................... 53 III.4.2. Interferences y Ticker ..................................................................................... 55 III.5. Cdigo MAST-File del componente NT_Processor_mdl_1 ......................................... 60 III.6. Modelo de tiempo real del componente C_IG_DT3153 ................................................ 64 III.7. Cdigo Mast-File del componente C_IG_DT3153 ........................................................ 72 IV. DEMOSTRADOR DE UN SISTEMA DE TIEMPO REAL BASADO EN COMPONENTES 76 IV.1. Control por computador de una maqueta de trenes utilizando visin artificial .............. 76 IV.2. Funcionalidad de la aplicacin ...................................................................................... 80 IV.3. Arquitectura software del demostrador ...........................................................................80 IV.4. Modelo de los componentes lgicos de la aplicacin .................................................... 86 IV.4.1. Modelo MAST de la clase Railway ................................................................. 86 IV.4.2. Modelo MAST de la clase Train ..................................................................... 92 IV.5. Modelo de las situaciones de tiempo real de la aplicacin ............................................ 96 IV.5.1. Configuracin de la RT_Situation .................................................................. 97 IV.5.2. Declaracin de las transacciones .................................................................... 100 IV.6. Anlisis de tiempo real de la aplicacin ........................................................................ 102 V. CONCLUSIONES .......................................................................................................................... 104 VI. REFERENCIAS ............................................................................................................................ 105 A. ESPECIFICACIN DE LOS COMPONENTES .......................................................................... 107 A.1. Componente C_IG_DT3153 ............................................................................................ 107 A.2. Componente C_Ada_Vision ............................................................................................ 108 A.3. Componente C_PCI9111 ................................................................................................. 113 B. DISEO Y CABLEADO DE LA TARJETA INTERMEDIA DE RELS ................................. 116
tecnologa de programacin basada en componentes
diciembre 2002
I. TECNOLOGA DE PROGRAMACIN BASADA EN COMPONENTES

I.1. Componentes software El objetivo de la tecnologa de componentes software es construir aplicaciones complejas mediante ensamblado de mdulos ( componentes ) que han sido previamente diseados por otras personas a fin de ser reusados en mltiples aplicaciones [1]. La ingeniera de programacin que sigue esta estrategia de diseo se la conoce por el acrnimo CBSE1 y es actualmente una de las ms prometedoras para incrementar la calidad del software, abreviar los tiempos de acceso al mercado y gestionar el contnuo incremento de su complejidad. La arquitectura software de una aplicacin basada en componentes consiste en uno o un nmero pequeo de componentes especficos de la aplicacin ( que se disean especficamente para ella ), que hacen uso de otros muchos componentes prefabricados que se ensamblan entre s para proporcionar los servicios que se necesitan en la aplicacin [2].
E n to rn o n o rm a liza d o d e co m p o n en tes
In terfaz In terfaz
C o m p o n e n te C
C o m p o n e n te A
In terfaz In terfaz
A p lic a ci n
In terfaz
C o m p o n e n te D
C o m p o n e n te B
In terfaz
En la tecnologa de componentes la interfaz constituye el elemento bsico de interconectividad. Cada componente debe describir de forma completa las interfaces que ofrece, as como las interfaces que requiere para su operacin. Y debe operar correctamente con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz. Caractersticas muy relevantes de la tecnologa de programacin basada en componentes son la modularidad, la reusabilidad y componibilidad y en todos ellos coincide con la tecnologa orientada a objetos [3] de la que se puede considerar una evolucin. Sin embargo, en la tecnologa basada en componentes tambin se requiere robustez ya que los componentes han de
1. Component Based Software Engineering.
diciembre 2002
operar en entornos mucho mas heterogneos y diversos. Principios bsicos compartidos por las tecnologas CBSE y OO1 son: Integracin de datos y funciones: un objeto software consiste en una serie de valores (estado) y las funciones que procesan esos datos. Encapsulamiento: el cliente2 de un objeto software no tiene conocimiento de como son almacenados los valores en el interior del objeto , ni como se implementan las funciones. Identidad: cada objeto software tiene una identidad nica. Polimorfismo: las interfaces se describen por separado de la implementacin , de modo que un cdigo que requiera una determinada interfaz puede utilizar cualquier componente / objeto que implemente dicha interfaz. Esto permite una gran flexibilidad en el diseo de aplicaciones. De hecho, el desarrollo de software basado componentes (CBSE) es la evolucin natural de la ingeniera software para mejorar la calidad, disminuir los tiempos de desarrollo y gestionar la creciente complejidad de los sistemas.
Tecn o lo g a O rien ta d a a O b jeto s
1 9 6 7 ..
1 9 8 9 ..
1 9 9 5 .. E v o lu c i n
S m allTalk
C++
RM I
E JB
P ro g ram a ci n O rien ta d a a O b jeto s

Ja v a A d a'9 5
Tecn o lo g ad e O b jeto s D istrib u id o s

CO RBA DCOM
C o m p o n e n tes
M T S /C O M + In teg ra serv ic io s. M ltip le esp acio d e d ireccio n e s E m p aq u etam ien to n o rm aliza d o
S o lo o p e ra d en tro d el len g u aje d e p ro g ram ac in U n esp a cio d e d ireccio n es
In d epen d ien te d el le n g u aje M ltip le esp acio d irecc io n es N o In teg ra se rv icio s
Los componentes presentan una serie de ventajas frente a las tecnologas orientadas a objetos: Componentes desarrollados con diferentes lenguajes de programacin son compatibles y pueden ejecutarse dentro de una misma aplicacin. Los componentes puede tener su propio estado persistente ( en una base de datos , en el sistema de ficheros del disco , ... ).
1. Object Oriented. 2. En el sentido de usuario o consumidor.
diciembre 2002
Las funciones de la interfaz no tiene que estar necesariamente implementadas utilizando tcnicas orientadas a objeto. Los componentes requieren mecanismos de empaquetamiento que deben ser ms robustos que los de los objetos. Normalmente ( por ejemplo en COM+ y EJB1 ) las instancias de componentes se instalan en un contenedor , que les proporciona contexto local. Mientras el componente aporta la simplemente la funcionalidad ( business logic ), es el contenedor quien se encarga de mapear las estructuras de datos desde el espacio lgico hasta el espacio fsico de memoria en la mquina sobre la que se est ejecutando. Los componentes integran servicios completos , lo que minimiza las interconexiones entre mdulos. La funcionalidad de un componente software se ofrece a travs de un conjunto de interfaces. Cada interfaz es una unidad funcional independiente que representa dentro de un dominio de aplicacin un conjunto de servicios en los que se puede basar una aplicacin sin tener que hacer referencia al componente que los soporta. Por ello, la informacin completa sobre los servicios que ofrece una interfaz debe formar parte de ella y describir tanto la funcionalidad que ofrece en estados correctos como la que ofrece bajo situacin de fallo. La tecnologa de componentes es habitual en otras ingenieras, y su xito se basa en:
P B L IC O PA R A E L U S U A R IO E spe cificaci n
- Q u e o fre c e a l q u e lo usa ? - Q u e re q u ie re d e l qu e u sa ?
P R IVA D O PA R A E L D IS E A D O R
A rq uitectu ra in te rna
- E stru c tu ra in te rn a - C o m p on ete s in te rn o s
Inte rfaz
- D o n d e, c o m o , a q u , se p u e de ac o p lar ?
E m pa qu eta m iento rob usto

- F c il e nsa m bla je . - F u n c io n am ie n to se g u ro .
C a ta log aci n esta nd ar

- O p c io ne s d e sustitu c i n . - M ltip les fu e n te s. - C o m o fu n cio na ? - D e q u e st h ec h o?
Servicio s de va lida cin

- S e rv ic io s p a ra v e rific ar su s presta c io n e s e n e l e n to rn o d e trab a jo
Una especificacin completa hacia el usuario. Tanto de los servicios que ofrece como de los servicios externos que requiere para operar correctamente. Mltiples interfaces en los que se especifican los diferentes modos de acoplo que admite, as como los mecanismos de acoplo y sus compatibilidades.
1. Entornos normalizados descritos posteriormente en este mismo texto.
diciembre 2002
Un empaquetamiento robusto, de fcil manipulacin y que garantice un funcionamiento fiable e independiente de otros componente que operen junto a l. Una catalogacin estndar que simplifique su localizacin, permita su sustitucin por otros equivalentes y que facilite el desarrollo de mltiples fuentes que garantice el soporte del producto. Debe ofrecer mecanismos de validacin en el entorno de trabajo del usuario y capacidad de configuracin y sintonizacin de acuerdo con las necesidades de la aplicacin. La arquitectura interna, las peculiaridades de su implementacin y la tecnologa que lo soporta, slo debe interesar al diseador del componente y a los que sean responsables de su mantenimiento y evolucin. Como reflexin final, podemos concluir que la ventaja principal del diseo basado en componentes no es la reutilizacin del software (que tambin), sino la posibilidad de sustituir un componente por otro que implemente las interfaces utilizadas en el sistema. De este modo mejoramos la calidad del sistema completo sin necesidad de redisearlo.
I.2. Entornos normalizados de desarrollo de componentes software Para que una arquitectura de componentes pueda operar es necesario disponer de un entorno normalizado que proporcione soporte a los mecanismos con que se comunican las interfaces. Existen varios entornos de soporte de componente creados para uso interno de empresas, pero los ms conocidos ( actualmente comercializados ) son:
I.2.1. EJB (Enterprise Java Bean) Tecnologa desarrollada por Sun Microsystems. Un Java Bean es un componente utilizado en un entorno Java que permite agrupar funcionalidades que pueden ser utilizadas por mltiples aplicaciones. Un Enterprise Java Bean tambin agrupa servicios funcionales utilizables por aplicaciones, sin embargo, a diferencia del anterior el EJB implica la existencia de un entorno de ejecucin conocido como EJB Container. As, mientras que un Java Bean requiere ser integrado con otros componentes para que sea funcional, un EJB puede ser activado y usado con solo ser incluido en un EJB Container. Algunas ventajas de los EJBs son: Divisin de trabajo: el EJB Container es el encargado de ofrecer los servicios , de modo que el diseador del componente se centra exclusivamente en el desarrollo de la funcionalidad principal (business logic). La interoperabilidad entre servicios y
diciembre 2002
componentes se define en las especificaciones correspondientes que forman parte del estndar J2EE1. Diversos vendedores: existen diversos vendedores tanto de EJB Containers , los cuales son incluidos en un servidor de aplicaciones Java , como de EJBs que resuelven algn tipo de lgica concreta. La compatibilidad est garantizada, y se puede ejecutar cualquier EJB en cualquier EJB Container, aunque ambos hayan sido desarrollados por distintas empresas proveedoras. Procedimientos remotos: el diseo de los EJB gira alrededor de la tecnologa RMI2, lo que permite la operacin en sistemas distribuidos. Diversos clientes: un EJB puede interactuar con una gran gama de clientes: Servlets, bases de datos , applets , sistemas ERP3, ... Por contra , tambin presenta algunos inconvenientes: Tiempo de desarrollo elevado: desarrollar un sistema con EJBs es sumamente complejo ; si bien para muchas empresas puede presentar una solucin ideal , para otras puede resultar un solucin sobrada debido a su elevado costo ( complejidad tiempo ). Conocimiento exhaustivo de Java: la tecnologa EJB es uno de los principales componentes de J2EE y por esta razn depende fuertemente de otras de sus partes: RMI , JNDI4 , JDBC5 , ...
I.2.2. COM+ (Component Object Model) Microsoft Component Object Model [4]. Los lenguajes de programacin clsicos fueron diseados para desarrollar aplicaciones secuenciales compuestas de mdulos, todos ellos codificados con un solo lenguaje. Sin embargo, hay situaciones en las que no es prctico restringirse al uso de un nico lenguaje. La tecnologa COM aborda la solucin a este problema proporcionando un sencillo, pero a la vez potente modelo para construir sistemas software a partir de la interaccin de objetos (componentes). COM define un estndar binario ( esto implica que es independiente del lenguaje de programacin ) para objetos y la intercomunicacin entre ellos. Toda comunicacin se realiza a travs de operaciones que son proporcionadas dentro de interfaces. El diseador invoca las operaciones que necesite directamente, incluso si el objeto destinatario est localizado en otro
1. Java 2 Platform Enterprise Edition. 2. (Remote Method Invocation) Invocacin Remota de Procedimientos. 3. (Enterprise Resource Planning) describe una serie de actividades de gestin empresarial soportadas por aplicaciones de tecnologa de informacin. 4. (Java Naming and Directory Interface) conjunto de aplicaciones API que actan como interfaz de mltiples servicios de directorio e identificacin. 5. (Java DataBase Conectivity) estndar que permite conexiones independientes entre bases de datos basadas en APIs SQL utilizando Java.
diciembre 2002
proceso o en otra mquina. De este modo, la combinacin de la tecnologa COM junto con las tcnicas de programacin orientada a objeto, nos ofrece una importante simplificacin en el proceso de desarrollo de aplicaciones informticas. Distintas herramientas han introducido particularidades propias para facilitar el desarrollo de aplicaciones basadas en COM. Por ejemplo, ATL1 dispone de un mecanismo basado en scripts para simplificar el registro de componentes. Visual Basic implementa un acceso sencillo a estructuras de datos a travs de controles. MTS2 proporciona mecanismos que permiten la escritura de cdigo escalable; esto quiere decir que el desarrollador del componente escribe cdigo asumiendo que un solo cliente accede al componente al tiempo, y es MTS quin se encarga de automatizar el proceso cuando varios clientes acceden simultneamente. Esta propiedad simplifica enormemente el desarrollo de sitemas distribuidos. En 1998 aparece la tecnologa COM+ como la evolucin natural de las tecnologas de componentes y sistemas distribuidos.
La tecnologa COM+ presenta varias ventajas respecto a su antecesora COM. En primer lugar, simplifica el desarrollo de los componentes ya que genera de forma automtica la implementacin de diversas interfaces (IUnknown, IDispatch, IConnectionPoint, ...) necesarias en COM para gestionar aspectos relativos al tiempo de vida del componente, contabilidad , referencias , ... Uno de los inconvenientes de COM era la complejidad de definir nuevas interfaces utilizando IDL3. Con COM+, las interfaces se definen usando lenguajes de programacin estndar: no se fuerza a aprender un nuevo lenguaje, API4 o forma de escribir cdigo.
1. 2. 3. 4. (Active Template Library) Biblioteca de plantilas C++ para el uso de componentes COM. Microsoft Transaction Server. Interface Definition Languaje. Application Programming Interface.
diciembre 2002
COM+ proporciona un modelo ms simple y robusto para registrar e instalar componentes. El mecanismo de registro permite reescribir la versin de una clase asociada a un paquete. Esto resuelve una de las cuestiones ms molestas de las aplicaciones basadas en componentes. Por ejemplo, supongamos que la aplicacin A utiliza la versin 1.0 del componente C y funciona correctamente. La aplicacin B instala la versin 2.0 del componente C y tambin funciona correctamente, pero la aplicacin A deja de hacerlo con la nueva versin de C. Con COM+, ambas versiones del componente se pueden usar simultneamente, la 1.0 para A y la 2.0 para B. COM+ presenta muchas otras ventajas respecto a COM en aspectos relativos a la gestin interna del componente, liberacin de memoria ( garbage collection ), accesos seguros, sistemas distribuidos , ... Adems, COM+ es compatible con COM, de modo que los antiguos componentes COM pueden ser usados junto con componentes COM+.
I.2.3. CORBA (Common Object Request Broker Architecture) Common Object Request Broker Architecture de OMG1[5]. CORBA es la solucin propuesta por el OMG para cubrir las necesidades de interoperabilidad entre los diversos productos hardware y software que nos ofrece el mercado hoy en da. CORBA 1.1 aparece en 1991 y en l se definen el IDL y la API que permiten la interaccin de objetos en modo cliente/servidor utilizando una implementacin especfica de un ORB2. En 1994 aparece CORBA 2.0, donde se define la interoperabilidad real entre ORBs de distintos fabricantes. En la figura de la siguiente pgina se muestra la arquitectura CORBA - ORB. La descripcin de los distintos elementos que la conforman es la siguiente: Object: entidad de programacin de CORBA compuesta de una identidad, una interface y una implementacin (tambin conocida como Servant ).
1. Object Management Group 2. Object Request Broker.
diciembre 2002
Servant: implementacin de un Object donde se definen las operaciones ofrecidas por una interfaz CORBA - IDL. Puede estar escrita en diversos lenguajes (C, C++, Java, Smalltalk, Ada, ...). Client: entidad de programacin que invoca una operacin sobre un Object. El acceso a los servicios del Object remoto es transparente para el usurio Client. Object Request Broker (ORB): mecanismo que proporciona una comunicacin transparente entre el Client y el Object. Esto hace que las solicitudes de Client sean aparentemente simples procedimientos locales desde su punto de vista. Cuando el Client invoca una operacin, el ORB es el responsable de localizar la implementacin del Object, trasladarle la peticin y devolver los resultados al Client. Internamente, un ORB puede utilizar diferentes protocolos de comunicacin, como por ejemplo IIOP1 o GIOP2 [6].
diciembre 2002
IDL Stubs / Skeletons : son el punto de conexin entre el Client / Object (respectivamente) y el ORB. La transformacin entre la definicin del CORBA IDL y el lenguaje de programacin utilizado es automtica a travs del compilador IDL. El uso del compilador reduce el peligro de aparicin de inconsistencias entre los Stubs del cliente y los Skeletons del servidor, e incrementa las posibilidades de optimizar la generacin automtica del cdigo. Dynamic Invocation Interface (DII): interface que permite al cliente acceder directamente a los mecanismos subyacentes de peticiones que ofrece un ORB. Las aplicaciones utilizan el DII para realizar peticiones dinmicamente sin necesidad de utilizar interfaces IDL (Stubs). A diferencia de los Stubs, el DII permite al Client efectuar llamadas no bloqueantes1 o unidireccionales2. Dynamic Skeleton Interface (DSI): es el anlogo al DII. El DSI permite a un ORB trasladar peticiones a un Object que no tiene conocimiento en tiempo de compilacin del tipo de Object que va a implementar. El Client que realiza la peticin no tiene porque saber si el ORB utiliza IDL Skeletons o DSI. Object Adapter: es el encargado de asociar los distintos Servants con el ORB. Pueden ser especializados para ciertos estilos de Servants, como por ejemplo OODB3 Object Adapters para objetos persistentes o Library Object Adapters para objetos locales (no remotos).
I.3. Metodologa de diseo de aplicaciones basadas en componentes El aspecto central del proceso de diseo de aplicaciones basadas en componentes es la gestin de la funcionalidad a travs de las especificaciones de las interfaces. Tras una evaluacin de algunos de los procesos de diseo basado en componentes [3][8][9][10], se ha adoptado el proceso RUP4 propuesto por por Cheesman [8]. En la figura se muestra un esquema a alto nivel de este proceso. Los bloques representan conjuntos de actividades que dan lugar a resultados tangibles, las flechas gruesas representan su secuenciacin y las flechas finas representan el flujo de elementos generados que transfieren informacin entre ellas. Si comparamos este diagrama con los propuestos en la metodologa RUP para la metodologa orientada a objetos, se comprueba que las actividades iniciales y finales de definicin de requerimientos, prueba y despliegue coinciden, mientras que difiere en que las fases centrales del proceso RUP (anlisis, diseo e implementacin de objetos) se han reemplazado por otras que representan la especificacin, aprovisionamiento y ensamblado de componentes. Los conjuntos de actividades que intervienen en el proceso son: Requerimientos: obtener una idea clara y concreta de los requerimientos que exige la aplicacin. Se genera un modelo conceptual general y un modelo de casos de uso.
1. 2. 1. 2. 3. 4. Internet Inter-ORB Protocol. General Inter-ORB Protocol. Operaciones de envo y recepcin distintas. Slo envo. Object Oriented DataBases. Rational Unified Process.
diciembre 2002
R e qu erim ien to s d e la a p lica ci n

M o delo de C asos d e U so
R eq u erim ien to s
M o delo de C asos d e U so M o d elo C on ceptua l Restriccio nes T cn ica s
Exp erien cia d isp onible C om p o nen tes
E sp ecifica ci n
A p ro visio n a m ie n to
Especifica cio nes de co m pon entes
E n sam b lad o
Ap licacion es
Test
Ap lic .
probadas
D es p lieg u e
Especificacin: consta de tres etapas. Primero, la identificacin de componentes donde se genera un conjunto inicial de interfaces y especificaciones de componentes conectados entre s en una primera aproximacin de la arquitectura. Segundo, la interaccin entre componentes donde se decide como los componentes van a trabajar de modo coordinado para conseguir la funcionalidad deseada. Tercero, la especificacin de componentes donde se definen las especificaciones concretas de cada uno de los componentes utilizados. Al final se han generado las especificaciones de los componentes. Aprovisionamiento: a partir de las especificaciones se implementa la funcionalidad de los componentes. Se generan los componentes completos. Ensamblado: se conectan los componentes unos con otros a travs de sus interfaces para lograr la funcionalidad requerida. Se generan las aplicaciones. Test: se comprueba el correcto funcionamiento de las aplicaciones. Se generan las aplicaciones probadas. Despliegue: se instalan las aplicaciones probadas en el entorno de trabajo donde van a llevar a cabo su funcionamiento. La secuenciacin de las actividades est representada por flechas bidireccionales. Esto quiere decir que el proceso de desarrollo es iterativo, y en un momento dado se puede volver a alguna etapa anterior para realizar modificaciones. De hecho, lo habitual es necesitar varias iteraciones para llegar a las versiones finales de los resultados generados. Los dos criterios bsicos por lo que este proceso se ha tomado como base de nuestro trabajo son su carcter neutro respecto del proceso de diseo lo que facilita las extensiones y su formulacin basada en UML (Unified Modeling Languaje) que lo hace compatible con las
10
diciembre 2002
0%
M odelo Conceptual M odelo de Casos de Uso Especificacin Com ponentes Com ponentes
% co m p le tad o
100 %
1 ite ra ci n
2 ite ra ci n
3 ite ra ci n
4 ite ra ci n
5 ite ra ci n
herramientas CASE (Computer Aided Software Engeneering) que ya utilizbamos (ROSE de Rational).
I.4. Componentes software de tiempo real Entendemos por sistemas de tiempo real aquellos en los que el correcto funcionamiento del sistema requiere el cumplimiento de plazos temporales [11]. Habitualmente los sistemas de tiempo real se utilizan para controlar o interactuar con un sistema fsico, y los requerimientos temporales vienen impuestos por el entorno. Como consecuencia de esto, el correcto funcionamiento de estos sistemas depende no slo de los resultados conseguidos a travs de la computacin de los datos, sino tambin de los instantes temporales en que se obtienen. Aunque la tecnologa de componentes es ya una realidad en muchos campos, como multimedia, interfaces grficas, etc., plantea problemas para su aplicacin en otros dominios como es el caso de los sistemas de tiempo real. Sin embargo, la necesidad de la tecnologa de componentes en sistemas de tiempo real est siendo manifestada por la industria de automatizacin, potencia y equipamiento elctrico, aviacin, automvil, etc... Empresas lderes en estos campos como ABB han implantado la tecnologa de componentes en sus productos, basndola en soluciones y especificaciones propias [12], lo cual le ha reportado ventajas en cuanto al mantenimiento y a la gestin de la evolucin de sus productos, pero ha supuesto muchos problemas a sus clientes que encuentran dificultades de compatibilidad de estos productos con aplicaciones desarrolladas por terceros. Cuando aplicamos CBSE en el desarrollo de sistemas de tiempo real uno de los problemas fundamentales es la reusabilidad de los componentes. El diseo de los componentes es mucho ms complejo ya que, en aplicaciones de tiempo real , han de colaborar unos con otros para cumplir las restricciones temporales. El uso de un determinado sistema operativo o una base de datos concreta no es siempre posible en sistemas de tiempo real, ya que muchos de estos elementos han sido diseados para optimizar su rendimiento, pero no para garantizar su predicibilidad temporal. Componentes comerciales como EJB ,CORBA o COM no pueden ser utilizados en sistemas de tiempo real precisamente por este motivo. En lneas generales podemos afirmar que el incremento de flexibilidad conlleva un decremento en la predicibilidad
11
diciembre 2002
temporal, de modo que es impensable (actualmente) obtener la flexibilidad que nos ofrecen los entornos comerciales mencionados en un modelo para sistemas de tiempo real. La propuesta que hacemos es modificar el proceso RUP1 para el diseo de componentes de tiempo real agregando a las especificaciones de los requerimientos de las aplicaciones y a las descripcin de los componentes nuevas secciones que especifican y describen el comportamiento de tiempo real requerido y ofertado. As, disponiendo de la descripcin de cada una de los componentes que constituyen una aplicacin, junto con un modelo complementario que describe las capacidades de procesamiento de las plataformas hardware/software en que se ejecutan, se puede construir un modelo de tiempo real de la aplicacin completa, que es utilizado como base de operacin de las herramientas de diseo que ayudan a la configuracin ptima de los componentes y de las herramientas de anlisis que permiten garantizar la planificabilidad de la aplicacin, o en caso negativo mediante anlisis de holguras localizar las causas que le impiden satisfacer los requerimientos temporales. La extensin que se propone solo afecta a tres de los bloques de trabajo del proceso de desarrollo:
R e qu erim ien to s d e la a p lica c i n
M o delo de C asos de U so
R eq u erim ien to s
M o delo de C asos de U so M o delo C on ceptua l Restriccio nes T cn ica s
Exp erien cia d isp onible C om p on en tes
E sp ecifica ci n
A p ro vision a m ie n to
Especifica cio nes de co m pon entes
E n sam b la d o
Ap licacion es
rea m odificada para tiem po real
Test
Ap lic .
probadas
D es p lieg u e
En el bloque de definicin de los requerimientos, se ha realizado la extensin necesaria para que se puedan formular los requerimientos de tiempo real de la aplicacin. Estos requerimientos se definen de forma independiente para cada modos de operacin del sistema, y por cada uno de ellos, se formulan a travs de las declaraciones de los conjuntos de transacciones que concurren en l. La declaracin de cada transaccin de tiempo real incluye la descripcin de sus caractersticas de disparo, los conjuntos de actividades que conlleva su ejecucin y los requerimientos de tiempo real que se imponen a lo largo de ella.
1. Descrito en el apartado I.3.
12
diciembre 2002
En el bloque de actividades relativas a la especificacin de los componentes la extensin incluye los procedimientos de descripcin del comportamiento temporal del componente. Esto se realiza mediante la especificacin de la secuencia de actividades que conlleva la ejecucin de cada una de los procedimientos ofrecidos por sus interfaces, y por cada actividad, se describe la cantidad procesado que requiere as como los recursos compartidos que puede requerir y que pueden dar lugar a suspensiones de su ejecucin. Por ltimo, en el bloque de actividades de test se incluyen las actividades que generan el modelo de tiempo real de la aplicacin a partir de los modelos de los componentes que se han utilizado para su ensamblaje y de los modelos de las plataformas hardware/software en que se despliega la aplicacin. As mismo se incluyen, los procesos de anlisis del modelo construido, bien para la toma de decisin sobre la configuracin ptima de los componentes o bien para verificar su planificabilidad. La idea bsica de la extensin que se propone es que el diseo de sistemas de tiempo real basados en componentes no se fundamenta en una estrategia de diseo de componentes con unas prestaciones temporales preestablecidas e independientes de su uso ( lo cual no se sabe hacer salvo para situaciones muy laxas ), sino en construir componentes que llevan asociado un modelo de comportamiento temporal, que permite modelar y analizar el comportamiento de tiempo real de las aplicaciones que hagan uso de ellos. El mtodo que se propone, se basa en la potencia de modelado y de anlisis de que se dispone, y no en la propuesta de nuevas en estrategias de diseo. El desarrollo de componentes estndar de tiempo real que puedan funcionar sobre distintas plataformas hardware es complicado debido a que los componentes tienen diferentes caractersticas temporales sobre diferentes plataformas. Cada componente ha de ser adaptado y verificado de nuevo para cada plataforma hardware sobre la que se pretende instalar , especialmente si el sistema es crtico (tiempo real estricto). Lo que se propone es generar por separado modelos independientes de las plataformas y de los componentes que nos permitan analizar el funcionamiento del sistema completo.
I.5. Entorno MAST de modelado , diseo y anlisis de sistemas de tiempo real El entorno MAST1 est siendo desarrollado en la actualidad por el grupo CTR2 de la Universidad de Cantabria , y su metodologa ya ha sido aplicada en diferentes entornos [13][14][15]. Su principal objetivo es simplificar la aplicacin de tcnicas estndar y bien conocidas de anlisis de sistemas de tiempo real, proporcionando al diseador un conjunto de herramientas para aplicar tcnicas de anlisis de planificabilidad, de asignacin ptima de prioridades o de clculos de holguras, etc., sin necesidad de que tenga que conocer los detalles algortmicos de los mtodos. Actualmente, MAST cubre sistemas monoprocesadores, sistemas multiprocesadores, y sistemas distribuidos basados sobre diferentes estrategias de planificacin, incluyendo planificacin expulsoras y no expulsoras, manejadores de interrupciones, servidores espordicos, escrutinios peridicos, etc.
1. Modeling and Analysis Suite for real-Time aplications. 2. Computadores y Tiempo Real.
13
diciembre 2002
Caractersticas relevantes de la metodologa MAST que la hace especialmente idnea para modelar sistemas basados en componentes , son: Se basa en el modelado independiente de la plataforma (procesadores, redes de comunicacin, sistema operativo, drivers, etc.), de los componentes lgicos que se utilizan (requerimientos de procesado, de recursos compartidos, de otros componentes, etc.) y del propio sistema que se construye (particin, despliegue, situaciones de tiempo real, carga de trabajo (workload) y requerimientos temporales). El modelo se construye con elementos que modelan los aspectos de tiempo real (temporizacin, concurrencia, sincronizacin, etc.) de los elementos lgicos (componentes), y en consecuencia da lugar a un modelo que tiene la misma estructura que el cdigo. Permite el modelado independiente de cada componente lgico de alto nivel, a travs de un modelo de tiempo real genrico, que se instancia en un modelo analizable cuando se completa con el modelo de los componentes de los que depende y se asignan valores a los parmetros definidos en el modelo. Soporta implcitamente la distribucin de componentes, de forma que en funcin de que un componente se encuentre asignado o no al mismo procesador que otro del que requiere servicios, se incorpora o no el modelo de la comunicacin a la invocacin del servicio. El comportamiento de tiempo real de un sistema se descompone en tres secciones independientes pero complementarias que en conjunto describen un modelo que proporciona toda la informacin estructural y cuantitativa que se necesita para ser procesado por las herramientas de diseo y anlisis de que se dispone.
Modelo de tiempo real
Real-Time tiempo real
Situacin de
Modelo de la plataforma
Modelo de los componentes lgicos
Modelo de la Plataforma: Modela los recursos hardware/software que constituyen la plataforma en que ejecuta la aplicacin y que es independiente de ella. Modela los procesadores (la capacidad de procesado, el planificador, el timer del sistema, ...), las redes de comunicacin: (la capacidad de transferencia, el modo de transmisin, los planificadores de mensajes, los drivers de comunicacin, ...) y la configuracin (las conexiones entre los procesadores a travs de las redes de comunicacin )
14
diciembre 2002
Modelo de los componentes lgicos: Modela el comportamiento de tiempo real de los componentes software con los que se construye la aplicacin. El modelo de un componente software describe: La cantidad de procesado que requiere la ejecucin de las operaciones. Los componentes lgicos de los que requiere servicios. Las tareas o threads que crea para implementar sus operaciones. Los mecanismos de sincronizacin que requiere sus operaciones. Los parmetros de planificacin definidos en el cdigo de sus operaciones. Los estados internos relevantes a efecto de requerimientos de tiempo real.
Modelo de las situaciones de tiempo real: Una "Situacin de Tiempo Real" representa un modo de operacin del sistema junto con un modelo de la carga de trabajo que tiene que ejecutar y constituye el mbito en que operara una herramienta de anlisis. El anlisis de un sistema de tiempo real consiste en la identificacin de las situaciones de tiempo real que el sistema puede alcanzar y en el anlisis independiente de cada una de ellas. Aunque los modelos de las situaciones de tiempo real son planteados independientemente comparten el modelo de la plataforma y el modelo de muchos de los componentes software que se utilizan en ellas. El entorno MAST ofrece un conjunto de componentes primitivos que se utilizan en el modelado de un sistema [13]. Estos componentes son simples y muy prximos a los componentes hardware y software que intervienen en la respuesta temporal de la aplicacin, y su uso directo en aplicaciones complejas en las que se necesitan cientos o miles de ellos para construir el modelo puede ser difcil de validar. Para evitar este problema se han definido diferentes perfiles de modelado que proporcionan componentes de mas alto nivel que facilitan la formulacin del modelo de tiempo real dentro de ciertos entornos de programacin especficos. Actualmente se disponen de los siguientes perfiles: _ UML_MAST: Perfil para el diseo de modelo de aplicaciones de tiempo real basadas en metodologas orientadas a objetos y desarrolladas mediante herramientas UML[14]. _ ADA_MAST: Perfil para el diseo de modelos de aplicaciones de tiempo real y distribuidas desarrolladas utilizando ADA95 con las extensiones establecidas en su apndices D (Real-Time System) y E (Distributed Systems) [15]. _ CBSE_MAST: Perfil para el diseo de modelos de tiempo real de componentes software que facilitan el diseo del modelo de aplicaciones basadas en ellos [17]. El perfil que ha sido utilizado en este proyecto es este ltimo y ser descrito con mayor detalle en la prxima seccin.
I.6. Perfil CBSE_MAST CBSE_MAST es un perfil definido en el entorno MAST a fin de simplificar la formulacin del modelo de tiempo real de un sistema y de una aplicacin construida por agregacin de componentes software tal como se considera en la metodologa CBSE (Component Based Software Engineering).
15
diciembre 2002
Con el perfil CBSE_MAST, los componentes (hardware y/o software) que se tienen catalogados tienen asociado su modelo de tiempo real y cuando construimos el sistema componiendo algunos de ellos, el modelo de tiempo real del sistema completo se podr a su vez construir componiendo los modelos de tiempo real de los componentes utilizados. El perfil CBSE_MAST ha sido formulado para ser aplicado a sistemas descritos mediante UML y proporciona recursos y normas para construir una nueva vista complementaria del modelo UML del sistema, que denominamos MAST_RT_View, que constituye un modelo de su comportamiento de tiempo real. CBSE_MAST es un perfil especializado del perfil UML_MAST y heredada de l todos los componentes de modelado de mediano y bajo nivel. De hecho CBSE_MAST es una extensin del perfil MAST_UML en el que se incluyen los elementos contenedores y de modularizacin que se necesitan para modelar eficientemente los diseos de sistemas desarrollados usando la metodologa CBSE.
< < profile> > UML_M A S T
M A ST
< < profile> > CB S E _M A S T
CBSE_MAST queda definido por un metamodelo CBSE_MAST_Metamodel formulado en UML [17]. Este metamodelo es a su vez una extensin del metamodelo UML_MAST_Metamodel y solo describe los nuevos aspectos establecidos en l respecto de este. El aspecto central de la metodologa CBSE es la modularizacin de subsistemas para su reusabilidad y esto requiere que el mtodo de modelado disponga de una mayor precisin de los conceptos de descriptor de un componente MAST como clase que define un patrn de modelado de un subsistema parametrizable disponible en la biblioteca de componentes y el de instancia de componente MAST, como objeto que representa el modelo de tiempo real de un componente concreto que participa en la ejecucin de la aplicacin que se analiza y que influye en el comportamiento temporal. Un MAST_Descriptor es un ente de modelado que constituye un descriptor genrico y posiblemente parametrizable que define la informacin que se necesita para describir el modelo de tiempo real de algn tipo de recurso o servicio del sistema. El descriptor proporciona la informacin semntica y cuantitativa que es comn a todos los entes que puedan resultar de su instanciacin.
16
diciembre 2002
Un MAST_Instance es un ente que constituye el modelo de tiempo real concreto y final de una instancia individual de un recurso o servicio del sistema. En el modelo de un sistema, cada objeto del tipo MAST_Instance que se declare debe tener una clase del tipo MAST_Descriptor que describa su naturaleza y semntica, y del que se deriva al establecer valores o instancias concretas a todos los atributos, parmetros o referencias que tenga declarados.
M AST_Instance
0..n inst
1..n type
M AST_D escriptor
M AST_C om ponent_Inst
0..n inst
1..n type
M AST_C om ponent_D escr
usageLst 0..n M AST_U sage_Inst 0..n inst +objectLst 0..n M AST_F orm ing_O bject valueLst 0..n M AST_Value 0..n inst 0..n inst 1..n type
usageLst
0..n
M AST_U sage_D escr
0..n 1..n type param eterLst 0..n 1..n M AST_Param eter type
declaratedLst
M AST_C onstituent_D eclaration
Un elemento MAST_Component_Descr es un MAST_Descriptor que describe una clase de elementos de modelado que describen un tipo de recurso hardware o software del sistema. Un MAST_Component_Descr tiene una triple funcin: 1) Constituye un elemento contenedor que declara: _ Los atributos, parmetros o smbolos que deben ser establecidos para declarar una instancia del modelo. De cada uno de ellos se especifica su tipo y optativamente el valor por defecto que se les asignar. _ Declara los componentes externos a l (y sus tipos) que deben ser referenciados ya que el modelo del componente hace uso de los modelos que representan. _ Declara los componentes (y sus tipos) que se instancian, por cada instancia suya que se declare en el modelo. _ Declara los modelos de los usos del componente que son requeridos en la ejecucin del sistema. Estos usos se describen individualmente como modelos de operaciones o bien agrupados por dominios de funcionalidad en interfaces. 2) Define un mbito de visibilidad, para nombres de smbolos, atributos y componentes. Cualquier atributo, smbolo o componente que se defina en un componente es visible y utilizables en la definicin de cualquier componente incluido dentro de l (salvo que se oculte por una declaracin mas prxima que haga uso del mismo identificador). 3) Cada MAST_Component_Descr tiene una referencia denominada host a un componente del tipo predefinido en UML "MAST_Processing_Resource" y hace referencia al modelo del processing resource en el que estar instalado el componente.
17
diciembre 2002
Un elemento MAST_Component_Inst es una instancia concreta de un tipo de ente de modelado descrito mediante un MAST_Component_Descr. Contiene la informacin cuantitativa completa y final que define el modelo de tiempo real del ente hardware o software que modela.
MAST_Component _Descr type 1..n
host MAST_Processing_Resource (from UML Profile) 0..1
host inst 0..n MAST_Component_Inst 0..1 place 1
MAST_Processing_Resource (from UML Profile) MAST_Descriptor_Place
MAST_Target_View_Placed MAST_Logical_View_Placed MAST_External_File + path : Identifier
Cuando se declara en un modelo un MAST_Component_Inst: Quedan declarados recursivamente a la vez todos las instancias de componentes que estaban declarados en la MAST_Component_Descr como elementos agregados. Se le tiene que asignar a cada parmetro, atributo o smbolo un valor concreto que sea resoluble dentro del modelo. Si en el correspondiente MAST_Component_Descr el parmetro, atributo o smbolo tena declarado valor por defecto, puede omitirse de la declaracin del MAST_Component_Inst si el valor que se le asigna es el declarado como por defecto. Se tiene que asignar a cada elemento declarado por referencia en el correspondiente MAST_Component_Descr, la referencia de un MAST_Component_Inst que est declarado en el modelo. Debe asignarse a la referencia host el componentes de tipo MAST_Processing_ Resource en que se instancia el componente (siempre que no se le asigne el valor por defecto). La asignacin de la referencia host sigue las siguientes reglas: _ Cuando una MAST_Component_Inst se declara explcitamente en un modelo siempre debe asignarse la referencia de la instancia MAST_Processing_Resource en la que se instale. _ Cuando una MAST_Component_Inst se declara implcitamente como agregada dentro de otro, su referencia host tiene como valor por defecto el mismo objeto
18
diciembre 2002
(del tipo MAST_Processing_Resource) referenciado en la referencia host del componente en el que se declara. Cuando un componente es del tipo MAST_Processing_Resource la referencia host se referencia a s mismo. Debe asignarse al atributo place el valor que permite localizar la descripcin del MAST_Component_Descr del que es instancia. Las posibles ubicaciones son la Target_View o la Logical_View del propio componente, o en un fichero externo, al que se puede acceder a travs del path que se declara.
Una MAST_Constituent_Decl es una referencia a algn ente (componente, tipo de uso o atributo) que se declaran en un MAST_Component_Decl como elemento utilizado internamente para construir el modelo de tiempo real del componente. Existen tres tipos de declaraciones: Aggregated MAST_Component_Descr que declara el tipo de un componente incluido en l que ser instanciado por cada instancia del componente que se describe. Referenced MAST_Component_Descr que declara un componente externo a l, que necesita conocerse, ya que su modelo es parte del modelo del componente que se describe. La instanciacin del componente referenciado no es inducida por la instanciacin del componente que la referencia. Referenced MAST_Usage_Descr que representa un tipo de uso incluido en un componente diferente y cuyo modelo se necesita conocer para construir el modelo del componente que se describe. Included MAST_Atribute que representa un tipo de datos cuyos valores necesitan conocerse para construir el modelo del componente que se describe. Un MAST_Constituent_Object es cada una de las instancias concretar que tienen que existir para que est completo el modelo de la instancia MAST_Component_Inst que se declara. En correspondencia con las MAST_Instance_Declaration que se definen en cada declaracin de un componente, en la instancia del mismo se puede tener que especificar:
19
diciembre 2002
Instanced MAST_Component_Inst que representa la instancia que crea como consecuencia de la declaracin aggregated MAST_Component_Descr establecida en el componente que describe al componente que se instancia. Esta declaracin solo se har en la instancia si en el descriptor existin elementos abstractos que se necesitan concretar o se desean asignar valores diferentes a los establecidos como por defecto. Assigned MAST_Component_Inst que representa la referencia a un componente que se encuentra instanciado en el modelo y que se declara en correspondencia a la declaracin referenced MAST_Component_Descr establecida en el componente que describe al componente que se instancia. Assigned MAST_Value que representa el valor que se asigna al atributo declarado por el included MAST_Attribute attribute establecido en el componente que describe al componente que se instancia. Assigned MAST_Usage_Inst que representa la referencia a un MAST_Usage_Inst que se obtiene por referenciar un MAST_Usage_Inst de un MAST_Component_Inst y asignar un nuevo valor concreto, si fuese preciso, al parmetro del uso. Si un componente referenciado, agregado o un atributo tiene definidos valores por defecto, se le pueden definir o no nuevos valores concretos cuando se realiza su instanciacin. Si se asumen todos los valores por defectos y con ellos el componente o uso queda completamente definidos, no es necesario declarar el elemento instanciado en la instancia que se describe.
M A S T _ U sa ge _D esc r
u s age s Lst 1..n
M A S T _ Inte rface _ D e sc r
M A S T _ O p e ratio n (fro m U M L Pro file)
m ode l 0..1
M A S T _ O p e ratio n_M o del (fro m U M L Pro file)
M A S T _ Sim p le _ O pe ration (fro m U M L Pro file) - w ce t : N orm alized _E x ecution _Tim e = 0.0 - a c et : N orm aliz ed _E x ec ution _ Tim e = 0.0 - b c et : N orm aliz e d_E x ecu tion _Tim e = 0.0
lo ck Lst 0..n 0..n un lock e dLs t M A S T _ Sha red _R e s ource (fro m U M L Pro file) M A S T _ O v e rride n_S che d_ Pa ram eter (fro m U M L Pro file)
0..1
O verriden _ Pa ra m e ter m ode l
M A S T _ Enc los ing_ O pera tion (fro m U M L Pro file) M A S T _ C om po site (fro m U M L Pro file) M A S T _ Job (fro m U M L Pro file) 0..n pa ram ete rL s t
M A S T _ C om po site_ M ode l (fro m U M L Pro file) 1 1 m ode l
m ode l 1 M A S T _ Job _ Pa ra m e ter (fro m U M L Pro file)
M A S T _ Job _ M od el (fro m U M L Pro file)
20
diciembre 2002
Un MAST_Usage_Descr describe el modelo de tiempo real de una forma de uso de un componente. Corresponde, por ejemplo, al modelo de la ejecucin del cdigo software que se realiza en respuesta a la invocacin de un procedimiento lgico o al modelo de un uso de un recurso hardware que se realiza en background (por ejemplo atencin al timer) o en respuesta de una interrupcin o acceso a algn estado interno. Un MAST_Usage_Descr se puede declarar individualmente en el componente como MAST_Operation o agrupado por su dominio de utilizacin en elementos contenedores del tipo MAST_Interface. Una MAST_Inteface es un conjunto de tipos de usos asociados por pertenecer a un mismo dominio funcional. Una MAST_Interface puede incluir bien un conjunto de MAST_Operations o de otras MAST_Interfaces ms simples. Es meramente un elemento contenedor, que permite organizar los servicios y sobre todo proporcionar un mbito especfico de nombres y de parmetros. Los nombres de parmetros y de operaciones dentro de una interfaces tienen que ser nicos, sin embargo parmetros u operaciones con el mismo nombre pero incluidos en diferentes interfaces son diferentes. Un MAST_Operation es un tipo de uso simple que corresponde a la ejecucin de un procedimiento de un sistema con unos datos y unas condiciones de ejecucin especficas y es un concepto definido en el perfil MAST_UML. Aunque en el diagrama de clases se muestra la estructura del metamodelo que describe MAST_Operation, y el conjunto de clases que se derivan de ellas, todas ellas pertenecen al UML_MAST profile y estn descritas en su documentacin.
M A S T _ P a ram e te r o n e o f th em d e cla re d 0 ..1 M A S T _ C o m p o n e nt_ D e scr d e cla re d 0 ..1 M A S T _ D a ta_ Typ e d e cla re d 0 ..1 M A S T _ S e rvice _D e scr
M A S T _ Va lu e o n e o f th em a ssig n ed 0 ..1 a ssig n ed 0 ..1 M A S T _ C o m p o n e nt_ In st M A S T _ D a ta_ Va lu e a ssig n ed 1 ..0 M A S T _ S e rvice _In st
Un MAST_Usage_Descr puede tener definidos un conjunto de parmetros MAST_Parameter que son utilizados en la descripcin del modelo de la forma de uso. Estos parmetros permiten especificar el recurso o forma de uso concreto que se utiliza en algn punto del modelo de una operacin, como consecuencia de que el procedimiento que se modela se ejecuta con diferentes datos o recursos. Los MAST_Parameter pueden utilizarse para declarar: Cada uno de los MAST_Component_Descr que son referenciados para formular el modelo de la forma de uso. Otros MAST_Usage_Descr a los que son referenciados para describir el modelo.
21
diciembre 2002
MAST_Data_Type que referenecia datos de tipo escalar o estructurado, que son utilizados para definir el modelo de la forma de uso. En la declaracin de un MAST_Parameter se pueden definir valores por defecto. La declaracin de las MAST_Interface_Inst est implcita en la declaracin del MAST_Component_Inst en que estn declaradas (y por tanto no existen declaraciones explicitas de las MAST_Interfaces_inst). En consecuencia, cuando se declara una MAST_Component_Inst hay que asignar a todos los MAST_Parameter de las MAST_interfaces declaradas en l, un MAST_Value que es un valor concreto (o instance) con el que se define completamente el modelo de la interfaz, lo cual constituye su instancia. Si el valor MAST_Value que se debe asignar al Mast_Parameter es el establecido por defecto en el MAST_Interface_Descr, la asignacin no necesita ser explicitada.
I.7. Objetivos del proyecto A lo largo de los tres ltimos aos, he participado en dos proyectos de investigacin1 desarrollados por la empresa Equipos Nucleares en colaboracin con el grupo Computadores y Tiempo Real (CTR), relativos a la aplicacin de la visin artificial a la automatizacin de los procesos industriales y al desarrollo de controladores de sistemas robotizados. En ellos, he tenido que llevar a cabo la adaptacin de diferentes libreras comerciales ( relativas a visin artificial (digitalizacin de imgenes y procesado digital de imgenes), acceso remoto a bases de datos Informix, driver de control de tarjetas de I/O analgicas y digitales ) al entorno en que se desarrollaban los proyectos, que eran plataformas Windows NT y aplicaciones de tiempo real desarrolladas con tecnologa Ada. En este proyecto fin de carrera hay dos objetivos principales que vertebran el desarrollo del proyecto y la exposicin del mismo en la memoria: 1) Diseo e implementacin de tres componentes de tiempo real tiles en diseo de controladores industriales: Se han desarrollado un conjunto de interfaces correspondientes a tres dominios de implementacin, y se han desarrollado tres componentes que las implementan. Dominio Adquisicin de seales analgicas y digitales: Se han diseado un conjunto de interfaces destinadas a la adquisicin de seales analgicas y digitales a travs de tarjetas de IO de propsito general. _ Interface I_Adq_Configuration: Conjunto de operaciones y constantes de gestin y configuracin de la tarjeta de adquisicin. _ InterfaceI_Analog_Adq: Conjunto de operaciones de adquisicin y generacin de tensiones analgicas a travs de convertidores A/D y D/A.
1. Entorno para la programacin de tiempo real de controladores industriales y aplicacin a la automatizacin del proceso de fabricacin de generadores de vapor en cmara limpia. Fondos FEDER, 1999-2001. Sistema robtico teleoperado (SRT). Financiado por Equipos Nucleares S.A.ENDESA y REN, 19992000.
22
diciembre 2002
_ InterfaceI_Adq_Analog_Active: Interfaz activa que aade a la interfaz bsica I_Analog_Adq un conjunto de operaciones basadas en tareas de background que temporizan la adquisicin o establecimiento de tensiones analgicas, las procesan y gestionan los resultados. _ InterfaceI_Digital_Adq: Conjunto de operaciones de lectura y escritura en lneas y grupos de lneas de entrada y de salida digitales. _ InterfaceI_Active_Digital_Adq: Interfaz activa que aade a la interfaz bsica I_Digital_Adq un conjunto de operaciones basadas en tareas de background que leen y escriben las lneas digitales, procesan la informacin y gestionan los resultados. _ Componente C_PCI9111: Componente basado en la tarjeta de adquisicin PCI9111DG de la casa ADLINK, con 1 canal de salida analgico de 12 bits de resolucin, 16 canales de entrada analgicos multiplexados de 12 bits de resolucin, 16 bits digitales de entrada, 16 bits digitales de salida y 4 bits digitales de entrada / salida. Este componente implementa las 5 interfaces antes citadas.
< < co m p o n en t> > C _ P C I9 111
I_ A n a log _ A d q
I_ D ig ital_ A d q
I_ A ctiv e_ A n a lo g _ A d q
I_ A d q _ C o n fig u ra tion
I_ A ctiv e_ D igital_ A d q
Dominio: Adquisicin y digitalizacin de imgenes de vdeo: Conjuntos de recursos para la configuracin de la tarjeta de digitalizacin de imgenes de vdeo, captura de imgenes, y transferencia de imgenes en vivo a ventanas de la workstation. _ Interface:I_Image_Grabber: Ofrece la capacidad de controlar y configurar la tarjeta, capturar y digitalizar imgenes individuales, convertirlas en otros formatos y activar o inhibir la transferencia continua de imgenes hacia ventanas de la aplicacin _ Componente: C_IG_DT3153: Contiene los recursos software de gestin de la tarjeta DT3153 de Data Translation que es una tarjeta digitalizadora de imgenes de
23
diciembre 2002
vdeo en color con capacidad de transferencia de imgenes a memoria de la workstation. Este componente implementa la interface I_Image_Grabber .
<<component>> C_IG _DT3153
I_Image_Grabber
Dominio Procesado digital de imgenes. Corresponde a diferentes recursos para la gestin, procesado digital, anlisis, caracterizacin estadstica etc. de imagenes almacenadas en el ordenador. Para este dominio se han definido 8 interfaces que ofrecen cada una de ellas un tipo de servicios especfico: _ InterfaceI_Img_Managing: Ofrece el conjunto bsico de operaciones de gestin y almacenamiento de imgenes. Es una interfaz que ofrece los recursos bsicos sobre las estructuras de datos asociadas a una imagen, as como los procedimientos de almacenamiento y recuperacin de la misma. Es utilizada por las restantes interfaces de visin. _ InterfaceImg_Processing: Ofrece el conjunto de operaciones que permiten el procesado de las imgenes por parte del usuario. Ofrece procedimientos de acceso a pxel y de transformacin de la imgenes en funcin de la posicin de los pixels. _ InterfaceI_Img_Logic_Processing: Ofrece el conjunto de operaciones de procesado lgico (bit a bit) de imgenes de grises. _ InterfaceI_Img_Arith_Processing: Ofrece el conjunto de operaciones de procesado aritmtico de imgenes de grises. _ InterfaceI_Img_Transforming: Ofrece el conjunto de operaciones de transformaciones de imgenes de un modo global. Se ofrecen transformaciones geomtricas, lineales, morfolgicas y filtrados. _ InterfaceI_Img_Statistic: Ofrece el conjunto de operaciones de clculo de valores estadsticos sobre una imagen de grises. _ InterfaceI_Img_Analysis: Ofrece el conjunto de operaciones que realizan anlisis complejos sobre imgenes para obtener resultados concretos. Permite identificar, localizar y caracterizar patrones presentes en la imagen. _ InterfaceI_Img_Draw: Ofrece de operaciones que permite dibujar e insertar distintos elementos en una imagen. _ Component C_Ada_Vision: Este componente ofrece los recursos relativos a gestin, procesado de imgenes y anlisis de imgenes. Su funcionalidad corresponde a las librerias IPL [18] y Open_CV [19] de cdigo abierto
24
diciembre 2002
proporcionadas por Intel y que han sido diseadas especficamente para que sean muy eficientes sobre la arquitectura de los procesadores con tecnologa MMX.
I_ Im g _ L o g ic_ P ro ce ssin g

I_ Im g _ A rith _ P ro ce ssin g I_ Im g _ M a na g in g I_ Im g _ A n a lysis I_ Im g _ P ro ce ssin g I_ Im g _ Tra n sfo rm in g I_ Im g _ Sta tistic < < co m p o n e n t> > C _ Ada_Visio n
I_ Im g _ D ra w
2) Desarrollo de una aplicacion de tiempo real ejemplo y su anlisis de planificabilidad de peor caso: Se ha desarrollado como ejemplo una aplicacin sencilla que hace uso de algunas de las interfaces que son implementadas por los tres tipos de componentes desarrollados y que consiste en el control de una maqueta de trenes de juguete, a travs de la deteccin de la posicin de los trenes mediante visin artificial. Esta aplicacin desarrollada tiene la finalidad de validar los componentes, tanto en lo relativo a su especificacin, a su interconectividad y a sus modelos de tiempo real, y sobre todo permite obtener experiencia sobre el ciclo de desarrollo de aplicaciones basadas en componentes. El proyecto fin de carrera ha tenido otros objetivos indirectos, que se enmarcan dentro de las lneas de investigacin que desarrolla el Grupo de Computadores y Tiempo Real, y cuya importancia transciende mas all del propio proyecto. Estos objetivos han sido: Se ha establecido estructuras de datos y estrategias para representar componentes de tiempo real en la herramienta UML CASE ROSE de Rational. Se proponen unos formatos para codificar interfaces y componentes implementados como paquetes Ada95. Se han analizado los procesos de transformacin de los cdigos ADA que representan los modelos funcionales de los componentes en las diferentes fases del desarrollo de la aplicacin, lo cual representa una informacin muy valiosa para el desarrollo de futuras herramientas de generacin automtica de cdigo a partir de los modelos UML. Se han analizado los procesos de construccin de los modelos de tiempo real de una aplicacin a partir de su MAST_RT_View y del los modelos de tiempo real de los componentes que se utilizan. Informacin que ser la base, o al menos una experiencia relevante a fin de desarrollar en el futuro herramientas de generacin automtica del modelo de tiempo real MAST de las aplicaciones. Se ha desarrollado modelos de tiempo real de una plataforma contruida por una workstation operando bajo sistema operativo Windows NT Server 4.0, y diferentes tarjetas de IO (Grabber DT 3153 y IO card PCI-9111DG).
25
especificacin y diseo funcional de componentes
diciembre 2002
II. ESPECIFICACIN Y DISEO FUNCIONAL DE COMPONENTES

II.1. Componentes e interfaces La palabra componente representa muchos conceptos diferentes dentro de CBSE y es importante fijar el significado que le damos en este proyecto. En la siguiente figura, se muestran diferentes formas en las que se puede tratar un componente.
n interfaceSoportada 1..n Especificacin de componentes 1 n realizacin Implementacin de componente 1 n instalacin Componente instalado 1 n instancia Componente objeto
Interface
La especificacin de un componente es un descriptor del comportamiento de un conjunto de objetos componentes y define una unidad de implementacin. El comportamiento de la especificacin de un componente se describe mediante un conjunto de interfaces. Una interface define los diferentes aspectos del comportamiento de un componente relativos a un mismo dominio que se ofrecen como una unidad o servicio que puede ser ofrecido de forma intercambiable por diferentes componentes. Una implementacin de un componente es una realizacin de una especificacin de componente que puede ser utilizado en el desarrollo de una aplicacin. Un componente instalado o desplegado es una copia de una implementcin de un componente que est registrado en algn entorno de ejecucin. Esto capacita al entorno de ejecucin para identificarlo y usarlo cuando se genere una instancia del componente o se invoque alguna de sus operaciones. Un componente objeto es una instancia ejecutable de un componente instalado. Es un concepto de ejecucin. Es un objeto con una nica identidad y con su propia instancia de datos y estado. Un componente instalado puede tener muchos (o solo un) componentes objetos instanciados, cada uno con su propia identificacin.
26
diciembre 2002
En este proyecto, se utilizan los siguientes conceptos: Descripcin de componente o de interface: son modelos independientes UML que describen su funcionalidad. En el modelo de un componente aparecen agregados los modelos de las interfaces que implementa. Implementacin de un componente: es un un paquete Ada compilable, que implementa a su vez la descripcin de un componente y las de las interfaces que ofrece el componente. Componente objeto: es una librera instanciada en una aplicacin Ada del paquete Ada que describe al componente. Es importante tener en consideracin los dos tipos de contrato que implica el manejo de componentes:
Interface Component description
realization usage
C lient
Component implementation
Contrato de uso: Es el contrato que se establece entre la especificacin del componente y la aplicacin cliente que lo utiliza. Esto se realiza a travs de las interfaces que definen de por s y con independencia del componente que las implementa y ofrece, las operaciones y el modelo de informacin del servicio que ofrece. Cuando una aplicacin usa una interface, su funcionalidad no puede quedar afectada por la naturaleza del componente que implementa la interface que se usa. Contrato de instalacin: Es el contrato que se establece entre la implementacin del componente y el entorno en el que puede operar. Debe establecer que entorno de implementacin y que otros componentes o interfaces deben estar implementados en l para que el componente pueda ofrecer su funcionalidad. Aunque estos dos tipos de contratos deben estar detalladamente explicitados en la descripcin de un componente, deben ser independientes entre si. La aplicacin que usa un componente no debe depender, ni necesita conocer el contrato de realizacin, y la instalacin de un componente debe ser independiente de que aplicacin va a utilizarla. Desde este punto de vista, la especificacin del componente y la especificacin de las interfaces son conceptos independientes que juegan un papel central en la tecnologa CBSE. La especificacin del componente es bsicamente el contrato de instalacin, que se formula principalmente pensando en el realizador, probador y ensamblador del componente. Define al componente como una unidad de realizacin, define su encapsulacin y determina su granularidad y la posibilidad de reemplazabilidad que tiene. Por el contrario, la especificacin de las interfaz representa el contrato con el componente cliente, y define los servicios que el
27
diciembre 2002
componente usuario puede esperar del componente que la implementa. En la siguiente tabla, se resumen las diferencias entre las descripcin de un componente y de una interfaz. Especificacin de Interfaz Una lista de operaciones Especificacin de Componente Una lista de interfaces soportadas
Define el modelo abstracto de Define el modelo de informacin que informacin lgica que se necesita establece las relaciones entre las para usarla diferentes interfaces. Representa el contrato con el cliente. Representa el contrato con el realizador, instalador, probador y ensamblador.
Especifica como las operaciones Define la implementacin y la unidad afecta o dependen del modelo de de ejecucin. informacin Describe solo los efectos locales al Especifica como se implementan las modelo de informacin del servicio operaciones que ofrece en funcin de que oferta. las operaciones que requiere de las interfaces del que el componente depende. En las siguientes secciones de este captulo se describen los recursos y los formatos que se proponen para formular las especificaciones y las implementaciones de los componentes y de las interfaces.
II.2. Especificacin de una interfaz La interfaz representa el conjunto de operaciones y modelo de informacin que se requiere para definir completamente el servicio que se espera del componente que las oferte y lo que el cliente debe espera de su uso. La especificacin de una interfaz contiene: El identificador de la declaracin de la interface al que se hace referencia en su instanciacin dentro de un componente. El modelo de informacin, esto es, los atributos, tipos, asociaciones, etc. definidos unos en funcin de otros hasta proporcionar un modelo completo y cerrado. La descripcin de las operaciones a travs de los que el usuario puede acceder al servicio proporcionado por la interfaz. Esto supone definir la especificacin completa de cada operacin (identificador, parmetros, precondiciones y postcondiciones, etc). Conjunto de invariantes y restricciones del modelo de informacin de la interfaz. Otras interfaces con las que tiene establecidas relaciones de dependencia o de herencia.
28
diciembre 2002
Una interfaz se describe con independencia de cualquier componente. En UML la representamos, como una clase con estereotipo <<interface_descr>> y su modelo de informacin se describe dentro de un paquete que contiene todos los elementos UML que se utilizan para su descripcin. El modelo de una interfaz es siempre un paquete con el estereotipo <<interface_model>> que tiene el nombre de la interfaz, y que se encuentra situado dentro del paquete Functional_View , que a su vez esta definido en Logical View del modelo.
Model Name User Case View Logical View Functional View <<interface_model>> I_Image_Grabber <<interface_model>> I_Vision MAST RT View Component View
El paquete de la interfaz puede estar incluido dentro del modelo que describe un componente, pero mas frecuentemente se encuentra descrita en un fichero (modelo) independiente que describe solo a la interfaz o tambin a otras interfaces relacionadas. En la descripcin UML de una interfaz se incluye: Identificador de la interfaz: Corresponde con el nombre de la clase con estereotipo <<interface_descr>> en que se declara la interfaz. Modelo de informacion de la interfaz: Corresponde con atributos, clases asociadas (por agregacin o por dependencia), diagramas de estado, etc. que se incluyen en el paquete de descripcin de la interfaz y que proporciona toda la informacin necesaria para que el usuario pueda utilizar la interfaz de forma autocontenida. Declaracin de las operaciones de la interfaz: Se formulan como operaciones declaradas en la clase de descripcin de la interfaz. Cada operacin se declara con su descripcin completa UML, esto es, con su identificador, su conjunto de parmetros, y en su caso valor de retorno. As mismo, en formato de texto se incluyen el conjunto de pre-condiciones (condiciones relativas a la interfaz que deben cumplirse antes de ser invocada una operacin a fin de que los resultados sea predecibles) y el conjunto de post-condiciones (condiciones que se satisfacen en la interfaz despues de haber sido ejecutada la operacin, si se satisfacian las pre-condiciones). Declaracin de invariantes y restricciones en la interfaz: Se formulan mediante texto asociado a la clase que declara la interfaz. Otras interfaces con la que tiene establecida relaciones de dependencia: Se formulan como clases que representan instancias de interfaces, en las que solo se describe su identificador y el path donde se encuentra su declaracin si esta est en un fichero diferente al del modelo. Acceso al fichero (de extensin .aci): que contiene la declaracin de la parte pblica del paquete Ada en que se describe la interfaz, mediante lenguaje Ada. El cdigo de
29
diciembre 2002
este fichero contiene la informacin necesaria para que el programador de la aplicacin pueda programar las sentencias de acceso a los servicios de la interface, sin embargo no podr compilar con ella su aplicacin, ya que: _ Falta la parte privada y la declaracin de los tipos privados, que sern funcin de su implementacin dentro de un componente. _ Pueden faltar constantes y tipos propios del dominio que deben ser establecidos tambin en la implementacin. En el siguiente diagrama de clases, se muestra una vista de la declaracin de la interfaz Image_Grabber. En esta vista, algunas de las clases que forman parte del modelo de informacin de la interfaz no estn explcitas, por lo que para completar el modelo, es necesario recurrir tambien a otras vista, complementarias y a la documentacin y diagramas de estado y de actividad asociadas con cada clase.
<<private type>> Video_Card
<<subtype>> PixelRGB
<<s ubtype>> PixelData
<<exception>> Start_Error
<<interface_des cr>> Im age_Grabber <<constant>> MAX_CARD : Natural <<constant>> RESOLUTION_X : Natural <<constant>> RESOLUTION_Y : Natural <<constant>> N_CHANNELS : Natural Brigthnes s_Values : Param _Value Contras t_Values : Param _Value V_Sat_Values : Param _Value U_Sat_Values : Param _Value Hue_Values : Param _Value Open_Card(n : Natural, r : Ratio) : Video_Card Clos e_Card(c : Video_Card) Start_Video(c : Video_Card, hwnd : HWND, x : Natural, y : Natural) Stop_Video(c : Video_Card) Overlays_ON(c : Video_Card, bm p : s tring, x : int, y : int, col : PixelRGB, trans : boolean) Overlays_OFF(c : Video_Card) Acquire(c : Video_Card) Snap(c : Video_Card) Read(c : Video_Card, f : Fram e, data : in out PixelData) Draw_Im age(c : Video_Card, hwnd : HWND) Set_Channel(c : Video_Card, ch : Channels ) ...
<<enum erated>> Ratio
<<exception>> End_Error
<<s ubtype>> Fram e
<<exception>> Draw_Error
<<exception>> Read_Error
<<s ubtype>> Channels
<<exception>> Pass thru_Error
<<enum erated>> Param
<<exception>> Acquisition_Error
<<s ubtype>> Param _Value
<<exception>> Config_Error
<<interface>> Envirom ent place : External(path = c:\Sauce\environm ent.m dl)
Im port: <<exception>> Unsuitable_Operation <<exception>> Value_Out_Of_Range <<type>> Byte <<type>> PVOID <<type>>HWND
La interfaz Image_Grabber que se propone como ejemplo ofrece los recursos para digitalizar y adquirir imgenes de vdeo. Es independiente de cualquier tarjeta hardware y ofrece servicios para inicializar y liberar los recursos que en cada caso se requiera, configurar
30
diciembre 2002
el proceso de digitalizacin de imgenes, transferir imgenes en vivo a una ventana de la aplicacin, transferir una imagen digitalizada a memoria, etc. El modelo de informacin necesario para hacer uso de esta interfaz, se describe constantes y atributos declarados en la clase y los tipos de datos y excepciones declarados en las clases asociadas. En la declaracin de la interfaz Image_Grabber, se indica que esta interfaz tiene una dependencia de la interfaz Environment, de la que importa dos tipos de excepciones de mayor mbito y el tipo relativo a los manejadores de ventanas Win32. En el siguiente cdigo, se muestra el fichero tipo .aci que formula la declaracin de la interface desde un punto de vista Ada. Se obtiene a partir de la especificacin abstracta UML y consiste en un fichero no compilable de declaraciones con la siguiente estructura: Dependencias externas: interfaces necesarias de Componentes externos. Constantes y subtipos: las constantes no inicializadas y los subtipos no definidos. Variables de estado: no inicializadas. Operaciones. Excepciones locales. Parte privada: no implementada.
--************************************************************************* --* * --* Declaration of Abstract MAST-Component Interface (ACI) * --* ACI Name: Image_Grabber * --* * --* * --* Documentation: * --* Conjunto de operaciones de gestin y manejo de la tarjeta de * --* adquisicin de imgenes de vdeo. * --* * --************************************************************************* --========================================================================= -- External dependency with Environment; --========================================================================= package Image_Grabber is --========================================================================= -- Declaration of exported constant, types and procedures = --========================================================================= ---------------------------------------------------------------------------- Constantes y tipos ---------------------------------------------------------------------------- Documentation -Nmero mximo de tarjetas que pueden estar registradas -simultnemente en un computador. MAX_CARD: constant Natural; -- Documentation
31
diciembre 2002
-Nmero mximo (pixels) de columnas de las imagenes adquiridas. RESOLUTION_X: constant Natural; -- Documentation -Nmero mximo (pixels) de columnas de las imagenes adquiridas. RESOLUTION_Y: constant Natural; -- Documentation -Nmero de canales de entrada de video de la tarjeta. N_CHANNELS: constant Natural;
-- Documentation: -Identificador de la tarjeta de adquisicin. type Video_Card is private; -- Documentation: -Escalado del tamao de las imagenes que se -capturaran en la tarjeta. type Ratio; -- Documentation: -Pixel RGB en formato: R-G-B. type PixelRGB; -- Documentation: -Pxels almacenados en las posiciones x,y. type PixelData; -- Documentation: -Canales de entrada de video de la tarjeta. type Channels; -- Documentation: -Parametros de la imagen. type Param; -- Documentation: -Valores maximo , minimo y nominal (por defecto) -de un parametro. type Param_Value; ---------------------------------------------------------------------------- Variables de estado ---------------------------------------------------------------------------- Documentation -Valor del brillo. Brigthness_Values: constant Param_Value; -- Documentation -Valor del contraste. Contrast_Values: constant Param_Value; -- Documentation -Valor de la saturacion V. V_Sat_Values: constant Param_Value; -- Documentation -Valor de la saturacion U. U_Sat_Values: constant Param_Value; -- Documentation
32
diciembre 2002
-Valor de la intensidad. Hue_Values: constant Param_Value; ---------------------------------------------------------------------------- Operaciones ---------------------------------------------------------------------------- Documentation: -Inicializa la tarjeta y reserva la memoria necesaria para dos -buffersde almacenamiento: uno para imgenes del vdeo en vivo y otro -para capturade imgenes estticas. Tambin se inicializan los -valores del estado de losparametros de vdeo para cada uno de los -canales (que pueden ser de distintovalor en un momento dado). -Eleva la excepcion Start_Error si se produce un error. function Open_Card(n:Natural;r:Ratio) return Video_Card; -- Documentation: -Libera los recursos asociados a la tarjeta. -Eleva la excepcion End_Error si se produce un error. procedure Close_Card(C: in out Video_Card); -- Documentation: -Comienza a mostrar el vdeo en vivo en la ventana hwnd. -La imagen aparece escalada con dimensiones x por y pixels. -La resolucin mxima es RESOLUTION_X por RESOLUTION_Y -pixels. -Se eleva la excepcin Passthru_Error si se produce un error procedure Star_Video(C: in out Video_Card; hwnd:I_Environment.HWND; x:natural; y:natural); -- Documentation: -Se detiene el video en vivo. -Se eleva la excepcin Passthru_Error si se produce un error procedure Stop_Video(C: in out Video_Card); -- Documentation: -Muestra una imagen superpuesta sobre el video en vivo -bmp es el nombre del fichero donde se encuentra la imagen -x e y son las dimensiones de la imagen de video que se -desea solapar; han de ser iguales o menores que los valores -de los parametros de la funcion VideoON -col indica el color de los pixels de la imagen que -desaparecen para permitir observar el video en vivo -Si translucent=true , la imagen superpuesta es toda -ella translucida. -Se eleva la excepcin Passthru_Error si se produce un error procedure Overlays_ON(C: in out Video_Card; bmp:in string; x:in integer; y:in integer; col:in PixelRGB; trans:in boolean); -- Documentation: -Finaliza el overlay -Es necesario invocar la funcion con el video en vivo ya detenido -Se eleva la excepcin Passthru_Error si se produce un error procedure Overlays_OFF(C: in out Video_Card); -- Documentation: -Captura una imagen y la almacena en el buffer de imagen -esttica con la resolucin mxima permitida.
33
diciembre 2002
-Se requiere que cuando se invoque no est el video en vivo. -Se eleva la excepcion Acquisition_Error si se produce un error procedure Acquire(C: in out Video_Card); -- Documentation: -Copia en el buffer de la imagen esttica la ltima imagen -almacenada en el buffer de vdeo en vivo. -Se requiere que cuando se invoque el vdeo est en vivo. -Se eleva la exception Acquisition_Error si se produce un error. procedure Snap(C: in out Video_Card); -- Documentation: -Transfiere a la memoria principal la imagen capturada -anteriormente con Acquire o Snap. -Transfiere el rectngulo determinado por los ndices de data. -Se eleva la excepcin Read_Error si se produce un error. procedure Read(C: in out Video_Card; data:in out PixelData); -- Documentation: -Muestra en una ventana la imagen capturada en el buffer de -la imagen esttica. Es necesario haber capturado previamente -una imagen con Acquire o Snap. -Se eleva la excepcin Draw_Error si se produce un error. procedure Draw_Image(C: in out Video_Card; hwnd:I_Environment.HWND); -- Documentation: -Selecciona el canal de entrada de vdeo. -Se eleva la interrupcin Config_Error si se produce un error. procedure Set_Channel(C: in out Video_Card; ch:Channels); -- Documentation: -Modifica un parmetro de las imgenes capturadas o mostradas -en vdeo en vivo en el futuro. -Se eleva la excepcin Config_Error si se produce un error. procedure Set_Parameter(C: in out Video_Card; p:Param; value:integer; ch:Channels); -- Documentation: -Devuelve el valor actual de un parmetro de las imgenes -capturadas o mostradas en vdeo en vivo en el futuro. -Se eleva la excepcin Config_Error si se produce un error. function Get_Parameter(C:Video_Card; p:Param; ch:Channels)return integer; --========================================================================= -- Declaration of exported exceptions = --========================================================================= Start_Error:exception; End_Error:exception; Draw_Error:exception; Read_Error:exception; Passthru_Error:exception; Acquisition_Error:exception; Config_Error:exception; --=========================================================================
34
diciembre 2002
-- Private interface declaration = --========================================================================= private end Image_Grabber; --=========================================================================
II.3. Especificacin de componentes La especificacin de un componente est directamente relacionada con la descripcin de los dos contratos que definen su arquitectura. Bsicamente debe describir el contrato de uso a travs de la declaracin de las interfaces que ofrece y debe describir el contrato de realizacin a travs de la declaracin de las interfaces que usa.
< <com p one nt>>
<<o ffers>>
In te rfa ce _ o ffe re d _ A In te rfa ce _ o ffe re d _ B
C om ponent
<<o ffers>>
<<use s>>
<< uses>>
In te rfa ce _ u se d _ 1 In te rfa ce _ u se d _ 2
En UML la informacin que describe un componente se incluye en un paquete con estereotipo <<component_model>> que tiene el nombre de la interfaz, y que se encuentra situado dentro del paquete Functional_View , que a su vez esta definido en Logical View del modelo. Un componente puede estar declarado independientemente en un modelo(fichero con extensin .mdl), o tambin puede estar varios de ellos agrupados y definidos conjuntamente dentro de un mismo modelo.
Model Name User Case View Logical View Functional View <<interface_model>> I_Image_Grabber <<component_model>> C_IG_DT_3153 MAST RT View Component View
Un componente se declara en UML mediante una clase con estereotipo <<component>>, que incluye:
35
diciembre 2002
Nombre del tipo de componente: coincide con el identificador de la clase <<component>>. Conjunto de interfaces ofrecidas: Se declaran como atributos o como clases agregadas de con estereotipo <<interface>>. Estas interfaces son instancias de interfaces descritas en el propio modelo o en modelos independientes. En la descripcin de cada interface se debe establecer el atributo place que describe el modelo en el que se encuentra el descriptor, este toma, por defecto, el valor model que hace referencia a que se encuentra descrita en el propio modelo del componente y en el caso de que se encuentre en un modelo externo, toma como valor el path del fichero en que se encuentra. En la declaracin de una interface ofrecida, tambin se explicitan valores iniciales de atributos y tipos que quedaron indefinidos en la declaracin de la interface. Conjunto de interfaces usadas: Se declaran como instancias de clases asociadas por dependencia. Estas interfaces, deben ser instancias de interfaz declaradas en componentes concretos. Restricciones entre interfaces: Restricciones de especificacin que se establecen entre las diferentes interfaces del componente como consecuencia de que son todas ellas ofrecidas conjuntamente por el mismo componente. Restricciones de acceso a componentes: Restricciones de especificacin que limitan las formas de uso con que las diferentes implementaciones pueden acceder a los componentes que se usan para implementar su funcionalidad. Estas restricciones se formulan, bien como texto agregado al componente o a las asociaciones de dependencia. En el diagrama de clases siguiente se muestra la descripcin del componente C_IG_DT_3153.
<<interface_ref>> Image_Grabber p lace : File(path = c: \Reposit ory\ Im age_G rabb er. mdl ) <<implements>> <<component> > C_IG_DT3153 <<offers>> I_Image_Grabber <<uses>> <<offers>> I_Environment <<component> > C_Sauce place : File(path = c:\Repository\Sauce.mdl)
La interface concreta <<interface>>I_Image_Grabber que ofrece, resulta de instanciar la interface abstracta <<interface_descr>>Image_Grabber. Como se muestra en el siguiente
36
diciembre 2002
diagrama de clases UML que describe la instancia, esta resulta de establecer los siguientes elementos que en la clase abstarcta estaban indefinidos: Se ha establecido que la interfaz del tipo <<interface_descr>>Environment que usa la interfaz concreta <<interface>>I_Image_Grabber del componente C_IG_DT3153 es la interfaz concreta <<interface>>I_Environment ofrecida por el componente C_Sauce que est descrito en el fichero c:\Repository\Sauce.mdl. Se ha establecido los valores de la constantes MAX_CARD, RESOLUTION_X, RESOLUTION_Y y N_CHANNELS. Se han definido de forma concreta de los tipos: PixelRGB, Frame, Ratio, Param, PixelData, Channels, Param_Value. Se han establecido valores iniciales de las variables: Brigthness_Values, Contrast_Values, V_Sat_Values, U_Sat_Values y Hue_Values. Se ha concretado el valor por defecto del parmetro r de la operacin Open_Card.
<<Interface>> I_Image_Grabber <<constant>> MAX_CARD : N atural = 1 <<constant>> RESOLU TION_X : Natural = 768 <<constant>> RESOLU TION_Y : Natural = 576 <<constant>> N_CH AN NEL S : Natural = 3 Bri gthness_Val ues : Param_Val ue = 0 ,255,163 Contrast_Values : Param_Value = 0,511,256 V_Sat_Values : Param_Value = 0,511,180 U_Sat_Value s : Param_Value = 0,51 1,254 Hue_Val ues : Param _Value = 0,255,128 Open_Card(n : Natural, r : Ratio = R_1) : Video_Card <<type>> PixelRGB P : array(0..2) of I_Environment.Byte <<type>> Frame x : Natural y : Natural width : Positive height : Positive
<<enumerated>> Ratio <<enum>> R_1 <<enum>> R_2 <<enum>> R_4 <<enum>> R_8 <<enum>> R_16 <<enum>> R_32
<<enumerated>> Param Brigthness : enum Contrast : enum V_Sat : enum U_Sat : enum Hue : enum <<type>> PixelData
P : (Natural range<>,Natural range<>)of PixelRGB
<<type>> Channels C : Natural range 0..N_CHANNELS-1
<<type>> Param_Value MIN : Integer MAX : Integer NOMINAL : Integer
<<implements>> I_Enviroment
<<in terface_ref>> Image_Grabber place : File(path = c:\Repository\Image_Grabber.mdl)
En el suguiente listado se muestra el cdigo Ada95 que corresponde a la descripcin UML del componente C_IG_DT3153 establecido.
--***************************************************************************** --* * --* Declaration of a MAST-Componet (CMP) * --* CMP Name: C_IG_DT3153 * --* * --* * --* Documentation: * --* Componente de gestin de la tarjeta de adquisicin de video DT3153. *
37
diciembre 2002
--* * --* Implementa la Interface: * --* I_Image_Grabber * --* * --***************************************************************************** --***************************************************************************** -- External dependency with C_Sauce; --***************************************************************************** package C_IG_DT3153 is --***************************************************************************** -- Declaration of exported interfaces * --***************************************************************************** --************************************************************************* --* * --* Declaration of Concrete MAST-Componet Interface (CCI) * --* CCI Name: I_Image_Grabber * --* * --* * --* Documentation: * --* Conjunto de operaciones de gestin y manejo de la tarjeta de * --* adquisicin de imgenes de vdeo. * --* * --************************************************************************* --========================================================================= -- External dependency --with I_Environment; -- => C_SAUCE.I_Enviroment --========================================================================= package I_Image_Grabber is --========================================================================= -- Declaration of exported constant, types and procedures = --========================================================================= ---------------------------------------------------------------------------- Constantes y tipos ---------------------------------------------------------------------------- Documentation -Nmero mximo de tarjetas que pueden estar registradas -simultnemente en un computador. MAX_CARD: constant Natural:= 1; -- Documentation -Nmero mximo (pixels) de columnas de las imagenes adquiridas. RESOLUTION_X: constant Natural:= 768; -- Documentation -Nmero mximo (pixels) de columnas de las imagenes adquiridas. RESOLUTION_Y: constant Natural:= 576; -- Documentation -Nmero de canales de entrada de video de la tarjeta. N_CHANNELS: constant Natural:= 3; -- Documentation: -Identificador de la tarjeta de adquisicin. type Video_Card is private; -- Documentation: -Escalado del tamao de las imagenes que se
38
diciembre 2002
-capturaran en la tarjeta. -R_1 corresponde a la resolucion mxima -R_n corresponde a escalar la resolucion mxima -dividiendo por n type Ratio is (R_1,R_2,R_4,R_8,R_16,R_32); -- Documentation: -Pixel RGB en formato: R-G-B. type PixelRGB is array(0..2)of C_Sauce.I_Environment.byte; -- Documentation: -Pxels almacenados en las posiciones x,y. type PixelData is array(natural range<>,netural range<>)of PixelRGB; -- Documentation: -Canales de entrada de video de la tarjeta. type Channels is new Integer range 0..N_CHANNELS-1; -- Documentation: -Parametros de la imagen. type Param is(Brigthness,Contrast,V_Sat,U_Sat,Hue); -- Documentation: -Valores maximo , minimo y nominal (por defecto) -de un parametro. type Param_Value is record MIN:integer; MAX:integer; NOMINAL:integer; end record; ---------------------------------------------------------------------------- Variables de estado ---------------------------------------------------------------------------- Documentation -Valor del brillo. Brigthness_Values: constant Param_Value:= (0,255,163); -- Documentation -Valor del contraste. Contrast_Values: constant Param_Value:= (0,511,256); -- Documentation -Valor de la saturacion V. V_Sat_Values: constant Param_Value:= (0,511,180); -- Documentation -Valor de la saturacion U. U_Sat_Values: constant Param_Value:= (0,511,254); -- Documentation -Valor de la intensidad. Hue_Values: constant Param_Value:= (0,255,128); ---------------------------------------------------------------------------- Operaciones ---------------------------------------------------------------------------- Documentation: -Inicializa la tarjeta y reserva la memoria necesaria para dos -buffers de almacenamiento: uno para imgenes del vdeo en vivo y -otro para capturade imgenes estticas. Tambin se inicializan los
39
diciembre 2002
-valores del estado de losparametros de vdeo para cada uno de -los canales (que pueden ser de distintovalor en un momento dado). -Eleva la excepcion Start_Error si se produce un error. function Open_Card(n:Natural;r:Ratio:=R_1) return Video_Card; -- Documentation: -Libera los recursos asociados a la tarjeta. -Eleva la excepcion End_Error si se produce un error. procedure Close_Card(C: in out Video_Card); -- Documentation: -Comienza a mostrar el vdeo en vivo en la ventana hwnd. -La imagen aparece escalada con dimensiones x por y pixels. -La resolucin mxima es RESOLUTION_X por RESOLUTION_Y -pixels. -Se eleva la excepcin Passthru_Error si se produce un error procedure Star_Video(C: in out Video_Card; hwnd:C_Sauce.I_Environment.HWND; x:natural; y:natural); -- Documentation: -Se detiene el video en vivo. -Se eleva la excepcin Passthru_Error si se produce un error procedure Stop_Video(C: in out Video_Card); -- Documentation: -Muestra una imagen superpuesta sobre el video en vivo -bmp es el nombre del fichero donde se encuentra la imagen -x e y son las dimensiones de la imagen de video que se -desea solapar; han de ser iguales o menores que los valores -de los parametros de la funcion VideoON -col indica el color de los pixels de la imagen que -desaparecen para permitir observar el video en vivo -Si translucent=true , la imagen superpuesta es toda -ella translucida. -Se eleva la excepcin Passthru_Error si se produce un error procedure Overlays_ON(C: in out Video_Card; bmp:in string; x:in integer; y:in integer; col:in PixelRGB; trans:in boolean); -- Documentation: -Finaliza el overlay -Es necesario invocar la funcion con el video en vivo ya detenido -Se eleva la excepcin Passthru_Error si se produce un error procedure Overlays_OFF(C: in out Video_Card);
-- Documentation: -Captura una imagen y la almacena en el buffer de imagen -esttica con la resolucin mxima permitida. -Se requiere que cuando se invoque no est el video en vivo. -Se eleva la excepcion Acquisition_Error si se produce un error procedure Acquire(C: in out Video_Card); -- Documentation: -Copia en el buffer de la imagen esttica la ltima imagen -almacenada en el buffer de vdeo en vivo. -Se requiere que cuando se invoque el vdeo est en vivo. -Se eleva la exception Acquisition_Error si se produce un error. procedure Snap(C: in out Video_Card);
40
diciembre 2002
-- Documentation: -Transfiere a la memoria principal la imagen capturada -anteriormente con Acquire o Snap. -Transfiere el rectngulo determinado por los ndices de data. -Se eleva la excepcin Read_Error si se produce un error. procedure Read(C: in out Video_Card; data:in out PixelData); -- Documentation: -Muestra en una ventana la imagen capturada en el buffer de -la imagen esttica. Es necesario haber capturado previamente -una imagen con Acquire o Snap. -Se eleva la excepcin Draw_Error si se produce un error. procedure Draw_Image(C: in out Video_Card; hwnd:C_Sauce.I_Environment.HWND); -- Documentation: -Selecciona el canal de entrada de vdeo. -Se eleva la interrupcin Config_Error si se produce un error. procedure Set_Channel(C: in out Video_Card; ch:Channels); -- Documentation: -Modifica un parmetro de las imgenes capturadas o mostradas -en vdeo en vivo en el futuro. -Se eleva la excepcin Config_Error si se produce un error. procedure Set_Parameter(C: in out Video_Card; p:Param; value:integer; ch:Channels); -- Documentation: -Devuelve el valor actual de un parmetro de las imgenes -capturadas o mostradas en vdeo en vivo en el futuro. -Se eleva la excepcin Config_Error si se produce un error. function Get_Parameter(C:Video_Card; p:Param; ch:Channels)return integer; --========================================================================= -- Declaration of exported exceptions = --========================================================================= Start_Error:exception; End_Error:exception; Draw_Error:exception; Read_Error:exception; Passthru_Error:exception; Acquisition_Error:exception; Config_Error:exception; --========================================================================= -- Private interface declaration = --========================================================================= private type Video_Card is new Integer range 0..MAX_CARD-1; end I_Image_Grabber; --========================================================================= --*****************************************************************************
41
diciembre 2002
-- Private component declaration * --***************************************************************************** end;
II.4. Proceso de automatizacin de la gestin de componentes La metodologa de diseo basada en componentes que se propone en este trabajo se basa en el modelado UML de las interfaces y de los componentes. Esto requiere disponer de herramientas que ayuden a la generacin y validacin del cdigo Ada que implementa estos componentes y de herramientas que generen el entorno UML que se requiere para el desarrollo de una aplicacin. Estas herramientas no son desarrolladas en el presente proyecto, pero si que trataremos en este apartado de obtener las claves para su implementacin en el futuro. En la siguiente figura se muestran las dos herramientas bsicas de generacin de cdigo Ada que se necesitan:
< < in terfa ce_ m d l> >
< < co m p o n en t_ m d l> >
in terfa c e _ c o d e g e n e rato r
c o m p o n e n t_ c o d e g e n e rato r
co m p o n en t.a ci
co m p o n en t.a d s
co m p o n en t.a d b
Generador del cdigo de interfaces: Una interfaz representa una especificacin de servicio y un modelo de informacin autocontenido. La herramienta que se propone tiene dos objetivos: _ Verificar la consistencia y completitud del modelo UML que constituye la descripcin de la interfaz.
42
diciembre 2002
_ Generar el cdigo fuente Ada de la interfaz. Este cdigo debe ser una especificacin Ada compilable que pueda ser utilizada para compilar las aplicaciones de usuario que la utilicen. Generador del cdigo de componentes: La herramienta integra la informacin contenida en el modelo del componentes y de las interfaces que implementa para generar el cdigo compilable que constituye la implementacin utilizable del componente. Esta herramienta lleva a cabo las siguientes tareas: _ Verifica la consistencia y complititud del modelo UML del componente. _ Verifica la existencia de los ficheros que contienen la descripcin de las interfaces que el componente debe implementar, y comprueba la consistencia de la descripciones que contienen. _ Genera un fichero fuente Ada con la especificacin completa y compilable del componente. _ Genera un fichero fuente Ada con el esqueleto del cuerpo del componente, conteniendo el encabezamiento del propio cuerpo del paquete y con la estructura de paquetes internos y de encabezamientos de los procedimientos y funciones que se correspondan con la especificacin. Este fichero deber ser completado por el programador con el cdigo que requiera la implementacin de las partes declarativas y los cuerpos de los procedimientos y funciones cuyas cabeceras se hayan incluido.
43
modelo de tiempo real de los componentes
diciembre 2002
III. MODELO DE TIEMPO REAL DE LOS COMPONENTES

III.1. Modelo de tiempo real de una aplicacin basada en componentes El modelo de tiempo real de un componente contiene la informacin estructural y los datos necesarios para poder formular el modelo de tiempo real de cualquier aplicacin que los incluya. El modelo de tiempo real de un componente aporta los modelos de los recursos hardware y software, los requerimientos de procesamiento y los artefactos de sincronizacin que se incorporan a la aplicacin con el uso o acceso al componente. El modelo de tiempo real de un componente solo aporta aquellos elementos que estn incluidos en el componente, y por ello, no constituye en s una instancia de modelo, sino un descriptor parametrizado que permitir contruir el modelo de la aplicacin que hace uso de l, cuando se definan los modelos de los otros componentes de los que hace uso el componente para ofrecer su funcionalidad y cuando se concreten los parmetros que establezcan la forma en que hace uso de l la aplicacin. El modelo de tiempo real de un componente, se describe como una clase UML de estereotipo <<component_descr>> que aporta: Identificador que debe ser invocado para instanciar un componente que corresponda al modelo. Descriptor de componente del que, en su caso, puede heredar sus caractersticas. Un dominio de nombres, que puede ser utilizado para referenciar los componentes internos que estn declarados en el modelo y que se instancia con cada instancia del componente. Parmetros con sus tipos, y en su caso, valores por defecto de los parmetros que deben ser establecidos en la instanciacin del componente, para especificar el uso que de l se hace. Referencias de los modelos de otros componentes, de los que depende la instancia del modelo del componente, y que deben ser resueltos en la instanciacin del modelo del componente. Conjunto de modelos de las operaciones, en su caso, organizadas por interfaces, que pueden ser referenciadas por la aplicacin o por los modelos de otros componentes, a fin de formular su propio modelo de tiempo real. En este captulo se muestra la estructura y la informacin asociada a dos componentes caractersticos de los desarrollados en este proyecto. En primer lugar, se describe el modelo del componente NT_Processor_Mdl_1 que representa la plataforma hardware/software sobre la que se ha desarrollado la aplicacin. Este es un componente tpico de un recurso hardware/ software, que modela una plataforma. En segundo lugar, se describe el componente C_IG_DT3153, que modela un componente hardware/software relativo a una tarjeta de captura, digitalizacin y almacenamiento de imagenes de vdeo, y al driver software de control de la misma.
44
diciembre 2002
En el prximo captulo, se utilizarn instancias de los modelos de estos componentes, as como la de los otros dos componentes desarrollados a fin de modelar el anlisis de planificabilidad y estimar el comportamiento de tiempo real del demostrador que se ha construido en este proyecto.
III.2. Descripcin de la plataforma WINDOWS NT Windows NT ha sido diseado como un sistema operativo de propsito general (GPOS1). Sin embargo, al no ser un sistema operativo de tiempo real RTOS2 puede presentar serias dificultades para el que se ve obligado a desarrollar un sistemas de tiempo real con l. Para que un sistema operativo pueda considerarse RTOS3 ha de tener entre otras las siguientes caractersticas [20]: Tiene que ser multitarea y expulsor. Ha de tener capacidad de priorizar las tareas. Tiene que implementar mecanismos de sincronizacin de tareas que tengan una temporizacin predecible. Ha de existir un sistema de herencia de prioridades que evite el problema de inversin de prioridad. Este problema se puede evitar con un diseo correcto , pero en sistemas complejos esto puede ser bastante complicado. El comportamiento del RTOS ha de ser conocido y predecible. Es interesante conocer diversos aspectos sobre el funcionamiento del sistema operativo Windows NT relativos a sistemas de tiempo real para comprobar si en nuestro caso puede ser utilizado como RTOS: Las aplicaciones de tiempo real utilizan un sistema de interrupciones para asegurar que los eventos externos son detectados por el sistema operativo. Es importante que estas interrupciones sean tratadas oportunamente de acuerdo a su prioridad. El kernel de Windows NT puede operar a uno de 32 niveles posibles de interrupcin , tal como se puede ver en la prxima figura. Cuando se produce una interrupcin, inmediatamente se ejecuta una pequea rutina de atencin llamada ISR4 que realiza nicamente las labores crticas (tpicamente la escritura o lectura de registros hardware). Ms adelante se completar la atencin a la interrupcin mediante la ejecucin de una rutina DPC5. Este mecanismo es necesario ya que cuando se produce una interrupcin de nivel n se enmascaran todas las dems interrupciones de nivel inferior hasta que se completa su ISR correspondiente.
1. 2. 3. 4. 5.
General Purpose Operating System. Real Time Operating System. Real Time Operating System. Interrupt Servicing Routine. Deferred Procedure Call.
45
diciembre 2002
Los APC1 permiten generar interrupciones software desde los programas de usuario. varias funciones de la API Win32 , como por ejemplo ReadFileEx o WriteFileEx , utilizan estos mecanismos.
IR Q Ls
31 30 29 28 H ig h P ow er Fail Inte rp ro ce sso r Interrup t C lo ck D evice n . . . D evice 1 2 Thread Priorities 0-31 1 0 D ispa tch / D P C APC P asive Level Software Interrupts Hardwa re Inte rrupts
Durante el funcionamiento normal del sistema se ejecutan concurrentemente varios procesos. Cada uno de ellos se compone de uno o varios threads. Es el planificador (dispatcher) quien decide que thread se ejecuta en cada instante de tiempo. Los diferentes estados en que se puede encontrar un thread son los siguientes [21]: Ready: thread dispuesto para competir en la planificacin. Standby: thread seleccionado por el planificador para ejecutarse a continuacin. Running: thread en ejecucin actualmente. Waiting: thread en espera de un recurso. Transition: thread que se puede considerar como ready pero que su stack an no se ha cargado en memoria.
1. Asynchronous Procedure Call.
46
diciembre 2002
Terminated: thread finalizado.

C reate and initialize thread object
R einitialize
Initialized
Place in ready queu e
Term inated
T a n h re ob ad je w a c t it ha s o W nd n ai le ti s co m pl et e
Waiting
K ernel stack outswapped
W ait is co m plete
K e in r n s w el a p s ta pe ck d
Ready
Execution co m pletes
Transition
Select for execution
Running
Preem pt (or tim e quantum ends)
Standby
Preem pt
C ontext-sw itch to it an d start its execution (dispatching)
Cuando el planificador tiene que decidir que thread se ejecuta a continuacin , lo primero que hace es ver si existe algn DPC pendiente. En caso afirmativo ste se ejecuta. En caso negativo se selecciona el thread de mayor prioridad. Los niveles de prioridad de los threads en Windows NT son 32 (0-31) , aunque en realidad no todos son utilizables. El programador de aplicaciones puede determinarlo fijando las prioridades del proceso (Win32 process priority class) y del thread (Win32 thread priority).
W in32 process p riority classes
R eal Tim e Tim e critical H ig hest 31 26 25 24 23 22 16 H ig h 15 15 14 13 12 11 1 N orm al 15 10 9 8 7 6 1 Idle 15 6 5 4 3 2 1
W in32 thread p riorities
A bove norm al N orm al B elow norm al Low e st Idle
47
diciembre 2002
Se distinguen dos tipos de prioridades: las dinmicas (0-15) y las de tiempo real (16-31).
En los threads que tienen asignada una prioridad dinmica, es posible que el sistema operativo cambie su prioridad en un momento dado (boost priority) para optimizar el rendimiento (por ejemplo al entrar en un estado wait , despus de una I/O , en tareas que tras muchos ciclos an no han conseguido el control de la CPU , ... ). Todos los threads de procesos propios del sistema operativo tienen prioridades dentro de este rango. En los threads que tienen asignada una prioridad de tiempo real , sta no varia durante toda su ejecucin (salvo que el programador lo especifique as en el cdigo de la aplicacin). Slo pueden tener este rango de prioridades threads propios de aplicaciones de usuario, de modo que siempre sern ms prioritarios que los procesos del sistema operativo.
III.3. Modelo de tiempo real de la plataforma WINDOWS NT De acuerdo a lo expuesto en el apartado anterior, podemos contemplar la utilizacin del sistema operativo Windows NT para sistema de tiempo real bajo unas determinadas condicionees: Los threads de la aplicacin tienen prioridades de tiempo real. No existe conexin a red de comunicacin externa. Se dispone de suficiente memoria como para evitar el uso de memoria virtual (I/O a disco). Es la nica aplicacin que se est ejecutando en el computador. En este trabajo se ha formulado el modelo de tiempo real de la plataforma Windows NT que utilizaremos posteriormente en la aplicacin que se desarrolla. El modelo describe un computador concreto que opera bajo el sistema operativo Windows NT Server 4.0.
48
diciembre 2002
El componente NT_Processor_Mdl_1 es el modelo CBSE_MAST del procesador que se ha utilizado como plataforma para desarrollar la aplicacin desarrollada como demostrador en este proyecto. Es un computador Pentium III a 800 MHz que opera con el sistema operativo Windows NT 4.1 Server. El modelo NT_Processor_Mdl_1 describe la potencia de procesado que suministra el procesador, as como la totalidad de las tareas de background que introduce el sistema operativo para gestin de los recursos que interfieren la ejecucin de la aplicacin por ejecutarse a prioridad superior de las que se ejecutan sus tareas. En la siguiente figura se muestra el modelo de la plataforma utilizando el perfil CBSE_MAST [23]. El modelo se describe mediante el elemento NT_Processor_Mdl_1, que agrega internamente un conjunto de componentes subordinados. El modelo de la plataforma tiene el objeto de describir la capacidad de computacin que se dispone para la ejecucin de la aplicacin, y esta resulta de considerar la que proporciona el procesador del computador, y de restarle la que se consume por las procesos de background que introduce el sistema operativo en la gestin de los diferentes recursos (timer, drivers, rutinas de recuperacin, etc.). La potencia que proporciona el procesador se modela mediante un componente del tipo MAST_FP_ Processor, el consumo por gestin del timer se modela mediante un elemento del tipo MAST_ Timer, que en este caso es del tipo especialicado MAST_Ticker, y el consumo de las otras rutinas de gestin se modelan como un conjunto de componentes del tipo MAST_Interference.
49
diciembre 2002
<<MAST_Component_Descr>>
NT_Processor_Mdl_1 <<ref>> host = proc
<<obj>> proc <<MAST_FP_Processor>> <<obj>>
Processor_Decl <<par>> Speed_Factor = 1.0 <<par>> Max_Priority = 31 <<par>> Min_Priority = 16 <<par>> Max_Interr_Priority = 32 <<par>> Min_Interr_Priority = 32 <<par>> Worst_Context_Switch = 5.3E-6 <<par>> Avg_Context_Switch = 4.2E-6 <<par>> Best_Context_Switch = 3.6E-6
sy stemTi me r <<MAST_Ti cke r>>
T imer_Decl <<par>> Worst_Overhead = 25.4E-6 <<par>> Avg_Overhead = 9.6E-6 <<par>> Best_Overhead = 1.9E-6 <<par>> Period = 1.0E-2
<<obj>> << obj>>
<<MAST_Interference>>
HiFrecInterferenc e_Decl <<obj>> trigger = MAST_Periodic_Event_Source(Period=16.6E-3) <<obj>> System_SS : MAST_FP_Sched_Server(policy = MAST_Interrupt_FP_Policy(priority = MAX_Interr_Priority))
HiFrecInterrference
<<simple>> + oper(wcet = 32.3E-6, bcet = 15.3E-6)
<<MAST_Interference>>
LoFrecInterference_Decl
LoFrecInterference
<<obj>> trigger = MAST_Periodic_Event_Source(Period=4.06E0) <<obj>> System_SS : MAST_FP_Sched_Server(policy = MAST_Interrupt_FP_Policy(priority = MAX_Interr_Priority)) <<job>> + oper() <<simple>> + Activity_1(wcet = 111.5E-6, bcet = 99.7E-6) <<job>> + delay_1(theDelay = 508.0E-6) <<simple>> + Activity_2(wcet = 89.7E-6, bcet = 87.2E-6) <<job>> + delay_2(theDelay = 838, 0E-6) <<simple>> + Activity_3(wcet = 108.1E-6, bcet = 103, 9E-6)
A c tivity m ode l of << job > > O per L o_ Freq Interfe rnc e.System _S S
< < M A S T _ W ait_ State> >
Trigge r
A c t_1
d o/A ctiv ity _ 1
< < M A S T _ D e la y > >
A c t_2
d o/D ela y (d = 5 0 8 .0 E -6 )
< < M A S T _ D e la y > >
A c t_3
d o/A ctiv ity _ 2
A c t_4 A c t_5
d o/A ctiv ity _ 3 d o/ D e la y (d= 8 3 8 .0 E -6 )
El componente NT_Processor_Mdl_1 describe el modelo de tiempo real de la plataforma. Es un elemento contenedor que se usa para proporcionar el identificador con que se puede hacer referencia al descriptor del modelo completo. Tiene los siguientes elementos agregados: <<ref>>host: Es una referencia predefinida para cualquier componente y especfica el modelo del procesador en que se instancia el componente. Aunque habitualmente es una referencia cuyo valor es establecido en la instanciacin, en este caso se puede
50
diciembre 2002
resolver en el propio descriptor. Se le asigna el valor proc que es la referencia interna al procesador que tambin se declara en el propio componente. <<MAST_FP_Processor>> proc: Es el componente de modelado que describe la capacidad de procesamiento del procesador que ejecuta el cdigo de la aplicacin. La capacidad de cmputo que representa se emplea en la ejecucin de las actividades de la aplicacin que tiene asignadas y en la ejecucin de las tareas de gestin, monitorizacin y cambio de contexto entre actividades. Opera bajo una estrategia de prioridad fija. Sus elementos agregados son: _ <<par>>Speed_Factor: es un atributo escalar que describe la capacidad de procesamiento del recurso (el tiempo fsico de ejecucin de cualquier actividad que se ejecute en el recurso se obtendr dividiendo el tiempo normalizado de ejecucin (WCET , ACET , BCET , ... ) establecido en las operaciones que lleva a cabo , por el factor de velocidad). En este caso tiene asignado el valor 1.0. ya que este procesador es el que se ha utilizado para evaluar los tiempos de ejecucin de las diferentes actividades. _ <<par>>Max_Priority: mximo nivel de prioridad para un proceso de aplicacin que se ejecuta en el procesador. Se le asigna el valor 31 que corresponde a la prioridad mas alta para un proceso de aplicacin de tiempo real en NT_Window. _ <<par>>Min_Priority: mnimo nivel de prioridad para un proceso de aplicacin que se ejecuta en el procesador. Se le asigna el valor 16 que corresponde a la prioridad mas baja para un proceso de aplicacin de tiempo real en NT_Window. _ <<par>>Max_Interr_Priority: mximo nivel de prioridad para una rutina de interrupcin de aplicacin que se ejecuta en el procesador.Se le asigna el valor 32, pero su valor es irrelevante salvo en que es superior a las prioridades de aplicacin. _ <<par>>Min_Interr_Priority: mnimo nivel de prioridad para una rutina de interrupcin de aplicacin que se ejecuta en el procesador.Se le asigna el valor 32, pero su valor es irrelevante salvo en que es superior a las prioridades de aplicacin. _ <<par>>Worst_Context_Switch: tiempo mximo de cmputo (peor caso) que el procesador emplea en realizar un cambio de contexto entre procesos de aplicacin. _ <<par>>Avg_Context_Switch: tiempo promedio de cmputo que el procesador emplea en realizar un cambio de contexto entre procesos de aplicacin. _ <<par>>Best_Context_Switch: tiempo mnimo de cmputo (mejor caso) que el procesador emplea en realizar un cambio de contexto entre procesos de aplicacin. _ <<par>>Worst_ISR_Switch: tiempo mximo de cmputo (peor caso) que el procesador emplea en realizar un cambio de contexto a una interrupcin. Se le asigna el valor 0.0 (default value)
51
diciembre 2002
_ <<par>>Avg_ISR_Switch: tiempo promedio de cmputo que el procesador emplea en realizar un cambio de contexto a una interrupcin. Se le asigna el valor 0.0 (default value) _ <<par>>Best_ISR_Switch: tiempo mnimo de cmputo (mejor caso) que el procesador emplea en realizar un cambio de contexto a una interrupcin. Se le asigna el valor 0.0 (default value) _ <<obj>>SystemTimer: Modelo de gestin del timer. Se describe en la siguiente seccin. <<MAST_Ticker>> proc.SystemTimer: Modela la carga de procesamiento que supone para el procesador la gestin de un timer basado en interrupciones hardware peridicas. As mismo modela la granularidad en la medida del tiempo por parte del sistema operativo que introduce el timer. Sus parmetros son: _ <<par>>Worst_Overhead: tiempo mximo de cmputo (peor caso) que el procesador emplea en gestionar la atencin a los plazos de temporizacin pendientes. Se le asigna el valor 25.4E-6 segundo. _ <<par>>Avg_Overhead: tiempo promedio de cmputo que el procesador emplea en gestionar la atencin a los plazos de temporizacin pendientes. Se le asigna el valor 9.6E-6 segundo. _ <<par>>Best_Overhead: tiempo mnimo de cmputo (mejor caso) que el procesador emplea en gestionar la atencin a los plazos de temporizacin pendientes. Se le asigna el valor 1.9E-6 segundo. _ <<par>>Period: periodo de tiempo entre dos evaluaciones del ticker. Este tiempo representa la granularidad de apreciacin del tiempo del procesador. Se le asigna el valor 1.0E-2 segundo. En la siguiente seccin III.4., se describe el mtodo de evalucin de estos parmetros. <<MAST_Interference>> : Modela la carga de procesamiento que supone para el procesador una interrupcin peridica que se produce en el procesador y que es atendida por ste. El origen puede ser diverso (tarjetas hardware , software , ...). En el modelo de una plataforma Windows NT puede existir una, varias o ninguna MAST_Interference. Una MAST_Interference tiene agregados dos elementos internos: <<obj>>Trigger: _ Es un componente del tipo << Mast_Periodic_Event_Source>> que modela el patrn de disparo de la interferencia. En este caso,tiene un nico parmetro interno <<par>>period. _ <<obj>>System_SS: Modela el proceso (<<MAST_FP_Sched_Server>>) en el que se planifica y ejecuta las actividades que se ejecutan. La poltica de planificacin que se le ha asociado es del tipo <<MAST_Interrupt_FP_Policy>> y est caracterizada a su vez por el atributo <<par>>priority. En este caso, se le asigna el valor proc.Max_Interr_Priority definida en el procesador.
52
diciembre 2002
_ <<usage>> Oper: Operacin que describe el cdigo que se ejecuta en cada invocacin de la interference. Puede ser simple (<<simple>>) o compuesta (<<job>>). En este ltimo caso ha de estar descrita en su diagrama de actividad correspondiente.
III.4. Estimacin de los valores de los parmetros del modelo de la plataforma
III.4.1. FP_Processor El valor del Speed_Factor es una constante de proporcionalidad respecto a un sistema de referencia. En nuestro caso, como el sistema que modelamos es a su vez el que se utiliza como herramienta de estimacin de tiempos de ejecucin, Speed_Factor = 1.0. Las prioridades de los threads de nuestras aplicaciones han de ser de tiempo real , de modo que Max_Priority = 31 y Min_Priority = 16. Hay que tener en cuenta que , a pesar de estos valores , slo disponemos de 7 valores efectivos de prioridad: 16 , 22 , 23 , 24 , 25 , 26 y 31. Cualquier interrupcin es ms prioritaria que cualquier thread de usuario. Adems , no nos importa cual es ms prioritaria entre ellas. Por ello , podemos fijar Max_Interr_Priority = Min_Interr_Priority = 32. Los tiempos de cambio de contexto se estimaron mediante dos pruebas de medida: 1) Evaluacin del tiempo de lectura del reloj de tiempo real. Se ejecuta un programa que lee de forma sucesiva y en un gran nmero de veces el reloj del sistema. El pseudocdigo del programa que realiza esta medida, es:
Procedure Test_Lectura; T:array (1..100000) of T_fisico; begin Establece prioridad a un nivel de tiempo real; for n in 1..100000 loop T[n]=Lee_tiempo_fisico; end loop; Guarda el array en un fichero para su analisis; end;
Se calculan las diferencias T[i+1]-T[i] entre los sucesivos tiempos que se obtienen de la ejecucin de este programa. De estos se eliminan todas las que superan un valor umbral prximo a los valores ms bajos, que corresponden a ejecuciones del bucle en las que se han producido algn tipo de interrupcin o interferencia, y del resto ( que corresponden a ejecuciones bases del bucle ) se calcula la media aritmtica. De este modo se obtiene el tiempo medio de la llamada al sistema para la medida del reloj que en nuestro caso resulta ser: TClock = 6.46 seg. Este valor ser utilizado en este y en otros anlisis posteriores.
53
diciembre 2002
2) Estimacin de los tiempo de cambios de contexto. A continuacin se ejecuta un programa con dos tareas a nivel de prioridad de tiempo real. Cada tarea lee sucesivamente el reloj del sistema un nmero de veces (25 veces) y luego realiza una sincronizacin con la segunda tarea que continua la lectura del reloj.
Procedure Test_Ctxt; T:array (1..20000) of T_fisico; m:integer=1; Tarea_1 is for i in 1..400 loop accept t1; for j in 1..25 loop T[m]=Lee_tiempo_fisico; m=m+1; end loop; entry t2; end loop; end Tarea_1; Tarea_2 is for i in 1..400 loop accept t2; for j in 1..25 loop T[m]=Lee_tiempo_fisico; m=m+1; end loop; Si i<>400 entonces entry t1; end loop; Guarda el array en un fichero para su analisis; end Tarea_2; begin Establece prioridad a un nivel de tiempo real; entry t1; end
Se calculan las listas de diferencias de sucesivas lecturas de tiempo, de ellas existirn 24 tiempos bases, mientras que los cambios de contexto aparecen en los ndices mltiplos de 25. Se extraen de la lista esos valores, se promedian y se les resta el tiempo base TClock de ejecucin del bucle. Con los valores obtenidos realizamos un anlisis estadstico y estimamos los tiempos de contexto: Worst_Context_Switch = 5.3 seg. Avg_Context_Switch = 4.2 seg. Best_Context_Switch = 3.6 seg. Este proceso se puede automatizar incluyendo en los algoritmos anteriores el anlisis estadstico, de modo que tengamos un programa que al ejecutarlo sobre otro PC con Windows NT nos devuelva directamente los valores de los parmetros del modelo.
54
diciembre 2002
III.4.2. Interferences y Ticker En el Test_Lectura detallado en el apartado anterior para estimar el tiempo base de lectura del reloj de tiempo real, se observan una serie de valores de tiempos entre lecturas del reloj que superan significativamente el tiempo base TClock. Se considera que cada vez que aparece uno de ellos es consecuencia de que durante la ejecucin de ese bucle se ha producido una interrupcin (relevante). A simple vista se aprecian dos tipos de interrupciones peridicas: unas simples, en las que cada cierto tiempo se produce un incremento superior a TClock , y otras ms complejas, en las que cada cierto tiempo se desencadena una sucesin de incrementos superiores a TClock siguiendo un patrn determinado. En nuestro caso aparecen dos interrupciones simples y una compuesta. En la figura se han representado en una grfica los tiempo entre lecturas, frente al tiempo fsico de medida. Se aprecia claramente las dos interrupciones simples , que en este caso ambas son de alta frecuencia: Cada punto de la grfica representa una interrupcin , y si a su valor le restamos el de TClock obtenemos el tiempo total de atencin ( ISR + DPC ) a dicha interrupcin. Analizando estos valores detectamos dos interrupciones peridicas simples con los siguientes parmetros:
Interrupciones peridicas
0,00005 0,000045 0,00004 0,000035 0,00003 0,000025 0,00002 0,000015 0,00001 0,000005 0 0 0,1 0,2 0,3 0,4 0,5
Incrementos (seg.)
Tiempo fsico (seg.)
Para la interrupcin 1: Periodo = 10 mseg. T_Atencin_Mximo = 25.4 seg. T_Atencin_Medio = 9.6 seg. 55
diciembre 2002
T_Atencin_Mnimo = 1.9 seg. Para la interrupcin 2: Periodo = 16.3 mseg. T_Atencin_Mximo = 32.3 seg. T_Atencin_Medio = 23.5 seg. T_Atencin_Mnimo = 15.3 seg. Estos valores se pueden obtener de forma automatizada implementando un algoritmo de anlisis espectral. Se ha hecho utilizando la herramienta informtica MATLAB 5.3. de la empresa MathWorks , Inc. Se han seguido los siguientes pasos: Se elimina el nivel de continua ( TClock ) de los datos y se normaliza el tiempo de muestreo ( en nuestro caso a 1 mseg.).
56
diciembre 2002
Se aplica la transformada rpida de Fourier y se obtienen las frecuencias fundamentales. En nuestro caso resultan ser 61.34 Hz ( periodo de 16.3 mseg.) y 100 Hz ( periodo de 10 mseg.).
Mediante un anlisis de correlacin se obtienen los ndices de las muestras que pertenecen a cada interrupcin. Se eliminan las que pertenecen a ms de una serie y con el resto se realiza un anlisis estadstico para obtener los tiempos mximo , medio y mnimo. De todas las interrupciones simples detectadas hay que identificar una de ellas como el Ticker. Como ya se ha comentado anteriormente, el periodo de esta interrupcin representa la granularidad de apreciacin del tiempo del procesador. Por ello, necesitamos ejecutar el siguiente test:
Procedure Test_Ticker; T:array (1..100000) of T_fisico; D:T_Fisico; cont:integer=1; begin Establece prioridad a un nivel de tiempo real; for i in 1..1000 loop D=0.1*(1/i); for n in 1..100 loop T[cont]=Lee_tiempo_fisico; cont=cont+1 Sleep D; end loop; end loop; Guarda el array en un fichero para su analisis; end;
57
diciembre 2002
Analizamos el array de resultados y obtenemos el valor mnimo de D para el cual T[i+1]T[i] es aproximadamente igual a D. Ese valor es precisamente el periodo del Ticker , que en nuestro caso resulta ser de 10 mseg. Adems de las dos interrupciones simples aparece otra ms compleja cada 4 segundos. sta consiste en tres interrupciones simples que se repiten siempre siguiendo un patrn fijo.
Interrupciones peridicas 0,00012 0,0001

Incrementos (seg.)
0,00008 0,00006 0,00004 0,00002 0 0 2 4

Tiempo fsico (seg.)
Si representamos como antes en una grfica los incrementos de tiempo respecto a la muestra anterior frente al tiempo fsico apreciamos las dos bandas de las interrupciones simples de alta frecuencia ( en torno a 15 y 23 seg. de incremento ) con cierta dispersin y las tres interrupciones de la interference compuesta cada 4 segundos. sta ltima se modela mediante un diagrama de actividad con los siguientes valores: Activity_1: wcet = 115.6 seg. bcet = 99.7 seg. Delay_1: theDelay = 508 seg.
<<MAST_Wait_State>> Trigger
Act_1 do/ Activity_1
Act_2 do/ Delay_1
Act_4 do/ Delay_2
<<Named_State>> End
58
diciembre 2002
Activity_2: wcet = 89.7 seg. bcet = 87.2 seg. Delay_2: theDelay = 838 seg. Activity_3: wcet = 108.1 seg. bcet = 103.9 seg. En esta ocasin la obtencin automatizada de estos valores es ms complicada , aunque en un futuro se pueden evaluar mecanismos que permitan llevarla a cabo. El periodo exacto ( en valor medio ) de esta interference compuesta es de 4.06 segundos. Por ltimo, realizamos el mismo test pero en esta ocasin con la conexin a la red ethernet externa activa, simplemente para comprobar que en este caso el modelo no sera vlido. El resultado es el siguiente:
Interrupciones peridicas
0,00012
Incrementos (seg.)
0,0001 0,00008 0,00006 0,00004 0,00002 0 0 2 4

Tiempo fsico (seg.)
Ahora se aprecian nuevas interrupciones aparentemente espordicas que no pertenecen a ninguna de las tres interferences modeladas anteriormente. Son interrupciones provocadas por
59
diciembre 2002
la red, y en principio no tenemos un modelo de ella, as que mantendremos la premisa de inabilitarla para implementar aplicaciones de tiempo real sobre esta plataforma.
III.5. Cdigo MAST-File del componente NT_Processor_mdl_1 A efecto de documentar de forma completa la naturaleza y significado del modelo CBSE_Mast de la plataforma se listan las lneas de cdigo que se insertan en el modelo Mast de la aplicacin como consecuencia de la compilacin del <<Mast_Component_Inst>> theProcessor que es una instancial del <<component>> NT_Processor_mdl_1.
< < M A S T_Com ponent_Ins t> > NT_P roc es s or_M dl_1:theP roc es s or pl ac e = MA S T_P lat fo rm_ Vi ew
De acuerdo con el modelo CBSE_Mast del procesador NT que se ha descrito en la seccin III.3., los elementos que el modelo introducen en el MAST_file son: <<Mast_FP_Processor>> theProcessor.proc: Que modela el procesador que incluye el componente. A su vez este procesador incluye el modelo del timer: _ <<Mast_Ticker>> theProcessor.sysTimer: que modela tanto el overhead que requiere la atencin del reloj interno del procesador, como la granularidad temporal que introduce en la medida del tiempo dentro del procesador. <<Mast_Interference>> theProcessor.HiFrecInterference : que model el overhead que introduce en el procesador una interrupcin con periodo 16.3 ms (de origen y con finalidad desconocida). La compilacin de esta Interference requiere introcuir en el cdigo: _ <<Mast_FP_Sched_Server>> theProcessor.HiFrecInterference.System_SS: que modela el scheduling server que con una poltica de planificacin MAST_Interrup_ FP_Policy y con prioridad 32. _ <<Mast_Operation>>theProcessor.HiFrecInterference.Oper: que modela la actividad que se ejecuta en cada invocacin de la interferencia. _ <<MAST_Regular_Transaction>> theProcessor.HiFrecInterference: Que modela la ejecucin periodica de la operacin previa. Esta transaccin incluye el patrn de generacin del evento externo theProccessor.HiFrecInterference.Trigger que dispara la interferencia. <<Mast_Interference>> theProcessor.LoFrecInterference : que modela el overhead que introduce en el procesador una interrupcin con periodo 4s (de origen y con finalidad desconocida). Esta interferencia es ms compleja ya que incluye la ejecucin a nivel de sistema de tres actividades separadas entre s por tiempos de retraso constantes. La compilacin de esta Interference requiere introducir en el cdigo:
60
diciembre 2002
_ <<Mast_FP_Sched_Server>>theProcessor.LoFrecInterference.System_SS: que modela el scheduling server que con una poltica de planificacin MAST_Interrup_ FP_Policy y con prioridad 32. _ <<Mast_Simple_Operation>>theProcessor.LoFrecInterference.Activity_1 _ <<Mast_Simple_Operation>>theProcessor.LoFrecInterference.Activity_2 _ <<Mast_Simple_Operation>>theProcessor.LoFrecInterference.Activity_3, que modelan las actividades que se ejecuta en cada invocacin de la interferencia. _ <<MAST_Regular_Transaction>>theProcessor.LoFrecInterference: Que modela la ejecucin periodica de la secuencias de las operaciones previas con los correpondientes retrasos entre ellas. Esta transaccin incluye el patrn de generacin del evento externo theProccessor.LoFrecInterference.Trigger que dispara la interferencia.
--********************************************************************************* -- Segmento del cdigo MAST-File del modelo RT_Comp_Railway ------------------------------------------------------------------------------------- theprocessor (: NT_Processor_Mdl_1 <<MAST_Component_Inst>>) -------------------------------------------------- place = MAST_Platform_View (Buscamos ahi el modelo) -- NT_Processor_Mdl_1 (<< MAST_COmponent_Descr>>) -- referencias -- host = proc -- objetos: ------------------------------------------------------------------------------------ theprocessor.proc (: MAST_FP_Processor) ----------------------------------------------- MAST_FP_Processor ----------------------------------------------- Se corresponde a un Fixed_Priority_Processor con todos los atributos que se -- pasan como parametros Processing_Resource (Type => Fixed_Priority_Processor, Name => theProcessor.proc, Max_Priority => 31, Min_Priority => 16, Max_Interrupt_Priority => 32, Min_Interrupt_Priority => 32, Worst_Context_Switch => 5.3E-6, Avg_Context_Switch => 4.2E-6, Best_Context_Switch => 3.6E-6, System_Timer => (Type => Ticker, Worst_Overhead => 25.4E-6, Avg_Overhead => 9.6E-6, Best_Overhead => 1.9E-6, Period => 1.0E-2 ), Speed_Factor => 1.0 ); ------------------------------------------------------------------------------------ theprocessor.HiFrecInterference (<<MAST_Interference>>) ----------------------------------------------
61
diciembre 2002
-- MAST_Interference -------------------------------------- Declaramos una transaction que tiene: -- External Event Periodico con periodo definido por trigger.Period -- Operation Oper con los WCET,ACET Y BCET que se especifican -- Scheduling server System_SS del tipo MAST_FP_Sched_Server ------------------------------- MAST_FP_Sched_Server ------------------------------- Declaramos un scheduling server con la policy y priority indicadas Scheduling_Server (Type => Fixed_Priority, Name => theProcessor.HiFrecInterference.System_SS, Server_Sched_Parameters => (Type => Interrupt_FP_Policy, The_Priority => 32 ), Server_Processing_Resource => theProcessor.proc ); -- se declara la operacion que ejecuta la interferecia Operation (Type => Simple, Name => theProcessor.HiFrecInterference.Oper, Worst_Case_Execution_Time => 32.3E-6, Best_Case_Execution_Time => 15.3E-6 ); Transaction (Type => Regular, Name => theProccessor.HiFrecInterference, External_Events => ((Type => Periodic, Name => theProccessor.HiFrecInterference.Trigger, Period => 16.6E-3 )), Internal_Events => ((Type => Regular, Name => theProcessor.HiFrecInterference.End )), Event_Handlers => ((Type => Activity, Input_Event => theProccessor.HiFrecInterference.Trigger, Output_Event => theProcessor.HiFrecInterference.End, activity_operation => theProcessor.HiFrecInterference.Oper, activity_server => theProcessor.HiFrecInterference.System_SS )) ); -------------------------------------------------------------------- theprocessor.LoFREcInterference (<<MAST_Interference>>) ----------------------------------------------- MAST_Interference -------------------------------------- Declaramos una transaction que tiene -- External Event Periodico con periodo definido por trigger.Period -- Operation Oper con los WCET,ACET Y BCET que se especifican -- Scheduling server System_SS del tipo MAST_FP_Sched_Server ------------------------------- MAST_FP_Sched_Server ------------------------------ Declaramos un scheduling server con la policy y priority definidas Scheduling_Server (Type => Fixed_Priority, Name => theProcessor.LoFrecInterference.System_SS, Server_Sched_Parameters =>
62
diciembre 2002
(Type => Interrupt_FP_Policy, The_Priority => 32 ), Server_Processing_Resource => theProcessor.proc ); -- La transaccin de la interferencia activa un job compuesto de tres operaciones -- simples y dos delays: -- # oper.Act_1 = Activity_1 -- # oper.Act_2 = Delay_1 ; que a su vez = delay(theDelay = 508.0E-6) -- # oper.Act_3 = Activity_2 -- # oper.Act_4 = Delay_2; que a su vez = delay (838.0E-6) -- # oper.Act_5 = Activity_3 Operation (Type => Simple, Name => theProcessor.LoFrecInterference.Activity_1, Worst_Case_Execution_Time => 111.5E-6, Best_Case_Execution_Time => 99.7E-6 ); Operation (Type => Simple, Name => theProcessor.LoFrecInterference.Activity_2, Worst_Case_Execution_Time => 89.7E-6, Best_Case_Execution_Time => 87.2E-6 ); Operation (Type => Simple, Name => theProcessor.LoFrecInterference.Activity_3, Worst_Case_Execution_Time => 108.1E-6, Best_Case_Execution_Time => 103.9E-6 ); Transaction (Type => Regular, Name => theProccessor.LoFrecInterference, External_Events => ((Type => Periodic, Name => theProccessor.LoFrecInterference.Trigger, Period => 4.06E0)), Internal_Events => ((Type => Regular, Name => LFI1 ), (Type => Regular, Name => LFI2 ), (Type => Regular, Name => LFI3 ), (Type => Regular, Name => LFI4 ), (Type => Regular, Name => theProcessor.LoFrecInterference.End )), Event_Handlers => ((Type => Activity, Input_Event => theProccessor.LoFrecInterference.Trigger, Output_Event => LFI1, Activity_operation => theProcessor.LoFrecInterference.Activity_1, Activity_server => theProcessor.LoFrecInterference.System_SS ), (Type => Delay, Input_Event => LFI1, Output_Event => LFI2,
63
diciembre 2002
Delay_Max_Interval Delay_Min_Interval ), (Type Input_Event Output_Event activity_operation activity_server ), (Type Input_Event Output_Event Delay_Max_Interval Delay_Min_Interval ), (Type Input_Event Output_Event Activity_operation Activity_server ))
=> 508.0E-6, => 508.0E-6 => => => => => => => => => => => => => => => Activity, LFI2, LFI3, theProcessor.LoFrecInterference.Activity_2, theProcessor.LoFrecInterference.System_SS Delay, LFI3, LFI4, 838.0E-6, 838.0E-6 Activity, LFI4, theProcessor.LoFrecInterference.End, theProcessor.LoFrecInterference.Activity_3, theProcessor.LoFrecInterference.System_SS
); --*********************************************************************************
III.6. Modelo de tiempo real del componente C_IG_DT3153 A modo de ejemplo, en este apartado se describir el modelo de tiempo real de uno de los componentes software implementados, concretamente describe el componente C_IG_DT3153, que posteriormente utilizaremos en la aplicacin de ejemplo para detectar la posicin de los trenes en la maqueta.
64
diciembre 2002
.
<< MAST_Component_Descr>> RTM_C_Image_Grabber << par>> << par>> << par>> << par>> << par>> << par>> << obj>> << obj>> << obj>> << obj>> PixelInLine : MAST_Factor = 64 ImageSize : MAST_Factor AvgPixelOverhead = 0.02E-6 SemiFrame_Duration = MAST_Time=18.0E-3 Driver_priority = host.Max_Interrupt_Priority Driver_Host = host AttendFrameTrans_SS = MAST_FP_Sched_Server(policy=MAST_Interrupt_FP_Policy(priority=host.Max_Interrupt_Priority)) Bus_Transfer_SS = MAST_FP_Sched_Server(policy=MAST_FP_Preemptible_Policy,host= DMA_Bus) Image_Processor : MAST_FP_Processor Image_Process = MAST_FP_Sched_Server(policy=MAST_Interrupt_FP_Policy(priority= host.Max_Interrupt_Priority),host=Image_Processor) W aitForFirstFrame(wcet = 1.2E-5, bcet = 1.2E-5) TransferSemiFrame(wcet = 18.0E-3, bcet = 18.0E-3) PreW aitForSecondFrame(wcet = 0.72E-3, bcet = 0.53E-3) PostW aitForSecondFrame(wcet = 1.62E-3, bcet = 1.09E-3) PreW aitForEnd(wcet = 0.66E-3, bcet = 0.47E-3) PostW aitForEnd(wcet = 19.93E-3, bcet = 14.41E-3) ProcessFrame(wcet = SemiFrame_Duration, bcet = SemiFrame_Duration) << obj>> D MA_Bus
<< simple>> << simple>> << simple>> << simple>> << simple>> << simple>> << simple>>
<< MAST_Component_Descr>> MAST_FP_Network:D MA_Bus << par>> << par>> << par>> << par>> << par>> Transmission = SIMPLEX - Max_Blocking = > SemiFrameDuration*PixelInLine/ImageSize Max_Packet_Transmission_Time = SemiFrameDuration*PixelInLine/ImageSize Packet_Best_Overhead = SemiFrameDuration*PixelInLine/ImageSize Max_Blocking = SemiFrameDuration*PixelInLine/ImageSize << obj>> th eDriver 1 << MAST_Component_Descr>> MA ST_FP_Packet_ Dri ver:DMA_Driver + Packet_ Re ceive(wcet = A vgPi xelOverhead *Pix elInLi ne, bcet = AvgPix elOve rhead*P ixelInLi ne) <<i mple ment > > << obj>> Pac ket_S erver 1 << MAST_ Co mpone nt_Descr>> MAST_FP_Scheduling _Se rve r:Pac ket_S erver << obj>> policy = MAST_FP_NonPreemptible(priority=Driver_Priority)) << par>> host = Driver_Host 1 I_Image_Grabber << MA ST_Interface_Descr>> RTM_I_Image_Grabber << job>> + Read(wbt : MAST_Time = 36.4E-3, wft : MAST_Factor = 0.15E-6, bbt : MAST_Time = 34.3E-3, bft : MAST_Factor = 0.14E-6, ImgSize : MAST_Factor) << job>> + Acquire()
Como se ha descrito en el captulo II este componente ofrece una interfaz que posibilita capturar una imagen de una cmara de vdeo, transferirla al espacio de memoria de la aplicacin o transferirla a una ventana de vdeo en vivo de windows. En este apartado solo se describen los modelos de tiempo real de las operaciones Read y Adquire, que son la que se utilizan en el demostrador. El componente C_IG_DT3153, modela el componente software diseado para controlar la tarjeta de digitalizacin de imgenes ( grabber ) DT3153 de Data Translation, construida a partir del propio driver que suministra el fabricante y que se ha encapsulado como una DDL a fin de poder ser utilizada desde el cdigo Ada que implementa el componente. Es un software de modelo de tiempo real complejo, ya que incorpora, una tarjeta hardware que realiza de manera autnoma la digitalizacin de la imagen, y de un canal DMA que transfiere la imagen desde la tarjeta a la memoria del computador en concurrencia con la ejecucin de la aplicacin. El elemento principal del modelo es el MAST_Component_Descr [23]. Se trata de un ente de modelado que constituye un descriptor genrico y parametrizable que describe en este caso el recurso software del sistema. En el se declaran los recursos (componentes) internos o externos
65
diciembre 2002
que requiere para su operacin, los prametros que deben establecerse en su intanciacin y los modelos de los modos de uso que se le pueden requerir: Parmetros: <<par>> PixelInLine: Mast_Factor= 64: Representa el nmero de pxels que son transferidos en una transaccin por el DMA. Es un parmetro de modelado que no corresponde al sistema fsico. Se ha introducido para incrementar la granularidad de la transferencia de informacin por el DMA. <<par>> AvgPixelOverhead: MAST_Time=0.02E-6: Representa el overhead medio que supone para el procesador la transferencia de un pxel a travs del DMA. <<par>> SemiFrame_Duration: Time=18.0E-3: Representa el tiempo que tarda en transmitirse un semiframe en una seal de vdeo. <<par>> Driver_Priority: MAST_Priority= Host.Max_Interrupt_Priority: Prioridad en la que se ejecuta el driver control de la tarjeta de captura de imgenes.Se ha establecido como valor por defecto la maxima prioridad de interrupcin del computador que ejecuta el driver. <<par>> DriverHost: MAST_FP_Processor= Host: Establece el computador en que se ejecuta el driver. Por defecto se establece el mismo procesador en que se ha instalado el componente. Referencias a componentes externos: <<par>>host: Referencia al UML NT_Processor_mdl_1: MAST_Processing_Resource que modela el Processing Resource en el que se ejecuta el componente. Debe ser establecido en la instanciacin del componente. Declaracin de los componentes internos agregados: <<obj>> AttendFrameTrans_SS:MAST_FP_Sched_Server: Tarea del procesador que ejecuta el componente en la que se ejecuta la actividad de background de gestin del proceso de transferencia por DMA de la imgenes desde la tarjeta de digitalizacin. Esta tarea se planifica con poltica MAST_Interrupt_Priority_Policy y con la prioridad mxima de interrupcin. <<obj>> Bus_Transfer_SS: MAST_FP_Sched_Server: Scheduling server del network auxiliar DMA_Bus para modelar el overhead que la transferencia de la imagen por DMA introduce sobre el procesador que executa el componente. Este scheduling server se planifica con poltica MAST_FP_Preemptible_Policy y con la prioridad por defecto. <<obj>> Image_Processor: MAST_FT_Processor: Procesador que modela las actividades de captura y digitalizacin de las imgenes en el hardware de la tarjeta de digitalizacin. Su unica funcin es modelar la temporizacin del proceso de camptura de imgenes de la seal de vdeo. <<obj>> Image_Process: MAST_FT_Sched_Server: Scheduling server en el que se ejecutan las actividades del Image_Processor. <<obj>>DMA_Bus: Network de tipo MAST_FP_Packet_Driver: MAST_FP_Network, que opera en modo Simplex, y que se utiliza como forma de modelar el overhead que produce el DMA sobre el procesador que ejecuta el
66
diciembre 2002
componente. Cuando se transmite una imagen, transfiere un nmero de paquetes igual al nmero de lneas (Pixel en imagen/Pixel en linea) y la duraccin de la transmisin de cada paquete es tal que la transmisin de cada Semiframe dure el tiempo estimado. Agregado a este componente se definen: _ <<obj>>theDriver: MAST_FP_Packet_Driver: Driver que introduce por cada paquete transmitido el correspondiente overhead en el procesador que ejecuta el componente. _ <<obj>>Packet_Server:MAST_FP_Sched_Server: Scheduling server del procesador en que se ejecuta el componente en el que ejecuta la actividad que modela el overhead que introduce la transferencia por el DMA. Modelo de tiempos reales de funciones que ofrece su interfaz: <<Simple>>WaitForFirstFrame <<Simple>>TransferSemiFrame <<Simple>>PreWaitForSecondFrame <<Simple>>PostWaitForSecondFrame <<Simple>>PreWaitForEnd <<Simple>>PostWaitForEnd <<Simple>>ProcessFrame
Conjunto de operaciones auxiliares utilizadas para el modelo de la operacin externa Acquire, que se describe ms adelante. <<MAST_Interface_Descr>>I_Image_Grabber: Interfaz pblica del componente que contiene las operaciones pblicas que ofrece el componente. <<job>> Read: Modela el procedimiento de transferencia a la memoria principal de la imagen capturada anteriormente con los procedimientos Acquire o Snap. Se trata de una operacin sencilla que lo nico que hace es copiar los pxels de la imagen capturada por la tarjeta en una estructura de datos accesible por el usuario. Es una operacin totalmente software, de modo que lo nico que necesitamos conocer son los tiempos de mejor y peor caso. En este caso estos tiempos dependen del tamao de la imagen. Se ha hecho un estudio de la variabilidad de los tiempos en funcin del nmero de pxels de la imagen. Se ha comprobado que el tiempo depende del nmero de pixels de forma lineal siguiendo el siguiente patrn: Tiempo = OFFSET + ( numero_pixels * CTE_LIN ) Realizando varias medidas para imgenes de distintos tamaos se han obtenido los valores de OFFSET y CTE_LIN ( para el mejor y el peor tiempo). En el modelo de tiempo real describimos este comportamiento del siguiente modo: En el MAST_Interface_Descr declaramos la operacin como:
<<job>> Read(wbt : MAST_Time = 36.4E-3, wft : MAST_FActor = 0.15E-6, bbt :
67
diciembre 2002
MAST_Time = 34.3E-3, bft : MAST_Factor = 0.14E-6, ImgSize : MAST_Factor)
Sus parmetros son: wbt : OFFSET para el clculo del wcet. wft : CTE_LIN para el clculo del wcet. bbt : OFFSET para el clculo del bcet. bft : CTE_LIN para el clculo del bcet. ImgSize : nmero de pxels de la imagen.
Y por lo tanto , el clculo de los tiempos wcet y bcet se describe mediante el diagrama de actividad asociado a la operacin:
Activity do/ MAST_Simple_Operation(wcet=wbt+wft*ImgSize, bcet=bbt + bft*ImgSize)
Los valores de los parmetros de la operacin se han obtenido realizando medidas sobre la plataforma que va a soportar la aplicacin. Es posible que estos valores varien si la plataforma fuese otra distinta. Por ello, parece aconsejable que en un futuro se ofrezcan procedimientos para recalcular automticamente estos valores al cambiar de plataforma. <<job>> Acquire: Se trata de una operacin compleja que cuando se invoca captura una imagen y la almacena en la memoria fsica reservada por la tarjeta. Esta memoria no es accesible por el usuario, por eso disponemos de la operacin Read anteriormente comentada. La tarjeta que utilizamos para la implementacin del componente1 realiza esta funcin utilizando DMA2 , lo que provoca unas interrupciones y bajadas de rendimiento del procesador del PC que han de ser descritas en el modelo. Para comprender su funcionamiento realizamos el siguiente test:
Procedure Test_Acquire; T:array (1..100000) of T_fisico; m:integer=1; Tarea_1 is Establece prioridad = 25;
1. DT3153 de Data Translation. 2. Acceso Directo a Memoria.
68
diciembre 2002
accept t1; entry t2; Sleep 0.01; -- para que comienze el acquire de Tarea_2 for i in 1..100000 loop T[i]=Lee_tiempo_fisico; end loop; entry t2; end Tarea_1; Tarea_2 is Establece prioridad = 24; accept t2; Acquire; accept t2; Guarda el array en un fichero para su analisis; end Tarea_2; begin Establece prioridad a un nivel de tiempo real; entry t1; end;
Si la operacin Acquire fuese convencional en el array de resultados tendramos muestras separadas TClock entre s ( salvo las interferences peridicas detectadas en la plataforma ) , ya que la Tarea_1 es ms prioritaria que Tarea_2. Pero en la prctica no es as. Si representamos en una grfica los incrementos de tiempo respecto a la muestra anterior frente al tiempo fsico tenemos :
Acquire
0,00016 0,00014 0,00012 0,0001 0,00008 0,00006 0,00004 0,00002 0 0 0,02 0,04 0,06 0,08 Tiempo fsico (seg.) Incrementos (seg.)
69
diciembre 2002
Si representamos de forma esquemtica este resultado podemos identificar varias zonas: ,QFUHPHQWRV
$&48,5(
T_ IN T 1 T_ IN T 2
In ic io d e la o pe ra c i n T1 T2 T3 T4 T5 T6 T7
F ina l d e la o pe ra c i n
7LHPSR#ItVLFR T1 : tiempo transcurrido desde el comienzo de la operacin hasta que comienza a transmitirse la imagen. Este tiempo depende de la referencia de sincronismo de la seal analgica de vdeo. En este intervalo las tareas de orden superior se ejecutan normalmente. T2 : transmisin de las lneas pares de la imagen. Este tiempo depende del estndar de la seal analgica de vdeo. Durante la transmisin se produce una bajada de rendimiento en el procesador principal debido a que se utiliza DMA , y cuando el procesador de la tarjeta de adquisicin utiliza el bus del sistema , el procesador principal tiene que esperar ( si desea utilizarlo l ). T3 : tiempo transcurrido desde el final de la transmisin de las lneas pares hasta la interrupcin 1. En este intervalo las tareas de orden superior se ejecutan normalmente. T_INT1 : interrupcin provocada por el procesador de la tarjeta para indicar que se ha completado la transmisin de las lneas pares. T4 : tiempo transcurrido desde la interrupcin 1 hasta el comienzo de la transmisin de las lneas impares. En este intervalo las tareas de orden superior se ejecutan normalmente. T5 : como T2 pero para las lneas impares. T6 : como T3 pero para las lneas impares. T_INT2 : interrupcin provocada por el procesador de la tarjeta para indicar que se ha completado la transmisin de las lneas impares. T7 : tiempo transcurrido desde la interrupcin 2 hasta que la operacin devuelve el control al flujo de la tarea desde la que se invoc. En este intervalo las tareas de orden superior se ejecutan normalmente.
70
diciembre 2002
Describimos este comportamiento con el siguiente diagrama de actividad1:
AttendFrameTrans_SS
Bus_Transfer_SS
Image_Process
Act_1 do/ WaitForFirstFrame Act_2 A ct_3 do / MAS T_ NOP Act_4 Act_5 do/ ProcessFrame Act_6 do/ PostWaitForSecondFrame Act_7 do/ Transf erSemiFrame Act_8 do/ MAST_NOP Act_9 d o/ P reWait ForEnd Act_10 do/ ProcessFrame Act_11 do/ PostWaitForEnd do/ PreWaitForSecondFrame do/ Transf erSemiFrame
Donde AttendFrameTrans_SS representa al procesador principal , Bus_Transfer_SS representa al bus del sistema e Image_Process representa al procesador de la tarjeta de adquisicin de la imagen. Se han obtenido los parmetros de las distintas operaciones que resultan ser: WaitForFirstFrame (wcet = 26.68E-3, bcet = 15.55E-3) [ T1 ] TransferSemiFrame (wcet = 18E-3, bcet = 18E-3) [ T2 , T5 ] PreWaitForSecondFrame (wcet = 0.72E-3, bcet = 0.53E-3) [ T3 ] PostWaitForSecondFrame (wcet = 1.62E-3, bcet = 1.09E-3) [ T4 ] PreWaitForEnd (wcet = 0.66E-3, bcet = 0.47E-3) [ T6 ] PostWaitForEnd (wcet = 19.93E-3, bcet = 14.41E-3) [ T7 ] ProcessFrame (wcet = 138.2E-6, bcet = 135.7E-6) [ T_INT1 , T_INT2 ]
Tenemos que modelar de alguna forma la bajada de rendimiento que se produce durante la ejecucin de TransferSemiFrame. Debido a la sensibilidad de la medida del tiempo en el PC ( 0.83 seg. ) no llegamos a apreciar con precisin lo que est ocurriendo pero si podemos calcular el overhead total que se produce en el intervalo. Realizando medidas con imgenes de distintos tamaos descubrimos que ese tiempo es proporcional al nmero de pxels y calculamos el valor del overhead medio por pxel , que resulta ser: AvgPixelOverhead = 20 nseg.
1. Las operaciones MAST_NOP no existen. se han incluido para poder describir el modelo en la herramienta de anlisis.
71
diciembre 2002
A continuacin debemos hacer una suposicin sobre el tamao de los paquetes transmitidos sobre el bus del sistema durante la ejecucin de TransferSemiFrame. Podramos suponer que un paquete equivale a un pxel , pero en ese caso el nmero de iteraciones que debera efectuar la herramienta de anlisis de planificabilidad sera demasiado elevado. Para evitar este problema , vamos a suponer que en cada paquete se tranmiten PixelInLine pxels. Este valor es completamente arbitrario , ya que lo que nosotros hemos medido es el overhead total. La nica restriccin que tenemos es que el valor ha de ser mltiplo de todos los tamaos de imagen posibles. Por ello , en nuestro caso fijamos un valor de: PixelInLine = 64
III.7. Cdigo Mast-File del modelo del componente A efecto de documentar de forma completa la naturaleza y significado del modelo CBSE_Mast del componente C_IG_DT3153 se listan las lneas de cdigo que se insertan en el modelo Mast de la aplicacin como consecuencia de la compilacin del <<Mast_Component_Inst>> theGraber que es una instancial del <<component>> C_IG_DT3153.
< < M A S T_ C o m p o n e n t In s ta n c e > > R TM _ C _ Im a g e _ G ra b b e r:Th e _ G ra b b e r p la c e = M A S T_ F ile c ( p a th = :\ M a s t \C o m p on e n t \S a u c e \C ap . m d l) I m a g e S iz e = 2 7 6 4 8 .0 < < i m p le m e nt > > I _ Im ag e _ G r a b b er
< < M A S T_ C o m p o n e n t _ In s t > > N T_ P ro c e s s o r_ M d l_ 1 : th e P ro c e s s o r p la c e = M A S T_P la tf o rm _V ie w
De acuerdo con el modelo CBSE_Mast del componente C_IG_DT3153 que se ha descrito en la seccin III.6, los elementos que el modelo introducen en el MAST_file son:
--********************************************************************************** -- Segmento del cdigo MAST-File del modelo RT_Comp_Railway -------------------------------------------------------------------------------------- the_Grabber (: RMT_C_Image_Grabber) ------------------------------------------------------------------------------------- place :C:/MAST/Component/Sauce/cap.mdl -- Imagesize = 27648 -- host = theprocessor (para nosotros theprocessor.proc) -- Buscamos ah el modelo del componente MAST_C_I_Grabber -- parametros -- PixelInLine = 64 -- Imagesize = 27648 -- AvgPixelOverhead = 0.02E-6 -- SemiFrame_Duration = 18E-3 -- Driver_Priority = host.Max_interrupt_Priority = 32 -- Driver_host = host = theprocessor -- RTM_C_Image_Grabber.AttendFrameTRans_SS (:MAST_FP_Sched_Server) Scheduling_Server (Type => Fixed_Priority, Name => the_Grabber.AttendFrameTrans_SS, Server_Sched_Parameters =>
72
diciembre 2002
(Type => Interrupt_FP_Policy, The_Priority => 32 ), Server_Processing_Resource => theProcessor.proc ); -- RTM_C_Image_Grabber.DMA_Bus (MAST_FP_Network) ----------------------------- MAST_FP_Network ----------------------------- Declaramos una network con los atributos que aparecen en la descripcin Processing_Resource (Type => Fixed_Priority_Network, Name => the_Grabber.DMA_Bus, Transmission => Simplex, Max_Blocking => 41.6E-6, Max_Packet_Transmission_Time => 41.6E-6, Min_Packet_Transmission_Time => 41.6E-6, List_of_Drivers => ((Type => Packet_Driver, Packet_Server => (Type => Fixed_Priority, Name => the_Grabber.DMA_Bus.theDriver.Packet_Server, Server_Sched_Parameters => (Type => Interrupt_FP_Policy, The_Priority => 32 ), Server_Processing_Resource => theProcessor.proc ), Packet_Send_Operation => (Type => Simple, Name => the_Grabber.DMA_Bus.theDriver.Packet_Send, Worst_Case_Execution_Time=> 1.28E-6, Best_Case_Execution_Time => 1.28E-6), Packet_Receive_Operation => (Type => Simple, Name => the_Grabber.DMA_Bus.theDriver.Packet_Receive, Worst_Case_Execution_Time=> 1.28E-6, Best_Case_Execution_Time => 1.28E-6 ) ) )); ------------------------------------------------------------------------------------- RMT_C_Image_GRabber.Bus_TRansfer_SS ( : MAST_FP_Sched_Server) --------------------------------------------Scheduling_Server (Type => Fixed_Priority, Name => the_Grabber.Bus_Transfer_SS, Server_Sched_Parameters => (Type => Fixed_Priority_Policy ), Server_Processing_Resource => the_Grabber.DMA_Bus ); ------------------------------------------------------------------------------------- RMT_C_Image_GRabbe.Image_Processor (type :Mast_Device) ---------------------------------------------- MAST_Device ----------------------- Corresponde a una FP_Processor sin atributos Processing_Resource (Type Name );
=> Fixed_Priority_Processor, => the_Grabber.Image_Processor
73
diciembre 2002
------------------------------------------------------------------------------------- MainProcessor.Image_Process (type : Mast_System_SS) -- Corresponde a un SS Non preemtible con prioridad por defecto ---------------------------------------------Scheduling_Server (Type => Fixed_Priority, Name => the_Grabber.Image_Process, Server_Sched_Parameters => (Type => Interrupt_FP_Policy, The_Priority => 32 ), Server_Processing_Resource=> the_Grabber.Image_Processor ); -- Declaramos ahora todas las operaciones simples que aparecen Operation (Type => Simple, Name => The_Grabber.WaitForFirstFrame, Worst_Case_Execution_Time => 1.2E-5, Best_Case_Execution_Time => 1.2E-5 ); Operation (Type => Simple, Name => The_Grabber.TRansferSemiFrame, Worst_Case_Execution_Time => 18.0E-3, Best_Case_Execution_Time => 18.0E-3 ); Operation (Type => Simple, Name => The_Grabber.PreWaitForSecondFrame, Worst_Case_Execution_Time => 0.72E-3, Best_Case_Execution_Time => 0.53E-3 ); Operation (Type => Simple, Name => The_Grabber.PostWaitForSEcondFrame, Worst_Case_Execution_Time => 1.62E-3, Best_Case_Execution_Time => 1.09E-3 ); Operation (Type => Simple, Name => The_Grabber.PreWaitForEnd, Worst_Case_Execution_Time => 0.66E-3, Best_Case_Execution_Time => 0.47E-3 ); Operation (Type => Simple, Name => The_Grabber.PostWaitForEnd, Worst_Case_Execution_Time => 19.93E-3, Best_Case_Execution_Time => 14.41E-3 ); Operation (Type => Simple, Name => The_Grabber.ProcessFrame, Worst_Case_Execution_Time => 18.0E-3, Best_Case_Execution_Time => 18.0E-3 ); -- Job parametrizables ----------------------------------------------Operation( -Type => Simple, -Name => The_Grabber.I_Image_Grabber.Read, -Worst_Case_Execution_Time => 36.4E-3 + 0.15E-6*ImgSize,
74
diciembre 2002
-Best_Case_Execution_Time => 36.4E-3 + 0.14E-6*ImgSize); ---------------------------------------------- Anadida desde al transaccion Operation (Type => Simple, Name => The_Grabber.I_Image_Grabber.Read_1, Worst_Case_Execution_Time => 40.55E-3, Best_Case_Execution_Time => 40.27E-3); --**********************************************************************************
75
demostrador de un sistema de tiempo real basado en componentes
diciembre 2002
IV. DEMOSTRADOR DE UN SISTEMA DE TIEMPO REAL BASADO EN COMPONENTES

IV.1. Control por computador de una maqueta de trenes utilizando visin artificial Se ha desarrollado como ejemplo una aplicacin sencilla que hace uso de algunas de las interfaces que son implementadas por los tres componentes desarrollados y que consiste en el control de una maqueta de trenes de escala N, en la que la posicin de las locomotoras se detecta mediante visin artificial. Esta aplicacin desarrollada tiene la finalidad de validar los componentes, tanto en lo relativo a la validez y completitud de su especificacin, a la capacidad de interconectividad y a la predecibilidad que aportan sus modelos de tiempo real, y sobre todo permite obtener experiencia sobre el ciclo de desarrollo de aplicaciones basadas en componentes. Tambin comprobamos la validez del anlisis de planificabilidad de peor caso utilizando la herramienta MAST propia para tal fin. Se dispone de una maqueta de trenes de la marca Roco de escala N instalada sobre una base rgida debidamente cableada para facilitar su control de modo electrnico. El aspecto que presenta ( vista desde arriba ) es el siguiente: &6
&4
&
&5
'
&7
Consta de tres tipos de elementos: LOCOMOTORAS: ROJA y AZUL .- Tambin denominadas trenes. Se trata de las mquinas que se mueven sobre las vas. En su parte superior llevan instalada una tarjeta de un determinado color que permite identificar su posicin mediante visin artificial. En nuestro caso tenemos un tren azul y un tren rojo. Son locomotoras de escala N de la marca Ibertren. TRAMOS: A , B , C , D , E y F .- Segmentos de va comprendidos entre dos cruces. Cuando una locomotora se encuentra situada sobre un tramo , su motor se alimenta
76
diciembre 2002
electricamente a travs del propio tramo de va. Para ello se ha cableado la maqueta como se muestra en la figura de modo que cada tramo se puede alimentar con una tensin diferente. La velocidad del tren vara de forma montona con la tensin de alimentacin de la va. As mismo, si se invierte la polaridad de la tensin, se invierte el sentido del desplazamiento del tren sobre la va. Las locomotoras Ibertren utilizadas admiten un rango de tensin de alimentacin desde 0 hasta 15 voltios, pero en la aplicacin del demostrador las locomotoras solo se mueven en un sentido dentro de cada tramo y solo utilizamos tres valores posibles de alimentacin: 9L 9M
7UDPR#L
7UDPR#M
STOPPED: se aplican 0 voltios al tramo. La locomotora situada en el tramo permanece parada. LOW_SPEED: se aplican 7 voltios al tramo. La locomotora situada en el tramo se desplaza a velocidad lenta en el sentido de las agujas del reloj. HIGH_SPEED: se aplican 13.5 voltios al tramo. La locomotora situada en el tramo se desplaza a velocidad rpida en el sentido de las agujas del reloj. Para que sea posible el control independiente de las dos locomotoras, se establece la restriccin de que nunca puedan estar ambas en un mismo tramo. CRUCES: C1 , C2 , C3 y C4 .- Cuatro cruces idnticos , cada uno de ellos con dos posibles estados denominados RECTO y DESVO. En funcin del estado y del tramo del que proceda la locomotora , sta saldr hacia un tramo determinado tal y como se indica en la figura:
'(692
5(&72 Como en la aplicacin las locomotoras siempre se van a desplazar en el sentido de las agujas del reloj slo necesitamos controlar los cruces C1 y C2 , mientras que el estado de C3 y C4 va a ser indiferente. El control se realiza mediante un electroimn (integrado en la propia pieza que conforma el cruce) con tres conexiones electrnicas: una de ellas a tierra (0 voltios),
77
diciembre 2002
otra para pasar a RECTO y otra ms para pasar al estado DESVO. La manera de pasar a un determinado estado es aplicar en la conexin correspondiente un pulso de 15 voltios de amplitud de una determinada duracin, en nuestro caso 300 mseg (esto no implica que el cambio se haga efectivo al comienzo o al final del pulso , ya que el electroimn es un dispositivo electromecnico). Lo que no disponemos es de informacin electrnica de retorno que nos indique el estado actual de un cruce, de modo que esta informacin deber de ser mantenida por la aplicacin software y ser gestionada adecuadamente como variables de estado. Por la conectividad que se ha establecido en la maqueta, los cruces C1 y C3 son parte 1 del tramo B , mientras que C2 y C4 son parte del tramo D. Para poder controlar de forma segura la operacin de los trenes en la maqueta, se necesita conocer la posicin de las locomotoras dentro de la maqueta. La posicin de las locomotoras se detecta mediante visin artificial, utilizando para ello una cmara situada sobre la maqueta y una tarjeta de captura y digitalizacin de imagenes del tipo DT3153 de Data Translation.
Como el fondo de la base rgida de la maqueta es bsicamente verde , un tren rojo y el otro azul podemos detectar sus posiciones dentro de la imagen mediante anlisis del color y determinar si una locomotora est situada en una zona definida previamente. Ya que nos interesa que la operacin de localizacin sea lo ms rpida posible, debemos trabajar con imgenes con la menor resolucin, pero que sean compatibles con la precisin de localizacin que se necesita. En nuestro caso se utilizan imgenes de 192 por 144 pxels2 ( 27648 pxels en total ). Se han definido varias zonas sobre las vas en las que va a ser de inters detectar la presencia de un tren en ella. Estas zonas se han determinado mediante edicin manual de una
1. En cuanto a la alimentacin de las locomotoras (desplazamiento). 2. Tamao R_4 del tipo Ratio en la interface Image_Grabber.
78
diciembre 2002
imagen de referencia utilizando una aplicacin independiente diseada para tal fin. Tambin se ha implementado otra aplicacin que permite recolocar la posicin de la maqueta respecto a la cmara para conseguir que la referencia de las zonas sea vlida. Para esta ltima se ha utilizado una tcnica basada en imgenes superpuestas sobre vdeo en vivo ( overlapping ). Hay dos tipos de zonas: Zonas de deteccin: se trata de 6 zonas, una por cada tramo, que implican la existencia del tren en el tramo correspondiente. Zonas de peligro: se trata de 6 zonas, una por cada tramo, que implican la existencia del tren en una posicin cercana a un cruce. Cuando se detecte un tren en esta zona se deben tomar una serie de decisiones (parar si el siguiente tramo est ocupado, o si no es as colocar el cruce en el estado adecuado). Estas zonas estan comprendidas dentro de la zona de deteccin respectiva, y en el caso de los tramos B y D coinciden completamente ( debido a su pequeo tamao ).
&
'
=RQD#GH#GHWHFFLyQ =RQD#GH#SHOLJUR
El control de la maqueta ( estado de los cruces y alimentacin de los tramos ) se realiza utilizando la tarjeta de I/O PCI9111, en concreto 16 de sus salidas digitales. Estas seales son de baja potencia1 , mientras que los elementos de la maqueta requieren seales de potencia. Por ello ha sido necesario disear e implementar una tarjeta intermedia de rels y cablearla de
1. TTL.
79
diciembre 2002
manera adecuada entre la tarjeta de adquisicin I/O y la maqueta para poder efectuar el control. El diseo y cableado de esta tarjeta intermedia de rels se describe detalladamente en el anexo B.
IV.2. Funcionalidad de la aplicacin En el demostrador, cada una de las locomotoras debe recorrer una ruta cerrada de forma cclica durante un determinado nmero de vueltas. En nuestro caso se le asigna al tren azul el recorrido externo (tramos A - B - C - D) y al tren rojo el recorrido interno (tramos E - B - F D). El tren azul inicialmente est situado en una posicin central del tramo A y el rojo en una posicin central del tramo E de modo que al comenzar la ejecucin ambos son detectados en la zona de deteccin del tramo correpondiente sin ningn problema. La deteccin se realiza de forma peridica durante toda la ejecucin del programa. Cuando se detecta que un tren llega a alguna zona de peligro lo primero que se hace es establecer su velocidad a LOW_SPEED. A continuacin se comprueba si el siguiente tramo del recorrido es accesible (no est ocupado) y en ese caso se pone el cruce en la posicin adecuada y se pasa la velocidad a HIGH_SPEED. Si el siguiente tramo no es accesible se detiene el tren (STOPPED) y se espera hasta que quede libre; en ese momento se pone el cruce en la posicin adecuada y se pasa la velocidad a HIGH_SPEED. Un tramo se considera que queda libre cuando el tren que lo ocupaba llega a su siguiente tramo.
IV.3. Arquitectura software del demostrador El programa Ada 95 que constituye la aplicacin se ha construido a partir de dos clases principales:
Tr ain Railway
Class Train: Representa el mdulo software que controla la circulacin de un tren de acuerdo con una ruta que se le ha asignado. Existe una instancia de esta clase por cada tren que circula en la aplicacin. Class Railway: Modela la librera de procedimientos de control de los elementos de la red ferroviaria e inspeccin de su estado. En la figura de la siguiente pgina se muestra la descripcin UML de la clase Train. En ella se muestra, el conjunto de atributos que representan el estado de cada instancia de la clase, su interfaz constituida por el conjunto de procedimientos y funciones con las que el procedimiento principal que constituye la aplicacin gestiona la operacin de la instancia y el conjunto de clases auxiliares que definen los diferentes tipos de variables utilizados en la clase Train.
80
diciembre 2002
La semntica de las diferentes clases est bastante autoexplicada, y en cualquier caso su explicacin detallada queda fuera del objeto de esta memoria.
<<type >> Stage_Id + s : Positive
Train + + + + id : Train_Id the Ro ute : Route veloc : Veloci ty position : Stage_Id in it ial _pos : Stag e_Id rounds : Natural theDriver : TrainTask_Link Create(Id : Train_Id , ro : Route, rounds : Positive) S tart () Set_Velocity(v : Velocity) Sector_ In() <<t ask type>> Trai nTask <<entry>> + R un(th eTrai n : Train_Li nk)
<<subtype>> Train_Id t i : Train_Id range RE D_TR AIN. .BLUE_TRAIN
<<enu merate d>> Velocity <<enum>> + STOPPED <<enum>> + LOW_ SP EED <<en um>> + HIGH_SP EED
Rou te - id : Rout e_Id - si : Posi tive + + + + + + + Create (Id : Route_Id) Size() : Pos itive Curren t_sector(curren t : Stage_Id) : Sect or Next_sector(current : Stage_Id) : Sector Next _crossway(current : S ta ge_Id) : Crossway Next_crossway_State(current : Stage_Id) : Cross wa y_State Firs t_Stage(s : Sector) : Stage_Id n <<enu merate d>> Sect or <<enum>> <<enum>> <<enum>> sector_Lst <<enum>> <<enum>> <<enum>> + + + + + + A_SECTOR B_SECTOR C_SECTOR D_SECTOR E_SECTOR F_SECTOR
<<exception>> Route_Error
<<enumerated >> Route_Id <<enum>> <<enum>> <<enum>> <<enum>> <<enum>> + + + + + LAR GE EXTERNAL INTERNAL RIGHT LEFT
<<enumerated>> Cross wa y <<enum >> <<enum >> <<enum>> <<enum>> + + + + X_CR OSSW AY Xo_CR OSSW AY Y_ CR OSSW AY Yo_CROSSW AY <<enumerated>> Crossway_State <<en um>> + STRAIGHT <<enum>> + BENT <<enum>> + ANYW AY
As mismo, en la figura de la siguiente pgina se muestra el modelo de la clase Railway, con sus atributos, su interfaz de funciones y procedimientos, y el conjunto de clases asociadas para definir los tipos utilizados en ellos. En el diagrama de clases de Railway se indica que la clase Railway hace uso de las interfaces, I_Configuration_Adq, I_Digital_Adq, I_Grabber, I_Image_Mannaging, I_Image_Statistic e I_Image_Logic_Processing. Dentro de la herramienta UML CASE, se han establecido junto a estos diagramas de clases, la documentacin que explica la semntica de cada componente, los diagramas de actividad, secuencia y colaboracin que ilustran su funcionalidad, y las posibilidades de interaccin con otros componentes que ofrecen, y las directivas de generacin de cdigo que permiten la generacin directa de la especificacin del paquete Ada95, y el esqueleto del cuerpo de del paquete Ada 95.
81
diciembre 2002
En este caso, a travs del diagrama de componentes se ha elegido que el cdigo de ambas clases se incluya en un nico mdulo de cdigo.
<<enumerated>> Sector <<enum>> <<enum>> <<enum>> <<enum>> <<enum>> <<enum>> + + + + + + A_SE CTOR B_SE CTOR C_SE CTOR D_SE CTOR E_SE CTOR F_SE CTOR
<<enumerated>> Crossway I_Configuration_Adq I_Image_Grabber I_Digital_Adq <<enum>> <<enum >> <<enum>> <<enum>> + + + + X_CR OSSW AY Xo_CROSSW AY Y_CROSSW AY Yo_CROSSW AY
Rai lway + CrosswayStates : array(Crossway) of Crossway_State + SectorOcupation : Railway_Ocupation + HZoneOcupation : Railway_Ocupation + SectorAssign : Railway_Ocupation - theMonitor : Monitor + + + + + + + + + + + + Initialize() Finalize() Register_Train(tr : Train_Link) Unregister_Train(tr : Train_Link) Set_Power() Set_State(crsswy : Crossway, st : Crossway_State) Get_State(crsswy : Crossway) : Crossway_State Set_Sector_Assign(sec : Sector, Id : Train_Id) : Boolean W ait_Sector_Ocupation(sec : Sector, sec_to_free : Sector, Id : Train_Id) W ait_Hazard_Zone(sec : Sector, Id : Train_Id) W ait_Sector_Assign(sec : Sector, Id : Train_Id) Locate()
<<enumerated>> Crossway_State <<enum>> + STRAIGHT <<enum >> + BENT <<enum>> + ANYW AY
<<s ubtype>> Train_Id
<<enumerated>> Sector_Status + RED_TRAIN + BLUE_TRAIN + NO_TRAIN
<<enumerated>> Velocity <<enum>> + STOPPED <<enum>> + LOW _SPEED <<enum>> + HIGH_SPEED
<<exception>> Not_Found
<<exception>> Register_Error
<<type>> Railway_Ocupation + ro : array(Sector) of Sector_Occ
<<Protected type>> Sector_Occ <<t ask type >> Monitor <<ent ry>> + Run() I_Image_Managing - value : Sector_Status + W rite(st : Sector_Status) + Read() : Sector_Status <<entry>> + W ait_For_Red() <<entry>> + W ait_for_Blue() + W rite_If_Free(st : Sector_Status, flag : out boolean) <<entry>> + W rite_W hen_Free(st : Sector_Status) <<entry>> + Free_W hen_Red() <<entry>> + Free_W hen_Blue()
I_Img_Logic_Processing
I_Img_St atist ic
A fin de documentar de forma precisa la arquitectura software de la aplicacin se incluye a continuacin la especificacin del paquete Railway_Resources.ads.
--********************************************************************************* -- Demostrador: CBSE_Railway -- Especificacin del paquete Railway_Resources --********************************************************************************* with List_Generic; package Railway_Resources is ---- TIPOS ----------------------------------------------------------type Sector_Status is (RED_TRAIN,BLUE_TRAIN,NO_TRAIN); subtype Train_Id is Sector_Status range RED_TRAIN..BLUE_TRAIN; type Sector is (A_SECTOR,B_SECTOR,C_SECTOR,D_SECTOR,E_SECTOR,F_SECTOR); type Velocity is (STOPPED,LOW_SPEED,HIGH_SPEED); type Crossway is (X_CROSSWAY,Xo_CROSSWAY,Y_CROSSWAY,Yo_CROSSWAY); type Crossway_State is (STRAIGHT,BENT,ANYWAY); type Route_Id is (LARGE,EXTERNAL,INTERNAL,RIGHT,LEFT);
82
diciembre 2002
type Stage_Id is Positive; type Train is private; type Train_Link is access Train; type Route is private; protected type Sector_Occ is procedure Write(st:Sector_Status); function Read return Sector_Status; entry wait(Train_Id); entry Wait_For_Red; entry Wait_For_Blue; procedure Write_If_Free(st:Sector_Status;flag:out Boolean); entry Write_When_Free(st:Sector_Status); entry Free_When_Red(sector_to_free:Sector); entry Free_When_Blue(sector_to_free:Sector); private value:Sector_Status; end Sector_Occ; type Railway_Ocupation is array(Sector)of Sector_Occ; ---- VARIABLES DE ESTADO --------------------------------------------CrosswayStates :array(Crossway)of Crossway_State; SectorOcupation:Railway_Ocupation; HZoneOcupation :Railway_Ocupation; SectorAssign :Railway_Ocupation; ---- OPERACIONES------------------------------------------------------- Railway procedure Initialize; procedure Finalize; procedure Register_Train(tr:Train_Link); procedure Unregister_Train(tr:Train_Link); procedure Set_Power; procedure Set_State(crsswy:Crossway;st:Crossway_State); function Get_State(crsswy:Crossway)return Crossway_State; function Set_Sector_Assign(sec:Sector;Id:Train_Id)return Boolean; procedure Wait_Sector_Ocupation(sec:Sector;sec_to_free:Sector;Id:Train_Id); procedure Wait_Hazard_Zone(sec:Sector;Id:Train_Id); procedure Wait_Sector_Assign(sec:Sector;Id:Train_Id); procedure Locate; -- Train procedure procedure procedure procedure -- Route procedure Create(Self:in out Route;Id:Route_Id); function Size (Self:Route) return Positive; function Current_sector(Self:Route;current:Stage_Id)return Sector; function Next_sector(Self:Route;current:Stage_Id)return Sector; function Next_crossway(Self:Route;current:Stage_Id)return Crossway; function Next_crossway_State(Self:Route;current:Stage_Id)return Crossway_State; function First_Stage(Self:Route;s:Sector)return Stage_Id; Create(Self: Train_Link;Id: Train_Id;ro: Route;rounds: Positive); Start(Self: Train_Link); Set_Velocity(Self: Train_Link;v: Velocity); Sector_In(Self: Train_Link);
83
diciembre 2002
---- EXCEPCIONES ----------------------------------------------------Register_error : exception; Not_Found : exception; Route_Error : exception; private RegisterTrains: array(Train_Id)of Train_Link; task type TrainTask is entry Run(theTrain:Train_Link); end TrainTask; type TrainTask_Link is access TrainTask; type Train is record id : Train_Id; theRoute : Route; veloc : Velocity; position : Stage_Id; initial_pos: Stage_Id; rounds : Natural; theDriver : TrainTask_Link:=new TrainTask; end record; package Sector_Object_List is new List_Generic (Sector); type Route is id sector_Lst si end record; record : Route_Id; : Sector_Object_List.List; : Positive;
task type Monitor is entry Run; end Monitor; theMonitor: Monitor; end Railway_Resources; --*********************************************************************************
El prximo listado de cdigo muestra el programa principal de la aplicacin demostrador que hace uso de los recursos ya definidos.
--********************************************************************************* -- Demostrator: CBSE_Railway -- Main procedure --********************************************************************************* with Railway_Resources; with Ada.Text_IO; with Ada.Exceptions; with Win32; with Win32.Winbase; with Win32.Winnt; procedure Main is trenRojo: Railway_Resources.Train_Link;
84
diciembre 2002
trenAzul: Railway_Resources.Train_Link; rutaR : Railway_Resources.Route; rutaB : Railway_Resources.Route; hProcess : Win32.Winnt.HANDLE; b : Win32.BOOL; begin hProcess:=Win32.Winbase.GetCurrentProcess; b:=Win32.Winbase.SetPriorityClass(hProcess, Win32.Winbase.REALTIME_PRIORITY_CLASS); Railway_Resources.Create(rutaR,Railway_Resources.INTERNAL); Railway_Resources.Create(rutaB,Railway_Resources.EXTERNAL); Railway_Resources.Create(trenRojo, Railway_Resources.RED_TRAIN, rutaR, 3); Railway_Resources.Create(trenAzul, Railway_Resources.BLUE_TRAIN, rutaB, 3); Ada.Text_IO.Put_Line("Pulsa intro para comenzar"); Ada.Text_IO.Skip_Line; Railway_Resources.Start(trenRojo); Railway_Resources.Start(trenAzul); Ada.Text_IO.Put_Line("Pulsa intro cuando se detengan los trenes"); Ada.Text_IO.Skip_Line; Railway_Resources.Finalize; exception when Railway_Resources.Register_Error => Ada.Text_IO.Put_Line("Error Register_Error"); raise; when Railway_Resources.Route_Error => Ada.Text_IO.Put_Line("Error Route_Error"); raise; when Railway_Resources.Not_Found => Ada.Text_IO.Put_Line("Error Not_Found"); raise; when E:others => Ada.Text_IO.Put_Line("Error desconocido"); Ada.Text_IO.Put_Line(Ada.Exceptions.Exception_Message(E)); raise; end Main; --**********************************************************************************
85
diciembre 2002
IV.4. Modelo de los componentes lgicos de la aplicacin Para construir el modelo de tiempo real de la aplicacin, es necesario construir en primer lugar el modelo de las dos clases Train y Railway diseadas especficamente para construir la aplicacin. En ambos casos, el modelo se ha formulado como un descriptor <<MAST_component_descr>>, que incluye todos los elementos necesarios para construir el modelo de la instancia.
IV.4.1. Modelo MAST de la clase Railway En la siguiente figura se muestra el modelo MAST de la clase lgica Railway.
digital <<ref>> I_Digital_Adq grabber <<ref>> I_Image_G rabber imgManaging <<ref>> I_Img_Managing imgT ransforming <<ref>> I_mg_T ransforming imgLogicalP roc <<ref>> I_Image_Logical_Processing imgStatistic <<ref>> I_Img_Statistic <<job>> + Wait_Hazard_Zone() <<job>> + Set_Veloci ty() <<job>> + Set_State() <<job>> + Locate(End : T imed_State, ImageSize = Image_Size) <<job>> + Locate_Sector(ImageSize = Image_Size) <<simple>> - Power_Mng(wcet = 16.1E-6, bcet = 3.8E-6) <<MAST_Component_Descr>> Railway_RT _Model <<par>> Monitor_Priority : MAST_Priority <<obj>> Monitor : Monitor_T ask <<obj>> Locate_Polling : Polling_T ask <<obj>> theCrossWayLock : MAST _Inmediate_Ceiling_Resource(Ceiling:MAST_Priority) <<par>> Image_ Size : MAST _Fac tor <<par>> CrossPulseWidth : MAST _Normalized_Execution_T ime = 0.3 <<obj>> A_Sector = Sector(SecTime =3.9) <<obj>> B_Sector = Sector(SecTime =1.25) <<obj>> C_Sector = Sector(SecTime =3.9) <<obj>> D_Sector = Sector(SecTime =1.25) <<obj>> E_Sector = Sector(SecTime =2.45) <<obj>> F_Sector = Sector(SecTime=2.45)
<<MAST_FP_Sched_Server>> Locate_Polling <<obj>> policy = Polling_FP(T he_Priority=Monitor_Priority,The_Period=0.4,pwo=0.0)
<<MAST_FP_Sched_Server>> Mon itor_T ask << obj>> policy = Preemptible_FP(prio rity=Monitor_Priority)
<<MAST_Component_Descr>> Sector <<par>> SecT ime : MAST_Normalized_Execution_T ime <<job>> + Run(st : MAST _Normalized_Execution_T ime = SecT ime, ss : MAST_Scheduling_Server = Locomotive.server)
<<obj>>
Locomotive
<<MAST_Component_Descr>> RTM_Locomotive <<obj>> proc : MA ST_FP_Processor(Max_ Priorit y = 1,Min_Priority=1) - sever : M AS T_FP_Sc heduling_Serv er(policy = MAST_FP_NonP reemtible(p riority:=1),h os t=proc)
86
diciembre 2002
El modelo MAST de la clase lgica Railway contiene la siguiente informacin:
Identificador: Railway_RT_Model: Identificador que debe utilizarse para declarar un modelo que sea una instancia de este descriptor.
Parmetros: <<par>> Monitor_Priority : MAST_Priority: Permite establecer en cada instancia la prioridad en que se ejecuta la tarea que realiza el anlisis del estado de la maqueta mediante visin artificial. <<par>> Image_Size : MAST_Factor: Permite establecer en cada instancia el tamao en pxels de las imgenes adquiridas para la deteccin. Son utilizadas para escalar los tirempos de procesado de las imgenes. <<par>> CrossPulseWidth : MAST_Normalized_Execution_Time = 0.3. Permite establecer en cada instancia del modelo la duracin del pulso que debe ser aplicado a los electroimanes de los cruces de va. Aunque es un tiempo normalizado, se corresponde con un tiempo fsico, ya que se ejecuta en un Device que tiene SpeedFactor=1.0.
Referencias: <<ref>> digital :MAST_Interface_Descr: Permite establecer en cada instancia el modelo del objeto que implementa la interface del tipo I_Digital_Adq que se utiliza. <<ref>> grabber :MAST_Interface_Descr:Permite establecer en cada instancia el modelo del objeto que implementa la interface del tipo I_Image_Grabber que se utiliza. <<ref>> imgManaging :MAST_Interface_Descr:Permite establecer en cada instancia el modelo del objeto que implementa la interface del tipo I_Img_Managing que se utiliza. <<ref>> imgTransforming :MAST_Interface_Descr:Permite establecer en cada instancia el modelo del objeto que implementa la interface del tipo I_Img_Transforming que se utiliza. <<ref>> imgLogicalProc :MAST_Interface_Descr:Permite establecer en cada instancia el modelo del objeto que implementa la interface del tipo I_Img_Logical_Processing que se utiliza. <<ref>> imgStatistic :MAST_Interface_Descr:Permite establecer en cada instancia el modelo del objeto que implementa la interface del tipo I_Img_Statistic que se utiliza.
Objetos: <<obj>> Monitor : Monitor_Task: Por cada instancia del modelo se intancia un componente del tipo Monitor_Task, tamben declarado en el modelo y que es un 87
diciembre 2002
MAST_FP_Sched_Server, con politica y prioridad declarada. Modela la tarea en la que se ejecuta el cdigo de evaluacin del estado de la maqueta por visin artificial. Ejecuta periodicamente (cada 350 mseg.) las operaciones Locate y Locate_Sector que detecta la posicin de los trenes. <<obj>>Locate_Polling : Polling_Task: Por cada instancia del modelo se intancia un componente del tipo Locate_Polling, tamben declarado en el modelo y que es un MAST_FP_Sched_Server, con politica de planificacin del tipo Polling_FP. La tarea Polling_Task es una tarea peridica que solo existe en el modelo y que se ha introducido para modelar el hecho de que no detectamos los trenes en el preciso instante en que llegan a la zona de peligro, sino que tenemos una cierta incertidumbre debido a que la deteccin se realiza cada 350 mseg. En esta tarea se ejecuta la operacin Wait_Hazard_Zone , que tiene duracin nula ya que se trata simplemente de una espera hasta que el resultado de la deteccin nos indica que el tren a llegado a una determinada zona de peligro. <<obj>> theCrossWayLock :MAST_Inmediate_Ceiling_Resource(Ceiling: MAST_ Priority): Por cada instancia del modelo se intancia un shared resource que modela el acceso con exclusin mtua al hardware que controla los cruces de vas de la maqueta. <<obj>> A_Sector = Sector(SecTime =3.9), <<obj>> B_Sector = Sector(SecTime =1.25), <<obj>> C_Sector = Sector(SecTime =3.9), <<obj>> D_Sector = Sector(SecTime =1.25), <<obj>> E_Sector = Sector(SecTime =2.45) y <<obj>> F_Sector = Sector(SecTime=2.45): modelan los seis tramos de la maqueta. Cada uno de ellos tiene un parmetro SecTime que indica el tiempo en segundos que tarda un tren (suponemos que el tren rojo y el azul son idnticos y por tanto tardan lo mismo) en recorrer el sector si no se detiene nunca (en nuestro caso se midi con un slo tren recorriendo todos los sectores de la maqueta). La operacin Run representa la accin de recorrer todo el sector a velocidad HIGH_SPEED, de modo que sus tiempos (wcet y bcet) son iguales al parmetro SecTime. De cualquier modo, en este tiempo el procesador no se utiliza y queda libre para realizar otras operaciones.
Modos de uso: <<job>> + Wait_Hazard_Zone(): Modela la incertidumbre que resulta en la determinacin de un tren a una zona de peligro como consecuencia de que el estado de la maqueta se determina con una granularidad de 350 ms. Consiste en la ejecucin de una operacion de duracin nula (MAST_NOP) en el scheduling server LocatePolling que tiene una poltica de planificacin del tipo Polling_FP.
Locate_Polling
W ait_Hazard_Zone do/ MAST_NOP
88
diciembre 2002
<<job>> + Set_Velocity():modela la asignacin de las tensiones a los distintos tramos en funcin de la velocidad de los trenes que se encuentran sobre ellos. Se describe mediante el siguiente diagrama de actividad:
Act do/ Power_Mng do/ Digital.DO_Write do/ Digital.DO_Write do/ Digital.DO_Write do/ Digital.DO_Write do/ Digital.DO_Write do/ Digital.DO_Write do/ Digital.DO_Write do/ Digital.DO_Write
<<job>> + Set_State() modela el control de los cruces y se describe mediante el siguiente diagrama de actividad:
activity do/ Lock(theCrossWayLock) do/ digitalActive.Generate_Pulse(duration=CrossPulseWidth) do/ Unlock(theCrossWayLock)
<<job>> + Locate(End : Timed_State, ImageSize = Image_Size): Modela la se cuencia de operaciones que se ejecutan para capturar, digitalizar, y procesar la imagen a fin de localizar la posicin de las locomotoras sobre la va. Se describe mediante el siguiente diagrama de actividad
89
diciembre 2002
Act_1 do/ grabber.Acquire Act_2 do/ grabber.Read(imgSize=imageSize)
Act_3 do/ Img_Managing.Import(Time_Factor=1.0)
Act_4 do/ Img_Transforming.Color_Detec(Time_Factor=1.0)
Act_5 do/ Locate_Sector(ImgSize=ImageSize)
Act_10 do/ Locate_Sector(ImgSize=ImageSize) <<Timed_State>> End
Se adquiere la imagen , se importa a un formato propio del componente de anlisis de imagen y se detectan los trenes ( colores rojo y azul ) utilizando la operacin Color_Detec, en nuestro caso con los siguientes umbrales de deteccin:
90
diciembre 2002
Rmax Tren Rojo Tren Azul 255 110
Rmin 150 1
Gmax 200 255
Gmin 50 90
Bmax 255 255
Bmin 50 175
Locate_Sector(ImageSize = Image_Size): Finalmente se ejecuta para cada uno de los seis sectores la operacin Locate_Sector , descrita mediante el siguiente diagrama de actividad:
Act_8 do/ Img_Logical_Processing.Logic _And(Time_Factor=1.0) do/ Img_Stat ist ic.Count _Non_Zero(Time_Fac tor=1.0)
Act_10 do/ Img_Logical_Processing.Logical_And(Time_Factor=1.0) do/ Img_Statist ic. Count_Non_Zero(Time_Fact or=1.0) Act_12 do/ Img_Logical_Processing.Logic_And(Time_Factor=1.0) do/ Img_Statistic.Count_Non_Zero(Time_Factor=1.0) Act_14 do/ Img_Logical_Processing.Logic _And(Time_Factor=1.0) do/ Img_Stat ist ic.Count _Non_Zero(Time_Fac tor=1.0)
Se repite cuatro veces ( para las zonas de deteccin y peligro del sector para el tren rojo y el azul ) la siguiente operacin: se ejecuta una operacin lgica And entre el resultado del anlisis de color y la mscara de la zona correspondiente ( almacenada en memoria en la inicializacin de la aplicacin ) y se cuenta el nmero de pxels blancos de la imagen obtenida. Si este nmero supera un umbral ( en nuestro caso es de 8 pxels ) suponemos que la deteccin es positiva , y si no lo supera suponemos que es negativa. <<simple>> - Power_Mng(wcet = 16.1E-6, bcet = 3.8E-6): Modela las operaciones de gestin para determinar las posiciones de los rels de la tarjeta intermedia de control en funcin de las tensiones necesarias en los distintos tramos y se describe como una operacin <<simple>>. Las dos primeras escrituras digitales determinan las dos tensiones necesarias ( T1 y T2 ) y las seis siguientes las asignan a los seis tramos adecuadamente1.
1. Ver anexo B.
91
diciembre 2002
IV.4.2. Modelo MAST de la clase Train En la siguiente figura se muestra el modelo MAST de la clase lgica Train.
< < M A S T_Compon ent_D esc r > > Train_RT_M odel < < par> > Train_P riority : M A S T_P riority < < obj> > theDriver : Train_Tas k (theP riority = Train_P riority ) < < ref> > theRailway : Railway _RT_M odel < < obj> > theE ngine : M A S T_Devic e < < obj> > theLoc om otive : M A S T_F P _S c hed_S erver(hos t = theE ngine) < < job> > < < job> > < < job> > < < job> > + + + + Run_Nex t_S ec tor(the_S ec tor : S ec tor) Run_F irs t_Se c tor(the_S ec tor : S ec tor, Haz ar d_S top : Tim ed_S tate) Run_E x ternal(hz S top : Tim ed_S tate, end : Tim ed_S tate) Run_Internal(hz S top : Tim ed_S tate, end : Tim ed_S tate)
< < M A S T_Com ponent_Des c r> > Rail way _R T_M odel (from Railway )
< < M A S T_Com ponent_Des c r> > S ec tor (from Railway )
< < M A S T_Com ponent_Des c r> > M A S T_F P _S c hed_S erver:Train_Tas k < < obj> > P olic y = P reem ptible_F P _P olic y (priority = TheP riority ) < < par> > theP riority : M A S T_P riority
El modelo MAST de la clase lgica Train contiene la siguiente informacin: Identificador: Train_RT_Model:Identificador que debe utilizarse para declarar un modelo que sea una instancia de este descriptor.
Parmetros: <<par>> Train_Priority : MAST_Priority: A travs de este parmetro se puede asignar a cada instancia del modelo, la prioridad de la tarea en que se se ejecuta el cdigo de control de la locomotora.
Referencias: theRailway : Railway_RT_Model: Referencia al modelo del objeto de la clase Railway que proporciona los recursos que requiere el movimiento del tren.
Objetos:
92
diciembre 2002
<<obj>> theDriver : Train_Task(thePriority = Train_Priority): Objeto de la clase Train_Task definida en el modelo y que representa un MAST scheduling server con poltica preemtible, en el que se ejecuta el cdigo de control del tren. <<obj>> theEngine : MAST_Device: Modela a la locomotora fsica, capaz de recorrer sucesivamente sectores de acuerdo con su ruta. Es un MAST processing resource con los valores por defecto asignados a sus parametros (son irrelevantes ya que solo ejecuta operaciones de forma secuencial). <<obj>> theLocomotive : MAST_FP_Sched_Server(host = theEngine). Representa el scheduling server auxiliar para ejecutar las operaciones de recorrer tramos en el processing resource theEngine.
Modos de usos: <<job>> + Run_Next_Sector(the_Sector : Sector): Modela el paso de un sector a otro y se modela con el siguiente diagrama de actividad:
Act_1 do/ theRailway.Wait_Hazard_Zone
Act_2 do/ theRailway.Set_Velocity
<<MAST_Timed_State>> Hazard_Stop
Act_4 do/ theRailway.Set_State
Act_6 do/ the_Sector.Run
En primer lugar el sistema se queda en espera hasta que el tren llega a la zona de peligro. Cuando llega se pasa la velocidad a LOW_SPEED. A continuacin , si el siguiente tramo no es accesible , se detiene el tren ( velocidad a STOPPED ) hasta que sea accesible1. Cuando ya sea accesible se coloca el cruce correpondiente en la
93
diciembre 2002
posicin adecuada , se pasa a velocidad HIGH_SPEED y se comienza a recorrer el siguiente tramo. <<job>> + Run_First_Sector(the_Sector : Sector, Hazard_Stop : Timed_State):es un caso particular de la anterior que modela el primer paso de sector ( A - B para el recorrido externo o E - B para el recorrido interno ). Se ha modelado en otra operacin ya que , como veremos posteriormente , vamos a aplicar una restriccin temporal en un estado interno de la operacin. Como es lgico , su diagrama de actividad es muy similar:
Act_1 do/ theRailway .Wait_Hazard_Zone
Act_2 do/ theRailway .Set_Velocity
<<MAST_Timed_State>> Hazard_Stop
Act_5 do/ the_Sector.Run
La nica diferencia con el anterior es que en esta ocasin no aparece la actividad Set_State para fijar el estado del cruce. Al ser el primer paso de sector no es necesario , ya que tanto para el recorrido exterior ( tramo A - tramo B ) como para el interior ( tramo F - tramo B ) se pasa por el cruce C3 , cuya posicin no es relevante teniendo en cuenta el sentido de la marcha. En otros cruces en los que es necesario actuar sobre el cruce es necesario tomar un recurso del sistema ( el semforo del propio cruce ) , y actualmente la herramienta MAST de anlisis no permite aplicar restricciones temporales en estos casos. De ah que se ha modelado la operacin Run_First_Sector , con el propsito de aplicarle una restriccin temporal para el anlisis de peor caso.
1. Esta actividad aparece en el modelo ya que deseamos analizar el peor caso.
94
diciembre 2002
<<job>> + Run_External(hzStop : Timed_State, end : Timed_State): Modela el recorrido exterior ( tramos A - B - C - D ) y se describe con el siguiente tramo de actividad:
Act_1 do/ Run_First_Sector(the_Sector=B_Sector,Hazard_Stop:HzStop)
Act_2 do/ Run_Next_Sector(the_Sector=C_Sector)
Act_3 do/ Run_Next_Sector(the_Sector=Sector_D)
Act_4 do/ Run_Next_Sector(the_Sector=A_Sector)
<<MAST_Timed_State>> end
<<job>> + Run_Internal(hzStop : Timed_State, end : Timed_State): Modela el recorrido interior ( tramos E - B - F - D ) y se describe con el siguiente tramo de actividad:
Act_1 do/ Run_First_Sector(the_Sector=B_Sector,Hazard_Stop:HzStop)
Act_2 do/ Run_Next_Sector(the_Sector=F_Sector)
Act_3 do/ Run_Next_Sector(the_Sector=D_Sector)
Act_4 do/ Run_Next_Sector(the_Sector=E_Sector)
<<Timed_State>> end
95
diciembre 2002
IV.5. Modelo de las situaciones de tiempo real de la aplicacin La situacin de tiempo real Railway_Operation que se ha analizado a travs del modelo de tiempo real corresponde a la operacin normal de la maqueta con la locomotora BLUE_TRAIN circulando por la ruta externa y con la locomotora RED_TRAIN circulando por la ruta interna. A fin de poder modelar y analizar todos los requerimientos temporal con las herramientas que actualmente se dispone, se considera la condicin inicialcuando los dos trenes se encuentran respectivamente en los sectores A y E, y justamente cuando se encuentran entrando en la zona de peligro de acceso al cruce C3. En la maqueta existen cinco requerimientos de tiempo estricto que deben ser considerados: _ 1) Se requiere que cada 350 ms se realice una evaluacin por visin artificial del estado de la maqueta, y en consecuencia, que se finalice la evaluacin antes de que se inicie el siguiente ciclo. _ 2) Se requiere que antes de que antes de que transcurran 700 ms desde que la locomotora BLUE_TRAIN entra en la zona prohibida del tramo A, la locomotora debe parar, si el tramo B estuviera ocupado. _ 3) Se requiere que antes de que antes de que transcurran 700 ms desde que la locomotora BLUE_TRAIN entra en la zona prohibida del tramo C, la locomotora debe parar, si el tramo D estuviera ocupado. _ 4) Se requiere que antes de que antes de que transcurran 700 ms desde que la locomotora RED_TRAIN entra en la zona prohibida del tramo E, la locomotora debe parar, si el tramo B estuviera ocupado. _ 5) Se requiere que antes de que antes de que transcurran 700 ms desde que la locomotora RED_TRAIN entra en la zona prohibida del tramo F, la locomotora debe parar, si el tramo D estuviera ocupado. En el modelo de las situaciones de tiempo real de la aplicacin que estamos considerando, 1), 2) y 4), pero dada la simetra de la situacin, los requerimientos 2) y 3) as como los requerimientos 4) y 5) son equivalentes. En la situacin de tiempo real que se considera, se han introducido dos nuevos requerimientos de tiempo real, que no son propios de la maqueta, sino que solo se introducen a fin de obtener informacin del anlisis. Estos requerimientos son: La locomotora BLUE_TRAIN debe completar una ciclo completo de su ruta antes de que transcurran 17 s. La locomotora RED_TRAIN debe completar una ciclo completo de su ruta antes de que transcurran 15 s. Para describir el modelo de una situacin de tiempo real, es necesario describir:
96
diciembre 2002
La configuracin del sistema: Esto es, la declaracin de todas las instancias de componente que participan en ella. El conjunto de transacciones que concurren en ellas, incluyendo en ellas, los eventos externos que las disparan y los requerimientos de tiempo real que incluyen.
IV.5.1. Configuracin de la RT_Situation En el siguiente diagrama de clases, se muestra los elementos bsicos que constituyen la declaracin de <<MAST_RT_Situation>> Railway_Operation.
<<MAST_Component_Inst>> MAST_Regular_Transaction:Locate_Transaction
<<MAST_Component_Inst>> MAST_Regular_Transaction:Blue_Trai n_Transaction
<<MAST_Component_Inst>> MAST_Regular_Transaction:Red_Train_Transaction
<<MA ST_RT_S ituat ion>> Railway_Operation
<<MAST_Component_Inst>> Railway_RT_Model:Simple_Railway Monitor_Priority = 25 place = MAST_Logical_View Image_Size = 27648.0 t heCrossW ayLock.ceiling = 23 digital = The_IOCard.I_Digital_Adq digitalActive = The_IOCard.I_Digital_Adq_Active grabber = The_Grabber.I_Im age_Grabber Img_Managing = The_V ision_library.I_Img_Managing Img_Transforming = The_Vision_library. I_Im g_Transform ing Img_Logic al_Proc = The_Vision_library. I_Im g_Logical_Proces sing Img_Statist ic = The_Vision_library.I_Img_St atist ic
<<MAST_Component_Inst>> Train_RT_Model:Blue _Train t heRailway = Simple_Railway Train_Priority = 23 place = MAST_Logical_View
<<M ast_Component_Inst>> Train_RT_Model:Red_Train theRailway = Simple_Railway Train_Priority = 23 place = MAST_Logical_View
<<MAST_Component Instance>> RTM_C_Ada_Vision:The_Vision_library place = MAST_File(pat h = c:\Mast\Component\Sauce\Vis.mdl)
<<MAST_Component Instance>> RTM_C_IO_Card_9111:The_IOCard place = MAST_File(path = c:\Sauce\Adq.mdl) <<par>> Digital_Priority = 23
<<MAST_Component Instance>> RTM_C_Im age_Grabber: The_Grabber place = M AST_Filec(path = c:\Sauce\Cap. mdl) ImageSiz e = 27648.0 host host host host host host
<<MAST_Component_Inst>> NT_Processor_Mdl_1:theProcessor place = MAST_Platform_View
97
diciembre 2002
En esta RT_Situation se han declarado seis instancias de componentes, y en ellas se han explicitado los valores concretos de los parmetros que se asignan a cada una de las instancias, y las referencias a otras instancias tambin declaradas en ella que eran requeridas en los correspondientes descriptores. <<MAST_Component_Inst>>Railway_RT_Model: Simple_Railway: que modela la librera de recursos de control y supervisin de la maqueta que se utiliza. Los valores y referencias establecidas en la instancia son: Parmetros: host=theProcessor Procesador en el que se instala el componente. Monitor_Priority = 25 Prioridad de la tarea de visin artificial. place = MAST_Logical_ViewLocatizacin del descriptor de la instancia. Image_Size = 27648.0 Tamao de las imgenes que se procesan. theCrossWayLock.ceiling = 23Techo de prioridad de los semforos de los cruces. Referencias: digital = The_IOCard.I_Digital_Adq grabber = The_Grabber.I_Image_Grabber Img_Managing = The_Vision_library.I_Img_Managing Img_Transforming = The_Vision_library.I_Img_Transforming Img_Logical_Proc = The_Vision_library.I_Img_Logical_Processing Img_Statistic = The_Vision_library.I_Img_Statistic
<<MAST_Componet_Inst>>Train_RT_Model: Blue_Train: que modela el software de control de la locomotora Blue. Los valores y referencias establecidas en la instancia son: Parmetros: host=theProcessor Procesador en el que se instala el componente. Train_Priority = 23 Prioridad de la tarea de control de la locomotora. place = MAST_Logical_ViewLocatizacin del descriptor de la instancia. Referencias: theRailway = Simple_Railway
<<MAST_Componet_Inst>>Train_RT_Model: Red_Train: que modela el software de control de la locomotora Red. Los valores y referencias establecidas en la instancia son:
98
diciembre 2002
Parmetros: host=theProcessor Procesador en el que se instala el componente. Train_Priority = 23 Prioridad de la tarea de control de la locomotora. place = MAST_Logical_ViewLocatizacin del descriptor de la instancia. Referencias: theRailway = Simple_Railway
<<MAST_Componet_Inst>>RTM_C_Ada_Vision: The_Vision_Library: Modela la instancia del componente C_Ada_Vision, que se utiliza para implementar las interfaces I_Img_Managing, I_Img_Transforming, I_Img_Logical_Processing y I_Img_Statistic, que se requiere en las operaciones de visin artificial Los valores y referencias establecidas en la instancia son: Parmetros: host=theProcessor Procesador en el que se instala el componente. place = MAST_File(path = c:\Mast\Component\Sauce\Vis.mdl)
<<MAST_Componet_Inst>>RTM_C_IO_Card_9111: The_IOCard: Modela la instancia del componente C_IO_Card_9111, que se utiliza para implementar la interfaz I_Digital_Adq, que se requiere en las operaciones de control del hardware de la maqueta. Los valores y referencias establecidas en la instancia son: Parmetros: host=theProcessor Procesador en el que se instala el componente. Digital_Priority = 23 Prioridad del semforo de acceso a los cruces. place = MAST_File(path = c:\Sauce\Adq.mdl).
<<MAST_Componet_Inst>>RTM_C_Image_Grabber: The_Grabber:Modela la instancia del componente C_IG_DT3153, que se utiliza para implementar la interfaz I_Image_Grabber, que se requiere en las operaciones de captura y digitalizacin de las imgenes de vdeo. Los valores y referencias establecidas en la instancia son: Parmetros: host=theProcessor Procesador en el que se instala el componente. ImageSize = 27648.0 Tamao de las imgenes que se capturan. place = MAST_Filec(path = c:\Sauce\Cap.mdl)
99
diciembre 2002
IV.5.2. Declaracin de las transacciones En el siguiente diagrama de clases, se describen las tres transacciones que concurren en la <<MAST_RT_Situation>>Railway_Operation.
<<MAST_Component_Inst>> MAST_Regular_Transaction:Locate_Transaction
<<MAST_Component_Inst>> MAST_Hard_Global_Dealine:Locate_End deadline = 0.35
ref erenced
<<MAST_Component_Inst>> MAST_Periodic_Ev ent_Source:Locate_Trigger period = 0.35
<<MAST_ Com pon ent_ In st>> MAST_Regular_Transaction:Blue_Train_Transaction
<<MAST_Component_Instance>> MAST_Hard_Global_Deadline:Blue_End deadline = 17.0 <<MAST_Com pone nt_In st>> MAST_ Ha rd_G lob al_ De adl ine:Bl ue_ Hazard _Stop deadline = 0.7
ref erenced
<<MAST_ Co mpon ent_ Inst>> MAST_ Periodic_ Ev ent_So urce :Blue_ Exit period = 17.0
ref erenced
<<MAST_Component_Inst>> MAST_Regular_Transaction:Red_Train_Transaction
<<MAST_Component_Inst>> MAST_Hard_Global_Deadline:Red_End deadline = 15.0
ref erenced
<<MAST_Component_Inst>> MAST_Periodic_Ev ent_Source:Red_Exit period = 15.0
<<MAST_Component_Declr>> MAST_Hard_Global_Deadline:Red_Hazard_Stop deadline = 0.7
ref erenced
MAST_Regular_Transaction: Locate_Transaction: Corresponde al proceso de localizacin se realiza peridicamente y que debe acabar dentro del periodo. _ Trigger: MAST_Periodic_Event_Source: Locate_Trigger: Patrn de generacin peridico con periodo de 350 ms. _ Requerimiento temporal: MAST_Hard_Global_Dealine : Locate_End: Se requiere que debe alcanzarse el estado Locate_End, antes del inicio del siguiente periodo.
100
diciembre 2002
_ Actividad: Se describe en el siguiente diagrama de actividad:
< < W ait_S tate> > Loc ate_Trigger
A ct do/ S im ple_R ailw ay .Loc ate(end= Loc ate_E nd)
MAST_Regular_Transaction: Blue_Train_Transaction: Corresponde al proceso decontrol de la locomotora BLUE_TRAIN a lo largo de su ruta externa. _ Trigger: MAST_Periodic_Event_Source: Blue_Exit: Patrn de generacin peridico con periodo de 17 s, que corresponde con el inicio de cada vuelta de la locomotora BLUE_TRAIN. _ Requerimientos temporales: _ MAST_Hard_Global_Dealine: Blue_Hazard_Stop: Se requiere que el programa de control pare antes de 700 ms el tren si el sector B est ocupado. _ MAST_Hard_Global_Deadline: Blue_End: Se requiere que la locomotora de una vuelta completa antes de 17 s. _ Actividad: Se describe en el siguiente diagrama de actividad:
< < W a it _ S t a t e > > B lu e _ E x it
Act d o / B lu e _ Tra in . R u n _ E x t e rn a l(H z S t o p = B lu e _ H a z a rd _ S t o p , e n d = B lu e _ E n d )
101
diciembre 2002
MAST_Regular_Transaction: Red_Train_Transaction: Corresponde al proceso decontrol de la locomotora RED_TRAIN a lo largo de su ruta interna. _ Trigger: MAST_Periodic_Event_Source: Red_Exit: Patrn de generacin peridico con periodo de 15 s, que corresponde con el inicio de cada vuelta de la locomotora RED_TRAIN. _ Requerimientos temporales: _ MAST_Hard_Global_Dealine: Red_Hazard_Stop: Se requiere que el programa de control pare antes de 700 ms el tren si el sector B est ocupado. _ MAST_Hard_Global_Deadline: Red_End: Se requiere que la locomotora de una vuelta completa antes de 15 s. _ Actividad:Se describe en el siguiente diagrama de actividad.
< < W ait_S tate> > Re d_E x it
Act do/ Red_Train.Run_Internal(hz S top= Red_Haz ard_S top,end= Red_E nd)
IV.6. Anlisis de tiempo real de la aplicacin Una vez definido el modelo completo de la RT_Situation, se ha generado un fichero MAST_File que describe el modelo en un formato interpretable con las herramientas de anlisis que nos va a analizar si el sistema es planificable y si se pueden cumplir las restricciones fijadas. En un futuro sera interesante automatizar la generacin de este fichero a partir del modelo UML, pero en al no existir actualmente la herramienta que compile el modelo CBSE_Mast al fichero MAST_File, se ha hecho la compilacin manualmente. Los resultados ms relevantes que se han obtenido son: La restriccin de tiempo de la localizacin ( 350 mseg. ) se cumple sobradamente , ya que los tiempos resultantes del anlisis son: WCET = 318.9 mseg.
102
diciembre 2002
BCET = 162.8 mseg. Esto quiere decir que an podramos haber bajado ms el periodo de la tarea de localizacin. De hecho , en la prctica el sistema funciona para valores del periodo inferiores a 300 mseg. Esto es debido a que el tiempo medio es bastante menor que el WCET. Sin embargo , no tenemos la seguridad de que el sistema funcione en el 100 % de las ocasiones. Lo que est claro es que si fijamos el periodo por debajo de BCET el sistema ni siquiera llega a poner en marcha a los trenes , ya que se ejecuta continuamente la tarea de localizacin ( ms prioritaria ) y nunca llegan a tener el control de la CPU las tareas de los trenes. La restriccin de tiempo de detencin ( 700 mseg. ) es idntica para ambos trenes , y se cumple sobradamente. Los resultados obtenidos son: WCET = 583.6 mseg. BCET = 0.17 mseg. Se cumple sobradamennte para el peor caso ( WCET ). La restriccin de tiempo de vuelta para el tren azul ( 17 seg. ) tambin se cumple , ya que los resultados son: WCET = 16.74 seg. BCET = 11.20 seg. Como era de esperar , el tiempo de mejor caso es ligeramente superior a la suma de los tiempos de los tramos que recorre1. La restriccin de tiempo de vuelta para el tren rojo ( 15 seg. ) tambin se cumple , ya que los resultados son: WCET = 13.84 seg. BCET = 8.30 seg. Como era de esperar , el tiempo de mejor caso es ligeramente superior a la suma de los tiempos de los tramos que recorre2.
1. Ver modelo del Railway : 3.9 + 1.25 + 3.9 + 1.25 = 10.3 seg. 2. Ver modelo del Railway : 2.45 + 1.25 + 2.45 + 1.25 = 7.4 seg.
103
conclusiones
diciembre 2002
V. CONCLUSIONES
Se han cubierto practicamente en su totalidad los objetivo del proyecto planteados en el apartado I.7. , y durante el desarrollo de los mismos se han obtenido interesantes conclusiones. Se ha comprobado la eficiencia del lenguaje de programacin Ada 95 para para la implementacin de componentes software. A pesar de tratarse de un lenguaje no demasiado utilizado en aplicaciones de propsito general , si est bastante implantado en el campo de las aplicaciones de tiempo real , lo que hace que sea especialmente interesante desarrollar la metodologa de desarrollo basado en componentes utilizando dicho lenguaje en este campo concreto. Ha quedado de manifiesto la validez del perfil CBSE_MAST para el modelado de componentes software de tiempo real , incluso si tenemos la necesidad de modelar operaciones relaivamente complejas ( como por ejemplo la operacin Acquire del componente C_IG_DT3153 ). Tras el desarrollo del presente trabajo se plantean varias lneas abiertas de trabajo para un futuro prximo: Se han de desarrollar herramientas que generen automticamente el cdigo Ada 95 de las interfaces y los componentes a partir de sus respectivas descripciones UML ( apartado II.4. ). Se han de desarrollar herramientas que generen automticamente el cdigo MASTFile de los componentes ( apartados III.5 y III.6. ). Se ha de plantear la posibilidad de que los componentes ofrezcan procedimientos para recalcular los valores de los parmetros de su modelo de tiempo real al cambiar de una plataforma a otra. Se han de evaluar metodologas estadsticas que nos permitan estimar con precisin las medidas temporales ( BCET , ACET y WCET ) de los modelos de tiempo real de los componentes.
104
referencias
diciembre 2002
VI. REFERENCIAS
[1] Szyperski C.: Component Software: Beyond Object-Oriented Programming AddisonWesley, 1999. [2] Medina J.L. y Drake J.M.: Modelado y Anlisis de Tiempo Real de Aplicaciones Basadas en Componentes V Jornadas de Tiempo Real. Cartagena , 2002. [3] Cameron A.: Designing Component Kits and Archiquctures with Catalysis TriReme International Ltd. http://www.trireme.com [4] Kirtland M.: Object-Oriented Software Development Made Simple with COM+ Runtime Services Noviembre 1997. Microsoft Systems Journal at http://www.microsoft.com/com, White Papers. [5] Schmidt D.: Overview of CORBA at http://cgi.omg.org/corba/beginners.html [6] Baker S.: CORBA Distributed Objects Addison-Wesley 1997. [7] Drake J.M. , Medina J.L. y Gonzlez M.: Entorno para el diseo de sistemas basados en componentes de tiempo real X Jornadas de Concurrencia , Jaca 2002. [8] Cheesman J. y Daniels J.: UML Components: A simple Process for Specifying Component-Based Software, Addison-Wesley,2000. [9] DSouza D.F. y Cameron A.: Objects, Components and Frame-works in UML: the Catalysis approach. Addison-Wesley, 1998. [10] Hassan Gomaa: Designing Concurrent, Distributed and Real-Time Application with UML. Addison-Wesley, 2000. [11] Isovic D. y Nostrm C.: Components in Real-Time Systems RTCSA2002 Tokyo. [12] Lders F. y Crnkovic I.: Experiences with Component-Based Sofware Development in Industrial Control Mlardalen Real-Time Research Center , 2001. [13] Gonzlez M., Gutirrez J.J., Palencia J.C. y Drake J.M.: "MAST: Modeling and Analysis Suite for Real-Time Applications" Proceedings of the Euromicro Conference on RealTime Systems, June 2001. [14] Medina J.L., Gonzlez M. y Drake J.M.:" "MAST Real-time View: A Graphic UML Tool for Modeling Object_Oriented Real_Time Systems", RTSS, 2001, December, 2001. [15] Medina J.L., Gutierrez J.J., Gonzlez M. y Drake J.M.:"Modeling ans Schedulability Analysis of Hard Real-Time Distributed Systems based on ADA Componentes." Ada Europe, 2002
105
referencias
diciembre 2002
[16] Kobryn C.: Modeling Components and frameworks with UML. Communications of the ACM , Octubre 2000/Vol. 43 , N 10. [17] Medina J.L.: Metodologa y herramientas UML para el modelado y anlisis de sistemas orientados a objetos de tiempo real. Tesis Doctoral (en preparacin). Universidad de Cantabria [18] ------: Intel Image Processing Library: Reference Manual Intel Corporation,1998. Order Num.:663791-002. http://developer.intel.com [19] ------: Open Source Computer Vision Library: Reference Manual Intel Corporation, 2000, Order Num.:TBD. http://developer.intel.com [20] Timmerman M.: Windows NT as Real-Time OS? Real-Time Magazine , Febrero 1997. [21] Solomon D.: Inside Windows NT Second Edition. Microsoft Press , 1998. [22] Drake J.M., Medina J.L.: UML MAST Metamodel 1.0 Grupo Computadores y Tiempo Real , Universidad de Cantabria , Febrero 2001. [23] Drake J.M.: CBSE_MAST_ConceptsGrupo Computadores y Tiempo Real , Universidad de Cantabria , Octubre 2002.
106
especificacin de los componentes
diciembre 2002
Apndice A: ESPECIFICACIN DE LOS COMPONENTES

A.1.Componente C_IG_DT3153 Especificacin funcional
<<component>> C_IG _DT3153
I_Image_Grabber
Interface I_Image_Grabber:
<<ex ception>> Start_Error <<private type>> Video_Card <<type>> PixelRGB P: array(0..3) of byte <<exception>> End_Error <<Interface>> I_Image_Grabber <<constant>> MAX_CARD : Natural = 1 <<constant>> RESOLUTION_X : Natural = 768 <<constant>> RESOLUTION_Y : Natural = 576 <<constant>> N_CHANNELS : Natural = 3 Brigthness_Values : Param_Value = 0,255,163 Contrast_Values : Param_Value = 0,511,256 V_Sat_Values : Param_Value = 0,511,180 U_Sat_Values : Param_Value = 0,511,254 Hue_Values : Param_Value = 0,255,128 Open_Card(n : Natural) : Video_Card Close_Card(c : Video_Card) Start_Video(c : Video_Card, hwnd : HWND, x : Natural, y : Natural) Stop_Video(c : Video_Card) Acquire(c : Video_Card) Snap(c : Video_Card) Read(c : Video_Card, f : Frame, data : in out PixelData) Draw_Image(c : Video_Card, hwnd : HWND) Set_Channel(c : Video_Card, ch : Channels) Set_Parameter(c : Video_Card, p : Param, value : Integer, ch : Channels) Get_Parameter(c : Video_Card, p : Param, ch : Channels) : Integer
<<type>> PixelData P: array of PixelRGB
<<ex ception>> Draw_Error
<<type>> Frame x : Natural y : Natural width : Positive height : Positive <<type>> Channels C: integer range 0..N_CHANNELS-1
<<exception>> Read_Error
<<exception>> Passthru_Error
<<ex ception>> Acquisition_Error
<<enumerate... Param Brigthness : enum Contrast : enum V_Sat : enum U_Sat : enum Hue : enum
<<exception>> Config_Error
<<exception>> O p_Not_Support (from I_Enviroment) <<Win32 type>> HWND (from I_Enviroment)
<<type>> Param_Value MIN : Integer MAX : Integer NOMINAL : Integer
<<exception>> Unknown_Error (f rom I_Enviroment)
107
diciembre 2002
A.2.Componente C_Ada_Vision Especificacin funcional.
I_ Im g _ L o g ic_ P ro ce ssin g

I_ Im g _ A rith _ P ro ce ssin g I_ Im g _ M a na g in g I_ Im g _ A n a lysis I_ Im g _ P ro ce ssin g I_ Im g _ Tra n sfo rm in g I_ Im g _ Sta tistic < < co m p o n e n t> > C _ Ada_Visio n
I_ Im g _ D ra w
Interface I_Img_Managing:
<<Interface>> I_Img_Managing <<constant>> MAX_WIDTH : Positive = 1024 <<constant>> MAX_HEIGHT : Positive = 1024 <<constant>> BITS_PER_VALUE : Positive = 8 New_Image(width : Positive, height : Positive, color : Color_Type) : Image Load_BMP(path : String) : Image Save_BMP(i : Image, path : String) Destroy_Image(i : Image) Height(i : Image) : Positive Width(i : Image) : Positive Color(i : Image) : Color_Type SetROI(i : Image, roi : Rectangle) GetROI(i : Image) : Rectangle Copy(i1 : Image, i2 : Image) Gray_To_RGB(igray : Image, iRGB : out Image) RGB_To_Gray(iRGB : Image, igray : out Image) Channels_To_RGB(iR : Image, iG : Image, iB : Image, iRGB : out Image) RGB_To_Channels(iRGB : Image, iR : out Image, iG : out Image, iB : out Image) Matrix_To_Image(m : Integer_Matrix, i : out Image) Image_To_Matrix(i : Image, m : out Integer_Matrix) <<private_type>> >> Image
<<enumerated>> Color_Type GRAY : enum RGB : enum
<<type>> Rectangle org : Pixel width : Natural height : Natural
<<type>> Pixel x : Natura l y : Natura l
<<type>> Integer_M atrix array (natural range <>,natural range<>) of integer
<<excepti on>> Op_Not_Support (from I_Enviroment)
<<excepti on>> Unknown_Error (from I_Envirom ent) )
<<exception>> Unsuitable_Operation (from I_Enviroment)
<<exception>> >> Library_Error
<<type>> Float_Matrix array (natural range <>,natural range<>) of float
<<type>> RGB_Value R : Value G : Value B : Value <<type>> Value <<type>> Integer_Array
v : is mod 2**BITS_PER_VALUE array (natural range<>) of integer
108
diciembre 2002
Interface I_Img_Processing:
<<priv ate_ty pe>> I mag e (f rom Image_Managing) <<priv ate_ty pe>> Cursor <<ty pe>> Pixel x : N atur al y : N atur al <<ty pe>> Value v : is mod 2**BITS_PER_VALUE
<<exception>> Op_Not_Support (f rom I_Env iroment)
<<Interf ace>> I_Img_Processing Init_Cursor(i : Image) : Cursor Free_Cursor(c : Cursor) Mov e(c : Cursor, dir : Direction) Mov e_Wrap(c : Cursor, dir : Direction) Mov e_To(c : Cursor, p : Pixel) Get_Pixel(c : Cursor) : Value Get_Pixel(c : Cursor) : RGB_Value Put_Pixel(c : Cursor, v : Value) Put_Pixel(c : Cursor, v : RGB_Value)
<<ty pe>> RGB_Value R : Value G : Value B : Value
<<exception>> Unsuitable_Operation (f rom I_Env iroment)
<<enumerated>> Direction NONE : enum LEFT : enum RIGHT : enum UP : enum DOWN : enum LEFT_UP : enum RIGHT_UP : enum LEFT_DOWN : enum RIGHT_DOWN : enum
<<exception>> Library _Error (fr om Image_Mana ging)
<<exception>> Unknown_Error (f rom I_Env iroment)
<<ex ception>> Value_Out_Of _Range (f rom I_Env iroment)
Interface I_Img_Logic_Processing:
<<Interface>> I_Img_Logic _Processing Logic_Not(s rc : Image, dst : out Image) Logic_And(src1 : Image, src2 : Image, dst : out Image) Logic_And(src : Image, v : Value, dst : out Image) Logic_Or(src1 : Image, src2 : Image, dst : out Image) Logic_Or(src : Image, v : Value, dst : Image) <<private_type>> Image (from Image_Managing) <<t ype>> Value v : is mod 2**BITS_PER_VALUE
<<exception>> Unknown_E rror (from I_Enviroment)
<<exception>> Op_Not_Support (from I_Enviroment)
<<exception>> Library_Error (from Image_Managing)
109
diciembre 2002
Interface I_Img_Arith_Processing:
<<Interface>> I_Img_Arith_Processing Add(src1 : Image, src2 : Image, dst : out Image) Add(src : Image, v : Value, dst : out Image) Subtract(src1 : Image, src2 : Image, dst : out Image) Subtract(src : Image, v : Value, dst : out Image) Subtract(v : Value, src : Image, dst : out Image) Multiply(src1 : Image, src2 : Image, dst : out Image) Multiply(src : Image, v : Value, dst : out Image) < <private_type>> Image (from Image_Managing) < <type>> Value v : is mod 2**BITS_PER_VALUE
<<exception>> Op_Not_Support (from I_Enviroment) )
<<exception>> Unknown_Error (from I_Enviroment) )
<<exception>> Library_Error (from Image_Managing) )
Interface I_Img_Transforming:
<<type>> Integer_Matrix array (n atural range < >,natu ral rang e<>) o f intege r <<private_type>> Image (from Image_Managing)
<<Interface>> I_Img_Transforming
<< enume rated> > Interpolation_Method
INTE R_NN : enum Zoom(src : Image, dst : out Image, int_met : Interpolation_Method) Rotate(src : Image, dst : out Image, angle : float, xShift : Natural, yShift : Natural, int_met : Interpolation_Method) INTE R_LINE AR : e num INTE R_CUB IC : en um Mirror(src : Image, dst : out Image, axis : Symmetry_Axis) FFT(src : Image) : Integer_Matrix Inverse_FFT (data : Integer_Matrix, dst : out Image) DCT(src : Image) : Integer_Matrix Inverse_DCT(data : Integer_Matrix, dst : out Image) Erode(src : Image, dst : out Image, n : Positive) Dilate(src : Image, dst : out Image, n : Positive) Open(src : Image, dst : out Image, n : Positive) Close(src : Image, dst : out Image, n : Positive) Filter(src : Image, dst : out Image, kernel : Integer_Matrix, c_row : Natural, c_col : Natural, shift : Natural) <<enu merate d>> Median _Filter(dst : out Image, src : Image, n : Positive) Symmetry_Axis Min_Filter(src : Image, dst : out Image, n : Positive) VER_AXIS : enum Max_Filter(src : Image, dst : out Image, n : Positive) HOR_AXIS : enum Threshold(src : Image, dst : out Image, thres : Value) BOTH_AXIS : enum Eq_Histogram(src : Image, dst : out Image) Border(src : Image, dst : out Image, sobel_order : Positive, min : Value, max : Value) Segmentation(src : Image, dst : out Image, level : Natural, link_thres : Value, segm_thres : Value)
<<exception>> Op _Not_S upport (from I_Enviroment) )
<<exception>> Unknown_Error (from I_Enviroment) )
<<exception>> Unsuita ble_Op eration (from I_Enviro ment)
<<exception>> Library_Error (f rom Im age_M anagin g) )
110
diciembre 2002
Interface I_Img_Statistic:
<<Interface>> I_Img_Statistic Count_Non_Zero(i : Image) : Natural Sum_Pixels(i : Image) : Natural Mean(i : Image, mean : out Float, std_dev : out Float) Min_Location(i : Image, min : out Value, pos : out Pixel) Max_Location(i : Image, max : out Value, pos : out Pixel) Central_Moment(i : Image, m : Natural, n : Natural) : Float Spatial_Moment(i : Image, m : Natural, n : Natural) : Float <<private_type>> Ima ge (from Image_Managing)
<<type>> P ixel x : Natural y : Natural
<<exception>> Unknown_Error (from I_Enviroment)
<<exception>> Op_Not_Support (from I_Enviroment) <<e xception>> Unsuitable_Operation (fro m I_Enviroment)
<<exception>> Value_Out_Of_Range (from I_Enviroment)
Interface I_Img_Analysis:
<<enumerated>> Matching_Method SQDIFF : enum SQDIFF_NORMED : enum CCORR : enum CCORR_NORMED : enum CCOEFF : enum CCOEFF_NORMED : enum <<subtype>> Ellipse_Param x : Fl oat y : Fl oat long_axis : Float short_axis : Float angle : Float <<subtype>> Corners array (1..49) of Pixel <<type>> Float_Matrix array (natural range <>,natural range<>) of float
<<private_type>> Image (from Image_Managing)
<<type>> Pixel <<Interface>> I_Img_Analysis Fi t_Line(src : Image, ref_point : out Pixel, dir_x : out Posi tive, dir_y : out Positive) Fi t_Ellipse(s rc : Image) : Ellipse_Param Match_Template(src : Image, template : Image, met : Matching_Method) : Float_Matrix Di stance_Transform(src : Image) : Float_Matrix Chessboard_Corners (src : Image) : Corners Boundary(src : Image, dst : out Image, p_min : Natural, p_max : Natural, n : out Natural, nptos : Integer_Array) Boundary(src : Image, p_min : Natural, p_max : Natural, n : out Natural, nptos : Integer_Array) x : Natural y : Natural
<<type>> Integer_Array array (natural range<>) of integer
<<exception>> CB_Not_Detected
111
diciembre 2002
Interface I_Img_Draw:
<<In te rface>> I_Img_Draw Circle(src : Image, center : Pixel, radius : Natural, RGB : RGB_Value) Circle(src : Image, center : Pixel, radius : Natural, Gray : Value) Circunference(src : Image, center : Pixel, radius : Natural, thick : Natural, RGB : RGB_Value) Circunference(src : Image, center : Pixel, radius : Natural, thick : Natural, Gray : Value) Line(src : Image, p1 : Pixel, p2 : Pixel, thick : Natural, RGB : RGB_Value) Line(src : Image, p1 : Pixel, p2 : Pixel, thick : Natural, Gray : Value) Rectangle(src : Image, r : Rectangle, thick : Natural, RGB : RGB_Value) Rectangle(src : Image, r : Rectangle, thick : Natural, Gray : Value) Poly(src : Image, pol : Polygonal, n : Positive, thick : Natural, RGB : RGB_Value) Poly(src : Image, pol : Polygonal, n : Positive, thick : Natural, Gray : Value) Fill_Poly(src : Image, pol : Polygonal, n : Positive, RGB : RGB_Value) Fill_Poly(src : Image, pol : Polygonal, n : Positive, Gray : Value) Elip_Arc(src : Image, arc_p : Arc_Param, thick : Natural, RGB : RGB_Value) Elip_Arc(src : Image, arc_p : Arc_Param, thick : Natural, Gray : Value) Text(src : Image, t : String, height : Natural, max_width : Natural, thick : Natural, RGB : RGB_Value) Text(src : Image, t : String, height : Natural, max_width : Natural, thick : Natural, Gray : Value) Flood_Fill(src : Image, val : Value, seed_point : Pixel, low_dif : Value, upp_dif : Value) : Natural <<private_type>> Image (from Image_Managing) <<type>> Pixel x : Natural y : Natural
<<type>> Rectangle org : Pixel width : Natural height : Natural <<type>> Value v : is mod 2**BITS_P ER_ VA LUE
<<subtype>> Arc_Param <<exception>> L ib ra ry_Error (fromImage_Managing ) center : Pixel long_axis : Natural short_axis : Natural orient_angle : Float start_angle : Float end_angle : Float
<<exception>> Unsuitab le_ Operatio n (from I_Enviroment)
<<exception>> Unknown_Error (from I_Enviroment) <<type>> RGB_Value <<subtype>> Polygonal array (natural range <>) of Pixel R : Value G : Value B : Value
112
diciembre 2002
A.3.Componente C_PCI9111 Especificacin funcional.

< < co m p o n en t> > C _P C I9 111
I_ A n alo g _ A d q
I_ D ig ita l_A d q
I_ A ctive _ A n a lo g _ A d q
I_ A d q_ C o nfig ura tion
I_ A ctive _ D ig ita l_ A d q
Interface I_Adq_Configuration:
<< Interface> > I_ Adq _C onfi g ura tio n << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> << constant>> M AX_CARD : Natural = 32 AI_M IN_CARD : Voltag e = -10.0 AI_M AX_CARD : Voltag e = 10.0 AI_M AX_RATE : Samplig _rate = 110000.0 AI_BUFFER_SIZE : Natural = 1024 AI_RESOLUTION : Natural = 12 AI_NUM _CHANNELS : Natural = 16 AO_M IN_CARD : Voltag e = -10.0 AO_M AX_CARD : Voltag e = 10.0 AO_RESOLUTION : Natural = 12 AO_NUM _CHANNELS : Natural = 1 DI_NUM _LINES : Natural = 20 DO_NUM _LINES : Natural = 20 << private_type> > Gain << private_type> > Card << type> > Voltag e v : Float
<< type> > Sampling _Rate sr : Float << type> > Code c : Natu ral << private_type> > Input_Channel_Id
Open_Card(n : Natural) : Card Close_Card(c : Card) AI_M in_Channel(g : Gain) : Voltag e AI_M ax_Channel(g : Gain) : Voltag e AI_Code(v : Voltag e, g : Gain) : Code AI_Voltag e(c : Code, g : Gain) : Voltag e AI_Channel(n : Natural) : Input_Channel_Id AI_Channel_Index(ci : Input_Channel_Id) : Natural AO_Code(v : Voltag e) : Code AO_Voltag e(c : Code) : Voltag e AO_Channel(n : Natural) : Output_Channel_Id AO_Channel_Index(co : Output_Channel_Id) : Natural DI_Line(n : Natural) : Input_Line_Id DI_Line_Index(l : Input_Line_Id) : Natural DO_Line(n : Natural) : Output_Line_Id DO_Line_Index(I : Output_Line_Id) : Natural Gain_Code(g : Float) : Gain Gain(g c : Gain) : Float Define_Input_Port(li : Input_Line_Id, If : Input_Line_Id) : Input_Port_Id Define_Output_Port(li : Output_Line_Id, lf : Output_Line_Id) : Output_Port_Id Create_Buffer() : Sig nal_Buffer Destroy_Buffer(b : Sig nal_Buffer) Get_Buffer_Values(b : Sig nal_Buffer) Clear_Buffer(b : Sig nal_Buffer) Get_First_Value(b : Sig nal_Buffer) : Code Get_Last_Value(b : Sig nal_Buffer) : Code
<< private_type> > Output_Channel_Id
<< private_type> > Input_Line_Id << private_type> > Output_Line_Id
<< private_type> > Input_Port_Id << private_type> > Output_Port_Id
<< private_type> > Sig na l_ Buf fer
<< exception> > Op_Not_Support (from I_Enviroment)
<< exception> > Unknown_Error (from I_Enviroment)
<< exception> > Unsuitable_Operation (from I_Enviroment)
<< exception> > Value_Ou t_Of_R ang e (fro m I_ Envirom ent)
113
diciembre 2002
Interface I_Analog_Adq:
<< private _type>> Card (from Adq_Config) <<private_type>> In put_Channel_ Id (from Adq_Config) <<private_type>> Output_Channel_Id (from Adq_Config)
<<Interface>> I_Analog_Adq gain_code : Gain AI_Read(c : Card, ch : Input_Channel_Id) : Voltage AI_Read(c : Card, ch : Input_Channel_Id) : Code AI_Read(c : Card, ch : Input_Channel_Id, g : Gain) : Voltage AI_Read(c : Card, ch : Input_Channel_Id, g : Gain) : Code AO_Write(c : Card, ch : Output_Channel_Id, v : Voltage) AO_Write(c : Card, ch : Output_Channel_Id, cod : Code) Set_Gain(gc : Gain) Get_Gain() : Gain
<< private_type>> Gain (from Adq_Config) <<type>> Voltage v : Float
<<type>> Code c : Natural
<<exception>> Op_Not_S upp ort (from I_Enviroment)
<<exception>> Unknown_Error (from I_ En viromen t)
<<exception>> Va lue_Out_Of_Range (from I_Enviroment)
Interface I_Active_Analog_Adq:
<<type>> Sampling_Rate sr : Float <<private_type>> Card (from Adq_Config) <<private_type>> Signal_Buffer (from Adq_Config) <<type>> Voltage v : Float <<private_type>> Input_Channel_Id (from Adq_Config)
<<Interface>> I_Acti ve_Analog _Adq samplingR ate : Sampling_Rate samplingC lockSource : Sampling_Clock_Source signalTransfer : Signal_Tr ansfer _Mode Set_SamplingRate(sr : Sampling _Rate) Set_SamplingClock(sc : Sampling_Clock_Source) Sample(c : Card) Sampling_Signal (c : Card, ch : Channnel_Id, Buff : Signal_Buffer ) Set_Signal Transfer(sgtr : Signal _Transfer_mode) Get_Continuous_Sampling (c : Card) Channel_F or_Continuous_Sampl ing(c : Card, ch : Input_C hannel_Id, Buff : Signal_Buffer) Aw ait_Value(c : Card, ch : Input_Channel_Id, Value : Voltage, slp : Slope) Start_Continuous _Sampling(c : Card) Stop_Conti nuous_Sampling(c : Card)
<<enumerated>> Sampling_Clok_Source INTERNAL_CLOCK EXTERNAL_CLOCK SOFTWARE_SHOT <<enumerated>> Sig nal_Transfer_M ode ONE_BUFFER SAMPLE_INTERRUPT BUFFER_INTERRUPT DMA
<<enumerated>> Slope <<exception>> Op_Not_Support (from I_Enviroment) <<exception>> Unsuitable_Operation (from I_Enviroment) <<exception>> Buffer _OverWriting ASCENDING DESCENDING
<<exception>> Value_Out_Of_Range ( from I_Env iroment)
114
diciembre 2002
Interface I_Digital_Adq:
<<private_type>> Card (from Adq_Config) <<private_type>> Input_Line_Id (from Adq_Config) <<private_type>> Input_Port_ Id (from A dq_Conf ig) << pri va te_type >> Outp ut _L ine_Id (fro m Adq_Config)
<<Interface>> I_Digital_Adq DI _Rea d(c : Card, ln : I nput _Line _Id) : Bo ol ean DI _Rea d_ Port (c : Card, p : I np ut _Port_I d) : Code DO _Re ad (c : Card, ln : Ou tp ut _L ine_ Id) : Bo ol ea n DO _Write (c : Card, ln : Ou tp ut _L ine_Id, valu e : B oole an ) DO _Re ad _P ort(c : Ca rd , p : Outp ut _P ort_Id) : Co de DO _Write _P ort(c : Ca rd , p : Ou tp ut _P ort_Id, v : Cod e) <<private_type>> Output_Port_Id (from Adq_Config)
<<type>> Code c : Natural
<<exception>> Op_No t_Su pp ort (from I_Enviroment)
Interface I_Active_Digital_Adq:.
<<private_type>> Card (from Adq_Config) <<private_type>> In put_L in e_ Id (from Adq_Config)
<<type>> Sampling_Rate sr : Float
<<Interface>> I_Active_Digital_Adq pollingRate : Sampling_Rate Set_Polling_Rate(pr : Sampling_Rate) Get_Polling_Rate() : Sampling_Rate Await_Change_T o_True(c : Card, ln : Input_Line_Id) Await_Change_T o_False(c : Card, In : Input_Line_Id) Await_To_T rue(c : Card, ln : Input_Line_Id) Await_To_False(c : Card, ln : Input_Line_Id) Await_Port_Arrival(c : Card, p : Input_Port_Id, v : Code) Await_Port_Exit(c : Card, p : Input_Port_Id, v : Code) Await_Port_State(c : Card, p : Input_Port_Id, v : Code) Await_Port_Not_State(c : Card, p : Input_Port_Id, v : Code) Generate_Pulse(c : Card, ln : Output_Line_Id, duration : T ime, st : Boolean) Generate_Blinking(c : Card, ln : Output_Line_Id, period : Time)
<<private_type>> Input_Port_Id (from Adq_Config)
<<private_type>> Out pu t_ Line_ Id (from Adq_Config)
<<type>> Code c : Na tu ra l
115
diseo y cableado de la tarjeta intermedia de rels.
diciembre 2002
Apndice B: DISEO Y CABLEADO DE LA TARJETA INTERMEDIA DE RELS.

Se ha diseado y construido una tarjeta intermedia de 16 rels controlados por entradas TTL , necesario para el control de la maqueta desde las salidas digitales de la tarjeta de I/O 9111-DG de la empresa Adlink utilizada en la implementacin del componente C_PCI9111. El elemento bsico del diseo es un rel de tres terminales como el que se muestra en la figura. Cuando la tensin en la bobina de control es de 0 voltios el terminal comn se cortocircuita con el terminal inferior y el superior queda en alta impedancia. Cuando la tensin en la bobina de control es de 12 voltios el terminal comn se cortocircuita con el terminal superior y el inferior queda en alta impedancia. En este ltimo caso la bobina consume una intensidad de 16.2 mA1. La tarjeta de interfase consiste en la rplica ( 16 veces ) del siguiente circuito que permite controlar los rels con niveles TTL: 15 V 180 1
R el i
C
IN
1 C 0
560 IN BC107
Cuando en el terminal IN tenemos un 0 lgico TTL el terminal C est cortocircuitado con el terminal 0. Cuando en el terminal IN tenemos un 1 lgico TTL el terminal C est cortocircuitado con el terminal 1. El cableado de la maqueta es acesible a travs de un conector DB-25 hembra , donde los distintos pines estn conectados del modo que se indica en la tabla de la pgina siguiente. Los pines 1 al 6 estn conectados a los polos positivos de los seis tramos. Los polos negativos estn conectados a 0 voltios ( GND / pin 25 ).
1. La bobina tiene una impedancia cuya parte real es de 740 .
116
diciembre 2002
Los pines 7 a 14 estn conectados a los terminales de control de los cuatro cruces. Los terminales comn de los cruces estn conectados a 0 voltios ( GND / pin 25 ). Pin DB-25 1 2 3 4 5 6 7 8 9 10 11 12 13 14 25 Conexin Tramo A Tramo B Tramo C Tramo D Tramo E Tramo F terminal RECTO C2 terminal DESVIO C2 terminal RECTO C1 terminal DESVIO C1 terminal RECTO C4 terminal DESVIO C4 terminal RECTO C3 terminal DESVIO C3 GND
117
diciembre 2002
El cableado realizado entre la tarjeta intermedia de rels y la maqueta por un lado y las salidas digitales de la tarjeta I/O por otro es:
R el 0 1 DO 0 IN C 0 R el 1 1 DO 1 IN C 0 R el 2 1 DO 2 IN C 0 R el 3 1 DO 3 IN C 0 R el 4 1 DO 4 IN C 0 R el 5 1 DO 5 IN C 0 R el 6 1 DO 6 IN C 0 R el 7 1 DO 7 IN C 0 15 V P IN 8 D O 15 IN 15 V `P IN 7 D O 14 IN T2 P IN 6 T1 D O 13 IN T2 P IN 5 T1 D O 12 IN T2 P IN 4 T1 D O 11 IN T2 P IN 3 T1 D O 10 IN T2 P IN 2 T1 DO 9 IN T2 P IN 1 T1 R el 9 1 C 0 R el 10 1 C 0 R el 11 1 C 0 R el 12 1 C 0 R el 13 1 C 0 R el 14 1 C 0 R el 15 1 C 0 15 V P IN 10 DO 8 IN R el 8 1 C 0 15 V P IN 9
15 V P IN 11
15 V P IN 12
15 V P IN 13
15 V P IN 14
7V T1
13.5 V T2
En el rel 15 se determina si T1 es 0 o 7 voltios ( LOW_SPEED ).
118
diciembre 2002
En el rel 14 se decide si T2 es 0 o 13.5 voltios ( HIGH_SPEED ). En los rels del 0 al 5 se decide si cada uno de los tramos se alimenta con T1 o con T2. En los rels 6 al 13 se controla la posicin de los cuatro cruces generando pulsos digitales en el terminal de la posicin deseada.
119

Diseño de Componentes Software - PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseño de Componentes Software - PDF

Uploaded by

Copyright:

Available Formats

ESCUELA TCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIN

Trabajo Fin de Carrera

DISEO DE COMPONENTES SOFTWARE DE TIEMPO REAL

Para acceder al Ttulo de

Pedro Javier Espeso Martnez Diciembre - 2002

tecnologa de programacin basada en componentes

I. TECNOLOGA DE PROGRAMACIN BASADA EN COMPONENTES

1. Component Based Software Engineering.

tecnologa de programacin basada en componentes

Tecn o lo g a O rien ta d a a O b jeto s

P ro g ram a ci n O rien ta d a a O b jeto s

Tecn o lo g ad e O b jeto s D istrib u id o s

S o lo o p e ra d en tro d el len g u aje d e p ro g ram ac in U n esp a cio d e d ireccio n es

In d epen d ien te d el le n g u aje M ltip le esp acio d irecc io n es N o In teg ra se rv icio s

1. Object Oriented. 2. En el sentido de usuario o consumidor.

tecnologa de programacin basada en componentes

E m pa qu eta m iento rob usto

C a ta log aci n esta nd ar

Servicio s de va lida cin

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

1. Object Management Group 2. Object Request Broker.

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

R e qu erim ien to s d e la a p lica ci n

Exp erien cia d isp onible C om p o nen tes

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

Exp erien cia d isp onible C om p on en tes

rea m odificada para tiem po real

1. Descrito en el apartado I.3.

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

Real-Time tiempo real

Modelo de los componentes lgicos

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

< < profile> > UML_M A S T

< < profile> > CB S E _M A S T

tecnologa de programacin basada en componentes

M AST_C om ponent_D escr

M AST_U sage_D escr

M AST_C onstituent_D eclaration

tecnologa de programacin basada en componentes

MAST_Component _Descr type 1..n

host MAST_Processing_Resource (from UML Profile) 0..1

host inst 0..n MAST_Component_Inst 0..1 place 1

MAST_Processing_Resource (from UML Profile) MAST_Descriptor_Place

MAST_Target_View_Placed MAST_Logical_View_Placed MAST_External_File + path : Identifier

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes

u s age s Lst 1..n

M A S T _ O p e ratio n (fro m U M L Pro file)

M A S T _ O p e ratio n_M o del (fro m U M L Pro file)

O verriden _ Pa ra m e ter m ode l

M A S T _ C om po site_ M ode l (fro m U M L Pro file) 1 1 m ode l

m ode l 1 M A S T _ Job _ Pa ra m e ter (fro m U M L Pro file)

M A S T _ Job _ M od el (fro m U M L Pro file)

tecnologa de programacin basada en componentes

tecnologa de programacin basada en componentes