Monografias | Sistema Operativo de tiempo real QNX

QNX Software Systems Ltd. fue fundada en 1980 por Gordon Bell y Dan Dodge para desarrollar, mantener y poner en el mercado el sistema operativo de tiempo real QNX que corre bajo procesadores INTEL: 386, 486, Pentiums y sus clones como AMD, Nat Semiconductor, Cyrix y SGS Thompson.

Aún hoy Dan Y Gordon participan en la codificación y desarrollo del sistema operativo QNX.

Siendo totalmente privada y auto-financiada la compañía ha sido redituable todos y cada uno de los años. También ha gozado de un crecimiento excepcional. De hecho, durante la década pasada, expandió sus cuarteles generales cuatro veces su tamaño para manejar el aumento de personal y de producción. Actualmente tiene alrededor de 150 empleados y con un ingreso anual aproximado de $ 24.000.000 por año en ventas. Tiene alrededor de 40 socios distribuidores que sirven a casi 100 países en todo el mundo. Para brindar soporte a la red de distribución en Europa tiene una división, QNX Europe, ubicada cerca de Londres, Inglaterra.

El cuartel general que aloja facilidades para R&D, ventas y marketing y entrenamiento del cliente se ubica en "Silicon Valley North" justo en las afueras de Ottawa, Canada.

Durante más de 20 años, nosotros hemos estado sirviendo las necesidades complejas del mercado del tiempo real (necesidades como alta fiabilidad, superior performance, funcionalidad sofisticada, y masiva escalabilidad). Esto es porque las compañías como 3Com, Motorola, Cisco, Matsushita, IBM, y otros escogen tecnología de QNX para ayudarles a construir aplicaciones fiables en electrónicos, telecomunicaciones, sistemas automotores, instrumentación médica, transporte, puntos de venta, y telefonía. Los productos de QNX son distribuidos en más de 100 países a nivel mundial.

Sus Fundadores

QNX fue creado por dos fundadores y co-presidentes Gordon Bell y Dan Dodge. Existe la leyenda que las primeras ideas surgieron en la época en que se encontraban en la universidad de Waterloo. A principio de los 80 comenzaron a trabajar en un pequeño SO basado en un kernel con pasaje de mensajes cuya interfase de usuario se parecía a la UNIX. Los prototipos eran dos procesadores un 6809 construido por Dan y un 8088 construido por Gordon. Al principio de los 80 IBM lanzó su IBM PC basada en el 8088 y ahí comenzó la carrera. Cerca de 6 meses después de que IBM hiciera su lanzamiento Dan y Gordon hicieron conocido su producto con un aviso en una PC Magazine. Ellos denominaron a su producto QUNIX, dado que era un "Quick UNIX". Llamaron a su compañía Quantum Software Systems Limited. El nombre QUNIX duró un año o dos hasta que recibieron una notificación de AT&T de que debían cambiarlo. Siempre listos para un desafío, cambiaron la forma de escribirlo a QNX pero no cambiaron su pronunciación(se supone que QNX se debe pronunciar "quiunix").

Primeros Pasos

Las primeras betas que se lanzaron no tenían multitasking pero corrían en una IBM PC con solo 64 k de RAM y un floppy de 180k. Después de unos pocos meses se lanzó la versión 1.0 que si soportaba multitasking. Aunque parezca increíble los 64 k de memoria eran suficientes para correr el SO, una shell y aún compilar programas. Es más, es posible que incluso se pudieran hacer trabajos en background, como imprimir un archivo. Un relativamente pequeño grupo de usuarios ambiciosos trabajó con los desarrolladores para reportar bugs y agregar mejoras. Este grupo de personas aún continúa usando QNX o trabajando en la compañía y dando convenciones sobre el producto.

IBM

A medida que el hardware para la IBM PC bajó de precio, los usuarios pudieron aumentar su memoria RAM hasta llegar a los 640k. Dado que esta era una gran cantidad de memoria para QNX, lo que se hacía comúnmente era crear un ram disk de 256k para acelerar la compilación.

Luego aparecieron los floppies de 360K, y los desarrolladores necesitaban dos: uno para alojar el SO y sus utilitarios y el otro para los archivos de entrada de datos.

El próximo gran paso para QNX fue la IBM AT. Las primeras modificaciones permitieron el uso de un procesador mucho más rápido, el 80286 que corría a 6MHz. 6 semanas más tarde ya soportaba el modo protegido. Debido a una impresionante visión de futuro algunos programas soportaban el modo protegido sin necesidad de ser modificados y de hecho ni siquiera se necesitó recompilarlos, a cambio de otros SOs. Siguiendo algunas pequeñas reglas, incluso los drivers podían correr en cualquiera de ambos modos. De esta manera las aplicaciones se hicieron mucho más estables, impidiendo que alguna tarea haga fallar a todo el sistema.

Casi al mismo tiempo de las 286 apareció la QNX Network. Todavía hoy se reportan antiguas versiones de las primeras tarjetas integradas de QNX funcionando.

La primera conferencia fue realizada a mediados de los 80’s en Ottawa. Muchas compañías comenzaron a utilizar QNX en esta época, pero la mayoría en proyectos cuyas características técnicas no llegaban al nivel ejecutivo. Lo que importaba era que funcionaba y por esos días Microsoft anunciaba una nueva versión de DOS que sí iba de verdad, pero de verdad, sí de verdad a ser multitarea, el que fue la primera versión del OS/2.

En el momento en que aparecieron las 386 había otras versiones de UNIX dando vueltas, se comenzaba a hablar de Internet y del código de libre acceso de UNIX. ¿Qué podía hacer QNX para encajar en el mercado y al mismo tiempo distinguirse? La respuesta vino de la mano de POSIX.

Posix

POSIX es una familia de estándares que fueron desarrollados para describir las interfaces de usuario tipo UNIX. Los estándares oficiales POSIX fueron escritos y publicados por la IEEE. POSIX posibilita a los desarrolladores de SOs que sus programas sean compatibles en tiempo de compilación.

QNX soporta los estándares API, estándares de utilitarios y la mayoría de los estándares de tiempo real, conocidos como 1003.1, 1003.2 y 1003.3 respectivamente. QNX no soporta algunos estándares en el cual su inclusión provocaría una limitación en la potencia del SO.

QNX puede compilarse en POSIX sin forzarlo a perder sus subyacentes características de alta performance. Esto es posible porque POSIX describe la interfase, pero no tiene requerimientos en cuanto a su implementación. Esto resultó ser una brillante maniobra. Manteniendo su núcleo subyacente de pasaje de mensajes, QNX mantiene sus características de performance en tiempo real.

En este punto se pensó que si el SO iba a ser reescrito para seguir dichos estándares, porque no se lo podía hacer aún mejor. Entonces se solucionarían muchas de las limitaciones y los cuellos de botella de la versión QNX 2. Esto trajo controversia en algunas personas que deseaban que se siguiera manteniendo la compatibilidad con los viejos procesadores 8088.

Distintos tipos de RTOS

En el mercado actual, los sistemas operativos de tiempo real caen bajo tres categorías principales - ejecutivo de tiempo real, monolítico, y modelo de proceso universal. A continuación explicamos los tres tipos de configuraciones:

Ejecutivo de tiempo real:

Referido a veces por como "kernel" estos sistemas operativos siguen un modelo de sistema operativo de espacio de direccionamiento simple. Todos los módulos de software se alojan en el mismo espacio de direccionamiento que el núcleo del SO, sin protección de la memoria entre las tareas – ya sean tareas de la aplicación o tareas del sistema. Consecuentemente, un solo error de puntero en una aplicación puede corromper las estructuras fundamentales del código o de los datos, dando por resultado una falla general del sistema. Cuando ocurren este tipo de fallos de funcionamiento, puede tomar semanas o meses localizar la fuente, particularmente en sistemas complejos con centenares de módulos. Puede también llevar mucho tiempo agregar o modificar características, puesto que cada cambio del código significa que el núcleo (kernel) tiene que ser reconstruido y reexaminado.

Arquitectura monolítica:

Para corregir algunos de los problemas de la configuración "ejecutivo en tiempo real", algunos vendedores de RTOS han adoptado una arquitectura monolítica. En este modelo, el sistema operativo y todos los servicios fundamentales, tales como file system, residen en un monitor monolítico que se accede a través de un mecanismo de llamada al núcleo. Las llamadas al núcleo hacen la transición del modo aplicación (o usuario) al modo supervisor. Se proporciona protección de modo que solo se puede acceder a recursos del núcleo en modo supervisor; las aplicaciones se ponen en ejecución generalmente como procesos que tienen espacios de direccionamiento separados con protección entre ellos.

Con un monitor monolítico, los servicios fundamentales que requieran acceso a los recursos del núcleo deben residir en este. De esta forma, la complejidad del núcleo aumenta, aumentando la probabilidad de encontrar errores. Asimismo, el acceso a entrada-salida, al vector de interrupciones, y a la memoria física se puede restringir al núcleo por razones de la seguridad, lo que significa que la mayoría de los drivers de dispositivos deben residir en el núcleo. Cruzar la barrera kernel/aplicación es con frecuencia costoso, así pues, en algunos casos, los drivers que de otro modo se podrían poner en ejecución modo usuario, tal como drivers de gráficos, se incorpora en el núcleo por razones de performance. Mientras que las aplicaciones no pueden corromper el núcleo, cualesquiera de estos drivers de dispositivos pueden – aumentando la probabilidad de que ocurran errores fatales.

Modelo de proceso universal:

La configuración "modelo de proceso universal" describe un conjunto de características que se han asociado tradicionalmente a los sistemas operativos de microkernel. Bajo la configuración UPM, un conjunto pequeño de servicios de base reside en el núcleo - tal como mecanismos de comunicación entre procesos y de sincronización. Todo el código restante en el sistema se ejecuta en procesos separados con espacios de direccionamiento de memoria propios, protegidos entre sí. El pasaje de mensajes proporciona a un mecanismo de comunicación al software mediante el cual un proceso puede solicitar un servicio de otro. Los servicios convencionales del sistema operativo, incluyendo los de file system, networking, y drivers de dispositivos, se ponen en ejecución como procesos separados que se ejecutan en su propio espacio de direccionamiento de memoria, protegidos entre sí..

En el caso de los drivers de dispositivos, las rutinas de servicio de interrupciones se limitan a realizar las operaciones de ubicación necesarias, entonces se envía un mensaje asíncrono para activar el proceso que pone el driver de dispositivo apropiado en ejecución. Ya que el costo del paso de mensajes es mínimo, éste método puede competir con el monitor monolítico, evitando la necesidad de realizar demasiadas rutinas de servicio de interrupciones o de poner drivers de dispositivos en el núcleo para mejorar la performance. Dado que los drivers de dispositivos se ejecutan como procesos individuales, pueden también ser comenzados y detenidos sobre la marcha, o ser reiniciados en caso de que ocurra una falla.

Con la configuración de UPM, un fallo en una aplicación no puede dar lugar a un fallo general del sistema – a diferencia del "ejecutivos de tiempo real" - y la falla en un driver de dispositivo tampoco – a diferencia de los "sistemas operativos monolíticos".

QNX 4

Luego de lo que parecieron décadas de espera, se lanzó QNX 4.0, el cual para muchos de los usuarios fue como una beta. Finalmente con la versión QNX4.1 el sistema se volvió mucho más estable. Comenzaron a aparecer noticias sobre una nueva y rápida GUI, denominada Photon. Al poco tiempo apareció QNX 4.2 soportando programas de 32 bits.

QNX 4.24

En las últimas etapas de esta historia la compañía cambió su nombre a QNX Software Systems Limited, ya que el nombre Quantum se confundía con otras compañías de nombres similares y además QSSL quería identificar su nombre más con su producto.

Cuando la última versión QNX 4.24 apareció, la cual incluye a Photon, se lo comparó con una Ferrari con respecto al lento e inestable Win95.

QNX/Neutrino

Pero nada dura para siempre en el rápido mercado de la computación. El sucesor de QNX: QNX/Neutrino ya está disponible, más bien dirigida al mercado de los embebidos.

Futuro

Microsoft parecería que se ha metido en el corazón de todos los mercados corporativos con su producto NT. Lamentablemente ellos se metieron en la cabeza que un SO con una performance bastante pobre y con un Procesador lo suficientemente rápido se puede proveer de un RTOS. Que en realidad, si no les importa es más bien un "soft" RTOS. Tristemente este tipo de pensamiento le quita cierto segmento del mercado a QNX. La pregunta es ¿Tendremos tostadoras eléctricas que deban poseer un Gigabyte de RAM sólo para bootear su SO? El futuro no está escrito.

Alianzas estratégicas

El mercado competitivo de hoy está haciendo ciclos de diseño aun más corto y usando todo lo más importante. Para cortar el tiempo de nuestros clientes para comercializar y hacer sus productos los mejores de su clase, nosotros buscamos funcionalidad industrial específica que complementa nuestra tecnología de OS. De hecho, nosotros dedicamos mucho tiempo y esfuerzo a desarrollar y nutrir relaciones estratégicas con fabricantes de software y de hardware de todos los tipos (los líderes en tecnología del semiconductor, herramientas de desarrollo, protocolos de comunicaciones, y otros). Nuestra larga lista de socios incluyen a AMD, Ampro, Arcom, Force Computers, Hewlett-Packard, IBM, Intel, Metrowerks, Motorola Computer Group, Motorola SPS, NEC, National Semiconductor, PEP Modular Computer, STMicroelectronics, el Sun Microsystems, Sybase, Trillium, y Ziatech. Esta estrategia no sólo nos permite ofrecer los últimos estándares de industria (como CORBA) y las tecnologías más usadas de hoy (como Java), también aseguramos a nuestros clientes recibir una solución integrada cuando nosotros y nuestros socios continúan creciendo.

Filosofía comercial

Nuestro acercamiento a los negocios se basa en la creencia de que todo los tratos con nosotros deben ser simples y convenientes. Por ejemplo, nosotros hacemos nuestro software modular ,no solo por una cuestión técnica sino también de precio, de este modo el cliente pueden mantener los costos al mínimo comprando sólo los módulos que su aplicación necesita.

Nos esforzamos por hacer que nuestro servicio y soporte sean los mejores en el negocio. Se ofrece un servicio de conferencia on line las 24 hs, un directorio de soluciones de tercera partida y una conferencia internacional de tecnología. Nosotros brindamos cuatro niveles de asistencia técnica con varios grados en los servicios por teléfono, fax e e-mail. Y, finalmente, ofrecemos entrenamiento y servicios de consultoría.

Estrategia del producto

Cada vez nosotros desarrollamos un nuevo producto, nosotros tenemos dos metas en mente: reducir el tiempo de nuestros clientes para comercializar y minimizar sus costos. Para este fin, nuestros productos ofrecen:

Mayor funcionalidad en menos memoria:

QNX es el único OS que puede encajar un ambiente POSIX de tiempo real más un sistema completo de windowing en menos de 1M de ROM.

Completa escalabilidad:

Como un verdadero microkernel, QNX es totalmente escalable, así que usted puede usar el mismo OS para todo, desde la electrónica hasta los sistemas de control de manufactura. Incluso nuestro sistema embebido de windowing, el Photon microGUI, es basado en la arquitectura del microkernel. Como resultado, es fácil de construir un GUI para lograr el equilibrio correcto de tamaño y funcionalidad para virtualmente cualquier sistema designado.

Alta Performance:

Con velocidades de cambio de contexto que van de 1.88 microsegundos sobre un Pentium 133MHz hasta los 0.62 microsegundos sobre el más nuevo procesador de Motorola G4, QNX les permite a diseñadores entregar sistemas de tiempo real muy sensibles que encuentran una gama amplia de necesidades de precio-performance.

Conectividad sin costura:

QNX va más allá de TCP/IP y otras normas del conectividad tradicionales para ofrecer conectividad gráfica con Windows 95/98, NT, y X Windows. Como resultado, los diseñadores pueden crear aplicaciones QNX sin dejar de lado su OS de escritorio y puede cada target de las compañías estar designado a otras plataformas de OS.

Adhesión estricta a las normas:

Para aumentar al máximo la portabilidad y minimizar el tiempo de compra, QNX les permite a diseñadores trabajar con APIs estándar de la industria, incluso POSIX. QNX también apoya normas para el Internet, poder de dirección, protocolos de comunicaciones, y más.

Soporte para el último hardware de PC:

De la PC/104 hasta la CompactPCI, QNX soporta más hardware de PC que cualquier otro OS de tiempo real. De hecho, QNX trabaja con los centenares de periféricos, en forma directa.

Soporte Multiplataforma:

Altamente reconocido como el principal OS de tiempo real para los x86, QNX soporta ahora plataformas MIPS y PowerPC. Otras plataformas están bajo desarrollo.

Transparencia de la red:

Todos nuestros productos usan el pasaje de mensajes transparente de red de QNX para acceder todos los recursos del sistema. ¿El resultado? Un ambiente donde los diseñadores pueden poner a punto o pueden controlar los sistemas embebidos remotos de sus escritorios y donde el diskless PCs puede ser usado para reducir los costos del hardware drásticamente.

Líderes del mercado

Durante más de 20 años, los Sistemas de Software QNX han estado poniendo la norma para lo que un sistema operativo de tiempo real debe ser. Durante ese tiempo, el sistema operativo de tiempo real de QNX®, ha evolucionado siendo el primer microkernel para PCs con mejores ventas y el más elegido para las aplicaciones de misión crítica.

En esa evolución QNX ha sido un líder tecnológico. De su debut en 1981, QNX ha disfrutado numerosos triunfos tecnológicos. Por ejemplo, QNX fue el primer OS en integrar proceso distribuido transparente al PC, el primero con tolerancia a falla en la estructura misma, el primero en ofrecer un sistema de windowing de microkernel embebido, el primero con un browser de web de escritorio para los sistemas embebidos, y la lista continua. Ahora nosotros hemos tomado la misma arquitectura del microkernel y se aplicó también a MIPS y procesadores de PowerPC.

Nosotros somos una compañía de OS, pero nosotros también sabemos hay más que el aspecto de desarrollo que simplemente teniendo el OS correcto. Una solución completa es sólo importante al proceso de desarrollo, lo cual es por qué nosotros somos partícipes con los vendedores de herramienta de desarrollo más buenos en la industria.

Aplicaciones que van de los dispositivos embebidos para aplicaciones del servidor, con todo el beneficio de la fiabilidad que QNX ofrece. Por esta razón, y nuestro compromiso de performance y calidad, QNX ha ganado la confianza de compañías como Cisco, Philips, y Siemens para el uso en aplicaciones como las telecomunicaciones, instrumentación médica, y electrónica.

De hecho, más de un millón de copias del QNX OS está trabajando en casi 100 países a nivel mundial, pero nosotros no tenemos ninguna intención de detenernos allí. Nosotros estamos actualmente en el proceso de aumentar nuestra presencia mundial. Las oficinas en los Estados Unidos, Europa, y Asia unen nuestra oficina principal en Kanata, Canadá , junto con nuestra red mundial de distribuidores de QNX, que nos permitirá servir a tantos clientes en forma directa como sea posible.

Desde que QNX apareció por primera vez en el mercado en 1981, QNX Software Systems ha construido una impresionante trayectoria en el campo de las innovaciones tecnológicas.

Arquitectura de microkernel, procesamiento distribuido para PCs y trabajo en red con alta tolerancia a fallas se encuentran entre las tecnologías en las cuales hemos sido pioneros. Nuestra tradición de productos innovadores continúa con el ganador de premios Photon MicroGUI, un sistema con todas las características de las ventanas y aún un sistema totalmente embebido; con QNX/Neutrino, nuestro nuevo microkernel para POSIX para sistemas profundamente embebidos; y con Voyager, el primer buscador de escritorio para la web para sistemas embebidos.

Lideramos la industria del tiempo real no solo en innovación sino también en experiencia. Ningún otro vendedor de sistemas operativos de tiempo real tienen 16 años sobre plataformas x86. Como resultado ningún otro SO de tiempo real ofrece más opciones para este entorno.

QNX también lidera la industria en esta parte del mercado. De acuerdo a un artículo reciente del Emerging Technologies "QNX software systems tiene la porción de mercado más grande de los SO de tiempo real dentro del mercado de las Intel x86". IDC Consulting y First Technology han encontrado resultados similares. De acuerdo con su reciente reporte Industry Report, QSSL tiene alrededor del 22% del mercado, mientras que el próximo mayor competidor tiene tan sólo el 11%.

Nuestros productos y servicios responden a las distintas necesidades de los diseñadores de tiempo real en ambientes críticos. Nosotros entendemos las necesidades especiales de los revendedores (VARs) y de los fabricantes de equipos originales (OEMs) en el mercado de los embebidos. Como resultado, nosotros hemos establecido una base firme en muchos mercados verticales, incluyendo automatización industrial, puntos de venta, telecomunicaciones, y la instrumentación médica. Más recientemente, la confiabilidad de nuestros productos se ha extendido hasta el límite más bajo del mercado de los embebidos, los electrónicos de consumo ( teléfonos para Internet, etc) , la tecnología automotor (como la navegación, dispositivos de control y monitoreo), y dispositivos manuales, por nombrar algunos.

Nuestros Clientes

Con centenares de miles de instalaciones mundiales, el os de tiempo real de QNX está trabajando en el transbordador espacial, en los reactores nucleares, etc.

Nuestros clientes incluyen a:

 

• ABB Automation (manufactura de semiconductores)
• AEG (automatización de máquinas postales)
• AKSYS (dispositivos de hemodiálisis portables)
• Alcatel (dispositivos de automóviles embebidos) Computadoras de abordo
• Atomic Energy of Canada (sistemas SCADA para los reactores CANDU)
• Atomic Energy of Canada (sistemas SCADA para monitoreo y control de los reactores nucleares CANDU)
• Cummins Engine (computadores de abordo - sistema GPS)
• E.I. DuPont (imágenes médicas)
• Eastman Kodak (procesamiento en tiempo real de películas a color)
• Ford Motor Company (sistemas de control activados por voz)
• Honda (control robotizado en la manufactura de automóviles)
• Mitsubishi (sistemas industriales de adquisición de datos)
• Motorola (manufactura de semiconductores)
• Philips (set top boxes, automatización de estaciones de TV)
• Siemens (imágenes médicas)
• VISA international (procesamiento de transacciones y verificación de tarjetas)
• Postal Sorters (US Post Office)
• Driver Training Simulators (Tren EuroTunnel)
• Testing Jet Engines (Imagination Systems)
• Wall Street (Infographics)
• Retail/Inventory Management (JC Penny, The Gap, Pick & Pay)
• POS for Bookstores (Barnes & Noble - Wordstock)
• Voice Messaging (Centigram, Brite Voice)
• Ozone Monitoring (NASA)
• Medical Imaging (Dupont, Siemens, Philips) Tomografía Computada
• Offshore Oil Control/Monitoring (Texaco)
• Energy Management (Johnson Controls)
• Process Control & Monitoring (Coors Beer, Labatts)
• Glass Bottle Manufacture and Inspection (Inex, Emhart Glass)
• 3D Holographic Imaging (VOXEL - General Scanning)
• Blood Analyzers (Beckman, Boehringer Mannheim)
• Set Top TV (Time Warner, Welcome to the Future, Philips)
• Locomotive Control & Monitoring (GE Transportation)
• Security Systems (Chubb)
• Stress Measurement (Burdick)
• Digital EEGs (Nicolet Instruments)
• Vehicle Location and Tracking (Houston Metro)
• Retail POS Terminals (Sears)
• Traffic Light Control (Cities of Toronto & Ottawa
• Fast Food POS (Arby’s, Burger King, Popeye’s, White Castle)
• Factory Cell Control (Samsung)
• Video-on-demand Server (Sony)
• Off-track Betting (Australia, New Zealand)
• F18 Fighter Jet Manufacturing (PACE Controls)
• Factory Automation (IBM, Northern Telecom)
• Cellular Switching Systems (Celcore)
• TV Station Automation (Mitsubishi)

1981:

Primer SO de microkernel para PCs, soportado por la PC de IBM

1982:

Primer SO para PCs que soportó un disco rígido (5MB Davong)

1983:

Primer SO para PCs que corre en una 80286 en modo protegido

1984:

Los primeros en ofrecer procesamiento distribuido transparente para PCs

1985:

Primer SO de tiempo real que corrió en la primera 80386 de Compaq

1990:

Primer microkernel de SO de tiempo real certificado por POSIX

1992:

Primer SO de tiempo real para trabajar en red con tolerancia a fallos (FLEETTM)

1994:

Primer sistema de microkernel con ventanas embebible (el Photon microGUI)

1996:

Primer microkernel basado en POSIX para sistemas profundamente embebidos (QNX/Neutrino)

1997:

El primer buscador de escritorio para la web de sistemas embebidos (Voyager TM) 1998 primero en ajustar un OS, GUI, browser, servidor, marcador, TCP/IP, y más dentro de un disco de 1.44M (1.44M Disco de Demostración)

2000:

Primero en ofrecer un host y plataforma gráfica para los diseñadores de OS embebidos

Premios obtenidos

Dan Dodge recibió en 1998 la medalla de honor Graham de la Universidad de Waterloo(Dan obtuvo su Master de Matemática en esta Universidad en 1981) por la categoría Computación e Innovación.

Voyager ganó el RTS(Real Time System) award. El software de acceso a Internet para TV Set Top Boxes y otros sistemas embebidos, ganó el premio a mejor producto de 1998 en la exhibición de París. Photon obtuvo el mismo premio pero en 1996. La modalidad de elección fue la siguiente: todo producto exhibido puede ser nominado, y los participantes del público votan por los distintos productos.

QNX ganó en 1997, por primera vez, el premio a mejor SO en la categoría de sistemas embebidos de la revista CTI. Entre los concursantes se encontraban más de 40 productos de telefonía.

QNX Software Systems S.A., el principal sistema operativo de tiempo real (RTOS) vendido en el mercado de los sistemas embebidos, fue votado como una de las 50 compañías privadas mejor administradas en Canadá.

Todos los años, la competición de los mejores 50 nacionales de Canadá reconoce a las compañías que han llevado a cabo prácticas comerciales excepcionales. Para ganar, una compañía debe demostrar crecimiento fuerte, firme, servicio del cliente excelente, un equipo motivado de empleados, productos excelentes, y una estrategia comercial eficaz. La competición es patrocinada por The Financial Post, Canadians Airlines, Arthur Andersen Enterpprise Group, y Le Groupe Mallette Maheu.

"Nosotros escogimos QNX Software Systems porque era fuerte en todas las cuatro áreas críticas: empleados, estrategia y visión, satisfacción del cliente, y prácticas comerciales," dijo Mike Runia de Arthur Andersen. "Pero nosotros nos impresionamos sobre todo con los empleados de QNX. No sólo por sus habilidades, sino por su dedicación y la proporción de la producción."

"Premios diferentes que enfocan en un solo logro o servicio, el ' 50 Best' mira los logros de la compañía entera," dijo Dan Dodge, cofundador y CTO de QNX. "Eso es porque es tan importante. Dice que nosotros no ofrecemos sólo productos superiores, sino una compañía sólida, una estrategia legítima, y un registro probado de soporte al cliente."

Las noticias del premio continúan con un año de expansión mayor para QNX. En 1998, la compañía abrió nuevas oficinas a lo largo de Europa y EE.UU.; forjo muchas nuevas alianzas con compañías como Cisco, HP, IBM, Motorola, y Sybase; y, pora primera vez, hizo su tecnología de RTOS disponible en MIPS y mcroprocesadores de PowerPC.

The Financial Post y Arthur Andersen crearon el premio en 1993. Para ser considerado para el premio, las compañías deben someterse a una evaluación formal que incluye entrevistas en profundidad dirigidas por Arthur Andersen. Este año, más de 800 compañías solicitaron el premio. Arthur Andersen seleccionó y entrevistó las mejores 246 solicitudes, y un panel de juicio luego escogió a los 50 ganadores. Todos los ganadores se perfilaron en la edición del 28 de diciembre de 1998 del The Financial Post.

Partners Program

Una vez que usted califica para el Partners Program, usted puede unirse por una cuota introductoria de $395. La cuota inicial cubre el primer año completo de membresía en el programa.

Por este bajo precio, usted consigue:

 

• La suscripción gratis a QNXnews, nuestra revista mundial del usuario, más espacio de anuncio.
• Inscripciones en nuestro sitio web Soluciones de Directorio, Noticias, y Updates del producto.
• Descuentos en los productos de QNX y upgrades .
• Acceso a los programas beta.
• libran materiales promocionales.
• acceso a nuestro servicio de mail directo

   

Las renovaciones son sobre una base anual, para una cuota de $200.

QNX y Educación

Dé la bienvenida a QNX en educación, nuestro programa educativo dedicado a hacer la tecnología de OS de tiempo real de QNX fácilmente accesible a las universidades alrededor del mundo.

Nosotros creemos que nuestra tecnologías de tiempo real de OS hacen una plataforma ideal para el uso en investigación y educación. Cuando un profesor dijo que cuando él cambió de un OS monolítico al microkernel de QNX: "QNX les permite a los estudiantes enfocarse en los problemas propiedad de la propia plataforma, esto ayuda a que ellos sean m'as productivos como ingenieros e investigadores."

Si usted está en el campo de la informática, usted encontrará que nuestras tecnologías de OS modular proveen una prueba ideal para algunos de los últimos OS y conceptos de red. O, si usted está en un campo diferente de estudio, como la robótica, inteligencia artificial, física, telecomunicaciones, ingeniería eléctrica u otro campo que exigen más de un sistema operativo, nuestra tecnología le permitirá que se preocupe menos por la plataforma que está debajo de sus experimentos y más sobre la investigación en s'i.

Para animar a las personas en la comunidad educativa a probar QNX, nosotros hemos establecido la iniciativa de QNX en educación. Nuestra meta es localizar a los estudiantes, personal, y miembros de facultativos alrededor del mundo, para hacer más fácil el acceso a QNX y compartir sus experiencias con otros miembros. Si su aplicación califica para el programa, usted recibirá altos descuentos en el precio y accederá a los recursos de información para ayudar ha hacer un éxito su aplicación de QNX.

Lo que usted consigue:

 

• Software gratis: Cada facultad calificada es elegida para recibir donaciones de software QSSL libre de cargo. Además, otro software vendido por QSSL está disponible a los miembros en un 50% descuento o más.
• Descuentos en documentación impresa: la documentación completa se proporciona libre de cargo con cada producto del software. Además, cada facultad puede calificar para los descuentos de 50% en manuales impresos.
• Descuentos en QNX para entrenadores: QNX ofrece descuentos a educadores para ayudarlos eficazmente a instruir a sus estudiantes en la tecnología de QNX. Hasta un descuento de más del 70%, la facultad puede aprender técnicas de programación de QNX, QNX Neutrino, y/o Photon microGUI de las personas que escribieron el código. Se realizan cursos sobre una base regular en la oficina principal de QNX en Kanata; el espacio está limitado.
• Soporte técnico: Los miembros reciben asistencia técnica las 24 horas en forma gratuita, a través de QNX Developer's Network. Con QDN, los miembros pueden:

   

buscar en una base de conocimiento de más de 1,000 entradas

conseguir "trucos" para la programación de QNX

bajar una variedad de software tercerista

participar en discusiones técnicas con la comunidad de QNX

 

• Suscripción a la revista QNXnews: Las facultades recibirán una subscripción a la revista de QNXnews libre de cargo. Publicado por QSSL, QNXnews mantiene a la comunidad de QNX informada de todas las noticias del producto, innovaciones, y desarrollos que afectan el mundo de QNX. Cada problema incluye historias de la aplicación, inscripciones del código, programación de trucos, y actualizaciones sobre la última tecnología disponible para el mercado embebido.

   

¿Califica Su Escuela?

Para poder ser aceptados en el programa la universidad debe utilizar QNX en una o más de las siguientes formas:

• Como parte de un curso curricular para graduados o estudiantes avanzados
• Como plataforma en un laboratorio de computadoras
• En un proyecto de investigación
• En cualquier otro proyecto que promueva el desarrollo de habilidades programando en QNX.

   

No se consideran aquellos que solo quieren utilizar QNX como plataforma para correr soft de aplicación.

El número mínimo de estudiantes va de acuerdo al tipo de curso o proyecto:

• Proyecto de investigación para graduados: 3 estudiantes
• Curso para graduados: 5 estudiantes
• Curso para no graduados: 25 estudiantes

   

Se tendrá en cuenta la duración del proyecto o curso, siendo favorecidos aquellos que tengan mayor duración.

QNX Training Services

Se ofrecen cursos dictados por técnicos que conocen a fondo a QNX, ya que son los desarrolladores del código.

Los precios de los mismos son:

Programación en tiempo real para el kernel Neutrino -- $1995

Introducción al desarrollo bajo Photon -- $2195

Escritura de un Manager de recursos bajo Neutrino - 1795$

Nadie conoce a los desarrolladores como los mismos desarrolladores de QNX. Las clases son con grupos reducidos, resolución de problemas concretos. El asistente va a estar listo para desarrollar productos bajo entornos de tiempo real, escribir Managers de procesos, aprender el manejo de interrupciones, y más. Una semana de clases puede ahorrarle meses de desarrollo posterior.

Las empresas confían fuertemente en la capacitación dada en la empresa.

¿Qué es QNX®?

QNX es una plataforma de OS de tiempo real que incorpora la arquitectura del modelo de proceso universal (UPM) . La arquitectura de UPM le permite que reduzca el tiempo de desarrollo (recompilar y retestear sin cambiar el kernel, crear drivers que usan herramientas fuente niveladas) mientras se confía en una protección MMU completa.

¿En qué tipos de aplicaciones se usa QNX?

Distribuido mundialmente, la tecnología de QNX brinda una fuente fiable para aplicaciones en telecomunicaciones, electrónicos, sistemas automotores, instrumentación médica, control industrial, y más.

¿Quiénes son clientes de QNX?

QNX se encuentra por encima del millón de instalaciones mundiales. Clientes de QNX incluyen a los líderes de la industria como Motorola, IBM, Matsushita, Siemens, 3Com, y Cisco, por nombrar unos.

¿Cuánto cuesta el SO QNX?

Nosotros sabemos que cada proyecto es diferente, es por eso que hemos adoptado una estructura de precio modular; usted sólo paga por módulos que se usarán en su aplicación. Para obtener precio e información del producto para su próximo proyecto, rellene nuestro formulario online o llámenos a 1 800 363-9001.

¿Cuál es el tamaño de la instalación del SO QNX?

Una instalación del desktop de QNX es aproximadamente de 10M. El Photon microGUI®, que incluye el QNX OS, browser de VoyagerTM, y TCP/IP, requiere más de 160M de espacio del disco.

¿Cómo se autoriza la licencia?

QNX es autorizado por CPU. Si el software autorizado es una versión de multi-computadora, la licencia se emite en el número de nodos. Para más detalles, visite la sección de autorización de nuestro web site.

¿Qué opciones de soporte técnico ofrece QNX?

Como un cliente de QNX, usted puede aprovechar de una variedad de opciones de soporte. Además del QNX Developer's Network (QDN), complete con una base de datos, el software download, y documentos online, también puede comprar paquetes de soporte suplementarios.

¿Qué CPUs soporta QNX?

QNX soporta x86, MIPS, y procesadores de PowerPC.

¿Dónde y cómo compro yo la tecnología de QNX?

Los clientes pueden conseguir más información sobre los productos de QNX de dos maneras:

* Llenar el formulario online

* Llamar al servicio del cliente a 1 800 363-9001

¿Cuál es la última versión de QNX?

Actualmente, nosotros estamos enviando QNX 4.25, QNX Neutrino 2.0, Photon microGUI 1.14, y Voyager 2.0.

¿Soporta QNX IP Networking (TCP/IP, etc.)? QNX soporta varios protocolos networking, incluso TCP/IP, PPP, y SLIP.

¿QNX integró soporte de MMU?

Con la arquitectura modular de QNX, el kernel, servicios de OS, aplicaciones, y drivers todos residen en su propio espacio de dirección de memoria protegida. Eso significa que si un driver o una aplicación falla, el sistema entero no quiere. No sólo esta arquitectura aumenta la fiabilidad del sistema, sino que hace la recuperación de las fallas del software mucho más fácil.

¿Está el entrenamiento técnico disponible para QNX?

QNX ofrece una serie de cursos de entrenamiento en nuestra oficina central en Kanata, Ont. (El entrenamiento en la web también está disponible.). El tamaño de la clase pequeño, resolución practica del problema y ejercicios asegura que los estudiantes tengan el conocimiento que ellos necesitan para aplicar QNX a su proyecto.

¿Hay un grupo de QNX público?

Actualmente, nosotros ejecutamos el QUICS newsgroups para los usuarios de QNX. El sitio es protegido y se limita a usuarios de QNX que tienen un plan de asistencia técnica válido. Sin embargo, nosotros planeamos hacer newsgroups públicos disponible a través de nuestro web site en el 2001. Usted también puede leer y puede anunciar mensajes a comp.os.qnx

Soporte Tecnico

Como un usuario de QNX, usted se vuelve un miembro de nuestra QNX Developer's Network automáticamente (QDN) que incluye:

• Una base de datos de autoayuda
• una colección de grupos de noticias online
• FAQs, whitepapers, y documentación online
• trucos, incluso el código fuente y código ejemplo
• acceso a las últimas actualizaciones y parches

   

Las actualizaciones del software sólo son para los sistemas de desarrollo

Existen representantes de esta firma alrededor del mundo con el fin de proveer al usuario un soporte de acuerdo al lugar donde éste se encuentre. Por esta razón se puede consultar en la República Argentina a la siguiente dirección de correo electrónico: Eldo Loguso: eldo@invisa.com

En la actualidad existen diferentes planes de soporte para los usuarios que poseen productos registrados. De esta manera se trata de brindarle al usuario diferentes alternativas que puedan satisfacer sus necesidades según su desempeño y utilización del sistema.

Servicios On-line:

Sistema de conferencias

Nuestro sistema de conferencia habilitado las 24 horas en línea es una ideal manera de realizar preguntas técnicas y ejemplo de código para nuestros analizadores pertenecientes a nuestra área de expertos de QNX.

Actualizaciones de Software

Acceda a nuestras últimas actualizaciones de software, utilidades lista de problemas conocidos, preguntas frecuentemente realizadas y mucho más a través de nuestro sitio web.

Plan de servicios gratis:

Todos los usuarios de QNX reciben este nivel básico de servicio, que incluye:

 

• Soporte telefónico gratuito (first come, first serve)
• Una suscripción a la revista QNXnews
• Acceso de solo lectura al QUICS (QNX Users Interactive Conferencing System - Sistema de Conferencia Interactiva de usuarios de QNX).
• La habilidad de bajar del QUICS soft gratis y actualizaciones de productos comprados previamente.

   

Plan de servicios standard

Este plan ofrece todos los servicios que se describen más arriba, y además se recibe un conjunto de "créditos" que se pueden utilizar para servicios sobre la base de se "paga lo que se usa".

Una suscripción anual provee 50 créditos. Si se requieren servicios adicionales más allá de la suscripción anual, se puede optar por el Frequent Package User (paquete del usuario frecuente) que provee 150 créditos.

Los créditos se usan de la siguiente forma:

 

• Soporte QUICS: reportar un problema o hacer una pregunta técnica utilizando QUICS cuesta dos créditos.
• Soporte por FAX: mandar un fax al Technical Support cuesta 5 créditos.
• Soporte por Email: hacer una pregunta vía correo privado, usando QUICS o Internet cuesta 5 créditos.

   

Plan de servicios dorado (Gold Service Plan

Los subscriptores de este plan gozan de todos los servicios descritos más arriba además de tener un acceso ilimitado y un tiempo de respuesta garantizado durante las horas comerciales (8:00 am a 6:00 pm EST)

• Soporte telefónico con prioridad (líneas separadas reservadas exclusivamente para los subscriptores del Gold Plan).
• Respuesta dentro de las dos horas
• Respuesta por fax dentro de las 24 horas
• Respuesta por Email dentro de las 24 horas.

   

Casos de estudio de QNX

Para darnos una idea del segmento al que apunta el sistema operativo QNX 4, veremos a continuación algunos casos de estudio, donde se analiza el tipo de problema a enfrentar, las limitaciones y la infraestructura que se cuenta, así como la razón por la que se eligió el sistema operativo y los resultados de la aplicación del mismo.

Aplicación en nuestro país, satélite SAC-C

La era espacial que comenzó en la década del ' 50 calificó poco a poco a países con un alto nivel tecnológico para hacer frente al desafío de poner en el espacio el primer satélite: Sputnik, y al primer astronauta, Yuri Gagarin y previamente a la perrita Laika. El avance ha sido vertiginoso y el conocimiento de nuestro planeta visto desde afuera, además de lo que se ha aprendido de los otros cuerpos celestes, va llevando a la humanidad a palpar una realidad indiscutible: la pertenencia a un todo infinito maravillosamente equilibrado.

La visita que realizó a INVAP (Investigación Aplicada) un técnico de la NASA en el año 1989 dejó sembrada una inquietud: incursionar en la tecnología espacial. Posteriormente la empresa fue calificada y estimulada por otros técnicos de la agencia espacial norteamericana a seguir progresando en la construcción de satélites. Desde estos orígenes casi casuales pero con gran empeño, nace el primer satélite argentino: el SAC-B. Pesó 1.81 Kg y estaba destinado a estudiar aspectos de la física del sol y radiaciones del espacio exterior. Todos sus mecanismos funcionaron a la perfección pero una falla en el lanzador Pegasus de USA desbarató la misión. El segundo de los satélites (SACA), fue puesto en órbita por la tripulación del Endeavour con éxito absoluto, ya que en vez de los 4 meses que debía permanecer en el espacio, permaneció por casi 10 enviando señales y fotos durante todo el tiempo.

La banda de alcance del muestreo

El SAC-C está dispuesto a ser lanzado a bordo de un cohete Delta II desde los EE.UU. en abril próximo. Este satélite es mucho más complejo que los anteriores. Tiene 480 Kg de peso, unos 2.50m de alto por 1 .20m de diámetro; puede reorientarse en órbita, y está provisto de varias cámaras para observar el territorio.

Un satélite se compone de una multitud de sistemas, y subsistamos sutilmente integrados entre sí, pero en lo esencial es un vehículo que lleva lo que uno le quiera poner encima. Es esa "carga útil" la que justifica su lanzamiento. Se trata de instrumentos de medición, cámaras fotográficas o su equivalente electrónico. El vehículo en sí es una estructura que debe contener los elementos básicos parta subsistir en el espacio y para comunicarse con la estación receptora terrestre. La estructura mecánica, que suele ser de aluminio, sostiene todo el conjunto y debe soportar los rigores del espacio, donde, entre un extremo y otro el aparato puede haber una diferencia de temperatura de 150 °C., además de soportar las fuertes aceleraciones y vibraciones que ocurren durante el lanzamiento. La estructura está provista de baterías que alimentan todos los sistemas electrónicos del satélite, y que a su vez son recargadas por medio de paneles de celdas fotovoltaicas que recogen la energía radiante del sol. Otro sistema fundamental de un satélite es el módulo de comunicaciones, por el cual recibe órdenes de tierra y transmite hacia ella las informaciones que va recogiendo a su paso sobre los distintos sectores del planeta. Los satélites más complejos, como el SAC-C, están provistos de órganos que sirven para controlar su orientación y reubicarlos en el espacio. Los mecanismos de muy alta precisión que controlan estas funciones también fueron desarrollados en Bariloche e hicieron su prueba de fuego en el SAC-A Otro de los órganos de reubicación son unos pequeños motores de cohete que tienen la importante función de prolongar notablemente la vida útil del satélite contrarrestando, mientras dura su gas impelente, la natural caída que se produce por efecto del suave rozamiento con restos de atmósfera a 500 o 700 Km de distancia de la superficie de la Tierra. Un impulso de esa naturaleza puede volver a levantar la órbita cuando ha caído unos kilómetros, pero por supuesto llega el momento en que la sustancia que genera su gas impelente se agota fatalmente, marcando el comienzo de una caída que puede ser muy lenta pero se acelera inevitablemente y termina con la caída del satélite hacia las capas más espesas de la atmósfera donde se quema totalmente. Eso es lo que ocurrió con el SAC-A - que no estaba provisto de tales cohetes auxiliares después de diez meses de girar fielmente alrededor de la tierra, cubriendo muchas más veces de las previstas nuestro territorio, y obteniendo miles de fotografías de distintos lugares del planeta. En el desarrollo de un satélite complejo como el SAC-C se re corre un camino que pasa por varias etapas, cada una de las cuales es sometida a un severo proceso de revisión. El diseño preliminar fue sometido a un exhaustivo examen de la ingeniería de todos los sistemas, que consiste en una larga sesión de auditoria de varios días de duración, y en la cual cada detalle es sometido a un escrutinio profundo. Este tipo de examen se repite en varias ocasiones, a medida que se cumplen determinadas etapas del diseño y de la construcción del aparato. En el caso del SAC-A la última de estas auditorias fue efectuada poco antes del lanzamiento - con el satélite ya terminado- por los responsables de su puesta en órbita. Tuvimos entonces el privilegio de albergar en Bariloche a cuatro de los integrantes del transbordador Endeavour, entre ellos el jefe de la misión, el comandante Cabana.

Cuando se diseña y construye un satélite el proceso pasa por numerosas etapas e ensayos, ya que el costo de cualquier falla puede ser el fracaso de la misión. Por lo tanto se construyen varios modelos del satélite: un modelo de ingeniería, que es sometido a todas las vibraciones que deberá soportar el satélite, sobre todo durante su lanzamiento, ya que una vez en órbita todo es suavidad; un modelo térmico, sobre el que se realizan otros ensayos pues estará sujeto agraves tensiones debido a las grandes diferencias de temperatura entre el lado que mira hacia el sol y el que está a la sombra. Finalmente se construye el "modelo de vuelo" que también es sometido a toda clase de esfuerzos y ensayos. Gran parte de todos estos ensayos son los que se han llevado a cabo en las instalaciones del organismo espacial brasileño, donde está depositado ala espera de su traslado a EE.UU. para su puesta en órbita en el próximo mes de abril. En realidad el SAC-C es un proyecto multinacional. Los países que participan son cinco, además de Argentina. EE.UU., además de efectuar la puesta en órbita, ha construido uno de los experimentos que van a bordo del SAC-C. Dinamarca ha colocado un sistema de medición de anomalías del campo magnético terrestre; Italia ha suministrado los paneles solares que alimentarán de energía al conjunto y los instrumentos que determinan la posición del satélite, y Francia que ha colocado a bordo un instrumento de medición de niveles de radiación por electrones, protones e iones pesados en la baja atmósfera. El SAC-C lleva tres cámaras de registro fotográfico. Las principales de estas cámaras fueron también diseñadas y construidas en Bariloche, y con ellas se puede obtener gran cantidad de información acerca del estado de bosques y cosechas, desertificación, contaminación del mar, etcétera.

El SAC-C tendrá un tiempo de revista de nueve días, es decir que cada nueve días recorre exactamente la misma órbita, lo que permite seguir los procesos que ocurren en el suelo debajo de él con esa resolución temporal. Sin embargo existe una posibilidad de ver procesos más veloces, ya que cada cuatro días el satélite pasa lo bastante cerca de cada sitio preestablecido como para que, con una leve inclinación de su eje se puedan recoger las imágenes deseadas. El SAC-C también permite observar a las ballenas aún sumergidas a gran profundidad. El cuarto satélite argentino, cuyo diseño ya ha comenzado se denomina SAOCOM (Satélite Argentino de Observación y comunicaciones) será mucho más complejo, ya que estará provisto de un radar que permite entre otras cosas, atravesar las nubes y las copas de los árboles, ver de noche y hasta cierto punto, penetrar en el suelo terráqueo. Esto le permite determinar el grado de humedad y hasta detectar la profundidad, el recorrido y el estado de las napas freáticas. Se estima que este satélite estará listo en 2003. Un laboratorio satelital como el desarrollado por INVAP en la zona de Llao-Llao en Bariloche, tiene parecidos con un quirófano, también con instalaciones futuristas tal como lo muestran las películas, esto se debe a que la construcción de un equipo destinado a atravesar el espacio, lejos de toda posibilidad de reparación, debe estar hecho a prueba de fallas, y eso implica un grado de limpieza muy superior al que debe regir en una sala de operaciones. En efecto, una partícula de polvo depositada en un contacto eléctrico en el vacío sideral puede producir una falla que ponga en peligro misiones muy costosas. Desde La Patagonia y en conjunto con la CONAE , el INVAP busca una salida internacional para el desarrollo de sistemas de tratamiento de las imágenes satelitales. Así Patagonia se proyecta más allá de los límites de la Tierra, con tecnologías propias y desarrollo científico.

Los datos del SAC-C serán adquiridos en la Estación Terrena Córdoba del Centro Espacial Teófilo Tabanera (CETT), desde donde, además , se realizará el control de la Misión, el tiempo disponible para la adquisición de datos del relevamiento y de estado del sistema, así como para la corrección de inconvenientes es de 12 minutos.

También se dispondrá de al menos tres estaciones secundarias de bajo costo ubicadas en distintas regiones del país, las que permitirán obtener en tiempo real imágenes de baja resolución de la cámara MMRS.

Estación de monitoreo remoto.

El satélite para realizar las tareas de control cuenta con tres procesadores Intel 486 DX 4 de 100Mhz corriendo con lógica de mayoría, para evitar fallas por mal funcionamiento de alguno de los procesadores, no se cuenta con discos rígidos (ya que son muy sensibles a campos magnéticos y cambios de temperatura frecuentes en el espacio), los datos muestrados son almacenados en memoria por lo que si no pueden ser transmitidos a la base terrestre los mismos se pierden. El sistema operativo utilizado es QNX 4, tanto en el satélite como en las estaciones de adquisición de datos y mantenimiento, por las siguientes razones:

 

• El tiempo es una variable crucial debido al bajo ancho de banda de las antenas digitales utilizadas para la transmisión (0.2 Mb/seg), y no se pueden permitir fallos debido a una mala performance de SO.
• Un satélite espacial de estas característica tiene un costo de alrededor de 40 millones de dólares, por lo que tiene que ser "A prueba de fallos"
• Se prevé una vida útil del satélite de 4 años, tiempo en el que el sistema operativo debe funcionar correctamente.
• Es posible que se deba modificar código en tierra, en caso de fallos, para luego ser levantado al satélite, QNX permite este tipo de manejo.
• El presupuesto fue acotado, por lo que no se contaba con computadoras de elevadas prestaciones.
• La capacidad del SO operativo de manejar gran cantidad de puertos serie aporta grandes beneficios, ya que utilizando una interfase estadard (RS 232), los procesadores pueden acceder a los diversos subsistamos.
• La posibilidad de mutile procesamiento con arrebato por prioridades fue un aspecto decisivo en la selección del SO.
• Los Técnicos de INVAP tenían conocimiento de desarrollo con el compilador de C Watcom.

El SAC-C en la etapa de ensamblaje

INVAP también utilizó este sistema operativo como software de base para los sistemas de control de un reactor nuclear que contruyó para Egipto. Recientemente la empresa Argentino ganó una licitación por 180 millones de dólares estadounidences para la construcción de un nuevo reactor en Australia y dado los buenos resultados obtenidos en el primero, también será utilizado para este nuevo proyecto.

La creación de COG el RoboBaby.

Las películas ciencia-ficción están llenas de ellos. Robots caminando y hablando como humanos. De hecho, desde que el campo de la inteligencia artificial nació, la gente ha soñado con robots que no solamente se parecen a seres humanos sino que pueden pensar, sentir, aprender, y cometer errores - casi como actuamos en la vida real.

El laboratorio de inteligencia artificial del MIT ha tenido éxito en hacer verdadera la ciencia-ficción con COG, un robot con forma humana que se está en desarrollo desde los ' 90s. Aunque carece piernas y espina dorsal flexible, COG es casi tan humano como un robot puede ser. Tiene una cabeza, un tronco, y los brazos son similares en dimensión, estructura, y grados de libertad a los del cuerpo humano. Un conjunto sofisticado de sensores y de actuadores coordinados con un sistema de control distribuido basado en QNX se aproxima la dinámica sensorial y motora humana con exactitud misteriosa.

Como los seres humanos, COG puede oír. Un par de micrófonos que hacen las veces de oído se montan directamente sobre su cabeza. COG puede también ver. El sistema visual del robot copia algunas capacidades visuales humanas, incluyendo la detección binocular y la sensación espacio-variante. Dos cámaras de escala de grises en cada 'ojo' permiten a COG un campo visual ancho y visión de alta resolución. COG incluso tiene un sistema vesti-bular, que en seres humanos mide la aceleración de la rotación de la cabeza y que es crítica en la coordinación de las respuestas motoras, del movimiento de los ojos, de la postura, y del balance. COG imita este sistema con tres giroscopios y dos acelerómetros lineares montados en la cabeza del robot. Los sistemas recepción vocal y táctil están en desarrollo.

Para los investigadores del MIT, conseguir que COG se vea y sienta como humano va más allá del plano estético - es fundamental en su investigación. COG está aprendiendo pensar como un ser humano. Con este ROBOT, el MIT está explorando la teoría de la encarnación, o la creencia que la cognición humana está desarrollada con la interacción del cuerpo físico con sus alrededores y otros seres humanos. Así pues, en vez de la preprogramación con la información detallada sobre su ambiente, COG está aprendiendo todo sobre sí mismo y el mundo casi como lo hacen los bebés - por el ensayo y el error.

El control computacional de COG es una red heterogénea de diversos tipos de procesadores que funcionan en diversos niveles de la jerarquía de control. El cerebro de COG, que consistía en una red de microcontroladores Motorola 68332 de 16MHz conectada a través de una RAM dual-port, ahora es una red de PCs industriales de 200MHz que ejecutan QNX conectadas mediante una topología Ethernet 100GV. Los cerebros viejos y nuevos se comunican vía una tarjeta de memoria compartida ISA hecha a medida. Como con todos los sistemas QNX, la red puede ser ampliada agregando nuevos nodos en el HUB de la red. La red también incluye display boards, y puertos de entrada-salida de audio. Otros procesadores que controlan las funciones corporales de COG van desde pequeños microcontroladores para el control de empalme a nivel de red hasta procesadores de señal digital (DSP) para pre-proceso de audio y vídeo.

Cuando se preguntó por qué QNX fue elegido para su proyecto a Matt Marjanovic, investigador del MIT, explicó: "con COG, obviamente hay un requisito visual y auditivo de tiempo real. Deseamos un SO que pueda cumplir con esto de modo que COG pueda percibir a la gente e interactuar con ellos. El establecimiento de una red transparente es también un gran extra. COG tiene ocho nodos QNX en este momento, y todos son accesados desde el servidor primario. También es muy conveniente desarrollar y ejecutar código remotamente. Tenemos a menudo varios estudiantes graduados que desarrollan código al mismo tiempo, algunos en el sistema, algunos en sus oficinas, y otros en sus casas.

QNX se ha utilizado con tanto éxito con el proyecto COG que ahora todas los robots del laboratorio se están construyendo alrededor del SO. Esto incluye un robot de alto perfil que el MIT nombró Kismet, diseñado para estudiar las emociones humanas del cual se ofrece una nota completa en la edición de octubre de 1999 de Discover Magazine. Dice la investigadora del MIT, Cynthia Breazeal, " es nuestra meta para hacer que todas los robots compartan la misma plataforma de cómputo para poder compartir el código a través de proyectos.

Desde su 'nacimiento' COG ha aprendido a darse vuelta y fijar la vista en un objeto móvil, imitar movimientos de cabeza afirmativos y negativos, estirarse para tocar objetos, y jugar con un juguete Slinky. Lo más importante, es que COG ha aprendido reconocer las caras y los ojos - el primer paso de progresión hacia interacciones sociales realistas. Y aunque COG no puede todavía ser considerado consciente, con este robot el MIT está cumpliendo un sueño que existe desde hace mucho tiempo, el de fabricar inteligencia humana a través de computadoras y tecnología robótica. Recientemente, el libro de los récords Guinness 2000 (edición del milenio) nombró a COG ' el robot más inteligente. '

Desde que las discusiones por lograr la restricción de pruebas nucleares comenzaron al inicio de los ' 50s, varios tratados han sido puestos en ejecución por la comunidad internacional para restringir el testeo de armas nucleares en el espacio, en la atmósfera, y bajo el agua. Pero ninguno ha ido tan lejos como para prohibir todas las pruebas de armas nucleares. Es decir, hasta que la asamblea general de la ONU votó el septiembre de 1999 de forma aplastante para adoptar el tratado Comprehensive Nuclear Test Ban Treaty (CTBT), que busca terminar con todo tipo de actividad nuclear.

La firma del tratado fue la parte fácil, comparada con la tarea de asegurarse de que todas las naciones cumplan con el tratado. Cerciorándose de que el CTBT se adopta globalmente, sobre todo en la capacidad de detectar violaciones. Para este fin, las naciones que firman el tratado están poniendo el sistema de monitoreo internacional (IMS), una red de centros de datos y varias tecnologías de verificación - sísmicas, infrasonido, hidroacoústicas, etcétera - para buscar para y para analizar las pistas que indican la prueba nuclear ilegal.

Tal tecnología de verificación es el Radionuclide Aerosol Sampler/Analyzer (RASA), una tecnología basada en QNX que ha sido desarrollada por el departamento de energía del laboratorio nacional de Pacific Northwest, en Richland, USA. RASA es un sistema que detecta radionúcleos aerotransportados – elementos de especies radiactivas como el bario, molibdeno, etcétera - que son liberados en la atmósfera por una explosión nuclear. La importancia de esta tecnología es la detección de radionúcleos que a diferencia del infrasonido, o las tecnologías hidroacoústicas de detección, proporciona una evidencia física irrefutable de violación del tratado porque captura las piezas más pequeñas del arma misma.

Para diseñar un dispositivo de detección de radionúcleos para el IMS, tuvimos que mantener varios factores firmemente en la vanguardia. Primero, el sistema de medición tuvo que ser capaz de detectar cantidades muy pequeñas de material radiactivo. Dependiendo de condiciones atmosféricas en el momento de la explosión los radionúcleos pueden viajar a desde una punta del globo terráqueo a otra y tener varios días para el momento en que alcancen una estación de medición. Para ese momento, los elementos con un período de vida corto habrán desaparecido, dejando solamente una pequeña fracción del material radiactivo original. En segundo lugar, tuvimos que pensar mucho en el costo total del sistema. Nuestros planes requerían 80 estaciones de medición mundial para mejorar las posibilidades de que una nube radiactiva sea detectada dentro de las primeras semanas críticas después de la detonación. Así pues, el sistema tuvo que ser accesible para todos los países, incluyendo países en desarrollo.

En tercer lugar, y más importante, ya que algunos de los detectores serán colocados en posiciones remotas, tuvimos que desarrollar un sistema totalmente automatizado que pueda estar en ejecución por varios meses continuos sin volver a reiniciarse. En RASA Manejamos todos estos requisitos, y más. Suficientemente sensible como para detectar una explosión nuclear incluso después que la nube de escombros radiactivos haya viajado totalmente alrededor del globo, RASA puede ejecutarse continuamente por 200 días sin volver a reiniciarse y tiene acceso y control remoto completo. RASA es también accesible, suficientemente silencioso como para no molestar en áreas residenciales próximas, y consume potencia mínima. Puede incluso tolerar cortes de energía!

Asemejándose a un horno pequeño en tamaño y forma (3 ' x 6 ' x 6 '), el muestreador de radionúcleos contiene un 486 Ziatech 8902corriendo QNX 4 y el sistema de medición físico: compuesto por un conjunto de tiras continuas de papel de filtro, de una pista dividida en segmentos de muestreo, y de un detector de alta resolución de rayos gama de germanio. Las tiras de papel se avanzan mecánicamente en la pista de muestreo a través de la cual los volúmenes grandes de aire se filtran. Después de un período de decaimiento, las tiras se ponen delante del detector de rayos gama. Para vigilar las condiciones de funcionamiento y los registros de ambiente de RASA, el sistema también incluye sensores secundarios para la temperatura, tensión, la velocidad del aire, y otras condiciones ambientales.

Una de nuestras primeras tareas era seleccionar un SO para el proyecto. En diciembre de 1992 repasamos varios sistemas operativos y elegimos QNX porque ofreció un sistema de control en tiempo real robusto y un método confiable para comunicar datos y comandos hacia y desde los varios centros de datos. Un sistema operativo estable era también un requisito crucial para RASA porque sabíamos que un tiempo medio de buen funcionamiento (MTBF) y un tiempo medio de reparación (MTTR) con valores inaceptables podría promover o romper la aceptación internacional de nuestro sistema. Sabíamos que QNX tenía un buen expediente en sistemas críticos. QNX tenía otras características tentadoras también, incluyendo un esquema IPC simple, capacidad de multitasking, conectividad TCP/IP, y compilación POSIX. Aunque no teníamos ninguna experiencia anterior con multitarea con arrebato (preemptive multitasking) y una arquitectura de paso de mensajes, aprendimos rápidamente el valor de estas características mientras que progresó el proyecto.

Cuando comenzamos el desarrollo, el CTBT todavía no estaba firmado así que las guías de consulta técnicas y políticas eran revisadas constantemente; por necesidad, encaramos el proyecto con modularidad en mente. Comenzando con un análisis orientado a objetos para el software de control, escribimos todo el software de control para el sistema RASA en C++ e hicimos uso extenso de clases de objetos de C++ en todas partes. Por ejemplo, todos los servidores se derivan de un objeto common-base-server que da a cada servidor un conjunto idéntico de capacidades de base (ej. ping, shutdown) y de una interfase consistente de paso de mensajes. Esta metodología orientada a objetos también aumentó considerablemente nuestra capacidad de mantener el sistema y de reutilizar nuestro código.

Este análisis modular nos dejó separar el software de control de los procesos específicos de hardware del servidor. El acceso a la interfase de hardware es proporcionado por procesos de I/O digitales y analógicos del servidor – que son los únicos procesos que tienen acceso directo al hardware subyacente. El resto de los procesos tienen acceso al hardware a través de peticiones enviadas a los procesos del servidor.

El servidor analógico presenta un conjunto secuencial de canales analógicos al cliente, cada uno de los cuales puede marcar de 0 a 10V. Internamente, los canales correspondientes no tienen que ser secuenciales o aún existir en la misma placa analógica. De hecho, es posible utilizar múltiples placas de diversos fabricantes simultáneamente: el set canales de la entrada de cada tarjeta puede ser mapeado en el espacio del canal lógico-secuencial presentado por el servidor. Un mapeo similar del canal físico-a-lógico es realizado por el servidor digital de entrada-salida.

Como trabajamos a través de varios prototipos de RASA esta técnica permitió cambiar el hardware subyacente sin afectar a ninguno de los clientes que requerían servicios digitales o analógicos. También, permitió que solamente un solo proceso tenga acceso al hardware directamente, evitamos conflictos entre los servidores múltiples que procuraban el acceso simultáneo al hardware. El sistema operativo arma colas de peticiones a servidor automáticamente, que luego son manejadas secuencialmente por el mismo.

A medida que nos trasladamos a un sistema del campo automatizado, la abstracción del hardware permitió que el equipo de software continuara trabajando aun con cambios y mejoras del hardware. Sin la abstracción del hardware, los cambios en el hardware habrían requerido cambios en los módulos de control. Con la abstracción, sólo el servidor de procesos de hardware específico tuvo que ser cambiado, e hizo ahorrar mucho tiempo.

Finalmente, el multiprocesamiento con arrebato de procesador propio de QNX permitió que desarrollásemos procesos eficientes para tareas específicas. Integrar estos procesos en una estructurade control robusta y unificada fue fácil gracias al pasaje de mensajes de QNX.

Cada subsistema de RASA o grupo de componentes relacionados (ej: sensores de temperatura) son gobernados por un proceso separado del servidor. El monitor de potencia del sistema, el acumulador de volumen de aire, el monitor del sensor, el control de datos meteorológicos, el sistema de adquisición de datos nucleares, y todos los controles del motor se comunican con el hardware a través de los servidores digitales / analógicos o a través de una interfase RS-232 proporcionada por QNX. Estos servidores presentan las interfaces al cliente que se relaciona con el dispositivo controlado o la cantidad medida, a diferencia de las señales reales de hardware que facilitan los controles y las mediciones. Por ejemplo, el servidor de sensores responderá a mensajes de la forma " qué temperatura tiene el aire de producto? " En comparación con "qué tensión está marcando el canal analógico 4?" El servidor de sensores responde a esta clase de mensaje obteniendo el voltaje apropiado del sensor del servidor analógico y convirtiéndolo a las unidades de temperatura antes de pasar la respuesta de nuevo al solicitante original.

Esta capa de abstracción agregada libera al cliente de tener que ocuparse de los detalles exactos de la conversión. No es necesario que el cliente sepa que el sensor de temperatura que está siendo consultado devuelve una tensión análoga. De hecho, en el comienzo del desarrollo de RASA, se investigaron varias tecnologías de sensores, incluyendo sensores de temperatura que indicaban a través de señales digitales, tensiones analógicas, e incluso secuencias de datos RS-232. Actualmente RASA usa solo sensores de temperatura analógicos, pero cualquier combinación de las tecnologías antedichas pueden ser substituidas sin realizar ningún cambio al software por sobre el nivel del servidor de sensores.

Una GUI (Graphic User Interface, o interface gráfica de usuario) fácil de utilizar es un requisito básico para la mayoría de las aplicaciones actuales, y RASA no fue diferente. Teniendo presente que este sistema sería utilizado eventualmente por todo el mundo, colocamos la X para el proyecto principalmente porque los servidores X se ejecutan en una variedad amplia de plataformas de cómputo. Utilizamos la herramienta de desarrollo para Xwindows que viene con QNX junto con Tcl/Tk, un lenguaje scripting de alto nivel que acortó considerablemente nuestro tiempo de desarrollo. Tcl/Tk permitió que escribiéramos en apenas algunas líneas lo qué habría requerido varias paginas de código XWindows. El lenguaje se puede también ampliar fácilmente para crear nuevos comandos. Por ejemplo, desarrollamos comandos Tcl/Tk específicos para RASA que pasan mensajes entre los distintos servidores de procesos de RASA.

Porque planteamos el subsistema de comunicaciones de forma modular también, RASA se puede configurar para utilizar cualquiera de los diversos métodos de comunicación. Internet proporciona el camino de comunicaciones más rápido al sistema. Sin embargo, puesto que en muchos lugares del mundo no tienen acceso Internet, diseñamos RASA para utilizar lans basadas en líneas telefónicas y módems estándares, o líneas celulares o módems basados en satélites - lo que más convenga para el caso.

Una serie de diseños del sistema RASA fueron construidos y probados desde que el proyecto comenzó. RASA Mark 3, el tercer prototipo y el primer sistema totalmente autómata, participo en una prueba de campo extensa en la base de fuerza aérea de McClelland en julio de 1995. La prueba de campo fue pensada para descubrir componentes y subsistamos inadecuados para instalaciones remotas, y durante el curso de la prueba de seis semanas de duración, varios sensores de temperatura, sensores ópticos, fuentes de alimentación, sensores de tensión, y otros componentes fallaron. Pero QNX no falló y siempre nos permitió el acceso al sistema para consultar el estado de los servidores individuales, e hizo el diagnóstico de los datos del día - incluso cuando el software de control estaba colgado!

Fuimos capaces de hacer muchas mejoras y correcciones del software en ejecución remotamente. Por ejemplo, en un punto teníamos problemas con la lógica en los sensores ópticos - que vigilan el adelanto del papel de filtro. Una batería de tres sensores fue utilizada en un modo mayoría lógica para evitar posibles fallas. Durante la prueba, control de estado reveló un sensor continuamente ruidoso, mientras que un segundo sensor solamente hizo pequeñas variaciones impresas que hicieron avanzar el papel. Esta situación haría que el papel de filtro no alcance para el período planeado. Pudimos sustituir el código defectuoso de mayoría lógica por código lógica unánime, y solucionamos el problema sin una visita al sitio. Estas pruebas de campo son solo el comienzo del camino para RASA. El sistema hará frente incluso a desafíos más grandes cuando sea instalado en los diversos climas tales como la Antártida, Hawaii, Guam, y Alaska. Pero es tranquilizante saber que si hay problemas, pueden ser diagnosticados y solucionados a miles de kilómetros del sitio.

Un servidor Web basado en QNX

¿Quién utiliza QNX 3,5 millones de veces a la semana? Los fanáticos de los deportes. ¿Por qué? Para conseguir la información del minuto sobre sus equipos y jugadores preferidos. En vez de ver la TV o de escuchar la radio, esta gente está visitando el Web site basado en QNX http://www.nando.net, donde se ensamblan y se ponen las noticias de los deportes del mundo disponibles para Internet vía SportServ. SportServ es mantenido por la división New Media del periódico News and Observer de Raleigh, Carolina del Norte. El periódico formó NandO.net hace dos años y medio, basado en la predicción que la salida electrónica de las noticias complementaría la salida en papel en un corto plazo y quizás para substituirlo a largo plazo. Según Charles Hall, miembro del personal técnico en NandO.net, "los periódicos en papel quedaron años atrás. El número total de lectores de menos de 30 es pequeño y sigue disminuyendo. Los costos del papel continúan elevándose. La única pregunta es cuál será el medio sucesor" Desde que NandO.net comenzó su operación, la gerencia se ha centrado en proporcionar contenido además de solo conectividad. Además de contar con todo el equipo de un ISP, la división tiene personal que genera noticias y además las compra a distintas fuentes de noticias. Las fuentes de noticias incluyen a Tribune Media Service, AP Market Reports, y SportsTicker, la fuente del contenido de SportServ.

La maquinaria para Internet de NandO.net's consiste actualmente de un Sparc 20s, un Sparc ultra 170s, una estación de trabajo Indy de SGI, y, desde febrero del año pasado, una PC con QNX. Las computadoras están conectadas unas a otras con FDDI, y a Internet con dos T1s (1,5 Mbit/sec), y con los usuarios con ochocientas líneas telefónicas. Uno de los T1 va a Sprint en Texas; el otro al MCI en Atlanta. El sitio pronto substituirá uno de los T1s por una T3 parcial para alcanzar un ancho de banda de 6 Mbit/sec.

Con todos estas estaciones de trabajo caras, por qué utilizar QNX? Porque los satélites no tienen control de flujo y las noticias son entregadas por estos. El tráfico es pesado y no hay manera de retrasar la alimentación o de solicitar un paquete faltante. QNX hace lo que el tiempo compartido de Solaris o de los Unix no puede hacer: operar con un tiempo de reacción determinista. Mientras que la estación de trabajo Indy de SGI está ocupada en determinar qué proceso intercambiar a disco, la PC con QNX está haciendo el parsing del flujo de entrada.

La aplicación en sí misma es muy simple. QNX 4 está instalado en una PC 486 DX2/66 con 16Mb de RAM, un disco rígido de 1Gb, una placa serie Connect Tech Intellicon 8, y una placa de red. Los módems basados en satélites están conectados con los puertos serie Connect Tech y el disco duro está montado en NFS a la estación de trabajo SGI que ejecuta el software de Web. Un editor de flujo configurable, escrito en C, analiza los flujos de noticias y escribe los resultados y las estadísticas en los archivos en el disco. Cada flujo de noticias se dirige a su propio directorio separado de modo que los editores de HTML no confundan el precio de los productos de IBM's con los resultados del playoff de los Chicago Bulls!

Muchos hits pero ningún Knock Out

En total, los usuarios locales y los de Internet generan 7,3 millones de hits, al sitio NandO.net cada semana. SportServ basado en QNX toma 3,5 millones de éstos hits, haciéndose la aplicación más popular. Después de un año de la operación, la PC con QNX continúa manejando todo este tráfico sin problemas. El cliente reinició la máquina cuando en la estación de trabajo de SGI se modificó el código de NFS, pero incluso eso no era necesario. Porque en la máquina que se está ejecutando QNX, solo bastaba con simplemente matar el proceso del servidor y reiniciar el mismo.

En los dos años de operación el personal de NandO.net ha aprendido mucho sobre proporcionar a servicios Internet. Por ejemplo, como se amplían, se preponen guardar la relación de 1:10 de las líneas telefónicas con sus clientes. También, ahora se dan cuenta que no pueden continuar proporcionando su servicio usando pocas estaciones de trabajo muy "cargadas". En consecuencia, están planeando un experimento en el cual substituyan al Sparc 20s y ultra 170s por un grupo de servidores Pentium. Aunque se necesitarán más maquinas, el bajo precio de las PC reducirá el costo del sistema. Y es más, las CPUs adicionales disminuirán tiempos de procesos y reducirán cuellos de botella.

Automatización

Motorola hace Control de calidad con QNX y RAIMA

Motorola Inc´s Metal Oxide Semiconductor Fabrication Plant 8 (MOS8) en Austin, Texas.

En esta planta de Motorola se utiliza un proceso de control estadístico (SPC) que permite encontrar desvíos en los parámetros de cualquier proceso, para evitar que tales desvíos amenacen la integridad del proceso y del producto final.

La aplicación SPC corre 24 horas del día, los siete días de la semana y es parte de Synapse, un sistema integrado de manufactura basado en QNX dentro MOS8. Synapse SPC está hecho totalmente para misiones críticas. Si se cae, la fábrica se cae.

SPC no es solo confiable sino que también es lo suficientemente sofisticado como para haber ganado un premio a la innovación en MOS8. Aún así, puede correr en las PC standard.

En MOS8 el Synapse SPC toma información de alrededor de 140 computadoras en red, que unen 50 tipos distintos de equipos de manufactura, alrededor de 600 procesos en las máquinas en total.

Fabricación de chocolates en Cadbury(sucursal Canadá)

La mencionada empresa poseía un sistema de control de planta basado en MS Windows, con una interfase de Touch Screen, y un PLC basado en Windows para dialogar con un PLC Siemens. El resultado: una calamidad. El sistema era inestable, completamente ineficiente para controlar el proceso. Por ejemplo, el sistema tenía respuestas muy lentas, y la comunicación con el PLC expiraba, y se perdían datos. Consecuentemente, el operador debía operar el sistema manualmente para concluir el resto del ciclo, produciendo muchos desvíos en los tiempos de producción, y desperdicio de mercadería. Cadbury gastó un año en tratar que este sistema funcionara, y en definitiva nos contrató a nosotros para que le diéramos la mejor solución.

Para minimizar los costos de la inversión que Cadbury había hecho en su sistema, se mantuvo el sistema InTouch basado en Windows para la interface. Para la otra parte se utilizó la capacidad de Networking transparente de alta velocidad de QNX, se utilizó el lenguaje de programación SCADALisp para los drivers de comunicación con los PLCs. Usamos la capacidad del scheduling por prioridades para correr este driver en máxima prioridad, y por consiguiente se logró evitar que otras tareas cortaran la comunicación del driver. El sistema original InTouch corría en una 486 con Windows 3.11. Las computadoras QNX y Windows fueron conectadas con un sistema de fibra óptica bidireccional, lo cual proveyó respuesta de tiempo real. Como protocolo de comunicaciones se usó TCP/IP.

El resultado fue que Windows tiene más recursos de sistema para correr y ser más estable. Los operarios deben rebootear Windows una vez cada varios días y cuando lo hacen QNX sigue teniendo el control de las tareas de la planta.

Estadísticas:

 

• 50% de aumento de producción, simplemente usando el equipamiento más eficientemente.
• Reducción en las variaciones de producción a menos del 1%.
• Prácticamente 0 errores de operación y 0 fallas del sistema.
• Aumento de datos disponibles para análisis por parte de operarios y managers.

   

Consorcio para automatizar las autopistas

Imagine ir conduciendo su automóvil por una rampa de una autopista y dejar que una computadora tome el control. Aunque esto pueda parecer futurista puede ser real dentro de unos pocos años.

El Departamento de Transporte de los Estados Unidos estima que los vehículos automatizados pueden mejorar el tránsito en las autopistas y al mismo tiempo incrementar la seguridad. Un consorcio que planea automatizar las autopistas en el siglo XXI ha sido formado recientemente por California Partners for Advance Transit and Higways (PATH), Caltrans, GM, Hughes Aircraft y más de 30 compañías de las industrias aerospaciales y automotrices.

Durante los últimos 8 años PATH ha estudiado el concepto de vehículos automatizados. El grupo equipa autos donados por los fabricantes con dispositivos de control y los testea en secciones cerradas de las autopistas. Información de tiempo real tal como distancia de seguimiento, velocidad relativa, aceleración e información acerca de vehículos precedentes llega desde los sensores del motor del vehículo, de la transmisión, ABS, y otros sensores y es procesada en una PC industrial que se encuentra a bordo de 33MHz 80486 que corre con QNX 4.2.

Este nuevo consorcio va a continuar utilizando QNX en todos los vehículos que estudia y espera demostrar la posibilidad de los vehículos automatizados por 1997 y proveer especificaciones para un sistema completo por el año 2001.

COBE® remedia los altos costos de la recolección de sangre

Los centros de donación de sangre siempre necesitaron obtener componentes sanguíneos de alta calidad. Históricamente, estos centros recolectan esta sangre de donantes. Pero, antes que esa sangre pueda ser usada para ciertos propósitos médicos, ésta debe ser separada en sus componentes: plaquetas, plasma y glóbulos rojos. El problema es que por ejemplo las plaquetas constituyen una muy pequeña fracción, y debían ser recolectadas de distintos centros para constituir una única dosis. En adición a ser costoso e ineficiente, la mezcla de componentes de distintos donantes aumentan la probabilidad de tener reacciones adversas en los pacientes.

Pero esto fue solucionado con el COBE(una división de los servicios médicos de la compañía sueca GAMBRO GROUP) BCT(Blood Component Collection) TRIMA. Este sistema filtra los componentes de un solo donante en diferentes bolsas recolectoras. Este proceso debe hacerse en tiempo real debido a que los componentes que no se necesiten son devueltos inmediatamente al donante, sólo se extraerá lo que requiera el médico.

Para el donante la experiencia no es muy diferente a la donación tradicional. Sin embargo para el centro este método es mucho más eficiente, ya que a través del método tradicional la sangre se depositaba en bolsas y al ser un proceso manual, siempre puede haber algún desperdicio de sangre por caídas de muestras de las bolsas.

Como es una misión critica, la seguridad es el factor primordial del sistema. Para lograr esta seguridad uno de los métodos fue utilizar un modelo redundante de procesadores 486(modelos especiales para reducir los riesgos de fallas). Por otro lado también se debía tener un sistema de control y monitoreo que fueran libres de fallas.

QNX fue elegido por su reconocido nivel de seguridad por todos los organismos médicos internacionales, e incluso otros SOs fueron rechazados en la elección por no tener el nivel de antigüedad en el mercado como el nuestro. Otra de las razones por la que se eligió QNX, fue la de ser el único RTOS que posibilita tener un GUI en tiempo real y seguro.

El diseño de los procesos se hizo con C++ como lenguaje, y un modelo en espiral como metodología de desarrollo, los cuales fueron divididos en comunicaciones, drivers de bajo nivel, y dominios de control, seguridad y GUI. Cada dominio fue diseñado independientemente, gracias a la filosofía IPC. El diseño y desarrollo fueron realizados bajo NT usando Phindows. Para el desarrollo de la interface gráfica fue usado Photon. El display muestra como instalar los tubos las centrífugas, etc., la secuencia de conección/desconección, y varias alarmas y alertas para indicar problemas potenciales con la calidad del producto. El display es de 640x480 y el desafío era poner hasta 400 o 500K de información en sólo un segundo.

Otras de las claves de la elección de QNX fue la garantía de protección de memoria, ya que programar procesos que garanticen esa protección por parte de los programadores hubiera sido un muy difícil desafío y una pérdida de tiempo para el proyecto. El proceso de desarrollo de software llevó 20 meses, terminando en Julio del 97.

No sólo QNX ayudó a que el producto se hiciera mucho más rápido, sino que como consecuencia de la acertada elección el desarrollo del TRIMA costó aproximadamente entre medio y un cuarto de millón de dólares menos.

Embebidos

Si uno está en Suiza y tiene que hacer una llamada es probable que se encuentre con el nuevo teléfono de TELIGENT, el Inform@fon. Lejos de los teléfonos convencionales, este teléfono basado en la tecnología de QNX abrió un nuevo horizonte en el mundo de las comunicaciones.

Diseñados para estar en aeropuertos, estaciones de trenes, shoppings, instituciones financieras, etc., este aparato transforma al teléfono de pago convencional en un teléfono multimedia.

Realiza un amplio rango de funciones de comunicación, desde comunicación de voz hasta almacenamiento de información y sirve como puerta de salida a fuentes de información externas y a proveedores de servicios.

Con el Inform@fon los usuarios pueden escribir, editar, transmitir, y recibir Email y fax. Sirve además de gateway a los servicios de VideoTex y Minitel y provee acceso a la red de teléfonos públicos. Opera además como un teléfono convencional. También puede usarse como pager.

Otra funcionalidad que provee el teléfono es el acceso a la Wold Wide Web, de hecho, los usuarios pueden navegar y ver documentos HTML en la pantalla de LCD. Posee además información en pantalla como guía de teléfono, una enciclopedia y un mapa interactivo e inteligente.

Trae incorporado un lector de tarjetas magnéticas pudiendo el usuario realizar transacciones bancarias seguras. Además de realizar las transacciones de manera segura, actúa como un cajero de la red ‘Sweden’s Electronic Purse’. La misma puede ser cargada por los clientes con efectivo y luego usarlo en los transportes públicos, teléfonos pagos, etc.

Trae incorporada una pequeña impresora que permite imprimir tickets que se reciben por las operaciones bancarias. Otra función, gracias a la posibilidad de comprar a través de la red, es imprimir tickets de teatros o de eventos deportivos.

Dada la necesidad de realizar las operaciones en tiempo real, la escalabilidad, la tolerancia a fallas y la interfaz GUI a color, Teligent utilizó QNX. Gracias a la escalabilidad de QNX, Teligent tiene la posibilidad de adaptar los aparatos según las necesidades del mercado. Los componentes de software y de hardware son modulares por lo tanto las terminales son completamente adaptables, nuevas funciones pueden ser incorporadas en cualquier momento. Si se requieren nuevas funcionalidades el software necesario es bajado de a través del modem sin necesidad de trasladarse hasta el lugar.

El aparato trae el tubo convencional del teléfono, un teclado QWERTY, un mouse, un lector y escritor de tarjetas magnéticas, un monitor 10.5’’ en una pantalla LCD color, un modem 33.6, e interfaces externas para fax e impresora. El sistema funciona sin ningún disco y actualmente está basado en un procesador 486. Todas las funciones son soportadas hoy en día por una memoria flash de 3Mb.

El teléfono ya está funcionando, hay 25 unidades operativas y se prevé un aumento de la demanda en cuestión de meses. Se están considerando adaptaciones a las próximas versiones: Incrementar la velocidad de transmisión con acceso a redes ISDN, migrar el sistema a procesadores Pentium, incluir impresoras externas y soportar la comunicación segura de Internet a través de l protocolo HTTP-S.

Realtime Networking

QNX sobre Microondas: A.L. Digital’s Satellite Based "Digital Jukebox" for MC Europe

¿Cuando fue la última vez que sintonizó una estación de radio que pase música ininterrumpidamente, sin ninguna conversación ni comerciales?. ¿O que sintonice todo con sonido de calidad digital? ¿O que le permita elegir el tipo de música que usted desea escuchar?

Esto es exactamente el tipo de servicio que es ofrecido por Music Choice Europe ( MC Europe), una industria reciente que ofrece a los subscriptores 60 canales de continua música con calidad de CD, todo desde la opera hasta el rock pesado.

Hoy en día la estación de radio MC Europe es la estación más demandada de todo el mundo. Todos los 60 canales deben pasar música las 24 horas del día, los 365 días del año, sin ninguna falla. El equipo de diseñadores y programadores detrás de este proyecto eligieron QNX para poder implementar tan compleja tarea.

MC Europe abrió sus puertas en 1993 como una compañía hermana de una americana llamada Digital Cable Radio (DCR). DCR ha entregado música por la red de cable americana desde 1987 y ha operado una base analógica de cable en Long Island, Nueva York.

El mercado europeo y americano difiere enormemente en cuestión de gustos musicales, aún en música clásica. Los compositores, orquestas y grabaciones que son populares en América del Norte, posiblemente no tengan comparación a aquellos que disfrutan de prestigio y popularidad en Europa.

La solución a este problema de gran complejidad fue implementada gracias a las redes de QNX. Dado que este proyecto requería de un gran ancho de banda se ha aprovechado las ventajas de las redes de QNX para correr varias de estas redes de manera simultánea.

"Nosotros elegimos QNX como nuestro sistema operativo principal por varias razones", comenta el presidente de MC Europe. "Primero porque es realmente un sistema multitarea, como Unix, en donde sabemos que se adapta muy fácilmente si existiera la necesidad de realizarlo. Segundo, está diseñado para aplicaciones de tiempo real lo que nos hace sentir confiados ya que nos brinda la seguridad que nosotros necesitamos. Y tercero, está excelentemente construido para redes, lo cual provee un balance automático a través de múltiples conexiones de redes. Simplemente se invoca y se está en camino".

Gracias a QNX, A.L. Digital no tiene que preocuparse o tener en cuenta ninguna precaución especial para asegurar que la música toque ininterrumpidamente porque los programas que pasan la música se ejecutan a una prioridad un poco mayor que cualquier otro proceso, y siempre en tiempo real, aún cuando otras aplicaciones, tal como una red de copia de archivos, esté trabajando de fondo (background), el sistema nunca pierde un bit.

Finalmente la señal emerge desde un set-top box conectado al sistema de estéreo del subscriptor. Este set-top viene equipado con un control remoto que no solamente permita al que escucha recibir los canales seleccionados, sino que también posibilita y muestra el título de la canción actual, el nombre del artista y el número y nombre del catálogo del CD. El control remoto también puede mostrar mensajes de texto que anuncian los nuevos y recientes eventos para los canales.

QNX ha superado las expectativas como un sólido sistema operativo de tiempo real, capaz de desarrollarse bajo condiciones críticas completas de estrés. Como resultado MC Europe multicanal hoy es un hecho y atrae cada día mayor cantidad de audiencia y subscriptores.

Competencia para QNX

Extracto de un artículo de CMP Media, 12 de Octubre de 1998

" El mercado más nuevo de NT - Microsoft empuja el NT Server hacia los sistemas embebidos - Stuart J. Johnson.

Aunque Microsoft pasa mucha parte de su tiempo tratando de convencer a los usuarios de cambiar su escritorio a Windows NT, la compañía también está luchando por obtener respeto en otro creciente mercado - el mundo de los sistemas embebidos y los controladores dedicados.

Microsoft que se encuentra muy lejos de ser un jugador dominante en la arena, está tratando de redefinir la porción de mercado de la misma forma que lo hizo con el campo de la PC: poniendo énfasis en la poderosa combinación de hardware de marca y software standard. En una palabra Wintel.(...)

Venture Data Corp dice que Windows NT obtuvo tal vez el 4% o 5% del mercado total de embebidos y sistemas de tiempo real en 1997. "Creo que NT está ganando mercado, aunque no a un ritmo realmente rápido", dice Pedro Zayas, un analista de la firma. Además, agrega, que la vasta mayoría de ese mercado es dominada por tres competidores: QNX, de QNX Software Systems Ltd. ; VxWorks, de Wind River Systems Inc. ; y pSOS de Integrated Systems Inc. Los analistas no quisieron identificar las porciones de mercado de los vendedores líderes, pero aún con pequeños segmentos se pueden ganar muchos dólares, haciendo que Microsoft se tome el tiempo de insistir; Venture Data dice que el mercado de los sistemas de tiempo real fue de alrededor de $380 millones en 1997.

Algunos usuarios y analistas dicen que sistemas como QNX, VxWorks y pSOS tienen una ventaja intrínseca: han sido construidos para proveer control de tiempo real. (...) Windows NT no fue diseñado para esto. Pero otras firmas independientes, tales como VenturCom, RadiSys e Imagination Systems han desarrollado extensiones que le dan a NT capacidades de tiempo real.

Usuarios de estas combinaciones dicen que la performance es buena. Y en lugar de tener un controlador dedicado que ofrece sólo control de tiempo real, los usuarios pueden correr otro software en la misma máquina.

Por ejemplo, Great Lakes Industries Inc. En Jackson, Michigan, está utilizando NT con la extensión para tiempo real RTX, de VenturCom, para correr cuatro máquinas de herramientas, cada una con un controlador PC.

La performance es tan buena como la de QNX y eso es decir mucho", dice Rick Stafford, ingeniero de fabricación en Great Lakes. Y la compatibilidad de NT con aplicaciones standard permite que el operador de la máquina busque planos de partes de la máquina en la misma computadora que la está controlando. Y, tomando ventaja de las capacidades de comunicación que tiene NT, las máquinas herramientas están linkeadas directamente a los sistemas de la empresa de planeamiento de recursos de la firma, una promesa que no es posible lograr con QNX".

Aplicaciones en Argentina

Invisa se dedica a desarrollos de aplicaciones OLTP, control de procesos, comunicaciones, como así también herramientas de desarrollo, principalmente sobre el Sistema Operativo QNX, y también sobre UNIX, Windows, Windows NT, DOS, y OS/2.

Invisa tiene profesionales con un promedio de 6 a 8 años de experiencia en desarrollo, integración de soluciones y soporte técnico en las distintas plataformas. Algunos de estos especialistas han publicado productos en la Guía de Tercer Partistas de QNX y los han presentado en la Conferencia Anual organizada por QSSL..

Invisa ha desarrollado productos para el área OLTP(On Line Transaction Processing) ya sea para comercios, bancos o compañías de tarjetas de crédito, entre los que se encuentran g-pay y TRANSAKTOR.

Esta empresa posee soluciones de tiempo real, control de procesos, automatización, interface hombre máquina, adquisición de datos, sincronización, sistemas embebidos, integración con bases de datos, transacciones on-line, comunicaciones, correo electrónico, sistemas telefónicos interactivos con respuesta por vos, acceso remoto, monitoreo, supervisión, visualización dinámica de datos y presentación de información a través de Internet.

Costos de QNX

QNX se puede comprar directamente a QSSL o a través de distribuidores. QSSL prefiere no dar precios específicos ya que estos varían según los módulos del SO que se incluyen.

Usted puede configurar el SO cuando usted quiere y usted sólo paga por los módulos que usted necesita.

Estos precios son principalmente pertinentes a los sistemas de desarrollo. Los precios pueden variar en parte realmente. Los descuentos están disponibles a diseñadores, y hay también descuentos por cantidad. Para embebidos y aplicaciones de OEM el precio por módulo está disponible. Esto le permite sólo pagar por los módulos del sistema que usted necesita. Por volumen, el precio se disminuye bastante.

Introducción

Las aplicaciones de tiempo real dependen del sistema operativo para manipular eventos múltiples dentro de restricciones fijas de tiempo.

El sistema operativo QNX es ideal para las aplicaciones de tiempo real. Proporciona multitarea, planificación por prioridades con desalojo, y rápido cambio de contexto.

QNX también es notablemente flexible. Desarrolladores pueden personalizar el sistema operativo fácilmente para satisfacer las necesidades de su aplicación. Desde la configuración del kernel en unos módulos pequeños, a un sistema de red amplia para servir cientos de usuarios.

QNX logra su único grado de eficacia, modularidad, y simplicidad a través de dos principios fundamentales:

 

• La arquitectura del Microkernel
• La comunicación entre procesos basada en mensajes.

La arquitectura del Microkernel de QNX

QNX consiste en un kernel pequeño a cargo de un grupo de procesos cooperativos.

Un verdadero kernel

El Microkernel de QNX es muy pequeño y se dedica a sólo dos funciones esenciales:

 

• Intercambio de mensajes: el Microkernel se ocupa de la asignación de ruta de todos los mensajes entre todos los procesos a lo largo de todo el sistema.
• Planificación: el scheduler es una parte del Microkernel y se invoca siempre que un proceso cambie el estado como el resultado de un mensaje o una interrupción.

   

A diferencia de los procesos, el propio Microkernel nunca se planifica para la ejecución o sea no participa en el scheduling. En él se entra sólo como el resultado directo de llamadas del kernel, ya sea de un proceso o de una interrupción del hardware.

Los procesos del sistema

Todos los servicios de QNX, excepto aquellos proporcionados por el Microkernel, se manejan como procesos comunes. Una configuración de QNX típica tiene los procesos de sistema siguientes:

• Administrador de procesos (Proc)
• Administrador del sistema de archivos (Fsys)
• Administrador de dispositivos (Dev)
• Administrador de red (Net)

Drivers de dispositivos

Los drivers de dispositivos son procesos que protegen al sistema operativo de tratar con todos los detalles requeridos para soportar hardware específico.

Agregar un nuevo driver a QNX no afecta al sistema operativo. El único cambio que usted necesita hacer a su ambiente de QNX es iniciar el nuevo driver.

QNX como un sistema operativo de intercambio de mensajes (IPC)

QNX fue el primer sistema operativo comercial de su tipo para hacer uso del intercambio de mensajes como significados verdaderos de IPC. QNX debe mucho de su poder, simplicidad, y elegancia a la integración completa de éste método a lo largo de todo el sistema.

En QNX, un mensaje es un paquete de bytes que pasa de un proceso a otro. QNX no le presta ningún significado al contenido de un mensaje - los datos en un mensaje tienen significado para el remitente del mensaje y para su receptor, pero para nadie más.

IPC también proporciona medios para sincronizar la ejecución de varios procesos. Sabiendo los estados y prioridades de cada proceso, el Microkernel puede realizar un scheduling sobre todos los procesos tan eficazmente como sea posible para hacer el mayor la disponibilidad de recursos de CPU.

QNX como una red

Cualquier proceso en cualquier máquina en la red puede hacer uso de cualquier recurso directamente en cualquier otra máquina. De la perspectiva de la aplicación, no hay ninguna diferencia entre un recurso local o remoto - ningún medio especial necesita ser construido en las aplicaciones para hacer uso de recursos remotos. ¡De hecho, un programa necesitaría un código especial para poder decir si un recurso, como un archivo o el dispositivo, estaba presente en la computadora local o estaba en algún otro nodo en la red!

Los usuarios pueden acceder a los archivos en cualquier parte en la red, aprovechar cualquier dispositivo periférico, y ejecutar aplicaciones en cualquier máquina en la red (siempre que ellos tengan la autoridad apropiada). Los Procesos pueden comunicarse de la misma manera a lo largo de la red entera.

SMP (Symmetric Multi-Processing)

SMP (Symmetric Multi-Processing) esta normalmente asociado con sistemas operativos como UNIX o NT. Estos sistemas con grandes kernels monolíticos tienden a ser bastante complejos, el resultado de muchos años de desarrollo. Puesto estos grandes kernels contienen la mayor parte de los servicios del sistema operativo, los cambios para soportar SMP son extensos, generalmente introduciendo muchas modificaciones en el código.

QNX por otro lado, contiene un microkernel muy pequeño rodeado por procesos que actúan como administradores de recursos, por ejemplo: sistemas de archivos, I/O, red. Modificando solamente el microkernel solamente, todos los demás servicios del sistema operativo ganaran inmediatamente una ventaja de SMP sin necesidad de cambios en el código. Si estos procesos son multihilo, cada uno de sus hilos será distribuido en los procesadores disponibles. Incluso en un servidor monohilo puede verse beneficiado por SMP, debido a que su hilo será ejecutado con mayor frecuencia.

Siguiendo la línea del microkernel de QNX, la versión SMP solo añade unos kilobytes mas de código. La versión actual permite bootear en un sistema que conforme la especificación Intel para multiprocesadores con hasta 8 procesadores pentium.

9. El Microkernel

Introducción

El Microkernel de QNX es responsable de lo siguiente:

 

• IPC - el Microkernel supervisa el ruteo de mensajes; también maneja otras dos formas de IPC: proxies y señales.
• La comunicación de la red a bajo nivel - el Microkernel entrega todos los mensajes destinados a los procesos en otros nodos.
• Scheduling de procesos - el scheduler del Microkernel decide qué proceso se ejecutará luego.
• Manejo de interrupciones del primer nivel - todas las interrupciones de hardware y las fallas se rutean primero a través del Microkernel, luego se pasa al driver o al administrador del sistema.

La comunicación entre procesos

El QNX Microkernel apoya tres tipos esenciales de IPC: mensajes, proxies y señales

 

• Mensajes - la forma fundamental de IPC en QNX. Ellos proporcionan la comunicación síncrona entre procesos cooperativos dónde el proceso que envía el mensaje requiere acuse de recibo y potencialmente una contestación al mensaje.
• Proxies - una forma especial de mensaje. Están especialmente preparados para notificación de eventos dónde el proceso que lo envía no necesita actuar recíprocamente con el destinatario.
• Señales - una forma tradicional de IPC. Se utilizan para apoyar la comunicación entre procesos de forma asíncrona.

   

Proceso de sincronización

El intercambio de mensajes no solo permite a los procesos pasarse datos entre ellos, sino que también proporciona un medio de sincronizar la ejecución de varios procesos que cooperan mutuamente.

IPC por la red

Una aplicación de QNX puede hablar con un proceso en otra computadora en la red como si estuviera hablando con otro proceso en la misma máquina. De la perspectiva de la aplicación, no hay ninguna diferencia entre un recurso local y remoto.

Este grado notable de transparencia es posible por los circuitos virtuales (VC), qué son los caminos que el Administrador de la Red proporciona para transmitir mensajes, proxies, y señales por la red.

Scheduling de procesos

El scheduler del Microkernel toma las decisiones de planificación cuando:

 

• Un proceso se desbloquea.
• El Quantum para el proceso corriente expira.
• El proceso corriente se desaloja.

   

Prioridades de procesos

En QNX, a cada proceso se le asigna una prioridad. El scheduler selecciona el próximo proceso para correr mirando la prioridad asignada a cada proceso que está en la cola de LISTOS (un proceso en la cola de LISTOS es uno capaz de usar el CPU). El proceso con la prioridad más alta se selecciona para ejecutarse.

La cola de listos para seis procesos (A-F) qué están LISTOS. Todos los otros procesos (G-Z) están BLOQUEADOS. El proceso A está corriendo actualmente. Los procesos A, B, y C están en la prioridad más alta.

Las prioridades asignadas al rango de procesos son de 0 (el más bajo) a 31 (el más alto). Se hereda la prioridad predefinida del padre a un proceso hijo.

Métodos de Scheduling

Para satisfacer las necesidades de varias aplicaciones, QNX proporciona tres métodos de planificación:

• FIFO.
• Round-robin.
• Adaptativa.

   

Cada proceso en el sistema puede correr usando cualquiera de estos métodos.

Recuerde que estos métodos de scheduling sólo se aplican cuando dos o más procesos que comparten la misma prioridad están LISTOS (es decir los procesos están compitiendo directamente entre sí). Si un proceso de prioridad superior se pone en LISTO, desaloja todos los procesos de baja-prioridad inmediatamente.

Planificación FIFO

En FIFO, un proceso seleccionado para correr continúa ejecutándose hasta que:

 

• Voluntariamente abandona el control (por ejemplo hace cualquier llamada al kernel).
• Es desalojado por un proceso de prioridad superior.

   

Dos procesos que corren a la misma prioridad pueden usar FIFO para asegurar la exclusión mutua a un recurso compartido. Ningún proceso será desalojado por el otro mientras se está ejecutando.

Planificación Round-robin

En Round-robin un proceso seleccionado para correr continúa ejecutando hasta que:

 

• Voluntariamente abandona el control.
• Es desalojado por un proceso de prioridad superior.
• Consume su quantum.

   

Un quantum es la unidad de tiempo asignada a cada proceso. Una vez que consume su quantum, un proceso se desaloja y el próximo proceso LISTO al mismo nivel de prioridad se le da el control. Un quantum es de 50 milliseconds.

Planificación adaptativa

En la planificación adaptativa, un proceso se comporta como sigue:

• Si el proceso consume su quantum (es decir no bloquea), su prioridad está reducida por 1. Esto se conoce como el decaimiento de prioridad. Notar que un el proceso "descendente" no continuará disminuyendo, aun cuando consume otro quantum sin bloquear; dejará caer la prioridad sólo un nivel por debajo de su prioridad original.
• Si el proceso bloquea, revierte inmediatamente a su prioridad original.

   

Usted puede usar la planificación adaptativa en ambientes dónde los procesos son del tipo background en su mayoría y están compartiendo la computadora con los usuarios interactivos.

La planificación adaptativa es el método de planificación predefinido para programas creados por la SHELL.

Latencia de interrupciones

La latencia de la interrupción es el tiempo de la recepción de una interrupción del hardware hasta que se ejecuta la primera instrucción de un manipulador de interrupción de software. QNX deja las interrupciones habilitadas casi todo el tiempo, para que la latencia de interrupción sea insignificante. Pero ciertas secciones críticas de código requieren que se desactive temporalmente las mismas. El máximo tiempo de desactivación de las interrupciones define la latencia de interrupción del peor caso, en QNX es muy pequeño.

La latencia de interrupción del peor caso será el tiempo más largo en que QNX desactiva las interrupciones de CPU.

La tabla siguiente muestra la latencia de interrupción típica cronometrada (Til) para un rango de procesadores:

Latencia del scheduling

Es el tiempo entre la terminación del manipulador de interrupción y la ejecución de la primera instrucción de un proceso del driver. Esto significa el tiempo que toma cambiar el contexto del proceso actualmente ejecutando y restaurar el contexto del proceso del driver requerido. Aunque es más grande que la latencia de la interrupción, este tiempo también es pequeño en un sistema de QNX.

 10. El Administrador del Procesos

Responsabilidades del Administrador de procesos

El Administrador de Procesos trabaja estrechamente con el Microkernel para proporcionar los servicios del sistema operativo esenciales. Aunque comparte el mismo espacio de dirección con el Microkernel, el Administrador de Procesos corre como un verdadero proceso, por lo que también el Microkernel realiza scheluding sobre él.

El Administrador del Procesos es responsable de crear nuevos procesos en el sistema y manejar los recursos más fundamentales asociados con un proceso. Estos servicios son todos proporcionados vía mensajes. Por ejemplo, si un proceso corriente quiere crear un nuevo proceso, envía un mensaje que contiene los detalles del nuevo proceso a ser creado. Note que desde que los mensajes pueden enviarse a través de la red, usted puede crear un proceso fácilmente en otro nodo enviando el mensaje de creación de proceso al Administrador del Procesos en ese nodo.

Primitivas de creación de procesos

QNX apoya tres primitivas:

• Fork ()
• Exec ()
• Spawn ()

   

Fork () y exec () se definen por POSIX, mientras que la implementación de spawn() es única a QNX.

 

• Fork () crea un nuevo proceso que es una imagen exacta del proceso que la invocó. El nuevo proceso comparte el mismo código que el proceso que invocó la primitiva y hereda una copia de los datos del mismo.
• Exec () reemplaza la imagen del proceso que la invoca con una nueva imagen del mismo.
• Spawn() crea un nuevo proceso como un hijo del proceso invocante. Puede evitar la necesidad de fork () y exec (), produciendo un medio más rápido y más eficaz para crear nuevos procesos. La primitiva spawn() puede crear procesos en cualquier nodo en la red.

   

El ciclo de vida de un proceso

Un proceso pasa por cuatro fases:

• Creación
• Carga
• Ejecución
• Terminación

   

Creación

Crear un proceso consiste en asignar un PID para el nuevo proceso y preparar la información que define el ambiente del nuevo proceso. La mayoría de esta información se hereda del padre del nuevo proceso.

Carga

La carga de imágenes del proceso se hace por un hilo del LOADER. El código del LOADER reside en el Administrador del Procesos, pero el hilo corre bajo el PID del nuevo proceso. Esto permite al Administrador de Procesos atender otras demandas mientras los programas se cargan.

Ejecución

Una vez que el código del programa se ha cargado, el proceso está listo para la ejecución; empieza a competir con otros procesos por los recursos de CPU. Nótese que todos los procesos se ejecutan concurrentemente con sus padres. Además, la muerte de un proceso padre no causa la muerte de sus procesos hijos automáticamente.

Terminación

Un proceso se termina de dos maneras:

 

• Por una señal cuya acción cause la terminación deliberada del proceso.
• El proceso invoca exit (), explícitamente o por defecto la acción al volver al principal ()

   

La terminación involucra dos fases:

 

1. Un hilo de terminación en el Administrador del Procesos se ejecuta. Este código está en el Administrador del Procesos pero el hilo corre con el PID del proceso a terminar. Este hilo cierra todos los descriptores de archivo abiertos y libera lo siguiente:

• Cualquier circuito virtual sostenido por el proceso.
• Toda la memoria asignada al proceso.
• Cualquier nombre simbólico.
• Cualquier número de dispositivo (Administrador de I/O).
• Cualquier manipulador de interrupciones.
• Cualquier proxie.
• Cualquier cronómetro.

Después de que el hilo de terminación se corre, la notificación de terminación del proceso se envía al proceso padre (esta fase corre dentro del Administrador del Procesos).

Si un proceso se termina por la entrega de una señal de terminación y la utilidad del dumper está corriendo, se genera un vuelco de memoria.

Estados del proceso

Un proceso siempre está en uno de los estados siguientes:

 

• LISTO: el proceso es capaz de usar el CPU (es decir no está esperando por cualquier evento a ocurrir).
• BLOQUEADO: el proceso está en uno de los siguientes estados bloqueados:

   

  • Enviar-bloqueado.
  • Recibir-bloqueado
  • Contestación-bloqueado
  • Señal-bloqueado
  • Semáforo-bloqueado

   

• RETENIDO: el proceso ha recibido una señal de SIGSTOP. Hasta que se remueva del estado RETENIDO, al proceso no se le permite usar el CPU; la única manera de quitarlo del estado RETENIDO es enviarle una señal de SIGCONT o terminar el proceso vía una señal.
• ESPERA –bloqueado: el proceso ha emitido una llamada WAIT () o WAITPID () para esperar por el estado de uno o más de sus procesos hijos.
• MUERTO - el proceso ha terminado pero es incapaz de enviar su estado de salida a su padre porque el padre no ha emitido un WAIT () o WAITPID (). UN proceso MUERTO tiene un estado, pero la memoria que ocupó una vez se ha liberado. Un proceso MUERTO también es conocido como un proceso zombi.

   

Nombres simbólicos para procesos

En QNX, la solución es permitir a los procesos darse un nombre simbólico. En el contexto de un solo nodo, los procesos pueden registrar este nombre con el Administrador del Procesos en el nodo dónde ellos se están ejecutando. Otros procesos pueden pedirle el PID asociado a ese nombre entonces al Administrador del Procesos.

Timers

Administración de timers

En QNX, la administración de tiempo se basa en un cronómetro del sistema mantenido por el sistema operativo. El cronómetro contiene Coordenadas de Tiempo Universal (UTC) relativo a 0 horas, 0 minutos, 0 segundos, el 1 de enero de 1970.

Facilidades avanzadas

Un proceso también puede crear timers, puede armarlos con un intervalo de tiempo, y puede quitar los mismos. Los medios de cronometrado avanzados son basados en POSIX Std 1003.1b.

La precisión del cronómetro

Usted puede setear la precisión de los cronómetros usando la utilidad del ticksize o la función qnx_ticksize (). Usted puede ajustar la precisión de 500 microseconds a 50 milliseconds.

Manipuladores de interrupciones

Ellos reaccionan a las interrupciones del hardware y manejan el traslado de bajo nivel de datos entre la computadora y los dispositivos externos.

Son empaquetados físicamente como la parte de un proceso QNX normal (por ejemplo un Driver), pero ellos siempre corren asincrónicamente con el proceso asociados con ellos.

Un manipulador de interrupciones:

 

• Se entra con una Far Call, no directamente por la propia interrupción (esto puede escribirse en C, en lugar de assembler).
• Se ejecuta incluido en el contexto del proceso, por lo que tiene acceso a todas las variables globales del proceso.
• Corre con las interrupciones habilitadas, pero solo se desaloja si una interrupción de prioridad superior ocurre.
• No debería hablar directamente con la interrupción de hardware 8259 (el sistema operativo se encarga de esto).
• Debe ser tan corto como sea posible.

   

Varios procesos se pueden atar a la misma interrupción (si es soportado por el hardware). Cuando una interrupción física ocurre, se le dará el mando a cada manipulador de interrupción de a uno a la vez.

El espacio de nombres de I/O

Los recursos de I/O no están construidos en el Microkernel de QNX. Los servicios de I/O son proporcionados por procesos que pueden ejecutarse dinámicamente mientras el sistema está corriendo. El filesystem de QNX es optativo, el espacio del pathname no se construye en el filesystem como en la mayoría de los sistemas monolíticos.

Los prefijos y regiones de autoridad

Con QNX, el espacio del pathname es dividido en regiones de autoridad. Cualquier proceso que desea proporcionar los servicios de I/O orientado a archivos registrará un prefijo con el Administrador del Procesos que define la porción del espacio de nombres que él desea administrar (es decir su región de autoridad). Estos prefijos constituyen un árbol de prefijos que se mantiene en la memoria en cada computadora que corre QNX.

Administrador prefijos I/O

Cuando un proceso abre un archivo, el pathname del archivo es aplicado contra el árbol de prefijos para direccionar el OPEN () al Administrador recursos I/O apropiado. Por ejemplo, el Administrador de Dispositivos de carácter (Dev) normalmente registra el prefijo /dev. Si un proceso llama OPEN () con /dev/xxx, una concurrencia con el prefijo de /dev ocurrirá y OPEN () se redireccionará a Dev (su dueño).

Network root

QNX apoya el concepto de súper o network root que te permiten aplicar un pathname contra el árbol de prefijos de un nodo específico. Esto también permite fácilmente que acceder a los archivos y dispositivos que no están en el espacio de nombres de su nodo. Por ejemplo, en una red de QNX típica los caminos siguientes se trazarían:

 

• /dev/ser1 el puerto de serie local
• / /10/dev/ser1 el puerto de serie en nodo 10
• / /0/dev/ser1 el puerto de serie local
• / /20/usr/dtdodge/test se archiva en nodo 20

Note que / /0 siempre se refieren al nodo local.

Alias

Una segunda forma de prefijo, es conocida como un alias, es una simple substitución de un string para un prefijo. Un alias es de la forma:

Prefijo =string reemplazante

Por ejemplo, asuma usted está corriendo en una máquina que no tiene un filesystem local (no hay ningún proceso que para administrar" /"). Sin embargo hay un filesystem, en otro nodo (diga 10) que usted desea acceder como" /". Usted logra esto usando el prefijo del seudónimo siguiente:

/ = / /10 /

Creando nombres del dispositivo especiales

Usted también puede usar alias para crear nombres de dispositivos especiales. Por ejemplo, si un spooler de impresión estuviera corriendo en el nodo 20, usted puede poner un pathname de la copiadora local como un alias a este de la siguiente forma:

/dev/printer=//20/dev/spool. Cualquier demanda para abrir /dev/printer se dirigirá por la red al spooler real.

Espacio de nombres del descriptor de archivos

Una vez que un recurso de I/O se ha abierto, un espacio de nombres diferente entra en acción. OPEN () retorna un entero llamado descriptor del archivo (FD) qué se usa para dirigir todas las demandas de I/O a ese Administrador.

El espacio de nombres de descriptor de archivos es completamente local a cada proceso. El Administrador usa una combinación de un PID y FD para identificar la estructura de control asociada con él la llamada OPEN () anterior. Esta estructura se llama Open Control Block (OCB) y se contiene dentro del Administrador de I/O.

El diagrama siguiente muestra a un Administrador de I/O que toma algún PID, FD mapeándolos y trazándolos a OCB.

El PID y FD trazan a un OCB de un Administrador de I/O.

Open Control Blocks (OCB)

El OCB contiene la información activa sobre el recurso abierto. Por ejemplo, el filesystem guarda el corriente punto de seek dentro del archivo dentro de esta estructura. Cada open () crea un nuevo OCB. Por consiguiente, si un proceso abre el mismo archivo dos veces, cualquier llamada al lseek () usando un FD no afectarán el punto seek del otro FD.

Lo mismo es válido para la apertura del mismo archivo por diferentes procesos.

El diagrama siguiente muestra dos procesos, en cuál un proceso abre el mismo archivo dos veces, y el otro lo abre una vez. No hay ningún FD compartido.

Muchos FD en uno o más procesos pueden referirse al mismo OCB. Esto es cumplido por dos medios:

 

• Un proceso puede usar dup (), dup2 (), o fcntl () funciones para crear un descriptor de archivo duplicado que se refiere al mismo OCB.
• Cuando un nuevo proceso se crea vía fork (), spawn (), o exec (), todos los descriptores de archivo abiertos se heredan por defecto por el nuevo proceso; estos descriptores heredados se refieren al mismo OCB como el descriptor de archivo correspondiente en el proceso padre.

   

Cuando varios FD se refieren al mismo OCB, entonces cualquier cambio en el estado del OCB se ve inmediatamente por todos los procesos que tienen el descriptor de archivo unido al mismo OCB.

El diagrama siguiente muestra dos procesos en cuál uno abre un archivo dos veces, entonces hace un dup () para conseguir un tercero. El proceso crea a un hijo que hereda todos los archivos abiertos.

Usted puede prevenir que un descriptor de archivo pueda heredarse cuando usted llama a un SPAWN () o exec () llamando a la función fcntl ()y seteando la bandera de FD_CLOEXEC.

Introducción

El Administrador de Filesystem (Fsys) proporciona un método estándar de guardar y acceder a los datos en los subsistemas de discos. Fsys es responsable de ocuparse de todas las demandas para abrir, cerrar, leer, y escribir los archivos.

¿Qué es un archivo?

En QNX, un archivo es un objeto que puede escribirse, leerse, o ambos. QNX implementa seis tipos de archivos; de los cuales cinco de éstos son manejados por Fsys:

• Archivos regulares - consisten en secuencia de bytes que pueden ser accedidas de forma aleatoria y no tiene ninguna otra estructura predefinida.
• Los directorios - contienen la información necesaria para localizar los archivos regulares; también contienen información del estado y los atributos para cada archivo regular.
• Simbolic links (accesos directos) - contienen un pathname a un archivo o directorio que será accedido en lugar del archivo simbolic link. Estos archivos se usan a menudo para proporcionar múltiples caminos a un solo archivo.
• Pipes y FIFOs - sirven como canales I/O entre procesos que cooperan.
• Archivos de bloques especiales - refiere a los dispositivos, como las unidades de disco, cintas, y particiones de la unidad de disco. Estos archivos normalmente se acceden de una manera que esconde las características del hardware del dispositivo de las aplicaciones.

   

El sexto tipo de archivo, el archivo especial de carácter, se maneja por el Administrador de Dispositivos.

Fecha y time stamps

Fsys mantiene cuatro tiempos diferentes por cada archivo:

 

• la fecha de último acceso (lea)
• La fecha de la última escritura.
• la fecha de última modificación
• la fecha de creación (único a QNX)

   

Acceso a archivos

El acceso a los archivos regulares y los directorios son controlados por bits de modo guardados en el inode del archivo.. Hay tres calificadores de acceso:

 

• Usuario únicamente.
• Grupo únicamente.
• Otros.

   

Un proceso también puede correr con el user ID o el group ID de un archivo en lugar de aquellos de su proceso padre. El mecanismo que permite esto está llamando el setuid ( setea el user ID en tiempo de ejecución)) y setgid (el Group ID).

Archivos regulares y directorios

Archivos regulares

QNX ve un archivo regular como una secuencia accesible de bytes en forma aleatoria que no tienen una estructura interior predefinida. Los programas de aplicación son responsables para entender la estructura y contenido de cualquier archivo regular.

Los directorios

Un directorio es un archivo que contiene entradas de directorio. Cada entrada de directorio asocia un nombre de archivo con un archivo. Un nombre de archivo es el nombre simbólico que permite identificar y acceder a un archivo. Un archivo puede identificarse por más de un nombre de archivo.

Los funcionamientos del directorio

El Administrador del Filesystem impone algunas restricciones en las operaciones que usted puede realizar en un directorio. Específicamente, usted no puede abrir un directorio para escribir en él.

Operaciones sobre directorios

Para leer las entradas del directorio, usted usa un juego de funciones POSIX definidas que proporcionan el acceso a las entradas del directorio en una forma independiente al SO. Estas funciones incluyen:

• opendir ()
• readdir ()
• rewinddir ()
• closedir ()

   

Extends

En QNX, se guardan archivos regulares y archivos del directorio como una sucesión de extends. Un extend es un conjunto de bloques consecutivos en el disco.

Donde se guardan los extends

Archivos que tienen sólo un extend almacenan la información del mismo en la entrada del directorio. Pero si más de un extend se necesita para almacenar el archivo, la información de éste se guarda en uno o más bloques extends anidados. Cada bloque extend puede sostener información de localización para 60 extends.

Un archivo que consiste en múltiples regiones consecutivas en un disco – llamadas extends en qnx.

Extendiendo archivos

Cuando el Administrador de Filesystem necesita extender un archivo cuyo último extend está completo, intenta primero extender el último extend, aun cuando sea sólo por un bloque. Pero si éste no puede extenderse, una nuevo extend es agregado.

Para asignar nuevos extends, el Administrador del Filesystem usa la política " First Fit". Una tabla especial en el Administrador del Filesystem contiene una entrada para cada bloque representado en el archivo "/. bitmap" (este archivo se describe en la sección. Cada entrada define el extend libre inmediato más grande en el área definida por su bloque correspondiente. El Administrador del Filesystem escoge la primera entrada en esta tabla, lo bastante grande para satisfacer la demanda para un nuevo extend.

Links e Inodes

En QNX, los archivos de datos pueden ser los referenciados por más de un nombre. A cada nombre de archivo se lo llama link. (Hay dos tipos de links: links duros a los que nosotros simplemente nos referimos como "links" y los simbolic links).

Para soportar links para cada archivo, el nombre de archivo está separado de la información que describe al archivo. La información que no pertenece al nombre de archivo se guarda en una tabla de almacenamiento llamada inode ( "nodo de información").

Si un archivo tiene sólo un link (es decir un nombre de archivo), la información del inode se guarda en la entrada del directorio para el archivo. Si el archivo tiene más de un link, el inode se guarda como un registro en un archivo especial nombrado / .inodes, y la entrada del directorio del archivo que apunta al registro del inode.

Usted sólo puede crear un link a un archivo si el archivo y el link están en el mismo filesystem.

El mismo archivo es el referenciado por dos links llamados "more" y "less."

Hay otras dos situaciones en que un archivo puede tener una entrada en el archivo de /.inodes:

 

• Si el filename de un archivo es más largo que 16 caracteres, la información del inode se guarda en el archivo / .inodes, haciendo lugar para un filename de 48 caracteres en la entrada del directorio.
• Si un archivo tiene más de un link y todos los links menos uno han sido quitados, el archivo continúa teniendo un archivo separado / .inodes en la entrada del mismo.

   

Removiendo links

Cuando se crea un archivo se le da una cuenta de links igual a uno. A medida que se agregan links al archivo, esta cuenta de links se incrementa; cuando se remueven links la cuenta se decrementa. El espacio que ocupa en disco el archivo no puede ser liberado a menos que la cuenta de links sea igual a cero y que todos los programas que usan el archivo lo hayan cerrado. Esto permite que un archivo abierto pueda seguir siendo utilizado aun cuando se hayan removido todos los links.

Simbolic Links

Es un archivo especial que tiene un pathname como dato. Cuando se nombra en una demanda de I/O - por Open(), por ejemplo - la parte del pathname del link se reemplaza por los "datos" del simbolic link y el path se reevalúa. Los simbolic links son medios flexibles de indirección del pathname y se usan a menudo para proporcionar caminos múltiples a un solo archivo. Al contrario que los links duros, estos pueden cruzar filesystems y también pueden crear links a directorios.

/ /1/usr/eric/src/test.c--> / /1/usr/src/game.c

El PID y FD trazan a un OCB de un Administrador de I/O.

Recuerde que quitando un link simbólico actúa sobre el link, no sobre el target.

Ya que los simbolics links pueden apuntar a directorios, las configuraciones incorrectas pueden producir problemas como links de directorios circulares. Para recuperarse de las referencias circulares, el sistema impone un límite en el número de saltos

Pipes

Un pipe es un archivo anónimo que sirve como un canal de I/O entre dos o más procesos que cooperan - un proceso escribe en el pipe y el otro lee del mismo. El Administrador del Filesystem cuida el buffering de los datos.

Normalmente se usan pipes cuando dos procesos quieren correr en paralelo, con datos que se mueven de un proceso al otro en una sola dirección. (Si la comunicación es bidireccional deben usarse mensajes)

Performance del Administrador de Filesystem

El Administrador de Filesystem tiene varias características que contribuyen a que el acceso al disco sea de alto rendimiento:

 

• Método de búsqueda del ascensor para el seek
• Cache de buffer
• multi-threading
• Prioridad que maneja el usuario
• Archivos temporales
• Ramdisks

   

Método de búsqueda del ascensor.

Minimiza el tiempo global de seek para leer o escribir los datos de o al disco. Las demandas de I/O son ordenadas de tal forma que todas puedan ser atendidas con una sola barrida del cabezal del disco, de la dirección más baja del disco a la más alta.

Cache de buffer

Es un buffer inteligente entre el Administrador del Filesystem y el driver del disco. El caché de buffer intenta guardar bloques del filesystem para minimizar el número de veces que el Administrador del Filesystem tiene que acceder el disco. Por defecto, el tamaño del caché es determinado por la memoria total del sistema, pero usted puede especificar un tamaño diferente vía una opción a Fsys.

Las operaciones de lectura son síncronas. Las escrituras, por otro lado, son normalmente asíncronas. Cuando los datos entran en el caché, el Administrador del Filesystem avisa al cliente que los datos fueron escritos. Los datos se escriben lo más pronto posible al disco, típicamente en menos de cinco segundos.

Las aplicaciones pueden modificar la conducta de las escrituras en un comportamiento de archivo-por-archivo. Por ejemplo, una aplicación de base de datos puede causar que todas las escrituras para un archivo dado deban ser realizadas sincrónicamente. Esto aseguraría un nivel alto de integridad del archivo ante problemas potenciales de hardware o suministro de energía que podrían dejar una base de datos en un estado incoherente.

Multi-threading

El Administrador del Filesystem es un proceso multi-hilo. Es decir, puede manejar varios pedidos de I/O simultáneamente. Esto le permite al Administrador del Filesystem totalmente aprovecharse del potencial del paralelismo de la siguiente forma:

• Acceso varios dispositivos en paralelo.
• Satisfacer demandas de I/O desde el caché de buffer mientras otras peticiones que acceden al disco son atendidas.

   

La prioridad del usuario

El Administrador del Filesystem puede tener su prioridad manejada por la prioridad de los procesos que le envían mensajes. Cuando el Administrador del Filesystem recibe un mensaje, se le asigna la prioridad del proceso que realizó la petición.

Ramdisks

El Administrador de Filesystem tiene una capacidad de ramdisk integrada que permite que 8M de memoria puedan ser usados como un disco simulado

El Administrador del Filesystem puede desviase del caché porque el ramdisk esta incorporado a él y no necesita un driver.

La robustez de Filesystem

El filesystem de QNX logra un throughput alto sin sacrificar la fiabilidad. Esto se cumple de varias maneras.

Mientras la mayoría de los datos se almacena en el caché y son escritos después de un retraso corto, los datos críticos del filesystem se escriben inmediatamente. Las actualizaciones de los directorios, inodes, los bloques extends, y los bitmap se envían forzosamente al disco para asegurar que la estructura del filesystem en el disco nunca sea incoherente.

La recuperación de Filesystem

Para que usted pueda recuperar tantos archivos como sea posible, únicas "firmas" han sido escritas en el disco para ayudar en la identificación automática y recuperación de los pedazos del filesystem críticos. Los archivos inodes (/ .inodes), así como cada directorio y extends blocks, contienen únicos modelos de datos que la utilidad del chkfsys puede usar para volver a montar un filesystem dañados.

Los discos y subsistemas del disco

QNX considera cada disco físico en una computadora como un bloque el archivo especial. Un disco se ve por el filesystem de QNX como un conjunto secuencial de bloques, de 512 bytes en el tamaño cada uno, sin tener en cuenta el tamaño y capacidad del disco. Se numeran los bloques, empezando con el primer bloque en el disco (bloque 1).

Una computadora QNX corriente puede tener uno o más subsistemas del disco. Cada subsistema del disco consiste en controlador y uno o más discos. Usted inicia el driver del dispositivo para cada subsistema del disco que será manejado por el Administrador de Filesystem.

Particiones de SO

QNX cumple con el estándar de la industria que permite tener distintos sistemas operativos sobre el mismo disco. De acuerdo con esto se puede definir una tabla de partición de hasta cuatro particiones primarias sobre el disco. La tabla se almacena en el primer bloque del disco. QNX trata a cada partición en un disco como un bloque el archivo especial.

Cada partición debe tener un tipo reconocido por el SO. Aquí se muestran los tipos de particiones que se usan generalmente:

Los componentes importantes de una partición de QNX

Los componentes importantes se encuentran juntos al principio de cada partición QNX:

• el bloque loader
• el bloque root
• el bitmap
• el directorio del root

Estas estructuras se crean cuando usted inicializa el filesystem con la utilidad del dinit.

La estructura de un filesystem de QNX dentro de una partición del disco.

El bloque loader

Éste es el primer bloque físico de una partición del disco. Este bloque contiene el código que se carga y se ejecuta por el BIOS de la computadora para cargar un sistema operativo de la partición. Si un disco no se ha dividido (por ejemplo como en un floppy), este bloque es el primer bloque físico en el disco.

El bloque root

El bloque de la raíz se estructura como un directorio normal. Contiene la información del inode para estos cuatro archivos especiales:

• el directorio de la raíz del filesystem (/)
• / .inodes
• / .boot
• / .altboot

Normalmente, el loader de QNX carga la imagen de OS guardada en el archivo /.boot. Pero si el archivo de /.altboot no está vacío, se dará la opción para cargar la imagen guardada en el archivo de /.altboot.

Bitmap

Para asignar el espacio en un disco, QNX usa un bitmap guardado en el archivo /.bitmap. Este archivo contiene un mapa de todos los bloques en el disco, indicando qué bloques están usados. Cada bloque se representa por un bit. Si el valor del bit es 1, su bloque correspondiente en el disco está usándose.

Borrado de archivos

Cuando un directorio o el archivo se borra, la estructura de datos que lo representa es marcada como borrada, pero no se remueve la misma. Esto evita borrar continuamente y volver a escribir el medio.

Eventualmente, el medio se quedará sin espacio libre y el Administrador del filesystem realizará el reclamo de espacio (o "Garbage Collector"). Durante este proceso, Efsys. * recupera el espacio ocupado por los archivos anulados y directorios.

NFS FILESYSTEM

Originalmente desarrollado por el Sun Microsystems, el Sistema de Archivo de Red (NFS) es una aplicación de TCP/IP que se ha llevado a cabo subsecuentemente en DOS y sistemas de Unix.

QNX soporta este tipo de fileSystems. Usted necesita sólo usar NFS si está accediendo a filesystems que no son QNX NFS, o si usted quiere permitir a los clientes de NFS acceder al espacio de nombres de QNX.

NFS le permite unir filesystems remotos - o porciones de ellos - hacia su espacio de nombres local. Los directorios en los sistemas remotos aparecen como parte de su filesystem local y todas las utilidades que usted usa para listar y manejar los archivos (por ejemplo el ls, el cp, el mv) operan exactamente igual en los archivos remotos como lo hacen en sus archivos locales.

Introducción

El QNX Administrador de Dispositivos (Dev) es la interfase entre los procesos y los dispositivos terminales. Estos dispositivos terminales se localizan en el namespace de I/O con nombres que comienzan con /dev. por ejemplo, un dispositivo de la consola en QNX tendría un nombre como:

Los servicios de dispositivos

Un dispositivo terminal se presenta a un proceso de QNX como un flujo bidireccional de bytes que pueden leerse o pueden escribirse por el proceso.

El Administrador del Dispositivos regula el flujo de datos entre una aplicación y el dispositivo. Algo del procesamiento de los datos es realizado por Dev según los parámetros en una estructura de control terminal (llamada el termios) que existe para cada dispositivo.

Los parámetros del termios controlan la funcionalidad de bajo nivel como:

 

• la disciplina de línea de mando (incluso la proporción del baudio, paridad, los bits de stop y los bits de datos)
• Eco de caracteres
• Edición de la línea de entrada
• Reconocimiento y solución sobre pausas y cortes
• Control de flujo por hardware y software
• la traducción de caracteres salida

   

Driver de Dispositivos

La ilustración siguiente muestra un subsistema típico de un dispositivo en QNX.

El proceso de Administrador de Dispositivos (Dev) maneja el flujo de datos a y de los procesos de aplicación QNX. La interfase del hardware se maneja por procesos de drivers individuales. El dato fluye entre Dev y sus drivers a través de un conjunto de colas de memoria compartida para cada dispositivo terminal.

Ya que se usan colas de memoria compartida, es necesario que Dev y todos sus drivers residan en el mismo CPU físico. La ventaja es que se incrementa la Performance.

Se usan tres colas para cada dispositivo. Cada cola se implementa usando FIFO. Una estructura de control también es asociada con cada cola.

Los datos recibidos se ponen en la cola de entrada por el driver y sólo se consume por Dev cuando la aplicación procesa los datos de la demanda.

Los tamaños de todas estas colas son configurables por el administrador del sistema; la única restricción es que el total de la suma de las tres colas no puede exceder 64K. Los valores por defecto normalmente son más que adecuados para manejar la mayoría de las configuraciones del hardware.

Control de Dispositivos

Los drivers de dispositivos agregan los datos recibidos simplemente a la cola de la entrada o consumen y transmiten los datos de la cola de salida. Dev decide cuando (y si) la transmisión de salida será suspendida, etc.

Para asegurar una buena respuesta interactiva a eventos de entrada, Dev debe correr a una prioridad bastante alta.

Los drivers son procesos como cualquier otro proceso en QNX; ellos pueden ejecutarse a prioridades diferentes según la naturaleza del hardware a los que ellos están sirviendo

La consola de QNX

Las consolas del sistema son manejadas por el driver procesos "Dev.con". El adaptador de la placa de video y la pantalla, más el teclado del sistema, están conjuntamente llamado la consola.

QNX permite correr las sesiones múltiples concurrentemente en las consolas por medio de las consolas virtuales. El proceso del driver de la consola "Dev.con" típicamente maneja más de un conjunto de colas de I/O a Dev que son disponibles para los procesos del usuario como un conjunto de dispositivos terminales con los nombres como /dev/con1, /dev/con2, etc.

Por supuesto que hay sólo una pantalla física y solo un teclado, entonces solo una de estas consolas virtuales realmente se despliega en cualquier único instante de tiempo. El teclado se asigna a la consola virtual que esta visible en ese instante.

El driver de las consolas QNX corre como un proceso normal QNX. Los caracteres de entrada por teclado son trazados por el manipulador de interrupciones del teclado y los coloca directamente en la cola de la entrada. Los datos de salida se consumen y despliegan por Dev.con.

¿QNX Soporta un archivo Swap?

No. hay algunos planes para llevar a cabo esto en algún momento en el futuro. Hay

otros rasgos que se agregarán a QNX antes de que un archivo Swap sea agregado. La razón principal de esto es que requerir tiempos de respuesta y performance en tiempo real tiene conflictos a la hora de implementar un archivo swap.

El requerimiento para swaping en la mayoría de las aplicaciones de QNX es bastante bajo.

La eficacia del OS y el copilador de Watcom proporcionan relativamente pequeños procesos en término de requisitos de memoria. Cuando esto se combina con

la habilidad de compartir el código entre las invocaciones de proceso múltiples y

las bibliotecas compartidas, las demandas de memoria en QNX son bastante moderadas.

¿ QNX soporta memoria virtual?

Sí. No confunda esto con un archivo swap. La memoria virtual sólo se refiere realmente al mapeo de memoria física a través de un MMU. QNX opera en modo protegido en los procesadores de Intel, y hace el uso de LDT y GDT para proveer un mapeo de memoria en la memoria física. El uso de memoria virtual permite que QNX provea tanto memoria compartida en una base por proceso como protección de memoria entre procesos aún entre los procesos que constituyen el mismo SO.

Protección de memoria

Mientras muchos de los kernels de tiempo real proveen soporte para la protección de memoria en tiempo de desarrollo, pocos los hacen para el momento de ejecución, con la performance como principal razón. Pero desde que la protección de memoria se esta haciendo común en muchos procesadores embebidos, la performance decae muy poco.
La ventaja clave ganada por añadir memoria protegida, especialmente para sistemas de misión critica, es la robustez.
Con protección de memoria, si uno de los procesos ejecutándose en un ambiente multitarea intenta acceder a memoria que no ha sido explícitamente declarada o alocada, el hardware MMU puede notificar al sistema operativo, que puede luego abortar el hilo.

Memory Management Units (MMUs)

Un típico MMU opera dividiendo la memoria física en un paginas de 4K. El hardware del procesador luego hace uso de un conjunto de tablas almacenadas en la memoria del sistema que definen el mapeo de direcciones virtuales a las direcciones emitida por el CPU para acceder memoria física.
Mientras el hilo se ejecuta, direcciona la memoria como si lo hiciera en un sistema sin MMU, excepto que las tablas de paginas administradas por el sistema operativo controla como estas direcciones se mapean en la memoria física.

Para espacios de direcciones muy grandes con muchos procesos e hilos, el numero de entradas en la tabla de paginas puede ser significativo – mas de lo que puede almacenar el procesador. Para mantener la performance el procesador cachea frecuentemente las porciones usadas de las paginas de tablas en un TLB (translation look-aside buffer).

Los servicios de fallos en el caché TLB es parte de la sobrecarga impuesta por el uso de MMU. QNX usa varios arreglos inteligentes para minimizar esta sobrecarga.

Asociados a estas tablas de paginas hay bits que definen los atributos de cada pagina de memoria. Las paginas puede ser marcadas como solo lectura, lectura-escritura, etc...

Cuando QNX ejecuta un context switch, manipula la MMU para usar potencialmente un conjunto nuevo de paginas para el nuevo hilo. Si se esta cambiando entre hilos de un mismo proceso, no se requieren manipulaciones del MMU.

Tipo de protección de memoria

El costo de performance por protección de memoria es insignificante en la mayoría de los sistemas. Quizás más importante es el incremento de costo de memoria para soportar las tablas de paginas MMU para implementar mayor nivel de protección.

El administrador de procesos ofrece la posibilidad de ninguna protección o protección total.

Sin protección

En este modelo, todos los procesos (kernel y usuarios) corren en el mismo espacio de memoria compartida.

Protección total VM

En este modelo, cada proceso tiene su espacio privado de memoria virtual, que comienza en 0 y se expande a 2 o 3.5 Gigabytes (dependiendo del CPU). Esto es logrado a través del MMU del procesador.

15. El Administrador de la Red (Qnet)

Introducción

Comunicándose directamente con el Microkernel, el Administrador de la Red mejora el intercambio de mensajes (IPC) propagando los mensajes eficazmente a las máquinas remotas. Además, el Administrador de la Red ofrece tres rasgos avanzados:

 

• Incrementa el throughput vía el equilibrio de carga
• la tolerancia a fallos vía conectividad redundante
• Puentes entre las redes de QNX

   

En pocas palabras, Qnet es una red basada en el envío de mensajes que le brinda acceso transparente a cualquier recurso del sistema. Qnet le permite construir aplicaciones eficientes y tolerantes a fallos que pueden ser escaladas fácilmente.

Qnet esta integrada en el corazón de las primitivas de manejo de procesos y envió de mensajes de QNX, haciendo que la intercomunicación de procesos local y a través de una red sea lo mismo. Usando Qnet, una red de nodos individuales se convierte en una supercomputadora virtual, donde cada nodo tiene acceso a todos los recursos del sistema.

El diseño único de Qnet le hace posible crear redes altamente escalables y tolerantes a fallo con soporte para balancear la carga.

Con Qnet, cualquier dispositivo en el sistema puede acceder cualquier recurso en forma transparente. Qnet extiende el mecanismo de envió de mensajes que forma el núcleo de la plataforma QNX. Utilizando Qnet, los mensajes son enviados de forma transparente de un nodo a otro, lo que hace posible acceder y utilizar recursos como por ejemplo sistemas de archivos, I/O, recursos de hardware, administradores de procesos y mas.

Un módulo independiente

El Administrador de la Red no tiene que ser construido en la imagen del sistema operativo. Puede ejecutarse y puede detenerse cuando quiera para proporcionar o quitar las capacidades de mensajería de red.

Cuando el Administrador de la Red empieza, se registra con el Administrador del Procesos y el Microkernel. Esto activa el código existente dentro de los dos que hace de interfase con el Administrador de la Red. Esto significa que mensajería de la red y la creación de procesos remotos no es sólo una capa agregada al sistema operativo.

Esta integración profunda al nivel más bajo le da transparencia a la red lo califica como un sistema operativo totalmente distribuido. Ya que las todas las aplicaciones acceden a los servicios vía mensajes, y que el Administrador de la Red permite a los mensajes fluir transparentemente en la red, los nodos de QNX trabajan juntos como una sola supercomputadora lógica.

Drivers de la red

Como el Administrador de Filesystem y el Administrador del Dispositivos, el Administrador de la Red no contiene ningún código hardware-específico. Esta funcionalidad es proporcionada por los Drivers de tarjeta de red. El Administrador de la Red puede soportar múltiples drivers de placas de red a la misma vez. Cada Driver soporta una sola tarjeta de red.

Las colas de memoria compartida proporcionan la interfase entre el Administrador de la Red y los drivers. El driver determina el protocolo apropiado para los medios de comunicación de la red.

El Driver es responsable de la packetización, la secuencia y retransmisión si la transmisión de datos garantizada y fiable es pedida por un nodo físico remoto. Este plan le permite a QNX soportar fácilmente nuevo hardware de red y protocolos, escribiendo o modificando solamente los Drivers red.

Equilibrio de carga y tolerancia a fallos

El throughput de la red es determinado por una combinación de la velocidad de la computadora y la velocidad de la red. Si su computadora puede proporcionar los datos más rápido que la red puede aceptarlo, entonces la red limitará su throughput.

El Administrador de la Red equilibrará automáticamente la carga escogiendo un driver de red apropiado.

Cuando nodos son conectados de a dos o más en la red, existe más de un camino a usar para la comunicación. Si una tarjeta en una red falla el Administrador de la Red re-dirigirá todos los datos automáticamente a través de otra red. Esto pasa automáticamente sin ningún tipo de intervención por parte del software de la aplicación, y resultados en la tolerancia a fallas de la red es totalmente transparente. Si se colocan cables para redes diferentes, usando rutas separadas, usted también se protegerá contra un corte de cable accidental.

Usted también puede construir sistemas en tándem, en que dos máquinas son conectadas por una red rápida para el funcionamiento normal y por una red más barata y más lenta que queda en espera. Si la primera red falla, la comunicación continuará, aunque se reduciría naturalmente el throughput.

Qnet permite alto rendimiento y tolerancia a fallos a través del soporte para múltiples enlaces entre nodos. Dependiendo en las necesidades de su sistema, usted puede elegir entre tres clases de servicios:

Balanceo de carga – El modulo administrador de red de Qnet decide que enlaces usar para el envío de paquetes dependiendo en la carga actual. Un paquete es encolado en el enlace que puede enviarlo mas rápidamente a través de la red. El resultado de esto es un mayor ancho de banda entre nodos y una menor degradación del servicio cuando el enlace falla. Cuando un enlace falla, paquetes periódicos de mantenimiento son enviados a ese enlace para detectar la recuperación.

Secuencial – el primer enlace es usado hasta que falla, luego el segundo link, y así sucesivamente. El usuario puede indicar el orden preferente de los enlaces.

Redundante – los paquetes son enviados a todos los links disponibles simultáneamente.

Arquitectura escalable

Con Qnet, es fácil crear redes altamente escalables. La misma aplicación puede correr en un procesador único o ser distribuida a través de múltiples procesadores. No se requiere recodificar. Y, ya que las aplicaciones no requieren código especifico para manejar la red, nuevas redes (Ethernet, serial, backplane) pueden ser introducidas, nuevamente, sin recodificar.

Puentes entre LANs

El Administrador de la Red permite a cualquier nodo actuar como un puente entre dos redes IEEE 802.

Ya que QNX usa el mismo formato de paquete y protocolo en todas las redes IEEE 802, usted puede crear los puentes entre Ethernet, Token Ring, y redes de FDDI. No pueden puentearse las redes de Arcnet.

Se soportan protocolos ARP, IP, ICMP, UDP, y protocolos de TCP también.

Redes TCP/IP

QNX implementa su protocolo propietario de red que está optimizado para proporcionar una rápida, e idéntica interfase entre computadoras basadas en QNX. Pero para comunicarse con sistemas que no utilizan QNX, utiliza el conjunto estándar de protocolos de red conocidos como TCP/IP.

Administrador de TCP/IP

El Administrador se deriva de la pila Berkeley BSD 4.3 que es la pila TCP/IP más común en Internet y se ha usado como la base para muchos sistemas.

NFS

El FileSystem de Red (NFS) es una aplicación TCP/IP que se ha implementado en sistemas DOS y Unix en su mayoría. NFS permite unir filesystems remotos (o porciones de ellos) en un espacio de nombres local. Los archivos en los sistemas remotos aparecen como la parte del filesystem local de QNX.

SMB

QNX también soporta los Bloques de Mensajes de Servidor (SMB) protocolo para compartir archivos, que son usados por varios servidores diferentes como Windows NT Windows 95, Windows para Workgroups, LAN Manager, y Samba. El filesystem de SMBfsys permite a un cliente de QNX acceder a los archivos remotos que residen en tales servidores transparentemente.

Internet
Navegador Voyager

Con el navegador Voyager, la interfase y el motor son dos programas separadas. Esto crea una arquitectura cliente/servidor donde la interfase (cliente) dialoga con el motor del navegador (servidor) a través de la interfaz llamada PtWebClient.

Con una arquitectura como esta es muy fácil la personalización. Para modificar la interfaz del navegador, simplemente se modifica el PtWebClient.

Si usted necesita un navegador WEB para su sistema embebido y no desea desperdiciar tiempo y dinero en construir uno, el navegador Voyager es para usted. Esta completamente equipado y es altamente modular, puedo correr en modo completo o compacto. Puede escalarlo desde un navegador básico con un manejo de memoria optimizado hasta incluir soporte para múltiples idiomas, un discador, etc...

Servidor WEB

Controle remotamente su fotocopiadora, reciba estadísticas de virtualmente cualquier dispositivo desde su navegador con el servidor WEB. Suficientemente pequeño para una impresora láser, y robusto para un robot de fabrica, este servidor le permite incluso a sistemas embebidos sin disco generar paginas dinámicas en tiempo real.

FLEETTM - la Gestión de redes Alto rendimiento para QNX

FLEET es una característica única de QNX que crea un solo conjunto homogéneo de recursos que se pueden acceder en forma transparente, desde cualquier lugar de la red. FLEET es un protocolo de red ultra liviano y de alta velocidad. Hace que todas las computadoras conectadas se vean como una sola supercomputadora lógica. Porque FLEET se construye sobre la arquitectura del pasaje de mensaje del QNX OS, ofrece lo último en flexibilidad. FLEET ofrece:

• Trabajo en red con total tolerancia a fallos
• Carga balanceada del trabajo
• Performance eficiente
• Arquitectura extensible
• Procesamiento distribuido transparente

Trabajo en red con total tolerancia a fallos

Si un cable o tarjeta de red en una red falla, FLEET automáticamente rutea los datos a través de otra red. Esto pasa en la red, sin involucrar software de aplicación, dándole automática tolerancia a falla de la red.

Carga balanceada del trabajo

El throughput de la red está normalmente limitado por la velocidad de su computadora y hardware de la red. Con FLEET, pueden transmitirse datos simultáneamente sobre múltiples redes, permitiéndole doblar, triplicar, o incluso cuadruplicar el ancho de banda de la red y throughput poniendo múltiples tarjetas de red en cada computadora y conectándolas con cables separados. Usted puede mezclar tipos diferentes de tarjetas de red incluso (ej. Ethernet, FDDI) en la misma máquina.

Performance eficiente

Drivers de red FLEET son construidos para hacer la mayoría del hardware de gestión de redes. Por ejemplo, al enviar bloques grandes de datos en una red de Ethernet de un proceso a otro, usted obtendrá:

Tipo de red No. de procesos del cliente Throughput

10 Mbit Ethernet 1 1.1 Mbytes/sec

100 Mbit Ethernet 1 7.5 Mbytes/sec

Arquitectura extensible

Gracias a FLEET, una red de QNX le da excelente flexibilidad. Los procesos de una red de computadoras son arquitectónicamente distintos para el OS, permitiéndole empezar y detener un nodo conectado en cualquier momento. Esto significa que usted puede agregar nodos a su red o puede quitarlos dinámicamente sin reconfigurar su sistema. Y, gracias al puenteo automático de red, usted puede agregar redes físicas diferentes también a su LAN.

Procesamiento distribuido transparente

Los procesos de red de FLEET están integrados en el corazón del pasaje de mensajes y primitives de administración de procesos, haciendo el ancho de red IPC y local uno y el mismo. Puesto que IPC es transparente, una red de PCs individual aparece como una sola. ¿El resultado? Usted nunca necesita modificar sus aplicaciones para comunicar a tavés de la red.

Introducción

Muchas sistemas embebidos requieren una interfaz de usuario para interactuar con las aplicaciones. Para simplificar las complejas interfaces de usuario, un sistemas gráficos de ventana es una elección natural. Sin embargo, los sistemas de ventanas en las PC de escritorio simplemente requieren demasiados recursos para ser practicas en un sistema embebido que tiene limitaciones de memoria y costo. A continuación se detalla la arquitectura única de Photon microGUI, un sistema de ventana escalable que corre con menos de 500K de memoria y sin embargo entrega toda la funcionalidad esperada de un sistema de ventanas e introduciendo muchas opciones de conectividad.

Photon microGUI ha sido diseñado para entregar un sistema grafico de ventanas a ambientes con restricciones de recursos. A través de su única arquitectura, también provee:

Opciones de escalabilidad – Photon puede ser escalado en un sistema grafico completo para escritorio. Photon puede ser integrado con sistemas de ventanas heterogéneos.

Tolerancia a fallos – si una parte del sistema de ventanas falla, ese componente puede ser reiniciado "en el vuelo" sin colgar el sistema entero.

Un microkernel grafico
Siguiendo la arquitectura del microkernel de QNX, y teniendo este una intercomunicación de proceso muy eficiente, el microkernel grafico se estructura como un proceso con un equipo de procesos adicionales cooperando con este, comunicándose vía IPC.

El microkernel de photon corre como un pequeño proceso (45K de código), implementando solo unas primitivas fundamentales que procesos externos usan para construir funcionalidades de mas alto nivel. Irónicamente, para el microkernel la palabra "ventana" no existe como así tampoco puede dibujar nada ni administrar mouse, teclado, etc.

En primero momento esto puede parecer similar a construir un sistema grafico alrededor del paradigma cliente/servidor ya utilizado en X Window. La arquitectura de Photon se diferencia restringiendo la funcionalidad implementada en el microkernel grafico ( o servidor ) y distribuyendo la mayor parte de la funcionalidad del GUI entre los procesos cooperadores.

Estos procesos, como por ejemplo el administrador de recursos del GUI y el administrador de ventanas pueden ser agregados dinámicamente al sistema corriendo sin tener que reiniciar.

(Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo")

Photon de adapta a cualquier ambiente:
Internet.
Electrónica.
Telefonía.
Instrumentación medica.
Automatización industrial.
PDAs .
Puntos de venta.
Y mas!

El espacio de evento de Photon

El "espacio de eventos" administrado por Photon puede ser visualizados como un espacio vacío con una región base al fondo. El usuario final puede ser imaginado como mirando a través de este espacio de eventos. Las aplicaciones colocan regiones en el espacio tridimensional entre la región base y el usuario final. Usan esas regiones para generar y aceptar varios tipos de eventos entre este espacio.

Los procesos que proveen servicios de driver colocan regiones adelante del espacio de eventos.

(Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo")

Se puede pensar que estos eventos viajen a través de este espacio como fotones.

La interacción entre eventos y regiones es la base de las entradas y salidas en Photon. Los eventos de mouse y teclado viajan desde el usuario hacia la región base. Los eventos de dibujo originados por regiones viajen hacia el usuario.

Drivers gráficos

Los drivers gráficos son implementados como procesos que están en el frente del espacio de eventos. Una región grafica es sensible a los eventos de dibujo provenientes del espacio de eventos. Cuando los eventos de dibujo intersectan la región, estos son recibidos por el proceso de driver grafico. De hecho, esta región puede ser imaginada como cubierta por fósforo, el cual es iluminado por el impacto de los fotones.

Múltiples drivers gráficos

Puesto que los drivers gráficos simplemente colocan una región en el espacio de eventos, y ya que esta región es un rectángulo que será interceptado por eventos de dibujo, naturalmente se puede utilizar drivers gráficos múltiples para múltiples controladoras graficas, todas con su región de dibujo presente es el mismo espacio de eventos.

Estas múltiples regiones puede ser puestas adyacentes una de la otra o solapadas de diversas maneras. Ya que photon hereda la transparencia de red de QNX, las aplicaciones o drivers pueden corren en cualquier nodo de la red, permitiendo drivers gráficos adicionales extender el espacio grafico de Photon al espacio físico de varios computadoras en red. Al tener este esquema, los eventos gráficos pueden ser replicados en múltiples pantallas.

Muchas aplicaciones interesantes se hacen posibles con esta capacidad. Por ejemplo, un operador de una fabrica con una computadora inalámbrica de mano puede caminar hacia una estación de trabajo y arrastrar una ventana de la planta de control en su computadora de mano y luego interactuar con el sistema de control.

Control remoto
Con photon, la conectividad esta incluida. Realmente no hay diferencia en que sus clientes estén en la misma ciudad o en el otro lado del mundo. Usted puede monitorear y brindarles soporte fácilmente. De hecho, usted puede ver e interactuar con cualquier aplicación Photon en cualquier momento y en cualquier lugar, usando Internet, TCP/IP o módems.

JumpGate Connectivity
Con JumpGate no necesita escribir una pregunta acerca de una aplicación y enviársela por mail a un colega. Con Photon, se puede enviar la interfaz de la aplicación entera y además, su colega puede interactuar con la aplicación y enviársela nuevamente.

Palabras clave: Sistema Operativo de tiempo real, Tiempo real, sistema operativo, sistemas embebidos, Microkernel, INVAP, SAC-C, Kernel, Multitarea, SCHEDULER, Round Robin, FIFO, QNX

Categoría: Sistemas operativos

Resumen: Aquí un aporte desde Argentina, para la categoría sistemas operativos, se trata de el SO QNX 4.25, que es perfecto para sistemas de tiempo real y para sistemas embebidos, es un trabajo de 88 página bastante completito

Trabajo enviado y realizado por:
Mauro Strione
mauro@strione.com
25 Años
Argentino - Soltero
Analista Universitario de sistemas
Estudiante de ingeniería en informática.

Compartir