Download CLASE 4: 23/04/98

J. M. G. – K. P. N.
CONTROL AUTOMÁTICO
CLASE 9: 11/06/98
SISTEMAS OPERATIVOS Y CONTROL AUTOMATICO
Dividimos a las aplicaciones de control en:
 Pequeñas
 Medianas
 Grandes
Las aplicaciones pequeñas son situaciones muy poco distinguibles como sistemas de
procesamientos de datos. Por ejemplo un teléfono público, tiene un procesador que clasifica
las monedas, lee las tarjetas, corta la comunicación si no tiene más crédito, etc. Tiene un
procesador que controla varios dispositivos. Hay muchas aplicaciones pequeñas en el área
de telefonía, también hay muchas en el área de la medicina, los aparatos que miden la
presión por ejemplo. Entonces este tipo de aplicaciones son sin sistema operativo y las
podemos llamar aplicaciones empotradas en un equipo físico. Otros ejemplos son las cajas
registradoras, las balanzas, etc.
Las aplicaciones medianas son las que tienen pocos lazos de control son prácticamente
todas basadas en PC.
Las aplicaciones grandes son aplicaciones de muchos lazos de control (work station), son
los casos de sistemas distribuidos con una distribución geográfica.
Las aplicaciones medianas y grandes son con sistema operativo, y son las que vamos a ver.
¿Cómo es la relación entre los lazos de control y las PC?
Si tengo:
1 LC ... 1PC
m LC ... m PC
Típicamente manejo varios lazos de control con una PC. Las otras relaciones dependen de
la naturaleza del problema, pero si tengo 40 lazos de control los puedo manejar sin mayores
problemas con un computador o con un PLC. Cuanto más grande sea el números de lazos
de control crece más la inseguridad, pero no ocasiona complicaciones extras.
Entonces un computador atendiendo varios lazos de control, ¿implica un sistema
operativo multitarea? La respuesta es no, puedo hacerlo con un sistema monotarea. Si
tengo 20 lazos de control puedo hacer un loop infinito que lea, calcule y saque las acciones
de control, esto no implica de ninguna manera que el sistema operativo tenga que ser
multitarea. Si cada lazo requiere atención cada 2 o 3 minutos, al computador le sobra
tiempo para poder realizar todos.
Si ahora decimos: ¿Las aplicaciones de control automático implican monotarea?
Y la respuesta también es NO.
Entonces en lazos de control automático no implica multitarea, pero casi siempre control
automático implica multitarea.
Entonces ¿de donde sale esta contradicción?
Esto se debe a que aplicaciones de control automático no solo implican lazos de control.
J. M. G. – K. P. N.
CONTROL AUTOMÁTICO
Las aplicaciones de control automático.
Lazos de control + Alarmas + Supervisión
del operador + Cálculos de balances + etc.
Y estas cosas SI son asincrónicas unas de otras. Las alarmas se producen no cuando se me
ocurren a mi, sino cuando se les ocurre a ellas. Estas cosas son definitivamente asincrónicas
respecto de mi programa y no puedo pretender manejar esto con monotarea.
Entonces: ¿Qué le pide el control automático al sistema operativo?
- Kernel o Task Scheduler
- Systems Calls
- E/S
KERNEL – TASK SCHEDULER
Algunos requisitos son sobre el Kernel, más específicamente sobre los algoritmos del
organizador de tareas (Task Scheduler).
La clave en esto es el Tiempo Real. Un sistema operativo de tiempo real decimos que el
Task Scheduler no esté basado en optimizar el uso de los recursos, sino que este basado en
la atención eficiente de los evento, y para esto decimos que deben responder en tiempo real.
Este es un sistema operativo que atienda a las tareas de mayor importancia, esto es manejo
de prioridades. La prioridad es muy dominante, no debo preocuparme por la eficiencia en el
cambio de contexto por parte del CPU, o de las entradas/salidas, debo preocuparme por la
seguridad, que establecen las prioridades.
Entonces un sistema de tiempo real requiere:
- No optimizar uso de recursos.
- Atención eficiente de eventos .
- Prioridades.
Estos requisitos se daban antes (10 años) como de un obligatoriedad extrema, o se cumple
ose tira. Antes en Unix no se hacían aplicaciones de control automático, existía QNX (un
UNIX de tiempo real) que en este sí se hacían aplicaciones de control automático. Esto se
debía a: la Fuerza Bruta. Hace 10 años la mayoría de las aplicaciones de control
automático eran balanceadas, esto es que antes a los computadores apenas le daba el cuero
para atender a los requisitos, atender en tiempo y forma las demandas. Pero hoy en día el
tiempo de respuesta esta muy por encima de lo demandado, entonces hoy sí existen
aplicaciones de control automático hechas en Unix. Estos requisitos o afirmaciones son
ciertas para sistemas que están mas o menos balanceados (tiempo de proceso y tiempo de
respuesta exigido son compatibles). Ahora estos requisitos son mas flexibles.
Hoy en Windows se puede hacer una aplicación de control automático con sus limitaciones,
ya que Windows permite que algunas aplicaciones no larguen la CPU (no hacen context
switch), si solo ocurre la aplicación de control automático que nosotros desarrollamos si se
puede (si, mas o menos). Si una tarea se pone a trabajar en Windows ninguna otra tarea
podría sacarle la CPU ya que la tarea no esta pensada para compartir la CPU, pero el caso
de Windows o sistemas no muy aptos dan una suerte de cambio de contexto, hoy en la
mayoría de los sistemas operativos, se tienen funciones del tipo relinguish, básicamente
ceder la CPU. Esto es, la propia tarea pide un context switch. Todas las tareas que han sido
hechas para control automático que han tenido cuidado de no ser abusivas con la CPU
entonces el sistema puede funcionar lo mas bien. Casi todos los sistemas Scada comerciales
que se consiguen hoy en día, corren bajo Windows, y lo hacen muy bien. Esto es porque
están hechos pensados con filosofía de que estamos en un sistema de tiempo real, un
sistema de control automático y nadie se apropia de la CPU.
J. M. G. – K. P. N.
CONTROL AUTOMÁTICO
Escala de niveles




Monotarea: NO se puede desde el punto de vista del sistema operativo. Pero por
ejemplo en Ada95 o algún lenguaje concurrente se podría hacer una aplicación para
control automático pero ahora se deben cumplir en el lenguaje, los requisitos de tiempo
real que tenía antes. Ada95 lo cumple.
Windows: Si pero tengo que tener cuidado con la programación y no usar otras
aplicaciones.
UNIX: SI solo debo tener capacidad de proceso, me despreocupo de la programación.
QNX: SI!!. Sistemas operativos construidos para tiempo real.
SYSTEMS CALLS
Las aplicaciones de control automático fuerzan mucho a los subsistemas. En las industrias
no existen unas cajas que por ejemplo entran piedras y sale cemento, existen subsistemas o
porciones del sistema casi siempre con buffer entre ellos (buffer en el sentido de
almacenamiento de productos intermedios). Puede ser que tenga una molienda, luego un
horno, luego una bancada, después un embolsado, etc. En general tengo fragmentos de la
planta que funcionan en conjunto. Entonces naturalmente el software va a tener una serie de
subsistemas como molienda, hornos, etc. Entonces habitualmente es posible pensar que hay
distintos programas que atienden las distintas partes que tiene el problema, esto es una
descomposición clásica de un problema de control automático.
En esta situación es natural la aparición de unos programas que se suelen llamar ejecutivos
cuyo propósito es coordinar la actividad del conjunto de programas que hacen tareas de este
tipo. Aparecen unas jerarquías de programas, o sea la aplicación tienen módulos y estos
tienen una cierta jerarquía, esto es que hay una descomposición del problema que me
permite verlo mas simplificadamente.
Ocurre que es mas sencillo tener un programa ejecutivo que conozca las distintas partes del
proceso industrial, entonces se arranca este ejecutivo y este coordina la ejecución de todos
los sistemas involucrados. Un programa ejecutivo que tenga concentrado la supervisión de
un sistema.
Una organización de este tipo muy típica de muchísimas aplicaciones de control automático
requiere que :
-
Arrancar, suspender o cancelar un programa
Cambiar prioridades a un programa o proceso. EL programa ejecutivo debe darse cuenta
que si un tanque esta casi al limite de una situación de alarma para darle mayor prioridad.
Crear, arrancar, eliminar o parar timers. En la industria se deben ligar un proceso o
conjunto de procesos a determinado tiempo u horario, esta es la noción de las timer.
Conectar y desconectar timers a programas.
Conectar y desconectar interrupciones a programas.
J. M. G. – K. P. N.
CONTROL AUTOMÁTICO
Estos requerimientos se traducen en system calls.
Estas cosas nos aglutina la posibilidad de influencia de una tarea sobre otra.
Por ejemplo tenemos un tanque cerca del limite inferior, pero todavía no hay alarma, pero
puede haber un limite anterior que cambia la atención sobre este tanque. Si tengo una bomba
que me inyecta liquido sobre el tanque.
Un alarma sobre esta bomba en condiciones normales es de menor jerarquía, pero si estamos
en el tanque en situación de pre alarma esta bomba es de suma importancia, entonces si el
nivel bajo hasta un cierto limite es posible que conecte una interrupción a un programa de
emergencia. Estas interrupciones son típicamente en casos donde la situación es peligrosa.
Entonces, todas las systems calls que pide el control automático se las agrupa muy bien
posibilitando la influencia de tareas sobre tareas.
Estas cosas sí se pueden hacer en windows y Unix.
En general, los sistemas operativos propietarios esto se puede hacer a veces, porque no
está pensado para estas situaciones, y en sistemas operativos abiertos se produce casi
siempre (Unix y Windows). Pero en los sistemas operativos propietarios hay algunas cosas
mejores que en los sistemas operativos abiertos, hay algunos sistemas operativos que
introducen la noción que no esta disponible ni en Unix ni en Windows, que es la noción de
precedencia que es muy importante para control automático.
La precedencia es una característica muy parecida a la prioridad, no son nociones
sincrónicas, eventualmente pueden ser asincrónicas. Si tengo dos procesos A y B, y digo
que A tiene prioridad sobre B (A>B), significa que cuando están los recursos disponibles se
ejecuta primero A. La noción de precedencia regula la influencia de una tarea sobre otra,
cuando una tarea (A) tiene mayor precedencia que otra (B), significa que A puede hacer
arrancar a B. Los ejecutivos son programas que tienen la posibilidad de arrancar la mayoría
de los programas del sistema. La relación de precedencia es parecida a la de prioridad pero
no hay ningún impedimento que estén cruzadas, podría decir que la prioridad de A sea
menor que la de B y que la precedencia de A es mayor que la de B (si se ejecutan los dos
primero B, pero A puede suspender a B y B no a A, A es mas importante), en general están
en paralelo (los programas de mayor precedencia son de mayor prioridad), pero no siempre
tiene que ser así.
En resumen, los sistemas operativos abiertos casi siempre tienen disponibles system calls
(Unix). En sistemas operativos propietarios hay mejores que Unix y algunos mucho peores
desde el punto de vista de la oferta del system calls. En algunos sistemas operativos
pensados para control automático aparecen las nociones de precedencia.
Finalmente, los sistemas operativos propietarios son sistemas operativos de una sola
máquina, por lo que son poco visibles, son muy pocos. Uno de los mejores fue MAX y
corrían en computadoras MODCOMP (NASA), en la Argentina hay unos pocos usadas en
lo que sea control de energía eléctrica.
Entradas / Salidas
En la clasificación que hicimos de las aplicaciones en grandes medianas y pequeñas,
decimos que en el sentido de pequeñas a grandes crece el tamaño y crecen las exigencias
del sistema operativo. Pero en dirección contraria crecen los periféricos especiales y esto es
sumamente significativo en control automático.
J. M. G. – K. P. N.
CONTROL AUTOMÁTICO
Clasificación de periférico:
-
CONVENCIONAL: Son naturales en el mundo de la informática, discos, CD , etc. Los
habituales. Los dispositivos con sus drivers.
NO CONVENCIONAL: (2 tipos) La disponibilidad del driver no es tan obvia
- Standard : conversores A/D y D/A y E/S digitales
- No standard: Sensores o dispositivos para una aplicación especial
(medir presión, teléfono público). NO necesito drivers porque es un
periférico que lo diseño específicamente para un problemas.
Entonces existen zonas donde tenemos aplicaciones ni grandes ni chicas donde tengo
sistemas operativo + periféricos especiales. Hay muchas aplicaciones donde debo utilizar
un periférico que fue construido para el problema (nadie lo conoce, solo el entorno que lo
construyó). Entonces necesito drivers y necesito system calls que lo manejen.
Hay exigencias sobre las entradas / salidas que son la de poder agregar drivers que yo
escribo, y tener system calls que me puedan acceder a esos drivers para que los programas
puedan utilizar los dispositivos.
Entonces tenemos a los tres requisitos involucrados (organizador de tareas, system calls y
E/S).
El cajero automático tiene un dispositivo (periférico) especial que es el contador de billetes.
Antes este no era standard.
Lenguaje
de
Aplicación
System Calls
Sistema
Operativo
Drivers
Periféricos
Especiales
Entonces necesito System Calls y Drivers
La aplicación puede pedir dinero al sistema operativo, esto lo hace por medio de system
calls, pero el sistema operativo no conoce al dispositivo (contador de billetes), entonces
necesito un driver para que el sistema operativo pueda manejar el dispositivo y a su vez el
sistema operativo me tiene que facilitar systems calls para manejar los periféricos con la
aplicación.
Podría hacer:
APLICACIÓN
ignoro al sistema operativo
PERIFERICO ESP.
Pero para muchas aplicaciones no puedo realizar esto, necesito drivers y systems calls.