ESCOLAPOLITÉCNICA/INSTITUTODEMATEMÁTICA
PROGRAMADEPÓS-GRADUAÇ O EMMECATRÔNICA
SANDRO SANTOS ANDRADE
SISTEMAS DISTRIBUÍDOS DE SUPERVIS O E CONTROLE
BASEADOS EM COMPONENTES DE TEMPO-REAL
Salvador
SISTEMAS DISTRIBUÍDOS DE SUPERVIS O E CONTROLE
BASEADOS EM COMPONENTES DE TEMPO-REAL
Dissertação apresentada ao Programa de Pós-Graduação em
Me atr ni a, Es ola Polité ni a / Instituto de Matemáti a,
Universidade Federal da Bahia, omo requisito par ial para
obtenção dograu de Mestre emMe atr ni a.
Orientador: Prof. Dr. Raimundo José de AraújoMa êdo.
Salvador
A553 Andrade,SandroSantos.
Sistemasdistribuídosdesupervisãoe ontrolebaseadosem omponentesdetempo-real/
SandroSantosAndrade. -2006.
216f. ;il.
In luiapêndi e.
Orientador: Prof. Dr. RaimundoJosédeAraújoMa êdo.
Dissertação(mestrado)-UniversidadeFederaldaBahia,Es olaPolité ni a, Instituto
deMatemáti a, 2006.
1. Programaçãoemtempo-real. 2. Engenharia desoftware. 3.Framework(programade
omputador).4. Software-Reutilização. 5. Me atr ni a. I.Ma êdo,RaimundoJoséde
Araújo. II.UniversidadeFederaldaBahia. Es olaPolité ni a. III.UniversidadeFederaldaBahia.
InstitutodeMatemáti a. IV.Título.
CDU-519.68
SANDRO SANTOS ANDRADE
SISTEMAS DISTRIBUÍDOS DE SUPERVIS O E CONTROLE
BASEADOS EM COMPONENTES DE TEMPO-REAL
Dissertação aprovada omo requisito par ial para obtenção do grau de
Mestre em Me atr ni a, Universidade Federal da Bahia, pela seguinte
ban a examinadora:
RaimundoJosé de AraújoMa êdo - Orientador
Ph.D.,UniversityofNew astleuponTyne,Inglaterra.
ProfessorTitulardoDepartamentodeCiên iadaComputação(DCC)daUniversidadeFederaldaBahia.
JonidaSilva Fraga
Doutor,InstitutNationalPolyte hniquedeToulouse (INPT),França.
ProfessorTitulardoDepartamento deAutomaçãoeSistemas(DAS)da Universidade Federal deSanta
Catarina.
Jean-MarieFarines
Doutor,InstitutNationalPolyte hniquedeToulouse (INPT),França.
ProfessorTitulardoDepartamento deAutomaçãoeSistemas(DAS)da Universidade Federal deSanta
Catarina.
Lu ianoPorto Barreto
Doutor,UniversitédeRennes,França.
ProfessorAdjuntodoDepartamentodeCiên iadaComputação(DCC)daUniversidadeFederaldaBahia.
meuspais, Dil ee Geraldo,por terem semprea reditado e on ado emmim.
meu lho,Benjamin, pelolindosorriso en orajadorepeloeternopresentedasua
Àvidaquemefoi on ebidae on edida,fruti adorade tantasoportunidadespara
res- er e ven er desa os. Veí ulo para a on retização de sonhos tantos, in ndáveis ... que
justi amos per alçosque permeiamo nosso aminho.
A minha mãe, Dil e Domingas dos Santos, pelo apoiosempre presente emtudo. A meu
pai,GeraldoGalvãode AndradeFilho,peloamor desempreepelas perguntas onstantes
de "Comovaio mestrado ?".
A Dedéa, pelo ompanheirismo, ompreensão eamor que afazem aluzda minhavida.
A Andréa Amorim, pelos onstantes in entivos ao mundo a adêmi o e pelo fruto mais
pre iosonesse períododa minhavida.
A Raimundo José de Araújo Ma êdo, pela ex elente orientação e a ompanhamento do
trabalho, pelo zelo da relação orientando/orientador e pela ompreensão e amizade de
sempre.
A Mar elo Embiruçu de Souza, pela disponibilidade e pela inigualável apa idade e boa
vontade em ensinare ontribuirpara o su esso dotrabalho.
À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), pelo apoio
nan eiro.
Aos professores, se retárias e olegas do Programa de Pós-Graduação em Me atr ni a
(PPGM) da UFBa,pelaboa onvivên ia durante o período. Agrade imentos espe iais a
So orro, Lú ia, Rebe a e Carmen, pela atenção dispensada e por tornarem tudo muito
mais fá ilno de orrer doprojeto.
Aosprofessores: Herman Lepkinson,pelasimpatiaepeloapoiode sempre,Leizer
S hnit-man, pelaajuda ini ial om o CLP e om as teorias de ontrole, Lu iano Porto Barreto,
por não me deixar o TAO passar desper ebido e Augusto Loureiro, pela ajuda om a
tentativa de uso das pla as.
A toda a equipe do DOC (Distributed Obje t Computing) Group da University of
Ca-lifornia, IrvineeWashington University,emespe ial aDr. Douglas S hmidt,Gan Deng,
WilliamOtte,Nanbor Wang, TomRitter, Je Parsons, Ming Xionge Jaiganesh
Balasu-bramanian.
Ao olegaClaudioWakabaiashi,pelastentativasdemontagemdoexperimentode ontrole.
idéias.
A Fabíola Greve, João Gualberto e toda a equipe do projeto Compose, realizado pelo
CPD da UFBa, pela oportunidade de realização de um ex elente trabalho, responsável
pelamaturidade dos on eitos de engenhariade software apli adosneste trabalho.
A Ro kwell Automation pelos kits didáti os, CLP's e treinamentos realizados no
Cen-trode Capa itação em Automação Industrialda UFBa, indispensáveis para a realização
destetrabalho.
Universo,nãopoderiahaver iên ia. Esta onvi ção
é, e ontinuará a ser, a base de toda a riação
ientí a. Em toda a extensão dosnossos esforços,
naslutasdramáti asentre asvelhaseasnovas
on- epções,entrevemosaânsia eternade ompreensão,
aintuição inabalável daharmoniauniversal, quese
robuste e na própria multipli idade dos obstá ulos
queseofere emaonossoentendimento."
O desenvolvimento dos primeirossistemas industriais de tempo-real foi ara terizado
pela utilização de soluções proprietárias e de té ni as ad-ho , om o objetivo
primor-dial de atender os requisitos de on abilidade e previsibilidade temporal impostos pelo
ambiente. Com a evolução das te nologias de pro essamento e omuni ação, demandas
rela ionadas a distribuição, exibilidade, extensibilidade, adaptação, uso de algoritmos
inteligentes, interoperabilidadee reutilização,passaram aser onsideradas. A abordagem
tradi ional, ara terizada pela utilizaçãode CLP's (Controladores Lógi o-Programáveis)
e de programas es ritos na linguagem LADDER, onstitui um entrave para a
imple-mentação dessas novas demandas, devido a restrições substan iais nas apa idades de
pro essamento, armazenamento e one tividade. Umaalternativa é a utilizaçãode
om-ponentes COTS (Commer ial O-The-Shelf) de hardware e software, reduzindo ustos,
fa ilitando questões de interoperabilidade e fazendo uso de uma infra-estrutura
ompu-ta ional mais poderosa. Nesse enário, soluções extensivamente baseadas em software
possibilitamautilizaçãode te nologias,paradigmas emetodologiasparaa onstruçãode
sistemas exíveis, reutilizáveiseinteroperáveis, tais omo aorientaçãoaobjetos,padrões
de projeto (design patterns), soluções de middleware, frameworks e omponentes
distri-buídos de software. Esta dissertação apresenta o projeto e implementação do ARCOS,
umaplataformabaseada em omponentes de software dedi ada à onstrução de sistemas
distribuídosdesupervisãoe ontrole, omfa ilidadesparareutilização,interoperabilidade
e espe i ação de restrições temporais. O ARCOS de ne e implementaserviços para as
atividadesdeaquisiçãodedados, ontroleesupervisão,disponibilizandoumasolução
par- ialereutilizávelem umavariedadede apli açõesindustriais. Sãoapresentados oprojeto
dessesserviços, om ênfase naadoção dopadrão DAIS (Data A quisitionfrom Industrial
Systems) para interoperabilidade, bem omo as soluções rela ionadas à previsibilidade
temporal da plataforma. Aspe tos de implementação são dis utidos e são apresentadas
duas apli açõesde validação onstruídas sobre aplataforma ARCOS: um sistema
super-visóriopara monitoramentode um reatorquími oeum sistemapara ontrole PIDde um
pilotoautomáti o. Oprojeto ontemplaaindaaimplementaçãode umambientegenéri o
para aquisição de dados (o DAIS Server Browser) e de uma ferramenta de auxílio ao
desenvolvimento de novasapli ações baseadas noARCOS (oARCOS Assembly Tool).
Palavras- have: sistemas industriais de supervisão e ontrole, sistemas de tempo-real,
desenvolvimentobaseadoem omponentesdistribuídos,frameworksparasistemasde
The development of the an ient industrialreal-timesystems was hara terized by the
useof proprietarysolutionsand ad-ho te hniques,whi haimedtoaddressthe reliability
and temporal predi tability requirements imposed by the operational environment. As
hardware and ommuni ationte hnologiesbe amemore powerful,the demands in terms
ofdistribution, exibility,extensibility,adaptivebehaviour, intelligentalgorithms,
intero-perability,andreusability,begantobe onsideredwhendesigningsu hindustrialsystems.
The lassi alapproa h, hara terizedby the useof PLC's (ProgrammableLogi
Control-lers)andsoftwarewrittenintheLADDERprogramminglanguage, onstitutesanobsta le
forthe implementation ofsu h new demands, due to onstraints relatedto omputation,
storage,and onne tivitypower. ApromisingalternativeistheuseofCOTS(Commer ial
O-The-Shelf)hardware andsoftware omponents,whi hsaves osts, enhan es
interope-rability a hievement, and relies onamore powerful omputationalinfrastru ture. In this
s enario, sofware-intensive solutions allow for the use of te hnologies, paradigms, and
methodologies that leverage the a hievement of exibility, reusability, and
interoperabi-lity,su h as the obje t-oriented programming, design patterns, middleware, frameworks,
anddistributed omponents. Thisdissertationpresents thedesignandimplementationof
ARCOS,a omponent-basedsoftwareplatformdevotedtothe onstru tionofsupervision
and ontrol distributed systems, with fa ilitiesfor reusability, interoperability, and
spe- i ation of temporal onstraints. ARCOS de nes and implements servi es for a tivities
related to industrial data a quisition, ontrol, and supervision, providing a par ial and
reusable solution for a range of industrial appli ations. We present the design of these
servi es, fo using on the adoption of DAIS (Data A quisition from Industrial Systems)
standard, as well as the solutionsrelated to the temporal predi tability of our platform.
Wealsodis ussimplementationissuesand presenttwo appli ationsbuiltatopARCOS:a
supervisory system for a hemi al rea torand a system for a ruise PID ontrol system.
Our proje t en ompass the implementation of a generi environment for industrial data
a quisition(the DAIS ServerBrowser)and adevelopment tooldevoted tothe
implemen-tationof new ARCOS-based real-timeappli ations(the ARCOS Assembly Tool).
Keywords: supervision and ontrol industrial systems, real-time systems,
1.1 Níveistípi osdeumsistemaindustrialdesupervisãoe ontrole. . . 7
2.1 Comuni açãodepro essosatravésdoRPC . . . 13
2.2 Comuni açãodepro essoseutilizaçãodeserviçosatravésdoORB . . . 13
2.3 Prin ipaiselementosdaarquiteturaCORBA2.x . . . 15
2.4 Modelode omponentesdoCCM . . . 19
2.5 Desenvolvimentobaseadoembibliote asedesenvolvimentobaseadoemframeworks . . . 28
2.6 Framework horizontaleframework verti al . . . 29
2.7 IntegranteseutilizadoresdoACE . . . 31
2.8 AarquiteturaOSA+. . . 32
2.9 Estruturabási adeumTMO . . . 34
2.10 Abordagemtradi ionaldoCORBA2.xparademultiplexaçãoderequisições . . . 36
2.11 Interfa esproxy para omuni açãodeprodutorese onsumidores . . . 40
2.12 EstruturainternadoServiçodeEventosdeTempo-RealdoTAO . . . 44
2.13 ObjetosdoDAnCEenvolvidosnopro essodeimplantaçãoe on guração . . . 49
2.14 ObjetivosdoDAIS . . . 53
2.15 Diagramadeseqüên iadopro essodeaquisiçãodedadosnoDAIS. . . 56
3.1 OARCOSesuaste nologiassubja entes . . . 61
3.2 OServiçodeEventosdeTempo-Real omoelementointegradordos omponentesdeaquisiçãode dados, ontroleesupervisãodoARCOS . . . 62
3.3 Diagramasimpli adodosobjetosde nidospelaespe i açãoDAIS . . . 63
3.4 Diagramados omponentesDAISpropostosparaoARCOS . . . 64
3.5 Diagramadeseqüên iaapresentandoainversãode ontrolerealizadapeloARCOSna onstrução daárvoreDAIS . . . 68
3.6 Diagramadeseqüên ia apresentandoainversãode ontrolerealizada peloARCOSnaaquisição dedados . . . 69
3.7 Implementaçãodohot-spot deaquisiçãodoARCOSeas relaçõesdomódulodeaquisição omo ServiçodeEventosdeTempo-Real. . . 70
3.8 Diagramados omponentesde ontrolepropostosparaoARCOS. . . 72
3.9 Diagramadeseqüên iaapresentandoainversãode ontrolerealizadapeloARCOSnarealização dasatividadesde ontrole . . . 76
3.10 Implementação dohot-spot de ontroledo ARCOS e as relaçõesdo módulo de ontrole omo ServiçodeEventosdeTempo-Real. . . 77
3.11 ARCOSManagementTool . . . 80
3.12 VisualizadordoServidordeNomes,disponibilizadopeloARCOSManagementTool . . . 82
3.13 VersãowebdoDAISServerBrowser . . . 83
3.16 Criaçãodeumanovainstân iade omponenteapartirde omponenteshome . . . 90
3.17 Criaçãodeumanovainstân iade omponenteutilizandooReDaC,viaprogramação . . . 93
3.18 Implementaçãodoloop deaquisiçãoatravésdousodoseventosdetimeout . . . 98
3.19 Implementaçãodos omponentesDAISDAGroupManager e DAISDAGroupClo k . . . 99
3.20 Usoda lasseDAISFa ade paraimplementaçãode lientesDAIS . . . 101
3.21 Espe i açãodosparâmetrostemporaisdeumgrupoDAIS. . . 102
4.1 Estruturadediretóriosdopa otedeinstalaçãodoARCOS . . . 107
4.2 AssemblyView doARCOSAssemblyTool . . . 122
4.3 ProviderView doARCOSAssemblyTool . . . 123
4.4 ControllerView doARCOSAssemblyTool . . . 124
4.5 Des riptor View doARCOSAssemblyTool . . . 126
4.6 Instrumentaçãodoreatorquími o . . . 127
4.7 Kit didáti oeCLPutilizados noexperimentodesupervisãodoreatorquími o . . . 129
4.8 Exe ução,nokit didáti o,dopro edimentodoreatorquími o . . . 130
4.8 Exe ução,nokit didáti o,dopro edimentodoreatorquími o( ontinuação) . . . 131
4.9 Ligaçõeselétri asentreokit didáti oeoCLP . . . 132
4.10 Parti ipantesdoexperimentodoreatorquími o . . . 132
4.11 ÁrvoreDAISprojetadaparaoDAISEthernetPLCProvider . . . 133
4.12 Supervisãodoreatorquími oatravésdoDAISServer Browser . . . 135
4.13 Supervisãodoreatorquími oatravésdosupervisórioespe í o . . . 136
4.14 ControlePIDdavelo idadedoveí ulo. . . 137
4.15 ÁrvoreDAISprojetadaparaoDAISSimulatedCarProvider . . . 138
4.16 Controlador dopilotoautomáti odoARCOS . . . 140
4.17 Atrasonaentregademensagens omoes alonamentoRMS . . . 142
4.18 Atrasonaentregademensagens omoes alonamentoMUF . . . 143
2.1 Diferenças on eituaisentreobjetose omponentes . . . 19
2.2 Categorias de omponentesemrelaçãoaoseu i lodevida . . . 24
2.3 Formasdistintasparaleituraees ritadedadosnoDAIS . . . 53
3.1 Sumáriodos omponentesARCOSparaaquisiçãodedados . . . 66
4.1 RamosdaárvoreDAISde nidapeloDAISEthernetPLCProvider . . . 133
2.1 ExemplodearquivoIDL . . . 22
2.2 ExemplodearquivoCIDL . . . 23
2.3 Exemplodearquivodes ritordeimplantação . . . 26
2.4 Exemplode riaçãodetarefadetempo-realnoOSA+ . . . 33
2.5 Espe i açãoderequisitos temporaisnoOSA+ . . . 33
2.6 Espe i açãoderequisitos temporaisnoTMOSM. . . 35
2.7 Exemplodeespe i açãoderequisitostemporaisnoTMOSM . . . 35
2.8 Espe i açãoderequisitos temporaisnoTAO . . . 38
2.9 Interfa esparaimplementaçãodeprodutorese onsumidoresdoCOSEvent Servi e . . . 39
2.10 Interfa esparaobtençãodosproxies deprodutores e onsumidorespush . . . 40
2.11 Proto olopadrãopara onexãode onsumidorespush . . . 40
2.12 Proto olopadrãoparaenviodemensagensatravésdeprodutorespush . . . 41
2.13 Proto olopara onexãode onsumidorespush noServiçodeEventosdeTempo-Real . . . 42
2.14 PassosparaimplantaçãodeumamontagemnoDAnCE . . . 49
2.15 Exemplodemapadenósparaumdeterminadodomíniodeimplantação . . . 50
2.16 ExemplodereimplantaçãoatravésdoPlanLaun her . . . 51
2.17 Exemplodereimplantaçãovia ódigo. . . 51
3.1 ArquivoIDLdainterfa eIDAISProviderBaseFa et espe i adapeloARCOS . . . 67
3.2 Espe i andoumnovoDAIS Provider . . . 67
3.3 ArquivoIDLdo omponente DAISServer espe i adopelo ARCOS. . . 71
3.4 Conexãodo omponenteDAISServer omumDAISProvider espe í o . . . 71
3.5 ArquivoIDLdainterfa eIControllerBaseFa et espe i adapeloARCOS . . . 74
3.6 Espe i andoumnovo ontrolador . . . 74
3.7 ArquivoIDLdo omponente ControlManager espe i adopelo ARCOS . . . 78
3.8 Conexãodo omponenteControlManager omum ontroladorespe í o . . . 79
3.9 EstruturaIDLrepresentandooplanodeimplantação . . . 93
3.10 EstruturaIDLrepresentandoumainstân iadoplanodeimplantação . . . 94
3.11 ClasseReDaCUtils paramanipulaçãodoplanodeimplantação . . . 95
3.12 ClasseDAISFa ade paraimplementaçãode lientesDAIS . . . 103
4.1 AlteraçõesaseremrealizadasnoarquivoMPCdonovoDAIS Provider. . . 111
4.2 AlteraçõesaseremrealizadasnoarquivoMPCdonovo ontrolador. . . 114
4.3 Exemplodedes ritordeimplantaçãoparaaquisiçãodedadosviaCLP e ontrolePID . . 115
4.4 Template utilizadopeloAST para riaçãodeumnovoDAIS Provider . . . 125
4.5 ClassequeimplementaoARCOSTemplate Engine . . . 125
4.6 ArquivoIDLdo omponente DAISSimulatedCarProvider . . . 138
4.7 ArquivoIDLdo omponente PIDController . . . 139
B.2 Gerandoosmake les apartirdeumarquivode on guraçãodoMPC . . . 167
B.3 Geraçãoautomáti adeumarquivode on guraçãodoMPC . . . 168
E.1 ComponenteDAISServer . . . 175
E.2 ComponenteDAISDASession . . . 175
E.3 ComponentesDAISDANodeHome eDAISDANodeIterator . . . 176
E.4 ComponentesDAISDAGroupHomeDAISDAGroupManager DAISDAGroupClo ke DAIS-DAGroupEntryIterator . . . 177
E.5 Interfa eIDAISProviderBaseFa et . . . 178
E.6 ComponenteDAISEthernetPLCProvider . . . 179
E.7 ComponenteDAISSimulatedCarProvider . . . 179
E.8 Interfa esA essPoint . . . 179
E.9 TipodeeventoEControlData . . . 180
E.10ComponenteControlManager . . . 180
E.11ComponenteControlManagerDAISCallba k . . . 181
E.12Interfa eIControllerBaseFa et . . . 181
ABEL AllenBradleyEthernet Library
ACE ADAPTIVECommuni ationEnvironment
ACCORD AspeCtualCOmponentbasedReal-timesystemDevelopment
ADAPTIVE ADynami allyAssembledProto olTransformation,Integration,
andeValuationEnvironment
AMT ARCOSManagementTool
API Appli ationProgramInterfa e
ARCOS ARquiteturaparaCOntroleeSupervisão
AST ARCOSAssemblyTool
CCM CORBAComponentModel
CIAO Component-IntegratedACEORB
CLP ControladorLógi o-Programável
CNC ComputerNumeri alControl
CORBA CommonObje tRequestBrokerAr hite ture
COS CommonObje tServi es
COTS Commer ialO-The-Shelf
CVS Con urrentVersioning System
DAIS DataA quisitionfromIndustrialSystems
DAnCE DeploymentAndCon gurationEngine
DCOM DistributedCOMponents
EDF EarliestDeadlineFirst
EJB EnterpriseJavaBeans
FIFO First-InFirst-Out
FMC FlexibleManufa turingCell
GIOP GeneralInter-ORBProto ol
IDE IntegratedDevelopmentEnvironment
IDL Interfa eDe nitionLanguage
IIOP InternetInter-ORBProto ol
IOR InteroperableObje tReferen e
IPC Inter-Pro essCommuni ation
MMS Manufa turingMessageSpe i ation
MUF MaximumUrgen yFirst
ORB Obje tRequestBroker
OSA+ OpenSystemAr hite turePLatformforUniversalServi es
PID Propor ionalIntegralDerivativo
QoS QualityofServi e
QuO QualityObje ts
RCCF Real-timeComponentCustomizationFramework
ReDaC ReDedeploymentandreCon guration
RIDL Real-timeInterfa eDe nition Language
RIOP Real-timeInter-ORBProto ol
RMI RemoteMethod Invo ation
RMS RateMonotoni S heduling
RPC RemotePro edureCall
SCADA SupervisoryControlAndDataA quisition
TAO TheACEORB
TMO Time-TriggeredMessage-TriggeredObje t
UUID UniversalUnique IDenti er
1 Introdução 1
1.1 Opapeldosoftwarenaindústria . . . 2
1.2 Componentesdesoftware . . . 4
1.3 Sistemasindustriaisdesupervisãoe ontrole. . . 5
1.4 Motivação eobjetivos . . . 7
1.5 Estruturadadissertação . . . 10
2 Plataformas e Serviços de Tempo-Real 12 2.1 Middlewareesistemas detempo-real . . . 12
2.1.1 CORBA(CommonObje tRequest BrokerAr hite ture) . . . 13
2.2 Componentesesistemasdetempo-real . . . 16
2.2.1 CCM(CORBAComponentModel) . . . 19
2.2.1.1 Omodelode omponentes . . . 20
2.2.1.2 ArquivosIDLeCIDL . . . 21
2.2.1.3 Des ritoresdeimplantação . . . 24
2.3 Frameworksesistemas detempo-real. . . 27
2.3.1 Frameworks . . . 27
2.3.2 ACE(ADAPTIVECommuni ationEnvironment) . . . 30
2.4 Abordagembaseadaemobjetos . . . 32
2.4.1 TAO(TheACEORB) . . . 35
2.4.1.1 Serviçodees alonamento . . . 37
2.4.1.2 Serviçodeeventosdetempo-real . . . 38
2.4.1.3 Oframework Kokyu . . . 43
2.5 Abordagembaseadaem omponentes. . . 45
2.5.1 CIAO(Component-IntegratedACEORB). . . 46
2.5.1.1 DAnCE (DeploymentandCon gurationEngine). . . 46
2.5.1.2 ReDaC (RedeploymentandRe on guration) . . . 50
2.6 DAIS(DataA quisitionfromIndustrialSystems). . . 52
3 ARCOS -ARquitetura para COntrole eSupervisão 57 3.1 ObjetivosdoARCOS . . . 57
3.2 Omodelo . . . 62
3.2.1 Aquisiçãodedados . . . 63
3.2.1.1 Hot-spotdeaquisiçãodedados. . . 65
3.2.2 Controle . . . 72
3.2.2.1 Hot-spotde ontrole. . . 73
3.2.3.2 DAISServerManager . . . 82 3.3 A implementação . . . 82 3.3.1 Requisitosdesoftware . . . 84 3.3.2 Históri o . . . 86 3.3.2.1 1 a solução: utilizaçãodeobjetosCORBA2.x . . . 86
3.3.2.2 2 a solução: utilizaçãode omponenteshome . . . 89
3.3.2.3 3 a solução(atual): utilização doReDaC . . . 91
3.3.3 ARCOS,DAnCEeReDaC . . . 92
3.3.3.1 A lasseReDaCUtils . . . 95
3.3.4 MPC(MakeProje tCreator) . . . 97
3.3.5 Implementaçãodosmódulos. . . 97
3.3.5.1 Aquisiçãodedados . . . 98
3.3.5.2 Controle . . . 100
3.3.5.3 Supervisão . . . 100
3.4 ARCOSeme anismosbási osparatempo-real . . . 102
4 Desenvolvimento de Apli açõesBaseadas no ARCOS 106 4.1 InstalandooCIAOeoARCOS . . . 106
4.2 Espe ializandooARCOS . . . 108
4.2.1 ImplementandoumnovoDAISProvider . . . 110
4.2.2 Implementandoumnovo ontrolador. . . 112
4.2.3 Con gurandoamontagemdosistema . . . 113
4.3 ARCOSAssembly Tool . . . 121
4.3.1 ARCOSTemplate Engine . . . 123
4.4 Apli açõesexemplo. . . 126
4.4.1 Experimento1: supervisãodeumreatorquími o . . . 126
4.4.1.1 Des rição dopro esso . . . 127
4.4.1.2 Implementação . . . 128
4.4.2 Experimento2: ontrolePIDparapilotoautomáti o . . . 136
4.4.2.1 Des rição damalhade ontrole. . . 137
4.4.2.2 Implementação . . . 137
4.5 Avaliaçãodaplataforma . . . 141
4.6 TrabalhosCorrelatos . . . 144
5 Con lusõeseTrabalhos Futuros 147 5.1 Con lusões . . . 147
5.2 Trabalhosfuturos . . . 150
5.3 Publi ações . . . 152
Referên iasBibliográ as 156
A Des ritorXML de implantação 162
B MPC(Make Proje t Creator) 166
C Implementandoum omponenteno CIAO 169
F Programa LADDERpara supervisãodo reatorquími o 183
Introdução
A
me atr ni aganhou legitimidadenaa ademiaem1996,apartirdapubli açãodaprimeira ediçãodoIEEE/ASMETransa tions onMe hatroni s."AMe atr ni aéaintegraçãosinérgi ada
engenha-riame âni a omaeletr ni aeo ontrole
omputa-dorizado inteligente, apli ada ao projeto e
manufa-turade produtos epro essosindustriais."
Auslander,1996[4℄
A Me atr ni a integra aEngenharia Me âni a, a Engenharia Elétri a ea Ciên ia da Computação,
omo objetivo prin ipal de desenvolver soluções otimizadas e inteligentes para apli ação na indústria
[11℄. Essastrêsáreas onstituintessurgirameevoluírameminstantesdistintosdahistória.
ComaRevoluçãoIndustrial,ini iadanaInglaterranasegundametadedosé uloXVIII,aEngenharia
Me âni a sebene ia de invenções, omo amáquina a vapor, epromove um onsiderávelaumento na
produtividadeequedanospreçosdosprodutosmanufaturados. Ainvençãodopára-raios,porBenjamin
Franklin em 1752, ara teriza o iní io do uso da energia elétri a em benefí io do homem. A
mi ro-eletr ni a,entretanto,sóse onsolidouquasedoissé ulosdepois, omosurgimentodasválvulasadiodo,
em1940edostransistors,em1950. Como onseqüên iadessesavanços,em1964surgemos omputadores
dater eirageração,baseadosem ir uitosimpressosenaarquiteturapropostaporJohnvonNeumann.
À medida em que a Engenharia Elétri a disponibilizava soluções que permitiam a onstrução de
máquinas adavezmaispoderosas,aCiên iadaComputaçãoestudava,dentreoutrosaspe tos,prin ípios
emetodologiaspara odesenvolvimento de sistemas omputa ionais ada vez mais orretos, ompletos,
fá eisdemantereintegráveis. Nota-se,todavia,queareal ontribuiçãodaCiên iadaComputaçãopara
oprojetoedesenvolvimentodesistemasme atr ni osaindaémodesta,se omparada omasdasoutras
duasáreas onstituintes [85℄.
Nosúltimosanos,as onstantesevoluçõesdaste nologiasdehardwareede omuni açãotêm
modi - adosigni ativamenteasmetodologiaseté ni asutilizadasnodesenvolvimentodesistemas
res e onsideravelmenteàmedidaemquenovasfun ionalidadespassamaserpassíveisde
implementa-ção. Além dessasnovasfun ionalidades, requisitos tais omo distribuição, exibilidade,extensibilidade,
adaptação,usodealgoritmosinteligentes, interoperabilidadeereutilização passamaser onsideradose
ousodeme anismosparageren iaressa res ente omplexidadesetornamandatório.
Noambiente industrialnão édiferente: autilizaçãodesoluçõesbaseadasemsoftwaretemsido ada
vez mais onsideradano projeto edesenvolvimento desistemas industriais. Em onjunto omosnovos
requisitosa ima itados, ane essidade desoluçõestolerantesa falhase temporalmente previsíveistem
demandadoimportantes pesquisas voltadaspara aapli açãode té ni asdaengenhariade softwarenos
sistemasindustriaisdetempo-real.
Este apítuloabordao ontexto,motivaçãoeobjetivosdestadissertação,atravésdaapresentaçãodo
papeldosoftwarenaindústriae,emparti ular,nossistemasindustriaisdesupervisãoe ontrole.
1.1 O papel do software na indústria
A utilização, pela indústria, de soluções baseadas em software expandiu-se em 1968 quando os
Con-troladoresLógi o-Programáveis(CLP's)passaramasubstituir ospainéisde relays, utilizadosaté então
nospro essosde automaçãode fábri as. Essespainéis eramformadospor entenas ou atémilhares de
dispositivosme âni os (relays) one tados uns aos outros atravésde os, impli ando em manutenções
onstantes egeralmente realizadasaaltos ustos. Oprimeiro CLP utilizado omer ialmente foi o
MO-dular DIgital CONtroller (MODICON) desenvolvidopela Bedford Asso iates para usoem uma grande
ompanhiaameri anade produção de automóveis[35℄. Oobjetivoeradisponibilizar uma solução om
manutençãofa ilitadaerobustaemrelaçãoàsintempéries doambienteindustrial.
Emmeados dadé adade70 surgiramosprimeirosesforçosparaaadoçãoderedes de omuni ação
na indústria. O primeiro sistema de omuni ação industrial foi oModbus, utilizadopelo já onhe ido
MODICON,possibilitandoatro ademensagensentreCLP'seo ontrolededispositivosgeogra amente
distantes. Neste mesmoperíodo, osCLP's passarama trabalhar om voltagens variáveis, sendo então
utilizadosemsituaçõesondeinformaçõesanalógi aserammanipuladas[35℄. Poroutrolado,aausên iade
padronizaçõesea onstanteevoluçãodosequipamentosdi ultavamainteroperabilidadena omuni ação
entre CLP's. Na dé ada de 80 surgiram os primeiros trabalhos para padronização dos proto olos de
omuni ação e para o desenvolvimento de ferramentas para programação de CLP's através dos PC's
(Personal Computers),operaçãoatéentãorealizadaporterminaisdedi ados deprogramação. Osanos
90foram ara terizadospormelhoriasnosproto olosde omuni açãomaisutilizadosepelapossibilidade
deprogramaçãodeCLP's emlinguagenstradi ionais omo,porexemplo,alinguagemC.
solução onstituem entravesparaodesenvolvimento desistemas industriais modernos. Devido aos
res-tritosre ursosdamaioriadosCLP's, emrelaçãoà apa idadedearmazenamento,poder omputa ional
e omuni ação,asuaprogramaçãoégeralmenterealizadadeformaad-ho e omoobjetivodesatisfazer
requisitosfun ionaisedeambiente,espe í osdeumasituaçãoemparti ular. Aausên iadeusode
me-todologiasedeté ni asdaengenhariadesoftwareemsoluçõesbaseadasemCLP'sétambémjusti ada
pelopapelsimpleserestritodesempenhadoportais sistemas,geralmenteen arregadosdefe harmalhas
de ontroleouimplementarsistemasdeautomaçãoatravésdeimplementaçõesmono-programadase
exe- utadasdeforma í li a. Comanovademandaporsistemasindustriais exíveis,extensíveis,adaptativos,
inteligentes,interoperáveisereutilizáveis,novaspesquisasvêmsendorealizadas omointuito deapli ar
té ni asdaengenhariadesoftware,jáutilizadasemsistemas onven ionais,nossistemasindustriaise
sis-temasdetempo-real[84,85,105℄. Taissoluções,entretanto,requeremumainfra-estrutura omputa ional
quesuportesuasdemandasporpro essamento,armazenamento(prin ipalese undário)e omuni ação.
Umatendên iaatualéautilizaçãode omponentesdeprateleira(Commer ialO-The-Shelf -COTS),
eem parti ularPC's,noprojetoeimplementaçãodesistemasindustriais [35℄. A apa idadede
pro es-samento earmazenamento dos omputadoresatuais, em onjunto om asfa ilidadesde omuni açãoe
one tividade,tem ontribuídopara osurgimentode pesquisas interessadasnautilizaçãode PC's omo
infra-estruturapara soluçõesindustriais baseadasem software. Por outro lado, a baixa on abilidade
dohardwareemrelaçãoàsfalhaseàsintempériesdoambiente,aliadoàimprevisibilidadetemporal
au-sadaporsoluções omplexasdesoftware,representamosprin ipaisdesa os paraa on retizaçãodessas
pesquisas.
Portanto,adisponibilizaçãodeumainfra-estrutura omputa ionalede omuni açãomaispoderosaé
fatorfundamentalparaodesenvolvimentodesistemasindustriaismodernos,osquaisrequerem
metodo-logiaseté ni asparageren iara omplexidade ausadapelosnovosrequisitos. Aengenhariadesoftware
éa áreada Ciên ia daComputação responsável pelo estudo edesenvolvimento de metodologiase
te -nologiasque propi iama onstruçãodesistemas omplexosmantendo,ao mesmotempo,fa ilidadesde
manutenção,reutilizaçãoees alabilidade 1
,dentreoutras. Diversaste nologiastêmsidoutilizadas omo
objetivodegeren iara res ente omplexidadedossistemaseoatendimentodosnovosrequisitos.
Pes-quisasre entes[43,44℄estudamadaptaçõesdasté ni asdaengenhariadesoftwareparaousoefetivoem
sistemasindustriaisedetempo-real,desta andoousodemiddleware[18,84℄,modelosarquiteturais[93℄,
frameworks [10,58℄,padrõesdeprojeto(design patterns)[87℄,orientaçãoaaspe tos[110℄e omponentes
desoftware[30,82℄.
1
Capa idade deumsistemanãoter seudesempenhodegradadoexponen ialmente nomomentoemque surgemnovas
1.2 Componentes de software
Hámuito tempo investigam-semeios para "industrializar"o pro essode desenvolvimento de software.
Osu essoapresentado pelas linhas industriais de montagemde automóveis, bem omo aprodução
pa-dronizadadepla asde ir uitoseletr ni os,serviramdeinspiraçãoparatentativasdeadaptaçãodessas
estratégiasparausonodesenvolvimentodesistemas. Componentesdesoftwareéate nologiaque
possi-bilitaa onstruçãodesistemas omputa ionaisapartirda onexãoe on guraçãodepeçasdesoftware
fun ionaisereutilizáveis( omponentes)[45,34,54,83,99℄. Algunsbenefí iossurgem omo onseqüên ia
imediatadessaabordagem,asaber:
Produtividade: o levantamento de té ni as que permitem areutilização de soluções éuma
preo- upação onstante daengenhariade software,desde asimplesmodularizaçãode programasatéo
usode omponentesdistribuídos. Aexistên iadeumrepositóriodesoluções,implementadassoba
formade omponentes,alavan adeformadeterminanteaprodutividadedopro essode
desenvolvi-mento,àmedidaemqueodesenvolvedorselimitaaquestõesrela ionadasà onexãoe on guração
desses omponentes. Além disso, essa onexão e on guração é geralmente realizada através de
ferramentas, poupandoesforçosdeimplementação.
Qualidade: oma omplexidadeintroduzida pelos requisitosdossistemas modernos,implementar
todasasfun ionalidadesrequeridassetornaumaatividade ustosa,demoradaepropensaaerros.
A reutilização de soluções validadas, orretas e robustas é ponto fundamental para a qualidade
do sistema desenvolvido e para a produtividade do pro esso de desenvolvimento. As demandas
por exibilidade,distribuiçãoetolerân iaafalhassão requisitosnão-fun ionais,independentes do
negó iodaapli ação,egeralmentedisponibilizados omo omponentesjáimplementados,validados
e omaltopoten ialdereutilização.
Flexibilidade: opro essode ombinaçãode omponenteségeralmenterealizadoatravésdepontos
de onexãobem de nidoselo alizados,osquaispermitem amanutençãoesubstituição departes
daapli ação deforma fa ilitada. Componentes podem sermodi adosou substituídos desdeque
os ritériosde onexão ontinuem sendoatendidos.
Es alabilidade: umadas ara terísti asdate nologiade omponenteséapossibilidadedeexe ução
e onexãode omponentesemumambientedistribuído. Desta forma,novosservidorespodemser
adi ionadose omponentes podem serrealo adosnesses servidores, de modo agarantiruma boa
es alabilidadedaapli ação.
Interoperabilidade: umpontofundamental paraosu essodate nologiade omponentes éa
forne- edoresdistintosinteroperemsemgrandesesforçosparaodesenvolvedor. Interoperabilidadeéuma
questão quepermeia diversos pontos no projeto de um sistema omputa ional, envolvendo
siste-mas opera ionais,redes de omuni ação,linguagens de programaçãoearquiteturas dehardware.
O grau de heterogeneidade desses pontos é fator importante para a es olha da padronização de
omponentesaserutilizadanodesenvolvimentodosistema.
Maximizara reutilizaçãode soluções eminimizara ne essidade dedesenvolvernovassoluçõestraz
be-nefí ios em relação a usto, produtividade e qualidade. Estudos sobre reutilização eviden iam que de
40%a 60% da implementação é reutilizávelentre apli ações, 60% do projeto e da implementação são
reutilizáveis entre sistemas de informação e somente 15% onstitui implementações espe í as de um
determinadosistema[83,21℄.
1.3 Sistemas industriais de supervisão e ontrole
Umambienteindustrialégeralmente ompostoporumadiversidadedeequipamentoseletro-me âni os
integradosasoluçõesbaseadasem omputadores: sensoreseatuadorespromovemainteraçãodosistema
omoambienteindustrial,braçosderob srealizammontagenseinspeções,máquinasde omando
numé-ri o(ComputerNumeri al Control -CNC)realizammanufaturasbási as,CLP'sexe utamprogramasde
automaçãoemalhasde ontrole,redesde omuni açãointerligamsub-sistemas,supervisóriosmonitoram
asatividadeset . O termo " hão de fábri a"é omumente utilizadopara designar oambiente noqual
o orreaproduçãoequehospedaosdispositivosenvolvidosdiretamentenopro esso. Otermo "planta"
refere-seatodoo onjunto desoluções,in luindo aquelasnão envolvidasdiretamente no pro esso, tais
omosistemas demonitoramento, ban osde dadoset . Dentre essassoluções,desta am-seosSistemas
Industriais de Supervisão e Controle (S&C). Conforme ilustrado na gura 1.1, sistemas de S&C são
ara terizadosportrêsníveisbási os,listadosaseguir.
Aquisição de Dados: a obtenção de dados advindos do hão-de-fábri a, bem omo o envio de
informaçõesparaatuaçãonaplanta,sãofun ionalidadesrequeridasporqualquersistemaindustrial.
Para a realização dessas operações, dois fatores devem ser onsiderados: a previsibilidade e a
heterogeneidadedosdispositivosdeaquisição/atuaçãoedosmeiosde omuni ação. Devidoaopapel
geralmente ríti odesempenhadopelos sistemas de ontrole, asoperaçõesde aquisiçãoeatuação
devem serrealizadas deformatemporalmente previsível. Essaprevisibilidade deveser ompatível
omosrequisitosdetempoditadospeloambientequeestásendo ontrolado. Oambienteindustrial
equipamentos adquiridos de forne edoresdistintos, omo intuito de adotaras melhoressoluções
para ada aso espe í o ou omo onseqüên ia da evolução da planta ao longo do tempo. Os
forne edoresgeralmentesãoespe ializadosemdeterminadosequipamentostais omo: CLP's,braços
derob s,máquinasde omandonuméri oousensores. Éimportantequeosequipamentosadquiridos
eassoluçõesdesoftwareestejamem onformidade ompadronizaçõesabertaspara omuni ação,
demodoagarantiraintegraçãodaplanta.
Controle: asatividadesde ontrolesãorealizadasporsistemasquetentammanterumadeterminada
variávelemumvalorpré-estabele ido(setpoint),mesmonapresençadeperturbaçõesdoambiente.
Comoexemplos,pode-se itaro ontroledatemperaturadeuma aldeiraemumaplantaindustrial
ouo ontrole davelo idadede umveí ulo. Esse ontroleé geralmente realizadode forma í li a:
veri a-seovaloratualdavariávelatravésdesensores, al ula-seaatuaçãoemfunçãodadiferença
entre ovalor atualeovalordesejadoerealiza-seamodi açãona planta atravésdeatuadores. É
esperadoqueestaatuação onduza avariávelparaovalordesejado. Quandoo ál ulodaatuação
érealizadoporum omputador,tem-se o ontroledigitalautomáti o. Dentre asdiversasté ni as
de ontrole propostas, algumas são omumente utilizadas na indústria, omo o ontrolador PID
(Propor ionalIntegralDerivativo);outras onstituempesquisasre entesdaárea,tais omoos
on-troladoresmulti-variáveis,adaptativosebaseadosemalgoritmosinteligentes. Deummodogeral,
ossistemasdeS&Cdisponíveisatualmenteapresentambaixa exibilidadeemrelaçãoaqual
estra-tégiade ontrolepodeserutilizada. Adaptaçõespara usodediferentes ontroladoressãoinviáveis
ousomente realizadasaaltos ustos. Adi ionalmente,a omputação realizadapelos ontroladores
também deve ser temporalmente previsível, de modo a satisfazer os requisitos demandados pelo
ambiente.
Supervisão: amonitoraçãodosdiversospro essosedispositivosdeumaplantaindustrialérealizada
atravésdossistemas desupervisãoousistemas supervisórios. Nesses sistemas, pode-severi aro
estadoatualdeumdeterminadosensor,válvulaoumotor;realizarpequenasmodi açõesnaplanta
tais omo amudança de um setpoint ou ade nição de alarmes de monitoramento; armazenaro
fun ionamento da planta para ns dehistóri o e registraras atividades realizadas pelos usuários
dosistema,dentre outrasoperações. Conformeapresentadona gura1.1,osníveisinferiores
dis-ponibilizamserviçosparaqueosníveissuperioresexe utemaçõesemumníveldeabstraçãomaior.
Dentreastendên iasatuaisdossistemassupervisóriospode-se itarain lusãodeme anismospara
on abilidade,previsibilidadeeinteroperabilidadeeaintegração omoambienteweb[102℄.
A integração,tanto horizontal (dentro deummesmo nível)quanto verti al(entre níveisdiferentes),
Aquisição de Dados
Controle
Supervisão
= disponibilização de serviços
Integração Horizontal
Integração Vertical
Figura1.1: Níveistípi osdeumsistemaindustrialdesupervisãoe ontrole
objetivodessaintegraçãoéobterdadossigni ativossobopontodevistageren ialeadministrativo,de
modoapossibilitaraelaboraçãodemetas,estimativadeperdaseanálisesderis os.
OssistemasdeS&C onstituemumdossistemasindustriaismaisimportanteseutilizados. Entretanto,
outras lassesdesistemassãotambém omumenteen ontradosnestesambientes,aexemplodossistemas
de omando numéri o,sistemasvisuaisdeinspeçãodeprodutosesistemas detransportedemateriais.
1.4 Motivação e objetivos
Justi adopelane essidadededisponibilizaçãodeplataformasdesoftwarequefa ilitemo
desenvol-vimento desistemas modernosde S&C, estetrabalho apresenta a on epção, projeto eimplementação
deuma arquiteturaabertaparasistemasdistribuídosdeS&C,baseadanautilizaçãode omponentesde
tempo-real. Essaplataforma,denominadaARCOS(ArquiteturaparaControleeSupervisão),
disponibi-liza omponentes eferramentasbási as paraasatividadesdeaquisiçãodedados, ontroleesupervisão.
O ARCOS apresenta uma solução reutilizável de software que on entra onhe imentos de projeto e
implementação a er a dos prin ipais serviçosne essários em sistemas de S&C e de ne pontos onde a
plataformapodeserespe ializada, demodoaserutilizadaemsituaçõesespe í asdeS&C.Atravésda
reutilizaçãodos omponentes implementadosnoARCOS,odesenvolvimentode novossistemas deS&C
é signi ativamente fa ilitado. O desenvolvedor onta om omponentes pré-desenvolvidosque
garan-tem um ambiente exível, reutilizável, es alável, interoperável e om um bom grau de previsibilidade
temporal.
A engenharia de software de ne otermo framework omo um onjunto de lasses que implementa
deforma genéri a epar ial os requisitos re orrentes em sistemas de um determinadodomínio de
apli- ação[23℄. Um framework éa implementaçãode uma soluçãoarquitetural bem projetada e quepode
serreutilizadaemsituaçõesondeoprojetistanãotemexperiên iasu iente,oupordes onhe imentodo
domíniodaapli açãoouporin ipiên ianoprojetodesistemasbaseadosem omponentes, omoobjetivo
prisma,oARCOSdisponibilizaumframework queimplementaosrequisitosre orrentesem sistemasde
S&Cede ne pontosde espe ialização, baseadosem onexõesde omponentes,para aadequaçãodesta
soluçãoparausoemsituaçõesespe í asdeaquisição, ontroleesupervisão. Comosesabe, omponentes
desoftwaretêmsidoumapromissorate nologiaparaoprojetoeimplementaçãodeframeworks [23,81℄.
Anatureza exível emodulardesta abordageménaturalmente ompatível omasoperaçõesde
espe i-alização,visto que estas são freqüentemente realizadas atravésde omponentes one tados àestrutura
de nidapeloframework.
Dentre as padronizações para objetos distribuídos, a espe i ação CORBA 2.x (Common Obje t
Request BrokerAr hite ture versões2.x) [41℄ temsido onstantementeutilizadano desenvolvimentode
sistemas ara terizadospor uma heterogeneidadesigni ativaemrelaçãoalinguagensde programação,
sistemasopera ionais,arquiteturasdehardwaree anaisde omuni ação. Emparti ular,aversão3dessa
espe i ação(CORBA3)espe i aummodelode omponentesdistribuídosdenominadoCCM(CORBA
Component Model) [71℄, ara terizado pela forte presença de me anismos para onexão, on guração,
empa otamento e implantação de omponentes. As espe i açõesCORBA e CCM foram riadas pelo
Obje t Management Group (OMG) [68℄, um onsór io para produção e manutenção de padronizações
parasistemas omputa ionais.
Interoperabilidadeemsistemasdistribuídoséapropriedadequepermitea omuni açãoentreesses
sis-temas,adespeitodalinguagemdeprogramação,sistemaopera ional,meiode omuni açãoearquitetura
de hardware utilizados. Para que essa interoperabilidadeseja efetiva, soluções abertas epadronizadas
devemseradotadasemtodososníveisdosub-sistemade omuni açãoutilizado. Assim omooproto olo
TCP/IPgarante ainteroperabilidade nosníveis de roteamento e transporte de mensagens naInternet
[16, 96℄, oCORBA de ne padronizaçõespara espe i ação eimplementação de objetos distribuídos e
omoestespodem sera essadosatravésde lientes. Entretanto, interoperabilidadeplena ésomente
al- ançadaatravés do uso de padronizações para a amada de apli ação, onde a lógi a do negó io está
de nida. Ao adotar-se uma espe i ação padronizada para um determinado domínio de apli ação, a
integração om soluçõesdesenvolvidas poroutros fabri antes é onsideravelmente fa ilitada, desde que
estassoluçõestambém estejamem onformidade omapadronizaçãoemquestão. OOMGde ne
algu-masespe i ações, onhe idas omoCORBADomains,paradomínioespe í osdeapli ações,tais omo
medi ina,telefoniae ontroledetráfegoaéreo.
Dentreessasespe i ações,oDAIS(DataA quisitionfromIndustrialSystems)[69℄de neumserviço
padronizadoparaaquisiçãode dadosemsistemas industriais deS&C, onsiderandoaspe tostais omo
a temporalidade dos dados e desempenho das atividades de oleta e entrega de dados. Por ser uma
padronizaçãoCORBA, oDAISusufrui detodasaspoten ialidadesdessate nologia,in luindoa
intero-perabilidadeefetivaeapossibilidadedeutilização date nologiade omponentespara aimplementação
Previsibilidade temporal e tolerân ia a falhas 2
são requisitos fundamentais na grande maioria dos
sistemasde S&C. Nossistemas baseadosem CLP's, esses requisitossão trivialmente satisfeitos através
do uso de estruturas simples (e, onseqüentemente, previsíveis) de programação, omo por exemploa
exe ução í li a emono-programadade umpro edimento. Poroutro lado,essas estruturas simplesde
programação onstituemumentraveparaodesenvolvimentodeapli açõesmodernasdeS&C,vistoque
osCLP'spossuemrestriçõesparapro essamento,armazenamentoe omuni ação.
Pesquisasre entespro uramdisponibilizarambientesdesoftwarequesebene iamdousoda
te nolo-giade omponentese,aomesmotempo,garantemalgumgraudeprevisibilidadetemporalnasoperações
realizadasporesses omponentes. Umdessesesforçosdepesquisa éo onjunto desoluçõespara
tempo-real desenvolvidas pelo Distributed Obje t Computing (DOC) Group [37℄ da University of California,
Irvine eWashington University,EUA.Dentre essassoluções,desta am-seoTAO(TheACEORB)[91℄
eoCIAO(Component-IntegratedACEORB)[103, 65℄. OTAOé umaimplementaçãodaespe i ação
CORBA2.x omotimizaçõeseextensõesparausoemsistemasdetempo-real. OTAOtemsido
ampla-menteutilizadoemdiversassituaçõesondedeseja-sealiarosbenefí iosdoCORBA omaprevisibilidade
temporal requeridapelossistemas de tempo-real,aexemplode sistemasde ontrolede aeronavese
sis-temas de telefonia. Devido ao fato de ser uma implementação da versão 2.xdo CORBA, oTAO não
trabalha omo on eitode omponentes de software. O CIAOéuma implementaçãodo CCM, omo
objetivodedisponibilizarumaplataformafun ionalparadesenvolvimentobaseadoem omponentes,que
garantaaexe uçãotemporalmenteprevisíveldos omponentesedosserviços.
Neste trabalho são apresentados o projeto, implementação evalidação de uma plataforma baseada
em omponentes CCM/CIAO e que disponibiliza soluções exíveis, interoperáveis e reutilizáveis para
sistemasdistribuídosdeS&C.OARCOSdisponibilizaumaimplementação,baseadaem omponentesde
tempo-real,daespe i açãoDAIS, omoobjetivodegarantirainteroperabilidade omoutrasferramentas
queseguemapadronizaçãopropostaporessaespe i ação. OARCOSremodelaaespe i açãoDAIS,
utilizandoate nologiade omponentes,sementretantogerarimpa tosna omuni ação om lientesDAIS
CORBA2.x. Adi ionalmente,aimplementaçãodoDAISrealizadapeloARCOSprevêaespe ializaçãodo
framework para obtençãode dadosapartirdete nologiasdistintas dedispositivos, omo porexemplo,
CLP's ou porta paralela. O ARCOS de ne uma arquitetura exível para utilização de estratégias de
ontrole, fa ilitandomodi açõespara uso de umtipoou outro de ontrolador. Um omponente para
ontrolePID foi desenvolvidonoARCOS paraexempli ar omo essa espe ialização érealizada. Para
asatividadesdesupervisão,oARCOSdisponibilizaduasferramentas: oDAIS ServerBrowser (versões
desktopeweb)eoDAISServerManager. ODAISServerBrowser permitea omuni ação omqualquer
implementação de um serviço DAIS, permitindo aobtenção e monitoramento de dados industriais. O
DAISServerManager reúneferramentasparageren iamentodoservidorDAIS.
2
Paravalidação daplataforma foram realizados experimentos de supervisãode um simulador de
re-atorquími o, om oobjetivode testara exibilidade e osserviçosde supervisãodisponibilizados pela
implementação. Uma simulação de ontrole de velo idade de um veí ulo valida a implementação dos
omponentes de ontrole.
1.5 Estrutura da dissertação
Estadissertaçãoen ontra-sedivididaem in o apítulos eseteapêndi es.
O apítulo 2 apresenta osfundamentos bási os sobre omponentes e sua apli ação em sistemas de
tempo-real. São apresentados o modelo de omponentes CCM proposto pelo OMG, suas fa ilidades
para onexão e onsiderações sobre o pro esso de montagem e implantação de sistemas baseados em
omponentes. O apítulo 2 dis ute também os prin ipais serviços disponibilizados pelo TAO e pelo
CIAO. Em função do número reduzido de do umentos sobre o TAO e o CCM/CIAO, nesse apítulo
pro urou-seelaborarum textoauto- ontidoesu iente,do modoa onstituiruma boareferên ia para
futurosutilizadoresdoCCM/CIAOedoARCOS.
O apítulo 3 apresenta a arquitetura de supervisão e ontrole proposta (ARCOS), justi ando as
de isõesdeprojetoete nologiasutilizadas. Aspe tosdeimplementaçãosãodis utidosatravésdo
levan-tamento de re ursos do TAO/CIAO que possibilitarama implementação do framework. O apítulo 3
apresentaaindaqualaestratégiautilizadaparaadisponibilizaçãodeumaplataformapreo upada oma
previsibilidadetemporaldasexe uções.
O apítulo4apresenta omooframework arquiteturalpodeserespe ializadoparausoemumasituação
parti ulardeS&C.Sãoapresentadasasformasdeespe ializaçãodos omponentesdeaquisiçãodedados
e ontrole, bem omo as on gurações ne essárias para one tar os omponentes. São apresentados
aindaosexperimentos de supervisãoe ontrole desenvolvidossobre aplataforma. Um experimento de
supervisãodeumsimuladordereatorquími oilustra omooDAISpodeserutilizadoparaaaquisiçãoe
monitoraçãodedadosindustriais. Umasimulaçãode ontroledevelo idadedeumveí uloilustra omoos
omponentesde ontrolesãoutilizadose omoo orreasuaintegração omos omponentesdeaquisição
dedados. O apítulo4apresentaaindaumaavaliaçãodaplataforma, bem omoostrabalhos orrelatos.
O apítulo5apresentaas on lusõesdadissertação,indi açõesdetrabalhosfuturos easpubli ações
originadasdestetrabalho.
O apêndi e A apresenta aestrutura do des ritor XML utilizadopara a implantações de apli ações
baseadasno CIAO e o objetivos de ada uma das tags presentes. O apêndi e B apresenta o formato
doarquivode on guração da ferramenta de geren iamento da ompilaçãodo CIAO e doARCOS. O
apêndi eCapresentaumroteirosobre omo onstruir, ompilareimplantarum omponenteutilizando
ARCOS.Oapêndi eE ontémosarquivosIDL dos omponentes daplataforma ARCOS.Oapêndi eF
apresentaoprogramaLADDERutilizadoparaasupervisãodosimuladordereatorquími o. Oapêndi e
Plataformas e Serviços de Tempo-Real
À
medida em quea omplexidadedossistemas omputa ionais res e,autilizaçãodeplataformas de software que fa ilitam o desenvolvimento se torna uma práti a fundamental para osu essodessasapli ações. Pode-sedistinguirdoistiposdeserviçospresentesemtaissistemas: osserviços
fun io-naiseosserviçosnão-fun ionais. Osserviçosfun ionaisimplementamalógi adenegó iodaapli açãoe
sãoparti ularesparaosistema emquestão. No asodossistemasde S&C,esteserviçosdevemgarantir
a orretudelógi ae temporal da apli ação. Osserviçosnão-fun ionais sãoresponsáveisporatividades
inerentes doambiente omputa ional noqualosistema éexe utado, tais omodistribuição, segurança,
persistên iade dados, ontrolede transações,tolerân iaafalhas eadaptação. Essesserviços,pelo fato
deseremre orrentesemumavariedadedesistemas,são andidatospoten iaisàreutilização. Oobjetivo,
ao utilizar uma plataforma de tempo-real, é permitir que odesenvolvedor dedique a maioria dos seus
esforçosnaimplementaçãodosserviçosfun ionais. Nessaabordagem,osserviçosnão-fun ionaissão
dis-ponibilizadospelaplataformadesoftwaree on guradosapartirdearquivosdes ritoresouferramentas.
Este apítulo apresenta os on eitos e me anismosutilizados no projeto edesenvolvimento do
AR-COS. São apresentados o modelo de omponentes do CORBA (CCM), as fun ionalidades e serviços
disponibilizadospeloTAO/CIAOeapadronizaçãoparaaquisiçãodedadosespe i adapeloDAIS.
2.1 Middleware e sistemas de tempo-real
Middleware ertamente éum termo muitoutilizadoao longo dahistória da omputação. Nota-seque,
desdeo naldadé adade80atéosdiasatuais,aidéiademiddleware passouporalgumasmudanças,de
modoare etirosnovosobjetivoseidéiasquesurgiam[6℄. Deummodogeral,omiddlewaredesempenha
um papel de fa ilitador do pro esso de desenvolvimento, situando-se entre o sistema opera ional e as
apli ações.Oobjetivoédispensarodesenvolvedordetarefasenfadonhasepropensasaerros,aumentando
stub
skeleton
middleware
= gerado pelo
= desenvolvido pelo programador
cliente
Programa
servidor
Programa
Figura2.1: Comuni açãodepro essos atravésdoRPC
middleware
= gerado pelo
= desenvolvido pelo programador
ORB
ORB
Segurança
Persistência
Transações
cliente
Programa
Servidor
de objetos
Figura2.2: Comuni açãodepro essos eutilização deserviçosatravésdoORB
Asprimeirassoluçõesdemiddleware parasistemasdistribuídostinham omoobjetivoarealizaçãode
atividadesbási asligadas aodesenvolvimentodesses sistemas. ORPC(RemotePro edure Call) [7,63℄
éumexemplodemiddleware quepoupaodesenvolvedordaimplementaçãode ódigopara omuni ação
entre pro essosnuma rede. Esse ódigo, re orrente e propenso a erros se onstruído por
programado-resinexperientes,éautomati amente geradopelomiddleware een apsuladoem unidades denominadas
stubs e skeletons, onformeilustrado na gura2.1. O desenvolvedor selimita ao desenvolvimento dos
serviçosfun ionaisda apli ação,estando esteslo alizadosnuma só máquinaou distribuídosnumarede
de omputadores. Essafa ilidadeégeralmente onhe ida omotransparên iadelo alização.
Umaevoluçãonaturaldessa abordagemfoiosurgimento dosORB's(Obje t RequestBroker),oque
propi iouautilização dere ursos daorientaçãoaobjetos na omuni açãoentre pro essosdistribuídos.
Assim omo as fun ionalidades para omputação distribuída, outros serviços tais omo persistên ia,
segurança, ontroledetransações,balan eamentode argae omuni açãobaseadaemeventospassarama
fazerpartedasoluçãopropostapelomiddleware. Conformeilustradona gura2.2,omiddlewarebaseado
emobjetosrealizaogeren iamentoda omuni açãodistribuídaedisponibilizaserviçosnão-fun ionaisque
podem serutilizadospelasapli ações, omoobjetivodeproverafun ionalidaderequerida.
2.1.1 CORBA (Common Obje t Request Broker Ar hite ture)
Diversasespe i açõesdemiddleware baseadosem objetos estãodisponíveisatualmente,desta ando-se
oCORBA2.x[41℄, oEJB (Enterprise Java Beans)[61℄ eoDCOM(DistributedCOMponents) [60℄. O
CORBA 2.xéuma espe i açãopara omputação distribuída baseadaem objetos,desenvolvidadesde
1991peloOMG.Umdosobjetivosdessaespe i açãoépromovera omuni açãodistribuídaentreobjetos,
exe utá-los. Desta forma, oCORBA 2.x é uma solução que promove independên ia de linguagem de
programação,sistemaopera ional,arquiteturadehardwareeredede omuni açãoutilizados; onstituindo
umaabordagemadequada parausoem sistemasde S&C,vistoque estessãogeralmente ara terizados
porumaheterogeneidadeaparente.
A gura2.3apresentaosprin ipaiselementosdaarquiteturaCORBA2.x,des ritosaseguir.
Stubs eSkeletons: deformasemelhanteao RPC,osstubs eskeletons sãopeçasde ódigogeradas
pelomiddleware erealizamatividadesdeempa otamentoedesempa otamento(marshalling e
un-marshalling)deparâmetrose omuni ação omas amadassubja entesdaarquitetura. Osstubs e
skeletons sãogeradosapartirda ompilaçãodeespe i açõesindependentes delinguagemde
pro-gramação,representadasporarquivosIDL(Interfa eDe nitionLanguage). O ompiladordeIDL's
édisponibilizadopela implementaçãoCORBA2.xegerastubs eskeletons paraumalinguagemde
programaçãoparti ular.
ORBeGIOP:oORBéoelementoresponsávelpelogeren iamentodereferên iasremotase
omuni- ação omoutrosORB'seutilizaumaespe i ação hamadaGIOP(GeneralInter-ORBProto ol)
parade nir omoenviarrequisiçõesere eberrespostasdeoutrosORB's. OGIOPéumproto olo
genéri oquegaranteainteroperabilidadeem ambientes omte nologiasdistintasde omuni ação.
Outrasespe i açõesrealizamesse trabalhoemambientesderedeespe í os,aexemplodoIIOP
(Internet Inter-ORBProto ol)queéumaespe ializaçãodoGIOPparausoemredesbaseadasnos
proto olosTCP/IP.
AdaptadordeObjetos: oadaptadordeobjetos éoelementoresponsávelpelagerên iado
ompor-tamento dosobjetosdistribuídos. Atravésdeleépossívelde nirpolíti asrela ionadasao i lode
vida, persistên iae es alabilidadedestes objetos. Emum mesmo sistema podem existir diversos
adaptadoresdeobjetos, adaumdeles on gurado ompolíti asqueprovêmdiferentes
omporta-mentos.
Servant: oCORBA 2.xrealiza uma distinção importante,porém sutil, entre objetos eservants.
Umobjeto de neumareferên iaremotaparaumaentidadequedisponibilizaserviços. Invo ações
realizadas a partir dessa referên ia são exe utadas por um servant que é "en arnado" naquele
objeto. De modo a garantir aspe tos tais omo es alabilidade, a orrespondên ia entre objetos
e servants pode não ser do tipo um-para-um. Antes de re eber invo ações remotas, um servant
pre isaserativadoemalgumadaptadordeobjetos. Apósessaativação,oservant passaaterseu
omportamentode nidopelaspolíti asdoadaptadordeobjetosnoqualele foiativado. Oservant
= desenvolvido pelo programador
= gerado pelo middleware
= disponibilizado pelo middleware
Objetos
Stub
Skeleton
Adaptador de
GIOP
Cliente
Servant
Ativação
Servidor
Invocação Remota
ORB
ORB
Figura2.3: Prin ipaiselementosdaarquiteturaCORBA2.x
ClienteeServidor: o liente eoservidorsãoapli ações onstruídaspelodesenvolvedor.Oservidor
realizaasatividadesdeini ializaçãodoORB, riaçãoe on guraçãodeadaptadoresdeobjetos;
ri-açãoeativaçãodeservants,dentreoutras. OdesenvolvimentodeservidoresCORBA2.x on áveis,
es aláveisereutilizáveiséumatarefa ustosaequeexigeexperiên iaporpartedo desenvolvedor.
O liente é uma apli ação que adquirereferên ias remotas para objetos eas utilizapara invo ar
operaçõesrealizadaspeloservidor.
OCORBA 2.x,apesardasvantagensrela ionadasaosuporteàheterogeneidade,apresenta algumas
de iên iasquedi ultamoseuusopoten ialnodesenvolvimentodesistemasdistribuídos omplexos:
Ausên iademe anismospara a onexãodesa oplada deobjetos: objetos ujaimplementação
de-pendem deoutrosobjetos pre isamlo alizarestesobjetos e one tar-seaeles deformaexplí ita,
atravésde ódigoimplementadopelodesenvolvedor. Essaabordagem onduzasistemasin exíveis
e ombaixograudereutilização.
Ausên ia de uma padronização para servidores: o CORBA 2.x não disponibiliza um framework
genéri o paraatividades re orrentesde servidores,tais omo: ini ializaçãodoservidor,
on gura-çãode serviços(lo alização,eventos, et ) egeren iamento doambiente de exe ução(políti asdo
adaptador)de adaobjeto.Osservidorespre isamserinteiramente odi adospelodesenvolvedor,
exigindo onhe imento aprofundado da arquitetura CORBA 2.x e demandando esforços que não
estãorela ionadosàpartefun ional donegó io.
Ausên iadepadronizaçõespara on guraçãoeimplantação: oCORBA2.xnãode neme anismos
paraimplantaçãoe on guraçãoremotade objetos. Asoperaçõesdeimplantação, on guraçãoe
ini ializaçãosão realizadasde formaad-ho , em ada máquinaque ompõeosistema distribuído,
Outrasde iên ias doCORBA 2.x onstituem umimpeditivopara asuautilizaçãoemsistemas ríti os
emrelaçãoaotempo:
Ausên iadeinterfa esparaespe i açãodeQoS(Quality ofServi e): oCORBA2.xnão
disponi-biliza interfa espara espe i ação deparâmetrosde QoS. Apli açõesCORBA 2.x não onhe em
informaçõessobreprioridades,taxasdeinvo açõesdeserviçosoupolíti asde ontroledeadmissão
denovos lientes.
Ausên ia deme anismos paragarantia de QoS:a maioria dasimplementaçõesCORBA realizaa
transmissão e exe ução de invo ações seguindo aestratégia FIFO (First-In First-Out), podendo
levarào orrên iadeinversõesdeprioridade[80,49℄. Adi ionalmente,oCORBA2.xnão permite
queprioridadessejamatribuídasàsthreads quepro essamasrequisiçõeseaalo açãodere ursos,
omomemória,éfeitadeformaad-ho esemumapreo upação omumpossível onsumoex essivo.
Ausên iadeotimizaçõesdedesempenho: asimplementações onven ionaisdoCORBA2.xsão
a-ra terizadaspor umalto overhead, alémde diversospontos queimpli amnuma imprevisibilidade
deexe ução. Essaimprevisibilidadeégeralmente ausadapor: ópiaex essivadedados,utilização
debuers om omportamentonão-uniforme,algoritmosimprevisíveisparademultiplexaçãoe
dis-pat hing, adeiaslongasdeinvo açõesamétodosvirtuaiseausên iadeintegração omas amadas
subja entesdesistemaopera ionalerede[91℄.
Frente aessas questões, padronizações quesuportassem osrequisitos para a apli ação do CORBA em
sistemas detempo-realpassaram a serdesenvolvidas,aexemplo doRT-CORBA (Real-Time CORBA)
[73℄edoFT-CORBA(Fault-Tolerant CORBA)[74℄.
2.2 Componentes e sistemas de tempo-real
O desenvolvimento das abstrações e me anismos que ompõem a orientação a objetos foi um dos
grandes avanços que possibilitaram um maior geren iamento da res ente omplexidade dos sistemas
omputa ionais. Apesardeumamaiormodularizaçãoereutilizaçãopromovidapelaorientaçãoaobjetos,
linguagens de programaçãoOO (Orientadas a Objetos) introduziam suas próprias derivações e
exten-sõesdo paradigma, di ultandoainteroperabilidade. Além disso,ainexistên ia depadronizaçõespara
representaçãode objetos e invo açõesde métodos tornava essas implementações espe í as para uma
A utilização moderada de re ursos omputa ionais, bem omo o geren iamento dasrelações
re ur-sos/usuáriossãopontos ríti osparaodesenvolvimentodesistemases aláveis. Atravésdasoperaçõesde
riação(instan iação)eremoçãodeobjetos,odesenvolvedordevealo aredesalo arosre ursos
ne essá-riospara aexe uçãodedeterminadaatividade. Aimplementaçãoinexperiente ounão planejadadessas
operaçõespodea arretaremsistemas in exíveise omes alabilidadelimitada.
Sistemasdistribuídos onven ionaissão, emsuamaioria, ara terizadospelane essidadedeserviços
não-fun ionais,tais omo: lo alizaçãodeobjetos,persistên ia,segurança, ontroledetransações,
tolerân- iaafalhas,dentre outros. Mesmo omadisponibilizaçãodesses serviçossobaformade bibliote asde
objetos,aintegraçãoentreaapli açãosendodesenvolvidaeestas bibliote asérealizadaexpli itamente
em ódigo, demandando tempo e onhe imento espe ializado. Além disso, mudanças nas te nologias
utilizadasnessesserviçosimpli amnumamodi açãoere ompilaçãodaapli ação.
Emapli ações omplexasé omumobjetosserela ionarem omoutrosobjetosdemodoaimplementar
umafun ionalidade emparti ular. Esses rela ionamentos ostumamserimplementados expli itamente
em ódigo, produzindo objetos omreutilização restrita esistemas onde a substituição de uma
imple-mentaçãodeobjetoporoutraégeralmenterealizadaaaltos ustos.
Uma abordagem que pro ura superarestas de iên ias é ate nologiade omponentes de software.
Duasde niçõesde omponentesdesoftwareen ontradasnaliteraturasão:
"Um omponente é um elemento de software, em
onformidade omummodelo, quepodeser
indepen-dentementeimplantadoe one tadoaoutros
ompo-nentes,sem ane essidadede modi ações."
Heineman,2001[45℄
"Componentes reutilizáveis de software são
artefa-tosauto- ontidosefa ilmenteidenti áveisque
des- reveme/ouimplementam funçõesespe í ase
pos-suem interfa es bem de nidas, do umentação
apro-priadae poten ialidadeparareutilização."
Sametinger,2001[83℄
Oprin ipalobjetivodaengenhariadesoftwarebaseadaem omponentesédesenvolversistemasapartir
da onexãofa ilitadadepeçaspré- onstruídasdesoftware( omponentes). Ate nologiade omponentes
superaasde iên iasdaorientaçãoaobjetosapartirdadisponibilizaçãodosseguintesme anismos[92℄:
De niçãodepadronizaçõespara omuni ação: omessanovaabordagem,um omponentepassaa
serumaentidadeem onformidade ompadronizaçõesquedes revemoformato derepresentação
de omponenteseaformaderealizaçãodeinvo ações.Cada omponentepossuiinterfa esque
des- revemosserviçosdisponibilizadosepontosbemde nidospara onexão omoutros omponentes.
ontainer. Após aimplantação (deployment) de um omponente em um ontainer, este passa
a geren iar atividades importantes na exe ução daquele. O geren iamento do i lo de vida do
omponente, bem omo a sua relação om os possíveis lientes é ex lusivamente realizada pelo
ontainer, numa operação geralmente hamada de instan e pooling. O objetivo é geren iar os
re ursosdisponíveis( omponentes)demodoagarantiruma boaes alabilidadedaapli ação.
Utilizaçãofa ilitada deserviçosnão-fun ionais: alémdasfa ilidadesa ima des ritas,aintegração
do omponente omosserviçosnão-fun ionaisé também geren iadapelo ontainer, omaajuda
deindi açõessimpli adasgeralmenterealizadasatravésdearquivosXML onstruídospelo
desen-volvedor (des ritoresde implantação). Todas essasoperações ontribuem signi ativamente para
a produtividade e qualidadedas soluções, visto que odesenvolvedor sepreo upa somente omo
desenvolvimentodeserviçosfun ionais(lógi adaapli ação).
Me anismos exíveispara onexãode omponentes: na abordagembaseadaem omponentes,
sis-temas sãoimplementadosatravésda onexãode omponentes pré- onstruídos. Umadeterminada
on guração,indi andoos omponentesparti ipanteseas onexõesentreeleségeralmente hamada
demontagem(assembly). Duranteopro essodeimplantação,todasasoperaçõesde onexãoentre
omponentesérealizadapelo ontainer, omaajudadeindi açõessimpli adaspresentes nos
ar-quivosdes ritoresdeimplantação. Aexistên iadeferramentasgeradorasdearquivosdes ritoresde
implantação, apartirde on guraçõesrealizadaspelo desenvolvedordeformavisual,representam
maisumavançoemdireçãoaodesenvolvimentoprodutivodesistemas on áveis. Adi ionalmente,
essa montagem pode ser modi ada de modo a atender ne essidades de mudanças do sistema.
Tem-se,destaforma,umnovoparadigmaparamanutençãodesistemas,podendoestain lusiveser
realizada omosistemaemfun ionamento. As onexõesentre omponentesseriammodi adasde
modoapermitirasubstituição deum omponenteporoutro.
Atabela2.1resumeasprin ipaisdiferençasentreaste nologiasdeobjetose omponentes. Enquantoa
orientaçãoaobjetosde neme anismosparaodesenvolvimentobaseadoemabstrações(en apsulamento,
o ultamentoseherança),ate nologiade omponentessepreo upa omade niçãodeme anismospara
a omposiçãofa ilitada desoluções. Outradiferençaimportanteéemrelaçãoaogeren iamentodo i lo
de vida. Enquanto objetos têm seu i lo de vida geren iado diretamente pelo desenvolvedor (através
deoperaçõesdotiponew - riaçãode instân iaedelete - destruiçãodeinstân ia), os omponentes são
geralmenteexe utadosemumambientedesoftwarepré- onstruído( ontainer). Esse ontainer geren ia
opro essode riaçãoedestruiçãodenovasinstân ias de omponentes,de nindo políti as es aláveisde
utilizaçãodessesre ursos. A ombinaçãodeobjetos, omoobjetivode onstruirumsistema ompleto,é
OBJETOS COMPONENTES
Ênfasenasabstrações Ênfasena omposição(assembly)
Têmseu i lodevidageren iado Têmseu i lodevidageren iadoporum
pelo desenvolvedor ambientedesoftwarepré- onstruído( ontainer)
Composiçãorealizadavia ódigo- Composiçãorealizadaatravésdeme anismos
fonte de nidospela espe i ação
Sãounidadesdeinstan iação Sãounidades deimplantação(deployment)
Tabela 2.1: Diferenças on eituaisentreobjetose omponentes
Interface
CORBA
Produtor
de Eventos
Consumidor
de Eventos
Interface
Suportada
Servidor de
Componentes 1
Componentes 2
Servidor de
Home
Home
Home
Conexão
Cliente CCM
Receptaculo
Faceta
Atributos
CONTAINER 2
Componente 1
Componente 2
Componente 3
CONTAINER 1
CONTAINER 3
Figura2.4: Modelode omponentesdoCCM
re ompilaçõesparaaalteraçãodealgumadessas ombinações. Ate nologiade omponentesprevêa
de -niçãodeme anismospadronizadospara onexão,eautilizaçãodete nologias exíveisparaaespe i ação
dessas ombinações omo,porexemplo,arquivosdes ritoresXML.Diversosmodelosepadronizaçõesde
omponentes têm sido propostos em pesquisas re entes, omdestaque para as padronizações CORBA
ComponentModel (CCM)[71℄,EJB (Enterprise Java Beans) [61℄eDCOM(DistributedCOMponents)
[60℄.
2.2.1 CCM (CORBA Component Model)
Motivadopelasde iên iasjá itadasdaarquiteturaCORBA2.x,oOMGdisponibilizouemjunhode
2002aversão3doCORBA, ontemplandoummodeloeumaespe i açãode omponentesdenominada
CORBAComponent Model (CCM). OCCM espe i a ummodelode omponentesdistribuídos,
