Figura 5.11: Integração entre os modelos de simulação, algoritmos de exploração e o frameworkAkaroa.
tempo máximo entre a saída e chegada do token nos arcos do modelo HSDG que estão sendo monitorados.
Sempre que um evento de entrada ocorre, isso indica que um token foi enviado ao bloco monitor. Quando um token é recebido pelo bloco monitor, isso pode representar o início ou o fim de uma verificação. Depois que o evento ocorre, a função de transição externa atualiza o clock interno do modelo (linhas 6-9). Em seguida, ela verifica se o evento indica o início ou o fim de uma verificação (linha 10). Caso o evento indique o início, então o valor atual do clock é inserido no final da fila de clocks, starttimes (linha 11). Caso contrário, uma subtração é feita entre o valor atual do clock e o primeiro valor da fila de clocks (linha 13). O resultado da subtração indica o tempo que o token levou entre a saída e a chegada nos arcos sendo monitorados. Caso esse valor seja maior que a constante DEADLINE, então isso significa que um deadline foi violado. Caso o deadline tenha sido violado, a função envia uma observação com valor 1 para o frameworkAkaroa (linha 14), caso contrário, uma observação com valor 0 é enviada (linha 16). Por fim, caso o evento recebido seja o fim de uma verificação, o primeiro valor da fila de clocks é removido (linha 17).
5.4
Avaliação dos modelos
A implementação das especificações e a composição dos blocos básicos são feitas utili- zando a biblioteca adevs (NUTARO,2012). Os modelos são avaliados por meio de simulação estacionária. Como mencionado na Subseção 5.3.4, o framework Akaroa (EWING; PAWLI- KOWSKI; MCNICKLE,1999) é usado para analisar as saídas da simulação. A Figura 5.11 exibe com maiores detalhes como o framework Akaroa, os modelos de simulação, e os algoritmos de exploração são integrados. Os métodos de análise estatística disponíveis em Akaroa são adotados para determinar quando a simulação deve parar (ver arco sinal de parada na Figura 5.11). A seguir, mostramos como probabilidades de violação de deadlines são calculadas.
Seja d(ck, cl) um deadline, e Y1, Y2, ... variáveis aleatórias, tal que:
Yj= 1, se deadline foi violado na j-ésima verificação 0, caso contrário. 5.3
Então, a probabilidade θ de se violar o deadline d(ck, cl) é dada pela média a seguir:
θ = E[Yj] 5.4
5.5. CONSIDERAÇÕES FINAIS 95
Devido à natureza da simulação estocástica, probabilidades de violação de deadlines não podem ser avaliadas de forma exata: elas só podem ser estimadas. Um estimador não enviesado para a probabilidade de violação de deadline θ é dado pela Equação 5.5 , onde n é o número de amostras (observações) coletadas da saída da simulação (BOLCH et al.,2006):
b Θ = lim n→∞ 1 n n
∑
j=1 Yj 5.5No entanto, na prática, a simulação precisa ser parada depois de um certo número de amostras, n, terem sido coletadas. Esta restrição e a natureza estocástica do modelo de simulação fazem com que o estimador bΘ seja por si só uma variável aleatória, e sua precisão vai depender, além de outros fatores, da sua variância. Portanto, é preciso levar em consideração essa incerteza. A análise estatística realizada pelo framework Akaroa estima esta variância (o método conhecido como Spectral Analysis (PAWLIKOWSKI,1990) foi adotado) e também determina quantas amostras devem ser coletadas para que a precisão desejada seja obtida. Akaroa determina a quantidade necessária de amostras por meio de uma abordagem sequencial em que a simulação só é parada quando precisão especificada para as estimativas é satisfeita, considerando um determinado nível de confiança. Uma dificuldade adicional é que a fase transiente da simulação pode deixar as estimativas enviesadas (PAWLIKOWSKI; JEONG; LEE,2002). Dessa forma, os métodos de Akaroa também foram usados para automaticamente detectar e remover as observações do período transiente da simulação.
5.5
Considerações finais
Esse capítulo apresentou como violações de deadlines são estimadas pelo método pro- posto. Durante a exploração do espaço de projeto, modelos de simulação são automaticamente criados por meio da composição de blocos básicos de simulação. Os blocos básicos, assim como sua composição, são definidas através do formalismo Parallel DEVS. Os modelos são avaliados por simulação estacionária e o framework Akaroa é adotado para eficientemente analisar as saídas da simulação. Os modelos são livres de detalhes funcionais da arquitetura, o que permite avaliar muitas opções de projeto em um curto espaço de tempo.
96 96 96
6
Algoritmos de exploração
Este capítulo apresenta os dois algoritmos multiobjetivo propostos para explorar o espaço de projeto de sistemas embarcados de tempo-real não críticos. Dada a especificação do problema (arquivo XML), gerada depois das atividades de especificação e caracterização do método proposto, os algoritmos de exploração automaticamente tentam otimizar a alocação, mapeamento e escalonamento do projeto. A otimização é feita considerando simultaneamente as seguintes medidas: probabilidades de violação de deadlines, potência consumida e custo monetário. Os algoritmos retornam como saída um subconjunto representativo do conjunto ótimo de Pareto (ou uma aproximação dele), considerando as medidas mencionadas.
Dentre as abordagens para atacar problemas de otimização multiobjetivo envolvendo simulação, os algoritmos genéticos (ou evolucionários) são uma das mais populares (JOINES et al., 2002; DING; BENYOUCEF; XIE, 2006; ESKANDARI; GEIGER, 2009; FU, 2002;
GUTJAHR,2011). Esse sucesso pode ser creditado principalmente a dois fatores (DEB,2008;
COELLO; LAMONT,2007): (i) a robustez que eles têm para escapar de regiões de mínimos locais e se adaptar às incertezas da simulação, e (ii) sua abordagem baseada em populações, o que permite que eles procurem múltiplas soluções do conjunto ótimo de Pareto em uma única execução.
O restante do capítulo está organizado da seguinte maneira: na Seção 6.1, o problema atacado pelos algoritmos propostos é formalmente definido. A Seção 6.2 apresenta o primeiro algoritmo proposto, denominado de MODSES, e a Seção 6.3 apresenta o segundo algoritmo proposto, chamado de C-MODSES. Por fim, a Seção 6.4 conclui esse capítulo.
6.1
Formulação do problema de otimização
A exploração do espaço de projeto pode ser estabelecida como um problema de otimiza- ção. Nesta seção, o problema de otimização tratado pelos algoritmos propostos é formalmente definido.
Considere o conjunto de elementos V e o conjunto de conexões entre esses elementos E do ATG Gatg= (V, E), além disso, considere o conjunto de tarefas T e o conjunto de canais de
comunicação Cd do HSDG Ghsdg= (A,C, s0), tal que T ⊆ A, Cd⊆ C. Então, cada vértice v ∈ V
do ATG representa um elemento potencialmente alocável. Seja uma alocação o vetor Γ = (qv),
qv∈ {0, 1} , v ∈ V , tal que
qv= 1, se o elemento representado por v está alocado,
0, caso contrário.
Além disso, seja um mapeamento a matriz Ψ = (hv,τ), hv,τ ∈ {0, 1}, v ∈ V , τ ∈ T ∪Cd,
6.1. FORMULAÇÃO DO PROBLEMA DE OTIMIZAÇÃO 97
hv,τ =
1, se a tarefa ou canal de comunicação representado por τ está mapeada no elemento representado por v.
0, caso contrário.
Seja uma atribuição de prioridades o vetor Ω = (ot), ot ∈ N, t ∈ T , tal que ot é a
prioridade da tarefa representada por t. Por último, seja uma atribuição de frequência o valor Λ ∈ R+, tal que Λ é a frequência de operação da arquitetura. Então, o problema de otimização tratado pelos algoritmos propostos pode ser formulado como
minimize F(x) = ( f1(x), f2(x), f3(x)) sujeito a x∈ S, 6.1
onde S representa o conjunto de soluções viáveis, e as funções fi: S → R+, i = 1, ... , 3
representam, respectivamente, os seguintes objetivos a serem otimizados: custo monetário, potência consumida, e probabilidades de violação de deadlines. A Seção 4.3 detalhou como custo monetário e potência consumida são calculados, e o Capítulo 5 apresentou como probabilidades de violação de deadlines são estimadas. Caso exista mais de um deadline a ser atendido no sistema, então f3(x) é definido como o somatório das probabilidades de violação de deadlines,
isto é, f3(x) = θ1(x) + ... + θk(x), onde k é o número de deadlines do sistema e θifoi definida na
Equação 5.4 .
Uma solução x = (Γ, Ψ, Ω, Λ) é viável se as seguintes restrições são satisfeitas:
Toda tarefa ou canal de comunicação representado por τ só pode ser mapeado no elemento representado por v, caso o último esteja alocado,
hv,τ ≤ qv, ∀v ∈ V, ∀τ ∈ T ∪Cd. 6.2
Toda tarefa ou canal de comunicação representado por τ deve estar mapeado em exatamente um elemento,
∑
v∈V hv,τ = 1, ∀τ ∈ T ∪Cd. 6.3Se duas tarefas representadas por tie tjestão mapeadas no mesmo elemento, então o canal de comunicação entre as duas tarefas (c = (ti,tj)) também deve ser mapeado
no mesmo elemento, hv,ti+ hv,tj ≤ 1 + hv,c, ∀c = (ti,tj) ∈ Cd, ∀v ∈ V 6.4
Se as tarefas representadas por tie tjestão mapeadas em elementos diferentes, então o canal de comunicação entre as duas tarefas (c = (ti,tj)) deve ser mapeado em um
6.2. ALGORITMO MODSES 98