P. 1
DISEÑO DE COMPONENTES SOFTWARE_.pdf

DISEÑO DE COMPONENTES SOFTWARE_.pdf

|Views: 7|Likes:
Published by oscar_lg_1

More info:

Published by: oscar_lg_1 on Jul 27, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/14/2014

pdf

text

original

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN

UNIVERSIDAD DE CANTABRIA

Trabajo Fin de Carrera

DISEÑO DE COMPONENTES SOFTWARE DE TIEMPO REAL

Para acceder al Título de

INGENIERO DE TELECOMUNICACIÓN

Pedro Javier Espeso Martínez Diciembre - 2002

índice

I. TECNOLOGÍA DE PROGRAMACIÓN 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. Metodología de diseño de aplicaciones basadas en componentes .................................... I.4. Componentes software de tiempo real .............................................................................. I.5. Entorno MAST de modelado , diseño y análisis de sistemas de tiempo real ................... I.6. Perfil CBSE_MAST ......................................................................................................... I.7. Objetivos del proyecto ...................................................................................................... II. ESPECIFICACIÓN Y DISEÑO FUNCIONAL DE COMPONENTES ....................................... II.1. Componentes e interfaces ................................................................................................ II.2. Especificación de una interfaz ......................................................................................... II.3. Especificación de componentes ....................................................................................... II.4. Proceso de automatización de la gestión 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 aplicación basada en componentes ............................... 44 III.2. Descripción de la plataforma WINDOWS NT .............................................................. 45 III.3. Modelo de tiempo real de la plataforma WINDOWS NT .............................................. 48 III.4. Estimación de los valores de los parámetros del modelo de la plataforma .................... 53 III.4.1. FP_Processor .................................................................................................... 53 III.4.2. Interference’s y Ticker ..................................................................................... 55 III.5. Código MAST-File del componente NT_Processor_mdl_1 ......................................... 60 III.6. Modelo de tiempo real del componente C_IG_DT3153 ................................................ 64 III.7. Código 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 visión artificial .............. 76 IV.2. Funcionalidad de la aplicación ...................................................................................... 80 IV.3. Arquitectura software del demostrador ...........................................................................80 IV.4. Modelo de los componentes lógicos de la aplicación .................................................... 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 aplicación ............................................ 96 IV.5.1. Configuración de la RT_Situation .................................................................. 97 IV.5.2. Declaración de las transacciones .................................................................... 100 IV.6. Análisis de tiempo real de la aplicación ........................................................................ 102 V. CONCLUSIONES .......................................................................................................................... 104 VI. REFERENCIAS ............................................................................................................................ 105 A. ESPECIFICACIÓN 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. DISEÑO Y CABLEADO DE LA TARJETA INTERMEDIA DE RELÉS ................................. 116

tecnología de programación basada en componentes

diciembre 2002

I. TECNOLOGÍA DE PROGRAMACIÓN BASADA EN COMPONENTES
I.1. Componentes software El objetivo de la tecnología de componentes software es construir aplicaciones complejas mediante ensamblado de módulos ( componentes ) que han sido previamente diseñados por otras personas a fin de ser reusados en múltiples aplicaciones [1]. La ingeniería de programación que sigue esta estrategia de diseño se la conoce por el acrónimo CBSE1 y es actualmente una de las más prometedoras para incrementar la calidad del software, abreviar los tiempos de acceso al mercado y gestionar el contínuo incremento de su complejidad. La arquitectura software de una aplicación basada en componentes consiste en uno o un número pequeño de componentes específicos de la aplicación ( que se diseñan específicamente para ella ), que hacen uso de otros muchos componentes prefabricados que se ensamblan entre sí para proporcionar los servicios que se necesitan en la aplicación [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 tecnología de componentes la interfaz constituye el elemento básico de interconectividad. Cada componente debe describir de forma completa las interfaces que ofrece, así como las interfaces que requiere para su operación. Y debe operar correctamente con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz. Características muy relevantes de la tecnología de programación basada en componentes son la modularidad, la reusabilidad y componibilidad y en todos ellos coincide con la tecnología orientada a objetos [3] de la que se puede considerar una evolución. Sin embargo, en la tecnología basada en componentes también se requiere robustez ya que los componentes han de

1. Component Based Software Engineering.

1

• Encapsulamiento: el cliente2 de un objeto software no tiene conocimiento de como son almacenados los valores en el interior del objeto . 1. • Los componentes puede tener su propio estado persistente ( en una base de datos . • Polimorfismo: las interfaces se describen por separado de la implementación ... En el sentido de usuario o consumidor. ni como se implementan las funciones. 2 . en el sistema de ficheros del disco . Tecn o lo g ía O rien ta d a a O b jeto s 1 9 6 7 . Object Oriented... 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 ión 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 tecnologías orientadas a objetos: • Componentes desarrollados con diferentes lenguajes de programación son compatibles y pueden ejecutarse dentro de una misma aplicación. De hecho. el desarrollo de software basado componentes (CBSE) es la evolución natural de la ingeniería software para mejorar la calidad.. 1 9 8 9 . Principios básicos compartidos por las tecnologías CBSE y OO1 son: • Integración de datos y funciones: un objeto software consiste en una serie de valores (estado) y las funciones que procesan esos datos. • Identidad: cada objeto software tiene una identidad única. 1 9 9 5 . . disminuir los tiempos de desarrollo y gestionar la creciente complejidad de los sistemas.tecnología de programación basada en componentes diciembre 2002 operar en entornos mucho mas heterogéneos y diversos. 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. ). 2. Esto permite una gran flexibilidad en el diseño de aplicaciones. de modo que un código que requiera una determinada interfaz puede utilizar cualquier componente / objeto que implemente dicha interfaz.

F á c il e nsa m bla je .¿ 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 .C o m p on ete s in te rn o s Inte rfaz . que les proporciona contexto local. Entornos normalizados descritos posteriormente en este mismo texto.M últip les fu e n te s. es el contenedor quien se encarga de mapear las estructuras de datos desde el espacio lógico hasta el espacio físico de memoria en la máquina sobre la que se está ejecutando. La funcionalidad de un componente software se ofrece a través de un conjunto de interfaces.F u n c io n am ie n to se g u ro . 3 . la información 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 situación de fallo. . C a ta log ació n esta nd ar . • Los componentes requieren mecanismos de empaquetamiento que deben ser más robustos que los de los objetos.O p c io ne s d e sustitu c ió n . .¿ D e q u é e stá h ec h o? Servicio s de va lida ción . • Los componentes integran servicios completos .¿ C o m o fu n cio na ? .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 especificación completa hacia el usuario.¿ D o n d e. se p u e de ac o p lar ? E m pa qu eta m iento rob usto .¿ Q u e o fre c e a l q u e lo usa ? .E stru c tu ra in te rn a . así como los mecanismos de acoplo y sus compatibilidades. La tecnología de componentes es habitual en otras ingenierías. 1. Por ello. lo que minimiza las interconexiones entre módulos. Tanto de los servicios que ofrece como de los servicios externos que requiere para operar correctamente. Mientras el componente aporta la simplemente la funcionalidad ( business logic ). c o m o . Cada interfaz es una unidad funcional independiente que representa dentro de un dominio de aplicación un conjunto de servicios en los que se puede basar una aplicación sin tener que hacer referencia al componente que los soporta. a q u é. 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 . • Múltiples interfaces en los que se especifican los diferentes modos de acoplo que admite.tecnología de programación basada en componentes diciembre 2002 • Las funciones de la interfaz no tiene que estar necesariamente implementadas utilizando técnicas orientadas a objeto. • Normalmente ( por ejemplo en COM+ y EJB1 ) las instancias de componentes se instalan en un contenedor . .

tecnología de programación basada en componentes diciembre 2002 • Un empaquetamiento robusto. Como reflexión final. de modo que el diseñador del componente se centra exclusivamente en el desarrollo de la funcionalidad principal (business logic).2. a diferencia del anterior el EJB implica la existencia de un entorno de ejecución conocido como “EJB Container”. mientras que un “Java Bean” requiere ser integrado con otros componentes para que sea funcional. Existen varios entornos de soporte de componente creados para uso interno de empresas.2. las peculiaridades de su implementación y la tecnología que lo soporta. Algunas ventajas de los EJB’s son: • División de trabajo: el “EJB Container” es el encargado de ofrecer los servicios . • Una catalogación estándar que simplifique su localización. De este modo mejoramos la calidad del sistema completo sin necesidad de rediseñarlo. de fácil manipulación y que garantice un funcionamiento fiable e independiente de otros componente que operen junto a él.1. permita su sustitución por otros equivalentes y que facilite el desarrollo de múltiples fuentes que garantice el soporte del producto. pero los más conocidos ( actualmente comercializados ) son: I. I. sino la posibilidad de sustituir un componente por otro que implemente las interfaces utilizadas en el sistema. Un “Java Bean” es un componente utilizado en un entorno Java que permite agrupar funcionalidades que pueden ser utilizadas por múltiples aplicaciones. 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. La interoperabilidad entre servicios y 4 . La arquitectura interna. • Debe ofrecer mecanismos de validación en el entorno de trabajo del usuario y capacidad de configuración y sintonización de acuerdo con las necesidades de la aplicación. Un “Enterprise Java Bean” también agrupa servicios funcionales utilizables por aplicaciones. podemos concluir que la ventaja principal del diseño basado en componentes no es la reutilización del software (que también). EJB (Enterprise Java Bean) Tecnología desarrollada por Sun Microsystems. Así. un EJB puede ser activado y usado con solo ser incluido en un “EJB Container”. sin embargo. sólo debe interesar al diseñador del componente y a los que sean responsables de su mantenimiento y evolución.

hay situaciones en las que no es práctico restringirse al uso de un único lenguaje. sistemas ERP3. (Java DataBase Conectivity) estándar que permite conexiones independientes entre bases de datos basadas en API’s SQL utilizando Java. • Conocimiento exhaustivo de Java: la tecnología EJB es uno de los principales componentes de J2EE y por esta razón depende fuertemente de otras de sus partes: RMI . • Diversos vendedores: existen diversos vendedores tanto de “EJB Containers” . JDBC5 . también presenta algunos inconvenientes: • Tiempo de desarrollo elevado: desarrollar un sistema con EJB’s es sumamente complejo . si bien para muchas empresas puede presentar una solución ideal . pero a la vez potente modelo para construir sistemas software a partir de la interacción de objetos (componentes). Los lenguajes de programación clásicos fueron diseñados para desarrollar aplicaciones secuenciales compuestas de módulos. • Procedimientos remotos: el diseño de los EJB gira alrededor de la tecnología RMI2. COM+ (Component Object Model) Microsoft Component Object Model [4]..2. El diseñador invoca las operaciones que necesite directamente. aunque ambos hayan sido desarrollados por distintas empresas proveedoras. bases de datos . 4. para otras puede resultar un solución sobrada debido a su elevado costo ( complejidad tiempo ). (Enterprise Resource Planning) describe una serie de actividades de gestión empresarial soportadas por aplicaciones de tecnología de información. (Java Naming and Directory Interface) conjunto de aplicaciones API que actúan como interfaz de múltiples servicios de directorio e identificación. (Remote Method Invocation) Invocación Remota de Procedimientos. La tecnología COM aborda la solución a este problema proporcionando un sencillo. y se puede ejecutar cualquier EJB en cualquier “EJB Container”. • Diversos clientes: un EJB puede interactuar con una gran gama de clientes: Servlets. . La compatibilidad está garantizada.tecnología de programación basada en componentes diciembre 2002 componentes se define en las especificaciones correspondientes que forman parte del estándar J2EE1. 5 . JNDI4 . Java 2 Platform Enterprise Edition. 3. 2. Por contra . incluso si el objeto destinatario está localizado en otro 1. todos ellos codificados con un solo lenguaje.. Sin embargo.2.. I. COM define un estándar binario ( esto implica que es independiente del lenguaje de programación ) para objetos y la intercomunicación entre ellos. como de EJB’s que resuelven algún tipo de lógica concreta. 5. los cuales son incluidos en un servidor de aplicaciones Java . . lo que permite la operación en sistemas distribuidos. Toda comunicación se realiza a través de operaciones que son proporcionadas dentro de interfaces.. applets .

. . Esta propiedad simplifica enormemente el desarrollo de sitemas distribuidos. Interface Definition Languaje. API4 o forma de escribir código. ATL1 dispone de un mecanismo basado en scripts para simplificar el registro de componentes. esto quiere decir que el desarrollador del componente escribe código asumiendo que un solo cliente accede al componente al tiempo. 1. 2. nos ofrece una importante simplificación en el proceso de desarrollo de aplicaciones informáticas. Visual Basic implementa un acceso sencillo a estructuras de datos a través de controles. simplifica el desarrollo de los componentes ya que genera de forma automática la implementación de diversas interfaces (IUnknown. la combinación de la tecnología COM junto con las técnicas de programación orientada a objeto. (Active Template Library) Biblioteca de plantilas C++ para el uso de componentes COM. contabilidad . En 1998 aparece la tecnología COM+ como la evolución natural de las tecnologías de componentes y sistemas distribuidos. MTS2 proporciona mecanismos que permiten la escritura de código escalable.) necesarias en COM para gestionar aspectos relativos al tiempo de vida del componente. De este modo. . Con COM+. En primer lugar. IDispatch. las interfaces se definen usando lenguajes de programación estándar: no se fuerza a aprender un nuevo lenguaje. Uno de los inconvenientes de COM era la complejidad de definir nuevas interfaces utilizando IDL3. La tecnología COM+ presenta varias ventajas respecto a su antecesora COM.tecnología de programación basada en componentes diciembre 2002 proceso o en otra máquina. Application Programming Interface. 6 .. y es MTS quién se encarga de automatizar el proceso cuando varios clientes acceden simultáneamente. 3. referencias . IConnectionPoint. Por ejemplo. Distintas herramientas han introducido particularidades propias para facilitar el desarrollo de aplicaciones basadas en COM. Microsoft Transaction Server. 4...

CORBA es la solución propuesta por el OMG para cubrir las necesidades de interoperabilidad entre los diversos productos hardware y software que nos ofrece el mercado hoy en día. de modo que los antiguos componentes COM pueden ser usados junto con componentes COM+. la 1. Object Request Broker. Con COM+.0. En la figura de la siguiente página se muestra la arquitectura CORBA . accesos seguros. . Por ejemplo. sistemas distribuidos . COM+ presenta muchas otras ventajas respecto a COM en aspectos relativos a la gestión interna del componente..0 para B. CORBA (Common Object Request Broker Architecture) Common Object Request Broker Architecture de OMG1[5]. I. Además. CORBA 1. una interface y una implementación (también conocida como Servant ). donde se define la interoperabilidad real entre ORB’s de distintos fabricantes.ORB. 1.2. En 1994 aparece CORBA 2..1 aparece en 1991 y en él se definen el IDL y la API que permiten la interacción de objetos en modo cliente/servidor utilizando una implementación específica de un ORB2. La aplicación B instala la versión 2. El mecanismo de registro permite reescribir la versión de una clase asociada a un paquete.3. liberación de memoria ( garbage collection ).tecnología de programación basada en componentes diciembre 2002 COM+ proporciona un modelo más simple y robusto para registrar e instalar componentes.0 para A y la 2.0 del componente C y funciona correctamente. Object Management Group 2. COM+ es compatible con COM. pero la aplicación A deja de hacerlo con la nueva versión de C. 7 .0 del componente C y también funciona correctamente. Esto resuelve una de las cuestiones más molestas de las aplicaciones basadas en componentes. La descripción de los distintos elementos que la conforman es la siguiente: • Object: entidad de programación de CORBA compuesta de una identidad. ambas versiones del componente se pueden usar simultáneamente. supongamos que la aplicación A utiliza la versión 1.

8 . trasladarle la petición y devolver los resultados al Client.IDL. Esto hace que las solicitudes de Client sean aparentemente simples procedimientos locales desde su punto de vista. El acceso a los servicios del Object remoto es transparente para el usurio Client. Ada. un ORB puede utilizar diferentes protocolos de comunicación. Java.. Smalltalk. Internamente. • Object Request Broker (ORB): mecanismo que proporciona una comunicación transparente entre el Client y el Object. . como por ejemplo IIOP1 o GIOP2 [6]. el ORB es el responsable de localizar la implementación del Object.).. Puede estar escrita en diversos lenguajes (C.tecnología de programación basada en componentes diciembre 2002 • Servant: implementación de un Object donde se definen las operaciones ofrecidas por una interfaz CORBA . Cuando el Client invoca una operación. C++. • Client: entidad de programación que invoca una operación sobre un Object.

El DSI permite a un ORB trasladar peticiones a un Object que no tiene conocimiento en tiempo de compilación del tipo de Object que va a implementar. En la figura se muestra un esquema a alto nivel de este proceso. Sólo envío. Tras una evaluación de algunos de los procesos de diseño basado en componentes [3][8][9][10]. 1. Operaciones de envío y recepción distintas. El Client que realiza la petición no tiene porque saber si el ORB utiliza IDL Skeletons o DSI. 2. A diferencia de los Stubs. Si comparamos este diagrama con los propuestos en la metodología RUP para la metodología orientada a objetos. Los conjuntos de actividades que intervienen en el proceso son: • Requerimientos: obtener una idea clara y concreta de los requerimientos que exige la aplicación. prueba y despliegue coinciden. se ha adoptado el proceso RUP4 propuesto por por Cheesman [8]. • Object Adapter: es el encargado de asociar los distintos Servants con el ORB. General Inter-ORB Protocol. • Dynamic Skeleton Interface (DSI): es el análogo al DII.tecnología de programación basada en componentes diciembre 2002 • IDL Stubs / Skeletons : son el punto de conexión entre el Client / Object (respectivamente) y el ORB. • Dynamic Invocation Interface (DII): interface que permite al cliente acceder directamente a los mecanismos subyacentes de peticiones que ofrece un ORB. Pueden ser especializados para ciertos estilos de Servants.3. Se genera un modelo conceptual general y un modelo de casos de uso. Las aplicaciones utilizan el DII para realizar peticiones dinámicamente sin necesidad de utilizar interfaces IDL (Stubs). el DII permite al Client efectuar llamadas no bloqueantes1 o unidireccionales2. Los bloques representan conjuntos de actividades que dan lugar a resultados tangibles. Rational Unified Process. e incrementa las posibilidades de optimizar la generación automática del código. diseño e implementación de objetos) se han reemplazado por otras que representan la especificación. El uso del compilador reduce el peligro de aparición de inconsistencias entre los Stubs del cliente y los Skeletons del servidor. 9 . como por ejemplo OODB3 Object Adapters para objetos persistentes o Library Object Adapters para objetos locales (no remotos). 2. 4. 3. Metodología de diseño de aplicaciones basadas en componentes El aspecto central del proceso de diseño de aplicaciones basadas en componentes es la gestión de la funcionalidad a través de las especificaciones de las interfaces. Internet Inter-ORB Protocol. mientras que difiere en que las fases centrales del proceso RUP (análisis. La transformación entre la definición del CORBA IDL y el lenguaje de programación utilizado es automática a través del compilador IDL. Object Oriented DataBases. 1. I. aprovisionamiento y ensamblado de componentes. las flechas gruesas representan su secuenciación y las flechas finas representan el flujo de elementos generados que transfieren información entre ellas. se comprueba que las actividades iniciales y finales de definición de requerimientos.

tecnología de programación basada en componentes

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

• Especificación: consta de tres etapas. Primero, la identificación de componentes donde se genera un conjunto inicial de interfaces y especificaciones de componentes conectados entre sí en una primera aproximación de la arquitectura. Segundo, la interacción entre componentes donde se decide como los componentes van a trabajar de modo coordinado para conseguir la funcionalidad deseada. Tercero, la especificación 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 través 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 secuenciación 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 básicos por lo que este proceso se ha tomado como base de nuestro trabajo son su carácter neutro respecto del proceso de diseño lo que facilita las extensiones y su formulación basada en UML (Unified Modeling Languaje) que lo hace compatible con las

10

tecnología de programación basada en componentes

diciembre 2002

0%
M odelo Conceptual M odelo de Casos de Uso Especificación 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 utilizábamos (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 físico, y los requerimientos temporales vienen impuestos por el entorno. Como consecuencia de esto, el correcto funcionamiento de estos sistemas depende no sólo de los resultados conseguidos a través de la computación de los datos, sino también de los instantes temporales en que se obtienen. Aunque la tecnología de componentes es ya una realidad en muchos campos, como multimedia, interfaces gráficas, etc., plantea problemas para su aplicación en otros dominios como es el caso de los sistemas de tiempo real. Sin embargo, la necesidad de la tecnología de componentes en sistemas de tiempo real está siendo manifestada por la industria de automatización, potencia y equipamiento eléctrico, aviación, automóvil, etc... Empresas líderes en estos campos como ABB han implantado la tecnología de componentes en sus productos, basándola en soluciones y especificaciones propias [12], lo cual le ha reportado ventajas en cuanto al mantenimiento y a la gestión de la evolución 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 diseño de los componentes es mucho más 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 diseñados 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 líneas generales podemos afirmar que el incremento de flexibilidad conlleva un decremento en la predicibilidad

11

tecnología de programación basada en componentes

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 diseño de componentes de tiempo real agregando a las especificaciones de los requerimientos de las aplicaciones y a las descripción de los componentes nuevas secciones que especifican y describen el comportamiento de tiempo real requerido y ofertado. Así, disponiendo de la descripción de cada una de los componentes que constituyen una aplicación, 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 aplicación completa, que es utilizado como base de operación de las herramientas de diseño que ayudan a la configuración óptima de los componentes y de las herramientas de análisis que permiten garantizar la planificabilidad de la aplicación, o en caso negativo mediante análisis de holguras localizar las causas que le impiden satisfacer los requerimientos temporales. La extensión 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 definición de los requerimientos, se ha realizado la extensión necesaria para que se puedan formular los requerimientos de tiempo real de la aplicación. Estos requerimientos se definen de forma independiente para cada modos de operación del sistema, y por cada uno de ellos, se formulan a través de las declaraciones de los conjuntos de transacciones que concurren en él. La declaración de cada transacción de tiempo real incluye la descripción de sus características de disparo, los conjuntos de actividades que conlleva su ejecución y los requerimientos de tiempo real que se imponen a lo largo de ella.

1. Descrito en el apartado I.3.

12

etc. I. se basa en la potencia de modelado y de análisis de que se dispone. Modeling and Analysis Suite for real-Time aplications. 1. se describe la cantidad procesado que requiere así como los recursos compartidos que puede requerir y que pueden dar lugar a suspensiones de su ejecución. sino en construir componentes que llevan asociado un modelo de comportamiento temporal. incluyendo planificación expulsoras y no expulsoras. Actualmente. sin necesidad de que tenga que conocer los detalles algorítmicos de los métodos. etc. y sistemas distribuidos basados sobre diferentes estrategias de planificación. servidores esporádicos. Entorno MAST de modelado . 2. El desarrollo de componentes estándar de tiempo real que puedan funcionar sobre distintas plataformas hardware es complicado debido a que los componentes tienen diferentes características temporales sobre diferentes plataformas. y su metodología ya ha sido aplicada en diferentes entornos [13][14][15].5. diseño y análisis de sistemas de tiempo real El entorno MAST1 está siendo desarrollado en la actualidad por el grupo CTR2 de la Universidad de Cantabria . Computadores y Tiempo Real. sistemas multiprocesadores. los procesos de análisis del modelo construido. • Por último.. de asignación óptima de prioridades o de cálculos de holguras. escrutinios periódicos. que permite modelar y analizar el comportamiento de tiempo real de las aplicaciones que hagan uso de ellos. y no en la propuesta de nuevas en estrategias de diseño. Su principal objetivo es simplificar la aplicación de técnicas estándar y bien conocidas de análisis de sistemas de tiempo real. Cada componente ha de ser adaptado y verificado de nuevo para cada plataforma hardware sobre la que se pretende instalar .tecnología de programación basada en componentes diciembre 2002 • En el bloque de actividades relativas a la especificación de los componentes la extensión incluye los procedimientos de descripción del comportamiento temporal del componente. proporcionando al diseñador un conjunto de herramientas para aplicar técnicas de análisis de planificabilidad. bien para la toma de decisión sobre la configuración óptima de los componentes o bien para verificar su planificabilidad. 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. y por cada actividad. Esto se realiza mediante la especificación de la secuencia de actividades que conlleva la ejecución de cada una de los procedimientos ofrecidos por sus interfaces. especialmente si el sistema es crítico (tiempo real estricto). Así mismo se incluyen. El método que se propone. manejadores de interrupciones. 13 . La idea básica de la extensión que se propone es que el diseño de sistemas de tiempo real basados en componentes no se fundamenta en una estrategia de diseño de componentes con unas prestaciones temporales preestablecidas e independientes de su uso ( lo cual no se sabe hacer salvo para situaciones muy laxas ). MAST cubre sistemas monoprocesadores. en el bloque de actividades de test se incluyen las actividades que generan el modelo de tiempo real de la aplicación 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 aplicación.

) y del propio sistema que se construye (partición.). despliegue.. . 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 información estructural y cuantitativa que se necesita para ser procesado por las herramientas de diseño y análisis de que se dispone. • Soporta implícitamente la distribución de componentes. a través de un modelo de tiempo real genérico. 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 parámetros definidos en el modelo. sincronización. son: • Se basa en el modelado independiente de la plataforma (procesadores. etc. de recursos compartidos. redes de comunicación. y en consecuencia da lugar a un modelo que tiene la misma estructura que el código.. etc. de otros componentes. el modo de transmisión. el timer del sistema. de forma que en función de que un componente se encuentre asignado o no al mismo procesador que otro del que requiere servicios. concurrencia. situaciones de tiempo real. • El modelo se construye con elementos que modelan los aspectos de tiempo real (temporización. los drivers de comunicación.) y la configuración (las conexiones entre los procesadores a través de las redes de comunicación ) 14 . se incorpora o no el modelo de la comunicación a la invocación del servicio. • Permite el modelado independiente de cada componente lógico de alto nivel. carga de trabajo (workload) y requerimientos temporales).). Modelo de tiempo real Real-Time tiempo real Situación de Modelo de la plataforma Modelo de los componentes lógicos Modelo de la Plataforma: Modela los recursos hardware/software que constituyen la plataforma en que ejecuta la aplicación y que es independiente de ella.. el planificador. etc..tecnología de programación basada en componentes diciembre 2002 Características relevantes de la metodología MAST que la hace especialmente idónea para modelar sistemas basados en componentes . de los componentes lógicos que se utilizan (requerimientos de procesado. drivers.) de los elementos lógicos (componentes). . las redes de comunicación: (la capacidad de transferencia. sistema operativo. los planificadores de mensajes. Modela los procesadores (la capacidad de procesado.

Actualmente se disponen de los siguientes perfiles: _ UML_MAST: Perfil para el diseño de modelo de aplicaciones de tiempo real basadas en metodologías orientadas a objetos y desarrolladas mediante herramientas UML[14].tecnología de programación basada en componentes diciembre 2002 Modelo de los componentes lógicos: Modela el comportamiento de tiempo real de los componentes software con los que se construye la aplicación. El análisis de un sistema de tiempo real consiste en la identificación de las situaciones de tiempo real que el sistema puede alcanzar y en el análisis independiente de cada una de ellas. Perfil CBSE_MAST CBSE_MAST es un perfil definido en el entorno MAST a fin de simplificar la formulación del modelo de tiempo real de un sistema y de una aplicación construida por agregación de componentes software tal como se considera en la metodología CBSE (Component Based Software Engineering). Los mecanismos de sincronización que requiere sus operaciones. y su uso directo en aplicaciones complejas en las que se necesitan cientos o miles de ellos para construir el modelo puede ser difícil de validar. _ ADA_MAST: Perfil para el diseño de modelos de aplicaciones de tiempo real y distribuidas desarrolladas utilizando ADA´95 con las extensiones establecidas en su apéndices D (Real-Time System) y E (Distributed Systems) [15]. Para evitar este problema se han definido diferentes perfiles de modelado que proporcionan componentes de mas alto nivel que facilitan la formulación del modelo de tiempo real dentro de ciertos entornos de programación específicos. _ CBSE_MAST: Perfil para el diseño de modelos de tiempo real de componentes software que facilitan el diseño del modelo de aplicaciones basadas en ellos [17]. Los estados internos relevantes a efecto de requerimientos de tiempo real. El perfil que ha sido utilizado en este proyecto es este último y será descrito con mayor detalle en la próxima sección.6. 15 . Modelo de las situaciones de tiempo real: Una "Situación de Tiempo Real" representa un modo de operación 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 análisis. El entorno MAST ofrece un conjunto de componentes primitivos que se utilizan en el modelado de un sistema [13]. 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. Los parámetros de planificación definidos en el código de sus operaciones. Las tareas o threads que crea para implementar sus operaciones. I. Estos componentes son simples y muy próximos a los componentes hardware y software que intervienen en la respuesta temporal de la aplicación. Los componentes lógicos de los que requiere servicios. El modelo de un componente software describe: • • • • • • La cantidad de procesado que requiere la ejecución de las operaciones.

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. De hecho CBSE_MAST es una extensión del perfil MAST_UML en el que se incluyen los elementos contenedores y de modularización que se necesitan para modelar eficientemente los diseños de sistemas desarrollados usando la metodología CBSE. Un MAST_Descriptor es un ente de modelado que constituye un descriptor genérico y posiblemente parametrizable que define la información que se necesita para describir el modelo de tiempo real de algún tipo de recurso o servicio del sistema. 16 . 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. El descriptor proporciona la información semántica y cuantitativa que es común a todos los entes que puedan resultar de su instanciación. < < 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 extensión del metamodelo UML_MAST_Metamodel y solo describe los nuevos aspectos establecidos en él respecto de este.tecnología de programación basada en componentes diciembre 2002 Con el perfil CBSE_MAST. El aspecto central de la metodología CBSE es la modularización de subsistemas para su reusabilidad y esto requiere que el método de modelado disponga de una mayor precisión de los conceptos de descriptor de un componente MAST como clase que define un patrón de modelado de un subsistema parametrizable disponible en la biblioteca de componentes y el de instancia de componente MAST. el modelo de tiempo real del sistema completo se podrá a su vez construir componiendo los modelos de tiempo real de los componentes utilizados. que denominamos MAST_RT_View. como objeto que representa el modelo de tiempo real de un componente concreto que participa en la ejecución de la aplicación que se analiza y que influye en el comportamiento temporal. CBSE_MAST es un perfil especializado del perfil UML_MAST y heredada de él todos los componentes de modelado de mediano y bajo nivel. que constituye un modelo de su comportamiento de tiempo real.

Un MAST_Component_Descr tiene una triple función: 1) Constituye un elemento contenedor que declara: _ Los atributos.n inst 0.n inst 1.. cada objeto del tipo MAST_Instance que se declare debe tener una clase del tipo MAST_Descriptor que describa su naturaleza y semántica.n inst 1. 2) Define un ámbito de visibilidad.n M AST_F orm ing_O bject valueLst 0. parámetros o símbolos que deben ser establecidos para declarar una instancia del modelo. 17 . 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.n 1. parámetros o referencias que tenga declarados.. y del que se deriva al establecer valores o instancias concretas a todos los atributos.... _ Declara los modelos de los usos del componente que son requeridos en la ejecución del sistema. símbolo o componente que se defina en un componente es visible y utilizables en la definición de cualquier componente incluido dentro de él (salvo que se oculte por una declaración mas próxima que haga uso del mismo identificador). _ 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...n type usageLst 0.n inst +objectLst 0.n inst 1.. por cada instancia suya que se declare en el modelo. para nombres de símbolos. Estos usos se describen individualmente como modelos de operaciones o bien agrupados por dominios de funcionalidad en interfaces.. De cada uno de ellos se especifica su tipo y optativamente el valor por defecto que se les asignará..n M AST_U sage_Inst 0...tecnología de programación basada en componentes 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. _ Declara los componentes (y sus tipos) que se instancian.n type param eterLst 0. M AST_Instance 0.n M AST_U sage_D escr 0..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. atributos y componentes.. En el modelo de un sistema...n type M AST_D escriptor M AST_C om ponent_Inst 0.n M AST_Value 0.n 1. Cualquier atributo.n type M AST_C om ponent_D escr usageLst 0.

la referencia de un MAST_Component_Inst que esté declarado en el modelo. atributo o símbolo tenía declarado valor por defecto. • Se tiene que asignar a cada elemento declarado por referencia en el correspondiente MAST_Component_Descr.n host MAST_Processing_Resource (from UML Profile) 0. La asignación de la referencia host sigue las siguientes reglas: _ Cuando una MAST_Component_Inst se declara explícitamente en un modelo siempre debe asignarse la referencia de la instancia MAST_Processing_Resource en la que se instale... Si en el correspondiente MAST_Component_Descr el parámetro.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. _ Cuando una MAST_Component_Inst se declara implícitamente como agregada dentro de otro.1 host inst 0. MAST_Component _Descr type 1... su referencia “host” tiene como valor por defecto el mismo objeto 18 .n MAST_Component_Inst 0. • Se le tiene que asignar a cada parámetro.tecnología de programación basada en componentes 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 información cuantitativa completa y final que define el modelo de tiempo real del ente hardware o software que modela. puede omitirse de la declaración del MAST_Component_Inst si el valor que se le asigna es el declarado como por defecto. • 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). atributo o símbolo un valor concreto que sea resoluble dentro del modelo.

al que se puede acceder a través del “path” que se declara. Las posibles ubicaciones son la Target_View o la Logical_View del propio componente. 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. • Debe asignarse al atributo “place” el valor que permite localizar la descripción del MAST_Component_Descr del que es instancia. Una MAST_Constituent_Decl es una referencia a algún ente (componente. • Referenced MAST_Component_Descr que declara un componente externo a él.tecnología de programación basada en componentes diciembre 2002 (del tipo MAST_Processing_Resource) referenciado en la referencia “host” del componente en el que se declara. En correspondencia con las MAST_Instance_Declaration que se definen en cada declaración de un componente. o en un fichero externo. Cuando un componente es del tipo MAST_Processing_Resource la referencia “host” se referencia a sí mismo. • 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. La instanciación del componente referenciado no es inducida por la instanciación del componente que la referencia. 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. • Included MAST_Atribute que representa un tipo de datos cuyos valores necesitan conocerse para construir el modelo del componente que se describe. que necesita conocerse. 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. en la instancia del mismo se puede tener que especificar: 19 . ya que su modelo es parte del modelo del componente que se describe.

0 . • 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 declaración referenced MAST_Component_Descr establecida en el componente que describe al componente que se instancia. Si un componente referenciado.a c et : N orm aliz ed _E x ec ution _ Tim e = 0.. se le pueden definir o no nuevos valores concretos cuando se realiza su instanciación.0 .. • 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.. si fuese preciso.b c et : N orm aliz e d_E x ecu tion _Tim e = 0.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. agregado o un atributo tiene definidos valores por defecto. Si se asumen todos los valores por defectos y con ellos el componente o uso queda completamente definidos.n 0.. Esta declaración solo se hará en la instancia si en el descriptor existián elementos abstractos que se necesitan concretar o se desean asignar valores diferentes a los establecidos como por defecto.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.tecnología de programación basada en componentes diciembre 2002 • Instanced MAST_Component_Inst que representa la instancia que crea como consecuencia de la declaración aggregated MAST_Component_Descr establecida 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.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) .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 ..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. M A S T _ U sa ge _D esc r u s age s Lst 1. no es necesario declarar el elemento instanciado en la instancia que se describe. al parámetro del uso.w ce t : N orm alized _E x ecution _Tim e = 0..0 lo ck Lst 0.

1 M A S T _ D a ta_ Typ e d e cla re d 0 . 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.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 . Una MAST_Inteface es un conjunto de tipos de usos asociados por pertenecer a un mismo dominio funcional. 21 . Aunque en el diagrama de clases se muestra la estructura del metamodelo que describe MAST_Operation..1 a ssig n ed 0 .tecnología de programación basada en componentes diciembre 2002 Un MAST_Usage_Descr describe el modelo de tiempo real de una forma de uso de un componente. Es meramente un elemento contenedor.1 M A S T _ C o m p o n e nt_ D e scr d e cla re d 0 . Un MAST_Operation es un tipo de uso simple que corresponde a la ejecución de un procedimiento de un sistema con unos datos y unas condiciones de ejecución específicas y es un concepto definido en el perfil MAST_UML. al modelo de la ejecución del código software que se realiza en respuesta a la invocación de un procedimiento lógico o al modelo de un uso de un recurso hardware que se realiza en background (por ejemplo atención al timer) o en respuesta de una interrupción o acceso a algún estado interno.0 M A S T _ S e rvice _In st Un MAST_Usage_Descr puede tener definidos un conjunto de parámetros MAST_Parameter que son utilizados en la descripción del modelo de la forma de uso. como consecuencia de que el procedimiento que se modela se ejecuta con diferentes datos o recursos. M A S T _ P a ram e te r o n e o f th em d e cla re d 0 . Un MAST_Usage_Descr se puede declarar individualmente en el componente como MAST_Operation o agrupado por su dominio de utilización en elementos contenedores del tipo MAST_Interface. todas ellas pertenecen al UML_MAST profile y están descritas en su documentación.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 . Estos parámetros permiten especificar el recurso o forma de uso concreto que se utiliza en algún punto del modelo de una operación. y el conjunto de clases que se derivan de ellas.. por ejemplo. sin embargo parámetros u operaciones con el mismo nombre pero incluidos en diferentes interfaces son diferentes.. • Otros MAST_Usage_Descr a los que son referenciados para describir el modelo. Corresponde. que permite organizar los servicios y sobre todo proporcionar un ámbito específico de nombres y de parámetros.... Una MAST_Interface puede incluir bien un conjunto de MAST_Operations o de otras MAST_Interfaces más simples. Los nombres de parámetros y de operaciones dentro de una interfaces tienen que ser únicos.

A. _ Interface I_Adq_Configuration: Conjunto de operaciones y constantes de gestión y configuración de la tarjeta de adquisición.tecnología de programación basada en componentes diciembre 2002 • MAST_Data_Type que referenecia datos de tipo escalar o estructurado. y se han desarrollado tres componentes que las implementan. 1. he participado en dos proyectos de investigación1 desarrollados por la empresa Equipos Nucleares en colaboración con el grupo Computadores y Tiempo Real (CTR). 19992000. “Sistema robótico teleoperado (SRT)”. la asignación no necesita ser explicitada. En ellos.ENDESA y REN. La declaración de las MAST_Interface_Inst está implícita en la declaración del MAST_Component_Inst en que están declaradas (y por tanto no existen declaraciones explicitas de las MAST_Interfaces_inst). I. “Entorno para la programación de tiempo real de controladores industriales y aplicación a la automatización del proceso de fabricación de generadores de vapor en cámara limpia”. un MAST_Value que es un valor concreto (o instance) con el que se define completamente el modelo de la interfaz. Financiado por Equipos Nucleares S. Si el valor MAST_Value que se debe asignar al Mast_Parameter es el establecido por defecto en el MAST_Interface_Descr. En este proyecto fin de carrera hay dos objetivos principales que vertebran el desarrollo del proyecto y la exposición del mismo en la memoria: 1) Diseño e implementación de tres componentes de tiempo real útiles en diseño de controladores industriales: Se han desarrollado un conjunto de interfaces correspondientes a tres dominios de implementación. Objetivos del proyecto A lo largo de los tres últimos años. En la declaración de un MAST_Parameter se pueden definir valores por defecto. driver de control de tarjetas de I/O analógicas y digitales ) al entorno en que se desarrollaban los proyectos. acceso remoto a bases de datos Informix. En consecuencia. 22 . cuando se declara una MAST_Component_Inst hay que asignar a todos los MAST_Parameter de las MAST_interfaces declaradas en él. _ InterfaceI_Analog_Adq: Conjunto de operaciones de adquisición y generación de tensiones analógicas a través de convertidores A/D y D/A. he tenido que llevar a cabo la adaptación de diferentes librerías comerciales ( relativas a visión artificial (digitalización de imágenes y procesado digital de imágenes). lo cual constituye su instancia. • Dominio Adquisición de señales analógicas y digitales: Se han diseñado un conjunto de interfaces destinadas a la adquisición de señales analógicas y digitales a través de tarjetas de IO de propósito general. relativos a la aplicación de la visión artificial a la automatización de los procesos industriales y al desarrollo de controladores de sistemas robotizados. que eran plataformas Windows NT y aplicaciones de tiempo real desarrolladas con tecnología Ada. 1999-2001. que son utilizados para definir el modelo de la forma de uso. Fondos FEDER.7.

16 bits digitales de salida y 4 bits digitales de entrada / salida.tecnología de programación basada en componentes diciembre 2002 _ InterfaceI_Adq_Analog_Active: Interfaz activa que añade a la interfaz básica I_Analog_Adq un conjunto de operaciones basadas en tareas de background que temporizan la adquisición o establecimiento de tensiones analógicas. 16 canales de entrada analógicos multiplexados de 12 bits de resolución. las procesan y gestionan los resultados. _ InterfaceI_Digital_Adq: Conjunto de operaciones de lectura y escritura en líneas y grupos de líneas de entrada y de salida digitales. convertirlas en otros formatos y activar o inhibir la transferencia continua de imágenes hacia ventanas de la aplicación _ Componente: C_IG_DT3153: Contiene los recursos software de gestión de la tarjeta DT3153 de Data Translation que es una tarjeta digitalizadora de imágenes de 23 . _ Componente C_PCI9111: Componente basado en la tarjeta de adquisición PCI9111DG de la casa ADLINK. Este componente implementa las 5 interfaces antes citadas. procesan la información y gestionan los resultados. _ InterfaceI_Active_Digital_Adq: Interfaz activa que añade a la interfaz básica I_Digital_Adq un conjunto de operaciones basadas en tareas de background que leen y escriben las líneas digitales. < < 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: Adquisición y digitalización de imágenes de vídeo: Conjuntos de recursos para la configuración de la tarjeta de digitalización de imágenes de vídeo. capturar y digitalizar imágenes individuales. _ Interface:I_Image_Grabber: Ofrece la capacidad de controlar y configurar la tarjeta. y transferencia de imágenes en vivo a ventanas de la workstation. 16 bits digitales de entrada. con 1 canal de salida analógico de 12 bits de resolución. captura de imágenes.

localizar y caracterizar patrones presentes en la imagen. _ InterfaceI_Img_Transforming: Ofrece el conjunto de operaciones de transformaciones de imágenes de un modo global. lineales. Su funcionalidad corresponde a las librerias IPL [18] y Open_CV [19] de código abierto 24 . _ Component C_Ada_Vision: Este componente ofrece los recursos relativos a gestión. _ InterfaceI_Img_Logic_Processing: Ofrece el conjunto de operaciones de procesado lógico (bit a bit) de imágenes de grises. _ InterfaceI_Img_Statistic: Ofrece el conjunto de operaciones de cálculo de valores estadísticos sobre una imagen de grises. _ InterfaceImg_Processing: Ofrece el conjunto de operaciones que permiten el procesado de las imágenes por parte del usuario. así como los procedimientos de almacenamiento y recuperación de la misma. procesado de imágenes y análisis de imágenes. caracterización estadística etc. <<component>> C_IG _DT3153 I_Image_Grabber • Dominio Procesado digital de imágenes. Se ofrecen transformaciones geométricas. Permite identificar. Para este dominio se han definido 8 interfaces que ofrecen cada una de ellas un tipo de servicios específico: _ InterfaceI_Img_Managing: Ofrece el conjunto básico de operaciones de gestión y almacenamiento de imágenes. Ofrece procedimientos de acceso a píxel y de transformación de la imágenes en función de la posición de los pixels. Es una interfaz que ofrece los recursos básicos sobre las estructuras de datos asociadas a una imagen.tecnología de programación basada en componentes diciembre 2002 vídeo en color con capacidad de transferencia de imágenes a memoria de la workstation. Es utilizada por las restantes interfaces de visión. análisis. _ InterfaceI_Img_Draw: Ofrece de operaciones que permite dibujar e insertar distintos elementos en una imagen. Este componente implementa la interface I_Image_Grabber . _ InterfaceI_Img_Analysis: Ofrece el conjunto de operaciones que realizan análisis complejos sobre imágenes para obtener resultados concretos. procesado digital. morfológicas y filtrados. _ InterfaceI_Img_Arith_Processing: Ofrece el conjunto de operaciones de procesado aritmético de imágenes de grises. Corresponde a diferentes recursos para la gestión. de imagenes almacenadas en el ordenador.

y sobre todo permite obtener experiencia sobre el ciclo de desarrollo de aplicaciones basadas en componentes. tanto en lo relativo a su especificación. y diferentes tarjetas de IO (Grabber DT 3153 y IO card PCI-9111DG). lo cual representa una información muy valiosa para el desarrollo de futuras herramientas de generación automática de código a partir de los modelos UML. y cuya importancia transciende mas allá del propio proyecto. 25 . a través de la detección de la posición de los trenes mediante visión artificial. • Se han analizado los procesos de transformación de los códigos ADA que representan los modelos funcionales de los componentes en las diferentes fases del desarrollo de la aplicación. • Se ha desarrollado modelos de tiempo real de una plataforma contruida por una workstation operando bajo sistema operativo Windows NT Server 4. • Se proponen unos formatos para codificar interfaces y componentes implementados como paquetes Ada’95. 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 análisis de planificabilidad de peor caso: Se ha desarrollado como ejemplo una aplicación 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. Información que será la base. El proyecto fin de carrera ha tenido otros objetivos indirectos. que se enmarcan dentro de las líneas de investigación que desarrolla el Grupo de Computadores y Tiempo Real. 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.tecnología de programación basada en componentes diciembre 2002 proporcionadas por Intel y que han sido diseñadas específicamente para que sean muy eficientes sobre la arquitectura de los procesadores con tecnología MMX. o al menos una experiencia relevante a fin de desarrollar en el futuro herramientas de generación automática del modelo de tiempo real MAST de las aplicaciones. Esta aplicación desarrollada tiene la finalidad de validar los componentes. a su interconectividad y a sus modelos de tiempo real.0. • Se han analizado los procesos de construcción de los modelos de tiempo real de una aplicación a partir de su MAST_RT_View y del los modelos de tiempo real de los componentes que se utilizan.

Es un objeto con una única identidad y con su propia instancia de datos y estado.especificación y diseño funcional de componentes diciembre 2002 II. cada uno con su propia identificación.n Especificación de componentes 1 n realización Implementación de componente 1 n instalación Componente instalado 1 n instancia Componente objeto Interface La especificación de un componente es un descriptor del comportamiento de un conjunto de objetos componentes y define una unidad de implementación..1. Un componente instalado o desplegado es una copia de una implementción de un componente que está registrado en algún entorno de ejecución. 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. se muestran diferentes formas en las que se puede tratar un componente. ESPECIFICACIÓN Y DISEÑO FUNCIONAL DE COMPONENTES II. Es un concepto de ejecución. n interfaceSoportada 1. Un componente instalado puede tener muchos (o solo un) componentes objetos instanciados. Un componente objeto es una instancia ejecutable de un componente instalado. 26 . En la siguiente figura. Una implementación de un componente es una realización de una especificación de componente que puede ser utilizado en el desarrollo de una aplicación. 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. Esto capacita al entorno de ejecución para identificarlo y usarlo cuando se genere una instancia del componente o se invoque alguna de sus operaciones. El comportamiento de la especificación de un componente se describe mediante un conjunto de interfaces.

Define al componente como una unidad de realización. Cuando una aplicación usa una interface. • Componente objeto: es una librería instanciada en una aplicación Ada del paquete Ada que describe al componente. Es importante tener en consideración 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 especificación del componente y la aplicación cliente que lo utiliza. probador y ensamblador del componente. se utilizan los siguientes conceptos: • Descripción de componente o de interface: son modelos independientes UML que describen su funcionalidad. que se formula principalmente pensando en el realizador.especificación y diseño funcional de componentes diciembre 2002 En este proyecto. y define los servicios que el 27 . Debe establecer que entorno de implementación y que otros componentes o interfaces deben estar implementados en él para que el componente pueda ofrecer su funcionalidad. y la instalación de un componente debe ser independiente de que aplicación va a utilizarla. su funcionalidad no puede quedar afectada por la naturaleza del componente que implementa la interface que se usa. que implementa a su vez la descripción de un componente y las de las interfaces que ofrece el componente. Aunque estos dos tipos de contratos deben estar detalladamente explicitados en la descripción de un componente. las operaciones y el modelo de información del servicio que ofrece. Esto se realiza a través de las interfaces que definen de por sí y con independencia del componente que las implementa y ofrece. • Implementación de un componente: es un un paquete Ada compilable. Desde este punto de vista. la especificación del componente y la especificación de las interfaces son conceptos independientes que juegan un papel central en la tecnología CBSE. • Contrato de instalación: Es el contrato que se establece entre la implementación del componente y el entorno en el que puede operar. La aplicación que usa un componente no debe depender. ni necesita conocer el contrato de realización. Por el contrario. En el modelo de un componente aparecen agregados los modelos de las interfaces que implementa. deben ser independientes entre si. La especificación del componente es básicamente el contrato de instalación. define su encapsulación y determina su granularidad y la posibilidad de reemplazabilidad que tiene. la especificación de las interfaz representa el contrato con el componente cliente.

Especificación de Interfaz Una lista de operaciones Especificación de Componente Una lista de interfaces soportadas Define el modelo abstracto de Define el modelo de información que información lógica que se necesita establece las relaciones entre las para usarla diferentes interfaces. información Describe solo los efectos locales al Especifica como se implementan las modelo de información del servicio operaciones que ofrece en función de que oferta. asociaciones. parámetros. instalador. probador y ensamblador.especificación y diseño funcional de componentes diciembre 2002 componente usuario puede esperar del componente que la implementa. definidos unos en función de otros hasta proporcionar un modelo completo y cerrado. tipos. Representa el contrato con el cliente. esto es. se resumen las diferencias entre las descripción de un componente y de una interfaz. etc). II. las operaciones que requiere de las interfaces del que el componente depende. Especificación de una interfaz La interfaz representa el conjunto de operaciones y modelo de información 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. etc. La especificación de una interfaz contiene: • El identificador de la declaración de la interface al que se hace referencia en su instanciación dentro de un componente. precondiciones y postcondiciones. Esto supone definir la especificación completa de cada operación (identificador. En la siguiente tabla. 28 . • El modelo de información. los atributos. • Conjunto de invariantes y restricciones del modelo de información de la interfaz. Especifica como las operaciones Define la implementación y la unidad afecta o dependen del modelo de de ejecución. Representa el contrato con el realizador. • Otras interfaces con las que tiene establecidas relaciones de dependencia o de herencia.2. • La descripción de las operaciones a través de los que el usuario puede acceder al servicio proporcionado por la interfaz. En las siguientes secciones de este capítulo se describen los recursos y los formatos que se proponen para formular las especificaciones y las implementaciones de los componentes y de las interfaces.

y en su caso valor de retorno. • Modelo de informacion de la interfaz: Corresponde con atributos. en las que solo se describe su identificador y el path donde se encuentra su declaración si esta está en un fichero diferente al del modelo. como una clase con estereotipo <<interface_descr>> y su modelo de información se describe dentro de un paquete que contiene todos los elementos UML que se utilizan para su descripción. 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. En la descripción 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. En UML la representamos. pero mas frecuentemente se encuentra descrita en un fichero (modelo) independiente que describe solo a la interfaz o también a otras interfaces relacionadas. y que se encuentra situado dentro del paquete Functional_View . que a su vez esta definido en Logical View del modelo. El código de 29 . mediante lenguaje Ada. en formato de texto se incluyen el conjunto de pre-condiciones (condiciones relativas a la interfaz que deben cumplirse antes de ser invocada una operación 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 operación.aci”): que contiene la declaración de la parte pública del paquete Ada en que se describe la interfaz. que se incluyen en el paquete de descripción de la interfaz y que proporciona toda la información necesaria para que el usuario pueda utilizar la interfaz de forma autocontenida. • Otras interfaces con la que tiene establecida relaciones de dependencia: Se formulan como clases que representan instancias de interfaces. • Declaración de las operaciones de la interfaz: Se formulan como operaciones declaradas en la clase de descripción de la interfaz. su conjunto de parámetros. si se satisfacian las pre-condiciones). • Acceso al fichero (de extensión “.especificación y diseño funcional de componentes diciembre 2002 Una interfaz se describe con independencia de cualquier componente. esto es. Cada operación se declara con su descripción completa UML. • Declaración de invariantes y restricciones en la interfaz: Se formulan mediante texto asociado a la clase que declara la interfaz. etc. con su identificador. El modelo de una interfaz es siempre un paquete con el estereotipo <<interface_model>> que tiene el nombre de la interfaz. Así mismo. diagramas de estado. clases asociadas (por agregación o por dependencia).

_ Pueden faltar constantes y tipos propios del dominio que deben ser establecidos también en la implementación. es necesario recurrir tambien a otras vista. por lo que para completar el modelo. <<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. x : int. f : Fram e.. hwnd : HWND.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 imágenes de vídeo. data : in out PixelData) Draw_Im age(c : Video_Card. bm p : s tring. y : Natural) Stop_Video(c : Video_Card) Overlays_ON(c : Video_Card. sin embargo no podrá compilar con ella su aplicación. algunas de las clases que forman parte del modelo de información de la interfaz no están explícitas. configurar 30 . En el siguiente diagrama de clases. complementarias y a la documentación y diagramas de estado y de actividad asociadas con cada clase. <<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. col : PixelRGB. se muestra una vista de la declaración de la interfaz Image_Grabber. ch : Channels ) .especificación y diseño funcional de componentes diciembre 2002 este fichero contiene la información necesaria para que el programador de la aplicación pueda programar las sentencias de acceso a los servicios de la interface. En esta vista. r : Ratio) : Video_Card Clos e_Card(c : Video_Card) Start_Video(c : Video_Card. Es independiente de cualquier tarjeta hardware y ofrece servicios para inicializar y liberar los recursos que en cada caso se requiera. hwnd : HWND) Set_Channel(c : Video_Card. ya que: _ Falta la parte privada y la declaración de los tipos privados. y : int. trans : boolean) Overlays_OFF(c : Video_Card) Acquire(c : Video_Card) Snap(c : Video_Card) Read(c : Video_Card. x : Natural.. que serán función de su implementación dentro de un componente.

Parte privada: no implementada.Declaration of exported constant. En la declaración de la interfaz Image_Grabber. Operaciones. se indica que esta interfaz tiene una dependencia de la interfaz Environment. types and procedures = --========================================================================= ---------------------------------------------------------------------------.Constantes y tipos ---------------------------------------------------------------------------. de la que importa dos tipos de excepciones de mayor ámbito y el tipo relativo a los manejadores de ventanas Win32.especificación y diseño funcional de componentes diciembre 2002 el proceso de digitalización de imágenes. se describe constantes y atributos declarados en la clase y los tipos de datos y excepciones declarados en las clases asociadas. -. transferir imágenes en vivo a una ventana de la aplicación. Excepciones locales.aci” que formula la declaración de la interface desde un punto de vista Ada. Se obtiene a partir de la especificación abstracta UML y consiste en un fichero no compilable de declaraciones con la siguiente estructura: • • • • • • Dependencias externas: interfaces necesarias de “Componentes externos”. --========================================================================= package Image_Grabber is --========================================================================= -.Documentation 31 . --************************************************************************* --* * --* Declaration of Abstract MAST-Component Interface (ACI) * --* ACI Name: Image_Grabber * --* * --* * --* Documentation: * --* Conjunto de operaciones de gestión y manejo de la tarjeta de * --* adquisición de imágenes de vídeo.Documentation -Número máximo de tarjetas que pueden estar registradas -simultánemente en un computador. se muestra el fichero tipo “. Constantes y subtipos: las constantes no inicializadas y los subtipos no definidos. MAX_CARD: constant Natural. transferir una imagen digitalizada a memoria.External dependency with Environment. etc. En el siguiente código. Variables de estado: no inicializadas. El modelo de información necesario para hacer uso de esta interfaz. * --* * --************************************************************************* --========================================================================= -.

Contrast_Values: constant Param_Value. type Param.Documentation: -Pixel RGB en formato: R-G-B. ---------------------------------------------------------------------------.Documentation -Valor del brillo.Documentation: -Valores maximo . -. -. -. V_Sat_Values: constant Param_Value. RESOLUTION_X: constant Natural. U_Sat_Values: constant Param_Value. minimo y nominal (por defecto) -de un parametro. RESOLUTION_Y: constant Natural.Documentation -Número de canales de entrada de video de la tarjeta. type Channels. type PixelRGB.especificación y diseño funcional de componentes diciembre 2002 -Número máximo (pixels) de columnas de las imagenes adquiridas. -. type PixelData. -. -. Brigthness_Values: constant Param_Value. type Param_Value. N_CHANNELS: constant Natural. type Ratio.Documentation: -Identificador de la tarjeta de adquisición.Documentation: -Escalado del tamaño de las imagenes que se -capturaran en la tarjeta. -. -.Documentation -Número máximo (pixels) de columnas de las imagenes adquiridas.Documentation: -Píxels almacenados en las posiciones x. -. type Video_Card is private.Documentation: -Parametros de la imagen. -.Documentation -Valor de la saturacion U.y. -.Documentation: -Canales de entrada de video de la tarjeta. -.Documentation -Valor de la saturacion V. -.Variables de estado ---------------------------------------------------------------------------.Documentation 32 .Documentation -Valor del contraste.

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 . y:natural). -.Documentation: -Inicializa la tarjeta y reserva la memoria necesaria para dos -buffersde almacenamiento: uno para imágenes del vídeo en vivo y otro -para capturade imágenes estáticas. -. -. -Eleva la excepcion End_Error si se produce un error. 33 .Documentation: -Comienza a mostrar el vídeo en vivo en la ventana hwnd. -. Hue_Values: constant Param_Value.Documentation: -Libera los recursos asociados a la tarjeta. ---------------------------------------------------------------------------.especificación y diseño funcional de componentes diciembre 2002 -Valor de la intensidad. -Se eleva la excepción Passthru_Error si se produce un error procedure Star_Video(C: in out Video_Card. -Se eleva la excepción Passthru_Error si se produce un error procedure Overlays_ON(C: in out Video_Card. x:in integer. x:natural. hwnd:I_Environment.HWND. bmp:in string.Documentation: -Se detiene el video en vivo.Documentation: -Captura una imagen y la almacena en el buffer de imagen -estática con la resolución máxima permitida. -Se eleva la excepción Passthru_Error si se produce un error procedure Stop_Video(C: in out Video_Card). y:in integer. -La resolución máxima es RESOLUTION_X por RESOLUTION_Y -pixels. -La imagen aparece escalada con dimensiones x por y pixels. la imagen superpuesta es toda -ella translucida. -. procedure Close_Card(C: in out Video_Card). trans:in boolean).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.Documentation: -Finaliza el overlay -Es necesario invocar la funcion con el video en vivo ya detenido -Se eleva la excepción Passthru_Error si se produce un error procedure Overlays_OFF(C: in out Video_Card). -.Operaciones ---------------------------------------------------------------------------. col:in PixelRGB. -Eleva la excepcion Start_Error si se produce un error. function Open_Card(n:Natural.r:Ratio) return Video_Card. También se inicializan los -valores del estado de losparametros de vídeo para cada uno de los -canales (que pueden ser de distintovalor en un momento dado).

Draw_Error:exception.Documentation: -Selecciona el canal de entrada de vídeo. value:integer. -Se eleva la excepción Config_Error si se produce un error. p:Param.Declaration of exported exceptions = --========================================================================= Start_Error:exception. procedure Snap(C: in out Video_Card). -. procedure Read(C: in out Video_Card.HWND).Documentation: -Transfiere a la memoria principal la imagen capturada -anteriormente con Acquire o Snap. -Transfiere el rectángulo determinado por los índices de data. -Se eleva la excepción Draw_Error si se produce un error. ch:Channels). ch:Channels)return integer. -. --========================================================================= -. --========================================================================= 34 . ch:Channels). -.Documentation: -Muestra en una ventana la imagen capturada en el buffer de -la imagen estática. -. -. -Se eleva la excepción Config_Error si se produce un error. -Se eleva la interrupción Config_Error si se produce un error.especificación y diseño funcional de componentes diciembre 2002 -Se requiere que cuando se invoque no esté el video en vivo. -Se eleva la excepción Read_Error si se produce un error. procedure Set_Parameter(C: in out Video_Card. p:Param. Es necesario haber capturado previamente -una imagen con Acquire o Snap. -Se eleva la excepcion Acquisition_Error si se produce un error procedure Acquire(C: in out Video_Card). -. function Get_Parameter(C:Video_Card.Documentation: -Devuelve el valor actual de un parámetro de las imágenes -capturadas o mostradas en vídeo en vivo en el futuro. -Se requiere que cuando se invoque el vídeo esté en vivo. End_Error:exception. Acquisition_Error:exception. Read_Error:exception.Documentation: -Modifica un parámetro de las imágenes capturadas o mostradas -en vídeo en vivo en el futuro.Documentation: -Copia en el buffer de la imagen estática la última imagen -almacenada en el buffer de vídeo en vivo. Passthru_Error:exception. procedure Draw_Image(C: in out Video_Card. Config_Error:exception. data:in out PixelData). -Se eleva la exception Acquisition_Error si se produce un error. procedure Set_Channel(C: in out Video_Card. hwnd:I_Environment.

3. y que se encuentra situado dentro del paquete Functional_View . o también puede estar varios de ellos agrupados y definidos conjuntamente dentro de un mismo modelo. que a su vez esta definido en Logical View del modelo.mdl).Private interface declaration = --========================================================================= private end Image_Grabber. Especificación de componentes La especificación de un componente está directamente relacionada con la descripción de los dos contratos que definen su arquitectura. Un componente puede estar declarado independientemente en un modelo(fichero con extensión . --========================================================================= II. que incluye: 35 .especificación y diseño funcional de componentes diciembre 2002 -. Básicamente debe describir el contrato de uso a través de la declaración de las interfaces que “ofrece” y debe describir el contrato de realización a través de la declaración 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 información que describe un componente se incluye en un paquete con estereotipo <<component_model>> que tiene el nombre de la interfaz. 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>>.

En la descripción de cada interface se debe establecer el atributo “place” que describe el modelo en el que se encuentra el descriptor. deben ser instancias de interfaz declaradas en componentes concretos. resulta de instanciar la interface abstracta <<interface_descr>>Image_Grabber. bien como texto agregado al componente o a las asociaciones de dependencia.mdl) La interface concreta <<interface>>I_Image_Grabber que ofrece. mdl ) <<implements>> <<component> > C_IG_DT3153 <<offers>> I_Image_Grabber <<uses>> <<offers>> I_Environment <<component> > C_Sauce place : File(path = c:\Repository\Sauce. Estas interfaces. toma como valor el path del fichero en que se encuentra. Estas interfaces son instancias de interfaces descritas en el propio modelo o en modelos independientes. En la declaración de una interface ofrecida. • Conjunto de interfaces usadas: Se declaran como instancias de clases asociadas por dependencia. Como se muestra en el siguiente 36 . 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. • Conjunto de interfaces ofrecidas: Se declaran como atributos o como clases agregadas de con estereotipo <<interface>>. también se explicitan valores iniciales de atributos y tipos que quedaron indefinidos en la declaración de la interface.especificación y diseño funcional de componentes diciembre 2002 • Nombre del tipo de componente: coincide con el identificador de la clase <<component>>. • Restricciones de acceso a componentes: Restricciones de especificación que limitan las formas de uso con que las diferentes implementaciones pueden acceder a los componentes que se usan para implementar su funcionalidad. • Restricciones entre interfaces: Restricciones de especificación que se establecen entre las diferentes interfaces del componente como consecuencia de que son todas ellas ofrecidas conjuntamente por el mismo componente. Estas restricciones se formulan. este toma. por defecto. En el diagrama de clases siguiente se muestra la descripción del componente C_IG_DT_3153. <<interface_ref>> Image_Grabber p lace : File(path = c: \Reposit ory\ Im age_G rabb er.

180 U_Sat_Value s : Param_Value = 0.128 Open_Card(n : Natural. Frame.511.256 V_Sat_Values : Param_Value = 0. • Se ha establecido los valores de la constantes MAX_CARD.254 Hue_Val ues : Param _Value = 0. <<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 .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. --***************************************************************************** --* * --* Declaration of a MAST-Componet (CMP) * --* CMP Name: C_IG_DT3153 * --* * --* * --* Documentation: * --* Componente de gestión de la tarjeta de adquisición de video DT3153. 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. Param. Contrast_Values.mdl. RESOLUTION_Y y N_CHANNELS.51 1. Ratio. PixelData.Natural range<>)of PixelRGB <<type>> Channels C : Natural range 0.especificación y diseño funcional de componentes diciembre 2002 diagrama de clases UML que describe la instancia. Param_Value. * 37 . RESOLUTION_X.. Channels.511.mdl) En el suguiente listado se muestra el código Ada95 que corresponde a la descripción UML del componente C_IG_DT3153 establecido.163 Contrast_Values : Param_Value = 0.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<>. • Se ha concretado el valor por defecto del parámetro r de la operación Open_Card. • Se han definido de forma concreta de los tipos: PixelRGB. • Se han establecido valores iniciales de las variables: Brigthness_Values.2) of I_Environment. U_Sat_Values y Hue_Values.255. V_Sat_Values..255. r : Ratio = R_1) : Video_Card <<type>> PixelRGB P : array(0.

types and procedures = --========================================================================= ---------------------------------------------------------------------------. RESOLUTION_Y: constant Natural:= 576.Declaration of exported interfaces * --***************************************************************************** --************************************************************************* --* * --* Declaration of Concrete MAST-Componet Interface (CCI) * --* CCI Name: I_Image_Grabber * --* * --* * --* Documentation: * --* Conjunto de operaciones de gestión y manejo de la tarjeta de * --* adquisición de imágenes de vídeo. MAX_CARD: constant Natural:= 1.External dependency --with I_Environment.Documentation -Número de canales de entrada de video de la tarjeta.Documentation -Número máximo de tarjetas que pueden estar registradas -simultánemente en un computador.Documentation: -Identificador de la tarjeta de adquisición. --***************************************************************************** package C_IG_DT3153 is --***************************************************************************** -. N_CHANNELS: constant Natural:= 3. -. -.External dependency with C_Sauce. type Video_Card is private. * --* * --************************************************************************* --========================================================================= -.especificación y diseño funcional de componentes diciembre 2002 --* * --* Implementa la Interface: * --* I_Image_Grabber * --* * --***************************************************************************** --***************************************************************************** -. -.Documentation: -Escalado del tamaño de las imagenes que se 38 . -.Documentation -Número máximo (pixels) de columnas de las imagenes adquiridas. RESOLUTION_X: constant Natural:= 768.Constantes y tipos ---------------------------------------------------------------------------.=> C_SAUCE. -.I_Enviroment --========================================================================= package I_Image_Grabber is --========================================================================= -. -.Documentation -Número máximo (pixels) de columnas de las imagenes adquiridas.Declaration of exported constant.

Variables de estado ---------------------------------------------------------------------------.Documentation -Valor del contraste. -.511. -.Documentation -Valor del brillo. minimo y nominal (por defecto) -de un parametro.511.Documentation: -Valores maximo .Documentation -Valor de la intensidad.511.256). type Param is(Brigthness.N_CHANNELS-1.R_2. Contrast_Values: constant Param_Value:= (0. ---------------------------------------------------------------------------.254).Documentation -Valor de la saturacion V. ---------------------------------------------------------------------------.255. U_Sat_Values: constant Param_Value:= (0.byte.. -. Brigthness_Values: constant Param_Value:= (0..Documentation: -Inicializa la tarjeta y reserva la memoria necesaria para dos -buffers de almacenamiento: uno para imágenes del vídeo en vivo y -otro para capturade imágenes estáticas. -. -.2)of C_Sauce.U_Sat. NOMINAL:integer.Documentation: -Pixel RGB en formato: R-G-B.V_Sat.R_8.R_16.Documentation -Valor de la saturacion U.128). -. MAX:integer. type Param_Value is record MIN:integer.R_4.Contrast.180). Hue_Values: constant Param_Value:= (0.Hue). type PixelData is array(natural range<>.Documentation: -Canales de entrada de video de la tarjeta. También se inicializan los 39 .163). -. -. -R_1 corresponde a la resolucion máxima -R_n corresponde a escalar la resolucion máxima -dividiendo por n type Ratio is (R_1.Documentation: -Parametros de la imagen.R_32).255. end record.I_Environment.netural range<>)of PixelRGB. type Channels is new Integer range 0.Operaciones ---------------------------------------------------------------------------. type PixelRGB is array(0.Documentation: -Píxels almacenados en las posiciones x. V_Sat_Values: constant Param_Value:= (0. -.y.especificación y diseño funcional de componentes diciembre 2002 -capturaran en la tarjeta.

Documentation: -Finaliza el overlay -Es necesario invocar la funcion con el video en vivo ya detenido -Se eleva la excepción Passthru_Error si se produce un error procedure Overlays_OFF(C: in out Video_Card).Documentation: -Libera los recursos asociados a la tarjeta. -. -Se eleva la excepción Passthru_Error si se produce un error procedure Overlays_ON(C: in out Video_Card. -Se eleva la excepción Passthru_Error si se produce un error procedure Star_Video(C: in out Video_Card. -.especificación y diseño funcional de componentes diciembre 2002 -valores del estado de losparametros de vídeo para cada uno de -los canales (que pueden ser de distintovalor en un momento dado). -Eleva la excepcion End_Error si se produce un error. x:in integer.Documentation: -Copia en el buffer de la imagen estática la última imagen -almacenada en el buffer de vídeo en vivo. -Se eleva la excepción Passthru_Error si se produce un error procedure Stop_Video(C: in out Video_Card). x:natural. -Eleva la excepcion Start_Error si se produce un error. function Open_Card(n:Natural. -La imagen aparece escalada con dimensiones x por y pixels.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. -. col:in PixelRGB. procedure Snap(C: in out Video_Card).Documentation: -Se detiene el video en vivo. -Se requiere que cuando se invoque el vídeo esté en vivo. -.Documentation: -Comienza a mostrar el vídeo en vivo en la ventana hwnd. 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 . -. trans:in boolean). -Se eleva la excepcion Acquisition_Error si se produce un error procedure Acquire(C: in out Video_Card). la imagen superpuesta es toda -ella translucida.Documentation: -Captura una imagen y la almacena en el buffer de imagen -estática con la resolución máxima permitida. -Se requiere que cuando se invoque no esté el video en vivo. hwnd:C_Sauce.I_Environment. y:natural). -Se eleva la exception Acquisition_Error si se produce un error. -. -La resolución máxima es RESOLUTION_X por RESOLUTION_Y -pixels.HWND.r:Ratio:=R_1) return Video_Card. 40 . y:in integer. -. bmp:in string. procedure Close_Card(C: in out Video_Card).

HWND). -. Passthru_Error:exception. -.Documentation: -Devuelve el valor actual de un parámetro de las imágenes -capturadas o mostradas en vídeo en vivo en el futuro. procedure Draw_Image(C: in out Video_Card. --========================================================================= -. ch:Channels).MAX_CARD-1. -Se eleva la excepción Config_Error si se produce un error. -. --========================================================================= --***************************************************************************** 41 . Config_Error:exception.Documentation: -Muestra en una ventana la imagen capturada en el buffer de -la imagen estática. Read_Error:exception. Draw_Error:exception. -Se eleva la excepción Config_Error si se produce un error. ch:Channels). procedure Read(C: in out Video_Card. -Se eleva la excepción Draw_Error si se produce un error. p:Param. -. Es necesario haber capturado previamente -una imagen con Acquire o Snap. procedure Set_Channel(C: in out Video_Card. value:integer.especificación y diseño funcional de componentes diciembre 2002 -. hwnd:C_Sauce..Documentation: -Selecciona el canal de entrada de vídeo. End_Error:exception. ch:Channels)return integer. procedure Set_Parameter(C: in out Video_Card. -Transfiere el rectángulo determinado por los índices de data. -Se eleva la interrupción Config_Error si se produce un error.Private interface declaration = --========================================================================= private type Video_Card is new Integer range 0. -Se eleva la excepción Read_Error si se produce un error.Declaration of exported exceptions = --========================================================================= Start_Error:exception. data:in out PixelData).Documentation: -Modifica un parámetro de las imágenes capturadas o mostradas -en vídeo en vivo en el futuro.Documentation: -Transfiere a la memoria principal la imagen capturada -anteriormente con Acquire o Snap. p:Param. --========================================================================= -. end I_Image_Grabber.I_Environment. Acquisition_Error:exception. function Get_Parameter(C:Video_Card.

II. pero si que trataremos en este apartado de obtener las claves para su implementación en el futuro.a d b • Generador del código de interfaces: Una interfaz representa una especificación de servicio y un modelo de información autocontenido. 42 . Esto requiere disponer de herramientas que ayuden a la generación y validación del código Ada que implementa estos componentes y de herramientas que generen el entorno UML que se requiere para el desarrollo de una aplicación.Private component declaration * --***************************************************************************** end.4. Estas herramientas no son desarrolladas en el presente proyecto.especificación y diseño funcional de componentes diciembre 2002 -.a d s co m p o n en t. En la siguiente figura se muestran las dos herramientas básicas de generación de código 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. Proceso de automatización de la gestión de componentes La metodología de diseño basada en componentes que se propone en este trabajo se basa en el modelado UML de las interfaces y de los componentes. La herramienta que se propone tiene dos objetivos: _ Verificar la consistencia y completitud del modelo UML que constituye la descripción de la interfaz.

_ Genera un fichero fuente Ada con el esqueleto del cuerpo del componente.especificación y diseño funcional de componentes diciembre 2002 _ Generar el código fuente Ada de la interfaz. y comprueba la consistencia de la descripciones que contienen. _ Genera un fichero fuente Ada con la especificación completa y compilable del componente. Este fichero deberá ser completado por el programador con el código que requiera la implementación de las partes declarativas y los cuerpos de los procedimientos y funciones cuyas cabeceras se hayan incluido. 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 descripción de las interfaces que el componente debe implementar. 43 . Este código debe ser una especificación Ada compilable que pueda ser utilizada para compilar las aplicaciones de usuario que la utilicen. • Generador del código de componentes: La herramienta integra la información contenida en el modelo del componentes y de las interfaces que implementa para generar el código compilable que constituye la implementación utilizable 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 especificación.

sino un descriptor parametrizado que permitirá contruir el modelo de la aplicación que hace uso de él. los requerimientos de procesamiento y los artefactos de sincronización que se incorporan a la aplicación con el uso o acceso al componente. En primer lugar.1. y por ello. a fin de formular su propio modelo de tiempo real. y que deben ser resueltos en la instanciación del modelo del componente. En este capítulo se muestra la estructura y la información asociada a dos componentes característicos de los desarrollados en este proyecto. puede heredar sus características. Este es un componente típico de un recurso hardware/ software. El modelo de tiempo real de un componente aporta los modelos de los recursos hardware y software. digitalización y almacenamiento de imagenes de vídeo. 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 parámetros que establezcan la forma en que hace uso de él la aplicación. de los que depende la instancia del modelo del componente. que puede ser utilizado para referenciar los componentes internos que están declarados en el modelo y que se instancia con cada instancia del componente. En segundo lugar. para especificar el uso que de él se hace. Modelo de tiempo real de una aplicación basada en componentes El modelo de tiempo real de un componente contiene la información estructural y los datos necesarios para poder formular el modelo de tiempo real de cualquier aplicación que los incluya. • Parámetros con sus tipos. El modelo de tiempo real de un componente. • Referencias de los modelos de otros componentes. MODELO DE TIEMPO REAL DE LOS COMPONENTES III. en su caso. • Conjunto de modelos de las operaciones. 44 .modelo de tiempo real de los componentes diciembre 2002 III. El modelo de tiempo real de un componente solo aporta aquellos elementos que están incluidos en el componente. • Descriptor de componente del que. en su caso. y en su caso. que modela un componente hardware/software relativo a una tarjeta de captura. • Un dominio de nombres. valores por defecto de los parámetros que deben ser establecidos en la instanciación del componente. se describe el componente C_IG_DT3153. que modela una plataforma. que pueden ser referenciadas por la aplicación o por los modelos de otros componentes. 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. no constituye en sí una instancia de modelo. se describe el modelo del componente NT_Processor_Mdl_1 que representa la plataforma hardware/software sobre la que se ha desarrollado la aplicación. organizadas por interfaces. y al driver software de control de la misma.

Real Time Operating System. Cuando se produce una interrupción. Para que un sistema operativo pueda considerarse RTOS3 ha de tener entre otras las siguientes características [20]: • Tiene que ser multitarea y expulsor. Este problema se puede evitar con un diseño correcto . 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. 4.2. 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 interrupción . III. Este mecanismo es necesario ya que cuando se produce una interrupción de nivel n se enmascaran todas las demás interrupciones de nivel inferior hasta que se completa su ISR correspondiente. • El comportamiento del RTOS ha de ser conocido y predecible. 5. Más adelante se completará la atención a la interrupción mediante la ejecución de una rutina DPC5. 1. Real Time Operating System. así como la de los otros dos componentes desarrollados a fin de modelar el análisis de planificabilidad y estimar el comportamiento de tiempo real del demostrador que se ha construido en este proyecto. Deferred Procedure Call. tal como se puede ver en la próxima figura. 2. se utilizarán instancias de los modelos de estos componentes. • Ha de tener capacidad de priorizar las tareas. 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. • Tiene que implementar mecanismos de sincronización de tareas que tengan una temporización predecible. Interrupt Servicing Routine.modelo de tiempo real de los componentes diciembre 2002 En el próximo capítulo. 45 . 3. pero en sistemas complejos esto puede ser bastante complicado. General Purpose Operating System. inmediatamente se ejecuta una pequeña rutina de atención llamada ISR4 que realiza únicamente las labores críticas (típicamente la escritura o lectura de registros hardware). Descripción de la plataforma WINDOWS NT Windows NT ha sido diseñado como un sistema operativo de propósito general (GPOS1). • Ha de existir un sistema de herencia de prioridades que evite el problema de “inversión de prioridad”. Sin embargo.

varias funciones de la API Win32 . Cada uno de ellos se compone de uno o varios threads. Asynchronous Procedure Call. Running: thread en ejecución actualmente. Transition: thread que se puede considerar como ready pero que su stack aún no se ha cargado en memoria. utilizan estos mecanismos. 1. . 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 . Es el planificador (dispatcher) quien decide que thread se ejecuta en cada instante de tiempo. Waiting: thread en espera de un recurso. .modelo de tiempo real de los componentes diciembre 2002 Los APC1 permiten generar interrupciones software desde los programas de usuario. 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. Los diferentes estados en que se puede encontrar un thread son los siguientes [21]: • • • • • Ready: thread dispuesto para competir en la planificación. como por ejemplo ReadFileEx o WriteFileEx . 46 . Standby: thread seleccionado por el planificador para ejecutarse a continuación.

Los niveles de prioridad de los threads en Windows NT son 32 (0-31) . 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 continuación . 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). lo primero que hace es ver si existe algún DPC pendiente.modelo de tiempo real de los componentes diciembre 2002 • Terminated: thread finalizado. En caso negativo se selecciona el thread de mayor prioridad. 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 . En caso afirmativo éste se ejecuta.

3. 48 . ésta no varia durante toda su ejecución (salvo que el programador lo especifique así en el código de la aplicación). 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 . Sólo pueden tener este rango de prioridades threads propios de aplicaciones de usuario. El modelo describe un computador concreto que opera bajo el sistema operativo Windows NT Server 4.0. Modelo de tiempo real de la plataforma WINDOWS NT De acuerdo a lo expuesto en el apartado anterior. podemos contemplar la utilización del sistema operativo Windows NT para sistema de tiempo real bajo unas determinadas condicionees: • Los threads de la aplicación tienen prioridades de tiempo real. en tareas que tras muchos ciclos aún no han conseguido el control de la CPU . de modo que siempre serán más prioritarios que los procesos del sistema operativo.. III.. En los threads que tienen asignada una prioridad de tiempo real . ). después de una I/O . • Es la única aplicación que se está ejecutando en el computador. • No existe conexión a red de comunicación externa. Todos los threads de procesos propios del sistema operativo tienen prioridades dentro de este rango. En los threads que tienen asignada una prioridad dinámica.modelo de tiempo real de los componentes diciembre 2002 Se distinguen dos tipos de prioridades: las dinámicas (0-15) y las de tiempo real (16-31). En este trabajo se ha formulado el modelo de tiempo real de la plataforma Windows NT que utilizaremos posteriormente en la aplicación que se desarrolla. • Se dispone de suficiente memoria como para evitar el uso de memoria virtual (I/O a disco). .

1 Server. El modelo de la plataforma tiene el objeto de describir la capacidad de computación que se dispone para la ejecución de la aplicación. y el consumo de las otras rutinas de gestión se modelan como un conjunto de componentes del tipo MAST_Interference.). El modelo NT_Processor_Mdl_1 describe la potencia de procesado que suministra el procesador. En la siguiente figura se muestra el modelo de la plataforma utilizando el perfil CBSE_MAST [23]. y de restarle la que se consume por las procesos de background que introduce el sistema operativo en la gestión de los diferentes recursos (timer. así como la totalidad de las tareas de background que introduce el sistema operativo para gestión de los recursos que interfieren la ejecución de la aplicación por ejecutarse a prioridad superior de las que se ejecutan sus tareas. 49 . etc. que agrega internamente un conjunto de componentes subordinados. el consumo por gestión del timer se modela mediante un elemento del tipo MAST_ Timer. que en este caso es del tipo especialicado MAST_Ticker. drivers. rutinas de recuperación. La potencia que proporciona el procesador se modela mediante un componente del tipo MAST_FP_ Processor. y esta resulta de considerar la que proporciona el procesador del computador. El modelo se describe mediante el elemento NT_Processor_Mdl_1.modelo de tiempo real de los componentes diciembre 2002 El componente NT_Processor_Mdl_1 es el modelo CBSE_MAST del procesador que se ha utilizado como plataforma para desarrollar la aplicación desarrollada como demostrador en este proyecto. Es un computador Pentium III a 800 MHz que opera con el sistema operativo Windows NT 4.

6E-6 sy stemTi me r <<MAST_Ti cke r>> T imer_Decl <<par>> Worst_Overhead = 25.0E-2 <<obj>> << obj>> <<MAST_Interference>> HiFrecInterferenc e_Decl <<obj>> trigger = MAST_Periodic_Event_Source(Period=16.1E-6. Aunque habitualmente es una referencia cuyo valor es establecido en la instanciación.6E-6 <<par>> Best_Overhead = 1. bcet = 99. en este caso se puede 50 .5E-6.4E-6 <<par>> Avg_Overhead = 9.modelo de tiempo real de los componentes diciembre 2002 <<MAST_Component_Descr>> NT_Processor_Mdl_1 <<ref>> host = proc <<obj>> proc <<MAST_FP_Processor>> <<obj>> Processor_Decl <<par>> Speed_Factor = 1.0E-6) <<simple>> + Activity_2(wcet = 89. bcet = 103.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 .7E-6) <<job>> + delay_1(theDelay = 508. 9E-6) A c tivity m ode l of << job > > O per L o_ Freq Interfe rnc e.0 E -6 ) El componente NT_Processor_Mdl_1 describe el modelo de tiempo real de la plataforma.3E-6 <<par>> Avg_Context_Switch = 4.7E-6.3E-6. bcet = 15.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 . 0E-6) <<simple>> + Activity_3(wcet = 108. bcet = 87. Tiene los siguientes elementos agregados: • <<ref>>host: Es una referencia predefinida para cualquier componente y específica el modelo del procesador en que se instancia el componente.06E0) <<obj>> System_SS : MAST_FP_Sched_Server(policy = MAST_Interrupt_FP_Policy(priority = MAX_Interr_Priority)) <<job>> + oper() <<simple>> + Activity_1(wcet = 111.2E-6 <<par>> Best_Context_Switch = 3.9E-6 <<par>> Period = 1.2E-6) <<job>> + delay_2(theDelay = 838.6E-3) <<obj>> System_SS : MAST_FP_Sched_Server(policy = MAST_Interrupt_FP_Policy(priority = MAX_Interr_Priority)) HiFrecInterrference <<simple>> + oper(wcet = 32. Es un elemento contenedor que se usa para proporcionar el identificador con que se puede hacer referencia al descriptor del modelo completo.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) <<MAST_Interference>> LoFrecInterference_Decl LoFrecInterference <<obj>> trigger = MAST_Periodic_Event_Source(Period=4.

En este caso tiene asignado el valor 1. _ <<par>>Worst_ISR_Switch: tiempo máximo de cómputo (peor caso) que el procesador emplea en realizar un cambio de contexto a una interrupción. _ <<par>>Best_Context_Switch: tiempo mínimo de cómputo (mejor caso) que el procesador emplea en realizar un cambio de contexto entre procesos de aplicación.Se le asigna el valor 32. ACET . por el factor de velocidad).0 (default value) 51 . _ <<par>>Avg_Context_Switch: tiempo promedio de cómputo que el procesador emplea en realizar un cambio de contexto entre procesos de aplicación. Sus elementos agregados son: _ <<par>>Speed_Factor: es un atributo escalar que describe la capacidad de procesamiento del recurso (el tiempo físico de ejecución de cualquier actividad que se ejecute en el recurso se obtendrá dividiendo el tiempo normalizado de ejecución (WCET . Se le asigna el valor 31 que corresponde a la prioridad mas alta para un proceso de aplicación de tiempo real en NT_Window. pero su valor es irrelevante salvo en que es superior a las prioridades de aplicación. Se le asigna el valor 16 que corresponde a la prioridad mas baja para un proceso de aplicación de tiempo real en NT_Window. BCET . _ <<par>>Worst_Context_Switch: tiempo máximo de cómputo (peor caso) que el procesador emplea en realizar un cambio de contexto entre procesos de aplicación. Se le asigna el valor “proc” que es la referencia interna al procesador que también se declara en el propio componente. _ <<par>>Max_Priority: máximo nivel de prioridad para un proceso de aplicación que se ejecuta en el procesador. • <<MAST_FP_Processor>> proc: Es el componente de modelado que describe la capacidad de procesamiento del procesador que ejecuta el código de la aplicación. ya que este procesador es el que se ha utilizado para evaluar los tiempos de ejecución de las diferentes actividades.Se le asigna el valor 32. Opera bajo una estrategia de prioridad fija. _ <<par>>Min_Priority: mínimo nivel de prioridad para un proceso de aplicación que se ejecuta en el procesador. . Se le asigna el valor 0. monitorización y cambio de contexto entre actividades. ) establecido en las operaciones que lleva a cabo . _ <<par>>Min_Interr_Priority: mínimo nivel de prioridad para una rutina de interrupción de aplicación que se ejecuta en el procesador. La capacidad de cómputo que representa se emplea en la ejecución de las actividades de la aplicación que tiene asignadas y en la ejecución de las tareas de gestión. pero su valor es irrelevante salvo en que es superior a las prioridades de aplicación.0..modelo de tiempo real de los componentes diciembre 2002 resolver en el propio descriptor. _ <<par>>Max_Interr_Priority: máximo nivel de prioridad para una rutina de interrupción de aplicación que se ejecuta en el procesador..

4E-6 segundo. Se le asigna el valor 25. • <<MAST_Ticker>> proc.9E-6 segundo.SystemTimer: Modela la carga de procesamiento que supone para el procesador la gestión de un timer basado en interrupciones hardware periódicas.tiene un único parámetro 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. Se le asigna el valor 1.modelo de tiempo real de los componentes diciembre 2002 _ <<par>>Avg_ISR_Switch: tiempo promedio de cómputo que el procesador emplea en realizar un cambio de contexto a una interrupción. _ <<par>>Avg_Overhead: tiempo promedio de cómputo que el procesador emplea en gestionar la atención a los plazos de temporización pendientes. • <<MAST_Interference>> : Modela la carga de procesamiento que supone para el procesador una interrupción periódica que se produce en el procesador y que es atendida por éste.). . En este caso. _ <<par>>Period: periodo de tiempo entre dos evaluaciones del ticker. varias o ninguna MAST_Interference. En la siguiente sección III. 52 .Max_Interr_Priority definida en el procesador. Así mismo modela la granularidad en la medida del tiempo por parte del sistema operativo que introduce el timer. software . Se describe en la siguiente sección. Se le asigna el valor 9.. se le asigna el valor proc. Sus parámetros son: _ <<par>>Worst_Overhead: tiempo máximo de cómputo (peor caso) que el procesador emplea en gestionar la atención a los plazos de temporización pendientes. Se le asigna el valor 1. Una MAST_Interference tiene agregados dos elementos internos: <<obj>>Trigger: _ Es un componente del tipo << Mast_Periodic_Event_Source>> que modela el patrón de disparo de la interferencia. La política de planificación que se le ha asociado es del tipo <<MAST_Interrupt_FP_Policy>> y está caracterizada a su vez por el atributo <<par>>priority. En el modelo de una plataforma Windows NT puede existir una.4. Se le asigna el valor 0. Se le asigna el valor 0. En este caso. El origen puede ser diverso (tarjetas hardware . _ <<par>>Best_Overhead: tiempo mínimo de cómputo (mejor caso) que el procesador emplea en gestionar la atención a los plazos de temporización pendientes. Este tiempo representa la granularidad de apreciación del tiempo del procesador.0E-2 segundo.6E-6 segundo.0 (default value) _ <<par>>Best_ISR_Switch: tiempo mínimo de cómputo (mejor caso) que el procesador emplea en realizar un cambio de contexto a una interrupción.. se describe el método de evalución de estos parámetros.0 (default value) _ <<obj>>SystemTimer: Modelo de gestión del timer.

modelo de tiempo real de los componentes diciembre 2002 _ <<usage>> Oper: Operación que describe el código que se ejecuta en cada invocación de la interference. end. 25 .. y del resto ( que corresponden a ejecuciones bases del bucle ) se calcula la media aritmética. Speed_Factor = 1. Se ejecuta un programa que lee de forma sucesiva y en un gran número de veces el reloj del sistema. Guarda el array en un fichero para su analisis. En nuestro caso. es: Procedure Test_Lectura. de modo que Max_Priority = 31 y Min_Priority = 16.46 µseg. 26 y 31. III. sólo disponemos de 7 valores efectivos de prioridad: 16 .100000) of T_fisico.1. 23 . 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. Este valor será utilizado en este y en otros análisis posteriores. no nos importa cual es más prioritaria entre ellas. begin Establece prioridad a un nivel de tiempo real. Puede ser simple (<<simple>>) o compuesta (<<job>>). Además .100000 loop T[n]=Lee_tiempo_fisico. En este último caso ha de estar descrita en su diagrama de actividad correspondiente. FP_Processor El valor del Speed_Factor es una constante de proporcionalidad respecto a un sistema de referencia.0. a pesar de estos valores . podemos fijar Max_Interr_Priority = Min_Interr_Priority = 32. Hay que tener en cuenta que . T:array (1.4. 22 . end loop. Estimación de los valores de los parámetros del modelo de la plataforma III. Las prioridades de los threads de nuestras aplicaciones han de ser de tiempo real .. Los tiempos de cambio de contexto se estimaron mediante dos pruebas de medida: 1) Evaluación del tiempo de lectura del reloj de tiempo real.4. Se calculan las diferencias T[i+1]-T[i] entre los sucesivos tiempos que se obtienen de la ejecución de este programa. for n in 1. Por ello . Cualquier interrupción es más prioritaria que cualquier thread de usuario. El pseudocódigo del programa que realiza esta medida. 24 . 53 . De estos se eliminan todas las que superan un valor umbral próximo a los valores más bajos. que corresponden a ejecuciones del bucle en las que se han producido algún tipo de interrupción o interferencia. como el sistema que modelamos es a su vez el que se utiliza como herramienta de estimación de tiempos de ejecución.

20000) of T_fisico. de ellas existirán 24 tiempos bases. 54 .6 µseg. Guarda el array en un fichero para su analisis. end Tarea_1.modelo de tiempo real de los componentes diciembre 2002 2) Estimación de los tiempo de cambios de contexto. mientras que los cambios de contexto aparecen en los índices múltiplos de 25.. begin Establece prioridad a un nivel de tiempo real. Cada tarea lee sucesivamente el reloj del sistema un número de veces (25 veces) y luego realiza una sincronización con la segunda tarea que continua la lectura del reloj.. for j in 1. end loop. end Se calculan las listas de diferencias de sucesivas lecturas de tiempo. m=m+1. Se extraen de la lista esos valores. entry t2.. T:array (1.400 loop accept t1.. de modo que tengamos un programa que al ejecutarlo sobre otro PC con Windows NT nos devuelva directamente los valores de los parámetros del modelo. end loop.400 loop accept t2. end loop. Con los valores obtenidos realizamos un análisis estadístico y estimamos los tiempos de contexto: Worst_Context_Switch = 5. entry t1. Best_Context_Switch = 3. Si i<>400 entonces entry t1. m=m+1. m:integer=1.25 loop T[m]=Lee_tiempo_fisico. se promedian y se les resta el tiempo base TClock de ejecución del bucle.25 loop T[m]=Lee_tiempo_fisico. Procedure Test_Ctxt. end loop. A continuación se ejecuta un programa con dos tareas a nivel de prioridad de tiempo real. Tarea_1 is for i in 1. end Tarea_2. Tarea_2 is for i in 1.3 µseg. Avg_Context_Switch = 4. for j in 1.2 µseg. Este proceso se puede automatizar incluyendo en los algoritmos anteriores el análisis estadístico..

00001 0. En nuestro caso aparecen dos interrupciones simples y una compuesta. frente al tiempo físico de medida.4.) Para la interrupción 1: Periodo = 10 mseg. en las que cada cierto tiempo se produce un incremento superior a TClock .5 Incrementos (seg.000045 0.) Tiempo físico (seg.4 0. 55 . Interference’s y Ticker En el Test_Lectura detallado en el apartado anterior para estimar el tiempo base de lectura del reloj de tiempo real.000005 0 0 0. en las que cada cierto tiempo se desencadena una sucesión de incrementos superiores a TClock siguiendo un patrón determinado. se observan una serie de valores de tiempos entre lecturas del reloj que superan significativamente el tiempo base TClock.1 0. En la figura se han representado en una gráfica los tiempo entre lecturas.6 µseg. Se aprecia claramente las dos interrupciones simples . A simple vista se aprecian dos tipos de interrupciones periódicas: unas simples. que en este caso ambas son de alta frecuencia: Cada punto de la gráfica representa una interrupción .000025 0. Se considera que cada vez que aparece uno de ellos es consecuencia de que durante la ejecución de ese bucle se ha producido una interrupción (relevante). Analizando estos valores detectamos dos interrupciones periódicas simples con los siguientes parámetros: Interrupciones periódicas 0.2 0.00002 0. y otras más complejas. T_Atención_Máximo = 25.000015 0. T_Atención_Medio = 9.00004 0.000035 0.4 µseg.00005 0.2.3 0.modelo de tiempo real de los componentes diciembre 2002 III.00003 0. y si a su valor le restamos el de TClock obtenemos el tiempo total de atención ( ISR + DPC ) a dicha interrupción.

Para la interrupción 2: Periodo = 16.).9 µseg. T_Atención_Mínimo = 15. Estos valores se pueden obtener de forma automatizada implementando un algoritmo de análisis espectral.3 µseg. T_Atención_Medio = 23.3 µseg. Se ha hecho utilizando la herramienta informática MATLAB 5.3 mseg.modelo de tiempo real de los componentes diciembre 2002 T_Atención_Mínimo = 1. Inc. de la empresa MathWorks .3. T_Atención_Máximo = 32. 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.5 µseg. 56 .

end loop.).1*(1/i). En nuestro caso resultan ser 61. end. De todas las interrupciones simples detectadas hay que identificar una de ellas como el Ticker. Como ya se ha comentado anteriormente.) y 100 Hz ( periodo de 10 mseg. for n in 1. necesitamos ejecutar el siguiente test: Procedure Test_Ticker..100 loop T[cont]=Lee_tiempo_fisico. el periodo de esta interrupción representa la granularidad de apreciación del tiempo del procesador. • Mediante un análisis de correlación se obtienen los índices de las muestras que pertenecen a cada interrupción.. Se eliminan las que pertenecen a más de una serie y con el resto se realiza un análisis estadístico para obtener los tiempos máximo . begin Establece prioridad a un nivel de tiempo real.3 mseg. medio y mínimo.1000 loop D=0. end loop. 57 . Por ello. cont:integer=1.modelo de tiempo real de los componentes diciembre 2002 • Se aplica la transformada rápida de Fourier y se obtienen las frecuencias fundamentales.. Guarda el array en un fichero para su analisis.34 Hz ( periodo de 16. D:T_Fisico. T:array (1.100000) of T_fisico. for i in 1. cont=cont+1 Sleep D.

0001 Incrementos (seg.00006 0.) 0.7 µseg. Interrupciones periódicas 0.00002 0 0 2 4 Tiempo físico (seg. Ésta consiste en tres interrupciones simples que se repiten siempre siguiendo un patrón fijo.00012 0. Además de las dos interrupciones simples aparece otra más compleja cada 4 segundos. Ésta última se modela mediante un diagrama de actividad con los siguientes valores: Activity_1: wcet = 115.) 6 8 Si representamos como antes en una gráfica los incrementos de tiempo respecto a la muestra anterior frente al tiempo físico apreciamos las dos bandas de las interrupciones simples de alta frecuencia ( en torno a 15 y 23 µseg. <<MAST_Wait_State>> Trigger Act_1 do/ Activity_1 Act_2 do/ Delay_1 Act_3 do/ Activity_2 Act_4 do/ Delay_2 Act_5 do/ Activity_3 <<Named_State>> End 58 . de incremento ) con cierta dispersión y las tres interrupciones de la interference compuesta cada 4 segundos.00008 0. Ese valor es precisamente el periodo del Ticker .modelo de tiempo real de los componentes diciembre 2002 Analizamos el array de resultados y obtenemos el valor mínimo de D para el cual T[i+1]T[i] es aproximadamente igual a D. Delay_1: theDelay = 508 µseg.6 µseg.00004 0. bcet = 99. que en nuestro caso resulta ser de 10 mseg.

) 0. bcet = 87. realizamos el mismo test pero en esta ocasión con la conexión a la red ethernet externa activa. Activity_3: wcet = 108.1 µseg. El periodo exacto ( en valor medio ) de esta interference compuesta es de 4.00002 0 0 2 4 Tiempo físico (seg.9 µseg. Son interrupciones provocadas por 59 .06 segundos.00006 0. El resultado es el siguiente: Interrupciones periódicas 0.modelo de tiempo real de los componentes diciembre 2002 Activity_2: wcet = 89.00008 0. En esta ocasión la obtención automatizada de estos valores es más complicada . Delay_2: theDelay = 838 µseg. aunque en un futuro se pueden evaluar mecanismos que permitan llevarla a cabo.00012 Incrementos (seg. simplemente para comprobar que en este caso el modelo no sería válido.0001 0. bcet = 103. Por último.00004 0.7 µseg.) 6 8 Ahora se aprecian nuevas interrupciones aparentemente esporádicas que no pertenecen a ninguna de las tres interferences modeladas anteriormente.2 µseg.

sysTimer: que modela tanto el overhead que requiere la atención del reloj interno del procesador.HiFrecInterference: Que modela la ejecución periodica de la operación previa. Esta interferencia es más compleja ya que incluye la ejecución a nivel de sistema de tres actividades separadas entre sí por tiempos de retraso constantes. así que mantendremos la premisa de inabilitarla para implementar aplicaciones de tiempo real sobre esta plataforma. • <<Mast_Interference>> theProcessor.HiFrecInterference. los elementos que el modelo introducen en el MAST_file son: • <<Mast_FP_Processor>> theProcessor. La compilación de esta Interference requiere introcuir en el código: _ <<Mast_FP_Sched_Server>> theProcessor.5. III. _ <<MAST_Regular_Transaction>> theProcessor. Esta transacción incluye el patrón de generación del evento externo theProccessor. Código 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 líneas de código que se insertan en el modelo Mast de la aplicación como consecuencia de la compilación del <<Mast_Component_Inst>> theProcessor que es una instancial del <<component>> NT_Processor_mdl_1..modelo de tiempo real de los componentes diciembre 2002 la red.Trigger que dispara la interferencia. < < 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 sección III. _ <<Mast_Operation>>theProcessor. como la granularidad temporal que introduce en la medida del tiempo dentro del procesador.System_SS: que modela el scheduling server que con una política de planificación MAST_Interrup_ FP_Policy y con prioridad 32.3 ms (de origen y con finalidad desconocida).Oper: que modela la actividad que se ejecuta en cada invocación de la interferencia. A su vez este procesador incluye el modelo del timer: _ <<Mast_Ticker>> theProcessor. La compilación de esta Interference requiere introducir en el código: 60 . • <<Mast_Interference>> theProcessor.LoFrecInterference : que modela el overhead que introduce en el procesador una interrupción con periodo 4s (de origen y con finalidad desconocida).HiFrecInterference.3.proc: Que modela el procesador que incluye el componente.HiFrecInterference : que model el overhead que introduce en el procesador una interrupción con periodo 16.HiFrecInterference. y en principio no tenemos un modelo de ella.

host = proc -.LoFrecInterference.modelo de tiempo real de los componentes diciembre 2002 _ <<Mast_FP_Sched_Server>>theProcessor. Name => theProcessor.2E-6.proc. que modelan las actividades que se ejecuta en cada invocación de la interferencia.Segmento del código MAST-File del modelo RT_Comp_Railway ------------------------------------------------------------------------------------.LoFrecInterference: Que modela la ejecución periodica de la secuencias de las operaciones previas con los correpondientes retrasos entre ellas. Min_Interrupt_Priority => 32.Se corresponde a un Fixed_Priority_Processor con todos los atributos que se -.theprocessor.System_SS: que modela el scheduling server que con una política de planificación MAST_Interrup_ FP_Policy y con prioridad 32.LoFrecInterference. Speed_Factor => 1.4E-6. Worst_Context_Switch => 5.6E-6.theprocessor.HiFrecInterference (<<MAST_Interference>>) ---------------------------------------------- 61 . --********************************************************************************* -.place = MAST_Platform_View (Buscamos ahi el modelo) -. -----------------------------------------------------------------------------------. Period => 1. _ <<MAST_Regular_Transaction>>theProcessor. Best_Context_Switch => 3.Trigger que dispara la interferencia.3E-6. Avg_Context_Switch => 4. Avg_Overhead => 9.6E-6. Max_Priority => 31.9E-6. Worst_Overhead => 25.Activity_2 _ <<Mast_Simple_Operation>>theProcessor.referencias -. Esta transacción incluye el patrón de generación del evento externo theProccessor.Activity_1 _ <<Mast_Simple_Operation>>theProcessor.proc (: MAST_FP_Processor) ----------------------------------------------.0E-2 ).objetos: -----------------------------------------------------------------------------------.0 ).LoFrecInterference. Min_Priority => 16. Best_Overhead => 1.NT_Processor_Mdl_1 (<< MAST_COmponent_Descr>>) -.theprocessor (: NT_Processor_Mdl_1 <<MAST_Component_Inst>>) -------------------------------------------------. Max_Interrupt_Priority => 32.pasan como parametros Processing_Resource (Type => Fixed_Priority_Processor.MAST_FP_Processor ----------------------------------------------.LoFrecInterference.LoFrecInterference.Activity_3. _ <<Mast_Simple_Operation>>theProcessor. System_Timer => (Type => Ticker.

Transaction (Type => Regular.3E-6.MAST_Interference -------------------------------------.ACET Y BCET que se especifican -.End.Oper. Internal_Events => ((Type => Regular.Trigger.Period -.LoFrecInterference.HiFrecInterference.System_SS )) ).proc ). External_Events => ((Type => Periodic.HiFrecInterference.HiFrecInterference.HiFrecInterference. activity_server => theProcessor.Declaramos un scheduling server con la policy y priority indicadas Scheduling_Server (Type => Fixed_Priority.HiFrecInterference. Best_Case_Execution_Time => 15.modelo de tiempo real de los componentes diciembre 2002 -. The_Priority => 32 ). Name => theProccessor.Period -.Declaramos un scheduling server con la policy y priority definidas Scheduling_Server (Type => Fixed_Priority.LoFREcInterference (<<MAST_Interference>>) ----------------------------------------------. -------------------------------------------------------------------. -. Name => theProcessor. Name => theProcessor. Output_Event => theProcessor.HiFrecInterference.MAST_FP_Sched_Server -----------------------------.System_SS.3E-6 ).Oper.MAST_Interference -------------------------------------.Scheduling server System_SS del tipo MAST_FP_Sched_Server ------------------------------.HiFrecInterference. Server_Sched_Parameters => 62 .End )). Name => theProcessor. activity_operation => theProcessor.Declaramos una transaction que tiene: -.theprocessor.Trigger.External Event Periodico con periodo definido por trigger.Scheduling server System_SS del tipo MAST_FP_Sched_Server ------------------------------.se declara la operacion que ejecuta la interferecia Operation (Type => Simple. Period => 16. Worst_Case_Execution_Time => 32.HiFrecInterference.External Event Periodico con periodo definido por trigger. Server_Sched_Parameters => (Type => Interrupt_FP_Policy.MAST_FP_Sched_Server ------------------------------. Name => theProccessor.Operation Oper con los WCET. Server_Processing_Resource => theProcessor. Name => theProcessor.ACET Y BCET que se especifican -. Input_Event => theProccessor.Declaramos una transaction que tiene -.HiFrecInterference.System_SS.Operation Oper con los WCET. Event_Handlers => ((Type => Activity.6E-3 )).

-.# oper. Operation (Type => Simple.LoFrecInterference. (Type => Regular.9E-6 ).Act_3 = Activity_2 -.2E-6 ).modelo de tiempo real de los componentes diciembre 2002 (Type => Interrupt_FP_Policy.1E-6. Name => theProcessor. (Type => Delay.System_SS ). Best_Case_Execution_Time => 87.Activity_1.# oper.LoFrecInterference. Internal_Events => ((Type => Regular. Name => theProccessor.End )). Worst_Case_Execution_Time => 111. Name => LFI1 ).# oper. (Type => Regular.LoFrecInterference.Act_2 = Delay_1 . Server_Processing_Resource => theProcessor. Event_Handlers => ((Type => Activity.LoFrecInterference.Activity_3. Operation (Type => Simple. Worst_Case_Execution_Time => 108.Trigger. Name => LFI2 ).Activity_2.Trigger.LoFrecInterference. Activity_server => theProcessor. External_Events => ((Type => Periodic. Input_Event => LFI1. Name => LFI3 ).7E-6 ).LoFrecInterference.Act_1 = Activity_1 -. Input_Event => theProccessor.LoFrecInterference. Best_Case_Execution_Time => 103. Best_Case_Execution_Time => 99. Name => LFI4 ).Act_4 = Delay_2.0E-6) -. The_Priority => 32 ).Act_5 = Activity_3 Operation (Type => Simple.simples y dos delays: -. Output_Event => LFI1.La transacción de la interferencia activa un job compuesto de tres operaciones -. (Type => Regular. Transaction (Type => Regular. Output_Event => LFI2. Period => 4.# oper.proc ).Activity_1. Name => theProcessor. Name => theProcessor.5E-6. 63 .06E0)). Worst_Case_Execution_Time => 89. Name => theProccessor. que a su vez = delay (838.0E-6) -. Activity_operation => theProcessor. que a su vez = delay(theDelay = 508.LoFrecInterference. Name => theProcessor. (Type => Regular.# oper.LoFrecInterference.7E-6.

0E-6. concretamente describe el componente C_IG_DT3153.0E-6.End. Modelo de tiempo real del componente C_IG_DT3153 A modo de ejemplo. theProcessor. (Type Input_Event Output_Event activity_operation activity_server ). theProcessor. 838.LoFrecInterference. LFI4.System_SS ). 64 .6. en este apartado se describir el modelo de tiempo real de uno de los componentes software implementados.Activity_3.LoFrecInterference. theProcessor. 838.Activity_2.LoFrecInterference. LFI2. LFI3. LFI4.modelo de tiempo real de los componentes diciembre 2002 Delay_Max_Interval Delay_Min_Interval ). (Type Input_Event Output_Event Activity_operation Activity_server )) => 508. theProcessor.LoFrecInterference. --********************************************************************************* III. LFI3. => 508.LoFrecInterference. que posteriormente utilizaremos en la aplicación de ejemplo para detectar la posición de los trenes en la maqueta. theProcessor.0E-6 => => => => => => => => => => => => => => => Activity.0E-6 Activity. (Type Input_Event Output_Event Delay_Max_Interval Delay_Min_Interval ).System_SS Delay.

0E-3.modelo de tiempo real de los componentes diciembre 2002 . bcet = 0.93E-3.41E-3) ProcessFrame(wcet = SemiFrame_Duration. Se trata de un ente de modelado que constituye un descriptor genérico y parametrizable que describe en este caso el recurso software del sistema. El componente C_IG_DT3153. y de un canal DMA que transfiere la imagen desde la tarjeta a la memoria del computador en concurrencia con la ejecución de la aplicación.62E-3. El elemento principal del modelo es el MAST_Component_Descr [23]. una tarjeta hardware que realiza de manera autónoma la digitalización de la imagen.09E-3) PreW aitForEnd(wcet = 0. bcet = 14.4E-3. bcet = 18. En este apartado solo se describen los modelos de tiempo real de las operaciones Read y Adquire. Es un software de modelo de tiempo real complejo. ya que incorpora.02E-6 SemiFrame_Duration = MAST_Time=18. bft : MAST_Factor = 0. 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. wft : MAST_Factor = 0. modela el componente software diseñado para controlar la tarjeta de digitalización de imágenes ( grabber ) DT3153 de Data Translation.2E-5. bcet = 1. 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 código Ada que implementa el componente.host= DMA_Bus) Image_Processor : MAST_FP_Processor Image_Process = MAST_FP_Sched_Server(policy=MAST_Interrupt_FP_Policy(priority= host.14E-6.66E-3.Max_Interrupt_Priority). transferirla al espacio de memoria de la aplicación o transferirla a una ventana de vídeo en vivo de windows.53E-3) PostW aitForSecondFrame(wcet = 1. bcet = SemiFrame_Duration) << obj>> D MA_Bus << simple>> << simple>> << simple>> << simple>> << simple>> << simple>> << simple>> 1 << MAST_Component_Descr>> MAST_FP_Network:D MA_Bus << par>> << par>> << par>> << par>> << par>> Transmission = SIMPLEX . que son la que se utilizan en el demostrador. bbt : MAST_Time = 34. En el se declaran los recursos (componentes) internos o externos 65 .15E-6.Max_Interrupt_Priority)) Bus_Transfer_SS = MAST_FP_Sched_Server(policy=MAST_FP_Preemptible_Policy.3E-3.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. << 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.host=Image_Processor) W aitForFirstFrame(wcet = 1.0E-3 Driver_priority = host.0E-3) PreW aitForSecondFrame(wcet = 0.47E-3) PostW aitForEnd(wcet = 19.2E-5) TransferSemiFrame(wcet = 18. bcet = 1.Max_Interrupt_Priority Driver_Host = host AttendFrameTrans_SS = MAST_FP_Sched_Server(policy=MAST_Interrupt_FP_Policy(priority=host. bcet = 0.72E-3. ImgSize : MAST_Factor) << job>> + Acquire() Como se ha descrito en el capítulo II este componente ofrece una interfaz que posibilita capturar una imagen de una cámara de vídeo.

• <<par>> Driver_Priority: MAST_Priority= Host. Por defecto se establece el mismo procesador en que se ha instalado el componente.0E-3: Representa el tiempo que tarda en transmitirse un semiframe en una señal de vídeo. Su unica función es modelar la temporización del proceso de camptura de imágenes de la señal de vídeo. Se ha introducido para incrementar la granularidad de la transferencia de información por el DMA. • <<par>> AvgPixelOverhead: MAST_Time=0. • <<par>> SemiFrame_Duration: Time=18. • <<par>> DriverHost: MAST_FP_Processor= Host: Establece el computador en que se ejecuta el driver. • <<obj>> Image_Process: MAST_FT_Sched_Server: Scheduling server en el que se ejecutan las actividades del Image_Processor. Debe ser establecido en la instanciación del componente.Max_Interrupt_Priority: Prioridad en la que se ejecuta el driver control de la tarjeta de captura de imágenes. Declaración 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 gestión del proceso de transferencia por DMA de la imágenes desde la tarjeta de digitalización. los párametros que deben establecerse en su intanciación y los modelos de los modos de uso que se le pueden requerir: Parámetros: • <<par>> PixelInLine: Mast_Factor= 64: Representa el número de píxels que son transferidos en una transacción por el DMA. Este scheduling server se planifica con política MAST_FP_Preemptible_Policy y con la prioridad por defecto.02E-6: Representa el overhead medio que supone para el procesador la transferencia de un píxel a través del DMA. • <<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. Esta tarea se planifica con política MAST_Interrupt_Priority_Policy y con la prioridad máxima de interrupción. y que se utiliza como forma de modelar el overhead que produce el DMA sobre el procesador que ejecuta el 66 . Es un parámetro de modelado que no corresponde al sistema físico.Se ha establecido como valor por defecto la maxima prioridad de interrupción del computador que ejecuta el driver.modelo de tiempo real de los componentes diciembre 2002 que requiere para su operación. • <<obj>> Image_Processor: MAST_FT_Processor: Procesador que modela las actividades de captura y digitalización de las imágenes en el hardware de la tarjeta de digitalización. 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. que opera en modo Simplex. • <<obj>>DMA_Bus: Network de tipo MAST_FP_Packet_Driver: MAST_FP_Network.

Se trata de una operación sencilla que lo único que hace es copiar los píxels de la imagen capturada por la tarjeta en una estructura de datos accesible por el usuario. <<MAST_Interface_Descr>>I_Image_Grabber: Interfaz pública del componente que contiene las operaciones públicas que ofrece el componente. Se ha hecho un estudio de la variabilidad de los tiempos en función del número de píxels de la imagen. bbt : 67 . transfiere un número de paquetes igual al número de líneas (Pixel en imagen/Pixel en linea) y la duracción de la transmisión de cada paquete es tal que la transmisión de cada Semiframe dure el tiempo estimado. Se ha comprobado que el tiempo depende del número de pixels de forma lineal siguiendo el siguiente patrón: Tiempo = OFFSET + ( numero_pixels * CTE_LIN ) Realizando varias medidas para imágenes de distintos tamaños se han obtenido los valores de OFFSET y CTE_LIN ( para el mejor y el peor tiempo). _ <<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.4E-3. En este caso estos tiempos dependen del tamaño de la imagen. 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. de modo que lo único que necesitamos conocer son los tiempos de mejor y peor caso. 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 operación externa Acquire. En el modelo de tiempo real describimos este comportamiento del siguiente modo: En el MAST_Interface_Descr declaramos la operación como: <<job>> Read(wbt : MAST_Time = 36. Es una operación totalmente software. Cuando se transmite una imagen. wft : MAST_FActor = 0. que se describe más adelante.modelo de tiempo real de los componentes diciembre 2002 componente.15E-6. <<job>> Read: Modela el procedimiento de transferencia a la memoria principal de la imagen capturada anteriormente con los procedimientos Acquire o Snap.

modelo de tiempo real de los componentes

diciembre 2002

MAST_Time = 34.3E-3, bft : MAST_Factor = 0.14E-6, ImgSize : MAST_Factor)

Sus parámetros son: • • • • • wbt : OFFSET para el cálculo del wcet. wft : CTE_LIN para el cálculo del wcet. bbt : OFFSET para el cálculo del bcet. bft : CTE_LIN para el cálculo del bcet. ImgSize : número de píxels de la imagen.

Y por lo tanto , el cálculo de los tiempos wcet y bcet se describe mediante el diagrama de actividad asociado a la operación:

Activity do/ MAST_Simple_Operation(wcet=wbt+wft*ImgSize, bcet=bbt + bft*ImgSize)

Los valores de los parámetros de la operación se han obtenido realizando medidas sobre la plataforma que va a soportar la aplicación. 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 automáticamente estos valores al cambiar de plataforma. <<job>> Acquire: Se trata de una operación compleja que cuando se invoca captura una imagen y la almacena en la memoria física reservada por la tarjeta. Esta memoria no es accesible por el usuario, por eso disponemos de la operación Read anteriormente comentada. La tarjeta que utilizamos para la implementación del componente1 realiza esta función 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

modelo de tiempo real de los componentes

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 operación Acquire fuese convencional en el array de resultados tendríamos muestras separadas TClock entre sí ( salvo las interferences periódicas detectadas en la plataforma ) , ya que la Tarea_1 es más prioritaria que Tarea_2. Pero en la práctica no es así. Si representamos en una gráfica los incrementos de tiempo respecto a la muestra anterior frente al tiempo físico 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 físico (seg.) Incrementos (seg.)

69

modelo de tiempo real de los componentes

diciembre 2002

Si representamos de forma esquemática 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 operación hasta que comienza a transmitirse la imagen. Este tiempo depende de la referencia de sincronismo de la señal analógica de vídeo. En este intervalo las tareas de orden superior se ejecutan normalmente. • T2 : transmisión de las líneas pares de la imagen. Este tiempo depende del estándar de la señal analógica de vídeo. Durante la transmisión se produce una bajada de rendimiento en el procesador principal debido a que se utiliza DMA , y cuando el procesador de la tarjeta de adquisición utiliza el bus del sistema , el procesador principal tiene que esperar ( si desea utilizarlo él ). • T3 : tiempo transcurrido desde el final de la transmisión de las líneas pares hasta la interrupción 1. En este intervalo las tareas de orden superior se ejecutan normalmente. • T_INT1 : interrupción provocada por el procesador de la tarjeta para indicar que se ha completado la transmisión de las líneas pares. • T4 : tiempo transcurrido desde la interrupción 1 hasta el comienzo de la transmisión de las líneas impares. En este intervalo las tareas de orden superior se ejecutan normalmente. • T5 : como T2 pero para las líneas impares. • T6 : como T3 pero para las líneas impares. • T_INT2 : interrupción provocada por el procesador de la tarjeta para indicar que se ha completado la transmisión de las líneas impares. • T7 : tiempo transcurrido desde la interrupción 2 hasta que la operación 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

09E-3) [ T4 ] PreWaitForEnd (wcet = 0.53E-3) [ T3 ] PostWaitForSecondFrame (wcet = 1. bcet = 18E-3) [ T2 . Las operaciones MAST_NOP no existen. bcet = 15. Se han obtenido los parámetros de las distintas operaciones que resultan ser: • • • • • • • WaitForFirstFrame (wcet = 26.55E-3) [ T1 ] TransferSemiFrame (wcet = 18E-3.66E-3. bcet = 0.68E-3.83 µseg. bcet = 1. Bus_Transfer_SS representa al bus del sistema e Image_Process representa al procesador de la tarjeta de adquisición de la imagen. bcet = 14. bcet = 0.47E-3) [ T6 ] PostWaitForEnd (wcet = 19. se han incluido para poder describir el modelo en la herramienta de análisis.62E-3. bcet = 135. que resulta ser: AvgPixelOverhead = 20 nseg. 71 . Debido a la sensibilidad de la medida del tiempo en el PC ( 0.41E-3) [ T7 ] ProcessFrame (wcet = 138.7E-6) [ T_INT1 . 1.72E-3. Realizando medidas con imágenes de distintos tamaños descubrimos que ese tiempo es proporcional al número de píxels y calculamos el valor del overhead medio por píxel .93E-3.modelo de tiempo real de los componentes 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 . T5 ] PreWaitForSecondFrame (wcet = 0. T_INT2 ] Tenemos que modelar de alguna forma la bajada de rendimiento que se produce durante la ejecución de TransferSemiFrame.2E-6. ) no llegamos a apreciar con precisión lo que está ocurriendo pero si podemos calcular el overhead total que se produce en el intervalo.

Max_interrupt_Priority = 32 -. Para evitar este problema .host = theprocessor (para nosotros theprocessor. vamos a suponer que en cada paquete se tranmiten PixelInLine píxels. Podríamos suponer que un paquete equivale a un píxel .02E-6 -.Buscamos ahí el modelo del componente MAST_C_I_Grabber -. La única restricción que tenemos es que el valor ha de ser múltiplo de todos los tamaños de imagen posibles. Código 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 líneas de código que se insertan en el modelo Mast de la aplicación como consecuencia de la compilación del <<Mast_Component_Inst>> theGraber que es una instancial del <<component>> C_IG_DT3153. pero en ese caso el número de iteraciones que debería efectuar la herramienta de análisis de planificabilidad sería demasiado elevado.place :C:/MAST/Component/Sauce/cap.modelo de tiempo real de los componentes diciembre 2002 A continuación debemos hacer una suposición sobre el tamaño de los paquetes transmitidos sobre el bus del sistema durante la ejecución de TransferSemiFrame.proc) -.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 sección III.AttendFrameTrans_SS. en nuestro caso fijamos un valor de: PixelInLine = 64 III.the_Grabber (: RMT_C_Image_Grabber) ------------------------------------------------------------------------------------.RTM_C_Image_Grabber.Driver_Priority = host. Este valor es completamente arbitrario .Imagesize = 27648 -. m d l) I m a g e S iz e = 2 7 6 4 8 .parametros -. Por ello . Server_Sched_Parameters => 72 .Imagesize = 27648 -. los elementos que el modelo introducen en el MAST_file son: --********************************************************************************** -.6. ya que lo que nosotros hemos medido es el overhead total.PixelInLine = 64 -. Name => the_Grabber.Driver_host = host = theprocessor -.AvgPixelOverhead = 0.SemiFrame_Duration = 18E-3 -.Segmento del código MAST-File del modelo RT_Comp_Railway -------------------------------------------------------------------------------------.7.AttendFrameTRans_SS (:MAST_FP_Sched_Server) Scheduling_Server (Type => Fixed_Priority. < < 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 .mdl -.

Name => the_Grabber.DMA_Bus.Bus_TRansfer_SS ( : MAST_FP_Sched_Server) --------------------------------------------Scheduling_Server (Type => Fixed_Priority. Best_Case_Execution_Time => 1.RTM_C_Image_Grabber.28E-6 ) ) )).Packet_Server.Packet_Receive.theDriver. The_Priority => 32 ). Server_Processing_Resource => the_Grabber. Max_Blocking => 41. Packet_Receive_Operation => (Type => Simple. => Fixed_Priority_Processor.DMA_Bus. Server_Sched_Parameters => (Type => Fixed_Priority_Policy ).DMA_Bus (MAST_FP_Network) ----------------------------.DMA_Bus ).28E-6). => the_Grabber.28E-6. Server_Processing_Resource => theProcessor.Image_Processor (type :Mast_Device) ---------------------------------------------. Worst_Case_Execution_Time=> 1. Packet_Send_Operation => (Type => Simple.Packet_Send. Transmission => Simplex.modelo de tiempo real de los componentes diciembre 2002 (Type => Interrupt_FP_Policy.RMT_C_Image_GRabbe.proc ). Best_Case_Execution_Time => 1. Server_Sched_Parameters => (Type => Interrupt_FP_Policy.theDriver. Name => the_Grabber.6E-6.Bus_Transfer_SS.28E-6.6E-6. The_Priority => 32 ). Name => the_Grabber. List_of_Drivers => ((Type => Packet_Driver.proc ). Min_Packet_Transmission_Time => 41. Max_Packet_Transmission_Time => 41. Name => the_Grabber.DMA_Bus. Packet_Server => (Type => Fixed_Priority.Corresponde a una FP_Processor sin atributos Processing_Resource (Type Name ).MAST_FP_Network ----------------------------. -.Declaramos una network con los atributos que aparecen en la descripción Processing_Resource (Type => Fixed_Priority_Network.RMT_C_Image_GRabber.theDriver.DMA_Bus. Server_Processing_Resource => theProcessor.6E-6.MAST_Device ----------------------.Image_Processor 73 . ------------------------------------------------------------------------------------. ------------------------------------------------------------------------------------. Worst_Case_Execution_Time=> 1. Name => the_Grabber.

Best_Case_Execution_Time => 1.0E-3. Name => The_Grabber.MainProcessor.41E-3 ). Worst_Case_Execution_Time => 1. Operation (Type => Simple. -.0E-3 ).66E-3.Image_Process.Image_Process (type : Mast_System_SS) -. -Worst_Case_Execution_Time => 36.Job parametrizables ----------------------------------------------Operation( -Type => Simple.47E-3 ).Declaramos ahora todas las operaciones simples que aparecen Operation (Type => Simple.0E-3 ). 74 .ProcessFrame. Name => the_Grabber. Best_Case_Execution_Time => 0. Worst_Case_Execution_Time => 1. Best_Case_Execution_Time => 1. Best_Case_Execution_Time => 0.4E-3 + 0.PostWaitForSEcondFrame.Image_Processor ). Operation (Type => Simple.Read.Corresponde a un SS Non preemtible con prioridad por defecto ---------------------------------------------Scheduling_Server (Type => Fixed_Priority.2E-5.2E-5 ). Worst_Case_Execution_Time => 19. Server_Processing_Resource=> the_Grabber. -Name => The_Grabber.09E-3 ).93E-3. Name => The_Grabber.PostWaitForEnd.PreWaitForEnd. Name => The_Grabber. Worst_Case_Execution_Time => 0. Worst_Case_Execution_Time => 18. Worst_Case_Execution_Time => 18.15E-6*ImgSize. Name => The_Grabber. Name => The_Grabber.53E-3 ).TRansferSemiFrame. Operation (Type => Simple. Name => The_Grabber. Name => The_Grabber.0E-3.I_Image_Grabber. Worst_Case_Execution_Time => 0. Operation (Type => Simple. Best_Case_Execution_Time => 18. Server_Sched_Parameters => (Type => Interrupt_FP_Policy.72E-3. Best_Case_Execution_Time => 18.PreWaitForSecondFrame. Operation (Type => Simple.modelo de tiempo real de los componentes diciembre 2002 ------------------------------------------------------------------------------------. Operation (Type => Simple. Best_Case_Execution_Time => 14. The_Priority => 32 ). -.62E-3.WaitForFirstFrame.

14E-6*ImgSize). Best_Case_Execution_Time => 40.I_Image_Grabber. Name => The_Grabber.27E-3). Worst_Case_Execution_Time => 40.55E-3.modelo de tiempo real de los componentes diciembre 2002 -Best_Case_Execution_Time => 36.Read_1. ---------------------------------------------.4E-3 + 0. --********************************************************************************** 75 .Anadida desde al transaccion Operation (Type => Simple.

Segmentos de vía comprendidos entre dos cruces.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 IV. En nuestro caso tenemos un tren azul y un tren rojo. tanto en lo relativo a la validez y completitud de su especificación. Cuando una locomotora se encuentra situada sobre un tramo . Control por computador de una maqueta de trenes utilizando visión artificial Se ha desarrollado como ejemplo una aplicación 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. su motor se alimenta 76 . D . B . DEMOSTRADOR DE UN SISTEMA DE TIEMPO REAL BASADO EN COMPONENTES IV.. TRAMOS: A . También comprobamos la validez del análisis de planificabilidad de peor caso utilizando la herramienta MAST propia para tal fin. a la capacidad de interconectividad y a la predecibilidad que aportan sus modelos de tiempo real. en la que la posición de las locomotoras se detecta mediante visión artificial..También denominadas trenes. y sobre todo permite obtener experiencia sobre el ciclo de desarrollo de aplicaciones basadas en componentes. Esta aplicación desarrollada tiene la finalidad de validar los componentes. Se dispone de una maqueta de trenes de la marca Roco de escala N instalada sobre una base rígida debidamente cableada para facilitar su control de modo electrónico. Son locomotoras de escala N de la marca Ibertren. En su parte superior llevan instalada una tarjeta de un determinado color que permite identificar su posición mediante visión artificial. Se trata de las máquinas que se mueven sobre las vías. C . E y F .1. El aspecto que presenta ( vista desde arriba ) es el siguiente: &6 % &4 $ ( ) & &5 ' &7 Consta de tres tipos de elementos: LOCOMOTORAS: ROJA y AZUL .

Cuatro cruces idénticos . El control se realiza mediante un electroimán (integrado en la propia pieza que conforma el cruce) con tres conexiones electrónicas: una de ellas a tierra (0 voltios). cada uno de ellos con dos posibles estados denominados RECTO y DESVÍO. La locomotora situada en el tramo se desplaza a velocidad lenta en el sentido de las agujas del reloj. La velocidad del tren varía de forma monótona con la tensión de alimentación de la vía. • HIGH_SPEED: se aplican 13. Para que sea posible el control independiente de las dos locomotoras. si se invierte la polaridad de la tensión. C3 y C4 . La locomotora situada en el tramo permanece parada.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 electricamente a través del propio tramo de vía. pero en la aplicación del demostrador las locomotoras solo se mueven en un sentido dentro de cada tramo y solo utilizamos tres valores posibles de alimentación: 9L 9M 7UDPR#L 7UDPR#M • STOPPED: se aplican 0 voltios al tramo. Así mismo. se establece la restricción de que nunca puedan estar ambas en un mismo tramo. mientras que el estado de C3 y C4 va a ser indiferente. • LOW_SPEED: se aplican 7 voltios al tramo. Las locomotoras Ibertren utilizadas admiten un rango de tensión de alimentación desde 0 hasta 15 voltios. ésta saldrá hacia un tramo determinado tal y como se indica en la figura: '(69Ì2 5(&72 Como en la aplicación las locomotoras siempre se van a desplazar en el sentido de las agujas del reloj sólo necesitamos controlar los cruces C1 y C2 . C2 . 77 . CRUCES: C1 . En función del estado y del tramo del que proceda la locomotora .5 voltios al tramo. se invierte el sentido del desplazamiento del tren sobre la vía. La locomotora situada en el tramo se desplaza a velocidad rápida en el sentido de las agujas del reloj. Para ello se ha cableado la maqueta como se muestra en la figura de modo que cada tramo se puede alimentar con una tensión diferente..

Estas zonas se han determinado mediante edición manual de una 1. Por la conectividad que se ha establecido en la maqueta. La manera de pasar a un determinado estado es aplicar en la conexión correspondiente un pulso de 15 voltios de amplitud de una determinada duración. mientras que C2 y C4 son parte del tramo D.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 otra para pasar a RECTO y otra más para pasar al estado DESVÍO. 78 . Tamaño R_4 del tipo Ratio en la interface Image_Grabber. Se han definido varias zonas sobre las vías en las que va a ser de interés detectar la presencia de un tren en ella. en nuestro caso 300 mseg (esto no implica que el cambio se haga efectivo al comienzo o al final del pulso . Ya que nos interesa que la operación de localización sea lo más rápida posible. utilizando para ello una cámara situada sobre la maqueta y una tarjeta de captura y digitalización de imagenes del tipo DT3153 de Data Translation. 2. los cruces C1 y C3 son parte 1 del tramo B . se necesita conocer la posición de las locomotoras dentro de la maqueta. de modo que esta información deberá de ser mantenida por la aplicación software y ser gestionada adecuadamente como variables de estado. pero que sean compatibles con la precisión de localización que se necesita. Como el fondo de la base rígida de la maqueta es básicamente verde . Lo que no disponemos es de información electrónica de retorno que nos indique el estado actual de un cruce. En nuestro caso se utilizan imágenes de 192 por 144 píxels2 ( 27648 píxels en total ). ya que el electroimán es un dispositivo electromecánico). La posición de las locomotoras se detecta mediante visión artificial. debemos trabajar con imágenes con la menor resolución. En cuanto a la alimentación de las locomotoras (desplazamiento). Para poder controlar de forma segura la operación de los trenes en la maqueta. un tren rojo y el otro azul podemos detectar sus posiciones dentro de la imagen mediante análisis del color y determinar si una locomotora está situada en una zona definida previamente.

una por cada tramo. 79 . Estas zonas estan comprendidas dentro de la zona de detección respectiva. Por ello ha sido necesario diseñar e implementar una tarjeta intermedia de relés y cablearla de 1. o si no es así colocar el cruce en el estado adecuado). Hay dos tipos de zonas: • Zonas de detección: se trata de 6 zonas. y en el caso de los tramos B y D coinciden completamente ( debido a su pequeño tamaño ). Estas señales son de baja potencia1 . % $ ( ) & ' =RQD#GH#GHWHFFLyQ =RQD#GH#SHOLJUR El control de la maqueta ( estado de los cruces y alimentación de los tramos ) se realiza utilizando la tarjeta de I/O PCI9111. Cuando se detecte un tren en esta zona se deben tomar una serie de decisiones (parar si el siguiente tramo está ocupado. en concreto 16 de sus salidas digitales. que implican la existencia del tren en el tramo correspondiente. • Zonas de peligro: se trata de 6 zonas. TTL. mientras que los elementos de la maqueta requieren señales de potencia.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 imagen de referencia utilizando una aplicación independiente diseñada para tal fin. Para esta última se ha utilizado una técnica basada en imágenes superpuestas sobre vídeo en vivo ( overlapping ). una por cada tramo. que implican la existencia del tren en una posición cercana a un cruce. También se ha implementado otra aplicación que permite recolocar la posición de la maqueta respecto a la cámara para conseguir que la referencia de las zonas sea válida.

Existe una instancia de esta clase por cada tren que circula en la aplicación. La detección se realiza de forma periódica durante toda la ejecución del programa.B . IV. en ese momento se pone el cruce en la posición adecuada y se pasa la velocidad a HIGH_SPEED. En ella se muestra. Arquitectura software del demostrador El programa Ada 95 que constituye la aplicación se ha construido a partir de dos clases principales: Tr ain Railway • Class Train: Representa el módulo software que controla la circulación de un tren de acuerdo con una ruta que se le ha asignado. Si el siguiente tramo no es accesible se detiene el tren (STOPPED) y se espera hasta que quede libre.2. cada una de las locomotoras debe recorrer una ruta cerrada de forma cíclica durante un determinado número de vueltas. el conjunto de atributos que representan el estado de cada instancia de la clase.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 manera adecuada entre la tarjeta de adquisición I/O y la maqueta para poder efectuar el control. El tren azul inicialmente está situado en una posición central del tramo A y el rojo en una posición central del tramo E de modo que al comenzar la ejecución ambos son detectados en la zona de detección del tramo correpondiente sin ningún problema.D) y al tren rojo el recorrido interno (tramos E . En nuestro caso se le asigna al tren azul el recorrido externo (tramos A . Cuando se detecta que un tren llega a alguna zona de peligro lo primero que se hace es establecer su velocidad a LOW_SPEED. El diseño y cableado de esta tarjeta intermedia de relés se describe detalladamente en el anexo B. su interfaz constituida por el conjunto de procedimientos y funciones con las que el procedimiento principal que constituye la aplicación gestiona la operación de la instancia y el conjunto de clases auxiliares que definen los diferentes tipos de variables utilizados en la clase Train. En la figura de la siguiente página se muestra la descripción UML de la clase Train. Un tramo se considera que queda libre cuando el tren que lo ocupaba llega a su siguiente tramo.3. A continuación se comprueba si el siguiente tramo del recorrido es accesible (no está ocupado) y en ese caso se pone el cruce en la posición adecuada y se pasa la velocidad a HIGH_SPEED.B . • Class Railway: Modela la librería de procedimientos de control de los elementos de la red ferroviaria e inspección de su estado. IV. Funcionalidad de la aplicación En el demostrador.F D). 80 .C .

la documentación que explica la semántica de cada componente. y las posibilidades de interacción con otros componentes que ofrecen. I_Grabber. I_Digital_Adq.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. con sus atributos. I_Image_Statistic e I_Image_Logic_Processing.BLUE_TRAIN <<enu merate d>> Velocity <<enum>> + STOPPED <<enum>> + LOW_ SP EED <<en um>> + HIGH_SP EED Rou te . y el conjunto de clases asociadas para definir los tipos utilizados en ellos. 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.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 La semántica de las diferentes clases está bastante autoexplicada. Dentro de la herramienta UML CASE. I_Configuration_Adq. . secuencia y colaboración que ilustran su funcionalidad. los diagramas de actividad. y el esqueleto del cuerpo de del paquete Ada 95. se han establecido junto a estos diagramas de clases. y en cualquier caso su explicación detallada queda fuera del objeto de esta memoria.id : Rout e_Id . En el diagrama de clases de Railway se indica que la clase Railway hace uso de las interfaces. <<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 . 81 . su interfaz de funciones y procedimientos. ro : Route. y las directivas de generación de código que permiten la generación directa de la especificación del paquete Ada95. en la figura de la siguiente página se muestra el modelo de la clase Railway. I_Image_Mannaging.

TIPOS ----------------------------------------------------------type Sector_Status is (RED_TRAIN.Especificación del paquete Railway_Resources --********************************************************************************* with List_Generic. package Railway_Resources is ---. sec_to_free : Sector. 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 aplicación se incluye a continuación la especificación del paquete Railway_Resources. type Sector is (A_SECTOR.C_SECTOR.EXTERNAL. Id : Train_Id) : Boolean W ait_Sector_Ocupation(sec : Sector.E_SECTOR. subtype Train_Id is Sector_Status range RED_TRAIN.Yo_CROSSWAY).BENT.Y_CROSSWAY. type Crossway is (X_CROSSWAY.BLUE_TRAIN. a través del diagrama de componentes se ha elegido que el código de ambas clases se incluya en un único módulo de código. 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 . type Crossway_State is (STRAIGHT.B_SECTOR.HIGH_SPEED). 82 .D_SECTOR.NO_TRAIN).LOW_SPEED..INTERNAL.RIGHT.Demostrador: CBSE_Railway -.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.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 En este caso. type Route_Id is (LARGE.F_SECTOR).theMonitor : Monitor + + + + + + + + + + + + Initialize() Finalize() Register_Train(tr : Train_Link) Unregister_Train(tr : Train_Link) Set_Power() Set_State(crsswy : Crossway.LEFT). type Velocity is (STOPPED. --********************************************************************************* -. <<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 . Id : Train_Id) W ait_Hazard_Zone(sec : Sector.Xo_CROSSWAY.ads. Id : Train_Id) W ait_Sector_Assign(sec : Sector.BLUE_TRAIN.ANYWAY). st : Crossway_State) Get_State(crsswy : Crossway) : Crossway_State Set_Sector_Assign(sec : Sector.

sec_to_free:Sector. entry Wait_For_Red. procedure Unregister_Train(tr:Train_Link).current:Stage_Id)return Crossway. function Read return Sector_Status. procedure Wait_Hazard_Zone(sec:Sector. function Next_sector(Self:Route.Id:Train_Id).s:Sector)return Stage_Id. entry Free_When_Blue(sector_to_free:Sector). SectorAssign :Railway_Ocupation.st:Crossway_State). type Railway_Ocupation is array(Sector)of Sector_Occ.OPERACIONES------------------------------------------------------. procedure Wait_Sector_Ocupation(sec:Sector. type Train is private. type Train_Link is access Train. entry wait(Train_Id). protected type Sector_Occ is procedure Write(st:Sector_Status).Route procedure Create(Self:in out Route. Start(Self: Train_Link). ---.v: Velocity). function Set_Sector_Assign(sec:Sector.Id:Train_Id). -.current:Stage_Id)return Crossway_State. procedure Finalize. function First_Stage(Self:Route.ro: Route. procedure Set_Power. entry Wait_For_Blue.Id:Train_Id)return Boolean. function Get_State(crsswy:Crossway)return Crossway_State. procedure Write_If_Free(st:Sector_Status. ---.Id:Train_Id).current:Stage_Id)return Sector.Railway procedure Initialize.Train procedure procedure procedure procedure -.Id: Train_Id. function Next_crossway(Self:Route. end Sector_Occ. private value:Sector_Status. procedure Set_State(crsswy:Crossway.current:Stage_Id)return Sector. function Size (Self:Route) return Positive.rounds: Positive). Set_Velocity(Self: Train_Link.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 type Stage_Id is Positive. HZoneOcupation :Railway_Ocupation.Id:Route_Id). entry Write_When_Free(st:Sector_Status).flag:out Boolean). procedure Locate. type Route is private. 83 .VARIABLES DE ESTADO --------------------------------------------CrosswayStates :array(Crossway)of Crossway_State. function Current_sector(Self:Route. procedure Register_Train(tr:Train_Link). entry Free_When_Red(sector_to_free:Sector). Sector_In(Self: Train_Link). Create(Self: Train_Link. procedure Wait_Sector_Assign(sec:Sector. function Next_crossway_State(Self:Route. SectorOcupation:Railway_Ocupation.

task type TrainTask is entry Run(theTrain:Train_Link). with Win32. with Ada. Not_Found : exception. with Win32. with Win32. type TrainTask_Link is access TrainTask. : Positive. procedure Main is trenRojo: Railway_Resources. end Monitor. theDriver : TrainTask_Link:=new TrainTask. record : Route_Id. end record. : Sector_Object_List. task type Monitor is entry Run.Train_Link. rounds : Natural. veloc : Velocity. Route_Error : exception. with Ada. initial_pos: Stage_Id. theMonitor: Monitor.Demostrator: CBSE_Railway -.Winnt. type Train is record id : Train_Id.Text_IO.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 ---. end Railway_Resources. package Sector_Object_List is new List_Generic (Sector).Exceptions. --********************************************************************************* El próximo listado de código muestra el programa principal de la aplicación demostrador que hace uso de los recursos ya definidos. 84 .EXCEPCIONES ----------------------------------------------------Register_error : exception. --********************************************************************************* -. position : Stage_Id. end TrainTask.List. theRoute : Route. type Route is id sector_Lst si end record.Main procedure --********************************************************************************* with Railway_Resources.Winbase. private RegisterTrains: array(Train_Id)of Train_Link.

Text_IO. when Railway_Resources.Skip_Line.Finalize.Railway_Resources.Create(rutaR. exception when Railway_Resources.Put_Line("Pulsa intro cuando se detengan los trenes").Put_Line("Error Register_Error"). Railway_Resources. rutaB.Text_IO.BLUE_TRAIN. Railway_Resources.SetPriorityClass(hProcess.Create(rutaB. b:=Win32. begin hProcess:=Win32. raise. raise.Exceptions.Route. rutaB : Railway_Resources.Put_Line("Pulsa intro para comenzar").Put_Line("Error desconocido"). Railway_Resources.RED_TRAIN.Winnt. rutaR. end Main.Route_Error => Ada.Create(trenAzul.Winbase.Text_IO. Railway_Resources.Text_IO.Railway_Resources.Put_Line("Error Route_Error"). Railway_Resources. 3). rutaR : Railway_Resources. raise. Railway_Resources. Railway_Resources.INTERNAL).Skip_Line. hProcess : Win32.Train_Link. Ada. Ada.Put_Line("Error Not_Found").Text_IO.Text_IO. Railway_Resources.Not_Found => Ada. Railway_Resources. Ada.Text_IO. raise.HANDLE.Register_Error => Ada.Text_IO.Winbase.Put_Line(Ada.Exception_Message(E)).Text_IO. when E:others => Ada.Create(trenRojo.GetCurrentProcess.EXTERNAL). Win32. when Railway_Resources. b : Win32. 3).Start(trenRojo).REALTIME_PRIORITY_CLASS). --********************************************************************************** 85 .Route.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 trenAzul: Railway_Resources. Ada. Ada.Start(trenAzul).BOOL.Winbase.

25) <<obj>> E_Sector = Sector(SecTime =2.4.sever : M AS T_FP_Sc heduling_Serv er(policy = MAST_FP_NonP reemtible(p riority:=1).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.9) <<obj>> B_Sector = Sector(SecTime =1.1. En ambos casos. 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>> .demostrador de un sistema de tiempo real basado en componentes diciembre 2002 IV. bcet = 3. es necesario construir en primer lugar el modelo de las dos clases Train y Railway diseñadas específicamente para construir la aplicación.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>> D_Sector = Sector(SecTime =1. IV.45) <<MAST_FP_Sched_Server>> Locate_Polling <<obj>> policy = Polling_FP(T he_Priority=Monitor_Priority. ss : MAST_Scheduling_Server = Locomotive.4.Min_Priority=1) . Modelo MAST de la clase Railway En la siguiente figura se muestra el modelo MAST de la clase lógica Railway. el modelo se ha formulado como un descriptor <<MAST_component_descr>>. Modelo de los componentes lógicos de la aplicación Para construir el modelo de tiempo real de la aplicación.1E-6.h os t=proc) 86 . que incluye todos los elementos necesarios para construir el modelo de la instancia.4.pwo=0.server) <<obj>> 1 Locomotive <<MAST_Component_Descr>> RTM_Locomotive <<obj>> proc : MA ST_FP_Processor(Max_ Priorit y = 1.45) <<obj>> F_Sector = Sector(SecTime=2.The_Period=0.25) <<obj>> C_Sector = Sector(SecTime =3.Power_Mng(wcet = 16.

demostrador de un sistema de tiempo real basado en componentes

diciembre 2002

El modelo MAST de la clase lógica Railway contiene la siguiente información:

• Identificador: Railway_RT_Model: Identificador que debe utilizarse para declarar un modelo que sea una instancia de este descriptor.

• Parámetros: • <<par>> Monitor_Priority : MAST_Priority: Permite establecer en cada instancia la prioridad en que se ejecuta la tarea que realiza el análisis del estado de la maqueta mediante visión artificial. • <<par>> Image_Size : MAST_Factor: Permite establecer en cada instancia el tamaño en píxels de las imágenes adquiridas para la detección. Son utilizadas para escalar los tirempos de procesado de las imágenes. • <<par>> CrossPulseWidth : MAST_Normalized_Execution_Time = 0.3. Permite establecer en cada instancia del modelo la duración del pulso que debe ser aplicado a los electroimanes de los cruces de vía. Aunque es un tiempo normalizado, se corresponde con un tiempo físico, 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, tambíen declarado en el modelo y que es un 87

demostrador de un sistema de tiempo real basado en componentes

diciembre 2002

MAST_FP_Sched_Server, con politica y prioridad declarada. Modela la tarea en la que se ejecuta el código de evaluación del estado de la maqueta por visión artificial. Ejecuta periodicamente (cada 350 mseg.) las operaciones Locate y Locate_Sector que detecta la posición de los trenes. • <<obj>>Locate_Polling : Polling_Task: Por cada instancia del modelo se intancia un componente del tipo Locate_Polling, tambíen declarado en el modelo y que es un MAST_FP_Sched_Server, con politica de planificación del tipo Polling_FP. La tarea Polling_Task es una tarea periódica 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 detección se realiza cada 350 mseg. En esta tarea se ejecuta la operación Wait_Hazard_Zone , que tiene duración nula ya que se trata simplemente de una espera hasta que el resultado de la detección 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 exclusión mútua al hardware que controla los cruces de vías 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 parámetro SecTime que indica el tiempo en segundos que tarda un tren (suponemos que el tren rojo y el azul son idénticos y por tanto tardan lo mismo) en recorrer el sector si no se detiene nunca (en nuestro caso se midió con un sólo tren recorriendo todos los sectores de la maqueta). La operación Run representa la acción de recorrer todo el sector a velocidad HIGH_SPEED, de modo que sus tiempos (wcet y bcet) son iguales al parámetro 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 determinación 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 ejecución de una operacion de duración nula (MAST_NOP) en el scheduling server LocatePolling que tiene una política de planificación del tipo Polling_FP.

Locate_Polling

W ait_Hazard_Zone do/ MAST_NOP

88

demostrador de un sistema de tiempo real basado en componentes

diciembre 2002

• <<job>> + Set_Velocity():modela la asignación de las tensiones a los distintos tramos en función 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 posición de las locomotoras sobre la vía. Se describe mediante el siguiente diagrama de actividad

89

demostrador de un sistema de tiempo real basado en componentes diciembre 2002 : Act_1 do/ grabber.0) Act_4 do/ Img_Transforming.Import(Time_Factor=1. en nuestro caso con los siguientes umbrales de detección: 90 .Read(imgSize=imageSize) Act_3 do/ Img_Managing.Color_Detec(Time_Factor=1.Acquire Act_2 do/ grabber. se importa a un formato propio del componente de análisis de imagen y se detectan los trenes ( colores rojo y azul ) utilizando la operación Color_Detec.0) Act_5 do/ Locate_Sector(ImgSize=ImageSize) Act_6 do/ Locate_Sector(ImgSize=ImageSize) Act_7 do/ Locate_Sector(ImgSize=ImageSize) Act_8 do/ Locate_Sector(ImgSize=ImageSize) Act_9 do/ Locate_Sector(ImgSize=ImageSize) Act_10 do/ Locate_Sector(ImgSize=ImageSize) <<Timed_State>> End Se adquiere la imagen .

0) do/ Img_Statistic.0) do/ Img_Statist ic.0) Act_10 do/ Img_Logical_Processing. descrita mediante el siguiente diagrama de actividad: Act_8 do/ Img_Logical_Processing. y si no lo supera suponemos que es negativa.demostrador de un sistema de tiempo real basado en componentes 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 operación Locate_Sector .8E-6): Modela las operaciones de gestión para determinar las posiciones de los relés de la tarjeta intermedia de control en función de las tensiones necesarias en los distintos tramos y se describe como una operación <<simple>>.Logical_And(Time_Factor=1.1E-6.Logic _And(Time_Factor=1. 1.Logic_And(Time_Factor=1.0) do/ Img_Stat ist ic.Count _Non_Zero(Time_Fac tor=1. • <<simple>> .Power_Mng(wcet = 16. Ver anexo B. 91 .Logic _And(Time_Factor=1. bcet = 3. Si este número supera un umbral ( en nuestro caso es de 8 píxels ) suponemos que la detección es positiva .0) Se repite cuatro veces ( para las zonas de detección y peligro del sector para el tren rojo y el azul ) la siguiente operación: se ejecuta una operación lógica And entre el resultado del análisis de color y la máscara de la zona correspondiente ( almacenada en memoria en la inicialización de la aplicación ) y se cuenta el número de píxels blancos de la imagen obtenida. Count_Non_Zero(Time_Fact or=1.0) do/ Img_Stat ist ic. Las dos primeras escrituras digitales determinan las dos tensiones necesarias ( T1 y T2 ) y las seis siguientes las asignan a los seis tramos adecuadamente1.0) Act_12 do/ Img_Logical_Processing.0) Act_14 do/ Img_Logical_Processing.Count _Non_Zero(Time_Fac tor=1.Count_Non_Zero(Time_Factor=1.

< < 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.4. • Parámetros: • <<par>> Train_Priority : MAST_Priority: A través de este parámetro se puede asignar a cada instancia del modelo. Modelo MAST de la clase Train En la siguiente figura se muestra el modelo MAST de la clase lógica Train. 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 lógica Train contiene la siguiente información: • Identificador: Train_RT_Model:Identificador que debe utilizarse para declarar un modelo que sea una instancia de este descriptor. Haz ar d_S top : Tim ed_S tate) Run_E x ternal(hz S top : Tim ed_S tate. • Objetos: 92 . • Referencias: • theRailway : Railway_RT_Model: Referencia al modelo del objeto de la clase Railway que proporciona los recursos que requiere el movimiento del tren. la prioridad de la tarea en que se se ejecuta el código de control de la locomotora. end : Tim ed_S tate) Run_Internal(hz S top : Tim ed_S tate.2.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 IV.

se detiene el tren ( velocidad a STOPPED ) hasta que sea accesible1.Set_Velocity <<MAST_Timed_State>> Hazard_Stop Act_4 do/ theRailway.Wait_Hazard_Zone Act_2 do/ theRailway. Representa el scheduling server auxiliar para ejecutar las operaciones de recorrer tramos en el processing resource theEngine. Cuando llega se pasa la velocidad a LOW_SPEED.Set_State Act_5 do/ theRailway.demostrador de un sistema de tiempo real basado en componentes 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 política preemtible.Run En primer lugar el sistema se queda en espera hasta que el tren llega a la zona de peligro. A continuación . si el siguiente tramo no es accesible . • 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. • <<obj>> theLocomotive : MAST_FP_Sched_Server(host = theEngine). 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>> theEngine : MAST_Device: Modela a la locomotora física.Set_Velocity Act_6 do/ the_Sector. en el que se ejecuta el código de control del tren. capaz de recorrer sucesivamente sectores de acuerdo con su ruta.Set_Velocity Act_3 do/ theRailway. Cuando ya sea accesible se coloca el cruce correpondiente en la 93 .

Al ser el primer paso de sector no es necesario . • <<job>> + Run_First_Sector(the_Sector : Sector. Como es lógico . cuya posición no es relevante teniendo en cuenta el sentido de la marcha. Esta actividad aparece en el modelo ya que deseamos analizar el peor caso.tramo B ) se pasa por el cruce C3 . y actualmente la herramienta MAST de análisis no permite aplicar restricciones temporales en estos casos.Wait_Hazard_Zone Act_2 do/ theRailway .B para el recorrido interno ). 94 . vamos a aplicar una restricción temporal en un estado interno de la operación. Hazard_Stop : Timed_State):es un caso particular de la anterior que modela el primer paso de sector ( A .tramo B ) como para el interior ( tramo F .Set_Velocity Act_3 do/ theRailway . De ahí que se ha modelado la operación Run_First_Sector .B para el recorrido externo o E . su diagrama de actividad es muy similar: Act_1 do/ theRailway . se pasa a velocidad HIGH_SPEED y se comienza a recorrer el siguiente tramo. ya que tanto para el recorrido exterior ( tramo A . con el propósito de aplicarle una restricción temporal para el análisis de peor caso.Set_Velocity Act_5 do/ the_Sector.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 posición adecuada .Set_Velocity <<MAST_Timed_State>> Hazard_Stop Act_4 do/ theRailway . como veremos posteriormente .Run La única diferencia con el anterior es que en esta ocasión no aparece la actividad Set_State para fijar el estado del cruce. En otros cruces en los que es necesario actuar sobre el cruce es necesario tomar un recurso del sistema ( el semáforo del propio cruce ) . 1. Se ha modelado en otra operación ya que .

end : Timed_State): Modela el recorrido exterior ( tramos A .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 .B .demostrador de un sistema de tiempo real basado en componentes diciembre 2002 • <<job>> + Run_External(hzStop : Timed_State. end : Timed_State): Modela el recorrido interior ( tramos E .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.F .C .B .D ) y se describe con el siguiente tramo de actividad: Act_1 do/ Run_First_Sector(the_Sector=B_Sector.

se han introducido dos nuevos requerimientos de tiempo real. la locomotora debe parar. pero dada la simetría de la situación. la locomotora debe parar.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 IV. Para describir el modelo de una situación de tiempo real. y justamente cuando se encuentran entrando en la zona de peligro de acceso al cruce C3. la locomotora debe parar. 2) y 4). que no son propios de la maqueta. _ 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. es necesario describir: 96 . Estos requerimientos son: • La locomotora BLUE_TRAIN debe completar una ciclo completo de su ruta antes de que transcurran 17 s. En el modelo de las situaciones de tiempo real de la aplicación que estamos considerando. si el tramo B estuviera ocupado. Modelo de las situaciones de tiempo real de la aplicación La situación de tiempo real Railway_Operation que se ha analizado a través del modelo de tiempo real corresponde a la operación 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. _ 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. En la situación de tiempo real que se considera.5. los requerimientos 2) y 3) así como los requerimientos 4) y 5) son equivalentes. si el tramo D estuviera ocupado. En la maqueta existen cinco requerimientos de tiempo estricto que deben ser considerados: _ 1) Se requiere que cada 350 ms se realice una evaluación por visión artificial del estado de la maqueta. 1). la locomotora debe parar. y en consecuencia. si el tramo B estuviera ocupado. A fin de poder modelar y analizar todos los requerimientos temporal con las herramientas que actualmente se dispone. si el tramo D estuviera ocupado. que se finalice la evaluación antes de que se inicie el siguiente ciclo. • La locomotora RED_TRAIN debe completar una ciclo completo de su ruta antes de que transcurran 15 s. se considera la condición inicialcuando los dos trenes se encuentran respectivamente en los sectores A y E. _ 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. _ 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. sino que solo se introducen a fin de obtener información del análisis.

los eventos externos que las disparan y los requerimientos de tiempo real que incluyen.I_Im age_Grabber Img_Managing = The_V ision_library. la declaración de todas las instancias de componente que participan en ella.I_Digital_Adq digitalActive = The_IOCard. mdl) ImageSiz e = 27648.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 • La configuración del sistema: Esto es.5.ceiling = 23 digital = The_IOCard. se muestra los elementos básicos que constituyen la declaración de <<MAST_RT_Situation>> Railway_Operation.I_Digital_Adq_Active grabber = The_Grabber. Configuración de la RT_Situation En el siguiente diagrama de clases. I_Im g_Transform ing Img_Logic al_Proc = The_Vision_library. incluyendo en ellas.0 host host host host host host <<MAST_Component_Inst>> NT_Processor_Mdl_1:theProcessor place = MAST_Platform_View 97 . IV.mdl) <<par>> Digital_Priority = 23 <<MAST_Component Instance>> RTM_C_Im age_Grabber: The_Grabber place = M AST_Filec(path = c:\Sauce\Cap. <<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.mdl) <<MAST_Component Instance>> RTM_C_IO_Card_9111:The_IOCard place = MAST_File(path = c:\Sauce\Adq.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.I_Img_Managing Img_Transforming = The_Vision_library. • El conjunto de transacciones que concurren en ellas.0 t heCrossW ayLock.1. I_Im g_Logical_Proces sing Img_Statist ic = The_Vision_library.

•place = MAST_Logical_ViewLocatización del descriptor de la instancia. y las referencias a otras instancias también declaradas en ella que eran requeridas en los correspondientes descriptores.I_Img_Statistic • <<MAST_Componet_Inst>>Train_RT_Model: Blue_Train: que modela el software de control de la locomotora Blue.0 Tamaño de las imágenes que se procesan. •Image_Size = 27648. •place = MAST_Logical_ViewLocatización del descriptor de la instancia.I_Image_Grabber •Img_Managing = The_Vision_library. Los valores y referencias establecidas en la instancia son: 98 . y en ellas se han explicitado los valores concretos de los parámetros que se asignan a cada una de las instancias. •theCrossWayLock.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 En esta RT_Situation se han declarado seis instancias de componentes.I_Digital_Adq •grabber = The_Grabber. • <<MAST_Component_Inst>>Railway_RT_Model: Simple_Railway: que modela la librería de recursos de control y supervisión de la maqueta que se utiliza.I_Img_Managing •Img_Transforming = The_Vision_library. Los valores y referencias establecidas en la instancia son: Parámetros: •host=theProcessor Procesador en el que se instala el componente. 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: Parámetros: •host=theProcessor Procesador en el que se instala el componente. •Monitor_Priority = 25 Prioridad de la tarea de visión artificial. •Train_Priority = 23 Prioridad de la tarea de control de la locomotora. Referencias: •digital = The_IOCard.ceiling = 23Techo de prioridad de los semáforos de los cruces.I_Img_Logical_Processing •Img_Statistic = The_Vision_library.I_Img_Transforming •Img_Logical_Proc = The_Vision_library.

•place = MAST_File(path = c:\Sauce\Adq. •ImageSize = 27648. Referencias: • theRailway = Simple_Railway • <<MAST_Componet_Inst>>RTM_C_Ada_Vision: The_Vision_Library: Modela la instancia del componente C_Ada_Vision. Los valores y referencias establecidas en la instancia son: Parámetros: •host=theProcessor Procesador en el que se instala el componente. que se requiere en las operaciones de visión artificial Los valores y referencias establecidas en la instancia son: Parámetros: •host=theProcessor Procesador en el que se instala el componente. que se utiliza para implementar la interfaz I_Image_Grabber. Los valores y referencias establecidas en la instancia son: Parámetros: •host=theProcessor Procesador en el que se instala el componente. •Digital_Priority = 23 Prioridad del semáforo de acceso a los cruces. •Train_Priority = 23 Prioridad de la tarea de control de la locomotora. • <<MAST_Componet_Inst>>RTM_C_Image_Grabber: The_Grabber:Modela la instancia del componente C_IG_DT3153. •place = MAST_Filec(path = c:\Sauce\Cap.mdl). que se requiere en las operaciones de control del hardware de la maqueta. que se utiliza para implementar las interfaces I_Img_Managing.0 Tamaño de las imágenes que se capturan. •place = MAST_File(path = c:\Mast\Component\Sauce\Vis.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 Parámetros: •host=theProcessor Procesador en el que se instala el componente. que se requiere en las operaciones de captura y digitalización de las imágenes de vídeo. I_Img_Transforming. que se utiliza para implementar la interfaz I_Digital_Adq.mdl) • <<MAST_Componet_Inst>>RTM_C_IO_Card_9111: The_IOCard: Modela la instancia del componente C_IO_Card_9111.mdl) 99 . •place = MAST_Logical_ViewLocatización del descriptor de la instancia. I_Img_Logical_Processing y I_Img_Statistic.

100 .0 <<MAST_Component_Declr>> MAST_Hard_Global_Deadline:Red_Hazard_Stop deadline = 0.2. <<MAST_Component_Inst>> MAST_Regular_Transaction:Locate_Transaction <<MAST_Component_Inst>> MAST_Hard_Global_Dealine:Locate_End deadline = 0. _ Requerimiento temporal: MAST_Hard_Global_Dealine : Locate_End: Se requiere que debe alcanzarse el estado Locate_End.0 ref erenced <<MAST_Component_Inst>> MAST_Periodic_Ev ent_Source:Red_Exit period = 15. antes del inicio del siguiente periodo.0 <<MAST_Com pone nt_In st>> MAST_ Ha rd_G lob al_ De adl ine:Bl ue_ Hazard _Stop deadline = 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.5. Declaración de las transacciones En el siguiente diagrama de clases.7 ref erenced <<MAST_ Co mpon ent_ Inst>> MAST_ Periodic_ Ev ent_So urce :Blue_ Exit period = 17.7 ref erenced • MAST_Regular_Transaction: Locate_Transaction: Corresponde al proceso de localización se realiza periódicamente y que debe acabar dentro del periodo.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 IV. se describen las tres transacciones que concurren en la <<MAST_RT_Situation>>Railway_Operation.0 ref erenced <<MAST_Component_Inst>> MAST_Regular_Transaction:Red_Train_Transaction <<MAST_Component_Inst>> MAST_Hard_Global_Deadline:Red_End deadline = 15. _ Trigger: MAST_Periodic_Event_Source: Locate_Trigger: Patrón de generación periódico con periodo de 350 ms.35 ref erenced <<MAST_Component_Inst>> MAST_Periodic_Ev ent_Source:Locate_Trigger period = 0.

_ 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 .demostrador de un sistema de tiempo real basado en componentes 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 . _ 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.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: Patrón de generación periódico con periodo de 17 s. e n d = B lu e _ E n d ) 101 . 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 . _ MAST_Hard_Global_Deadline: Blue_End: Se requiere que la locomotora de una vuelta completa antes de 17 s. que corresponde con el inicio de cada vuelta de la locomotora BLUE_TRAIN.

_ Actividad:Se describe en el siguiente diagrama de actividad. _ 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. _ Trigger: MAST_Periodic_Event_Source: Red_Exit: Patrón de generación periódico con periodo de 15 s. < < W ait_S tate> > Re d_E x it Act do/ Red_Train. pero en al no existir actualmente la herramienta que compile el modelo CBSE_Mast al fichero MAST_File. ya que los tiempos resultantes del análisis son: WCET = 318.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 • MAST_Regular_Transaction: Red_Train_Transaction: Corresponde al proceso decontrol de la locomotora RED_TRAIN a lo largo de su ruta interna.Run_Internal(hz S top= Red_Haz ard_S top.end= Red_E nd) IV.6. En un futuro sería interesante automatizar la generación de este fichero a partir del modelo UML. Los resultados más relevantes que se han obtenido son: La restricción de tiempo de la localización ( 350 mseg. se ha hecho la compilación manualmente. Análisis de tiempo real de la aplicación Una vez definido el modelo completo de la RT_Situation.9 mseg. 102 . que corresponde con el inicio de cada vuelta de la locomotora RED_TRAIN. se ha generado un fichero MAST_File que describe el modelo en un formato interpretable con las herramientas de análisis que nos va a analizar si el sistema es planificable y si se pueden cumplir las restricciones fijadas. _ MAST_Hard_Global_Deadline: Red_End: Se requiere que la locomotora de una vuelta completa antes de 15 s. ) se cumple sobradamente .

De hecho . 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 .25 = 10.25 = 7. Ver modelo del Railway : 2. no tenemos la seguridad de que el sistema funcione en el 100 % de las ocasiones. BCET = 8. 103 . BCET = 0. Esto es debido a que el tiempo medio es bastante menor que el WCET.demostrador de un sistema de tiempo real basado en componentes diciembre 2002 BCET = 162.74 seg.84 seg. ya que los resultados son: WCET = 13.17 mseg.25 + 3.6 mseg. La restricción de tiempo de detención ( 700 mseg. Sin embargo .8 mseg. Como era de esperar . el tiempo de mejor caso es ligeramente superior a la suma de los tiempos de los tramos que recorre2. Ver modelo del Railway : 3. 2. ya que se ejecuta continuamente la tarea de localización ( más prioritaria ) y nunca llegan a tener el control de la CPU las tareas de los trenes. ) también se cumple . y se cumple sobradamente. La restricción de tiempo de vuelta para el tren azul ( 17 seg.4 seg.9 + 1. Esto quiere decir que aún podríamos haber bajado más el periodo de la tarea de localización.45 + 1. ) es idéntica para ambos trenes .45 + 1. ) también se cumple .3 seg. 1.20 seg.9 + 1. La restricción de tiempo de vuelta para el tren rojo ( 15 seg. Como era de esperar .30 seg. el tiempo de mejor caso es ligeramente superior a la suma de los tiempos de los tramos que recorre1. Se cumple sobradamennte para el peor caso ( WCET ). Los resultados obtenidos son: WCET = 583. ya que los resultados son: WCET = 16. BCET = 11. en la práctica el sistema funciona para valores del periodo inferiores a 300 mseg.25 + 2.

.6.7. • Se ha de plantear la posibilidad de que los componentes ofrezcan procedimientos para recalcular los valores de los parámetros de su modelo de tiempo real al cambiar de una plataforma a otra. lo que hace que sea especialmente interesante desarrollar la metodología de desarrollo basado en componentes utilizando dicho lenguaje en este campo concreto. A pesar de tratarse de un lenguaje no demasiado utilizado en aplicaciones de propósito general .conclusiones diciembre 2002 V. si está bastante implantado en el campo de las aplicaciones de tiempo real . ). 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 operación Acquire del componente C_IG_DT3153 ).4. ). y durante el desarrollo de los mismos se han obtenido interesantes conclusiones. 104 .5 y III. • Se han de evaluar metodologías estadísticas que nos permitan estimar con precisión las medidas temporales ( BCET . • Se han de desarrollar herramientas que generen automáticamente el código MASTFile de los componentes ( apartados III. ACET y WCET ) de los modelos de tiempo real de los componentes. CONCLUSIONES Se han cubierto practicamente en su totalidad los objetivo del proyecto planteados en el apartado I. Se ha comprobado la eficiencia del lenguaje de programación Ada 95 para para la implementación de componentes software. Tras el desarrollo del presente trabajo se plantean varias líneas abiertas de trabajo para un futuro próximo: • Se han de desarrollar herramientas que generen automáticamente el código Ada 95 de las interfaces y los componentes a partir de sus respectivas descripciones UML ( apartado II.

C.M. y Drake J. Components and Frame-works in UML: the Catalysis approach”.J. [3] Cameron A.F. [9] D’Souza D. [2] Medina J.: “Objects. [13] González M.microsoft. y Noström C..M.trireme. [12] Lüders F.: “Object-Oriented Software Development Made Simple with COM+ Runtime Services” Noviembre 1997. Gutierrez J. 2001. [15] Medina J.org/corba/beginners. 2001. 2001..com [4] Kirtland M.L. [7] Drake J.M.J. González M. 1998. Palencia J.: “Overview of CORBA” at http://cgi. 2002. Distributed and Real-Time Application with UML”. Medina J. Cartagena . Jaca 2002.L.: “Component Software: Beyond Object-Oriented Programming” AddisonWesley." Ada Europe. RTSS. y Drake J.: “Modelado y Análisis de Tiempo Real de Aplicaciones Basadas en Componentes” V Jornadas de Tiempo Real. González M. y González M.:" "MAST Real-time View: A Graphic UML Tool for Modeling Object_Oriented Real_Time Systems".M.L. Microsoft Systems Journal at http://www. http://www. December. Addison-Wesley.: "MAST: Modeling and Analysis Suite for Real-Time Applications" Proceedings of the Euromicro Conference on RealTime Systems. 1999. 2002 105 .M. y Drake J. . y Drake J. REFERENCIAS [1] Szyperski C.: “Components in Real-Time Systems” RTCSA’2002 Tokyo. y Cameron A.com/com.:"Modeling ans Schedulability Analysis of Hard Real-Time Distributed Systems based on ADA Componentes.: “Designing Component Kits and Archiquctures with Catalysis” TriReme International Ltd.2000. y Daniels J. [8] Cheesman J. 2000.: “Entorno para el diseño de sistemas basados en componentes de tiempo real” X Jornadas de Concurrencia .referencias diciembre 2002 VI.: “Experiences with Component-Based Sofware Development in Industrial Control” Mälardalen Real-Time Research Center . Addison-Wesley.omg.html [6] Baker S. [11] Isovic D.. [5] Schmidt D.: “UML Components: A simple Process for Specifying Component-Based Software”. [14] Medina J.: “CORBA Distributed Objects” Addison-Wesley 1997.. Gutiérrez J.L.. [10] Hassan Gomaa: “Designing Concurrent. June 2001. y Crnkovic I. Addison-Wesley. “White Papers”.

0” Grupo Computadores y Tiempo Real . [17] Medina J.: “CBSE_MAST_Concepts”Grupo Computadores y Tiempo Real .1998.referencias diciembre 2002 [16] Kobryn C.: “Modeling Components and frameworks with UML. Octubre 2002.” Communications of the ACM . Medina J.L.: “UML MAST Metamodel 1. 106 .. Microsoft Press .: “Inside Windows NT” Second Edition. Universidad de Cantabria [18] ------: ”Intel Image Processing Library: Reference Manual” Intel Corporation. Order Num. 1998.” Tesis Doctoral (en preparación). Nº 10.com [20] Timmerman M. [21] Solomon D.intel.com [19] ------: ”Open Source Computer Vision Library: Reference Manual” Intel Corporation. [23] Drake J. [22] Drake J. http://developer. Febrero 1997. Universidad de Cantabria .intel.L. Octubre 2000/Vol.:TBD. 2000.M.:663791-002.: “Windows NT as Real-Time OS?” Real-Time Magazine .M. Febrero 2001. Order Num. 43 . http://developer. Universidad de Cantabria .: “Metodología y herramientas UML para el modelado y análisis de sistemas orientados a objetos de tiempo real.

128 Open_Card(n : Natural) : Video_Card Close_Card(c : Video_Card) Start_Video(c : Video_Card. 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.Componente C_IG_DT3153 Especificación 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.. hwnd : HWND.255. f : Frame. p : Param.N_CHANNELS-1 <<exception>> Read_Error <<exception>> Passthru_Error <<ex ception>> Acquisition_Error <<enumerate.. y : Natural) Stop_Video(c : Video_Card) Acquire(c : Video_Card) Snap(c : Video_Card) Read(c : Video_Card.254 Hue_Values : Param_Value = 0.180 U_Sat_Values : Param_Value = 0.255.511. x : Natural. 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 .163 Contrast_Values : Param_Value = 0. ch : Channels) Get_Parameter(c : Video_Card. ch : Channels) Set_Parameter(c : Video_Card. data : in out PixelData) Draw_Image(c : Video_Card.256 V_Sat_Values : Param_Value = 0.especificación de los componentes diciembre 2002 Apéndice A: ESPECIFICACIÓN DE LOS COMPONENTES A..1. p : Param. hwnd : HWND) Set_Channel(c : Video_Card.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. value : Integer.511.511..

i : out Image) Image_To_Matrix(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. iB : out Image) Matrix_To_Image(m : Integer_Matrix.Componente C_Ada_Vision Especificación funcional.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 <>. iG : Image. iB : Image. 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. i2 : Image) Gray_To_RGB(igray : Image. iRGB : out Image) RGB_To_Gray(iRGB : Image. iR : out Image. iG : out Image.2. iRGB : out Image) RGB_To_Channels(iRGB : Image.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 . height : Positive.especificación de los componentes diciembre 2002 A. color : Color_Type) : Image Load_BMP(path : String) : Image Save_BMP(i : Image. igray : out Image) Channels_To_RGB(iR : 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 <>.

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>> Unsuitable_Operation (from I_Enviroment) <<exception>> Op_Not_Support (from I_Enviroment) <<exception>> Library_Error (from Image_Managing) 109 . dir : Direction) Mov e_To(c : Cursor. v : Value. src2 : Image. src2 : Image. dir : Direction) Mov e_Wrap(c : Cursor. dst : out Image) Logic_Or(src : Image. dst : out Image) Logic_Or(src1 : Image. dst : out Image) Logic_And(src1 : Image. p : Pixel) Get_Pixel(c : Cursor) : Value Get_Pixel(c : Cursor) : RGB_Value Put_Pixel(c : Cursor. v : Value. 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.especificación de los componentes 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. dst : out Image) Logic_And(src : Image. v : Value) Put_Pixel(c : Cursor.

dst : out Image) Erode(src : Image. level : Natural. v : Value. angle : float. dst : out Image. c_row : Natural. dst : out Image. n : Positive) Dilate(src : Image. min : Value. n : Positive) Open(src : Image. dst : out Image) Multiply(src1 : Image. c_col : Natural. 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) ) <<exception>> Unsuitable_Operation (from I_Enviroment) Interface I_Img_Transforming: <<type>> Integer_Matrix array (n atural range < >. dst : out Image. src2 : Image. dst : out Image.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. n : Positive) Filter(src : Image. thres : Value) BOTH_AXIS : enum Eq_Histogram(src : Image. dst : out Image) Subtract(v : Value. dst : out Image) Subtract(src1 : Image.especificación de los componentes diciembre 2002 Interface I_Img_Arith_Processing: <<Interface>> I_Img_Arith_Processing Add(src1 : Image. src2 : Image. shift : Natural) <<enu merate d>> Median _Filter(dst : out Image. n : Positive) HOR_AXIS : enum Threshold(src : Image. dst : out Image. n : Positive) VER_AXIS : enum Max_Filter(src : Image. v : Value. v : Value. dst : out Image. axis : Symmetry_Axis) FFT(src : Image) : Integer_Matrix Inverse_FFT (data : Integer_Matrix. dst : out Image. dst : out Image. dst : out Image) Add(src : Image. src2 : Image. dst : out Image. link_thres : Value. dst : out Image. src : Image. int_met : Interpolation_Method) INTE R_LINE AR : e num INTE R_CUB IC : en um Mirror(src : Image. n : Positive) Symmetry_Axis Min_Filter(src : Image. 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 . sobel_order : Positive. dst : out Image) Multiply(src : Image. xShift : Natural. kernel : Integer_Matrix. dst : out Image) Border(src : Image. int_met : Interpolation_Method) Rotate(src : Image. dst : out Image) DCT(src : Image) : Integer_Matrix Inverse_DCT(data : Integer_Matrix. dst : out Image. n : Positive) Close(src : Image. max : Value) Segmentation(src : Image. src : Image. dst : out Image) Subtract(src : Image. yShift : Natural. dst : out Image. dst : out Image.

n : out Natural. min : out Value. n : Natural) : Float Spatial_Moment(i : Image. max : out Value. template : Image.. p_max : Natural.49) of Pixel <<type>> Float_Matrix array (natural range <>. m : Natural. pos : out Pixel) Max_Location(i : Image.natural range<>) of float <<private_type>> Image (from Image_Managing) <<type>> Pixel <<Interface>> I_Img_Analysis Fi t_Line(src : Image. n : Natural) : Float <<private_type>> Ima ge (from Image_Managing) <<type>> P ixel x : Natural y : Natural <<exception>> Unknown_Error (from I_Enviroment) <<exception>> Library_Error (from Image_Managing) <<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. m : Natural. mean : out Float. nptos : Integer_Array) x : Natural y : Natural <<type>> Integer_Array array (natural range<>) of integer <<exception>> Op_Not_Support (from I_Enviroment) <<exception>> Unknown_Error (from I_Enviroment) <<exception>> Unsuitable_Operation (from I_Enviroment) <<exception>> CB_Not_Detected <<exception>> Value_Out_Of_Range (from I_Enviroment) <<exception>> Library_Error (from Image_Managing) 111 . std_dev : out Float) Min_Location(i : Image. p_max : Natural. pos : out Pixel) Central_Moment(i : Image. dst : out Image. p_min : Natural. dir_y : out Positive) Fi t_Ellipse(s rc : Image) : Ellipse_Param Match_Template(src : Image. met : Matching_Method) : Float_Matrix Di stance_Transform(src : Image) : Float_Matrix Chessboard_Corners (src : Image) : Corners Boundary(src : Image. dir_x : out Posi tive. n : out Natural. ref_point : out Pixel. nptos : Integer_Array) Boundary(src : Image.especificación de los componentes diciembre 2002 Interface I_Img_Statistic: <<Interface>> I_Img_Statistic Count_Non_Zero(i : Image) : Natural Sum_Pixels(i : Image) : Natural Mean(i : Image. p_min : Natural.

center : Pixel. radius : Natural. Gray : Value) Text(src : Image. thick : Natural. Gray : Value) Elip_Arc(src : Image. seed_point : Pixel. p1 : Pixel. low_dif : Value. thick : Natural. thick : Natural. center : Pixel. Gray : Value) Fill_Poly(src : Image. p2 : Pixel. RGB : RGB_Value) Circle(src : Image. RGB : RGB_Value) Text(src : Image. thick : Natural. Gray : Value) Circunference(src : Image. radius : Natural. r : Rectangle. t : String. r : Rectangle. radius : Natural. RGB : RGB_Value) Rectangle(src : Image. Gray : Value) Line(src : Image. n : Positive. thick : Natural. thick : Natural. RGB : RGB_Value) Poly(src : Image. max_width : Natural. arc_p : Arc_Param. Gray : Value) Rectangle(src : Image. RGB : RGB_Value) Line(src : Image. radius : Natural. thick : Natural. thick : Natural. center : Pixel. RGB : RGB_Value) Elip_Arc(src : Image. arc_p : Arc_Param. p2 : Pixel. max_width : Natural. p1 : Pixel. height : Natural. n : Positive. RGB : RGB_Value) Fill_Poly(src : Image. pol : Polygonal. center : Pixel. n : Positive. 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 <<exception>> Op_Not_Support (from I_Enviroment) 112 . n : Positive. pol : Polygonal.especificación de los componentes diciembre 2002 Interface I_Img_Draw: <<In te rface>> I_Img_Draw Circle(src : Image. Gray : Value) Flood_Fill(src : Image. height : Natural. pol : Polygonal. val : Value. thick : Natural. Gray : Value) Poly(src : Image. thick : Natural. thick : Natural. t : String. pol : Polygonal. thick : Natural. RGB : RGB_Value) Circunference(src : Image.

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 .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.especificación de los componentes diciembre 2002 A.0 AO_M AX_CARD : Voltag e = 10. If : Input_Line_Id) : Input_Port_Id Define_Output_Port(li : Output_Line_Id. g : Gain) : Code AI_Voltag e(c : Code.3.0 AI_M AX_CARD : Voltag e = 10.Componente C_PCI9111 Especificación funcional.0 AI_BUFFER_SIZE : Natural = 1024 AI_RESOLUTION : Natural = 12 AI_NUM _CHANNELS : Natural = 16 AO_M IN_CARD : Voltag e = -10. < < 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_RATE : Samplig _rate = 110000. 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.

ch : Input_Channel_Id. Value : Voltage. Buff : Signal_Buffer ) Set_Signal Transfer(sgtr : Signal _Transfer_mode) Get_Continuous_Sampling (c : Card) Channel_F or_Continuous_Sampl ing(c : Card. Buff : Signal_Buffer) Aw ait_Value(c : Card. ch : Input_Channel_Id) : Voltage AI_Read(c : Card. 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 : Output_Channel_Id. 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>> Unknown_Error (from I_Enviroment) <<exception>> Value_Out_Of_Range ( from I_Env iroment) 114 . ch : Output_Channel_Id.especificación de los componentes 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. g : Gain) : Code AO_Write(c : Card. ch : Channnel_Id. v : Voltage) AO_Write(c : Card. ch : Input_Channel_Id) : Code AI_Read(c : Card. g : Gain) : Voltage AI_Read(c : Card. ch : Input_Channel_Id. ch : Input_C hannel_Id. ch : Input_Channel_Id.

ln : Output_Line_Id. v : Code) Generate_Pulse(c : Card. ln : Output_Line_Id. In : Input_Line_Id) Await_To_T rue(c : Card. p : Input_Port_Id. ln : Input_Line_Id) Await_Change_T o_False(c : Card. ln : Ou tp ut _L ine_ Id) : Bo ol ea n DO _Write (c : Card. v : Code) Await_Port_Exit(c : Card. duration : T ime. p : Outp ut _P ort_Id) : Co de DO _Write _P ort(c : Ca rd . valu e : B oole an ) DO _Re ad _P ort(c : Ca rd . 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 <<exception>> Op_Not_Support (from I_Enviroment) <<exception>> Unknown_Error (from I_Enviroment) <<exception>> Value_Out_Of_Range (from I_Enviroment) 115 . p : Input_Port_Id.especificación de los componentes 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. v : Code) Await_Port_Not_State(c : Card. p : Ou tp ut _P ort_Id. st : Boolean) Generate_Blinking(c : Card. p : Input_Port_Id. p : Input_Port_Id. ln : Input_Line_Id) Await_To_False(c : Card. v : Code) Await_Port_State(c : Card. ln : Ou tp ut _L ine_Id. <<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. p : I np ut _Port_I d) : Code DO _Re ad (c : Card. v : Cod e) <<private_type>> Output_Port_Id (from Adq_Config) <<type>> Code c : Natural <<exception>> Unknown_Error (from I_Enviroment) <<exception>> Op_No t_Su pp ort (from I_Enviroment) <<exception>> Value_Out_Of_Range (from I_Enviroment) Interface I_Active_Digital_Adq:. ln : Input_Line_Id) Await_Port_Arrival(c : Card. ln : I nput _Line _Id) : Bo ol ean DI _Rea d_ Port (c : Card.

La tarjeta de interfase consiste en la réplica ( 16 veces ) del siguiente circuito que permite controlar los relés con niveles TTL: 15 V 180 Ω “1” R elé i C IN “1” C “0” 560 Ω IN BC107 “0” Cuando en el terminal IN tenemos un “0” lógico TTL el terminal C está cortocircuitado con el terminal “0”. En este último caso la bobina consume una intensidad de 16. 1.diseño y cableado de la tarjeta intermedia de relés. Cuando la tensión en la bobina de control es de 0 voltios el terminal común se cortocircuita con el terminal inferior y el superior queda en alta impedancia. Cuando en el terminal IN tenemos un “1” lógico TTL el terminal C está cortocircuitado con el terminal “1”. La bobina tiene una impedancia cuya parte real es de 740 Ω. donde los distintos pines están conectados del modo que se indica en la tabla de la página siguiente. 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 implementación del componente C_PCI9111. Los polos negativos están conectados a 0 voltios ( GND / pin 25 ). Se ha diseñado y construido una tarjeta intermedia de 16 relés controlados por entradas TTL . 116 . Los pines 1 al 6 están conectados a los polos positivos de los seis tramos. Cuando la tensión en la bobina de control es de 12 voltios el terminal común se cortocircuita con el terminal superior y el inferior queda en alta impedancia. El cableado de la maqueta es acesible a través de un conector DB-25 hembra . El elemento básico del diseño es un relé de tres terminales como el que se muestra en la figura.2 mA1. diciembre 2002 Apéndice B: DISEÑO Y CABLEADO DE LA TARJETA INTERMEDIA DE RELÉS.

Los terminales “común” de los cruces están conectados a 0 voltios ( GND / pin 25 ).diseño y cableado de la tarjeta intermedia de relés. diciembre 2002 Los pines 7 a 14 están conectados a los terminales de control de los cuatro cruces. Pin DB-25 1 2 3 4 5 6 7 8 9 10 11 12 13 14 25 Conexión 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 .

5 V T2 En el relé 15 se determina si T1 es 0 o 7 voltios ( LOW_SPEED ). diciembre 2002 El cableado realizado entre la tarjeta intermedia de relés 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. 118 .diseño y cableado de la tarjeta intermedia de relés.

diciembre 2002 En el relé 14 se decide si T2 es 0 o 13. 119 .diseño y cableado de la tarjeta intermedia de relés. En los relés del 0 al 5 se decide si cada uno de los tramos se alimenta con T1 o con T2.5 voltios ( HIGH_SPEED ). En los relés 6 al 13 se controla la posición de los cuatro cruces generando pulsos digitales en el terminal de la posición deseada.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->