SISTEMAS OPERATIVOS CAPITULO 20 PARTE 1

¿Qué significa que el software esté «embebido» en un sistema, según el capítulo?. Que el software se encuentra integrado en el hardware del sistema, con frecuencia en memoria de solo lectura, y responde en tiempo real a eventos del entorno. Que el software se ejecuta exclusivamente en la nube y nunca interactúa de forma directa con el hardware. Que el software solo puede actualizarse mediante una reinstalación completa del sistema operativo anfitrión.

¿Qué se entiende por «tiempo real» en el contexto de un sistema embebido?. Que el sistema de software tiene un plazo para responder a eventos externos; si no se cumple, el sistema global no funcionará correctamente. Que el sistema procesa la información con la mayor rapidez posible, sin que existan plazos definidos. Que el sistema únicamente puede ejecutarse mientras el usuario mantiene una conexión activa a Internet.

Según la definición del capítulo, ¿qué distingue a un «sistema duro de tiempo real» de un «sistema blando de tiempo real»?. En el sistema duro, no producir resultados según la especificación de tiempo se considera una falla del sistema; en el blando, la operación solo se degrada. El sistema duro nunca requiere cumplir plazos, mientras que el blando debe cumplirlos siempre de forma estricta. Ambos términos son sinónimos y se usan indistintamente para describir cualquier sistema embebido.

¿Por qué es tan importante, desde el punto de vista económico, el software embebido según el capítulo?. Porque casi todos los dispositivos eléctricos incluyen software, por lo que existen muchos más sistemas embebidos que de otros tipos. Porque genera más ingresos que cualquier otro tipo de software de información o de oficina. Porque su desarrollo es obligatorio únicamente para los gobiernos y las fuerzas armadas.

¿Cuál de los siguientes se menciona como ejemplo de sistema embebido que NO requiere una respuesta muy rápida a eventos externos?. El software de una bomba de insulina, que verifica el nivel de glucosa a intervalos periódicos. El software de frenado antiderrapante de un automóvil. El manipulador de interrupciones de un sistema de adquisición de datos a alta velocidad.

Respecto a la operación continua de los sistemas embebidos, ¿qué característica se menciona en el capítulo?. Por lo general operan de manera continua, comenzando cuando el hardware se activa y ejecutándose hasta que éste se desactiva. Se diseñan siempre para detenerse automáticamente después de procesar el primer estímulo recibido. Nunca pueden actualizarse mientras están en servicio, a diferencia de los sistemas de información.

¿Cómo son las interacciones entre un sistema embebido de tiempo real y su entorno, en comparación con un sistema interactivo?. Son incontrolables e impredecibles, por lo que el sistema debe responder en cualquier momento a sucesos inesperados. Son completamente controlables, ya que el sistema decide cuándo y con qué frecuencia ocurren los eventos externos. Son idénticas, pues ambos tipos de sistema regulan el ritmo de interacción de la misma manera.

¿Qué tipo de limitaciones físicas pueden afectar el diseño de un sistema embebido, según el capítulo?. Limitaciones en la energía disponible y en el espacio físico que ocupa el hardware. Limitaciones exclusivamente relacionadas con el precio de las licencias de software utilizadas. Limitaciones relacionadas únicamente con el idioma en que se programa el sistema.

¿Por qué los conflictos de protección y fiabilidad suelen dominar el diseño de un sistema embebido?. Porque muchos sistemas embebidos controlan dispositivos cuyas fallas pueden tener altos costos humanos o económicos. Porque estos sistemas nunca se someten a pruebas antes de su despliegue final. Porque el hardware embebido es siempre más barato que el software que lo controla.

Según Berry y Lee, ¿por qué se considera a los sistemas embebidos como «sistemas reactivos»?. Porque deben reaccionar ante los eventos a la velocidad de su entorno, regida con frecuencia por las leyes de la física. Porque reaccionan únicamente ante comandos directos escritos por el usuario en una interfaz gráfica. Porque su velocidad de respuesta depende exclusivamente de la conveniencia humana, igual que un procesador de texto.

¿Por qué el proceso de diseño de software para sistemas embebidos se considera un proceso de ingeniería de sistemas?. Porque los diseñadores de software deben considerar a detalle el diseño y el rendimiento del hardware del sistema. Porque el software embebido nunca interactúa con ningún componente de hardware específico. Porque se elabora exclusivamente a partir de especificaciones legales, sin ninguna consideración técnica.

¿Por qué resulta poco práctico, en la mayoría de los sistemas de tiempo real, un proceso de diseño de software puramente descendente (top-down)?. Porque las decisiones de bajo nivel en hardware, software de soporte y temporización deben considerarse desde el inicio del proceso. Porque los sistemas de tiempo real jamás requieren tomar en cuenta las restricciones de hardware disponibles. Porque el enfoque descendente está prohibido explícitamente por los estándares internacionales de tiempo real.

Según el modelo estímulo-respuesta usado en el diseño de sistemas embebidos, ¿qué es un «estímulo»?. Un evento que ocurre en el entorno del sistema de software y que hace que el sistema reaccione de alguna forma. Una señal que el software envía siempre hacia su entorno para modificarlo intencionalmente. Un mensaje de error que solo se genera cuando el sistema detecta una falla catastrófica.

¿Cuál es la diferencia entre un estímulo periódico y uno no periódico?. El periódico ocurre a intervalos predecibles; el no periódico ocurre de manera irregular e impredecible, y suele señalarse mediante interrupciones. El periódico siempre proviene de un actuador, mientras que el no periódico siempre proviene de un sensor. Ambos tipos de estímulo son idénticos en cuanto a su previsibilidad, y solo cambia el nombre que reciben.

En el modelo general de un sistema embebido de tiempo real (sensores ® sistema de control ® actuadores), ¿qué lineamiento de diseño se sugiere para cada tipo de sensor y actuador?. Tener dos procesos independientes para cada tipo de sensor y actuador: uno de gestión del sensor y otro de control del actuador. Combinar obligatoriamente todos los sensores y actuadores en un único proceso monolítico sin excepción. Eliminar cualquier proceso de control de actuador, dejando que el hardware actúe sin intervención del software.

¿Cuál de las siguientes NO se menciona como una actividad del proceso de diseño de software de tiempo real descrito en el capítulo?. Selección de plataforma, identificación de estímulos/respuestas y análisis de temporización. Certificación notarial del código fuente ante una autoridad gubernamental antes de iniciar el diseño. Diseño de procesos, diseño de algoritmo, diseño de datos y planeación del proceso.

¿Qué mecanismos se mencionan en el capítulo para probar la exclusión mutua sobre recursos compartidos entre procesos?. Semáforos (Dijkstra), monitores (Hoare) y regiones críticas (Brinch-Hansen). Exclusivamente contraseñas de usuario que restringen el acceso a los recursos compartidos. Firewalls de red configurados específicamente para separar los procesos del sistema operativo.

¿Por qué se implementa el intercambio de información entre procesos productor y consumidor mediante un buffer circular compartido?. Para evitar que la información se sobrescriba antes de leerse o que se lea dos veces, acomodando diferencias de velocidad entre los procesos. Para garantizar que el proceso productor y el consumidor se ejecuten siempre exactamente a la misma velocidad. Para eliminar por completo la necesidad de cualquier mecanismo de sincronización entre procesos.

¿Por qué se usan comúnmente los modelos de estado para describir sistemas de tiempo real?. Porque los eventos a los que debe reaccionar el sistema causan con frecuencia que éste se mueva de un estado a otro. Porque los modelos de estado son el único formalismo aceptado legalmente en el desarrollo de software embebido. Porque eliminan por completo la necesidad de identificar estímulos y respuestas en el sistema.

En un modelo de máquina de estado, ¿qué representan los rectángulos redondeados y qué representan las flechas?. Los rectángulos redondeados representan estados del sistema; las flechas representan estímulos que fuerzan una transición de un estado a otro. Los rectángulos representan procesadores físicos; las flechas representan cables de conexión eléctrica entre ellos. Los rectángulos representan actuadores; las flechas representan exclusivamente errores del sistema.

¿Qué formalismo del UML soporta el desarrollo de modelos de estado jerárquicos según el capítulo?. Los diagramas de estado (statecharts) de Harel, que permiten que grupos de estados se consideren como una sola entidad. Los diagramas de despliegue, que describen exclusivamente la ubicación física del hardware. Los diagramas de casos de uso, que se emplean únicamente para especificar requerimientos funcionales.

En el ejemplo del sistema de entrega de combustible (bomba de gasolina) modelado con máquina de estado, ¿qué ocurre después de que el comprador retira la tarjeta de crédito del lector?. Se activa una transición hacia el estado Validar, donde se valida la tarjeta. El sistema pasa directamente al estado Entregar sin ninguna validación previa de la tarjeta. El sistema regresa de inmediato al estado Espera, cancelando toda la operación.

¿Para qué se pueden usar los modelos de estado dentro de la ingeniería dirigida por modelo, según el capítulo?. Para definir la operación de un sistema, pudiendo transformarse automáticamente en un programa ejecutable. Únicamente para fines de documentación histórica, sin ninguna relación con el código fuente del sistema. Exclusivamente para describir la arquitectura física de red de un sistema distribuido.

¿Por qué los sistemas de tiempo real duros en ocasiones todavía se programan en lenguaje ensamblador?. Para poder cumplir con los plazos ajustados que exige el sistema. Porque los lenguajes de alto nivel están prohibidos legalmente en cualquier sistema embebido. Porque el ensamblador es el único lenguaje capaz de acceder al hardware del sistema.

¿Cuál es una desventaja de usar un lenguaje de programación de sistemas como C para el desarrollo de sistemas de tiempo real?. No incluye sentencias para soportar concurrencia o gestión de recursos compartidos, por lo que estas deben implementarse mediante llamadas al sistema operativo de tiempo real. Genera código significativamente menos eficiente que cualquier lenguaje orientado a objetos. No permite en ningún caso el acceso directo al hardware del sistema embebido.

¿Por qué el desarrollo orientado a objetos puede no ser adecuado para sistemas de tiempo real duros, según el capítulo?. Porque implica una carga adicional de rendimiento (código para mediar el acceso a atributos y manejar llamadas a operaciones) que puede impedir cumplir los plazos. Porque los lenguajes orientados a objetos no permiten definir ningún tipo de estructura de datos compartida. Porque la programación orientada a objetos fue diseñada exclusivamente para sistemas de información empresarial.

¿Qué modificación se incluyó en la versión de Java diseñada para sistemas embebidos (Real-Time Java), según el capítulo?. Un mecanismo de hilo modificado que permite especificar hilos que no se interrumpen por el recolector de basura del lenguaje. La eliminación completa del manejo de eventos asíncronos, ya que no son necesarios en tiempo real. La sustitución total del lenguaje Java por instrucciones en lenguaje ensamblador puro.

Según el capítulo, ¿en qué tipo de plataformas se ha usado principalmente Real-Time Java hasta el momento de escribirse el libro?. En plataformas con capacidad representativa de procesador y memoria, como un teléfono celular, y no en sistemas embebidos más simples. Exclusivamente en supercomputadoras dedicadas a cálculos científicos de gran escala. En todos los sistemas embebidos sin excepción, sustituyendo por completo el uso de C.

¿Qué nuevo modelo de gestión de memoria se incluyó en Real-Time Java para evitar demoras impredecibles?. Un modelo que evita las demoras impredecibles que pueden resultar de la recolección de basura convencional. Un modelo que elimina cualquier tipo de asignación dinámica de memoria en tiempo de ejecución. Un modelo que requiere reiniciar el sistema completo cada vez que se libera un bloque de memoria.

¿Por qué los patrones arquitectónicos de los sistemas embebidos difieren de los estudiados en el capítulo 6 para sistemas interactivos?. Porque los patrones de los sistemas embebidos están orientados a procesos, más que a objetos o componentes. Porque los sistemas embebidos nunca requieren ningún tipo de patrón arquitectónico formal. Porque los patrones del capítulo 6 solo pueden aplicarse a sistemas de tiempo real duro.

¿Cómo debe entenderse un patrón arquitectónico, según el capítulo?. Como un punto de partida para comprender una arquitectura y crear un diseño arquitectónico específico, no como un diseño genérico a copiar directamente. Como una plantilla de diseño final que debe implementarse literalmente sin ninguna modificación. Como un estándar obligatorio impuesto por los fabricantes de hardware para cualquier sistema embebido.

¿Cuáles son los tres patrones arquitectónicos de tiempo real analizados en el capítulo?. Observar y reaccionar, Control ambiental y Segmentación de proceso (process pipeline). Cliente-servidor, Componentes distribuidos y Peer-to-peer. Maestro-esclavo, Repositorio y Tubería y filtro exclusivamente para sistemas interactivos.

¿Cuándo se utiliza el patrón Observar y Reaccionar, según su descripción en el capítulo?. Cuando un conjunto de sensores se monitoriza y despliega de manera rutinaria, y el sistema reacciona al detectar cierto evento. Únicamente cuando el sistema no cuenta con ningún tipo de sensor ni actuador. Exclusivamente en sistemas que transforman datos de una representación a otra mediante una secuencia de pasos.

¿Cuáles son los procesos típicos del patrón Observar y Reaccionar, según la figura del capítulo?. Observador, Análisis, Despliegue, Alarma y Reactor. Productor, Buffer y Consumidor exclusivamente. Monitor, Control, Despliegue, Controlador de actuador y Monitor de actuador.

En el ejemplo del sistema de alarma antirrobos que usa el patrón Observar y Reaccionar, ¿qué ocurre si el sistema detecta una caída de voltaje?. Supone que intrusos interrumpieron el suministro eléctrico, por lo que se activa la alarma. El sistema se apaga por completo de inmediato sin realizar ninguna otra acción. Ignora la caída de voltaje, ya que este patrón no puede procesar estímulos relacionados con la energía.