consideraciones de seguridad y confiabilidad para la...

CONSIDERACIONES DE SEGURIDAD YCONFIABILIDAD PARA LA

IMPLEMENTACIÓN DE REDES DE SENSORESINALÁMBRICOS EN EL CONTEXTO DE LA

ATENCIÓN Y HOSPITALIZACIÓNDOMICILIARIA

Autor:

Manuel Eduardo Ríos

Olaya

Tutor:

Fredy Alexander Rivera

Velez

Grupo de Investigación de Sistemas Embebidos e Inteligencia Computacional -

SISTEMIC

Facultad de Ingeniería

http://sistemic.udea.edu.co/

http://sistemic.udea.edu.co/

Resumen

Las redes de área corporal (Wireless Body Area Networks, (WBAN)) se han consolida-

do en los últimos años como una alternativa tecnológica para aplicaciones médicas que

requieren la mmonitorización continua de signos vitales en pacientes con enfermedades

denominadas crónicas, es decir, de lento progreso y larga duración. Sin embargo, persisten

retos asociados a esta tecnología teniendo en cuenta las exigencias de los escenarios mé-

dicos. Entre estos retos se destacan los relacionados con las propiedades de con�abilidad

y seguridad, ya que una falla en el sistema puede ocasionar falsas alarmas, alteraciones

del diagnostico médico y en el peor de los casos la muerte del paciente. En la literatura

relacionada con las WBANs se destaca la ausencia de metodologías para la evaluación y

predicción del comportamiento de estas propiedades en la etapa de diseño de este tipo

de aplicaciones. En este trabajo de investigación se realiza el estudio de las propiedades

de con�abilidad y seguridad para un sistema de monitorización remota de pacientes en

condición de hospitalización domiciliaria basado en la tecnología WBAN. El estudio de

estas propiedades ha sido abordado desde la identi�cación de requerimientos asociados

a la con�abilidad y seguridad del sistema, utilizando estrategias utilizadas en el diseño

y desarrollo de productos de innovación y usando técnicas de análisis de riesgo amplia-

mente recomendadas en la literatura. A partir de los requerimientos y puntos críticos

relacionados con las propiedades de intéres se propuso una arquitectura compuesta por

mecanismos de hardware y software encauzados a la tolerancia y prevención de fallos en

el sistema. La validación de la efectividad de los mecanismos propuestos se realizó a tra-

vés del formalismo de redes de actividad estocástica (Stochastic Activity Network, SAN),

donde se construyeron submodelos atómicos de un modelo referencia carente de mecanis-

mos de con�abilidad y seguridad y un modelo que incluye la arquitectura propuesta, que

permita comparar el comportamiento de los atributos relacionados con la con�abilidad

y seguridad en ambos modelos. La evaluación se realizó considerando escenarios típicos

de funcionamiento del sistema, permitiendo validar la arquitectura propuesta y su efec-

tividad al mitigar las los riesgos y amenazas a la con�abilidad y seguridad del sistema

de monitorización remota de pacientes en condición de hospitalización domiciliaria.

Agradecimientos

Agradezco a:

Dios por darme la salud y fortaleza para emprender una importante meta personal y

profesional. Por darme la oportunidad de aprender de cada una de las actividades ne-

cesarias para llevar a cabo este trabajo de investigación, y por permitirme disfrutar del

conocimiento adquirido durante esta etapa.

Mis padres Gustavo y Lili, por su apoyo incondicional, por ser mi principal motivación

para lograr cada una de mis metas y por enseñarme que la perseverancia, la disciplina

y la responsabilidad son valores fundamentales para obtener el conocimiento, que me

permita día a día realizar mi trabajo con pasión y profesionalismo.

Mi hermanita Catalina por cuidar a mis viejos y no perder la costumbre de brindarme

sus inusuales pero signi�cativos gestos de amor, que me motivan a ser alguien de quien

se pueda sentir orgullosa.

Mi hermosa Marcela, por ayudarme y motivarme con sus gestos de amor y comprensión

en los momentos cruciales para lograr este objetivo y por sacri�car parte de su tiempo

para acompañarme de una u otra forma en la obtención de este logro.

Fredy Rivera PhD, por su trabajo responsable y respetuoso para guiar mi investigación

con sus acertados consejos y por la paciencia y tiempo dedicado a mejorar cada una de

las fases de este proyecto de investigación.

Natalia Gaviria y Jose Edison Aedo, por abrirme las puertas de la Universidad de

Antioquia y de los grupos de investigación GITA y SISTEMIC.

ii

Índice general

Resumen i

Agradecimientos ii

1. Introducción 1

1.1. Contextualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Conceptos y trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1. Con�abilidad y seguridad en sistemas de computación y comunicación 51.3.2. Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.2. Objetivos especí�cos . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5. Estructura del trabajo de investigación . . . . . . . . . . . . . . . . . . . . 10

2. Identi�cación de requerimientos de con�abilidad y seguridad 11

2.1. Estrategia de co-creación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.1. Diseño conceptual del sistema . . . . . . . . . . . . . . . . . . . . . 14

2.2. Estándares de seguridad para equipos electro-médicos . . . . . . . . . . . 152.2.1. Estándar IEC 60601-1 . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2. Estándar IEC 60601-1-2 . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3. Árboles de fallas (FTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4. Análisis de modos de fallas y efectos (FMEA) . . . . . . . . . . . . . . . . 26

3. Arquitectura de con�abilidad y seguridad 30

3.1. Implementación hardware/software del sistema HealTICa . . . . . . . . . 303.2. Medidas de prevención de fallas a nivel de software . . . . . . . . . . . . . 33

3.2.1. Patrón CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.2. Patrón SmartData . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3. Medidas de tolerancia y prevención de fallas a nivel de hardware . . . . . 383.3.1. Patrón Sanity Check - Redundancia liviana . . . . . . . . . . . . . 383.3.2. Firmware del canal redundante . . . . . . . . . . . . . . . . . . . . 40

3.4. Implementación de mecanismos de seguridad en la comunicación inalámbrica 43

4. Evaluación de con�abilidad y seguridad 50

4.1. Modelos atómicos SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iii

iv

4.1.1. Dinámica de las redes de actividad estocástica SAN . . . . . . . . 514.2. Modelo SAN de referencia para evaluar la con�abilidad del nodo HealTICa 544.3. Modelo SAN del nodo HealTICa con arquitectura de con�abilidad . . . . 624.4. Escenarios experimentales y resultados . . . . . . . . . . . . . . . . . . . . 694.5. Modelos atómicos SAN para la evaluación de la seguridad . . . . . . . . . 79

5. Conclusiones y Trabajos Futuros 83

5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2. Publicación derivada de este trabajo . . . . . . . . . . . . . . . . . . . . . 855.3. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Bibliografía 86

Índice de �guras

1.1. Componentes de la plataforma para la vigilancia de eventos de riesgo enpacientes crónicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Escenario general de sistema de monitorización remoto de pacientes basa-do en redes inalámbricas de área corporal WBAN . . . . . . . . . . . . . . 4

1.3. Taxonomía de las propiedades de con�abilidad y seguridad de un sistema. 61.4. Secuencia de amenazas a la seguridad y la con�abilidad. . . . . . . . . . . 7

2.1. Diseño conceptual del sistema HealTICa . . . . . . . . . . . . . . . . . . . 152.2. Simbología establecida en el estándar IEC 60601-1 correspondiente a los

diferentes tipos de dispositivos electro-médicos. (a) tipo B, (b) tipo BF y(c) tipo CF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3. Árbol de fallas para el evento principal de lesiones en la piel . . . . . . . . 232.4. Árbol de fallas para el evento principal de vulnerabilidad de seguridad del

sistema HealTICa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5. Árbol de fallas para la detección de un evento de alto riesgo asociado a

los signos vitales del paciente . . . . . . . . . . . . . . . . . . . . . . . . . 252.6. Árbol de fallas para el evento principal de falla en la comunicación del

sistema HealTICa intra- y extra-WBAN . . . . . . . . . . . . . . . . . . . 25

3.1. Diagrama de bloques del hardware del nodo sensor inalámbrico . . . . . . 313.2. Diagrama de clases del �rmware del nodo HealTICa . . . . . . . . . . . . 323.3. Diagrama de clases del patrón CRC . . . . . . . . . . . . . . . . . . . . . . 343.4. Diagrama de clases del �rmware del nodo sensor incluyendo el patrón CRC. 363.5. Diagrama de clases del patrón SmartData . . . . . . . . . . . . . . . . . . 373.6. Diagrama de clases del �rmware del nodo sensor incluyendo el patrón

SmartData. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.7. Estructura del Patrón Sanity Check . . . . . . . . . . . . . . . . . . . . . 393.8. Diagrama de bloques de conexiones entre el nodo sensor y el canal de

redundancia liviana Sanity Check . . . . . . . . . . . . . . . . . . . . . . . 403.9. Diagrama de clases de la arquitectura de con�abilidad y seguridad inclu-

yendo el patrón de redundancia liviana Sanity Check. . . . . . . . . . . . . 423.10. Diagrama de clases de la arquitectura de con�abilidad y seguridad imple-

mentada en el sistema de monitorización remota HealTICa. . . . . . . . . 45

4.1. Diagrama de �ujo del comportamiento en el tiempo de una SAN . . . . . 534.2. Modelo compuesto de referencia para la evaluación de la con�abilidad del

nodo HealTICa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3. Submodelo atómico SAN del hardware del nodo sensor HealTICa . . . . . 554.4. Algoritmo CSMA/CA ranurado usado por el protocolo IEEE 802.15.4 . . 59

v

vi

4.5. Submodelo atómico SAN para la evaluación de la in�uencia del protocolode comunicación inalámbrico sobre la con�abilidad del sistema HealTICa . 60

4.6. Modelo compuesto del nodo sensor inalámbrico HealTICa con mecanismosde con�abilidad y seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.7. Submodelo atómico SAN para modelar el consumo de energía del nodosensor inalámbrico HealTICa con mecanismos de con�abilidad y seguridad 64

4.8. Submodelo atómico SAN del hardware del nodo sensor HealTICa conmecanismos de con�abilidad y seguridad . . . . . . . . . . . . . . . . . . . 66

4.9. Submodelo atómico SAN para evaluar el impacto en los valores de con-�abilidad las fallas en los sensores de aceleración y temperatura corporalcon mecanismos de con�abilidad y seguridad . . . . . . . . . . . . . . . . . 68

4.10. Submodelo SAN para modelar el impacto de las fallas en el sensor depulsioximetría del nodo sensor HealTICa con mecanismos de con�abilidady seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.11. Fiabilidad del nodo HealTICa de referencia para diferentes escenarios decongestión en el canal de comunicación inalámbrico . . . . . . . . . . . . . 72

4.12. Evaluación de la �abilidad de la comunicación del nodo HealTICa queincluye los mecanismos propuestos en la arquitectura de con�abilidad. . . 73

4.13. Fiabilidad del nodo HealTICa para diferentes valores de capacidad y por-centajes de carga de baterías . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.14. Evaluación de la �abilidad del microcontrolador del nodo HealTICa queincluye los mecanismos propuestos en la arquitectura de con�abilidad. . . 75

4.15. Evaluación del impacto sobre la �abilidad del nodo HealTICa de la tasade falla de la batería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.16. Evaluación del impacto sobre la �abilidad del nodo HealTICa de la tasade falla de la batería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.17. Evaluación de disponibilidad del nodo HealTICa de acuerdo a capacidadde carga de diferentes baterías . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.18. Evaluación de disponibilidad del nodo HealTICa de acuerdo a capacidadde carga de diferentes baterías . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.19. Módelo atómico SAN del nodo HealTICa sin incluir mecanismos de segu-ridad para evaluar la probabilidad de intrusión. . . . . . . . . . . . . . . . 80

4.20. Módelo atómico SAN del nodo HealTICa con mecanismos de seguridadpara evaluar la probabilidad de intrusión. . . . . . . . . . . . . . . . . . . 81

4.21. Evaluación del porcentaje mínimo requerido para realizar de forma �abley garantizar disponibilidad del nodo sensor de monitorización . . . . . . . 82

Índice de tablas

2.1. Listado de requerimientos de con�abilidad y seguridad obtenidos de lassesiones de co-creación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2. Límites de corrientes de fuga en las partes aplicadas para dispositivos tipoB, BF y CF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3. Límites de corrientes de fuga permitidas para las diferentes clases de dis-positivos electro-médicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4. Clasi�cación de dispositivos electro-médicos de acuerdo al estándar IEC60601-1-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5. Listado de requerimientos de seguridad eléctrica del sistema de acuerdo alestándar IEC 60601. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6. Simbología para la elaboración de análisis de árboles de falla (FTA) . . . . 212.7. Escalas de probabilidad, severidad y detección del análisis de modos de

falla y efectos, FMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.8. Análisis de modo de falla y efecto FMEA para el sistema (parte 1) . . . . 272.9. Análisis de modo de falla y efecto FMEA para el sistema (parte 2) . . . . 282.10. Análisis de modo de falla y efecto FMEA para el sistema (parte 3) . . . . 292.11. Listado de requerimientos de con�abilidad y seguridad del sistema obte-

nidos mediante los análisis FTA y FMEA. . . . . . . . . . . . . . . . . . . 29

3.1. Polinomios de CRC más utilizados. . . . . . . . . . . . . . . . . . . . . . . 343.2. Modos de seguridad disponibles en el estándar IEEE 802.15.4 . . . . . . . 443.3. Análisis de modo de falla y efecto FMEA para la arquitectura de con�a-

bilidad y seguridad (parte 1) . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4. Análisis de modo de falla y efecto FMEA para la arquitectura de con�a-

bilidad y seguridad (parte 2) . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5. Análisis de modo de falla y efecto FMEA para la arquitectura de con�a-

bilidad y seguridad (parte 3) . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1. Primitivas grá�cas para la construcción de modelos atómicos para redesde actividad estocástica (SAN) . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2. Predicados habilitadores y funciones de las compuertas de entrada delsubmodelo SAN del hardware del nodo sensor HealTICa . . . . . . . . . . 57

4.3. Función de salida del submodelo SAN del hardware del nodo sensor Heal-TICa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.4. Predicados habilitadores y funciones de entrada de las compuertas de en-trada del submodelo SAN de la comunicación inalámbrica del nodo sensorHealTICa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.5. Funciones de salida del submodelo SAN de la comunicación inalámbricadel nodo sensor HealTICa . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

vii

viii

4.6. Submodelo SAN del consumo de energía del nodo sensor HealTICa conmecanismos de con�abilidad y seguridad . . . . . . . . . . . . . . . . . . . 64

4.7. Funciones de salida del submodelo SAN de la batería del nodo sensorHealTICa con mecanismos de con�abilidad y seguridad . . . . . . . . . . . 64

4.8. Predicados habilitadores y funciones de entrada de las compuertas de en-trada del submodelo SAN del hardware del nodo sensor HealTICa conmecanismos de con�abilidad y seguridad . . . . . . . . . . . . . . . . . . . 66

4.9. Funciones de salida en el modelo SAN de fallas de hardware del nodoHealTICa con mecanismos de seguridad y con�abilidad . . . . . . . . . . . 67

4.10. Funciones de salida del submodelo SAN del nodo sensor HealTICa conmecanismos de con�abilidad y seguridad . . . . . . . . . . . . . . . . . . . 67

4.11. Funciones de salida en el modelo SAN de sensores de temperatura y ace-leración del nodo HealTICa con mecanismos de seguridad y con�abilidad . 67

4.12. Predicados habilitadores y funciones de entrada para el modelo SAN delsensor de pulsioximetría del nodo HealTICa con mecanismos de con�abi-lidad y seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.13. Funciones de salida en el modelo SAN del sensor de pulsioximetría delnodo HealTICa con mecanismos de seguridad y con�abilidad . . . . . . . 69

4.14. Parámetros constantes en los escenarios experimentales propuestos parala evaluación de la con�abilidad del nodo HealTICa . . . . . . . . . . . . . 70

4.15. Con�guración de valores experimentales para la evaluación de la �abilidaddel nodo sensor HealTICa en diferentes escenarios . . . . . . . . . . . . . . 71

4.16. Predicados habilitadores y funciones de entrada de las compuertas de en-trada para el modelo atómico de seguridad del nodo HealTICa sin meca-nismos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.17. Funciones de salida en el modelo SAN con mecanismos de seguridad delnodo HealTICa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Capítulo 1

Introducción

En este capítulo se describen la contextualización y justi�cación del presente trabajo de

investigación. Además, se introducen los conceptos y trabajos de investigación relacio-

nados, los cuales fueron usados como punto de partida para el alcance de los objetivos

propuestos, que son presentados también.

1.1. Contextualización

La seguridad y la con�abilidad son propiedades fundamentales de cualquier sistema de

cómputo y de telecomunicaciones, por lo cual es de gran importancia incluir en la etapa

de diseño medidas que garanticen un nivel adecuado de estas propiedades, y sus atributos

relacionados, de acuerdo al escenario de uso del sistema. En el caso de esta investigación se

busca identi�car amenazas a estas propiedades, proponer medidas para mitigar los riesgos

que conllevan, y evaluarlas en el diseño de una plataforma tecnológica, cuya principal

funcionalidad es la monitorización remota de pacientes en condición de hospitalización

domiciliaria, demandando una rigurosa identi�cación y cumplimiento de requerimientos

referentes a la protección de la con�dencialidad e integridad de la información, y a la

capacidad del sistema de evitar o prevenir fallas frecuentes y severas. Con base en lo

anterior, y con el objetivo de diseñar un sistema seguro y con�able, de manera que

se garantice su desempeño efectivo en el contexto del sistema de salud colombiano, en

este trabajo de investigación se propone una metodología para identi�car, incrementar y

evaluar las propiedades de con�abilidad y seguridad de un sistema para la monitorización

remota de pacientes en condición de hospitalización domiciliaria.

Una de las principales limitaciones del sistema de salud en Colombia es la atención médica

hospitalaria debido a, entre otros factores, la limitada infraestructura del sistema de salud

1

Capítulo 1. Introducción 2

y al incremento en los últimos años de la población con enfermedades crónicas, de�nidas

por la Organización Mundial de la Salud (OMS), como enfermedades de larga duración

y, por lo general, de progresión lenta. Las enfermedades cardíacas, los infartos, el cáncer,

las enfermedades respiratorias y la diabetes son las principales causas de mortalidad

en el mundo [1]. Éstas se agudizan, generalmente, en pacientes mayores a 45 años. De

acuerdo con estadísticas del Ministerio de Salud y Protección Social de Colombia, para

2020 la población mayor a los 60 años de edad en Colombia superará los seis millones

de habitantes [2]. Por estas razones se espera un aumento considerable en la atención y

hospitalización de pacientes con este tipo de enfermedades, generando un mayor impacto

en el sistema de salud debido a que su tratamiento requiere de un seguimiento continuo

y recurrente.

En el contexto de la anterior problemática, el Centro de Excelencia ARTICA (Alianza

Regional en TIC Aplicadas), desarrolló el macroproyecto "Plataforma tecnológica para

los servicios de teleasistencia, emergencias médicas, seguimiento y monitoreo de per-

manente a los pacientes y apoyo a los programas de promoción y prevención - Eje 3:

Vigilancia de eventos de riesgo para pacientes crónicos", �nanciado por el Sistema Gene-

ral de Regalías. Para abordar el diseño e implementación de la plataforma considerada

en este eje, el equipo de investigadores del proyecto la dividió en varios módulos y asignó

responsables para los mismos. En la Figura 1.1 se observan los módulos principales que

componen la plataforma. Como puede verse en la Figura 1.1, dentro de los planteamien-

tos del citado macroproyecto se consideran las redes inalámbricas de sensores de área

corporal (Wireless Body Area Network, WBAN) como una alternativa promisoria en la

implementación de sistemas de monitorización en ambientes domiciliarios, tal como lo

ha explorado el grupo de investigación en proyectos previos [3], [4], [5]. Las WBAN están

constituidas por un conjunto de pequeños nodos sensores, instalados sobre o alrededor

del cuerpo del paciente, interconectados de forma inalámbrica formado un sistema de

monitorización y procesamiento de señales �siológicas que en este caso será utilizado co-

mo apoyo al diagnóstico y la atención de pacientes crónicos en el contexto de la atención

domiciliaria [6]. Esta área de aplicación fue concertada con la IPS Universitaria que es

una institución prestadora de servicios de salud perteneciente a la Universidad de An-

tioquia y miembro de la alianza ARTICA, con experiencia en atención domiciliaria de

pacientes. Particularmente, este trabajo de investigación se ocupa de proponer medios

para elevar la seguridad y la con�abilidad de la WBAN, tal como se destaca en la Figura

1.1.


Paciente

WBAN

Procesamiento de Señales

Seguridad

SistemaRemoto

Grupo Familiar/médico

Confiabilidad

Figura 1.1: Componentes de la plataforma para la vigilancia de eventos de riesgo enpacientes crónicos.

1.2. Planteamiento del problema

El acelerado avance en los últimos años de las WBAN en aspectos como miniaturización,

reducción de costos monetarios y energéticos, mayor capacidad de cómputo y estandariza-

ción de protocolos de comunicación, permite pensar en la consolidación de esta tecnología

como una excelente alternativa para mejorar los procesos de tratamiento y diagnostico

de paciente con enfermedades crónicas, caracterizadas por su larga duración y lento pro-

greso, al posibilitar el monitorización remota de signos vitales, mejorando la calidad de

vida de los pacientes, descongestionando la infraestructura hospitalaria y disminuyendo

los tiempos de atención [7]. En la Figura 1.2 se presenta la arquitectura típica de una

aplicación médica basada en una WBAN. La WBAN está constituida por nodos sensores

interconectados de forma inalámbrica que se ubican o implantan en diferentes partes del

cuerpo humano. Estos dispositivos tienen capacidad de adquirir, procesar y transmitir

señales �siológicas, y concentran la información adquirida, transmitiéndola a un nodo

central denominado sink, encargado del procesamiento de los datos y de proporcionar la

interfaz entre la WBAN y las redes de comunicación tradicionales [8]. La extraWBAN

hace referencia al sistema remoto donde se despliega la información médica del paciente

recogida por los nodos sensores. Esta información se deja disponible para análisis por


Figura 1.2: Escenario general de sistema de monitorización remoto de pacientes ba-sado en redes inalámbricas de área corporal WBAN

parte del personal médico encargado del paciente, y conocimiento del círculo de acompa-

ñamiento del mismo, entendido este último como los familiares o personas responsables

de brindar la primera atención al paciente cuando se presente un evento que ponga en

riesgo su salud. Además del diagnóstico que puede realizar el personal médico a partir

de la información médica proporcionada por los nodos sensores, tanto la red de sensores

como el sistema remoto deben estar en capacidad de generar automáticamente alertas

ante la presencia de eventos de riesgo, que serán transmitidas a través de las interfaces de

comunicación del sistema, de manera que se pueda prestar atención oportuna al paciente

por parte del círculo de acompañamiento y el personal médico.

Pese al potencial de la tecnología WBAN, la cual ha despertado mucho interés a nivel

de investigación en los último años [9], [10], [11], persisten algunos problemas que de-

ben solucionarse para que sea adoptada de forma efectiva por las entidades prestadoras

de servicios de salud. Uno de ellos está relacionado con las amenazas típicas a las pro-

piedades de seguridad y con�abilidad [12], tales como las fallas en el hardware de un

nodo sensor, el desvanecimiento de la señal inalámbrica causado por el cuerpo humano,

interferencia del medio ambiente, calidad del diseño hardware/software, autonomía de

batería insu�ciente, y ausencia de medidas para asegurar la con�dencialidad e integridad

de la información médica. Estas amenazas deben ser mitigadas con el �n de garantizar la

disponibilidad de nodos con�ables y seguros para aplicaciones médicas. Se hace necesa-

rio, entonces, especi�car y evaluar una arquitectura que incluya técnicas de mitigación, a

nivel hardware y software, de las amenazas identi�cadas relacionadas con las propiedades

de con�abilidad y seguridad, considerando como escenario de uso la atención y hospi-

talización domiciliaria. Es importante destacar que la evaluación de las propiedades de

con�abilidad y seguridad es una tarea compleja, que típicamente se aborda empleando


modelos basados en procesos estocásticos de tipo markoviano, cuyo principal problema es

que el tamaño de los espacios de estados crece de manera exponencial, de acuerdo con la

complejidad del sistema. Para hacer viable un método de evaluación de las propiedades

de con�abilidad y seguridad de un sistema con las características del que se plantea, es

necesario disponer de modelos de buena calidad en los que el número de estados esté

bajo control, de manera que no pierdan precisión y permitan lograr buenas estimaciones

en tiempo de diseño con un costo computacional tolerable.

Así, se busca garantizar que las WBAN ofrezcan con�abilidad a los usuarios durante

los tiempos de uso requeridos para la adquisición, procesamiento y comunicación de

información médica y pueden preservar la seguridad de la información médica, a través

de medidas que permitan prevenir la ocurrencia o introducción de fallas en el sistema y

tolerar la presencia de las mismas.

1.3. Conceptos y trabajos relacionados

Antes de enunciar los objetivos del presente trabajo, esta sección introduce los conceptos

básicos de con�abilidad y seguridad sobre los que se sustentan. Asimismo, se presenta el

trabajo relacionado.

1.3.1. Con�abilidad y seguridad en sistemas de computación y comunicación

Para proponer una arquitectura de con�abilidad y seguridad es importante conocer la

terminología y conceptos asociados a estas dos propiedades fundamentales. En la Figura

1.3 se muestra la relación entre los atributos, amenazas y métodos para incrementar

los atributos asociados con las propiedades de con�abilidad y seguridad, tal como fue

propuesta por Aviºienis at al. [13]. En esta taxonomía se presentan de forma intencional

algunos conceptos con su traducción en inglés, para evitar confusión en su uso.

La con�abilidad (dependability) hace referencia a la capacidad de un sistema de evitar

las fallas con mayor probabilidad de ocurrencia y las más perjudiciales, de tal manera

que no afecten su normal funcionamiento. Por su parte, la seguridad (security) se de�ne

como la ausencia de accesos y manipulaciones no autorizados del sistema. El atributo de

disponibilidad se de�ne como la capacidad del sistema para funcionar de forma correcta

en el momento requerido. La �abilidad (reliability) se re�ere a la capacidad de ejecutar

satisfactoriamente la funcionalidad del sistema sin experimentar fallas. La protección

(safety) está de�nida como la ausencia de consecuencias catastró�cas sobre el usuario

o el entorno cuando se presentan fallas fortuitas. Mediante el atributo de con�denciali-

dad se asegura la divulgación de información sólo a personal autorizado. La ausencia de


Confiabilidad y Seguridad

(Dependabilityand Security)

DisponibilidadFiabilidad (Reliability)Protección (Safety)ConfidencialidadIntegridadMantenibilidad

Fallas (Faults) ErroresAverías (Failures)

Prevención de fallasTolerancia a fallasEliminación de fallasPredicción de fallas

Atributos

Amenazas

Métodos

Figura 1.3: Taxonomía de las propiedades de con�abilidad y seguridad de un sistema.

alteraciones no autorizadas tanto de la información como del sistema se denomina inte-

gridad. La mantenibilidad se entiende como la capacidad que tiene el sistema de soportar

modi�caciones y reparaciones. Los atributos presentados en la Figura 1.3 son críticos en

sistemas de monitorización médica, dada la naturaleza privada de la información médica

de un paciente, y la necesidad de ofrecer un sistema que preste servicios funcionalmente

correctos y seguros en el momento que se requieran.

Las amenazas a la con�abilidad y la seguridad están asociadas a tres conceptos princi-

pales: fallas, errores y averías, que tienen incidencia sobre la vulnerabilidad del sistema

y se de�nen así:

- Avería (Failure): es un concepto asociado al evento que ocurre cuando la funciona-

lidad del sistema se desvía de su correcto funcionamiento.

- Error: es la desviación del correcto funcionamiento de un sistema causado por una

falla.

- Falla (Fault): es la causa hipotética de un error.

Una vulnerabilidad se entiende como una falla interna del sistema que le permite a una

falla externa dañar el sistema. Si no existe la vulnerabilidad, la falla externa no puede

causar errores y consecuentemente averías, como se muestra en la Figura 1.4, donde se

observa la activación de una falla, la propagación de errores sobre varios componentes

de un sistema y las consecuentes averías en la correcta prestación del servicio.


Falla

Interna

Latenteactivación

Error Error

propagaciónFalla

Externa

propagación

Componente A

Error

de entrada

propagaciónError

Interface deServicio

propagación

Componente B

Error Error

propagación

Interface deServicio

Estado del servicio

del Componente A

Estado del servicio

del Componente B

FuncionamientoCorrecto Avería Servicio

Incorrecto

FuncionamientoCorrecto Avería

Servicio Incorrecto

Figura 1.4: Secuencia de amenazas a la seguridad y la con�abilidad.

Los métodos para mejorar los atributos asociados a la seguridad y la con�abilidad se

pueden agrupar en cuatro categorías:

- Prevención de fallos: métodos para prevenir la ocurrencia o introducción de fallos.

- Tolerancia a fallos: métodos para evitar averías en el servicio ante la presencia de

fallos.

- Remoción de fallos: métodos enfocados a reducir el número y severidad de los fallos

- Predicción de fallos: métodos que buscan estimar el número presente, la incidencia

futura y las probables consecuencias de los fallos.

En la actualidad es de gran importancia ofrecer dispositivos de computación y teleco-

municaciones con�ables y seguros, teniendo en cuenta que sus aplicaciones son cada vez

más diversas, abarcando servicios de seguridad crítica tales como plantas nucleares, ae-

ronaves o dispositivos médicos. Una falla en este tipo de aplicaciones puede tener como

consecuencia daños catastró�cos representados en la muerte de uno o varios seres huma-

nos. Por lo anterior es importante tener claridad sobre las propiedades fundamentales de

este tipo de sistemas, las cuales se deben considerar de manera minuciosa en el diseño

y desarrollo de este tipo de sistemas. A continuación se presentan algunos trabajos rela-

cionados en donde se proponen metodologías de identi�cación y evaluación de amenazas

a la con�abilidad y seguridad de sistemas basados en la tecnología de nodos sensores

inalámbricos para aplicaciones críticas.

1.3.2. Trabajos relacionados

En la bibliografía se reportan algunos trabajos sobre la identi�cación y mitigación de

amenazas, y técnicas para la evaluación de las propiedades de con�abilidad y seguridad


en WBANs. En [12] Hovakeemian et al. identi�can las causas potenciales de fallas en una

WBAN relacionadas con hardware de baja �abilidad, autonomía energética insu�cien-

te, interferencia electromagnética y ausencia de medidas que ofrezcan con�dencialidad

e integridad de la información. En cuanto a las medidas de mitigación propuestas, se

destacan la retransmisión de tramas de datos por el medio inalámbrico, incorporando

técnicas de cifrado de la información y la inclusión de nodos redundantes. Sin embargo,

esta última implica un aumento de costo, además de afectar requerimientos como la ergo-

nomía y movilidad del sistema. A pesar de identi�car las amenazas y proponer medidas

para incrementar la con�abilidad y seguridad de las WBANs en aplicaciones médicas,

este trabajo carece de una evaluación de los atributos de con�abilidad y seguridad antes

y después de aplicar las medidas de mitigación propuesta por los autores. Entre tanto

en [14], Ivanovitch et al. proponen una metodología para la evaluación de la �abilidad

de un nodo sensor inalámbrico, basado en la generación automática de árboles de fallos

(FTA) para representar la ocurrencia de una falla permanente en los dispositivos de la

red. Es importante resaltar la versatilidad del método de evaluación propuesto en este

trabajo, al ser compatible con diferentes topologías de red, permitir la inclusión de dife-

rentes niveles de redundancia, recon�guración de rutas de enrutamiento y condiciones de

fallo arbitrarias, con lo cual es posible optimizar parámetros en la etapa de diseño que

podrían afectar a los atributos de con�abilidad y seguridad. Como caso de uso los auto-

res evaluaron la con�abilidad de un nodo sensor inalámbrico en un ambiente industrial,

permitiendo identi�car amenazas y cuellos de botella de �abilidad y disponibilidad de

una red de sensores inalámbricos (Wireless Sensor Network, WSN). Otro enfoque para

evaluar la �abilidad se reporta en [15], donde Cinque et al., además de la identi�cación de

las amenazas a la �abilidad y la disponibilidad de una WSN, proponen el uso de redes de

actividad estocástica (Stochastic Activity Network, SAN) para la evaluación y el análisis

de sus atributos de �abilidad y disponibilidad. La clasi�cación de las amenazas y riesgos

potenciales la realizan utilizando el análisis de modo de fallo y de efecto (Failure Mode

and E�ect Analisys, FMEA) con el �n de obtener el modelo de fallo de un único nodo

sensor. Cabe resaltar el uso que hacen de bibliotecas externas en el modelo de SAN, para

modi�car el comportamiento de fallo en tiempo de ejecución de acuerdo con la dinámica

de la red. Los resultados de la evaluación de la WSN para una aplicación médica carecen

de planes o medidas que aumentan los valores de �abilidad y disponibilidad diferentes

al uso de nodos redundantes, donde se observa un aumento en los valores de los atribu-

tos evaluados, pero no se menciona el costo en términos de consumo energético, costo

monetario e impacto sobre otros requerimientos no funcionales del sistema.

En la literatura se abordan los diferentes atributos asociados a la propiedad de segu-

ridad identi�cando las amenazadas en WBANs para aplicaciones médicas. En cuanto

a con�dencialidad, la principal amenaza esta vinulada con la captura y divulgación no


autorizada de información médica del paciente, transmitida inalámbricamente entre los

nodos sensores de la WBAN. En [16] Lui y Ning proponen la inclusión de mecanismos

de cifrado y listas de control de acceso como protección a la con�dencialidad. El uso

de cifrado simétrico es el más adecuado para este tipo de redes, teniendo en cuenta que

el cifrado de clave pública requiere un alto costo computacional. La integridad de este

tipo de sistemas es afectada por la modi�cación mal intencionada de tramas de datos

intercambiados por los nodos de la WBAN (Captura de nodos). En [17] Khattiya et al.

proponen métodos de corrección de errores en la capa MAC (Medium Access Control)

tales como códigos Reed-Solomon. La disponibilidad es un atributo vulnerable por su

relación con el correcto funcionamiento de la comunicación inalámbrica. Se destacan los

ataques de denegación de servicio y ataques sobre los mecanismos de enrutamiento. En

[18] Sharmilee et al. proponen la redundancia de nodos o detección de intrusiones en

la red (Intrusion Detection System, IDS) usando señales biometricas y MAC (Message

Authentication Code), estos últimos de gran complejidad y alto costo computacional.

A pesar de encontrar diferentes reportes donde se identi�can y evalúan las amenazas a

la con�abilidad y seguridad de aplicaciones críticas basadas en la tecnología WBAN, es

de resaltar la ausencia de investigaciones enfocadas a proponer y evaluar alternativas

tecnológicas dirigidas a incrementar estas propiedades a través de técnicas ya sea de

hardware o software, que permitan mitigar las amenazas a los atributos asociados a estas

propiedades. Se determina entonces la necesidad de suplir esta carencia, formulando una

arquitectura de con�abilidad y seguridad para aplicaciones de monitorización remota

de pacientes, iniciando con la identi�cación y de�nición de requerimientos, proponiendo

estrategias de mitigación y evaluándolas en un ambiente controlado, permitiendo aceptar

o descartar, de acuerdo a los resultados, las que mejor se ajusten a este tipo de aplicación.

1.4. Objetivos

Los objetivos general y especí�cos que se plantearon para este trabajo de investigación

se presentan a continuación.

1.4.1. Objetivo general

Formular una estrategia para de�nir e integrar atributos de con�abilidad y seguridad en

WBANs aplicadas a escenarios de atención y hospitalización domiciliaria.


1.4.2. Objetivos especí�cos

1. Establecer los atributos más importantes relacionados con la con�abilidad y segu-

ridad de este tipo de redes en el contexto mencionado.

2. Proponer una arquitectura y mecanismos a nivel de hardware y software en las

WBANs para satisfacer estos atributos.

3. Veri�car de forma experimental la efectividad de las arquitecturas y mecanismos

propuestos en escenarios controlados.

1.5. Estructura del trabajo de investigación

El resto del trabajo de investigación consta de 4 capítulos. En el capítulo 2 se describe

la metodología usada para identi�car las amenazas y requerimientos de con�abilidad y

seguridad de la plataforma de monitorización remota de pacientes en condición de hospi-

talización domiciliaria. En el capítulo 3 se describen en detalle las técnicas y mecanismos

de hardware y software que conforman la arquitectura de con�abilidad y seguridad. En

el capítulo 4, la arquitectura es evaluada en un ambiente experimental controlado usando

herramientas de simulación computacional a través de técnicas de modelado estocástico

de las fallas. Cada modelo es acompañado de la discusión de sus resultados. Finalmente,

en el capítulo 5 se presentan las conclusiones de la metodología propuesta y los trabajos

futuros que pueden surgir a partir de los resultados obtenidos en esta investigación.

Capítulo 2

Identi�cación de requerimientos de

con�abilidad y seguridad

Este capítulo está conformado por la descripción de la estrategia de co-creación utili-

zada para identi�car los requerimientos asociados a las propiedades de con�abilidad y

seguridad del sistema en la etapa de diseño, usando técnicas que permitieron contar con

una activa participación de los stakeholders o interesados del proyecto. Además, incluye

la revisión de recomendaciones plasmadas en estándares internacionales para el diseño

y fabricación de equipos electró-médicos seguros que son aplicables al sistema en desa-

rrollo, y la exploración de técnicas para la identi�cación de amenazas a la seguridad y

con�abilidad útiles en el contexto del presente trabajo.

2.1. Estrategia de co-creación

Esta estrategia se basa en el principio de que un nuevo producto tiene una probabilidad

más alta de convertirse en una innovación si sus atributos y funcionalidades se deter-

minan mediante co-creación con los usuarios o clientes del sistema [19]. Al interior del

Centro de Excelencia ARTICA se han diseñado varias técnicas de innovación que per-

miten desarrollar nuevos productos basados en co-creacion [20]. Mediante esta estrategia

se determinaron los requerimientos, atributos y funcionalidades del proyecto a partir de

la inclusión de los stakeholders o interesados del proyecto en el proceso de diseño, discu-

tiendo con ellos en sesiones con alto componente didáctico, las fortalezas, debilidades y

necesidades por satisfacer en el actual proceso de prestación del servicio de atención do-

miciliaria de pacientes en ambientes de hospitalización domiciliaria [21]. Las sesiones de

co-creación contaron con la participación de médicos, enfermeras y personal administra-

tivo de la IPS Universitaria de la Universidad de Antioquia [22], que es una institución

11

Capítulo 2. Identi�cación de requerimientos de con�abilidad y seguridad 12

prestadora de servicios de salud, con experiencia en procesos de atención hospitalaria

en el domicilio de los pacientes. En cada sesión de co-creación existía un coordinador,

representado en este caso por el personal cientí�co asociado al proyecto, encargado de

dirigir la actividad y recopilar la información. A continuación se detallan las técnicas

de co-creación aplicadas para la determinación de los atributos y funcionalidades del

sistema, a partir de los cuales se de�nieron los requisitos funcionales y no funcionales,

particularmente aquellos referidos a la seguridad y la con�abilidad, que son el objeto de

estudio de este trabajo.

Análisis de actividades: mediante esta técnica se pudieron determinar, con los usua-

rios y los prestadores del servicio, las etapas de las que se compone el proceso de atención

domiciliaria, así como las di�cultades que se presentan en su ejecución. El proceso fue

descrito como una línea de tiempo en la que para cada etapa los participantes aportaron

sus conocimientos y experiencia. Los problemas asociados a la atención domiciliaria que

fueron identi�cados, con relevancia para el presente trabajo, fueron la disponibilidad de

los sistemas de información, la adquisición y transmisión de información médica con�able

y segura, es decir, garantizando su con�dencialidad.

Sketch and match: el objetivo de esta técnica era obtener un diagrama del sistema

para la monitorización remota de pacientes en condición de hospitalización domiciliaria,

desde el punto de vista del personal médico de la IPS Universitaria. Entre los atributos

de protección identi�cados se resalta la necesidad de seguir las recomendaciones de es-

tándares internacionales para la fabricación de dispositivos médicos, los cuales establecen

directrices para asegurar la integridad física del paciente y la con�abilidad del sistema

teniendo en cuenta el escenario de aplicación.

Forecasting : con esta técnica se buscaba identi�car tendencias tecnológicas en el con-

texto de la atención domiciliaria que pudieran ser aplicables en el desarrollo del sistema y

que facilitaran su inserción en el sistema de salud colombiano. Dentro de estas tendencias

fueron citados los dispositivos electrónicos para el cuidado de pacientes, la interacción a

través de redes sociales y el almacenamiento en la nube de la historia clínica. De acuerdo

a estas tendencias, el personal médico y administrativo de la IPS ayudó a establecer

algunas características que debía poseer el sistema, como son con�abilidad y seguridad

de la información generada, y uso personalizado y continuo del sistema.

Si yo fuera: esta técnica está basada en un juego de roles en el que se consideran to-

dos los posibles actores (stakeholders) del sistema, y tenía el propósito de obtener sus

principales atributos desde diferentes perspectivas. Cada participante asumió cada uno


de los roles establecidos para el sistema y aportó, desde su conocimiento y experiencia,

los atributos que le gustaría que incluyera un sistema para la monitorización remota de

pacientes en condición de hospitalización domiciliaria. Los roles de�nidos en este ejercicio

fueron médico, paciente, miembro del círculo de acompañamiento e ingeniero de desarro-

llo. De la aplicación de esta técnica se obtuvieron atributos y funcionalidades referidas

a la usabilidad (sistema cómodo, no invasivo, personalizable, seguro) y a su capacidad

de capturar signos vitales y generar alertas cuando estos estuvieran fuera de unos ran-

gos determinados, las cuales deberían ser noti�cadas al personal médico y el círculo de

acompañamiento. Todos los participantes desde sus roles destacaron la importancia de

incluir mecanismos que elevaran la �abilidad y con�dencialidad del sistema en la captu-

ra, procesamiento y transmisión de la información médica.

Prototipado: mediante esta última técnica se buscó obtener un prototipo conceptual

del sistema de monitorización remota de pacientes en condición de hospitalización domi-

ciliaria. Se pidió a los participantes en la sesión de co-creación (ingenieros del proyecto,

médicos y personal administrativo de la IPS Universitaria) elaborar un dibujo del sistema

que representara un prototipo conceptual del mismo. Para elaborar el prototipo concep-

tual los médicos se pusieron de acuerdo en el tipo de enfermedades crónicas que serían de

interés para el sistema. Se descartaron las enfermedades renales por el análisis continuo

de muestras de laboratorio que acarrean, concentrándose en las enfermedades cardiacas y

respiratorias. Para estas enfermedades los participantes de�nieron las señales �siológicas

a capturar, la ubicación de los respectivos sensores en el cuerpo del paciente para lograr-

lo, y los mecanismos para la generación de alertas ante eventos de riesgo para el paciente.

ID Requerimiento detallado

CS1 El proceso de diseño del sistema de apoyo a la atención domiciliaria debecontar con metodologías, tanto a nivel de hardware como de software, quepermitan cumplir con parámetros de seguridad y con�abilidad mínimospara equipos médicos recomendados por estándares internacionales.

CS2 El diseño de la red de sensores debe abordarse con técnicas que permitanincrementar la con�abilidad y disponibilidad de las variables médicas.

CS3 Los datos del paciente deben ser almacenados y transmitidos de formacifrada, para conservar la con�dencialidad de la información médica.

CS4 El nodo sensor deben permitir la veri�cación de autenticidad de los men-sajes recibidos, implementado técnicas de seguridad de la información.

Tabla 2.1: Listado de requerimientos de con�abilidad y seguridad obtenidos de lassesiones de co-creación.

Tras el análisis de la información recopilada en las sesiones de co-creación se identi�caron

requerimientos importantes a tener en cuenta en el diseño del sistema, ajustados a las


necesidades y características expresadas por los stakeholders, las cuales son particulares

para el contexto colombiano . En la Tabla 2.1 se presentan de manera concisa los reque-

rimientos de seguridad y con�abilidad establecidos para el sistema, que son los de interés

en este trabajo de investigación.

2.1.1. Diseño conceptual del sistema

A partir de la estrategia de co-creación y vigilancia tecnológica, se propusieron las carac-

teristicas y requerimientos funcionales y no funcionales del primer prototipo del sistema

de monitorización remota de pacientes en condición de hospitalización domiciliaria de-

nominado HealTICa. Con la participación del equipo de trabajo del macro-proyecto y

la validación del personal médico de la IPS Universitaria, se desarrolló una sesión de

co-creacion más para obtener un prototipo conceptual del sistema, durante la cual se

de�nieron la forma del sensor y la comunicación entre los componentes de la WBAN.

En la Figura 2.1 se muestra el diseño conceptual obtenido. El sistema está conforma-

do por dos componentes típicos de las WBANs, un nodo sensor donde se adquieren y

pre-procesan las variables �siológicas de interés (temperatura corporal, frecuencia car-

díaca, concentración de oxigeno en la sangre (SpO2), señal electrocardiogra�ca (ECG)

y aceleración), y un nodo sink que está a cargo de procesar, interpretar y visualizar la

información obtenida por el nodo sensor. El nodo sink, además, posibilita la transmisión

de la información médica hacia un sistema remoto donde es almacenada y desplegada

al personal médico autorizado y al círculo de acompañamiento del paciente, que es el

primer responsable de su atención ante una situación de riesgo. Teniendo en cuenta su

alta capacidad de procesamiento, múltiples interfaces de comunicación y gran acogida

en los últimos años, se determinó usar un smartphone como nodo sink. Para la comuni-

cación inalámbrica con el nodo sensor, la cual es realizada utilizando el protocolo IEEE

802.15.4, se desarrolló un dongle USB que funciona como gateway entre la comunicación

inalámbrica y la interfaz de comunicación USB del smartphone (comunicación serial).

Para la visualización y con�guración de parámetros de monitorización, se desarrolló una

aplicación móvil, que se ejecuta en el nodo sink, en donde además se incluyen algoritmos

de análisis de la señal ECG que posibilitan el diagnóstico de diferentes tipos de anoma-

lías cardiacas, lo cual permite prevenir episodios catastró�cos sobre la salud del paciente.

Cabe resaltar que la forma y ubicación del nodo sensor, fueron diseñados pensando en la

movilidad y ergonomía del usuario como principales requerimientos no funcionales. Por

lo tanto, el nodo sensor sensor está ubicado en una especie de collar abierto rígido que

reposa sobre el cuello del paciente, dándole comodidad y facilidad de uso, y desde él se

desprenden los electrodos hasta la caja torácica del paciente para la adquisición de la


señal ECG. En tanto los sensores de SpO2 y temperatura están ubicados en la oreja del

paciente.

Smartphone

Circúlo de Acompañamiento

Nodo HealTICa

PersonalMédico

Dongle

MCU

Batería

SeñalECG

SpO2

TemperaturaCorporal

RadioTransceptor

Electrodos

OpticalSensor

Electrodos

Figura 2.1: Diseño conceptual del sistema HealTICa

2.2. Estándares de seguridad para equipos electro-médicos

Una vez concebido el diseño conceptual del sistema, se presenta el análisis de normas

y estándares que regulan y de�nen las características que debe cumplir, a �n de ser

utilizado en el contexto deseado. En este caso particular, la recomendación hecha por el

personal médico en las sesiones de co-creación se enfocó en la revisión de requerimientos

de acuerdo a los estándares para el diseño de dispositivos electrónicos con propósitos

médicos, los cuales se resumen a continuación.

2.2.1. Estándar IEC 60601-1

El estándar IEC 60601-1, publicado por la International Electrotechnical Commission,

referente a los requerimientos de seguridad en equipos electro-médicos, tiene como objeti-

vo establecer las características básicas de seguridad que deben cumplir los equipos elec-

trónicos de monitorización o diagnostico médico, cuyo funcionamiento exige el contacto

directo de alguna de sus partes con el paciente y además integran fuentes de alimentación

eléctrica [23]. Para la plataforma de monitorización remota de pacientes con enfermeda-

des crónicas en condición de hospitalización domiciliaria, se enfatizó en los requerimientos

que conducen a la reducción de la probabilidad de riesgo eléctrico en el sistema, lo cual

apunta a identi�car y mitigar las amenazas a la protección de la integridad física del

usuario. Además, en el estándar se encuentran establecidos los requerimientos y reco-

mendaciones para mitigar el riesgo asociado a partes mecánicas, elementos radiactivos o


ignición y temperaturas excesivas, los cuales no fueron analizados durante el desarrollo

de esta investigación.

Un accidente eléctrico con un equipo electro-médico puede llegar a dañar tejidos, órganos

o incluso causar la muerte del paciente. En el sistema bajo análisis, se obtiene de la

señal de electrocardiografía (ECG) utilizando electrodos ubicados sobre la piel de la caja

torácica del paciente, como se observa en la Figura 2.1, y aunque no existe inyección de

corriente al cuerpo, es necesario considerar módulos de protección ante fallos eléctricos

o fugas de corriente indeseadas en el sistema; teniendo en cuenta que el corazón es el

órgano más susceptible a sufrir daños ante la inyección de �ujos de corriente. De acuerdo

a las características de la fuente de alimentación y el punto de contacto con el paciente

se establecen diferentes niveles de aislamiento (de�nido en el estándar como clase) y

grado de seguridad (de�nido como tipo), con lo cual se busca limitar los efectos adversos

en la salud del paciente, minimizando el �ujo de corriente que puede llegar al usuario

u operador del equipo ante posibles fallas eléctricas. En la Figura 2.2 se presenta la

simbología correspondiente a cada tipo de dispositivo. A continuación se presenta la

clasi�cación de�nida en el estándar y los requerimientos asociados a cada grupo.

(a) (b) (c)

Figura 2.2: Simbología establecida en el estándar IEC 60601-1 correspondiente a losdiferentes tipos de dispositivos electro-médicos. (a) tipo B, (b) tipo BF y (c) tipo CF.

Tipo B: ofrece un grado básico de protección contra fallas eléctricas que produzcan

corrientes de fuga. Las partes aplicadas (o en contacto con el paciente) deben tener

conexión �able a tierra. Es la clasi�cación de menor exigencia en cuanto a medidas

de aislamiento eléctrico, pues las partes aplicadas (parte en contacto con el cuerpo del

paciente) no son conductoras.

Tipo BF (Body Floating): se clasi�can en este tipo todos los dispositivos que tienen

contacto conductivo con el paciente a través de un circuito �otante con respecto a tierra,

el cual brinda una protección adicional. El aislamiento a tierra de las partes aplicadas

elimina la conducción de corrientes de fuga a través del cuerpo.


CorrienteTipo B Tipo BF Tipo CF

CN CF CN CF CN CFCorriente de fuga a tierra 500 µA 1 mA 500 µA 1 mA 500 µA 1 mACorriente de fuga de carcasa 100 µA 500 µA 100 µA 500 µA 100 µA 500 µACorriente de fuga del paciente 100 µA 500 µA 100 µA 500 µA 10 µA 50 µA

Tabla 2.2: Límites de corrientes de fuga en las partes aplicadas para dispositivos tipoB, BF y CF.

Tipo CF (Cardiac Floating): es la clasi�cación más exigente ya que en este tipo se

incluyen los dispositivos que contienen partes aplicadas conductivas en contacto directo

con el corazón. Los límites en las corrientes de fuga permitidos son muy estrictos, teniendo

en cuenta el alto riesgo.

En la Tabla 2.2, se presentan los valores máximos permitidos de los diferentes tipos de

corrientes de fuga para cada tipo de dispositivo electro-médico. Se presentan los valores

para condiciones normales (CN) y en condición de falla (CF) del dispositivo. La corriente

de fuga a tierra se de�ne como la corriente que �uye en el conductor a tierra, mientras que

la corriente de fuga de carcasa es aquella que �uye hacia tierra a través del paciente desde

la carcasa. Finalmente, la corriente de fuga del paciente hace referencia a la corriente

que puede �uir hacia tierra a través del paciente desde una parte aplicada.

La categorización de los dispositivos de acuerdo al estándar IEC 60601-1, además de

considerar el tipo de partes aplicadas del sistema, también considera la fuente de ali-

mentación. Para el caso de fuentes externas se clasi�can en dos clases, donde cada cla-

se especi�ca las características del aislamiento eléctrico requerido. Los dispositivos con

fuente de alimentación externa son considerados en una clase aparte. En la Tabla 2.3 se

presentan los valores limites para las diferentes categorías establecidas en el estándar.

Clase I: dispositivos que contienen protección suplementaria a tierra, (PE, Protective

Earth) la cual consiste en la conexión de todos los conductores del equipo a un punto

común por medio de hilos de muy baja resistencia. Este punto está a su vez conectado a la

tierra física [24], de tal manera que los componentes metálicos accesibles no se conviertan

en partes vivas al momento de la ocurrencia de una falla del aislamiento básico.

Clase II: estos dispositivos no cuentan con PE y utilizan como protección de fallas eléc-

tricas una capa adicional de aislamiento. El aislamiento básico puede ser proporcionado

por la separación física de los conductores vivos y la carcasa del equipo. El material de

la carcasa es usado como mecanismo de aislamiento suplementario a través del uso de

materiales dieléctricos como el plástico.

Equipos con alimentación interna: para los dispositivos que cuentan con alimenta-

ción interna, como el caso del sistema de monitorización de pacientes en condición de


Clase Limite de corriente de fuga

I0,75 mA (equipos portables)3,5 mA (equipos que operan en el área deatención del paciente)

II 0,25 mAAlimentación interna 0,5 mA

Tabla 2.3: Límites de corrientes de fuga permitidas para las diferentes clases de dis-positivos electro-médicos.

hospitalización domiciliaria, se de�ne la clase de equipos con fuente de alimentación in-

terna SELV (Separated or Safety Extra-Low Voltage), la cual no supera los 25 VAC ó 60

VDC. El voltaje de una fuente de alimentación SELV es considerado seguro en condi-

ciones de funcionamiento normal, por lo que el paciente puede tener contacto con piezas

aplicadas conductivas del equipo, minimizando el riesgo de descargas eléctricas o fugas

de corrientes que produzcan daños en su integridad física. Sin embargo, es importante

considerar mecanismos de prevención de corrientes de fuga, al tener partes aplicadas

que podrían, en condición de falla, inyectar pequeñas corrientes de fuga al cuerpo del

paciente.

Teniendo en cuenta las características eléctricas del sistema de monitorización de pacien-

tes en condiciones de hospitalización domiciliaria, se concluye que este se clasi�ca como

equipo con alimentación interna, Tipo BF, con lo cual los requerimientos de seguridad

eléctrica se enfocan al cumplimiento de las recomendaciones estipuladas en el estándar

para esta clasi�cación. Al �nal de esta sección se presentan los requerimientos obtenidos

de este análisis.

2.2.2. Estándar IEC 60601-1-2

El estándar IEC 60601-1-2 [25] es una norma colateral del estándar principal de reque-

rimientos básicos de seguridad para dispositivos electro-médicos (IEC 60601-1). En él

se establecen los requisitos generales y los ensayos correspondientes a la Compatibilidad

Electromagnética (CEM) de equipos electro-médicos. La CEM es de�nida en el están-

dar como la capacidad de un sistema para funcionar satisfactoriamente en su entorno

electromagnético, sin introducir perturbaciones electromagnéticas (EM) intolerables pa-

ra todo aquello que se encuentre en dicho entorno [23]. El sistema de monitorización y

detección de eventos de riesgos está basado en la transmisión de información a través

de tecnologías inalámbricas de área corporal WBAN, por lo tanto exige determinar los

requerimientos de compatibilidad electromagnética que debe cumplir el sistema. Para las

pruebas de radiación EM, la norma IEC 60601-1-2 hace referencia a la norma CISPR

11 del Comité Internacional Especial de Perturbaciones Radioeléctricas, la cual incluye


Clasi�cación Descripción

Clase A Equipos destinados para ser usados en ambientes hospitalarios

Clase BEquipos destinados para ser utilizados en cualquier ambiente,incluyendo el doméstico y conectados a la red eléctrica de bajatensión.

Grupo 1

El dispositivo utiliza radiación de energía en RF (radio frecuen-cia) para su funcionamiento interno. Las emisiones de RF sonmuy bajas y es poco probable la interferencia electromagnética(IEM) con otros equipos electrónicos cercanos.

Grupo 2El dispositivo debe emitir energía electromagnética para reali-zar su función principal. Los dispositivos electrónicos cercanospueden ser afectados por IEM.

Tabla 2.4: Clasi�cación de dispositivos electro-médicos de acuerdo al estándar IEC60601-1-2

todos los dispositivos electrónicos que presenten radiaciones entre los 0 Hz a 400 GHz y

establece los límites de emisión de radiación para frecuencias en el rango de 9 kHz a 400

GHz [26]. Los dispositivos electro-médicos cobijados por esta norma son clasi�cados en

dos grupos y dos clases de acuerdo a sus características de radiación electromagnética

y el ambiente en el cual se utilizará. En la Tabla 2.4 se presenta la descripción de cada

clase y grupo de�nidos en el estándar.

De la Tabla 2.4 se puede concluir que el sistema de monitorización de pacientes en

condición de hospitalización domiciliaria HealTICa se clasi�ca como Clase A, Grupo 1.

Sin embargo, es importante tener en cuenta que dispositivos electrónicos a distancias

cercanas al sistema pueden ser afectados por interferencia electromagnética de los radios

IEEE 802.15.4. En la ecuación 2.1, tomada del estándar IEC 60601-1-2 [25] se presenta

el cálculo de la distancia máxima (d), expresada en metros, a la cual se presenta IEM

para dispositivos que operan a frecuencias entre los 80 MHz y 2,5 GHz.

d = 2,3√p (2.1)

En la ecuación 2.1, p es la máxima potencia de salida en vatios del radio transmisor

El prototipo HealTICa emplea un radio IEEE 802.15.4 cuya potencia de transmisión,

de acuerdo a [27], corresponde a 0,002238[W ]. Es decir, equipos electrónicos ubicados

a distancias menores a 10 cm del transmisor IEEE 802.15.4 del sistema pueden verse

afectados por IEM. Considerando el valor entregado en este caso por la ecuación 2.1, es

necesario restringir el uso del sistema a pacientes con marcapasos, ya que la distancia

necesaria para evitar las IEM debidas a las transmisiones de datos a 2,4 GHz pueden

ocasionar mal funcionamiento del mismo, desencadenando un evento de riesgo con una



CS5 El sistema no debe permitir la inyección voluntaria o el �ujo indeseado decorriente (o fugas de corriente) mayores a 0,5 mA a través de las partesaplicadas (electrodos).

CS6 El voltaje de alimentación del dispositivo no debe superar los 60 V DC.CS7 El nodo sensor debe permanecer a una distancia mayor a 10 cm de

dispositivos electrónicos que puedan ser afectados por la interferenciaelectromagnética generada por el radio transmisor IEEE 802.15.4.

Tabla 2.5: Listado de requerimientos de seguridad eléctrica del sistema de acuerdo alestándar IEC 60601.

severidad alta. En la Tabla 2.5 se resumen los requerimientos del sistema de monitoriza-

ción remota de pacientes en condición de hospitalización domiciliaria, obtenidos tras el

análisis del estándar IEC 60601 referentes a la seguridad eléctrica.

Como etapa posterior a la descripción conceptual del sistema de monitorización de pa-

cientes en condición de hospitalización domiciliaria HealTICa y a la identi�cación los

requerimientos eléctricos de acuerdo al estándar IEC 60601, el paso siguiente fue identi�-

car las amenazas y posibles medidas para contrarrestarlas de acuerdo al diseño conceptual

de la Figura 2.1. Esto incluye identi�car los puntos más vulnerables del sistema (cuellos

de botella) en términos de las propiedades de interés en esta investigación. Se usaron

dos técnicas que permiten evaluar de manera rápida las combinaciones de fallos con ma-

yor probabilidad de ocurrencia. Se desarrolló el análisis de árboles de falla (Failure Tree

Analysis, FTA) y el análisis de modo de falla y efecto (Failure Mode and Efect Analisys,

FMEA) que además permite evaluar de forma aproximada, cómo disminuye la probabi-

lidad de ocurrencia de una falla una vez se agrega al sistema una técnica de mitigación.

A continuación se de�nen los conceptos básicos para realizar los análisis, acompañados

de la descripción y resultados de cada escenario.

2.3. Árboles de fallas (FTA)

El análisis de árbol de fallas (FTA) es una técnica analítica utilizada para determinar

la probabilidad de ocurrencia de combinaciones de eventos de falla en un sistema. Para

realizar el análisis se establece un evento principal, cuya probabilidad de ocurrencia se

desconoce. A partir de este se desprenden eventos secundarios o básicos los cuales son

los causantes de los eventos intermedios y el evento principal. La estructura del árbol y

la asignación de probabilidades está argumentada en documentación técnica y aportes

de personal experto, que permiten identi�car cómo in�uyen los eventos secundarios y

sus combinaciones sobre el evento principal. Esta técnica permite obtener resultados


cualitativos y cuantitativos a través del cálculo de probabilidad de ocurrencia de cada

evento y la posterior predicción de �abilidad del sistema. Sin embargo, en este caso se

utilizó el análisis de árboles de falla para identi�car cuellos de botella de �abilidad, más

no para evaluar o predicir el comportamiento de este atributo del sistema. En la Tabla

2.6 se presenta la simbología utilizada en la elaboración de diagramas de árbol de fallas

[28].

Simbolo Descripción

Evento principal: representa el evento de falla que se desea eva-luar. Se localiza en la parte superior del diagrama. Es causado porlos eventos básicos.

Evento básico: representan la falla en un componente o elementodel sistema. Se ubica en la raíz (parte inferior) del árbol, siendointerconectado con otros eventos a través de compuertas lógicas.

Evento sin desarrollar: representa eventos donde se desconoceinformación o el impacto del evento básico sobre el evento princi-pal.

Compuerta AND: permite la interconexión de dos o más eventosbásicos, los cuales se deben desarrollar de manera simultánea paraque in�uyan sobre el evento principal.

Compuerta OR: permite la interconexión de dos o más even-tos. Si se produce al menos uno de los eventos de entrada a lacompuerta, se verá re�ejado en el evento principal.

Tabla 2.6: Simbología para la elaboración de análisis de árboles de falla (FTA)

Los árboles de fallos pueden ser analizados de forma cualitativa y cuantitativa. La pri-

mera consiste en analizar la estructura del árbol de fallas para poder determinar las

combinaciones de eventos que producen el evento principal, mediante el uso del álgebra

de Boole, traduciendo esta estructura a ecuaciones lógicas. Entre tanto, la evaluación

cuantitativa precisa conocer la probabilidad de ocurrencia de los eventos básicos y de-

terminar valores probabilísticos de fallo para los eventos no desarrollados. A partir de

lo anterior se calcula la probabilidad de fallo del evento principal en función de la tasa

de fallo que se puede obtener en hojas de datos de los componentes del sistema y de

datos experimentales [29]. También es posible incluir información de datos estimativos

asignando valores probabilísticos a su ocurrencia.


El análisis de árbol de fallas realizado al sistema de monitorización de pacientes en con-

dición de hospitalización domiciliaria HealTICa consistió en la elaboración de diagramas

de árbol de falla para eventos principales identi�cados en reuniones técnicas con los in-

genieros desarrolladores, que de acuerdo a su experiencia y a la revisión de las hojas

de datos de los dispositivos electrónicos que conforman el prototipo, permitieron de�nir

los eventos secundarios y sus respectivas probabilidades de ocurrencia. Los FTA fueron

simulados usando el software Möbius [30], el cual permite realizar el diagrama de árbol

de fallas con su respectiva simbología, asociar valores de probabilidad a los eventos bá-

sicos y no desarrollados y calcular la probabilidad de ocurrencia del evento principal. A

continuación se presentan el análisis de árboles de fallas para cada uno de los eventos

principales identi�cados en las reuniones técnicas. Cada uno de los nombres asignados a

los escenarios hace referencia al evento principal.

- Lesiones en la piel del paciente: A pesar de que el sistema de monitorización de pa-

cientes en condición de hospitalización domiciliaria no es considerado un sistema de

seguridad crítica, es posible que una falla del sistema (con muy baja probabilidad de

ocurrencia) desencadene un evento adverso donde la integridad física del paciente puede

resultar afectada. El FTA de la Figura 2.3 permite analizar la probabilidad de que la

plataforma de monitorización remota pueda provocar lesiones al paciente (evento prin-

cipal skinLesions), ya sea por sobrecalentamiento del nodo sensor, el cual se ubica en

el cuello del usuario, o por �ujo de corriente a través de los electrodos ubicados en el

pecho (ver Figura 2.1). Esto puede llegar a ser crítico al momento de usar el sistema

pues, como se explicó anteriormente, las fugas de corriente a través de partes aplicadas

conductoras deben ser limitadas para evitar, no solo lesiones en la piel sino anomalías

que puedan afectar al corazón del paciente. En el análisis FTA para este evento prin-

cipal se consideraron seis eventos básicos: falla en el hardware de aislamiento eléctrico

(elecIsolationFail); bugs o fallas en el �rmware del nodo (adsFirmwareBug), los cuales

pueden provocar errores en la con�guración del sensor de adquisición y procesamiento de

la señal ECG, que tiene la opción de inyectar �ujo de corriente para medir la frecuencia

respiratoria; corrientes de fuga (leakageCurrent); y sobrecalentamiento de la carcasa del

nodo (overheatingHousing), que ser causado por fallas en la batería (batteryFail), con-

diciones ambientales (enviorementalConditions) o una falla eléctrica (electricFail). La

probabilidad de ocurrencia de este evento es del 1,1% durante una hora de operación,

sin fallas previas detectadas. Tal y como se esperaba, la probabilidad de ocurrencia de

una lesión en la piel del paciente como consecuencia de una falla en el sistema es baja.

Sin embargo, para considerar despreciable la probabilidad de ocurrencia de este evento,

es necesario estimar la �abilidad de las baterías a utilizar en los prototipos y asegurar que


desde el �rmware del nodo se elimine la opción de inyectar corriente para la adquisición

de la frecuencia respiratoria

p=1x10-6 p=0.01 p=1x10-3

p=1x10-5 p=0.01 p=1x10-3

p=0.011

Figura 2.3: Árbol de fallas para el evento principal de lesiones en la piel

- Acceso no autorizado a la información médica: la información médica es de carácter

altamente sensible y privado, por lo cual su almacenamiento y transmisión a través de

medios abiertos como la comunicación inalámbrica es un aspecto importante a evaluar

en el proceso de diseño. A partir de las reuniones técnicas, sesiones de co-creación y

revisión bibliográ�ca [6], se identi�có como crítico el envío o almacenamiento de la infor-

mación médica y personal del paciente en texto plano. Por lo anterior, en la Figura 2.4

se presenta el análisis de árbol de fallas para el evento principal asociado a al acceso de

personal no autorizado a la información médica del paciente (unauthorizedInfoAccess).

Para el FTA se consideraron cinco eventos básicos que fueron de�nidos en reuniones téc-

nicas y a través de la revisión bibliográ�ca de las principales amenazas a la seguridad en

sistemas de monitorización remota basados en la tecnología WBAN. Entre los eventos

considerados se encuentran la suplantación de nodos (spoo�ng), interceptación de men-

sajes por el canal inalámbrico (sni�ng), esto sumado al almacenamiento de los datos en

texto plano (plainTextDataBase) y a la ausencia de medidas que permitan autenticar a

las personas que tiene acceso a la información almacenada (controlAccessAbsence). Las

probabilidades de los eventos básicos en el árbol de la Figura 2.4 fueron asignadas de

acuerdo a la complejidad de materializar una de las amenazas consideradas en el con-

texto de la atención domiciliaria de pacientes y de acuerdo a experimentos realizados

durante el desarrollo del proyecto, donde se utilizaron sni�ers para el protocolo IEEE

802.15.4. La probabilidad de que una amenaza a la seguridad se mani�este es del 12%,

una probabilidad de ocurrencia considerable, con lo cual se deben incluir en el sistema


mecanismos que permitan preservar la con�dencialidad de la información, no solo en la

transmisión de la información médica si no también en su almacenamiento.

p=0.01 p=0.01 p=0.1 p=1x10-3

p=1x10-3

p=0,12

Figura 2.4: Árbol de fallas para el evento principal de vulnerabilidad de seguridad delsistema HealTICa

- Falla en detección de evento de riesgo: en la Figura 2.5 se presenta el FTA corres-

pondiente a la falla del sistema para detectar un evento de riesgo asociado a los signos

vitales del paciente. Se observa que la ausencia de mecanismos que identi�quen la falta de

calibración o ajuste de los sensores (sensorsFail) y la corrupción malintencionada de los

datos DBCorruption) son amenazas a tener en cuenta en este escenario. Con ayuda del

equipo de desarrollo del sistema de monitorización de pacientes en condiciones de hospi-

talización domiciliaria se de�nieron nueve eventos básicos que pueden desencadenar una

falla en la detección de eventos de riesgo para la salud del paciente. Entre ellos están los

que pueden generar corrupción sobre las variables médicas como la generación intencio-

nal de variables falsas o de fuentes no autenticadas (suplantatioDataSource), corrupción

de datos por interferencia electromagnética (EMI ) y captura de nodos y modi�cación

mal intencionada (DBCorruption) o repetida (packetReplay). Como es de suponerse, las

fallas en el hardware son una importante fuente de fallas que pueden afectar la funcio-

nalidad de detección de eventos de riesgo. En el árbol se consideran fallas en los sensores

(sensorsFail) y fallas o mala conexión de los electrodos usados para la adquisición de

la señal ECG (electrodesBadConn). Finalmente se consideraron eventos de falla relacio-

nados con el software implementado, ya sea por fallas de programación (appBug), por

uso de personal no capacitado (unquali�edUser), o con�guración mal intencionada de


los umbrales de detección de riesgo (thresholdMiscon�gured). La probabilidad de que se

mani�este un falla en la detección de eventos de riesgo es del 35%. Con una proabilidad

de ocurrencia tan alta se identi�ca la exigencia de almacenar y transmitir información

con técnicas de veri�cación de integridad de los datos. En cuanto a la �abilidad del sis-

tema, se requiere que el sistema cuente con mecanismos a nivel de hardware y software

que permitan veri�car los umbrales e integridad de variables.

p=5x10-3p=0.01p=1x10-3 p=1x10-4 p=1x10-5

p=0,35

p=0.15 p=0.01 p=0.05 p=0.15

Figura 2.5: Árbol de fallas para la detección de un evento de alto riesgo asociado alos signos vitales del paciente

p=1x10-5 p=0.05

p=1x10-8 p=1x10-6

p=1x10-5 p=0.05 p=0.1 p=0.015

p=0,21

p=3x10-3

Figura 2.6: Árbol de fallas para el evento principal de falla en la comunicación delsistema HealTICa intra- y extra-WBAN

- Falla en la comunicación: en este análisis se considera como evento principal la ocu-

rrencia de un evento adverso que imposibilite la comunicación entre el nodo sink y el


nodo sensor. En las reuniones técnicas con el grupo de trabajo y en la revisión biblio-

gra�ca [15] se de�nieron tres eventos secundarios en el sistema que pueden desencadenar

una falla en la comunicación, ya sea fallas en el protocolo de comunicación por inter-

venciones mal intencionadas (DDoS, denegación del servicio) y jamming, interferencia

electromagnética mal intencionada); falla de hardware, tales como mala conexión o fallas

en las interfaces de comunicación (dongleBadConnection), fallas en el microcontrolador

(MCUFail), fallas eléctricas (PCBFail, batteryFail y lowBattery); dispositivos fuera de

rango de cobertura, debido a escenarios ruidosos en la banda de operación (noisySce-

nario); y mal uso del sistema (nodeO� ). Tras realizar el análisis se identi�caron como

puntos críticos en el funcionamiento del sistema, las averías de hardware asociadas a la

fuente de alimentación o a la plataforma embebida, elemento central de la adquisición,

procesamiento y control de periféricos I/O en el nodo, el cual se identi�ca como un cuello

de botella de �abilidad del sistema. Es necesario, además, implementar una técnica que

permita mitigar los ataques maliciosos en el protocolo de comunicación, que afecten la

con�dencialidad y disponibilidad del sistema, esto debido a la alta probabilidad (21%)

obtenida tras desarrollar este análisis.

2.4. Análisis de modos de fallas y efectos (FMEA)

El Análisis de Modos de Fallas y Efectos (Failure Modes and E�ects Analysis, FMEA) es

un método de evaluación de fallas o modos de fallas, que permite identi�car dónde y cómo

es más propenso a fallar el sistema, permitiendo también evaluar el impacto relativo de

cada falla. El FMEA consiste en asignar una cali�cación que cuanti�ca la probabilidad

de ocurrencia de la falla, la probabilidad de que la falla no sea detectada y la cantidad

de daño que el modo de falla puede causar a las personas o equipos. El producto de estos

tres valores es denominado el Risk Priority Number (RPN) de la falla. El RPN permite

comparar los efectos de las medidas propuestas para mitigar una falla y determinar qué

tan efectiva es la inclusión de estos cambios en el sistema en términos de riesgos. En la

Tabla 2.7 se presentan las escalas de probabilidad de ocurrencia, severidad y detección

de fallas. Es una escala continua entre 1 y 10, con tres puntos de referencia cualitativa

que se se utiliza para calcular el RPN mediante la ecuación 2.2 del análisis realizado

para identi�car las principales amenazas a la con�abilidad y seguridad del sistema de

monitorización remota de pacientes en condición de hospitalización domiciliaria basado

en WBAN. En las Tablas 2.8, 2.9 y 2.10 se realiza el análisis FMEA para los diferentes

componentes del sistema. Las tablas constan de celdas donde se describe la función del

componente, el modo de falla y su causa. En las celdas correspondientes a la severidad

(S), probabilidad de ocurrencia (P) y detección (D) se ponderan los valores considerados

de acuerdo a especi�caciones en hojas de datos, experiencia de personal experto y valores


determinados experimentalmente. En el análisis FMEA se deben incluir las medidas de

mitigación propuestas para cada falla identi�cada, y los nuevos de S, P y D, para efectuar

el cálculo del nuevo RPN que se logran con ellas. Sin embargo, la presentación de esta

parte se posterga hasta cuando se expliquen en detalle las medidas de mitigación en el

siguiente capítulo.

Bajo Medio Alto

Escala de Probabilidad 1 5 10Escala de Severidad 1 5 10Escala de Detección 1 5 10

Tabla 2.7: Escalas de probabilidad, severidad y detección del análisis de modos defalla y efectos, FMEA

RPN = Severidad×Ocurrencia×Deteccion (2.2)

Componente Función Modo de

Falla

Efectos Causas S P D RPN

Sensores Adquirir lasvariables mé-dicas de inte-rés

Variablesfuera derango onulas

Datos noválidos parael proce-samiento,resultadoserróneos

Falla en lossensores

8 2 8 128

Memoria Respaldo delas variablesmédicas

Lectura co-rrupta de losdatos

Datos pro-cesados nocorrespon-den a losadquiridos

Falla en lamemoria

6 2 8 96

Acondicionadorde señalECG

Adquisicióny acondicio-namiento deseñal ECG

Fuga de co-rriente

Descargaeléctricasobre elpaciente

Falla en elsistema deaislamientoeléctrico delacondicio-nador deseñal

10 2 1 20

Batería Alimentacióneléctrica delcircuitoelectrónico

Carga debatería in-su�ciente noalertada

La informa-ción médicano es trans-mitida alpersonalmédico

Deterioro dela bateríay/o fallaen el sensorde carga debatería

5 2 8 80

Tabla 2.8: Análisis de modo de falla y efecto FMEA para el sistema (parte 1)



Falla


Microcontrolador Coordinar laadquisición,procesa-miento,transmisióny recep-ción deinformación

No se ejecu-tan las ruti-nas progra-madas

Error enlas funcio-nalidadesprincipalesdel nodo

Deteriorodel dis-positivo odescargaelectrostáti-ca

7 2 1 14

TransceptorTransmitiry recibirinformaciónusando elprotoco-lo IEEE802.15.4

No es po-sible la co-municacióninalám-brica conlos demásnodos de laWBAN

La informa-ción médicarecolecta-da por elnodo no estransmitidaal personalmédico querealiza lamonitoriza-ción de lospacientes nia su círculode acompa-ñamiento.

Deteriorodel dis-positivo,descargaelectrostá-tica, IEMo ataquesmaliciosos

8 4 2 64

Nodo sink ynodo sensorfuera de ran-go de cober-tura o don-gle USB noconectado

7 3 2 42


De la revisión de las tablas de análisis FMEA es evidente que las fallas en los sensores, en

el microcontrolador, la batería y las referentes a la seguridad de la información (con�den-

cialidad, integridad y autenticidad), son las de mayor RPN y requieren ser priorizadas al

momento de proponer la introducción de medidas para contrarrestar sus efectos en una

arquitectura de con�abilidad y seguridad, tal como se explicará en el siguiente capítulo.

En la Tabla 2.11 se presentan los requerimientos del sistema obtenidos de los análisis

FTA y FMEA. Cabe recalcar que la de�nición de los requerimientos funcionales y no

funcionales del sistema fue abordada por el equipo de trabajo del macro-proyecto en

pleno, pero aquí solo se da cuenta en detalle de los referidos a la seguridad y la con�abi-

lidad. Otros requerimientos que puedan ser necesarios para la comprensión del presente



Falla


Base de datos Almacenarvariablesmédicas

No es posi-ble almace-nar los datosmédicos

Pérdida deinformaciónmédica yausencia derespaldo delos datos

Deterioro oausencia dela memoria

5 2 8 80

Acceso noautorizadoa la in-formaciónmédica

Informaciónmédica delpacienteaccedida porpersonal noautorizado

Base de da-tos almace-nada sin te-ner en cuen-ta mecanis-mos de segu-ridad

7 5 8 280



CS8 En caso de que un nodo sufra una falla tolerable, el sistema debe contarcon un modo de funcionamiento seguro y generar alertas correspondientescuando entre en él.

CS9 Tanto el nodo sink como el nodo sensor deben permitir la veri�cación deautenticidad de los mensajes recibidos, implementado técnicas de segu-ridad de la información.

CS10 El sistema debe asegurar los atributos de seguridad de la información(con�dencialidad, integridad, autenticación y disponibilidad) en redesWBAN, priorizando la óptima utilización de recursos energéticos y decómputo.

Tabla 2.11: Listado de requerimientos de con�abilidad y seguridad del sistema obte-nidos mediante los análisis FTA y FMEA.

trabajo, serán explicados de manera sucinta en su momento.

A partir de las estrategias de co-creación y las técnicas de análisis de árboles de fallas

(FTA) y análisis de modos de fallas y efectos (FMEA) fue posible obtener los requeri-

mientos referidos a la seguridad y con�abilidad del sistema de monitorización remota de

pacientes en condición de hospitalización domiciliaria, los cuales se resumen en las Ta-

blas 2.1, 2.5 y 2.11. De esta manera el primer objetivo especi�co del presente trabajo de

investigación, establecer los atributos más importantes relacionados con la con�abilidad

y seguridad de este tipo de redes en el contexto mencionado, se da por logrado y se da

paso al capítulo 3, cuyo objetivo es presentar la descripción de una propuesta de arqui-

tectura de con�abilidad y seguridad para la plataforma de monitorización de pacientes

en condición de hospitalización domiciliaria, que permita satisfacer los requerimientos

obtenidos en este capítulo.

Capítulo 3

Arquitectura de con�abilidad y

seguridad

En este capítulo, en primera instancia, se describe la implementación hardware/software

del sistema de monitorización remota de pacientes en condición de hospitalización do-

miciliaria. Consecuentemente se realiza la descripción de las medidas que se introducen

para conformar la arquitectura de con�abilidad y seguridad para el sistema diseñado, a

partir de los requerimientos obtenidos en el capítulo anterior.

3.1. Implementación hardware/software del sistema Heal-

TICa

Para el diseño del hardware del nodo sensor, se consideró la necesidad de implementar un

módulo capaz de adquirir, procesar y transmitir señales y variables biomédicas, de�nidas

por los expertos y usuarios en los ejercicios de co-creación. Particularmente, se cuenta

con un Analog Front End de alta resolución encargado de adquirir y acondicionar la se-

ñal electrocardiográ�ca (ECG) a través de electrodos conectados en la piel del torso del

paciente. El Analog Front-End permite el muestreo simultáneo de la señal ECG en múl-

tiples canales con una resolución de 24 bits, incorporando las características necesarias

para aplicaciones con este tipo de señales. Además, permite la obtención de la frecuencia

respiratoria a través de la inyección de corriente en los electrodos y midiendo las varia-

ciones de impedancia respiratoria. Sin embargo, esta opción fue descartada para evitar

cualquier inyección de corriente sobre el paciente. La frecuencia respiratoria es calculada

por los algoritmos de procesamiento de la señal ECG implementados en el nodo sink.

Los datos obtenidos son procesados por un microcontrolador de 32 bits con arquitectura

30

Capítulo 3. Arquitectura de con�abilidad y seguridad 31

ARM, optimizado para aplicaciones que requieren bajo consumo de potencia. El nodo

sensor cuenta además con un módulo de pulsioximetría, que posibilita la adquisición de

los valores referentes a la concentración de oxígeno en la sangre del paciente (SpO2),

ritmo cardíaco y, de ser necesario, la señal PPG (fotopletismográ�ca). Finalmente, se

incluyen sensores de aceleración de tres ejes y temperatura corporal de tecnología in-

frarroja, eliminando el contacto directo con el paciente. En la Figura 3.1 se presenta el

diagrama de bloques del hardware del nodo sensor.

MCU

Batería

Señal ECG

SpO2

TemperaturaCorporal

RadioTransceptor

Electrodos

I2CAcelerómetro

MemoriaUART

SPI

I2CUART

I2C

SensorÓptico

Figura 3.1: Diagrama de bloques del hardware del nodo sensor inalámbrico

Para adquirir las medidas de saturación de oxígeno y ritmo cardíaco provenientes del

pulsioxímetro se realiza la comunicación por medio de la interfaz serial UART, donde

la tasa de transmisión se establece en 9600 bps. Los valores de temperatura corporal

y aceleración se transmiten a través de la interfaz de comunicación I2C. En esta situa-

ción el microcontrolador actúa como un dispositivo maestro que controla los tiempos de

transmisión sobre el bus de comunicación. Finalmente, el módulo de adquisición y acon-

dicionamiento de la señal ECG transmite tramas de datos cada 4 milisegundos mediante

la interfaz SPI. Esté valor está asociado a la frecuencia de muestreo (250 Hz) de�nida en

las sesiones de co-creación con el personal médico, con la cual se garantiza la reconstruc-

ción de la señal ECG. Las tramas son ventanas de tiempo de la señal electrocardiografíca

del paciente.

Además del hardware se cuenta con el �rmware del microcontrolador, que ha sido progra-

mado para coordinar las tareas de comunicación y adquisición de datos con los módulos

sensores a través de las diferentes interfaces de comunicación. Es importante conocer y

comprender el funcionamiento y posibles amenazas a la con�abilidad y seguridad del

sistema asociadas al software desarrollado. En la Figura 3.2 se presenta el diagrama de

clases del �rmware diseñado e implementado. La abstracción del �rmware en el diagra-

ma UML se realizó asignando clases para cada sensor que compone el nodo. La clase


sensorController controla y adquiere la información sincronizando las peticiones a cada

una de las interfaces de comunicación que se presentaron en la Figura 3.1. La clase ECG-

Sensor es la encargada de recibir y almacenar la señal ECG cuando ésta se encuentra

disponible en el Analog Front End. Esta clase se encarga de empaquetar en un bu�er

de datos la señal ECG correspondiente a 2500 muestras, que equivale a diez veces la

frecuencia de muestreo (250Hz), tiempo recomendado en las sesiones de co-creación por

los stakeholders. Cuando se recibe una petición del nodo sink, la clase sensorsController

accede al bu�er y envía la información a través de la interfaz de comunicación inalámbri-

ca IEEE 802.15.4. La clase oximSensor adquiere la información proveniente del módulo

de oximetría, es decir, los valores de ritmo cardíaco y saturación de oxígeno en la san-

gre, realizando peticiones al pulsioxímetro, que son inmediatamente transmitidas al nodo

sink. La clases tempSensor y accelSensor están encargadas de solicitar los valor de tem-

peratura provenientes del sensor de temperatura corporal y los valores de la aceleración

en los ejes x, y y z brindados por el acelerómetro. La clase comm realiza la comunicación

por medio de la interfaz de comunicación serial (UART) con el radio transceptor, quien

implementa la comunicación inalámbrica usando el protocolo IEEE 802.15.4. Finalmente,

la clase memory implementa los métodos necesarios para almacenar y extraer informa-

ción en la memoria externa. Cabe aclarar que el diseño e implementación del �rmware

del nodo sensor hace parte de otro trabajo de investigación, desarrollado en el marco de

macroproyecto ejecutado por ARTICA [31].

sensorsData: structquerySensors()

sensorController

oximSensor

oximData: struct

setSensorData()getSensorData()

tempSensor

tempData: struct


accelSensor

accelData: struct


comm

sendData()handleIncomingData()

memory

storeData()readData()

ECGSensor


ECGData: struct

Figura 3.2: Diagrama de clases del �rmware del nodo HealTICa


3.2. Medidas de prevención de fallas a nivel de software

Como medidas para incrementar la �abilidad y protección del sistema HealTICa se pro-

pone incluir en la arquitectura de software, patrones de diseño. Los patrones han sido

reportados como una metodología de gran acogida para el diseño de arquitecturas seguras

y con�ables. Son de�nidos como soluciones genéricas propuestas a problemas recurrentes

dentro del diseño de hardware y software [32], permitiendo integrar a un sistema requi-

sitos no funcionales (entre ellos con�abilidad y seguridad). Los patrones de seguridad

y �abilidad reportados por Douglass en [33] están enfocados en sistemas de seguridad

crítica, en los cuales una falla del sistema puede representar desde lesiones a usuarios

u operarios hasta pérdidas mortales de uno o más actores involucrados en la operación

del mismo. El sistema de monitorización remoto de pacientes en condición de hospita-

lización domiciliaria, no cabe dentro de la clasi�cación de sistema de seguridad crítica,

como se explicó en el capitulo anterior. Sin embargo, como resultado de la estrategía de

co-creación se identi�có la necesidad incluir medidas que permitan incrementar la con�a-

bilidad y la seguridad de dispositivos basados en WBAN para aplicaciones en escenarios

de hospitalización domiciliaria. A continuación se describen los patrones incluidos, acom-

pañados de modelos de alto nivel que facilitan observar cómo se realizó su integración en

el �rmware del sistema.

3.2.1. Patrón CRC

Como medida para mitigar la corrupción de datos, que puede ser generada por inter-

ferencias electromagnéticas (IEM) que afecten el dispositivo de almacenamiento o por

intrusiones maliciosas al sistema, se propone la inclusión de checksums que son generados

a partir de cálculos matemáticos sobre la variable que se desea veri�car su integridad.

Mediante la inclusión del patrón CRC (Código de Redundancia Cíclica ) al �rmware del

sistema se busca atender los requerimientos CS2 y CS9 de la Tabla 2.1, los cuales de-

mandan garantizar atributos asociados a la con�abilidad y seguridad del sistema, entre

ellos la integridad, �abilidad y disponibilidad. El CRC es una técnica ampliamente usada

para aplicaciones embebidas que requieren veri�cación de errores en el almacenamiento

de datos de gran tamaño e incluso en la transmisión de datos [33]. Consiste en el cálculo

de un código binario de longitud �ja sobre el dato al cual se quiere veri�car su integri-

dad. El CRC es almacenado en memoria junto al dato o variable que se está actualizando

y se veri�ca la integridad del mismo cuando se requiere leer el dato para su posterior

procesamiento.

Matemáticamente el CRC se puede expresar como la división de una trama de datos

binarios considerado un polinomio GF (2) (Galois Field donde los coe�cientes son ceros


NombreLongitud

(bits)

Polinomio Generador

Algebraico Hexadecimal

CRC-12 12 x12 + x11 + x3 + x2 + x+ 1 0x80F

CRC-16 16 x16 + x15 + x+ 1 0x8005CRC-CCITT

16 x16 + x12 + x5 + 1 0x1021

CRC-32 32 x32 + x26 + x23 + x22 + x16 + x12+x11 + x10 + x8 + x7 + x5 + x4 + x2 + x+ 1

0x04C11DB7

Tabla 3.1: Polinomios de CRC más utilizados.

y unos), sobre un polinomio generador G(x) llamado polinomio CRC. El residuo de

la división es el valor utilizado para la detección de errores en los datos. Este valor,

usualmente llamado FCS (Frame Check Sequence), es almacenado o enviado junto a los

datos. La veri�cación de la integridad se realiza comparando el FCS calculado al leer

o recibir un dato con el FCS originalmente calculado. Si los valores no coinciden se

considera que existe corrupción de datos. Existen diferentes polinomios generadores que

permiten disminuir la probabilidad en la falla de detección de errores dada por (1/2n)

donde n corresponde al número de bits del FCS. Para polinomios de 16 bits se considera

una probabilidad de fallas en la detección de errores de 1,5 × 10−5 mientras que para

polinomios de 32 bits esta probabilidad disminuye a un valor de 2,3×10−10. En la Tabla

3.1 se presentan los polinomios generadores más utilizados de acuerdo a la literatura, en

su representación algebraica y en sistema hexadecimal [34]. Es importante resaltar que

a mayor número de bits mayor es el consumo de recursos de cómputo que requiere el

cálculo del FCS.

CRCProtectedData

CRC:unsigned intdataSet:DataType dataSet[MAX_DATA_ELEMENTS]

updateData():voidgetData()voidsetData(data:char*, crcValue:int)voiderrorHandler():void

DataType

<<Function>>

computeCRC(data:char*. size:unsigned int, seed:int, final:int):void

DataClient<<Usage>>

1

Figura 3.3: Diagrama de clases del patrón CRC

En [33] se presenta el cálculo de CRC como patrón de seguridad y �abilidad que puede

ser implementado en una plataforma embebida. La Figura 3.3 muestra el diagrama de

clases del patrón CRC, en donde resalta la función computeCRC(), la cual está encargada


de realizar todo el cálculo matemático de los datos a nivel de bits, usando un algoritmo

basado en tablas con los valores del CRC prede�nidos, lo que permite un menor consumo

de recursos de cómputo. Al leer (actualizar) un dato de la clase DataClient, la clase CRC-

ProtectedData hace uso de del método updateData(), el cual calcula el CRC y lo almacena

junto al dato. Cuando se requiere leer un dato, el método getData() calcula nuevamente

el CRC y lo compara con el valor almacenado, permitiendo identi�car corrupción en los

datos almacenados y tomando acciones usando el método errorHandler().

En la Figura 3.4 se presenta el diagrama UML del �rmware del nodo sensor incluyendo el

patrón CRC (crcCalculator). La clase CRCProtectedData contiene los métodos de veri�-

cación y cálculo del CRC de variables médicas adquiridas por la clase sensorController,

además de los métodos getData y setData, que permiten almacenar y leer un variable,

incluyendo un código de veri�cación de integridad. El método calculateCRC, encargado

de calcular el valor del FCS usando el módulo de hardware del microcontrolador, recibe

como parámetros de entrada la semilla correspondiente al polinomio generador (0xFFFF

correspondiente al CRC-CCITT), y el dato, con su longitud, al cual se le calculará el

CRC.

3.2.2. Patrón SmartData

La inclusión del patrón SmartData va encaminada a identi�car inconsistencias en los

valores de cada una de las variables procesadas por el microcontrolador del nodo sen-

sor, es decir, busca satisfacer los requerimientos CS1 y CS9 de las Tablas 2.1 y 2.5

respectivamente, relacionados con la �abilidad, integridad y disponibilidad del sistema

HealTICa. Este patrón de diseño permite codi�car software seguro a través de la creación

de clases que veri�can errores en tiempo de ejecución sobre los rangos de funcionamiento,

índices y tipos de variables, a partir de umbrales establecidos de funcionamiento normal

en la inicialización del sistema. Al implementar este patrón se facilita la identi�cación de

fallas de hardware, las cuales se ven re�ejadas en valores anómalos en la adquisición y el

procesamiento de los datos. El uso de este patrón evita que estos valores fuera de rango

sean usados como parámetros de entrada de otras funciones o métodos ocasionando un

mal funcionamiento del sistema o que puedan dar origen a falsos estados de alerta. En

otras palabras, se previene la propagación de fallos en el sistema. En la Figura 3.5 se

muestra el diagrama de clases reportado en [33], correspondiente al patron SmartData.

La clase smartDataType implementa diferentes métodos que son llamados por la clase

serverClass, de los cuales se destacan los métodos setHighBoundary() y setLowBoun-

dary(), que permiten modi�car los umbrales de funcionamiento normal para cada una

de las variables de interés; los métodos getHighBoundary() y getLowBoundary() que per-

miten obtener los valores actuales de los umbrales inferior y superior en los cuales no se



sensorController

oximSensor

oximData: struct


tempSensor

tempData: struct


accelSensor

accelData: struct


comm


memory


ECGSensor


ECGData: struct

varPatientInit()calculateCRC()checkDatos()setVariable()getVariable()generateError

crcCalculator

Figura 3.4: Diagrama de clases del �rmware del nodo sensor incluyendo el patrónCRC.

detecta un mal funcionamiento en el sistema; y el método checkValidity() que realiza una

veri�cación de todas las variables, antes de ser pasadas como parámetros a otros métodos

que requieren de estos valores para realizar cálculos o procedimientos especializados. Si

el valor del dato sujeto a validación no se encuentra dentro de los umbrales normales

de funcionamiento, se hace uso de la clase ErrorManager, encargada de tomar acciones

en el sistema, como alertar, reiniciar el sistema o activar mecanismos de redundancia de

hardware como medidas de prevención o corrección de fallas.

La clase SmartData, la cual se muestra integrada al �rmware del nodo sensor en la Figura

3.6, implementa las principales funcionalidades del patrón del mismo nombre. En ella se

tiene acceso al objeto sensorsData, se realiza su veri�cación de acuerdo a los umbrales de

cada variable, las cuales se almacenan en la estructura de datos. El método init recibe

como parámetros el valor de la variable y los umbrales, los cuales son almacenados para

evaluar la validez de los rangos de funcionamiento. Este método se utiliza como cons-

tructor de la variable y para asignar espacio en memoria correspondiente a la estructura


<<Usage>><<Usage>>

<<Usage>>

handleErrorCode(ErrorCodeType):void

ErrorCodeType

ServeClass

set:SmartDataType

setValue(SmartDataType):ErrorCodeTypegetValue():SmartDataType

:NO_ERRORS:BELOW_RANGE:ABOVE_RANGE:INCONSISTENT_VALUE:ILLEGAL_USE_OF_NULL_PTR:INDEX_OUT_OF_RANGE

<<Type>>

value:PrimitiveTypelowRange:PrimitiveTypehighRange:PrimitiveTypeerrorCode:ErrorCodeType=NO_ERRORS

SmartDataType

init(val:PrimitiveType, low:PrimitiveType, high:PrimitiveType, errMsgPtr:ErrorManagercheckValidity():ErrorCodeTypesetValue(v SmartDataType):ErrorCodeTypegetPrimitive():PrimitiveTypegetValue():SmartDataTypeerrorHandler(err:ErrorCodeType):voidsetLowBoundary(low PrimitiveType):voidsetHighBoundary(high PrimitiveType):voidgetLowBoundary():PrimitiveTypegetHighBoundary():PrimitiveTypegetErrorCode():ErrorCodeType

ErrorManagerq

Figura 3.5: Diagrama de clases del patrón SmartData


sensorController

oximSensor

oximData: struct


tempSensor

tempData: struct


accelSensor

accelData: struct


comm


memory


ECGSensor


ECGData: struct

init()checkVality()getUmbralLow()getUmbralHigh()setUmbralLow()setUmbralHigh()generateError()

smartData


crcCalculatorvaluelowRangehighRange

Figura 3.6: Diagrama de clases del �rmware del nodo sensor incluyendo el patrónSmartData.

de datos médicos. El método checkValidity está a cargo de veri�car si los valores de la

variable se encuentran dentro de los umbrales o si el tipo de variable corresponde al


de�nido en el método de inicialización de la variable a veri�car. La clase retorna el tipo

de error identi�cado.

3.3. Medidas de tolerancia y prevención de fallas a nivel de

hardware

Dentro de los patrones de diseño enfocados en mejorar las propiedades de seguridad y

con�abilidad, son de gran acogida los patrones de redundancia de hardware [35]. De

acuerdo a los niveles de severidad en las fallas de la aplicación, existen diferentes alter-

nativas para tolerar fallos, permitiendo al sistema tomar acciones en caso de detectarse

una avería. De acuerdo a los requerimientos identi�cados en el capítulo 2, el sistema de

monitorización de pacientes en condición de hospitalización domiciliaria requiere incluir

mecanismos que toleren fallos leves en el sistema y den continuidad a la prestación del

servicio. En esta sección se describe el patrón de redundancia liviana denominado Sanity

Check, incluido dentro de la arquitectura de con�abilidad y seguridad del sistema para

satisfacer los requerimientos relacionados con la integridad, disponibilidad, �abilidad y

tolerancia a fallos no severos en la funcionalidad del sistema, tal como se de�nieron en

las Tablas 2.1 y 2.11, correspondientes a los identi�cados como CS1, CS2 y CS9.

3.3.1. Patrón Sanity Check - Redundancia liviana

El patrón Sanity Check es considerado un patrón liviano usado para asegurar el funcio-

namiento correcto de un módulo o canal a través de un canal de redundancia ligera; se

recomienda el uso de este patrón en situaciones donde los requerimientos de disponibili-

dad del sistema son bajos, se cuenta con un estado de falla segura o cuando el control �no

del sistema no afecta la seguridad del mismo. La estructura del patrón Sanity Check [36]

presentado en la Figura 3.7, consiste de dos canales o módulos diferentes: un canal de

actuación o canal principal, el cual realiza las acciones de procesamiento, adquisición y

control, y el canal de veri�cación o Sanity Check, encargado de monitorizar el canal prin-

cipal, con el �n de asegurar que sus salidas sean aproximadamente correctas de acuerdo

a un rango de valores de funcionamiento correcto previamente con�gurados. Una carac-

terística muy importante del canal de veri�cación es que se busca incluir dispositivos de

menor costo, consumo y precisión para identi�car las fallas.

Es importante mencionar la conexión física del Analog Front End al microcontrolador,

pues será de utilidad al momento de explicar los mecanismos de redundancia liviana que

hacen parte de la arquitectura de con�abilidad y seguridad. Tal como se presenta en la


Figura 3.7: Estructura del Patrón Sanity Check

Figura 3.1, el módulo ECG es conectado al microcontrolador a través del protocolo de

comunicación serial SPI (Serial Peripheral Interface), para realizar las funciones de ini-

cio y �nalización de los procesos de adquisición de datos. Además, el módulo cuenta con

un pin que indica mediante cambios lógicos, la disponibilidad de muestras de las señal

ECG listas para transmitir. Esto es noti�cado a través de interrupciones al microcontro-

lador. Como se mencionó, el patrón Sanity Check tiene como propósito incluir un canal

redundante para veri�cación de la funcionalidad del canal. En este caso, se incluyó un

microcontrolador para realizar el chequeo de las de la funcionalidad de los sensores cuan-

do éstos están realizando procesos de comunicación con el microcontrolador principal, tal

como se observa en la Figura 3.8. El hardware adicional tiene características inferiores en

cuanto a capacidad de procesamiento, costo y consumo energético. Se propuso un micro-

controlador de 8 bits con interfaces de comunicación seriales y pines de propósito general

con�gurables para manejar interrupciones externas. Para validar el comportamiento del

sensor de pulsioximetría se interceptó la línea transmisión de la comunicación serial. Para

examinar los valores del sensor de temperatura y el acelerómetro se utilizó el periférico

de comunicación serial del microcontrolador redundante conectándolo al bus de datos y

a la señal de reloj de la interfaz de comunicación. Con esta conexión es posible capturar

los valores de temperatura y aceleración y transmitir los resultados de la veri�cación des-

de el microcontrolador redundante al microcontrolador principal, permitiendo noti�car

errores de lectura o variables fuera de rango de funcionamiento normal.

Finalmente, para la veri�cación de funcionamiento del módulo de adquisición y acon-

dicionamiento de la señal ECG se interceptó la interfaz de petición de interrupción. El

tiempo entre interrupciones debe ser menor a 4 mS, de acuerdo a la frecuencia de mues-

treo establecida en 250 Hz, de�nida en las sesiones de co-creación con la cual se asegura


MCU

Batería

Señal ECG

SpO2

TemperaturaCorporal

RadioTransceptor

I2CAcelerómetro

UART

SPI

I2C

UART

SanityCheck

Figura 3.8: Diagrama de bloques de conexiones entre el nodo sensor y el canal deredundancia liviana Sanity Check

la reconstrucción óptima de las señal ECG. De no detectarse señales de interrupción

generadas por el módulo ECG durante un tiempo de 20 mS, se genera un mensaje de

error de comunicación desde el microcontrolador redundante hacia el microcontrolador

principal.

Cuando el microcontrolador principal recibe mensajes de error, la medida de corrección

de fallas es reiniciar la interfaz y ejecutar nuevamente las funciones de inicialización del

sensor que se identi�có con mal funcionamiento. Este procedimiento se repite un par de

veces. En caso de continuar el mal funcionamiento, el módulo o sensor es aislado, per-

mitiendo continuar con la adquisición de las demás variables �siologicas, cuyos módulos

presentan un correcto funcionamiento. Al aislar cualquier módulo del nodo se noti�ca al

usuario por medio de la aplicación en el smartphone la falla y se pregunta si se desea

continuar con la sesión de medida. Si los problemas se presentan en el ECG, el sistema

pasa de modo normal a modo seguro, en el cual se detiene la medida hasta contar con

la intervención de personal técnico cali�cado.

3.3.2. Firmware del canal redundante

El patrón Sanity Check se implementó en una plataforma embebida de 8-bits del fabrican-

te Atmel (Atmega328p) que brinda una gran cantidad de librerías para la con�guración


de periféricos, con�guración del reloj (8MHz), herramientas para realizar retardos de

tiempo, entre otras. El temporizador interno del microcontrolador es con�gurado para

ser cotejado con los tiempos de interrupción del módulo ECG para noti�car que tiene

una trama de la señal ECG lista para ser transmitida. La secuencia de funciones del

�rmware implementado para realizar veri�caciones de funcionamiento correcto sobre las

variables obtenidas por los sensores del nodo, se describe a continuación.

1 Al iniciar, el sistema realiza la inicialización de los periféricos y crea la estructura

SmartData para las variables de temperatura, SpO2, aceleración y ritmo cardíaco.

2 Las diferentes rutinas de atención a las interrupciones permiten manejar los eventos

desencadenados por los periféricos y retornar a la rutina principal.

3 La interrupción de la interfaz serial UART permite obtener los datos del sensor de

pulsioximetría.

4 Un contador aumenta cada 1 ms de acuerdo a la con�guración interna de los

temporizadores, y si su valor superar el valor de la variable AFEMsLimit = 5 ms, se

indica un estado de error en el módulo ECG. La variable AFEMsLimit es reiniciada

cada que hay una interrupción generada por la disponibilidad de muestras de la

señal ECG, cada 4 ms.

5 Otro temporizador interno del microcontrolador redundante es con�gurado para

ejecutar las rutinas de adquisición de variables al alcanzar los 2 segundos. Las

rutinas de adquisición son las siguientes:

a) Solicitud del valor de temperatura, SpO2, ritmo cardíaco y aceleración de

manera sincronizada para no interferir con las demás tareas del microcon-

trolador principal. Las variables obtenidas en este proceso son almacenadas

inmediatamente.

b) Evaluación mediante la estructuras SmartData de los valores de la tempe-

ratura, SpO2, ritmo cardíaco y aceleración. Una vez evaluados se genera un

reporte que indica el estado de cada uno de los componentes del sistema al

microcontrolador principal. De acuerdo al resultado de la evaluación, el mi-

crocontrolador principal puede aislar un determinado componente o entrar en

modo seguro en donde no se permite ni la adquisición, ni el procesamiento de

variables médicas. Esté modo está concebido para indicar al usuario la necesi-

dad de intervención técnica especializada, ya que está asociado a la necesidad

de un mantenimiento correctivo del sistema.


Finalmente, se presenta en la Figura 3.9 el diagrama de clases del �rmware del nodo

sensor, incluyendo los patrones SmartData, Sanity Check y CRC, medidas que fueron

implementadas para mitigar las amenazas sobre la con�abilidad y la seguridad.


sensorController

oximSensor

oximData: struct


tempSensor

tempData: struct


accelSensor

accelData: struct


comm


memory


ECGSensor


ECGData: struct

init();checkVality()getUmbralLow()getUmbralHigh()setUmbralLow()setUmbralHigh()generateError()

smartData


crcCalculatorvaluelowRangehighRange

Patient DatagetTemp()getSpO2()checkADSIRQ()getAcceleration()checkSensorStatus()generateError()

sanityCheck

Figura 3.9: Diagrama de clases de la arquitectura de con�abilidad y seguridad inclu-yendo el patrón de redundancia liviana Sanity Check.

Los patrones mencionados anteriormente dan cuenta de requerimientos relacionados con

atributos de �abilidad, disponibilidad y protección. Sin embargo, hasta el momento los

atributos de con�dencialidad y autenticación no han sido abordados, y tal como se iden-

ti�có en el análisis de árboles de fallas, la probabilidad de materializar amenazas a estos

atributos presentan una alta probabilidad de ocurrencia es alta. Por tal motivo, en la

sección posterior se describen los mecanismos propuestos en la arquitectura de con�a-

bilidad y seguridad encaminados a mejorar la seguridad del sistema de monitorización

remota de pacientes en condición de hospitalización domiciliaria.


3.4. Implementación de mecanismos de seguridad en la co-

municación inalámbrica

Como se explicó en el capítulo anterior se seleccionó el protocolo IEEE 802.15.4 como

tecnología para la comunicación inalámbrica en la WBAN del sistema HealTICa. En la

literatura especializada se encontraron las ventajas y retos de implementar una WBAN

con este protocolo [37], [8], [38], entre los cuales se destacan los mecanismos para proveer

seguridad de la información transmitida por el medio inalámbrico, a través de técnicas

de cifrado. Teniendo en cuenta que la transmisión de los datos se realiza por un canal

no seguro (inalámbrico), es necesario incluir mecanismos que permitan proteger la con-

�dencialidad, integridad y disponibilidad de los datos. En el protocolo IEEE 802.15.4,

la capa MAC es la responsable de indicar los diferentes servicios de seguridad para los

paquetes que llegan y salen desde y hacia las capas superiores. El estándar soporta los

siguientes servicios de seguridad:

1. Con�dencialidad: Este servicio usa claves simétricas para proteger la información

de partes que no posean las claves criptográ�cas. Los datos pueden ser cifrados

usando una clave compartida por un grupo de dispositivos. En este estándar el

cifrado puede proveerse a payloads beacon, payloads command, y payload data.

2. Autenticación: Este servicio asegura mediante un código MIC (Message Integrity

Code) que la información transmitida por una fuente no haya sido modi�cada en

el transcurso de la comunicación.

3. Protección de replay : Este servicio asegura que la información no sea duplicada.

Esto lo hace mediante el secuenciamiento ordenado de los frames.

Los servicios de seguridad son materializados a través del algoritmo de cifrado simétrico

AES (Advanced Encryption Standard). La integridad y autenticación de la información

se garantiza a través de la inclusión en la trama de un código MIC que permite la veri�-

cación de estos dos atributos de seguridad [39]. En la Tabla 3.2 se presentan los niveles

de seguridad que pueden ser con�gurados, permitiendo ajustar diferentes opciones de se-

guridad en una aplicación, desde no usar ningún mecanismo de seguridad (por defecto en

el estándar), solo con�dencialidad, solo integridad, o con�dencialidad e integridad [40].

En la arquitectura propuesta se seleccionó el modo donde se garantiza la protección a

la con�dencialidad y autenticación de los datos conocido como modo CCM (Counter

with CBC-MAC), que combina los modos CTR (Counter mode), que hace referencia a

solo cifrado, y CBC (Cipher Block Chaining), el cual ofrece solo autenticación [41]. De

esta manera se satisfacen los requerimientos CS3, CS6 y CS11, listados en la Tablas


Nivel de

SeguridadModo Con�dencialidad Autenticidad

0 Ninguno NO NO (M=0)1 MIC-32 NO SI (M=4)2 MIC-64 NO SI (M=8)3 MIC-128 NO SI (M=16)4 ENC SI NO (M=0)5 AES-MIC-32 SI SI (M=4)6 AES-MIC-64 SI SI (M=8)7 AES-MIC-128 SI SI (M=16)

Tabla 3.2: Modos de seguridad disponibles en el estándar IEEE 802.15.4

2.1, 2.5 y 2.11, respectivamente. En el modo CCM se transmite la cabecera en texto

plano junto al payload cifrado. La integridad de la cabecera y payload está protegida al

adherir el MIC a la trama. Además, en este modo se protege el código de autenticación

del mensaje al ser necesario que los receptores conozcan la clave de cifrado del MIC. El

algoritmo CCM* usado en el protocolo IEEE 802.15.4 se diferencia del AES-CCM usado

en otras aplicaciones por brindar la posibilidad de elegir solo cifrado o solo autenticación.

El sistema HealTICa se implementó sobre radio transceptores de la marca Atmel, que

ofrecen un framework robusto que facilitó el desarrollo de la aplicación. En la Figura

3.10 se presenta el diagrama UML que incluye los métodos utilizados para el cifrado y

descifrado AES-CCM de la información transmitida por el canal inalámbrico (cipherData

y decipherData), además del método para veri�cación de integridad (checkIntegrity) ba-

sado en el MIC. La autenticación (checkAutentication) está relacionado con las llaves

de cifrado y el conocimiento de la con�guración de tiempo de acceso al medio, que en

nuestro caso se ha con�gurado utilizando beacons y el algoritmo CSMA/CA, el cual será

descrito en el capítulo 4, cuando será necesario para construir el modelo de con�abilidad

del sistema..

Una vez presentado el conjunto de medidas de mitigación que componen la propuesta de

arquitectura de con�abilidad y seguridad, se retoma el análisis de modos de falla y efectos

(FMEA) que se inició en la sección 2.4 y se postergó hasta este punto para ofrecer claridad

al momento de recalcular los valores del RPN, asociados a los nuevos valores de severidad

(S), probabilidad (P) y detección (D) para las medidas descritas en esté capítulo. Las

Tablas 3.3, 3.4 y 3.5 contienen el análisis FMEA que incluye una evaluación aproximada

de las mejoras resultantes de la implementación de la arquitectura descrita. Los valores

asignados a los parámetros S, P y D después de implementar las medidas para elevar

la seguridad y con�abilidad del sistema fueron obtenidas en conjunto con el equipo de

trabajo del macro-proyecto.



sensorController

oximSensor

oximData: struct


tempSensor

tempData: struct


accelSensor

accelData: struct


comm


memory


ECGSensor


ECGData: struct

init()checkVality()getUmbralLow()getUmbralHigh()setUmbralLow()setUmbralHigh()generateError

smartData


crcCalculator

valuelowRangehighRange

Patient DatagetTemp()getSpO2()checkADSIRQ()getAcceleration()checkSensorStatus()generateError()

sanityCheck

Patient DatacipherData()decipherData()checkAutentication()checkIntegrity

securityComm

Figura 3.10: Diagrama de clases de la arquitectura de con�abilidad y seguridad im-plementada en el sistema de monitorización remota HealTICa.


Componente

Función

MododeFalla

Efectos

Causas

SP

DRPN

Mitigación

SP

DRPN

Sensores

Adquirir

las

variablesmé-

dicasde

inte-

rés

Variables

fuera

derango

onulas

Datos

noválidos

para

elproce-

samiento,

resultados

erróneos

Falla

enlos

sensores

82

8128

Implem

entación

depatrón

de�abilidad

SmartData

ySanityC

heck

82

232

Mem

oria

Respaldo

delas

variables

médicas

Lectura

co-

rrupta

delos

datos

Datos

pro-

cesados

nocorrespon-

den

alos

adquiridos

Falla

enla

mem

oria

62

896

Implem

entación

depatrón

de�abilidad

CRC

62

224

Acondicionador

deseñalECG

Adquisición

yacondicio-

namiento

deseñalECG

Fuga

deco-

rriente

Descarga

eléctrica

sobre

elpaciente

Falla

enel

sistem

ade

aislam

iento

eléctrico

del

acondiciona-

dorde

señal

ECG

102

120

Pruebas

eléctri-

cas

previas

alusoen

pacien-

tesde

acuerdo

alestándar

60601-1

y�rm

ware

con

restricciónpara

inyección

decorriente.

101

220

Batería

Alim

entación

eléctrica

del

circuito

electrónico

Carga

debatería

in-

su�cienteno

alertada

La

inform

a-ción

médica

noes

trans-

mitida

alpersonal

médico

Deterioro

dela

batería

y/o

falla

enel

sensor

decarga

debatería

52

880

Implem

entación

depatrón

de�abilidad

SmartData

ySanityC

heck

52

220

Tabla3.3:Análisisde

mod

ode

falla

yefecto

FMEA

para

laarqu

itectura

decon�

abilidadyseguridad(parte

1)


Componente

Función

MododeFalla

Efectos

Causas

SP

DRPN

Mitigación

SP

DRPN

Microcontrolador

Coordinar

laadquisición,

procesa-

miento,

transm

isión

yrecepción

deinform

a-ción

Nose

ejecu-

tan

las

ru-

tinasprogra-

madas

Error

enlas

funcio-

nalidades

principales

delnodo

Deterioro

del

dispositivo

odescarga

electrostáti-

ca

72

114

Selección

dedispositivos

dealta

�abilidad

81

19

Radio

IEEE

802.15.4

Transmitir

yrecibir

inform

ación

usando

elprotoco-

loIEEE

802.15.4

Noes

posible

lacomunica-

ción

inalám

-bricaconlos

demás

nodos

delaWBAN

La

inform

a-ción

médica

recolecta-

dapor

elnodo

noes

transm

itida

alpersonal

médico

que

realiza

lamonitoriza-

ción

delos

pacientes

nia

sucírculo

deacom

pa-

ñamiento.

Deterioro

del

dispositivo,

descarga

electrostá-

tica,

IEM

oataques

maliciosos

84

264

Activación

demecanismos

deseguridad

para

protección

decon�denciali-

dad,

integridad

yautentica-

ción.

82

118

Nodosinky

nodo

sensor

fuerade

ran-

gode

cober-

tura

odongle

USB

noco-

nectado

73

242

Noti�cación

visual

y/o

audible

fuera

derango

decobertura

yveri�cación

desconexióndel

dongle.

72

228


mod

ode

falla

yefecto

FMEA

para

laarqu

itectura

decon�


2)


Componente

Función

MododeFalla

Efectos

Causas

SP

DRPN

Mitigación

SP

DRPN

Basede

datos

Almacenar

variables

médicas

Noes

posible

almacenar

los

datos

médicos

Perdida

deinform

ación

médica

yausencia

derespaldo

delosdatos

Deterioro

oausencia

delamem

oria

52

880

Modo

seguro

delsistem

a5

21

10

Lectura

co-

rrupta

delos

datos

Datos

médi-

cosalterados

Falla

enla

mem

oria

omodi�cación

maliciosa

73

242

Implem

entación

depatrón

de�abilidad

CRC

72

228

Acceso

noautorizado

ala

in-

form

ación

médica

Inform

ación

médica

del

paciente

accedida

por

personal

noautorizado

Base

dedatos

al-

macenada

sin

tener

encuenta

mecanismos

deseguridad

75

8280

Implem

entar

mecanismos

decifrado

para

basesde

datos

yautenticación

deusuario

72

114


mod

ode

falla

yefecto

FMEA

para

laarqu

itectura

decon�


3)


En este capítulo fueron presentados, a través de modelos de alto nivel, los mecanismos

que conforman la arquitectura de con�abilidad y seguridad propuesta para el sistema

de monitorización de pacientes en condición de hospitalización domiciliaria. Cada una

de las medidas descritas en este capítulo han sido encausadas a cumplir con los requeri-

mientos identi�cados a partir de las técnicas mencionadas en el capítulo 2. Del análisis

de modos de falla y efectos (FMEA) presentados en las Tablas 3.3, 3.4 y 3.5 es evidente

el decremento de los valores de RPN al aplicar medidas de mitigación a los modos de

fallas de los diferentes componentes. Sin embargo, hasta el momento la efectividad de su

implementación en términos de las propiedades de con�abilidad y seguridad no ha sido

probada a través de una técnica formal. En el siguiente capítulo se aborda la evaluación

de la arquitectura de con�abilidad y seguridad a través de técnicas formales de modelado

y simulación, a �n de poder concluir si las técnicas propuestas en este capítulo permiten

satisfacer los requerimientos del sistema. El capítulo que aquí concluye da cuenta del

logro del segundo objetivo especi�co del presente trabajo, que hace referencia a propo-

ner una arquitectura y mecanismos a nivel de hardware y software para satisfacer los

atributos de con�dencialidad y seguridad en redes WBAN.

Capítulo 4

Evaluación de con�abilidad y

seguridad

Con el objetivo de evaluar la efectividad de la arquitectura de con�abilidad y seguridad

para el sistema propuesta en el capítulo anterior, se utilizó el formalismo de redes de

actividad estocástica (Stochastic Activity Networks, SAN) que facilita la evaluación de

propiedades fundamentales de sistemas dinámicos, tales como rendimiento, con�abilidad

y seguridad. Las ventajas que ofrece esta técnica son ampliamente reconocidas, ya que

través de modelos atómicos permite crear una representación de alto nivel del sistema a

evaluar. Las caracteristicas estocásticas inherentes en este formalismo facilitan la creación

de modelos con comportamiento dinámico muy similares al sistema, y de esta manera

evaluar de forma acertada atributos asociados a la con�abilidad y seguridad [42], [43].

En este capítulo se presentan los modelos y resultados de la evaluación de con�abilidad

y seguridad del nodo inalámbrico para monitoreo remoto de pacientes en condición de

hospitalización domiciliaria HealTICa, usando modelos atómicos SAN. Para efectos de

comparación y análisis de resultados, inicialmente se crea un modelo del sistema que

hace las veces de referencia en el que no se incluyen las técnicas de prevención y tole-

rancia a fallas. Luego, se construye un segundo modelo del sistema que corresponde a

la arquitectura de seguridad y con�abilidad presentada en el capítulo anterior. Ambos

modelos son simulados para extraer las conclusiones de los resultados arrojados. Las pro-

piedades de con�abilidad y seguridad se analizan por separado, bajo diferentes escenarios

de operación del sistema que permitan obtener conclusiones sobre las cualidades de la

arquitectura de con�abilidad y seguridad.

50

Capítulo 4. Evaluación de con�abilidad y seguridad 51

4.1. Modelos atómicos SAN

Las redes de actividad estocástica SAN son un formalismo de modelado ampliamente

utilizado para la evaluación del rendimiento y los atributos asociados a las propiedades

de seguridad y con�abilidad de sistemas de computación y redes de comunicaciones [43].

Las SAN son una extensión estocástica de las redes de Petri, en las cuales se incluye

la posibilidad de de�nir características temporales con parámetros estadísticos [42], lo

cual contribuye a incrementar el nivel de descripción del comportamiento de un sistema.

Algunas de las características adicionales de las SAN con respecto a las redes de Petri

son:

1. Permiten especi�car la evolución del sistema en el tiempo a través de predicados

asociados a las transiciones entre los estados del sistema, es decir, la habilitación

de las actividades depende del cumplimento de condiciones preestablecidas.

2. Posibilitan la especi�cación de reglas de terminación de actividades.

3. Disponen de elementos primitivos para la representación de eventos instantáneos,

cuya duración no impacta la �abilidad del sistema.

4. Los retardos asociados a las actividades temporizadas son de�nidos mediante fun-

ciones de distribución de probabilidad.

5. Una vez �naliza una actividad es posible realizar transiciones probabilísticas en-

tre los estados del sistema, a partir de la inclusión de casos condicionales en las

actividades.

Con el objetivo de ser efectivo y ampliamente aplicable, un esquema de modelamiento

debe tener bases formales que describan su comportamiento sin ningún tipo de ambigüe-

dad. El esquema debe ser su�cientemente general para permitir la fácil representación

de un sistema real, y su�cientemente formal de manera que permita obtener resultados

útiles al momento del modelar [42]. Para lograr lo mencionado las SAN cuentan con

cuatro tipos de elementos primitivos que proporcionan las herramientas necesarias para

especi�car modelos atómicos de alto nivel. En la Tabla 4.1 se muestra la representa-

ción grá�ca y de�nición de los elementos primitivos con los que se construye un modelo

atómico SAN.

4.1.1. Dinámica de las redes de actividad estocástica SAN

Se considera importante describir, de manera sucinta, la dinámica de la ejecución de una

red de actividad estocástica. La dinámica de las SAN está determinada por un conjunto


Primitiva Descripción

Lugares (Places): representan estados del sistema modelado. Cadalugar contiene un cierto número de tokens o marcas que representan elmarcado del lugar. El número de tokens en un lugar se de�ne de formaarbitraria, es decir, que se puede asociar a un número de componentesde hardware, intentos de realizar una actividad, entre otros.

Compuerta de entrada (input gate): su función es controlar la ha-bilitación de las actividades y de�nir los cambios en la marcación de loslugares de entrada una vez la actividad se ha habilitado. Como paráme-tros de de�nición las compuertas de entrada cuentan con un predicadohabilitador y una función de entrada. El primero permite de�nir unafunción booleana, que generalmente que depende de la marcación de loslugares de entrada o lugares generales del sistema, y de acuerdo a suresultado se da paso a habilitar o no la actividad asociada. La función deentrada de�ne los cambios en el marcado de la red cuando la actividadse ha habilitado.

Compuerta de salida (output gate): este elemento permite de�nircambios en la marcación en los lugares de la red una vez �naliza laactividad de la cual dependen. Las compuertas de salida cambian lamarcación de la SAN de acuerdo a lo de�nido en su función de salida.Esto es similar a la función de entrada en las compuertas de entrada conla diferencia que las compuertas de salida están asociadas a un únicocaso.

Actividad: representan acciones propias del sistema, es decir, transicio-nes de estados. Cada actividad tiene asociada una duración que puedeimpactar el comportamiento del sistema en términos de �abilidad o dis-ponibilidad. El tiempo de cada actividad temporizada (barra gruesa) esde�nido por un función de distribución de probabilidad, que se inicia unavez se cumplen las condiciones de habilitación de la actividad. General-mente es una variable continua aleatoriamente distribuida. Si la barra esdelgada la actividad es instantánea.

Casos: con este elemento el modelo atómico cuenta con diversas opcionespara la transición de lugares una vez �naliza una actividad, teniendoen cuenta una distribución de probabilidad asignada a cada caso, quepuede depender de la marcación de la red. En modelos donde se observenactividades sin casos asociados, se concluye que solo hay una opción detransición con probabilidad igual a uno.

Tabla 4.1: Primitivas grá�cas para la construcción de modelos atómicos para redesde actividad estocástica (SAN)

de tokens ubicados en los diferentes lugares, la �nalización de actividades y la selección

de casos. Para comprender mejor la ejecución de un modelo atómico SAN se presenta en

la Figura 4.1 un diagrama de �ujo que describe de manera informal como se comporta

en el tiempo una SAN.

La habilitación y �nalización de las actividades que permiten modelar la transición de


Inicio

Lugares conectados¿tokens>0?

¿Se cumplenpredicados habilitadores?

Elección y habilitación de una actividad

¿Periodo de espera finalizado?

Elección de caso para realizar la transición de estado del sistema

Lugares conectados directamente a la entrada de la actividad decrementansu marcación Mark()=--

Lugares conectados directamente a la salida de la actividad incrementan su marcación Mark()=++

La selección del caso se realiza de acuerdo a las probabilidades asignadas y su dependencia con la marcación existente

Actividades inhabilitadas

La elección de la actividad se basa en: - Las funciones de distribución de tiempo- Actividades instantáneas tienen prioridad

Se ejecutan las funciones de entrada, cambiando la marcación de lugares

de entrada

Se ejecutan las funciones de salida,modificando la marcación de la red

Si

Si

Si

No

No

No

Figura 4.1: Diagrama de �ujo del comportamiento en el tiempo de una SAN


estados asociando funciones de distribución de probabilidad temporales a cada activi-

dad y probabilidades para la selección de casos, se realiza de acuerdo a condiciones de

habilitación y terminación de la actividad. En la Figura 4.1 el algoritmo inicia con un

conjunto de actividades que no han sido habilitadas pero son candidatas a serlo. Para que

una actividad sea habilitada el predicado de todas las compuertas de entrada debe ser

verdadero y todos los lugares conectados directamente a la entrada de la actividad deben

contener al menos un token. Estas condiciones deben perdurar el tiempo que se tarda en

�nalizar la actividad. Una vez se habilita la actividad se evalúan las probabilidades espe-

ci�cadas en cada uno de sus casos, para luego seleccionar uno de ellos. Cuando el tiempo

de espera �naliza, es decir, que la actividad está terminada, se ejecutan las funciones de

entrada de las compuertas de entrada conectadas a la actividad y los lugares de entrada

que se encuentran conectados directamente a la actividad disminuyen su marcación en

uno. Finalmente, se ejecutan las funciones de salida de las compuertas de salida y se

modi�ca la marcación de la red SAN de acuerdo a la nueva con�guración de�nida por

las respectivas funciones.

4.2. Modelo SAN de referencia para evaluar la con�abilidad

del nodo HealTICa

referenceHardware

Figura 4.2: Modelo compuesto de referencia para la evaluación de la con�abilidad delnodo HealTICa

La con�abilidad del nodo HealTICa será evaluada a través de sus atributos �abilidad y

disponibilidad. Para lograrlo, se construyó un modelo SAN de referencia del hardware

del nodo sensor, en el que se modela el comportamiento de las fallas y la respuesta del

sistema sin los mecanismos de tolerancia y prevención de fallas, con el objetivo de contar

con una base para evaluar la efectividad de la arquitectura de con�abilidad y seguridad

propuesta. El modelo SAN de referencia para evaluar la con�abilidad del nodo HealTICa

está compuesto por dos submodelos atómicos, tal como se muestra en la Figura 4.2. El

primer submodelo (referenceHardware) está asociado al comportamiento de las fallas en

los principales componentes de hardware como son el microcontrolador, la batería, el


radio transceptor y los sensores de temperatura, pulsioximetría y adquisición y acon-

dicionamiento de la señal ECG. El segundo submodelo (communication) representa el

comportamiento de la comunicación inalámbrica para la transmisión de paquetes usan-

do el protocolo IEEE 802.15.4, teniendo en cuenta el algoritmo de acceso al canal que

determina el comportamiento de la comunicación al presentarse la pérdida de paquetes,

principal factor de in�uencia sobre la �abilidad de la comunicación. Los dos submode-

los conforman el modelo compuesto de referencia, que a través del bloque join pueden

compartir los lugares con el mismo nombre y cambiar su marcación de manera general.

CPUOk

batteryDrain

Figura 4.3: Submodelo atómico SAN del hardware del nodo sensor HealTICa

En la Figura 4.3 se presenta el submodelo atómico SAN del hardware del nodo sensor

correspondiente al submodelo referenceHardware de la Figura 4.2. La descripción del

submodelo es complementada por las Tablas 4.2 y 4.3, en donde se describe el compor-

tamiento de las compuertas de entrada y salida que lo constituyen. Los lugares o places

relacionados con el estado de los sensores son adsOk (módulo de adquisición y acondicio-

namiento de señal ECG), temperatureOk (sensor de temperatura corporal) y oximeterOk

(sensor de pulsioximetría). Además, el modelo cuenta con lugares relacionados con los

estados del microcontrolador (CPUOk), del transceptor de comunicación (transceiverOk)

y de la batería (batteryOk). De acuerdo con el comportamiento de las redes de actividad

estocástica descrito anteriormente, en este modelo un lugar con un token signi�ca que no

se han presentado fallas en dicho componente. Cuando no hay tokens en un lugar, sig-

ni�ca que se ha presentado una falla en el componente respectivo. Las actividades, que

representan acciones del sistema modelado, son representadas grá�camente por líneas

gruesas, y están asociadas con los fallos en cada componente del nodo. Las actividades

fueron con�guradas para seguir una distribución exponencial cuyo parámetro λ está li-

gado a las tasas de fallas, diferentes para cada componente de hardware, y obtenidas de

la información suministrada en las hojas de datos de los fabricantes. La actividad adsFail


representa el intervalo de tiempo promedio entre la ocurrencia de fallas en el sensor de

ECG, lo cual se modela a partir de la con�guración de la compuerta de entrada IG5

donde el predicado habilitador se de�ne en función del número de tokens en los lugares

adsOk->Mark()=1 y systemFail->Mark=0 para habilitar la actividad. Esta condición es

de�nida en la compuerta como se muestra en la Tabla 4.2.

La función de entrada de la misma compuerta retira el token del lugar adsOk, modelando

una falla en este componente. Del mismo modo que ocurre con las demás actividades y

compuertas de entrada incluidas dentro del modelo SAN tales como transceiverFail (tasa

de fallas asociadas al transceptor inalámbrico), habilitada por la compuerta de entrada

IG4 en donde el predicado habilitador considera la condición de no identi�carse fallos en

el transceptor (transceiverOk->Mark()=1 ) y no presentarse fallos en generales del siste-

ma, tal como se presenta en la Tabla 4.2. La actividad tempFail (tasa de fallos asociadas

al sensor de temperatura corporal) es habilitada por la compuerta de entrada IG6, con

un comportamiento semejante a las compuertas de entrada mencionadas anteriormente,

es decir, se veri�ca la existencia del token en el lugar tempOk que representa el fun-

cionamiento correcto del sensor de temperatura, como se presenta en la Tabla 4.2. El

predicado habilitador de la actividad batteryCrash (tasa de fallas asociadas a la batería),

está asociado con las compuertas de entrada IG1 e IG2, cuya habilitación depende del

predicado habilitador con condición de marcación en los lugares batteryOk>Mark()=1,

que representa el funcionamiento correcto de la batería y en el caso del lugar systemFail

el cual representa una falla total del sistema, la ausencia de tokens modela el funciona-

miento correcto del sistema. Las actividades oximeterFail (tasa de fallas del sensor de

pulsioximetría), habilitada por la compuerta IG7 y cpuFail (tasa de fallas asociada al

microcontrolador) habilitada por la compuerta IG3, se muestran en la Tabla 4.2 Como

se explicó anteriormente, la activación de las actividades depende de los predicados ha-

bilitadores de�nidos en las compuertas de entrada. Si el predicado de una compuerta de

entrada es verdadero, la actividad correspondiente es habilitada, activando su función de

distribución de tiempo. En el modelo de la Figura 4.3 cuando se completa una actividad,

un token es ubicado en el lugar systemFail, lo cual modela una falla en el sistema.

En el diseño e implementación del sistema HealTICa se consideró el protocolo IEEE

802.15.4 para la comunicación inalámbrica de los nodos sensores. Este es un estándar para

conectividad inalámbrica cuyas principales características son el bajo consumo energético

y bajas tasas de transmisión de datos. Las redes basadas en el protocolo son conocidas co-

mo Redes Inalámbricas de Área Personal (WPAN, Wireless Personal Area Network), las

cuales suelen ser con�guradas en dos tipos de topologías: estrella, utilizada en el sistema

HealTICa, en donde en uno de los dispositivos denominado coordinador controla todas

las comunicaciones de la red WPAN, y la topología punto a punto en donde cualquier


Compuerta de

entrada

Predicado Función de entrada

IG1(systemFail->Mark()==0)&&(batteryOk->Mark()==1)

;

IG2 batteryOk->Mark()==1 batteryOk->Mark()=0;

IG3(CPUOk->Mark()==1) &&(systemFail->Mark()==0)

CPUOk->Mark()=0;

IG4(transceiverOk->Mark()==1)&&

(systemFail->Mark()==0)transceiverOk->Mark()=0;

IG5(adsOk->Mark()==1)&&(systemFail->Mark()==0)

adsOk->Mark()=0;

IG6(temperatureOk->Mark()==1)&&

(systemFail->Mark()==0)temperatureOk->Mark()=0;

IG7(oximeterOk->Mark()==1)&&(systemFail->Mark()==0)

oximeterOk->Mark()=0;

Tabla 4.2: Predicados habilitadores y funciones de las compuertas de entrada delsubmodelo SAN del hardware del nodo sensor HealTICa

Compuerta de salida Función de salida

OG1

batteryLevel->Mark()=batteryLevel->Mark()-totalBatteryDrain;if (batteryLevel->Mark()<50){

systemFail->Mark()=1;}

Tabla 4.3: Función de salida del submodelo SAN del hardware del nodo sensor Heal-TICa

dispositivo puede comunicarse con los otros dispositivos que se encuentren en el área de

cobertura sin necesidad de un coordinador [44].

La �abilidad de una WBAN está directamente relacionada con la probabilidad de pér-

dida de paquetes y el retardo en la transmisión. Con el objetivo de construir un modelo

SAN que permita modelar el impacto de la comunicación inalámbrica sobre la �abilidad

del sistema HealTICa, a continuación se presentan los conceptos relacionados con los me-

canismos de acceso al medio utilizados en el estándar de comunicaciones IEEE 802.15.4,

que tienen in�uencia sobre la �abilidad de la comunicación inalámbrica. El estándar

IEEE 802.15.4 detalla los mecanismos y técnicas de acceso al medio de transmisión, con-

trolados por las capas física (Physical Layer, PHY) y de acceso al medio (Medium Access

Channel, MAC). En la capa física el estándar de�ne los mecanismos para la activación y

desactivación de los transceptores, la detección del nivel de energía del canal, la ejecución

del algoritmo de Clear Channel Assessment (CCA) para el protocolo CSMA/CA (Ca-

rrier sense multiple access with collision avoidance), selecciona la frecuencia del canal

y realiza la transmisión y recepción de datos. La capa MAC se encarga del acceso de


los dispositivos al canal de comunicaciones, de mantener un enlace con�able entre los

dispositivos, sincronizar, asociar y desasociar los dispositivos y hacer uso del protocolo

de acceso al medio. Para el acceso al medio usando IEEE 802.15.4 se puede hacer uso de

dos mecanismos, uno usando el envío de tramas de sincronización denominadas beacons

(beacon enabled), y otro sin el envío de estos paquetes (non-beacon enabled).

En el acceso al medio sin beacons (non-beacon enabled) los dispositivos emplean el proto-

colo CSMA/CA en el modo no ranurado (unslotted), en el cual los dispositivos escuchan

el canal por un periodo de tiempo antes de realizar una transmisión. Si encuentran el

canal desocupado, el dispositivo realiza la transmisión de la trama de datos; de lo con-

trario, vuelve a repetir la escucha para transmitir cuando el canal se encuentre libre. Un

dispositivo puede enterarse de la ocurrencia de una colisión en su transmisión si no se

recibe una trama de acuso de recibo (ACK) desde el dispositivo receptor. En el modo

beacon enabled se utiliza el protocolo CSMA/CA ranurado (slotted), donde un dispositivo

coordinador transmite beacons periódicamente para sincronizar los dispositivos de la red

y de�nir las ranuras (slots) de tiempo en las que los dispositivos pueden transmitir. En

el modo ranurado de CSMA/CA se utiliza una estructura llamada súper-trama que está

limitada por los beacons que transmite el coordinador. Cada súper-trama está compuesta

de una parte activa en la cual los nodos compiten por el canal en el periodo de acceso por

contienda (Content Access Period, CAP) o dependiendo de la aplicación pueden tener

unas ranuras de tiempo garantizadas (Guaranteed Time Slot, GTS) en las que pueden

transmitir sin necesidad de escuchar el canal ni competir con los demás dispositivos de la

red. A ese periodo de ranuras garantizadas se le llama periodo libre de contienda (Con-

tent Free Period, CFP). En la parte inactiva de la súper-trama los dispositivos pueden

entrar en modo de bajo consumo para ahorrar energía.

La Figura 4.4 muestra el algoritmo CSMA/CA ranurado, el cual es empleado por el no-

do HealTICa. En este algoritmo la capa MAC primero inicializa en cada dispositivo las

variables para cada intento de transmisión: NB, CW y BE. NB (Number of Backo�s)

es el número de veces que el algoritmo CSMA/CA fue requerido para hacer una trans-

misión. Este valor es inicializado en cero antes de un nuevo intento de transmisión. CW

(Contention Window) corresponde a la longitud de la ventana de contención y de�ne el

número de periodos de backo� en los cuales el canal debe estar inactivo antes de que

una transmisión pueda comenzar. Este valor es inicializado en 2 antes de cada intento de

transmisión y llevado a 2 cuando el canal se encuentra ocupado. BE (Backo� exponent)

es un valor usado como exponente para generar un periodo de backo� aleatorio (entre 0 y

2BE−1 ms) durante el cual el dispositivo debe esperar antes de intentar acceder al canal.

De allí se solicita una evaluación del estado del canal (Clear Channel Assesment, CCA),

realizado por la capa PHY. El CCA inicia en un límite de periodo de backo�. Si al evaluar

el canal este se encuentra ocupado, la capa MAC incrementa en una unidad los valores


NB=0, CW=2

BE= macMinBE

Retardorandom (2 -1)periodos Backoff

BE

Realiza CCAen el limite delperiodo Backoff

CSMA/CARanurado

Canal Ocupado

CW=2, NB=NB+1BE=min(BE+1, aMAxBE)

NB>macMaxCSMABackoffs

ComunicaciónFallida

CW=CW-1

CW=0

ComunicaciónExitosa

No

Si

No

Si

Si

No

Figura 4.4: Algoritmo CSMA/CA ranurado usado por el protocolo IEEE 802.15.4

de NB y BE, asegurándose de que BE no exceda el límite de�nido por el parámetro

aMaxBE. Si el valor NB es menor o igual al del parámetro macMaxCSMABacko�s, el

algoritmo CSMA/CA retorna a la generación del retardo aleatorio. Si el valor de NB

es mayor que el parámetro macMaxCSMABacko�s, el protocolo CSMA/CA termina con

un estado de acceso fallido al canal. Si el CCA permite concluir que el canal se encuentra

disponible, la capa MAC veri�ca que la ventana de contención haya expirado (CW = 0)

antes de comenzar la transmisión. Si la ventana de contención no es igual a cero, el algo-

ritmo CSMA/CA realiza nuevamente el CCA. En el caso contrario, la capa MAC inicia

la transmisión de una trama sobre el límite del próximo periodo de backo�. En el sistema

HealTICa el inicio del primer periodo de backo� de cada dispositivo es alineado con el

inicio de la transmisión del beacon. En este sentido la capa MAC se asegura de que la

capa física (PHY) comience sus transmisiones en el límite de un periodo de backo�.

La Figura 4.5 muestra el submodelo atómico SAN de la comunicación inalámbrica del

nodo sensor, correspondiente al submodelo communication de la Figura 4.2. Su propósi-

to es modelar el impacto del protocolo de comunicación inalámbrica sobre la �abilidad

y disponibilidad de sistema HealTICa. El modelo para el estándar IEEE 802.15.4 fue

con�gurado con los parámetros por defecto para el número de periodos de backo� (mac-

MaxCSMABacko�s = 4), y el número máximo de retransmisiones si el mensaje ACK no

es recibido (MaxFrameRetries = 3). Si el canal está ocupado, representado en el modelo

por el lugar chBusy, la ventana de contención (CW) se reinicializa a CW = 2. Si el

parámetro macMaxCSMABacko�s alcanza el número máximo de periodos de backo�s,


macMaxCSMABackoffs

OG1

OG2

OG3

OG4

Figura 4.5: Submodelo atómico SAN para la evaluación de la in�uencia del protocolode comunicación inalámbrico sobre la con�abilidad del sistema HealTICa

Input gate Enabling predicate Input function

IG1(transceiverOk->Mark()==1)&&(idleRadio->Mark()==1)&&(systemFail->Mark()==0)

idleRadio->Mark()=0;

IG2(waitACK->Mark()==1)&&(systemFail->Mark()==0)

waitACK->Mark()=0;

IG3(chBusy->Mark()==1)&&(systemFail->Mark()==0)

chBusy->Mark()=0;

Tabla 4.4: Predicados habilitadores y funciones de entrada de las compuertas deentrada del submodelo SAN de la comunicación inalámbrica del nodo sensor HealTICa

se reporta una falla en el envío de la trama de datos, y el número de tokens en el lugar

discardPacket es incrementado, como se muestra en la función de salida OG4 en la Tabla

4.5. De lo contrario, se realiza nuevamente el CCA. Si al realizar la evaluación se detecta

que el canal está desocupado, el parámetro CW disminuye su valor, como se observa en

la Figura 4.4.

El CCA se repite si CW alcanza el valor de 0. Esto asegura la realización de dos eva-

luaciones del canal (CCA) para evitar posibles colisiones de tramas de acuse de recibo.

Si el canal se vuelve a detectar como inactivo, el nodo intenta transmitir hasta que el

número de MaxFrameRetries sea alcanzado, momento en el que el paquete es descartado.

El submodelo atómico del protocolo de comunicación inalámbrica del sistema HealTICa

presentado en la Figura 4.5 considera una tasa de transmisión �ja representada por la

actividad txPacket, con�gurada con una distribución exponencial. Esta actividad es con-

trolada por la compuerta de entrada IG1 a través de su predicado habilitador, de�nido

en términos de la marcación del lugar idleRadio, que representa la disponibilidad del ra-

dio transceptor para iniciar el envío de datos; y del lugar transceiverOk, que como en las


compuertas anteriores, representa que no hay fallos asociados al hardware del transcep-

tor. Teniendo en cuenta que existe una gran cantidad de compuertas de entrada con este

mismos comportamiento, de acá en adelante describirán con detalle las compuertas que

presentan comportamientos diferentes. La actividad txPacket tiene asociados dos casos

probabilisticos, los cuales representan el acceso exitoso al medio al colocar un token en

el lugar waitACK ó la posibilidad de encontrar el canal ocupado, con lo que se ubica un

token en el lugar chBusy. En el primer caso, la actividad txStatus es habilitada por la

compuerta IG2 reportada en la Tabla 4.4, que representa el tiempo de espera del men-

saje de acuse de recibo tras haber establecido una conexión exitosa. En la compuerta

de salida OG4 que se presenta en la Tabla 4.5 se realiza la veri�cación del número de

retransmisiones. Si se alcanza este número se descarta el paquete, aumentando el núme-

ro de tokens en el lugar noACK. En caso de recibir de manera exitosa el ACK antes de

alcanzar el límite de retransmisiones, la compuerta OG3 restablece la marcación inicial

de los lugares idleRadio->Mark()=1 y noACK->Mark()=0. Si el canal está ocupado,

representado en el modelo por el lugar chBusy, la ventana de contención (CW) se reini-

cializa a CW = 2. Si el parámetro macMaxCSMABacko�s alcanza el número máximo de

periodos de backo�s con�gurado por defecto en cuatro, se reporta una falla en el envío

de la trama de datos, y el número de tokens en el lugar discardPacket es incrementado,

como se muestra en la función de salida OG4 en la Tabla 4.5. De lo contrario, se realiza

nuevamente el CCA. Si al realizar la evaluación se detecta que el canal está desocupado,

el parámetro CW disminuye su valor, como se observa en la Figura 4.4. Las actividades

txStatus y chStatus permiten modelar el retardo asociado al tiempo que ocupa el nodo

en recibir el mensaje ACK antes de realizar un proceso de retransmisión y el período

de backo� en el algoritmo CSMA/CA, respectivamente [45]. Estos casos representan en

estas actividades la probabilidad de fallo en el Clear Channel Assessment (CCA) y la

probabilidad de recepción exitosa del mensaje de ACK. Finalmente, Se considera que un

fallo en el sistema se produce si el número de tokens en el lugar discardPacket es mayor

de 40 tramas de datos por hora, es decir, si hay pérdidas mayores al 5% de las tramas,

número máximo de paquetes perdidos tolerables con el �n de reconstruir correctamente

la señal de ECG. En este caso, se ubica un token en el lugar systemFail. Las funciones

de salida de las puertas de salida OG3 y OG4 se describen en la Tabla 4.5 y permiten

veri�car si el número de retransmisions MaxFrameRetries en el lugar noACK es menor

a 3, y si el número de macMaxCSMABacko�s en el lugar con el mismo nombre es menor

a 4. Los lugares macMaxCSMABacko�s y MaxFrameRetries incrementan su marcación

con la dinámica en el tiempo del sistema modelado. Si la marcación en estos lugares

alcanza el limite mencionado, las compuertas OG3 y OG4, a través de su función de

salida, incrementan el número de tokens en el lugar discardPacket.



OG1waitACK->Mark()=1;maxCSMABacko�s->Mark()=0;

OG2idleRadio->Mark()=1;noACK->Mark()=0;

OG3

noACK->Mark()++;waitACK->Mark()=1;if(noACK->Mark()>3){

discardPacket->Mark()++;}

OG4

chBusy->Mark()=1;maxCSMABacko�s->Mark()++;if(maxCSMABacko�s->Mark()>4){

discardPacket->Mark()++;}

Tabla 4.5: Funciones de salida del submodelo SAN de la comunicación inalámbricadel nodo sensor HealTICa

Aprovechando las primitivas grá�cas dispuestas por la SAN para el modelado y evalua-

ción de la con�abilidad, se construyó el modelo de la Figura 4.3 con el objetivo de simular

el comportamiento de la �abilidad del hardware del nodo inalámbrico, sin incluir me-

canismos de con�abilidad. Es de resaltar la versatilidad para el control de la marcación

general del sistema que ofrecen las funciones y predicados de las compuertas de entrada

y salida, permitiendo modelar a través de modelos de alto nivel, la dinámica de las fallas

asociadas a lo componentes de hardware en el nodo. Como lugar de evaluación se de�nió

el lugar systemFail, sobre el cual se evalúa el comportamiento probabilístico de las fallas

en el nodo respecto al tiempo de operación del sistema. Este modelo sera utilizado como

referencia para comparar los valores de con�abilidad con el modelo del nodo inalámbrico

que incluye los mecanismos de con�abilidad, el cual se presenta en la siguiente sección.

4.3. Modelo SAN del nodo HealTICa con arquitectura de

con�abilidad

El modelo SAN descrito en esta sección incluye las medidas de hardware y software

consideradas en la arquitectura de seguridad y con�abilidad en el capítulo anterior. Los

resultados de la evaluación de este modelo serán comparados con los del modelo de

referencia para determinar la efectividad de la arquitectura de con�abilidad y seguridad.

El modelo que incluye los mecanismos de tolerancia y prevención de fallos está compuesto

por cinco (5) submodelos, que son agrupados en el modelo compuesto de la Figura 4.6. El

submodelo battery permite simular el consumo de energía del nodo sensor, mientras que

el submodelo comm802154 fue incluido para evaluar el impacto de comunicación sobre


Figura 4.6: Modelo compuesto del nodo sensor inalámbrico HealTICa con mecanismosde con�abilidad y seguridad

la �abilidad del sistema. En cuanto al hardware del nodo, se consideraron submodelos

para modelar las fallas sobre los sensores de pulsioximetría (oximeter), temperatura y

aceleración (I2Csensor), y se integraron al submodelo del modulo ECG (failModel) las

fallas en el transceptor y el microcontrolador principal. Como se explicó en el modelo de

referencia, el bloque join del modelo compuesto permite la actualización de los tokens

de los lugares compartidos entre los submodelos para considerar su contribución sobre

los atributos a evaluar.

En la Figura 4.7 se presenta el submodelo correspondiente a las fallas asociadas a la

batería (submodelo battery en la Figura 4.6) del nodo HealTICa con mecanismos de

con�abilidad y seguridad. Este modelo es similar al utilizado en el modelo de referencia,

es decir, cuenta con lugares para modelar el consumo de energía siguiendo un compor-

tamiento lineal en el tiempo. El lugar batteryLevel inicia con un valor de 1.000 tokens

que corresponden a los 1.000 mAh de la batería considerada en el diseño inicial. El lugar

batteryDrain es inicializado con 44 tokens que representan el consumo de energía de los

componentes del nodo por hora. Al activarse la actividad DrainningBattery, la función

de salida de la compuerta OG1 disminuye la marcación del lugar batteryLevel, de acuer-

do al consumo de�nido en el lugar batteryDrain, equivalente al modelo anterior. Si la

marcación del lugar batteryLevel es menor a 50 mAh, un token es ubicado en el lugar

de falla general del sistema, systemfail. En este modelo también se considera la tasa de

fallas para baterías de Li-ion, que de acuerdo a [46] es de alrededor de 20.000 horas.

En el modelo, el lugar batteryOk cuenta con un token inicialmente. Una vez �nalizada

la actividad batteryCrash, que tiene distribución exponencial, se ejecuta la función de

salida de la la compuerta de salida OG2 que se presenta en la Tabla 4.7, la cual ubica

un token en el lugar de falla de batería batteryFail y en el lugar de falla general del

sistema systemFail. Las compuertas de entrada IG1 e IG2 controlan las condiciones de

ejecución de las actividades DrainningBattery que dependen de la marcación en los lu-

gares batteryDrain->Mark()>0, batteryOk=1 y systemFail=0 y batteryCrash, tal como

se muestra en la Tabla 4.6.


Puerta de entrada Predicado habilitador Función de entrada

IG1(systemFail->Mark()==0)&&(batteryDrain->Mark()>0)&&(batteryOk->Mark()==1)

;

IG2 batteryOk->Mark()==1&& batteryOk->Mark()=0;

Tabla 4.6: Submodelo SAN del consumo de energía del nodo sensor HealTICa conmecanismos de con�abilidad y seguridad

Figura 4.7: Submodelo atómico SAN para modelar el consumo de energía del nodosensor inalámbrico HealTICa con mecanismos de con�abilidad y seguridad

Compuerta Función de salida

OG1

batteryLevel->Mark()=batteryLevel->Mark()-totalBatteryDrain;if(batteryLevel->Mark()<50){systemFail->Mark()=1;}

OG2 systemFail->Mark()=1;

Tabla 4.7: Funciones de salida del submodelo SAN de la batería del nodo sensorHealTICa con mecanismos de con�abilidad y seguridad

Para modelar el impacto del protocolo de comunicación inalámbrica en la arquitectura

de con�abilidad y seguridad (submodelo comm802154 en la Figura 4.6) se ha utilizado el

mismo submodelo de la Figura 4.5. En los escenarios experimentales se realizan cambios

en los parámetros MaxCSMABacko�s y MaxFrameRetries para evaluar su in�uencia

sobre los atributos de �abilidad y disponibilidad.

En la Figura 4.8 se presenta el submodelo atómico de las fallas en componentes de hard-

ware, fundamentales para el correcto funcionamiento del nodo sensor HealTICa. Este

corresponde al submodelo failModel de la Figura 4.6. Si se presenta una falla en el ra-

dio transceptor (transceiverFail), el microcontrolador principal (cpuFail) o el módulo de

adquisición y acondicionamiento de la señal ECG (adsFail), se considera que el nodo

HealTICa no se encuentra en condiciones de continuar realizando medidas de variables


�siológicas. Este funcionamiento es denominado modo seguro, como se explicó en la

sección 3.3.1. Además, en el modelo se consideran los mecanismos de veri�cación imple-

mentados con el patrón Sanity Check, al incluir un caso que permite veri�car si las fallas

se presentan por errores en los tiempos que se genera la interrupción de datos disponibles

del módulo ECG. En la Tabla 4.8 se presentan los predicados y funciones de entrada de

las compuertas de entrada del modelo de fallas.

En el modelo, el lugar irqNull representa el estado en el cual el canal de veri�cación

detecta fallas en los tiempos de interrupción y su marcación esta controlada por la com-

puerta IG2 en la Tabla 4.8 en donde se de�ne como predicado habilitador la condición

de garantizar el correcto funcionamiento del modulo ECG (adsOk->Mark()=1) y de no

tener fallas generales en el sistema (systemFail->Mark()=0). La actividad reinitADS

corresponde a la medida de mitigación realizada desde el �rmware del nodo, donde se

reinicializan las interfaces de comunicación con el módulo ECG para intentar recuperar

el funcionamiento correcto del nodo. Esta actividad es habilitada de acuerdo al predi-

cado de entrada de la compuerta IG5 cuya condición es haber detectado una falla de

comunicación con el modulo ECG (irqNull->Mark()=1) y no haber ejecutado más de

tres procesos de reinicialización del modulo (reinitADSFail->Mark()<=3). En la com-

puerta de salidaOG3, cuya de�nición se presenta en la Tabla 4.9, se registra el número

de reinicializaciones realizadas sobre el módulo. Si este proceso se realiza en más de tres

oportunidades, se determina que el módulo se encuentra averiado y se procede a ubicar

un token en el lugar systemFail correspondiente a una falla general del sistema. Los luga-

res CPUOk y transceiverOk representan la funcionalidad correcta del microcontrolador

y el radio transceptor, respectivamente. En las actividades asociadas a cada lugar se

con�guró la tasa de fallos reportada por el fabricante con una distribución exponencial

al momento de activarse alguna de las actividades relacionadas con las fallas en estos

componentes. Un token es ubicado en el lugar systemFail representando la criticidad de

una falla sobre estos componentes.

Una de las veri�caciones que realiza el patrón Sanity Check (redundancia liviana) está

enfocada a interceptar los valores publicados por los sensores de aceleración y tempera-

tura corporal sobre la interfaz de comunicación serial con los sensores de temperatura

y aceleración. En la Figura 4.9 se presenta el submodelo de esta funcionalidad que co-

rresponde al submodelo I2CSensor de la Figura 4.6. Los sensores pueden generar fallas,

representadas por la actividad getI2CVarFail, activada por la compuerta de entrada IG1

que se presenta en la Tabla 4.10, por eventos tales como la identi�cación de un valor

nulo (i2cNullValue) o errores de comunicación (i2cBusError). Al presentarse cualquiera

de estas situaciones se reinicializan desde software las con�guración de los sensores de

temperatura corporal y aceleración como medida de recuperación de las fallas. Esto es

modelado con la actividad reinitI2CSlave. En la compuerta OG2 se modela el número


Compuerta de entrada Predicado habilitador Función de entrada

IG1(isolatedSensors->Mark()>2)&&

(systemFail->Mark()==0)isolatedSensors->Mark()=0;

IG2(adsOk->Mark()==1)&&systemFail->Mark()==0)

adsOk->Mark()=0;

IG3(cpuOk->Mark()==1) &&(systemFail->Mark()==0)

cpuOk->Mark()=0;

IG4(transceiverOk->Mark()==1)&&

(systemFail->Mark()==0)transceiverOk->Mark()=0;

IG5(irqNull->Mark()==1) &&(reinitADSFail->Mark()<=3)

irqNull->Mark()=0;

Tabla 4.8: Predicados habilitadores y funciones de entrada de las compuertas deentrada del submodelo SAN del hardware del nodo sensor HealTICa con mecanismos

de con�abilidad y seguridad

Figura 4.8: Submodelo atómico SAN del hardware del nodo sensor HealTICa conmecanismos de con�abilidad y seguridad

máximo de reinicios antes de, en este caso, aislar el sensor, es decir, no se realizarán más

peticiones y el sistema podrá continuar adquiriendo y procesando las variables médicas

de los demás sensores del nodo. La función de salida de la compuerta OG3 se presenta en

la Tabla 4.11, y representa un proceso exitoso de recuperación de la comunicación con el

sensor. De ser así se restablecen los valores de la marcación inicial de los lugares tempOk

(tempOk->Mark()=1), accelOk (accelOk->Mark()=1) y reinitI2CFail->Mark()=0, si la

reinicialización desde el �rmware sirvió para superar la falla. La tasa de fallas con�gu-

rada en la actividad getI2CVarFail fue obtenida de las especi�caciones técnicas de los

sensores y de valores experimentales usando la interfaz de comunicación I2C.

Finalmente, el último modelo presentado en la Figura 4.10, corresponde al pulsioxímetro,

sobre el cual el patrón Sanity Check realiza la veri�cación de valores de variables dentro

del rango de funcionamiento a través de la interceptación del pin RX de la interfaz

UART. Las fallas en el sensor son representadas por la actividad (oximFail), activada

por la compuerta de entrada IG1, de�nida como se presenta en la Tabla 4.12. Entre



OG1adsCrash->Mark()=1;systemFail->Mark()=1;adsOk->Mark()=0;

OG2reinitADSFail->Mark()=0;

adsOk->Mark()=1;

OG3

reinitADSFail->Mark()++;adsOk->Mark()=1;if(reinitADSFail->Mark()>3){systemFail->Mark()=1;adsOk->Mark()=0;adsCrash->Mark()=1;}

Tabla 4.9: Funciones de salida en el modelo SAN de fallas de hardware del nodoHealTICa con mecanismos de seguridad y con�abilidad

Puerta de entrada Predicado habilitador Función de entrada

IG1

(accelOk->Mark()==1)&&(tempOk->Mark()==1) &&(systemFail->Mark()==0) &&

(tempSensorCrash->Mark()==0)

tempOk->Mark()=0;accelOk->Mark()=0;

IG2((i2cBusError->Mark()==1) ||

(tempNullValue->Mark()==1)) &&(reinitI2CFail->Mark()<4)

i2cBusError->Mark()=0;tempNullValue->Mark()=0;

Tabla 4.10: Funciones de salida del submodelo SAN del nodo sensor HealTICa conmecanismos de con�abilidad y seguridad


OG1tempSensorCrash->Mark()=1;isolatedSensors->Mark()++;tempOk->Mark()=0;

OG2

reinitI2CFail->Mark()++;if(reinitI2CFail->Mark()>3){isolatedSensors->Mark()++;reinitI2CFail->Mark()=0;tempOk->Mark()=0;tempSensorCrash->Mark()=1;batteryDrain->Mark()=batteryDrain->Mark()-consI2CSensors;}

OG3reinitI2CFail->Mark()=0;tempOk->Mark()=1;accelOk->Mark()=1;

Tabla 4.11: Funciones de salida en el modelo SAN de sensores de temperatura yaceleración del nodo HealTICa con mecanismos de seguridad y con�abilidad


Figura 4.9: Submodelo atómico SAN para evaluar el impacto en los valores de con�a-bilidad las fallas en los sensores de aceleración y temperatura corporal con mecanismos

de con�abilidad y seguridad

Figura 4.10: Submodelo SAN para modelar el impacto de las fallas en el sensor depulsioximetría del nodo sensor HealTICa con mecanismos de con�abilidad y seguridad

las eventos identi�cados como fallas se encuentran la repetición constante de valores

asociados a un estado de falla (stuckAtFault) y las fallas en la comunicación, es decir, no

hay ninguna comunicación o la veri�cación del valor entregado por el pulsioxímetro para

indicar una mala conexión del sensor óptico en el cuerpo del paciente (oximBadComm).

Como en los casos de los sensores de temperatura, aceleración y el módulo ECG, como

medida de mitigación a la falla se realiza la reinicialización (reinitOxim) de parámetros

de con�guración del sensor. El pulsioxímetro también puede ser aislado, de acuerdo a

lo de�nido en la compuerta de salida OG2 de la Tabla 4.13, para darle continuidad

al servicio al no considerarlo un sensor fundamental para el funcionamiento del nodo.

Sin embargo, cuando se aísla un sensor, se reporta al nodo sink que el nodo sensor se

encuentra funcionando en estado de falla.


Compuerta de entrada Predicado habilitador Función de entrada

IG1(oximOk->Mark()==1)&&(systemFail->Mark()==0)

oximOk->Mark()=0;

IG2(oxiStuckAtFault->Mark()==1)||

(uartFail->Mark()==1)&&(reinitOximFail->Mark()<=3)

oxiStuckAtFault->Mark()=0;uartFail->Mark()=0;

Tabla 4.12: Predicados habilitadores y funciones de entrada para el modelo SANdel sensor de pulsioximetría del nodo HealTICa con mecanismos de con�abilidad y

seguridad


OG1isolatedSensors->Mark()=1;oximOk->Mark()=0;

OG2

reinitOximFail->Mark()++;if(reinitOximFail->Mark()>3){reinitOximFail->Mark()=0;isolatedSensors->Mark()++;oximOk->Mark()=0;batteryDrain->Mark()=batteryDrain->Mark()-batteryConsOxim;}

OG3 oximOk->Mark()=1;

OG4

oximBadConn->Mark()++;if(oximBadConn->Mark()>3){oximBadConn->Mark()=0;isolatedSensors->Mark()++;oximOk->Mark()=0;}else{oximOk->Mark()=1;}

Tabla 4.13: Funciones de salida en el modelo SAN del sensor de pulsioximetría delnodo HealTICa con mecanismos de seguridad y con�abilidad

4.4. Escenarios experimentales y resultados

Para evaluar la efectividad de los mecanismos que conforman la arquitectura propuesta,

sobre los atributos de con�abilidad, se consideraron diferentes escenarios de funciona-

miento típicos del sistema HealTICa. Estos experimentos permitieron identi�car pará-

metros críticos, que impactan el comportamiento en el tiempo de la con�abilidad y cómo

mejora su respuesta en el tiempo a través de la inclusión de los mecanimos de tolerancia

y prevención de fallos propuestos. Los modelos descritos en la sección anterior fueron

construidos y simulados utilizando el software Möbius, que es una herramienta de simu-

lación de modelos dinámicos complejos, a partir de la construcción de modelos de alto

nivel como son las redes de actividad estocástica, además de ofrecer múltiples técnicas de


solución [30]. El software fue instalado y ejecutado en un computador portátil con pro-

cesador Intel Core i5-3337U (1,80GHZ, 3MB cache), 4 GB de memoria RAM y sistema

operativo Ubuntu Linux 14.04. Antes de iniciar a describir en detalle los parámetros con-

�gurados para cada uno de los escenarios experimentales, en la Tabla 4.14 se presentan

algunas parámetros cuyos valores son �jos para todos los escenarios. Entre los valores

mencionados se encuentran las tasa de fallos de los dispositivos electrónicos tales como

pulsioxímetro, módulo ECG, microcontroladores y sensores de temperatura y acelera-

ción, los cuales fueron tomados de las hojas de datos publicadas por los fabricantes [47],

[48]. La tasa de transmisión de datos fue establecida en 900 tramas por hora, número

asociado al valor necesario de paquetes para reconstruir y analizar correctamente la señal

ECG.

Los resultados obtenidos de la simulación realizada en la herramienta Möbius fueron

gra�cados para analizar el comportamiento de la con�abilidad, en el caso particular la

�abilidad y disponibilidad, con respecto al tiempo de uso del sistema. Para evaluar la

�abilidad se consideró un tiempo de 1.000 horas de uso no continuo. Entre tanto, para la

disponibilidad se consideran 60 horas de operación continua como máximo valor, teniendo

en cuenta la autonomía energética que presenta una fuerte relación con la capacidad total

de la batería.

Parámetro Valor MTBF Descripción

adsFailRate 2,6×10−10 Tasa de fallas módulo ECG

oximeterFailRate 3,4×10−6 Tasa de falla sensor de pulsioximetría

tempFailRate 1,8×10−6 Tasa de fallas sensorde temp. corporal

txRate 900 Tasa de transmisión (tramas/hora)

Tabla 4.14: Parámetros constantes en los escenarios experimentales propuestos parala evaluación de la con�abilidad del nodo HealTICa

Los escenarios propuestos para la evaluación de la disponibilidad y con�abilidad se com-

ponen de grupos de con�guraciones donde se modi�can los valores de parámetros aso-

ciados al impacto del componente que se desea evaluar. Es decir, los escenarios están

relacionados con los factores que tienen mayor impacto sobre los atributos de con�a-

bilidad, de acuerdo a los resultados de los análisis de requerimientos (FTA y FMEA)

realizados en el capítulo 2. A continuación se presentan los escenarios experimentales

propuestos para la simulación, con los que se pretende evaluar la in�uencia de factores

como la comunicación inalámbrica, la autonomía energética, la �abilidad de componentes

de hardware críticos sobre el modelo compuesto de referencia de la Figura 4.2 y la efecti-

vidad de los mecanismos propuestos en la arquitectura de con�abilidad correspondiente

al modelo compuesto de la Figura 4.6.


Escenario

ExperimentalVariable Valor

relCommTypicalreceiveACKProb 0,95

chBusyProb 0,05

relCommNoisyreceiveACKProb 0,85

chBusyProb 0,15

relMCUTypical mcuFailRate 1× 10−8

relMCULow mcuFailRate 1× 10−6

relBatteryTypical batteryFailRate 1/40.000

Tabla 4.15: Con�guración de valores experimentales para la evaluación de la �abilidaddel nodo sensor HealTICa en diferentes escenarios

- Escenario de �abilidad asociado a la comunicación inalámbrica (relCommTypical,

relCommVeryNoisy, relCommVeryNoisy): en este grupo de experimentos se con-

sideran valores típicos de congestión de los canales inalámbricos de comunicación

para un ambiente domiciliario. Es importante considerar que el protocolo IEEE

802.15.4 utiliza diferentes canales de la banda libre de 2,4GHz para realizar los

procesos de comunicación, por lo cual comparte el medio con múltiples tecnolo-

gías como Wi-Fi, bluetooth y dispositivos electrónicos como teléfonos inalámbricos,

entre otros, lo cual hace al nodo sensor altamente susceptible a la interferencia

electromagnética generada por las tecnologías mencionadas. Los valores de las va-

riables fueron con�gurados de acuerdo a los resultados experimentales realizados

en ambientes altamente congestionados, donde se pudieron obtener valores para

la probabilidad de recepción exitosa de mensajes de acuse de recibo ACK (recei-

veACKProb) y de congestión del canal (chBusyProb), tal como se presenta en la

Tabla 4.15. En escenarios domiciliarios es importante considerar diferentes niveles

de congestión, por lo cual este grupo esta compuesto por 3 niveles de congestión

denominados relCommTypical para valores típicos, relCommNoisy para escenarios

ruidosos y relCommVeryNoisy para escenarios con mucha congestión. Este último

fue evaluado experimentalmente con 10 dispositivos Wi-Fi radiando alrededor del

nodo sensor, observando un evidente in�uencia en el número de paquetes recibidos

para periodos de tiempo de 20 minutos. Este grupo de experimentos fue evaluado

para ambos modelos SAN, donde cada con�guración generó un espacio de esta-

dos de 182.797 estados y un tiempo promedio de solución de 321 segundos para el

modelo de referencia de la Figura 4.2, y 415.987 estados para el nodo HealTICa

con arquitectura de con�abilidad, con un tiempo promedio de solución de 12.678

segundos. En la Figura 4.11 se muestran los resultados de la evaluación del modelo

SAN de referencia del nodo HealTICa para simular la in�uencia de la congestión

en el canal de comunicación inalámbrico sobre la �abilidad del sistema.


relCommTypicalrelCommNoisyrelCommVeryNoisy

Tiempo [horas]

Fiab

ilida

d

Figura 4.11: Fiabilidad del nodo HealTICa de referencia para diferentes escenariosde congestión en el canal de comunicación inalámbrico

En la grá�ca se observa el decrecimiento exponencial en los valores de �abilidad,

a partir del efecto que tiene la congestión del canal de comunicación, lo cual se ve

re�ejado en perdida de paquetes y difícil acceso al medio de transmisión. Para valo-

res menores a 100 horas las grá�cas para los tres escenarios presentan valores muy

cercanos, por lo cual es importante analizar el comportamiento para tiempos ma-

yores. A partir de allí es importante considerar un umbral del 95% para programar

actividades de mantenimiento preventivo que en los casos donde se presenta mayor

congestión. Es recomendable realizarlo para tiempos entre las 600 y 700 horas de

operación del sistema. Se recomienda realizar un análisis de los canales mas satura-

dos del entorno de operación del nodo HealTICa y de ser necesario recon�gurar el

�rmware de los radios tranceptores, de manera que pueda operar en canales donde

la comunicación inalámbrica no sean muy susceptibles a la interferencia de otras

tecnologías inalámbricas. En [49] se recomienda con�gurar los radios transceptores

en el canal 20, que corresponde a una frecuencia de 2.450 MHz.

En cuanto a los resultados del modelo SAN con mecanismos de con�abilidad, se

presenta el resultado de la simulación del modelo compuesto con mecanismos de

con�abilidad en la Figura 4.12. Los escenarios considerados fueron los mismos que

en el modelo de referencia, salvo la modi�cación de los valores de parámetros por

defecto del protocolo IEEE 802.15.4, relacionados con el número de retransmisio-

nes (MaxFrameRetries = 7) y el número máximo de periodos de backo� (maxCS-

MABacko� = 5). Se observa que en el peor escenario considerado, es decir, con

ambientes muy ruidosos el sistema presenta un incremento del 2% en la �abilidad

para valores cercanos a las 600 horas y del 4% para valores cercanos a las 1.000

horas respecto al modelo de referencia. En cuanto a los escenarios con valores de

congestión típicos y ruidosos, el incremento también es importante, pues el nodo


HealTICa en un escenario típico tendrá un �abilidad asociada a la comunicación

inalámbrica después de 1.000 horas de operación cercana al 98%, que respecto al

modelo de referencia permitirá prolongar los tiempos de mantenimiento preventivo

y correctivo del sistema.

relCommTypicalrelCommNoisyrelCommveryNoisy

Tiempo [horas]

Fiab

ilida

d

Figura 4.12: Evaluación de la �abilidad de la comunicación del nodo HealTICa queincluye los mecanismos propuestos en la arquitectura de con�abilidad.

- Escenarios de �abilidad de microcontrolador principal (relMCULow y relMCUHigh):

este grupo de experimentos considera valores típicos encontrados en el mercado co-

rrespondientes al tiempo medio entre fallas (Mean Time Before Failure, MTBF)

para microcontroladores de 32 bits (mcuFailRate). Tal como se observó en el análisis

de falla y efecto el microcontrolador representa un cuello de botella de con�abili-

dad al ser un componente fundamental para garantizar la correcta funcionalidad

del sistema de monitorización remota. Una falla en este componente representa un

error severo en el sistema. Los fabricantes más reconocidos ofrecen una diferentes

gamas de microcontroladores de acuerdo al tipo de aplicación y la �abilidad nece-

saria. En la Tabla 4.15 se presentan los valores de MTBF usados para simular este

escenario. El tiempo de simulación promedio para este grupo de escenarios fue de

1.108 segundos, generando un espacio de estados de 7.564. Estos valores para el

modelo compuesto de referencia de la Figura 4.2. Entre tanto para el modelo SAN

que incluye los mecanismos de con�abilidad de la Figura 4.6, el tiempo promedio

fue de 13.987 segundos con un numero de 416.528 estados.

En la Figura 4.13 se observa el comportamiento para el par de valores seleccionados

para evaluar el impacto del MTBF del microcontrolador sobre la con�abilidad del

sistema. De acuerdo a los valores disponibles en el mercado se realizó la compara-

ción del comportamiento de ambos valores en el tiempo de operación del sistema.

En la grá�ca se evidencia la tendencia a incrementar la diferencia entre ambas

grá�cas después de 1.000 horas de operación. Esta diferencia es crítica pues para


relMCUHighrelMCULow

Tiempo [horas]

Fiab

ilida

d

Figura 4.13: Fiabilidad del nodo HealTICa para diferentes valores de capacidad yporcentajes de carga de baterías

microcontroladores con bajo MTBF el valor de la �abilidad está por debajo del

90% despues de 1.000 horas de operación, exigiendo la intervención de manteni-

miento del sistema para poder corregir un porcentaje de falla crítica del 10%. Entre

tanto un valor alto de MTBF permite llegar de manera holgada a las 1.000 horas

de operación. Sin embargo, estos dispositivos tienen un alto valor en el mercado,

encareciendo el precio �nal del mercado del sistema HealTICa.

Los resultados que dan cuenta del comportamiento de la �abilidad con respecto al

tiempo de uso del nodo HealTICa con mecanismos de con�abilidad son presentados

en la Figura 4.14, donde se observa un incremento de la �abilidad cercano del 6%

respecto al modelo de referencia para el escenario de uso de microcontroladores con

bajos valores de MTBF considerado el peor escenario. La diferencia en comparación

con el escenario de microcontroladores con altos MTBF se mantiene igual a lo

observado en el modelo de referencia, Figura 4.13 (cerca del 2%). A pesar de no

contar con un microcontrolador principal redundante que permita dar continuidad

al sistema en caso de una falla, el patrón Sanity Check permite dar continuidad al

sistema en caso de fallos no severos en sensores que no son fundamentales para la

adquisición de variables �siológicas del paciente, esto de acuerdo a lo de�nido por

el personal médico. Se pudo determinar a partir de los resultados que en el modelo

que se incluye la arquitectura de con�abilidad, se puede prescindir de la inclusión

de microcontroladores con altos valores de �abilidad al garantizar valores �abilidad

del 95% después de 1.000 horas de uso, aceptable para este tipo de dispositivos de

monitorización remota.

- Escenarios de �abilidad y disponibilidad asociados a la batería (relBatteryHigh, rel-

BatteryTypical y relBatteryLow): en este escenario se consideran los valores de tasa


relMCUHighrelMCULow

Tiempo [horas]

Fiab

ilida

d

Figura 4.14: Evaluación de la �abilidad del microcontrolador del nodo HealTICa queincluye los mecanismos propuestos en la arquitectura de con�abilidad.

de fallas, que en el caso de las baterías esta dado por el ciclo de vida. En el mer-

cado existen diferentes valores de ciclos de vida para baterías especí�camente de

Li-Ion, siendo un valor típico 40.000 horas. Teniendo en cuenta que la batería y la

autonomía de las misma tienen fuerte in�uencia sobre los atributos de �abilidad

y disponibilidad, en este escenario se varía el valor del ciclo de vida de la misma,

teniendo como valores 40.000 horas como valor típico, 20.000 horas como baja �a-

bilidad y 60.000 para baterías de alta �abilidad. Con esta con�guración la duración

del tiempo de solución para el modelo SAN de referencia para la evaluación de la

con�abilidad del nodo HealTICa, Figura 4.2 fue de 134 segundos, generándose un

total de 7.564 estados. Para el modelo SAN del nodo sensor incluyendo la arquitec-

tura de con�abilidad y seguridad, Figura 4.6, los valores ascienda a 7.723 segundos

de duración para la solución y se generan 427.012 estados.

relBatteryHighrelBatteryTypicalrelBatteryLow

Tiempo [horas]

Fiab

ilida

d

Figura 4.15: Evaluación del impacto sobre la �abilidad del nodo HealTICa de la tasade falla de la batería


En la Figura 4.15 se observa que la diferencia entre la batería con ciclo de vida de

40.000 horas, es decir relBatteryTypical, respecto a la batería de alta �abilidad no

es tan grande, y para las 900 horas se alcanza una diferencia apenas cercana al 1%.

Teniendo en cuenta los altos costos asociados a las baterías de alta �abilidad, a

partir de estos resultados se decide utilizar una batería con ciclo de vida de 40.000

horas. Evidentemente, de la grá�ca se selecciona descartar la opción de considerar

baterías de baja �abilidad pues su tendencia después de las 1.000 horas de operación

del sistema impactará fuertemente la �abilidad del sistema.

Los resultados del comportamiento de la �abilidad asociados valores de ciclo de

vida de las baterías en el modelo con mecanismos de con�abilidad (Figura 4.6),

son presentados en la Figura 4.16. En la �gura se observa una diferencia mínima

respecto a los resultados del modelo de referencia de la Figura 4.15. Esto se debe

a que entre los mecanismos propuestos no se ha considerado la inclusión de téc-

nicas que consideren tolerar o prevenir fallos en las baterías, tales como baterías

redundantes o algoritmos de predicción de fallas. En la grá�ca se observa que la

tendencia del descenso de la �abilidad en los resultados del modelo de referencia

es más pronunciada que en el modelo con mecanismos de con�abilidad, lo cual

permite predecir un mejor comportamiento del sistema en términos de �abilidad

despues de las 1.000 horas de operación

relBattLowrelBattTypicalrelBattHigh

Tiempo [horas]

Fiab

ilida

d

Figura 4.16: Evaluación del impacto sobre la �abilidad del nodo HealTICa de la tasade falla de la batería

Finalmente, se proponen un par de escenarios que permiten evaluar la in�uencia

de la autonomía de batería sobre los valores de la disponibilidad del nodo sen-

sor HealTICa. De acuerdo con las sesiones de co-creación se requiere que el nodo

cuenta con una autonomía mínima de 2 horas, tiempo aproximado de una sesión de

monitorización de signos vitales adecuada, en pacientes con enfermedades crónicas.

Con este escenario se busca estimar el valor mínimo de carga de batería necesario


para establecer como umbral antes de realizar la sesión de medida. Ante un valor

de carga de la batería por debajo de este umbral se debe noti�car al sistema la

necesidad de entrar en un modo seguro donde se alerte al usuario que se requiere

su intervención para incrementar los porcentajes de carga de batería. Además de lo

anterior se desea corroborar que la decisión técnica de elegir baterías de 1.000 mAh

es su�ciente para cumplir con el requerimiento especi�cado por los stakeholders.

En el primer escenario se con�gura la capacidad de la batería, que corresponde

a la variable batteryCharge con valores de 800 mAh (availBattLow), 1.000 mAh

(availBattTypical), y 1.600 mAh (availBattHigh). El segundo escenario considera

porcentajes de batería al inicio del uso del nodo sensor de 10% (avalBatt10% ),

20% (avalBatt20% ), y 30% (avalBatt30% ) de la capacidad total de una batería

con capacidad total de 1.000 mAh. El número de estados para el modelo SAN del

nodo sencillo fue de 54208 y un tiempo de solución computacional de 750 segundos.

En este escenario solo se presentan los grá�cos obtenidos con el modelo compuesto

de con�abilidad y seguridad pues los resultados respecto al modelo de referencia

son iguales, lo cual era de esperarse pues en las medidas de con�abilidad no se

interviene el modelo de descarga de batería y se considera que el microcontrolador

redundante, tal y como se desarrolló en el prototipo, es alimentado por una fuente

de alimentación externa.

De acuerdo a lo anterior el primer escenario permite determinar la autonomía del

nodo HealTICa para diferentes valores de capacidad de almacenamiento de carga

eléctrica. En la Figura 4.18 se presenta el comportamiento en el tiempo de la

disponibilidad del sistema para 3 valores de capacidad de carga. Es evidente el

excelente comportamiento de la batería de 1.600 mAh. Sin embargo, de acuerdo

a los periodos de�nidos en las sesiones de co-creación una batería de 1.000 mAh

permite al nodo cumplir con el requerimiento de disponibilidad de mínimo dos

horas en una sesión de medida.

El segundo escenario es importante, para determinar el valor umbral mínimo de

porcentaje de carga al momento de iniciarse una sesión de medida de variables

médicas. En la Figura 4.18 se presenta el comportamiento en el tiempo de la dispo-

nibilidad del nodo para tres situaciones típicas de uso. Se consideran porcentajes

bajos de carga batería con valores menores al 30%, por lo cual se consideran dos

niveles más por debajo de este umbral, 10% y 20%. De la grá�ca es evidente con-

cluir que el comportamiento del sistema para los valores de carga de 10% y 20%

son críticos para disponibilidad del sistema, pues con el 10% de batería se tiene

solo un 40% de probabilidad de tener disponible el sistema durante dos horas. A

pesar de no ser tan critico el caso del 20%, se decidió de�nir como umbral mínimo

a partir del comportamiento de la grá�ca el valor de 30% de carga en la batería del


800mAh1000mAh1600mAh

Tiempo [horas]

Dispo

nibi

lidad

Figura 4.17: Evaluación de disponibilidad del nodo HealTICa de acuerdo a capacidadde carga de diferentes baterías

nodo sensor. De identi�carse este valor se noti�cará al usuario realizar la carga del

nodo, entrando el sistema en modo seguro hasta alcanzar valores de carga mayores

al 30%.

avalBatt30%(1000mAh)avalBatt20%(1000mAh)avalBatt10%(1000mAh)

Tiempo [horas]

Dispo

nibi

lidad

Figura 4.18: Evaluación de disponibilidad del nodo HealTICa de acuerdo a capacidadde carga de diferentes baterías

Ha sido demostrado a partir de la comparativa del comportamiento en el tiempo de la

�abilidad del nodo HealTICa, la efectividad de los mecanismos de con�abilidad relaciona-

dos con las técnicas de prevención y tolerancia a fallos que conforman la arquitectura de

con�abilidad propuesta. Los resultados permiten corroborar incrementos importantes en

las respuestas de cada uno de los escenarios propuestos respecto al modelo de referencia.

En cuanto a la disponibilidad, su fuerte relación con los valores de carga de la batería

hacen que el aporte de la arquitectura sobre este atributo sea despreciable, con lo cual

este atributo debe ser abordado con otro tipo de mecanismos en investigaciones futuras.


De esta manera se da paso a la descripción y evaluación de la propiedad de seguridad a

partir del modelado de los mecanismos de seguridad propuestos en la sección 3.4 de este

trabajo.

4.5. Modelos atómicos SAN para la evaluación de la segu-

ridad

Para la evaluación de la efectividad de los mecanismos de seguridad propuestos como

técnica de mitigación a las amenazas de los atributos asociados a la seguridad del nodo

sensor inalámbrico, se construyeron los modelos SAN para la evaluación de la probabi-

lidad de intrusión exitosa del sistema con y sin la implementación de los mecanismos

de seguridad. En el modelo de la Figura 4.19 se de�ne como estado de inicio de la eva-

luación de la seguridad en la comunicación inalámbrica el proceso de asociación de los

nodos sensores con el nodo sink a través de envío de beacons. Estos son transmitidos a

todos los sensores que están escuchando el canal de comunicación, pero solo aquellos que

han sido con�gurados con los mismos parámetros de acceso al medio podrán asociarse

con el nodo sink para crear la red de área personal (WPAN). Esta condición se modela

ubicando un token en el lugar initWBAN, el cual habilita la actividad beaconBroadcast.

En esta actividad se tiene en cuenta la posibilidad de tener un dispositivo no autorizado

intentando establecer comunicación con el nodo, pero al no tener las con�guración ade-

cuada la comunicación es rechazada (deviceRejected). En está actividad se con�guraron

dos casos con diferentes probabilidades. La primera representa la asociación de un dis-

positivo no autorizado pero que logró establecer la red. Esto puede darse si el atacante

conoce detalles del �rmware de comunicación lo cual presenta una baja probabilidad de

ocurrencia (se estimó en 0,1%). El segundo caso, cuya probabilidad de ocurrencia es alta

(99,9%) hace referencia al establecimiento de la red WPAN con dispositivos autoriza-

dos. Establecer la comunicación inalámbrica con el nodo ofrece al ataque aprovechar otro

tipo de vulnerabilidades, tales como espionaje de la información (sni�ng) y ataques a

la disponibilidad del sistema a través de peticiones innecesarias suplantando un nodo

autenticado (DDoS). Si la actividad attackNetwork ubica un token en algun lugar que

representa una amenaza, inmediatamente un token es ubicado en el lugar de evaluación

de la variable de premio, denominado compromizedData. De lo contrario la comunicación

se considera segura y se procede a modelar el envío de otro paquete de información. Las

compuertas de entrada IG1 y IG2 son con�guradas para realizar cambios generales en

la marcación del sistema permitiendo modelar el envío de 900 tramas de datos por hora

y el envío de tramas beacon cada 250 ms. En la Tabla 4.16 se presentan las funciones de

entrada y los predicados habilitadores.


Figura 4.19: Módelo atómico SAN del nodo HealTICa sin incluir mecanismos deseguridad para evaluar la probabilidad de intrusión.

Compuerta

de

entrada

Predicado habilitador Función de entrada

IG1(txSecured->Mark()==1)||(deviceRejected->Mark()==1)

txSecured->Mark()=0;deviceRejected->Mark()=0;initWBAN->Mark()=1;

IG2(beaconInsecureDev->Mark()==1)||(sni�ng->Mark()==1)||(DDoS->Mark()==1)

beaconInsecureDev->Mark()=0;sni�ng->Mark()=0;DDoS->Mark()=0;initWBAN->Mark()=1;dataCompromized->Mark()=1;

Tabla 4.16: Predicados habilitadores y funciones de entrada de las compuertas deentrada para el modelo atómico de seguridad del nodo HealTICa sin mecanismos de

seguridad

Una vez planteado el modelo SAN para la comunicación inalámbrica sin mecanismos de

seguridad, se procedió a construir el modelo SAN que incluyera dichos mecanismos y

poder contrastar los resultados correspondientes a la probabilidad de intrusión maliciosa

al sistema con respecto al tiempo. En la Figura 4.20 se presenta el modelo SAN con

mecanismos de cifrado y veri�cación de autenticación a través delMessage Integrity Code,

MIC. Para modelar el cifrado y la veri�cación de autenticidad se adicionó al modelo de la

Figura 4.19 la actividad denominada decipherFrame que representa el tiempo necesario

para decifrar un frame y la probabilidad de hacerlo si no se cuenta con la llave de cifrado.

También se incluyó la actividad blackListedDevice que representa la medida que toma

la capa MAC del protocolo IEEE 802.15.4 al identi�car la recepción de mensajes cuyo

MIC no coincide con el esperado. La dirección de estos dispositivos es almacenada en una

lista donde se restringe la comunicación con el intruso. Se consideró una probabilidad de

romper el algoritmo de cifrado de 3 ×10−8. Aunque este valor es mucho menor de acuerdo

a [50], por efectos prácticos se de�nió de esta manera. En la Tabla 4.17 se presentan las



OG1

if((dataCompromized->Mark()==1)||(DDoS->Mark()=1;)){dataCompromized->Mark()=1;initComm-Mark()=1;}

OG2deviceRejected->Mark()=1;DDoS->Mark()=0;

Tabla 4.17: Funciones de salida en el modelo SAN con mecanismos de seguridad delnodo HealTICa

funciones de salida de las compuertas adicionadas al modelo de la Figura 4.20.

Figura 4.20: Módelo atómico SAN del nodo HealTICa con mecanismos de seguridadpara evaluar la probabilidad de intrusión.

Finalmente, se presentan los resultados de la simulación en la Figura 4.21. En la Figura

se diferencian los modelos sin seguridad (noSecurity) y con mecanismos de seguridad

(securityMechanisms), evidenciándose un comportamiento preocupante en la probabili-

dad de un intrusión exitosa en la comunicación que no cuenta con mecanismos de segu-

ridad. En solo 60 horas un atacante tiene una probabilidad superior al 80% de acceder a

la información médica del paciente. Esto en gran medida es ocasionado por la facilidad

de obtener datos del canal inálambrico si estos carecen de mecanismos de cifrado. Entre

tanto, la diferencia de los valores de probabilidad para la comunicación que incluye los

mecanismos de cifrado y veri�cación de integridad son evidentes, pues tras 60 horas de

intentos de intrusión alcanza un 20% y esto considerando que la probabilidad real de

romper el algoritmo AES es mucho mayor, pero por efectos de facilidad al momento de

simular se redujo. Con esto queda mas que claro que la inclusión de los mecanismos de

cifrado al �rmware del nodo HealTICa altamente efectivos y permiten dar cumplimiento

a los requerimientos CS1, CS3, CS4, CS9 y CS10, referentes a la necesidad de garan-

tizar la con�dencialidad, integridad y autenticidad de la información médica adquirida

por el nodo HealTICa.


securityMechanismnoSecurity

Tiempo [horas]

Prob

abili

dad

de I

ntru

sión

Figura 4.21: Evaluación del porcentaje mínimo requerido para realizar de forma �abley garantizar disponibilidad del nodo sensor de monitorización

Los resultados obtenidos con el formalismo SAN han permitido evaluar la efectividad

de la arquitectura de con�abilidad y seguridad propuesta y descrita en el capítulo 3. Se

demostró a través de escenarios de uso típico del sistema que la arquitectura satisface

el objetivo de incrementar los valores de �abilidad, disponibilidad y seguridad del nodo

HealTICa con respecto al tiempo de uso del sistema. Con lo anterior se da por logrado

el último objetivo especi�co planteado para este trabajo de investigación, referente a

evaluar la efectividad arquitectura en escenarios controlados.

Capítulo 5

Conclusiones y Trabajos Futuros

5.1. Conclusiones

En este trabajo de investigación se presentó el análisis de las propiedades de con�abilidad

y seguridad de un nodo sensor para la monitorización remota de pacientes en condición

de hospitalización domiciliaria. El análisis fue iniciado con la identi�cación de atributos,

riesgos y amenazas, reportando en el documento la descripción de las estrategias, aná-

lisis y conclusiones de los resultados obtenidos. Cabe resaltar el uso en la identi�cación

de requerimientos no funcionales asociados a las propiedades de interés de estrategias de

co-creación e ideación para el diseño y desarrollo de productos de innovación, la cual es re-

sultado de investigaciones anteriores realizadas por el grupo de investigación SISTEMIC

(Sistemas Embebidos e Inteligencia Computacional) y que han sido depuradas y mejo-

radas para obtener información de alto valor técnico a partir de sesiones realizadas con

los diferentes interesados del proyecto (stakeholders). Se destaca la colaboración en esta

actividad del personal médico y administrativo de la IPS universitaria de la Universidad

de Antioquia e ingenieros del grupo de excelencia ARTICA. El uso de está estrategia

permitió desde la etapa de diseño identi�car los puntos críticos del sistema referentes a

las propiedades de con�abilidad y seguridad y realizar un planteamiento temprano de

mecanismos que permiten mitigar la probabilidad de ocurrencia de fallas que incumplan

con las expectativas y necesidades del usuario �nal.

En cuanto a los requerimientos relacionados con la seguridad eléctrica del nodo sensor

inalámbrico, el análisis de la norma IEC 60601 permitió establecer los requerimientos

funcionales a nivel de hardware y software necesarios para cumplir con lo establecido en la

norma y de�nir con los ingenieros encargados del desarrollo de hardware los componentes

y consideraciones a cumplir. Gracias a esto el hardware del nodo sensor inalámbrico

fue desarrollado considerando técnicas de diseño de circuitos impresos que disminuyen

83

Capitulo 5. Conclusiones y Trabajos Futuros 84

el riesgo de corrientes de fuga y el desarrollo de una carcasa desarrollada en material

dielectrico que permite un nivel de aislamiento eléctrico acorde a las exigencias de la

norma, eliminando cualquier riesgo eléctrico. Además de lo anterior, se dio pie a al

desarrollo de algoritmos para el cálculo de la frecuencia respiratoria de manera indirecta,

pues el método de inyección de corriente requiere de dispositivos electrónicos con altos

niveles de con�abilidad y la aprobación de estrictas evaluaciones con muy bajo margen

de error, que fueron necesarias al eliminar la inyección voluntaria de corriente.

La arquitectura propuesta a partir de los requerimientos identi�cados en el análisis de las

propiedades de con�abilidad y seguridad en la etapa de diseño fue presentada utilizando

diagramas de alto nivel que facilitaron el desarrollo e implementación del prototipo. Ade-

más, el uso de patrones de diseño encauzados a incrementar la con�abilidad del software

fue exitoso debido a la posibilidad de implementar software de bajo nivel abstrayendo el

paradigma de programación orientada a objetos, y permitiendo dimensionar el �rmware

a través de la implementación de clases, métodos y por supuesto, objetos.

La evaluación de la con�abilidad y la seguridad se realizo a través de la técnica de re-

des de actividad estocástica, con los cuales se construyeron modelos de alto nivel que

facilitaron la evaluación de la con�abilidad y seguridad de los nodos sensores con y sin

la inclusión de la arquitectura de con�abilidad y seguridad. De esta manera, se evaluó

de manera cuantitativa su efectividad sobre los atributos no funcionales del sistema co-

mo la �abilidad, disponibilidad y con�dencialidad de la arquitectura propuesta. En la

búsqueda realizada en la literatura se identi�có una gran ausencia de reportes cientí�cos

donde se plasmara la evaluación de la con�abilidad y seguridad en redes WBAN, con

lo cual es un aporte de está investigación el uso de el formalismo SAN como técnica de

evaluación de estas propiedades. Los resultados obtenidos son promisorios y permiten

validar la efectividad de los mecanismos propuestos en términos de la reducción de la

probabilidad de fallos respecto al tiempo y la predicción de la disponibilidad del sistema.

En los resultados se observan incrementos notables en los valores de �abilidad, disponibi-

lidad y con�dencialidad. Se concluye que el sistema cuenta con una autonomía su�ciente

para realizar sesiones de adquisición de señal por periodos mayores a los establecidos en

los requerimientos funcionales, y con la inclusión de los mecanismos de con�abilidad y

seguridad se garantiza una alta probabilidad de uso correcto del sistema sin intervención

técnica por un periodo mínimo de 5 meses, que corresponde a 1.000 horas con un uso

promedio de 6 horas diarias.

Capitulo 5. Conclusiones y Trabajos Futuros 85

5.2. Publicación derivada de este trabajo

Como resultado de este trabajo de investigación fue sometido y aceptado para publica-

ción y presentación oral, el artículo titulado Dependability Evaluation of WBAN-based

Home Healthcare Systems using Stochastic Activity Networks, en el congreso HIMS'16 -

The 2nd International Conference on Health Informatics and Medical Systems a reali-

zarse en la ciudad de las Vegas del 25 al 28 de julio de 2016.

El nodo sensor inalámbrico desarrollado en este macroproyecto y en el cual está en-

marcado el presente trabajo de investigación, conjunto con los demás módulos que los

componen, se encuentran en proceso de registro de propiedad intelectual.

5.3. Trabajos Futuros

Los resultados obtenidos en este trabajo sirven como punto de partida para investigacio-

nes enmarcadas en el diseño y desarrollo de dispositivos médicos de atención domiciliaria

con�ables y seguros. A partir de esto es posible impulsar trabajos de investigación que

se enfoquen en complementar la técnica de evaluación de redes de actividad estocástica

(SAN), al tener en cuenta la inclusión de otros factores referentes al protocolo de comu-

nicación inalámbrico IEEE 802.15.4, ya que en este trabajo solo se consideró la in�uencia

de sobre la con�abilidad y seguridad del algoritmo de acceso al medio. Además, es im-

portante tener en cuenta la posibilidad de incluir dentro de la arquitectura mecanismos

mas so�sticados de tolerancia a fallos, tales como la redundancia homogénea, permi-

tiendo incrementar los valores de �abilidad y disponibilidad del sistema. Finalmente, se

identi�có como trabajo futuro la posibilidad del desarrollo de algoritmos que permitan

la autenticación del usuario a partir del análisis de señales biomédicas adquiridas por el

nodo sensor, las cuales son únicas para cada persona.

Bibliografía

[1] OMS Organización Mundial para la Salud. Temas de salud - Enfermedades crónicas.

http://www.who.int/topics/chronic_diseases/es/, 2008.

[2] Ministerio de salud y protección social o�cina de promoción so-

cial. Envejecimiento demográ�co en Colombia 1951-2020, dinámi-

ca demográ�ca y estructuras poblacionales, 2013. URL https://www.

minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/DE/PS/

Envejecimiento-demografico-Colombia-1951-2020.pdf.

[3] Juan Franco, Jose Aedo, and Fredy Rivera. Continuous, non-invasive and cu�-

free blood pressure monitoring system. In Andean Region International Conference

(ANDESCON), 2012 VI, pages 31�34. IEEE, 2012.

[4] F. Rivera J. Olarte, J. Aedo. Diseño de nodos sensores para apoyo médico en

situaciones críticas. In XXII Workshop Iberchip, 2016.

[5] F. Rivera J. Arboleda, J. Aedo. Wireless system for supporting home health care

of chronic disease patients. In The 2016 IEEE Colombian Conference on Commu-

nications and Computing (IEEE COLCOM), 2016.

[6] Guang He Zhang, Carmen Chung Yan Poon, and Yuan Ting Zhang. A review on

body area networks security for healthcare. ISRN Communications and Networking,

2011:21, 2011.

[7] Sana Ullah, KHAN Pervez, Niamat Ullah, Shahnaz Saleem, Henry Higgins,

Kyung Sup Kwak, et al. A review of wireless body area networks for medical

applications. Int'l J. of Communications, Network and System Sciences, 2(08):797,

2009.

[8] Ming Li, Wenjing Lou, and Kui Ren. Data security and privacy in wireless body

area networks. IEEE Wireless Communications, 17(1):51�58, 2010.

[9] Karandeep Malhi, Subhas Chandra Mukhopadhyay, Julia Schnepper, Mathias Haef-

ke, and Hartmut Ewald. A zigbee-based wearable physiological parameters monito-

ring system. Sensors Journal, IEEE, 12(3):423�430, 2012.

86

http://www.who.int/topics/chronic_diseases/es/

https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/DE/PS/Envejecimiento-demografico-Colombia-1951-2020.pdf



Bibliografía 87

[10] Sergio Saponara, Massimiliano Donati, Tony Bacchillone, Luca Fanucci, Isabel

Sanchez-Tato, Cristina Carmona, and Pierluigi Barba. Remote monitoring of vi-

tal signs in patients with chronic heart failure: Sensor devices and data analysis

perspective. In Sensors Applications Symposium (SAS), 2012 IEEE, pages 1�6.

IEEE, 2012.

[11] Mehmet R Yuce. Implementation of wireless body area networks for healthcare

systems. Sensors and Actuators A: Physical, 162(1):116�129, 2010.

[12] Yasmin Hovakeemian, Kshirasagar Naik, and Amiya Nayak. A survey on dependa-

bility in body area networks. In Medical Information & Communication Technology

(ISMICT), 2011 5th International Symposium on, pages 10�14, 2011.

[13] Algirdas Aviºienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr. Basic

concepts and taxonomy of dependable and secure computing. Dependable and Secure

Computing, IEEE Transactions on, 1(1):11�33, 2004.

[14] Ivanovitch Silva, Luiz A�onso Guedes, Paulo Portugal, and Francisco Vasques. Re-

liability and availability evaluation of wireless sensor networks for industrial appli-

cations. Sensors, 12(1):806�838, 2012.

[15] Marcello Cinque, Domenico Cotroneo, Catello Di Martinio, and Stefano Russo. Mo-

deling and assessing the dependability of wireless sensor networks. In Reliable Dis-

tributed Systems, 2007. SRDS 2007. 26th IEEE International Symposium on, pages

33�44, 2007.

[16] An Liu and Peng Ning. Tinyecc: A con�gurable library for elliptic curve crypto-

graphy in wireless sensor networks. In Information Processing in Sensor Networks,

2008. IPSN'08. International Conference on, pages 245�256. IEEE, 2008.

[17] Wannarit Khattiya, Sekson Timakul, and Somsak Choomchuay. An error control

coding in mac layer for uwb wban. In Signal Processing, Communication and Com-

puting (ICSPCC), 2013 IEEE International Conference on, pages 1�5. IEEE, 2013.

[18] KM Sharmilee, Rajeswari Mukesh, A Damodaram, and V Subbiah Bharathi. Secure

wban using rule-based ids with biometrics and MAC authentication. In e-health

Networking, Applications and Services, 2008. HealthCom 2008. 10th International

Conference on, pages 102�107. IEEE, 2008.

[19] ARTICA. Reporte técnico interno: Resultados �nales del proyecto de co-creación,

2014.

[20] Huber Morales, María Plested, and José Aedo Cobo. El coco-game un juego de mesa

para co-crear, potenciación del trabajo colaborativo y creativo. Enl@ce: Revista

Venezolana de Información, Tecnología y Conocimiento, 12(1), 2015.

Bibliografía 88

[21] Huber Hernando Morales. Co-creación: Diálogo activo con grupos de interés. 2014.

[22] IPS Universitaria. Ips universitaria universidad de antioquia. http://www.

ipsuniversitaria.com.co/en/about-us, 2016.

[23] Switzerland IEC, International Electrotechnical Commission: Geneva. 60601-1 me-

dical electrical equipment-part 1: General requirements for basic safety and essential

performance, 2012.

[24] Antonio José Salazar Gómez and Diana Katherine Cuervo Ramírez. Protocolo de

pruebas de seguridad eléctrica para equipos electro-médicos: caso de estudio de

equipos de telemedicina. Revista de Ingeniería, (38):27�32, 2013.

[25] International Electrotechnical Commission et al. Iec en 60601-1-2. Medical elec-

trical equipment. Part 1: General requirements for safety. 2. Collateral standard:

electromagnetic compatibility. Requirements and tests, 2007.

[26] Antonio José Salazar Gómez and Diana Katherine Cuervo Ramírez. Protocolo de

ensayos de emisiones radiadas en equipos médicos: caso de estudio de equipos de

telemedicina. Revista Facultad de Ingeniería Universidad de Antioquia, (65):33,

2012.

[27] Dresden Elektronik. Radio modules derfmega256 23m00 | 23m10. http:

//www.dresden-elektronik.de/fileadmin/Downloads/Dokumente/Produkte/1_

Funkmodule/1_2__OEM_Module/deRFmega128-22M12-DBT-en.pdf, 2013.

[28] International Electrotechnical Commission et al. Iec 61025 fault tree analysis, 1990.

[29] Andrew J Kornecki and Mingye Liu. Fault tree analysis for safety/security veri�ca-

tion in aviation software. Electronics, 2(1):41�56, 2013.

[30] Tod Courtney, Shravan Gaonkar, Ken Keefe, Eric WD Rozier, and William H San-

ders. Möbius 2.3: An extensible tool for dependability, security, and performance

evaluation of large and complex system models. In Dependable Systems & Networks,

2009. DSN'09. IEEE/IFIP International Conference on, pages 353�358, 2009.

[31] ARTICA Alianza Regional de TICs Aplicadas. Plataforma tecnológica para los

servicios de teleasistencia, emergencias médicas, seguimiento y monitoreo de perma-

nente a los pacientes y apoyo a los programas de promoción y prevención - eje 3:

Vigilancia de eventos de riesgo para pacientes crónicos. 2012.

[32] Michael Mahemo�, Andrew Hussey, and Lorraine Johnston. Pattern-based reuse

of successful designs: usability of safety-critical systems. In Software Engineering

Conference, 2001. Proceedings. 2001 Australian, pages 31�39. IEEE, 2001.

http://www.ipsuniversitaria.com.co/en/about-us

http://www.ipsuniversitaria.com.co/en/about-us

http://www.dresden-elektronik.de/fileadmin/Downloads/Dokumente/Produkte/1_Funkmodule/1_2__OEM_Module/deRFmega128-22M12-DBT-en.pdf



Bibliografía 89

[33] Bruce Powel Douglass. Design patterns for embedded systems in C: an embedded

software engineering toolkit. Elsevier, 2010.

[34] Jyoti Wadhwani and Nitin Narkhede. Implementation of communication using cyclic

redundancy check. 2013.

[35] Ashraf Armoush. Design Patterns for Safety-Critical Embedded Systems. Tesis

doctoral en ciencias de ingeniería, RWTH Aachen University, 2010.

[36] Ashraf Armoush. Design patterns for safety-critical embedded systems. PhD thesis,

RWTH Aachen University, 2010.

[37] Ramesh Kumar. State Of The Art : Security In Wireless Body Area Networks. Int.

J. Comput. Sci. Eng. Technol., pages 622�630, 2013.

[38] Shahnaz Saleem, Sana Ullah, and Kyung Sup Kwak. A study of ieee 802.15. 4

security framework for wireless body area networks. Sensors, 11(2):1383�1395, 2011.

[39] Naveen Sastry and David Wagner. Security considerations for ieee 802.15. 4 net-

works. In Proceedings of the 3rd ACM workshop on Wireless security, pages 32�42.

ACM, 2004.

[40] IEEE 802.15.4. Wireless medium access control (MAC) and physical layer (PHY)

speci�cations for low-rate wireless personal area networks (LR-WPANs). IEEE,

2006.

[41] Kaisa Nyberg and Howard Heys. Selected Areas in Cryptography: 9th Annual Inter-

national Workshop, SAC 2002, St. John's, Newfoundland, Canada, August 15-16,

2002, Revised Papers, volume 9. Springer Science & Business Media, 2003.

[42] William H Sanders and Luai M Malhis. Dependability evaluation using composed

SAN-based reward models. Journal of parallel and distributed computing, 15(3):

238�254, 1992.

[43] William H Sanders and John F Meyer. Stochastic activity networks: Formal de�ni-

tions and concepts. In Lectures on Formal Methods and PerformanceAnalysis, pages

315�343. 2001.

[44] NJ PISCATAWAY. Wireless LAN medium access control (MAC) and physical layer

(PHY) speci�cations. IEEE P802. 11 D3, 1996.

[45] Anis Koubaa, Mário Alves, Eduardo Tovar, and Ye-Qiong Song. On the performance

limits of slotted CSMA/CA in IEEE 802.15.4 for broadcast transmissions in wireless

sensor networks. 2006.

Bibliografía 90

[46] Seung-Wook Eom, Min-Kyu Kim, Ick-Jun Kim, Seong-In Moon, Yang-Kook Sun,

and Hyun-Soo Kim. Life prediction and reliability assessment of lithium secondary

batteries. Journal of Power Sources, 174(2):954�958, 2007.

[47] Texas Instrument. DPPM/FIT/MTBF estimator part number ADS1294R.

http://www.ti.com/quality/docs/estimator.tsp?OPN=ADS1294RIZXGR&CPN=

&partNumber=ads1294r#resultstable, 2013.

[48] Atmel. Reliability monitor report. http://www.atmel.com/Images/Relmtrq2-16.

pdf, 2016.

[49] Chieh-Jan Mike Liang, Nissanka Bodhi Priyantha, Jie Liu, and Andreas Terzis.

Surviving wi-� interference in low power zigbee networks. In Proceedings of the 8th

ACM Conference on Embedded Networked Sensor Systems, pages 309�322. ACM,

2010.

[50] Atmel. Application note AVR2027: AES security module. http://www.atmel.com/

Images/doc8260.pdf, 2009.

http://www.ti.com/quality/docs/estimator.tsp?OPN=ADS1294RIZXGR&CPN=&partNumber=ads1294r#resultstable

http://www.ti.com/quality/docs/estimator.tsp?OPN=ADS1294RIZXGR&CPN=&partNumber=ads1294r#resultstable

http://www.atmel.com/Images/Relmtrq2-16.pdf

http://www.atmel.com/Images/Relmtrq2-16.pdf

http://www.atmel.com/Images/doc8260.pdf

http://www.atmel.com/Images/doc8260.pdf

consideraciones de seguridad y confiabilidad para la...

Documents