You are on page 1of 439

N

UNIVERSIDADE DA CORUNA
DEPARTAMENTO DE ELECTRNICA E SISTEMAS

TESE DE DOUTORAMENTO

IMPLEMENTACIN DUN^AMBIENTE 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.1. Estructuras de control .......................................................................... 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.2.5. Anlise sintctica ................................................................................. 118

4.2.2.2.6. Simulacin e execucin ....................................................................... 119

4.2.2.2.7. O algoritmo de interpretacin .............................................................. 119

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.1. Estructuras de control .......................................................................... 121

.
4.2.3.2.2. Estructura xerrquica ...........................................................................

4.2.3.2.3. Accins e receptividades ..................................................................... 122

4.2.3.2.4. Identificacin .. ..................................................................................... 122

4.2.3.2.5. Anlise sintctica ................................................................................. 123

4.2.3.2.6. Simulacin e execucin ....................................................................... 123

4.2.3.2.7. O algoritmo de interpretacin .............................................................. 123

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.2.5. Anlise sintctica ................................................................................. 126

4.2.4.2.6. Simulacin e execucin ....................................................................... 126

4.2.4.2.7. O algoritmo de interpretacin .............................................................. 127

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.1. Estructuras de control .......................................................................... 128

.
4.2.5.2.2. Estructura xerrquica ........................................................................... 1

4.2.5.2.3. Accins e receptividades ..................................................................... 128

4.2.5.2.4. Identificacin ....................................................................................... 129

4.2.5.2.5. Anlise sintctica ................................................................................. 129

4.2.5.2.6. Simulacin e execucin ....................................................................... 129

4.2.5.2.7. O algoritmo de interpretacin .............................................................. 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.3. Accins e receptividades ..................................................................... 132

4.2.6.2.4. Identificacin ....................................................................................... 133

4.2.6.2.5. Anlise sintctica ................................................................................. 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.1. Estructuras de control .......................................................................... 137

4.2.7.2.2. Estructura xerrquica ........................................................................... 137

4.2.7.2.3. Accins e receptividades ..................................................................... 137

4.2.7.2.4. Identificacin ....................................................................................... 138

4.2.7.2.5. Anlise sintctica ................................................................................. 138

4.2.7.2.6. Simulacin e execucin ....................................................................... 138

4.2.7.2.7. O algoritmo de interpretacin .............................................................. 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.1. Estructuras de control .......................................................................... 139

4.2.8.2.2. Estructura xerrquica ........................................................................... 139

4.2.8.2.3. Accins e receptividades ..................................................................... 139

4.2.8.2.4. Identificacin ................................................................................ ... 140

4.2.8.2.5. Anlise sintctica ................................................................................. 140

4.2.8.2.6. Simulacin e execucin ....................................................................... 141

4.2.8.2.7. O algoritmo de interpretacin .............................................................. 141

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.1. Estructuras de control .......................................................................... 142

4.2.9.2.2. Estructura xerrquica ........................................................................... 142

4.2.9.2.3. Accins e receptividades ..................................................................... 143

4.2.9.2.4. Identificacin ....................................................................................... 144

4.2.9.2.5. Anlise sintctica ................................................................................. 144

4.2.9.2.6. Simulacin e execucin ....................................................................... 144

4.2.9.2.7. O algoritmo de interpretacin .............................................................. 145

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.13. Grafcet utilizado como exemplo . ....................................................................................... 372

Figura 8.14. Grafcet utilizado como exemplo . ....................................................................................... 374

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
^UML
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 `estar 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]: `a
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 `abertos', 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`intelixencia'
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/

Captulo 1: Introduccin

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) `intelixentes' 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 `abertos' 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.

Captulo 1: Introduccin

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/.

Captulo 1: Introduccin

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.

Captulo 1: Introduccin

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]: `o 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:

Captulo 2: Fundamentos e descricin da ferramenta proposta

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^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.

Captulo 2: Fundamentos e descricin da ferramenta proposta

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.

Captulo 2: Fundamentos e descricin da ferramenta proposta

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 `informais' 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 `informais' 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]).

Captulo 2: Fundamentos e descricin da ferramenta proposta

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 `intelixentes' 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.

Captulo 2: Fundamentos e descricin da ferramenta proposta

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

Seccin 2.3: A ferramenta proposta

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^ortamento. 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).

Captulo 2: Fundamentos e descricin da ferramenta proposta

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

Seccin 2.3: A ferramenta proposta

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

Captulo 2: Fundamentos e descricin da ferramenta proposta

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

Hardware/Sistema Operativo

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

Hardware/Sistema Operativo

(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

Seccin 2.3: A ferramenta proposta

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

Captulo 2: Fundamentos e descricin da ferramenta proposta

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

Captulo 3: O Grafcet

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

Seccin 3.2: A sintaxe do Grafcet

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

Captulo 3: O Grafcet

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

Seccin 3.2: A sintaxe do Grafcet

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

Captulo 3: O Grafcet

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

Seccin 3.2: A sintaxe do Grafcet

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.

Captulo 3: O Grafcet

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

Seccin 3.2: A sintaxe do Grafcet

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

Captulo 3: O Grafcet

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

Seccin 3.2: A sintaxe do Grafcet

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

Captulo 3: O Grafcet

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.

Captulo 3: O Grafcet

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^a.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

Seccin 3.3: A semntica do Grafcet

a=1

b=0

(1)-^a.b

(^)^a.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

Captulo 3: O Grafcet

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 ^a ocorre antes ou despois da activacin da etapa 2. A demostracin a seguinte: sexa
ta = t(^a) - 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

Seccin 3.3: A semntica do Grafcet

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 ^acordo 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

Captulo 3: O Grafcet

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

Seccin 3.3: A semntica do Grafcet


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

Captulo 3: O Grafcet

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]: `a 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

Seccin 3.3: A semntica do Grafcet

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
Escreber variabeis de saida

Rearas 3. 4& 5: Evolucin da situacin


Si

Figura 3.33. Xogador ARS con das escalas de tempo baixo a hiptese de sincronismo forte.

Captulo 3: O Grafcet

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 `estructurais' 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
`estructural', 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

Seccin 3.3: A semntica do Grafcet

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
Escreber variabeis de saida

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

Captulo 3: O Grafcet

^ 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

Seccin 3.3: A semntica do Grafcet

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).

Captulo 3: O Grafcet

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^I
i4s
i

i
i

;E i4s^^,

Figura 3.42. Cronograma dunha accin retardada.

83

Seccin 3.3: A semntica do Grafcet


^-.^
^ ^

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.

Captulo 3: O Grafcet

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.

Captulo 3: O Grafcet

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^Is; 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

Seccin 3.4: O modelo matemtico do Grafcet


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.

Captulo 3: O Grafcet

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

Seccin 3.4: O modelo matemtico do Grafcet

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.

Captulo 3: O Grafcet

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

Captulo 3: O Grafcet

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

Seccin 3.5: Exemplos de modelado

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

Avance do cilindro 3

Dfc2

Detector inferior de final de carreira do motor 1

Ci14

Avance do cilindro 4

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

Captulo 3: O Grafcet

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^EF
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

Seccin 3.5: Exemplos de modelado

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^EF (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

Captulo 3: O Grafcet

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

Seccin 3.5: Exemplos de modelado

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.

Captulo 3: O Grafcet

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 `efecto 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

Captulo 3: O Grafcet

corresponde coa especificacin detallada definida no estndar IEC 60848 (Figura 3.5) e est
formada por 4 campos:
1. Campo `a', 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

Seccin 3.6: O estndar IEC 61131-3 e o SFC

>_

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

Captulo 3: O Grafcet

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

Seccin 3.6: O estndar IEC 61131-3 e o SFC

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.

Captulo 3: O Grafcet

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 ^ue 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:

Captulo 4: Anlise de aplicacins Grafcet

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 `efectos 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

Captulo 4: Anlise de aplicacins Grafcet

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.

Captulo 4: Anlise de aplicacins Grafcet

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

Seccin 4.2: Aplicacins analizadas

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.
4.2.1.2.3. Accins e receptividades

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 `et'. Ambas partes son opcionais, e a ausencia simultnea
dambas equivale a unha receptividade sempre certa. A condicin segue a mesma sintaxe que a

Captulo 4: Anlise de aplicacins Grafcet

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 `efectos 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

Seccin 4.2: Aplicacins analizadas

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

Captulo 4: Anlise de aplicacins Grafcet

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

Seccin 4.2: Aplicacins analizadas

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.
4.2.2.2. O editor Grafcet
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.
4.2.2.2.1. Estructuras de control

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.
4.2.2.2.2. Estructura xerrquica

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.
4.2.2.2.3. Accins e receptividades

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

Captulo 4: Anlise de aplicacins Grafcet

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 `efectos colaterais' durante a sa avaliacin.

^e ^d3 Vew ^ro'^ect Bulld

o^^^i,^ ^^

yout OPfine Ophar>; ]^irtd

;^^f ^'^_:'^^^

j^^.l^^ l

^ 1 ^;^__ I II,^ ^^, ^'^ ^'^

^ -^,; ^ ,^ ^ ^ ^ f ^^i;
-^ 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 ^^Access ^ 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.

4.2.2.2.4. Identificacin

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.
4.2.2.2.5. Anlise sintctica

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

Seccin 4.2: Aplicacins analizadas

4.2.2.2.6. Simulacin e execucin

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.

Captulo 4: Anlise de aplicacins Grafcet

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.

Seccin 4.2: Aplicacins analizadas


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.
4.2.3.2. O editor Grafcet
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.
4.2.3.2.1. Estructuras de control

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.
4.2.3.2.2. Estructura xerrquica

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" ^efinidos
na ltima revisin do estndar Grafcet [85]-.

Captulo 4: Anlise de aplicacins Grafcet

122

4.2.3.2.3. Accins e receptividades

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 `efectos 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.

4.2.3.2.4. Identificacin

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

Seccin 4.2: Aplicacins analizadas

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.
4.2.3.2.5. Anlise sintctica

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.
4.2.3.2.6. Simulacin e execucin

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.
4.2.3.2.7. O algoritmo de interpretacin

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

Captulo 4: Anlise de aplicacins Grafcet

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

Seccin 4.2: Aplicacins analizadas

4.2.4.2. O editor Grafcet


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

^`Initial 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^e

Figura 4.9. Editor Grafcet do PL7.

4.2.4.2.1. Estructuras de control

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.
4.2.4.2.2. Estructura xerrquica

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

Captulo 4: Anlise de aplicacins Grafcet

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.
4.2.4.2.3. Accins e receptividades

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 `efectos colaterais' durante a
sa avaliacin.
4.2.4.2.4. Identificacin

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.
4.2.4.2.5. Anlise sintctica

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.
4.2.4.2.6. Simulacin e execucin

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

Seccin 4.2: Aplicacins analizadas

4.2.4.2.7. O algoritmo de interpretacin

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.
4.2.5.2. O editor Grafcet
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

Captulo 4: Anlise de aplicacins Grafcet


4.2.5.2.1. Estructuras de control

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.


4.2.5.2.2. Estructura xerrquica

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.
4.2.5.2.3. Accins e receptividades

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

Seccin 4.2: Aplicacins analizadas

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
`efectos colaterais' que poidan producirse durante a avaliacin das receptividades.
4.2.5.2.4. Identificacin

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.
4.2.5.2.5. Anlise sintctica

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.
4.2.5.2.6. Simulacin e execucin

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.
4.2.5.2.7. O algoritmo de interpretacin

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.

Captulo 4: Anlise de aplicacins Grafcet

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.
4.2.6.2. O editor Grafcet
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

Seccin 4.2: Aplicacins analizadas

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.
4.2.6.2.1. Estructuras de control

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.
(^E^ ^Edmon AK^+^9e^ Eroqenme 4^e Fe^e
t^ ^ i II f^i ;^} ^ ^ e^^i ^ ^', .^
^^ ,^Ii
. : 1

_^ . ^:

aJ

^_,^^
^^3^14 *^ j ^z^G : ^. :: ,.

r,

-^ R^wces '
^;^j Modul^sadairei ^

il ^ ^_ ^..-: _.^; _.

^^_
^^

^enrtn nt daM>UT04UEt{ lopicier dman i 07"r11]


^^ . O! : aDpliution i leur, exieution ... DassaOe en RUN ... aCtration de la visualWllen dynamiQu! ... tennin.

w (^^ w.^a

^`^,^tmEMOSEH

Figura 4.11. Interface do programa Automgen.

Captulo 4: Anlise de aplicacins Grafcet

132

4.2.6.2.2. Estructura xerrquica

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.

4.2.6.2.3. Accins e receptividades

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

Seccin 4.2: Aplicacins analizadas

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
`efectos 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.
4.2.6.2.5. Anlise sintctica

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.

Captulo 4: Anlise de aplicacins Grafcet

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.
4.2.6.2.6. Simulacin e execucin

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.
4.2.6.2.7. O algoritmo de interpretacin

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

Seccin 4.2: Aplicacins analizadas

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

Captulo 4: Anlise de aplicacins Grafcet

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.

4.2.7.2. O editor Grafcet


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

Seccin 4.2: Aplicacins analizadas

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.
4.2.7.2.1. Estructuras de control

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.
4.2.7.2.2. Estructura xerrquica

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

^e^
^

^-^"^S
^I
^ P`rt settrt^3s

^ Q SYstem tnary
': p_d [^achi H-series]
p..^ ^sf^^^
O[] [^C-^el
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
-.^^^
^,
,.
^I:,
^
. ^ ^T'^
.^ ..
:
^^
--
^, r._
!^..^:U:a.
- . . __ ' .
t ^ __ .. ,

[f
e
_i

^Cordroi

^ ^;.,
^
, , . ^'
^ i ,^
^.

^ 6W MOndOt

,,

;-

[
{^ t ^
-'
^' ^-^
^
^-xi

Corrd ot Upper Cai^eyx.


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
^^O
rj ^ r+25x (cPtm-o2HC) [meiN
ACTANA-S2
_^^ PIM-0W
....
POM.RH

i^
^^
^^ ;
i,

r
t

^ rl 'y^

-^ X ^ ^
;

'

^+. [] SYmbds

^^^

^f ^i

..

n ', kf I 81 Bt^^ 8j ^.'-

^
^^ ^
^
^^^^,^=^^
^^^^_ ^^. ^^_^>

- .^ -_; _-^ -

..

=q x

^ p r? Project Sfc demo

.,a;x
.
a

. ^_,; .: -.
^.^ . Eae _Et:zxiew jm^rt>;:9Perafioru ^"Sortnr^aGon^ I^ ^ci^ow^.tleb ..., ;.
^`^ i`^ ^ ;^ ^ (^ ^' ^G ^C: '^ X ris ^ S^ ^^ ^I^`^ ^ '^tF ^r ^, ^. ^,aa `^ ^ t4: ^ ^t2 I 1

`,,

^^

,, `

j^

^`
'
^ F^
^.

^,

^:
^, ^ ^
r

' -o

- *^.

^
^_

_.._
{

.__

_ .^..__-- - - --- -
-^ :
-,,_ .._,_ _
_.. ^ ^ ^

z,- : _
..
^.^l^ 3 ^ F^ ._^S
.I_eit

t'
_-

,,

": - ' -. . -J^ ;


-----

^:^rt.^ ..^^^^^u _
`

^^ 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.

4.2.7.2.3. Accins e receptividades

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

Captulo 4: Anlise de aplicacins Grafcet

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 `efectos colaterais' durante a sa avaliacin.
4.2.7.2.4. Identificacin

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.
4.2.7.2.5. Anlise sintctica

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.
4.2.7.2.6. Simulacin e execucin

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.
4.2.7.2.7. O algoritmo de interpretacin

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

Seccin 4.2: Aplicacins analizadas

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.).
4.2.8.2. O editor Grafcet
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.
4.2.8.2.1. Estructuras de control

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.
4.2.8.2.2. Estructura xerrquica

O WinGrafcet non incle soporte estructura xerrquica do Grafcet.


4.2.8.2.3. Accins e receptividades

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

Captulo 4: Anlise de aplicacins Grafcet

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 `efectos
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

4.2.8.2.4. Identificacin

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.
4.2.8.2.5. Anlise 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

Seccin 4.2: Aplicacins analizadas

4.2.8.2.6. Simulacin e execucin

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.
4.2.8.2.7. O algoritmo de interpretacin

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.
4.2.9.2. O editor Grafcet
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

Captulo 4: Anlise de aplicacins Grafcet


4.2.9.2.1. Estructuras de control

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.
4.2.9.2.2. Estructura xerrquica

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

Seccin 4.2: Aplicacins analizadas

4.2.9.2.3. Accins e receptividades

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

Captulo 4: Anlise de aplicacins Grafcet

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 `efectos colaterais'.
4.2.9.2.4. Identificacin

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.
4.2.9.2.5. Anlise sintctica

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.
4.2.9.2.6. Simulacin e execucin

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

Seccin 4.2: Aplicacins analizadas

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.
4.2.9.2.7. O algoritmo de interpretacin

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

Captulo 4: Anlise de aplicacins Grafcet

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

Seccin 4.3: Conclusins


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 `efectos 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

Captulo 4: Anlise de aplicacins Grafcet

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

Seccin 4.3: Conclusins


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^o 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

Captulo 4: Anlise de aplicacins Grafcet

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
Si (mediante LabView)
Si (mediante LabView)
Si (mediante LabView)
Si (mediante LabView)
Si (mediante LabView)
Si (mediante 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

Seccin 4.3: Conclusins


VISUAL IO
- ^.
_.
.-

AUTOMGEN
. .,, _ " . . .

Dats".^a,. 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

,- ,,_
`E^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^ii^`
^Opcids
'. :^
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
-..-_^.. ...

-__

Captulo 4: Anlise de aplicacins Grafcet

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
-

^^Inter 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

Seccin 4.3: Conclusins


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 `unha 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^uery : 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:

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet

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.

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet


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^able : 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.

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet

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

Captulo 5: Proposta dun metamodelo para o Grafcet

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^afcetNode
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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet

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

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet


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 (^^ActionStateAssoc")


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.

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet


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.

Captulo 5: Proposta dun metamodelo para o Grafcet


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-^includesAll(closure->allAdjacents)
then closure
else transitiveClosure(closure^union(closure^allAdjacents))
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^allAdjacents(s : Set(T)) : Set(T);
allAdjacents = s^collect(adjacents)-^asSet

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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet

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))--^isEmpty

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-^includes(self. name)

--indicador

self.indicator^notEmpty implies

self. Step. PartialGrafcet. GlobalGrafcet. data-^includes(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^includesAll(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-^includes(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.

Captulo 5: Proposta dun metamodelo para o Grafcet

172

allVars : Set(GrafcetVar);

a1lVars = self.GrafcetVar-^union(self.Event->collect(var)-^asSet)

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^includes(node2)

or nodel.allPredecessors-^includes(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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet

self.subsystems^forAll(PartialGrafcet pg ^

self.subsystems^includesAll(pg.allForced) and

self.subsystems^includesAll(pg. allForcers))

3. A xerarqua de forzado acclica.


self.subsystems^forAll(PartialGrafcet pg ^

not(pg. allForcers^incl 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^includesAll(action^Grafcet Var))

Grafcet parcial ("PartialGrafcet")

1. Os identificadores dos grafcets conexos includos nun grafcet parcial son nicos.

174

Captulo 5: Proposta dun metamodelo para o Grafcet


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^includes(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^includesAll(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-^includes(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)
Operacins auxiliares

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-^asSet)

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^asSet)

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

Seccin 5.1: Metamodelo para a sintaxe do Grafcet

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-^includesAll(self.allSuccessors) and

self. ConnectedGrafcet. nodes--^includesAll(self. a1lPredecessors)

Captulo 5: Proposta dun metamodelo para o Grafcet

176

Operacins auxiliares
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^asSet)

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-^asSet)

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^includesAll(self.situation.allSteps)
3. A etapa que a orde de forzado est asociada est contida no grafcet parcial forzador.
self forcer. nodes^includes(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^includesAll(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 o primeiro libre (1)

reserva o primeiro libre (2)

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

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.2: Implementacin do metamodelo

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].

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.2: Implementacin do metamodelo

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 ^e 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

Captulo 5: Proposta dun metamodelo para o Grafcet


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

Seccin 5.2: Implementacin do metamodelo


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

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.2: Implementacin do metamodelo


^

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


nivel da xerarqua estructural.

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)

Liberar ids. 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)

Liberar ids. 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

Notificar DELETE (grafcet parcial pai)

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.

Captulo 5: Proposta dun metamodelo para o Grafcet

186

, SETID_SFC

Modificacin do identificador dun SFCGlobal


nivel da xerarqua estructural.

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

Notificar DELETE (grafcet parcial pai)

Comprobar duplicados (novo id. macroetapa)

Liberar id. vello

Actualizar id. (macroetapa)

Bloquear novo id.

Notificar INSERT (grafcet parcial pai)

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


nivel da xerarqua estructural.
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)

Notificar DELETE (grafcet parcial pai)

Comprobar duplicados (novo id. nodo)

Liberar id. vello

Actualizar id. (nodo)

Bloquear novo id.

Notificar INSERT (grafcet parcial pai)

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

Seccin 5.2: Implementacin do metamodelo


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
^ ^

^U

^ 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.

Captulo 5: Proposta dun metamodelo para o Grafcet

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^E

o ^

C
O ^

C y

O O

^ ^

^
a^

o W

^i

am

^
^

C r

G^

O ^ m
C

s
^i
E m m

a^^

Figura 5.17. Secuencia de mensaxes da insercin dun nodo nun grafcet conexo.

189

Seccin 5.2: Implementacin do metamodelo

I
^
I
-. ............

..^

4
^
N
i
U

.......................^

..............i^

V^

^^

^
^

^
^^
^^

$ ^

^^

I ^

'
^

^
'

^^ ^'

! ^^

^^
:

^io;^^
.

^s

^^

^$

g
E

^.
^^
Figura 5.18. Secuencia de mensaxes da insercin dun nodo na macroexpansin dunha macroetapa.

190

Captulo 5: Proposta dun metamodelo para o Grafcet

^W

^--. V

^ m
^

$ ,^

^
J ^

LL

^_

m v m
y

W
^

}__._..._..v_...__^_.__._._^ _._.._...

^
^

^7 ^

I'

9' 11
?T

_.-___Y .__

vd

t.^

n
y

p
^

`m
^

^I
^ ^

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

'

^i

^_ m

^I'

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^i W

m
c_
C L
^c
m^aci
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

Seccin 5.2: Implementacin do metamodelo


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
^I ['for all node (n) in csfc]
remove(n)

D uNockSFCIDs(csfc)
^unlocklD(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

Captulo 5: Proposta dun metamodelo para o Grafcet

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

Seccin 5.3: Exemplos de modelado

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)");

54.SFCTrans trans2("(2)");

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);

Captulo 5: Proposta dun metamodelo para o Grafcet


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");

75.SFCStep step2("2");

76.SFCStep step3("3");

77.SFCStep step4("4");

78.// tranaicins

79.SFCTrans trans0a("(O.a)");

80.SFCTrans transOb("(O.b)");

81.SFCTrans transla("(l.a)");

82.SFCTrans translb("(i.b)");

83.SFCTrans trans2("(2)");

84.SFCTrans trans3("(3)");

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);

98.sfc1->link(t2, s4);

99.sfc1->link(t3, s4);

100. node iterator t4

= sfcl->insertAfter(s4,

trans4);

var

195

Seccin 5.3: Exemplos de modelado

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");

109. SFCStep step3("3");

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

Captulo 5: Proposta dun metamodelo para o Grafcet


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);

133. SFCStep step5("5");

134. // tranaicias

135.
136.
137.
138.
139.

SFCTrans transl("(1)");

SFCTrans trans2("(2)");

SFCTrans trans3("(3)");

SFCTrans trans4("(4)");

// 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);

152. sfcl->link(t3, s3);

153. sfcl->link(t3, s4);

197

Seccin 5.3: Exemplos de modelado


[
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

Captulo 5: Proposta dun metamodelo para o Grafcet

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^II^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^IEI, 2",

169.
170.
171.
172.
173.
174.
175.

- READ);
process_vars.insert(inputl);
process_vars.insert(input2);

// modelo Grafcet

SFCGlobal global("GG");

// 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.

SFCTrans trans0("(0)");

// 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

SFCGlobal global("GG");

// grafcets parciais

SFCPartial* sfcl = new SFCPartial("PG1");

global.insert(sfcl);

// etapas

SFCStep step0("0", SFCStep::initial);

SFCStep step2("2");

P, "","" 0, 0, true);

199

Seccin 5.3: Exemplos de modelado

211. // transicina

212. SFCTrans trans0("(0)");

213. SFCTrans

214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.

transl("(1)");

SFCTrans trans2("(2)");

// 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) ;

235. sfcl->link(t2, s0);

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.

Captulo 5: Proposta dun metamodelo para o Grafcet

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* sfcl = new SFCPartial("PG1");

SFCPartial* sfc2 = new SFCPartial("PG2");

global.insert(sfcl);

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.

Seccin 5.4: Conclusins


// 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^ath;

285.
string sfcpp^ath;
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

^eventos simultneos?

291. }

A informacin almacenada nos atributos desta clase a seguinte:


1. Nome e localizacin do proxecto -atributos project_name (lia 284) e project^ath (lia
285}-.
2. Localizacin do compilador Grafcet -atributo sfcpp^ath (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^ath-. 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^ath- 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.

Captulo 6: Compilacin de modelos Grafcet

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^arent^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

Captulo 6: Compilacin de modelos Grafcet

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

Captulo 6: Compilacin de modelos Grafcet


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 `amiga' (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

Seccin 6.2: A estructura do compilador Grafcet

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^iler, 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

Captulo 6: Compilacin de modelos Grafcet

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

Seccin 6.2: A estructura do compilador Grafcet

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

Captulo 6: Compilacin de modelos Grafcet

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
[^or all subphase]
subphase() ^
acceso informacin interna

^ preprocesamento
['for all subphase (phase)j
phaseO
acceso informacin interna
N-J

procesamento da fase

acceso informacin interna


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.

Captulo 6: Compilacin de modelos Grafcet

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

Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet

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

Captulo 6: Compilacin de modelos Grafcet

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.

Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet


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-relational-expression
sfcpp-relational-expression
sfcpp-relational-expression
sfcpp-relational-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 )

[+]

( sfcpp-expression )

[+]

T (

549.
^
550.
551. sfcpp-timer-expreasion:
552.
T# ( digit-sequence,^^ ; sfcpp-expressioa,D^ ; digit-sequence,pt )
553.

[+]
[+]

Captulo 6: Compilacin de modelos Grafcet


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-expression )

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 . }

Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet


// 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

Captulo 6: Compilacin de modelos Grafcet

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.

618. /* Cdigo modificado */

619. const bool sfcpp_event_id = vm.getModelVarEvent("a", EDGE_UP);

620. sfcpp_event_id = true; // BRROR: asignacin a uaha varibel tipo coast

621.

622. /* Cdigo orixinal */

623. any_function(Ta); // fuacin que modifica o parmetro

624.

625. /* Cdigo modificado */

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

Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet

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:
628. /* Cdigo orixinal */

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.

644. /* Cdigo modificado: paso 4*/

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)

658. /* Cdigo modificado: paso 6*/

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.

/* Cdigo modificado: paso 7*/

// substitucin de eventos simples

const bool sfcpp_timer_id = vm.getTimerState("sfcpp_timer_id");

const bool sfcpp_event_id = vm.getSystemVarEvent("b", EDGE_UP);

bool sfcpp_expr_id = (bool) (c+5 > 10);

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))

Captulo 6: Compilacin de modelos Grafcet

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^es,
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.

/* Cdigo modificado: paso 7*/

// substitucia de eventos simples

const bool sfcpp_timer_id = vm.getTimerState("sfcpp_timer_id");

const bool sfcpp_event_id = vm.getSystemVarEvent("b", EDGE_UP);

static bool sfcpp_expr_id_last = false;

bool sfcpp_expr_id_up, sfcpp_expr_id_down;

225
701.
702.
703.
704.
705.
706.

707 .
7oa.
709.
710.
711.
712.

Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet


bool sfcpp_expr_id = (bool) (c+5 > 10);

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 */


static bool sfcpp_expr_id_last = false;

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.

740. /* Cdigo modificado */

741. static bool sfcpp_expr_id_last = false;

742. bool sfcpp_expr_id_up, sfcpp_expr_id_down;

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_down = (sfcpp_expr_id_last) ? true : false;

sfcpp_expr_id_last = sfcpp_expr_id;

226

Captulo 6: Compilacin de modelos Grafcet


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.

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;

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.

768. /* Cdigo modificado */

769. static bool sfcpp_expr_id_last = false;

770. bool sfcpp_expr_id_up, sfcpp_expr_id_down;

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.
if (sfcpp_expr_id != sfcpp_expr_id_last)

778.
{

779.

sfcpp_expr_id_up = (sfcpp_expr_id_last) ? false : true;

780.
sfcpp_expr_id_down = (sfcpp_expr_id_last) ? true : false;

781.
sfcpp_expr_id_last = sfcpp_expr_id;

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.

Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet

/* Cdigo modificado */

// declaracin e iniciacin da varibel auxiliar

const bool sfcpp_timer_id = vm.getTimerState("sfcpp_timer_id");

// 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.
793. /* Cdigo orixinal */

794. expr(X_id)

795.

796. /* Cdigo modificado */

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);

Captulo 6: Compilacin de modelos Grafcet

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.
802. /* Cdigo orixinal */

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)

/* Cdigo modificado */

// declaracin e iniciacin da varibel auxiliar

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

Seccin 6.3: Consideracins sobre a utilizacin de C++ nos modelos Grafcet

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.

/* Cdigo orixinal */

expr(output)

/* Cdigo modificado */

// declaracin e iniciacin da varibel auxiliar

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

Captulo 6: Compilacin de modelos Grafcet

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

/* Cdigo modificado */

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

/* Cdigo modificado */

SFCRTOutput<int> sfcpp_modelvar id;

int var = sfcpp_modelvar_id + 5; // BRROR: expresin ilegal

/* Cdigo modificado */

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

/* Cdigo modificado */

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.

/* Cdigo orixinal */

any_function(output); // funcin que modifica a sada iaternamente

895.
896.
897.
898.
899.

900.
901.
902.
903.
904.

/* Cdigo modificado */

SFCRTOutput<bool> sfcpp_modelvar_id;

any_function(sfcpp_modelvar_id); // BRROR: expresin ilegal

/* Cdigo orixinal corrixido */

bool aux_var;

any_function(aux_var);

output = aux_var;

/* Cdigo corrixido modificado */

SFCRTOutput<bool> sfcpp_modelvar_id;

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.

Captulo 6: Compilacin de modelos Grafcet

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
^ode 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.

Captulo 6: Compilacin de modelos Grafcet

234

RTReceptivityInfo
Clase que representa a informacin de cada receptividade do modelo Grafcet durante a
execucin. Os atributos desta clase son os seguintes:

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
execucin. Os atributos desta clase son os seguintes:

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

execucin. Os atributos desta clase son os seguintes:


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

execucin. Os atributos desta clase son os seguintes:


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

Captulo 6: Compilacin de modelos Grafcet

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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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

Captulo 6: Compilacin de modelos Grafcet

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^ ^ 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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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.

Captulo 6: Compilacin de modelos Grafcet

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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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

Captulo 6: Compilacin de modelos Grafcet

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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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

Captulo 6: Compilacin de modelos Grafcet

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.

Seccin 6.5: Implementacin das fases do compilador Grafcet


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.

Captulo 6: Compilacin de modelos Grafcet

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>;

<condition_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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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^os = buscar_delimitador^revio(code, pos)

1038.// buscar palabra reservada C++ en code(delimJpos, pos]

1039.stbegin, type = buscar^alabra_reservada(code, delim^os, 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^os, pos)

1044.e1se if (type == WHILE)

1045.
// a expresin parte dua wh31e ou dua do while?

1046.
type = while_ou_dowhile(code, delim^os, 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^os = cond_end

type = STATEMENT

end if

1055.end if

1056.// calcular infox^acin de contexto

1057.begin, end, cbegin, cend, code_block = calcular_contexto(code,

type, stbegin,

1058.
delim^os, 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.

Captulo 6: Compilacin de modelos Grafcet

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^os]

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^os]

( 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^os]

1075.[st_begin]<statement_with_complex_event_expression>;

O algoritmo identifica as diferentes posibilidades e corrixe axeitadamente o valor de^inicio


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^os]

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^oos]

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^os].


bs Indicado como [st begin].

249

Seccin 6.5: Implementacin das fases do compilador Grafcet

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^os]
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^os]

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^os]

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

Captulo 6: Compilacin de modelos Grafcet


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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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

Captulo 6: Compilacin de modelos Grafcet


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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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

Captulo 6: Compilacin de modelos Grafcet


^
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):
1218./* Exemplo 1: Expresin orixinal */

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.

1234./* Exemplo 2: Expresin orixinal */

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)

1240.// Sintaxe Sidoni

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

Seccin 6.5: Implementacin das fases do compilador Grafcet

1253.// Sintaxe Sidoni

1254.>(sfcpp_expr_3 + sfcpp_expr_4)
// afcpp_expr_2

1255.<(c + sfcpp_expr_5)
// sfcpp_expr_4

1256./* Subexpresins con eventos aniSadas simplificadas


1257.// Sintaxe Sidoni

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)


1268.[declaracin + iniciacin]

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. }

Captulo 6: Compilacin de modelos Grafcet

256

Instruccin de iteracinfor (3 posicins, tipo = FOR[1 j2J31)


1275.// FOR1

1276.[declaracin + iniciacin]

1277.for(<expression_with_complex_event_expression>;

1278.
<condition>;

1279.
1280.
1281.

<expression>)

<statement>;

1282.// FOR2

1283.[declaracin + iniciacin]

1284.for(<expression>;

1285.
<condition_with_complex_event_expression>;

1286.
<expression>)

1287. {
1288.
<statements>

1289.
[actualizacn]

1290. }

1291.

1292.// FOR3

1293.[declaracin]

1294.for(<expression>;

<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)


1308.[declaracin + iniciacin]

1309.while (<condition_with_complex_event_expression>)

1310 . {

<statements>

1311.
1312.
[actualizacin]

1313 . }

Instruccin de salto return (tipo = RETURN)


1314.[declaracin + iniciacin]

1315.return (<condition_with_complex_event_expression>);

Calquera outra instruccin (tipo = STATEMENT)


1316.[declaracin + iniciacin]

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

Seccin 6.5: Implementacin das fases do compilador Grafcet

1318./* Cdigo orixinal


1319.for(<expression>;

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++]));

1331.for(<expression>;

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

Captulo 6: Compilacin de modelos Grafcet

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. }

1385.for(<expression>;

(^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

1405.static bool sfcpp_expr_1_last = false;

1406.boo1 sfcpp_expr_1_up, sfcpp_expr_1_down;

1407.static bool sfcpp_expr_3_last = false;

1408.boo1 sfcpp_expr_3_up, sfcpp_expr_3_down;

1409.static bool sfcpp_expr_4_last = false;

1410.boo1 sfcpp_expr_4_up, sfcpp_expr_4_down;

1411.static bool sfcpp_expr_5_last = false;

1412.boo1 sfcpp_expr_5_up, sfcpp_expr_5_down;

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

Seccin 6.5: Implementacin das fases do compilador Grafcet

1423.
1424.

// Actualizacin varibeia auxiliares

sfcpp_expr_5 = (bool) (d/3 > b);

1425.

if (sfcpp_expr_5 != sfcpp_expr_5_last)

1426.

1427.
1428.
1429.
1430.
1431.

1432.
1433.
1434.
1435.
1436.
1437.
1438.
1439.

1440.
1441.
1442.

sfcpp_expr_5_up = (sfcpp_expr_5_last) ? false : true;

sfcpp_expr_5_down = (sfcpp_expr_5_last) ? true : false;

sfcpp_expr_5_last = sfcpp_expr_5;

sfcpp_expr_4 = (bool) ((^c && !sfcpp_expr_5) ^^ (sfcpp_expr_5_down && !c));

if (sfcpp_expr_4 != sfcpp_expr_4_last)

sfcpp_expr_4_up = (sfcpp_expr_4_last) ? false : true;

sfcpp_expr_4_down = (sfcpp_expr_4_last) ? true : false;

sfcpp_expr_4_last = sfcpp_expr_4;

sfcpp_expr_3 = (bool) (c > d*3);

if (sfcpp_expr_3 != sfcpp_expr_3_last)

1443.
1444.
1445.
1446.
1447.

1448.
1449.
1450.

1451.
1452.

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;

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)));

if (sfcpp_expr_1 != sfcpp_expr_1_last)

1453.
1454.
1455.
1456.

1457.
1458. }

sfcpp_expr_1_up = (sfcpp_expr_1_last) ? false : true;

sfcpp_expr_1_down = (sfcpp_expr_1_last) ? true : false;

sfcpp_expr_1_last = sfcpp_expr_1;

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.

Captulo 6: Compilacin de modelos Grafcet

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")
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 transicin do
modelo.
6.5.1.8. Procesamento das condicins dos temporizadores ("SFCTimerConditionCompiler")
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 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

Seccin 6.5: Implementacin das fases do compilador Grafcet

(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

Captulo 6: Compilacin de modelos Grafcet

262

1482.// declaracins globais

1483.deque<module^ointer> 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^ointer 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

Seccin 6.5: Implementacin das fases do compilador Grafcet

1547.
1548.
1549.
1550.

if (!var) GESCA_THROW_BAD ALLOC

rtstaticmodel.getDecls().insert(var);

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
if (!var) GESCA_THROW_BAD ALLOC

1573.

rtstaticmodel.getDecls().insert(var);

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^ointer>& getModules(void)

1603 . {

1604.
return modules;

1605 . }

Captulo 6: Compilacin de modelos Grafcet

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

Seccin 6.5: Implementacin das fases do compilador Grafcet

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

Captulo 6: Compilacin de modelos Grafcet

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

Seccin 6.6: Conclusins


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^ointer;

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

Captulo 7: A mquina virtual

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 . } ;

Seccin 7.1: A arquitectura da mquina virtual


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^ointer getModule(const string& type,

const string& name) = 0;

virtual module_iterator addModule(module^ointer 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

Captulo 7: A mquina virtual

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^ointer>& 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^ointer> 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

Seccin 7.1: A arquitectura da mquina virtual

1737.DLL_API void onUnload(void)

1738. {

1739.
for (deque<module^ointer>::iterator module = modules.begin();

1740.
module != modules.end();

^
++module)

delete *module;

modules.clear();

1741.
1742.
1743.
1744 . }

1745.

1746.DLL_API deque<module^ointer>& 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& ^ath);

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.

Captulo 7: A mquina virtual

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

^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

^
^ModuleConfiauration

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

Seccin 7.1: A arquitectura da mquina virtual

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. }

Captulo 7: A mquina virtual


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

Seccin 7.1: A arquitectura da mquina virtual

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);

Captulo 7: A mquina virtual

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

Seccin 7.1: A arquitectura da mquina virtual

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.

Captulo 7: A mquina virtual

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

Seccin 7.1: A arquitectura da mquina virtual

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.

Captulo 7: A 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

Seccin 7.1: A arquitectura da mquina virtual

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

Captulo 7: A mquina virtual


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

Seccin 7.1: A arquitectura da mquina virtual

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 `invocador' poda obter unha referencia vlida ao proceso `invocado',
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 `invocador' 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

Captulo 7: A mquina virtual

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

Seccin 7.1: A arquitectura da mquina virtual

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

Captulo 7: A mquina virtual

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

Seccin 7.1: A arquitectura da mquina virtual

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

Captulo 7: A mquina virtual


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

Seccin 7.1: A arquitectura da mquina virtual

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^aplicacin
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);

Captulo 7: A mquina virtual


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

Seccin 7.1: A arquitectura da mquina virtual

^
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.

Captulo 7: A mquina virtual

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.

Seccin 7.1: A arquitectura da mquina virtual

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.

Captulo 7: A 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

2343. virtual void Start() = 0;

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

Captulo 7: A mquina virtual

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

Seccin 7.2: O subsistema de E/S

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.

Captulo 7: A mquina virtual

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

Seccin 7.2: O subsistema de E/S

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^ort = new DeviceLevel("COM1", IOPOINT, 1);

DeviceInfo* info = new DeviceInfo(com^ort);

2378.

2379.

// velocidade

2380.
2381.
2382.

DeviceCharacteristic<unsigned>*

baud_rate = new DeviceCharacteristic<unsigned>("Baud Rate", 9600);

com^ort->characs.insert(baud_rate);

2383.

2384.

// paridade

2385.
2386.
2387.

DeviceCharacteristic<bool>*

parity_check = new DeviceCharacteristic<bool>("Parity Check", true);

com^ort->characs.insert(parity_check);

2388.

2389.

// nmero de bits, 5-8

2390.
2391.
2392.
2393.
2394.
2395.

DeviceCharacteristic<unsigned>*

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^ort->characs.insert(num_bits);

2400.

DeviceCharacteristic<unsigned>*

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);

DeviceSingleValue<unsigned>*

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();

DeviceSingleValue<unsigned>*

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

Captulo 7: A mquina virtual

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^ort->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
`Ildd_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

Seccin 7.2: O subsistema de E/S

^ > ^^
_' ^
^ ^ E
ffi

F
N

F>I
Ui

N
N
t
U

q
L
U

L
U

O
^
J

m
^ II

.^

^^ ^I
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.

Captulo 7: A mquina virtual

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

Seccin 7.2: O subsistema de E/S

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)