Bachilleres:

Ramrez Anglica
Silva Zenaida
Call Edgar
Quezada Edgar
Barreto Vctor
Salazar Jos
org!n "arian

Ciudad ua#ana$ "a#o de %&'&
RE()B*+CA B,*+VAR+A-A .E VE-EZ/E*A
+-S0+0/0, /-+VERS+0AR+, (,*+01C-+C,
2SA-0+A, "AR+3,4
EXTENSIN GUAYANA
Sistemas en Tiempo Real
Es bien sabido que los Sistemas de Tiempo Real pueden llevar el control
eventos que ocurren en el mundo real, por lo tanto es un sistema que responde a
un estmulo externo dentro de un tiempo especificado.
Entonces los sistemas de tiempo real interactan con el entorno que se le
presente y pueden ejecutar acciones de respuesta para determinados estmulos
de dicho entorno.
Este tipo de sistemas tienen muchas caractersticas que benefician a todo
el individuo que pretenda interactuar con ellos.
!sicamente los sistemas de tiempo real se definen como sistemas
inform!ticos que tienen la capacidad de interactuar r!pidamente con su entorno
fsico, el cual puede reali"ar funciones de supervisi#n o control para su mismo
beneficio.
Todos los sistemas de tiempo real tienen la facultad de ejecutar actividades
o tareas en de intervalos de tiempo bien definidos.
Todas las tareas son ejecutadas inmediatamente en una forma concurrente, esto
es para sincroni"ar el funcionamiento del sistema con la simultaneidad de
acciones que se presentan en el mundo fsico.
En los sistemas de tiempo real los intervalos de tiempo en que se ejecutan
las tareas se definen por un esquema de activacin y por un plazo de ejecucin.
En lo que respecta al esquema de activaci#n puede ser peridico, es decir en
intervalos re$ulares, o tambi%n puede ser aperidico, es decir, en respuesta a
sucesos externos que ocurren de forma irre$ular.
&a mayora de los STR son utili"ados cuando existen requerimientos de
tiempo muy r$idos en las operaciones o en el flujo de datos, $eneralmente son
requeridos como sistemas de control en una aplicaci#n dedicada.
&a eficiencia de los STR no solo depende de la exactitud de los resultados
de c#mputo, sino tambi%n del momento en que los entre$a. &a predictibilidad es su
caracterstica principal de este tipo de sistemas.
Este tipo de sistemas se caracteri"an por tener que producir una salida,
como respuesta a una entrada, en un tiempo determinado. El intervalo de tiempo
que se presenta entre la entrada y la salida debe ser muy peque'o para que la
respuesta temporal del sistema sea aceptable.
(uando se dise'a un sistema de tiempo real se pasa por varias fases)
*.+ Se identifican todas las tareas que se tienen que reali"ar y tambi%n se
identifican las restricciones temporales que se pretenden cumplir.
,.+ -osteriormente se codifican los pro$ramas que ejecutar!n las tareas
..+ -osteriormente se pasa a medir el tiempo de c#mputo de cada tarea y se
reali"a un an!lisis de planificabilidad.
Este an!lisis consiste en aplicar unas pruebas al conjunto de tareas de tal forma
que si %stas pasan el test entonces se puede $aranti"ar que nin$una tarea perder!
su pla"o de ejecuci#n. /e lo contrario si no pasan el test se tiene que volver a
comen"ar desde el principio, es decir, comen"ar de nuevo, utili"ando otro
procesador m!s potente o utili"ando otros al$oritmos para implementar las tareas.
0eneralidades
Requiere t%cnicas de an!lisis, dise'o y prueba que son desconocidas en
otras !reas de aplicaci#n.
Esta muy acoplado con el mundo externo.
1pera bajo condiciones de rendimiento muy ri$urosas.
Esta conducido por el hard2are, soft2are, por las caractersticas del
sistema operativo, por requisitos de la aplicaci#n, as como por aspectos de
dise'o.
Elementos
3spectos de inte$raci#n y de rendimiento.
4anejo de 5nterrupciones.
ases de /atos de Tiempo Real.
Sistemas 1perativos de Tiempo Real.
&en$uajes de Tiempo Real.
Sincroni"aci#n y comunicaci#n de tareas.

Sistemas 1perativos de Tiempo Real
&os Sistemas 1perativos de tiempo real son la plataforma para establecer un
sistema de tiempo real ya que en los S1TR no tiene importancia el usuario, sino
los procesos.
3l$unos ejemplos de Sistemas 1perativos de tiempo real son)
a. 6x7or8s,
b.
c. Solaris, &yns 1S
d. Spectra
-or lo re$ular Sistema 1perativo de tiempo real suele tener la misma arquitectura
que un Sistema 1perativo convencional, pero su diferencia radica en que
proporciona mayor prioridad a los elementos de control y procesamiento que son
utili"ados para ejecutar los procesos o tareas.
a. El S1TR debe ser multitarea y permisible
b. 9n S1TR debe poder asi$nar prioridades a las tareas
c. El S1TR debe proporcionar medios de comunicaci#n y sincroni"aci#n entre
tareas
d. 9n S1TR debe poder evitar el problema de inversi#n de prioridades
e. El comportamiento temporal del S1TR debe ser conocido
(lasificaci#n
&os sistemas de tiempo real pueden ser de dos tipos, esto es en funci#n de su
severidad en el tratamiento de los errores que puedan presentarse)
Sistemas de tiempo real blandos o Soft real-time systems: estos pueden tolerar un
exceso en el tiempo de respuesta, con una penali"aci#n por el incumplimiento del
pla"o. Estos sistemas $aranti"an que las tareas crticas se ejecutan en tiempo.
3qu los datos son almacenados en memorias no vol!tiles, no utili"an t%cnicas de
memoria virtual ni tiempo compartido, estas t%cnicas no pueden ser
implementadas en hard2are.
Sistemas de tiempo real duros o Hard real-time systems: aqu la respuesta fuera
de t%rmino no tiene valor al$uno, y produce la falla del sistema. Estos sistemas
tienen menos utilidades que los implementados por hard, por ejemplo no pueden
utili"arse para control industrial y rob#tico. -ero si para multimedia, supervisi#n de
controles industriales y realidad virtual.
4%todos de /ise'o
(uando se elabora soft2are de tiempo real se deben incorporar una alta calidad.
3l elaborar el soft2are de tiempo real se presentan mltiples problemas como)
Representaci#n de interrupciones y cambio de contexto.
(omunicaci#n y sincroni"aci#n de tareas.
0randes variaciones en las tasas de datos.
Requisitos especiales para manejo de errores y recuperaci#n de fallos.
-rocesamiento asncrono.
-ara evitar muchos de los problemas que se presentan al elaborar soft2are de
tiempo real se han establecido al$unos m%todos como lo son)
*. 4etodolo$a de flujo de datos.
,.
.. 4etodolo$a de estructura de datos.
:. 4etodolo$a orientada a los objetos.
(aractersticas
(3R3(TER;ST5(3S -R543R53S (3R3(TER;ST5(3S SE(9</3R53S
-rocedimiento concurrente =iabilidad
5nterfa" hard2are Reconfi$urabilidad
Tiempo de reacci#n antes de los eventos 9sabilidad
3rquitectura distribuida 1bli$aciones
ases de datos (apacidad de evoluci#n
1tra (aracterstica
/ETER45<5S41 E< &1S STR
Este t%rmino es una parte fundamental en estos sistemas, podra decirse
que es una cualidad ya que es la capacidad de determinar con una alta
probabilidad, cuanto es el tiempo que tarda una tarea en iniciar, es decir,
que los STR necesitan que ciertas tareas se comiencen a ejecutar antes
que otras.
Requisitos Temporales
Tiempo real estricto (hard real-time)
> todas las acciones deben ocurrir dentro del pla"o especificado
? Ejemplo) control de vuelo
Tiempo real flexible (soft real-time)
> se pueden perder pla"os de ve" en cuando
> el valor de la respuesta decrece con el tiempo
? Ejemplo) adquisici#n de datos
Tiempo real firme (firm real-time)
> se pueden perder pla"os ocasionalmente
> una respuesta tarda no tiene valor
Respondivilidad
Este t%rmino se basa en el tiempo que tarda una tarea en ejecutarse. &a
responsividad se enfoca a . aspectos los cuales son)
*.
,. &a cantidad de tiempo que tarda iniciar la ejecuci#n de una interrupci#n
.. &a cantidad de tiempo que se necesita para reali"ar las tareas que pidi# la
interrupci#n.
:. &os efectos de 5nterrupciones anidadas.
9suarios (ontroladores
Todos los el usuario tienen un mejor control de todos los procesos que se ejecutan
en el sistema esto es)
a. &os procesos son capaces de especificar su prioridad
b. &os procesos son capaces de especificar el manejo de memoria que
requiere
c. &os procesos especifican que derechos tiene sobre el sistema.
(onfiabilidad
En los STR la confiabilidad jue$a un papel muy importante, ya que el sistema no
debe de presentar fallos, sino que m!s aun la calidad del servicio que ofre"ca no
debe de de$radarse m!s all! de un lmite especificado.
El sistema tiene que tener la capacidad de se$uir funcionando aunque se
presenten $randes cat!strofes, o fallos mec!nicos. -or lo $eneral una de$radaci#n
en el servicio en un STR lleva consecuencias catastr#ficas.
Tolerancia a =allos
3l hablar de tolerancia a los fallos nos estamos refiriendo a la capacidad de un
sistema de conservar la m!xima capacidad y los m!ximos datos posibles en caso
de un problema $rave que afecte a parte del sistema.
3l referirnos a la tolerancia a los fallos estamos hablando tambi%n de la estabilidad
ya que un sistema de tiempo real cuando le es imposible cumplir todos los pla"os
de ejecuci#n de las tareas que tenia asi$nado en ese momento, el sistema cumple
los pla"os de las tareas mas criticas y de mayor prioridad que hasta ese momento
se estaban ejecutando.
Entonces el sistema debe de fallar de manera que cuando se presente un
problema en el sistema conserve $ran parte de los datos y capacidades del
sistema en la mayor medida posible.
(aractersticas concretas)
*. Se presentan en entornos en donde deben ser aceptados y procesados una
$ran cantidad de sucesos, donde la mayora de estos sucesos son externos
al sistema computacional, con un tiempo de respuesta inmediato.
,. -ueden ser utili"ados en muchos !mbitos entre los cuales est!n en control
industrial, conmutaci#n telef#nica, control de vuelo, simulaciones en tiempo
real., aplicaciones militares @entre otrasA.
.. -roporciona r!pidos tiempos de respuesta.
:. (apacidad de procesar r!fa$as de miles de interrupciones por se$undo sin
perder un solo suceso.
B. El proceso que ten$a mayor prioridad expropia recursos.
C. &a mayora de los de procesos son est!ticos.
D. &a $esti#n de archivos se enfoca a velocidad de acceso que a la utili"aci#n
eficiente del recurso.
3plicaciones
&os sistemas de tiempo real pueden tener muchsimas y con el paso del tiempo y
el desarrollo de nuevas tecnolo$as sur$en nuevos campos de utili"aci#n para
estos sistemas.
&as !reas m!s comunes donde se aplican los servicios de un STR podran ser)
a.
b. &as telecomunicaciones
c. &os sistemas multimedia
d. El control industrial
e. &a rob#tica
f. &os sistemas de avi#nica y espaciales
$. &os ferrocarriles
h. 3utom#viles
i. Electrodom%sticos de nueva $eneraci#n
j. experimentos cientficos
8. sistemas m%dicos.
Se$uridad
0ran parte de los sistemas de tiempo real presentan requisitos de se$uridad muy
complicados, lo que da como resultado que la elaboraci#n o desarrollo de un STR
sea m!s complicada. Esto es que en al$unos casos no se puede permitir que
nin$una tarea se ejecute fuera del intervalo especificado ni una sola ve".
EntradaEsalida de los sistemas de tiempo real
(uando el procesamiento en tiempo real esta reali"ado, es necesario que la
interacci#n con los dispositivos externos sea tambi%n acotada en tiempo.
Entonces para establecer la transmisi#n de datos o informaci#n entre el sistema
de tiempo real, los sensores y actuadores que conforman al sistema, pueden
usarse diversas t%cnicas de buses de tiempo real, que ofrecen la oportunidad de
disponer de sensores inteli$entes.
Este tipo de sensores no solo tienen la capacidad de transmitir los datos que se
recolectaron, sino tambi%n poseen la capacidad de enviar la informaci#n del
instante que los datos fueron recolectados.
Ejemplos de protocolos de comunicaci#n que utili"an los STR los cuales tienen la
capacidad de reducir los tiempos de transmisi#n son los si$uientes)
El protocolo -3R @-ositive 3c8no2led$e or RetransmitA, 5mplicit =lo2 (ontrol,
(S43E(/ @(arrier Sense 4ultiple 3ccessE(ollision /etectionA, (3< @(ontrol 3rea
<et2or8A, To8enbus, (entral 4aster, y T/43+TT-.
Sistema multiproceso
3 pesar de las $randes mejoras acaecidas en monoprocesadores para
al$unas aplicaciones no es suficiente.
&a soluci#n pueden ser los sistemas multiprocesadores)
Soluci#n m!s sencilla, natural y con mejor coste+prestaciones.
&as mejoras en microprocesadores cada ve" son m!s complejas) cada avance
implica crecer en complejidad, potencia y superficie.
&enta pero clara mejora en el soft2are, que permite explotar el paralelismo.
&as arquitecturas actuales
son muy diversas) hay m!s investi$aci#n que resultados definitivos.
Fablaremos de multiprocesadores de peque'a y mediana escala
/os factores clave para la extensi#n de los 4ultiprocesadores
*. =lexibilidad) El mismo sistema puede usarse para un nico usuario
incrementado el rendimiento en la ejecuci#n de una nica aplicaci#n o para varios
usuarios y aplicaciones en un entorno compartido.
,. (oste+rendimiento) 3ctualmente estos sistemas se basan en procesadores
comerciales, por lo que su coste se ha reducido dr!sticamente. &a inversi#n m!s
fuerte se hace en la memoria y la red de interconexi#n.
(omo su nombre indica son aquellos sistemas operativos que est!n montados
sobre ordenadores que est!n compuestos por m!s de un procesador,
supon$amos un -( que en ve" de tener un -entium, tuviera dos o m!s -entium
conectados entre si dentro de la misma placa base, esto sera un sistema
multiprocesador.
(lasificaci#n
Sistemas monopro$ramados) Son los que solo permiten la ejecuci#n de un
pro$rama en el sistema, se instalan en la memoria y permanecen all hasta que
termine su ejecuci#n.
Sistemas multipro$ramados) Son aquellos que se basan en las t%cnicas de
multipro$ramaci#n, existen dos tipos)
4ultitarea apropiativa @preemptiveA) Se utili"a en sistemas operativos cuya
$esti#n es quitar el control del microprocesador al pro$rama que lo tiene.
4ultitarea cooperativa) El pro$rama tiene el control del microprocesador, el
sistema operativo no puede decidir quien usa el microprocesador.
Sistemas de multiprocesamiento) =ormado por varios microprocesadores.
/epende del tipo de trabajo y los objetivos que debe cumplir cada sistema para
dar el mejor servicio al usuario, se clasifican en)
-rocesamiento por lotes @batchA) (ada pro$rama reali"a un conjunto de pasos
secuenciales relacionados entre si
Tiempo compartido
El tiempo compartido se refiere a compartir un recurso de computaci#n
entre muchos usuarios por medio de la multitarea. Su introducci#n en los a'os
*GCH, y el sur$imiento como el modelo prominente de la computaci#n en los a'os
*GDH, representa un cambio importante en la historia de la computaci#n. 3l permitir
que un $ran nmero de usuarios interactuara simult!neamente en una sola
computadora, el tiempo compartido dram!ticamente baj# el costo del servicio de
computaci#n, mientras que al mismo tiempo haca la experiencia computacional
mucho m!s interactiva.
/ebido a que los primeros mainframes y minicomputadores eran
extremadamente costosos, era raramente posible permitir a un solo usuario el
acceso exclusivo a la m!quina para uso interactivo. -ero debido a que los
computadores en uso interactivo a menudo pasan mucho de su tiempo ocioso
esperando por la entrada del usuario, fue su$erido que mltiples usuarios podran
compartir una m!quina al asi$nar el tiempo ocioso de un usuario para servir a
otros usuarios.
El tiempo compartido se desarroll# al darse cuenta que mientras un usuario
solo era ineficiente, un $rupo $rande de usuarios juntos no lo era. Esto era debido
al patr#n de la interacci#nI en la mayora de los casos los usuarios entran
explosiones @r!fa$asA de informaci#n se$uidas por una lar$a pausa de inactividad,
pero un $rupo de usuarios trabajando al mismo tiempo si$nificara que las pausas
de un usuario en un momento determinado seran consumidas por la actividad de
los otros. /ado un tama'o de $rupo #ptimo, el proceso total poda ser muy
eficiente. Similarmente se podra conceder a otros usuarios, las peque'as
porciones de tiempo $astadas en esperar por el disco, la cinta, o la entrada de la
tarjeta de red.
&a implementaci#n de un sistema capa" de tomar provecho de esto sera
difcil. El procesamiento por lotes era realmente un desarrollo metodol#$ico
encima de los primeros sistemasI las computadoras todava corran simple
pro$ramas para simple usuarios en un momento determinado, todo lo que el
procesamiento por lotes cambi# fue el retardo de tiempo entre un pro$rama y el
si$uiente. /esarrollar un sistema que soportara mltiples usuarios al mismo
tiempo era un concepto totalmente diferente, el JestadoJ de cada usuario y sus
pro$ramas tendra que ser mantenidos en la m!quina, y lue$o cambiado entre
ellos r!pidamente. Esto tomara ciclos de la computadora, y en las m!quinas
lentas de la %poca esto era una preocupaci#n. Sin embar$o, a medida que las
computadoras r!pidamente mejoraban en velocidad, y especialmente en el
tama'o de la memoria de ncleo para mantener el estado, estos $astos indirectos
en la implementaci#n del tiempo compartido se redujeron continuamente en
t%rminos $lobales.
El concepto primero fue descrito pblicamente a principios de *GBD por ob
emer como parte de un artculo en utomatic !ontrol "a#azine. El primer
proyecto para implementar un sistema de tiempo compartido fue iniciado por Kohn
4c(arthy a finales de *GBD, en un 54 DH: modificado, y m!s adelante
adicionalmente una computadora 54 DHGH modificada. 3unque %l se fue para
trabajar en el -roject 43( y otros proyectos, uno de los resultados del proyecto,
conocido como el (ompatible Time+Sharin$ System o (TSS compatible, fue
demostrado en noviembre de *GC*. El (TSS tiene una buena aclamaci#n de ser el
primer sistema de tiempo compartido y permaneci# en uso hasta *GD.. El primer
sistema de tiempo compartido comercialmente exitoso fue el /artmouth Time+
Sharin$ System @/TSSA que fue implementado por primera ve" en el /artmouth
(olle$e en *GC: y subsecuentemente form# la base de los computer bureau
services de 0eneral Electric. El /TSS influenci# el dise'o de otros sistemas de
tiempo compartido tempranos desarrollados por Fe2lett -ac8ard, (ontrol /ata
(orporation, 9<563( y otros, adem!s de introducir el len$uaje de pro$ramaci#n
3S5(.
Requerimiento de sistemas
En la in$eniera de sistemas, un requerimiento es una necesidad
documentada sobre el contenido, forma o funcionalidad de un producto o servicio.
Se usa en un sentido formal en la in$eniera de sistemas o la in$eniera de
soft2are.
En la in$eniera cl!sica, los requerimientos se utili"an como datos de
entrada en la etapa de dise'o del producto. Establecen L9M debe hacer el
sistema, pero <1 (N41 hacerlo.
&a fase del desarrollo de requerimientos puede estar precedida por una
fase de an!lisis conceptual del proyecto. Esta fase puede dividirse en recolecci#n
de requerimientos de los inversores, an!lisis de consistencia e inte$ridad,
definici#n en t%rminos descriptivos para los desarrolladores y un esbo"o de
especificaci#n, previo al dise'o completo.
(ondici#n o capacidad que un usuario necesita para poder resolver un
problema o lo$rar un objetivo @5EEEA.
(ondici#n o capacidad que debe exhibir o poseer un sistema para
satisfacer un contrato, est!ndar, especificaci#n, u otra documentaci#n
formalmente impuesta @5EEEA.
9na condici#n o capacidad que debe ser conformada por el sistema @R9-A.
3l$o que el sistema debe hacer o una cualidad que el sistema debe poseer
@Robertson + RobertsonA.
Requerimientos en ingeniera de software y sistemas
En in$eniera de sistemas existen tres tipos de requerimientos.
9n requerimiento funcional puede ser una descripci#n de lo que un sistema
debe hacer. Este tipo de requerimiento especifica al$o que el sistema
entre$ado debe ser capa" de reali"ar.
9n requerimiento no funcional) de rendimiento, de calidad, etcI especifica
al$o sobre el propio sistema, y c#mo debe reali"ar sus funciones. 3l$unos
ejemplos de aspectos solicitables son la disponibilidad, el testeo, el
mantenimiento, la facilidad de uso, etc.
1tros tipos de limitaciones externas, que afectan en una forma indirecta al
producto. Estas pueden ir desde la compatibilidad con cierto sistema
operativo hasta la adecuaci#n a leyes o re$ulaciones aplicables al producto
9na colecci#n de requerimientos describe las caractersticas o atributos del
sistema deseado. Se omite el c#mo debe lo$rarse su implementaci#n, ya que esto
debe ser decidido en la etapa de dise'o por los dise'adores.
En la in$eniera de soft2are se aplica el mismo si$nificado, s#lo que el
%nfasis est! puesto en el propio soft2are.
Caractersticas
&os requerimientos bien formulados deben satisfacer varias caractersticas. Si
no lo hacen, deben ser reformulados hasta hacerlo.
<ecesario) &o que pida un requerimiento debe ser necesario para el
producto.
<o ambi$uo) El texto debe ser claro, preciso y tener una nica
interpretaci#n posible.
(onciso) /ebe redactarse en un len$uaje comprensible por los inversores
en lu$ar de uno de tipo t%cnico y especiali"ado, aunque an as debe
referenciar los aspectos importantes
(onsistente) <in$n requerimiento debe entrar en conflicto con otro
requerimiento diferente, ni con parte de otro. 3simismo, el len$uaje
empleado entre los distintos requerimientos debe ser consistente tambi%n.
(ompleto) &os requerimientos deben contener en s mismos toda la
informaci#n necesaria, y no remitir a otras fuentes externas que los
expliquen con m!s detalle.
3lcan"able) 9n requerimiento debe ser un objetivo realista, posible de ser
alcan"ado con el dinero, el tiempo y los recursos disponibles.
6erificable) Se debe poder verificar con absoluta certe"a, si el requerimiento
fue satisfecho o no. Esta verificaci#n puede lo$rarse mediante inspecci#n,
an!lisis, demostraci#n o testeo.
Estas caractersticas suelen ser subjetivas, es decir, no pueden ser calculadas
de forma autom!tica por nin$n sistema. -or ello, se tiende a medir otras m%tricas
o indicadores que s que pueden ser calculados de forma autom!tica y que, de
al$n modo, pueden sustituir o mapear con esta lista de caractersticas.
Anlisis de requerimientos
&a etapa en que se estudian los requerimientos para verificar que est%n
correctamente adecuados a las caractersticas mencionadas es conocida como 3n!lisis
de Requerimientos. En la misma se enfocan e intentan solucionar las deficiencias que los
requerimientos puedan tener.
Bibliografa
222.elclima.com.mxEcomparte.htm
es.2i8ipedia.or$E...ETiempoOcompartidoO@inform!tica
222.mono$rafias.com P ... P Sistemas 1perativos