jueves, 10 de diciembre de 2020

BATCH

 

Procesamiento por lotes

Se conoce como sistema por lotes (en inglés batch processing), o modo batch, a la ejecución de un programa sin el control o supervisión directa del usuario (que se denomina procesamiento interactivo). Este tipo de programas se caracterizan porque su ejecución no precisa ningún tipo de interacción con el usuario.

Generalmente, este tipo de ejecución se utiliza en tareas repetitivas sobre grandes conjuntos de información, ya que sería tedioso y propenso a errores realizarlo manualmente. Un ejemplo sería el renderizado de los fotogramas de una película. Otros ejemplos de procesos batch pueden ser la generación de extractos bancarios, el cálculo de intereses corrientes o moratorios de cuentas de crédito, la generación automática de archivos de interfaz con otros sistemas, etc.

Los programas que ejecutan por lotes suelen especificar su funcionamiento mediante scripts o guiones (procedimientos) en los que se indica qué se quiere ejecutar y, posiblemente, qué tipo de recursos necesita reservar.

 

Programas batch

Algunos programas conocidos que pueden funcionar en modo por lotes: GIMP (GNU Image Manipulation Program), ​ R-project, gnuplot, GNU Octave, command.com, EXEC II, entre otros muchos.

Realmente, casi cualquier programa puede ejecutar en modo batch, siempre y cuando pueda especificarse los distintos pasos de ejecución o las entradas de usuario a partir de un script.

Es importante no confundir el procesamiento por lotes con los programas o archivos .bat de los sistemas batch (de los cuales heredan su nombre debido a su metodología). Como bien está explicado más arriba, estos archivos se ejecutan de manera secuencial, y cerrando la ejecución al usuario ya que este no puede interactuar ni intervenir en el programa que se ejecuta.

Frente a este tenemos los 'Sistemas por batch', los cuales son una manera de llevar a cabo el proceso de la información, en lenguaje llano, una manera de hacer informática, en estos sistemas los programas y tareas se ejecutan de manera secuencial, no porque el programa lo exija como es el caso de los .bat, sino porque no conocía otra forma de ejecución. 

 

ACTIVIDAD 

Esta semana no les dejo actividad para el PORTAFOLIO.

Los alumnos que aún no han conformado grupos de trabajo para exponer preparen su exposición en base a este tema propuesto.

jueves, 3 de diciembre de 2020

SISTEMAS BATCH EN LA INDUSTRIA

 

La industria farmacéutica está realizando grandes esfuerzos en digitalización

 

Nuevas tendencias de los sistemas BATCH para la industria farmacéutica

Reactores intermitentes o reactores batch

 

Los sistemas de automatización de procesos Batch nacieron para solucionar la problemática de la fabricación de múltiples productos en una misma instalación. En los últimos tiempos ha aumentado la cantidad de variantes, o de productos diferentes, que se fabrican en una planta, haciendo imprescindible que el sistema de control disponga de una gran capacidad de adaptación, y permita minimizar el tiempo de acceso al mercado. Además, en la actualidad, la demanda creciente de datos e información a los sistemas de control, así como la búsqueda de la eficiencia y seguridad de las operaciones, lleva a los sistemas de control Batch a incorporar una serie de nuevas funcionalidades para hacer frente a los retos y demandas de la industria.

A finales de los años 90, para solucionar las necesidades de ciertas industrias con procesos de fabricación por lotes que demandaban flexibilizar y aumentar la eficiencia de los equipos de planta, la Asociación ISA (International Society of Automation) desarrolló el estándar S88. Uno de los principales beneficios de la norma ISA S88 es la habilidad para separar los equipos físicos de los pasos para fabricar un producto. Se utilizan recetas y procedimientos que describen cómo fabricar un producto concreto y para fabricarlo, las capacidades de los equipos e instalaciones.

Paralelamente a esta norma, comenzaron a desarrollarse softwares y sistemas Batch. Con un sistema Batch se puede diseñar un control basado en ISA S88 que nos permita realizar diferentes recetas para múltiples productos y de forma sencilla, pudiendo modificar o crear nuevos productos, pero sin realizar cambios en el sistema de control. Además, nos facilita el registro de todos los eventos que ocurren durante la fabricación de un lote. Siendo fundamental para una correcta auditoria y trazabilidad.

La automatización de los procesos de fabricación por lote busca garantizar la repetitividad de los diferentes procedimientos, disminuyendo la variabilidad para asegurar en todos los lotes la calidad del producto. El sistema Batch garantiza la ejecución del lote de fabricación según se ha definido en el procedimiento o receta.

Si nos centramos en la industria farmacéutica, se están realizando grandes esfuerzos en la digitalización industrial buscando fábricas más modernas que permitan una mayor flexibilidad de sus procesos productivos, la optimización del uso de equipos, la mejora de la calidad de producción y la reducción de sus costes de fabricación. Para conseguir fábricas más flexibles y optimizadas, los sistemas Batch actuales han ampliado sus capacidades y disponen de nuevas funcionalidades para conseguir:

• La mejora de los procedimientos y la gestión de recetas para conseguir una mayor flexibilidad y reducir los tiempos de fabricación simplificando la introducción de nuevos productos.

• El mantenimiento de la calidad reduciendo la variabilidad, digitalizando los procedimientos manuales y prediciendo problemas que puedan corregirse en tiempo real.

• El aumento de la productividad del personal facilitando herramientas de movilidad y realidad aumentada que permitan la eficiencia de operación, mantenimiento e ingeniería.

 

 

Simplicidad y seguridad en la gestión de recetas

Las herramientas de creación de recetas de los sistemas Batch modernos se han adaptado a los nuevos requerimientos para simplificar y dotar de mayor seguridad la gestión de las diferentes recetas o procedimientos.

Se simplifica la gestión de recetas potenciando la gestión de fórmulas que permiten reutilizar las secuencias definidas en una receta con múltiples ingredientes/parámetros. También el uso de controladores o PLCs basados en ISA S88 simplifica la creación de recetas. Estos controladores permiten la programación nativa de fases de control con el modelo de estados S88 que sincronizan directamente con el sistema Batch, pero en los últimos tiempos también se han incorporado a los controladores otros niveles del modelo procedural de la norma S88, como operaciones o procedimientos de unidad que se pueden implementar directamente en el controlador. Con estas opciones, el controlador tiene más capacidad de gestión batch, distribuyendo las lógica procedural en diferentes partes del sistema. Se consigue así, centralizar la gestión de los procedimientos y recetas y la distribución de la lógica de control para facilitar la integración de skids y nuevos equipos de forma rápida y fiable.

La seguridad de la gestión de las recetas adquiere cada vez más importancia. Se asegura un correcto control de versiones generando, cada vez que se modifica su contenido, una nueva versión de la receta, registrando todas las acciones realizadas en el editor de recetas.

Para garantizar el uso correcto de los procedimientos, el sistema batch debe permitir un proceso de validación de cada receta maestra. El gestor de recetas permite definir diferentes circuitos de firmas para que un grupo de usuarios determinado, con un rol específico en el sistema, valide la receta o los cambios realizados en la receta, antes de que esté disponible para fabricación.

La información que contienen las recetas maestras es información sensible y confidencial que se tiene que proteger de forma adecuada. La definición de políticas de seguridad para roles de usuarios debe configurarse correctamente, pero también hay que proteger la información sensible que contienen las recetas maestras. Para ello las herramientas de edición de recetas del sistema permiten encriptar su contenido para evitar accesos no autorizados a información sensible, protegiendo el acceso e inutilizando posibles copias extraídas del sistema.

Acciones manuales, Procedimiento Estándar de Operación y Registro Electrónico de Lotes

En múltiples ocasiones, durante la ejecución de una receta, nos encontramos acciones manuales. Un sistema Batch puede ayudarnos a la gestión de estas acciones para: asegurar la correcta ejecución, reducir el tiempo de reacción, y registrarlas con el resto de eventos automáticos del lote. No basta con avisar al operador cuándo se debe incorporar un paso manual en una receta. El sistema Batch avisará al operador cuando la receta ordena la ejecución de una acción manual, pero además, le dotará de una interface en la que dispondrá de las instrucciones concretas que debe realizar, con información adicional para la ejecución de la operación (pueden ser documentos electrónicos, fotos o videos). El sistema asegurará la captura de información mediante formularios incorporados a la receta y registrará toda la interactuación con el operador en el registro del lote. El sistema también puede permitir definir firmas electrónicas para confirmar un paso de receta, o para validar alguna excepción durante la ejecución, por ejemplo por un registro fuera de rango, y continuar con la ejecución de la receta únicamente si se ha realizado la firma correctamente.

En ocasiones, estas acciones manuales definen un procedimiento completo de fabricación. Es lo que se conoce como Guía de Fabricación o Procedimiento Estándar de Operación (del Inglés SOP -Standard Operating Procedure-). Los Sistemas Batch modernos permiten la incorporación de estas acciones manuales en procedimientos automáticos, creando procedimientos mixtos o procedimientos manuales completos, aprovechando las ventajas que ofrece un sistema Batch para la digitalización de estas guías de fabricación.

En el gestor de recetas del sistema Batch se pueden definir diferentes Procedimientos o SOP. En la receta se incorporan las instrucciones de operación para que el operador las vaya ejecutando según se ha definido. El entorno de operación del sistema Batch permitirá al operador seguir la ejecución de la guía, e introducir la información que se vaya pidiendo en cada instante. La entrada de datos puede ser manual, bien por teclado o con lectores de código de barras, o automática, capturando información de sistemas de control, lectores de peso, instrumentación u otras Bases de datos. Toda la ejecución de la guía quedará registrada en un Registro Electrónico de Lotes o EBR (Electronic Batch Record).

En este registro se van capturando y registrando todos los eventos que ocurren durante el transcurso de la receta. Toda la información y trazabilidad del lote de fabricación estará disponible en un único fichero de eventos. La información de la receta maestra, las horas de inicio y ejecución de cada uno de los pasos de la receta con los parámetros de entrada y reporte, las acciones manuales realizadas durante el lote, y todas las alarmas y situaciones anómalas, así como posibles variaciones o desvíos producidos durante la ejecución. Para facilitar el acceso a esta información, se pueden realizar diferentes informes de lote que muestren la información, según las excepciones o las situaciones anómalas producidas durante la ejecución del lote y que requieren la atención o supervisión del personal asignado.

 

 

Terminales móviles y Realidad Aumentada

Actualmente, la sala de control no es el único lugar desde el que se supervisan los procesos de producción. Sobre todo, si tenemos operadores que deben realizar acciones manuales interactuando con el sistema de control para la ejecución de acciones manuales en un lote de fabricación. Los terminales móviles permiten a diferentes usuarios del sistema de control: operadores, mantenimiento o supervisores; acceder al mismo desde cualquier parte. Tienen así la posibilidad de utilizar su propio terminal o un dispositivo móvil para seguir la ejecución de los lotes, guías de fabricación o realización de las indicaciones o instrucciones que les va pidiendo el sistema.

El uso de tecnología HTML5 en los clientes Batch permite el acceso web, independientemente del sistema operativo o navegador utilizado en el terminal de acceso. De esta manera, el sistema Batch está disponible en PCs corporativos, tablets o Thin Clients de forma controlada y segura. Se trata de un acceso más flexible y un mantenimiento del sistema más sencillo al no requerir de la instalación de software Batch en los terminales. Esta tecnología de los clientes web ofrece un entorno moderno e intuitivo que facilita operaciones más eficientes en el sistema Batch.

Los sistemas Batch actuales que integran las acciones manuales en la elaboración de los procedimientos de recetas, como ya hemos comentado, nos permiten digitalizar las SOP o guías de fabricación para ser realizadas desde terminales móviles, pero además, habilitan la utilización de las tecnologías más innovadoras que ofrecen las nuevas tendencias de digitalización. Una de ellas, orientada a reforzar la eficiencia de operación en los Procedimientos Estándar de Operación, es la Realidad Aumentada (RA).

Si estamos digitalizando los Procedimientos Estándar de Operación para asegurar la correcta ejecución y creación de informes de las operaciones de fabricación, la RA nos permitirá avanzar un paso más. Nos permitirá incorporar las instrucciones de operación sobre los elementos físicos y comprobar en tiempo real la correcta ejecución de las diferentes instrucciones de operación.

La utilización de la RA puede facilitar las operaciones manuales de preparación de equipos para la realización de un lote de producción y mejorar a su vez, el cumplimiento de normativas. Registrando las acciones realizadas y complementándolas con capturas de imágenes y videos que muestren las operaciones realizadas en los equipos físicos.

Diferentes casos de uso de RA en entornos de fabricación por lote y/o farmacéutica pueden ser los siguientes:

• Mejora de la efectividad de operación desde HMI y clientes Batch. Acceso a la información en tiempo real desde terminales móviles contextualizados a los equipos físicos sin necesidad de acceder a terminales in situ, en salas blancas o de difícil acceso, que demoran el tiempo de respuesta.

• Operaciones de preparación de equipos para la ejecución de lotes más eficientes. Crítico en entornos de fabricación con skids o equipos móviles como pueden ser los biorreactores de un solo uso. Ejemplo de caso de uso.

• Soporte remoto mediante herramientas de chat y RA. Establecer video llamadas con equipos de soporte sobre las que se pueden dar indicaciones y mostrar diferentes procedimientos de operación y mantenimiento basadas en RA.

• Facilitar el cumplimiento de normativas de regulación. Mejorar el registro de audits incorporando verificaciones en tiempo real basadas en las cámaras de los terminales móviles y generando registros en el EBR de las acciones realizadas desde la aplicación de realidad aumentada.

• Optimizar el rendimiento mediante Machine Learning. El aprendizaje automático permitirá que el sistema sepa cuál es el comportamiento normal del proceso durante los lotes. El algoritmo puede observar "anomalías" o comportamientos anormales dentro de los parámetros del proceso para guiar al operador a la acción correctiva y mejorar el rendimiento del lote.

ACTIVIDAD EN BASE AL TEXTO PROPUESTO

DESARROLLAR Y PASAR AL PORTAFOLIO

SEMANA DEL 30/11 AL 04/12 DE 2020

 

1. Realiza un organizador gráfico que represente lo más importante del texto propuesto.

2. Conteste las siguientes preguntas

a) ¿Qué es lo que más te llamó la atención de la lectura realizada?

b) De los diferentes casos de uso de RA en entornos de fabricación por lote y/o farmacéutica. ¿Cuál es el que más te impacto?

c) ¿Para qué nacieron los sistemas de automatización de procesos BATCH?

d) ¿Los sistemas BATCH actuales trabajan con las nuevas tecnologías?  ¿Sí / No? ¿Por qué?

e) ¿Qué busca garantizar la automatización de los procesos de fabricación por lote?

f) ¿Gracias a qué tecnología el sistema BATCH está disponible en PCs corporativos, tablets o Thin Clients de forma controlada y segura?

g) Estas de acuerdo con la afirmación: “Los Sistemas BATCH modernos permiten la incorporación de estas acciones manuales en procedimientos automáticos”   ¿Sí / No? ¿Por qué?

h) ¿Para garantizar el uso correcto de los procedimientos, el sistema BATCH qué debe permitir?

LOS GRUPOS QUE NO EXPUSIERON ESTA SEMANA DEBERÁN HACERLO EN LA SIGUIENTE CLASE, ASÍ QUE ENVÍEN SUS DIAPOSITIVAS A MI CORREO. HASTA EL DOMINGO 06 DE DICIEMBRE.

jueves, 26 de noviembre de 2020

Evolución de los Sistemas Operativos

EVOLUCIÓN DE LOS SISTEMAS OPERATIVOS

En este apartado se va a comentar cómo han ido evolucionando los sistemas operativos a través de la historia. No estamos interesados en las fechas, sino en la progresión de las ideas.

 

https://lsi.vc.ehu.eus/pablogn/docencia/manuales/SO/TemasSOuJaen/INTRODUCCION/Bullet1.gif Primera etapa: Procesamiento en serie.

En un principio no existían sistemas operativos, programándose sobre el hardware básico. Los programas se escribían en lenguaje máquina, y se introducían en el ordenador, junto a los datos, en octal o hexadecimal mediante una consola con interruptores manuales. Se iniciaban los programas cargando el registro contador de programa con la dirección de memoria de la primera instrucción del programa. Los resultados de la ejecución se obtenían examinando el contenido de los registros y posiciones de memoria relevantes. Los dispositivos de E/S se controlaban directamente, escribiendo y leyendo en los puertos de E/S.

Evidentemente la programación del hardware básico resulta baja en productividad, tanto para los usuarios, como para la máquina. El proceso largo y tedioso de la introducción de programas y datos excluye prácticamente la ejecución de programas medios y grandes.

Un siguiente paso significativo en la evolución en el uso de los ordenadores viene con la llegada de los dispositivos de E/S, tales como lectores de tarjetas y de cintas de papel perforadas. También aparecen los traductores de lenguajes. Los programas, codificados ahora en un lenguaje simbólico, se traducen a forma ejecutable mediante un traductor. Otro programa, llamado cargador, automatiza la carga de programas ejecutables en memoria. El usuario pone un programa y sus datos de entrada en un dispositivo de entrada, y el cargador transfiere información desde el dispositivo de entrada a memoria. Después, se transfiere el control, mediante medios manuales o automáticos, al programa cargado para su ejecución. El programa en ejecución lee sus entradas desde el dispositivo de entrada designado y puede producir alguna salida en un dispositivo de salida, como la impresora o la pantalla. Una vez en memoria, el programa se puede reejecutar con un conjunto diferente de datos de entrada.

 

El mecanismo de desarrollo de programas sigue siendo engorroso. En una secuencia típica, se carga el programa editor para preparar el código fuente del programa de usuario. El siguiente paso es cargar y ejecutar el traductor, y alimentarlo con el código fuente del programa de usuario. Los traductores de paso múltiple pueden requerir que se vuelva a poner el código fuente durante cada paso para leerlo. Una vez corregido sintácticamente el programa se ejecuta el código objeto. Si se detectan errores en la ejecución, se puede examinar y modificar el contenido de la máquina mediante los interruptores de la consola, o con la ayuda de un programa denominado depurador.

La mayoría de los programas utilizaban dispositivos de E/S. Una mejora lógica fue el proporcionar unas rutinas estándares de E/S que fueran usadas por todos los programas. Al principio, las rutinas de E/S se introducían con las demás tarjetas del programa de usuario. Posteriormente, se guardaba en memoria las rutinas compiladas, y mediante un programa enlazador se combinaban con el código objeto del usuario.

En estos sistemas las rutinas de E/S y el programa cargador constituyen una forma rudimentaria de sistema operativo. Los traductores, editores y depuradores son programas de sistema, pero no forman parte del sistema operativo.

 

https://lsi.vc.ehu.eus/pablogn/docencia/manuales/SO/TemasSOuJaen/INTRODUCCION/Bullet1.gifSegunda etapa: Procesamiento por lotes.

Hasta ahora la utilización del procesador es muy baja, pues el tiempo empleado en leer un programa almacenado en tarjetas suele ser mucho mayor que el empleado en ejecutar el programa. Cuando aparecieron las cintas magnéticas, cuya lectura y escritura era muy inferior en tiempo a las tarjetas, se pensó que se utilizaría más el procesador si todas las entradas y salidas se realizaban sobre cintas.

Para realizar esto se utilizó una técnica de off-lining (fuera de línea). La idea era dedicar un ordenador periférico, de menor costo y potencia, a convertir las tarjetas o la cinta perforada en información sobre cinta magnética, y la salida sobre cinta magnética en salida sobre impresora o cinta perforada. Una vez que se procesaban varios trabajos a cinta, ésta se desmontaba del ordenador periférico, y se llevaba a mano para su procesamiento por el ordenador principal. Cuando el ordenador principal llenaba una cinta de salida, ésta se llevaba al ordenador periférico para su paso a impresora o cinta perforada.

Una de las implicaciones de esta forma de trabajo era que en una cinta de entrada podían existir los trabajos de varios programadores. Para diferenciar los trabajos (o tareas) de distintos programadores se introducían tarjetas de control que interpretaba un sistema operativo embrionario. Así, por ejemplo, un trabajo podía empezar con una tarjeta $JOB de comienzo, con un identificativo del programador. Después una tarjeta $FORTRAN para indicarle al sistema operativo que cargue el compilador de FORTRAN de una cinta del sistema. A continuación vendrían las tarjetas del código fuente. Una tarjeta $LOAD para que se cargue en memoria el programa compilado (pues usualmente se guardaba en cinta). La tarjeta $RUN indicaba que se ejecutara el programa con los datos que vienen en las tarjetas siguientes. Por fin, una tarjeta $END indicaba el fin del trabajo.

 

El sistema operativo residía en memoria y tenía un programa de control que interpretaba las tarjetas de control, las cuales representaban un lenguaje de control de tareas. Dependiendo del tipo de tarjeta de control el sistema operativo realizaba una acción determinada. Este programa de control es un antecedente de los modernos intérpretes de órdenes.

 Con esta forma de trabajo el programador entregaba sus tarjetas a un operador y esperaba horas hasta que el programa proporcionara su salida. La falta de un punto y coma al final de una línea de un programa podía provocar un error sintáctico, y la pérdida de estas horas de espera. Por otro lado, debido a que la cinta magnética es un medio de almacenamiento serie, no había opción alguna de orden de ejecución de las tareas que no fuese el orden en que éstas se habían presentado al ordenador.

 De cara a eliminar la dependencia de las E/S en lugar de tan sólo reducirla, hay que emplear técnicas mediante las cuales se puedan superponer las E/S al proceso a ejecutar. Ello es posible con la ayuda de dos elementos del hardware: el canal y la interrupción. Un canal es un elemento que controla uno o más dispositivos, llevando a cabo transferencias de datos entre estos dispositivos y la memoria sin involucrar prácticamente al procesador central. Una interrupción es una señal que transfiere el control del procesador central a una posición fija de memoria, almacenando al mismo tiempo el valor anterior del contador de programa, y, posiblemente, la palabra de estado del procesador. De esta forma, se suspende temporalmente la ejecución del programa que estaba siendo llevado a cabo en el momento de la interrupción, aunque podrá reemprenderse dicha ejecución más tarde (o sea, el programa es interrumpido). Una interrupción de un canal actúa como señal que indica que se ha completado una transferencia de datos. De esta forma es posible que el procesador central inicie una transferencia a un dispositivo, continúe el proceso que estaba llevando a cabo mientras el canal controla la transmisión y reciba a través de una interrupción la notificación de haberse completado dicha transferencia.

 

Es posible ahora leer las tareas a ejecutar guardándolas en un soporte adecuado (normalmente disco), y ejecutarlas una a una al mismo tiempo que se van leyendo otras. Para ello ha habido que añadir a nuestro sistema operativo una rutina de gestión de las interrupciones y otra que decida cuál de las tareas almacenadas en disco será la siguiente en ser ejecutada. Esta última función, que recibe el nombre de sheduling, deriva del empleo del disco (caracterizado por un acceso aleatorio) como medio de almacenamiento de las distintas tareas en lugar de la cinta magnética, caracterizada por un acceso serie. Un sistema que trabaje de esta forma recibe el nombre de monitor de batch de flujo único (en inglés, single stream batch monitor). El concepto de flujo único lleva implícita la idea de una sóla tarea ejecutándose a la vez.

 

https://lsi.vc.ehu.eus/pablogn/docencia/manuales/SO/TemasSOuJaen/INTRODUCCION/Bullet1.gifTercera etapa: Multiprogramación y tiempo compartido.

La principal desventaja de un sistema de cola única es la total dedicación de la máquina a la ejecución de una sóla tarea, no importa lo larga o lo corta que sea. Este inconveniente puede superarse mediante la multiprogramación, o sea, la ejecución simultánea de varios programas que residen en la memoria principal, dividiendo el procesador central su tiempo entre ellos de acuerdo con los recursos (tal como canales o dispositivos) que necesite en cada momento cada uno de ellos. De esta forma es posible, teniendo almacenado un conjunto adecuado de tareas en cada momento, obtener una utilización óptima de los recursos disponibles. Ello incluye la utilización del procesador central, ya que en tanto que una tarea esté esperando el final de una transferencia de E/S, este procesador puede pasar a trabajar en alguna otra tarea que esté pendiente en la máquina. La carga que recae sobre el sistema operativo consiste en el control de los recursos, así como la protección de cada tarea frente a las actividades de las otras. Un sistema operativo de este tipo recibe el nombre de monitor de batch de varios flujos.

 

En el estado actual de la progresión que hemos llevado a cabo tenemos un sistema notablemente sofisticado que hace bastante buen uso de la electrónica disponible. Sin embargo, desde el punto de vista del usuario el sistema adolece de falta de interactividad, tan necesaria en el proceso de desarrollo de programas, y útil también para desarrollar programas interactivos que respondan instantáneamente a las peticiones del usuario. Para hacer posible esta interacción, el sistema de batch de varios flujos debe modificarse con el fin de que pueda adquirir la información que le suministren los usuarios desde los respectivos terminales: es decir, debe convertirse en un sistema multiusuario. Un sistema de este tipo, en el cual existen varios usuarios con un terminal en línea (usuarios interactivos), se llama sistema de tiempo compartido. En estos sistemas se divide el tiempo del procesador central, y de los demás recursos del ordenador, de forma que cada usuario tiene la ilusión de que todo el ordenador se le dedica exclusivamente a él, al recibir unos tiempos de respuesta aceptables. En un sistema de tiempo compartido los usuarios suelen ejecutar programas cortos (por ejemplo, compilar un programa), frente a los programas largos (por ejemplo, ordenar una cinta de un millón de datos) que se suelen dar en los sistemas batch.

Por último hay que indicar que algunos sistemas operativos permiten tanto usuarios interactivos como lotes de trabajos batch. En estos sistemas se atiende a los usuarios interactivos con mayor prioridad, ejecutándose los programas batch cuando no hay programas de usuario.

 

https://lsi.vc.ehu.eus/pablogn/docencia/manuales/SO/TemasSOuJaen/INTRODUCCION/Bullet1.gifCuarta etapa: redes de ordenadores.

En una red de ordenadores se tiene una configuración de varios ordenadores conectados físicamente. Los ordenadores de una red pueden tener sistemas operativos de red o sistemas operativos distribuidos.

En un sistema operativo de red los usuarios son conscientes de la existencia de varios ordenadores, y pueden conectarse con máquinas remotas para, por ejemplo, copiar ficheros. Cada máquina ejecuta su propio sistema operativo local y tiene su propio usuario (o grupo de usuarios). Los sistemas operativos de red no difieren de los sistemas operativos tradicionales de un sólo procesador. Necesitan un controlador de red, algunas rutinas de E/S para utilizar dicho controlador, y programas que permitan la conexión y el acceso a ordenadores remotos, pero esas características adicionales no modifican la estructura esencial del sistema operativo.

En un sistema distribuido los ficheros que utiliza un usuario (así como el procesador en el que se ejecutan sus programas) pueden estar situados en cualquier ordenador de la red. Además, esto es transparente al usuario. Los sistemas operativos distribuidos requieren algo más que añadir un poco de código a un sistema operativo de un único procesador, ya que los sistemas distribuidos difieren en aspectos críticos de los sistemas centralizados.

 

 

ACTIVIDAD QUE DEBEN REALIZAR EN EL PORTAFOLIO

1. Realice un organizador gráfico que sintetice la información proporcionada

 

2. Contesta las siguientes preguntas en base a la lectura propuesta

a.      ¿Qué sucedía en la primera etapa de los sistemas operativos?

b.      ¿Cuál era la característica principal en la segunda etapa de los sistemas operativos?

c.       ¿En un sistema operativo de red de qué son conscientes los usuarios?

d) ¿Cuál es la principal desventaja de la programación por lotes?

e) ¿Qué inconveniente puede superar la multiprogramación?

f) En la actualidad ¿En qué etapa de los sistemas operativos estamos?

 

3. Organicen grupos de trabajo DE MÁXIMO 6 ESTUDIANTES , REALIZAN POR GRUPO DIAPOSITIVAS Y ENVÍA EL ARCHIVO DE POWER POINT UN MIEMBRO DEL GRUPO A MI CORREO ELECTRÓNICO HASTA EL SABADO 17H00 PM