ES2599006T3

ES2599006T3 - Sistema y procedimiento de programación de la ejecución de componentes de un modelo usando eventos del modelo

Info

Publication number: ES2599006T3
Application number: ES05705164.1T
Authority: ES
Inventors: Peter Szpak; Matthew Englehart
Original assignee: MathWorks Inc
Current assignee: MathWorks Inc
Priority date: 2004-01-15
Filing date: 2005-01-06
Publication date: 2017-01-31
Anticipated expiration: 2025-01-06
Also published as: HUE031215T2; JP2007518190A; US20050160397A1; US20160012162A1; US8458655B1; EP1706818B1; US10157246B2; US20160011919A1; US8793602B2; WO2005071537A1; EP1706818A1; CN1965293A; CN1965293B

Abstract

En un entorno de modelado gráfico que tiene al menos un modelo gráfico ejecutable con una pluralidad de componentes basados en tiempo ejecutables, representando los componentes basados en tiempo unos sistemas dinámicos que tienen entradas, estados y salidas que cambian continua o discretamente en puntos específicos en el tiempo, un procedimiento, que comprende las etapas de: visualizar una vista del modelo (20) gráfico ejecutable, incluyendo dicho modelo (20) gráfico ejecutable un primer conjunto de componentes basados en tiempo ejecutables, comprendiendo dicho primer conjunto de componentes basados en tiempo ejecutables al menos un componente (22) de envío gráfico ejecutable configurable por el usuario, que tiene al menos un puerto (26) de entrada para recibir al menos una señal (24) de entrada, estando dicho al menos un componente (22) de envío gráfico ejecutable configurable por el usuario configurado para enviar un evento cuando se cumple una condición asociada con dicha al menos una señal (24) de entrada de dicho al menos un componente (22) de envío gráfico ejecutable configurable por el usuario; asociar al menos un componente (28) basado en tiempo de un segundo conjunto de componentes basados en tiempo con dicho evento; programar la ejecución del primer conjunto del primer conjunto de componentes basados en tiempo ejecutables en una o más velocidades predeterminadas, identificando cuando se cumple dicha condición durante la ejecución de dicho modelo (20) gráfico ejecutable; enviar, mediante dicho componente (22) de envío gráfico ejecutable configurable por el usuario, una aparición de dicho evento en dicho entorno de modelado gráfico a un manipulador de eventos; notificar dicha aparición de dicho evento a dicho al menos un componente basado en tiempo del segundo conjunto que está asociado con dicho evento; y ejecutar dicho al menos un componente basado en tiempo solo condicionalmente en respuesta a dicha notificación.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Sistema y procedimiento de programacion de la ejecucion de componentes de un modelo usando eventos del modelo

La realizacion ilustrativa de la presente invencion se refiere en general a la ejecucion de los componentes del modelo dentro de un entorno de modelado, y mas espedficamente a la programacion de la ejecucion de los componentes de modelado usando los eventos del modelo.

La realizacion ilustrativa de la presente invencion esta relacionada con una solicitud de patente de Estados Unidos actualmente pendiente titulada, “A System and Method for Using Execution Contexts in Block Diagram Modeling", numero de serie: 10/414, 644.

Simulink™ de The MathWorks, Inc. de Natick, Massachusetts, es un ejemplo de un entorno de modelado grafico, espedficamente un entorno de diagrama de bloques. Simulink™ permite a los usuarios crear un modelo pictorico de un sistema dinamico. El modelo consiste en un conjunto de sfmbolos, llamados bloques. Cada bloque puede tener cero o mas puertos de entrada, puertos de salida, y estados. Cada bloque representa un sistema dinamico cuyas entradas, estados y salidas pueden cambiar continuamente y/o discretamente en puntos espedficos en el tiempo. Las lmeas se utilizan para conectar los puertos de los bloques entre sf, y representan las dependencias de datos entre bloques. Las senales pueden representarse como valores que se desplazan a lo largo de las lmeas que conectan los bloques en un diagrama de bloques.

Si todas las entradas, las salidas y los estados del bloque cambian o continuamente o en una velocidad periodica fija, el bloque se considera que es un bloque 'de velocidad unica'. Si las entradas, los estados, y las salidas se actualizan, o juntos o por separado en puntos en el tiempo definidos por dos o mas velocidades, el bloque se considera que es un bloque 'multi-velocidad'. Si un modelo tiene unos bloques multi-velocidad en el mismo, o dos o mas bloques de velocidad unica ejecutandose a velocidades diferentes, entonces el modelo en sf mismo es multi- velocidad (frente a velocidad unica).

Un bloque se denomina como 'atomico' si su definicion funcional esta fuera del contexto del modelo en el que se coloca. Simulink™ tiene un conjunto de bloques atomicos predefinidos (por ejemplo, suma, producto, ganancia), y el usuario tambien puede crear sus propios bloques atomicos a traves de unas 'funciones-S' escritas por el usuario. Al ser atomicas, las definiciones funcionales de las 'funciones-S' se especifican fuera del contexto del modelo, por ejemplo, usando un codigo C o un codigo MATLAB 'm'. Un bloque 'compuesto' es un bloque cuya definicion funcional se especifica a traves del modelo usando unos conjuntos de bloques atomicos y compuestos. Simulink™ permite al usuario especificar 'subsistemas', bloques compuestos cuya definicion consiste en conjuntos interconectados de bloques predefinidos, funciones-S' escritas por el usuario, y otros subsistemas Simulink™. Los subsistemas pueden anidarse jerarquicamente, definiendo una ‘jerarqma del modelo'.

Las velocidades de muestreo Simulink™ proporcionan un mecanismo para especificar la velocidad con que se ejecutan los componentes de un modelo. La figura 1 representa un ejemplo del uso de las velocidades de muestreo en el control de la ejecucion de los componentes del modelo. Por ejemplo, el disenador puede especificar que un bloque 4 de establecimiento se ejecuta a una velocidad continua, y un bloque 10 de controlador se ejecuta en alguna velocidad periodica, discreta. La ejecucion de los componentes del modelo se programa por la infraestructura Simulink™ cuando se simula, o por el sistema operativo para una implementacion en tiempo real. No existe una relacion causal entre las dinamicas del modelo y la programacion de estas velocidades; los instantes en los que los componentes se ejecutan estan predeterminados.

Simulink™ soporta la propagacion de las velocidades de muestreo. Por ejemplo, las velocidades de los bloques de ganancia de 8 y 12 en la figura 1 pueden haberse dejado sin especificar, o mas bien, especificadas como “Heredadas”. En este caso, asumiendo que se han especificado las velocidades de los bloques de establecimiento 4 y de controlador 10, los bloques de ganancia de 8 y 12 heredan sus velocidades de los bloques de establecimiento y de controlador.

Simulink™ tambien proporciona unos mecanismos para especificar las relaciones causales entre las dinamicas del modelo y la ejecucion de los componentes del modelo, incluyendo: subsistemas de funcion de llamada, subsistemas activados, subsistemas de iterador, subsistemas de accion y subsistemas habilitados. La especificacion de las relaciones causales permite a los usuarios especificar la ejecucion de los componentes del modelo condicionados en los valores presentes y pasados de las senales y en otros datos del modelo.

Sin embargo, el ambito de la ejecucion condicional se restringe en general a un subsistema como los procedimientos convencionales de especificar las relaciones que no permiten que el ambito de la ejecucion condicional se defina como un conjunto arbitrario de bloques (en comparacion con el conjunto de bloques que comprenden un subsistema). Esta es una limitacion importante, ya que hay veces en las que es deseable ejecutar simultaneamente un conjunto de bloques que no estan en un subsistema y/o no son contiguos en el modelo. Por ejemplo, los procedimientos convencionales de ejecucion condicional no permiten la ejecucion de varios bloques distribuidos a traves del modelo en el encendido o en el apagado. Como resultado, la manera en que pueden estar compuestas las relaciones causales esta restringida. Los procedimientos convencionales de especificar las relaciones causales

5

10

15

20

25

30

35

40

45

50

55

entre las dinamicas de un modelo y la ejecucion de los componentes del modelo no permiten que un usuario habilite la mitad de los bloques en un subsistema y active los otros bloques. Del mismo modo, uno puede no activar algunos de los bloques en un subsistema con un activador, y los bloques restantes con un activador diferente.

Un inconveniente adicional de los mecanismos convencionales para especificar las relaciones causales entre las dinamicas de un modelo y la ejecucion de los componentes del modelo es que estos mecanismos requieren unas conexiones graficas a realizarse en el diagrama de bloques para indicar la causalidad. Esto puede resultar en una apariencia de que algunos usuarios sienten que “desordenan” el diagrama. Otra limitacion de los mecanismos convencionales para especificar las relaciones causales es que los mecanismos convencionales no se mapean de manera natural en el software avanzado o en las construcciones del sistema operativo, tal como la inicializacion, las excepciones, o las tareas. Del mismo modo, ya que los mecanismos convencionales de especificar las relaciones causales carecen de un primer objeto de clase asociado con la relacion causal, es diffcil configurar y asignar unas caracteffsticas a esa relacion. Tambien es diffcil para el usuario aprovechar directamente las dinamicas implfcitas asociadas con los mecanismos, por ejemplo, los procedimientos de habilitar y deshabilitar asociados con un subsistema habilitado, y para ejecutar condicionalmente los componentes del modelo basados en estas dinamicas implfcitas.

El documento US 5.497.500 trata de la manipulacion de eventos por medio de un manipulador de eventos dentro de un entorno grafico. El documento US 5.497.500 no permite ejecutar los componentes basados en tiempo dentro del entorno grafico.

El entorno de modelado grafico que tiene una pluralidad de componentes basados en tiempo ejecutables se conoce en la tecnica. El arffculo “Real-time workshop - for use with Simulink”

(
http://mntek3.ulb.ac.be/Matlab/pdf_doc/rtw/rtw_ug.pdf) trata, por ejemplo, en la pagina 373, un entorno de modelado grafico. En este caso, se asignan diferentes tiempos de muestreo a diferentes bloques que tienen dependencias de datos. A partir de este arffculo, es el problema objetivo de la presente invencion permitir un modelado y una estimulacion mas eficiente de los sistemas dinamicos en los entornos graficos conocidos.

El problema se resuelve por el procedimiento de la reivindicacion 1 y el sistema de la reivindicacion 12. Otras realizaciones de la invencion pueden obtenerse de las reivindicaciones dependientes.

La realizacion ilustrativa de la presente invencion proporciona un mecanismo para especificar y configurar una relacion causal entre las dinamicas de un modelo y la ejecucion de los componentes del modelo. La ejecucion del componente del modelo esta ligada a la aparicion de los “eventos del modelo”. Los eventos del modelo se definen primero en el entorno de modelado. La aparicion de condiciones en el modelo especificadas en la definicion del evento hace que el evento se “envfe”. Los componentes del modelo que se han asociado con la aparicion del evento “reciben” la notificacion del envfo del evento y a continuacion se ejecutan. Los componentes aislados dentro de un subsistema pueden designarse para ejecutarse tras la aparicion de un evento, como componentes no contiguos dentro de un modelo. La asociacion entre los eventos del modelo y la ejecucion del componente puede especificarse sin dibujar los indicadores graficos que conectan los componentes en la vista del modelo.

En el entorno de modelado que tiene al menos un modelo con multiples componentes ejecutables, el procedimiento monitoriza la ejecucion del modelo para la aparicion de un evento especificado. Tras determinar la aparicion del evento especificado, la aparicion del evento se envfa a un manipulador de eventos. A continuacion, se ejecuta un componente en respuesta a la notificacion del manipulador de eventos.

En otra realizacion, en un entorno de modelado que tiene al menos un modelo con multiples componentes ejecutables, un procedimiento monitoriza la ejecucion del modelo para la aparicion de un evento especificado. Tras determinar la aparicion del evento especificado, se interrumpe la ejecucion de otro evento en respuesta a la determinacion de la aparicion del evento especificado. A continuacion, se realiza una operacion en el modelo en respuesta a la determinacion de la aparicion del evento especificado.

En una realizacion, en un entorno de modelado, un sistema incluye un modelo grafico con multiples componentes ejecutables. El sistema tambien incluye un manipulador de eventos. El manipulador de eventos recibe una notificacion del modelo de la aparicion de un evento especificado. El sistema incluye ademas al menos un componente que recibe la notificacion desde el manipulador de eventos de la aparicion del evento especificado. El componente de recepcion se ejecuta en respuesta a la notificacion.

Breve descripcion de los dibujos

La figura 1 representa un modelo de diagrama de bloques convencional que utiliza unas velocidades de muestreo;

la figura 2 representa un modelo que utiliza el procedimiento de envfo de la realizacion ilustrativa de la presente invencion;

la figura 3 representa el envfo y la recepcion de unos eventos en un entorno Stateflow™ de acuerdo con la realizacion ilustrativa de la presente invencion;

la figura 4 es un diagrama de temporizacion de los eventos implfcitos que ocurren en un subsistema habilitado; la figura 5 representa un modelo que usa los eventos implfcitos en un subsistema habilitado;

5

10

15

20

25

30

35

40

45

50

55

60

la figura 6A representa un modelo con unas transiciones de eventos que ocurren dentro de la misma tarea y sin unos bloques de transicion de eventos;

la figura 6B representa un modelo con unas transiciones de eventos que ocurren en diferentes tareas usando unos bloques de transicion de eventos;

la figura 6C es una lmea de tiempo del uso de los bloques de transicion de eventos en un modelo;

la figura 7A representa un modelo que utiliza la realizacion ilustrativa de la presente invencion para manipular

los eventos como excepciones;

la figura 7B representa un modelo que utiliza la realizacion ilustrativa de la presente invencion para controlar el orden de ejecucion usando un bloque de prioridad de rama;

la figura 7C resalta el orden de ejecucion dictado por el bloque de prioridad de rama en el modelo de la figura 7B;

la figura 7D representa un modelo que utiliza la realizacion ilustrativa de la presente invencion para controlar el orden de ejecucion con grupos de bloques;

la figura 8 es un diagrama de flujo de datos que contrasta la manipulacion de los eventos normales y excepcionales en la realizacion ilustrativa de la presente invencion;

la figura 9 representa un entorno adecuado para practicar la realizacion ilustrativa de la presente invencion; y la figura 10 es un diagrama de flujo de una vista de alto nivel de la secuencia de etapas seguidas por la realizacion ilustrativa de la presente invencion para asociar las velocidades de muestreo con la aparicion del evento.

Descripcion detallada

La realizacion ilustrativa de la presente invencion proporciona un mecanismo para ligar la ejecucion de los componentes del modelo a la aparicion de los eventos del modelo especificados. Las velocidades de muestreo se especifican como eventos que ligan de este modo la ejecucion del componente del modelo a las dinamicas del modelo. Los elementos del modelo no contiguos pueden configurarse para ejecutarse condicionalmente basandose en una aparicion del evento del modelo. Ademas, el ambito de la ejecucion del componente no esta limitado a los subsistemas en su totalidad como se requiere por algunos sistemas convencionales. La ejecucion condicional de los componentes basados en una aparicion del evento tambien puede usarse para manipular las excepciones. Las asociaciones entre los componentes y los eventos del modelo pueden establecerse sin dibujar las conexiones de componente adicionales en la vista del modelo.

En aras de la claridad, la explicacion de la realizacion ilustrativa de la presente invencion contenida en el presente documento hace referencia a un entorno de modelado basado en Simulink™ y MATLAB™ (ambas aplicaciones de The MathWorks de Natick, Massachusetts). Sin embargo, debena reconocerse por los expertos en la materia, que la realizacion ilustrativa de la presente invencion puede aplicarse tambien a otros entornos de modelado y a otros tipos de diagramas ademas de a los diagramas de bloques tradicionales como Stateflow™ de The MathWorks de Natick, Massachusetts, una aplicacion de diagramas de estado, y unos entornos de diagramas de flujos de datos.

Un evento del modelo Simulink™ tal como se usa en la realizacion ilustrativa de la presente invencion (tambien denominado en lo sucesivo en el presente documento como “evento” o “evento Simulink™”) puede definirse explfcitamente en un espacio de trabajo de MATLAB como un objeto. Sus atributos pueden incluir un nombre, un color, una velocidad esperada opcional, una tarea opcional, y una explicacion de como debena implementarse la funcion correspondiente al evento (por ejemplo, en lmea frente a una firma definida explfcitamente).

Los eventos que se han definido pueden “enviarse” por bloques en el modelo, basados en unas condiciones arbitrarias que define el usuario. Los bloques que “reciben” este evento se ejecutan cuando se envfa. “Enviar” se refiere al envm de un mensaje a un manipulador de eventos que indica la aparicion de un evento espedfico. A continuacion, se informa a los bloques que se han registrado con o de otro modo enganchado en el manipulador de eventos acerca de la aparicion del evento cuando se envfa el evento.

La figura 2 representa un ejemplo de un modelo 20 que utiliza el procedimiento de envm. El evento “A” se ha definido y dado el atributo de color “azul”. En el modelo 20, el bloque de “Envm” 22 se ha configurado (como se ve por la ventana de dialogo en esa figura) para enviar el evento “A” condicionalmente cuando la senal 24 en su puerto 26 de entrada es mayor que cero. El cuadro de dialogo solicita un numero de parametros del usuario para el bloque 22 de envm que incluye el numero de entradas 36, la condicion 38 bajo la que se ejecuta el bloque, y el nombre asignado al evento 40 del modelo definido. La vista del modelo 20 indica que la velocidad de muestreo del bloque “constante” 28 se ha especificado para ser el evento “A”. Esta velocidad de muestreo (es decir: la aparicion del evento “A”) se propaga a los bloques de “retardo de unidad” 30 y de “salidal” 32 que se han establecido para heredar sus velocidades de muestreo. Por lo tanto, los tres bloques reciben el evento “A”. Los tres bloques 28, 30 y 32 pueden asumir el “color” del evento “A” y sombrearse de azul en una visualizacion a un usuario como una forma de expresar la asociacion logica. Por lo tanto, cuando la salida del bloque 21 “onda sinusoidal” es positiva, “A” se envfa por el bloque de “envm”, se ejecutan los tres bloques 28, 30 y 32, y se actualiza el valor en el puerto de salida rafz del modelo.

El modelo representado en la figura 2 muestra la resolucion de algunos de los problemas asociados con la ejecucion condicional de los subsistemas que se proporcionan por la realizacion ilustrativa de la presente invencion.

5

10

15

20

25

30

35

40

Hay un primer objeto “A” de clase asociado con la relacion causal, de manera que es posible configurar y asignar unas caractensticas a esa relacion tal como el color. El ambito de la ejecucion condicional no se limita a un subsistema. Los tres bloques 28, 30 y 32 que se ejecutan condicionalmente no estan agrupados dentro de un subsistema padre y pueden elegirse desde areas no contiguas del modelo 20. Ademas, el ambito de la ejecucion condicional emplea una propagacion de velocidad (solo el bloque “constante” 28 especifica “A” como su velocidad de muestreo). Esto resulta en un procedimiento de especificar las velocidades de muestreo que es mas conciso de lo que sena el caso si cada bloque que recepciona una “A” tuviera que tener su velocidad de muestreo especificada explfcitamente como “A”. Ademas, la asociacion de bloques con un evento no requiere una conexion grafica entre el bloque 22 de envfo y el bloque 28 constante para realizarse en el diagrama para indicar la causalidad. La relacion causal entre la condicion especificada por el bloque 22 de “envfo” y la ejecucion de los tres bloques 28, 30 y 32 es a traves de su referencia comun para el objeto de evento llamado “A” 23.

Un “ambito” de un evento es el ambito del espacio de trabajo dentro del que existe. Si un espacio de trabajo esta asociado con un subsistema o modelo, el ambito del evento es ese subsistema o modelo. Los bloques solo pueden especificar su tiempo de muestreo como un evento cuando ese evento esta en el ambito de ese bloque.

La figura 3 representa otro ejemplo de un entorno en el que ocurre el envfo y la recepcion explfcita de eventos, visualizando una grafica 30 Stateflow™ y un modelo 32 de diagrama de bloques de los componentes de la grafica con mas detalle. En este ejemplo, el usuario define los eventos “A” 34 y “B” 36, con los colores de atributos verde y azul, respectivamente. Ambos eventos 34 y 36 tienen sus velocidades de muestreo especificadas como 20 ms. A continuacion, la grafica 30 Stateflow se ejecuta cada 20 ms y se envfan estos eventos en una secuencia periodica bien definida. Los dos bloques 40 y 50 de puerto de entrada tienen sus velocidades de muestreo establecidas en los eventos “A” 34 y “B” 36. El resto de los bloques asumen estos eventos como unas velocidades de muestreo heredadas y se sombrean con el color correspondiente al evento. El conjunto de bloques de color verde 40, 42, 44 y 46 reciben el evento “A” y se ejecutan cuando se envfa ese evento. Del mismo modo, el conjunto de bloques de color azul 50, 52, 54 y 56 se ejecutan cuando se envfa ese evento “B”.

El conjunto de elementos que manipula cada evento se ejecutan en el orden relativo en el que aparecen en la lista de bloques ordenados del modelo. El orden de la lista de bloques ordenados esta determinado por las dependencias de datos. En consecuencia, cada 20 ms se ejecuta la grafica 30 Stateflow, y la cadena de bloques de color verde 40, 42, 44, y 46 se ejecuta, de izquierda a derecha, seguida de la cadena de bloques de color azul 50, 52, 54 y 56, de izquierda a derecha. Ademas, ya que la velocidad de muestreo opcional de los eventos se ha especificado explfcitamente para que sea de 20 ms, se realiza una comprobacion de tiempo de ejecucion para afirmar que estos eventos se envfan cada 20 ms. Una de las ventajas de la especificacion explfcita de la velocidad de un evento es que cualquier codigo generado para esa velocidad puede usar el tiempo de muestreo constante correspondiente en el codigo generado siempre que se requiera un tiempo transcurrido entre la ejecucion sucesiva, en lugar de requerir el uso de temporizadores, lo que normalmente sena el caso.

A diferencia de los eventos explfcitos, que se definen como objetos del espacio de trabajo y cuyas condiciones para enviarse se especifican explfcitamente por el usuario (por ejemplo, a traves del uso de bloques de “envfo” Simulink™ o de la logica Stateflow), los eventos implfcitos estan implfcitos en las construcciones del modelo y, se envfan automaticamente en respuesta a la ejecucion de dichas construcciones. El usuario no puede enviar eventos implfcitos. Sin embargo, el usuario puede manipular los eventos implfcitos, lo que significa que el usuario puede definir los componentes del modelo que se ejecutan directamente en respuesta a un evento implfcito.

La realizacion ilustrativa de la presente invencion incluye los cinco tipos de eventos implfcitos observados en la tabla a continuacion:

Nombre del evento: Tipo de evento Ambito Localizacion donde se envia Cuando enviar

ts: Iniciar Todo el modelo Rafz del modelo Comienzo de la ejecucion del modelo

to: Inicializar Habilitar/Si/ subsistema de caso Nivel superior del subsistema La primera vez el subsistema transiciona de inactivo a activo

te: Habilitar Habilitar/Si/ subsistema de caso Nivel superior del subsistema Siempre que el subsistema transiciona de inactivo a activo

td: Deshabilitar Habilitar/Si/ subsistema de caso Nivel superior del subsistema Siempre que el subsistema transiciona de activo to inactivo

tf: Cerrar Todo el modelo Rafz del modelo Fin de la ejecucion del modelo

Los expertos en la materia reconoceran que pueden manipularse otros tipos de eventos implfcitos, ademas de los

5

10

15

20

25

30

35

40

45

50

55

60

que enumerados en la tabla anterior sin alejarse del ambito de la presente invencion. Por ejemplo, otros tipos de eventos impKcitos que pueden soportarse incluyen condiciones de error, tales como un evento impKcito enviado cuando un bloque de producto intenta dividir por cero, o un bloque logaritmo intenta tomar el logaritmo de cero. Los objetos correspondientes a los eventos implfcitos pueblan automaticamente los diversos espacios de trabajo del modelo, por lo que sus propiedades pueden configurarse por el usuario.

La figura 4 representa los eventos implfcitos observados en la tabla anterior en un diagrama de temporizacion. La figura 4 muestra la temporizacion relativa de los eventos que estan en el ambito en un subsistema habilitado o sus descendientes en la jerarqma de la funcion de llamada; la senal variable en el tiempo es la senal de habilitacion del subsistema. Los cinco tipos de eventos implfcitos tienen una velocidad de muestreo asmcrona. Los eventos implfcitos incluyen un inicio 70, una inicializacion 72, una habilitacion 74, una deshabilitacion 76 y un cierre 78.

Un ejemplo del uso de eventos implfcitos en un subsistema 90 habilitado se muestra en la figura 5. El subsistema 90 tiene unos eventos de habilitar y deshabilitar implfcitos asociados, que se envfan cuando el subsistema se habilita y deshabilita. El bloque 92 de “retencion de orden cero” tiene su velocidad de muestreo especificada como “deshabilitada”, de manera que se ejecuta cuando el evento de deshabilitar implfcito se ejecuta, es decir, cuando el subsistema 90 habilitado se deshabilita. A traves de la propagacion, el bloque “Ganancial” 94 tambien hereda ese evento (deshabilitado) como su velocidad de muestreo, y juntos, estos dos bloques se ejecutan y actualizan la memoria asociada con el puerto 96 de salida del subsistema cuando el subsistema 90 se deshabilita.

Cada evento en la realizacion ilustrativa de la presente invencion se mapea 1-1 a una funcion (tambien denominada en el presente documento como el “manipulador de eventos”) que sirve como punto de entrada para el codigo correspondiente a los bloques cuya velocidad de muestreo se ha especificado o heredado como el evento. Siempre que las condiciones que conducen al envm del evento son verdaderas, el sistema reacciona llamando a la funcion. La funcion puede dejarse en lmea durante la generacion del codigo. La eleccion de si se deja o no en lmea la funcion de un evento es una propiedad del objeto de evento correspondiente. Como una implementacion por defecto, un usuario puede elegir por dejar en lmea las funciones de los eventos implfcitos, y por no dejar en lmea las funciones de los eventos explfcitos.

Una de las propiedades de un evento Simulink™ es su tarea. Por defecto, un evento hereda su tarea del contexto desde el que se envfa. Por ejemplo, en la figura 3 los eventos “A” 34 y “B” 36 se ejecutan en la misma tarea que la grafica 30 Stateflow que envfa esos eventos. El codigo generado llama a las funciones que corresponden a “A” y “B”, como unas llamadas de funcion local que se representan en el siguiente pseudocodigo correspondiente al modelo de la figura 3.

void model step ()

{

A();

B();

void A()

{

u3 = x; u2'= 2*u1; x = u2;

}

void B()

{

v3 = y; v2 = 3*v1; y = v2 ;

La tarea de un evento puede especificarse como el nombre de un objeto de tarea del modelo, que corresponde a una tarea en la implementacion en tiempo real. Los objetos de tarea Simulink™ corresponden a las tareas generadas del sistema operativo. Las propiedades de un objeto Tareas pueden incluir una velocidad designada (un valor periodico, o asmcrono), una prioridad, un tamano de pila de tareas, si la tarea es preferente, u otras propiedades. Cuando se envfa un evento cuya tarea es diferente de la tarea de la construccion de bloque o de modelo que envfa el evento, la funcion correspondiente al evento se programa en la tarea del evento. Si la tarea se especifica para que sea periodica, la funcion se ejecuta durante cualquier etapa de tiempo de esa tarea durante la que se envfa el evento. Si la tarea se especifica como asmcrona, entonces el envm del evento hace que la tarea se ejecute por el sistema operativo.

La realizacion ilustrativa de la presente invencion evita el envm asmcrono de eventos y una implementacion multiproceso, a traves del uso de tareas. Las tareas se usan para ayudar a garantizar la integridad de los datos cuando se usan los eventos en una implementacion en tiempo real indicando donde se requiere un bloque de transicion de evento en aras de la integridad de los datos. Las tareas tambien se usan para especificar la prioridad relativa de las tareas asociadas con una transicion. La realizacion ilustrativa de la presente invencion usa un bloque de transicion de eventos que es una generalizacion del bloque de transicion de velocidad de Simulink™ Las figuras

5

10

15

20

25

30

35

40

45

50

55

60

6A, 6B y 6C ilustran algunos de los temas involucrados con las transiciones de eventos y el uso de los bloques de transicion de eventos.

La figura 6A representa un modelo 100 con transiciones que ocurren en respuesta a la aparicion del evento A y del evento B. En el modelo 100, los eventos A y B tienen la misma tarea y el problema de integridad de datos puede resolverse utilizando la memoria persistente para almacenar los datos en los lfmites entre los dos eventos. Ya que los dos eventos estan en la misma tarea, no pueden preferirse entre sf, y no son necesarios mecanismos adicionales (por ejemplo, doble almacenamiento intermedio). En este modelo 100, la memoria persistente se utiliza para las salidas de los dos bloques 102, 104 de funcion de transferencia de la izquierda y los bloques de transicion no son necesarios para transferir los datos entre los bloques 102, 104 y 106 de funcion de transferencia.

Sin embargo, si se especifican los eventos A y B para ejecutarse en diferentes tareas, son necesarios los bloques de transicion de eventos, como se muestra en la figura 6B. En el modelo 110 de la figura 6B, el evento A tiene una tarea con alta prioridad, mientras que el evento B tiene una tarea de baja prioridad. En este caso, el bloque denominado Transicion 114, que se encuentra en el lfmite entre los bloques de funcion de transferencia primero 112 y segundo 116, actua como una retencion de orden cero. El bloque denominado Transicion1 118, que se encuentra en el lfmite entre los bloques de funcion de transferencia segundo 116 y tercero 120, actua como un retraso por defecto.

La lmea de tiempo de la figura 6C muestra la funcionalidad de los bloques de transicion de eventos de la figura 6B. Ya que el bloque de transicion de eventos Transicion 114 actua como una retencion de orden cero, se representa en la figura por unos intervalos de tiempo etiquetados “ZOH”. Ya que el bloque de transicion de eventos Transicion1 118 actua como un retraso, se representa en la figura por unos intervalos de tiempo etiquetados “1/z”. El bloque de transicion de eventos Transicion 114 se ejecuta cada vez que se ejecuta el manipulador para el evento A, siempre que la tarea asignada al evento A no sea preferente a la tarea que contiene el evento B. Esto evita la entrada al manipulador para cambiar B en el medio de su ejecucion. Esto es necesario ya que en un sistema asmcrono causal, no hay manera de saber de antemano cuando el evento B se enviara proximamente. La funcion de salida para el bloque de transicion de eventos Transcion1 118 se ejecuta cada vez que el evento A se envfa despues de que el manipulador para el evento B haya finalizado su ejecucion. Esto garantiza que el manipulador para el evento A utiliza el ultimo valor calculado por el manipulador para B, pero no ejecuta la funcion de salida de Transicion1 si no es necesario.

Por lo tanto, en la figura 6C, la tarea de baja prioridad asociada con el evento B (etapa 130), ejecuta un retardo (etapa 132), la tarea de alta prioridad asociada con el evento A (etapa 134) se ejecuta y se sigue por la retencion de orden cero (etapa 136). A continuacion, la tarea asociada con el evento A se ejecuta (etapa 138) sin que se preceda por el retraso ya que B no se ha ejecutado desde la ultima vez que se ha ejecutado A. A continuacion, se ejecuta la retencion de orden cero (etapa 140) seguida de la tarea de alta prioridad (etapa 138). A continuacion, se ejecuta la tarea de baja prioridad asociada con B (etapa 142) y se interrumpe por la tarea de alta prioridad (etapa 144). Tras la finalizacion de la tarea de alta prioridad (etapa 144) se reanuda la tarea de baja prioridad (etapa 142) sin que se ejecute la retencion de orden cero ya que la tarea de baja prioridad ya habfa comenzado. El procedimiento continua con el retardo (etapa 146), la tarea de alta prioridad (etapa 148) y la retencion de orden cero (etapa 150) que se ejecutan en orden.

Ademas de garantizar la integridad de los datos, los bloques de transicion de eventos pueden ser necesarios para la resolucion durante la propagacion de eventos. Sin embargo, al realizar la transicion entre los eventos que estan en la misma tarea, el bloque copia su valor de entrada a su salida persistente. A continuacion, despues de la compilacion puede intentarse reducir el bloque. Debena observarse que los bloques de transicion requieren un parametro de InitialCondition para inicializar su memoria. En una implementacion, el valor por defecto de este parametro es cero.

Los eventos tambien pueden usarse para manipular los errores encontrados cuando se ejecuta un modelo. Cuando se produce un error, el modelo puede “enviar excepcionalmente un evento”. Un evento que se envfa excepcionalmente se llama un “evento de excepcion”. Una caractenstica clave de un evento de excepcion es que se manipula de manera diferente a partir de un evento que se envfa no excepcionalmente, o un “evento normal”. En particular, cuando un evento envfa otro evento de excepcion, esa primera funcion del evento nunca reanuda la ejecucion tras salir la funcion del evento de excepcion. En otras palabras, si B interrumpe a A excepcionalmente, la ejecucion de A no se reanuda despues de la finalizacion de B. Observese que un evento puede llamarse tanto normal como excepcionalmente en el mismo modelo.

El uso de un evento de excepcion en un modelo se representa en la figura 7A. En el modelo 160, el componente superior es parte del manipulador para el evento A. Si la magnitud de la entrada u1 162 es menor que o igual que 1e-6, el evento B se envfa de manera excepcional, o “se lanza” para abreviar, por el bloque 166 de lanzamiento en el subsistema 164 de excepcion. El subsistema 164 de excepcion evalua la entrada 162 y solo lanza el evento B si la entrada u1 162 es menor que o igual que 1e-6. El bloque 166 de lanzamiento es similar en funcionalidad al bloque de envfo excepto en que envfa un evento de manera excepcional en lugar de normalmente. Cuando se lanza el evento B, se ejecuta el manipulador para el evento B, estableciendo un almacen 168 de datos para una constante fija y grande. Cuando el manipulador para el evento B termina, el control no vuelve al manipulador para el evento A,

5

10

15

20

25

30

35

40

45

50

55

60

ya que el evento B se ha lanzado como una excepcion, sino que mas bien vuelve al procedimiento de llamada. El codigo representativo del procedimiento representado en la figura 7A puede representarse de la siguiente manera:

void model step ()

{

A();

void A()

{

u2 = fabs(ul);

u3 = u2 <= 1.0e-6;

if (fabs (u1) <= 1.0e-6) {

B(); /* return from B() exceptionally */ return;

v4 = rt_sgn(4*(v1 / ul)); x = rt lookup(rtP.lookup, v4); }

void B()

{

x = 1.0e6;

Si el evento B se hubiese enviado normalmente en lugar de como una excepcion, cuando se termina el manipulador para el evento B, el manipulador para el evento A habna finalizado su ejecucion. Estos dos escenarios contrastantes se representan de manera abstracta en la figura 8. Se entendera por los expertos en la materia que es importante tener un mecanismo preciso para controlar como se clasifican los bloques cuando se introducen eventos en un modelo, ya que los eventos introducen una relacion causal antes y despues de las relaciones causales implicadas por la dependencia de los datos.

El modelo de la figura 7A utiliza un subsistema atomico para forzar una orden de los bloques ordenados en el que el bloque de lanzamiento se ejecuta antes del bloque de producto que esta destinado a evitarse condicionalmente a traves del evento B de excepcion. Debido a que el subsistema atomico es anterior al bloque de producto en la lista de bloques ordenados, sus contenidos, que incluyen el bloque de lanzamiento, se ejecutaran antes que el bloque de producto. Una desventaja de un subsistema atomico es que sus contenidos no se reproducen al mismo nivel grafico que su grafico padre, haciendo sus contenidos menos facilmente discernibles.

Un mecanismo alternativo para el uso de un subsistema atomico para controlar orden de ejecucion es asignar la prioridad de las ramas que salen de un bloque, y a continuacion todos los bloques en una rama heredar la prioridad de esa rama cuando tal herencia es unica y no ambigua. La figura 7B muestra la colocacion de un “bloque 170 de prioridad de rama” que especifica que los bloques en la rama inferior debenan ejecutarse antes que los bloques en la rama superior. La figura 7C indica el orden de ejecucion dictado por el bloque 170 de prioridad de rama de la figura 7B. El numero “1” (172) en el bloque 170 de prioridad de rama indica que las ramas mas bajas debenan ejecutarse en primer lugar. El numero “2” en el bloque 170 de prioridad de rama indica que la rama superior debena ejecutarse en segundo lugar.

Una alternativa adicional al uso de un subsistema atomico para controlar el orden de ejecucion se representa en la figura 7D. La figura 7D representa el uso de unos “grupos de bloques”. Los bloques en el Grupo 1 (176) aparecera antes que los bloques en el grupo 2 (178) en la lista de bloques ordenados.

En el diagrama de la izquierda en la figura 8 que muestra un procedimiento de envfo normal para dos eventos, la ejecucion de un modelo (etapa 180) activa el evento A (etapa 182). Durante la ejecucion del evento A, el evento B ocurre normalmente y se manipula (etapa 184). Despues de la manipulacion del evento B (etapa 184), se reanuda la manipulacion del evento A (etapa 182). Despues de la terminacion de la ejecucion del evento A (etapa 182) el control se devuelve al punto en la ejecucion del modelo antes de la aparicion del evento A (etapa 180).

En el diagrama de la derecha en la figura 8, que muestra un procedimiento de envfo de excepcion para dos eventos, la ejecucion de un modelo (etapa 190) activa el evento A (etapa 192). Durante la ejecucion del evento A (etapa 192), se produce el evento B excepcionalmente y se manipula (etapa 194). Debido a que se ha manejado excepcionalmente el evento B, el control pasa de nuevo al punto de la ejecucion del modelo que existfa antes de la aparicion del evento A (etapa 190) sin reanudar la manipulacion del evento A.

La “devolucion anticipada” asociada con un evento de excepcion tambien puede ayudar a evitar ejecutar inutilmente los calculos corriente abajo de una senal involucrada en una condicion de error. Por ejemplo, en el ejemplo de la figura 7, la comprobacion de la magnitud de u1 se produce como parte de la ejecucion del subsistema atomico antes del bloque de producto y los bloques corriente abajo del bloque de producto. Debido a la devolucion anticipada del evento interrumpido, estos bloques se libran de la ejecucion (inutil) si se lanza el evento B.

Como ha tratado anteriormente, un evento puede enviarse normal o excepcionalmente. El bloque de envfo se usa para enviar un evento normalmente, mientras que el bloque de lanzamiento se usa para enviar un evento

5

10

15

20

25

30

excepcionalmente. Ademas, puede usarse una API de funcion-S especificada por el usuario para enviar un evento normal o excepcionalmente. Un componente del modelo puede manipular el evento cuando se lanza normalmente o cuando se lanza excepcionalmente, pero no en ambos casos. Un tiempo de muestreo de un bloque puede especificarse como 'A' para indicar que se manipula el evento A cuando se envfa normalmente o 'A.excepcion' para indicar que se manipula el evento A cuando se envfa excepcionalmente. Un bloque con el tiempo A de muestreo no manipula el evento A cuando se envfa excepcionalmente, y un bloque con el tiempo A.excepcion de muestreo no manipula el evento A cuando se envfa normalmente.

Los eventos explfcitos enviados excepcionalmente debenan tener un manipulador no vado; debena haber al menos un bloque en el modelo que manipulase el evento excepcionalmente. Si este no es el caso, se genera un error. Este requisito se justifica por el reconocimiento de que un evento de excepcion explfcito se envfa por los componentes del modelo que el usuario se ha tomado tiempo para crear, y que un evento de este tipo debena manipularse por el modelo. Los eventos implfcitos se envfan normalmente si hay un manipulador no vado. Si ningun componente del modelo esta manejando el evento implfcito enviado normalmente, se envfa el evento excepcionalmente en su lugar. Un bloque de lanzamiento puede reenviar un evento que se esta manipulando normalmente como un evento de excepcion. Este escenario puede utilizarse cuando no esta garantizado el exito de la manipulacion del evento normalmente. Despues de un primer intento, el evento puede manipularse excepcionalmente.

La figura 9 representa un entorno adecuado para practicar la realizacion ilustrativa de la presente invencion. Un dispositivo 200 electronico mantiene un entorno 202 de modelado grafico y de ejecucion tal como las aplicaciones Simulink™ o Stateflow™. El dispositivo 200 electronico puede ser una estacion de trabajo o un servidor, un ordenador portatil, una PDA, un dispositivo conectado a la red, o algun otro dispositivo electronico digital capaz de soportar el entorno 202 de modelado grafico y de ejecucion. El entorno 202 de modelado grafico y de ejecucion incluye al menos un modelo 204 grafico y un manipulador 206 de eventos como se ha tratado anteriormente. El dispositivo 200 electronico se interconecta con un dispositivo 208 de visualizacion que visualiza una vista 210 del modelo 204 para un usuario 212. El dispositivo 208 de visualizacion y el usuario 212 pueden estar localizados local o remotamente del dispositivo 200 electronico. Los expertos en la materia reconoceran que hay muchas diferentes configuraciones posibles de software y hardware dentro del ambito de la presente invencion.

Una secuencia de alto nivel de etapas seguidas por la realizacion ilustrativa de la presente invencion se muestra en la figura 10. La secuencia comienza con la ejecucion del modelo 204 en el entorno 202 de modelado grafico y de ejecucion (etapa 220). A continuacion, se determina la aparicion de un evento especificado anteriormente durante la ejecucion del modelo (etapa 222). La aparicion del evento se envfa al manipulador 206 de eventos (etapa 224). El manipulador de eventos notifica a los bloques registrados cuyas velocidades de muestreo estan ligadas a la aparicion del evento (etapa 226). Tras la notificacion, se ejecutan los bloques cuyas velocidades de muestreo estan ligadas a la aparicion del evento (etapa 228).

Claims

5

10

15

20

25

30

35

40

45

50

REIVINDICACIONES

1. En un entorno de modelado grafico que tiene al menos un modelo grafico ejecutable con una pluralidad de componentes basados en tiempo ejecutables, representando los componentes basados en tiempo unos sistemas dinamicos que tienen entradas, estados y salidas que cambian continua o discretamente en puntos espedficos en el tiempo, un procedimiento, que comprende las etapas de:

visualizar una vista del modelo (20) grafico ejecutable, incluyendo dicho modelo (20) grafico ejecutable un primer conjunto de componentes basados en tiempo ejecutables, comprendiendo dicho primer conjunto de componentes basados en tiempo ejecutables al menos un componente (22) de envfo grafico ejecutable configurable por el usuario, que tiene al menos un puerto (26) de entrada para recibir al menos una senal (24) de entrada, estando dicho al menos un componente (22) de envfo grafico ejecutable configurable por el usuario configurado para enviar un evento cuando se cumple una condicion asociada con dicha al menos una senal (24) de entrada de dicho al menos un componente (22) de envfo grafico ejecutable configurable por el usuario; asociar al menos un componente (28) basado en tiempo de un segundo conjunto de componentes basados en tiempo con dicho evento;

programar la ejecucion del primer conjunto del primer conjunto de componentes basados en tiempo ejecutables en una o mas velocidades predeterminadas, identificando cuando se cumple dicha condicion durante la ejecucion de dicho modelo (20) grafico ejecutable;

enviar, mediante dicho componente (22) de envfo grafico ejecutable configurable por el usuario, una aparicion de dicho evento en dicho entorno de modelado grafico a un manipulador de eventos;

notificar dicha aparicion de dicho evento a dicho al menos un componente basado en tiempo del segundo conjunto que esta asociado con dicho evento; y

ejecutar dicho al menos un componente basado en tiempo solo condicionalmente en respuesta a dicha notificacion.
2. El procedimiento de la reivindicacion 1, que comprende las etapas adicionales de:

registrar el al menos un componente basado en tiempo del segundo conjunto con dicho manipulador de eventos.
3. El procedimiento de la reivindicacion 1, que comprende la etapa adicional de:

establecer un tiempo de muestreo para la ejecucion inicial de dicho componente basado en tiempo ejecutable del segundo conjunto para ser la aparicion del evento especificado.
4. El procedimiento de la reivindicacion 3, que comprende la etapa adicional de:

propagar el tiempo de muestreo a un componente basado en tiempo ejecutable adicional de dicho segundo conjunto, estando dicho componente basado en tiempo ejecutable adicional configurado para heredar una velocidad de muestreo.
5. El procedimiento de la reivindicacion 3, que comprende la etapa adicional de:

establecer un tiempo de muestreo de una pluralidad de componentes basados en tiempo ejecutables no contiguos del segundo conjunto para ser la aparicion de dicho evento.
6. El procedimiento de la reivindicacion 5,

en el que dicho tiempo de muestreo para la pluralidad de componentes basados en tiempo ejecutables no contiguos se establece sin ajustar conexiones visibles entre dicha pluralidad de componentes basados en tiempo ejecutables visualizados en dicha vista.
7. El procedimiento de la reivindicacion 3, que comprende la etapa adicional de:

indicar con un identificador (ID) de evento en dicha vista que el tiempo de muestreo de dicho componente basado en tiempo ejecutable esta establecido para dicho evento.
8. El procedimiento de la reivindicacion 1, en el que un ambito de ejecucion del evento para el que se esta supervisando la ejecucion del modelo grafico ejecutable esta restringido a una parte del modelo grafico ejecutable.
9. El procedimiento de la reivindicacion 1, en el que cada evento en dicho modelo grafico ejecutable se mapea sobre una base de uno a uno a un manipulador de eventos, siendo dicho manipulador de eventos una funcion.
10. El procedimiento de la reivindicacion 1, en el que un bloque de prioridad de ramas indica una orden de ejecucion entre al menos dos ramas de bloques en respuesta a dicha notificacion.
11. El procedimiento de la reivindicacion 1, en el que se ejecuta mas de un segundo conjunto en respuesta a dicha notificacion, siendo dichos segundos conjuntos una agrupacion de bloques seleccionada por un usuario, especificandose el orden de ejecucion de los segundos conjuntos por un usuario.
12. En un entorno de modelado, un sistema, que comprende:

al menos un modelo grafico con una pluralidad de componentes ejecutables;

un manipulador de eventos, recibiendo dicho manipulador de eventos una notificacion de dicho modelo de la aparicion de un evento especificado; y

5 al menos un componente de recepcion, recibiendo dicho componente de recepcion la notificacion desde dicho

manipulador de eventos con respecto a la aparicion de dicho evento especificado y ejecutandose en respuesta a dicha notificacion,

implementando el sistema el procedimiento de acuerdo con una de las reivindicaciones 1 a 11.