Analyzing Formal Requirements Specifications using an Off-The-Shelf ModelChecker

Gaston Scilingo∗, Marıa Marta Novaira∗, Renzo Degiovanni∗†, y Nazareno Aguirre∗†∗Departamento de Computacion, FCEFQyN, Universidad Nacional de Rıo Cuarto, Argentina

†Consejo Nacional de Investigaciones Cientıficas y Tecnicas (CONICET), Argentina{gaston, mnovaira, rdegiovanni, naguirre}@dc.exa.unrc.edu.ar

Abstract—We study the use of an off-the-shelf formal ver-ification tool, namely the explicit-state model checker SPIN,for various analyses related to SCR (Software Cost Reduction)formal requirements specifications. Unlike other studies, wheremodel checking is used for a specific purpose in the contextof SCR analysis (e.g., test generation or invariant verification),we use the model checker as the only analysis tool, for con-sistency checking, completeness analysis, property verification,etc. Moreover, to assess our characterization of the variousanalyses in terms of model checking, we develop a case study(a pacemaker specification), more complex than those typicallyfound in the SCR literature.

Keywords-Formal Methods, Requirements Specification,SCR Method, Model Checking.

I. INTRODUCCION

Es ampliamente aceptado que la depuracion es una delas etapas mas costosas en el desarrollo de software, yque los errores son mas faciles (y menos costosos) decorregir si se capturan lo mas temprano posible en elproceso de desarrollo [8], [12], [17]. Luego, el descubririnconsistencias, errores de comprension e imprecisiones du-rante la captura de requisitos es de fundamental importanciapractica y economica en la actividad de produccion desoftware. Debido a esto, la calidad de las especificacionesde requisitos tienen un enorme impacto en todo el procesode desarrollo, en particular debido a que gran parte de lasactividades de validacion (contrastacion del sistema solici-tado por el usuario con el que describe la especificacion)y verificacion (contrastacion del sistema especificado conel construido) dependen de estas especificaciones. Existeuna amplia variedad de notaciones para la descripcion derequisitos de software, pero aquellas con una semanticaformal son particularmente apropiadas para el analisis, yaque las ambiguedades propias de la notacion se eliminanabsolutamente. Sin embargo, una semantica formal no essuficiente: las complejidades y sutilezas de los requisitos, yel grado de detalle propio de las notaciones formales, de-mandan formas de modularizar especificaciones, de manerade colaborar con los desarrolladores en la comprension y lamanipulacion para el analisis. Esto es crucial para que unanotacion formal sea practicamente utilizable.

Una de estas notaciones es la subyacente al metodo

SCR (Software Cost Reduction). El mismo esta basadoen la notacion tabular de Parnas [6], y propone organi-zar especificaciones formales de requisitos en forma detablas usando una notacion rigurosa, con el objetivo deconseguir modularidad y adecuacion al analisis. Ademas, enla literatura se han aplicado exitosamente diversos tipos deanalisis formales a especificaciones SCR, muchos de ellosasistidos por herramientas de software, que incrementansignificativamente la capacidad de deteccion de errores enlos requisitos. Las herramientas de analisis para SCR se con-centran en el denominado SCR Toolset, que permite generarescenarios de ejecucion, producir tests, verificar propiedadestemporales, analizar la consistencia de la especificacion, etc.,tanto automaticamente como de manera asistida, usandouna variedad de tecnicas, como el model checking y lademostracion automatica. Sin embargo, las herramientas deanalisis detras de SCR Toolset no son de libre acceso dadoque pertenecen al Naval Reseach Laboratory de los EstadosUnidos, con lo cual la adopcion de SCR como metodoformal de especificacion se ve seriamente limitada, a pesardel exito que ha demostrado tener en la especificacion derequisitos de sistemas crıticos.

En este artıculo, estudiaremos como podemos aprovecharuna herramienta convencional off-the-shelf de verificacionformal, para analizar automaticamente diferentes aspectos deuna especificacion SCR. Nuestro objetivo es el de evaluarcuan efectiva puede ser una herramienta estandar y encierto sentido de proposito “mas general”, en el analisis deespecificaciones de requisitos, y cuales son las mayores di-ficultades con las cuales puede encontrarse un desarrolladoren esta tarea. La herramienta a utilizar es el model checkerde estados explıcitos SPIN. El trabajo consiste entoncesen mostrar como diferentes tareas de analisis de especi-ficaciones SCR pueden capturarse en terminos de modelchecking. A diferencia de otros trabajos que utilizan SPINpara analizar especificaciones SCR de formas especıficas(por ejemplo, para la generacion automatica de tests [7], o laverificacion de invariantes), en nuestro caso estudiamos lautilizacion de SPIN para todas las actividades de analisisvinculadas a SCR, incluyendo analisis de consistencia ycompletitud, alcanzabilidad de modos, generacion de tests,etc.

978-1-4799-1340-4/13/$31.00 ©2013 IEEE

2013 XXXIX Latin American Computing Conference (CLEI)

Con el objetivo de evaluar las capacidades del modelchecker y nuestra caracterizacion de las diversas actividadesde analisis, desarrollamos un caso de estudio basado en lacaptura formal de requisitos del sistema de control de unmarcapasos, que es mas complejo que los que se suelenanalizar en la literatura de SCR. Esto nos permitira, enparticular, evaluar la escalabilidad de los diversos analisis.La eleccion de este caso de estudio fue motivada porun desafıo a los metodos formales del Software QualityResearch Laboratory de la Universidad McMaster [15]. Estedesafıo propone el analisis de un marcapasos por dos razonesprincipales: es un sistema crıtico del cual dependen lasvidas de sus usuarios, y por la complejidad del software delmismo. Propondremos una especificacion en SCR de estecaso de estudio no trivial, y analizaremos todos los aspectosposibles de la especificacion usando el model checker SPIN,una herramienta libre de verificacion de software, ampli-amente utilizada para la verificacion formal de software,en particular de sistemas concurrentes o paralelos. Comoveremos, esto requerira capturar la semantica y condicionesde consistencia propias de la notacion subyacente a SCR enla notacion aceptada por SPIN para la verificacion. Buscare-mos por supuesto descubrir inconsistencias en la especifi-cacion, problemas de completitud o casos no contemplados,y demas tareas de validacion. Cabe aclarar que todas estastareas seran realizadas sobre una especificacion producidapor los autores del artıculo para la evaluacion (no un casode estudio de probada consistencia o correccion), con lo cualbuscamos descubrir errores propios de nuestra interpretaciondel problema, o de nuestra actividad de captura de requisitos.Es importante destacar ademas que nuestro trabajo involu-cra una traduccion automatica de especificaciones SCR aPromela (el lenguaje de especificaciones vinculado a SPIN),y una caracterizacion de los diferentes analisis en terminosde model checking. Estas son generales, en el sentido de queson aplicables a cualquier especificacion SCR, aunque seranpresentadas en terminos del caso de estudio desarrollado.

El artıculo esta organizado de la siguiente manera. Enla Seccion II se detalla el funcionamiento y la organi-zacion de un marcapasos. En la Seccion III se describebrevemente el metodo SCR. En IV se introducen las partesprincipales de la notacion usada en SCR, utilizando comoejemplo la especificacion SCR del sistema descripto enla seccion II. Mas adelante, en V, se describe los tiposde analisis aplicados sobre el modelo, la forma en quelos mismos fueron capturados para poder ser analizadosautomaticamente (i.e., el procedimiento aplicado para latraduccion de la especificacion para su analisis). En laSeccion VI vemos como los distintos analisis llevados a cabocontribuyeron a la deteccion de errores en los requerimentos.Por ultimo, discutimos sobre las lecciones aprendidas, lasmayores dificultades encontradas, nuestras conclusiones ypropuestas de trabajo futuro (Seccion VII).

II. UN SISTEMA DE MARCAPASOS

En esta seccion, y con el objetivo de hacer este artıculolo mas autocontenido posible, describimos brevemente enque consiste un sistema de marcapasos. Un sistema demarcapasos, al menos en lo que respecta a la captura yanalisis de requisitos realizados en este artıculo, tomandola descripcion de [15], consta de tres componentes: (i)un dispositivo electronico disenado para producir impulsoselectricos, llamado generador de pulsos (PG), cuya finalidades la estimulacion del corazon cuando falla la estimulacionfisiologica o normal; (ii) una estacion Controlador-Monitor(DCM), para programar y consultar al PG; y (iii) un set decables conductores que llevan los pulsos del PG al corazony las senales sensadas en el corazon al PG.

El DCM consiste de una plataforma de hardware y unaaplicacion de software que se comunican con el PG usandoun protocolo de comunicacion especıfico, por telemetrıa bi-direccional. Esto le permite al medico o al tecnico pro-gramar, consultar (por ejemplo, medir el nivel de baterıa,obtener histogramas de frecuencia, etc.) y enviar coman-dos al dispositivo de forma no invasiva despues de laimplantacion.

El PG monitorea y regula la frecuencia del corazondel paciente; detecta y provee terapia para condiciones debradicardia1; puede ser programado para proporcionar unafrecuencia adaptativa de ritmo, de simple y doble camara(aurıcula y ventrıcula), tanto permanente como temporaria.

Los valores nominales y la configuracion de valores deoperacion mınima del dispositivo quedan establecidos en sufabricacion. Ademas, el dispositivo cuenta con una memoriaflash para registrar datos historicos (de su operacion yeventos sensados), y para almacenar la configuracion devalores que establece y determina el medico para proveerterapia al paciente durante el perıodo ambulatorio.

El PG puede sensar y/o estimular la camara auricular,la ventricular o ambas con pulsos electricos (de voltajey ancho programable), segun el modo de operacion debradicardia que le sea programado. Un modo de operacionindica basicamente lo siguiente: que camara/s estimular, quecamara/s sensar, y como responder ante la deteccion de unpulso espontaneo o provocado en una camara. El modelode marcapasos utilizado en el presente trabajo permite 19modos de operacion de bradicardia en estado permanente,a saber: off, DDD, VDD, DDI, DOO, VOO, AOO, VVI,AAI, VVT, AAT, DDDR, VDDR, DDIR, DOOR, VOOR, AOOR,VVIR, AAIR. En todos estos modos, excepto off, laprimera letra indica que camara debe ser estimulada; la se-gunda que camara debe ser sensada; la tercera en que formase debe responder ante un pulso sensado; y la cuarta, en casode estar presente, indica si esta habilitada la modulacion defrecuencia. Por ejemplo, el modo de operacion VVI indica

1La bradicardia es una alteracion del ritmo al que late el corazon.Concretamente se trata de un descenso en la frecuencia cardıaca.

2013 XXXIX Latin American Computing Conference (CLEI)

que se debe pulsar y sensar la ventrıcula, e inhibir un pulsoprogramado si se sensa un pulso espontaneo previamente.

El PG puede encontrarse en cinco estados de fun-cionamiento distintos. El estado normal o permanente(Normal) es el estado en el cual el dispositivo proveeal paciente la terapia programada por el medico; estimula,sensa y responde segun el modo de operacion de bradicardiay el conjunto de valores seteados para el resto de lasvariables, como por ejemplo ancho y voltaje del pulso.El estado temporal (Temporal) es utilizado para setearvalores en el dispositivo, testear parametros o proveer prue-bas de diagnostico. Tambien existe el modo de operacionde bradicardia para este estado, y de este se debera salirinmediatamente por una rotura en el enlace de telemetrıa,por un comando CANCEL o PN (Pace-Now) provenientedel DCM. El estado Pace-Now (PaceNow) es un estado deestimulacion de emergencia, del cual no se sale hasta queno se reciba un cambio en el modo de estimulacion desde elDCM. El estado magnetico es un estado de funcionamientoprovocado por la presencia de un bunuelo magnetico2 enuna distancia menor a 2,5 cm del dispositivo; este estadoes utilizado para determinar la salud de la baterıa y entraren este estado provoca cambios en el modo de operacionde bradicardia. El modo de operacion anterior debe serrestituido al salir del estado magnetico. Es posible ademasprogramar el PG para ignorar la deteccion del bunuelo. Fi-nalmente, el dispositivo puede encontrarse en estado Poweron Reset (POR): se debera entrar en este estado cuando elnivel de voltaje de la baterıa se encuentre por debajo de uncierto umbral (BatteryLevel) que hace impredecible elcomportamiento del PG; en tal caso, todas las funcionali-dades se inhabilitan hasta que el nivel de voltaje exceda elumbral, manteniendo una actividad mınima para optimizarel uso de la baterıa y garantizar un mınimo de estimulacional paciente.

III. ESPECIFICACIONES TABULARES: EL METODO SCR.

El metodo SCR [6] utiliza una notacion formal paraespecificar requerimientos de software de manera concisamediante tablas. Este metodo ha sido utilizado en ccasosindustriales reales, principalmente para la captura de req-uisitos de sistemas crıticos. En el metodo SCR, las tablasson usadas para describir de manera organizada la relacionque el sistema debe inducir entre variables monitoreadas ycontroladas. Para describir de forma organizada y modularesta relacion, SCR hace uso de eventos, condiciones, clasede modo y terminos.

Una clase de modo (mode class en ingles) es una particionde los estados del sistema. Cada clase de equivalencia en laparticion es un modo del sistema. Un termino es una funcionsobre las variables de la especificacion. Una condicion es

2El bunuelo magnetico es un dispositivo imantado que se utiliza paramedir el nivel de voltaje en baterıas de marcapasos.

una expresion logica que hace referencia a las variables.Un evento ocurre cuando el valor de cualquier variable delsistema cambia (una variable del sistema es: una variablemonitoreada o controlada, una clase de modo o un termino).Un evento puede o no tener condiciones. La notacion @T(c)WHEN d denota un evento condicionado definido como:

@T(c) WHEN d ≡ ¬ c ∧ c’ ∧ d

donde las condiciones no primadas c y d son evaluadas enel estado previo y la condicion primada c’ esta evaluadaen el nuevo estado, al que se arriba como consecuencia delevento. Informalmente, esto denota el siguiente evento:

el predicado c se hace verdadero en el nuevoestado al mismo tiempo que el predicado d secumple en el estado previo.

La notacion @F(c) denota el evento @T(¬ c).Durante la operacion del sistema, el ambiente cambia una

variable monitoreada, causando un evento de entrada. Enrespuesta, el sistema actualiza los terminos y las clases demodo, y cambia las variables controladas, de la forma en quese indica en las tablas. En otras palabras, las tablas definenterminos, clases de modo y variables controladas.

El comportamiento del sistema se describe usando trestipos de tablas: de condicion, de eventos y de transicionde modos. Las tablas permiten describir una gran cantidadde requisitos de manera concisa, bien organizada y deforma modular. Cada tabla define una funcion (aunque lasespecificaciones SCR pueden ser no deterministas). La tablade condicion describe variables de salida (controladas) oterminos en funcion de modo y condicion. Una tabla deeventos describe ambos (variables de salida y terminos)como funcion de modos y eventos. La tabla de transicionde modos describe modos como funcion de otros modosy eventos. Es decir, una tabla de transicion de modos esuna tabla de eventos que define una clase de modo. Lastablas de condicion definen funciones totales, mientras quelas tablas de eventos y de transicion de modos puedendefinir funciones parciales, ya que algunos eventos puedenno ocurrir cuando cierta condicion es verdadera.

Utilizaremos el prefijo “m” para indicar los nombres delas variables monitoreadas, y el prefijo “c” para las variablescontroladas. El tipo de una variable monitoreada indica elrango de valores que pueden ser asignados a las variables.

IV. CAPTURA DE REQUISITOS DEL MARCAPASOSMEDIANTE SCR

En esta seccion introducimos parte de nuestra especi-ficacion SCR del sistema de control del marcapasos de-scrito previamente. Mostraremos solo una porcion de laespecificacion completa, que sera suficiente para ilustrar laforma en que haremos analisis, y los resultados obtenidos.Tambien introduciremos algunos aspectos relevantes delcomportamiento esperado del dispositivo, representado enlas construcciones mostradas.

2013 XXXIX Latin American Computing Conference (CLEI)

A. Deteccion de Clases de Modo

Como se menciono en la seccion II, el dispositivo PGpuede estar en cinco estados de funcionamiento distin-tos. Estos estados de funcionamiento pueden ser captura-dos naturalmente como modos de operacion, de la unicaclase de modo que tendremos en la especificacion, yque llamaremos mcPulseCondition. Cabe hacer notarque para satisfacer el requerimiento de que cada vez quese abandone el estado magnetico se vuelva al modo deoperacion previo al test, es necesario modelar el estadomagnetico como cuatro modos distintos (MAGnormal,MAGpacenow, MAGpor, MAGtemporal). La Tabla Imuestra un fragmento de la tabla de transicion de modos.Esta tabla indica, por ejemplo, que si se esta en modo Nor-mal y el nivel de voltaje de la baterıa mBATTERYvoltagese hace menor que BatteryLevel, entonces el sistemaentra en modo POR. Notese que, para que esta tabla seacorrecta (como mostraremos mas adelante), cada par de filasdistintas correspondiente a un mismo modo de salida debenser disjuntas, en el sentido que los eventos correspondientesno pueden tener solapamiento. De lo contrario, tendrıamosuna contradiccion, en algun sentido, pues los requisitospedirıan que se realicen dos cosas distintas en una mismasituacion. Esta sera una de las propiedades a verificar de laespecificacion.

B. Valores monitoreados y valores controlados

El PG debe controlar que camaras se estimulan, cualesse sensan y como se responde ante una deteccion de pulso,de acuerdo: al programa configurado por el medico, comorespuesta a comandos recibidos por telemetrıa desde elDCM, o bien por otros factores como una caıda en elnivel de baterıa o la presencia de un bunuelo magnetico.Estos hechos, que representan cambios ambientales parael sistema de control del PG, se modelan como variablesmonitoreadas. El hecho de que el medico pueda programarun modo de operacion de bradicardia para el estado Normallo hemos modelado a traves de una variable monitoreadamMODEbrad, cuyo rango de valores fue presentado enla seccion II. Los comandos recibidos vıa telemetrıa loshemos modelado con la variable mCommand. El nivel devoltaje medido en la baterıa del PG es representado pormBATTERYvoltage. Finalmente, la presencia de un imanpara test magnetico (a menos de 2,5 cm del dispositivo)esta indicada por el termino tMagnetON. Para hacer masconcisas las tablas y facilitar la escritura de propiedadeshemos definido varios terminos. Por ejemplo, en la TablaII se muestra la tabla de condicion de tModebradPV, queindica si el modo de operacion de bradicardia esta progra-mado en algun programa de pulsado de camara ventricular.

La variable controlada cCHAMBERSpaced modela cam-bios controlados por el sistema, la forma de pulsado de lascamaras. Si el PG esta en estado de operacion Normal laforma de pulsado sera acorde al programa configurado por

OLD MODE EVENT NEW MODENormal @T(mBATTERYvoltage < BatteryLevel) PORNormal @T( tMagnetON ) when mMagnet=ON MAGnormalNormal @T( mCommand=TMP ) TemporalTemporal @T(mBATTERYvoltage < BatteryLevel) PORTemporal @T( tMagnetON ) when mMagnet =ON MAGtemporalTemporal @F( tTELEMETRYsignal ) NormalPaceNow @T(mBATTERYvoltage < BatteryLevel) PORPaceNow @T( mCommand=NORMAL ) NormalPOR @T( tMagnetON ) when mMagnet=ON MAGporPOR @T( mCommand=PN ) when PaceNow

mBATTERYvoltage ≥ BatteryLevelPOR @T( mCommand=NORMAL ) when Normal

mBATTERYvoltage ≥ BatteryLevelPOR @T( mCommand=TMP ) when Temporal

mBATTERYvoltage ≥ BatteryLevel........ ...... ..........MAGpacenow @F( tMagnetON ) PaceNowMAGpor @F( tMagnetON ) POR

Tabla I: Fragmento de la tabla de transicion de modosmcPulseCondition.

el medico (por ejemplo, cCHAMBERSpaced tendra el valorA si el programa elegido es AAI). Pero ante un evento comola senal de estimulacion de emergencia (PN) o la caıda en elnivel de baterıa, el sistema debe cambiar la forma de pulsadoa pulsado de solo ventrıculo (V). En la Tabla III se muestraun fragmento de la tabla de eventos que define la variableantes mencionada.

mMODEbrad = VDD or NOT (mMODEbrad = VDD ormMODEbrad = VDDR or mMODEbrad = VDDR ormMODEbrad = VOOR or mMODEbrad = VOOR ormMODEbrad = VVIR or mMODEbrad = VVIR ormMODEbrad = VOO or mMODEbrad = VOO ormMODEbrad = VVI or mMODEbrad = VVI ormMODEbrad = VVT mMODEbrad = VVT)

tMODEbradPV true false

Tabla II: Tabla de condicion para el termino tMODEbradPV

V. VERIFICACION DE ESPECIFICACIONES DEREQUISITOS SCR

Debido a que SCR posee una semantica formal biendefinida, esta se puede aprovechar para realizar analisis depropiedades de las especificaciones, tales como ausencia decontradicciones, entre otras. De hecho, se han desarrolladovarias tecnicas de analisis automatico aplicadas a este tipode especificaciones. En particular, existe la herramienta SCRToolset [10] que da soporte a varias de estas tecnicas. Estaherramienta, o conjunto de herramientas para ser precisos,no esta publicamente disponible dado que pertenece allaboratorio Naval de los Estados Unidos. La motivacionde este trabajo es justamente estudiar la factibilidad deutilizar una herramienta de verificacion off-the-shelf, antela ausencia de contar con la familia de herramientas es-pecıficas, especialmente disenadas y ajustadas para este

2013 XXXIX Latin American Computing Conference (CLEI)

Normal @T(mCOMMAND = @T(tMagnetON) @T(mBATTERYvoltage < @T(tMagnetON)TMP) When BatteryLevel) When

(mMagnet = ON or @T(mCOMMAND = PN) (mMagnet = ONand or andtMODEbradPA) (@T(tMagnetON) tMODEbradPD)

when (mMagnet = ONand tMODEbradPV))

Temporal ... ... ... ...PaceNow @T(mCommand = @T(mCommand = @T(mCommand = @T(mCommand =

TMP) NORMAL) NORMAL) NORMAL)when tMODEbradPA when tMODEbradPV when tMODEbradPD

POR @T(mCommand = @T(mCommand = (@T(tMagnetON) @T(mCommand =TMP) when NORMAL) when mMagnet = ON) NORMAL)mBATTERYvoltage ≥ when or whenBatteryLevel (mBATTERYvoltage ≥ (@T(mCommand = PN) (mBATTERYvoltage≥

BatteryLevel) when BatteryLevel)and mBATTERYvoltage≥ andtMODEbradPA BatteryLevel) tMODEbradPD

or(@T(mCommand =NORMAL)when(mBATTERYvoltage≥BatteryLevel)and tMODEbradPV)

MAGnormal Never @F(TMagnetON) @F(TMagnetON) @F(TMagnetON)when tMODEbradPA when tMODEbradPV when tMODEbradPD

MAGtemporal @F(tMagnetON) Never Never NeverMAGpacenow Never Never @F(tMagnetON) NeverMAGpor Never Never @F(tMagnetON) NevercCHAMBERSpaced O A V D

Tabla III: Fragmento de la tabla de Eventos para cCHAMBERSpaced.

metodo. Como veremos mas adelante, usaremos el modelchecker de estados explıcitos SPIN, una herramienta muymadura y de amplia adopcion (ademas de ser de codigoabierto y de libre disponibilidad), para realizar los analisisnecesarios.

Los tipos de analisis considerados en este trabajo son:analisis estructurales, tales como completitud de las tablasde condicion, disyuncion de las filas de las tablas, elimi-nacion de posibles redundancias, alcanzabilidad de modos yverificacion de propiedades.

Existen ademas otros tipos de analisis, con los cualesno trabajaremos en este artıculo, tales como simulacion deejecuciones del sistema [10], generacion de casos de test[2], [7] (cuyo tratamiento usando SPIN ha sido tratadopreviamente), y la generacion automatica de invariantes [13],etc.

A. Disyuncion - Determinismo en la definicion de las tablas

En general, el metodo SCR es aplicado a sistemas re-activos. El ambiente en el que se ejecutan estos sistemases no determinista, pero el comportamiento capturado porcada transicion de dicho sistema debe ser determinista(basicamente, el no determinismo estara dado por la posi-bilidad de tener varias formas de avance en el sistemahabilitadas en un momento dado, pero cada una de ellastiene un efecto determinista en el estado del sistema).

Tal como se muestra en [9], para chequear que el compor-tamiento que define una tabla es funcional (o determinista),debemos corroborar que las condiciones que forman cada

fila sean disjuntas. A este tipo de chequeo se lo conoce conel nombre de disjointness y es uno de los principales analisisestructurales en este tipo de especificaciones.

Dos filas distintas f1 y f2 cualesquiera pertenecientes auna tabla son disjuntas, si ocurre que f1 ∧ f2 = false.Es decir, si la interseccion entre las dos filas es vacıa, oexpresado de manera similar, si ambas filas son disjuntas.Este tipo de chequeo requiere, usualmente, algun procesode decision para la logica utilizada en las tablas (e.g.,SMT solving, SAT solving), o una teorıa (no decidible)capturada en algun demostrador de teoremas. Para com-probar disjointness, se utiliza entonces SMT, SAT o algunotro mecanismo de constraint solving, o alternativamente sedemuestra deductivamente la disyuncion.

En nuestro caso, debemos tratar de analizar disjointnesscon un model checker. SPIN no cuenta con constraintsolvers subyacentes, con lo cual debemos capturar dis-jointness como alguna propiedad chequeable con el modelchecker. Notemos que si bien f1 ∧ f2 = false es loque efectivamente queremos verificar, lo que nos interesaes que no sea alcanzable una situacion que falsifique lacondicion anterior. Es decir, que partiendo del estado inicial,no podemos alcanzar un estado en el cual f1 ∧ f2 6= false.Esta propiedad es mas debil que disjointness, pero equiva-lente para nuestros propositos. Lo que estaremos verificandoes disjointness de f1 y f2 en los estados alcanzables dela especificacion (no su disjointness absoluta). Suponiendoque podemos caracterizar f1 y f2 con propiedades de pro-grama (lo veremos mas adelante), disjointness sera verificada

2013 XXXIX Latin American Computing Conference (CLEI)

chequeando la siguiente propiedad LTL:

�¬(f1 ∧ f2)

B. Completitud de Tablas de Condiciones

Una propiedad importante de las tablas de condicioneses que la disyuncion de todas las condiciones de una deestas tablas, para una misma fila, abarcan todo el espectro deposibilidades (tecnicamente, la disyuncion de las diferentesceldas de una misma fila equivalen a true). Nuevamente,para chequear este tipo de propiedades requerirıamos unconstraint solver. Al igual que para el caso anterior, locomprobaremos a traves de propiedades de alcanzabilidad:comprobaremos si el sistema admite la alcanzabilidad de unestado en el cual no se de ninguna de las condiciones delas celdas de una misma fila en una tabla (mostrando ası suincompletitud). Esto puede expresarse para toda fila k conla siguiente propiedad LTL:

♦¬(C1k ∨ C2k... ∨ Cnk)

C. Alcanzabilidad de modos

Otro chequeo de consistencia de una especificacion SCRes la alcanzabilidad de modos. De acuerdo a la semanticade SCR, todo modo en una especificacion debe ser noredundante (necesario). La comprobacion de esta propiedadtambien puede hacerse a traves de chequeos de alcanzabil-idad, uno por cada modo de la especificacion. Estaremoscomprobando entonces, mediante SPIN, que para toda clasede modo M y todo modo m ∈ M, existe al menos unaejecucion del sistema tal que, comenzando desde el estadoinicial, visite algun estado cuyo modo coincida con m. Porejemplo, para nuestro caso de estudio, deberemos verificarlo siguiente:

♦(mcPulseCondition = m)

para cada modo m de la especificacion.

D. Cobertura de tablas - Eliminacion de redundancia

Debido a la complejidad que pueden alcanzar las especi-ficaciones SCR, dependiendo del sistema en cuestion, puedeocurrir que existan filas en las tablas que sean inconsistentese inalcanzables. Es un analisis similar al de alcanzabilidadde modos, aunque mas complejo.

Entendemos por filas inconsistentes a aquellas para lascuales no puede existir un estado que las satisfaga. De otramanera, pueden existir filas consistentes pero inalcanzablesen el comportamiento del sistema. Es decir, no existe unaejecucion, comenzando desde el estado inicial, de maneratal que alguno de los estados visitados satisfaga la condicionde la fila. Es evidente que toda fila inconsistente es ademasinalcanzable.

La deteccion de filas inalcanzables pone en evidencia quela especificacion contiene redundancias. Por lo que se debe

de localizar el problema y eliminar esa redundancia en ladefinicion de la tabla.

Es posible utilizar tecnicas de generacion de casos detests, para lograr verificar si nuestra especificacion poseeo no filas inalcanzables. Tal como se muestra en [7], sila especificacion cumple con el criterio de cobertura TableCoverage, entonces para cada fila existe un caso de test (unaejecucion) que ejercita esa fila, es decir, obtiene un estadoque satisface las condiciones de la fila. Podemos ver estoverificando que para toda fila k de una tabla es valida laformula:

♦fk

E. Verificacion de propiedades Temporales

Se han presentado en la literatura diversas formas deverificar propiedades sobre especificaciones SCR [10]. En-tre estas podemos mencionar el model checker de estadoexplıcito SPIN [3], ALV (un model checker simbolico)[5], SALSA (un constraint solver basado en BDDs) [4],TAME (una interfaz para el demostrador de teoremas PVS[1] adaptada a especificaciones tabulares). Muchas de lasherramientas mencionadas pertenecen al SCR Toolset, porlo que no pueden ser usadas para propositos publicos.

En este artıculo nos centramos en la verificacion de untipo particular de propiedades temporales, las conocidascomo invariantes (propiedades de safety). En particular,un invariante puede ser de estado, si vale en todo estadoalcanzable s ∈ S , o de transicion si vale en todo parde estados alcanzables (s, s′), donde S es el conjuntode estados del sistema, s, s′ ∈ S y existe un evento ehabilitado en s y cuya ejecucion a partir de s obtiene s′. Laeleccion de analizar invariantes del sistema se debe al tipode propiedades identificadas desde la descripcion informal.

F. SPIN como herramienta de analisis

SPIN [11] es la herramienta elegida para realizar analisis,como hemos mencionado anteriormente, debido a variascaracterısticas, en particular su aplicacion previa a ciertosanalisis de especificaciones SCR [7], [3], [10] (aunque no to-dos los tratados en este artıculo). SPIN es un model checkerde estado explıcitos que utiliza exploracion de estados paraverificar propiedades. La descripcion del sistema debe serrealizado en el lenguaje Promela [11] y las propiedadespueden codificarse con la sentencia assert o formulas enlogica temporal lineal [14].

Considere la siguiente porcion de la tabla de modosespecificada en la Tabla I:

OLD MODE EVENT NEW MODENormal @T(mBATTERYvoltage < BatteryLevel) PORNormal @T( tMagnetON ) when mMagnet=ON MAGnormalTemporal @T(mBATTERYvoltage < BatteryLevel) POR... ... ...

2013 XXXIX Latin American Computing Conference (CLEI)

Bharadwaj y Heitmeyer introdujeron en [3] una traduccionde especificaciones tabulares SCR al lenguaje Promela.A continuacion mostramos cual serıa la codificacion enPromela de la porcion de la tabla de modos mostradaanteriormente.

/* definicion de tabla de modo mcPulseCondition */if:: mcPulseCondition == Normal ->if:: (mBATERYvoltageP < BatteryLevel) &&

(!(mBATERYvoltage < BatteryLevel))-> mcPulseConditionP = POR;

:: (tMagnetONP && ! tMagnetON) && (mMagnet == On)-> mcPulseConditionP = MAGnormal;

::else skip;fi;

:: mcPulseCondition == Temporal ->if:: (mBATERYvoltageP < BatteryLevel) &&

(!(mBATERYvoltage < BatteryLevel))-> mcPulseConditionP = POR;

:: ...fi;...

fi;

Figura 1: Porcion de la traduccion a Promela para Tab. I

Se puede observar que por cada variable SCR, ten-emos dos variables en Promela para modelar el estadoprevio y el siguiente. Por ejemplo, mcPulseConditiony mcPulseConditionP modelan el modo previo y elmodo siguiente, respectivamente. De esta manera podemosexpresar facilmente invariantes de transicion utilizando lasentencia assert. Consideremos por ejemplo la siguienteasercion:

assert (!( !(mBATERYvoltage < BatteryLevel)&& (mBATERYvoltageP < BatteryLevel))|| (mcPulseConditionP == POR));

Figura 2: Invariante de transicion

El invariante especificado por esta asercion indica que siel voltaje de la baterıa se hace menor al nivel permitido, elnuevo modo deberıa ser POR.

VI. RESULTADOS EXPERIMENTALES

En esta seccion mostraremos los resultados experimen-tales de aplicar los analisis descriptos en la seccion anterior,a la especificacion SCR del sistema de control de unmarcapasos, presentado anteriormente en este artıculo. De laespecificacion original expresada en tablas SCR (en un doc-umento de textos) pasamos manualmente a una descripcionen el lenguaje SAL (SCR Abstract Language), para luegoser traducida a Promela (ver subseccion V-F), y ası poderutilizar SPIN como herramienta de analisis.

El analisis de alcanzabilidad de modos resulto exitoso.SPIN logro encontrar una ejecucion que cubra cada modoen pocos segundos. Los chequeos de disyuncion y decobertura fueron aplicados a las tablas de eventos que

definen a las variables controladas cCHAMBERSpaced,cCHAMBERSsensed y cRESPONSEsensing, y a la tablade modos que define la variable mcPulseCondition.Los experimentos develaron un error de disyuncion de filasen la tabla de cRESPONSEsensing. Este error tenıaque ver con una falla a la hora de transcribir la especifi-cacion en SAL. Mas precisamente, faltaba incluir el termino(tMODEbradSA) en la definicion de la tabla, el cual debeser mencionado para asegurar que el sistema de transicionesdefinido sea determinista.

Ademas de las tareas arriba descritas, es sumamenteimportante poder analizar si la especificacion de requisitosgarantiza ciertas propiedades (lo que podemos entendercomo verificacion de propiedades de la descripcion de requi-sitos). La importancia de tal verificacion es particularmenterelevante en el contexto de sistemas crıticos, como es el casodel sistema de control del marcapasos.

Desde la descripcion informal fueron identificadas lassiguientes propiedades que deberıan ser invariantes a lolargo de la ejecucion del sistema.

1) @T(mBATTERYvoltage < BatteryLevel)⇒ mcPulseCondition’ = POR

2) @T(tMagnetON) ∧ (mMagnet = On) ⇒( cCHAMBERSpaced’ = cCHAMBERSpaced )

3) mcPulseCondition’ = Temporal ⇒ (cCHAMBERSpaced’ = O ∧cRESPONSEsensing’ = O )

4) cCHAMBERSpaced’ = O ⇒mcPulseCondition’ = Temporal

5) mcPulseCondition’ = POR ⇒( cCHAMBERSpaced’=V ∧cCHAMBERSsensed’=V ∧cRESPONSEsensing’=I ).

La propiedad 1 describe una de las situaciones crıticasdel sistema: si el voltage de la baterıa cae por debajo delnivel normal, el marcapasos debe funcionar en modo POR,el cual posee una configuracion por defecto para que elconsumo de baterıa sea mınimo. La propiedad 2 indica queal pasar a modo magnetico, la configuracion de la camara depulsado no debe cambiar. Las propiedades 3, 4 y 5, por otraparte, reflejan los valores que deben mantener las variablescontroladas en los modos respectivos.

Como se menciono anteriormente, la propiedad 1 esuna de las situaciones crıticas del sistema. SPIN fue ca-paz, en pocos segundos, de encontrar varias violacionesa esta propiedad. Estos contraejemplos mostaron que latabla de modos que aparece en la Tabla I era incom-pleta; la condicion crıtica @T(mBATTERYvoltage <BatteryLevel) no fue considerada en diversas situa-ciones. Por ejemplo, se debieron agregar las siguientesnuevas filas en la definicion de mcPulseCondition:

2013 XXXIX Latin American Computing Conference (CLEI)

OLD MODE EVENT NEW MODEMAGpacenow @T(mBATTERYvoltage < POR

BatteryLevel)MAGtemporal @T(mBATTERYvoltage < POR

BatteryLevel)

Por otra parte, la omision de la condicion crıtica men-cionada anteriormente tambien afecto las definiciones de lasvariables controladas, ya que el modo de bradicardia en PORdebe ser VVI. Las tablas no contemplaban dicha situacion,por lo que debimos extender la definicion, por ejemplo, dela variable cCHAMBERSspaced (Tabla III) agregando filassimilares a las siguientes:

PaceNow ... ... @T(mBATTERYvoltage < ...BatteryLevel)

MAGpacenow ... ... @T(mBATTERYvoltage < ...BatteryLevel)

cCHAMBERSpaced O A V D

Luego de solucionar los errores mencionados, laspropiedades 1, 2 y 3 pudieron ser verificadas en menos de10 segundos usando SPIN.

Las propiedades 4 y 5 estan relacionadas; ambas tratande establecer la relacion que debe cumplirse entre la clasede modos y las variables controladas. El analisis de dichaspropiedades manifestaron que existıan diversos errores ennuestra especificacion. A partir de la informacion provistapor los contraejemplos encontrados, se decidio primeroverificar la validez de una propiedad adicional:

6) mcPulseCondition’ = Normal ⇒( tMODEbradPA ∨ tMODEbradPV ∨tMODEbradPD ).

Esta propiedad indica que si el marcapasos funciona enmodo Normal, entonces el medico deberıa haber seteadopreviamente la configuracion del modo de bradicardia queindica como debe de realizarse el pulsado. El resultadofue sorpresivo, ya que la condicion resulto ser invalida.Luego de una revision exhaustiva del modelo se advirtio quela variable de modo de bradicardia (mMODEbrad) admitetambien el valor off, indicando que no tiene programa.En este punto se retomo la lectura de la especificacioninformal del marcapasos y se encontro que la descripcionen este caso era incompleta. Luego de una busqueda deinformacion adicional, se encontro la solucion al problemaplanteado, que consistio en agregar nuevas condiciones (porejemplo, mMODEbrad!=off) a la tabla de modos queaseguren que el marcapasos puede pasar a modo Normalsolo si previamente el medico ha seteado la configuracionrequerida. Ası tambien, se decidio que el valor inicialcorrecto de mMODEbrad debe ser el valor off, para queluego el medico sea quien lo configure adecuadamente. Amodo de ejemplo, a continuacion se presenta una de lasmodificaciones realizadas a la tabla de modo de la Tabla Ipara solucionar el problema mencionado anteriormente:

OLD MODE EVENT NEW MODETemporal @F(tTELEMETRYsignal) Normal

when (mMODEbrad!=off)

Finalmente, se descubrio que la definicion de la tablade condicion del termino tMODEbradPD era incompletadebido a que uno de los diecinueve valores posibles fue omi-tido durante la transcripcion de la especificacion informal aSCR.

VII. CONCLUSION Y TRABAJOS FUTUROS

En este artıculo hemos estudiado la posibilidad de utilizaruna herramienta de verificacion estandar, un model checkeroff-the-shelf, para el analisis de especificaciones de requi-sitos realizadas utilizando el metodo SCR. Para evaluar lascapacidades de una herramienta de estas caracterısticas paraanalizar especificaciones de requisitos, y ver en que medidala herramienta puede contribuir a mejorar la calidad de laespecificacion, se desarrollo un caso de estudio de capturade requisitos usando el metodo SCR. El mismo consistioen la captura de requisitos de parte de un sistema crıtico,mas precisamente, un sistema de marcapasos. Este caso deestudio, un desafıo del grupo Software Quality ResearchLaboratory de la Universidad McMaster [15], constituyeun caso no trivial, sobre el cual aplicar la notacion SCRresulta relevante. La relevancia de este estudio tiene que vercon que si bien SCR cuenta con un set de herramientaspotente, las mismas no son de acceso publico, lo que limitala utilizacion del metodo (que ha demostrado ser sumamenteutil para sistemas crıticos). Es generalmente aceptado quecontar con herramientas de analisis automatico es hoy endıa indispensable para conseguir que una tecnica formalsea adoptada en la practica. Hemos evaluado si usar unaherramienta off-the-shelf (en contraste con las herramientasdel SCR Toolset, disenadas y adaptadas especıficamente paraaprovechar las caracterısticas de la notacion) contribuye alproceso de captura de requisitos. Hemos analizado con estaherramienta la especificacion en busca de inconsistencias,porciones incompletas de la especificacion, y otros proble-mas de validacion de la misma.

La evaluacion de la especificacion formal en SCR, yel analisis automatico de la misma, resulto en nuestraopinion satisfactorio. Gracias al analisis realizado se en-contraron y repararon errores importantes: incompletitud dealgunas tablas, falta de informacion en la especificacioninformal de requerimientos, errores en la traduccion delos requerimientos formales a SCR y en el estado inicial.Para las propiedades identificadas como importantes parala especificacion, y a pesar de que la traduccion a SPINes relativamente simple (comparandola probablemente conla forma en que SCR Toolset, una herramienta con variasdecadas de madurez, hace uso de model checking), noencontramos en el analisis problemas de escalabilidad. Cabedestacar que nuestro analisis no contempla la totalidad delmarcapasos en la especificacion, sino una porcion no trivialdel mismo. Una de las tareas que resulto mas difıcil fuela interpretacion de los contraejemplos obtenidos del modelchecker. Estos contraejemplos estan expresados en terminos

2013 XXXIX Latin American Computing Conference (CLEI)

de la forma en que se codifica la especificacion original enPromela, y su “bajo nivel de abstraccion” complica la tareade depuracion de la especificacion.

Como parte de nuestro trabajo futuro, planeamos extenderel trabajo aquı expuesto a la totalidad del marcapasos,extendiendo la especificacion a un modelo completo delaparato, y aplicando analisis automatico a la especificacionresultante. Buscamos en particular chocarnos con problemasde escalabilidad, que demanden un uso mas sofisticado demodel checking (e.g., a traves de abstraccion). Es indudableque eventualmente deberemos lidiar con problemas de es-calabilidad; en estos casos, trabajaremos en identificar lasfuentes y adaptar las tecnicas de analisis vıa model checking,aprovechando caracterısticas particulares de la notacion y laforma en la que se emplea. Tambien planeamos trabajar enformas de visualizar la salida obtenida del model checker demanera que la misma sea de mas facil intepretacion por partedel desarrollador. Diferentes mecanismos de visualizaciongrafica, al nivel de abstraccion de la especificacion original,seran utiles para esta tarea.

Agradecimientos

Los autores quisieran agradecer a los revisores anonimos delartıculo, por sus comentarios y sugerencias, que ayudaron amejorar el mismo. Este trabajo ha sido financiado parcial-mente por la Agencia Nacional de Promocion Cientıfica yTecnologica de Argentina, a traves de los proyectos PICTPAE 2007 No. 2772 y PICT 2010 No. 1690, y por elproyecto MEALS (EU FP7 programme, grant agreement No.295261).

REFERENCIAS

[1] M. Archer, TAME: Using PVS strategies for special-purposetheorem proving, Annals of Mathematics and Artificial Intel-ligence, 29(1-4):131189, February 2001.

[2] D. Beyer, A. Chlipala, T. Henzinger, R. Jhala and R. Ma-jumdar, Generating Tests from Counterexamples, in Proc. ofICSE 2004, IEEE, 2004.

[3] R. Bharadwaj, C. Heitmeyer, Model Checking Complete Re-quirements Specifications Using Abstraction, in Proc. Auto-mated Software Engineering, 1999.

[4] R. Bharadwaj and S. Sims, Salsa: Combining constraintsolvers with BDDs for automatic invariant checking, in proc.Tools and Algorithms for the Construction and Analysis ofSystems (TACAS 2000), Berlin, March 2000.

[5] T. Bultan and C. Heitmeyer, Applying Infinite State ModelChecking and Other Analysis Techniques to Tabular Re-quirements Specifications of Safety-Critical Systems, DesignAutomation for Embedded Systems, 12(1-2), 2008

[6] M. Engel, M. Kubica, J. Madey, D. Parnas, A. Ravn, A.van Schowen, A Formal Approach to Computer SystemsRequirements Documentation, Hybrid Systems, LNCS 736,Springer, 1993.

[7] A. Gargantini and C. Heitmeyer, Using Model Checking toGenerate Tests from Requirements Specifications, in Proc. ofESEC/FSE 1999, LNCS, Springer, 1999.

[8] C. Ghezzi, M. Jazayeri y D. Mandrioli, Fundamentals ofSoftware Engineering, 2nd. Edition, Prentice-Hall, 2002.

[9] C. Heitmeyer, B. Labaw, D. Kiskis, Consistency Checkingof SCR-Style Requirements Specifications, en Proceedings deIEEE International Symposium on Requirements Engineer-ing, York, Inglaterra. IEEE Computer Society 1995.

[10] C. Heitmeyer, M. Archer, R. Bharadwaj, R. Jeffords, Tools forconstructing requirements specifications: the SCR Toolset atthe age of ten, Computer Systems Science and Engineering,20(1), CRL Publishing, 2005.

[11] G. J. Holzmann, Design and Validation of Computer Proto-cols, Prentice-Hall, 1991.

[12] P. Jalote, An Integrated Approach to Software Engineering,3rd. Edition, Springer, 2005.

[13] R.Jeffords and C. Heitmeyer. Automatic generation of stateinvariants from requirements specifications, in Proc. of 6thACM SIGSOFT Symp. Foundations Softw. Eng., 1998.

[14] Z. Manna and A. Pnueli, The temporal logic of reactive andconcurrent systems specification, Springer, 978-3-540-97664-6, pp. I-XIV, 1-427, 1992.

[15] Pacemaker Formal Methods Challenge, PACEMAKER SystemSpecification, Software Quality Research Laboratory, McMas-ter Univerity.

[16] D.L Parnas et al. Software Requirements for the A-7E Aircraft,Naval Laboratory Report Documentation, 1992.

[17] I. Sommerville, Software Engineering, 8th Edition, Addison-Wesley, 2006.

2013 XXXIX Latin American Computing Conference (CLEI)