Modelos Gracef11

N
UNIVERSIDADE DA CORUNA
DEPARTAMENTO DE ELECTRNICA E SISTEMAS
TESE DE DOUTORAMENTO
IMPLEMENTACIN DUNÂMBIENTE ABERTO E

DISTRIBUDO PARA O DESENVOLVEMENTO
DE APLICACINS DE CONTROL INDUSTRIAL
AUTOR: D. XON CARLOS PARDO MARTNEZ

DIRECTOR: D. RAMN FERREIRO GARCA
A CORUA, 2004
AGRADECEMENTOS
Aos meus pais e mia irm, a enerxa da mia vida.
mia aboa Ofelia, o seu xeito de ollarme faime invencbel.
mia familia, cos que compartn mis ausencias que presencias, compensareivos.
A Marta, que gusta do Outono. Eu amo o Outono.
Aos meus amig@s, a cada un por unha razn e a tod@s pola mesma, sntome moi afortunado.
Ao meu director de tese, polo seu estmulo intelectual e a sa grande humanidade, algn da
outro mundo ser posbel.
Aos meus compaeiros de departamento, que sempre tiveron unha cara ambel diante dos meus
problemas, non sabedes canto agradezo a vosa paciencia.
A Woody Allen, el xa sabe por qu.
A !NUNCA MIS!
ndice
LISTA DE FIGURAS .....................................................................................................................XV
LISTA DE TABOAS .............................................. ....................................................................... XXI
GLOSARIO DE ABREVIATURAS ......................................................................................... XXIII
,
.
CAPITULO 1. INTRODUCCION ...................................................................................................25
1.1. MOTIVACIN ............................................................................................................... 25
1.1.1. Antecedentes histricos ........................................................................................ 26
1.1.2. Lias de investigacin ......................................................................................... 28
1.2. ^BXECTIVOS ................................................................................................................ 31
1.3. MTODOS E FERRAMENTAS UTILIZADOS ...................................................................... 32
1.3.1. SGI STL ................................................................................................................ 33
1.3.2. Common. C++ ...................................................................................................... 33
1.3.3. Sidoni ................................................................................................................... 33
1. 3. 4. PCCTS ................................................................................................................. 33
1.4. SUMARIO ..................................................................................................................... 33
CAPTULO 2. FUNDAMENTOS E DESCRICIN DA FERRAMENTA PROPOSTA...........35
2.1. ^S SISTEMAS INDUSTRIAIS E O SEU CONTROL ............................................................... 35
2.1.1. Descricin dun sistema industrial ....................................................................... 35
2.1.2. Os sistemas de control industrial ......................................................................... 37
2.1.3. Modelado de procesos industriais ....................................................................... 38
2.1.4. A arquitectura fisica do sistema de control ......................................................... 39
2.2. O DESENVOLVEMENTO DE "SOFTWARE" PARA SISTEMAS MDUSTRIAIS ........................ 40
2.2.1. As arquitecturas de referencia na enxeera de sistemas industriais ................. 40
2.2.2. O modelado na enxeera de sistemas industriais ............................................... 41
2.2.3. Caracteristicas do "software " de control industrial ........................................... 42
2.2.4. Aplicacin de metodoloxa;s "software " en sistemas industriais ........................ 43
2.3. A FERRAMENTA PROPOSTA .......................................................................................... 44
2.3.1. A orientacin a obxectos no modelado de sistemas industriais .......................... 44
2.3.2. O Grafcet como formalismo de especificacin .................................................... 45
.,
.
.,
2.3.3. Comparacton con outras aproxtmactons .............................................................
2.3.4. A arquitectura da ferramenta .............................................................................. 49
2.3.5. O proceso de desenvolvemento coa ferramenta .................................................. SO
ndice
vi
2.3. 6. Integracin da ferramenta con outras aplicacins ............................................. SI
2.4. CONCLUSINS .............................................................................................................. $2
CAPITULO 3. O GRAFCET ...........................................................................................................55
3.1. INTRODUCCIN ............................................................................................................ $$
3.2. A SINTAXE DO GRAFCET .............................................................................................: $7
3.2.1. Elementos bsicos ....................................................:........................................... 57
3.2.1.1. Etapas ....................................................................................................................................$7
3.2.1.2. Transicins ............................................................................................................................$7
3.2.1.3. Arcos orientados ...................................................................................................................$7
3.2.1.4. Receptividades ......................................................................................................................$8
3.2.1.$. Accins ..................................................................................................................................$8
3.2.2. Extensins sintcticas .......................................................................................... 59
3.2.2.1. Etapas fonte e sumidoiro .....................................................................................................$9
3.2.2.2. Macroetapas ..........................................................................................................................60
3.2.2.3. Particins ...............................................................................................................................61
3.2.2.4. Ordes de forzado ..................................................................................................................61
3.2.3. Estructuras de control bsicas ............................................................................ 63
3.2.3.1. Secuencia ..............................................................................................................................63
3.2.3.2. Seleccin de secuencia ........................................................................................................63
3.2.3.3. Fin de seleccin de secuencia .............................................................................................63
3.2.3.4. Paralelismo ............................................................................................................................63
3.2.3.$. Fin de paralelismo (sincronizacin) ..................................................................................64
3.2.3.6. Salto de etapas ......................................................................................................................64
3.2.3.7. Ciclo .......................................................................................................................................6$
3.2.3.8. Semforo ...............................................................................................................................6$
3.2.3.9. Acumulacin e reserva ........................................................................................................67
3.2.3.10. Paralelismo interpretado e paralelismo estructural .........................................................68
3.3. A SEMNTICA DO GRAFCET ......................................................................................... 69
3.3.1. As regras de evolucin ........................................................................................ 69
3.3.1.1. Regra 1: Situacin inicial .........................................................................................:...........69
3.3.1.2. Regra 2: Determinacin das transicins franquebeis .....................................................69
3.3.1.3. Regra 3: Franqueamento dunha transicin ........................................................................70
3.3.1.4. Regra 4: Evolucins simultneas ........................................................................................70
.
.
.
.
.
3.3.1.$. Regra $: Achvacin e desactivacin sunultnea dunha etapa .........................................7
3.3.2. Semntica temporal do modelo ........................................................................... 71
3.3.2.1. Postulados temporais ...........................................................................................................71
3.3.2.2. Algoritmos de interpretacin do Grafcet ...........................................................................72
3.3.2.3. Semiformalizacin da semntica do Grafcet: o xogador Grafcet ...................................72
3.3.2.4. Revisin dos postulados temporais baixo a hiptese de sincronismo forte ...................7$
3.3.2.$. Consideracin das ordes de forzado no xogador de Grafcet ...........................................78
3.3.2.6. Consideracins sobre o uso de das escalas temporais independentes ..........................79
3.3.3. Interpretacin temporal das accins ................................................................... 81
3.3.3.1. Accins continuas (tipo 1^ ..................................................................................................81
3.3.3.2. Accins impulsionais (tipo P) .............................................................................................81
3.3.3.3. Accins memorizadas (tipos S e R) ...................................................................................81
3.3.3.4. Accins condicionais (tipo C) .............................................................................................81
3.3.3.$. Accins temporizadas: retardadas (tipo D) e limitadas (tipo L) ......................................81
vii
ndice
3.3.3.6. Combinacin de accins .....................................................................................................82
3.3.3.7. Funcins operativas asociadas s accins ..........................................................................84
3.3.3.8. Resolucin de conflictos entre accins .............................................................................. 84
3.4. ^ MODELO MATEMTICO DO GRAFCET ........................................................................ 85
3.4.1. O contorno do modelo .........................................................................................

85
.
,.
3.4.2. Estructura estatica ............................................................................................... 86
3.4.3. Evolucin dinmica ............................................................................................. 87
3.4.4. Comparacin con outros formalismos ................................................................. 88
3.4.4.1. Grafcet e redes de Petri . ....................................................................................................... 88
3.4.4.2. Grafcet e mquinas de estados ............................................................................................89
3.4.4.3. Grafcet e StateC;harts ...........................................................................................................89
3.5. EXEMPLOS DE MODELADO ........................................................................................... 90
3.5.1. Automatizacin dun posto de fabricacin de bridas ........................................... 90
3.5.2. Automatizacin dunha cela de fabricacin flexible ............................................. 93
3.6. O EsTNDAR IEC 61131-3 E O SFC ............................................................................ 98
3.6.1. O SFC .................................................................................................................. 99
3.6.1.1. Etapas ....................................................................................................................................99
3.6.1.2. Transicins ............................................................................................................................99
3.6.1.3. Accins ..................................................................................................................................99
3.6.1.4. Eshucturas de control ........................................................................................................100
3.6.1.5. Regras de evolucin ...........................................................................................................101
3.6.2. Comentarios sobre o estndar IEC 61131-3 ..................................................... 102
3.7. CONCLUSINS ............................................................................................................ 104
CAPTULO 4. ANLISE DE APLICACINS GRAFCET .......................................................105
4.1. ESTRUCTURACIN E MTODOS UTILIZADOS NA ANLISE ........................................... 106
. . .
,
4.1.1. Caracteristicas sintacticas ................................................................................. 1 7
4.1.1.1. Estructuras de control bsicas ...........................................................................................107
4.1.1.2. Extensins s estructuras de control bsicas ..................................................................108
4.1.1.3. Accins e receptividades ...................................................................................................108
4.1.1.4. Identificacin ......................................................................................................................108
4.1.1.5. Estructuras xerrquicas ......................................................................................................109
, .
. .
4.1.2. Caracteristzcas semanticas ................................................................................
4.1.2.1. O algoritmo de interpretacin ...........................................................................................109
4.1.2.2. Semntica temporal das accins .......................................................................................110
4.1.2.3. Aplicacin das ordes de forzado .......................................................................................110
4.2. APLICACINS ANALIZADAS ........................................................................................ 111
4.2.1. GrafcetView ....................................................................................................... 111
4.2.1.1. Compoentes ......................................................................................................................111
4.2.1.2. O editor Grafcet ..................................................................................................................112
4.2.1.2.1. Estructuras de control .......................................................................... 112
4.2.1.2.2. Estructura xerrquica ........................................................................... 113
4.2.1.2.3. Accins e receptividades ..................................................................... 113
4.2.1.2.4. Identificacin ....................................................................................... 114
4.2.1.2.5. Anlise sintctica ................................................................................. 114
4.2.1.2.6. Simulacin e execucin ....................................................................... 114
4.2.1.2.7. O algoritmo de interpretacin .............................................................. 115
4.2.1.3. Conclusins .........................................................................................................................115
ndice
viii
4.2.2. MachineShop .. ................................................................................................... 116
4.2.2.1. Compoentes ..................................................................................................................... 116
4.2.2.2. O editor Grafcet .................................................................................................................117
4.2.2.2.2. Estructura xerrquica .................. .........................................................

.....................................................................
I
17
4.2.2.2.3. Accins e receptividades

4.2.2.2.4. Identificacin . ...................................................................................... 118
4.2.2.3. Conclusins ........................................................................................................................ 119
4.2.3. IsaGraph ........ .................................................................................................... 120
4.2.3.1. Compoentes .....................................................................................................................120
4.2.3.2. O editor Grafcet ................................................................................................................. 121
.
4.2.3.2.2. Estructura xerrquica ...........................................................................
4.2.3.2.4. Identificacin .. ..................................................................................... 122
4.2.3.3. Conclusins ........................................................................................................................123
4.2.4. PL7 ..................................................................................................................... 124
4.2.4.1. Compoentes ..................................................................................................................... 124
4.2.4.2. O editor Grafcet ................................................................................................................. 125
4.2.4.2.1. Estructuras de control . ......................................................................... 125
.
4.2.4.2.2. Estructura xerrquica ...........................................................................
4.2.4.2.3. Accins e receptividades . .................................................................... 126
4.2.4.2.4. Identificacin ....................................................................................... 126
4.2.4.3. Conclusins ........................................................................................................................ 127
4.2. 5. Visual I/O e Visual PLC .................................................................................... 127
4.2.5.1. Compoentes ..................................................................................................................... 127
4.2.5.2. O editor Crrafcet ................................................................................................................. 127
.
4.2.5.2.4. Identificacin ....................................................................................... 129
4.2.5.3. Conclusins ........................................................................................................................ 130
4.2.6. AutomGen .......................................................................................................... 130
4.2.6.1. Compoentes ..................................................................................................................... 130
4.2.6.2. O editor Giafcet ................................................................................................................. 130
4.2.6.2.1. Estructuras de control ...... .................................................................... 131
ix
ndice
.
. . . . . Estructura xerrquica ........................................................................... 132
4.2.6.2.4. Identificacin ....................................................................................... 133
4.2.6.2.6. Simulacin e execucin ........................................................................ 134
4.2.6.2.7. O algoritrno de interpretacin .............................................................. 134
4.2.6.3. Conclusins .........................................................................................................................135
4.2. 7. Actwin ................................................................................................................ 135
4.2.7.1. Compoentes ......................................................................................................................136
4.2.7.2. O editor Grafcet ..................................................................................................................136
4.2.7.2.4. Identificacin ....................................................................................... 138
4.2.7.3. Conclusins .........................................................................................................................138
4.2.8. WinGrafcet ......................................................................................................... 139
4.2.8.1. Compoentes ......................................................................................................................139
4.2.8.2. O editor Grafcet ..................................................................................................................139
4.2.8.2.4. Identificacin ................................................................................ ... 140
4.2.8.3. Conclusins .........................................................................................................................141
4.2.9. Graf7-C .............................................................................................................. 141
4.2.9.1. Compoentes ......................................................................................................................141
4.2.9.2. O editor Grafcet ..................................................................................................................141
4.2.9.2.4. Identificacin ....................................................................................... 144
4.2.9.3. Conclusins .........................................................................................................................145
4.3. CONCLUSINS ............................................................................................................ 146
CAPTULO 5. PROPOSTA DUIV METAMODELO PARA O GRAFCET ..............................155
5.1. METAMODELO PARA A SINTAXE DO GRAFCET ........................................................... 156
5.1.1. Estructura de paquetes ...................................................................................... 156
5.1.1.1. Metaclases do metamodelo UML ....................................................................................156
5.1.2. Sintaxe abstracta do modelo .............................................................................. 160
5.1.2.1. O paquete Grafcet Data ....................................................................................................160
ndice
5.1.2.2. O paquete Grafcet Core ................................................................................................... 163
5.1.2.3. O paquete Grafcet Actions ............................................................................................... 166
5.1.2.4. O paquete Grafcet Hierarchy .......................................................................................... 168
5.1.3. Semntica esttica do modelo .......................................................................... 170
5.1.3.1. Clculo do peche transitivo .............................................................................................. 170
5.1.3.2. Regras semnticas .............................................................................................................^171
5.2. IMPLEMENTACIN DO METAMODELO ......................................................................... 177
5.2.1. Funcionalidade bsica ...................................................................................... 177
5.2.1.1. Identificacin ..................................................................................................................... 177
5.2.1.2. Notificacins ......................................................................................................................179
5.2.2. Clases da librara .............................................................................................. 180
5.2.3. Implementacin das operacins bsicas ........................................................... 183
5.2.3.1. Insercin dun nodo ............................................................................................................ 183
5.2.3.2. Insercin dunha macroetapa ............................................................................................ 183
5.2.3.3. Eliminacin dun nodo .......................................................................................................183
5.2.3.4. Eliminacin dun grafcet conexo ...................................................................................... 184
5.2.3.5. Modificacin do identificador dun nodo ........................................................................ 184
5.3. EXEMPLOS DE MODELADO ......................................................................................... 193
5.3.1. Estructuras bsicas ............................................................................................ 193
5.3.1.1. Secuencia ...........................................................................................................................193
5.3.1.2. Seleccin de secuencia ...............................................:.....................................................194
5.3.1.3. Paralelismo ......................................................................................................................... 195
5.3.1.4. Semforo ............................................................................................................................196
5.3.1.5. Accins ...............................................................................................................................197
5.3.2. Xerarqua ........................................................................................................... 198
5.3.2.1. Macroetapas .......................................................................................................................198
5.3.2.2. Ordes de forLado ............................................................................................................... 200
5.4. CONCLUSINS ............................................................................................................ 201
,
.
CAPITULO 6. COMPILACION DE MODELOS GRAFCET ...................................................203
6.1. ^ PROCESO DE COMPILACIN .................................................................................... 203
6.1.1. Os arquivos de entrada ...................................................................................... 204
6.1.2. O resultado da compilacin .............................................................................. 205
6.1.3. As aplicacins externas ..................................................................................... 206
6.1.4. As operacins realizadas polo compilador ....................................................... 207
6.2. A ESTRUCTURA DO COMPILADOR GRAFCET ............................................................... 208
6.2.1. A informacin interna do compilador ............................................................... 209
6.2.2. Acceso informacin interna do compilador ................................................... 210
211
6.2.3. As fases do compilador ..................................................................................

6.2.4. Iniciacin e execucin das fases do compilador ............................................... 213
6.3. CONSIDERACINS SOBRE A UTILIZACIN DE C++ NOS MODELOS GRAFCET ............... 21 S
6.3.1. Extensin da sintaxe C++ para inclur os operadores Grafcet ........................ 216
6.3.1.1. Sintaxe dos operadores Grafcet ....................................................................................... 216
6.3.1.2. Modificacin da gramtica do C++ ................................................................................ 217
6.3.2. Implementacin dos operadores Grafcet .......................................................... 220
6.3.3. Substitucin de operadores e varibeis .............................................:............... 221
6.3.3.1. Substitucin de eventos .................................................................................................... 221
6.3.3.2. Substucin de temporizadores ....................................................................................... 226
xi
ndice
6.3.3.3. Substitucin de varibeis ...................................................................................................227
6.4. INFORMACIN PARA A EXECUCIN DUN MODELO GRAFCET ....................................... 231
6.5. IMPLEMENTACIN DAS FASES DO COMPILADOR GRAFCET ......................................... 235
6.5.1. Fase principal ("SFCCompiler') ...................................................................... 23S
6.5.1.1. Procesamento de macroetapas ("SFCMacroProcessor'^ ..............................................235
6.5.1.2. Recopilacin inicial de informacin ("SFCInfoHarvester") .........................................236
6.5.1.2.1. Recopilacin de Informacin ............................................................... 236
6.5.1.2.2. Asignacin de identificadores numricos ............................................ 238
6.5.1.3. Proc.esamento das ordes de forzado ("SFCFOrderCompiler'^ .....................................241
6.5.1.4. Procesamento das asociacins de accin ("SFCAssociationPreprocessor") ...............242
6.5.1.5. Procesamento do cdigo das accins ("SFCActionCodeCompiler") ..........................242
6.5.1.5.1. Preprocesamento do cdigo C++ ("CPPActionPreprocessor") ........... 242
6.5.1.5.2. Procesamento dos temporizadores ("TimerPreprocessor") ................. 243
6.5.1.5.3. Procesamento de eventos e varibeis ("SFCEventCompiler") ............ 243
6.5.1.6. Procesamento das condicins das asociacins ("SFCActionConditionCompiler")...260
6.5.1.7. Procesamento das condicins de transicin ("SFCReceptivityCompilei") .................260
6.5.1.8. Procesamento das condicins dos temporizadores ("SFCTimerConditionCompilec'') 260
6.5.1.9. Xeracin do cdigo fonte da DLL ("SFCDLLGeneratoi'') ..........................................260
6.5.1.10. Compilacin da DLL ("SFCCPPCompilei") ...............................................................266
6.6. CONCLUSINS ............................................................................................................ 266
,
,
CAPITULO 7. A MAQUINA VIRTUAL ......................................................................................269
7.1. A ARQUITECTURA DA MQUINA VIRTUAL .................................................................. 269
7.1.1. Estructuracin da arquitectura: os mdulos ..................................................... 270
7.1.1.1. Mdulos simples: a interface IModule .............................................................................270
7.1.1.2. Mdulos complexos: a interface IStructuredModule .....................................................271
7.1.1.3. Almacns de mdulos: a interface IModuleStore ...........................................................272
7.1.1.4. Almacns de configuracins: a interface IConfigurationStore .....................................273
7.1.1.5. Carga e descarga dinmica de mdulos ...........................................................................274
7.1.1.6. Exemplo da utilizacin de mdulos .................................................................................275
7.1.2. Operativa da arquitectura: os procesos ............................................................ 281
7.1.2.1. As funcionalidades dun proceso .......................................................................................282
7.1.2.2. O ciclo de vida dun proceso ..............................................................................................283
7.1.2.3. A implementacin dos procesos ...........................................................................
7.1.2.3.1. O bloqueo da execucin dun proceso .................................................. 285
7.1.2.3.2. Invocacin dos mtodos Suspend e Resume dende outro proceso....... 285
7.1.2.3.3. Invocacin do mtodo Finish dende outro proceso ............................. 286
7.1.2.3.4. Inicio dunha operacin asncrona dende outro proceso ....................... 287
287
7.1.2.4. A comunicacin entre procesos ..................................................................................

7.1.2.4.1. Paso de mensaxes entre procesos ......................................................... 288
7.1.2.4.2. Notificacin da finalizacin de operacins asncronas ........................ 289
7.1.2.5. Exemplo da utilizacin de procesos .................................................................................293
7.1.3. A arquitectura de procesos da mquina virtual ..................................:............. 296
7.1.4. Implementacin da arquitectura da mquina virtual ........................................ 296
7.2. O SUBSISTEMA DE E/S ............................................................................................... 298
7.2.1. Os "drivers " de E/S ........................................................................................... 298
7.2.1.1. As funcionalidades dun "driver" de FIS ..........................................................................298
7.2.1.2. Configuracin dun "drivei" de FJS ..................................................................................299
xii
ndice
7.2.1.2.1. Exemplo de configuracin dun dispositivo de E/S .............................. 303
7.2.1.3. Lectura e escritura de valores ........................................................................................... 304
7.2.1.4. Asignacin de varibeis a puntos de FlS ........................................................................ 306
7.2.1.4.1. Asignacin de varibeis a puntos de E/5 ............................................. 306
7.2.1.4.2. Monitorizacin de varibeis de entrada ............................................... 307
7.2.1.4.3. Actualizacin de varibeis de sada ..................................................... 309
7.2.2. Xestin da E/S .................................................................................................... 309
7.2.3. Simulacin de E/S .............................................................................................. 311
7.2.3.1. O intercambio de informacin de simulacin ................................................................

7.2.3.1.1. Modelado do intercambio de informacin de simulacin ...................
7.2.3.1.2. O formato das mensaxes ......................................................................
7.2.3.1.3. O protocolo de intercambio de informacin ........................................
311
312
313
314
7.2.3.2. Modelado dun mediador xenrico ................................................................................... 314
7.2.3.3. Implementacin dun mediador en redes TCP/IP ........................................................... 315
7.2.3.4. Implementacin dun simulador de dispositivos de F/S ................................................ 318
7.2.3.4.1. Implementacin da interface IDeviceDriver ....................................... 319
7.3. ^ NCLEO DA MQUINA VIRTUAL ............................................................................. 321
7.3.1. A base de datos de E/S ....................................................................................... 322
7.3.1.1. Funcionalidades da base de datos de E/S ....................................................................... 322
7.3.1.2. Implementacin da base de datos de FJS ........................................................................ 322
7.3.1.3. Actualizacin de valores e sincronizacin da imaxe do proceso ................................. 325
7.3.2. Temporizadores ................................................................................................. 326
7.3.2.1. Temporizador simple ..............................................................................................:......... 326
7.3.2.2. Temporizador mltiple ..................................................................................................... 327
7.3.3. Acceso aos servicios do ncleo ......................................................................... 329
7.4. ^ SUBSISTEMA DE XESTIN DA CONFIGURACIN ....................................................... 329
7.4.1. Formato das mensaxes ...................................................................................... 330
7.4.2. Protocolo de intercambio de mensaxes ............................................................. 331
7.4.3. Servicios remotos da mquina virtual ............................................................... 332
7.4.4. Modelado do acceso remoto mquina virtual ................................................ 334
7.4.4.1. Implementacin do acceso remoto en redes TCP/lP .................................................... 335
7.4.4.2. Implementacin do acceso simultneo a mltiples mquinas viriuais ........................ 336
7.5. ^ SUBSISTEMA DE APLICACIN .................................................................................. 340
7.6. CONCLUSINS ............................................................................................................ 341
CAPTULO 8. O INTRPRETE DE MODELOS GRAFCET ..................................................347
8.1. ARQUITECTURA DO INTRPRETE ................................................................................ 348
$.2. IMPLEMENTACIN DA ARQUITECTURA DO INTRPRETE .............................................. 348
8.3. CONFIGURACIN DO INTRPRETE .............................................................................. 3S0
8.3.1. Mdulos substitubeis no intrprete .................................................................. 351
8.3.1.1. A politica de acceso aos eventos ...................................................................................... 351
8.3.1.2. A politica de reaccin ....................................................................................................... 352
8.3.1.3. O algoritmo de interpretacin .......................................................................................... 353
8.3.1.4. A poltica de evolucin ..................................................................................................... 354
8.3.1.5. A poltica de execucin ...........................................................,........................................ 354
8.3.2. Parmetros de interpretacin dos modelos ....................................................... 354
8.4. FUNCIONAMENTO DO INTRPRETE ............................................................................. 354
.,
. ,
.
8.4.1. Ciclo de execucion do interprete .......................................................................
xiii
ndice
8.4.2. Obtencin de eventos de entrada ....................................................................... 357
8.4.3. Iniciacin e evolucin do modelo ...................................................................... 357
8.4.4. Actualizacin das sadas do proceso ................................................................. 359
8.4.5. Poltica de evolucin ......................................................................................... 359
8.4.6. Deteccin de ciclos estacionarios ....................................................................... 359
8.5. INFORMACIN DE INTERPRETACIN DUN MODELO: O XOGO GRAFCET ....................... 362
8.5.1. Implementacin do xogo Grafcet ....................................................................... 363
8.5.1.1. Consulta e actualizacin da situacin do modelo ...........................................................364
8.5.1.2. Consulta e sincronizacin das escalas de tempo .............................................................367
8.5.1.3. Consulta e actualizacin de eventos .................................................................................367
8.5.1.4. Consulta e actualizacin de varibeis ...............................................................................367
8.5.1.5. Acceso s receptividades, accins e temporizadores activos ........................................368
8.5.1.6. Acceso s funcins co cdigo C++ de condicins e accins ........................................368
8.5.2. Informacin para cada escala de tempo .......................................:.................... 368
8.6. A POLTICA DE EXECUCIN ........................................................................................ 370
8.6.1. Avaliacin e franqueamento de transicins ....................................................... 371
8.6.2. Xestin de temporizacins ................................................................................. 375
8.6.3. Execucin de accins ......................................................................................... 381
8.6.4. Consulta e modificacin de varibeis ................................................................ 385
8.7. CONCLUSINS ............................................................................................................ 387
CAPTULO 9. CONCLUSINS E FUTURAS LIAS DE INVESTIGACIN .......................389
389
............................................................................................. 391
9.3. FUTURAS LIAS DE INVESTIGACIN ........................................................................... 391
9.1. CONCLUSINS ............................................................................................................

9.2. MELLORAS A REALIZAR
ANEXO A.
CARACTERSTICAS DO SFC NO ESTNDAR IEC 61131-3 .......................393
ANEXO B.
FUNCIONALIDADES BSICAS DA LIBRARA . ...........................................401
B.1. CONTEDORES ............................................................................................................ 401
B.2. VARIBEIS E DECLARACINS .................................................................................... 405
ANEXO C.
COMPILACIN DA DLL XERADA NO COMPILADOR GRAFCET .........409
ANEXO D.
GRAMTICA ANTLR .........................................................................................413
ANEXO E.
,
GRAMATICA SORCERER .................................................................................421
,
,
ANEXO F.
ACCESO REMOTO A MAQUINA VIRTUAL ..............':..................................433
F.1. CDIGOS DAS MENSAXES ........................................................................................... 433
F.2. CARGA E DESCARGA DE DLLS ................................................................................... 434
F.2.1. Carga dunha DLL ............................................................................................. 434
F.2.2. Descarga dunha DLL ........................................................................................ 434
F.2.3. Descarga de todas as DLLs ............................................................................... 434
F.3. CARGA E DESCARGA DE TBOAS DE E/S .................................................................... 434
F.3.1. Carga dunha tboa de E/S ................................................................................ 434
F.3.2. Descarga dunha tboa de E/S ........................................................................... 434
F.4. CARGA, DESCARGA E EXECUCIN DE MODELOS ......................................................... 434
F.4.1. Carga dun modelo ............................................................................................. 435
F.4.2. Descarga dun modelo ........................................................................................ 435
ndice
xiv
F.4.3. Inicio da execucin dun modelo ........................................................................ 435
F.4.4. Detencin da execucin dun modelo ................................................................. 435
F.4.5. Continuacin da execucin dun modelo ........................................................... 43S
F.S. XESTIN DE CONFIGURACINS . ................................................................................. 436
F.S.1. Engadir unha configuracin ............................................................................. 436
F.5.2. Eliminar unha configuracin ............................................................................ 4'36
F.5.3. Activar unha configuracin ............................................................................... 436
F.5.4. Consultar a configuracin activa ...................................................................... 436
F.S.S. Consultar as configuracins dispobeis .......................................................... 437
F.5.6. Activar un mdulo nunha configuracin ........................................................... 437
F.5.7. Desactivar un mdulo nunha configuracin ..................................................... 437
F.6. CONSULTA DA ESTRUCTURA DE MDULOS DA MQUINA VIRTUAL . ........................... 437
F.6.1. Consultar a estructura da mquina virtual ....................................................... 437
F.6.2. Consultar os mdulos dispobeis nun almacn de mdulos ............................ 437
F.7. CONSULTA DA INFORMACIN DE CONFIGURACIN DOS "DRIVERS" DE E/S ............... 438
F.7.1. Consulta da informacin de configuracin dun "driver" de E/S ..................... 438
F.. DESCONEXIN E FINALIZACIN DA EXECUCIN DA MQUINA VIRTUAL .................... 438
F.8.1. Desconexin do cliente ..................................................................................... 438
F.8.2. Apagado da mquina virtual ............................................................................. 438
BIBLIOGRAFIA .. ........................................................................................................................... 439
Lista de figuras
Figura I.1: Arquitectura dunha ferramenta CACE dependente das ferramentas .................................... 29
Figura 1.2: Arquitectura de referencia para ferramentas CACE independentes das ferramentas.......... 29
Figura 2.1. Estructura dunha unidade de proceso ................................................................................... 36
Figura 2.2. Niveis lxicos nun sistema de control industrial . .................................................................. 37
Figura 2.3. Arquitectura fisica dun sistema de control industrial . .......................................................... 39
Figura 2.4. Formas de estructurar un sistema de control utilizando Grafcet: a) o Grafcet
utilizado nalgn dos mdulos que forman o sistema de control; b) o Grafcet

utilizado para a coordinacin dos mdulos do sistema de control; e c) o sistema de
control especificado completamente utilizando o Grafcet . ............................................... 46
Figura 2.5. Arquitectura da ferramenta proposta: a) subsistema de desenvolvemento; b)
configuracin co subsistema de desenvolvemento e execucin no mesmo equipo; e c)

subsistema de execucin . ..................................................................................................... SO
Figura 2.6. Proceso de desenvolvemento dunha aplicacin coa ferramenta implementada . .................. SO
Figura 2. 7. Formas de integracin da ferramenta con outras aplicacins: a) mediante cdigo fonte
C++; b) mediante mdulos compilados; e c) mediante modelos baseados no
metamodelo Grafcet ............................................................................................................. 52
Figura 3.1. Representacin grfica de: (a) unha etapa inactiva; (b) unha etapa activa; (c) unha
etapa inicial . ........................................................................................................................ S7
Figura 3.2. Representacin grfica dunha transicin .............................................................................. 57
Figura 3.3. Representacin grfica dos arcos orientados . ...................................................................... 58
Figura 3.4. Representacin grfica dunha transicin con receptividade asociada ................................. 58
Figura 3.5. Representacin grfica dunha accin coas tres seccins definidas polo estndar: (a)
tipo; (b) descricin; e(c) identificacin . ............................................................................. 59
Figura 3.6. Representacin grfica de varias accins asociadas mesma etapa: (a) en vertical; e
(b) en horizontal ...................................................................................................................59
Figura 3.7. Representacin grfica de etapas: (a) fonte; e (b) sumidoiro ............................................... 60
Figura 3.8. Representacin grfica de transicins: (a) fonte; e (b) sumidoiro . ...................................... 60
Figura 3.9. Representacin grfica dunha: (a) macroetapa; e(b) a sa expansin . .............................. 60
Figura 3.10. Xerarqua estructural do Grafcet . ....................................................................................... 61
Figura 3.11. Exemplo dunha xerarqua de forzado . ................................................................................ 62
Figura 3.12. Representacin grfica dunha secuencia . ........................................................................... 64
Figura 3.13. Representacin grfica dunha seleccin de secuencia . ...................................................... 64
Figura 3.14. Representacin grfica do fcnal dunha seleccin de secuencia . ......................................... 64
Figura 3.1 S. Representacin grfca do comezo de varias secuencias paralelas .................................... 64
Figura 3.16. Representacin grfica do final de varias secuencias paralelas . ....................................... 65
Figura 3.17. Exemplo de sincronizacin: (a) a transicin 1 non est validada; (b) a transicin 1 si
est validada ........................................................................................................................ 65
Figura 3.18. Representacin grfica de: a) salto de etapas; e b) un ciclo . ............................................. 6S
xv
Lista de figuras
xvi
Figura 3.19. Representacin grfica dun semforo -etapa 30- que proporciona un mecanismo
de exclusin mutua entre das secuencias ........................................................................... 66
Figura 3.20. Representacin grfzca dun semforo -etapa 200- que proporciona un mecanismo .
de exclusin mutua entre varias secuencias . ....................................................................... 66
Figura 3.21. Representacin grfica dunha estructura que proporciona un mecanismo de
alternancia entre das secuencias de accins . .................................................................... 67
Figura 3.22. Exemplo de alternancia das secuencias de fabricacin e ensamblaxe, coordinadas
mediante as operacins de depsito e recollida de pezas . .................................................. 67
Figura 3.23. Representacin grfica dunha estructura que realiza: a) unha acumulacin; e b) unha
reserva . .. ... . . .. .... . . . ... . .. ... .......... ............. .. .... ... . .. ........ ... ........ ..... ..... ... ... .... ......... ... . ...... . . ... .... . 68
Figura 3.24. Exemplo de activacin inicial dun Grafcet . ........................................................................ 69
Figura 3.25. Estados dunha transicin: (a) transicin non validada; (b) transicin validada, e(c)
transicin validada e franquebel . ...................................................................................... 70
Figura 3.26. Franqueamento da transicin 1: (a) situacin anterior; e(b) situacin posterior ............. 70
Figura 3.27. Franqueamento simultneo das transicins 1 e 2: (a) situacin anterior; e(b)
situacin posterior . .............................................................................................................. 70
Figura 3.28. Activacin e desactivacin simultnea da etapa 2: (a) situacin anterior; e(b)
situacin posterior . .............................................................................................................. 71
Figura 3.29. Demostracin do non determinismo do algoritmo SRS . ..................................................... 73
Figura 3.30. Xogador SRS de modelos Grafcet . ...................................................................................... 73
Figura 3.31. Xogador ARS de modelos Grafcet . ...................................................................................... 7S
Figura 3.32. Escalas de tempo interna e externa na interpretacin do Grafcet ...................................... 76
Figura 3.33. Xogador ARS con das escalas de tempo baixo a hiptese de sincronismo forte ............... 77
Figura 3.34. Xogador ARS de modelos Grafcet con ordes de forzado . ................................................... 79
Figura 3.35. Representacin dilatada do tempo interno .......................................................................... 79
Figura 3.36. Posbeis interpretacins dun evento externo na escala de tempo interna: (a) como
unha constante; e(b) como un evento de duracin nula . .................................................... 80
Figura 3.37. Exemplo de interpretacins dun mesmo Grafcet considerando: (a) %b e TX3 na escala
externa; (b) ib na escala externa e%X3 na interna; (c) %^ na escala interna e%X3 na
externa; e(d) %b e%`X3 na escala interna . .......................................................................... 80
Figura 3.38. Cronograma dunha accin tipo N ....................................................................................... 82
Figura 3.39. Cronograma dunha accin tipo P . ...................................................................................... 82
Figura 3.40. Cronograma dunha accin memorizada . ............................................................................ 82
Figura 3.41. Cronograma dunha accin condicional .............................................................................. 82
Figura 3.42. Cronograma dunha accin retardada ................................................................................. 82
Figura 3.43. Cronograma dunha accin limitada . ......................:........................................................... 83
Figura 3.44. Cronograma dunha accin DS ............................................................................................ 83
Figura 3.45. Cronograma dunha accin SD ............................................................................................ 83
Figura 3.46. Cronograma dunha accin SL . ........................................................................................... 83
Figura 3.47. Intercambio de informacin entre o modelo e o seu contorno ............................................ 85
Figura 3.48. Posto de fabricacin de bridas (vista 1) .............................................................................. 91
Figura 3.49. Posto de fabricacin de bridas (vista 2) .............................................................................. 92
Figura 3.50. Grafcet principal de control do posto de fabricacin de bridas . ........................................ 92
Figura 3.51. Contidos da macro 100 que controla o proceso de taladrado dunha peaa ......................... 93
Figura 3.52. Cela de fabricacin flexbel . ............................................................................................... 94
Figura 3.53. Grafcet principal de control do robot 1 . ............................................................................. 97
Figura 3.54. Interface externa dun bloque de control de accins . ........................................................ 100
Figura 3.SS. Estructura interna dun bloque de control de accins . ......................................................101
Figura 3.56. Exemplo do uso dos bloques de control de accins: (a) SFC con distintos tipos de
accins; e(b) bloques de control de accin equivalentes . ................................................101
Figura 3.57. Exemplos de: (a) SFC inseguro; e(b) SFC con etapas inalcanzbeis ..............................102
Figura 4.1. Grafcet utilizado para comprobar o tipo de interpretacin ................................................109
xvii
Lista de figuras
Figura 4.2 Grafcet utilizado para comprobar o manexo de eventos e varibeis durante as
evolucins internas . ...........................................................................................................110
Figura 4.3. Grafcet utilizado para comprobar a aplicacin das ordes de forzado durante as
evolucins internas . ........................................................................................................... I11
Figura 4.4. Contidos do VI que proporciona a estructura dunha aplicacin GrafcetView (versin
multitarefa) . ..........................................................................................................:............112
Figura 4.5. Das posbeis interfaces para a animacin das evolucins dun grafcet no GrafcetView...115
Figura 4.6. Interface da barra de tarefas do MachineShop ...................................................................116
Figura 4.7. Interface do MachineLogic ..................................................................................................118
Figura 4.8. Interface do editor SFC no IsaGraph ..................................................................................122
Figura 4.9. Editor Grafcet do PL7 . ........................................................................................................125
Figura 4.10. Editor Grafcet do Visual I/O e Visual PLC .......................................................................128
Figura 4.11. Interface do programa Automgen ......................................................................................131
Figura 4.12. Interface da aplicacin ActWin . ........................................................................................137
Figura 4.13. Interface do editor Grafcet do WinGrafcet . ......................................................................140
Figura 4.14. Interface do editor Grafcet do Graf7C ..............................................................................142
Figura 5.1. Estructura de paquetes do metamodelo Grafcet . ................................................................156
Figura 5.2. Dependencias do metamodelo UML ....................................................................................157
Figura 5.3. Diagrama parcial das clases do metamodelo UML ............................................................ I57
Figura 5.4. Diagrama de clases do paquete Grafcet Data . ....................................................................161
Figura S. S. Diagrama de clases do paquete Grafcet Core: elementos bsicos ......................................164
Figura 5.6. Diagrama de clases do paquete Grafcet Core: elementos xerrquicos ............:..................164
Figura 5.7. Diagrama de clases do paquete Grafcet Actions . ...............................................................167
Figura 5.8. Diagrama de clases do paquete Grafcet Hierarchy .............................................................169
Figura 5.9. Diagrama de clases do repositorio de identificadores ........................................................178
Figura 5.10. Diagrama das clases implicadas no mecanismo de identificacin . ..................................178
Figura 5.11. Diagrama das clases implicadas no mecanismo de notificacin . .....................................179
Figura 5.12. Diagrama das clases que implementan a declaracin de varibeis . ................................181
Figura 5.13. Diagrama das clases que implementan accins e receptividades .....................................181
Figura 5.14. Diagrama das clases abstractas que dan soporte estructura dos modelos Grafcet.......182
Figura S.1 S. Diagrama das clases que implementan a estructura dos modelos Grafcet .......................183
Figura 5:16. Secuencia de mensaxes da insercin dun nodo nun grafcet parcial . ................................187
Figura 5.17. Secuencia de mensaxes da insercin dun nodo nun grafcet conexo ..................................188
Figura 5.18. Secuencia de mensaxes da insercin dun nodo na macroexpansin dunha
macroetapa . .......................................................................................................................189
Figura 5.19. Secuencia de mensaxes da insercin dunha macroetapa nun grafcet parcial . .................190
Figura 5.20. Secuencia de mensaxes da eliminacin dun nodo do modelo . ..........................................191
Figura 5.21. Secuencia de mensaxes da eliminacin dun grafcet conexo do modelo ............................191
Figura 5.22. Secuencia de mensaxes da modifccacin do identificador dun nodo includo nunha
macroexpansin . ................................................................................................................192
Figura 5.23. Exemplo de: a) secuencia; e b) representacin co metamodelo proposto . .......................194
Figura 5.24. Exemplo de: a) seleccin de secuencia; e b) representacin co metamodelo proposto....195
Figura 5.25. Exemplo de: a) secuencias paralelas; e b) representacin co metamodelo proposto.......196
Figura 5.26. Exemplo de: a) secuencias exclusivas (semforo); e b) representacin co metamodelo
proposto . .. . . . .. .. . .... . ...... . . ....... ... ..... .. .... ............ ..... .... . ..... . . .. .... .... . . ......... .... ....... .. ...... .... .......197
Figura 5.27. Exemplo de: a) accins; e b) representacin co metamodelo proposto ...........................197
Figura 5.28. Exemplo de: a) macroetapa e macroexpansin; e b) representacin co metamodelo
proposto . . .... . ...... .... . ....... ..... ... ... .. .... . ... .. . ... .. .... .. . ....... ........ . . . .... .... .. .. ... ..... .. . .. . ..... ... .... ..... ...199
Figura 5.29. Exemplo de: a) ordes de forzado; e b) representacin co metamodelo proposto . ............ 200
Figura 6.1. Proceso de compilacin dun modelo Grafcet ...................................................................... 204
Figura 6.2. Estructura de directorios utilizada polo compilador Grafcet . ............................................ 205
Figura 6.3. Diagrama de clases da estructura de fases do compilador Grafcet .................................... 208
Figura 6.4. Diagrama de clases das fases simples do compilador Grafcet . .......................................... 211
Lista de figuras
xviii
Figura 6.5. Diagrama de clases das fases compostas do compilador Grafcet . ..................................... 211
Figura 6.6. Estructura de fases do compilador Grafcet ......................................................................... 211
Figura 6. 7. Secuencia das mensaxes intercambiadas entre a fase principal e as subfases do
compilador Grafcet ............................................................................................................ 214
Figura 6.8. Diagrama de clases da informacin utilizada para a execucin dun modelo Grafcet. ...... 232
Figura 6.9. Tratamento de accins temporizadas: a) accin retardada e limitada no tempo; e b)

modificacin realizada polo compilador Grafcet .............................................................. 238
Figura 6.10. Exemplo do funcionamento da fase SFCInfoHarvester: a) modelo Grafcet; e b)
diagrama de obxectos da informacin recopilada pola fase . ............................................ 239
Figura 6.11. Exemplo do funcionamento da fase SFCInfoHarvester: a) modelo Grafcet; e b)
diagrama de obxectos da informacin recopilada pola fase . ............................................ 240
Figura 7.1. Estructura de capas da mquina virtual . ............................................................................ 270
Figura 7.2. Diagrama das clases que definen os mdulos e as sas funcionalidades ........................... 272
Figura 7.3. Exemplo de utilizacin dos mdulos: a) arquitectura flexbel da aplicacin; b)
configuracins vlidas; c) diagrama de obxectos da implementacin; e d) diagramas
de obxectos das configuracins vlidas ............................................................................. 276
Figura 7.4. Diagrama de estados do ciclo de vida dun proceso da mguina virtual . ........................... 283
Figura 7.5. Diagrama das clases gue modelan o mecanismo de paso de mensaxes entre procesos. .... 288
Figura 7.6. Secuencias de mensaxes intercambiadas no envo e recepcin dunha mensaxe ................. 289
Figura 7.7. Exemplo de utilizacin dos procesos: a) arquitectura da aplicacin; e b) diagrama de
obxectos da implementacin .............................................................................................. 295
Figura 7.8. Arquitectura de procesos da mquina virtual . .................................................................... 296
Figura 7.9. Diagrama das clases que modelan a arquitectura da mquina virtual . ............................. 297
Figura 7.10. Diagrama das clases que modelan os subsistemas da mquina virtual ............................ 297
Figura 7.11. Diagrama das clases que modelan a configuracin dun dispositivo de E/5 ..................... 300
Figura 7.12. Diagrama de obxectos da informacin de configuracin dunha porta serie .................... 305
Figura 7.13. Conexins dos xestores de E/S da mquina virtual ........................................................... 309
Figura 7.14. Diagrama das clases que modelan os xestores de E/5 ...................................................... 310
Figura 7.1 S. Tcnicas para a simulacin de E/S na mquina virtual: a) utilizando un xestor de E/S;
e b) utilizando un "driver" . ................................................................................................ 312
Figura 7.16. Exemplo dun ambiente de simulacin distribuido ............................................................. 312
Figura 7.17. Ambiente de simulacin distribudo utilizando. o patrn Productor / Mediador /
Consumidor ........................................................................................................................ 313
Figura 7.18. Formato das mensaxes utilizadas para o intercambio de informacin de simulacin. .... 314
Figura 7.19. Secuencia de mensaxes do protocolo de intercambio de informacin de simulacin....... 314
Figura 7.20. Diagrama das clases utilizadas para modelar un mediador ............................................. 31 S
Figura 7.21. Diagrama das clases utilizadas para implementar o mediador TCP/IP ........................... 316
Figura 7.22. Secuencia de mensaxes do intercambio de informacin de simulacin utilizando un
mediador TCP/IP ............................................................................................................... 317
Figura 7.23. Diagrama das clases utilizadas para a implementacin dun "driver" TCP/IP de
simulacin . ......................................................................................................................... 318
Figura 7.24. Secuencia de mensaxes do intercambio de informacin de simulacin utilizando un
..driver" TCP/IP ................................................................................................................ 319
Figura 7.25. Diagrama de clases para a asignacin de varibeis no "driver" de simulacin ............. 320
Figura 7.26. Estructura da base de datos de E/5 ................................................................................... 322
Figura 7.27. Diagrama das clases que modelan a base de datos de E/5 ............................................... 324
Figura 7.28. Secuencia das mensaxes intercambiadas na creacin dunha nova entrada na BD.......... 325
Figura 7.29. Secuencia das mensaxes intercambiadas no procesamento das mensaxes recibidas
dende o subsistema de E/S . ................................................................................................ 326
Figura 7.30. Servicios proporcionados polo temporizador bsico: a) temporizacin con bloqueo;
b) temporizador con notificacin asncrona; e c) temporizador con notificacin
peridica . ........................................................................................................................... 328
Figura 7.31. Secuencia de mensaxes intercambiadas na planificacin de temporizadores . ................. 330
xix
Lista de figuras
Figura 7.32. Formato das mensaxes utilizadas no acceso remoto aos servicios da mquina virtual. .. 331
Figura 7.33. Tipos de mensaxes utilizadas no acceso remoto aos servicios da mquina virtual. ......... 331
Figura 7.34. Protocolo de intercambio de mensaxes no acceso remoto aos servicios da mquina
virtual: a) orde simple sen resposta (resultado correcto); b) orde simple sen resposta
(resultado errneo); c) orde simple con resposta; e d) orde mltiple sen resposta
(resultado correcto) . ................................................................................................^.........332
Figura 7.35. Diagrama das clases utilizadas para modelar o acceso dun cliente aos servicios
remotos da mquina virtual . .............................................................................................. 33S
Figura 7.36. Clases utilizadas para modelar o acceso dun cliente a mltiples mquinas virtuais en
redes TCP/IP ...................................................................................................................... 337
Figura 7.37. Secuencia de mensaxes intercambiadas no acceso aos servicios remotos da mquina
virtual nunha rede TCP/IP ................................................................................................. 338
Figura 7.38. Secuencia das mensaxes intercambiadas para a creacin dunha conexin coa
mquina virtual .................................................................................................................. 342
Figura 7.39. Secuencia das mensaxes intercambiadas para a solicitude de carga dunha DLL na
mquina virtual ..................................................................................................................343
Figura 7.40. Secuencia das mensaxes intercambiadas para o procesamento dun evento detectado
no proceso nunha aplicacin dirixida por eventos . ........................................................... 344
Figura 7.41. Secuencia das mensaxes intercambiadas para o procesamento dun evento detectado
no proceso nunha aplicacin cclica . ................................................................................ 345
Figura 8.1. Arquitectura de mdulos do ntrprete Grafcet ................................................................... 348
Figura 8.2. Diagrama das clases utilizadas para implementar a estructura do intrprete Grafcet...... 350
Figura 8.3. Diagrama de clases dos mdulos utilizados para configurar o intrprete Grafcet. ........... 3S1
Figura 8.4. Grafcet utilizado como exemplo .......................................................................................... 352
Figura 8. S. Secuencia de mensaxes do ciclo de execucin do intrprete Grafcet .................................. 356
Figura 8.6. Secuencia de mensaxes da obtencin de novos eventos de entrada .................................... 357
Figura 8.7. Secuencia de mensaxes da evolucin inicial dun modelo Grafcet . ..................................... 3S8
Figura 8.8. Secuencia de mensaxes da evolucin externa dun modelo Grafcet ..................................... 3S9
Figura 8.9. Secuencia de mensaxes da actualizacin das sadas do proceso . ....................................... 360
Figura 8.10. Secuencia de mensaxes da evolucin interna dun modelo Grafcet . .................................. 361
Figura 8.11. Grafcet utilizado como exemplo . ....................................................................................... 362
Figura 8.12. Diagrama das clases utilizadas para modelar un xogo Grafcet . ...................................... 363
Figura 8.1 S. Semntica dos temporizadores: a) non redisparbel; e 6) redisparbel . ......................... 375
Figura 8.16. Diagrama de estados dun temporizador Grafcet . ............................................................. 377
Figura 8.17. Efecto da latencia de resposta no control dun temporizador: a) comportamento ideal;
e b) comportamento con latencia ....................................................................................... 378
Figura 8.18. Secuencia de mensaxes para a xestin das temporizacins Grafcet . ................................ 379
Figura 8.19. Diagrama de estados dun temporizador Grafcet con latencias de resposta ..................... 380
Figura 8.20. Relacin temporal entre o tempo de activacin dunha etapa e o dunha asociacin
asociada a ela: a) TD _< TL _< T(Xi); b) TD _< T(Xi) S TL; e c) T(Xi) _< TD _< TL. ........ 383
Figura 8.21. Semntica temporal dos `flags" dos diferentes tipos de asociacins ............................... 384
Figura 8.22. Semntica temporal dos `Jlags " das asociacins impulsionais ........................................ 385
Figura 8.23. Secuencias de mensaxes da implementacin dos mtodos que acceden aos valores das
varibeis do proceso: a) mtodo getSystemVar; e b) mtodo setSystemVar .................... 388
Figura B.1. Diagrama de clases dos contedores implementados na librara . ....................................... 401
Figura B.2. Diagrama de clases das varibeis e declaracins implementadas na librara . ................. 406
Lista de tboas
Tboa 3-I. Tipos de accins . ....................................................................................................................59
Tboa 3-II. Entradas, sadas e contadores utilizados na automatizacin do posto de fabricacin de bridas..... 93
Tboa 3-III. Valores do cdigo de cada peza ...........................................................................................94
Tboa 3-IV. Movementos de pezas que pode realizar o robot 1 . ............................................................. 94
Tboa 3-V Entradas e varibeis utilizadas na automatizacin da cela de fabricacin flexibel . ............ 95
Tboa 3-VI. Significado do estado de activacin das etapas do Grafcet do robot 1 . ..............................95
Tboa 4-I. Accins que controlan a execucin dos SFCs dependentes no IsaGraph . ...........................122
Tboa 4-II. Sintaxe da directiva de agrupamento e ordes de forzado en AutomGen .............................132
Tboa 4-III. Sintaxe das accins que modifican directamente o valor dunha varibel no AutomGen. .133
Tboa 4-IV. Incompatibilidades entre accins definidas por AutomGen ..............................................135
Tboa 4-V. Sintaxe das accins en WinGrafcet .....................................................................................140
Tboa 4-VI. Sintaxe das accins no Graf7-C .........................................................................................143
Tboa 4-VII. Resume dos resultados da anlise: funcionalidades das aplicacins ............................... l SO
Tboa 4-VIII. Resume dos resultados da anlise. funcionalidades das aplicacins (continuacin). ....1 Sl
Tboa 4-IX. Resume dos resultados da anlise: caractersticas Grafcet soportadas . ............................152
Tboa 4-X. Resume dos resultados da anlise: caractersticas Grafcet soportadas (continuacin)......153
Tboa S-I. Notificacins relacionadas coa modificacin da estructura dun modelo Grafcet . ..............185
Tboa S-II. Notificacins relacionadas coa identificacin de elementos dun modelo Grafcet ..............186
Tboa 6-I. Valores dos atributos in_condition e timers_allowed nas fases compostas do compilador Grafcet.... 213
Tboa 6-II. Equivalencia entre os operadores Sidoni e os operadores C++ . .......................................254
Tboa 8-I. Configuracins do intrprete Grafcet ................................................................................... 3S5
Tboa A-I Caractersticas das etapas . .................................................................................................. 393
Tboa A-II. Caractersticas das transicins e das condicins de transicin . ........................................ 395
Tboa A-III. Declaracin de accins . .................................................................................................... 396
Tboa A-IV. Asociacin de etapas e accins .......................................................................................... 397
Tboa A-V. Caractersticas dos bloques de definicin de accins .........................................................397
Tboa A-VI. Tipos de accins .................................................................................................................398
Tboa A-VII. Estructuras de control . ... ..................................................................................................400
Tboa B-I. Propiedades dos contedores implementados na libraria . ....................................................402
Tboa F-I. Cdigos das mensaxes dos servicios de acceso remoto da mquina virtual .................:...... 433
Glosario de abreviaturas
AFCET
ANDECS
ANSI
ANTLR
ARS
AST
CACE
CACSD
CASE
CIM
CIMOSA
CLADP
COCA
CORBA
CSMP
CSSL
DAIS
DCOM
DDC
DDE
DEDS
DLL
DOS
E/S
FBD
GEMMA
GNU
GRAFCET
GRAI
Association Franaise des Sciences et Technologies de 1'Information et des Systmes

Analysis and Design of Controlled Systems
American National Standards Institute
Another Tool for Language Recognition
Avec Recherche de la Stabilit
Abstract Sintax Tree
Computer Aided Control Engineering
Computer Aided Control System Design
Computer Aided Software Engineering
Computer Integrated Manufacturing
CIM Open System Architecture
Cambridge Linear Analysis and Design Programs
Component Oriented Control Architecture
Common Object Request Broker Architecture
Continuous System Modelling Program
Continuous System Simulation Language
Design Advisor for Implementing Systems
Distributed Component Object Model
Direct Digital Control
Dynamic Data Exchange
Discrete Event Dynamic Systems
Dynamic Link Library
Disk Operating System
Entrada/Saida
Function Block Diagram
Guide d'tude des Modes de Marches et d'Arrts
GNU's Not Unix!
GRAphe Fonctionnel de Commande Etapes/Transitions
Graphes de Rsultats et Activits Interrelis
GIM
GRAI Integrated Methodology
HDCCS
HMI
ICAM
IDEF
IDN
IEC
IL
ISO
Hierarchical Distributed Computer Control Systems

Human Machine Interface
Integrated Computer Aided Manufacturing
ICAM Definition Method
Integrated Design Notation
International Electrotechnical Commission
Instruction List
International Organization for Standardization
xxiii
Glosario de abreviaturas
JIT
LD
MFC
MIS
MMS
MOF
OCL
OLE
OMT
OPC
PC
PCCTS
PERA
PiCSI
PID
PLC
POU
RdP
RdPI
RNA
RTC
RTOS
RTTL
SA/RT
SADT
SCADA
SFC
SLICE
SLICOT
SRS
SSEE
ST
STL
TCCS
TCP/IP
TIC
TML
TTM
ÛML
VEE
VI
VPU
XML
Just In Time
Ladder Diagram
Microsoft Foundation Classes
Management Information System
Manufacturing Message Specification
Meta Object Facility
Object Constraint Language
Object Linking and Embedding
Object Modelling Technique
OLE for Process Control
Personal Computer
Purdue Compiler Construction Tool Set
Purdue Enterprise Reference Architecture
Process Control Systems Integration
Regulador con accin Proporcional, Integral e Derivativa
Programmable Logic Controller
Program Organization Unit
Rede de Petri
Rede de Petri Interpretada
Rede de Neuronas Artificiais
Run To Completion
Real Time Operating System
Real Time Temporal Logic
Structured Analysis / Real Time
Structured Analysis and Design Technique
Supervision, Control And Data Acquisition
Sequential Function Chart
Subroutine Library for Control Engineering
Subroutine Library in Systems and Control Theory
Sans Recherche de la Stabilit
Sistema Experto
Structured Text
Standard Template Library
Timed Calculus for Communicating Systems
Transmission Control Protocol/Internet Protocol
Target Independent Code
Timed Modal Logic
Timed Transition Model
Unified Modelling Language
Virtual Engineering Environment
Virtual Instrument
Visual Pascal Unit
Extensible Markup Language
xxiv
Captulo 1 . Introduccin
Este captulo presenta o traballo realizado nesta tese de doutoramento, describindo

brevemente a sa motivacin, obxectivos e os mtodos utilizados na sa realizacin. A
estructura do captulo a seguinte: en (1.1) indcase brevemente os motivos que deron lugar
ao traballo realizado, as como os antecedentes histricos e as principais lias de investigacin
relacionadas; en ( 1.2) descrbense as caractersticas e obxectivos da solucin aportada; en
( 1.3) indcanse os mtodos e ferramentas utilizados; e, finalmente, en ( 1.4) resmense os
contidos dos demais captulos.
1.1. Motivacin
Na actualidade o desenvolvemento de "software" para a implementacin de sistemas de
control por computador unha tarefa realmente complexa para a que os enxeeiros de control
requiren da asistencia de ambientes "software" especializados. Os factores que afectan
complexidade dos sistemas de control son mltiples, entre outros:
1. As tecnoloxas aplicadas nos procesos industriais son cada vez mais complexas.
2. As actividades de control automatizadas son cada vez mais numerosas e ocupan un nivel
cada vez mais alto na xerarqua de control.
3. O nmero de posibilidades tecnolxicas das que se dispn para a realizacin do sistema de
control cada vez maior.
4. A cantidade de aspectos tecnolxicos alleos enxeera de control que preciso
considerar, principalmente os relacionados coas tecnoloxas da informacin e as
telecomunicacins, incremntase a un ritmo que fai moi dificil èstar ao da'.
5. Os sistemas incorporan un nmero cada vez maior de requisitos adicionais aln dos
relacionados directamente co control, como a integracin cos sistemas de informacin da
empresa, interfaces grficas avanzadas, xestin de modelos, simuladores, xestin de
mltiples configuracins, portabilidade, etc.
Os ambientes "software" que proporcionan asistencia ao desenvolvemento de "soflware"
para sistemas de control reciben o nome de ambientes CACE^, e son definidos como [26]: à
aplicacin do modelado e simulacin asistidos por computador para o deseo e
implementacin de sistemas de control ^realimentadosJ'. Estes ambientes caracterzanse por
^ O termo CACE utilizado na actualidade para indicar a evolucin das ferramentas CACSD a ambientes que
proporcionan asistencia integrada por computador en todas as fases do ciclo de vida dun sistema de control, de
xeito semellante s ferramentas CASE na enxeeria do "software".
25
Captulo 1: Introduccin
26
combinar mtodos, tcnicas e ferramentas de diferentes dominios co obxectivo de proporcionar

asistencia durante todas as fases do ciclo de vida dun sistema de control, dende a sa
identificacin e modelado ata a sa implementacin e operacin. Idealmente deberan facilitar a
utilizacin de formalismos familiares aos enxeeiros de control durante a especificacin,
deseo, modelado e simulacin do sistema, e automatizar o mximo posbel os detalles
relacionados coa obtencin do cdigo para a sa implementacin en arquitecturas de coritrol
distribudas e heteroxneas. O papel destas ferramentas semellante ao das ferramentas CASE
dentro do campo da Enxeera do Soflware, coa peculiaridade de que integran formalismos e
tcnicas propios da enxeera de control, e van ser manexadas por usuarios que non son
expertos en desenvolvemento de "soflware".
O desenvolvemento de ambientes CACE ten moitos aspectos en comn co desenvolvemento
de ambientes asistidos por computador noutras reas da enxeera, como poden ser o deseo de
circutos, a enxeera de procesos de fabricacin, a enxeera do "software", etc. A base desta
disciplina a forman os mtodos de modelado e anlise matemtica da teora de control clsica e,
gradualmente, fronse incorporando novos mtodos e tcnicas provenientes de diferentes
campos, como por exemplo: mtodos numricos de optimizacin; clculo simblico; linguaxes
de simulacin; formalismos de especificacin de DEDS, tcnicas de "soft-computing" (redes de
neuronas, lxica difusa, algoritmos xenticos); paradigmas e linguaxes de programacin
(orientacin a obxectos, programacin lxica, programacin visual); arquitecturas "software"
distribudas (CORBA, DCOM, sistemas multiaxente); etc. O desenvolvemento de sistemas de
control por computador modernos convertiuse nun rea multidisciplinar que require da
utilizacin conxunta e coordinada de diferentes mtodos, tcnicas e ferramentas que permitan
integrar diferentes puntos de vista dun sistema, como o da enxeera de control, o da enxeera
do "software" ou o da enxeera das telecomunicacins.
No resto deste apartado ofrcese unha breve introducin histrica a algns dos avances
producidos en diferentes areas que influiron a evolucin dos sistemas de control por
computador e os ambientes CACE, e descrbense algunhas das lias que na actualidade dirixen
a investigacin neste campo.
1.1.1. Antecedentes histricos

A evolucin das ferramentas CACE [92][93] est intimamente ligada evolucin parella da
complexidade nos sistemas de control [ 141 ]. As primeiras aplicacins dos computadores en
actividades de control datan de finais dos anos 50, nas que era utilizado para calcular os valores
de referencia dos lazos de regulacin. A funcionalidade do computador no sistema era reducida
e estaba limitada supervisin e, nalgns casos, ao control deses valores de referencia. Nos
comezos dos anos 60 conectouse o computador directamente ao proceso mediante os
transductores axeitados e os lazos de control implementronse directamente no computador,
desprazando este progresivamente aos reguladores analxicos. Esta configuracin recibiu o
nome de control dixital directo (DDC) e tia a avantaxe de facilitar a implementacin de
esquemas de control nos que era precisa a interaccin entre varios lazos. Nesta altura anda non
se dispoa de ferramentas CACE, mais era posbel que enxeeiros de control con nocins de
programacin en ensamblador ou Fortran abordaran por si mesmos todas as fases de
desenvolvemento do sistema, dende a sa concepcin inicial ata a fase de operacin e
mantemento.
Nos finais dos 60, a aparicin dos microprocesadores permitiu a aplicacin masiva dos
sistemas de control por computador e a comezos dos 70, a aparicin das primeiras redes de
comunicacin entre computadores, propiciou a instalacin dos primeiros sistemas xerrquicos
27
Seccin 1.1: Motivacin
distribudos de control por computador (HDCCS). Estes sistemas caracterzanse pola

utilizacin de varios computadores interconectados entre si e organizados dende un punto de
vista lxico en niveis, formando unha xerarqua de control. Os computadores con maior
capacidade de proceso ocupan os niveis mais altos da xerarqua, nos que se realizan funcins de
supervisin e coordinacin dos niveis inferiores; e de anlise e asistencia toma de decisins
sobre o proceso. Nos niveis inferiores estn os equipos conectados directamente ao proceso
como minicomputadores, PLCs ou microcontroladores encargados do control local dacordo s
estratexias indicadas polos niveis superiores. Entre ambos niveis, e dependendo do sistema
concreto, pode haber diferentes niveis intermedios que proporcionan interfaces de operador e
diferentes graos de control, coordinacin e supervisin en funcin das necesidades. No
referente s ferramentas, na dcada dos 60 e primeira metade da dos 70 cando aparecen as
primeiras libraras para lxebra lineal (EISPACK [69], LINPACK [50]), as primeiras linguaxes
e ferramentas de simulacin (Simula [42], CSMP [159], CSSL [160]), as primeiras linguaxes
de programacin estructurada (Algol [125], Pascal [175]), as redes de Petri (RdP) [137], e o
que podera ser considerado como primeira xeracin de ferramentas CACSD (UMIST [ 142],
CLADP [110]), programas que proporcionaban asistencia para a realizacin de actividades
especficas dentro do ciclo de desenvolvemento do sistema de control.
Os finais dos 70 e a dcada dos 80 estivo caracterizada pola aparicin do computador
persoal que, debido ao abaratamento de custes que supua, foi aplicado en actividades de
control, habitualmente non nas relacionadas co control directo pois non se dispua das
interfaces co proceso axeitadas, senn nas relacionadas coa supervisin, anlise e interface
grfica. Popularizronse os denominados sistemas SCADA que utilizaban computadores
persoais, nos que se implementaba a interface de operador e as funcins de anlise e
supervisin, conectados a PLCs e microcontroladores encargados de realizar o control directo.
Comezan tamn os primeiros esforzos por interconectar o sistema de control co sistma de
informacin de xestin (MIS) da empresa. nesta dcada na que aparecen as primeiras
ferramentas CACSD implementadas sobre libraras de clculo numrico (Ctrl-C [107],
MatrixXZ [ 171 ], Impact [ 140]) e os que poden considerarse como primeiros ambientes ACE
(Federated CACSD [158], ECSTASY [122], GE-MEAD [162], CACE-III [90]). Tamn
aparecen neste periodo ferramentas para o clculo numrico, simblico e a simulacin
(MATLAB3 [119], Maple4 [39], SLICE [156], CSIMS [152]), formalismos para a descricin
formal de DEDS (StateCharts [78], Grafcet [1]); aproximacins sncronas ao deseo de
sistemas reactivos (Esterel [24]); popularzanse os ambientes grficos (MacOS6, Windows^); e
aparecen linguaxes que inclen conceptos que facilitan a estructuracin do "software" para
manexar a sa complexidade (ADA [ 166], Smalltalk [82]).
A aparicin dos buses de campo, a proliferacin de redes de rea local, o espectacular
incremento nas capacidades de proceso dos computadores persoais, os esforzos de
estandarizacin cara a facilitar a aparicin de sistemas àbertos', os avances tecnolxicos en
campos como as bases de datos, os sistemas operativos en tempo real, as arquitecturas
"software" distribudas, os dispositivos multimedia, os robots ou a intelixencia artificial son s
algns dos factores que veen influenciando o desenrolo dos sistemas de control dende o
comezo da dcada dos 90 ata a actualidade. A tendencia actual a de distribur aìntelixencia'
Matrixx, LabView e LookOut son productos de National Instruments. http://www.ni.com/
MatLab e Simulink son productos de The MathWorks. http://www.mathworks.com/
Maple un producto da compaa Waterloo Maple. http://www.maplesoft.com/
CSIM un producto da compaa Mesquite Software. http://www.mesquite.com/
Mac OS un poducto da compaa Apple Computer. http://www.apple.com/
Windows un poducto da compaa Microsoft. http:/Iwww.microsoft.com/
28
do sistema sobre unha xerarqua lxica de computadores, equipos de control (computadores

industriais, PLCs, microcontroladores, robots, etc.) e dispositivos de campo (sensores e
actuadores) ìntelixentes' conectados fisicamente entre si mediante un nmero limitado de
buses de comunicacins. Exemplos desta tendencia son os sistemas multiaxente ou os sistemas
holnicos, ambos basanse na definicin de entidades autnomas (axentes e holns,
respectivamente) que deben cooperar entre si para a realizacin de actividades complexs.
Estes sistemas reciben a denominacin de sistemas heterrquicos debido a que neles existe
tanto unha organizacin xerrquica, parella aos niveis de decisin da estructura organizativa da
empresa, como unha rede de entes autnomos cooperantes distribudos sobre a rede fisica do
sistema de control.
No referente s ferramentas, neste periodo aparecen ferramentas para o desenvolvemento
grfico de sistemas de adquisicin de datos (LabView2 [56], HP VEEB) e sistemas SCADA
(LookOut2, Intouch9). Defnese o estndar IEC 61131-3 [86] para programacin de PLCs, o que
da lugar a que comecen a aparecer os primeiros ambientes àbertos' de programacin de PLCs
(IsaGraph10, CodeSys"). Popularizase o uso de MATLAB3 coa incorporacin de diferentes
"toolboxes" que permiten a sa aplicacin en mltiples campos e a inclusin do Simulink's
Real Time Workshop, que permite xerar cdigo para sistemas de tempo real a partires dos
modelos deseados co Simulink2. Desenvolvense ferramentas avanzadas de clculo numrico,
simblico e simulacin (SLICOT [20], LAPACK [5], Mathematica12 [176], Ptolemy [32]);
linguaxes (C++ [161], Eiffel [118]), metodoloxas (Booch [28], LIML [29]) e ferramentas
CASE (Rational Rose13, Real Time Studio14) orientadas a obxectos; ambientes para o
desenvolvemento de sistemas en tempo real (Tornado15, QNX16); estndares para sistemas
distribudos (CORBA [126], DCOM [154]) e numerosas tecnoloxas provenientes do campo da
Intelixencia Artificial (SSEE, RNAs, lxica difusa, algoritmos evolutivos) son aplicadas ao
desenvolvemento de sistemas de control.
Estes avances, xunto coa integracin cada vez maior entre o sistema de control e o MIS,
permitiron a aparicin de paradigmas para a xestin de procesos de fabricacin, como o CIM
[ 170] ou o JIT [44], que estn baseados no suporte proporcionado polas tecnoloxas da
informacin e as comunicacins. Na actualidade as tecnoloxas relacionadas coa Internet estn
a ter unha aceptacin crecente na implementacin destes paradigmas xa que proporcionan un
conxunto de estndares para o intercambio e visualizacin de informacin que facilitan a
integracin dos diferentes subsistemas da empresa.
1.1.2. Lias de investigacin

Algunhas das lias de investigacin relacionadas coa infraestructura "software" que da
soporte aos ambientes CACE que na actualidade estn recibindo maior atencin son as
seguintes:
8 HP VEE un producto da compaa Hewlett-Packard. http://www.hp.com/

9 InTouch HMI un producto da compaa Wonnderware. http://www.wonderware.com/
10 IsaGraph un producto da compaa Altersys. http://www.altersys.com/.
" CodeSys un producto da compaa Smart Software Solutions. http://www.3s-software.com/.
12 Mathematica un producto da compaa Wolfram Research. http://www.wolfram.com/
13 Rational Rose un producto da compaa IBM Rational Software. http://www.rational.com/
14 Real Time Studio un producto da compaa Artisan Software Tools. http://www.artisansw.com/
15 Tornado un producto da compaa WindRiver Systems. http://www.windriver.com/
16 QNX Momentics un producto da compaa QNX Software Systems. http://www.qnx.com/
29

Seccin 1.1: Motivacin

Evolucin cara a arquitecturas independentes das ferramentas. Os primeiros ambientes
CACE tian unha arquitectura dependente das ferramentas que integraban (Figura 1.1). Un
supervisor implementaba os servicios precisos para manexar as peculiaridades de cada
ferramenta e proporcionaba unha linguaxe de comandos comn a todas elas. Os ambientes
mis actuais eliminan esta dependencia utilizando estndares de modelado e
proporcionando unha interface de acceso a servicios bsicos comns a travs dos que se
integran as diferentes ferramentas. Un exemplo deste tipo de arquitectura o amosado na
Figura 1.2, denominado `modelo da torradora' [17].
Intertace
de usuarlo
Linguaxe
de comandos
SupeMsor
Comandos e datos
\da ferramenta
Ferramenta
Ferramenta
Ferramenta
Figura 1.1: Arquitectura dunha ferramenta CACE dependente das ferramentas.
Figura 1.2: Arquitectura de referencia para ferramentas CACE independentes das ferramentas.
Algns exemplos desta lia de investigacin son:

1. O modelo unificado de informacin proposto en [ 168], que tenta dar unha definicin
neutral da informacin utilizada nun ambiente CACE.
2. A notacin de deseo integrada (IDN) proposta en [ 17] para representar o modelo do
sistema na ferramenta PiCSI. Esta notacin consta de tres modelos relacionados: o de
requirimentos, o arquitectnico e o modelo "soflware", que conxuntamente permiten
modelar todos os aspectos implicados nas diferntes fases de desenvolvemento do
sistema, dende a sa especificacin ata a xeracin de cdigo. A IDN unha notacin
de modelado orientada a obxectos que utiliza algns dos diagramas propostos na UML.
30
3. Modelado mediante patrns de compoentes ("template components"), como os

utilizados na ferramenta de simulacin Saber'^ ou os propostos en CIMOSA [169] para
o modelado de empresas. Nesta aproximacin os modelos particulares son creados a
partires da instanciacin de bloques xenricos, o que aumenta a reusabilidade e
aplicabilidade dos modelos.
4. A utilizacin do XML [ 151 ] para a descricin neutral da informacin e a linguaxe ava
para a implementacin dos servicios bsicos comns [17][93].
Desenvolvemento de sistemas de deseo virtual. Estes sistemas manexan a informacin
relacionada co proceso iterativo de deseo do sistema de control, asistindo na toma de
decisins que permitan obter unha solucin tendo en conta mltiples obxectivos e
restriccins en conflicto. Algns exemplos son:
1. O traballo de [13] estudia a aplicacin de patrns de deseo de "software" na
implementacin de sistemas "batch".
2. A ferramenta ANDECS [71], unha aplicacin de deseo multiobxectivo que asiste na
sntese, simulacin, anlise e optimizacin do sistema de control.
3. A ferramenta DAIS [163], un "front-end" intelixente que combina un ambiente CACE
e unha ferramenta de desenvolvemento de sistemas expertos para implementar un
sistema de asistencia ao deseo e implementacin de sistemas de control.
Implementacin de arquitecturas de integracin utilizando estndares para a computacin
distribuda. Algns exemplos son:
l. O uso de CORBA, mquinas virtuais para Java en tempo real e servidores Web para o
intercambio da informacin do proceso no proxecto PiCSI [17].
2. O uso de CORBA para implementar a especificacin de paso de mensaxes ISO MMS
^
[89] no proxecto COCA [70].
Xeracin automtica de cdigo a partires do modelo do sistema para a sa implementacin
en sistemas de tempo real. Esta unha funcionalidade moi importante que permite illar ao
enxeeiro dos aspectos tecnolxicos alleos enxeera de control implicados na
implementacin do sistema. unha caracterstica que incorporan un numero cada vez
maior de ferramentas comerciais orientadas ao desenvolvemento de sistemas de control
(Simulink Real-time Workshop, Matrixx/Autocode, LabView Application Builder) ou de
"software" de propsito xeral (Rational Rose, Real Time Studio). As investigacins nesta
lia non s procuran a xeracin do cdigo especfico para cada arquitectura, senon tamn o
desenvolvemento de tcnicas para o mantemento da consistencia entre o modelo e o cdigo
xerado cando algn dos dous modifcado, a obtencin do modelo a partires do cdigo
(enxeera inversa), a verificacin das condicins que garantan a seguridade no
funcionamento do sistema ou o soporte distribucin das aplicacins.
A programacin visual permite construir e simular os modelos do sistema utilizando
fornnalismos grficos. A sa combinacin con mtodos formais de validacin e con
tcnicas de xeracin automtica' de cdigo permite obter ferramentas de fcil manexo que
reducen o esforzo de desenvolvimento dun sistema de control. Os seguintes son exemplos
de ferramentas comerciais que incorporan esta caracterstica:
1. Aplicacins que utilizan UML como Rational Rose ou Real Time Studio.
^^ Saber un producto da compaa Synopsys. http://www.synopsys.com/.
31
Seccin 1.2: Obxectivos

2. Aplicacins que utilizan formalismos grficos para a modelizacin de DEDS como 0
StateFlow en MATLAB, as RdP en Artifex18 ou os StateCharts en Rational Rose.
3. Aplicacins que utilizan as linguaxes grficas do estndar IEC 61131-3 como
IsaGraph, PL719 ou CodeSys.
4. Aplicacins que utilizan linguaxes visuais propias como HP VEE ou LabView.
Ademais das lias de investigacin anteriores existen outras mis relacionadas cos mtodos
formais utilizados nos ambientes CACE, como por exemplo:
A busca de novos mtodos para a anlise e sntese de sistemas de control mediante
algoritmos numricos, simblicos ou "soft-computing".
A proposta de novos mtodos para a modelado e simulacin de sistemas continuos, de
eventos discretos ou hbridos.
O estudio de novos mtodos de optimizacin multiobxectivo para a anlise e o deseo do
sistema.
O estudio de novas tcnicas de supervisin e deteccin de fallas baseadas na utilizacin de

modelos.
A elaboracin de estndares para o intercambio de informacin (principalmente os modelos

do sistema e a informacin de deseo).
En resume, o desenvolvemento de ambientes CACE caracterzase por tratar con sistemas
complexos que requiren de aproximacins multidisciplinares que integren mtodos e tcnicas
procedentes de campos diferentes e nas que as tecnoloxas da informtica e as
telecomunicacins gaan cada vez maior importancia. A tendencia na actualidade a de utilizar
diferentes ferramentas especializadas que proporcionan soporte nas diferentes etapas do ciclo
de vida do sistema de control, dende a sa concepcin inicial ata a sa operacin e
mantemento. As ferramentas utilizadas comparten un modelo nico do sistema representado
mediante formalismos estndar e integranse a travs dunha infraestructura "software" comn.
1.2. Obxectivos
A finalidade do traballo realizado nesta tese de doutoramento a de desear e implementar
unha ferramenta que proporcione asistencia aos enxeeiros de control no desenvolvemento de
"software" para sistemas industriais e que poda ser integrada nun ambiente de
desenvolvemento heteroxneo, no que se combinen diferentes mtodos e formalismos que
proporcionen asistencia durante todo o ciclo de vida do sistema de control. En concreto a
ferramenta proposta combina un formalismo grfico para a especificacin de controladores
lxicos secuenciais, o Grafcet, cunha aproximacin orientada a obxecto. As funcionalidades
que implementa inclen a estructuracin, modelado e simulacin das secuencias lxicas que
describen o comportamento dos sistemas de control complexos, a integracin de modelos
desenvolvidos con outras ferramentas, e a xeracin automtica de cdigo para a execucin da
aplicacin en arquitecturas de control distribudas e heteroxneas. O desenvolvemento de
"software" para a superyisin e control de DEDS e certos tipos de sistemas hbridos (p.e.
sistemas "batch") son exemplos de posbeis aplicacins da ferramenta.
18 Artifex un producto da compaa Artis Software. http://www.artis.com/.

19 PL7 un producto da compaa Schneider Automation. http://www.modicon.com/.
32
A inclusin do Grafcet proporciona unha linguaxe grfica normalizada, definida

formalmente, fcil de aprender e utilizar, amplamente difundida e independente da tecnoloxa
utilizada na sa implementacin. As funcionalidades da ferramenta organzanse arredor da
proposta e implementacin dun metamodelo para este formalismo, e inclen un editor grfico e
un compilador dos modelos representados utilizando o metamodelo proposto que permiten
xerar automaticamente o cdigo do sistema de control dende a representacin grfica da lxica
secuencial do seu funcionamento. A execucin dos modelos compilados realzase nun
intrprete Grafcet, no que pode escollerse a interpretacin semntica desexada, e que forma
parte dunha mquina virtual portbel na que pode configurarse dinamicamente a interaccin do
intrprete co proceso. O Grafcet as utilizado de maneira uniforme durante a maior parte das
fases do ciclo de vida do sistema de control, dende a especificacin inicial ata a posta en
funcionamento, operacin e mantemento. Gracias ao soporte proporcionado pola ferramenta, o
enxeeiro utilzao para representar graficamente as secuencias lxicas que modelan o
comportamento do sistema, verifica a correccin sintctica do modelo, valdao mediante
simulacin, xera automaticamente o seu cdigo, exectao seguindo unhas regras semnticas
ben definidas, deprao e, finalmente, utilzao como interface de operador durante a operacin
do sistema.
O modelado, estructuracin e reutilizacin das aplicacins implementadas coa ferramenta
son reforzadas aproveitando as avantaxes da aproximacin orientada a obxecto que
proporcionan o metamodelo Grafcet proposto e a utilizacin da linguaxe C++ para a
programacin das accins de control e a representacin da informacin utilizada nas
aplicacins. O metamodelo Grafcet definido como parte do metamodelo UML, de xeito
semellante ao dos StateCharts, co que se facilita a integracin da ferramenta con aplicacins
CASE baseadas en UML, utilizando o Grafcet como alternativa para a especificacin do
comportamento dinmico dos elementos dos modelos. A linguaxe C++, ademais das
propiedades de orientacin a obxectos da propia linguaxe, permite a utilizacin nas aplicacins
dun grande nmero de funcins includas en libraras externas, como por exemplo libraras
matemticas, de simulacin, de "soft-computing" (redes de neuronas, lxica difusa, algoritmos
evolutivos); etc.
En conxunto a ferramenta proposta proporciona un ambiente de desenvolvemento
"software" que utiliza un formalismo uniforme en diferentes fases do ciclo de vida dun sistema
de control, dende o deseo inicial ate a operacin e mantemento. As caractersticas do Grafcet
combinan adecuadamente coas da orientacin a obxectos na aplicacin dun proceso de
desenvolvemento iterativo, baseado na construccin de modelos grficos executbeis que son
validados e refinados progresivamente mediante simulacin.
1.3. Mtodos e ferramentas utilizados

No desenvolvemento da ferramenta proposta utilizouse unha aproximacin orientada a
obxectos [28] durante o deseo e a implementacin. Aplicronse diferentes patrns de deseo
[67], considerando en especial algns dos propostos para sistemas de tempo real [51][52] na
implementacin da mquina virtual. UML [29] foi a linguaxe de modelado utilizada e o C++
[ 161 ] a de programacin. A aplicacin de modelado UML utilizada foi o Rational Rose e o
compilador o Visual C++, os dous na sa versin para o sistema oprativo Windows. Para a
programacin grfica do editor Grafcet utilizronse as libraras MFC e Stingray Objective
Studio. Esta a nica compoente da ferramenta non portbel, debido a que se preferiu a
utilizacin dunha librara grfica dependente do sistema operativo que ofrecera maiores
posibilidades que as libraras grficas portbeis. Ademais das ferramentas, libraras e^ mtodos
33
Seccin 1.4: Sumario
indicados, que son ben coecidos e non requiren maior explicacin, utilizronse outros que se
describen a continuacin.
1.3.1. SGI STL
Implementacin libre da librara STL [123][11] da empresa Silicon Graphics. A STL unha
librara C++ xenrica que proporciona unha implementacin baseada no uso de "templates" das
estructuras de datos mis habituais (listas, colas, conxuntos, etc.) e os algoritmos que permiten
manexalas.
1.3.2. Common C++

Librara libre baixo licencia GNU que proporciona un conxunto de clases que facilitan a
programacin de aplicacins portbeis: "threads", "sockets", sincronizacin (semforos,
mutex), persistencia, carga dinmica de mdulos compilados, etc. Estas clases abstraen os
servizos bsicos proporcionados polos sistemas operativos e eliminan parte dos problemas
debidos s diferencias entre eles. Na actualidade hai versins desta librara para diferentes
variantes de Unix e para Windows.
1.3.3. Sidoni
Sidoni [ 146] unha aplicacin para a simplificacin de expresins booleanas extendidas,
nas que ademais dos operadores do lxebra de Boole se utilicen os operadores de evento (T e
^). Esta aplicacin utilizada durante a compilacin dos modelos Grafcet para converter as
expresins con eventos complexas, nas que os eventos afectan a expresins, en expresins con
eventos simples, nas que os eventos afectan unicamente a varibeis.
1.3.4. PCCTS
PCCTS [135] un conxunto de tres ferramentas para a xeracin automtica de analizadores
sintcticos e traductores en C++: DLG, un xerador de analizadores lxicos; ANTLR, un
xerador de analizadores sintcticos pred-LL(k), con k>1 (analizador descendente con
predicados semnticos); e SORCERER, un traductor de rbores sintcticas abstractas (ASTs).
1.4. Sumario
Os contidos desta tese de doutoramento estructranse da maneira seguinte:
No Captulo 2 presntase as ideas principais nas que se basea o traballo realizado e
describese a ferramenta proposta.
No Captulo 3 detllase a sintaxe e semntica do Grafcet, realzase unha comparacin con
outros formalismos, faise unha introduccccin ao estndar IEC 61131-3 e ao SFC e
mostranse algns exemplos de modelado con Grafcet.
No Captulo 4 clasificanse e analzanse diferentes tipos de ferramentas para o
desenvolvemento de sistemas de control que utilicen algunha variante do Grafcet.
No Captulo 5 explcase en detalle o metamodelo proposto para o Grafcet, a librara que o

implementa e algns exemplos da sa utilizacin.
No Captulo 6 descrbese a arquitectura e funcionamento do compilador que converte os

modelos Grafcet ao formato utilizado para a sa carga dinmica e execucin na mquina
virtual.
34
No Captulo 7 detllase a arquitectura e implementacin da mquina virtual que

proporciona soporte execucin dos modelos Grafcet en ambientes distribudos
heteroxneos.
No Captulo 8 detllase a implementacin e funcionamento do intrprete de modelos
Grafcet.
No Captulo 9 resmense as conclusins e propense as futuras lias de investigacin.
Ademais tamn se inclen algns anexos con informacin de interese sobre diferentes
aspectos relacionados co traballo realizado:
No Anexo A inclense as tboas do estndar IEC 61131-3 coas caractersticas definidas
para o SFC.
No Anexo B descrbense algunhas das funcionalidades bsicas implementadas como parte
da ferramenta desenvolvida nesta tese de doutoramento
No Anexo C mstrase o arquivo .mak utilizado para compilar e enlazar co Visual C++ 6.0
as DLLs xeradas polo compilador Grafcet.
No Anexo D mstrase a gramtica ANTLR utilizada para xerar un analizador sintctico de
expresins C++ estendidas cos operadores de evento e temporizacin do Grafcet.
No Anexo E mstranse as gramticas Sorcerer utilizadas para a xeracin automtica de

analizadores/traductores de expresins C++ estendidas cos operadores de evento e
temporizacin do Grafcet.
No Anexo F mstranse os patrns de comunicacin e o intercambio de mensaxes para

acceder aos servicios remotos da mquina virtual.
Debe facerse notar que, como se explica en ( 2.3.4), unha das compoentes da ferramenta
proposta nesta tese de doutoramento un editor grfico a travs do que se accede s
funcionalidades das outras compoentes (compilador, mquina virtual, simulador). Para evitar
que o tamao desta documentacin fose excesivo preferiuse non inclur nela un captulo
dedicado a describir o manexo deste editor, e decidiuse axuntalo como manual de usuario ao
cdigo e aos executbeis da ferramenta desenvolvida.
Captulo 2 . Fundamentos e
descricin da ferramenta
proposta
Neste captulo presntanse brevemente algns conceptos bsicos sobre os sistemas

industriais e o proceso de desenvolvemento de "software" para o seu control por computador.
Destcase o papel central dos modelos dentro deste proceso en aproximacins baseadas na
utilizacin de compoentes reutilizabeis, e sitase a aplicacin de metodoloxas de
desenvolvemento "software" no contexto mis xenrico da enxeeria de sistemas industriais.
Ademais presntanse as funcionalidades bsicas da ferramenta proposta nesta tese de
doutoramento e comprase a aproximacin adoptada con outras relacionadas.
O captulo est organizado da forma seguinte: en (2.1) dse unha breve introduccin aos
sistemas industriais e ao seu control; en (2.2) explcanse os aspectos relacionados co
desenvolvemento de "software" para sistemas de control; as caractersticas, arquitectura e
utilizacin da ferramenta proposta descrbense en (2.3); e finalmente, o captulo resmese en
(2.4).
2.1. Os sistemas industriais e o seu control

Neste apartado descrbense as caractersticas que definen a un sistema industrial e
introdcense os conceptos bsicos que se aplican no seu control. A descricin que se realiza e
as definicins utilizadas estn baseadas no estndar ISA S88.01 [87].
2.1.1. Descricin dun sistema industrial

Un sistema industrial pode definirse como [57]: ò conxunto de equipamentos coa
capacidade de realizar as operacins precisas para a obtencin dun producto como parte da
actividade de produccin dunha empresa'. Os sistemas industriais modernos estn organizados
como estructuras xerrquicas compostas por mltiples subsistemas que funcionan
coordinadamente e se relacionan mediante diferentes fluxos de intercambio de materiais,
enerxa e informacin. A actividade dun sistema industrial pode concibirse como un proceso de
transformacin de productos bsicos en productos elaborados, no que se consume enerxa e
xranse residuos.
Os procesos realizados nun sistema industrial son secuencias de actividades fisicas,
qumicas ou biolxicas para a transformacin, transporte ou almacenamento de materiais ou
35
36
Captulo 2: Fundamentos e descricin da ferramenta proposta
enerxa [87]. Unha clasificacin habitual dos procesos industriais divdeos en tres categoras
dacordo forma en que se obtn o producto:
1. Procesos continuos, nos que se obtn un fluxo continuo de producto.
2. Procesos "batch ", nos que o producto se fabrica por lotes ou coadas.
3. Procesos de fabricacin ou ensamblaxe de compoentes, nos que se obteen cantidades
discretas de producto.
Na prctica un sistema industrial est formado por unha combinacin de procesos, e anda
que estea caracterizado principalmente pola presencia maioritaria dos pertencentes a unha das
categoras anteriores, con frecuencia inclen tamn procesos pertencentes s outras.
Os equipamentos que forman parte dun sistema industrial poden clasificarse funcionalmente
en das categoras: o equipamento de proceso e o equipamento de operacin. O equipamento
de proceso frmano os dispositivos flsicos utilizados para transportar, transformar e almacenar
os productos e a enerxa; mentres que o equipamento de operacin est formado polos
dispositivos que asisten ao persoal no manexo do equipamento de proceso. Como parte do
equipamento de operacin poden considerarse tanto os sistemas de control como os de
informacin de xestin da empresa.
Os equipamentos de proceso e contrl agrpanse dende un punto de vista funcional para
formar unidades de proceso [87]. Cada unidade pode realizar unha ou varias operacins e
habitualmente estar composta por un elemento de proceso relevante (un decantador, un
depsito, un reactor, etc.) e o equipamento auxiliar para o seu manexo (vlvulas, motores,
reguladores, etc.). A Figura 2.1 mostra a estructura xenrica dunha unidade de proceso na que
se combinan equipamentos de proceso e control e se intercambian prod-uctos, enerxa e
informacin con outras unidades. A estructura fisica dun sistema industrial poden representarse
mediante a conexin de mltiples unidades de proceso como a mostrada. Ao conxunto de
unidades que funcionan coordinadamente para a produccin dun ou varios productos se lle
denomina cela de produccin.
:^^^^ enencia
:..................:................. ^ ^^^.........
:
.
Equipamento
de control
= - - - --..._......---------- - ..;
sensores
actuadores `
(ordes) ^ ^ (estado)
................................................^......._;
:
Productos
sen elaborar
Equipamento
de proceso
coordinacibn
Productos
elaborados
Figura 2.1. Estructura dunha unidade de proceso.
Dende o punto de vista operativo, o comportamento dos equipamentos de proceso e control

descrito mediante diferentes estados de operacin (STARTING, RUNNING, PAUSED, etc.)
representados utilizando algn tipo de diagrama de estados e transicins. O estado dun
equipamento determina a forma en que este funciona e como reacciona aos comandos externos
e condicins internas do proceso. Un exemplo de proposta para a formalizacin dos estados
operativos dun equipamento industrial o Gemma [ 121 ], que ten unha relacin moi estreita co
Grafcet [30].
37
Seccin 2.1: Os sistemas industriais e o seu control
2.1.2. Os sistemas de control industrial

Os sistemas de control caracterzanse por interactuar directamente co equipamento de
proceso mediante o intercambio de ordes e informacins, sendo a combinacin dambos a que
proporciona a funcionalidade que permite obter un producto cumprindo coas especificacins de
produccin indicadas en cada momento. Un sistema de control moderno non se limita
regulacin das magnitudes fisicas do proceso, senn que coa aplicacin crecente dos
computadores e as tecnoloxas da comunicacin, pasou a ser unha compoente chave dos
sistemas de informacin e xestin da produccin da empresa. En [57] indcase que na
actualidade o control de procesos consiste `na integracin funcional do control secuencial e de
regulacin clsicos coa xestin de informacin en tempo real' e clasifica en tres categoras as
funcins que realiza un sistema de control moderno:
l. A aplicacin das estratexias de control da empresa.
2. O acceso informacin sobre o proceso de produccin para a asistencia na toma de
decisins de xestin a medio e longo prazo.
3. O manexo do sistema que permita aos operadores a supervisin do sistema e a adopcin de
accins correctivas en caso de ser preciso.
Para dar soporte a estas funcins o sistema de control ademais de co proceso ter que
interactuar cos operadores, co sistema de informacin da empresa e, en caso de ser un sistema
distribudo, as diferentes partes que o forman tamn interactuarn entre si (Figura 2.1). A sa
arquitectura lxica adopta unha estructura xerrquica parella aos niveis de decisin (Figura 2.2)
da empresa, na que os niveis mis baixos son os implicados mis directamente no control de
procesos mentres que os mais altos son os que proporcionan asistencia na toma de decisins en
actividades como a planificacin da produccin, o mantemento das instalacins, o control de
calidade, a xestin de "stocks", etc.
^ + intelixencia
Fbrica
Area
Cela /
Controlador /
Equipamento
^ Xestin ^
da produccion
Planificacin
de tarefas
Control de coordinacin
Equipamento de control
Equipamento de proceso
+ reactividade
Figura 2.2. Niveis lxicos nun sistema de control industrial.
Ao nivel de proceso poden utilizarse diferentes tipos de control, cuxo funcionamento

coordinado o que proporciona as funcins que permiten aplicar as estratexias definidas pola
empresa. Os tipos de control son independentes da tecnoloxa utilizada, por exemplo, un tipo
de control bsico a regulacin das magnitudes do proceso, que antes da aparicin dos
reguladores dixitais facase utilizando a tecnoloxa electromecnica ou pneumtica existente no
momento. O avance da tecnoloxa de control permite mellorar as prestacins e a fiabilidade dos
tipos de control, facilitar a sa instalacin e o seu manexo, reducir custes, incrementar a
cantidade e a complexidade das funcins dispobeis, e aumentar o nmero de actividades
automatizadas, principalmente nos niveis superiores da xerarqua de control. En [87J
clasificanse os tipos de control utilizados nun sistema industrial en tres categoras:
38
1.
O control bsico, que o utilizado para activar e manter un estado determinado nun
equipamento ou proceso. O control bsico incle:
a. A regulacin de magnitudes do proceso arredor dun valor de consigna, realizada
mediante os clsicos lazos de control xeralmente implementados mediante reguladores
PID e nos que se utilizan diferentes configuracins ben coecidas: regulacin simple,
en cascada, por adianto, de relacin, selectivo ("override"), etc.
b. O control discreto ("ON/OFF"), realizado mediante rels e utilizado para producir un
cambio no estado do equipamento de proceso (acendido/apagado de motores,
apertura/peche de vlvulas, etc). O diagrama de contactos a representacin grfica
utilizada tradicionalmente para expresar a lxica booleana do control discreto. Os
PLCs foron inicialmente deseados coa finalidade de executar a lxica dos diagramas
de contactos, substitundo as s implementacins cableadas ou pneumticas anteriores.
c. O control secuencial, baseado no control discreto aplicado en procesos cuxa lxica
de funcionamento consiste na realizacin de operacins organizadas en secuencias
ordenadas de pasos. Este o tipo de control que habitualmente se utiliza en procesos de
fabricacin, ensamblaxe e almacenamento de pezas, no control da secuencia de
fabricacin en procesos "batch" e no control do arranque e a parada de procesos
continuos.
d. A monitorizacin, que consiste na obtencin de informacin sobre o estado e evolucin
do proceso e os eventos que se detecten.
e. O manexo de excepcins, que consiste na automatizacin das accins a realizar para
recuperar un proceso cando se detecta un evento ou condicin anormal.
2.
O control procedemental, que describe as accins a realizar en cada unidade de proceso

para a obtencin dun producto mediante unha secuencia ordenada de operacins e fases. O
estndar ISA S88.01 [87] define un diagrama que describe os estados (IDL;E, STARTING,
RUNNING, etc.) e as condicins de transicin vlidas (START, STOP, ABORT, etc.) para
xestionar o funcionamento de procedementos, operacins e fases. A definicin completa de
cada procedemento, operacin ou fase realzase especificando a lxica secuencial das
accins a aplicar en cada estado. Este tipo de control o que habitualmente se utiliza en
procesos "batch" e fundamental nos sistemas de fabricacin flexbeis e nos esquemas de
control baseados no uso de `receitas'.
O control de coordinacin, que utilizado para controlar a utilizacin dos recursos
compartidos por diferentes procesos ou `lotes' de produccin. Este tipo de control
utilizado habitualmente para coordinar a transferencia ou transporte de materiais entre
diferentes unidades de produccin en sistemas de fabricacin flexbeis.
3.
2.1.3. Modelado de procesos industriais

No desenvolvemento de sistemas de control ten un papel moi importante o modelado do
proceso mediante formalismos que permitan verificar as sas propiedades formais e estudiar o
seu comportamento, xa sexa mediante mtodos analticos ou por simulacin. Dende o punto de
vista da sa dinmica, os modelos dos procesos industriais dividronse tradicionalmente en
das categoras:
1. Os modelos continuos, nos que o tempo considerado como unha varibel continua. Os
modelos matemticos destes sistemas estn baseados nos principios fundamentais de
conservacin da materia, o momento e a enerxa ou na observacin emprica das relacins
entre as magnitudes do sistema. Matematicamente son representados mediante sistemas de
ecuacins alxebraicas ou diferenciais.
39
Seccin 2.1: Os sistemas industriais e o seu control
2. Os modelos discretos, nos que o tempo considerado en instantes de tempo concretos.

Matematicamente son representados mediante sistemas de ecuacins en diferencias.
Unha aproximacin habitual no control de procesos a de representar o sistema de control
como un sistema dinmico de eventos discretos (DEDS), e utilizar algn dos numerosos
formalismos existentes para o modelado, simulacin e verificacin de DEDS: os autmatas de
estados finitos [104], os diagramas de estados ("StateCharts", [78]), as RdP [137][155], o
Grafcet [46], etc. Os DEDS son representados mediante un conxunto discreto de estados a
travs dos que a situacin do sistema evoluciona dirixida por eventos. Dependendo de se os
eventos poden producirse en calquera momento ou unicamente en instantes concretos os DEDS
clasificanse en asncronos e sncronos respectivamente.
As lias de investigacin mis recentes [8] cntranse nas aproximacins hbridas, que
combinan os modelos continuos ou discretos do proceso coas aproximacins baseadas en
modelos DEDS do sistema de control. Son numerosos os exemplos de fenmenos que son
mellor representados mediante aproximacins hbridas: o arranque e parada de procesos
continuos, os sistemas "batch" nos que se combinan procesos discretos e continuos, a
utilizacin de reguladores dixitais en procesos continuos, etc. As principais motivacins para
utilizar aproximacins hbridas no modelado de procesos industriais son:
1. A reduccin da complexidade dos modelos con tcnicas como por exemplo:
a.
b.
A aproximacin do modelo non lineal dun proceso continuo mediante varios modelos
lineais entre os que se conmuta en funcin de determinadas condicins.
A estructuracin xerrquica do sistema de control utilizando modelos abstractos nos
niveis superiores que son simplificacins discretas dos modelos continuos dos niveis
inferiores.
2. A utilizacin de dispositivos dixitais para o control de procesos continuos mellor

modelada como un sistema hbrido, no que se utiliza un modelo continuo ou discreto para o
proceso e un modelo DEDS para o sistema de control.
2.1.4. A arquitectura fsica do sistema de control

A Figura 2.3 mostra a arquitectura fisica utilizada como referencia neste traballo para
proporcionar soporte execucin do "soflware" do sistema de control. Esta arquitectura est
formada por computadores e PLCs nos que se dispn de sistemas operativos con capacidades
de tempo real (RTOS) e que se interconectan mediante redes de comunicacins industriais. A
interaccin co proceso realzase mediante dispositivos de E/S interconectados utilizando buses
de campo. En [35] analzase a idoneidade desta arquitectura para a implementacin da
estructura xerrquica dun sistema de control industrial como o da Figura 2.2.
Computador de
desenvoNimento
PLC con
RTOS
;
IÎ
^^
Computador
con RTOS
Computador
con RTOS
LAN industrial
- PLC con
R^
Bus de campo
Sensores/Actuadores
Figura 2.3. Arquitectura fisica dun sistema de control industrial.
40
2.2. O desenvolvemento de "software" para sistemas industriais

Neste apartado descrbense brevemente as caractersticas do proceso de desenvolvemento de
"software" para sistemas de control industrial como parte da actividade desenvolvida no
contexto mis xenrico da enxeera de sistemas industriais. A descricin que se realiza e as
definicins utilizadas estn baseadas no estndar ENV 40 003 [34] e en traballos relacionados.
2.2.1. As arquitecturas de referencia na enxeera de sistemas industriais

O desenvolvemento de "soflware" en sistemas industriais (e mis especificamente, o de
"software" de control) debe entenderse como unha mis das actividades realizadas durante o
ciclo de vida do sistema industrial, e as metodoloxas de desenvolvemento "software" como un
mtodo a ser integrado cos procedentes doutras disciplinas (como a enxeera de procesos
industriais ou a enxeera de control, por exemplo) no contexto da aplicacin das tecnoloxas
da informacin e as comunicacins enxeera de sistemas industriais.
A enxeera de sistemas industriais est sufrindo na actualidade un proceso semellante ao
que no seu da se deu no campo da enxeera do "software", coa busca de metodoloxas,
mtodos e ferramentas que permitan, mediante a utilizacin de ambientes asistidos por
computador, a aplicacin de aproximacins sistemticas coas que podan manexarse as
crecentes demandas dos novos paradigmas de fabricacin (como o JIT [44] ou a enxeera
concorrente [136], por exemplo) derivados da necesidade de adaptarse a un mercado en
continua e rpida evolucin.
Debido complexidade deste proceso nunha actividade que integra mltiples disciplinas
consideradas dende diferentes puntos de vista (dende o tcnico ate o econmico ou xurdico)
propuxronse varias arquitecturas de referencia para o modelado de empresas20 (GRAI/GIM
[54], CIMOSA [4] ou PERA [ 174]). Estas arquitecturas proporcionan un mrco de referencia
no que situar os modelos, mtodos e ferramentas utilizados ao longo do ciclo de vida da
empresa, co obxectivo de obter un ambiente de modelado asistido por computador no que os
modelos podan ser editados, executados e utilizados en ltimo termo para a operacin,
monitorizacin e control das actividades da empresa. As arquitecturas propostas organzanse
dacordo a tres dimensins [34]:
1. A dimensin da xenericidade, que o nivel de abstraccin correspondente aos elementos da
arquitectura utilizados:
a.
b.
c.
O nivel xenrico, no que se definen os elementos de modelado bsico.

O nivel parcial, formado por modelos parciais que poden ser reutilizados e adaptados
polo usuario para obter modelos particulares.
O nivel particular, no que se describen os aspectos particulares da empresa utilizando
os elementos do nivel xenrico e parcial.
O proceso de particularizacin de modelos a partir dos elementos xenricos e modelos

parciais denomnase refinamento por particularizacin ou instanciacin.
2. A dimensin dos modelos, que o nivel de abstraccin correspondente as fases do proceso
de desenvolvemento do modelo da empresa:
a. Os modelos de requirimentos, que definen as operacins a realizar pola empresa.
20 O concepto de empresa utilizado nestas arquitecturas nun sentido amplo, que inclue ao de sistema industrial
definido anteriormente (2.1.1).
41
Seccin 2.2: O desenvolvemento de "software" para sistemas industriais

b. Os modelos de deseo, que especifican como van a realizarse as operacins para
cumprir cos requirimentos da empresa.
c. Os modelos de implementacin, que describen os medios e regras a utilizar na

execucin das operacins da empresa.
O proceso de obtencin dos modelos de implementacin a partir dos de requirimentos e
deseo denomnase refinamento por derivacin.
3. A dimensin das vistas, que son descricins que se concentran en aspectos particulares da
empresa co obxectivo de reducir a complexidade:
a. A visin funcional, que proporciona unha descricin xerrquica das funcins, do
comportamento e da estructura funcional da empresa.
b. A visin da informacin, que proporciona unha descricin estructurada dos obxectos da
empresa identificados nas outras vistas.
c. A visin dos recursos, que proporciona unha descricin da organizacin dos recursos
da empresa.
d. A visin organizativa, que proporciona unha descricin da estructura organizativa da
empresa.
O nmero de vistas non fixo e as vistas non son modelos en si mesmas senn diferentes
puntos de vista do modelo da empresa. O proceso da sa obtencin para cada nivel de
modelado denomnase refinamento por xeracin.
Unha das caractersticas definitorias destas arquitecturas o papel central que adquire a
actividade de modelado e o interese por conseguir a infraestructura que permita dispor de
modelos parciais estandarizados que podan ser reutilizados adaptndoos aos aspectos
particulares de cada sistema. Isto permitira avanzar cara a unha situacin equiparbel que se
da noutras reas como a electrnica ou a enxeera do "software" baseada en compoentes: a
existencia de ambientes abertos que posibiliten o desenvolvemento de arquitecturas
consistentes, modulares e flexbeis mediante a conexin de mdulos estandarizados
dispobeis en forma de libraras ou mdulos "software" precompilados (aproximacin "plug
and-play" [139]).
2.2.2. O modelado na enxeera de sistemas industriais

Como se indicou anteriormente o modelado unha actividade central na enxeera de
sistemas industriais. Os modelos son utilizados para a anlise, deseo, simulacin e operacin
(control, coordinacin e monitorizacin) dos sistemas, ademais de servir como medio de
representacin do coecemento ("know-how"), como ferramenta de apoio toma de decisins
ou como elemento de integracin de puntos de vista multidisciplinares, por exemplo. O
modelado dun sistema industrial abrangue numerosos aspectos que deben ser considerados
dende diferentes puntos de vista (funcional, informacin, recursos, organizacin, etc.) como,
por exemplo: os procesos e a sa estructura funcional, os productos, os equipamentos de
proceso e control, a estructura organizativa e de toma de decisins, etc.
En [ 169] descrbense os principios que se aplican no modelado de empresas (e sistemas
industriais) para manexar a sa complexidade:
1. Principio de separacin temtica, que establece que a empresa non debe considerarse un
todo, senn ser analizada por partes.
42
2. Principio de descomposicin funcional, que establece que a empresas son sistemas

dinmicos complexos definidos principalmente en base sa funcionalidade que
modelada mediante unha xerarqua de subfuncins. A aproximacin funcional de mtodos
como SADT [144] ou IDEF [81] a utilizada tradicionalmente nos sistemas industriais.
Recentemente propxose en CIMOSA [4] a utilizacin dunha aproximacin baseada en
procesos.
^^
3. Principio de modularidade, que establece que os modelos deben ser modulares,

construdos mediante a ensamblaxe de bloques bsicos predefinidos.
4. Principio da xenericidade do modelo, que establece a importancia de definir bloques
xenricos estandarizados que abstraian os aspectos comns a diferentes dominios que
podan ser adaptados para a sa utilizacin en aplicacins particulares.
5. Principio de reusabilidade, que establece a reusabilidade dos modelos xenricos ou
parciais previamente existentes na creacin de novos modelos.
6. Principio de separacin do comportamento e a funcionalidade, que establece a distincin
entre as funcins a realizar e como son realizadas, para garantir a flexibilidade organizativa
da empresa.
7. Principio de separacin de proceso e recurso, que establece a distincin entre as
operacins realizadas e as entidades que as realizan, para garantir a flexibilidade operativa
da empresa.
8. Principio de conformidade, que establece que as linguaxes de modelado deben ser
consistentes e non redundantes.
9. Principio de visualizacin do modelo, que establece que as linguaxes de modelado deben
ter representacins grficas simples e non ambiguas.
En [ 124] identiflcanse como bsicos os principios de xenericidade, modularidade e
reusabilidade na aplicacin dunha aproximacin ao desenvolvemento de sistemas industriais
mediante a utilizacin de bloques de modelado predefinidos e libraras de mdulos "software"
de diferentes provedores. As ferramentas informticas que proporcionen soporte a esta
aproximacin deben cumprir os seguintes requisitos [169]:
1. Proporcionar bloques de modelado xenricos, representados mediante "templates" e
implementados mediante tcnicas de orientacin a obxectos.
2. Proporcionar libraras de modelos (parciais e particulares) que podan ser reutilizados.
3. Permitir o acceso aos modelos dende diferentes puntos de vista, como mnimo o funcional,
de informacin, de recursos e o organizativo comentados anteriormente.
4. Proporcionar soporte nas diferentes fases do ciclo de vida do sistema comentados
anteriormente: requirimentos, deseo e implementacin.
Considerase en [ 169] que unha plataforma formada por unha interface grfica sobre un
ambiente de programacin orientado a obxectos adecuada para a implementacin destas
ferramentas, e que a principal dificultade est en proporcionar ambientes grficos amigbeis
para o usuario ao tempo que se oculta a complexidade do manexo dos modelos e se
proporcionan funcins eficaces de anlise e simulacin.
2.2.3. Caractersticas do "software" de control industrial

O"software" de control industrial ten caractersticas coincidentes coas do "software" para
sistemas de tempo real, anda que tamn presenta algunhas peculiaridades. Sen nimo de ser
43
Seccin 2.2: O desenvolvemento de "soflware" para sistemas industriais
exhaustivos poden considerarse as caractersticas indicadas a continuacin como as mis

significativas das aplicacins de control industrial:
1. Estn deseadas para interactuar directa ou indirectamente cun proceso fisico, xa sexa en
tarefas de control, supervisin ou coordinacin, polo que a consideracin dos requisitos
temporais do proceso un aspecto fundamental no deseo e implementacin da-aplicacin
para garantir a reactividade e a seguridade na operacin do sistema de control.
2. Teen estructuras "software" complexas organizadas xerarquicamente dende un punto de
vista lxico e que poden reconfigurarse dinamicamente para adaptarse a diferentes modos
de operacin. Fisicamente estn distribudas en sistemas como o da Figura 2.3, nos que
poden realizarse mltiples actividades simultneas en cada nodo. En consecuencia a
estructuracin xerrquica, a configuracin dinmica, a distribucin e a concorrencia son
caractersticas inherentes deste tipo de aplicacins.
3. Integran mltiples descricins que utilizan distintos puntos de vista do sistema: a estructura
fisica e o comportamento dinmico do proceso; a estructura fisica, a funcional, os modos
de operacin e o comportamento dinmico do sistema de control; a informacin utilizada,
etc. Incorporan polo tanto diferentes formalismos de modelado para representar os aspectos
estticos, dinmicos, funcionais e informacionais da aplicacin.
4. Integran modelos da dinmica do proceso, da dinmica do sistema de control ou dambas.
Estes modelos son representados utilizando formalismos que permiten verificar durante o
deseo as propiedades formais do modelo mediante tcnicas analticas ou por simulacin.
2.2.4. Aplicacin de metodoloxas "software" en sistemas industriais

Dadas as caractersticas descritas anteriormente, pode deducirse que o desenvolvemento de
"software" en sistemas industriais require de metodoloxas que combinen unha aproximacin
"software" (con caractersticas de tempo real) con formalismos para o modelado dinmico de
sistemas [ 181 ]. A utilizacin conxunta dambas aproximacins permite combinar as capacidades
de modelado propias das metodoloxas "software" (diferentes niveis de abstraccin, distintos
puntos de vista, etc.) coas que proporcionan os formalismos de modelado dinmico de sistemas
(verificacin formal, simulacin, xeracin automtica de cdigo, etc.). As diferentes propostas
realizadas neste sentido poden clasificarse en catro categoras:
1. A inclusin dalgn formalismo de modelado dinmico de sistemas como parte da
metodoloxa de desenvolvemento "software", definindo as regras de integracin do novo
formalismo cos demais modelos da metodoloxa. Algns exemplos son o Grafcet con OMT
[157] ou as RdP con OMT [12].
2. A definicin de semnticas formais para os modelos ìnformais' da metodoloxa
"software". Algns exemplos son os diagramas de actividades en SADT [145) ou os
StateCharts en OMT [80].
3. A asociacin dunha semntica formal aos modelos ìnformais' da metodoloxa "software"
mediante a especificacin dun algoritmo que permita convertelos a unha representacin na
que se utilice un formalismo de modelado dinmico de sistemas. Algns exemplos son
SADT e RdP [ 181 J, SA/RT e RdP [57] ou LJML e RdP [23].
4. A proposta de novos formalismos que incorporan capacidades adicionais (estructuracin
xerrquica, abstraccin, reusabilidade) aos formalismos de modelado dinmico de sistemas
bsicos. Algns exemplos son os Object-StateCharts [180] ou as RdP de alto nivel ("HighLevel Petri Nets", [91]).
44
A aproximacin utilizada nesta tese de doutoramento pertence primeira das categoras

indicadas anteriormente, propoendo a utilizacin conxunta do Grafcet coa UML [29]
definindo a relacin entre ambos a travs dos seus metamodelos.
2.3. A ferramenta proposta
Neste apartado descrbense as avantaxes proporcionadas no desenvolvemento de "software"

para sistemas industriais polas caractersticas implementadas na ferramenta proposta nesta tese
de doutoramento: a orientacin a obxectos e o modelado de DEDS mediante Grafcet. Ademais
comprase a aproximacin utilizada con outras aproximacins relacionadas; descrbese a
arquitectura lxica da ferramenta e o proceso de desenvolvemento dunha aplicacin con ela; e
indcanse as tcnicas dispobeis para a integracin con outras aplicacins. En conxunto a
ferramenta implementada proporciona as funcionalidades precisas para obter automaticamente,
a partir dos modelos especificados nas fases de anlise e deseo, unha versin da aplicacin
executbel nunha mquina virtual deseada para dar soporte a aplicacins dirixidas por eventos
en ambientes distribudos como o da Figura 2.3.
2.3.1. A orientacin a obxectos no modelado de sistemas industriais

No modelado de sistemas industriais tense aplicado diferentes aproximacins como a
funcional (SADT, IDEF), a de modelado da informacin (diagramas entidade-relacin [41]) ou
a da especificacin da dinmica (RdP). A utilizacin da aproximacin orientada a obxectos est
obtendo cada vez maior aceptacin debido a que os principios nos que se sustenta (capsulacin,
abstraccin, modularidade e xerarquizacin) proporcionan mltiples avantaxes no modelado e
simulacin de sistemas complexos heteroxneos:
1. O soporte reusabilidade dos modelos, mediante mecanismos como a^ herdanza ou a
composicin.
^
2. A modularidade, que permite capsular os modelos para formar compoentes con interfaces
ben definidas que poden organizarse en libraras para ser reutilizados.
3. A flexibilidade dos modelos orientados a obxectos, que poden ser modificados e ampliados
engadindo, eliminando ou modificando obxectos e clases.
4. A portabilidade dos modelos, que poden ser compartidos entre diferentes plataformas.
5. A expresividade da orientacin a obxectos, que utiliza un concepto uniforme en diferentes
niveis de detalle e fases do ciclo de vida do sistema. ademais poden obterse versins
executbeis dos modelos de maneira natural utilizando unha linguaxe de programacin
orientada a obxecto.
6. A consistencia entre os distintos puntos de vista do modelo.
7. A dispoibilidade dunha linguaxe unificada de modelado (UML [29]) e dunha
infraestructura de execucin distribuda (CORBA [126]) estandarizadas.
8. A dispoibilidade de multitude de metodoloxas, mtodos, linguaxes e ferramentas para a
anlise, deseo, simulacin e programacin orientada a obxectos.
Como exemplos da aplicacin da aproximacin orientada a obxectos en sistemas industriais
^
poden citarse os seguintes:
Entre as metodoloxas: IEM [ 117], metodoloxa que combina conceptos da orientacin a

obxectos con diagramas de actividades baseados nos de IDEF; CIMOSA [4], que se ben en
45
Seccin 2.3: A ferramenta proposta

si mesma non unha metodoloxa orientada a obxectos, si se identifica esta aproximacin
como vlida para a representacin e implementacin de parte das propostas que nela se fan.
Entre as ferramentas: MOSES [ 112], un ambiente para o modelado de sistemas hbridos

complexos; FBCad [111], un ambiente de programacin baseada en compoentes para o
desenvolvemento de bloques funcin reutilizabeis que soporta o deseo, sirnulacin e
xeracin de cdigo para sistemas distribudos; G2 [68], un ambiente de programacin de
sistemas de supervisin ìntelixentes' que combina unha aproximacin orientada a obxecto
con mecanismos de busca heurstica baseados en regras.
Un dos principais focos de interese da aplicacin da aproximacin a obxectos a sistemas

industriais que soporta de forma natural a construccin de libraras de bloques xenricos para
o modelado de sistemas que, ao ser representados mediante "templates", poden ser reutilizados
ou adaptados para obter modelos particulares, utilizando os mecanismos de instanciacin,
herdanza ou composicin propios da orientacin a obxectos. A simulacin e xeracin do cdigo
dos modelos particulares directa utilizando o soporte proporcionado polas ferrarnentas e
linguaxes dispobeis. A principal carencia a non dispoibilidade na industria dun modelo de
referencia estandarizado, unha proposta neste sentido pode consultarse en [36].
2.3.2. O Grafcet como formalismo de especificacin

Dacordo a[99], os requisitos que debe cumprir un formalismo para a especificacin de
sistemas de control complexos son:
1. Debe ser grfico e fcil de utilizar polo enxeeiro de control.
2. Debe estar baseado nun mtodo xerrquico que permita diferentes niveis de abstraccin.
3. Debe basearse nunha aproximacin hbrida que integre un modelo discreto para a
coordinacin da lxica de execucin das actividades de control e un modelo continuo para
a sntese das leis de control.
4. Debe permitir a representacin de comportamentos xenricos que representen invariantes
en certos dominios de aplicacin que permitan derivar modelos particulares para os
sistemas de control pertencentes a eses dominios.
Analizando o Grafcet dende o punto de vista dos criterios anteriores, as conclusins son as
seguintes:
1. O Grafcet un formalismo grfico estandarizado [84][85] para a especificacin de
controladores lxicos secuenciais, fcil de utilizar, amplamente difundido e independente
da tecnoloxa de implementacin utilizada.
2. O Grafcet define unha estructura xerrquica ( 3.2.2.3) e permite a utilizacin de diferentes
niveis de detalle en accins e condicins, polo que pode ser utilizado con mtodos nos que
se aplique unha estratexia baseada no refinamento sucesivo a diferentes niveis de
abstraccin.
3. O Grafcet especialmente adecuado para a coordinacin de diferentes actividades. En [30]
descrbense tres posbeis formas de utilizar o Grafcet na estructuracin dun sistema de
control:
a. A estructura global do sistema modelase usando algn formalismo distinto ao Grafcet,
e os mdulos que a forman son especificados utilizando distintos formalismos, includo
o Grafcet (Figura 2.4.a). Os mdulos que utilicen Grafcet interaccionan cos demais
mediante o intercambio de valores booleanos.
46
b.
A estructura global do sistema modlase utilizando o Grafcet, e os mdulos que a

forman son especificados utilizando distintos formalismos, includo o Grafcet (Figura
2.4.b). A coordinacin entre a estructura global e os mdulos que utilicen outros
formalismos realzase mediante o intercambio de valores booleanos.
c.
A estructura e os mdulos que a forman son especificados utilizando o Grafcet (Figura

2.4.c).
^
Estas estructuracins estn baseadas na definicin orixinal do Grafcet [84], que estaba
dirixida especificacin de controladores lxicos nos que as varibeis utilizadas eran
unicamente de tipo booleano. Recentemente a revisin do estndar [85] adoptou as
propostas de [75] e[76] para ampliar a aplicabilidade do Grafcet a sistemas hbridos.
Aplicacins do Grafcet na estructuracin do control de sistemas hbridos e"batch" son
descritas en [172] e [95], respectivamente.
4. O estndar Grafcet non incle un medio de representar comportamentos xenricos a partir
dos que poidan derivarse modelos particulares. Existen propostas baseadas en
aproximacins orientadas a obxecto que inclen esta capacidade: parametrizacin de
grafcets, macroetapas e procedementos en [94] ou herdanza e agregacin de modelos
dinmicos en [157].
J ^soo', C
Bool
Real
Control contnuo
Control contnuo
-1 (p . e . posicionador
brazo robotizado)
(p.e. posicionador
brazo robotizado)
(a)
(b)
(c)
Figura 2.4. Formas de estructurar un sistema de control utilizando Grafcet: a) o Grafcet utilizado nalgn dos
mdulos que forman o sistema de control; b) o Grafcet utilizado para a coordinacin dos mdulos do sistema de
control; e c) o sistema de control especificado completamente utilizando o Grafcet.
47
Ademais das caractersticas anteriores, o Grafcet ofrece outras avantaxes:

1. Ao ser un formalismo estandarizado e grfico, facilita a comunicacin entre os diferentes
tcnicos e futuros usuarios implicados no proceso de desenvolvemento do sistema de
control.
2. Mediante o soporte informtico adecuado, pode utilizarse o mesmo formalismo dende a
especificacin do sistema ate a sa operacin e mantemento [30]. O propio formalismo
pode utilizarse como interface grfica para a simulacin e monitorizacin do sistema.
3. O Grafcet pode utilizarse para estructurar o sistema dende diferentes puntos de vista [95]:
funcional, fisico, modos de operacin, etc.
4. O Grafcet permite automatizar diferentes funcins de control utilizando o mesmo
formalismo: coordinacin, seguridade, deteccin de fallas [62][63], supervisin [61], etc.
5. O Grafcet un formalismo de especifcacin independente da tecnoloxa utilizada na sa
implementacin (p.e. pneumtica, electromecnica, computador) e da distribucin fisica
dos modelos.
6. Disponse de diferentes mtodos formais para a validacin, verificacin e sntese de
modelos Grafcet (3.1) e dunha versin estandarizada [86] adaptada programacin de
PLCs -o SFC (3.6.1^.
2.3.3. Comparacin con outras aproximacins

Descrbense a continuacin as principais caractersticas que distinguen o traballo realizado
nesta tese de doutoramento doutros relacionados. Ntese que son moitas as aproximacins
existentes para o desenvolvemento de "software" en sistemas de control industrial, polo que
unicamente se citan aquelas que se consideraron conceptualmente mis prximas proposta
realizada:
1. Utilizacin do Grafcet como parte dunha metodoloxa para o desenvolvemento de sistemas
de control industrial. Existen varias propostas de metodoloxas que utilizan o Grafcet para a
especificacin das secuencias lxicas das actividades de control identificadas por medio da
aplicacin dalgn mtodo, xa sexa de descomposicin funcional ou orientada a obxectos. O
Grafcet utilzase unicamente a nivel local e a coordinacin de actividades modlase
mediante outro formalismo DEDS (RdP, StateCharts). Como exemplos pdense citar:
SADT con RdP [ 181 ], OMT con extensins para o modelado de xerarquas funcionais
[ 181 ] ou uso de diagramas de fluxo e RdP [37].
Con respecto a estas metodoloxas a ferramenta proposta complementaria. Utilizando 0
metamodelo Grafcet como formato de representacin dos modelos poden integrarse as
ferramentas que dean soporte a estas metodoloxas co compilador e o intrprete Grafcet, tal
e como se explica en (2.3.6). Isto posibilita o paso automtico da especificacin
implementacin e a dispoibilidade dun ambiente para a simulacin e operacin dos
modelos.
2. Inte^racin do Grafcet nunha metodoloxa "software" como formalismo alternativo para a
especificacin do comôrtamento. O nico traballo neste sentido do que o autor desta tese
ten noticia a proposta realizada en [157]. Nese traballo proponse un metamodelo para
integrar o Grafcet na metodoloxa OMT e enncianse os principios para a reutilizacin dos
modelos mediante os mecanismos de herdanza e agregacin. Este un traballo inicial que
enuncia unhas ideas bsicas dende o punto de vista do deseo. Non se tratan aspectos
importantes como a semntica e a implementacin dos modelos, e o metamodelo proposto
non incle todas as caractersticas comentadas en (3.2.2).
48
3. Utilizacin dun formalismo baseado no Grafcet: o GraphChart f91. Este formalismo

basease na sintaxe e semntica do Grafcet e incle conceptos avanzados como a
parametrizacin, o uso de mtodos ou o paso de mensaxes, tomados da aproximacin
orientada a obxectos e das RdP de alto nivel [91]. O GraphChart foi aplicado na
especificacin de supervisores intelixentes [9] e no modelado de receitas en sistemas
"batch" [95]. En [94] descrbense as diferencias entre o Grafcet e o GraphChart. O
principal inconveniente do GraphChart dende o punto de vista prctico que s se dispn
dunha implementacin en G2 [68], un ambiente orientado ao desenvolvemento de
aplicacins de suprvisin intelixente. Isto limita a aplicabilidade do formalismo e require
de soporte adicional para a xeracin de cdigo eficiente. Actualmente est en proxecto
unha versin Java, denominada JGraphChart, que anda non estaba dispobel no momento
de redactar esta tese.
4. Aproximacins baseadas nas RdP. Existen numerosos traballos que utilizan as RdP como
formalismo para o desenvolvemento de "software" de control. Entre os mis relacionadas
cos obxectivos desta tese poden citarse: a proposta dun mtodo baseado na lxica de paso
de testigo para a obtencin dunha representacin en linguaxe de contactos dunha RdP dada
[96]; a integracin das RdP nunha ferramenta de desenvolvemento "software" baseada na
utilizacin de UML [47]; a proposta dunha metodoloxa de desenvolvemento "software"
para a obtencin de programas en lista de instruccins (IL) para PLCs a partir de modelos
formais que utilizan un tipo de RdP [98]; e a proposta dun metamodelo para as RdP que
utiliza conceptos de modelado orientado a obxectos e que pode ser utilizado no deseo de
compoentes "software" xenricos orientados ao control industrial [109].
O Grafcet proporciona capacidades de modelado, anlise e verificacin prximas s das
RdP (3.4.4.1), e ademais un formalismo estandarizado, fcil de aprender e interpretar, e
unha linguaxe estndar de programacin de PLCs baseada nos seus conceptos. O Grafcet
mellor aceptado nos ambientes industriais sobre todo durante a operacin do sistema, xa
que os modelos obtidos coas RdP tenden a ser complexos e dificiles de interpretar. O
mbito de aplicabilidade da ferramenta proposta est mis orientado s fases de deseo,
implementacin e operacin da aplicacin que s de anlise e verificacin, polo que o
Grafcet foi o formalismo escollido. factbel tamn a utilizacin de aproximacins
hbridas que utilicen ambos formalismos, integrando a ferramenta proposta con algunha
outra que dea soporte s RdP mediante os mecanismos descritos en (2.3.6).
5. Anroximacins baseadas nos StateCharts. Os StateCharts foron inicialmente propostos para
a especificacin de sistemas reactivos complexos descritos mediante diagramas de estados
e transicins aos que basicamente se lles engade a concorrencia e unha estructura
xerrquica. Foron includos como formalismos para a especificacin do comportamento en
metodoloxas orientadas a obxectos como Booch ou UML, e son utilizados con pequenas
variacins en ferramentas comerciais como o StateFlow de MatLab, o Statemate21, ou o
anyStates22. O Grafcet proporciona capacidades de modelado prximas s dos StateCharts
(3.4.4.3), e as razns para sa utilizacin son semellantes s comentadas para as RdP. A
utilizacin de aproximacin hbridas que combinen ambos formalismos facilita a aplicacin
de ferramentas de desenvolvemento "software" xenricas na implementacin de
controladores industriais. Como se comentou anteriormente, nesta tese proponse con ese
fin un metamodelo para o Grafcet integrado no de UML (5.1). Outra aproximacin que
21 Statemate un producto da compaa I-Logix. http://www.ilogix.com/
22
AnyStates un producto da compaa XJ Technologies. http://www.xjtek.com/
49
propn a utilizacin do SFC para a descricin detallada das accins estticas nos estados
dun StateChart pode consultarse en [ 19J.
6. Ambientes de programacin SFC/Grafcet. Existe unha variedade de ferramentas
dispobeis na actualidade, orientadas sobre todo programacin de PLC's ou "softPLCs",
que inclen o SFC ou algunha versin mis ou menos completa do Grafcet como^ linguaxe
grfica de programacin. Algunhas destas aplicacins son analizadas en detalle no Captulo
4. As principais aportacins da ferramenta proposta, considerando as conclusins extradas
da anlise realizada nese captulo, son as seguintes:
a.
b.
c.
d.
e.
Definese un metamodelo para o Grafcet relacionado co da UML que pode ser utilizado
como formato de intercambio dos modelos Grafcet entre aplicacins ou para integrar o
Grafcet en ambientes CASE baseados en LJML e utilizalo as como alternativa para a
especificacin do comportamento das compoentes dinmicas dos modelos.
As funcionalidades para a representacin, compilacin, simulacin e execucin de
modelos Grafcet poden ser utilizadas de maneira integrada dende o editor grfico da
ferramenta ou de maneira independente dende outras ferramentas que utilicen os
mecanismos de integracin indicados en (2.3.6).
A interpretacin de modelos pode ser configurada para elixir o algoritmo a utilizar e a
fonma en que os eventos, varibeis e accins sern considerados durante as evolucins
internas utilizando interpretacins semnticas ben definidas ( 3.3.2).
Disponse dun ambiente de execucin (a mquina virtual) flexbel, portbel, escalbel e
configurbel dinamicamente, que facilita a aplicabilidade en ambientes distribudos e
heteroxneos. Ademais a sa funcionalidade non se limita interpretacin de modelos
Grafcet, senn que proporciona os mecanismos bsicos (xestin de eventos,
temporizacins e varibeis de E/S) que permitirn integrar intrpretes doutros
formalismos DEDS en futuras versins.
A linguaxe de programacin de accins utilizada o C++, o que posibilita a utilizacin
do grande nmero de libraras externas existentes e que, conxuntamente co
meetamodelo Grafcet definido, permiten integrar o Grafcet cunha aproximacin
orientada a obxecto no desenvolvimento de "software" para sistemas de control
industrial.
2.3.4. A arquitectura da ferramenta

A^ arquitectura lxica da ferramenta proposta est formada por dous subsistemas: o
subsistema de desenvolvemento (Figura 2.S.a) e o de execucin (Figura 2.S.c). O subsistema de
desenvolvemento est formado por un editor que proporciona unha interface grfica a travs da
que o usuario accede s funcionalidades da ferramenta e un compilador que xera o cdigo a
executar no subsistema de execucin. O subsistema de execucin est composto por unha
mquina virtual que contn un intrprete Grafcet e os mdulos que permiten a interaccin da
mquina virtual cun proceso fisico e cos servizos proporcionados polo "hardware" e o sistema
operativo (procesos, temporizacins) no que se execute. Ambos subsistemas interaccionan a
travs dos servizos de acceso remoto da mquina virtual que permiten a consulta e
modificacin da sa configuracin e a carga, descarga e control da execucin das aplicacins.
Os subsistemas poden executarse en equipos diferentes ou no mesmo equipo (Figura 2.S.b),
que a configuracin habitual utilizada durante a simulacin. Esta arquitectura modular e
facilmente escalbel, pudendo utilizarse configuracins distribudas nas que unha ou mis
mquinas virtuais se utilicen conxuntamente cun ou mis subsistemas de desenvolvemento. Sen
embargo para que a ferramenta sexa plenamente operativa en ambientes distribudos preciso
50
incluir certas funcionalidades que non foron consideradas na versin actual, como por exemplo
a edicin simultnea de modelos, asistencia compilacin e distribucin automtica de
aplicacins en redes heteroxneas, ou o intercambio de informacin de estado entre mquinas
virtuais.
^
Modelos
Grafcet
Ambiente de desenvolvimento
odelos
rafcet
compilados
Hardware/Sistema Operativo
Ambiente de
desenvolvimento
Compilador GrafceUC++
^
Modelos
Grafcet
compilados
^
odelos
rafcet
^
Editor Grafcet
Mquina Vrtual
(b)
(a)
Aplicacin de usuario
Modelos Grafcet en execucin

--------------;
^ Depurador ;
'------------ --^
Xstor
Confi uracin
Intrprete Grafcet
gase de datos
^^ Simulador ElS ;^
'--------------
P estor
Tem orizadores
Xestor
Eventos
M3quina virtual
Subsistema de E/S
(c)
Figura 2.5. Arquitectura da ferramenta proposta: a) subsistema de desenvolvemento; b) configuracin co
subsistema de desenvolvemento e execucin no mesmo equipo; e c) subsistema de execucin.
2.3.5. O proceso de desenvolvemento coa ferramenta

A Figura 2.6 mostra un diagrama que representa o proceso de desenvolvemento dunha
aplicacin utilizando as compoentes da ferramenta implementada. O editor Grafcet
proporciona unha interface griica comn a travs da que o usuario accede s funcionalidades
da ferramenta, sen embargo, tanto o compilador como a mquina virtual non dependen do
editor grfico e poden ser utilizadas por separado como aplicacins autnomas.
Ed itor
Grafcet
Figura 2.6. Proceso de desenvolvemento dunha aplicacin coa ferramenta implementada.
51
No editor grfico o enxeeiro utiliza unha combinacin de C++ e Grafcet para modelar a
estructura do sistema de control a diferentes niveis de abstracin e dende diferentes puntos de
vista. O cdigo C++ utilizado para estructurar os modelos pode codificarse manualmente ou
importarse o xerado automaticamente cunha ferramenta CASE externa. Os mtodos definidos
nas interfaces pblicas das clases que compoen os modelos poden ser utilizados dende o
cdigo de accins e condicins, que tamn ser programado en C++. O Grafcet utilizado no
editor para a especificacin das secuencias de estados de operacin (2.1.1) das compoentes
identificadas nos modelos, s como para a descricin detallada da lxica secuencial deses
estados. As colaboracins entre compoentes e a dinmica global do sistema de control tamn
son modeladas mediante Grafcet.
O editor proporciona asistencia durante a edicin grfca dos modelos Grafcet, facilitando a
sa estructuracin, a sa verificacin sintctica, a codificacin de accins e condicins e a
declaracin das varibeis utilizadas. Unha vez finalizada a edicin obtense unha versin
executbel do modelo mediante o compilador Grafcet. Este converte o modelo Grafcet a unha
representacin C++ equivalente e utiliza un compilador C++ externo para obter unha versin
compilada en forma de DLL. O compilador C++ utilizado pode ser un compilador nativo ou
cruzado, dependendo de se o sistema operativo do equipo no que se executa a mquina virtual
coincide ou non co do equipo no que se executa o subsistema de desenvolvemento.
A versin executbel do modelo pode utilizarse tanto para a validacin do sistema
(simulando as E/S) como para o control do proceso. A mquina virtual pode ser configurada
para axustar os tempos de resposta do sistema dependendo dos requisitos temporais do proceso.
Ademais a mquina virtual implementa un modo de depuracin que permite visualizar no
editor grfco o estado de evolucin do modelo Grafcet e que pode ser utilizado dende
aplicacins externas para a implementacin dunha interface grfica de operador que permita a
monitorizacin e a supervisin do proceso durante a sa operacin.
Ntese que o proceso descrito anteriormente pode repetirse mltiples veces durante o
desenvolvemento dunha aplicacin, xa sexa en fases diferentes (p.e. anlise, deseo,
implementacin, probas, operacin, mantemento); con distintos niveis de refinamento (p.e.
especificacin inicial, especificacin detallada, implementacin); ou concentrndose en partes
diferentes dun mesmo modelo. A ferramenta utilzase de maneira uniforme nas diferentes fases
e niveis de abstraccin, o que a fai especialmente indicada para procesos de desenvolvemento
de "software" iterativos baseados na construccin e refinamento progresivo de modelos
grficos executbeis.
2.3.6. Integracin da ferramenta con outras aplicacins

A ferramenta proposta foi deseada para ser utilizada en ambientes de desenvolvemento de
"software" de control heteroxneos, nos que se utilice conxuntamente con outras aplicacins
para o modelado de sistemas continuos, o deseo orientado a obxectos, o modelado de DEDS
utilizando formalismos distintos a Grafcet como os StateCharts ou as RdP, etc. A ferramenta
proporciona tres formas diferentes de integracin con outras aplicacins:
1. A inclusin dos modelos desenvolvidos noutras ferramentas como parte do modelo Grafcet
a executar na mquina virtual, que pode facerse de das maneiras: obtendo unha versin
C++ dos modelos e importndoa no editor (Figura 2.7.a); ou obtendo unha versin
compilada que poida enlazarse DLL da aplicacin (Figura 2.7.b).
.
2. A utilizacin do mecanismo de simulacin da mquina virtual para o intercambio de
informacin en tempo de execucin (7.2.3). Neste caso a mquina virtual executa
52
unicamente o modelo Grafcet, e os modelos definidos coas outras ferramentas son

executados en aplicacins externas mquina virtual (Figura 7.17).
3. Utilizando o metamodelo Grafcet proposto como parte da ferramenta e a librara C++ que o
implementa (5.2). Tanto o editor Grafcet como o compilador traballan con modelos
Grafcet representados utilizando este metamodelo, que pode ser utilizado basicamente de
das maneiras (Figura 2.7.c):
A
a. Como forma de integracin do Grafcet como alternativa aos StateCharts en ferramentas
de deseo orientado a obxecto baseadas en UML.
b. Como formato de intercambio coas aplicacins externas utilizadas para a verificacin
formal e a anlise de modelos Grafcet.
Aplicacin
externa
__--- '""
_ Cdigo C/C++
dos modelos
; 4InP0/fan
(a)
^---;N
Aplicacin
externa
Verifican/Anlise
^Mtmodlo
^ Grafcet
^------^
(C)
Cdigo obxecto
dos modelos .^
.
Editor
Grafcet
Modelos
Grafcet
^
^
^
^
^
^
;
'
<enlazan ;
^
Compilan
Compilador _______^
Grafcet/C++
Modelos Grafcet
compilados (DLLs)
(b)
Figura 2.7. Formas de integracin da ferramenta con outras aplicacins: a) mediante cdigo fonte C++; b)
mediante mdulos compilados; e c) mediante modelos baseados no metamodelo Grafcet.
2.4. Conclusins
Neste captulo explicronse as funcionalidades bsicas da ferramenta proposta nesta tese de
doutoramento introducndose a sa arquitectura lxica, a sa utilizacin no proceso de
desenvolvemento dunha aplicacin e os mecanismos de integracin con outras aplicacins nun
ambiente heteroxneo de desenvolvemento de "software" de control industrial. As
caractersticas da orientacin a obxectos e o modelado de istemas dinmicos de eventos
discretos foron situadas en contexto dentro do proceso mis xenrico da enxeera de sistemas
industriais utilizando unha aproximacin baseada na dispoibilidade de modelos reutilizabeis.
53
Seccin 2.4: Conclusins
As compoentes da ferramenta proposta proporcionan en conxunto as funcionalidades precisas

que permitan a un enxeeiro de control obter automaticamente o cdigo dunha aplicacin
executbel nun ambiente industrial distribudo a partir dos modelos especificados nas fases de
anlise e deseo, combinando unha aproximacin orientada a obxecto cun formalismo grfico
para a especificacin de controladores lxicos secuenciais.
_,
Como se explica nos captulos posteriores, no deseo e implementacin da ferramenta
tomronse como prioridades a modularidade, portabilidade e aplicabilidade, evitando no
posbel as dependencias de sistemas ou tecnoloxas especficas. A nica excepcin a do editor
grfico, xa que as libraras portbeis existentes non permitan as mesmas posibilidades que as
especficas dun sistema concreto, por ese motivo decidiuse a utilizacin dunha librara
dependente do sistema operativo Windows. O resto de compoentes foron implementadas na
sa versin inicial para traballar no sistema operativo Windows utilizando unha rede de
comunicacins TCP/IP, anda que a sa portabilidade a outros sistemas operativos e redes de
comunicacins est garantida mediante a utilizacin de interfaces abstractas no deseo da
aplicacin que permiten eliminar as dependencias dos aspectos especficos de cada sistema. O
soporte dun novo sistema require unicamente a implementacin desas interfaces abstractas
utilizando as funcionalidades especficas que este proporcione.
O traballo realizado nesta tese de doutoramento permitiu obter unha versin inicial da
ferramenta proposta que soporta as caractersticas indicadas neste captulo. Sen embargo
existen algns aspectos que deben ser revisados en futuras versins para mellorar a sa
aplicabilidade, principalmente no referente ao soporte distribucin de aplicacins, a
definicin de mecanismos de reutilizacin de modelos Grafcet compatbeis cos de herdanza e
agregacin da aproximacin orientada a obxectos, ou o soporte dalgunha linguaxe de
descricin de dispositivos de E/S nos "drivers" da mquina virtual, por exemplo.
Ca p tu l o 3. O G rafcet
3.1. Introduccin
O Grafcet un formalismo grfico baseado nas RdP definido co propsito de dispor dun
medio normalizado de descricin de controladores lxicos que fora independente da tecnoloxa
utilizada na sa implementacin. Foi inicialmente proposto pola AFCET [ 1], unha asociacin
francesa formada a partes iguais por membros de universidades e empresas. Posteriormente foi
adoptado como estndar, primeiro en Francia [ 164] e con posterioridade a nivel internacional
[84]. O seu uso espallouse na industria europea e na educacin [97], e a sa introduccin no
mercado americano foi medrando progresivamente [15][16]. Coa adopcin no estndar IEC
61131-3 [86] do SFC, unha versin lixeiramente modificada do Grafcet, como linguaxe grfica
para a programacin de PLCs (3.6), o Grafcet converteuse nun formalismo amplamente
recoecido e utilizado. Entre as avantaxes que proporciona poden citarse:
1. un formalismo normalizado, grfico, fcil de entender e utilizar que facilita a
comunicacin entre os tcnicos implicados no desenvolvemento dun sistema de control.
2. independente da tecnoloxa de implementacin utilizada polo que permite a anlise e
especificacin do sistema antes de pasar a considerar os aspectos relacionados coa
implementacin.
3. Pode ser aplicado en diferentes fases e a diferentes niveis de detalle da especificacin, polo
que pode utilizarse con mtodos de deseo baseadas no refinamento sucesivo da solucin.
4. Propn unha interpretacin nica das E/S como valores booleanos o que facilita a
expresin das relacins lxicas que definen o comportamento do controlador.
5. A sa definicin est baseada na das RdP, polo que se dispn dunha base matemtica que
pode ser utilizada en mtodos de anlise e verificacin formal.
6. Disponse dunha versin estandarizada para a programacin de PLCs, polo que o paso
dende a especificacin implementacin en ambientes de programacin IEC case directo.
No que respecta aos aspectos negativos, o Grafcet ten sido criticado por non dispor dunha
semntica formal que permita garantir os requisitos de correccin e seguridade, e tamn por
non existir unha metodoloxa que permita utilizalo no desenvolvemento eficiente de modelos
de calidade cando se traballa con sistemas complexos. Co nimo de superar estas limitacins
desenvolvronse (principalmente en Francia) numerosos traballos de investigacin orientados
basicamente en catro direccins [182]:
55
Captulo 3: O Grafcet
1.
56
Extensins sintcticas e semnticas
As extensins sintcticas propostas permiten estructurar xerarquicamente os modelos

Grafcet [103], facilitan o manexo de diferentes niveis de abstraccin [55][73] e melloran a
representacin de sistemas hbridos [75][76]. No referente s extensins semnticas
propuxronse interpretacins que garanten a sincrona, determinismo e reactividade dos
modelos. Parte destas propostas estandarizaronse en [165] e son explicadas en (3.2.2; 3.3.2).
2. Metodoloxas
Nesta lia realizronse algns traballos que propoen metodoloxas orientadas ao
desenvolvemento de sistemas automatizados de fabricacin nas que se utiliza o Grafcet e que
cobren o ciclo de vida do sistema. A maiora destes traballos parten dunha metodoloxa de
desenvolvemento "software" que lle incorporan algn formalismo de modelado de DEDS e
definen as regras que permiten converter os modelos representados mediante ese formalismo a
especificacins de implementacin utilizando Grafcet. Algunha destas propostas utilizan unha
aproximacin funcional [37][120][163] e outras unha aproximacin orientada a obxecto
[173][181].
3. Verificacin e validacin das especificacins
A verificacin de determinadas propiedades dos modelos Grafcet como a consistencia,
estabilidade, capacidade de reiniciacin, ausencia de bloqueo, etc. e a validacin das sas
propiedades temporais, restriccins de seguridade, etc. son campos nos que se produciu na
pasada dcada unha grande actividade investigadora. Entre o grande nmero de tcnicas
propostas pode diferenciarse entre as que teen en conta unicamente o modelo Grafcet e as que
teen en conta tamn o comportamento do sistema a controlar. Entre as primeiras hai propostas
baseadas no uso de linguaxes sncronas [7][115], autmatas con informacin temporal [116],
RdP [13], lxebra Max+ [129], mquinas de estados [38][148] ou autmatas hbridos [79]. E
entre as segundas hainas baseadas no uso de TCCS/TML [13] e no de TTM/RTTL [48].
4. Sntese dos modelos
As investigacins nesta lia basanse na teora do control supervisor [177] e teen como
obxectivo obter mtodos para a sntese do grafcet supremo [40][183][184], que o que se obtn
ao aplicar as mnimas restriccins posbeis ao comportamento dun grafcet dado para cumprir
unhas determinadas especificacins de seguridade e garantir a ausencia de bloqueo durante o
funcionamento do sistema de control.
Recentemente aprobouse unha revisin do estndar Grafcet internacional [85] que incle
algunha das propostas anteriores. O traballo realizado nesta tese de doutoramento est baseado
nas definicins anteriores a esta revisin. Para unha discusin sobre como poden representarse
algunhas das extensins adoptadas nesa revisin na ferramenta proposta nesta tese poden
consultarse [133] e [134].
O resto deste captulo estructrase da maneira seguinte: o apartado (3.2) dedcase sintaxe
do Grafcet, descrbense neste apartado os elementos sintcticos bsicos e as extensins
propostas, as como as estructuras de control mais habituais utilizadas nos modelos; no
apartado (3.3) descrbense os aspectos relacionados coa semntica do Grafcet, as regras de
evolucin, as interpretacins e postulados temporais que garanten a reactividade e
determinismo dos modelos e a interpretacin temporal das accins; no apartado (3.4)
inclense algns exemplos de modelado con Grafcet; no apartado (3.6) introdcese o estndar
IEC 61131-3 e o SFC; e finalmente, o captulo resmese en (3.7).
57
Seccin 3.2: A sintaxe do Grafcet
3.2. A sintaxe do Grafcet

3.2.1. Elementos bsicos
O Grafcet un grafo orientado formado por dous tipos diferentes de nodos: as etapas e as
transicins. Os nodos nense mediante arcos orientados. A nica regra sintctica def nida para
o Grafcet a que impide que das etapas ou das transicins estean conectadas entre si.
3.2.1.1. Etapas
As etapas representan comportamentos invariantes dentro da secuencia lxica que describe o
funcionamento do sistema de control e represntanse graficamente mediante un cadrado
(Figura 3. l.a). Durante a interpretacin do modelo cada etapa poder estar nun de dous estados
posbeis: activa ou inactiva. O conxunto de etapas activas nun instante dado determina a
situacin do modelo. Para indicar que unha etapa est activa utilizase unha marca distintiva
colocada no interior do cadrado, normalmente un pequeno crculo (Figura 3.1.b). Para
diferenciar as etapas iniciais, aquelas que estarn activas ao comezo da interpretacin do
modelo, utilizase un cadrado con dobre lia (Figura 3.1.c). As etapas son identificadas
mediante un valor alfanumrico situado no interior do cadrado. Cada etapa ter asociada unha
varibel booleana, denominada X; (sendo i o identificador alfanumrico da etapa) que durante a
interpretacin do modelo ter un valor igual a true sempre que a etapa estea activa, e igual a
false cando estea inactiva. As etapas poden ter asociadas accins (3.2.1.5), que s sern
executadas cando a etapa estea activa.
12
T
12
(a)
(b)
12
(c)
Figura 3.1. Representacin grfica de: (a) unha etapa inactiva; (b) unha etapa activa; (c) unha etapa inicial.
3.2.1.2. Transicins
As transicins representan posbeis evolucins da secuencia de control entre etapas e son
representadas graficamente mediante un trazo groso horizontal (Figura 3.2). Cada transicin
pode ter asociada unha funcin booleana denominada receptividade que determinar, dacordo
s regras de evolucin do Grafcet (3.3.1), cando unha transicin poder ser franqueada (
dicir, cando pode producirse unha evolucin na situacin do modelo). Nunca pode haber mis
dunha transicin entre das etapas calquera e a sa identificacin faise mediante un valor
alfanumrico que pode aparecer entre parnteses esquerda da transicin.
(22) +
Figura 3.2. Representacin grfica dunha transicin.
3.2.1.3. Arcos orientados

Os arcos orientados (Figura 3.3) deben unir sempre unha etapa a unha transicin ou
viceversa, mais nunca das etapas ou das transicins entre si. O sentido do arco pode indicarse
mediante unha frecha nun dos seus extremos, sendo aconsellbel utilizalo sempre que o arco
vaia de abaixo cara riba.
58
Figura 3.3. Representacin grfica dos arcos orientados.
3.2.1.4. Receptividades
As receptividades son condicins lxicas booleanas asociadas s transicins que aparecen
representadas de maneira textual ou simblica dereita das transicins (Figura 3.4). O
resultado da avaliacin da condicin determinar se unha transicin validada pode ou non ser
franqueada e, en consecuencia, se a situacin do modelo pode evoluir (3.3.1). Nas
receptividades poden utilizarse varibeis internas, externas e eventos relacionados mediante os
operadores booleanos AND, OR e NOT. As varibeis internas son as que representan os
valores de activacin das etapas e almacenan clculos internos. As varibeis externas son as
que representan os valores das varibeis do proceso controlado, os sinais de mando
proporcionados polo operador, o estado dos temporizadores e contadores, etc. En xeral, e dende
un punto de vista puramente formal, pode considerarse como varibel externa calquera sinal
que tea un caracter asncrono en relacin evolucin do Grafcet, e como interna a modificada
de forma sncrona coa evolucin do modelo. Os eventos, representados mediante os operadores
T e.^, indican a ocorrencia dun cambio no valor dunha varibel ou condicin lxica e
clasificanse en externos e internos segundo afecten a varibeis externas ou internas
.
respectivamente.
(22) + a (b + c)
Figura 3.4. Representacin grfica dunha transicin con receptividade asociada.
3.2.1.5. Accins
As accins estn asociadas s etapas e describen a forma en que son modificadas as
varibeis de sada do modelo cando as etapas estn activas. Represntanse graficamente (Figura
3.5) como unha descricin textual ou simblica no interior dun rectngulo unido mediante unha
lia etapa. Cada accin est asociada a unha nica etapa, mais unha mesma etapa pode ter
asociadas calquera nmero de accins. Cando isto acontece nense os rectngulos das accins
en horizontal ou vertical (Figura 3.6), sen que esta representacin implique ningunha relacin
de orde ou prioridade entre elas. As etapas sen accins asociadas utilzanse normalmente para
modelar estados de espera ou sincronizacin. Cada accin est composta por tres seccins [84]:
1. Unha seccin opcional na que se indica o tipo de accin. Este tipo determina a relacin
temporal entre o estado de activacin da etapa e os valores das sadas modificados pola
accin (3.3.3). O tipo indicase mediante unha ou varias das letras da Tboa 3-I.
2. Unha seccin que contn a descricin da accin. O formato concreto desta seccin non
especificado nas normas, de xeito que poida utilizarse calquera formalismo que se
considere axeitado: cronogramas, organigramas, funcins de transferencia, ecuacins de
estado, etc. A norma IEC 61131-3 un exemplo de proposta dunha sintaxe para a
especificacin dos contidos desta seccin.
3. Unha seccin opcional que contn o identificador da varibel que ser utilizada para
indicar a finalizacin da accin.
59
Continua
Memorizada
Demorada
R, S
D
L
P
Limitada
Impulsional
Condicional
Tboa 3-I. Tipos de accins.

1
12
(12^
Figura 3.5. Representacin grfica dunha accin cloas tres seccins definidas polo estndar: (a) tipo; (b) descricin;
e (c) identificacin.
accin 1
12
accin 2 I
(12)
accin 3
(a)
12
(12)
accin 1
accin 1
accin 1
+
(b)
Figura 3.6. Representacin grfica de varias accins asociadas mesma etapa: (a) en vertical; e(b) en horizontal.
3.2.2. Extensins sintcticas

Para facilitar a estructuracin dos modelos de sistemas complexos propuxronse varias
extensins sintcticas proposta inicial recollidas en [165]. Estas propostas permiten a
aplicacin de estratexias de deseo tipo `divide e vencers', consistente na divisin dun
problema complexo en mltiples subproblemas mais sinxelos; ou "top-down", consistente en
concentrarse nos aspectos relevantes a un nivel de abstraccin deixando os detalles superfluos
para a sa consideracin posterior. As extensins sintcticas explicadas nesta seccin son as
seguintes: etapas fonte e sumidoiro (3.2.2.1), macroetapas (3.2.2.2), particins (3.2.2.3) e
ordes de forzado (3.2.2.4).
3.2.2.1. Etapas fonte e sumidoiro
Unha etapa fonte (Figura 3.7.a) unha etapa que unicamente ten transicins conectadas
sucedndoa na secuencia de control. As etapas fonte s poden activarse pola aplicacin da
regra 1 de evolucin (3.3.1.1), se son etapas iniciais, ou ben ser forzadas dende un grafcet
parcial de nivel xerrquico superior (3.2.2.4). Da mesma maneira, unha etapa sumidoiro
(Figura 3.7.b) unha etapa que unicamente ten transicins conectadas precedndoa na
secuencia de control. Estas etapas s son desactivadas en caso de que a situacin do grafcet ao
que pertencen sexa forzada.
De xeito semellante son definidas as transicins fonte e sumidoiro (Figura 3.8), cunha
pequena diferencia: unha etapa pode ser ao mesmo tempo fonte e sumidoiro mais non unha
transicin, xa que isto non tera sentido dende un punto de vista lxico. As transicins sen
60
conexins a etapas non afectan evolucin da secuencia de control. A nica consecuencia da

sa utilizacin sera a introduccin dunha sobrecarga durante a interpretacin do modelo, pois
considrase que as transicins fonte estn sempre validadas e, en consecuencia, a sa
receptividade ser avaliada en cada ciclo do algoritmo de interpretacin utilizado (3.3.2.2).
,2
12
(b)
(a)
Figura 3.7. Representacin grfica de etapas: (a) fonte; e(b) sumidoiro.

(22) ^^ (23) ^n
(b)
(a)
Figura 3.8. Representacin grfica de transicins: (a) fonte; e(b) sumidoiro.
3.2.2.2. Macroetapas
As macroetapas (Figura 3.9) son representacins simplificadas dun conxunto de.etapas e
transicins, denominado expansin da macroetapa, que cumpre as seguintes regras sintcticas:
l. Hai unha nica etapa de entrada e unha nica etapa de sada, que se corresponden cos
puntos de conexin da macroetapa no modelo.
2. O conxunto de etapas e transicins forman un grafo conexo (3.2.2.3).
3. A cada macroetapa correspndelle unha nica expansin.
A utilizacin de macroetapas permite introducir diferentes niveis de detalle nos modelos e
facilita a reutilizacin. As macroetapas ocultan os detalles superfluos nun nivel de descricin
dado do modelo, que son especificados nun nivel inferior de detalle no interior das expansins.
As macroetapas poden aniarse ( posbel utilizar novas macroetapas nas expansins doutras
macroetapas) polo que posbel utilizar no modelo tantos niveis de detalle como se precisen.
i
,1
(11>
M10
1z
^^
13
(-^
(13)
14
(a)
(b)
Figura 3.9. Representacin grfica dunha: (a) macroetapa; e(b) a sa expansin.
Durante a interpretacin do modelo unha macroetapa estar activa cando o estea algunha das
etapas da sa expansin. A utilizacin de macroetapas introduce distintos niveis de detalle na
descricin do modelo, mais non na xerarqua de forzado (3.2.2.4), do que se deduce que:
1. Dende un grafcet que contea macroetapas non poden forzarse as etapas das sas
expansins.
61
2. O contrario tampouco posbel, dicir, dende a expansin dunha macroetapa non pode
forzarse a situacin do grafcet que contn a macroetapa.
3. Da mesma maneira tampouco poder forzarse dende a expansin dunha macroetapa a
situacin dun grafcet de nivel xerrquico superior ao que contn a macroetapa.
3.2.2.3. Particins
En [165] definense as seguintes particins dun modelo Grafcet:
1. Un grafcet conexo aquel no que todo nodo est conectado directa ou indirectamente aos
demais. Os grafcets conexos modelan secuencias simples que poden combinarse para
formar estructuras complexas de nivel superior.
2. Un grafcet parcial un conxunto de grafcets conexos. Os grafcets parciais modelan os
subsistemas que forman un sistema complexo.
3. Un grafcet global un conxunto de grafcets parciais. O grafcet global correspndese co
modelo do sistema de interese.
As particins definidas permiten estructurar o modelo do sistema formando unha xerarquia
estructural (Figura 3.10), na que un grafcet global est formado por un ou varios grafcets
parciais e estes, sa vez, por un ou varios grafcets conexos que poden conter tantos niveis de
detalle como se desexe mediante o uso de macroetapas (3.2.2.2).
Grafcets Parciais
Grafcet Global
Grafcets Conexos
Figura 3.10. Xerarqua estructural do Grafcet.
3.2.2.4. Ordes de forzado

A definicin dunha xerarqua estructural (3.2.2.3) non suficiente para modelar as
relacins existentes entre as distintas compoentes dun sistema. preciso dispor ademais de
mecanismos que permitan especificar relacins mis complexas. As ordes de forzado [103]
foron includas como parte da definicin do Grafcet para modelar as relacins que se establecen
nun sistema cando o estado dalgn dos seus subsistemas controlado por outros. Desde o punto
62
de vista da estructuracin lxica do sistema, os subsistemas dependentes son considerados

como pertencentes a un nivel inferior ao dos subsistemas dos que dependen.
As ordes de forzado considranse como ordes internas que, ao igual que as accins, estn
asociadas s etapas. Estas ordes son utilizadas para forzar dende un grafcet parcial a situacin
doutro, que se manter na situacin forzada mentres a etapa que a orde de forzado estea
asociada siga activa. Exemplos de utilizacin das ordes de forzado son a activacir^ de
secuencias para a deteccin de faios e a xestin de situacins de emerxencia, a especificacin
dos estados de operacin dun sistema, etc.
A representacin grfica das ordes de forzado semellante das accins (Figura 3.5)
excepto pola sintaxe utilizada para especificalas, que a seguinte:
F/G : {situacin}
sendo:
F/ o indicador utilizado para identificar unha orde de forzado.
G^ o identificador do grafcet parcial forzado.
{situacin} a situacin que se quere forzar.
A utilizacin de ordes de forzado no modelado dun sistema establece relacins de

dependencia entre os grafcets parciais forzados e os `forzadores' que en conxunto forman unha
xerarqua de forzado (Figura 3.11). Os grafcets parciais forzados estn situados nesta xerarqua
en niveis inferiores aos dos seus `forzadores'.
i
11
^-{ F! G2 : {22}
12
l
21
F/ G3 : {34}
22
F/G4: {42,43}
31
41
23
(31)
32
33
(41)
^
42
43
^
(43)
(33)
34
44
(44)
(34)
J
Figura 3.11. Exemplo dunha xerarqua de forzado.
63
Para manter a coherencia dun modelo estructurado desta maneira e garantir o determinismo
da sa interpretacin, a xerarqua de forzado ten que cumprir as regras seguintes:
1. A xerarqua ten que ser total, dicir, se un grafcet parcial forza directa ou indirectamente a
outro, o contrario non pode acontecer. Esta regra garante que a xerarqua de forzado non
contea ciclos e que os grafcets parciais `forzadores' estean situados en niveisasuperiores
aos forzados. En [103] proponse un mtodo baseado na teora de grafos para comprobar a
coherencia dunha xerarqua de forzado (6.5.1.3).
2. Durante a interpretacin do modelo e para todo instante de funcionamento cada grafcet
parcial forzado ter un nico `forzador'. Esta regra evita os conflictos entre ordes de
forzado durante a interpretacin do modelo.
Estas regras compltanse coa modificacin do algoritmo de interpretacin para ter en conta a
aplicacin das ordes de forzado (3.3.2.5) respectando a xerarqua de forzado e garantindo 0
determinismo e a coherencia da interpretacin.
3.2.3. Estructuras de control bsicas

Nesta seccin recllense algunhas das estructuras de control mis comns nos modelos
Grafcet e como son representadas graficamente.
3.2.3.1. Secuencia
Unha secuencia est formada por un conxunto de etapas e transicins conectadas de maneira
que a continuacin de cada etapa s pode haber unha nica transicin e a continuacin de cada
transicin unha nica etapa (Figura 3.12).
3.2.3.2. Seleccin de secuencia
A seleccin de secuencia, indicada graficamente mediante unha lia horizontal (Figura
3.13), unha estructura que permite especificar unha alternativa entre varias posbeis
secuencias, que estarn conectadas a continuacin dunha ou mis etapas por medi de tantas
transicins como alternativas haxa. Para evitar situacins non desexadas de paralelismo
interpretado (3.2.3.10) -activacin de mis dunha secuencia despois dunha seleccin
durante a interpretacin do modelo debe garantirse que as condicins asociadas s transicins
da seleccin son exclusivas entre si.
3.2.3.3. Fin de seleccin de secuencia
O fin de seleccin de secuencia (Figura 3.14) representa o punto de unin sen sincronizacin
de varias secuencias de control. Cada secuencia finaliza cunha transicin e, se se garantiu a
exclusividade no inicio da seleccin, s unha das secuencias que converxen estar activa
durante a interpretacin do modelo.
3.2.3.4. Paralelismo
O paralelismo, indicado graficamente mediante unha dobre lia horizontal (Figura 3.15),
unha estructura que representa a activacin simultnea de varias secuencias concorrentes
introducindo nos modelos o concepto de paralelismo estructural (3.2.3.10). Neste caso haber
unha nica transicin entre as secuencias a activar e a etapa ou etapas que as anteceden.
64
H accin 1
^-{ accin 2
H accin 3
(1)
(2)
(3)
Figura 3.12. Representacin grfica dunha secuencia.

accin 1
a.b
(1)
2
(2)
a.F
accin 2
accin 3
accin 4
Figura 3.13. Representacin grfica dunha seleccin de secuencia.
accin 1
accin 2
2
(2
(1)^-a
accin 3
(3)
accin 4
Figura 3.14. Representacin grfica do final dunha seleccin de secuencia.
accin 1
(1)
L
2
accin 2
a.b
accin 3
accin 4
Figura 3.15. Representacin grfica do comezo de varias secuencias paralelas.
3.2.3.5. Fin de paralelismo (sincronizacin)

O fin de paralelismo unha estructura complementaria coa anterior que permite representar
un punto de sincronizacin entre varias secuencias concorrentes, que estarn conectadas
mediante unha nica transicin etapa ou etapas que as suceden (Figura 3.16). Durante a
interpretacin do modelo, e dacordo segunda regra de evolucin (3.3.1.2), esta transicin s
estar validada cando todas as etapas que a preceden estean activas (Figura 3.17).
3.2.3.6. Salto de etapas
O salto de etapas permite avanzar a situacin dunha secuencia `saltando' algunha das etapas
que a forman. Esta estructura pode considerarse como un caso particular da seleccin de
secuencia (3.2.3.2) na que s hai das posbeis escollas excluntes entre si: ou ben continuar a
secuencia ou ben avanzar ata unha etapa posterior. O salto de etapas representase graficamente
mediante unha transicin que une as etapas de inicio e destino do `salto' (Figura 3.18.a).
65
accin 1
accin 2
(1) -^- a.b
accin 3
accin 4
Figura 3.16. Representacin grfica do final de varias secuencias paralelas.

1
accin 1
accin 2
(1)-}- a.b
accin 3
accin 4
(a)
accin 1
accin 3
accin 2
(1)-.^- a.b
4
accin 4
(b)
Figura 3.17. Exemplo de sincronizacin: (a) a transicin 1 non est validada; (b) a transicin 1 si est validada.
3.2.3.7. Ciclo
Un ciclo o equivalente a un salto a un punto anterior na secuencia. Represntase

graficamente coma un salto, indicando o sentido cunha frecha no arco orientado (Figura
3.18.b).
1
a (2)
H accin 1
H accin 1
H accin 2
^^)
H accin 2
(3)
(2)
H accin 3
H accin 4
(5)^
(a)
(3)
3 H accin 3
H accin 4
(5)...L..
(Ib)
Figura 3.18. Representacin grfica de: a) salto de etapas; e b) un ciclo.
3.2.3.8. Semforo
O semforo permite representar a exclusin mutua no acceso a un recurso compartido desde
varias secuencias. Exemplos destes recursos son os postos de almacenaxe de pezas, os carros de
66
transporte automatizados, etc. O semforo garante o acceso exclusivo ao recurso compartido a

unha soa das secuencias. Nos modelos os semforos son representados mediante etapas iniciais
situadas en paralelo coa finalizacin das secuencias que acceden ao recurso compartido e
sincronizadas co seu comezo (Figura 3.19).
11
1
^
(1)
m -I
f1
12
2
30
19
10
20
Figura 3.19. Representacin grfica dun semforo -etapa 30- que proporciona un mecanismo de exclusin
mutua entre das secuencias.
O funcionamento do semforo durante a interpretacin do modelo o seguinte: inicialmente

a etapa que modela o semforo -etapa 30- estar activa, cando as secuencias que acceden ao
recurso vaian comezar simultaneamente ^tapas 1 e 11 activas-, as transicins que lles dan
comezo -transicins 1 e 11- estarn validadas, entn a primeira das receptividades asociadas
a estas transicins -condicins f^ e f2- que sexa certa determinar qu secuencia accede ao
recurso compartido. Cando isto acontece (supoamos que fi a receptividade franqueada) a
etapa inicial da secuencia -etapa 2- actvase e desactvanse as etapas 1 e 30 (o semforo), co
que a transicin 11 deixa de estar validada impedindo que outra secuencia poida acceder
simultaneamente ao recurso compartido. Unha vez remate o acceso ao recurso actvanse as
etapas 10 e 30 e a transicin 11 volve estar validada, e a segunda secuencia xa pode acceder ao
recurso cando a receptividade f2 sexa certa. importante destacar que para que o semforo
funcione correctamente preciso que as receptividades f^ e f2 sexan exclusivas. A estructura
dun semforo pode ampliarse a calquera nmero de secuencias, como mostra a Figura 3.20.
91
11
f2
2
f9
(91)
12
92
19
99
200
(99)
(19)
10
^^
20
100
Figura 3.20. Representacin grfica dun semforo ^tapa 200- que proporciona un mecanismo de exclusin
mutua entre varias secuencias.
67
Unha caracterstica do semforo que a orde de activacin das secuencias ou o nmero de

veces que se activa cada unha non significativo. Cando preciso establecer unha orde de
activacin pode utilizarse unha variante como a da Figura 3.21. Neste caso as secuencias
acceden a un recurso compartido executando operacins que deben realizarse de maneira
alterna. Na Figura 3.22 mstrase un exemplo no que se modela a sincronizacin das operacins
realizadas por das mquinas, unha de produccin de pezas e outra de ensamblaxe,
comunicadas mediante un posto de almacenaxe no que s pode haber unha peza. O depsito e a
retirada dunha peza no posto de almacenaxe son operacins exclusivas que se realizan
alternativamente comezando pola de depsito da peza.
30
10
11
^T
f2
12
19
Figura 3.21. Representacin grfica dunha estructura que proporciona un mecanismo de alternancia entre das
secuencias de accins.
^
10
comezar fabricacibn
(10)
11
Fabricar
20
^(20^comezar ensamblaxe
(11^peza preparad^
21
S
=1
(21)
13
Depositar
(13^peza depositada
22
Coller
(22).+ peza collida

1
23 H Ensamblar
(23^fin ensamblaxe
Figura 3.22. Exemplo de alternancia das secuencias de fabricacin e ensamblaxe, coordinadas mediante as
operacins de depsito e recollida de pezas.
3.2.3.9. Acumulacin e reserva

A acumulacin (Figura 3.23.a) utilizase para representar a sincronizacin de mltiples
activacins, coincidentes ou non no tempo, dunha mesma secuencia. A reserva ou xeracin
(Figura 3.23.b) utilizase para representar mltiples activacins simultneas dunha mesma
secuencia.
68
O funcionamento da acumulacin durante a interpretacin do modelo o seguinte: a

transicin 3 s estar validada cando as etapas 1, 2, e 3 estean activas, a primeira vez que se
active a secuencia as receptividades das transicins 1 e 2 son certas, polo que se activar a
etapa 3. A segunda vez a transicin 2 ser falsa e a secuencia rematar activando a etapa 2, e a
terceira vez a transicin 1 ser falsa e a secuencia rematar activando a etapa 1. Nese intre a
transicin 3 estar validada e cando a sa receptividade sexa certa desactivaranse as etapas "1, 2
e 3 e continuarase coa interpretacin do modelo.
(6)
(^)
(2)
RS
(8)
3
(9)
(a)
(b)
Figura 3.23. Representacin grfica dunha estructura que realiza: a) unha acumulacin; e b) unha reserva.
No referente reserva, cando a transicin 6 franqueada actvanse simultaneamente as

etapas 6, 7 e 8, e valdanse as transicins 7, 8 e 9. Nesta situacin as receptividades das
transicins 7 e 8 sern falsas, e cando a receptividade da transicin 9 pase a ser certa
desactivarase a etapa 8, a receptividade da transicin 8 pasar a ser certa co que se activar de
novo a etapa 8 e desactivarase a 7. Isto sa vez provoca que a receptividade da transicin 7
pase a ser certa e sexa reactivada a etapa 7 e desactivada a 6. Na nova situacin estarn activas
as etapas 7 e a 8, validadas as transicins 8 e 9 e ser falsa a receptividade da transicin 8.
Cando a receptividade da transicin 9 volva ser certa repetirase o proceso anterior. Esta
estructura garante que a secuencia posterior transicin 9 ser activada tres veces.
3.2.3.10. Paralelismo interpretado e paralelismo estructural
Como se indicou en (3.2.3.4) a estructura de paralelismo permite representar
explicitamente nos modelos Grafcet a activacin simultnea de das ou mais secuencias
concorrentes. Esta representacin explcita denominada paralelismo estructural, en
contraposicin ao paralelismo interpretado, que consiste na representacin nos modelos de
estructuras que activan simultaneamente varias secuencias concorrentes sen indicalo co
smbolo grfico utilizado para representar o paralelismo estructural (Figura 3.15). Se isto se fai
inadvertidamente pode dar lugar durante a interpretacin do modelo a comportamentos
imprevistos polo que, na medida do posbel, debe evitarse esta situacin.
As estructuras que inician unha situacin de paralelismo interpretado denomnanse
conflictos, e caracterzanse por estar formadas por das ou mais transicins con receptividades
que non son mutuamente exclusivas e cuxa activacin depende de etapas comns. O exemplo
mais simple de conflicto unha seleccin de secuencia (Figura 3.13) na que as receptividades
das transicins implicadas non son mutuamente exclusivas. A eliminacin de conflictos debe
ter en conta a semntica que pretenda modelarse, de xeito que se o que se pretende non
69
Seccin 3.3: A semntica do Grafcet
permitir a activacin simultnea de varias secuencias entn debern modificarse as

receptividades para facelas mutuamente exclusivas. Polo contrario, se o que se pretende
permitir a activacin simultnea de varias secuencias entn deber modificarse a estructura
para representar explicitamente o paralelismo estructural.
3.3. A semntica do Grafcet ^

Na proposta inicial do Grafcet [lJ ademais de definirse os elementos sintcticos e as regras
que permiten combinalos para construr modelos sintacticamente correctos, definronse tamn
as regras para a interpretacin semntica dos modelos denominadas regras internas de
evolucin, que permiten calcular as evolucins dun modelo dado, determinndose a situacin
seguinte do modelo a partires da sa situacin actual e dos valores das varibeis de entrada.
Nesta seccin presntanse estas regras, explcanse as diferentes interpretacins semnticas s
que poden dar lugar e descrbese o comportamento temporal dos distintos tipos de accins
utilizados nos modelos.
3.3.1. As regras de evolucin

A situacin inicial dun modelo establcese aplicando a seguinte regra:
3.3.1.1. Regra 1: Situacin inicial
Inicialmente activaranse unicamente as etapas iniciais do grafcet, permanecendo as demais
etapas inactivas ata que se produza unha evolucin na situacin do modelo (Figura 3.24).
11
14
Figura 3.24. Exemplo de activacin inicial dun Grafcet.
A evolucin do modelo dunha situacin seguinte realizase mediante o franqueamento de

transicins dacordo s regras seguintes:
3.3.1.2. Regra 2: Determinacin das transicins franquebeis
Unha transicin ser franquebel cando se cumpran as das condicins seguintes (Figura
3.25):
1. Todas as etapas que anteceden transicin estn activas. Neste caso dirase que a transicin
est validada.
2. A receptividade asociada transicin certa.
De cumprirse ambas as das condicins a transicin deber ser franqueada, o que producir
unha evolucin na situacin do modelo.
70
a.b = 0
a.b = 1
(1
)
a .b
(1 )
a
.b
(1
.b
^L
2
I
(a)
(b)
(c)
Figura 3.25. Estados dunha transicin: (a) transicin non validada; (b) transicin validada, e(c) transicin validada
e franquebel.
3.3.1.3. Regra 3: Franqueamento dunha transicin

O franqueamento dunha transicin consiste na desactivacin das etapas que a anteceden e a
activacin das etapas que a suceden (Figura 3.26). A desactivacin e activacin destas etapas
simultnea.
a.b = 1
(1 )
a.b
(1â.b
2
(a)
(b)
Figura 3.26. Franqueamento da transicin 1: (a) situacin anterior; e(b) situacin posterior.
Debido a que o Grafcet aplicase ao modelado de sistemas fisicos complexos, as evolucins

do modelo implican normalmente o franqueamento simultneo de mltiples transicins. Para
garantir o sincronismo das evolucins definiuse a regra seguinte:
3.3.1.4. Regra 4: Evolucins simultneas
Se durante unha evolucin do modelo hai varias transicins franquebeis, todas elas sern
franqueadas simultaneamente (Figura 3.27).
2
b _ ^
(1)
a.b
^)
(2
a
5
(2)
a.b
(1)
(a)
(b)
Figura 3.27. Franqueamento simultneo das transicins 1 e 2: (a) situacin anterior; e(b) situacin posterior.
Por ltimo definiuse unha regra que se aplica cando unha etapa activada e desactivada
simultaneamente durante unha evolucin do modelo:
3.3.1.5. Regra 5: Activacin e desactivacin simultnea dunha etapa
Se durante unha evolucin do modelo, unha etapa activada e desactivada simultaneamente,
permanecer activa na nova situacin.
71
a=1
b=0
(1)-â.b
(^)â.b
3
(a)
(b)
Figura 3.28. Activacin e desactivacin simultnea da etapa 2: (a) situacin anterior; e(b) situacin posterior.
3.3.2. Semntica temporal do modelo

A prctica posterior definicin das regras de evolucin do Grafcet demostrou que non
abondaba co definido para permitir a implementacin prctica dos modelos sen ambigiiidades
na interpretacin. Para resolver este problema presentouse unha segunda proposta [2] que
complementaba primeira definindo por unha banda os postulados temporais que aclaran a
relacin entre as evolucins internas do modelo e o contexto temporal dictado polo seu
contorno e, por outra, as diferentes interpretacins dos modelos que poden derivarse da
aplicacin das regras de evolucin.
3.3.2.1. Postulados temporais
Os postulados que especifican a relacin temporal entre as evolucins internas dun modelo
-dacordo s regras de evolucin explicadas en (3.3.1^ e o seu contorno son os seguintes:
Postulado 1
A duracin do franqueamento dunha transicin (e, en consecuencia, o de activacin dunha
etapa) pode ser, dende un punto de vista terico, tan pequeno como se desexe, mais non
pode ser nulo. Na prctica este tempo depender da tecnoloxa empregada na
implementacin fisica do sistema.
Este postulado ten consecuencias directas na interpretacin das regras de evolucin
relacionadas co franqueament simultneo de transicins. Debido a que o postulado establece
que a duracin do franqueamento dunha transicin non pode ser nulo, cando unha etapa se
activa as transicins que a suceden non sern franqueadas inmediatamente -en aplicacin da
regra 4(3.3.1.4}- anda que as sas receptividades sexan certas. O motivo que ao non ser
nulo o tempo de franqueamento das transicins previas etapa, a activacin da etapa non
instantnea e, polo tanto, as transicins que a suceden non estaran validadas. O franqueamento
desas transicins farase nunha evolucin posterior do modelo se as sas receptividades
seguiran sendo certas. Outra consecuencia directa deste postulado que as accins asociadas s
etapas activas son consideradas durante un tempo teoricamente tan pequeno como se desexe
mais non nulo.
Postulado 2
Os modelos Grafcet basanse na hiptese da existencia dun contorno asncrono coa
restriccin de que calquera dous eventos externos non relacionados non poden acontecer
simultaneamente.
Unha consecuencia directa deste segundo postulado o establecemento dun lmite superior
para a duracin dunha evolucin interna do modelo. Este lmite ven dado pola separacin
mnima entre dous eventos externos calquera non relacionados. Teoricamente, se todas as
72
evolucins internas do modelo poden facerse nun tempo inferior a este lmite grntese a
reactividade (capacidade de resposta ante todos os eventos externos que se produzan) do
modelo.
3.3.2.2. Algoritmos de interpretacin do Grafcet
Ademais dos postulados temporais, na revisin da definicin do Grafcet propuxronse dous
posbeis algoritmos de interpretacin distintos que utilizan as regras de evolucin do modelo
(3.3.1): sen busca da estabilidade (SRS) e con busca da estabilidade (ARS). Estes algoritmos
proporcionan unha referencia terica que pode servir de gua na implementacin dun intrprete
Grafcet considerando as restriccins dunha tecnoloxa especfica. A utilizacin dun ou doutro
algoritmo depender dos requirimentos de reactividade e determinismo (a toda secuencia de
variacin das entradas lle corresponde unha nica secuencia de variacins das sadas) do
sistema, e das restriccins da tecnoloxa utilizada.
As para unha aplicacin especfica, se fose posbel garantir que o tempo preciso para pasar
dunha situacin estbel (situacin dende a que s posbel evoluir debido a ocorrencia dun
evento externo) seguinte sempre inferior ao intervalo mnimo entre dous eventos externos
non relacionados, entn o algoritmo SRS garante os requisitos de determinismo e
reactividade23. Sen embargo na prctica non posbel garantir esa condicin, e o algoritmo
SRS pode resultar nunha interpretacin non determinista do modelo dependendo da relacin
existente entre o tempo preciso para realizar unha evolucin interna do modelo e o intervalo
mnimo entre dous eventos externos non relacionados. Como pode verse no exemplo da Figura
3.29, se se considera a situacin inicial { 1} como situacin de partida, o franqueamento da
transicin 1 producirase coa ocorrencia do evento Ta e a evolucin do modelo depender de se
o evento â ocorre antes ou despois da activacin da etapa 2. A demostracin a seguinte: sexa
ta = t(â) - t(Ta) o tempo transcorrido entre ambos eventos e tr o tempo consumido no
franqueamento da transicin 1; entn se tf < ta a situacin seguinte ser {3}, pois o valor da
varibel a ser 1 cando se avalen as condicins asociadas s transicins 2 e 3, polo contrario,
se tf> taa situacin final ser {4}, pois nese caso o valor da varibel a ser 0.
O segundo dos algoritmos propostos, o algoritmo ARS, resolve en parte este problema. Este
algoritmo garante o determinismo da interpretacin do modelo independentemente do tempo de
franqueamento das transicins, mais co custe de degradar a reactividade. A solucin aportada
por este algoritmo consiste en ter en conta os eventos externos s cando o modelo est nunha
situacin estbel, o que implica que os eventos que se produzan durante a evolucin interna do
modelo (mentres pasa dunha situacin estbel seguinte) perderanse a menos que se
proporcione algn mecanismo externo ao modelo para o seu almacenamento. O algoritmo ARS
presenta un segundo problema, o grafo de situacins do modelo (grafo dirixido no que os
estados representan as situacins do modelo e os arcos as evolucins) pode inclur ciclos
estacionarios (evolucins compostas unicamente por situacins inestbeis). Nese caso a
interpretacin do modelo nunca alcanzara unha situacin estbel e o sistema quedara
bloqueado nunha busca sen fin dentro do ciclo.
3.3.2.3. Semiformalizacin da semntica do Grafcet: o xogador Grafcet
En traballos posteriores [25][106] definicin dos postulados temporais e algoritmos de
interpretacin, propxose unha semiformalizacin dun intrprete de modelos Grafcet xenrico,
23 Ntese que esta condicin, xunto co postulado 2 comentado anteriormente, correspndense co modelo de
funcionamento no modo fundamental dos sistemas secuenciais asncronos.
73
denominado xogador Grafcet, independente da implementacin prctica utilizada. Este

xogador constite unha gua de lectura ou interpretacin da dinmica dos modelos que indica
explicitamente e sen ambigiiidades como deben integrarse conxuntamente as regras de
evolucin (3.3.1), a lectura das entradas e escritura das sadas, os postulados temporais da
relacin do modelo co seu contorno (3.3.2.1) e os algoritmos de interpretacin (3.3.2.2).
1
2
(2)
(3)
tr < ta / \ tt > ta
1
(1)^?a
(2)
a
^
(3)
(2)
(3)
Figura 3.29. Demostracin do non determinismo do algoritmo SRS.
O xogador mais elemental (Figura 3.30) basease nunha interpretacin SRS dos modelos.
Este xogador ten unha fase de iniciacin na que" se aplica a regra 1(3.3.1.1) para establecer a
situacin inicial do modelo, lense os valores iniciais das varibeis de entrada e calclanse os
valores iniciais das varibeis de sada. Despois da fase inicial, o xogador entra nun ciclo no que
se repiten as seguintes actividades:
1. Lectura dos valores das varibeis de entrada.
2. Clculo das transicins franquebeis âcordo ao definido pola regra 2(3.3.1.2^.
3. Evolucin da situacin franqueando as transicins franquebeis -dacordo ao definido
polas regras 3 e 4(3.3.1.3;3.3.1.4)---, aplicando cando sexa preciso a regra 5(3.3.1.5)
para a resolucin dos conflictos de activacin e desactivacin simultnea de etapas.
4. Clculo dos valores das varibeis de sada segundo o especificado polas accins asociadas
s etapas activas na nova situacin do modelo.
Reara 1: Activar etapas iniciais
i
i
Ler variabeis de entrada N
0 < Atr < T^ < min(Ode)
ReQra 2: Determinar as transicibns franqueabeis
T
t
Rearas 3. 4& 5: Evolucibn da situacin
Escreber variabeis de saida ^

Figura 3.30. Xogador SRS de modelos Grafcet.
74
A consideracin dos postulados temporais (3.3.2.1) define ademais os lmites temporais

tericos que delimitan o tempo de ciclo do xogador (T^) para garantir o determinismo e a
reactividade da interpretacin en calquera implementacin. O lmite inferior ser igual ao
tempo preciso para o franqueamento das transicins: Otf > 0( postulado 1), e o superior ao
tempo mnimo entre dous eventos externos non relacionados: min(Ode) > 0(postulado 2). Da
consideracin conxunta dambos postulados obtense a seguinte desigualdade:
0 < Otf< T^ < min(0^)
(3.1)
A adaptacin do xogador a unha interpretacin ARS require a modificacin do ciclo de

actividades para representar o feito de que a lectura das entradas e a escritura das sadas faise s
cando o modelo est nunha situacin estbel. Deber tamn engadirse unha nova actividade
encargada da deteccin dos ciclos estacionarios que poida haber no grafo de situacins do
modelo, para evitar que o xogador quede bloqueado nunha evolucin sen fin. O ciclo de
actividades modificado ser o seguinte:
l. Lectura dos valores das varibeis de entrada.

2. Clculo das transicins franquebeis -dacordo ao definido pola regra 2(3.3.1.2^.
3. Se hai algunha transicin franquebel, ir ao paso 6.
4. Clculo dos valores das varibeis de sada segundo o especificado polas accins asociadas
s etapas activas na nova situacin do modelo.
5. Volver ao paso 1.
6. Evolucin da situacin franqueando as transicins franquebeis -dacordo ao definido
polas regras 3 e 4(3.3.1.3;3.3.1.4}-, aplicando cando sexa preciso a regra 5(3.3.1.5)
para a resolucin dos conflictos de activacin e desactivacin simultnea de etapas.
7. Se a nova situacin non coincide con ningunha das xa visitadas neste ciclo de busca dunha
situacin estbel, ir ao paso 2.
8. Indicar deteccin dun ciclo estacionario no grafo de situacins do modelo.
Como pode comprobarse, no xogador ARS existen realmente dous ciclos entrelazados. No
primeiro deles, formado pola secuencia 2, 6, 7 e 8, realzase a evolucin do modelo dende unha
situacin estbel seguinte e detctanse os ciclos estacionarios. Dentro deste ciclo non se len
novos valores de entrada nin se obteen novos valores de sada. A deteccin de ciclos
estacionarios realzase comparando a situacin actual do modelo coas situacins polas que xa
se pasou durante o actual proceso de busca dunha situacin estbel, se coincide con algunha
entri a busca entrou nun ciclo estacionario. No segundo dos ciclos, formado pola secuencia 1,
2, 3, 4 e 5, comzase nunha situacin estbel do modelo, lense os valores das varibeis de
entrada, faise evoluir o modelo ata atopar unha nova situacin estbel e calclanse os valores
das sadas.
A consideracin dos postulados temporais no xogador ARS modifica lixeiramente os lmites
do seu tempo de ciclo. Debido a existencia de dous ciclos, o tempo de ciclo total T^ calculado
agora como
(3 2)
T^ = Tci + Tce
sendo:
T^;, o tempo mximo que o ciclo interno precisa para calcular unha nova situacin estbel.
TCei o tempo mximo que o ciclo externo precisa para ler as entradas, calcular a nova
situacin do modelo e calcular as sadas.
75

Reara 1: Activar etapas iniciais
i
i
,N Re9ra 2: Determinar as transicins franqueabeis
Ler variabeis de entrada
0< dti < Ti^ < min(dde)/n
Hai transicins que franquear?
Non
Si
Rearas 3. 4& 5: Evolucin da situacin
Non
0 < dt^ < nTa < min(dde)
Situacin estable
Escreber variabeis de saida
O modelo estivo xa na situacin actual? r/Situacin estacionaria (n=oo

Figura 3.31. Xogador ARS de modelos Grafcet.
Pdese entn reescribir a inecuacin (3.1) que limita o tempo de resposta do xogador como
0< Otr < Toi + TCe < min(Ode)
(3.3)
Tci Tce
(3.4)
T^; = n T;;
(3.5)
e debido a que
e
sendo:
n, o nmero mximo de iteracins que o ciclo interno precisa para atopar unha nova
situacin estbel (o xogador entra nun ciclo inestbel cando n= oo).
T;;, o tempo mximo necesario para realizar unha desas iteracins.
Entn pdese reescribir a inecuacin (3.3) como

0 < Otf < nT;; < min(Ode)
(3.6)
Esta desigualdade representa os lmites tericos do tempo de ciclo definidos polos

postulados temporais para poder garantir nun xogador ARS a reactividade e o determinismo na
interpretacin dos modelos. Desta expresin poden derivarse tamn os lmites tericos de cada
iteracin do ciclo de busca dunha situacin estbel, que sern
0 < Ote < Tii < min(^de)/n
(3.7)
3.3.2.4. Revisin dos postulados temporais baixo a hiptese de sincronismo forte

A proposta da aproximacin sncrona especificacin de sistemas reactivos [21 ] e a
dispoibilidade de linguaxes como Signal [22] ou Esterel [24], motivaron unha revisin dos
postulados temporais do Grafcet e da sa semntica [33][114][149]. As linguaxes sncronas
basanse na hiptese de sincronismo forte que establece que: `dende un punto de vista terico,
un sistema reactivo ideal aquel que produce as sas sadas de maneira sncrona coas sas
entradas, dicir, as sas reaccins son instantneas (causalidade de duracin nula) e
deterministas'. Dito doutra forma, un sistema reactivo ideal traballa ao ritrno que lle impn o
seu contorno e, para garantir as restriccins relacionadas coa seguridade, as sas reaccins
teen que ser deterministas baixo esas condicins de funcionamento.
76
A consideracin desta hiptese ten importantes consecuencias nos postulados temporais do

Grafcet [25][106]. O primeiro postulado non compatbel coa hiptese de sincronismo forte,
pois establece que o tempo de duracin dunha evolucin do modelo pode ser tan pequeno como
se queira mais non nulo. Obviamente isto incompatbel coa hiptese de causalidade de
duracin nula. Ademais as evolucins internas dos modelos Grafcet son sncronas (3.3.1.4), o
cal tampouco compatbel cos principios que fundamentan as linguaxes sncronas [128]:' En
canto ao o segundo postulado, establece os lmites tericos na resposta do xogador de Grafcet
para garantir a reactividade do modelo. Mais, como xa foi explicado, este postulado por si s
non garante ambas as das propiedades de interese nos sistemas reactivos (a reactividade e o
determinismo), pois para garantir a segunda preciso que o xogador poda, en todas as
situacins posbeis, evoluir a unha nova situacin estbel antes da ocorrencia dun novo evento
externo. Como na prctica isto non sempre posbel, propuxronse das posbeis
interpretacins do Grafcet que priman unha das propiedades sobre a outra: a interpretacin SRS
prima a reactividade e a ARS o determinismo.
En consecuencia, o marco temporal do Grafcet podera ser denominado como de
sincronismo feble', pois a reactividade externa do modelo est condicionada pola sa
evolucin interna. Co obxecto de compatibilizar a interpretacin dos modelos Grafcet coa
hiptese de sincronismo forte, propxose un novo marco temporal que establece, dende un
punto de vista terico, a independencia necesaria entre a reactividade externa do modelo e a sa
evolucin interna. Neste novo marco definense das escalas temporais independentes, unha
para a evolucin interna do modelo e outra para a evolucin do sistema fisico controlado
(percibida dende o modelo a travs da variacin dos valores das entradas). A fronteira
conceptual entre o modelo do sistema e o sistema fisico convertese as tamn nunha fronteira
temporal entre a escala de tempo interna e a externa, sen relacin entre elas. A definicin
textual a seguinte [106]: à fronteira de separacin entre o modelo e o sistema fisico constite
tamn unha fronteira temporal entre unha escala de tempo interna e outra externa ao modelo.
Ambas as das escalas non teen unha medida comn.'
Esta separacin entre ambas escalas permite compatibilizar os postulados temporais do
Grafcet coa hiptese de sincronismo forte. Na escala externa a resposta do modelo prodcese
instantaneamente para cada novo evento do sistema, e na escala interna o modelo evoluciona
segundo unha interpretacin ARS, de forma sncrona e coa duracin de cada evolucin
infinitamente pequena mais non nula. Esta aproximacin basease na suposicin de que a
velocidade de evolucin do modelo (velocidade do sistema de control) infinitamente rpida
comparada coa velocidade do sistema controlado, ou dito doutra forma, que os intervalos de
tempo internos son percibidos dende o punto de vista externo como instantneos (Figura 3.32).
Escala externa
j ^/ ^
Entradas
tempo
/ / p _ Saidas externo
tempo
interno
(Estmulo)
(Resposta)
Variacin
Variacin
dunha.
de ,^ das
entrada ^^.^t ^ saidas
Evolucin interna da
situacin do Grafcet
Escala Interna
Figura 3.32. Escalas de tempo interna e externa na interpretacin do Grafcet.
77
Os postulados temporais do Grafcet (3.3.2.1), revisados para ter en conta as das escalas
temporais definidas, quedan agora da maneira seguinte:
Postulado 1
Na escala de tempo externa, todo evento tido en conta polo modelo no instante,xusto da
sa ocorrencia. Os cambios no estado do modelo e nos valores das sadas que provoque
cada evento son percibidos nesta escala como se sucederan instantaneamente.
Postulado 2
Na escala de tempo interna, a duracin dunha evolucin pode ser tan pequena coma se
desexe mais non pode ser nula. En consecuencia o tempo de activacin dunha etapa
tampouco pode ser nulo.
A consideracin conxunta dambos postulados e das das escalas de tempo independentes
definidas garanten as propiedades de reactividade e determinismo que caracterizan aos sistemas
reactivos ideais. En efecto, o primeiro postulado establece que o tempo de resposta do modelo
na escala de tempo externa instantneo, e polo tanto cumpre coa condicin de causalidade
nula imposta pola hiptese de sincronismo forte. Por outra banda o segundo postulado, xunto
coa utilizacin dunha interpretacin ARS dos modelos, garante simultaneamente o sincronismo
da evolucin e o determinismo da resposta.
As modificacins no xogador ARS que esta revisin dos postulados implican poden verse na
Figura 3.33. As ecuacins que describen os lmites temporais dos dous ciclos deste xogador
cambian agora para ter en conta as das escalas de tempo independentes definidas. O tempo de
ciclo interno (o ciclo que calcula a nova situacin estbel despois da ocorrencia dun evento)
estar medido na escala interna e dacordo ao segundo postulado vir dado por:
(3.8)
T^;(int) > 0
No que respecta ao tempo de ciclo externo (o ciclo que calcula o valor das varibeis de sada
na nova situacin_ estbel) medirase na escala de tempo externa e segundo o primeiro postulado
vir dado por:
(3.9)
TCe(ext) = 0
Regra 1: Activar etapas iniciais
*
Ler variabeis de entrada
ReQra 2: Determinar as transicins franqueabeis
Tci (int) > 0
Hai transicins que franqueai?

Si
Non
Tce (ext) = 0
Situacin estable
Rearas 3. 4& 5: Evolucin da situacin

Si
Figura 3.33. Xogador ARS con das escalas de tempo baixo a hiptese de sincronismo forte.
78
3.3.2.5. Consideracin das ordes de forzado no xogador de Grafcet

As ordes de forzado (3.2.2.4) permiten modelar relacins de dependencia entre os grafcets
parciais dun modelo. Estas relacins forman unha xerarqua na que os grafcets forzados estn
situados en niveis inferiores ao dos grafcets `forzadores'. Para a aplicacin da xerarqua de
forzado durante a interpretacin dos modelos precisa a modificacin do xogador Grafcetr, As
ordes de forzado son ordes internas que forzan unha nova situacin do modelo dende o propio
modelo, polo que para evitar que entren en conflicto coas evolucins èstructurais' obtidas
como resultado da aplicacin das regras de evolucin, preciso formalizar a relacin entre
ambas conservando a propiedade de sincronismo na evolucin interna do modelo. Con este
obxectivo definronse as regras seguintes [25]:
Regra de forzado 1
As ordes de forzado son ordes internas posteriores a unha evolucin estructural do
modelo. Cando unha nova situacin, obtida como consecuencia da aplicacin das regras
de evolucin, contn unha ou mais ordes de forzado, os grafcets forzados pasan a estar na
situacin forzada de maneira inmediata e mantense nela mentres que as ordes que os
forzan estean activas.
Regra de forzado 2
A aplicacin das ordes de forzado ten prioridade diante de calquera outra actividade do
modelo (evolucin interna, clculo dos novos valores das sadas, etc.).
A consecuencia directa destas das regras a definicin dunha orde na aplicacin conxunta
das ordes de forzado e as regras de evolucin interna do modelo (3.3.1). As primeiras teen
prioridade sobre as segundas, o cal implica que calquera situacin obtida como consecuencia da
aplicacin das regras de evolucin pode ser modificada antes dunha nova aplicacin das regras,
se algunha das etapas activas nesa situacin tivera asociada unha orde de forzado. Unha nova
aplicacin das regras de evolucin s ser posbel dende a situacin obtida despois de aplicar
todas as ordes de forzado asociadas s etapas activas.
Unha consideracin adicional a ter en conta durante a aplicacin das ordes de forzado a
posibilidade de que se produzan forzados en cascada, que consisten en que algunha das etapas
activadas como consecuencia da aplicacin dunha orde de forzado tea asociadas sa vez
novas ordes de forzado, que tern que ser aplicadas antes de permitir unha nova evolucin
interna do modelo -regra de forzado 2-. Ser preciso, polo tanto, garantir que durante a
aplicacin das ordes de forzado se mantn a coherencia entre a xerarqua de forzado e as
evolucins internas do modelo.
O xogador Grafcet modificado para ter en conta as ordes de forzado pode verse na Figura
3.34. Debido a que son ordes internas, a sa aplicacin realizase no ciclo interno do xogador e
faise na orde definida polos niveis da xerarqua de forzado, aplicando primeiro as ordes
asociadas s etapas activas nos grafcets parciais de nivel superior e baixando na xerarqua ate
que todos os niveis son cubertos. Deste xeito introdcese, despois de cada evolucin
èstructural', unha evolucin asncrona na escala de tempo interna. Sen embargo o ciclo interno
considerado no seu conxunto segue conservando o seu caracter sncrono, pois a propagacin
das ordes de forzado prioritaria sobre calquera outra actividade do modelo, o que implica que
as regras de evolucin s volvern a aplicarse unha vez que esta remate.
Outro aspecto a ter en conta durante a interpretacin do modelo o forzado mltiple dun
mesmo grafcet parcial, que se produce cando das ou mais ordes de forzado forzan
simultaneamente situacins diferentes nun mesmo grafcet parcial. O estndar prohibe
79
explicitamente esta posibilidade, polo que ser preciso engadir no xogador a deteccin desta
condicin durante a propagacin das ordes de forzado.
ReQra 1: Activar etapas iniciais
i
i
Re9ra 2: Determinar as transicins franqueabeis
Ler variabeis de entrada N
Hai transicibns que franquear?
Non
Tc^s (ext) = 0
Situacin estable
Si
Reoras 3. 4& 5: Evolucin da situacin

Tct (int) > 0
Non
Aplicar as ordes de forzado

respectando a orde xerrquica
Forzado mltiple
O modelo estivo xa na situacin actual? ^1 Situacin estacionaria
Figura 3.34. Xogador ARS de modelos Grafcet con ordes de forzado.
3.3.2.6. Consideracins sobre o uso de das escalas temporais independentes

Inda que a definicin de das escalas temporais independentes permite desligar as
evolucins internas do modelo da sa resposta externa e as, dende un punto de vista terico,
garantir a hiptese de sincronismo forte (3.3.2.4), existen certas complicacins adicionais
derivadas desta definicin. Como as das escalas son independentes non poden representarse os
eventos externos e internos sobre unha mesma escala de tempo, mais xa que as duracins na
escala de tempo interna son infinitamente pequenas en relacin escala externa onde son
percibidas como instantneas, si que posbel representar o que acontece na escala interna nun
instante dado da escala externa (Figura 3.35). Esta representacin recebe o nome de
representacin dilatada do tempo interno e unha propiedade da anlise non estndar [64],
utilizada na demostracin formal dos postulados temporais relativos s das escalas de tempo.
t1
t2
Figura 3.35. Representacin dilatada do tempo intemo.
As complicacins proveen da falla dunha definicin que indique como deben considerarse
os eventos externos, que son flancos instantneos no tempo externo, na escala de tempo interna,
onde os instantes externos son dilatados e, teoricamente, poden ter duracins tan longas como
se desexe. Como pode verse na Figura 3.36 hai das posbeis respostas, que o evento sexa
considerado como unha constante durante todo o perodo, ou ben, que a sa duracin sexa nula
no tempo interno e, polo tanto, poda asimilarse a un flanco ao comezo do perodo dilatado. A
escolla dunha ou outra solucin influir na evolucin interna do modelo, pois a avaliacin do
evento nas receptividades ter valores distintos nun e noutro caso.
80
^ tempo
externo
tempo
externo
tem po
interno
^ tempo
interno
(b)
(a)
Figura 3.36. Posbeis interpretacins dun evento externo na escala de tempo interna: (a) como tinha constante; e
(b) como un evento de duracin nula.
------------------------------ , -------------------.----------------------------------------------------------^
r---, ,--, ^-, , .^------^^
0
10
20
X31 , .
(10)
,^
30
(30^ a
F/GP4: {32}
11
31
(21^tX3
32
22
(22)
(32)
TX3
GP4
------------------------'
NF2
GP3
GP2
GP1
^-----------------------------------------------------------' '-------------------------------------NF1
N FO
S32 ^
L___1__L__L
1,
-------fi--------
S22
^-----^-------,
,
,
S20
S30
S22
S21
S21
^-i
S20
S11
S11
S10
S10
S10
S3
S3
S2
S2
S11
S1
S1
^---^---t---L
i

(a)
S31
S22
S3
S31
S30
S20
S32
S21
S32
S30
X3
L___J___l.__L
(b)
(c)
(d)
Figura 3.37. Exemplo de interpretacins dun mesmo Grafcet considerando: (a) Tb e TX3 na escala externa; (b) Tb
na escala externa e TX3 na interna; (c) Tb na escala interna e TX3 na externa; e(d) Tb e TX3 na escala interna.
81
Ademais este problema non afecta unicamente consideracin dos eventos externos [25]. O
mesmo acontece co estado de activacin das etapas, cos valores das varibeis e coa
consideracin das accins. En efecto, durante unha evolucin interna do modelo o estado de
activacin interno dunha etapa pode ser diferente ao seu estado de activacin externo, debido a
que o modelo puido mudar a sa situacin interna, mais a externa s mudara cando se chegue a
unha situacin interna estbel. A cuestin que se suscita cal dos dous valores utilizar durante
unha evolucin interna do modelo. O razoamento para as varibeis e as accins semellante, o
modelo podera inclur varibeis cuxos valores foran significativos s nunha das das escalas, e
accins que fosen consideradas s na escala externa (nunha situacin estbel) ou tamn na
interna (en situacins inestbeis). A Figura 3.37 mostra un exemplo de como a interpretacin
dos eventos, varibeis e accins con respecto s das escalas temporais modifica o
comportamento externo do modelo.
3.3.3. Interpretacin temporal das accins

O estndar Grafcet [ 164] incle diferentes tipos de accins que permiten o modelado de
diferentes relacins temporais entre o estado de activacin dunha etapa e o das varibeis
modificadas nas accins que tea asociadas. Neste apartado explcanse as semnticas temporais
de cada un dos tipos de accins do estndar.
3.3.3.1. Accins continuas (tipo N)
Nas accins continuas o estado de activacin da accin coincide co da etapa (Figura 3.38).
Se na especificacin da accin non se indica ningn tipo, este o utilizado por defecto.
3.3.3.2. Accins impulsionais (tipo P)
As accins impulsionais son accins que teen unha duracin moi pequena (Figura 3.39) e
que se utilizan para xerar pulsos nas sadas. O pulso xrase no instante de activacin da etapa.
3.3.3.3. Accins memorizadas (tipos S e R)
As accins memorizadas utilzanse cando a duracin da activacin dunha accin superior
ao da etapa que est asociada. Nese caso utilzanse un par de accins S e R asociadas a etapas
diferentes (Figura 3.40), na tipo S actvase a accin e na tipo R desactvase.
3.3.3.4. Accins condicionais (tipo C)
Nas accins condicionais o estado de activacin da accin depende do estado de activacin
da etapa e dunha condicin lxica. A accin s estar activa cando o estea a etapa que est
asociada e a condicin lxica sexa certa (Figura 3.41).
3.3.3.5. Accins temporizadas: retardadas (tipo D) e limitadas (tipo L)
As accins tmporizadas son un caso particular das accins condicionais nas que a
condicin lxica depende do tempo de activacin da etapa. Nas accins retardadas o instante
de activacin da accin posterior ao de activacin da etapa (Figura 3.42). Nas accins
limitadas o estado de activacin da accin simultneo co da etapa, e a sa duracin est
limitada, sendo sempre inferior ou igual duracin da activacin da etapa (Figura 3.43).
82
3.3.3.6. Combinacin de accins

As accins condicionais (C) e as temporizadas (D e L) poden ser utilizadas como
cualificadores das accins bsicas: continuas (N), impulsionais (P) e memorizadas (S, R), para
formar un tipo combinado (CP, DS, SL, DC, etc.), no que a orde na que aparece cada letra
relevante na interpretacin da semntica da accin (Figura 3.44; Figura 3.45; Figura 3.46). ,^
accin 1
n
(n)
Figura 3.38. Cronograma dunha accin tipo N.

n.X
acn 1
acn 1
(n)
_^
(n)
Figura 3.39. Cronograma dunha accin tipo P.
accin 1
accin 1
(m)--F-
(m)
Figura 3.40. Cronograma dunha accin memorizada.

n,X
accin 1
si D
i
i i--i
r,
' ' ---u^----i-----------

; n n
accin 1
^
(n)
Figura 3.41. Cronograma dunha accin condicional.

F
accin 1
_
^n^
n
D
accin 1
t#4s
i^-rÎ
i4s
i
i
i
;E i4s^^,
Figura 3.42. Cronograma dunha accin retardada.
83

^-.^
^ ^
n.X
accin 1
(n^
n
L
accin 1
t#4s
i
i
_ ;4s _
i
i
i
t-I-!
accin 1
(n)
Figura 3.43. Cronograma dunha accin limitada.
n.X
DS
accin 1
t#4s
(n)
accibn 1
i^4^
m.X
accin 1
n.X
--
^
i< i4s^; i
accin 1
m.X
i
ii
Figura 3.44. Cronograma dunha accin DS.

n.X
accin 1
i -
l^^
, :Q
m.X
n.X
accin 1
i4s
>
m.X
Figura 3.45. Cronograma dunha accin SD.
SL
t#4s
accin 1
accin 1
accin 1
m.X
Figura 3.46. Cronograma dunha accin SL.
84
3.3.3.7. Funcins operativas asociadas s accins

Como se explica en (3.4.1) o modelo Grafcet bsico formaliza unicamente dous tipos de
accins: as continuas e as impulsionais24; e utiliza un conxunto de funcins operativas [30]
pertencentes a un segundo nivel de descricin para modelar, desde un punto de vista externo, as
diferentes semnticas temporais explicadas nos apartados previos. As funcins operativas
utilizadas son as seguintes:
1. O operador de retardo, utilizado nas expresins lxicas que inclen temporizacins (por
exemplo, nas accins tipos D e L). Represntase mediante a expresin:
S = tl/E/t2
(3.10)
sendo:
S, a varibel booleana obtida como resultado da temporizacin.
E, a varibel booleana utilizada como base para o clculo da temporizacin.
t^ e t2, os tempos de retardo aplicados a E para obter S. En concreto, os instantes de

activacin (ta) e desactivacin (ta) de S calclanse segundo as frmulas:
ta(S) = ta(E) + t^
(3.11)
td(S) = ta(E) + t2
(3.12)
Cando algns dos retardos igual a cero pode omitirse, sendo entn E/t2 e t^/E as
representacins utilizadas para o operador. No primeiro caso t^ = 0 e ta(S) = ta(E) e no
segundo tZ = 0 e ta(S) = td(E).
2. O xerador de pulsos, utilizado para xerar un pulso de duracin tan pequena como se precise
nas accins impulsionais (tipo P).
3. A memoria, utilizada para almacenar o estado de activacin das accins memorizadas (tipos
R e S).
3.3.3.8. Resolucin de conflictos entre accins
Unha circunstancia que pode producirse durante a interpretacin dos modelos Grafcet a
modifcacin simultnea dunha mesma varibel desde diferentes accins activas. Se as
modificacins intentan asignar valores diferentes varibel existir unha situacin de conflicto
que pode dan lugar a resultados inesperados. preciso polo tanto ou ben garantir que o modelo
est libre de conflictos mediante tcnicas de anlise a priori, ou ben definir un mtodo para a
resolucin do conflicto cando este se produza. En [114] propense tres psbeis maneiras de
resolver esta situacin:
1. Asignar prioridades s etapas do modelo, de xeito que en caso de conflicto se apliquen
unicamente as accins de maior prioridade.
2. Definir unha relacin de composicin entre os valores asignados polas accins. Por
exemplo, podera utilizarse o OR lxico para os valores booleanos e a suma para os
enteiros.
3. Detectar a existencia de conflictos, indicalo activando un sinal de alarma e deter a

interpretacin do modelo.
24 Non confundir coas accins tipo P explicadas anteriormente.
85
Seccin 3.4: O modelo matemtico do Grafcet
Como explicado posteriormente (3.6.1.3), o estndar IEC 61131-3 resolve os conflictos

entre asociacins definindo un bloque de control que determina o estado de activacin dunha
varibel ou accin cando hai varias asociacins activas que a modifican.
3.4. O modelo matemtico do Grafcet

O modelo matemtico aqu descrito correspndense coa definicin orixinal do Grafcet
derivada da das RdP e na que se utilizan unicamente varibeis booleanas. O modelo est
composto por das compoentes: unha esttica, que describe a estructura dos modelos; e outra
dinmica, que describe as evolucins; e foi tomado das propostas aparecidas en diferentes
traballos [38][100][164]. Outras aproximacins baseadas en diferentes formalizacins
matemticas do tempo e os eventos poden consultarse en [33][64][65][74][147]. Recentemente
propuxronse extensins a este modelo para mellorar as capacidades de modelado de
xerarquas complexas, interrupcins ("preemption") e a aplicacin do Grafcet en sistemas
hbridos [75][76]. Algunhas destas propostas foron aprobadas como parte da revisin do
estndar Grafcet internacional [85] e a sa incidencia na ferramenta proposta nesta tese de
doutoramento pode consultarse en [133] e[134].
3.4.1. O contorno do modelo

A proposta orixinal do Grafcet propua unha formalizacin baseada na suposicin dunha
relacin entre o modelo e o seu contorno como a mostrada na Figura 3.47. Todas as entradas
(i) e sadas (o) utilizadas son booleanas e as accins divdense en das categoras: as
continuas e as impulsionais25. As accins continuas representan estados nos que se modifican
directamente as sadas do modelo (oZ, 04, 06), mentres que as impulsionais representan ordes
que ou ben poden ser emitidas directamente no proceso controlado (os*), ou ben indicar o
inicio (08*) dunha operacin auxiliar -realizada polas funcins operativas asociadas ao
Grafcet (3.3.3.7^ na que se modifique indirectamente unha sada (o^, 03) ou varibel interna
(i4) do modelo. As funcins operativas proporcionan diferentes posibilidades de modificacin
das sadas do modelo: xeracin de pulsos, temporizacins e memorizacins; o que permite
modelar, desde un punto de vista externo, distintos tipos de semnticas nas accins ( 3.3.3): P,
D, L, R, S, etc. En consecuencia no Grafcet distnguense formalmente dous niveis ou fronteiras
de descricin [30): o primeiro sera o formado pola definicin bsica, na que se dispn
unicamente dos dous tipos de accins comentados, e o segundo englobara ademais as funcins
operativas asociadas que permiten o modelado nas accins de diferentes semnticas temporais
desde un punto de vista externo.
Seccin lxica__
Equipamento
de control
^ Funcins operativas ,
i(temporizacins,_pulso_s)i
o
_`
___^____ f o8 _
Control secuencia^
^ (modelo Grafcet) i
i3
03
Seccins
continua e
numrica
bo4 li2 05'
Equipamento
de proceso
Figura 3.47. Intercambio de informacin entre o modelo e o seu contorno.

ZS Indicadas na Figura 3.47 cun asterisco.
86
3.4.2. Estructura esttica

O Grafcet un formalismo para a especificacin de sistemas lxicos secuenciais que pode
ser representado como unha tupla (G, Env, Int), na que:
G=(S, T, L, So), a estrutura do Grafcet. Esta estructura un grafo bipartito dirixido,

composto de dous tipos de nodos (conxuntos S e T) e un conxunto de arcos orientados (L ):
n
S={si, sz, ... , sm}, conxunto finito non baleiro de etapas. SocS o subconxunto de
etapas iniciais.
T={t^, tz, ... , t}, conxunto finito non baleiro de transicins.
L={l^, lz, ... , lP}, conxunto finito non baleiro de arcos orientados que unen unha etapa
a unha transicin ou viceversa; est formado polo par (LI, Lo) de xeito que:
n
LI: S x T--^ {0, 1} a funcin que describe o conxunto de arcos que unen unha
etapa a unha transicin.
Lo: T x S^{0, 1} a funcin que describe o conxunto de arcos que unen unha
transicin a unha etapa.
Utilzanse as notacins (s;) e(s;) para indicar, respectivamente, o conxunto de transicins

que preceden e suceden a unha etapa.^ A mesma notacin utilizada para indicar o
conxunto de etapas que preceden ou suceden a unha transicin.
Env =(I, O, EI, Eo), a interface do Grafcet co seu contorno (InOr1EInEo=QS):

n
I={i^, iz, ... , iq}, conxunto finito de entradas booleanas.
n
n
O={o^, oz, ... , o^}, conxunto finito de sadas booleanas.
Eo= {eo1, ez, ... , e,,}, conxunto finito de eventos de sada.
EI ={e;^, e;z, ... , e;,,}, conxunto finito de eventos de entrada.
Int =(R, A, X) a interpretacin do Grafcet:

n
R={r^, rz, ... , r}, conxunto finito de receptividades asociadas s transicins; `dt; E T,
r; a receptividade asociada transicin t;, e est formada polo par (E, C) de xeito que:
n
r;.E a parte da receptividade formada exclusivamente por eventos.
r;.C a parte da receptividade formada exclusivamente por varibeis booleanas.
Unha transicin ser franqueada cando ambas partes sexan certas e todas as etapas
que a precedan estean activas.
n
A={a^, az, ... , aW}, conxunto finito de accins asociadas s etapas; tÎs; E S, A(s;) _
{a;l, aiz, ... , a;k} o conxunto de accins asociadas etapa s;, e est formado polo par
(N, P) de xeito que:
n
A(s;).N o conxunto de accins continuas asociadas etapa s;.
A(s;).P o conxunto de accins impulsionais asociadas etapa s;.
X={X; ^(s; E S)} o conxunto de varibeis booleanas que almacenan o estado de

activacin das etapas. Relacionados con elas definense dous conxuntos de eventos:
n
n
Xa ={X',a ^(s; E S)} o conxunto de eventos de activacin da etapa s;.

Xd ={X;d ^(s; E S)} o conxunto de eventos de desactivacin da etapa s;.
87

O conxunto Es = EI U Xa U Xd define os eventos significativos, e dicir, os eventos que
poden dar lugar a unha evolucin do modelo.
3.4.3. Evolucin dinmica

No modelo dinmico as regras de evolucin dos modelos Grafcet (3.3.1) son representadas
mediante un conxunto de ecuacins booleanas que calculan a situacin seguinte do sistema en
funcin da situacin actual e dos valores das entradas. A activacin/desactivacin de cada etapa
do modelo calculada mediante a seguinte ecuacin:
X (t + 1) = CP(s ) V X (t) n CN(s )
(3.13)
sendo:
Xn(t), o estado de activacin da etapa s no instante t
CP(s), a condicin de activacin da etapa s,,, representada como:

p
CP(S )= V
r=i
n X ^ n r;
^=i
(3.14)
p o nmero de transicins que anteceden a s,,, e para cada transicin t; E{t^, .. , tP} que
antecede etapa:
n
m o nmero de etapas que anteceden a t; (e polo tanto a validan).

m
n X^ a condicin de validacin de t;, que ser certa cando todas as etapas que
l=^
anteceden a t; estean activas.
r, a receptividade asociada a t;.
CN(sn) a condicin de desactivacin da etapa s,,, representada como:

s
CN(s )= V
r=t
n X^ n r;
^=i
(3.15)
s o nmero de transicins que suceden a sn, e para cada transicin t; E{t^, .. , ts} que
sucede etapa:
n
n o nmero de etapas que anteceden a t; (e polo tanto a validan).

n
n X^ a condicin de validacin de t;, que ser certa cando todas as etapas que
j=1
anteceden a t; estean activas.
r; a receptividade asociada a t;.
Ntese que este modelo unicamente considera unha escala de tempo e non ten en conta as
ordes de forzado. En [59] pode consultarse un modelo dinmico que ten en conta ambos
aspectos e est baseado na representacin das regras de evolucin do Grafcet como ecuacins
.
diferenciais nun grupo de Galois de orde 2.
88
3.4.4. Comparacin con outros formalismos

Existen diferentes traballos que comparan formalmente as capacidades expresivas do
Grafcet coas doutros modelos para a especificacin de sistemas secuenciais e DEDS. Poden
consultarse [45][46] para unha comparativa coas RdP e as mquinas de estados; e[19][27] para
unha comparativa cos StateCharts. Nesta seccin resmense as principais conclusins deses
traballos.
3.4.4.1. Grafcet e redes de Petri
O Grafcet comparado cun tipo de RdP denominado RdP interpretadas (RdPI), que se
caracterizan basicamente por ter operacins asociadas aos nodos e eventos e condicins
asociadas s transicins. Hai das diferencias fundamentais entre o Grafcet e as RdPI
(supoendo que se utilicen interfaces de E/S e interpretacins equivalentes):
1. O marcado das etapas no Grafcet booleano (unha etapa pode estar activa ou inactiva) e
nas RdPI numrico (un nodo pode conter mltiples marcas).
2. No Grafcet se hai varias transicins franquebeis todas son simultaneamente franqueadas,
mentres que nas RdPI unicamente se franquea unha e non hai unha regra definida que
proporcione unha escolla determinista.
En consecuencia, para que un grafcet e unha RdPI sexan equivalentes teen que eliminarse
estas diferencias, o que se consigue impoendo certas restriccins na utilizacin dambos
modelos. No referente s RdPI, estas diferencias elimnanse se o modelo garante as
propiedades de seguridade: o nmero de "tokens" en cada nodo da rede ser menor ou igual a
un en calquera marca; e determinismo: as condicins asociadas s transicins simultaneamente
franquebeis sern exclusivas para evitar o franqueamento simultneo.
Con respecto ao Grafcet, definiuse o concepto de grafcet `san' para indicar un modelo que
cumpre coas propiedades seguintes:
1. En ningn momento pode darse a circunstancia de que estando unha etapa activa, haxa
unha transicin franquebel que a preceda e ningunha transicin franquebel que a suceda.
A razn que no Grafcet esta circunstancia provocara que a etapa continuase activa
regra 5 de evolucin (3.3.1.5^, mais nas RdPI o nmero de "tokens" do nodo pasara a
ser maior de un, incumprndose a condicin de seguridade.
2. Cada par de transicins que poidan ser simultaneamente franqueadas non poden ter unha
etapa inmediatamente predecesora en comn. Esta propiedade garante que non haber
conflictos (varias transicins cuxa activacin depende do mesmo nodo) na RdPI
equivalente e, polo tanto, que ser determinista.
3. Ningunha etapa pode ter mis dunha transicin antecesora simultaneamente disparbel. O
motivo o mesmo que na primeira propiedade, no Grafcet esta circunstancia provocara
que a etapa se activase, mentres que nas RdPI o nmero de "tokens" do nodo pasara a ser
igual ou maior de un.
Das consideracins anteriores dedcese que un grafcet `san' equivalente a unha RdPI
(cunha interface de E/S e unha interpretacin equivalentes s do Grafcet) que cumpra as
propiedades de seguridade e determinismo. En [46], este tipo de redes denomnanse RdPI de
comando.
89
3.4.4.2. Grafcet e mquinas de estados

As mquinas de estados son o modelo clsico de descricin de sistemas secuencias e
divdense en das categoras: as mquinas asncronas, nas que os cambios de estado debidos a
variacins nas entradas son considerados en calquera momento de funcionamento; e as
mquinas sncronas, nas que unicamente poden producirse en sincrona cos cambios^dunha das
entradas utilizada como sinal de reloxo. Nambos casos existen dous tipos de mquinas
dependendo da funcin considerada para o clculo das varibeis de sada: as mquinas de
Moore, nas que os valores das sadas dependen unicamente do estado interno do sistema; e as
mquinas de Mealy, nas que dependen tamn do valor das entradas.
Existe unha correspondencia directa entre todos os tipos de mquinas comentados e o
Grafcet: os estados e transicins dunha mquina son representados, respectivamente, mediante
etapas e transicins no grafcet equivalente. As diferencias entre os diferentes tipos de mquinas
afectan unicamente especificacin das receptividades e accins utilizadas. Como regra xeral,
a representacin de mquinas sncronas require a inclusin do evento T clk (sendo clk o sinal de
reloxo) en todas as receptividades do grafcet equivalente e, independentemente do tipo de
sincronismo da mquina, o clculo das sadas nas mquinas de Moore especificarase mediante
accins continuas e nas de Mealy mediante accins condicionais. Pode consultarse [46] para
unha explicacin detallada das diferentes posibilidades.
No que respecta ao caso contrario non sempre existe unha correspondencia directa entre o
Grafcet e as mquinas de estados, e isto debido fundamentalmente a das razns:
1. No Grafcet non preciso especificar transicins para todos os posbeis cambios de valor
nas entradas, senn unicamente para aqueles aos que o modelo receptivo nun estado
dado. En consecuencia o nmero de transicins utilizadas nun grafcet ser, por regra xeral,
menor ao da mquina de estados equivalente.
2. No Grafcet pode haber mis dunha etapa activa simultaneamente (concorrencia), o cal non
pode ser representado directamente nas mquinas de estados asociando un estado a cada
etapa. A forma comn de obter a mquina de estados equivalente consiste en representar
cun estado cada posbel situacin do grafcet (que pode estar formada por unha ou mis
etapas activas simultaneamente). En xeral isto leva a obter mquinas cun nmero de
estados moi superior ao nmero de etapas no grafcet equivalente (con n etapas poden
representarse 2" situacins).
Do explicado anteriormente dedcese que a capacidade de modelado do Grafcet
equivalente das mquinas de estados nas sas diferentes variantes, e que o nmero de etapas e
transicins necesarios ser inferior ou igual ao de estados e transicins da mquina equivalente.
3.4.4.3. Grafcet e StateCharts
Os StateCharts [78] son un formalismo baseado nas mquinas de estados para a
especificacin grfica de sistemas reactivos complexos que teen sido aplicados no modelado
de sistemas "hardware", do comportamento de aplicacins "soflware" complexas, de sistemas
de comunicacins, etc. As principais propostas deste formalismo en relacin s mquinas de
estados son a representacin de estructuras xerrquicas e a ortogonalidade (representacin de
mltiples estados independentes simultaneamente activos). importante indicar que os
StateCharts non incrementan as capacidades de modelado das mquinas de estados, senn que
constiten unha aproximacin que permite reducir a explosin combinatoria e facilita o manexo
de diagramas cun grande nmero de estados, que son habituais en sistemas complexos.
90
En xeral posbel obter unha equivalencia entre os StateCharts e o Grafcet, facendo

corresponder etapas e transicins no Grafcet con estados atmicos e transicins dentro dun
mesmo nivel nos StateCharts. As condicins de transicin e accins teen representacin
directa nambos formalismos. Cada nivel xerrquico dos StateCharts representarase mediante
un grafcet parcial no Grafcet, e as compoentes ortogonais dos estados AND mediante grafcets
conexos nos que se garanta que, como mximo, unha etapa estea activa en cada instante. Sen
embargo hai caractersticas nambos formalismos que non teen representacin directa no outro,
anda que sempre posbel buscar unha alternativa que respecte a semntica, por exemplo:
1. As transicins entre diferentes niveis xerrquicos nos StateCharts poden representrse no
Grafcet mediante transicins fonte precedendo s etapas a activar e transicins sumidoiro
sucedendo s etapas a desactivar en cada nivel. As receptividades destas transicins
relacionarn o estado de activacin das etapas implicadas coas condicins de transicin
orixinais26.
2. O concepto de historia dun estado nos StateCharts require da utilizacin de varibeis
auxiliares que memoricen o estado dunha etapa e dunha aproximacin semellante
explicada anteriormente para activar as ltimas etapas que estiveran activas nun
determinado nivel xerrquico do modelo.
3. As ordes de forzado no Grafcet poden representarse mediante transicins entre niveis
xerrquicos nos StateCharts.
Do anterior dedcese que a capacidade de modelado do Grafcet equivalente dos
StateCharts, anda que a representacin das transicins entre niveis e o concepto de historia dun
estado require, en xeral, da utilizacin de transicins (fonte e sumidoiro) adicionais, e de
receptividades complexas que relacionen os estados de activacin das etapas coas condicins
de transicin orixinais.
3.5. Exemplos de modelado

Neste apartado recllense dous exemplos da aplicacin do Grafcet na automatizacin de
procesos discretos de fabricacin e manipulacin de pezas que son comns a moitas
instalacins industriais. Para simplificar os exemplos non se tivo en conta o control dos estados
de operacin do sistema nin o tratamento de condicins errneas de funcionamento.
3.5.1. Automatizacin dun posto de fabricacin de bridas

Neste exemplo [108] descrbese a automatizacin dun posto de fabricacin de bridas (Figura
3.48 e Figura 3.49), que contn tamn un mdulo de deteccin e discriminacin de pezas
defectuosas e outro de embalaxe. As pezas sen procesar (aneis metlicos) entran no posto pola
cinta 1 e son situadas baixo a taladradora mediante a accin combinada dos cilindros 1 e 2.
Cando o detector (D 1) detecta a presencia dun anel, a cinta 1 parase e o cilindro 1 empurra o
anel diante do cilindro 2. Este cilindro est conectado a un presostato que regula a presin que
o anel presionado contra un tope fixo situado baixo a taladradora. Xunto a este tope hai un
detector de proximidade (Dpos) que sirve para determinar se o anel est correctamente situado,
pois a viruta xerada polo taladrado podera desprazalo inadvertidamente. Cando o anel est
correctamente situado realizase o proceso de taladrado. A taladradora contn dous motores, un
Z6 Na revisin mis recente do estndar Grafcet [85] inclese o concepto de "enclosure steps", directamente
baseado nos estados AND dos StateCharts. Con esta extensin a representacin de transicins entre diferentes
niveis non require mis que a modificacin de receptividades para obter a mesma semntica nambos formalismos.
91
Seccin 3.5: Exemplos de modelado
para o desprazamento vertical da taladradora (M2) e outro para o xiro do cabezal multibroca
(M 1). O arranque e parada destes motores controlado mediante detectores de fin de carreira
(Dfc 1 e Dfc2 para M 1 e Dfc3 e Dfc4 para M2). Unha vez rematado o proceso de taladrado 0
cilindro 3 retira a tapa dun burato situado baixo anel e este cae na cinta 2 que o transporta
cara ao mdulo de deteccin de defectos e empaquetado.

O proceso de deteccin de pezas defectuosas realizase mediante un sistema de visin
artificial que se activa cando o detector (Dva) detecta o paso dunha peza pola cinta 2. Nese
intre a cinta pararase e o sistema determinar si a peza ou non vlida. En caso de non selo 0
cilindro 4 empurrar a peza dentro da caixa de pezas defectuosas e en caso de ser correcta
continuar o funcionamento da cinta 2 que levar a peza s caixas da cinta 3. Ao final da cinta
2 hai un detector de presencia (Dn) utilizado para contar o nmero de pezas que van caendo en
cada caixa. Cando se enche unha caixa, a cinta 2 parase e arrncase a cinta 3 que leva unha
nova caixa baixo a cinta 2. Para situar correctamente a nova caixa utilzase outro detector de
presencia (Dc).
Na Tboa 3-II poden verse resumidas as entradas, sadas e contadores implicados na
automatizacin do posto de fabricacin de bridas. Na Figura 3.50 amsase o Grafcet principal
de control do posto de fabricacin de bridas e na Figura 3.51 os contidos da macro que controla
o proceso de taladrado das pezas. Para aproveitar a posibilidade de realizar en paralelo os
procesos de taladrado, discriminacin de pezas defectuosas e embalaxe utilizouse no Grafcet da
Figura 3.50 unha estructura semellante da Figura 3.21, que permite alternar entre das
secuencias de accins paralelas. Neste exemplo concreto poden realizarse en paralelo 0
taladrado dunha nova peza e a verificacin e embalaxe doutra. Para que se procese unha nova
peza preciso que a que actualmente ocupa a taladradora pase ao subsistema de deteccin de
fallas (etapa 2) e isto non acontecer ate que se valide a peza anterior (etapas 8 a 12) e haxa
unha caixa correctamente situada na cinta 3(etapas 5 a 7).
Figura 3.48. Posto de fabricacin de bridas (vista 1).
92
Dm8
q
CIL. 4
q D
4 Dm7
Bridas
defectuosas
Figura 3.49. Posto de fabricacin de bridas (vista 2).
^ PZS != Lim
5
PZS == Lim
0
PZS = 0
DFS = 0
Cinta 3
Dfc1 Dfc3
PZS = 0
?Dc
100
=1
Cil 3
1Dva
1Dpos
9
3
H Cinta2
Cil 2
Visin
Artificial
defectuosa
^X3/2.5s
10
Cil4
vlida
11
DFS++
^X10/2.5s
Cinta 2
si Dc
^Dn
12
^-
Figura 3.50. Grafcet principal de control do posto de fabricacin de bridas.
PZS++
93
DI
Detector de proximidade da cinta 1
Cil l
Avance do cilindro I
PZS I Pezas na caixa actual
Dpre
Presostato do cilindro 2
Cil2+
Avance do cilindro 2
DFS
Dpos
Detector de proximidade do tope fixo
Cil2-
Retroceso do cilindro 2
Dfc 1
Detector superior de final de carreira do motor 1
Cil3
Dfc2
Detector inferior de final de carreira do motor 1
Ci14
Dfc3
Detector superior de final de carreira do motor 2
Cintal
Arranque da cinta 1
Dfc4
Detector inferior de final de carreira do motor 2
Cinta2
Arranque da cinta 2
Dva
Detector de presencia na entrada ao mdulo de VA
Cinta3
Arranque da cinta 3
Valida
Indicador de peza vlida
MI+
Avance do motor 1
Defectuosa
Indicador de peza defectuosa
Ml-
Retroceso do motor I
Dn
Detector de presencia ao final da cinta 2
M2+
Avance do motor 2
Dc
Detector de caixa na cinta 3
M2-
Retroceso do motor 2
Lim
Nmero de pezas por caixa
Total pezas defectuosas
Tboa 3-II. Entradas, sadas e contadores utilizados na automatizacin do posto de fabricacin de bridas.
X105/2.5s
106 H M1Dfc1
107 H M2Dfc3
108
Figura 3.51. Contidos da macro 100 que controla o proceso de taladrado dunha peza.
3.5.2. Automatizacin dunha cela de fabricacin flexible

O problema a resolver neste exemplo [30] consiste na automatizacin dunha cela de
fabricacin flexbel como a que pode verse na Figura 3.52. Esta cela est composta por unha
cinta de transporte pola que circulan os pals que conteen as pezas a ser procesadas, das
mquinas (unha fresadora e un torno), tres postos (PE, PS e PT) para o desprazamento das
pezas dende as mquinas aos pals ou viceversa, dous robots que realizan eses desprazamentos,
94
un punto de entrada na cela das pezas a procesar e outro de sada da cela das pezas xa
procesadas. Cada peza que entra na cela leva asociado un cdigo que indica as operacins que
xa se realizaron sobre ela e as que quedan por realizar. Este cdigo pode ter un dos valores
indicados na Tboa 3-III.
(t-, f-, t-f-, f-t-)
Entrada
Pals
valeiros
Espera para torneado

(t-, t-f-, f+t-)
PE
^^
SF
Fresadora
EF
Espera para
fresado
(f-, f-t-)
PT
^^,
Torno
(f-, t+f-, f-t-)
PS
t+,f+t+)
(f+^ t+f+)
^
Espera para
fresado ou saida
(t+, t+f-^ f+t+)
Saida
Figura 3.52. Cela de fabricacin flexbel.
Peza ara torneado

t*
f*
Peza ara fresado
t*f* Peza ara torneado e fresado nesa orde
f*t* Peza ara fresado e torneado nesa orde
*_+- indica se a o eracin xa foi realizada ou anda hai ue facela.
Tboa 3-III. Valores do cdigo de cada peza.
Os robots encrganse das operacins de movemento das pezas desde as mquinas e puntos
de entrada e sada da cela cara aos pals situados nos postos para a transferencia de pezas (PE,
PS e PT). As o robot 2 move as pezas entre o pal situado no posto PT e o torno, e o robot 1
pode realizar algn dos movementos indicados na Tboa 3-IV.
E^PE
PS^S
PSÊF
SF^PE
Do punto de entrada ao pal baleiro situado no posto PE (pezas novas)
Do pal situado no posto PS ao punto de sada (pezas rematadas)
Do pal situado no posto PS entrada da fresadora
Da sada da fresadora ao pal baleiro situado no posto PE
SF^S
Da sada da fresadora ao punto de sada (pezas rematadas)
Tboa 3-IV. Movementos de pezas que pode realizar o robot 1.
A efectos do exemplo o mais interesante o control do robotl polo que se obviaron as

operacins de fresado, torneado, o control do robot 2, a carga e descarga de pals nos puntos
PE, PS e PT e a descricin detallada da secuencia de movemento dunha peza dun posto a outro.
Algunha destas operacins aparecen no grafcet de control do robot 1 representadas mediante
macroetapas, mais no exemplo non se inclen os contidos das macroexpansins. As entradas e
95
varibeis utilizadas son as indicadas na Tboa 3-V e o grafcet principal de control do robot 1
o amosado na Figura 3.53. O estado de activacin dalgunhas das etapas deste grafcet teen un
significado especfico que se recolle na Tboa 3-VI.
On
Peza
Fin_op
Saida
Fe
Sinal de funcionamento da cela ^ X ^ Orixe da operacin de movemento dunlia Qeza

Presencia dunha peza na entrada
Final da operacin de movemento dunha peza
Final da operacin en curso
Indicador de sada dunha peza
Indicador de entrada dunha peza
na fresadora
Tboa 3-V. Entradas e varibeis utilizadas na automatizacin da cela de fabricacin flexibel.
2
3
4
5
6
7
8
Peza a ardando na entrada a ser movida a PE

Robot 1 libre
^
Pal baleiro no osto PE
Peza en SF a ardando a ser movida a PE
Sada da fresadora libre
Peza en SF a ardando a ser movida sada
Peza en EF
9
10
11
12
100
200
300
EF libre
Peza en PS a ardando a ser movida a EF
Peza en PS a ardando a ser movida sada
Peza a ardando a ser retirada da sada
Movemento dunha eza dun unto a outro
Car a e descar a de als no osto PE
Car a e descar a de als no osto PS
Tboa 3-VI. Significado do estado de activacin das etapas do Grafcet do robot 1.
O grafcet de control do robot 1 debe garantir que unicamente unha das cinco posbeis
secuencias de control para o movemento de pezas est activa. Isto consguese pola propia
estructura do grafcet e mediante as condicins asociadas s transicins 2, 4, 7, 9 e 11. Estas
condicins impoen unhas prioridades nos posbeis movementos do robot, sendo mais
prioritarios os movementos que sacan pezas da cela cara ao posto de sada e menos prioritarios
os que introducen pezas dende a entrada cara ao posto PE, co obxectivo de evitar a saturacin
do sistema. A orde de prioridades dos movementos SF^S (transicin 7), PS^S (transicin
11), PSÊF (transicin 9), SF^PE (transicin 4) e E^PE (transicin 2).
Como pode comprobarse no grafcet da Figura 3.53, para que as transicins que dan paso s
secuencias de control dos movementos do robot estean validadas, o robot debe estar inactivo
etapa 3 activa-. Ademais a transicin 7(a mis prioritaria) estar validada unicamente cando
haxa unha peza agardando na sada da fresadora para ser movida sada da cela ^tapa 7
activa- e s ser franqueada cando a sada non estea ocupada ^tapa 12 non activa-. Esta
transicin ten maior prioridade que as transicins 9 e 11, xa que estas transicins s poden ser
franqueadas cando non haxa pezas agardando na sada da fresadora -etapa 7 non activa-.
Ademais as transicins 9 e 11 non poden estar simultaneamente validadas pois as etapas 10 e
11, que representan a presencia dunha peza agardando no posto PS, non poden estar activas
simultaneamente. Como estas transicins son as que dan paso s secuencias de movemento
dunha peza dende o posto PS, s unha delas vai estar validada cando haxa unha peza en PS.
Algo semellante acontece coas transicins 4 e 7 que controlan as secuencias de movemento
de pezas dende a sada da fresadora. Para que a transicin 4 estea validada ten que estar activa a
etapa 5, e para que a transicin 7 estea validada ten que estar activa a etapa 7. Ambas as das
etapas -5 e 7- representan a presencia dunha peza agardando na sada da fresadora e s unha
das das pode estar activa simultaneamente. Ademais para que a transicin 4 sexa franqueada
non pode haber ningunha peza agardando en PS -macro 300 activa-, o que garante que as
96
transicins 9 e 11 (que son as que controlan o movemento de pezas dende PS) van ter
prioridade sobre a transicin 4.
A transicin con menor prioridade a transicin 2, que da paso secuencia de control para o
movemento de pezas dende a entrada da cela ata o posto PE. Esta transicin s vai estar
validada cando haxa unha peza agardando na entrada -etapa 2 activa-, o robot 1 estea libre
-etapa 3 activa- e haxa un pal baleiro no posto PE -etapa 4 activa-. Unha vez qu se
cumpran esas condicins, para poder franquear a transicin ten que cumprirse ademais que non
haxa pezas agardando na sada da fresadora ^tapa 6 activa- ou no posto PS -macro 300
activa-. Isto garante que as transicins 4 e 7 e as transicins 9 e 11, respectivamente, van ser
mis prioritarias que a transicin 2.
A secuencia que sigue unha peza dende que chega entrada da cela ate que sae dela a
seguinte:
Cando chega a peza cela (Peza = true), se esta est en funcionamento (ON = true),
actvase a etapa 2.
Unha vez que o robot queda libre -etapa 3 activa-, haxa un pal baleiro no posto PE
etapa 4 activa- e non haxa pezas agardando nin na sada da fresadora nin no posto PS
etapas 6 e 300 activas- inciase a secuencia de movemento da peza dende a entrada ate o
posto PE -secuencia 50, 100-. Ao remate desta secuencia actvanse as etapas 1(para
aceptar novas pezas na entrada da cela), 3(robot libre) e 200 (macro que despraza o pal
ocupado cara zona de espera correcta dacordo ao cdigo da peza e introduce un novo pal
baleiro no posto PE).
Ao rematar a macro 200, actvase a etapa 4 para indicar que un novo pal baleiro est na
posicin PE. A peza estar agora sobre un pal na zona de espera do torno se o seu cdigo
t- ou t-f-, ou na zona de espera do posto PS se o seu cdigo f- ou f-t-. No primeiro dos
casos a peza, despois de ser torneada, posta de novo sobre un pal na zona de espera do
posto PS e o seu cdigo pasar a ser t+ ou t+f-. En calquera caso o pal no que est a peza
ser cargado no posto PS na macro 300. Se xa se remataron todos os procesos sobre ela
(cdigo t+) actvase a etapa 1 l, que indica que a peza est en PS agardando a ser movida
sada da cela. Se anda hai que fresala (cdigos f-, f-t- ou t+f-) activarase a etapa 10 que
indica que hai unha peza en PS agardando a ser movida entrada da fresadora.
Se a peza est agardando en PS a ser movida sada ^tapa 11 activa-, cando o robot
estea libre ^tapa 3 activa-, non haxa outra peza agradando na sada da fresadora
etapa 7 inactiva- e a sada estea libre -etapa 12 inactiva- iniciarase a secuencia 90, 100,
que move a peza dende o posto PS sada. Cando esta secuencia remate liberarase o robot
-actvase a etapa 3-, retirarase o pal baleiro do posto PS -na macro 300- para cargar
un novo pal, e activarase a etapa 12 que indica que hai unha peza na sada da cela
agardando a ser retirada.
Se a peza est agardando en PS a ser movida fresadora ^tapa 10 activa-, cando 0

robot e a entrada da fresadora queden libres -etapas 3 e 9 activas-, e non haxa outra peza
agardando na sada da fresadora -etapa 7 inactiva-, iniciarase a secuencia 80, 100 que
move a peza dende o posto PS entrada da fresadora (EF). Cando esta secuencia remate,
liberarase o robot -activase a etapa 3-, retirarase o pal baleiro do posto PS -na macro
300- para cargar un novo pal, e activarase a etapa 8 que indica que hai unha peza
agardando na entrada da fresadora.
97
l"^
X I>.
^
rn
^^
r-N
n
o^
c
LL
v
c^
aNi
co
wa
u u
d
n
II
O_
0
0
Figura 3.53. Grafcet principal de control do robot 1.
98
As etapas 5 e 7 actvanse cando remata a operacin de fresado sobre unha peza e esta
depositada na sada da fresadora. A etapa 5 actvase cando peza anda lle queda pasar
polo torno (cdigo f+t-), o que indica que a peza agarda a ser movida a un pal baleiro no
posto PE para ser posteriormente transportada ao torno. En canto etapa 7, actvase cando
xa se remataron todas as operacins sobre a peza (cdigos f+ ou t+f+) e indica que a peza
est agardando a ser movida sada da cela. Este o caso prioritario e abondar con qu o
robot e mais a sada da cela estean libres -etapa 3 activa e 12 inactiva, respectivamente
para que se inicie a secuencia 70, 100 que mover a peza dende a sada da fresadora ate a
sada da cela. Unha vez rematada a secuencia, liberase o robot -actvase a etapa 3-,
indcase que a sada da fresadora est libre ^tapa 6 activa- e que na sada da cela hai
unha peza agardando a ser retirada -etapa 12 activa-.
No caso en que a peza est agardando a ser movida dende a sada da fresadora ate o posto
PE -etapa 5 activa-, cando o robot quede libre -etapa 3 activa-, haxa un pal baleiro
situado no posto PE -etapa 4 activa- e non haxa ningunha peza agardando no posto PS a
ser movida -macro 300 activa-, iniciarase a secuencia 60, 100 para realizar dito
movemento. Ao rematar a secuencia liberarase o robot -etapa 3 activa-, activarase a
macro 200 para dirixir o pal sobre o que est agora a peza cara zona de espera para o
torno, cargarase un novo pal baleiro no posto PE e activarase a etapa 6 que indica que a
sada da fresadora est agora libre.
3.6. O estndar IEC 61131-3 e o SFC

O Grafcet foi inicialmente concibido como un estndar grfico (IEC 60848, [84]) para a
especificacin de controladores lxicos secuenciais independente da tecnoloxa utilizada na
implementacin: pneumtica, elctrica, microprocesadores, PLCs, etc. O equipamento mis
utilizado nos sistemas industriais para a implementacin de controladores lxicos o PLC. As
primeiras linguaxes de programacin destes equipos estaban baseadas na representacin das
relacins lxicas de E/S mediante a utilizacin de listas de instruccins ou diagramas de
contactos. Con estas linguaxes a programacin de secuencias de control complexas resulta
dificil, pois non proporcionan soporte estructuracin e non fcil abstraer a estructura de
control a partir do cdigo dos programas. Os fabricantes de PLCs decatronse pronto de que o
Grafcet proporcionaba unha linguaxe grfica, fcil de entender e utilizar, coa que a
programacin e depuracin de secuencias complexas resultaba moito mis simple, polo que
comezaron a inclulo como linguaxe de programacin nos seus ambientes de desenvolvemento.
Sen embargo a carencia dunha especificacin que indicase de maneira unvoca como
implementar o Grafcet nesta nova funcin levou a unha situacin de coexistencia de diferentes
dialectos incompatbeis entre si, que dependan en boa medida das capacidades proporcionadas
polo "hardware" dos fabricantes. Esta situacin tia numerosas desvantaxes [105]:
A dependencia dun fabricante, pois estes ofrecan solucins baseadas en arquitecturas
propietarias que dificilmente podan integrar e.
Os custos de mantemento, a dependencia dun fabricante provoca que non sexa posbel
dispor de equipamentos equivalentes proporcionados por terceiros. Esta ausencia de
competencia provoca que os prezos dos recambios e actualizacins sexa maior.
Os custos de formacin, a ausencia dunha interface comn dificulta a formacin de

operadores e enxeeiros no manexo do "hardware" dos diferentes fabricantes.
A dificultade na adopcin de solucins heteroxneas, debido complexidade inherente

integracin de equipos de diferentes fabricantes.
99
Seccin 3.6: O estndar IEC 61131-3 e o SFC
O estndar IEC 61131-3 [86] xurde como un intento de unificar as diferentes linguaxes
utilizadas para a programacin de PLCs co obxectivo de permitir a aparicin de ferramentas
abertas que faciliten a portabilidade e permitan reducir a dependencia dos fabricantes existente
ata ese momento. Unha das linguaxes includa no estndar o SFC, unha versin do Grafcet
adaptada programacin de PLCs. Neste apartado resmense as caractersticas mis relevantes
do SFC, especialmente aquelas que presentan diferencias coa definicin do Grafcet vista
anteriormente. O estndar IEC 61131-3 resume estas caractersticas mediante tboas, que
poden ser consultadas no Anexo A.
3.6.1. O SFC
O SFC utilizado para a estructuracin da secuencia de control interna nos diferentes tipos
de POUs (funcins, bloques funcin e programas) definidos no modelo "software" proposto
como parte do estndar IEC 61131-3. A sa definicin est baseada no estndar IEC 60848
coas modificacins precisas para converter o que un estndar de especificacin e
documentacin nunha linguaxe de programacin.
3.6.1.1. Etapas
Adptase a representacin grfica definida polo estndar IEC 60848 para as etapas e etapas
iniciais (3.2.1.1). Tamn se definen das varibeis que estarn asociadas a cada etapa:
Un `flag" booleano que almacena o estado da etapa, o seu valor inicial ser 0 excepto nas
etapas iniciais que ser 1.
Unha varibel (tipo TIME) que almacena o tempo transcorrido desde a ltima activacin
da etapa, o seu valor inicial t#Os. Esta varibel almacena a informacin mesmo despois da
desactivacin da etapa e non se reinicia ata que a etapa volve activarse.
Ambas varibeis son s de lectura, e o estndar indica que debe considerarse un erro
calquera intento de modificar o seu valor.
^
Un aspecto no que difiren o SFC e o Grafcet a restriccin de permitir unicamente unha

etapa inicial en cada rede SFC -que o equivalente a un grafcet conexo (3.2.2.3^.
3.6.1.2. Transicins
Adptase a representacin grfica definida polo estndar IEC 60848 para as transicins
(3.2.1.2). As condicins de transicin poden especificarse utilizando as linguaxes ST, LD ou
FBD directamente no SFC, ou ben definindo un bloque de cdigo con calquera das linguaxes
do estndar: LD, FBD, IL ou ST e asocindoo transicin mediante o seu nome. O estndar
especifica que calquera èfecto colateral' (modificacin dunha varibel) provocado pola
avaliacin dunha condicin de transicin ser considerado coma un erro.
3.6.1.3. Accins
Adptase a representacin grfica definida polo estndar IEC 60848 para as accins
(3.2.1.5). Cada etapa pode ter asociadas 0 ou mais accins, unha etapa sen accins asociadas
equivale a unha funcin WAIT que agarda a que algunha das transicins que suceden etapa
sexa franqueada. A definicin de cada accin faise nun bloque de definicin de accin ("action
block"), que utilizado como un elemento grfico mis nos diagramas LD e FBD e que se
100
corresponde coa especificacin detallada definida no estndar IEC 60848 (Figura 3.5) e est
formada por 4 campos:
1. Campo à', o tipo da accin.
2. Campo `b', o nome da accin.
3.
Campo `c', o valor booleano utilizado para indicar a finalizacin da accin, condicins de
erro, etc.
4.
Campo `d', o cdigo da definicin da accin, no que pode utilizarse calquera das outras
linguaxes definidas polo estndar, includo o SFC.
O estndar IEC 61131-3 mais especfico que o IEC 60848 na definicin dos tipos de
accins e a sa semntica temporal. Ademais establece que as accins temporizadas (tipos L,
D, SD, DS e SL) tern asociada unha varibel tipo TIME na que se almacene a duracin dende
a activacin da accin.
Encanto resolucin de conflictos entre accins ( 3.3.3.8), o estndar IEC 61131-3 define
un bloque de control de accins ("ACTION_CONTROL function block", Figura 3.54) de uso
interno ( dicir, non accesbel ao usuario) que define a semntica de execucin das accins
cando son activadas simultaneamente desde diferentes etapas. O estndar establece que toda
accin deber ter asociada unha instancia deste tipo de bloque, describe a sa estructura interna
(Figura 3.55) e indica as regras de conexin entre as accins e os bloques que as controlan.
Unha accin ser executada de maneira continua mentres a sada Q do bloque que a controla
sexa certa, e unha vez mis despois dun flanco negativo de Q. A Figura 3.56 mostra un
exemplo da utilizacin dos bloques de control de accin.
A execucin da accin unha vez mis inmediatamente despois dun flanco descendente da
sada Q, aspecto que foi introducido no estndar para penmitir que unha accin poida reiniciar
as varibeis que utiliza, ten creado certa confusin na interpretacin temporal das accins tipo
P, pois con esta especificacin son executadas das veces: unha no flanco de subida da sada Q
e outra no flanco de baixada. Este comportamento pouco intuitivo polo que se propuxeron
dous novos tipos de accins a incorporar nas futuras ampliacins do estndar: as tipo P 1 e P0,
que son executadas respectivamente nos instantes de activacin e desactivacin de Q.
ACTION_CONTROL
bool^ N
bool- R
bool
bool
bool
bool
bool
bool
bool
TIME
^-- bool
S
L
D
P
SD
DS
SL
T
Figura 3.54. Interface externa dun bloque de control de accins.
3.6.1.4. Estructuras de control

O estndar IEC 61131-3 adopta as mesmas estructuras de control definidas no IEC 60848
(3.2.3): secuencia simple, seleccin de secuencia, secuencias mltiples e saltos de secuencia.
Sen embargo non incle as macroetapas (3.2.2.2) e permite especificar a prioridade na
avaliacin das condicins de transicin co fin de evitar as situacins de paralelismo
interpretado (3.2.3.10).
101
>_
S FF
RS
R1
L TMR
TON
IN
Q
PT
D TMR
TON
IN
PT
P_TRIG
R_TRIG
SD FF
SD_TMR
RS
SD
S
R1
TON
IN
O
PT
Q1
DS_TMR
DS_FF
TON
IN
O
PT
DS
RS
S
R1
01
SL FF
SL
SL TMR
TON
IN
O
PT
Figura 3.55. Estructura interna dun bloque de control de accins.
12
(12).+
13
accionar bomba S FF
H S accionar bomba
D
t#2s
RS
S12.X
S14.X
H R accionar bomba
(a)
Q1
accionar
bomba
activar sinal
activar sinal D TMR
(13)
14
S
R1
S13.X
t#2s
TON
IN
Q1
PT
activar
sinal
(b)
Figura 3.56. Exemplo do uso dos bloques de control de accins: (a) SFC con distintos tipos de accins; e(b)
bloques de control de accin equivalentes.
3.6.1.5. Regras de evolucin

As regras de evolucin (3.3.1) adoptadas polo IEC 61131-3 son as do IEC 60848 con
pequenas variacins:
1. S pode haber unha etapa inicial en cada rede SFC, polo que a situacin inicial vir
determinada polo estado desa etapa.
102
2. As receptividades asociadas s transicins que suceden a unha etapa non son avaliadas ata
que os efectos da activacin da etapa sexan propagados na POU que a etapa pertenza.
3. A regra sobre a activacin/desactivacin simultnea dunha etapa non se incle no SFC
(3.3.1.5), non obstante o estndar especifica que a definicin de SFCs inseguros (Figura
3.57.a) que poidan dar lugar a situacins de paralelismo interpretado (3.2.3.10), as como
a definicin de SFCs que contean etapas inalcanzbeis (Figura 3.57.b) deben considerarse
como erros.
Ademais adptase para o SFC o postulado temporal do Grafcet (3.3.2.1) que establece que
o tempo de franqueamento dunha transicin (e polo tanto tamn o de activacin dunha etapa)
poder ser tan pequeno como se queira, mais non nulo. Isto implica que o estndar IEC 61131
3 adopta para o SFC unha semntica SRS (3.3.2.2).
(a)
(b)
Figura 3.57. Exemplos de: (a) SFC inseguro; e(b) SFC con etapas inalcanzbeis.
3.6.2. Comentarios sobre o estndar IEC 61131-3

A pesar das numerosas avantaxes que os promotores do estndar preconizaron, como por
exemplo:
A eliminacin da dependencia dun nico fabricante, ao favorecer o estndar a
uniformizacin das caractersticas ofrecidas polos diferentes fabricantes.
Un mellor aproveitamento dos recursos humanos, xa que cun menor esforzo en formacin
consguese unha maior aplicabilidade dos coecementos adquiridos.
A reutilizacin dos programas de control e a dispoibilidade de librarias xenricas, o

estndar favorece a aparicin de terceiras compaas que proporcionen solucins
"soflware" independentes dos fabricantes de equipamentos "hardware".
Faciltase a programacin e a depuracin, o estndar promove a programacin

estructurada, a utilizacin de tipos e estructuras de datos, a combinacin de diferentes
linguaxes, a utilizacin de libraras, etc. o que permite reducir os tempos de
desenvolvemento, a presencia de erros e os custes de instalacin e mantemento.
103
Posibiltase a adopcin de solucins de control heteroxneas, ao favorecer a aparicin de

terceiras compaas que proporcionen equipos que poidan integrarse facilmente.
O estndar proporciona unha interface de programacin uniforme que facilita a evolucin

dos sistemas de control baseados en PLCs a sistemas mis flexbeis e heteroxneos, nos
que se combinen diferentes equipamentos de control: p.e. PLC-PC, "SoftPLC", control
baseado en PC, etc.
A da de hoxe o proceso de adopcin do estndar est a ser lento e desigual, e pode dicirse
que non se acadaron os niveis de aceptacin que serian previsbeis se se consideran os
beneficios anunciados. As principais reticencias proveen das comunidades de control
americana e asitica nas que teen maior importancia a presin do mercado e a esixencia de
competitividade que o cumprimento do estndar, que percibido como unha cuestin
secundaria. A opinin maioritaria a de estar a expectativa e agardar a que haxa mais
productos dispobeis no mercado de cara a considerar a sa adopcin no futuro [14][167].
Entre as diferentes crticas que se teen realizado [42][138] poden indicarse, por exemplo:
A estandarizacin dun conxunto de linguaxes constite un impedimento innovacin e en
ltimo termo vai en contra dos intereses dos usuarios.
As linguaxes estandarizadas (en concreto IL, FB, LD) estn anticuadas e son linguaxes de
baixo nivel baseadas en conceptos procedentes principalmente do campo da
electromecnica e a electrnica.
A portabilidade completa dos programas dificil de acadar, e probablemente non se
chegue nunca a conseguir completamente.
A adopcin do estndar s proporciona beneficios a longo prazo, xa que a substitucin
dun sistema de control propietario por outro baseado no estndar non proporciona ningn
beneficio inmediato.
No que ao SFC respecta, valrase a sa capacidade de sntese de secuencias complexas
mediante unha representacin grfica de fcil comprensin, mesmo para os non iniciados. As
principais crticas que se Ile realizaron foron as seguintes [42]:
A utilizacin conxunta do SFC e as outras linguaxes do estndar obriga ao programador a
traballar simultaneamente en dous planos: o secuencial definido polo SFC, e o
combinacional, especificado nas accins utilizando as outras linguaxes.
O conxunto de tipos de accins definido polo estndar innecesariamente arbitrario e

complexo, o que complica a interpretacin temporal do seu comportamento e constite
unha probable fonte de erros dificiles de detectar. Esta complexidade non est xustificada
se se compara coa funcionalidade que proporcionan.
Sen embargo e a pesar destas crticas a percepcin xeral a de que o SFC presenta mis
avantaxes que inconvenientes, por exemplo:
Permite representar secuencias de control complexas mediante un conxunto reducido de

estructuras bsicas: secuencia, seleccin de secuencia, paralelismo e saltos de secuencia.
Combinado co modelo software proposto no estndar promove a estructuracin e a

reutilizacin dos programas de control.
Proporciona unha forma de especificar os contidos de receptividades e accins mediante as

outras linguaxes definidas no estndar.
Clarifica os tipos de accins e a semntica da sa execucin.
3.7. Conclusins
104
Este captulo dedicouse a presentar o Grafcet, que o formalismo grfico utilizado para a
especificacin de secuencias de control complexas na ferramenta proposta nesta tese de
doutoramento. Expuxronse as vantaxes que proporciona e as principais lias de investigacin
relacionadas coa sa utilizacin como parte de metodoloxas de desenvolvemento "soflware".; a
proposta de extensins ao modelo, a verificacin e validacin mediante tcnicas formais, etc.
Describiuse a sa sintaxe, discutronse os aspectos temporais das diferentes posibilidades de
interpretacin dos modelos Grafcet, e incluronse unha formalizacin da relacin entre o
modelo e o seu contorno, unha descricin alxbrica da sintaxe e regras de evolucin, e unha
comparativa con outros formalismos de especificacin de sistemas secuenciais. Mostrronse
algns exemplos da aplicacin do Grafcet no modelado de sistemas industriais reais, e
finalmente, explicouse a relacin entre o SFC proposto no estndar IEC 61131-3 e o Grafcet.
O SFC unha versin do Grafcet adaptada programacin de PLCs que, en resume,
presenta as seguintes diferencias:
O SFC elimina as posbeis situacins de paralelismo interpretado (3.2.3.10) nas seleccins

de secuencia mediante a utilizacin de prioridades implcitas ou explcitas.
O SFC restrinxe a unha o nmero de etapas iniciais en cada rede SFC -que o
equivalente a un grafcet conexo (3.2.2.3^.
Os elementos sintcticos do SFC son unicamente os que permiten representar as estructuras

de control bsicas (3.2.1) definidas no estndar IEC 60848, sen inclur ningunha das
extensins sintcticas (3.2.2) propostas posteriormente.
A estructuracin dos modelos SFC realzase mediante a divisin en POUs do modelo

software proposto no estndar IEC 61131-3, no que as comunicacins entre SFCs
realzanse mediante o intercambio de varibeis globais. Non hai equivalente no SFC s
xerarquas estructurais (3.2.2.3) e de forzado (3.2.2.4) do Grafcet.
A semntica adoptada polo SFC a SRS (con pequenas variacins), e presenta os

problemas comentados na seccin (3.3.2).
Captulo 4 . Anlise de aplicacins

Grafcet
Dende a proposta inicial do Grafcet [ 1] foron varias as iniciativas de implementacin de

ferramentas para automatizacin de procesos que o incluran como formalismo de
especificacin de secuencias de control. En [16] analzase, dende un punto de vista histrico, a
incidencia do Grafcet no mercado norteamericano das ferramentas de automatizacin de
procesos. Algunhas das aplicacins comentadas nese artigo son dos finais dos anos 80 e xa non
estn dispobeis na actualidade (p.e. Sylgraf, Flexis) mentres que outras (p.e. Cadepa27,
PCPVirgo) foron adaptndose s innovacins do mercado e na actualidade estn dispobeis
comercialmente como ambientes para o desenvolvemento de aplicacins de control.
O obxectivo deste captulo analizar a situacin actual no que ao soporte do Grafcet se
refire. Para elo escolleuse unha mostra de aplicacins pertencentes a diferentes mbitos que o
utilizan para a especificacin ou programacin de secuencias de control. A escolla das
aplicacins fixose seguindo tres criterios:
1. A sa representatividade dentro dun mbito de aplicacin.
2. A sa difusin, xa sexa comercial ou educativa.
3. A sa relevancia como elemento de comparacin para os obxectivos desta tese de
doutoramento.
Debe terse en conta que esta escolla est limitada por dous factores inevitbeis: o
coecemento parcial do autor, dado o grande nmero de aplicacins existentes no mercado, e a
dispoibilidade dunha versin da aplicacin que puidese ser analizada. As aplicacins
escollidas, clasificadas por criterio de mbito de aplicacin28, son as seguintes:

Programacin de PLCs: ActWin e PL7.
Desenvolvemento de aplicacins de contro129: AutomGen, Graf7-C e WinGrafcet.
Desenvolvemento de aplicacins de control distribudas: IsaGraph.
Desenvolvemento de aplicacins HMI/SCADA: MachineShop e Visual UO.
Libraras Grafcet30: GrafcetView.
Z' Cadepa un producto da compaa Famic Technologies. http://www.famictech.com/
28 Esta clasificacin unicamente orientativa, algunha das aplicacins poderan ser includas en varias categoras.
29 Nesta categora tentou inclurse a Cadepa, unha aplicacin xurdida da investigacin sobre Grafcet realizada na
universidade francesa de Nancy nos finais dos 80, mais non se dispuxo dunha versin de demostracin.
105
Captulo 4: Anlise de aplicacins Grafcet
106
Un aspecto que preciso ter en conta na anlise a proposta do SFC (3.6) como linguaxe
grfica para a programacin de secuencias de control en PLCs no estndar IEC 61131-3 e a sa
influencia nas caractersticas do Grafcet implementadas nas ferramentas. Na actualidade a
conformidade co estndar percibida en xeral como un valor engadido nos productos, sobre
todo a longo prazo, polo que a maiora das aplicacins tenden a implementar a versin
aprobada nas recomendacins do estndar, en prexuzo da maior potencialidade de model'ado
do Grafcet. Estas aplicacins presentan un menor interese dende o punto de vista dos
obxectivos desta tese de doutoramento.
O resto do captulo est organizado da forma seguinte: no apartado (4.1) explcase como se
organizou a anlise das aplicacins e os mtodos utilizados nela; o apartado (4.2) describe en
detalle a anlise de cada aplicacin e, por ltimo, no apartado (4.3) resmense os resultados e
establcense as conclusins.
4.1. Estructuracin e mtodos utilizados na anlise

Na anlise das aplicacins seleccionadas tivronse en conta tanto os aspectos sintcticos
coma os semnticos do Grafcet, e relacionronse as caractersticas implementadas coas
recomendacins dos estndares IEC 60848 [84] e IEC 61131-3 [86]. Dividiuse a informacin
de cada aplicacin nos apartados seguintes:
Descricin e compoentes, no que se describe de forma xenrica a aplicacin e as sas
compoentes e funcionalidades principais, dndolle maior importancia ao soporte ofrecido
para a estructuracin dos proxectos.
O editor Grafcet, este o apartado principal no que se analizan as caractersticas do editor

grfico e as capacidades de modelado, simulacin e execucin da aplicacin. Pola sa
extensin este apartado dividiuse nas seguintes seccins:
1. Estructuras de control, dedicada a analizar as capacidades de edicin das estructuras
sintcticas bsicas (3.2.1), as extensins ao modelo includas (3.2.2) e o uso das
seleccins de secuencia, paralelismo, ciclos e saltos.
2. Estructura xerrquica, na que se analiza o soporte ofrecido edicin tanto da
xerarqua estructural (3.2.2.3) como da de forzado (3.2.2.4).
3. Accins e receptividades, nesta seccin comprobronse diferentes aspectos
relacionados coa edicin de accins e receptividades como os tipos de accins
includos, a sintaxe utilizada, o soporte de eventos, temporizadores e contadores, etc.
4. Identificacin, na que se analizan as opcins de identificacin e as funcionalidades
relacionadas coa renumeracin automtica durante a edicin.
5. Anlise sintctica, onde se analizou o mtodo de anlise sintctica e comprobouse se se

detectaban os erros mais comns.
6. Simulacin e execucin, seccin na que se describen as opcins includas pola
aplicacin para a simulacin e depuracin dos programas.
7. Algoritmo de interpretacin, analzanse aqu a semntica da execucin dos modelos
Grafcet: tipo de interpretacin (3.3.2.2), resolucin de conflictos entre accins
(3.3.3.8), aplicacin de ordes de forzado (3.3.2.5), etc.
Conclusins, onde se resumen as principais caractersticas da aplicacin.

3o Non se incluiu o GraphChart [ 10] nesta categora ao non disporse dunha versin de demostracin.
107
Seccin 4.1: Estructuracin e mtodos utilizados na anlise
No resto deste apartado descrbense en detalle as caractersticas analizadas detallando os

mtodos utilizados para realizar as comprobacins.
4.1.1. Caractersticas sintcticas

Coa intencin de sistematizar a anlise, dividronse as caractersticas sintcticas do Grafcet
en cinco grupos: estructuras de control bsicas, as definidas no estndar IEC 60848; extensins
das estructuras de control bsicas, as aparecidas con posterioridade norma IEC 60848;
accins e receptividades, identificacin e estructuras xerrquicas. Ademais analizronse
aspectos adicionais relacionados co funcionamento dos editores Grafcet que quedan fora do
alcance do definido nos estndares:
As limitacins dos editores grficos. bastante comn nos editores Grafcet que o rea de
edicin estea composta por unha matriz de celas organizadas en filas e columnas. O comn
que neste tipo de editores sexa dificil ou mesmo non sexa posbel editar estructuras
complexas ûe inclan semforos (3.2.3.8), por exemplo-. Ademais algunhas
aplicacins limitan o tipo de nodos que poden inserirse en cada cela dependendo da fila
que pertenza (p.e. filas impares para as etapas e pares para as transicins).
O mtodo de verificacin sintctica. Ademais de comprobar que os modelos cumpren a

regra sintctica da alternancia etapa-transicin (unha etapa non pode estar unida
directamente a outra etapa, nin unha transicin a outra transicin) os editores Grafcet teen
que verificar outros aspectos, como o cdigo de accins e receptividades, a identificacin
de etapas e transicins, a coherencia lxica das xerarquas estructural e de forzado, etc. En
xeral hai dous mtodos para realizar esta verificacin: "on-line" (simultaneamente coa
edicin do modelo) ou "off-line" (unha vez que a edicin do modelo est rematada). O
mais habitual son as aproximacins mixtas, que realizan automaticamente a verificacin
"on-line" dalgunhas caractersticas (a regra de alternancia etapa-transicin, a identificacin
de etapas e transicins) e o resto en "off-line" cando o usuario o solicita.
4.1.1.1. Estructuras de control bsicas

Neste apartado comprobouse a utilizacin dos elementos sintcticos bsicos definidos no
estndar IEC 60848: etapas (includas as iniciais), transicins e unins mediante arcos
orientados; as como as estructuras de control que poden modelarse con elas: secuencias, saltos,
ciclos, seleccins de secuencia e paralelismo. As principais diferencias danse entre as
aplicacins que implementan as recomendacins do estndar IEC 61131-3 e as que non. As
entre as primeiras hai aplicacins que permiten a edicin dunha nica rede SFC ou de varias,
as como aplicacins que limitan a unha o nmero de etapas iniciais utilizadas en cada rede
SFC ou que non impoen ningn limite. En canto ao segundo tipo de aplicacins, o habitual
que non tean estas limitacins e que permitan editar varios grafcets conexos sen lmite de
etapas iniciais.
Outro aspecto analizado foi a utilizacin de saltos e ciclos. Comprobouse se a aplicacin
permita a sa utilizacin e a forma utilizada para representalos (p.e. arcos orientados,
referencias de salto). Tamn se comprobou se era posbel iniciar mltiples saltos dende un
mesmo punto dunha secuencia de control, se son permitidos os saltos a etapas de niveis
xerrquicos diferentes e se a aplicacin actualizaba correctamente as referencias de salto
durante a edicin dos modelos.
Por ltimo, verificouse a utilizacin das estructuras de seleccin de secuencia e paralelismo,
distinguindo dous casos:
108
O caso bsico (ou rxido), no que unicamente poden modelarse estructuras completas nas
que cada comezo de seleccin (ou paralelismo) ten que ir acompaado dun fin de seleccin
(ou paralelismo).
2. O caso flexbel, no que os comezos e fins de seleccin (ou paralelismo) poden utilizarse sen
restriccins.
1.
As aplicacins do primeiro tipo non permiten modelar grafcets con estructuras complexas.
Para comprobar esta caracterstica utilizouse o modelo da Figura 3.53 que require, para poder
ser editado, dunha utilizacin flexbel das estructuras de seleccin de secuencia e paralelismo.
4.1.1.2. Extensins s estructuras de control bsicas
Dentro desta categora inclense as estructuras sintcticas definidas con posterioridade
norma IEC 60848: etapas (transicins) fonte e sumidoiro (3.2.2.1) as como calquera outra
caracterstica adicional non estndar implementada. Comprobouse se o programa detectaba
como errnea a definicin dunha transicin como fonte e sumidoiro simultaneamente e se as
transicins fonte estaban sempre validadas durante a execucin.
4.1.1.3. Accins e receptividades
Na anlise de accins e receptividades comprobronse os seguintes aspectos, relacionndoos
coas definicins dos estndares IEC 60848 e IEC 61131-3:
Os tipos de varibeis permitidos e a nomenclatura utilizada para asignar a sa posicin en

memoria.
Os tipos de accins ( 3.2.1.5) implementados e a semntica temporal de cada tipo. .
As linguaxes permitidas para a edicin de accins e receptividades. Neste punto hai

variedade de solucins: aplicacins que utilizan algunha ou todas as linguaxes do estndar
IEC 61131-3, que implementan algunha linguaxe propietaria ou que integran unha linguaxe
de programacin de alto nivel como Pascal ou C.
O soporte proporcionado utilizacin de eventos, temporizadores e contadores.
O mecanismo utilizado para impedir os èfectos colaterais' durante a avaliacin de

receptividades (3.6.1.2).
As caractersticas non estndar includas pola aplicacin.
Por ltimo tamn se analizou o mecanismo utilizado para resolver os conflictos entre
accins, anda que este aspecto foi includo no apartado dedicado ao algoritmo de
interpretacin ao tratarse dunha caracterstica relacionada coa execucin dos modelos.
4.1.1.4. Identificacin
Neste apartado analzase a forma de identificar as compoentes dun modelo: etapas,
transicins, accins, grafcets parciais, etc. Ademais de comprobar qu elementos poden
identificarse e qu tipo de identificador pode utilizarse, tamn se analizaron os erros detectados
durante a verificacin sintctica: identificadores duplicados, elementos sen identificar,
referencias de salto a etapas inexistentes, etc.; e as opcins dispobeis durante a edicin:
asignacin automtica de identificadores, renumeracin de etapas e transicins ao copiar ou
eliminar partes dun modelo, actualizacin automtica de referencias de salto e varibeis de
etapa nas renumeracins, etc.
109
Seccin 4.1: Estructuracin e mtodos utilizados na anlise
4.1.1.5. Estructuras xerrquicas

Neste apartado comprobouse qu elementos das xerarquas estructural (3.2.2.3) e de
forzado (3.2.2.4) implementa cada aplicacin, e as facilidades ofrecidas para a sa edicin.
Verificronse alg,ins aspectos relacionados coa correccin sintctica e a coherencia lxica
destas estructuras, como: utilizacin nica e aniamento das macroetapas, correccin dos
contidos das macroexpansins, sintaxe das ordes de forzado, presencia de ciclos na xerarqua
de forzado, etc. No apartado dedicado ao algoritmo de interpretacin tamn se analizou a
aplicacin das ordes de forzado durante a execucin dos modelos.
4.1.2. Caractersticas semnticas

A anlise das caractersticas semnticas de cada aplicacin dividiuse en tres seccins: o
algoritmo de interpretacin (3.3.2.2), a semntica temporal das accins (3.3.3) e a aplicacin
das ordes de forzado (3.3.2.5).
4.1.2.1. O algoritmo de interpretacin
Ningunha das aplicacins analizadas permite escoller o tipo de interpretacin semntica dun
modelo Grafcet, todas implementan unha nica aproximacin: xa sexa a SRS ou a ARS. Para
determinar a interpretacin utilizada en cada aplicacin utilizouse o grafcet da Figura 4.1. Nas
aplicacins con algoritmo tipo SRS executarase a accin asociada etapa 2, activando a sada
SO durante un tempo igual ao de franqueamento da transicin 2, cuxa condicin de transicin
sempre certa. Polo contrario, nas aplicacins con algoritmo ARS a situacin na que queda o
grafcet ao franquear a transicin 1 non estbel, polo que evolucionar desactivando a etapa 2
e activando de novo a 1 sen activar a sada S0.
1
(1)
2s/Xi
SO
Figura 4.1. Grafcet utilizado para comprobar o tipo de interpretacin.
Nas aplicacins con algoritmo ARS fixronse das comprobacins adicionais:

1. Utilizouse o grafcet da Figura 4.2 para verificar como son considerados os valores de
eventos e varibeis externas durante as evolucins internas (3.3.2.6). Neste grafcet,
partindo da situacin inicial, o evento Ta pode producir catro evolucins diferentes31:
a.
{0, 3}^(1, 3)-^{l, 4}, os eventos externos son considerados coma eventos durante a
evolucin interna e os internos son tratados no tempo interno.
b.
{0, 3}^{ 1, 3}^{ 1, 4 }, os eventos externos son considerados coma eventos durante a
evolucin interna e os internos son tratados no tempo externo.
c.
{0, 3}-^(1, 3)-^{2, 4}, os eventos externos son considerados coma constantes durante
a evolucin interna e os internos son tratados no tempo interno.
d.
{0, 3}-^(1, 3)-> {2, 3}^(2, 4)-^ {2, 5}, os eventos externos son considerados coma
constantes durante a evolucin interna e os internos son tratados no tempo externo.
31 As situacins estbeis representanse mediante chaves `{}'e as inestbeis mediante parnteses `Q'.
110
2. Comprobouse se a aplicacin inclua algn mecanismo para a deteccin de ciclos

estacionarios durante as evolucins internas (3.3.2.2). Para determinar esta caracterstica
utilizouse o grafcet da Figura 4.1, trocando a condicin da transicin 1 polo estado da
varibel externa a, deste xeito mentres esa varibel estea activada, o grafcet entrar nun
ciclo estacionario.
(o)
ta
(3)
iXi
(1)
ta
(4)
iX1
(2)
(5)
Figura 4.2 Grafcet utilizado para comprobar o manexo de eventos e varibeis durante as evolucins internas.
4.1.2.2. Semntica temporal das accins

Neste apartado analizouse o mecanismo utilizado en cada aplicacin para resolver as
situacins de conflicto entre accins (3.3.3.8). Como se explica en (3.6.1.3), o estndar IEC
61131-3 define un bloque de control de accin que determina o estado dunha varibel booleana
ou accin cando hai simultaneamente varias etapas activas que a modifican. Ademais o
estndar indica que a activacin simultnea de varias temporizacins que afecten mesma
varibel booleana ou accin debe considerarse como errnea. Tendo en conta estas
recomendacins analizronse catro situacins diferentes:
1. Varias accins (tipos R, S e N) modifican simultaneamente a mesma sada booleana.
2. Varias accins temporizadas (tipos L, D, SL, SD, DS) modifican simultaneamente a mesma
sada booleana.
3. Varias accins temporizadas (tipos L, D, SL, SD, DS) asignan valores diferentes mesma
varibel interna non booleana.
4. Varias accins simultneas do mesmo tipo (non temporizadas) asignan valores diferentes
mesma varibel interna non booleana.
Dacordo ao estndar IEC 61131-3, no primeiro caso a accin tipo R ten prioridade sobre as
demais; o segundo caso e o terceiro estn prohibidos; e non se define o comportamento do
sistema no ltimo caso.
4.1.2.3. Aplicacin das ordes de forzado
Neste apartado fixronse, naquelas aplicacins que inclen ordes de forzado, tres
comprobacins adicionais que estn relacionadas coa sa aplicacin durante a interpretacin
dos modelos (3.3.2.5):
1. As ordes de forzado son ordes internas que teen que aplicarse tanto en situacins estbeis
coma inestbeis. Para verificalo utilizouse o modelo da Figura 4.3. Nese grafcet, partindo
da situacin {1, 4, 8}, se aplicada correctamente a orde de forzado da etapa 5 ao
producirse o evento externo Ta, o modelo debera evoluir do xeito seguinte: {1, 4, 8}-^(2,
4, 8)^(2, 5, 9)^{2, 6, 7}.
111
Seccin 4.2: Aplicacins analizadas
2. A aplicacin das ordes de forzado debe manter a coherencia lxica da xerarqua de forzado,
dicir, as ordes son aplicadas recursivamente comezando polo nivel mais alto. Para
comprobalo utilizouse o grafcet da Figura 3.37, no que partindo da situacin { 1, 10, 20,
30}, se as ordes de forzado das etapas 2 e 21 son aplicadas correctamente, ao activarse a
varibel a producirase a evolucin seguinte: {1, 10, 20, 30}^{2, 10, 21, 32}. E.dende esta
situacin, ao producirse o evento Tb, a evolucin correcta sera unha das indicadas na
Figura 3.37 (dependendo da interpretacin dos eventos durante as evolucins internas).
3. Non estn permitidas as situacins de forzado mltiple.
G1
(4)
F/G1:{9)
2
(2'
(5^X2
3
(3)
i
8
(8,
6
b
(6)
.c
9
b
(9)
X2
Figura 4.3. Grafcet utilizado para comprobar a aplicacin das ordes de forzado durante as evolucins internas.
4.2. Aplicacins analizadas

4.2.1. GrafcetView
O GrafcetView unha librara desenvolvida pola empresa TecAtlant que permite a
utilizacin de modelos Grafcet no LabView [56], un ambiente de programacin da empresa
National Instruments orientado ao desenvolvemento de aplicacins para a adquisicin,
procesamento e visualizacin de datos e o control de instrumentos. O proceso de
desenvolvemento de aplicacins no LabView consiste na programacin de instrumentos
virtuais (VIs) mediante unha linguaxe grfica propietaria denominada G. O LabView incle un
grande nmero de VIs predefinidos para a adquisicin de datos, o procesamento de sinais, o
control de instrumentos, as comunicacins, operacins matemticas, etc.
O GrafcetView implementa os VIs precisos para poder integrar modelos Grafcet nas
aplicacins LabView, aproveitando deste xeito todas as facilidades de edicin, depuracin,
visualizacin grfica, conexin con dispositivos de E/S, etc. que proporciona esta aplicacin.
Mediante a implementacin de libraras adicionais e os dispositivos externos axeitados sera
posbel implementar mediante LabView a funcionalidade dun PLC e programalo utilizando
unha aproximacin grfica multilinguaxe semellante ^roposta polo IEC 61131-3. A versin
do GrafcetView analizada aqu a 1.1 de demostracin3 .
4.2.1.1. Compoentes
A librara GrafcetView implementa en dous VIs, un para as versins monotarefa e outro
para as multitarefa, a estructura comn (Figura 4.4) a todas as aplicacins que utilicen o
Grafcet. Ademais, as operacins utilizadas para realizar a interpretacin de modelos Grafcet
estn implementadas en cinco VIs adicionais:
3Z No resto deste apartado presuponse do lector unha familiaridade co manexo do LabView e a programacin en G.
112
l. G7-init, iniciacin da aplicacin;

2. G7-lecture, lectura das entradas e clculo de eventos e temporizacins;
3. G7-calcul, evolucin do modelo Grafcet e clculo das sadas;
4. G7-delete, finalizacin da aplicacin;
5. G7-calcul monoboucle, implementa a funcionalidade conxunta de G7-lecture e G7-ccul
nas aplicacins monotarefa.
O proceso de desenvolvemento dunha aplicacin con GrafcetView realizase en tres fases:
1. Definicin das E/S da aplicacin. As E/S poden simularse mediante os controis e
indicadores dos paneis de usuario ou adquirirse mediante algn dos dispositivos de E/S
soportados polo LabView. Tantos as entradas como as sadas estn definidas como
arranxos de valores booleanos con identifcadores coa sintaxe E para as entradas, e S para
as sadas.
2. Edicin do grafcet de usuario utilizando os VIs includos na librara que implementan as
estructuras de control do Grafcet.
3. Integracin dos resultados das das fases precedentes nunha das aplicacins predefnidas
polo GrafcetView. Para elo hai que inserir as entradas, sadas e modelos definidos polo
usuario nos lugares indicados na estructura da Figura 4.4.
Tache d'elaboration des sorties
ache de lecture
Remphcz ce.ritrole
par yos_ ntrs - -
Remplacez cet'indicateur
pr vos rti ; ,>
Sorties
[rF7
100
:................"" l^'
q
G
rafcet edite
status
q
Ct
al
Nombre d'entrees
du systme
Figura 4.4. Contidos do VI que proporciona a estructura dunha aplicacin GrafcetView (versin multitarefa).
4.2.1.2. O editor Grafcet

Ao ser unha librara para LabView, o GrafcetView non dispn dun editor Grafcet propio,
senn que proporciona un conxunto de VIs, controis e tipos de datos que permiten editar
modelos Grafcet utilizando as facilidades proporcionadas polo ambiente grfico do LabView.
4.2.1.2.1. Estructuras de control
GrafcetView incle controis para todos os elementos sintcticos bsicos do Grafcet, coa
excepcin das estructuras de comezo e fin de seleccin de secuencia, que son realizadas
mediante a conexin dunha etapa a mltiples transicins ou de mltiples transicins a unha
etapa, respectivamente. Estes controis permiten modelar todas as estructuras de control bsicas
do Grafcet e, ademais, as estructuras de comezo e fin de paralelismo poden utilizarse de forma
flexbel, o que permite editar estructuras complexas.
113
A librara tamn soporta algunha das extensins sintcticas como as etapas (e transicins)
fonte/sumidoiro ou as macroetapas. Unha etapa pode utilizarse conectndoa s a transicins
anteriores na secuencia de control (etapa sumidoiro), s a transicins posteriores (etapa fonte)
ou sen conectala a ningunha transicin. O mesmo acontece coas transicins, coa excepcin de
que unha transicin si ten que estar conectada a, cando menos, unha etapa. De non ser as o
GrafcetView o considera un erro de sintaxe. Durante as probas comprobouse que as transicins
fontes non eran interpretadas correctamente ao non ser consideradas como validadas en todo
momento.
Existen algunhas limitacins que afectan edicin dos Grafcets anda que son de pouca
importancia: os controis de comezo e fin de paralelismo non poden conectarse a mais de catro
secuencias de control diferentes ( preciso aniar varios controis cando se precisan mais); e os
arcos orientados que van en sentido contrario secuencia de control (de abaixo a enriba) teen
que conectar sempre unha transicin a unha etapa.
4.2.1.2.2. Estructura xerrquica
A utilizacin de macroetapas basease nas funcionalidades do LabView para crear VIs

mediante o capsulamento dos programas definidos polo usuario. Nos VIs creados deste xeito
pode editarse tanto a icona que os representa graficamente como as conexins que
proporcionan aos VIs de nivel superior. Utilizando este mecanismo poden crearse subgrafcets
que agrupen calquera estructura que se utilice de forma habitual e definir as conexins
utilizando catro tipos de datos includos na librara. Estes tipos permiten identificar as
conexins entrantes e santes e detectar automaticamente as que non cumpran coa regra de
alternancia etapa-transicin.
Se ben este mecanismo ten a avantaxe de ser moi flexbel, responsabilidade do usuario que
as estructuras agrupadas cumpran coas regras definidas no estndar IEC 60848 para as
macroetapas. Ademais non se inclen as mesmas opcins de identificacin para as macroetapas
que para as etapas.
No que respecta s particins do Grafcet, posbel utilizar o mtodo anterior para capsular
mltiples grafcets conexos e formar un grafcet parcial. Do mesmo xeito que aconteca coas
macroetapas, isto non deixa de ser unha utilizacin especfica dunha funcionalidade
proporcionada polo LabView, e calquera caracterstica adicional (como a identificacin dos
grafcets parciais) ten que ser implementada polo usuario. Ademais a librara non incle ordes
de forzado, polo que non posbel modelar unha xerarqua de forzado.
No GrafcetView cada etapa pode ter asociada unha accin na que as sadas se indican
mediante a notacin S,,, separndoas con vrgulas no caso de querer activar varias
simultaneamente. As accins poden levar asociada unha condicin na que, mediante os
operadores do lxebra de Boole: AND (.), OR (+) e NOT (-), poden editarse expresins
booleanas que contean entradas (E), varibeis de etapa (X) e temporizacins sobre varibeis
de etapa (t^/X/t2). O seguinte un exemplo de accin condicional na que se activan das
sadas:
S3, S4 si (E4+20/X2/50).-X3
As receptividades teen unha sintaxe que consta de das partes: un evento e unha condicin,
separados pola palabra reservada èt'. Ambas partes son opcionais, e a ausencia simultnea
dambas equivale a unha receptividade sempre certa. A condicin segue a mesma sintaxe que a
114
explicada para as accins condicionais; encanto ao evento, este pode ser un flanco ascendente
(A^ ou descendente (D) aplicado a unha entrada, varibel de etapa ou temporizacin sobre unha
varibel de etapa. Algns exemplos de receptividades son os seguintes:
ME3 et (X2+E0)
D30/X4/60 et 10/X2/50
DXS et -ES.-X 12
Como pode deducirse da sintaxe de accins e receptividades, posbel mediante

GrafcetView editar accins continuas, condicionais, limitadas e demoradas no tempo. Non se
inclen as accins impulsionais nin as memorizadas. Ademais a sintaxe das receptividades
garante que non poidan producirse èfectos colaterais' durante a sa avaliacin.
4.2.1.2.4. Identificacin
Co GrafcetView s posbel asociar identificadores s etapas e estes deben ser numricos.

Non se incle ningunha opcin de renumeracin nin se actualiza esta automaticamente durante
a edicin do modelo para evitar duplicados. Tampouco se incle soporte para a numeracin de
macroetapas ou a identificacin de Grafcets parciais.
4.2.1.2.5. Anlise sintctica
O GrafcetView realiza a anlise sintctica dos modelos en das fases. Durante a edicin
identificanse as conexins que non cumpren a regra de alternancia etapa-transicin, as etapas
sen numerar ou os arcos orientados sen conectar; e unha vez que comeza a interpretacin do
modelo detctanse os erros de sintaxe nas accins e receptividades, os identificadores de etapa
duplicados ou as transicins non conectadas.
Un aspecto orixinal do GrafcetView consiste en que cada etapa responsbel da anlise
sintctica da accin que ten asociada (e cada transicin da sa receptividade). Isto posbel
porque tanto as etapas como as transicins estn implementadas mediante controis (un tipo de
VI) e, polo tanto, son realmente programas G representados no modelo mediante unha icona.
4.2.1.2.6. Simulacin e execucin
Os modelos Grafcet desenvolvidos co GrafcetView poden simularse e executarse do mesmo

xeito que calquera outro programa en LabView. Sen embargo a divisin entre implementacin
(diagrama de bloques) e interface de usuario (panel) dos programas LabView non permite a
animacin da evolucin dos modelos Grafcet directamente sobre a sa estructura. Existen das
alternativas (Figura 4.5) para conseguir a animacin do marcado das etapas activas:
1. Debuxar a estructura do grafcet nun panel de usuario e situar sobre o grfico os indicadores
de estado das etapas.
2. Utilizar dous indicadores que a librara incle para mostrar os identificadores e o estado das
etapas nos paneis de usuario durante a execucin dos modelos.
O primeiro tipo de interface require que o usuario debuxe a estructura do grafcet e site
sobre ela os indicadores de etapa. Isto implica que un cambio no modelo require volver a
debuxar a estructura e volver a situar os indicadores. En canto segunda interface, fcil de
editar e modificar pero non sigue as recomendacins do estndar IEC 60848 e, no caso de
grafcets complexos (con moitas etapas ou mltiples grafcets conexos), resulta complicado
interpretala. Ningn dos dous tipos de solucins completamente satisfactoria, mais en
115
contrapartida, o LabView facilita a edicin de interfaces de usuario nas que se mostre o estado
do proceso e que inclan controis e indicadores que permitan interactuar con el.
4.2.1.2.7. O algoritmo de interpretacin
GrafcetView utiliza un algoritmo de interpretacin de tipo ARS, no que as accins son

executadas unicamente nas situacins estbeis, e detecta e avisa da existencia de ciclos
estacionarios. Os eventos externos foron considerados como eventos na escala interna, e os
eventos internos foron tratados internamente (4.1.2.1, caso l.a).
En canto s probas para comprobar a resposta diante de conflictos entre accins, no
GrafcetView unicamente ten sentido realizar a segunda (4.1.2.2). O resultado obtido foi que a
aplicacin non considerou coma un erro a existencia de mltiples temporizacins activas sobre
a mesma varibel, e na sada obtvose un valor equivalente aplicacin da disxuncin lxica
das accins activas.
Figura 4.5. Das posbeis interfaces para a animacin das evolucins dun grafcet no GrafcetView.
4.2.1.3. Conclusins
GrafcetView unha librara que permite a utilizacin de modelos Grafcet como parte das
aplicacins LabView. Incle soporte a todas as estructuras de control bsicas, permite o uso .
flexbel das seleccins de secuencia e paralelismo e a utilizacin de etapas (transicins)
fonte/sumidoiro. A estructuracin xerrquica basease nas capacidades do LabView para o
capsulamento dos programas, non se inclen ordes de forzado e queda baixo responsabilidade
do usuario a utilizacin correcta das macroetapas e Grafcets parciais. Mediante unha sintaxe
simple poden editarse accins continuas, condicionais, limitadas e demoradas no tempo. Nas
condicins e receptividades poden utilizarse tanto temporizacins coma eventos. A anlise
sintctica realizase en das fases e a interpretacin dos modelos de tipo ARS con deteccin de
ciclos estacionarios, considerando os eventos externos como eventos na escala interna e
resolvendo os conflictos entre accins mediante a disxuncin lxica das accins activas.
En conclusin, GrafcetView permite engadir o control secuencial de forma simple nas
aplicacins LabView. tamn unha excelente ferramenta para a aprendizaxe e o prototipado
rpido de aplicacins, xa que LabView facilita enormemente o desenvolvemento de interfaces
de usuario, a adquisicin de datos, a interaccin con equipos de proceso e o intercambio de
informacin con outras aplicacins. Entre os puntos febles pdense citar: o soporte limitado
estructuracin xerrquica dos modelos, a imposibilidade de animar as evolucins dos Grafcets
116
sobre a sa estructura, os problemas no uso de flancos coas varibeis de etapa e a aplicabilidade

limitada da librara ao depender do ambiente LabView.
4.2.2. MachineShop
MachineShop o nome co que a empresa CTC Parker Automation comercializa un
conxunto de aplicacins para o desenvolvemento de sistemas SCADA en arquitecturas PC con
sistema operativo Windows. O aspecto grfico do MachineShop o dunha barra de tarefas no
escritorio de Windows (Figura 4.6) dende a que poden xestionarse os proxectos de
automatizacin, a comunicacin cos sistemas remotos e a creacin e modificacin dos
programas de control e interfaces de operador.
Figura 4.6. Interface da barra de tarefas do MachineShop.
4.2.2.1. Compoentes
O programa para a definicin da interface de operador denomnase Interact, e est formado
por numerosos "drivers" de comunicacin e mdulos que proporcionan as funcionalidades
precisas para implementar un sistema SCADA. Entre os mdulos mais relevantes poden
citarse:
l. O editor de paneis de operador, que permite editar interfaces que contean elementos
grficos como botns, grficas, indicadores, etc.
2. O editor de animacins grficas, que permite inclur animacins grficas nos paneis de
operador.
3. O xestor de alarmas, receitas, histricos e informes, mdulos que proporcionan paneis
predefinidos para as opcins habituais nun SCADA en cada unha destas funcins.
4. A configuracin de mquinas, que permite xestionar a carga e descarga de parmetros de
configuracin nos equipos de control.
5. A transferencia de datos, que permite configurar a transferencia de datos a alta velocidade
entre diferentes equipos de control en aplicacins multicontrolador.
6. As comunicacins, mdulo que permite compartir a informacin das aplicacins Interact
con outras aplicacins a travs de NetBios ou DDE.
Ademais destes mdulos predefinidos, pode engadrselle aplicacin un programa de
usuario que realice actividades adicionais. Este programa actvase mediante interrupcins e
intercambia datos cos outros mdulos a travs dun rea de memoria compartida.
A aplicacin para o desenvolvemento do "software" de control denomnase MachineLogic
(Figura 4.7) e sigue s recomendacins do estndar IEC 61131-3. A versin de MachineLogic
analizada neste apartado a 2.01. Esta versin incle un ambiente de execucin en tempo real
no que poden simularse e depurarse os programas, e conta con "drivers" de E/S para buses de
campo Profibus e DeviceNet. A interface do MachineLogic incle numerosas caractersticas
que facilitan o seu manexo: barras de botns, mens flotantes, xanelas que poden fixarse nos
bordes do area de traballo, organizacin de mltiples xanelas mediante lapelas, asistentes
edicin dos programas, etc. O elemento principal da aplicacin a rbore do proxecto dende a
117
que se ten acceso s opcins principais de edicin. Cada proxecto ten catro compoentes
principais:
1. As POUs, que poden ser de tres tipos: programas, funcins e bloques funcin dacordo ao
definido no estndar IEC 61131-3. Cada POU divdese en tres partes: a descricin, a
declaracin de varibeis e a implementacin, que pode codificarse utilizando calquera das
linguaxes IEC: IL, ST, LD, FBD ou SFC.
2. Os tipos de datos do usuario: estructuras, arranxos e cadeas de caracteres definidos dacordo
ao estndar IEC 61131-3.
3. A configuracin hardware, que describe a estructura do sistema de control segundo 0
modelo "sof^ware" definido no estndar IEC 61131-3. O sistema pode conter varias
con^guracins, cada unha delas pode ter un ou mais recursos, e en cada recurso declranse
as varibeis globais, configranse os dispositivos de E/S e exectanse unha ou mais
tarefas. Cada tarefa executa unha ou mais POUs utilizando para cada unha un dos tres tipos
de planificacins soportados: cclica, de sistema ou de evento.
4. As libraras, que permiten a reutilizacin de POUs entre proxectos.
O editor do MachineLogic est orientado edicin de SFCs que contean unha nica rede
cclica na que non pode haber mais dunha etapa inicial. Utilzase a aproximacin mais comn
neste tipo de editores consistente en dividir o rea de traballo en filas e columnas e inclense a
maiora das opcins de edicin habituais nun ambiente grfico: seleccionar, mover, eliminar,
desfacer os cambios, zoom, etc. O editor permite a insercin, eliminacin e desprazamento dos
nodos da rede unicamente se se mantn a sa correccin sintctica e non se incumpre a
restriccin de ter unha nica rede SFC.
Ao tratarse dun editor SFC, o MachineLogic ofrece soporte unicamente aos elementos
sintcticos bsicos do Grafcet, anda que tamn incle a posibilidade de utilizar etapas
sumidoiro para terminar secuencias de control non cclicas. O editor non permite o cruce de
lias e a utilizacin de seleccins de secuencia e paralelismo s pode facerse mediante
estructuras completas que comecen por un inicio de seleccin de secuencia (paralelismo) e
rematen cun final de seleccin de secuencia (paralelismo). Esta restriccin non permite modelar
estructuras flexbeis.
Est pennitida a utilizacin de ciclos e saltos de secuencia, sendo posbel iniciar mltiples
ciclos ou saltos dende un mesmo punto da secuencia de control mediante a utilizacin dunha
seleccin de secuencia. Ademais o editor permite definir unha etapa como etapa de salto a
outra etapa. O identificador da etapa de salto ten que coincidir co da etapa que se salta, anda
que o programa non controla durante a compilacin que esta exista.
O editor non permite definir unha estructura xerrquica entre SFCs. A estructuracin do
proxecto realzase a nivel de POU, seguindo as recomendacins do estndar IEC 61131-3.
O MachineLogic incle todos os tipos de accins IEC: N, R, S, P, L, D, DS, SD ou SL, e

penmite utilizar as linguaxes IL, ST, FBD e LD para implementar o seu contido. Os
118
identificadores das accins sen cdigo son utilizados como varibeis booleanas e o seu valor
modificado durante a activacin da etapa dacordo ao tipo de accin do que se trate.
As receptividades tamn poden implementarse utilizando as mesmas linguaxes que para as
accins. No caso de utilizar LD ou FBD, a implementacin da receptividade pode facerse
directamente no editor SFC. Entre os FBs dispobeis hai contadores, temporizadores,
biestbeis e detectores de flancos, e tamn pode utilizarse o estado de activacin das etapas
(coa sintaxe step,,.J^ no cdigo de receptividades e accins. O programa non impide a edicin
de receptividades que produzan èfectos colaterais' durante a sa avaliacin.
ê ^d3 Vew ^ro'êct Bulld
o^^î,^ ^^
yout OPfine Ophar>; ]îrtd
;^^f ^'^_:'^^^
j^^.l^^ l
^ 1 ^;^__ I II,^ ^^, ^'^ ^'^
^ -^,; ^ ,^ ^ ^ ^ f ^î;
-^ Project
; - ^J Libraries
--d DataTypes
p-^ LogicalPOUs
p Q main
value
.END_VAR
I2^Tr .= 0;
VAR_EX1'ERNAL (*AUTOINSERTt)
BOOL;
.
input0
BOOL;
.
inputl
END_VAR
^^
^ mainV
^ main
+- i'^, Transitions
q
+p--d Actions
p-^ Physical Hardware
p-!^ Configuration
p-^ Resource
^ Geating_A Project
p+-^ Tasks
'--^`p Global Variables
--^ 10_Configuration
^ Cr^rrint ^.;
!Vtiable (LEF )^'< ^ POU^^n/aksheet ^Âccess ^ Camrnad ^ TyPe
ACTION
;
main.main
^ A001
ACTION
main.mam
^ A002
BOOL
inputup.inputup
Read
II
^`pinput0
BOOL
main.main
Read
6^pinput0
^ -:,.{^'^
^`
r^ inout0 _ ..
mammain
=-_Read ._ __ . ,^,_.800^, ^
For He1p oeys F1 .,
.;, ^
^^
^_ ^^ ^
^ ^_
^48215'^C ^1^164.3MB^^
Figura 4.7. Interface do MachineLogic.
O MachineLogic permite a asignacin de identificadores alfanumricos nicos a etapas,

transicins e accins sen que existan conflictos entre eles ( posbel ter unha etapa, unha
transicin e unha accin co mesmo identificador). O programa detecta os identificadores
duplicados durante a compilacin.
A anlise sintctica faise en das fases, durante a edicin dos SFCs o editor non permite o
cruce de lias nin operacins que incumpran a regra de alternancia etapa-transicin. O resto de
comprobacins realzanse durante a compilacin do proxecto. O nico problema atopado foi a
non comprobacin da existencia da etapa destino nas etapas de salto.
119
O MachineShop incle un subsistema implementado sobre unha extensin ao sistema

operativo DOS, denominada RTXDOS, que proporciona capacidades multitarefa e de tempo
real. Este subsistema est formado por un compilador, un xestor da execucin das tarefas de
control que emula o funcionamento dun PLC, un depurador, un xestor de erros e os "drivers"
de E/S e comunicacins. Dende o MachineLogic pdense configurar, compilar, descargar,
simular e depurar en tempo real as POUs do proxecto. Durante a execucin disponse de
numerosas opcins para a depuracin e monitorizacin dos programas: inicio e parada de
recursos, monitorizacin e forzado de varibeis, animacin grfica dos elementos das redes LD,
FBD e SFC, modificacin "on-line" das POUs (con certas restriccins), simulacin de E/S, etc.
4.2.2.2.7. O algoritmo de interpretacibn
O algoritmo de interpretacin utilizado no subsistema en tempo real do MachineLogic de

tipo SRS, executndose as accins tanto en situacins estbeis como inestbeis. Os resultados
das probas realizadas para comprobar o funcionamento do programa cando hai conflictos entre
accins (4.1.2.2) foron os seguintes: no caso (l.a) a sada mantivo o valor 0, o que indica que
a accin R tivo prioridade sobre as demais segundo o definido no estndar IEC 61131-3; no
caso ( l.b) o programa non considerou que a situacin dada fose errnea e a sada tomou o valor
resultado da disxuncin lxica das accins activas; e, por ltimo, os casos (l.c) e(l.d)
tampouco foron considerados coma erros e varibel asignronselle valores de forma errtica
mentres as accins estiveron activas.
4.2.2.3. Conclusins
O MachineShop unha aplicacin para o desenvolvemento de sistemas SCADA composta
por tres compoentes principais: un ambiente de execucin en tempo real, un editor (o
MachineLogic) para a implementacin de programas de control, e un editor (o Interact) para a
interface de usuario e demais aspectos do sistema (alarmas, receitas, histricos, etc.). O
MachineLogic un ambiente grfico que sigue as recomendacins do estndar IEC 61131-3 e
incle numerosas opcins para estructurar o"software" e configurar o"hardware", as
comunicacins e os dispositivos de E/S dun proxecto. Para a programacin das POUs pdense
utilizar todos os tipos de accins e linguaxes IEC, e as opcins de simulacin e depuracin son
moi completas: monitorizacin e forzado de varibeis, definicin de puntos de parada
("breakpoints"), animacin do estado dos SFCs, simulacin das E/S, etc.
En canto s caractersticas Grafcet que o MachineLogic implementa, estas limtanse s
includas na definicin do SFC coa nica extensin sintctica das etapas sumidoiro. Non se
permite a estructuracin xerrquica dos SFCs, o algoritmo de interpretacin de tipo SRS e
non se manexan correctamente os conflictos entre accins en todos os casos analizados. En
resume, o MachineShop unha aplicacin moi completa que facilita o desenvolvemento de
sistemas SCADA en arquitecturas PC con sistema operativo Windows. Un inconveniente da
aplicacin que o subsistema de execucin en tempo real non portbel e funciona unicamente
en equipos co sistema operativo DOS instalado. No que respecta ao Grafcet, o MachineLogic
non aporta ningunha caracterstica nova, limitndose a implementar o SFC dacordo ao estndar
IEC 61131-3.
120
4.2.3. IsaGraph
O IsaGraph da compaa AlterSys33 unha das aplicacins de desenvolvemento de soflware
de control mais populares no mercado da automatizacin industrial. Pioneira na aplicacin do
concepto de automatizacin aberta (consistente na aplicacin dos principios do software aberto
automatizacin industrial), permite o desenvolvemento de aplicacins independentes do
sistema final no que vaian executarse. O nico requisito a dispoibilidade dunha versin do
ambiente de execucin do IsaGraph para ese sistema concreto. A versin da aplicacin aqu
analizada a 4.10. Esta versin soporta mltiples ambientes de execucin distribudos en
diferentes equipos interconectados mediante unha ou mais redes de comunicacins, as como a
posibilidade de incorporar un servidor "web" no sistema de control.
4.2.3.1. Compoentes
O IsaGraph unha aplicacin complexa que incle numerosas funcionalidades e opcins. A
sa arquitectura de alto nivel divdese en tres compoentes principais:
1. O ambiente de desenvolvemento, con versins para Windows 98, 2000 e NT, proporciona
soporte configuracin do sistema de control e codificacin, simulacin e execucin do
seu "software". A arquitectura dos proxectos sigue as recomendacins do estndar IEC
61131-3: cada configuracin IEC correspndense no IsaGraph cun nodo fisico que executa
unha ou mais mquinas viriuais. Cada mquina virtual executa un recurso (o equivalente a
un PLC virtual) e a sa versin determina as redes de comunicacins, dispositivos de E/S,
funcins C e bloques funcin dispobeis. En cada recurso configranse as POUs e datos
que contea, os parmetros de execucin, as comunicacins e os dispositivos de E/S. A
compoente principal do ambiente de desenvolvemento o Xestor de Proxectos, dende o
que se accede ao resto de opcins da aplicacin. Entre as mais importantes destacan:
a. O editor "hardware ", no que se configura o"hardware" do sistema de control: os
parmetros das configuracins, das redes de comunicacin e das conexins, a
asignacin de recursos a cada configuracin, as propiedades de execucin de cada
recurso, etc.
b. O editor de enlaces entre recursos, no que se editan os recursos e a definicin dos
enlaces34 para o intercambio de informacin entre eles. Para cada recurso mstranse as
POUs, datos e parmetros mediante unha estructura de rbore dende a que pode
accederse aos editores do cdigo das POUs. IsaGraph soporta todas as linguaxes IEC
mis os diagramas de fluxo.
c.
O diccionario do proxecto, no que se edita a informacin do proxecto, que est

organizada en catro categoras: parmetros de funcins e bloques funcin, varibeis,
tipos de datos e macros definidas polo usuario.
d.
O editor da configuracin de E/S, no que se edita a asignacin de varibeis aos canais

de E/S. Este editor incle opcins para engadir e eliminar dispositivos de E/S,
configurar os parmetros de cada canal, asignar e eliminar varibeis, etc.
33 O IsaGraph foi desenvolvido inicialmente pola compaa CJ International. Debido ao seu xito comercial foi
absorbida pola A1terSys, distribuidora do Virgo Automation Studio e lder na comercializacin de productos
softPLC e softDCS. A versin actual do IsaGraph o resultado da integracin dambos productos, da adaptacin s
recomendacins do estndar IEC 61131-3 e do abandono comercial da denominacin Virgo.
3a O concepto de enlace semellante ao de acceso ("access path") definido no estndar IEC 61131-3. A principal
diferencia que os enlaces intercambian informacin entre recursos que poden estar ou non na mesma
configuracin. Os accesos son para intercambios entre recursos de diferentes configuracins.
121
2.

A mquina virtual ou ambiente de execucin, no que se executan as aplicacins compiladas
no ambiente de desenvolvemento. Esta mquina est deseada para ser facilmente portbel,
existindo versins para moitos dos sistemas operativos mais coecidos, as como para
diferentes tipos de equipamentos de control. A portabilidade da mquina basease na
definicin de catro interfaces que abstraen os detalles propios de cada sistema: ,
a. A interface de comunicacins, utilizada para a depuracin e a comunicacin da
mquina virtual con outros sistemas como SCADAs, HMIs, PLCs, etc.
b. A interface de E/S, para o intercambio de informacin co proceso mediante tarxetas de
E/S, buses de campo, etc.
c.
A interface de sistema, que abstrae os servicios do sistema operativo para a xestin de

temporizadores, memoria, etc.
d.
A interface de aplicacin, que proporciona acceso a funcins C e bloques funcin que

permiten aumentar as funcionalidades da mquina virtual.
3. As ferramentas de soporte, orientadas aos usuarios avanzados que queiran adaptar a

mquina virtual a un novo sistema ou incorporar novas funcionalidades.
O editor do IsaGraph (Figura 4.8) est orientado edicin de SFCs que contean mltiples
redes nas que non se restrinxe o nmero de etapas iniciais en cada rede. Utilzase a
aproximacin mais comn neste tipo de editores consistente en dividir o rea de traballo en
filas e columnas e inclense as opcins de edicin habituais nos ambientes grficos:
seleccionar, mover, copiar, eliminar, desfacer os cambios, zoom, etc.
Ao tratarse dun editor SFC s ofrece soporte aos elementos sintcticos bsicos do Grafcet. A
utilizacin das seleccins de secuencia e paralelismo flexbel mais non o suficiente como para
modelar estructuras complexas que inclan semforos, debido a que o editor non permite a
conexin directa entre un inicio de seleccin de secuencia e un final de paralelismo ou entre un
inicio de paralelismo e un final de seleccin de secuencia.
Os ciclos e saltos de secuencia poden representarse graficamente mediante arcos orientados
ou mediante referencias de salto. O programa controla que as conexins que se realicen desta
maneira cumpran a regra de alternancia etapa-transicin. Se se queren iniciar mltiples saltos a
diferentes etapas dende un mesmo punto da secuencia de control pode utilizarse unha estructura
de inicio de seleccin.
O IsaGraph aporta unha solucin propia que non coincide con ningunha das
recomendacins dos estndares IEC, poden establecerse relacins de subordinacin entre as
POUs codificadas con SFC dividndoas en das categoras:
1. Os SFCs principais, activados polo sistema ao comezo da execucin.
2. Os SFCs dependentes, cuxa execucin controlada polos SFCs dos que dependen.
A Tboa 4-I resume as cinco accins que controlan a execucin dun SFC dependente. Con
este mecanismo poden implementarse funcionalidades semellantes, ainda que mis limitadas e
non equivalentes semanticamente, s das ordes de forzado ou aos "enclosure steps" êfinidos
na ltima revisin do estndar Grafcet [85]-.
122
O IsaGraph non incle todos os tipos de datos nin de accins definidos polo estndar IEC
61131-3. En concreto permite accins dos tipos: N, R, S, PO e P 1 (non incle accins
temporizadas) e divdeas en das categoras:
1. As que poden programarse mediante unha das linguaxes IL, ST ou LD (tipos N, PO ou P 1.).
2. As booleanas (tipos R, S e N), que poden utilizarse para activar e desactivar o valor de
varibeis booleanas ou nomes de SFCs (equivalen s accins GSTART e GKILL).
En canto s receptividades, poden programarse mediante IL, ST ou LD e poden utilizarse as
funcins booleanas e FBs dispobeis, entre os que hai contadores, temporizadores, biestbeis e
detectores de flancos. O IsaGraph non impide os èfectos colaterais' que poidan producirse
durante a avaliacin das receptividades, e define das varibeis para cada etapa - o estado de
activacin (stepn.J^ e o tempo de actividade (step,,.T}- cuxos valores poden ser utilizados no
cdigo de accins e receptividades.
, ^^
S^
, ^ ,.
_,^,X
S Boo InitOk.
I
'^`f --' P1 ST resetTre
- _ ^ I ' r.i , sT
ST T1
ComplexTest(OK1,M y
nuelReset) AND
R^_tnndio^
Stop^.al ^
Figura 4.8. Interface do editor SFC no IsaGraph.
GSTART
GKILL
GFREEZE
GRST
GSTATUS
Activa as eta as da situacin inicial do SFC de endente.
Desactiva todas as eta as activas no SFC de endente.
Memoriza a situacin actual do SFC de endente.
Activa as eta as da ltima situacin memorizada.
Consulta o estado do SFC de endente activo, sus endido ou inactivo .
Tboa 4-I. Accins que controlan a execucin dos SFCs dependentes no IsaGraph.
O IsaGraph numera automaticamente as etapas e transicins dos SFCs asignndolles

identificadores alfanumricos nicos (S para as etapas e T para as transicins), e permite que
sexan modificados polo usuario. A unicidade dos identificadores unicamente obrigatoria en
cada SFC, e a deteccin de identificadores duplicados realzase durante a compilacin do
123
programa. Algunhas caractersticas relacionadas coa identificacin que facilitan a edicin de

SFCs son:
1.
2.
A renumeracin automtica de etapas e transicins a peticin do usuario.

A renumeracin automtica durante as operacins de copia para evitar duplicados.
Ambas opcins actualizan conrectamente as referencias de salto e a primeira dlas tamn

actualiza conrectamente as varibeis de etapa utilizadas no cdigo de accins e receptividades.
A anlise sintctica faise en das fases, durante a edicin comprobase que as conexins
cumpran coa regra da alternancia entre etapas e transicins e durante a compilacin realzase a
anlise sintctica completa.
O IsaGraph incle opcins para a compilacin, simulacin e depuracin das aplicacins.

Pode compilarse un proxecto completo, un recurso ou unicamente unha POU. A compilacin
pode xerar un cdigo intermedio independente do sistema (TIC), ou ben cdigo C que pode ser
includo nas libraras da mquina virtual. Durante a simulacin os recursos son emulados
mediante mquinas virtuais que se executan no mesmo computador que o ambiente de
desenvolvemento. A interaccin co proceso realizase a travs de paneis de E/S dende os que se
poden visualizar, modificar e forzar os valores das varibeis, entradas e sadas. Entre outras
opcins dispobeis, durante a simulacin pode verse graficamente o estado de activacin das
etapas, indicar puntos de parada ("breakpoints"), forzar o franqueamento de transicins, etc.
Para a depuracin da aplicacin preciso descargar previamente os recursos compilados nas
mquinas virtuais definidas durante a configuracin do sistema. Estas mquinas teen a
capacidade de almacenar o cdigo dos recursos en disco, o que penmite recuperalos
posteriormente dende o ambiente de desenvolvemento ou iniciar a sa execucin de forma
autnoma (sen descarga previa). Entre as opcins que as mquinas virtuais proporcionan
durante a depuracin poden citarse: o inicio e parada de recursos, a execucin continua ou ciclo
a ciclo, a informacin de estado (tempos de ciclo, varibeis de estado) e a diagnose dos
recursos.
A mquina virtual do IsaGraph executa os programas utilizando un algoritmo de

interpretacin de tipo SRS. Nas probas realizadas para comprobar a resposta do IsaGraph
cando varias accins modifican simultaneamente unha mesma varibel (4.1.2.2), os resultados
foron os seguintes: no caso (l.a) a sada mantivo o valor 0, o que indica que a accin R tivo
prioridade sobre as demais dacordo ao definido no estndar IEC 61131-3; os casos (l.b) e(l.c)
non foron analizados pois o IsaGraph non ten accins temporizadas; e, por ltimo, o caso (l.d)
non foi considerado coma un erro, asignndoselle valores de forma non determinista varibel
mentres as accins estiveron activas.
4.2.3.3. Conclusins
O IsaGraph unha das aplicacins que con mais xito aplica os conceptos de
automatizacin aberta e"SoftPLC". O ncleo da aplicacin est formado por unha mquina
virtual facilmente portbel, que emula a arquitectura lxica dun PLC sobre calquera equipo que
dispoa dun sistema operativo multitarefa. O desenvolvemento dos proxectos realzase dende
124
un ambiente grfico que incorpora parte das recomendacins do estndar IEC 61131-3 no
referente estructura da aplicacin e programacin das POUs. Dende este ambiente pdense
editar mltiples parmetros relacionados coa configuracin "hardware", arquitectura
"soflware", comunicacins e interfaces de E/S; programar, compilar e depurar as POUs de cada
recurso; descargar o cdigo compilado nas mquinas virtuais e monitorizar a sa execucin.
Para a programacin das POUs, pdense utilizar todas as linguaxes IEC e mis os diagrama de
fluxo.
En canto s caractersticas do Grafcet includas no IsaGraph, limtanse implementacin
dunha versin do SFC: non se incle ningunha das extensins sintcticas do Grafcet, a
estructura xerrquica non sigue as recomendacins dos estndares IEC, non se inclen todos os
tipos de accins IEC, o algoritmo de interpretacin de tipo SRS e non se manexan
correctamente os conflictos entre accins. En resume, o IsaGraph unha aplicacin moi
completa para o desenvolvemento de proxectos de automatizacin en sistemas distribudos que
incle unha potente mquina virtual que facilita a creacin de "software" portbel. No que
respecta ao Grafcet, o IsaGraph non aporta ningunha caracterstica nova, limitndose a
implementar unha versin do SFC se exceptuamos a posibilidade de definir unha estructura
xerrquica entre SFCs que non se axusta ao definido nos estndares Grafcet.
4.2.4. PL7
O PL7 unha aplicacin da empresa Schneider Automation para a programacin de PLCs
da marca Telemecanique dende PCs co sistema operativo Windows. O ambiente grfico do
programa sigue as directrices do estndar IEC 61131-3 adaptadas s caractersticas dos PLCs
que soporta. A versin analizada a PL7 Pro v3.1, que permite traballar cos PLCs das series
TSX Micro e TSX Premium.
4.2.4.1. Compoentes
A compoente principal da aplicacin o navegador, no que se organiza o proxecto de
automatizacin nunha estructura de tipo rbore. Dende este navegador tense acceso a todas as
demais funcionalidades do programa: definicin da estructura dos programas, definicin das
varibeis e tipos de datos, programacin, compilacin e depuracin das POUs, configuracin
dos PLCs e da comunicacin, documentacin dos programas, etc. A aplicacin tamn incle un
editor cunha librara de obxectos grficos (bombas, depsitos, motores, etc.) para crear
interfaces de operador simples.
A execucin dos programas nos PLCs TSX das series Micro e Premium pode facerse tanto
en modo monotarefa como multitarefa, dependendo das capacidades de cada equipo concreto.
En calquera caso sempre existe unha tarefa principal, denominada MAST, que pode executarse
cclica ou periodicamente. Nas configuracins multitarefa poden engadirse ademais tarefas de
alta prioridade para a xestin rpida de eventos externos ou a realizacin de operacins que
requiran un perodo inferior ao da tarefa MAST. Todas as tarefas divdense en seccins e
subprogramas (que poden ser chamados dende as seccins ou dende outros subprogramas).
Cada seccin pode programarse utilizando as linguaxes IEC: IL, LD, FBD ou ST. Ademais,
nalgns PLCs pode inclurse na tarefa MAST unha seccin adicional programada con Grafcet.
Esta seccin divdese en tres partes: o tratamento previo, o tratamento secuencial e o tratamento
posterior. Os tratamentos previo e posterior poden programarse con IL, ST ou LD e serven para
realizar operacins de iniciacin e finalizacin do proceso secuencial executado polo grafcet.
125

O editor Grafcet do PL7 (Figura 4.9) est orientado edicin de mltiples grafcets conexos
cclicos. Utiliza a opcin de dividir o rea de traballo en filas e columnas (reservando as filas
impares para as transicins e as pares para as etapas) e soporta as operacins bsicas de edicin
nun ambiente grfico: seleccionar, mover, copiar, eliminar, zoom, etc. O tamao do rea de
traballo est limitado a oito pxinas de 154 celas cada unha, organizadas en catorce filas e once
columnas. O editor tamn limita o nmero de etapas, transicins e macroetapas que poden
utilizarse dependendo do PLC escollido.
^^
------.-----------------^^
.
('Initial step^ ,
0
('Start o( cycle conditions^
(^Feeding box filling up^
MO
a
^
4
^Ìnitial step^
(`Mixer filling up7
('End o( proportioning^
T
(`Mixing and emptying^

M1
^L
^^ ^T.^;'jtEi+n `^n, ,Fr ^
^J
I('MAIN GRPPH')
: _ -- :_ . ;. _
^^
-^^
^r ^ ^R ^^^+ n^ ^F^ imn
1Q^b
^14ê
Figura 4.9. Editor Grafcet do PL7.
O editor Grafcet do PL7 soporta a edicin de mltiples grafcets conexos cclicos que
contean calquera das estructuras de control bsicas. O uso das seleccins de secuencia e
paralelismo flexbel, anda que a divisin do rea de traballo en filas e columnas limita en
certos casos a complexidade das estructuras que poden editarse. Os ciclos e saltos de secuencia
poden representarse mediante arcos orientados ou mediante pares de frechas que indican a
orixe e o destino do salto, estando permitido inclur mltiples saltos a diferentes etapas dende
un mesmo punto da secuencia de control.
Dependendo do modelo concreto de PLC, o editor permite a utilizacin de macroetapas nos

modelos e incle soporte estructura xerrquica que estas forman. O lmite de aniamento das
126
macroetapas de oito niveis, e a estructura icerrquica que forman pode verse no avegador da
aplicacin. O programa controla que cada macroetapa s sexa utilizada unha vez e que non
existan recursividades nin ciclos na estructura xerrquica. As etapas de entrada e sada nas
expansins das macroetapas denomnanse IN e OUT respectivamente, e s a etapa IN pode ter
accins asociadas. As macroexpansins non estn limitadas a unha nica estructura conexa que
comece na etapa de entrada e remate na de sada, senn que poden conter varios grafcets
conexos, sempre e cando as etapas de entrada e sada sexan nicas.
O PL7 permite a utilizacin nas accins e receptividades dos elementos de memoria dos
PLCs Telemecanique: entradas, sadas, varibeis de sistema, varibeis de estado dos FBDs e
Grafcets, etc. Tamn poden utilizarse os FBDs predefinidos que inclen contadores,
temporizadores e biestbeis. Unha parte da memoria de sistema resrvase para manter os
parmetros de configuracin do Grafcet e a informacin sobre o estado e tempo de activacin
de cada etapa durante a execucin. O programa permite a modificacin destas varibeis na
seccin de tratamento previo do grafcet mediante a utilizacin de instruccins SET e RESET.
As etapas poden ter asociadas tres accins, unha de activacin (tipo PO), unha continua (tipo
N 1) e unha de desactivacin (tipo P 1), que poden ser programadas mediante as linguaxes IL,
LD, FBD ou ST. A documentacin do programa indica que as accins N1, anda que se
denominen continuas, son tratadas como accins memorizadas e ser preciso activalas e
desactivalas explicitamente mediante instruccins SET e RESET nas accins PO e P 1 para
limitar o seu efecto duracin dunha etapa.
As receptividades tamn poden ser programadas coas mesmas linguaxes, anda que o PL7
restrinxe as caractersticas que poden ser utilizadas para evitar os èfectos colaterais' durante a
sa avaliacin.
O PL7 s permite asignar identificadores numricos s etapas e non incle opcins de

renumeracin durante as operacins de copia. O programa detecta os duplicados durante a
verifcacin sintctica e permite, cando se utilizan macroetapas, que o mesmo identificador
sexa utilizado en macroexpansins distintas.
A anlise sintctica faise en das fases, durante a edicin do modelo comprobase o

cumprimento da regra de alternancia etapa-transicin. A anlise completa realzase durante a
fase de verificacin sintctica unha vez rematada a edicin.
O PL7 non incle a posibilidade de simular os programas, e a sa depuracin e

monitorizacin en tempo real require descargalos previamente no PLC. Inclense opcins que
durante a depuracin permiten ver e forzar o valor dos elementos de memoria do PLC, ver
graficamente a animacin do estado dos programas (includo o grafcet) e realizar accins
relacionadas coa depuracin da seccin Grafcet, como a suspensin da evolucin do modelo ou
o forzado dunha situacin especfica.
127
O algoritmo de interpretacin do PL7 de tipo SRS, o propio do modo de funcionamento

cclico nos PLCs. As probas para comprobar a resposta do programa cando varias accins
modifican simultaneamente unha mesma varibel (4.1.2.2) non puideron facerse no PL7 ao
non dispor o programa dun simulador.
..
4.2.4.3. Conclusins
O PL7 unha aplicacin para a programacin de PLCs da marca Telemecanique que
permite a utilizacin das linguaxes IL, LD, FBD, ST e Grafcet. O programa incorpora algunha
das recomendacins do estndar IEC 61131-3 e incle editores para configurar o"hardware" e
os dispositivos de E/S, estructurar e programar o"soflware", definir varibeis, depurar e
monitorizar os programas, documentar a aplicacin, etc.
No referente ao Grafcet, o PL7 permite editar mltiples grafcets conexos que contean
macroetapas. A estructura das macroexpansins non est limitada a un nico grafcet conexo,
anda que si ten que ter unha nica etapa de entrada e outra de sada. Non se incle ningunha
outra extensin sintctica e s as etapas poden ter identificadores. Cada etapa ten tres accins
asociadas de tipos xa predefinidos, non se soportan os tipos de accins do estndar IEC e o
algoritmo de interpretacin de tipo SRS. En conclusin, o PL7 e unha aplicacin que
proporciona mltiples opcins para a programacin e monitorizacin de PLCs Telemecanique.
A versin de Grafcet que incle permite unha estructura xerrquica de macroetapas pero non
soporta os tipos de accins IEC. O programa carece dun simulador e a sa aplicabilidade
limitada.
4.2.5. Visual I/O e Visual PLC

O Visual UO e o Visual PLC son aplicacins da empresa ArSoft International para o
desenvolvemento e execucin de programas de control e as sas interfaces. As versins
analizadas neste apartado son de demostracin, a 4.02 do Visual PLC e a 3.09 do Visual UO.
4.2.5.1. Compoentes
O Visual UO consiste nun ambiente de desenvolvemento de interfaces grficas Windows
que integra un compilador Pascal e que incle un conxunto de caractersticas adicionais que
penmiten sa aplicacin en tarefas de control: programacin con LD, FBDs ou Grafcet,
xestin de alanmas, histricos e receitas, "drivers" de E/S para buses de campo (ModBus,
ProfiBus) e PLCs (Unitelway, Omron), etc. O Visual PLC consiste nun mdulo softPLC que
permite a execucin en `tempo real' dos programas desenvolvidos co Visual UO. Dende ambos
programas poden utilizarse libraras que inclen funcins para o manexo do tempo, arquivos de
texto, dispositivos multimedia, bases de datos, impresin, comunicacins serie, etc.
Visual UO e Visual PLC inclen un editor Grafcet (Figura 4.10) no que a rea de traballo
est dividida en filas e columnas e que permite as operacins bsicas de edicin nun ambiente
grfico: seleccionar, mover, copiar, eliminar, desfacer, zoom, etc. A comprobacin do
cumprimento da regra de alternancia etapa-transicin realzase durante a edicin dos modelos,
pero durante as probas comprobouse que o editor permita a edicin de estructuras non
admitidas polo estndar, quedando baixo a responsabilidade do usuario a edicin de Grafcets
sintacticamente correctos.
128

O editor permite a edicin de mltiples grafcets conexos sen estructura xerrquica, que
inclan as estructuras de control bsicas, ademais de permitir a utilizacin de etapas
(transicins) fontes e sumidoiro. Nas probas comprobouse que o editor non considera coma
erro que unha transicin sexa vez fonte e sumidoiro e durante a execucin as transicins fonte
non se comportaron coma se estiveran sempre validadas. A colocacin das etapas iniciais est
restrinxida primeira fila35 do rea de traballo e as seleccins de secuencia e paralelismo poden
utilizarse de forma flexbel, permitndose a edicin de estructuras complexas. Sen embargo
tamn poden editarse estructuras incorrectas (Figura 4.10) que non son detectadas durante a
anlise sintctica. Os ciclos e saltos de secuencia fanse mediante referencias de salto podendo
iniciarse mltiples saltos dende o mesmo punto da secuencia de control.
i^
._^ ._
^- .Y^__ ^ ..
+
---^ ^.^. -
^j ^X
+
^ True
^ True
+
+
^
^
True
^ F True
+
+
^ True
^
True
True
+
+
+
u.
(^
ti
Figura 4.10. Editor Grafcet do Visual UO e Visual PLC.

Os grafcets permitidos polo Visual UO non teen estructura xerrquica. O que si permite o
programa modificar o estado de activacin das etapas directamente a travs das varibeis que
almacenan o seu valor. Anda que isto est prohibido polos estndares IEC, unha maneira de
emular as ordes de forzado. O inconveniente que non se incle soporte deteccin de ciclos
na xerarqua de forzado nin medios de evitar o forzado mltiple dunha situacin.
O contido de accins e receptividades codificado mediante a linguaxe Pascal. O cdigo

edtase nun editor de texto que comproba a correccin da sintaxe ao tempo que se escribe. As
varibeis utilizadas poden ser de calquera dos tipos de datos Pascal e teen que declararse
nunha VPU xunto con todas as outras varibeis do programa: varibeis internas, de entrada, de
sada e de estado. Para cada grafcet definese un conxunto de varibeis que almacenan o valor
do estado, o tempo de activacin e o indicador de activacin (denominado Start Step) de cada
's Anda que despois posbel movelas ou copialas a outras filas, co que a restriccin deixa de ter senso.
129
etapa. O Visual UO permite a modificacin do valor destas varibeis dende o cdigo do

programa, o que est expresamente prohibido polos estndares IEC.
O programa non soporta directamente os tipos de accins IEC, anda que algns poden ser
emulados dende o cdigo mediante a utilizacin das varibeis de estado do grafcet. Por
exemplo, pode limitarse ou demorarse a execucin dunha accin comprobando o valor do
tempo de activacin da etapa que estea asociada (tipos D e L), ou pode executarse un cdigo
determinado no momento da activacin dunha etapa utilizando a varibel Start Step (tipo PO).
Nas receptividades poden utilizarse os operadores lxicos e relacionais do Pascal as como
chamadas a funcins. Sen embargo o programa non incle operadores para a deteccin de
flancos nin para a utilizacin de temporizadores. Tampouco se incle ningn medio de evitar os
èfectos colaterais' que poidan producirse durante a avaliacin das receptividades.
O Visual UO asigna automaticamente identificadores numricos nicos s etapas. O usuario

non pode modificar estes identificadores nin identificar as transicins. O programa incle unha
opcin de renumeracin que actualiza automaticamente os identificadores de etapa para evitar
duplicados. Esta opcin tamn actualiza correctamente as referencias de salto. O editor non
comproba a existencia de duplicados durante a verificacin sintctica do modelo.
A anlise sintctica faise en das fases, o editor comproba o cumprimento da regra de

alternancia etapa-transicin durante a edicin, e a correccin do cdigo de accins e
receptividades durante a compilacin. Sen embargo a comprobacin da correccin sintctica
dos grafcets queda baixo a responsabilidade do usuario, xa que o editor acepta como vlidas
estructuras non estndar ou identificadores duplicados.
O Visual PLC proporciona as opcins precisas para simular ou executar os programas

desenvolvidos co Visual UO. Os programas complanse para xerar VPUs que poden cargarse no
mdulo softPLC do Visual PLC. Este mdulo pode estar no mesmo computador ou nun
computador diferente e a sa interface ofrece informacin sobre os mdulos cargados e o seu
estado. Outras opcins que incle o Visual PLC para a simulacin e depuracin dos programas
son, por exemplo, a visualizacin dos valores das varibeis, a simulacin das E/S, a animacin
grfica do estado do grafcet, etc. Ademais pdense utilizar os valores das varibeis e
animacins do estado do grafcet dende as interfaces de operador desenvolvidas co Visual UO.
O algoritmo de interpretacin utilizado no motor en tempo real do visual PLC de tipo SRS,
executando as accins tanto en situacins estbeis como inestbeis. Os resultados das probas
realizadas para comprobar a resposta do Visual UO cando varias accins modifican
simultaneamente unha mesma varibel (4.1.2.2) foron os seguintes: o caso (l.a) non puido
probarse xa que todas as accins no Visual UO son continuas; e os casos (l.b), (l.c) e(l.d) non
foron considerados coma errneos polo programa, mudando o valor da varibel de forma non
determinista mentres as accins estiveron activas.
130
4.2.5.3. Conclusins
Visual UO e Visual PLC son das aplicacins implementadas partindo dun ambiente de
programacin e desenvolvemento de interfaces grficas Windows utilizando Visual Pascal. A
esta base engadronselle un conxunto de funcins adicionais (programacin en LD, FBD e
Grafcet, xestin de alarmas, histricos e receitas, etc.) para a sa utilizacin no
desenvolvemento de aplicacins de control en PCs. O conxunto compltase cun mdulo
softPLC para a execucin dos programas e"drivers" de E/S para diferentes buses de campo
(ModBus, ProfiBus) e PLCs (Unitelway, Omron).
A versin Grafcet implementada no Visual UO e o soporte proporcionado polo editor son
bastante limitados. S se permiten as estructuras de control bsicas, non se permite unha
estructura xerrquica, non se implementan os diferentes tipos de accins IEC e non se poden
utilizar eventos nin temporizadores (anda que si os tempos de activacin das etapas) nas
condicins. O editor permite a edicin de estructuras Grafcet non estndar ou con
identificadores duplicados, a interpretacin dos modelos de tipo SRS e non se manexan
correctamente os conflictos entre accins. En resume, o Visual PLC aporta unha idea nova
como a de integrar as linguaxes grficas do IEC nun ambiente de desenvolvemento de
aplicacins Windows e proporcionar un mdulo softPLC e"drivers" de E/S para a execucin
dos programas. Sen embargo a versin Grafcet implementada non aporta nada novo e
nalgunhas das caractersticas comentadas nin sequera cumpre aspectos bsicos dos estndares.
4.2.6. AutomGen
AutomGen unha aplicacin da empresa francesa Irai para o desenvolvemento de software
de control que pode executarse en PCs ou PLCs. O programa incle un editor grfico
multilinguaxe (permite utilizar Gemma, Grafcet, loxigramas, organigramas, LD, FBD, IL e
ST), un compilador, un simulador e un editor de pantallas de operador. Para permitir a
portabilidade, AutomGen xera durante a compilacin un cdigo intermedio que traducido
linguaxe propia de cada PLC mediante un post-procesador. A versin analizada a 7.0 de
demostracin.
4.2.6.1. Compoentes
A compoente principal do AutomGen o navegador (Figura 4.11) no que se organizan
mediante unha estructura en forma de rbore todos os elementos que forman parte dun
proxecto: folios (programas), tboas de smbolos, postprocesadores (configuracin
"hardware"), documentacin e outros elementos relacionados coa depuracin e o deseo de
pantallas de operador. Dende o navegador estn tamn dispobeis opcins para seleccionar o
postprocesador a utilizar, acceder librara de estructuras predefinidas para as linguaxes
grficas e editar a lista de smbolos do proxecto. A aplicacin compltase coa posibilidade de
editar e executar a interface grfica mediante un programa externo denominado IRIS, que
permite a animacin de obxectos 2D e 3D.
O AutomGen non incle un editor Grafcet especfico, senn que se utiliza o mesmo para
todas as linguaxes grficas, pudendo definirse mltiples `redes' multilinguaxe en cada folio. Os
folios organzanse en filas e columnas e en cada cela pode inserirse un dos mltiples smbolos
das linguaxes grficas soportadas. O programa permite inserir e eliminar filas e columnas, e
131
soporta as operacins habituais en ambientes grficos: seleccionar, mover, copiar, eliminar,

zoom, etc. Ademais incle das opcins de grande utilidade durante a edicin:
1. Unha librara coas estructuras grficas mis comns de cada linguaxe xa predefinidas, de
xeito que o usuario s ten que seleccionalas e copialas nos folios.
2. Un asistente que permite inserir estructuras complexas mediante a modificacin duns
poucos parmetros sen ter que editalas smbolo a smbolo.
Un caso particular a edicin de folios Gemma [ 121 ], neste caso o folio xa contn un
diagrama de estados predefinido e unicamente hai que modificar os estados, lias de unin e
condicins. O programa incle unha opcin que permite pasar directamente da representacin
Gemma ao grafcet equivalente.
Poden editarse grafcets que contean calquera das estructuras sintcticas bsicas as como
etapas (transicins) fontes e sumidoiro, macroetapas e ordes de forzado. O uso das estructuras
de seleccin de secuencia e paralelismo flexbel, sendo posbel editar estructuras complexas.
Os ciclos e saltos de secuencia poden representarse mediante arcos orientados, e poden
iniciarse varios dende un mesmo punto da secuencia de control mediante unha estructura de
inicio de seleccin. O editor non considera coma erro que unha transicin sexa
simultaneamente fonte e sumidoiro.
P.
(Ê^ Êdmon AK^+^9e^ Eroqenme 4ê Feê
t^ ^ i II fî ;^} ^ ^ e^î ^ ^', .^
^^ ,Îi
. : 1
_^ . ^:
aJ
^_,^^
^^3^14 *^ j ^z^G : ^. :: ,.
r,
-^ R^wces '
^;^j Modul^sadairei ^
il ^ ^_ ^..-: _.^; _.
^^_
^^
ênrtn nt daM>UT04UEt{ lopicier dman i 07"r11]

^^ . O! : aDpliution i leur, exieution ... DassaOe en RUN ... aCtration de la visualWllen dynamiQu! ... tennin.
w (^^ w.â
^`^,^tmEMOSEH
Figura 4.11. Interface do programa Automgen.
132
O AutomGen soporta as das estructuras xerrquicas do Grafcet: a estructural e a de

forzado, anda que non sexa posbel ver ningunha das das no navegador do proxecto. A
utilizacin de macroetapas na xerarqua estructural sigue as seguintes regras:
1. Cada macroetapa pode ser utilizada unha nica vez na secuencia de control.
.,
2. As macroetapas poden aniarse.
3. A macroexpansin ten que definirse nun folio diferente e asociarse macroetapa indicando
o seu identificador nas propiedades do folio.
4. A macroexpansin non est limitada a un nico grafcet conexo, anda que s pode conter
unha nica etapa de entrada e outra de sada.
5. A etapa de entrada ten que usar o identificador 0 ou E e a de sada 9999 ou S,,.
Durante a anlise comprobouse que o AutomGen detecta durante a compilacin as
macroetapas sen expansin e as macroexpansins que conteen mis dunha etapa inicial ou
final. Sen embargo aceptou como correctas macroexpansins sen etapa inicial ou final
(indicouno cun aviso do compilador), coa etapa inicial e a final en grafcets conexos diferentes,
ou macroexpansins con estructuras cclicas (a etapa final conectada inicial mediante unha
transicin).
No referente s ordes de forzado, o programa non incle o concepto de grafcet parcial, mais
si permite o agrupamento de mltiples grafcets conexos mediante unha directiva de
compilacin. Para referenciar un grafcet nas ordes de forzado pode utilizarse o identificador do
grupo ao que pertenza, o identificador de calquera das sas etapas ou o identificador do folio no
que est definido. O uso correcto dos agrupamentos e ordes de forzado deixase baixo
responsabilidade do usuario sendo posbel, por exemplo, inclur un mesmo grafcet conexo en
varios grupos distintos, forzar etapas inexistentes ou definir xerarquas de forzado cclicas.
Ademais do uso estndar das ordes de forzado, AutomGen incle das extensins:
1. As ordes de bloqueo, que son un caso particular das ordes de forzado nas que se bloquea o
estado dun grafcet na sa situacin actual mentres a orde estea activa.
2. As ordes de memorizacin da situacin do grafcet, que permiten almacenar a situacin
actual dun grafcet para utilizala posteriormente nas ordes de forzado.
A Tboa 4-II resume a sintaxe da directiva de agrupamento e das ordes de forzado en
AutomGen.
#G<id^rupo>:<id_grafl>, ..<id-grafN>;
Directiva de agrupamento
F<id^ra^: {<situacin>}
Orde de forzado
F<id^raf>: {}
Forzado dunha situacin baleira
G<idJgra^:<store>
Orde de memorizacin en store da situacin actual
G<id^raf>:^store>{^situacin>}
Orde de memorizacin en store dunha situacin especfica
F<id^raJs:<store>
Orde de forzado da situacin memorizada en store
F<id^raf>
Orde de bloqueo
Tboa 4-II. Sintaxe da directiva de agrupamento e ordes de forzado en AutomGen.
O AutomGen permite utilizar nas accins e receptividades elementos de memoria de tipo

booleano (entradas, sadas, bits de etapa Grafcet, bits do sistema, etc.), numrico (varibeis de
usuario, contadores, etc.) ou temporizadores, mediante unha sintaxe propia ou dacordo
133
sintaxe do IEC 61131-3. O contido das accins pode especificarse mediante sentencias nas
linguaxes IL, ST ou mediante unha das sintaxes da Tboa 4-III, que permiten a modificacin
directa do valor das varibeis. AutomGen implementa os tipos de accins IEC seguintes3: N,
R, S, P1 e P0, ademais incle accins condicionais que xunto cos temporizadores permiten
emular as accins temporizadas L, D e DS do estndar.
,
En canto s receptividades, pode utilizarse nelas calquera elemento de memoria (includas as
sadas); os operadores booleanos AND (.), OR (+) e NOT (^; os de comparacin; eventos (T,^)
en varibeis e expresins; e temporizacins, cunha das sintaxes seguintes:
<duracin>l<var id>lT
Tl<var id>l<duracin>
<duracin>l<var id>
A propia sintaxe das receptividades impide a posibilidade de introducir cdigo que produza
èfectos colaterais' durante a sa avaliacin. Os nicos valores que se modifican son os dos
temporizadores iniciados na receptividade.
^
<var name>
^
booleana, tem orizador Mantn o valor a 1 durante a activacin da eta a
N<var name>
R<var name>
S<var name>
I<var_name>
booleana, tem orizador

todas
booleana, tem orizador
booleana, temporizador
[+^-] <var_name>
numrica, contador
Mantn o valor a 0 durante a activacin da eta a

Posta a 0 do valor memorizado
Posta a I do valor memorizado
Invirte o valor (unha vez por ciclo
durante a activacin da eta a
Incrementa/decrementa en 1 o valor (unha vez por
ciclo durante a activacin da eta a
Tboa 4-III. Sintaxe das accins que modifican directamente o valor dunha varibel no AutomGen.
4.2.6.2.4. Identif cacin
No AutomGen s poden asignarse identificadores numricos s etapas (excepcin feita das

etapas de entrada e sada das macroexpansins que teen unha sintaxe especfica). O programa
non comproba a existencia de duplicados durante a edicin e incle unha opcin para numerar
automaticamente todas ou parte das etapas dun grafcet (sen actualizar os contidos de accins e
receptividades). A utilizacin de identificadores alfanumricos, as etapas sen identificador, as
varibeis de etapas inexistentes e os identificadores duplicados son detectados durante a
compilacin.
A verificacin sintctica realzase durante a compilacin dos folios. A nica asistencia

previa compilacin que proporciona o programa durante a edicin de accins e
receptividades. Esta realzase mediante un cadro de dilogo composto de das partes: unha na
que se edita o cdigo que o programa marca con diferentes cores a medida que comproba a sa
correccin sintctica, e outra na que se proporciona acceso sintaxe dos elementos de memoria
e accins as como aos smbolos do proxecto.
36 Na documentacin indcase que se soportan tamn os tipos L, D, SD, DS e SL, mais a versin do programa
analizada non permitiu utilizar estes cualificadores.
134
Durante as probas comprobouse que o compilador do AutomGen acepta como correctas as

macroexpansins sen etapa inicial ou final (indcao cun aviso), coa etapa inicial e a final en
grafcets conexos diferentes ou con estructuras cclicas (a etapa final conectada inicial
mediante unha transicin); permite o agrupamento dun grafcet conexo en varios grupos
distintos, o uso de etapas inexistentes nas directivas de agrupamento e nas ordes de forzado, a
existencia de varias directivas de agrupamento cun mesmo identificador de grupo e non dete ta
as xerarquas de forzado cclicas nin os forzados mltiples.
O AutomGen permite a simulacin e a monitorizacin en tempo real dos programas. O

editor incle opcins para compilar, descargar e executar de forma continua ou paso a paso os
programas, visualizar e forzar o valor das varibeis, animar graficamente nos folios os valores
de etapas, varibeis e temporizadores, simular as entradas, etc. Co postprocesador adecuado
pode executarse o cdigo directamente no PC ou descargalo nun PLC (hai dispobeis
postprocesadores para un grande nmero de fabricantes: Omron, Telemecanique, Siemens,
etc.). Dende o postprocesador PC poden utilizarse "drivers" para diferentes sistemas de E/S
(tarxetas de adquisicin de datos, buses de campo, etc.) e tamn pode configurarse o modo de
funcionamento (peridico ou continuo) e o tempo mximo de ciclo permitido.
O algoritmo de interpretacin utilizado no postprocesador PC do AutomGem de tipo ARS

sen deteccin de ciclos estacionarios (cando o grafcet entra nun ciclo estacionario 0
comportamento do sistema deixa de ser determinista). Durante as evolucins internas do
modelo os eventos externos foron considerados coma eventos na escala interna e os eventos
internos tratronse internamente (4.1.2.1, caso l.a). Ademais comprobouse que a pesar de
utilizar un algoritmo ARS, todas as accins, ordes de forzado e bloqueo son executadas tanto
nas situacins estbeis como nas inestbeis, o que significa que o programa non diferencia
entre accins internas e externas.
Tamn se atoparon algns problemas durante a comprobacin da aplicacin da xerarqua de
forzado (4.1.2.3):
1. No grafcet da Figura 3.37, partindo da situacin {1, 10, 20, 30}, ao producirse o evento Ta
a evolucin foi {1, 10, 20, 30}-^{2, 11, 21, 32}, o que indica que a evolucin estructural (o
franqueamento da transicin 10) tivo prioridade sobre a aplicacin da orde de forzado da
etapa 21.
2. No mesmo grafcet, cando se produce o evento Tb na situacin {2, 11, 21, 32}, a evolucin
foi {2, 11, 21, 32}-^{3, 11, 21, 32}-^{3, 11, 22, 32}, do que se deduce que ao deixar de
estar activa a orde de forzado da etapa 2 e activarse a etapa 3 pode franquearse a transicin
21, mais isto tamn desactiva a orde de forzado da etapa 21 o que provocara o
franqueamento da transicin 32, o cal non acontece.
En resume, no AutomGen a aplicacin das ordes de forzado non ten prioridade sobre as
evolucins estructurais e non se aplica recursivamente a xerarqua de forzado.
En canto aos conflictos entre accins, AutomGen define unha tboa de incompatibilidades
que se reproducen na Tboa 4-IV. Cando o programa detecta algunha destas incompatibilidades
durante a compilacin indcao mediante un aviso. Polas probas realizadas dedcese que o
programa da o aviso mesmo se non hai posibilidade de que as accins conflictivas estean
135
activas simultaneamente, polo que responsabilidade do usuario determinar se o posbel

conflicto existe realmente ou non.
Continua
Continua
N
S
R
I
X
X
X
X
N
X
S
X
X
R
X
X
I
X
X
X
X
X
Tboa 4-IV. Incompatibilidades entre accins definidas por AutomGen
Esta incompatibilidade non afecta s probas realizadas (4.1.2.2) para analizar a resposta do
programa cando varias accins modifican simultaneamente unha mesma varibel, xa que isto
pode acontecer entre accins que a priori son compatbeis. Os resultados para o AutomGen
foron os seguintes: no caso ( l.a) a sada mantivo o valor 1, o que indica que a accin R non
prioritaria sobre as demais en contra do definido no estndar IEC 61131-3; o caso ( l.b) non foi
considerado coma un erro e a sada tomou o valor resultado da disxuncin lxica das accins
activas; e, por ltimo, os casos ( l.c) e(l.d) tampouco foron considerados coma erros, e a
varibel tomou diferentes valores mentres as accins estiveron activas.
4.2.6.3. Conclusins
O AutomGen unha aplicacin de desenvolvemento de software de control para PC e unha
ampla gama de PLCs. O programa soporta un grande nmero de linguaxes: Gemma, Grafcet,
loxigramas, organigramas, LD, FBD, IL e ST, e incle opcins para a configuracin do
"hardware" e dos dispositivos de E/S, a edicin, compilacin, descarga, control e depuracin en
tempo real da execucin dos programas, a animacin das linguaxes grficas, a monitorizacin e
forzado de varibeis durante a depuracin, etc. Ademais tamn pode editarse unha interface
grfica para a supervisin do proceso que pode executarse mediante un programa externo
denominado IRIS.
En canto ao Grafcet, o AutomGen moi completo soportando case todas as caractersticas
definidas polos estndares IEC. Entre os aspectos negativos atopados durante as probas poden
citarse: s as etapas poden ter identificadores (numricos); permtense macroexpansins sen
etapa inicial ou final e con estructuras cclicas; non se incle o concepto de grafcet parcial,
anda que se permite o agrupamento de grafcets conexos; as ordes de forzado poden conter
etapas inexistentes; a xerarqua de forzado pode conter ciclos; non se soportan directamente as
accins temporizadas do IEC; o algoritmo de interpretacin de tipo ARS mais non detecta
ciclos estacionarios e a deteccin de conflictos entre accins limitada. En resume, o
AutomGen unha excelente aplicacin que destaca polo nmero de linguaxes que incle, a
gama de PLCs e sistemas de E/S que soporta e as capacidades de animacin grfica durante a
simulacin dos programas. Implementa case todas as caractersticas do Grafcet e o nico dos
programas analizados que ofrece soporte ao estndar Gemma.
4.2.7. Actwi n
ActWin unha aplicacin da empresa sueca Actron para a implementacin de proxectos de
automatizacin con PLCs da empresa Hitachi dende un PC con sistema operativo Windows. O
programa incle opcins para configurar os PLCs, configurar as comunicacins e dispositivos
de E/S, editar o diccionario, os programas e a documentacin do proxecto, cargar o proxecto no
136
PLC e monitorizar o seu funcionamento en tempo real. O ambiente de desenvolvemento sigue

en parte as especificacins do estndar IEC 61131-3 e as linguaxes permitidas para a
programacin son todas as do estndar menos a ST. A aplicacin tamn incle un "driver"
softPLC que permite depurar e executar os programas no propio PC sen necesidade de dispor
dun PLC. A versin do ActWin analizada a 3.26 de demostracin.
4.2.7.1. Compoentes
Tres son as principais compoentes da arquitectura do ActWin:
1. O ambiente de desenvolvemento (Figura 4.12), que unha aplicacin Windows que sigue
as recomendacins do estndar IEC 61131-3 e proporciona as opcins precisas para a
configuracin, programacin, documentacin, depuracin e monitorizacin do proxecto.
Dentro deste ambiente as principais opcins estn dispobeis a travs de tres editores:
a.
b.
c.
O editor do proxecto, no que se organizan mediante unha estructura en forma de rbore

os diferentes elementos que compoen un proxecto: configuracin do "hardware" e
dispositivos de E/S, POUs, tboas de smbolos, libraras de FBs e outras opcins
relacionadas coa impresin e a monitorizacin do proxecto.
O editor de smbolos dende o que se editan as propiedades dos smbolos utilizados no
proxecto.
Os editores de programas nos que se editan as POUs utilizando as linguaxes IL, LD,
FBD e SFC.
O ambiente compltase cun corixunto de dilogos que facilitan a edicin da configuracin

"hardware", a asignacin de smbolos a puntos de E/S, a escolla de instruccins,
operadores e smbolos durante a edicin dos programas, etc.
2.
3.
Os "drivers " PLC, que implementan para os PLCs soportados as funcins que permiten a
sa configuracin, a dos dispositivos de E/S e comunicacins, a carga e descarga de
programas e smbolos, a monitorizacin dos programas, etc. Ademais dos "drivers" das
diferentes versins de PLCs Hitachi, ActWin incle un "driver" softPLC co que poden
executarse os programas no PC e emular o sistema de control sen necesidade de dispor dun
PLC. Este "driver" incle caractersticas como: a posibilidade de traballar como "master"
con distintos buses de campo (Profibus-DP, Interbus-S, CANOpen ou DeviceNet); a
monitorizacin e forzado de varibeis en tempo real; ou a modificacin "on-line" dos
programas.
As ferramentas para a programacin de "drivers ", orientadas a aqueles usuarios
avanzados que queiran desenvolver "drivers" para dar soporte a novos PLCs.

O editor do ActWin (Figura 4.12) est orientado edicin de mltiples redes SFC cclicas
que contean unha nica etapa inicial. Ao comezar a edicin, no rea de traballo aparece unha
rede mnima composta por unha etapa inicial, unha transicin e un ciclo. Durante a edicin s
est permitido inserir novos elementos en puntos concretos do SFC nos que se mantea a sa
correccin sintctica. A cada rede poden asocirselle das condicins para controlar a sa
execucin:
1. A condicin de activacin, que mentres sexa falsa `conxela' o estado da rede.
2. A condicin de reinicio, que ao activarse devolve a rede sa situacin inicial.
137
O editor soporta as opcins de edicin mis comns nos ambientes grficos: inserir, mover,
copiar e eliminar redes ou elementos das redes, zoom, etc. e incle unha opcin que permite
traducir automaticamente os SFCs a LD.
O ActWin unicamente permite a utilizacin dos elementos sintcticos bsicos do Grafcet. As

redes SFC editadas teen que ter unha estructura cclica e non poden conter mis dunha etapa
inicial. As estructuras de seleccin de secuencia e paralelismo non poden ser utilizadas de
forma flexbel, permitndose unicamente a edicin de estructuras completas. Poden inserirse
tamn ciclos (mediante referencias de salto) e saltos de etapa, sendo posbel iniciar mltiples
ciclos ou saltos dende un mesmo punto da secuencia de control.
O editor non permite definir unha estructura xerrquica entre SFCs. A estructuracin do
proxecto realzase a nivel de POU, seguindo as recomendacins do estndar IEC 61131-3.
..._ T ____^. _ _
^._.
_
-
f ,
(^ : -^ ^
----
'
'
^^:
^
F^'
I^
^
i
.^ ^
,
I: ^
ii
^
!, ;
^ .
tII
`
I '
( ^., ,
`
i
i
^_ _
;
i .-
i.
i
S
`' i
ê^
^
^-^"^S
Î
^ P`rt settrt^3s
^ Q SYstem tnary
': p_d [âchi H-series]
p..^ ^sf^^^
O[] [^C-êl
0-d [^^-sPedf^^l
^- llsa Ebrary
-
, ^
^^
r ^ y^j . ( . ^1
:
'
1
r, . -^ __.,._.____^.-_.^.^..., ^t--- r-,-^

------- -^----^r.^---`;^ Fm He^ Pters F7
-
e ^;
'^,
-^.
,.
,Y.
. .
..
^^_
4^
-^
. . . , , ,
o
^,
^
.
a.
,^^ ?
-
^;,
_ ^
'
.:
. , ^- ^ >.
..
^ 's^
,^^ . ;^_. .
7 -^ .^_r^
^ ( to
-.^^^
^,
,.
Î:,
^
. ^ ^T'^
.^ ..
:
^^
--
^, r._
!^..^:U:a.
- . . __ ' .
t ^ __ .. ,
[f
e
_i
^Cordroi
^ ^;.,
^
, , . ^'
^ i ,^
^.
^ 6W MOndOt
,,
;-
[
{^ t ^
-'
^' ^-^
^
^-xi
Corrd ot Upper Caiêyx.

Catrid ts done 6y e Ledder
dla9ram
pl ^r^
^r
^^
Pktwork 5
.. .
],
--^ Date memaY
[^
, Contrd oi trerisport sysfam

Conveyor erid LKt.
--Ol ^
^ ^,,,v+
^
-^
^
^-
ma^n
Network
'(^ ^9nd
`- ^ llp^rConveyorCordrd
p Hardwere confi9watfon [H ecF^ H-series]
q ^g5M-4
,
PSM-A2
^Ô
rj ^ r+25x (cPtm-o2HC) [meiN
ACTANA-S2
_^^ PIM-0W
....
POM.RH
i^
^^
^^ ;
i,
r
t
^ rl 'y^
-^ X ^ ^
;
'
^+. [] SYmbds
^^^
^f î
..
n ', kf I 81 Bt^^ 8j ^.'-
^
^^ ^
^
^^^^,^=^^
^^^^_ ^^. ^^_^>
- .^ -_; _-^ -
..
=q x
^ p r? Project Sfc demo
.,a;x
.
a
. ^_,; .: -.
^.^ . Eae _Et:zxiew jm^rt>;:9Perafioru ^"SortnrâGon^ I^ ^ciôw^.tleb ..., ;.
^`^ i`^ ^ ;^ ^ (^ ^' ^G ^C: '^ X ris ^ S^ ^^ Î^`^ ^ '^tF ^r ^, ^. ^,aa `^ ^ t4: ^ ^t2 I 1
`,,
^^
,, `
j^
^`
'
^ F^
^.
^,
^:
^, ^ ^
r
' -o
- *^.
^
^_
_.._
{
.__
_ .^..__-- - - --- -
-^ :
-,,_ .._,_ _
_.. ^ ^ ^
z,- : _
..
^.^l^ 3 ^ F^ ._^S
.I_eit
t'
_-
,,
": - ' -. . -J^ ;

-----
^:^rt.^ ..^^^^û _
`
^^ X ^
`.
._..
_ _
.
. . .^ ^ . ^'
-- -^- --- -
.
l dr
.
:
.
IEC rddrew
-,
Tl^
.
^ .. .
.. .PLC addr ,CammeiR
I,_ _
.
r.......
..
BOOL
%Mi A2 = ' R2
; ' - L ' St 1 X
I i..L-, stert_BWOn
%112
' f:
BOOL
X00102
' F=L. PE_id_Corneyor BOOL
9N1.4
X00104
BOOL
%11.6
: fL^ Lift Low
X00106
.^ ^ '
L` Litt_Fisp^
9Nt.8
BOOL
XOQ108 _
`'
-_.^^
..
.
=_^--_
_
.
.
; ^
_
.
-.^--
-..
,
.
^
,
.
t=
:
.._____
i .
..
,
r . k.
-_
' .- -=--r^-_ _-_<
- - -- - - - - -- _ :--L---- -- _
^- --_._ .-^, _ - - ----- -- ^ - -^-_ ^
-- ^ M'uedmode ^ OB^Sne ^^ f/
-1^ (^JrLtit ^ ^ . M 1 Q
Figura 4.12. Interface da aplicacin ActWin.
O ActWin soporta todos os tipos de datos bsicos e formatos de direccionamento definidos

no estndar IEC 61131-3. O programa permite escoller entre traballar utilizando a
nomenclatura IEC ou a especfica de cada PLC. Cada etapa pode conter mltiples accins que
poden ser de calquera dos tipos IEC: N, R, S, P, L, D, DS, SD e SL. As accins poden ter
138
asociado un smbolo booleano, que ser modificado durante a activacin da etapa, ou ser
programadas mediante a linguaxe LD. O mesmo pode dicirse das receptividades, que poden ter
asociado un smbolo booleano ou unha condicin lxica en LD. Nos diagramas LD poden
usarse os FBs predefinidos que inclen temporizadores e contadores. O programa non impide a
edicin de receptividades que produzan èfectos colaterais' durante a sa avaliacin.
O ActWin s permite asignar identificadores alfanumricos s etapas e s accins ou

condicins LD. Os identificadores poden coincidir con calquera outro smbolo xa que, para
evitar duplicados, a aplicacin define internamente os smbolos <step_id>.X para as etapas e
<action_id>.Q para as accins. Por defecto utilzanse para as etapas identificadores co formato
S_x, sendo n o identificador da rede SFC e x o da etapa. O programa actualiza
automaticamente os identificadores e referencias cada vez que se insire ou elimina unha nova
rede ou etapa e controla a existencia de duplicados durante a edicin. Cada programa ten a sa
propia tboa de smbolos, polo que os identificadores poden repetirse en SFCs diferentes.
O propio proceso de edicin do ActWin impide que se editen estructuras SFC incorrectas,
que se utilicen identificadores duplicados ou se asignen os smbolos a puntos de E/S
incorrectamente. Ademais o programa incle tamn unha opcin de verificacin sintctica que
realiza a comprobacin da correccin do proxecto antes de descargalo no PLC.
A aplicacin incle as opcins precisas para a carga e descarga de proxectos no PLC, o

intercambio de informacin de configuracin e de estado, a monitorizacin e forzado dos
valores das varibeis, a animacin dos elementos grficos nos diagramas LD, FBD e SFC, a
modificacin "on-line" dos programas, etc. Ademais a dispoibilidade dun "driver" softPLC
permite executar os programas no propio PC simulando os dispositivos de E/S, o que permite
depurar os programas sen necesidade de dispor dun PLC.
O algoritmo de interpretacin do "driver" softPLC do ActWin de tipo SRS. A resposta do

ActWin, nos diferentes casos probados cando varias accins modifcan simultaneamente unha
mesma varibel (4.1.2.2) foi a seguinte: no caso (l.a) a sada mantivo o valor 0, o que indica
que a accin R tivo prioridade sobre as demais dacordo ao definido no estndar IEC 61131-3; o
caso (l.b) non foi considerado coma un erro e a sada tomou o valor resultado da disxuncin
lxica das accins activas; e, por ltimo, os casos (l.c) e(l.d) tampouco foron considerados
coma erros, e varibel asignronselle valores de forma errtica mentres as accins estiveron
activas.
4.2.7.3. Conclusins
O ActWin unha aplicacin que sigue as recomendacins do estndar IEC 61131-3 para a
programacin de PLCs Hitachi dende PCs con Windows. O programa incle opcins para a
configuracin "hardware" dos PLCs, a definicin de smbolos e a sa asignacin a puntos de
E/S, a edicin e verificacin dos programas, a descarga dos proxectos nos PLCs, o control e
monitorizacin da sa execucin, a visualizacin e forzado de varibeis durante a depuracin,
139
etc. A aplicacin completase cun "driver" softPLC que permite executar os programas no
propio PC e ferramentas para o desenvolvemento de "drivers" para soportar novos PLCs.
Dende o punto de vista do Grafcet, o ActWin implementa o SFC dacordo ao definido no
estndar IEC 61131-3. Polo tanto s permite utilizar as estructuras de control bsicas, non
incle soporte xerrquico, o algoritmo de interpretacin de tipo SRS e non manexa
correctamente os conflictos entre accins. En resume, no ActWin destaca o fcil que resulta a
edicin dos programas e configuracin dos smbolos gracias aos dilogos que guan ao usuario,
e o alto grao de conformidade co estndar IEC 61131-3. Ademais a aplicabilidade da aplicacin
non se limita unicamente programacin de autmatas Hitachi, xa que o"driver" softPLC
pode configurarse como "master" de diferentes buses de campo, o que permite realizar o
control directamente dende o PC.
4.2.8. WinGrafcet
O WinGrafcet unha aplicacin Windows desenvolvida polo Centro Rexional de
Documentacin Pedagxica do Languedoc-Roussillon en colaboracin co Centro de Formacin
Tecnolxica de Montpellier, para o desenvolvemento de programas de control secuenciais
mediante Grafcet. A versin analizada a versin 1.01 de demostracin.
4.2.8.1. Compoentes
A aplicacin est formada por un editor grfico, un verificador sintctico, un simulador e un
monitor en tempo real compatbel con mltiples interfaces de E/S (AM 1, AM2, IP 16,
Approtech, Technologie Service, Ipocaen, etc.).
O editor Grafcet do WinGrafcet (Figura 4.13) est orientado edicin de mltiples grafcets
conexos e permite as operacins bsicas de edicin nun ambiente grfico como: seleccionar,
mover, copiar, eliminar, zoom, etc. A rea de traballo divdese en filas e columnas, podendo
inserirse en cada cela un dos elementos sintcticos bsicos do Grafcet. O editor incle unha
opcin para detectar e eliminar as estructuras non conexas antes de realizar a verificacin
sintctica, e os smbolos utilizados poden verse en dous niveis de descricin diferentes.
O editor facilita a edicin de mltiples grafcets conexos que contean calquera dos
elementos sintcticos bsicos do Grafcet. Non se incle ningunha das extensins sintcticas nin
soporte estructura xerrquica. Non est permitido que as lias se crucen e as estructuras de
seleccin de secuencia e paralelismo non poden utilizarse de forma flexbel, o que impide a
edicin de grafcets complexos. Poden utilizarse ciclos e saltos de secuencia que son
representados mediante referencias de salto. Est permitido iniciar mltiples saltos ou ciclos
dende un mesmo punto da secuencia de control.
O WinGrafcet non incle soporte estructura xerrquica do Grafcet.

O WinGrafcet define diferentes elementos de memoria que poden ser utilizados en accins e
receptividades: entradas (e0-ell), sadas (s0-s^, varibeis internas (v0-v99), temporizadores
140
(t0-t19) e contadores (c0-c19). Os nomes destes elementos estn predefinidos e non posbel
modificalos. A cantidade de elementos dispobeis de cada tipo depender da interface de E/S
da que se dispoa, aspecto que controlado polo programa durante a verificacin sintctica.
O editor permite unicamente accins continuas cunha das sintaxes da Tboa 4-V. Nas
receptividades poden utilizarse os valores de entradas, varibeis, contadores, temporizadores, e
o estado das etapas relacionados mediante operadores booleanos, de comparacin e^^ de
deteccin de flancos. O intento de modificacin dunha sada dende unha receptividade
detectado polo programa durante a verificacin sintctica impedndose as os èfectos
colaterais'.
irhier
Edition
E^ment
Affichage
Optiotts ,4ryde
Cliquer sur la llle de;dpi
Figura 4.13. Interface do editor Grafcet do WinGrafcet.
S;
Activar unha sada booleana
C;(valor)
C;++, C;-
Iniciar un contador
V;(valor)
Iniciar unha varibel interna
T;
Iniciar un temporizador
Incrementar/decrementar un contador
Tboa 4-V. Sintaxe das accins en WinGrafcet
No WinGrafcet s poden asignarse identificadores numricos s etapas. O programa incle

unha opcin de renumeracin automtica que pode ser utilizada para evitar identificadores
duplicados (esta opcin non actualiza os contidos das receptividades). Tampouco se renumeran
automaticamente as etapas ao copiar nin se controla a existencia de duplicados durante a
edicin, anda que si durante a verificacin sintctica.
O editor incorpora un verificador sintctico para realizar a comprobacin da correccin do

modelo Grafcet. Non se realiza ningunha comprobacin durante a edicin.
141
O WinGrafcet incle un simulador para a depuracin dos programas. As evolucins son

controladas polo usuario a travs dunha interface na que se simulan as entradas mediante
botns e as sadas mediante indicadores luminosos. Durante a simulacin pode consultarse a
informacin sobre a situacin do modelo, ver os valores das varibeis internas e rnodificar a
velocidade da simulacin.
A execucin dos programas faise nun monitor en tempo real que permite conectar o PC ao
proceso mediante diferentes interfaces de E/S (AM 1, AM2, IP 16, Approtech, Technologie
Service, Ipocaen). Na versin de demostracin analizada a opcin de monitorizacin en tempo
real est desactivada, polo que non foi posbel comprobar o seu funcionamento.
O algoritmo de interpretacin do WinGrafcet de tipo SRS, executndose as accins tanto

en situacins estbeis como inestbeis. Debido a que na versin de demostracin a opcin de
simulacin s permite simular un exemplo que ven co programa, non foi posbel realizar as
probas para comprobar a resposta do programa cando varias accins modifican
simultaneamente unha mesma varibel.
4.2.8.3. Conclusins
O WinGrafcet unha aplicacin para a edicin de programas de control secuencial mediante
Grafcet. Est formado por un editor grfico, un verificador sintctico, un simulador e un
monitor en tempo real que permite realizar o control co PC conectado directamente ao proceso
mediante diferentes interfaces de E/S. Os Grafcets editados non incorporan ningunha das
extensins sintcticas nin inclen soporte estructuracin xerrquica. S se permiten accins
continuas cunha sintaxe propia e o algoritmo de interpretacin de tipo SRS. En resume, o
WinGrafcet unha aplicacin til para o ensino e o control mediante PC de procesos simples,
que implementa unha versin bsica do Grafcet na que unicamente poden utilizarse estructuras
bsicas e accins continuas.
4.2.9. Graf7-C
O Graf7-C unha aplicacin realizada con fines educativos polo Centre Collgial de
Dveloppement de Matriel Didactique do Canada, para o desenvolvemento de programas de
control mediante o uso conxunto do Grafcet e a linguaxe C. A versin analizada a 2.1 para o
sistema operativo DOS.
4.2.9.1. Compoentes
A aplicacin est formada por un editor, un analizador sintctico, un compilador, un
traductor, un simulador e un monitor en tempo real.
O editor Grafcet do Graf7-C (Figura 4.14) traballa en modo texto e soporta as operacins
bsicas de edicin: seleccionar, mover, copiar, eliminar, zoom, etc. Permite a edicin de
mltiples grafcets conexos distribudos en catro pxinas de 255 filas por 255 columnas,
reservando as filas impares para as etapas e as pares para as transicins. Os grafcets poden
visualizarse en tres niveis diferentes de detalle: documentacin, programacin e cdigo C, e a
correccin sintctica das estructuras editadas comprobada durante a edicin.
142

Para a edicin dos grafcets poden utilizarse todas as estructuras de control bsicas e algunha
das extensins sintcticas: etapas (transicins) fontes e sumidoiro, macroetapas e ordes de
forzado. O uso das estructuras de seleccin de secuencia e paralelismo flexbel, pudendo
editarse estructuras complexas. Os ciclos e saltos de secuencia poden representarse mediante
arcos ou mediante referencias de salto, e poden iniciarse varios ciclos ou saltos dende' un
mesmo punto da secuencia de control. O editor non considera coma erro que unha transicin
sexa simultaneamente fonte e sumidoiro. Ademais o editor permite a utilizacin doutros
elementos sintcticos non estndar:
1. As tarefas, que son unha alternativa s macroetapas en PLCs programados mediante
diagramas de contactos.
2. As ordes de bloqueo, que son un caso particular das ordes de forzado que bloquean o
estado dun grafcet na situacin actual mentres a orde estea activa.
O Graf7-C soporta as das estructuras xerrquicas do Grafcet: a formada polas macroetapas

e a formada polas ordes de forzado. As macroetapas son utilizadas unha nica vez na secuencia
de control, poden aniarse, est permitida a asociacin de accins tanto s etapas de inicio e fin
da macroexpansin como s macroetapas (caracterstica non estndar), e as macroexpansins
teen que comezar por unha nica etapa de inicio e rematar por unha nica etapa final. Sen
embargo, durante as probas detectouse que o editor unicamente comproba que os
identificadores das macroetapas (MX), das etapas de inicio (EX) e de fin (Sx) da macroexpansin
sexan nicos, sendo posbel a edicin de macroexpansins incorrectas (sen etapa de inicio ou
fin), e a existencia de macroetapas en macroexpansin ou viceversa.
En canto s ordes de forzado, o editor non incle o concepto de grafcet parcial polo que
estas limtanse ao forzado de grafcets conexos. Para poder forzar un grafcet conexo preciso
asociarlle previamente un identificador que ser utilizado nas ordes de forzado. O editor deixa
baixo a responsabilidade do usuario a coherencia das ordes de forzado, sendo posbel na
prctica editar ordes de forzado que forcen etapas inexistentes e definir estructuras de forzado
que contean ciclos ou provoquen situacins de forzado mltiple.
_ax
^dohe
compta^^12'
X4`:. .
5}.-done;.
.
^
^
:^
Figura 4.14. Interface do editor Grafcet do Graf7C.
143
No Graf7C o cdigo de accins e receptividades especificado utilizando unha versin da

linguaxe C, denominada C7, que foi implementada partindo dun subconxunto do C estndar ao
que se lle engadiron algunhas caractersticas novas, como:
1. Un control mais estricto dos tipos de datos.
2. Novos operadores para representar aspectos especficos do Grafcet: ordes de forzado,

pulsos, temporizadores, eventos, etc.
3. Unha librara moi variada de funcins para a visualizacin, acceso a arquivos,
programacin de interfaces de E/S, etc.
Cada accin est composta por un conxunto de sentencias C7 consideradas internamente
como o cdigo dunha funcin C de tipo void (funcin que non devolve ningn valor). Cada
sentencia pode ser polo tanto unha declaracin de varibel local, unha sentencia C(o que
incle: bucles, seleccins, saltos, chamadas a funcins, etc.) ou unha accin dalgn dos tipos
indicados na Tboa 4-VI. Destas accins as continuas e memorizadas poden utilizarse
unicamente con varibeis booleanas, as condicionais definense mediante a instruccin if/else do
C e as impulsionais utilizando a funcin pulse implementada polo C7 (esta funcin devolve o
valor true mentres o cdigo da accin non sexa executado). A utilizacin de temporizadores
nas accins condicionais permite editar tamn accins demoradas e limitadas no tempo. A
sintaxe C7 para os temporizadores pode ser unha das seguintes:
T/<t>>s/<X>
T/<X>/<t2>s
T/<t>>S/<X>/<t2>s
T/<t>>s/[T ^ ^]<expresin>
polo que as accins demoradas e limitadas representaranse como:
if (T/ls/X;) accin;
// accin retardada
if (T/X;/ls) accin;
// accin limitada
if (T/ls/X;/2s) accin;
// accin retardada e limitada
Sen embargo durante as probas realizadas, os temporizadores que inclen un tempo t1 non
funcionaron correctamente, polo que foi preciso representar as accins limitadas da forma
seguinte:
if (!(T/ls/X;)) accin;
// accin limitada
if (T/ls/X; && !(T/2s/X;)) accin;
// accin retardada e limitada
Continuas
Memorizadas
Condicionais
Impulsionais
Ordes de forzado
Ordes de blo ueo
<varibeh;
<varibel> = 1 0 ;
if <condicin> <accin 7y else <accin FS
if (pulseQ) <accin>
<varibel> = pulseQ;
<contador> + - = ulse ;
Fl^sub a cet>: <situacin>
F/^sub a cet>: *
Tboa 4-VI. Sintaxe das accins no Graf7-C
144
As receptividades no Graf7-C son condicins lxicas escritas en C7, polo que poden
utilizarse os operadores lxicos e relacionais do C, chamadas a funcins, temporizadores,
eventos e unha macro denominada done, que certa cando as accins asociadas s etapas
previas transicin foron xa executadas. O Graf7-C non impide que durante a avaliacin das
condicins poidan producirse èfectos colaterais'.
O Graf7-C permite asignar identificadores s etapas, transicins e grafcets conexos

utilizados na xerarqua de forzado. Os formatos dos identificadores son: X para as etapas, M
para as macroetapas, E e S para as etapas de inicio e fin de macroexpansin, identificadores
numricos para as transicins e alfanumricos para os grafcets conexos. O editor asigna os
identificadores de etapa e transicin automaticamente, controla que non existan duplicados e
renumera automaticamente as etapas e transicins despois dunha operacin de copia, anda que
esta caracterstica non actualiza os contidos de accins e receptividades e non funciona
correctamente coas referencias de salto.
O Graf7-C realiza a anlise sintctica en das fases, durante a edicin s poden inserirse
smbolos e realizar conexins que cumpran a regra de alternancia etapa-transicin, e impdese o
uso de identificadores duplicados. A deteccin de erros sintcticos no contido de accins e
receptividades realzase durante a compilacin do grafcet. Durante as probas comprobouse que
o compilador non detecta o uso incorrecto de macroetapas (macroexpansins sen etapa de
inicio ou fin, macroetapas sen macroexpansin ou viceversa), erros nas ordes de forzado
(forzado de etapas inexistentes, autoforzado dun grafcet), ou a existencia de arcos non
conectados.
O Graf7-C permite tanto a simulacin como a execucin dos grafcets co PC directamente

conectado ao proceso mediante unha interface de E/S. O programa incle unha opcin para a
execucin paso a paso do algoritmo de evolucin e un traductor que pode converter os grafcets
a tres formatos diferentes: cdigo-P (pseudoensamblador, para ser implementado mediante IL),
cdigo C e ecuacins booleanas (para ser implementado mediante LD). Tanto durante a
simulacin como durante a execucin pode verse o estado do programa a travs de tres
interfaces diferentes:
1. A interface Grafcet, na que se anima a evolucin da situacin do grafcet e os valores das
entradas e sadas.
2. A interface de monitorizacin de varibeis, na que se monitorizan os valores de varibeis,
entradas e sadas, e os estados de etapas e transicins.
3. A interface de operador, na que pode verse unha animacin grfica do proceso. O usuario
pode modificar esta interface implementando un conxunto de funcins reservadas no
Graf1-C para este cometido.
As varibeis e parmetros precisos para conectar o PC ao proceso mediante unha interface
de E/S son definidos nun arquivo denominado grafcet.io. Por defecto o Graf7-C declara trinta
e das entradas (a-z) e dezaseis sadas (SB^-SB^S) booleanas, catro entradas (EA^-EA3) e das
sadas (SA^-SA^) analxicas e oito contadores (Cf-C8), e presupn a existencia de das tarxetas
de E/S, unha dixital e unha analxica, cos seus portos de E/S mapeados en memoria. Ademais,
145
e para permitir a simulacin, tamn asigna as entradas booleanas ao teclado. O usuario pode
modificar esta interface editando o arquivo grafcet.io e implementando un conxunto de
funcins reservadas no Graf7-C para realizar as operacins de E/S.
O algoritmo de interpretacin do Graf7-C de tipo ARS con deteccin de ciclos

estacionarios. Durante as evolucins internas do modelo os eventos externos foron
considerados coma eventos na escala interna e os internos foron tratados internamente
(4.1.2.1, caso l.a).
As accins, includas as impulsionais, son executadas unicamente nas situacins estbeis, e
atopronse problemas durante a comprobacin da aplicacin das ordes de forzado e bloqueo
(4.1.2.3). Cando o grafcet da Figura 4.3 estaba na situacin { 1, 4, 8} e se produciu o evento
externo Ta, a evolucin do modelo foi a agardada, executndose a orde de forzado da etapa 5
na situacin inestbel (2, 5, 8). Sen embargo, cando se partiu da situacin {1, 4, 7} a evolucin
ante o evento Ta foi {l, 4, 7}^(2, 4, 7)^{2, 5, 7}, da que se deduce que neste caso non se
executou a orde de forzado, o cal incorrecto.
Tamn se atoparon problemas na aplicacin xerrquica das ordes de forzado. Partindo da
situacin { 1, 10, 20, 30} no grafcet da Figura 3.37, cando a varibel a se activou, o modelo
evoluiu situacin {2, 10, 21, 32} dacordo ao comportamento agardado. Sen embargo, cando
se produce o evento Tb, a situacin pasou a ser a{3, 10, 21, 32}, que non coincide con
ningunha das catro previstas. En efecto, ao desactivarse a etapa 2 e activarse a 3, a orde de
forzado sobre a etapa 21 deixa de estar activa, co que a situacin do grafcet parcial GP3 podera
evoluir etapa 22, cousa que non acontece. O mesmo pode dicirse da orde de forzado da etapa
21 e o grafcet parcial GP4.
No referente resposta do Grafc7-C cando varias accins modifican simultaneamente unha
mesma varibel (4.1.2.2), os resultados nos diferentes casos probados foron os seguintes: no
caso (l.a) a sada mantivo o valor 1, o que indica que a accin R non prioritaria sobre as
demais en contra do definido no estndar IEC 61131-3; o caso (l.b) non foi considerado coma
un erro e a sada tomou o valor resultado da disxuncin lxica das accins activas; e, por
ltimo, os casos ( l.c) e( l.d) tampouco foron considerados coma erros e a varibel tomou
diferentes valores mentres as accins estiveron activas.
4.2.9.3. Conclusins
O Graf1-C unha aplicacin concibida con fines educativos para o desenvolvemento de
programas de control mediante Grafcet e C. A aplicacin est composta por un editor, un
compilador, un traductor (de Grafcet a cdigo-P, C ou ecuacins lxicas), un simulador, un
monitor en tempo real (que permite utilizar o PC como controlador) e unha ampla librara de
funcins C. O usuario pode redefinir partes do programa (a interface de E/S, a interface de
operador, etc.) mediante a modificacin de funcins C predefinidas que son chamadas durante
a execucin do programa.
A versin do Grafcet implementada moi completa, podendo utilizarse todas as estructuras
bsicas e extensins como as etapas (transicins) fonte e sumidoiro, as macroetapas e as ordes
de forzado. As accins e receptividades son codificadas en C7, unha versin da linguaxe C que
incle algunhas extensins Grafcet como o uso de eventos, temporizadores ou contadores. O
algoritmo de interpretacin utilizado de tipo ARS con deteccin de ciclos estacionarios. No
aspecto negativo pode indicarse que o programa non incle o concepto de grafcet parcial (as
146
ordes de forzado aplcanse entre grafcets conexos), permite a edicin de macroetapas e

macroexpansins incorrectas, deixa baixo a responsabilidade do usuario a utilizacin correcta
das ordes de forzado e non manexa correctamente os conflictos entre accins. En resume, a
pesar de ser un programa para o sistema operativo DOS que traballa en modo texto, o Graf7-C
implementa case todas as caractersticas do Grafcet, proporciona unha linguaxe de alto nivel
para a especificacin de accins e receptividades, incle boas opcins de simulacit e
monitorizacin e facilita os medios para conectar o PC ao proceso a travs de diferentes
interfaces de E/S.
4.3. Conclusins
Os datos obtidos da anlise de caractersticas de cada aplicacin resmense nas tboas
situadas ao final deste captulo. En base a eses datos poden extraerse as conclusins seguintes:
No referente ao editor Grafcet:
1. Todas as aplicacins analizadas (excepto GrafcetView) utilizan un editor que divide o
rea de traballo en filas e columnas e restrinxe o tipo de nodo que pode inserirse en
funcin da posicin. O modelado de estructuras Grafcet complexas require que esta
divisin non impida o uso flexbel das estructuras de inicio e fin de seleccin
(paralelismo), que se permitan os cruces de lias ou a utilizacin de referencias de
salto, e que non se limite o nmero de grafcets conexos nin de etapas iniciais. Isto non
soportado por todas as aplicacins analizadas, en especial as baseadas no SFC.
2. A edicin da estructura xerrquica dun modelo mais fcil se se dispn dunha vista
tipo rbore na que se representen os niveis de aniamento da xerarqua. Das
aplicacins analizadas que soportaban a estructuracin dos modelos, a maiora incluan
esta vista para a xerrquica estructural mais non para a xerarqua de forzado.
3. A maior parte das aplicacins fan a anlise sintctica en das fases. Isto, xunto coa
inclusin de asistentes para a edicin de estructuras Grafcet (como o do AutomGen,
p.e.) e do cdigo de accins e receptividades (como o do Visual I/O, p.e.), facilita a
edicin e especialmente til para os usuarios inexpertos durante a aprendizaxe.
4. Ningunha das aplicacins analizadas incle un soporte completo identificacin dos
diferentes elementos dun grafcet: ou ben non permiten identificar todos os elementos,
ou non permiten identificadores alfanumricos, ou non numeran automaticamente os
novos elementos, ou non inclen opcins que mantean a coherencia da numeracin
durante a edicin. Neste aspecto, o IsaGraph a aplicacin mis completa, pois
permite a numeracin alfanumrica de etapas, transicins e subgrafcets, e actualiza
correctamente as copias de elementos xa existentes, as referencias de salto e o cdigo
de accins e receptividades durante a edicin.
5. Outra caracterstica desexbel nun editor Grafcet a posibilidade de xestionar unha
librara de estructuras grafcet predefinidas. Unicamente o AutomGen incle unha
destas libraras, mais non permite modificala.
No referente s opcins de simulacin e execucin:

1. O Grafcet un formalismo definido para ser independente da tecnoloxa utilizada na
sa implementacin. Para incrementar a sa aplicabilidade preciso dispor dun
ambiente de execucin que sexa facilmente portbel e dende o que poidan utilizarse
mltiples sistemas E/S e protocolos de intercambio de informacin con outras
aplicacins. Entre as aplicacins analizadas a opcin mis comn a de dispor dun
147

emulador PLC (mdulo softPLC) no que poidan cargarse os modelos previamente
compilados ou traducidos a unha linguaxe intermedia que interpretada polo
emulador. Algunhas aplicacins inclen tamn unha librara de programacin que
permite engadir novos "drivers" de E/S e funcins adicionais ao emulador. O ambiente
de execucin mis completo dos analizados o do IsaGraph, que est dispobel para
mltiples sistemas operativos de tempo real e que incle unha librara para desenvolver
"drivers" de E/S e portar o ambiente a novos sistemas.
2. A simulacin dos modelos require soporte animacin grfica da sa evolucin,
monitorizacin en tempo real dos valores das varibeis e algn mtodo de simulacin
das entradas. Todas as aplicacins analizadas, excepto o PL7, inclen estas opcins.
3. O soporte para a depuracin dos modelos require opcins que permitan a execucin
ciclo a ciclo, colocacin de puntos de parada baseados na situacin actual do modelo,
forzado da situacin, e modificacin e forzado de varibeis. Unicamente o IsaGraph e o
PL7 inclen todas estas opcins, nas demais aplicacins o mais comn permitir a
monitorizacin de varibeis e nalgunhas delas a execucin ciclo a ciclo.
No referente sintaxe do Grafcet:

1. O soporte sintctico ofrecido polas aplicacins analizadas vara dependendo de si a
aplicacin est orientada edicin de SFCs ou edicin de versins mais completas do
Grafcet. Nas aplicacins do primeiro tipo non poden utilizarse etapas (transicins)
fonte e sumidoiro, non penmiten o uso flexbel das estructuras de inicio e fin de
seleccin (paralelismo), e non permiten representar semforos. Ademais algunhas
destas aplicacins unicamente permiten editar unha rede SFC e limitan o nmero de
etapas iniciais. Entre as do segundo tipo, o WinGrafcet presenta as mesmas limitacins
que as aplicacins SFC, o PL7 non implementa as etapas (transicins) fonte e
sumidoiro, e as referencias de salto non son includas en todas as aplicacins.
2. A implementacin das xerarquas do Grafcet un dos aspectos nos que se detectaron
maiores diferencias e deficiencias no que sintaxe respecta. As aplicacins SFC non
implementan nin a xerarqua estructural nin a de forzado, mentres que das demais s
algunhas implementan as macroetapas e unicamente o AutomGen e o Graf7-C soportan
as ordes de forzado. Ningunha das aplicacins analizadas implementa de forma
explcita a estructuracin dos modelos en grafcets globais, parciais e conexos, nin
permite visualizar ou comprobar a coherencia e a correccin da xerarqua de forzado.
3. Outro aspecto sintctico no que hai grandes diferencias a implementacin de accins
e receptividades. Hai aplicacins que implementan completa ou parcialmente o
estndar IEC (MachineShop, Actwin), outras que implementan mediante unha sintaxe
propia parte dos tipos de accins definidos polo IEC (AutomGen, GrafcetView) e
outras que utilizan unha linguaxe de programacin de alto nivel e inclen medios para
representar diferentes comportamentos temporais nas accins (Visual UO, Graf7-C). A
maiora das aplicacins (excepto o Visual UO) permiten utilizar eventos,
temporizadores e contadores nas accins e receptividades, e s algunhas inclen algn
medio para impedir os èfectos colaterais' durante a avaliacin das receptividades.
4. Todas as aplicacins detectan durante a verificacin sintctica (xa sexa nunha ou en
das fases) os erros de edicin mais comns: alternancia etapa-transicin, erros
sintcticos en accins e receptividades ou elementos sen identificador. A maiora
tamn detecta ou impide os identificadores duplicados e as referencias a etapas
inexistentes. Sen embargo caractersticas mais avanzadas como a utilizacin dunha
148
transicin simultaneamente como fonte e sumidoiro ou a estructura sintctica das

macroexpansins non se comproba case en ningunha aplicacin, e tampouco hai
ningunha que comprobe a correccin e coherencia das ordes de forzado.
No referente interpretacin dos modelos:

1. O algoritmo de interpretacin mis utilizado o SRS, utilizando en toda ^ as
aplicacins IEC e as orientadas programacin de PLCs. Unicamente tres aplicacins
implementan un algoritmo tipo ARS, e destas unicamente das (GrafcetView, Graf7C) detectan os ciclos estacionarios durante a execucin. Ningunha permite configurar
como sern considerados os eventos ou que valor das varibeis (interno ou externo)
ser utilizado durante as evolucins internas, e tampouco permiten indicar que accins
se executarn unicamente nas situacins estbeis e cales en calquera situacin.
2. S as aplicacins AutomGen e Graf7-C implementan as ordes de forzado e ningunha
delas as aplica correctamente durante a execucin: no Graf7-C non teen prioridade
sobre as evolucins estructurais e en ningunha das das se aplican recursivamente
dacordo aos niveis da xerarqua de forzado.
3. Das tres aplicacins que implementan un algoritmo de interpretacin tipo ARS,
ningunha aplica correctamente as accins e ordes de forzado durante as evolucins
internas do modelo: o GrafcetView non ten ordes de forzado e s implementa accins
externas que se executan nas situacins estbeis; o AutomGen executa accins e ordes
de forzado en todas as situacins, tanto estbeis como inestbeis; e o Graf7-C executa
as accins s en situacins estbeis, independentemente do seu tipo, e aplica de forma
incorrecta as ordes de forzado.
4. Ningunha das aplicacins analizadas detecta ou impide os conflictos entre accins.
Algunhas das aplicacins que seguen as recomendacins do IEC (ActWin, IsaGraph)
dan prioridade s asociacins tipo R e a maiora aplican a disxuncin lxica dos
resultados en caso de conflicto. Sen embargo ningunha implementa a semntica
definida polo IEC mediante os bloques de control de accins (3.6.1.3) e tampouco
impiden a aparicin de comportamentos indeterministas cando hai asignacins
simultneas de valores mltiples a unha mesma varibel.
5. Das aplicacins que permiten a utilizacin de transicins fonte (catro en total) s 0
AutomGen e o Graf7-C as consideran como sempre validadas durante a execucin.
Outras consideracins:
1. Exceptuando o GrafcetView, que implementa o Grafcet como librara para LabView,
ningunha das aplicacins analizadas permite utilizar o Grafcet fora do ambiente da
propia aplicacin, de xeito que poida ser integrado con outras aplicacins, libraras ou
linguaxes. Isto ten como consecuencia a perda de aplicabilidade, xa que non permite
utilizar o Grafcet como formalismo xenrico independente da tecnoloxa de
implementacin e aberto integracin de calquera linguaxe para a especificacin de
accins e receptividades.
2. Non existe un formato para o intercambio de grafcets entre aplicacins. Isto
consecuencia tanto do comentado no punto anterior como das diferencias entre as
aplicacins hora de implementar o Grafcet. Este formato nin sequera existe entre as
aplicacins que seguen as recomendacins do IEC.
3. Ningunha aplicacin permite configurar o tipo de interpretacin co que o usuario quere
executar os modelos. Sera desexbel dispor dun ambiente de execucin no que o
149

usuario puidera elixir entre executar un modelo mediante unha interpretacin SRS ou
ARS sen necesidade de modificar o modelo.
4. As aplicacins con algoritmos ARS tampouco permitn modificar a configuracin de
como se considerarn os eventos, varibeis e accins nas das escalas de tempo deste
algoritmo. Ao igual que no punto anterior, sera desexbel que o usuarô puidera
configurar estas opcins durante a execucin sen que iso afectase ao modelo.
5. O soporte distribucin dos modelos Grafcet limitado. A maiora das aplicacins
analizadas non permiten distribulos entre varios ambientes de execucin, e nas que o
permiten (IsaGraph, p.e.) a distribucin rxida: primeiro definense os nodos do
sistema e, posteriormente, edtanse os grafcets de cada nodo. Sera desexbel dispor
dun editor que permitira editar os modelos Grafcet de maneira independente da
estructura do sistema de control, que inclura ferramentas que permitiran analizar
diferentes posibilidades de distribucin e que realizaran esta de forma automtica.
150
GRAFCETVIEW
_
_ _
Datos da aplicrb ^^;
Dis oibilidade
Fabricante
Tipo
Sistema o erativo
Sistema E/S
E ui o de control
Ambiente de execucin
__ .
^^^ ^
Comercial
AlterS s
Programacibn
sistemas distribudos
Windows
Windows, Unix
Serie, DAO, GPIB, Modbus, Memobus,
Profibus
VXI
PC, PLC, SCADA
PC
l.inux, VxWorics, pSOS,
LabView
Windows
Comercial
TecAtlant
Librara LabView
PL7
MACHINESHOP
ISAGRAPH
,.. .
^j....
^ ^^^
._
^ :..^ ^
Comercial
Comercial
CTC Partcer Automation Schneider Automation
Programacin PLC
HMI/SCADA
Windows
Profibus, DeviceNet,
Modbus, PC104
PC, PLC, CTC
RTXDOS
Windows
Modbus, Profibus,
InterBus, CanO en
PLCs Telemecani ue
PLCs Telemecanique
Filas e cotumnas
Si
Si (2 fases)
Si
Non
Non
Si
Si
Si
Si
Si
Filas e columnas
Si
Si (2 fases)
Si
Non
Non
Si
Non
-
Filas e columnas
Si
Si (2 fases)
Non
Non
Non
Si
Non
-
Si
Si
SoftPLC portbel
Si
Si
Si
Si
Si
Si
Si
Si
SoftPLC en RTXDOS
Si
Si
Non
Non
Si
Si
Si
Non
Si
Si
Si
Si
Si
Si ( IEC)
Si
Si
Si
Si
Si
Si (mediante Interact)
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Editor Grafcet
Editor LabView
Tipo editor
Edicin: copiar, mover, ...
Si
Si (2 fases)
Anlise sintctica
Non
Asistente edicin cdigo
Non
Asistente edicin estructuras
Non (pode crearse)
Librarfa de estructuras
Non
Identificacin automtica
Non
Opcins renumeracin
Renumeracin ao copiar
Renum. referencias de salto
Renumeracin referencias en accins e receptividades
_Opcins de simulacin e dperacin
Animacin de grafcets
Simulacin
Ambiente de simulacin
Simulacin de entradas
Depuracin
Execucin paso a paso
"Breakpoints"
Monitorizacin varibeis
Forzado de varibeis
Non (pode emularse)

Si (mediante LabView)
LabView
Funcins adicionais
Estructuracin do proxecto
Diccionario / Tboa simbolos
Editor configuracin hardware
Editorconfiguracin E/S
Referencias cruzadas
Biblioteca de programas
Editor interface de usuario
Documentacin do proxecto
SDK para programacin
Si (capsulamento Vls) Si (equivalente a IEC)

Si
Non
Si (mediante LabView) Si
Si (mediante LabView) Si
Si
Non
Si
Si (libraras de Vls)
Si (mediante LabView) Non
Limitada (docum. Vls) Si
Non
Si
Tboa 4-VII. Resume dos resultados da anlise: funcionalidades das aplicacins.
151

VISUAL IO
- ^.
_.
.-
AUTOMGEN
. .,, _ " . . .
Dats".â,. Apli acin'

.
..^
. .
_^, . .
.
,.
.,'
- . y.-
ACTWIN
__
^ '
..
Comercial
ArSoft Intemational
HMI/SCADA
Comercial
Irai
Programacin
software de control
Windows
Windows
Profibus, Modbus,
Profibus, Modulink,
Interbus, CanOpen
Modbus
PC
PC, PLC
Windows/Sistemas RT Postprocesador PC ou
x86
PLC
,- ,,_
È^3ifor G'raft
. ..^
Filas e columnas
Si
Si (2 fases)
Si
Non
Non
Si
Si
Non
Si
Non
-,-
_,,^.
__ ---^
-_
Filas e columnas
Si
Si (1 fase)
Si
Si
Si
Non
Si
Non
Non
"de"imtilacin/dep"racîi^`
Ôpcids
'. :^
K, ,^
.....
.
Si
Si
SoftPLC en NVindows
Si
Si
Non
Non
Si
Si
Si
Si
Simulador Windows
Si
Si
Si
Non
Si
Si
^Funcis
adiiona^ '
^ _ ., .
_ ^,
_
.
Si
Si
Si
Si
Si
Si
Si
Si
Si
Non
Si (mediante VPUs)
Si
Si
Si
Si
Si
Si
Non
.,
.. <
^:
.
WINGRAFCET
_ ,
_...^.
_ _ _x .
. -..
. ... .
- ^,
-. .
GRAF7-C
.
. . . ,,
.
,e ^
^
...C'
^
.
.
Comercial
Actron
Programacin PLC
Comercial/Educacin
CDRP Montpellier
Programacin Grafcet
Educacin
CCDMD
Programacin Grafcet
Windows
Profibus, Interbus,
CANOpen, DeviceNet
PC, PLCs Hitachi
Windows
Windows
AM1, AM2, IP16,
Approtech, Ipocaen
PC
Windows
DOS
Tancetas E/S para PC
^-o_. _
Edicin controlada
Si
Si (2 fases)
Si
Non
Non
Si
Si
Si
Si
PC
DOS
^^ o- ^. g.^^ ^^- :
. -_ _.._
__ . _ . . . ._-
- .
Si
Si
SoftPLC en Windows
Si
Si
Non
Non
Si
Si
^
,
Si (IEC)
Si
Si
Si
Si
Si
Non
Si
Si
Filas e columnas
Si
Si 1 fase)
Non
Non
Non
Si
Si
Non
Non
Non
^ . .^
,
_^.^__
Non
Non
Non
N/A
Non
Non
Non
Non
Non
c^.
S^
Si
Simulador Windows
Si
Si
Non
Non
Si
Non
^ ^,:
_--
Filas e columnas
Si
Si (2 fases)
Non
Non
Non
Si
Si
Si
Si (con erros)
Non
`^
-. ,
.
^.
....^.
Si
Si
Simulador DOS
Si
Si
Si
Non
Si
Non
_ .
. .. _ _. -_ . " ,...
Non
Non
Non
Si (mediante prog.)
Non
Si
Si (mediante prog.)
Non
Si
Tboa 4-VIII. Resume dos resultados da anlise: funcionalidades das aplicacins (continuacin).
'
8
-..-_^.. ...
-__
152
GRAFCETVIEW
Grafcet/SFC
ISAGRAPH
PL7
MACHINESHOP I
Grafcet
SFC+xerarqua propia
SFC
Eta a/Eta a IniciallTransicin

Mlti les eta as iniciais
Rece tividades/Accibns
Referencias de salto
Eta a fonte/sumidoiro
Transicin fonte/sumidoiro
Si
Si
Si
Non
Si
Si
Si
Si
Si
Si
Non
Non
Si
Non
Si
Si eta as de salto
Eta as sumidoiro
Non
Si
Si
Si
Si
Non
Non
Estructuras de control
Secuencia
Si
Si
Si
Si
Seleccin de secuencia
Paralelismo
Salto de secuencia
Ciclo
Semforo
Si uso flexbel
Si uso flexibel
Si
Si
Si
Si uso flexbel
Si uso flexbel
Si
Si
Non
Si uso rxido
Si uso rxido
Si
Si
Non
Si uso flexbel
Si uso flexbel
Si
Si
Si
Si ca sulamento Vls
Si ca sulamento Vls
Si
Non
Non
Non
Si
Non
Non
Non
Non
Non
Si
Non
Si
Non
Sintaxe ro ia
N, C
emulacin D e L
Si
Si
Si varibeis de eta a
Non
Si
lL, ST, LD
N, R, S, P0, P1
IL, LD, FBD, ST

IL, ST, FBD, LD
N, R, S, P, L, D, DS, SD, SL P0, N, P1
Si
Si FBs IEC
Si FBs IEC
Si FBs IEC
Si
Si
Si FBs IEC
Si FBs IEC
Si FBs IEC
Si
Si uso limitado
Non
Si FBs IEC
Si FBs IEC
Non
Numrico
Eta as
Alfanumrica
Eta as, trans., rafcets
Alfanumrica
Eta as, trans., accins
Numrico
Eta as
Si
Si
Si
Si
Si evtase na edicin
-
Si
Si
Si
Si
Si
-
Si
Si
Si
Si
Si
Si
-
, .
"Smtax^
Grafcet
,i
Elementos bsicos
Estructura xerr uica

Macroeta as
Grafcet Conexo/ParciaUGlobal
Mlti les rafcets conexos
Ordes de forzado
Accins / Rece tividades

Lin uaxes
Tipos de accins
Varibeis de eta a
Eventos
Tem orizadores
Contadores
Efectos colaterais
Identificacin
Ti o
Elementos
Erros detectados na anlise sintctica

Altemancia Eta a/1'ransicin
Identificadores du licados
Cdi o accins
Cdi o rece tividades
Ref. de salto inexistentes
Transicin fonte e sumidoiro
Estructura macroex ansins
Coherencia xera u!a forzado
Si
Si
Si
Si
Si
Non
-
^Înter retaci
^^ ^^^
Al oritmo
Ti o
Deteccin ciclos estacionarios
Trans. fonte sem re validadas
Eventos na esca/a intema
Escala eventos intemos
Varibeis eatema^ntemas
Accins en situacins inestbeis
Accins extema^ntemas
FO en situacins inestbeis
A licacin n:cursiva de FOs
ARS
Si
Non
Eventos
Intema
Non
Non
Non
-
SRS
-
SRS
-
SRS
-
Non
-
Si
Non
Si
Non
Non
Non
N/A
N/A
N/A
N/A
Conflictos entre accins

Prioridade do Reset
Tem orizacin var. booleanas
Tem orizacin de asi nacins
Asi nacins mlti les
Tboa 4-IX. Resume dos resultados da anlise:caractersticas Grafcet soportadas.
153

VISUAL I/O
Grafcet
^^^
`Sintaxe
.....,
AUTOMGEN
Grafcet
^^n^
^
-^_
.
^. ;^^ _
ACTWIlV
SFC
,_
.^
. __ _
WINGRAFCET
GRAF7-C
Grafcet
^ ,.x.
. ^._..
.
-
Grafcet
. .:. .. -..
'
Elementos bsicos
Si
Si
Si
Si
Si
Si
Si
Non
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Non
Si
Si
Si
Non
Non
Si
Non
Non
Si
Si
Si
Si
Si uso rixido
Si uso rxido
Si
Si
Non
Si
Si uso rxido
Si uso rxido
Si
Si
Non
Si
Si uso flexbel
Si uso flexibel
Si
Si
Si
Non
Non
Si
Non
Non
Non
Si
Non
Si tamn tarefas
Non
Si
Si
Sintaxe ro ia
N, C, R, S, P1, PO
emulacin L, D, DS
Si
Si
Si
Si
Non
LD, FBD
N, R, S, P, L, D, DS,
SD, SL
Si
Non
Si
Si
Si
Sintaxe ro ia
N
Si
Si
Si
Si
Non
C7
N, C, R, S, P
emulacin L, D
Si
Si
Si
Si
Si
Numrico
Eta as
Alfanumrico
Eta as, accins, recs.
Numrico
Eta as
Num./Alfanumrico
Eta as, trans., GCs
Erros detectados na anlise sintctica

Si
Si ermite erros
Si
Si
Si
Non
'
Si
Si
Si evtase na edicin
Non
-
Si
Si
Si
Si evtase na edicin
-
Non
Si
Si
Si
-
Si
Si
Si
Non
Non
Non
Non
Estructuras de control
Si
Si uso flexibel
Si uso flexibel
Si
Si
Si
Si
Si uso flexbel
Si uso flexbel
Si
Si
Si
Estructura xerr u ica

Non
Non
Si
Non
Si
Non a ru am. GCs
Si
Si
Accins / Rece tividades

Pascal
N
emulacibn L, D, P
Si
Non
Non
Non
Si
Identificacin
Numrico
Eta as
Int
Si
Si
Si
Non
Si limitado
Non
retacin
"
'
-^
AI oritmo
SRS
Non
-
ARS
Non
Si
Eventos
Intema
Non
Si
Non
Si
Non
SRS
-
SRS
-
ARS
Si
Si
Eventos
Intema
Non
Non nin im ulsionais
Non
Non
Non
Si
Non
Non
Non
N/A
N/A
N/A
N/A
Non
Non
Non
Non
Conflictos entre accins

Non
Non
Non
Non
Non
Non
Non
Tboa 4-X. Resume dos resultados da anlise:caracteristicas Grafcet soportadas (continuacin).
Captulo 5 . Proposta dun

metamodelo para o Grafcet
Como se indicou no Captulo 4, dende a aparicin do primeiro estndar Grafcet

internacional [84], fixronse diferentes propostas coa intencin de mellorar as capacidades de
do Grafcet para o modelado de sistemas complexos. Algunhas destas propostas foron recollidas
na norma [2] e, recentemente, nunha nova revisin do estndar internacional [85]. Ademais
tamn se estandarizou unha versin orientada programacin de PLCs [86]. A existencia de
diferentes versins do estndar e distintas propostas de mellora do formalismo levou na
prctica a unha situacin, posta de relevo nas conclusins da anlise realizada no Captulo 4, na
que cada aplicacin implementa versins diferentes do Grafcet dando lugar existencia de
mltiples dialectos. Algunhas das desvantaxes desta situacin son:
1. Non se dispn dunha referencia comn que permita verificar que unha aplicacin
implementa as caractersticas definidas polos estndares.
2. Non existe un formato estndar de intercambio de grafcets entre aplicacins.
3. Non se dispn da infraestructura precisa (p.e. librara, compilador, etc.) que permita
integrar o Grafcet como linguaxe xenrica de especificacin de secuencias de control en
calquera aplicacin.
Coa intencin de solucionar estes problemas e formalizar as caractersticas do Grafcet
utilizadas na ferramenta proposta nesta tese de doutoramento, proponse neste captulo un
metamodelo que describe a sintaxe do Grafcet37 [132], dacordo s definicins e propostas
anteriores ltima revisin do estndar.
Un metamodelo ùnha definicin precisa dos conceptos, regras e restriccins utilizados na
creacin de modelos'. dicir, o metamodelo proposto formaliza os conceptos e regras
utilizados durante a especificacin da secuencia de control dun sistema modelado mediante
Grafcet. Algunha das avantaxes de dispor dun metamodelo son as seguintes:
1. Pode ser utilizado como base para a definicin dun formato de almacenamento e
intercambio de informacin entre aplicacins.
2. Existen ferramentas baseadas no uso de metamodelos para a anlise formal, verificacin
sintctica e traduccin de modelos.
3. un elemento de integracin cos metamodelos doutros formalismos, incrementndose as a
reusabilidade e aplicabilidade dos modelos.
37 Os aspectos semnticos son tratados en (8.4).
155
156
Captulo 5: Proposta dun metamodelo para o Grafcet
O resto do captulo estructurase do xeito seguinte: no apartado (5.1) descrbese o

metamodelo proposto; no apartado (5.2) presntanse os aspectos mis relevantes dunha
librara C++ que implementa o metamodelo; en (5.3) mstranse algns exemplos de modelado
utilizando esta librara e, por ltimo, no apartado (5.4) resmense as conclusins do captulo.
^^
5.1. Metamodelo para a sintaxe do Grafcet
O metamodelo que se propn toma como base o definido en [59]. Mellorouse a

representacin das xerarquas Grafcet, engadiuse unha descricin precisa das accins e tipos de
datos utilizados nos modelos e definiuse un conxunto de invariantes que describen as regras
que debe cumprir un modelo para ser sintacticamente correcto. Ademais definronse as
relacins entre as metaclases do Grafcet e as do UML, de xeito que poida ser utilizado como
alternativa aos StateCharts na especificacin do comportamento das compoentes dinmicas
dun modelo. A representacin do metamodelo fixose utilizando os mesmos medios que utiliza
UML: a MOF [127] e a linguaxe OCL [178].
5.1.1. Estructura de paquetes

O metamodelo est estructurado en catro paquetes (Figura 5.1):
1. Grafcet data, no que se definen os tipos de datos, varibeis e expresins do metamodelo.
2. Grafcet core, no que se especifican os elementos sintcticos bsicos do Grafcet.
3. Grafcet actions, no que se inclen as definicins dos tipos de accins.
4. Grafcet hierarchy, no que se definen as metaclases que permiten estructurar
xerarquicamente os modelos.
Como todos os paquetes dependen do metamodelo UML (Figura 5.2), antes de pasar a
describir o metamodelo Grafcet en detalle, reprodcense aqu parte das especificacins das
metaclases UML38 utilizadas, para por en contexto o metamodelo proposto.
Grafcet Core
Grafcet Hierarchp
Grafcet Data
Grafcet Actions
Figura 5.1. Estructura de paquetes do metamodelo Grafcet.
5.1.1.1. Metaclases do metamodelo UML

Na Figura 5.3 pode verse un diagrama de clases contendo todas as metaclases UML
utilizadas directa ou indirectamente polo metamodelo Grafcet proposto. A descricin resumida
de cada metaclase a seguinte:
38 Pode consultarse en [ 127] a especificacin completa do metamodelo.
157
Seccin 5.1: Metamodelo para a sintaxe do Grafcet
Elemento del modelo ("Model Element")
un elemento que representa unha abstraccin extrada do sistema modelado. No

metamodelo unha entidade con identidade nun modelo. a metaclase base do metamodelo
UML, todas as demais metaclases derivan directa ou indirectamente dela.
Atributos:
name, identificador do elemento.
Figura 5.2. Dependencias do metamodelo UML.

Expression
language : Name
body : String
ModelElement
name : Name
_^
Feature
ownerScope : ScapelGnd
visibility : YsibilityKind
Structural Feature
multiplicity : Multiplicity
changeability : ChangeableKind
targetScope : ScopeKind
ordering : OrderingFGnd
^
Attribute
initiaNalue : Expression
Action
recunence : IterationExpression
target : ObjectSetExpression
isAsynchronous : Boolean
script : ActionExpression
BooleanExpression
^
Behavioral Feature
isûery : Boolean
Operation
signature : String
isRoot : Boolean
isLeaf : Boolean
isAbstract : Boolean
concurrency : CaIlConcunencylGnd
specification
1
Method
body : ProcedureExpression
Figura 5.3. Diagrama parcial das clases do metamodelo UML.
Caracterstica ("Feature")
unha propiedade capsulada nun clasificador (elemento con propiedades estticas e
dinmicas). No metamodelo declara unha caracterstica estructural ou de comportamento dun
clasificador ou dunha instancia dun clasificador. Esta metaclase abstracta.
Atributos:

ownerScope, indica se a caracterstica aparece en cada instancia do clasificador ou nica.

Pode ter un dos valores seguintes:
n
n
instance, cada instancia ten o seu propio valor para a caracterstica.
classifier, hai un nico valor da caracterstica para todas as instancias do clasificador.
visibility, indica se a caracterstica pode ser utilizada por outros clasificadores. Pode ter un
dos valores seguintes:
158
public, calquera clasificador externo pode usar a caracterstica.
n
n
n
protected, calquera descendente do clasificador pode usar a caracterstica.

private, unicamente o clasificador pode usar a caracterstica.
package, calquera clasificador no mesmo paquete declarado como propietario da
caracterstica pode utilizala.
Caracterstica estructural ("Structural Feature")

Refirese a unha caracterstica esttica dun elemento, como por exemplo un atributo. No
metamodelo, unha caracterstica estructural declara un aspecto estructural dunha instancia dun
clasificador. A caracterstica pode especificar, por exemplo, a multiplicidade dun atributo. Esta
unha metaclase abstracta.
Atributos:
changeability, indica se pode modificarse o valor despois da creacin do obxecto. Os

valores que pode tomar son:
n
changeable, pode modificarse.
frozen, o valor non pode ser modificado.
addOnly, utilizado cando a multiplicidade varibel. Poden engadirse novos valores,

mais unha vez creados non poden modificarse nin eliminarse.
multiplicity, indica o nmero de valores da caracterstica que pode haber en cada instancia.
O caso mais comn unha multiplicidade 1..1 (un nico valor para a caracterstica).
ordering, indica se o conxunto de instancias est ordenado. A ordenacin mantida polas

operacins que engaden valores caracterstica. Este atributo ten significado s cando a
multiplicidade superior a un. Os valores que pode ter son:
unordered, os valores non estn ordenados.
n
n
ordered, un conxunto de instancias pode ser percorrido seguindo unha orde.
outros valores (p.e. clasificado) definidos polo usuario.
targetScope, indica se os valores da caracterstica se refiren a instancias ou a clasificadores.

Pode ter un dos seguintes valores:
n instance, cada valor unha referencia a unha instancia do clasificador. Este o valor
normal dun atributo.
n classifier, cada valor contn unha referencia ao clasificador. Este valor sirve para
almacenar metainformacin.
Atributo ("Attribute")
Un atributo un espacio identificado dentro dun clasificador que describe o rango de valores
que as sas instancias poden tomar.
Atributos:

initial Value, unha expresin que especifica o valor do atributo despois da iniciacin. Este
atributo est pensado para ser avaliado no momento en que o obxecto iniciado.
Caracterstica dinmica ("Behavioral Feature")

Refirese a unha caracterstica dinmica dun elemento, como por exemplo unha operacin ou
mtodo. No metamodelo especfica un aspecto do comportamento dun clasificador. Todos os
aspectos dinmicos dun clasificador, como as operacins e mtodos, son subclases desta
metaclase que abstracta.
159
Atributos:
isQuery, indica si a execucin da caracterstica modifica o estado do sistema. O valor true

indica que non o modifica e false que si.
Operacin ("Operation")
Unha operacin un servicio que pode solicitarse dende un obxecto para levar a cabo un
comportamento. Unha operacin ten unha declaracin que describe os seus parmetros e
valores devoltos. No metamodelo unha operacin unha caracterstica dinmica que pode
aplicarse s instancias do clasificador que contn a operacin.
Atributos:
signature, declaracin da operacin.
concurrency, especifica a semntica cando hai varias chamadas concorrentes mesma

instancia pasiva. Os valores posbeis son:
n
sequential, os clientes deben coordinarse para que s unha chamada estea activa en
cada momento. A semntica e integridade do sistema non pode garantirse se hai varias
chamadas simultneas.
guarded, estn permitidas varias chamadas simultneas mais s pode comezar unha
delas. As demais son bloqueadas ate que a primeira se completa. responsabilidade do
deseador do sistema garantir que non se produzan interbloqueos ("deadlocks").
concurrent, pode haber mltiples chamadas simultneas dende "threads" concorrentes
e todas elas son executadas concorrentemente mantendo a correccin semntica.
isAbstract, indica se a operacin ten implementacin. Se true a implementacin

proporcionada por unha clase derivada, se false implemntase na propia clase ou hrdase.
isLeaf, indica se a operacin pode ser redefinida nunha clase derivada.
isRoot, indica se a clase pode herdar ou non unha declaracin para a mesma operacin. O
valor true indica que non e false que si.
Mtodo ("Method")
Un mtodo a implementacin dunha operacin. Especifica o algoritmo ou procedemento
que calcula os resultados da operacin. No metamodelo un mtodo unha declaracin dunha
parte identificada do comportamento dun clasificador e realiza unha (directamente) ou varias
(indirectamente) operacins do clasificador. Como moito debe haber un nico mtodo para
cada par clasificador/operacin (o primeiro como propietario e a segunda como especificacin
do mtodo).
Atributos:
body, implementacin do mtodo.
Asociacins:
specification, indica a operacin que o mtodo implementa.
Accin ("Action")
Unha accin a especificacin dunha sentencia executbel, abstraccin dun procedemento
computacional que provoca un cambio no estado do modelo e que pode realizarse mediante o
envo dunha mensaxe a un obxecto ou a modificacin dunha conexin ou valor dun atributo.
Esta metaclase abstracta.
160
Atributos:
isAsynchronous, indica si o envo dun estmulo por parte da accin asncrono ou non.
recurrence, expresin que determina cantas veces debe realizarse a accin.
script, expresin que describe os efectos da accin.
target, expresin que indica o conxunto de instancias aos que se lles vai a aplicar a ac in.
UML non define se a accin aplicada secuencialmente ou en paralelo.
Expresin ("Expression")
Unha expresin define unha sentencia que devolver un conxunto de instancias cando sexa
avaliada nun contexto. As expresins non modifican o contorno no que son avaliadas.
Atributos:
language, indica con que linguaxe se especifica a expresin. As predefnidas son:

n OCL, a linguaxe utilizada en UML [ 178] para a expresin de restriccins.
n A linguaxe natural, indicada cun valor baleiro no atributo language.
body, contn o texto da expresin na linguaxe indicada.
Expresin booleana ("Boolean Expression")

Especifica unha sentencia que devolver un valor booleano ao ser avaliada.
5.1.2. Sintaxe abstracta do modelo

Nesta seccin especifcase a sintaxe abstracta do metamodelo utilizando os diagramas de
clases UML para representar as metaclases e as sas relacins. Para cada metaclase inclese
ademais unha descricin informal da sa semntica e descrbese o significado dos seus
atributos e asociacins.
5.1.2.1. O paquete Grafcet Data
No paquete Grafcet Data definense os tipos de datos e as metaclases que permiten modelar a
informacin e as expresins utilizadas nos modelos Grafcet. A Figura 5.4 mostra o diagrama de
clases deste paquete no que pode verse a relacin entre as metaclases definidas e as metaclases
UML comentadas no apartado anterior. A descricin detallada das metaclases deste paquete a
seguinte:
Tipo de etapa ("StepType")
Enumeracin que define o tipo dunha etapa do modelo. Os valores escalares definidos son:
step, indica que a etapa unha etapa simple.
initial, a etapa unha etapa inicial.
macro, a etapa representa unha macroetapa, cuxos contidos sern especificados nunha
macroexpansin.
Tipo de nodo ("NodeType")

Enumeracin que define o tipo dun nodo do modelo dende o punto de vista da sa posicin
nunha secuencia de control. Os valores escalares definidos son:
source, o nodo unicamente pode aparecer ao inicio dunha secuencia de control (non pode
ter conexins con nodos que o precedan na secuencia).
161

target, o nodo unicamente pode aparecer ao final dunha secuencia de control (non pode ter
conexins con nodos que o sucedan na secuencia).
both, o nodo pode aparecer en calquera punto dunha secuencia de control (pode ter
conexins con nodos que o precedan ou sucedan na secuencia).
none, o nodo non forma parte dunha secuencia de control (non ten conexins on ningn
outro nodo).
enumeration
StepType
step
initial
macro
enumeration
NodeType
source
target
both
none
ModelElement
r---------------------------------------------1 (trom UAIL Matamodep

; Subject
I
(Pattern}
Proxy = {
Proxy,
Subject,
RealSubject
}
^
SystemVar
value : DataType
RealSubject ^
Feature
(trom UYL Metemode^
Cwent
change : l3oolean
events
var
Situation
^
^ Proxy
Structural Feature
(from UML Metamode^
reads
enumeration
ActionType
Attribute
(from UML Metamodep
N
R
P1
PO
P
t
GrafcetVar
value : DataType
BooleanExpression
(irom UML Melamodet)
var
reads
enumeration
FOrderType
^
Grafcetl3ooleanCondition
GrafcetTemporizedCondit ion
delay : TimeExpression
limit : TimeExpression
force
empty
initial
freeze
ProcessValue
alias : String
'
qctionState
StepState
modâble : Boolean
^----------------------- '
T'imerValue
Figura 5.4. Diagrama de clases do paquete Grafcet Data.
Tipo de accin ("ActionType")

Enumeracin que define a semntica temporal que debe aplicarse durante a activacin dun
bloque de accin asociado a unha etapa para modificar o valor dunha varibel ou o estado de
activacin dunha accin. Os valores escalares definidos son: N, R, S, P, P 1 e P0.
Tipo de orde de forzado ("ForderType")
Enumeracin que define a semntica dunha orde de forzado. Os valores escalares definidos
son:
force, a orde forza unha situacin especfica nun grafcet. As etapas pertencentes situacin
dada son activadas e todas as demais desactivadas.

empty, a orde forza a situacin baleira nun grafcet. Todas as etapas do grafcet son
desactivadas.
initial, a orde forza a situacin inicial nun grafcet. Todas as etapas iniciais do grafcet son
activadas e todas as demais desactivadas.
freeze, a orde forza a situacin actual dun grafcet. Mantense o estado de activacin das
etapas impedindo as evolucins estructurais do modelo.
162
Varibel do sistema ("SystemVar")

Representa un valor externo utilizado polo modelo Grafcet. Esta metaclase derivouse de
ModelElement para permitir que aplicacins especficas do metamodelo a describan con maior
detalle. A este nivel de abstraccin o mtodo de acceso ou a descricin detallada do elemento
non son relevantes, unicamente interesa indicar que un elemento externo que contn un valor
^'
accedido dende o modelo39
Atributos:
value, valor do elemento externo accedido dende o modelo.
Varibel do modelo ("GrafcetVar")
Representa as varibeis identificadas no modelo. Mediante o atributo visibility, herdado da
metaclase Feature, pode especificarse a visibilidade dende outros modelos. Poden definirse
varibeis accesbeis dende outros grafcets ou s internamente, xa sexa no propio grafcet ou nos
seus derivados. Tamn pode especificarse o nome, modificabilidade, multiplicidade e valor
inicial mediante os atributos derivados das clases do metamodelo UML (Figura 5.3).
Atributos:

value, valor da varibel.
Evento ("Event")
Un evento representa un cambio no valor dunha varibel booleana manexada polo modelo.
O xeito de xerar o evento ou o seu manexo son aspectos que non se especifican no metamodelo.
Atributos:
change, indica o tipo de cambio do valor: true indica un flanco de subida e false un de
baixada.
Asociacins:

var, varibel cuxo valor cambia.
Valor do proceso ("ProcessValue")

Esta metaclase representa o acceso a unha varibel externa dende o modelo. O medio de
acceso non especificado no metamodelo. Esta metaclase dervase da metaclase GrafcetVar
para permitir a sa utilizacin nas condicins e accins do modelo do mesmo xeito que
calquera outra varibel.
Atributos:
alias, nome utilizado no modelo para referirse varibel externa.
modifiable, indica se o valor da varibel externa pode ser modificado ou unicamente

accedido dende o modelo.
Asociacins:
var, varibel externa cuxo valor utilizado no modelo.
39 Representouse o acceso externo mediante o patrn de deseo Proxy [67]. A representacin grfica do patrn non
coincide coa estndar proposta por UML debido a limitacins da ferramenta de modelado utilizada.
163
Estado de accin ("ActionState")

Representa o estado de activacin dunha accin utilizada no modelo. O atributo herdado
value de tipo booleano e a visibilidade desta metaclase non pode ser public para evitar que o
estado das accins sexa modificado externamente.
Estado de etapa ("StepState")
Representa as varibeis internas ao modelo que almacenan o estado das etapas. O atributo
herdado value de tipo booleano e o valor inicial ser true para as etapas iniciais e false para as
demais. A visibilidade desta metaclase non pode ser public para evitar que o estado dun grafcet
sexa modificado externamente.
Valor de temporizador ("TimerValue")
A metaclase TimerValue representa os valores de temporizadores utilizados nun modelo. A
metaclase dervase de ProcessValue para indicar que o seu valor utilizado internamente, mais
que o manexo dos temporizadores e o medio de acceso ao seu valor unha cuestin de
implementacin non recollida no metamodelo.
Situacin ("Situation")
Unha situacin un agrupamento dos estados dun conxunto de etapas.
Condicin booleana do modelo ("GrafcetBooleanCondition")
Esta metaclase representa unha expresin booleana na que poden utilizarse eventos e os
valores das varibeis do modelo.
Asociacins:
vars, varibeis cuxos valores son utilizados na condicin.
events, eventos utilizados na condicin.
Condicin temporal do modelo ("GrafcetTemporizedCondition")

Representacin dunha expresin booleana na que poden utilizarse eventos e os valores das
varibeis do modelo e que unicamente avaliada no intervalo temporal delimitado polos
valores dos atributos delay e limit.
Atributos:
delay, expresin temporal que indica a demora antes da que a expresin non pode ser
avaliada. O valor resultado da avaliacin da condicin non tido en conta antes de
transconrer o perodo de tempo indicado polo valor deste atributo.
limit, expresin temporal que indica o lmite temporal despois do cal a expresin non pode
ser avaliada. O valor resultado da avaliacin da condicin non tido en conta unha vez
transcorrido o perodo de tempo indicado polo valor deste atributo.
^
5.1.2.2. O paquete Grafcet Core

Neste paquete definense as metaclases que representan os elementos sintcticos bsicos do
Grafcet (Figura 5.5) e os agrupamentos destes elementos en estructuras mais complexas como
macroetapas e grafcets conexos (Figura 5.6). A descricin detallada das metaclases deste
paquete a seguinte:
164
Nodo do modelo ("GrafcetNode")

Esta metaclase representa os nodos que forman parte dun modelo Grafcet, xa sexan etapas
ou transicins. Un nodo pode participar nunha ou mais secuencias de control, dicir, pode
conectarse a mltiples nodos que o precedan ou sucedan nas secuencias nas que participe. Esta
unha metaclase abstracta.
Atributos:
links, indica a posicin que pode ocupar o nodo nunha secuencia de control (se pode ter
predecesores e/ou sucesores).
Asociacins:
predecessor, indica os predecesores do nodo nas secuencias de control nas que este
participa.
successor, indica os sucesores do nodo nas secuencias de control nas que este participa.
ModelElement
(hom UML Metamode^
predecessor
^^
GâfcetNode
links : NodeType
` ^J
successor
GrafcetAction
(hom GufeHAeUor^
Transition
actions
^ type : StepType
1
receptivity ^ t
state I 1
ActionAssociation
(from GrafoelANOn^
StepState
(trom Grafoet DaL)
ForcingOrder
(trom Orafeet Actlons)
Grafc et 800 le anC ondit i on

(}rom Gufcet Data)
faces
situation
Situation
(from Outoet Datal
Figura 5.5. Diagrama de clases do paquete Grafcet Core: elementos bsicos.

ModelElement
(hom UML Metamoden
groups
ConnectedGrafcet
^
1..'
GrafcetNode
nodes links : NodeType
^
MacroExpansion
start
end
1^
SteP
1 type : StepType
Transition
t
expansion
,, Component
MacroStep
(Pattem)
Composite = {
Component,
'--------------------------------------------Container,
Container
Leaf
}
Figura 5.6. Diagrama de clases do paquete Grafcet Core: elementos xerrquicos.
165
Etapa ("Step")
Unha etapa representa un punto da secuencia de control susceptbel de realizar algunha
actuacin que modifique o estado do modelo. En cada instante da execucin unha etapa pode
estar activa ou non. Unicamente as etapas activas poden realizar actuacins. O conxunto de
etapas activas determina a situacin actual do modelo.
^
Unha etapa pode realizar mltiples actuacins que modifiquen o estado do modelo (e
indirectamente o do sistema controlado polo modelo).
O estado dunha etapa almacenado nunha varibel booleana do modelo que pode ser
utilizada nas condicins lxicas. Unha etapa pode participar nunha ou mais secuencias de
control. Poden conectarse a unha etapa mltiples transicins que a precedan ou a sucedan nas
secuencias nas que participe, mais non pode conectarse a outra etapa.
As etapas iniciais e as macroetapas son tipos especiais de etapas. O estado das primeiras
activado ao comezo da interpretacin do modelo. O conxunto de etapas iniciais determina a
situacin inicial dun modelo. En canto s macroetapas, son representacins abreviadas de
partes dun grafcet que cumpren unhas regras sintcticas especficas.
Atributos:
type, indica o tipo de etapa.
Asociacins:
state, indica a varibel do modelo que contn o valor do estado de activacin da etapa.
actions, actuacins realizadas pola etapa cando est activa.
Transicin ("Transition")
Unha transicin representa un punto da secuencia de control no que a execucin se detn ate
que se cumpra unha condicin determinada.
Unha transicin pode participar nunha ou mais secuencias de control. Poden conectarse a
unha transicin mltiples etapas que a precedan ou a sucedan nas secuencias nas que participe,
mais non pode conectarse a outra transicin. Tampouco correcto que unha transicin non
participe nunha secuencia de control (tea un valor none no atributo herdado links).
Asociacins:
receptivity, condicin lxica que debe cumprirse para continuar a execucin da secuencia
de control. As regras de evolucin do Grafcet (3.3.1) indican que o resultado da avaliacin
desta condicin s se ten en conta cando todas as etapas que preceden transicin estean
activas, excepcin feita das transicins fonte (as que teen o valor source no atributo
herdado links) que estn sempre validadas.
Macroetapa ("MacroStep")
Unha macroetapa un tipo especfico de etapa que representa de forma abreviada un
conxunto conectado de etapas e transicins denominado macroexpansin da macroetapa. Unha
macroetapa pode aparecer nun grafcet na mesma posicin que calquera outra etapa e o seu
estado depender do estado das etapas da sa macroexpansin. As macroetapas non teen
actucins asociadas.
No metamodelo representouse como unha metaclase derivada de Step para modelar as as
asociacins e restriccins especficas que non comparte cos demais tipos de etapas. O valor do
atributo herdado type ten que ser igual a macro nesta metaclase. Ntese que para modelar o
166
feito de que unha macroetapa un nodo que contn outros nodos na sa macroexpansin,
aplicouse o patrn de deseo Composite [67].
Asociacins:
expansion, indica o grafcet conexo que representa a macroexpansin da macroetapa.
Grafcet conexo ("ConnectedGrafcet")

Un grafcet conexo unha agrupacin de nodos na que todos estn conectados entre si,
directa ou indirectamente a travs doutros nodos. Cada nodo dun modelo unicamente pode
pertencer a un grafcet conexo.
Asociacins:
nodes, nodos agrupados no grafcet conexo.
Macroexpansin ("MacroExpansion")
Unha macroexpansin un tipo de grafcet conexo que modela os contidos dunha
macroetapa. As macroexpansins teen unha restriccin sintctica, teen que comezar e
rematar por unha nica etapa, de xeito que a substitucin dunha macroetapa pola sa
macroexpansin mantea a correccin sintctica do modelo.
Asociacins:
start, indica a etapa de comezo da macroexpansin.
end, indica a etapa final da macroexpansin.
5.1.2.3. O paquete Grafcet Actions

No paquete Grafcet Actions definense as metaclases que permiten modelar as actuacins
asociadas s etapas dun Grafcet: accins e ordes de forzado. A Figura 5.7 mostra o diagrama de
clases deste paquete e a relacin entre as metaclases definidas e as metaclases UML
comentadas en (5.1.1.1). A descricin detallada das metaclases deste paquete a seguinte:
Accin do modelo ("GrafcetAction")
Esta metaclase a base de todas as actuacins que poden realizarse nunha etapa dun grafcet.
Actualmente hai definidos dous tipos de actuacins: as accins e as ordes de forzado. Calquera
outra actuacin que poida definirse no futuro incluirase no metamodelo como derivada desta
metaclase. Esta unha metaclase abstracta.
Asociacin ("ActionAssociation")
Derivada da metaclase GrafcetAction, representa os bloques de accin asociados a unha
etapa segn o definido no estndar [86]. Cada bloque de accin IEC (3.6.1.3) ten catro partes:
un nome, un indicador, un cualificador e unha implementacin. O nome e o indicador son
varibeis booleanas modificadas polo bloque durante a sa execucin, e o cualificador indica a
semntica da sa execucin. No metamodelo inclense ademais algunhas caractersticas
adicionais non definidas polo IEC, como os bloques condicionais ou as accins internas.
Atributos:
type, cualificador do bloque de accin. Os cualificadores definidos son: N, R, S, P, P 1 e P0.

Os cualificadores IEC: L, D, SD, DS e SL son representados no metamodelo mediante
unha condicin temporal asociada metaclase.
167

internal, indica se un bloque de accin debe ou non ser executado en situacins inestbeis
durante as evolucins internas do modelo. O valor deste atributo unicamente ten validez en
grafcets interpretados mediante un algoritmo de evolucin tipo ARS (3.3.2.2). O valor
deste atributo non pode ser true para bloques con cualificador tipo N, xa que internamente.
s poden executarse accins impulsionais.
a
Asociacins:
name, indica a varibel booleana do modelo modificada polo bloque de accin durante a
sa execucin, dacordo semntica indicada polo cualificador do bloque. A varibel non
pode ser un valor de entrada do proceso.
indicator, indica a varibel booleana do modelo modificada polo bloque de accin para
indicar a finalizacin da sa execucin. A varibel non pode ser un valor de entrada do
proceso.
condition, indica unha condicin temporal que modifica a semntica de execucin do

bloque de accin. Permite demorar, condicionar e limitar os efectos da execucin dunha
accin.
ModelElement
(from UMLMetamodal)
Feature
Action
(from UML Metamode^
(from UML Matamodel)
Behavioral Feature
GrafcetAction
(from UML Metamode^
GrafcetVar
(from Grafcet Data)
modify
name
o.. ^
indicator
Operation
(from UML Metamodep
O
^
specificatiord
Method
(from UML Metamodel)
'
set
ActionAssociation
ppe : ActionType
nternal : Boolean
Forcingorder
ype : ForderTppe
!/lOdlfy
condition
Actionlmplementation action
F
1
actrvate
ActionStateAssoc
^.. ^
GrafcetTemporizedCondition
(from Grafcet Data)
Figura 5.7. Diagrama de clases do paquete Grafcet Actions.
Bloque de accin (^ÂctionStateAssoc")

Metaclase que representa un tipo de bloque de accin que modifica unha varibel de estado
de accin ActionState (5.1.2.1}-. O estado da varibel modificada indica o estado de
activacin da accin e mediante a sa modificacin controlase a execucin do cdigo da
accin.
Asociacins:
action, indica a accin cuxa execucin controlada polo bloque de accin mediante a
modificacin do valor da varibel do modelo que almacena o seu estado de activacin.
168
Cdigo de accin ("ActionImplementation")

Esta metaclase representa a implementacin dunha accin. Deriva da metaclase UML
Method, polo que pode representar a implementacin de operacins definidas ou herdadas por
un grafcet. O medio utilizado para a implementacin da accin non especificado polo
metamodelo.
Asociacins:
modify, indica as varibeis do modelo accedidas (e posiblemente modificadas) dende a

implementacin da accin.
Orde de forzado ("ForcingOrder")

Metaclase que representa as ordes de forzado dacordo ao definido en [2]. No metamodelo
cada orde de forzado relaciona un par de grafcets parciais (Figura 5.8), o`forzador' e o forzado,
e especifica a situacin do grafcet forzado mentres a orde estea activa.
Atributos:
type, indica o tipo da orde de forzado.
Asociacins:
forcerOrder, indica o grafcet parcial que contn a etapa que a orde de forzado est
asociada, dicir, o grafcet `forzador'.
forcingOrder, indica o grafcet parcial cuxa situacin forzada.

situation, indica a situacin forzada.
5.1.2.4. O paquete Grafcet Hierarchy

No paquete Grafcet Hierarchy (Figura 5.8) definense as metaclases e relacins que permiten
modelar as estructuras xerrquicas do Grafcet: a estructural (3.2.2.3) e a de forzado (3.2.2.4),
as como o contexto dun modelo grafcet dentro dun modelo UML. A descricin detallada das
metaclases deste paquete a seguinte:
Grafcet global ("G1obalGrafcet")
Esta metaclase representa unha abstraccin do comportamento do sistema modelado e
constite o elemento de mis alto nivel na xerarqua estructural do modelo Grafcet. O contexto
o mesmo que o dos StateCharts no metamodelo LTML, polo que na prctica o metamodelo
proposto permite utilizar o Grafcet como alternativa a aqueles para a especificacin do
comportamento dos elementos dinmicos dun modelo iIML. Neste nivel estn definidas as
varibeis e accins utilizadas no modelo, e agrpanse os grafcets parciais que definen a sa
estructura.
Asociacins:
context, indica o elemento do modelo cuxo comportamento especificado polo grafcet

global.
actions, agrupamento das accins implementadas no grafcet global.
data, agrupamento das varibeis definidas no grafcet global.

subsystems, agrupamento dos grafcets parciais que definen a estructura do grafcet global.
169

context
-C^,
^..1 I
behavior
ModelElement
(from UML Metamoden
GlobalGrafcet o-
SystemVar
(from Grafcet Data)
^ -use ^
actions
GrafcetVar
Actionlmplementation
(irom Grafcet Data)
(from GrafcetAdions)
ConnectedGrafcet
(from Grafcet Core)
data
.
1
parts
subsystems 1..'
1
1
situation
PartialGrafcet
1
forcer ^1 1^ forced
Situation
(from Grafcet Data)
situation
1..' I nodes
groups
1..*
GrafcetNode
(from Grafcet Core)
nodes
forcingOrder
forcerOrder
ForcingOrder
forces
(from GrafcetActions)
w
Figura 5.8. Diagrama de clases do paquete Grafcet Hierarchy.

Grafcet parcial ("PartialGrafcet")
Esta metaclase representa unha abstraccin do comportamento dunha parte identificada do

elemento modelado. Na prctica constite un medio de reducir a complexidade do modelo
dividndoo en partes que poden ou non interactuar entre elas e que se organizan
xerarquicamente mediante as relacins de forzado.
As metaclases PartialGrafcet e ConnectedGrafcet son as que permiten representar a
xerarqua estructural dos modelos Grafcet. O nivel mais baixo da xerarqua est representado
polos nodos do modelo que se agrupan en grafcets conexos, que a sa vez forman grafcets
parciais. O conxunto de grafcets parciais define o comportamento dun grafcet global (e polo
tanto do elemento modelado).
Debido a que na prctica a utilizacin dos grafcets conexos como partes identificadas dun
modelo non habitual, coa excepcin das macroexpansins, no metamodelo proposto
representouse a relacin entre o grafcet parcial e os nodos que o forman por duplicado:
mediante a asociacin directa entre as metaclases PartialGracet e GrafcetNode, e mediante a
asociacin indirecta entre estas das clases a travs da metaclase ConnectedGrafcet. Deste
xeito o usuario do metamodelo pode elixir se utilizar ou non os grafcets conexos como
elementos significativos nos seus modelos.
Asociacins:
nodes, agrupamento dos nodos que pertencen ao grafcet parcial. Cada nodo est contido
tamn nun dos grafcets conexos que forman parte do grafcet parcial.
situation, indica a situacin actual do grafcet parcial, que o conxunto de valores dos
estados de activacin das etapas que forman parte do grafcet parcial. A situacin dun
grafcet global est determinada polas situacins dos grafcets parciais que o forman.

170
parts, agrupamento dos grafcets conexos que son parte dun grafcet parcial.
forcer e forced, ^ especifican a relacin xerrquica establecida entre dous grafcets parciais a
travs dunha orde de forzado. Esta xerarqua ten que ser acclica e non est permitido 0
forzado mltiple simultneo dun grafcet parcial durante a execucin do modelo.
5.1.3. Semntica esttica do modelo

Nesta seccin compltase a sintaxe abstracta do metamodelo cun conxunto de invariantes
expresadas utilizando a linguaxe OCL. Estas invariantes expresan a semntica esttica que as
instancias do metamodelo deben cumprir para formar un modelo sintacticamente correcto.
5.1.3.1. Clculo do peche transitivo
No metamodelo faise preciso expresar algunhas regras que comproben que unha instancia
dunha metaclase non est relacionada recursivamente consigo mesma (p.e. para indicar que a
xerarqua de forzado non pode conter ciclos). Precsase polo tanto dun medio para calcular o
peche transitivo dunha relacin (asociacin) a partir dunha instancia dunha metaclase dada.
OCL non especifica ningn operador ou operacin para realizar este clculo [113], polo que foi
preciso inclulo como parte do metamodelo proposto. A descricin xenrica do clculo do
peche transitivo a seguinte:
T-^transitiveClosure(closure : Set(T)) : Set(T);
transitiveClosure = if closure-încludesAll(closure->allAdjacents)
then closure
else transitiveClosure(closureûnion(closureâllAdjacents))
endif
O clculo faise recursivamente, inclundo os adxacentes dos elementos xa includos no

peche ate que non haxa mais adxacentes que inclur. Este clculo evita a recursividade infinita
en caso de ciclos, pois detense unha vez que todos os elementos adxacentes (directa ou
indirectamente) foron xa includos no peche. O clculo a partir dunha instancia podera facerse
do xeito seguinte:
allRelated(t: T) : Set(T);
allRelated = transitiveClosure(Set{t))
A relacin utilizada para o clculo do peche transitivo a adxacencia entre instancias de tipo
T. Presuponse no tipo T a existencia dunha operacin que devolva os adxacentes dun conxunto
de instancias (almacenados nun atributo denominado adjacents). A descricin desta operacin
a seguinte:
TâllAdjacents(s : Set(T)) : Set(T);
allAdjacents = s^collect(adjacents)-âsSet
Nas regras do metamodelo que utilizan a operacin transitiveClosure indicouse mediante un

comentario a relacin utilizada para o clculo do peche transitivo. A relacin as indicada ter a
mesma funcionalidade que a que se acaba de describir para a adxacencia. Deste xeito evtase a
necesidade de redefinir a operacin de clculo do peche transitivo para cada metaclase ou
relacin especfica.
171
5.1.3.2. Regras semnticas

Cdigo de Accin ("ActionImplementation")
1. Unha accin non pode modificar o estado dunha etapa, o estado doutra accin ou o valor
dunha varibel externa non modificbel.
self.GrafcetVar-^select(var ^
((var.ocllsTypeOf(StepState) or
var.ocllsTypeOf(ActionState)) and var.changeability = #frozen) or
(var.ocllsTypeOf(ProcessValue) and
var.oclAsType(ProcessValue).modifiable = false))--îsEmpty
Asociacin ("ActionAssociation")
1. As varibeis modificadas pola asociacin son booleanas.
-- nome
self name. value. ocllsTypeOf(Boolean)
-- indicador
self. indicator->notEmpty implies self. indicator. value. ocllsTypeOf(Boolean)
2. As varibeis modificadas pola asociacin estn definidas no mesmo grafcet global.

-- nome
self. Step.PartialGrafcet. GlobalGrafcet. data-încludes(self. name)
--indicador
self.indicator^notEmpty implies
self. Step. PartialGrafcet. GlobalGrafcet. data-încludes(self. indicator)
3. As varibeis accedidas pola condicin da asociacin estn definidas no mesmo grafcet

global.
self.condition^notEmpty implies
self.Step.PartialGrafcet.GlobalGrafcet.dataîncludesAll(self condition.allVars)
4. Unicamente as accins impulsionais poden ser internas.

self. internal= true implies self. type <> #N
5. As accins internas non poden ter condicins temporizadas (demoradas ou limitadas).
self.internal = true and selj.condition-^notEmpty implies
self.condition^delay.body = " and self.condition^limit.body = "
Bloque de accin ("ActionStateAssoc")

1. A accin activada polo bloque de accin pertence ao mesmo grafcet global que o bloque.
self. Step. PartialGrafcet. GlobalGrafcet. actions-încludes(self. action)
Condicin booleana do modelo ("GrafcetBooleanCondition")
Operacins auxiliares
l. a1lVars, calcula todas as varibeis accedidas dende unha condicin booleana, xa sexa
directamente ou a travs dun evento.
172
allVars : Set(GrafcetVar);
a1lVars = self.GrafcetVar-ûnion(self.Event->collect(var)-âsSet)
Estado de accin ("ActionState")
1. As varibeis que conteen os valores do estado de activacin das accins son de tipo
booleano.
self. value. ocllsTypeOf(Boolean)

Estado de etapa ("StepState")
l. As varibeis que conteen os valores do estado de activacin das etapas son de tipo
booleano.
self. value.ocllsTypeOf(Boolean)
Etapa ("Step")
1. Os antecesores dunha etapa s poden ser transicins.

self.predecessor^forAll(ocllsTypeOf (Transition))
2. Os sucesores dunha etapa s poden ser transicins.
self.successor^forAll(ocllsTypeOf ( Transition))
Evento ("Event")
,
1. Os eventos son cambios de estado de varibeis booleanas.
self. var. value. ocllsTypeOf(Boolean)
Grafcet conexo ("ConnectedGrafcet")

1. Todos os nodos agrupados nun grafcet conexo estn conectados directa ou indirectamente
entre eles.
self.nodes-^forAll(GrafcetNode nodel, node2 ^
nodel <> node2 implies
(nodel. a1lSuccessorsîncludes(node2)
or nodel.allPredecessors-încludes(node2)))
Grafcet global ("GlobalGrafcet")

l. O contexto dun grafcet global pode ser ou un clasificador ou unha caracterstica
dinmicaao
self.context.notEmpty implies
(self.context.ocllsKindOf(BehavioralFeature) or
self. context. ocllsKindOf(Classifier))
2. Os grafcets parciais relacionados mediante unha orde de forzado pertencen ao mesmo

grafcet global.
ao Esta regra especifica que o contexto dos modelos Grafcet o mesmo que o definido en UML para os
StateCharts.
173
self.subsystems^forAll(PartialGrafcet pg ^
self.subsystemsîncludesAll(pg.allForced) and
self.subsystemsîncludesAll(pg. allForcers))
3. A xerarqua de forzado acclica.

self.subsystems^forAll(PartialGrafcet pg ^
not(pg. allForcersîncl udes(p^)
4. Os identificadores dos grafcets globais son nicos.

G1obalGrafcet.alllnstances^forAll(g ^
g<> self implies g.name <> self.name)
5. Os identificadores dos grafcets parciais includos nun grafcet global son nicos.
selfsubsystems^forAll(PartilGrafcetpgl, pg2 ^
pgl <> pg2 implies pgl.name <> pg2.name)
6. Os identificadores das varibeis includas nun grafcet global son nicos.

self.data-^forAll(GrafcetVar varl, var2 ^
varl <> var2 implies varl.name <> var2.name)
7. Os identificadores das accins includas nun grafcet global son nicos.

self actions->forAll(Actionlmplementation actl, act2 ^
actl <> act2 implies actl.name <> act2.name)
8. Para cada accin includa nun grafcet global hai unha e s unha varibel co mesmo nome
que almacena o seu valor de activacin.
self.actions-^forAll(action ^
se f data^select(name = action.name and isOclType(ActionState))-^size = 1))
9. Para toda varibel includa nun grafcet global que almacene o valor do estado de activacin
dunha accin, hai unha e s unha accin.
self.data^forAll(GrafcetVar var^
var.ocllsTypeOf(ActionState) implies self.actions-^select(name = var.name)^size = 1)
10. Para toda varibel includa nun grafcet global que almacene o estado de activacin dunha
etapa, hai unha e s unha etapa.
self.data-^forAll(GrafcetVar var^
var.ocllsTypeOf(StepState) implies self.subsystems.nodes-^select(name = var.name)^size = 1)
11. As varibeis modificadas polas accins includas nun grafcet global estn definidas tamn
no mesmo grafcet global.
self.actions-^forAll(action ^
self. dataîncludesAll(action^Grafcet Var))
Grafcet parcial ("PartialGrafcet")
1. Os identificadores dos grafcets conexos includos nun grafcet parcial son nicos.
174

selfparts-^forAll(ConnectedGrafcet cgl, cg2 ^
cgl <> cg2 implies cgl.name <> cg2.name)
2. Os identificadores de nodos de igual tipo nun grafcet parcial son nicos.

self.nodes^forAll(GrafcetNode nodel, node2 ^
(nodel <> node2 and nodel.type = node2.type)
implies nodel.name <> node2.name)
3. Cada nodo dun grafcet parcial est includo nun (e s nun) dos grafcets conexos que incle.
self.nodes-^forAll(node ^
self parts^select(nodesîncludes(node))-^size = 1)
4. Todos os nodos dun grafcet conexo estn includos tamn no grafcet parcial que o contn.
self.parts^forAll(cg ^
self. nodesîncludesAll(cg-^nodes))
5. Para cada etapa dun grafcet parcial hai unha varibel no grafcet global que almacena o seu
estado de activacin.
self.node-^select(isOclType(Step))^forAll(step ^
self. GlobalGrafcet.data-încludes(step.state))
6. A situacin dun grafcet parcial incle unicamente varibeis de estado de etapas

pertencentes ao grafcet parcial.
self. node. includesAll(self.situation. a1lSteps)
1. a1lForced, calcula o peche transitivo dos grafcets forzados directa ou indirectamente por un
grafcet parcial dado ( o conxunto de grafcets parciais que pertencen a un nivel inferior da
xerarqua de forzado).
a1lForced : Set(PartialGrafcet); -- utiliza a relacin forcingOrder.forced (Figura 5.8)
allForced = transitiveClosure(forcingOrder.forced-âsSet)
2. allForcers, calcula o peche transitivo dos grafcets que forzan directa ou indirectamente a
un grafcet parcial dado ( o conxunto de grafcets parciais que pertencen a un nivel superior
da xerarqua de forzado).
a1lForcers: Set(PartialGrafcet); -- utiliza a relacin forcerOrder.forcer (Figura 5.8)
allForcers = transitiveClosure(forcerOrder.forcerâsSet)
Macroetapa ("MacroStep")
1. O valor do atributo herdado type sempre macro nunha macroetapa.
self.type = #macro
2. As macroetapas non teen accins asociadas.
self. actions-> isEmpty
175
3. Os tipos de etapas inicial e final dunha macroexpansin estn restrinxidos polo tipo da
macroetapa que pertencen.
self.links = #rtone
-- macroetapa fonte e sumidoiro
implies (self.expansion.start.links = #source
and self.expansion.end.links = #target)

self.links = #target -- macroetapa sumidoiro
implies (self.expansion.start.links = #both
and self.expansion.end.links = #target)
self.links = #source
-- macroetapa fonte
implies (self.expansion.start.links = #source
and self.expansion.end.links = #both)
self.links = #both
-- macroetapa
implies (self.expansion.start.links = #both
and self.expansion.end.links = #both)
Macroexpansin ("MacroExpansion")
1. As etapas inicial e final dunha macroexpansin son diferentes.
self.start <> self.end
2. A etapa inicial non pode ser unha etapa sumidoiro.
self.start.links = #both or
self.start.links = #source
3. A etapa final non pode ser unha etapa fonte.

self.end.links = #both or
self.end.links = #target
Nodo do modelo ("GrafcetNode")

1. Multiplicidade dos predecesores e sucesores dun nodo en funcin do valor do atributo
links.
node.links =#none
-- nodo fonte e sumidoiro
implies (node.predecessor-^size = 0
and node.succesor-^size = 0)
-- nodo sumidoiro
node.links = #target
implies (node.predeccesor^size > 0
and node. succesor^size = 0)
node.links = #source
-- nodo fonte
implies (node. predeccesor^size = 0
and node. succesor^size > 0)
node.links = #both
-- nodo normal
implies (node. predeccesor-^size > 0
and node. succesor-^size > 0)
2. Todos os nodos conectados entre si estn includos no mesmo grafcet conexo.

self.ConnectedGrafcet.nodes-încludesAll(self.allSuccessors) and
self. ConnectedGrafcet. nodes--încludesAll(self. a1lPredecessors)
176
l. allPredecessors, calcula o peche transitivo dos predecesores dun nodo: o conxunto de
todos os nodos que o preceden na secuencia de control.
a1lPredecesors : Set(GrafcetNode); -- utilzase a relacin predecessor (Figura S.S)
allPredecesors = transitiveClosure(self-^predecessorâsSet)
2. allSuccessors, calcula o peche transitivo dos sucesores dun nodo: o conxunto de todos os
nodos que o suceden na secuencia de control.
a1lSuccesors : Set(GrafcetNode); -- utilzase a relacin successor (Figura S.S)
a1lSuccesors = transitiveClosure(self^successor-âsSet)
Orde de forzado ("ForcingOrder")

1. As macroetapas non poden ser forzadas (o forzado debe facerse utilizando as etapas
includas na macroexpansin da macroetapa).
self.situation.allSteps^forAll(step.type <> #macro)
2. Todas as etapas forzadas estn contidas no grafcet parcial forzado.
self.forced. nodesîncludesAll(self.situation.allSteps)
3. A etapa que a orde de forzado est asociada est contida no grafcet parcial forzador.
self forcer. nodesîncludes(self.step)
Situacin ("Situation")
Oneracins auxiliares
1. a1lSteps, devolve o conxunto de etapas cuxos estados de activacin son almacenados na
situacin.
allSteps : Set(Step);
a1lSteps = self.StepState^collect(step)->asSet
Transicin ("Transition")
1. As transicins non poden ser fonte e sumidoiro ao mesmo tempo.
self.links <> #none
2. Os antecesores dunha transicin s poden ser etapas.
self. predecessor^forAll (ocllsKindOf(Step))
3. Os sucesores dunha transicin s poden ser etapas.

self.successor-^forAll(ocllsKindOf(Step))
4. As varibeis accedidas pola receptividade estn definidas no mesmo grafcet global.
self.PartialGrafcet.GlobalGrafcet.dataîncludesAll(self.receptivity.all vars)
177
Seccin 5.2: Implementacin do metamodelo
5.2. Implementacin do metamodelo

Para a utilizacin prctica do metamodelo proposto desenvolveuse unha librara C++ que
implementa as metaclases e asociacins nel definidas ao tempo que garante certos aspectos da
correccin sintctica durante a construccin dos modelos (p.e. a identificacin, a alternancia
etapa-transicin, etc.). Ademais a librara proporciona medios para realizar operacins como a
comprobacin da coherencia da xerarqua de forzado ou a substitucin de macroetapas.
5.2.1. Funcionalidade bsica

A librara est implementada partindo dun conxunto de clases que ofrecen unhas
funcionalidades bsicas: contedores e iteradores, representacin de varibeis e tipos de datos,
identificacin, `persistencia', etc. Algunhas destas funcionalidades son comns a outras partes
da ferramenta proposta nesta tese de doutoramento e outras foron deseadas para resolver
cuestins especficas relacionadas coa implementacin do metamodelo. Neste apartado
descrbense estas ltimas. Poden consultarse no Anexo B algunha das funcionalidades comns
con outras partes da ferramenta.
5.2.1.1. Identificacin
Relacionadas coa identificacin dos elementos dun Grafcet foron dous os problemas
principais que houbo que resolver:
1. A xeracin automtica de identificadores nicos.
2. O almacenamento de nodos de diferentes tipos con igual identificador nunha mesma
coleccin.
Para a resolucin do primeiro problema definiuse unha clase que funciona como
`repositorio' de identificadores numricos clasificados en categoras. Esta clase leva para cada
categora o rexistro dos identificadores que estn sendo utilizados e proporciona o
identificador numrico mis baixo dos que estean libres. Para reducir a memoria necesaria, o
rexistro de identificadores almacenado en forma de intervalos. No diagrama de clases da
Figura 5.9 mstranse as clases e relacins definidas.
O cdigo seguinte mostra un exemplo da utilizacin do repositorio na obtencin de
identificadores nicos para os nodos dun grafcet:
1. IdRepository ids;
2. ids.addCategory(`Step');
3. ids.addCategory(`Trans');
4. string step0 = ids.lockId(`Step');

5. string stepl0 = ids.lockId(`Step', `10');
6. string step20 = ids.lockld(`Step', `20');
7. bool isused = ids.isZdLocked(`Step', `1');
8. string trans0 = ids.lockId(`Trans');
9. string transl = ids.lockZd(`Trans');
l0.string transl0 = ids.lockZd(`Trans', `10');
ll.string transl0 = ids.lockId(`Trans', `10');
12.ids.unlockZd(`Trans', `10');
13.transl0 = ids.lockId(`Trans', `10');
//
//
//
//
//
//
//
//
//
//
reserva o primeiro libre (1)
reserva a etapa 10
reserva a etapa 20
devolve true
reserva a tranaicia 10
0 10 xa est reaervado
libera a transicin 10
reserva a transicin 10
O segundo problema aparece cando queren almacenarse nunha mesma coleccin mltiples
nodos Grafcet de diferentes tipos (etapas, transicins, ...). As coleccins utilizadas (B.1)
presupoen que os elementos almacenados teen un identificador alfanumrico nico, mais isto
non se cumpre para os nodos dun grafcet, pois posbel que unha etapa e unha transicin tean
178
o mesmo identificador. En consecuencia foi preciso definir un mecanismo que permitira utilizar
dous identificadores para cada obxecto:
l. Un identificador alfanumrico nico para os obxectos dun tipo dado (este o identificador
proporcionado polo usuario durante a definicin dos modelos).
2. Un identificador cualificado nico independente do seu tipo para todos os obxectos (este
o identificador utilizado internamente nas coleccins de obxectos).
IdRepository
addCategory( )
removeCategory( )
isCategory( )
t
lockld( )
unlockld( )
isldLocked( )
category
IdCategory
name
^ lockld( )
unlockld( )
isldLocked( )
Interoal
interval min
max
Figura 5.9. Diagrama de clases do repositorio de identificadores.
A relacin entre ambos identificadores debe ser moi estreita, de xeito que o clculo dun a
partir do outro sexa directo e que a modificacin dun actualice o outro automaticamente. O
diagrama de clases da Figura 5.10 mostra como se resolveu este problema.
A clase abstracta IdContainer define a interface que teen que implementar as clases que
incluan o mecanismo de dobre identificacin. A clase Identifier a que representa o
identificador proporcionado polo usuario4i. Esta clase define as operacins bsicas para realizar
comparacins, modificar e almacenar o identificador. A clase IdentifiedClass utilizada como
exemplo de como inclur a dobre identificacin nunha clase calquera. Nesta clase o atributo key
almacena o identificador utilizado internamente nas coleccins de obxectos e os operadores de
comparacin definidos estn implementados utilizando o valor deste atributo. Na
implementacin da librara cmprese a relacin key = Class_Name. identifier, polo que a partir
do seu valor inmediato obter o identificador e viceversa.
IdContainer
Storable0bject
getld( )
setld( )
getKey( )
getKeyList( )
getClassName( )
read()
write( )
getPersistencetd( )
Identifier
id : string
IdentifiedClass
key : string
operator--()
aperator-=( )
operator^( )
operator<()
operator<=()
operator>()
operator>=()
read( )
write( )
getValue( )
setValue( )
operator-( )
identifier operator-=( )
operator!=()
1
operator<()
operator<=( )
operator>()
operator>=( )
read( )
write( )
Figura 5.10. Diagrama das clases implicadas no mecanismo de identificacin.
41 Esta clase derivada da clase Storable0ject, que a que proporciona o soporte `persistencia' na librara
implementada.
179
O cdigo seguinte mostra un exemplo da utilizacin de identificadores:

14.Node node;
15.node.setId(`10');
16.string id = node.getId();
17.string key = node.getKey();
18.string type = node.getClassName();
// clase que implementa a dobre identificacin
/ / id = `10'
// key = `Node.10'
// type = `Node'
-'
5.2.1.2. Notificacins
Os modelos Grafcet son almacenados en memoria como grafos dirixidos cclicos con
estructura xerrquica. A informacin da estructura est repartida entre diferentes elementos e a
modificacin dalgn deles require a actualizacin da informacin que conteen os demais. Por
exemplo, a eliminacin dun nodo implica que o seu identificador sexa liberado (esta
informacin est no grafcet parcial que contn o nodo), as sas conexins eliminadas
(actualizacin dos nodos adxacentes) e os grafcets conexos actualizados (ao eliminar un nodo 0
grafcet conexo no que est includo pode dividirse en dous ou mais grafcets conexos). Para
proporcionar esta funcionalidade definiuse un mecanismo de notificacins42, cando un
elemento modificado e esa modificacin require actualizar a informacin almacenada noutro
lugar da estructura, o elemento afectado enva unha notificacin aos seus adxacentes indicando
o cambio realizado. O elemento da estructura que reciba a notificacin pode reenviala,
procesala ou simplemente ignorala. Un inconveniente deste mecanismo a posibilidade dunha
explosin combinatoria de notificacins que afecte ao rendemento. Na implementacim da
librara Grafcet isto non supuxo un problema, pois as notificacins realzanse ben entre
elementos de diferentes niveis xerrquicos, ben entre adxacentes directos do mesmo nivel, polo
que a propagacin ^dunha notificacin afecta a un nmero moi reducido de elementos. A Figura
5.11 mostra o diagrama das clases definidas para implementar esta funcionalidade.
As clases que manexen notificacins teen que implementar a interface
NotificationManager, que incle operacins para activar e desactivar a recepcin de
notificacins e un manexador xenrico -mtodo onNotification- que pode ser refinado nas
subclases. As notificacins son representadas mediante a clase xenrica Notification da que
poden derivarse diferentes tipos especficos de notificacins, ou ben utilizar o atributo info para
ese fin.
Not^cationManager
enabled
enable( )
disable( )
isEnabled( )
onNotification( )
Notification
O
info
1 I sender
^
NotficationReceiver
receiver ,
sender
NotificationSender
^sendNotification( )
Figura 5.11. Diagrama das clases implicadas no mecanismo de notificacin.
42 Este mecanismo unha implementacin do patrn de deseo Observer [67].
180
5.2.2. Clases da librara

A Figura 5.12 mostra as clases definidas para implementar a declaracin das varibeis
utilizadas nos modelos43. Todas as declaracins de varibeis utilizadas son instancias de clases
obtidas mediante a especializacin da clase parametrizada GescaVarDecl para diferentes tipos
de datos bsicos: SFCBooI, SFCInt, etc. As declaracins de varibeis que almacenan os valores
de estado de accins e etapas son instancias de clases derivadas de SFCBooI. Tamn se define
un contedor especfico -clase SFCVarDeclarations- para almacenar conxuntos de
declaracins^.
As clases que implementan as accins e receptividades mstranse no diagrama da Figura
5.13. Por conveniencia definronse algunhas clases abstractas -Enunciation, Statement,
Expression e InternalOrder- que permiten organizar conceptualmente as clases definidas.
Definiuse tamn un contedor especfico para almacenar as accins --clase SFCActionSeq-.
Ntese que na implementacin da librara agrupronse as metaclases ActionAssociation e
GrafcetTemporizedCondition nunha nica clase -SFCActionAssociation-, e que a situacin
forzada por unha orde de forzado agregada na clase SFCForcingOrder -atributo situation-.
O diagrama da Figura 5.14 mostra as clases abstractas que proporcionan os conceptos
bsicos utilizados para implementar as metaclases dos paquetes Grafcet Core (5.1.2.2) e
Grafcet Hierarchy (5.1.2.4) do metamodelo. Como pode verse definense dous contedores
especficos para almacenar nodos e grafcets -clases SFCNodeSeq e SFCSeq,
respectivamente-, obtidos por especializacin da clase parametrizada pdcid2ptrSeq. Ademais
destes contedores, as principais clases definidas son:
SFCRoot, clase base de todas as demais, implementa as interfaces IdContainer,
pdcptrSeqElem e NotificationSender proporcionando, respectivamete, as seguintes
funcionalidades: dobre identificacin (5.2.1.1); persistencia e semntica de asignacin por
valor (B.1); e recepcin de notificacins (5.2.1.2).
SFCNode, clase abstracta derivada de SFCRoot que implementa a metaclase GrafcetNode
(5.1.2.2). As asociacins cos nodos antecesores e sucesores son implementadas mediante
os atributos before e after -de tipo SFCNodeSeq-.
SFCBase, clase abstracta derivada de SFCRoot que proporciona as definicins comns a
todas as clases que participan na estructuracin xerrquica dos modelos Grafcet. As
instancias desta clase representan os diferentes niveis da xerarqua estructural. Os grafcets
contidos no nivel almacnanse no atributo sfcs -de tipo SFCSeq-.
A notificacin de cambios entre niveis xerrquicos diferentes implemntase mediante as
clases SFCChild e SFCParent. Estas clases son unha especializacin do mecanismo de
notificacin (5.2.1.2) mediante a cal todo elemento do modelo mantn unha referencia ao
nivel xerrquico inmediatamente superior. Mediante esta referencia poden propagarse as
notificacins dende os niveis inferiores da xerarqua aos superiores. A Tboa 5-I e a Tboa
5-II mostran as notificacins identificadas durante a implementacin da librara e unha
descricin da funcin realizada en cada clase que manexa a notificacin.
a3 A regra xeral utilizada para identificar as clases da libraria consistiu en tomar os nomes utilizados no
metamodelo e precedelos co prefixo SFC. En caso de que o nome do metamodelo contivese a palabra Grafcet esta
eliminada na librara.
44 Esta clase unha instanciacin da clase parametrizada pdcid2ptrSeq, que un dos contedores que forrna parte
da librara comn ( B.1).
181
SFCNodeContainer, clase abstracta derivada de SFCBase. Representa os niveis

xerrquicos do Grafcet que inclen nodos. Os nodos includos no nivel son almacenados no
atributo nodes ê tipo SFCNodeSeq-.
SFCConnectedBase, clase abstracta derivada de SFCNodeContainer que representa os

niveis xerrquicos que conteen nodos e nos que non se leva rexistro dos identificadores
utilizados.
:^ ---
pdcid2pirSeq
'
^'
^ bind(ModelDataDeclaration)
ModelDataDeclaration
vars
SFCVarDeclarations
r-----^
^T
GescaVarl)ecl r ^
I
bind(string)
, bind(tloat)
^ bind(boo^ ' .
SFCFIoat
SFCString
bind(nt) .
SFCInt
SFCBooI
f1
SFCStepState ^ ^ SFCActionState
Figura 5.12. Diagrama das clases que implementan a declaracin de varibeis.

Storable0bject
Enunciation
E
clone( )
read( )
wrte( )
pptrSeqElem
4
4
pdcptrSeqElem
Statement
Expression
pdcid2ptrSe
n
^ bind(SFCAction)
SFCActionSeq
SFCAction
SFCActionAssociation
name : string
type : ActionType
indicator : string
condition : string
intemal : bool
delay : double
limit : double
SFCReceptivity
condition : string
name : string actions

code : string
SFCFarcingOrder
type : FOrderType
forcedSFC : siring
situation : list<string>
Figura 5.13. Diagrama das clases que implementan accins e receptividades.
182

NotificationManager
NotificationSender
pdcptrSeqElem
IdContainer
SFCChild
SFCParent
parent
^
SFCRoot
id : Identifier
key : string
____
^
'E
' ____^
pdcid2ptrSeq
bind(SFCBase) ^ '^
SFCBase
sfc
sfcs : SFCSeq
SFCSeq
^^
;
1
SFCNode
before : SFCNodeSeq
after : SFCNodeSeq
links : NodeType
SFCNodeContainer
nodes : SFCNodeSeq
nodes I '
SFCConnectedBase
^
^
^
bind(SFCNode) ;
SFCNodeSeq
Figura 5.14. Diagrama das clases abstractas que dan soporte estructura dos modelos Grafcet.
O diagrama de clases da Figura 5.15 mostra a especificacin completa das clases que
implementan, as metaclases dos paquetes Grafcet Core e Grafcet Hierarchy do metamodelo e
cal a sa relacin coas clases abstractas da Figura 5.14. As clases SFCGlobal e SFCPartial
conteen a informacin sobre a utilizacin de identificadores no modelo -nos atributos pgids
e nodeids, respectivamente-. A clase SFCGlobal leva rexistro dos identificadores dos grafcets .
parciais que contn, e a clase SFCParcial os dos nodos45. Ntese que a clase SFCMacro
especializa tanto clase SFCNode como clase SFCNodeContainer, polo que implementa
simultaneamente a semntica dun nodo e a dun nivel da xerarqua estructural que contn outros
nodos ( os da sa macroexpansin).
A librara compltase con tres clases que implementan diferentes algoritmos para a
verificacin de propiedades sintcticas. Estas clases son as seguintes:
SFCFlattener, dado un modelo calcula o equivalente despois de substitur as macroetapas

polas sas correspondentes macroexpansins. Polo tanto o resultado o grafcet equivalente
ao orixinal sen macroetapas.
SFCMacroChecker, comproba a correccin sintctica das macroexpansins dun modelo

(3.2.2.2).
SFCFOChecker, comproba a coherencia da xerarqua de forzado dun modelo (3.2.2.4).
as A librara non implementa un mecanismo de identificacin automtico para os grafcets conexos, ainda que si
garante a sa unicidade.
183

SFCRoot
SFCTrans
SFCNode
SFCBase
SFCStepBase
SFCNodeContainer
condition : SFCReceptivitp
SFCGlobal
pgids : IdRepositorp
actions : SFCActionSeq
vars : SFCVarDeclarations
l
SFCStep
type : StepTppe
actions : list<Statement>
SFCCannectedBase
^
SFCPartial
nodeids : IdRepository
start
SFCMacro
SFCConnected
a description : string
Figura 5.15. Diagrama das clases que implementan a estructura dos modelos Grafcet.
5.2.3. Implementacin das operacins bsicas

Neste apartado descrbense as notificacins identificadas durante a implementacin e danse
algns detalles de como se implementou algunha das operacins bsicas da librara. A Tboa
5-I mostra as notificacins relacionadas con cambios na estructura dos modelos e a Tboa 5-II
as relacionadas coa identificacin dos elementos que conteen. Para cada notificacin indcanse
as clases que a procesan e dse unha breve descricin das operacins que realizan.
5.2.3.1. Insercin dun nodo
As operacins a realizar para a insercin dun nodo dependen do nivel da xerarqua do
modelo no que se insira. Basicamente consisten en comprobar a existencia de duplicados no
modelo (o que require un percorrido recursivo da estructura xerrquica), almacenar referencias
ao novo nodo, reservar o seu identificador (informacin almacenada en cada grafcet parcial) e,
se o caso, crear un novo grafcet conexo que o contea. Na Figura 5.16, na Figura 5.17 e na
Figura 5.18 mstranse as secuencias de mensaxes que implementan a insercin dun nodo nun
grafcet parcial, nun grafcet conexo e na macroexpansin dunha macroetapa, respectivamente.
5.2.3.2. Insercin dunha macroetapa
A insercin dunha macroetapa semellante dun nodo. A principal diferencia consiste en
que a comprobacin de duplicados, o almacenamento de referencias e a reserva de
identificadores ten que ter en conta non s a macroetapa senn tamn os contidos da sa
macroexpansin (que pode conter macroetapas aniadas). A Figura 5.19 mostra a secuencia de
mensaxes que implementa a insercin dunha macroetapa nun grafcet parcial.
5.2.3.3. Eliminacin dun nodo
A operacin de eliminacin consiste, basicamente, na eliminacin de referencias ao nodo, a
liberacin do seu identificador e a actualizacin da informacin dos grafcets conexos no caso
de que, despois da eliminacin do nodo, o grafcet conexo que o contia quede dividido en un
ou mis grafcets conexos. As macroetapas son eliminadas do mesmo xeito, coa diferencia de
184
que a eliminacin de referencias e a liberacin de identificadores ten que ter en conta tamn os
contidos da sa macroexpansin. A Figura 5.20 mostra a secuencia de mensaxes que
implementan a eliminacin dun nodo dun grafcet parcial.
5.2.3.4. Eliminacin dun grafcet conexo
A eliminacin dun grafcet conexo mais simple ca dun nodo, e consiste na eliminacin de
referencias ao grafcet conexo, a liberacin do seu identificador e a eliminacin de referencias e
liberacin dos identificadores dos nodos que contn. A Figura 5.21 mostra a secuencia de
mensaxes que implementan a eliminacin dun grafcet conexo contido nun grafcet parcial.
5.2.3.5. Modificacin do identificador dun nodo
A modificacin do identificador dun nodo require actualizar toda a informacin contida no
modelo que faga referencia a ese nodo a travs do seu identificador. Isto implica comprobar a
existencia de duplicados co novo identificador, liberar o identificador vello, eliminar as
referencias que utilicen o identificador vello tanto na estructura xerrquica como nos nodos
conectados ao nodo modificado, reservar o novo identificador e actualizar as referencias ao
nodo utilizando o novo identificador. A Figura 5.22 mostra a secuencia de mensaxes que
implementan .a modificacin do identificador dun nodo contido na macroexpansin dunha
macroetapa. Ntese que a, operacin de actualizacin de referencias ao nodo co novo
identificador faise utilizando a operacin descrita na Figura 5.18.
185

^
INSERTCONTENTS_SFC
Insercin de novos nodos nun SFCPaztial

nivel da xerarqua estructural.
Almacenar referencias (nodos)
DELETECONTENTS_SFC
Eliminacin de nodos nun nivel da SFCPartial

xerarqua estructural.
Eliminar referencias (nodos)
DELETE_SFC
Destruccin dunha particin nun SFCGlobal

Eliminar referencia (grafcet pazcial)
Liberar id. (grafcet pazcial)
ERASE_SFC
SFCPartial
Eliminaz referencia (grafcet conexo)
Liberar ids. (contidos grafcet conexo)
SFCConnected
Notificar DELETE (grafcet parcial pai)
Eliminar referencia (macroetapa)
Liberar id. (macroetapa)
Eliminar referencias nodos (macroexpansin)
Liberar ids. nodos (macroexpansin)
Calcular novos grafcets conexos
Actualizar o grafcet parcial pai
SFCMacro
Eliminaz referencia (macroetapa)
Liberaz id. (macroetapa)
Eliminaz referencias nodos (macroexpansin)
Eliminacin dunha particin nun SFCGlobal

nivel da xerazqua estructural.
SFCPartial
SFCConnected
SFCMacro
INSERT_SFC
Insercin dunha nova particin SFCGlobal

nun nivel da xerarqua estructural.
INSERT
Destruccin dun nodo.
Insercin dun novo nodo.
Idem DELETE SFC
Notificaz DELETE (grafcet parcial pai)
Eliminaz referencia (macroetapa)
Liberar id. (macroetapa)
Eliminaz referencias nodos (macroexpansin)
Idem DELETE SFC
Comprobar duplicados (id. grafcet parcial)
Inserir referencia (grafcet parcial)
Bloqueaz id. (grafcet parcial)
SFCPartial
Comprobaz duplicados (id. grafcet conexo)
Comprobaz duplicados (contidos gafcet conexo)
Inserir referencia (grafcet conexo)
Bloquearid.(grafcetconexo)
Bloquear ids. (contidos grafcet conezo)
SFCConnected
Inserir referencia (macroe[apa)
Bloquear id. (macroetapa)
Inserir referencias nodos (macroexpansin)
Bloquear ids. nodos (macroexpansin)
Notificar INSERT (grafcet parcial pai)
SFCMacro
Inserir referencia (macroetapa)
Bloqueaz id. (macroetapa)
Inserir referencias nodos (macroexpansin)
Bloquear ids. nodos (macroexpansin)
SFCPaztial
Eliminaz referencia (nodo)
SFCConnected
Elimnar nodo
Liberar id. (nodo)
Calcular novos grafcets conexos
Actualizar o grafcet pazcial pai
SFCMacro
Notificar i1NLOCKID
Eliminar nodo
SFCPartial
Inserir referencia ( nodo)
SFCCoimected
Notificar INSERT (erafcet narcial oail
DELETE
Idem DELETE_SFC
Tboa 5-I. Notificacins relacionadas coa modificacin da estructura dun modelo Grafcet.
186
, SETID_SFC
Modificacin do identificador dun SFCGlobal

Comprobar duplicados (novo id. grafcet parcial)
Liberar id. vello
Actualizar id. (grafcet parcial)
Bloquear novo id.
SFCPartial
Comprobar duplicados (novo id. grafcet conexo)
Liberar id. vello
Actualizar id. (grafcet conexo)
Bloquear novo id.
SFCConnected
Comprobar duplicados (novo id. macroetapa)
Liberar id. vello
Actualizar id. (macroetapa)
Bloquear novo id.
SFCMacro
Comprobar duplicados (novo id. macroetapa)
Liberar id. vello
Actualizar id. (macroetapa)
Bloquear novo id.
LOCKID_SFC
UNLOCKID_SFC
Bloqueo do identificador dun nivel SFCGlobal

da xerarqua estructural.
SFCPartial
Notificar LOCKID SFC (grafcet parcial pai)
SFCMacro
Notificar LOCKID SFC
Liberacin do identificador dun SFCGlobal

SFCPartial
Bloqueo
nodo.
IJNLOCKID
do identificador
Liberar id. (grafcet conexo)
Notificar iJNLOCKID SFC (grafcet parcial pai)
SFCMacro
Notificar UNLOCKID SFC
Consulta do estado de bloqueo do SFCGlobal

identificador dun nodo.
SFCPartial
LOCKID
Liberar id. (grafcet parcial)
SFCConnected
SFCMacro
CHECKID
Bloquear id. (grafcet conexo)
SFCConnected
Modificacin do identificador dun SFCConnected

nodo.
SETID
Bloquear id. (grafcet parcial)
Comprobar duplicados (novo id. nodo)
Liberar id. vello
Actualizar id. (nodo)
Bloquear novo id.
Comprobar duplicados (novo id. nodo)
Liberar id. vello
Actualizar id. (nodo)
Bloquear novo id.
Comprobar duplicados (id. grafcet parcial)
Comprobar duplicados (id. grafcet conexo)
Comprobar duplicados (contidos grafcet conexo)
SFCConnected
Notificar CHECKID (grafcet parcial pai)
SFCMacro
Notificar CHECKID
dun SFCPartial
Bloquear id. (nodo)
SFCConnected
Notificar LOCKID (grafcet parcial pai)
SFCMacro
Notificar LOCKID
Liberacin do identificador dun SFCPartial

nodo.
SFCConnected
SFCMacro
Liberar id. (nodo)
Notificar LTNLOCKID (grafcet parcial pai)
Notificar LJNLOCKID
Tboa 5-II. Notificacins relacionadas coa identificacin de elementos dun modelo Grafcet.
187

0
U
l0
______Y _
U
(n
m ^
^
c
l0
T
II
m
Y
T
^
V
^
W II
^
(p
a
Y ^
U
N
N
C
C
I
U
^ _ ___
^
Y
U
^ I I
d
II
Q .-.
LL W
^
^
C
d
(p
C
^
I
^
w ^,
^
^
Y N N
W Y ^
m
^ V ^ W N
y
U
W D C II
^ a;
v
N ^p o ^ ^-N.
^ U U N ^p
o
^ ^^
7
W V
II ^ p n ^ y
l0
^
n ^
Y I C^r-U
N
7
V ^ Y
W^
^ ^
^
U
^
O
^ p
r !I ^ ^ V
W
U
^d
] N
" ^
U
CL
^
Oj ^
W^V
d
N
C
0
_
d n P d E
O
^ a y lyJ ^
01 y
N
c
D
^ ^
^
^
V
O^ d
^+ ^
d' ^
O
X
N O
C
m
O
X
W
C
W
D
O
^
C
y
o i-.
C C
W
U
W
^ ^
Û
^ W O
^ ^
t] iT
W ^
fp
^ ^
lD p
`W O
j
O
C ^
O^
W
U
n._
C f0
W
Um
]
C
^
E^
o^
U^
1OV
Eo
QB
O ^
_ ^
m
U m
~_N ^
mm
v^
^
O0 m
Q w
Figura 5.16. Secuencia de mensaxes da insercin dun nodo nun grafcet parcial.
188
w
C
^
E
0 11
^
WY
x E
n
m ^
11
^
O Y
^^
..C.. ^
^
m 11
v 1
S`
,
o y m
C
^
l0
^ - '
g
i
^ ^ ^ ^ : .
^
^ ^
.^
--
p^
O.
C
^
m
w
W
^
P.
N ^
C d
C ^Q
C ^ U "
Y W n
^ II
9
II
^ ^
vW
l g
^ W
^ V
^^,
d
(p
^
y
Fy
y
Y_
^
>
^
^
l0
W _U
^
.
g
C
II .
11
V
N
m
^ '
a
2

L v
I^^/^ ^
`_____________________________________ ^ ^
_^
Y
U
O
^
8
W
^
Z
L'
tn
^
U
V
LL
L T V1
U
m
Y
n
N_
E
^
^ ^ C
; ^
^ ^-. ^ d^
E ^ 9 ^^. d
^-
m
V p
O
C
^
.^.
m
^ ^
2 ^Y ^rn
f0
^
d^
_
10
O^
^ ^ ^
X
m
.
C m
O^
E
^ ^
omm
cÊ
o ^
C
O ^
C y
O O
^ ^
^
a^
o W
î
am
^
^
C r
G^
O ^ m
C
s
î
E m m
a^^
Figura 5.17. Secuencia de mensaxes da insercin dun nodo nun grafcet conexo.
189
I
^
I
-. ............
..^
4
^
N
i
U
.......................^
..............i^
V^
^^
^
^
^
^^
^^
$ ^
^^
I ^
'
^
^
'
^^ ^'
! ^^
^^
:
îo;^^
.
^s
^^
^$
g
E
^.
^^
Figura 5.18. Secuencia de mensaxes da insercin dun nodo na macroexpansin dunha macroetapa.
190
^W
^--. V
^ m
^
$ ,^
^
J ^
LL
^_
m v m
y
W
^
}__._..._..v_...__^_.__._._^ _._.._...
^
^
^7 ^
I'
9' 11
?T
_.-___Y .__
vd
t.^
n
y
p
^
`m
^
Î
^ ^
W
^
T O 11.
0
W
W
EW
^
m ^
$
v
^
^ ,^
"
.-. c
ao
w
C j,
^
,i
W II
^^^^
c m
q
W u V
i
^ ^ ^..^
W
tJ v ^ ^
N
^.
Y
,_
m
^ m
rn ^_
Ti
m ^
w ^
l w
^ GDI U
^ ^j II
LL
T W D
^ W
NI
'^ ^ ^ ^
.^ ^ ^ ^
m ^
^ ^
`^ ^ E
^ ^ N
r;
^
U
LL
^
^ Y
^ W
'
î
^_ m
Î'
r
D
U
W
O
^
m
o
T
F
V
W
`v
(9
FT
U
W
E
O
LL
y
U
^
m
^
Y
y
d
^
P.
^
^
u
m
i0 8
^ ^ ^ ^ m
O^
E
^
W
^
c W^
L^
`m^
m O
N
O
W
O
^
W 9
^ ^
Q
C
`^
^
O
^{
v
m_
W
6oW
o
mî W
m
c_
C L
^c
mâci
N
a ^ d
c
{p
11 W V
oc
m ^
Ec^
OWW
UE
K^ W
W
aE
D
o
W
8v
E ^
O
^ co
c$E
o._ W
m ^ ^
E^fO
c c
m cl
m o ^
U D ^
``
a
^
a$
rood
o W '^
i^
Wax
E ^ 0
d_ -^
m
i`_v' ^ V
aW^
0
U
>
a ^^
^
W
m_
m ^
01m
m a
a=N
O m
Figura 5.19. Secuencia de mensaxes da insercin dunha macroetapa nun grafcet parcial.
191

on:SFCPartial
erase(node) _ :
parent := node.getParent()
DarentSFCConneded
erase(node) ;
getParent().notify(SFCMSG DELETE, node)

remwe(rade)
node.remweUnksQ
[node,iaMaoro()]
{false}
Qrue}
remove(node)
getPerentQ.notiy(SFCMSG_UNLOCIaO SFC, node)
urdockSFCIDa(node)
FJiminar o nodo do grafcet pardal
e do nodo conexo nos que estea
inserido. Uberar o aeu
iden6ficadoc Se unha
macroetapa liberar tamn oa
idenfificadores doa nodas da s0a
maeroexpansi0n
unlocklD(node.getTypeQ, node.getKey())
[Yor all node ( n) in node maeroexpasion]
unlocklD(n.getType(),n.getKeyQ)
[Yw all macro (m) in node macroexpesion]
unlockSFCIDs(m)
node.setPe rent( NULL)

removeSFC(node)
getPerent().notify(SFCMSG_UNLOCKID, nodB)
unlocklD(node.getTypeQ, node.getKeyQ)
node.aetParent(NULL)
remove(node)
r
.
.---.-..-.--...__....
csfw := recalwtateCSFCQ
[cetcs.empty0l
(true}
{talae}
^ remwePJl()
tirst := csf<s.begin0
Celcular se e eliminadOn do nodo

dividiu o grafcet conexo en varioa
sutprafceffi. Se asl, eaignar o
primeiro dos subgrafcets calculados
ao gratcet conexo
[Yor ell node ( n) in first[

n.setParent(this)
store(n)
[n.isMaao()1 {true}
{false}
atoreSFC(n)
csfca.ramove(first)
getPerent().notify(SFCMSG INSERT_SFC, Cg)
I[Yor aIl conneded grafcet (cg) in csfcs)
insert(cg)
I
Insedr os demais sutqrafceffi no
grafcet pardal que contn ao grafcet
conexo do que se eliminou o nodo.
Bloquear os idemficadorea dos novos
grafcets conexos.
id = getUniquelD(cg)
k := cg.getKeyQ
^ id := IocldD(k)
cg.setlDValue(id)
cg.setParenqthis)
store(cg)
^-----_-..._.........-`-'----_.-..---...--'--------`----.... U
f---......_ _ .................-Se o grafcet conexo non comn mais
nodos, eliminalo.
IMc'c"^c"'Y'll/l
Figura 5.20. Secuencia de mensaxes da eliminacin dun nodo do modelo.

Da:SFCPartial
Eliminar do grafcet parcial os

nodos contidos no grafcet conexo
erase(cstc
Î ['for all node (n) in csfc]
remove(n)
D uNockSFCIDs(csfc)
ûnlocklD(csfc.getType(), csfc.getKeyQ)
[Yor all node ( n) in csfc]
l.iberar os identificadores do
grafcei conexo e dos seus corttidos
uNoddD(n.getTypeQ, n.getKeyp)
t
[Yor all maao (m) in csfc]
unlodcSFCIDs(m)
Eliminar o grafcet conexo
csfc. setParent( N ULL)
^ removeSFC(csfc)
Figura 5.21. Secuencia de mensaxes da eliminacin dun grafcet conexo do modelo.
192
t^
_^
K o
0 10
v_
0 0
m`^
C `.
`m9
O V
ry O
_ m
`^
W ^
Q ^
Figura 5.22. Secuencia de mensaxes da modificacin do identificador dun nodo includo nunha macroexpansin.
193
5.3. Exemplos de modelado

Para ilustrar a utilizacin do metamodelo e da librara que o implementa, neste apartado
danse varios exemplos da sa utilizacin. Cada exemplo mostra unha estructura Grafcet, o
diagrama de obxectos que a representa mediante os conceptos definidos no metamodelo
proposto, e o cdigo C++ que crea a estructura en memoria utilizando a librara implementada.
5.3.1. Estructuras bsicas

5.3.1.1. Secuencia
19.// tipos de datos: inatanciacins explcitas
20.template GescaVarDecl<bool>;
21.template GescaVar<bool>;
22.typedef GescaVarDecl<bool> SFC_bool;
23.template GescaSystemVarDecl<bool>;
24.template GescaSystemVar<bool>;
25.typedef GescaSystemVarDecl<bool> SFC_system_bool;
26.SystemDataDeclSeq process_vars;
27.// creacin das entradas booleanas e asignacia aos canais de S/S
28.SFC_system_bool* inputl = new SFC_system_bool("a",
29.
30.
31.
"SIM:TCP_BOOL_SI 80",
"\\\\sim:tcp bool_8i_8o\\sim:tcp bool_8i_Bo\\in channel\\in channel_1",
READ);
32.process_vars.insert(inputl);
33.// modelo Grafcet
34.SFCGlobal global("GG");
35.// varibeis do modelo
36.SFC_bool* varl = new SFC bool("A");
37.global.vars.insert(varl);
38.// grafcets parciais
39.SFCPartial* sfcl = new SFCPartial("PG1");
40.global.insert(sfcl);
41.// etapas
42.SFCStep step0("0", SFCStep::initial);
43.SFCStep stepl("1");
44.SFCStep step2("2");
45.// asociacins etapa-accin
46.SFCActionAssociation* associationl = new SFCActionAssociation("A", S);
47.SFCActionAssociation* association2 = new SFCActionAssociation("A",
48.
R, "", "", 0, 0, true);
49.stepl.addAction(associationl);
SO.step2.addAction(association2);
51.// transicins
52.SFCTrans trans0("(0)");
53.SFCTrans transl("(1)");
55.// condicins de transicin
56.trans0.m_condition.setCondition("Ta");
57.transl.m_condition.setCondition("Ta");
58.trans2.m_condition.setCondition("a");
59.// enlacea directos
60.node_iterator s0 = sfcl->insert(step0);
61.node_iterator
62.node_iterator
63.node_iterator
64.node_iterator
t0
sl
tl
s2
= sfcl->insertAfter(s0,
= sfcl->insertAfter(t0,
= sfcl->insertAfter(sl,
= sfcl->insertAfter(tl,
trans0);
stepl);
transl);
step2);
65.node_iterator t2 = sfcl->insertAfter(s2,
66.sfc1->link(t2, s0);
trans2);

successor
O:Ste^
type = #initial
links = #both
predecessor
successor
(Ol:Transition rece tivi
links = #both
predecessor
successor
^step
194
GrafcetBoolea nCondition
body = ?a
read
Event
change = true
ActionAssociation
action tYPe = #S
type = #step
links = #both
predecessor
internal = false
successor
J11:Transition rece tivi

links = #both
predecessor
[R]
(2) a
successor
3..^t s
r-
type = #step
links = #both
predecessor
(a)
GrafcetBoolea nC ondition read

Event
change = true
body = `ta
ActionAssociation
type = #R
internal = true
modify
A:GrafcetVar
modify
successor
(21:Transition receptivity GrafcetBoolea nC on dition

body = a
links = #both
predecessor
var
read a:GrafcetVar
(b)
Figura 5.23. Exemplo de: a) secuencia; e b) representacin co metamodelo proposto.
5.3.1.2. Seleccin de secuencia

67.// modelo Grafcet
68.SFCGlobal global("GG");
69.// grafcets parciaia
70.SFCPartial* sfcl = new SFCPartial("PG1");
71.global.insert(sfcl);
72.// etapas
73.SFCStep step0("0", SFCStep::initial, SFCStep::out);
74.SFCStep stepl("1");
78.// tranaicins
79.SFCTrans trans0a("(O.a)");
80.SFCTrans transOb("(O.b)");
81.SFCTrans transla("(l.a)");
82.SFCTrans translb("(i.b)");
85.SFCTrans trans4("(4)", "", SFCTrans::in);
86.// ealaces directoa
87.node_iterator s 0 = sfcl->insert(step0);
88.node_iterator t 0a = sfcl->insertAfter(s0, t rans0a);
89.node_iterator t Ob = sfcl->insertAfter(s0, t ransOb);
90.node_iterator s l = sfcl->insertAfter(tOb, s tepl);
91.node_iterator t la = sfcl->insertAfter(sl, t ransla);
92.node_iterator t lb =
sfcl->insertAfter(sl, t ranslb);
93.node_iterator s 2 = sfcl->insertAfter(tla, s tep2);
94.node_iterator t 2 =
sfcl->insertAfter(s2, tr ans2);
95.node_iterator s 3 = sfcl->insertAfter(tlb, s tep3);
96.node_iterator t 3 = sfcl->insertAfter(s3, tr ans3);
97.node_iterator s 4 = sfcl->insertAfter(t0a, s tep4);
100. node iterator t4
= sfcl->insertAfter(s4,
trans4);
var
195
0
(O.b)
1
(O.a)
(1.a)
(1.b) ^
o: Stea
type = #initial
predecessor links = #source

predecessor
successor
(O.a):Transition
(O.bl:Transition
links = #both
links = #both
predecessor
su ccessor
successor
1:Ste^
predecessor
type = #step
links = #both
predecessor
successor
successor
(1.a):Transition
(1.b):Transition
links = #both
links = #both
predecessor
predecessor
successor
successor
2: Ste^
3:Steo
type = #step
type = #step
links = #both
links = #both
predecessor
predecessor
successor
successor
(2):Transition
(3):Transition
links = #both
links = #both
predecessor
predec ssor
successor
4: Steo
successor
type = #step
links = #both
predecessor
successor
(4):Transition
links = #target
(b)
Figura 5.24. Exemplo de: a) seleccin de secuencia; e b) representacin co metamodelo proposto.
5.3.1.3. Paralelismo
101.
102.
103.
104.
105.
106.
// modelo Grafcet
SFCGlobal global("GG");
// grafcets parciais
SFCPartial* sfcl = new SFCPartial("PG1");
global.insert(sfcl);
// etapas
107. SFCStep stepl("1", SFCStep::initial);
108. SFCStep step2("2");
110. // traasicina
111.
112.
113.
114.
SFCTrans trans0("(0)", "", SFCTrans::out);
SFCTrans transl("(1)");
SFCTrans trans2("(2)");
// enlaces directos
115.
node_iterator t0 = sfcl->insert(trans0);
116.
117.
118.
119.
120.
121.
122.
node_iterator sl = sfcl->insertAfter(t0,
node_iterator tl = sfcl->insertAfter(sl,
node_iterator s2 = sfcl->insertAfter(tl,
node_iterator s3 = sfcl->insertAfter(tl,
node_iterator t2 = sfcl->insertAfter(s2,
sfcl >link(s3, t2);
sfcl->link(t2, sl);
stepl);
transl);
step2);
step3);
trans2);
196

LO^ransition
links = #source
predecessor
successor
1:Sten
predecessor
type = #initial
links = #both
predecessor
(0)
1
(1)
successor
(1):Transition predecessor
links = #both
predecessor successor
successor
(2)
3: Ste
2: Ste
type
= #step
type = #step
links = #both
links = #both
predecessor
predecessor
successor
(2):Transition successor
successor links = #both
{a)
( b)
Figura 5.25. Exemplo de: a) secuencias paralelas; e b) representacin co metamodelo proposto.
5.3.1.4. Semforo
123. // modelo Grafcet
124. SFCGlobal global("GG");
125. // grafcets parciais
126. SFCPartial* sfcl = new SFCPartial("PG1");
127. global.insert(sfcl);
128. // etapas
129.
130.
131.
132.
SFCStep
SFCStep
SFCStep
SFCStep
stepl("1", SFCStep::initial);
step2("2");
step3("3", SFCStep::initial);
step4("4", SFCStep::initial);
134. // tranaicias
135.
136.
137.
138.
139.
SFCTrans transl("(1)");
// enlaces directos
140. node_iterator sl = sfcl->insert(stepi);
141.
142.
143.
144.
node_iterator
node_iterator
node_iterator
node_iterator
tl
s2
t2
s3
=
=
=
=
sfcl->insertAfter(sl, transl);
sfci->insertAfter(tl, step2);
sfcl->insertAfter(s2, trans2);
sfcl->insertBefore(t2, step3);
145. sfcl->link(t2, sl);
146. sfcl->link(t2, s3);
147. node_iterator s4 = sfcl->insert(step4);
148. node_iterator t4 = sfcl->insertAfter(s4, trans4);
149. node_iterator s5 = sfcl->insertAfter(t4, step5);
150. node_iterator t3 = sfcl->insertAfter(s5, trans3);
151. sfcl->link(s3, t3);
197

[
4
^
5
(2)
(a)
1.Ste^
.
type = #initial
links = #both
predecessor
successor
(11:Transition
links = #both
predecessor
successor
2:Ste
type = #step
links = #both
predecessor
4:Ste
predecessor
type = #initial
links = #both
predecessor
successor
(4):Transition
links = #both
predecessor
successor
S:Stea
type = #step
links = #both
predecessor
predecessor
successor
successor
3:Steo
(21:Transition successor
successor (31:Transition
type = #initial
predecessor links = #both Predecessor
links = #both successor
successor links = #both
predecessor
predecessor
successor
successor
(b)
Figura 5.26. Exemplo de: a) secuencias exclusivas (semforo); e b) representacin co metamodelo proposto.
5.3.1.5. Accins
^_ ^[D#10s,L#ZOs] a &8^ c
0
a
(0)
[P] act0
act0
B=12;
(a)
successor
0: Steo
type = #initial
links = #both
ActionStateAssoc
bPe = #P
action internal = true
predecessor
body = B = 12
ActionAssociation
rype = #N
action internal = false
successor
(O1:Transition rece tivi

links = #both
predecessor
action actO:Actionlmplementation
GrafcetTem oorizedCondition
condition body = a 88 c
delay = 10s
limit = 20s
modify
B:GrafcetVar
read c:GrafcetVar
modify A:GrafcetVar
GrafcetBool eanCo ndftion

body
read
read
a:GrafcetVar
(b)
Figura 5.27. Exemplo de: a) accins; e b) representacin co metamodelo proposto.
198
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
// tipos de datos: instanciacias explcitas
template GescaVarDecl<bool>;
template GescaVar<bool>;
typedef GescaVarDecl<bool> SFC_bool;
template GescaSystemVarDecl<bool>;
template GescaSystemVar<bool>;
typedef GescaSystemVarDecl<bool> SFC_system_bool;

SystemDataDeclSeq process_vars;
// creacin das entradas booleanas e asigaacia aos canaia de $/S
SFC_system_bool* inputl = new SFC_system_bool("a",
164.
165.
"DDSIM:TCP_BOOL_8I_80",
"\\\\I^.1SIM:7CP_BOOL_SI_80\\LG6IM:ZCP BOOL_8I_80\\INPtTT Ci-IAtÎI^CS\\IIVP^JP C[^,_1",
166.
READ);
167. SFC_system_bool* input2 = new SFC_system_bool("c",
168.
"DDSIM:TCP_BOOL_8I_80",
"\\\\I7LlSIM:TCP BOOL 8I BO\\ffiISIM:RC^ BOOL 8I 80\\IIVPUf Q^:LS\\INP[TT CHÎEI, 2",
169.
170.
171.
172.
173.
174.
175.
- READ);
process_vars.insert(inputl);
process_vars.insert(input2);
// modelo Grafcet
// varibeis do modelo
176.
177.
178.
179.
180.
181.
182.
SFC_bool* varl = new SFC_bool("A");
SFC_bool* var2 = new SFC bool("B");
global.vars.insert(varl);
global.vars.insert(var2);
// bloques de cdigo
SFCAction* action0 = new SFCAction("act0", "B=12;");
global.actions.insert(action0);
- -
183. // grafcets parcisis
184. SFCPartial* sfcl = new SFCPartial("PG1");
185. global.insert(sfci);
186. // etapas
187. SFCStep step0("0", SFCStep::initial);
188. // asociacina etapa-accin
189. SFCActionAssociation* associationl = new SFCActionAssociation("A",
N, "","a&&c", 10, 20);
190.
191. SFCActionAssociation* association2 = new SFCActionAssociation("act0",
192.
193. step0.addAction(associationl);
194. step0.addAction(association2);
195. // transicias
196.
197.
198.
199.
200.
201.
202.
// condicins de transicia
trans0.m_condition.setCondition("a");
// enlaces directos
node_iterator s0 = sfcl->insert(step0);
node_iterator t0 = sfcl->insertAfter(s0, trans0);
sfcl->link(t0, s0);
5.3.2. Xerarqua
5.3.2.1. Macroetapas
203.
204.
205.
206.
207.
208.
209.
210.
// modelo Grafcet
// grafcets parciais
// etapas
SFCStep step0("0", SFCStep::initial);
SFCStep step2("2");
P, "","" 0, 0, true);
199
211. // transicina
212. SFCTrans trans0("(0)");
213. SFCTrans
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
transl("(1)");
// macroetapaa
SFCMacro macro100("M100", "Macro expansion");

^
macrol00.getStart()->setld("S100");
macrol00.getEnd()->setId("E100");
// nodos da macrotapa
SFCStep s tep101("101");
SFCTrans trans100("100");
SFCTrans trans101("101");
// enlace a directos da macroetapa
node_iter ator t100 = macrol00.insertAfter(macrol00.getStart(), trans100);
node_iterator s101 = macrol00.insertAf ter(t100, step101);
node_iter ator t101 = macrol00.insertAf ter(s101, trans101);
227. macrol00. link(t101, macrol0.getEnd());
228. // enlace s directos
229. node_iter ator s0 = sfcl->insert(step0);
230. node_iter ator t0 = sfcl->insertAfter(s0, trans0);
231. node_iterator m100 = sfcl->insertAfter(t0, macro 100);
232. node_iter ator tl = sfcl->insertAfter(m 100, trans l);
233. node_iter ator s2 = sfcl->insertAfter(t l, step2);
234. node_iter ator t2 = sfcl->insertAfter(s 2, trans2) ;
M 100
S100
(0)
(100 )
100
101
(1)
(101 )
E100
(2)
successor
(a)
O:Stea
type = #initial
links = #both
predecessor
start
S100:Ste^
type = #step
node
links = #both
predec ssor
successor
(Ol:Transi6on
links = #both
predecessor
successor
successor
100:MacroSteo
type = #macro
expansi
links = #both
predecessor
^
M 100:MacroExoansion
successor
101:Ste^
type
= #step
node
links = #both
predec ssor
successor
(1):Transition
links = #both
predecessor
successor
j101):Transition
successor
node links = #both
2.Steo
.
type = #step
links = #both
predecessor
successor
predece ssor
E100:Steo
node type = #step
links = #both
end
successor
(2):Transition
links = #both
predecessor
I1001:TransiUon
nodd links = #both
predec ssor
(b)
Figura 5.28. Exemplo de: a) macroetapa e macroexpansin; e b) representacin co metamodelo proposto.
200
5.3.2.2. Ordes de forzado
CG2
^3=
(0)
1
10
F/PG2: {11 }
(10)
^--{ F/PG2:^
11
(11)
(1)
CG1
PG1
PG2
(a)
GG:GIobalGrafcet
subsystem
subsystem
PG2:PartialGrafcet
pG1:PartialGrafcet
part
forcer
part
forcer
forced
forced
CG2: Con nectedGrafcet
CG 1:ConnectedGrafcet
successor
successor
(2):Transition
links
= #sourcd node
node
predecessor
O:Stea
node
type = #initial
links = #both node
preecessor
successor
successor
(0):Transi6on node
links = #both node
predecessor
:ForcingOrder
type = #force
successor
1:Steo
node
:ForcingOrder
type = #step
action
links = #both node
tYPe = #emPtY
predecessor
successor
(1):Transition
node
links = #both node

predecessor
2.Stea
node type = #step node

action links = #both
predecessor
successor
(3):Transition
links
= #targef^ node
node
10:Step
type = #initial n^
links = #both
pre ecessor
successor
(10):Transition
links = #both node

predecessor
successor
11:Steo
type = #step node
links = #both
predecessor
successor
(11):Transition
links = #both node
predecessor
(b)
Figura 5.29. Exemplo de: a) ordes de forzado; e b) representacin co metamodelo propostoab
236. // modelo Grafcet
237. SFCGlobal global("GG");
238. // grafcets parciais
239.
240.
241.
242.
243.
SFCPartial* sfc2 = new SFCPartial("PG2");
global.insert(sfc2);
// grafcets conexos
244. SFCConnected* csfcl = new SFCConnected("CG1");
245. SFCConnected* csfc2 = new SFCConnected("CG2");
a Por razns de simplicidade non se incluiu na figura a representacin das situacins forzadas polas ordes de
forzado.
201
246.
247.
248.
249.

// etapas
SFCStep step0("0", SFCStep::initial);
SFCStep stepl("1");
SFCStep step2("2");
250. SFCStep stepl0("10", SFCStep::initial);
251. SFCStep stepll("11");
252. // tranaicias
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
SFCTrans
SFCTrans
SFCTrans
SFCTrans
trans0("(0)");
transl("(1)");
trans2("(2)", "", SFCTrans::out);
trans3("(3)", "", SFCTrans::in);
SFCTrans
SFCTrans
transl0("(10)");
transll("(11)");
// ordes de forzado
SFCForcingOrder* forderl = new SFCForcingOrder("PG2", FORCE_EMPTY);
stepl.addAction(forclerl) ;
listestring> situation;
situation.push_back("11");
264. SFCForcingOrder* forder2 = new SFCForcingOrder("PG2", situation);
265. step2.addAction(forder2);
266. // enlaces directos
267. node_iterator s0 = csfcl->insert(step0);
268. node_iterator t0 = csfcl->insertAfter(s0,

269. node_iterator sl = csfcl->insertAfter(t0,
270.
271.
272.
node_iterator tl = csfcl->insertAfter(sl,
csfcl->link(tl, s0);
273.
274.
275.
276.
277.
278.
279.
280.
281.
node_iterator s2 = csfcl->insertAfter(t2,
node_iterator t3 = csfcl->insertAfter(s2,
sfcl->insert(csfcl);
sfcl->insert(csfc2);
trans0);
stepl);
transl);
node_iterator t2 = csfcl->insert(trans2);
step2);
trans3);
node_iterator s10 = sfc2->insert(stepl0);
sfc2->insertAfter(s10,
transl0);
node_iterator sil = sfc2->insertAfter(t10,

node_iterator tll = sfc2->insertAfter(sll,
stepll);
transll);
node_iterator t10 =
sfc2->link(tll, s10);
5.4. Conclusins
Neste captulo propxose un metamodelo para o Grafcet que define formalmente os ^
conceptos e regras utilizados na creacin de modelos coa ferramenta proposta nesta tese de
doutoramento. Este metamodelo est integrado no de iJML, polo que proporciona un medio de
integracin con outros formalismos especificados da mesma maneira (como acontece cos
StateCharts), e facilita a utilizacin do Grafcet para a especificacin de dinmicas complexas
como parte de metodoloxas de desenvolvemento "software" baseadas en ITML. Ademais
completouse o metamodelo definindo un conxunto de invariantes na forma de regras OCL que
poden ser utilizadas, mediante as ferramentas apropiadas, para a validacin automtica d
correcin sintctica dos modelos Grafcet representados utilizando o metamodelo proposto.
A utilizacin prctica do metamodelo realzase mediante unha librara C++, que implementa
os conceptos e regras nel definidos, ademais dun conxuto de clases auxiliares para a
comprobacin da correcin de caractersticas como a coherencia da xerarqua de forzado ou a
estructura interna das macroexpansins. Esta librara un medio de integracin do Grafcet en
calqueira aplicacin e, ademais, o soporte que incle `persistencia' dos modelos proporciona
indirectamente un formato de almacenamento que pode ser utilizado para o intercambio destes
entre aplicacins. As explicacins sobre a implementacin da librara non describen esta en
detalle, limitndose a mostrar como son aplicados algn dos mecanismos e tcnicas utilizados
na implementacin das operacins mis relevantes. O captulo compltase con algns exemplos
de modelado de distintos aspectos sintcticos dos modelos Grafcet.
Captulo 6. Compilacin de
modelos Grafcet
Para poder executar os modelos Grafcet representados mediante o metamodelo explicado en

(5.1), nos que o cdigo de accins e receptividades especificado utilizando unha linguaxe de
programacin de alto nivel (neste caso C++), preciso realizar prev.iamente a compilacin do
modelo para obter o cdigo obxecto que ser cargado e executado na mquina virtual. A
compilacin dun modelo Grafcet implica comprobar a sa correccin, crear unha
representacin optimizada para a sa execucin, transfonmar o cdigo de accins e
receptividades para facelas compilbeis cun compilador C++, xerar o cdigo fonte da DLL que
ser utilizada para cargar e executar o modelo na mquina virtual e, finalmente, compilalo para
obter o cdigo obxecto da DLL.
Neste captulo descrbese o compilador Grafcet desenvolvido para realizar as operacins
anteriores. No deseo da arquitectura lxica do compilador buscouse unha estructura de fases
flexbel, que permitira en futuras versins engadir, eliminar ou modificar fases facilmente.
Tamn se deseou unha tcnica que permite utilizar aplicacins externas durante a compilacin
para realizar diferntes operacins como, por exemplo, a simplificacin de expresins lxicas.
Esta tcnica permite cambiar a aplicacin externa utilizada sen que sexa necesario modificar o
cdio do compilador. Un aspecto do que o compilador fortemente dependente a linguaxe
utilizada para a especificacin de accins e receptividades. Nesta primeira versin, a
implementacin de varias das fases do compilador presupn que a linguaxe utilizada o C++.
En futuras versins podera inclurse soporte a outras linguaxes.
O resto do captulo estructurouse do xeito seguinte: no apartado (6.1) descrbese o proceso
de compilacin e os arquivos e aplicacins implicados; no apartado (6.2) explcase a
estructura de fases do compilador e a informacin interna que manexa durante a compilacin;
no apartado (6.3) detllanse os aspectos relacionados coa utilizacin da linguaxe C++ para a
especificacin do cdigo de accins e receptividades, as como as extensins que foi preciso
implementar para dar soporte aos operadores Grafcet de evento e temporizacin; no apartado
(6.4) descrbese o formato utilizado para representar os modelos Grafcet durante a sa
execucin na mquina virtual; no apartado (6.5) explcase en detalle a implementacin das
fases do compilador; e, finalmente, no apartado (6.6) resmense algunhas conclusins.
6.1. O proceso de compilacin

O proceso de compilacin dun modelo Grafcet resmese na Figura 6.1. O compilador recibe
como entradas o modelo Grafcet a compilar -arquivo model.sfc- e as opcins de
203
204
Captulo 6: Compilacin de modelos Grafcet
configuracin do proceso de compilacin -arquivo options.cfg-. A partir destas entradas e

ca asistencia de das aplicacins externas preprocess e sidoni-, xranse como resultado da
compilacin dous arquivos -model.h e model.cpp- que conteen o cdigo fonte en C++
dunha DLL. A compilacin do cdigo desta DLL realzase mediante unha terceira aplicacin
externa -compile- que xera o cdigo binario que poder ser cargado posteriormente na
mquina virtual, e que contn a informacin e funcins precisas para a execucin do modlo.
Ademais o compilador tamn proporciona unha listaxe dos erros atopados durante a
compilacin -arquivo model. err-, no caso de habelos.
model.err
compile.bat
model.sfc options.cfg
^^
model.h
model.cpp
model.lib
model.dll
compiler.exe ^^
preprocess.bat^ ^^ sidoni.bat
Figura 6.1. Proceso de compilacin dun modelo Grafcet.
No resto desta seccin explcanse certos aspectos relacionados cos arquivos de entrada e
sada do compilador, coas aplicacins externas utilizadas e co proceso realizado durante a
compilacin.
6.1.1. Os arquivos de entrada

O compilador recibe dous arquivos de entrada:
1. O modelo Grafcet, creado mediante a librara que implementa o metamodelo explicada en
(5.2). O cdigo de accins e receptividades suponse especificado en C++ coas extensins
que se detallan en (6.3.1).
2. As opcins de configuracin. O compilador recibe esta informacin mediante unha
instancia da clase SFCCompilationlnfo, cuxa declaracin (simplificada) a seguinte:
282 . s truct SFCComp ilationInfo
283. {
string project_name;
284.
string projectâth;
285.
string sfcppâth;
286.
string compiler_name;
287.
string iomap_file;
288.
deque<string> user_libs;
289.
bool simultaneous;
290.
// proxecto Grafcet
//
//
//
//
//
compilador Grafcet
compilador C++
declaracins 8/S
libraras exteraas
êventos simultneos?
291. }
A informacin almacenada nos atributos desta clase a seguinte:

1. Nome e localizacin do proxecto -atributos project_name (lia 284) e projectâth (lia
285}-.
2. Localizacin do compilador Grafcet -atributo sfcppâth (lia 286}-.
3. Nome do compilador C++ externo -atributo compiler name (lia 287}-.
205
Seccin 6.1: O proceso de compilacin
4. Nome do arquivo que contn as declaracins das varibeis de proceso utilizadas -atributo
iomapfle (lia 288}-.
5. Ubicacin das libraras externas utilizadas polo usuario -atributo user libs (lia 289^.
6. Indicador booleano da posbel ocorrencia de eventos simultneos utilizado na
simplificacin de expresins con eventos (6.5.1.5.3) -atributo simultaneous (lia 290^.
Basicamente estas opcins son utilizadas para indicar a localizacin dos arquivos temporais,
libraras e aplicacins externas utilizados durante a compilacin. O compilador presupn a
existencia dunha estructura de directorios como a da Figura 6.2. O executbel do compilador
Grafcet est almacenado no directorio principal -atributo sfcppâth-. Dentro deste
directorio hai catro subdirectorios que conteen o seguinte:
1.
2.
include, os arquivos de cabeceira (.h) das libraras utilizadas polo compilador Grafcet.
lib, as libraras utilizadas polo compilador.
3. systeml0, a localizacin por defecto dos arquivos coas declaracins das varibeis de
proceso.
4.
compilers, a informacin precisa para acceder s aplicacins externas utilizadas polo

compilador. Hai un subdirectorio para a aplicacin Sidoni ( 1.3.3) que sirve para a
simplificacin de expresins booleanas con eventos, e un subdirectorio por cada
compilador C++ soportado polo compilador Grafcet. O compilador C++ utilizado para o
preprocesado do cdigo de accins e receptividades e para a compilacin do cdigo fonte
da DLL xerado polo compilador Grafcet.
^] Sfcpp
^ d Compilers
l^ Sidoni
^^^ Vcpp60
'- ^d Include
=--1 Lib
^--^ Systeml0
Figura 6.2. Estructura de directorios utilizada polo compilador Grafcet.
Ademais o compilador utiliza un directorio adicional para o almacenamento dos arquivos

temporais e dos arquivos resultado do proceso de compilacin. Este directorio crease dentro do
directorio do proxecto - atributo projectâth- co nome compiled.
6.1.2. O resultado da compilacin

A compilacin dun modelo Grafcet produce como resultado dous arquivos (Figura 6.1) que
conteen o cdigo C++ necesario para crear, mediante un compilador externo, unha DLL que
permita cargar na mquina virtual a informacin precisa para a execucin do modelo. En
(6.5.1.9) pode verse a estructura do cdigo xerado para unha DLL xenrica, que consta,
basicamente, de tres partes:
1. O cdigo que inicia a informacin do modelo durante a carga da DLL en memoria. A
estructura desta informacin descrbese en (6.4) e consiste nunha clase que facilita o
acceso tanto informacin estructural como s funcins da DLL nas que se incle o cdigo
do modelo.
2. As funcins C++ que conteen o cdigo do modelo: accins, condicins de accin,
temporizadores e condicins de transicin.
206
3. A implementacin da interface que permite a carga e descarga de mdulos executbeis na

mquina virtual (7.1.1.5). A informacin do modelo crgase dinamicamente na mquina
virtual utilizando esta interface.
6.1.3. As aplicacins externas

Durante o proceso de compilacin preciso utilizar varias aplicacins externas que
proporcionen as funcins seguintes:
1. Simplificacin de expresins lxicas con eventos ( 6.5.1.5.3).
2. Preprocesamento do cdigo C++ dacordo s directivas de preprocesador (#define, #ifdef,

#include, etc.) presentes no cdigo.
3. Compilacin do cdigo fonte xerado polo compilador Grafcet e enlazado da DLL resultado
coas libraras que acompaan ao compilador mis as proporcionadas polo usuario.
Durante o deseo do compilador Grafcet quxose manter a independencia entre a sa
implementacin e as aplicacins externas, de xeito que se proporcionase unha tcnica sinxela
que permitira utilizar diferentes simplificadores de expresins lxicas, preprocesadores,
compiladores ou enlazadores sen que iso requirise modificar o cdigo do compilador. Ademais
esta caracterstica facilitara, en futuras versins do compilador, dar soporte a outras linguaxes
diferentes ao C++. A tcnica utilizada consiste en acceder dende o compilador Grafcet s
aplicacins externas a travs de clases "wrapper" que executan arquivos de comandos do
sistema operativo (arquivos . bat en Windows). Estas clases son responsbeis tamn de realizar
as operacins de conversin de formatos e a creacin e manexo de arquivos temporais cando
sexa necesario.
^
Por exemplo, no caso da compilacin e enlazado da DLL resultado, definiuse unha clase
SFCCPPCompiler -derivada de SFCCompilerPhase (6.2^, que ten a interface pblica
seguinte:
292.
293.
class SFCCPPCompiler : public SFCCompilerPhase

{
294.
295.
2 96 .
297.
public:
explicit SFCCPPCompiler(Phase* phase);
bool operator ( ) ( ) ;
};
Como a clase define o mtodo operator()47, as sas instancias poden utilizarse no cdigo
C++ do mesmo xeito que as funcins. O cdigo para chamar ao compilador externo dende o
compilador Grafcet sera o seguinte:
298. // definicia e invocacia do "wrapper^ do compilador C++
299. SFCCPPCompiler compiler(<anyârent^hase>);
300. compiler();
A implementacin do mtodo operator() executa o arquivo de comandos denominado

compile.bat localizado no subdirectorio do directorio compilers (Figura 6.2) indicado nas
opcins de compilacin - atributo compiler_name-. No caso do compilador Visual C++ este
arquivo contn o seguinte:
301. nmake /C /S /F inakedll.mak CFG=%1 DLLNAME=%2 SOURCEPATH=%3 SFCPPPATH=%4 USER LIBS=%5
47 En C++ as instancias de clases que declaran este operador denomnanse obxectos funcin ("function objects").
207
Seccin 6.1: O proceso de compilacin
dicir que a aplicacin nmake executa as instruccins do arquivo makedll.mak48 cos

argumentos pasados pola clase SFCCPPCompiler na chamada a compile.bat (indicados como
%l, %2, etc.). Estes argumentos proporcionan informacin sobre a versin da DLL a crear, o
nome e localizacin dos arquivos fonte a compilar e a localizacin do compilador Grafcet e das
libraras externas proporcionadas polo usuario.
Esta tcnica permite modificar a compilacin da DLL editando os arquivos compile.bat e
makedll.mak, sen afectar implementacin do compilador Grafcet. Ademais pode utilizarse un
compilador C++ diferente seguindo os pasos seguintes:
1. Crear un subdirectorio no directorio compilers (Figura 6.2) de nome igual ' ao do
compilador C++.
2. Inclur no subdirectorio un arquivo denominado compile.bat cos comandos que realizan a
compilacin utilizando o novo compilador.
3. Pasarlle ao compilador Grafcet o nome do subdirectorio como parmetro de configuracin.
A mesma tcnica foi aplicada coas outras das aplicacins externas utilizadas. Para a
simplificacin de expresins lxicas con eventos utilizouse a aplicacin Sidoni ( 1.3.3),
accedida dende o compilador Grafcet a travs da clase SidoniWrapper, que realiza as
conversins de formatos precisas e executa o arquivo sidoni.bat almacenado no subdirectorio
sidoni do directorio compilers (Figura 6.2). Para o preprocesamento do cdigo C++ de accins
e receptividades utilzase a clase CPPActionPreprocessor, que executa o arquivo
preprocess.bat almacenado no subdirectorio do directorio compilers indicado nas opcins de
compilacin - atributo compiler_name-.
6.1.4. As operacins realizadas polo compilador

As principais operacins que o compilador Grafcet realiza para obter a DLL resultado a
partir dun modelo Grafcet son as seguintes:
1. Comprobacin da correccin do modelo Grafcet. O compilador Grafcet recibe como
entrada un modelo creado utilizando a librara explicada en (5.2). Esta librara garante que
os modelos con ela construdos cumpran a regra sintctica da alternancia etapa-transicin e
que non existan duplicados nos identificadores de grafcets parciais, etapas (e macroetapas),
transicins e accins. O compilador comproba a coherencia da xerarqua de forzado
(3.2.2.4) e a correccin da estructura das macroexpansins (3.2.2.2).
2. Representacin da informacin estructural do modelo no formato utilizado para a sa
execucin (6.4). Esta operacin implica obter unha representacin do modelo sen
macroetapas, substitundo estas polas sas macroexpansins, almacenar a informacin de
grafcets parciais, etapas, transicins, accins, receptividades, etc. e substitur os
identificadores alfanumricos proporcionados polo usuario por identificadores numricos
nicos que sern os utilizados internamente durante a execucin do modelo.
3. Transformacin do cdigo de accins e receptividades. Como se explica en (6.3), o
cdigo de accins e receptividades non directamente compilbel nun compilador C++
estndar, pois contn operadores de evento e temporizacin que non son parte da linguaxe
C++. preciso polo tanto, substitur os eventos e temporizadores polo cdigo que
implementa o seu funcionamento, o cal forma parte dunha das libraras do compilador. O
mesmo pode dicirse do acceso aos valores das varibeis do modelo e de proceso que son
48 Os contidos do arquivo makedll.mak para o compilador Visual C++ poden verse no Anexo C.
208
almacenadas nunha base de datos na mquina virtual (7.3.1) durante a execucin do

modelo. Os seus nomes teen que ser substitudos polas chamadas s funcins da librara
que proporcionan acceso base de datos en tempo de execucin. As transformacins que se
realizan no cdigo son explicadas en detalle en (6.3.3).
4. Xeracin do cdigo fonte da DLL (en C++).
5. Compilacin e enlazado da DLL resultado coas libraras do compilador e mis as
proporcionadas polo usuario, utilizando un compilador C++ externo.
6.2. A estructura do compilador Grafcet

A arquitectura do compilador Grafcet est formada por un conxunto de fases organizadas
xerarquicamente formando un grafo^ dirixido acclico (Figura 6.6) mis a informacin xerada
durante o proceso de compilacin que todas as fases teen acceso. Cada fase responsbel de
realizar unha operacin concreta, accedendo (e modificando si preciso) esa informacin. As
fases do compilador exectanse secuencialmente, de xeito que cada fase utiliza a informacin
xerada polas fases previas e prepara a que utilizarn as fases posteriores. Cada fase pode ser
simple ou composta (formada por mltiples subfases), de modo que unha mesma subfase pode
estar contida en mltiples fases compostas e, en consecuencia, ser executada varias veces en
fases diferentes. A Figura 6.3 mostra o diagrama de clases que modela os aspectos bsicos que
permiten construr esta estructura.
----=--------------------------------------,
,
, ^
;,
Phase
ICom ilerDataAccesor
*
getRoot( )
root
operator( )
\
:
^,
^
; Component
{Pattern}
Composite = {
Component,
Container,
Leaf
}
1
Leaf
{friend} ;'
;
. ,
^ Container
'
;
,
,
,
,
MultiStepPhase
SFCCompilerPhase
SFCMuItiStepPhase
'
phases
addPhase()
deletePhases( )
operator()
^
_ _ _ _ _ _ _ SFCCom iler
'
` `.
^
;
^
^
^
operatorQ:
for all phase in phases
phaseQ
^^^^^^^^^_^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^_^^^_^^^^^^^^^^^^J
Figura 6.3. Diagrama de clases da estructura de fases do compilador Grafcet.
A relacin de agregacin entre fases modelouse aplicando o patrn de deseo Composite

[67]. A clase Phase proporciona a interface compartida por todas as fases, que poden ser
simples --clase SFCCompilerPhase- ou compostas --clase MultiStepPhase-. A clase
SFCCompiler, derivada de MultiStepPhase, a raz do grafo dirixido acclico que forman as
fases do compilador. Esta clase proporciona un punto de acceso comn s operacins que o
compilador realiza (aplicacin do patrn de deseo Facade [67]) e almacena a informacin
interna accedida e modificada polas fases durante a compilacin. Nos apartados seguintes
descrbese a informacin almacenada polo compilador, a sa estructura de fases e as tcnicas
utilizadas para a creacin e execucin das fases as como o acceso destas informacin do
compilador.
.
209
Seccin 6.2: A estructura do compilador Grafcet
6.2.1. A informacin interna do compilador

O cdigo seguinte mostra a parte da declaracin da clase SFCCompiler na que se define a
informacin utilizada internamente durante a compilacin dun modelo Grafcet:
302. class SFCCompiler : public MultiStepPhase
303. {
304.
friend class SFCCompilerPhase;
305. private:
306.
307.
308.
309.
310.
// entradas ao compilador
const SFCGlobal* sfc_model;

// modelo Grafcet
// declaracina das B/S do proceao
SystemDataDeclSeq systeml0;
SFCCompilationInfo* comp_info; // opcina de compilacin
// estructura do modelo Grafcet
311.
312.
313.
314.
RTSituation initial;
deque<RTPGInfo*> pgs;
deque<RTNOdeInfo*> nodes;
deque<RTActionInfo*> actions;
//
//
//
//
315.
deque<RTFOInfo*> forders;
// ordes de forzado
316.
317.
FOHierarchyLevels fo_levels;
deque<RTTimerInfo*> timers;
// aiveis da xerarqua de forzado
// temporizadores
318.
319.
320.
321.
322.
323.
// cdigo do modelo Grafcet
SFCActionSeq actions_code;
// accina
deque<RTReceptivityInfo*> recs; // receptividades
// informacin iaterna do compilador
/ / ideatificadorea iaternoa
deque<string> ids;
set<unsigned long> used_ids;
324.
325.
SFCCompilerPaths paths;
// arquivos e localizacibas auxiliarea
// erros de compilacin
SFCCompilerErrors* errors;
SFCCompilationTempData temp_data;
326.
327. } ;
aituacia iaicial
grafceta parciaia
nodos
accina
Esta informacin est formada por:

1.
A informacin de entrada ao compilador:

a. O modelo Grafcet a compilar -atributo sfc_model (lia 307^, no formato creado coa
librara explicada en (5.2).
b. As declaracins de varibeis do proceso49 -atributo systeml0 (lia 308}- utilizadas
no cdigo de accins e receptividades.
c. As opcins de compilacin (6.1.1) -atributo comp_info (lia 309}-.
2.
A informacin estructural do modelo (lias 311-317), utilizando o formato para a

representacin do modelo en tempo de execucin ( 6.4).
3.
O cdigo C++ de accins e receptividades (lias 319-320).
4.
Outras informacins auxiliares:

a. A informacin para a asignacin e conversin entre os identificadores alfanumricos
nicos asignados polo usuario s diferentes compoentes do modelo e os numricos
utilizados en tempo de execucin -atributos ids (lia 322) e used_ids (lia 323^--.
b. A localizacin dos arquivos temporais e aplicacins auxiliares utilizadas durante a
compilacin -atributo paths (lia 324^.
c. A listaxe de erros producidos durante a compilacin -atributo errors (lia 325}-.
d. A informacin temporal utilizada para configurar a execucin das fases do compilador
e almacenar os resultados intermedios (6.2.3) -atributo temp_data (lia 326^.
49 A declaracin das varibeis intemas estn includas no modelo Grafcet.
210

6.2.2. Acceso informacin interna do compilador
Para acceder informacin interna almacenada polo compilador, cada fase mantn unha
referencia -atributo root da clase Phase (Figura 6.3^ raz do grafo de fases do compilador
(que unha instancia da clase SFCCompiler) e implementa a interface ICompilerDataAccesor
declarada comoso:
328. struct ICompilerDataAccesor
329. {
330.
// entrada ao compilador
331.
virtual const SFCGlobal& model() const = 0;
virtual const SystemDataDeclSeq& getSysteml0() const = 0;
332.
virtual const SFCCompilationInfo& getOptions() const = 0;
333.
334.
// eatructura do modelo Grafcet
virtual RTSituation& initialSituation() = 0;

335.
336.
virtual deque<RTPGInfo*>& pgs() = 0;
337.
338.
339.
340.
341.
342.
virtual deque<RTNodeInfo*>& nodes() = 0;
virtual deque<RTActionInfo*>& actions() = 0;
virtual deque<RTFOInfo*>& forders() = 0;
virtual FOHierarchyLevels& folevels() = 0;
virtual deque<RTTimerInfo*>& timers() = 0;
// cdigo do modelo Grafcat
343.
344.
345.
virtual SFCActionSeq& actionscode() = 0;
virtual deque<RTReceptivityInfo*>& receptivities() = 0;
// mtodoa auxiliares
346.
347.
348.
349.
virtual
virtual
virtual
virtual
unsigned long getId(const string& key) = 0;
void registerld(unsigned long id) = 0;
bool isIdUsed(unsigned long id) const = 0;
SFCCompilerPaths& getPaths() = 0;
virtual void signalError(SFCCompilerErrMsg* err) = 0;
350.
virtual SFCCompilationTempData& getTempData() = 0;
351.
352 . } ;
Esta interface implemntase na clase SFCCompilerPhase da que derivan todas as fases

simples do compilador. Esta clase unha àmiga' (Figura 6.3) da clase SFCCompiler, polo que
ten acceso aos seus membros privados (entre eles a informacin interna do compilador). A
implementacin por defecto dos mtodos da interface ICompilerDataAccesor accede
directamente ao atributo do compilador no que est a informacin requirida. O seguinte cdigo
mostra, a modo de exemplo, como sera a implementacin dun destes mtodos:
353. SFCCompilationTempData& SFCCompilerPhase::getTempData()
354. {
SFCCompiler* pRoot = dynamic_cast<SFCCompiler*>( getRoot()

355.
assert( pRoot != NULL );
356.
return pRoot->temp_data;
357.
358. }
)7
Este mtodo de acceso permite que as fases redefinan estes mtodos para realizar as
operacins requiridas de iniciacin, comprobacin ou formatado da informacin do compilador
antes de ser utilizada pola fase. O seguinte cdigo mostra un exemplo de redefinicin do
mtodo anterior para unha fase hipottica:
359. SFCCompilationTempData& AnySimplePhase::getTempData()
360. {
SFCCompilationTempData& data = SFCCompilerPhase::getTempData();
361.
// iniciar, comprobar ou modificar aqu a informacin antea de utilizala
362.
return data;
363.
364. }
so A interface mostrada unha versin reducida. Na interface completa declranse das versins de cada mtodo,
unha a mostrada, e outra unha versin constante (p.e. virtual const RTSituation& initialSituationQ const = 0; ).
211
6.2.3. As fases do compilador

A Figura 6.4 e a Figura 6.5 mostran os diagramas de clases das fases definidas no
compilador Grafcet. As fases simples son derivadas da clase SFCCompilerPhase e as
compostas de SFCMuItiStepPhase. Cada unha das clases que modela unha fase, xa sexa simple
ou composta, redefine o operador operator() no que se implementan as operacins propias d
cada fase.
SFCCompilerPhase
operator Q : bool
SFCInfoHarvester
SFCAssociatianPreproccessor
EventExprContextHanester
SFCMacroPreprocessor
SFCDLLGenerator ^ ^ TimerPreprocessor
EventExprHarvester ^ ^ VarlnfoHarvest er
SFCFOrderCompiler
CPPActionPreprocessor 'I
EventExpressionCompiler
EveniVarTranslator
SFCCPPCompiler I
Figura 6.4. Diagrama de clases das fases simples do compilador Grafcet.

SFCMuItiStepPhase
operator Q : bool
1
SFCActionCodeCompiler
1
SFCEventCompiler
SFCTimerConditionCompiler
SFCActionConditionCompiler ^ ^FCReceptivityCompiler
Figura 6.5. Diagrama de clases das fases compostas do compilador Grafcet.
Durante a iniciacin do compilador constrese a estructura de fases da Figura 6.6, utilizando

a tcnica explicada en (6.2.4). Esta estructura un grafo dirixido acclico no que as fases
compostas SFCActionCodeCompiler, SFCActionConditionComîler, SFCReceptivityCompiler
e SFCTimerConditionCompiler comparten as mesmas subfasess .
: SFCInfoHarvester
: SFCFOrderComoiler
: SFCAssoationPreorocessar
: SFCActionCodeComoiler
: SFCComoiler
CPPAionPreprocessor ^
^ : EventExwHarvester
SFCTi m e rConditionCom oil e r
: SFCDLLGenerator
: SFCCPPComoiler
Figura 6.6. Estructura de fases do compilador Grafcet.
St A orde de execucin das fases mstrase na figura de esquerda a dereita e de amba a baixo
VarlnfoHarvester
EventVarTranslator
212
Nas catro fases indicadas nas que se compila respectivamente o cdigo C++ das accins,
condicins das asociacins, condicins de transicin e condicins dos temporizadores. As
operacins realizadas en cada caso son moi semellantes, polo que durante o deseo decidiuse
compartir a estructura de fases e configurar as opcins especficas de cada caso mediante a
informacin almacenada no compilador, nunha instancia da clase SFCCompilationTempData.
^'
A interface pblica desta clase a seguinte:
365. struct SFCCompilationTempData
366. {
367.
// "buffera" temporais para almacenar as transformacins no cdigo
368.
stringstream original_code;
369.
stringstream preprocessed_code;
370.
stringstream modified_code;
371.
stringstream final code;
// opcias temporais para configurar as fases do compilador
372.
373.
bool in_condition;
374.
bool timers_allowed;
// informacin de expresins e varibeis
375.
376.
ExpressionSeq event_expressions;
377.
VarInfoSeq var_info;
378.
// mtodoa pblicos
void initialize(const string& code, bool cond, bool timers);
379.
380.
void clear();
381. };
Os atributos que se declaran na clase SFCCompilationTempData son:

1. original_code (lia 368), preprocessed_code (lia 369), modified code (lia 370) e
final_code (lia 371), "buffers" utilizados para almacenar os cambios que as subfases
realizan no cdigo orixinal para transformalo nun cdigo executbel na mquina virtual.
2. in_condition (lia 373), valor booleano que indica se o cdigo que se est a compilar o
dunha condicin ou o dunha accin. Algunhas das transformacins a realizar (6.3.3)
dependen deste valor, por exemplo, non est permitido modificar varibeis nas condicins.
3. timers_allowed (lia 374), valor booleano que indica se est permitida a utilizacin de
temporizadores no cdigo que se est a compilar. Na versin actual do compilador
unicamente se permite a utilizacin de temporizadores nas condicins de transicin.
4. event expressions (lia 376) e var_info (lia 377), informacin temporal sobre expresins
e varibeis utilizada para realizar transformacins no cdigo segundo se explica en
(6.3.3).
Ademais declranse os mtodos initialize (lia 379) e clear (lia 380) para establecer os
valores iniciais destes atributos. O seguinte pseudocdigo mostra a implementacin xenrica do
operador operatorQ nas fases indicadas anteriormente:
382. AnyCompoundPhaseClass::operator()()
383. {
for every code_block code
384.
385.
/* iaclur aqu o cdigo de preprocesamento especfico da fase */
// iaiciar informacin de configuracin
386.
getTempData().initialize(code, <in_condition>, <timers_allowed>);
387.
// executar as aubfases
388.
SFCMultiStepPhase::operator()();
389.
390.
391.
392.
393.
394. }
/* inclur aqu o cdigo de postprocesamento especfico da fase */
// almacenar cdigo transformado
code = getTempData().final_code;
// reiaiciar i aformacin auxiliar
getTempData().clear();
end for
213
O cdigo fonte a compilar est almacenado na varibel code. Cada fase composta concreta
iniciar a informacin de configuracin (lia 387) con este cdigo e os valores conrespondentes
dos argumentos in_condition e timers allowed indicados na Tboa 6-I. Unha vez executadas as
subfases (lia 389), o cdigo modificado almacenado na varibel code (lia 391) e a
informacin temporal reiniciada (lia 392). Isto reptese para cada bloque de cdigo que haxa
que compilar (p.e. a fase SFCReceptivityCompiler repite a execucin das lias 384-393, unha
vez por cada condicin de transicin).
^
SFCActionCodeCompiler
Non
Non
SFCActionConditionCompiler
Si
Non
SFCReceptivityCompiler
Si
Si
SFCTimerConditionCompiler
Si
Non
Tboa 6-I. Valores dos atributos in_condition e timers_allowed nas fases compostas do compilador Grafcet.
6.2.4. Iniciacin e execucin das fases do compilador

Como xa foi comentado anteriormente, a estructura de fases do compilador organzase
nunha xerarqua en forma de grafo dirixido acclico (Figura 6.6). Cada fase pode ser simple ou
estar fonmada por mltiples subfases, que poden ser compartidas entre varias fases compostas.
Estas son responsbeis de configurar e iniciar a execucin das subfases que conteen. A orde
de execucin secuencial e a estructura de fases esttica (non se modifica durante a
execucin). A raz da estructura unha instancia da clase SFCCompiler, que a responsbel de
crear e almacenar o resto da estructura durante a iniciacin do compilador. O cdigo seguinte
mostra a declaracin da clase abstracta Phase (Figura 6.3), da que derivan todas as fases do
compilador:
395.
396.
397.
398.
399.
400.
401.
402.
class Phase
private:
Phase* root;
public:
virtual Phase* getRoot() const { return root;

virtual bool operator ( ) ( ) = 0 ;
};
A clase contn un nico atributo -root (lia 398^ no que se almacena a referencia raz
da estructura de fases. O valor deste atributo iniciado no constructor e accedido mediante o
mtodo getRoot (lia 400). A execucin da fase implementouse mediante o operador C++
operator(), de xeito que se utilice da mesma maneira que a chamada a unha funcin. Este
operador redefinido nas clases derivadas para implementar as operacins realizadas en cada
fase concreta. As fases compostas son derivadas da clase abstracta MultiStepPhase (Figura
6.3), que declarada do xeito seguinte:
403.
class MultiStepPhase : public virtual Phase
404.
405.
private:
406.
407.
408.
list<Phase*> phases;
public:
void add^hase(Phase* phase, bool back = true);
409.
410.
411 .
void delete^hases();
virtual bool operator()();
};
214
Esta clase, derivada da clase Phase, declara un atributo phases (lia 406}- no que se
almacena a secuencia de subfases, e dous mtodos -add^hase (lia 408) e delete_phases
(lia 409^- para engadir e eliminar subfases. Ademais esta clase incle unha implementacin
por defecto para o operador operator() que executa as subfases secuencialmente:
412. bool MultiStepPhase::operator()()
413 . {
414.
415.
bool error = false;

for every subphase ia phases
416.
417.
error = subfase.operator()();
end for
// executar a subfase
418.
return error;
419 . }
A Figura 6.7 mostra de forma simplificada a secuencia de mensaxes que se intercambian

entre a fase principal do compilador e as subfases durante o proceso de compilacin.
comoiler : SFCComoiler
sub^hase : MultlSteoPhase
ohase : Phase
compiler()
preprocesamento
[ôr all subphase]
subphase() ^
acceso informacin interna
^ preprocesamento
['for all subphase (phase)j
phaseO
N-J
procesamento da fase

postprocesamento
^ postprocesamento
Figura 6.7. Secuencia das mensaxes intercambiadas entre a fase principal e as subfases do compilador Grafcet.
A creacin da estructura de fases faise durante a iniciacin do compilador, no constructor

das fases compostas (a maior parte da estructura inciase no constructor da clase
SFCCompiler). O seguinte cdigo mostra como se crea a estructura de fases no constructor
dunha fase composta hipottica:
420. AnyCompoundPhaseClass::AnyCompoundPhaseClass()
421 . {
422.
// engadir unha aubfase simple
423.
424.
add^hase(phase);
425.
426.
427.
428.
429.
430.
431 . }
Phase* phase = new AnySimplePhaseClass(this);
// eagadir unha subfase composta
MultiStepPhase* multiphase = new AnyCompoundPhaseClass(this);
add^hase(multiphase);
// engadir unha subfase simple subfase composta
Phase* subphase = new AnySimplePhaseClass(this);
multiphase->add^hase(subphase);
215
Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet
6.3. Consideracins sobre a utilizacin de C++ nos modelos Grafcet

O Grafcet foi concibido inicialmente [ 1] como un formalismo grfico para a especificacin
de controladores lxicos secuenciais. Os modelos Grafcet describen os valores que toma un

conxunto de sadas en funcin dos valores dun conxunto de entradas, varibeis internas e da
situacin do modelo, determinada polo conxunto de etapas activas. A situacin do modelo
evoluciona dacordo a un conxunto de condicins lxicas asociadas as transicins, nas que se
relacionan os valores das entradas, as varibeis internas e os estados das etapas. Todas as
varibeis utilizadas no modelo son booleanas.
Nesta descricin bsica do modelo, cada accin asociada a unha etapa unicamente modifica
o valor dunha sada booleana dacordo a unha semntica ben definida que depende do seu tipo
(3.3.3). Os nicos elementos do modelo que aceptan unha representacin textual son as
condicin booleanas asociadas a transicins e accins (nas accins condicionais). O estndar
non propn unha sintaxe determinada para a especificacin das condicins lxicas, indicando
unicamente que podern utilizarse os operadores booleanos: AND, OR e NOT, os operadores
de evento (T, ^) e o de retardo (tl\Xi\t2).
A adopcin dunha versin do Grafcet como linguaxe de programacin de PLCs (3.6)
requiriu das consideracins en relacin a este modelo bsico:
1. A utilizacin de varibeis non booleanas para dar soporte aos diferentes tipos de datos e
clculos manexados nos PLCs.
2. A posibilidade de especificar cdigo nas accins aln das accins booleanas bsicas do
modelo. O SFC permite definir bloques de cdigo cuxa execucin controlada polas
accins asociadas s etapas dacordo semntica definida por un bloque de control de
accin (3.6.1.3). O contido das accins e condicins lxicas pode especificarse utilizando
diferentes linguaxes tanto textuais como grficas: IL, ST, LD e FBD.
No metamodelo proposto en (5.1) adptanse, entre outras, estas das extensins ao modelo
Grafcet orixinal, e definense os conceptos relacionados coa representacin dos bloques de
cdigo e os tipos de accins-os aspectos relacionados coa sa execucin explcanse en
(8.6^. O metamodelo deixa aberta a posibilidade de utilizar calquera linguaxe para a
especificacin dos contidos de condicins lxicas e bloques de accin. O soporte utilizacin
de C++ implementado no compilador proporciona as seguintes avantaxes:
1. Disponse de todos os tipos de datos e operadores da linguaxe.
2. Poden utilizarse as libraras externas existentes para inclur as funcionalidades que se
precisen.
3. As caractersticas de orientacin a obxecto da linguaxe permiten estructurar e reutilizar o
cdigo.
4. ^ Resulta simple inclur funcins avanzadas como, por exemplo, a deteccin de fallas
baseada na execucin dun modelo "software" do proceso controlado.
Sen embargo hai un inconveniente importante na utilizacin do C++: os operadores Grafcet
de evento (T, ^) e retardo (tl\Xi\t2) non son parte da linguaxe. En consecuencia preciso
implementar soporte para estes operadores, o que implica:
1. Estender a sintaxe das expresins C++ para engadir os novos operadores.
2. Proporcionar a infraestructura (en forma de librara de funcins) que implemente a
semntica dos operadores durante a execucin dos modelos.
216
3. Transformar as expresins estendidas en expresins C++ estndar durante a compilacin

do modelo (cada operador substitudo polo cdigo que accede s funcins que
implementan a sa semntica).
Unha consideracin semellante afecta ao uso de varibeis do modelo (entradas, sadas,
varibeis internas, nomes de etapa, etc.) no cdigo C++. Anda que sintacticamente o seu uso
igual ao de calquera outra varibel C++, o acceso ao seu valor durante a execucin do modelo
diferente. Os valores das varibeis C++ (declaradas no cdigo) almacnanse na memoria do
programa durante a execucin do modelo, sen embargo, o valor das varibeis do modelo
(declaradas como parte do modelo) almacenado durante a execucin nunha base de datos na
mquina virtual (7.3.1). A obtenciri do seu valor faise mediante funcins que implementan o
acceso base de datos en tempo de execucin. Polo tanto, durante a compilacin preciso
substitur os nomes das varibeis do modelo polo cdigo que utilice estas funcins.
No resto desta seccin explcanse as modificacins realizadas na sintaxe e gramtica do C++
para inclur os operadores de evento e temporizacin, o soporte proporcionado pola mquina
viriual para implementar a sa semntica e as tcnicas utilizadas para substitur estes
operadores polo cdigo que implementa a sa funcionalidade.
6.3.1. Extensin da sintaxe C++ para inclur os operadores Grafcet

Neste apartado explcanse en detalle as modificacins realizadas dende o punto de vista
sintctico para inclur os operadores Grafcet de evento e temporizacin na linguaxe C++. Estas
.
modificacins consisten en:
1. Definicin da sintaxe dos operadores.
2. Modificacin da gramtica das expresins C++ para inclur os novos operadores.
6.3.1.1. Sintaxe dos operadores Grafcet
Os operadores de evento (T e.^) definronse como operadores booleanos unarios en C++
(como o NOT lxico, por exemplo). Estes operadores poden utilizarse directamente con
varibeis booleanas (T bool_var) ou con expresins booleanas entre parnteses52 (T (expr)). As
expresins con eventos poden aniarse, tal e como mostran os seguintes exemplos:
Ta ^) ^d && !(^(3*b > 12))
1'(a && J.(b ^ 2) ^^ '(J^d))

O operador de temporizacin (T#) representa a semntica do operador de retardo definido
en [83]. A condicin de temporizacin foi estendida para permitir a utilizacin de expresins
C++ complexas. A sintaxe completa do operador a seguinte:
T#(<tl_expr>; <cond expr>; <t2_expr>)
Os argumentos da temporizacin estn separados polo delimitador (;) e son todos opcionais,
do mesmo xeito que na instruccin for do C++. O significado destes argumentos o seguinte:
1.
tl_expr, expresin numrica constante que indica o tempo de retardo que a condicin do
temporizador ten que ser certa para que este se active. O valor por defecto cero.
52 Como se explica en (6.5.1.5.3), a restriccin de que a expresin vaia entre parnteses simplifica a
implementacin da fase EventExprHarvester.
217
2. cond expr, expresin booleana que activa o temporizador. O valor por defecto true.
3. t2_expr, expresin numrica constante que indica o tempo que o temporizador permanece
activo despois de que a condicin deixe de ser certa. O valor por defecto cero.
Os operadores de temporizacin non poden aniarse, dicir, non poden utilizarse
temporizadores nas condicins doutros temporizadores. Os seguintes exemplos mostran
algunhas expresins con temporizadores:
T#(; a&&b>20^^^d; 350)
T#(30; !a; )
T#(150; ; 300)
6.3.1.2. Modificacin da gramtica do C++

A gramtica C++ utilizada como base a ANSI [88]. Os cambios realizados consistiron en
engadir "tokens" lxicos para representar os novos operadores (T, ^ e T#) e en modificar a
regra que afecta sintaxe das expresins unarias para inclur os dous novos tipos de
expresinss3:
432.
433.
Expressions
434.
unary-expression:
435.
436.
[gram.expr]
postfix-expression
++ cast-expression
437.
-- cast-expression
438.
439.
440.
441.
unary-operator cast-expression
sizeof unary-expression
sizeof ( type-id )
new-expresson
442.
delete-expression
443.
444.
sfcpp-event-expresaion
sfcpp-tmer-expreasion
[+]
[+]
445.
446.
[+]
sfcpp-event-expresaion:
447.
T identfier
[+]
448.
449.
450.
^ identifier
T
( sfcpp-expression )
^ ( sfcpp-expression )
[+]
[+]
[+]
451.
452.
453.
afcpp-timer-expresaion:
T# ( digt-aequence,p^
; sfcpp-expression,p^ ; digit-sequenceapt )
[+]
[+]
As regras sfcpp-event-expression (lia 446) e sfcpp-timer-expression (lia 452) definen a

sintaxe das novas expresins. Ntese que na definicin destas regras utilzase unha versin
simplificada das expresins C++ -regra sfcpp-expression (lia 454^. Estas expresins teen
as seguintes restriccins con respecto s expresins C++:
Non se permiten as conversins de tipo explcitas nin o uso dos operadores de conversin
dynamic_cast, static cast, reinterpret_cast e const cast.
Non se permite o uso dos operadores sizeof, typeid, new e delete.
s3
Por conveniencia reprodcense uncamente as regras da gramtica C++ afectadas polas modificacins. Estas
estn indicadas en negria e cun smbolo dereita da pxina indicando o tipo de modificacin: [+] parte engadida,
[-] parte eliminada e[^`] parte modificada. En caso de requerirse algn comentario adicional indcase tamn a
referencia numrica das notas incluidas ao fmal da gramtica.
218
Non se permite o uso da palabra reservada throw, polo que dende as expresins
simplificadas non poden lanzarse excepcins.
Non se permite o uso das palabras reservadas typename e template, polo que nas expresins
simplificadas non pode usarse a cualificacin explcita dos tipos de datos nin dos membros
de "templates".
n
Non se permite o uso da palabra reservada operator, polo que nas expresins simplificadas
non poden referenciarse explicitamente os operadores declarados polo usuario.
Inclense as expresins con eventos e temporizadores do Grafcet.
A razn de utilizar estas expresins simplificadas que o nmero de regras sintcticas

necesarias para representar as expresins redcese de maneira significativa, o que simplifica a
implementacin da fase EventExpressionCompiler (6.5.1.5.3). Ademais na prctica estas
restriccins non supoen un problema importante, pois o uso dalgunha destas caractersticas en
expresins con eventos e temporizadores non tera sentido (p.e. o uso de delete ou throw) e, en
ltimo caso, sempre podera buscarse unha representacin alternativa da expresin que utilizase
estas caractersticas de forma indirecta a travs de varibeis ou funcins auxiliares.
En consecuecia, tomouse a decisin de primar a simplicidade do compilador fronte ao
soporte das caractersticas indicadas, que podern engadirse en futuras versins. A gramtica
completa das expresins simplificadas toma como base a das expresins C++, e a seguintesa;
454.
455.
456.
sfcpp-expression:
sfcpp-assignment-expression
sfcpp-expression, sfcpp-assignment-expression
[-]
sfcpp-expression-list:
sfcpp-expression
sfcpp -expression , sfcpp -expression-list
[+]
4 5 7 .
458.
459.
460 .
461 .
462.
463.
464.
465.
sfcpp-ass i gnment-express i on:
sfcpp-conditional-expression
sfcpp-logical-or-expression assignment-operator sfcpp-assignment-expression
[-]
throw-expressioa
466.
467.
468.
469.
470.
471.
472.
assignment-operator: one of
_ _ &_ ^_ ^_
+_
^_
^_
-_
_
*_
sfcpp-con di t i ona l -express i on:
sfcpp-logical-or-expression
sfcpp-logical-or-expression ? sfcpp-expression : sfcpp-assignment-expression
473.
474.
475.
476.
sfcpp-logical-or-expression:
sfcpp-logical-and-expression
sfcpp-logical-or-expression ^^ sfcpp-logical-and-expression
477 .
478.
479.
480.
sfcpp-logical-and-expression:
sfcpp-inclusive-or-expression
sfcpp-logical-and-expression && sfcpp-inclusive-or-expression
481.
482.
483.
484.
sfcpp-inclusive-or-expression:
sfcpp-exclusive-or-expression
sfcpp-inclusive-or-expression ^
sfcpp-exclusive-or-expression
485.
486.
487.
488.
sfcpp-exclusive-or-expression:
sfcpp-and-expression
sfcpp-exclusive-or-expression ^ sfcpp-and-expression
sa As regras sintcticas das expresins simplificadas teen o mesmo nome que as do C++ co prefixo sfcpp-.
219
489.
490.
491.
492.
493.
494.
495.
496.
497.
498.
499.
500.
501.
502,
503.
504.
505.
506.
507.
508.
509.
510.
511,
512.
513.
514.
515.
516.
517.
518.
519.
520.
521.
522.
523.
524.
525.
526.
527.
528.
529.
530.
531.

sfcpp-and-expression:
sfcpp-equality-expression
sfcpp-and-expression & sfcpp-equality-expression
sfcpp-equality-expression:
sfcpp-relational-expression
sfcpp-equality-expression == sfcpp-relational-expression
sfcpp-equality-expression != sfcpp-relational-expression
sfcpp-relational-expression:
sfcpp-shift-expression
.,
< sfcpp-shift-expression
> sfcpp-shift-expression
<= sfcpp-shift-expression
>= sfcpp-shift-expression
sfcpp-shift-expression:
sfcpp-additive-expression
sfcpp-shift-expression sfcpp-additive-expression
sfcpp-shift-expression sfcpp-additive-expression
sfcpp-additive-expression:
sfcpp-multiplicative-expression
sfcpp-additive-expression + sfcpp-multiplicative-expression
sfcpp-additive-expression - sfcpp-multiplicative-expression
sfcpp-multiplicative-expression:
sfcpp-pm-expression
sfcpp-multiplicative-expression * sfcpp-pm-expression
sfcpp-multiplicative-expression / sfcpp-pm-expression
sfcpp-multiplicative-expression ^ sfcpp-pm-expression
sfcpp-pm-expression:
cast-expression
sicpp-pm-expression . * cast-expressioa
sfcpp-pm-expression - >* cast-expression
cast-expression:
sfcpp-unary-expression
( type-id ) cast-expression
[*:1]
[*:1]
[*:1]
[-:1]
[-:1]
sfcpp-unary-expression:
sfcpp-postfix-expression
++
cast-expression
532.
533.
-
cast-expresaion
unary-operator cast-expression
534.
sizeof unary-expresaioa
535.
sizeof ( type-id )
536.
new-expression
537.
delete-expression
538.
sfcpp-event-expressioa
539.
sfcpp-timer-expression
540.
541.
542. unary-operator: one of
+
!
&
543.
*
544.
545. sfcpp-event-expression:
[*:1]
[*:1]
[*:1]
[-]
[-]
[-]
[-]
[+]
[+]
[+]
546.
identifier
[+]
547.
identifier
[+]
548.
afcpp-expression )
[+]
[+]
T (
549.
^
550.
551. sfcpp-timer-expreasion:
552.
T# ( digit-sequence,^^ ; sfcpp-expressioa,D^ ; digit-sequence,pt )
553.
[+]
[+]

554.
555.
556.
557.
558.
559.
560.
561.
562.
563.
564.
565.
566.
567.
568.
569.
570.
sfcpp-postfix-expression:
sfcpp-primary-expression
postfix-expressioa [ sfcpp-expression ]
postfix-expressioa ( sfcpp-expression-listopc )
aimple-type-specifier ( expression-liatopt )
postfix-expression . template,pt ::oPt sfcpp-id-expression
postfix-expressioa - > templateopr ::,pt sfcpp-id-expression
postfix-expreasioa . paeudo-destructor-name
postfix-expressioa - > pseudo-destructor-name
postfix-expression ++
poatfix-expression --
dynamic_cast < type-id > ( expression )
static_cast < type-id > ( expressioa )
reinterpret_cast < type-id > ( expressioa )
const_cast < type-id > ( expreasioa )
typeid ( expresaion )
typeid ( type-id )
220
[*:2]
[*:2]
[-]
[*:2,31
[*:2,3]
[-]
[-]
[*:2]
[*:2]
[-]
[-]
[-]
[-]
[-]
[-l
571 .
572.
sfcpp-primary-expression:
573.
literal
574.
575.
576.
577.
578.
579.
580.
581 .
582.
583.
584 .
585.
586.
587.
this
.: identifier
.: operator-functioa-id
.: qualified-id
sfcpp-id-expression
identifier sfcpp-id-expressionopt
sfcpp-id-expression:
.: identifier sfcpp-id-expreasion,Pt
[-]
[-l
[-l
[+:4]
[+:4]
[+:4]
digit-sequence: igual que en C++
li tera l : i gua l que en C ++
identfier: igual que en C++
Notas:
1. A regra
cast_expression
eliminada na gramtica simplificada e as
ocorrencias deste smbolo substitudas por sfcpp-unary-expression.
2. As ocorrencias do smbolo postfix-expression son substitudas por sfcpp

primary-expression na gramtica simplificada.
gramtica
eliminadas
na
optativas
destas
regras
son
partes
3. As
simplificada.
non
permitir
sfcpp-id-expression
simplificouse
para
4. A
regra
cualificacin explcita de tipos de datos, membros de "templates" nin
operadores declarados polo usuario.
6.3.2. Implementacin dos operadores Grafcet

Como se explicou na introduccin desta seccin, a implementacin da semntica dos
operadores de evento e temporizacin implementada substitundoos por chamadas a mtodos
dunha interface implementada na mquina virtual (8.6), dacordo ao explicado en (6.3.3).
Esta interface permite acceder aos valores das varibeis e comprobar o estado de eventos e
temporizadores durante a execucin dos modelos Grafcet. A sa declaracin a seguinte:
588. struct IVMachineACCess
589. {
590.
591.
592.
593.
594.
595.
// varibeis internas
virtual bool getModelVarEvent(const string& id, bool updown) const = 0;
template <class T>
bool getModelVar(const string& id, T& value) const;
template <class T>
bool setModelVar(const string& id, const T& value);
221
596.
597.
598.
599.
600.
601,
602.
603.
604.
605 . }

// varibeis de proceso
virtual bool getSystemVarEvent(const string& id, bool updown) const = 0;
template <class T>
bool getSystemVar(const string& id, T& value) const;
template <class T>
bool setSystemVar(const string& id, const T& value);
// estado de etapas e temporizadores
virtual bool getStepState(unsigned long id) const = 0;
virtual bool getTimerState(const string& id) const = 0;
Ntese que o acceso aos valores das varibeis internas (lias 591-595) e de proceso (lias
597-601) est representado mediante mtodos parametrizados (mtodos template en C++) cuxo
parmetro o tipo de dato da varibel accedida. Todos o mtodos utilizan o identificador
alfanumrico da varibel ou temporizador coa excepcin do mtodo que accede ao estado das
etapas do modelo (lia 603) que utiliza o identificador numrico asignado automaticamente
polo compilador. Ademais os mtodos que consultan a ocorrencia de eventos (lias 591 e 597)
teen un segundo parmetro booleano que indica o tipo de evento consultado (flanco positivo
ou negativo do sinal). Ntese tamn que a ocorrencia de eventos, o estado das etapas e o estado
dos temporizadores unicamente poden ser consultados (os seus valores son modificados
internamente pola mquina virtual durante a evolucin do modelo), polo que s se definen
mtodos de acceso e non de modificacin dos seus valores.
6.3.3. Substitucin de operadores e varibeis

Para compilar o cdigo de accins e receptividades cun compilador C++ hai que substitur
os operadores de evento e temporizacin, as como os nomes das varibeis almacenadas na
mquina virtual durante a execucin, polo cdigo que accede aos seus valores utilizando a
interface IVMachineAccess explicada no apartado anterior. Neste apartado descrbense as
modificacins realizadas polo compilador Grafcet no cdigo de accins, condicins de
transicin e condicins de asociacin para obter un cdigo compilbel nun compilador C++.
6.3.3.1. Substitucin de eventos
As expresins con eventos poden ser simples, nas que o operador de evento precede ao
nome dunha varibel booleana: T bool_var, ou complexas nas que precede a unha expresin
entre parnteses: T(expr). O seguinte cdigo mostra como se realiza a modificacin de
expresins que conteen eventos simples:
606. /* Cdigo orixinal (expreain coatendo un evento aimple) */
607. expr(Tbool_var)
608.
609. /* Cdigo modificado */
610. // declaracin e iaiciacia da varibel auxiliar
611. const bool sfcpp_event_id = vm.getModelVarEvent(bool_var", EDGE_UP);
612.
613. // substitucin do evento aa expreain pola varibel auxiliar
614. expr(sfcpp_event_id);
Cada aparicin do evento simple no cdigo substitudo por unha varibel booleana
auxiliar: sfcpp_event_id (id un identificador numrico nico asignado internamente polo
compilador). Esta varibel declarada localmente ao comezo da funcin na que estea includo
o cdigo (lia 611). O seu valor iniciado ao resultado devolto polo mtodo
222
getModel VarEventss cada vez que a funcin executada. O mtodo chamado a travs de vm,
que unha instancia da clase que implementa a interface IVMachineAccess (6.3.2) pasada
como parmetro funcin. Ntese que a varibel auxiliar definida como const para evitar que
as expresins que poidan modificar o seu valor compilen correctamente. O seguinte cdigo
mostra dous exemplos:
615. /* Cdigo orixinal */
616. Ta = true; / / asignacin errnea dun valor a un evento aimple
617.
619. const bool sfcpp_event_id = vm.getModelVarEvent("a", EDGE_UP);
620. sfcpp_event_id = true; // BRROR: asignacin a uaha varibel tipo coast
621.
623. any_function(Ta); // fuacin que modifica o parmetro
624.
626. const bool sfcpp_event_id = vm.getModelVarEvent("a", EDGE_UP);
627. any_function(sfcpp_event_id);// SRROR: parmetro tipo const
A substitucin de expresins con eventos complexas realzase simplificando a expresin a

unha equivalente na que s se utilicen eventos simples. Cada evento simple despois
substitudo utilizando a tcnica explicada anteriormente. Para a simplificacin das expresins
utilzase a aplicacin externa Sidoni [146], que implementa o clculo formal preciso para
simplificar as expresins lxicas permitidas no Grafcet. Sen embargo, comparadas coas
expresins C++ estendidas ( 6.3.1) as soportadas por Sidoni presentan as seguintes
restriccins:
Unicamente son permitidas expresins booleanas, nas que aparezan os operadores lxicos:
AND, OR e NOT, e os de evento: T e^ (Sidoni utiliza os smbolos: ., +, /, > e<,
respectivamente).
As varibeis utilizadas nas expresins son, polo tanto, tamn booleanas e distnguense dous
tipos: as entradas de proceso e as varibeis de estado das etapas (de sintaxe X).
Os nicos valores numricos permitidos son as constantes 0 e 1(representadas en Sidoni

como =0 e = 1, respectivamente).
En consecuencia preciso modificar as expresins con eventos complexas para adaptalas s

caractersticas e sintaxe soportada por Sidoni e levar a cabo a sa simplificacin. O proceso
completo de adaptacin e simplificacin dunha expresin faise nos pasos seguintes:
1. Substitucin dos operadores de temporizacin por varibeis booleanas auxiliares, tal e
como se explica en (6.3.3.2).
2. Anlise sintctica da expresin para identificar as subexpresins non booleanas.
3. Substitucin das expresins non booleanas identificadas por varibeis booleanas. Estas
varibeis sern iniciadas ao valor devolto (interpretado como valor booleano) pola
subexpresin non booleana que substiten. Ntese que en cada subexpresin substituda
ter que aplicarse recursivamente o proceso de substitucin de varibeis e operadores de
evento e temporizacin.
ss O mtodo utilizado sera getSystemVarEvent no caso de tratarse dunha varibel de proceso.
223
4. Conversin sintctica da expresin booleana C++ resultante das transformacins anteriores

ao formato soportado por Sidoni. Esta conversin implica substitur os operadores,
constantes numricas e os nomes de varibeis para adaptalos aos utilizados en Sidoni.
5. Simplificacin da expresin con Sidoni.
6. Conversin do resultado simplificado da sintaxe Sidoni sintaxe C++. Esta a operacin
contraria do paso 4.
7. Substitucin dos eventos simples e varibeis da expresin simplificada utilizando as
tcnicas descritas en (6.3.3.1) e (6.3.3.3), respectivamente.
O seguinte cdigo mostra un exemplo das diferentes transformacins e substitucins
realizadas para simplificar unha expresin complexa:
629. if
630.
(a && T(b
^^
(c+5 > 10) && !T#(10;X_10;20) && (100
^^
^c)))
631. /* Cdigo modificado: paso 1*/
632. // substitucin de temporizadores
633. const bool sfcpp_timer_id = vm.getTimerState("sfcpp_timer_id");
634.
635. if (a && T(b ^^ (c+5 > 10) && !sfcpp_timer_id && (100 ^^ c)))
636.
637.
638.
639.
640.
/* Cdigo modificado: pasos 2 e 3*/
// identificacin e substitucin de expresibns non booleanas
const bool sfcpp_timer_id = vm.getTimerState("sfcpp_timer_id");
bool sfcpp_expr_id = (bool) (c+5 > 10);
641.
642. if (a && T(b ^^ sfcpp_expr_id && !sfcpp_timer_id && (100 ^^ ^c)))
643.
645. // conversin da expresin ao formato SIDONI
646. // formato C++
647. T(b ^^ sfcpp_expr_id && !sfcpp_timer_id && (100 ^^ .^c))
648.
649. // formato SIDONI
650. >(b + sfcpp_expr_id . /sfcpp_timer_id . (=1 + <c))
651.
652.
653.
654.
655.
656.
657.
/* Cdigo modificado: paso 5*/
// aimplificacin da expresin con SIDONI
// resultado:
(/sfcpp_expr_id . >b) + (sfcpp_timer_id . >b) +
(/sfcpp_timer_id . >sfcpp_expr_id . /b) + (a . <sfcpp_expr_id . /b)
659. // conversin da expresin do formato SIDONI a C++
660. const bool sfcpp_timer_id = vm.getTimerState("sfcpp_timer_id");
661. bool sfcpp_expr_id = (bool) (c+5 > 10);
662.
663. if (a && (!sfcpp_expr_id && Tb) ^^ (sfcpp_timer_id && Tb) ^^
664.
(!sfcpp_timer_id && Tsfcpp_expr_id && !b) ^^
665.
666.
(a && ^sfcpp_expr_id && !b))
667.
668.
669.
670.
671.
// substitucin de eventos simples
const bool sfcpp_event_id = vm.getSystemVarEvent("b", EDGE_UP);
672.
673. if (a && (!sfcpp_expr_id && sfcpp_event_id) ^^
(sfcpp_timer_id && sfcpp_event_id) ^^
674.
675.
676.
(!sfcpp_timer_id && Tsfcpp_expr_id && !b) ^^
(a && ^sfcpp_expr_id && !b))
224
No exemplo anterior ponse de relevo que hai que ter en conta unha consideracin adicional
ao aplicar o paso 7(lia 667). Como pode comprobarse na expresin resultado da
simplificacin (lia 673) poden aparecer expresins con eventos simples que afecten s
varibeis auxiliares utilizadas para substitur as expresins non booleanas -sfcpp_expr_id, no
exemplo-. Estas varibeis son declaradas e iniciadas localmente (lia 671) na funcin que
contn o cdigo e, ao contrario que as varibeis do modelo (entradas, etapas, temporizadotês,
etc.), o seu valor non almacenado pola mquina virtual durante a execucin, en consecuencia,
os seus cambios de estado teen que ser detectados localmente en cada execucin do cdigo da
funcin. O seguinte exemplo mostra como se realizara a substitucin dunha subexpresin non
booleana nun caso coma o anterior:
677. /* Cdigo orixinal
678.
679.
680.
681.
682.
( expresin contendo un evento simple) */
Texpr(subexpr num)
/* Cdigo modificado */
// declaracin e iniciacin das varibeis auxiliares
static bool sfcpp_expr_id_last = false;
683. bool sfcpp_expr_id_up, sfcpp_expr_id_down;
684.
685. bool sfcpp_expr_id =(bool) subexpr num;

686. if (sfcpp_expr_id != sfcpp_expr_id_last)
// avaliacin da subexpresin
687. {
sfcpp_expr_id_up =
688.
sfcpp_expr_id_down
689.
sfcpp_expr_id_last
690.
691. }
692.
693. // substitucin das
(sfcpp_expr_id_last) ? false : true;
= (sfcpp_expr_id_last) ? true : false;
= sfcpp_expr_id;
varibeis auxiliares na expresia
694. expr_simplificada(sfcpp_expr_id[Q1^_up^_down]);
A tcnica utilizada consiste en declarar para cada subexpresin non booleana catro varibeis
booleanas: sfcpp_expr_id (lia 685), sfcpp_expr id last (lia 682), sfcpp_expr id up e
sfcpp_expr_id down (lia 683). Estas varibeis almacenan, respectivamente, o valor actual da
subexpresin, o valor anterior da subexpresin, a ocorrencia dun cambio no valor da expresin
de false a true, e a ocorrencia dun cambio de true a false. Na expresin simplificada substitese
a subexpresin e as expresins de evento simple que a afecten polas varibeis auxiliares
correspondentes. Ntese que a varibel que almacena o valor anterior declarada como static,
de xeito que o seu valor conservado na memoria entre diferentes execucins da funcin. Cada
vez que esta se executa calclase o valor actual da subexpresin (lia 685), se diferente ao
ltimo valor calculado, actualzanse os valores das varibeis que indican a ocorrencia de
eventos na subexpresin (lias 688-690) e, finalmente, exectase a expresin simplificada cos
valores calculados para as varibeis auxiliares (lia 694).
Esta tcnica ten o inconveniente de introducir varibeis auxiliares innecesarias cando a
subexpresin constante, xa que nese caso o resultado de aplicar un operador de evento
varibel auxiliar sempre falso. Nesta primeira versin non se implementou o tratamento deste
caso especfico, deixndose para unha futura optimizacin do compilador. O seguinte cdigo
mostra o resultado do paso 7 do exemplo anterior (lia 667) aplicando esta tcnica para
substitur a subexpresin non booleana:
695.
696.
697.
698.
699.
700.
// substitucia de eventos simples
const bool sfcpp_event_id = vm.getSystemVarEvent("b", EDGE_UP);
bool sfcpp_expr_id_up, sfcpp_expr_id_down;
225
701.
702.
703.
704.
705.
706.
707 .
7oa.
709.
710.
711.
712.

if (sfcpp_expr_id != sfcpp_expr_id_last)
{
sfcpp_expr_id_up = (sfcpp_expr_id_last) ? false : true;
sfcpp_expr_id_down = (sfcpp_expr_id_last) ? true : false;
sfcpp_expr_id_last = sfcpp_expr_ id;
}
if (a && (!sfcpp_expr_id && sfcpp_event_id) ^^
(sfcpp_timer_id && sfcpp_event_id) ^^
(!sfcpp_timer_id && sfcpp_expr_id_up && !b)

(a && sfcpp_expr_id_down && !b))
^^
Ntese que para completar a modificacin da expresin con eventos complexa faltara
procesar a subexpresin non booleana (lia 701), substitundo nela a varibel c coa tcnica
explicada en (6.3.3.3).
A ubicacin do cdigo que calcula os valores das varibeis auxiliares (lias 704-706)
presenta unha complicacin adicional, pois preciso realizar diferentes substitucins
dependendo da posicin no cdigo na que estea situada a expresin con eventos complexa.
Considrense os exemplos seguintes nos que a expresin aparece en diferentes posicins dun
bucle for:
713. /* 8xemplo l: Cdigo orixinal */
714. // expresin na asignacin inicial dun for
715. for (bool var = Texpr(c>5); // c>5, subexpresin non booleana
<any expr>;
716.
717.
<any expr>)
c++; // cdigo que modifica c e, polo tanto, o valor da subexpresin
718.
719.
720.
721.
722.
723.
724.
725.
726.
727.
728.
/* Cdigo modifi ado */

bool sfcpp_expr_id_up, sfcpp_expr_id_down;
bool sfcpp_expr_id =
{
sfcpp_expr_id_up =
sfcpp_expr_id_down
sfcpp_expr_id_last
(bool) (c>5)
(sfcpp_expr_id_last) ? false : true;
= (sfcpp_expr_id_last) ? true : false;
= sfcpp_expr_id;
729. }
730.
731. for (bool var = expr_simpl(sfcpp_expr_id[^^_up^_down]);
732.
<any expr>;
733.
<any expr>)
734.
c++;
735. /* $xemplo 2: Cdigo orixinal */
736. // expresin na condicin dun for
737. for (<any expr>; Texpr(c>5); <any expr>)
c++;
738.
739.
741. static bool sfcpp_expr_id_last = false;
743.
744. bool sfcpp_expr_id = (bool) (c>5);
745. if (sfcpp_expr_id != sfcpp_expr_id_last)
746. {
747.
748.
749.
750. }
sfcpp_expr_id_up =(sfcpp_expr_id last) ? false : true;
sfcpp_expr_id_last = sfcpp_expr_id;
226

751. for
752. {
(<any expr>;
expr_simpl(sfcpp_expr_id[QJ^_up^_down]);
753.
754.
c++;
755.
sfcpp_expr_id = (bool) (c>5);
756.
757.
758.
759.
760.
761.
<any expr>)
762. }
763. /* $xemplo 3: Cdigo orixinal */
764. // expresin na terceira expresia dun for
765. for (<any expr>; <any expr>;

c++;
766.
Texpr(c>5))
767.
769. static bool sfcpp_expr_id_last = false;
771.
772. bool sfcpp_expr_id;
773. for (<any expr>; <any expr>; expr_simpl(sfcpp_expr_id[Q^^_up^_down]))
774. {
c++;
775.
776.
(subexpr num);
sfcpp_expr_id = (bool)
777.
778.
{
779.
780.
781.
782.
}
783.
784. }
Como pode comprobarse nos tres casos mostrados no exemplo anterior, a localizacin da
expresin con eventos complexa no cdigo modifica substancialmente o resultado da
substitucin. Cando utilizada na expresin de iniciacin da instruccin for (lia 715)
abondo con calcular o valor da subexpresin e das varibeis auxiliares antes de iniciarse o
bucle. Sen embargo, se a expresin aparece na condicin do for (lia 737), hai que facer a
iniciacin antes de iniciarse o bucle e recalcular o valor da expresin e das varibeis auxiliares
ao fnal de cada iteracin do bucle. Finalmente, se a expresin est na parte do for que se
executa despois de cada ciclo (lia 765) non far falta facer a iniciacin antes do bucle, mais si
a actualizacin ao final de cada ciclo. En consecuencia hai que analizar o contexto no que
aparece a expresin no cdigo para realizar unha substitucin que mantea a sa semntica,
especialmente naqueles casos que requiren recalcular o valor das varibeis auxiliares por estar a
expresin dentro dun bucle. Os diferentes casos tratados polo compilador son detallados en
(6.5.1.5.3).
6.3.3.2. Substitucin de temporizadores
O seguinte cdigo mostra como se realiza a modificacin de expresins que conteen
temporizadores:
785. /* Cdigo orixinal ( expresin contendo un temporizador) */
786 . expr (T# ( tl; cond; t2) )
227
787.
788.
789.
790.
791.
792.
// declaracin e iniciacin da varibel auxiliar
// subatitucin do evento na expreain pola varibel auxiliar
expr(sfcpp_timer_id);
A tcnica a mesma que a explicada para os eventos (6.3.3.1). Unicamente cambia o nome
da varibel auxiliar -sfcpp_timer_id- e o mtodo chamado para iniciala getTimerState-.
Ademais o compilador ten que almacenar os parmetros do temporizador substitudo para
compilar con posterioridade a sa condicin e xerar a informacin que permita xestionar o seu
estado durante a execucin do modelo na mquina virtual.
6.3.3.3. Substitucin de varibeis
Na substitucin dunha varibel, o cdigo a utilizar depende de se o valor da varibel pode
consultarse e modificarse, unicamente consultarse ou unicamente modificarse. preciso polo
tanto considerar os seguintes factores:
1. O tipo de varibel, pode tratarse dunha varibel do modelo, do proceso, do estado de
activacin dunha etapa ou do estado de activacin dunha accin.
2. O cdigo no que se utiliza a varibel, pode ser nunha condicin (o que incle as condicins
de transicin, temporizacin e as de asociacin de accin) ou nunha accin.
3. O acceso especificado para a varibel, pode ser de lectura, escritura ou ambas.

Tendo en conta estes factores as seguintes regras definen os diferentes casos a considerar ao
realizar a substitucin dunha varibel:
l. Os estados de activacin de etapas e accins s poden consultarse e non modificarse.
2. As varibeis do modelo definidas polo usuario poden consultarse e modificarse.
3. As varibeis do proceso divdense en dous grupos: as entradas, que s poden consultarse; e
as sadas, que s poden modificarse.
4. As condicins non poden producir efectos colaterais, dicir, as substitucins realizadas no
cdigo das condicins teen que garantir que as varibeis non son modificadas. Esta regra
ten prioridade sobre as anteriores.
5. Unha consecuencia das regras 3 e 4 que as sadas do proceso non poden ser utilizadas nas
condicins.
Ademais tamn hai que ter en conta que o mtodo utilizado para acceder ao valor do estado
de activacin dunha etapa diferente ao do resto de varibeis (6.3.2). Os cdigos das
substitucins realizadas polo compilador nos diferentes casos identificados son os seguintes:
Estado de activacin de etapas nas condicins e accins.
794. expr(X_id)
795.
797. // declaracin e iaiciacin da varibel auxliar
798. const bool sfcpp_modelvar_id = vm.getStepState(id_num);
799.
800. // substitucin da varibel de etapa na expreaia pola varibel auxiliar
801. expr(sfcpp_modelvar_id);
228
A tcnica a mesma que a explicada para os eventos (6.3.3.1) e temporizadores (6.3.3.2).

Unicamente cambia o nome da varibel auxiliar -sfcpp_modelvar_id- e o mtodo chamado
para iniciala getStepState-. Ntese que neste caso o parmetro pasado a este mtodo non o
nome da varibel senn o identificador numrico nico, denominado id_num, asignado polo
compilador etapa (id e id_num son identificadores diferentes). A utilizacin dunha varibel
auxiliar constante garante o cumprimento da regra 1.
"
Estado de activacin de accins, varibeis do modelo e entradas nas condicins e estado de
activacin de accins nas accins.
803. expr(var)
804.
BOS. /* Cdigo modificado */
806.
807.
808.
809.
810.
511.
812.
// declaracia e iniciacia da varibel auxiliar
type sfcpp_modelvar_id_value;
vm.getModelVar("var", sfcpp_modelvar_id_value);
const type sfcpp_modelvar_id = sfcpp_modelvar_id_value;
// subatitucin da varibel na expresin pola varibel auxiliar
expr(sfcpp_modelvar_id);
Neste caso o acceso ao valor da varibel faise mediante o mtodo getModel Var56. Este un
mtodo parametrizado co tipo de dato da varibel accedida (6.3.2). Este valor obtido
mediante unha varibel auxiliar do tipo do que se trate -sfcpp_modelvar_id_value (lia
807^ e asignado a outra varibel do mesmo tipo -sfcpp_modelvar_id (lia 809}- que a
utilizada para realizar a substitucin. Esta segunda varibel constante, polo que se garante o
cumprimento da regra 4, xa que o seu valor non vai poder ser modificado. A razn de necesitar
das varibeis do mesmo tipo, unha constante e a outra non, que ao mtodo getModelVar non
se lle pode pasar como parmetro unha varibel constante, xa que o seu valor vai ser
modificado no interior do mtodo. Sen embargo, para realizar a substitucin, e evitar que o
valor sexa modificado no cdigo da funcin, precsase unha varibel auxiliar constante. Ntese
tamn que o estado de activacin dunha accin un caso particular das varibeis do modelo, no
que o tipo da varibel booleano e o seu valor non pode ser modificado. A utilizacin desta
tcnica cos estados de activacin das accins garante tamn o cumprimento da regra 1.
Varibeis do modelo nas accins.
813.
814.
815.
816.
817.
818.
/* Cdigo orixinal */
expr(var)
pair<type, type> sfcpp_modelvar_id;
819. vm.getModelVar("var", sfcpp_modelvar_id.first);
820. sfcpp_modelvar_id.second = sfcpp_modelvar_id.first;
821.
822.
823.
824.
825.
826.
827.
sb
// substituci da varibel aa expresin pola varibel auxiliar
expr(sfcpp_modelvar_id.second);
// actualizacin do valor da varibel no modelo
if (sfcpp_modelvar_id.first != sfcpp_modelvar_id.second)
vm.setModelVar("var", sfcpp_modelvar_id.second);
O mtodo utilizado ser getSystemVar se se trata dunha entrada.
229
Ao contrario dos casos anteriores, os valores das varibeis do modelo utilizados nas accins
si poden ser modificados. Ao realizar a substitucin ser preciso, polo tanto, inclur non s 0
cdigo que accede ao valor da varibel senn tamn o que o actualiza en caso de que sexa
modificado. Isto implementado declarando un par de varibeis (lia 818) auxiliares do tipo do
que se trate (mediante o"template" pair do C++). Os dous membros do par son iniciados ao
valor da varibel do modelo ( lia 820), que obtido mediante o mtodo getModelVar do
mesmo xeito que no caso comentado anteriormente. O segundo membro do par utilizado para
realizar a substitucin da varibel do modelo no cdigo. Este membro non constante, polo
que pode ser modificado polo cdigo da accin. A actualizacin do valor modificado faise nas
lias 826-827, que son inseridas ao final da funcin que contn o cdigo. Nestas lias
comprase o valor dos dous membros do par, o primeiro conter o valor da varibel antes de
executar o cdigo da accin e o segundo o valor despois de executar o cdigo. Se ambos
valores son diferentes actualzase na mquina virtual o valor modificado mediante o mtodo
setModel Var.
Sadas do proceso nas accins.
Como indica a regra 3, as sadas do proceso poden modificarse mais non consultarse (no
caso de precisar a consulta dunha sada, o seu valor e introducido no modelo mediante unha
entrada auxiliar). Por este motivo a tcnica utilizada para realizar a substitucin ten que
producir como resultado un cdigo que non compile correctamente nun compilador C++ se a
sada utilizada con calquera outro fin que non sexa o de asignarlle un valor. A modificacin
realizada a seguinte:
828.
829.
830.
831.
832.
833.
expr(output)
SFCRTOutput<type> sfcpp_modelvar_id;
834.
835. // substitucin da varibel na expresin pola varibel auxiliar
836. expr(sfcpp_modelvar_id);
837.
838. // actualizacin do valor da varibel no modelo
839. if (sfcpp_modelvar_id.modified())
840.
vm.setSystemVar("var", sfcpp_modelvar_id.value());
Neste caso a varibel auxiliar utilizada unha instancia da clase SFCRTOutput. Esta unha
clase parametrizbel co tipo de valor da sada. A sa declaracin a seguinte:
841.
842.
843.
844.
845.
846.
847.
template <class T>
class SFCRTOutput
T output;
bool flag;
public:
SFCRTOutput(): flag(false){}
848.
T& operator=(const T& val) { output = val; flag
849.
bool modified() const { return flag; }
850.
T value() const { return output; }
851. };
true; return output;
Cada instancia da clase ten dous atributos, o valor da sada -atributo output (lia 844)--- e
un indicador booleano -atributo Jlag (lia 845^ que indica se ese valor foi modificado con
posterioridade creacin da instancia. Inicialmente este indicador ten o valor false e s pasa a
230
valer true cando se lle asigna un valor sada mediante o operador de asignacin simple
(operator=) que redefinido pola clase (lia 848). A tcnica utilizada para a substitucin
garante que o cdigo resultado produce un erro de compilacin se a sada utilizada nunha
expresin que non sexa de asignacin. O seguinte cdigo mostra algns exemplos:
852.
853.
654.
855.
856.
857.
/* Bxemplo 1: Cdigo orixinal */
if (output) // acceso ao valor dunha safda nuaha condicin
SFCRTOutput<bool> sfcpp_modelvar_id;
if (sfcpp_modelvar_id) // BRROR: expresin ilegal
858.
859.
860.
861.
662.
863.
/* Bxemplo 2: Cdigo orixinal */
int var = output + 5; // acceso ao valor duaha sada nunha asignacia
864.
865.
866.
867.
868.
869.
/* Exemplo 3: Cdigo orixinal */
output = true; // asigaacin dun valor a unha sada
SFCRTOutput<int> sfcpp_modelvar id;
int var = sfcpp_modelvar_id + 5; // BRROR: expresin ilegal
SFCRTOutput<bool> sfcpp_modelvar id;
sfcpp_modelvar_id = true; // OK: asignacia correcta
En caso de que o valor da sada sexa modificado, o novo valor actualizado na mquina
virtual nas lias 839-840, que son inseridas ao final da funcin que contn o cdigo. Nestas
lias comprobase se a sada foi modificada -mediante o mtodo modified da clase
SFCRTOutput (lia 849}-, e en caso afirmativo actualzase na mquina virtual o valor
modificado mediante o mtodo setSystemVar -o valor modificado devolto polo mtodo
value da clase SFCRTOutput (lia 850^.
A tcnica descrita ten a limitacin de que o valor da sada s pode ser modificado mediante
0 operador de asignacin simple. A asignacin de valores sada utilizando os operadores de
asignacin compostoss' do C++ ( +_, -_, *_, /_, %_, ^_, &_, ^_) ou a utilizacin da sada como
argumento dunha funcin que modifique o seu valor internamente daran como resultado da
substitucin un cdigo que provocara un erro na compilacin. Na prctica estas limitacins
poden evitarse utilizando varibeis auxiliares. O seguinte cdigo mostra algns exemplos:
870. /*
Cdigo orixinal */
871. output = 3;
872.
873.
874.
875.
876.
877.
878.
879.
880.
881.
882.
883.
output += 5; // asignacin dun valor a unha sada
SFCRTOutput<int> sfcpp_modelvar_id;
sfcpp_modelvar_id = 3;
sfcpp_modelvar_id += 5; // BRROR: expresin ilegal
/* Cdigo orixinal corrixido */
int aux_var = 3;
aux_var += 5;
output = aux_var;
57 A asignacin en C++ mediante un operador composto require que a varibel modificada tea un valor vlido,
que ser utilizado para calcular o novo valor asignado. Se se utilizaran cunha instancia da clase SFCRTOutput
antes de que tivese un valor inicial vlido, o valor asignado sera erroneo.
231
Seccin 6.4: Informacin para a execucin dun modelo Grafcet
884.
885.
886.
887,
888.
/* Cdigo corrixido modificado */
SFCRTOutput<int> sfcpp_modelvar_id;
int aux_var = 3;
aux_var += 5;
sfcpp_modelvar_id = aux var;

// OK: asigaacin correcta
889.
890.
891.
892.
893.
894.
any_function(output); // funcin que modifica a sada iaternamente
895.
896.
897.
898.
899.
900.
901.
902.
903.
904.
any_function(sfcpp_modelvar_id); // BRROR: expresin ilegal
/* Cdigo orixinal corrixido */
bool aux_var;
any_function(aux_var);
output = aux_var;
/* Cdigo corrixido modificado */
bool aux_var;
any_function(aux_var);
// OK: asigaacin correcta
sfcpp_modelvar_id = aux_var;
6.4. Informacin para a execucin dun modelo Grafcet

O diagrama da Figura 6.8 mostra as clases definidas para representar os modelos Grafcet no
formato utilizado durante a sa execucin na mquina virtual. Este formato consiste nunha
versin compacta do modelo na que se utilizan identificadores numricos e se incle
informacin adicional que permita reducir o nmero de accesos e avaliacins de condicins
durante a execucin do modelo. A clase RTModel, derivada da clase abstracta IModule
(7.1.1.1), agrupa toda a informacin xerada polo compilador e proporciona unha interface
comn que permite cargar e almacenar o modelo na mquina virtual. Os detalles sobre como se
utiliza esta informacin durante a execucin dos modelos explcanse en (8.4). Exemplos de
diferentes modelos Grafcet representados mediante este fonmato poden verse en (6.5.1.2). A
descricin detallada das clases mostradas no diagrama da Figura 6.8 a seguinte58:
TimeScale
Enumeracin que define as das escalas (3.3.2.4) utilizadas na execucin dos modelos
Grafcet. Os valores escalares definidos son:
ts_internal, escala interna.
ts external, escala externa.
RTActionType
Enumeracin que define os tipos de accins que se diferencian durante a execucin dun
modelo Grafcet. Os valores escalares definidos son:
model var action, accin que modifica o valor dunha varibel (booleana) do modelo.
system_var action, accin que modifica o valor dunha varibel (booleana) do proceso.
code_block action, accin que executa un bloque de cdigo especificado en C++.
58 Para evitar complicar o diagrama da Figura 6.8 non se mostran as operacins definidas en cada clase, que
consisten basicamente en funcins que permiten a insercin e o acceso informacin do modelo utilizando os
identificadores numricos dos diferentes elementos.
232
IModule
(from Modules)
RTModel
actions_code : map<string, void*>
conditions_code : map<string, void*>
RTFOInfo
pgid : unsigned long
stepid : unsigned long
type : FOrderTppe
fpg : unsigned long
fsituation : RTSituation
forcing_orders
SFCVarDeclarations
(from Grafcet Library)
1
static model
declarations
1
bind(unsigned long) ^
RTStaticModel
*^
FO_levels
RTSituation
name : string
RTTimerlnfo
timers initial situation : RTSituation
id : unsigned long *
partial_grafcets
_^^3I
condition : string ^^
RTPGInfo
*
t1 : double
receptivit i es
ôde s
id
:
unsigned
long
actions
t2 : double
key : string
vars : set<string>
:
steps : RTSituation
fosteps : RTSituation
RTActionlnfo
*
RTReceptivitylnfo
id : unsigned long
receptivity : string
source : bool
vars : set<string>
id : unsigned long
stepid : unsigned long
action_name : string
type : ActionType
indicator : string
delay : double
limit : double
condition : string
scale : TimeScale
code_type : RTActionType
vars : set<string>
RTNodelnfo
id : unsigned long
key : string
pgid : unsigned long
before : RTSituation
after : RTSituation
enumeration
RTActionType
model_var_action
system var_action
code block action
enumeration
TimeScale
ts internal
ts external
Figura 6.8. Diagrama de clases da informacin utilizada para a execucin dun modelo Grafcet.
RTSituation
Conxunto de identificadores numricos. Esta clase utilzase tanto para representar a
situacin do modelo durante a execucin como calquera outra informacin que requira
almacenar un conxunto de identificadores de elementos pertencentes ao modelo.
RTModel
Clase que proporciona unha interface comn de acceso informacin dun modelo Grafcet
que sexa cargado na mquina virtual para a sa execucin. Os atributos desta clase son os
seguintes:
actions_code, informacin que permite acceder ao cdigo obxecto das accins xerado
como resultado da compilacin do modelo.
conditions_code, informacin que permite acceder ao cdigo obxecto das condicins

xerado como resultado da compilacin do modelo.
static model, informacin estructural do modelo.
233
Seccin 6.4: Informacin para a execucin dun modelo Grafcet
RTStaticModel
Clase que proporciona unha interface comn de acceso informacin esttica (estructural)
do modelo Grafcet durante a execucin. Os atributos desta clase son os seguintess9:

name, nome do modelo (nome do grafcet global que representa o modelo).
initial_situation, identificadores das etapas que sern activadas ao comezo da excucin do

modelo.
declarations, declaracins das varibeis utilizadas no modelo.
nodes, informacin dos nodos contidos no modelo.
partial^rafcets, informacin dos grafcets parciais do modelo.

receptivities, informacin das receptividades do modelo.
timers, informacin dos temporizadores do modelo.
actions, informacin das accins do modelo.
forcing_orders, informacin das ordes de forzado do modelo.

fo_levels, informacin dos niveis da xerarqua de forzado (para cada nivel da xerarqua de
forzado almacnanse os identificadores dos grafcets parciais que pertencen ao nivel). Esta
informacin utilzase durante a execucin do modelo para aplicar recursivamente as ordes
de forzado comezando polos niveis superiores.
RTNodeInfo
Clase que representa a informacin de cada nodo (etapas e transicins) do modelo Grafcet
durante a execucin. Os atributos desta clase son os seguintes:
id, identificador interno do nodo (numrico e asignado automaticamente polo compilador).
key, identificador externo do nodo (alfanumrico e asignado polo usuario).

pgid, identificador do grafcet parcial que contn o nodo.
before, identificadores dos nodos que preceden ao nodo na secuencia de control.
after, identificadores dos nodos que suceden ao nodo na secuencia de control.
RTPGInfo
Clase que representa a informacin de cada grafcet parcial do modelo Grafcet durante a
execucin. Os atributos desta clase son os seguintes:
id, identificador interno do grafcet parcial (numrico e asignado automaticamente polo

compilador).
key, identificador externo do grafcet parcial (alfanumrico e asignado polo usuario).

steps, identificadores das etapas contidas no grafcet parcial.
fosteps, identificadores das etapas contidas no grafcet parcial que teen asociada algunha
orde de forzado.
59 Os atributos nodes, partial^rajcets, receptivities, timers, actions e forcing_orders foron implementados como
mapas de chave numrica (map<unsigned long, DataClass>). Isto podera indicarse no diagrama da Figura 6.8
engadindo a chave a cada relacin de agregacin, mais non se indicou para manter a simplicidade.
234
RTReceptivityInfo
Clase que representa a informacin de cada receptividade do modelo Grafcet durante a
id, identificador da receptividade.
receptivity, nome da funcin que contn o cdigo da receptividade.
source, atributo que indica se a receptividade est asociada a unha transicin fonte.
vars, varibeis (do modelo ou de proceso) utilizadas na receptividade.

RTTimerInfo
Clase que representa a informacin de cada temporizador do modelo Grafcet durante a
id, identificador do temporizador.
condition, nome da funcin que contn o cdigo da condicin que activa o temporizador.
tl , cantidade de tempo que a condicin debe ser certa para que se active o temporizador.
t2, cantidade de tempo a transcorrer para desactivar o temporizador dende que a condicin
deixa de ser certa.
vars, varibeis (do modelo ou de proceso) utilizadas na condicin do temporizador.
RTActionInfo
Clase que representa a informacin de cada asociacin do modelo Grafcet durante a

id, identificador da asociacin.
stepid, identificador da etapa que a asociacin est asociada.
action_name, este atributo indica o nome dunha varibel do modelo (en accins tipo
model_var_action) ou de proceso (en accins tipo system_var_action) que modificada
durante a activacin da asociacin. Nas accins tipo code_block_action o valor deste
atributo indica o nome da funcin que contn o cdigo da accin executada durante a
activacin da asociacin.
type, tipo de accin (5.1.2.1).
indicator, nome da varibel do modelo utilizada como indicador da finalizacin da

execucin da accin.
delay, cantidade de tempo que indica a demora antes da cal a condicin da asociacin non
avaliada (a accin non se executa). O valor resultado da avaliacin da condicin non tido
en conta antes de transcorrer o perodo de tempo indicado polo valor deste atributo.
limit, cantidade de tempo que indica o lmite temporal despois do cal a condicin da
asociacin non pode ser avaliada (a accin non se executa). O valor resultado da avaliacin
da condicin non tido en conta unha vez transcorrido o perodo de tempo indicado polo
valor deste atributo.
condition, nome da funcin que contn o cdigo da condicin que controla a execucin da
accin.
scale, atributo que indica si a accin vai ser executada en situacins inestbeis durante as
evolucins internas do modelo, ou s nas situacins estbeis.
235
Seccin 6.5: Implementacin das fases do compilador Grafcet

code_type, o valor deste atributo indica se o atributo action_name contn o nome dunha
varibel do modelo, de proceso ou o nome dunha accin.
vars, varibeis (do modelo ou de proceso) utilizadas na condicin da asociacin.

RTFOInfo
Clase que representa a informacin de cada orde de forzado do modelo Grafcet durante a

pgid, identificador do grafcet parcial que contn a etapa que a orde de forzado est
asociada.
stepid, identificador da etapa que a orde de forzado est asociada.
type, tipo de orde de forzado (5.1.2.1).
fpg, identificador do grafcet parcial forzado.

situation, situacin forzada no grafcet parcial indicado polo atributo fpg.
6.5. Implementacin das fases do compilador Grafcet

No resto desta seccin descrbense en detalle as operacins realizadas en cada fase do
compilador (6.2.3), ordenadas dacordo sa secuencia de execucin.
6.5.1. Fase principal ("SFCCompiler")

Esta a fase principal do compilador, nela crease a estructura de fases e controlase a
execucin do proceso de compilacin utilizando a tcnica explicada en (6.2.4). Ademais nesta
fase almacenase a informacin sobre o modelo Grafcet, as declaracins de varibeis do proceso
e as opcins de compilacin que se lle pasan ao compilador -atributos sfc_model, systeml0 e
comp_info da clase SFCCompiler (6.2.1), respectivamente- e inciase a informacin sobre
directorios e nomes de aplicacins a utilizar durante a compilacin -atributo paths da clase
SFCCompiler (6.2.1^.
6.5.1.1. Procesamento de macroetapas ("SFCMacroProcessor")
Nesta fase realzanse as seguintes operacins sobre as macroetapas do modelo:
1. Comprobar a correccin sintctica das macroexpansins. En (5.1.3.2) definronse, como
parte do metamodelo proposto para o Grafcet, as regras semnticas que teen que verificar
as macroexpansins para que un modelo sexa correcto. A librara que implementa o
metamodelo garante, durante a construccin dun modelo, o cumprimento destas regras coa
excepcin da que establece que todos os nodos dunha macroexpansin teen que estar
conectados (directa ou indirectamente) entre si. Polo tanto preciso comprobar o
cumprimento desta regra semntica para cada macroexpansin, utilizando para elo a clase
auxiliar SFCMacroChecker (5.2.2) includa na librara. Esta clase comproba, para unha
macroexpansin dada que todos os seus nodos estn includos no peche transitivo da sa
etapa de entrada (o conxunto de nodos directa ou indirectamente conectados a ela).
2. Obter unha versin `plana' do modelo equivalente ao modelo orixinal. A informacin sobre
a estructura xerrquica que forman os grafcets conexos e as macroetapas non utilizada
durante a execucin dun modelo Grafcet. En consecuencia esta informacin descartada,
substitundo as macroetapas polas sas macroexpansins e eliminando o nivel intermedio
que forman os grafcets conexos entre un grafcet parcial e os nodos que contn. Para elo
236
utilzase. a clase auxiliar SFCFlattener ( 5.2.2), includa na librara que implementa o

metamodelo proposto para o Grafcet.
6.5.1.2. Recopilacin inicial de informacin ("SFCInfoHarvester")
Nesta fase realzase a recopilacin inicial da informacin do modelo Grafcet no form^to
utilizado durante a execucin (6.4) as como a asignacin de identificadores numricos nicos
aos diferentes elementos do modelo.
6.5.1.2.1. Recopilacin de Informacin
As operacins realizadas para cada elemento do modelo60 son as seguintes:
Grafcet Global ("SFCGlobal")

1. Almacenar as accins (sen modificalas) no compilador -no atributo actions_code da clase
SFCCompiler (lia 319}-.
2. Procesar os grafcets parciais.
Grafcet Parcial ("SFCPartial")
1. Obter un identificador numrico nico.
2. Crear e almacenar -no atributo pgs da clase SFCCompiler (lia 312}- unha instancia da
clase RTPGInfo (6.4) coa informacin do grafcet parcial.
3. Procesar os nodos (as etapas e transicins) do grafcet parcial.
Nodo ("SFCNode"^
1. Obter un identificador numrico nico.

2. Crear e almacenar -no atributo nodes da clase SFCCompiler (lia 313^ unha instancia
da clase RTNodelnfo (6.4) coa informacin do nodo.
3. Representar os arcos orientados substitundo os apuntadores aos nodos cos que hai unha
conexin polos seus identificadores numricos asignados polo compilador -atributos
before e after da clase RTNodelnfo (Figura 6.8}-.
4. Realizar as operacins especficas do tipo de nodo do que se trate (etapa ou transicin).
Transicin ("SFCTrans")
1. Crear e almacenar -no atributo recs da clase SFCCompiler (lia 320^ unha instancia da
clase RTReceptivitylnfo ( 6.4) coa informacin da receptividade (o identificador numrico
da receptividade igual ao da transicin que a contn).
Etapa ("SFCStep")
1. Se unha etapa inicial, engadir o seu identificador numrico situacin inicial -no
atributo initial da clase SFCCompiler (lia 311}-.
2. Engadir o identificador numrico lista de etapas do grafcet parcial que a contn -no
atributo steps da clase RTPGInfo (Figura 6.8^.
3. Procesar asociacins e ordes de forzado da etapa.
60 Indcase entre parnteses o nome da clase utilizada para representar o elemento na librara que implementa o
metamodelo Grafcet (5.2).
237
Asociacin ("SFCActionAssociation")
1. Obter un identificador numrico (nico para cada asociacin).
2. Crear e almacenar -no atributo actions da clase SFCCompiler (lia 314^ unha instancia
da clase RTActionlnfo (6.4) coa informacin da asociacin.
3. Se unha asociacin retardada:
'
3.1. Obter un identificador numrico (nico para cada temporizador).

3.2. Crear e almacenar -no atributo timers da clase SFCCompiler (lia 317^ unha
instancia da clase RTTimerlnfo (6.4) coa informacin do temporizador (a condicin
do temporizador igual a varibel de etapa que contn a asociacin).
3.3. Almacenar na lista de varibeis utilizadas na condicin do temporizador o nome da
varibel de etapa que contn a asociacin -no atributo vars da clase RTTimerlnfo
(Figura 6.8^.
3.4. Engadir o identificador interno do temporizador (sfcpp_timer_<id>) lista das
varibeis utilizadas na condicin da asociacin -no atributo vars da clase
RTActionlnfo (Figura 6.8}-.
3.5. Engadir o texto `&& sfcpp_timer_<id>' condicin da asociacin -no atributo
condition da clase RTActionlnfo (Figura 6.8}- para ter en conta o valor do
temporizador na avaliacin da condicin.
4. Se unha asociacin limitada:
4.1. Obter un identificador numrico (nico para cada temporizador).
4.2. Crear e almacenar -no atributo timers da clase SFCCompiler (lia 317}- unha
instancia da clase RTTimerlnfo ( 6.4) coa informacin do temporizador (a condicin
do temporizador igual a varibel de etapa que contn a asociacin).
4.3. Almacenar na lista de varibeis utilizadas na condicin do temporizador o nome da
varibel de etapa que contn a asociacin -no atributo vars da clase RTTimerlnfo
(Figura 6.8^.
4.4. Engadir o identificador interno do temporizador (sfcpp_timer <id>) lista das
varibeis utilizadas na condicin da asociacin -no atributo vars da clase
RTActionlnfo (Figura 6.8}-.
4.5. Engadir o texto `&& !sfcpp_timer_<id>' condicin da asociacin -no atributo
condition da clase RTActionlnfo (Figura 6.8}- para ter en conta o valor do
temporizador na avaliacin da condicin.
Na Figura 6.9 mostrase un exemplo de como son tratadas as asociacins retardadas e/ou
limitadas polo compilador. Para cada restriccin temporal definese un temporizador que ten
como condicin o estado de activacin da etapa que contn a asociacin (que ten a forma
X_<id>, <id> = identificador numrico da etapa). Por exemplo, para a asociacin da Figura
6.9.a cranse dous temporizadores: 2sIX_n para o retardo e 6sIX_n para o lmite. Os
identificadores internos destes temporizadores teen a forma sfcpp_timer_<id> (<id> _
identificador numrico do temporizador). Para ter en conta os valores destes temporizadores
modificase a condicin de activacin da asociacin, facendo o AND lxico da condicin
orixinal, o valor do temporizador de retardo e o valor negado do temporizador de lmite (Figura
6.9.b).
238
Orde de forzado ("SFCForcing_Order")

1. Crear e almacenar -no atributo forders da clase SFCCompiler (lia 315}- unha instancia
da clase RTFOInfo (6.4) (as ordes de forzado non teen identificador numrico).
2. Almacenar os identificadores numricos das etapas da situacin forzada -no atributo
fsituation da clase RTFOlnfo (Figura 6.8^.
^
3. Almacenar o identificador numrico do grafcet parcial forzado -no atributo fpg da clase
RTFOInfo (Figura 6.8}-.
4. Engadir o identificador numrico da etapa que contn a orde de forzado lista de etapas
con ordes de forzado no grafcet parcial que contn a etapa -no atributo fosteps da clase
RTPGInfo (Figura 6.8^.
n. X
n
cond
D#2s var
L#6s
-+-+--^----+^^
cond
Î^ ^ i
var
^;^;^! i
i2i i4sii
i ii ^
^.
(n)
(a)
cond &&
sfcpp timer_u &t^
!sfcpp_timer_L
n
X n
- cond
--F^---+----+-+F
sfcpp timer_D
var
(n)
(b)
Figura 6.9. Tratamento de accins temporizadas: a) accin retardada e limitada no tempo; e b) modificacin
realizada polo compilador Grafcet.

6.5.1.2.2. Asignacin de identificadores numricos
A asignacin de identificadores numricos aos elementos do modelo faise do xeito seguinte:

Para os grafcets parciais e nodos, o identificador alfanumrico nico proporcionado polo
usuario almacenado nunha cola. O identificador numrico asignado a posicin na cola
do identificador alfanumrico.
Para as receptividades utilzase o mesmo identificador que a transicin que as contn.
Para as asociacins e temporizadores, o identificador numrico asignado a posicin na
cola de asociacins e temporizadores do compilador -nos atributos actions e timers da
clase SFCCompiler (lias 314 e 317, respectivamente}-.
s ordes de forzado, non se lles asigna un identificador numrico.
239
Os identificadores numricos utilizados teen un tamao de catro bytes. O nmero mximo

de elementos do modelo manexados polo compilador son polo tanto:
Grafcets parciais + etapas + transicins = 4.294.967.296
Asociacins = temporizadores = 4.294.967.296
Receptividades = transicins = 4.294.967.296 - (grafcets parciais + etapas)
Na Figura 6.10 e na Figura 6.11 mstranse exemplos da informacin creada por esta fase
para algns modelos Grafcet concretos.
PG1
)_
0
(0)
a
1
a 88 !b
!c
HP action_1 indicator_t
S I var_t
D#2s
c
P
D#2s action 2
L#10s
(z) ^-!(b II ^)
(a)
:RTPGInfo
id=0
key ='SFCPartial.PGt'
steps = {1, 3, 5}
fosteps = Q
:SFCComoiler
P8s
initial = {1}
timers
actions
nodes
:RTNodelnfo
recs
:RTReceoliviNlnfo
id=2
key ='SFCTrans.(0)'
pgid = 0
before = {1}
after = {3}
:RTReceotiviNlnfo
id=4
receptiviry ='d'
source = false
vars = Q
id=2
receptivity ='a'
source = false
vars = Q
id=3
key ='SFCStep.1'
pgid = 0
before = {2}
after = {4}
:RTNodelnfo
id=4
key ='SFCTrans.(1)'
pgid = 0
before = {3}
after = {5}
:RTNodelnfo
id=5
key ='SFCStep.2'
pgid = 0
before = {4}
after = {8}
:RTNodelnfo
id=8
key ='SFCTrans.(2)'
pgid = 0
before = {5}
after = {1}
'RTReceotiviNlnfo
id=
receptivity ='!(bllc)'
source = false
vars = Q
^RTAdionlnfo
:RTActionlnfo
id=1
stepid = 3
action_name ='var_1'
tYPe = S
indicator ="
delay = 2s
limit = 0
wndrtion ='!c 88 sfcpp timer 0'
sple =1s_external
wde_tYPe =
vars = {'sfcpp_Gmer_Oy
id=2
stepid = 5
actlon_name ='action 2'
tYPe = P
indicator =
delay = 2s
limt = 10s
wndition ='c 88 sicpp timer_1 88 !sfcpp_timer_Y
scale = ts_eMemal
wde_tYPe =
vars = {'sfcpp timer_1', 'sfcpp 6mer_2^
:RTActionlnfo
id=0
stepid = 3
action_name ='action_1'
tYPe = P
indicator ='indicator_1'
delay = 0
limit = 0
wndrtion ='a 88 !b'
scale = ts_external
code_bPe =
vars = q
:RTNOdelnfo
:RTNodelnfa
id=1
key ='SFCStep.O'
p^d = 0
before = {8}
aRer = {2}
:RTTimerlnfo
:RTTimerlnfo
:RTTimednfo
id=0
wnddion ='X_1'
tt = 2s
t2=0
vars = {'SFCStep.1^
id=1
wndrton ='X 2'
t1 = 2s
12=0
vars = {SFCStep.2^
id=2
wndrtion ='X Y
t1 = 10s
t2=0
vars = {'SFCStep.Y)
(b)
Figura 6.10. Exemplo do funcionamento da fase SFCInoHarvester: a) modelo Grafcet; e b) diagrama de obxectos
da informacin recopilatia pola fase.
240
PG3
20
PG2
PG1
(20)
F/PG3:{22}
10
21
(10)
(0)
(21.a)
^--^F/PG2:{10
23
22
(1)+b&&c
Ib
b (21.b)
F/PG3:{20, 23}
12
11
(11)+1b88d
(22)
(23).}^d
(a)
:SFCCamoiler
initial = {1, 6, 12}
recs
pgs
:RTPGInfo
:RTPGInfo
id=0
key ='SFCPartial.PG1
steps ={1, 3}
fosteps ={3}
id=5
key ='SFCParbaI.PG2'
steps ={6, 8, 9}
fosteps = {6, 9}
Glnfo
id=11
key ='SFCPartial.PG3"
steps ={12, 14, 16, 19}
fosteps = Q
nodes
:RTNodelnfo
forders
id=1
key ='SFCStep.O'
pgid = 0
before = {4}
after = {2}
:RTNodelnfo
:RTNodelnfo
id=2
key ='SFCTrans.(0)'
pgid = 0
before = {1}
after = {3}
id=3
key ='SFCStep.1'
pgid = 0
before = {2}
after = {4}
:RTNodelnfo
id=4
key ='SFCTrans.(1)'
pgid = 0
before = {3}
after = {1}
:RTNodelnfo
:RTNodelnfo
:RTNodelnfo
RTNodelnfo
RTNodelnfo
id=6
key =SFCStep.10'
pgid = 5
before = {10}
after = {7}
id=7
key ='SFCTrans.(10)'
pgid = 5
before = {6}
after = {8, 9}
id=8
key ='SFCStep.11'
pgid = 5
before = {7}
after = {10}
id=9
key ='SFCStep.12'
pgd = 5
before = {7}
after = {10}
id=10
key =SFCTrans.(11)'
pgid = 5
before = {8, 9}
after = {6}
:RTNodelnfo
:RTNodelnfo
;RTNodelnfo
:RTNodelnfo
:RTNodelnfo
id=12
key ='SFCStep.20'
pgid = 11
before = Q
after = {13}
id=13
key ='SFCTrans.(20)
pgid = 11
before = {12}
after = {14}
id=14
key ='SFCStep.21'
pgid = 11
before = {13}
after = {15, 18}
id=15
key ='SFCTrans.(21.a)' '
pgid = 11
before = {14}
after = {16}
id=16
key ='SFCStep.22'
pgid = 11
before = {15}
after = {17}
:RTNodelnfo
:RTNodelnfo
:RTNodelnfo
:RTNodelnfo
id=17
key ='SFCTrans.(22)
P9id = 11
before = {16}
after = {14}
id=18
key ='SFCTrans.(21.b)
pgid = 11
before = {14}
after = {19}
id=19
key ='SFCStep.23'
pgid = 11
before = {18}
after = {20}
id=20
key = SFCTrans.(23)'
P9id = 11
before = {19}
after = {14}
:RTFOInfo
:RTFOInfo
:RTFOInfo
pgid = 0
stepid = 3
type = force
fpg = {5}
situation = {6}
pgid = 5
stepid = 6
type = force
fpg = {11}
situation = {16}
pgid = 5
stepid = 9
type = force
fpg = {11}
situation = {12, 19}
:RTReceotivitvlnfo
id=2
receptivity ='a'
source = false
vars=Q
:RTReceotivirilnfo
id=4
receptivity ='b &8 c'
source = false
vars=Q
:RTReceotivitvlnfo
id=7
receptivity ='b'
source = false
vars=Q
:RTReceotivitvlnfo
id=10
receptivity ='!b && d'
source = false
vars=Q
:RTReceotivitvlnfo
:RTReceotivirilnfo
:RTReceotivitvlnfo
:RTReceotivirilnfo
^RTReceptivirilnfo
id=13
receptivity = 'a'
source = false
vars = Q
id=15
receptivity = 'b'
source = false
vars = Q
id=17
receptivty = 'c'
source = false
vars = Q
id=18
receptivity = '!b'
source = false
vars = Q
id=20
receptivity ='d'
source = false
vars = Q
(b)
Figura 6.11. Exemplo do funcionamento da fase SFCInfoHarvester: a) modelo Grafcet; e b) diagrama de obxectos
da informacin recopilada pola fase.
241
6.5.1.3. Procesamento das ordes de forzado ("SFCFOrderCompiler")

Nesta fase comprbase a correccin das ordes de forzado do modelo e almacnase a
informacin relativa xerarqua de forzado. Para cada orde de forzado fanse as comprobacins
seguintes:
1. Que o grafcet parcial forzado exista.
'
2. Que as etapas da situacin forzada existan no grafcet parcial forzado.

3. Que a situacin forzada sexa baleira se a orde de forzado e de tipo initial, empty ou freeze;
e non baleira se de tipo force (5.1.2.1).
Se todas as ordes de forzado do modelo son correctas, entn comprobase a coherencia da
xerarqua de forzado que estas definen. O algoritmo utilizado est baseado no proposto en
[103] e implementado na clase SFCFOChecker (5.2.2) da librara que implementa o
metamodelo Grafcet. Este algoritmo consiste na deteccin de ciclos no grafo dirixido que
forman as ordes de forzado, a xerarqua s ser coherente se non contn ciclos. O seguinte
pseudocdigo describe o algoritmo utilizado:
905.
906.
907,
908.
909.
910.
911.
912.
913.
914.
915.
916.
Construr o grafo dirixido que representa a xerarqua de forzado
while (algn arco poda ser eliminado)
for each nodo N
calcular nmero de arcos de entrada (in) e sada (out)
if (in + out > 0&& (in = 0 ^^ out = 0))
eliminar arcos de N do grafo
end if
end for
end while
if (o grafo non ten arcos)
calcular niveis da xerarqua de forzado
end if
Basicamente o algoritmo vai eliminando iterativamente os arcos daqueles nodos do grafo

que s teen arcos de entrada ou de sada ( son os que non poden formar parte dun ciclo). O
grafo non ter ciclos se ao final do proceso iterativo todos os seus arcos foron eliminados. Nese
caso calclanse e almacnanse -no atributo fo_levels da clase SFCCompiler (lia 316^ os
niveis da xerarqua de forzado. Esta informacin utilizada durante a execucin do modelo
para aplicar iterativamente as ordes de forzado comezando polo nivel mis alto. O algoritmo
que calcula os niveis da xerarqua, baseado no proposto en [103], o seguinte:
917.
918.
919.
920.
921.
922.
923.
924.
925.
926.
927.
928.
929.
930.
931.
932.
933.
934.
Construr o grafo dirixido que representa a xerarqua de forzado inversa
for each nodo N
iniciar o nivel do nodo (nivel :_ +oo)
end for
while (algn nodo tea un nivel igual a+ao)
for each nodo N
if (nivel de N = +ao)
nivel de N:= 1
for each nodo P predecesor directo de N
if (nivel de P = +ao)
nivel de N :_ +ao
else
nivel de N:= max(nivel de N, nivel de P+ 1)
end if
ead for
end if
end for
end while
242
Este algoritmo comeza construndo o grafo dirixido que representa a xerarqua de forzado
inversa, na que hai un arco dirixido dende cada nodo que represente un grafcet parcial forzado
ao nodo que represente o grafcet parcial que o forza. O nivel de cada nodo inciase a un valor
mximo (+oo) utilizado como indicador e posteriormente percrrense iterativamente todos os
nodos asignndolles o mximo nivel dos seus predecesores incrementado nunha unidade,
sempre e cando ningn dos predecesores tea un nivel igual ao do indicador mximo. Dste
xeito na primeira iteracin asgnase o nivel dos nodos sen predecesores (os de nivel 1), na
segunda os de nivel 2, e as consecutivamente ata que non quede ningn nodo sen asignrselle
nivel.
6.5.1.4. Procesamento das asociacins de accin ( "SFCAssociationPreprocessor")
Nesta fase comprbase que as asociacins de accin do modelo (5.1.2.3) cumpren as
seguintes regras:
1. Todas as asociacins teen que ter un nome.
2. O nome dunha asociacin ten que ser unha varibel do modelo, unha sada do proceso ou o
nome dunha accin declarada como parte do modelo Grafcet. Ademais ten que ser de tipo
booleano e o seu valor modificbel. O tipo de asociacin almacenado no atributo
code type da clase RTActionlnfo (6.4).
3. O indicador dunha asociacin ten que ser unha varibel do modelo ou do proceso declarada
como parte do modelo Grafcet.
4. As nicas asociacins que poden definirse como internas son as que, dende un punto de
vista externo (3.3.2.4), teen -teoricamente- unha duracin nula. Polo tanto
unicamente as accins impulsionais e almacenadas (P, P0, P1, R ou S) poden ser internas.
5. Pola mesma razn, as asociacins definidas como internas non poden ser retardadas ou
limitadas, xa que -teoricamente- non teen duracin na escala de tempo externa.
6.5.1.5. Procesamento do cdigo das accins ( "SFCActionCodeCompiler")
Esta fase est composta de varas subfases que procesan o cdigo de cada accin do modelo
dacordo ao explicado en (6.3.3). A execucin das subfases configrase utilizando a tcnica
explicada en (6.2.4), e basicamente realizan as operacins seguintes:
1. Preprocesar o cdigo da accin utilizando un preprocesador C++ externo.
2. Substitur os temporizadores utilizando a tcnica explicada en (6.3.3.2).
3. Substitur as varibeis e expresins con eventos, simplificando as expresins con eventos
complexas utilizando as tcnicas explicadas en (6.3.3.1) e(6.3.3.3).
Cada unha das subfases explicada en detalle a continuacin.
6.5.1.5.1. Preprocesamento do cdigo C++ ("CPPActionPreprocessor")
Nesta fase realizase o procesamento das directivas de preprocesador (#define, #ifdef,

#include, etc.) presentes no cdigo C++. Esta fase unha clase "wrapper" que capsula o acceso
a un preprocesador externo utilizando a tcnica explicada en (6.1.3). Esta clase presupn a
existencia dun arquivo denominado preprocess.bat que estar almacenado no subdirectorio do
directorio compilers indicado nas opcins de configuracin (6.1.1).
243
6.5.1.5.2. Procesamento dos temporizadores ("TimerPreprocessor")
Esta fase recopila e almacena a informacin dos temporizadores utilizados no cdigo -coa
sintaxe explicada en (6.3.1.1^ e os substite por varibeis auxiliares que van almacenar o
seu valor durante a execucin. Na versin actual do compilador non se permite a utilizacin de
temporizadores no cdigo das condicins de asociacin, no cdigo das accins nin o uso de
temporizadores aniados (temporizadores nas condicins doutros temporizadores), polo que na
prctica esta fase s se executa cando se compila o cdigo dunha condicin de transicin. As
operacins realizadas por esta fase son as seguintes:
1. Para cada temporizador crase e almacnase -no atributo timers da clase SFCCompiler
(lia 317^ unha instancia da clase RTTimerlnfo (6.4) utilizando a informacin
recopilada polo compilador: identificador numrico nico asignado automaticamente,
cdigo da condicin do temporizador e valores de retardo e lmite.
2. Substitense os operadores de temporizacin polo cdigo que permite acceder ao seu valor
durante a execucin do modelo aplicando a tcnica explicada en (6.3.3.2). As condicins
dos temporizadores son almacenadas para ser procesadas nunha fase posterior do
compilador (6.5.1.8).
6.5.1.5.3. Procesamento de eventos e varibeis ( "SFCEventCompiler")
Esta unha fase composta que realiza a simplificacin das expresins con eventos
complexas e a substitucin das varibeis e eventos simples polo cdigo que permite acceder aos
seus valores en tempo de execucin. As operacins realizadas por esta fase son as seguintes:
1. Detectar e almacenar a informacin sobre as expresins con eventos complexas que
aparecen no cdigo.
2. Obter a informacin sobre o contexto (posicin no cdigo) no que aparecen estas
expresins. Esta informacin utilizada posteriormente para substitur as expresins
complexas.
3. Reducir e simplificar as expresins con eventos complexas por equivalentes que contean
unicamente eventos simples dacordo ao explicado en (6.3.3.1).
4. Obter a informacin sobre as varibeis do modelo, de proceso, nomes de accin, eventos
simples, etc. utilizados no cdigo.
5. Substitur as varibeis e eventos simples utilizando as tcnicas explicadas en (6.3.3).
Cada unha das subfases detallada a continuacin.
Deteccin das expresins con eventos ("EventExprHarvester")
Esta fase procura as expresins complexas con eventos para reducilas nas fases posteriores.
O obxectivo obter expresins equivalentes que unicamente utilicen eventos simples (cambios
de estado en varibeis booleanas), que son os manexados pola mquina virtual. Isto facilita a
avaliacin de condicins en tempo de execucin.
As expresins con eventos complexas son as que comezan por un operador de evento (T ou
.^) seguido dunha expresin entre parnteses:
T (<expr>) ou ^(<expr>)
A obrigatoriedade de utilizar os parnteses unha restriccin imposta nesta primeira versin
do compilador para facilitar a deteccin dos lmites da expresin. Con esta restriccin a
implementacin desta fase resulta moi simple e non require unha anlise sintctica detallada do
244
cdigo que sigue ao operador de evento para determinar en que punto remata a expresin. Esta
restriccin podera eliminarse en futuras implementacins desta fase. Por cada expresin
identificada, almacnase a sa posicin no cdigo e a expresin contida entre parnteses. Anda
que as expresins con eventos poden aniarse (unha expresin complexa pode aparecer dentro
doutra) isto non tido en conta nesta fase, na que s son detectadas as expresins mis
externas.
A
Recopilacin do contexto das expresins con eventos ("EventExprContextHarvester")
Como foi explicado en (6.3.3.1), a posicin no cdigo na que se utilice unha expresin con
eventos complexa pode modificar substancialmente os cambios a realizar no cdigo para
simplificala e substitula polas varibeis auxiliares coas que se implementa a sa semntica.
Nesta fase analzase e recoplase a informacin sobre o contexto no que son utilizadas as
expresin con eventos complexas. A parte da gramtica C++ que define as instruccins da
linguaxe a seguinte:
935. statement:
labeled-statement
936.
expression-statement
937.
compound-statement
938.
selection-statement
939.
iteration-statement
940.
jump-statement
941.
declaration-statement
942.
try-block
943.
944.
945. labeled-statement:
identifier : statement
946.
947.
948.
case constant-expression : statement
default : statement
949.
950. expression-statement:
expressionaPt ;
951.
952.
953. compound-statement:
{ statement-seqoPt }
954.
955.
956. statement-seq:
statement
957.
958.
959.
statement-seq statement
960. selection-statement:
if ( condition ) statement
961.
if ( condition ) statement else statement
962.
switch ( condition ) statement
963.
964.
965. condition:
expression
966.
type-specifier-seq declarator = assignment-expression
967.
968.
969. iteration-statement:
while ( condition ) statement
970.
do statement while ( expression );
971.
for ( for-init-statement conditionoPt ; expressionopt ) statement
972.
973.
974. for-init-statement:
expression-statement
975.
simple-declaration
976.
977.
^
978. jump-statement:
979.
980.
break ;
continue ;
245
981.
982.
983.
984.
985.

return expressionopc ;
goto identifier ;
declaration-statement:
block-declaration
Dacordo a esta gramtica as expresins con eventos poden ser utilizadas nos^ contextos
seguintes:
1. Na condicin dunha instruccin de seleccin: if(lia 961) ou switch (lia 963).
2. Na condicin dunha instruccin iterativa: while (lia 970), do while (lia 971) ou for (lia
972) -a condicin neste caso opcional-.
3. Na instruccin opcional de iniciacin dun bucle for (lia 974).
4. Na expresin opcional dun bucle for (lia 972), executada ao final de cada ciclo do bucle.
5. Na expresin opcional da instruccin de salto return (lia 981).
6. Como parte dunha expresin que por si mesma constite unha instruccin (lia 950).
7. Como parte dunha instruccin de declaracin (lia 984).
Para realizar a substitucin de cada expresin con eventos complexa preciso determinar en
que posicin do cdigo orixinal inserir as modificacins. Nos casos mais complicados, nos que
a expresin simplificada contn eventos simples aplicados a subexpresins numricas
(6.3.3.1), poden requirirse modificacins en tres posicins diferentes dependendo do contexto
concreto: unha na que inserir a declaracin das varibeis auxiliares, outra para a iniciacin das
subexpresins numricas e varibeis auxiliares e unha ltima, cando a expresin orixinal
utilizada na condicin dun bucle, para a actualizacin de subexpresins numricas e varibeis
auxiliares. En consecuencia nesta fase recoplase, para cada expresin con eventos complexa, a
informacin seguinte:
1. Tipo de instruccin (contexto) no que est contida a expresin (p.e. if, for, etc.).
2. Posicin do comezo e fin da instruccin.
3. No caso das instruccins de seleccin (lia 960) ou iteracin (lia 969), que estn formadas
por unha parte condicional e un conxunto de instruccins executadas cando a condicin se
cumpre:
a. A posicin do comezo e fin do conxunto de instruccins.
b. Un indicador booleano de si o conxunto de instruccins est pechado entre `{}'. En
caso de non estalo tratarase dunha nica instruccin (includa a baleira: `;').
Os valores desta informacin para os diferentes contextos diferenciados nesta fase son os
seguintes1:
Instruccin de seleccin if^tipo = IF)
986. [b]if (<condition_with_complex_event_expression>)
[cb]<statement>;[ce][e]
987.
988. (b]if (<condition_with_complex_event_expression>)
{ [cb]
989.
<statements>
990.
} [ce] (e]
991.
61 Os valores almacenados pola fase para o inicio e fin da sentencia son indicados coas etiquetas: [b] e[e], e os de
inicio e fin do conxunto de instruccins coas etiqutas: [cb] e[ce]. Nas sentencias nas que sexa aplicbel danse
duas versins, unha na que o conxunto de instruccins est pechado entre "{}" e outra na que non.
246
Instruccin de seleccin switch (tipo = SWITCH)

992.
993.
994.
995.
996.
997.
[b]switch (<condition_with_complex_event_expression>)
{ [cb]
case <value_1>: <statements> break;
case <value_n>: <statements> break;
default: <statements> break;
} [ce] [e]
Instruccin de iteracin for (3 posicins, tipos = FORf 112131)

998. [b]for(<expression_with_complex_event_expression>;
<condition_with_complex_event_expression>;
999.
1000.
<expression with_complex_event_expression>)
1001.
[cb]<statement>;[ce][e]
1002.[b]for(<expression_with_complex_event_expression>;
1003.
<expression_with_complex_event_expression>)
1004.
{[cb]
1005.
1006.
<statements>
1007.
} [ce] [e]
Instruccin de iteracin do while (tipo = DOWHILE)

1008 . [b] do
1009.
1010.
[cb]<statement>;[ce]
while
(<condition_with_complex_event_expression>);[e]
1011 . [b] do
1012 .
{ [cb]
1013.
1014.
<statements>
}[ce]
1015.
while
(<condition_with_complex_event_expression>);[e]
Instruccin de iteracin while (tipo = WHILE)

1016.[b]while ( <condition_with_complex_event_expression>)
1017.
( cb]<statement>;[ce][e]
1018.[b]while
( <condition_with_complex_event_expression>)
1019.
{[cb]
1020.
1021.
<statements>
} [ce] [e]
Instruccin de salto return (tipo = RETURN)

1022.[b][cb)return
( <condition_with_complex_event_expression>);[ce][e]
Calquera outra instruccin (tipo = STATEMENT)
1023.[b][cb]<expression_statement_with_complex_event_expression>;[ce][e]
As modificacins realizadas e o xeito en que esta informacin utilizada para realizalas

explcase no apartado seguinte (fase EventExpressionCompiler). O pseudocdigo seguinte
describe de maneira simplificada o algoritmo utilizado para calcular a informacin de contexto
de cada expresin:
1024./* 8atradas */
1025.code = cdigo orixinal
1026.code_tam = lonxitude do cdigo orixinal
1027.pos = posicin no cdigo orixinal da expresin con eventos complexa
1028.
247
1029./* Sadas */
1030.begin, end = comezo e final da instruccin que contn a expresin
1031.cbegin, cend = comezo e final do cdigo da instruccibn
1032.type = tipo de instruccin
1033.code_block = indicador de instruccin simple ou bloque de cdigo
1034.
1035./* Algoritmo */
1036.// buscar delimitador da iastruccin previa
1037.delimôs = buscar_delimitador^revio(code, pos)
1038.// buscar palabra reservada C++ en code(delimJpos, pos]
1039.stbegin, type = buscarâlabra_reservada(code, delimôs, pos)
1040.// procesar casos especiais
1041.if (type == STATEMENT)
// a expreain parte dun for ou dunha instruccin?
1042.
1043.
type = for_ou_expresin(code, delimôs, pos)
1044.e1se if (type == WHILE)
1045.
// a expresin parte dua wh31e ou dua do while?
1046.
type = while_ou_dowhile(code, delimôs, pos)
1047.ead if
1048.if (type == IF or type == WHILE or type == FOR3)
1049.
// est a expreain includa na condicia da instruccin?
cond_end = buscar_fin_condicin(code, stbegin)
1050.
1051.
1052.
1053.
1054.
if (pos > cond_end)
delimôs = cond_end
type = STATEMENT
end if
1055.end if
1056.// calcular infoxâcin de contexto
1057.begin, end, cbegin, cend, code_block = calcular_contexto(code,
type, stbegin,
1058.
delimôs, pos)
1059.
O algoritmo determina que palabra reservada do C++ hai entre o inicio da instruccin que
contn a expresin e a posicin da expresin no cdigo. O inicio da instruccin determnase
buscando o delimitador da instruccin previa (lia 1037), que pode ser un dos seguintes: `{',
`}', `;' ou `:'. Existen das situacins nas que algn destes smbolos pode aparecer no cdigo
sen ser delimitadores dunha instruccin:
1. O smbolo `;' pode aparecer como separador das expresins dunha instruccin for (lia
972). Durante a busca o algoritmo sltase as expresins entre parnteses, polo que os
smbolos `;' que estean na parte da condicin dun for non sern detectados como
delimitadores. A nica excepcin cando a expresin con eventos fai parte da condicin
dunfor. Este caso explcase posteriormente.
2. O smbolo `:' pode formar parte do operador `?:' (lia 472). Neste caso o algoritmo
comproba que o smbolo non fai parte dunha instruccin etiquetada2 (lia 945) e contina
a busca doutro delimitador.
Unha vez localizado o delimitador bscase entre a sa posicin3 e a posicin da expresin
no cdigo, unha das seguintes palabras reservadas do C++: if, switch, for, while ou return (lia
1039). O tipo da instruccin inciase en funcin da palabra reservada atopada, en caso de non
atopar ningunha o tipo inciase ao valor STATEMENT. Existen algns casos nos que esta
anlise inicial non suficiente para determinar o contexto da expresin e precisan dun
procesamento mis especfico (lias 1040-1055). Estes casos son os seguintes:
bZ O algoritmo nicamente comproba as instruccins etiquetadas
case e default. A utilizacin de etiquetas de salto
non habitual e o seu uso non soportado nesta primeira versin do compilador.
63 Ntese que no caso de non atopar nengn delimitador isto indicaria que a expresin est contida na primeira das
instruccins do cdigo.
248
Distincin entre unha expresin que unha instruccin por si propia e unha instruccin for
Cando o delimitador da instruccin previa atopado `;' e non hai ningunha palabra C++
reservada entre a posicin do delimitador^ e a da expresin con eventos, poden darse dous
casos diferentes: que a expresin con eventos estea includa na parte condicional dunha
instruccin for, ou nunha expresin que por si propia constite unha instruccin. Os seguintes
exemplos mostran as diferentes posibilidades:
1060./* caso 1: a expreain fai parte dun for */
1061.// l.a: ondicin do for (tipo = FOR2)
1062.for(<for_initial_expression>;[delimôs]
1063.
[st_begin]<condition_with_complex_event_expression>;
1064.
<expression>)
1065. <statement>;
1066.
1067.// l.b: expresin do for executada ao final de cada ciclo

1068.for(<for_initial_expression>;
1069.
<condition>;[delimôs]
( tipo = FOR3)
[st_begin]<expression_with_complex_event_expression>)
1070.
1071.
<statement>;
1072.
1073./* caso 2: a expresin noa fai parte dun for */
1074. <statement>; [delimôs]
1075.[st_begin]<statement_with_complex_event_expression>;
O algoritmo identifica as diferentes posibilidades e corrixe axeitadamente o valor deînicio

da instruccin65 e o do tipo de contexto, que pasar a ser FOR2, FOR3 ou STATEMENT
dependendo do caso concreto.
Distincin entre unha instruccin while e unha do while
Se a palabra C++ reservada atopada entre a posicin do delimitador da instruccin previa e a
da expresin con eventos while, poden darse dous casos: que a expresin con eventos estea
includa nunha instruccin while ou na parte condicional dunha instruccin do while. Os
seguintes exemplos mostran as diferentes posibilidades:
1076./* caso 1: a expresin fai parte dun whi2e */
1077.
<statement>;[delimôs]
1078.[st_begin]while(<condition_with_complex_event_expression>)
1079.
<statement>;
1080.
1081./* caso 2: a expresin fai parte dua do while */
do
1082.
<statement>;[delimôos]
1083.
1084.[st_begin]while(<condition_with_complex_event_expression>);
O algoritmo distingue entre ambas e no caso de tratarse dunha instruccin do while corrixe o
valor de inicio da instruccin e o do tipo de contexto, que pasar a ser DOWHILE. A
determinacin do inicio da instruccin do while require buscar a palabra reservada do que se
corresponda co while atopado e que apareza no cdigo nunha posicin anterior sa, tendo en
conta que as instruccins do while poden aniarse entre si e con outras instruccins while, tal e
como mostra o exemplo seguinte:
^4 Indicada como [delimôs].

bs Indicado como [st begin].
249
1085.
do // iaicio da instruccin do while
while(<condition>)
1066.
1067.
do
1088.
1089.
if (<condition>)
1090.
do
1091.
do
.
1092.
while(<condition>); // while cuaha inatruccin baleira
1093.
while(<condition>);
1094.
while(<condition>);
1095.
else
1096.
do ; // do while cunha instruccin baleira
1097.
while(<condition>);
1098.
}
1099.
while (<condition>) ; [delimôs]
1100.[st_begin]while(<condition_with_complex_event_expression>);
Distincin entre unha expresin utilizada na condicin ou na primeira instruccin do cdigo

dunha instruccin if, while ou for
Se a palabra C++ reservada atopada if, while ou for preciso distinguir se a expresin
parte da condicin da instruccin ou da primeira das instruccins do seu cdigo. O seguinte
exemplo mostra as das posibilidades para unha instruccin if:
caso 1: a expresin parte da condicin */
<statement>; [delimôs]
1102.
1103.[st_begin]if (<condition_with_complex_event_expression>)[cond_end]
<statement>;
1104.
1101./*
1105.
1106./* caso 2: a expreain parte da primeira instruccin */
1107.
<statement>;[delimôs]
1108.[st_begin]if (<condition>)[cond_end]
<statement_with_complex_event_expression>;
1109.
Neste exemplo o algoritmo detectara a palabra reservada if entre a posicin do delimitador

da instruccin previa e a posicin da expresin no cdigo. O tipo da instruccin iniciarase o
valor IF e a posicin de inicio iniciarase posicin do if no cdigo. Sen embargo, no segundo
caso mostrado no exemplo preciso corrixir o tipo e posicin de inicio da instruccin (lias
1106-1109). O tipo pasar a ser STATEMENT e a posicin de inicio ser igual ao final da
condicin6. Este mesmo razoamento aplicbel s instruccins while e for. Nas instruccins
switch e do while non aparece este problema xa que a sa condicin sempre vai seguida dos
delimitadores `{` e`;', respectivamente. Polo tanto sempre que se detecte as palabras
reservada switch ou while nunha destas instruccins, a nica posibilidade que a expresin
estea includa na condicin da instruccin.
Unha vez identificado o tipo de instruccin no que est includa a expresin, o ltimo paso
do algoritmo (lia 1057) consiste na recopilacin da informacin de contexto explicada
anteriormente: posicins de inicio e fin da instruccin, posicins de inicio e fin do cdigo da
instruccin e determinacin de se o cdigo est pechado entre `{}'. A parte do algoritmo que
realiza este clculo ten en conta as consideracins seguintes:
1.
Cando a expresin est includa na condicin dunha instruccin if, hai que determinar se
o ifinicial ou parte dunha pla else if. O seguinte cdigo mostra un exemplo:
1110. / * caso 1: a expresin est na condicin dun f */
1111.[begin]if (<condition_with_complex_event_expression>)
<statement_seq>
1112.
^ Indicado como [cond end].
250

1113./* caso 2: a expresin est na condicin dua elae if */
1114.[begin]if (<condition>)
<statement_seq>
1115.
1116.
1117.
else if (<condition_with_complex_event_expression>)
<statement_seq>
Polo tanto a localizacin do inicio da instruccin require buscar a palabra reservada if que
non vaia antecedida dun else e que se corresponda co else if no que est a expresin. D
mesmo xeito que aconteca nas instruccins do while explicadas anteriormente o algoritmo
ten en conta que as instruccins if poden aniarse entre si e con outras instruccins, tal e
como mostra o exemplo seguinte:
1118.[begin]if (<condition>) // inicio da iastruccia if
1119.
if (<condition>)
1120.
1121.
if (<condition>)
<statement_seq>
1122.
1123.
1124.
1125.
1126.
1127.
1128.
1129.
else
<statement_seq>
else
<statement_seq>
else if (<condition>)
if (<condition>)
<statement_seq>
else
1130.
1131.
1132.
<statement seq>
else if(<condition_with_complex_event_expression>)
<statement_seq>
'
2. A localizacin do final do cdigo dunha instruccin pode implicar unha busca recursiva
cndo este est formado por mltiples instruccins aniadas unhas dentro doutras. O
seguinte cdigo mostra un exemplo:
1133.while (<condition_with_complex_event_expression>)
if (<condition>)
1134.
<statement_seq>
1135.
1136.
else
for (<initial_for_expr>;<condition>;<expression>)
1137.
<statement>;[cend]
1138.
Neste exemplo, a determinacin do final do cdigo da instruccin while67 faise buscando 0

punto no que remata a instruccin for contida na parte else da instruccin if.
En resume, a implementacin desta fase ten en conta todas as consideracins indicadas para
a obtencin da informacin de contexto dunha expresin con eventos complexa. Os detalles das
partes do algoritmo que permiten diferenciar os diferentes contextos e calcular a sa
informacin non foron includos para evitar complicar en exceso a explicacin desta fase.
Simplificacin de expresins con eventos complexas ("EventExpressionCompiler")
Esta fase encrgase de simplificar as expresins con eventos complexas calculando unha
equivalente que s utilice eventos simples, dacordo ao explicado en (6.3.3.1). Para a reduccin
das expresins utilzase a aplicacin externa Sidoni ( 1.3.3), que unicamente reduce expresins
lxicas con eventos, polo que preciso adaptar as expresins C++ (que poden conter
subexpresins numricas) para que sexan aceptadas por Sidoni. A adaptacin de cada expresin
detectada na fase EventExprHarvester realzase mediante as operacins seguintes:
67 Indicado como [cend].
251
1. Analzase sintacticamente a expresin, obtendo como resultado a rbore da sintaxe

abstracta (AST) que a representa. Esta AST utilizada para identificar as subexpresins
numricas e as subexpresins con eventos complexas aniadas.
2. Modificase a AST da expresin, substitundo as subexpresins numricas e as
subexpresins con eventos complexas aniadas por varibeis booleanas. ^No cdigo
resultado da modificacin, estas varibeis sern iniciadas ao valor devolto pola
subexpresin que substiten.
3. Simplificase a AST modificada utilizando Sidoni, aplicacin que utiliza as regras do
lxebra de Boole estendidas (que teen en conta os flancos no valor das varibeis
booleanas) para simplificar expresins lxicas.
4. Procsanse as expresins con eventos complexas aniadas, aplicando as operacins
anteriores a cada unha delas.
5. Modificase o cdigo orixinal, substitundo a expresin inicial pola equivalente simplificada
e engadindo o cdigo para o manexo das expresins non booleanas segundo o explicado en
(6.3.3.1).
Cada un destes pasos explicado en detalle a continuacin.
Anlise sintctica da expresin, obtencin da AST
Para realizar a anlise sintctica da expresin implementouse un analizador sintctico
tomando como base a gramtica68 descrita en (6.3.1.2). O analizador foi xerado
automaticamente mediante a aplicacin ANTLR, que unha ferramenta que permite xerar
automaticamente analizadores sintcticos pred-LL(k): analizadores descendentes recursivos
con k"tokens" de adianto e soporte utilizacin de predicados semnticos e sintcticos para a
resolucin de ambigidades na gramtica. Esta utilidade parte do PCCTS ( 1.3.4), un
conxunto de ferramentas para a xeracin automtica de compiladores [135].
A definicin da gramtica no formato utilizado por ANTLR pode verse no Anexo D. Esta
gramtica est anotada con smbolos e accins que dirixen o proceso de construccin da AST
de cada expresin. O acceso ao analizador sintctico faise mediante unha clase auxiliar
denominada CPPParserWrapper, cuxa interface pblica a seguinte:
1139.class CPPParserWrapper
1140. {
1141.
void operator()(const string& input, ASTBase **ast);
1142. };
Os detalles do cdigo que executa as aplicacins auxiliares xeradas polo PCCTS para
realizar a anlise sintctica das expresins son ocultados na implementacin do operador
operatorQ. Este mtodo recibe o cdigo da expresin a analizar -no parmetro input- e
devolve a AST da expresin -no parmetro ast-. Os seguintes exemplos mostran as ASTs
xeradas para algunhas expresins:
^ Coa excepcin dos temporizadores que son substituidos previamente na fase TimerPreprocessor, o que pen^nite
restrinxir o seu uso nicamente s condicins de transicin.
252

1143.
1144.
1145.
1146.
1147.
1148.
1149.
1150.
T(a && ^(b
^^
3+c > 5
T(a > b+3))
&& lfun(ob->sys.dat[i++]))
( - )
&& - a
&&
1151.
1152 . I
^
^
1153 . !
1154 . ^
( - )
I
1155. ( - fun
1156. ^
1157. [ - ++ - i
^^
^
1158 . ^
1159. . - dat
1160. ^
1161. -> - ob - sys
1162.
1163.
^)
( - )
^^ - b
^
^
> - a
> - 5
I
^
+ - 3 - c + - b - 3
T(SOO+class::attrib
>((T(c > d*3 ^^ .^(c ^^ d/3 > b)))?12:(26*b)) ^^ ^c)
1164 . ^
1165. ^
1166.
( - )
1167. ^
1168. ^^
1169. ^
1170.
>
1171. ^
+ - 500 - class::attrib
1172.
1173.
1174.
1175.
( - )
^
? - 12 - . - ( - )
^
^
* - 26 - b
( - )
^
1176.
1177.
1178.
1179.
1180.
1181.
1182.
1183.
1184.
1185.
1186.
1187.
1188.
^^
I
> - c
( - )
^
* -d-3
( - )
^^
-c
> - b
^
/ -d-3
Reduccin da AST da expresin

Para realizar a modificacin da AST substitundo as subexpresins numricas e as
subexpresins con eventos complexas por varibeis auxiliares booleanas utilizouse un
analizador\traductor de rbores sintcticas xerado automaticamente mediante a aplicacin
Sorcerer, que outra das ferramentas do PCCTS. A gramtica utilizada para xerar o analizador
pode verse no Anexo E. O acceso a este analizador faise mediante unha clase auxiliar
denominada CPPTreeParser, cuxa interface pblica a seguinte:
1189.class CPPTreeParser
1190 . {
void parse(SORASTBase **root, SORASTBase **result,
1191.
astdata_seq& expressions, unsigned& init_number);
1192.
1193 . ^ ;
253
O mtodo parse implementa o proceso de anlise e substitucin da AST da expresin. Este

mtodo recibe dous argumentos: a AST orixinal -no parmetro root- e un ndice utilizado
para numerar as varibeis auxiliares nas substitucins -no parmetro init_number-; e
devolve a AST da expresin resultado -no parmetro result- e as ASTs das subexpresins
substitudas -no parmetro expressions-. Os seguintes exemplos mostran os resultados
obtidos ao reducir as expresins das lias 1143 e 1162:
1194./* Exemplo 1: Expresia orixinal */
1195.T(a && ^(b ^^ 3+c > 5 ^^ T(a > b+3)) && !fun(ob->sys.dat[i++]))
1196.
1197./* Resultado */
1198.T(a && ^(b ^^ sfcpp_expr_1 ^^ T(sfcpp_expr_2)) && !sfcpp_expr_3)
1199.
1200./*
Subexpresins substitudas */
1201.sfcpp_expr_1 = 3+c > 5
1202.sfcpp_expr_2 = a > b+3
1203.sfcpp_expr_3 = fun(ob->sys.dat[i++))
1204./* Exemplo 2: Expresin orixinal */
1205.T(500+class::attrib >((T(c > d*3 ^^ ^(c ^^ d/3 > b)))?12:(26*b)) ^^ ^c)
1206.
1207./* Resultado */
1208.'(sfcpp_expr_1 ^^ ^c)
1209.
1210./* Subexpresias substitudas */
1211.sfcpp_expr_1 = SOO+class::attrib > ((sfcpp_expr_2)?12:(26*b))
1212.
1213./* Subexpresins aaiSadas */
1214.sfcpp_expr_2
1215.sfcpp_expr_3
1216.sfcpp_expr_4
1217.sfcpp_expr_5
=
=
=
=
T(sfcpp_expr_3 ^^ sfcpp_expr_4)
c > d*3
^(c ^^ sfcpp_expr_5)
d/3 > b
No caso da primeira expresin (lia 1195) o analizador detecta tres subexpresins numricas
(non booleanas), que substite por varibeis booleanas auxiliares (coa sintaxe sfcpp_expr_id).
A segunda das expresins (lia 1205) contn unha nica subexpresin numrica que
substituda polo analizador. Esta subexpresin sfcpp_expr_I- contn sa vez unha
expresin con eventos complexa (a condicin do operador `?:'), polo que o proceso de
reduccin aplicado recursivamente, e esta subexpresin substituda pola varibel
sfcpp_expr 2. O proceso continua aplicndose recursivamente s subexpresins numricas e
con eventos contidas en sfcpp_expr_2 ata que non queda ningunha sen substitur.
Simplificacin da expresin
Unha vez reducida a expresin orixinal para que contea unicamente subexpresins
booleanas, a simplificacin da expresin faise utilizando a aplicacin externa Sidoni [ 146],
dacordo ao explicado en (6.3.3.1). Esta aplicacin utiliza as regras do lxebra de Boole
estendidas co soporte utilizacin de eventos para simplificar expresins lxicas. O acceso a
esta aplicacin faise mediante a clase auxiliar SidoniWrapper, que se encarga de converter unha
expresin booleana C++ ao formato utilizado por Sidoni, executar a aplicacin -utilizando a
tcnica explicada en (6.1.3^ e converter o resultado de novo sintaxe do C++. A Tboa 6-II
mostra a correspondencia entre as caractersticas soportadas por Sidoni e o equivalente C++
estendido cos operadores de evento e temporizacin.
254

^
Operadores booleanos
AND = .
AND = &&
OR=+
OR=II
NOT = /
NOT = !
Operadores con eventos > e<
' e^
Constantes numricas
=0
=1
Calquera valor numrico
Varibeis
X;d = identificador de etapa
X_;d = identificador de etapa
id = varibel de proceso
sfcpp_timer_id = temporizador
sfcpp_expr_id = varibel auxiliar
id = varibel de proceso, do modelo
ou identificador de accin
Tboa 6-II. Equivalencia entre os operadores Sidoni e os operadores C++.
O exemplos seguintes mostran o resultado da simplificacin das expresins das lias 1143 e
1162, representadas no formato Sidoni e na sintaxe C++ (ntese que no caso da expresin da
lia 1162, tamn son simplificadas as subexpresins con eventos complexas aniadas):
1219.T(a && ^(b ^^ 3+c > 5 ^^ T(a > b+3)) && !fun(ob->sys.dat[i++]))
1220.
1221./* Expreain reducida */
1222.// Siataxe C++
1223.T(a && .^(b ^^ sfcpp_expr_1 ^^ T(sfcpp_expr_2)) && !sfcpp_expr_3)
1224.// Sintaxe Sidoai
1225.>(a . <(b + sfcpp_expr_1 + >(sfcpp_expr_2)) . /sfcpp_expr_3)
1226.
1227./* Expresin simplificada */
1228.// Sintaxe Sidoni
1229.(<b . /sfcpp_expr_1 . a . /sfcpp_expr_3) +
(<sfcpp_expr_3 . /b . a . /sfcpp_expr_3)
1230.
1231.// Sintaxe C++
1232.(.^b && !sfcpp_expr_1 && a && !sfcpp_expr_3) ^^
(^sfcpp_expr_3 && !b && a && !sfcpp_expr_3)
1233.
1235.T(500+class::attrib >((T(c > d*3 ^^ .^(c ^^ d/3 > b)))?12:(26*b)) ^^ ^c)
1236.
1237./* Expresin reducida */
1238.// Siataxe C++
1239.T(sfcpp_expr_1 ^^ ^c)
1241.>(sfcpp_expr_1 + <c)
1242.
1243./* Expreain simplificada */
1244.// 3intaxe Sidoni
1245.>sfcpp_expr_1 + (<c . /sfcpp_expr_1)
1246.// Sintaxe C++
1247.Tsfcpp_expr_1 ^^ (^c && !sfcpp_expr_1)
1248.
1249./* Subexpresina con eventos aniadas reducidas */
1250.// Sintaxe C++
// sfcpp_expr_2
1251.T(sfcpp_expr_3 ^^ sfcpp_expr_4)
// sfcpp_expr_4
1252.^(c ^^ sfcpp_expr_5)
255
1254.>(sfcpp_expr_3 + sfcpp_expr_4)
// afcpp_expr_2
1255.<(c + sfcpp_expr_5)
// sfcpp_expr_4
1256./* Subexpresins con eventos aniSadas simplificadas

1258.(/sfcpp_expr_4 . >sfcpp_expr_3) +
//
1259.
(>sfcpp_expr_4 . /sfcpp_expr_3)
1260.(<c . /sfcpp_expr_5) + (<sfcpp_expr_5 . / c)

//
1261.// Sintaxe C++
1262.(!sfcpp_expr_4 && Tsfcpp_expr_3) ^^

//
1263.
('sfcpp_expr_4 && !sfcpp_expr_3)
1264.(^c && !sfcpp_expr_5) ^^ (^sfcpp_expr_5 && !c)

//
*/
sfcpp_expr_2
sfcpp_expr_4
sfcpp_expr_2
afcpp_expr_4
Hai un aspecto adicional a considerar na utilizacin de Sidoni. Esta aplicacin ten en conta
automaticamente as seguintes hipteses do modelo Grafcet ( 3.3.2.1):
1.
Non posbel a ocorrencia simultnea de dous eventos externos non relacionados (Ta and
T b = 0).
2.
Non posbel a ocorrencia simultnea dun evento externo e un interno (Ta and TX, = 0).
Sen embargo na implementacin do algoritmo de interpretacin dos modelos Grafcet

utilizado na mquina virtual ( 8.3.1.3) esta unha caracterstica configurbel, que pode
aplicarse ou non dacordo ao indicado polo usuario. Polo tanto preciso evitar que Sidoni
aplique automaticamente estas hipteses na simplificacin de expresins, para que o resultado
da simplificacin poda ser utilizado nambos casos. A tcnica utilizada consistiu en preceder
todas as varibeis utilizadas na expresin orixinal coa letra X, de modo que Sidoni interpreta
que todas as varibeis utilizadas son internas (varibeis de etapa) e non se dan, polo tanto, as
condicins para a aplicacin das hipteses indicadas. Unha vez simplificada a expresin
elimnanse os prefixos das varibeis. En certos casos o resultado obtido non a simplificacin
mnima que podera obterse, mais conserva a semntica da expresin orixinal durante a
execucin dos modelos tanto se se teen en conta as hipteses anteriores coma se non.
Modificacin do cdigo
A ltima operacin realizada por esta fase do compilador consiste na modificacin do
cdigo da expresin orixinal polo cdigo da expresin simplificada, as como a insercin do
cdigo que declara, inicia e actualiza as varibeis auxiliares utilizadas para a substitucin das
expresins numricas e con eventos aniadas, dacordo tcnica explicada en (6.3.3.1). O
cdigo modificado a utilizar depende do contexto da expresin, tal e como se indica en
(6.3.3.1). As diferentes posibilidades tratadas polo compilador e a localizacin do cdigo
auxiliar en cada caso son as seguintes:
Instruccin de seleccin if (tipo = IF)
1265.[declaracin + iniciacin]
1266.if (<condition_with_complex_event_expression>)
1267. <statement>;
Instruccin de seleccin switch (tipo = SWITCH)

1269.switch
(<condition_with_complex_event_expression>)
1270. {
1271.
case <value_1>: <statements> break;
1272.
case <value_n>: <statements> break;
default: <statements> break;
1273.
1274. }
256
Instruccin de iteracinfor (3 posicins, tipo = FOR[1 j2J31)

1275.// FOR1
1277.for(<expression_with_complex_event_expression>;
1278.
<condition>;
1279.
1280.
1281.
<expression>)
<statement>;
1282.// FOR2
1284.for(<expression>;
1285.
1286.
<expression>)
1287. {
1288.
<statements>
1289.
[actualizacn]
1290. }
1291.
1292.// FOR3
1293.[declaracin]
<condition>;
1295.
<expression_with_complex_event_expression>)
1296.
1297. {
1298.
<statements>
1299.
[actualizacin]
1300. }
Instruccin de iteracin do while (tipo = DOWHILE)

1301.[declaracin]
1302. do
1303. {
1304. <statements>
[actualizacin]
1305.
1306. }
1307.while (<condition_with_complex_event_expression>);
Instruccin de iteracin while (tipo = WHILE)

1309.while (<condition_with_complex_event_expression>)
1310 . {
<statements>
1311.
1312.
[actualizacin]
1313 . }
Instruccin de salto return (tipo = RETURN)

1315.return (<condition_with_complex_event_expression>);
Calquera outra instruccin (tipo = STATEMENT)

1317.<expression_statement_with_complex_event_expression>;
Os seguintes exemplos mostran o cdigo xerado para a substitucin das expresins das lias
1143 e 1162 cando son utilizadas en contextos tipo FOR2 e DOWHILE, respectivamente:
257
1318./* Cdigo orixinal

1320.
1321.
( FOR2) */
T(a && ^(b II 3+c > 5 II T(a > b+3)) && !fun(ob->sys.dat[i++]));
<expression>)
1322 . {
1323.
<statements>
1324. }
1325.
1326./* Cdigo modificado */
1327.// declaracin + iniciacin varibeis suxiliares
1328.boo1 sfcpp_expr_1 = (bool) (3+c > 5);
1329.boo1 sfcpp_expr_2 = (bool) (a > b+3);
1330.boo1 sfcpp_expr_3 = (bool) (fun(ob->sys.dat[i++]));
1332.
(^b && !sfcpp_expr_1 && a && !sfcpp_expr_3) II
1333.
(^sfcpp_expr_3 && !b && a && !sfcpp_expr_3);
1334.
<expression>)
1335 . {
<statements>
1336.
1337.
// actualizacin varibeis auxiliares
1338.
sfcpp_expr_1 = (bool) (3+c > 5);
sfcpp_expr_2 = (bool) (a > b+3);
1339.
1340.
sfcpp_expr_3 = (bool) (fun(ob->sys.dat[i++]));
1341 . }
Ntese que a pesares de que a subexpresin numrica substituda coa varibel auxiliar
sfcpp_expr_2 non utilizada na expresin orixinal simplificada (lia 1332) ao ser eliminada
durante a simplificacin da expresin, si declarada (lia 1329) e o seu valor actualizado (lia
1339) introducindo no cdigo clculos innecesarios. Este un aspecto a corrixir en futuras
versins do compilador.
1342./* Cdigo orixinal (DOWILE) */
1343 . do
1344 . {
1345.
1346. }
<statements>
1347.while (T(500+class::attrib>((T(c>d*3II `^(clld/3>b)))?12:(26*b))II ^c));
1348.
1349./* Cdigo modificado */
1350.// declaracin varibeis auxiliarea
1351.boo1 sfcpp_expr_1;
1352.boo1
1353.boo1
1354.boo1
1355.boo1
1356.do
sfcpp_expr_2;
sfcpp_expr_3;
sfcpp_expr_4;
sfcpp_expr_5;
1357. {
<statements>
1358.
1359.
/ / actualizacia varibeis auxiliaree
sfcpp_expr_5 = (bool) (d/3 > b);
1360.
sfcpp_expr_4 = (bool) ((^c && !sfcpp_expr_5) I) (^sfcpp_expr_5 && !c));
1361.
sfcpp_expr_3 = (bool) (c > d*3);
1362.
sfcpp_expr_2 = (bool) ((!sfcpp_expr_4 && Tsfcpp_expr_3) II
1363.
(Tsfcpp_expr_4 && !sfcpp_expr_3));
1364.
sfcpp_expr_1 = (bool) (SOO+class::attrib>((sfcpp_expr_2)?12:(26*b)));
1365.
1366. }
1367.while ('sfcpp_expr_1 II (^c && !sfcpp_expr_1));
Como se explica en (6.3.3.1), cando no resultado da simplificacin da expresin con

eventos complexa aparece algn evento simple que afecte a algunha das varibeis auxiliares
utilizadas para substitur as subexpresins numricas e con eventos aniadas, preciso inserir
cdigo adicional que permita detectar os flancos no valor das varibeis auxiliares. Este sera o
258
caso da varibel sfcpp_expr 3 (lia 1330), no primeiro dos exemplos anteriores, e das varibeis
sfcpp_expr 1 (lia 1351), sfcpp_expr_3 (lia 1353), sfcpp_expr_4 (lia 1354) e sfcpp_expr S
(lia 1355), no segundo.
A deteccin destes eventos realzase na fase VarlnfoHarvester, e a insercin do cdigo
adicional, dacordo tcnica explicada en (6.3.3), na fase EventVarTranslator. O resultado
destas modificacins nos exemplos anteriores sera o seguinte:
1368./* Cdigo final ( FOR2) */
1369.// Varibeis para o clculo de eventos aa subexpresin 3
1370.static bool sfcpp_expr_3_last = false;
1371.boo1 sfcpp_expr_3_up, sfcpp_expr_3_down;
1372.
1373.// Declaracin + iniciacin varibeis auxiliarea
1374.boo1 sfcpp_expr_1 = (bool) (3+c > 5);
1375.boo1 sfcpp_expr_2 = (bool) (a > b+3);
1376.
1377.// Clculo da subexpresin 3 e dos cambios no seu valor
1378.boo1 sfcpp_expr_3 = (bool) (fun(ob->sys.dat[i++]));
1379.if (sfcpp_expr_3 != sfcpp_expr_3_last)
1380. {
1381. sfcpp_expr_3_up = (sfcpp_expr_3_last) ? false : true;
1382. sfcpp_expr_3_down = (sfcpp_expr_3_last) ? true : false;
1383. sfcpp_expr_3_last = sfcpp_expr_3;
1384. }
(^b && !sfcpp_expr_1 && a && !sfcpp_expr_3) ^^
(sfcpp_expr_3_down && !b && a && !sfcpp_expr_3);
<expression>)
1386.
1387.
1388.
1389. {
1390.
<statements>
1391.
1392.
1393.
// actualizacin varibeis auxiliares
1394.
1395.
1396.
1397.
1398.
1399.
1400.
// Actualizacin da subexpreain 3 e dos cambios no seu valor
sfcpp_expr_3 = (bool) (fun(ob->sys.dat[i++]));
if (sfcpp_expr_3 != sfcpp_expr_3_last)
sfcpp_expr_3_up = (sfcpp_expr_3_last) ? false : true;
sfcpp_expr_3_down = (sfcpp_expr_3_last) ? true : false;
sfcpp_expr_3_last = sfcpp_expr_3;
1401.
1402. }
sfcpp_expr_1 = (bool) (3+c > 5);
sfcpp_expr_2 = (bool) (a > b+3);
1403./* Cdigo final
( DOWHILB) */
1404.// Varibeis para o clculo de eveatos aas subexpresins 1,3,4 e 5
1413.
1414.// Declaracin varibeis auxiliares
1415.boo1 sfcpp_expr_1;
1416.boo1
1417.boo1
1418.boo1
1419.boo1
1420. do
1421 . {
1422.
sfcpp_expr_2;
sfcpp_expr_3;
sfcpp_expr_4;
sfcpp_expr_5;
<statements>
259
1423.
1424.
// Actualizacin varibeia auxiliares
sfcpp_expr_5 = (bool) (d/3 > b);
1425.
1426.
1427.
1428.
1429.
1430.
1431.
1432.
1433.
1434.
1435.
1436.
1437.
1438.
1439.
1440.
1441.
1442.
sfcpp_expr_4 = (bool) ((^c && !sfcpp_expr_5) ^^ (sfcpp_expr_5_down && !c));
sfcpp_expr_3 = (bool) (c > d*3);
1443.
1444.
1445.
1446.
1447.
1448.
1449.
1450.
1451.
1452.
sfcpp_expr_2 = (bool) ((!sfcpp_expr_4 && sfcpp_expr_3_up) ^^
(sfcpp_expr_4_up && !sfcpp_expr_3));
sfcpp_expr_1 = (bool) (500+class::attrib>((sfcpp_expr_2)?12:(26*b)));
1453.
1454.
1455.
1456.
1457.
1458. }
1459.while (sfcpp_expr_1_up ^^ (^c && !sfcpp_expr_1));
Recopilacin da informacin das varibeis utilizadas no cdigo ("VarInfoHarvester")

Esta a fase encargada de detectar as varibeis e eventos simples utilizados no cdigo e
recopilar a informacin que permita en fases posteriores substitulos dacordo s tcnicas
explicadas en (6.3.3). Os tipos de varibeis identificados por esta fase son:
Varibeis do proceso.
Varibeis do modelo.
Estados de activacin das etapas do modelo, de sintaxe X id.
Estados de activacin das accins do modelo.
Varibeis auxiliares para a substitucin de temporizadores, de sintaxe sfcpp_timer_id. Estas

varibeis son introducidas no cdigo como resultado das substitucins realizadas pola fase
TimerPreprocessor (6.5.1.5.2).
Varibeis auxiliares para a substitucin de expresins numricas, de sintaxe sfcpp_expr id.

Estas varibeis son introducidas no cdigo como resultado das substitucins realizadas pola
fase EventExpressionCompiler.
Para cada unha das varibeis identificadas obtense a informacin seguinte, que ser utilizada
para determinar o tipo de substitucin a realizar:
Identificador numrico nico asignado polo compilador.
Posicin da varibel no cdigo.
Nome da varibel.
Tipo de datos da varibel.
260
Tipo de varibel (un dos indicados anteriormente).
Indicador booleano de se a varibel est precedida dun operador de evento.
Indicador booleano do tipo de operador do que se trata (T ou ^).
Indicador booleano de se o valor da varibel pode ser consultado.

Indicador booleano de se o valor da varibel pode ser modificado.
Ao tempo que obtn a informacin das varibeis, esta fase tamn detecta os seguintes erros:
Utilizacin dos operadores de evento con varibeis non booleanas.
Utilizacin dos operadores de evento con varibeis booleanas cuxo valor non poda ser
consultado, p.e. as sadas do proceso.
Utilizacin de varibeis cuxo valor non poda ser consultado cando o cdigo compilado
corresponda a unha condicin de transicin, condicin dunha asociacin de accin ou
condicin dun temporizador.
Substitucin de varibeis e eventos simples ("EventVarTranslator")

Esta a fase que, utilizando a informacin recopilada na fase previa, substite varibeis e
eventos simples polo cdigo que permite acceder aos seus valores en tempo de execucin
dacordo s tcnicas descritas en (6.3.3). Esta fase leva rexistro das substitucins xa realizadas
de xeito que a mesma varibel auxiliar utilizada para substitur todas as aparicins no cdigo
dunha mesma varibel ou evento simple. Isto permite reducir o nmero de varibeis auxiliares
utilizadas e o numero de accesos informacin almacenada pola mquina virtual durante a
execucin dos modelos.
6.5.1.6. Procesamento das condicins das asociacins ("SFCActionConditionCompiler")
Esta fase comparte subfases coa fase SFCActionCodeCompiler (6.5.1.5), polo que realiza
as mesmas operacins, executando as subfases unha vez por cada condicin de asociacin do
modelo.
6.5.1.7. Procesamento das condicins de transicin ("SFCReceptivityCompiler")
as mesmas operacins, executando as subfases unha vez por cada condicin de transicin do
modelo.
6.5.1.8. Procesamento das condicins dos temporizadores ("SFCTimerConditionCompiler")
as mesmas operacins, executando as subfases unha vez por cada condicin de temporizacin
do modelo.
6.5.1.9. Xeracin do cdigo fonte da DLL ("SFCDLLGenerator")
Nesta fase xrase o cdigo fonte da DLL que vai permitir cargar na mquina virtual a
informacin precisa para a execucin do modelo. Este cdigo esta formado por dous arquivos
261
(Figura 6.1), un que contn as declaracins das funcins da DLL (de extensin . h) e outro as
implementacins das funcins (de extensin .cpp). O cdigo C++ xerado para o arquivo que
contn as declaracins da DLL o seguinte:
1460.// defiaicias auxiliarea
1461.#define DLL_API _declspec(dllexport)
1462.// i aterface da DLL
1463.extern "C"
1464 . {
/ / interface pblica comn
1465.
DLL_API bool onLoad(void);
1466.
1467.
DLL_API void onUnload(void);
1468.
DLL_API deque<modulerpointer>& getModules(void);
1469.
1470.
// para cada accin ( action_name = i dentificador da accin)
DLL_API void action name(RunningPolicy& env);
1471.
1472.
// para cada condicia de asociacin ( nnn = identificador da asociacin)
DLL_API bool action name_nnn(RunningPolicy& env);
1473.
// para
DLL_API
// para
DLL_API
1474.
1475.
1476.
1477 . }
cada
bool
cada
bool
condicin de transicia ( nna = identificador da transicin)
cond_nnn(RunningPOlicy& env);
temporizador ( nnn = identificador do temporizador)
timer_nnn(RunningPOlicy& env);
As funcins onLoad (lia 1466), onUnload (lia 1467) e getModules (lia 1468) declaran a
interface comn a todas as DLLs utilizadas coa mquina viriual (7.1.1.5), e son utilizadas para
a carga e descarga dinmica de mdulos executbeis. Ademais inclense as seguintes
declaracins:
1. Unha funcin por cada accin do modelo (lia 1470). O identificador de cada unha destas
funcins igual ao nome da accin no modelo.
2. Unha funcin por cada condicin de asociacin de accin do modelo (lia 1472). O
identificador de cada funcin ten a sintaxe: action_name_nnn, sendo action_name o nome
da asociacin (que pode ser o dunha varibel do modelo, varibel de proceso ou accin) e
nnn o identificador numrico asignado asociacin polo compilador.
3. Unha funcin por cada receptividade do modelo (lia 1474). O identificador de cada
funcin ten a sintaxe: cond_nnn, sendo nnn o identificador numrico asignado
receptividade polo compilador (6.5.1.2.2).
4. Unha funcin por cada temporizador utilizado nas receptividades do modelo e mis por
cada un dos definidos automaticamente polo compilador (6.5.1.2.1) para a temporizacin
das accins retardadas e limitadas (lia 1476). O identificador de cada funcin ten a
sintaxe: timer_nnn, sendo nnn o identificador numrico asignado ao temporizador polo
compilador (6.5.1.2.2).
Estas funcins reciben como nico parmetro unha instancia da clase RunningPolicy (8.6)
que implementa a interface IVMachineAccess (6.3.2) que proporciona acceso aos valores de
varibeis e temporizadores almacenados na mquina virtual durante a execucin dos modelos.
As funcins que representan condicins lxicas devolven ademais un valor booleano, que o
resultado da avaliacin da condicin utilizando os valores que varibeis, eventos e
temporizadores tean no momento da chamada funcin.
En canto ao arquivo que contn a implementacin da DLL, o cdigo xerado o seguinte:
1478.//
arquivos de definicins
1479.#include "gescartmodellib.h" / / definicins comna ao co^mpilador e vM
1480.#include
1481.#include
"DLLname.h"
"project.h"
// definicias da DLL
// definicias do proxecto
262
1482.// declaracins globais
1483.deque<moduleôinter> modules;
1484.
1485./* INT$RFACB COMN */
1486.// onLoad
1487.DLL_API bool onLoad(void)
1488. {
1489.
// crear iaformacin para a execucin do modelo
1490.
RTModel* rtmodel = new RTModel();
1491. if (!rtmodel) return true;
1492. GESCA_TRY
1493. {
1494.
RTStaticModel& rtstaticmodel = rtmodel->getStaticModel();
1495.
rtstaticmodel.setKey("model_id"); / / almacenar identificador do modelo
1496.
1497.
// para cada declaracin de varibel
1498.
1499.
modeldatadeclôinter var = NULL;
var = new GescaVarDecl<var_data_type>("var_id",
(ElementAccess) var_access,
(ElementScope) var_scope);
if (!var) GESCA_THROW_BAD ALLOC
rtstaticmodel.getDecls().insert(var);
1500.
1501.
1502.
1503.
1504.
1505.
1506.
1507.
1508.
1509.
1510.
1511.
// para cada grafcet parcial
RTPGInfo* pg = NULL;
pg = new RTPGInfo(pg_id, "pg_key");
if (!pg) GESCA_THROW_BAD_ALLOC
pg->steps.insert(step_id);
// unha lia para cada etapa
pg->fosteps.insert(step_id); // uaha lia para cada etapa con FOs
rtstaticmodel.addPG(pg);
1512.
1513.
1514.
// para cada nodo
RTNodeInfo* node = NULL;
1515.
1516.
1517.
1518.
node = new RTNodeInfo(node_id, "node_key", pg_id);
if (!node) GESCA_THROW_BAD_ALLOC
// uaha lia por cada predecesor
node->before.insert(node id);
// unha lia por cada sucesor
node->after.insert(node_id);
1519.
1520.
1521.
rtstaticmodel.addNode(node);
1522.
RTReceptivity2nfo* tinfo = NULL;
1523.
1524.
1525.
1526.
1527.
1528.
1529.
tinfo = new RTReceptivityInfo(rec_id, "cond_rec_id", source_flag);
if (!tinfo) GESCA_THROW_BAD_ALLOC
tinfo->vars.insert("var name"); // unha lia para cada varibel
rtstaticmodel.addReceptivity(tinfo);
rtmodel->addCondition("cond_rec_id",
cond_rec_id);
// referencia ao cdigo
1530.
1531.
1532.
1533.
1534.
1535.
// para cada asociacin
RTActionInfo* ainfo = NULL;
ainfo = new RTActionlnfo(assoc_id, step_id, "assoc_name",
(ActionType) assoc_type, "assoc_indicator",
assoc_delay, assoc_limit, "assoc_name_nnn",
(TimeScale) assoc_tscale,
1536.
1537.
1538.
1539.
1540.
(RTActionType) assoc_rttype);
if (!ainfo) GESCA_THROW_SAD_ALLOC
ainfo->vars.insert("var_name"); // unha lia para cada varibel
rtstaticmodel.addAction(ainfo);
rtmodel->addCondition("assoc name_nnn",
1541.
1542.
// addlnitialNode se unha etapa inicial
// para cada condicin de transicia
assoc_name_nnn); //
referencia ao cdigo
1543.
// para cada accin
1544.
1545.
1546.
var = new GescaVarDecl<bool>("action_name",
(ElementAccess) 2, // acceso R/W
(ElementScope) 2); // alcance
263
1547.
1548.
1549.
1550.
rtmodel->addAction("action_name", action_name); // refereacia ao cdigo
1551.
// para cada orde de forzado

RTFOInfo* foinfo = NULL;
1552.
1553.
1554.
1555.
1556.
1557.
1558.
1559.
1560.
1561.
1562.
/ / xerarqua de forzado
RTSituation level;
rtstaticmodel.initFOLevels(num_folevels);
// para cada nivel da xerarqua
1563.
1564.
level.insert(step_id); // unha lia por cada etapa no nivel

rtstaticmodel.addFOLeve1(num_level, level);
1565.
1566.
level.clear();
foinfo = new RTFOInfo(pg_id, step_id, forcedpg_id,

(FOrderType) fo_type);
if (!foinfo) GESCA_THROW_BAD_ALLOC
foinfo->steps.insert(step_id); // unha lia por cada etapa forzada
rtstaticmodel.addFO(foinfo);
.,
1567.
// para cada temporizador
1568.
1569.
1570.
1571.
1572.
RTTimerInfo* timer = NULL;

var = new GescaVarDecl<bool>("sfcpp_timer_nnn",
(ElementAccess) 2, // acceso R/W
(ElementScope) 2); // alcance
1573.
1574.
1575.
timer = new RTTimerInfo(timer_id, "timer_nnn", timer_tl, timer_t2);

if (!timer) GESCA_THROW_BAD_ALLOC
1576.
1577.
timer->vars.insert(var_name); // unha lia para cada varibel

rtstaticmodel.addTimer(timer);
1578.
rtmodel->addCondition("timer_nnn", timer_nnn); / / referencia ao cdigo
1579.
// almacenar o modelo no conxunto de mdulos
1580.
modules.push_back(rtmodel);
1581.
1582. }
GESCA_CATCH_ALL
1583.
1584. {
1585.
delete rtmodel;
return true;
1586.
1587. }
1588. return false;
1589. }
1590.
1591.// onIInload
1592.DLL_API void onUnload(void)
1593. {
1594.
1595.
for (deque<module^pointer>::iterator module = modules.begin();
module != modules.end();
1596.
1597.
1598.
1599. }
++module)
delete *module;
modules.clear();
1600.
1601.// getModules
1602.DLL_API deque<moduleôinter>& getModules(void)
1603 . {
1604.
return modules;
1605 . }
264
1606./* CDIGO DO MOD$LO */
1607.// para cada accin
1608.DLL_API void action_name(RunningPolicy& env)
1609. {
// cdigo da accin
1610.
1611 . }
1612.
1613.// para cada

1614.DLL_API bool
1615 . {
1616.
// cdigo
1617 . }
1618.
1619.// para cada

1620.DLL_API bool
1621 . {
1622.
// cdigo
1623. }
condicin de asociacia
action_name_nnn(RunningPolicy& env)
"
da condicin de asociacia
condicin de tranaicin
cond_nnn(RunningPolicy& env)
da condicin de tranaicia
1624.
1625.// para cada temporizador
1626.DLL_API bool timer_nnn(RunningPolicy& env)
1627. {
1628.
1629. }
// cdigo da condicin do temporizador
Nas lias 1479-1481 inclense os arquivos que conteen as declaracins do ambiente de

execucin da mquina virtual, as da DLL e as de usuario, respectivamente. A implementacin
das funcins que permiten a carga e descarga dinmica de mdulos executbeis na mquina
virtual est nas lias 1487-1605. A funcin onLoad (lia 1487), chamada pola mquina virtual
durante a carga da DLL, inicia a informacin do modelo e insrea na cola de mdulos
varibel global modules declarada na lia 1483-. A mquina virtual accede aos mdulos
almacenados nesta varibel mediante a funcin getModules (lia 1602). Os mdulos son
eliminados na funcin ^nUnload (lia 1592), chamada pola mquina virtual cando a DLL
descargada. Ademais inclese a implementacin das funcins que conteen o cdigo de
accins (lia 1608), condicins de asociacin (lia 1614), condicins de transicin (lia 1620)
e condicins de temporizacin (lia 1626) obtido como resultado das substitucins explicadas
en (6.3.3).
A implementacin da funcin onLoad, na que se inicia a informacin do modelo utilizando
o formato explicado en (6.4), contn o cdigo seguinte:
1. Na lia 1490 crase unha instancia da clase RTModel (Figura 6.8), que vai conter a
informacin para a execucin do modelo.
2. Na lia 1494 obtense unha referencia informacin esttica do modelo.
3. Na lia 1495 asgnase un identificador ao modelo. Este identificador utilizado na
mquina virtual para identificar o modelo no caso de ter varios cargados simultaneamente
na memoria.
4. Nas lias 1498-1503 insrese, para cada varibel do modelo, o cdigo para crear a sa
declaracin utilizando a informacin recopilada polo compilador: nome, tipo, acceso e
alcance da varibel; e para inserila no modelo.
5. Nas lias 1506-1511 insrese, para cada grafcet parcial, o cdigo para crear unha instancia
da clase RTPGInfo (Figura 6.8) utilizando a informacin recopilada polo compilador:
identificador numrico e alfanumrico do grafcet parcial; para engadirlle a informacin das
etapas contidas no grafcet parcial e das que teen ordes de forzado asociadas (unha lia de
cdigo por etapa); e para inserir a informacin no modelo.
265
6. Nas lias 1514-1519 insrese, para cada nodo do modelo, o cdigo para crear unha
instancia da clase RTNodelnfo (Figura 6.8) utilizando a informacin recopilada polo
compilador: identificador numrico e alfanumrico da etapa, e identificador numrico do
grafcet parcial que contn a etapa; para engadirlle a informacin dos nodos que o suceden e
que o preceden na secuencia de control ( unha lia de cdigo por cada un); e para inserir a
informacin no modelo ( as etapas iniciais son inseridas no modelo utilizando un mtodo
diferente -addlnitialNode- ao utilizado para os demais nodos -addNode-).
7. Nas lias 1522-1528 insrese, para cada receptividade do modelo, o cdigo para crear unha
instancia da clase RTReceptivitylnfo (Figura 6.8) utilizando a informacin recopilada polo
compilador: identificador numrico da receptividade, nome da funcin que contn o cdigo
da receptividade e indicador booleano de se a receptividade est asociada a unha transicin
fonte; para engadirlle a informacin das varibeis utilizadas no cdigo da receptividade
(unha lia de cdigo por cada unha); e para inserir a informacin no modelo (insrese a
instancia da clase RTReceptivitylnfo e a informacin que permite obter un apuntador
funcin que contn o cdigo da receptividade dado o seu nome).
8. Nas lias 1531-1541 insrese, para cada asociacin de accin do modelo, o cdigo para
crear unha instancia da clase RTActionlnfo (Figura 6.8) utilizando a informacin recopilada
polo compilador: identificador numrico da asociacin, identificador numrico da etapa
que est asociada, nome da varibel booleana modificada pola asociacin, cualificador da
asociacin, nome da varibel utilizada como indicador, valores de retardo e lmite en
asociacins temporizadas, nome da funcin que contn o cdigo da condicin da
asociacin, indicador de se a asociacin pode ser aplicada en situacins inestbeis e valor
do tipo interno de asociacin asignado polo compilador; para engadirlle a informacin das
varibeis utilizadas no cdigo da condicin da asociacin (unha lia de cdigo por cada
unha); e para inserir a informacin no modelo (insrese a instancia da clase RTActionlnfo e
a informacin que permite obter un apuntador funcin que contn o cdigo da condicin
da asociacin dado o seu nome).
9. Nas lias 1544-1549 insrese, para cada accin do modelo, o cdigo para crear unha
varibel booleana co nome da accin que almacenar o seu valor de activacin e para
inserir a informacin no modelo (insrese a declaracin da varibel e a informacin que
permite obter un apuntador funcin que contn o cdigo da accin dado o seu nome).
10. Nas lias 1552-1557 insrese, para cada orde de forzado do modelo, o cdigo para crear
unha instancia da clase RTFOlnfo (Figura 6.8) utilizando a informacin recopilada polo
compilador: identificador numrico do grafcet parcial que contn a etapa que est
asociada a orde de forzado, identificador numrico desta etapa, identificador numrico do
grafcet parcial forzado e identificadores numricos das etapas forzadas (unha lia de
cdigo por cada etapa forzada); e para inserir a informacin no modelo.
11. Nas lias 1560-1565 insrese o cdigo para iniciar o nmero de niveis da xerarqua de
forzado do modelo. Ademais, para cada nivel, insrese o cdigo para engadir o
identificador numrico das etapas pertencentes ao nivel que teen ordes de forzado
asociadas (unha lia de cdigo por cada etapa) e para inserir a informacin no modelo.
12. Nas lias 1568-1578 insrese, para cada temporizador do modelo, o cdigo para crear unha
varibel booleana de nome sfcpp_timer_nnn (nnn = identificador numrico do
temporizador) que almacenar o seu valor, para crear unha instancia da clase RTTimerlnfo
(Figura 6.8) utilizando a informacin recopilada polo compilador: identificador numrico
do temporizador, nome da funcin que contn o cdigo da condicin do temporizador,
valores de retardo e lmite; para engadirlle a informacin das varibeis utilizadas no cdigo
266
da condicin do temporizador (unha lia de cdigo por cada unha) e para inserir a
informacin no modelo (insrese a instancia da clase RTTimerlnfo, a declaracin da
varibel e a informacin que permite obter un apuntador funcin que contn o cdigo da
condicin do temporizador dado o seu nome).
13. Na lia 1581 insrese a informacin do modelo na cola de mdulos.
No caso de que algunha das operacins anteriores provoque un erro durante a execucin,
lanzase unha excepcin que capturada nas lias 1583-1587, onde se libera a memoria
utilizada ate o momento e sese da funcin onLoad devolvendo un valor de erro (true).
6.5.1.10. Compilacin da DLL ("SFCCPPCompiler")
Nesta fase realzase a compilacin e enlazado do cdigo fonte da DLL xerado nas fases
previas. Esta fase unha clase "wrapper" que capsula o acceso a un compilador externo
utilizando a tcnica explicada en (6.1.3). Esta clase presupn a existencia dun arquivo
denominado compile.bat que estar almacenado no subdirectorio do directorio compilers
indicado nas opcins de configuracin (6.1.1).
6.6. Conclusins
Neste captulo tratronse os aspectos relacionados coa compilacin dos modelos Grafcet
para obter unha DLL que permita cargalos dinamicamente e executalos na mquina virtual que
implementa o intrprete de modelos Grafcet. Describiuse o formato utilizado para representar
os modelos de forma optimizada para a sa execucin. Analizronse os aspectos a considerar
cando se utiliza unha linguaxe de alto nivel como o C++, estendida cos operadores Grafcet de
evento e temporizacin, na especificacin das accins e receptividades do modelo. Fxose
fincap nas modificacins realizadas na gramtica da linguaxe para inclur os novos operadores
e nas substitucins que preciso realizar no cdigo de accins e receptividades para poder
compilalas cun compilador C++ externo.
No referente implementacin do compilador Grafcet, describiuse a sa arquitectura lxica,
composta' por unha estructura de fases que acceden durante a compilacin informacin
interna almacenada nun nico punto accesbel a todas as fases. Esta arquitectura permite a
modificacin da estructura de fases ou a reimplementacin dunha fase concreta sen que iso
afecte ao resto nin a estructura do compilador. Nesta primeira versin do compilador a
implementacin das fases presupn que a linguaxe de programacin utilizada o C++, sen
embargo partindo da estructura deseada, fcil en futuras versins engadir novas
implementacins das fases que permitan utilizar linguaxes de alto nivel diferentes. Tamn se
describiu a tcnica que permite utilizar aplicacins externas, como un compilador C++ por
exemplo, sen que sexa necesario modificar o compilador Grafcet se se cambia de aplicacin.
En canto s melloras a realizar, resmense aqu algunhas das xa comentadas nos contidos do
captulo:
1. Eliminar a restriccin de que as expresins con eventos complexas tean que ir entre
parnteses (6.3.1.1).
2. Reducir as restriccins impostas nas expresins que poden utilizarse cos operadores de
evento e temporizacin (6.3.1.2).
3. Permitir a utilizacin de temporizadores no cdigo das accins (6.5.1.5.2).
4. Optimizar a substitucin das subexpresins numricas ao simplificar expresins con
eventos complexas (6.3.3.1). Na implementacin actual non se trata o caso no que como
267

resultado da simplificacin se obtn unha expresin na que non se utiliza a varibel auxiliar
que substite subexpresin numrica. Tampouco se ten en conta se a subexpresin
constante cando se obtn na expresin simplificada un evento que afecte varibel auxiliar.
5. Eliminar a restriccin de que o valor das sadas do proceso unicamente poda ser
modificado mediante o operador de asignacin simple (6.3.3.3).
>
Outras optimizacins, que reduciran o tempo necesario para compilar un modelo, son as
seguintes:
1. Substitur a fase que chama aplicacin externa Sidoni por outra que implemente
directamente a simplificacin de expresins booleanas. Isto eliminara o tempo necesario
para executar a aplicacin externa cada vez que hai que simplificar unha expresin.
2. Desear unha tcnica que permita preprocesar todo o cdigo do modelo nunha nica
chamada ao preprocesador. Na implementacin actual o preprocesador executado unha
vez por cada accin, condicin de transicin, condicin de asociacin e condicin de
temporizacin do modelo, co consumo de tempo que isto implica.
Captulo 7 . A mquina virtual
A mquina virtual un ambiente "software" que proporciona soporte execucin de

aplicacins que interaccionen cun proceso fisico mediante o intercambio de eventos discretos a
travs dun ou mis dispositivos de E/S. Dende o punto de vista do usuario, a mquina virtual
proporciona un conxunto de servicios aos que se accede a travs dun enlace de comunicacins
que permiten o control remoto do seu funcionamento e a modificacin da sa configuracin.
Dende o punto de vista das aplicacins, a mquina virtual proporciona unha interface comn de
acceso s funcionalidades do sistema no que se executan as aplicacins, como por exemplo: a
notificacin de eventos, a xestin das temporizacins ou o acceso aos valores das varibeis do
proceso.
Anda que inicialmente foi deseada co obxectivo de proporcionar soporte a un intrprete no
que executar os modelos Grafcet, pode ser utilizada igualmente para a implementacin de
intrpretes doutros formalismos para a especificacin de DEDS, como: RdPI, StateCharts, etc.
ou doutras aplicacins que interaccionen cun proceso fisico como, por exemplo, un emulador
PLC. Como parte do desenvolvemento da arquitectura da mquina virtual implementouse unha
librara que incle diferentes tcnicas para facilitar a creacin de aplicacins concorrentes,
portbeis e reconfigurbeis dinamicamente.
O resto deste captulo est organizado da forma seguinte: no apartado (7.1) descrbense a
arquitectura da mquina virtual e os mecanismos utilizados para dar soporte sa estructura
flexbel e concorrente; en (7.2) explcase o subsistema que xestiona a interaccin cos
dispositivos fisicos e penmite simular as magnitudes dun proceso; no apartado (7.3) descrbese
o ncleo da mquina virtual no que se almacenan os valores do proceso e xestinanse
temporizadores e eventos; os servicios proporcionados pola mquina virtual aos clientes
remotos para a xestin da sa configuracin e o control do seu funcionamento son explicados
no apartado (7.4); no apartado (7.5) detllase a interaccin entre as aplicacins executadas
pola mquina virtual e o ncleo desta; e finalmente, no apartado (7.6) recllense as
conclusins do captulo.
7.1. A arquitectura da mquina virtual

O deseo da arquitectura da mquina virtual ten como obxectivo proporcionar os servicios
precisos para a execucin de aplicacins baseadas no intercambio de eventos discretos cun
proceso fisico. Os requisitos considerados no deseo foron os seguintes:
1. A arquitectura deba ser flexbel, de xeito que fose posbel utilizar diferentes dispositivos
de E/S, configurar a interaccin entre a mquina virtual e o proceso, e executar distintos
tipos de aplicacins.
269
270
Captulo 7: A mquina virtual
2. A implementacin deba ser facilmente portbel, reducindo no posbel as dependencias de

aspectos especficos dos sistemas utilizados, facilitando as a aplicacin da mquina virtual
en ambientes de control heteroxneos.
Para cumprir estes requisitos utilizronse das solucins complementarias:
1. A arquitectura est baseada na utilizacin de mdulos (7.1.1). Os mdulos son elementos
"software" que poden ser cargados e descargados dinamicamente na memoria, substitudos
en tempo de execucin, utilizados como base para formar estructuras complexas mediante
agregacin e composicin, etc.
2. Definiuse unha capa software (Figura 7.1) que proporciona unha interface abstracta das
funcionalidades proporcionadas polo sistema operativo, dispositivos fisicos e redes de
comunicacin nos que se execute a mquina virtual. A implementacin desta capa basease
na utilizacin de patrns de deseo [67] e na definicin de interfaces mediante clases
abstractas e mtodos virluais, de xeito que a portabilidade da mquina virtual consguese
implementando as interfaces definidas nos diferentes sistemas a utilizar. As
funcionalidades proporcionadas pola capa de abstraccin do sistema comprenden: procesos
e mecanismos de comunicacin entre procesos (7.1.2); "drivers" de E/S (7.2.1);
temporizadores (7.3.2); e interfaces de comunicacin (7.4.3).
Aplicacins de usuario
Mquina virtual
Capa de Abstraccin do Sistema
Sistema Operativo
Dispositivos: E/S, comunicacins,etc^. Hardware
Figura 7.1. Estructura de capas da mquina viriual.
O resto deste apartado estructrase do xeito seguinte: os detalles dos dous mecanismos
bsicos (mdulos e procesos) utilizados no deseo e implementacin da mquina virtual
explcanse en (7.1.1) e(7.1.2), respectivamente; a arquitectura da mquina virtual descrbese
en (7.1.3); e a sa implementacin en (7.1.4).
7.1.1. Estructuracin da arquitectura: os mdulos

O elemento bsico da arquitectura da mquina virtual o mdulo. Os mdulos son
elementos "soflware" que poden ser creados ou cargados dinamicamente na memoria dende
DLLs en tempo de execucin. O seu uso facilita a implementacin de estructuras complexas e
de comportamentos flexbeis mediante a agregacin e a substitucin dinmica de mdulos sen
que sexa preciso deter a execucin da aplicacin. A Figura 7.2 mostra o diagrama das
interfaces e clases utilizadas para declarar e implementar as funcionalidades dispobeis na
creacin e xestin de arquitecturas soflware baseadas en mdulos. No resto deste apartado
descrbense estas clases e as funcionalidades que proporcionan e danse exemplos da sa
utilizacin.
7.1.1.1. Mdulos simples: a interface IModule
A clase abstracta IModule declara a interface bsica dun mdulo. Esta interface est formada
unicamente por dous mtodos que proporcionan acceso aos identificadores alfanumricos do
271
Seccin 7.1: A arquitectura da mquina virtual
mdulo, un que indica o seu tipo e outro que identifica univocamente ao mdulo entre os do
seu mesmo tipo. O cdigo da declaracin o seguinte:
1630.// Interface dun mdulo
1631.struct IModule : public ptrSeqElem
1632 . {
1633. virtual string getKey() const = 0;
1634. virtual string getType() const = 0;
1635. };
1636.
1637.// Declaracias auxiliarea
1638.typedef IModule module;
1639.typedef IModule* moduleôinter;
1640.typedef id2ptrSeq<module> module_map;
1641.typedef id2ptrSeq<module>::iterator module_iterator;
Ntese que os mdulos son derivados da clase ptrSeqElem, de xeito que poidan ser
almacenados en memoria utilizando a coleccin id2ptrSeq ( B.1).
7.1.1.2. Mdulos complexos: a interface IStructuredModule
A clase abstracta IStructuredModule declara a interface a implementar polos mdulos
complexos cuxa estructura se forma mediante a agregacin doutros mdulos que poden ser
substitudos dinamicamente durante a execucin da aplicacin. O cdigo da declaracin desta
interface o seguinte:
1642.struct IStructuredMOdule
1643 . {
1644.
// consulta i nformacia da estructura actual
1645.
1646.
1647.
1648.
1649.
1650.
1651.
1652.
1653.
1654.
1655
virtual void getStructureInfo(deque<vMModuleInfo>& structure) const

// almaca de mdulos
virtual IModuleStore* getModuleStore() const = 0;
virtual void setModuleStore(IModuleStore* store) = 0;
// almacn de configuracins
virtual IConfigurationStore* getConfigurationStore() const = 0;
virtual void setConfigurationStore(IConfigurationStore* store) = 0;
// activar/desactivar configuracia
virtual bool activateCurrentConf() = 0;
virtual bool deactivateCurrentConf() = 0;
};
= 0;
A interface declara mtodos para consultar a estructura actual do mdulo, asignar e obter
apuntadores tanto ao almacn de mdulos (7.1.1.3) como ao de configuracins (7.1.1.4)
utilizados polo mdulo, e activar e desactivar a configuracin actual do mdulo. A clase
StructuredModule (Figura 7.2) proporciona a implementacin por defecto dos mtodos
getModuleStore (lia 1647), setModuleStore (lia 1648), getConfigurationStore (lia 1650), e
setConfigurationStore (lia 1651). Os outros mtodos sern redefinidos nas clases derivadas
desta interface.
A informacin dos tipos e nomes dos mdulos que forman a estructura dun mdulo
complexo denomnase configuracin. Cada mdulo omplexo pode adoptar diferentes
configuracins, anda que en cada instante s unha estea activa. As configuracins son
representadas mediante a clase ModuleConfiguration (Figura 7.2) e conteen a informacin
necesaria para que os mdulos complexos podan organizar dinamicamente a sa estructura
interna. Cada configuracin contn, por cada tipo de mdulo utilizado, unha instancia da clase
Configurationltem na que se almacena o nome do tipo de mdulo, a cantidade de mdulos dese
272
tipo utilizados9 e, no caso de especificarse unha cantidade fixa, os nomes dos mdulos
utilizados. Os detalles dos cambios de configuracin son implementados nos mtodos
activateCurrentConf (lia 1653) e deactivateCurrentConf (lia 1654) nas clases derivadas.
ptrSeqElem
(from euic El^m^nt^
I
ModuleCategory
name : string
modules
IModule
IStmcturedModule
StructuredModule
config sto
IConfigurationStore
module store
t
IModuleStore
1
Confi urationStore configurations
current_conf : string
ModuleConfiguration
, conf name : string
categories
ModuleRepository I
repasitory
MaduleStore
IStruct uredStoreModule
Configurationltem
id : siring
size : int
mod names : deque<string>
Figura 7.2. Diagrama das clases que definen os mdulos e as sas funcionalidades.
A consulta sobre a estructura actual dun mdulo complexo realzase mediante o mtodo
getStructurelnfo (lia 1645). A implementacin deste mtodo recursiva e devolve para cada
mdulo complexo agregado un rexistro contendo o nome e tipo do mdulo, o nome do almacn
de mdulos que utiliza (7.1.1.3) e os nomes dos mdulos agregados que compoen a sa
estructura. O cdigo seguinte mostra a declaracin destes rexistros:
1656.struct VMModuleInfo
1657 . {
1658.
string name;
1659.
string type;
1660.
string store;
1661. deque<string> parts;

1662 . } ;
//
//
//
//
nome do mdulo complexo
tipo
nome do almacn de mduloa que utiliza
mdulos agregados que forman a sa estructura
7.1.1.3. Almacns de mdulos: a interface IModuleStore

A clase abstracta IModuleStore declara a interface para a xestin do almacenamento de
mltiples mdulos en memoria organizados formando categoras en funcin do seu tipo. O
cdigo da sa declaracin o seguinte:
1663.// Interface dua almaca de mdulos
1664.struct IModuleStore
1665. {
1666.
// categoras
1667.
virtual void initCategories() = 0;
1668.
virtual bool isCategory(const string& name) const = 0;
69 Na implementacin actual aceptanse duas posibilidades, ou unha cantidade fixa ou unha cantidade non
especificada (o..N mdulos).
273
1669.
1670.
1671.
1672.
1673.
1674.
1675.
1676.
1677.
1678.
1679.
1680.
1681.
1682.
1683 . } ;

virtual void getCategoryNames(deque<string>& names) const = 0;
virtual voi.d addCategory(const string& name) = 0;
virtual void removeCategory(const string& name) = 0;
virtual void clearCategory(const string& name) = 0;
// mduloa
virtual bool isModule(const string& type,
const string& name) const = 0;

K
virtual bool getModuleNames(const string& type,
deque<string>& names) const = 0;
virtual moduleôinter getModule(const string& type,
const string& name) = 0;
virtual module_iterator addModule(moduleôinter module) = 0;
virtual bool removeModule(const string& type, const string& name) = 0;
virtual void clearAllModules() = 0;
Como pode verse a interface declara mtodos para crear, consultar e eliminar categoras
(lias 1667-1672) e para engadir, eliminar e recuperar os mdulos almacenados nas categoras
existentes (lias 1674-1682). A clase ModuleStore (Figura 7.2) proporciona a implementacin
por defecto desta interface utilizando un almacn de mdulos, representado pola clase
ModuleRepository, que pode conter varias categoras, representadas mediante a clase
ModuleCategory. Cada categora almacena un conxunto de mdulos do mesmo tipo. O nome
da categoria coincidir co do tipo de mdulos que almacene.
7.1.1.4. Almacns de configuracins: a interface IConggurafionSfore
A clase abstracta IConfigurationStore declara a interface para a xestin do almacenamento
de mltiples configuracins en memoria. O cdigo da sa declaracin o seguinte:
1684.struct IConfigurationStore
1685. {
1686.
// iniciacin das configuracina
1687.
virtual void initConfigurations() = 0;
virtual bool setDefaultConf() = 0;
1688.
1689.
// eagadir, eliminar e modificar coafiguracina
virtual bool addConfiguration(const ModuleConfiguration& c) = 0;
1690.
virtual bool removeConfiguration(const string& id) = 0;
1691.
virtual bool updateConfiguration(const string& id,
1692.
const ModuleConfiguration& c) = 0;
1693.
1694.
// coasulta de configuracias
1695.
virtual bool isValidConfiguration(const ModuleConfiguration& c) const = 0;
virtual const ModuleConfiguration&
1696.
getConfiguration(const string& name) const = 0;
1697.
1698.
virtual void getConfigurationNames(deque<string>& names) const = 0;
// configuracin actual
1699.
virtual const string& getCurrentConf() const = 0;
1700.
virtual bool setCurrentConf(const string& id ="NONE") = 0;
1701.
1702 . } ;
Como pode verse esta interface proporciona mtodos para a iniciacin (lias 1687-1688),
consulta (lias 1695-1698), insercin (lia 1690) e eliminacin (lia 1691) de configuracins,
as como para consultar (lia 1700) e seleccionar (lia 1701) a configuracin actual. A clase
ConfigurationStore (Figura 7.2) proporciona a implementacin por defecto da maiora dos
mtodos desta interface -^xcepto initConfigurations (lia 1687), isValidConfiguration (lia
1695) e setDefaultConf (lia 1688^.
Ademais das interfaces e clases xa comentados tamn se definiu a interface
IStructuredStoreModule (Figura 7.2), derivada simultaneamente das catro interfaces explicadas
anteriormente: IModule, IStructuredModule, IModuleStore e IConfigurationStore, para ser
274
utilizada como base dos mdulos complexos que sexan utilizados simultaneamente como
^
almacns de mdulos e configuracins.
7.1.1.5. Carga e descarga dinmica de mdulos
Unha funcionalidade adicional proporcionada polos mdulos a posibilidade de cargalos e
descargalos dinamicamente en memoria mediante a utilizacin de DLLs, o que proporciona un
mecanismo simple para a extensin e modificacin das caractersticas dunha aplicacin en
tempo de execucin. Este mecanismo utilizado con frecuencia na implementacin da mquina
virtual, como por exemplo para o manexo dos "drivers" de E/S, dos modelos Grafcet ou das
polticas de evolucin. O cdigo seguinte mostra a interface pblica dunha DLL que
proporcione soporte carga e descarga dinmica de mdulos:
1703.#define DLL_API _declspec(dllexport)
1704.extern "C"
1705. {
1706.
1707.
1708.
1709. }
DLL_API bool onLoad(void); .
DLL_API void onUnload(void);
DLL_API deque<moduleôinter>& getModules(void);
^
Esta interface est formada por tres funcins:
1. onLoad (lia 1706), funcin executada no momento de cargar a DLL en memoria na que se
inician os mdulos que sern posteriormente cargados na aplicacin.
2. onUnload (lia 1707), funcin executada no momento de descargar a DLL. Nela
implemntanse as operacins necesarias para liberar a memoria e recursos utilizados polos
mdulos.
3. getModules (lia 1708), funcin que permite acceder aos mdulos contidos na DLL.
O seguinte cdigo mostra unha implementacin tpica destas funcins:
1710.// coleccin de mdulos
1711.deque<moduleôinter> modules;
1712.
1713.DLL_API bool onLoad(void)
1714 . {
Module* module_1 = NULL;
1715.
Module* module_2 = NULL;
1716.
1717.
try
1718. {
1719.
// crear mdulos
1720.
1721.
1722.
1723.
Module* module_1 = new Module("MODULE_1", "TYPE");
if (!module_1) throw;
Module* module_2 = new Module("MODULE_2", "TYPE");
if (!module_2) throw;
1724.
// almacenar os mduloa na coleccia
modules.push_back(module_1);
1725.
modules.push_back(module_2);
1726.
1727. }
1728. catch(...)
1729.
1730.
// eliminar mdulos en caso de erro
if (module_1) delete module_1;
1731.
if (module_2) delete module_2;
1732.
return false;
1733.
1734. }
1735. return true;
1736. }
275
1737.DLL_API void onUnload(void)
1738. {
1739.
for (deque<moduleôinter>::iterator module = modules.begin();
1740.
module != modules.end();
^
++module)
delete *module;
modules.clear();
1741.
1742.
1743.
1744 . }
1745.
1746.DLL_API deque<moduleôinter>& getModules(void)
1747. {
1748.
return modules;
1749. }
A varibel global modules (lia 1711) unha cola na que se almacenarn os mdulos
contidos na DLL. Na implementacin da funcin onLoad (lias 1713-1736) cranse os
mdulos e almacnanse na cola modules (lias 1719-1726). En caso de detectarse algn erro
lnzase unha excepcin que procesada nas lias 1730-1733, eliminando a memoria ocupada
polos mdulos. Na funcin onUnload (lias 1737-1744), executada cando a DLL descargada
da memoria, elimnanse todos os mdulos almacenados en modules. Por ltimo, a funcin
getModules (lia 1746) devolve unha referencia coleccin de mdulos da DLL.
O acceso DLL dende unha aplicacin faise mediante unha instancia da clase DLLlnfo. Esta
clase oculta os detalles da carga e descarga de DLLs, ofrecendo unha interface independente do
sistema operativo utilizado. A sa declaracin a seguinte:
1750.class DLLInfo
1751 . {
1752.public:
// carga/descarga da DLL
1753.
1754.
1755.
DLLInfo(const string& _name,
const string& âth);
1756.
1757.
1758,
1759.
// mtodos pblicos da DLL

bool load();
bool unload();
bool getModules(module_map& _modules);
-DLLInfo();
1760. };
O constructor (lia 1754) e o destructor (lia 1755) da clase son os que implementan
respectivamente a carga e descarga en memoria da DLL. O resto dos mtodos permiten o
acceso s funcins da interface pblica da DLL explicadas anteriormente.
7.1.1.6. Exemplo da utilizacin de mdulos
Neste apartado descrbese un exemplo de como son utilizadas as funcionalidades
proporcionadas polos mdulos para implementar unha aplicacin coa arquitectura flexbel da
Figura 7.3.a. A arquitectura da aplicacin est formada por dous mdulos, un simple, que sirve
de almacn dos mdulos creados dinamicamente en memoria, e outro complexo cunha
estructura formada pola agregacin de dous mdulos, un complexo de tipo A e outro simple de
tipo B. O mdulo complexo de tipo A ten sa vez unha estructura formada pola agregacin
dun mdulo simple de tipo C. A Figura 7.3.b mostra as configuracins vlidas que son
aceptadas na arquitectura indicada, e o diagrama de obxectos da Figura 7.3.c a sa
implementacin utilizando as clases explicadas anteriormente. Ntese que o mdulo store
utilizado como almacn das configuracins vlidas do mdulo main e este, sa vez, como
almacn das configuracins vlidas dos mdulos tipo A. Os diagramas de obxectos das
configuracins vlidas da arquitectura son mostrados na Figura 7.3.d.
276
MAIN
TYPE A
TYPE_B
STORE
ttPE C
(e)
MAIN
A
MAIN
C1
B,
MAIN
81
MAIN
A
C2
B2
C2
(b)
CoMaurationltem
:COnficurationltem
name ='TYPE_C'
aize = 1
name='TYPE_C'
aiZe = 1
mod_namea = {'MODULE_C1y
mod_names = ('MODULE_C2^
Itema
kema
^ModuleConfiauration
neme ='CONF B'
name ='CONF A'

;Module
Module
name ='MODULE 82'

rype ='ttPE_B' -
name='MODULE_C2'
rype ='TYPE_C'
:MOdule
:Module
ComdexModule
name ='MODULE C1'

rype ='TYPE_C' -
name ='MODULE_A'
lyPe ='TYPE_A'
configurations
:MainModule
configuration_atore
name ='MODULE B
rype ='TYPE_B' modules
modules
ModuleCateaorv
:ModuleCeteaorv
modulea
:ModulaCateaorv
name ='TYPE_B'
name='ttPE C'
name ='TYPEf'
configuration_atore name ='MAIN'
type ='MAIN'
modute atore
module atore
atore:Store
eonfiguratione
categoriea
^
ModuleConfiauretion
na e ='CONF B'
name='CONF A'
kema
Itema
^Canfiourationltem
nama ='TYPE_A'
size = 1
mod_names = {MODULE_Ay
;onfiaurauonltem
:Confiaurafionltem
name ='TYPE_A'
size = 1
mod_namea = {MODULE_A}
Confiaurationltem
name ='TYPE_B'
aize = 1
name ='TYPE_B
ai28 = 7
mod_names = {'MODULE_Bt^
mod namea={MODULE_82
(c)
MainModu
^MainModule
module a
name ='MAIN'
bPe 'MAiN'
module_a
module_b
:ComdexModule
:MOdule
name='MODULE A'
rype ='TYPE_A' -
name ='MODULE 81'

type ='TYPE B' -
name ='MAIN'
type ='MAIN'
ComdexModule
name ='MODULE 82'

Hpe ='ttPE_B'
module_c
Mcdulfl
;Module
neme ='MODULE_C1'
rype ='TYPE_C'
name='MODULE C1
rype ='TYPE_C'
:MainModule
module a
:Module
name='MODULE A
lype ='TYPE_A' -
module e
module_b
name ='MAIN'
type ='MAIN'
:MainModule
module b
:ComdexModule
:Module
name ='MODULE A'

rype ='ttPE_A' -
name ='MODULE 81'

NPe ='ttPE_B' -
modde e
name ='MAIN'
bPe''MAiN'
:ComdexModule
name='MODULE A'
rype ='TYPE_A' -
module_c
module b
:MOdule
name='MODULE 82'
hpe ='TYPE_B
module_c
Module
:Module
name ='MODULE C2'

rype ='ttPE_C' -
name='MODULE C2'
rype ='TYPE_C'
(d)
Figura 7.3. Exemplo de utilizacin dos mdulos: a) arquitectura flexbel da aplicacin; b) configuracins vlidas;
c) diagrama de obxectos da implementacin; e d) diagramas de obxectos das configuracins vlidas.
277
O cdigo que implementa a arquitectura do exemplo o seguinte:

1761.// Mdulo aimple
1762.class Module : public IModule
1763 . {
1764.
string name;
1765. string type;

1766.public:
1767.
Module(const string& n, const string& t):name(n), type(t){}
1768.
string getKey() const { return name; }
1769.
string getType() const { return type; }
1770. } ;
1771.
1772.// Mdulo complexo ( tipo A)
1773.class ComplexModule : public StructuredModule, public Module
1774 . {
1775.
// mdulos agregados
1776.
IModule* module_C;
1777.public:
1778 . Cortq^lexn'todule (const string& n, IModuleStore* mstore, IConfiguratioalStore* cstore) ;

1779. void getStructurelnfo(deque<VMModuleInfo>& s) const;
1780. bool activateCurrentConf();
1781. bool deactivateCurrentConf();
1782 . } ;
1783.
1784. Comple^d^lodule::Cottq^lexModule(const string& n, IModuleStore* mstore,
IConfigurationStore* cstore)
1785.
1786.
1787.
StructuredModule(mstore, cstore), Module(n, "TYPE_A") {}
1788.void ComplexModule::getStructureInfo(deque<VMModuleInfo>& s) const
1789. {
1790. VMModuleInfo info;
1791. info.name = getKey();
1792. info.type = getType();
1793.
1794.
IModule* pStore = dynamic_cast<IModule*>(getModuleStore());
info.store = (pStore) ? pStore->getKey() : "NONE";
1795. if (module_C) info.parts.push_back(module_C->getKey());
1796. s.push_back(info);
1797. }
1798.
1799.boo1 ComplexModule::activateCurrentConf()
1800. {
1801. // obter o almacn de mdulos
1802.
1803.
IModuleStore* mstore = getModuleStore();
if (mstore == NULL) return false;
1804.
1805.
1806.
// obter o almacn de configuracins
IConfigurationStore* cstore = getConfigurationStore();
if (cstore == NULL) return false;
1807.
// obter a configuracin actual
1808.
string conf_name = cstore->getCi^rrentConf();
const ModuleConfiguration& conf = cstore->getConfiguration(conf_name);
1809.
1810.
// obter un mdulo tipo C
conf.getModuleNames("TYPE_C", names);
1811.
module_C = mstore->getMOdule("TYPE_C", names[O]);
1812.
1813 . }
1814.
1815.boo1 ComplexModule::deactivateCurrentConf()
1816. {
1817.
module_C = NULL;
1818. }

1819.// Almacn de mdulos
1820.class Store : public ModuleStore, public ConfigurationStore
1821 . {
1822.public:
1823. Store();
1B24. void initCategories();
1825. void initConfigurations();
1826. bool isValidConfiguration(const ModuleConfiguration& conf) const;
1827. bool setDefaultConf();
1828. };
1829.
1830.Store::Store()
1831 . (
1832.
initCategories();
1833.
initConfigurations();
1834.
setDefaultConf();
1835. }
1836.
1837.void Store::initCategories()
1838. {
1839.
addCategory("TYPE_A");
1840.
addCategory("TYPE_B");
1841.
addCategory("TYPE_C");
1842 . }
1843.
1844.void Store::initConfigurations()
1845. {
1846.
// configuracin A
1847.
1848.
1849.
1850.
1851.
1852.
ModuleConfiguration conf_A("CONF_A");
conf.addItem("TYPE_A", 1);
conf.addItem("TYPE_B", 1);
COrif["TYPE_A"].addMOdule("MODULE_A");
COnf["TYPE_B"].addMOdule("MODULE_B1");
addConfiguration(conf_A);
1853.
// configuraciba B
ModuleConfiguration conf_B("CONF_B");
1854.
conf.addItem("TYPE_A", 1);
1855.
conf.addItem("TYPE_B", 1);
1856.
conf["TYPE_A"].addModule("MODULE_A");
1857.
COnf("TYPE_B"].addMOdule("MODULE_B2");
1858.
addConfiguration(conf_B);
1859.
1860. }
1861.
1862.boo1 Store::isValidConfiguration(const ModuleConfiguration& conf) const
1863 . {
1864.
1865.
1866.
1867.
1868.
// comprobar que todos os elemeatos da configuracin son vlidos

deque<string> items;
conf.getItemNames(items);
for (deque<string>::const_iterator item = items.begin();
item != items.end(); ++item)
if (*item !_ "TYPE_A" && *item !_ "TYPE_B") return false;

1869.
return true;
1870.
1871 . }
1872.
1873.boo1 Store::setDefaultConf()
1874. {
1875. setCurrentConf("CONF_A");
1876. }
278
279
1877.// Mdulo principal
1878. class Mainl^lodule : public StructuredNbdule, public ConfigurationStore, public Module
1879. {
1880. // mdulos agregadoa
1881. IModule* module_A;
1882. IModule* module_B;
1883.public:
MainModule(const string& n, IModuleStore* mstore, IConfigurationStore* cstore);
1884.
1885. void getStructureInfo(deque<VMModulelnfo>& s) const;
1886. bool activateCurrentConf();
1887. bool deactivateCurrentConf();
1888. void initConfigurations();
1889. bool isValidConfiguration(const ModuleConfiguration& conf) const;
1890. bool setDefaultConf();
1891 . } ;
1892.
1893.MainModule::MainModule(const string& n, IModuleStore* mstore,
IConfigurationStore* cstore)
1894.
1895.
: StructuredModule(mstore, cstore), Module(n, "MAIN")
1896. {
1897. initConfigurations();
1898. setDefaultConf();
1899. }
1900.
1901.void MainModule::getStructurelnfo(deque<VMModuleInfo>& s) const
1902 . {
1903. VMModuleInfo info;
1904. info.name = getKey();
1905. info.type = getType();
1906. IModule* pStore = dynamic_cast<IModule*>(getModuleStore());
1907. info.store = ( pStore) ? pStore->getKey() : "NONE";
1908. if (module_A) info.parts.push_back(module_A->getKey());
1909. if (module_B) info.parts.push_back(module_B->getKey());
1910. s.push_back(info);
1911. // obter informacin dos mbdulos complexos agregadoa
1912.
if (module_A) module_A->getStructureInfo(s);
1913 . }
1914.
1915.boo1 MainModule::activateCurrentConf()
1916 . {
// obter almacn de mduloa
1917.
IModuleStore* mstore = getModuleStore();
1918.
if (mstore == NULL) return false;
1919.
1920.
// obter almaca de configuracins
1921.
1922.
IConfigurationStore* cstore = getConfigurationStore();
1923.
1924.
1925.
1926.
1927.
1928.
// obter configuracin actual
string conf_name = cstore->getCurrentConf();
const ModuleConfiguration& conf = cstore->getConfiguration(conf_name);
/ / obter mdulo tipo A
deque<string> names;
conf.getModuleNames("TYPE_A", names);
1929.
1930.
1931.
1932.
1933.
1934.
module A= mstore->getModule("TYPE_A", names[O]);
// activar configuracin do mdulo A
if (cstore == NULL) return false;
module_A->setMOduleStore(mstore);
module_A->setConfigurationStore(this);
module_A->activateCurrentConf();
// obter mdulo tipo B
conf.getModuleNames("TYPE_B", names);
1935.
module_B = mstore->getModule("TYPE_B",
1936.
1937 . }
names[OJ);
280
1938.boo1 MainModule::deactivateCurrentConf()
1939. {
1940.
module_A = NULL;
1941.
module_B = NULL;
1942. }
1943.
1944.void MainModule::initConfigurations()
1945. {
// configuracin A
1946.
1947.
ModuleConfiguration conf_A("CONF_A");
1948.
conf.addItem("TYPE_C", 1);
1949.
1950.
'
conf["TYPE_C"].addModule("MODULE_C1");
addConfiguration(conf_A);
1951.
/ / configuracin B
1952.
1953.
ModuleConfiguration conf_B("CONF_B");
conf.addItem("TYPE_C", 1);
1954.
conf["TYPE_C"].addModule("MODULE_C2");
1955.
addConfiguration(conf_B);
1956 . }
1957.
1958. bool MainModule::isValidConfiguration(const ModuleConfiguration& conf) const
1959. {
1960.
1961.
// comprobar que todos os mdulos da configuracin son vlidos
deque<string> items;
1962.
1963.
1964.
conf.getItemNames(items);
for (deque<string>::const_iterator item = items.begin();
item != items.end(); ++item)
1965.
1966.
if (*item !_ "TYPE_C") return false;
return true;
1967. }
1968.
1969.boo1 MainModule::setDefaultConf()
1970. {
setCurrentConf("CONF_A");
1971.
1972 . }
1973.
1974.// Construccin da arquitectura
1975 . int main ( )
1976 . {
1977. // creacin dos mdulos dinmicos
1978.
1979.
1980.
1981.
1982.
1983.
1984.
1985.
1986.
1987.
1988.
1989.
1990.
1991.
1992.
1993.
1994 . }
IModule* module_A = dynamic_cast<IModule*>(new ComplexModule("MODULE_A", "TYPE_A"));
IModule* module_B1 = dynamic_cast<IModule*>(new Module("MODULE_B1", "TYPE_B"));
IModule* module_B2 = dynamic_cast<IModule*>(new Module("MODULE_B2", "TYPE_B"));
IModule* module_C1 = dynamic_cast<IModule*>(new Module("MODULE_C1", "TYPE_C"));
IModule* module_C2 = dynamic_cast<IModule*>(new Module("MODULE_C2", "TYPE_C"));
// almacenamento dos mdulos
Store store;
store.addModule(module_A);
store.addModule(module_B1);
store.addModule(module_B2);
store.addModule(module_C1);
store.addModule(module C2);
// creacin e activacin do mdulo principal
MainModule main module("MAIN", &store, &store);
main_module.activateCurrentConf(); // actvase CONF_A
return 0;
Os mdulos simples son implementados mediante instancias da clase Module (lias 1762
1770), derivada da interface IModule (7.1.1.1), que declara atributos para almacenar o nome e
tipo do mdulo e implementa os mtodos de acceso aos valores deses atributos. Os mdulos
complexos de tipo A son implementados mediante instancias da clase ComplexModule (lias
1773-1782), que declara un atributo (lia 1776) para referenciar ao mdulo simple de tipo C
que forma parte da sa arquitectura. A activacin da configuracin actual do mdulo complexo
281
implemntase no mtodo activateCurrentConf (lias 1799-1813), no que se obtn a

informacin da configuracin actual do almacn de configuracins (lia 1809) e utilzase para
obter do almacn de mdulos a referencia ao mdulo agregado (lia 1812). A implementacin
da clase ComplexModule compltase cos mtodos getStructurelnfo (lias 1788-1797), que
devolve unha representacin da estructura actual do mdulo, e deactivateCurrentConf (lias
1815-1818), que anula o apuntador ao valor do mdulo agregado.
Os mdulos son almacenados nunha instancia da clase Store (lias 1820-1828), derivada da
clase ModuleStore (7.1.1.3), organizados en tres categoras que son iniciadas na
implementacin do mtodo initCategories (lias 1837-1842). Ademais este mdulo tamn
almacena as configuracins vlidas para o mdulo main, que son iniciadas no mtodo
initConfigurations (lias 1844-1860). A clase implementa o mtodo isValidConfiguration
(lias 1862-1871), que neste exemplo comproba para unha configuracin dada se os mdulos
que a forman son dos tipos agardados.
O mdulo principal da arquitectura unha instancia da clase MainModule (lia 1878-1891),
que declara dous atributos para referenciar os mdulos agregados que forman a sa estructura.
Ademais este mdulo tamn serve como almacn das configuracins vlidas para os mdulos
complexos de tipo A. As configuracins vlidas son iniciadas na implementacin do mtodo
initConfigurations (lias 1944-1956) e a validez dunha configuracin comprobada polo mtodo
isValidConfiguration (lias 1958-1967). A activacin da configuracin actual implementada
no mtodo activateCurrentConf (lias 1915-1937), no que se obteen do mdulo store, que o
que fai as veces de almacn de mdulos e configuracins do mdulo principal, tanto a
informacin da configuracin actual (lia 1925) como as referencias aos mdulos agregados
(lias 1929 e 1936). Ntese que este mdulo o responsbel tamn de activar a configuracin
dos mdulos complexos que forman a sa estructura (lias 1931-1933). A implementacin da
clase MainModule compltase cos mtodos getStructurelnfo (lias 1901-1913), que devolve
unha representacin da estructura actual do mdulo, e deactivateCurrentConf (lias 1938
1942), que anula os valores dos apuntadores aos mdulos agregados. Ntese que o mtodo
getStructurelnfo aplcase recursivamente ao mdulo complexo agregado de tipo A(lia 1912).
7.1.2. Operativa da arquitectura: os procesos

Dende o punto de vista operativo, a arquitectura interna da mquina virtual est formada por
mltiples procesos concorrentes que se comunican tanto sncrona como asincronamente. Anda
que se lles denomine igual, non o mesmo un proceso da mquina virtual que un proceso do
sistema operativo sobre o que esta se execute. No deseo e implementacin da mquina virtual
tentouse que as dependencias dos aspectos especficos de cada sistema operativo fosen mnimas
para facilitar a portabilidade. O concepto de proceso utilizado na mquina virtual a
abstraccin lxica dunha secuencia de execucin e proporciona as funcins necesarias para
controlar o seu estado e a comunicacin coas demais secuencias da mquina virtual.
A implementacin dun proceso da mquina virtual pode realizarse de diferentes formas, por
exemplo asignndoo a un ou mis procesos, tarefas ou "threads" do sistema operativo. A
implementacin actual da mquina virtual presupn a existencia dun sistema operativo
"multithread", no que a mquina executada nun proceso do sistema operativo e cada proceso
da mquina virtual executado nun "thread" do sistema operativo. En consecuencia, a
comunicacin entre procesos da mquina virtual implementada utilizando os mecanismos de
comunicacin entre "threads" do sistema operativo. No resto deste apartado descrbense as
funcionalidades proporcionadas polos procesos da mquina viriual, explcase como foron
definidas e implementadas e mstranse exemplos da sa utilizacin.
282
7.1.2.1. As funcionalidades dun proceso

Os procesos da mquina virtual proporcionan catro funcionalidades bsicas:
1.
O control do estado de execucin do proceso.
2.
A exclusin mutua no acceso aos datos internos do proceso.
3.
A comunicacin asncrona entre procesos mediante paso de mensaxes.
4.
A notificacin da finalizacin de operacins asncronas.
A interface abstracta dun proceso incle as declaracins dos mtodos a redefnir nas clases
derivadas para implementar as tres primeiras funcionalidades, mentres que a transferencia do
fluxo de control cando se produce unha notificacin asncrona unha caracterstica
implementada internamente nas subclases.
O cdigo da interface abstracta dun proceso o seguinte:

1995.class IVMProcess
1996. {
1997.public:
1998. // control do estado do proceso
1999. virtual void Start() = 0;
2000.
virtual void
2001.
virtual void
2002.
virtual void
virtual bool
2003.
2004.
virtual bool
2005.protected:
2006.
/ / exclusin
2007.
virtual bool
Suspend() = 0;
Resume() = 0;
Finish() = 0;
isSuspended() = 0;
isRunning() = 0;
mutua no acceao aos datos iaternos
tryDataAccess() = 0;
2008. virtual void lockDataAccess() = 0;
2009. virtual void unlockDataAccess() = 0;
2010.public:
2011. // xestibn de coaexins
2012. virtual bool isValidPort(const string& port, bool& state) = 0;
2013. virtual bool isConnected(const string& port, bool& state) = 0;
2014. virtual bool connect(const string& port, VMChannel* channel) = 0;
2015. virtual bool disconnect(const string& port) = 0;
2016. virtual bool getConnection(const string& port, VMChannel* channel) = 0;
2017.protected:
2018.
// lectura/escritura de mensaxes
2019.
2020.
2021.
2022.
virtual bool read(const string& port, IVNIMsg** msg) = 0;
virtual bool read(const string& port,
IVMMsg** msg,
pfn callbck,
IAsyncClbkArg* clbk_arg = NULL) = 0;
2023.
virtual bool write(const string& port, IVMMsg* msg) = 0;
2024.
2025.protected:
2026.
// cdigo do proceso
2027.
virtual void Initial() = 0;
2028.
2029.
2030.
virtual bool Run() = 0;
virtual void Final() = 0;
virtual bool OnSuspend() = 0;
2031.
virtual bool OnResume() = 0;
2032.
2033.
2034.
2035 . }
virtual bool OnEvent() = 0;
virtual bool OnHandler(void* arg)

virtual bool OnError() = 0;
= 0;
283
A interface declara mtodos para controlar e consultar o estado de execucin dun proceso
(lias 1999-2004), garantir a exclusin mutua no acceso aos datos internos (lias 2007-2009),
configurar as conexins para o paso de mensaxes entre procesos (lias 2012-2016) e escribir e
ler mensaxes (lias 2019-2024). Ntese que parte dos mtodos declarados son protected, polo
que unicamente poden ser utilizados na implementacin das clases derivadas. O cdigo
especfico de cada proceso implementado redefinindo os mtodos declarados nas lias 2027
2034 nas clases derivadas. Estes mtodos son executados en diferentes estados do proceso
segundo se explica no apartado seguinte.
7.1.2.2. O ciclo de vida dun proceso
A Figura 7.4 mostra o diagrama de estados do ciclo de vida dun proceso da mquina virtual.
Durante este ciclo cada proceso ten unha prioridade que lle asignada na sa creacin e non
pode ser modificada. As transicins entre estados correspndense con eventos producidos por
chamadas aos mtodos da interface do proceso: Start (lia 1999), Suspend (lia 2000), Resume
(lia 2001) e Finish (lia 2002); ou por condicins internas detectadas durante a execucin:
error, async_call e sync_call. As accins executadas nas transicins do diagrama
correspndense cos mtodos que conteen o cdigo especfico de cada proceso declarados na
interface IVMProcess (lias 2027-2034).
7.1.2.3. A implementacin dos procesos
A clase VMProcess proporciona a implementacin por defecto da interface IVMProcess
(7.1.2.1) supoendo que cada unha das sas instancias vai ser asignada a un "thread" do
sistema operativo. Ademais esta clase implementa a interface IModule (7.1.1.1), polo que
proporciona tamn a funcionalidade precisa para cargar e descargar procesos dinamicamente na
memoria da mquina virtual. A lxica do ciclo de vida da Figura 7.4 dende que o proceso
iniciado invocando o mtodo Start (lia 1999), ata que a sa execucin remata pola invocacin
do mtodo Finish (lia 2002) ou pola deteccin dun erro, implementada no mtodo Run (lia
2028) da clase VMProcess.
EN EXECUCION
asyncall / OnHand/erQ
syncall / OnEventQ
crear
INICIADO
start/lnitialQ
error / OnError()
*
EN ESPERA
suspend / OnSuspendQ
finisi / FinalQ
FI NALIZADO
resume / OnResumeQ
DETIDO
Figura 7.4. Diagrama de estados do ciclo de vida dun proceso da mquina virtual.
284
O cdigo seguinte mostra a implementacin deste mtodo:

2036.void SFCVMProcess::Run()
2037. {
2038. while (!exit)
2039. {
2040.
unsigned result = getEvent()->Wait(); // bloqueo do proceao
2041.
switch (result)
2042.
2043.
case IAlertableEvent::AE SIGNALED: // proceso desbloqueado
2044.
2045.
2046.
2047.
2048.
2049.
getEvent()->Reset();
if (!exit)
if (suspend)
// invocouse o mtodo auspend
exit ^_ !OnSuspend();
if (!exit)
--ssuspend; // agardar invocacin do mtodo resume
suspend = false;
exit ^_ !OnResume();
2050.
2051.
2052.
2053.
2054.
2055.
2056.
2057.
2058.
2059.
2060.
2061.
2062.
2063.
2064.
2065.
2066.
else if (clbk)
// recibiuae unha notificacin asncrona
exit ^_ !OnHandler(clbk_arg);
clbk = false;
clbk_arg = NULL;
else
// invocouse un mtodo do proceso
exit ^_ !OnEvent();
2067.
}
2068.
break;
2069.
default:
2070.
exit
2071.
2072.
break;
2073.
}
2074.
2075. }
^_ !OnError(); // erro
Unha vez iniciado un proceso, a sa execucin realzase nun bucle do que non se sae ata que
a varibel booleana exit activada, xa sexa porque se invoque o mtodo Finish (lia 2002) ou
debido deteccin dalgunha condicin interna na execucin dos mtodos asociados s
transicins do diagrama de estados da Figura 7.4 (lias 2030-2034). En cada iteracin do bucle
a execucin do proceso bloquease (lia 2040) ata a ocorrencia dalgn dos eventos seguintes:
1. A invocacin dende outro proceso dalgn dos mtodos de control do estado (lias 2000
2002): Finish, Suspend ou Resume.
2. A notificacin dende outro proceso da finalizacin dunha operacin asncrona iniciada por
este proceso.
3. O inicio dende outro proceso dunha operacin asncrona que este proceso implemente.
No resto deste apartado explcanse os detalles da implementacin do mecanismo de bloqueo
da execucin do proceso e os eventos asociados invocacin dos seus mtodos. As
notificacins asncronas son explicadas en (7.1.2.4.2).
285
7.1.2.3.1. O bloqueo da execucin dun proceso
O bloqueo do proceso implementado utilizando un tipo de semforo cuxa interface

abstracta a seguinte:
2076.struct IAlertableEvent
2077. {
2078. // reaultado dunha solicitude de bloqueo
2079. enum {AE_ERROR = 0, AE_SIGNALED, AE_TIME_OUT};
2080. // bloqueo, desbloqueo, consulta e iaiciacin
2081. virtual unsigned Wait() = 0;
2082. virtual unsigned Wait(unsigned timer) = 0;
2083. virtual void Signal() = 0;
2084. virtual bool isSignaled() = 0;
2085. virtual void Reset() = 0;
2086 . } ;
Esta interface declara das versins do mtodo Wait (lias 2081 e 2082), que permiten
bloquear un proceso indefinidamente ou durante un perodo de tempo determinado. O proceso
estar bloqueado ata que transcorra o perodo de tempo indicado ou outro proceso invoque o
mtodo Signal (lia 2083). O mtodo Reset (lia 2085) sirve para reiniciar o semforo e
permitir novos bloqueos. Cada^roceso crea e almacena durante a sa iniciacin unha instancia
que implemente esta interface , que accedida utilizando o mtodo privado getEvent (lia
2040) da clase VMProcess.
7.1.2.3.2. Invocacin dos mtodos Suspend e Resume dende outro proceso
Na versin "multithread" da mquina virtual, a suspensin e reinicio dun proceso

implementada nos mtodos Suspend (lia 2087-2098) e Resume (lia 2100-2111) da clase
VMProcess. A utilizacin destes mtodos presenta as restriccins seguintes^l:
1. Un proceso non pode ser suspendido simultaneamente por varios procesos.
2. Un proceso s pode ser reiniciado polo proceso que o suspenda.
Estas restriccins son garantidas internamente na implementacin dos mtodos Suspend e
Resume utilizando os seguintes atributos privados da clase VMProcess:
1. suspend, un indicador booleano que indica se o proceso est detido.

2. ssuspend, .un semforo no que se bloquea a execucin do proceso mentres est detido.
3. msuspend, un "mutex" para implementar a segunda das restriccins comentadas
anteriormente cando varios procesos invocan simultaneamente o mtodo Suspend. Este
"mutex" proporciona un mecanismo de exclusin mutua de xeito que o primeiro proceso
que obtea o"mutex" ser o que tea o control do reinicio do proceso suspendido.
70 A versin Windows da mquina virtual utiliza o mecanismo de sincronizacin entre "threads" denominado
Event Object para implementar esta interface.
'^ A utilizacin incorrecta dos mtodos Suspend e Resume pode provocar o bloqueo indefinido dun proceso. A
versin de depuracin da implementacin destes mtodos emite mensaxes de aviso para os erros mais comns
sendo responsabilidade do programador garantir a sa utilizacin correcta.
286

O cdigo seguinte mostra unha versin simplificada dos mtodos Suspend e Resume:
2087.void vMProcess::Suspend(void)
2088. {
2089.
if (msuspend.TryEnterMutex()) //
obter "mutex"
2090. {
2091.
if (suspend)
/ / indicar que xa eataba detido (depuracin)

2092.
2093.
suspend = true;
// activar i ndicador
2094.
getEvent()->Signal(); // desbloquear proceso
2095. }
else
2096.
2097.
// indicar que xa foi detido por outro proceso
'
( depuracin)
2098. }
2099.
2100.void VMProcess::Resume()
2101 . {
2102. try
2103.
2104.
2105.
msuspend.LeaveMutex();
++ssuspend;
2106.
2107.
2108.
catch (...)
// liberar "mutex"
// incrementar semforo
2109.
// indicar que non pode ser reiniciado
}
2110.
2111 . }
(_ > resume o proceao)
( depuracin)
Cando un proceso invoca o mtodo Suspend tenta obter o"mutex" msuspend (lia 2089). Se
este est ocupado o proceso xa foi suspendido previamente por outro proceso, polo que a
execucin continua sen modificar o estado do proceso suspendido. En caso contrario, actvase o
indicador suspend (lia 2093) e desbloquease o proceso de xeito que a operacin concla no
mtodo Run, executando o mtodo OnSuspend (lia 2050) no que se suspende o proceso
bloquendoo no semforo ssuspend (lia 2053). Para reiniciar a execucin do proceso invcase
o mtodo Resume, no que se libera o mutex msuspend (lia 2104) e se desbloquea o proceso
suspendido incrementando o semforo ssuspend (lia 2105). A operacin compltase no
mtodo Run, no que se desactiva o indicador suspend (lia 2054), exectase o mtodo
OnResume (lia 2055) e continase coa execucin do proceso. En caso de que o proceso que
invoque o mtodo Resume non sexa o mesmo que detivo o proceso suspendido, o intento de
liberar o mutex msuspend provocar unha excepcin e a execucin continuar sen modificarse
^
o estado do proceso suspendido.
7.1.2.3.3. Invocacin do mtodo Finish dende outro proceso
O cdigo seguinte mostra unha versin simplificada do mtodo Finish (lia 2002):
2112.void VMProcess::Finish(void)
2113 . {
exit = true;
2114.
2115.
if (suspend)
Resume();
2116.
2117.
else
getEvent()->Signal();
2118.
2119 . }
A execucin deste mtodo activa o indicador exit (lia 2114) para que o proceso saia do
bucle do mtodo Run e, dependendo do estado do proceso -valor do indicador suspend (lia
2115}-, reinciase a sa execucin ou desbloquease. Debido s restriccins comentadas
anteriormente, un proceso suspendido unicamente pode ser finalizado polo proceso que o
suspendeu.
287
7.1.2.3.4. Inicio dunha operacin asncrona dende outro proceso
O seguinte cdigo mostra un mtodo xenrico que implemente o inicio dunha operacin
asncrona implementada polo proceso:
2120.void AnyVMProcess::AnyMethod(void)
2121 . {
2122. lockDataAccess();
2123. / / cdigo especfico do mtodo (modifica datos internos se preciso)
2124. getEvent()->Signal(); // deabloquear proceao
2125. unlockDataAccess();
2126 . }
A implementacin deste mtodo comeza obtendo o"mutex" (lia 2122) que regula o acceso
aos datos internos do proceso (a execucin detense ata que o"mutex" estea libre). Unha vez
que se obtn o"mutex" realzanse as operacins que preparan a execucin asncrona (lia
2123), modificando os datos internos do proceso se preciso, desbloquease o proceso (lia
2124) e finalmente librase o"mutex" (lia 2125). A operacin compltase no mtodo Run,
invocando o mtodo OnEvent (lia 2067) que implementa o cdigo da operacin asncrona que
^
especfico de cada proceso.
7.1.2.4. A comunicacin entre procesos
A comunicacin entre procesos da mquina virtual pode realizarse mediante unha das tres
tcnicas seguintes:
1. Como os procesos da mquina virtual son instancias de clases derivadas da interface
IVMProcess (7.1.2.1), o mecanismo de comunicacin mis simple consiste na invocacin
dende un proceso dalgn dos mtodos implementados por outro. O uso desta tcnica
require que o proceso ìnvocador' poda obter unha referencia vlida ao proceso ìnvocado',
o que en ocasins implica coecer de antemn o tipo concreto deste proceso. Exemplos do
uso desta tcnica son as invocacins dos mtodos Finish, Suspend ou Resume explicados
en (7.1.2.3.2; 7.1.2.3.3).
2. En ocasins a invocacin dun mtodo nun proceso sirve para iniciar unha operacin
asncrona (7.1.2.3.4). Existen situacins nas que o proceso ìnvocador' require dunha
notificacin que indique cando esta remata. O segundo mecanismo de comunicacin entre
procesos consiste na notificacin da finalizacin de operacin asncronas, tal e como se
explica en (7.1.2.4.2).
3. A terceira tcnica consiste no envo de mensaxes asncronas entre procesos. As mensaxes
poden ser utilizadas, por exemplo, para intercambiar informacin, iniciar operacins
asncronas ou notificar a ocorrencia de eventos. Para que dous procesos podan intercambiar
mensaxes preciso que exista entre eles unha conexin. As conexins son unidireccionais e
poden restrinxir o tipo de mensaxes transmitidas a travs delas. En cada proceso se indica o
nmero e tipo de conexins que poden realizarse mediante a declaracin de portas de
enlace. Unha conexin entre dous procesos crease unindo das portas de enlace do mesmo
tipo (unha en cada proceso) mediante un canal de comunicacins, que fai as veces de
medio de transmisin entre os procesos. Esta tcnica ten a avantaxe de que o acoplamento
entre os procesos moi dbil ao non existir referencias directas entre eles o que facilita a
reconfiguracin dinmica da arquitectura da mquina virtual mediante a modificacin das
conexins entre procesos.
288
No resto deste apartado explcanse en detalle a implementacin dos mecanismos de paso de

mensaxes e de notificacin asncrona entre procesos da mquina virtual na sa versin
"multithread".
7.1.2.4.1. Paso de mensaxes entre procesos
Na Figura 7.5 mstrase o diagrama das clases utilizadas na implementacin do mecanismo

de paso de mensaxes entre procesos. Como pode verse son catro as clases principais implicadas
na implementacin deste mecanismo:
1. A clase VMProcess, derivada de IVMProcess (7.1.2.1), proporciona a implementacin por
defecto dos mtodos relacionados coa conexin de procesos (lias 2012-2016) e o envo e
recepcin de mensaxes (lias 2019-2024). Esta clase tamn almacena o conxunto de portas
de enlace do proceso -agregacin ports-.
2. A clase VMPort, especializacin da clase parametrizada Port para mensaxes de tipo
IVMMsg, representa as portas de enlace utilizadas para realizar as conexins entre
procesos. Cada porta de enlace ten un identificador alfanumrico -atributo id- nico no
proceso que a contea e mantn unha referencia -agregacin channel- ao canal utilizado
como medio de transmisin da conexin. A clase parametrizada Port declara mtodos para
conectar a porta a un canal dado e consultar o seu estado. Ntese que poden crearse portas
de distintos tipos que restrinxan as mensaxes transmitidas a travs delas mediante
diferentes especializacins da clase parametrizada Port.
3. A clase VMChannel, especializacin da clase parametrizada Channel para mensaxes de
tipo IVMMsg, representa o medio de transmisin utilizado na conexin entre procesos. Os
canais implementan comunicacins N a 1. Cada canal ten a responsabilidade de almacenar
as mensaxes -agregacin buffer- na orde na que son recibidas mentres non sexan
recuperadas polo proceso receptor. A clase parametrizada Channel declara mtodos para
ler e escribir mensaxes no canal e, do mesmo xeito que coas portas de enlace, poden
crearse canais de diferentes tipos que restrinxan as mensaxes transmitidas a travs deles.
Na versin actual da implementacin da clase parametrizada Channel garntese a exclusin
mutua no acceso simultneo ao canal e non se tratan os problemas relacionados co
desbordamento do "buffer" de mensaxes.
4. A clase IVMMsg, interface abstracta da que derivar as clases de mensaxes intercambiadas
entre os procesos da mquina virtual.
-------------,
;Msg
Port
;Msg ;
id : string
IVMMs9
bulTer
Channel
NMProcess
read (port_id, IVMMsg)
write (port_id, NMMsg)
isValidPort (port_id)
connect (part_id, VMChanne^

discannect (port_id)
isConnected (port_id) : bool
getConnection (port_id) : VMChannel
0. 1
OI getKep Q : string
getChannel Q : Channel<Msg>
isConnected Q : bool
connect (Channel<Msg>)
disconnect Q
^
; bind(IVMMsg)
; bind(IVMMsg)
read (Msg)
write (Msg)
VMChannel
channel
VMPort
f
vMProcess
ports
Figura 7.5. Diagrama das clases que modelan o mecanismo de paso de mensaxes ene procesos.
289
O mtodo read da clase VMChannel, utilizado polo proceso receptor para recuperar as
mensaxes almacenadas nun canal, implementouse con das semnticas diferentes:
l. Con bloqueo, o proceso receptor detn a sa execucin ata que haxa algunha mensaxe
dispobel no canal.
2. Sen bloqueo, utilzase o mecanismo de notificacin asncrona para notificarlle ao proceso
receptor a presencia dunha mensaxe no canal.
O diagrama da Figura 7.6 mostra a interaccin entre os obxectos implicados no envo dunha
mensaxe dende un proceso da mquina virtual a outro. A primeira secuencia mostra o envo da
mensaxe, que almacenada no canal, mentres que a segunda secuencia mostra a lectura con
bloqueo. Na implementacin do canal utilzase un "mutex" para controlar o acceso ao "buffer"
de mensaxes e un semforo para bloquear a execucin do proceso receptor ata que haxa
algunha mensaxe dispobel.
^1:VMProcess
write("port_id, msg)
port = ports.find("port id)
port:VMPort
channel:VMChannel
write(msg)
write(msg)
buffer.lock()
buffer.write(msg)
buffer.unlock()
--------------------------------------
sem.incQ
^2:VMProcess
msg = read(port_id)
port = ports.find("port id)
port:VMPort
channel:VMChannel
msg = read()
msg = readQ
----------------------------------------------,,^ -------------------------------------
sem.decQ
buffer.lock()
msg = bufrer.read()
buffer.unlock0
Figura 7.6. Secuencias de mensaxes intercambiadas no envo e recepcin dunha mensaxe.
7.1.2.4.2. Notificacin da finalizacin de operacins asncronas
Existen situacins nas que dende un proceso se inicia unha operacin asncrona noutro e,
unha vez que esta se completa, continase coa execucin doutras operacins. A
implementacin deste funcionamento require dalgn mecanismo que permita dende un proceso
notificar a outro a finalizacin dunha operacin asncrona. Ntese que a tcnica de paso de
mensaxes explicada no apartado anterior pode ser utilizada para iniciar operacins asncronas e
notificar a sa finalizacin naqueles casos nos que os procesos implicados estean conectados
mediante un canal e non haxa requirimentos relacionados co tempo que a notificacin pase
almacenada neste antes de ser procesada. Sen embargo estas condicins non sempre se
cumpren, polo que se implementou na mquina virtual unha tcnica que perrnite realizar
notificacins asncronas inmediatas entre procesos non conectados mediante un canal.
290
A tcnica basease na utilizacin de funcins "callback" e presupn que os procesos

implicados na comunicacin pertencen ao mesmo espacio de direccionamento. A sa
implementacin consiste en almacenar, no proceso que realiza a operacin asncrona, unha
referencia a unha funcin que executada cando a operacin remata. Esta funcin notifica a
finalizacin da operacin ao proceso que a iniciou e, opcionalmente, psalle un argumento
almacenado xunto coa funcin. A clase AsyncClbkContainer implementa o comportamento por
defecto dun proceso que realice notificacins asncronas. O seguinte cdigo mostra a
implementacin desta clase:
2127.class AsyncClbkContainer
2128 . {
2129.private:
pfn async_fun;
2130.
2131. IAsyncClbkArg* async_fun_arg;

2132.public:
2133. // conaulta, modificacin e execucin da notificacibn
2134. pfn getCallback(void) { return async_fun; }
2135. IAsyncClbkArg* getCallbackArg(void) { return async_fun_arg;
2136. void setCallback(pfn fun, IAsyncClbkArg* fun_arg = NULL)
2137. {
2138.
async_fun = fun;
async_fun_arg = fun_arg;
2139.
2140. }
2141. void callCallback(void) const

2142. {
if (asyn _fun)
2143.
(*async_fun)(async_fun_arg);
2144.
2145. }
2146. };
2147.// declaracin do tipo da fuacin "callback"
2148.typedef void (*pfn) (IAsyncClbkArg*);
2149.// argumento da notificacin
2150.struct IAsyncClbkArg
2151. {
2152. virtual IAsyncClbkArg* clone() = 0;
2153 . } ;
A clase AsyncClbkContainer almacena as referencias funcin "callback" e ao argumento

opcional nos atributos async_f'un (lia 2130) e async_fun_arg (lia 2131), respectivamente.
Tamn declara mtodos para consultar (lias 2134-2135) e almacenar (lias 2136-2140) a
funcin "callback" e o seu argumento, e para executar a notificacin asncrona (lias 2141
2145). Como pode verse na lia 2148, suponse que a funcin "callback" non devolve ningn
resultado e ten un argumento de tipo IAsyncClbkArg, que a interface abstracta (lias 2150
2153) da que derivan todas as clases utilizadas como argumento dunha notificacin asncrona.
Esta implementacin ten das restriccins:
1. As funcins "callback" s poden ser funcins globais ou mtodos estticos dunha clase^Z.
2. Cada proceso non pode almacenar mis dunha funcin "callback" simultaneamente. Isto
limita o nmero de operacins asncronas simultneas que un proceso pode notificar73.
A recepcin dunha notificacin asncrona implementada na clase VMProcess, que
proporciona un mecanismo xenrico reutilizado en todas as clases derivadas. Esta clase declara
'Z Pode consultarse [ 142] para unha explicacin detallada de porqu non poden utilizarse os mtodos non estticos
dunha clase como funcins "callback".
73 Ainda que podera realizarse unha implementacin que eliminara esta restriccin, na versin actal da mquina
virtual nunca se utilizou mis dunha notificacin asncrona por proceso.
291
un mtodo esttico, que ser utilizado como funcin "callback" por todos os procesos, e dous
atributos privados auxiliares. O cdigo seguinte mostra as declaracins e a implementacin do
mtodo esttico na clase VMProcess:
2154.class VMProcess
2155. {
2156. bool clbk;

// indicador da recepcin duaha notificacin asfncroaa
2157. void* clbk_arg; // argumento da notificacin
2158.protected:
2159. static void async_callback(IAsyncClbkArg* arg); // funcin "callback^
2160. };
2161.// recepcin dunha notificacin asncrona
2162.void VMProcess::async_callback(IAsyncClbkArg* arg)
2163 . {
2164. async_clbk_arg* parg = dynamic_cast<async_clbk_arg*>(arg);
2165. if (parg)
2166.
2167.
parg->pthis->clbk = true;
// activar indicador
parg->pthis->clbk_arg = parg->parg; // almacenar argumento
2168.
// desbloquear proceso
parg->pthis->getEvent()->Signal();
2169.
2170.
2171. delete arg;
2172 . }
O mtodo async_callback (lia 2159) presupn que recibe unha instancia da clase
async_clbk_arg. Esta clase derivada de IAsyncClbkArg (lias 2150-2153) e almacena unha
referencia ao proceso que iniciou a operacin asncrona e un argumento opcional que lle ser
enviado ao proceso cando a operacin remate. A implementacin do mtodo utiliza a
informacin almacenada nesta instancia para acceder ao proceso que iniciou a operacin
asncrona (lia 2164), activar o valor do atributo clbk (lia 2167), almacenar a informacin
opcional da notificacin no atributo clbk arg (lia 2168) e desbloquear o proceso (lia 2169).
O procesamento da notificacin compltase no mtodo Run no que se invoca o mtodo
OnHandler (lia 2061), pasndolle como argumento a informacin almacenada no atributo
clbk_arg. Finalmente reincianse os valores dos atributos clbk e clbk_arg (lias 2062 e 2063)
para permitir unha nova notificacin.
Unha limitacin da implementacin descrita que unicamente se almacena a ltima
notificacin recibida por un proceso, polo que cando un proceso suspendido que tea unha
notificacin pendente reciba unha nova notificacin, a pendente prdese. Esta situacin
repetirase mentres o proceso suspendido contine recibindo notificacins. responsabilidade
do programador ter en conta esta limitacin naquelas situacins nas que sexa preciso procesar
todas as notificacins asncronas. No seguinte exemplo mstrase o cdigo mnimo preciso para
implementar a solicitude dun servicio asncrono con notificacin de finalizacin entre un
proceso cliente e un proceso servidor utilizando a tcnica explicada previamente:
2173.// Proceso servidor
2174.class Server : public VMProcess, public AsyncClbkContainer
2175. {
bool OnEvent();
2176.
2177.public:
void initAsyncService(pfn clbk, IAsyncClbkArg* clbk_arg);
2178.
2179. } ;
2180.
2181.boo1 Server::OnEvent()
2182 . {
2183.
// executar aqu o cdigo do servicio
callCallback(); //
2184.
2185. }
invocar funcin callback^
292

2186.void Server::initAsyncService(pfn clbk, IAsyncClbkArg* clbk_arg)
2187 . {
2188.
lockDataAcess();
2189. setCallback(clbk, clbk_arg);// almacenar informacin ^callbacky
// desbloquear proceao
2190. getEvent()->Signal();
2191. unlockDataAcess();
2192. }
2193.
2194.// Proceso cliente
2195.class Client : public VMProcess
2196 . {
2197.
2198.
2199.
2200.
Server* pServer;
void requestAsyncService()
bool OnEvent();
bool OnHandler(void* arg);
2201.public:
2202.
Client(Server* srv)
2203.
void Operation();
2204 . } ;
: pServer(srv) {}
2205.
2206.boo1 Client::OnEvent()
2207. {
// executar aqu o cdigo previo ao inicio do aervicio asncroao
2208.
requestAsyncService ( ); // iniciar servicio asncrono
2209.
// executar aqu o cdigo posterior ao iaicio do servicio asncrono
2210.
2211. }
2212.
2213. bool Client::OnHandler(void* arg)
2214. {
2215.
// executar aqu o cdigo de manexo da notificacin asncrona
2216. }
2217.
2218. void Client::requestAsyncService()
2219. {
async_clbk_arg* parg = new async_clbk_arg(this);
2220.
if (parg)
2221.
pserver->initAsyncService(async_callback, parg); //
2222.
2223.
2224.
2225.
2226.
2227.
2228.
2229.
2230.
2231.
2232.
2233.
2234.
2235.
2236.
2237.
2238.
2239.
iniciar aervicio
void Client::Operation()
lockDataAcess();
// modificar aqu os datos internos do cliente
getEvent()->Signal(); // deabloquear proceao
unlockDataAcess();
// $xecucin do exemplo
int main()
Server server;
Client client(&server);
client.Operation();
Na implementacin da solicitude da operacin asncrona (lias 2218-2223), ao servidor

psanselle como argumentos unha referencia ao mtodo esttico async_callback e outra ao
proceso que solicita o inicio da operacin (mediante o apuntador this do C++). No
procesamento da solicitude (lias 2186-2192) o servidor almacena estes argumentos utilizando
o mtodo setCallback herdado da clase AsyncClbkContainer (lia 2136). A execucin do
servicio asncrono implemntase no mtodo OnEvent do servidor (lias 2181-2185) e, unha vez
que remata, a notificacin ao cliente faise mediante o mtodo callCallback, que tamn
herdado da clase AsyncClbkContainer (lia 2141).
293
7.1.2.5. Exemplo da utilizacin de procesos

A Figura 7.7.a mostra un exemplo de aplicacin formada por un proceso de tipo A conectado
cun de tipo B e dous de tipo C. Nas conexins entre o proceso tipo A e os procesos tipo C
intercambiase un tipo de mensaxes e nas conexins entre o proceso tipo A e o proceso tipo B
intercambiase outro tipo diferente. A Figura 7.7.b mostra o diagrama de obxectos daâplicacin
no que se utilizan as clases explicadas anteriormente, e que implementada mediante o cdigo
seguinte:
2240.// Mensaxes
2241 . struct VNIl^7essageA : public IVMMsg {};
2242.struct VMMessageB : public IVMMsg {};
2243.
2244.// Portas de enlace
2245.typedef Port<VMMessageA> VMPortA;
2246.typedef Port<VMMessageB> VMPortB;
2247.
2248.// Canaia de comunicacin
2249.typedef Channel<VMMessageA> VMChannelA;
2250.typedef Channel<VMMessageB> VMChannelB;
2251.
2252.// Proceso tipo A
2253.class VMProcessA : public VMProcess
2254. {
2255.public:
2256.
VMProcessA();
2257.
-VMProcessA();
2258 . } ;
2259.
2260.VMProcessA::VMProcessA()
2261. {
2262.
2263.
2264.
2265.
2266.
VMPortA *port_al = new

VMPortA *port_a2 = new
VMPortB *port_bl = new
VMPortB *port_b2 = new
ports.insert(port_al);
VMPortA("al");
VMPortA("a2");
VMPOrtB("bl");
VMPortB("b2");
2267. ports.insert(port_a2);
2268. ports.insert(port_bl);
2269. ports.insert(port_b2);
2270. }
2271.
2272.VMProcessA::-VMProcessA()
2273. {
2274.
ports.destroy();
2275. }
2276.
2277.// Proceao tipo B
2278.class VMProcessB : public VMProcess
2279. {
2280.public:
2281.
VMProcessB();
-VMProcessB();
2282.
2283 . } ;
2284.
2285.VMProcessB::VMProcessB()
2286. {
2287.
2288.
2289.
2290.
2291. }
VMPortB *port_bl = new VMPortB("bl");
VMPOrtB *port_b2 = new VMPortB("b2");
ports.insert(port_bl);
ports.insert(port_b2);

2292.VMProcessB::-t7MProcessB()
2293. {
2294. ports.destroy();
2295. }
2296.
2297.// Proceso tipo C
2298.class VMProcessC : public VMProcess
2299. {
2300.public:
2301. VMProcessC();
2302. -VMProcessC();
2303 . } ;
2304.
2305.VMProcessC::VMProcessC()
2306. {
2307.
2308.
VMPOrtA *port_al = new VMPortA("al");
ports.insert(port_al);
2309. }
2310.
2311.VMProcessC::-VMProcessC()
2312. {
2313. ports.destroy();
2314 . }
2315.
2316.// Creacin e conexin doa proceaos
2317 . int main ( )
2318. {
2319. // canais
2320.
2321.
2322.
VMChannelA channel_al, channel_a2;

VMChannelB channel_bl, channel_b2;
// procesos
2323.
2324.
VMProcessA process_a;
VMProcessB process_b;
2325.
2326.
VMProcessC process_cl, process_c2;

// conexin A-C1
2327.
2328.
2329.
2330.
2331.
2332.
2333.
2334.
2335.
2336.
2337.
2338. }
process_a.connect("al", &channel_al);
process_cl.connect("al", &channel_al);
// conexin A-C2
process_a.connect("a2", &channel_a2);
process_c2.connect("al", &channel_al);
// conexina A-B
process_a.connect("bl", &channel_bl);
process_b.connect("bl", &channel_bl);
process_a.connect("b2", &channel_b2);
process_b.connect("b2", &channel_b2);
return 0;
294
295
^
U
O
f0
^
47
U'
c
c
ti'
N
N
L
U
^
G
^
i
O
l0
I
^
41
L
U
^
N
l0
l0
L
U
^
>
m
U
a^
c
c
m
t
c
c
O
^
Co
N
W
I
^
m
^ a
> i
d
^
t
>
d
m
L
U
Figura 7.7. Exemplo de utilizacin dos procesos: a) arquitectura da aplicacin; e b) diagrama de obxectos da
implementacin.
296
7.1.3. A arquitectura de procesos da mquina virtual

Os procesos que forman a arquitectura lxica da mquina virtual son mostrados na Figura
7.8. Os cadros pequenos representan as portas de enlace dos procesos, e as frechas que os unen,
os canais de comunicacin a travs dos que se intercambian mensaxes asncronas (7.1.2.4.1).
Os rectngulos cun contorno mis fino correspndense con procesos que implementan a
interface IModule ( 7.1.1.1), polo que poden ser substitudos dinamicamente sen deter a
execucin da mquina virtual. Nesta arquitectura poden distinguirse catro subsistemas
principais:
1.
O ncleo da mquina virtual, formado pola base de datos de E/S na que se almacenan os
valores das varibeis de proceso, o manexador de temporizacins, e o depurador.
2.
O subsistema de E/S, formado polos "drivers" de E/S e os procesos que xestionan a

relacin entre estes e o ncleo da mquina virtual.
3. O xestor da configuracin, que proporciona unha interface de acceso remoto aos servicios
de configuracin e control da mquina virtual.
4. O subsistema de aplicacin, no que se executan as aplicacins desenvolvidas polo usuario
que son cargadas dinamicamente na memoria da mquina virtual.
Temporizador
"Driver" de Driver" de
entrada
E/S
Driver" d
E/S
Driver" de "Driver" de
sada
saida
1 " ^`^`^ .
Proceso
Figura 7.8. Arquitectura de procesos da mquina virtual.
7.1.4. Implementacin da arquitectura da mquina virtual

Os diagramas da Figura 7.9 e da Figura 7.10 mostran as clases e relacins utilizadas para
representar a estructura da mquina virtual, que modelada mediante a clase VMachine. As
instancias desta clase son procesos que inclen os mecanismos par o almacenamento de
mdulos (7.1.1.3) e a xestin de configuracins (7.1.1.4) derivndoos das clases
ModuleStore e ConfigurationStore respectivamente. A sa estructura se forma mediante a
agregacin de mdulos (7.1.1.2), utilizando o soporte derivado da clase StructuredModule.
297
VMProcess
(trom Pro
StructuredModule
(hom Modula^
IStructuredStoreModule
(from Module^
ModuleStore
(from Modvlrrs)
DLUnfo
ConfigurationStore
(trom Modula^
VMachine
services
dlls
^state : VMState ^
IVMServices
systeml0
channels
SystemDataDeclaration
(from Baslo Ehments)
VMChannel
(hom Prooeaes)
Figura 7.9. Diagrama das clases que modelan a arquitectura da mquina virtual.
As agregacins representadas na Figura 7.9 son as seguintes:

1. dlls, almacena a informacin sobre as DLLs e mdulos cargados na memoria da mquina
virtual.
2. systeml0, almacena a declaracin das varibeis de proceso e a sa asignacin aos puntos de
E/S (7.2.1.4.1).
3. channels, almacena os canais utilizados para o paso de mensaxes entre os procesos da
mquina virtual (7.1.2.4.1).
4. services, mantn unha referencia a unha instancia dunha clase derivada da interface
IVMServices, que proporciona un punto de acceso comn aos servicios proporcionados
polo ncleo da mquina virtual (7.4.3).
As clases e relacins utilizadas para a representacin dos subsistemas da mquina virtual
mstranse na Figura 7.10. As agregacins output_mgr, input_mgr e iodrivers referencian
xestores e"drivers" que forman o subsistema de E/S. O ncleo da mquina virtual est formado
polas agregacins iortdb, timer e debugger, que referencian respectivamente base de datos de
E/S (7.3.1), ao xestor de temporizacins (7.3.2) e ao depurador. O subsistema de xestin da
configuracin est formado pola agregacin comm_server, que referencia ao servidor de acceso
remoto, e as agregacins dlls e systeml0 (Figura 7.9) comentadas anteriormente. Por ltimo, o
subsistema de aplicacin est formado unicamente por un intrprete Grafcet referenciado
mediante a agregacin player.
IORTDB
(hom RTDataBase)
t
IMultitimerSeroer
output_mgr
iortdb
timer
1
IModule
(from blodules)
iodrivers
yMachine
_ debugger
VMDebu ger
omm_seroer
input_mgr
player
t
IGrafcetPlayer
(hom Gratcet Player)
1
NMServer
(from Communleatlons)
Figura 7.10. Diagrama das clases que modelan os subsistemas da mquina virtual.
298
Ntese que a representacin do subsistema de aplicacin mediante a clase abstracta

IGrafcetPlayer implica que a versin actual da mquina viriual non permite a integracin de
calquera tipo de interprete ou aplicacin. Ser preciso modificar este aspecto en futuras
versins para permitir a reutilizacin da arquitectura.
7.2. O subsistema de E/S
O subsistema de E/S (Figura 7.8) est formado polos "drivers" de E/S e os procesos que
xestionan a interaccin entre os "drivers" e o ncleo da mquina virtual. Nesta seccin se
explican os detalles do deseo e implementacin dos "drivers" (7.2.1) e xestores de E/S
(7.2.2), as como as tcnicas utilizadas para a simulacin de valores do proceso (7.2.3).
7.2.1. Os "drivers" de E/S

A interaccin da mquina virtual co proceso realzase mediante dispositivos que
proporcionan acceso as sas magnitudes fisicas. Estes dispositivos poden ser de moi diferentes
tipos: tarxetas de E/S que proporcionen un nmero reducido de valores booleanos e analxicos,
sistemas de E/S distribudos, buses de campo, redes de comunicacin, etc. O manexo desta
variedade de dispositivos realzase mediante "drivers". Cada "driver" da mquina virtual pode
xestionar un ou varios dispositivos externos, ben accedendo directamente ao seu "hardware" ou
interactuando cos "drivers" propietarios proporcionados polo fabricante do dispositivo. A
complexidade da implementacin dun "driver" da mquina virtual depender do dispositivo
concreto e das funcionalidades que este proporcione, pero o seu manexo dende a mquina
virtual ser igual en cada caso. Ademais os "drivers" implementan a interface IModule
(7.1.1.1) polo que poden ser cargados e descargados dinamicamente en memoria dende unha
DLL. En consecuencia, a inclusin do soporte a novos dispositivos require da implementacin
de novos "drivers" ou a modificacin dos existentes, pero non da modificacin da arquitectura
lxica da mquina virtual.
7.2.1.1. As funcionalidades dun "driver" de E/S
Os "drivers" da mquina virtual proporcionan as seguintes funcionalidades:
1.
O control do estado de execucin do "driver".
2. A consulta e modificacin da configuracin do dispositivo de E/S.

3. A lectura e escritura de valores no dispositivo de E/S.
4. A xestin da asignacin de varibeis a magnitudes Esicas accedidas mediante o dispositivo

de E/S.
O seguinte cdigo mostra a declaracin da interface IDeviceDriver que define os mtodos
que proporcionan as funcionalidades indicadas:
2339.class IDeviceDriver
2340. {
2341.public:
2342. / / coatrol do estado de exacucin
2344.
2345.
2346.
2347.
2348.
virtual
virtual
virtual
virtual
virtual
void
void
void
bool
bool
Suspend() = 0;
Resume() = 0;
Finish() = 0;
isSuspended() = 0;
isRunning() = 0;
299
Seccin 7.2: O subsistema de E/S
2349. // configuracia do dispoaitivo
2350.protected:
2351. virtual Devicelnfo* buildDeviceInfo(void) const = 0;
2352. virtual void configureDevice(const DeviceInfo& di) = 0;
2353.public:
2354. virtual bool getDeviceInfo(DeviceInfo& di) const = 0;
2355. virtual bool setDeviceInfo(const DeviceInfo& di) = 0;

.
2356. virtual bool isvalidCharacteristic(const string& c) const = 0;
2357. virtual bool isvalidiOPoint(const string& iopt) const = 0;
2358. // asignacin de varibeis
2359. virtual bool schedule0utput(const string& iopt, const string& out) = 0;
2360. virtual bool unschedule0utput(const string& iopt) = 0;
2361. virtual bool scheduleInput(const string& iopt, const string& in,
2362.
unsigned sz, long period = 0) = 0;
2363. virtual bool unscheduleInput(const string& iopt) = 0;
2364. virtual bool unscheduleAll(void) = 0;
2365. // lectura e escritura de valorea
2366.
virtual bool readIOPoint(const string& iopt, void* buf, unsigned sz) = 0;
2367.
virtual bool writelOPoint(const string& iopt, void* buf, unsigned sz) = 0;
2368. virtual bool listenIOPoint(const string& iopt, void* buf, unsigned sz,
pfn clbk, IAsyncClbkArg* clbk_arg = NULL) = 0;
2369.
2370.
virtual bool receivedlOPoint(const string& iopt, unsigned& sz, unsigned& err) = 0;
2371. virtual bool stopListeningIOPoint(const string& iopt) = 0;
2372 . } ;
A interface declara mtodos comns aos da interface IVMProcess (7.1.2.1) para o control e
consulta do estado de execucin do "driver" (lias 2343-2348). A configuracin do dispositivo
realzase mediante os mtodos declarados nas lias 2351-2352. Ntese que os mtodos
buildDevicelnfo e configureDevicelnfo estn declarados como protected, polo que uniamente
poden ser utilizados na implementacin das clases derivadas. Os mtodos para a xestin da
asignacin de varibeis a magnitudes fisicas declranse nas lias 2359-2364, e os que permiten
ler e escribir valores no dispositivo nas lias 2366-2371.
Nos apartados seguintes explcanse os detalles da implementacin das funcionalidades
proporcionadas polos "drivers" da mquina virtual.
7.2.1.2. Configuracin dun "driver" de E/S
Cada "driver" da mquina virtual almacena internamente a informacin que describe a
estructura, caractersticas e valores que permiten configurar o funcionamento dun dispositivo
de E/S. Esta informacin creada durante a iniciacin do "driver" na implementacin do
mtodo buildDevicelnfo (lia 2351), e pode ser consultada e modificada utilizando os mtodos
getDevicelnfo (lia 2354) e SetDevicelnfo (lia 2355). A configuracin do dispositivo
utilizando os valores da configuracin actual realizada na implementacin do mtodo
configureDevicelnfo (lia 2352).
Cada dispositivo de E/S modelado na mquina virtual como un conxunto de subsistemas
que forman unha estructura xerrquica en forma de rbore. A raz da xerarqua correspndense
co dispositivo e os niveis inferiores (as follas) cos transductores (denominados puntos de E/S na
mquina virtual) que permiten ler e escribir os valores das magnitudes fisicas do proceso. Cada
subsistema ten asociado un conxunto de caractersticas que permiten configuralo. Cada
caracterstica ten un nome, un conxunto de valores vlidos e un valor actual. Os subsistemas,
caractersticas e valores vlidos poden ter asociada unha condicin que permite determinar o
seu estado de activacin ou validez en funcin dos valores actuais da configuracin.
Esta especificacin suficientemente xenrica como para permitir a descricin de mltiples
tipos de dispositivos como, por exemplo, a porta serie dun PC, que pode ser modelada como un
nico punto de E/S cun pequeno conxunto de caractersticas (velocidade, bits de parada, tipo de
300
paridade, etc.); unha tarxeta de adquisicin de datos con varios subsistemas (convertedor D/A,
convertedor A/D, mdulos de E/S dixitais e analxicas, contadores, temporizadores, etc.) e
mltiples puntos de E/S; ou dispositivos de E/S distribuda mis complexos.
Ademais, a posibilidade de asociar unha condicin de activacin ou validez aos subsistemas,
caractersticas e valores vlidos perrnite modelar situacins nas que os valores ou a validez
dunha caracterstica dependen dos valores doutras. Por exemplo, nunha porta serie o valor do
tipo de paridade non aplicbel se non est activado o control de paridade. Do mesmo xeito
poden modelarse diferentes configuracins dos subsistemas que formen o dispositivo de E/S.
Por exemplo, hai tarxetas de adquisicin de datos analxicos que teen dous modos de
funcionamento, por voltaxe simple ou por diferencia de voltaxe. No segundo modo, para cada
valor adquirido utilzanse dous canais de entrada (o valor adquirido a diferencia das
medicins nambos canais) polo que o nmero de puntos de E/S a metade dos dispobeis
cando se utiliza o modo simple.
No diagrama da Figura 7.11 mstranse as clases utilizadas para representar a informacin de
configuracin dun "driver" da mquina virtual. No resto deste apartado descrbese en detalle
cada clase e mostrase un exemplo de como son utilizadas para modelar un dispositivo de E/S,
en concreto a porta serie dun PC.
enumeration
DeaiceLevelType
Device
Subsystem
IOPoint
De+ricelnfo
name : string
num_levels : unsigned
main level
DeviceLevel
name : string
type : DeviceLevelType
level : unsigned
IDeviceCharacteristic
characteristics
characteristic
subsystems
values
DeviceCharacteristicReference
IDeviceValue
r---- ^
^type ,
DeviceVaue ^ I
levels
DeviceSubsystem
^
'type
values
----^
DeviceSingleValue
value : tppe
_^
-L;tYPe ---- ^
DevicelntenralValue ^ ^
min_value : type
max_value : tppe
DeviceValidValue
R
OevicePrecanditon 0^_1
0..1
valid values
precondition
^type----:
_^^
DeviceCharacteristic
n ame : string
value : type
Figura 7.11. Diagrama das clases que modelan a configuracin dun dispositivo de E/S.
Tipo de subsistema ("DeviceLevelType")

Enumeracin que describe os tipos de subsistemas dun dispositivo de E/S. Os valores
escalares definidos son:
301
device, identifica ao dispositivo. En cada configuracin unicamente pode haber un

subsistema deste tipo, que se corresponde coa raz da estructura xerrquica que forman os
subsistemas do dispositivo.
subsystem, indica un subsistema xenrico que pode conter outros subsistemas ou puntos de
E/S.
-^
iopoint, identifica un transductor de entrada ou sada do dispositivo. Os subsistemas deste
tipo unicamente poden aparecer no nivel mis baixo da estructura xerrquica e cada un
deles permitir a lectura ou escritura do valor dunha magnitude do proceso.
Informacin do dispositivo ("DeviceInfo")
Esta clase a que agrupa a informacin do dispositivo e sirve como punto de acceso
estructura xerrquica que esta forma.
Atributos:
name, identificador alfanumrico do dispositivo de E/S.
num_levels, nmero de niveis da estructura xerrquica que forman os subsistemas do

dispositivo.
Asociacins:
main_level, referencia raz da estructura xerrquica.
Nivel da xerarqua de subsistemas ("DeviceLevel")
Esta clase representa os niveis da estructura xerrquica que forman os subsistemas.
Atributos:
name, identificador alfanumrico do nivel.
type, tipo de subsistema que representa o nivel.
level, profundidade do nivel na xerarqua.
Asociacins:
characteristics, conxunto de caractersticas que permiten configurar o nivel.
subsystems, conxunto de subsistemas que forman o nivel.
Subsistema ("DeviceSubsystem")
Esta clase representa os subsistemas do dispositivo.
Asociacins:
precondition, condicin de activacin do subsistema.
levels, conxunto de referencias aos niveis inmediatamente inferiores da xerarqua que

forman parte do subsistema.
Caracterstica ("IDeviceCharacteristic")
Interface abstracta da que derivan todas as clases utilizadas para representar as
caractersticas do dispositivos de E/S.
302
Caracterstica ("DeviceCharacteristic")
Clase parametrizada derivada de IDeviceCharacteristic. As clases que representan
caractersticas asociadas a valores de diferentes tipos (booleanos, enteiros, reais, etc.) obtense
instanciando esta clase utilizando o tipo de valor como argumento.
Atributos:
name, identificador alfanumrico da caracterstica.
value, valor actual da caracterstica.
Asociacins:
precondition, condicin de validez da caracterstica.
valid values, conxunto de valores vlidos da caracterstica.

Valor vlido ("DeviceValidValue")
Esta clase representa un dos valores vlidos dunha caracterstica. Cada valor vlido ten
asociada unha condicin que indica cando aplicbel e un conxunto de valores discretos que
poden ser asignados caracterstica.
Asociacins:
precondition, condicin de aplicabilidade do valor.
values, conxunto de valores discretos que poden ser asignados caracterstica.

Valor ("IDeviceValue")
Interface abstracta da que derivan as clases utilizadas para representar os valores que poden
ser asignados a unha caracterstica.
Valor ("DeviceValue")
Clase parametrizada derivada de IDeviceValue. As clases que representan valores discretos
de diferentes tipos (booleanos, enteiros, reais, etc.) obtense instanciando esta clase utilizando
o tipo de valor como argumento. Os valores poden ser nicos, representados mediante a clase
DeviceSingleValue, ou estar contidos nun intervalo de valores vlidos, representado mediante a
clase Devicelnterval Value.
Condicin de validez ("DevicePrecondition")
Esta clase representa unha condicin de activacin ou validez que pode asociarse a
subsistemas, caractersticas ou valores vlidos. A condicin consiste nun conxunto de
caractersticas e dos valores que estas poden ter asignados para que a condicin sexa certa.
Asociacins:
characteristics, conxunto de caractersticas cuxos valores afectan ao cumprimento da

condicin de validez.
Referencia dunha caracterstica ("DeviceCharacteristicReference")
Esta clase representa cada caracterstica comprobada para avaliar o resultado da condicin
de validez.
303
Asociacins:
characteristic, referencia caracterstica cuxos valores afectan ao cumprimento da

condicin de validez.
values, conxunto de valores que a caracterstica pode ter para que se cumpra a condicin.
7.2.1.2.1. Exemplo de configuracin dun dispositivo de E/S
O cdigo seguinte mostra unha versin simplificada da implementacin do mtodo

buildDevicelnfo nun "driver" que controle a porta serie dun PC:
2373.DeviceInfo* COMDriver::buildDeviceInfo() const
2374. {
2375.
2376.
2377.
// informacin do dispositivo
DeviceLevel* comôrt = new DeviceLevel("COM1", IOPOINT, 1);
DeviceInfo* info = new DeviceInfo(comôrt);
2378.
2379.
// velocidade
2380.
2381.
2382.
DeviceCharacteristic<unsigned>*
baud_rate = new DeviceCharacteristic<unsigned>("Baud Rate", 9600);
comôrt->characs.insert(baud_rate);
2383.
2384.
// paridade
2385.
2386.
2387.
DeviceCharacteristic<bool>*
parity_check = new DeviceCharacteristic<bool>("Parity Check", true);
comôrt->characs.insert(parity_check);
2388.
2389.
// nmero de bits, 5-8
2390.
2391.
2392.
2393.
2394.
2395.
num_bits = new DeviceCharacteristic<unsigned>("Number of bits", 7);
DeviceValidValue* num_bits_wl = new DeviceValidValue();
DevicelntervalValue<unsigned>*
num_bits_vall = new DeviceIntervalValue<unsigned>(5, 8);
num_bits_wl->values.push_back(num_bits_vall);
2396.
2397.
2398.
2399.
num_bits->validValues.push_back(num_bits_wl);
comôrt->characs.insert(num_bits);
2400.
2401.
2402.
2403.
stop_bits = new DeviceCharacteristic<unsigned>("Stop bits", ONEBIT);
DeviceValidValue* stop_bits_wl = new DeviceValidValue();
DeviceSingleValue<unsigned>*
2404.
2405.
2406.
2407.
stop_bits_vall = new DeviceSingleValue<unsigned>(ONEBIT);
stop_bits_wi->values.push_back(stop_bits_vall);
stop_bits->validValues.push_back(stop_bits_wl);
2408.
2409.
DeviceValidValue* stop_bits_w2 = new DeviceValidValue();
DeviceSinglevalue<unsigned>*
2410.
2411.
stop_bits_va12 = new DeviceSingleValue<unsigned>(ONE5BITS);
stop_bits_w2->values.push_back(stop_bits_va12);
2412.
2413.
DevicePrecondition* stop_bits^rel = new DevicePrecondition();
DeviceCharacteristicReference*
2414.
2415.
2416.
2417.
2418.
2419.
stop_bits_refl = new DeviceCharacteristicReference(num_bits);
num bits^vall = new DeviceSingleValue<unsigned>(5);
stop_bits_refl->values.push_back(num_bits^vall);
stop_bits^rel->characteristics.insert(stop_bits_refl);
stop_bits_w2->setPrecondition(stop_bits^rel);
2420.
2421.
2422.
stop_bits->validValues.push_back(stop_bits_w2);
DeviceValidValue* stop_bits_w3 = new DeviceValidValue();
2423.
2424.
2425.
stop_bits_va13 = new DeviceSingleValue<unsigned>(TWOBITS);
stop_bits_w3->values.push_back(stop_bits_va13);
DevicePrecondition* stop_bits^re2 = new DevicePrecondition();
// bits de parada: 0,1,2
= 1,
1.5, 2
304
2426.
2427.
DeviceCharacteristicReference*
stop_bits_ref2 = new DeviceCharacteristicReference(num_bits);
2428.
2429.
2430.
2431.
2432.
2433.
DeviceIntervalValue<unsigned>*
num bits^val2 = new DevicelntervalValue<unsigned>(6,

stop_bits_ref2->values.push_back(num_bits^val2);
stop_bits^re2->characteristics.insert(stop_bits_ref2);
stop_bits_w3->setPrecondition(stop_bits^re2);
stop_bits->validValues.push_back(stop_bits_w3);
S);
'
2434.
2435. comôrt->characs.insert(stop_bits);
2436. return info;
2437. }
A porta serie modelada como un nico punto de E/S (lia 2376) con catro caractersticas
que permiten configuralo: a velocidade de transmisin (lias 2380-2382), o nmero de bits por
palabra (lias 2385-2387), o control de paridade (lias 2390-2397), e o nmero de bits de
parada utilizados (lias 2400-2433). O nmero de bits por palabra pode ser un valor entre 5 e 8,
o cal definido mediante un intervalo de valores vlidos (lias 2393-2396). Encanto ao nmero
de bits de parada utilizados poden ser 1, 1.5 ou 2. O valor 1.5 s pode seleccionarse se o
nmero de bits da palabra 5 e o valor 2 s se o nmero de bits diferente a 5. Ambas
condicins estn representadas mediante condicins de validez nas lias 2412-2419 e lias
2425-2432, respectivamente. Na Figura 7.12 mstrase o diagrama de obxectos da informacin
de configuracin creada polo cdigo anterior.
7.2.1.3. Lectura e escritura de valores
Os "drivers" da mquina virtual permiten ler e escribir valores directamente nos puntos de
E/S dun dispositivo mediante os mtodos readlOPoint e writelOPoint (lias 2366 e 2367).
Ambos mtodos reciben como argumento o identificador alfanumrico do punto de E/S, o
"buffer" que contn a informacin a escribir ou no que se almacenar a informacin lida, e o
tamao desta informacin. Ntese que estes mtodos non impoen restriccins no tipo de datos
lidos ou escritos, ser a base de datos da mquina virtual a que realice as conversins precisas,
como se explica en (7.3.1).
Os puntos de E/S son identificados mediante a sa rota de acceso ("path") na estructura
xerrquica da informacin de configuracin do dispositivo, que se forma de xeito semellante
rota de acceso dun arquivo na rbore de directorios dun sistema operativo. Por exemplo, a rota
Ìldd_b8i8oliodevicelbinputslbinputl' identifica un punto de E/S denominado binputl contido
no subsistema binputs do dispositivo iodevice descrito mediante a informacin de
configuracin cuxo identificador dd_b8i8o. Esta rota podera utilizarse para indicar unha
entrada dun dispositivo que proporcione oito entradas e oito sadas booleanas, por exemplo.
Ademais dos mtodos anteriores, os "drivers" da mquina virtual proporcionan outros tres
mtodos -ZistenlOPoint (lia 2368), receivedlOPoint (lia 2370) e stopListeninglOPoint (lia
2371^ que permiten realizar lecturas asncronas nun punto de E/S. O mtodo ZistenlOPoint
a versin asncrona do mtodo readlOPoint, este mtodo notifica a lectura dun valor ao
proceso que iniciou a operacin utilizando o mecanismo de notificacin asncrona (7.1.2.4.2).
Os outros dous mtodos serven, respectivamente, para consultar o estado e deter a lectura
asncrona dun valor.
305
^ > ^^
_' ^
^ ^ E
ffi
F
N
F>I
Ui
N
N
t
U
q
L
U
L
U
O
^
J
m
^ II
.^
^^ Î
c K

F_
m
^J >
>
>
>
a
.^
>
n
q
m
j O
^
0 p
m m
A
m
Y
^1 n
m m
^
n
n 11
aD m
O 11
^ ?
w
U-y
.. ^
m
m^
VO^
>
>
m a p ii
E g -d -
io
m
^ L
C ri m m
C C
^
`m
L
U
Figura 7.12. Diagrama de obxectos da informacin de configuracin dunha porta serie.
306
7.2.1.4. Asignacin de varibeis a puntos de E/S

Ademais da lectura e escritura de valores simples, os "drivers" da mquina virtual permiten
asignar as varibeis definidas nos modelos executados na mquina virtual a puntos de E/S nos
dispositivos. Esta asignacin permite facer un seguimento continuo das variacins nas entradas
dun proceso (indicando como parmetro a frecuencia da monitorizacin desexada) ou a
actualizacin automtica das sadas. Unha vez realizadas as asignacins e iniciadosd os
dispositivos de E/S, o intercambio de valores entre a mquina viriual e os "drivers" faise
utilizando o mecanismo de paso de mensaxes (7.1.2.4.1). Isto permite `desacoplar' o
funcionamento interno da mquina virtual dos aspectos relacionados coa implementacin da
lectura e escritura de valores nos dispositivos.
Cada "driver" xera mensaxes para as varibeis de entrada que lle foron asignadas ao ritmo
indicado pola frecuencia de monitorizacin. Estas mensaxes, que conteen os valores actuais
das varibeis, son enviadas mquina virtual. Do mesmo xeito a mquina virtual enva aos
"drivers" unha mensaxe para cada varibel de sada que sexa preciso actualizar. A velocidade
que os cambios nos valores das entradas son procesados e os valores das sadas producidos
depende do tempo de resposta da mquina virtual, dicir, o tempo que esta precisa para
calcular os valores das sadas a partir das entradas dacordo ao especificado nos modelos
executados no subsistema de aplicacin. Tal e como se explica no Captulo 8, este tempo
varibel, e en caso de ser superior ao ritmo de cambio das magnitudes do proceso pode
producirse un desbordamento nos canais da mquina virtual debido a que esta non pode
procesar todas as mensaxes xeradas polos "drivers". A posibilidade de especificar unha
frecuencia de monitorizacin na asignacin de varibeis de entrada a dispositivos de E/S
permite reducir en certa medida este problema. O valor dos tempos de monitorizacin
depender de cada proceso concreto e ser responsabilidade do deseador do sistema axustalos
para evitar o colapso da mquina virtual.
A asignacin de varibeis a puntos de E/S nos dispositivos realzase mediante os mtodos
schedule0utput (lia 2359) e schedulelnput (lia 2361). Ambos mtodos reciben como
argumento o identificador alfanumri o do punto de E/S e o identificador da varibel asignada.
No mtodo schedulelnput, que asigna unha varibel de entrada, psase ademais como
argumento o tamao do valor a monitorizar e a frecuencia de actualizacin na mquina virtual
(unha frecuencia igual a cero indica que o valor debe actualizarse cada vez que cambie). As
asignacins individuais a un punto de E/S elimnanse cos mtodos unschedule0utput (lia
2360) e unschedulelnput (lia 2363), que reciben como argumento o identificador alfanumrico
do punto de E/S. Tamn poden eliminarse todas as asignacins dun dispositivo utilizando 0
mtodo unscheduleAll (lia 2364).
A clase DeviceDriver, derivada de IDeviceDriver, proporciona unha implementacin por
defecto dos mtodos anteriores e do mecanismo que xestiona a monitorizacin das varibeis de
entrada e a actualizacin das de sada. Ademais esta clase tamn define das portas de enlace
que permiten establecer das conexins entre cada "driver" e a mquina virtual, unha para o
envo e outra para a recepcin de mensaxes. No resto deste apartado explcanse os detalles
desta implementacin.
7.2.1.4.1. Asignacin de varibeis a puntos de E/S
A clase DeviceDriver mantn informacin sobre as varibeis asignadas aos puntos de E/S do
dispositivo. A implementacin dos mtodos schedule0utput e schedulelnput controla que unha
mesma varibel non asignada a mis dun punto de E/S, que como moito se asigna unha
307
varibel a cada punto de E/S e que o punto de E/S ao que se asigna a varibel existe no
dispositivo.
7.2.1.4.2. Monitorizacin de varibeis de entrada
O mecanismo de monitorizacin de varibeis de entrada xera unha mensaxe co valor de cada

varibel de entrada asignada ao dispositivo ao ritmo indicado pola frecuencia de monitorizacin
da varibel. Estas mensaxes son enviadas mquina virtual a travs dunha das das portas de
enlace definidas por defecto para cada "driver". En funcin da frecuencia de monitorizacin as
varibeis de entrada son divididas en dous grupos:
1. As varibeis cuxo valor enviado mquina virtual cada vez que este cambia (a frecuencia
de monitorizacin igual a cero).
2. As varibeis cuxo valor enviado mquina virtual a intervalos regulares.
Ambos casos son tratados de forma diferente na implementacin da clase DeviceDriver. No
referente s varibeis do primeiro grupo, para cada unha delas iniciase unha lectura asncrona
no punto de E/S no que estea asignada utilizando o mtodo IistenlOPoint (lia 2368). Cando se
recibe unha notificacin procedente dalgunha das operacins de lectura asncrona iniciadas, o
"driver" comproba a que varibel corresponde, crea e enva unha mensaxe mquina virtual
contendo o identificador da varibel e o seu valor, e reinicia unha nova operacin de lectura
asncrona no punto de E/S no que a varibel estea asignada. Ntese que os detalles da deteccin
dun cambio no valor da varibel e a sa notificacin son manexados pola subclase derivada de
DeviceDriver que implemente o mtodo ZistenlOPoint, e dependern de cada dispositivo
concreto.
Para o manexo das varibeis do segundo grupo utilzase un temporizador (7.3.2) de xeito
que o"driver" reciba notificacins peridicas e determine en cada instante as varibeis cuxos
valores preciso actualizar. Na implementacin da clase DeviceDriver o temporizador
iniciado de xeito que se reciba unha notificacin cada vez que transcorra un tempo igual ao
mximo comn divisor (m.c.d.) dos perodos de monitorizacin das varibeis asignadas ao
dispositivo. Para cada notificacin recibida calclase o conxunto de varibeis a actualizar
como:
update_vars = {var ^ time mod T(var) = 0}
(7.1)
onde:
Tu(var), perodo de actualizacin da varibel.
time, tempo transcorrido dende a iniciacin do temporizador. Este tempo calculase como:
time = ticks * mcd
(7.2)
sendo:
ticks, nmero de notificacins recibidas.
mcd, m.c.d. dos perodos de monitorizacin das varibeis.
dicir, as varibeis a actualizar son aquelas cuxo periodo de monitorizacin un divisor do

tempo transconrido dende a iniciacin do temporizador.
Captulo 7: A mquina virlual
308
O seguinte exemplo mostra o clculo deste conxunto para a serie de notificacins recibidas
nun "driver" con catro varibeis de entrada asignadas con perodos de monitorizacin de 5, 5,
10 e 1 S mseg. respectivamente.
2438.// Valores iniciaia
2439.vars ={(vl, 5), (v2, 5), (v3, 10), (v4, 15)}
2440.ticks = 0
2441.time = 0
2442.mcd = 5
2443.mcm = 30
2444.ticks
= 1 //
2445.time = 5
2446.update_vars =
2447.ticks = 2 //
2448.time = 10
2449.update_vars =
2450.ticks = 3 //
2451.time = 15
primeira notificacin
{vl, v2}
segunda notificacin
{vl, v2, v3}
terceira notificacin
2452.update_vars = {vl, v2, v4}
2453.ticks = 4 // cuarta notificacin
2454.time = 20
2455.update_vars =
2456.ticks = 5 //
2457.time = 25
2458.update_vars =
2459.ticks = 6 //
2460.time = 30
2461.update_vars =
{vl, v2, v3}
quinta notificacin
{vl, v2}
sexta notificacin
{vl, v2, v3, v4}
Ntese que a serie anterior reptese cun perodo igual ao mnimo comn mltiplo dos
perodos de monitorizacin das varibeis (mcm = 30), polo que cando o nmero de
notificacins tal que o tempo transcorrido sexa igual a ese perodo (ticks = 6), pode reiniciarse
o seu valor e considerar que se volve situacin inicial. Na implementacin do algoritmo de
clculo do conxunto update_vars reduciuse o nmero de operacins necesarias ordenando as
varibeis dacordo ao seu perodo de monitorizacin e considerando en cada notificacin
unicamente aquelas que teen un perodo (valor de Tu) inferior ao tempo transcorrido dende a
iniciacin do temporizador (valor de time).
Unha vez determinado o conxunto de varibeis a actualizar o"driver" obtn os seus valores
dos puntos de E/S nos que estn asignadas utilizando o mtodo readlOPoint (lia 2366) e
envalle mquina virtual as mensaxes con estes valores a travs da porta de enlace
correspondente. A implementacin do mtodo readlOPoint faise nas subclases derivadas de
DeviceDriver e depender de cada dispositivo concreto. A tcnica descrita reduce o"overhead"
debido monitorizacin de varibeis, xa que:
1. A interaccin entre o temporizador e o"driver" redcese unicamente iniciacin do
temporizador e recepcin e procesamento no "driver" das notificacins do temporizador.
2. O clculo do conxunto de varibeis a actualizar require unicamente unha divisin e unha
comparacin por cada varibel cuxo perodo de monitorizacin sexa inferior ao tempo
transcorrido dende a iniciacin do temporizador.
Sen embargo presenta dous inconvenientes:

1. Cada "driver" utiliza un temporizador, que normalmente un recurso limitado.
2. Os perodos de monitorizacin das varibeis deben axustarse para que o seu m.c.d. sexa un
valor o suficientemente grande para non colapsar o"driver" con mis notificacins das que
poda procesar.
309
7.2.1.4.3. Actualizacin de varibeis de sada
A actualizacin dos valores das sadas realzase mediante a lectura sen bloqueo (7.1.2.4.1)
da porta de enlace do "driver" pola que se reciben as mensaxes enviadas pola mquina virlual.
Estas mensaxes conteen o identificador e valor da varibel de sada a actualizar. Cada vez que
se recibe unha mensaxe o"driver" comproba en que porta de E/S est asignada a^^ varibel e
escribe nela o novo valor utilizando o mtodo writelOPoint (lia 2367). A implementacin
deste mtodo faise nas subclases derivadas de DeviceDriver e depender de cada dispositivo
concreto.
7.2.2. Xestin da E/S

A interface entre o ncleo da mquina virtual e os "drivers" de E/S xestionada mediante
dous procesos: o xestor de entradas e o de sadas. Como mostra a Figura 7.13 cada xestor
mantn conexins cos "drivers" de dispositivo e coa mquina virtual para o intercambio de
mensaxes. O xestor de entradas ten das portas de enlace, unha a travs da que se reciben as
mensaxes dos "drivers" de E/S cos valores das varibeis de entrada do proceso e outra pola que
se encamian estas mensaxes cara mquina virtual. Pola sa banda o xestor de sadas recibe
por unha porta de enlace as mensaxes da mquina virtual cos valores das varibeis de sada a
actualizar e encamaas ao dispositivo correspondente utilizando unha porta de enlace por cada
"driver" de sada.
Mquina Virtual
f
porta de sada^
Mquil virtual
porta entrada ^
Xestor Entrada
porta de entrada
"driver" "driver" "driver"
entrada entrada entrada
"driver" "driver" driver"

sada
safda
sada
(a)
(b)
Figura 7.13. Conexins dos xestores de E/S da mquina virtual.
O seguinte cdigo mostra a declaracin da interface abstracta IIOMgr que implementan os

xestores de E/S:
2462.struct IIOMgr
2463. {
// control do estado
2464.
virtual void Start() = 0;
2465.
virtual void Suspend() = 0;
2466.
virtual void Resume ( ) = 0 ;
2467.
virtual void Finish() = 0;
2468.
virtual bool isSuspended() = 0;
2469.
virtual bool isRunning() = 0;
2470.
^
// portas de enlace
2471.
2472.
virtual bool isValidPort(const string& port, bool& state) = 0;
virtual bool isConnected(const string& port, bool& state) = 0;
2473.
virtual bool connect(const string& port, VMChannel* channel) = 0;
2474.
virtual bool disconnect(const string& port) = 0;
2475.
virtual bool getConnection(const string& port, VMCharmel* charmel) = 0;
2476.
2477 . } ;
310
Como pode comprobarse esta interface coincide coa interface pblica dos procesos da
mquina virtual (7.1.2.1). A Figura 7.14 mostra o diagrama das clases derivadas de IIOMgr
que son utilizadas para a implementacin dos xestores de E/S. A sa implementacin por
defecto proporcionada pola clase IOMgr utilizando os mtodos derivados da clase
VMProcess. A clase IOMgr crea no seu constructor a porta de enlace para a recepcin de
mensaxes que teen en comn tanto os xestores de entrada como os de sada e implementa o
mecanismo de recepcin de mensaxes. Ademais a clase IOMgr declara un mtodo que
invocado cada vez que unha mensaxe recibida. Este mtodo tipo protected e ser redefinido
polas subclases para implementar comportamentos especficos. A sa declaracin a seguinte:
2478.class IOMgr : public ^7MProcess, public IIOMgr
2479. {
2480.protected:
2481. virtual bool onlnputMessage(IVMMsg* msg) = 0;
2482 . } ;
Figura 7.14. Diagrama das clases que modelan os xestores de E/S.
A clase abstracta IIMgr utilizada como clase base dos xestores de entrada e no seu
constructor crease a porta de enlace utilizada para a conexin do xestor coa mquina virtual. En
canto s clases IMgr e OMgr, son as que proporcionan as implementacins por defecto do
mtodo onlnputMessage (lia 2481) para os xestores de entrada e sada, respectivamente. Esta
implementacin se encarga de encamiar as mensaxes recibidas porta de enlace de sada que
corresponda, dacordo do tipo de xestor do que se trate.
A clase OMgr implementa ademais o manexo das portas de enlace utilizadas para conectar o
xestor aos "drivers" de sada. Esta clase redefine os mtodos connect (lia 2014) e disconnect
(lia 2015) de xeito que as portas de enlace son creadas e destrudas dinamicamente cada vez
que se realiza ou elimina unha conexin entre o xestor e os "drivers" de sada. Cada porta de
enlace creada dinamicamente identificase co nome do "driver" ao que estea conectada. Este
identificador utilzase para determinar a qu porta de enlace enviar as mensaxes recibidas polo
xestor de sadas (cada mensaxe contn o nome e valor da varibel a actualizar e o identificador
do "driver" de sada no que est asignada).
Os xestores implementados polas clases IMgr e OMgr unicamente proporcionan a
funcionalidade de encamiar as mensaxes intercambiadas entre a mquina virtual e os
dispositivos de E/S. Sen embargo derivando novas clases das explicadas anteriormente
posbel implementar xestores que proporcionen outras funcionalidades adicionais, como por
exemplo:
311
1. O rexistro das mensaxes intercambiadas para a anlise posterior do funcionamento do

sistema.
2. A utilizacin de secuencias de mensaxes de entrada preestablecidas (escenarios) para a
simulacin e a anlise da resposta do sistema.
3. O filtrado e a asignacin de prioridades s mensaxes.
Ntese que os xestores de E/S derivan da clase IModule (7.1.1.1), polo que poden ser
substitudos en tempo de execucin utilizando a tcnica explicada en (7.1.1.5) para cargalos e
descargalos dinamicamente en memoria dende unha DLL.
7.2.3. Simulacin de E/S

A incorporacin dalgn mecanismo co que se poidan simular as entradas do proceso externo
e rexistrar os valores de sada producidos como resposta permite utilizar a mquina virtual en
diferentes funcins, como por exemplo:
1. A verificacin mediante simulacin do comportamento do sistema de control antes da sa
posta en funcionamento.
2. A utilizacin conxunta de subprocesos reais e simulados para analizar a repercusin de
futuros cambios no sistema.
3. A anlise da resposta do sistema ante secuencias de entradas preprogramadas (escenarios)
para optimizar a sa resposta.
Na arquitectura proposta para a mquina viriual (Figura 7.8) posbel incorporar un
mecanismo de simulacin de E/S utilizando das tcnicas diferentes:
1. Substitundo os xestores de E/S (7.2.2) bsicos por outros que permitan a utilizacin de
entradas simuladas e o rexistro das sadas.
2. Proporcionando "drivers" (7.2.1) que simulen os dispositivos de E/S.
Tanto os xestores coma os "drivers" de E/S son procesos que implementan a interface
IModule (7.1.1.1), polo que poden ser cargados e descargados dinamicamente na memoria da
mquina virtual. Mediante a definicin das configuracins (7.1.1.2) axeitads ser posbel
alternar entre o modo de simulacin e o de execucin sen que sexa preciso deter a mquina
virtual. A Figura 7.15 mostra exemplos de configuracins de simulacin que utilizan as das
tcnicas indicadas anteriormente. Ntese que ambas tcnicas non son excluntes e poderan
combinarse.
No resto deste apartado detllase o mecanismo que se definiu para o intercambio da
informacin de simulacin entre os mdulos da mquina virlual e os simuladores remotos,
explcase a implementacin do mecanismo de simulacin nun ambiente distribudo sobre redes
TCP/IP, e descrbese a implementacin dun "driver" xenrico para utilizar en configuracins
que apliquen a segunda das tcnicas indicadas.
7.2.3.1. O intercambio de informacin de simulacin
No deseo do mecanismo para o intercambio de informacin entre a mquina virtual e os
simuladores remotos tivronse en conta os seguintes requisitos:
1. Deber ser posbel utilizar diferentes simuladores simultaneamente. Os simuladores
podern enviar valores de entrada simulados e/ou recibir valores de sada, e podern ser
312
tanto aplicacins especficas como formar parte de ambientes de simulacin ou

visualizacin (p.e. LabView, HP VEE, Excel, etc.).
2. Tanto a informacin intercambiada como o protocolo de comunicacin deben ser simples.
3. O intercambio de informacin debe ser independente do medio de comunicacin utilizado,
e poder ser implementado utilizando diferentes protocolos de comunicacin (p.e. DDE,
OPC, TCP/IP, etc.).
O cumprimento destes requisitos permite a utilizacin do mecanismo de simulacin en
configuracins distribudas heteroxneas nas que se utilicen diferentes aplicacins de
simulacin e visualizacin interactuando mediante diferentes sistemas de comunicacin (Figura
7.16).
Mquina virtuaf
Mquina virtual
Xestor sada
(simulacin)
Xestor entrada
(simulacin)
Valores de
sada
Entradas
simuladas
.........N
^^
Secuencias
pregrabadas
Simulador remoto
"Driver" de
entrada
"Driver" de Driver" d
sada
simulacin
"Driver" de
safda
Valores de
safda
^^.........^ Simulador remoto ........^
^^
Rexistro das
Secuencias
sadas
pregrabadas
(b)
Entradas
simuladas
.^
Rexistro das
sadas
(a)
Driver" de
entrada
Figura 7.15. Tcnicas para a simulacin de E/S na mquina viriual: a) utilizando un xestor de E/S; e b) utilizando
un "driver".
r----------'---------------^
Vsualizacin sadas i
(p.e. Excel)
Simulacin proceso
(p.e. Matlab)
DDE
DDE
i
Visualizador sadas
(p.e. HP VEE)
Mquina virtual
OPC
UDP
TCPfl P
Simulacin entradas e ^
Mquina virtual
animacin do proceso Conexion;
(p.e. LabView)
en sene ^---
Figura 7.16. Exemplo dun ambiente de simulacin distribudo.
7.2.3.1.1. Modelado do intercambio de informacin de simulacin
Os participantes nun ambiente como o mostrado na Figura 7.16 poden clasificarse en das
categoras non excluntes dependendo do seu papel no intercambio de informacin de
simulacin:
l. Os productores de valores de entrada simulados (p.e. simuladores de paneis de operador,
simuladores de proceso, etc.).
2. Os consumidores de valores de sada (p.e. animacins grficas do estado do proceso,
aplicacins de anlise de datos, etc.).
313
O intercambio de informacin pode, polo tanto, modelarse como unha interaccin entre un
conxunto de productores e consumidores de valores de simulacin. Esta interaccin estar
regulada por un mediador [67] que cumprir das funcins:
1. Proporcionar un punto de acceso coecido no ambiente distribudo ao que os productores e

consumidores poden conectarse para enviar e recibir valores.
^
2. Distribur cada valor enviado polos productores entre os consumidores que solicitaron
recibilo. Para reducir o nmero de mensaxes intercambiadas os consumidores indicarn, no
momento de conectarse ao mediador, as varibeis que queren recibir. Deste xeito 0
mediador unicamente reenviar cada valor recibido aos consumidores interesados.
A utilizacin dun mediador permite manexar de maneira transparente diferentes
configuracins no intercambio de datos, por exemplo:
1. O mediador proporciona un punto de acceso coecido nico ao que se conecten
productores e consumidores utilizando o mesmo protocolo de comunicacins.
2. O mediador proporciona un ou mis puntos de acceso coecidos tanto aos productores
como aos consumidores. Neste caso poden utilizarse protocolos de comunicacin
diferentes.
Ntese ademais que nun ambiente distribudo poden coexistir mltiples mediadores e que
sera tamn posbel utilizar configuracins nas que un mediador se conecte a outro como
productor ou consumidor. Na Figura 7.17 mstrase unha posbel implementacin da
configuracin da Figura 7.16 utilizando o patrn Productor/Mediador/Consumidor.
i
DDE
r---------------------------------,
Vsualizador sa(das i
^
(consumidor)
.
UDP
OPC
aimwaaon emraaas e ^
DDE ^ Mediador
Mquina virtual
; (productor/consumidor)
animacin do proceso ^ti

^^
i
(productor/consumidor) ; Conxin
; en sjerie
'
'----------------------------------------'
Mediador
;
;
TCPflP
z
Mediador
Visualizacin sadas
(consumidor)
---------------------------^
Simulacin proceso
(productor)
,
UDP
Mquina virtual
( produ ctor/consumidor)
Figura 7.17. Ambiente de simulacin distribudo utilizando o patrn Productor / Mediador / Consumidor.
7.2.3.1.2. O formato das mensaxes
A Figura 7.18 mostra a estructura dos dous tipos de mensaxes utilizadas no intercambio de
informacin de simulacin. O primeiro tipo de mensaxe enviado por cada participante no
momento de conectarse ao mediador, e est formado polos seguintes campos:
1. Un indicador booleano (1 byte) que indica se o participante quere recibir valores.
2. Un indicador booleano (1 byte) que indica se o participante vai enviar valores.
3. Os nomes das varibeis das que o participante quere recibir valores.
O segundo tipo de mensaxe o utilizado para intercambiar os valores simulados, e est
formado polos seguintes campos:
1. O nome da varibel.
2. O tamao do valor da varibel (4 bytes).
3. O valor da varibel.
314
Parmetros da
simulacin
recv?
send?
Valores de
simulacin
var
name
value
size
var 1
name
var 2
name
var_N
name
value
size
Figura 7.18. Formato das mensaxes utilizadas para o intercambio de informacin de simulacin.
7.2.3.1.3. O protocolo de intercambio de informacin
A Figura 7.19 mostra un exemplo do protocolo de comunicacin utilizado para o

intercambio de informacin de simulacin. Cada participante se conecta a un mediador
enviando unha mensaxe do primeiro dos tipos explicados no apartado anterior, coa que indica
se vai a enviar e/ou recibir valores e que valores quere recibir. Os valores son intercambiados
utilizando mensaxes do segundo tipo. Os participantes que simulan valores de entrada envan
estes valores ao mediador que se encarga de distribulas entre os participantes que solicitaron
recibir eses valores.
:Simulador
:Simulador
:Mediador
:Virtual Machine
recv? send? var 1.__._ var_N
recv?
send?
var 1 ...__. var N

var 4 value (4 bytes)

recv? send? var 1...___ var N

Figura 7.19. Secuencia de mensaxes do protocolo de intercambio de informacin de simulacin.
7.2.3.2. Modelado dun mediador xenrico

A Figura 7.20 mostra o diagrama das clases definidas para representar a estructura dun
mediador. A clase abstracta ISimulationServer declara a interface comn a todos os mediadores
utilizados na simulacin. O cdigo da declaracin desta interface o seguinte:
2483.struct ISimulationServer
2484. {
2485. virtual void onReceive(ISimulationLinkPoint* link,
2486.
const SimulationDataSeq& data) = 0;
2487. virtual bool buildLinkPoints(ISimulationServer* server) = 0;
2488 . } ;
Esta interface declara os mtodos onReceive (lia 2485), que ser invocado cada vez que se
reciban valores simulados a travs dalgunha das conexins abertas do mediador, e
buildLinkPoints (lia 2487), mtodo utilizado para crear os puntos de acceso do mediador. Os
315
puntos de acceso son creados invocando este mtodo durante a iniciacin do mediador e
suponse que non se modifican durante a vida deste. Poderan definirse mediadores que
permitiran a construccin e destruccin dinmica dos puntos de acceso mediante a utilizacin
de mtodos constructores ("factory methods" [67]) en clases derivadas de ISimulationServer.
ISimulationServer I
^ mediator linkôint
connection end
ISimulat ionLinkPoint
ISimulationSenrice
linkôint
Figura 7.20. Diagrama das clases utilizadas para modelar un mediador.
Os puntos de acceso do mediador coecidos polos participantes na simulacin son

representados mediante a clase abstracta ISimulationLinkPoint. O cdigo que declara esta
interface o seguinte:
2489.class
2490. {
ISimulationLinkPoint
2491.protected:
2492. virtual void addConnection(ISimulationService* service) = 0;
2493.
virtual void removeConnection(ISimulationService* service) =
2494.public:
2495. virtual void onReceive(ISimulationService* service) = 0;
2496. virtual void onDisconnect(ISimulationService* service) = 0;
2497. virtual void broadcastData(const SimulationDataSeq& data) =

2498. } ;
0;
0;
Os mtodos addConnection (lia 2492) e removeConnection (lia 2493) son utilizados para
engadir e eliminar conexins entre o mediador e os participantes; onReceive (lia 2495) e
onDisconnect (lia 2496) son mtodos pblicos invocados dende as conexins para procesar a
recepcin de datos e a finalizacin da conexin, respectivamente; e finalmente, o mtodo
broadcastData (lia 2497) invocado dende o mediador para enviar datos a todas as conexins
dun punto de acceso.
Por ltimo, a clase abstracta ISimulationService modela cada conexin establecida entre o
mediador e os participantes. Esta interface declara mtodos que sern invocados dende o punto
de acceso para o envo e recepcin de valores:
2499.struct ISimulationService
2500. {
virtual bool getPendingData(SimulationDataSeq& data) =
0;
2502. virtual void sendData(const SimulationDataSeq& data) =

2503 . } ;
0;
2501.
7.2.3.3. Implementacin dun mediador en redes TCP/IP

A Figura 7.21 mostra o diagrama das clases utilizadas na implementacin dun mediador que
permite intercambiar datos de simulacin entre unha ou mis mquinas virtuais e diferentes
simuladores remotos utilizando o protocolo TCP/IP. Este mediador un proceso "multithread"
que proporciona dous puntos de acceso ("sockets"), nun deles se conectan os simuladores e
noutro as mquinas virtuais. O mediador encrgase de enviar os valores de cada varibel
recibidos polas conexins dun "socket" s conexins do outro que solicitaran recibir valores
desa varibel.
ISimulationSeroer
316
Thread
linkôint
ISimulationLinkPoint
(from Common C++
TCPSimulationServer
address : InetHostAddress I server
vmport : tpport_t
procport : tpport_t
TCPSocket
(from Common C++)
connection end
1
TCPSimulationLinkPoint
ISimulationSenrice
vm side
process_side
TCPSession
(from Common C++)
_Mutex_
data
TCPSimulationSerrice
(from Common C++)
params
send_buf
SimulatonDataQueue
Simulation0ata
name : string
size : unsigned
value : char[]
_ recv_buf
t
SimulationParameters
receive : bool
send : bool
var ids : list<string>
Figura 7.21. Diagrama das clases utilizadas para implementar o mediador TCP/IP.
O mediador unha instancia da clase TCPSimulationServer, que deriva da clase Thread da

librara Common C++ ( 1.3.2). As instancias desta clase son "threads" que implementan a
interface ISimulationServer e proporcionan dous puntos de acceso -agregacins vm_side e
process_side- para a conexin dos participantes na simulacin. Os puntos de acceso son
instancias da clase TCPSimulationLinkPoint, que deriva das clases TCPSocket e TCPThread da
librara Common C++. Cada punto de acceso , en consecuencia, un servidor TCP que
implementa a interface ISimulationLinkPoint. As conexins con estes servidores son
manexadas por instancias da clase TCPSimulationService, que deriva da clase TCPSession da
librara Common C++. Cada instancia desta clase , polo tanto, un "thread" que manexa unha
conexin entre dous "sockets". En cada conexin se almacenan os parmetros de configuracin
enviados polo participante ao conectarse -agregacin params- e mantense das colas cos
valores recibidos e os pendentes de enviar a travs da conexin -agregacin data-.
A Figura 7.22 mostra a secuencia de mensaxes intercambiados entre un simulador, o
mediador e unha mquina virtual para o establecemento de conexins e o intercambio de
valores de simulacin. Como complemento deste mediador creouse un VI74 en LabView que
permite simular paneis de E/S booleanas e intercambiar os seus valores co mediador TCP/IP.
^4 Os detalles da implementacin deste VI non foron incluidos como parte desta documentacin.
317
^
i^
^Q^ ^ ^
g
b
$^L
i^
^n
^
asy ê i:
^
i
0 ^^
^^
^^ ^ ^ i
^
^
.^ ^
i
^ ^
5 ^^-^ i
9
^ 6 ^ ^ I
@ S ^ ^ ^
^ ^ ^^^^ i
^ II^ ^ i
L ^ ^ ;
vj
^;
;^
Figura 7.22. Secuencia de mensaxes do intercambio de informacin de simulacin utilizando un mediador TCP/IP.
318
7.2.3.4. Implementacin dun simulador de dispositivos de EIS

Como parte da mquina virtual incluuse a implementacin dun simulador de dispositivos de
E/S que intercambia valores a travs dunha rede TCP/IP e que pode ser utilizado
conxuntamente co mediador explicado no apartado anterior. Este simulador implementado
como un "driver" que mantn unha conexin cun servidor TCP remoto e mediante o que poden
simularse calquera nmero de entradas e sadas. A Figura 7.23 mostra o diagrama das clases
utilizadas.
IDeviceDriver
(from Device Driver)
VMProcess
(from Proceaes)
DeviceDriver ^
(from Devioe Driver)
DriverSimulator
inputs : unsigned
outputs : unsigned
buildService( )
IDriverService
simulator
service onReceive( )
data
params
VMProcess
(lrom Proceses)
_Mutex_
(from Common C++)
TCPDriverSimulator
address : InetHostAddress
port : tpport_t
buildService( )
data
^
SimulatonDataDueue
recv_buf
d buf',
SimulationData -sen
TCPStream
name : string
size : unsigned
value : char[]
(from Common C++)
TCPDriverSenice
SimulationParameters
1
DriverSeroice
receive : bool
send : bool
var_ids : list<string>
Figura 7.23. Diagrama das clases utilizadas para a implementacin dun "driver" TCP/IP de simulacin.
A clase DriverSimulator, derivada de DeviceDriver (7.2.1), a que implementa o

simulador dos dispositivos de E/S. O constructor desta clase recibe como parmetro o nmero
de entradas e sadas a simular, polo que as sas instancias permiten simular dispositivos de
diferentes tamaos no que a entradas e sadas se refire. A conexin do "driver" co mediador
remoto representada mediante a clase abstracta IDriverService. Para manter a implementacin
do "driver" independente do sistema de comunicacin utilizado, na clase DriverSimulator
declrase un mtodo constructor virtual ("factory method" [67]), que ser redefinido nas clases
derivadas e que devolver unha instancia dunha clase derivada da interface IDriverService. Por
exemplo, a clase TCPDriverSimulator devolve unha instancia da clase TCPDriverService que
un proceso da mquina virtual que xestiona unha conexin cun servidor TCP remoto.
A clase DriverService proporciona a implementacin por defecto dun proceso da mquina
virtual que xestione unha conexin cun mediador remoto e a comunicacin co simulador do
dispositivo de E/S. Esta comunicacin realzase mediante o intercambio de valores a travs de
319
colas e a notificacin asncrona (7.1.2.4.2) da recepcin de valores na conexin -mtodo

onReceive-. As colas de valores recibidos e os pendentes de enviar son almacenados polas
instancias da clase DriverSimulator -agregacin data-, xunto cos parmetros de
configuracin a enviar ao mediador no establecemento da conexin -agregacin params-.
As instancias da clase TCPDriverSimulator reciben apuntadores a esta informa in como
argumentos do mtodo buildService (Figura 7.23) cando establecida a conexin co mediador
remoto.
A Figura 7.24 mostra a secuencia de mensaxes intercambiadas entre o simulador de
dispositivo, o proceso que xestiona a conexin co mediador e o propio mediador para o
establecemento da conexin e o intercambio de valores de simulacin.
:TCPDriverSimulator
St^^
^buildService(params, data)
create ( address, port, params, data, this)
---------------------------------------------------------------------+^ :TCPDriverService
Start()
params = true, true,'varl', ..,'varN'

--------------------------------------------------------------------+i
vrtitelOPoint(iopoint, value, size)
iopoints[opoint].value = value
iopoints[opoint].size = size
data.send_buf. push_back(iopoints[iopoint])
Run()
values = data.send_buf
send_buf.dearQ
['for all value (v) in values]
v.name, v.size, v.value
^--------------------------------------------------------------*
- -
onReceive()
'a', 2, [valor]
--
- - -------------------
value = P datos rebidos '/

data.rew_buf.push back(value)
notifiqtion
onHandlerQ
values = data.rew buf
data.re^ buf.dear()
/' Procesar valores redbidos '/
^
Figura 7.24. Secuencia de mensaxes do intercambio de informacin de simulacin utilizando un "driver" TCP/IP.
7.2.3.4.1. Implementacin da interface IDeviceDriver
Dos mtodos da interface IDeviceDriver, a clase DriverSimulator implementa os utilizados

para crear a informacin de configuracin do dispositivo (7.2.1.2) e ler e escribir valores
(7.2.1.3); e redefine os implementados pola clase DeviceDriver para xestionar a asignacin de
varibeis a puntos de E/S (7.2.1.4). A continuacin danse algns detalles sobre a
implementacin destes mtodos.
Creacin da informacin de configuracin do dispositivo
A implementacin do mtodo buildDevicelnfo crea unha informacin de configuracin que
define un dispositivo formado por dous subsistemas, denominados input_channels e
output_channels respectivamente. O primeiro conter as definicins dos puntos de entrada e o
segundo as de sada. En cada subsistema engadirase un nmero de puntos igual ao valor dos
atributos inputs e outputs iniciados no constructor do simulador do dispositivo. Os
identificadores dos puntos sern input_channel_N para as entradas e output_channel_N para as
tanto
identificador completo
Polo
o
de entrada seria
sadas.
dun punto
320
` I l ddsim l iodevicel input_channels l input_channel_n'. Na versin actual do simulador non se

define ningunha caracterstica asociada aos subsistemas ou aos puntos de E/S. En futuras
versins poderan utilizarse, por exemplo, para restrinxir o tipo de datos das varibeis asignadas
aos puntos de E/S.
Asignacin de varibeis a puntos de E/S
Como se mostra na Figura 7.25, a clase DriverSimulator mantn internamente dous mapas,
un con informacin sobre as varibeis asignadas a puntos de E/S -agregacin vars-, e outro
cos ltimos valores recibidos ou enviados en cada punto de E/S que tea unha varibel
asignada -agregacin iopoints-. Os mtodos que modifican a asignacin de varibeis a
puntos de E/S (schedulelnput, schedule0utput, unschedulelnput, unschedule0utput, e
unscheduleAll) son redefinidos de xeito que se mantean correctamente actualizados estes
mapas cada vez que se realice ou elimine unha asignacin.
SimulationData
name : string
size : unsigned
value : char[j
#Aop
'l
iopoint_name : string
DriverSimulator
Akars
âr_name : string
AssignedVarlnfo
iopoint : string
value : +roid'
size : unsigned
clbk_arg : void'
Figura 7.25. Diagrama de clases para a asignacin de varibeis no "driver" de simulacin.
Lectura e escritura de valores

Os mtodos de lectura e escritura de valores non acceden directamente conexin co
mediador remoto, senn que se utilizan os datos almacenados nos mapas do simulador (Figura
7.25) para implementar a lectura sncrona e asncrona e as colas de comunicacin coa conexin
(Figura 7.23) para a escritura de valores. O pseudocdigo seguinte mostra a implementacin do
mtodo IistenlOPoint, que almacena no mapa vars a informacin precisa para realizar unha
notificacin asncrona cando se reciba un valor no punto de E/S indicado:
2504.DriverSimulator::listenIOPoint(const string& iopoint_name,
void* value,
2505.
unsigned size,
2506.
pfn callback,
2507.
IAsyncClbkArg* clbk_arg)
2508.
2509. {
2510. // obter varibel asigaada ao punto de E/S
2511. iopoint_info = iopoints[iopoint_name]
2512. var_info = vars[iopoint_info->name]
2513. // almaceaar informacin para a notificacia asacrona
2514. var_info.clbk_arg = clbk_arg
var_info.value = value
2515.
var_info.size = size
2516.
2517. }
Os mtodos stopListeninglOPoint e receivedlOPoint tamn acceden informacin da

varibel asignada ao punto de E/S indicado, que almacenada no mapa vars, para iniciala e
para consultar se o valor do atributo value foi modificado, respectivamente. O procesamento
dunha lectura asncrona compltase cando se recibe un valor para a varibel asignada na porta
de E/S. Cando isto acontece, a notificacin asncrona recibida dende o proceso que xestiona a
conexin co mediador (Figura 7.24) manexada no mtodo onHandler (lia 2033) do
simulador, que ten o pseudocdigo seguinte:
321
2518.DriverSimulator::OnHandler(void* arg)
2519. {
2520.
2521.
2522.
2523.
2524.
2525.
2526.
2527.
2528.
2529.
2530.
2531.
2532.
2533.
2534.
2535. }
// copiar valorea recibidoa da cola de entrada a un "buffer^ local
data.EnterMutex()
sim_values = data.recv_buf
data.recv_buf.clear()
data.LeaveMutex()
// almacenar valorea recibidos ao mapa i opointa
for each sim_value in sim_values
var_info = vars[sim_value.name]
iopoints[var_info.iopoint] = sim_value
// realizar aotificacin aencrona ae estivera activada
if (var info.clbk_arg)
var info.value = sim_value.value
DeviceDriver::OnHandler(var_info.clbk_arg)
end if
end for
A implementacin deste mtodo comeza copiando os valores recibidos dende o mediador

(que estarn almacenados na cola recv_bu^ a un "buffer" local. Despois, cada valor recibido
almacenado no mapa iopoints, no elemento correspondente ao punto de entrada no que a
varibel estea asignada. Por ltimo, se estivera activada a lectura asncrona da varibel, copiase
o valor recibido ao "buffer" pasado como argumento na chamada ao mtodo IistenlOPoint. A
notificacin procesada no mtodo onHandler da clase DeviceDriver, que enva unha mensaxe
co valor recibido porta de sada do simulador de dispositivos.
No caso de non estar activada a lectura asncrona, o valor recibido ser recuperado cando se
invoque o mtodo readlOPoint. O pseudocdigo deste mtodo o seguinte:
2536.DriverSimulator::readIOPoint(const string& iopoint_name,
void* value,
2537.
unsigned size)
2538.
2539. {
// recuperar valor almacenado no mapa oponts
2540.
iopoint_info = iopoints[iopoint_name]
2541.
2542.
value = iopoint_info.value
2543. }
No referente escritura de valores, a implementacin do mtodo writelOPoint almacena o

valor a enviar no mapa iopoints e na cola send_buf, da que sern lidos polo proceso que
xestiona a conexin co mediador. O pseudocdigo deste mtodo o seguinte:
2544.DriverSimulator::writeIOPoint(const string& iopoint_name,
void* value,
2545.
unsigned size)
2546.
2547. {
2548.
2549.
2550.
// almacenar valor no mapa opoints
iopoint_info = iopoints[iopoint_name]
iopoint_info.value = value
2551.
2552.
2553.
2554.
2555.
iopoint_info.size = size
// copiar valor na cola de sada
data.EnterMutex()
data.send_buf.push_back(iopoints[iopoint_name])
data.LeaveMutex()
2556. }
322
7.3. O ncleo da mquina virtual

O ncleo da mquina virtual (Figura 7.8) est formado pola base de datos de E/S, os
procesos que xestionan os temporizadores e o depurador. Nesta seccin se explican os detalles
do deseo e implementacin da base de datos de E/S (7.3.1), os temporizadores (7.3.2) e os
servicios que o ncleo proporciona s aplicacins executadas no subsistema de aplicacin
(7.3.3). Os detalles do depurador non se incluron nesta documentacin -na versin actual a
sa nica funcin o envo, a travs dun enlace de comunicacin, da situacin do modelo
Grafcet en execucin utilizando o formato explicado en (F.4.5}-.
7.3.1. A base de datos de E/S

A base de datos o proceso da mquina virtual que almacena os valores das varibeis do
proceso, xa sexan estes simulados ou obtidos mediante "drivers" de E/S. Como pode verse na
Figura 7.26, a base de datos dispn de catro portas de enlace a travs das que recibe e enva
mensaxes aos xestores de E/S (7.2.2) e ao subsistema de aplicacin (7.5).
Subsistema de Aplicacin
^n
Base de datos
de E/S
r,t
Xestores E/S
Figura 7.26. Estructura da base de datos de E/S.
7.3.1.1. Funcionalidades da base de datos de E/S

As funcionalidades que a base de datos de E/S proporciona son as seguintes:
1. Mantn un rexistro histrico dos valores das varibeis. Cada valor almacenado xunto coa
hora e data na que se obtn e pode confgurarse o nmero de valores histricos a almacenar
para cada varibel.
2. Contn a imaxe actual do proceso, consistente en das tboas cos valores das entradas e
sadas que unicamente se actualizan cando se recibe unha peticin de sincronizacin dende
o subsistema de aplicacin. As mensaxes recibidas pola base de datos contendo novos
valores para as varibeis do proceso unicamente afectan imaxe do proceso cando se
realice esa sincronizacin.
3. Mantn un "buffer" de entrada e outro de sada, nos que as mensaxes son almacenadas ata
que se reciba unha peticin de sincronizacin co proceso.
4. Encrgase de xerar os eventos que indican os cambios de valor nas entradas booleanas do
proceso.
7.3.1.2. Implementacin da base de datos de E/S
O diagrama de clases da Figura 7.27 mostra as clases e as relacins utilizadas na
implementacin da base de datos. A clase principal a denominada IORTDB, derivada de
VMProcess, que contn das colas de mensaxes -agregacins input_messages e
output_messages-, os valores das varibeis do proceso -agregacins inputs e outputs- e as
imaxes do proceso utilizadas durante a evolucin ds modelos executados no subsistema de
aplicacin -agregacins input_image e output_image-. As imaxes do proceso son
323
Seccin 7.3: O ncleo da mquina viriual
representadas mediante instancias da clase IORTDBSnapshot, que unha coleccin de

varibeis obtida por especializacin da clase parametrizada pdcid2ptrSeq ( B.1). Do mesmo
xeito as varibeis de proceso son almacenadas nunha instancia da clase IORTDBEntrySeq, que
unha coleccin de instancias derivadas da interface IIORTDBEntry, obtida igualmente por
especializacin da clase parametrizada pdcid2ptrSeq.
a
A clse IORTDBEntry, derivada da interface IIORTDBEntry, unha clase parametrizada
que representa as entradas da base de datos. As instancias desta clase son parametrizadas co
tipo de datos da varibel que almacenan. Haber unha entrada por cada varibel contida na base
de datos. Para cada varibel almacenase o seu valor actual -agregacin process_var-, o
rexistro de valores histricos -agregacin history_values-, os identificadores alfanumricos
do "driver" e do punto de E/S no que a varibel estea asignada -atributos ddriver id e
iopoint_id, respectivamente-, e o numero de valores histricos a almacenar -atributo
num_values-. O valor actual e os valores histricos son representados mediante instancias
obtidas por especializacin dos "templates" GescaSystemVar e TimedValue (B.2), utilizando
como argumento o tipo de datos da varibel almacenada.
O cdigo seguinte mostra unha versin simplificada da declaracin da interface pblica da
clase IORTDB:
2557.class IORTDB : public VMProcess
2558. {
2559.public:
2560. // engadir e eliminar entradas da BD
2561. bool isEmpty() const;
2562. bool insert(ISystemDataDeclaration* var_decl);
2563. bool remove(const string& var);
2564. bool removeAll();
2565. // sincronizacin co proceso
2566.
2567.
bool getInputEvents(MsgBuffer& events);
bool synchronizeInputs();
2568.
bool synchronize0utputs();
2569.
2570.
// consulta e modificacin de valores
template <class T>
2571.
2572.
bool getInputSnapshot(const string& var, T& val);
template <class T>
2573.
2574.
2575.
2576.
template <class T>
bool getIORTDBValue(const string& var, T& val);
2577.
2578.
bool setIORTDBValue(const string& var, const T& val);
template <class T>
2579.
bool setOutputSnapshot(const string& var, const T& val);
template <class T>
bool getIORTDBTimedValue(const string& var,
unsigned span, // valor histrico, 0= actual
2580.
TimedValue<T>& tval);
2581.
2562. template <class T>
bool setIORTDBTimedValue(const string& var, const TimedValue<T>& tval);
2583.
2584. };
Esta interface est composta polos mtodos que permiten engadir e eliminar entradas na
base de datos (lias 2562-2564), sincronizar a imaxe do proceso cos valores actuais das
varibeis (lias 2566-2568), e acceder e modificar tanto os valores da imaxe do proceso (lias
2570-2573) coma os valores actuais (lias 2574-2577) e histricos (lias 2578-2583) das
varibeis.
A Figura 7.28 mostra a secuencia de mensaxes intercambiadas para a creacin dunha nova
entrada na base de datos (implementacin do mtodo insert). A nova entrada creada
utilizando o mtodo CreatelORTDBEntry, un mtodo constructor ("factory method" [67]) ao
324
que se accede a travs da instancia da clase parametrizada GescaSystemVarDecl (B.2) pasada

como parmetro da chamada ao mtodo insert. Esta instancia contn a informacin da varibel
de proceso a almacenar na base de datos. Unha vez creada a nova entrada esta almacenada na
base de datos como parte das entradas ou das sadas dependendo da declaracin da varibel
(son consideradas como entradas as varibeis que devolven un valor true na chamada ao
mtodo canReac^.
'
pdcptrSeqElem ^
(from easlo El.man4)
^^----
pdcld2ptrSeq 1 ^
(trom BMe El.mentt^
viviPrOCeSS
(erom Proe.ss.s^
bind(DataElement) _
^
input_messages
^
^^T-------
IORTDBSnapshot
input_image
output image
IVMMsg
bindQIORTDBEntry) ^
IORTDB
(erom Prooeae^
IORTDBEntr Se
inputs
output_messages
IIORTDBEntry
outputs
IORTDBEntr
ddriver_id : string
iopoint_id : string
num_values : unsigned
1
process var r
\ history_values
' I:---------r
0.
^ r
T
GescaSystemVar
value : TimedValue<T>
-------;
^^T
TimedValue
^ ^
value : T
timestemp : double
Figura 7.27. Diagrama das clases que modelan a base de datos de E/S.
A declaracin simplificada da interface pblica da clase IIORTDBEntry a seguinte:

2585.class IIORTDBEntry
public pdcptrSeqElem
2586. {
2587.public:
2588.
// consulta da informacin da entrada
2589.
2590.
2591.
25^92.
2593.
2594.
2595.
2596.
2597.
2598.
2599.
2600.
2601.
2602.
2603.
2604 . }
virtual
virtual
virtual
virtual
virtual
string getDeviceID(void) const = 0;
string get20PointID(void) const = 0;
unsigned ge.tNumValues(void) const = 0;
type_info typeOf()^ const = 0;
size_t sizeOf() const = 0;
// consulta e modificacin de valores
template <class T>
void getValue(T& val];
template <class T>
void setValue(const T& val);
template <class T>
void getTimedValue(unsigned span, // valor histrico, 0 = actual
TimedValue<T>& tval);
template <class T>
void setTimedValue(const TimedValue<T>& tval);
A interface est formada polos mtodos que permiten acceder informacin sobre a varibel
almacenada na entrada da base de datos (lias 2589-2593): tipo, tamao, nmero de valores
histricos, e"driver" e punto de E/S no que est asignada; e acceder e modificar tanto o valor
actual (lias 2595-2598) coma os histricos (lias 2599-2603) da varibel.
325
Seccin 7.3: O ncleo da mquina virtual
:IORTDB
insert(decl)
ded : GescaSystemVarDecl<>
entry = CreatelORTDBEntry()
create
IockDataAccess()
entrv : IORTDBEntrv<>
read = canRead()
[readl
{false}
{true}
inputs.insert(entry)
outputs.insert(entry)
f-------------------------------------^
unlockDataAccess()
Figura 7.28. Secuencia das mensaxes intercambiadas na creacin dunha nova entrada na BD.
7.3.1.3. Actualizacin de valores e sincronizacin da imaxe do proceso

O valor dunha varibel almacenada na base de datos actualizado cando se recibe unha
mensaxe contendo un novo valor. O diagrama da Figura 7.29 mostra a secuencia de mensaxes
intercambiadas para a xestin dos valores recibidos dende o xestor de entradas (7.2.2). A
secuencia comeza coa solicitude dunha lectura sen bloqueo na porta de enlace pola que se
reciben as mensaxes do xestor de entradas. Cando recibe unha mensaxe, a porta de enlace enva
unha notificacin asncrona base de datos que manexada no seu mtodo OnHandler (lia
2033). A mensaxe recibida conter o identificador da varibel, o seu novo valor e a data e hora
na que foi adquirido polo "driver" de entrada no que estivera asignada. O procesamento da
mensaxe consiste en localizar a entrada que se corresponde coa varibel modificada e actualizar
o seu valor. Isto realzase na implementacin do mtodo setTimedValue (lia 2603), que se
encarga tanto da modificacin do valor actual da varibel como da correcta xestin dos seus
valores histricos. Ademais, se a varibel modificada booleana e o valor actual diferente do
valor que tia anteriormente, a base de datos crea e almacena o evento que indica este cambio.
Estes eventos sern enviados ao subsistema de aplicacin cada vez que este solicite unha
sincronizacin co proceso. O procesamento remata coa destruccin da mensaxe recibida e o
inicio dunha nova operacin de lectura sen bloqueo na porta de enlace que conecta a base de
datos co xestor de entradas.
A sincronizacin dos valores de entrada almacenados na imaxe do proceso (Figura 8.6) e os
da base de datos realzase implicitamente cando se invoca o mtodo getlnputEvents (lia 2566)
ou explicitamente co mtodo synchronizeinputs (lia 2567). O algoritmo utilizado para realizar
a sincronizacin actualiza unicamente os valores da imaxe que foron modificados na base de
datos dende a ltima sincronizacin (o indicador booleano modified utilizado para indicar esta
circunstancia). O seu pseudocdigo o seguinte:
2605.for each var V in input_image
entry = inputs[V]
2606.
if inputs[V].modified
2607.
input_image[V] = inputs[V][0]
2608.
inputs[V].modified = false
2609.
end if
2610.
2611.end for
// almacenar o valor actual na imaxe
326
:IORTDB
^ readMessageO
Iniar a lectura asfncrona
das mensaxes enviadas desde

o xestor de entradas
port:VMPort
port = ports.find(IMgrPort)
read(async_dbk, this)
Iniar o manexo da notificacin
de recepn dunha mensaxe
input message
^----------------------
notification
] onHandler(msg)
IockDataAccess()
Almacenar o novo valor

da varibel de entrada na
base de datos
entry = inputs.find(msg.var name)
entrv : IORTDBEntrv<>
setTimedValue(msg.value, msg.time)
tYPe = tYPe^() _I
^
[tYPe =_ bool]
old_value = getTimedVal ue(1)
Se a varibel booleana e o
novo valor diferente ao
valor anterior, crear e almacenar
o evento correspondente
new value = getTimedValue(0)

[new_value != old_value]
create I
event:VMEvent
i nput_m essages. add( event)

r
Eliminar a mensaxe recibida
msg:IVMMsg
unlockDataAccess()
destroy
.X
] readMessageO
Iniar a lectura as(ncrona
dunha nova mensaxe
port = ports.find(ÌMgrPort")
read(async_clbk, this)
Figura 7.29. Secuencia das mensaxes intercambiadas no procesamento das mensaxes recibidas dende o subsistema
de E/S.
O proceso utilizado para manexar as mensaxes de sada enviadas dende o subsistema de

aplicacin semellante ao explicado para as entradas. A principal diferencia consiste en que
para cada mensaxe recibida actualzase o valor da sada na imaxe do proceso. A sincronizacin
da imaxe das sadas co proceso (Figura 8.9), que consiste na actualizacin dos valores das
sadas almacenados na base de datos e o envo das mensaxes ao xestor de sadas cos valores
modificados, realzase explicitamente cando se invoca o mtodo synchronize0utputs (lia
2568).
7.3.2. Temporizadores
A implementacin da mquina virtual incle dous tipos diferentes de temporizadores que
son utilizados para as funcins de control do tempo que os procesos da sa arquitectura
requiran, as como para as temporizacins especificadas nos modelos executados no subsistema
de aplicacin (7.5). Todos os temporizadores da mquina virtual son implementados como
procesos que proporcionan servicios de temporizacin aos que se lles asigna a prioridade mis
alta. Debe terse en conta que a resolucin e precisin dos temporizadores dependen do soporte
proporcionado pola combinacin "hardware/software" na que se implemente a mquina virtual.
7.3.2.1. Temporizador simple
O primeiro tipo de temporizador definido proporciona un servicio bsico de temporizacin
en das versins:
327
Seccin 7.3: O ncleo da mquina virtual
1. Con bloqueo, o proceso que solicita o servicio bloqueado durante o tempo indicado.
2. Con notificacin de finalizacin, o proceso que solicita o servicio recibe unha notificacin
asncrona (7.1.2.4.2) cando transcorre o perodo de tempo indicado. Ademais, nesta
versin, pode solicitarse a repeticin da notificacin cunha periodicidade determinada.
Os temporizadores deste tipo implementan a interface ITimerServer:
2612.struct ITimerServer
2613. {
2614. // control do estado do tamporizador
2616.
2617.
2618.
2619.
2620.
2621.
virtual void
virtual void
virtual void
virtual bool
virtual bool
// servicios
2622.
2623.
2624.
virtual bool set(long time,
long period = 0,
pfn clbk = Ni7LL,
IAsyncClbkArg* clbkarg = NiJLL) = 0;
virtual bool wait(long time) = 0;
2625.
2626.
Suspend() = 0;
Resume() = 0;
Finish() = 0;
isSuspended() = 0;
isRunning() = 0;
de temporizacin
2627. virtual void stop(void) = 0;
2628 . } ;
A interface declara mtodos comns aos da interface IVMProcess (7.1.2.1) para o control e
consulta do estado do temporizador. O mtodo wait (lia 2626) proporciona o servicio de
temporizacin con bloqueo e o mtodo set (lia 2622) o de temporizacin con notificacin.
Ambos mtodos reciben como argumento a cantidade de tempo a considerar. O mtodo set
recibe ademais os argumentos relacionados coa notificacin asncrona, entre eles un valor
opcional utilizado para as notificacins peridicas. A interface compltase co mtodo stop (lia
2627) que detn o temporizador. A Figura 7.30 mostra a secuencia de mensaxes das diferentes
opcins de temporizacin comentadas.
7.3.2.2. Temporizador mltiple
O tipo de temporizador explicado anteriormente non pode atender mis dunha solicitude
simultaneamente. Debido a que os temporizadores son recursos limitados nun sistema e, en
ocasins, preciso ter activas un grande nmero de temporizacins simultaneamente, definiuse
un segundo tipo de temporizador que permite a planificacin con notificacin de mltiples
temporizacins. A cada unha se lle asigna un identificador numrico que includo na
notificacin e que pode ser utilizado para deter individualmente cada temporizacin. En
contrapartida este temporizador introduce un certo "overhead" debido xestin das
temporizacins que pod non ser aceptbel en sistemas que requiran unha precisin moi alta.
Estes temporizadores implementan a interface IMultitimerServer:
2629. struct IMultitimerServer
2630. {
2631.
2632.
// control do estado do tamporizador
2633.
2634.
2635.
2636.
virtual
virtual
virtual
virtual
2637.
void
void
void
bool
Suspend() = 0;
Resume() = 0;
Fin'ish() = 0;
isSuspended() = 0;

2638.
2639.
2640.
2641.
2642.
2643.
2644.
2645.
2646.
2647 . }
328
// servicios de te:mporizacin
virtual bool doSchedules(void) = 0; .
virtual bool doUnschedules(void) = 0;
virtual unsigned schedule(long time,
pfn clbk,
IAsyncClbkArg* clbkarg
bool deferred = false)
virtual bool unschedule(unsigned id, bool deferred
virtual void stop(void) = 0;
:VMProcess
^ ^
:VMTimerServer
:VMProcess
wait(time)
-^
time
NUI,L ,
0;
false) = 0;
:VMTimerServer
^ set(time, 0, async_clbk, this), i

.r;
time
t ^
notifiation__________ ^J
^---------------^Procesar notificacin
---------------------- ,
(a)
(b)
:VMTimerServer
:VMProcess
set(time, period, async_clbk, this) ;

z
fime
period
notification
^--------------------------------------------------
^ Procesar nofificacin
period
notification ______________i
f--------------------------------------
^ Procesar notificacin
'
:
(c)
Figura 7.30. Servicios proporcionados polo temporizador bsico: a) temporizacin con bloqueo; b) temporizador
con notificacin asncrona; e c) temporizador con notificacin peridica.
Do mesmo xeito que na interface ITimerServer, declranse mtodos comns aos da interface
IVMProcess para o control e consulta do estado do temporizador. A planificacin dun novo
temporizador faise co mtodo schedule (lia 2641), que recibe como argumento a cantidade de
tempo a considerar, os argumentos utilizados para a notificacin asncrona e un valor booleano
que indica se a planificacin debe terse en conta inmediatamente ou permanecer en suspenso
ata que sexa invocado o mtodo doSchedules (lia 2639). O mtodo schedule devolve o
identificador numrico asignado ao temporizador. O mtodo unschedule (lia 2645) permite
deter a planificacin dun temporizador concreto indicado mediante o seu identificador. Do
mesmo xeito que aconteca coa planificacin, este mtodo recibe como argumento un valor
booleano que indica se a parada do temporizador debe facerse inmediatamente ou manterse en
suspenso ata que sexa invocado o mtodo doUnschedules (lia 2640). A interface compltase
co mtodo stop (lia 2646) que detn todos os temporizadores planificados.
A Figura 7.31 mostra un exemplo da secuencia de mensaxes intercambiadas entre dous
procesos da mquina virtual e un temporizador que implemente a interface IMultitimerServer.
Un dos procesos inicia tres temporizadores que inicialmente estarn suspendidos ata que se
invoque o mtodo scheduleAll. O outro proceso inicia dous temporizadores, un deles
suspendido e o outro non -timer 4-. Unha vez transcorrido o tempo indicado -time 4- o
329
Seccin 7.4: O subsistema de xestin da configuracin
proceso que iniciou o temporizador recibe e procesa a notificacin correspondente. Os demais

temporizadores son activados na chamada a scheduleAll. Unha vez transcorrido o tempo
indicado para cada un deles o proceso que os iniciou recibe e procesa a notificacin
correspondente. Unha excepcin o temporizador timer_1 que desactivado polo mtodo
unschedule antes de que transcorra o tempo time_I. Ntese que tamn se fai unha, chamada a
este mtodo para o temporizador timer 3, mais neste caso unha desactivacin que queda
suspendida ata a seguinte chamada ao mtodo unscheduleAll. Como isto non acontece antes de
que transcorra o tempo time_3 o temporizador non desactivado. Sen embargo o temporizador
timer_6, que est en estado suspendido cando se chama a unscheduleAll, si desactivado e
nunca chega a iniciarse.
7.3.3. Acceso aos servicios do ncleo

O acceso aos servicios proporcionados polo ncleo da mquina viriual realzase mediante
unha clase que implemente a interface IVMServices que sirve como punto de acceso comn ao
ncleo (patrn "Facade" [67]). A declaracin da interface IVMServices a seguinte:
2648.class IVMServices
2649. {
2650.public:
2651. // temporizadorea
2652. virtual bool doSchedules(void) = 0;
2653. virtual bool doUnschedules(void) = 0;
2654. virtual unsigned long schedule(long time,
pfn callback,
2655.
IAsyncClbkArg* clbk_arg = NULL,
2656.
bool deferred = true) = 0;
2657.
2658. virtual bool unschedule(unsigned long _id, bool deferred = true) = 0;
2659. // eventos/entradas/sadas
2660. virtual bool getInputEvents(deque<VMEvent*>& events) = 0;
2661. virtual bool set0utputValues() = 0;
2663.
2664.
2665.
2666.
bool getSystemData(const string& id, T& value);
template <class T>
bool setSystemData(const string& id, const T& value);
// xeatin de erros
2667. virtual void onError(unsigned code, IModule* source) = 0;
2668 . } ;
Como pode verse, os servicios do ncleo aos que pode accederse utilizando esta interface
son os seguintes:
1. A xestin de temporizacins.
2. O acceso aos eventos almacenados no canal de entrada do subsistema de aplicacin e aos
valores da base de datos de E/S, as como a actualizacin nesta dos valores de sada
modificados no subsistema de aplicacin.
3. A sinalizacin de erros detectados durante a execucin.
7.4. O subsistema de xestin da configuracin

A mquina virtual proporciona un conxunto de servicios para a xestin da sa configuracin
e o control do seu funcionamento que poden ser accedidos remotamente mediante o
intercambio de mensaxes simples. O acceso a estes servicios foi deseado para ser
independente do medio de transmisin utilizado mediante a definicin de interfaces que
abstraen as caractersticas especficas de cada sistema e que haber que implementar en cada
caso concreto. A mquina virtual incle unha implementacin por defecto para redes de
330
comunicacin que utilicen o protocolo TCP/IP. En futuras versins poderan proporcionarse

implementacins que utilicen outros medios como lias serie de transmisin de datos,
protocolos distribudos de intercambio de datos entre procesos, etc. Unha limitacin da versin
actual da mquina viriual que non acepta mis dunha conexin remota simultnea. No resto
deste apartado descrbese o formato e o protocolo de intercambio de mensaxes, os servicios
'
proporcionados e a implementacin do acceso remoto en redes TCP/IP.
: VMProcess
:VMTimerServer
...
:VMProcess
timer_1 = schedule(time 1, async_clbk, this, false)

timer 2= schedule(time 2, async_clbk, this, false),
timer 3= schedule(time 3, async_clbk, this, false),
timer_4 = schedule(time 4, async_dbk, this, true)
z
timer 5= schedule(time 5, async_clbk, this, false) I
time_4
_
scheduleAll(),
:
__
notification (timer 4)
- - - - - - - - - - ------------------------------time 2
Procesar notficacin
time 5
unschedule(timer_1, true)
:
time_ 1
Procesar notificacin
time 3
t------------------------------------------------- -
^ Procesar notificacin
unschedule(timer 3, false)
_
- ---------------------- ----- --------------------^] Procesar notificacin
timer_6 = schedule(time 6, async_clbk, this, false),I

unscheduleAllO ,^ ^
Figura 7.31. Secuencia de mensaxes intercambiadas na planificacin de temporizadores.
7.4.1. Formato das mensaxes

A Figura 7.32 mostra o formato das mensaxes utilizadas no acceso remoto aos servicios da
mquina virlual. Cada mensaxe est formada por unha cabeceira e un conxunto opcional de
parmetros de tamao varibel. A cabeceira contn tres campos:
1. O cdigo que identifica o tipo de mensaxe (4 bytes).
2. Un cdigo auxiliar (4 bytes) utilizado para indicar condicins excepcionais, como por
exemplo un cdigo de erro.
3. O nmero de parmetros opcionais (4 bytes).
Pola sa banda cada parmetro opcional est formado por dous campos:
1. O tamao en bytes do parmetro (4 bytes).
2. O valor do parmetro.
Tendo en conta os valores dos campos da cabeceira dunha mensaxe, estas poden clasificarse
en tres tipos diferentes (Figura 7.33):
1. As mensaxes de control, utilizadas para indicar a finalizacin correcta dun servicio
(mensaxe OK! ) ou a deteccin dunha condicin de erro (mensaxe FAIL).
331
2. As mensaxes de resposta, utilizadas pola mquina virtual para enviar datos. O valor do
cdigo destas mensaxes OK, e o seu cdigo auxiliar maior ou igual a un.
3. As ordes, mensaxes utilizadas polo cliente que accede remotamente mquina virtual para
solicitar un servicio. As ordes poden ser simples, formadas por unha soa mensaxe, ou
mltiples, formados por varias mensaxes. Neste caso utilzase a mensaxe que tdelimita o
final dunha orde mltiple (mensaxe CMD_END) para indicar cal a ltima mensaxe da
orde.
Cabeceira
Cdigo
Cdigo
auxiliar
param_1
param_2
Num
params
param_N
TamaRo Valor
param param
Figura 7.32. Formato das mensaxes utilizadas no acceso remoto aos servicios da mquina virtual.
OK
FAI L
error
code
Mensaxes de control
Mensaxe
de datos
OK
params
param_1
param_2
param_N
param_1
param_2
param_N
Mensaxes de resposta
Orde
con datos
code
0/1
params
Delimitador fin de orde

mltiple (CMD_END)
code
Ordes
Figura 7.33. Tipos de mensaxes utilizadas no acceso remoto aos servicios da mquina virtual.
7.4.2. Protocolo de intercambio de mensaxes

Coas mensaxes descritas no apartado anterior son varios os patrns de comunicacin
definidos para dar soporte ao intercambio de informacin que se produce no acceso aos
servicios remotos ofrecidos pola mquina virtual. A definicin destes patrns faise partindo da
suposicin de que o medio de comunicacin utilizado fibel (non perde mensaxes) e mantn a
orde de envo das mensaxes. Tendo en conta estas suposicins, poden producirse as seguintes
interaccins entre un cliente e a mquina virtual:
l. Peticin, cunha orde simple, dun servicio que non devolva resposta. Se o servicio pode
realizarse a mquina virtual devolver unha mensaxe OK! (Figura 7.34.a), en caso
contrario devolver unha mensaxe FAIL (Figura 7.34.b) cun cdigo que indique o motivo.
Ntese que a orde pode conter parmetros ou non e que o valor do seu cdigo auxiliar
cero.
2. Peticin, cunha orde simple, dun servicio que devolva resposta (Figura 7.34.c). Neste caso
a mquina virtual enva mltiples mensaxes resposta contendo os datos resultado do
servicio. Ntese que o valor do cdigo auxiliar nestas mensaxes un, e que o nmero de
parmetros e maior ou igual a un. A resposta da mquina virtual remata cunha mensaxe
OK!. En caso de producirse un erro, a mquina virtual enviara a mensaxe FAIL e a
operacin quedara abortada.
332
3. Peticin, cunha orde mltiple, dun servicio que non devolva resposta (Figura 7.34.d). O
cliente enva mltiples ordes co mesmo cdigo. Cada unha destas ordes poder conter
parmetros ou non, mais o valor do seu cdigo auxiliar ser maior ou igual a un. O final da
orde mltiple se indica co envo dunha mensaxe CMD_END. A mquina virtual devolver
OK! ou FAIL despois de cada mensaxe recibida, dependendo do resultado da
comunicacin e da execucin do servicio.
'
4. Peticin, cunha orde mltiple, dun servicio que devolva resposta. Este caso unha
combinacin dos dous anteriores.
Ntese que a mquina virtual unicamente enva mensaxes con cdigos OK ou FAIL e que o
cliente sempre agarda a recibir unha destas mensaxes antes de enviar a sa seguinte mensaxe.
^Client
:Virtual Machine
code p params param_1
:yrtual Machine
:Client
param_N
code
params param_1
param_N
FAI L err 0
OK 0 0
f
(b)
(a)
:Virtual Machine
:Client
code 0 params param_1
param_N
OK 1 params param_1
param_N
OK 1 params param_1
param_N
:Vrtual Machine
^C ie t
param_N
OK 0 0
param_N
OK 0 0
OK 0 0
code 0 0
(C)
OK 0 0
(d)
Figura 7.34. Protocolo de intercambio de mensaxes no acceso remoto aos servicios da mquina virtual: a) orde
simple sen resposta (resultado correcto); b) orde simple sen resposta (resultado errneo); c) orde simple con
resposta; e d) orde mltiple sen resposta (resultado correcto).
7.4.3. Servicios remotos da mquina virtual

Os servicios proporcionados pola mquina virtual a travs do mecanismo de acceso remoto
poden clasificarse nas categoras seguintes:
1. Carga e descarga de DLLs, nesta categora agrpanse os servicios que permiten:
a. Iniciar remotamente a carga en memoria dos mdulos contidos nunha DLL, utilizando
o mecanismo explicado en (7.1.1.5).
b. Descargar unha DLL e os seus mdulos da memoria da mquina virtual.
c. Descargar todas as DLLs e mdulos da memoria da mquina virtual.
2. Carga e descarga de tboas de E/S (tboas que conteen as declaracins das varibeis do
proceso e a informacin da sa asignacin aos "drivers" de E/S), nesta categora agrpanse
os servicios que permiten:
333

a. Iniciar remotamente a carga en memoria dunha tboa de E/S. Estas tboas conteen a
informacin sobre as varibeis de proceso utilizadas. Para cada varibel indcase o seu
nome, tipo e tamao; o nmero de valores histricos a almacenar na base de datos
(7.3.1); e a informacin utilizada para asignar a varibel a un dispositivo de E/S
(7.2.1.4.1): identificador do "driver", identificador do punto de E/S e frecuencia de
monitorizacin.
b. Descargar unha tboa de E/S da memoria da mquina virtual.
3. Carga, descarga e execucin de modelos no subsistema de aplicacin da mquina virtual,

nesta categora agrpanse os servicios que permiten:
a. Cargar un modelo no subsistema de aplicacin da mquina virtual para a sa posterior
execucin.
b. Descargar un modelo do subsistema de aplicacin da mquina virtual.
c. Iniciar a execucin dun modelo.
d. Deter a execucin dun modelo.
e. Continuar a execucin dun modelo. Este servicio utilzase na opcin de execucin
paso a paso do modelo durante a sa depuracin.
A mquina virtual permite ter varios modelos almacenados simultaneamente na sa
memoria. Antes de iniciar a execucin dun modelo preciso cargalo no mdulo do
subsistema de aplicacin da mquina virtual no que vaia a executarse. Anda que na versin
actual da mquina virtual o subsistema de aplicacin unicamente contea un intrprete de
modelos Grafcet, e este s acepte a carga dun nico modelo, as mensaxes que implementan
estes servicios foron definidas para permitir en futuras versins a utilizacin de mltiples
interpretes e mltiples modelos.
A execucin dun modelo pode facerse nun de dous modos: depuracin ou explotacin. No
modo de depuracin a mquina virtual enva, despois de cada evolucin do modelo a
informacin sobre a situacin e os valores das sas varibeis. Despois detense a sa
evolucin ata que non se reciba unha mensaxe de continuacin ou de detencin da
execucin. Este modo permite tanto a visualizacin remota do estado como o control paso
a paso da evolucin dos modelos. Combinando este modo coa simulacin remota de E/S
(7.2.3) pode simularse o proceso e verificar o comportamento dos modelos antes da posta
en funcionamento do sistema de control.
4. Xestin de configuracins, nesta categora agrpanse os servicios que permiten:
Engadir unha nova configuracin (7.1.1.4) nun mdulo da mquina virtual.
Eliminar unha configuracin dun mdulo da mquina virtual.
Activar unha configuracin nun mdulo da mquina virtual.
Consultar a configuracin activa nun mdulo da mquina virtual.
Consultar as configuracins dispobeis nun mdulo da mquina virtual e os tipos e
mdulos que as forman.
f. Activar un mdulo da configuracin dun mdulo da mquina virtual.
g. Desactivar un mdulo da configuracin dun mdulo da mquina virtual.
^
a.
b.
c.
d.
e.
5. Consulta da estructura de mdulos da mquina virlual, nesta categora agrpanse os

servicios que permiten:
a. Consultar a estructura de mdulos da mquina virtual.
b. Consultar os mdulos dispobeis nun almacn de mdulos (7.1.1.3) da mquina
virtual.
334
6. Consulta da informacin de configuracin (7.2.1.2) dos "drivers" de E/S.

7. Desconexin e finalizacin da execucin da mquina virtual. Nesta categora agrpanse os
servicios que permiten:
a.
b.
Desconectar ao cliente da mquina virtual, deixando a conexin libre para que un novo
cliente poda acceder aos servicios remotos.
,
Apagar a mquina virtual, detendo a sa execucin e eliminando os recursos que ocupe
na memoria.
Os cdigos, patrns de comunicacin, mensaxes e parmetros utilizados en cada servicio

poden consultarse no Anexo F.
7.4.4. Modelado do acceso remoto mquina virtual

O diagrama da Figura 7.35 mostra as clases definidas para implementar a comunicacin
remota entre un cliente e a mquina virtual. A clase VMCommand representa as mensaxes
intercambiadas nesta comunicacin e os seus atributos correspndense cos campos indicados
en (7.4.1). A clase abstracta IVMClient declara a interface a travs da que un cliente accede
aos servicios remotos da mquina virtual. A declaracin desta interface a seguinte:
2669.struct IVMClient
2670. {
2671.
2672.
2673.
2674.
2675.
virtual bool loadDLL(const string& name, const string& path) = 0;
virtual bool unloadDLL(const string& name) = 0;
virtual bool unloadAllDLLs() = 0;
// carga e descarga de tboas de E/S
// carga e descarga de DLLs
2676.
2677.
2678.
2679.
2680.
2681.
2682.
2683.
2684.
2685.
2686.
2687.
2688.
2689.
2690.
2691.
2692.
2693.
2694.
2695.
2696.
2697.
virtual bool loadSystemIO(const string& path) = 0;
virtual bool unloadSystemIO() = 0;
// carga, descarga e execucin de modelos
virtual bool loadModel(const string& module, const string& model) = 0;
virtual bool unloadModel(const string& module, const string& model) = 0;
virtual bool playModel(const string& module,
const string& model,
unsigned opts) = 0;
virtual bool nextModelEvolution(const string& module,
const string& model) = 0;
virtual bool stopModel(const string& module, const string& model) = 0;
// xestin de configuracins
virtual bool addConfiguration(const string& module,
const ModuleConfiguration& conf) = 0;
virtual bool removeConfiguration(const string& module,
virtual bool setCurrentConfiguration(const string& module,
virtual bool getCurrentConfiguration(const string& module,
ModuleConfiguration& conf) = 0;
virtual bool getConfigurationInfo(const string& module,
ModuleConfSeq& conf) = 0;
2698.
virtual bool activate(const string& module,
2699.
const string& conf,
2700.
const string& type,
2701.
2702.
virtual bool deactivate(const string& module,
2703.
const string& conf,
const string& type,
2704.
2705.
2706.
2707.
2708.
// consulta da eatructura de mdulos da mquina virtual
virtual bool getModuleInfo(const string& module, ModuleInfo& info) = 0;
virtual bool getVMInfo(VMInfo& info) = 0;
335
2709.
2710.
2711.

// coasulta da informacia de configuracia dos "drivers" de S/S
virtual bool getDeviceInfo(const string& device, DeviceInfo& ddinfo) = 0;
// fiaalizacia da execucin da mquiaa virtual
2712.
virtual bool shutdown() = 0;
2713 . } ;
Os mtodos desta interface correspndense cos servicios da mquina virtual explicados no

apartado anterior. O nico servicio para o que non se define o correspondente mtodo o de
desconexin, xa que se supn que esta se realiza cando o cliente destrudo, e polo tanto ser
implementado no destructor das clases derivadas de IVMClient.
IVMClient
TCPSocket
IVMServer
(trom Common C++)
TCPIPVMCIient
stream
TCPStream
stream
VMProcess
(from ProoeaK
TCPIPVMSeroer
(from Common C4+) '
send_comms
^
VMCommand
code : unnsigned
aux code : unsigned
param_size : unsigned
params : deque<string>
recv_comms
1'
Figura 7.35. Diagrama das clases utilizadas para modelar o acceso dun cliente aos servicios remotos da mquina
virtual.
A xestin do envo e recepcin de mensaxes na mquina virtual realizada por un proceso

que implemente a interface definida pola clase abstracta IVMServer. O cdigo da declaracin
desta interface o seguinte:
2714.struCt IVMServer
2715. {
2716.
// control de estado
2717.
2718.
2719.
virtual void Resume ( ) = 0;
2720.
2721.
2722.
virtual bool isRunning() _ 0;
// recepcin de measaxes
2723.
2724.
2725.
2726.
2727.
2728.
2729.
2730. }
virtual void onCommand(pfn fun, IAsyncClbkArg* fun_arg

virtual void getCommand(SFCVMCommand*& command) = 0;
= NLTLL ) = 0 ;
// envo de mensaxes
virtual bool ok(unsigned code = 0) = 0;
virtual bool ok(const deque<string>& params, unsigned code = 1) = 0;
virtual bool fail(unsigned err = 0) = 0;
Ademais dos mtodos que permiten controlar o estado do proceso (lias 2717-2722), esta
interface declara mtodos para solicitar unha notificacin asncrona cando se reciba unha
mensaxe -mtodo onCommand (lia 2724}-, para recuperar as mensaxes recibidas -mtodo
getCommand (lia 2725}- e para enviar as mensaxes de resposta -mtodos ok (lias 2727 e
2728) e fail (lia 2729^.
7.4.4.1. Implementacin do acceso remoto en redes TCP/IP
O mecanismo de acceso remoto mquina virtual en redes TCP/IP implementouse nas
clases TCPIPVMCIient e TCPIPVMServer, derivadas das interfaces IVMClient e IVMServer
respectivamente. A comunicacin entre as instancias destas clases realzase mediante instancias
da clase TCPStream, pertencente librara Common C++ ( 1.3.2). Esta clase representa unha
336
conexin entre un cliente e un servidor TCP, e permite o envo e recepcin de datos mediante
os operadores e, do mesmo xeito que se fai nos "streams" C++. As instancias da clase
TCPIPVMServer son procesos da mquina virtual que proporcionan un servidor TCP que
implementa a xestin do envo, recepcin e almacenamento -agregacins recv_comms e
send_comms- das mensaxes intercambiadas pola mquina virtual cos seus clientes. A clase
TCPSocket, tamn pertencente librara Common C++, proporciona un servidor TCP bsido a
partir do cal se implementa o resto da funcionalidade da clase TCPIPVMServer.
O diagrama da Figura 7.37 mostra a secuencia de mensaxes entre as instancias que
implementan o mecanismo de acceso remoto aos servicios da mquina virtual para realizar a
carga dunha DLL. A mquina virtual configura o servidor TCP para recibir unha notificacin
cada vez que se reciba unha orde e despois inicia a sa execucin invocando o seu mtodo Start
(lia 2717). A solicitude do servicio remoto iniciada coa chamada ao mtodo loadDll (lia
2672) na instancia da clase TCPIPVMCIient. A implementacin deste mtodo crea a orde a
enviar mquina virtual, envaa a travs do "stream" TCP e agarda a mensaxe de resposta.
Cando a orde recibida no servidor TCP, almacnase na cola de ordes recibidas -agregacin
recv_comms- e unha notificacin enviada mquina virtual. Esta recupera a orde recibida
chamando ao mtodo getCommand (lia 2725), a interpreta e executa o servicio solicitado. En
funcin do resultado da execucin a mquina virtual chama aos mtodos ok (lias 2727 e 2728)
ou fail (lia 2729) no servidor para enviar unha mensaxe de resposta. Estes mtodos crean a
mensaxe correspondente, almacnana na cola de mensaxes de sada -agregacin
send_comm- e sinlanlle ao servidor a presencia dunha nova mensaxe. Este recupera a
mensaxe e envaa ao cliente a travs do "stream" TCP.
7.4.4.2. Implementacin do acceso simultneo a mltiples mquinas virtuais
Para facilitar o desenvolvemento de aplicacins distribudas, definiuse un conxunto de
clases que permiten xestionar o acceso simultneo a mltiples mquinas virtuais dende un
cliente. O diagrama da Figura 7.36 mostra as clases utilizadas para modelar esta funcionalidade
e implementala utilizando mltiples "threads" e o protocolo de comunicacins TCP/IP.
A xestin das mltiples conexins que un cliente pode establecer simultaneamente cunha
mquina virtual son manexadas nunha secuencia de execucin independente que implemente a
interface IVMConnectionMgr, que proporciona mtodos para iniciar e finalizar conexins coas
mquinas virtuais e para acceder aos servicios que estas proporcionan:
2731.struct IVMConnectionMgr
2732. {
2733.
// conexins
2734.
virtual bool connect(IVMachineInfo* vm) = 0;
2735.
virtual bool disconnect(IVMachineInfo* vm) _ 0;
2736.
2737.
virtual bool loadDll(IVMachineInfo* vm,
2738.
const string& name,
2739.
const string& path) = 0;
2740.
virtual bool unloadDll(IVMachinelnfo* vm, const string& name) = 0;
2741.
virtual bool unloadAllDlls(IVMachinelnfo* vn ) = 0 ;
2742.// xestin de configuracina
2743.
2744.
2745.
2746.
2747.
2748.
virtual bool addConf(IVMachineInfo* vm,
const string& part,
ModuleConfiguration* conf) _ 0;
virtual bool removeConf(IVMachineInfo* vm,
const string& part,
const string& conf) = 0;
337
2749.
2750.
2751.
2752.
2753.
2754.
2755.
2756.
2757.
2758.
2759.
2760.
2761.
virtual bool selectConf(IVMachineInfo* vm,
const string& part,
const string& conf) = 0;
// xeatia de mduloa
virtual bool addModule(IVMachinelnfo* vm,
const string& part,
const string& conf,
const string& type,
const string& module) = 0;
virtual bool removeModule(IVMachineInfo* vm,
const string& part,
const string& conf,
const string& type,
2762.
2763.
// conaulta da estructura da mquina virtual
2764.
2765.
virtual bool getVMInfo(IVMachineInfo* vm) = 0;
// finalizacin da execucin da.mquiaa virtual
virtual bool shutdown(IVMachineInfo* vm) = 0;
2766.
2767
};
Como pode comprobarse, os mtodos desta interface coinciden cos da interface IVMClient75
coa diferencia de que teen un parmetro mis para identificar a mquina virtual que van
dirixidas as solicitudes de servicio. Cando un cliente solicita un servicio, pasa como parmetro
unha instancia que implemente a interface IVMachinelnfo e que contea, como mnimo, o
identificador alfanumrico da mquina virtual, o enderezo numrico utilizado para establecer
unha conexin con ela, e un apuntador ao cliente que realiza a solicitude7. As clases derivadas
poden inclur outras informacins especfcas do sistema de comunicacins utilizado.
IVMReqest
NMConnectianMgr
^ getld( )
getVMachine( )
Thread
getParam( )
(from Common C^^)
^
TCPSession
(fiom Common C++)
4^
NMConnection
connectiov yylConnectionM r
vniRequeSt
id : unsigned
params : deque<string>
o-uests
req
vminfo
TCPIPVMConnection
^connection
1 name : string
TCPIPVMCIientSession
^1 session address : in addr
manager
^-
TCPIPVMConnectionMgr
1
IVMachinelnfo
vmachine
Decorator '
Component
^_^,.
vminfo
{Pattem}
Decorator = {
Component,
Decorator
}
client
IClientApplication
getName( )
getAddress( )
onMessage( )
^
frCPIPVMachinelnfo
TCPIPVMCIient
1
getPort()
TCPIPVMachinelydo
name : string
address : long
port : unsigned
Figura 7.36. Clases utilizadas para modelar o acceso dun cliente a mltiples mquinas virtuais en redes TCP/IP.
75 A principal diferencia que nesta interface os mtodos de IVMClient utilizados para consultar a informacin
sobre os mdulos, configuracins e"drivers" de E/S da mquina virtual son substituidos polo mtodo getVMlnfo.
'b Representado na Figura 7.36 mediante a interface IClientApplication, que se deixou sen especificar
intencionadamente.
338
^
^
fi
^
T
-I
^^
E ^y
E
^
$^ i
^^
^ ^-^^ ..,..
^9
^
0
^
^
a
Figura 7.37. Secuencia de mensaxes intercambiadas no acceso aos servicios remotos da mquina virtual nunha
rede TCP/IP.
339
As instancias da clase VMConnectionMgr son "threads" que proporcionan unha

implementacin por defecto da interface IVMConnectionMgr, utilizando para elo a
funcionalidade derivada da clase Thread pertencente librara Common C++. Cada instancia
almacena informacin sobre as solicitudes de servicio pendentes -agregacin requests- e as
conexins coas mquinas virtuais abertas -agregacin connections-. As soli itudes de
servicio son representadas mediante instancias da clase VMRequest, derivada da interface
IVMRequest, que almacenan o cdigo e os parmetros do servicio solicitado, as como un
apuntador informacin da mquina virtual recibida do cliente cando este solicita o servicio
agregacin vminfo-. No referente s conexins, son representadas mediante instancias de
clases derivadas da interface IVMConnection, cuxa declaracin a seguinte:
2768.struct IVMConnection
2769. {
2770. // conexibna
virtual bool connect() = 0;
2771.
2772.
virtual bool disconnect() = 0;
2773.
virtual bool loadDll(const string& name, const string& path) = 0;
2774.
virtual bool unloadDll(const string& name) = 0;
2775.
virtual bool unloadAllDlls() = 0;
2776.
2777.
// xeatin de configuracins
virtual bool addConf(const string& part, ModuleConfiguration* conf) _

2778.
virtual bool removeConf(const string& part, const string& conf) = 0;
2779.
2780.
virtual bool selectConf(const string& part, const string& conf) = 0;
// xestin de mbdulos
2781.
virtual bool addModule(const string& part,
2782.
const string& conf,
2783.
const string& type,
2784.
2785.
virtual bool removeModule(const string& part
2786.
const string& conf,
2787.
const string& type,
2788.
2789.
// consulta da estructura da mquina virtual
2790.
virtual bool getVMInfo(VMArchitectureInfo* p2nfo) = 0;
2791.
// finalizacin da execucin da mquina virtual
2792.
virtual bool shutdown() = 0;
2793.
0;
2794. };
A declaracin desta interface semellante da interface IVMClient. Isto permite que as

instancias das clases derivadas de IVMConnection poidan ser utilizadas como decoradores [67]
das instancias de clases derivadas de IVMClient e, polo tanto, implementar de forma
transparente funcins adicionais no acceso aos servicios da mquina virtual. As clases
TCPIPVMConnectionMgr, TCPIPVMachinelnfo e TCPIPVMConnection (Figura 7.36)
proporcionan unha implementacin das interfaces IVMConnectionMgr, IVMachinelnfo e
IVMConnection para redes que utilicen o protocolo de comunicacins TCP/IP. Nesta
implementacin cada conexin manexada nunha sesin independente representada pola clase
TCPIPVMCIientSession. Esta clase implementa a interface IVMConnection utilizando a
funcionalidade derivada da clase TCPSession, pertencente librara Common C++. Cada
instancia da clase TCPIPVMCIientSession , polo tanto, un "thread" que xestiona unha
conexin coa mquina virtual servindo de decorador dunha instancia da clase TCPIPVMCIient
-agregacin vmachine-. Esta instancia a que proporciona o acceso remoto aos servicios da
mquina virtual tal e como se explicou no apartado anterior (Figura 7.35).
A Figura 7.38 e a Figura 7.39 mostran exemplos das secuencias de mensaxes intercambiadas
entre as instancias das clases anteriores para o establecemento dunha conexin cunha mquina
virtual remota e a solicitude de carga dunha DLL, respectivamente. Ntese que a finalizacin
340
do servicio solicitado se lle indica ao cliente invocando o mtodo onMessage (Figura 7.36) da
instancia da clase derivada de IVMachinelnfo recibida omo parmetro da solicitude. Esta
instancia mantn un apuntador ao cliente que solicitou o servicio, que ser notificado da
finalizacin do mesmo. A implementacin actual da clase VMConnectionMgr ten a limitacin
de bloquearse durante o procesamento dunha solicitude ata que esta remate. En futuras versins
poderan implementarse xestores que procesen mltiples solicitudes simultneas, incorporardo
a cada conexin a capacidade de almacenar as solicitudes e notificarlle ao xestor a sa
finalizacin.
7.5. O subsistema de aplicacin

O subsistema de aplicacin a compoente da arquitectura na que se cargan dinamicamente
e se executan os modelos de usuario. Este subsistema est deseado para ser utilizado con
aplicacins que interaccionen co proceso mediante o intercambio de eventos. A versin actual
contn unicamente un intrprete Grafcet pero proporciona a infraestructura "soflware" precisa
para inclur en futuras versins outros tipos de intrpretes (p.e, RdPI, diagramas de estados,
etc.) e aplicacins. Neste apartado explcanse os aspectos da interaccin entre este subsistema e
o proceso. A implementacin do intrprete Grafcet explcase no Captulo 8.
A interaccin do subsistema de aplicacin co proceso realzase mediante dous canais, un de
entrada polo que o subsistema recibe os eventos detectados no proceso; e outro de sada polo
que se envan os valores das sadas calculados pola aplicacin. A Figura 7.40 e a Figura 7.41
mostran de maneira simplificada as secuencias de mensaxes intercambiadas entre os procesos
da mquina virtual dende que se obtn o valor dunha entrada do proceso ata que o subsistema
de aplicacin procesa ese valor. Como pode verse esta interaccin non directa, senn que nela
interveen diferentes procesos do subsistema de E/S e do ncleo da mquina virlual.
Como se explica en (7.2.1.3), os "drivers" de E/S poden configurarse tanto para
monitorizar o valor dunha entrada a intervalos regulares (lectura sncrona), como para obter o
valor da entrada cada vez que este cambie (lectura asncrona). Nas das secuencias mostradas
na Figura 7.40 e na Figura 7.41, o"driver" utilizado est configurado para obter o valor da
entrada a intervalos regulares, mais a secuencia seria semellante se estivera configurado para
obter un valor cada vez que se detectase un cambio na entrada.
Do mesmo xeito, os canais para o paso de mensaxes (7.1.2.4.1) proporcionan mecanismos
tanto para o envo dunha notificacin asncrona cada vez que se almacena unha nova mensaxe,
como para a lectura con bloqueo das mensaxes que almacenen. Na secuencia da Figura 7.40 0
canal de entrada do subsistema de aplicacin envalle unha notificacin asncrona ao
subsistema cada vez que se recibe un novo evento, mentres que na secuencia da Figura 7.41,
o subsistema de aplicacin quen obtn a intervalos regulares os eventos almacenados no canal
de entrada. Ntese que a base de datos unicamente crea un evento cando o valor obtido o
dunha varibel booleana e, ademais, diferente do ltimo valor almacenado.
A combinacin das caractersticas anteriores permite a utilizacin do subsistema de
aplicacin para executar tanto procesos dirixidos por eventos, activados cada vez que se reciba
un novo evento no canal de entrada, como procesos cclicos, que accedan aos eventos de
entrada como parte do seu ciclo de execucin. A arquitectura proposta ten dous inconvenientes
que condicionan sa aplicabilidade en procesos con requisitos temporais estrictos:
1. Os canais para o paso de mensaxes entre procesos non implementan ningn mecanismo
que impida o desbordamento das colas de mensaxes. Isto implica que o funcionamento da
mquina virtual pode colapsarse se utilizada con procesos que xeren eventos a un ritmo
341

maior do que esta sexa capaz de procesar. Este problema pode reducirse en certa medida
mediante a especificacin de frecuencias de monitorizacin nas varibeis de entrada, como
se explica en (7.2.1.4.2).
2. A mquina virtual introduce unha latencia entre o instante no que un "driver" obtn un
valor de entrada e o instante no que o subsistema de aplicacin recibe-^ o evento
correspondente. O valor deste retardo varibel e dbese ao "overhead" introducido polo
subsistema de E/S e o ncleo da mquina virtual no procesamento dos valores de entrada.
7.6. Conclusins
Neste captulo describiuse a arquitectura e o funcionamento da mquina virtual que da
soporte execucin dun interprete Grafcet para a interpretacin dos modelos de usuario. A
flexibilidade e portabilidade da arquitectura permite a sa utilizacin en diferentes sistemas e
con mltiples dispositivos de E/S. Explicronse as tcnicas implementadas para utilizar a
mquina virtual en ambientes de simulacin distribudos e os servicios remotos que
proporciona para a xestin da sa configuracin e o control do seu funcionamento. Tamn se
describiron os servicios bsicos proporcionados pola mquina virtual, como a xestin de
eventos e temporizacins ou a consulta, almacenamento e actualizacin dos valores do proceso.
Anda que a mquina virtual foi deseada inicialmente coa intencin de executar un
intrprete Grafcet, a arquitectura resultante proporciona un ambiente cos servicios precisos para
implementar e executar outras aplicacins dirixidas por eventos. Un dos aspectos que se
describiron en detalle no captulo foi como realizada a interaccin entre o subsistema de
aplicacin e o proceso, poendo de relevo os diferentes tipos de aplicacins soportados e
indicando as latencias introducidas pola mquina virtual e as consecuencias na sa aplicacin
en sistemas con restriccins temporais estrictas. Para reducir en parte este problema describiuse
unha tcnica implementada nos "drivers" de E/S baseada na monitorizacin de entradas.
Entre as melloras que poderan implementarse en futuras versins poden citarse as
seguintes:
1. A implementacin dun mecanismo que permita configurar a resposta do sistema en caso de
producirse un desbordamento das colas de mensaxes almacenadas nos canais de
comunicacin.
2. O soporte utilizacin dalgunha linguaxe de definicin de "drivers" de E/S ou mtodo
semellante, que permita reaproveitar as especificacins utilizadas noutros sistemas.
3. A substitucin das comunicacins baseadas no intercambio de mensaxes pola utilizacin
dalgunha infraestructura para o soporte a distribucin de obxectos como a proporcionada
por CORBA [126].
Por ltimo indicar que a versin actual da mquina viriual non incle un mecanismo
especfico para a comunicacin directa entre mquinas virtuais que permita a execucin
distribuda de Grafcets. Ntese sen embargo que posbel implementar este mecanismo
utilizando a mesma tcnica empregada para a simulacin de E/S, intercambiando informacin
entre as mquinas virtuais a travs de "drivers" de E/S implementados a tal efecto.
342
C
y
^
n
Î
.;i
ni
n:
i m
F;
^^
`m
OG
'I
Vj
i ^
ac m
mm
m ^
m "
^
^^
u`^
m
' m
m^
^s
mE
â
^ m
U u
ag
^ ^
Figura 7.38. Secuencia das mensaxes intercambiadas para a creacin dunha conexin coa mquina virtual.
343
1_-""_-"'
8_
f^l , , L
E
^
m
E
^
^
t
v
0
^
E
^
^'
m
^
^
^
E
m
0
d
0
m
^ E =
^
p^
^
m
^
^
^^ p
r ^ ^ o
W
cW
>
n
^ ^ m ^
^ ^ $
^ n ^ n
^ r^$> ^
qO
....................................................................
^ j O
"
â
^ ^
^
^9
v^
:
u
J
q
^
o
_'
sp
^
î
ye

^$
Ê
a
Z
o_
$$
gS
^^
Figura 7.39. Secuencia das mensaxes intercambiadas para a solicitude de carga dunha DLL na mquina virtual.
344
A'
AI
C
O^
F ^
^
^
^- I
^
pi
i
V'
:. :
VI
II
a>i
ml
ar
^
d
7
aci
^ 7 (p
4/ C f0 >
E ^ > '
^ _VI>
0
^ ^ ^
`m a^
vi^ >>
`m ^n.^
m
>
^^mm;t
Ev>d^
l0 '.^-'
E 1 >I `m
p O ^ >
m o
â c
E lo >^ ^ ^ ^
lp
A O ^ v
>
;^^ 3 >
m u ^ '
m`
û >Ij
>
`m $.n,^
d^^^
aci
mm^ >
^>dy a^
> ii > >
m
>
aci
a>>
m $n.^
aci^^^
^^mm^
E v > a/ 9
aci
m
U C
@
UC
QI
N :_
N C N >
>
aci^`>>
^ ^ lO
d C f0 >
U
N :^
(p
C
d
c1
Ot,^
; ^
U (p
p I d
^ (^p
i ^
I 11
V I O1
V I N
N
II
O1
C I II
V ^ O1
^.
rn
E
^
.;
N
E
^
^v31
E
d
rn
^ '
A i
F i
c^
o;
cI
o;
c^
ol
U^ _
I _
p i ^
G' U
I ^
C' N
Vj
V I 11
^ m
C i d
y^
V ' II
^ ^
^ i N
V^
V I II
Î
JI
N
4%
^
a
,_,
^
>
^
>
`m
>
^
>
`m
>
1
rn
^
>
u
rn
^
w
}
i1f
C
0^
0^
a^
o_ N
a^
Figura 7.40. Secuencia das mensaxes intercambiadas para o procesamento dun evento detectado no proceso nunha
aplicacin dirixida por eventos.
345
Seccin 7.6: Cnclusins
Q V
E^
^
^^
c
m
E^
~^
~^
^
^
d
^
d
a>i
n
^
m
a'^
^
> ^
^
y ^
^m d
d m> a>i
E ô> - v
A OÎ > ^=
aio
^^ ^^
û >w
^
d ^
^ ^
^To
^
d m> a>i
^
ip
>
-
l0 :t
^=
l0
>
-
i" >w
'
^ GI
m^
m` ^'I ^
^^.>>
^
` :
mm
^^>d ^
V 41
l0 :t
>
?
'^
?'^ >w
^
a^
>
a^
^y.>>
m m;^
`
^^>d ^
E ô> -^
A O^^
'
`m q ^
a^
î>m`
^ >
^
>
ti^
3
' ^
`m ' u ^
^,'>>
d^
E A>
A O^^
^
d ^
^ ^
^N
^
m m> a>i
l0 ^
^
l0
>
'
^
a^
>
a^
^ Q1
-^
^
A^
AI
A^
c;
AI
c;
o;
AI
A^
c;
p ^ ^
F ^ v
wi
N
^
V^^
^ ^ N
p ^ ^
;u
v^ rn
v
^ I ^
j II
v : rn
v ^
^ î

I
^
oi
rn
^
v^
rn
^
rn
E
d
.^
3
a^
.^
E
m
.^
3
î
^
o;
a^
A i
^
i ^
o;
; ^
C ^ N
V,
V : II
^ i l0
y I d
II
V ; II
rn
[
^
N
IN
a^
d
.C
m
7
N
>
;E
^
^
N
N
'C
3
N
>
^
'
3
m
7
N
>
m
^
W
>
N
>
W
>
IT
e
m^
v^
m^
v^
O N
Figura 7.41. Secuencia das mensaxes intercambiadas para o procesamento dun evento detectado no proceso nunha
aplicacin cclica.
Captulo 8 . O intrprete de
modelos Grafcet
O intrprete Grafcet o proceso da mquina virtual que se encarga da interpretacin dos

modelos Grafcet cargados na sa memoria. A interaccin do intrprete co proceso fisico
realzase mediante o intercambio de eventos utilizando os canais de comunicacin do
subsistema de aplicacin da mquina virtual (7.5). O funcionamento do intrprete est
composto polas seguintes fases que se executan ciclicamente:
1.
A obtencin dos eventos de entrada a considerar na seguinte evolucin do modelo.
2.
O clculo das temporizacins.
3.
A evolucin do modelo Grafcet.
4.
A execucin das accins activas.
5.
A actualizacin dos valores das sadas.
Dende o punto de vista do manexo dos eventos o intrprete ten unha semntica RTC, na que
non se teen en conta os novos eventos que se produzan durante unha evolucin do modelo ata
que esta remate. Esta semntica xunto coa comunicacin mediante o paso de mensaxes garante
que non se produzan conflictos ("race conditions") durante a execucin do intrprete.
O ritmo ao que se procesan os eventos do proceso depende do tempo de ciclo do intrprete,
que varibel e dependente do modelo Grafcet interpretado. Isto implica que teoricamente s
poda garantirse a reactividade do intrprete en procesos cun ritmo de cambio inferior ao do
tempo de ciclo mximo. En (3.3.2.4) descrbese un algoritmo de interpretacin Grafcet que
garante a reactividade supoendo o caso ideal no que este tempo instantneo comparado co
tempo de resposta requirido polo proceso (hiptese de causalidade nula). Sen embargo na
prctica esta hiptese ideal relxase, e considrase que o interprete garante a reactividade se o
seu tempo de ciclo inferior ao tempo de resposta mximo pennitido polo proceso (esta
aproximacin semellante utilizada nos PLCs). En (7.2.1.4.2) explcase unha tcnica que
utiliza os tempos de monitorizacin das varibeis de entrada para reducir en parte este
problema.
O intrprete Grafcet foi deseado aproveitando o mecanismo de substitucin dinmica de
mdulos (7.1.1.5) para configurar diferentes aspectos da sa arquitectura, como a obtencin
dos eventos do proceso ou o tipo de semntica (3.3.2.2) a utilizar na interpretacin dos
modelos. O resultado un intrprete cunha arquitectura flexbel que pode ser utilizado en
diferentes aplicacins, como por exemplo: a simulacin e control de sistemas dirixidos por
347
Captulo 8: O intrprete de modelos Grafcet
348
eventos, a anlise de extensins ao Grafcet que afecten aos algoritmos de interpretacin, a

emulacin de PLCs, etc.
A organizacin deste captulo a seguinte: a arquitectura do intrprete presentada no
apartado (8.1) e a sa implementacin en (8.2); os mdulos e parmetros que permiten
configurar o intrprete son detallados en (8.3); o apartado (8.4) describe os detalles do seu
funcionamento; a informacin utilizada durante a interpretacin dun modelo Grafcet detllase
en (8.5); a implementacin da poltica de execucin e as tcnicas utilizadas para optimizar a
avaliacin de condicins e a execucin de accins explcanse en (8.6); finalmente, no apartado
(8.7) resmense as conclusins do captulo.
8.1. Arquitectura do intrprete

O intrprete Grafcet ten unha arquitectura lxica composta polos mdulos mostrados na
Figura 8.1. Os rectngulos cun contorno mis fino correspndense con mdulos que poden ser
substitudos dinamicamente para modificar a configuracin do intrprete. Esta arquitectura
basease na proposta en [114] para a interpretacin do Grafcet en sistemas sncronos, e nela
poden distinguirse catro compoentes principais:
1. O xestor de eventos, que se encarga do manexo dos eventos recibidos polo intrprete a
travs do canal de entrada do subsistema de aplicacin. A configuracin e o funcionamento
do xestor de eventos poden modificarse mediante dous mdulos substitubeis que definen a
poltica de acceso (8.3.1.1) e a de reaccin (8.3.1.2).
2. O algoritmo de interpretacin, que o mdulo encargado de interpretar os modelos
Grafcet. Este algoritmo pode ser substitudo dinamicamente, de xeito que un mesmo
intrprete poda utilizar diferentes algoritmos. Ademais cada algoritmo pode configurarse
mediante dous mdulos substitubeis que definen a poltica de evolucin dos modelos
(8.3.1.4) e a de execucin do seu cdigo (8.3.1.5).
3. A interpretacin Grafcet ou xogo Grafcet, que o mdulo que contn a informacin
estructural do modelo, o cdigo de accins e condicins e a informacin asociada ao estado
da sa evolucin.
4. O xestor de sada, que xestiona o envo de mensaxes co valor das sadas modificadas
durante a evolucin do modelo ao canal de sada do subsistema de aplicacin.
Intrprete Grafcet
Xestor Eventos
Poltica de Reaccin
Poltica de Acceso
Algoritmo de Interpretacibn Interpretacin

Grafcet
Poltica de Politica de
Xestor Saida
Execucin Evolucion
Ncleo da Mquina Virtual

Figura 8.1. Arquitectura de mdulos do intrprete Grafcet.
8.2. Implementacin da arquitectura do intrprete

O intrprete representado mediante a clase SingleGrafcetPlayer, cuxas relacins de
especializacin e agregacin son mostradas no diagrama da Figura 8.2. Como se mostra neste
diagrama, as instancias desta clase son procesos que implementan a interface IGrafcetPlayer e
que inclen os mecanismos para o almacenamento de mdulos (7.1.1.3) e configuracins
349
Seccin 8.2: Implementacin da arquitectura do intrprete
(7.1.1.4), derivndoos respectivamente das clases ModuleStore e ConfigurationStore. A sa

estructura se forma mediante a agregacin de mdulos, utilizando o soporte derivado da clase
StructuredModule. O cdigo da declaracin da interface IGrafcetPlayer o seguinte:
2795.struct IGrafcetPlayer
2796. {
2797.
// control do estado do intrprete
2798.
2799.
2800.
virtual void Resume() = 0;
2801.
2802.
2803.
2804.
// control da execucin do modelo Grafcet
virtual bool loadModel(RTModel* model) = 0;
2805.
virtual bool unloadMOdel(const string& id) = 0;
2806.
virtual bool playModel(const string& model, // modo continuo
2807.
TimeScale ev,
2808.
TimeScale st,
2809.
bool act,
2810.
bool retrig,
2811.
IVMServices* vm) = 0;
2812.
2813. . virtual bool playModel(const string& model, // modo paso a paso
TimeScale ev,
2814.
2815.
2816.
2817.
2816.
2819.
2820.
TimeScale st,
bool act,
bool retrig,
IVMServices* vm,
pfn callback,
IAsyncClbkArg* parg = NULL) = 0;
virtual bool nextModelEvolution(const string& model) = 0;
2821,
virtual bool stopModel(const string& model) = 0;
2822.
virtual bool abortModel(const string& model, unsigned err_code = 0) = 0;
2823.
2824 . } ;
Os mtodos declarados nas lias 2798-2803 son comns aos declarados na interface
IVMProcess (7.1.2.1) para o control e consulta do estado de execucin dun proceso. A carga e
descarga de modelos Grafcet na memoria do intrprete realzase mediante os mtodos
IoadModel (lia 2805) e unloadModel (lia 2806). Os modelos Grafcet estarn representados
utilizando o formato xerado polo compilador Grafcet (6.4). Os demais mtodos son os que
controlan a execucin do modelo. O mtodo playModel, que ten das versins, utilizado para
iniciar a execucin do modelo, unha versin o executa de forma continua (lia 2807) e a outra
(lia 2813) o executa no modo paso a paso (ciclo a ciclo). Esta segunda versin enva unha
notificacin asncrona (7.1.2.4.2) mquina virtual cada vez que remata unha evolucin do
modelo e agarda a que se invoque o mtodo nextModelEvolution (lia 2821) para iniciar a
seguinte. Os atributos do mtodo playModel permiten configurar a interpretacin do modelo
segundo se explica en (8.3.2). Os mtodos stopModel (lia 2822) e abortModel (lia 2823)
serven para deter a execucin do modelo, o primeiro remata a evolucin actual antes de detelo
e o segundo deteno inmediatamente sen rematar a evolucin actual.
No que se refire as relacins de agregacin definidas para representar a estructura do
intrprete Grafcet (Figura 8.2), as agregacins input e output referencian aos xestores de
eventos e sadas respectivamente, que son modelados mediante as clases GrafcetPlayerlnput e
GrafcetPlayerOutput. A agregacin algorithm referencia ao algoritmo de interpretacin, que
unha instancia dunha clase que implemente a interface IGrafcetPlayerAlgorithm. Finalmente, a
interpretacin do modelo Grafcet representada coa clase GrafcetGame, que referenciada
mediante a agregacin game. O intrprete accede aos servicios proporcionados polo ncleo da
350
mquina virtual mantendo unha referencia -agregacin vmachine- a unha instancia da clase
IVMServices (7.3.3) que recibe como argumento do mtodo playModel (lia 2807).
IGrafcetPlayer
IStructuredStoreModule
(from Module^
VMProcess
(from Prooeaes)
ConfigurationStore
(from Modula^
StructuredModule
(from Module^
ModuleStore
(from Modulefj
GrafcetPlayerlnput
gatherôlicy
reactôlicy
SingleGrafcetPlaye
algorithm
output
GrafcetPlayer0utput
game
vmachine
GrafcetGam^
(from Oratcel pama)
ReactivenessPolicy
GatheringPolicy
IGrafcetPlayerAlgorithm
GrafcetPlayerAlgorithm
runôlicy
NMServices
(}rom Virtual Machina
I RunningPolicy
êvolveôlicy
1
EvolutionPolicy
Figura 8.2. Diagrama das clases utilizadas para implementar a estructura do intrprete Grafcet.
A estructura do intrprete compltase coas agregacins definidas nas clases

GrafcetPlayerlnput e GrafcetPlayerAlgorithm para referenciar aos mdulos substitubeis que
permiten modificar a sa configuracin. No caso da clase GrafcetPlayerlnput, a agregacin
gatherôlicy referencia poltica de acceso aos eventos que modelada mediante a clase
GatheringPolicy, e a agregacin reactôlicy referencia poltica de reaccin que modelada
mediante a clase ReactivenessPolicy.
No referente clase GrafcetPlayerAlgorithm, derivada de IGrafcetPlayerAlgorithm, tamn
define das relacins de agregacin: evolveôlicy que referencia poltica de evolucin de
modelos, representada mediante a clase EvolutionPolicy, e runôlicy poltica de execucin
do cdigo dos modelos, representada mediante a clase RunningPolicy.
Ntese que a arquitectura mostrada na Figura 8.1 correspndese cun intrprete que xestiona
unha nica interpretacin dun nico modelo. Utilizando a mesma arquitectura posbel
implementar intrpretes que xestionen mltiples interpretacins dun ou varios modelos
diferentes, simplemente substitundo o algoritmo de interpretacin e almacenando varios xogos
simultaneamente.
8.3. Configuracin do intrprete

A configuracin da arquitectura e do funcionamento do intrprete realzase utilizando das
tcnicas diferentes: mediante o mecanismo de carga, descarga e substitucin dinmica de
mdulos utilizado na implementacin da mquina virtual (7.1.1.5), e mediante parmetros que
351
Seccin 8.3: Configuracin do intrprete
dada unha configuracin especfica modifiquen certos aspectos do seu funcionamento. A

continuacin descrbense os detalles das das tcnicas utilizadas.
8.3.1. Mdulos substitubeis no intrprete

Como pode verse na Figura 8.1 na arquitectura do intrprete poden substiturs ata cinco
tipos distintos de mdulos que modifican diferentes aspectos do seu comportamento:
1. A poltica de acceso aos eventos detectados no proceso.
2. A poltica de reaccin diante dos eventos detectados no proceso.
3. O algoritmo de interpretacin.
4. A poltica de evolucin dos modelos.

5. A poltica de execucin do cdigo dos modelos.
A Figura 8.3 mostra o diagrama de clases dos diferentes mdulos definidos na versin actual
do intrprete para configurar a sa estructura. A continuacin descrbese a funcionalidade e as
posbeis configuracins de cada un dos tipos de mdulos indicados.
IStructuredModule
(from MoEules)
IModule
(irom MoCUIe^
^
I G rafc et P l a y e rAl g o rit h m
initializeGame( )
evolveGame( )
finishGame( )
^
GrafcetPlayerAlgorithm
Component _
StructuredModule
(from MoOUIe^
RunningPolicy
run()
evaluate( )
calculateTimers( )
EvolutionPolic
^ ^ ^ Decorator
SimpleEvolutionPo lic
Com oundEvolutionPolic
WoSR
ReactivenessPolicy
^
D ef a u I t R e a ct ive n e s s P o I i c y
evolve( )
DefaultRunningPolicy
OnUnmanagedEvents( )
OnUnexpectedEvents()
{Pattem)
Decorator = (
Component,
Decorator
}
WSR
GatheringPolicy
onlnputEvents( )
getlnputEvents( )
^
GatherAllPolicy
^
GatherFirstPolicy
Figura 8.3. Diagrama de clases dos mdulos utilizados para configurar o intrprete Grafcet.
8.3.1.1. A poltica de acceso aos eventos

Este mdulo utilizado para realizar o acceso aos eventos almacenados no canal de entrada
do subsistema de aplicacin no que se executa o intrprete. Como pode verse na Figura 8.3 a
poltica de acceso est representada mediante a clase GatheringPolicy, que declara dous
mtodos virtuais a redefinir nas clases derivadas:
1. onlnputEvents, invocado cando hai novos eventos de entrada para filtrar os que non sexan
considerados vlidos. A implementacin por defecto deste mtodo unicamente almacena os
eventos recibidos sen realizar ningn filtrado.
2. getlnputEvents, invocado polo xestor de eventos para seleccionar o(s) evento(s) de entrada
a considerar na seguinte evolucin do modelo. Dos eventos almacenados polo mtodo
onlnputEvents, este mtodo selecciona os que van ser utilizados na seguinte evolucin. Na
versin actual do intrprete hai das posibilidades, representadas na Figura 8.3 mediante as
352
clases GatherAllPolicy e GatherFirstPolicy, que devolven respectivamente todos os

eventos almacenados e unicamente o primeiro dos eventos almacenados.
8.3.1.2. A poltica de reaccin
A poltica de reaccin, representada na Figura 8.3 mediante a clase ReactivenessPolicy,
permite configurar o comportamento do intrprete ante algunha das circunstancias seguintes:
1. A ocorrencia de eventos de entrada non significativos. Considrese o modelo Grafcet da
Figura 8.4 no que a situacin actual S={2, 3, 7} e as varibeis de entrada do proceso son
a, b, e c, todas booleanas e independentes entre si. O conxunto de posbeis eventos de
entrada do modelo ser polo tanto E_{'a, â, Tb, ^b, Tc, ^c}. Sexa I E o conxunto de
eventos a considerar nun momento determinado para avaliar as condicins das transicins
validadas e, se o caso, iniciar unha nova evolucin do modelo. Este conxunto ser
significativo (pode provocar o franqueamento dunha transicin) unicamente se contn
eventos que afecten s varibeis das transicins validadas, neste exemplo {Ta, .â, Tb, .^b}.
Os eventos que non pertenzan a este conxunto poden descartarse pois non modifican a
situacin do modelo'^.
b. c
2 I I 3 I
a
4
a.b
Figura 8.4. Grafcet utilizado como exemplo.
2. A ocorrencia dun evento de entrada durante unha evolucin do modelo. Como se explica en
(3.3.2.4), a interpretacin reactiva dun modelo Grafcet basease na hiptese ideal da
causalidade nula, na que o tempo de evolucin do modelo instantneo comparado co
tempo de resposta esixido polo proceso. Isto implica que non existe a posibilidade de que
se reciba un novo evento mentres se realiza unha evolucin iniciada pola ocorrencia dun
evento anterior. Sen embargo nunha aplicacin real non posbel garantir esta hiptese e
moitos sistemas funcionan proporcionando un tempo de resposta o suficientemente rpido,
comparado co do proceso, para permitir o procesamento de todos os eventos de entrada cun
retraso aceptbel.
A clase ReactivenessPolicy declara os mtodos virtuais onUnexpectedEvents e
onUnmanagedEvents que poden ser redefinidos nas clases derivadas para configurar a resposta
nas circunstancias anteriores dependendo da utilizacin que se estea a facer do intrprete. Na
" Ntese que este un exemplo simple, nun caso real habera que ter en conta tamn as condicins das
temporizacins e das accins condicionais asociadas a etapas activas.
353
Seccin 8.3: Configuracin do intrprete
implementacin por defecto, proporcionada pola clase DefaultReactivenessPolicy, todos os

eventos son considerados como significativos e os eventos recibidos durante unha evolucin do
modelo son almacenados para o seu procesamento posterior.
8.3.1.3. O algoritmo de interpretacin
A interface IGrafcetPlayerAlgorithm (Figura 8.3) declara os mtodos que permiten iniciar,

evoluir e finalizar a execucin do algoritmo de interpretacin de modelos Grafcet. A clase
derivada GrafcetPlayerAlgorithm, que proporciona a implementacin por defecto, unha
aplicacin do patrn de deseo "template method" [67]. dicir, esta clase proporciona a
estructura xenrica do algoritmo de interpretacin, que para realizar a evolucin do modelo e
para executar o cdigo utiliza os mtodos proporcionados polas polticas de evolucin e
execucin respectivamente.
Como pode verse na Figura 8.3, a versin actual da mquina virtual proporciona dous
algoritmos de interpretacin diferentes, representados mediante as clases SIEPZayerAlgorithm e
NSIEPIayerAlgorithm. A diferencia entre ambos est no momento no que teen en conta os
eventos do proceso recibidos durante unha evolucin do modelo Grafcet. Na Figura 3.37
mstrase un exemplo das diferencias na interpretacin dun modelo cando os eventos xerados
pola sa evolucin (cambios no estado das etapas e das varibeis internas) son considerados na
escala de tempo interna ou na externa. A interpretacin mostrada considera un caso ideal no
que a resposta do sistema instantnea dende o punto de vista externo e, en consecuencia, non
existe a posibilidade de que se reciba un novo evento do proceso mentres se realiza unha
evolucin do modelo.
Mais, como se comentou anteriormente, isto non posbel garantilo na prctica, polo que ao
final dunha evolucin pode haber eventos do proceso, recibidos durante a evolucin do modelo,
agardando a ser procesados. Se o intrprete se configura para considerar no tempo externo (na
seguinte evolucin externa) os eventos internos producidos durante a evolucin do modelo,
pode darse o caso de que ao final dunha evolucin se tean tanto eventos de proceso como
eventos producidos pola evolucin do modelo pendentes de ser procesados. O algoritmo
SIEPlayerAlgorithm ten en conta simultaneamente ambos tipos de eventos, mentres que o
algoritmo NSIEPIayerAlgorithm da prioridade aos eventos producidos pola evolucin do
modelo. O pseudocdigo seguinte mostra a diferencia entre ambos algoritmos:
2825.
// SIBPlayerAlgorithm
2826.
events = fZ)
2827.
2828.
2829.
2830.
2831.
2832.
while (!end)
process_events = getlnputEvents()
events = events + process_events
model_events = evolveGame(events)
events = model_events
end while
2833.
// NSZBPlayerAlgorithm
2834.
events = fC3
2835.
while (!end)
2836.
2837.
process_events = getZnputEvents()
events = process_events
2838.
while
2839.
2840.
2841.
2842.
(!events.empty())
model_events = evolveGame(events)
events = model_events
end while
end while
354
8.3.1.4. A poltica de evolucin

A poltica de evolucin, representada na Figura 8.3 mediante a clase EvolutionPolicy, a
que realiza a evolucin dun modelo Grafcet dende a sa situacin actual seguinte tendo en
conta os parmetros de configuracin do intrprete, os valores das varibeis do proceso e os
eventos detectados. Como pode verse na Figura 8.3 na versin actual da mquina virtual
inclense das polticas de evolucin diferentes representadas mediante as clases WoSR e WSR,
que se corresponden cos algoritmos de evolucin sen e con busca de estabilidade (3.3.2.2).
Ntese que para permitir o reaproveitamento das polticas de evolucin aplicouse o patrn de
deseo "Decorator" [67], definndose dous tipos de polticas: as simples, instancias da clase
SimpleEvolutionPolicy, e as compostas, instancias da clase CompoundEvolutionPolicy. As
compostas son implementadas mediante composicin reaproveitando as polticas simples ou
compostas xa existentes. A poltica WSR un exemplo de poltica composta implementada
reaproveitando a poltica simple WoSR.
8.3.1.5. A poltica de execucin
A poltica de execucin, representada na Figura 8.3 mediante a clase RunningPolicy, a que
xestiona a execucin do cdigo do modelo Grafcet: avaliacin de condicins, execucin de
accins e control de temporizacins; as como o acceso aos servicios do ncleo da mquina
virtual. A clase DefaultRunningPolicy proporciona a implementacin por defecto desta poltica
que explica con detalle en (8.6).
8.3.2. Parmetros de interpretacin dos modelos

As configuracins que utilizan unha poltica de evolucin tipo WSR manexan a situacin do
modelo en das escalas temporais diferentes, a correspondente ao punto de vista externo (do
proceso) e a do punto de vista interno (do sistema de control). Como se explica en (3.3.2.6), a
utilizacin de das escalas de tempo permite diferentes alternativas segundo se consideren os
eventos, valores de varibeis e accins internas. O intrprete permite configurar estes aspectos.
mediante tres parmetros que son pasados como argumentos do mtodo playModel (lia 2807)
cando se inicia a execucin dun modelo. Os valores destes parmetros indican:
1. Se os eventos externos son considerados como eventos ou como constantes na escala
interna.
2. Se os cambios nas varibeis e estados das etapas do modelo despois dunha evolucin
interna son tomados en consideracin na seguinte evolucin interna ou na seguinte
evolucin externa.
3. Se utilizar ou non accins internas -includas as ordes de forzado (3.3.2.5^ durante as
evolucins internas do modelo.
A Tboa 8-I resume as diferentes configuracins que pode adoptar o intrprete utilizando os
tipos de mdulos e parmetros explicados.
8.4. Funcionamento do intrprete

Neste apartado descrbense as principais colaboracins entre os mdulos que forman a
estructura do intrprete coas que se implementa a interpretacin de modelos Grafcet.
355
Seccin 8.4: Funcionamento do intrprete
8.4.1. Ciclo de execucin do intrprete

Na Figura 8.5 mstrase a secuencia de mensaxes da execucin paso a paso dun modelo
Grafcet. O modelo deber estar cargado na memoria do intrprete mediante unha chamada
previa ao mtodo ZoadModel (lia 2805). A execucin inciase coa invocacin da versin con
notificacin asncrona do mtodo playModel (lia 2813), en resposta ao envo dunha mensaxe
PLAY_MODEL dende un cliente remoto. Este mtodo crea e inicia unha nova interpretacin
(xogo) do modelo, almacena os parmetros da notificacin asncrona e desbloquea o intrprete.
A execucin do ciclo realzase no mtodo OnEvent (lia 2032), que obtn do xestor de eventos
os novos eventos de entrada -mtodo getlnputEvents- e almacnaos no xogo -mtodo
storelnputEvents (lia 2859}-, delega a evolucin do modelo no algoritmo de interpretacin
-mtodo evolveGame-, e actualiza, mediante o xestor de sada, os novos valores calculados
para as sadas do proceso -mtodo setOutputValues-.
Ao remate da execucin do ciclo envaselle unha notificacin asncrona mquina virtual
que sa vez enva unha mensaxe OK ao cliente remoto para indicarlle este feito. O seguinte
ciclo non comeza ata que a mquina virtual desbloquee de novo ao intrprete invocando o seu
mensaxe
mtodo
nextModelEvolution
(lia
2821),
en
resposta
a
unha
NEXT_MODEL_EVOLUTION recibida dende o cliente remoto. A execucin do modelo
remata coa invocacin do mtodo stopModel (lia 2822) que finaliza o xogo e o elimina da
memoria do intrprete. Ntese que a secuencia de mensaxes da versin continua sera
semellante explicada coa excepcin da notificacin asncrona e o intercambio de mensaxes
OK e NEXT MODEL EVOLUTION co cliente remoto.
^
Nome
WOSR_FIRST
WORST_ALL
WSR_SIE
WSR_NSIE
Mdulos
Acceso = GatherFirstPolicy
Reaccin = DefaultReactivenessPolicy
Algoritmo = SIEPlayerAlgorithm
Evolucin = WoSR
Execucin = De aultRunnin Polic
Acceso = GatherAllPolicy
Evolucin = WoSR
Evolucin = WSR
Algoritmo = NSIEPIayerAlgorithm
Evolucin = WSR
Execucin = De aultRunnin Poli
Parmetros
N/A
N/A
Eventos externos = eventos/constantes internas

Valores internos = evolucin interna/externa
Ordes internas = Si/Non
Eventos externos = eventos/constantes internas

Valores internos = evolucin interna/externa
Ordes intemas = Si/Non
Tboa 8-I. Configuracins do intrprete Grafcet.
356
-^----------- --- ---- -- --- -----^-- ---
si I
a P
r
^----^-^----
B
@
c3
^
&
^
.6_
i
m^
î
^ ^ ^
^^^ ^ P
"
.^
^ ^ g
8
-
^
8
,^ v ,^ II
Rg
^
"
^^
;^
^!
$^
^':
Î
4i
^;
gi
^
^
ti
Figura 8.5. Secuencia de mensaxes do ciclo de execucin do intrprete Grafcet.
357
8.4.2. Obtencin de eventos de entrada

A Figura 8.6 mostra as mensaxes da colaboracin para a obtencin de novos eventos de
entrada. Cando invocado o mtodo getlnputEvents no xestor de eventos, este consulta a
existencia de eventos almacenados na poltica de acceso e, se non hai ningn, obtn os eventos
almacenados no canal de entrada do subsistema de aplicacin. En caso de haber novos. eventos
estes sern almacenados na poltica de acceso mediante o mtodo onlnputEvents, que filtra os
non significativos e os non vlidos (8.3.1.1). O manexo dos eventos filtrados realzase na
poltica de reaccin -mtodos onUnmanaged e OnUnexpected, respectivamente-. A versin
por defecto destes mtodos non filtra ningn evento, considerando que todos son significativos
e vlidos. Por ltimo reptese a consulta poltica de acceso que agora almacena os novos
eventos obtidos do canal de entrada. Ntese que nesta implementacin os eventos de entrada
non son procesados mentres anda haxa eventos dos previamente almacenados na poltica de
acceso (procesamento por antigiiidade).
GrafcetPlayednout
a3ther odicv:GatherinaPalia
ym:IVMServices
react oolicv:DefaultReactivenessPolia
input events = getlnputEvents(vm) , ;

input events = getlnputEvenffiQ
[nput_events. em p1yQ]
;
new events = geUnputEvenffiQ _ ;
unmanaged, unexpected = anlnputEvents(new evenffi)

onUnmanaged(unmanaged) ;
onUnexpeded(unexpeGed) ;
input everds = getlnputEventsQ
Figura 8.6. Secuencia de mensaxes da obtencin de novos eventos de entrada.
8.4.3. Iniciacin e evolucin do modelo

A clase GrafcetPlayerAlgorithm, derivada da interface IGrafcetPlayerAlgorithm (Figura
8.3), proporciona a implementacin por defecto dos mtodos initializeGame e finishGame, que
permiten iniciar e finalizar a interpretacin de modelos Grafcet. A Figura 8.7 mostra a
secuencia de mensaxes da colaboracin que implementa o primeiro destes mtodos. A
iniciacin realzase activando as etapas da situacin inicial do modelo -regra 1 de evolucin
(3.3.1.1}-, executando as accins internas activas na situacin inicial e facendo a evolucin
inicial do modelo considerando os eventos xerados durante a activacin da situacin inicial. No
que respecta ao mtodo para finalizar a interpretacin, non ten implementacin na versin
actual.
A Figura 8.8 mostra a secuencia de mensaxes da implementacin do mtodo evolveGame na
clase SIEPIayerAlgorithm, que modela un tipo de algoritmo de eyolucin que considera
simultaneamente os eventos producidos pola evolucin do modelo e os detectados no proceso
durante a evolucin (8.3.1.3). O mtodo realiza a evolucin externa do modelo actualizando
no xogo Grafcet os eventos a considerar -mtodo updateEvents (lia 2861^, realizando as
operacins relacionadas coa xestin dos temporizadores -mtodo calculateTimers-,
delegando na poltica de evolucin a evolucin do modelo -mtodo evolve-, almacenando
no xogo Grafcet os novos eventos xerados pola evolucin -mtodo storeNewEvents (lia
2862}- e delegando na poltica de execucin a execucin das accins activas -mtodo run-.
A implementacin deste mesmo mtodo na clase NSIEPIayerAlgorithm consiste nun bucle que
repite a secuencia anterior ata que non haxa mais eventos producidos pola evolucin do
modelo.
358
---------------------------------------------------------- -------------
.^
^
^
mc
>
mE
m
^
m
c
L
W
F
2
N
H
d
>
m
m
W
t
>
L
c
L
U
{O
E
>
m
E
z
^
d
E
^
E
F=
w
^
>
z
^
^
A
^
6
lq
^
^
^
^
G I
.____^ _____._*_____*__..
u
^ ^
L
C
C C
N m ^
^ W
.^
^
_ ^
.C
Om
^
m
CD
p>^.
^ m l0
d^
f./ O
^mo
wmda
9sO^^
c5 E î
ôcoc
'oovo
W
C
{00
ma
ro
vm
m
^,coc
^ l0 ^
mx ^ ^
V V
A
mx
W W ^ ^!A
W ^y
Figura 8.7. Secuencia de mensaxes da evolucin inicial dun modelo Grafcet.
359

alaorithm: GrafcetPl ayerAlgorithm
aame:GrafcetGame
[un oolicv:DefaultRunninaPolicv
evolve oolia:EvolutionPolicv
evolveGame(game, vm) ;
updateEvents()
qlculateTimers(game, vm)
evolve(game, vm, runôlicy) :
storeNewEventsQ
run(game, vm)
^
Figura 8.8. Secuencia de mensaxes da evolucin externa dun modelo Grafcet.
8.4.4. Actualizacin das sadas do proceso

A Figura 8.9 mostra a secuencia de mensaxes mediante a que se realiza a actualizacin na
base de datos de E/S dos valores das sadas do proceso modificados como resultado da
evolucin do modelo. O mtodo setOutputValues na clase GrafcetPlayerOutput accede aos
valores modificados almacenados no xogo Grafcet e, para cada un deles, enva unha mensaxe
porta de sada do subsistema de aplicacin. Estas mensaxes son procesadas pola base de datos
de E/S, que actualiza a imaxe do proceso cos valores recibidos. A sincronizacin desta imaxe
co proceso (7.3.1.3) realzase cando o intrprete invoca o mtodo setOutputYalues (lia 2661)
dos servicios do ncleo da mquina virtual.
8.4.5. Poltica de evolucin

A poltica de evolucin responsbel da evolucin da situacin dos modelos. Como se
explica en (8.3.1.4), na versin actual do intrprete existen das posibilidades: a poltica
WoSR, que realiza unha evolucin sen busca de estabilidade (SRS), limitndose a aplicar as
regras de evolucin 2 5(3.3.1) avaliando as transicins validadas e calculando a nova
situacin despois do franqueamento simultneo das que cumpran a condicin de transicin; e a
poltica WSR, que reutiliza a poltica WoSR engadndolle a comprobacin da estabilidade da
nova situacin, a deteccin de ciclos estacionarios e a execucin de accins internas. A Figura
8.10 mostra a secuencia de mensaxes da colaboracin que implementa o mtodo evolve na
poltica WSR.
8.4.6. Deteccin de ciclos estacionarios

Cando se utiliza o algoritmo de interpretacin con busca de estabilidade (ARS) preciso
detectar a existencia de ciclos estacionarios para evitar que o modelo evolucione sen alcanzar
nunca unha situacin estbel (3.3.2.2). O algoritmo descrito en [25] basase no
almacenamento das situacins internas polas que evoluciona o modelo detectando a existencia
de situacins duplicadas. Sen embargo, como se indica en [76], a utilizacin de varibeis non
booleanas, cuxos valores podan ser modificados e consultados durante as evolucins internas
do modelo, pode dar lugar a que ese algoritmo detecte incorrectamente ciclos estacionarios en
evolucins vlidas.
Considrese o exemplo mostrado na Figura 8.11, na que as accins internas son indicadas
escribindo o seu tipo entre corchetes e a interpretacin utilizada considera os cambios nos
valores internos das varibeis na seguinte evolucin interna. Neste exemplo, despois da
deteccin do evento Ta, exectase a accin interna asociada desactivacin da etapa i-1 que lle
asigna varibel c o valor de k. Se k 5 a evolucin do modelo ser {i-1 }^(i)^(i+2)-^..., sen
360
embargo se k<5, o modelo evolucionar a travs do ciclo (i)-^(i+l) e o algoritmo detectar a

existencia dun ciclo estacionario {i-1}->(i)-^(i+l)-^(i)-^..., o cal non correcto xa que a
situacin volvese estbel despois dun nmero de iteracins igual a 5-k, supoendo k>_0. Isto
implica que o resultado do algoritmo de deteccin de ciclos estacionarios depender do valor de
k.
N
N
7
i
^
a
^
--------------------^
------^ -------------- --
^. ^
^
>
^
Î
N
N
^ÎI
l0 .-.
> m
C
_ ^
N >
> ^
L ^p
U y
l0
y U
^ V
O V
d
C
l0
>
E
m
rn
l0
Figura 8.9. Secuencia de mensaxes da actualizacin das sadas do proceso.
361
- -------------------------------^ -----------------------^-------------------------^^------Z
^^
>
m
E
^
W
H
Z
^
F
^
>
m
E
Z
^
W
H
Z
F
ai
c
b
a
---- -t-------------
--'------------'----'--...
Z
K
^
c
O
^
Î
m
c
^
w^
^
c
m
D)
tn
.tl
u
d
.-. Q
p
p
m
W
^
^ m
^
Z
m
^S 10
^ ^
W
d
m
q-
m
~
Z
t:
0;
C:
0^
r:
E
a
^^
^^
^m
^m
^
af ^
C
O_ ^

_j U
^^ m
vD
o f0
0
m$
^
- m
C m C
oao
V O
Em
a^m
m^
^m
m j V
m^
^
m^,^.,
^^m
mQm
^m
9
m
^
v o
oom
`;
i
vma,
gc
E
^^_O
m^
g-
^ c ^
pO
a Ip
^^
a^
om^
v^
m yW
V K>
Eoo^
o_m ^m
amo
E m
0 C
0 ^
p C
2^
'm ^
0
m
cc
o ^
^D
fA
O g
Qv
Figura 8.10. Secuencia de mensaxes da evolucin interna dun modelo Grafcet.
362
i1
[PO] c=k
c>=5
i+1
[P] c=c+1
i+2
true
Anda non existe un mtodo que permita solucionar este problema, requirndose unha
anlise a priori de cada modelo concreto para evitar situacins como a anterior. En [76]
proponse como regra xeral considerar que non existe un ciclo estacionario se o modelo chega
por segunda vez a unha mesma situacin cando esta sexa estbel. Esta proposta non soluciona o
problema mais coherente co algoritmo clsico. A versin actual do intrprete utiliza esta
aproximacin.
8.5. Informacin de interpretacin dun modelo: o xogo Grafcet

A informacin utilizada para a interpretacin dun modelo Grafcet representada mediante a
clase GrafcetGame. O intrprete almacena o estado de execucin de cada modelo utilizando
instancias desta clase. A versin actual do intrprete unicamente permite realizar unha nica
interpretacin dun nico modelo, sen embargo a sa arquitectura modular (Figura 8.1) e a
separacin entre os algoritmos e a informacin de interpretacin dos modelos, facilitar a
implementacin en futuras versins de intrpretes que xestionen mltiples interpretacins dun
ou varios modelos diferentes.
A Figura 8.12 mostra unha versin simplificada das relacins de agregacin da clase
GrafcetGame. A informacin mantida en cada instancia da clase durante a interpretacin dun
modelo a seguinte:
1. Un identificador alfanumrico nico -atributo name-.
2. Os parmetros de interpretacin do modelo (8.3.2) -atributos eventScale, stepScale e
internalActions-.
3. A informacin do modelo no formato de execucin ( 6.4) xerado polo compilador Grafcet
-agregacin model-.
4. Os eventos de entrada considerados na evolucin actual do modelo -agregacin
input_events-.
5. A informacin sobre as transicins, accins, ordes de forzado e temporizadores do modelo
-agregacins receptivities, actions, forders e timers, respectivamente-. As clases
Receptivitylnfo, Actionlnfo, ForcingOrderlnfo e Timerlnfo almacenan a informacin do
estado de activacin dos elementos do modelo citados e xestionan a informacin que
permite optimizar a avaliacin das condicins de transicins, asociacins, temporizadores,
e a aplicacin das ordes de forzado78.
^8 Para evitar introducir aspectos innecesarios sobre a implementacin destas clases non se detalla a informacin
que conteen, sen embargo si se explica en (8.6) a forma en que esta informacin utilizada polo intrprete.
363
Seccin 8.5: Informacin de interpretacin dun modelo: o xogo Grafcet
6. A informacin de interpretacin do modelo dependente da escala de tempo, interna ou

externa, considerada -agregacin time scales-. Cando se utiliza un algoritmo de
interpretacin ARS certos aspectos da informacin de interpretacin do modelo son
diferentes en cada unh das das escalas de tempo utilizadas. A informacin almacenada
no xogo Grafcet para cada escala de tempo representada mediante a clase
GameTimeScale, e consiste no seguinte:
a. A situacin actual (o conxunto de etapas activas) do modelo -atributo situation-.
b. conxunto de transicins validadas na situacin actual -atributo validated_trans-.
c. Os eventos considerados na evolucin actual -agregacin events-.
d. Os valores das varibeis do modelo e das sadas do proceso modificadas a

consecuencia da execucin das accins do modelo -agregacin vars-.
e. O estado de activacin das asociacins -agregacin associations-.
RTModel
ForcingOrderlnfo
(from rafcet runtime model)

^
applyForcingOrder( )
applpForcingOrders( )
Actionlnfo
model
actions
GrafcetGame
Receptivitylnfo
1
receptivities
name : string
eventScale : TimeScale
stepScale : TimeScale
internalActions : bool
^ ^ timers
VMEvent
input_events
(from Prooesses)
time scales
Timerlnfo
GescaDataElement
(from Basio Elements)
2
GameTimeScale
^ situation : RTSituation
validated trans : RTSituation
^
events
associations
Associationlnfo
Figura 8.12. Diagrama das clases utilizadas para modelar un xogo Grafcet.
8.5.1. Implementacin do xogo Grafcet

Os mtodos declarados pola clase GrafcetGame permiten consultar a informacin de
execucin do modelo xerada polo compilador e consultar e actualizar a informacin do estado
da interpretacin do modelo. O seguinte cdigo C++ mostra a declaracin simplificada da sa
interface:
^
2843.class GrafcetGame
2844. {
2845.public:
2846.
// consulta e actualizacin da situacin do modelo
2847.
2848.
2849.
2850.
2851.
2852.
void getInitialSituation(RTSituation& s) const;
void getSituation(RTSituation& s,
TimeScale scale = TSEXTERNAL) const;
void setStartSituation(const RTSituation& s);
void calculate5ituation(const RTSituation& fired_transitions,
TimeScale scale = TSEXTERNAL);
364
2853. // coasulta e sincronizacin das escalas de tempo
2854. bool hasInternalActions() const;
2855.
2856.
bool useTimeScales() const;
void synchronizeTimeScales();
2857. void getModifiedOutputs(deque<GescaDataElement*>& values);
2858. // consulta e actualizacin de eveatos
2859. void storeInputEvents(deque<VMEvent>& events);
2860.
void updateTimerEvents();
2861. void updateEvents(TimeScale scale = TSEXTERNAL);
2862. void storeNewEvents(TimeScale scale = TSEXTERNAL);
2863. bool areNewEvents(TimeScale scale = TSEXTERNAL) const;
2864. // consulta e actualizacin de varibeis
2865. bool getStepState(unsigned long id);
2866. bool getModelVarEvent(const string& id, bool updown);
2867. bool getSystemVarEvent(const string& id, bool updown);
2869.
bool getData(const string& id,
2870.
T& value,
2871.
2872.
2873.
2874.
2875.
TimeScale ts = TSEXTERNAL);
template <class T>
bool setData(const string& id,
const T& value,
TimeScale ts = TSEXTERNAL);
2876.
// acceso s receptividades, accins e temporizadorea activos
2877.
2878.
void getValidatedReceptivities(deque<ReceptivitySchedulelnfo>& val_recs,
2879.
2880.
void getActionAssociations(deque<AssociationScheduleInfo>& act_assocs,
deque<AssociationScheduleInfo>& deact_assocs,
2881.
2882.
2883.
2884.
2885.
2886.
2887. }
void getActions(deque<ACtionScheduleInfo>& action_seq);
void getACtiveTimers(deque<TimerScheduleInfo>& t);
// acceso s funcins co cdigo C++ de condicins e accins
pfnCond getCondition(const string& name) const;
pfnCode getAction(const string& name) const;
A continuacin detllanse algns aspectos relacionados coa utilizacin e implementacin

dos mtodos declarados na interface pblica da clase GrafcetGame.
8.5.1.1. Consulta e actualizacin da situacin do modelo
Os mtodos getlnitialSituation (lia 2847) e getSituation (lia 2848) permiten consultar a
situacin inicial do modelo (o conxunto de etapas iniciais) e a situacin actual almacenada na
escala de tempo indicada. O mtodo setStartSituation (lia 2850) establece a situacin de
partida das evolucins do modelo, que pode ser a inicial ou outra situacin calquera. Este
mtodo invocado durante a iniciacin da interpretacin do modelo (8.4.3), e o pseudocdigo
seguinte mostra as operacins realizadas na sa implementacin:
2888 . void GrafcetGame::setStartSituation(const RTSituation& s)
2889 {
2890. scale = useTimeScales()
2891. // aplicar ordes de forzado
2892. if (scale && internalActions)
2893.
initial_situation = forders.applyForcingOrders(s, 0, f^, model->static_model)
2894.
end if
2895. // iniciar na escala de tempo correspondente a
2896. // informacin da situacin actual, transicias validadas,
2897.
// e asociacins activas.
2898. time_scales[scaleJ.setSituation(initial_situation)
2899. time_scales(scale].calculateValidatedTransitions(model->static_model)
2900. time_scales[scale].updateAssociationlnfo()
2901 . }
365
O mtodo comeza determinando cal a escala de tempo a modificar, en caso de ser a escala
interna e estar activadas as accins internas aplcanse as ordes de forzado activas na situacin
indicada, que poden modificar a situacin de partida. Coa nova situacin calculada actualzase
a informacin almacenada na escala de tempo afectada, utilizando os mtodos da clase
_
GameTimeScale que se explican en (8.5.2).
O mtodo calculateSituation (lia 2851) invocado dende a poltica de evolucin (8.4.5)
para calcular a nova situacin do modelo, recibindo como parmetros o conxunto de transicins
a franquear na situacin actual e a escala de tempo na que se realiza a evolucin. O
pseudocdigo seguinte mostra as operacins realizadas na sa implementacin:
2902.void
2903. GrafcetGame::calculateSituation(const RTSituation& fired_transitions,
TimeScale scale)
2904.
2905. {
2906.
2907.
2908.
2909.
2910.
2911.
2912.
2913.
current_situation = time_scales[scale].situation
// calcular etapas activadas e desactivadas
2914.
// aplicar ordes de forzado
if (scale && internalACtions)
enabled, disabled = forders.applyForcingOrders(current_situation,
enabled,
disabled,
model->static_model)
2915.
2916.
2g17,
2glg.
2glg.
2920.
2921.
2922.
2923.
2924.
2925.
2926.
2927.
2928.
2929.
2930.
2931.
2932. }
enabled = Q)
disabled = fZ
for each transition (t) in fired_transitions
enabled = enabled U t.after
disabled = disabled U t.before
end for
end if
// calcular nova situacin
// as etapas que son activadas e desactivadas simultaneamente
// mantense activas (regra 5 de evoluci n ( 3.3.1.5))
new_situation =(current_situation - disabled) U enabled
// actualizar na escala de tempo correspondente a
// informacin da situacin actual, transicina validadas,
// e asociacins activas.
time_scales[scale].setSituation(new_situation)
time_scales[scale].calculateValidatedTransitions(model->static_model,
fired_transitions)
time_scales[scale].updateAssociationInfo()
O mtodo comeza determinando os conxuntos de etapas a activar e desactivar tendo en conta

a situacin actual do modelo e o conxunto de transicins a franquear. Se as accins internas
estn activadas e a evolucin se realiza na escala interna, aplcanse as ordes de forzado que
poden modificar os conxuntos de etapas a activar e desactivar. Unha vez aplicadas as ordes de
forzado, calclase a nova situacin e actualzase a informacin almacenada na escala de tempo
afectada.
Nos dous mtodos anteriores as ordes de forzado do modelo aplcanse mediante o mtodo
applyForcingOrders da clase ForcingOrderlnfo respectando os postulados temporais
explicados en (3.3.2.5). Este mtodo utiliza a informacin sobre os niveis da xerarqua de
forzado xerada polo compilador Grafcet para determinar o conxunto de etapas a activar e
desactivar nunha situacin dada. O pseudocdigo da versin simplificada do algoritmo
utilizado o seguinte:
366
2933.void
2934.
ForcingOrderlnfo::applyForcingOrders(const RTSituation& current,
2935.
RTSituation& disabled,
2936.
RTSituation& enabled,
2937.
const RTStaticModel& model)
2938. {
2939.
2940.
2941.
2942.
2943.
2944.
2945.
2946.
2947.
2948.
2949.
2950.
2951.
2952.
2953.
2954.
2955.
2956.
2957.
2958.
2959.
2960.
2961.
2962.
2963. }
forcedârtial_grafcets = QJ
// aplicar ordea reapectando aiveis da xerarqua de forzado
for each level (1) in model.FO_levels
// calcular situacia previa aplicacin das ordes do aivel
situation_before =(current - disabled) U enabled
// aplicar ordes de cada grafcet parcial "forzador no nivel
for each partial grafcet (pg) in 1
// obter etapas activas do grafcet parcial con ordes asociadas
forder_steps = pg.fosteps f1 situation_before
for each step (s) in forder_steps
/ / obter ordea de forzado asociadas etapa
active_forders = model.forcing_orders[s]
for each forcing order (fo) in active_forders
// comprobar se outra orde forza o mesmo grafcet parcial
if (fo.fpg in forcedârtial_grafcets)
indicar error (forzado mltiple)
end if
forcedârtial_grafcets.insert(fo.fpg)
/ / aplicar orde de forzado
applyForcingOrder(fo, current, disabled, enabled, model)
end for
end for
end for
end for
Como pode verse as ordes de forzado son aplicadas respectando a orde dos niveis da
xerarqua de forzado. En cada nivel obtense e aplcanse as ordes de forzado asociadas s
etapas activas dos grafcets parciais do nivel. O algoritmo comproba que non se producen
situacins de forzado mltiple (3.3.2.5) almacenando no conxunto forcedârtial grafcets os
identificadores dos grafcets parciais forzados polas ordes que van sendo aplicadas e
comprobando que non existan duplicados antes de aplicar unha nova orde. A aplicacin de cada
orde realzase mediante o mtodo privado applyForcingOrder da clase ForcingOrderlnfo, que
modifica os conxuntos de etapas a activar e desactivar como resultado da evolucin do modelo.
O pseudocdigo da versin simplificada deste mtodo o seguinte:
2964.void
ForcingOrderInfo::applyForcingOrder(const RTFOInfo& fo
2965.
const RTSituation& current,
RTSituation& disabled,
RTSituation& enabled,
const RTStaticModel& model)
2966.
2967.
2968.
2969.
2970. {
2971.
2972.
// obter infornnacin do grafcet parcial forzado
forced_grafcet = model.partial_grafcets[fo.fpg]
2973.
2974.
// calcular etapas forzadas no grafcet parcial segundo o tipo de orde
if (fo.type == FORCE_EMPTY)
2975.
2976.
2977.
2978.
forced_steps = QS
else if
(fo.type == FORCE_INITIAL)
// etapas do grafcet parcial contidas na situacin inicial do modelo
forced_steps = model.initial_situation fl forced_grafcet.steps
2979.
elae if (fo.type == FREEZE)
2980.
2981.
2982.
2983.
2984.
// etapas do grafcet parcial coatidas na situacin actual do modelo
forced_steps = current f1 forced_grafcet.steps
else if (fo.type == FORCE_SITUATION)
forced_steps = fo.fsituation
end if
367
2985.
2986.
2987.
2988.
2989.
2990. }

// calcular etapas aon forzadas no grafcet parcial
unforced_steps = forced_grafcet.steps - forced_steps
// modificar as etapas a activar e desactivar
disabled =(disabled - forced_steps) U(unforced_steps fl current)
enabled =(enabled - unforced_steps) U forced_steps
As modificacins realizadas por este mtodo no conxunto de etapas a desactivar consisten

en eliminar del as etapas que pasan a estar forzadas e engadirlle as que estando activas na
situacin actual deixan de estalo ao non pertencer ao conxunto de etapas forzadas. Do mesmo
xeito, no conxunto de etapas a activar engdense as etapas forzadas e elimnanse as que non
pertencen ao conxunto de etapas forzadas.
8.5.1.2. Consulta e sincronizacin das escalas de tempo
Os mtodos haslnternalActions (lia 2854) e useTimeScales (lia 2855) permiten consultar
respectivamente se as accins internas, includas as ordes de forzado, estn habilitadas na
interpretacin do modelo e se o algoritmo de interpretacin utiliza unha ou das escalas de
tempo. O mtodo synchronizeTimeScales (lia 2856) actualiza os datos almacenados na escala
externa facndoos iguais aos da escala interna. Este mtodo invocado dende as polticas de
evolucin ARS cando se chega a unha situacin estbel despois dunha evolucin interna do
modelo. O mtodo getModifiedOutputs (lia 2857) devolve os valores das sadas modificadas
durante a evolucin do modelo. Este mtodo invocado polo xestor de sada para a
actualizacin da base de datos de E/S ao final de cada ciclo de execucin do intrprete (8.4.4).
8.5.1.3. Consulta e actualizacin de eventos
Os mtodos desta categora permiten xestionar os diferentes tipos de eventos externos e
internos que son considerados durante as evolucins do modelo. O mtodo storelnputEvents
(lia 2859) invocado ao comezo de cada ciclo de execucin do intrprete (Figura 8.5) para
almacenar no xogo os eventos detectados no proceso e recibidos a travs do canal de entrada do
subsistema de aplicacin da mquina virtual. O mtodo updateTimerEvents (lia 2860)
invocado para almacenar no xogo os eventos producidos a consecuencia da avaliacin dos
temporizadores do modelo (Figura 8.18). O mtodo updateEvents (lia 2861) invocado antes
de cada evolucin do modelo, xa sexa interna (Figura 8.10) ou externa (Figura 8.8), para
calcular os eventos a considerar, que dependern dos eventos de entrada, de temporizacin, dos
producidos a consecuencia da evolucin anterior do modelo e dos parmetros utilizados na
interpretacin (8.3.2). O mtodo storeNewEvents (lia 2862) invocado despois de cada
evolucin do modelo, xa sexa interna (Figura 8.10) ou externa (Figura 8.8), e antes de executar
as accins para considerar os eventos producidos a consecuencia da evolucin do modelo na
avaliacin das condicins das asociacins activas. Por ltimo, o mtodo areNewEvents (lia
2863) sirve para consultar se se produciron novos eventos a consecuencia da evolucin do
modelo. Este mtodo utilizado nas polticas de evolucin ARS para detectar as situacins
estbeis (Figura 8.10).
8.5.1.4. Consulta e actualizacin de varibeis
Os mtodos desta categora proporcionan acceso ao estado de activacin das etapas
mtodo getStepState (lia 2865^, aos eventos considerados durante a evolucin -mtodos
getModelVarEvent (lia 2866) e getSystemVarEvent (lia 2867^ e aos valores das varibeis
do modelo -mtodos getData (lia 2869) e setData (lia 2873^. Estes mtodos son
invocados pola poltica de execucin (8.6) durante a execucin das funcins que conteen o
368
cdigo C++ das condicins e accins do modelo. Ntese que a escala de tempo utilizada polos
mtodos getStepState, getModelVarEvent e getSystemVarEvent non se pasa como argumento
senn que calculada internamente en funcin dos parmetros de interpretacin do modelo
(8.3.2).
8.5.1.5. Acceso s receptividades, accins e temporizadores activos
'
Os mtodos desta categora son invocados pola poltica de execucin para obter a
informacin sobre as transicins validadas -mtodo getValidatedReceptivities (lia 2877^, e
as asociacins -mtodo getActionAssociations (lia 2879^--, accins -mtodo getActions
(lia 2882}- e temporizadores activos -mtodo getActiveTimers (lia 2883^ para a
avaliacin de receptividades (8.6.1), temporizadores (8.6.2), e a execucin de accins
(8.6.3). A informacin devolta est optimizada para reducir o nmero de operacins a realizar
dacordo tcnica explicada en (8.6.1).
8.5.1.6. Acceso s funcins co cdigo C++ de condicins e accins
Os mtodos desta categora tamn son invocados pola poltica de execucin (8.6) para
acceder s funcins que conteen o cdigo C++ das condicins -mtodo getCondition (lia
2885)- e accins -mtodo getAction (lia 2886}- do modelo.
8.5.2. Informacin para cada escala de tempo

Como se comentou anteriormente, a clase GameTimeScale almacena a informacin que
depende da escala de tempo considerada cando se utiliza un algoritmo de interpretacin ARS.
Os mtodos desta clase permiten consultar e actualizar a informacin da escala de tempo, a
declaracin simplificada da sa interface a seguinte:
2991.class GameTimeScale
2992. {
2993.public:
// consulta e actualizacin de varibeis
2994.
bool getStepState(unsigned long id);
2995.
bool getEvent(const string& id, bool updown);
2996.
2997.
template <class T>
bool getData(const string& id, T& value);
2998.
template <class T>
2999.
bool setData(const string& id, const T& value);
3000.
3001.
// actualizacia da informacin da escala de tempo
void setSituation(const RTSituation& new_situation);
3002.
void calculateValidatedTransitions(const RTStaticModel& model,
3003.
3004.
const RTSituation& fired_transitions = RTSituation());
void updateAssociationInfo();
3005.
3006 . } ;
Os mtodos de consulta e actualizacin de varibeis proporcionan a mesma funcionalidade

que os da clase GrafcetGame, permitindo o acceso na escala de tempo ao estado de activacin
das etapas -mtodo getStepState (lia 2995^, aos eventos considerados durante a evolucin
-mtodo getEvent (lia 2996^ e aos valores das varibeis do modelo -mtodos getData
(lia 2998) e setData (lia 3000}-.
Os demais mtodos permiten actualizar a informacin almacenada pola escala de tempo
cando se establece unha nova situacin do modelo. O mtodo setSituation (lia 3002) almacena
a nova situacin e calcula e almacena os novos eventos xerados pola evolucin. O
pseudocdigo simplificado da sa implementacin o seguinte:
369
3007.void GameTimeScale::setSituation(const RTSituation& new situation)
3008
3009.
3010.
3011.
3012.
3013.
3014.
3015.
/ / calcular etapas activadas e desactivadas
disabled = situation - new_situation
enabled = new_situation - situation
// almacenar eventoa xeradoa pola activacin e desactivacin de etapas
for each step (s) in disabled

_
events.insert(VMEvent(s, false))
end for
3016.
for each step (s) in enabled
3017.
3018.
events.insert(VMEvent(s, true))
end for
3019.
3020.
3021. }
// almaceaar a aova aituacia

situation = new_situation
O mtodo calculateValidatedTransitions (lia 3003) calcula as transicins validadas na nova

situacin da escala de tempo (a establecida polo mtodo anterior) tendo en conta o conxunto de
transicins franquebeis calculado pola poltica de evolucin (8.4.5). Ntese que a situacin
almacenada na escala de tempo a obtida despois de aplicar as ordes de forzado (lias 2915
2920), polo que o conxunto de transicins realmente franqueadas non ten necesariamente que
coincidir coas transicins franquebeis obtidas pola poltica de evolucin como resultado da
evolucin estructural do modelo. Este aspecto considerado na implementacin deste mtodo,
cuxo pseudocdigo simplificado o seguinte:
3022.void
3023. GameTimeScale::calculateValidatedTransitions(const RTStaticModel& model,
3024.
3025. {
const RTSituation& fired_transitions)
3026.
3027.
3028.
3029.
3030.
3031.
3032.
3033.
3034.
// calcular etapas activadas e desactivadas
disabled = situation - new_situation
enabled = new_situation - situation
// calcular transicina que deixan de eatar validadas
// ( as sucesoras das etapas desactivadas)
3035.
3036.
// calcular transicins que poden pasar a estar validadas
// ( as sucesoras das etapas activadas)
3037.
3036.
3039.
3040.
3041.
3042.
3043.
3044.
3045.
3046.
3047.
3048.
3049.
3050.
candidate = 0
for each step (s) in enabled
candidate = candidate U s.after
end for
// comprobar que traasicina eatn realmente validadas
/ / (unha tranaicin est validada cando todas as etapas
// que a precedea eatn activas na situacin actual)
invalidated = Q)
for each step (s) in disabled
invalidated = invalidated U s.after
end for
new_validated = QJ
for each transition (t) in candidate
steps_before = t.before
if ((steps_before n situation) _= steps_before)
new_validated.insert(t)
end if
end for
3053.
3054.
// engadir s transicina validadas as transicina fraaquebeia que noa
// soa finalmente franqueadas debido aplicacia das ordes de forzado
new_validated = new_validated U(fired_transitions - invalidated)
// calcular e almacenar as transicins validadas na situacin actual
3055.
validated_trans =(validated_trans - invalidated) U new_validated
3051.
3052.
3056. }
370
Por ltimo o mtodo updateAssociationlnfo (lia 3005) actualiza o estado de activacin das
asociacins do modelo tendo en conta a nova situacin establecida na escala de tempo.
8.6. A poltica de execucin

A poltica de execucin a responsbel de xestionar a execucin do cdigo do modelo
Grafcet: avaliacin de condicins, execucin de accins e control'de temporizacins; as como
de proporcionar o acceso aos valores das varibeis do modelo e do proceso dende as funcins
C++ xeradas polo compilador (6.5.1.9). A clase RunningPolicy (Figura 8.3) implementa polo
tanto das interfaces diferentes, a utilizada polo algoritmo de interpretacin e a utilizada no
cdigo C++ de accins e condicins, que definida pola clase abstracta IVMachineAccess
(6.3.2). O cdigo seguinte mostra unha versin simplificada da sa declaracin:
3057.class RunningPolicy : public IModule, public IVMachineAccess
3058. {
3059.
3060.
3061.
// mtodoa utilizados polo algoritmo de interpretacibn
virtual void run(GrafcetGame* game,
IVMServices* vmachine,
3062.
3063.
3064.
3065.
TimeScale time_scale = TSEXTERNAL) = 0;
virtual void evaluate(GrafcetGame* game,
RTSituation& fired_transitions,
3066.
3067.
TimeScale time_scale = TSEXTERNAL) = 0;
virtual void calculate_timers(GrafcetGame* game,
3068.
3069.
3070.
3071.
3072.
3073.
3074.
3075.
3076.
IVMServices* vmachine) = 0;
// mtodos utilizados no cdigo das funcina xeradas polo compilador Grafcet
bool getModelVarEvent(const string& id, bool updown);
bool getSystemVarEvent(const string& id, bool updown);
bool getStepState(unsigned long id);
bool getTimerState(const string& id);
template <class T>
bool getModelVar(const string& id, T& value);
template <class T>
3077.
3078.
bool setModelVar(const string& id, const T& value);
template <class T>
3079.
3080.
bool getSystemVar(const string& id, T& value);
template <class T>
3081.
3082.
bool setSystemVar(const string& id, const T& value);
// mtodoa para a xestin das temporizacins
3083.
3084.
3085.
3086.
3087.
3088 . } ;
bool setTimerState(const string& id, bool state);
unsigned setTimer(long time, pfn callback, IAsyncClbkArg* parg = NULL);
// mtodos de acceso ao cdigo de condicins e accins no xogo Grafcet
pfnCond getCondition(const string& name) const;
pfnCode getAction(const string& name) const;
A clase RunningPolicy proporciona a implementacin por defecto dos mtodos declarados

na interface IVMachineAccess que acceden aos valores das varibeis do proceso almacenadas
na base de datos de E/S -mtodos getSystemYar (lia 3079) e setSystemVar (lia 3081}-, aos
valores das varibeis declaradas no modelo -mtodos getModelVar (lia 3075) e setModelVar
(lia 3077}-, aos eventos externos e internos -mtodos getModelVarEvent (lia 3070) e
getSystemVarEvent (lia 3071}- e ao estado de temporizadores e etapas do modelo -mtodos
getTimerState (lia 3073) e getStepState (lia 3072}-. Tamn declara os mtodos utilizados
para o clculo dos temporizadores -mtodo calculate_timers (lia 3067}-, a avaliacin das
receptividades -mtodo evaluate (lia 3063}- e a execucin das accins -mtodo run (lia
3060^, que son implementados na clase derivada DefaultRunningPolicy (Figura 8.3).
Ademais incle algns mtodos . auxiliares para facilitar a xestin das temporizacins (lias
Seccin 8.6: A poltica de execucin
371
3083 e 3084) e o acceso ao cdigo das condicins e accins do modelo Grafcet que se estea
executando (lias 3086 e 3087).
No resto deste apartado explcanse de forma simplificada os detalles da implementacin

destes mtodos e as tcnicas empregadas para reducir as operacins a realizar en cada ciclo de
^
evolucin do modelo.
8.6.1. Avaliacin e franqueamento de transicins
Para cada transicin do modelo Grafcet, o xogo Grafcet almacena unha instancia da clase
ReceptivitySchedulelnfo -estas instancias son manexadas na implementacin da clase
Receptivitylnfo ( Figura 8.12}-. O cdigo da declaracin simplificada desta clase o seguinte:
3089.class ReceptivityScheduleInfo
3090. {
3091.private:
RTReceptivityInfo* rec;
3092.
3093.public:
bool evaluate(RunningPolicy* env) const;
3094.
3095. } ;
Cada instancia desta clase mantn un apuntador informacin da transicin xerada polo
compilador ( 6.4) e proporciona un mtodo para avaliala. A implementacin deste mtodo a
seguinte:
3096.boo1 ReceptivityScheduleInfo::evaluate(RunningPolicy* env) const
3097. {
if (rec->receptivity.empty())
3098.
return true;
3099.
ead if
3100.
3101.
3102. }
return (env->getCondition(rec->receptivity))(*env);
O mtodo devolve true se a transicin non ten receptividade asociada. En caso contrario
devolve o resultado de executar a funcin do modelo que contn o cdigo da receptividade
accedida mediante o mtodo getCondition (lia 3086) da poltica de execucin-, pasndolle
como parmetro a poltica de execucin, que a que proporciona o acceso aos valores de
eventos, temporizadores e varibeis.
O seguinte pseudocdigo mostra unha versin simplificada da implementacin do mtodo
que calcula, para unha situacin dada, as receptividades franquebeis e as devolve no
argumento fired_transitions. Ntese que utilizado o mesmo mtodo tanto nas evolucins
internas como nas externas do modelo, os aspectos especficos de cada escala son mantidos no
xogo Grafcet.
3103.void DefaultRunningPolicy::evaluate(GrafcetGame* game,
3104.
RTSituation& fired_transitions,
TimeScale time_scale)
3105.
3106.
3107. {
3108.
3109.
3110.
validated_receptivities = game->getValidatedReceptivities(time_scale)
for each receptivity (r) ia validated_receptivities
if r.evaluate(this)
3111.
3112.
3113.
3114 . }
fired_transitions.insert(r)
end if
end for
Para reducir o nmero de receptividades a avaliar, o xogo Grafcet mantn a informacin

actualizada das transicins validadas e das varibeis booleanas utilizadas en cada receptividade
372
(esta informacin obtida polo compilador Grafcet). Utilizando esta informacin, para unha
situacin do modelo dada, unicamente se avalan as receptividades das transicins que pasaron
a estar validadas como resultado da ltima evolucin do modelo e, das que xa estaban
validadas, unicamente as que contean varibeis booleanas para as que haxa algn evento de
entrada significativo ( 8.3.1.2). Como exemplo considrese o grafcet da Figura 8.13, no que as
varibeis a e b son booleanas e c real.
'
1
5
(1)^c<5.0
a.b (6)
(5)
2
(2)
3
b
(3)
4
yb (4)
6
!a.(c<3.5)
($)
!a
a.!b (7)
7
b (9)
8
ya (10)
c>7.0
A informacin sobre as receptividades obtida polo compilador e almacenada no xogo

Grafcet para este modelo sera a seguinte:
3115.
3116.
3117.
3118.
3119.
// transicins do modelo
T = { (1) , (2) , (3) , (4) , (5) , (6) , (7) , (8) , (9) , (10) }
// transicins con receptividades que s conteen varibeis booleaaas
// ( iadexadas polo nome da varibel)
Tb = { {"a", (5), (6), (7), (9)},
3120.
3121.
3122.
{"b", (2), (3), (5), (6), (8)} }
transicins con receptividades que conteen varibeis non booleanas
Tr = {(1), (4), (10)}
//
Supase que os valores das varibeis son: a=1, b=0 e c=12.5, e que o modelo est no medio
dunha evolucin na que ven de activarse a etapa 5. A informacin almacenada no xogo sobre o
estado da evolucin ser a seguinte:
3123.
3124.
3125.
3126.
3127.
3128.
// situacin actual
S = {1, 5}
// transicibns validadas
T;, _ { (1) , (5) , (6) , (7) }
// novas transicins validadas a consecuencia da evolucia anterior
T,,,, _ { (5) , (6) , (7) }
Se se utiliza unha poltica de evolucin ARS, na que os eventos producidos pola evolucin
do modelo son considerados na seguinte evolucin interna e teen prioridade sobre os eventos
externos, a avaliacin e franqueamento das transicins do modelo producir os seguintes
resultados:
3129.
// CICLO 1
3130.
3131.
a=1, b=0, c=12.5
// eventos
3132.
3133.
E _ {TXS}
// tranaicins a avaliar
3134.
Ta = Tvn(-^) U (Tvc-^) n (Tr U TbL"XS"^ ) ) _ { (1) . (5) . (6) ^ (7) }
// transicins franquebeis
Tp = {.0^}
3135.
3136.
3137.
// nova situacin
3138.
S = {1, 5}
( non hai evolucin)
3139.
3140.
3141.
314 2 .
// transicias validadas
T _ { (1) , (5) , (6) , (7) }
// transicins que pasaa a estar validadas a consecueacia da evolucin
T,,,, _ { .0' }
373
Do conxunto de transicins que xa estaban validadas antes da ltima evolucin, non se

avaliarn aquelas con receptividades que contean unicamente varibeis booleanas para as que
non haxa ningn evento. A razn que o resultado da avaliacin destas transicins non pode
variar ata que cambie o valor dalgunha das varibeis booleanas da sa receptividade, e os
cambios nestes valores son recibidos polo intrprete en forma de eventos. No caso concreto do
ciclo 1, o conxunto de transicins a avaliar coincide co de transicins validadas. Como
resultado da avaliacin ningunha transicin pode ser franqueada, polo que o modelo queda na
mesma situacin na que estaba ao comezo o ciclo.
Supase agora que antes do seguinte ciclo de execucin do intrprete o valor da varibel c
cambia a 4.5, nese caso o resultado da avaliacin e franqueamento das transicins sera o
seguinte:
// CICLO 2
3143.
3144.
3145.
a=1, b=0, c=4.5
// eventoa
3146.
E _ {.^}
3147.
/ / transicias a avaliar
3148.
3149.
Ta = T71^_1) U (T^^_1) (1 Tr) _ { (1) }
// tranaicina franquebeis
3150.
3151.
Tf = {(1)}
// nova situacin
3152.
3153.
S={2, 3, 4, 5}
// tranaicins validadas
3154.
T _ { (2) , (3) , (4) , (5) , (6) , (7) }
3155.
3156.
// traasicina que pasan a estar validadas a conaecuencia da evolucin
T^, _ { (2) , (3) , (4) }
Neste ciclo non hai eventos, pois c non unha varibel booleana, e das transicins validadas
unicamente preciso avaliar a que contn varibeis non booleanas na sa receptividade, pois o
resultado da avaliacin das outras vai seguir sendo igual ao da ltima vez que se avaliaron,
dicir false. Como resultado da avaliacin franquease a transicin 1 e actvanse as etapas 2, 3 e
4. A evolucin continuara do xeito seguinte:
3157.
3158.
3159.
// CICLO 3
a=1, b=0, c=4.5
// eventos
3160.
3161.
3162.
E_{.^Xl, TXZ, TX3, TXQ}
// tranaicina a avaliar
3163.
Ta = Tvnl-^)U (Tvc-^)n (TrUTpI"Xl"^ UTyI^^X^"l UTyI^^X3"! UTbI"Xq"! ) ) _ { (2) , (3) , (4) }

// tranaicina franquebeis
3164.
3165.
3166.
TE _ {,^}
/ / nova situacin
S={2, 3, 4, 5}
( aon hai evolucia)
tranaicina validadas
3167.
//
3168.
3169.
317 0 .
T _ { (2) , (3) , (4) , (5) , (6) , (7) }

// tranaicina que pasan a estar validadas a conaecueacia da evolucin
T,,,, _ { .^ }
Neste terceiro ciclo avalanse unicamente as transicins que veen de ser validadas pola
evolucin anterior, xa que as demais conteen nas sas receptividades unicamente varibeis
booleanas non afectadas polos eventos de entrada. Por ltimo, supase que antes do seguinte
ciclo cambia o valor da varibel a. Como esta varibel booleana o intrprete recibir un
evento a travs do canal de entrada do subsistema de aplicacin e a evolucin do modelo sera a
seguinte:

3171.
// CICLO 4
3172.
3173.
a=0, b=0, c=4.5
// eventos
3174.
E _ {.â}
374
3175.
// transicins a avaliar
3176.
3177.
Ta = T^,T,t_1^ U (T^_1^ fl (Tr U Tb["a"l ) ) _ { (4) , (5) , (6) , (7) }

// transicins fraaquebeis
3178.
3179.
3180.
Tf = {(7)}
// nova situacin
S={2, 3, 4, 8}
3181.
//
3182.
T _ {(2), (3), (4), (10)}
3183.
318 4 .
// transicias que pasan a estar validadas a consecuencia da evolucin
Ti, _ { (10 ) }
transicins validadas
Neste caso, das transicins validadas sern avaliadas as de receptividades que contean
unicamente varibeis booleanas afectadas polo cambio de a, mis as que conteen varibeis
non booleanas.
Existen das consideracins adicionais que preciso ter en conta na tcnica descrita
anteriormente para a reduccin do nmero de transicins a avaliar en cada ciclo, de xeito que
poda ser aplicada en todas as situacins:
1. As transicins fonte (3.2.2.1) do modelo. Este tipo de transicins estn sempre validadas,
polo que na iniciacin do xogo Grafcet teen que inserirse no conxunto de transicins
validadas (T,,) no que permanecern ata que finalice a interpretacin do modelo. Polo
demais manexaranse do mesmo xeito que calquera outra transicin, inserndose no
conxunto Tb (lia 3119) se a sa receptividade contn unicamente varibeis booleanas ou
no conxunto T^ (lia 3122) se contn algunha varibel non booleana.
2. As transicins validadas como consecuencia das ordes de forzado que deixan de estar
activas. Considrese o modelo mostrado na Figura 8.14, no que a transicin 10 est
validada mais non poder ser franqueada, independentemente do valor da varibel b,
mentres a etapa 10 siga estando forzada pola orde de forzado da etapa 1. Cando se recibe o
evento Ta, a situacin evoluciona a{2, 10} e valdase a transicin 2. Ademais, como a
etapa 10 deixa de estar forzada, debe considerarse a transicin 10 como se tamn acabara
de validarse para que sexa avaliada e franqueada se o caso. Ntese que unicamente
preciso considerar este caso cando se utilice unha poltica de evolucin ARS coas ordes
internas habilitadas. Para manexalo, o xogo Grafcet mantn informacin sobre as etapas
que estn forzadas en cada situacin e calcula, para cada evolucin na que hai cambios nas
etapas forzadas, o conxunto de transicins que suceden s etapas que deixan de estar
forzadas. As transicins dese conxunto que estean validadas sern engadidas ao conxunto
de transicins a avaliar en cada ciclo (Ta).
--------------------------------------------
-^ .....................^--........
1
10
F/G2:{10}
(1 )^ a
(10
(2)^ya
b
11
G1 i ` (11)
:
yb G2.:
375
8.6.2. Xestin de temporizacins

Como se explica en (3.3.3.7), a definicin orixinal do Grafcet [1] incle un operador para
especificar temporizacins nas condicins de transicin e nas condicins das asociacins, o que
permite modelar accins retardadas e limitadas no tempo. Este operador ten a semntica do
elemento de retardo definido no estndar [83] e considerado, dende o punto de vista da
definicin do Grafcet, como unha funcin operativa asociada ao modelo e non como un
elemento constitutivo do mesmo [30]. En (6.3) comntanse os aspectos a considerar cando se
modifica o operador anterior para permitir a utilizacin de expresins C++ na sa condicin.
Neste apartado detllanse os aspectos relacionados coa implementacin da semntica do
operador de temporizacin e co manexo das temporizacins durante a evolucin do modelo.
As temporizacins implementadas no intrprete Grafcet teen das posbeis semnticas,
como mostra a Figura 8.15. A semntica utilizada durante a interpretacin indcase como
parmetro do mtodo playModel (lia 2807) cando esta iniciada. A diferencia entre ambas
semnticas est no comportamento do valor do temporizador cando est activado e a sa
condicin deixa de ser certa. Nesas circunstancias, se a condicin de activacin do
temporizador volve a ser certa antes de que transcorra o tempo de desactivacin t2, poden darse
das posibilidades:
^
1. Que o temporizador se desactive cando transcorra o tempo tZ. Esta semntica correspndese
coa dun temporizador non redisparbel.
2. Que o temporizador non se desactive cando transcorra o tempo t2. Esta semntica
correspndese coa dun temporizador redisparbel.
T=t^\cond\t2
i
cond
cond
^ t^ ;
i I
If
^^^
i
i t^ ^
4f--^^H i^-f
i
;t2
t2
-^
----------------^-----
'
(a)
--
---------------^------^---^----------^
^
!
(b)
Figura 8.15. Semntica dos temporizadores: a) non redisparbel; e b) redisparbel.
O seguinte pseudocdigo mostra unha versin simplificada da implementacin do mtodo

que realiza os clculos precisos para a xestin dos temporizadores. Este mtodo executado
polo algoritmo de interpretacin (Figura 8.8) ao inicio de cada ciclo do intrprete, na escala de
tempo externa. En consecuencia os cambios de estado dos temporizadores son recibidos polo
intrprete xunto cos eventos do proceso.
3185.void DefaultRunningPolicy::calculate_timers(GrafcetGame* game,
3186.
3187 . {
IVMServices* vmachine)
3188.
/ / avaliar temporizadores activos
3189.
3190.
3191.
active_timers = game->getACtiveTimers();
for each timer (t) in active_timers
t.evaluate(this);
3192.
end foz
3193.
3194.
game->updateTimerEvents();
// almacenar novos eventos

3195.
3196.
3197.
3198 . }
376
// activar/desactivar temporizadores da mquina virtual
vmachine->doSchedules();
vmachine->doUnschedules();
Para reducir o nmero de condicins de temporizacin que preciso avaliar -obtidas

mediante o mtodo getActiveTimers do xogo Grafcet (lia 2883}- utilizouse a mesma tcnica
que se explicou no apartado anterior para as receptividades, de xeito que en cada ciclo son
avaliadas as condicins de temporizacin que contean varibeis non booleanas e as que
contean unicamente varibeis booleanas afectadas por algn dos eventos considerados.
Para o manexo das condicins de temporizacin do modelo Grafcet a interpretar, o xogo
Grafcet almacena unha instancia da clase TimerSchedulelnfo para cada temporizador -estas
instancias son manexadas na implementacin da clase Timerlnfo (Figura 8.12^. O cdigo da
declaracin simplificada desta clase o seguinte:
3199.class TimerScheduleInfo
3200. {
3201.private:
3202. string timer_name; // nome do temporizador no modelo
3203. bool retrigger;

// L redisparbel?
3204. RTTimerInfo* info; // informacin proporcionada polo compilador
3205. bool last_eval;

// resultado da ltima avaliacin
3206.private:
3207.
// mtodos auxiliarea
3208.
bool evaluateCondition(RunningPolicy* env);
3209.
void setTimerVar(bool value, RunningPolicy* env);
3210.
void startTl(RunningPolicy* env);
3211.
void stopTl(RunningPolicy* env);
3212.
void startT2(RunningPolicy* env);
3213.
void stopT2(RunningPOlicy* env);
3214.public:
3215.
// manexo da temporizacin
3216. void evaluate(RunningPolicy* env);
3217 . } ;
Como pode verse, esta clase declara os atributos e mtodos auxiliares necesarios para
implementar no mtodo evaluate (lia 3216) o control da temporizacin, que se corresponde
co diagrama de estados da Figura 8.16. Ntese que os estados WAIT e T1T2_COLTNT son
utilizados unicamente nos temporizadores con semntica redisparbel. O significado dos
eventos e accins utilizados nas transicins do diagrama son os seguintes:
up(cond) e down(cond), indican que a condicin do temporizador pasa a ser certa ou falsa,
respectivamente. Estes eventos son detectados internamente no mtodo evaluate da clase
TimerSchedulelnfo. Esta clase almacena no atributo last_eval (lia 3205) o valor do
resultado da ltima avaliacin da condicin e o compara co resultado actual, devolto polo
mtodo privado evaluateCondition (lia 3208). Este mtodo executa a funcin do modelo
que contn o cdigo C++ da condicin; a sa implementacin semellante do mtodo
evaluate (lias 3096-3102) explicado anteriormente para as receptividades.
up(t^) e up(t2), representan notifcacins asncronas (7.1.2.4.2) recibidas dende o ncleo

da mquina viriual cando transcorren os tempos t^ e tZ respectivamente. Ao recibir unha
destas notificacins o temporizador almacenado na lista de temporizadores activos -os
devoltos polo mtodo getActiveTimers (lia 2883^ do xogo Grafcet, para ser avaliado no
seguinte ciclo de execucin do intrprete. A medicin dos tempos tl e t2 realzase utilizando
os servicios de temporizacin da mquina virtual (7.3.2), a travs dos mtodos privados
startTl (lia 3210), stopTl (lia 3211), startT2 (lia 3212) e stopT2 (lia 3213).
377
A activacin e desactivacin da varibel que almacena o valor do temporizador no modelo

indicado no diagrama mediante as accins enable e disable, respectivamente. Ambas
accins son realizadas utilizando o mtodo privado setTimerYar (lia 3209).
^
0
U
^
.N
G1
1--^
G
f0
f..l
O
n
11
j
^
Qf
.C
O
41
QI
.
r
0
^
d
^
L
6f
^
f0
aî
^
^
L
a^
rn
rn
^
^
cv
a^
6.1
f0
^
v
r
U
^
61
T
Figura 8.16. Diagrama de estados dun temporizador Grafcet.
378
A Figura 8.18 mostra un exemplo da secuencia de mensaxes intercambiadas na colaboracin

entre a poltica de execucin, o xogo Grafcet, os servicios de temporizacin do ncleo da
mquina virtual e a instancia da clase TimerSchedulelnfo que xestiona o estado do
temporizador. Ntese que debido natureza cclica do intrprete e a que, como se indicou
anteriormente, os temporizadores son avaliados ao inicio de cada ciclo, existen unhas latencias
asociadas planificacin dos temporizadores na mquina virlual e ao tempo de ciclo` do
intrprete. Estas latencias son varibeis e producen unha perda de precisin nas temporizacins,
o que pode non ser aceptbel en procesos con requisitos temporais moi estrictos.
A existencia destas latencias obriga a modificar o diagrama de estados da Figura 8.16 para
considerar a posibilidade de que se produza algn evento durante a latencia de resposta. Na
Figura 8.17 mostrase un exemplo da diferencia entre un caso ideal e un caso con latencia. No
caso ideal, a notificacin do cumprimento do tempo t^ procesada instantaneamente e, polo
tanto, o valor da condicin ser true. Sen embargo no caso con latencia, dende que se recibe a
notificacin ata que se procesa, transcorre un tempo no que o valor da condicin pode deixar de
ser certo.
O diagrama de estados no que se teen en conta as latencias mstrase na Figura 8.19. Cada
estado no que hai un temporizador activo estar agora formado por varios subestados que
representan as diferentes posibilidades que introducen os tempos de latencia. Por exemplo no
caso da Figura 8.17 o temporizador est no estado T1_COUNT:TICOLTNTING, cando se
recibe a notificacin de ter transcorrido o tempo t^ -evento up(t^)- o temporizador pasa ao
estado T1 COLJNT:T1_EXPIRED, no que se mantn ata ser avaliado no seguinte ciclo do
intrprete^ No momento da avaliacin comprbase o resultado actual da condicin, se este
segue sendo certo, o temporizador pasa ao estado ENABLED igual que no comportamento
ideal, en caso contrario pasa ao estado START ou T2_COLJNT:T2COLTNTING dependendo do
valor de t2. Ntese que ao avaliar o temporizador no ciclo seguinte ao de recibir a notificacin,
non existe a posibilidade de que se produza mis dun cambio no valor da sa condicin xa que
s se obteen novos valores para as varibeis usadas na condicin ao comezo de cada ciclo.
T=t^\cond\t2
cond
cond
^_t1 '
'^
^
^
^
^
T1 COUNT ! ENABLED
(a)
' t1 ^ ^L^
^
;^^N i2
^^^^
^
,
^^
^
^^^
^^
^'^ s
^
^^
T1 COUNT i T2 COUNT
(b)
Figura 8.17. Efecto da latencia de resposta no control dun temporizador: a) comportamento ideal; e b)
comportamento con latencia.
79 Para reducir a informacin das transicins do diagrama, omitiuse o nome do evento naquelas que son avaliadas
ao executarse o mtodo evaluate do temporizador, e unicamente se indica nelas a condicin de transicin.
379

oame:GrafcetGame
tun oolicv:DefaultRunninaPoliw
vm:IVMServicea
ti merTi merSchedulel rtto
calculate_timers(game, vm) i
active_timera = getActiveTimerep ;
START
[' for any timer In active timera]
evaluate(titis)
up(rqnd) &8 t1>0]

âtanrto
aetTimer(tt, this)
schedule(tt, timer
latencia de panificacin
T1_COUN
updateTimerEvenffiQ i
doSchedulesQ^-^;
doUnschedutes()^5
calculate_timers(game, vm) i
tt
calculate timers(game, vm) i
^ Emers.activate(this)
i^
calculate Omers(game, vm)
;
q --------------
notification
-
active_tlmers = getActiveTimers(L;
latencia de resposta
rj [' tor any timer In acuve timere]
evaluate(this)
setTimerVar(true, runôtiq)
setTimerState(timer name, true)
aetData(timer_name, truel ;
ENABLED
updateTimerEvents() j
doSchedulesp i
-^
doUnschedules( ;
plalate_timers(game, vm) ;
calalate_timers(game, vm) ;
calculate timers(game, vm)

active timera = getActiveTimers() ;
[ tor any timer In actve_time^)
,
evaluate(this)
i
down(cond)&8t2>g)
startT2p
aetTimer(t2, this)
schedule(t2, timer) ;
^
T2_COU
updateTimerEventa() ;
latenda de qanificacin
doSchedulesp j
doUnschedules() ;
calculate 6mers(game, vm) ^

t2
^
calaAate timers(game, vm) ;
calwlate_Umers(game, vm)
^ timers.auivate(this)
i
active fimers = getActiveTimers() ;
.'
notification ;
^----- --------- -- ------- . _. ---^t
II
^
z
latena de resposta
( far any timer in active timers)

.
evalvate(ttris). :
setTunerVar(false,runydicy)
setTimerState(Cmer_name, fafse)
setData(timer name, false) :
START
updateTunerEvenTS() i
{condâlse)
doSchedrCes() i
-^
doUnschedNesp ;
Figura 8.18. Secuencia de mensaxes para a xestin das temporizacins Grafcet.
380
r
^
^
^
m
a
v
N
N
(:
^
O
U
^
O
U
W
^_
a
X
W
~
m I
m
c
m
C
O
U
d
z
Figura 8.19. Diagrama de estados dun temporizador Grafcet con latencias de resposta.
381
8.6.3. Execucin de accins

En (5.1.2.3) descrbese a representacin de accins e asociacins no metamodelo proposto
para o Grafcet. O tipo de asociacins que poden representarse utilizando ese metamodelo
mis amplo que o definido polo estndar IEC 61131-3 [86]. Os tipos bsicos de asociacins
definidos son: N, R, S, P, PO e P1; a sa semntica temporal a descrita en (3.3.3). Calquera
destes tipos bsicos pode ter asociada unha condicin (C), unha demora (D) e un lmite
temporal (L). Ademais as accins R, S, P, PO e P1 poden ser internas ou externas, sendo
executadas respectivamente nas evolucins internas do modelo ou unicamente nas externas.
Como se explica en (3.6.1.3), o estndar IEC 61131-3 define un bloque de control de
accins que describe a semntica utilizada para a execucin das accins nos SFCs. O
equivalente a este bloque implementado no intrprete Grafcet mediante a clase
ActionSchedulelnfo. Durante a interpretacin do modelo almacnase unha instancia desta clase
para cada accin no xogo Grafcet -estas instancias son manexadas na implementacin da
clase Actionlnfo (Figura 8.12}-. O cdigo simplificado da sa declaracin o seguinte:
3218.// Tipos bsicos de asociacina
3219.enum ActionType {N, R, S, P, P1, PO};
3220.
3221.class ActionScheduleInfo
3222. {
3223.private:
3224. string action_name;

3225. bool state;
3226. RTActionType code_type;
3227. bool flags[6];
3228. unsigned count[3];
3229. bool stored;
//
//
//
//
//
//
nome da accia no modelo
estado da accin
tipo de accin ( 5.1.2.1)

1"flag" por cada tipo bsico de asociacin
nmero de asociacina N, R e S activas
L valor da accin almacenado?
3230.private:
void runAction(RunningPolicy* env);
3231.
void setActionValue(bool value, RunningPolicy* env);
3232.
3233.public:
void set(ActionType type);
3234.
void reset(ActionType type);
3235.
void run(RunningPolicy* env);
3236.
3237 . } ;
Ademais da informacin sobre o nome da accin no modelo, o tipo de accin e o seu estado
de activacin, cada instancia da clase ActionSchedulelnfo almacena nos atributos count (lia
3228) e flags (lia 3227) o nmero e tipo das asociacins activas que afecten ao valor do seu
estado nunha situacin do modelo. Os mtodos set (lia 3234) e reset (lia 3235) permiten
modificar esta informacin. O valor da varibel do modelo que almacena o estado de activacin
da accin modificado mediante o mtodo privado setActionValue (lia 3232), e o mtodo
runAction (lia 3231), cunha implementacin semellante do mtodo evaluate (lias 3096
3102) explicado anteriormente para as receptividades, executa a funcin do modelo que contn
o cdigo C++ da accin. O control da execucin da accin realizado no mtodo run (lia
3236), que ten a seguinte implementacin:
3238.void ActionSchedulelnfo::run(RunningPolicy* env)
3239. {
3240.
3241.
3242.
3243.
3244.
3245.
3246.
3247.
// calcular eatado da accin
if (flags[R])
state = stored = false;
else if (flags [N] ^ ^ flags [PJ ^ ^ flags [P1] ^ ^ flags [PO] ^ ^ flags [S]
state = true;
if (flags [S] )
stored = true;
ead if

3248. else if (!stored)
3249.
state = false;
3250. end if
3251. // activar/desactivar valor da accia no modelo
3252. setActionValue(state, env);
3253. // executar accin
3254. if (state)
3255.
runAction(env);
3256. end if
3257. // desactivar "flags" accins impulsionais
3258 . if (flags [P] ^ ^ flags [Pi] ^ ^ flags [PO] )
flags [P] = flags [P1] = flags [PO] = false;
3259.
3260. end if
3261 . }
382
"
O clculo do estado de activacin da accin faise nas lias 3241-3250 considerando os tipos
das asociacins activas. As asociacins tipo R teen prioridade sobre as demais, polo que
sempre que haxa unha asociacin tipo R activa o valor da accin ser desactivado (lia 3242)
independentemente da existencia doutras asociacins activas. En caso de non haber ningunha
asociacin tipo R activa e haber algunha doutro tipo, o valor da accin activado (lia 3244).
Se ademais a asociacin de tipo S actvase o valor do atributo stored (lia 3246), para indicar
que o valor que ten a accin almacenado. No caso de non haber ningunha asociacin activa, o
valor da accin desactvase se non un valor almacenado (lia 3249). Ntese que se o valor de
activacin da accin almacenado, unicamente pode ser desactivado por unha asociacin tipo
R. En caso de non ser almacenado desactvase simplemente coa ausencia dunha asociacin
activa. Unha vez calculado o estado de activacin da accin actualzase o seu valor no modelo
(lia 3252) e exectase o cdigo da accin en caso de estar esta activa (lia 3255). Por ltimo
desactvanse os indicadores correspondentes s asociacins impulsionais activas, de xeito que
afecten execucin da accin unicamente unha vez.
O mtodo da poltica de execucin que executa as accins do modelo realiza, para unha
situacin dada, das operacins diferentes: primeiro avala as asociacins activas e despois
calcula o estado de activacin das accins e executa as activas. A versin simplificada do seu
pseudocdigo a seguinte:
3262.void DefaultRunningPolicy::run(GrafcetGame* game,
3263.
TimeScale time_scale)
3264.
3265. {
3266.
3267.
3268.
3269.
// avaliacin das asociacins activas e das que deixan de estalo
active_associations,
disabled_associations = game->getActionAssociations(time_scale)
for each association (a) in active_associations
3270.
3271.
3272.
a.evaluate(this)
end for
for each association (d) in disabled_associations
3273.
3274.
3275.
a.onDeactivate(this)
end for
// execucin de accins activas
3276.
3277.
actions = game->getActions()
for each action (act) in actions
act.run(this)
3278.
3279.
3280.
3281.
3282. }
end for
// aincronizacin da "cach"
flushCache()
Ntese que o mesmo mtodo utilizado tanto nas evolucins internas como nas externas do
modelo, os aspectos especficos de cada escala son mantidos no xogo Grafcet. O nmero de
383
asociacins a avaliar en cada ciclo redcese utilizando coas asociacins condicionais a mesma
tcnica que coas receptividades e temporizadores, de xeito que as que contean unicamente
varibeis booleanas non afectadas por algn dos eventos considerados non son avaliadas. Unha
vez executadas as accins actualzanse os datos do modelo e, se preciso, os valores das sadas
do proceso mediante o mtodo privado flushCache (lia 3281), que explicado en (8.6.4).
Para a avaliacin e manexo das asociacins, o xogo Grafcet almacena unha instancia da
clase AssociationSchedulelnfo para cada asociacin do modelo a interpretar -estas instancias
son manexadas na implementacin da clase Associationlnfo (Figura 8.12^-. O cdigo da
declaracin simplificada desta clase o seguinte:
3283.class AssociationScheduleInfo
3284. {
3285.private:
3286. bool last_eval;

/ / resultado da ltima avaliacin
3287. ActionScheduleInfo* action;

// accin modificada pola asociacin
3288.
RTActionInfo* info;
/ / informaci^n proporcionada polo campilador
3289.private:
3290. bool evaluateCondition(RunningPolic,y* env);
3291.public:
void evaluate(RunningPOlicy* env);
3292.
void onDeactivate(RunningPolicy* env);
3293.
3294 . } ;
Cada instancia da clase almacena o resultado da ltima avaliacin da condicin da

asociacin, un apuntador instancia da clase ActionSchedulelnfo que contn a informacin da
accin cuxo estado de activacin modificado pola asociacin, e un apuntador informacin
da asociacin xerada polo compilador (6.4). En canto aos mtodos da clase, o mtodo privado
evaluateCondition (lia 3290), cunha implementacin semellante do mtodo evaluate (lias
3096-3102) explicado anteriormente para as receptividades, executa a funcin do modelo que
contn o cdigo C++ da condicin da asociacin; e os mtodos evaluate (lia 3292) e
onDeactivate (lia 3293) implementan o control da asociacin.
A Figura 8.20 mostra a representacin dunha asociacin xenrica e as relacins temporais
existentes entre o tempo de activacin da etapa que est asociada e o tempo de activacin da
propia asociacin tendo en conta os posbeis tempos de demora (Tp) e lmite (TL) especificados
no modelo. Se non se especifican tempos de demora e lmite o tempo de activacin da
asociacin coincide co da etapa. Ntese que os tempos de demora e lmite aparecen
especificados na condicin tal e como seran representados polo compilador Grafcet (6.5.1.2).
I
To && cond &8^ !T^
tipo accin
Xi
Xi
. T^
^
Asoc
Asoc
.
Asoc
(a)
Fgura 8.20. Relacin temporal entre o tempo de activacin dunha etapa e o dunha asociacin asociada a ela: a)
Tp < TI, < T(Xi); b) TD _< T(Xi) 5 TL; e c) T(Xi) < Tp < TL.
384
O mtodo evaluate (lia 3292) executado en cada ciclo do intrprete mentres a asociacin
estea activa, e o mtodo onDeactivate (lia 3293) no ciclo no que deixa de estalo. A
implementacin destes mtodos activa e desactiva -en funcin do valor da condicin
calculado co mtodo privado evaluateCondition (lia 3290}- o"flag" correspondente ao tipo
da asociacin na instancia da clase ActionSchedulelnfo referenciada polo atributo action (lia
3287). A semntica temporal do "flag" de cada tiô de asociacin mostrada na Figura 8.2 Y en
funcin dos cambios na condicin da asociacin8 . A activacin e desactivacin do "flag" faise,
respectivamente, mediante os mtodos set (lia 3234) e reset (lia 3235) da clase
ActionSchedulelnfo, aos que se lles pasa como parmetro o tipo da asociacin.
Ntese que a semntica de activacin dos "flags" dos tipos N, R e S coincidente. A
diferencia entre elas estar polo tanto na forma en que son manexadas as activacins dos seus
"flags" no mtodo run da clase ActionSchedulelnfo (lias 3241-3250). No que respecta s
asociacins impulsionais, o"flag" das tipo P 1 activado a primeira vez que a condicin certa,
xa sexa no instante de activarse a asociacin (Figura 8.21) ou unha vez activada (Figura 8.22).
O das tipo P activado cada vez que a condicin se volve certa (Figura 8.22), includo o caso
no que xa sexa certa no instante de activarse a asociacin (Figura 8.21). O das tipo PO
activado no instante en que a asociacin deixe de estar activa se a condicin certa (Figura
8.21). En caso de non selo non seria activada (Figura 8.22). Os "flags" de todos os tipos de
accins impulsionais son desactivados no mtodo run da clase ActionSchedulelnfo (lias 3258
3260) para garantir que a accin s executada unha vez en cada activacin.
flag[P]
flag[P1]
i
flag[PO]
i
i
Figura 8.21. Semntica temporal dos "flags" dos diferentes tipos de asociacins.
80 Coa semntica aqu descrita posbel representar todos os tipos de asociacions definidos no estndar IEC
61131-3, coa excepcin dos tipos SD e SL que non teen equivalente no intrprete Grafcet.
385
Asoc
^
--
-,--^------:---^-----_-;--- ^ ---^
iii
i
cond
i
i^
flag[Pl
i
flag[P1]
i
iî
flag(PO]
i
...
Figura 8.22. Semntica temporal dos "flags" das asociacins impulsionais.
8.6.4. Consulta e modificacin de varibeis

Os mtodos getModelVarEvent (lia 3070), getSystemVarEvent (lia 3071) e getStepState
(lia 3072) da clase RunningPolicy invocan directamente aos mtodos de igual nome no xogo
Grafcet (8.5.1.4), permitindo consultar a ocorrencia de eventos e o estado de activacin das
etapas do modelo. De igual modo o mtodo getTimerState (lia 3073) consulta o estado dun
temporizador invocando o mtodo getData (lia 2869) do xogo Grafcet. Os mtodos anteriores
utilzanse na execucin das funcins que conteen o cdigo C++ das condicins e accins
xeradas polo compilador Grafcet. Estes mtodos unicamente consultan valores, sen que exista a
posibilidade de modificar dende estas funcins o estado dunha etapa, temporizador ou evento.
Sen embargo os mtodos getModelVar (lia 3075) e getSystemVar (lia 3079) consultan
valores de varibeis que poden ser modificados dende as funcins C++ utilizando os mtodos
setModelVar (]ia 3077) e setSystemVar (lia 3081), segundo se explica en (6.3.3.3). En cada
ciclo de execucin do intrprete a avaliacin de todas as condicins e a execucin de todas as
accins teen que realizarse utilizando os valores que as varibeis do modelo e do proceso
tean ao comezo do ciclo. Como a execucin de accins pode modificar estes valores preciso
implementar algn mecanismo que mantea os valores que as varibeis teen ao inicio do
ciclo, almacene as modificacins e actualice os valores modificados ao final do ciclo. Este
problema resolto implementando na clase RunningPolicy unha "cach" de datos. Os
elementos almacenados nesta "cach" son instancias da clase parametrizada CacheEntry, cuxa
declaracin simplificada a seguinte:
3295.template <class T>
class CacheEntry : public ptrSeqElem
3296.
3297. {
3298.private:
// identificador da varibel
3299. string name;

// valor ao inicio do ciclo
3300. T initial_value;
// valor modificado
3301. T modified value;

3302. bool modified, updated;// indicadores auxiliares
3303.public:
const string& getKey(void) const;
3304.
bool isUpdated(void) const;
3305.
bool isModified(void) const;
3306.
3307.
// acceso e modificacia do valor
template <class T> void getValue(T& value);
3308.
template <class T> void setValue(const T& value);
3309.
3310.
// actualizacin e aiacronizacin do valor
3311. void update();
3312. void flush(RunningPolicy& runôlicy);
3313 . } ;
386
Cada entrada da "cach" almacena dous valores, o que a varibel tia ao comezo do ciclo
actual -atributo initial_value (lia 3300^-- e o valor modificado durante o ciclo -atributo
modified_value (lia 3301^. O mtodo getValue (lia 3308) devolve o valor de comezo de
ciclo, mentres que o mtodo setValue (lia 3309) almacena o valor modificado. Este mtodo
tamn detecta o intento de modificar a varibel con valores diferentes mis dunha vez na
mesma evolucin do modelo (3.3.3.8), nese caso indcase o erro utilizando os servicio^ do
ncleo da mquina virtual. Para realizar a actualizacin dos valores na "cach" e a
sincronizacin da "cach" cos valores do modelo, utilzanse dous indicadores booleanos e os
mtodos update (lia 3311) e flush (lia 3312). A"cach" representada mediante a clase
DataCache, que proporciona os mtodos que permiten xestionar un conxunto de instancias da
clase CacheEntry. A declaracin simplificada da sa interface pblica a seguinte:
3314.class DataCache
3315. {
3316.public:
3317. bool empty() const;
3318. bool modified() const;
3319. void removeAll();
3320. // consulta e modificacin das entradas da "cach"
3321. template <class T> bool insertValue(string varID, const T& value);
3322. template <class T> bool getValue(string varID, T& value);
3323. template <class T> bool setValue(string varID, const T& value);
3324.
3325. // actualizacin e sincronizacia do valor

3326. void update();
3327. void flush(RunningPolicy& runôlicy);
3328 . } ;
^.
Os mtodos desta interface permiten consultar se hai valores na "cach" -mtodo empty
(lia 3317^, se algn dos valores foi modificado -mtodo modified (lia 3318}-, baleirar
os seus contidos -mtodo removeAll (lia 3319^, actualizalos -mtodo update (lia
3326}- e sincronizalos cos valores do modelo -mtodo flush (lia 3327^. A insercin,
consulta e modificacin das entradas almacenadas na "cach" realzase cos mtodos
insertValue (lia 3321), getValue (lia 3322) e setValue (lia 3323), respectivamente.
O funcionamento da "cach" o seguinte: ao comezo de cada ciclo de execucin do
intrprete, a"cach" est baleira. Cada invocacin dos mtodos getModel Var e getSystem Var
da clase RunningPolicy dende unha accin ou condicin realiza primeiro unha busca do valor
na "cach". Se o valor non est na "cach" crease unha nova entrada co valor obtido do xogo
Grafcet ou da base de datos de E/S da mquina virtual (7.3.1), dependendo do caso. Do
mesmo xeito, os mtodos setModelYar e setSystemVar da clase RunningPolicy tentan modificar
o valor existente na "cach". En caso de que o valor a modificar non estea na "cach", crease
unha nova entrada co novo valor. A Figura 8.23 mostra como exemplo as secuencias de
mensaxes das colaboracins que implementan os mtodos getSystem Var e setSystem Var.
A actualizacin dos valores da "cach" e a sincronizacin cos valores do modelo faise
mediante o mtodo privado flushCache da clase DefaultRunningPolicy, que invocado ao final
do mtodo run (lia 3281) unha vez executadas as accins activas do modelo. A actualizacin
consiste en asignar o valor modificado ao valor inicial na entrada da "cach" para poder
reutilizala, mentres que a sincronizacin consiste en actualizar no xogo Grafcet os valores
modificados na "cach". O instante no que se realiza cada unha destas operacins depende do
tipo de varibel almacenada na "cach":
1. Os valores das varibeis do proceso son actualizadas na "cach" despois de cada evolucin
interna do modelo e sincronizadas co xogo Grafcet despois de cada evolucin externa.
387

Ntese que unicamente as sadas do proceso poden verse afectadas por unha actualizacin
ou sincronizacin, xa que o valor das entradas non pode ser modificado pola avaliacin de
condicins e a execucin de accins.
2. As varibeis internas do modelo son actualizadas na "cach" e sincronizadas co xogo

Grafcet despois de cada evolucin, xa sexa interna ou externa. A escala .de tempo
actualizada no xogo Grafcet ser a mesma na que se produza a evolucin do modelo.
Todas as entradas da "cach" son eliminadas despois dunha evolucin externa do modelo.
Os valores das sadas do proceso modificadas na evolucin son actualizadas na base de datos
de E/S segundo se explica en (8.4.4).
Unha consecuencia derivada da utilizacin da "cach" a reduccin dos tempos de acceso
s varibeis do proceso almacenadas na base de datos de E/S. A base de datos executada nun
proceso da mquina virtual diferente ao do intrprete Grafcet, polo que preciso utilizar algn
mecanismo de exclusin mutua no acceso aos valores da base de datos de E/S coa
correspondente penalizacin temporal que isto implica. Coa utilizacin da "cach", unicamente
se accede base de datos a primeira vez que se consulte ou modifique o valor dunha varibel
do proceso en cada ciclo do intrprete. En consecuencia cando un mesmo valor accedido en
mltiples ocasins en cada ciclo do intrprete, xa sexa porque utilizado en diferentes
condicins ou accins ou en diferentes evolucins internas do modelo, consguese unha
reduccin significativa do tempo preciso para a execucin de condicins e accins.
8.7. Conclusins .
Neste captulo describiuse a arquitectura e o funcionamento do intrprete utilizado para a
interpretacin dos modelos Grafcet definidos polo usuario. O intrprete foi deseado para que
os mdulos da sa arquitectura podan ser substitudos dinamicamente e facilitar as a
implementacin de novas caractersticas e algoritmos sen que sexa preciso recompilar o
intrprete. Tamn se implementou a xestin da informacin de das escalas de tempo diferentes
durante a evolucin dos modelos, de xeito que podan utilizarse algoritmos de evolucin con ou
sen busca da estabilidade. Ademais poden configurarse mediante parmetros diferentes opcins
relacionadas coa utilizacin das das escalas de tempo.
A arquitectura do intrprete foi implementada para permitir a escalabilidade. Toda a
informacin precisa para a evolucin de cada modelo xestionada mediante un `xogo Grafcet',
que tamn contn a informacin utilizada polas tcnicas que optimizan a execucin do cdigo
de condicins e accins do modelo. Isto permite desacoplar a informacin de interpretacin do
modelo da lxica utilizada para a sa evolucin e a execucin do seu cdigo. Deste xeito
resulta simple modificar o intrprete para implementar caractersticas mis complexas, como
por exemplo a interpretacin simultnea de mltiples modelos con diferentes opcins de
configuracin. Entre as melloras que poden inclurse no intrprete poden citarse as seguintes:
1. A utilizacin da informacin sobre os eventos de cada condicin do modelo para descartar
os non significativos na poltica de acceso (8.3.1.1). A recopilacin desta informacin
requirira tamn a modificacin do compilador Grafcet.
2. A reduccin do tempo de ciclo do intrprete implementando polticas de execucin que
reduzan os tempos de acceso s varibeis ou os tempos de execucin das condicins e
accins, por exemplo distribundoas nun sistema multiprocesador.
3. A incorporacin dun mecanismo tipo "watchdog" (semellante ao utilizado nos PLCs) que
permita especificar o tempo de resposta mximo aceptado polo proceso e configurar a
accin a realizar se algn dos ciclos de execucin do intrprete supera este lmite.
-------------------------------------- ----------------m
W^
^
388
r-------------------------------------------------------------------------------------^
m
W
>
11
> > m
^
Wt^
Î II II
O V D
^ ^ 0
EE^
m
0
^1
^p II
m
8
m
'
^
^^
^
^
V
__._._._
_______________________^
(JI
^
>
^
a
`^
,?
`^.
m
c
m
^
>
II
Z`
^ d
------^T
----.,^
im
-m
d
E
>
>
m
E
_^
^^
1;
b;
c^
^:
c^
m^
c
^
d
E
>
E
T
^
i
E
d
^
m
x
c
v ,!
ô^
> .
O^
L
y u
^^
s^
0
m
m
m
V Ip
mD
.^
c. 10
m ^
^
^7

mv
7 Ip
X^t,C
_ ^
O
t
N C
^
V
_
C V
m^
`p N
W V% A
C q
(p ^ p
C n W
m
(q9 i>>
C
W
d
bD
O ^
;
(/1 OC
d ^
^ E
c;?
m
^
m ^
C ^y
O
y
^
^ ^
^
^
^._m. m
^ O ry U_
^
._ ^'c
rL^..^..C
W '>
Figura 8.23. Secuencias de mensaxes da implementacin dos mtodos que acceden aos valores das varibeis do
proceso: a) mtodo getSystemVar; e b) mtodo setSystemVar.
Captulo 9 . Conclusins e futuras

lias de investigacin
Neste captulo resmense as conclusins extradas do desenvolvemento da ferramenta

proposta, indcanse algunhas melloras a realizar en futuras versins e propense futuras lias
de investigacin.
9.1. Conclusins
A ferramenta implementada nesta tese de doutoramento proporciona as compoentes
precisas para integrar as descricins de sistemas cunha lxica secuencial complexa,
especificados combinando unha aproximacin orientada a obxecto co Grafcet, en ambientes de
desenvolvemento de "soflware" para sistemas industriais nos que se utilice unha aproximacin
multiformalismo que proporcione asistencia aos enxeeiros de control durante o ciclo de vida
do sistema.
Os modelos Grafcet poden ser integrados en calquera outra ferramenta utilizando 0
metamodelo Grafcet definido, xa sexa mediante a librara C++ que o implementa ou inclundoo
na propia ferramenta por outros medios. O cdigo para a execucin dos modelos xrase
automaticamente utilizando o compilador implementado. A execucin e simulacin dos
modelos realzase na mquina virtual que proporciona o soporte bsico para o manexo de
eventos, temporizacins e acceso s magnitudes do proceso, e na que se dispn dun intrprete
que pode ser configurado para utilizar diferentes algoritmos de interpretacin. A mquina
virtual pode ser utilizada en arquitecturas heteroxneas e, mediante a definicin dos "drivers"
apropiados, pode interactuarse co proceso mediante mltiples sistemas de E/S diferentes.
Ademais esta interaccin pode ser configurada para que as magnitudes sexan lidas cada vez que
varen, ou ben a intervalos regulares. A estructuracin da aplicacin realzase combinando a
estructura xerrquica do Grafcet coas prbpiedades da orientacin a obxectos que proporciona a
linguaxe C++, que tamn a linguaxe utilizada (estendida coa agregacin de operadores para o
manexo de eventos e temporizacins) para programar os contidos das accins e receptividades
dos modelos Grafcet, o que permite inclur nos modelos as funcionalidades implementadas en
libraras externas, como por exemplo libraras matemticas, de simulacin, de tcnicas de "soft
computing", etc. A ferramenta compltase cun editor grfico que proporciona un punto de
acceso comn a todas as compoentes implementadas.
En conxunto as compoentes da ferramenta permiten que un enxeeiro de control aplique un
proceso de desenvolvemento iterativo baseado na construccin de modelos grficos executbeis
que son validados e refinados progresivamente mediante simulacin, e no que posbel utilizar
389
Captulo 9: Conclusins e futuras lias de investigacin
390
o Grafcet, combinado con outros formalismos, de maneira uniforme ao longo das diferentes
fases do ciclo de vida do sistema de control. A combinacin dunha aproximacin orientada a
obxecto cun formalismo grfico de semntica ben definida para a especificacin de secuencias
complexas, facilita a estructurain dos modelos nas fases de anlise e deseo e a obtencin
automtica do cdigo da aplicacin para ser executado en arquitecturas industriais distribudas.
Durante o deseo e implementacin da ferramenta priorizouse a aplicabilidade, flexibilidde
e portabilidade das sas compoentes, deixando nesta primeira versin os aspectos
relacionados coa eficiencia na execucin e no manexo de memoria nun segundo plano. Isto
pode comprobarse na utilizacin de libraras como STL (baseada no uso de "templates") ou
Common C++, que facilitan a portabilidade ao custe dunha menor eficiencia. Tamn na
arquitectura da mquina virtual, que est implementada en base definicin de interfaces
abstractas e utilizacin de conceptos tomados das arquitecturas baseadas en actores [3].
Nestas arquitecturas a comunicacin entre os procesos (nomenclatura utilizada na mquina
virtual) realzase mediante o intercambio de mensaxes, que son procesados utilizando unha
semntica RTC, de xeito que un proceso non ten en conta unha nova mensaxe ata que non
remate co procesamento da actual. Esta arquitectura ten tres consecuencias principais:
1. Os procesos teen un acoplamento dbil entre eles, o que facilita a substitucin e a
reconfiguracin dinmica da arquitectura.
2. Elimnanse os problemas derivados da concorrencia no interior dos procesos. Debido a que
o procesamento dunha mensaxe non pode ser interrompida, non precisa a inclusin de
mecanismos de exclusin mutua na implementacin dos procesos: Ntese que o
procesamento dun proceso si pode ser interrompido por outro de maior prioridade, mais
isto non afectar ao seu estado interno.
3. Os tempos de resposta ao envo de mensaxes son, en xeral, superiores neste tipo de
arquitecturas que nas baseadas no manexo de interrupcins.
Un inconveniente desta arquitectura o referido ao manexo das temporizacins, que son
implementadas como procesos que notifican a finalizacin dun perodo de tempo utilizando 0
mecanismo de paso de mensaxes. Anda que estas notificacins teen prioridade sobre as outras
mensaxes, non son consideradas ata que o proceso receptor remate o procesamento da mensaxe
actual en caso de habela. Isto ten como consecuencia unha perda de precisin que pode non ser
aceptbel en certas aplicacins. En consecuencia a aplicabilidade da mquina virtual depender
basicamente de tres parmetros:
1. A cantidade de memoria dispobel no equipamento de control utilizado.
2. Os tempos de resposta que o proceso a controlar precise.
3. A precisin requirida nas temporizacins.
Ningn dos parmetros anteriores constante e varan en funcin do equipamento de
control, da configuracin da mquina virtual e dos modelos Grafcet concretos que se utilicen. A
validacin por simulacin dos modelos e o axuste das frecuencias de monitorizacin das
magnitudes do proceso son os medios dos que dispn o enxeeiro de control para comprobar e
axustar o funcionamento da aplicacin.
En contrapartida a estas limitacins, as arquitecturas implementadas son portbeis e
flexbeis. As no compilador poden inclurse novas funcionalidades de forma simple êngadindo
novas fases ou reimplementando as existentes. De igual maneira a implementacin da mquina
virtual pode ser portada facilmente a diferentes equipamentos de control, poden inclurse
mltiples "drivers" para utilizar diferentes dispositivos de E/S, a sa configuracin pode ser
391
Seccin 9.2: Melloras a realizar
modificada dinamicamente, e a interaccin do subsistema de aplicacin co subsistema de E/S

pode ser configurada. As funcionalidades que proporciona a mquina viriual (xestin de
eventos e temporizacins, acceso s magnitudes do proceso, sincronizacin da imaxe de E/S,
etc.) non se limitan sa utilizacin co intrprete Grafcet, senn que son comns no control de
DEDS, polo que a mquina virtual pode ser reutilizada na implementacin doutras aplicacins,
como por exemplo: intrpretes de RdPI ou StateCharts, emuladores de PLC, etc.
Tamn o intrprete Grafcet ten unha arquitectura lxica flexbel na que poden substiturse
dinamicamente algunha das sas compoentes, como a poltica para a obtencin de novos
eventos, o algoritmo de evolucin ou o de execucin, por exemplo. A interpretacin dos
modelos pode realizarse utilizando semnticas con ou sen busca de estabilidade, e nas
primeiras, pode configurarse a forma en que os eventos e varibeis son utilizados nas das
escalas de tempo utilizadas. Anda que a versin actual s permite a interpretacin dun nico
modelo Grafcet, o intrprete foi deseado para permitir, con pequenas modificacins, a
interpretacin simultnea de mltiples modelos. Da mesma maneira, a implementacin de
novas polticas de evolucin faciltase implementando un mecanismo de composicin que
permite reutilizar as xa existentes.
9.2. Melloras a realizar

Algns dos aspectos mis relevantes que pode ser mellorados nas diferentes compoentes da
ferramenta presentados nesta documentacin son os seguintes:
1. Inclur no metamodelo as extensins adoptadas na ltima revisin do estndar Grafcet [85]
e na mquina virtual un algoritmo de interpretacin que implemente as modificacins
semnticas debidas a esas extensins.
2. Inclur soporte utilizacin dun formato estndar (p.e. XML) para o intercambio de
modelos Grafcet entre aplicacins.
3. Inclur soporte utilizacin dalgunha linguaxe de descricin de dispositivos (como a
utilizada en FieldBus, por exemplo) para representar a informacin de configuracin dos
"drivers" de E/S.
4. Implementar na mquina virtual un mecanismo tipo "watchdog" semellante ao dispobel
nos PLCs que permita especificar un tempo de resposta mximo para o intrprete e detecte
cando este superado.
5. Adaptacin da mquina virtual para permitir a implementacin de intrpretes doutros
formalismos de modelado de DEDS (RdPI, StateCharts, etc.).
6. Implementacin do acceso remoto aos servicios da mquina virtual, actualmente baseado
no intercambio de mensaxes, por algn mecanismo de invocacin remota como 0
proporcionado por CORBA, p.e.
7. Optimizar a eficiencia en termos de utilizacin de memoria e tempo de procesamento das
implementacins do compilador e da mquina virtual.
8. Implementacin de "drivers" de E/S para ser utilizados con buses de campo (p.e. Profibus
ou Fieldbus) e protocolos de intercambio de informacin con outras aplicacins (p.e.
NetDDE ou OPC).
9.3. Futuras lias de investigacin

Algunhas das lias de investigacin que supoen unha continuacin do traballo realizado
nesta tese de doutoramento son as seguintes:
Captulo 9: Conclusins e futuras lias de investigacin
392
l. A anlise e proposta de tcnicas que permitan tomar en consideracin as restriccins de

tempo e memoria dos equipamentos de control utilizados. A priori isto implica a
implementacin de versins especficas da mquina virtual mis dependentes do sistema e
a modificacin do cdigo xerado polo compilador para obter unha versin mis compacta.
2. A anlise, proposta e implementacin de tcnicas para a integracin doutras linguaxes e
formalismos na especificacin de accins e condicins, sendo de especial interes as
linguaxes IEC, as linguaxes de fluxo de datos e a utilizacin de mtodos de "soft
computing" (bases de regras, lxica difusa, etc.).
3. O estudio, proposta e implementacin de regras formais de utilizacin que permitan
mellorar a reusabilidade dos modelos Grafcet en ambientes orientados a obxecto mediante
mecanismos como a herdanza, a composicin ou a parametrizacin.
4. A anlise e proposta de mtodos para a integracin de formalismos de especificacin de

sistemas complexos en base definicin dos seus metamodelos.
5. A proposta de mtodos para a adaptacin de metodoloxas de desenvolvemento "software"
implementacin de aplicacins industriais baseadas nos estndares IEC. Ten especial
interese a proposta e implementacin de extensins a UML, de xeito que poidan aplicarse
con ese obxectivo as ferramentas CASE existentes.
6. O estudio, proposta e implementacin de extensins ferramenta orientadas ao
desenvolvemento de software para sistemas "batch", baseados no uso de `receitas'.
7. A anlise, proposta e implementacin de tcnicas para a aplicacin da ferramenta no
desenvolvemento de aplicacins con arquitecturas distribudas, como por exemplo as
baseadas na utilizacin de compoentes ou os sistemas multiaxente.
Anexo A. Caractersticas do SFC

no estndar IEC 61131-3
Neste anexo inclense as tboas que resumen as caractersticas do SFC tal e como son
definidas no estndar IEC 61131-3 [86].
^
I
I*** I
Etapa: representacin grfica con arcos orientados.

*** = nome da etapa
+-----+
+_______+
I I *** I I
Etapa inicial: representacin grfica con arcos orientados.
*** = nome da etaPa inicial
+_______+
STEP *** :
Eta a: definicin textual sen arcos orientados.
(* Step Body *)
2
*s P nome da etapa
END STEP
INITIAL_STEP *** :
(* Step Body *)
END STEP
3a
Flag de estado da etapa (valor booleano)

*** = nome da etapa
***.X = 1 cando *** estea activa, 0 noutro caso
*** x
+-- I--+
I*** I ---
+-----+
3b
Eta a Inicial: definicin textual sen arcos orientados.

ss: nome da etapa inicial
Flag de estado da etapa (valor booleano)

conexin directa dunha varibel booleana.
**.X ao lado dereito da etapa ***
Tempo de activacin da etapa
*** .T
* * * = nome da etapa
***.T = varibel ti o TIME
Notas
1.
Se se incle soporte para algunha das caractersticas 3a, 3b ou 4, entn debe considerarse un
erro o intento de modificacin da varibel asociada. Por exemplo, se temos unha etapa
chamada S4, as seguintes instruccins ST deberan producir un erro:
S4.X := 1;
( * ERRO *)
S4.T := t#100ms;
( * ERRO *)
2. A conexin superior nunha etapa inicial non precisa cando non tea antecesores.
Tboa A-I. Caractersticas das etapas.
393
Anexo A: Caractersticas do SFC no estndar IEC 61131-3
I
+-----+
^STEP7^
+-----+
^ÎX2 . 4 &%Ix2. 3
^
Definicin da condicin de transicin mediante ST
+-----+
^STEPS^
+-----+
^
%IX2.4
ÎX2.3
(
+-----+
^STEP7^
+-----+
^
+- - - ^ ^ - - - - - ^ ^ - - - - - - - -+
^
^
+-----+
Definicin da condicin de transicin mediante LD
^STEPB^
+-----+
^
^
+-----+
+-------+
^
^
&
3
%ZX2.4- ^
^STEP7^
+-----+
^
^-----+
^
%IX2.3-^
+-------+
Definicin da condicin de transicin mediante FBD
^
+-----+
^STEPB^
+-----+
^
^
+-----+
^STEP7^
+-----+
>TxANx> - - - - - - - - - - I
^
+-----+
Utilizacin de conectores nas condicins de transicin:
^STEPB^
+-----+
^
^
4a
4b
ÎX2.4
ÎX2.3
+--- ^ ^----- ^ ^-->TR.ANx>

I
+-------+
I
I ^&
%IX2.4- ^
^-->TxANx>
%IX2.3-^
mediante LD
mediante FBD
+-------+
STEP STEP7 : END_STEP
TRANSITION FROM STEP7 TO STEPB:
._%IX2 . 4 &%IX2 . 3;
Definicin da condicin de transicin mediante ST
END_TRANSITION
STEP STEPS : END STEP
STEP STEP7 : END_STEP
TRANSITION FROM STEP7 TO STEPB:
6
LD %IX2 . 4
AND %IX2.3
END_TRANSITION
STEP STEP8 : END STEP
Definicin da condicin de transicin mediante IL
394
Anexo A: Caracteristicas do SFC no estndar IEC 61131-3
395
I
+-----+
^STEP7^
+-----+
I Tx^7e
^
+-----+
Utilizacin do nome de transicin nas condicins de

transicin:
.,
^STEPB^
+-----+
TRANSITZON TRAN78:
^%IX2 .4
.1a
%Ix2 . 3 TRAN78 ^
+---^^-----^^------()---+
I
I
mediante LD
END TFtANSITION
TRANSITION TRAN78:
+-------+
^
&
^
^--TRAN78
%IX2 . 4- ^
^
%IX2.3-^
+-------+
END TRANSITION
7b
mediante FBD
TRANSITION TRANS78 :
LD %IX2 . 4
,^C
AND %IX2.3
END TRANSITION
mediante IL
TRANSITION TRANS78 :
. _ %IX2 . 4 & %IX2 . 3 ;
mediante ST
END TRANSITION
Notas
1.
2.
Se se incle soporte para a caracterstica I da Tboa A-I, entn debe inclurse soporte para cando
menos unha das caractersticas I, 2, 3, 4 ou 7 desta tboa.
Se se incle soporte para a caracterstica 2 da Tboa A-I, entn debe inclurse soporte para cando
menos unha das caractersticas 5 ou 6 desta tboa.
Tboa A-II. Caractersticas das transicins e das condicins de transicin.
Calquera varibel booleana nun bloque VAR ou VAR OUTPUT pode ser unha accin
+----------------------------------------+
ACTION_4
+----------------------------------------+
^
^ÎX1
^MX3
SB.X
^Q17 ^
21
+--- ( I----- I I---- I I----- (> ---+

I
I
+-------+
I
I
^
^
LT
C--^
^
I
Declaracin grfica de bloques de definicin de
^Mxl o ^
^---------(S)---+
+- ---( EN ENO ^
accins mediante LD
I
I
I D--i
I
+-------+
I
I
I
I
+----------------------------------------+
+----------------------------------------+
OPEN_VALVE_1
+----------------------------------------+
^
...
^
^
^
+________________+
Î VALVE_1_READY ^^
^+________________+
2S
^
^
STEPB. X
Utilizacin de elementos do SFC nos bloques e

definicin de accins
I
I
^ +-----------------+ +---+- ----------+ I
^ VALVE_1_OPENING ^--^ N ^VALVE_1_FWD^ ^
+-----------------+
^
...
+---+-----------+ ^
^
+----------------------------------------+
+----------------------------------------+
(
ACTION_4
+----------------------------------------+
^
+---+
^
^
%IX1--^ & ^
^
^
^--%QX17
%MX3--^
^
2f
s s. x- -------- I
+---+
FF28
+_ ___+
^
^
^ SR ^
+------+ ^ Q1^-^MX10
Declaracin grfica de bloques de definicin de

accins mediante FBD
^
^
^
C--I LT I--IS1 I
I
^
n--I
I
I +----+
+------+
I
^
+----------------------------------------+
ACTION ACTION 4:
%Qx17 = Îxl &%MX3 & ss . x;
3s
FF28 (S1 :_ (C<D) ) ;
^MX10 := FF28.Q;
END ACTION
ACTION ACTION_4:
LD 58.X
Declaracin textual de bloques de definicin de

accins mediante ST
AND ÎX1
AND ^MX3
sT ^Qxi7
31
LD c
LT D
S1 FF28
Declaracin textual de bloques de definicin de

accins mediante IL
LD FF28.Q
ST %MX10
END ACTION
Notas
1. O flag de estado da etapa S8.X utilzase para obter o valor desexado, que estando S8 desactivado, ser
%QX17:=0.
2. Se se incle soporte para a caracteristica 1 da Tboa A-I, entn tamn debe inclurse para unha ou mais
das caractersticas desta tboa ou para a caracterstica 4 da Tboa A-IV.
3. Se se incle soporte para a caracterstica 2 da Tboa A-I, entn tamn debe inclurse para unha ou mais
das caractersticas 1, 3s ou 3i desta tboa.
Tboa A-III. Declaracin de accins.
396
397
Anexo A: Caracteristicas do SFC no estndar IEC 61131-3
+----+
+-----+----------+---+
^ SB ^--^
L ^ ACTION_ 1 ^DN1^
+----+ ^t#lOS^
^
^
Bloque de definicin de accins
+-----+----------+---+
+ DN1
+----+
+-----+----------+---+
^ S8 ^--^
L ^ ACTION_ 1 ^DN1^
+----+ ^t#lOS^
^
^
----------+ DNl ^ P ^ ACTION_2 ^ ^
+-----+----------+---+
^
^
^
N ^ ACTION_3 ^
^
+-----+----------+---+
Bloques de definicin de accins concatenados
STEP S8:
ACTION_ 1(1, T#lOS, DN1)
ACTION_2 ( P)
ACTION_3(N)
END STEP
Definicin textual das etapas
+-----+---------------------+---+
^
N ^
ACTION_4
^
^--
+-----+---------------------+---+
t}
$QxI^ :_ $IxI & $ntx3 & se .x; ^
FF28
$MX10 := FF28.Q;
( S1 :_ (C<D));
Campo "d" do bloque de definicin de accins
+-------------------------------+
Nota
I. Cando se utilice a caracterstica 4, o nome de accin conrespondente non pode utilizarse en
ningn outro bloque de definicin de accins.
Tboa A-IV. Asociacin de etapas e accins.
"a": tipo
"b": nome da accin
"c": indicador booleano
"d": definicin da accin mediante:
Linguaxe IL
Linguaxe ST
Linguaxe LD
Linguaxe FBD
2
3
4
5
6
7
+-----+------------+---+
---^
$ZX7.5
+---+------+---+
OK1 ^
^
SB.X
+---^^-----^^-----^ N ^ ACT1 ^DN1^--()---+
+---+------+---+
Utilizacin de bloques de definicin de accins nos diagramas de bloques funcin:

+---+
+---+------+---+
S8.X--^ & ^-----^ N ^ ACT1 ^DN1^---OK1
$IX7.5--^
I
I
+----------------------+
Utilizacin de bloques de definicin de accins nos diagramas de contactos:
c ^--
+-----+------------+---+
+---+------+---+
Notas
1.
O campo "a" pode omitirse cando o tipo da accin "N".
2.
O campo "c" pode omitirse cando non se utilicen indicadores.

Tboa A-V. Caractersticas dos bloques de definicin de accins.
1
2
3
4
5
6
7
8
9
10
Non almacenado (cualificador nulo)

Non almacenado
Reset
Ningn
S
L
D
P
SD
DS
SL
Set
Limitado
Demorado
Pulso
Almacenado e demorado
Demorado e almacenado
Almacenado e limitado
Tboa A-VI. Tipos de accins.
+-----+
^ S3
^
+-----+
Secuencia simple: a alternancia etapa-transicin reptese en

series.
^
+c
^
+- ----+
Exemplo: a evolucin dende S3 a S4 ter lugar s si S3 est

activo e a condicin de transicin c certa.
^ S4
+-----+
2a
+- I--+
Diverxencia nunha seleccin desecuencia: a seleccin entre
^ ss ^
+----+
^
varias secuencias represntase mediante tantos smbolos de

transicin baixo a lia horizontal como posbeis evolucins haxa.
O asterisco indica que a prioridade de avaliacin das condicins
de transicin de esquerda a dereita.
+- - - - - - * - - - - - -+- - . . .
I
I
+ f
+ e
^
+----+
^ sa ^
+----+
^ s5 ^
+----+
I
+----+
I
I
+----+
^ ss ^
+----+
Diverxencia nunha seleccin de secuencia: o asterisco seguido de
plas numeradas, indica explicitamente a prioridade de avaliacin

das condicins de transicin. A pla con prioridade mais alta ser
+------*------+-- ...
2b
'
Iz
+f
I
+----+
+----+
I
+----+
I sa ^
I
+- ---+
^ ss ^
+----+
^
^
+------*------+-- ...
2c
aqueteaomenornmero.
I1
+e
^
+----+
^ s6 ^
Exemplo: a evolucin dende SS a S6 ter lugar s si SS est

activo e a condicin de transicin e certa, ou dende SS a S8 se
SS est activo, a condicin de transicin f certa e a condicin e
falsa.
+e
+ NOT e& f
^
+- ---+
I
+- ---+
^ S6 ^
+----+
I
^ Sa ^
+----+
I
Exemplo: a evolucin dende SS a S8 ter lugar s se SS est

activo e a condicin de transicin f certa, ou dende SS a S6 se
SS est activo, a condicin de transicin e certa e a condicin f
falsa.
Diverxencia nunha seleccin de secuencia: a conexin das plas
indica que o usuario tenq ue garantir exPlicitamente que as

condicins de transicin son mutuamente exclusivas, tal e como 0
defineoIEC60848.
Exemplo: a evolucin dende SS a S6 ter lugar s si SS est
activo e a condicin de transicin e certa, ou dende SS a S8 se
SS est activo, a condicin de transicin f certa e a condicin e
falsa.
398
399

I
+----+
f
+----+
^ s7 ^
^ s9 ^
+----+
^
Converxencia nunha seleccin de secuencia: o final dunha
+----+
^
seleccin entre varias secuencias represntase mediante tantos

smbolos de transicin sobre a lia horizontal como secuencias
+h
+j
+------+------+-- ...
^
+-----+
^ sio ^
rematen na converxencia.
:.
Exemplo: a evolucin dende S7 a S10 ter lugar s si S7 est
activo e a condicin de transicin h certa, ou dende S9 a S10 se
S9 est activo e a condicin j certa.
+-----+
I
I
+-----+
^ s11 ^
Diverxencia de secuencias simultneas: represntase mediante un
+-----+
^
nico smbolo de transicibn sobre a dobre lia horizontal que

indica a diverxencia.
__+____= I =____+_=
I
^
Exemplo: a evolucin dende S11 a S12, S14,... ter lugar sb si

S11 est activo e a condicin de transicin b certa. Despois da
+ b
+-----+
+-----+
activacin simultnea de 512, 514,... cada secuencia evoluciona
^ S12 ^
independentemente.
+-----+
+-----+
I
I
+-----+
I
I
+-----+
s14 ^
^ S13 ^
^ s15 ^
Converxencia de secuencias simultneas: represntase mediante
+- ----+
+- ----+
un nico smbolo de transicin baixo a dobre lia horizontal que
I
I
__+_____+_____+__ ...
indica a converxencia.
^d
^
+-----+
Exemplo: a evolucin dende S13,S15... a S16 ter lugar s si

todas as etapas que estn por riba da dobre lia horizontal e
conectadas a ela estn activas e a condicin de transicin d
^ si5 ^
certa.
+-----+
I
I
+-----+
^ S30 ^
+-----+
^
+---*---+
^
^
+ a
+ d
+-- I--+
( s3i I
^
I
$a
-+
^b
$C
+_ _ ^__+
^ s32 ^
^
^
$b
+- ----+
I
i
+^
I
I
+---+---+
I
+-----+
^ S33 ^
+-----+
^
Salto de secuencia cara adiante: este salto un caso especial da

seleccin de secuencia, no que unha ou mais das plas non
conteen etapas. As mesmas caractersticas aplicbeis seleccin
de secuencia (2a, 2b e 2c) son tamn aplicbeis ao salto.
Exemplo: a evolucin dende S30 a S33 ter lugar s si a
condicin de transicin a falsa e a condicin d certa. Desta
maneira sltase a secuencia (531, S32).

I
+-----+
^ S30 ^
+-----+
^
+ a
^
+---------+
^
^
+-----+
^
6a
^ s31 I
-+
Ib
+__ ^__+
^ s32 ^
^
^
+-----+
I
6b
6C
*-----+
Salto de secuencia cara atr.s: este salto un caso especial da

seleccin de secuencia, no que unha ou mais das plas volven a
unha etapa previa. As mesmas caracteristicas aplicbeis
seleccin de secuencia (2a, 2b e 2c) son tamn aplicbeis ao salto.
Exemplo: a evolucin dende S32 a S31 ter lugar s si a
condicin de transicin c falsa e a condicin d certa. Desta
maneira a secuencia (S31, S32) reptese.
I^ Id
I
I
I
+-----+ +---+
^ S33 ^
+-----+
^
^
+-----+
^ S30 ^
+-----+
^
+ a
^
+----<----+
^
i
+-----+
^
S31 ^
+-----+
,^
^b
^
+-----+
i
_I
^
^ S32 ^
+-----+
^
^
^
*-----+
Arcos orientados: cando sexa preciso clarificar o sentido dunha

conexin entre dous elementos do SFC, pode inclurse na lia que
os una unha pequena cabeza de frecha (>) que o indique
explicitamente.
I ^ i d ^
^
^
^
+->-+
+-----+
^ S33 ^
+-----+
^
Tboa A-VII. Estructuras de control.
400
Anexo B . Funcionalidades bsicas

da librara
Neste anexo descrbense de forma breve as funcionalidades bsicas relacionadas co

almacenamento e representacin de varibeis e tipos de datos implementadas como parte da
librara que da soporte s diferentes compoentes da ferramenta desenvolvida nesta tese de
doutoramento. Outras funcionalidades que non se incluron neste anexo e que tamn forman
parte da librara son, por exemplo, os mecanismos de conta de referencias a obxectos ou a
implementacin da `persistencia'.
6.1. Contedores
A librara incle contedores con diferentes semnticas no referente `persistencia', copia e
asignacin de elementos, para o manexo de coleccins de obxectos de distintos tipos con
identificadores alfanumricos nicos. A implementacin destes contedores est baseada nas
coleccins definidas como parte da librara STL [11][123]. Na Figura B.1 pode verse o
diagrama das clases utilizadas para representar os distintos tipos de contedores implementados,
e na Tboa B-I resmense as propiedades de cada un.
^^-------
^------^
id2ptrSeq
j-^
elements : map<string, E>
Storable0bject
read( )
e()
getPersistenceld( )
^^---^
dcid2ptrSeq J ^
^Ê^
pdcid2 trSeq
read( )
write( )
ptrSeqElem
getKey( )
^
^^--
pptrSeqElem
dcptrSeqElem I
pid2 trSe
read( )
vrrite^l
read( )
write( )
clone( )
pdcptrSeqElem
Figura B.1. Diagrama de clases dos contedores implementados na librara.
401
Anexo B: Funcionalidades bsicas da librara
402
id2ptrSeq
ptrSeqElem
Non
Por referencia
dcid2ptrSeq
dcptrSeqElem
Non
Por valor
pid2ptrSeq
pptrSeqElem
Si
Por referencia
pdcid2ptrSeq
pdcptrSeqElem
Si
Por valor
Tboa B-I. Propiedades dos contedores implementados na librara.
A clase id2ptrSeq unha clase parametrizada que deiine e implementa a interface bsica
para o manexo dunha coleccin de obxectos de tipo E(e derivados) identificados mediante
unha chave alfanumrica nica. Esta clase non implementa a persistencia dos elementos que
almacena, e as operacins de copia e asignacin de elementos son unicamente por referencia
("shallow copy"). A interface pblica desta clase a seguinte:
3329.template <class E>
3330.
class id2ptrSeq
3331. {
3332.public:
3333. // declaracin de referencias e apuntadorea aos elementos da coleccin
3334. typedef E* pointer;
3335. typedef const E* constôinter;
3336. typedef E& reference;
3337. typedef const E& const_reference;
3338. // constructores/deatructor
// constructor
3339. id2ptrSeq();
3340.
3341.
id2ptrSeq(const id2ptrSeq& seq); // constructor de copia
// destructor
virtual -id2ptrSeq();
3342. // consulta
bool empty() const;

unsigned size() const;
3345. // asignacin/iasercin elementoa
3343.
3344.
// L colaccin baleira?
// nmero de elamentos
3346. virtual void assign(const_iterator first, const_iterator last);
3347. iterator insert(pointer element);
3348. // eliminacin elementos
3349. unsigned erase(const string& key);
3350. void erase(iterator element);
3351. void erase(iterator first, iterator last);
3352. // acceso aos extremoa da coleccin
iterator begin();
3353.
iterator end();
3354.
3355. reverse_iterator rbegin();
3356. reverse_iterator rend();
3357. const_iterator begin() const;
3358. const_iterator end() const;
3359.
3360.
3361.
3362.
3363.
3364.
3365.
3366.
3367.
3368.
3369.
3370.
3371.
3372.
3373 . }
const_reverse_iterator rbegin() const;
const_reverse_iterator rend() const;
// busca de elemeatos
iterator find(const string& key);
const_iterator find(const string& key) const;
// outras operacins
void clear();
/ / baleirar coleccin ( sen destruir elementos)
// baleirar coleccin ( destruindo elementos)
void destroy();
void swap(id2ptrSeq& seq);
// intercambiar elementos entre coleccins
// operadores
// asignacia
id2ptrSeq& operator= (const id2ptrSeq& seq);

bool operator== (const id2ptrSeq& seq) const;
// i gualdade
// referencia
reference operator[](const string& key);

const_reference operator[](const string& key) const; // referencia constante
403
Seccin B.1: Contedores
Internamente esta clase capsula un mapa STL con chaves tipo string e elementos de tipo E*
-atributo elements (Figura B.1 }-, e os mtodos da sa interface non son mais que
adaptadores dos mtodos equivalentes no mapa. A clase tamn define iteradores bidireccionais
(non includos aqu) que capsulan aos do mapa e penmiten utilizar a coleccin como se se
tratase dun contedor de elementos tipo E, ocultando os detalles do manexo de apuntadores aos
elementos. Na implementacin dos mtodos da clase id2ptrSeq presuponse que os elementos
almacenados na coleccin implementan a interface seguinte:
3374.struct ptrSeqElem
3375. {
3376. virtual const string& getKey(void)

3377. } ;
const = 0;
O mtodo getKey devolve o identificador alfanumrico nico do elemento. O seguinte

cdigo mostra un exemplo de utilizacin da clase id2ptrSeq:
3378.// Declaracia da clase dos elementos
3379.class Element : public ptrSeqElem {
3380. string key;
3381.public:
3382. Element(const string& k) : key(k){}
3383. const string& getKey(void) const {return key;}
3384. }
3385.
3386.// Iastanciacin da coleccin e o iterador
3387.typedef id2ptrSeq<Element> ElementSeq;
3388.typedef id2ptrSeq<Element>::const_iterator const_element_iterator;
3389.
3390.// Utilizacin da coleccia
3391 . main ( )
3392. {
3393. // declaracin da coleccin
3394. ElementSeq elements;
3395. // declaracin doa elementoa
3396. Element el("first");
3397. Element e2("second");
3398. // inaerimento dos elementos na coleccin
3399. elements.insert(&el);
3400.
elements.insert(&e2);
3401.
3402.
3403.
// percorrido e acceso ao ideatificador dos elementos

for (const_element_iterator iter = elements.begin();
iter != elements.end();
3404.
3405.
3406. }
cout
++iter)
iter->getKey();
Os demais contedores implementados son definidos mediante "templates" derivados de

id2ptrSeq. O contedor pid2ptrSeq (Figura B.1) engade o soporte persistencia dos elementos
almacenados na coleccin. A declaracin pblica da sa interface a seguinte:
3407.template <class E>
class pid2ptrSeq : public id2ptrSeq<E>, public StorableObject
3408.
3409. {
GESCA_DECLARETEMPLATE_PERSISTENT
3410.
3411.public:
3412.
3413.
virtual bool write(Storage& st) const;
virtual bool read(Storage& st);
3414 . } ;
3415.
3416.GESCA IAiPLEtdENITEMPLATEI_PERSISTENT(pid2ptrSeq, E)
404
Toda clase que utilice o mecanismo de `persistencia' implementado pola librara ten que ser
derivada da interface StorableObject (Figura B.1), e implementar os mtodos read e write que
son os que xestionan a`serializacin' das instancias da clase. Estes mtodos reciben como
parmetro unha instancia da clase Storage, que a que manexa os detalles da implementacin
e
GESCA_DECLARETEMPLATE_PERSISTENT
macros
da
`persistencia'.
As
GESCA IMPLEMENTTEMPLATEI_PERSISTENT serven para inclur nas coleccins
`serializbeis' a declaracin e implementacin de mtodos auxiliares utilizados polo
mecanismo de `persistencia'. A implementacin da clase pid2ptrSeq presupn que os
elementos que almacena implementan a interface seguinte, que engade as operacins de
`serializacin' do elemento s definidas pola interface ptrSeqElem:
3417.struct pptrSeqElem : public virtual ptrSeqElem, public virtual StorableObject
3418 . {
3419. virtual bool write(Storage& st) const = 0;
3420. virtual bool read(Storage& st) = 0;
3421 . } ;
Os outros dous contedores implementados na librara: dcid2ptrSeg e pdcid2ptrSeq (Figura

B.1), son especializacins dos anteriores que implementan as operacins de copia e asignacin
cunha semntica por valor ("deep copy"). A implementacin dambos contedores presupn que
os elementos que almacenan implementan a interface seguinte, que engade a operacin de
`clonacin' do elemento s definidas pola interface ptrSeqElem:
3422.struct dcptrSeqElem : public virtual ptrSeqElem
3423. {
virtual dcptrSeqElem* clone(void) const = 0;
3424.
3425 . } ;
O mtodo clone devolve unha copia do elemento. O cdigo seguinte mostra exemplos da
declaracin de elementos e coleccins utilizando os distintos contedores implementados na
librara:
3426.// Coleccin sea `persistencia' e con copia por referencia
3427.class Element : public ptrSeqElem
3428. {
3429. string key;
3430.public:
3433. }
3434.
3435.typedef id2ptrSeq<Element> ElementSeq;
3436.typedef id2ptrSeq<Element>::iterator element_iterator;
3437.
3438.// Coleccin con `persistencia' e con copia por referencia
3439.class Element : public pptrSeqElem
3440. {
string key;
3441.
3442.public:
Element(const string& k) : key(k){}

3443.
3444.
3445.
3446.
const string& getKey(void) const {return key;}

bool write(Storage& st) const { st key; return true;}
bool read(Storage& st) { st key; return true;}
3447. }
3448.
3449.typedef pid2ptrSeq<Element> ElementSeq;
3450.typedef pid2ptrSeq<Element>::iterator element_iterator;
405
Seccin B.2: Varibeis e declaracins
34_51.// Colecci a sen `peraistencia' e con copia por valor

3452.class Element : public dcptrSeqElem
3453. {
3454. string key;
3455.public:
3457. Element(const Element& e) : key(e.key){}
3459. dcptrSeqElem* clone(void) const {return new Element(this);}
3460. }
3461.
3462.typedef dcid2ptrSeq<Element> ElementSeq;
3463.typedef dcid2ptrSeq<Element>::iterator element_iterator;
3464.
3465.// Coleccia con `persistencia' e con copia por valor
3466.class Element : public pdcptrSeqElem
3467. {
3468. string key;
3469.public:
3471. Element(const Element& e) : key(e.key){}
3473. dcptrSeqElem* clone(void) const {return new Element(this);}
3474. bool write(Storage& st) const { st key; return true;}
3475. bool read(Storage& st) { st key; return true;}
3476. }
3477.
3478.typedef pdcid2ptrSeq<Element> ElementSeq;
3479.typedef pdcid2ptrSeq<Element>::iterator element_iterator;
B.2. Varibeis e declaracins

A librara incle diferentes clases para manexar os distintos tipos de varibeis e declaracins
utilizados na ferramenta implementada. Como pode verse na Figura B.2, todas as clases
definidas son derivadas da interface pdcptrSeqElem, polo que poden ser utilizadas
conxuntamente cos contedores explicados no apartado anterior. A descricin detallada das
clases definidas a seguinte:
ElementAccess
Enumeracin que define o tipo de acceso permitido ao valor dunha varibel. Os valores
escalares definidos son:
read, o valor pode ser consultado, mais non modificado.
write, o valor pode ser modificado, mais non consultado.
readwrite, o valor pode ser consultado e modificado.
ElementScope
Enumeracin que define o alcance dunha varibel en relacin ao modelo no que utilizada.
Os valores escalares definidos son:
local, a varibel definida no contexto do modelo e s pode ser utilizada nese contexto.
shared, a varibel definida no contexto do modelo e pode ser utilizada fora dese contexto.
external, a varibel utilizada no modelo mais definida fora do seu contexto.
406

pdcptrSeqElem
StorableObject
enumeration
ElementAccess
read
vrtite
readwrite
^
IDataElement
^T ---TimedValue
value : T
timestamp : double
enumeration
ElemeniScope
local
shared
eztemal
setKey( )
canRead()
canWrite( )
canShare()
ype0f( )
size0^
IDataDeclaretion
createVar( )
GescaDataElement
name : string
access : ElementAccess
scope : ElementScope
operator-( )
T ---^
GescaVar
value : T
getValue( )
setValue( )
'
ISystemDataDeclaration
getDDredDO
setDDriverlD( )
getlOPointlD( )
setlOPointlD( )
getNumValues( )
setNumValues( )
getPeriod()
setPeriod()
createlORTDBEntry( )
IModelDataDeclaration
dumpConstructor( )
^T -------^
T ---- ^
--------^
'------- -' GescaS stemVarDecl
GescaS stemVar
ddrired id : string
value : T'imedValue<T>
iopomt id : stnng
numyalues : unsigned
getValue( )
period : double
setValue( )
^---- ^
GescaVarDecl
T --------^
Figura B.2. Diagrama de clases das varibeis e declaracins implementadas na librara.
IDataElement
Clase abstracta que defne a interface comn a todas as clases da librara utilizadas para
representar as varibeis e as declaracins de varibeis. A sa declaracin a seguinte:
3480.struct IDataElement : public pdcptrSeqElem
3481 . {
3482.
3483.
3484.
3485.
// modificacin do identificador
virtual void setKey(const string& name) = 0;
// consulta do tipo de acceso e alcaace
virtual bool canReadValue() const = 0;
virtual bool canWriteValue() const = 0;
3486.
virtual bool canShareValue() const = 0;
3487.
3488.
// conaulta do tipo de datos da varibel
virtual const type_info& typeOf() const = 0;
3489.
virtual size_t sizeOf() const = 0;
3490.
3491. };
3492.
3493.// Apuntadorea e referencias a elementos de datoa
3494.typedef IDataElement data_element;
3495.typedef IDataElement* dataôinter;
3496.typedef IDataElement& data_reference;
3497.typedef const IDataElement* const_dataôinter;
3498.typedef const IDataElement& const_data_reference;
Seccin B.2: Varibeis e declaracins
407
IDataDeclaration
Clase abstracta que define a interface comn a todas as clases utilizadas para representar
declaracins de varibeis. A sa declaracin a seguinte:
3499.struct IDataDeclaration : virtual public IDataElement
3500. {
3501. // mtodo constructor ( varibel do tipo declarado)
3502. virtual dataôinter CreateVar() const = 0;
3503 . } ;
Esta interface declara o mtodo CreateVar, que un mtodo constructor ("factory method",
[67]) utilizado para crear unha instancia do tipo de varibel que corresponde declaracin.
IModelDataDeclaration
Clase abstracta que define a interface das clases utilizadas para representar as declaracins
de varibeis internas aos modelos. A sa declaracin a seguinte:
3504.struct IModelDataDeclaration : virtual public IDataDeclaration
3505. {
3506. virtual void dumpConstructor(ostream& out) const = 0;
3507 . } ;
Esta interface declara o mtodo dumpConstructor, que devolve unha representacin textual
do cdigo C++ que crea unha instancia do tipo de varibel que corresponde declaracin. Este
mtodo utilizado polo compilador Grafcet (6.5.1.9) para xerar o cdigo das declaracins de
varibeis do modelo (lias 1498-1503).
ISystemDataDeclaration
Clase abstracta que define a interface das clases utilizadas para representar as declaracins
de varibeis do proceso utilizadas nos modelos. A sa declaracin a seguinte:

3508.struct ISystemDataDeclaration : virtual public IDataDeclaration
3509. {
// "driver" no que a varibel est asignada
3510.
virtual void setDDriverID(const string& dd) = 0;
3511.
virtual const string& getDDriverID(void) const = 0;
3512.
3513. // punto de $/ S no que a varibel est asignada
virtual void setIOPointID(const string& ioôint) = 0;
3514.
virtual const string& getIOPointID(void) const = 0;
3515.
3516. // nmero de valores histricos almaceaados aa base de datos de 8/S
3517.
virtual void setNumValues(unsigned num) = 0;
3518. virtual unsigned getNumValues(void) const = 0;
3519. // frecuencia de monitorizacibn
3520. virtual void setPeriod(double period) = 0;
3521. virtual double getPeriod(void) const = 0;
// mtodo constructor ( entrada na base de datos de B/S)
virtual IIORTDBEntry* CreateIORTDBEntry() const = 0;
3523.
3524 . } ;
3522.
Esta interface declara mtodos para acceder aos valores que identifican o"driver" e o punto
de E1S no que a varibel vai estar asignada (7.2.1.4.1), a frecuencia de monitorizacin do
valor da varibel (7.2.1.4.2), e o nmero de valores histricos a almacenar na base de datos de
E/S da mquina virtual (7.3.1.1). Ademais declrase un mtodo constructor CreatelORTDBEntry- utilizado para crear unha entrada na base de datos de E/S que se
corresponda cos datos almacenados na declaracin.
408
GescaDataElement
Clase abstracta que implementa parte da funcionalidade comn a todas as clases utilizadas
para representar varibeis e declaracins de varibeis. En concreto esta clase declara atributos
(Figura B.2) para almacenar o identificador -atributo name-, o tipo de acceso -atributo
access- e o alcance -atributo scope- da varibel ou declaracin, e proporciona un operador
de asignacin e implementacins por defecto para os mtodos getKey, read e write herdado da
interface pdcptrSeqElem; e para os mtodos setKey, canRead, canWrite e canShare herdados
da interface IDataElement.
GescaVarDecl
Clase parametrizada utilizada para representar as declaracins das varibeis internas dos
modelos. As declaracins dos diferentes tipos de varibeis obtense por instanciacin (Figura
5.12), indicando como argumento o tipo de dato a almacenar na varibel declarada.
GescaVar
Clase parametrizada utilizada para representar as varibeis internas dos modelos. Esta clase
declara un atributo (Figura B.2) no que se almacena o valor da varibel -atributo value- e
mtodos para consultar -mtodo getValue- e modificar -mtodo setYalue- o seu valor. Os
diferentes tipos de varibeis obtense por instanciacin, indicando como argumento o tipo de
dato a almacenar.
GescaSystemVarDecl
Clase parametrizada utilizada para representar as declaracins das varibeis do proceso
utilizadas nos modelos. Esta clase declara atributos (Figura B.2) para almacenar as propiedades
da varibel: o"driver" -atributo ddriver_id- e o punto de E/S -atributo iopoint_id- no que
a varibel vai estar asignada (7.2.1.4.1), a frecuencia de monitorizacin -atributo period
do valor da varibel (7.2.1.4.2), e o nmero de valores histricos -atributo num_values- a
almacenar na base de datos de E/S da mquina viriual (7.3.1.1). As declaracins dos diferentes
tipos de varibeis obtense por instanciacin, indicando como argumento o tipo de dato a
almacenar na varibel declarada.
GescaSystemVar
Clase parametrizada utilizada para representar as varibeis do proceso utilizadas nos
modelos. Esta clase declara un atributo (Figura B.2) no que se almacena o valor da varibel
atributo value- e mtodos para consultar -mtodo getValue- e modificar -mtodo
setValue- o seu valor. Ntese que, a diferencia da clase GescaVar, o valor almacenado unha
instancia da clase parametrizada TimedValue que almacena o valor xunto coa data e hora na
que foi obtido. Os diferentes tipos de varibeis obtense por instanciacin, indicando como
argumento o tipo de dato a almacenar.
TimedValue
Clase parametrizada utilizada para representar os valores das varibeis do proceso utilizadas
nos modelos. Esta clase declara atributos (Figura B.2) para almacenar tanto o valor da varibel
-atributo value- como a data e a hora na que foi obtido -atributo time_stamp-. Os
diferentes tipos de valores obtense por instanciacin, indicando como argumento o tipo de
dato a almacenar.
Anexo C . Compilacin da DLL

xerada no compilador Grafcet
Exemplo de arquivo .mak utilizado para compilar e enlazar co Visual C++ 6.0 o cdigo
dunha DLL (6.5.1.9) xerado polo compilador Grafcet.
^
3525. #
3526.# arquivo make para compilar unha DLL que contn ua modelo Grafcet
3527. #
3528.
3529.!IF "$(CFG)" __ ""
3530.CFG=Debug
3531.!MESSAGE No configuration specified. Defaulting to Debug.
3532.!ENDIF
3533.
3534.!IF "$(CFG)" !_ "Release" && "$(CFG)" !_ "Debug"
3535.!MESSAGE
3536.!MESSAGE Possible choices for configuration are:
3537.!MESSAGE
3538.!MESSAGE "Release" (based on "Win32 (x86) Dynamic-Link Library")
3539.!MESSAGE "Debug" (based on "Win32 (x86) Dynamic-Link Library")
3540.!MESSAGE
3541.!ERROR Invalid configuration "$(CFG)" specified.
3542.!ENDIF
3543.
3544.!IF "$(DLLNAME)" __ ""
3545.!ERROR No model name "$(DLLNAME)" has been specified.
3546.!ENDIF
3547.
3548.!IF "$(SOURCEPATH)" __ ""
3549.!ERROR No source path "$(SOURCEPATH)" has been specified.
3550.!ENDIF
3551.
3552.!IF "$(SFCPPPATH)" __ ""
3553.!ERROR No SFCPP path "$(SFCPPPATH)" has been specified.
3554.!ENDIF
3555.
3556.TMPDIR=.\Compiled
3557.CPP=cl.exe
3558.MTL=midl.exe
3559.RSC=rc.exe
3560.BSC32=bscmake.exe
3561.LINK32=1ink.exe
409
Anexo C: Compilacin da DLL xerada no compilador Grafcet
410
3562.BSC32_FLAGS=/nologo /o"$(TMPDIR)\\$(DLLNAME).bsc"
3563.BSC32_SBRS= \
3564.
3565.!IF "$(CFG)" __ "Release"
3566.CPP_PROJ=/nologo /MD /W3 /Gi /GR /GX /02 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D
3567.
"_MBCS" /D "_USRDLL" /I"$(SOURCEPATH)" /I"$(SFCPPPATH)\\include"
3568.
/I"$(SFCPPPATH)\\include\\stlport" /I"$(SFCPPPATH)\\include\\commoncpp"
3569.
/Fp"$(TMPDIR)\\$(DLLNAME).pch" /YX /Fo"$(TMPDIR)\\$(DLLNAME).obj"
'
3570.
/Fd"$(TMPDIR)\\" /FD /c
3571.MTL_PROJ=/nologo /D "NDEBUG" /mktyp1ib203 /win32
3572.LINK32_FLAGS=/LIBPATH:"$(SFCPPPATH)\\Lib" stlport_vc6.lib ccppw32dll.lib
3573.
gescalib.lib gescadata.lib gescapersistence.lib gescaruntimelib.lib
3574.
gescaruntimeinfo.lib gescavmlib.lib gescaiortdb.lib gescasfcplayer.lib
3575.
/nologo /dll /incremental:no /pdb:"$(TMPDIR)\\$(DLLNAME).pdb"
3576.
/machine:I386 /nodefaultlib:"nafxcw.lib"
3577.
/out:"$(TMPDIR)\\$(DLLNAME).dll" /implib:"$(TMPDIR)\\$(DLLNAME).lib"
3578.
/pdbtype:sept
3579.!ELSEIF "$(CFG)" __ "Debug"
3580.CPP_PROJ=/nologo /MDd /W3 /Gm /Gi /GR /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D
3581.
"_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_MT" /D "_DLL" /D "_WINDLL" /D
3582.
"_AFXDLL" /I"$(SOURCEPATH)" /2"$(SFCPPPATH)\\include"
/I"$(SFCPPPATH)\\include\\stlport" /I"$(SFCPPPATH)\\include\\commoncpp"
3583.
3584.
/Fo"$(TMPDIR)\\$(DLLNAME).obj" /Fd"$(TMPDIR)\\" /FD /GZ /Zm150 /c
3585.MTL_PROJ=/nologo /D " DEBUG" /mktyp1ib203 /win32
3586.LINK32_FLAGS=/LIBPATH:"$(SFCPPPATH)\\Lib" stlport_vc6.lib ccppw32dll.lib
3587.
3588.
3589.
3590.
gescalib.lib gescadata.lib gescapersistence.lib gescaruntimelib.lib
gescaruntimeinfo.lib gescavmlib.lib gescaiortdb.lib gescasfcplayer.lib
/nologo /dll /incremental:yes /pdb:"$(TMPDIR)\\$(DLLNAME).pdb" /debug
/machine:I386 /nodefaultlib:"nafxcwd.lib"
/out:"$(TMPDIR)\\$(DLLNAME).dll" /implib:"$(TMPDIR)\\$(DLLNAME).lib"
3591.
3592.
/pdbtype:sept
3593.!ENDIF
3594.
3595..c{$(TMPDIR)}.obj::
3596.
$(CPP) @
$(CPP_PROJ) $<
3597.
3598.
3599.
3600..cpp{$(TMPDIR)}.obj::
3601 .
$ (CPP) @
$(CPP_PROJ) $<
3602.
3603.
3604.
3605..cxx{$(TMPDIR)}.obj::
3606.
$(CPP) @
$(CPP_PROJ) $<
3607.
3608.
3609.
3610..c{$(TMPDIR)}.sbr::
3611.
$(CPP) @
3612.
$(CPP_PROJ) $<
3613 .
3614.
3615..cpp{$(TMPDIR)}.sbr::
3616.
$(CPP) @
3617.
$(CPP_PROJ) $<
3618.
3619.
3620..cxx{$(TMPDIR)}.sbr::
3621.
$(CPP) @
3622.
$(CPP_PROJ) $<
3623.
3624.
3625.LINK32 OBJS="$(TMPDIR)\\$(DLLNAME).obj"
3626.SOURCE="$(TMPDIR)\\$(DLLNAME)DLL.cpp"
411
Anexo C: Compilacin da DLL xerada no compilador Grafcet
3627.ALL : "$(TMPDIR)" "$(TMPDIR)\\$(DLLNAME).dll"
3628.
3629."$(TMPDIR)" .
Cd "$(SOURCEPATH)"
3630.
3631.
3632."$(TMPDIR)\\$(DLLNAME).dll"
$(LINK32_OBJS)
$(LINK32) @$(USER_LIBS) @
3633.
$(LINK32_FLAGS) $(LINK32_OBJS)
3634.
3635.
3636.
3637."$(TMPDIR)\\$(DLLNAME).obj" :
3638. $(CPP) $(CPP_PROJ) $(SOURCE)
3639.
3640.CLEAN :
- @erase "$(TMPDIR)\\$(DLLNAME).obj"
3641.
3642.
- @erase "$(TMPDIR)\\vc60.idb"
- @if exits "$(TMPDIR)\\vc60.pdb" erase "$(TMPDIR)\\vc60.pdb"
3643.
3644.
- @erase "$(TMPDIR)\\$(DLLNAME).dll"
3645.
- @erase "$(TMPDIR)\\$(DLLNAME).exp"
-@erase "$(TMPDIR)\\$(DLLNAME).lib"
3646.
- @if exits "$(TMPDIR)\\$(DLLNAME).pdb" erase "$(TMPDIR)\\$(DLLNAME).pdb"
3647.
Anexo D . Gramtica ANTLR
Neste anexo mstrase a gramtica ANTLR [135] utilizada para xerar automaticamente un
analizador sintctico para as expresins C++ estendidas cos operadores de evento e
temporizacin, tal e como explica en (6.5.1.5.3). As regras da gramtica conteen ademais as
anotacins e accins utilizadas para construr a AST da expresin ao tempo que se realiza a sa
anlise sintctica.
3648. /*
3649. *
3650.
3651.
3652.
3653.
3654.
3655.
3656.
3657.
3658.
Gramtica C++ para ANTLR e SORCBRSR
Bxpreains C++ sen:
. especializacins de "templatesn
"casts"
conversins de tipo explcitas
operadores sizeof e typeid
funcias membro operator
funcias membro de conversia
operadores de reserva e liberacin de memoria
modificadores de Microsoft nos nomes cualificadoa
Bngadronse:
. operadores de evento: IIP EDGB e DOWN BDGI3
3659. *
3660. *
3661. */
3662.#header
3663.
3664. #include <deque>
3665. #include <string>
3666. #include <set>
3667. #include <sstream>
3668. using namespace std;
3669. #include "tokens.h"
3670. #include "AToken.h"
3671. #include "ATokenBuffer.h"
typedef ANTLRCommonToken ANTLRTOken;
3672.
#include "ASTBase.h"
3673.
#include "ATokPtr.h"
3674.
#include "AST.h"
3675.
typedef AST SORAST;
3676.
3677.
3678.
3679.// "TORSNSn SIMPL$S
3680.
3681.// ANSI C++ tokens
3682.#token TOK_AMPERSAND
3683.#token TOK_AND
3684.#token TOK_ASSIGNEQUAL
3685.#token TOK_BITWISEANDEQUAL
3686.#token TOK BITWZSEOR
413
Anexo D: Gramtica ANTLR

3687.#token
3688.#token
3689.#token
3690.#token
3691.#token
3692.#token
3693.#token
3694.#token
3695.#token
3696.#token
3697.#token
3698.#token
3699.#token
3700.#token
3701.#token
3702.#token
3703.#token
3704.#token
3705.#token
3706.#token
3707.#token
3708.#token
3709.#token
3710.#token
3711.#token
3712.#token
3713.#token
3714.#token
3715.#token
3716.#token
3717.#token
3718.#token
3719.#token
3720.#token
3721.#token
3722.#token
3723.#token
3724.#token
3725.#token
3726.#token
3727.#token
3728.#token
3729.#token
3730.#token
3731.
3732.// C++
TOK_BITWISEOREQUAL
TOK_BITWISEXOR
TOK_BITWISEXOREQUAL
TOK_COMMA
TOK COLON
TOK DIVIDE
TOK_DIVIDEEQUAL
TOK_DOT
TOK_DOTMBR
TOK_ELLIPSIS
TOK_EQUAL
TOK_GREATERTHAN
TOK_GREATERTHANOREQUALTO
TOK_LCURLY
TOK_LESSTHAN
TOK_LESSTHANOREQUALTO
TOK_LPAREN
TOK_LSQUARE
TOK_MINUS
TOK_MINUSEQUAL
TOK_MINUSMINUS
TOK_MOD
TOK_MODEQUAL
TOK_NOT
TOK_NOTEQUAL
TOK_OR
TOK_PLUS
TOK_PLUSEQUAL
TOK_PLUSPLUS
TOK_POINTERTO
TOK_POINTERTOMBR
TOK_QUESTIONMARK
TOK RCURLY
TOK_RPAREN
TOK_RSQUARE
TOK_SCOPE
TOK_SEMICOLON
TOK_SHIFTLEFT
TOK_SHIFTLEFTEQUAL
TOK_SHIFTRIGHT
TOK_SHIFTRIGHTEQUAL
TOK_STAR
TOK_TILDE
TOK TIMESEQUAL
414
11 \ ^ =11
11^11
11^_II
11 11
11 . 11
11 / 11
11/_11
11 11
n
\*n
11...11
11__11
11 ^ 11
11 ^ _ 11
11 \ { 11
11 ^ 11
11^=11
11 \ (11
11 \ [ 11
11\_11
11\__11
11\-\-11
n^n
11 ^ _ 11
11 i 11
11 i _ 11
11\I\I11
n\+n
11 \+_ 11
"\+\+"
11\->11
11\_^\*11
11 ^ 11
11 \ } 11
n\)n
11 \ ) 11
n^_n
u.n
11^^\^11
11\^\^_11
n\)\)u
11\^\^_11
11 \ * 11
11\_11
u\,t=n
exteasiona
3733.#token
TOK_UPEDGE
3734.#token
TOK_DWEDGE
3735.
3736.// ANSI C++ Keywords
"\Ox18"
"\Ox19"
3737.#token TOK_BOOLFALSE
3738.#token TOK_BOOLTRUE
3739.#token TOK_THIS
3740.
3741. // "TOKI3NS" COMPLBXOS
"false"
"true"
"this"
3742.
3743.#token
3744.#token
3745.#token
3746.#token
3747.#token
3748.
TOK_ID
TOK_OCTALINT
TOK_DECIMALINT
TOK_HEXADECIMALINT
TOK_FLOATONE
3749.#token
TOK_FLOATTWO
"[a-zA-Z_][a-zA-ZO-9_)*"
"0 [0-7] *{ [uU1L] }"
" [1-9] [0-9] *{ [uU1L) }"
"(OxÔX) [0-9a-fA-F]+{ [uU1L] }"
" ( [0-9] + . [0-9] * ^ [0-9] * . (0-9] +)
{ [eE] { [\-\+] } [0-9]+} { [fF1L] }"

"[0-9]+ [eE] { [\-\+] } [0-9]+ { [fF1L) }"
415

mode(STRINGS); more ();
3750.#token "\""
3751.#token "'"
3752.#token "\\\n"
3753. #token " [\t\ ] +"
3754.#token "\12"
3755.#token TOK_NEWLINE "\n"
mode(CHARACTERS); more O;
newline(); skip();
skip ( ) ;
skip ( ) ;
newline(); skip();
3756.#token TOK_EOF "^"

3757.
3758.// CLASBS LBXICAS AIIXILIARBS
3759.
3760.// Arranxoa de caracteres
3761.#lexclass STRINGS
3762.#token TOK_STRING "\""

mode (START);
3763. #token " \\ ( [ntvbrfa\\?' \"] ^ [0-9] + ^ ( x^X) [0-9a-fA-F] + ) "
newline(); more();
3764.#token "\\ [\n\r]"
3765.#token "-[\\ \" \n \r]+"
more ( ) ;
3766.
3767.// Coastantes de caracter
3768.#lexclass CHARACTERS
3769.#token TOK_CHARACTER ""'
3770.#token " \\ ( [ntvbrfa\\?'\"]
3771.#token "-[\\ ' \n \r]+"
3772.
3773.// Clase i nicial
mode (START);
[0-9]+ ^ (x^X)[0-9a-fA-F]+ ) "
more();
3774.#lexclass START
3775.
3776.// "Tokena" de asignacin
3777.#tokclass ASSIGN_TOKCLASS
3778. {
TOK_ASSIGNEQUAL TOK_TIMESEQUAL TOK_DIVIDEEQUAL
3779.
TOK_MODEQUAL TOK_PLUSEQUAL TOK_BITWISEXOREQUAL
3780.
TOK_MINUSEQUAL TOK_SHIFTLEFTEQUAL
3781.
TOK SHIFTRIGHTEQUAL TOK BITWISEANDEQUAL TOK BITWISEOREQUAL
3782.
3783. }
3784.
3785.// "Tokens" utilizados aas expreaina
3786.#tokclass BOOLEANUNARYOP_TOKCLASS
3787. {
3788.
TOK_NOT
3789. }
3790.
3791.#tokclass BOOLEANEVENTOP_TOKCLASS
3792. {
TOK_UPEDGE TOK_DWEDGE
3793.
3794. }
3795.
3796.#tokclass NUMERICUNARYOP_TOKCLASS
3797. {
TOK_AMPERSAND TOK_STAR TOK_PLUS TOK_MINUS
3798.
TOK_TILDE TOK_PLUSPLUS TOK_MINUSMINUS
3799.
3800. }
3801.
3802.#tokclass UNARYOP_TOKCLASS
3803. {
TOK_AMPERSAND TOK_STAR TOK_PLUS TOK_MINUS TOK_TILDE TOK_NOT
3804.
TOK_PLUSPLUS TOK_MINUSMZNUS TOK_UPEDGE TOK_DWEDGE
3805.
3806. }
3807.
3808.#tokclass ADDITZVE_TOKCLASS
3809. {
3810.
3811. }
TOK_PLUS TOK_MINUS
more U ;
more ( ) ;

3812.#tokclass EQUALITY_TOKCLASS
3813 . {
3814.
TOK_NOTEQUAL TOK_EQUAL
3815. }
3816.
3817.#tokclass MULTIPLICATIVE_TOKCLASS
3818. {
TOK_STAR TOK_DIVIDE TOK_MOD
3819.
3820. }
3821.
3822.#tokclass PM_TOKCLASS
3823. {
3824.
TOK_DOTMBR TOK_POINTERTOMBR
3825. }
3826.
3827.#tokclass RELATIONAL_TOKCLASS
3828. {
3829.
3830.
3831. }
TOK_LESSTHAN TOK_GREATERTHAN
TOK_LESSTHANOREQUALTO TOK_GREATERTHANOREQUALTO
3832.
3833.#tokclass SHIFT_TOKCLASS
3834. {
3835.
3836. }
TOK_SHIFTLEFT TOK_SHIFTRIGHT
3837.
3838.// "Tokens" literais
3839.#tokclass CONSTANTNUMBER_TOKCLASS
3840. {
TOK_OCTALINT TOK_DECIMALINT TOK_HEXADECIMALINT
3841.
TOK_FLOATONE TOK_FLOATTWO
3842.
3843. }
3844.
3845.#tokclass CONSTANTBOOL_TOKCLASS
3846. {
TOK_BOOLTRUE TOK_BOOLFALSE
3847.
3848. }
3849.
3850.// cla8ea SORC$RBR
3851.#token TOK_BOOLEANUNARYOP
3852.#token TOK_BOOLEANEVENTOP
3853.#token TOK_NUMERICUNARYOP
3854.#token TOK_POSTOP
3855.#token TOK_NUMERICEXPR
3856.#token TOK_EVENTEXPR
3857.
3858.// DBFINICIN DO ANALIZADOR SINTCTICO
3859.
3860.class CPPParser {
3861.
3862.// Gramtica
3863.
3864.sfcpp_expression :
3865. { expression } TOK_EOF!
3866. ,
3867.
3868.expression_list :
3869. expression
3870. ,
3871.
3872.expression :
3873. expr_assignment ( TOK_COMMA" expr_assignment )*
3874. ,
416
417
3875.expr_assignment :
3876. expr_conditional { ASSIGN_TOKCLASS" expr_assignment }
3877. ;
3876.
3879.expr_conditional :
expr_logical_or { TOK QUESTIONMARK" expression TOK COLON expr_conditional }
3880.
3881. ;
..
3882.
3883.expr_logical_or :
3884. expr_logical_and ( TOK OR" expr_logical_and )*
3885. ;
3886.
3887.expr_logical_and :
3888. expr_inclusive_or ( TOK_AND" expr_inclusive_or )*
3889. ;
3890.
3891.expr_inclusive_or :
3892. expr_exclusive_or ( TOK_BITWISEOR" expr_exclusive_or )*
3893. ;
3894.
3895.expr_exclusive_or :
3896. expr_and ( TOK_BITWISEXOR" expr_and )*
3897. ,
3898.
3899.expr_and :
expr_equality ( TOK_AMPERSAND" expr_equality )*
3900.
3901. ;
3902.
3903.expr_equality :
expr_relational ( EQUALITY_TOKCLASS" expr_relational )*
3904.
3905. ,
3906.
3907.expr_relational :
expr_shift ( RELATIONAL_TOKCLASS" expr_shift )*
3908.
3909. ,
3910.
3911.expr_shift :
expr_additive ( SHIFT_TOKCLASS" expr_additive )*
3912.
3913. ,
3914.
3915.expr_additive : .
expr_multiplicative ( ADDITIVE_TOKCLASS" expr_multiplicative )*
3916.
3917. ;
3918.
3919.expr_multiplicative :
3920. expr^m ( MULTIPLICATIVE_TOKCLASS" expr^m )*
3921. ,
3922.
3923. expr^m :
expr_unary ( PM_TOKCLASS" expr_unary )*
3924.
3925. ;
3926.
3927.expr_unary :
3928.
(
3929.
( exprôstfix )?.
3930. ^
tokO:BOOLEANUNARYOP_TOKCLASS" exp0:expr_unary
3931.
#0=#(#[TOK BOOLEANUNARYOP, tok0->getText()], #exp0);
3932.
3933. ^
_
tok1:BOOLEANEVENTOP_TOKCLASS" expl:expr_unary
3934.
#0=#(#[TOK_BOOLEANEVENTOP, tokl->getText()], #expi);

3935.
3936. ^
tok2:NUMERICUNARYOP_TOKCLASS" exp2:expr_unary
3937.
#0=#(#[TOK_NUMERICUNARYOP, tok2->getText()], #exp2);
3938.
3939. )
3940. ,
418
3941. exprôstfix! :
3942.
exp0:expr^rimary
3943.
#0=#exp0;
3944. (
3945.
3946.
3947.
3948.
tokO:TOK_LSQUARE expl:expression TOK_RSQUARE
#0=#(#[TOK_POSTOP, tok0->getText()], #0, #expl);
3949.
3950.
3951.
tok1:TOK_LPAREN { exp2:expression_list } TOK_RPAREN
#0=#(#[TOK_POSTOP, tokl->getText()], #0, #exp2);
3952.
3953.
3954.
3955.
tok2:TOK_DOT exp3:expr_id
#0=#(#[TOK_POSTOP, tok2->getText()], #0, #exp3);
tok3:TOK_POINTERTO exp4:expr_id
3956.
3957.
#0=#(#[TOK_POSTOP, tok3->getText()], #0, #exp4);
3958.
3959.
3960.
tok4:TOK_PLUSPLUS
#0=#(#[TOK POSTOP, tok4->getText()], #0);
3961.
3962.
3963.
3964.
3965.
3966.
3967.
3968.
3969.
3970.
3971.
3972.
3973.
tok5:TOK_MINUSMINUS
#0=#(#[TOK_POSTOP, tok5->getText()], #0);
)*
expr^rimary :
TOK_THIS
expr_id
expr_literal
3974.
TOK_LPAREN^ { expression } TOK_RPAREN
3975. ;
3976.
3977.expr_id! :
3978.
bool scope = false;
3979. {
3980.
tokO:TOK_SCOPE
3981.
3982.
#0=#[TOK_ID, tok0->getText()];
scope = true;
3983.
3984.
3985. }
3986. tok1:TOK_ID
3987.
3988.
if (!scope)
3989.
#0=#[TOK_ID, tokl->getText()];
3990.
else
3991.
strncat(((AST*)#0)->getText(), tokl->getText(), strlen(tokl->getText()));
3992.
3993.
(
3994.
tok2:TOK_SCOPE
3995.
tok3:TOK_ID
3996.
3997.
strncat(((AST*)#0)->getText(), tok2->getText(), strlen(tok2->getText()));
3998.
strncat(((AST*)#0)->getText(), tok3->getText(), strlen(tok3->getText()));
3999.
4000. )*
4001. ,
419
4002.expr_literal :
4003.
constant
4004. ^
4005.
expr_string
4006. ;
4007.
4008.constant :
'
4009.
CONSTANTNUMBER_TOKCLASS
4010. ^
4011.
TOK_CHARACTER
4012. ^
4013.
CONSTANTBOOL_TOKCLASS
4014. ;
4015.
4016.expr_string! :
4017.
tokO:TOK_STRING
4018. #0=#[tok0->getType(), tok0->getText()];

4019. (
4020.
tok1:TOK_STRING
4021.
strncat(((AST*)#0)->getText(), tokl->getText(),
4022. )*
4023. ,
4024. }
strlen(tokl->getText()));
Anexo E . Gra m tica SORCERER
Neste anexo mstranse as gramticas utilizadas para a xeracin automtica, coa aplicacin
Sorcerer [135], de analizadores/traductores das ASTs das expresins C++ estendidas cos
operadores de evento e temporizacin. A primeira gramtica serve para xerar un
analizador/traductor que substita as expresins numricas por varibeis booleanas nas
expresins con eventos complexas, para a sa posterior reduccin coa aplicacin Sidoni, tal e
como se explica en (6.5.1.5.3). A segunda gramtica xera un analizador/traductor que imprime
as ASTs modificadas na sintaxe C++.
Substitucin de expresins numricas
4025. /*
4026. *
4027. *
Gramtica C++ para SORCSRSR
Sxpresias C++ sen:
4028.
4029.
4030.
4031.
*
*
*
*
. especializacins de "templates"
. "Casts
. converaina de tipo explcitas
. operadorea atzeof e typeid
4032.
4033.
4034.
4035.
4036.
*
*
*
*
4037.
funcins membro operator
. fuacins membro de conversin
. operadorea de reserva e liberacin de memoria
. modificadores de Microsoft nos aomes cualificados
Sngadronse:
operadores de evento: IIP_SDGS e DOWN_SDGS
4038. */
4039.#header
4040.
4041. #include <deque>
4042.
#include <set>
4043.
#include <string>
4044.
#include <sstream>
4045.
using namespace std;
4046.
4047.
#include
#include
4048.
#include "ATokenBuffer.h"
"tokens.h"
"AToken.h"
4049.
typedef ANTLRCommonToken ANTLRToken;
4050.
4051.
#include
4052.
4053.
#include "AST.h"
typedef AST SORAST;
4054.
#include
4055.
"ATokPtr.h"
"CPPTreePrinter.h"
421
Anexo E: Gramtica SORCERER
422
4056.// DSFINICIN DO ANALIZADOR SINTCTICO DL ASTs
4057.
4058.class CPPTreeParser {
4059.
4060.
4061. private:
4062.
astdata_seq* trees;
4063.
unsigned expr_number;
4064.
std::string add_expression(PCCTS AST* tree, bool boolean = false);
4065.
void erase_ast(std::string name);
4066.
void reduce_expressions();
4067.
public:
4068.
void parse(SORASTBase **_root,
4069.
SORASTBase **_result,
4070.
astdata_seq& expressions,
4071.
unsigned& init_number);
4072 .
4073.
4074.// GRAMTICA
4075.
4076.// Bxpresins xerais
4077.
4079.
expr_boolean
4080.
4081.
4082.
4083.
4084.
4085.
4086.
4087.
4088.
4089.
4090.
4091.
4092.
4093.
4094.
4095.
4096.
4097.
4098.
4099.
4100.
4101.
exp0:expr_numerical
std::string expr_name = add_expression(exp0);
#sfcpp_expression=#(#[TOK NUMERICEXPR,
const cast<char*>(expr_name.c_str())],
exp0);
#( TOK COMMA sfcpp_expression sfcpp_expression
#( TOK_LPAREN sfcpp_expression TOK RPAREN )

TOK_CHARACTER
TOK_STRING
TOK_ID
TOK_THIS
4102 . // Expresins booleanas

4103.
4104.expr_boolean :
#( TOK BOOLEANUNARYOP sfcpp_expression )
4105.
4106.
4107.
4108.
4109.
4110.
4111.
4112.
4113.
4114.
4115.
4116.
4117.
4118.
4119.
#( tokO:TOK_BOOLEANEVENTOP exp0:sfcpp_expression )
PCCTS_AST* aux =#(#^(ANTLRTokenType) tok0->type(), tok0->getText()], exp0);
std::string expr_name = add_expression(aux, true);
#expr_boolean=#(#[TOK EVENTEXPR, const_cast<char*>(expr_name.c_str())], aux);
expr_boolean_binary
TOK BOOLTRUE
TOK_BOOLFALSE
423
4120.expr_boolean_binary :
#( TOK OR sfcpp_expression sfcpp_expression )
4121.
4122. ^
#( TOK_AND sfcpp_expression sfcpp_expression )
4123.
4124. ;
4125.
4126.// $xpresina numricas

4127.
4128.expr_numerical :
#( TOK_NUMERICUNARYOP sfcpp_expression )
4129.
4130. ^
expr_numerical_binary
4131.
4132. ^
#( TOK QUESTIONMARK sfcpp_expression sfcpp_expression TOK_COLON sfcpp_expression )
4133.
4134. ^
#( TOK_POSTOP sfcpp_expression {sfcpp_expression} )
4135.
4136. ^
TOK_OCTALINT
4137.
4138. ^
TOK_DECIMALINT
4139.
4140. ^
TOK_HEXADECIMALINT
4141.
4142. ^
TOK_FLOATONE
4143.
4144. ^
TOK_FLOATTWO
4145.
4146. ;
4147.
4148.expr_numerical_binary :
#( TOK ASSIGNEQUAL sfcpp_expression sfcpp_expression )
4149.
4150.
4151.
4152.
4153.
4154.
4155.
4156.
4157.
4158.
4159.
4160.
4161.
4162.
4163.
4164.
4165.
4166.
4167.
4168.
4169.
4170.
4171.
4172.
4173.
4174.
4175.
4176.
4177.
4178.
4179.
4180.
4181.
4182.
4183.
4184.
#( TOK_TIMESEQUAL sfcpp_expression sfcpp_expression )
#( TOK_DIVIDEEQUAL sfcpp_expression sfcpp_expression )
#( TOK_MODEQUAL sfcpp_expression sfcpp_expression )
#( TOK_PLUSEQUAL sfcpp_expression sfcpp_expression )
I#( TOK_BITWISEXOREQUAL sfcpp_expression sfcpp_expression )
#( TOK MINUSEQUAL sfcpp_expression sfcpp_expression )
#( TOK SHIFTLEFTEQUAL sfcpp_expression sfcpp_expression )
#( TOK_SHIFTRIGHTEQUAL sfcpp_expression sfcpp_expression )
#( TOK BITWISEANDEQUAL sfcpp_expression sfcpp_expression )
#( TOK BITWISEOREQUAL sfcpp_expression sfcpp_expression )
#( TOK_PLUS sfcpp_expression sfcpp_expression )
#( TOK MINUS sfcpp_expression sfcpp_expression )
#( TOK NOTEQUAL sfcpp_expression sfcpp_expression )
#( TOK EQUAL sfcpp_expression sfcpp_expression )
#( TOK STAR sfcpp_expression sfcpp_expression )
#( TOK DIVIDE sfcpp_expression sfcpp_expression )
#( TOK MOD sfcpp_expression sfcpp_expression )

4185.
4186.
4187.
4188.
4189.
4190.
4191.
4192.
4193.
4194.
4195.
4196.
4197. }
4198.
4199. //
424
#( TOK_LESSTHAN sfcpp_expression sfcpp_expression )
#( TOK_GREATERTHAN sfcpp_expression
sfcpp_expression )
#( TOK LESSTHANOREQUALTO sfcpp_expression sfcpp_expression
#( TOK_GREATERTHANOREQUALTO sfcpp_expression sfcpp_expression
#( TOK_SHIFTLEFT sfcpp_expression sfcpp_expression )
#( TOK SHIFTRIGHT sfcpp_expression sfcpp_expression )
MTODOS DO ANALIZADOR
4200.
4201.
4202.
4203.
std::string CPPTreeParser::add expression(PCCTS AST* tree, bool boolean)
4204.
4205.
4206.
char num[5];
itoa(expr_number++, num, 10);
ast_data data;
4207.
4208.
4209.
4210.
4211.
4212.
data.name = "sfcpp_expr";
data.name.append(num);
data.type = boolean;
data.ast = tree;
trees->push_back(data);
return data.name;
4213.
}
4214.
4215.
void CPPTreeParser::erase_ast(std::string name)
4216. {
4217.
for(astdata_iterator it = trees->begin(); it != trees->end(); ++it)
4218.
if (it->name == name)
4219.
{
4220.
trees->erase(it);
4221.
return;
4222.
}
4223.
4224.
4225.
4226.
void CPPTreeParser::reduce_expressions()
4227.
4228.
std::set<std::string> names;
// eliminar expresins numricas contidas noutras expresias numricas
4229.
for(const_astdata_iterator it = trees->begin(); it != trees->end(); ++it)
4230.
4231.
4232.
if (!it->type)
4233.
4234.
4235.
((AST*) it->ast)->find_numexpr(names);
for(std::set<std::string>::const_iterator iter = names.begin();
iter != names.end();
4236.
4237.
4238.
4239.
4240.
4241.
4242.
4243.
4244.
4245.
4246.
4247.
4248.
4249. }
++iter)
erase_ast(*iter);
names.clear();
for(it = trees->begin(); it != trees->end(); ++it)
names.insert(it->name);
++iter)
if (it->name !_ *iter)
((AST*) it->ast)->remove_expr(*iter);
425
4250.
4251.
4252.
4253.
4254.
4255.
4256.
4257.

void CPPTreeParser::parse(SORASTBase ** root,
SORASTBase **_result,
astdata_seq& expressions,
unsigned& init_number)
trees = &expressions;
expr_number = init_number;
// obter expresins
sfcpp_expression(_root, _result);
init_number = expr_number;
// reducir expresins
std::set<std::string> names;
((AST*)(*_result))->find_eventexpr(names);
++iter)
erase_ast(*iter);
reduce_expressions();
for(astdata_iterator it = trees->begin(); it != trees->end(); ++it)
((AST*)(*_result))->remove_expr(it->name);
// producir resultado
CPPTreePrinter tree^rinter;
stringstream output;
tree^rinter.dump(&it->ast, output);
it->code = output.str();
4258.
4259.
4260.
4261.
4262.
4263.
4264.
4265.
4266.
4267.
4268.
4269.
4270.
4271.
4272.
4273.
4274.
4275.
4276.
}
4277.
4278. }
4279.
Impresin ASTs na sintaxe C++

4280. /*
4281. *
4282. *
Gramtica C++ para SORCBRSR: impresin das ASTs
8xpresina C++ sen:
4283.
4284.
*
*
. especializacins de "templates"
. "casts"
4285.
4286.
4287.
*
*
*
.
.
.
4288.
. funcins membro de coaversin
4289.
4290.
4291.
*
*
*
conversina de tipo explcitas
operadorea aizeof e typeid
funcins membro operator
. operadorea de reserva e liberacin de memoria
. modificadores de Microsoft nos nomes cualificados
Sngadronse:
4292. *
. operadores de evento: IIP_8DG$ e DOWN_$DGB
4293. */
4294.#header
4295.
#include <deque>
4296.
4297.
#include <iostream>
#include <string>
4298.
4299.
#include <set>
using namespace std;
4300.
4301.
#include "tokens.h"
4302.
#include "AToken.h"
#include "ATokenBuffer.h"
4303.
typedef ANTLRCommonToken ANTLRToken;
4304.
4305.
#include "ATokPtr.h"
4306.
#include "AST.h"
4307.
typedef AST SORAST;
4308.
4309.
426
4310. // Df3FINICIN DO IMPRBSOR DB ASTs

4311.
4312.class CPPTreePrinter {
4313.
4314 .
4315. private: .
4316. ostream* out;
4317.public:
4318. void dump(SORASTBase** _root, ostream& out_stream

4319.
4320.
4321.// GRAMTICA
4322.
4323.// Bxpresins xerais
4324.
4326.
expr_boolean
4327.
4328.
4329.
4330.
4331.
4332.
4333.
4334.
4335.
4336.
4337.
4338.
4339.
4340.
4341.
4342.
4343.
4344.
4345.
4346.
4347.
4348.
4349.
4350.
4351.
4352.
4353.
4354.
4355.
4356.
4357.
expr_numerical
#(
tokO:TOK_COMMA
sfcpp_expression
(*out) tok0->getText();
sfcpp_expression
#(
tok1:TOK_LPAREN
(*out) tokl->getText();
sfcpp_expression
tok2:TOK_RPAREN
tok3:TOK_CHARACTER
tok4:TOK_STRING
tokS:TOK_ID
tok6:TOK_THIS
4360.expr_boolean :
4361.
bool expr = false;
4364.
4365.
4366.
4367.
4368.
4369.
4370.
4371.
4372.
4373.
4358. // Expreaias booleanas
4359.
4362.
4363.
#(
tokO:TOK_EVENTEXPR
expr_boolean
expr = true;
if (!expr)
cout)
427
4374.
4375.
4376.
4377.

#(
tok1:TOK_BOOLEANUNARYOP
sfcpp_expression
4378.
4379. ^
4380.
#(
4381.
4382.
4383.
tok2:TOK_BOOLEANEVENTOP
sfcpp_expression
4384.
)
4385. ^
expr_boolean_binary
4386.
4387. ^
TOK_BOOLTRUE
4388.
(*out) "(1)";
4389.
4390. ^
4391.
TOK_BOOLFALSE
(*out) "(0)";
4392.
4393. ,
4394.
4395.expr_boolean_binary :
4396.
#(
4397.
tokO:TOK_OR
sfcpp_expression
4398.
4399.
4400.
sfcpp_expression
4401.
)
4402. ^
4403.
#(
tok1:TOK_AND
4404.
sfcpp_expression
4405.
4406.
4407.
(*out) toki->getText();
sfcpp_expression
4408.
4409. ,
4410.
4411.// Bxpresins numricas
4412.
4413.expr_numerical :
bool expr = false;

4414.
4415.
#(
tokO:TOK_NUMERICEXPR
4416.
4417.
{
4418.
expr_numerical
expr = true;
4419.
}
4420.
4421.
)
4422.
if (!expr)
4423.
4424.
4425.
4426. ^
4427.
#(
tok1:TOK_NUMERZCUNARYOP
4428.
4429.
sfcpp_expression
4430.
4431.
)
4432. ^
expr_numerical_binary
4433.
4434. ^
4435.
#(
tok2:TOK_QUESTIONMARK
4436.
sfcpp_expression
4437.
4438.
sfcpp_expression
4439.

4440.
tok3:TOK_COLON
4441.
( *out) tok3->getText();
4442.
sfcpp_expression
4443.
)
4444. ^
4445.
#(
4446.
tok4:TOK_POSTOP
4447.
sfcpp_expression
4448.
4449.
char* text = tok4->getText();
4450.
( *out) text;
4451.
4452.
{sfcpp_expression}
4453.
4454.
if ( text[0] __ '[')
4455.
(*out) "]";
4456.
4457.
else if (text[0] __ '(')
(*out) ")";
4458.
4459.
)
4460. I
4461.
tok5:TOK_OCTALINT
4462.
4463. ^
4464.
tok6:TOK_DECIMALINT
4465.
4466. I
4467.
tok7:TOK_HEXADECIMALINT
4468.
4469. ^
4470.
tok8:TOK_FLOATONE
4471.
4472. ^
4473.
tok9:TOK_FLOATTWO
4474.
4475. ;
4476.
4477.expr_numerical_binary :
4478.
#(
4479.
tokO:TOK_MODEQUAL
4480.
sfcpp_expression
4481.
4482.
4483.
4484 .
4485.
4486.
4487.
sfcpp_expression
#(
tok1:TOK_ASSIGNEQUAL
sfcpp_expression
4488.
4489.
4490.
4491.
sfcpp_expression
4492 .
#(
4493.
tok2:TOK_TIMESEQUAL
4494.
4495.
4496.
sfcpp_expression
sfcpp_expression
4497.
4498 .
4499.
4500.
4501.
4502.
4503.
#(
tok3:TOK_DIVIDEEQUAL
sfcpp_expression
sfcpp_expression
4504.
428
429
4505. ^
4506.
#(
tok4:TOK_PLUSEQUAL
sfcpp_expression
4507.
4508.
4509.
4510.
sfcpp_expression
4511.
)
4512. ^
4513.
#(
4514.
tok5:TOK_BITWISEXOREQUAL
sfcpp_expression
4515.
4516.
4517.
sfcpp_expression
4518.
)
4519. I
4520.
#(
tok6:TOK_MINUSEQUAL
4521.
sfcpp_expression
4522.
sfcpp_expression
4523.
4524.
4525.
)
4526. ^
4527.
#(
tok7:TOK_SHIFTLEFTEQUAL
4528.
sfcpp_expression
4529.
sfcpp_expression
4530.
4531.
4532.
4533. ^
4534.
#(
tok8:TOK_SHIFTRIGHTEQUAL
4535.
sfcpp_expression
4536.
sfcpp_expression
4537.
4538.
4539.
4540.
4541.
4542.
4543.
4544.
4545.
4546.
4547.
4548.
4549.
4550.
4551.
4552.
4553.
4554.
4555.
4556.
4557.
4558.
4559.
4560.
4561.
4562.
4563.
4564.
#(
tok9:TOK_BITWISEANDEQUAL
sfcpp_expression
sfcpp_expression
#(
tok10:TOK_BITWISEOREQUAL
sfcpp_expression
sfcpp_expression
#(
tok11:TOK_PLUS
sfcpp_expression
(*out) tokll->getText();
sfcpp_expression
#(
tok12:TOK_MINUS
sfcpp_expression
4565.
sfcpp_expression
4566.
4567.
)
4568. ^
4569.
4570.
4571.
4572.
4573.
4574.
4575.
4576.
4577.
4578.
4579.
4580.
4581.
4582.
#(
tok13:TOK_NOTEQUAL
sfcpp_expression
sfcpp_expression
)
#(
tok14:TOK_EQUAL
sfcpp_expression
sfcpp_expression
4583.
4584.
4585.
4586.
4587.
4588.
4589.
4590.
4591.
4592.
4593.
4594.
4595.
4596.
4597.
4598.
4599.
4600.
4601.
4602.
4603.
4604.
4605.
4606.
4607.
4608.
4609.
4610.
4611.
4612.
4613.
4614.
4615.
4616.
4617.
4618.
4619.
4620.
4621.
4622.
4623.
4624.
4625.
4626.
4627.
4628.
4629.
4630.
4631.
430
#(
tok15:TOK_STAR
sfcpp_expression
sfcpp_expression
)
^
#(
tok16:TOK_DIVIDE
sfcpp_expression
sfcpp_expression
)
#(
tok17:TOK_MOD
sfcpp_expression
sfcpp_expression
)
#(
tok18:TOK_LESSTHAN
sfcpp_expression
sfcpp_expression
)
#(
tok19:TOK_GREATERTHAN
sfcpp_expression
sfcpp_expression
)
^
#(
tok20:TOK_LESSTHANOREQUALTO
sfcpp_expression
sfcpp_expression
)
#(
tok21:TOK_GREATERTHANOREQUALTO
sfcpp_expression
sfcpp_expression
)
431
4632.
4633.
4634.
4635.
4636.

#(
tok22:TOK_SHIFTLEFT
sfcpp_expression
sfcpp_expression
4637.
)
4638. ^
4639.
#(
4640.
tok23:TOK_SHIFTRIGHT
4641.
sfcpp_expression
4642.
4643.
sfcpp_expression
4644.
)
4645. ;
4646. }
4647.
4648.// MTOD03 DO IMPRBSOR
4649.
4650.
4651.
4652.
4653.
4654.
4655.
4656.
void CPPTreePrinter::dump(SORASTBase** _root, ostream& out_stream)
out = &out_stream;
sfcpp_expression(_root);
433
Anexo F: Acceso remoto mquina virtual
Anexo F . Acceso remoto

mquina virtual
Neste anexo inclense os cdigos das mensaxes, indcanse os patrns de comunicacin e

mstrase o intercambio de mensaxes utilizados para acceder aos servicios remotos da mquina
virtual (7.4.3).
F.1. Cdigos das mensaxes

A Tboa F-I mostra, clasificados por categoras, os cdigos das mensaxes (7.4.1) utilizadas
na implementacin actual dos diferentes servicios de acceso remoto da mquina virtual.
^
Carga e descarga de DLLs
Carga e descarga de tboas de E/S
Carga, descarga e execucin de modelos
Xestin de configuracins
LOAD_DLL
UNLOAD_DLL
UNLOAD ALL DLL
LOAD_SYSTEMIO
UNLOAD SYSTEMIO
LOAD_MODEL
UNLOAD_MODEL
PLAY_MODEL
NEXT_MODEL_E V OLUTION
STOP MODEL
ADD_CONF
REMOVE_CONF
S ET_CURRENT_CONFIGURATION
GET_CURRENT_CONFIGURATION
GET_CONFIGURATION_INFO
ACTIVATE
DEACTIVATE
Consulta da estuctura de mdulos da mquina virtual
GET_VM_INFO
GET_MODULE INFO
Consulta da informacin de configuracin dos "drivers" de E/S
GET DEVICE 1NF0
Desconexin e finalizacin da execucin da mquina virtual
DISCONNECT
SHUTDOWN
Tboa F-I. Cdigos das mensaxes dos servicios de acceso remoto da mquina virtual.
434
No resto deste anexo descrbense os intercambios de mensaxes de cada servicio e indcase o

patrn de comunicacins (7.4.2) utilizado para cada un.
F.2. Carga e descarga de DLLs

En todos os srvicios desta categora utilzase unha orde simple sen resposta (patrn 1). (J
intercambio de mensaxes en cada caso concreto o seguinte:
F.2.1. Carga dunha DLL

Na mquina virtual poden almacenarse simultaneamente mltiples DLLs, polo que ademais
de indicarse a localizacin da DLL, proporcinase tamn como parmetro desta orde un valor
alfanumrico nico que ser utilizado para identificar a DLL.
^ LOAD_DLL, 0, 2, dll name, dllâth
a OK!
F.2.2. Descarga dunha DLL

b IJNLOAD_DLL, 0, l, dll name
a OK!
F.2.3. Descarga de todas as DLLs

b UNLOAD_ALL_DLL, 0, 0
a OK!
F.3. Carga e descarga de tboas de E/S

En todos os servicios desta categora utilzase unha orde simple sen resposta (patrn 1). O
F.3.1. Carga dunha tboa de E/S

A versin actual da mquina virtual non permite cargar mis dunha tboa de E/S
simultaneamente na memoria, polo que unicamente se pasa como parmetro da orde o
directorio no que est localizada a tboa.
^ LOAD_SYSTEMIO, 0, 1, io_tableâth
a OK!
F.3.2. Descarga dunha tboa de E/S

b LJNLOAD SYSTEMIO, 0, 0
a OK!
F.4. Carga, descarga e execucin de modelos

En todos os servicios desta categora utilzase para as comunicacins unha orde simple sen
resposta (patrn 1) excepto na continuacin da execucin dun modelo, no que se recibe unha
435
Anexo F: Acceso remoto mquina virlual
resposta fonmada por mltiples mensaxes (patrn 2) que conteen a informacin utilizada para
a depuracin da execucin do modelo. O intercambio de mensaxes en cada caso concreto o
seguinte:
F.4.1. Carga dun modelo

^ LOAD MODEL, 0, 2, module name, model name
a OK! .
F.4.2. Descarga dun modelo

^ LTNLOAD MODEL, 0, 2, module name, model name
a OK!
F.4.3. Inicio da execucin dun modelo

O terceiro parmetro desta orde contn a informacin que permite configurar o inicio da
execucin do modelo. Na versin actual este parmetro utilizado para indicar dous tipos de
opcins:
1. As relacionadas coa configuracin do intrprete Grafcet (8.3.2): ^Cmo son considerados
os eventos externos no tempo interno?. Ôs eventos internos son considerados na seguinte
evolucin interna?. ^Permtese a utilizacin de accins internas?. Ôs temporizadores
utilizan unha semntica redisparbel (8.6.2)?
2. A activacin ou non do modo de depuracin.
^ PLAY_MODEL, 0, 3, module_name, model name, options
a OK!
F.4.4. Detencin da execucin dun modelo

^ STOP_MODEL, 0, 2, module_name, model name
a OK!
F.4.5. Continuacin da execucin dun modelo

Na execucin dos modelos en modo depuracin, despois de cada evolucin, a mquina
virtual enva a informacin sobre a situacin e os valores das varibeis do modelo. No caso
dos modelos Grafcet a situacin envase nunha mensaxe que contn os identificadores
alfanumricos das etapas activas, e os valores das varibeis envanse en formato binario
dividido en varias secuencias que o receptor ten que concatenar e interpretar.
b NEXT MODEL EVOLUTION, 0, 2, module name, model name
a OK, 1, 2, module name, model name
a OK, 1, situation_size, active step_l, active_step_2, ... , active step_N
a OK, 1, model_info_size, model info_l, mode_info_2, ... ,model info_N
a OK!
436
F.5. Xestin de configuracins.

No servicio para engadir unha configuracin utilzase unha orde mltiple sen resposta
(patrn 3), nos servicios de consulta unha orde simple con resposta (patrn 2), e en todos os
demais unha orde simple sen resposta (patrn 1). O intercambio de mensaxes en cada caso
concreto o seguinte:
^
F.5.1. Engadir unha configuracin

A configuracin est formada por un conxunto de mdulos agrupados en categoras dacordo
ao seu tipo. O cliente enva das ordes por cada categora, a primeira contn o nome da
categora e o nmero mximo de mdulos permitidos nela; e o segundo a lista de mdulos da
categora.
^ ADD_CONF, l, 2, module_name, configuration_name
a OK!
// Repetir para cada categora da configuracin
b ADD_CONF, modules_max_size, 1, category_name
a OK!
^ ADD_CONF, 1, modules_size, module name_l, ... , module_name N
a OK!
b ADD_CONF, 0, 0
a OK!
F.5.2. Eliminar unha configuracin

^ REMOVE_CONF, 0, 2, module_name, configuration_name
a OK!
F.5.3. Activar unha configuracin

b SET CURRENT_CONFIGURATION, 0, 2, module name, configuration_name
a OK!
F.5.4. Consultar a configuracin activa

b GET CURRENT CONFIGURATION, 0, 1, module name
a OK, l, 1, configuration_name
a OK, modules_max_size, l, category_name
a OK, 1, modules_size, module name 1, ... , module name N
a OK!
437
F.5.5. Consultar as configuracins dispobeis

^ GET_CONFIGURATION_INFO, 0, 1, module name
// Repetir para cada configuracin
a OK, 1, 1, configuration_name
a OK, modules_max_size, 1, category_name
a OK, 1, modules_size, module_name_l, ... , module name N
a OK!
F.5.6. Activar un mdulo nunha configuracin

Activar un mdulo na configuracin dun mdulo da mquina virtual. Os parmetros desta
mensaxe son o nome do mdulo da mquina virtual, o nome da configuracin dese mdulo que
vai ser modificada, e o tipo e o nome do mdulo a activar.
^ ACTIVATE, 0, 4, module_name, configuration_name, type_name, module name
a OK!
F.5.7. Desactivar un mdulo nunha configuracin

^ DEACTIVATE, 0, 4, module name, configuration_name, type_name, module name
a OK!
F.6. Consulta da estructura de mdulos da mquina virtual.

En todos os servicios desta categora utilzase unha orde simple con resposta (patrn 2). O
F.6.1. Consultar a estructura da mquina virtual

Este servicio devolve informacin sobre a estructura de mdulos que forma a mquina
virtual. Para cada mdulo M(includa a propia mquina) recbese unha mensaxe de resposta
contendo o nome de M, o nome do mdulo utilizado como almacn dos mdulos cos que se
forma a estructura lxica de M, e a lista de mdulos agregados que forman a estructura de M no
momento de executar o servicio.
^ GET_VM_INFO, 0, 0
a OK, 1, 1, vmachine name
// Repetir para cada mdulo
a OK, 1, parts_size+2, module name, module store name, part_1, ... , part_N
a OK!
F.6.2. Consultar os mdulos dispobeis nun almacn de mdulos

Este servicio devolve para cada categora dos mdulos almacenados no almacn indicado
como parmetro da orde, das mensaxes: a primeira co nome da categora e, a segunda, coa
438
lista de mdulos desa categora presentes no almacn e o nome da DLL dende a que se cargou
cada un deles na memoria da mquina virtual.
b GET MODULE_INFO, 0, 1, module name
// Repetir para cada tipo de mdulo
a OK, 1, l, type_name
"
a OK, 1, modules_size*2, module 1, dll 1, ... , module N, dll N
a OK^
F.7. Consulta da informacin de configuracin dos "drivers" de E/S

En todos os servicios desta categora utilzase unha orde simple con resposta (patrn 2). O
intercambio de mensaxes o seguinte:
F.7.1. Consulta da informacin de configuracin dun "driver" de E/S
Na versin actual unicamente se enva a informacin da estructura do dispositivo e non se
inclen as caractersticas, valores e condicins de validez.
^ GET DEVICE_INFO, 0, 1, driver name
a OK, num levels, 1, device_name
// Obter informacin do nivel principal
a OK, 1, 4, main_level name, main_level type, main_level order, subsystems_size
// Repetir para cada subsistema
a OK, num_levels, 1
// Repetir para cada nivel do subsistema
a OK, 1, 4, level name, level type, level_order, subsystems_size
// Repetir recursivamente para cada subsistema
a OK!
F.8. Desconexin e finalizacin da execucin da mquina virtual

En todos os servicios desta categora utilzase unha orde simple sen resposta (patrn 1). O
F.8.1. Desconexin do cliente

A versin actual da mquina virtual non permite mis dunha conexin simultnea.
b DISCONNECT, 0, 0
a OK!
F.8.2. Apagado da mquina virtual

b SHLTTDOWN, 0, 0
a OK!
B ibliografa
AFCET, Association Franaise des Sciences et Technologies de 1'Information et des

Systmes, Groupe Systmes Logiques. Pour une reprsentation normalise du cahier de
charges dn automatisme logique. In: Automatique et Informatique Industrielle, 61, pp:
27-32, 62, pp: 36-40, 1977.
[2] AFCET, Association Franaise des Sciences et Technologies de 1'Information et des
Systmes, Groupe Systmes Logiques. Interprtations algbriques et algorithmiques et
temporisations. In: Le Nouvel Automatisme, 1983.
[3] Agha, G. Actors: a model of concurrent computation in distributed systems. Cambridge,
MA: the MIT Press, 1986.
[4] AMICE. CIMOSA: Open systems architecture for CIM, 2nd version, Springer-Verlag,
Berlin, 1993.
[5] Anderson, E. Bai, Z. Bischof, C. Demmel, J. Dongarra, J. Du Croz, J. Greenbaum, A.
Hammarling, S. McKenney, A. Ostrouchov, S. and Sorensen, D. LAPACK Users' Guide,
Release 1.0. SIAM, Philadelphia, 1992.
[6] Andr, C. & Peraldi, M.A. Grafcet et langages synchrones. In: Proceedings of the
Grafcet'92 conference, pp. 90-100, Paris, France, 1992.
[7] Andr, C. & Gaff, D. Proving properties of Grafcet with synchronous tools. In:
Proceedings of IMACS/IEEE CESA'96 Multiconference, pp: 777-782, Lille, France,
1996.
[8] Antsaklis, P., Koutsoukos, X. & Zaytoon, J. On hybrid control of complex systems: a
survey. In: 3rd International Conference ADMP'98, Automation of Mixed Processes,
Dynamic Hybrid Systems, pp: 1-8, Reims, France, 1998.
[9] Arzn, K. Grafcet for intelligent supervisory control applications. In: Automatica, 30:10,
1994.
[ 10] Arzn, K. Graphchart, a graphical language for sequential supervisory control. In: Proc.
of IFAC World Congress, pp. 407-412, San Francisco, 1996.
[ 11 ] Austern, M. Generic Programming and the STL. Addison-Wesley, 1998. ISBN 0-201
30956-4.
[12] Azzopardi D, Holding D J and Genovese G, Object-Oriented Petri Net Synthesis for
Modelling a Semiconductor Testing Plant. In: Proceedings of IMACS/IEEE CESA'96
Multiconference, Symposium on Discrete Events and Manufacturing Systems, Lille,
France, pp: 374-379, 1996.
[ 1]
439
Bibliografia
440
[13] Aygalinc, P. & Denat, J.P. Validation of functional Grafcet models and performance
evaluation of the associated system using Petri Nets. In: Automatic Control Production
Systems, 27, pp: 81-93. 1993.
[ 14] Babb, M. IEC 1131-3 seeks the attention of U.S. engineers. In: Control Engineering
Magazine, February, 1997.
[15] Baracos, Paul. Automation Engineering in North America. In: Proc. of 2"d Int. Conf. on
Industrial Automation, pp: 3-8, Nancy, France, 1995.
[ 16] Baracos, Paul. Grafcet: a North American perspective. In: Proc. of 9th IFAC Symposium
on Information Control in Manufacturing, pp: 41-46, Nancy-Metz, France, 1998. Elsevier
Science Ltd. ISBN: 0-08-042928-9.
[17] Barker, H.A., Chen, M., Grant, P.W., Jobling, C.P. & Townsend, P. Open Architecture
for Computer-Aided Control Engineering. In: IEEE Control Systems Magazine, 13(2),
pp: 17-27, 1993.
[ 18] Bass, J.M., Schooling, S. & Turnbull, G. Process Control Systems Integration. In:
Preprints of 8th IFAC symposium on Computer Aided Control Systems Design, Saldford,
UK, 2000.
[ 19] Bauer, N. and Engell, S. A comparison of Sequential Function Charts and Statecharts
and an approach towards integration. In: Proc. 2nd Int. Workshop on Integration of
Specification Techniques for Applications in Engineering, pp: 58-69, Grenoble, France,
2002.
[20] Benner, P., Mehrmann, V., Sima, V., Van Huffel, S. and A. Varga. SLICOT - A
Subroutine Library in Systems and Control Theory, NICONET Report 97-3, June 1997.
[21 ] Benveniste, A. & Berry, G. The synchronous approach to reactive and real-time systems.
In: Proc. of the IEEE, 79(9), pp: 1270-1282, 1991.
[22] Benveniste, A., LeGuernic, P. and Jacquemot, Ch. Synchronous programming with events
and relations: the SIGNAL language and its semantics. Science of Computer
Programming, 16:103-149, 1991.
[23] Bernardi, S., Donatelli, S. & Merseguer, J. From UML Sequence Diagrams and
Statecharts to analysable Petri Net models. In: Prc. of 3rd Int. Workshop on Soflware
and Performance, pp: 35-45, Rome, Italy, 2002. ISBN:1-58113-563-7.
[24] Berry G. and Gonthier, G. The ESTEREL synchronous language: design, semantics, and
implementation. In: Science of Computer Programming, 19(2), pp: 87-152, 1992.
[25) Bierel, E., Douchin, O. & Lhoste, P. Grafcet: from theory to implementation. In:
Automatique, Productique et Informatique Industrielle, 31(3), pp: 543-559, 1997.
[26] Bilqees, A. Computing Environments for Control Engineering. PhD. University of
Cambridge, 1996.
[27] Boissier, R., Dima, B., Razafindramary, D. and Soriano, T. Hybrid systems modelling
and validating using Statecharts and Grafcet. In: Proc. of the IFAC Int. Workshop on
Real Time Programming, pp: 73-9, 1994.
[28] Booch, G. Anlisis y diseo orientado a objetos con aplicaciones. 28 ed. AddisonWesley. 1994. ISBN: 0-201-60122-2.
[29] Booch, G., Rumbaugh, J. & Jacobson, I. EI lenguaje unificado de modelado. Ed.
Addison-Wesley Iberoamericana, 1999. ISBN: 84-7829-028-1.
441
Bibliografia
[30] Bouteille N, Brard P, Colombari G, Cotaina N& Richet D. Le Grafcet. 28 ed. Cpadus
ditions, 1995. ISBN: 2-85428-380-5.
[31 ] Brendel, W. & Tiegelkamp, M. Uniform PLC programming in accordance with IEC
61131-3. Infoteam Soflware GmbH, Bubenreuth, Germany.
[32] Buck, J. T. Ha, S. Lee, E. A. and Messerschmitt, D. G. Ptolemy: A Framework for
Simulating and Prototyping Heterogeneous Systems. In: Int. Journal of Computer
Simulation, special issue on Simulation Software Development, 4, pp: 155-182, April,
1994.
[33] Cassez, Franck. Formal semantics for reactive Grafcet. In: Automatique, Productique et
Informatique Industrielle, 31(3), pp: 581-603, 1997.
[34] CEN. ENV 40 003: Computer-Integrated Manufacturing - Systems Architecture Framework for Enterprise Modelling, CEN/CENELEC, Brussels, 1990.
[35] Chacn E, Moreno W and Hennet J C, Towards an Implementation of Hierarchical
Hybrid Control Systems for the Integrated Operation of Industrial Complexes. In: Proc.
of IMACS/IEEE CESA'96 Multiconference, Symposium on Discrete Events and
Manufacturing Systems, pp: 396-401, Lille, France, 1996.
[36] Chalmeta, R. Reference Architecture for Enterprise Integration. PhD. Universidad
Politcnica de Valencia.
[37] Chapulart, V., Giaconne, T., Monneret, G., Pereyrol, F., Prunet, F. & Simottel, D. A
structured model for specification of Discrete Event Systems: the ACSY model. In:
Automatic Control Production Systems, 27, pp: 65-80. 1993.
[38] Chapulart, V., Larnac, M. 8i Dray, G. Analysis and formal verification of Grafcet using
interpreted sequential machine. In: Proc. of IMACS-IEEE CESA'96 Multiconference,
Symposium on Discrete Events and Manufacturing Systems, pp: 758-764, Lille, France,
1996.
[39] Char, B.W., Geddes, K.O., Gentleman, W.M. and Gonnet, G.H. The design of Maple: A
compact, portable, and powerful computer algebra system. In: Lecture Notes in
Computer Science, 162, pp. 101-115, Springer-Verlag, Berlin, 1983.
[40] Charbonnier, F., Alla, H. & David, R. The supervised control of discrete event dynamic
systems: a new approach. In: Proc. of 34th Conf. on Decision and Control, New Orleans,
USA, 1995.
[41 ] Chen, P. The Entity-Relationship model: toward a unified view of data. In: ACM
Transactions on Database Systems, 1(1), pp: 9-36, 1976.
[42] Crater, K.C. When technology standards become counterproductive. In: Control
[43]
[44]
[45]
[46]
Engineering Magazine, 1992.

Dahl, O.J. & Nygaard, K. SIMULA - An Algol Based Simulation Language. In: Comm.
ACM, 9(9), pp. 671-678, 1966.
Damodar,Y.G. & Carol, L.S. The just-in-time philosophy: a literature review. In: Int.
Journal of Production Research, 29(4), pp: 657-76, 1991.
David R. Grafcet: a powerful tool for specification of logic controllers. In: IEEE
transaction on control systems technology, 3, pp: 253-368, 1995.
David, R. & Alla, H. Du Grafcet aux Rseaux de Petri. 2a ed. Ed. Hermes, Paris, 1997.
ISBN: 2-86601-325-5.
Bibliografia
442
[47] Delatour, J. & Lamotte, F. ArgoPN. a CASE tool merging UML and Petri Nets. In: Proc.
of 1 st Int. Workshop on Validation and Verification of soflware for Enterprise
Information Systems, pp: 94-102. ISBN: 972-98816-2-6.
[48] De Loor, P. Du TTM/RTTL pour la validation des systmes commands par Grafcet. PhD
Thesis, University of Reims, France, 1996.
[49] Dima, Bruno & Manka, Marc. Graf7-C version 2.1 DOS. Manuel de l'utilisateur, tutoriel
et exemples Grafcet. Ministre de 1'ducation du Quebec, 1995. ISBN: 2-89740-009-1.
[50] Dongarra, J.J., Moler, C.B., Bunch J.R. & Stewart, G.W. LINPACK Users' Guide. 1979.
[51 ] Douglass, B. Real-time design patterns: robust scalable architecture for real-time
systems. Addison-Wesley, 2003. ISBN: 0-201-69956-7.

[52] Douglass, B. Doing hard time: developing real-time systems with UML, objects,
frameworks and patterns. Addison-Wesley, 1999. ISBN: 0-201-49837-5.
[53] Douglass, B. Real-time design patterns: robust scalable architecture for real-time
systems. Addison-Wesley, 2003. ISBN: 0-201-69956-7.
[54] Doumeingts, G., Vallespir, B., Zanettin, M. & Chen, D. GIM, GRAI integrated
methodology - A methodology for designing CIM systems, version 1.0. Unnumbered
report, LAP/GRAI, University of Bourdeaux I, France, 1992.
[55] Dumry, J.J., Faure, J.M., Frachet, J.P., Lamprire, S. & Louni, F. A tool for the
structured modelling of discrete events systems behaviour: the hypergrafcet. In: Proc. of
IMACS-IEEE CESA'96 Multiconference; Symposium on Discrete Events and
[56] Dye, R. Labview : a visual data flow programming language and environment. Master's
thesis, Dept. of Elec. and Comp. Eng. University of Texas at Austin, 1989.
[57] Elmstron, R., Lintulampi, R. & Pezz, M. Giving semantics to SA/RT by means of high
level timed Petri Nets. In: Real-Time Systems, 5, pp: 249-271.
[58] Erickson, K.T. & Hedrick, J.L. Plantwide process control. Ed. John Wiley & Sons, 1999.
ISBN: 0-471-17835-7.
[59] Faure, J.M., ôuffin, F., Lamprire-Couffin, S. SAGITAL, un environment d'aide la
conception de grafcets bas sur des mta-modles. In: Proc. of Modeling of Reactive
Systems, pp: 183-192, 1999.
[60] Ferreiro, R. Nociones sobre aplicacin de PLC's al control de procesos industriales.
Universidade da Corua, Servicio de publi acins, 1995. ISBN: 84-88301-12-X.
[61 ] Ferreiro, R., Pardo, X. C., Vidal, J., Coego, J. Adaptive SFC based supervision algorithm
on flexible production systems. En: Proc. of IFAC Workshop on Control of Industrial
Systems, pp: 445-450, Belfort, Francia, 1997. ISBN: 0-08-042907-6.
[62] Ferreiro, R., Vidal, J. Pardo, X. C. SFC Based FDI with Parity Equations on Hybrid
Systems. En: Proc. of 2nd IMACS Int. Multiconf. on Computational Engineering in
Systems Applications. Symposium on Industrial and Manufacturing Systems, pp: 613
617, Nabeul-Hammamet, Tunez, 1998. ISBN: 2-9512309-0-7.
[63] Ferreiro, R., Pardo, X. C., Vidal, J. Hybrid FDI on Chemical Plants. En: Proc. of
Workshop on On-Line Fault Detection and Supervision in the Chemical Process
Industries, pp: 377-381, Solaize-Lyon, Francia, 1998. ISBN: 0-08-043233-6.
443
Bibliografia
[64] Frachet, J.P. & Colombari, G. Elements for a semantics of the time in Grafcet and
dynamic systems using non-standard analysis. In: Automatique, Productique et
Informatique Industrielle, 27(1), pp: 107-125, 1993.
[65] Frachet, J.P. & Lamperiere, S. & Faure, J.M. The hyperfinite signal: application to the
modelling of discrete event systems behaviour. In: Proc. of IMACS-IEEE^ CESA'96
Multiconference, Syrnposium on Discrete Events and Manufacturin Systems, pp. 584
589, Lille, 1996.
[66] Frensel, G. & Bruijin, P.M. From Grafcet to Hybrid Automata. In: Proc. of 9th IFAC
Symposium on Information Control in Manufacturing, pp: 47-52, Nancy-Metz, France,
1998. Ed. Elsevier Science Ltd. ISBN: 0-08-042928-9.
[67] Gamma, E., Helm, R., Johnson, R. & Vlissides, J. Design patterns: elements of reusable
object-oriented software, Addison-Wesley, 1995. ISBN: 0-20-163361-2.
[68] Gensym, G2 Reference Manual, version 4.0. Gensym Coorporation, 125 Cambridge Park
Drive, Cambridge, MA 02140, USA.
[69] Grabow, B.S., Boyle, J.M., Dongarra J.J. & Moler, C. B. editors. Matrix Eigensystem
Routines - EISPACK Guide Extension. In: Lecture Notes in Computer Science, 51,
Springer Verlag, New York, 1977.
[70] Gressier-Soudan, E., Epivent, M., Laurent, A., Boissier, R., Razafindramary, D. &
Raddadi, M. Component oriented control architecture: the COCA project. In:
Microprocessors and Microsystems, 23(2), pp: 95-102, 1999. ISSN: 0141-9331.
[71 ] Grbel, G., Joos, H., Otter, M. & Finsterwalder, R. The ANDECS design environment for
control engineering. In: Prepr. of 12`h IFAC World Congress, Sydney, Australia, 1993.
[72] Griibel, G., Varga, A., Boom, A. & Geurts, A.J. Towards a coordinated development of
numerical CACSD software: the RASP/SLICOT compatibility concept. In: Proc. of IEEE
Int. Symposium on Computer Aided Control System Design, pp. 499-504, Tucson, 1994.
[73] Guguen, H. & Bouteille, N. Extensions of Grafcet to structure behavioural
specifications. In: Control Engineering Practice, 9, pp: 743-756, 2001.
[74] Guillaume, M., Grave, J.M. & Chlique, P. Formalization of edges for the Grafcet state
machine. In: Proc. of IMACS-IEEE CESA'96 Multiconference, Symposium on Discrete
Events and Manufacturing Systems, pp. 579-583, Lille, France, 1996.
[75] Guillemaud, L., Grave, J.M. & Guguen, H. Requirements for extending Grafcet to
hybrid specifications, In: Proc. 3rd Int. Conf. Automation of Mixed Processes, pp. 209
215, Reims, France, 1998.
[76] Guillemaud, L. & Guguen, H. Extending Grafcet for the specification of control of
hybrid sytems, In: Proc. Int. Conf. Systems, Man and Cybernetics, 1, pp. 171-175, Tokyo,
Japan, 1999.
[77] Halepota, A.S., Grant, P.W., & Jobling, C.P. Design is a document. In: Proc. of IEE
Conference Control, pp: 1-5, Swansea, UK, 1998.
[78] Harel, D. StateCharts: a visual formalism for complex systems. In: Science of Computer
Programming, 8, 1987.
[79] Hassapis, G., Kotini, I. & Doulgeri, Z. Validation of a SFC software specification by
using hybrid automata. In: Proc. of 9th IFAC Symposium on Information Control in
Manufacturing, pp:65-70, Nancy-Metz, France, 1998. Elsevier Science Ltd. ISBN: 0-08
042928-9.
Bibliografia
444
[80] Hooman, J., Ramesh, S., De Roever, W. A compositional axiomatization of statecharts.

In: Theoretical Computer Science, 101, pp: 289-335, 1992.
^
[81 ] ICAM. US Air Force Integrated Computer Aided Manufacturing Architecture, Part II,
Volume IV-Functional Modeling Manual (IDEFO). Air Force Materials Laboratory,
Wright-Patterson AFB, Ohio 45433, AFWAL-tr-81-4023, 1981.
[82] Ingalls, D. H. The Smalltalk-76 programming system: Design and implementation. In:
Proc. Sth ACM Symposium on Principles of Programming Languages, pp: 9-16, 1978.
[83] International Electrotechnical Commission. Graphical symbols for diagrams - Part 12:
Binary logic elements. IEC Standard 60617-12, 1981.

[84] International Electrotechnic Commision. Preparation of Function Charts for Control
Systems. Function Chart Grafcet. Publicacin 60848. Decembro, 1988. Genve, Suisse.
[85] International Electrotechnical Commission. Grafcet Specification Language for
Sequential Function Charts. IEC Standard 60848, Ed. 2, 2001. Genve, Suisse.
[86] International Electrotechnical Commission. Programmable Controllers. Part 3:
Programming Languages. Publicacin 61131-03. 1993. Genve, Suisse.
[87] Instrument Society of America, ISA-588.01, Batch Control, Part 1: Models and
Terminology, Research Triangle Park, NC, 1995.
[88] International Organization for Standardization, ISO/IEC 14882. Information Technology
- Programming Languages - C++, 1998.
[89] International Organization for Standardization, ISO 9506-1. Industrial automation
systems - Manufacturing Message Specification - Part 1: Service definition, 1990.
[90] James, J.R. A survey of knowledge-based systems for computer-aided control system
design. In: Proc. of American Control Conference, Minneapolis, 1987.
[91 ] Jensen, K. & Rozenberg, G. High-level Petri Nets. Springer Verlag, 1991.
[92] Jobling, C. P. User interface issues and the role of Artificial Intelligence in ComputerAided Control Engineering. In: Lecture Notes of ERASMUS intensive course on
Application of Artificial Intelligence in Process Control, pp: 303-338. Ed: Boullart, L.
Krijgsman, A. and Vingerhoeds, R. A. Pergamon Press, Exeter, England, 1992. ISBN: 0
08-042017-6.
[93] Jobling, C.P. & Varsamidis, T. The state of the art in CACSD a decade after ECSTASY.
In: Proc. of 8th IFAC symposium on Computer Aided Control Systems Design, Saldford,
UK, 2000.
[94] Johnson, C. & Arzn, K. Graphchart and its relations to Grafcet and Petri Nets. In:
Preprints of 9th symposium on Information Control in Manufacturing, vol. II, pp: 53-58,
Nancy-Metz, 1998.
[95] Johnson, C. & Arzn, K. Batch recipe structuring using high-level Grafchart. In:
Preprints of 13th IFAC World Congress, San Francisco, 1996.
[96] Jones, A.H. A General Methodology for Converting Petri Nets into Ladder Logic: The
TPLL Methodology. In: Journal of Intelligent Manufacturing, 5, pp. 103-120, 1996.
[97] Kheir, N.A., Astrm, K.J., Auslander, D., Cheok, K.C., Franklin, G.F., Masten, M. &
Rabins, M. Control Systems Engineering Education, In: Automatica, 32, pp: 147-166,
1996.
445
Bibliografia
[98] Klein, S., Frey, G., & Litz, L. A Petri net based approach to the development of correct
logic controllers. In: Proceedings of the 2nd International Workshop on Integration of
Specification Techniques for Applications in Engineering, Grenoble, France, 2002.
[99] Kohn, W., James, J., Nerode, A., Harbison, K. & Agrawala, A. A hybrid systems
approach to computer-aided control engineering. In: IEEE Control Systems, :15(2), pp:
14-25, 1995.
[100] Kouthon, T., Decotignie, J.D. & Koppenhoefer, S. On distribution of Grafcet software.
In: Proc. of IMACS-IEEE CESA'96 Multiconference, Symposium on Discrete Events
and Manufacturing Systems, pp. 498-506, Lille, France, 1996.
[ 101 ] Kristensen, C.H., Andersen, J.H. & Skou, A. Specification and automated verification of
real-time behaviour -a case study. In: Proc. of 3rd IFAC/IFIP Workshop on
Arrchitectures and Algorithms for Real-Time Control, pp: 613-628, Ostend, Belgium,
1995.
[ 102] Kuikka, S., Tommila, T. & Venta, O. Distributed Batch Process Management
Framework based on Design Patterns and Software Components. In: Proc. of 14th
triennial IFAC World Congress, vol. Q, pp: 263-268, Beijing, China, 1999.
[103] Lessage, J.J. & Roussel, J.M. Hierarchical approach to Grafcet using forcing order. In:
Automatique, Productique et Informatique Industrielle, 27(1), pp: 25-38, 1993.
[ 104] Lewin, D. Design of Logic Systems. Van Nostrand Reinhold, 1985.
[ 105] Lewis, R. S. Programming industrial control systems using IEC 61131-3. IEE Control
Engineering series, The Institution of Electrical Engineers, Exeter, England, 1995. ISBN:
0-85296-827-2.
[106] Lhoste, P., Faure, J.M., Lessage, J.J. & Zaytoon, J. Comportement temporel du Grafcet.
In: Automatique, Productique et Informatique Industrielle, 31(4), pp: 695-711, 1997.
[ 107] Little, J.N. Emami-Naeini, A. & Bangert, S.N. CTRL-C and Matrix Environments for the
Computer-Aided Design of Control Systems. Jamshidi M. and Herget C. J., editors,
Computer-Aided Control Systems Engineering, Elsevier Science Publishers, Amsterdam,
1985.
[108] Lobato, V. & Fernndez, D. Fabricacin automtica de bridas. E.T.S. de Ingenieros
Industriales e Ingenieros Informticos de Gijn, Universidad de Oviedo, 1999.
[ 109] Machado, R.J. & Fernandes, J.M., A Petri Net Meta-Model to develop Software
Components for Embedded Systems. In: Proc. of 2nd Int. Conf. on Application of
Concurrency to System Design, pp: 113, Newcastle upon Tyne, UK, 2001.
[110] Maciejowski, J.M. & MacFarlane, A.G. CLADP: The Cambridge Linear Analysis and
Design Programs. Control Systems Magazine, 1982.
[ 111 ] Maffezoni, C., Ferrarini, L. and Carpanzano, E. Object oriented models for advanced
automation engineering. In: Preprints of 9th Symp. on Information Control in
Manufacturing, vol. I, pp: 21-31, Nancy-Metz, France, 1998.
[112] Maffezzoni, C. and Girelli, R. Moses: Modular Modeling of Physical Systems in an
Object-Oriented Database. In: Mathematics and Computer Modelling of Dynamical
Systems, 4, pp. 121-147, 1998.
[113] Mandel, L. and Cengarle, M.V. On the expressive power of OCL. In: Proc. of World
Congress on Formal Methods in the Development of Computing Systems, volume 1708
of LNCS, pp: 854-874, Toulouse, France, 1999.
Bibliografia
446
[114] Marc, L. & Le Parc, P. Modlisation de la smantique du Grafcet 1'aide de processes

synchrones. In: Proc. of Grafcet'92 conference, pp: 101-110, Paris, France, 1992.
[115] Marc, L. & Le Parc, P. Defining the semantics of languages for programmable
controllers with synchronous processes. In: Control Engineering Practice, 1, pp: 79-84,
1993.
[ 116] Marc, L., L'Her, D. & Le Parc, P. Modelling and verification of temporized Grafcet. In:
Proc. of IMACS/IEEE CESA'96 Multiconference, Symposium on Discrete Events and
Manufacturing Systems, pax: 783-788, Lille, France, 1996.
[117] Mertins, K., Edeler, H., Jochem, R. & Hofmann, J. Object oriented modeling and
analysis of business processes. In: Integrated Maufacturing Systems Engineering (P.
Ladet an F. Vernadat, eds), pp: 115-28, Chapman&Hall, London, UK, 1995.
[ 118] Meyer, B. Eiffel, the Language. Prentice Hall, 2 edition, 1992.
[119] Moler, C. B. MATLAB - An Interactive Matrix Laboratory. Technical Report 369,
Department of Mathematics and Statistics, University of New Mexico, 1980.
[ 120] Morel, G. & Lhoste, P. Outline for discrete part manufacturing engineering. In: Proc. of
7th annual European computer conference, pp: 146-155, Paris, France, 1993.
[ 121 ] Moreno, S., Peulot, E. Le GEMMA: modes de marches et d'arrts, Grafcet de
coordination des tches, Conception des Systmes Automatiss de Production srs.
Editions Casteilla. 1997.
[122] Munro, N. ECSTASY - A Control System CAD Environment. In: Proc. of l lth IFAC
World Congress on Automatic Control, pp: 13-17, Tallinn, Estonia, 1990.
[123] Musser, D. & Saini, A. STL Tutorial and Reference Guide. Addison-Wesley, 1996.
ISBN 0-201-63398-1.
[124] Naeger, G. & Rembold, U. An integrated approach to sofhvare system planning and
selection based on CIMOSA models. In: Control Engineering Practice, 3(1), 97-103.
1994.
[ 125] Naur, P. Report on the Algorithmic Language algol 60. In: Communications of the ACM,
6, pp: 1-17, 1960.
[126] OMG. Common Object Request Broker Architecture, v3.0. Object Management Group,
Inc.
[127] OMG. UML Semantics, v1.4. Object Management Group, Inc, September, 2001.
[128] Panetto, H., Lhoste, P., Petin, J.F. & Bierel, E. Contribution of the Grafcet model to
synchrony in discrete events systems modelling. In: Proc. of IEEE 20th Int. Conf.
on Industrial Electronics Control and Instrumentation, 3, pp. 1527-32, Bologne, Italy,
1994. ISBN 0-7803-13291.
[ 129] Panetto, H. Stability property of the Grafcet model with (Max, +) algebra. In:
Proceedings of IMACS/IEEE Multiconference CESA'96, Symposium on Discrete Events
and Manufacturing Systems, pp: 771-776, Lille, France, 1996.
[130] Pardo, X.C. & Ferreiro, R. SFC++: a tool for developing distributed real-time control
software. Microprocessors and Microsystems Journal, 23(2), pp: 75-84, 1999.
[131] Pardo, X.C. & Ferreiro, R. Initial design of a virtual machine to play grafcet models. In:
Preprints of 2nd IFAC/IFIP/IEEE Int. Conf. on Management and Control of Production
and Logistics, Grenoble, France, 2000.
447
Bibliografia
[ 132] Pardo, X.C. & Ferreiro, R. An object-oriented static metamodel for sequential function
charts. In: Proc. 8th IFAC Symposium on Computer Aided Control Systems Design, pp:
113-118, Salford, UK, 2000.
[133] Pardo, X.C. & Ferreiro, R. Control of Hybrid Systems with SFC++. En: Actas do
Semanario Anual de Automtica, Electrnica Industrial e Instrumentacin, Vigo, Espaa,
2003. ISBN: 84-688-3055-6 (en CD).
[134] Pardo, X.C. & Ferreiro, R. Modeling of Hybrid Sequential Control Systems with SFC++.
In: Proc. of 12`h IASTED Int. Conf. on Applied Simulation and Modelling, pp: 663-668,
Marbella, Spain, 2003. ISBN: 0-88986-384-9.
[135] Parr, T.J. Language translation using PCCTS and C++: a reference guide. Automata
Publishing Company, San Jose, CA 95129, USA. 1993. ISBN: 0-9627488-5-4.
[ 136] Parsaei, H.R. & Sullivan. W.G. (eds) Concurrent Engineering: contemporary issues and
modern design tools, Chapman&Hall, London. 1993.
[137] Petri, C. Kommunication mit Automaten. PhD Thesis. Institut fiir Instrumentelle
Mathematik, Univ. Bonn, 1962.
[138] Pollard, J. IEC 61131-3: the toolbet is on, but it's not very full. In: Control Engineering
Magazine, February, 1997.
[ 139] Qurenet, B. CIMOSA - A European development for enterprise integration. Part III:
Enterprise Integrating Infraestructure. In: Enterprise Integration Modeling (C. Petrie, ed.),
pp: 205-15, The MIT Press, Cambridge, MA, 1992.
[ 140] Rimvall, M. & Cellier, F.E. A Structural Approach to CACSD. In: Computer-Aided
Control Systems Engineering. Elsevier Science Publishers, Amsterdam, 1985.
[141] Rodd, M. G. & Suski, G. J. Computer Control Systems: an introduction. Lecture Notes of
ERASMUS intensive course on Application of Artificial Intelligence in Process Control,
pp: 205-222. Ed: Boullart, L. Krijgsman, A. and Vingerhoeds, R. A. Pergamon Press,
Exeter, England, 1992. ISBN: 0-08-042017-6.
[ 142] Rogerson, D. Calling All Members: Member Functions as Callbacks. MSDN Library,
Visual Studio 6.0, Technical Article, 37. 1992.
[143] Rosenbrock, H.H. Computer-Aided Control System Design, Academic Press, London,
1974.
[144] Ross, D.T. Structured Analysis (SA): a language for communicating ideas. In: IEEE
Trans. on Soflware Engineering, SE-3, pp: 6-15, 1977.
[145] Ross, D.T. Applications and extensions of SADT. In: IEEE computer, 18(4), pp: 25-34,
1985.
[ 146] Rousell, J.M. Sidoni: de la thorie la pratique.
[ 147] Rousell, J.M. & Lesage, J.J. Une algbre de Boole pour 1'approche vnementielle des
systmes logiques. In: Automatique, Productique et Informatique Industrielle, 27(5), pp:
541-560, 1993.
[148] Rousell, J.M. & Lesage, J.J. Validation and verification of Grafcets using State Machine.
In: Proc. of IMACS/IEEE Multiconference CESA'96, Symposium on Discrete Events and
[149] Roux, O. & Rusu, V. Du Grafcet au langage ractif Electre. In: Automatique,
Productique et Informatique Industrielle, 28(2), pp: 131-157, 1994.
Bibliografia
448
[ 150] Rumbaugh, J., Jacobson, I. & Booch, G. The unified modeling language reference
manual. Ed. Addison-Wesley, 1999. ISBN: 0-201-30998-X.
[151] Sall, K. XML Family of Specifications: A Practical Guide. Ed. Addison-Wesley, 2002.
ISBN: 0-201-70359-9.
[ 152] Schwetman, H. D. CSIM. A C-based, process oriented simulation language, Tech. Rep.
PP-080-85, Microelectronics and Computer Technology Corporation, 1985.
[153] Selic, B., Gullekson, G. & Ward, P. Real-time object-oriented modeling. John Wiley &
Sons, Inc, 1994. ISBN: 0-471-59917-4.
[ 154] Sessions, R. COM and DCOM: Microsoft's Vision for Distributed Objects. New York,
NY: John Wiley & Sons, 1997. ISBN 0-471-19381-X.
[155] Silva, M. & Teruel, E. A systems theory perspective of discrete event dynamic systems:
the Petri Net paradigm. In: Proc. of IMACS/IEEE CESA'96 Multiconference,
Symposium on Discrete Events and Manufacturing Systems, pp: 1-12, Lille, Franc,
1996.
[ 156] SLICE, A Subroutine Library for Control Engineering, The Numerical Algorithms
Group, Oxford, 1987.
[157] Soriano T, Boissier R, Razafindramary D and Raddadi M, Object-Oriented Analysis of
Hybrid Aspects of a Machine Tool. In: Proc. of IMACS/IEEE CESA'96 Multiconference,
Symposium on Discrete Events and Manufacturing Systems, pp: 390-395, Lille, France,
1996.
[158] Spang, H.A.. The Federated Computer-Aided Control Design System. In: ComputerAided Control Systems Engineering, Elsevier Science Publishers, Amsterdam, 1985.
[ 159] Spechart, F. H., Green, W. L. A Guide to Using CSMP - the Continuous System
Modelling Program., pp. 35-39, Prentice Hall, 1976.
[ 160] Strauss, J.C. The SCi Continuous System Simulation Language (CSSL), Simulation, 9(6),
281-303, 1967.
[161] Stroustrup, B. The C++ programming language, special edition. Ed: Addison-Wesley,
2000. ISBN: 0-201-70073-5.
[ 162] Taylor, J. H., Frederick, D. K. Rimvall, C. M. and Sutherland, H. A. .The GE MEAD
Computer-Aided Control Engineering Environment. In: Proc. IEEE Symposium on
CACSD, Tampa, FL, 1989.
[163] Taylor, J.H. & Chan, C. An Expert-Aided implementation interface for Industrial Process
Control Systems. In: Proc. of the IEEE 1999 Mediterranean Control Conference, Haifa,
Israel, 1999.
[164] Union Technique de 1'lectricit. Diagramme fonctionnel GRAFCET pour la description
des systmes logiques de commande. NFC 02, Paris, France, 1982.
[ 165] Union Technique de 1'lectricit. Function Charts GRAFCET. Extension of basic
principles. NFC 03-191, Paris, France, 1993.
[ 166] United States Department of Defense. Reference Manual for the Ada programming
language. DoD, Washington, D.C., January 1983. ANSUMIL-STD-1815A.
[167] Van der Wal, E. Acceptance grows for IEC 61131-3 and PLCOpen. In: Control
Engineering Magazine, February, 1997.
449
Bibliograâ
[168] Varsamidis, T., Hope, S. & Jobling, C.P. An object-oriented information model for
Computer-Aided Control Engineering. In: Control Engineering Practice, 4(7), pp: 929-37,
1996.
[169] Vernadat, F. Enterprise Modelling and Integration. Principles and Applications. Ed.
Chapman&Hall, London, LTK. 1996. ISBN: 0-412-60550-3.
,
[ 170] Waldner, J. CIM. principles of computer-integrated manufacturing. John Wiley & Sons,
New York, NY. 1992.
[ 171 ] Walker, R., Gregory Jr., C. & Shah. S. Matrix-X, A Data Analysis, System Identification,
Control Design and Simulation Package. IEEE Control Systems Magazine, 2(4), pp: 30
37, 1982.
[172] Walln, A. Using Grafcet To Structure Control Algorithms. In: Proc. of 3rd European
Control Conference, 1995.
[173] Wilczynski, B.K. & Wallace, B.K. OOPS in real-time control applications. In: Object
oriented software for manufacturing systems, pp: 194-229, Chapman&Hall, London,
England, 1992.
[ 174] Willians, T.J. The Purdue Enterprise Reference Arquitecture. In: Computers in industry,
24(2-3), pp:141-158, 1994.
[175] Wirth, N. The Programming Language Pascal. In: Acta Informatica, 1, pp: 35-63, 1971.
[ 176] Wolfram, S. Mathematica, A System for poing Mathematics by Computer, AddissonWesley, 1991.
[ 177] Wonham, W.M. & Ramadge, P.J. On the supremal controllable sublanguage of a given
language. In: SIAM Journal of Control Optimization, 25, pp: 637-659, 1987.
[ 178] Wormer, J. & Kleppe A. The object constraint language, precise modeling with UML,
Addison-Wesley, 1999. ISBN: 0-201-37940-6.
[ 179] Zaytoon, J. Specification and design of logic controllers for automated manufacturing
systems. In: Robot & CIM, 12, pp: 353-366, 1996.
[ 180] Zaytoon J, Richard E, Moughamir S and Angelloz L, A formalism for Complex Control
Systems: Application to a Machine for Training and Re-education of Lower Limbs. In:
Proc. of IMACS/IEEE CESA'96 Multiconference, Symposium on Discrete Events and
[ 181 ] Zaytoon, J. & Villermain-Lecolier, G. Two methods for the engineering of manufacturing
systems. In: Control Engineering Practice, 5(2), pp: 185-198, 1997.
[ 182] Zaytoon, J., Carr-Mntrier, V., Niclet, M. & De Loor, P. On the recent advances in
Grafcet. In: Preprints of the IFAC Workshop on Manufacturing Systems: Modelling,
Management and Control, pp: 419-424, Vienna, Austria, 1997.
[183] Zaytoon, J., Ndjab, C. & Carr-Mntrier. On the synthesis of Grafcet using the
supervisory control theory. In: Proc. of IFAC conference, pp: 391-396, Belfort, France,
1997.
[184] Zaytoon, J., Ndjab, C. & Roussel, J.M. On the supremal controllable Grafcet of a given
Grafcet. In: Proc. of 2nd IMACS MATHMOD conf., pp: 371-376, Vienna, Austria. 1997.

Modelos Gracef11

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelos Gracef11

Uploaded by

Copyright:

Available Formats

N

IMPLEMENTACIN DUN^AMBIENTE ABERTO E

AUTOR: D. XON CARLOS PARDO MARTNEZ

LISTA DE FIGURAS .....................................................................................................................XV

LISTA DE TABOAS .............................................. ....................................................................... XXI

GLOSARIO DE ABREVIATURAS ......................................................................................... XXIII

1.1. MOTIVACIN ............................................................................................................... 25

1.1.1. Antecedentes histricos ........................................................................................ 26

1.1.2. Lias de investigacin ......................................................................................... 28

1.2. ^BXECTIVOS ................................................................................................................ 31

1.3. MTODOS E FERRAMENTAS UTILIZADOS ...................................................................... 32

1.3.1. SGI STL ................................................................................................................ 33

1.3.2. Common. C++ ...................................................................................................... 33

1.3.3. Sidoni ................................................................................................................... 33

1.4. SUMARIO ..................................................................................................................... 33

CAPTULO 2. FUNDAMENTOS E DESCRICIN DA FERRAMENTA PROPOSTA...........35

2.1. ^S SISTEMAS INDUSTRIAIS E O SEU CONTROL ............................................................... 35

2.1.1. Descricin dun sistema industrial ....................................................................... 35

2.1.2. Os sistemas de control industrial ......................................................................... 37

2.1.3. Modelado de procesos industriais ....................................................................... 38

2.1.4. A arquitectura fisica do sistema de control ......................................................... 39

2.2. O DESENVOLVEMENTO DE "SOFTWARE" PARA SISTEMAS MDUSTRIAIS ........................ 40

2.2.1. As arquitecturas de referencia na enxeera de sistemas industriais ................. 40

2.2.2. O modelado na enxeera de sistemas industriais ............................................... 41

2.2.3. Caracteristicas do "software " de control industrial ........................................... 42

2.2.4. Aplicacin de metodoloxa;s "software " en sistemas industriais ........................ 43

2.3. A FERRAMENTA PROPOSTA .......................................................................................... 44

2.3.1. A orientacin a obxectos no modelado de sistemas industriais .......................... 44

2.3.2. O Grafcet como formalismo de especificacin .................................................... 45

2.3.3. Comparacton con outras aproxtmactons .............................................................

2.3.4. A arquitectura da ferramenta .............................................................................. 49

2.3.5. O proceso de desenvolvemento coa ferramenta .................................................. SO

2.4. CONCLUSINS .............................................................................................................. $2

CAPITULO 3. O GRAFCET ...........................................................................................................55

3.1. INTRODUCCIN ............................................................................................................ $$

3.2. A SINTAXE DO GRAFCET .............................................................................................: $7

3.2.1. Elementos bsicos ....................................................:........................................... 57

3.2.1.1. Etapas ....................................................................................................................................$7

3.2.1.2. Transicins ............................................................................................................................$7

3.2.1.3. Arcos orientados ...................................................................................................................$7

3.2.1.4. Receptividades ......................................................................................................................$8

3.2.1.$. Accins ..................................................................................................................................$8

3.2.2. Extensins sintcticas .......................................................................................... 59

3.2.2.1. Etapas fonte e sumidoiro .....................................................................................................$9

3.2.2.2. Macroetapas ..........................................................................................................................60

3.2.2.3. Particins ...............................................................................................................................61

3.2.2.4. Ordes de forzado ..................................................................................................................61

3.2.3. Estructuras de control bsicas ............................................................................ 63

3.2.3.1. Secuencia ..............................................................................................................................63

3.2.3.2. Seleccin de secuencia ........................................................................................................63

3.2.3.3. Fin de seleccin de secuencia .............................................................................................63

3.2.3.4. Paralelismo ............................................................................................................................63

3.2.3.$. Fin de paralelismo (sincronizacin) ..................................................................................64

3.2.3.6. Salto de etapas ......................................................................................................................64

3.2.3.7. Ciclo .......................................................................................................................................6$

3.2.3.8. Semforo ...............................................................................................................................6$

3.2.3.9. Acumulacin e reserva ........................................................................................................67

3.2.3.10. Paralelismo interpretado e paralelismo estructural .........................................................68

3.3. A SEMNTICA DO GRAFCET ......................................................................................... 69

3.3.1. As regras de evolucin ........................................................................................ 69

3.3.1.1. Regra 1: Situacin inicial .........................................................................................:...........69

3.3.1.2. Regra 2: Determinacin das transicins franquebeis .....................................................69

3.3.1.3. Regra 3: Franqueamento dunha transicin ........................................................................70