LATAM Architect Newsletter

Prueba

Martin.Cabrera@microsoft.com — Mon, 27 Oct 2008 22:04:11 GMT

Probado en blog...

.NET 3.5 Enhancements Training Kit

Martin.Cabrera@microsoft.com — Wed, 09 Jul 2008 16:30:27 GMT

Este training kit posee presentaciones, hands-on labs y demos de las siguientes tecnologías:

ASP.NET MVC
ASP.NET Dynamic Data
ASP.NET AJAX History
ASP.NET Silverlight Controls
ADO.NET Data Services
ADO.NET Entity Framework

Súper recomendable para todos aquellos que quieran entrenar o entrenarse en dichas tecnologías.

Les dejo el link para que lo puedan bajar:

http://www.microsoft.com/downloads/details.aspx?familyid=355C80E9-FDE0-4812-98B5-8A03F5874E96&displaylang=en

Debugging avanzado en .Net

Martin.Cabrera@microsoft.com — Fri, 08 Jun 2007 22:48:00 GMT

Presentación

por Ezequiel Glinsky (Gerente de Grupo de Arquitectura, Microsoft Cono Sur)

Los términos de bug y debugging tienen ya larga data. Me incluyo entre los que creíamos que eran términos acuñados por Admiral Grace Hopper y su equipo en la década de 1940 para referirse a los insectos que se atoraban en los relays causando fallas difíciles de detectar, y para definir la técnica de solucionar esos problemas.

Para mi sorpresa, el término bug habría sido originalmente utilizado por Thomas Edison para describir fallas mecánicas en sus creaciones a fines del siglo XIX:

"It has been just so in all my inventions. The first step is an intuition-and comes with a burst, then difficulties arise. This thing gives out and then that -"Bugs"- as such little faults and difficulties are called--show themselves and months of anxious watching, study and labor are requisite before commercial success -or failure- is certainly reached"
Edison: A Biography
Matthew Josephson, John Wiley & Sons, 1992, page 198)

Es evidente que no somos los primeros (ni seremos los últimos, claro está) en batallar contra bugs -sean físicos o lógicos-.

Pasé por algunos debuggers, luché contra otros, y lloré junto a algunos otros. Sin ordenarlos por ningún criterio particular, recuerdo algunos momentos que fueron importantes para mí respecto a este tema. Cuando utilizábamos una improvisada búsqueda binaria para encontrar problemas al trabajar con Cobol sobre VAX/VMS, la sorpresa de encontrar buen soporte en las IDEs de Borland, el deleite con la facilidad de uso de algunas versiones de PowerBuilder, de Visual C++ y de Visual Basic, y mi dolor al ver que las cosas se complicaban utilizando TimeWarp, MPIch y el CD++ cuando trabajábamos en simulación de eventos discretos en entornos distribuidos.

El artículo de Rodolfo Finochetti cubre aspectos poco conocidos -y en muchos casos, muy necesarios- en la ardua tarea del debugging que pueden ayudarnos a la hora de solucionar problemas. Nos permite además actualizarnos con respecto a las herramientas y facilidades disponibles en la actualidad.

Los invito a disfrutarlo, y recuerden que en la tercera y última entrega, les presentaremos un desafío sobre algunos de los temas cubiertos en esta serie de tres artículos, con libros de Microsoft Press como premio para el ganador. ¡Todos los lectores estarán invitados a participar!

Debugging avanzado en .NET (Parte 1)

Por Rodolfo Finochietti (http://weblogs.shockbyte.com.ar/rodolfof)

Diagnosticar y corregir errores en las aplicaciones siempre ha sido difícil, sobre todo cuando estos errores no tienen una causa aparente o no se pueden reproducir fácilmente. Seguramente a muchos de ustedes esta situación les resulte familiar: luego de mucho meses de desarrollo y pruebas en distintos ambientes, nuestra aplicación (que ha sido diseñada teniendo en cuenta buenas prácticas de arquitectura y ha sido sometida muchas instancias de pruebas) es puesta en producción, al tiempo (inmediatamente o después de meses o años) empieza "colgarse", consume demasiada memoria (incluso hasta que termina abruptamente) o se vuelve lenta sin estar sometida a demasiada carga. Todo esto sin una explicación aparente y lo que es peor aun en forma aleatoria no pudiendo reproducir estos problemas en un entorno distinto al productivo. La primera reacción de la mayoría de nosotros es decir "¡no puede ser, en mi maquina funciona!", luego del shock inicial tratamos de diagnosticar el problema en forma "artesanal", la mayoría de las veces con poco éxito, y aplicando soluciones parciales que atacan el síntoma y no el problema. Aunque no lo crean he visto muchas instalaciones en donde la solución a casos como los que he descripto consistía en un operador monitoreando la aplicación para reiniciarla cuando detecta que esta "colgada".

En esta serie de artículos voy a explicar técnicas y herramientas poco difundidas para diagnosticar y resolver este tipo de problemas. Además, estas técnicas, sirven para ayudar a mejorar la calidad de las aplicaciones aun cuando estas no presenten problemas graves (por ejemplo la aplicación consume demasiada memoria pero termina en forma abrupta). Este primer artículo contiene una introducción a las diferentes técnicas de debugging, las ventajas y desventajas de cada una, las distintas herramientas a utilizar, como obtenerlas, como configurarlas y como utilizarlas.

Diagnosticando en distintos ambientes

El principal motivo para depurar una aplicación es encontrar la causa de un problema de performance, operación, configuración o una condición de error anormal que impida el normal funcionamiento del sistema. Esta definición aplica tanto al ambiente de desarrollo como al ambiente de producción, pero desde el punto de vista del debugging ambos ambientes tienen características y posibilidades muy distintas.

En el ambiente de desarrollo se tiene control total, la seguridad es menos estricta y se pueden instalar herramientas de diagnostico invasivas (básicamente un IDE con un debugger). En este ambiente se utiliza la técnica de debugging más común y antigua: Live Debugging, es decir ejecutar el código de la aplicación línea por línea verificando el valor de las variables y el contexto de ejecución hasta encontrar el error.

Producción es un ambiente mucho más controlado en el que no se pueden instalar herramientas de diagnostico invasivas y en el que normalmente el equipo de desarrollo ni siquiera tiene acceso, por lo que iniciar una sesión de Live Debugging local o remoto es muy difícil. Aun cuando dispongamos del nivel de acceso necesario para instalar herramientas de diagnostico o iniciar sesiones de Live Debugging esto podría interrumpir la normal ejecución de las partes de la aplicación que no presentan errores o de otras aplicaciones que se ejecutan los mismos equipos, situación para nada deseable en un entorno productivo.

Por otra parte la técnica de Live Debugging es útil para diagnosticar errores que se pueden reproducir siguiendo un patrón, pero la mayoría de los errores que pueden producir que una aplicación deje de operar totalmente no se pueden reproducir mediante un patrón y seguramente solo ocurren en el ambiente productivo únicamente. La dificultad para reproducir problemas en el entorno de desarrollo se debe generalmente a que el hardware, software y configuraciones son distintos a los utilizados en producción y a que la carga a la que está sometida la aplicación es también distinta, no pudiéndose reproducir fácilmente en desarrollo los mismos niveles de uso que se registran en producción.

El tiempo es también un factor importante. Cuando una condición de error se produce en desarrollo generalmente se dispone de más tiempo para diagnosticar su causa y corregir el problema. En cambio en producción el tiempo desde que se produce a la falla hasta que la aplicación vuelve a operar normalmente debe ser el menor posible. Esto es así fundamentalmente porque cada segundo que la aplicación esta fuera de línea (total o parcialmente) la organización pierde dinero. Por este motivo en producción es más importante aplicar soluciones que hagan que la aplicación vuelva a estar 100% operacional lo más rápido posible, aun cuando estas no sean del todo "elegantes", para luego con más tiempo poder encarar una "refactorizacíon" más profunda.

El diagnostico y análisis de errores en producción es, en esencia, la habilidad de diagnosticar un problema sin utilizar herramientas intrusivas (como un IDE) y sin interrumpir la normal operación de las partes de la aplicación que funcionan normalmente, u otras aplicaciones ejecutando en el mismo hardware. Estás técnicas también sirven para depurar en desarrollo cuando las herramientas no aportan información o bien es un problema de reproducción esporádica.

Fases del proceso de diagnostico

Al diagnosticar un problema en una aplicación hay dos fases:

Discovery Phase: El objetivo de esta fase es obtener información del estado de la aplicación y el servidor al momento de producirse el error y luego permitir que continúen su funcionamiento. Esta fase a menudo no es tenida en cuenta pero es tan importante como la siguiente.
Debugging Phase: En esta fase se utilizan dos técnicas.
o Live Debugging.
o Post-Mortem Debugging: Consiste en analizar la información recolectada en la fase anterior para encontrar la causa del problema. La ventaja de esta técnica es que se trabaja con información obtenida de un problema real en vez de tratar de encontrar los pasos necesarios para reproducir el problema.

En cada fase y para cada técnica se utilizan herramientas distintas.

Herramientas para la fase de Discovery

Incluidas dentro de Windows hay dos herramientas muy útiles para obtener información en la fase de Discovery:

Task Manager: Esta muy conocida herramienta permite obtener importantes métricas en tiempo real como la utilización de CPU, memoria física o memoria virtual.
Performance Monitor: Permite registrar los valores de los diferentes contadores de performance, en tiempo real o en un archivo para su posterior análisis.

También existen otras herramientas que permiten obtener valiosa información para el diagnostico de un problema:

Autodump+ (ADPlus): Esta herramienta está incluida dentro del paquete Debugging Tools for Windows, disponible para su descarga desde http://www.microsoft.com/whdc/devtools/debugging/default.mspx. Es un script (VBScript) que utiliza el Core Debugger para obtener vuelcos de memoria y logs que para el análisis post-mortem. Se puede utilizar para obtener información en forma inmediata o para monitorear una aplicación y tomar datos en el momento de su caída. Al ser un script su principal ventaja es su facilidad de instalación, pero tiene como desventaja que si queremos dejar monitoreando una aplicación es necesario que una sesión interactiva este iniciada en el servidor.
Debug Diagnostics: Originalmente pensada analizar problemas de memoria en Internet Information Server, esta herramienta sirve además para obtener y analizar datos y vuelcos de memoria en cualquier tipo de proceso en Windows. Lo interesante de esta herramienta es que se instala como un servicio lo que permite obtener datos sin que tener que dejar una sesión interactiva abierta en el servidor. También dispone de una consola grafica de administración y una serie de wizards que diagnostican automáticamente los problemas de memoria más comunes. Viene incluida dentro del paquete Internet Information Services Diagnostic Tools, disponible para su descarga desde http://www.microsoft.com/windowsserver2003/iis/diagnostictools/default.mspx.

Herramientas para la fase de Debugging

Las siguientes herramientas permiten hacer Live Debugging o analizar la información obtenida en la fase de Discovery (Post-Mortem Debugging):

WinDbg: Es un debugger de código nativo con interfaz grafica que viene incluido dentro del paquete Debugging Tools for Windows. Se puede utilizar para Live Debugging de procesos locales o remotos, permite analizar post-mortem vuelcos de memoria y además soporta extensiones para ampliar sus capacidades. WinDbg utiliza DBGENG.DLL que es una biblioteca que ofrece servicios de debugging y sobre la cual se basan casi todos las UI de debugging que se incluyen en el paquete Debugging Tools for Windows (como el Core Debugger, cdb.exe, que es un debugger de consola que también utiliza los servicios de DBGENG.DLL).
CorDbg: es un debugger de código manejado con interfaz de consola. Viene incluido en el SDK de .NET Framework (la versión 1.1 del SDK se puede descargar desde http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en%20 y la versión 2.0 del SDK desde http://www.microsoft.com/downloads/details.aspx?FamilyID=FE6F2099-B7B4-4F47-A244-C96D69C35DEC&displaylang=en). Es muy útil para debugging en ambientes productivos ya que ocupa muy poco tamaño, no requiere instalación y tiene un número pequeño de dependencias.
SOS.dll (Son of Strike): Es una extensión que permite depurar código manejado utilizando WinDbg. Incluye una gran cantidad de comandos muy útiles para visualizar información del stack manejado, objetos, threads, Garbage Collector, etc. Viene incluida dentro de .NET Framework (se encuentra en el directorio de instalación). Es importante destacar que existe una versión de SOS para cada versión de .NET Framework y para cada plataforma. De esta manera si estamos debuggeando una aplicación .NET 1.1 debemos usar la versión de SOS incluida dentro de .NET Framework 1.1. Lo mismo si, por ejemplo, estamos analizando un vuelco de memoria de una aplicación .NET 2.0 x64, debemos utilizar la versión SOS incluida en .NET Framework 2.0 x64.
SieExtPub.dll: Es otra extensión para WinDbg que se utiliza para visualizar información de threading de COM. Se encuentra dentro del paquete Debugging Tools (que también incluye una versión SOS para .NET Framework 1.0 y una versión de AutoDump+,) y se puede descargar desde http://www.microsoft.com/downloads/details.aspx?FamilyID=7c6ec49c-a8f7-4323-b583-6a7a6aeb5e66&DisplayLang=en.
Visual Studio .NET 2003/Visual Studio 2005 debuggers: Son debugger de código nativo y manejado que soportan el debugging al mismo tiempo de código escrito en diferentes lenguajes y scripts. Soportan debugging remoto pero para esto es necesario instalar las herramientas de remote debugging (incluidas en el paquete de instalación de Visual Studio) en la maquina remota que se desea depurar.

Utilizando las herramientas

Para demostrar el uso de algunas de las herramientas que he mencionado anteriormente utilizare como ejemplo un programa WinForm escrito en .NET Framework 2.0. Este programa tiene dos botones, el primero de ellos crea y destruye objetos de 20 MB, y el segundo botón llama al método GC.Collect para forzar que los objetos que no están siendo utilizados se eliminen de la memoria.

Pero este simple programa tiene un problema. Si lo ejecutamos y abrimos el Task Manager en la solapa Process, seleccionado las columnas Memory - Working Set y Memory - Private Working Set, podemos observar que siempre que presionamos el primer botón la cantidad de memoria utilizada aumenta, por más que los objetos se crean e inmediatamente se eliminan. La cantidad de memoria utilizada tampoco disminuye al forzar la recolección de basura mediante el segundo botón.

Si continuamos presionando el primer botón luego de un tiempo obtendremos una excepción del tipo System.OutOfMemoryException. Esta excepción se produce cuando un una alocación de memoria falla, en la mayoría de los casos por que ya no hay mas memoria disponible. Luego de producirse la excepción el programa termina abruptamente.

Este error es fácilmente reproducible, es claro que se produce al presionar repetidas veces el primer botón y además al ser una aplicación WinForm sin demasiadas dependencias es fácilmente diagnosticable utilizando Live Debugging . Pero supongamos que el problema no sea reproducible en un ambiente controlado, o no podemos instalar herramientas de debugging en el entorno productivo, o que simplemente no dispongamos del código fuente para poder hacer Live Debugging. En estos casos es donde debemos tratar de obtener la mayor cantidad de información en el momento que se produce el problema.

Una fuente importante de información son los contadores de performance. La herramienta Performance Monitor nos permite seleccionar contadores y visualizar sus valores en tiempo real o registrarlos en un archivo para poder analizarlos posteriormente.

En la próxima entrega de este artículo explicaré en detalle como diagnosticar problemas de memoria, por el momento mencionaré que los contadores que generalmente se utilizan para analizar este tipo de errores son los del grupo .NET CLR Memory, Process\Virtual Bytes y Process\Private Byte.

Otra fuente muy importante de información son los vuelcos de memoria (memory dumps). Como ya he mencionado, la mayoría de las veces es imposible depurar la aplicación en el momento en que el problema se produce. En este tipo de circunstancias los vuelcos de memoria nos permiten tener una "foto" exacta de lo que estaba pasando en el sistema al momento del error. Además por la naturaleza misma del entorno de ejecución de .NET Framework, el CLR, un vuelvo de memoria de un programa .NET tiene mucha más información que un vuelco de memoria de un proceso tradicional, lo que ayuda muchísimo en el diagnostico.

Para obtener vuelcos de memoria podemos utilizar AutoDump+. Esta herramienta tiene dos modos de utilización: hang y crash. El modo hang permite tomar un vuelco de memoria inmediatamente sin interrumpir la normal ejecución del proceso. Para hacerlo debemos ejecutar desde la consola: adplus.vbs -hang -pn <nombre del proceso> o adplus.vbs -hang -p <identificador del proceso>. En el modo crash AutoDump+ se queda monitoreando hasta que detecta una excepción que hace que el proceso termine en forma abrupta y en ese momento toma un vuelco de memoria. Para activar el modo crash debemos usar el comando: adplus.vbs -crash -pn <nombre del proceso> o adplus.vbs -crash -p <identificador del proceso>.

Junto con los vuelcos de memoria AutoDump+ genera una serie de archivos de texto con información de los registros de CPU, threading y contexto de ejecución al momento de generar el vuelco.

También podemos tomar vuelcos de memoria utilizando Debug Diagnostics. Para ello al ejecutar Debug Diagnostics se inicia un Wizard que nos permite realizar esta tarea. En este Wizard debemos seleccionar la opción Crash, A specific process, el proceso a monitorear y por último si queremos comenzar a monitorear inmediatamente o en otro momento.

Ejecutando el Wizard se creará una "regla de diagnóstico", podemos tener tantas reglas monitoreando procesos como se quiera y además las reglas se ejecutan mediante el servicio Debug Diagnostic Service (DbgSvc.exe) con lo cual se puede cerrar la consola de administración, la sesión interactiva y hasta reiniciar el sistema operativo y las reglas seguirán activas.

Una vez que obtuvimos un vuelvo de memoria utilizaremos WinDbg y SOS para analizarlo. Para ello primero deberemos configurar la variable de entorno NT_SYMBOL_PATH. Esta variable de entorno permite configurar todas las rutas (separadas por ;) donde WinDbg va a buscar los archivos de símbolos cuando los necesite. Los símbolos son archivos de datos que contienen información sobre el código ejecutable con el que están asociados. Esta información incluye los nombres de las funciones y su ubicación en memoria, los nombres de las variables globales y locales y su ubicación en memoria, información sobre el código fuente (números de línea, nombres de los archivos, etc.) y otra información importante para el debugging. Los archivos de símbolos de todas las versiones de Windows se pueden descargar desde http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx y los de las diferentes versions.NET Framework vienen incluidos en sus respectivos SDK's. Pero si contamos con conexión a Internet mientras estamos analizando un vuelco de memoria podemos configurar la variable NT_SYMBOL_PATH para que WinDbg descargue automáticamente los símbolos del servidor público de símbolos de Microsoft a medida que se necesiten, para ello debemos agregar el siguiente texto como si fuera una ruta más: *<directorio de descarga>*http://msdl.microsoft.com/download/symbols.

Ya estamos listos para utilizar WinDbg. Para abrir un vuelco de memoria debemos ir al menú File\Open Crash Dump y elegir el archivo que contiene el vuelco. Para comprobar si se el vuelco se ha generado correctamente podemos usar el comando ~ que lista información sobre todos los threads del proceso.

Una vez abierto el vuelco podemos cargar extensión SOS utilizando el comando .load <ruta de instalación de .NET Framework\SOS.dll>. Para probar SOS podemos utilizar el comando !EEVersion que lista la versión de .NET utilizada en el vuelco y el modo de ejecución del Garbage Collector.

En la ayuda de WinDbg se encuentra la referencia completa de todos sus comandos. La referencia de los comandos de SOS esta en el directorio SDK\v1.1\Tool Developers Guide\Samples\SOS dentro del directorio de instalación de Visual Studio .NET 2003. En la continuación de este artículo explicaré como utilizar alguno de estos comandos para diagnosticar el problema que tiene el programa de ejemplo con el manejo de memoria.

Con WinDbg y SOS también podemos hacer Live Debugging utilizando el mismo entorno y comandos que al analizar un vuelvo de memoria. Para esto se utiliza el menú File\Attach to a Process que despliega una ventana para que seleccionar cual de los procesos que actualmente se están ejecutando queremos depurar.

Conclusiones

Como hemos visto hay cierto tipo de errores en una aplicación que no se pueden diagnosticar utilizando los métodos usuales. En esta primera parte he explicado cuales son las técnicas y herramientas para diagnosticar efectivamente esa clase de situaciones. En la próxima parte pondremos en prácticas estas técnicas para diagnosticar problemas de memoria.

Rodolfo Finochietti es un profesional con amplia experiencia en el desarrollo de sistemas empresariales de gran escala y frameworks de aplicaciones. Rodolfo ha estado trabajando con la plataforma .NET desde sus primeras versiones betas y actualmente se desempeña como Arquitecto de Software, Ingeniero de Soporte y consultor en Lagash Systems una firma que provee consultaría y soporte en arquitecturas empresariales tanto en empresas de Argentina como del exterior.
Es frecuente orador en los eventos organizados por Microsoft Argentina, y desde su blog comparte con la comunidad su experiencia, ideas y piezas de código.

Graphics Computing: not just games and entertainment

Martin.Cabrera@microsoft.com — Wed, 11 Apr 2007 20:26:00 GMT

Authors:

Ph.D. Claudio Augusto Delrieux – Associate Professor - Universidad Nacional del Sur

Lic. Federico Andrés Lois – Consultant - Huddle Group (Computer Graphics Division)

The importance of graphics and visual reasoning can never be overestimated, as has been shown many times and in several research areas. As a biological species, we depend on visual information for most of our critical tasks and, because of that, more than 60% of the active areas of our brain are devoted to the processing of visual stimuli. As a culture, visual information is the most important means of communication, and many of our linguistic conventions appeal to the strong, rich, visual environment that we experience in our everyday lives. As technology producers and consumers, visually oriented products have been paramount. Computer technology is no exception to that.

Computer Graphics and its associated disciplines in Computer Science have been there for nearly 40 years. Even though the goals and purposes of graphics computing have been clear from the very beginning, the technological limitations constrained the full expression of what now can be considered as one of the most attractive, widespread, and socially relevant sides of the computing technology. A sustained growth of the share of computer graphics products in the entertainment market, together with the recent spectacular breakthroughs in graphic hardware development, are leading to revolutionary new ways of designing and programming systems. Graphics processors are becoming widespread, and imaginative uses of their processing power in non graphics related applications, are steadily emerging.

The computing capabilities of graphic processing units (GPUs) are increasing at an astounding rate, and the quality achieved by current off the shelf graphic products exceeds even the most optimistic expectations of just a few years ago. The current generation of GPUs is about to reach the Teraflop throughput mark, with a full parallel architecture that streams together 128 processors. In addition to this, runtime support provides the programmer with an adequate level of abstraction over the full programmability of the pipeline. Consequently, the most diverse kind of applications can take advantage of the computational power of GPUs when used as generic processors.

It would be short-sighted to think that the solutions that GPUs may provide are relevant or only limited to graphics. Examples of this are the upsurge of plug-ins that take advantage of GPUs in general-purpose software (for instance, matrix algebra accelerators for scientific software), and applications in DSP, data parallel algorithms, and database management, to name just a few. All these examples show how a less than US$ 400 card may perform several times faster than a US$ 2000, 3 GHz dual-core CPU, when adequately programmed. In fact, GPU acceleration has been successfully used in applications that range from research oriented software (for example gene sequencing, protein folding, and climate models) to industrial systems including chemical reactors simulation, video surveillance and analysis, and augmented reality for task instruction.

However, this good news has a problematic side, which is due to the influence of the hardware evolution in the life cycle of an application. In conventional hardware platforms (e.g., CPUs), the application life cycle is only influenced by major changes in the underlying architecture (for instance, upgrading from 32 to 64 bit processors). These changes are likely to occur seldom in the lifetime of a typical application. With GPUs this is hardly the case, since what can be considered as a “major change” in the underlying architecture happens at a yearly basis, sometimes even twice a year. Therefore, any reasonable design methodology should consider that the hardware that is available at the time of the specification of the application is going to be obsolete during its development phase, and will be two or three generations old at the moment of delivery. Consider now, how would your product look today if the binary was designed for 8 or 16 bit architectures?

This situation is rather unprecedented in the traditional Software Engineering discipline, and puts the software factories into a difficult quandary: either disregard the possibility of GPU-accelerated applications, or face the challenge of redefining the whole life cycle of their processes and products. The fact is that disregarding the inception of inherent parallelism in the underlying hardware platform can be suicidal for software companies, given the current trend in hardware development. Even what we know today as a CPU is probably going to evolve into architectures of several parallel processors in a chip. Examples of this are IBM’s Cell Processors, SUN’s multi-core architecture, and the new Intel and AMD releases. However, programming for those architectures has proven to be very difficult and error-prone. The complexities arising from the subtle interaction between processors and processes is daunting even for world-class software teams. Even though some products like IIS or Database Engines are able to abstract part of the concurrency problem, it is a known fact that unexpected performance hits, and subtle, difficult to diagnose errors are frequent in almost every application.

The software industry is constantly struggling to find creative ways of handling API complexity and obsolescence problems. It always pays back to invest in technologies that increase the support for higher abstraction and reduce the overall burden of the product’s engineering and development. In particular, they make the final products more competitive, and above all, they shorten the release times. In this aspect, GPU programming is subject to the currently strong evolutionary pressure in the games and entertainment industry. For this reason, hardware and software providers are beginning to offer general-purpose programming tools that enable rapid application development. To mention just a few, NVidia CUDA and Microsoft’s Research Accelerator are among the most remarkable examples.

NVidia CUDA provides a data parallel execution model for developing real time mathematical simulation and modelling. Programming is simplified though a special purpose C-like language supporting an adequate level of abstraction from the underlying parallelism and synchronization primitives. Runtime libraries allow for dynamic compiling and binding of GPU programs with the application program. Microsoft’s Research Accelerator, on the other hand, gives a .Net API the power to handle vectorized math procedures on the GPU, dynamically generating and loading the programs on the GPU.

The change is inevitable, independent of the specific shape that those technological breakthroughs are going to adopt, decision makers and developers alike should be aware that they will certainly be forced into a major change in how to specify, design, and implement software.

La Fuerza Aérea Argentina utiliza plataforma integrada Microsoft en simuladores y juegos de guerra para entrenamiento

Martin.Cabrera@microsoft.com — Wed, 11 Apr 2007 17:23:00 GMT

Con el objeto de renovar completamente la plataforma tecnológica para el entrenamiento de su personal, tras evaluar diferentes alternativas como Linux o Java, la Escuela Superior de Guerra Aérea creó un conjunto de simuladores y aplicaciones utilizando .NET y Windows Server System. Diferentes Fuerzas Areas de América y Europa reconocieron la calidad de la solución y comenzar a adoptarla para sus propios juegos de guerra.

Situación

La Escuela Superior de Guerra Aérea, perteneciente a la Fuerza Aérea Argentina, es el organismo de perfeccionamiento del personal Militar Superior de la Institución, dependiente del Comando de Personal. Para desarrollar esta actividad con un alto grado de excelencia fue integrada como Unidad Académica al Instituto Universitario Aeronáutico.

La formación de oficiales no incluye solamente a los pilotos sino también a un conjunto de expertos que intervienen en caso de un conflicto aéreo, como ser especialistas en radares, comunicaciones, guerra electrónica, ingenieros y artillería antiaérea, entre otros. Lograr un desempeño de excelencia requiere no solo del manejo de los aviones, armas y demás dispositivos, sino que se requiere del entrenamiento en la toma de decisiones y manejo de situaciones de crisis con muy poco tiempo de maniobra, alto grado de incertidumbre, múltiples variables para el análisis y niveles importantes de stress, considerando que hay acciones con resultados de consecuencias irreparables.

Desde hace muchos años se utilizan juegos de guerra en la capacitación de pilotos militares y diversos especialistas. Estos permiten poner ante diversas hipótesis de conflicto y escenarios concretos de combate a quienes están realizando su entrenamiento. “Las aplicaciones con las que contábamos tenían importantes limitaciones gráficas y de funcionalidad. Además, estaban construidas con tecnologías que requerían una gran dependencia de un equipo administrador del sistema, eran bastante inflexibles y reducía las posibilidades para incorporar el dinamismo y las variables que son propias de este tipo de actividades”, recuerda el Vice Comodoro Carlos Maroni, Jefe del Centro de Simulación y Juegos de Guerra. Como una evolución de lo que fuera el Departamento de Investigación Operativa, se creó el Centro de Simulación y Juegos de Guerra, que obligó a renovar el software que se utilizaba en la formación de oficiales.

Solución

En la búsqueda por contar con una herramienta más abarcativa de la experiencia tal como es en la realidad, que fuera flexible, pudiera operar en tiempo real y estuviera alineada con estándares internacionales, la Escuela Superior de Guerra Aérea creó un nuevo juego de guerra que es un verdadero simulador para la toma de decisiones de vuelo y combate; además, desarrolló otro sistema para el planeamiento, comando y control de operaciones aéreas denominado ICC (Integrated Command and Control), y un Juego de Estrategia Competitiva. “Creamos una solución única en Sudamérica, que ya están utilizando Perú, Venezuela, Bolivia, Uruguay e incluso España. La eligieron por ser la más completa a nivel de funcionalidades y la más moderna en cuanto a la tecnología utilizada. Las aplicaciones fueron construidas íntegramente con herramientas Microsoft, porque nos garantizan la productividad en desarrollo, la flexibilidad y el rendimiento que necesitamos. Si bien muchos no creían en el camino que elegimos junto a Microsoft, con los resultados a la vista, estamos muy satisfechos de lo que hemos conseguido”, agrega el Vice Comodoro Maroni.

Desde el inicio mismo del desarrollo de la nueva versión del Juego de Guerra, la inminencia de ejercicios militares planificados por el Comando de Operaciones de la Fuerza Aérea Argentina imponía plazos muy cortos para su puesta en marcha. “Veníamos de una historia con un viejo juego de guerra, iniciado en Fortran y una actualización a Visual Basic. Para atender a los nuevos requerimientos evaluamos utilizar Delphi, Java, lenguajes que corren sobre Linux. Finalmente adoptamos la plataforma .NET, particularmente el lenguaje C#, al mismo tiempo que lo aprendíamos a utilizar. Nos sorprendió la facilidad con la quepudimos dominarlo y construir nuestras aplicaciones. Cuando encaramos el desarrollo del sistema de comando y control, vimos que con otras herramientas nos llevaría más de dos años con cinco personas trabajando en eso. Finalmente pudimos resolverlo en tan solo 6 meses, incluso con personas en el equipo que empezaron a programar sin conocer .NET, una tecnología que cambia los paradigmas anteriores respecto de la cantidad líneas de código que se pueden generar por cada desarrollador”, comenta Mario Crippa, uno de los programadores principales de la Escuela. Por su parte, el Vice Comodoro Maroni recuerda que “al comienzo hubo algunas resistencias respecto a la tecnología Microsoft, por las necesidades que tendríamos de trabajar en tiempo real. Lo cierto es que toda la plataforma demostró una gran solidez en términos de confiabilidad y rendimiento, y también una gran versatilidad, permitiéndonos obtener resultados excelentes. Hasta la Fuerza Aérea de Francia nos felicitó públicamente en el último ejercicio multinacional CRUZEX 2006, realizado en Brasil, por la calidad del producto que habíamos creado con la aplicación de Comando y Control”.

El simulador del Juego de Guerra permite conformar dos equipos, representantes de sendas regiones o países, cada uno de los cuales tiene acceso a un sitio SharePoint para acceder a los diversos formularios que permiten solicitar requerimientos de ayuda en pista, abastecimiento general, armamento y otros recursos necesarios para el combate. Con la utilización de workflows se logran las aprobaciones correspondientes y los procesos van pasando por las diferentes etapas que corresponden. Para cada ejercicio de simulación se arma una operación aérea que puede tener parámetros reales o ficticios. A las decisiones de acción que va tomando cada grupo, el sistema va resolviendo lo que sucederá a partir de complejos cálculos probabilísticos y la contrastación con los parámetros pre-establecidos. Asimismo hay secuencias lógicas que deben respetarse para no cometer errores o forzar fallas del equipamiento virtual. A su vez, hay un Estado Mayor designado para cada ocasión, que se ocupa de evaluar las alternativas que se van sucediendo y quien evaluará finalmente el desempeño de los participantes. “Son ejercicios donde se pone en juego la capacidad para la planificación de corto plazo y la toma de decisiones. Cada grupo tiene 7 consolas, cada una con una función específica: inteligence, current operation, planning, logistic real time, electronic warfare, report y communication. Cuando un avión ingresa en el evento despegue y abandona la órbita controlada logísticamente por la base aérea, los eventos controlados por el piloto son administrados por el sistema lo hasta reingresarlo nuevamente, pudiéndolo hacer el jugador bajo el concepto de ‘decisión humana’ o dejarlo bajo custodia del módulo de ‘inteligencia artificial’. Participan unas 20 personas por grupo más 10 personas en la Dirección del Juego, así que hay entre 50 y 60 involucrados, en cada actividad que dura una semana con una cantidad limitada de horas por día, dado que en su desarrollo se genera un gran stress. Hay tiempos reservados para la planificación, y diferentes modalidades para resolver situaciones con más o menos tiempo disponible, e incluso escenarios políticos que implican diferentes interacciones simuladas, abogados especializados en derecho bélico y otros asesores típicos de una situación de crisis”.

Estas tres aplicaciones (simulador de juego de guerra, comando y control, y estrategia competitiva) fueron creadas con tecnologías .NET, utilizando una arquitectura de 3 capas y remoting; la herramienta fue Visual Studio 2003 y actualmente se está evaluando la incorporación de la versión 2005. Están corriendo sobre servidores con Windows 2003 Server (con sus servicios SMTP integrados en las aplicaciones y Active Directory para el manejo de políticas de grupo para cada uno de los equipos participantes) y SQL Server 2000 (actualmente en proceso de migración a 2005); también cuentan con un Microsoft Exchange Server 2003. Si bien la configuración estándar es de 25 terminales por cada procesador del servidor de juegos, hubo casos como el de Venezuela que pudo utilizar las aplicaciones con más aviones, más radares y más terminales con resultados muy positivos. “Ellos eligieron nuestra solución basada en la plataforma integrada Microsoft, señalando que era la propuesta tecnológica más completa entre las alternativas que habían evaluado”, comenta Maroni. En el caso de Perú, las aplicaciones adaptadas a los requerimientos puntuales del país andino, estuvieron operativas en tan solo 24 horas.

Para la representación gráfica de los escenarios de combate se utilizan tecnologías DirectX y el equipo de desarrollo del Centro de Simulación ya está explorando las posibilidades de Windows Presentation Foundation, que forma parte del .NET Framework 3.0. “Buscamos el máximo realismo posible, tenemos arquitectos que hacen los diseños en base a medidas existentes y reproducimos visualmente lo que sucedería en la realidad con un impacto, por eso ya estamos yendo a un modelo 3D; además, usamos cartografía vectorial para representación de los que ‘ve’ el radar”, comenta Crippa.

Beneficios

“Este tipo de simuladores, como el que creamos para los Juegos de Guerra en la Fuerza Aérea Argentina, cambian la forma de entrenar a nuestros oficiales. Aquí, y en los otros países donde fueron implementados, a partir de esto se renuevan los planes de estudio, cambia la manera de calificar y el resultado final de todo esto que es estamos mejor preparados para cumplir nuestra misión, ubicando a las Fuerzas Aéreas en los más altos estándares mundiales de simulación para la toma de decisiones. Utilizando toda la plataforma Microsoft, desde la infraestructura hasta las tecnologías de desarrollo, para crear y operar ésta que es nuestra aplicación de misión crítica, obtuvimos resultados espectaculares, alcanzando los más altos niveles de seguridad, confiabilidad y rendimiento. Ahora estamos al nivel de lo que se utiliza en la OTAN y de lo que es un ejercicio real”, señala el Vice Comodoro Carlos Maroni, Jefe del Centro de Simulaciones y Juegos de Guerra de la Escuela Superior de Guerra Aérea de la Fuerza Aérea Argentina.

“Ahora, con las tecnologías que estamos utilizando, los ejercicios fluyen mucho mejor, los concursantes y asesores van llevando las distintas alternativas del juego con gran autonomía, dejando al área de sistemas tiempo para concentrarse en mejorar permanentemente el rendimiento, incrementar la escalabilidad de la solución e introducirle más funcionalidades. Además, con Active Directory y ASP.NET podemos manejar diferentes niveles y estrategias de seguridad más completas y eficaces, brindando accesos a carpetas y documentos por perfil, que constituyen una gran mejora a las aplicaciones”, agrega Mario Crippa.

“El uso de Office SharePoint Server marcó un antes y un después. Antes teníamos páginas HTML y cada cambio o imagen que era necesario publicar, implicaba un requerimiento a sistemas, lo que hacía muy lento el proceso por la cantidad de solicitudes. Ahora cada grupo tiene su espacio y puede publicar o editar contenidos con gran facilidad. Nos sorprendió la velocidad con la que los usuarios se acostumbraron a SharePoint después de participar de un workshop dictado por gente de Microsoft Argentina. En tan solo 3 horas logramos cumplir una tarea que antes nos demandaba una semana”, amplia Maroni. Por su parte, Crippa cuenta que “además de los libros para conocer las tecnologías de desarrollo Microsoft, estamos suscriptos a MSDN y estuvimos aprovechando el programa Desarrollador Cinco Estrellas”.

“Con el sistema de Comando y Control, los oficiales que están realizando su entrenamiento pueden realizar una completa planificación de una operación aérea en diferentes fases y plazos. Cuando todo está dispuesto en el teatro de operaciones a nivel teórico, con el uso del simulador del Juego de Guerra, la práctica es completa. Esto constituye una verdadera revolución y estamos orgullosos de liderar regionalmente las innovaciones en esta materia”, concluye el Vice Comodoro Maroni.