Safety & Liveness. Vocabulario ● Una propiedad de un sistema es un conjunto de sucesiones infinitas de estados. ● Un sistema también se caracteriza como.

Presentación del tema: "Safety & Liveness. Vocabulario ● Una propiedad de un sistema es un conjunto de sucesiones infinitas de estados. ● Un sistema también se caracteriza como."— Transcripción de la presentación:

1 Safety & Liveness

2 Vocabulario ● Una propiedad de un sistema es un conjunto de sucesiones infinitas de estados. ● Un sistema también se caracteriza como un conjunto de sucesiones infinitas de estados. – Si un sistema alcanza su estado final, entonces ese estado se repite al infinito. ● Decimos que una propiedad vale para un sistema si el conjunto de sucesiones infinitas de estados del sistema está incluido en la propiedad.

3 Pasos intrascendentes ● Las sucesiones de estados de M1, ¿son únicamente de la forma 〈 A1,B1,C1,A1,B1,... 〉 ? ● ¿Qué pasa si y nunca aparece? ● Entonces, deberían admitirse sucesiones de la forma 〈 A1,B1,B1,B1,B1,B1,.... 〉. M1 B1 A1 C1

4 Pasos intrascendentes (2) ● ¿Qué pasa si a M1 se la compone con M2? ¿Cuáles son las sucesiones de estados del sistema completo, M? ● Por ejemplo tendrían la forma: 〈 (A1,A2),(A1,B2),(B1,B2),(C1,C2),(A1,C2),... 〉 ? M2 B2 A2 C2

5 Pasos intrascendentes (3) ● ¿Qué ocurre si proyectamos esa sucesión en M1 o M2? ● Por ejemplo, para M1 obtenemos: 〈 A1,A1,B1,C1,A1,... 〉 ● Pero esa sucesión no está dentro del conjunto de sucesiones que habíamos calculado para M1 porque A1 se repite en los dos primeros pasos. ● Entonces si descomponemos M no obtenemos los elementos originales con los cuales lo construimos. ● El problema se soluciona si admitimos pasos intrascendentes en las sucesiones que definen el sistema.

6 Ejemplo

7 Ejemplo (cont) ● Pensemos ahora en una propiedad para M1: siempre que M1 esté en B1 o C1 eventualmente volverá a A1. ● Sin embargo, M1 no verifica la propiedad porque, por ejemplo, la ejecución de M1 〈 A1,B1,C1,C1,C1,... 〉 No es una ejecución de la propiedad.

8 Pasos intrascendentes (3) ● En Statecharts, Z o Larch no es posible describir M1 de manera tal que cumpla con Propiedad. ● Es una imposibilidad del lenguaje. ● Para describir ese tipo de propiedades es necesario recurrir a lenguajes más expresivos. ● En general la semántica de esos lenguajes se basa en algún tipo de lógica modal o temporal.

9 Dos clases de propiedades ● En 1985 Alpern y Schneider publican un artículo en el cual demuestran que cualquier sistema o propiedad puede ser descripta como la intersección de dos propiedades muy particulares. ● Una de esas propiedades siempre indica lo que el sistema no debe hacer, la otra indica siempre lo que el sistema eventualmente debe hacer. ● A la primer clase pertenecen las propiedades de safety (seguridad) y a la segunda las de liveness (vitalidad).

10 Dos clases de propiedades (2) ● Los nombres no son caprichosos: – Seguridad hace referencia a que el sistema no hará daño, es decir hará sólo lo especificado, lo que le está permitido. ● Según esta clase de propiedades el sistema siempre tiene la opción de detenerse repitiendo un estado al infinito. – Vitalidad hace referencia a que el sistema eventualmente alcanzará ciertos estados de interés. ● Según Lamport la especificación de la vitalidad sólo ocupa el 10% del tiempo de descripción.

11 Seguridad ● Algo malo no se da durante la ejecución del sistema (veamos algunos ejemplos sobre el problema del cruce ferroviario). – Un tresn no puede entrar en la zona de interés si el anterior aun no salió (EC-U-DK) – El sensor Y no puede activarse sin que antes se haya activado el Z (EC-S-DK) – La alarma se enciende y apaga de forma alternada (MC-S-DK) – La barrera no sube mientras pasa el tren (MC-S- RQ)

12 Vitalidad ● Algo bueno ocurre durante una ejecución. – Un tren que llega eventualmente sale (EC-U-DK) – Llega un momento en que el sensor Y no emite señal (EC-S-DK) – Una vez que el tren pasó se levantará la barrera (MC-S-RQ) – MC-S-DK parecen no ser posibles en ningún sistema.

13 Formalización de safety ● Si P es una propiedad de seguridad pero el sistema M no la satisface, entonces quiere decir que hay una ejecución, s, de M que no está en P. ● Si s está fuera de P significa que algo malo sucedió durante s; peor aun, eso es irremediable: ya sucedió... aun volviendo hacia atrás la historia del sistema no evitaremos que haya pasado. ● P es de seguridad si y sólo si:

14 Formalización de safety (2) ● Si P es "La barrera no sube mientras pasa el tren", s ∉ P significa que hay un punto de s, s[..i], donde el tren estaba pasando y se subió la barrera. ● Entonces, la definición dice que hagamos lo que hagamos después de eso (t), será imposible olvidar que la barrera se subió mientras el tren cruzaba: s[..i]t ∉ P. ● Otra formalización es: P es de seguridad sii

15 ¿Cómo reconocer safety? M tiene ciertas transiciones y no otras Si M no está en A eventualmente volverá a A

16 ¿Cómo reconocer safety? (2) Acepta el mismo lenguaje ⇒ es de seguridad Acepta el mismo lenguaje ⇒ es de seguridad No acepta el mismo lenguaje ⇒ no es de seguridad No acepta el mismo lenguaje ⇒ no es de seguridad

17 ¿Cómo reconocer safety? (3) ● Algunas propiedades de seguridad corresponde a un autómata de Buchi que sólo tiene estados finales, pero que al menos tiene un estado que no acepta al menos un tipo de transición. ● De esta forma, los estados que no aceptan ciertos tipos de transiciones proscriben esas transiciones.

18 Formalización de liveness ● Ninguna ejecución parcial es irremediable: siempre existe la posibilidad de que lo bueno suceda en el futuro. ● Las propiedades de vitalidad no pueden prohibir cosas malas, sólo pueden prescribir cosas buenas. ● P es una propiedad de vitalidad si y sólo si

19 Formalización de liveness (2) ● Si P es "Todo convoy que llega eventualmente sale", entonces, si antes de salir se detiene, siempre existe la posibilidad de que vuelva a arrancar y cruce la ruta ● Supongamos que P es una propiedad de vitalidad que no satisface la definición dada. Entonces habrá una ejecución parcial s tal que entonces s es algo prohibido por P, por lo que P es en parte de seguridad.

20 ¿Cómo reconocer liveness? No acepta ⇒ no es de vitalidad No acepta ⇒ no es de vitalidad Acepta ⇒ es de vitalidad Acepta ⇒ es de vitalidad

21 ¿Cómo reconocer liveness? (2) ● Algunas propiedades de vitalidad corresponden a un autómata de Buchi que permite todas las transiciones posibles pero que tiene al menos un estado que no es final. ● De esta forma, si en algún momento se alcanza un estado no final, es seguro que se lo abandonará pues es posible salir con cualquier transición.

22 Safety ∩ Liveness ∩ ∩

23 Safety ∩ Liveness (2) ● En algunos casos puede ocurrir que al intersecar una propiedad de vitalidad con una de seguridad, el sistema resultante sea más restrictivo de lo que la propiedad de seguridad indica. ● Consideremos el siguiente sistema: – el estado es la variable natural x, – la única transición posible es incrementado x en 1, – el estado inicial x es 0, – se exige que si x llega a 1 eventualmente debe volver a cero.

24 ∩ ∩ Safety ∩ Liveness (3) La única transición es incrementar x en 1 Si x llega a 1 debe volver a 0

25 Máquina cerrada ● Un par de propiedades una de las cuales es de seguridad, se denomina máquina cerrada si la conjunción de ambas no restringe aun más el funcionamiento del sistema. ● Si P es de seguridad y L es una propiedad arbitraria, entonces el par (P,L) es máquina cerrada sí y sólo sí C(P ∩ L) = P. – C(A) es la clausura de A, definida como la menor propiedad de seguridad que contiene a A. – Abadi-Lamport

26 Máquina cerrada (2) ● P ∩ L ⊆ P ● Ahora, si existe otra propiedad de seguridad P' tal que P ∩ L ⊆ P' ⊂ P significa que L no contempla algunas de las ejecuciones incluidas en P. Es decir, L restringe el sistema más que P. ● P = {incrementar, permanecer igual}, L1 = {cada tanto incrementar}, L2 = {cada tanto incrementar, si pasa 5 decrementar} – P ∩ L1 = {cada tanto incrementar} – P ∩ L2 = {cada tanto incrementar pero no pasar 5}

27 Siempre ● Para obtener máquinas cerradas, escribiremos las propiedades de vitalidad de un sistema con fórmulas de equidad (fairness). ● Las fórmulas de equidad tienen una forma sintáctica muy simple pero que requiere introducir algunos conceptos de la lógica temporal. ● Sea P un predicado de estado: – □ P es un predicado de lógica temporal que depende de una ejecución, se lee "siempre", "de aquí en más"; – □ P es verdadero en s ∈ S ∞ sii P es verdadero en s[i] para todo i.

28 Siempre (2) ● Sea A un predicado que depende de dos estados (es decir, define una transición de estados): – □ A es un predicado de lógica temporal que depende de una ejecución; – □ A es verdadero en s ∈ S ∞ sii A es verdadero en (s[i],s[i+1]) para todo i. – Si A = (x' = x + 1), s[4]=[x2], s[5]=[x3], s[6]=[x 5], entonces A es verdadero en (s[4],s[5]) pero no lo es en (s[5],s[6]), y □ A es falso en s.

29 Eventualmente ● F = ¬ □ ¬F – Es decir F no es siempre es falsa lo que equivale a que es verdadera en algún momento. – Se lee "eventualmente (tal vez ahora)". ● □ F, indica que, para cualquier estado, F es verdadera allí o en un algún estado futuro. ● □ F, indica que existe algún estado tal que F es verdadera en todos los estados que le siguen.

30 Subir la barrera ● Consideremos el siguiente requerimiento: – Si la barrera está baja y no hay trenes pasando eventualmente debe levantarse la barrera. ● Establecemos que la barrera sólo puede subirse si está baja y no hay un convoy cruzando SBarrera ≙ b =Baja ∧ ¬convoy ∧ b'=Arriba ● Por lo tanto el requerimiento puede re- escribirse: – Siempre que se pueda subir la barrera hay que hacerlo.

31 ● El requerimiento anterior se puede escribir así: ● □ (se puede subir la barrera ⇒ SBarrera) ● Podemos definir el predicado Enabled(Op) como verdadero sii la precondición de Op es cierta en el estado actual. Entonces: ● □ (Enabled(SBarrera) ⇒ SBarrera) ● Sin embargo, este predicado es muy difícil de implementar pues si SBarrera se habilita por un segundo y luego queda deshabilitada por siempre, igual habría que ejecutarla. Equidad

32 ● Entonces, por un lado debilitando la fórmula anterior y por otro generalizándola, llegamos a: ● WF(Op) = □ ( □ Enabled(Op) ⇒ Op) ● Esto es lo que se conoce como equidad débil. ● En TLA es necesario modificar levemente estas fórmulas para que resulten invariantes a los pasos intrascendentes. ● La fórmula anterior es equivalente a: ● □ (¬Enabled(Op)) ∨ □ Op ● □ Enabled(Op) ⇒ □ Op Equidad débil

33 ● WF exige que la operación esté habilitada por siempre. Entre WF y la fórmula que descartamos está la equidad fuerte: ● SF(Op) = □ Enabled(Op) ⇒ □ Op ● Es decir, si Op está infinitamente a menudo habilitada, entonces se la ejecutará infinitas veces. ● La fórmula anterior es equivalente a: ● □ (¬Enabled(Op)) ∨ □ Op Equidad fuerte

34 ● WF dice que eventualmente debe ejecutarse Op si está continuamente habilitada. ● SF dice que si Op sólo a veces está inhabilitada, se la debe ejecutar infinitas veces. ● SF puede ser más difícil de implementar que WF, y es un requisito más infrecuente. ● Por ejemplo, en el caso de la vía sería exagerado pedir SF pues los trenes pasan cada tanto. Comparación

35 ❑ Abadi-Lamport: ❑ Teorema. Si P es de seguridad y L es una conjunción numerable de fórmulas WF(Op) y/o SF(Op) tal que cada Op puede ejecutarse satisfaciendo P, entonces (P,L) es máquina cerrada. ❑ Luego de introducir TLA veremos un enunciado más formal de este teorema. Máquina cerrada (3)