Guião de Relatório de Projeto / Estágio - CISTER · da conclusão do trabalho estar prevista...

of 73/73
Framework para Sistemas Distribuídos em Tempo-real BEng Thesis CISTER-TR-161201 2016/10/31 Roberto Duarte
  • date post

    17-Dec-2018
  • Category

    Documents

  • view

    213
  • download

    0

Embed Size (px)

Transcript of Guião de Relatório de Projeto / Estágio - CISTER · da conclusão do trabalho estar prevista...

Framework para Sistemas Distribudos em Tempo-real

BEng Thesis

CISTER-TR-161201

2016/10/31

Roberto Duarte

BEng Thesis CISTER-TR-161201 Framework para Sistemas Distribudos em Tempo-real

CISTER Research Center www.cister.isep.ipp.pt

1

Framework para Sistemas Distribudos em Tempo-real

Roberto Duarte

*CISTER Research Centre

Polytechnic Institute of Porto (ISEP-IPP)

Rua Dr. Antnio Bernardino de Almeida, 431

4200-072 Porto

Portugal

Tel.: +351.22.8340509, Fax: +351.22.8321159

E-mail: [email protected]

http://www.cister.isep.ipp.pt

Abstract

The development of real-time distributed systems has always been a complex, platform-specific and expensive task. The introduction of the fork-join paradigm in multicore systems allowed the distribution of computations between the cores.This work proves that it is possible to implement the fork/join parallel computing paragidm in real-time systems. This paradigm allows to relocate part of the computation to different computational nodes when it is not feasible to execute the computation locally within a given deadline. Another motivation to distribute the computation can be the need to save energy on some battery-powered nodes by means of load balancing. The framework was developed with a focus on embedded nodes with low computational capabilities, and the implementation features a great deal of low-level optimization, with the goal of meeting deadlines up to 70 ms.The work was based on an open-source implementation of the communication protocol Flexible Time Trigger-Switched Ethernet (FTT-SE), in which the distributed operations are executed in Linux nodes equipped with the real-time scheduler provided by the kernel patch PREEMPT-RT.

Framework para Sistemas Distribudos

de Tempo-real Research Centre in Real-Time & Embedded Computing Systems (CISTER)

2015 / 2016

1070485 Roberto Daniel Alves Duarte

Framework para Sistemas Distribudos

em Tempo-real Research Centre in Real-Time & Embedded Computing Systems (CISTER)

2015 / 2016

1070485 Roberto Daniel Alves Duarte

Licenciatura em Engenharia Informtica

Outubro de 2016

Orientador ISEP: Prof. Dr. Luis Lino Ferreira

Supervisor Externo: Eng. Ricardo Garibay-Martinez

Framework para Sistemas Distribudos em Tempo-real

v

Aos meus pais,

minha famlia,

minha namorada

E aos meus amigos.

Agradecimentos

Quero em primeiro lugar enderear um forte agradecimento ao Professor Doutor Lus Lino

Ferreira e ao Engenheiro Ricardo Garibay-Martnez por todo o seu apoio, dedicao e

disponibilidade que me facultaram e por me orientarem sempre no sentido de melhorar o

meu trabalho.

Quero tambm agradecer a todos os amigos que fiz no CISTER que por toda ajuda e

camaradagem ao longo do tempo que estive l. No esquecendo claro o agradecimento ao

Departamento de Informtica pela oportunidade de frequentar a Licenciatura em Engenharia

Informtica. Estes ltimos anos de estudo, apesar de extenuantes, tm sido muito

recompensadores, cheios de desafios e aprendizagem. O que aprendemos no ISEP, no s nos

preparou intelectualmente para o mercado de trabalho como tambm nos ajudou a ganhar

maturidade.

Framework para Sistemas Distribudos em Tempo-real

vii

Resumo

O desenvolvimento de sistemas distribudos de tempo-real tem sido sempre uma tarefa

complexa, altamente especializada para cada plataforma e com custo muito elevados. A

introduo do paradigma de computao paralela fork/join em sistemas multicore permite

dividir a computao entre vrios cores.

Este trabalho demostra que possvel a implementao do paradigma de computao

fork/join distribuda em sistemas de tempo-real. Este paradigma permite distribuir parte de

determinadas operaes que no podem ser executadas localmente num n, dentro da

deadline definida para essa operao. Tal deve-se ao facto desses ns no terem capacidade

de processamento suficiente. Outra razo para distribuir a computao pode tambm ser a

necessidade de poupar energia num n sem fios. Assim, a framework desenvolvida permite

distribuir parte da computao por outros ns do mesmo sistema que tenham recursos livres.

Foi especialmente desenvolvida para ser utilizada em sistemas embebidos com fraca

capacidade de processamento, a operar numa rede totalmente fechada ao exterior. A

implementao por isso muito otimizada e de baixo nvel de modo a que possa cumprir

deadlines acima dos 70 ms.

Este trabalho foi baseado numa implementao open-source do protocolo de comunicao

Flexible Time Trigger-Switched Ethernet (FTT-SE) em que as operaes distribudas so

executas em ns Linux com o patch PREEMPT-RT, que assegura o suporte a aplicaes de

tempo real.

Palavras Chave (Tema): Fork/Join parallel distributed, tempo-real

Palavras Chave (Tecnologias): FTT-SE, C

Framework para Sistemas Distribudos de Tempo-real

ix

ndice

1 Introduo ............................................................................................................. 15

1.1 Apresentao do projeto/estgio ................................................................... 15

1.2 Tecnologias utilizadas .................................................................................... 19

1.3 Apresentao da organizao ......................................................................... 20

1.4 Contributos deste trabalho............................................................................. 20

1.5 Organizao do relatrio ................................................................................ 21

2 Contexto ................................................................................................................ 22

2.1 Sistemas de tempo-real .................................................................................. 22

2.2 Sistemas operativos de tempo-real................................................................. 22

2.3 Comunicao distribuda de tempo-real ......................................................... 24

2.4 Flexible Time Triggered over Switched Ethernet (FTT-SE)................................. 25

2.5 Paradigma de programao paralela fork/join distribuda ............................... 30

3 Descrio Tcnica ................................................................................................... 32

3.1 Levantamento de Requisitos .......................................................................... 32

3.2 Modelao e desenvolvimento da soluo ...................................................... 33

4 Resultados e Validao .......................................................................................... 63

4.1 Experiencias Realizadas .................................................................................. 63

5 Concluses ............................................................................................................. 68

5.1 Objetivos realizados ....................................................................................... 68

5.2 Outros trabalhos realizados............................................................................ 69

5.3 Trabalho futuro .............................................................................................. 69

5.4 Apreciao final ............................................................................................. 69

6 Bibliografia ............................................................................................................ 71

Framework para Sistemas Distribudos de Tempo-real

xi

ndice de Figuras

Figura 1: Arquitetura interna do FTT-SE. [7] ........................................................................... 26

Figura 2: Demonstrao da composio do Elementary Cycle. [7] ......................................... 28

Figura 3: Execuo de uma tarefa usando o modelo de execuo paralelo distribudo. [10] 31

Figura 4: Diagrama de Deployment PDRTF. ............................................................................ 34

Figura 5: Configurao utilizada durante o desenvolvimento e testes da PDRTF. .................. 36

Figura 6: Disposio das partes locais e remotas das tarefas no cluster. ............................... 38

Figura 7: Diagrama de sequncia da Interao entre parte local e remota da tarefa. ........... 40

Figura 8: Diagrama de estados da parte remota da tarefa. .................................................... 41

Figura 9: Diagrama de estados da parte local da tarefa. ......................................................... 42

Figura 11: Diagrama de estados do processo de Leitura do ficheiro de configurao. .......... 48

Figura 12: Diagrama de estados da criao de streams no n local ....................................... 50

Figura 13: Diagrama de estados da criao de streams no n remoto ................................... 52

Figura 14: Exemplo de atribuio de ids s streams para duas tarefas com dois ns remotos.

................................................................................................................................................. 53

Figura 15: Diagrama de estados da criao de threads no n local ........................................ 54

Figura 16: Diagrama de estados da criao de threads no n remoto ................................... 55

Figura 17: Diagrama de estados da execuo da thread no n local. ..................................... 56

Figura 18: Diagrama de estados da execuo da thread no n remoto. ................................ 57

Framework para Sistemas Distribudos de Tempo-real

xiii

ndice de Tabelas

Tabela 1: Lista de tarefas que constam do planeamento do projeto ..................................... 17

Tabela 2: Lista de tarefas que constam do planeamento do projeto ..................................... 19

Tabela 3: Caractersticas das tarefas tempo-real a testar ....................................................... 65

Notao e Glossrio

AW Asynchronous Window

C Linguagem de programao orientada a objetos

CISTER Centro de Investigao em Sistemas Embebidos e de Tempo-Real

CSMA/CD Carrier Sense Multiple Access With Collision Detection

EC Elementary Cycle

FTT Flexible Time Triggered

FTT-SE Flexible Time Triggered - Switched Ethernet

MIT Minimum Inter-arrival Time

MTU Maximum Transmission Unit

NES Network Embedded System

NRBD Node Requirements Database

PDRTF Parallel Distributed Real Time Framework

SRDB System Requirements Database

SW Synchronous Window

TM Trigger Message

WCET Worst-Case Execution Time

WCML Worst-Case Message Length

WCRT Worst-Case Response Time

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 15

1 Introduo

1.1 Apresentao do projeto/estgio

Neste captulo, feita a introduo do projeto realizado, onde explicado o seu

enquadramento, demonstrado o seu planeamento e reunies de acompanhamento, descritas

brevemente as tecnologias utilizadas e apresentada a organizao onde ele foi desenvolvido.

No seu final descrita a organizao do presente relatrio.

1.1.1 Enquadramento

O presente relatrio desenvolvido no mbito da unidade curricular Projeto/Estgio (PESTI)

da Licenciatura Em Engenharia Informtica (LEI) do Instituto Superior de Engenharia do Porto

(ISEP). Em PESTI o principal objetivo a consolidao das competncias adquiridas durante o

curso em um ambiente real de trabalho, melhor preparando o aluno para a sua integrao

num contexto profissional.

Este projeto de estgio foi realizado no Centro de Investigao em Sistemas Embebidos e de

Tempo-Real (CISTER) e teve como objetivo a implementao de uma Framework para

Sistemas Distribudos em Tempo-real e a consequente realizao de testes a fim de obter

resultados que demonstrem a viabilidade deste tipo de implementao.

1.1.2 Apresentao do Projeto

Atualmente existe uma grande proliferao de sistemas embebidos integrados em objetos do

nosso cotidiano tal como em meios de transporte, eletrodomsticos, edifcios, sistemas de

apoio a medicina etc. Alguns destes sistemas tem requisitos temporais rigorosos e para

responder a esses requisitos so divididos em partes que comunicam entre si atravs de uma

rede para efetuar diferentes tarefas ou distribuir o trabalho, estes sistemas so denominados

de Networked Embedded Systems (NES).

O desenvolvimento para este tipo de sistemas por norma torna se uma tarefa complexa

devido a necessidade de integrar o processamento distribudo e transmisso de dados para

que forneam o grau de determinismo temporal necessrio.

com vista a responder a este tipo de dificuldade que foi criada esta Framework que integra

num s lugar ferramentas que do suporte a este tipo de programao como os elementos

necessrios para que o cumprimento destas exigncias temporais.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 16

tambm importante mencionar que esta Framework assenta na utilizao no protocolo de

transmisso de dados com garantias de tempo-real FTT-SE que baseado no paradigma

Flexible Time Triggered (FTT).

1.1.3 Planeamento de projeto

O planeamento deste projeto consistiu na separao em 5 fases: anlise, implementao da

Framework inicial, introduo ao tempo-real, implementao da Framework com tempo-real

e obteno e anlise de resultados. A extenso deste projeto deve se ao facto de ter sido

necessrio estudar vrios conceitos e tecnologias diferentes cujo seu conhecimento seria

essencial para o desenvolvimento de uma Framework desta natureza. Alem desse facto apesar

da concluso do trabalho estar prevista para junho de 2014 devido a problemas de sade o

projeto foi interrompido tendo sido retomado em julho de 2016 para concluso do relatrio.

A Tabela 1 demonstra o planeamento elaborado para o projeto.

% Concluda Nome da Tarefa Durao Incio Concluso Predecessoras

100% Anlise 28 dias Seg

16/09/13 Qua

23/10/13

100% Estudar OpenMP e MPI 7 dias Seg 16/09/13

Ter 24/09/13

100% Estudar Pthreads 7 dias Qua 25/09/13

Qui 03/10/13 2

100% Estudar Sockets 7 dias Sex 04/10/13

Seg 14/10/13 3

100% Estudar outras bibliotecas e Frameworks relacionadas com o projeto

7 dias Ter 15/10/13

Qua 23/10/13

4

100% Implementar Framework

Inicial 28 dias

Qui 24/10/13

Seg 02/12/13 1

100% Implementar funes de paralelizao

7 dias Qui 24/10/13

Sex 01/11/13 1

100% Implementar mecanismo de configurao

14 dias Seg 04/11/13

Qui 21/11/13 7

100% Implementar comunicao distribuda com Sockets

14 dias Seg 04/11/13

Qui 21/11/13 7

100% Testar implementao inicial 7 dias Sex 22/11/13

Seg 02/12/13 8;7;9

100% Introduo ao Tempo-real 28 dias Qui

05/12/13 Seg 13/01/14 6

100% Estudar programao em tempo-real

7 dias Qui 05/12/13

Sex 13/12/13 6

100% Estudar sistemas operativos tempo-real

7 dias Seg 16/12/13

Ter 24/12/13 12

100% Estudar escalonadores linux tempo-real

7 dias Qua 25/12/13

Qui 02/01/14 13

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 17

100% Estudar comunicao em tempo-real

7 dias Sex 03/01/14

Seg 13/01/14 14

100% Estudar Flexible Time Triggered - Switched Ethernet (FTT-SE)

7 dias Sex 03/01/14

Seg 13/01/14 14

100% Implementar Framework com

tempo-real 43 dias

Ter

14/01/14 Qui 13/03/14 11

100% Implementar nova comunicao distribuida usando FTT-SE

14 dias Ter 14/01/14

Sex 31/01/14 11

100% Implementar novo mecanismo de configurao para suportar FTT-SE

14 dias Ter 14/01/14

Sex 31/01/14 11

100% Integrao com escalonador tempo-real linux

7 dias Seg 03/02/14

Ter 11/02/14 18;19

100% Actualizao mecanismo de parelizao para suportar escalonamento tempo-real

7 dias Qua 12/02/14

Qui 20/02/14 20

100% Testar implementao final 15 dias Sex 21/02/14

Qui 13/03/14 21

100% Resultados 15 dias Sex

14/03/14 Qui 03/04/14 17

100% Experincias usando a implementao realizada

7 dias Sex 14/03/14

Seg 24/03/14 17

100% Analise de resultados das experincias

7 dias Ter 25/03/14

Qua 02/04/14

24

100% Escrever relatrio 35 dias Qua 20/07/16

Ter 06/09/16 25

100% Preparar distribuio Open Source

7 dias Qua 07/09/16

Qui 15/09/16 26

Tabela 1: Lista de tarefas que constam do planeamento do projeto

1.1.4 Reunies de acompanhamento

Conforme se pode verificar na tabela 2, so apresentadas as reunies de acompanhamento

realizadas ao longo do projeto que tiveram sempre lugar no CISTER, nestas reunies foi

abordado o estado do trabalho, foram esclarecidas dvidas que iam surgindo sobre o trabalho

e foram discutidas questes sobre a implementao. Alm destas reunies houveram

tambm conversas informais que ocorreram num evento semanal da prpria organizao

de o i ado Mo i g Coffee onde grande parte dos elementos da organizao se juntam num ambiente descontrado para socializarem.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 18

Data Participantes Assunto

9-9-2013 Prof. Lus Lino Ferreira e Eng. Ricardo

Garibay Martinez Discusso sobre objetivos

do projeto

18-9-2013 Eng. Ricardo Garibay Martinez Esclarecimento de dvidas

26-9-2013 Prof. Lus Lino Ferreira Progresso do trabalho

1-10-2013 Prof. Lus Lino Ferreira e Eng. Ricardo

Garibay Martinez Esclarecimento de dvidas

12-10-2013 Prof. Lus Lino Ferreira Progresso do trabalho

15-10-2013 Eng. Ricardo Garibay Martinez Discusso sobre implementao

21-10-2013 Eng. Ricardo Garibay Martinez Esclarecimento de dvidas

28-10-2013 Prof. Lus Lino Ferreira e Eng. Ricardo

Garibay Martinez Progresso do trabalho

13-11-2013 Prof. Lus Lino Ferreira e Eng. Ricardo

Garibay Martinez

Discusso sobre

implementao

29-11-2013 Prof. Lus Lino Ferreira Progresso do trabalho

12-12-2013 Prof. Lus Lino Ferreira e Eng. Ricardo

Garibay Martinez

Progresso do trabalho e

Discusso sobre

implementao

8-1-2014 Prof. Lus Lino Ferreira Progresso do trabalho

24-1-2014 Eng. Ricardo Garibay Martinez Esclarecimento de dvidas

11-2-2014 Eng. Ricardo Garibay Martinez

Esclarecimento de dvidas

e Discusso sobre

implementao

17-2-2014 Prof. Lus Lino Ferreira e Eng. Ricardo

Garibay Martinez

Progresso do trabalho e

Discusso sobre

implementao

7-3-2014 Prof. Lus Lino Ferreira Progresso do trabalho

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 19

23-3-2014 Eng. Ricardo Garibay Martinez

Esclarecimento de dvidas

e Discusso sobre

implementao

10-4-2014 Prof. Lus Lino Ferreira Progresso do trabalho

29-4-2014 Prof. Lus Lino Ferreira Progresso do trabalho

18-7-2016 Prof. Lus Lino Ferreira Discusso sobre o relatrio

26-7-2016 Prof. Lus Lino Ferreira Discusso sobre o relatrio

4-8-2016 Prof. Lus Lino Ferreira Discusso sobre o relatrio

12-8-2016 Prof. Lus Lino Ferreira Discusso sobre o relatrio

Tabela 2: Lista de tarefas que constam do planeamento do projeto

1.2 Tecnologias utilizadas

Para este projeto foi necessrio o uso de vrias tecnologias tanto para o seu desenvolvimento

como para suporte ao desenvolvimento. Estas tecnologias so descritas na seguinte lista que

est organizada por escales:

Sistemas Operativos

o Linux Debian 7.8 com Kernel de tempo-real RT-PREEMPT

Programas utilizados

o Netbeans IDE

o Microsoft Word

o Microsoft Excel

o Microsoft Visio

o Microsoft Project

Controlo de Verses

o Github

Linguagens de programao

o C

Bibliotecas usadas

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 20

o FTT-SE

o Libconfig

1.3 Apresentao da organizao

O Centro de Investigao em Sistemas Embebidos e de Tempo-Real (CISTER) uma unidade

de investigao Portuguesa de referncia, baseada no Instituto Superior de Engenharia do

Porto (ISEP) do Politcnico do Porto (IPP). O Centro foca a sua atividade de investigao na

anlise, projeto e implementao de sistemas de computadores embebidos e de tempo-real,

sendo um dos lderes mundiais na investigao em diversos tpicos dentro das reas das redes

de sensores sem fio, das plataformas multi-core embebidas ou de software de tempo-real.

Desde que foi criado (em 1997), o CISTER cresceu at se tornar a unidade mais proeminente

do ISEP, sendo o nico Centro de I&D Portugus nas reas da Engenharia Eletrotcnica e

Informtica a obter consecutivamente a avaliao de Excelente nos ltimos dois processos de

avaliao de I&D em Portugal, realizada por painis internacionais. O Centro participa

consistentemente em projetos de Investigao, Desenvolvimento e Inovao (I&D&I)

nacionais e internacionais, com parceiros como a Portugal Telecom, a Critical Software, a ISA,

a Thales, a EADS, a Infineon, a SAP, a Schneider Electric ou a Embraer.

A informao contida nesta seco foi elaborada com base na referncia: [1].

1.4 Contributos deste trabalho

Apesar e existirem algumas solues para desenvolvimento de aplicaes distribudas de

tempo-real estas so ofertas que por norma requerem hardware e software dispendioso.

Com este projeto possvel colmatar estas problemticas pois possvel desenvolver um

sistema distribudo com hardware comum e relativamente barato, para alm disso o cdigo

fonte disponibilizado para a comunidade open source e foi desenvolvido a pensar na

facilidade de utilizao no obstante da necessidade de alguns conhecimentos da linguagem

C e de boas prticas de programao.

Parte deste projeto nomeadamente o componente FTT-SE Wrapper foi dese volvido a pa a facilitar utilizao da biblioteca FTT-SE de Ricardo Marau fornecendo uma interface mais

simplificada e de fcil aprendizagem. Por esta razo este mdulo foi utilizado no projeto

Arrowhead [11] que tambm fez uso do protocolo FTT-SE [12].

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 21

1.5 Organizao do relatrio

O presente relatrio tem uma estrutura organizada por objetivos especficos os quais sero

apresentados a seguir:

Captulo 1 Introduo: Este o captulo atual e pretende apresentar o projeto realizado e fornecer uma contextualizao generalizada do problema proposto.

Captulo 2 Contexto: Neste captulo, as tecnologias utilizadas ao longo do projeto para o desenvolvimento da Framework so apresentadas de forma a fornecer noes tericas

fundamentas para a compreenso de como o projeto foi elaborado.

Captulo 3 - Descrio Tcnica: Neste captulo apresentada a descrio da implementao

de maneira a fundamentar as decises tomadas no decurso do desenvolvimento para

corresponder aos requisitos do trabalho.

Captulo 4 -Resultados e validao: Neste captulo so realizadas experincias utilizando a

Framework de forma a validar os objetivos propostos.

Captulo 5 Concluso: Neste captulo final so apresentadas as concluses do trabalho

analisando os objetivos concretizados e possvel trabalho futuro.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 22

2 Contexto

Neste captulo fornecida uma contextualizao das tecnologias e conceitos utilizados ao

longo do projeto. A seco 2.1 ir descrever o que um sistema de tempo-real, assentando

caminho para a seco 2.2 que ir caracterizar os sistemas operativos de tempo-real

fornecendo exemplos de alguns destes e detalhando o que foi usado neste projeto.

Seguidamente na seco 2.3 ser descrita a comunicao distribuda de tempo-real,

finalizando na seco 2.4 com a descrio do protocolo FTT-SE que foi utilizado neste projeto.

2.1 Sistemas de tempo-real

De acordo com [2] um sistema de tempo-real pode ser definido como um sistema em que o

resultado de um computao no depende apenas do resultado lgico da mesma, mas

tambm do tempo em que os resultados so produzidos.

Consequentemente, estes sistemas devem responder a eventos (temporais, fsicos ou outros)

dentro de um determinado intervalo de tempo sendo o seu limite designado por deadline. O

tipo de consequncia e utilidade do resultado aps uma falha de cumprimento deste deadline

o que caracteriza o tipo de sistema de tempo-real. Se um resultado tiver utilidade mesmo

depois de a deadline ter passado, classificado como soft, seno classificado como firm, se

o no cumprimento der origem a uma falha catastrfica (p.e. uma acidente), ento o sistema

classificado como hard.

Exemplos de sistemas de tempo-real [3] incluem o controlo de centrais de energia nuclear,

sistemas de automao industrial, controlo de experiencias laboratoriais, controlo de motores

automveis, sistemas de telecomunicaes, entre muitos outros. Um exemplo de um sistema

de tempo-real hard o airbag de um automvel, se o airbag for acionado tarde demais (e

tambm neste caso cedo demais) em caso de acidente, o condutor poder correr perigo de

vida pois no ser protegido do impacto.

2.2 Sistemas operativos de tempo-real

A maioria dos sistemas operativos permite executar vrias tarefas simultaneamente apesar

de na verdade cada ncleo do processador apenas pode correr uma nica thread de cada vez.

O escalonador a parte do sistema operativo responsvel por decidir que tarefa ser

executada num dado momento criando a iluso da execuo simultnea atravs da

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 23

alternncia entre threads no processador. De forma a se obter determinismo, num sistema

operativo de tempo-real, o escalonador concebido de maneira a permitir atribuio de

prioridades s tarefas impedindo desta forma que as tarefas de maior prioridade no sero

interrompidas pelas de menor prioridade [4]. Existe tambm muitos outros modelos de

escalonamento, tal como o Earliest Deadline First, por exemplo.

Alguns exemplos de sistemas operativos de tempo-real incluem o FreeRTOS, o RTLinux, o

VxWorks, o QNX, o eCos e o Linux com patch PREEMPT-RT. Sendo que este ultimo foi o

escolhido para este projeto, nas prximas seces ser brevemente descrito o escalonamento

em Linux e em que consiste a patch PREEMPT-RT.

2.2.1 Escalonamento em Linux

Atualmente o escalonamento em Linux [5] est dividido em 3 polticas principais, uma para

tarefas normais do utilizador, designada por SCHED_OTHER que a utilizada por omisso e

duas polticas de escalonamento de tempo-real compatveis com o norma POSIX, designadas

por SCHED_FIFO e SCHED_OTHER, as tarefas escalonadas por estas polticas de tempo-real

nunca sero interrompidas pela tarefas escalonadas pela poltica SCHED_OTHER.

A poltica SCHED_OTHER atualmente implementada seguindo o algoritmo de

escalonamento chamado CFS (Completely Fair Scheduler), este algoritmo tenta maximizar a

utilizao do processador por todas as tarefas de maneira a manter o sistema responsivo ao

utilizador.

Na poltica SCHED_FIFO, so atribudas prioridades s tarefas, sendo as de mesma prioridade

colocadas em filas FIFO (First In First Out), as tarefas de mesma prioridade so executadas por

ordem de chegada sem nunca sarem do processador a no ser que estejam espera de um

recurso ou sejam explicitamente interrompidas a nvel de utilizador.

O escalonamento de tarefas na poltica SCHED_RR difere da SCHED_FIFO na medida que, em

vez de as tarefas com mesma prioridade em vez de serem colocadas numa fila, so alternadas

entre si de forma a todas terem hiptese de obter acesso ao processador diminuindo a

interferncia das tarefas de longa durao sobre as de curta durao.

2.2.2 Patch PREEMPT-RT

Apesar da existncia das polticas de escalonamento tempo-real para o Linux, devido

maneira como o kernel est implementado, existem partes deste que no permitem a

preempo, por causa desta situao, apesar de as tarefas de tempo-real no poderem ser

interrompidas por tarefas normais, elas podem acabar por ser interrompidas por tarefas do

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 24

kernel, isto significa que este tipo de escalonamento seria apenas adequado para tarefas soft

real-time pois no existe garantia de determinismo necessrio para tarefas firm e hard real

time.

Com o objetivo de resolver este tipo de limitaes que a patch RT-PREEMPT [6] foi

desenvolvida, as partes do kernel que no permitiam preempo foram alteradas para o

permitir e foi adicionado suporte a um relgio de alta resoluo fornecendo um nvel de

preciso temporal superior, com estas alteraes o kernel passa a ganhar capacidades hard

real-time.

2.3 Comunicao distribuda de tempo-real

Atualmente, devido a sua disponibilidade, baixo custo e potencial para expansibilidade, a

tecnologia mais utilizada para comunicaes em rede cablada a tecnologia Ethernet, no

entanto, quando esta foi desenvolvida no foi tido em conta o cumprimento de requisitos de

tempo-real sendo por isso geralmente considerada inapropriada para utilizao neste tipo de

aplicaes. Parte deste problema deve-se ao facto de que o acesso rede pelos ns ser feito

atravs do mecanismo CSMA/CD (Carrier Sence Multiple Access with Colision Detection) para

evitar colises em meio partilhado, recorrendo ao mecanismo BEB (Binary Exeponential Back-

Off) para resolver as colises. Estes algoritmos funcionam de maneira no determinstica, o

que os torna inapropriados para comunicao em tempo-real.

A introduo de switches e ligaes full-duplex na rede permite resolver este problema pois

deixa de haver um nico domnio de coliso, deixando de ser necessrio resolver colises. No

entanto, continua a existir o problema de no ser possvel priorizar a transmisso de

mensagens o que por sua vez torna impossvel obter determinismo, um fator essencial para

comunicao em tempo-real.

A Ethernet e outros protocolos que no so de tempo real, focam-se mais na consistncia dos

dados transmitidos entre diferentes ns do que o tempo que estes demoram do n origem ao

n destino. Aplicaes como o email, para um funcionamento correto no necessitam de uma

resposta rpida para o consumo das suas funcionalidades. Se um utilizador envia um email,

este no est preocupado se o email foi recebido no destino em dois ou mais segundos.

Contudo, j em sistemas de tempo-real, especialmente em sistemas crticos, um qualquer

atraso de transmisso de dados pode implicar uma falha do sistema, podendo ocorrer uma

catstrofe com perda de vidas.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 25

Exemplos de tecnologias de comunicao distribuda de tempo real incluem: Asynchronous

Transfer Mode (ATM), Controlled Area Network (CAN) e o protocolo FTT-SE usado neste

projeto.

2.4 Flexible Time Triggered over Switched Ethernet (FTT-SE)

O protocolo Flexible Time Triggered Switched Ethernet (FTT-SE) foi desenvolvido por Ricardo Marau e baseado no protocolo FTT-Ethernet [5], sendo que ambos seguem o paradigma

Flexible Time Triggered FTT [6]. Nas prximas seces ser brevemente descrito o paradigma

FTT, a diferena entre o FTT-SE e o FTT-Ethernet, a arquitetura interna do FTT-SE, em que

que consiste o Elementary Cycle e por fim expostos os tipos e trafego existentes no FTT-SE.

2.4.1 Paradigma Flexible Time Triggered (FTT)

O paradigma FTT baseado no modelo master/slave em que a entidade master o n da rede

que coordena todo o trafego trocado pelos restantes ns slaves. Com esta metodologia

possvel introduzir polticas de escalonamento de mensagens e implementar um mecanismo

de controlo de admisso oferecendo assim garantias de cumprimento de requisitos

temporais.

O funcionamento dos protocolos FTT assenta na existncia de intervalos regulares de durao

pr fixa, chamados de Elementary Cycles (ECs), dentro dos quais so trocadas as mensagens

previamente escalonadas pelo master. A informao sobre o escalonamento comunicada

pelo master, a todos os slaves e no incio de cada EC, atravs da transmisso em broadcast de

uma mensagem designada de Trigger Message (TM). Por sua vez a quando a TM recebida

pelos slaves estes verificam se so transmissores de alguma das mensagens escalonadas

procedendo ento ao envio das mesmas.

2.4.2 FTT-SE vs FTT-Ethernet

Enquanto o FTT-Ethernet foi desenvolvido para funcionar sobre uma rede Ethernet partilhada,

o FTT-SE foi desenvolvido para funcionar sobre uma rede conectada por switches com ligaes

full duplex. Desta maneira a rede torna-se micro-segmentada, onde cada segmento contem o

seu domnio de coliso privado com um nico n na sua extremidade. Como entre cada n e

switch existem dois links: um uplink do switch para o n e um downlink do n para o switch, a

comunicao bidirecional ocorre sem interferncia, o que no o caso com o FTT-Ethernet

pois existe um nico domnio de coliso. Este facto implica que o FTT-Ethernet no poder

fornecer o mesmo nvel de determinismo que o FTT-SE, dado que o seu mecanismo de

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 26

resoluo de colises, apesar de ser mais eficiente que o mecanismo CSMA/CD, no

completamente determinstico.

2.4.3 Arquitetura interna do FTT-SE

Como se pode observar na Figura 1, a arquitetura do FTT-SE divide se em 3 camadas principais

designadas por Interface, Management e Core. Como parte da lgica partilhada por Masters

e Slaves, as camadas Interface e Core encontram-se em ambos enquanto a camada

Management encontra-se apenas no Master.

Figura 1: Arquitetura interna do FTT-SE. [7]

A camada Interface disponibiliza as funes de gesto e de comunicao do protocolo a nvel

aplicacional.

A camada Management, exclusiva do Master onde se encontra a lgica relacionada com a

gesto de Qualidade de Servio e controlo de admisso de mensagens, sendo portanto nesta

camada que os recursos das streams (ligao de dados entre dois ns) so geridos, bem como

tomadas decises face ao registo de novas streams com base na possibilidade de serem ou

no escalonveis.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 27

A camada Core onde gerida a comunicao, nela existe, do lado do Master, uma base de

dados designada por System Requirements Database (SRDB) onde guardada a informao

sobre as streams que se encontram registadas. As mensagens pendentes que se encontram

na SRDB so guardadas pelo Scheduler numa fila chamada de Ready Queue, a qual usada

em cada EC para se efetuar o escalonamento de acordo com a poltica de escalonamento

configurada. Depois de efetuado o escalonamento, as mensagens so colocadas no EC

Register que por usa vez ser usado pelo Dispatcher para construir e enviar a TM.

J do lado do Slave, a camada Core possui uma base de dados designada por Node

Requirements Database (NRDB), esta similarmente a SRDB contem a informao das streams

registadas mas apenas aquelas que dizem respeito ao Slave em questo. Esta informao

usada pelo Dispatacher em conjunto com a TM para verificar se alguma das mensagens

escalonadas corresponde, no caso de ser produtor ou consumidor de alguma delas o

Dispatcher ir iniciar o envio ou receo das mensagens de ou para a Memory Pool

respetivamente.

2.4.4 Elementary Cycle

Tal como foi falado na seco 2.4.1, o Elementary Cycle o intervalo de durao pr fixa

dentro do qual so trocadas as mensagens previamente escalonadas pelo master, sendo que

no incio dele que enviada a TM que contem a informao de escalonamento a ser

processada pelos Slaves.

O Elementary Cycle dividido em vrias partes as quais podem ser analisadas mais facilmente

atravs da Figura 2.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 28

Figura 2: Demonstrao da composio do Elementary Cycle. [7]

A primeira parte designada por Guard Window representa a largura de banda necessria para

a transmisso da TM, a segunda parte designada por Turn-around Window representa a

largura de banda reservada para permitir o processamento da TM pelos Slaves. Existe ainda a

Signalling Window, que composta pelas duas partes anteriores e onde os Slaves podem

enviar para o master sinalizaes de eventos como o registo de streams ou pedidos de envio

de mensagens, estas mensagens de sinalizao so designadas por Signalling Messages.

As partes seguintes designadas por Synchronous Window e Assynchronous Window reservam

a largura de banda para a transmisso de trafego sncrono e assncrono respetivamente, o seu

tamanho pode variar de acordo com a largura de banda necessria para a transmisso de

todas as mensagens sncronas e assncronas que foram escalonadas naquele EC sem, no

entanto, ultrapassar o limite mximo configurado no FTT-SE. Estes dois tipos de trafego sero

descritos em maior detalhe na prxima seco.

2.4.5 Tipos de trfego

No protocolo FTT-SE existem dois tipos de trfego distintos, sncrono e assncrono, a maneira

como estes so escalonados influenciada no s pela poltica de escalonamento configurada

como tambm pelas suas especificidades particulares que sero descritas a seguir:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 29

Trfego sncrono

O trafego sncrono no FTT-SE segue o modelo comunicaes Time-Triggered (TT), isto significa

que as mensagens so trocadas em instantes de tempo peridicos especficos fornecendo

assim um nvel elevado de determinismo. Como foi mencionado na seco 2.4.3 a informao

sobre as streams colocada na SRDB, no caso das mensagens sncronas estas so colocadas

na Synchronous Requirements Table (SRT) que uma parte integrante da SRDB. O conjunto

das streams sncronas constituinte da SRT pode ser definido de acordo com a Equao 1: = { : = ( , , , , , , { 1, , }), = 1, , } Equao 2: Equao da Synchronous Requirements Table (SRT). [7]

Nesta equao cada stream caracterizada pelo Worst-Case Message Length (WCML) , que o tempo mximo de transmisso da mensagem, o deadline , o perodo e o offset que so representados em numero inteiro de ECs, a prioridade , o ID do n produtor e o conjunto de IDs dos ns consumidores { 1, , }. [7] com base nestas propriedades e a poltica de escalonamento configurada no FTT-SE que as

mensagens sncronas pendentes so colocadas no EC Register para posteriormente ser

construda a Trigger Message.

Trfego assncrono

O trafego assncrono segue o modelo Event Triggered (ET), isto significa que a transmisso das

mensagens no est diretamente relacionada com um perodo como no modelo TT mas com

a ocorrncia de um evento, este modelo de transmisso no fornece o mesmo grau de

determinismo que o modelo TT devido a imprevisibilidade da ocorrncia dos eventos [8,9].

Desta forma ao alocar recursos para este tipo de mensagens preciso considerar sempre o

pior caso tendo como base para esse calculo o intervalo mnimo em que as mensagens so

esperadas para serem transmitidas o minimum inter arrival time (Tmit). Tal como no trafego

sncrono como a informao sobre a streams colocada na SRDB com a diferena que neste

caso as mensagens assncronas so colocadas na Assynchronous Requirements Table (ART),

que tambm uma parte integrante da SRDB. O conjunto das streams assncronas

constituinte da ART pode ser definido como na Equao 3 [7]: = {: = ( , , , , { 1, , }), = 1, , } Equao 4: Assynchronous Requirements Table (ART).

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 30

Nesta equao as streams so caracterizadas similarmente s sncronas na SRT, com a

diferena que em lugar do perodo e deadline considerado o minimum inter-arrival

time , que o intervalo mnimo entre a transmisso de mensagens assncronas consecutivas, no sendo tambm considerado o offset.

Ao contrrio das mensagens sncronas que seguem o modelo TT, as mensagens assncronas,

seguindo o modelo ET, fazem uso de um mecanismo de Signalling como mencionado na

seco 2.4.4, desta maneira para quando um evento de uma transmisso de uma mensagem

assncrona gerado no slave produtor, este envia uma SM para o master com a informao

das mensagens pendentes na sua NRDB. A quando da receo das SM dos slaves, o master

colocar essa informao na sua SRDB e proceder ao escalonamento como explicado na

seco 2.4.3. Por causa deste processo de signalling, que implica informar a master do envio

e esperar pela sua resposta, o tempo de resposta de uma mensagem assncrona nunca ser

inferior a dois ECs.

2.5 Paradigma de programao paralela fork/join distribuda

Hoje em dia h uma grande disponibilidade de plataformas multiprocessador que beneficiam

de modelos de execuo paralela para aumentar a sua capacidade de computao,

naturalmente este tipo de modelos tambm trazem vantagens para aplicaes de tempo-real.

Com eles possvel cumprir requisitos temporais mais restritos que de outra forma no seriam

possveis com plataformas uniprocessador. Um dos modelos mais comuns o modelo

fork/join, o qual consiste na execuo sequencial seguida de uma diviso de trabalho (fork)

para ser executado em paralelo, quando as operaes paralelas tiverem terminado, os

resultados so agregados atravs da operao join.

Em sistemas distribudos que possuem vrias unidades de processamento ligadas em rede,

possvel utilizar o modelo fork/join para aproveitar a capacidade de processamento disponvel

em todos os ns. Atendendo ao facto de que a operao de transmisso tem um custo

temporal, preciso ter em considerao que nem sempre poder ser benfico o tempo que

se ganha com distribuio do trabalho face ao tempo que se gasta com as comunicaes.

A Figura 3 representa um exemplo da aplicao do modelo fork/join distribudo que neste

caso foi realizado usando a tecnologia MPI.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 31

Figura 3: Execuo de uma tarefa usando o modelo de execuo paralelo distribudo. [10]

A mesma aproximao pode ser aplicada aos sistemas distribudos de tempo-real, tendo em

conta porm que, a utilizao de um protocolo de transmisso com garantias tempo-real ser

necessria para fornecer as garantias temporais necessrias face ao grau de determinismo

requerido por este tipo de aplicaes.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 32

3 Descrio Tcnica

Neste captulo da descrio tcnica ser abordado o levantamento de requisitos funcionais e

no funcionais bem como a modelao da soluo implementada.

3.1 Levantamento de Requisitos

O processo de levantamento de requisitos um passo fundamental para a anlise de um

projeto, com base nele que e escolhida a metodologia de desenvolvimento mais

apropriada para elaborar a soluo para o problema. Por esta razo nas prximas seces

sero enumerados e descritos os requisitos funcionais e no funcionais.

3.1.1 Requisitos Funcionais

Os requisitos funcionais, que descrevem explicitamente as funcionalidades e servios do

sistema, so enumerados nesta seco.

Fork-Join Parallel-Distributed

Devem ser criadas rotinas que permitam o envio, receo e processamento dados em ns

distribudos, de acordo com o paradigma Fork-Join Parallel/Distributed, tal como descrito na

seco 2.5.

Tarefas de Tempo-real

Devem ser criadas rotinas que permitam a criao de tarefas de tempo-real com atribuio

de prioridades e que se encarreguem da respetiva gesto de periodicidade e verificao de

cumprimento de deadlines.

Integrar Protocolo FTT-SE

O protocolo FTT-SE dever ser integrado na Framework de forma a se obter determinismo e

garantias de tempo-real na transmisso de dados entre os ns distribudos.

3.1.2 Requisitos No Funcionais

Os requisitos no funcionais, que esto relacionados com as qualidades globais ou atributos

do sistema, so enumerados nesta seco.

Usabilidade

A interface da Framework deve ser simplificada e fcil de usar no obstante da necessidade

de alguns conhecimentos da linguagem c e de boas prticas de programao.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 33

A Framework deve ser de alta performance

A Framework dever garantir overheads temporais pequenos e grande previsibilidade

temporal.

3.2 Modelao e desenvolvimento da soluo

Nesta seco ser descrita a abordagem escolhida para a implementao dos requisitos

identificados na seco anterior. Comeando por uma introduo utilizao da Framework,

como ponto de partida para uma caracterizao em maior detalhe dos pormenores de

funcionamento interno das suas funes.

3.2.1 Introduo Parallel Distributed Real-Time Framework (PDRTF)

A Framework PDRTF fornecida como uma biblioteca de linguagem C que permite, atravs

da sua interface, criar e gerir tarefas de tempo-real, que podero ser executadas de forma

distribuda num cluster de computadores, por sua vez este cluster ser configurado atravs

de um ficheiro de configurao.

O cdigo criado fazendo uso desta Framework, ser exatamente o mesmo a ser executado em

todos os ns do cluster, comportando-se de maneira distinta dependendo do n onde

executado. Devido a esta caracterstica, o uso de um ficheiro de configurao para

identificao dos ns, permite que sejam adicionados ou removidos ns ao cluster sem que

seja necessrio recompilar novamente o cdigo.

Devido s exigncias de tempo-real, utilizado o protocolo FTT-SE, descrito em maior detalhe

na seco 2.4, para a comunicao entre os ns, esta tecnologia implica a existncia no cluster

de um n dedicado designado de Master, que se encarregar de gerir a comunicao dos

restantes ns que neste contexto so designados de Slaves.

A fim de melhor compreender a interligao entre todos os elementos descritos nesta seco,

na Figura 4 encontra-se representado o diagrama de Deployment da soluo:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 34

N Master FTT-SE

SwitchEthernet

Ethernet

Ethernet Ethernet

Ethernet Ethernet

N Slave FTT-SE / N local PDRTF

Aplicao Tempo Real

FicheiroConfigurao

FTT-SE

PDRTF

N Slave FTT-SE / N remoto PDRTF 1

Aplicao Tempo Real

FicheiroConfigurao

FTT-SE

PDRTF

N Slave FTT-SE / N remoto PDRTF 2

Aplicao Tempo Real

FicheiroConfigurao

FTT-SE

PDRTF

FTT-SE

N Slave FTT-SE / N remoto PDRTF N

Aplicao Tempo Real

FicheiroConfigurao

FTT-SE

PDRTF

Figura 4: Diagrama de Deployment PDRTF.

Neste diagrama de Deployment o ele e to Apli ao Tempo-real ep ese ta a programao das tarefas de tempo-real que sero realizadas com a PDRTF, tambm ela

representada por um componente. A tecnologia FTT-SE encontra-se representada como um

componente que utilizado pela PDRTF. O ficheiro de configurao, tal como descrito

anteriormente, utilizado pela PDRTF tambm se encontra neste diagrama.

3.2.2 Como utilizar a Framework PDRTF.

Nesta seco ser demonstrada a aplicao prtica da utilizao da Interface C e do ficheiro

de configurao da Framework PDRTF na programao de um conjunto de tarefas distribudas

de tempo-real.

Para programar tarefas distribudas de tempo-real utilizando a PDRTF necessrio seguir 3

passos importantes:

1. Adicionar o nome da placa de rede e endereo Mac de cada n do cluster ao ficheiro

de configurao.

2. Programar no ponto de entrada main()do programa C o mapeamento das tarefas

com as respetivas propriedades de tempo-real e atribuir aos ns remotos do cluster

as partes paralelas/remotas de cada tarefa.

3. Programar para cada tarefa que foi adicionada, como descrito no ponto anterior, as

funes que representam a parte local e remota e sero executadas como callbacks

pela PDRTF.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 35

Antes de continuar, ser importante mencionar que, devido a existncia de vrios conceitos

diferentes, a explicao de todos eles ao mesmo tempo pode-se tornar uma tarefa complexa,

podendo dificultar a sua compreenso. Assim, de forma a melhor os explicar, o segundo e

terceiro passos sero considerados como aes separadas, apesar de na prtica acabarem por

ser aplicados em conjunto como um nico s.

Primeiro passo: Configurao do cluster.

Como foi descrito anteriormente a PDRTF identifica o n onde est a executar atravs da

informao contida no ficheiro de configurao, este ficheiro de configurao contem, para

cada um dos ns, o nome e endereo Mac da placa de rede Ethernet que vai ser utilizada. Esta

estrutura permite tambm, no caso de existirem vrias placas de rede no n, especificar qual

delas se pretende utilizar. No Excerto de Cdigo 1 encontra-se o ficheiro de configurao com

a configurao utilizada durante o desenvolvimento e testes da PDRTF:

# config.cfg

# Ficheiro de configurao PDRTF.

# Endereo mac do n local e nome da placa de rede usada.

local_node_mac_address = "e4:11:5b:56:8f:eb"; local_node_device_name = "eth0"; # Conjunto dos ns remotos. remote_nodes = ( { # N remoto 1. mac_address = "e4:11:5b:56:8f:86"; device_name = "eth0"; }, { # N remoto 2. mac_address = "e4:11:5b:56:8f:66"; device_name = "eth0"; }, { # N remoto 3. mac_address = "e4:11:5b:56:8f:bc"; device_name = "eth0"; });

Excerto de Cdigo 1: Exemplo de ficheiro de configurao

Como se pode observar existe uma distino clara entre o n local e os ns remotos no ficheiro

de configurao, os ns remotos so agrupados em conjunto sendo que a sua posio

corresponde ao nmero que os identificar. Os comentrios presentes no ficheiro de

configurao, identificados atravs da presena do caracter # no seu incio, foram colocados

de maneira a melhor elucidar e complementar esta explicao. A prxima Figura 5 fornecer

uma representao grfica da configurao descrita neste exemplo.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 36

SwitchEthernet

N local PDRTF

Placa de rede: eth0Endereo MAC:

e4:11:5b:56:8f:eb

N Remoto 1 PDRTF

Placa de rede: eth0 Endero MAC:

e4:11:5b:56:8f:86

N Remoto 3 PDRTF

Placa de rede: eth0Endereo MAC:

e4:11:5b:56:8f:bc

N Remoto 2 PDRTF

Placa de rede: eth0Endereo MAC:

e4:11:5b:56:8f:66

Ethernet

Ethernet

Ethernet

Ethernet

Figura 5: Configurao utilizada durante o desenvolvimento e testes da PDRTF.

Segundo passo: Mapear tarefas com a interface C PDRTF

Depois de adicionados os dados dos ns ao ficheiro de configurao, o prximo ser a

programao, no ponto de entrada main() do programa C, do mapeamento das tarefas com

as respetivas propriedades de tempo-real.

A programao das tarefas dever seguir o modelo fork/join distribudo, como explicado na

seco 2.5, onde as tarefas so divididas em parte local e parte remota. Devido a natureza do

sistema distribudo, no existe memria partilhada entre elas, isto significa que a parte remota

tem de receber todos os dados partilhados que necessitar como parmetro de entrada,

retornando por sua vez parte local todos os dados necessrios como parmetros de sada.

Por esta razo, a PDRTF p e isa ue toda esta i te ao seja apeada de forma a poder preparar todas as condies necessrias para a sua execuo. De forma a melhor explicar este

conceito de mapeamento das tarefas, encontra-se no Excerto de Cdigo 2 um exemplo que

contempla a programao de duas tarefas, cada uma com duas partes remotas/paralelas:

void main() {

pdrtf_start();

int id_tarefa_x = new_pdrtf_task(tarefa_x_parte_local, 150, 48); set_pdrtf_task_sub_task(id_tarefa_x, 1, tarefa_x_parte_remota_1, sizeof(int), sizeof(char)); set_pdrtf_task_sub_task(id_tarefa_x, 2, tarefa_x_parte_remota_2, sizeof(double), sizeof(float));

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 37

int id_tarefa_y = new_pdrtf_task(tarefa_y_parte_local, 300, 47); set_pdrtf_task_sub_task(id_tarefa_y, 1, tarefa_y_parte_remota_1, 200, 100); set_pdrtf_task_sub_task(id_tarefa_y, 3, tarefa_y_parte_remota_2, 1000, 2000);

pdrtf_launch_tasks();

}

Excerto de Cdigo 2: Exemplo de utilizao PDRTF no ponto de entrada main().

Neste exemplo possvel observar a sequncia de instrues a seguir durante o mapeamento

das tarefas, o significado de cada uma delas ser explicado de seguida:

A funo pdrtf_start() a primeira a ser executada e no faz uso de qualquer parmetro

de entrada, esta responsvel por acionar a leitura do ficheiro de configurao e inicializao

da biblioteca FTT-SE,

A funo new_pdrtf_task() tem como funo adicionar lista interna da PDRTF uma nova

tarefa a ser executada, aps a sua execuo esta funo retorna um valor inteiro que

representa o ID da tarefa criada, este ID ser utilizado posteriormente para mapear nos ns

remotos as respetivas partes remotas dessa tarefa. Os parmetros desta funo so

enumerados e descritos em seguida:

void * function_ptr Este o primeiro parmetro da funo, ele contem o

apontador para a funo com a especificao da execuo local da tarefa. Esta

especificao ser descrita mais a frente na terceira fase.

unsigned short period_in_ms Este o segundo parmetro da funo, ele

contem o perodo/deadline em milissegundos da tarefa.

unsigned short linux_priority Este o terceiro e ultimo parmetro da

funo, ele contem a prioridade Linux de tempo-real que ser atribuda tarefa. Este

parmetro pode tomar um valor entre 1 e 48. Um nmero maior corresponde a uma

prioridade superior a um nmero inferior.

A funo set_pdrtf_task_sub_task() tem como funo atribuir a uma tarefa

previamente adicionada pela funo new_pdrtf_task() a parte remota a executar num dos

ns disponveis. De forma a melhor explicar esta operao, em seguida ser apresentada uma

figura que representa a disposio no cluster do mapeamento das tarefas caracterizado na

Figura 8:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 38

SwitchEthernet

Ethernet

Ethernet

Ethernet

Ethernet

N Local PDRTF

Tarefa x ID = 1

(tarefa_x_parte_local)

Tarefa y ID = 2

(tarefa_y_parte_local)

N Remoto 1 PDRTF

Tarefa x ID = 1

(tarefa_x_parte_Remota_1)

Tarefa y ID = 2

(tarefa_y_parte_remota_1)

N Remoto 3 PDRTF

Tarefa x ID = 1

(inactiva)

Tarefa y ID = 2

(tarefa_y_parte_remota_2)

N Remoto 2 PDRTF

Tarefa x ID = 1

(tarefa_x_parte_Remota_2)

Tarefa y ID = 2

(inactiva)

Figura 6: Disposio das partes locais e remotas das tarefas no cluster.

Cada tarefa tem a sua disposio todos os ns remotos do cluster e pode atribuir uma parte

remota de execuo a cada um deles, no tendo obrigatoriamente de o fazer para todos.

Neste exemplo, para demonstrar esta possibilidade, foram apenas mapeadas partes remotas

nos ns 1 e 2 para a tarefa x, enquanto para a tarefa y, apenas foram mapeadas partes remotas

nos ns 1 e 3. Os parmetros desta funo so enumerados e descritos em seguida:

unsigned short pdrtf_task_id Este o primeiro parmetro da funo , contem

o ID da tarefa qual se pretende mapear uma parte remota. Este id ter sido

retornado pela funo new_pdrtf_task(), a quando da criao da tarefa.

unsigned short node_id Este o segundo parmetro da funo, ele contem o

ID do n remoto ao qual se pretende mapear a parte remota. Para cada tarefa s

possvel mapear uma parte remota por n, no sendo obrigatrio que o seja feito.

void * function Este o terceiro parmetro da funo, ele contem o apontador

para a funo com a especificao da execuo remota da tarefa. Esta especificao

ser descrita mais a frente.

unsigned short input_data_size Este o quarto parmetro da funo, ele

contem o tamanho em bytes dos parmetros de entrada da parte remota.

unsigned short output_data_size Este o quinto e ultimo parmetro da

funo, ele contem o tamanho em bytes dos parmetros de sada da parte remota.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 39

A funo pdrtf_launch_tasks() a ultima a ser executada e no faz uso de qualquer

parmetro de entrada, esta encarregar-se- de iniciar a abertura das Streams FTT-SE entre os

ns do cluster, que sero usadas na comunicao tempo-real entre os ns, e de criar e lanar

as threads que executaro as tarefas de tempo-real.

Terceiro passo: Programar parte local e remota de cada tarefa

neste terceiro passo que sero programadas a parte local e as partes remotas de cada tarefa.

De forma a melhor compreender como programar estas partes de uma tarefa, comearemos

por fornecer um exemplo simplificado do cdigo local e remoto, necessrio para programar a

tarefa x do exemplo anterior, que possui execuo distribuda em 2 ns remotos. Como o

processo ser o mesmo para qualquer tarefa, a programao da tarefa y no ser includa

neste exemplo.

void * tarefa_x_parte_local (void * param_pdrtf){

/* execuo sequencial */ ()

int param_entrada_1; double param_entrada_1; pdrtf_launch_remote_execution(param_pdrtf, &param_entrada_1, sizeof (int), 1); pdrtf_launch_remote_execution(param_pdrtf, &param_entrada_2, sizeof (double), 2);

/* execuo local */ ()

char param_saida_1; float param_saida_2; pdrtf_get_remote_execution_result(param_pdrtf, &param_saida_1, sizeof (char), 1); pdrtf_get_remote_execution_result(param_pdrtf, &param_saida_2, sizeof (float), 2)

/* processar dados recebidos */ ()

}

void * tarefa_x_parte_remota_1 (void * param_pdrtf){

int param_entrada_1; pdrtf_get_input_parameters(param_pdrtf, &param_entrada_1, sizeof (int));

/* execuo remota */ /* processar dados recebidos e retornar resultados */ ()

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 40

char param_saida_1; pdrtf_set_output_parameters(param_pdrtf, &param_saida_1, sizeof (char));

} void * tarefa_x_parte_remota_2 (void * param_pdrtf){

double param_entrada_2; pdrtf_get_input_parameters(param_pdrtf, &param_entrada_2, sizeof (double));

/* execuo remota */ /* processar dados recebidos e retornar resultados */ ()

float param_saida_2; pdrtf_set_output_parameters(param_pdrtf, &param_saida_2, sizeof (float));

}

Excerto de Cdigo 3: Exemplo simplificado do cdigo local e remoto

De forma a ajudar compreenso deste exemplo de cdigo, apresentada uma

representao visual de como se processa a interao entre a parte local e remota atravs do

diagrama de sequncia da Figura 7 e diagramas de estado da Figura 8 e 9:

N local N Remoto 1 N Remoto 2

Ativao da parte local

Execuo sequencial

pdrtf_launch_remote execution() Ativao da parte remota

pdrtf_launch_remote execution() Ativao da parte remota

pdrtf_get_input_parameters()

Execuo Remota

pdrtf_set_output_parameters()

pdrtf_get_remote execution_results()

pdrtf_get_remote execution_results()

Processar dados recebidos

pdrtf_get_input_parameters()

Execuo Remota

pdrtf_set_output_parameters()

Fim de execuo remota Fim de execuo remota

Fim de execuo local

Execuo local

Figura 7: Diagrama de sequncia da Interao entre parte local e remota da tarefa.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 41

Figura 8: Diagrama de estados da parte remota da tarefa.

Ser importante mencionar que este exemplo foca-se apenas na troca de informao entre a

parte local e remota, que parte relevante para implementar o modelo fork/join, os restantes

detalhes da lgica da tarefa que sero deixados a cargo do programador esto representados

n cdigo atravs de comentrios.

A assinatura da funo local e remota dever ser do tipo void * porque ser executada

como uma callback pela Framework e dever ter um nico parmetro de entrada tambm do

tipo void *, nomeado neste exemplo de param_pdrtf, que ser fornecido pela Framework

durante a execuo. Este parmetro de entrada contem uma estrutura de controlo que ser

utilizada em todas as chamadas Framework de forma a identificar a tarefa.

pdrtf_get_input_parameters()

Execuo remota

pdrtf_set_output_parameters()

Parmetro de entrada:estrutura de controlo

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 42

pdrtf_launch_remote_execution()

Lanar mais execues remotas?

Sim

Execuo remota

No

Execuo local

pdrtf_get_remote_execution_results()

Execuo distribuda

Obter resultados de mais execues remotas?

SimNo

Execuo sequncial

Execuo sequncial

Processar dados recebidos das execues remotas

Parmetro de entrada:estrutura de controlo

S possvel lanar execues remotas

para ns que tenham sido prviamente

configurados para a tarefa em questo

Figura 9: Diagrama de estados da parte local da tarefa.

A funo pdrtf_launch_remote_execution() utilizada apenas na parte local da tarefa

e responsvel por iniciar o envio dos parmetros de entrada da funo remota para o n

onde ela estiver configurada para executar. Como se pde observar no diagrama de sequncia

anterior este envio tambm responsvel por despoletar a execuo da parte remota. Os

parmetros desta funo so agora enumerados e descritos:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 43

void * task_data: Este o primeiro parmetro da funo, e como j foi descrito

anteriormente, ele contm a estrutura de controlo que permite Framework

identificar a tarefa, este parmetro ser fornecido atravs do parmetro de entrada

da funo local ou remota.

void * input_parameters: Este o segundo parmetro da funo e

corresponde a um apontador C de tipo indefinido para posio de memria onde se

encontram os dados dos parmetros da funo remota a serem enviados.

unsigned short input_parameters_size: Este o terceiro parmetro da

funo e corresponde ao tamanho dos dados que so apontados pelo parmetro

input_parameters. Esta informao necessria porque a Framework permite

enviar qualquer tipo de dados entre os ns, prevendo a utilizao de estruturas de

dados criadas pelo programador de tamanho desconhecido. Este facto tambm

explica a razo do uso de um apontador de tipo indefinido void *. Alm disso

tambm serve como verificao do cumprimento do tamanho fixo dos parmetros de

entrada, pr-estabelecido durante a fase de mapeamento de tarefas.

unsigned short pdrtf_node_id: Este o quarto e ltimo parmetro da funo

e contem a identificao do n para o qual esto a ser enviados os parmetros de

entrada da funo remota. Este parmetro dever corresponder a um n que exista

no cluster e tenha sido configurado durante a fase de mapeamento de tarefas.

A funo pdrtf_get_remote_execution_results() utilizada apenas na parte local da

tarefa e responsvel por iniciar a receo dos parmetros de sada da funo remota do n

onde ela estiver configurada para executar. Caso, a quando da chamada desta funo, o

processamento remoto no estiver concludo, a execuo local bloquear at que a execuo

remota termine e a mensagem seja recebida. Os parmetros desta funo so agora

enumerados e descritos:

void * task_data: Este o primeiro parmetro da funo, e como j foi descrito

anteriormente, ele contm a estrutura de controlo que permite Framework

identificar a tarefa, este parmetro ser fornecido atravs do parmetro de entrada

da funo local ou remota.

void * output_parameters: Este o segundo parmetro da funo e

corresponde a um apontador C de tipo indefinido para posio de memria onde

sero copiados os dados dos parmetros de sada da funo remota que forem

retornados.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 44

unsigned short output_parameters_size: Este o terceiro parmetro da

funo e corresponde ao tamanho dos dados que so apontados pelo parmetro

output_parameters. Esta informao necessria porque a Framework permite

enviar qualquer tipo de dados entre os ns, prevendo a utilizao de estruturas de

dados criadas pelo programador de tamanho desconhecido. Este facto tambm

explica a razo do uso de um apontador de tipo indefinido void *. Alm disso

tambm serve como verificao do cumprimento do tamanho fixo dos parmetros de

sada, pr-estabelecido durante a fase de mapeamento de tarefas.

unsigned short pdrtf_node_id: Este o quarto e ltimo parmetro da funo

e contem a identificao do n a partir do qual sero recebidos os parmetros de

sada da funo remota. Este parmetro dever corresponder a um n que exista no

cluster e tenha sido configurado durante a fase de mapeamento de tarefas.

A funo pdrtf_get_input_parameters() utilizada apenas na parte remota da tarefa e

responsvel por obter os parmetros de entrada que foram recebidos a quando da sua

ativao. Os parmetros desta funo so agora enumerados e descritos:

void * task_data: Este o primeiro parmetro da funo, e como j foi descrito

anteriormente, ele contm a estrutura de controlo que permite Framework

identificar a tarefa, este parmetro ser fornecido atravs do parmetro de entrada

da funo local ou remota.

void * data: Este o segundo parmetro da funo e corresponde a um

apontador C de tipo indefinido para posio de memria onde sero copiados os

dados dos parmetros de entrada da funo remota que foram recebidos.

unsigned short data_size: Este o terceiro e ultimo parmetro da funo e

corresponde ao tamanho dos dados que so apontados pelo parmetro data. Esta

informao necessria porque a Framework permite enviar qualquer tipo de dados

entre os ns, prevendo a utilizao de estruturas de dados criadas pelo programador

de tamanho desconhecido. Este facto tambm explica a razo do uso de um

apontador de tipo indefinido void *. Alm disso tambm serve como verificao do

cumprimento do tamanho fixo dos parmetros de sada, pr-estabelecido durante a

fase de mapeamento de tarefas.

A funo pdrtf_set_output_parameters() utilizada apenas na parte remota da tarefa

e responsvel por guardar os parmetros de sada que forem produzidos a quando da sua

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 45

execuo, sendo posteriormente enviados de volta para a parte local da tarefa. Os parmetros

desta funo so agora enumerados e descritos:

void * task_data: Este o primeiro parmetro da funo, e como j foi descrito

anteriormente, ele contm a estrutura de controlo que permite Framework

identificar a tarefa, este parmetro ser fornecido atravs do parmetro de entrada

da funo local ou remota.

void * data: Este o segundo parmetro da funo e corresponde a um

apontador C de tipo indefinido para posio de memria a partir de onde sero

copiados os dados dos parmetros de sada da funo remota que foram produzidos.

unsigned short data_size: Este o terceiro e ultimo parmetro da funo e

corresponde ao tamanho dos dados que so apontados pelo parmetro data. Esta

informao necessria porque a Framework permite enviar qualquer tipo de dados

entre os ns, prevendo a utilizao de estruturas de dados criadas pelo programador

de tamanho desconhecido. Este facto tambm explica a razo do uso de um

apontador de tipo indefinido void *. Alm disso tambm serve como verificao do

cumprimento do tamanho fixo dos parmetros de sada, pr-estabelecido durante a

fase de mapeamento de tarefas.

3.2.3 Funcionamento interno das funes da API

Esta seco ir descrever o funcionamento interno da API da PDRTF descrevendo as funes

pela ordem que apareceram na seco anterior. Internamente a PDRTF faz uso de um

componente designado de FTT-SE Wrapper para lidar com a biblioteca do FTT-SE. As

chamadas internas ao FTT-SE Wrapper sero demonstradas nesta seco quando necessrio,

no entanto a descrio detalhada do seu funcionamento ser deixado para a prxima seco,

a qual ser dedicada ao componente FTT-SE Wrapper.

3.2.3.1 pdrtf_start()

Esta funo a primeira ser executada, entre outras operaes, ela altera a poltica de

escalonamento da thread em execuo para a poltica de tempo-real SCHED_FIFO e define a

prioridade da tarefa como 49. Este facto merece especial ateno e est diretamente

relacionado com o uso da biblioteca FTT-SE, sendo a seguir explicada a sua razo.

A biblioteca FTT-SE foi desenvolvida para trabalhar em Linux e RTLinux que um sistema

operativo tempo-real. No nosso caso, como o RTLinux no uma distribuio open-source foi

colocada de parte a sua utilizao, no entanto, devido a necessidade de um sistema operativo

de tempo-real, o Linux foi aqui utilizado com recurso a patch Preempt RT como descrito na

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 46

seco 2.2.2. Durante a integrao da PDRTF com a tecnologia FTT-SE foram encontradas as

seguintes condicionantes:

Ao correr threads de tempo-real em concorrncia com as threads da biblioteca FTT-

SE, se as ultimas no tiverem prioridade sobre todas as outras, sero objeto de

preempo. Como do lado dos Slaves necessria constante verificao da Trigger

Message, se este processo for interrompido o FTT-SE falhar.

Se as threads em execuo tiverem uma prioridade igual ou superior as threads do

kernel, que possuem prioridade de nvel 50, o mesmo poder eventualmente suceder.

A observao deste facto leva a crer que o FTT-SE depende de chamadas ao sistema,

atendendo ao facto que no caso da patch Preempt RT o kernel do sistema operativo

passa a ser completamente preemptvel, a existncia de chamadas ao sistema em

outras threads poder levar a que o acesso a estes recursos pelo FTT-SE seja

interrompido, causado o problema aqui descrito.

Apesar destas condicionantes as restantes qualidades da patch Preempt RT justificam ainda

assim a sua utilizao. Alem do mais, apesar desta situao significar que garantias de tempo-

real Hard no podero ser garantidas, a utilidade do desenvolvimento e estudo da PDRTF

mantem-se. Desta maneira, como a resoluo mais aprofundada destas condicionantes se

encontra fora do mbito deste projeto, para este caso de estudo, assumiu-se que as threads

FTT-SE correriam com uma prioridade 49, que se encontra abaixo da prioridade das tarefas da

kernel do Linux, e que as tarefas criadas e geridas pela PDRTF teriam uma prioridade inferior

a 49 de forma a no interromperem a execuo das threads do FTT-SE.

Voltando a explicao da funo pdrtf_start(), a definio da thread corrente para a prioridade

49 garante que as threads do FTT-SE criadas durante a sua inicializao partilharo a mesma

prioridade.

A prxima ao a ser executada a leitura do ficheiro de configurao, para determinar em

que n se encontra a executar, aps o seu trmino ser despoletado por intermdio do FTT-

SE Wrapper a inicializao da biblioteca FTT-SE na placa de rede configurada. Caso termine

com sucesso retornar 1 ou retornar um nmero negativo em caso de erro. O processo aqui

explicado encontra-se representado na Figura 15 por um diagrama de estados:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 47

pdrtf_start()

sched_setscheduler(0, SCHED_FIFO, &priority)

read_configuration()

ftt_se_wrapper_start(device_name)

priority.sched_priority = 49

get_node_device_name()

Figura 10: Mquina de estados da funo pdrtf_start()

De forma a melhor se compreender o processo da leitura do ficheiro de configurao,

encontra-se na Figura 17 um diagrama de estados detalhando o funcionamento da funo

read_configuration():

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 48

Ficheiro existe

Erro de Configurao

NoSim

Abre Ficheiro de configurao

L nome de placa de rede

e endereo mac do n local

SimNo

L numero de ns remotos

Placa de rede existente Concide com n local

Define n em execuo como n local

Sim No

N em execuo o n local?

Sim

Erro de Sintaxe

No

Define n em execuo como n remoto e guarda o seu id

L nome de placa de rede e

endereo mac do prximo n remoto

Existem ns remotos por verificar?

No

Sim No (Este n no foi configurado)

Placa de rede existente concide com n remoto lido

Sim

read_configuration()

Configurao lida com Sucesso

Figura 11: Diagrama de estados do processo de Leitura do ficheiro de configurao.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 49

3.2.3.2 new_pdrtf_task()

A funo new_pdrtf_task() adiciona uma nova tarefa lista interna do PDRTF. Ela comea

por verificar se o apontador para a funo da parte local function_ptr vlido e se a

prioridade da tarefa linux_priority est dentro do intervalo entre 1 e 48. Verificando-se

estas condies, ela alocar memria para uma nova posio da lista interna de tarefas e

guardar os parmetros introduzidos. Caso termine com sucesso retornar um nmero

positivo com a identificao da tarefa seno retornar um nmero negativo representativo do

erro.

3.2.3.3 set_pdrtf_task_sub_task()

A funo set_pdrtf_task_sub_task()atribu a um n disponvel de uma tarefa, uma

parte remota de execuo. Ela comea por verificar se o id da tarefa pdrtf_task_id e o id

do n remoto node_id existem e se o apontador para a funo da parte remota function

vlido. Aps essas verificaes ir guardar, para a tarefa existente na lista interna, no n

escolhido, o apontador da funo da parte remota de execuo e respetivos tamanhos dos

parmetros de entrada input_data_size e sada output_data_size. A condio do n

perante a tarefa passar para ativo. Caso termine com sucesso retornar 1, seno retornar

um nmero negativo representativo do erro.

3.2.3.4 pdrtf_launch_tasks()

A funo pdrtf_launch_tasks()ir percorrer as tarefas guardadas na lista interna de

tarefas e com essa informao tratar de primeiro criar as streams que sero necessrias a

comunicao entre os ns e a seguir de criar e lanar as threads que iro executar as respetivas

partes locais e remotas das tarefas. Na Figura 12 encontra-se um diagrama de estados

representativo da criao das streams para o n local:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 50

Existem tarefas por verificar?

NoSim

Existem ns remotos da tarefa por verificar?

No Sim

N remoto da tarefa activo?

NoSim

ftt_se_wrapper_new_stream()

-ID da stream = ID da tarefa * 1000 + ID do n * 10

ftt_se_wrapper_new_stream()

-ID da stream = ID da tarefa * 1000 + ID do n * 10 + 1

ftt_se_wrapper_set_stream_parameters()

-tamanho da stream = tamanho dos parmetros de entrada-MIT da stream = 2 ECs

ftt_se_wrapper_set_stream_parameters()

-tamanho da stream = tamanho dos parmetros de sada-MIT da stream = 2 ECs

ftt_se_wrapper_initialize_producer()

ftt_se_wrapper_initialize_consumer()

Figura 12: Diagrama de estados da criao de streams no n local

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 51

Neste diagrama, possvel observar que, para cada parte remota, sero criadas duas streams,

correspondentes entrada e sada dos seus parmetros, e apenas para os ns que estiverem

ativos, ou seja, os ns que foram mapeados atravs da funo

set_pdrtf_task_sub_task().

Primeiro, ser chamada a funo ftt_se_wrapper_new_stream() que ir alocar a posio

de memoria onde guardar as definies da stream, correspondentes ao seu id, tipo (sncrona

ou assncrona) e numero de posies do buffer. Como a primeira stream a ser definida a de

entrada para o n, o seu id ser dado pela frmula (ID da tarefa * 1000 + ID do n * 10) como

demonstrado no diagrama. A stream ser do tipo assncrono, pois a natureza das mensagens

sncronas FTT-SE impossibilita a sua utilizao neste contexto. O buffer ter apenas uma

posio, pois nunca ser enviada uma nova mensagem na mesma stream sem que a anterior

tenha sido consumida.

A segunda funo chamada ser a funo ftt_se_wrapper_set_stream_parameters()

que ir definir as restantes propriedades da stream, nomeadamente o seu tamanho, o

tamanho do MTU a usar e o seu perodo/MIT. Neste caso o seu tamanho corresponde ao

tamanho dos parmetros de entrada da funo remota, o tamanho de MTU escolhido de

1450 bytes, que ser o mesmo a usar em todas as streams, por fim o Perodo/MIT escolhido

ser de 2 Elementary Cycles, que o mnimo exigvel de uma stream FTT-SE do tipo assncrono

como descrito na seco 2.4.5. A escolha do valor mnimo baseia-se na necessidade das

aplicaes de tempo-real distribudas dependerem no s do determinismo, como do

desempenho mximo possvel da transmisso de forma a reduzir o overhead associado,

maximizando o ganho face paralelizao.

A terceira funo chamada ser a funo ftt_se_wrapper_initialize_producer()que

ir efetivamente abrir a stream criada sendo o n o produtor da mesma.

Para a stream correspondente a sada da parte remota, as chamadas as funes

ftt_se_wrapper_new_stream() e ftt_se_wrapper_set_stream_parameters()

sero iguais as anteriores com a diferena que o id da stream ser dado pela frmula (ID da

tarefa * 1000 + ID do n * 10 + 1) e o tamanho da stream corresponder ao tamanho dos

parmetros de sada da funo remota.

Por fim ser chamada a funo ftt_se_wrapper_initialize_consumer()que ir

efetivamente abrir a stream criada sendo o n o consumidor da mesma.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 52

Na Figura 13 encontra-se um diagrama de estados representativo da criao das streams para

o n remoto:

Existem tarefas por verificar?

Sim

No

N remoto em execuo est activo?

Sim

ftt_se_wrapper_new_stream()

-ID da stream = ID da tarefa * 1000 + ID do n * 10

No

ftt_se_wrapper_new_stream()

-ID da stream = ID da tarefa * 1000 + ID do n * 10 + 1

ftt_se_wrapper_initialize_consumer()

ftt_se_wrapper_initialize_producer()

Figura 13: Diagrama de estados da criao de streams no n remoto

Neste diagrama possvel observar o processo de criao das streams do lado do n remoto,

este processo assemelha-se ao do n local com algumas diferenas: apenas so abertas

streams referentes ao prprio n, a funo

ftt_se_wrapper_set_stream_parameters() no chamada pois s precisa de ser

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 53

chamada no n local. Em vez de produtor consumidor da stream de entrada, e em vez de

consumidor produtor da stream de sada.

De forma a complementar a explicao anteriorna Figura 14 encontra-se uma representao

grfica de um exemplo de atribuio dos ids s streams para duas tarefas, cada uma com

partes remotas em dois ns.

N Local

Tarefa 1

N Remoto 1

Tarefa 1

ID da Stream Input 1010

ID da Stream Output 1011

ID da Stream Input 2010

ID da Stream Output 2011Tarefa 2

Tarefa 2

N Remoto 2

Tarefa 1ID da Stream Output 1021

ID da Stream Input 2020

ID da Stream Output 2021Tarefa 2

ID da Stream Input 1020

Figura 14: Exemplo de atribuio de ids s streams para duas tarefas com dois ns remotos.

Depois de criadas as streams ser ento a vez de serem criadas as threads que executaram as

partes locais e remotas das tarefas. De forma a melhor explicar este processo na Figura 15 e

16 encontram se os diagramas de estado que descrevem este processo tanto do lado do n

local como do lado do n remoto:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 54

Criao de threads no n local

Existem tarefas por lanar?

NoSim

Cria estrutura de controlo para a thread

-ID da tarefa

Cria thread

-prioridade definida pelo utilizador para a tarefa-estrutura de controlo como parmetro

Figura 15: Diagrama de estados da criao de threads no n local

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 55

Existem tarefas por verificar?

Criao de threads no n remoto

Sim

No

N remoto em execuo est activo?

No

Cria estrutura de controlo para a thread

-ID da tarefa-ID do n remoto em execuo

Cria thread

-Prioridade definida pelo utilizador para a tarefa-estrutura de controlo como parmetro

Sim

Figura 16: Diagrama de estados da criao de threads no n remoto

Depois de criadas as threads estas encarregar-se-o de chamar as funes especificadas para

as partes locais e remotas das tarefas como se pode observar nos prximos diagramas de

estado representados na Figura 17 e 18:

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 56

Execuo da thread no n local

Prxima ativao = tempo actual do sistema

Executa callback da tarefa

-estrutura de contolo como parmetro

Instante final = tempo actual do sistema

Instante final < prxima ativao

No (falhou deadline)Sim (cumpriu deadline)

Espera at prxima ativao

Proxima ativao +=

periodo/deadline da tarefa

Notificao de deadline falhada

Parmetro de entrada:estrutura de controlo

Figura 17: Diagrama de estados da execuo da thread no n local.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 57

Execuo da thread no n remoto

Espera por recepo na stream input

Guarda parmetros de entrada recebidos

No

Falhou recepo?

Sim

Executa callback remota

-estrutura de controlo como parmetro

Obtem parmetros de sada produzidos

pela execuo

Efetua envio dos parmetros de saida

na stream output

Falhou envio?

SimNo

Parmetro de entrada:estrutura de controlo

Figura 18: Diagrama de estados da execuo da thread no n remoto.

3.2.3.5 pdrtf_launch_remote_execution()

A funo pdrtf_launch_remote_execution() responsvel por executar o envio dos

parmetros de entrada da funo remota para o n onde ela se encontra a executar. Esta

funo comea por verificar se a estrutura de controlo task_data vlida e o id do n

pdrtf_node_id existe e est ativo, verifica se o apontador da mensagem a enviar

input_parameters vlido e se o tamanho da mensagem input_parameters_size

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 58

coincide com o tamanho especificado pela funo set_pdrtf_task_sub_task()durante

a fase de mapeamento de tarefas.

Depois de verificados os parmetros de entrada ela chamar a funo

ftt_se_wrapper_send() que acionar o envio da mensagem para o n escolhido, atravs

da stream de entrada da parte remota da tarefa.

3.2.3.6 pdrtf_get_remote_execution_result()

A funo pdrtf_get_remote_execution_results() responsvel por acionar a reco

dos parmetros de sada da funo remota a partir do n onde ela se encontra a executar.

Esta funo comea por verificar se a estrutura de controlo task_data vlida e o id do n

pdrtf_node_id existe e est ativo, verifica se o apontador da mensagem a receber

output_parameters vlido e se o tamanho da mensagem output_parameters_size

coincide com o tamanho especificado pela funo set_pdrtf_task_sub_task()durante

a fase de mapeamento de tarefas.

Depois de verificados os parmetros de entrada ela chamar a funo

ftt_se_wrapper_receive() que acionar a receo da mensagem a partir do n

escolhido, atravs da stream de saida da parte remota da tarefa.

3.2.3.7 pdrtf_get_input_parameters()

A funo pdrtf_get_input_parameters() responsvel por fornecer os parmetros de

entrada funo da parte remota da tarefa. Esta funo comea por verificar se a estrutura

de controlo task_data vlida, se o apontador data para a posio de memoria onde os

parmetros sero copiados tambm vlida e se o tamanho dessa posio data_size

coincide com o tamanho especificado pela funo set_pdrtf_task_sub_task()durante

a fase de mapeamento de tarefas.

Depois de verificados os parmetros de entrada ela copiar para a posio em questo os

parmetros de entrada.

3.2.3.8 pdrtf_set_output_parameters()

A funo pdrtf_set_otput_parameters() responsvel por guardar os parmetros de

sada produzidos pela funo da parte remota da tarefa. Esta funo comea por verificar se

a estrutura de controlo task_data vlida, se o apontador para posio de memoria data

a partir de onde os parmetros sero copiados tambm vlida e se o tamanho dessa posio

data_size coincide com o tamanho especificado pela funo

set_pdrtf_task_sub_task()durante a fase de mapeamento de tarefas.

Framework para Sistemas Distribudos de Tempo-real

Roberto Duarte 59

Depois de verificados os parmetros de entrada ela copiar dessa posio para o buffer

interno para posteriormente serem enviados de volta para o n local.

3.2.4 Descrio da API do mdulo FTT-SE Wrapper

Devido a complexidade da interface da bibl