Verificação de Modelos CPN (Model Checking)

A verificação de modelos é um método automático onde um conjunto de especificações sobre o comportamento do modelo (descritas em uma lógica temporal proposicional) é confrontado com o espaço de estados do mesmo, verificando se o modelo satisfaz essas especificações. O uso de verificação de modelos tem a vantagem de ser um procedimento totalmente automático e exaustivo no espaço de estados do modelo [89]. E, ao se especificar um comportamento desejado (uma propriedade), caso essa propriedade não seja verdadeira um contra-exemplo é apresentado pelo verificador de modelos, facilitando a análise. Porém, [9] alerta para o fato de que é necessário experiência para se escrever as especificações de comportamento em lógica temporal, e que demanda mais experiência ainda para entender as especificações escritas por outras pessoas.

A lógica temporal é um tipo de lógica especialmente desenvolvida para a definição de especificações comportamentais que envolvam a noção de ordem temporal [9]. Para essa tarefa diversos operadores temporais foram disponibilizados. As propriedades (ou especificações) que se desejam verificar são descritas em lógica temporal por meio de fórmulas construídas por proposições atômicas em lógica proposicional clássica em conjunto com os operadores temporais [89].

A lógica temporal pode ser classificada em Lógica Temporal Linear (LTL – Linear Temporal Logic) e Lógica Temporal Ramificada (CTL – Computational Tree Logic) [9][89]. Na Lógica Temporal Linear só há um futuro possível, enquanto na Lógica Temporal Ramificada vários futuros são admitidos. Uma definição sobre lógica temporal CTL e LTL pode ser obtida em [9][53].

No caso de modelos em CPN as especificações são formuladas em uma extensão da lógica temporal CTL denominada ASK/CTL [19], a qual é disponibilizada como uma biblioteca para uso no Design/CPN. Essa extensão ao CTL faz com que na verificação sejam levados em conta os estado e as transições do espaço de estados do modelo, e não apenas só os estados como ocorre no CTL [26][89].

3.7.1 – ASK/CTL

A biblioteca ASK/CTL pode ser usada, através do Design/CPN, para a verificação de modelos CPN. Essa biblioteca possui tanto a definição da linguagem da lógica do ASK/CTL como também um verificador de modelo [19]. O verificador toma uma fórmula (especificação de propriedade) em ASK/CTL como argumento e verifica se a mesma é válida no espaço de estados do modelo. Uma restrição a essa biblioteca é que não foi implementada a geração de um contra-exemplo caso a fórmula verificada não seja verdadeira.

As fórmulas podem ser escritas no domínio dos estados ou das transições, gerando então duas categorias de fórmulas: de estados ou de transições. Os operadores do ASK/CTL podem ser aplicados tanto a estados quanto a transições, e a semântica do operador vai depender então do domínio no qual estamos trabalhando [19]. A seguir são apresentados de forma sucinta os operadores do ASK/CTL [19] para fórmulas de nós:

1. TT: operador booleano que especifica que a condição é verdadeira 2. FF: operador booleano que especifica que a condição é falsa 3. NOT(A): operador booleano que nega a proposição A

4. AND(A1,A2): operador booleano que retorna verdadeiro se as proposições A1 e A2

são verdadeiras

5. OR(A1,A2): operador booleano que retorna verdadeiro se pelo menos uma das

proposições A1 ou A2 é verdadeira

6. NF(<expressão de nó>): operador que indica que a proposição deve ser verificada nos nós (estados) do espaço de estados

7. AF(<expressão de nó>): operador que indica que a proposição deve ser verificada nos arcos (transições) do espaço de estados

8. EXIST_UNTIL(A1,A2): operador usado para verificar se existe um caminho a

partir de nó atual no qual a proposição A1 é verdadeira em todos os estados do

9. FORALL_UNTIL(A1,A2): operador análogo a EXIST_UNTIL, sendo que ao invés

de procurar apenas um caminho, a condição deve ser verdadeira para todos os caminhos

10. POS(A): operador usado para verificar se existe um caminho a partir do estado atual que termine em um estado aonde a proposição A é verdadeira

11. INV(A): análogo a POS(A), só que para todos os caminhos possíveis

12. EV(A): operador usado para verificar se, para todos os caminhos, é sempre possível chegar a um estado no qual a proposição A é verdadeira

13. ALONG(A): operador usado para verificar se existe um caminho no qual a proposição A é sempre verdadeira, podendo este caminho ser infinito ou acabar em um estado terminal (dead marking)

14. MODAL(A): operador de mudança de domínio; e no caso de ser uma fórmula de estado a mesma será avaliada como verdadeira se existir uma transição imediata ao estado atual na qual o argumento A é verdadeiro a partir dessa transição

15. EXIST_MODAL(A1,A2): também é um operador de mudança de domínio, e no

caso de ser uma fórmula de estado, ela será avaliada como verdadeira se existir um estado sucessor ao atual no qual A2 seja verdadeira e que na transição entre o

estado atual e esse sucessor A1 seja verdadeira

16. FORALL_MODAL(A1,A2): similar ao EXIST_MODAL, mas neste caso A2 deve

ser verdadeiro para todos os sucessores imediatos do estado atual e A1 deve ser

verdadeiro para todas as transições entre o estado atual e seus sucessores

17. EXIST_NEXT(A): operador utilizado para verificar se existe um sucessor imediato do estado atual no qual A é verdadeiro

18. FORALL_NEXT(A): similar a EXIST_NEXT, sendo neste caso necessário que A seja verdadeiro para todos os sucessores imediatos

A verificação de uma fórmula é realizada pelo verificador utilizando o comando

eval_node. Um exemplo é apresentado a seguir.

fun PA n = (Mark.Switchgear'SG_Open 1 n = ((1,(TL01Y3,SG31Y34))!!empty)); fun PB n = (Mark.Switch_Breaker'CB_Open 1 n = ((1,(TL01Y3,SB21Y3))!!empty)); val check = POS(AND(NF("Error",PD),NF("Error",PB)));

eval_node checka InitNode;

Inicialmente temos as proposições PA e PB que são definições de marcações para os lugares SG_Open e CB_Open (o significado desses lugares não é relevante para o entendimento do exemplo de verificação). Em seguida temos check que é a fórmula que

será avaliada e que verifica se é possível, a partir do nó atual, alcançar um estado no qual tanto PA quanto PB são verdadeiros, ou seja, alcançar um estado em que as marcações dos lugares SG_Open e CB_Open sejam (TL01Y3,SG31Y34) e (TL01Y3,SB21Y3), respectivamente. O passo seguinte é a avaliação dessa fórmula a partir do estado inicial do modelo (InitNode). O retorno dessa verificação é mostrado a seguir, indicando que a fórmula foi avaliada como verdadeira, ou seja, que existe pelo menos um caminho a partir do estado inicial do modelo cujo estado final satisfaz tanto PA quanto PB.

val it = true : bool

Para a verificação de comportamentos no modelo se faz necessário definir quais comportamentos da interface são interessantes de teste, e isso depende das necessidades de análise, e escrever as proposições e fórmulas correspondentes. No capítulo que apresenta as análises aplicadas ao estudo de caso mostramos alguns exemplos de uso de model

checking aplicado a esse contexto.